Discussion:
[Axiom-developer] Re: [Axiom-mail] Two beginner questions
Martin Rubey
2007-04-10 12:21:42 UTC
Permalink
Hi Martin,
Thanks so much for your detailed reply! So - I'm using Axiom in TeXmacs.
Without starting a new instance of Axiom from another shell, how do I access
HyperDoc?
Oh, HyperDoc does not appear when started from within Axiom? I'd call that a
bug. (I'm not using TeXmacs, anybody out there who knows?)

However, it is not so inconvenient as you might think. When Axiom is doing a
big calculation, HyperDoc becomes unresponsive. Thus I often start a second
Axiom, to do some browsing while I let Axiom compute. Maybe you want to write
a tiny shell script like

## call this file axiom and put it into your private ~/bin directory ##########
#! /bin/bash

$AXIOM/bin/axiom
$AXIOM/bin/axiom $@
###############################################################################

(i.e., first start axiom without any parameters, which you will use for
HyperDoc browsing, then start the "real" axiom process, which TeXmacs will
use.)
And how do Windows users get their Axiom help?
They don't :-(. It's too sad, but we have not found a programmer who is either

* willing to port HyperDoc to MS Windows (HyperDoc relies on X)

or

* willing to write a HyperDoc replacement as outlined in
http://wiki.axiom-developer.org/SummerOfCode2007 and many many long email
discussions.

If you have somebody handy, please tell me immediately. We can even pay a
(very) symbolic amount of money. If he decides today (deadline is April 11),
he probably can do it as a Summer of Code project and earn 4500$. In this case
he should apply here:

http://lispnyc.org/soc.clp

and mention Martin Rubey as (inofficial) co-mentor.

Martin
Bill Page
2007-04-10 14:11:37 UTC
Permalink
Post by Martin Rubey
Hi Martin,
Thanks so much for your detailed reply! So - I'm using Axiom
in TeXmacs. Without starting a new instance of Axiom from
^^^^^^^
Post by Martin Rubey
another shell, how do I access HyperDoc?
Oh, HyperDoc does not appear when started from within Axiom?
I'd call that a bug. (I'm not using TeXmacs, anybody out there
who knows?)
No. Of course HyperDoc does not start when Axiom is used under
TeXmacs. TeXmacs (normally) uses only AXIOMsys.
Post by Martin Rubey
However, it is not so inconvenient as you might think. When
Axiom is doing a big calculation, HyperDoc becomes unresponsive.
Thus I often start a second Axiom, to do some browsing while
I let Axiom compute. Maybe you want to write a tiny shell script
like
## call this file axiom and put it into your private ~/bin
#! /bin/bash
$AXIOM/bin/axiom
##############################################################
(i.e., first start axiom without any parameters, which you
will use for HyperDoc browsing, then start the "real" axiom
process, which TeXmacs will use.)
Martin, your "advice" is confusing. TeXmacs starts it's own
copy of Axiom. It cannot use a previously started process.
Post by Martin Rubey
And how do Windows users get their Axiom help?
They don't :-(. It's too sad, but we have not found a
programmer who is either
* willing to port HyperDoc to MS Windows (HyperDoc relies on X)
or
* willing to write a HyperDoc replacement as outlined in
http://wiki.axiom-developer.org/SummerOfCode2007 and many
many long email discussions.
If you have somebody handy, please tell me immediately. We
can even pay a (very) symbolic amount of money. If he decides
today (deadline is April 11), he probably can do it as a Summer
of Code project and earn 4500$. In this case he should apply
http://lispnyc.org/soc.clp
and mention Martin Rubey as (inofficial) co-mentor.
Sorry, but Summer of Code application deadline was March 26.

Regards,
Bill Page.
Martin Rubey
2007-04-10 14:51:47 UTC
Permalink
Martin, your "advice" is confusing. TeXmacs starts it's own copy of Axiom. It
cannot use a previously started process.
I didn't say that the first process should be used by TeXmacs. It is just there
for HyperDoc to pop up.

OK, I didn't know that TeXmacs uses AXIOMsys. So, maybe it is possible to
modify TeXmacs to start HyperDoc? Alternatively, write a script that first
starts axiom normally (such that HyperDoc can be used) and then starts TeXmacs
(which will start it's own axiom mode, of course)
Sorry, but Summer of Code application deadline was March 26.
LispNYC says that their deadline is today. If I misunderstood, please remove
the advertisment on the Frontpage.

Martin
Alfredo Portes
2007-04-10 15:13:16 UTC
Permalink
Post by Martin Rubey
Post by Bill Page
Sorry, but Summer of Code application deadline was March 26.
LispNYC says that their deadline is today. If I misunderstood, please remove
the advertisment on the Frontpage.
The deadline of April 11 is for mentors.
Bill Page
2007-04-10 16:01:43 UTC
Permalink
Martin,
Post by Martin Rubey
Post by Bill Page
Martin, your "advice" is confusing. TeXmacs starts it's own
copy of Axiom. It cannot use a previously started process.
I didn't say that the first process should be used by TeXmacs.
It is just there for HyperDoc to pop up.
Ok.
Post by Martin Rubey
OK, I didn't know that TeXmacs uses AXIOMsys. So, maybe it is
possible to modify TeXmacs to start HyperDoc?
Yes, it is possible. There are some instructions for this on
the wiki somewhere I think. Of course it is only applicable to
TeXmacs running on Linux. This also enables the use of Axiom
graphics.
Post by Martin Rubey
Alternatively, write a script that first starts axiom normally
(such that HyperDoc can be used) and then starts TeXmacs
(which will start it's own axiom mode, of course)
Ok.
Post by Martin Rubey
Post by Bill Page
Sorry, but Summer of Code application deadline was March 26.
LispNYC says that their deadline is today.
Student applications closed March 26. Today (April 10) is the
day that all applications must have assigned mentors. Revisions
and comments on applications submitted before March 26 will be
accepted until April 11 at which point the winners will be
posted by Google.

http://code.google.com/support/bin/answer.py?answer=60325&topic=10729

But Google has been juggling these dates a little, perhaps there
is a little slack, however I do not think any new applications
are being accepted.

Unfortunately we did not receive any eligible applications from
students regarding Axiom. :-( I think we should try to analyze
why that happened. Although I do think that Lisp is an important
programming language, I fear that Axiom's association with Lisp
is of very little benefit to Axiom. It seems that very of the
already very few student Lisp programmers are really interested
in Axiom... Does anyone have any other ideas about why we did
not receive any applications?
Post by Martin Rubey
If I misunderstood, please remove the advertisment on the
Frontpage.
I have just updated FrontPage.

Regards,
Bill Page.
Gabriel Dos Reis
2007-04-10 16:21:50 UTC
Permalink
"Bill Page" <***@synthesis.anikast.ca> writes:

[...]

| why that happened. Although I do think that Lisp is an important
| programming language, I fear that Axiom's association with Lisp
| is of very little benefit to Axiom. It seems that very of the
| already very few student Lisp programmers are really interested
| in Axiom...

We should all view Lisp as just an *assembly language* for the
Axiom runtime system. Any argument that elevates Lisp to the level of
Axiom on whatever ground completely misses the whole point.
Lisp, as any other assembly language in a high-level system, should be
rarely be advertised. It is of interest only to those who want to go
under the cover and dismantle the system -- there are very people of
those. We may very well just have an Axiom Virtual Machine that does
not require full Lisp power.

Spad and the computational aspect is what we want to advertise.

BTW, it would be great if either you or Alfredo can make a new Windows
binary (from build-improvements or wh-sandbox, whichever builds).

-- Gaby
Bill Page
2007-04-10 16:34:25 UTC
Permalink
Post by Gabriel Dos Reis
[...]
| why that happened. Although I do think that Lisp is an important
| programming language, I fear that Axiom's association with Lisp
| is of very little benefit to Axiom. It seems that very of the
| already very few student Lisp programmers are really interested
| in Axiom...
We should all view Lisp as just an *assembly language* for the
Axiom runtime system. Any argument that elevates Lisp to the
level of Axiom on whatever ground completely misses the whole
point. Lisp, as any other assembly language in a high-level system,
should be rarely be advertised. It is of interest only to those
who want to go under the cover and dismantle the system -- there
are very people of those.
Personally I agree with your conclusion, however I have been
waiting the last few years for some more Lisp-oriented people to
appear who are interested in participating in the Axiom project.
Post by Gabriel Dos Reis
We may very well just have an Axiom Virtual Machine that does
not require full Lisp power.
Yes. Aldor for example provides a "C" run-time environment that is
in essence a "Lisp" virtual machine. It is conceivable that Axiom
could be re-written in Aldor running in this environment - although
that would be **lot** of work.
Post by Gabriel Dos Reis
Spad and the computational aspect is what we want to advertise.
BTW, it would be great if either you or Alfredo can make a new
Windows binary (from build-improvements or wh-sandbox, whichever
builds).
I am willing to help anyone who wants to do this. I created the
previous Windows binary distribution more than two years ago.
I could do it again now but I think there would be greated
benefit if someone else also participates in this task.

Regards,
Bill Page.
C Y
2007-04-10 17:20:36 UTC
Permalink
Post by Bill Page
Unfortunately we did not receive any eligible applications from
students regarding Axiom. :-( I think we should try to analyze
why that happened. Although I do think that Lisp is an important
programming language, I fear that Axiom's association with Lisp
is of very little benefit to Axiom. It seems that very of the
already very few student Lisp programmers are really interested
in Axiom... Does anyone have any other ideas about why we did
not receive any applications?
A few, none of which have any particular supporting evidence:

a) There are very few students interested in CAS work
b) Axiom is not a CAS that appeals to students (this has been
discussed in the past - there are good reasons for Axiom doing things
the way it does but the benefits take time to appear).
c) Using GCL in non-ANSI mode is not a work environment that would
appeal to most lisp programmers today (no SLIME, many standard libs
won't work, etc...)
d) There is still a lot of "cleanup" work to be done before more
interesting projects that will produce user visible results will begin
e) The "learn the territory" work needed to do useful work on Axiom is
much more extensive as opposed to other projects (learning how Axiom
does things and how to change them without breakage is a process WE are
still going through, after all...) - a single summer is not a lot of
time to both get up to speed and code something interesting.

The work that is being done on the branches now will help to address
many of these problems (running on SBCL should be a big help...)

For example, I've wondered about the possibility of using the
hunchentoot code http://weitz.de/hunchentoot/ to define a "gateway" for
Axiom IO that would be used for everything - have the terminal connect
to it, a webpage interface connect to it, and a GUI connect to it.
Essentially Axiom would become the mathematical "server" and all client
interaction systems would talk to it through the same basic mechanism,
with different communications protocols being chosen based on the
interface connecting. Mathematica uses this kernel-client approach,
but they defined their own protocol to do it called MathLink. I'm
wondering if Axiom couldn't achieve the same result with the server
code in hunchentoot, and more or less for free get a web interface at
the same time. However, this requires a) sufficient knowledge of
Axiom's systems to know how to set up something like that and b) a
system on which hunchentoot and its requirements (and there are a
number of those) can be run - i.e. not GCL in its current form. When I
look at trying to do this from the SoC point of view, I can see that
Axiom would be a very intimidating prospect. Most other projects would
have similar hurdles.

I think in the future Axiom will fare better, as we are slowly cleaning
up the system and porting to SBCL et. al. That should be one big step
forward, and improved code documentation also will be a big help.

Cheers,
CY



