KOSH [Kommunity Orientated Software Hardware] Weekly Summary Week Commencing: 27th March 1999 Number: 014 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. a) Subject: Cymraeg, Gaelic, Cornish and other local languages Summary of debate: It would be inclusive and a positive step for the Kommunity of Koshans to include support for languages that are normally missed out in mainstream systems. This could be done via the KOSH localisation system. Suggested that we contact relevant local organisations sometime soon about this. There was (and still is??) an Amiga Translator's organisation. Perhaps we could contact them to see if they would do KOSH work too? - Does anyone have the contact details? Suggested contact is Gary Peake who was apparently in contact with them sometime earlier on this mailing list. b) Subject: Colour clash and dithering Summary of debate: It was noted that certain colours on certain coloured backgrounds (eg: red on blue, black on red) can be difficult to view by a large number of people. Further, dithering and patterns such as checks with text on top can also present difficulties. Therefore in KOSH documentation we should avoid such designs. It was also suggested that where possible we so not use dithering in KOSH as a whole, particularly as we are looking at supporting new fast 24bit+ graphics cards (admittedly AGA 256 colour dithering will be needed). All of this obviously only applies to full colour KOSH systems. c) Subject: KOSH documentation formats Summary of debate: It was asked what sort of documentation KOSHans would like. A printed manual or manuals would be liked as online documentation is often difficult to use at the same time as the software it refers to - both being on the same system. As well as this, online (HTML?) documentation that configures itself to represent the settings that the user has setup (as mentioned in a previous summary). d) Subject: Functional languages Summary of debate: It was suggested on the subject of what computer languages to use with KOSH that a functional language that includes complex computations could be used. However functional languages are not very straightforward as they often have bizarre syntax. e) Subject: Application generators Summary of debate: Traditionally application generators are always tailored for a specific type of application. However, as the UI in KOSH will have personalities the applications for it will not have to be constant. We could have a KOSH-Script builder with another layer on top that changes with the personality. An applications generator that produced KOSH scripts could come in different versions, each specialized for one type of work. f) Subject: More COMAL Summary of debate: See: http://www.macharsoft.demon.co.uk/unicomal/aboutcml.html Macharsoft produces unicomal, a current COMAL implementation which they claim incorporates OO concepts. NB: the whole site is dedicated to COMAL. g) Subject: Structured summaries Summary of debate: Marcus Peterson has gone through the summaries and restructured them according to categories instead of summary dates. Having both date and subject-based summary formats available will make locating particular information easier. h) Subject: Wider world survey Summary of debate: Greg Webb, greg@gpwebb.freeserve.co.uk would like help with conducting a survey of the wider world beyond us Koshans to see what the computer world at large would like in something like KOSH. If you can help (particularly but not exclusively if you have experience with statistical analysis) then please email Greg directly. i) Subject: KOSH programming and semicolons Summary of debate: It was pointed out that C brings up an error when it is missing a semicolon but then pinpoints the exact location that the semicolon should have been placed at. Therefore it was implied that KOSH should be able to automatically insert such characters. j) Subject: One KOSH programming language for all / A KOSHan beginners language Summary of debate: It was suggested that one global KOSH programming language could be designed (possibly based on existing languages) that was suitable for beginners to programming all the way up to experts in OOP and structured programming. An opinion was expressed against BASIC for something like this in that it can make structured programming difficult. However it was noted by another scribe-e that this may only apply to some versions of BASIC. Such a language could ship with KOSH and be used to encourage people to program. However this may only teach them how to program in the cosy well thought out world of KOSH which could limit their ability to program with other systems. Was suggested that the critical features and design decisions that must be made for a beginners language are: 1) Garbage collection - this may be too complex for a beginner. The language must support garbage collection. 2) No traditional C-style pointers thereby eliminating a possible memory leak, and making implementing garbage collection easier. 3) Run-time array bounds checking or unbounded arrays to protect against inaccurate writes to memory. It was mentioned that eliminating pointers eliminates a lot of power and convenience. It was noted that Java almost fits these criteria except that it doesn't actually support run-time bounds checking but uses a theorem prover instead. Suggested goals for a programming language for beginners are that the system should be protected from accidental damage, the language should be immediately effective with something visible after only a short amount of work and the language should help teach better habits, possibly by requiring the syntax to be commented although this latter suggestion may make the language wordy. A language for KOSH should aim to reduce the gap between having ideas and being able to implement them in a computer language. k) Subject: ISO Modula-2 compiler Summary of debate: Suggested that in the fullness of time we could look at created a ISO Modula-2 compiler for KOSH. l) Subject: Installing KOSH Summary of debate: Proposed that the KOSH v1 installation (on CD?) should include a setup routine to install a base version of Linux as well, with options available for a number of platforms. This would allow those who own platforms on which a hosted version of KOSH has yet to be written to use it, via the Linux hosted version. The complete install could be available as an FTP directory located somewhere. m) Subject: Terminology WG Summary of debate: Could anyone interested in joining the above named Working Group for KOSH please email Ruward F. Leenstra at uart@xs4all.nl n) Subject: Loading and coping with older versions of objects Summary of debate: The following questions were posed: what happens if you have have software which has a number of objects that contain data and when the next version is released, these objects have changed? How should this be handled? How would older versions of objects be loaded? Old versions should be loadable. It should be possible to just plug the old objects into the new handles or use an adaptor for this. o) Subject: Sharing computer experiences Summary of debate: A way to share experiences of the various computer systems that we all use (including Mac, BeOS, Amiga, Linux, Unix, BSD, NeXTStep, Windows, OS/2 and many others) could be useful. This could take the form of a large section on the web site available (to members only it was suggested) for downloading in parts that would contain emulators, trial versions and other relevant software to allow people to try other systems. The same area could also contain languages like COMAL and Delphi that people could try out. Jason Radford the administrator for the server that the KOSH web site is on agreed that some of the 4gig of drive space available for KOSH could be used for this purpose. He suggested that if enough interest and ideas came forward that ftp.kosh.net could be created. p) Subject: Case-insensitive KOSH Summary of debate: Suggested that throughout KOSH an Amiga-style system where case is stored but operations are case-insensitive is used. q) Subject: Standardized diagram construction package Summary of debate: It was suggested that we try to find a standardized package to construct diagrams for KOSH. A set of brushes that could be used would be useful. r) Subject: Executive Scheduler Summary of debate: KOSH could implement a scheduler similar to the Amiga's scheduler. Further suggested that this should be a separate object. The basic system could ship with a scheduler that does the basic round-robin scheduling.