Amplifier_Dopu.lha   biz/dopus    0K+Load MPEG AUDIO files into Amplifier wit
DeliTracker2_D.lha   biz/dopus    1K+Load Modules into DeliTracker2 with Dopu
VE-addspaceb.lha     gfx/edit     2K+Visual Eng. - Add space B v1.03
SvII-2.lha           gfx/misc   209K+SViewII V8.30 (31.3.99) - Part 2/8
SvII-8.lha           gfx/misc   211K+SViewII V8.30 (31.3.99) - Part 8/8 (opti
houseBreed.lha       mods/house  40K+A happy house PT module by Breed
lns30jungleEp1.lha   mods/jungl 376K+JungleEp p1 - Devils delegate
lns30jungleEp2.lha   mods/jungl 330K+JungleEp p2 - a lovely bomb
lnsR4_diarrea.lha    mods/jungl 372K+Summer diarrea - jungle
A2-MRb338.lha        mods/misc   30K+Astrosyn`2 - Rebirth-338 music compo ent
astralBreed.lha      mods/techn  36K+A little techno PT module by Breed
lns28_tomatEp1.lha   mods/techn 236K+Tomat Ep p1 - A happy tomato
lns28_tomatEp2.lha   mods/techn 134K+Tomat Ep p2 - meanwhile
lns29_arson.lha      mods/techn 230K+Premeditated arson - techno house
lns31technoEp1.lha   mods/techn 172K+Techno ep p1 - Monster
lns26_hardEp1.lha    mods/tranc 389K+Hardtrance ep p1 - snowblower
lns26_hardEp2.lha    mods/tranc 494K+Hardtrance ep p2 - On sale
lns27_goaEp1.lha     mods/tranc 585K+Goa Ep p1 - empty brain
lns27_goaEp2.lha     mods/tranc 450K+Goa Ep p2 - segregation of objekts
nearBreed.lha        mods/tranc 159K+A little trancy PT module by Breed
RachelRuns.jpg       pix/art    232K+Rachel Raccoon finishes running with a p
A2-G24bit_1.lha      pix/misc   2.2M+Astrosyn`2 - 24bit gfx compo entries [1/
A2-G24bit_2.lha      pix/misc   1.5M+Astrosyn`2 - 24bit gfx compo entries [2/
A2-GAscii.lha        pix/misc     7K+Astrosyn`2 - ascii graphics compo entrie
A2-GPixel_1.lha      pix/misc   1.3M+Astrosyn`2 - pixel compo entries [1/2]
A2-GPixel_2.lha      pix/misc   1.9M+Astrosyn`2 - pixel compo entries [2/2]
A2-GTrace_1.lha      pix/misc   1.1M+Astrosyn`2 - raytracing gfx compo entrie
A2-GTrace_2.lha      pix/misc   2.1M+Astrosyn`2 - raytracing gfx compo entrie
Notes1.5.lha         text/dtp   283K+ProPage4 Notes-print-Genie Deu&Eng
mpgerman.lha         util/misc    3K+German Catalog for Miamiphone V1.5
SummerGer.lha        util/time    3K+German Catalog for sguard V 1.0

From: Titan Computer Amiga Hard&Software <MacFly@TitanComputer.de>
To: Petra Struck <petra.struck@online-club.de>
Date: Thu, 01 Apr 1999 10:18:08 +0100
Subject: Re: mailto:MacFly@TitanComputer.de

Hallo Petra,

Am 27-Mär-99 schriebst Du:
> Hallo MacFly,
>
> ich wende mich nochmal an Euch wegen SiedlerII.
> Es geistern ja mittlerweile jede Menge "News" zu
> diesem Thema durch Netz.

Ja, das ist richtig jeder, jeder User hat seine ganz eigenen "News". Fakt
ist, daß Blue Byte die Lizenz zurückgezogen hat, unter dem fadenscheinigen
Argument, daß sie zu sehr mit der Umsetzung belastet werden würden. Die
einzige Belastung für sie wäre gewesen eine CD mit den nötigen Daten
zusammen zustellen, 2-3 Stunden Arbeit sind das besten Falls.
Wir haben, nachdem diese "Begründung" kam, nocheinmal schriftlich
garantiert, daß wir keinerlei technischen Support Seitens Blue Byte
benötigen. Leider hält es Herr Hertzler nicht einmal für nötig auf unser
Angebot zu reagieren. Also somit ist Siedler 2 für uns gestorben.

>
> Einige sagen, SiedlerII sei komplett gestrichen.
> Meine letzte Info war, daß Ihr von Blue Byte nicht
> den nötigen Support bekommt.

Wir haben alles soweit fertig es fehlen nur noch die Daten von BlueByte.
Aber mittlerweile reicht es mir, denn seit nun mehr als 1 Jahr zieht sich
der Quatsch hin und außer heißer Luft ist bei BlueByte nichts zustande
gekommen. Sie benötigten sage und schreibe 7 Monate, um eine Entscheidung
zu fällen. Die erhielten wir dann Anfang Oktober, da hieß es per Telefon
durch Herrn Simon "Ok, sie haben die Lizenz, schicken Sie uns die Verträge
zu" Gesagt getan und wieder passiert wochenlang nichts, ständig wurden wir
auf neue Termine vertröstet, bis dann im Januar die Absage erteilt worden
war.
Daraufhin habe ich nocheinmal mein Mindestlizenzgebot erhöht, sowie
schriftlich garantiert, daß wir keine Support von Blue Byte in Anspruch
nehmen und auch nach dem Release der Usersupport von uns übernommen wird.


Um mal ein paar positive News abzugeben. Wir haben zusammen mit ACT(Apollo)
und Haage ein PPC G3/G4 Projekt für den A1200 ins Leben gerufen.

Das Twister Projekt zeichnet sich durch folgende techn Merkmale.
(Gerüchteweise haben einige Spezialisten dies als Viper-projekt im Umlauf
gebracht das ist natürlich Quatsch gewesen.)

G3/G4 Karten von 300-450Mhz, 2 Ram Sockel für bis zu 512MB SGram (100Mhz),
512kb 2nd Level Cache, 2MB Flashrom on board für 68xxx Emulation und Karten
Bios, 2 local PCI Slots mit je 100 Mhz für RivaTNT2 Gfx-Karte mit 8MB SGRam
und einem UW-SCSI Kontroller

Der geplante VK für die G3 Karte mit 300 Mhz sind DM 999.- Release 4 Quartal
99

RivaTNT addon DM 349.-
UW-SCSI-Kit   DM 299.-


Bei BurnIT gibt es auch was Neues V2.25 ist released worden:

- Support des Joliet-File Formates
- mpeg3 encoder für das Audiostudio
- Bugfix für Trackanzahl es sind jetzt die vollen 99 Track per CD möglich
nicht nur wie bis
  her 98 (Anmerk. gab wirklich jemanden, der sich wegen diesem einen Track
aufgeregt hat)

Mfg

Michael Garlich

*** E-Mail: MacFly@TitanComputer.de             ***
*** Web   :http://www.TitanComputer.de          ***

Date: 01 Apr 99 14:24:37 +0100
Subject: SViewII PPC/WOS information
To: aakt@gmx.de, petra.struck@online-club.de, webmaster@amiga.org
From: Andreas_Kleinert@t-online.de (Andreas R. Kleinert)

Hi,

 as you may have noticed, SViewII 8.30 and PNG/JPEG-Box V4.10
 now also do offer basic WOS support (although not all of
 the PPC modules already have been converted from .svm to .dll).

 However there did happen a small mistake with the 31 March release,
 so please note the following:

 There's a BIG bug in svppclaunch.library V1.0 and all PPC users should download
 Aminet:gfx/misc/SvIIFix830.lha as well - it does include V1.1 of the library.

 This version already has been detected to have another small bug: LOADELF_WOS=ON
 is default, which should have been =OFF (simply go to SVPrefs and change it
 manually to =OFF).


 P.S.: This isn't an April fools mail ;)

--
Andreas_Kleinert@t-online.de  or via @gmx.de | ARK@News.wwbnet.de
Or try good, old: FidoNet 2:2457/350.18 --- *SuperView* development
PerSuaSiVe SoftWorX - Software Engineering Amiga/Wintel and more
Visit http://wdo.de/ark/ for information, free downloads, registration

Subject: 6/7/8 august 1999: chaos communication camp
Date:    Wed, 31 Mar 1999 22:02:56 +0200
From:    Chaos Update <chaos-update-owner@lists.ccc.de>
To:      "Chaos Update" <chaos-update@lists.ccc.de>

Liebe Hacker,

vor einiger Zeit hat die intergalaktische Kontaktgruppe des CCC ein
Notsignal empfangen: im Raumschiff Herz Aus Gold ereignete sich an Bord
ein schwerwiegender Computerfehler und bedarf nun einer dringenden
Reparatur. Die Kontaktgruppe verständigte sich mit der Bordcrew auf eine
Reparatur unter Gravitationsbedingungen auf unserem Planeten. Die
Vorbereitungen laufen auf Hochtouren und im August wird das Raumschiff
nun endlich landen.

     http://www.ccc.de/camp/story.html

Anläßlich der Ankunft der Herz Aus Gold organisiert der Chaos Computer
Club eine Drei-Tage-Hack-Session im Freien für Nerds, Hacker und Phreaks
aus der ganzen Welt. Die Veranstaltung steht in der Tradition der HEU
(93) und HIP (97) in Holland und damit für viel Spaß am Gerät. Gemeinsam
werden wir die Herz Aus Gold schon wieder flott machen.

     http://www.ccc.de/camp/camp.html

Das Camp findet vom 6. bis 8. August 1999 auf einer Wiese in der Nähe von
Berlin statt. Wir werden die notwendige Infrastruktur für einen
angemessenen Hackerurlaub bereitstellen (Strom, Internet und
Möglichkeiten zur Nahrungsaufnahme) und die Aktivitäten auf dem Gelände
koordinieren.

Du bist eingeladen, Dein Zelt und Deinen Computer mitzubringen und Deine
Geräte an das Campnet und damit an das Internet anzuschließen. Die
Internetverbindung wird befriedigend breitbandig ausfallen. Mehr Details
zur Technik später.

Alle Informationen (zur Zeit nur in englisch) finden sich unter

     http://www.ccc.de/camp

Die deutsche Web Site und eine umfangreiche FAQ sind in Vorbereitung.
Weitere Informationen werden über die camp-announce Mailingliste
erhältlich sein. Wer alle Informationen zum Camp automatisch erhalten
will, kann sich durch eine leere Mail an

     camp-announce-subscribe@lists.ccc.de

auf der Liste eintragen lassen.

Wir hoffen auf eine rege und aktive Beteiligung auf dem Camp (das Camp
wird für 1500-2000 Leute ausgelegt). Wir erwarten eine Vielzahl von
Projekten zu den unterschiedlichsten Themen (Kryptographie, Free
Software, Chipcards, Astronomie, Meteorologie). Wer Lust hat, eigene
Projekte auf dem Camp zu realisieren, sollte sich mit der Orga-Crew in
Verbindung setzen: crew@camp.ccc.de.

Für die Presse wird es besondere Richtlinien geben, die derzeit noch
ausgearbeitet werden. Auch dazu später mehr.

Chaos Computer Club
März 1999

From:    Salva <Salva.Fernandez@rhein-main.netsurf.de>
To:      Petra Struck <petra.struck@online-club.de>
Date:    Wed, 31 Mar 1999 20:54:22 +0000
Subject: G3/G4 Projekt

Hallo Petra,

es gibt erfreuliche Neuigkeiten aus dem phase 5 Lager !

Bitte setze doch diese Mail in Ihrer ursprünglichen Form
in das Netz. Danke

Nachdem ich heute ein ausführliches Gespräch mit Wolf Dietrich
hatte, haben sich folgende neue bzw. ergänzende Tatsachen
heraus kristallisiert.

Das Cyberstorm G3/G4 Projekt wird, nach den ja derart schon
massenhaften Vorbestellungen, die innerhalb kürzester Zeit aufgekommen
sind, in den nächsten 2-3 Wochen aufgegriffen und somit komplett
im Laufe der Zeit realisiert. Eine Vision wird somit wahr.
Wer hätte noch vor Kurzem an eine G3/G4 Beschleunigerkarte
von phase 5 gedacht.
Herr W. Dietrich ist auf Wünsche und Vorschläge der User, Händler,
Programmierer, sowie verschiedenen Entwicklern, eingegangen um
einen weiteren Meilenstein in der Geschichte des Amigas zu setzen.
Herr Dietrich hat die Zeichen der Zeit wahrgenommen um dadurch
auf eine verheissungsvolle Technologie des nächsten Jahrtausends
zu setzen.
Bestandteil des Gespräches war unter anderem auch die Frage nach
einer Grafikkarte. Die existierenden Grafikkarten verfügen derzeit über
einen sehr leistungsfähigen Permedia 2 Prozessor, welche
an einem dafür speziell angefertigten Hochleistungsbus an der
Cyberstorm PPC oder Blizzard PPC angeschlossen wird.
Auf der Cyberstorm G3/G4 soll dieser Grafikkartenanschluß aus
Platz- und kostenbedingten Gründen nicht vorhanden sein.
Deswegen wird derzeit über eine Grafikkarte mit z.B. einem high Speed
3D Grafikprozessor Permedia 3 von 3D Labs und Texas Instruments,
mit z.B. 32MB VideoRAM vehement nachgedacht.

Ein anderer wesentlicher Aspekt bzw. Gesichtspunkt trägt
offenbar die schon ehemals verkündigte Multiprozessor-Technologie.
Hier möchte man gegenüber anderen Computersystemem,
durch die Integration von 2 oder gar 4 ZIF Prozessorsockeln,
dem Amiga einen Vorsprung bieten können.
Man überlege sich z.B. eine Cyberstorm G4 mit zwei 300MHz G4 PPC
Prozessoren zu verwirklichen. Eine solche Karte würde nicht
die Verdopplung des Preises von 899 EURO heisen, sondern könnte z.B.
für ca. 1.199 EURO verwirklicht werden.
Bei vorhandener Software, die die Altivec Technologie der G4 Prozessoren
unterstützt, sind Geschwindigkeitssteigerungen gegenüber dem G3 Prozessor
um gar 4-5 mal schneller, durch aus realistisch. Durch Multiprocessing ist
der Rechner dann wahrhaftig nicht mehr zu "bremsen". ;-)

Hiervon abgesehen können Interessierte weiterhin Vorbestellungen
tätigen, da erst bei Beginn der Erstellung von den ersten Karten die Kunden
nochmals gefragt werden, welche Version Sie denn gerne hätten bzw.
bei zukünftigen Änderungen wird auf Kundenwünsche eingegangen.

Das natürlich jetzt auch noch die Amiga 1200 User unsere Unterstützung
erhalten, ist eine klare Entscheidung, der man nicht oder nur ungern aus-
weichen würden. Das Projekt der Blizzard G3/G4 Karten ist auch hiermit
eindeutig beschlossen und wird mit höchster Sorgfalt entwickelt werden.
Nichts desto trotz ist dies auch eine kleine Reaktion auf anderweitige
Vorankündigungen, die gerade kurz nach unserer plötzlich erscheinen.
Wodurch ein Mitbewerber hier versucht, auf bestimmter Art und Weise auf
dieses Projekt wie auch auf das Geschäft zu intervenieren.
Das ist also ganz meine persönliche Meinung bzw. mein persönlicher Eindruck.
Wie heisst es so schön......Konkurrenz belebt das Geschäft, obwohl
ich in der Hinsicht weniger an die Konkurrenz glaube, als an andere
Sachen....
Die Vergangenheit hat gegenteilige Fakten auf den Tisch gelegt, wie z.B.
das plötzliche nicht Erscheinen auf bestimmten Amiga Messen und so
ne..........

Zum Zeitpunkt sitzen seit 19 Uhr in Frankfurt die führenden und leitenden
Kräfte des Amiga Marktes zusammen, um der Zukunft des Amigas
mit höchster Kreativität und neuen Impulsen die genialen Innovationen
der Firma phase 5 digital products zu unterstützen.

Petro Tyschtschenko, Jürgen Haage sowie Wolf Dietrich beraten
derzeit die Situation des Amigas, um signifikante wie auch
effiziente Pläne für die Zukunft zu schmieden.

Bin gespannt mit welchen ereignisreichen Ergebnissen hierbei
zu rechnen ist.

Die neue, große und hoffnungsvolle Amiga Phase [5;)] hat hiermit begonnen.

