Welcome, Guest. Please login or register.

Author Topic: Os 3.1.4 - List of bug fixes and changes by component  (Read 84953 times)

Description:

0 Members and 2 Guests are viewing this topic.

Offline utri007

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #44 on: October 24, 2018, 09:16:42 PM »
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.
ACube Sam 440ep Flex 800mhz, 1gb ram and 240gb hd and OS4.1FE
A1200 Micronic tower, OS3.9, Apollo 060 66mhz, xPert Merlin, Delfina Lite and Micronic Scandy, 500Gb hd, 66mb ram, DVD-burner and WLAN.
A1200 desktop, OS3.9, Blizzard 060 66mhz, 66mb ram, Ide Fix Express with 160Gb HD and WLAN
A500 OS2.1, GVP+HD8 with 4mb ram, 1mb chip ram and 4gb HD
Commodore CDTV KS3.1, 1mb chip, 4mb fast ram and IDE HD
 

guest11527

  • Guest
Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #45 on: October 25, 2018, 08:19:47 AM »
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.
The speed did not change, but there was definitely a bug in the color usage of the picture datatype I remember fixing. You could pass in a palette or request the palette from a picture, but this did not work in the Os 3.9 datatypes. It used to work in Os 3.1, but those did not support RTG graphics.
 

guest11527

  • Guest
Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #46 on: October 25, 2018, 07:40:06 PM »
There are a couple of changes in Rexx and around Rexx as well. First, the rexxsyslib.library did well in re-opening the mathieeedoubbas.library over and over again, but unfortunately ignored the result and only used the first library base. However, with the new "jumpy, the magic math library" the library base might have changed because the FPU was turned on. Not any more.

Then, we had a bug in FindDevice() which prevented rexx to locate scripts in multi-assigned ehem.. assigns. Instead of using dos.library functions, rexx there used Forbid()-locking for the dos-lists.

Finally, we had an issue in WORD(). It only takes 2 arguments, and not 2 or 3 arguments, so this was fixed.

Also, there are changes for all the commands in Rexxc. They now use ReadArgs() consistently, and hence support "?" as argument to query the arguments they take. "Rx" is a special case, but had special issues. If you ever tried to execute a script from "Ram Disk" like this
Code: [Select]
rx "Ram Disk:script.rexx"
you probably know. The above does not what you think, but tries to execute the string in quotes as rexx commands directly. To resolve that, "rx" takes a new argument "script" that enforces that the argument in quotes is a script and nothing else. This requires the new rexxsyslib.library as well.

Code: [Select]
rx script "Ram Disk:script.rexx"

