Compiler development

[pip88nl]

Hello Aldor developers,

tonight, I have restarted my work on the compiler (I had no time for it
anymore and now I have forgot most of the things I knew back then). I
would like to verify the quality of the compiler by splitting it up into
subsystems and perform extensive regression tests on each. By splitting
them up, I also want to understand and possibly document the internal
working of these subsystems.

The problem I am currently having is that the memory allocation subsystem
crashes in various ways. The most annoying crash happens when I try to
make it output debug information using the STO_DEBUG_DISPLAY macro and
the GC_DETAIL environment variable. It causes a segmentation fault in
vfprintf where something tries to access memory at address 0xc0. This is
clearly caused by undefined behaviour elsewhere.

Is anybody actually still developing Aldor or does anybody have a clue
about the compiler internals? I'll have uploaded the code I have here to
svn://svn.xinutec.org/aldor/trunk. It does not include the changes I made
before tonight. It does not include the make scripts either, since they
are not license-compatible with the APLv2. (Would it be possible to use
SVN external repositories and just let svn fetch the required files
without those being license-compatible?)

Regarding license issues, I no longer care about it. If the Aldor
Software Organisation wants the "royalty-free" "unrestricted" right to
modify and redistribute my changes, that would only be good, since it
would mean there are actually people out there besides me who care about
the quality of the compiler.

--
Pippijn van Steenhoven


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Ralf Hemmecke]

Hi Pippijn,

I'm happy that you are back. You are probably the most active aldor
developer. I'd like to do something, but unfortunately I really really
have no knowledge in compiler development.

> tonight, I have restarted my work on the compiler (I had no time for
> it anymore and now I have forgot most of the things I knew back
> then). I would like to verify the quality of the compiler by
> splitting it up into subsystems and perform extensive regression
> tests on each. By splitting them up, I also want to understand and
> possibly document the internal working of these subsystems.

That would be really really great.

> Is anybody actually still developing Aldor

I wanted to improve the make system, but since you are now working on
this... I'll probably postpone this.

> or does anybody have a clue about the compiler internals?

There are probably several people around. But I guess, Peter Broadbery
and Stephen Watt are the ones with the most knowledge. Peter recently
answered some specific questions of mine about the aldor fricas
connection (see
http://groups.google.com/groups/profile?enc_user=s4Aq-BoAAAD4O05ngkOc1duH131iwdPIQpAYQ-1NAqDM0H5TLnE-zQ
). But usually he is too busy to answer.

> I'll have uploaded the code I have here to
> svn://svn.xinutec.org/aldor/trunk.

Pippijn, would it be possible for you to use a new branch at
https://svn.origo.ethz.ch/algebraist?

See also
http://algebraist.origo.ethz.ch/wiki/parallel_development
for more information. Bill Page has setup that parallel development site
and there is no problem in giving you write access to it. Just register.

> It does not include the changes I made before tonight. It does not
> include the make scripts either, since they are not
> license-compatible with the APLv2. (Would it be possible to use SVN
> external repositories and just let svn fetch the required files
> without those being license-compatible?)

I don't see a problem with that. In fact, I guess you could open up
another directory on Algebraist that explicitly states your license
conditions for your code and gets the appropriate sources at build time.
All that license stuff is a bit annoying, but if external svn
repositories contribute to the development of the compiler, I am all for
it. All I want to have is a compiler with fewer bugs. If that could be
done with a build system under GPL or so that downloads the current
aldor trunk at build time, I don't care. Of course, then there can be no
binary distribution of the compiler since that would violate both the
GPL and APL2.

BTW, are you aware of
http://www.risc.uni-linz.ac.at/about/conferences/summer2008/
and in particular of
http://axiom-wiki.newsynthesis.org/WorkShopRISC2008/ ?

Would be nice if you could make it to the workshop and let people know
about your work.

Ralf

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[pip88nl]

Hi,

I have a few additional questions regarding the aldor compiler and a few
things to correct from earlier posts.

First of all: the reason valgrind warns 14 million times even if I
allocate only 1 byte of memory is the garbage collector scanning the full
memory image including the read-only data segment and the stack for
pointers. This is how garbage collectors work, so it's fine, it just does
a good job at rendering valgrind completely useless, which is not so
nice. I am not sure how other garbage collectors get around this (or
whether they do at all).

