From casper at unbc.ca  Thu Jan  3 21:07:26 2008
From: casper at unbc.ca (David Casperson)
Date: Thu, 3 Jan 2008 18:07:26 -0800 (PST)
Subject: [Aldor-l] Mac OS X support added to svn repository
Message-ID: <Pine.OSX.4.64-MacPine.0801031755570.7457@tl-fac-1-226-53.unbc.ca>

Hi folks,

I have added what I believe to be support for Mac OS X to the
subversion repository.

For a list of what was changed run "svn log" on os_unix.c and
os_macosvm.c.  I adopted the strategy of committing the changed
files in every directory where they are committed, even though
this is clearly redundant.

I am sure you will let me know how many things I have broken.  :)


David
-- 
Dr. David Casperson, Assistant Professor     |  casper at unbc.ca
Department of Computer Science               |  (250)   960-6672 Fax 960-5544
College of Science and Management            |  3333 University Way
University of Northern British Columbia      |  Prince George, BC   V2N 4Z9
                                              |  CANADA


From timo.jyrinki at hut.fi  Fri Jan  4 17:03:26 2008
From: timo.jyrinki at hut.fi (Timo Jyrinki)
Date: Sat, 05 Jan 2008 00:03:26 +0200
Subject: [Aldor-l] Aldor is or is not free?
In-Reply-To: <fbcd16d40712201738t1f452f06q1aa04d3b7cbac59f@mail.gmail.com>
References: <Pine.SOC.4.64.0712201343240.27628@vipunen.hut.fi>
	<9qmys5tcya.fsf@aquin.mat.univie.ac.at>
	<fbcd16d40712201738t1f452f06q1aa04d3b7cbac59f@mail.gmail.com>
Message-ID: <477EAD2E.2010907@hut.fi>

Hi. I was supposed to answer one more time to this thread. Thanks to
Martin for fixing the front page with the reference to semi-free. It's
now correct so there are no problems anymore.

Regarding the possibilities of becoming free software some day:

Bill Page wrote:
> specifically the terms of the GPL. It seems that there is a rather
> deep disagreement with the choice of GPL as the best means to promote
> open software development. It seems unlikely to me that this
> philosophical disagreement can be resolved in a rational manner.

BSD license would probably be preferred in this case as Axiom is BSD
licensed. There would be also a possibility, in case I understood
correctly possible objections to GPL, to release as GPL while keeping
all the copyrights _and_ asking copyright assignments to be done so that
there is a possibility of having both the Free, GPL'd version that
cannot be made non-free (because it's GPL, not BSD), and any non-free /
closed versions as needed. This is what MySQL is succesfully making
business with, ie. in addition to services business which Free software
business is usually about, also license selling of a version that the
customer can keep closed even when making changes / distributing.

BSD would be the best option in this case, but just to remind about the
fact that there is a possibility of having both the GPL'd version and
keeping all copyrights of the official GPL'd version to itself, if it's
somehow closer to what's being wanted.

> Personally I don't understand the issue over the "royalty free" clause
> since it seems to me that this is implicit in both GPL and BSD -
> unless I grossly misunderstand the intent.

Do you mean what's wrong with Aldor Public License's royalty free
clause? Basically just the fact that it makes Aldor non-free (as defined
by the free software and open source definitions), stopping its
"consumption" in the free software eco-system - one cannot include it
into any free system, and cannot sell any combination of software that
includes Aldor. After all, a lot of the free software business is done
by selling eg. distributions / deployments of software, or doing
software development of eg. Axiom when asked to, which is commercial
business, which now must exclude Aldor from the software stack that can
be used. Free software requires the freedom of using the software in any
way fit.

GPL and BSD require that the source code must be provided to someone
receiving the program itself, if the receiver wants it, but part of the
freedoms is the requirement to be able to ask money anyway, for the
convenience of eg. ready-made builts / complex combinations of different
service, or any other service involved in it. So the code is free also
as in no money, but services may include also eg. writing more code to
the customer's needs or anything.

> Yes! :-) This is an excellent and much anticipated result of making
> the source code of Aldor  more widely available. I think we need to do
> everything possible to encourage this and make possible a
> collaborative environment where these improvements will be shared.

Yes, no matter what Aldor is now probably more easily developed than before.

BR,
Timo Jyrinki


From ralf at hemmecke.de  Thu Jan 10 06:01:41 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 10 Jan 2008 12:01:41 +0100
Subject: [Aldor-l] [open-axiom-devel] [fricas-devel] Re: About operators
 for the interpreter.
In-Reply-To: <9qd4sahvti.fsf@aquin.mat.univie.ac.at>
References: <9qzlvhybqn.fsf@aquin.mat.univie.ac.at>	<9q3at9wtam.fsf@aquin.mat.univie.ac.at>	<9qd4scsm2f.fsf_-_@aquin.mat.univie.ac.at>	<87r6gstq43.fsf_-_@nerim.fr>
	<47837E9F.5080400@hemmecke.de>	<Pine.LNX.4.64.0801080747100.20939@gauss.cs.tamu.edu>	<4783815B.9000805@hemmecke.de>	<Pine.LNX.4.64.0801080757360.20939@gauss.cs.tamu.edu>	<9qk5mkmfcs.fsf@aquin.mat.univie.ac.at>
	<478484B4.9040407@hemmecke.de>	<Pine.LNX.4.64.0801090225180.26978@gauss.cs.tamu.edu>	<47848C41.6070209@hemmecke.de>	<Pine.LNX.4.64.0801091143460.28321@gauss.cs.tamu.edu>	<87k5mig8af.fsf_-_@nerim.fr>	<Pine.LNX.4.64.0801091506450.29198@gauss.cs.tamu.edu>	<4785E456.50002@hemmecke.de>
	<9qd4sahvti.fsf@aquin.mat.univie.ac.at>
Message-ID: <4785FB15.10106@hemmecke.de>

On 01/10/2008 10:30 AM, Martin Rubey wrote:
> Ralf Hemmecke <ralf at hemmecke.de> writes:
> 
>> If I am allowed to dream then I would like to be able to write something like
>>
>>    (x: A) \oplus (y: A): A == ...
>>
>> (with \oplus being the actual (unicode) character for that operator).
>>
>> Of course that raises lots of questions and I am not 100% sure whether it
>> would be a good idea to
>>
>>    1) allow unicode in identifiers
> 
> certainly not, unless you also provide means to input them in a ordinary
> terminal.

Each Unicode character has a name.

http://unicode.org/cldr/utility/character.jsp?a=2295
http://unicode.org/cldr/utility/character.jsp?a=2A01

So one could for example still use 7bit ASCII in .spad / .as files and 
there write

(x: A) _'CIRCLED PLUS' (y: A): A == ...

and the Axiom User Interface would do the conversion. Mathematica does 
similar things. Type in

   CirclePlus[A, B] // StandardForm

However, there is still some mechanism missing to specify whether some 
identifier is prefix/infix/postfix and what its precedence is.

I don't care at the moment for such syntactic sugar.

In fact, I also fear that enabling true Unicode (not the syntactic sugar 
I mentioned above) in identifiers might make some programs harder to 
read. I guess, I would have lots of trouble understanding a program 
where the identifiers are denoted by chinese characters.

Does someone know about the JAVA experience? They allow Unicode in 
identifiers. Is the above chinese problem really a problem?

Ralf


From ralf at hemmecke.de  Fri Jan 18 17:20:00 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Fri, 18 Jan 2008 23:20:00 +0100
Subject: [Aldor-l] generated file axl_y.yt in repository
Message-ID: <47912610.60908@hemmecke.de>

aldor/src/axl_y.yt

says.

  * "zacc" output from "axl.y" on Sat Sep  1 03:30:34 2007