hence does the right thing, and is also used by the shell implicitly for rexx scripts. The "script" argument brings another change, namely the interpretation of the script arguments. It then uses "shell-style" syntax, meaning that "*"" is the quote, because * is the escape character, unlike in rexx, where """" would indicate the quote (count the quotes!).

This is useful because
Code: [Select]
rx script "Ram Disk:script.rexx" "$arg"
expands correctly, even if the variable $arg contains blanks or quotes - which are escaped by the shell with an asterisk, not a double quote.

Last but not least, rexxsyslib.library contained since Os 3.9 the "RVI" (rexx variable interface) which allows setting rexx variables from rexx hosts. This used to be in amiga.lib (for strange reasons). The Os tools such as the workbench, ed but also multiview and some datatypes no longer link against amiga.lib, but use the RVI in the rexxsyslib.library directly, avoiding code duplications.

 
The following users thanked this post: Tygre

guest11527

  • Guest
Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #47 on: October 26, 2018, 10:12:15 PM »
More news on devices. We start with a seemingly harmless device, the clipboard.device. It (temporarily) keeps characters for copy & paste operations, or offloads it to disk. Strangely, by default to the RAM-Disk, which is probably not a good idea if RAM is low.
Anyhow. The clipboard.device is new. Really new. The problem with the old design was that it used Forbid()/Disable() locking, and hence did not work "so well" with multitasking. I am not even clear whether this always worked as intended, as the clipboard.device also made file operations to write clips to disk, and hence broke forbids.

The v45 clipboard.device uses semaphores. This is a bit touchy as one must not run into a semaphore conflict, aka "deadlock". It seems I succeeded there.

There are a couple of minor tweaks in the serial.device, especially to take precautions for some 68040 systems where blocking interrupts by writing to custom chips may leave a chance for a "delay slot" into which an interrupt may still be triggered. CMD_WRITE was also unnecessarily slow by requiring to go through an interrupt for writing the first character. This is no longer necessary.  Parity check was partially missing on CMD_READ, depending on the configuration.

There are not many changes in the parallel.device. The device used to add a sleeper port to the public port list, though who should look for it there as it is only used for internal operations. In fact, this was only used to initialize the port, so it was not needed.

What is common to all devices is that they support NSDQuery, i.e. support requesting the device command set. I am not a big fan of this mechanism as it has a couple of design issues, but it is too late to fix this, so we keep it (unfortunately).

The printer.device is a story of its own, so I will report separately. A longer story.

The mfm.device for crossdos trashed registers on some calls. It could also crash in case the code failed to initalize the disk geometry. CrossDos does, but not necessarily any other user. Also, its stack was really too small.

Last but not least, the narrator.device: Yes, it is not part of 3.1.4. Unfortunately. I had contact to its owner, SoftVoice, which is still in business. Unfortunately, they did not want to give a license, so we have to do without it. Too bad. The same goes for the translator.library. I case you wonder, SoftVoice also  provided S.A.M. (on C64 and the Atari 8-bit series). I would have loved to see, err. hear, narrator again.

 
The following users thanked this post: Tygre

Offline NinjaCyborg

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #48 on: October 27, 2018, 10:57:37 AM »
Datatypes: There is a new datatypes library...

Two questions about data types:

Are the Save methods implemented, which would allow rudimentary file format conversion?

Is progressive loading from stream inputs enabled for bitmaps, which would make them more suitable for use in a web browser type application?
 

Offline kolla

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #49 on: October 27, 2018, 02:32:02 PM »
Input.device was the source of head aches ever since Amiga got USB support - was anything done to improve this, or are USB users advised to continue to use old patched input.device?
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.1.4 - List of bug fixes and changes by component
« Reply #50 on: October 27, 2018, 04:33:39 PM »
Are the Save methods implemented, which would allow rudimentary file format conversion?
The picture.datatype supports DTM_WRITE, and so do the sound and the animation.datatype.

Is progressive loading from stream inputs enabled for bitmaps, which would make them more suitable for use in a web browser type application?
I afraid the datatypes system lacks the suitable abstraction to enable that, at least I wouldn't know how this should work.
 

Offline NinjaCyborg

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #51 on: October 27, 2018, 07:03:11 PM »
Are the Save methods implemented, which would allow rudimentary file format conversion?
The picture.datatype supports DTM_WRITE, and so do the sound and the animation.datatype.


Thanks but what I mean is do the sub types support it, for example Multiview has a Save menu, which by and large does nothing. It would be nice if you could load a file in ILBM format into Multiview and then save it out as PNG for example or vice versa, assuming save method was properly supported. Multiview would need some way of picking the target format from the list of compatible types too. This for me always seems like one of the features Commodore weren't able to finish what they intended, and while DefIcons picked up the slack of integrating datatypes with Workbench, I'd love to see this feature "finished".

As for progressive loading, datatypes should in theory allow creation from both a file handle, and a memory buffer, but the buffer needed to be fully populated already, datatypes couldn't provide partial renders based on progressive population of the buffer from say, and http stream, making it impossible for web browsers to progressively display jpegs, for example, decoding them line by line. Admittedly, that's less of an issue now in 2018 that everyone has megabit connectivity and images generally download instantly. I'm not familiar with OS4, but did they ever implement that capability?

By the way I used to work at Symbian, and we had a technology that allowed instantaneous blitting of compressed JPG and PNG files to the display, so you didn't need to store the uncompressed bitmap in ram before transferring it to the screen buffer. It would be decompressed at copy time.
« Last Edit: October 27, 2018, 07:13:27 PM by NinjaCyborg »
 

guest11527

  • Guest
Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #52 on: October 28, 2018, 09:08:02 AM »
I afraid this is currently not how it works. Saving pictures, just to name one example, is a matter of the picture.datatype (or at least it provides a DTM_SAVE method), and the picture.datatype always saves in ILBM. Of course, any subclass would be able to overload DTM_SAVE if it wishes to, but this does not enable conversion to another format. It would only allow to save the image either in the original format (if overloaded by the subclass) or the ILBM type (if no overload is present and the picture datatype does).

Your requested feature would require that a datatype "adopts" the bitmap of another datatype, and then save that. Not sure whether this is available, but it is at least not one of the initial requirements of datatypes.

I would need to check what exactly the "Save" menu of multiview does, at this point, I do not recall.
 

Offline NinjaCyborg

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #53 on: October 28, 2018, 09:40:26 AM »
It's a shame, as that would have allowed for multiview to work as a basic file conversion tool. Everything to ILBM one way conversion is only useful for stuff like using any image type as a wallpaper or window decoration.

The other bit of datatypes 'never finished' was the ability to specify the default tools for each of the different methods - one for each of "misc", "info", "browse", "edit", "print" or "mail" - the function is there in the library to retrieve the tool (e.g. the Rexx host FINDTOOL method) but there's nowhere for the user to configure it in the first place. An easy way would be to have tooltypes in either the def_<type>.info file or in the DataTypes Descriptor. Then Workbench could have been able to support choosing an action other than 'Open using default tool'. This was all stuff alluded to in the 3.1 NDK as being planned for 3.2 but never finished after C= closed down.
 

guest11527

  • Guest
Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #54 on: October 28, 2018, 05:19:12 PM »
Input.device was the source of head aches ever since Amiga got USB support - was anything done to improve this, or are USB users advised to continue to use old patched input.device?
Frankly, I do not see why a patch would be necessary in first place, but I also lack information in this respect. The input.device is just a broker, it does not "generate" input. If a USB stack wants to generate input, it just needs to create an InputEvent and send it down the stream of input event handlers by means of a simple DoIO(). Why would anything need patching for that?
 

Offline kolla

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #55 on: October 29, 2018, 01:57:38 PM »
Sorry, it's not really a patch as much as replacing entire input.device with one ported from MorphOS (v50), to (more) correctly handle multiple keyboard and multiple pointer devices.

I take your answer to mean that v50 input.device may still be what Poseidon USB stack users wish to use.
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.1.4 - List of bug fixes and changes by component
« Reply #56 on: October 31, 2018, 06:31:37 PM »
Handlers are one level above devices, and reside in L:. Their interface stems from Tripos, and hence a lot of BCPL legacy is found here. The very last snipped of BCPL code is, however, finally gone. 3.1.4 includes a completely new Aux-Handler that was written from scratch in C. For those that do not know: Aux is the "serial" counterpart of CON:. Unlike SER:, which only reads and writes characters, AUX: also buffers lines and includes a couple of keyboard shortcuts for editing text. Hence, you can start a new shell on a serial terminal with
Code: [Select]
newshell AUX:
The AUX: handler here handles now also ^C through ^F more carefully, and ACTION_WAIT_FOR_CHAR allows buffering of multiple requests.

Speaking of SER: This is implemented by the Port-Handler, which is also responsible for PAR: and PRT:. It is also new and fixes many issues. The previous version crashed if multiple read or write requests were piled up, and hence did not support asynchronous I/O at all. It also tries to identify the nature of the device it talks to, and hence changes its interface to either speak "parallel", "serial" or "printer" language, even if you connect it to another device - which is also a new feature. If you open "SER:" with the additional "path name" NOWAIT (i.e. Open("SER:NOWAIT")), then SER: will not block when no characters are in the input buffer of the serial port. It will return immediately.

The full set of options encoded in the path name is "BAUD/N,CONTROL,RAW/S,NOWAIT/S,TRANSPARENT/S,UNIT/K/N", where "BAUD" sets the serial speed, and CONTROL sets the serial parameters, e.g. "8N1" is 8-bit, no parity, 1 stop bit. NOWAIT we discussed above. RAW turns off the translation from LF to LF/CR pairs for the printer, and TRANSPARENT disables the translation of Amiga-specific (ANSI) control characters to printer-specific sequences. UNIT sets the unit number.

For some strange reason, the old port handler neither supported ACTION_WAIT_FOR_CHAR, which was a logical packet to support, especially with the serial console. Strange...

Also, a ^C send to the requesting process aborts the I/O interface. If you previously send a string to PAR:, but the printer was not ready, the system deadlocked because the process cannot be aborted waiting for PAR: to return, which it never did... This changed now, and even a "LIST >PAR:" can be safely aborted.

Speaking of speaking, there is a revised SPEAK:-Handler, though no narrator.device for it. There is not much new, except for a couple of minor fixes. ^C to abort speaking did not work quite right, it also stayed in memory permanently, and parsing of opt/ as well.

The queue-handler is completely new and unrelated to any former QUEUE-Handler. It handles abortion of queues ("broken pipes") now correctly, and this is the queue-handler you should use for the new shell. Even though there is no "IN:" or "OUT:" as in Os 4, there is "PIPE:". That is,

Code: [Select]
type s:foo | type pipe: hex
is a complicated way to type s:foo in hex. The "PIPE:" file name of the second "type" command accesses the input pipe.

Similarly,
Code: [Select]
list lformat="..." | execute PIPE:
creates a list of commands with list, and executes it with "execute". Here, PIPE: also accesses the input stream (reading end) of the pipe. PIPE: can also be used as the writing end of a pipe, i.e.

Code: [Select]
type s:foo to PIPE: | type pipe: hex
works too, just more complicated. Hence, no need for "IN:" or "OUT:", just write "PIPE:" and it will figure out itself into which end of the pipe the stream will go, reading or writing.

Other than that, there are also named pipes, as before. They can be read or write by name. For example:
Code: [Select]
type s:foo to pipe:bar &
type pipe:bar hex
starts the first command in background, and then reads from the same pipe, with type again. Even more complicated than before, but does just the same...

There are more new handlers: CrossDos, and the CD File System. I will cover them later in a separate blog.
 
The following users thanked this post: Tygre

Offline kolla

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #57 on: November 01, 2018, 07:33:48 AM »
What happens when "Execute" finds an "IF" in the pipe line? Will it patiently wait for "EndIF" till end of 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.1.4 - List of bug fixes and changes by component
« Reply #58 on: November 01, 2018, 07:49:10 AM »
What happens when "Execute" finds an "IF" in the pipe line? Will it patiently wait for "EndIF" till end of time?
Execute does not find "If"s. Actually, execute does not know much about the shell. In best case, it just redirects the input stream of the shell. In worst case, it creates a temporary file in T: by copying its input to T: and then redirects the input stream of the shell. It does not interpret the command stream in either case. It only substitutes formal parameters.

The shell itself neither cares about "if". The "If" command does. All it does is to continue pulling lines from the shell input stream if the condition is false until it finds the matching "EndIf".

What will not work if you execute from a PIPE: is a "Skip Back" command, and that only if execute does not perform command substitution, i.e. if there are no formal parameters. That is because the pipe does not allow seeking, for obvious reasons.
 

Offline mschulz

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #59 from previous page: November 01, 2018, 01:51:07 PM »
Quote
Your requested feature would require that a datatype "adopts" the bitmap of another datatype, and then save that. Not sure whether this is available, but it is at least not one of the initial requirements of datatypes.

You could just adopt an enhancement from AROS. When you create new datatype object you may explicitly specify the DTA_BaseName tag in order to select proper class. This way one could use datatypes to e.g. load a picture from disk, create new datatype object with specified class (e.g. { DTA_BaseName, (ULONG)"png" }), transfer data between them (PDTM_READPIXELARRAY/PDTM_WRITEPIXELARRAY) and finally write new datatype object (DTM_WRITE). Dunno if picture.datatype from 3.1.4 support this.

Example of use (writing picture datatype object as PNG) can be found in AROS sources, e.g. in my mirror: https://github.com/michalsc/AROS/blob/master/workbench/tools/ScreenGrabber/main.c