SweetAda 0.1 released

SweetAda 0.1 released

[gabriele.galeotti.xyz]

Hi all.

I've just released SweetAda version 0.1.

SweetAda is a lightweight development environment to create Ada code on a wide range of CPUs and platforms.

Have a look at http://www.sweetada.org.

This is an experimental preview, so comments and advices are welcome.

Feel free to ask me about everything, I know that a lot of components are poorly documented and difficult to understand without startup informations. This is a heavy work in progress, the manual is under incomplete translation and things could be not in-sync.

Many things do work, but many things, even basic, are still in a TODO list, and I will complete them upon an explicit interest.

E.G.:
- a PC-x86 platform will respond to network pings
- IBM S/390 (emulated) support is lacking even basic CPU setup, interrupts handling, etc (but will startup and write a message to a 3270 terminal)
- a Raspberry board is only able to start the first core and pulse a GPIO LED

I release SweetAda this way because otherwise I will spend other years in the development without a feedback, and existent codebase shows me enough prospective.

Excuse me for slow download of the packages and toolchains, the website is hosted at my home.

Re: SweetAda 0.1 released

[Fabien Chouteau]

On Tuesday, June 30, 2020 at 6:34:53 PM UTC+2, gabriele....@gmail.com wrote:
> I've just released SweetAda version 0.1.
> 
> SweetAda is a lightweight development environment to create Ada code on a wide range of CPUs and platforms.

Very interesting project Gabriele!

> Excuse me for slow download of the packages and toolchains, the website is hosted at my home.

I would recommend to host your project on GitHub. You can do release with binaries packages that will be hosted on the platform.

Re: SweetAda 0.1 released

[Stéphane Rivière]

Hi Gabriele,

> I've just released SweetAda version 0.1.

I saw your announce yesterday on Ada Linkedin group... Amazing job !

> Feel free to ask me about everything,

Basically, I'll test soon the Linux>AVR environment which comes with GDB...

Now, I had to use a Windows VM to get a functional GDB with a GNAT cross
compiler to AVR (I own an old but reliable jtag ICE MkII)...

>I know that a lot of components are poorly documented and difficult to understand without startup informations. This is a heavy work in progress, the manual is under incomplete >translation and things could be not in-sync.

I saw runsweetada needs at launch a (missing or not seen by me or at
least undocumented) configuration file but I did not dig around that
yesterday, it was late midnight. So instead I've dl the source code to
read it at first this evening :)

> Excuse me for slow download of the packages and toolchains, the website is hosted at my home.

Saw that. No problem. Github - as suggested by Fabien - could also
increase your project visibility...

-- 
Be Seeing You
Number Six

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Wednesday, July 1, 2020 at 11:32:51 AM UTC+2, Fabien Chouteau wrote:
> On Tuesday, June 30, 2020 at 6:34:53 PM UTC+2, gabriele....@gmail.com wrote:
> > I've just released SweetAda version 0.1.
> > 
> > SweetAda is a lightweight development environment to create Ada code on a wide range of CPUs and platforms.
> 
> Very interesting project Gabriele!
> 
> > Excuse me for slow download of the packages and toolchains, the website is hosted at my home.
> 
> I would recommend to host your project on GitHub. You can do release with binaries packages that will be hosted on the platform.

Thank you very much.

It's in the TODO list, with many many other things. For the moment I would like to reach a minimum stable point, otherwise I got confused, because there are countless things to adjust and harmonize. There is a huge amount of development behind SweetAda, e.g. I am still collecting hardware platforms to make everything real, and writing automated scripts for building toolchains and utilities. Strict Ada coding takes only 5% of the whole project effort time.

I know you for your AdaCore fame. By the way, I am looking for a new job. This is why SweetAda exists. ;)

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Wednesday, July 1, 2020 at 1:01:53 PM UTC+2, Stéphane Rivière wrote:
> Hi Gabriele,
> 
> > I've just released SweetAda version 0.1.
> 
> I saw your announce yesterday on Ada Linkedin group... Amazing job !
> 
> > Feel free to ask me about everything,
> 
> Basically, I'll test soon the Linux>AVR environment which comes with GDB...
> 
> Now, I had to use a Windows VM to get a functional GDB with a GNAT cross
> compiler to AVR (I own an old but reliable jtag ICE MkII)...
> 
> >I know that a lot of components are poorly documented and difficult to understand without startup informations. This is a heavy work in progress, the manual is under incomplete >translation and things could be not in-sync.
> 
> I saw runsweetada needs at launch a (missing or not seen by me or at
> least undocumented) configuration file but I did not dig around that
> yesterday, it was late midnight. So instead I've dl the source code to
> read it at first this evening :)
> 
> > Excuse me for slow download of the packages and toolchains, the website is hosted at my home.
> 
> Saw that. No problem. Github - as suggested by Fabien - could also
> increase your project visibility...
> 
> -- 
> Be Seeing You
> Number Six

Hi Stéphane.

I feel very sorry, unfortunately the AVR is the ONLY cpu I can't provide even elementary support, because I am still waiting an hardware board. I promise you effort on that, maybe not just tomorrow morning. I just had no time to build a test emulator environment. Please give me a little bit of time. The AVR toolchain exists because, once I automated the build, I got it nearly for free, and it is an interesting CPU.

Being said that, runsweetada is useful only for the QEMU emulator, so no worries if you plan to work on bare hardware. I know that the manual is missing important pieces, ask me without fear. Please explain me your context in detail, so I can help you.

And thanks for your interest.

Re: SweetAda 0.1 released

[Fabien Chouteau]

On Wednesday, July 1, 2020 at 1:06:24 PM UTC+2, gabriele....@gmail.com wrote:
> By the way, I am looking for a new job. This is why SweetAda exists. ;)

You should have a look here: https://www.adacore.com/company/careers

Re: SweetAda 0.1 released

[Roger]

Looks very interesting.
I have been trying for a few hours to install sweetada on a Mac-mini (2018) but have been unable to.
I haven't been able to figure out the correct install action and build procedure.
I installed the three source packages and installed http://www.sweetada.org/packages/x86_64-sweetada-elf-20200417M.tar.gz into my /opt directory

Re: SweetAda 0.1 released

[Roger]

I also tried on my Mac Air.
Result using build.sh:
MacBook-Air:sweetada-0.1 rogermcmurtrie$ ./menu.sh 
make[1]: *** No rule to make target `all-clean'.  Stop.

PC-x86: configuration file kernel.cfg created successfully.

Installing files for subplatform QEMU-ROM:
Makefile.in
bsp-board_init.adb
configuration.in
configure.ads.in
configure.h.in
linker.lds
qemu-ifdown.sh
qemu-ifup.sh
qemu.cfg
startup-memory.S

fathdcreate.sh: *** Error: unsupported operation.
processcfg.sh: configure.h: done.
processcfg.sh: configure.ads: done.
createconfiguregpr.sh: configure.gpr: done.
creategnatadc.sh: gnat.adc: done.

PC-x86: configuration completed.

Configuration parameters:
PLATFORM:         PC-x86
SUBPLATFORM:      QEMU-ROM
CPU:              x86
CPU MODEL:        i586
SWEETADA_PATH:    /Ada_Source/SweetAda/sweetada-0.1
TOOLCHAIN PREFIX: /opt/sweetada
TOOLCHAIN NAME:   x86_64-sweetada-elf
GCC VERSION:      9.3.0
GCC SWITCHES:      -march=i586 -Wa,-march=i586
GCC MULTIDIR:     .
RTS ROOT PATH:    /Ada_Source/SweetAda/sweetada-0.1/rts/x86_64-sweetada-elf
RTS PATH:         /Ada_Source/SweetAda/sweetada-0.1/rts/x86_64-sweetada-elf/.
LD SWITCHES:       
OBJCOPY SWITCHES:  --output-target=binary --gap-fill=0x00
OBJDUMP SWITCHES:  
RTS:              ZFP
PROFILE:          ZFP
BUILD MODE:       MAKEFILE

PC-x86: start kernel build.

[GNATMAKE]   abort_library.adb
x86_64-sweetada-elf-gnatmake: RTS path not valid: missing adainclude and adalib directories
make[1]: *** [../obj/abort_library.o] Error 4
make: *** [kernel_base] Error 2

PC-x86: start kernel build.

[GNATMAKE]   abort_library.adb
x86_64-sweetada-elf-gnatmake: RTS path not valid: missing adainclude and adalib directories
make[1]: *** [../obj/abort_library.o] Error 4
make: *** [kernel_base] Error 2

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Wednesday, July 1, 2020 at 5:00:17 PM UTC+2, Roger wrote:
> Looks very interesting.
> I have been trying for a few hours to install sweetada on a Mac-mini (2018) but have been unable to.
> I haven't been able to figure out the correct install action and build procedure.
> I installed the three source packages and installed http://www.sweetada.org/packages/x86_64-sweetada-elf-20200417M.tar.gz into my /opt directory

Sorry Roger. As i said, if I test every bit of SweetAda, another year will go.

I built the OSX toolchains with a cross compiler, then I use a VirtualBox VM running El Capitan 10.11. But chances are that something went out of sync.

Let's try to make a step-by-step.

First of all, download sweetada-0.1a.tar.gz. I change some bits last night in x86_64, last minute patch.
 
You must ended up with the Ada toolchain executables in /opt/sweetada/bin/x86_64-sweetada-elf-[as,gnat,gcc,ld,...]. Try to execute the compiler executables ...-gcc for missing libraries or anything else.

Inside the sweetada source package, edit the menu.sh file.
There are some platform choices. Comment out all the choices and write:
PLATFORM=PC-x86-64 ; SUBPLATFORM=QEMU-ROM

Run menu.sh with "./menu.sh". It should end up compiling without errors.

At this point, you cannot go further because I have still to build QEMU emulator for OSX. But the code is laying in the kernel.rom file. 

There is another subplatform, PC-USBkey, that once upon a time will ***physically*** boot out of a USB key, but you need the "dd" utility online. Honestly, haven't test it recently, but it worked for real.

Please let me know which is the very first point that is failing, possibly with an error description.

Best regards.

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Wednesday, July 1, 2020 at 5:30:10 PM UTC+2, Roger wrote:
> I also tried on my Mac Air.
> Result using build.sh:
> MacBook-Air:sweetada-0.1 rogermcmurtrie$ ./menu.sh 
> make[1]: *** No rule to make target `all-clean'.  Stop.
> 

Please give me some hours, I'll try at home with my virtual machine, now I aint sitting in front of my pc. I'll try to replicate all the installation steps.

That said:

1)
If you donwload x86_64 toolchain, you have to select an 86_64 target, not an ***x86*** one.
2)
Errors from fathdcreate is normal. As I just said in the previous post, you have to install the "dd" utility in your PC. Honestly, the OS X support is very basic.

Hope to come back soon.

Re: SweetAda 0.1 released

[Stéphane Rivière]

Hi Gabriele,

> I feel very sorry, unfortunately the AVR is the ONLY cpu I can't provide even elementary support, because I am still waiting an hardware board.

No problem. May be it's an opportunity to help each other...

Any small arduino board could fit at nearly no expanse.

To give you a perspective of the various existing development
environments for AVR and Ada :
https://stef.genesix.org/pub/ada/embedded_AVR-Ada_%20Setup_v29.pdf

> I promise you effort on that, maybe not just tomorrow morning. I just had no time to build a test emulator environment. Please give me a little bit of time. The AVR toolchain exists because, once I automated the build, I got it nearly for free, and it is an interesting CPU.

I understand, I have to reactivate mine too :)

> Being said that, runsweetada is useful only for the QEMU emulator, so no worries if you plan to work on bare hardware. 

That's the case... Bare Metal only...

There is also AVR emulators under Linux like
https://github.com/buserror/simavr for particular needs.

I know that the manual is missing important pieces, ask me without fear.
Please explain me your context in detail, so I can help you.

Many thanks !

> And thanks for your interest.

You're welcome ! Your project is a motivating one.

-- 
Be Seeing You
Number Six

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Wednesday, July 1, 2020 at 6:57:33 PM UTC+2, Stéphane Rivière wrote:
> Hi Gabriele,
> 
> > I feel very sorry, unfortunately the AVR is the ONLY cpu I can't provide even elementary support, because I am still waiting an hardware board.
> 
> No problem. May be it's an opportunity to help each other...
> 
> Any small arduino board could fit at nearly no expanse.
> 
> To give you a perspective of the various existing development
> environments for AVR and Ada :
> https://stef.genesix.org/pub/ada/embedded_AVR-Ada_%20Setup_v29.pdf
> 
> > I promise you effort on that, maybe not just tomorrow morning. I just had no time to build a test emulator environment. Please give me a little bit of time. The AVR toolchain exists because, once I automated the build, I got it nearly for free, and it is an interesting CPU.
> 
> I understand, I have to reactivate mine too :)
> 
> > Being said that, runsweetada is useful only for the QEMU emulator, so no worries if you plan to work on bare hardware. 
> 
> That's the case... Bare Metal only...
> 
> There is also AVR emulators under Linux like
> https://github.com/buserror/simavr for particular needs.
> 
> I know that the manual is missing important pieces, ask me without fear.
> Please explain me your context in detail, so I can help you.
> 
> Many thanks !
> 
> > And thanks for your interest.
> 
> You're welcome ! Your project is a motivating one.
> 
> -- 
> Be Seeing You
> Number Six

