Welcome, Guest. Please login or register.

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

Description:

0 Members and 2 Guests are viewing this topic.

Offline Gulliver

Re: Os 3.2 development preview
« Reply #209 on: October 20, 2019, 11:23:29 AM »
Will the new Datatype system still be compatible with older datatypes like Warp and AK or will it require the developers to update them?
The datatypes system did not change in 3.1.4, and there are no interface changes planned for 3.2.
I was referring to Gulliver's statement that "The datatype system has been improved". I was wondering if those improvements would cause any problems with older datatypes. Improvements is a bit vague so was looking for a little more explanation.

If it sounds a bit vague to you, then I will change the wording so that I avoid any confusion.

Thanks
 

Offline kolla

Re: Os 3.2 development preview
« Reply #210 on: October 20, 2019, 01:26:11 PM »
I never heard of anyone using the Ghostbuster patch having problems formatting devices... ??

It is a useful option for those cases when more handlers/filesystem definitions are used for the same device and unit, for example I have both CD0 and SD0 in devs:dosdrivers, and depending on whether it’s a cd drive or sd card attached to the second IDE unit, one of them show up and the other is hidden from workbench.
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 kolla

Re: Os 3.2 development preview
« Reply #211 on: October 20, 2019, 02:55:12 PM »
Why? Isn't this rather redundant as one can use "If not WARN" instead?
There is no "or". || is output concatenation. && is sequencing. It is most useful in pipe constructions.
I know there is no "or", what I am asking is if "&&" is now an "and".

Are these equivalent?
Code: [Select]
command1 && command2 && command3vs
Code: [Select]
command1
if not warn
  command2
  if not warn
    command3
  endif
endif

Quote
Great - and how do one redirect from stdout to stderr and vice versa?
Same as you always did. Without any other activities, stderr goes to stdout. *> redirects stderr.  *<> redirects stderr to stdout, *>> appends stderr. The shell syntax did not change, only the commands did (and the dos.library did) to make consistent use of stderr.
Hm, I have had troubles with this before due to inconsistent implementations - I don't recall exactly, but a work-around with v46 (iirc) was using "( command ) > file" instead of "command > file"

Quote
And which font in Font prefs is used? Same as for Window and Screen titles? Or has this been fine masked a little?
The system default font, unless the window doesn't fit on the screen, in which case it falls back to topaz.8.
Meh, so same font will be used for just about everything except Workbench icons (a font setting that really should be in Workbench prefs) and console windows (ViNCEd use its own font settings though). I wish for more "fine grained" settings, as I want to use a smaller font for GUI/gadgets/requesters etc than I use for window title bars and screen title bar. Oh well.

Quote
Still not possible to hide "NDOS" or other non-validated filesystem devices, like the Ghostbuster patch does?
No. Otherwise, you won't be able to format unformatted disks.
As mentioned, I never had a problem formatting anything because of this... it's as if you never tried the Ghostbuster commodity and its Workbench prefs replacement, and hence do not really know how it is used.

Quote
Does search also work in amiga guides?
Amigaguide did not change. It is not HTML.
I just asked if is possible to search in Amigaguide files, I never said anything about HTML - why do you bring up HTML??
Quote
Will the Workbench "Find" be "populated" again?
If you have WBFind installed, it is. That does not change. The workbench itself does not have a global find, it requires an external component for that.
I take that as a "No", and I never ever heard of a "WBFind".
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 paul1981

Re: Os 3.2 development preview
« Reply #212 on: October 20, 2019, 07:44:52 PM »
@kolla
"Super - though it sucks for those systems that don't have serial port, because "who in this day and age need that?" :)"

That's like saying Amiga - Who in this day and age needs that? :)
 

Offline kolla

Re: Os 3.2 development preview
« Reply #213 on: October 21, 2019, 05:47:38 AM »
@kolla
"Super - though it sucks for those systems that don't have serial port, because "who in this day and age need that?" :)"

That's like saying Amiga - Who in this day and age needs that? :)

I agree - I use serial port literally all the time - as that's where the console for the raspberry pi is :)
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 Tygre

Re: Os 3.2 development preview
« Reply #214 on: October 21, 2019, 11:01:48 PM »
I’m not publishing jack, any dumbass “expert” can do this themselves, the masses can follow your pipe.
So, why don't you? Let other people make the work, and then complain about the results? Yes, I know that's easier, but it's not very helpful. Try to be a bit positive and contribute. I'm serious.

