Welcome, Guest. Please login or register.

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

Description:

0 Members and 2 Guests are viewing this topic.

Offline kolla

Re: Os 3.2 development preview
« Reply #404 from previous page: December 06, 2019, 07:12:11 PM »
No, because then a lot of other bad things will happen.

Scaremongery much?

I don’t see anything bad about Cloanto taking over, only a lot of positive things.
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 #405 on: December 06, 2019, 07:52:07 PM »
I don’t see anything bad about Cloanto taking over, only a lot of positive things.
Another fanboy then, as expected.
 

Offline Neuf

  • Newbie
  • *
  • Join Date: Aug 2017
  • Posts: 3
    • Show only replies by Neuf
Re: Os 3.2 development preview
« Reply #406 on: December 07, 2019, 05:26:48 AM »
@kolla
You say you don't see anything bad about Cloanto taking over.  I must say I beg to differ with you. Firstly, Cloanto has made it abundantly clear that if they win the court case 3.1.4 will be discarded. He has said this quite publicly on numerous occasions,and very firmly I might add. There are a few other things he has said that have my eyebrows on the ceiling. I won't go into detail at this time. Hyperion has not done much right in the last twenty years,but 3.1.4 is by far and away the most important.  In fact they have almost rectified the damage they have done in the past.

I fully understand your loathing of Hyperion.  I think you and I are very close to being on the same page in this regard.  OS 4.x is a terrible mess. A-Eon brought in Warp 3D and warp 3D Nova as well to deal with RTG graphics. They are bringing in Enhancer software to improve the OS as well.  The problem with Enhancer is that many of its features should have been in the OS in the first place. SMP should have been done in 2012, if not sooner. I could go on and on on the defects in OS 4.x,but since this is about OS 3.2, I'll leave it at that. Cloanto I must tell you is no better than Hyperion.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #407 on: December 07, 2019, 07:46:51 AM »
Another day, another component. Or some of them, in a bundle. Math libraries.

3.1.4. created the "magic math libraries" that rebuild themselves if a FPU becomes available later in the livetime of the system, .e.g. through setpatch, though there was still something odd about them: The rounding convention.

The math libraries (singbas, doubbas and the corresponding "trans" libs) all follow a "round towards zero" strategy in software, and similarly, set the FPU - if present - to round in the same direction. This gives consistent results, though it is - as far as the math is concerned - not ideal as it will loose precision.

3.2 changes that and follows a strict "round to even" rounding policy, which is a better and more precise rounding mode. It means that it tries to round to the nearest number if rounding is required, and in case of a tie, it rounds to the next number with the LSB set as zero. It can then be shown that under such conditions the output of the computation is identical to the output that had been obtained by computing with infinite precision, followed by round-to-even, which is a nice result. IOWs, you cannot possibly round better.

There is one exception, and that is the "convert float to int" function of the math libraries. They continue to round to zero. There are two reasons for that: First, because the C standard says so, and second, because some programs depend on it, for example the (really naive) floating point to text conversion (i.e. "printf %g") of the Aztec compiler.

Now, it seems easy just to configure the FPU such that it follows a different rounding convention. While the math libraries certainly do that, all the CPU only implementation *also* has to change, and this was a tremendous task. So every function in the "bas" libraries was touched, and the code to adjust the digits for rounding was modified to implement a proper "round to even" strategy. Multiply, add, subtract, division, square root.

The libraries were then verified for correctness by the "Paranoia test", which is a numerical unit test that checks for corner cases of the implementation, and checks for proper rounding. Again, running a test sounds harmless, but bear in mind that the test is in C, is compiled with SAS/C, and SAS/C does not support IEEE single precision numbers. So, the first step was to get the test working on the ieeesingbas library, and then to get the libraries working correctly, which took another two weeks of work.

Final result now: While the old libraries returned an "acceptable result" with some "numerical flaws" due to improper rounding, the new libraries pass all numerical tests with "excellent". So, no numerical flaws left in the math department, and the CPU output is identical to the FPU output.

mathffp (math.library and mathtrans.library) remain in the sad state they have been before. Unfortunately, there is little we can fix here because the number format is just broken. There are no infinities, there are no NaN ("not a number"), there is no gradual underflow (no "denormalized numbers"), so for any kind of numerics, stay away from this math library.

The only reason why it is still in ROM despite its sad state is that some software may depend on it early on booting (still to be available), but mathffp is one of my prime candidates to be thrown out in the future. It's bad numerical quality, beyond fixing. The code quality is fine - hand optimized assembler, coming directly from Motorola - but that doesn't help if it doesn't compute right.

 
The following users thanked this post: Tygre

Offline kolla

Re: Os 3.2 development preview
« Reply #408 on: December 07, 2019, 11:56:32 AM »
I don’t see anything bad about Cloanto taking over, only a lot of positive things.
Another fanboy then, as expected.
If I was a fan boy, you would think I also favour their products, but I don’t. I bought Amiga4Ever way back when I was still a little involved with bttr, but mostly for the extras, and I also bought their “personal” collection, but that was it, I always found their Amiga software awkward to use, and their attempt to recreate windowsish registry nuts.

But this is not about “pro Cloanto” as much as it is about being against Hyperion, I have said all along that there will have to be another “back to scratch” development from 3.1 once the nonsensical legal situation is cleared up, and I am fine with that, especially since the current development is going very much in a wrong direction IMO. If Hyperion “win”, OS3 will be in same state as OS4 within very short time.

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 #409 on: December 07, 2019, 12:01:45 PM »
especially since the current development is going very much in a wrong direction IMO.
So what's wrong about the direction?
 

Offline LiveForIt

