Re: [Axiom-developer] solaris

[Aleksej Saushev]

address@hidden writes:

>>>>>>Greetings!  Are solaris and or Windows (mingw and cygwin) targets of
>>>>>>interest?  If so, what AXIOM setting works here?
>>>>>
>>>>> Solaris? Does that still exist? I don't have access to a Solaris box
>>>>> anymore. I thought it sat in the corner with Multics and MVS. I would
>>>>> have no idea how to set up the environment for it. Has anyone ported
>>>>> texlive?
>>>>
>>>>Not only Solaris does exist, it perceives a revival.
>>>>The only problem is that neither GCL nor Axiom are useful there.
>>>>ECL and FriCAS/OpenAxiom are.
>>>
>>> I'm not sure what point you are trying to make. 
>>>
>>> Axiom has been run on Lisp/VM, Symbolics, Gold Hill, AIX, and DOS.
>>> It isn't difficult to make it run anywhere but such porting efforts
>>> take time away from the primary project goals.
>>
>>Probably, but I'm speaking about platforms that are actively used and
>>developed today rather than something that went off the scene two decades ago.
>>There's no practical use for software than ran on Symbolics
>>if it doesn't run on up-to-date system.
>
> Axiom does run on 'up-to-date' systems, just not ones you want to use.
>
> Hmmm. Let me explain something to you which you seem to misunderstand.
>
> *YOU* want Axiom to run on Solaris. You have access to Solaris.
> You have the Axiom source code. You have the need. You have the time.
>
> *I* want Axiom well documented so the code lives after I die.
> I don't have access to Solaris (although I could if I made the effort).
> I post source code and changes on an almost daily basis for your use.
> I work on Axiom approximately 60 hours a week and have done so for the
> last 14 years. I have a list of current tasks I estimate will take 7
> years to complete. Time is one thing *I* don't have.
>
> I spent a lot of time making Axiom ports over the years. Indeed, I'm
> the person who rewrote it from Maclisp/LispVM to Common Lisp. So I
> am well aware that I could easily make it run on ECL/SBCL/etc. and
> on Solaris/Windows/OSX. I don't have the need. I don't have the time.
>
> It seems to me that if you want to create a Solaris port you can do it.
> And, if you want to maintain Axiom on Solaris, you can submit the port
> or self-host it and regularly update it.

Sorry, but as of today I have no guarantee that my work is not wasted.
This work has been done at least once long ago, but you haven't merged it.
Thus, what you say effectively, is that I can create my own fork,
do the same work once again and hope that you merge it. Given the past
of your project I'm more inclined to think that this hope is in vain.

You don't need to tell me about how little time you have.
I observed your project for a long time, and what I see is that you had
collaborators who made Axiom work on ECL, SBCL, and some other
implementations. Instead of making use of their work you wasted it,
so they left.

>>Not to mention that one cannot even build (original) Axiom easily
>>due to somewhat trashy build system even by standards of decade ago.
>
> Typing 'make' doesn't qualify as 'easily'? Sigh.

Yes, it doesn't qualify as "easily" since it doesn't work.
In order to make it work one has to invest a lot of effort.
So it isn't "easily".

> Of course, I authored that "somewhat trashy build system" and it was
> over 3 decades ago. But you shouldn't worry as eventually the whole
> build system will be in lisp, making it a new trashy build system
> based on technology from 1960!

Meanwhile you're going to work effectively alone.

>>Making claims that one can use Parallels, VMWare, VirtualBox, or QEMU
>>doesn't change anything. Using native port is always an advantage.
>>It sounds as if you have never actively used software that requires VM.
>
> I was a systems programmer on IBM/370 VM in 1978. I wrote portions of
> the memory management system for a high-performance improvement.
> I know a bit more about VM technology than you give me credit for.

Sorry, but how does that experience apply here? Programmers have
absolutely no knowledge of related problems unless they worked closely
with the first line of technical support.