Vorbestellungen meiner begeisterten Kumpels, sowie die meinerseits
sind schon längst abgegeben worden. Die Vorauskasse bezahle ich gern,
wenn die Vorankündigungen der Leistungen eingehalten wird. Dann
lohnt sich das Ganze sehr. Wer der Meinung ist, daß ca. 2.000,- DM zuviel
für eine G3/G4 Karte sei, der soll doch bitte sich eine aktuelle Macintosh
Zeitschrift holen und nach den Preisen von G3 ZIF Prozessor-Modulen
Ausschau halten. Er wird bemerken, daß das günstigste G3 400MHz Modul,
wo nur der Prozessor und der Backside-Level-Cache drauf ist, ca. 1.700,- DM
bezahlt. Übrigens ist das günstigste Angebot auch von phase 5. Wer sich
einen
G3 Prozessor-Modul von z.B. NewerTek holt, der wird dann locker noch ein
paar Scheinchen hinlegen müssen.
Somit erhält man für ca. 300,-DM eine Cyberstorm G3/G4 mit 1-4 ZIF Sockeln,
UW-SCSI onboard, zwei SD-RAM Bänke, zukunftsträchtige FireWire Ports,
PCI 2.1 Interface, 1 Direktslot für z.B. eine Permedia 3 GKarte sowie den
512KB FlashROM. Von der 68k Emulation mal abgesehen.
Also was wollt Ihr denn noch ?

