Re: SweetAda 0.1 released

[gabriele.galeotti.xyz@gmail.com]

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