>>> Given these tools it seems you can run Axiom without much effort.
>>> You get the added benefit that GCL is optimized for running Axiom
>>> so it runs faster in VirtualBox on GCL than on native ECL.
>>
>>Dubious until proven. Even if it is so, with FriCAS and OpenAxiom
>>I can use better CL implementation than anything of KCL family.
>
> GCL was originally AKCL which was written by Bill Schelter under
> contract with IBM specifically to support Scratchpad (now Axiom).
> I'm also a minor co-author having worked on the garbage collector
> and tail recursion. Bill Schelter shared my office on occasion.
> We worked to make AKCL run Axiom very efficiently and much better
> than existing Common Lisp implementations. 

How does this supports the claim?

>>My main point is that instead of wasting time into supporting one of the
>>worst maintained CL implementations (substandard, dormant for a decade
>>or two, very limited number of supported platforms, one man effort)
>>you'd rather have invested time into integrating build system improvements
>>Gabriel and/or Waldek did before leaving the project. One of advantages
>>of open-source software that is easy to build by anyone rather than only
>>by single developer is that it is easier for other people to become
>>involved into development. 
>
> You'd like Axiom to be rewritten to build using Autoconf, which involves
> more machinery and a dependence on specific autoconf versions (check
> the mailing list for discussions). Oh, and Autoconf uses that trashy
> build machinery called 'make' and an obscure macro language 'm4'.
> But, hey, it's "modern and up-to-date" so it's better, right?
>
> Axiom is removing external dependencies. Eventually Axiom will no
> longer need 'make' at all. Indeed, the build system will be pure lisp.

No. So far all I can see is that you miss the point totally.

Autoconf does the job for many people. Your make machinery does the job
only for you and, perhaps, for very few lucky ones.
Whether you're going to make Axiom CL-only eventually or not,
that doesn't matter at all. What matters is the collaboration.
You may have little time to work on autoconf, fine. Others did that.
All you need is to merge their work. Autoconf is a clear improvement
over what you have, and it doesn't stop elimination of dependencies or
rewriting everything in CL.

>>                              In particular, using autoconf brings you
>>closer to your goal of maintainability and modifiability than supporting
>>selected number of platforms (subset of those supported by GCL)
>>and recommending others to use Parallels or WMware.
>
> You missed the point of 'maintainability and modifiability'. The build
> system isn't what needs to be maintained. Do you understand the type
> hierarchy and the underlying mathematics?  Do you know how to add a
> Category to Axiom? Do you understand the type lattice?  Can you modify
> the Axiom interpreter? If ncAlist throws an error at level 73 in the
> call stack can you debug it?  Do you know how to maintain the Axiom
> compiler?  Do you know how to build test cases or add to the computer
> algebra test suite?
>
> The build system is a wart on the back of this hugely complex piece
> of software. There are tens of thousands of projects in sourceforge
> and github that used autoconf and are dead because nobody knows what
> they do or how to maintain and modify the main software. Only the
> lead developer knew and he documented nothing. That way lies death.

Nobody can do any serious work on a system one cannot even build.
This is especially true for working on core features like the
interpreter or adding test cases so that they work.

> As for 'wasting time'... it does seem to be my time to waste, right?
>
> I see you make a lot of assertions, snide remarks, and biased remarks
> against Axiom and GCL. What I don't see are contributions. Port Axiom
> to native Solaris. Merge the Autoconf changes you want. Use ECL. 
> Package it and post a link. That's how open source works.
>
> Axiom isn't a product, it is a research effort. 

That's because I'm not interested in fixing GCL. There're better CL
implementations around. The reason why you don't see my contributions
is that they all went to FriCAS and OpenAxiom. I don't have time to see
what happens to research effort that isn't a product.

"Package it and post a link" is not the way open source works. At least
successful projects don't work this way. Somehow they try to merge
contributions faster and manage to have more developers.

As for "snide remarks"... Well... Check the archive of your own list.
You can see noticable decline in population since 2007. The list has
degraded to a monologue with occasional cross-postings from FriCAS list.
You have alienated nearly all your original contributors.
I don't understand how you want to overcome the problem of "only the
lead developer knows..." in such conditions. Even if you manage to
finish your magnum opus, there's no guarantee for it to be continued
or even maintained.

And last, when you claim that it's only your time that is wasted,
remember not to complain all over the Internet how nobody helps you
or understands your ideas. Perhaps, they find that your ideas nice
but reject the way you implement them.


-- 
HE CE3OH...