Re: [Axiom-developer] solaris

[daly]

>>>>>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.





>> Axiom's primary goal is to be well documented, easily maintained, and
>> easily modified.  Axiom is a research effort aimed at teaching and new
>> development.
>>
>> If you need it to run on Solaris or Windows, there is no advantage in
>> using a native port. Axiom runs in Oracle's Virtualbox and in VMWare.
>
>At this point almost any reasonable person would say that Axiom is
>more of a failure as software project:
> - there exist well maintained and more maintainable forks;
> - they work at least equally well, if not better.

So, according to your metrics, Axiom is a failure.  And, according to
your reasoning by hasty generalization, 'everyone' considers Axiom a
failure. You see no value at all in Axiom. So why are you posting here?




>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.

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!




>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.





>> 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.

So use them. Axiom isn't in a competition. Axiom obviously addresses a
need you don't have. 

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. 




>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.






>                              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.




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. 

Tim