but is under revision control.

I suggest

svn rm https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/src/axl_y.yt

Another such generated file is axl_y.c.

svn rm https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/src/axl_y.c

Ralf




From ralf at hemmecke.de  Fri Jan 18 19:00:09 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 19 Jan 2008 01:00:09 +0100
Subject: [Aldor-l] Ignoring errors where they shouldn't
Message-ID: <47913D89.6030704@hemmecke.de>

In trunk/aldor/aldor/tools/Makefile I found

unixdir:
	-(cd unix ; $(MAKE) all)

Is there some good reason why a possible error should be ignored?


In fact, on my system I currently don't have "lex" available, so the 
build must fail, but it doesn't. It goes on producing an "aldor" 
executable and then comes to

aldor 
-R/home/hemmecke/scratch/SVNAldor-Generated/temp/installdir/linux/1.1.0/lib 
-Q3 -Qinline-all -Fao -Fo -Z db -Wcheck -M no-ALDOR_W_WillObsolete -M 
no-ALDOR_W_OverRideLibraryFile lang.as

and starts slowing down my system drastically by repeatedly starting 
aldor processes until all the memory is filled.

So there are in fact >3 bugs.

1) The "-" above should be removed.
2) Similarly in trunk/aldor/aldor/Makefile

toolsdir:  envcheck
	-(cd tools ; $(TIMER) $(MAKE) all)

3) In trunk/aldor/aldor/tools/Makefile the following target should have 
"&&" instead of ";" in order to abort early.

# zacc: Parser generator with parameterized rules. Based on Yacc.
$(ALDORTOOLS)/zacc$(EXE): zaccgram.y zaccscan.l zacc.c zacc.h zcport.h 
cenum.h cenum.c
	@ (cd $(ALDORTOOLS) && \
		echo "$(LEX) $(SRC)/zaccscan.l" && \
		      $(LEX) $(SRC)/zaccscan.l && \
		echo "yacc -d $(SRC)/zaccgram.y" && \
		      yacc -d $(SRC)/zaccgram.y && \
		echo "mv y.tab.h zaccgram.h" && \
		      mv y.tab.h zaccgram.h && \
		echo "$(CC) $(CFLAGS) -I. -I$(SRC) \
		   $(SRC)/zacc.c lex.yy.c y.tab.c $(SRC)/cenum.c -o zacc$(EXE)" && \
		      $(CC) $(CFLAGS) -I. -I$(SRC) \
		   $(SRC)/zacc.c lex.yy.c y.tab.c $(SRC)/cenum.c -o zacc$(EXE) && \
		rm lex.yy.c y.tab.c zaccgram.h \
	)

4) There are several other places where errors are ignored, but I didn't 
yet have problems with those.

Could somebody correct the sources in the repository?

Thank you

Ralf



From casper at unbc.ca  Sun Jan 20 18:49:50 2008
From: casper at unbc.ca (David Casperson)
Date: Sun, 20 Jan 2008 15:49:50 -0800 (PST)
Subject: [Aldor-l] Ignoring errors where they shouldn't
In-Reply-To: <47913D89.6030704@hemmecke.de>
References: <47913D89.6030704@hemmecke.de>
Message-ID: <Pine.OSX.4.63.0801201541320.4856@david-caspersons-computer.local>

On 2008-01-19, Ralf Hemmecke wrote:

> Date: Sat, 19 Jan 2008 01:00:09 +0100
> From: Ralf Hemmecke <ralf at hemmecke.de>
> To: aldor-l <aldor-l at aldor.org>
> Subject: [Aldor-l] Ignoring errors where they shouldn't
> 
> In trunk/aldor/aldor/tools/Makefile I found
>
> unixdir:
> 	-(cd unix ; $(MAKE) all)
>
> Is there some good reason why a possible error should be ignored?

I have asked myself the same question.  There seem to be other
places where errors are explicitly ignored with no apparent
reason for doing so.

Were there in fact good reasons for ignoring errors in spots like
this?  If so, do they still exist?  I would propose to remove
them from the Makefile's unless someone gives good reason for
caution.


> ...So there are in fact >3 bugs.
>
> 1) The "-" above should be removed.
> 2) Similarly in trunk/aldor/aldor/Makefile
>
> toolsdir:  envcheck
> 	-(cd tools ; $(TIMER) $(MAKE) all)
>
> 3) In trunk/aldor/aldor/tools/Makefile the following target should have
> "&&" instead of ";" in order to abort early.
>
> # zacc: Parser generator with parameterized rules. Based on Yacc.
> $(ALDORTOOLS)/zacc$(EXE): zaccgram.y zaccscan.l zacc.c zacc.h zcport.h
> cenum.h cenum.c
> 	@ (cd $(ALDORTOOLS) && \
> 		echo "$(LEX) $(SRC)/zaccscan.l" && \
> 		      $(LEX) $(SRC)/zaccscan.l && \
> 		echo "yacc -d $(SRC)/zaccgram.y" && \
> 		      yacc -d $(SRC)/zaccgram.y && \
> 		echo "mv y.tab.h zaccgram.h" && \
> 		      mv y.tab.h zaccgram.h && \
> 		echo "$(CC) $(CFLAGS) -I. -I$(SRC) \
> 		   $(SRC)/zacc.c lex.yy.c y.tab.c $(SRC)/cenum.c -o zacc$(EXE)" && \
> 		      $(CC) $(CFLAGS) -I. -I$(SRC) \
> 		   $(SRC)/zacc.c lex.yy.c y.tab.c $(SRC)/cenum.c -o zacc$(EXE) && \
> 		rm lex.yy.c y.tab.c zaccgram.h \
> 	)

This also seems to be common: joining multiple commands by ;
where && would seem preferable.  Is there some kind of
cross-platform compatibility issue here?  That is, are there Make
environments where we cannot rely on && being understood?

> 4) There are several other places where errors are ignored, but I didn't
> yet have problems with those.

The general philosophy of "fail early and fail hard" seems to be
missing from the Makefiles.  I am curious to know if there were
historical reasons for this, or if individual developers were
overriding failures in order to get Make to work, and then bad
checkins resulted.

David
-- 
Dr. David Casperson, Assistant Professor     |  casper at unbc.ca
Department of Computer Science               |  (250)   960-6672 Fax 960-5544
College of Science and Management            |  3333 University Way
University of Northern British Columbia      |  Prince George, BC   V2N 4Z9
                                              |  CANADA



From gdr at cs.tamu.edu  Sun Jan 20 18:58:16 2008
From: gdr at cs.tamu.edu (Gabriel Dos Reis)
Date: Sun, 20 Jan 2008 17:58:16 -0600 (CST)
Subject: [Aldor-l] Ignoring errors where they shouldn't
In-Reply-To: <Pine.OSX.4.63.0801201541320.4856@david-caspersons-computer.local>
References: <47913D89.6030704@hemmecke.de>
	<Pine.OSX.4.63.0801201541320.4856@david-caspersons-computer.local>
Message-ID: <Pine.LNX.4.64.0801201757180.3894@gauss.cs.tamu.edu>

On Sun, 20 Jan 2008, David Casperson wrote:

