Welcome, Guest. Please login or register.

Author Topic: Os 3.2 development preview  (Read 135031 times)

Description:

0 Members and 3 Guests are viewing this topic.

Offline kolla

Re: Os 3.2 development preview
« Reply #44 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.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #45 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.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #46 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.
« Last Edit: August 30, 2019, 03:49:50 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #47 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.

 

Offline kolla

Re: Os 3.2 development preview
« Reply #48 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 :)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #49 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?

 

Offline HyAmi

  • Full Member
  • ***
  • Join Date: Apr 2005
  • Posts: 101
    • Show only replies by HyAmi
Re: Os 3.2 development preview
« Reply #50 on: August 30, 2019, 09:04:58 PM »
Will there be any different hardware requirements for 3.2?
 

Offline wiser3

  • Jr. Member
  • **
  • Join Date: Jan 2007
  • Posts: 84
    • Show only replies by wiser3
    • http://www.trep4.com/
Re: Os 3.2 development preview
« Reply #51 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.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #52 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.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline Gulliver

Re: Os 3.2 development preview
« Reply #53 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.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #54 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.
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #55 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?
 

Offline Gulliver

Re: Os 3.2 development preview
« Reply #56 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. ;-)
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #57 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
 

Offline Gulliver

Re: Os 3.2 development preview
« Reply #58 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.
 

Offline wiser3

  • Jr. Member
  • **
  • Join Date: Jan 2007
  • Posts: 84
    • Show only replies by wiser3
    • http://www.trep4.com/
Re: Os 3.2 development preview
« Reply #59 from previous page: 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.