Yeah, I know about arduino and the like. Just hadn't the time.

Good news for you, I hope.
For me a little less.

As a matter of fact, I just run an Ada fragment under simavr. Quick and dirty. GDB support. But there is absolutely nothing other than this. The code does nothing, it crash for surely on real hardware due to absent stack setup or something like this. But GDB connected to simavr shows instruction execution.

There are some things to adjust and/or to correct in the future, but for the moment I will deprecate quality w.r.t. your needs. Stay tuned and prepare yourself to download a new pre-pre-alpha of SweetAda in the next 24hrs.

Bye

Re: SweetAda 0.1 released

[Roger]

> Sorry Roger. As i said, if I test every bit of SweetAda, another year will go.
No problem. Thanks for the prompt reply. I will be glad to help with your development.
> I built the OSX toolchains with a cross compiler, then I use a VirtualBox VM running El Capitan 10.11. But chances are that something went out of sync.
> My Mac-mini uses OSX Catalina 0.15.5
My Mac Air uses OSX  El Capitan

> Let's try to make a step-by-step.
> 
> First of all, download sweetada-0.1a.tar.gz. I change some bits last night in x86_64, last minute patch.
I also redownloaded http://www.sweetada.org/packages/x86_64-sweetada-elf-20200417M.tar.gz and reinstalled that in /opt 
> You must ended up with the Ada toolchain executables in /opt/sweetada/bin/x86_64-sweetada-elf-[as,gnat,gcc,ld,...]. Try to execute the compiler executables ...-gcc for missing libraries or anything else.
> 
Result of attempted compilation:
Roger@Rogers-Mac-mini bin % ./x86_64-sweetada-elf-gcc -c /opt/test/src/a_dot.adb
fatal error, run-time library not installed correctly
cannot locate file system.ads
compilation abandoned

I do have  system.ads in /opt/GNAT/2020/lib/gcc/x86_64-apple-darwin17.7.0/8.4.1/rts-native/adainclude
Best regards,
Roger

Re: SweetAda 0.1 released

[Roger]

On Thursday, July 2, 2020 at 2:21:28 PM UTC+10, Roger wrote:
> I do have  system.ads in /opt/GNAT/2020/lib/gcc/x86_64-apple-darwin17.7.0/8.4.1/rts-native/adainclude

I forgot to reinstall http://www.sweetada.org/packages/sweetada-rts.tar.gz which I have now done and find system.ads in the rts files.

I tried copying `sweetada-0.1/rts/x86_64-sweetada-elf/adainclude` into `/opt/sweetada/x86_64-sweetada-elf`  but still got the `"cannot locate file system.ads"`  message.

> Best regards,
> Roger

Re: SweetAda 0.1 released

[Roger]

On Thursday, July 2, 2020 at 1:37:14 AM UTC+10, gabriele....@gmail.com wrote:
>
> 
> Inside the sweetada source package, edit the menu.sh file.
> There are some platform choices. Comment out all the choices and write:
> PLATFORM=PC-x86-64 ; SUBPLATFORM=QEMU-ROM
> 
> Run menu.sh with "./menu.sh". It should end up compiling without errors.
> 
Result:
Configuration parameters:
PLATFORM:         PC-x86-64
SUBPLATFORM:      QEMU-ROM
CPU:              x86-64
CPU MODEL:        ???
SWEETADA_PATH:    /System/Volumes/Data/Ada_Source/sweetada-0.1
TOOLCHAIN PREFIX: /opt/sweetada
TOOLCHAIN NAME:   x86_64-sweetada-elf
GCC VERSION:      9.3.0
GCC SWITCHES:      -m64 -Wa,--64
GCC MULTIDIR:     .
RTS ROOT PATH:    /System/Volumes/Data/Ada_Source/sweetada-0.1/rts/x86_64-sweetada-elf
RTS PATH:         /System/Volumes/Data/Ada_Source/sweetada-0.1/rts/x86_64-sweetada-elf/.
LD SWITCHES:       
OBJCOPY SWITCHES:  --output-target=binary --gap-fill=0x00
OBJDUMP SWITCHES:  
RTS:              ZFP
PROFILE:          ZFP
BUILD MODE:       MAKEFILE

PC-x86-64: start kernel build.

[GNATMAKE]   abort_library.adb
...

then build continued until:
[GNATMAKE-M] kernel.d
[ADAC]       b__main.adb
[LD]         kernel.o
[OBJDUMP]    kernel.lst
[OBJDUMP-S]  kernel.src.lst
[READELF]    kernel.elf.lst

PC-x86-64: ELF sections dump.

make: elftool: No such file or directory
make: *** [kernel_info] Error 1

PC-x86-64: start kernel build.

[GNATMAKE]   main.adb
[GNATBIND]   b__main.adb
[GNATMAKE-M] kernel.d
[ADAC]       b__main.adb
[LD]         kernel.o
[OBJDUMP]    kernel.lst
[OBJDUMP-S]  kernel.src.lst
[READELF]    kernel.elf.lst

PC-x86-64: ELF sections dump.

make: elftool: No such file or directory
make: *** [kernel_info] Error 1

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Thursday, July 2, 2020 at 6:47:48 AM UTC+2, Roger wrote:
> On Thursday, July 2, 2020 at 1:37:14 AM UTC+10, gabriele....@gmail.com wrote:
> >
> > 
> > Inside the sweetada source package, edit the menu.sh file.
> > There are some platform choices. Comment out all the choices and write:
> > PLATFORM=PC-x86-64 ; SUBPLATFORM=QEMU-ROM
> > 
> > Run menu.sh with "./menu.sh". It should end up compiling without errors.
> > 
> Result:
> Configuration parameters:
> PLATFORM:         PC-x86-64
> SUBPLATFORM:      QEMU-ROM
> CPU:              x86-64
> CPU MODEL:        ???
> SWEETADA_PATH:    /System/Volumes/Data/Ada_Source/sweetada-0.1
> TOOLCHAIN PREFIX: /opt/sweetada
> TOOLCHAIN NAME:   x86_64-sweetada-elf
> GCC VERSION:      9.3.0
> GCC SWITCHES:      -m64 -Wa,--64
> GCC MULTIDIR:     .
> RTS ROOT PATH:    /System/Volumes/Data/Ada_Source/sweetada-0.1/rts/x86_64-sweetada-elf
> RTS PATH:         /System/Volumes/Data/Ada_Source/sweetada-0.1/rts/x86_64-sweetada-elf/.
> LD SWITCHES:       
> OBJCOPY SWITCHES:  --output-target=binary --gap-fill=0x00
> OBJDUMP SWITCHES:  
> RTS:              ZFP
> PROFILE:          ZFP
> BUILD MODE:       MAKEFILE
> 
> PC-x86-64: start kernel build.
> 
> [GNATMAKE]   abort_library.adb
> ...
> 
> then build continued until:
> [GNATMAKE-M] kernel.d
> [ADAC]       b__main.adb
> [LD]         kernel.o
> [OBJDUMP]    kernel.lst
> [OBJDUMP-S]  kernel.src.lst
> [READELF]    kernel.elf.lst
> 
> PC-x86-64: ELF sections dump.
> 
> make: elftool: No such file or directory
> make: *** [kernel_info] Error 1
> 
> PC-x86-64: start kernel build.
> 
> [GNATMAKE]   main.adb
> [GNATBIND]   b__main.adb
> [GNATMAKE-M] kernel.d
> [ADAC]       b__main.adb
> [LD]         kernel.o
> [OBJDUMP]    kernel.lst
> [OBJDUMP-S]  kernel.src.lst
> [READELF]    kernel.elf.lst
> 
> PC-x86-64: ELF sections dump.
> 
> make: elftool: No such file or directory
> make: *** [kernel_info] Error 1

Hi Roger, very fine. I'm happy, thanks for your testing.

The compilation is successful.

elftool is, at this level, more or less a visual tool to dump ELF sections well-formatted and free from annoying text, suitable for a parsing tool. You can find the same informations in the various *.lst being generated in the top level directory (like "kernel.elf.lst")

Your problem is very strange. I verified that elftool is stored in the toolchain package, please check if it exists along other executables. Try to dry-run it in the command line for library problems, even if I am pretty sure it does not require other than the system libc.

Anyway, as a temporary hack, you can comment out elftool execution in the main Makefile. Just put a comment "#" in front of its call, around lines 682/786/798/801, beware of the tabs:
old: <--tab-->@$(ELFTOOL) ...
new: <--tab-->#@$(ELFTOOL) ...

I will try to make available an initial version of QEMU, but please give me a little bit of time. Really you can use a normal QEMU built with x86_64 target, but you lack the IOEMU visual part. From your result, by executing a "make postbuild", you can create a "ROM BIOS" image suitable for the emulator, file "kernel.rom".

Please note that the x86_64 is a large work in progress, not at the same level of the 32-bit counterpart. I am working on it. But you have theoretically an Ada mockup system suitable for experimentation that runs in full 64-bit mode. It should run even on real hardware, with proper support.

Let me know of your progress.

Re: SweetAda 0.1 released

[Roger]

"elftool" is stored in my toolchain package along with the other executables. I ran it successfully  in the command line.

I commented out elftool execution in the main Makefile. 
"menu.sh" then ran successfully to completion.

"make postbuild" then generated "kernel.rom". 

I'm not sure how to proceed but will investigate.
Thanks for the advice.

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Wednesday, July 1, 2020 at 6:57:33 PM UTC+2, Stéphane Rivière wrote:
> Hi Gabriele,
> 
> > I feel very sorry, unfortunately the AVR is the ONLY cpu I can't provide even elementary support, because I am still waiting an hardware board.
> 
> No problem. May be it's an opportunity to help each other...
> 
> Any small arduino board could fit at nearly no expanse.
> 
> To give you a perspective of the various existing development
> environments for AVR and Ada :
> https://stef.genesix.org/pub/ada/embedded_AVR-Ada_%20Setup_v29.pdf
> 
> > I promise you effort on that, maybe not just tomorrow morning. I just had no time to build a test emulator environment. Please give me a little bit of time. The AVR toolchain exists because, once I automated the build, I got it nearly for free, and it is an interesting CPU.
> 
> I understand, I have to reactivate mine too :)
> 
> > Being said that, runsweetada is useful only for the QEMU emulator, so no worries if you plan to work on bare hardware. 
> 
> That's the case... Bare Metal only...
> 
> There is also AVR emulators under Linux like
> https://github.com/buserror/simavr for particular needs.
> 
> I know that the manual is missing important pieces, ask me without fear.
> Please explain me your context in detail, so I can help you.
> 
> Many thanks !
> 
> > And thanks for your interest.
> 
> You're welcome ! Your project is a motivating one.
> 
> -- 
> Be Seeing You
> Number Six

Hi Stéphane.

Have a look at the site. Download sweetada-0.1b.tar.gz and re-download sweetada-rts.tar.gz.

The core package has now an "AVR-simavr" platform. There is nothing, but at least you could verify if it generates code. The RTS has now a complete runtime for AVR, something functional.

Some notably things:

- the GCC front-end does not generate atomic instructions, I think this is due to actual implementation or maybe the lack of that instructions in AVR chips. Chances are the even a C compiler will refuse a similar construct.

- nearly the same reason, in RTS, no 64-bit floats, but this a rather impractical thing to worry about now, since there is no even basic support for other most useful things

- you have to comment out in core/core.ads the "Atomic" aspect in the declaration of Tick_Count, simply put a double dash in front of it. It is obviously not used but ADAC will just complains

Have a look in platforms/AVR-simavr/configuration.in and change whatever you want to suit your needs. I had no time to make a full simavr test, I've only check a GDB connection and it shows something interesting. Check the declaration of the ports. Maybe they need adjustment. Just for the record, I am going to buy an AVR board very soon.

Let me know.

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Thursday, July 2, 2020 at 3:03:31 PM UTC+2, Roger wrote:
> "elftool" is stored in my toolchain package along with the other executables. I ran it successfully  in the command line.
> 
> I commented out elftool execution in the main Makefile. 
> "menu.sh" then ran successfully to completion.
> 
> "make postbuild" then generated "kernel.rom". 
> 
> I'm not sure how to proceed but will investigate.
> Thanks for the advice.