In diesem Sinne...........

Where do you want to be tomorrow ?

Gruß

Salva


See you later .....
--

``````````````````````\_______________________________/`````````````````````````
                         |    »»»SALVAFACTORY©«««   |

``````````````````````````````````````````````````````````````````````````````````````````````
AMIGA POWER against monopolism ! Stop that lousy WINTEL-System !

REMEMBER: ITS NOT THE CHIPS OR MIPS......,THE OS IS THE BOSS!

AMIGA 4000T MICRONIK^CYBERSTORM PPC PHASE V DUALBOARD
    WITH MOTOROLA 604e 233MHZ & 68060 66MHZ PROCESSOR
 WITH ULTRA-WIDE SCSI CONTROLLER & IBM DCHS 9 GIG UW-SCSI
152MB-TOTAL-FAST-RAM^CYBERVISION PPC WITH T.I. PERMEDIA 2
`N` 8MB SG-RAM^SILICON GRAPHICS 20" MONITOR^YAMAHA SOUND
ITH ISDN-MASTER II REV.8^MACROSYSTEMS VLAB MOTION SVIDEO
NONLINEAR EDITING STATION WITH TOCCATA SOUND & MOVIESHOP
SOFTWARE^DIGITAL BROADCASTER 32 PROFESSIONAL NONLINEAR
EDITING STATION FROM DIGITAL MICRONIKS^FRAMEMACHINE AND
PRISM 24 S-VIDEO-GRABBER FROM ELECTRONIC DESIGN...........etc.
                                                ///
                                               ///
                                         \\\  ///
                                           \X//
...................and he`s still the SURVIVOR. Long live the Amiga
community.

                        ------AMIGA RULEZ-------

                   DON. SALVADOR FERNANDEZ GOMEZ

                            FON___+49 (0) 6101 500039
                            FAX___+49 (0) 6101 127579
                            BBS___+49 (0) 6101 127579
                            GSM___+49 (0) 172 6532859
                          http://www.aranea.net/~sfernand
                e-mail: Salva.Fernandez@rhein-main.netsurf.de
                       e-mail2: donjuan@stud.fh-frankfurt.de

                    AMIGA - THE LAST LINE OF DEFENSE

From:    Martin Baute <solar@baud.de>
To:      Petra Struck <petra.struck@online-club.de>
Date:    Wed, 31 Mar 1999 12:46:37 +0100
Subject: Hilfe - ISDN?

Hallo,

soeben hat der Postbote mein ISDN-Paket gebracht. Enthalten ist u.a. eine
Fritz!X PC-Box (externes ISDN-Modem).

Nun spricht das Handbuch an allen Ecken von CAPI. Ich hatte bei der Hotline
vor der Bestellung extra gefragt, ob die Fritz!X auch per AT-Befehle an-
gesteuert werden kann, was bejaht wurde.

Nur, im Handbuch steht nix davon!

Du hast doch ISDN? Gibt es da irgendwelche Software, die ich mir besorgen
müßte, oder soll ich auf Teufel komm raus Miami auf die Fritz!X loslassen,
und zusehen, was passiert?