| > # zacc: Parser generator with parameterized rules. Based on Yacc.
| > $(ALDORTOOLS)/zacc$(EXE): zaccgram.y zaccscan.l zacc.c zacc.h zcport.h
| > cenum.h cenum.c
| > 	@ (cd $(ALDORTOOLS) && \
| > 		echo "$(LEX) $(SRC)/zaccscan.l" && \
| > 		      $(LEX) $(SRC)/zaccscan.l && \
| > 		echo "yacc -d $(SRC)/zaccgram.y" && \
| > 		      yacc -d $(SRC)/zaccgram.y && \
| > 		echo "mv y.tab.h zaccgram.h" && \
| > 		      mv y.tab.h zaccgram.h && \
| > 		echo "$(CC) $(CFLAGS) -I. -I$(SRC) \
| > 		   $(SRC)/zacc.c lex.yy.c y.tab.c $(SRC)/cenum.c -o zacc$(EXE)" && \
| > 		      $(CC) $(CFLAGS) -I. -I$(SRC) \
| > 		   $(SRC)/zacc.c lex.yy.c y.tab.c $(SRC)/cenum.c -o zacc$(EXE) && \
| > 		rm lex.yy.c y.tab.c zaccgram.h \
| > 	)
| 
| This also seems to be common: joining multiple commands by ;
| where && would seem preferable.  Is there some kind of
| cross-platform compatibility issue here?  That is, are there Make
| environments where we cannot rely on && being understood?

It is actually the shell executing the command; I don't know of any that
wouldn't work.

-- Gaby


From casper at unbc.ca  Sun Jan 20 19:04:30 2008
From: casper at unbc.ca (David Casperson)
Date: Sun, 20 Jan 2008 16:04:30 -0800 (PST)
Subject: [Aldor-l] generated file axl_y.yt in repository
In-Reply-To: <47912610.60908@hemmecke.de>
References: <47912610.60908@hemmecke.de>
Message-ID: <Pine.OSX.4.63.0801201559540.4856@david-caspersons-computer.local>

On 2008-01-18 Ralf Hemmecke wrote:

> Date: Fri, 18 Jan 2008 23:20:00 +0100
> From: Ralf Hemmecke <ralf at hemmecke.de>
> To: aldor-l <aldor-l at aldor.org>
> Subject: [Aldor-l] generated file axl_y.yt in repository
> 
> aldor/src/axl_y.yt
>
> says.
>
>  * "zacc" output from "axl.y" on Sat Sep  1 03:30:34 2007
>
> but is under revision control.
>
> I suggest
>
> svn rm https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/src/axl_y.yt
>
> Another such generated file is axl_y.c.
>
> svn rm https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/src/axl_y.c

The question of how to deal with generated content is an
interesting one.  On the one hand, we ought to want to avoid
redundancy.  On the other, providing redundant content may help
people that are lacking certain tools.

Thinking towards the future, would we want to add pre-made
packages for particular operating systems to the svn repository?

There are entire chunks of code from aldor/aldor/src that show up
elsewhere in the svn repository, even though they are clearly
copied by Makefile's.  Should we remove them too?

David
-- 
Dr. David Casperson, Assistant Professor     |  casper at unbc.ca
Department of Computer Science               |  (250)   960-6672 Fax 960-5544
College of Science and Management            |  3333 University Way
University of Northern British Columbia      |  Prince George, BC   V2N 4Z9
                                              |  CANADA



From ralf at hemmecke.de  Tue Jan 22 07:21:34 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Tue, 22 Jan 2008 13:21:34 +0100
Subject: [Aldor-l] generated file axl_y.yt in repository
In-Reply-To: <Pine.OSX.4.63.0801201559540.4856@david-caspersons-computer.local>
References: <47912610.60908@hemmecke.de>
	<Pine.OSX.4.63.0801201559540.4856@david-caspersons-computer.local>
Message-ID: <4795DFCE.8050806@hemmecke.de>

On 01/21/2008 01:04 AM, David Casperson wrote:
> On 2008-01-18 Ralf Hemmecke wrote:
> 
>> Date: Fri, 18 Jan 2008 23:20:00 +0100
>> From: Ralf Hemmecke <ralf at hemmecke.de>
>> To: aldor-l <aldor-l at aldor.org>
>> Subject: [Aldor-l] generated file axl_y.yt in repository
>>
>> aldor/src/axl_y.yt
>>
>> says.
>>
>>  * "zacc" output from "axl.y" on Sat Sep  1 03:30:34 2007
>>
>> but is under revision control.
>>
>> I suggest
>>
>> svn rm 
>> https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/src/axl_y.yt
>>
>> Another such generated file is axl_y.c.
>>
>> svn rm 
>> https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/src/axl_y.c

> The question of how to deal with generated content is an
> interesting one.  On the one hand, we ought to want to avoid
> redundancy.  On the other, providing redundant content may help
> people that are lacking certain tools.

We should distinguish a source code repository from a distribution.
I would like to remove redundancy from the SVN repository. People who 
really want to develop Aldor will know how to get their tools right. 
Otherwise there is a place called aldor-l to ask for help.

> Thinking towards the future, would we want to add pre-made
> packages for particular operating systems to the svn repository?

No. Packages should be build via "make dist" or "make distcheck" and 
simply put on the website or some other kind of archive. In such a 
distribution some generated files (like axl_y.c etc.) can be contained.
The goal must be that a person just unpacks the .tgz file and types

./configure && make && make install

Editing something by hand should be avoided.

> There are entire chunks of code from aldor/aldor/src that show up
> elsewhere in the svn repository, even though they are clearly
> copied by Makefile's.  Should we remove them too?

I am in favour of removing them. The problem is that I am not the 
authority to decide. In fact, I would be happy if it were clearer how 
further development of Aldor should happen. Currently, only the sources 
are in the open, but no develepment happens.

I've made the suggestion "svn rm ..." above. That would not hurt 
building Aldor. But no reaction at all from the maintainers of the 
repository, not even saying that this deletion is not wanted for this or 
that reason.

Any suggestions how to speed up improvements/bugfixes to the Aldor compiler?

Ralf


From bill.page at newsynthesis.org  Wed Jan 23 23:01:57 2008
From: bill.page at newsynthesis.org (Bill Page)
Date: Wed, 23 Jan 2008 23:01:57 -0500
Subject: [Aldor-l] generated file axl_y.yt in repository
In-Reply-To: <4795DFCE.8050806@hemmecke.de>
References: <47912610.60908@hemmecke.de>
	<Pine.OSX.4.63.0801201559540.4856@david-caspersons-computer.local>
	<4795DFCE.8050806@hemmecke.de>
Message-ID: <fbcd16d40801232001s42e92082t8facefa3cfbfa94@mail.gmail.com>

On 1/22/08, Ralf Hemmecke wrote:
> On 01/21/2008 01:04 AM, David Casperson wrote:
> ...
> > There are entire chunks of code from aldor/aldor/src that show
> > up elsewhere in the svn repository, even though they are
> > clearly copied by Makefile's.  Should we remove them too?
>
> I am in favour of removing them.

+1 I agree.

> The problem is that I am not the authority to decide. In fact, I
> would be happy if it were clearer how further development of
> Aldor should happen. Currently, only the sources are in the
> open, but no develepment happens.
>

Yes, it is a problem. The Aldor project is not "live" because it
really has not project leader.

> I've made the suggestion "svn rm ..." above. That would not
> hurt building Aldor. But no reaction at all from the maintainers
> of the repository, not even saying that this deletion is not
> wanted for this or that reason.
>
> Any suggestions how to speed up improvements/bugfixes to
> the Aldor compiler?
>

We have previously discussed the possibility of setting up a parallel
development project on another public site. This would be a *branch*
not a fork. In fact if we had the co-operation of aldor.org this
branch could actually be a branch on the aldor.org site. The intention
would be to produce a new experimental distribution of Aldor that
would (eventually) be merged back to trunk.

Perhaps it is time to do something like this?

Regards,
Bill Page.


From ralf at hemmecke.de  Sun Jan 27 15:30:13 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 27 Jan 2008 21:30:13 +0100
Subject: [Aldor-l] redundant files in the source tree
Message-ID: <479CE9D5.20004@hemmecke.de>

in trunk/aldor/contrib/gmp/Makefile

one finds