You're welcome.

I would like to solve the elftool problem, but really there is no apparent reason on why it's got not executed. I don't know, maybe something related to your environment. If Makefile executes other executables, it should execute elftool as well. Let's make it an open point.

Wait a little bit for a QEMU emulator. OS X is a very bad beast when cross-compiling is concerned. I had to hack QEMU very hardly, it's not that simple.

Next days I'll try also to write some x86_64 Ada low-level code to make the CPU a little bit usable.

Let me know further progress.

Re: SweetAda 0.1 released

[Stéphane Rivière]

Thanks Gabriele for your reactiveness :)

> Have a look at the site. Download sweetada-0.1b.tar.gz and re-download sweetada-rts.tar.gz.

Fantastic.

> The core package has now an "AVR-simavr" platform. There is nothing, but at least you could verify if it generates code. The RTS has now a complete runtime for AVR, something functional.

Great !

> - nearly the same reason, in RTS, no 64-bit floats, but this a rather impractical thing to worry about now, since there is no even basic support for other most useful things

Floats are not expected in such this platform :)

> Let me know.
> 

I reactivate my AVR platform this weekend and come back to you as soon
as I've tested sweetada-0.1b !!!

-- 
Be Seeing You
Number Six

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Friday, July 3, 2020 at 6:12:54 AM UTC+2, Stéphane Rivière wrote:
> Thanks Gabriele for your reactiveness :)
> 
> > Have a look at the site. Download sweetada-0.1b.tar.gz and re-download sweetada-rts.tar.gz.
> 
> Fantastic.
> 
> > The core package has now an "AVR-simavr" platform. There is nothing, but at least you could verify if it generates code. The RTS has now a complete runtime for AVR, something functional.
> 
> Great !
> 
> > - nearly the same reason, in RTS, no 64-bit floats, but this a rather impractical thing to worry about now, since there is no even basic support for other most useful things
> 
> Floats are not expected in such this platform :)
> 
> > Let me know.
> > 
> 
> I reactivate my AVR platform this weekend and come back to you as soon
> as I've tested sweetada-0.1b !!!
> 
> -- 
> Be Seeing You
> Number Six

You're welcome. Obviously this is a first try, so things could need adjustment.

Edit your configuration, cpu model, etc.
Begin your work by modifying startup.S. Basic cpu setup, setup of the stack pointer. Check linker.lds for memory areas. Once the RAM subsystem is functional, you could enable the calls to adainit and _ada_main. If everything went ok, you end up executing code in Bsp_Setup. Theoretically you have at this point complete control. Even pulse a LED will be a great result.

Anyway, waiting for a physical board, I'll try to build a full-functional simavr so I could write a BSP, and create fundamental infrastructure in the cpu hierarchy.

I'll come back ASAP.

Re: SweetAda 0.1 released

[Roger]

On 3 Jul 2020, at 1:26 am, gabriele.galeotti wrote:

You're welcome.

I would like to solve the elftool problem, but really there is no apparent reason on why it's got not executed. I don't know, maybe something related to your environment. If Makefile executes other executables, it should execute elftool as well. Let's make it an open point.

elftool works when I replace "@$(ELFTOOL)" with "/opt/sweetada/bin/elftool" in the Makefile.

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Saturday, July 4, 2020 at 2:30:58 AM UTC+2, Roger wrote:
> On 3 Jul 2020, at 1:26 am, gabriele.galeotti wrote:
> 
> You're welcome.
> 
> I would like to solve the elftool problem, but really there is no apparent reason on why it's got not executed. I don't know, maybe something related to your environment. If Makefile executes other executables, it should execute elftool as well. Let's make it an open point.
> 
> elftool works when I replace "@$(ELFTOOL)" with "/opt/sweetada/bin/elftool" in the Makefile.

At least we know that elftool runs ok. It's very strange, I double-checked in my OSX VM and it got executed. Ok, we will see.

Some news. Have a look at the site, you can download a very preliminar release of QEMU x86-64 for OSX.

There are two packages.

qemu-x86-64-osx.tar.gz should be uncompressed in /opt/sweetada ... as usual, internal hierarchy is the same.

Then download qemu-libraries-osx.tar.gz. This package, uncompressed in the root filesystem, should end up with some libraries in /usr/local/lib. It's a very rapid solution to make a successful loading. At least in my VM.

When you execute a "/opt/sweetada/bin/make run" in the sweetada directory (after a successful "make all" compilation), chances are that a QEMU will appear. Two windows, the standard one and the IOEMU one. If Ada code is running ok, a LED bar will show you a binary upcounting. It's the image of the hardware parallel port register. Try to slow down by increase the count in application.adb.

I am pretty sure you will receive errors in the log because maybe you have no xterm support, so no serialport support. Also network support is difficult in QEMU under OSX. Try to comment ("#") lines in PC-x86-64/platform/QEMU-ROM/qemu.cfg, else wait for a minor sweetada-core release. If you are in a hurry, download http://www.sweetada.org/packages/qemu.cfg (it's not in web page) and place the file where it should stay.

Sorry, all these things are yet to be documented. Together with a countless other things.

One last thing, please write down and save your work, so you can keep track of your personal changes. As you can see I am in a phase of unavoidable adjustments.

Let me know.

Re: SweetAda 0.1 released

[Roger]

On Sunday, July 5, 2020 at 1:59:21 AM UTC+10, gabriele....@gmail.com wrote:
> Then download qemu-libraries-osx.tar.gz. This package, uncompressed in the root filesystem, should end up with some libraries in /usr/local/lib.
My /usr/local/lib already contained these libraries.

> When you execute a "/opt/sweetada/bin/make run" in the sweetada directory (after a successful "make all" compilation), chances are that a QEMU will appear. 
 "/opt/sweetada/bin/make run" fails with:
 sweetada-0.1 % /opt/sweetada/bin/make run
dyld: Library not loaded: /usr/x86_64-apple-darwin15/x86_64-apple-darwin15/lib/libgcc_s.1.dylib
  Referenced from: /opt/sweetada/bin/elftool
  Reason: image not found
make: *** [Makefile:787: run] Abort trap: 6


> Sorry, all these things are yet to be documented. Together with a countless other things.
I quite understand.
> One last thing, please write down and save your work, so you can keep track of your personal changes. OK.

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Sunday, July 5, 2020 at 4:15:28 AM UTC+2, Roger wrote:
> On Sunday, July 5, 2020 at 1:59:21 AM UTC+10, gabriele....@gmail.com wrote:
> > Then download qemu-libraries-osx.tar.gz. This package, uncompressed in the root filesystem, should end up with some libraries in /usr/local/lib.
> My /usr/local/lib already contained these libraries.
> 
> > When you execute a "/opt/sweetada/bin/make run" in the sweetada directory (after a successful "make all" compilation), chances are that a QEMU will appear. 
>  "/opt/sweetada/bin/make run" fails with:
>  sweetada-0.1 % /opt/sweetada/bin/make run
> dyld: Library not loaded: /usr/x86_64-apple-darwin15/x86_64-apple-darwin15/lib/libgcc_s.1.dylib
>   Referenced from: /opt/sweetada/bin/elftool
>   Reason: image not found
> make: *** [Makefile:787: run] Abort trap: 6
> 
> 
> > Sorry, all these things are yet to be documented. Together with a countless other things.
> I quite understand.
> > One last thing, please write down and save your work, so you can keep track of your personal changes. OK.

Hi Roger.

Please re-download the x86_64-sweetada-elf-20200417M.tar.gz toolchain and overwrite the old one. Now the support executables like elftool are statically linked against the problematic library.

Hope this helps. If QEMU runs, I've prepared a new ioemu.cfg script that allows output to the Terminal app.

Let me know.

Re: SweetAda 0.1 released

[Roger]

On Monday, July 6, 2020 at 7:41:29 AM UTC+10, gabriele....@gmail.com wrote:
 
> Please re-download the x86_64-sweetada-elf-20200417M.tar.gz toolchain and overwrite the old one. Now the support executables like elftool are statically linked against the problematic library.
> 
> Hope this helps. If QEMU runs, I've prepared a new ioemu.cfg script that allows output to the Terminal app.
> 
/opt/sweetada/bin/make run 
runs through to
runsweetada: loading: /System/Volumes/Data/Ada_Source/sweetada-0.1/platforms/PC-x86-64/qemu.cfg
runsweetada: working directory: /System/Volumes/Data/Ada_Source/sweetada-0.1/platforms/PC-x86-64
runsweetada: executing: /opt/sweetada/bin/qemu-system-x86_64
then OK through to

IOEMU: initializing
IOEMU: PPID = 69722
IOEMU: PID  = 69723
qemu-system-x86_64: -device ne2k_pci,netdev=qemu,mac=02:00:00:11:22:33: Property 'ne2k_pci.netdev' can't find value 'qemu'
IOEMU: shutdown
runsweetada: execute_exec(): child pid 69723 exited with status: 1.
runsweetada: *** Error: exec_command() exit status: 1.

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Monday, July 6, 2020 at 5:03:24 AM UTC+2, Roger wrote:
> On Monday, July 6, 2020 at 7:41:29 AM UTC+10, gabriele....@gmail.com wrote:
>  
> > Please re-download the x86_64-sweetada-elf-20200417M.tar.gz toolchain and overwrite the old one. Now the support executables like elftool are statically linked against the problematic library.
> > 
> > Hope this helps. If QEMU runs, I've prepared a new ioemu.cfg script that allows output to the Terminal app.
> > 
> /opt/sweetada/bin/make run 
> runs through to
> runsweetada: loading: /System/Volumes/Data/Ada_Source/sweetada-0.1/platforms/PC-x86-64/qemu.cfg
> runsweetada: working directory: /System/Volumes/Data/Ada_Source/sweetada-0.1/platforms/PC-x86-64
> runsweetada: executing: /opt/sweetada/bin/qemu-system-x86_64
> then OK through to
> 
> IOEMU: initializing
> IOEMU: PPID = 69722
> IOEMU: PID  = 69723
> qemu-system-x86_64: -device ne2k_pci,netdev=qemu,mac=02:00:00:11:22:33: Property 'ne2k_pci.netdev' can't find value 'qemu'
> IOEMU: shutdown
> runsweetada: execute_exec(): child pid 69723 exited with status: 1.
> runsweetada: *** Error: exec_command() exit status: 1.

Re-download http://www.sweetada.org/packages/qemu.cfg

As a general advice, you can comment problematic lines in that file with a "#". The new version should allow to run a terminal and see the characters "XYZ" appear.

Let me know.

Re: SweetAda 0.1 released

[Roger]

On Monday, July 6, 2020 at 6:36:40 PM UTC+10, gabriele....@gmail.com wrote:
> Re-download http://www.sweetada.org/packages/qemu.cfg

Getting closer!
After /opt/sweetada/bin/make run,  qemu-system-x86_64 ran and two windows opened via:

Roger@Rogers-Mac-mini ~ %  telnet 127.0.0.1 4447
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

However, after a few seconds QMEU crashed with:
2020-07-06 21:25:50.423 qemu-system-x86_64[36318:3118137] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'nextEventMatchingMask should only be called from the Main Thread!'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff320e0be7 __exceptionPreprocess + 250
	1   libobjc.A.dylib                     0x00007fff6aeb85bf objc_exception_throw + 48
	2   AppKit                              0x00007fff2f2d8b65 +[NSEvent _discardTrackingAndCursorEventsIfNeeded] + 0
	3   libioemu.dylib                      0x00000001038fc7c6 panel_eventloop + 134
	4   libioemu.dylib                      0x00000001038fa454 IOEMU_panel_processevent + 9
	5   qemu-system-x86_64                  0x00000001000f0e42 qemu-system-x86_64 + 986690
)
libc++abi.dylib: terminating with uncaught exception of type NSException
runsweetada: execute_exec(): child pid 36318 got unhandled signal 6 (Abort trap: 6).
runsweetada: *** Error: exec_command() exit status: 134.
runsweetada: exit status = 1

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Monday, July 6, 2020 at 1:30:32 PM UTC+2, Roger wrote:
> On Monday, July 6, 2020 at 6:36:40 PM UTC+10, gabriele....@gmail.com wrote:
> > Re-download http://www.sweetada.org/packages/qemu.cfg
> 
> Getting closer!
> After /opt/sweetada/bin/make run,  qemu-system-x86_64 ran and two windows opened via:
> 
> Roger@Rogers-Mac-mini ~ %  telnet 127.0.0.1 4447
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> However, after a few seconds QMEU crashed with:
> 2020-07-06 21:25:50.423 qemu-system-x86_64[36318:3118137] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'nextEventMatchingMask should only be called from the Main Thread!'
> *** First throw call stack:
> (
> 	0   CoreFoundation                      0x00007fff320e0be7 __exceptionPreprocess + 250
> 	1   libobjc.A.dylib                     0x00007fff6aeb85bf objc_exception_throw + 48
> 	2   AppKit                              0x00007fff2f2d8b65 +[NSEvent _discardTrackingAndCursorEventsIfNeeded] + 0
> 	3   libioemu.dylib                      0x00000001038fc7c6 panel_eventloop + 134
> 	4   libioemu.dylib                      0x00000001038fa454 IOEMU_panel_processevent + 9
> 	5   qemu-system-x86_64                  0x00000001000f0e42 qemu-system-x86_64 + 986690
> )
> libc++abi.dylib: terminating with uncaught exception of type NSException
> runsweetada: execute_exec(): child pid 36318 got unhandled signal 6 (Abort trap: 6).
> runsweetada: *** Error: exec_command() exit status: 134.
> runsweetada: exit status = 1

