From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:aed:3023:: with SMTP id 32mr5571516qte.37.1594745590483; Tue, 14 Jul 2020 09:53:10 -0700 (PDT) X-Received: by 2002:aca:48d3:: with SMTP id v202mr4313790oia.78.1594745590210; Tue, 14 Jul 2020 09:53:10 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!peer02.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 14 Jul 2020 09:53:09 -0700 (PDT) In-Reply-To: <7b67ad1e-f157-4ac5-8512-829ea35b3715o@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=87.1.135.85; posting-account=JRF_-woAAABYlsAtkCl_CUxBuQy2SsaQ NNTP-Posting-Host: 87.1.135.85 References: <242465de-0171-44b1-9618-752b22c3604co@googlegroups.com> <11c21c57-69de-4fcb-9193-71a98ca93ecao@googlegroups.com> <126727e4-3108-46cd-acc6-e42dbdb9dd6bo@googlegroups.com> <011aef92-84e3-47e5-a558-a8c2c6504161o@googlegroups.com> <8959b86d-ec38-4e0b-a272-384751914732o@googlegroups.com> <16b49b03-8657-425d-bad5-67cc5fe725d2o@googlegroups.com> <891fe070-40a4-4ba2-a7be-a7e9c4c036a4o@googlegroups.com> <04195e55-a82f-4035-a05d-5078ea2e6259o@googlegroups.com> <2790711b-d169-4a19-b666-5853eb0f5268o@googlegroups.com> <7052e60c-33ad-4961-9a2c-76014bd6c516o@googlegroups.com> <6efbebf3-8dd2-4909-ab48-d57ba39dc309o@googlegroups.com> <7e2ea50e-412b-421a-b842-e97014043e37o@googlegroups.com> <24f16e6b-e885-4dc5-8519-05c6a786f4dfo@googlegroups.com> <53e66aa5-c298-4b27-8718-386e7a624141o@googlegroups.com> <43a34342-88a2-4af3-b146-817192dab5b7o@googlegroups.com> <80160030-7962-4abd-a6cb-46ea2c91decao@googlegroups.com> <8469bb3c-4caa-404d-8fd0-b74d0238450fo@googlegroups.com> <654e2ffe-f7ee-439d-a535-aab4360fad67o@googlegroups.com> <3ad33643-08b1-4ab6-8672-f9df27d822f6o@googlegroups.com> <89558f25-5b98-40a4-a106-d1e9f12eb6beo@googlegroups.com> <59edfbd5-3108-47d1-ab0e-982fe568078co@googlegroups.com> <437612bd-3739-40d1-ad00-6dfffea7a06fo@googlegroups.com> <487c7db4-da9a-4191-999e-05be41e36b72o@googlegroups.com> <7b67ad1e-f157-4ac5-8512-829ea35b3715o@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <49c4a965-b50f-4774-9f41-cc535d967399o@googlegroups.com> Subject: Re: SweetAda 0.1 released From: gabriele.galeotti.xyz@gmail.com Injection-Date: Tue, 14 Jul 2020 16:53:10 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 9819 X-Received-Body-CRC: 2080421524 Xref: reader01.eternal-september.org comp.lang.ada:59448 List-Id: 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 wro= te: > > 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. > > > >=20 > > > > 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 th= is useful also for other people. Windows is a totally different beast and I= won't explain it now. > > > >=20 > > > > Filesystem rules got the concept of hierarchy of directories. If yo= u look at a normal Linux filesystem, things appear clear enough. You can fi= nd some hints also in OSX, although is a rather proprietary implementation. > > > >=20 > > > > A hierarchy is a directory together with a collection of subdirecto= ries. 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, ... > > > >=20 > > > > When you look at a Linux (unix) filesystem, you note that a more or= less standard hierarchy exists, rooted at /. > > > >=20 > > > > 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 nec= essary to run basic system functionalities. > > > >=20 > > > > Then there is the /usr hierarchy. Inside /usr you can find, again, = bin/, lib/, and also include/, share/, ... > > > >=20 > > > > /usr is the main working hierarchy for system development. > > > >=20 > > > > Then there is normally a third hierarchy rooted at /usr/local. The = same story, but for user development and user "personal" files. > > > >=20 > > > > A common hierarchy is also rooted at /opt. Here people would often = install their programs. > > > >=20 > > > > But in order to mantain maximum separation and avoid possible confl= icts, you can create your own hierarchy. This hierarchy is known as the PRE= FIX. And this is why, normally, most packages defaults to /usr or /usr/loca= l. You can change the prefix by passing "--prefix=3D" to the c= onfigure. If every program got installed in the same prefix, things could r= apidly become a mess. > > > >=20 > > > > SweetAda does that, indeed, inside the installation prefix, you can= find bin/, lib/, ... > > > >=20 > > > > 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 h= ave 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 ha= ve to add them to PATH. > > > >=20 > > > > Note that you must add PREFIX/bin, not PREFIX alone -- your PREFIX = is a hierarchy with a standard layout. > > > >=20 > > > > And there is obviously a rather nice feauture: if you want to delet= e your package, you simply delete the prefix. You can't do that if prefix= =3D/usr. > > > >=20 > > > > And obviously, this a rather coarse explanation. Things are not fix= ed and many packages have strange layouts. > > > >=20 > > > > Hope it was useful, see you soon. > > > >=20 > > > > G > > >=20 > > > Thanks for your useful explanation which I have saved for future refe= rence. > > > I am currently investigating IOEMU not displaying the pulsing 8-bit d= ata. > > > Fortunately your code is well structured which makes it fairly easy t= o follow so I have got some way into understanding its operation. > > > I have established that the 8-bit data is certainly being generated. > > >=20 > > > A clue that I have yet to delve into is: > > > IOEMU: initializing > > > IOEMU: PPID =3D 72658 > > > IOEMU: PID =3D 72659 > > > IOEMU: serial port terminal SERIALPORT0 (NO_DEVICE): > > > IOEMU: serial port terminal SERIALPORT1 (NO_DEVICE): > > > IOEMU: executing /usr/bin/osascript > > > for which I'm assuming " SERIALPORT0 (NO_DEVICE): " indicates = a problem. > > > Regards, > > > Roger > >=20 > > Hi Roger. Thank you very much for your effort. > >=20 > > This is normal. 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 qe= mu.cfg. So IOEMU simply opens a terminal to that port. This holds always fo= r QEMU, this is a feauture only for FS-UAE or GXemul emulators. Could be a = misleading message, perhaps I should change the output log. > >=20 > > 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, betwe= en Ada sessions and many other things. > >=20 > > IOEMU not displaying the parallel port data is maybe due to some GUI pr= oblem. Let's try to investigate this. You could download the QEMU package c= urrently in the server, so we get a common starting point. > >=20 > > Remember that inside the tar archive there are two main directories, op= t/, which should overwrite old sweetada files (OK), and usr/, which contain= s (usr/)local/lib/????.dylib, that could overwrite your already installed l= ibraries (maybe not very OK). > >=20 > > 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. > >=20 > > 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 c= opying 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-2020071= 4M.tar.gz", which I've just released today. There is no need to install sep= arate libraries in /usr/local/lib, the package uncompresses as usual in opt= /, but the .dylib libraries are now installed in a relative sibling lib/ di= rectory of executable located in bin/. So you could, eventually, delete add= itional libraries installed with the separate package qemu-libraries-osx.ta= r.gz some days ago, which may clash with already-present ones, and is now d= eprecated. The QEMU package is now more compact and manageable. Best regards