#
# Rules to get the common source files (as links or copies)
#
axlport.h:	$(SRC)/axlport.h ;	 ( $(RM) $@ ; $(LN) $? $@ )
platform.h:	$(SRC)/platform.h ;	 ( $(RM) $@ ; $(LN) $? $@ )
...
output.c: 	$(SRC)/output.c ; 	 ( $(RM) $@ ; $(LN) $? $@ )
store.c: 	$(SRC)/store.c ; 	 ( $(RM) $@ ; $(LN) $? $@ )

So all of these files are generated from the original sources, if they 
are not available. Yet many (all?) are in the SVN tree.

Edit the Makefile to contain

svnclean:
	svn rm $(FOAMH) $(FOAMC)

then call

make svnclean
svn revert Makefile
svn commit

That should solve the redundancy problem.

Could somebody with write access commit that?

Thanks
Ralf



From ralf at hemmecke.de  Sun Jan 27 15:08:17 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 27 Jan 2008 21:08:17 +0100
Subject: [Aldor-l] $(SHELL) tools/unix/maclean $(MACHINE)
Message-ID: <479CE4B1.9020009@hemmecke.de>

Any ideas why in trunk/aldor/Makefile there appears something like

clean::
	$(SHELL) tools/unix/maclean $(MACHINE)

and maclean explicitly sets ALDORROOT?

ALDORROOT="../../base/${MACHINE}"

I am in favour of removing tools/unix/maclean.

Any comments?

Ralf



From bill.page at newsynthesis.org  Tue Jan 29 20:48:29 2008
From: bill.page at newsynthesis.org (Bill Page)
Date: Tue, 29 Jan 2008 20:48:29 -0500
Subject: [Aldor-l] [Axiom-developer] aldor/axiom interoperability
In-Reply-To: <73691350801170132r3e6d7058lf76874fdc8c557c7@mail.gmail.com>
References: <73691350801170132r3e6d7058lf76874fdc8c557c7@mail.gmail.com>
Message-ID: <fbcd16d40801291748w367a74d9p3149ecef2bc5c7d3@mail.gmail.com>

Peter,

Thank you very much for sending the revised version of src_aldor3.tgz!
I think eliminating the Java dependency is a very important thing if
we are to eventually include this as an optional part of the
Axiom/FriCAS/OpenAxiom build.  I am trying to use your revised build
system with OpenAxiom but I have some questions:

Could you explain the following lines in the makefile:

  echo ")co RNS.spad"  >> $@.lsp

I was not able to find 'RNS.spad' in the Axiom sources or in your
tarball. Perhaps you forgot to include it?

I notice also that there is still some mention of java in the makefile, e.g.

all_dirs += $(ALDOR_INT)/java_axiom

$(ALDOR_INT)/java_axiom/spadset.mk: $(ALDOR_INT)/java_axiom/.dir
$(ALDOR_INT)/java_axiom/spadset.mk: $(domain_dep_files) $(aldor_dep_files)
$(ALDOR_INT)/java_axiom/spadset.mk: $(ALDOR_INT)/java/Sort.class
$(ALDOR_INT)/java_axiom/spadset.mk: $(ALDOR_INT)/deps/axextend.dep
$(ALDOR_INT)/java_axiom/spadset.mk: $(ALDOR_INT)/libaxiom.lst
$(ALDOR_SRC)/extra_deps.lst
        (cd $(ALDOR_INT); java -cp `pwd`/java Sort makefile     \
                                        deps/axextend.dep       \
                                        libaxiom.lst            \
                                        $(ALDOR_SRC)/extra_deps.lst)

java_axiom: $(ALDOR_INT)/java_axiom/spadset.mk
.PHONY: java_axiom

...

#
# :: Java
#
all_dirs += $(ALDOR_INT)/java
$(ALDOR_INT)/java/Sort.class: $(ALDOR_INT)/java/.dir
$(ALDOR_INT)/java/Sort.class: $(ALDOR_SRC)/Sort.java
        javac -source 1.5 -d $(ALDOR_INT)/java Sort.java


---------

Am I misunderstanding or are these only a left-over stanza's from the
previous version which is not used any more?

Regards,
Bill Page.

On 1/17/08, Peter Broadbery wrote:
> Finally got round to looking at this.
> The code attached can be used to build the axiom/aldor interopability
> library (libaxiom.al).
>
> New features:
> Less abuse of make features (though I've only used a recent version of
> make, and have used some newer features)
> Dependency on java removed.
> Cleaner build process - all the dependency analysis is done in the
> aldor code.  It should be more data driven, but it isn't.
>
> There's a small aldor patch that I'll send along this evening.
>
> Peter
>
> _______________________________________________
> Axiom-developer mailing list
> Axiom-developer at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
>
>
>


From ralf at hemmecke.de  Tue Jan 29 17:34:23 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Tue, 29 Jan 2008 23:34:23 +0100
Subject: [Aldor-l] Version of libalgebra
Message-ID: <479FA9EF.5040809@hemmecke.de>

Is it a typo that in LibAldor

lib/aldor/src/util/sal_version.as

there appears

	major:Z			== 1;
	minor:Z			== 2;
	patch:Z			== 0;

and at the same time

	VER == "Aldor Library Version 1.1.0 - April 19, 2005";

???

Ralf



From ralf at hemmecke.de  Wed Jan 30 07:27:53 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Wed, 30 Jan 2008 13:27:53 +0100
Subject: [Aldor-l] gcd
Message-ID: <47A06D49.5010206@hemmecke.de>

Dear Marc,

I guess, you or one of your students should know more about this code from

svn cat 
https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/lib/algebra/src/multpoly/multpolycat/alg_defgcd.as 


See end of mail. Could you say a few words about the intend of this 
content function with 2 parameters? Why wouldn't "content(b)" instead of 
"content(b,vc)" be enough?

Anyway this content function is computing

   gcd(cpv,content(cu,vcu))$%;

at the end of the for loop and *never* using that computation. Besides 
from leading to segfaults that code also wastes computation time.

Maybe you know a quick fix of that buggy piece of code.

Thank you
Ralf


         content(p: P, v: V): P == {
		local u := univ(p,v);
                 -- content(u)$D;
		local cpv: P := 0;
		for cu in coefficients(u) repeat {
		    ground? cu => cpv := gcd(cpv,cu)$%;
		    vcu := mainVariable(cu);
		    vcu < v => cpv := gcd(cpv,cu)$%;
		    gcd(cpv,content(cu,vcu))$%;
		}
		return cpv;
         }
         gcd(a: P, b: P): P == {
	    a = 0 => b;
	    b = 0 => a;
	    ground? a or ground? b => {
		gm:P:=gcd(content(a)$P, content(b)$P)::P;
		unitCanonical gm;}
             (a:=unitCanonical(a)) =(b:=unitCanonical(b)) => a;
             va :V:= mainVariable(a);
             vb :V:= mainVariable(b);
             va < vb => {
	    	-- MB 11/2004: THIS CODE IS BUGGY, WILL BOMB IF b is UNIVARIATE
		--             SINCE THERE IS NO "NEXT VARIABLE"
                 vc  := nextVariable(b,va);
                 gm :P:= gcd(a,content(b,vc))$%;
                 unitCanonical gm;}
             va > vb => {
	    	-- MB 11/2004: THIS CODE IS BUGGY, WILL BOMB IF a is UNIVARIATE
		--             SINCE THERE IS NO "NEXT VARIABLE"
                 vc  := nextVariable(a,vb);
                 gm :P:= gcd(b,content(a,vc))$%;
                 unitCanonical gm; }
             assert(va = vb);
             g :D:= gcd(univ(a,va),univ(b,vb))$D;
             tmp:=multivariate(D)(g,va);
             unitCanonical tmp;}


