kls@halas.UUCP (Karl Swartz) (09/02/90)
... and as far as I know this is the first message in the pc532 mailing list has been written on and sent by a pc532! Thursday night (and Friday morning) Dave and George helped me load up Minix -- it's quite nice having an ICM handy to format the disk and get the minimal system onto the disk. A few hours of downloading from George's PC got the rest of the system onto my disk whereupon I went home, walked Alex (canine type roommate), and then tinkered until the sky was starting to lighten. The installation certainly has some rough edges, but I plan to write up some notes to add to Bruce's in the next few days. And the system itself certainly has some bugs (watch for mail, Bruce) but considering its tender young age it's been remarkably solid. Great job, Bruce! With a fair amount of debugging halas is now running uucp reliably (albeit not very fast), and also has smail 2.5 and a few other bits and pieces loaded up to make mail function. Dave has mentioned he is always thinking in terms of uucp; to me a machine isn't real until I can send mail to/from it. Next project will likely be jove; MicroEmacs is certainly better than vi but I badly need a list of commands and just generally prefer jove these days. More after I wake up ... -- Karl Swartz |UUCP uunet!apple!zygot!ditka!kls 1-408/223-1308 |INet zygot!ditka!kls@apple.com "I never let my schooling get in |BIX kswartz the way of my education."(Twain) |Snail 1738 Deer Creek Ct., San Jose CA 95148
news@daver.bungi.com (09/03/90)
> ... and as far as I know this is the first message in the pc532 > mailing list has been written on and sent by a pc532! Fantastic !!! [stuff deleted] > With a fair amount of debugging halas is now running uucp reliably > (albeit not very fast), and also has smail 2.5 and a few other bits > and pieces loaded up to make mail function. Dave has mentioned he > is always thinking in terms of uucp; to me a machine isn't real > until I can send mail to/from it. Are you using the Minix uucp posted to comp.os.minix a while back ? > Next project will likely be jove; MicroEmacs is certainly better > than vi but I badly need a list of commands and just generally > prefer jove these days. One thought, you might want to wait for version 1.5.10 before you do any serious code porting. Makeing adjustments for version 1.3 /usr/include is can be a real pain, and will have to be undone for version 1.5.10. Version 1.5.10 ANSI / POSIX compatibility makes porting relatively easy. I think you will be delighted with version 1.5.10. In all respects it is a substantial improvement over 1.3: o Generally behaves as expected o Much faster, block io uses an io_vector, o tty driver is faster and handles binary data properly (eg. zmodem works). o etc, etc, etc. Also, I highly recommend that you tryout 'shh', shell with history, that was posted awhile back -- really makes the command line humane. 'shh' is a cdiff to 'sh. I there is an interest I could post this as well as a minix system / termcap interface for microEmacs. Best regards, johnc --
kls@ditka.UUCP (Karl Swartz) (09/03/90)
> Are you using the Minix uucp posted to comp.os.minix a while back ? I don't know. At the time I wasn't following comp.os.minix and didn't hear about the uucp until the article(s) had expired. I grabbed it via ftp from nodak.edu; the comments in uucico.c say it was ported to Minix by Peter S. Housel and later mods were done by F. van Kempen. Does it sound like the same beast? > One thought, you might want to wait for version 1.5.10 before you > do any serious code porting. Makeing adjustments for version 1.3 > /usr/include is can be a real pain, and will have to be undone > for version 1.5.10. Version 1.5.10 ANSI / POSIX compatibility > makes porting relatively easy. So far I haven't run into any serious difficulties in this regard. I spent a lot of time figuring out that the kernel was silently tossing my NULs into the abyss, then spent a lot more time trying to figure out why transfers to Minix would die after about 12KB. Still haven't nailed that one but telling uucico to request a window size of 1 rather than 3 provided a workaround, albeit with a massive performance penalty. The behavior suggests poor error recovery by the uucico implementation, perhaps compounded by problems with tty system. (Several other issues also smell like tty problems; this may be a weak spot at the moment.) I also had a problem with the following: static char *tempname = "/tmp/fooXXXXXX"; ... mktemp(tempname); GCC makes the string in read-only, which led to a "bus error". When I changed the declaration to static char tempname[] = "/tmp/fooXXXXXX"; everybody was happy. Other than this, having GCC and its libraries is perhaps a big step towards making 1.3 easier to deal with. Jove has been balky, but I expected this based on experience with other systems. The big chore here is figuring out what config options you should be using -- and finding all the files that define them. There are at least 4 files that have options, and the documentation doesn't point you to all of them. There are also a fair number of outright bugs which GCC justifiably gets indignant about. One big hole is tty ioctls -- few are present on this version of Minix, which has required a bit of work. > I think you will be delighted with version 1.5.10. In all respects it > is a substantial improvement over 1.3: Keep in mind that much of Bruce's code is 1.5 already. As I recall only one major piece is still at 1.3. > o Much faster, block io uses an io_vector, Interrupts? It sure needs to use 'em. > o tty driver is faster and handles binary data properly > (eg. zmodem works). Performance seems reasonable (of course throwing horsepower at the problem can't hurt!) and binary data has been working fine since I took care of the NUL disposer. > Also, I highly recommend that you tryout 'shh', shell with history Sounds nice, though right now a better editor is my first priority. Not that MicroEmacs is bad; jove is just better. -- Karl Swartz |UUCP uunet!apple!zygot!ditka!kls 1-408/223-1308 |INet zygot!ditka!kls@apple.com "I never let my schooling get in |BIX kswartz the way of my education."(Twain) |Snail 1738 Deer Creek Ct., San Jose CA 95148
ian@sibyl.eleceng.ua.oz.au (09/04/90)
Karl Swartz writes: > I also had a problem with the following: > > static char *tempname = "/tmp/fooXXXXXX"; > ... > mktemp(tempname); > > GCC makes the string in read-only, which led to a "bus error". When I > changed the declaration to > > static char tempname[] = "/tmp/fooXXXXXX"; > > everybody was happy. Well, that is the "correct" declaration. You could have also used the "-fwritable-strings" option. Ian Dall
news@daver.bungi.com (09/04/90)
> > > Are you using the Minix uucp posted to comp.os.minix a while back ? > > I don't know. At the time I wasn't following comp.os.minix and didn't > hear about the uucp until the article(s) had expired. I grabbed it via > ftp from nodak.edu; the comments in uucico.c say it was ported to Minix > by Peter S. Housel and later mods were done by F. van Kempen. Does it > sound like the same beast? Yep. I did some searching of my Minix stuff and it appears that it was posted as three parts to comp.os.minix on 15 May 90 by Fred van Kempen. Apparently there have been no subsequent updates. Fred has also posted 'w-mail' and 'u-mail'. 'w-mail' is a simple local mail agent (ie. mail reader / sender linked to lmail, mail, etc). It was posted on 29 April 90 and was updated on 21 May 90. 'u-mail' is a remote mail transport agent (ie. linked to rmail). It was posted on 29 April 90 and has three updates dated 21 May 90, 16 June 90, and 23 June 90. > > I think you will be delighted with version 1.5.10. In all respects it > > is a substantial improvement over 1.3: > > Keep in mind that much of Bruce's code is 1.5 already. As I recall > only one major piece is still at 1.3. > > > o Much faster, block io uses an io_vector, > > Interrupts? It sure needs to use 'em. I am not sure what you mean. In version 1.5 the FS builds an array of block requests that can not be satisfied from the cache. It then passes to the block device drive that address of the array along with the number of elements in the array. The block driver then loops on the array of requests. In 1.3 each block is a separate message transaction. > Sounds nice, though right now a better editor is my first priority. > Not that MicroEmacs is bad; jove is just better. In the meantime this may help. Type 'META X' then 'describe-bindings' then save the resulting buffer for reference. If command completion is enabled "des <space-bar>" should do it. For some reason my image of Bruce's xemacs is corrupted, so I am not able to verify the above. However, it should work. Also you might try 'META ?' which should open up a help screen if it can located a file 'emacs.hlp'. Best regards, johnc --