(Wenn's schiefgeht, wäre ich vom Internet abgeschnitten... :-( )

Mit freundlichen Grüssen
--
    Martin Baute          /// Amiga A1200 Towerhawk - PowerPC 603e / MC68060
 => solar@baud.de <=     /// Newsmaster & VersionWatch at http://www.baud.de
Member of Team AMIGA \\\/// Member of the Bielefeld Amiga Users & Developers
100% Microsoft free!  \XX/ "Move, and you're dead." "I am dead, and I move!"

Amiga, MS-DOS, Windows: The Good, the Bad and the Ugly...

Hier noch ein Ausschnitt aus einer zweiten Mail von Martin:

Allerdings habe ich gerade etwas herumexperimentiert, und Miami kann mit
der Fritz!X nicht das geringste anfangen. Sieht so aus, als hätte ich mich
zu früh auf die heile ISDN-Welt gefreut... :-(

Ich werde jetzt erst einmal versuchen, mein 33.6k Modem als Analoggerät
an die Fritz!X anzuschließen. Dann hätte ich immerhin schon mal ISDN-
Telefonie plus 33.6k Internet plus zwei Kanäle plus drei Rufnummern. Auf
die Voice-/Fax-Funktionen sowie den 64k-Zugang werde ich dann wohl
verzichten müssen. (Wozu, zum Henker, habe ich mir eigentlich so voreilig
STFax zugelegt? Gargl... :-( )

Na, vielleicht dann unter OS 5... :-/ Schade, die Fritz!X ist vom Funktions-
umfang her einfach klasse, günstig (149,- DM bei ISDN-Neuantrag) und sehr
leicht erhältlich (1&1, Conrad). Rennt da draußen evtl. irgendjemand rum,
der einen Fossil/CAPI-Treiber für die Fritz!X stricken könnte?

Und noch eine Message ist gerade eingegangen:


On 31-Mär-99, Petra Struck wrote:

> Martin Baute (solar@baud.de)
> schrieb am: 31-Mär-99 um 12:46:37
> zum Thema:  Hilfe - ISDN?

> Hallo Martin,

>> soeben hat der Postbote mein ISDN-Paket gebracht. Enthalten ist u.a. eine
>> Fritz!X PC-Box (externes ISDN-Modem).

Ein Anruf bei der 1&1 Hotline erbrachte folgendes:

Man entschuldigte sich zerknirscht für das Mißverständnis: AT-Befehle
verstünde die Fritz!X nur über einen (mitgelieferten) Spezialtreiber -
für Windows... :-/

Man bot mir an, die Fritz!X zum Differenzbetrag gegen eine Hagenuk
SpeedDragon umzutauschen.

Kurze Frage an die ISDN-Kenner: Taugt die SpeedDragon? Was ich gerne
hätte, wäre 64k-ISDN Datentransfer, Voice, AB, Fax (STFax vorhanden)
und eine Möglichkeit zum Anschluß eines analogen Telefons (letzteres
muß nicht unbedingt, wäre aber nett). Ach ja, und AT-Befehle sollte
sie beherrschen - aber da Miami Voreinstellungen für die SpeedDragon
hat, gehe ich davon mal aus. Bringt die SpeedDragon mir das?
Und was kriege ich an Mehrwert gegenüber der Fritz!X für die 100,- DM
Preisunterschied?

Dann höre ich auch auf zu nerven... ;-)

Regards

    Martin Baute          /// Amiga A1200 Towerhawk - PowerPC 603e / MC68060
 => solar@baud.de <=     /// Newsmaster & VersionWatch at http://www.baud.de
Member of Team AMIGA \\\/// Member of the Bielefeld Amiga Users & Developers
100% Microsoft free!  \XX/ "Move, and you're dead." "I am dead, and I move!"

"If you strike me down I shall become more powerful
than you can possibly imagine."
- Obi-Wan Kenobi

Nachtrag vom 01.04.1999

1&1 zeigt sich kulant: man schickt mir die SpeedDragon, und die Fritz!X
muß ich erst bei Erhalt der SpeedDragon zurückschicken. Preislich lag
wohl ein Mißverständnis vor (die Hotline hatte ja 100,- DM Aufpreis
gennannt), der Versand berechnet nur 30,- DM. Man mailt sich demnächst
mit ISDN...

bulllister.lha       comm/cnet    5K+Bull Lister Version 1.0
KewlStory_12.lha     comm/maxs   49K+Let your callers make up a story, 1.2
MagicFile_46.lha     comm/maxs  178K+Automated file menus & more for MAXs, 4.
EMR-ResTito.lha      demo/aga   3.9M+"Restito" by Embora - 6th at Astrosyn`2
PHT-Schedule.lha     demo/aga   3.1M+"Schedule One" by Phase Truce - 7th at A
DKG-BreezeNow.lha    demo/intro   5K+5th place at Astrosyn'99!
noe_ppc_c2p.lha      dev/asm    195K+Ppc c2p converters (8bpp and 15bpp)
gtshape.lha          dev/basic    3K+Blitz2 - code for fixing GTShapes
FlashROM_11.lha      disk/cdrom  16K+Amiga tool to change the flash ROM of Pl
b5guide.lha          docs/hyper 102K+Babylon 5 Episode Guide
ovenbird_src.lha     game/misc   41K+Source codes for Ovenbird v0.50
RushHour_16a.lha     game/misc  344K+Switch trafficlights, like C64 Traffic
MortalKombat2H.lha   game/patch   5K+MortalKombat2_Hd {4 disks)
PowerView.lha        gfx/show    75K+JPEG Viewer (CGFX and AGA) for PPC-Amiga
PowerView.readme     gfx/show     2K+JPEG Viewer for AGA and PPC (BETA!)
imdbDiff990319.lha   misc/imdb  1.5M+Diffs for the Internet MovieDatabase
mw_trust.lha         mods/wmr   1.4M+IMM: "Trust" by wOOd/Acid Demons
MMULib.lha           util/libs  218K+Library to ctrl the MC68K MMUs, beta
ShowMem.lha          util/moni   15K+Shows memory fragmentation via gfx
BenchTrash.lha       util/wb    185K+Global trashcan for WB, with eject suppo

sakkare.lha          biz/dopus  177K+Awesome theme for magellanII
sshnote.txt          comm/net     0K+Note regarding comm/net/SSH.lha.
GetAllHTML.lha       comm/tcp    13K+Auto-download entire web sites! (v0.61 )
MyHost.lha           comm/tcp     7K+Shows your host on one or all interfaces
FLP-Elthiag.lha      demo/aga   3.3M+"Elthiag" by Floppy - 3rd at Astrosyn`2
UDP_Chat.lha         dev/basic   94K+UDPfuncsV2.3 for Blitz-good for Net game
E-List9811.lha       dev/e      127K+All November 98 msgs on the AmigaE Maili
E-List9812.lha       dev/e       50K+All December 98 msgs on the AmigaE Maili
E-List9901.lha       dev/e       49K+All January 99 msgs on the AmigaE Mailin
E-List9902.lha       dev/e       53K+All February 99 msgs on the AmigaE Maili
AutodocV131.lha      dev/misc    28K+A really neat autodoc viewer v1.31 (OS3.
ReCatItProGRca.lha   dev/misc     5K+ReCatItPro v1.00 Greek catalog
MakeCDdeutschD.lha   disk/cdrom 322K+German documentation for MakeCD V3.2b
BUFF_Gde.lha         docs/hyper 100K+Buffy Vampire Slayer Episode Guide (51)
ACNews_9.lha         docs/mags   62K+E-zine focused on Amiga News: #9-Mar 99
SCSI_PCMCIA.lha      docs/misc  124K+Allows you to connect a SCSI PCMCIA read
startrekanm.lha      game/think 3.1M+Optional Anims My Star Trek Game
startrekprg.lha      game/think 998K+Updated Star Trek Game! Hires graphics!
Sezioni.lha          misc/misc  112K+Sezioni v2.0 DEMO (ITALIAN)
SpaTra06.lha         misc/misc   32K+Spanish Translations Pack 06 v0.10
Totogol.lha          misc/misc  132K+Totogol v3.6 DEMO (ITALIAN)
TotoSei.lha          misc/misc   61K+TotoSei v1.0 DEMO (ITALIAN)
lns22_peasants.lha   mods/techn 169K+British peasants - minimalism
lns23_cranium.lha    mods/techn 247K+My cranium is gone - minimalism
lns13_childe.lha     mods/tranc 281K+Children of the sun - softtrance
lns14_black.lha      mods/tranc 152K+The black death - softtrance
lns15_stack.lha      mods/tranc 296K+Smoke stack - hardtrance
lns16_desert.lha     mods/tranc 211K+Desert hero - hardtrance
lns17_light.lha      mods/tranc 346K+Let there be light - hardtrance
lns18_netto.lha      mods/tranc 405K+Nude in netto - hardtrance
lns19_pressure.lha   mods/tranc 235K+Endangered by pressure - acid+goa
lns20_secret.lha     mods/tranc 181K+Secret world - softtrance
lns21_Ra.lha         mods/tranc 188K+The eye of Ra - softtrance
lns24_coin.lha       mods/tranc 515K+Co-incidence - softtrance remix
lns25_tmt.lha        mods/tranc  31K+The morning trip - goa
bp_melt.lha          mods/wmr   553K+IMM: "Melt" by balistic/DiSC
ds-above.lha         mods/wmr   386K+IMM: "Above the Clouds" by Dawnstar
Sub.lha              pix/anim   844K+Sub anim with sonar sound in IFF-SoundAN
MODiskIcons12.lha    pix/icon   104K+Icons for 3.5" Magneto-Optical disks

From:    "Colin-Stewart Bridge Deady" <csbdeady@mythicz.u-net.com>
Date:    29 Mar 99 23:33:47 +0000
Subject: Summary 13
To:      kosh-general@kosh.net

This is a MIME encoded multipart message. The fact that you are reading
this means you don't have a MIME capable mail program. You might still
be able to read part of the mail's content, but some of it may require
a MIME capable mail reader to decode. Following are some URLs where
you can find MIME-capable mail programs for common platforms:

  Amiga............: MicroDot-II  http://www.vapor.com/
  Unix.............: Metamail     ftp://ftp.bellcore.com/nsb/
  Windows/Macintosh: Eudora       http://www.qualcomm.com/

General info about MIME can be found at:

  http://www.cis.ohio-state.edu/hypertext/faq/usenet/mail/mime-faq/top.html

--=_=8<==MD237000DDB-2E5C69D0==8<=_=
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all

Summary 13 enclosed. Many thanks to Robert Wise and John Chandler who
helped out with writing it.

It's a long one - a very long one - and I decided to keep John's
excellent contribution in a separate file to reduce the size of the
main file - although admittedly this is a larger_than_average summary.

If we get this many contributions to the general mailing list in the
future I will need help summarising the ML on a regular basis -
alternatively -please- take a lot of topics to the appropriate other
lists as I can't summarise them for lack of time.

Regards
-Bridge


--
http://www.mythicz.u-net.com | csbdeady@mythicz.u-net.com
ICQ:29145054 | DT-MUD:sunsite.auc.dk:4242
Amigan | Vegan | KOSHan Go for a swim in the object sea,
http://www.kosh.net | Storm of the Eye GUI-PBEM http://www.2bp.com/

--=_=8<==MD237000DDB-2E5C69D0==8<=_=
Content-Type: text/plain; charset=us-ascii; name="ksum13.txt"
Content-Transfer-Encoding: plain (7/8 bit)
Content-Disposition: attachment; filename="ksum13.txt"
X-MD2-FilePath: Work:mythicz/ksum13.txt

KOSH [Kommunity Orientated Software Hardware]

Weekly Summary

Week Commencing: 20th March 1999

Number: 013

Mailing List: kosh-general

In the mailing list this week, the following items were discussed. Please do
not email the scribe regarding any of these topics, it is not his job to answer
these questions but merely to report  the topics of conversation. If you have
any queries about this summary, please email ben@kosh.net, stating the Summary
Number, and Mailing List Name, and he will try to answer your queries.

The Summary this week was completed jointly by myself, Bridge Deady, Robert
Wise and John Chandler. I have incorporated Robert's sections into the main
summary but I have enclosed John's separately to allow for different
pagination.

a)

Subject: Keyboard mapping

Summary of debate: An idea posted is that it would be useful if you could swap
                   keys of the keyboard in software. For example, if you wanted
                   to replace "x" with "y" you would just run the appropriate
                   mini application, specify the keys to swap and choose OK.
                   This would allow people who would like keys to be mapped
                   slightly differently to be able to accomplish this.

                   It was further suggested that this could later be
                   implemented in hardware by allowing physical hotswapping of
                   keys on a keyboard. Does USB have the bandwidth and features
                   to enable this?

                   Each key could have the character it represents embedded in
                   it, interfacing through a quick-connect/disconnect plug. An
                   advantage of this is that if a key stopped working you could
                   just buy a new key rather than a new keyboard. If you needed
                   more space for a larger alphabet you could just clip on a
                   new section to the board and populate it with your chosen
                   keys. Perhaps this interfacing could be achieved with PIC
                   chips cut down to size?

                   It was pointed out that this is all part of a larger picture
                   about the ability to input into a computer in a native
                   language. To this end it would be nice to get involvement
                   from people in Asia in KOSH. The system should support many
                   languages as standard (presumably via language objects).

                   Keyboards could be handled via a keyboard driver object. The
                   actual keyboard can be anything the user wants to use. A
                   stream of input messages come from the keyboard which could
                   be unicode characters or special events (eg: Help key)/ If
                   its a smart keyboard (like USB) it will automatically start
                   the correct driver.

                   Suggested that a lot of what has been said could be
                   accomplished by a configurable touch screen although it
                   would lack tactile feedback. Tactile feedback could possibly
                   be handled via a gell that becomes progressively harder as
                   an electric field is applied to it - at the points where it
                   is pressed.


                   Different keyboard input objects based on Unicode could
                   handle any input required. Alternatively have an intermediate
                   object between the keyboard input object and the input
                   handler object, which may translate.

                   The Dworak keyboard that maps the most used keys closest to
                   where one has ones fingers was mentioned.

                   Could each key have a LED like the one on the Amiga Caps
                   Lock key?




b)

Subject: Cooling KOSH (was Waterproofing KOSH)

Summary of debate: Perhaps by using conductive fluid pipes in the computer one
                   could cool it.

                   Another idea would be to have slots on top of the machine
                   (not the side where they currently are), but this would take
                   us back to the first problem - coffee spills and dust.
                   Therefore the slits could be at the top edges of the case
                   facing out of either side with a slight V-shape in the
                   inside top of the case directing hot air that rises to these
                   outlets. Any foreign bodies entering these outlets could be
                   made to fall down channels in the inner side of the machine
                   and hopefully not enter the fragile innards.


c)