____________________________________________________________________________________
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097
Martin Rubey
2007-04-10 19:03:26 UTC
Permalink
Unfortunately we did not receive any eligible applications from students
regarding Axiom. :-( I think we should try to analyze why that
happened. Although I do think that Lisp is an important programming language,
I fear that Axiom's association with Lisp is of very little benefit to
Axiom. It seems that very of the already very few student Lisp programmers
are really interested in Axiom... Does anyone have any other ideas about why
we did not receive any applications?
I must say that this question makes me a little angry. There is at least one
*very* simple reason why we will not participate in SOC:

I prepared a wiki page, in the contents of which I put roughly five hours,
trying to prepare something which would be focussed and possible to
tackle. (not all of this effort is visible on the page, I did do some more
thinking) In fact, I also prepared a rather detailed application for google.

I then asked for mentors to step forward. I got *very* little response, and in
the end, *not a single person* was ready to send me his/her google account
adress as required by google.

In other words, I wasted a lot of energy.

It is quite obvious to me why nobody from the lisp community wanted to write
something for axiom: the projects I proposed had nothing at all to do with
lisp... Furthermore, the last lisp project was, in my opinion, a complete
failure.

I guess that it would have been possible to prepare some lispy project, for
example cleaning up the boot compiler. This might have been interesting, but
I'm unable to prepare such a project for several reasons:

* I do not know enough about the boot/lisp internals of axiom

* I doubt that it would be very interesting for somebody not enthusiastic about
the axiom project

* I'm not sure whether it would be useful.

I believe it is not true that there are too few interested people in CAS. At
least Ondrej stated that he had more students applications than he could
mentor, and I'm convinced that this is only partially due to Pythons
popularity.

-------------------------------------------------------------------------------

Finally, I'd like to ask you for help.

It seems that I have lost (more or less) Neil Sloane. I hope I'll be able to
win him back, it is very important for me personally. I am currently extremely
close to having to stop maths (and thereby also axiom), and I badly need some
"success" stories.

I am also advertising axiom at the maths and physics departments of Vienna
university -- that's one of the bigger players in the game, by the way.

I am not sure what I can ask for, I only know what would be most helpful
(regarding non-mathematical projects):

* HyperDoc or a HyperDoc replacement on Windows

* a free Aldor, or, since this is quite unlikely to happen, SPAD becoming more
Aldor-like. Furthermore, but maybe also a first step, Axiom should understand
Aldor's "extend". Concerning SPAD becoming more Aldor-like, the most
important thing would be to allow signatures as used in the Species project:

SPECIES ==> (L: LabelType) -> CombinatorialSpecies L;

Plus(
F: SPECIES,
G: SPECIES
)(L: LabelType): CombinatorialSpecies(L) == add {
Rep == Union(left: F L, right: G L);
import from Rep;
<<implementation: Plus>>
}


(To make this easies to understand, here is a usage example:

Partition(L: LabelType): with {
<<exports: Partition>>
} == add {
<<representation: Partition>>
import from Rep;
<<implementation: Partition: auxiliary functions>>
<<implementation: Partition>>
}

is used (in Axiom roughly) like

generatingSeries()$Partition(Integer)

which would give the generating function for the Bell numbers, or

structures(set [1,2,3])$Partition(Integer)

which would return all set partitions of [1,2,3]: [[1,2,3]], [[1,2],[3]],
[[1,3],[2]], [[2,3],[1]], [[1],[2],[3]]


P2 ==> Plus(Partition, Partition)(Integer)

generatingSeries()$P2

would return twice the generating series of the set partitions.



Another remark: I'm meanwhile more convinced than ever that SPAD is simply a
subset of Aldor. A while ago, somebody said that "==" would have different
semantics, since "==" would mean "delayed evaluation" in Axiom, but that's
not quite true: it's meaning within SPAD is compatible with Aldor's meaning,
namely "constant assingment": functions in Aldor and SPAD are constants, and
the usage

f(1)==1; f(2)==1; f(n)==f(n-1)+f(n-2)

is only possible in the interpreter -- and that's a wise decision, too, as
Christian Aistleitner confirmed.



Martin
Martin Rubey
2007-04-10 19:16:45 UTC
Permalink
Dear Bill, Gaby and Waldek!

lest my recent rant stirs bad emotions, I'd like to send the three of you a

BIG "THANK YOU!"

for your work on making axiom available and stable! Sometimes I am very
impatient, and in fear I become even more impatient and more uneasy.

Also, especially Waldek earns another

BIG "THANK YOU!"

for succeeding in making my guessing package available, even if Neil Sloane was
unable to build it, for whatever reason.

I am very much indebted,

Martin
Gabriel Dos Reis
2007-04-10 22:23:06 UTC
Permalink
Martin Rubey <***@univie.ac.at> writes:

[...]

| even if Neil Sloane was unable to build it, for whatever reason.

I believe we must not underestimate people's time. If it does not
work out from the box, you'll have hard time convincing people that it
is worth their time. It is a fact I've observed many times in many
occassions. This is partly why I'm spending so much resource in
simplifying the build machinery; and I hope it does not get lost
because the Axiom community is unfocused -- even though it is a very
very tiny community.

For my class using Axiom to "succeed", I need an Axiom that does not
require heroic effort -- please don't tell me "yum", "apt-get"; they
don't work for everybody.

-- Gaby
Martin Rubey
2007-04-11 07:02:20 UTC
Permalink
I hope it does not get lost because the Axiom community is unfocused -- even
though it is a very very tiny community.
Yes, I also think that this is a great problem, although it is a problem of all
packages developed by people in their spare time or as a hobby.

For this reason I started the axiom workshops together with Ralf, and tried
hard to make them VERY focussed. If the coming workshop is as successful as the
last in terms of resulting code, it would be wonderful.


Waldek, Gaby, maybe you could spend a minute explaining in what ways
build-improvements and wh-sandbox differ. I have the impression that wh-sandbox
covers most if not all of build-improvements. Is this incorrect? If not, why
do you want to merge things back from wh-sandbox into build-improvements and
not the other way round?


Martin
Gabriel Dos Reis
2007-04-11 13:40:05 UTC
Permalink
Martin Rubey <***@univie.ac.at> writes:

[...]

| Waldek, Gaby, maybe you could spend a minute explaining in what ways
| build-improvements and wh-sandbox differ. I have the impression that wh-sandbox
| covers most if not all of build-improvements. Is this incorrect?

I believe wh-sandbox does not contain all of build-improvements as
evidenced by the recent experiment of Bill and Waldek. It is hard for
me tell which is which because when the changes are merged to
wh-sandbox, the ChangeLog does not contain proper labels, which
changes are taken, which are left out, etc and the rationale. Waldek
knows best all the details.

Furthermore, in any sane development development environment, when you
create a branch B from a tree A, you regularly merge from A to B, not
to lose track. And other branches are created as well from A, so it
is simpler to merge back to A to minimize conflicts, manual
resolutions etc. That is why, for example I try to make sure
gdr-sandbox does not stay too far from build-improvements. Anything
else tend to create unnecessary work -- I don't know for others, but I
don't enough time to spend solving problems I could avoid in the first
place.

-- Gaby
Gabriel Dos Reis
2007-04-10 22:17:25 UTC
Permalink
Martin Rubey <***@univie.ac.at> writes:

[...]

| It is quite obvious to me why nobody from the lisp community wanted to write
| something for axiom: the projects I proposed had nothing at all to do with
| lisp... Furthermore, the last lisp project was, in my opinion, a complete
| failure.

The idea that Axiom is a Lisp project is largely fantasy.
Semi ;-)

-- Gaby
C Y
2007-04-10 20:28:54 UTC
Permalink
Post by Martin Rubey
It is quite obvious to me why nobody from the lisp community wanted
to write something for axiom: the projects I proposed had nothing
at all to do with lisp... Furthermore, the last lisp project was, in
my opinion, a complete failure.
Well, to be fair it was lispnyc that was the "parent" project supporter
- if we are going to ask them to support an Axiom project it's only
reasonable to expect their potentital students to be looking for
"lispy" projects.

Just as another data point - Maxima has not qualified as an SoC mentor
on its own. In one sense it might have an easier time being a
sub-project of lispnyc than Axiom in that the hurdles to jump through
to get working on it are lower (runs on more common lisps, for one
thing) but I didn't seen any such projects.
Post by Martin Rubey
I guess that it would have been possible to prepare some lispy
project, for example cleaning up the boot compiler. This might
have been interesting, but I'm unable to prepare such a project
* I do not know enough about the boot/lisp internals of axiom
I think that's a problem with many potential Axiom projects. I know I
certainly don't have enough knowledge currently to act as a mentor.
Post by Martin Rubey
* I doubt that it would be very interesting for somebody not
enthusiastic about the axiom project
Most of our projects are going to be like that, unless we are looking
for some more "general purpose" lisp library we can make use of.
Post by Martin Rubey
* I'm not sure whether it would be useful.
Hard to say. Done well I'm sure it would be, but it is not a simple
job. I am not sure how many of the projects Axiom needs at the lisp
level at this stage are good summer projects.
Post by Martin Rubey
I believe it is not true that there are too few interested people in
CAS. At least Ondrej stated that he had more students applications
than he could mentor, and I'm convinced that this is only partially
due to Pythons popularity.
Well, that's a good sign.
Post by Martin Rubey
Finally, I'd like to ask you for help.
It seems that I have lost (more or less) Neil Sloane. I hope I'll be
able to win him back, it is very important for me personally. I am
currently extremely close to having to stop maths (and thereby also
axiom), and I badly need some "success" stories.
Sorry to hear that!
Post by Martin Rubey
I am also advertising axiom at the maths and physics departments of
Vienna university -- that's one of the bigger players in the game,
by the way.
If I may ask, what applications would they be likely to use Axiom for?
Post by Martin Rubey
I am not sure what I can ask for, I only know what would be most
* HyperDoc or a HyperDoc replacement on Windows
One question - as I understand it, AXIOMsys works on Windows but the
parent program axiom does not. Would a HyperDoc for Windows also
require a new communications mechanism? Doing this straight from lisp
(ala hunchentoot or something similar) would be my preference, but
again it's probably not simple.

In this problem being on a non-ANSI lisp without the support of most of
the library of Lisp goodies available today hurts.
Post by Martin Rubey
* a free Aldor, or, since this is quite unlikely to happen, SPAD
becoming more Aldor-like. Furthermore, but maybe also a first step,
Axiom should understand Aldor's "extend". Concerning SPAD becoming
more Aldor-like, the most important thing would be to allow
signatures as used in the Species
Has anyone attempted ANY SPAD compiler hacking as yet? To the best of
my knowledge that area is almost completely uncharted waters.

Martin, is the most important thing for you to have available a Windows
binary with the Guess package successfully installed? I can see where
we might be able to put together a NSIS based installer of a merger of
the latest build-improvements, the Guess package and maybe Emacs as a
GUI for Windows, if that would help, but getting to the point where we
can be reasonably sure of not running into the same sort of issue that
originally caused the problems with the Guess package is (IMO) a ways
down the road. (Not that I'm qualified to have an opinion - Tim, Gaby,
or Waldek would be a much better source.) I might be able to take a
stab at compiling a Windows release, but I'd be starting from square
one and I'm not completely sure I'll have access to a Windows box. If
that would be a very significant help, I will look into it - let me
know.

Cheers,
CY



____________________________________________________________________________________
Now that's room service! Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097
Bill Page
2007-04-10 20:57:44 UTC
Permalink
C Y,

I can't resist "jumping" at the conclusion of your last email...
Post by C Y
...
Martin, is the most important thing for you to have available a
Windows binary with the Guess package successfully installed?
I can see where we might be able to put together a NSIS based
installer of a merger of the latest build-improvements, the
Guess package and maybe Emacs as a GUI for Windows, if that
would help,
Yes, that is very easy to accomplish.
Post by C Y
but getting to the point where we can be reasonably sure of not
running into the same sort of issue that originally caused the
problems with the Guess package is (IMO) a ways down the road.
(Not that I'm qualified to have an opinion - Tim, Gaby, or
Waldek would be a much better source.)
I would not anticipate any problems at all - especially if we
can merge changes from wh-sandbox back into build-improvements.
Post by C Y
I might be able to take a stab at compiling a Windows release,
but I'd be starting from square one and I'm not completely sure
I'll have access to a Windows box. If that would be a very
significant help, I will look into it - let me know.
I hope Martin says "yes". Surely you can find a Windows box down
at the K-mart for not much money. ;) And I as I have said several
times before: I have done this before and I would be very glad
to help someone do it again.

Regards,
Bill Page.
Gabriel Dos Reis
2007-04-10 22:30:32 UTC
Permalink
"Bill Page" <***@synthesis.anikast.ca> writes:

[...]

| I would not anticipate any problems at all - especially if we
| can merge changes from wh-sandbox back into build-improvements.

We should. I see no compelling reason why we should hae parallel
build effort on branches from build-improvements and keep them
separate.

-- Gaby
Martin Rubey
2007-04-10 21:21:06 UTC
Permalink
Post by C Y
If I may ask, what applications would they be likely to use Axiom for?
research and teaching.
Post by C Y
Martin, is the most important thing for you to have available a Windows
binary with the Guess package successfully installed?
Although that would be nice, it won't help too much. A functional HyperDoc (or
a HyperDoc replacement) is a must, because, how do you expect an MS Windows
user (used to clicking on buttons) to find out how to express and solve an ODE?
I guess, you won't teach him how to use asq or, gasp!, grep?

If you do put together a new windows binary (and: please do!), and if you want
to include my package, please note that its most recent version depends on
several algebra fixes currently only applied to wh-sandbox.

Therefore, I guess it would be more useful (especially for non-windows
developers) to help Gaby and Waldek merge there distributions (although I must
admit that I do not even know what functionality of build-improvements is
missing from wh-sandbox).
Post by C Y
Tim Daly reported successfully building HyperDoc under cygwin on Windows and
accessing it via Xming (an X-windows server for Windows).
But didn't he say that it was somewhat non-functional, namely, browse wouldn't
work?
Post by C Y
I think that it is a real possibility to build both HyperDoc and Axiom
graphics under cygwin in this manner. Cygwin is a "unix emulator" for
windows. GCL however currently only builds under MSYS/MinGW which a native
Windows build environment. Requiring both cygwin and MSYS/MinGW to build
Axiom on Windows is a bit of a heavy requirement but it is possible.
Do you think it would be possible to bundle this up in a (albeit huge) package,
that works more or less out of the box? (However, again: it makes sense only if
HyperDoc browse works)

This would be WONDERFUL!

You see, I'm a bit reluctant to drive people into developing HyperDoc too much,
since what I really want is a bit different. (namely, a HyperDoc replacement
running on any good internet browser, having the functionality of HyperDoc but
moreover understanding documentation written in LaTeX with ALLPROSE / aldoc
conventions.)

But if it is not tooooo big a project, such a bundle would be, again:
WONDERFUL.

