I'm still in the process of trying to merge silver/BI/WH-sandbox.
I'm currently tracking down a compiler bug that was introduced by
one of the interp changes causing the compile of EXPR.spad to fail.
t
___
Axiom-developer mailing list
Axiom-developer
The summer of code deadline has been pushed back to March 26th:
http://code.google.com/soc/
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| "Bill Page" <[EMAIL PROTECTED]> writes:
|
| [...]
|
| | > I think the the most natural solution for this problem is to
| | > require already installed external noweb.
| | >
| |
| | I agree. In fact I think it would be best to also require
| | exte
Tim --
Is there a particular reason why "spad-save" is defined in package
"user", instead of "boot"?
-- Gaby
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
Versions of the Aldor compiler up to 1.0.3 (I have not actually checked
1.1.0rc1) cannot properly deal with #line directives.
ALLPROSE is a framework to produce Aldor libraries. Instead of .as
files, the sources are noweb files (extension .as.nw). The .as files are
actually generated and fed t
Gabriel Dos Reis wrote:
> "Bill Page" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | > I can do that. But then we cannot duplicate a directory like
> | > last time or we are going to have the disk space problem again.
> | > But should /trunk be removed first?
> |
> | I think we should *first* merg
Bill Page wrote:
> wh-sandbox has implemented a radically different algebra build
> process that avoids many of the problems associated with the
> old "bootstrap" method. It has also implemented some significant
> improvements to the way the Axiom database is built. Therefore
> it is not clear to m
"Bill Page" <[EMAIL PROTECTED]> writes:
[...]
| > I think the the most natural solution for this problem is to
| > require already installed external noweb.
| >
|
| I agree. In fact I think it would be best to also require
| external gcl. We can do what is necessary to warn and advise
| the use
On March 21, 2007 1:39 PM Waldek Hebisch wrote:
> ...
> We have the same problem with few critical build files,
> notably with Makefile.in.
>
Yes, I confirm that sometimes this is problem. Sometimes
I have to 'touch' the Makefiles.
> I think the the most natural solution for this problem is to
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
[...]
| > Typically this is not a problem because if checkout is fast
| > enough file and its dependencies get the same timestamp.
| > But sometimes we may loose race and files are needlessly
| > re-made, which again typically is not a big problem. But
|
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Looking at build problem (reported in private mail) I noticed
| something which looks as serious incompatibility between svn
| and noweb. Namely, AFAICS files retrived by svn get timestamp
| corresponding to time of retrival. So, genereted files which
On 03/21/2007 06:39 PM, Waldek Hebisch wrote:
Looking at build problem (reported in private mail) I noticed
something which looks as serious incompatibility between svn
and noweb. Namely, AFAICS files retrived by svn get timestamp
corresponding to time of retrival. So, genereted files which
are
Looking at build problem (reported in private mail) I noticed
something which looks as serious incompatibility between svn
and noweb. Namely, AFAICS files retrived by svn get timestamp
corresponding to time of retrival. So, genereted files which
are up to date in repository may look out of date a
On March 21, 2007 12:40 PM Gaby wrote:
>
> "Bill Page" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | I think we should *first* merge build-improvements and
> | wh-sandbox to define a new "Silver" /trunk at SourceForge.
> | Delete the old /silver branch as SourceForge.
>
> If we all agree on tha
"Bill Page" <[EMAIL PROTECTED]> writes:
[...]
| > I can do that. But then we cannot duplicate a directory like
| > last time or we are going to have the disk space problem again.
| > But should /trunk be removed first?
|
| I think we should *first* merge build-improvements and wh-sandbox
| to d
15 matches
Mail list logo
