Hyperion announces OS 3.1 update

[Oldsmobile_Mike]

We got "Ed" fixed up. This is really a pretty screwy program - probably because it came from BCPL and was "translated automatically to C". Or at least, the code looks like that. Good part: Ed can now run in the same shell window it was called from, and can be run over "AUX:", i.e. a serial connection.

So, all the usual: Bug fixes, and lots of work.

Nice!  Looking forward to seeing which of these programs I can "hack" to work under my existing 3.9 installs.  Maybe someone should write a guide.  

Would be nice if PFS3 was made the default file system, but I can't really see such a "radical change" being adopted by the community as a whole.  :lol:

[guest11527]

This CDFS has nothing to do with old L:CDFileSystem (aka cdfs.library 40.11), which be gone?

It probably has, yes, though that was a long time ago. CDFS was updated originally by Jörg Strohmeier, then by Sebastian Bauer, all for Os 4.0 and later, so the Os 4 version is at 52.4 or so. The backport beta (or rather, alpha) we have right now is again 45.1, so version numbers are certainly a bit backwards. Adding the "auto-boot" capabilitiy of the cdfs.library is by that in principle possible, though this mounts hardcoded on the "scsi.device" and not every Amiga has it. Besides, the ROM is full anyhow.

There have been some queue-handler replacements around too, don't know if you know about them? One is versioned 50.something, so I wonder if maybe it comes from OS4.0 or OS4.1 for classic.

Queue-Handler is new from scratch, no relation to the old code (which was just broken) nor any other new code. The problem with all the replacements (and the old code) was that it didn't work right with the new shell pipe support.

In particular, the following is an interesting race condition one had to fix: If you have a long directory listing (say) going and pipe that to "more", such as

Code: [Select]

list all | more

and then abort "more" with ^C, then you somehow need to take care of to interrupt "list" as well. None of the pipe handlers I found did that right. Also, you somehow need to tell commands that cannot read from "stdin" to read from the pipe. The "hack-me-up" approach of the "C:Pipe" command you find in aminet is to do second-level parsing, which is a dangerous thing to do with the weird shell syntax, so that approach is long gone. Pipes are intrinsic in the shell. Now, instead, you can now (with the new pipe handler) use the unnamed Pipe to do just the same:

Code: [Select]

list all | type hex PIPE:
will give you the directory output in hex. For whatever this should be good for, but... we have it. Also "Sort" can be run on a pipe, and "Dir" reformats its output according to the shell window size.

So, all tiny tiny improvements here and there. There is no "big new thing" that will come with 3.1.4. It is just "cleaning out the dust and bring down the trash".

But no, we're still busy, and CDFS will keep me busy for more time. Besides, I will be away for conferences, meetings and vacations for the next weeks, which will slow things do. Nothing is dead here, not at all.

[kolla]

Woop woop!