Martin
C Y
2007-04-10 22:14:24 UTC
Permalink
Post by Martin Rubey
Post by C Y
I think that it is a real possibility to build both HyperDoc and Axiom
graphics under cygwin in this manner. Cygwin is a "unix emulator" for
windows. GCL however currently only builds under MSYS/MinGW which a native
Windows build environment. Requiring both cygwin and MSYS/MinGW to build
Axiom on Windows is a bit of a heavy requirement but it is possible.
Do you think it would be possible to bundle this up in a (albeit huge) package,
that works more or less out of the box? (However, again: it makes sense only if
HyperDoc browse works)
That might be technically possible but large doesn't even begin to
describe it. At that point we might as well think about bundling a live
ISO with an emulator and do things that way - it would probably be simpler.
Post by Martin Rubey
This would be WONDERFUL!
Keep in mind that this would be an X Windows application under Microsoft
Windows, and would not match at all closely the look and feel of any
normal Windows application. Also, it may conflict with existing
cygwin/X setups - not sure about that.
Post by Martin Rubey
You see, I'm a bit reluctant to drive people into developing HyperDoc too much,
since what I really want is a bit different. (namely, a HyperDoc replacement
running on any good internet browser, having the functionality of HyperDoc but
moreover understanding documentation written in LaTeX with ALLPROSE / aldoc
conventions.)
WONDERFUL.
I don't quite know about the technical difficulty, as it's been a while
since I have dealt with any of these systems. I would expect such a
bundle to be HUGE.

If we can successfully release a "normal" Windows binary perhaps we can
look next at bundling cygwin and X for an "all-in-one" type release.

Cheers,
CY
Bill Page
2007-04-10 22:54:36 UTC
Permalink
Post by C Y
Post by Martin Rubey
Post by C Y
I think that it is a real possibility to build both HyperDoc
and Axiom graphics under cygwin in this manner. Cygwin is a
"unix emulator" for windows. GCL however currently only builds
under MSYS/MinGW which a native Windows build environment.
Requiring both cygwin and MSYS/MinGW to build Axiom on Windows
is a bit of a heavy requirement but it is possible.
Do you think it would be possible to bundle this up in a
(albeit huge) package, that works more or less out of the
box? (However, again: it makes sense only if HyperDoc browse
works)
That might be technically possible but large doesn't even begin
to describe it.
No. Let's be clear. The *build* environment would require both
cygwin and MSYS/MinGW. That is large but not huge. I run both of
these easily in my usual Windows development environment.

But the *run-time* (binary) environment would not be much bigger
than the current Linux and Windows binaries. Applications built
with cygwin require only the presence of the cygwin dll library.
There used to be a license issue about distributing packages
containing only that part of cygwin - I am not sure if that is
still the case or not - but in any case requiring that the user
install a minimal cygwin environment as a prerequiste is not all
that bad. Applications built with MSYS/MinGW on the other hand
run natively on Windows and do not require any extra specially
licensed libraries.

cygwin provides a online download and update facility similar
to Debian apt-get, so if it was possible to package Axiom for
cygwin this way, it would make it very easy for Windows users
to install Axiom.
Post by C Y
At that point we might as well think about bundling a live
ISO with an emulator and do things that way - it would probably be simpler.
A live ISO that will boot under VMware was developed by Alfredo
and is already available. See

http://wiki.axiom-developer.org/DoyenCD
Post by C Y
Post by Martin Rubey
This would be WONDERFUL!
In principle it would be easy to create a new DoyenCD with
Axiom compiled from wh-sandbox which would already contain
Martin's guess package.
Post by C Y
Keep in mind that this would be an X Windows application
under Microsoft Windows, and would not match at all closely
the look and feel of any normal Windows application.
That is true, however Xming integrates very well with Windows
in my opinion. The X managed windows appear along with the
windows managed directly by Microsoft Windows. It is true
that they have an "odd" menu system by Windows standards but
in other respects they look familiar.
Post by C Y
Also, it may conflict with existing cygwin/X setups - not
sure about that.
No, I don't think so. But in general I avoid running the
X windows server under cygwin. I like Xming much better.
Post by C Y
Post by Martin Rubey
You see, I'm a bit reluctant to drive people into developing
HyperDoc too much, since what I really want is a bit different.
(namely, a HyperDoc replacement running on any good internet
browser, having the functionality of HyperDoc but moreover
understanding documentation written in LaTeX with ALLPROSE
/ aldoc conventions.)
But if it is not tooooo big a project, such a bundle would be,
again: WONDERFUL.
I don't quite know about the technical difficulty, as it's been
a while since I have dealt with any of these systems. I would
expect such a bundle to be HUGE.
No, I don't agree. It is not likely to be any bigger than the
existing HyperDoc application under Linux - smaller perhaps
because the web browser itself would presumably be just be an
easily satisfied pre-requisite, i.e. all Windows users have at
least IExplorer and FireFox is very easy it acquire.
Post by C Y
If we can successfully release a "normal" Windows binary perhaps
we can look next at bundling cygwin and X for an "all-in-one"
type release.
That's the easy part. Finding a way to build HyperDoc and
Axiom Graphics as cygwin applications while running AXIOMsys
as a native application with the right support for sockets
might be the hard part.

Regards,
Bill Page.
Gabriel Dos Reis
2007-04-10 22:32:09 UTC
Permalink
Martin Rubey <***@univie.ac.at> writes:


[...]

| Bill writes:
|
| > Tim Daly reported successfully building HyperDoc under cygwin on Windows and
| > accessing it via Xming (an X-windows server for Windows).

GCL-2.6.8pre cannot build on cygwin; I don't know how to get the whole
thing.

-- Gaby
Gabriel Dos Reis
2007-04-10 22:28:52 UTC
Permalink
C Y <***@yahoo.com> writes:

[...]

| > * I do not know enough about the boot/lisp internals of axiom
|
| I think that's a problem with many potential Axiom projects. I know I
| certainly don't have enough knowledge currently to act as a mentor.

At this point, there is no much to improve at the boot/lisp internals
per see. But, you definitely want to integrate the new parser into
the compiler and share more between in the intepreter and the
compiler.

Also, people should really look at the trace file and try to correct
the algebra files -- there are quite a few bugs there.

[...]

| > I am not sure what I can ask for, I only know what would be most
| > helpful (regarding non-mathematical projects):
| >
| > * HyperDoc or a HyperDoc replacement on Windows
|
| One question - as I understand it, AXIOMsys works on Windows but the
| parent program axiom does not. Would a HyperDoc for Windows also
| require a new communications mechanism? Doing this straight from lisp
| (ala hunchentoot or something similar) would be my preference, but
| again it's probably not simple.

I see no fundamental reason why both process should not be threads in
the same problem and therefore bypass the socket stuff.
Bill Page
2007-04-10 23:34:56 UTC
Permalink
Post by Gabriel Dos Reis
...
|
| One question - as I understand it, AXIOMsys works on Windows but the
| parent program axiom does not. Would a HyperDoc for Windows also
| require a new communications mechanism? Doing this straight from lisp
| (ala hunchentoot or something similar) would be my preference, but
| again it's probably not simple.
Currently AXIOMsys can only be built using gcl on windows. The only
available version of gcl for windows is built as a native windows application
using MSYS/MinGW. There is an experimental version of Axiom built
with SBCL for Windows by Gregory Vanuxem but as far as I know it
does not include socket support. For that matter, neither does the
gcl version of Axiom for windows. Axiom has it's own routines written
in C that provide the socket interface and so far this has not been
incorporated into the version of Axiom for Windows.

If by "parent program" you mean "sman" and "session"? Since these are
C programs there is no good reason not be able to compile them under
either cygwin or MSYS/MinGW (native windows). The trick is to get the
right support for sockets. On the other hand, 'hyperdoc' and 'graphics'
both require X-windows. This is something that (as far as I know) is only
available under cygwin.
Post by Gabriel Dos Reis
I see no fundamental reason why both process should not be threads in
the same problem and therefore bypass the socket stuff.
Bill Page
2007-04-10 20:48:12 UTC
Permalink
Post by Martin Rubey
lest my recent rant stirs bad emotions, I'd like to send the
. three of you a
Post by Martin Rubey
BIG "THANK YOU!"
for your work on making axiom available and stable! Sometimes
I am very impatient, and in fear I become even more impatient
and more uneasy.
Don't worry. I understand very well the reasons for your frustration.
Post by Martin Rubey
Also, especially Waldek earns another
BIG "THANK YOU!"
for succeeding in making my guessing package available, even if
Neil Sloane was unable to build it, for whatever reason.
Well, it is difficult to help people who do not ask for help ...
Post by Martin Rubey
I am very much indebted,
As are we all.
Post by Martin Rubey
.. Does anyone have any other ideas about why we did not
receive any applications?
I must say that this question makes me a little angry. There is
at least one *very* simple reason why we will not participate in
I prepared a wiki page, in the contents of which I put roughly
five hours, trying to prepare something which would be focussed
and possible to tackle. (not all of this effort is visible on the
page, I did do some more thinking) In fact, I also prepared a
rather detailed application for google.
I then asked for mentors to step forward. I got *very* little
response, and in the end, *not a single person* was ready to
send me his/her google account adress as required by google.
In other words, I wasted a lot of energy.
I am sorry Martin. I recall clearly the SOC wiki page you created
but I do not recall your request for mentors, as such. Certainly
I was willing. In fact a couple of weeks later when Hoew asked me
if the Axiom project was interested in participating in SOC via
LispNYC, I immediately said "yes!" and in that case I did register
online with Google as a mentor under the LispNYC project, but I
did not have to supply Hoew directly with my Google email account.
Perhaps there was some misunderstanding of the requirements?
Post by Martin Rubey
It is quite obvious to me why nobody from the lisp community
wanted to write something for axiom: the projects I proposed
had nothing at all to do with lisp...
I added two new items to your SOC 2007 page which were specifically
directed at people with Lisp experience as soon as Hoew invited us
to participate.
Post by Martin Rubey
Furthermore, the last lisp project was, in my opinion, a complete
failure.
Why do you say that? Have you looked at the code that Kai produced?
I would say that the fact that we are not yet using any of this code
is not related to Kai's effort at all. I counted it as successful
because at least he showed that it was possible to work with Axiom
using common lisp tools and how to adapt Axiom's boot code to better
interface with an externally supplied user interface based on a web
browser. Personally I think that was a lot to accomplish during one
summer project.
Post by Martin Rubey
I guess that it would have been possible to prepare some lispy
project, for example cleaning up the boot compiler. This might
have been interesting, but I'm unable to prepare such a project
No, that is not the kind of project I would consider suitable for SOC.
Post by Martin Rubey
* I do not know enough about the boot/lisp internals of axiom
* I doubt that it would be very interesting for somebody not
enthusiastic about the axiom project
* I'm not sure whether it would be useful.
I would be useful. In fact we already have at least two people doing
that: Gaby and Waldek - although that is not their only objective.
Post by Martin Rubey
I believe it is not true that there are too few interested people
in CAS.
I never said that. I think that C.Y. might have argued that in
another email. I also do not agree with that. What I said was that
there are first of all only a few students currently interested in
Lisp and of those there seem to be only a few who are interested
in Axiom. In fact the only proposals that LispNYC did receive that
could be considered related to Axiom did not even seem to realize
that what they were proposing was already a basic part of Axiom!
I replied to these applicants and at least one of them has since
joined the Axiom developer email list.
Post by Martin Rubey
At least Ondrej stated that he had more students applications
than he could mentor, and I'm convinced that this is only
partially due to Pythons popularity.
I disagree.
Martin Rubey
2007-04-10 21:40:34 UTC
Permalink
Post by Martin Rubey
* a free Aldor, or, since this is quite unlikely to happen,
I still think it is possible. Please keep up the pressure however you
can. Most recently (two weeks ago) it was publicly promised by Steven Watt
that there would be some news within a week. But we are still waiting ...
well, the trouble really is: in what sense do you expect aldor to be open
source? would you be happy if it was open source but without granting the right
for redistribution? I expect something of this sort. And, although I believe
that this would still be great, I also believe that in this case it would be
better to have a free implementation of the Aldor language, too, even if it
implements only a subset and is, say, much slower.

This model works very well in the Lisp world, and it would prevent another
MuPAD catastrophy from happening...
I think it would be great if you and other members of the "Species project"
could find a way to make your work more visible (and therefore more
interesting) to others.
There are two developers: Ralf and me. We do have at least two advisors:
Nicolas Thiery for maths and design and Christian Aistleitner for Aldor.
I still do not completely understand the objectives and what has been
accomplished so far.
We implemented Andre Joyal's theory of "Combinatorial Species", as developed by
Francois Bergeron, Gilbert Labelle and Pierre Leroux

http://en.wikipedia.org/wiki/Combinatorial_species

in a *very* mathematical manner. In one sentence: a species is a collection of
labelled objects, closed under relabelling.

I.e., to define binary trees (the labels are on the leaves) they write:

B = X + B*B

and we write

macro {
CS == CombinatorialSpecies;
X == SingletonSpecies;
}
B(L: LabelType): CS L == Plus(X, Times(B, B))(L) add;

I hope, you see the similarity. To define forests of binary trees we continue
with

F(L: LabelType): CS L == Compose(SetSpecies, B)(L) add;

So far we can

* generate exhaustively the structures - and also use them, i.e., for example,
write a function that computes the height of a given tree.

