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=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Received: by 2002:a05:6214:946:: with SMTP id dn6mr68094263qvb.224.1594621742156; Sun, 12 Jul 2020 23:29:02 -0700 (PDT) X-Received: by 2002:aca:6289:: with SMTP id w131mr11717064oib.122.1594621741881; Sun, 12 Jul 2020 23:29:01 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 12 Jul 2020 23:29:01 -0700 (PDT) In-Reply-To: <59edfbd5-3108-47d1-ab0e-982fe568078co@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=203.59.139.151; posting-account=d51RWwoAAADvR-x0zYAtT9z3CRxT1eXo NNTP-Posting-Host: 203.59.139.151 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <437612bd-3739-40d1-ad00-6dfffea7a06fo@googlegroups.com> Subject: Re: SweetAda 0.1 released From: Roger Injection-Date: Mon, 13 Jul 2020 06:29:02 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:59442 List-Id: 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 this use= ful 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 you look= at a normal Linux filesystem, things appear clear enough. You can find som= e hints also in OSX, although is a rather proprietary implementation. >=20 > 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 li= braries. 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 al= lowed. share is not present. But you get bin/ and lib/, which are necessary= 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 s= tory, but for user development and user "personal" files. >=20 > A common hierarchy is also rooted at /opt. Here people would often instal= l their programs. >=20 > But in order to mantain maximum separation and avoid possible conflicts, = you can create your own hierarchy. This hierarchy is known as the PREFIX. A= nd this is why, normally, most packages defaults to /usr or /usr/local. You= can change the prefix by passing "--prefix=3D" to the configu= re. If every program got installed in the same prefix, things could rapidly= 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 commun= icate 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 du= ring initialization by the system to their corrispondent executables subdir= ectories /usr/bin and /usr/local/bin. But with other prefixes, you have to = add them to PATH. >=20 > Note that you must add PREFIX/bin, not PREFIX alone -- your PREFIX is a h= ierarchy with a standard layout. >=20 > 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=3D/usr. >=20 > And obviously, this a rather coarse explanation. Things are not fixed and= many packages have strange layouts. >=20 > Hope it was useful, see you soon. >=20 > 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 foll= ow 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 =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 prob= lem. Regards, Roger