saj@chinet.chi.il.us (Stephen Jacobs) (05/04/90)
Right off the bat: I'm not volunteering to manage this, and it REQUIRES a
manager, so the idea may be doomed.
There are a lot of questions of the form "How do I get the ST to do job X
in language Y". These are well answered with small example programs. It
gets messy to try to save all of these examples in any kind of organized
manner, and there's a tendency to forget whether a particular question has
already been answered. The answers are generally too small for reasonable
sources postings. It would be useful if someone were to collect and index
these little sources, solicit new ones, link the originals to corrections
and updates, and generally keep them available. Any offers? Better ideas?
What I will offer to do is contribute a few goodies of this type myself.
Steve J.gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) (05/05/90)
In article <1990May4.163735.9794@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: >Right off the bat: I'm not volunteering to manage this, and it REQUIRES a >manager, so the idea may be doomed. > >There are a lot of questions of the form "How do I get the ST to do job X >in language Y". These are well answered with small example programs. Yes, this would be an excellent way to spread documentation about the ST. How about one example for each BIOS, XBIOS, and GEMDOS call? A few complete AES/VDI-based programs? Examples that show how to read the right mouse button, use the VBI queue, work with GDOS. Any volunteers? >What I will offer to do is contribute a few goodies of this type myself. Ditto. "Perhaps I'm commenting a bit cynically, but I think I'm qualified to." - Dan Bernstein
jdb9608@ultb.isc.rit.edu (J.D. Beutel) (05/06/90)
>saj@chinet.chi.il.us (Stephen Jacobs) writes: >> >>There are a lot of questions of the form "How do I get the ST to do job X >>in language Y". These are well answered with small example programs. I agree this would be a wonderful thing. No, I can't do it. I don't own a site, nor have the storage, and I keep moving. I just wanted to say that I think that good indexing will be crucial to its usefulness. I can imagine stuff going in but never coming back out because users can't find what they're looking for--then it would be no better than the net now. I suggest that the manager of the archive will have to read each submission (I doubt there'd be more than one or two per day), anticipate its usefulness, and assign appropriate keywords. (This would be important and take some skill.) The new article number (or whatever naming scheme is used) and the keywords for that article can then be added together on one line to a global index file. Users can `ftp` the index file and then do a `grep '(key1)(key2)(key3)' index` kinda command to get just the files they want. E.g., `grep '(hirez)(vdi)' index | grep -n '(window)'` would list all the files related to vdi calls on monochrome systems which are not related to using windows. Okay, so it's not a very practical example, but you get the idea of the flexability and power once the indexing is done and the keywords are made available. Regularity of the index would be crucial, so using the supplied keywords would be unreliable. It doesn't have to be just source code either. I've seen some awfully useful little chunks of text floating by here that I was sure I'd want later, but knew I'd never be able to find again even if I tried to archive them. Of course, a server should be available to do the `grep` locally and return the results to those who only have mail capability. -- -- J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." Looking for co-op Sept..Feb in NN, OS, VR, or AI.
dav@eleazar.dartmouth.edu (William David Haas) (05/10/90)
saj@chinet.chi.il.us (Stephen Jacobs) writes: >There are a lot of questions of the form "How do I get the ST to do job X >in language Y". These are well answered with small example programs. It >gets messy to try to save all of these examples in any kind of organized >manner, and there's a tendency to forget whether a particular question has > ... Ok. I will volunteer. I don't have a lot of free time but I can dedicate a constant amount each week to it. What I expect to happen is I will get a lot of contributions and it will take a month or two to get the first version made. Then I will send a copy to each volunteer to review. After that I will post something once a month that will indicate where to find the file/files and how to use them. Here is what you should do: a) Ignore this message and wait a few months for this to come together or die a horrible death. b) Send me contributions. It can be as small as you want or as big as you want, C-code or text describing whatever. All submissions should be Public Domain or Free use if author's name remains in comments. I will not accept anything that is copywrited, shareware or has any 'catches' except for inclusion of the submitter's name. When you make your submission let me know if you want to be a reviewer of the document before it gets posted. I would like source code for working GEM programs even if you don't want the code itself posted. I would like some example GEM programs to play with. Simple or complex. When you send in stuff keep in mind I am a c-hacker by trade but I have a very limited knowledge of Atari internals. On another note. A few months ago I posted asking if there was any interest in a GCR mailing list. I recieved 1 reply. I am still willing to run one if I get enough people on the list. dav@dartmouth.edu