Great to see gadtools replacement prefs for Workbench and ASL!
(btw - http://aminet.net/package/util/misc/AslToRT - patch all programs to use ASL instead of ReqTools etc)

Also very nice to see old Ed getting some love, it's pretty much the "vi of Amiga" (while c:edit is the "ed of Amiga" ironically, btw your very own SED could very well be included, super useful!). Really looking forward to more reliably be able to run Ed remotely over serial and TCP connections. I presume the old problem of Ed "clearing" protection bits when writing files is taken care of too?

Oh no, guess I will be repeating myself now, but here goes...

Links in filesystems, softlinks - Workbench now indicates them with underline, which is great, but from CLI they just looks like directories. C:List should be able to indicate that they are links and more important, display where they point to.

Ram-handler? I think I have mentioned before that "version RAM:" could/should output version of ram-handler that is used, if at all (there are other means of setting up RAM: after all) to be consistent with FFS (and PFS3 and others).

Formatted output from C:Info - Info DH0: LFORMAT "Size of %d: is: %s, its name is %n and it is %p%% full, using %u bytes, having %f bytes free!"

I better stop... :rolleyes:

[guest11527]

Also very nice to see old Ed getting some love, it's pretty much the "vi of Amiga" (while c:edit is the "ed of Amiga" ironically, btw your very own SED could very well be included, super useful!). Really looking forward to more reliably be able to run Ed remotely over serial and TCP connections. I presume the old problem of Ed "clearing" protection bits when writing files is taken care of too?

Probably not, but thanks for pointing this out.

Links in filesystems, softlinks - Workbench now indicates them with underline, which is great, but from CLI they just looks like directories. C:List should be able to indicate that they are links and more important, display where they point to.

That has been taken care of already. Softlinks are shown correctly, can be deleted by delete, and - even better - work now. Both FFS and the Ram Disk had really a couple of issues here.

Ram-handler? I think I have mentioned before that "version RAM:" could/should output version of ram-handler that is used, if at all (there are other means of setting up RAM: after all) to be consistent with FFS (and PFS3 and others).

Hmm. I wouldn't know why that should not the version, but I'll see.

Formatted output from C:Info - Info DH0: LFORMAT "Size of %d: is: %s, its name is %n and it is %p%% full, using %u bytes, having %f bytes free!"

I better stop... :rolleyes:

Well, that would probably too much of a change right now, or more than I would be willing to handle. Also, we lost the "sort" option of List since the old sources of List from 3.9 seem to be lost in space and time. I already rewrote Execute. I don't really want to spend too much time on List.

[guest11527]

Probably not, but thanks for pointing this out.

This was a good one:

Code: [Select]

#define BACKUPNAME ":T/ed-backup"
DeleteFile(BACKUPNAME);
Rename(file_name,BACKUPNAME);
do_writebuf(line_first,line_last,file_name,BACKUPNAME);
...spot the error. CBM quality code at its best.

[kolla]

...spot the error. CBM quality code at its best.

Yes, not the only program that loves to have a directory :T on whatever filesystem you are editing a file, I think C:edit does the same. Can you imagine race-condition cases when a user is editing multiple files on same filesystem using Ed? The lolz

[guest11527]

Yes, not the only program that loves to have a directory :T on whatever filesystem you are editing a file, I think C:edit does the same. Can you imagine race-condition cases when a user is editing multiple files on same filesystem using Ed? The lolz

C:Edit was probably the last executable program in BCPL. The last handler in BCPL was the Aux-Handler, but that got rewritten already. My current handling of C:Edit is that I removed it from the distribution. It is about the only binary (along with C:MagTape) I haven't used *once* in 20 years. It shares now the same destiny with MagTape -> NIL:

[Gulliver]

C:Edit was probably the last executable program in BCPL. The last handler in BCPL was the Aux-Handler, but that got rewritten already. My current handling of C:Edit is that I removed it from the distribution. It is about the only binary (along with C:MagTape) I haven't used *once* in 20 years. It shares now the same destiny with MagTape -> NIL:

It is a pitty as c:edit is great for building scripts to edit the startup-sequence in a non interactive manner. I am all for a replacement, but not for a removal without something that replaces that functionality.

We had a little chat about edit a while ago about this with Olaf Barthel:
http://www.amiga.org/forums/showthread.php?t=57601&

On the other hand, I have nothing good to say in favour of Magtape.

[kolla]

Totally expect MEmacs updates, haha

[sean_sk]

So, all tiny tiny improvements here and there. There is no "big new thing" that will come with 3.1.4. It is just "cleaning out the dust and bring down the trash".

It might seem like that but, after having read through all the changes and improvements, it does altogether amount to a pretty "big new thing" and really wanted to thank you for undertaking such a task. I'm really excited about the changes and am looking forward to trying them out.

I bought WB 3.1 ADF's from Cloanto last year so there's one thing I'm not clear on: how will 3.1.4 be released? Is there a rough time frame?

[Romanujan]

Thomas, any chance to include GhostBuster (hiding invalid disks depending on user settings) functionality in the improved Workbench?

[Iggy_Drougge]

Well, that would probably too much of a change right now, or more than I would be willing to handle. Also, we lost the "sort" option of List since the old sources of List from 3.9 seem to be lost in space and time. I already rewrote Execute. I don't really want to spend too much time on List.

Wasn't the SORT option first introduced by Heinz Wrobel in Envoy, long before OS 3.9?

[guest11527]

Wasn't the SORT option first introduced by Heinz Wrobel in Envoy, long before OS 3.9?

Yes, it was. But we don't have the sources of this particular version. What I do have are the sources of the 4.x "List" which includes the same as far as I know, but given my experience with CDFS, I currently plan to inverst the little work power we have into more serious issues.

[guest11527]

Thomas, any chance to include GhostBuster (hiding invalid disks depending on user settings) functionality in the improved Workbench?

Please understand. We have very limited resources for development, and we cannot just include feature after feature. The central theme of this release is "we fix bugs" not "we add new features". We don't have resources beyond the bare essential means, and most of the resources go into important bug fixing, so please lower your expectations.

Just to give you an idea: Workbench and icon are already too large to fit into the ROMs. There will be only a loader version in the ROM, and the libraries will be on disk. Because they already have more features, they will take more RAM, so that there is less left on the low-end machines. It will probably not work with 512K alone. This already gave reasons for complains.

We cannot do everything right for everyone, and we cannot address every need, every feature, yet at the same time keep it fast, small and simple. It is a painful compromize to include the essential features, and only that, and focus on the most important issues we have.

My experience is that 3.1.4 as we have it right now is already much larger (in the amount of changes we did) than I expected it to become, and yet, as an update, it is much smaller than what 3.9 offered. We try to keep 3.9 components workable, but we cannot include many 3.9 components for multiple reasons. Leave alone, update 3.9 components.

There is a reason why this is 3.1.4 and not 3.14.

[Romanujan]

That's perfectly OK, I only asked - in fact, I have asked for this particular feature only because it seems very simple to implement (one more value for already existing configuration parameter + few more C statements to determine if disk icon should be displayed)... at least from the point of view of someone, who didn't see the Workbench 3.9 source code

[kolla]

C:Wait and C:Sort, both version 42.1, at least the sources are not a problem, hehe

The FILE option of Wait 42.1 has turned out to be quite useful for me, simple trick to solve situations with several background running scripts having dependencies on each other etc.