Then Kolla would not be Kolla ;D

More seriously, there has been many great questions/answers in this thread (and elsewhere), maybe they should be all put together in some kind of FAQ somewhere?

Offline matt020

  • Jr. Member
  • **
  • Join Date: Apr 2010
  • Posts: 50
  • Country: au
    • Show only replies by matt020
Re: Os 3.2 development preview
« Reply #215 on: October 22, 2019, 01:56:43 PM »
Hi,

Lots of pages to read here, my appologies if this has been covered already.

Is this an upgrade/update to Workbench 3.1, or to 3.1.4?
What ROM will be required to run OS 3.2, and will there be a Kickstart 3.2 ROM?

Cheers.
A500, A600, A2000, A1200, CD32, A4000
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #216 on: October 22, 2019, 07:01:28 PM »
Is this an upgrade/update to Workbench 3.1, or to 3.1.4?
Will work on top of both.

What ROM will be required to run OS 3.2, and will there be a Kickstart 3.2 ROM?
As for 3.1.4, there will likely be a ROM option.
 

Offline CBH

Re: Os 3.2 development preview
« Reply #217 on: October 22, 2019, 07:13:53 PM »
(Will there be a PPC product line? I do not know.)

In itself that's quite a bold statement for a developer of a hyperion product. I'm glad I never moved away from the 68k.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #218 on: October 23, 2019, 07:34:21 AM »
In itself that's quite a bold statement for a developer of a hyperion product. I'm glad I never moved away from the 68k.

No, it just means what I said: "I don't know". Nothing more, nothing less.
 

Offline Gulliver

Re: Os 3.2 development preview
« Reply #219 on: October 23, 2019, 10:22:43 AM »
More seriously, there has been many great questions/answers in this thread (and elsewhere), maybe they should be all put together in some kind of FAQ somewhere?

I have been continuously writing and improving a FAQ for 3.2 since 11 months by now.

And it is still getting more content, as questions are asked and features are added.

The FAQ will be publicly available when AmigaOS 3.2 gets ready for release.
« Last Edit: October 23, 2019, 10:25:12 AM by Gulliver »
 
The following users thanked this post: Tygre

Offline kolla

Re: Os 3.2 development preview
« Reply #220 on: October 23, 2019, 10:37:30 AM »
I’m not publishing jack, any dumbass “expert” can do this themselves, the masses can follow your pipe.
So, why don't you? Let other people make the work, and then complain about the results? Yes, I know that's easier, but it's not very helpful. Try to be a bit positive and contribute. I'm serious.
Then Kolla would not be Kolla ;D

Well, this is the "development model" chosen by Hyperion and Thomas here, they could have done it differently so that it would be easier to participate and contribute without being dragged into silly non-disclosure nonsense.

I am coming back to WBLoad... let's see what the FAQ says:

Quote
7.5 * What does the new WBLoad command located in C: actually do?

It is a sort of replacement for the more known WBRun command. It loads
Workbench programs from the CLI/Shell. However, it does not require
the Workbench. Hence, it is safe to use in the Startup-Sequence before
LoadWB, and it operates synchronously, i.e. it does not return until
the started program returns. If this bothers you, place an "&" as the
last argument to the program.

Well, we have now learnt that it is not a "sort of replacement" for WBRun, as they are very different tools that have different goals and purposes. WBLoad is _only_ for opening programs that for some weird reason cannot be opened from CLI directly - personally I don't even know of any such program (and I would find such a program that only can be launched from Workbench to be rather broken). If it at least could open files/drawers that have "project" type icons and an associated default tool, I could see some use for it. Secondly, it does not return until the started program returns, not sure why this is a feature, but perhaps if you have some obscure (broken) program that you insist on puttin in startup-sequence, and you don't want to continue startup-sequence until user has exited.... It also does not pass on ctrl-signals to the program that is started, even when those programs accept ctrl-signals themselves...  bug, lacking feature, who knows. Thirdly - does it even care about the associated .info file? Does it take tooltypes etc into account when starting programs? I admit I have not tested... but I am not be surprised if it does not. Meh... pfew...
« Last Edit: October 23, 2019, 10:46:28 AM 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 #221 on: October 23, 2019, 11:02:17 AM »
Well, this is the "development model" chosen by Hyperion and Thomas here, they could have done it differently so that it would be easier to participate and contribute without being dragged into silly non-disclosure nonsense.
This development model (which is a rather standard model for software, actually) is also due to some "users". Does this development model stop you from creating programs yourself right now, from developing? From publishing? If things would be "open" (in your definition), would you contribute any more than you do now? (And no, "complaining" is not contribution). Would it make any difference from you whether the Os sources would be accessible for you? If so, why? What does the current model stop you from doing right now you would be able to do otherwise?