From casper at unbc.ca  Thu Jan  3 21:07:26 2008
From: casper at unbc.ca (David Casperson)
Date: Thu, 3 Jan 2008 18:07:26 -0800 (PST)
Subject: [Aldor-l] Mac OS X support added to svn repository
Message-ID: <Pine.OSX.4.64-MacPine.0801031755570.7457@tl-fac-1-226-53.unbc.ca>

Hi folks,

I have added what I believe to be support for Mac OS X to the
subversion repository.

For a list of what was changed run "svn log" on os_unix.c and
os_macosvm.c.  I adopted the strategy of committing the changed
files in every directory where they are committed, even though
this is clearly redundant.

I am sure you will let me know how many things I have broken.  :)


David
-- 
Dr. David Casperson, Assistant Professor     |  casper at unbc.ca
Department of Computer Science               |  (250)   960-6672 Fax 960-5544
College of Science and Management            |  3333 University Way
University of Northern British Columbia      |  Prince George, BC   V2N 4Z9
                                              |  CANADA



From timo.jyrinki at hut.fi  Fri Jan  4 17:03:26 2008
From: timo.jyrinki at hut.fi (Timo Jyrinki)
Date: Sat, 05 Jan 2008 00:03:26 +0200
Subject: [Aldor-l] Aldor is or is not free?
In-Reply-To: <fbcd16d40712201738t1f452f06q1aa04d3b7cbac59f@mail.gmail.com>
References: <Pine.SOC.4.64.0712201343240.27628@vipunen.hut.fi>
	<9qmys5tcya.fsf@aquin.mat.univie.ac.at>
	<fbcd16d40712201738t1f452f06q1aa04d3b7cbac59f@mail.gmail.com>
Message-ID: <477EAD2E.2010907@hut.fi>

Hi. I was supposed to answer one more time to this thread. Thanks to
Martin for fixing the front page with the reference to semi-free. It's
now correct so there are no problems anymore.

Regarding the possibilities of becoming free software some day:

Bill Page wrote:
> specifically the terms of the GPL. It seems that there is a rather
> deep disagreement with the choice of GPL as the best means to promote
> open software development. It seems unlikely to me that this
> philosophical disagreement can be resolved in a rational manner.

BSD license would probably be preferred in this case as Axiom is BSD
licensed. There would be also a possibility, in case I understood
correctly possible objections to GPL, to release as GPL while keeping
all the copyrights _and_ asking copyright assignments to be done so that
there is a possibility of having both the Free, GPL'd version that
cannot be made non-free (because it's GPL, not BSD), and any non-free /
closed versions as needed. This is what MySQL is succesfully making
business with, ie. in addition to services business which Free software
business is usually about, also license selling of a version that the
customer can keep closed even when making changes / distributing.

BSD would be the best option in this case, but just to remind about the
fact that there is a possibility of having both the GPL'd version and
keeping all copyrights of the official GPL'd version to itself, if it's
somehow closer to what's being wanted.

> Personally I don't understand the issue over the "royalty free" clause
> since it seems to me that this is implicit in both GPL and BSD -
> unless I grossly misunderstand the intent.

Do you mean what's wrong with Aldor Public License's royalty free
clause? Basically just the fact that it makes Aldor non-free (as defined
by the free software and open source definitions), stopping its
"consumption" in the free software eco-system - one cannot include it
into any free system, and cannot sell any combination of software that
includes Aldor. After all, a lot of the free software business is done
by selling eg. distributions / deployments of software, or doing
software development of eg. Axiom when asked to, which is commercial
business, which now must exclude Aldor from the software stack that can
be used. Free software requires the freedom of using the software in any
way fit.

GPL and BSD require that the source code must be provided to someone
receiving the program itself, if the receiver wants it, but part of the
freedoms is the requirement to be able to ask money anyway, for the
convenience of eg. ready-made builts / complex combinations of different
service, or any other service involved in it. So the code is free also
as in no money, but services may include also eg. writing more code to
the customer's needs or anything.

> Yes! :-) This is an excellent and much anticipated result of making
> the source code of Aldor  more widely available. I think we need to do
> everything possible to encourage this and make possible a
> collaborative environment where these improvements will be shared.

Yes, no matter what Aldor is now probably more easily developed than before.

BR,
Timo Jyrinki



From ralf at hemmecke.de  Thu Jan 10 06:01:41 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 10 Jan 2008 12:01:41 +0100
Subject: [Aldor-l] [open-axiom-devel] [fricas-devel] Re: About operators
 for the interpreter.
In-Reply-To: <9qd4sahvti.fsf@aquin.mat.univie.ac.at>
References: <9qzlvhybqn.fsf@aquin.mat.univie.ac.at>	<9q3at9wtam.fsf@aquin.mat.univie.ac.at>	<9qd4scsm2f.fsf_-_@aquin.mat.univie.ac.at>	<87r6gstq43.fsf_-_@nerim.fr>
	<47837E9F.5080400@hemmecke.de>	<Pine.LNX.4.64.0801080747100.20939@gauss.cs.tamu.edu>	<4783815B.9000805@hemmecke.de>	<Pine.LNX.4.64.0801080757360.20939@gauss.cs.tamu.edu>	<9qk5mkmfcs.fsf@aquin.mat.univie.ac.at>
	<478484B4.9040407@hemmecke.de>	<Pine.LNX.4.64.0801090225180.26978@gauss.cs.tamu.edu>	<47848C41.6070209@hemmecke.de>	<Pine.LNX.4.64.0801091143460.28321@gauss.cs.tamu.edu>	<87k5mig8af.fsf_-_@nerim.fr>	<Pine.LNX.4.64.0801091506450.29198@gauss.cs.tamu.edu>	<4785E456.50002@hemmecke.de>
	<9qd4sahvti.fsf@aquin.mat.univie.ac.at>
Message-ID: <4785FB15.10106@hemmecke.de>

On 01/10/2008 10:30 AM, Martin Rubey wrote:
> Ralf Hemmecke <ralf at hemmecke.de> writes:
> 
>> If I am allowed to dream then I would like to be able to write something like
>>
>>    (x: A) \oplus (y: A): A == ...
>>
>> (with \oplus being the actual (unicode) character for that operator).
>>
>> Of course that raises lots of questions and I am not 100% sure whether it
>> would be a good idea to
>>
>>    1) allow unicode in identifiers
> 
> certainly not, unless you also provide means to input them in a ordinary
> terminal.

Each Unicode character has a name.

http://unicode.org/cldr/utility/character.jsp?a=2295
http://unicode.org/cldr/utility/character.jsp?a=2A01

So one could for example still use 7bit ASCII in .spad / .as files and 
there write

(x: A) _'CIRCLED PLUS' (y: A): A == ...

and the Axiom User Interface would do the conversion. Mathematica does 
similar things. Type in

   CirclePlus[A, B] // StandardForm

However, there is still some mechanism missing to specify whether some 
identifier is prefix/infix/postfix and what its precedence is.

I don't care at the moment for such syntactic sugar.

In fact, I also fear that enabling true Unicode (not the syntactic sugar 
I mentioned above) in identifiers might make some programs harder to 
read. I guess, I would have lots of trouble understanding a program 
where the identifiers are denoted by chinese characters.

Does someone know about the JAVA experience? They allow Unicode in 
identifiers. Is the above chinese problem really a problem?

Ralf



From ralf at hemmecke.de  Fri Jan 18 17:20:00 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Fri, 18 Jan 2008 23:20:00 +0100
Subject: [Aldor-l] generated file axl_y.yt in repository
Message-ID: <47912610.60908@hemmecke.de>

aldor/src/axl_y.yt

says.

  * "zacc" output from "axl.y" on Sat Sep  1 03:30:34 2007