* experimentally, generate exhaustively the isomorphismtypes of the structures.
For example, we can generate all set partitions, but also all integer
partitions.

* compute the generating function (in the sense of a lazy stream) for the
structures, the isomorphismtypes, but also a formal power series that
generalises these two generating functions, namely, the cycle index series.

Our next goals are

* extend to multisorted species, i.e., species where the labels are structured
according to colour

and maybe

* investigate vectorial species, i.e., functors from the category of finite
sets into the category of finite dimensional vector spaces

* investigate whether we can compute the molecular expansion of a species


Martin
C Y
2007-04-10 21:24:33 UTC
Permalink
Post by Bill Page
Post by Martin Rubey
I believe it is not true that there are too few interested people
in CAS.
I never said that. I think that C.Y. might have argued that in
another email. I also do not agree with that.
What I suggested was a possible cause of the SoC result - that there
are very few students interested in CAS work. I also mentioned that I
was only listing possible causes without having data to back them up.
I am not arguing that IS the case, only suggesting it as a possible
casue of lack of SoC interest (if it WERE true, it would explain it - I
do not know if it is true.)
C Y
2007-04-10 21:30:35 UTC
Permalink
Post by Bill Page
Post by C Y
I can see where we might be able to put together a NSIS based
installer of a merger of the latest build-improvements, the
Guess package and maybe Emacs as a GUI for Windows, if that
would help,
Yes, that is very easy to accomplish.
OK. I am of the opinion that, given the already large size of Axiom,
it is worth bundling a binary of Emacs and making that the default UI
unless/until something better becomes available. Anyone else have an
opinion on that one?
Post by Bill Page
I would not anticipate any problems at all - especially if we
can merge changes from wh-sandbox back into build-improvements.
OK.
Post by Bill Page
I hope Martin says "yes". Surely you can find a Windows box down
at the K-mart for not much money. ;) And I as I have said several
times before: I have done this before and I would be very glad
to help someone do it again.
We are long overdue for a Windows release. I might be able to get
access to a box in about 3 weeks, and if I can I'll set up an Axiom
build environment and take a stab at it. I'm a Linux guy myself but we
really need something newer than the current binary...

Cheers,
CY



____________________________________________________________________________________
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097
C Y
2007-04-10 21:56:30 UTC
Permalink
Post by Martin Rubey
well, the trouble really is: in what sense do you expect aldor to be
open source? would you be happy if it was open source but without
granting the right for redistribution?
Arrgh. In other words, we still couldn't integrate it into the Axiom
system?
Post by Martin Rubey
I expect something of this sort.
While of course it is the right of the copyright holders to do as they
see fit, I'd be curious as to what they would expect to gain from this
Post by Martin Rubey
it would be better to have a free implementation of the Aldor
language, too, even if it implements only a subset and is, say,
much slower.
SPAD will probably become that, if it must. Which would pretty much
leave Aldor where it is now - is there another potential large scale
application for the Aldor language that can't be adequately filled by
O'Caml, Haskell, or one of the other such languages available today?

There are some potentially interesting long term projects that could be
investigated with either SPAD or Aldor in terms of integrating proof
systems with Axiom, and the flexibility to work deeply with the
language implementation and even the language definition itself could
wind up being important. Either way, something definite on Aldor would
be nice - even if we find out for sure we can't use it at least we
could then devote time to SPAD knowing we wouldn't have the rug yanked
out from under us by an Aldor release (i.e. it would be work we do
actually need to do and couldn't avoid by waiting).

Cheers,
CY




____________________________________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
C Y
2007-04-10 21:56:48 UTC
Permalink
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121
C Y
2007-04-11 00:42:16 UTC
Permalink
Post by Bill Page
If by "parent program" you mean "sman" and "session"? Since these are
C programs there is no good reason not be able to compile them under
either cygwin or MSYS/MinGW (native windows). The trick is to get the
right support for sockets. On the other hand, 'hyperdoc' and
'graphics' both require X-windows. This is something that (as far
as I know) is only available under cygwin.
There are X servers for Windows other than cygwin but I believe they
are all commercial - nor do I know if we could successfully work with
them. The correct approach here is to work with some cross platform
toolkit and avoid the need for an X server, but that will take time
:-(. Socket support on Windows should be possible - IIRC Maxima makes
use of this.
Post by Bill Page
Post by Gabriel Dos Reis
I see no fundamental reason why both process should not be threads
in the same problem and therefore bypass the socket stuff.
Bill Page
2007-04-11 00:59:20 UTC
Permalink
Post by C Y
Post by Bill Page
If by "parent program" you mean "sman" and "session"? Since these are
C programs there is no good reason not be able to compile them under
either cygwin or MSYS/MinGW (native windows). The trick is to get the
right support for sockets. On the other hand, 'hyperdoc' and
'graphics' both require X-windows. This is something that (as far
as I know) is only available under cygwin.
There are X servers for Windows other than cygwin but I believe they
are all commercial - nor do I know if we could successfully work with
them.
No. I meant X-windows *client* support, i.e. the X libraries and associated
machinery. Both hyperdoc and graphics require this X-windows client
support.

The X server component is no problem. A good free X server is provided
by Xming on Windows:

http://sourceforge.net/projects/xming

I would not recommend running the X server component under cygwin.
I've tried it and I think it sucks. If you really want this, then I think you
really want Linux.
Post by C Y
The correct approach here is to work with some cross platform
toolkit and avoid the need for an X server, but that will take time
I am not convinced that this is the correct approach. It works for
some, e.g. GIMP, but it still looks ugly to me. I am much more
in favor of the web-browser-as-gui solution for cross platform
support. But both of these are too much work for the resources
we have available right now.
Post by C Y
:-(. Socket support on Windows should be possible - IIRC
Maxima makes use of this.
Certainly GCL supports sockets on Windows. No problem. But
Axiom rolls it's own socket support, so linking it into GCL on
Windows is a little technically challenging (but not too difficult,
I think). But probably it would be better to modify AXIOM to use
the socket support built in to Lisp (GCL).
Post by C Y
...
Regards,
Bill Page.
C Y
2007-04-11 03:34:13 UTC
Permalink
Post by Bill Page
No. I meant X-windows *client* support, i.e. the X libraries and associated
machinery. Both hyperdoc and graphics require this X-windows client
support.
Ah.
Post by Bill Page
The X server component is no problem. A good free X server is provided
http://sourceforge.net/projects/xming
Neat! Clearly I'm behind on the state of the art in free Windows X servers.
Post by Bill Page
I would not recommend running the X server component under cygwin.
I've tried it and I think it sucks. If you really want this, then I
think you really want Linux.
Agreed - that was the context I was originally considering for X
Hyperdoc on Windows. Xming changes things.
Post by Bill Page
Post by C Y
The correct approach here is to work with some cross platform
toolkit and avoid the need for an X server, but that will take time
I am not convinced that this is the correct approach. It works for
some, e.g. GIMP, but it still looks ugly to me. I am much more
in favor of the web-browser-as-gui solution for cross platform
support. But both of these are too much work for the resources
we have available right now.
GIMP uses GTK, which I agree is not very good for a native Windows look
and feel. TK with the Tile extensions is somewhat better, and there are
other alternatives as well (QT is excellent, but does not have robust
lisp bindings). The Right Way to do native behavior would be a robust
McCLIM with native backends for each platform, but that is likely many
man-years of work away :-(.

In theory, a proper communications API would allow browsers, GUIs, and
anything else to communicate with the same core with minimal trouble -
IIRC Kai and I agreed that was a logical point to focus initial efforts,
the last time the issue came up.
Post by Bill Page
Post by C Y
:-(. Socket support on Windows should be possible - IIRC
Maxima makes use of this.
Certainly GCL supports sockets on Windows. No problem. But
Axiom rolls it's own socket support, so linking it into GCL on
Windows is a little technically challenging (but not too difficult,
I think). But probably it would be better to modify AXIOM to use
the socket support built in to Lisp (GCL).
Agreed. Maybe an overlay to hide implementation specific socket APIs
would be good, but I'm not familiar with the options except knowing
about the existence of usocket: http://common-lisp.net/project/usocket/
Apparently GCL is not on the usocket list yet.

Cheers,
CY
Waldek Hebisch
2007-04-11 19:54:38 UTC
Permalink
Post by Martin Rubey
Waldek, Gaby, maybe you could spend a minute explaining in what ways
build-improvements and wh-sandbox differ. I have the impression that wh-sandbox
covers most if not all of build-improvements. Is this incorrect? If not, why
do you want to merge things back from wh-sandbox into build-improvements and
not the other way round?
Concerning parts of build-improvements included in wh-sandbox let
me repeat (with little correction) what I wrote in another mail:

The src/boot directory and src/scripts/document.in is synced with
build improvements 485.
In src/interp and src/algebra I belive that I picked all changes
that I now want to go into wh-sandbox -- in this sense both directories
are synced, but differences are significant (I may use some changes later
but ATM other changes conflict with my work). Other directories
(src/lib, src/clef, src/sman, src/graph, src/hyper) were synced
with build improvements 358 and need re-syncing.

In particular many portability improvements to build-improvements
are still not merged.

If you look at line counts (and skip genereated files) probably the
biggest part of build-improvements not include in wh-sandbox is in
src/interp/Makefile.pamphlet and src/algebra/Makefile.pamphlet. ATM
this difference is intentional, algebra build in wh-sandbox is quite
different then in build-improvements, and in interp Makefile I belive
that wh-sandbox has similar functionality as build-improvements, but
the Makefile is simpler.

I intend to merge other changes but I considered wholesale merge
inpractical (it would generate too much breakage). So my tactic
was to merge configure part (most other changes depend on configure),
boot part (easy to do and needed for my other work), and
interp changes (needed to avoid major breakage). In principle
merging the other part should be now easier, but there are
some conflicts there...

What wh-sandbox has which is not in build-improvements:
1) A lot of unused code is removed from wh-sandbox
2) depsys boot files are converted to shoe (and bootstrap
Lisp is removed). IIUC Gaby is doing similar thing
in build-improvements.
3) new algebra bootstrap
4) many bug fixes
--
Waldek Hebisch
***@math.uni.wroc.pl
Gabriel Dos Reis
2007-04-11 20:25:08 UTC
Permalink
Waldek Hebisch <***@math.uni.wroc.pl> writes:

[...]

| 2) depsys boot files are converted to shoe (and bootstrap
| Lisp is removed). IIUC Gaby is doing similar thing
| in build-improvements.

This is something I would have liked to go into build-improvements so
that I don't have to do the same thing.

-- Gaby
Waldek Hebisch
2007-04-12 14:20:42 UTC
Permalink
Post by Gabriel Dos Reis
| One question - as I understand it, AXIOMsys works on Windows but the
| parent program axiom does not. Would a HyperDoc for Windows also
| require a new communications mechanism? Doing this straight from lisp
| (ala hunchentoot or something similar) would be my preference, but
| again it's probably not simple.
I see no fundamental reason why both process should not be threads in
the same problem and therefore bypass the socket stuff.
g***@cs.tamu.edu
2007-04-12 14:30:18 UTC
Permalink
Post by Gabriel Dos Reis
| One question - as I understand it, AXIOMsys works on Windows but the
| parent program axiom does not. Would a HyperDoc for Windows also
| require a new communications mechanism? Doing this straight from lisp
| (ala hunchentoot or something similar) would be my preference, but
| again it's probably not simple.
I see no fundamental reason why both process should not be threads in
the same problem and therefore bypass the socket stuff.
Gabriel Dos Reis
2007-04-12 14:40:56 UTC
Permalink
***@cs.tamu.edu writes:

| Quoting Waldek Hebisch <***@math.uni.wroc.pl>:
|
| > Gabriel Dos Reis wrote:
| >> C Y <***@yahoo.com> writes:
| >> | One question - as I understand it, AXIOMsys works on Windows but the
| >> | parent program axiom does not. Would a HyperDoc for Windows also
| >> | require a new communications mechanism? Doing this straight from lisp
| >> | (ala hunchentoot or something similar) would be my preference, but
| >> | again it's probably not simple.
| >>
| >> I see no fundamental reason why both process should not be threads in
| >> the same problem and therefore bypass the socket stuff.
Waldek Hebisch
2007-04-14 22:31:29 UTC
Permalink
Post by Gabriel Dos Reis
[...]
| 2) depsys boot files are converted to shoe (and bootstrap
| Lisp is removed). IIUC Gaby is doing similar thing
| in build-improvements.
This is something I would have liked to go into build-improvements so
that I don't have to do the same thing.
It looks that you just re-did work on last file that I converted
(I left non-bootstrap files as-is).
--
Waldek Hebisch
***@math.uni.wroc.pl
g***@cs.tamu.edu
2007-04-14 23:01:32 UTC
Permalink
Post by Waldek Hebisch
Post by Gabriel Dos Reis
[...]
| 2) depsys boot files are converted to shoe (and bootstrap
| Lisp is removed). IIUC Gaby is doing similar thing
| in build-improvements.
This is something I would have liked to go into build-improvements so
that I don't have to do the same thing.
It looks that you just re-did work on last file that I converted
(I left non-bootstrap files as-is).
Hi,

As I said, if there is something valuable to the entire comunity,
we should try to get it proposed to the "upper" stream (i.e. where
we branched from).