Subject: Chunky pixel and bit plane graphics modes

Summary of debate: When we get around to designing KOSH graphics cards can we
                   try to use the advantages of both systems mentioned above?

                   By connecting the vsync signal from the graphics card to a
                   hardware interrupt pin on the CPU we can make real-time
                   window dragging look smooth and fluid.

                   KOSH should use the inbuilt interrupt feature of many
                   graphics cards to accomplish this.

                   KOSH graphics cards could contain some form of copper, maybe
                   a more advanced version that allows 2D operation (which
                   would speed up the GUI).

                   Further questions raised: do we want a graphics card at all
                   when instead we could use a modular design, keeping the RAM,
                   DAC and custom chips as separate, scalable and optional
                   modules?

                   Do we want shared memory for graphics, data and sound like
                   the Amiga's chip RAM?



d)

Subject: Memory protection

Summary of debate: Would it be possible with today's memory management units to
                   protect private members of a single object?

                   Dave Haynie has previously suggested a system using flexible
                   context objects, which can live in at least four different
                   protection levels (app, global, object, and system).

                   Only if you wanted to devote a large chunk of memory to each
                   such object. An MMU, for good reason, works in page-sized
                   increments.

                   Could there be a standard way to lock an object in memory
                   for reading and writing to prevent another task or person
                   from changing the object that is curently being used?

                   Only if you wanted to devote a large chunk of memory to each
                   such object. An MMU works in page-sized increments.

                   However from the Amiga we can see that a system can be
                   stable without protection - it also shows where protection
                   is needed.

                   Only write-protection is needed to avoid having
                   applications trash each other's memory. However security
                   reasons would mean that you may not want someone to scan all
                   your documents and therefore read-protection is also needed.

                   What mechanism might exist to identify methods that a given
                   object understands? How would it be possible to tell that a
                   particular subclass of text object manipulator understands
                   font styles or not, or some similar thing? Not necessarily
                   determining whether it responds to a specific method, but
                   whether it has an equivalent method.

                   To physically protect objects from being altered by
                   malfunctioning classes each object could have its own memory
                   space. Knowing when to protect the object is as important as
                   actually protecting it.


