Instructions for building with Aldor

[Waldek Hebisch]

Instructions for building Aldor interface are both in INSTALL and
INSTALL.aldor, however neither mentions '-with-aldor-binary=...'.

I think that we should rationalize this, and keep master source
only in one place. And make sure that this place is complete
and up to date.

--
Waldek Hebisch

[Ralf Hemmecke]

I think that INSTALL.aldor should disappear and the respective
information should go to install.rst.
Give me some time to prepare a pull request.

Ralf

[Waldek Hebisch]

On Tue, Dec 05, 2023 at 11:20:35AM +0100, Ralf Hemmecke wrote:
> I think that INSTALL.aldor should disappear and the respective information
> should go to install.rst.

Yes.

> Give me some time to prepare a pull request.

BTW: When installing Aldor in the wiki I updated:

http://wiki.fricas.org/AldorForFriCAS

so that it contains info needed to install Aldor on wiki machine.
In particular I did not see _working_ instructions for building
Aldor itself in single place (there were hints in emails from
Peter).

--
Waldek Hebisch

[Ralf Hemmecke]

> BTW: When installing Aldor in the wiki I updated:
>
> http://wiki.fricas.org/AldorForFriCAS
>
> so that it contains info needed to install Aldor on wiki machine.
> In particular I did not see _working_ instructions for building
> Aldor itself in single place (there were hints in emails from
> Peter).

Oh, up to now I thought that Aldor build instructions is something that
the Aldor project is responsible for.

But I agree, the need for "--disable-maintainer-mode" should be more
prominent in the Aldor build instructions or rather should be the
default. There seems to be a problem with the standard way.

[git checkout...]
cd $ALDOR/aldor
./autogen.sh
cd $BUILDDIR
$ALDOR/aldor/configure
make -j8

gives

libtool: Version mismatch error. This is libtool 2.4.7 Debian-2.4.7-4,
but the
libtool: definition of this LT_INIT comes from libtool 2.4.6.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.7
Debian-2.4.7-4
libtool: and run autoconf again.

Maybe autogen.sh must be updated to regenerate everything properly for
the standard --enable-maintainer-mode.

Ralf

[Waldek Hebisch]

On Sat, Dec 09, 2023 at 01:55:34AM +0100, Ralf Hemmecke wrote:
> > BTW: When installing Aldor in the wiki I updated:
> >
> > http://wiki.fricas.org/AldorForFriCAS
> >
> > so that it contains info needed to install Aldor on wiki machine.
> > In particular I did not see _working_ instructions for building
> > Aldor itself in single place (there were hints in emails from
> > Peter).
>
> Oh, up to now I thought that Aldor build instructions is something that the
> Aldor project is responsible for.

Well, it should be done by Aldor folks. But to build Aldor
interface one needs to get (that is build) Aldor first and at
least for wiki the simplest way was to add instructions to
page above.

> But I agree, the need for "--disable-maintainer-mode" should be more
> prominent in the Aldor build instructions or rather should be the default.
> There seems to be a problem with the standard way.
>
> [git checkout...]
> cd $ALDOR/aldor
> ./autogen.sh
> cd $BUILDDIR
> $ALDOR/aldor/configure
> make -j8
>
> gives
>
> libtool: Version mismatch error. This is libtool 2.4.7 Debian-2.4.7-4, but
> the
> libtool: definition of this LT_INIT comes from libtool 2.4.6.
> libtool: You should recreate aclocal.m4 with macros from libtool 2.4.7
> Debian-2.4.7-4
> libtool: and run autoconf again.
>
> Maybe autogen.sh must be updated to regenerate everything properly for the
> standard --enable-maintainer-mode.

AFAIK in maintainer mode autotools do not tolerate any version
differences: maintainers are supposed to use exactly the same
autotools version. I mean that upgrade/downgrade may require
modifying code which should be trivial for person familiar
with build system, that is maintainer. But in practice IIUC projects
with complicated build systems tend to stay with single version
and then there is real work to upgrade. I affraid that having
users to deal with maintainer mode is too problematic.

--
Waldek Hebisch

[Peter Broadbery]

I think the reference to 'Aldor folks' above is optimistic - I'd like
to get a few more
people helping with development (this is an optimistic plea for
interested parties, to get involved btw).
Anyway, I hadn't noted the impact of maintainer mode. If it's easier
to work without it, then it's not a problem to drop it from the github
configure.ac