I said this again: If you want a WBRun that works different from WBLoad, go ahead, write one and contribute. It does not matter whether it is distributed along with the Os. You can distribute it yourself, stay away from Hyperion (hopefully stay away from me), and just be happy.

Instead of contributing to the solution, you stick around, spread bad mood, complain, keep naging, and otherwise.... do nothing.

WBLoad is _only_ for opening programs that for some weird reason cannot be opened from CLI directly - personally I don't even know of any such program (and I would find such a program that only can be launched from Workbench to be rather broken).
No, it is for programs where you put parameters into icons as tooltypes, and you want to pass over exactly these arguments in the tooltypes to the program run, and not use the CLI parsing branch of the program. Thus, where you must ensure that the program behaives exactly as if double clicked from the workbench.


If it at least could open files/drawers that have "project" type icons and an associated default tool,
Which it does. So, you haven't tried. See what I mean by "users"?

Secondly, it does not return until the started program returns, not sure why this is a feature, but perhaps if you have some obscure (broken) program that you insist on puttin in startup-sequence, and you don't want to continue startup-sequence until user has exited....
It can. Put a "&" as last argument. Oh, that's an "obscure" shell feature? Nevermind, it does work.

It also does not pass on ctrl-signals to the program that is started, even when those programs accept ctrl-signals themselves...
Since when do workbench programs care about ^C? You can send them a signal if you want.


bug, lacking feature, who knows.
I know. You troll.

Thirdly - does it even care about the associated .info file?
If you ask this question, you don't know how WBStartup works.

I admit I have not tested... but I am not be surprised if it does not. Meh... pfew...
No, you haven't. You just come around trolling, complaining, not willing to contribute in any particular form.... Kolla, you are a shame for this "Community", and you are one of the top reasons why any form of "open development model" is a very bad idea.

Seriously, sit on your bottom, and write programs yourself. Help, contribute, then you are entitled to criticize because you've proven that you can do better. Actually, all you show is "I don't care, I don't want to do better, I just want to complain".

What's just wrong with you? Do you enjoy complaining instead of doing?
 
The following users thanked this post: Tygre

Offline CBH

Re: Os 3.2 development preview
« Reply #222 on: October 23, 2019, 02:44:30 PM »
In itself that's quite a bold statement for a developer of a hyperion product. I'm glad I never moved away from the 68k.

No, it just means what I said: "I don't know". Nothing more, nothing less.

If there was going to be a 4.2 you'd know for sure. It's normal to always expect that there will be a new version of a successful OS, if there's any room for "not knowing" it can only be for bad reasons.

Imagine if we could've skipped the PPC misadventure. We could've had 3.1.4 or equivalent 18 years ago. Are you getting paid this time around?
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #223 on: October 23, 2019, 03:14:24 PM »
If there was going to be a 4.2 you'd know for sure.
No, I wouldn't. Simply because I don't really care, and I don't look there - there is too much to do anyhow. So please don't read more into this than I said, it can be good, it may be bad - I simply don't bother.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #224 from previous page: October 23, 2019, 05:28:36 PM »
If things would be "open" (in your definition), would you contribute any more than you do now?

Yes, I would.

Quote
Would it make any difference from you whether the Os sources would be accessible for you?

Yes, it would make a big difference.

Quote
If so, why?

Because sources are often where one find the best documentation. Because with sources available one can actually read what the code is supposed to do. Because with sources available one can alter them, build, test out, debug etc, and potentially improve the code and submit patches. Most important though - and I am sure you would not approve - is that would allow regular users to build and share "special versions" among each other, and allow fixes to be dealt with swiftly, instead of having to wait months/years for updates that may or may not include fixes for the bugs I (and others) are struggling with.