Hi Roger.

Fine. Unfortunately this is a difficult issue to solve. QEMU (and maybe Cocoa) has changed his policy about the GUI in OSX. It's a problem I don't see because I am stuck with El Capitan 10.11. The IOEMU window runs in another thread and so a crash happens.

Anyway, if it is pleasant for you, you have a decent toolchain setup now. I will try to solve the QEMU issue, just don't hold your breath.

Maybe next days I will release a QEMU version for you without the IOEMU window in order to check if it's running Ada code correctly, by using the serialport terminals, waiting for a definitive solution.

I'll come back ASAP.

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Monday, July 6, 2020 at 1:30:32 PM UTC+2, Roger wrote:
> On Monday, July 6, 2020 at 6:36:40 PM UTC+10, gabriele....@gmail.com wrote:
> > Re-download http://www.sweetada.org/packages/qemu.cfg
> 
> Getting closer!
> After /opt/sweetada/bin/make run,  qemu-system-x86_64 ran and two windows opened via:
> 
> Roger@Rogers-Mac-mini ~ %  telnet 127.0.0.1 4447
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> However, after a few seconds QMEU crashed with:
> 2020-07-06 21:25:50.423 qemu-system-x86_64[36318:3118137] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'nextEventMatchingMask should only be called from the Main Thread!'
> *** First throw call stack:
> (
> 	0   CoreFoundation                      0x00007fff320e0be7 __exceptionPreprocess + 250
> 	1   libobjc.A.dylib                     0x00007fff6aeb85bf objc_exception_throw + 48
> 	2   AppKit                              0x00007fff2f2d8b65 +[NSEvent _discardTrackingAndCursorEventsIfNeeded] + 0
> 	3   libioemu.dylib                      0x00000001038fc7c6 panel_eventloop + 134
> 	4   libioemu.dylib                      0x00000001038fa454 IOEMU_panel_processevent + 9
> 	5   qemu-system-x86_64                  0x00000001000f0e42 qemu-system-x86_64 + 986690
> )
> libc++abi.dylib: terminating with uncaught exception of type NSException
> runsweetada: execute_exec(): child pid 36318 got unhandled signal 6 (Abort trap: 6).
> runsweetada: *** Error: exec_command() exit status: 134.
> runsweetada: exit status = 1

Hi Roger, again.

If you want, please download:

http://www.sweetada.org/packages/qemu-system-x86_64
http://www.sweetada.org/packages/libioemu.dylib

and replace the same files in your filesystem (maybe do a backup of the old two).

Let me know if the situation changes to something good.

Re: SweetAda 0.1 released

[Roger]

On Tuesday, July 7, 2020 at 2:13:33 AM UTC+10, gabriele....@gmail.com wrote:
> If you want, please download:
> 
> http://www.sweetada.org/packages/qemu-system-x86_64
> http://www.sweetada.org/packages/libioemu.dylib
> 
> and replace the same files in your filesystem (maybe do a backup of the old two).
> 
>
 The new qemu-system-x86_64 failed with an exec() not found mesage;
but, with the previous version, on replacing libioemu.dylib, qemu-system-x86_64 worked with two windows being displayed.
I haven't tried to do anything with it yet.
Your prompt expert attention is very much appreciated.
Thanks,
Roger

Re: SweetAda 0.1 released

[Roger]

Although /opt/sweetada/bin/make run produced IOEMU and QEMU windows neither of those or the menu bar was responsive.
The terminal window associated with one of them did respond with XYZ.

When I get the QEMU window to go full-screen it contains the message:
Guest has not initialized the display (yet)

I also tried running toolchain tools directly, such as qemu-img, but they failed with 
dyld: Library not loaded: /usr/x86_64-apple-darwin15/darwin/usr/local/lib/libgthread-2.0.0.dylib
  Referenced from: /opt/sweetada/bin/qemu-img
  Reason: image not found

Also:
/opt/sweetada/bin/x86_64-sweetada-elf-gnatmake    
fatal error, run-time library not installed correctly
cannot locate file system.ads
raised TYPES.UNRECOVERABLE_ERROR : targparm.adb:183

x86_64-sweetada-elf-gnatmake: INTERNAL ERROR. Please report.

Hoping this helps
Roger

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Tuesday, July 7, 2020 at 9:20:34 AM UTC+2, Roger wrote:
> Although /opt/sweetada/bin/make run produced IOEMU and QEMU windows neither of those or the menu bar was responsive.
> The terminal window associated with one of them did respond with XYZ.
> 
> When I get the QEMU window to go full-screen it contains the message:
> Guest has not initialized the display (yet)
> 
> I also tried running toolchain tools directly, such as qemu-img, but they failed with 
> dyld: Library not loaded: /usr/x86_64-apple-darwin15/darwin/usr/local/lib/libgthread-2.0.0.dylib
>   Referenced from: /opt/sweetada/bin/qemu-img
>   Reason: image not found
> 
> Also:
> /opt/sweetada/bin/x86_64-sweetada-elf-gnatmake    
> fatal error, run-time library not installed correctly
> cannot locate file system.ads
> raised TYPES.UNRECOVERABLE_ERROR : targparm.adb:183
> 
> x86_64-sweetada-elf-gnatmake: INTERNAL ERROR. Please report.
> 
> Hoping this helps
> Roger

If you see the XYZ characters on a terminal, then QEMU is running fine, and you are seeing CPU sending characters through a serial port. You don't see other things because there is nothing else on the terminal, as I said SweetAda is essentially a framework and the code does very little. The main window of QEMU does display the VGA screen of the emulated platform, which is not used. IOEMU should display a pulsing 8-bit register (the CPU is in a loop counting forever), but if it didn't maybe there are some GUI problems yet to solve.

If you want to execute the toolchain directly, then you have to know exactly what you want. You can call GNATMAKE, but then you have to supply the RTS location, compiler switches and the source files of your project. If you aren't an embedded Ada developer, then there is no point in doing that.

My feeling is that, after many test (sorry), you could have a corrupted environment, since does sound strange to me that you have errors in running the new QEMU executable and the new libioemu library.

Being said that, try to annotate your work and wait for me to collect further info from other OSX users, so we can understand better where potential QEMU problems could arise.

I appreciate your interest.

Re: SweetAda 0.1 released

[Stéphane Rivière]

Hi Gabriele,

I finally found time to restore my AVR dev setup.

While I was writing an install script for SweetAda-AVR (before testing
it), it appears (from different IP used to check) that your website is
now really unstable, specifically when download big files like
avr-sweetada-elf-20200417L.tar.xz

I have to use some dirty tricks like "--timeout=1 --waitretry=0
--tries=1000 --continue" with wget to speed up and improve downloading
(keeping parts already downloaded and modify default retry strategy).

For example, at 71% completed, I already experiment 143 connexions loss
(and then  retries)... The average dl rate is now around 35 Kbps...

For the records (and others sweetada users), a wget command facing this
problem could be :

----------------
wget --timeout=1 --waitretry=0 --tries=1000 --continue
http://www.sweetada.org/packages/<FILE_TO_DL>
----------------

--waitretry=0 ensure a (timeout * tries) timing instead of (tries *
timeout + 1 + 2 + ... + (tries - 1)) - a far more longer timing.

-- 
Be Seeing You
Number Six

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Tuesday, July 7, 2020 at 10:45:38 AM UTC+2, Stéphane Rivière wrote:
> Hi Gabriele,
> 
> I finally found time to restore my AVR dev setup.
> 
> While I was writing an install script for SweetAda-AVR (before testing
> it), it appears (from different IP used to check) that your website is
> now really unstable, specifically when download big files like
> avr-sweetada-elf-20200417L.tar.xz
> 
> I have to use some dirty tricks like "--timeout=1 --waitretry=0
> --tries=1000 --continue" with wget to speed up and improve downloading
> (keeping parts already downloaded and modify default retry strategy).
> 
> For example, at 71% completed, I already experiment 143 connexions loss
> (and then  retries)... The average dl rate is now around 35 Kbps...
> 
> For the records (and others sweetada users), a wget command facing this
> problem could be :
> 
> ----------------
> wget --timeout=1 --waitretry=0 --tries=1000 --continue
> http://www.sweetada.org/packages/<FILE_TO_DL>
> ----------------
> 
> --waitretry=0 ensure a (timeout * tries) timing instead of (tries *
> timeout + 1 + 2 + ... + (tries - 1)) - a far more longer timing.
> 
> -- 
> Be Seeing You
> Number Six

Thanks Stéphane, I am experiencing problems not only with internet connection, also SMTP provider is behaving bad, and the forum could not respond to account request. Now I have to restart the modem. Wait some time before trying to reconnect, sweetada.org is under dynamic IP DNS.
Thanks a lot, and let me know of every problem you can notice.

Re: SweetAda 0.1 released

[Stéphane Rivière]

> Thanks Stéphane, I am experiencing problems not only with internet connection, also SMTP provider is behaving bad, and the forum could not respond to account request. Now I have to restart the modem. Wait some time before trying to reconnect, sweetada.org is under dynamic IP DNS.

I understand. Not easy for you.

> Thanks a lot, and let me know of every problem you can notice.

The dl of "insight-avr-sweetada-elf-20200417L.tar.xz" /allways/ fails
around 4% (at bytes : 1932170 / 1933239)...
Strange...

-- 
Be Seeing You
Number Six

Re: SweetAda 0.1 released

[Roger]

On Tuesday, July 7, 2020 at 6:13:15 PM UTC+10, gabriele....@gmail.com wrote:
> 
> If you see the XYZ characters on a terminal, then QEMU is running fine, and you are seeing CPU sending characters through a serial port. You don't see other things because there is nothing else on the terminal, as I said SweetAda is essentially a framework and the code does very little. The main window of QEMU does display the VGA screen of the emulated platform, which is not used. IOEMU should display a pulsing 8-bit register (the CPU is in a loop counting forever), but if it didn't maybe there are some GUI problems yet to solve.
> 
> If you want to execute the toolchain directly, then you have to know exactly what you want. You can call GNATMAKE, but then you have to supply the RTS location, compiler switches and the source files of your project. If you aren't an embedded Ada developer, then there is no point in doing that.
> 
> My feeling is that, after many test (sorry), you could have a corrupted environment, since does sound strange to me that you have errors in running the new QEMU executable and the new libioemu library.
> 
> Being said that, try to annotate your work and wait for me to collect further info from other OSX users, so we can understand better where potential QEMU problems could arise.
> 
> I appreciate your interest.

Thanks for your advice.
I'll try and investigate further.

Re: SweetAda 0.1 released

[Stéphane Rivière]

Finally, using on of our Italian VPN, I got it ;)

-- 
Be Seeing You
Number Six

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Tuesday, July 7, 2020 at 6:29:40 PM UTC+2, Stéphane Rivière wrote:
> Finally, using on of our Italian VPN, I got it ;)
> 
> -- 
> Be Seeing You
> Number Six

Hi Stéphane, I am very happy.

I restart everything, I think that the modem was going pretty unusable because it is nearly six months that it's running full-time.
Perhaps I solved also mail problems in the forum, even if I have to switch SMTP to my google account. Not sure, though.
I am releasing 0.1c, mostly for changes in the RISC-V platform, which is running Ada code and is now more usable. Other minor corrections, but for you nothing should change, so you can continue. Anyway, in this preliminary phase I kindly recommend to save your work, so you won't have to restart from scratch on every version.
Sorry, this initial phase will be a little bit convulse. I hope to stabilizing things and change the overall handling of SweetAda.
Best regards.

PS
Maybe I'll make a whole new post to explain other more generic things, so let's continue there.

Re: SweetAda 0.1 released

[Stéphane Rivière]

> I restart everything, I think that the modem was going pretty unusable because it is nearly six months that it's running full-time.
> Perhaps I solved also mail problems in the forum, even if I have to switch SMTP to my google account. Not sure, though.

In France, xDSL comes often with port 25 blocked...