Peter


Peter


> --
> Waldek Hebisch
>
> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZXPJDyEqIn8y7BVL%40fricas.org.

[Ralf Hemmecke]

Hi Peter,

> I think the reference to 'Aldor folks' above is optimistic - I'd like
> to get a few more people helping with development (this is an
> optimistic plea for interested parties, to get involved btw).

Yes, would be supergood to have more developers, but it's somewhat of a
hen-egg-problem. Nobody can get interested in Aldor if he/she doesn't
know about the advantages of Aldor. I'm afraid that FriCAS will not help
much. I try to have an eye on the generation of libfricas.al so that
Aldor is at least usable together with FriCAS, but what is needed is a
kind of killer application that shows why Aldor is good. Now many people
jump on the Julia train simply because they see faster development
there. It's hard to say how one can best advertise Aldor to other
compiler developers.

> Anyway, I hadn't noted the impact of maintainer mode. If it's easier
> to work without it, then it's not a problem to drop it from the

> github configure.ac.

Oh, I think, the problem is not maintainer mode, but only me. I used to
always start from a clean checkout and ran ./autogen.sh. It had never
been a problem until I tried yesterday. Since you have included the
Makefile.in, I haven't compiled Aldor myself. I just thought, it would
be good if ./autogen.sh really uses the installed autotools version of
my system and generates what is needed or tells me which versions of
automake, autoconf, libtool and whatever I must have installed to build
Aldor.

For people who are just interested in using aldor, the pregenerated
Makefile.in (and other stuff) are just fine. And maybe it then makes
more sense to switch from the default (that maintainer-mode is enabled)
to maintainer-mode is disabled, i.e. maintainers (you) would have to add
--enable-maintainer-mode. Maybe that is not a too big burden for you,
but makes the life of Aldor users easier. Nobody should have to know
about maintainer mode unless he/she is a Aldor developer.

Thank you for still keeping Aldor alive,
Actually I wonder where you are heading too. I see several commits
connected to Java. Do you aim at a .as --> .java translation?

Ralf

[Peter Broadbery]

On Sat, 9 Dec 2023 at 16:47, Ralf Hemmecke <ra...@hemmecke.org> wrote:
>
> Hi Peter,
>
> > I think the reference to 'Aldor folks' above is optimistic - I'd like
> > to get a few more people helping with development (this is an
> > optimistic plea for interested parties, to get involved btw).
>
> Yes, would be supergood to have more developers, but it's somewhat of a
> hen-egg-problem. Nobody can get interested in Aldor if he/she doesn't
> know about the advantages of Aldor. I'm afraid that FriCAS will not help
> much. I try to have an eye on the generation of libfricas.al so that
> Aldor is at least usable together with FriCAS, but what is needed is a
> kind of killer application that shows why Aldor is good. Now many people
> jump on the Julia train simply because they see faster development
> there. It's hard to say how one can best advertise Aldor to other
> compiler developers.
>

Yes - it is hard to sell without a strong application; unfortunately I
don't have a strong sense of what a
killer application would look like. I suspect that the algebra
library contains several
good starting points for anyone wishing to push it further.

>
> Thank you for still keeping Aldor alive,
> Actually I wonder where you are heading too. I see several commits
> connected to Java. Do you aim at a .as --> .java translation?
>

The .as -> java thing is pretty much done (excluding fully generic
generics/type constructors). It is quite possible
to call java methods from aldor and vice-versa. My other side project
of an Aldor/Fricas code editor uses it quite intensely.
Maybe exposing the algebra library as java would be an interesting
project.. I've yet to try it.

As for where I'm heading with Aldor - my todo list is: (in increasing
order of vagueness)
- Improvements to way C functions are called, fixing compiler warnings
- Re-implementing generators, thus improving code generation
- Java port performance analysis and improvements
- Better Fricas interop (the libfricas.al thing is, I think, avoidable)
- Type inference improvements to allow undeclared parameters and locals
But this list may change over time.

Peter

[Waldek Hebisch]