but is under revision control.

I suggest

svn rm https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/src/axl_y.yt

Another such generated file is axl_y.c.

svn rm https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/src/axl_y.c

Ralf





From ralf at hemmecke.de  Fri Jan 18 19:00:09 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 19 Jan 2008 01:00:09 +0100
Subject: [Aldor-l] Ignoring errors where they shouldn't
Message-ID: <47913D89.6030704@hemmecke.de>

In trunk/aldor/aldor/tools/Makefile I found

unixdir:
	-(cd unix ; $(MAKE) all)

Is there some good reason why a possible error should be ignored?


In fact, on my system I currently don't have "lex" available, so the 
build must fail, but it doesn't. It goes on producing an "aldor" 
executable and then comes to

aldor 
-R/home/hemmecke/scratch/SVNAldor-Generated/temp/installdir/linux/1.1.0/lib 
-Q3 -Qinline-all -Fao -Fo -Z db -Wcheck -M no-ALDOR_W_WillObsolete -M 
no-ALDOR_W_OverRideLibraryFile lang.as

and starts slowing down my system drastically by repeatedly starting 
aldor processes until all the memory is filled.

So there are in fact >3 bugs.

1) The "-" above should be removed.
2) Similarly in trunk/aldor/aldor/Makefile

toolsdir:  envcheck
	-(cd tools ; $(TIMER) $(MAKE) all)

3) In trunk/aldor/aldor/tools/Makefile the following target should have 
"&&" instead of ";" in order to abort early.

# zacc: Parser generator with parameterized rules. Based on Yacc.
$(ALDORTOOLS)/zacc$(EXE): zaccgram.y zaccscan.l zacc.c zacc.h zcport.h 
cenum.h cenum.c
	@ (cd $(ALDORTOOLS) && \
		echo "$(LEX) $(SRC)/zaccscan.l" && \
		      $(LEX) $(SRC)/zaccscan.l && \
		echo "yacc -d $(SRC)/zaccgram.y" && \
		      yacc -d $(SRC)/zaccgram.y && \
		echo "mv y.tab.h zaccgram.h" && \
		      mv y.tab.h zaccgram.h && \
		echo "$(CC) $(CFLAGS) -I. -I$(SRC) \
		   $(SRC)/zacc.c lex.yy.c y.tab.c $(SRC)/cenum.c -o zacc$(EXE)" && \
		      $(CC) $(CFLAGS) -I. -I$(SRC) \
		   $(SRC)/zacc.c lex.yy.c y.tab.c $(SRC)/cenum.c -o zacc$(EXE) && \
		rm lex.yy.c y.tab.c zaccgram.h \
	)

4) There are several other places where errors are ignored, but I didn't 
yet have problems with those.

Could somebody correct the sources in the repository?

Thank you

Ralf




From casper at unbc.ca  Sun Jan 20 18:49:50 2008
From: casper at unbc.ca (David Casperson)
Date: Sun, 20 Jan 2008 15:49:50 -0800 (PST)
Subject: [Aldor-l] Ignoring errors where they shouldn't
In-Reply-To: <47913D89.6030704@hemmecke.de>
References: <47913D89.6030704@hemmecke.de>
Message-ID: <Pine.OSX.4.63.0801201541320.4856@david-caspersons-computer.local>

On 2008-01-19, Ralf Hemmecke wrote:

> Date: Sat, 19 Jan 2008 01:00:09 +0100
> From: Ralf Hemmecke <ralf at hemmecke.de>
> To: aldor-l <aldor-l at aldor.org>
> Subject: [Aldor-l] Ignoring errors where they shouldn't
> 
> In trunk/aldor/aldor/tools/Makefile I found
>
> unixdir:
> 	-(cd unix ; $(MAKE) all)
>
> Is there some good reason why a possible error should be ignored?

I have asked myself the same question.  There seem to be other
places where errors are explicitly ignored with no apparent
reason for doing so.

Were there in fact good reasons for ignoring errors in spots like
this?  If so, do they still exist?  I would propose to remove
them from the Makefile's unless someone gives good reason for
caution.


> ...So there are in fact >3 bugs.
>
> 1) The "-" above should be removed.
> 2) Similarly in trunk/aldor/aldor/Makefile
>
> toolsdir:  envcheck
> 	-(cd tools ; $(TIMER) $(MAKE) all)
>
> 3) In trunk/aldor/aldor/tools/Makefile the following target should have
> "&&" instead of ";" in order to abort early.
>
> # zacc: Parser generator with parameterized rules. Based on Yacc.
> $(ALDORTOOLS)/zacc$(EXE): zaccgram.y zaccscan.l zacc.c zacc.h zcport.h
> cenum.h cenum.c
> 	@ (cd $(ALDORTOOLS) && \
> 		echo "$(LEX) $(SRC)/zaccscan.l" && \
> 		      $(LEX) $(SRC)/zaccscan.l && \
> 		echo "yacc -d $(SRC)/zaccgram.y" && \
> 		      yacc -d $(SRC)/zaccgram.y && \
> 		echo "mv y.tab.h zaccgram.h" && \
> 		      mv y.tab.h zaccgram.h && \
> 		echo "$(CC) $(CFLAGS) -I. -I$(SRC) \
> 		   $(SRC)/zacc.c lex.yy.c y.tab.c $(SRC)/cenum.c -o zacc$(EXE)" && \
> 		      $(CC) $(CFLAGS) -I. -I$(SRC) \
> 		   $(SRC)/zacc.c lex.yy.c y.tab.c $(SRC)/cenum.c -o zacc$(EXE) && \
> 		rm lex.yy.c y.tab.c zaccgram.h \
> 	)

This also seems to be common: joining multiple commands by ;
where && would seem preferable.  Is there some kind of
cross-platform compatibility issue here?  That is, are there Make
environments where we cannot rely on && being understood?

> 4) There are several other places where errors are ignored, but I didn't
> yet have problems with those.

The general philosophy of "fail early and fail hard" seems to be
missing from the Makefiles.  I am curious to know if there were
historical reasons for this, or if individual developers were
overriding failures in order to get Make to work, and then bad
checkins resulted.

David
-- 
Dr. David Casperson, Assistant Professor     |  casper at unbc.ca
Department of Computer Science               |  (250)   960-6672 Fax 960-5544
College of Science and Management            |  3333 University Way
University of Northern British Columbia      |  Prince George, BC   V2N 4Z9
                                              |  CANADA




From gdr at cs.tamu.edu  Sun Jan 20 18:58:16 2008
From: gdr at cs.tamu.edu (Gabriel Dos Reis)
Date: Sun, 20 Jan 2008 17:58:16 -0600 (CST)
Subject: [Aldor-l] Ignoring errors where they shouldn't
In-Reply-To: <Pine.OSX.4.63.0801201541320.4856@david-caspersons-computer.local>
References: <47913D89.6030704@hemmecke.de>
	<Pine.OSX.4.63.0801201541320.4856@david-caspersons-computer.local>
Message-ID: <Pine.LNX.4.64.0801201757180.3894@gauss.cs.tamu.edu>

On Sun, 20 Jan 2008, David Casperson wrote:

| > # zacc: Parser generator with parameterized rules. Based on Yacc.
| > $(ALDORTOOLS)/zacc$(EXE): zaccgram.y zaccscan.l zacc.c zacc.h zcport.h
| > cenum.h cenum.c
| > 	@ (cd $(ALDORTOOLS) && \
| > 		echo "$(LEX) $(SRC)/zaccscan.l" && \
| > 		      $(LEX) $(SRC)/zaccscan.l && \
| > 		echo "yacc -d $(SRC)/zaccgram.y" && \
| > 		      yacc -d $(SRC)/zaccgram.y && \
| > 		echo "mv y.tab.h zaccgram.h" && \
| > 		      mv y.tab.h zaccgram.h && \
| > 		echo "$(CC) $(CFLAGS) -I. -I$(SRC) \
| > 		   $(SRC)/zacc.c lex.yy.c y.tab.c $(SRC)/cenum.c -o zacc$(EXE)" && \
| > 		      $(CC) $(CFLAGS) -I. -I$(SRC) \
| > 		   $(SRC)/zacc.c lex.yy.c y.tab.c $(SRC)/cenum.c -o zacc$(EXE) && \
| > 		rm lex.yy.c y.tab.c zaccgram.h \
| > 	)
| 
| This also seems to be common: joining multiple commands by ;
| where && would seem preferable.  Is there some kind of
| cross-platform compatibility issue here?  That is, are there Make
| environments where we cannot rely on && being understood?

It is actually the shell executing the command; I don't know of any that
wouldn't work.

-- Gaby



From casper at unbc.ca  Sun Jan 20 19:04:30 2008
From: casper at unbc.ca (David Casperson)
Date: Sun, 20 Jan 2008 16:04:30 -0800 (PST)
Subject: [Aldor-l] generated file axl_y.yt in repository
In-Reply-To: <47912610.60908@hemmecke.de>
References: <47912610.60908@hemmecke.de>
Message-ID: <Pine.OSX.4.63.0801201559540.4856@david-caspersons-computer.local>

On 2008-01-18 Ralf Hemmecke wrote:

> Date: Fri, 18 Jan 2008 23:20:00 +0100
> From: Ralf Hemmecke <ralf at hemmecke.de>
> To: aldor-l <aldor-l at aldor.org>
> Subject: [Aldor-l] generated file axl_y.yt in repository
> 
> aldor/src/axl_y.yt
>
> says.
>
>  * "zacc" output from "axl.y" on Sat Sep  1 03:30:34 2007
>
> but is under revision control.
>
> I suggest
>
> svn rm https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/src/axl_y.yt
>
> Another such generated file is axl_y.c.
>
> svn rm https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/src/axl_y.c

The question of how to deal with generated content is an
interesting one.  On the one hand, we ought to want to avoid
redundancy.  On the other, providing redundant content may help
people that are lacking certain tools.

Thinking towards the future, would we want to add pre-made
packages for particular operating systems to the svn repository?

There are entire chunks of code from aldor/aldor/src that show up
elsewhere in the svn repository, even though they are clearly
copied by Makefile's.  Should we remove them too?

David
-- 
Dr. David Casperson, Assistant Professor     |  casper at unbc.ca
Department of Computer Science               |  (250)   960-6672 Fax 960-5544
College of Science and Management            |  3333 University Way
University of Northern British Columbia      |  Prince George, BC   V2N 4Z9
                                              |  CANADA




From ralf at hemmecke.de  Tue Jan 22 07:21:34 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Tue, 22 Jan 2008 13:21:34 +0100
Subject: [Aldor-l] generated file axl_y.yt in repository
In-Reply-To: <Pine.OSX.4.63.0801201559540.4856@david-caspersons-computer.local>
References: <47912610.60908@hemmecke.de>
	<Pine.OSX.4.63.0801201559540.4856@david-caspersons-computer.local>
Message-ID: <4795DFCE.8050806@hemmecke.de>

On 01/21/2008 01:04 AM, David Casperson wrote:
> On 2008-01-18 Ralf Hemmecke wrote:
> 
>> Date: Fri, 18 Jan 2008 23:20:00 +0100
>> From: Ralf Hemmecke <ralf at hemmecke.de>
>> To: aldor-l <aldor-l at aldor.org>
>> Subject: [Aldor-l] generated file axl_y.yt in repository
>>
>> aldor/src/axl_y.yt
>>
>> says.
>>
>>  * "zacc" output from "axl.y" on Sat Sep  1 03:30:34 2007
>>
>> but is under revision control.
>>
>> I suggest
>>
>> svn rm 
>> https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/src/axl_y.yt
>>
>> Another such generated file is axl_y.c.
>>
>> svn rm 
>> https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/src/axl_y.c

> The question of how to deal with generated content is an
> interesting one.  On the one hand, we ought to want to avoid
> redundancy.  On the other, providing redundant content may help
> people that are lacking certain tools.

We should distinguish a source code repository from a distribution.
I would like to remove redundancy from the SVN repository. People who 
really want to develop Aldor will know how to get their tools right. 
Otherwise there is a place called aldor-l to ask for help.

> Thinking towards the future, would we want to add pre-made
> packages for particular operating systems to the svn repository?

No. Packages should be build via "make dist" or "make distcheck" and 
simply put on the website or some other kind of archive. In such a 
distribution some generated files (like axl_y.c etc.) can be contained.
The goal must be that a person just unpacks the .tgz file and types

./configure && make && make install

Editing something by hand should be avoided.

> There are entire chunks of code from aldor/aldor/src that show up
> elsewhere in the svn repository, even though they are clearly
> copied by Makefile's.  Should we remove them too?

I am in favour of removing them. The problem is that I am not the 
authority to decide. In fact, I would be happy if it were clearer how 
further development of Aldor should happen. Currently, only the sources 
are in the open, but no develepment happens.

I've made the suggestion "svn rm ..." above. That would not hurt 
building Aldor. But no reaction at all from the maintainers of the 
repository, not even saying that this deletion is not wanted for this or 
that reason.

Any suggestions how to speed up improvements/bugfixes to the Aldor compiler?

Ralf



From bill.page at newsynthesis.org  Wed Jan 23 23:01:57 2008
From: bill.page at newsynthesis.org (Bill Page)
Date: Wed, 23 Jan 2008 23:01:57 -0500
Subject: [Aldor-l] generated file axl_y.yt in repository
In-Reply-To: <4795DFCE.8050806@hemmecke.de>
References: <47912610.60908@hemmecke.de>
	<Pine.OSX.4.63.0801201559540.4856@david-caspersons-computer.local>
	<4795DFCE.8050806@hemmecke.de>
Message-ID: <fbcd16d40801232001s42e92082t8facefa3cfbfa94@mail.gmail.com>

On 1/22/08, Ralf Hemmecke wrote:
> On 01/21/2008 01:04 AM, David Casperson wrote:
> ...
> > There are entire chunks of code from aldor/aldor/src that show
> > up elsewhere in the svn repository, even though they are
> > clearly copied by Makefile's.  Should we remove them too?
>
> I am in favour of removing them.

+1 I agree.

> The problem is that I am not the authority to decide. In fact, I
> would be happy if it were clearer how further development of
> Aldor should happen. Currently, only the sources are in the
> open, but no develepment happens.
>

Yes, it is a problem. The Aldor project is not "live" because it
really has not project leader.

> I've made the suggestion "svn rm ..." above. That would not
> hurt building Aldor. But no reaction at all from the maintainers
> of the repository, not even saying that this deletion is not
> wanted for this or that reason.
>
> Any suggestions how to speed up improvements/bugfixes to
> the Aldor compiler?
>

We have previously discussed the possibility of setting up a parallel
development project on another public site. This would be a *branch*
not a fork. In fact if we had the co-operation of aldor.org this
branch could actually be a branch on the aldor.org site. The intention
would be to produce a new experimental distribution of Aldor that
would (eventually) be merged back to trunk.

Perhaps it is time to do something like this?

Regards,
Bill Page.



From ralf at hemmecke.de  Sun Jan 27 15:30:13 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 27 Jan 2008 21:30:13 +0100
Subject: [Aldor-l] redundant files in the source tree
Message-ID: <479CE9D5.20004@hemmecke.de>

in trunk/aldor/contrib/gmp/Makefile

one finds