e)

Subject: Book recommendations

Summary of debate: Booch's book about Object Oriented Analysis and Design,
                   (Grady Booch. 0-8053-5340-2) comes recommended.
                   Also recommended is Software Inspection by Gilb and
                   Graham (0-201-19246-2, 0-201-63181-4), which gives good
                   ideas about how to increase the quality of software.

                   Scribe's note: Books are summarised on the kosh booklist
                   website - see a previous summary for the URL.



f)

Subject: KOSH training

Summary of debate: Many people involved with KOSH may not that well versed in
                   the technology behind the proposals. Mario Saitti is willing
                   to help set up a system for KOSH to teach structured
                   programming methodology/Data Structures/SSADM/computational
                   to anyone interested.

                   Suggested that we should be thinking about teaching OO, not
                   structured programming. Structure programming doesn't really
                   go well with the object sea.

                   OO Design could also be a very valuable skill for all KOSH
                   members.

                   Could such training "courses" actually be devised?
                   Supplementing such training with books was recommended.


g)

Subject: Against hosted

Summary of debate: One scribe-e pointed out that they are against running hosted
                   versions of KOSH. Their reasoning is that there may be little
                   point in redefining computing to use modern methodology if we
                   put it atop of a base that is at least 20 years old. While
                   ensuring market compatibility is the compromise worth it?


h)

Subject: Why there should be an Object Sea

Summary of debate: One scribe-e pointed out they currently view the object sea
                   as just a set of descriptors and protocols made up of sub
                   classes which determine how the system will handle the
                   object.

                   The advantages of this approach include the fact that it
                   promotes really serious, heavy use of code reuse and
                   polymorphism. Together, these can lead to both better
                   performance and far more reliable code. It is then easy to
                   add behaviours to the system.

                   why is there a need for a frozen form?

                   A datatype still needs to open the JPEG file, close it later,
                   perhaps committing or forgetting edits at the same point.


i)

Subject: COMAL, REBOL, JIT & Basic KOSH

Summary of debate: Should KOSH come with a BASIC-like interpreted language?

                   A COMAL interpreter included with KOSH as standard was also
                   suggested. COMAL is very widely supported.

                   How about REBOL which is a messaging based interpretive
                   language currently going towards version 2.0 and developed
                   by Carl Sassenrath? See: http://www.rebol.com <=Some like
                   REBOL, others are less impressed.

                   Why bother with an interpreted language when with KOSH we
                   are thinking of the possibility of programs compiling at
                   either install or run time from a slim binary type of
                   format? How about a JIT compiled language as we would not
                   lose significantly in time that way?

                   Suggested is making a computer language that is more like
                   the equations that scientists and people in general have
                   been using all their life. Pointed out that we may not want
                   to create a new language. Mentioned that instead of a
                   compiled language one that halts and hilighted errors would
                   be good.

                   The standard compiler shipped with KOSH could be simple with
                   a more advanced highly optimised version available for
                   purchase.

                   In regard to OO rather than structured programming, see
                   Farenheit at http://www.sgi.com for some of the newest
                   declarative systems.


j)

Subject: CORBA links

Summary of debate: See:
                   http://www.corba.org ? Try searching for papers and AOOC.
                   http://www.cetus-links.org/ have some links that might be of
                   interest.

                   Also see: http://www.omg.org (or something similar) - the
                   parent organization is something like "Open Management
                   Group".




k)

Subject: Structured design methodology

Summary of debate: Suggested that we could all write a few lines on structured
                   design methodology and someone could summarize it for the
                   glossary.


l)

Subject: Accessing KOSH (continued)

Summary of debate: A completely aural interface for the system could be very
                   useful for those who are completely blind.

                   However this could have disadvantages such as if the
                   interface was left turned on next to a radio. Perhaps
                   preface commands to the computer with another word (aka Star
                   Trek).

                   Any audio control should be able to understand conceptual
                   terms - most likely via some AI.

                   A true 2-colour screen could be useful for someone who is
                   colourblind.

                   Avoiding colour clash (a form of colour blindness) when
                   certain colours are placed on other colours should be
                   paramount in KOSH.

                   Braille keyboards and a Braille screen were further
                   suggested.

                   Circular radar like pulses going to a mouse pointer when you
                   press a shortcut key could be used to help keep track of the
                   pointer.

                   The Amiga and Mac ability to flash the screen when there is
                   an error as well as provide a beep should be included.

                   We should also look at alternatives to keyboard + mouse
                   including joystick control amongst many possibilities.

                   Mario Saitti has suggested that issues like these would need
                   an entire working group of their own.



m)

Subject: DLL's

Summary of debate: Was mentioned by a number of people that we should stay away
                   from a system similar to Windows DLL files as these can
                   create severe problems when things go wrong.


n)

Subject: Garbage collection

Summary of debate: Garbage collection from LISP could be used. Object Seas
                   based on their existence are suggested as the way to go.


o)

Subject: Localised languages

Summary of debate: Locale on AmigaOS allowed easy adaptation to many languages.
                   By incorporating this in some form into KOSH the system as a
                   whole becomes even more inclusive.

                   To fully internationalise KOSH it was suggested that a
                   mixture of languages should be useable at once. An example
                   given was Swedish in a wordprocessor but something else in
                   the other applications.

                   KOSH from the ground up should be designed to be flexible
                   and powerful in respect to language implementation including
                   Kanji which appears to be very complex.


p)

Subject: Punch cards

Summary of debate: KOSH should support punch cards as there is a lot of data
                   stored on them which is currently difficult to access.

                   It was pointed out that this could be achieved by placing
                   the punch card in a scanner and then interpreting the
                   resulting picture.