> I am releasing 0.1c, mostly for changes in the RISC-V platform, which is running Ada code and is now more usable. Other minor corrections, but for you nothing should change, so you can continue. Anyway, in this preliminary phase I kindly recommend to save your work, so you won't have to restart from scratch on every version.

I'm currently writing a full script install (Ubuntu/Debian style).

> Sorry, this initial phase will be a little bit convulse. I hope to stabilizing things and change the overall handling of SweetAda.

No problem.
I'll contact you by mail as I have some attachments for you...

-- 
Be Seeing You
Number Six

Re: SweetAda 0.1 released

[Roger]

I solved the elftool problem quite easily by simply adding /opt/sweetada/bin to my PATH!
So not a real problem at all. Just me being a bit slow in taking an indepth look at the problem!

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

Hi Roger.

Nice. However it's pretty strange, because elftool get the same PATH as other executables. I guess you are trying to execute it from the outside of SweetAda.

I released preliminary QEMU OSX for other platforms, so let's wait for other users' experience in order to gain informations and confidence about the setup.

See you soon.

Re: SweetAda 0.1 released

[Roger]

On Friday, July 10, 2020 at 5:50:42 AM UTC+10, gabriele....@gmail.com wrote:
> Hi Roger.
> 
> Nice. However it's pretty strange, because elftool get the same PATH as other executables. I guess you are trying to execute it from the outside of SweetAda.
> 

The problem occurs when running menu.sh.
I decided that updating PATH was needed after finding the declaration of ELFTOOL at Makefile.tc.in which does not provide a path for either : gprbuild or elftool:
GPRBUILD := gprbuild$(EXEEXT)
ELFTOOL  := elftool$(EXEEXT)
GDB      := $(TOOLCHAIN_GDB)

There's a possibilty that the wrong gprbuild may be used as no path is declared for GPRBUILD but may be using /opt/GNAT/2020/bin/gprbuild?
I was thinking of adding the /opt/sweetada/bin/path to these declarations in Makefile.tc.in.

Re: SweetAda 0.1 released

[Roger]

On Friday, July 10, 2020 at 10:24:41 AM UTC+10, Roger wrote:
> On Friday, July 10, 2020 at 5:50:42 AM UTC+10, gabriele....@gmail.com wrote:
> > Hi Roger.
> > 
> > Nice. However it's pretty strange, because elftool get the same PATH as other executables. I guess you are trying to execute it from the outside of SweetAda.
> > 
> 
> The problem occurs when running menu.sh.
> I decided that updating PATH was needed after finding the declaration of ELFTOOL at Makefile.tc.in which does not provide a path for either : gprbuild or elftool:
> GPRBUILD := gprbuild$(EXEEXT)
> ELFTOOL  := elftool$(EXEEXT)
> GDB      := $(TOOLCHAIN_GDB)
> 
> There's a possibilty that the wrong gprbuild may be used as no path is declared for GPRBUILD but may be using /opt/GNAT/2020/bin/gprbuild?
> I was thinking of adding the /opt/sweetada/bin/path to these declarations in Makefile.tc.in.

After further investigation I have removed /opt/sweetada/bin from my PATH and have modified my Makefile.tc.in to:

> GPRBUILD := $(TOOLCHAIN_PREFIX)/bin/gprbuild$(EXEEXT)
> ELFTOOL  := $(TOOLCHAIN_PREFIX)/bin/elftool$(EXEEXT)
> GDB      := $(TOOLCHAIN_GDB)

I think that other tools use  TOOLCHAIN_PROGRAM_PREFIX: x86_64-sweetada-elf-
resulting in commands such as : x86_64-sweetada-elf-gcc
which is in the same directory as elftool,  so why  ELFTOOL  := elftool$(EXEEXT) doesn't work remains a mystery to me.

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Friday, July 10, 2020 at 8:44:13 AM UTC+2, Roger wrote:
> On Friday, July 10, 2020 at 10:24:41 AM UTC+10, Roger wrote:
> > On Friday, July 10, 2020 at 5:50:42 AM UTC+10, gabriele....@gmail.com wrote:
> > > Hi Roger.
> > > 
> > > Nice. However it's pretty strange, because elftool get the same PATH as other executables. I guess you are trying to execute it from the outside of SweetAda.
> > > 
> > 
> > The problem occurs when running menu.sh.
> > I decided that updating PATH was needed after finding the declaration of ELFTOOL at Makefile.tc.in which does not provide a path for either : gprbuild or elftool:
> > GPRBUILD := gprbuild$(EXEEXT)
> > ELFTOOL  := elftool$(EXEEXT)
> > GDB      := $(TOOLCHAIN_GDB)
> > 
> > There's a possibilty that the wrong gprbuild may be used as no path is declared for GPRBUILD but may be using /opt/GNAT/2020/bin/gprbuild?
> > I was thinking of adding the /opt/sweetada/bin/path to these declarations in Makefile.tc.in.
> 
> After further investigation I have removed /opt/sweetada/bin from my PATH and have modified my Makefile.tc.in to:
> 
> > GPRBUILD := $(TOOLCHAIN_PREFIX)/bin/gprbuild$(EXEEXT)
> > ELFTOOL  := $(TOOLCHAIN_PREFIX)/bin/elftool$(EXEEXT)
> > GDB      := $(TOOLCHAIN_GDB)
> 
> I think that other tools use  TOOLCHAIN_PROGRAM_PREFIX: x86_64-sweetada-elf-
> resulting in commands such as : x86_64-sweetada-elf-gcc
> which is in the same directory as elftool,  so why  ELFTOOL  := elftool$(EXEEXT) doesn't work remains a mystery to me.

Hi Roger, sorry for the delay, I have a very hard time correcting various thing for make sweetada more useful.

Thank you very much for your investigation.

Maybe you are right, I did not understand that you get another gprbuild installed in your system. Chances are that the wrong one is called from scripts due to paths.

I will try to elaborate on that, keeping in mind your considerations. See you soon.

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Friday, July 10, 2020 at 8:44:13 AM UTC+2, Roger wrote:
> On Friday, July 10, 2020 at 10:24:41 AM UTC+10, Roger wrote:
> > On Friday, July 10, 2020 at 5:50:42 AM UTC+10, gabriele....@gmail.com wrote:
> > > Hi Roger.
> > > 
> > > Nice. However it's pretty strange, because elftool get the same PATH as other executables. I guess you are trying to execute it from the outside of SweetAda.
> > > 
> > 
> > The problem occurs when running menu.sh.
> > I decided that updating PATH was needed after finding the declaration of ELFTOOL at Makefile.tc.in which does not provide a path for either : gprbuild or elftool:
> > GPRBUILD := gprbuild$(EXEEXT)
> > ELFTOOL  := elftool$(EXEEXT)
> > GDB      := $(TOOLCHAIN_GDB)
> > 
> > There's a possibilty that the wrong gprbuild may be used as no path is declared for GPRBUILD but may be using /opt/GNAT/2020/bin/gprbuild?
> > I was thinking of adding the /opt/sweetada/bin/path to these declarations in Makefile.tc.in.
> 
> After further investigation I have removed /opt/sweetada/bin from my PATH and have modified my Makefile.tc.in to:
> 
> > GPRBUILD := $(TOOLCHAIN_PREFIX)/bin/gprbuild$(EXEEXT)
> > ELFTOOL  := $(TOOLCHAIN_PREFIX)/bin/elftool$(EXEEXT)
> > GDB      := $(TOOLCHAIN_GDB)
> 
> I think that other tools use  TOOLCHAIN_PROGRAM_PREFIX: x86_64-sweetada-elf-
> resulting in commands such as : x86_64-sweetada-elf-gcc
> which is in the same directory as elftool,  so why  ELFTOOL  := elftool$(EXEEXT) doesn't work remains a mystery to me.

Hi Roger.

I would like to investigate a little bit more. Sorry if I am writing trivial things, it's just to keep ourselves synchronized.

I assume you download 0.1c, but only minor unrelated thing changes, the same holds for 0.1.

First of all, toolchains for Windows and OSX have a GNU make as part of the toolchain. Windows does not have such thing (unless you install MSYS/Cygwin), while for OSX you have to install Xcode. I want sweetada to be as independent as possible, that's why you can find the GNU make in the package.

All begins in menu.sh.

sweetada development could be performed in a shell with a PATH wich has /opt/sweetada/bin (or whatever is the installation prefix) added in front of its current content (so to override other potential clashes). menu.sh is a shortcut and nothing else.

Please note that once you have a correct PATH, you could issues shell commands like "make all", etc etc, without calling menu.sh. In order to obey to the least surprise principle, stay in the sweetada source code directory.

So you call menu.sh. But menu.sh doesn't know where you really install the toolchain. In the case of OSX, there is a guess in the standard prefix, i.e. /opt/sweetada/bin.

The particular make in that directory is thus called.

So, the first thing is checking if menu.sh detect "darwin" as a legal os. Try to "echo $OSTYPE" inside the script. Be sure that MAKE is set to the GNU make 
which is located inside the toolchain.

Maybe I could add a read of the master configuration.in to import settings, I will think about it.

Once menu.sh calls the Makefile, everything should be handled correctly. If the configuration.in is correctly configured, Makefile will build a PATH with the sweetada toolchain as the first path to look in, so it will have no problems in calling executables. GPRBUILD or ELFTOOL are called exactly like the compiler, so there is no point in prepend anything.

The reason why ELFTOOL != elftool is honestly rather inexplicable, because if the current OSTYPE is set to "darwin", then EXEEXT evaluates to empty, so ELFTOOL should end up in simply "elftool".

That's how things should work. Try to insert a line like
$(info $(<varname)) in the Makefiles in order to dump some variable, maybe it could help.

Let me know, I will continue to check also in my environment.

Re: SweetAda 0.1 released

[Roger]

On Sunday, July 12, 2020 at 2:18:19 AM UTC+10, gabriele....@gmail.com wrote:

> 
> I would like to investigate a little bit more. Sorry if I am writing trivial things, it's just to keep ourselves synchronized.
Not trivial at all.  I am a relative novice with these things. My Unix make experience is quite limited.
> I assume you download 0.1c, but only minor unrelated thing changes, the same holds for 0.1.
Yes, I am using 0.1c.
> First of all, toolchains for Windows and OSX have a GNU make as part of the toolchain. I want sweetada to be as independent as possible, that's why you can find the GNU make in the package.
Seems a good idea.
> All begins in menu.sh.
Understood.  I have been starting with  menu.sh.
> sweetada development could be performed in a shell with a PATH which has /opt/sweetada/bin (or whatever is the installation prefix) added in front of its current content (so to override other potential clashes). menu.sh is a shortcut and nothing else.
Understood.  I note the "could" and the importance of "in front of its current content"
> Please note that once you have a correct PATH, you could issues shell commands like "make all", etc etc, without calling menu.sh. In order to obey to the least surprise principle, stay in the sweetada source code directory.
By " correct PATH", I presume a PATH which has /opt/sweetada/bin in front of its other content.
> So you call menu.sh. But menu.sh doesn't know where you really install the toolchain. In the case of OSX, there is a guess in the standard prefix, i.e. /opt/sweetada/bin.
Noted. TOOLCHAIN_PREFIX := /opt/sweetada is declared in configuration.in
But not  /opt/sweetada/bin; or elsewhere that I can find.
However, the makefile has PATH := $(TOOLCHAIN_PREFIX)/bin:$(PATH) which should do the job.

> The particular make in that directory is thus called.
> 
> So, the first thing is checking if menu.sh detect "darwin" as a legal os. Try to "echo $OSTYPE" inside the script. 
"echo $OSTYPE"  returns "darwin". 

I also added "@$(call echo-command,"PATH:    $(PATH)")" to the Makefile which confirmed that "/opt/sweetada/bin" is at the start of PATH.

Being convinced of this, I removed my prepends for elftool and gprbuild in Makefile.tc.in and menu.sh now WORKS.
>Be sure that MAKE is set to the GNU make 
> which is located inside the toolchain.
> 
> Maybe I could add a read of the master configuration.in to import settings, I will think about it.
> 
> Once menu.sh calls the Makefile, everything should be handled correctly. If the configuration.in is correctly configured, Makefile will build a PATH with the sweetada toolchain as the first path to look in, so it will have no problems in calling executables. GPRBUILD or ELFTOOL are called exactly like the compiler, so there is no point in prepend anything.
> 
> The reason why ELFTOOL != elftool is honestly rather inexplicable, because if the current OSTYPE is set to "darwin", then EXEEXT evaluates to empty, so ELFTOOL should end up in simply "elftool".
> 
> That's how things should work. Try to insert a line like
> $(info $(<varname)) in the Makefiles in order to dump some variable, maybe it could help.
> 
> Let me know, I will continue to check also in my environment.