I'm not sure who did, but someone said that the aldor GC is quite fast.
It is.. quite, but I don't see why every allocation using stoAlloc must
take 30 times longer than an allocation using system malloc. I will be
looking into the allocation later, after some bugs have been fixed.

I came across the following comment:

 * Most C compilers ought to be able to Do The Right Thing with the
 * definitions below, as the corresponding C++ compiler is obliged to
 * support std::less<Pointer>() & co,  which is obliged to be a consistent
 * total order on the Pointer type regardless of where the pointers
 *  are found.

this comment is about the relational operator applications in the
ptr[GL][ET] functions. The first assumption is right: every C compiler on
a flat memory model system will do the right thing. Nearly every platform
supported by aldor uses such a memory model, so it is fair to assume that
it works as you would expect. The rationale for this, however, is wrong.
The std::less<> template does nothing but return x < y according to
ISO/IEC 14882:2003 20.3.3p5. All it does is wrap it. Also, according to
ISO/IEC 9899:1999 (the C99 standard) section 6.5.6p9, relational
operators applied to pointers whose pointees are not members of the same
array result in unspecified behaviour. The same applies to C++ where it
is specified in 5.9p2 (the last point: Other pointer comparisons are
unspecified.)

The exception to this is the 8086 which is also said to be supported by
aldor. The 8086 architecture implements a segmented memory model where
memory pages may overlap. The assumption breaks on such systems. I have
several suboptimal solutions to the problem. One of them would be ignore
it.

Another issue is the "portable bytecode format". Right now I am too tired
to really look into it, but it seems to assume that a byte always
consists of 8 bits:

 # define BYTE_BITS              8       /* Not sizeof(...)!  See above. */

I find this comment rather misleading, since it is not possible to find
the number of bits in a byte using the sizeof operator anyway.. "see
above" points at the "these are hardcoded numbers because we need to be
portable" statement.

As far as I can see, aldor currently supports:
 - Intel 8086
 - Intel 80386
 - Motorola 68000 series
 - AIM PowerPC
 - Intel IA64
 - IBM System 370
 - AIX RT
 - AIX RS/6000
 - Sun Sparc
 - Sun Sparc64
 - Alpha AXP
 - IRIX MIPS
 - Cray
 - VAX
 - HPPA-RISC

I assume each of them currently works, but if I start rewriting things, I
might break some of them. We need people who test aldor on their
platform. Who uses what?
 
--
Pippijn van Steenhoven


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[David Casperson]

Hi Pippijn,

I have been looking at the compiler from the point of view of
making it ``open'', by which I mean accessible from some kind of
Aldor library.

I am primarily interested in accessing the parser and earlier
stages for the purposes of being able to insert hooks to support
an IDE.

I've looked at store.x a fair bit when porting to a Mac, but
haven't looked since then.

What kind of component systems are you thinking about using?

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

Hello Aldor developers,



tonight, I have restarted my work on the compiler (I had no time for it

anymore and now I have forgot most of the things I knew back then). I

would like to verify the quality of the compiler by splitting it up into

subsystems and perform extensive regression tests on each. By splitting

them up, I also want to understand and possibly document the internal

working of these subsystems.



The problem I am currently having is that the memory allocation subsystem

crashes in various ways. The most annoying crash happens when I try to

make it output debug information using the STO_DEBUG_DISPLAY macro and

the GC_DETAIL environment variable. It causes a segmentation fault in

vfprintf where something tries to access memory at address 0xc0. This is

clearly caused by undefined behaviour elsewhere.



Is anybody actually still developing Aldor or does anybody have a clue

about the compiler internals? I'll have uploaded the code I have here to

svn://svn.xinutec.org/aldor/trunk. It does not include the changes I made

before tonight. It does not include the make scripts either, since they

are not license-compatible with the APLv2. (Would it be possible to use

SVN external repositories and just let svn fetch the required files

without those being license-compatible?)



Regarding license issues, I no longer care about it. If the Aldor

Software Organisation wants the "royalty-free" "unrestricted" right to

modify and redistribute my changes, that would only be good, since it

would mean there are actually people out there besides me who care about

the quality of the compiler.



--

Pippijn van Steenhoven



_______________________________________________

Aldor-l mailing list

Aldor-l@...

http://aldor.org/mailman/listinfo/aldor-l_aldor.org


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[David Casperson]

Pippijn, you wrote