What I committed before leaving was part of a larger patch. If it is
worked already done, I'm sad to see it wasn't proposed for build-improvements.
Because I would have concentrated on some other paters.

There are more changes to come, but not before I find a more
reliable network connection and ways to install autoconf-2.60 on
mingw/msys.
Post by Waldek Hebisch
--
Waldek Hebisch
Bill Page
2007-04-15 06:12:14 UTC
Permalink
Post by g***@cs.tamu.edu
There are more changes to come, but not before I find a more
reliable network connection and ways to install autoconf-2.60
on mingw/msys.
What problems are you having with autoconf on MSYS/MinGW?

I built autoconf-2.61 and m4-1.4.9 directly from the gnu distribution
sources. Provided you have upgraded m4 first, autoconf passes all
tests.

Apparently you can also install autoconf-2.61 and m4-1.4.7 binaries
from:

http://sourceforge.net/project/showfiles.php?group_id=148008

I ran build-setup.sh with autoconf-2.61 to create a new ./configure
and built build-improvements on my Solaris 10.2 x86 system and on
Windows without any problems.

Is there any particular reason you want to continue using the older
version autoconf-2.60? (I think you can, but I haven't actually built
2.60 on MSYS/MinGW.)

Regards,
Bill Page.
g***@cs.tamu.edu
2007-04-15 09:56:15 UTC
Permalink
Post by Bill Page
Post by g***@cs.tamu.edu
There are more changes to come, but not before I find a more
reliable network connection and ways to install autoconf-2.60
on mingw/msys.
What problems are you having with autoconf on MSYS/MinGW?
Build of Autoconf-2.6[01] fails for me with:

"The system cannot find the specified file"

I've spent some time understanding this; I made some progress, but not
to the point of getting pass that failure. my frustration with windows
is only growing.
Post by Bill Page
I built autoconf-2.61 and m4-1.4.9 directly from the gnu distribution
sources. Provided you have upgraded m4 first, autoconf passes all
tests.
I'm using m4-1.4.9 and ActivePerl-5.8.9 build 820.
Post by Bill Page
Apparently you can also install autoconf-2.61 and m4-1.4.7 binaries
http://sourceforge.net/project/showfiles.php?group_id=148008
yes, i donwloaded the autoconf package from there last night; I've
not tried that version yet.
Post by Bill Page
I ran build-setup.sh with autoconf-2.61 to create a new ./configure
and built build-improvements on my Solaris 10.2 x86 system and on
Windows without any problems.
Is there any particular reason you want to continue using the older
version autoconf-2.60? (I think you can, but I haven't actually built
2.60 on MSYS/MinGW.)
my three main linux boxes are running that version,
Post by Bill Page
Regards,
Bill Page.
Bill Page
2007-04-15 19:20:53 UTC
Permalink
Post by g***@cs.tamu.edu
...
"The system cannot find the specified file"
I've spent some time understanding this; I made some progress,
but not to the point of getting pass that failure. my
frustration with windows is only growing.
I think it best to avoid the trap that most linux developers
fall into when working with Windows. As far as I am concerned
it is just another operating system ...
Post by g***@cs.tamu.edu
Post by Bill Page
I built autoconf-2.61 and m4-1.4.9 directly from the gnu
distribution sources. Provided you have upgraded m4 first,
autoconf passes all tests.
I'm using m4-1.4.9 and ActivePerl-5.8.9 build 820.
I have:

$ m4 --version
m4 (GNU M4) 1.4.9

$ perl --version

This is perl, v5.6.1 built for msys

$ gcc --version
gcc.exe (GCC) 3.4.2 (mingw-special)
$ make --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-msys

----------

My first guess is that your problem might have something to do
with be the version of Perl that you are using. I have never
used ActivePerl for buidling MSYS/MinGW apps.

I prefer to install as much from the MSYS/MinGW distribution
as possible. See for example the instructions here:

http://wiki.axiom-developer.org/BuildAxiom

under the heading "Building Axiom on Windows".

Then I built m4 and autoconf from the GNU sources without any
problems.
Post by g***@cs.tamu.edu
Post by Bill Page
Apparently you can also install autoconf-2.61 and m4-1.4.7
http://sourceforge.net/project/showfiles.php?group_id=148008
yes, i donwloaded the autoconf package from there last night;
I've not tried that version yet.
Let me know how it turns out.
Post by g***@cs.tamu.edu
...
Post by Bill Page
Is there any particular reason you want to continue using
the older version autoconf-2.60?
my three main linux boxes are running that version,
I recommend that we go to autoconf-2.61 for all Axiom builds.

Regards,
Bill Page.
g***@cs.tamu.edu
2007-04-15 21:27:55 UTC
Permalink
Post by Bill Page
Post by g***@cs.tamu.edu
...
"The system cannot find the specified file"
I've spent some time understanding this; I made some progress,
but not to the point of getting pass that failure. my
frustration with windows is only growing.
I think it best to avoid the trap that most linux developers
fall into when working with Windows. As far as I am concerned
it is just another operating system ...
Maybe -- I don't know what trap it is.
Post by Bill Page
Post by g***@cs.tamu.edu
Post by Bill Page
I built autoconf-2.61 and m4-1.4.9 directly from the gnu
distribution sources. Provided you have upgraded m4 first,
autoconf passes all tests.
I'm using m4-1.4.9 and ActivePerl-5.8.9 build 820.
$ m4 --version
m4 (GNU M4) 1.4.9
$ perl --version
This is perl, v5.6.1 built for msys
$ gcc --version
gcc.exe (GCC) 3.4.2 (mingw-special)
$ make --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-msys
Apart from ActivePerl, I have the same setting.
Post by Bill Page
----------
My first guess is that your problem might have something to do
with be the version of Perl that you are using. I have never
used ActivePerl for buidling MSYS/MinGW apps.
Maybe. But, again, the idea of using ActivePerl for msys/mingw came from
mingw website. I did not pull it out of my hat.
Post by Bill Page
I prefer to install as much from the MSYS/MinGW distribution
http://wiki.axiom-developer.org/BuildAxiom
under the heading "Building Axiom on Windows".
Then I built m4 and autoconf from the GNU sources without any
problems.
Post by g***@cs.tamu.edu
Post by Bill Page
Apparently you can also install autoconf-2.61 and m4-1.4.7
http://sourceforge.net/project/showfiles.php?group_id=148008
yes, i donwloaded the autoconf package from there last night;
I've not tried that version yet.
Let me know how it turns out.
not well -- my Perl is not /bin/perl.
Post by Bill Page
Post by g***@cs.tamu.edu
...
Post by Bill Page
Is there any particular reason you want to continue using
the older version autoconf-2.60?
my three main linux boxes are running that version,
I recommend that we go to autoconf-2.61 for all Axiom builds.
As long as you prepare and commit all my patches, I'm fine with that.
Post by Bill Page
Regards,
Bill Page.
Bill Page
2007-04-16 02:52:51 UTC
Permalink
Post by g***@cs.tamu.edu
Post by Bill Page
...
my frustration with windows is only growing.
I think it best to avoid the trap that most linux
developers fall into when working with Windows. As
far as I am concerned it is just another operating
system ...
Maybe -- I don't know what trap it is.
The "trap" to which I was referring has been called "Linux
chauvinism", see for example:

http://www.softpanorama.org/OSS/Bla_faq/raymondism.shtml

by Nikolai Bezroukov

In my own words its something like this: Assuming that because
one is having trouble in an environment with which one is less
familiar, that it is therefore inferior and a unnecessary source
of frustration - sort of opposite to the slogan: "familiarity
breeds contempt". It is a trap because believing this tends to
make it seem true.

But I did *not* intend to accuse you of this even by implication.
Sorry. It's just that I see this statement made very often in
different ways and I think it tends to perpetuate views that I
think are undesirable. However frustration, is of course quite
natural.
Post by g***@cs.tamu.edu
...
I'm using m4-1.4.9 and ActivePerl-5.8.9 build 820.
Post by Bill Page
...
$ perl --version
This is perl, v5.6.1 built for msys
I suppose you meant ActivePerl-5.8.8.820?

http://www.activestate.com/Products/ActivePerl/more_information.plex

Perl comes in two flavours from ActiveState the 5.6.x track and the
5.8.x track. Both are considered current releases. I have 5.8.8 in
my Windows installation but 5.6.1 in MSYS.
Post by g***@cs.tamu.edu
Post by Bill Page
My first guess is that your problem might have something to do
with be the version of Perl that you are using. I have never
used ActivePerl for buidling MSYS/MinGW apps.
Maybe. But, again, the idea of using ActivePerl for msys/mingw
came from mingw website. I did not pull it out of my hat.
Well, it was only my first guess. But just be sure I renamed my
MSYS /bin/perl to /bin/old_perl and restarted MSYS so that it
picks up ActivePerl-5.8.8.820 from my Windows installation. Now
I can reproduce the error that you reported:

$ perl --version

This is perl, v5.8.8 built for MSWin32-x86-multi-thread

$ cd autoconf-2.61

$ make clean

$ ./configure
...
$ make
...
autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg'
../bin/autom4te -B '..'/lib -B '..'/lib
--language M4sh --cache '' --melt ./autoconf.as -o autoconf.in
The system cannot find the path specified.
autom4te: need GNU m4 1.4 or later: /usr/local/bin/m4
make[1]: *** [autoconf.in] Error 1
make[1]: Leaving directory `/home/Administrator/autoconf-2.61/bin'
make: *** [all-recursive] Error 1
Post by g***@cs.tamu.edu
Post by Bill Page
Post by Bill Page
Apparently you can also install autoconf-2.61 and m4-1.4.7
http://sourceforge.net/project/showfiles.php?group_id=148008
yes, i donwloaded the autoconf package from there last night;
I've not tried that version yet.
Let me know how it turns out.
not well -- my Perl is not /bin/perl.
Do you mean that they assume that perl is in /bin/perl?
Post by g***@cs.tamu.edu
Post by Bill Page
...
Post by Bill Page
Is there any particular reason you want to continue using
the older version autoconf-2.60?
my three main linux boxes are running that version,
I recommend that we go to autoconf-2.61 for all Axiom builds.
As long as you prepare and commit all my patches, I'm fine with
that.
Gee, that sounds familiar. Where did I hear that before? Oh,
sorry. I forgot. This is the Axiom open source project - the
one where each developer chooses there own flavor and version
of the basic tools ... I with draw my recommendation. Let's
just all continue to do it our own way. ;)

Regards,
Bill Page.
g***@cs.tamu.edu
2007-04-16 07:31:43 UTC
Permalink
Post by Bill Page
Post by g***@cs.tamu.edu
Post by Bill Page
...
my frustration with windows is only growing.
I think it best to avoid the trap that most linux
developers fall into when working with Windows. As
far as I am concerned it is just another operating
system ...
Maybe -- I don't know what trap it is.
The "trap" to which I was referring has been called "Linux
http://www.softpanorama.org/OSS/Bla_faq/raymondism.shtml
by Nikolai Bezroukov
In my own words its something like this: Assuming that because
one is having trouble in an environment with which one is less
familiar, that it is therefore inferior and a unnecessary source
of frustration - sort of opposite to the slogan: "familiarity
breeds contempt". It is a trap because believing this tends to
make it seem true.
But I did *not* intend to accuse you of this even by implication.
Sorry. It's just that I see this statement made very often in
different ways and I think it tends to perpetuate views that I
think are undesirable. However frustration, is of course quite
natural.
I have a functional development environment under windows -- cygwin --
but I cannot use it because GCL does not work under cygwin and I
have been told on this list that windows people don't care about
GCL under cygwin. I guess the fact that windows people on this list don't
help that much to make concrete forward progress is OK. Now, I've
been trying to set up a reasonable environment for working on Axiom
with no good result so far and I'm told by non-implicative non-accusation
that I would be suffering from trap known as "linux chauvinism" when nobody
knows what I think of comparison of linux and windows. I guess that is
fair. And my problems did not go away. I guess that is forward progress.
Post by Bill Page
Post by g***@cs.tamu.edu
...
I'm using m4-1.4.9 and ActivePerl-5.8.9 build 820.
Post by Bill Page
...
$ perl --version
This is perl, v5.6.1 built for msys
I suppose you meant ActivePerl-5.8.8.820?
http://www.activestate.com/Products/ActivePerl/more_information.plex
Perl comes in two flavours from ActiveState the 5.6.x track and the
5.8.x track. Both are considered current releases. I have 5.8.8 in
my Windows installation but 5.6.1 in MSYS.
Post by g***@cs.tamu.edu
Post by Bill Page
My first guess is that your problem might have something to do
with be the version of Perl that you are using. I have never
used ActivePerl for buidling MSYS/MinGW apps.
Maybe. But, again, the idea of using ActivePerl for msys/mingw
came from mingw website. I did not pull it out of my hat.
Well, it was only my first guess. But just be sure I renamed my
MSYS /bin/perl to /bin/old_perl and restarted MSYS so that it
picks up ActivePerl-5.8.8.820 from my Windows installation. Now
$ perl --version
This is perl, v5.8.8 built for MSWin32-x86-multi-thread
$ cd autoconf-2.61
$ make clean
$ ./configure
...
$ make
...
autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg'
../bin/autom4te -B '..'/lib -B '..'/lib
--language M4sh --cache '' --melt ./autoconf.as -o autoconf.in
The system cannot find the path specified.
autom4te: need GNU m4 1.4 or later: /usr/local/bin/m4
make[1]: *** [autoconf.in] Error 1
make[1]: Leaving directory `/home/Administrator/autoconf-2.61/bin'
make: *** [all-recursive] Error 1
yes.
Post by Bill Page
Post by g***@cs.tamu.edu
Post by Bill Page
Post by Bill Page
Apparently you can also install autoconf-2.61 and m4-1.4.7
http://sourceforge.net/project/showfiles.php?group_id=148008
yes, i donwloaded the autoconf package from there last night;
I've not tried that version yet.
Let me know how it turns out.
not well -- my Perl is not /bin/perl.
Do you mean that they assume that perl is in /bin/perl?
Yes. Have a look at autom4te.
Post by Bill Page
Post by g***@cs.tamu.edu
Post by Bill Page
...
Post by Bill Page
Is there any particular reason you want to continue using
the older version autoconf-2.60?
my three main linux boxes are running that version,
I recommend that we go to autoconf-2.61 for all Axiom builds.
As long as you prepare and commit all my patches, I'm fine with
that.
Gee, that sounds familiar. Where did I hear that before? Oh,
sorry. I forgot. This is the Axiom open source project - the
one where each developer chooses there own flavor and version
of the basic tools ... I with draw my recommendation. Let's
just all continue to do it our own way. ;)
I believe you got it wrong; even with a smiley.
There are several "rules" I've developed over the years, while
maintaining linux boxes, that include:
(1) don't mess with "system" tools packaged by linux distros;
(2) duplicating tools under /usr/local, sooner or later causes
troubles.
(3) install system tools under /usr/local only when they solve
fundamental problems.

