Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A600 Memory

AuthorTopic: Os 3.2 development preview  (Read 20027 times)

Steady and 3 Guests are viewing this topic.

Offline zurt

Re: Os 3.2 development preview
« Reply #150 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
« Last Edit: September 29, 2019, 08:32:59 PM by zurt »
zurt

AmigaOS user since 1989
MorphOS user since 2003
 

Offline Thomas Richter

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

Offline kolla

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

Offline Thomas Richter

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

Offline kolla

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

Offline Thomas Richter

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

Offline kolla

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

Offline Thomas Richter

Re: Os 3.2 development preview
« Reply #157 on: September 30, 2019, 01:25:11 PM »
Well, you are now, I gave you a hint.
That is addressed.

Offline kolla

Re: Os 3.2 development preview
« Reply #158 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?
« Last Edit: October 03, 2019, 01:17:52 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

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

Offline kolla

Re: Os 3.2 development preview
« Reply #160 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"?
« Last Edit: October 03, 2019, 02:37:36 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

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

Offline kolla

Re: Os 3.2 development preview
« Reply #162 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
« Last Edit: October 03, 2019, 09:42:25 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline paul1981

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

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.  :)
 

Offline Thomas Richter

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