> Hi,
>
> I have a few additional questions regarding the aldor compiler and a few
> things to correct from earlier posts.
>
> First of all: the reason valgrind warns 14 million times even if I
> allocate only 1 byte of memory is the garbage collector scanning the full
> memory image including the read-only data segment and the stack for
> pointers. This is how garbage collectors work, so it's fine, it just does
> a good job at rendering valgrind completely useless, which is not so
> nice. I am not sure how other garbage collectors get around this (or
> whether they do at all).

Pardon my ignorance, I don't know what valgrind does.  I
shouldn't speak for Stephen Watt but I suspect that the reason
that the garbage collector does this large-scale search is an
assumption that ALDOR memory is shared with some other system,
for instance, Aldor running inside of Maple.


> I'm not sure who did, but someone said that the aldor GC is quite fast.
> It is.. quite, but I don't see why every allocation using stoAlloc must
> take 30 times longer than an allocation using system malloc. I will be
> looking into the allocation later, after some bugs have been fixed.
>
> I came across the following comment:
>
  * Most C compilers ought to be able to Do The Right Thing with the
  * definitions below, as the corresponding C++ compiler is obliged to
  * support std::less<Pointer>() & co,  which is obliged to be a consistent
  * total order on the Pointer type regardless of where the pointers
  *  are found.
>
> this comment is about the relational operator applications in the
> ptr[GL][ET] functions. The first assumption is right: every C compiler on
> a flat memory model system will do the right thing. Nearly every platform
> supported by aldor uses such a memory model, so it is fair to assume that
> it works as you would expect. The rationale for this, however,
> is wrong.

I wrote the comment above.  The main point here is that before I
changed these definitions, the compiler was using signed
comparisons of pointers (cast to some integral type), and that
was causing the Mac OS X port to break.

I am aware that in C/C++ we are in Nasal Daemon territory when we
attempt to manipulate two pointers that don't point into the same
underlying array (or one past the end in C++), but it is hard to
see how to find a portable C fix to this that works across
platforms.  Presumably, if we run into problems on segmented
architectures we may have add some external routines to the
CC_noncanonical_pointer section.

> The std::less<> template does nothing but return x < y according to
> ISO/IEC 14882:2003 20.3.3p5. All it does is wrap it.

I am surprised to hear this.  I had seen comments to the effect
that instances of

     std::less<X*> ...

were required to supply a meaningful order for all legal X*
pointers, and in particular for pointers from different arrays.
I'm afraid that I can't cite a standard here, but the writer was
knowledgeable, and commenting specifically about implementations
of C++ on possibly non-flat architectures.

> Also, according to
> ISO/IEC 9899:1999 (the C99 standard) section 6.5.6p9, relational
> operators applied to pointers whose pointees are not members of the same
> array result in unspecified behaviour. The same applies to C++ where it
> is specified in 5.9p2 (the last point: Other pointer comparisons are
> unspecified.)

Aside the from the exception granted to ensure that "end"
iterators for plain arrays are valid, this is correct.  The
comment whose provenance I cannot remember explicitly asserted
that this did not hold for std::less and company.  This still
doesn't get us a solution that works in C, but it does seem to
indicate that for most architectures this is likely to work.


> The exception to this is the 8086 which is also said to be supported by
> aldor. The 8086 architecture implements a segmented memory model where
> memory pages may overlap. The assumption breaks on such systems. I have
> several suboptimal solutions to the problem. One of them would be ignore
> it.

That's my take too.  A slightly better solution might be to put
the ptrXX macros inside the conditional part of
CC_noncanonical_pointer in cport.h, and put comments in cconfig.h
explaining what is required when working with segmented
architectures.


> ...
> --
> Pippijn van Steenhoven

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


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Bill Page-7]

On 2008/6/15 Pippijn van Steenhoven wrote::
>
> tonight, I have restarted my work on the compiler ...

Excellent!

> ...
> Is anybody actually still developing Aldor or does anybody have a
> clue about the compiler internals? I'll have uploaded the code I have
> here to
> svn://svn.xinutec.org/aldor/trunk

This links seems dead.

> It does not include the changes I made before tonight. It does not
> include the make scripts either, since they are not license-compatible
> with the APLv2. (Would it be possible to use SVN external
> repositories and just let svn fetch the required files without those
> being license-compatible?)
>