q)

Subject: KOSH-OO-help ML

Summary of debate: A mailing list with the above title was suggested by John
                   Gustafsson so him, Dave and others can post a mail now and
                   then about something about OO and those interested could
                   talk about it.


r)

Subject: Get together

Summary of debate: Suggested we should all get together to celebrate the
                   release of KOSH 1.0 when it is out. Joel Newkirk wants to
                   know if we want to go to a party at his place? Such an
                   opportunity will give us all a chance to meet each other.
                   Dave Haynie then goes and invites us all to his place for a
                   Summer party in the year 2000 - what a nice gesture!. Mario
                   Saitti then makes further offers around the theme of a get
                   together.

                   Oh and ideas for the place to celebrate KOSH 2.0 are coming
                   in now as well:P


s)

Subject: Hardware Procurement WG

Summary of debate: Joel Newkirk suggests the above working group to establish
                   means of procuring hardware for testing, kommunity needs,
                   individual purposes, etc at the lowest available prices.
                   Maybe establish a specific physical/legal base in the state
                   of Delaware, which is conveniently free of sales tax, yet in
                   a convenient location at the heart of the US East Coast
                   Metro-Belt.


t)

Subject: Users as objects

Summary of debate: Suggested that we could tread users as objects or a set of
                   objects, with permissions for various things and levels
                   being objects or object-related as well.

u)

Subject: Multiuser systems

Summary of debate: Mentioned that would we need a multiuser system? With KOSH
                   being designed so that it is fast, easy and fun to use
                   rather than a mainframe OS with terminals and users perhaps
                   multiuser is unnecessary.

                   However multiuser systems may be a must for any connected
                   computer. File sharing would be hard and inefficient without
                   a multiuser system.

                   The multiuser model could be defined and then set the single
                   user model as the degenerate case.

                   By being able to boot the system into a configuration mode
                   that is free of user context software and hardware could be
                   easily added globally.

                   Data, applications and hardware could all be user-specific
                   (with the ability to add other users) or global in their
                   availability. Therefore we could have just one KOSH
                   distribution with many different levels of users. Sharing
                   like this could also be done over a network.

                   If every KOSH machine is fully multi-user it would mean that
                   identifying oneself to any machine would allow access to all
                   of that users resources and settings. Suggested that KOSH
                   should see multiuser as adding "personal" resources and
                   access privileges to the generic system.


v)

Subject: Resolving handles

Summary of debate:  Resolving handles and finding methods/interfaces is likely
                    to take at least some processor time. Suggested these
                    things could be cached.

                    Further suggested is that we could have some objects built
                    at install time and updated at runtime if applicable, to
                    handle the resolving, on the machine the application or
                    object's installed on. The OS then wouldn't have to do a
                    new complete resolve each time the object were to be
                    invoked.


w)

Subject: KOSH Vocabulary WG

Summary of debate: Ruward F. Leenstra has suggested that it is time to create
                   the above named working group. As this will help with
                   reading Dave's paper on the Object Sea by defining and
                   explaining the terms contained within it.

                   A lot of interest was shown in this idea.


x)

Subject: KOSH FAQ

Summary of debate: Suggested that for subjects covered by KOSH mailing lists we
                   could have a frequently asked questions section of the web
                   site.


y)

Subject: Object synchronization

Summary of debate: One of the concepts arising in the discussions is the ability
                   to synchronize object by transferring the events (methods)
                   from one system to another. If the objects in question are
                   identical then no problem exists. If they are different, but
                   significantly similar then the same effect could be achieved,
                   in a limited fashion. The question is how can we determine
                   what methods a given object will respond to, and if those
                   methods are globally standard or intrinsic to that object?

                   By looking at the objects class hierarchy, the class
                   definition will determine the methods an object will
                   understand.

                   Suggested that we let the object manager be responsible for
                   almost everything related to this.  Instead of calling an
                   object directly or using an object that pre-exists, we could
                   call the object manager to rebuild an appropriate object. All
                   calls to the object manager should be abstract under this.

                   Object Synchrony developed as an approach where two compatible
                   objects on different systems are synchronized by duplicating
                   the events therein or methods sent thereto between 2+ objects.

z)

Subject: Alternatives to the monitor

Summary of debate: Audio cues discussed in depth. They have advantages over
                   simply enlarging the text on screen, although having the
                   ability to work split at the OS level (not just in
                   applications) with one half at 100% magnification and the
                   other at anything you choose would be neat.

                   See http://www.cast.org - Center for Applied Special
                   Technology. Part of their purpose is to expand the
                   accessibility of computers. Their Blobby tool at
                   http://www.cast.org/blobby is very useful to check web pages
                   for accessibility.

                   Suggested KOSH could contact relevant organisations (eg:
                   Royal Society for the Blind in the UK) and tell them that we
                   are interested in getting opinions of our ideas from
                   experts in the field, and that we are eager to try to
                   incorporate capabilities they can show to be helpful.

                   It was stated by someone who is visually impaired that a
                   windowing system is useless for the blind and if you are
                   otherwise visually impaired such a system is poor.


1a)

Subject: Window shapes

Summary of debate: At the moment almost all windows are rectangular. If KOSH
                   implemented a form of masks from the outset the windows
                   could be any shape desired.


1b)

Subject: VB Problems

Summary of debate: See the following re Visual Basic and problems with it:
http://www.vb-zone.com/upload/free/features/vbpj/1999/mckinney/mckinney1.asp#1


1c)

Subject: Mouse movement

Summary of debate: The mouse pointer in KOSH must not be jerky, it must be
                   completely fluent.


1d)

Subject: More mouse control

Summary of debate: A small trackball under the finger on top of a mouse could
                   be used in addition to the mouse itself for panning and
                   zooming etc.

                   How about a horizontal wheel as well as the vertical one.

                   Mice that sense rotation were suggested.

                   Pointed out that if the drivers were written better the
                   support for the mouse could be automatic without an
                   application exactly having to support it.

                   A trackball or a trackpad in the center of a split keyboard
                   was suggested as an alternative.


1e)

Subject: Cartesian Coordinates

Summary of debate: Cartesian Coordinates were suggested to be used with the
                   Object Sea as 2D and 3D objects. However they can be
                   difficult to deal with a lot of non-rectilinear objects and
                   waveforms.


1f)

Subject: Alternative caching method

Summary of debate: Could we create a new 'protected' directory object that is
                   accessible only to the parent task and appears and
                   disapears along with it? This could be useable to get
                   around a new EU ruling that caching is against copyright
                   law.


1g)

Subject: Mutual NDA

Summary of debate: To protect KOSH work and the work of individuals involved it
                   may be necessary at some stage in the future to use mutual
                   non disclosure acts in some areas of the Kommunity - namely
                   in certain Working Groups set up for certain reasons. Anyone
                   could have access to this but they would have to sign a
                   mutual NDA with KOSH, Inc. to gain access.


1h)

Subject: High Performance Computing Users (HPCU) Group Annual Conference

Summary of debate: See: http://www.hpcu.org re the above, or the email posted
                   by Giorgio Gomelsky (gio1@interport.net) on the 26th March
                   entitled "Fwd: Computers/computation/standards" which is a
                   forwarded message calling for computer papers on an array of
                   topics.