I suspect you'd have much more effective impact at explaining me
how automake-2.61 fare vis-a-vis the above three rules.
Post by Bill Page
Regards,
Bill Page.
Bill Page
2007-04-16 15:28:22 UTC
Permalink
Post by g***@cs.tamu.edu
I have a functional development environment under windows
-- cygwin -- but I cannot use it because GCL does not work under
cygwin
What do you mean that GCL does not work under cygwin? It works
for me. You just can't compile it under cygwin.
Post by g***@cs.tamu.edu
and I have been told on this list that windows people don't
care about GCL under cygwin.
I think that in general windows people don't care much for
cygwin. period. What it does is foreign to them plus it is a
poor replacement for linux, if linux is what you really want.
Post by g***@cs.tamu.edu
I guess the fact that windows people on this list don't help
that much to make concrete forward progress is OK.
I think that is typical. Most "windows people" aren't that
interested in application development. According to the Windows
user model that is somebody else's problem. Of course there are
Windows developers, even Windows open source developers but the
ratio of users to developers is much higher for Windows than
linux (perhas by as much as several orders of magnitude).
Post by g***@cs.tamu.edu
Now, I've been trying to set up a reasonable environment for
working on Axiom with no good result so far and I'm told by
non-implicative non-accusation that I would be suffering from
trap known as "linux chauvinism" when nobody knows what I
think of comparison of linux and windows.
Ok, that was gratuatous on my part, for which I do apologize.
It just turned out that I happened to be reading Nikolai's stuff
when you wrote: "my frustration with windows is only growing"
and it touched a nerve.
Post by g***@cs.tamu.edu
I guess that is fair.
not. sorry.
Post by g***@cs.tamu.edu
And my problems did not go away. I guess that is forward
progress.
not.

I could repeat almost word-for-word a similar statement by Tim
Daly concerning svn. It turns out that I can reproduce both of
your problems and I discussed how to solve both of them and
still neither of you are interested. I guess that's progress.

not.
Post by g***@cs.tamu.edu
...
Post by Bill Page
...
The system cannot find the path specified.
...
yes.
So install MSYS from pre-packaged components and the problem goes
away. Just because other people get away with using ActivePerl
with minGW doesn't make it a "supported configuration" or good
idea.
Post by g***@cs.tamu.edu
Post by Bill Page
Post by g***@cs.tamu.edu
Post by Bill Page
I recommend that we go to autoconf-2.61 for all Axiom builds.
As long as you prepare and commit all my patches, I'm fine
with that.
Gee, that sounds familiar. Where did I hear that before? Oh,
sorry. I forgot. This is the Axiom open source project - the
one where each developer chooses there own flavor and version
of the basic tools ... I with draw my recommendation. Let's
just all continue to do it our own way. ;)
I believe you got it wrong; even with a smiley.
There are several "rules" I've developed over the years, while
(1) don't mess with "system" tools packaged by linux distros;
(2) duplicating tools under /usr/local, sooner or later causes
troubles.
(3) install system tools under /usr/local only when they solve
fundamental problems.
MSYS is not a linux distro by any imagination but I think the same
principle applies. Install MSYS from "standard" components as I
indicated here:

http://wiki.axiom-developer.org/BuildAxiom

Then build autoconf-2.6x. Install it where ever you like.
Post by g***@cs.tamu.edu
I suspect you'd have much more effective impact at explaining
me how automake-2.61 fare vis-a-vis the above three rules.
The current MSYS developer package does not contain autoconf-2.6x.
If you think you need at least 2.60 what other choice do you have?
If not revert the autoconf stuff to 2.59. (Waldek is still using
2.59 in wh-sandbox.)

Regards,
Bill Page.
g***@cs.tamu.edu
2007-04-16 16:22:00 UTC
Permalink
Post by Bill Page
Post by g***@cs.tamu.edu
I have a functional development environment under windows
-- cygwin -- but I cannot use it because GCL does not work under
cygwin
What do you mean that GCL does not work under cygwin? It works
for me. You just can't compile it under cygwin.
That means the same thing for me: If I cannot compile it under cygwin,
it does not work for me as far as Axiom development is concerned.
Post by Bill Page
Post by g***@cs.tamu.edu
and I have been told on this list that windows people don't
care about GCL under cygwin.
I think that in general windows people don't care much for
cygwin. period. What it does is foreign to them plus it is a
poor replacement for linux, if linux is what you really want.
But, I do not mean linux. My impression is that you're
completely missing the picture by micro-focusing on linux vs.
non-linux environment and drawing misplaced conclusions
characterizations.

What I want is to have a reasonable development under windows
-- whether it is mingw or cygwin, I don't care much. The only
thing I care about is that the environment does not disrupt
me much from doing actual work.
Post by Bill Page
Post by g***@cs.tamu.edu
I guess the fact that windows people on this list don't help
that much to make concrete forward progress is OK.
I think that is typical.
OK; I believe the logical conclusion for me is probably that I
drop any work on Axiom on windows.

[...]
Post by Bill Page
Post by g***@cs.tamu.edu
And my problems did not go away. I guess that is forward
progress.
not.
I could repeat almost word-for-word a similar statement by Tim
Daly concerning svn. It turns out that I can reproduce both of
your problems and I discussed how to solve both of them and
still neither of you are interested. I guess that's progress.
Granted you can reproduce the problems, but the solution you suggested
did not work for me. I moved ActivePerl's path away from /bin and
/mingw/bin. Now, I tried to install autoconf-2.60 -- I explained
why I cannot require autoconf-2.61; more on this below. Except the
build goes into infinite loop, so that I never get a functional build.
Post by Bill Page
not.
Post by g***@cs.tamu.edu
...
Post by Bill Page
...
The system cannot find the path specified.
...
yes.
So install MSYS from pre-packaged components and the problem goes
away.
But I already have MSYS pre-packaged components from mingw.org!
Post by Bill Page
Just because other people get away with using ActivePerl
with minGW doesn't make it a "supported configuration" or good
idea.
Definitely, my reading of the mingw documentation from mingw
website is that ActivePerl is a "supported configuration".
But again, that point is moot by now. Even old Perl from
msys does not get me install Autoconf-2.60.
Post by Bill Page
Post by g***@cs.tamu.edu
Post by Bill Page
Post by g***@cs.tamu.edu
Post by Bill Page
I recommend that we go to autoconf-2.61 for all Axiom builds.
As long as you prepare and commit all my patches, I'm fine
with that.
Gee, that sounds familiar. Where did I hear that before? Oh,
sorry. I forgot. This is the Axiom open source project - the
one where each developer chooses there own flavor and version
of the basic tools ... I with draw my recommendation. Let's
just all continue to do it our own way. ;)
I believe you got it wrong; even with a smiley.
There are several "rules" I've developed over the years, while
(1) don't mess with "system" tools packaged by linux distros;
(2) duplicating tools under /usr/local, sooner or later causes
troubles.
(3) install system tools under /usr/local only when they solve
fundamental problems.
MSYS is not a linux distro by any imagination but I think the same
principle applies.
Which implies that I should not even try your suggestion of installing
Autoconf-2.61 from a non-officially supported third party. I don't
think your statements are coherent.
Post by Bill Page
Install MSYS from "standard" components as I
http://wiki.axiom-developer.org/BuildAxiom
I'm very familiar with that webpage; it does not solve
the issues I'm facing.
Post by Bill Page
Then build autoconf-2.6x. Install it where ever you like.
Bill -- again, building Autoconf-2.60 does not work on the "virgin"
msys/mingw fails as an infinite loop.
Post by Bill Page
Post by g***@cs.tamu.edu
I suspect you'd have much more effective impact at explaining
me how automake-2.61 fare vis-a-vis the above three rules.
The current MSYS developer package does not contain autoconf-2.6x.
If you think you need at least 2.60 what other choice do you have?
I move from Autoconf-2.5x to Autoconf-2.60 because:
(1) it does fix a bug, that turns out to be serious in later
development for Axiom (partly because of some bugs in Axiom).
(2) all my development machines have Autoconf-2.60 installed
(prepackages with the linux distribution).

As I see this, I can the reasonable choice for me is to stop any
work related to Axiom on windows; that save me valuable time, and
probably spares me from unwarranted unhelpful characterizations
and moralization. If people care about Axiom on windows, they
will find resources to get it happen. I'm done.
Post by Bill Page
If not revert the autoconf stuff to 2.59. (Waldek is still using
2.59 in wh-sandbox.)
Regards,
Bill Page.
Bill Page
2007-04-16 17:19:01 UTC
Permalink
Post by g***@cs.tamu.edu
Post by Bill Page
Post by g***@cs.tamu.edu
I have a functional development environment under windows
-- cygwin -- but I cannot use it because GCL does not work
under cygwin
What do you mean that GCL does not work under cygwin? It works
for me. You just can't compile it under cygwin.
That means the same thing for me: If I cannot compile it under
cygwin, it does not work for me as far as Axiom development is
concerned.
Why not? It is not necessary to build gcl as part of the Axiom
build - just install the windows binary for gcl, like other users
Windows do.
Post by g***@cs.tamu.edu
Post by Bill Page
Post by g***@cs.tamu.edu
and I have been told on this list that windows people don't
care about GCL under cygwin.
I think that in general windows people don't care much for
cygwin. period. What it does is foreign to them plus it is a
poor replacement for linux, if linux is what you really want.
But, I do not mean linux. My impression is that you're
completely missing the picture by micro-focusing on linux vs.
non-linux environment and drawing misplaced conclusions
characterizations.
Yes, perhaps. Sorry.
Post by g***@cs.tamu.edu
What I want is to have a reasonable development under windows
-- whether it is mingw or cygwin, I don't care much. The only
thing I care about is that the environment does not disrupt
me much from doing actual work.
MSYS/minGW works for me.
Post by g***@cs.tamu.edu
Post by Bill Page
Post by g***@cs.tamu.edu
I guess the fact that windows people on this list don't
help that much to make concrete forward progress is OK.
I think that is typical.
OK; I believe the logical conclusion for me is probably that
I drop any work on Axiom on windows.
Your choice.
Post by g***@cs.tamu.edu
Granted you can reproduce the problems, but the solution you
suggested did not work for me. I moved ActivePerl's path away
from /bin and /mingw/bin.
??? That doesn't sound right. Did you take a look at

$ echo $PATH
.:/usr/local/bin:/mingw/bin:/bin:/c/Perl/site/bin:/c/Perl/bin:
/c/watcom-1.3/binnt:/c/watcom-1.3/binw:/c/Perl/bin/:
/c/program files/imagemagick-6.2.6-q16:/c/Program Files/tla:
/c/program files/aldor/bin:/c/Program Files/Java/jdk1.5.0_04/bin:
/c/watcom-1.3/binnt:/c/watcom-.3/binw:/c/texmf/miktex/bin:
/c/WINXP/system32:/c/WINXP:/c/WINXP/System32/Wbem:
/c/Program Files/axiom/mnt/windows/bin:
/c/Program Files/Common Files/GTK/2.0/bin:
/c/Program Files/gs/gs8.51/bin:/c/Program Files/GnuWin32/bin:
/c/Program Files/QuickTime/QTSystem/:/d/smlnj/bin:
/c/Program Files/Moscow ML/bin:/c/Program Files/darcsdir-w32:
/c/Mercurial:/c/Program Files/Subversion/bin:
/c/Program Files/Aldor/bin:/c/Program Files/Aldor/bin:
.:/mingw/bin