#
# Rules to get the common source files (as links or copies)
#
axlport.h:	$(SRC)/axlport.h ;	 ( $(RM) $@ ; $(LN) $? $@ )
platform.h:	$(SRC)/platform.h ;	 ( $(RM) $@ ; $(LN) $? $@ )
...
output.c: 	$(SRC)/output.c ; 	 ( $(RM) $@ ; $(LN) $? $@ )
store.c: 	$(SRC)/store.c ; 	 ( $(RM) $@ ; $(LN) $? $@ )

So all of these files are generated from the original sources, if they 
are not available. Yet many (all?) are in the SVN tree.

Edit the Makefile to contain

svnclean:
	svn rm $(FOAMH) $(FOAMC)

then call

make svnclean
svn revert Makefile
svn commit

That should solve the redundancy problem.

Could somebody with write access commit that?

Thanks
Ralf




From ralf at hemmecke.de  Sun Jan 27 15:08:17 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 27 Jan 2008 21:08:17 +0100
Subject: [Aldor-l] $(SHELL) tools/unix/maclean $(MACHINE)
Message-ID: <479CE4B1.9020009@hemmecke.de>

Any ideas why in trunk/aldor/Makefile there appears something like

clean::
	$(SHELL) tools/unix/maclean $(MACHINE)

and maclean explicitly sets ALDORROOT?

ALDORROOT="../../base/${MACHINE}"

I am in favour of removing tools/unix/maclean.

Any comments?

Ralf




From bill.page at newsynthesis.org  Tue Jan 29 20:48:29 2008
From: bill.page at newsynthesis.org (Bill Page)
Date: Tue, 29 Jan 2008 20:48:29 -0500
Subject: [Aldor-l] [Axiom-developer] aldor/axiom interoperability
In-Reply-To: <73691350801170132r3e6d7058lf76874fdc8c557c7@mail.gmail.com>
References: <73691350801170132r3e6d7058lf76874fdc8c557c7@mail.gmail.com>
Message-ID: <fbcd16d40801291748w367a74d9p3149ecef2bc5c7d3@mail.gmail.com>

Peter,

Thank you very much for sending the revised version of src_aldor3.tgz!
I think eliminating the Java dependency is a very important thing if
we are to eventually include this as an optional part of the
Axiom/FriCAS/OpenAxiom build.  I am trying to use your revised build
system with OpenAxiom but I have some questions:

Could you explain the following lines in the makefile:

  echo ")co RNS.spad"  >> $@.lsp

I was not able to find 'RNS.spad' in the Axiom sources or in your
tarball. Perhaps you forgot to include it?

I notice also that there is still some mention of java in the makefile, e.g.

all_dirs += $(ALDOR_INT)/java_axiom

$(ALDOR_INT)/java_axiom/spadset.mk: $(ALDOR_INT)/java_axiom/.dir
$(ALDOR_INT)/java_axiom/spadset.mk: $(domain_dep_files) $(aldor_dep_files)
$(ALDOR_INT)/java_axiom/spadset.mk: $(ALDOR_INT)/java/Sort.class
$(ALDOR_INT)/java_axiom/spadset.mk: $(ALDOR_INT)/deps/axextend.dep
$(ALDOR_INT)/java_axiom/spadset.mk: $(ALDOR_INT)/libaxiom.lst
$(ALDOR_SRC)/extra_deps.lst
        (cd $(ALDOR_INT); java -cp `pwd`/java Sort makefile     \
                                        deps/axextend.dep       \
                                        libaxiom.lst            \
                                        $(ALDOR_SRC)/extra_deps.lst)

java_axiom: $(ALDOR_INT)/java_axiom/spadset.mk
.PHONY: java_axiom

...

#
# :: Java
#
all_dirs += $(ALDOR_INT)/java
$(ALDOR_INT)/java/Sort.class: $(ALDOR_INT)/java/.dir
$(ALDOR_INT)/java/Sort.class: $(ALDOR_SRC)/Sort.java
        javac -source 1.5 -d $(ALDOR_INT)/java Sort.java


---------

Am I misunderstanding or are these only a left-over stanza's from the
previous version which is not used any more?

Regards,
Bill Page.

On 1/17/08, Peter Broadbery wrote:
> Finally got round to looking at this.
> The code attached can be used to build the axiom/aldor interopability
> library (libaxiom.al).
>
> New features:
> Less abuse of make features (though I've only used a recent version of
> make, and have used some newer features)
> Dependency on java removed.
> Cleaner build process - all the dependency analysis is done in the
> aldor code.  It should be more data driven, but it isn't.
>
> There's a small aldor patch that I'll send along this evening.
>
> Peter
>
> _______________________________________________
> Axiom-developer mailing list
> Axiom-developer at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
>
>
>



From ralf at hemmecke.de  Tue Jan 29 17:34:23 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Tue, 29 Jan 2008 23:34:23 +0100
Subject: [Aldor-l] Version of libalgebra
Message-ID: <479FA9EF.5040809@hemmecke.de>

Is it a typo that in LibAldor

lib/aldor/src/util/sal_version.as

there appears

	major:Z			== 1;
	minor:Z			== 2;
	patch:Z			== 0;

and at the same time

	VER == "Aldor Library Version 1.1.0 - April 19, 2005";

???

Ralf




From ralf at hemmecke.de  Wed Jan 30 07:27:53 2008
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Wed, 30 Jan 2008 13:27:53 +0100
Subject: [Aldor-l] gcd
Message-ID: <47A06D49.5010206@hemmecke.de>

Dear Marc,

I guess, you or one of your students should know more about this code from

svn cat 
https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/lib/algebra/src/multpoly/multpolycat/alg_defgcd.as 


See end of mail. Could you say a few words about the intend of this 
content function with 2 parameters? Why wouldn't "content(b)" instead of 
"content(b,vc)" be enough?

Anyway this content function is computing

   gcd(cpv,content(cu,vcu))$%;

at the end of the for loop and *never* using that computation. Besides 
from leading to segfaults that code also wastes computation time.

Maybe you know a quick fix of that buggy piece of code.

Thank you
Ralf


         content(p: P, v: V): P == {
		local u := univ(p,v);
                 -- content(u)$D;
		local cpv: P := 0;
		for cu in coefficients(u) repeat {
		    ground? cu => cpv := gcd(cpv,cu)$%;
		    vcu := mainVariable(cu);
		    vcu < v => cpv := gcd(cpv,cu)$%;
		    gcd(cpv,content(cu,vcu))$%;
		}
		return cpv;
         }
         gcd(a: P, b: P): P == {
	    a = 0 => b;
	    b = 0 => a;
	    ground? a or ground? b => {
		gm:P:=gcd(content(a)$P, content(b)$P)::P;
		unitCanonical gm;}
             (a:=unitCanonical(a)) =(b:=unitCanonical(b)) => a;
             va :V:= mainVariable(a);
             vb :V:= mainVariable(b);
             va < vb => {
	    	-- MB 11/2004: THIS CODE IS BUGGY, WILL BOMB IF b is UNIVARIATE
		--             SINCE THERE IS NO "NEXT VARIABLE"
                 vc  := nextVariable(b,va);
                 gm :P:= gcd(a,content(b,vc))$%;
                 unitCanonical gm;}
             va > vb => {
	    	-- MB 11/2004: THIS CODE IS BUGGY, WILL BOMB IF a is UNIVARIATE
		--             SINCE THERE IS NO "NEXT VARIABLE"
                 vc  := nextVariable(a,vb);
                 gm :P:= gcd(b,content(a,vc))$%;
                 unitCanonical gm; }
             assert(va = vb);
             g :D:= gcd(univ(a,va),univ(b,vb))$D;
             tmp:=multivariate(D)(g,va);
             unitCanonical tmp;}