I think the answer is "yes". Provided that you are not re-distributing
a modified version of Aldor under a different license, I do not think
that there is any problem to make aldor-related source code separately
available under what ever license you choose. (If I am wrong about
this, I hope someone more knowledgeable about the actual intention of
APLv2 will correct me.) Of course at some point this is likely to get
rather inconvenient if there are many changes and dependencies on
specific versions of the Aldor distribution.

> Regarding license issues, I no longer care about it. If the Aldor
> Software Organisation wants the "royalty-free" "unrestricted" right
> to modify and redistribute my changes, that would only be good,
> since it would mean there are actually people out there besides me
> who care about the quality of the compiler.
>

Certainly there are a significant number of people who care about the
quality of the Aldor compiler, so yes do I think that is a reasonable
take on the issue - it allows work to continue. Of course there is
still reason to wish that the Aldor Software Organization and any
remaining interests at NAG and IBM would simply agree to the
re-licensing of Aldor under GPL. I do believe that such a change would
make Aldor more attractive to a much wider group of potential
developers and users. GPL (or something compatible with GPL) meets the
needs of almost all other open source compiler development projects.
Like it or not, choosing anything else seems only to invite confusion
and raise red flags with both users and developers.

Regards,
Bill Page.

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[pip88nl]

On Sun, Jun 15, 2008 at 11:07:40PM -0400, Bill Page wrote:
> > svn://svn.xinutec.org/aldor/trunk
>
> This links seems dead.

It's not, but it is not a HTTP URL.
  svn co svn://svn.xinutec.org/aldor/trunk
should work (and works for me). Note that I am currently just importing
the aldor sources and trying to find a good way of doing so.

> I think the answer is "yes". Provided that you are not re-distributing
> a modified version of Aldor under a different license, I do not think
> that there is any problem to make aldor-related source code separately
> available under what ever license you choose. (If I am wrong about

I am not going to re-distribute anything, I am just providing sources. In
fact, the source tree is not a "work", is it? I mean, if I mix GPL
sources with APL2 sources in the same source tree, that does not mean the
entire source tree has to be GPL, does it? My repository does not form a
"work", it should be seen as loosely coupled collection of sources. Is
that possible?

Regards,

--
Pippijn van Steenhoven


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Ralf Hemmecke]

On 06/16/2008 04:37 PM, Pippijn van Steenhoven wrote:
> On Sun, Jun 15, 2008 at 11:07:40PM -0400, Bill Page wrote:
>>> svn://svn.xinutec.org/aldor/trunk
>> This links seems dead.
>
> It's not, but it is not a HTTP URL.
>   svn co svn://svn.xinutec.org/aldor/trunk
> should work (and works for me). Note that I am currently just importing
> the aldor sources and trying to find a good way of doing so.

Does *not* work for me. Well, isn't there a way in SVN to use 'external
sources' so that your repository would never contain the Aldor source
tree, but only a reference to it? So the question of distribution would
be settled.

>> I think the answer is "yes". Provided that you are not re-distributing
>> a modified version of Aldor under a different license, I do not think
>> that there is any problem to make aldor-related source code separately
>> available under what ever license you choose. (If I am wrong about

> I am not going to re-distribute anything, I am just providing sources. In
> fact, the source tree is not a "work", is it? I mean, if I mix GPL
> sources with APL2 sources in the same source tree, that does not mean the
> entire source tree has to be GPL, does it? My repository does not form a
> "work", it should be seen as loosely coupled collection of sources. Is
> that possible?

What about a mail to the FSF? Make the problem clear and hope they
suggest something reasonable. They should know best about the GPL.

Ralf

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Bill Page-7]

>> On Sun, Jun 15, 2008 at 11:07:40PM -0400, Bill Page wrote:
>>>> svn://svn.xinutec.org/aldor/trunk
>>> This links seems dead.
>>
> On 06/16/2008 04:37 PM, Pippijn van Steenhoven wrote:
>> It's not, but it is not a HTTP URL.
>>   svn co svn://svn.xinutec.org/aldor/trunk
>> should work (and works for me). Note that I am currently just
>> importing the aldor sources and trying to find a good way of
> doing so.
>

On Mon, Jun 16, 2008 at 10:58 AM, Ralf Hemmecke wrote:
> Does *not* work for me.

Ok, this now worked for me:

-bash-3.00$ svn co svn://svn.xinutec.org/aldor/trunk aldor-Pippijn
A    aldor-Pippijn/include
A    aldor-Pippijn/include/path.h
A    aldor-Pippijn/include/of_inlin.h
...
A    aldor-Pippijn/include/cport.h
A    aldor-Pippijn/src
A    aldor-Pippijn/src/frontend
A    aldor-Pippijn/src/frontend/winmain.c
A    aldor-Pippijn/src/frontend/main.c
A    aldor-Pippijn/src/frontend/Makefile
A    aldor-Pippijn/src/zacc
A    aldor-Pippijn/src/zacc/zaccscan.l
...
A    aldor-Pippijn/src/zacc/zaccgram.y
A    aldor-Pippijn/src/library
A    aldor-Pippijn/src/library/runtime
A    aldor-Pippijn/src/library/runtime/src
A    aldor-Pippijn/src/library/runtime/src/runtime.as
A    aldor-Pippijn/src/library/runtime/Makefile
A    aldor-Pippijn/src/library/foamlib
A    aldor-Pippijn/src/library/foamlib/include
A    aldor-Pippijn/src/library/foamlib/include/foamlib.as
A    aldor-Pippijn/src/library/foamlib/src
A    aldor-Pippijn/src/library/foamlib/src/opsys.as
...
A    aldor-Pippijn/src/library/foamlib/src/list.as
A    aldor-Pippijn/src/library/foamlib/Makefile
A    aldor-Pippijn/src/library/Makefile
A    aldor-Pippijn/src/compiler
A    aldor-Pippijn/src/Makefile
A    aldor-Pippijn/obj
A    aldor-Pippijn/obj/include
A    aldor-Pippijn/obj/lib
A    aldor-Pippijn/obj/bin
A    aldor-Pippijn/Makefile
A    aldor-Pippijn/setenv.sh
Checked out revision 17.

------

Thank you!

> Well, isn't there a way in SVN to use 'external sources' so that your
> repository would never contain the Aldor source tree, but only a
> reference to it? So the question of distribution would be settled.
>

Ralf, did you find a way to do this? Do you know if this approach is
used in any open source projects?

Regards,
Bill Page.

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Ralf Hemmecke]

>> Well, isn't there a way in SVN to use 'external sources' so that your
>> repository would never contain the Aldor source tree, but only a
>> reference to it? So the question of distribution would be settled.

> Ralf, did you find a way to do this? Do you know if this approach is
> used in any open source projects?

http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html

I haven't used that myself, but Christian has in his AldorUnit project.
He references his own LibModel project.

You can investigate starting from
http://www.risc.uni-linz.ac.at/software/aldor/project.php?id=AldorUnit

Just try

svn proplist -v svn://svn.risc.uni-linz.ac.at/caistlei/aldorunit

Ralf

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Gabriel Dos Reis-2]

Ralf Hemmecke <ralf@...> writes:

| >> Well, isn't there a way in SVN to use 'external sources' so that your
| >> repository would never contain the Aldor source tree, but only a
| >> reference to it? So the question of distribution would be settled.
|
| > Ralf, did you find a way to do this? Do you know if this approach is
| > used in any open source projects?
|
| http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html
|
| I haven't used that myself, but Christian has in his AldorUnit project.
| He references his own LibModel project.

I use it for personal repos.  It works well, as long as you don't
push too much the envelop.  I wish SVK had better support for it.

-- Gaby

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[daly-4]

It is possible to do a git-pull and specify multiple sources
to pull and merge. git can also fetch from SVN repositories.
So, in theory, I suppose you could construct a command line
that pulls all the parts together and does a merge.

Tim

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Bill Page-7]

Ralf Hemmecke writes:

>
> | >> Well, isn't there a way in SVN to use 'external sources' so that
> | >> your repository would never contain the Aldor source tree, but
> | >> only a reference to it? So the question of distribution would be
> | >> settled.
> |
> | Bill Page asked:
> | > Ralf, did you find a way to do this? Do you know if this approach
> | > is used in any open source projects?
> |
> | http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html
> |
> | I haven't used that myself, but Christian has in his AldorUnit project.
> | He references his own LibModel project.
>

On Tue, Jun 17, 2008 at 1:04 PM, Gabriel Dos Reis wrote:
> I use it for personal repos.  It works well, as long as you don't
> push too much the envelop.  I wish SVK had better support for it.
>