1i)

Subject:  Using a new object model rather than an existing one.

Summary of Debate:  Several features were proposed for the KOSH object
                    model which do not exist in current object models
                    (specifically C++'s.)  One of these features is
                    method transparency/translucence.  Using this
                    feature it is possible to create a transparent/
                    translucent container class which receives methods
                    and passes those methods along to the objects the
                    class contains.  Method transparency/translucence
                    can be utilized by an object to "broadcast" a
                    method to many recieving objects.  There was some
                    concern that this would be wasteful, in that during
                    a broadcast many objects could receive methods they
                    do not implement, and be forced to ignore those
                    methods.  Used appropriately, however, the ability
                    to "broadcast" methods would be a powerful tool.
                    An example of a translucent container would be a
                    generic-disc-object-container.  This would be a
                    container class that held all the information
                    necessary to store an object that exists in memory
                    on the disc.  The advantage of this is that while
                    the object is in memory it is not burdened with the
                    information about how it is stored on disc, and the
                    information about how to store an object on disc
                    can be implemented once, rather than over and over
                    again for each class.

                    Another feature proposed for the KOSH object model
                    was bidirectional polymorphism.  Here methods can
                    be sent to a class which does not implement those
                    methods but may implement them at some point in the
                    future.


1j)

Subject:  "Model-View-Controller" GUI Implementations

Summary of Debate:  Under this common method for GUI implementation
                    each GUI component is broken into three pieces.
                    The Model consists of the logical representation of
                    the component, the View consists of the visible
                    representation of the component, and the Controller
                    consists of mechanisms to which the component
                    responds.  This model originated in Smalltalk and
                    is used in QNX and in modified form in Java
                    JFC (SWING)


1k)

Subject:  Polymorphism

Summary of Debate:  Polymorphism was described as a subclass being
                    functionally the same class as it's parent class.
                    It was noted that this would be useful when
                    attempting to synchronize heterogenous objects.  As
                    long as the objects shared a common ancestry they
                    would have a set of common methods.  C++ uses
                    "pure virtual methods" in it's handling of
                    polymorphism, which are methods that are left
                    unimplemented in a parent class and must be
                    implemented in all subclasses of the parent.


1l)

Subject:  Object Links

Summary of Debate:  Anyone wanting to read more about object
                    orientation should check out the following:
                    Very Introductory Stuff
                    http://www.soft-design.com/softinfo/objects.html
                    Smalltalk ("Squeak" is a popular free subset
                    implementation)
                    http://www2.ncsu.edu/eos/info/ece480_info/project/
                        spring96/proj63/www/index.html
                    http://squeak.cs.uiuc.edu/
                    http://www.ddj.com/articles/1999/9901/9901k/
                        9901k.htm (funny)
                    http://www.stic.org/

                    Eiffel
                    http://www.eiffel.com/doc/manuals/language/intro/
                        page.html

                    Java
                    http://128.95.4.112/homes/gjb/doc/java-lang/
                        index.htm
                    http://www.javasoft.com/docs/books/tutorial/
                    http://www.javasoft.com/beans/docs/spec.html


--=_=8<==MD237000DDB-2E5C69D0==8<=_=
Content-Type: text/plain; charset=us-ascii; name="Ksum13a.txt"
Content-Transfer-Encoding: plain (7/8 bit)
Content-Disposition: attachment; filename="Ksum13a.txt"
X-MD2-FilePath: Work:mythicz/Ksum13a.txt

Object Technology & Resources Summary

** Efficiency, Flexibility & Classes

The discussion mentioned the trade-offs required to balance efficiency and flexibility. Concerns about
making unnecessary calls to objects which may not implement a specified method was countered with the
fact that broadcasting requests can often be more efficient than implementing suitability tests.

It was also pointed out that it is better to build an object in runtime from appropriate classes using
predefined methods. An 'upgrade flag' would be present in the system: objects could be 'frozen' to assist
with performance, but re-built by the object manager during each upgrade. Classes unable to fulfil a
functional requirement are ignored - this leaves a missing function, but is highly unlikely to cause
anything to fail.

Properties of objects shouldn't be restricted in general - UI characteristics, for example, could
legitimately be inherited by 'non-UI' objects in order to, say, provide display and user-interaction
parameters. Developing hybrid weirdity (great term!) is another reason for being able to want methods
mutating, but without the object code changing. A functional flow interface with user interaction provides
an example of this: streaming data and live interaction with adaption being performed - methods adapting
to the quality and quantity of data to change the visualisation. Dynamic artwork is also mentioned, as is
being able to change colour representation or whatever. To quote Paula Lieberman:

	"let's add some purple dye up there at time N, and at time N+1 change the dye to yellow, and
	when I press the Escape key, make it violent chartreuse with an A minor chord on a organ sample
	at fff....."

In essence, you need to be able to ensure the flexibility is there to cope with the things we didn't
originally anticipate. [John's note: truly creative stuff comes from really bending things totally out of
shape - if you can't do that, creativity is limited]. The needs of users can often be different from the needs
of programmers, which suggests we must make it easy for developers to create the software the users
want, and not their own 'toy pet'.

** Selfmodifying Code

Comments on selfmodifying code spawned some interesting points. Experience of LISP has given a sour
opinion of selfmodifying code to many, and it is indeed a bad idea in most cases (selfmodifying code, that
is - not LISP!). Modern computers, with varying cache capabilities, can easily have performance
degraded by selfmodifying code. Well, if you do it wrongly it can - but if you do it right it can improve
things quite considerably. [John's note: compare to the issue of 'goto' - while a bad thing for almost all
situations, it does have its uses when handled properly].

The cache problem can be handled sufficiently by flushing the first level cache. However, as cache sizes
get bigger and more processors are added you have more caches to flush. The Intel Merced, for example,
will probably have an 8 MB cache, and be present in multiple-CPU configurations.

Furthermore, it's important not to get confused about what selfmodifying code is:  it's code directly
changed during execution. However, if this code is actually rewritten to cover different cases as multiple
sections of code accessed through conditional branching you can develop alternatives for most uses of
selfmodification without cache problems and the like which can degrade performance. Of course, you
could create versions of functions/methods for a given system and just swap a pointer to direct code to the
right method - selfmodification would then only occur at the moment code is first loaded up. It was
mentioned that selfmodification should even be physically forbidden through techniques such as write-
protection of memory.

Are some of us trying to out-optimise modern optimising compilers by any means necessary? Apart from
keeping code compact (not really much of a necessity these days and still achievable through other means)
selfmodification can be replaced by more considered, structured programming approaches.

** Structured Programming

Ah, structured programming... In particular, criticism about universities and other institutions
(particularly in the west) not placing enough emphasis on structured design and programming techniques.
[John's note: Oxford Brookes University, UK taught me structured programming and design with great
emphasis, so not all universities are bad].

Good languages mentioned for teaching structured programming included Pascal and Modula-2 (praise to
Wirth!) as well as Java, while C and C++ came under fire for being unnecessarily complex,
unstructured and unfriendly. C++ has also helped destroy some companies, apparently! [John's note:
Sounds like C++ and ISO 9000 are related...]


--=_=8<==MD236FCC7A3-1EFDE8CC==8<=_=--

--=_=8<==MD237000DDB-2E5C69D0==8<=_=--
(end of MIME multipart message)