Quote
What does the current model stop you from doing right now you would be able to do otherwise?
The current model prevents me from having any clue what bugs are known and which bugs are not, or even know what is bug and what intended feature, as both changelogs and list over known bugs are kept "secret".

Quote
and just be happy.

Who says I am not happy? I am happy, Amiga is just a hobby, and if there was less to complain about regarding the OS development, I would happily complain less - but the things way are now, there is just so much... nonsense... going on.

Quote
Instead of contributing to the solution, you stick around, spread bad mood, complain, keep naging, and otherwise.... do nothing.

Well, you know what? Complaining, nagging etc has proven be to be most effective method of getting useful information. Yeah, it's a sad thing.
Quote
WBLoad is _only_ for opening programs that for some weird reason cannot be opened from CLI directly - personally I don't even know of any such program (and I would find such a program that only can be launched from Workbench to be rather broken).
No, it is for programs where you put parameters into icons as tooltypes, and you want to pass over exactly these arguments in the tooltypes to the program run, and not use the CLI parsing branch of the program. Thus, where you must ensure that the program behaives exactly as if double clicked from the workbench.

Again, you write "program", and yes, for exactly that, it works.

Quote
If it at least could open files/drawers that have "project" type icons and an associated default tool,
Which it does. So, you haven't tried. See what I mean by "users"?

I have tried, and it did not work...

So it is supposed to work, you say....well after some testing I can say that it _only_ works if default tool is specified with full path - it doesn't care about shell path, and it doesn't care about workbench path - it only uses current directory as path. Where is this documented? Guess I just reported another bug, then... ouch, that was unintended.

Quote
Secondly, it does not return until the started program returns, not sure why this is a feature, but perhaps if you have some obscure (broken) program that you insist on puttin in startup-sequence, and you don't want to continue startup-sequence until user has exited....
It can. Put a "&" as last argument. Oh, that's an "obscure" shell feature? Nevermind, it does work.
Well, I prefer to stick with old "run >NIL:" which one can rely on, regardless of which broken version of Amiga shell that is used. But I still don't understand _why_ it should not detach by itself - by not detaching, it suggest that one can do something useful with the input, but nothing is described, and it doesn't handle ctrl-signals... so what is the point of not detaching?
Quote
It also does not pass on ctrl-signals to the program that is started, even when those programs accept ctrl-signals themselves...
Since when do workbench programs care about ^C? You can send them a signal if you want.

Well, don't just about all programs that ship with Workbench care about ctrl-c? All prefs programs, all commodities, tools like multiview etc.

Quote
bug, lacking feature, who knows.
I know. You troll.

In most cases, it looks like you are the only one who knows, even people like Gulliver more often than not, does not know and must check with you.
 
Quote
Thirdly - does it even care about the associated .info file?
If you ask this question, you don't know how WBStartup works.

WBStartup? Or did you mean WBLoad?
WBStartup cares about tooltypes like DONOTWAIT and WAIT - imagine if WBLoad could support those too, _that_ would actually have been useful - DONOTWAIT would detach, and WAIT, if present, could be used to specify for how long to wait before detaching. Consider this a feature request... oh now, I did again - sorry, not my intention to contribute with constructive criticism and ideas - I am really just here to whine!
Quote
I admit I have not tested... but I am not be surprised if it does not. Meh... pfew...
No, you haven't.
And I admitted it, it was the one example I took reservation with.
Quote
You just come around trolling, complaining, not willing to contribute in any particular form.... Kolla, you are a shame for this "Community", and you are one of the top reasons why any form of "open development model" is a very bad idea.
So you are saying that *I* am the number one reason why keep the development model as it is? Wow, I am flattered!

Quote
Seriously, sit on your bottom, and write programs yourself. Help, contribute, then you are entitled to criticize because you've proven that you can do better. Actually, all you show is "I don't care, I don't want to do better, I just want to complain".

What's just wrong with you? Do you enjoy complaining instead of doing?

Dr. Thomas is at it again? Why can you not stick to the topic instead of going on rants with personal attacks and asking suggesting questions? For the your information, nothing is wrong with me, I am also not complaining for the sake of complaining, you just take any sort of criticism of the product as a personal attack against yourself.
« Last Edit: October 23, 2019, 05:30:51 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