MSYS looks in a lot of places besides /bin and /mingw/bin.
If ActivePerl is in your windows PATH, it will be accessible
to MSYS.

But if you have /bin/perl installed it will be found by MSYS
first before ActivePerl.
Post by g***@cs.tamu.edu
Now, I tried to install autoconf-2.60 -- I explained
why I cannot require autoconf-2.61; more on this below.
Ok.
Post by g***@cs.tamu.edu
Except the build goes into infinite loop, so that I never
get a functional build.
Post by Bill Page
$ perl --version
This is perl, v5.6.1 built for msys
then that seems very strange. It works for me. And if I rename
/bin/perl to something else (and thereby use ActivePerl from
windows), it fails that way you said it does for you.
Post by g***@cs.tamu.edu
...
But I already have MSYS pre-packaged components from mingw.org!
So you are running "perl, v5.6.1 built for msys" or not?
Post by g***@cs.tamu.edu
Post by Bill Page
Just because other people get away with using ActivePerl
with minGW doesn't make it a "supported configuration" or good
idea.
Definitely, my reading of the mingw documentation from mingw
website is that ActivePerl is a "supported configuration".
But again, that point is moot by now. Even old Perl from
msys does not get me install Autoconf-2.60.
...
Post by Bill Page
MSYS is not a linux distro by any imagination but I think the
same principle applies.
Which implies that I should not even try your suggestion of
installing Autoconf-2.61 from a non-officially supported third
party. I don't think your statements are coherent.
By your rules you would only do this if you had no other choice.
What choice do you have? If you want to abandon Windows development
for build-improvements, fine, it's your choice. But would still
try to encourage you to continue.
Post by g***@cs.tamu.edu
Bill -- again, building Autoconf-2.60 does not work on the
"virgin" msys/mingw fails as an infinite loop.
Very odd. I works fine for me:

--------
$ wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.60.tar.gz

$ tar xzvf autoconf-2.60.tar.gz
$ perl --version

This is perl, v5.6.1 built for msys

Copyright 1987-2001, Larry Wall

Perl may be copied only under the terms of either the Artistic License or
the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.

$ cd autoconf-2.60

$ ./configure
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether /bin/sh -n is known to work... yes
checking for expr... /bin/expr
checking for gm4... no
checking for gnum4... no
checking for m4... /bin/m4
checking whether m4 supports frozen files... yes
checking for perl... /bin/perl
checking for emacs... no
checking for xemacs... no
checking for emacs... no
checking where .elc files should go... ${datadir}/emacs/site-lisp
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for a sed that does not truncate output... /bin/sed
configure: creating ./config.status
config.status: creating config/Makefile
config.status: creating tests/Makefile
config.status: creating tests/atlocal
config.status: creating man/Makefile
config.status: creating lib/emacs/Makefile
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating lib/Makefile
config.status: creating lib/Autom4te/Makefile
config.status: creating lib/autoscan/Makefile
config.status: creating lib/m4sugar/Makefile
config.status: creating lib/autoconf/Makefile
config.status: creating lib/autotest/Makefile
config.status: creating bin/Makefile
config.status: executing tests/atconfig commands

$ make
Making all in bin
make[1]: Entering directory `/home/Administrator/autoconf-2.60/bin'
rm -f autom4te autom4te.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e 's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated from
autom4te.in; do not edit by hand.|g' `test -f ./autom4te.in || echo
./`autom4te.in >autom4te.tmp
chmod +x autom4te.tmp
chmod a-w autom4te.tmp
mv autom4te.tmp autom4te
cd ../lib && make autom4te.cfg
make[2]: Entering directory `/home/Administrator/autoconf-2.60/lib'
rm -f autom4te.cfg autom4te.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e 's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' ./autom4te.in >autom4te.tmp
chmod a-w autom4te.tmp
mv autom4te.tmp autom4te.cfg
make[2]: Leaving directory `/home/Administrator/autoconf-2.60/lib'
cd ../lib/m4sugar && make version.m4
make[2]: Entering directory `/home/Administrator/autoconf-2.60/lib/m4sugar'
{ \
echo '# This file is part of -*- Autoconf -*-.'; \
echo '# Version of Autoconf.'; \
echo '# Copyright (C) 1999, 2000, 2001, 2002'; \
echo '# Free Software Foundation, Inc.'; \
echo ;\
echo 'm4_define([m4_PACKAGE_NAME], [GNU Autoconf])'; \
echo 'm4_define([m4_PACKAGE_TARNAME], [autoconf])'; \
echo 'm4_define([m4_PACKAGE_VERSION], [2.60])'; \
echo 'm4_define([m4_PACKAGE_STRING], [GNU Autoconf 2.60])'; \
echo 'm4_define([m4_PACKAGE_BUGREPORT], [bug-***@gnu.org])'; \
} >version.m4
make[2]: Leaving directory `/home/Administrator/autoconf-2.60/lib/m4sugar'
autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg'
../bin/autom4te -B '..'/lib -B '..'/lib --language M4sh --cache ''
--melt ./autoconf.as -o autoconf.in
rm -f autoconf autoconf.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e 's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated from
autoconf.in; do not edit by hand.|g' `test -f ./auto
conf.in || echo ./`autoconf.in >autoconf.tmp
chmod +x autoconf.tmp
chmod a-w autoconf.tmp
mv autoconf.tmp autoconf
rm -f autoheader autoheader.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e 's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated from
autoheader.in; do not edit by hand.|g' `test -f ./autoheader.in || echo
./`autoheader.in >autoheader.tmp
chmod +x autoheader.tmp
chmod a-w autoheader.tmp
mv autoheader.tmp autoheader
rm -f autoreconf autoreconf.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e 's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated from
autoreconf.in; do not edit by hand.|g' `test -f ./autoreconf.in || echo
./`autoreconf.in >autoreconf.tmp
chmod +x autoreconf.tmp
chmod a-w autoreconf.tmp
mv autoreconf.tmp autoreconf
rm -f ifnames ifnames.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e 's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated from
ifnames.in; do not edit by hand.|g' `test -f ./ifnames.in || echo
./`ifnames.in >ifnames.tmp
chmod +x ifnames.tmp
chmod a-w ifnames.tmp
mv ifnames.tmp ifnames
rm -f autoscan autoscan.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e 's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated from
autoscan.in; do not edit by hand.|g' `test -f ./autoscan.in || echo
./`autoscan.in >autoscan.tmp
chmod +x autoscan.tmp
chmod a-w autoscan.tmp
mv autoscan.tmp autoscan
rm -f autoupdate autoupdate.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e 's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated from
autoupdate.in; do not edit by hand.|g' `test -f ./autoupdate.in || echo
./`autoupdate.in >autoupdate.tmp
chmod +x autoupdate.tmp
chmod a-w autoupdate.tmp
mv autoupdate.tmp autoupdate
make[1]: Leaving directory `/home/Administrator/autoconf-2.60/bin'
Making all in .
make[1]: Entering directory `/home/Administrator/autoconf-2.60'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/home/Administrator/autoconf-2.60'
Making all in lib
make[1]: Entering directory `/home/Administrator/autoconf-2.60/lib'
Making all in Autom4te
make[2]: Entering directory `/home/Administrator/autoconf-2.60/lib/Autom4te'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/Administrator/autoconf-2.60/lib/Autom4te'
Making all in m4sugar
make[2]: Entering directory `/home/Administrator/autoconf-2.60/lib/m4sugar'
autom4te_perllibdir='../..'/lib AUTOM4TE_CFG='../../lib/autom4te.cfg'
../../bin/autom4te -B '../..'/lib -B '../..'/lib
\
--language=m4sugar \
--freeze \
--output=m4sugar.m4f
autom4te_perllibdir='../..'/lib AUTOM4TE_CFG='../../lib/autom4te.cfg'
../../bin/autom4te -B '../..'/lib -B '../..'/lib
\
--language=m4sh \
--freeze \
--output=m4sh.m4f
make[2]: Leaving directory `/home/Administrator/autoconf-2.60/lib/m4sugar'
Making all in autoconf
make[2]: Entering directory `/home/Administrator/autoconf-2.60/lib/autoconf'
autom4te_perllibdir='../..'/lib AUTOM4TE_CFG='../../lib/autom4te.cfg'
../../bin/autom4te -B '../..'/lib -B '../..'/lib
\
--language=autoconf \
--freeze \
--output=autoconf.m4f
make[2]: Leaving directory `/home/Administrator/autoconf-2.60/lib/autoconf'
Making all in autotest
make[2]: Entering directory `/home/Administrator/autoconf-2.60/lib/autotest'
autom4te_perllibdir='../..'/lib AUTOM4TE_CFG='../../lib/autom4te.cfg'
../../bin/autom4te -B '../..'/lib -B '../..'/lib
\
--language=autotest \
--freeze \
--output=autotest.m4f
make[2]: Leaving directory `/home/Administrator/autoconf-2.60/lib/autotest'
Making all in autoscan
make[2]: Entering directory `/home/Administrator/autoconf-2.60/lib/autoscan'
echo '# Automatically Generated: do not edit this file' >autoscan.list
sed '/^[#]/!q' ./autoscan.pre >>autoscan.list
( \
sed -n '/^[^#]/p' ./autoscan.pre; \
autom4te_perllibdir='../..'/lib AUTOM4TE_CFG='../../lib/autom4te.cfg'
../../bin/autom4te -B '../..'/lib -B '../..'/lib --cache '' -M -l
autoconf -t'AN_OUTPUT:$1: $2 $3' \
) | LC_ALL=C sort >>autoscan.list
make[2]: Leaving directory `/home/Administrator/autoconf-2.60/lib/autoscan'
Making all in emacs
make[2]: Entering directory `/home/Administrator/autoconf-2.60/lib/emacs'
WARNING: Warnings can be ignored. :-)
if test "no" != no; then \
set x; \
list='autoconf-mode.el autotest-mode.el'; for p in $list; do \
if test -f "$p"; then d=; else d="./"; fi; \
set x "$@" "$d$p"; shift; \
done; \
shift; \
EMACS="no" /bin/sh ../../config/elisp-comp "$@" || exit 1; \
else : ; fi
make[2]: Leaving directory `/home/Administrator/autoconf-2.60/lib/emacs'
make[2]: Entering directory `/home/Administrator/autoconf-2.60/lib'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/home/Administrator/autoconf-2.60/lib'
make[1]: Leaving directory `/home/Administrator/autoconf-2.60/lib'
Making all in config
make[1]: Entering directory `/home/Administrator/autoconf-2.60/config'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/Administrator/autoconf-2.60/config'
Making all in man
make[1]: Entering directory `/home/Administrator/autoconf-2.60/man'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/Administrator/autoconf-2.60/man'
Making all in doc
make[1]: Entering directory `/home/Administrator/autoconf-2.60/doc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/Administrator/autoconf-2.60/doc'
Making all in tests
make[1]: Entering directory `/home/Administrator/autoconf-2.60/tests'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/Administrator/autoconf-2.60/tests'

---------
Post by g***@cs.tamu.edu
(1) it does fix a bug, that turns out to be serious in later
development for Axiom (partly because of some bugs in Axiom).
(2) all my development machines have Autoconf-2.60 installed
(prepackages with the linux distribution).
As I see this, I can the reasonable choice for me is to stop any
work related to Axiom on windows; that save me valuable time, and
probably spares me from unwarranted unhelpful characterizations
and moralization.
Your choice. Maybe you can wait until someone produces an MSYS
developer package with 2.60 pre-installed. Again I apologize for
my "unwarranted unhelpful characterizations and moralization".
I have no excuse except to observe that it is common human failing.
Post by g***@cs.tamu.edu
If people care about Axiom on windows, they will find resources
to get it happen.
I doubt that very much. All that is likely to happen is that they
will dismiss Axiom as uninteresting. Consider for example Martin's
recent experience with promotion of his guess package for Axiom.
My current goal is to produce a version of Axiom for windows that
has this (and other bug fixes by Waldek) pre-installed. Right now
build-improvements is the best tool to accomplish this. Porting
upstream build-improvement changes to wh-sandbox seems very
difficult, so I am currently looking at pulling what's needed from
wh-sandbox back into build-improvements. The changes in the
wh-sandbox algebra build makes this just a little tricky in the
case of the guess package. I would also like to pull the changes
for the algebra build since it avoids embedding Lisp into the
algebra files, but I think I'll tackle that second (or wait for
someone else to do it).
Post by g***@cs.tamu.edu
I'm done.
I'm sorry to hear that. :-(

Regards,
Bill Page.
g***@cs.tamu.edu
2007-04-16 23:56:38 UTC
Permalink
Post by Bill Page
Post by g***@cs.tamu.edu
=20
=20
Post by Bill Page
Post by g***@cs.tamu.edu
I have a functional development environment under windows
-- cygwin -- but I cannot use it because GCL does not work
under cygwin
What do you mean that GCL does not work under cygwin? It works
for me. You just can't compile it under cygwin.
=20
That means the same thing for me: If I cannot compile it under
cygwin, it does not work for me as far as Axiom development is
concerned.
Why not? It is not necessary to build gcl as part of the Axiom
build - just install the windows binary for gcl, like other users
Windows do.
(1) but I'm not like other windows users; I'm doing something
to Axiom that most of them -- if I understand your previous
postings correctly. I'm doing changes to Axiom, and I need
to make sure that what was previously working (build Axiom
with or without bundled GCL) is still working.

(2) you would have to assume that although I'm facing build issues, I'm
not totally dumb and there are reasons why I need to do what I'm
doing, i.e. building GCL.
Otherwise, I feel like after wasting time fighting the build
issues under windows itself, I'm wasting time at being convinced
that I really do not have time to waste on windows issues.

What I'm looking for is way to get forward, given the constraints
I enounciated. I need automake-2.60 working, I need the ability
to compile GCL, among other things. If you know of no way that would
let me do those, that is fine. But, please don't waste time arguing
why I need to compile GCL.

I need to compile GCL as long as that is the only supported Lisp
system.


[...]
Post by Bill Page
Post by g***@cs.tamu.edu
=20
What I want is to have a reasonable development under windows
-- whether it is mingw or cygwin, I don't care much. The only
thing I care about is that the environment does not disrupt
me much from doing actual work.
MSYS/minGW works for me.
yes, I believed you. The trouble is that it is not working for
me at the moment. So, the fact that it works for you is good,
but at moment it does not help me make forward progress.
Post by Bill Page
=20
Post by g***@cs.tamu.edu
Post by Bill Page
Post by g***@cs.tamu.edu
I guess the fact that windows people on this list don't
help that much to make concrete forward progress is OK.
I think that is typical.
=20
OK; I believe the logical conclusion for me is probably that
I drop any work on Axiom on windows.
Your choice.
Indeed. If I had infinite amount of time, I may continue this
"windows entertainment", but I haven't. And I don't have time for
infinite argumentation either.
Post by Bill Page
Post by g***@cs.tamu.edu
=20
Granted you can reproduce the problems, but the solution you
suggested did not work for me. I moved ActivePerl's path away
from /bin and /mingw/bin.
??? That doesn't sound right. Did you take a look at
I hoped it does not sound right. But, that is what I'm experiencing.
[...]
Post by Bill Page
MSYS looks in a lot of places besides /bin and /mingw/bin.
I know that; I may be clueless at how to solve the issue I'm
facing currently, but I'm exactly newbie in program and system
development. I need a help that is more than "basic".
Post by Bill Page
If ActivePerl is in your windows PATH, it will be accessible
to MSYS.
But, never used if its path is after /bin, where MSYS's perl resides.
Post by Bill Page
But if you have /bin/perl installed it will be found by MSYS
first before ActivePerl.
I know that. I need more than "101" stuff.

[...]
Post by Bill Page
Post by g***@cs.tamu.edu
Post by Bill Page
$ perl --version
This is perl, v5.6.1 built for msys
then that seems very strange. It works for me. And if I rename
/bin/perl to something else (and thereby use ActivePerl from
windows), it fails that way you said it does for you.
I believed you when you said it worked for you. I did believe there
was a way to get everything working -- that is why I originally said
that I was looking for a way to get a reasonable build environment
set up. If you can't trust me, you can't help me :-)
Post by Bill Page
Post by g***@cs.tamu.edu
...=20
But I already have MSYS pre-packaged components from mingw.org!
So you are running "perl, v5.6.1 built for msys" or not?
yes -- if that was not clear, yes, yes, yes, yes.

[...]
Post by Bill Page
Post by g***@cs.tamu.edu
Post by Bill Page
MSYS is not a linux distro by any imagination but I think the
same principle applies.
=20
Which implies that I should not even try your suggestion of
installing Autoconf-2.61 from a non-officially supported third
party. I don't think your statements are coherent.
By your rules you would only do this if you had no other choice.
What choice do you have?
(1) stop sinking my time in this windows+axiom black hole
(2) get a way to get a reasonable build environment.
Post by Bill Page
If you want to abandon Windows development
for build-improvements, fine, it's your choice. But would still
try to encourage you to continue.
so far, I've seen more "discouragement"; sorry to put it that way.
But, I'm sure there people on this list that can sort this out, so
my not working anymore on windows+axiom is not a big deal.
Post by Bill Page
Post by g***@cs.tamu.edu
=20
Bill -- again, building Autoconf-2.60 does not work on the
"virgin" msys/mingw fails as an infinite loop.
--------
$ wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.60.tar.gz
The "wget" that comes with msys/ming packaged does not work for me.
So I use ncftp to download tarballs. I don't believe that changes
anything though.
Post by Bill Page
$ tar xzvf autoconf-2.60.tar.gz
$ perl --version
This is perl, v5.6.1 built for msys
as I said, I already have that.
Post by Bill Page
$ ./configure
this works fine.
Post by Bill Page
$ make
this step, attempts to install things for me (which I was
surprised of), and goes into infinite loop. There is no way
to effectively stop the build, except killing the msys shell
itself.
Post by Bill Page
Post by g***@cs.tamu.edu
=20
(1) it does fix a bug, that turns out to be serious in later
development for Axiom (partly because of some bugs in Axiom).
(2) all my development machines have Autoconf-2.60 installed
(prepackages with the linux distribution).
=20
As I see this, I can the reasonable choice for me is to stop any
work related to Axiom on windows; that save me valuable time, and
probably spares me from unwarranted unhelpful characterizations
and moralization.
Your choice. Maybe you can wait until someone produces an MSYS
developer package with 2.60 pre-installed. Again I apologize for
my "unwarranted unhelpful characterizations and moralization".
I have no excuse except to observe that it is common human failing.
apologies accepted.
Post by Bill Page
Post by g***@cs.tamu.edu
If people care about Axiom on windows, they will find resources
to get it happen.
I doubt that very much. All that is likely to happen is that they
will dismiss Axiom as uninteresting.
then, I'm afraid Axiom is effectively uninteresting to them. If the
Axiom community coming from windows users cannot find developers from
that community that understands them better than I do, it is unlikely
that Axiom will ever be of use to them. Interested people usually
put their money whether their month is.
Post by Bill Page
Consider for example Martin's
recent experience with promotion of his guess package for Axiom.
I'm sorry for Martin.

What I've learnt over the years working on several projects (usually
open source) and the C++ language is that if something is of interest
to you better make sure that you invest enough effort to meet the
interest. It is unlikely that just waiting for something to happen
will effectively make that thing happen. That certainly partly
explains, apart from natural research curiosity, why I spend resources
working on Axiom.
Post by Bill Page
My current goal is to produce a version of Axiom for windows that
has this (and other bug fixes by Waldek) pre-installed. Right now
build-improvements is the best tool to accomplish this.
I was hoping to make it better, but I faced issues and I did not find
the kind of resources that would help me make progress. I do hope
someone in this community has better chance that I.

-- Gaby
Bill Page
2007-04-17 04:52:04 UTC
Permalink
Post by g***@cs.tamu.edu
...
Post by Bill Page
$ make
this step, attempts to install things for me (which I was
surprised of), and goes into infinite loop. There is no way
to effectively stop the build, except killing the msys shell
itself.
It would be very useful to me if you could include some actual
output cut-and-paste from your attempt.

Obviously this behaviour of make is very bizarre. I do not see
any attempt to install things when I run make (as the output
in my last email showed). Of course it does later if I run
'make install'. Therefore something rather fundamental must
be different between your configuration and mine.

Does your Makefile start like this?

# Makefile.in generated by automake 1.9.6 from Makefile.am.
# Makefile. Generated from Makefile.in by configure.
...

Does your output from make at least start like this (before
it goes into a loop)?

Making all in bin
make[1]: Entering directory `/home/Administrator/autoconf-2.60/bin'
rm -f autom4te autom4te.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e