FIXED! as explained above.
I suspect that some change in 0.1c fixed my problem.
Appologies for the inconvenience.  I should have checked properly  0.1c first.

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Sunday, July 12, 2020 at 4:45:11 AM UTC+2, Roger wrote:
> On Sunday, July 12, 2020 at 2:18:19 AM UTC+10, gabriele....@gmail.com wrote:
> 
> > 
> > I would like to investigate a little bit more. Sorry if I am writing trivial things, it's just to keep ourselves synchronized.
> Not trivial at all.  I am a relative novice with these things. My Unix make experience is quite limited.
> > I assume you download 0.1c, but only minor unrelated thing changes, the same holds for 0.1.
> Yes, I am using 0.1c.
> > First of all, toolchains for Windows and OSX have a GNU make as part of the toolchain. I want sweetada to be as independent as possible, that's why you can find the GNU make in the package.
> Seems a good idea.
> > All begins in menu.sh.
> Understood.  I have been starting with  menu.sh.
> > sweetada development could be performed in a shell with a PATH which has /opt/sweetada/bin (or whatever is the installation prefix) added in front of its current content (so to override other potential clashes). menu.sh is a shortcut and nothing else.
> Understood.  I note the "could" and the importance of "in front of its current content"
> > Please note that once you have a correct PATH, you could issues shell commands like "make all", etc etc, without calling menu.sh. In order to obey to the least surprise principle, stay in the sweetada source code directory.
> By " correct PATH", I presume a PATH which has /opt/sweetada/bin in front of its other content.
> > So you call menu.sh. But menu.sh doesn't know where you really install the toolchain. In the case of OSX, there is a guess in the standard prefix, i.e. /opt/sweetada/bin.
> Noted. TOOLCHAIN_PREFIX := /opt/sweetada is declared in configuration.in
> But not  /opt/sweetada/bin; or elsewhere that I can find.
> However, the makefile has PATH := $(TOOLCHAIN_PREFIX)/bin:$(PATH) which should do the job.
> 
> > The particular make in that directory is thus called.
> > 
> > So, the first thing is checking if menu.sh detect "darwin" as a legal os. Try to "echo $OSTYPE" inside the script. 
> "echo $OSTYPE"  returns "darwin". 
> 
> I also added "@$(call echo-command,"PATH:    $(PATH)")" to the Makefile which confirmed that "/opt/sweetada/bin" is at the start of PATH.
> 
> Being convinced of this, I removed my prepends for elftool and gprbuild in Makefile.tc.in and menu.sh now WORKS.
> >Be sure that MAKE is set to the GNU make 
> > which is located inside the toolchain.
> > 
> > Maybe I could add a read of the master configuration.in to import settings, I will think about it.
> > 
> > Once menu.sh calls the Makefile, everything should be handled correctly. If the configuration.in is correctly configured, Makefile will build a PATH with the sweetada toolchain as the first path to look in, so it will have no problems in calling executables. GPRBUILD or ELFTOOL are called exactly like the compiler, so there is no point in prepend anything.
> > 
> > The reason why ELFTOOL != elftool is honestly rather inexplicable, because if the current OSTYPE is set to "darwin", then EXEEXT evaluates to empty, so ELFTOOL should end up in simply "elftool".
> > 
> > That's how things should work. Try to insert a line like
> > $(info $(<varname)) in the Makefiles in order to dump some variable, maybe it could help.
> > 
> > Let me know, I will continue to check also in my environment.
> 
> FIXED! as explained above.
> I suspect that some change in 0.1c fixed my problem.
> Appologies for the inconvenience.  I should have checked properly  0.1c first.

Fine, Roger. I'm happy to read your post.

Now I would like to clarify the difference between:
- the installation PREFIX, /opt/sweetada
- executable PATH, /opt/sweetada/bin
which has a totally general meaning in the unix/gnu world. Maybe this useful also for other people. Windows is a totally different beast and I won't explain it now.

Filesystem rules got the concept of hierarchy of directories. If you look at a normal Linux filesystem, things appear clear enough. You can find some hints also in OSX, although is a rather proprietary implementation.

A hierarchy is a directory together with a collection of subdirectories. Standard subdirectories are:
- bin
- include
- lib
- share
- ...
bin is for executables. include is for development headers. lib is for libraries. share is for auxiliary files. Other subdirectories may exist, like sbin, man, doc, ...

When you look at a Linux (unix) filesystem, you note that a more or less standard hierarchy exists, rooted at /.

There is no include, because development in the main filesystem is not allowed. share is not present. But you get bin/ and lib/, which are necessary to run basic system functionalities.

Then there is the /usr hierarchy. Inside /usr you can find, again, bin/, lib/, and also include/, share/, ...

/usr is the main working hierarchy for system development.

Then there is normally a third hierarchy rooted at /usr/local. The same story, but for user development and user "personal" files.

A common hierarchy is also rooted at /opt. Here people would often install their programs.

But in order to mantain maximum separation and avoid possible conflicts, you can create your own hierarchy. This hierarchy is known as the PREFIX. And this is why, normally, most packages defaults to /usr or /usr/local. You can change the prefix by passing "--prefix=<your_prefix>" to the configure. If every program got installed in the same prefix, things could rapidly become a mess.

SweetAda does that, indeed, inside the installation prefix, you can find bin/, lib/, ...

Obviously, if you choose a non-pretty-standard prefix, you have to communicate that to your system. If are stuck with /usr or /usr/local you have to do nothing, because the executables are already visible due to PATH set during initialization by the system to their corrispondent executables subdirectories /usr/bin and /usr/local/bin. But with other prefixes, you have to add them to PATH.

Note that you must add PREFIX/bin, not PREFIX alone -- your PREFIX is a hierarchy with a standard layout.

And there is obviously a rather nice feauture: if you want to delete your package, you simply delete the prefix. You can't do that if prefix=/usr.

And obviously, this a rather coarse explanation. Things are not fixed and many packages have strange layouts.

Hope it was useful, see you soon.

G

Re: SweetAda 0.1 released

[Roger]

On Sunday, July 12, 2020 at 7:59:11 PM UTC+10, gabriele....@gmail.com wrote:
> Fine, Roger. I'm happy to read your post.
> 
> Now I would like to clarify the difference between:
> - the installation PREFIX, /opt/sweetada
> - executable PATH, /opt/sweetada/bin
> which has a totally general meaning in the unix/gnu world. Maybe this useful also for other people. Windows is a totally different beast and I won't explain it now.
> 
> Filesystem rules got the concept of hierarchy of directories. If you look at a normal Linux filesystem, things appear clear enough. You can find some hints also in OSX, although is a rather proprietary implementation.
> 
> A hierarchy is a directory together with a collection of subdirectories. Standard subdirectories are:
> - bin
> - include
> - lib
> - share
> - ...
> bin is for executables. include is for development headers. lib is for libraries. share is for auxiliary files. Other subdirectories may exist, like sbin, man, doc, ...
> 
> When you look at a Linux (unix) filesystem, you note that a more or less standard hierarchy exists, rooted at /.
> 
> There is no include, because development in the main filesystem is not allowed. share is not present. But you get bin/ and lib/, which are necessary to run basic system functionalities.
> 
> Then there is the /usr hierarchy. Inside /usr you can find, again, bin/, lib/, and also include/, share/, ...
> 
> /usr is the main working hierarchy for system development.
> 
> Then there is normally a third hierarchy rooted at /usr/local. The same story, but for user development and user "personal" files.
> 
> A common hierarchy is also rooted at /opt. Here people would often install their programs.
> 
> But in order to mantain maximum separation and avoid possible conflicts, you can create your own hierarchy. This hierarchy is known as the PREFIX. And this is why, normally, most packages defaults to /usr or /usr/local. You can change the prefix by passing "--prefix=<your_prefix>" to the configure. If every program got installed in the same prefix, things could rapidly become a mess.
> 
> SweetAda does that, indeed, inside the installation prefix, you can find bin/, lib/, ...
> 
> Obviously, if you choose a non-pretty-standard prefix, you have to communicate that to your system. If are stuck with /usr or /usr/local you have to do nothing, because the executables are already visible due to PATH set during initialization by the system to their corrispondent executables subdirectories /usr/bin and /usr/local/bin. But with other prefixes, you have to add them to PATH.
> 
> Note that you must add PREFIX/bin, not PREFIX alone -- your PREFIX is a hierarchy with a standard layout.
> 
> And there is obviously a rather nice feauture: if you want to delete your package, you simply delete the prefix. You can't do that if prefix=/usr.
> 
> And obviously, this a rather coarse explanation. Things are not fixed and many packages have strange layouts.
> 
> Hope it was useful, see you soon.
> 
> G

Thanks for your useful explanation which I have saved for future reference.
I am currently investigating IOEMU not displaying the pulsing 8-bit data.
Fortunately your code is well structured which makes it fairly easy to follow so I have got some way into understanding its operation.
I have established that the 8-bit data is certainly being generated.

A clue that I have yet to delve into is:
IOEMU: initializing
IOEMU: PPID = 72658
IOEMU: PID  = 72659
IOEMU: serial port terminal SERIALPORT0 (NO_DEVICE): <NONE>
IOEMU: serial port terminal SERIALPORT1 (NO_DEVICE): <NONE>
IOEMU: executing /usr/bin/osascript
for which I'm assuming  " SERIALPORT0 (NO_DEVICE): <NONE>" indicates a problem.
Regards,
Roger

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Monday, July 13, 2020 at 8:29:03 AM UTC+2, Roger wrote:
> On Sunday, July 12, 2020 at 7:59:11 PM UTC+10, gabriele....@gmail.com wrote:
> > Fine, Roger. I'm happy to read your post.
> > 
> > Now I would like to clarify the difference between:
> > - the installation PREFIX, /opt/sweetada
> > - executable PATH, /opt/sweetada/bin
> > which has a totally general meaning in the unix/gnu world. Maybe this useful also for other people. Windows is a totally different beast and I won't explain it now.
> > 
> > Filesystem rules got the concept of hierarchy of directories. If you look at a normal Linux filesystem, things appear clear enough. You can find some hints also in OSX, although is a rather proprietary implementation.
> > 
> > A hierarchy is a directory together with a collection of subdirectories. Standard subdirectories are:
> > - bin
> > - include
> > - lib
> > - share
> > - ...
> > bin is for executables. include is for development headers. lib is for libraries. share is for auxiliary files. Other subdirectories may exist, like sbin, man, doc, ...
> > 
> > When you look at a Linux (unix) filesystem, you note that a more or less standard hierarchy exists, rooted at /.
> > 
> > There is no include, because development in the main filesystem is not allowed. share is not present. But you get bin/ and lib/, which are necessary to run basic system functionalities.
> > 
> > Then there is the /usr hierarchy. Inside /usr you can find, again, bin/, lib/, and also include/, share/, ...
> > 
> > /usr is the main working hierarchy for system development.
> > 
> > Then there is normally a third hierarchy rooted at /usr/local. The same story, but for user development and user "personal" files.
> > 
> > A common hierarchy is also rooted at /opt. Here people would often install their programs.
> > 
> > But in order to mantain maximum separation and avoid possible conflicts, you can create your own hierarchy. This hierarchy is known as the PREFIX. And this is why, normally, most packages defaults to /usr or /usr/local. You can change the prefix by passing "--prefix=<your_prefix>" to the configure. If every program got installed in the same prefix, things could rapidly become a mess.
> > 
> > SweetAda does that, indeed, inside the installation prefix, you can find bin/, lib/, ...
> > 
> > Obviously, if you choose a non-pretty-standard prefix, you have to communicate that to your system. If are stuck with /usr or /usr/local you have to do nothing, because the executables are already visible due to PATH set during initialization by the system to their corrispondent executables subdirectories /usr/bin and /usr/local/bin. But with other prefixes, you have to add them to PATH.
> > 
> > Note that you must add PREFIX/bin, not PREFIX alone -- your PREFIX is a hierarchy with a standard layout.
> > 
> > And there is obviously a rather nice feauture: if you want to delete your package, you simply delete the prefix. You can't do that if prefix=/usr.
> > 
> > And obviously, this a rather coarse explanation. Things are not fixed and many packages have strange layouts.
> > 
> > Hope it was useful, see you soon.
> > 
> > G
> 
> Thanks for your useful explanation which I have saved for future reference.
> I am currently investigating IOEMU not displaying the pulsing 8-bit data.
> Fortunately your code is well structured which makes it fairly easy to follow so I have got some way into understanding its operation.
> I have established that the 8-bit data is certainly being generated.
> 
> A clue that I have yet to delve into is:
> IOEMU: initializing
> IOEMU: PPID = 72658
> IOEMU: PID  = 72659
> IOEMU: serial port terminal SERIALPORT0 (NO_DEVICE): <NONE>
> IOEMU: serial port terminal SERIALPORT1 (NO_DEVICE): <NONE>
> IOEMU: executing /usr/bin/osascript
> for which I'm assuming  " SERIALPORT0 (NO_DEVICE): <NONE>" indicates a problem.
> Regards,
> Roger

