Apply it, apply it.
SQLite wrappers are functional, albeit somehow primitive. Postgresql not, so currently it's better not to include them
Il 6 maggio 2024 17:52:16 CEST, Raphael Mack <ramack@raphael-mack.de> ha scritto:
Thanks Remy,
@Paolo: what do you think about the Postgres-wrapper and its near future? Shall we apply this patch? remove it from the loadpath or fix it?
Regards, Rapha
Am Sonntag, dem 05.05.2024 um 12:31 +0200 schrieb Remy.Schleimer: Hi, In an attempt to make “se eiffeldoc” executable, I made some changes to liberty-eiffel. A diff is in the attachment, for those who are interested On 1 May 2024, at 09:18, Remy.Schleimer <remy.Schleimer@org-it.lu> wrote:
As a follow-up to my earlier mails, I made some additional tests (on a fresh install) %mkdir dev %cat loadpath.se ../src/lib/loadpath.se ../src/smarteiffel/loadpath.se
% diff loadpath.se ../src/loadpath.se 1,3c1,5 < ../src/lib/loadpath.se < ../src/smarteiffel/loadpath.se < ../src/tools/loadpath.se --- > ./lib/loadpath.se > ./smarteiffel/loadpath.se > ./tools/loadpath.se > ./wrappers/loadpath.se
-> excluding wrappers and staging
% se find POSTGRESQL_DATABASE ****** Fatal Error: Cannot find the class "LIBPQ_FE_EXTERNALS" in any known cluster.
Line 23 column 8 in POSTGRESQL_DATABASE (/Users/eiffel/Repos/liberty-eiffel/src/wrappers/database/library/postgresql/postgresql_database.e): insert LIBPQ_FE_EXTERNALS ^ ———
-> class POSTGRESQL_DATABASE is included in my project, even though I did not specify the cluster containing it in my loadpath.se
As a conclusion, liberty-eiffel does not use my loadpath, but rather makes its own stuff. When adding the -verbose flag to my command, it appears, that the system will use the default settings in addition to my loadpath.se which is unexpected
Question: Is this the expected behaviour? Question: Is there a good documentation explaining how to configure my development environment?
Any help appreciated Remy
On 28 Apr 2024, at 22:27, Remy.Schleimer <remy.Schleimer@org-it.lu> wrote:
Hi Rapha, Allow me to express some thoughts: - currently liberty eiffel distribution has 7k+ classes - a very few of them are incompletely specified (is indicated in my previous message) - those few ones prevent the whole system from being documented
I am not convinced (as you suggested) that the problem stems from “the size of generated html”: 7k classes is huge, there is nothing we can do about it.
IMHO, the problem is more about definition of the universe: after a standard install, liberty eiffel just assumes that I want to use all the classes included in the distribution. This is definitely not the case: On a first trial, I’d be happy to work with the classes included in “my universe”, which in my case was an empty directory. Should I want to add more classes, I would be happy to provide a universe to the system ( loadpath.se).
While being easy to use, I believe the system should not imply a default universe, but stick to the one defined in the current directory. Obviously, other settings from “ liberty.se” (e.g. compiler settings) are worth keeping unchanged. But who am I to make such suggestions? Regards Remy
BTW, “install.sh -wrapper” currently yields errors, which seem to be the very origin to the problems discussed in this thread
find . -type f -iname "*.e"|wc 7345 7345 392788
cd dev % ls -l total 0 % se find any
/Users/eiffel/Repos/liberty-eiffel/src/lib/kernel/any.e (class ANY in cluster "liberty_core:kernel/loadpath.se:")
On 28 Apr 2024, at 18:22, Raphael Mack <ramack@raphael-mack.de> wrote:
Hi, yea, clearly I'd say it's better to continoue. But we had already so much trouble with eiffeldoc - you know that normally it runs on every commit and generates the nightly docs, but that process also fails due to memory issues. Also the size of the generated HTML is a nightmare and maybe it would be best, to redesign the whole thing, starting with better html output and than rework eiffeldoc as needed to do the job properly. Ideas or PRs are warmly welcome! Rapha Am Sonntag, dem 28.04.2024 um 17:23 +0200 schrieb Remy.Schleimer: Hi,
Thanks for confirming that I am not alone.
So we have to fix this!
First question would then be, in such circumstance, does the tool
need to break, and generate nothing, rather than to fall back
generating what goes, and leaving appropriate messages for the rest?
Sent from my iPhone
On 28 Apr 2024, at 17:07, Jakub Pavlík <jkb.pavlik@gmail.com>
wrote:
When I came to Liberty Eiffel not long ago and started tinkering
with eiffeldoc, I encountered the same issue and temporarily
addressed it by simply deleting the postgres bindings (and a few
other similarly offending subclusters of the library IIRC). It
seems that eiffeldoc lacks support for some aspects of the library.
See also contents of "The library wrappers"
at https://doc.liberty-eiffel.org/ , suggesting that documentation
generation isn't broken just for noobs like me, but also for the
project's heads.
Regards, Jakub
ne 28. 4. 2024 v 16:54 odesílatel Remy.Schleimer
<remy.Schleimer@org-it.lu> napsal:
Hi there,
In an attempt to start with liberty eiffel, I have done the
following:
git clone git://git.sv.gnu.org/liberty-eiffel.git
cd liberty-eiffel
./install.sh
export PATH=$PATH:`pwd`/target/bin
mkdir dev
cd dev
se eiffeldoc
This yields the following error:
****** Fatal Error: Cannot find the class "LIBPQ_FE_EXTERNALS" in
any known cluster.
Line 23 in POSTGRESQL_DATABASE (/Users/eiffel/Repos/liberty-
eiffel/src/wrappers/database/library/postgresql/postgresql_databa
se.e):
insert LIBPQ_FE_EXTERNALS
———————————
Any hints to get rid of this would be great
Remy
--
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. |