Re: Os 3.2 development preview
« Reply #410 on: December 07, 2019, 03:12:39 PM »
Quote
Concerning iconification, intuition gets a new first class citicizen window gadget you can request to get added to your window, and this is the iconification gadget. WFLG_ICONIFY enables it. If the user presses on the gadget, intuition sends an IDCMP_CLOSEWINDOW with a "CODE=1" instead of CODE=0 to the application, which can then react accordingly. All the system tools, preferences, utilities and the console window use it to iconify themselves on the workbench.

This sound like a really bad idea, so everyone that enable that will have there programs crashing when adding WFLG_ICONIFY,
way not do it like its done in AmigaOS4, make it compatible use IDCMP_GADGETUP, what is the point of updating AmigaOS3.x is you’re are not making it compatible.
« Last Edit: December 07, 2019, 03:16:31 PM by LiveForIt »
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #411 on: December 07, 2019, 03:27:41 PM »
This sound like a really bad idea, so everyone that enable that will have there programs crashing when adding WFLG_ICONIFY,
Can you please tell me why anything should crash?  Nothing crashes here.

way not do it like its done in AmigaOS4,
Os4 doesn't have a window flag to add an iconification gadget at all. The iconification gadget is a second-class citizen there.

make it compatible use IDCMP_GADGETUP, what is the point of updating AmigaOS3.x is you’re are not making it compatible.
Can you tell me why the close gadget is a first class system gadget and iconification should not?
 

Offline nbache

Re: Os 3.2 development preview
« Reply #412 on: December 07, 2019, 04:20:38 PM »
@LiveForIt:

Quote
This sound like a really bad idea, so everyone that enable that will have there programs crashing when adding WFLG_ICONIFY
If I understand it correctly, it is the programmer who requests the new gadget in his setup code by means of WFLG_ICONIFY.

The same programmer who then of course makes his code ready to receive the new CODE=1 value and react accordingly.

All other programs do not request the new feature and will therefore only receive the already known IDCMP_CLOSEWINDOW value (when the window close gadget is used).

That sounds to me like a pretty solid design.

Best regards,

Niels
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #413 on: December 07, 2019, 04:29:34 PM »
I should probably add that you can still create iconification gadgets the same way as Os 4 did it, so no harm is done.

It is just much more complicated: You create a sysiclass boopsi image of the right type, then create a struct Gadget, then fiddle the gadget into the title bar of the window, then react on the IDCMP_GADGETUP.

Yes, you can still do that, and it works, of course. It is just a lot more complicated than just telling intuition right away what you want. Intuition then takes responsibility to allocate the gadget and to release it.
 

Offline LiveForIt

Re: Os 3.2 development preview
« Reply #414 on: December 07, 2019, 07:20:21 PM »
Well maybe it will not crash, maybe the program just terminate unexpected, if the event is not handled as you suggest. Well it’s more complicated to write the same code two times one for 3.x and one for 4.x, I don’t see how that’s easier, my impression of boobsi system is that all window gadgets are buttons, including resize, close button, window back, window front etc,
 

Offline LiveForIt

Re: Os 3.2 development preview
« Reply #415 on: December 07, 2019, 07:27:43 PM »
Quote
That sounds to me like a pretty solid design.
Are you joking? He is going to break the design, just to break it.
WFLG_ICONIFY is flag that exist today that you will always get a IDCMP_GADGETUP event, doing it differently and now you have incompatible code.

it’s just like scroll wheel thing its different for the sake of being different.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #416 on: December 07, 2019, 07:41:32 PM »
I don’t see how that’s easier, my impression of boobsi system is that all window gadgets are buttons, including resize, close button, window back, window front etc,
You still do not understand. The system gadgets *are* not boopsis. They use boopsis for the gadget images, but do so since Os 3.0. CloseWindow does not send a GAGETUP, so why should Iconify?
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #417 on: December 07, 2019, 07:47:17 PM »
Are you joking? He is going to break the design, just to break it.
WFLG_ICONIFY is flag that exist today that you will always get a IDCMP_GADGETUP event, doing it differently and now you have incompatible code.
Pardon my ignorance, but WLFG_ICONIFY does not exist in AmigaOs 4.0.  What AmigaOs 4.x offers is an ICONIFYIMAGE, which is a boopsi derived from the sysiclass boopsi that renders the iconification gadget imagery. As I already explained, this does not change. This boopsi continues to exists in 3.2, under the same ID.
There is also the reaction window.class which offers iconification. Iconification with the window.class works exactly as it did before, except that the window class internally uses now WLFG_ICONIFY instead of fiddling its custom gadget into the title bar.

it’s just like scroll wheel thing its different for the sake of being different.

Not at all. Ported Os 4 programs will just work, as the sysiclass ID of the iconification image is as before. But writing programs that support iconification becomes much simpler as you do not have to create the gadget yourself.
 

Offline TribbleSmasher

Re: Os 3.2 development preview
« Reply #418 on: December 07, 2019, 07:58:26 PM »
Some ideas, maybe stupid:
Can there be a way to invoke the border scrollers and arrows in a similar way, by adding WFLG_WBborderscrolls or something?
And, on another topic, is it possible to implement a late-mount for devices that has been powered up while the system is already running, and are not swappable?
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #419 on: December 07, 2019, 08:04:44 PM »
Can there be a way to invoke the border scrollers and arrows in a similar way, by adding WFLG_WBborderscrolls or something?
Scrollers are probably not quite as generic as the remaining system gadgets, so I do no t yet see them as such useful.

And, on another topic, is it possible to implement a late-mount for devices that has been powered up while the system is already running, and are not swappable?
Yes, is possible and already done. I'm just not there yet with the update report. SYS:System contains a new tool "Mounter" that will do that. It will also use the new ACTION_DIE to safely shut down running file systems. That is, all the changes to the FFS became necessary to make the "Mounter" design more robust.