Hi Roger. Thank you very much for your effort.

This is normal. <NONE> means that a serialport device was not generated on-the-fly by IOEMU library, and that's because QEMU is generating one for you through a telnet connection, as established by the configuration in qemu.cfg. So IOEMU simply opens a terminal to that port. This holds always for QEMU, this is a feauture only for FS-UAE or GXemul emulators. Could be a misleading message, perhaps I should change the output log.

I'm very sorry, I know that all those informations should be written in the manual. I'm trying to fill the manual with those relevant infos, between Ada sessions and many other things.

IOEMU not displaying the parallel port data is maybe due to some GUI problem. Let's try to investigate this. You could download the QEMU package currently in the server, so we get a common starting point.

Remember that inside the tar archive there are two main directories, opt/, which should overwrite old sweetada files (OK), and usr/, which contains (usr/)local/lib/????.dylib, that could overwrite your already installed libraries (maybe not very OK).

Pay attention in uncompressing the package blindly. Unfortunately I do not known OSX in the details, and placing libraries in /usr/local/lib does work for me so far.

Best regards.
G

Re: SweetAda 0.1 released

[Roger]

On Monday, July 13, 2020 at 8:07:27 PM UTC+10, gabriele....@gmail.com wrote:
> On Monday, July 13, 2020 at 8:29:03 AM UTC+2, Roger wrote:
> > On Sunday, July 12, 2020 at 7:59:11 PM UTC+10, gabriele....@gmail.com wrote:
> > > Fine, Roger. I'm happy to read your post.
> > > 
> > > Now I would like to clarify the difference between:
> > > - the installation PREFIX, /opt/sweetada
> > > - executable PATH, /opt/sweetada/bin
> > > which has a totally general meaning in the unix/gnu world. Maybe this useful also for other people. Windows is a totally different beast and I won't explain it now.
> > > 
> > > Filesystem rules got the concept of hierarchy of directories. If you look at a normal Linux filesystem, things appear clear enough. You can find some hints also in OSX, although is a rather proprietary implementation.
> > > 
> > > A hierarchy is a directory together with a collection of subdirectories. Standard subdirectories are:
> > > - bin
> > > - include
> > > - lib
> > > - share
> > > - ...
> > > bin is for executables. include is for development headers. lib is for libraries. share is for auxiliary files. Other subdirectories may exist, like sbin, man, doc, ...
> > > 
> > > When you look at a Linux (unix) filesystem, you note that a more or less standard hierarchy exists, rooted at /.
> > > 
> > > There is no include, because development in the main filesystem is not allowed. share is not present. But you get bin/ and lib/, which are necessary to run basic system functionalities.
> > > 
> > > Then there is the /usr hierarchy. Inside /usr you can find, again, bin/, lib/, and also include/, share/, ...
> > > 
> > > /usr is the main working hierarchy for system development.
> > > 
> > > Then there is normally a third hierarchy rooted at /usr/local. The same story, but for user development and user "personal" files.
> > > 
> > > A common hierarchy is also rooted at /opt. Here people would often install their programs.
> > > 
> > > But in order to mantain maximum separation and avoid possible conflicts, you can create your own hierarchy. This hierarchy is known as the PREFIX. And this is why, normally, most packages defaults to /usr or /usr/local. You can change the prefix by passing "--prefix=<your_prefix>" to the configure. If every program got installed in the same prefix, things could rapidly become a mess.
> > > 
> > > SweetAda does that, indeed, inside the installation prefix, you can find bin/, lib/, ...
> > > 
> > > Obviously, if you choose a non-pretty-standard prefix, you have to communicate that to your system. If are stuck with /usr or /usr/local you have to do nothing, because the executables are already visible due to PATH set during initialization by the system to their corrispondent executables subdirectories /usr/bin and /usr/local/bin. But with other prefixes, you have to add them to PATH.
> > > 
> > > Note that you must add PREFIX/bin, not PREFIX alone -- your PREFIX is a hierarchy with a standard layout.
> > > 
> > > And there is obviously a rather nice feauture: if you want to delete your package, you simply delete the prefix. You can't do that if prefix=/usr.
> > > 
> > > And obviously, this a rather coarse explanation. Things are not fixed and many packages have strange layouts.
> > > 
> > > Hope it was useful, see you soon.
> > > 
> > > G
> > 
> > Thanks for your useful explanation which I have saved for future reference.
> > I am currently investigating IOEMU not displaying the pulsing 8-bit data.
> > Fortunately your code is well structured which makes it fairly easy to follow so I have got some way into understanding its operation.
> > I have established that the 8-bit data is certainly being generated.
> > 
> > A clue that I have yet to delve into is:
> > IOEMU: initializing
> > IOEMU: PPID = 72658
> > IOEMU: PID  = 72659
> > IOEMU: serial port terminal SERIALPORT0 (NO_DEVICE): <NONE>
> > IOEMU: serial port terminal SERIALPORT1 (NO_DEVICE): <NONE>
> > IOEMU: executing /usr/bin/osascript
> > for which I'm assuming  " SERIALPORT0 (NO_DEVICE): <NONE>" indicates a problem.
> > Regards,
> > Roger
> 
> Hi Roger. Thank you very much for your effort.
> 
> This is normal. <NONE> means that a serialport device was not generated on-the-fly by IOEMU library, and that's because QEMU is generating one for you through a telnet connection, as established by the configuration in qemu.cfg. So IOEMU simply opens a terminal to that port. This holds always for QEMU, this is a feauture only for FS-UAE or GXemul emulators. Could be a misleading message, perhaps I should change the output log.
> 
> I'm very sorry, I know that all those informations should be written in the manual. I'm trying to fill the manual with those relevant infos, between Ada sessions and many other things.
> 
> IOEMU not displaying the parallel port data is maybe due to some GUI problem. Let's try to investigate this. You could download the QEMU package currently in the server, so we get a common starting point.
> 
> Remember that inside the tar archive there are two main directories, opt/, which should overwrite old sweetada files (OK), and usr/, which contains (usr/)local/lib/????.dylib, that could overwrite your already installed libraries (maybe not very OK).
> 
> Pay attention in uncompressing the package blindly. Unfortunately I do not known OSX in the details, and placing libraries in /usr/local/lib does work for me so far.
> 
> Best regards.
> G
Just a quick check.
By "QEMU package currently in the server", I presume you mean "http://www.sweetada.org/packages/qemu-x86_64-20200707M.tar.gz"?
I think that placing libraries in /usr/local/lib for OSX usually works if  /usr/local/lib is in PATH.
In fact, when I have "library missing" problems I usually solve them by copying the inaccessible library into  /usr/local/lib or provide a link in /usr/local/lib to the otherwise  inaccessible library.

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Monday, July 13, 2020 at 2:03:23 PM UTC+2, Roger wrote:
> On Monday, July 13, 2020 at 8:07:27 PM UTC+10, gabriele....@gmail.com wrote:
> > On Monday, July 13, 2020 at 8:29:03 AM UTC+2, Roger wrote:
> > > On Sunday, July 12, 2020 at 7:59:11 PM UTC+10, gabriele....@gmail.com wrote:
> > > > Fine, Roger. I'm happy to read your post.
> > > > 
> > > > Now I would like to clarify the difference between:
> > > > - the installation PREFIX, /opt/sweetada
> > > > - executable PATH, /opt/sweetada/bin
> > > > which has a totally general meaning in the unix/gnu world. Maybe this useful also for other people. Windows is a totally different beast and I won't explain it now.
> > > > 
> > > > Filesystem rules got the concept of hierarchy of directories. If you look at a normal Linux filesystem, things appear clear enough. You can find some hints also in OSX, although is a rather proprietary implementation.
> > > > 
> > > > A hierarchy is a directory together with a collection of subdirectories. Standard subdirectories are:
> > > > - bin
> > > > - include
> > > > - lib
> > > > - share
> > > > - ...
> > > > bin is for executables. include is for development headers. lib is for libraries. share is for auxiliary files. Other subdirectories may exist, like sbin, man, doc, ...
> > > > 
> > > > When you look at a Linux (unix) filesystem, you note that a more or less standard hierarchy exists, rooted at /.
> > > > 
> > > > There is no include, because development in the main filesystem is not allowed. share is not present. But you get bin/ and lib/, which are necessary to run basic system functionalities.
> > > > 
> > > > Then there is the /usr hierarchy. Inside /usr you can find, again, bin/, lib/, and also include/, share/, ...
> > > > 
> > > > /usr is the main working hierarchy for system development.
> > > > 
> > > > Then there is normally a third hierarchy rooted at /usr/local. The same story, but for user development and user "personal" files.
> > > > 
> > > > A common hierarchy is also rooted at /opt. Here people would often install their programs.
> > > > 
> > > > But in order to mantain maximum separation and avoid possible conflicts, you can create your own hierarchy. This hierarchy is known as the PREFIX. And this is why, normally, most packages defaults to /usr or /usr/local. You can change the prefix by passing "--prefix=<your_prefix>" to the configure. If every program got installed in the same prefix, things could rapidly become a mess.
> > > > 
> > > > SweetAda does that, indeed, inside the installation prefix, you can find bin/, lib/, ...
> > > > 
> > > > Obviously, if you choose a non-pretty-standard prefix, you have to communicate that to your system. If are stuck with /usr or /usr/local you have to do nothing, because the executables are already visible due to PATH set during initialization by the system to their corrispondent executables subdirectories /usr/bin and /usr/local/bin. But with other prefixes, you have to add them to PATH.
> > > > 
> > > > Note that you must add PREFIX/bin, not PREFIX alone -- your PREFIX is a hierarchy with a standard layout.
> > > > 
> > > > And there is obviously a rather nice feauture: if you want to delete your package, you simply delete the prefix. You can't do that if prefix=/usr.
> > > > 
> > > > And obviously, this a rather coarse explanation. Things are not fixed and many packages have strange layouts.
> > > > 
> > > > Hope it was useful, see you soon.
> > > > 
> > > > G
> > > 
> > > Thanks for your useful explanation which I have saved for future reference.
> > > I am currently investigating IOEMU not displaying the pulsing 8-bit data.
> > > Fortunately your code is well structured which makes it fairly easy to follow so I have got some way into understanding its operation.
> > > I have established that the 8-bit data is certainly being generated.
> > > 
> > > A clue that I have yet to delve into is:
> > > IOEMU: initializing
> > > IOEMU: PPID = 72658
> > > IOEMU: PID  = 72659
> > > IOEMU: serial port terminal SERIALPORT0 (NO_DEVICE): <NONE>
> > > IOEMU: serial port terminal SERIALPORT1 (NO_DEVICE): <NONE>
> > > IOEMU: executing /usr/bin/osascript
> > > for which I'm assuming  " SERIALPORT0 (NO_DEVICE): <NONE>" indicates a problem.
> > > Regards,
> > > Roger
> > 
> > Hi Roger. Thank you very much for your effort.
> > 
> > This is normal. <NONE> means that a serialport device was not generated on-the-fly by IOEMU library, and that's because QEMU is generating one for you through a telnet connection, as established by the configuration in qemu.cfg. So IOEMU simply opens a terminal to that port. This holds always for QEMU, this is a feauture only for FS-UAE or GXemul emulators. Could be a misleading message, perhaps I should change the output log.
> > 
> > I'm very sorry, I know that all those informations should be written in the manual. I'm trying to fill the manual with those relevant infos, between Ada sessions and many other things.
> > 
> > IOEMU not displaying the parallel port data is maybe due to some GUI problem. Let's try to investigate this. You could download the QEMU package currently in the server, so we get a common starting point.
> > 
> > Remember that inside the tar archive there are two main directories, opt/, which should overwrite old sweetada files (OK), and usr/, which contains (usr/)local/lib/????.dylib, that could overwrite your already installed libraries (maybe not very OK).
> > 
> > Pay attention in uncompressing the package blindly. Unfortunately I do not known OSX in the details, and placing libraries in /usr/local/lib does work for me so far.
> > 
> > Best regards.
> > G
> Just a quick check.
> By "QEMU package currently in the server", I presume you mean "http://www.sweetada.org/packages/qemu-x86_64-20200707M.tar.gz"?
> I think that placing libraries in /usr/local/lib for OSX usually works if  /usr/local/lib is in PATH.
> In fact, when I have "library missing" problems I usually solve them by copying the inaccessible library into  /usr/local/lib or provide a link in /usr/local/lib to the otherwise  inaccessible library.

Yes, http://www.sweetada.org/packages/qemu-x86_64-20200707M.tar.gz is the last build.

