AROS ABIv0 20180423 Development

[AMIGASYSTEM]

@deadwood

I integrated your D3 ISO into my AROS One x86 ISO, everything went well, as you can see from the attached video, Help Prefs worked fine from DVD Live, also Locale Prefs, and OWB and Wanderer Prefs Tabs worked fine without any problem.

I forgot, even the Pointer Prefs now works well.

https://drive.google.com/file/d/1ZXTvD5sry90QaTKnJO9KvniO_1vHk_aE/view?usp=sharing

[deadwood]

Good, I look into remaining issues then.

[cavemann]

@ deadwood

I'm surprised so many programs use isnan.
Well okay, here's the output.

-------------------------------------------------------------------------------
1 > make

current values of user-set variables:
        DESTDIR      ?=
        prefix       ?= /usr/local
        exec_prefix  ?= /usr/local
        OPTIMS       ?= -march=native -mtune=native -Ofast
        WARNINGS     ?= -Wall -Wextra -pedantic

g++     PEngine/audio.cpp -> PEngine/audio.o
In file included from ./include/vmath.h:8:0,
                 from ./include/pengine.h:38,
                 from PEngine/audio.cpp:40:
/Development/lib/gcc/i386-aros/6.3.0/include/c++/math.h:66:12: error:
'constexpr bool std::isnan(double)' conflicts with a previous declaration

 using std::isnan;
            ^~~~~
In file included from /Development/lib/gcc/i386-aros/6.3.0/include/c++/cmath:45:0,

                 from /Development/lib/gcc/i386-aros/6.3.0/include/c++/math.h:36,

                 from ./include/vmath.h:8,
                 from ./include/pengine.h:38,
                 from PEngine/audio.cpp:40:
/Development/include/aros/stdc/math.h:320:6: note: previous declaration
'int isnan(double)'

 int (isnan)(double) __pure2;
      ^~~~~
make: *** [PEngine/audio.o] Error 1

-------------------------------------------------------------------------------

Also another request, gcc has much more output. I wonder if the shell buffer
could possibly be increased someday, to show more lines of text.

ps  I've managed to compile my first c++11 program, yay 

[deadwood]

-------------------------------------------------------------------------------
1 > make

Can you share those source codes with me?

Also another request, gcc has much more output. I wonder if the shell buffer
could possibly be increased someday, to show more lines of text.

You mean to hold more "history" lines / scroll back longer?

ps  I've managed to compile my first c++11 program, yay 

Gratz! That's was the aim.

[deadwood]

Additional question: Did you have any freezes of GCC/freezes of AROS itself when compiling?

[AMIGASYSTEM]

@deadwood

In your Distributions D2, D3 and earlier in the Locale\Catalogs folder, there are duplicate languages:

- Italiano
- Italian

- Deutsch
- German

Included in the duplicate folder is the file "Locale.catalog" which is missing in the other folder so before dileminating the duplicate, the missing file must be retrieved.


On AROS 68k in your Distros there are no Duplicates, but in the Devs\Keymaps folder the pc105_i file is corrupt, we had discussed this in the past.

In my ISO of AROS One I deleted the duplicate Catalogs and created Icons for the main folders, see screenshot.

[cavemann]

@ deadwood

> Can you share those source codes with me?

Sure thing. Where should I send them?
 
> You mean to hold more "history" lines / scroll back longer?

Yes, it's an old request, but, make > RAM:stdout.log doesn't seem to work, So instead, I have to make the compiler stop output after the first error. Or perhaps somehow make the compiler less verbose.

> Did you have any freezes of GCC/freezes of AROS itself when compiling?

I don't recall, I think not. I usually have the stack set at 800k. And with gcc 4.6.4, linking would get faster and more stable if I compiled in RAM.
 

[Amiwell]

I updated my system with the last Build the only strange thing perhaps concerns the muimaster.library some applications that use it show strange anomalies in their main bar but everything works regularly

[AMIGASYSTEM]

I confirm the problem on the Top Bar Title for ZunePaint, this happens with D1, D2, D3, Distro earlier the problem does not exist, i have not encountered this problem on other applications

There is however a more important bug on applications that make use of Zune, this is an old problem that also happened on the last Nightly Builds.

Basically if you do "Open File" the request file if moved produces many copies of the window, if the request remains open the windows on Wanderer will also have the same problem, see screenshot.

Tested this Problem on OWB, Zune Paint, Zune Fig and probably also found it on many other applications using Zune.

Also the Request File is too small in size, and this in some cases creates problems in navigating, if a larger request is possible it would be more optimal and work better.

[deadwood]

On AROS 68k in your Distros there are no Duplicates, but in the Devs\Keymaps folder the pc105_i file is corrupt, we had discussed this in the past.

It the locale files are updated in ABIv11, we will have to wait until ABIv0 gets updated to recent enough release. Note that this is not a bug. AROS supports both "english" and "native" locale names, so the locale files can be in either german or deutch directories.

As for the keymap, I added a bug report: https://github.com/deadw00d/AROS/issues/70

[deadwood]

@ cavemann

>> Can you share those source codes with me?
>Sure thing. Where should I send them?
 
You can find my email here: https://axrt.org/index.php?tab=community

>> You mean to hold more "history" lines / scroll back longer?
>Yes, it's an old request, but, make > RAM:stdout.log doesn't seem to work, So instead, I have to make the compiler stop output after the first error. Or perhaps somehow make the compiler less verbose.

What about if you do >RAM:stdout.log (without space after >)

>> Did you have any freezes of GCC/freezes of AROS itself when compiling?
>I don't recall, I think not. I usually have the stack set at 800k. And with gcc 4.6.4, linking would get faster and more stable if I compiled in RAM.

Ok, this confirms GCC 6.3.0 needs more stack space than the default 256k.

[deadwood]

Ok, noted the ZunePaint window title problem for investigation.

For the requester, I created enhancement report: https://github.com/deadw00d/AROS/issues/71

As for the size, how much bigger you need. Remember that you also need to take into account m68k build where space is limited in lower resolutions. Best if you provide two sets of sizes, one for x86 another for m68k.

[AMIGASYSTEM]

Note that this is not a bug. AROS supports both "english" and "native" locale names, so the locale files can be in either german or deutch directories.

They are aware of the dual support "english" and "native"

Regarding the keymap, the pc105_i file possibly can be replaced with the one in an old Aros 68k distro (aros-orca-m68k).

For the requester, I created enhancement report: https://github.com/deadw00d/AROS/issues/71

As for the size, how much bigger you need. Remember that you also need to take into account m68k build where space is limited in lower resolutions. Best if you provide two sets of sizes, one for x86 another for m68k.

Even 68k has the same problem if you use RTG screens (some times the clicked folder is move on other folder), for the size I was referring more to the "length", see screenshot

[paolone]

@all


If you wish to try it, I have a new Icaros Desktop Live! build available, with old programs but newest system files from Deadwood's D3 ISO:
http://www.icarosdesktop.com/BETA/20220520/live-experimental.iso


let me know if it works OK for you, and if you find any unresponsive/incompatible 3rd party application.
You'll have to install it onto hard drive to test it thoroughly.


have a nice day

[Amiwell]

ok Paolone