On Sat, Dec 09, 2023 at 08:26:57PM +0000, Peter Broadbery wrote:
> On Sat, 9 Dec 2023 at 16:47, Ralf Hemmecke <ra...@hemmecke.org> wrote:
> >
> > Hi Peter,
> >
> > > I think the reference to 'Aldor folks' above is optimistic - I'd like
> > > to get a few more people helping with development (this is an
> > > optimistic plea for interested parties, to get involved btw).
> >
> > Yes, would be supergood to have more developers, but it's somewhat of a
> > hen-egg-problem. Nobody can get interested in Aldor if he/she doesn't
> > know about the advantages of Aldor. I'm afraid that FriCAS will not help
> > much. I try to have an eye on the generation of libfricas.al so that
> > Aldor is at least usable together with FriCAS, but what is needed is a
> > kind of killer application that shows why Aldor is good. Now many people
> > jump on the Julia train simply because they see faster development
> > there. It's hard to say how one can best advertise Aldor to other
> > compiler developers.
> >
>
> Yes - it is hard to sell without a strong application; unfortunately I
> don't have a strong sense of what a
> killer application would look like. I suspect that the algebra
> library contains several
> good starting points for anyone wishing to push it further.

I am affraid that it works differently: you or somebody else have
a cool idea and use Aldor to implement it. There are some
necessery (but certainly not sufficient) condition for this.
First, Aldor must be good language to solve given problem.
Now, in abstract Aldor language is good. But when doing something
new there is a lot of experimentation and for this it matters
how smooth is developement cycle. First, one needs fast compilation
and interactive testing. Clear compiler diagnostics help.
IDE and debugger can make a difference.

Next, there is need for libraries. For math Aldor library is
resonable start, but is limited. FriCAS library gives more
coverage, so symbolic math is resonably covered. But symbolic
math is rather narrow programming domain and I think that
Aldor alone here have little chance. In more general context
people want database access, web framework, GUI toolkit etc.
For heavy computations people want multithreading and there
are tricky issues of parallel garbage collection.

I am not saying that language must have all of the above,
but need enough for a succesful application.

Also, for other people to join Aldor must be easy to build
and work on their machines. Which means either being very
careful to use portable constructs or have a build/test
farm of machines (possibly virtual) running several different
configurations.

In different spirit: fact that Aldor is not written in Aldor
also is a disadvantage. You need a person that is comfortable
writing C and likes Aldor, and persons liking Aldor are
unlikely to want to develop in C. Also, given that Aldor
developers used C, Aldor users may have doubts about suitablity
of Aldor for serious projects. Of course, it is probably too
late to change this...

--
Waldek Hebisch

[Peter Broadbery]

You make a lot of good points - aldor is steadily improving as both a
code base and a development environment - I find it ok for the projects
I have, but there is space to do more to improve it. For the user experience
side of things, writing a GUI is hard. Common practice is to steal
someone else's.
In this vein, I've picked intellij as a starting point. It does
around 80% of what I want
- ie. host projects, compile on the fly, and jump between
definitions, documentation
and usages of names. Pretty much hyperdoc embedded in an editing UI.
That said, other
people want different things (or only use the One True Editor).

The java and lisp ports can provide database, web and GUI -
re-inventing those wheels would be
time consuming otherwise.

For the 'C' side of things, the Aldor code base is quite friendly -
there are no issues with
memory management (it assumes a garbage collector), and it's largely
written in a very clear manner.
As far as self-hosting goes, I have usefully experimented with writing
the type system in aldor
Rewriting the parser, codegen and optimisation passes would just take time.

I'll put a bit more effort into the build environment - I guess a
larger farm of agents would be handy.

Peter

> --
> Waldek Hebisch
>
> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZXaDlBkRHhy-0C5o%40fricas.org.

[Ralf Hemmecke]

> For the user experience side of things, writing a GUI is hard. ...

> In this vein, I've picked intellij as a starting point. It does
> around 80% of what I want - ie. host projects, compile on the fly,
> and jump between definitions, documentation and usages of names.
> Pretty much hyperdoc embedded in an editing UI.

Peter, in install.rst I have already included some text to jFriCAS and
the emacs frimacs-mode, I think it would be good to also provide some
pointers to your intellij GUI so that it becomes a little more visible.
Can you give a pointer to your installation instructions for the
intellij aldor+fricas mode?

Ralf

[Peter Broadbery]

Hi Ralf,

Instructions are here: https://github.com/pbroadbery/aldor-idea-plugin
Latest release is here:
https://github.com/pbroadbery/aldor-idea-plugin/releases/tag/release-1.3.2

It's due an update, as the underlying framework has moved on a little
over the last couple of years. That said, it ought to work.
I expect I'll have time to look at rolling a new version over the holidays.

Peter