Notwithstanding that IANAL probably applies to everyone likely to
comment here, I would like to know the opinions of the participants in
this email list concerning the proposed use of SVN external sources.
Does this "technical solution" really provide a way to avoid
incompatible license restrictions? For example, would including such
an external definition in the FriCAS and/or OpenAxiom repositories
that points to a separate Aldor repository really make it more
convenient to retain two separate incompatible licenses for panAxiom
and Aldor? Certainly it would be nice to do one checkout, configure,
and make to get a fully operational version of panAxiom+Aldor, but ...

The natural next step would likely be to begin conversion of Axiom
SPAD code to Aldor to create a true
"2nd generation" version of the panAxiom library. Of course doing this
would create something that could not exist except by the combination
of at least two projects with nominally incompatible licenses. In this
case what would be the status of a binary distribution of
panAxiom+Aldor? Would such a binary necessarily have to be distributed
only under terms of the more restrictive APLv2 license?

Finally, do you think we need a more convenient name than
panAxiom+Aldor for this combination?

Regards,
Bill Page.

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Gabriel Dos Reis-2]

"Bill Page" <bill.page@...> writes:

| Ralf Hemmecke writes:
| >
| > | >> Well, isn't there a way in SVN to use 'external sources' so that
| > | >> your repository would never contain the Aldor source tree, but
| > | >> only a reference to it? So the question of distribution would be
| > | >> settled.
| > |
| > | Bill Page asked:
| > | > Ralf, did you find a way to do this? Do you know if this approach
| > | > is used in any open source projects?
| > |
| > | http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html
| > |
| > | I haven't used that myself, but Christian has in his AldorUnit project.
| > | He references his own LibModel project.
| >
|
| On Tue, Jun 17, 2008 at 1:04 PM, Gabriel Dos Reis wrote:
| > I use it for personal repos.  It works well, as long as you don't
| > push too much the envelop.  I wish SVK had better support for it.
| >
|
| Notwithstanding that IANAL probably applies to everyone likely to
| comment here, I would like to know the opinions of the participants in
| this email list concerning the proposed use of SVN external sources.

I have not studied the implications for the licenses.  However, given
the default behaviour of SVN externals (by default, check out the
externals as if inclusion by reference) I would prefer to give
instructions to OpenAxiom users about how to fetch the `externals'.

My previous message was merely commenting on the technical aspects,
not the legal ones.  Sorry if that confuses people.

-- Gaby

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Ralf Hemmecke]

> Notwithstanding that IANAL probably applies to everyone likely to
> comment here, I would like to know the opinions of the participants
> in this email list concerning the proposed use of SVN external
> sources. Does this "technical solution" really provide a way to avoid
>  incompatible license restrictions?

Suppose you open up a SVN repository MyAldorImprovements where you
exclusively include patches to the current source repository

https://aquarium.aldor.csd.uwo.ca/svn, Rev. 23
or
https://svn.origo.ethz.ch/algebraist, Rev. 24

(no code from these repositories ever is included in
MyAldorImprovements). The only thing that connects MyAldorImprovements
with the Aldor (APL2) repositories would be a SVN external property.

But with or without such an external property, who can forbid you to put
your sources at MyAldorImprovements under GPL?

It is the user who actually compiles everything together to make the
merge of the sources and produce the final binary. I don't see any legal
problem. Anybody else?

Such a scenario would at least make it possible for people who want to
improve Aldor to go on with a free license for the additional stuff even
if Aldor itself is only semi-free.

> For example, would including such an external definition in the
> FriCAS and/or OpenAxiom repositories that points to a separate Aldor
> repository really make it more convenient to retain two separate
> incompatible licenses for panAxiom and Aldor? Certainly it would be
> nice to do one checkout, configure, and make to get a fully
> operational version of panAxiom+Aldor, but ...

The extra download can also be made through a Makefile, there is no need
to use SVN:external. See
http://fricas.svn.sourceforge.net/viewvc/fricas/branches/aldor-interface/src/aldor/Makefile.in?view=markup&pathrev=296 
lines 143-183.
(But I hope that for those few .as files that I now reference in that
fricas branch, Aldor.org and NAG agree to release them under mBSD soon.)

The problem is that the a binary must be distributed under APL2. If
something like MyAldorImprovements uses GPL there cannot be any
distribution of a binary, since it would violate both GPL and APL2.
Everyone would have to make his own version of Aldor.

Very inconvenient indeed. But isn't it more important to enable all
those who want to contribute to Aldor under a free license to do so by a
free "extension" repository like MyAldorImprovements?

Ralf

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org