About the libraries, I think that OSX accesses a library first by looking at that directory, at least in my installation.

Go ahead with your idea, possibly trying to understand if the libraries I supplied are those really loaded when QEMU starts.

I would like to solve this "problem", because, as I said in previous post, I want to make sweetada compact and isolated from the system as much as possible. I am working on that, but there are some issues with the handling of LD_LIBRARY_PATH variable.

Let me know.
G

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Monday, July 13, 2020 at 2:03:23 PM UTC+2, Roger wrote:
> On Monday, July 13, 2020 at 8:07:27 PM UTC+10, gabriele....@gmail.com wrote:
> > On Monday, July 13, 2020 at 8:29:03 AM UTC+2, Roger wrote:
> > > On Sunday, July 12, 2020 at 7:59:11 PM UTC+10, gabriele....@gmail.com wrote:
> > > > Fine, Roger. I'm happy to read your post.
> > > > 
> > > > Now I would like to clarify the difference between:
> > > > - the installation PREFIX, /opt/sweetada
> > > > - executable PATH, /opt/sweetada/bin
> > > > which has a totally general meaning in the unix/gnu world. Maybe this useful also for other people. Windows is a totally different beast and I won't explain it now.
> > > > 
> > > > Filesystem rules got the concept of hierarchy of directories. If you look at a normal Linux filesystem, things appear clear enough. You can find some hints also in OSX, although is a rather proprietary implementation.
> > > > 
> > > > A hierarchy is a directory together with a collection of subdirectories. Standard subdirectories are:
> > > > - bin
> > > > - include
> > > > - lib
> > > > - share
> > > > - ...
> > > > bin is for executables. include is for development headers. lib is for libraries. share is for auxiliary files. Other subdirectories may exist, like sbin, man, doc, ...
> > > > 
> > > > When you look at a Linux (unix) filesystem, you note that a more or less standard hierarchy exists, rooted at /.
> > > > 
> > > > There is no include, because development in the main filesystem is not allowed. share is not present. But you get bin/ and lib/, which are necessary to run basic system functionalities.
> > > > 
> > > > Then there is the /usr hierarchy. Inside /usr you can find, again, bin/, lib/, and also include/, share/, ...
> > > > 
> > > > /usr is the main working hierarchy for system development.
> > > > 
> > > > Then there is normally a third hierarchy rooted at /usr/local. The same story, but for user development and user "personal" files.
> > > > 
> > > > A common hierarchy is also rooted at /opt. Here people would often install their programs.
> > > > 
> > > > But in order to mantain maximum separation and avoid possible conflicts, you can create your own hierarchy. This hierarchy is known as the PREFIX. And this is why, normally, most packages defaults to /usr or /usr/local. You can change the prefix by passing "--prefix=<your_prefix>" to the configure. If every program got installed in the same prefix, things could rapidly become a mess.
> > > > 
> > > > SweetAda does that, indeed, inside the installation prefix, you can find bin/, lib/, ...
> > > > 
> > > > Obviously, if you choose a non-pretty-standard prefix, you have to communicate that to your system. If are stuck with /usr or /usr/local you have to do nothing, because the executables are already visible due to PATH set during initialization by the system to their corrispondent executables subdirectories /usr/bin and /usr/local/bin. But with other prefixes, you have to add them to PATH.
> > > > 
> > > > Note that you must add PREFIX/bin, not PREFIX alone -- your PREFIX is a hierarchy with a standard layout.
> > > > 
> > > > And there is obviously a rather nice feauture: if you want to delete your package, you simply delete the prefix. You can't do that if prefix=/usr.
> > > > 
> > > > And obviously, this a rather coarse explanation. Things are not fixed and many packages have strange layouts.
> > > > 
> > > > Hope it was useful, see you soon.
> > > > 
> > > > G
> > > 
> > > Thanks for your useful explanation which I have saved for future reference.
> > > I am currently investigating IOEMU not displaying the pulsing 8-bit data.
> > > Fortunately your code is well structured which makes it fairly easy to follow so I have got some way into understanding its operation.
> > > I have established that the 8-bit data is certainly being generated.
> > > 
> > > A clue that I have yet to delve into is:
> > > IOEMU: initializing
> > > IOEMU: PPID = 72658
> > > IOEMU: PID  = 72659
> > > IOEMU: serial port terminal SERIALPORT0 (NO_DEVICE): <NONE>
> > > IOEMU: serial port terminal SERIALPORT1 (NO_DEVICE): <NONE>
> > > IOEMU: executing /usr/bin/osascript
> > > for which I'm assuming  " SERIALPORT0 (NO_DEVICE): <NONE>" indicates a problem.
> > > Regards,
> > > Roger
> > 
> > Hi Roger. Thank you very much for your effort.
> > 
> > This is normal. <NONE> means that a serialport device was not generated on-the-fly by IOEMU library, and that's because QEMU is generating one for you through a telnet connection, as established by the configuration in qemu.cfg. So IOEMU simply opens a terminal to that port. This holds always for QEMU, this is a feauture only for FS-UAE or GXemul emulators. Could be a misleading message, perhaps I should change the output log.
> > 
> > I'm very sorry, I know that all those informations should be written in the manual. I'm trying to fill the manual with those relevant infos, between Ada sessions and many other things.
> > 
> > IOEMU not displaying the parallel port data is maybe due to some GUI problem. Let's try to investigate this. You could download the QEMU package currently in the server, so we get a common starting point.
> > 
> > Remember that inside the tar archive there are two main directories, opt/, which should overwrite old sweetada files (OK), and usr/, which contains (usr/)local/lib/????.dylib, that could overwrite your already installed libraries (maybe not very OK).
> > 
> > Pay attention in uncompressing the package blindly. Unfortunately I do not known OSX in the details, and placing libraries in /usr/local/lib does work for me so far.
> > 
> > Best regards.
> > G
> Just a quick check.
> By "QEMU package currently in the server", I presume you mean "http://www.sweetada.org/packages/qemu-x86_64-20200707M.tar.gz"?
> I think that placing libraries in /usr/local/lib for OSX usually works if  /usr/local/lib is in PATH.
> In fact, when I have "library missing" problems I usually solve them by copying the inaccessible library into  /usr/local/lib or provide a link in /usr/local/lib to the otherwise  inaccessible library.

Hi Roger.

Perhaps, you may want to try also a new build of QEMU, "qemu-x86_64-20200714M.tar.gz", which I've just released today. There is no need to install separate libraries in /usr/local/lib, the package uncompresses as usual in opt/, but the .dylib libraries are now installed in a relative sibling lib/ directory of executable located in bin/. So you could, eventually, delete additional libraries installed with the separate package qemu-libraries-osx.tar.gz some days ago, which may clash with already-present ones, and is now deprecated. The QEMU package is now more compact and manageable.

Best regards

Re: SweetAda 0.1 released

[Roger]

On Wednesday, July 15, 2020 at 2:53:11 AM UTC+10, gabriele....@gmail.com wrote:

> Hi Roger.
> 
> Perhaps, you may want to try also a new build of QEMU, "qemu-x86_64-20200714M.tar.gz", which I've just released today. There is no need to install separate libraries in /usr/local/lib, the package uncompresses as usual in opt/, but the .dylib libraries are now installed in a relative sibling lib/ directory of executable located in bin/. So you could, eventually, delete additional libraries installed with the separate package qemu-libraries-osx.tar.gz some days ago, which may clash with already-present ones, and is now deprecated. The QEMU package is now more compact and manageable.
> 
> Best regards

I tried the latest "qemu-x86_64-20200714M.tar.gz". The results are the same.
I think that your latest .dylib libraries installation is a good idea especially as it makes the QEMU package more compact and manageable.

Re: SweetAda 0.1 released

[gabriele.galeotti.xyz]

On Wednesday, July 15, 2020 at 9:52:05 AM UTC+2, Roger wrote:
> On Wednesday, July 15, 2020 at 2:53:11 AM UTC+10, gabriele....@gmail.com wrote:
> 
> > Hi Roger.
> > 
> > Perhaps, you may want to try also a new build of QEMU, "qemu-x86_64-20200714M.tar.gz", which I've just released today. There is no need to install separate libraries in /usr/local/lib, the package uncompresses as usual in opt/, but the .dylib libraries are now installed in a relative sibling lib/ directory of executable located in bin/. So you could, eventually, delete additional libraries installed with the separate package qemu-libraries-osx.tar.gz some days ago, which may clash with already-present ones, and is now deprecated. The QEMU package is now more compact and manageable.
> > 
> > Best regards
> 
> I tried the latest "qemu-x86_64-20200714M.tar.gz". The results are the same.
> I think that your latest .dylib libraries installation is a good idea especially as it makes the QEMU package more compact and manageable.

OK Roger.

Yes, now QEMU emulator is a consistent package and there is no need to install 
libraries in other places. It should be completely independet, just unpack it and overwrite previous installation. No more libraries in other locations.

For the problem of no IOMEU output, some questions:
- do you see the terminals appear?
- do you see some messages in those terminals?
- do you change something in ioemu.cfg?

It would be beautiful if you you could download and work on sweetada-0.1d.tar.gz, so we have a common base.

In the meantime, I could prepare a QEMU executable (only this, to be used instead of that in the package) full of logs about window creation and widgets setup, so we can understand better what's going on. When it will be ready I'll tell you.

Unfortunately no one feed informations so far, so if you are willing, we have to experiment a bit in "raw" mode.

Thanks, let me know.

Re: SweetAda 0.1 released

[Roger]

On Thursday, July 16, 2020 at 9:09:50 PM UTC+10, gabriele....@gmail.com wrote:
> OK Roger.
> 
> Yes, now QEMU emulator is a consistent package and there is no need to install 
> libraries in other places. It should be completely independet, just unpack it and overwrite previous installation. No more libraries in other locations.
> 
> For the problem of no IOMEU output, some questions:
> - do you see the terminals appear?
Two telnet 127.0.0.1 4447  terminals appear.
> - do you see some messages in those terminals?
One returns:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

The other returns:
PC-x86-64
PCI Device #0000 8086:29C0
PCI Device #0001 1234:1111
PCI Device #0002 8086:10D3
PCI Device #001F 8086:2918

plus some other messages that I have been using to investigate the code.

Also the IOEMU and QEMU windows appear.

> - do you change something in ioemu.cfg?
I don't seem to have an  ioemu.cfg file; only  qemu.cfg files which I have not changed.
> 
> It would be beautiful if you you could download and work on sweetada-0.1d.tar.gz, so we have a common base.
Will do.
> 
> In the meantime, I could prepare a QEMU executable (only this, to be used instead of that in the package) full of logs about window creation and widgets setup, so we can understand better what's going on. When it will be ready I'll tell you.
> 
Thanks. That will be great.
> Unfortunately no one feed informations so far, so if you are willing, we have to experiment a bit in "raw" mode.
> 
> Thanks, let me know.

Re: SweetAda 0.1 released

[Roger]

> On Thursday, July 16, 2020 at 9:09:50 PM UTC+10, gabriele....@gmail.com wrote:
> > OK Roger.
> > 
> > Yes, now QEMU emulator is a consistent package and there is no need to install 
> > libraries in other places. It should be completely independet, just unpack it and overwrite previous installation. No more libraries in other locations.
> > 
> > For the problem of no IOMEU output, some questions:
> > - do you see the terminals appear?
> Two telnet 127.0.0.1 4447  terminals appear.
> > - do you see some messages in those terminals?
> One returns:
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> 
> The other returns:
> PC-x86-64
> PCI Device #0000 8086:29C0
> PCI Device #0001 1234:1111
> PCI Device #0002 8086:10D3
> PCI Device #001F 8086:2918
> 
> plus some other messages that I have been using to investigate the code.
> 
> Also the IOEMU and QEMU windows appear.
> 
> > - do you change something in ioemu.cfg?
> I don't seem to have an  ioemu.cfg file; only  qemu.cfg files which I have not changed.
> > 
> > It would be beautiful if you you could download and work on sweetada-0.1d.tar.gz, so we have a common base.
> Will do.
> > 
> > In the meantime, I could prepare a QEMU executable (only this, to be used instead of that in the package) full of logs about window creation and widgets setup, so we can understand better what's going on. When it will be ready I'll tell you.
> > 
> Thanks. That will be great.
> > Unfortunately no one feed informations so far, so if you are willing, we have to experiment a bit in "raw" mode.
> > 
> > Thanks, let me know.

 I've installed sweetada-0.1d
The terminal windows contain the same results (except for my 0.1c additions).
IOEMU still shows no activity.
QEMU now has some messages (it had none under 0.1c):
Archaea: initializing
Close this window to shut down the emulator.
The cursor release message.
Plus cycling characters.

I'm happy to experiment a bit in "raw" mode but will need your instructions as, so far, I'm in uncharted waters.

Regards,
Roger