...

I.e. a normal recursive make?

So far I can only think of 3 possible causes:

1) Makefile is corrupt

- What version of tar do you use?

mine:

$ tar --version
tar (GNU tar) 1.13.19

- Windows line endings (cr)

only Unix line endings are expected

2) Different version of make?

mine:

$ make --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.

3) Different shell?

mine:

$ sh --version
GNU bash, version 2.04.0(1)-release (i686-pc-msys)
Copyright 1999 Free Software Foundation, Inc.

Perhaps 2 and 3 are already ruled out since apparently both you
and I can build gcl and Axiom from build-improvements without
any problem.

Stunned.

Regards,
Bill Page.
Gabriel Dos Reis
2007-05-02 13:21:18 UTC
Permalink
"Bill Page" <***@synthesis.anikast.ca> writes:

[...]

| 2) Different version of make?

Make was definitely corrupted.
In the end I erase all install of msys/mingw, and reinstalled
everything, NOT downloading from www.mingw.org, but from
the SF download site.

Reading

http://sbcl-internals.cliki.net/Build%20on%20Windows

was definitely useful to get back on track. I was able to install
Autoconf-2.60 in /usr/local/

I can now build Axiom on windows, again.

-- Gaby

Waldek Hebisch
2007-04-18 09:59:30 UTC
Permalink
Post by Bill Page
Why not? It is not necessary to build gcl as part of the Axiom
build - just install the windows binary for gcl, like other users
Windows do.
Is there a binary version of gcl suitable for Axiom developement?
The latest binary I see is 2.6.6, but AFAIK with 2.6.6 we are
getting errors which vanish if we use 2.6.7 or 2.6.8.

Also, can one install gcl without affecting existing Mingw
installation (the gcl readme claims that on Windows gcl
need a specific, rather old Mingw version -- for me
downgrading Mingw is not an option)?
--
Waldek Hebisch
***@math.uni.wroc.pl
Bill Page
2007-04-18 16:35:40 UTC
Permalink
Post by Waldek Hebisch
Post by Bill Page
Why not? It is not necessary to build gcl as part of the Axiom
build - just install the windows binary for gcl, like other
users Windows do.
Is there a binary version of gcl suitable for Axiom developement?
The latest binary I see is 2.6.6, but AFAIK with 2.6.6 we are
getting errors which vanish if we use 2.6.7 or 2.6.8.
You are right and what I wrote above is wrong. Gaby also has
pointed out that it is not currently realistic to depend on the
GCL binaries on Windows for Axiom development.

As far as I can tell no one has posted any binaries for GCL on
windows newer than

gcl_2.6.6.mingw32_cltl1_japi_20050210.exe 22-Mar-2005

at

http://ftp.gnu.org/gnu/gcl/binaries/stable

And gcl-2.6.8pre is still a "pre-release". I guess the gcl
project is also critally lacking in resources. If it would be
helpful I could certainly upload a windows binary of this
pre-release to the Axiom Wiki web site. But I am discouraged
also by Gaby's observation that there does not seem to be much
interest in development of the Windows versions of GCL or
Axiom. :-(
Post by Waldek Hebisch
Also, can one install gcl without affecting existing Mingw
installation (the gcl readme claims that on Windows gcl
need a specific, rather old Mingw version -- for me
downgrading Mingw is not an option)?
MinGW is required in order to compile Lisp to object code and
of course to compile the Lisp output of the SPAD compiler in
Axiom. Unlike Linux, it is not correct to assume that a C
compiler is available in the basic window installation. The
existing binary installer that I prepared for Axiom on Windows
includes the necessary parts of MinGW to permit GCL and Axiom
to compile object code. I think a similar binary installer
for GCL should include these same parts of MinGW so that the
GCL installation will be complete and fully functional.

Regards,
Bill Page.
Camm Maguire
2007-04-20 16:14:43 UTC
Permalink
Greetings!
Post by Bill Page
Post by Waldek Hebisch
Post by Bill Page
Why not? It is not necessary to build gcl as part of the Axiom
build - just install the windows binary for gcl, like other
users Windows do.
Is there a binary version of gcl suitable for Axiom developement?
The latest binary I see is 2.6.6, but AFAIK with 2.6.6 we are
getting errors which vanish if we use 2.6.7 or 2.6.8.
You are right and what I wrote above is wrong. Gaby also has
pointed out that it is not currently realistic to depend on the
GCL binaries on Windows for Axiom development.
As far as I can tell no one has posted any binaries for GCL on
windows newer than
gcl_2.6.6.mingw32_cltl1_japi_20050210.exe 22-Mar-2005
at
http://ftp.gnu.org/gnu/gcl/binaries/stable
And gcl-2.6.8pre is still a "pre-release". I guess the gcl
project is also critally lacking in resources. If it would be
helpful I could certainly upload a windows binary of this
pre-release to the Axiom Wiki web site. But I am discouraged
also by Gaby's observation that there does not seem to be much
interest in development of the Windows versions of GCL or
Axiom. :-(
Thanks so much for this update. GCL development, like most open
source projects run by volunteers, usually proceeds in bursts, most
frequently during the summer months. But I think it is also true, as
we've discussed personally in the past, that the community dynamics of
Windows computer users are by in large quite different from BSD/Linux
users, in that relatively speaking there are far fewer people
interested in actually contributing work than in simply downloading
the work done by others. Mike Thomas was of course the heroic
exception in this regard, and his determination of the superiority of
the mingw environment vis a vis the cygwin environment coupled with
his more than ample contributions of time and skill have given us the
mingw system we have today. I do think we need to discuss the way
forward, for unless we find his equivalent somewhere, it can be argued
that it would be better for us to migrate to a system that can be well
emulated and/or remotely accessed under Linux using familiar tools,
even if those are deficient in other regards with respect to customary
Windows usage.
Continue reading on narkive:
Loading...