From dabenavidesd at yahoo.es  Wed May  2 18:07:02 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 2 May 2012 17:07:02 +0100 (BST)
Subject: [M3devel] About something we shouldn't care?
Message-ID: <1335974822.36880.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
http://app.reg.techweb.com/e/es.aspx?s=2150&e=50711&elq=cef656ee4d6c4bca996b337620b98f85

Oracle is/seems to be claiming no one except them can implement their API without a license, being Android a not JVM-compatible product, then what is this for Modula-3, threads, are still of them?
IMHO I don't think this is something we should care as Modula- has received any recovery of investment of this APIs, then we could make tons of money, or me not but at least DEC, etc.
Thanks in advance


From dataf4l at gmail.com  Wed May  2 18:57:20 2012
From: dataf4l at gmail.com (felipe valdez)
Date: Wed, 2 May 2012 11:57:20 -0500
Subject: [M3devel] About something we shouldn't care?
In-Reply-To: <1335974822.36880.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <1335974822.36880.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <CAGi-_-9fCmreApLkUGZJ5-CXNGYVWuELXVrL0p=Agnx70Q37WQ@mail.gmail.com>

if oracle wins, then IBM can sue them for their SQL.



On Wed, May 2, 2012 at 11:07 AM, Daniel Alejandro Benavides D. <
dabenavidesd at yahoo.es> wrote:

> Hi all:
>
> http://app.reg.techweb.com/e/es.aspx?s=2150&e=50711&elq=cef656ee4d6c4bca996b337620b98f85
>
> Oracle is/seems to be claiming no one except them can implement their API
> without a license, being Android a not JVM-compatible product, then what is
> this for Modula-3, threads, are still of them?
> IMHO I don't think this is something we should care as Modula- has
> received any recovery of investment of this APIs, then we could make tons
> of money, or me not but at least DEC, etc.
> Thanks in advance
>



-- 
312-444-2124
Skype: f3l.headhunter
Casa: 8043901
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120502/d6e9d22b/attachment.html>

From dabenavidesd at yahoo.es  Wed May  2 19:27:37 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 2 May 2012 18:27:37 +0100 (BST)
Subject: [M3devel] About something we shouldn't care?
In-Reply-To: <CAGi-_-9fCmreApLkUGZJ5-CXNGYVWuELXVrL0p=Agnx70Q37WQ@mail.gmail.com>
Message-ID: <1335979657.75013.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all.
Talking about IBM, they constructed an incremental computation system in Modula-3, so guess what does it care to be written in Modula-3
Thanks in advance

--- El mi?, 2/5/12, felipe valdez <dataf4l at gmail.com> escribi?:

De: felipe valdez <dataf4l at gmail.com>
Asunto: Re: [M3devel] About something we shouldn't care?
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: m3devel at elegosoft.com
Fecha: mi?rcoles, 2 de mayo, 2012 11:57

if oracle wins, then IBM can sue them for their SQL.



On Wed, May 2, 2012 at 11:07 AM, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:


Hi all:

http://app.reg.techweb.com/e/es.aspx?s=2150&e=50711&elq=cef656ee4d6c4bca996b337620b98f85





Oracle is/seems to be claiming no one except them can implement their API without a license, being Android a not JVM-compatible product, then what is this for Modula-3, threads, are still of them?

IMHO I don't think this is something we should care as Modula- has received any recovery of investment of this APIs, then we could make tons of money, or me not but at least DEC, etc.

Thanks in advance




-- 
312-444-2124Skype: f3l.headhunterCasa: 8043901


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120502/726b8e28/attachment.html>

From dabenavidesd at yahoo.es  Wed May  2 21:24:49 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 2 May 2012 20:24:49 +0100 (BST)
Subject: [M3devel] About something we shouldn't care?
In-Reply-To: <CAGi-_-9fCmreApLkUGZJ5-CXNGYVWuELXVrL0p=Agnx70Q37WQ@mail.gmail.com>
Message-ID: <1335986689.43364.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
Besides RMI, we have exceptions, interfaces, garbage collection of references of modular type system (because this was demonstrated in Java-class like languages), which everything is an object except the object itself that is not classic language BTW, classic is Modula-3, so I don't know why they claim, C-like structures are classic:

ftp://cs.stanford.edu/cs/theory/katiyar/papers/PhDThesis.ps

And the most basic thing in Java languages are objects so, I don't know how they claim that they invented that.

Instead Modula-3 Objects are pure Object type systems, functional like Baby Modula-3, or Modular, like Modula-3 itself. But aside of that Java is not-centric object-oriented, just Modular, but Modula-3 is purely Modular, and if you want Module oriented development you are thinking in wise understood language, not in an unproven "Object-oriented" language.

Thanks in advance

--- El mi?, 2/5/12, felipe valdez <dataf4l at gmail.com> escribi?:

De: felipe valdez <dataf4l at gmail.com>
Asunto: Re: [M3devel] About something we shouldn't care?
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: m3devel at elegosoft.com
Fecha: mi?rcoles, 2 de mayo, 2012 11:57

if oracle wins, then IBM can sue them for their SQL.



On Wed, May 2, 2012 at 11:07 AM, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:


Hi all:

http://app.reg.techweb.com/e/es.aspx?s=2150&e=50711&elq=cef656ee4d6c4bca996b337620b98f85





Oracle is/seems to be claiming no one except them can implement their API without a license, being Android a not JVM-compatible product, then what is this for Modula-3, threads, are still of them?

IMHO I don't think this is something we should care as Modula- has received any recovery of investment of this APIs, then we could make tons of money, or me not but at least DEC, etc.

Thanks in advance




-- 
312-444-2124Skype: f3l.headhunterCasa: 8043901


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120502/c15d61ba/attachment.html>

From dragisha at m3w.org  Fri May  4 22:37:19 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 4 May 2012 22:37:19 +0200
Subject: [M3devel] GC algorithm
Message-ID: <488CE4EB-8FAA-4D43-8481-D5DD3B3BE3FB@m3w.org>

I am not very fluent with RTCollector source, but it looks to me there is at least one possible race condition situation possible.

RTHooks.CheckStoreTraced() explicitly marks object & its page dirty/not-clean. Everything with heap locked. But - next thing is - heaps is unlocked and this method returns. What if collector from other thread "hijacks" heap right at end of CheckStoreTraced()/well before mutator changes some reference field in object? 

Similar situaction is with "read barrier" in CheckLoadTraceRef(). Or at least it looks like one to me :).

dd



From dragisha at m3w.org  Fri May  4 22:55:03 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 4 May 2012 22:55:03 +0200
Subject: [M3devel] GC algorithm
In-Reply-To: <488CE4EB-8FAA-4D43-8481-D5DD3B3BE3FB@m3w.org>
References: <488CE4EB-8FAA-4D43-8481-D5DD3B3BE3FB@m3w.org>
Message-ID: <2397638D-5AA9-4C9F-B286-452AED50F769@m3w.org>

.. Getting at this. Probably not a problem because reference is, in case when this is emitted by compiler, on stack/registers. As ambiguous root - object/page will not be altered. So, probably not race, when called as a hook from compiler emitted code?

On May 4, 2012, at 10:37 PM, Dragi?a Duri? wrote:

> I am not very fluent with RTCollector source, but it looks to me there is at least one possible race condition situation possible.
> 
> RTHooks.CheckStoreTraced() explicitly marks object & its page dirty/not-clean. Everything with heap locked. But - next thing is - heaps is unlocked and this method returns. What if collector from other thread "hijacks" heap right at end of CheckStoreTraced()/well before mutator changes some reference field in object? 
> 
> Similar situaction is with "read barrier" in CheckLoadTraceRef(). Or at least it looks like one to me :).
> 
> dd
> 



From dabenavidesd at yahoo.es  Fri May  4 23:30:32 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 4 May 2012 22:30:32 +0100 (BST)
Subject: [M3devel] A possible grammar overstrictness or ambiguity problem
Message-ID: <1336167032.54236.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
Please take a look at p. 18:
http://math.guc.edu.eg/Wafik/Characterizing%20Unambiguity.pdf

I have recreated in a small program not particulary useful to you but to the example:
///////////////////////// Main.m3 /////////////////////////////////
MODULE Main;
VAR a, b :=FALSE;

BEGIN

IF b = (NOT a)
 THEN a:=b;
END 

END Main.

It works as theory expresses but in my small program's alphabet it's overstrict, isn't it? Line 6 is a bad expression without parenthesis.

 Thanks in advance


From rodney_bates at lcwb.coop  Sun May  6 01:27:31 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 05 May 2012 18:27:31 -0500
Subject: [M3devel] A possible grammar overstrictness or ambiguity problem
In-Reply-To: <1336167032.54236.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1336167032.54236.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <4FA5B763.5030205@lcwb.coop>

Hmm, interesting.  If the expression were  NOT a = b, (and no precedence rules),
there would be two ways to parenthesize: (NOT a) = b and NOT (a = b), an
ambiguity.  Making NOT have lower precedence than = resolves this in favor
of the latter.  Equivalently, the grammar is written so that = demands each
of its operands be E4 or higher, which NOT E3 is not, it's an E2.  This fixes
this and other potential ambiguities.

But in the example, since NOT is only a prefix operator, there is only way
to parenthesize, i.e. nothing like (b =) NOT a.  So the precedence would not be
necessary in this case.  But the grammar is written to apply the precedence
rule consistently, leaving the unparenthesized version b = NOT a
underivable.  Overly strict, but maybe not worth the trouble to weaken.

An interesting exercise that I do not have the energy to do would be to
rewrite the M3 expression grammar to allow b = NOT a, without introducing
ambiguity elsewhere.  And make it work on the other prefix operators + and -.
Would be good for a textbook.

I don't think postfix operators (Selector in the grammar) can get into
a counterpart problem because they have the highest precedence.

On 05/04/2012 04:30 PM, Daniel Alejandro Benavides D. wrote:
> Hi all:
> Please take a look at p. 18:
> http://math.guc.edu.eg/Wafik/Characterizing%20Unambiguity.pdf
>
> I have recreated in a small program not particulary useful to you but to the example:
> ///////////////////////// Main.m3 /////////////////////////////////
> MODULE Main;
> VAR a, b :=FALSE;
>
> BEGIN
>
> IF b = (NOT a)
>   THEN a:=b;
> END
>
> END Main.
>
> It works as theory expresses but in my small program's alphabet it's overstrict, isn't it? Line 6 is a bad expression without parenthesis.
>
>   Thanks in advance
>


From dabenavidesd at yahoo.es  Tue May  8 22:43:13 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 21:43:13 +0100 (BST)
Subject: [M3devel] A possible grammar overstrictness or ambiguity problem
In-Reply-To: <4FA5B763.5030205@lcwb.coop>
Message-ID: <1336509793.29460.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
Thanks for the hints I have just re-read your message, I think you can purpose a multi-value suitable solution:
IF NOT a=b, 
which is in semantic analysis 
same as 
IF b = NOT a
then I think would make the case for the "fix" or vice versa, but I think language definition has no assumptions over this (or at least I can't see them).

I was thinking that we could sort of avoid this by defining a core grammar, in top of which we can put the rest, but this is the harder solution as you say. But I'm thinking along this lines, since I'm a true proposer of Baby Modula-3 be in some form (along the lines) in the Modula-3 language definition.

I wish we could talk more than in typing texts by email, but the other diea I had about this is to introduce animations (Obliq, Trestle, whatever fills our purposes, or better, Juno ones) of the Modula-3 SPWM3 book, since most of the interfaces are in the code base, I think by making a Baby Modula-3 implementation we could insert it in the Chapter 1, in same way (succinctly because Baby is small by language definition) and by allow information on it to be explained incrementally by the language itself in a cool manner.

OK, I will let you know the details, as soon I get into it, but hope you can give more hints or some opinion on anyones behalf.

Thanks in advance

--- El s?b, 5/5/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] A possible grammar overstrictness or ambiguity problem
> Para: m3devel at elegosoft.com
> Fecha: s?bado, 5 de mayo, 2012 18:27
> Hmm, interesting.  If the
> expression were  NOT a = b, (and no precedence rules),
> there would be two ways to parenthesize: (NOT a) = b and NOT
> (a = b), an
> ambiguity.  Making NOT have lower precedence than =
> resolves this in favor
> of the latter.  Equivalently, the grammar is written so
> that = demands each
> of its operands be E4 or higher, which NOT E3 is not, it's
> an E2.  This fixes
> this and other potential ambiguities.
> 
> But in the example, since NOT is only a prefix operator,
> there is only way
> to parenthesize, i.e. nothing like (b =) NOT a.  So the
> precedence would not be
> necessary in this case.  But the grammar is written to
> apply the precedence
> rule consistently, leaving the unparenthesized version b =
> NOT a
> underivable.  Overly strict, but maybe not worth the
> trouble to weaken.
> 
> An interesting exercise that I do not have the energy to do
> would be to
> rewrite the M3 expression grammar to allow b = NOT a,
> without introducing
> ambiguity elsewhere.  And make it work on the other
> prefix operators + and -.
> Would be good for a textbook.
> 
> I don't think postfix operators (Selector in the grammar)
> can get into
> a counterpart problem because they have the highest
> precedence.
> 
> On 05/04/2012 04:30 PM, Daniel Alejandro Benavides D.
> wrote:
> > Hi all:
> > Please take a look at p. 18:
> > http://math.guc.edu.eg/Wafik/Characterizing%20Unambiguity.pdf
> >
> > I have recreated in a small program not particulary
> useful to you but to the example:
> > ///////////////////////// Main.m3
> /////////////////////////////////
> > MODULE Main;
> > VAR a, b :=FALSE;
> >
> > BEGIN
> >
> > IF b = (NOT a)
> >   THEN a:=b;
> > END
> >
> > END Main.
> >
> > It works as theory expresses but in my small program's
> alphabet it's overstrict, isn't it? Line 6 is a bad
> expression without parenthesis.
> >
> >   Thanks in advance
> >
> 


From dabenavidesd at yahoo.es  Tue May  8 22:58:05 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 21:58:05 +0100 (BST)
Subject: [M3devel] GC algorithm
In-Reply-To: <2397638D-5AA9-4C9F-B286-452AED50F769@m3w.org>
Message-ID: <1336510685.96265.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
Dragisha I can't be quite sure what are you talking about but assuming arbitrary implementations must be the best way to talk respect of the language itself. (This is to me ask the same question but in a garbage Collector-less way)
Thanks in advance

--- El vie, 4/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 4 de mayo, 2012 15:55
> .. Getting at this. Probably not a
> problem because reference is, in case when this is emitted
> by compiler, on stack/registers. As ambiguous root -
> object/page will not be altered. So, probably not race, when
> called as a hook from compiler emitted code?
> 
> On May 4, 2012, at 10:37 PM, Dragi?a Duri? wrote:
> 
> > I am not very fluent with RTCollector source, but it
> looks to me there is at least one possible race condition
> situation possible.
> > 
> > RTHooks.CheckStoreTraced() explicitly marks object
> & its page dirty/not-clean. Everything with heap locked.
> But - next thing is - heaps is unlocked and this method
> returns. What if collector from other thread "hijacks" heap
> right at end of CheckStoreTraced()/well before mutator
> changes some reference field in object? 
> > 
> > Similar situaction is with "read barrier" in
> CheckLoadTraceRef(). Or at least it looks like one to me
> :).
> > 
> > dd
> > 
> 
> 


From dragisha at m3w.org  Tue May  8 23:21:45 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 8 May 2012 23:21:45 +0200
Subject: [M3devel] GC algorithm
In-Reply-To: <F1D953B3-6D64-4A07-B983-7DDC91C6C363@gmail.com>
References: <488CE4EB-8FAA-4D43-8481-D5DD3B3BE3FB@m3w.org>
	<F1D953B3-6D64-4A07-B983-7DDC91C6C363@gmail.com>
Message-ID: <E63127A8-6383-4A46-AF8A-3B6F2CCCF561@m3w.org>

Got that. You pointed write barrier to me few yrs ago, and that's it.

I am reading through RTCollector.m3 in pieces of time I have to spare. Lots of legacy code there. Any good reaosn to keep several different functionalities in single source module? Like RTWeakRef, lots of differentable mutator/collector code and so on?

On May 8, 2012, at 11:12 PM, Antony Hosking wrote:

> Just following up quickly while extremely rushed.
> Indeed, the fact that the mutator has the references on its stack will cause their targets to be pinned (not copied) if a collection intervenes between the marking and before the store.  So, they will be retained.
> 
> On May 4, 2012, at 4:37 PM, Dragi?a Duri? wrote:
> 
>> I am not very fluent with RTCollector source, but it looks to me there is at least one possible race condition situation possible.
>> 
>> RTHooks.CheckStoreTraced() explicitly marks object & its page dirty/not-clean. Everything with heap locked. But - next thing is - heaps is unlocked and this method returns. What if collector from other thread "hijacks" heap right at end of CheckStoreTraced()/well before mutator changes some reference field in object? 
>> 
>> Similar situaction is with "read barrier" in CheckLoadTraceRef(). Or at least it looks like one to me :).
>> 
>> dd
>> 
> 



From dabenavidesd at yahoo.es  Wed May  9 00:02:56 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 23:02:56 +0100 (BST)
Subject: [M3devel] GC algorithm
In-Reply-To: <E63127A8-6383-4A46-AF8A-3B6F2CCCF561@m3w.org>
Message-ID: <1336514576.13662.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
for my God sake, I think is better to be useful than useless, and if that's different from general than specific, that's better, but be careful, we could loose some Boehm GC correspondence in Gcc GC, which would in turn be useful for timing and short cutting the native Modula-3 Collector, specially RTCollector SRC and perhaps the SUN test suite module (more on this later). Tony and his team did that:

http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html

Thanks in advance

--- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "Antony Hosking" <antony.hosking at gmail.com>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 8 de mayo, 2012 16:21
> Got that. You pointed write barrier
> to me few yrs ago, and that's it.
> 
> I am reading through RTCollector.m3 in pieces of time I have
> to spare. Lots of legacy code there. Any good reaosn to keep
> several different functionalities in single source module?
> Like RTWeakRef, lots of differentable mutator/collector code
> and so on?
> 
> On May 8, 2012, at 11:12 PM, Antony Hosking wrote:
> 
> > Just following up quickly while extremely rushed.
> > Indeed, the fact that the mutator has the references on
> its stack will cause their targets to be pinned (not copied)
> if a collection intervenes between the marking and before
> the store.  So, they will be retained.
> > 
> > On May 4, 2012, at 4:37 PM, Dragi?a Duri? wrote:
> > 
> >> I am not very fluent with RTCollector source, but
> it looks to me there is at least one possible race condition
> situation possible.
> >> 
> >> RTHooks.CheckStoreTraced() explicitly marks object
> & its page dirty/not-clean. Everything with heap locked.
> But - next thing is - heaps is unlocked and this method
> returns. What if collector from other thread "hijacks" heap
> right at end of CheckStoreTraced()/well before mutator
> changes some reference field in object? 
> >> 
> >> Similar situaction is with "read barrier" in
> CheckLoadTraceRef(). Or at least it looks like one to me
> :).
> >> 
> >> dd
> >> 
> > 
> 
> 


From dabenavidesd at yahoo.es  Wed May  9 00:20:16 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 23:20:16 +0100 (BST)
Subject: [M3devel] "The New Native Languages" time for us to code a Modula-3
	JIT compiler?
Message-ID: <1336515616.28079.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:

http://app.reg.techweb.com/e/es.aspx?s=2150&e=52494&elq=b491fb8f21d64a28ab346c4bc41650e6

I know of a "unclassified" tool for doing that but end support is a need symbolically speaking.

A guy was working on a LLVM backend, but I don't know, does anyone plans some sort of M3CG related project?

Thanks in advance


From dragisha at m3w.org  Wed May  9 00:20:30 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 9 May 2012 00:20:30 +0200
Subject: [M3devel] GC algorithm
In-Reply-To: <1336514576.13662.YahooMailClassic@web29703.mail.ird.yahoo.com>
References: <1336514576.13662.YahooMailClassic@web29703.mail.ird.yahoo.com>
Message-ID: <F3E03E0F-AD87-4573-8280-A802AAA34C7B@m3w.org>

G1 collector sounds interesting, and funny. Pause prediction - good luck with that.

Fast sweep through blurb on that page and I think this collector of theirs is a bit behind what we have in Modula-3. No wonder - Modula-3 had what they are describing and few things more years before Java existed.

Interesting tidbit, maybe. If they can collect with multiple threads at same time, that _is_ something new. But they danced around that on that page.

Also, G1 is not what Antony and his team did. They made real-time collector, and G1 is not. I think link was posted here some time ago.

On May 9, 2012, at 12:02 AM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> for my God sake, I think is better to be useful than useless, and if that's different from general than specific, that's better, but be careful, we could loose some Boehm GC correspondence in Gcc GC, which would in turn be useful for timing and short cutting the native Modula-3 Collector, specially RTCollector SRC and perhaps the SUN test suite module (more on this later). Tony and his team did that:
> 
> http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
> 
> Thanks in advance
> 
> --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
>> De: Dragi?a Duri? <dragisha at m3w.org>
>> Asunto: Re: [M3devel] GC algorithm
>> Para: "Antony Hosking" <antony.hosking at gmail.com>
>> CC: "m3devel" <m3devel at elegosoft.com>
>> Fecha: martes, 8 de mayo, 2012 16:21
>> Got that. You pointed write barrier
>> to me few yrs ago, and that's it.
>> 
>> I am reading through RTCollector.m3 in pieces of time I have
>> to spare. Lots of legacy code there. Any good reaosn to keep
>> several different functionalities in single source module?
>> Like RTWeakRef, lots of differentable mutator/collector code
>> and so on?
>> 
>> On May 8, 2012, at 11:12 PM, Antony Hosking wrote:
>> 
>>> Just following up quickly while extremely rushed.
>>> Indeed, the fact that the mutator has the references on
>> its stack will cause their targets to be pinned (not copied)
>> if a collection intervenes between the marking and before
>> the store.  So, they will be retained.
>>> 
>>> On May 4, 2012, at 4:37 PM, Dragi?a Duri? wrote:
>>> 
>>>> I am not very fluent with RTCollector source, but
>> it looks to me there is at least one possible race condition
>> situation possible.
>>>> 
>>>> RTHooks.CheckStoreTraced() explicitly marks object
>> & its page dirty/not-clean. Everything with heap locked.
>> But - next thing is - heaps is unlocked and this method
>> returns. What if collector from other thread "hijacks" heap
>> right at end of CheckStoreTraced()/well before mutator
>> changes some reference field in object? 
>>>> 
>>>> Similar situaction is with "read barrier" in
>> CheckLoadTraceRef(). Or at least it looks like one to me
>> :).
>>>> 
>>>> dd
>>>> 
>>> 
>> 
>> 



From dabenavidesd at yahoo.es  Wed May  9 00:36:27 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 23:36:27 +0100 (BST)
Subject: [M3devel] GC algorithm
In-Reply-To: <F3E03E0F-AD87-4573-8280-A802AAA34C7B@m3w.org>
Message-ID: <1336516587.51821.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
OK, understood, I think this kind of philosophy is smoother:
http://static.usenix.org/events/coots99/full_papers/liang/liang.pdf

Similarly the CM JVM  can be applied to this test too.

Look at this old news (it seems they didn't believe it that much, probably that's why they never released it):
http://www.informationweek.com/newsflash/nf655/1105_st9.htm

Thanks in advance

--- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "Antony Hosking" <antony.hosking at gmail.com>, "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 8 de mayo, 2012 17:20
> G1 collector sounds interesting, and
> funny. Pause prediction - good luck with that.
> 
> Fast sweep through blurb on that page and I think this
> collector of theirs is a bit behind what we have in
> Modula-3. No wonder - Modula-3 had what they are describing
> and few things more years before Java existed.
> 
> Interesting tidbit, maybe. If they can collect with multiple
> threads at same time, that _is_ something new. But they
> danced around that on that page.
> 
> Also, G1 is not what Antony and his team did. They made
> real-time collector, and G1 is not. I think link was posted
> here some time ago.
> 
> On May 9, 2012, at 12:02 AM, Daniel Alejandro Benavides D.
> wrote:
> 
> > Hi all:
> > for my God sake, I think is better to be useful than
> useless, and if that's different from general than specific,
> that's better, but be careful, we could loose some Boehm GC
> correspondence in Gcc GC, which would in turn be useful for
> timing and short cutting the native Modula-3 Collector,
> specially RTCollector SRC and perhaps the SUN test suite
> module (more on this later). Tony and his team did that:
> > 
> > http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
> > 
> > Thanks in advance
> > 
> > --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> >> De: Dragi?a Duri? <dragisha at m3w.org>
> >> Asunto: Re: [M3devel] GC algorithm
> >> Para: "Antony Hosking" <antony.hosking at gmail.com>
> >> CC: "m3devel" <m3devel at elegosoft.com>
> >> Fecha: martes, 8 de mayo, 2012 16:21
> >> Got that. You pointed write barrier
> >> to me few yrs ago, and that's it.
> >> 
> >> I am reading through RTCollector.m3 in pieces of
> time I have
> >> to spare. Lots of legacy code there. Any good
> reaosn to keep
> >> several different functionalities in single source
> module?
> >> Like RTWeakRef, lots of differentable
> mutator/collector code
> >> and so on?
> >> 
> >> On May 8, 2012, at 11:12 PM, Antony Hosking wrote:
> >> 
> >>> Just following up quickly while extremely
> rushed.
> >>> Indeed, the fact that the mutator has the
> references on
> >> its stack will cause their targets to be pinned
> (not copied)
> >> if a collection intervenes between the marking and
> before
> >> the store.  So, they will be retained.
> >>> 
> >>> On May 4, 2012, at 4:37 PM, Dragi?a Duri?
> wrote:
> >>> 
> >>>> I am not very fluent with RTCollector
> source, but
> >> it looks to me there is at least one possible race
> condition
> >> situation possible.
> >>>> 
> >>>> RTHooks.CheckStoreTraced() explicitly marks
> object
> >> & its page dirty/not-clean. Everything with
> heap locked.
> >> But - next thing is - heaps is unlocked and this
> method
> >> returns. What if collector from other thread
> "hijacks" heap
> >> right at end of CheckStoreTraced()/well before
> mutator
> >> changes some reference field in object? 
> >>>> 
> >>>> Similar situaction is with "read barrier"
> in
> >> CheckLoadTraceRef(). Or at least it looks like one
> to me
> >> :).
> >>>> 
> >>>> dd
> >>>> 
> >>> 
> >> 
> >> 
> 
> 


From dragisha at m3w.org  Wed May  9 00:40:17 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 9 May 2012 00:40:17 +0200
Subject: [M3devel] GC algorithm
In-Reply-To: <1336516587.51821.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1336516587.51821.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <325641F7-37AF-4BCC-AB5C-78C1172090F0@m3w.org>

Very old news. In JVM world - five years is a lot. 13yrs are another age :).
 
On May 9, 2012, at 12:36 AM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> OK, understood, I think this kind of philosophy is smoother:
> http://static.usenix.org/events/coots99/full_papers/liang/liang.pdf
> 
> Similarly the CM JVM  can be applied to this test too.
> 
> Look at this old news (it seems they didn't believe it that much, probably that's why they never released it):
> http://www.informationweek.com/newsflash/nf655/1105_st9.htm
> 
> Thanks in advance
> 
> --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
>> De: Dragi?a Duri? <dragisha at m3w.org>
>> Asunto: Re: [M3devel] GC algorithm
>> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
>> CC: "Antony Hosking" <antony.hosking at gmail.com>, "m3devel" <m3devel at elegosoft.com>
>> Fecha: martes, 8 de mayo, 2012 17:20
>> G1 collector sounds interesting, and
>> funny. Pause prediction - good luck with that.
>> 
>> Fast sweep through blurb on that page and I think this
>> collector of theirs is a bit behind what we have in
>> Modula-3. No wonder - Modula-3 had what they are describing
>> and few things more years before Java existed.
>> 
>> Interesting tidbit, maybe. If they can collect with multiple
>> threads at same time, that _is_ something new. But they
>> danced around that on that page.
>> 
>> Also, G1 is not what Antony and his team did. They made
>> real-time collector, and G1 is not. I think link was posted
>> here some time ago.
>> 
>> On May 9, 2012, at 12:02 AM, Daniel Alejandro Benavides D.
>> wrote:
>> 
>>> Hi all:
>>> for my God sake, I think is better to be useful than
>> useless, and if that's different from general than specific,
>> that's better, but be careful, we could loose some Boehm GC
>> correspondence in Gcc GC, which would in turn be useful for
>> timing and short cutting the native Modula-3 Collector,
>> specially RTCollector SRC and perhaps the SUN test suite
>> module (more on this later). Tony and his team did that:
>>> 
>>> http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
>>> 
>>> Thanks in advance
>>> 
>>> --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org>
>> escribi?:
>>> 
>>>> De: Dragi?a Duri? <dragisha at m3w.org>
>>>> Asunto: Re: [M3devel] GC algorithm
>>>> Para: "Antony Hosking" <antony.hosking at gmail.com>
>>>> CC: "m3devel" <m3devel at elegosoft.com>
>>>> Fecha: martes, 8 de mayo, 2012 16:21
>>>> Got that. You pointed write barrier
>>>> to me few yrs ago, and that's it.
>>>> 
>>>> I am reading through RTCollector.m3 in pieces of
>> time I have
>>>> to spare. Lots of legacy code there. Any good
>> reaosn to keep
>>>> several different functionalities in single source
>> module?
>>>> Like RTWeakRef, lots of differentable
>> mutator/collector code
>>>> and so on?
>>>> 
>>>> On May 8, 2012, at 11:12 PM, Antony Hosking wrote:
>>>> 
>>>>> Just following up quickly while extremely
>> rushed.
>>>>> Indeed, the fact that the mutator has the
>> references on
>>>> its stack will cause their targets to be pinned
>> (not copied)
>>>> if a collection intervenes between the marking and
>> before
>>>> the store.  So, they will be retained.
>>>>> 
>>>>> On May 4, 2012, at 4:37 PM, Dragi?a Duri?
>> wrote:
>>>>> 
>>>>>> I am not very fluent with RTCollector
>> source, but
>>>> it looks to me there is at least one possible race
>> condition
>>>> situation possible.
>>>>>> 
>>>>>> RTHooks.CheckStoreTraced() explicitly marks
>> object
>>>> & its page dirty/not-clean. Everything with
>> heap locked.
>>>> But - next thing is - heaps is unlocked and this
>> method
>>>> returns. What if collector from other thread
>> "hijacks" heap
>>>> right at end of CheckStoreTraced()/well before
>> mutator
>>>> changes some reference field in object? 
>>>>>> 
>>>>>> Similar situaction is with "read barrier"
>> in
>>>> CheckLoadTraceRef(). Or at least it looks like one
>> to me
>>>> :).
>>>>>> 
>>>>>> dd
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>> 



From dabenavidesd at yahoo.es  Wed May  9 00:47:29 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 23:47:29 +0100 (BST)
Subject: [M3devel] GC algorithm
In-Reply-To: <325641F7-37AF-4BCC-AB5C-78C1172090F0@m3w.org>
Message-ID: <1336517249.96878.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:

but contemporary of the SUN's profiler article.

Thanks in advance


--- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "Antony Hosking" <antony.hosking at gmail.com>, "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 8 de mayo, 2012 17:40
> Very old news. In JVM world - five
> years is a lot. 13yrs are another age :).
>  
> On May 9, 2012, at 12:36 AM, Daniel Alejandro Benavides D.
> wrote:
> 
> > Hi all:
> > OK, understood, I think this kind of philosophy is
> smoother:
> > http://static.usenix.org/events/coots99/full_papers/liang/liang.pdf
> > 
> > Similarly the CM JVM  can be applied to this test
> too.
> > 
> > Look at this old news (it seems they didn't believe it
> that much, probably that's why they never released it):
> > http://www.informationweek.com/newsflash/nf655/1105_st9.htm
> > 
> > Thanks in advance
> > 
> > --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> >> De: Dragi?a Duri? <dragisha at m3w.org>
> >> Asunto: Re: [M3devel] GC algorithm
> >> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> >> CC: "Antony Hosking" <antony.hosking at gmail.com>,
> "m3devel" <m3devel at elegosoft.com>
> >> Fecha: martes, 8 de mayo, 2012 17:20
> >> G1 collector sounds interesting, and
> >> funny. Pause prediction - good luck with that.
> >> 
> >> Fast sweep through blurb on that page and I think
> this
> >> collector of theirs is a bit behind what we have
> in
> >> Modula-3. No wonder - Modula-3 had what they are
> describing
> >> and few things more years before Java existed.
> >> 
> >> Interesting tidbit, maybe. If they can collect with
> multiple
> >> threads at same time, that _is_ something new. But
> they
> >> danced around that on that page.
> >> 
> >> Also, G1 is not what Antony and his team did. They
> made
> >> real-time collector, and G1 is not. I think link
> was posted
> >> here some time ago.
> >> 
> >> On May 9, 2012, at 12:02 AM, Daniel Alejandro
> Benavides D.
> >> wrote:
> >> 
> >>> Hi all:
> >>> for my God sake, I think is better to be useful
> than
> >> useless, and if that's different from general than
> specific,
> >> that's better, but be careful, we could loose some
> Boehm GC
> >> correspondence in Gcc GC, which would in turn be
> useful for
> >> timing and short cutting the native Modula-3
> Collector,
> >> specially RTCollector SRC and perhaps the SUN test
> suite
> >> module (more on this later). Tony and his team did
> that:
> >>> 
> >>> http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
> >>> 
> >>> Thanks in advance
> >>> 
> >>> --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org>
> >> escribi?:
> >>> 
> >>>> De: Dragi?a Duri? <dragisha at m3w.org>
> >>>> Asunto: Re: [M3devel] GC algorithm
> >>>> Para: "Antony Hosking" <antony.hosking at gmail.com>
> >>>> CC: "m3devel" <m3devel at elegosoft.com>
> >>>> Fecha: martes, 8 de mayo, 2012 16:21
> >>>> Got that. You pointed write barrier
> >>>> to me few yrs ago, and that's it.
> >>>> 
> >>>> I am reading through RTCollector.m3 in
> pieces of
> >> time I have
> >>>> to spare. Lots of legacy code there. Any
> good
> >> reaosn to keep
> >>>> several different functionalities in single
> source
> >> module?
> >>>> Like RTWeakRef, lots of differentable
> >> mutator/collector code
> >>>> and so on?
> >>>> 
> >>>> On May 8, 2012, at 11:12 PM, Antony Hosking
> wrote:
> >>>> 
> >>>>> Just following up quickly while
> extremely
> >> rushed.
> >>>>> Indeed, the fact that the mutator has
> the
> >> references on
> >>>> its stack will cause their targets to be
> pinned
> >> (not copied)
> >>>> if a collection intervenes between the
> marking and
> >> before
> >>>> the store.  So, they will be
> retained.
> >>>>> 
> >>>>> On May 4, 2012, at 4:37 PM, Dragi?a
> Duri?
> >> wrote:
> >>>>> 
> >>>>>> I am not very fluent with
> RTCollector
> >> source, but
> >>>> it looks to me there is at least one
> possible race
> >> condition
> >>>> situation possible.
> >>>>>> 
> >>>>>> RTHooks.CheckStoreTraced()
> explicitly marks
> >> object
> >>>> & its page dirty/not-clean. Everything
> with
> >> heap locked.
> >>>> But - next thing is - heaps is unlocked and
> this
> >> method
> >>>> returns. What if collector from other
> thread
> >> "hijacks" heap
> >>>> right at end of CheckStoreTraced()/well
> before
> >> mutator
> >>>> changes some reference field in object? 
> >>>>>> 
> >>>>>> Similar situaction is with "read
> barrier"
> >> in
> >>>> CheckLoadTraceRef(). Or at least it looks
> like one
> >> to me
> >>>> :).
> >>>>>> 
> >>>>>> dd
> >>>>>> 
> >>>>> 
> >>>> 
> >>>> 
> >> 
> >> 
> 
> 


From dragisha at m3w.org  Fri May 11 09:44:17 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 11 May 2012 09:44:17 +0200
Subject: [M3devel] Proposal for new pragma
Message-ID: <A1D021C3-0B10-4D2C-B0E2-FADCF857850E@m3w.org>

DEBUG and ASSERT pragmas are good examples of very helpful and almost non-intrusive debug features. UNUSED is also worth mention.

Another good one can be a way to tell compiler where some object is expected to be referenced. I am just reading big source and part of what I do is to add comments - in particular I comment where from is some procedure called/variable used. Putting this in pragma will not change language at all, but will help writing correct programs a lot.

Also, once we establish a framework for such attributes, steps can be taken towards further ways to ensure correctness of code we write.



From dragisha at m3w.org  Fri May 11 09:49:41 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 11 May 2012 09:49:41 +0200
Subject: [M3devel] Proposal for new pragma
Message-ID: <1EB31CDB-C6DC-4A42-B9EE-3CA0743028A0@m3w.org>

DEBUG and ASSERT pragmas are good examples of very helpful and almost non-intrusive debug features. UNUSED is also worth mention.

Another good one can be a way to tell compiler where some object is expected to be referenced. I am just reading big source and part of what I do is to add comments - in particular I comment where from is some procedure called/variable used. Putting this in pragma will not change language at all, but will help writing correct programs a lot.

Also, once we establish a framework for such attributes, steps can be taken towards further ways to ensure correctness of code we write.



From dabenavidesd at yahoo.es  Fri May 11 17:08:03 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 11 May 2012 16:08:03 +0100 (BST)
Subject: [M3devel] Proposal for new pragma
In-Reply-To: <82A6C364-C699-4C7C-B482-F197EF4D4D1B@m3w.org>
Message-ID: <1336748883.38986.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
any program can have such construct? The main con is if it does what does it mean to be undetected side-effects, sort of writing for your self. Also what does the program needs to do to ensure safety under such considerations. For instance does it allows a program to be checked?
It is not moral correct to write something to hide details of the implementation to it but to your self?
OK, you can ignore some details I guess but then who cares what you don't know, more than we don't know. This is the ideal; isn't to expose the structure of an operation towards getting the correct answer, if you can't make both something is wrong, both your program or your language.
In certain sense we can avoid undetected side-effects, but your responsibility is about it where there are ones. If your program can check or know that I think is wrong respect of that programmer, since he should read it without that help. Right? 
Thanks in advance
 

--- El vie, 11/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] Proposal for new pragma
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> Fecha: viernes, 11 de mayo, 2012 09:31
> Code readability will be nice effect
> of such a pragma. And - if written correctly, all pragmas
> have no to minimal side-effects.
> 
> On May 11, 2012, at 4:26 PM, Daniel Alejandro Benavides D.
> wrote:
> 
> > Hi all:
> > I'm not sure whether you want to handle inter
> procedural side effects, if that's the case Modula-3 done
> code needs arbitrary annotations of such constructs isn't
> guaranteed to be safely isolated since every annotation is
> side-effected then it could led towards the not sound
> Modular checking of ESC/Modula-3, etc. This is a natural
> deduction system.
> > Having said that I think is a good idea to allow
> recursion logic to Modula-3 procedures but this is precisely
> what Baby Modula-3 is about.
> > I don't have more details at hand but I think the idea
> if is yours the same has better compression of code,
> optimization and safe execution.
> > The good news is that object-code view of objects in
> Baby Modula-3 and Modula-3 is the same so all benefits are
> applicable.
> > Perhaps the other approach is just use the M3 AST and
> someone has done something akin to localize uncalled
> procedures, etc.
> > Thanks in advance
> > 
> > --- El vie, 11/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> >> De: Dragi?a Duri? <dragisha at m3w.org>
> >> Asunto: [M3devel] Proposal for new pragma
> >> Para: "m3devel" <m3devel at elegosoft.com>
> >> Fecha: viernes, 11 de mayo, 2012 02:49
> >> DEBUG and ASSERT pragmas are good
> >> examples of very helpful and almost non-intrusive
> debug
> >> features. UNUSED is also worth mention.
> >> 
> >> Another good one can be a way to tell compiler
> where some
> >> object is expected to be referenced. I am just
> reading big
> >> source and part of what I do is to add comments -
> in
> >> particular I comment where from is some procedure
> >> called/variable used. Putting this in pragma will
> not change
> >> language at all, but will help writing correct
> programs a
> >> lot.
> >> 
> >> Also, once we establish a framework for such
> attributes,
> >> steps can be taken towards further ways to ensure
> >> correctness of code we write.
> >> 
> >> 
> 
> 


From dragisha at m3w.org  Fri May 11 19:29:35 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 11 May 2012 19:29:35 +0200
Subject: [M3devel] Proposal for new pragma
In-Reply-To: <1336748883.38986.YahooMailClassic@web29704.mail.ird.yahoo.com>
References: <1336748883.38986.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <4B5415DB-107E-49EC-9AE7-7DCFB5088114@m3w.org>

It would ne kind of DEBUG/ASSERT/UNUSED.

Obviously, it is meant to be used in implementation. And to be optional. You may use it, but you don't have to.

As for moral? I'll no comment it :).

Side-effects are possible with DEBUG/ASSERT. They will be possible with this new pragma. Take care.

On May 11, 2012, at 5:08 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> any program can have such construct? The main con is if it does what does it mean to be undetected side-effects, sort of writing for your self. Also what does the program needs to do to ensure safety under such considerations. For instance does it allows a program to be checked?
> It is not moral correct to write something to hide details of the implementation to it but to your self?
> OK, you can ignore some details I guess but then who cares what you don't know, more than we don't know. This is the ideal; isn't to expose the structure of an operation towards getting the correct answer, if you can't make both something is wrong, both your program or your language.
> In certain sense we can avoid undetected side-effects, but your responsibility is about it where there are ones. If your program can check or know that I think is wrong respect of that programmer, since he should read it without that help. Right? 
> Thanks in advance
> 
> 
> --- El vie, 11/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
>> De: Dragi?a Duri? <dragisha at m3w.org>
>> Asunto: Re: [M3devel] Proposal for new pragma
>> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
>> Fecha: viernes, 11 de mayo, 2012 09:31
>> Code readability will be nice effect
>> of such a pragma. And - if written correctly, all pragmas
>> have no to minimal side-effects.
>> 
>> On May 11, 2012, at 4:26 PM, Daniel Alejandro Benavides D.
>> wrote:
>> 
>>> Hi all:
>>> I'm not sure whether you want to handle inter
>> procedural side effects, if that's the case Modula-3 done
>> code needs arbitrary annotations of such constructs isn't
>> guaranteed to be safely isolated since every annotation is
>> side-effected then it could led towards the not sound
>> Modular checking of ESC/Modula-3, etc. This is a natural
>> deduction system.
>>> Having said that I think is a good idea to allow
>> recursion logic to Modula-3 procedures but this is precisely
>> what Baby Modula-3 is about.
>>> I don't have more details at hand but I think the idea
>> if is yours the same has better compression of code,
>> optimization and safe execution.
>>> The good news is that object-code view of objects in
>> Baby Modula-3 and Modula-3 is the same so all benefits are
>> applicable.
>>> Perhaps the other approach is just use the M3 AST and
>> someone has done something akin to localize uncalled
>> procedures, etc.
>>> Thanks in advance
>>> 
>>> --- El vie, 11/5/12, Dragi?a Duri? <dragisha at m3w.org>
>> escribi?:
>>> 
>>>> De: Dragi?a Duri? <dragisha at m3w.org>
>>>> Asunto: [M3devel] Proposal for new pragma
>>>> Para: "m3devel" <m3devel at elegosoft.com>
>>>> Fecha: viernes, 11 de mayo, 2012 02:49
>>>> DEBUG and ASSERT pragmas are good
>>>> examples of very helpful and almost non-intrusive
>> debug
>>>> features. UNUSED is also worth mention.
>>>> 
>>>> Another good one can be a way to tell compiler
>> where some
>>>> object is expected to be referenced. I am just
>> reading big
>>>> source and part of what I do is to add comments -
>> in
>>>> particular I comment where from is some procedure
>>>> called/variable used. Putting this in pragma will
>> not change
>>>> language at all, but will help writing correct
>> programs a
>>>> lot.
>>>> 
>>>> Also, once we establish a framework for such
>> attributes,
>>>> steps can be taken towards further ways to ensure
>>>> correctness of code we write.
>>>> 
>>>> 
>> 
>> 



From hendrik at topoi.pooq.com  Sun May 13 19:47:47 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Sun, 13 May 2012 13:47:47 -0400
Subject: [M3devel] libXaw.so.6 again
Message-ID: <20120513174747.GA25729@topoi.pooq.com>

I just installed the AMD64 LINUX deb on my aging Debian stable system, 
tried it out, and got the familiar=from-years-ago message

 -> linking PgMdb
/usr/bin/ld: warning: libXaw.so.6, needed by 
/usr/local/cm3/pkg/formsvbt/AMD64_LINUX/libm3formsvbt.so, not found (try 
using -rpath or -rpath-link)
collect2: ld returned 1 exit status
  m3_link => 1
linker failed linking: PgMdb

Now the obvious thing to do is to install libXaw.so.6.

Except that the only libXaw packages available are libXaw7, libXaw7-dev, 
and similar for libXaw8.

So it  looks as if the .deb needs updating, presumably with a new Debian 
version number affixed.

-- hendrik



From hendrik at topoi.pooq.com  Sun May 13 19:50:49 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Sun, 13 May 2012 13:50:49 -0400
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120513174747.GA25729@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
Message-ID: <20120513175049.GA25774@topoi.pooq.com>

On Sun, May 13, 2012 at 01:47:47PM -0400, Hendrik Boom wrote:
> I just installed the AMD64 LINUX deb on my aging Debian stable system, 
> tried it out, and got the familiar=from-years-ago message
> 
>  -> linking PgMdb
> /usr/bin/ld: warning: libXaw.so.6, needed by 
> /usr/local/cm3/pkg/formsvbt/AMD64_LINUX/libm3formsvbt.so, not found (try 
> using -rpath or -rpath-link)
> collect2: ld returned 1 exit status
>   m3_link => 1
> linker failed linking: PgMdb
> 
> Now the obvious thing to do is to install libXaw.so.6.
> 
> Except that the only libXaw packages available are libXaw7, libXaw7-dev, 
> and similar for libXaw8.

Correction: no libXaw8-dev.
> 
> So it  looks as if the .deb needs updating, presumably with a new Debian 
> version number affixed.
> 
> -- hendrik
> 

The situation is pretty well the same on Debian testing i386.

-- hendrik



From dabenavidesd at yahoo.es  Sun May 13 20:06:44 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 13 May 2012 19:06:44 +0100 (BST)
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120513174747.GA25729@topoi.pooq.com>
Message-ID: <1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I think the packages in deb already do that so.6, so.7 thing for that purposes, you don't need to that for yourself, I believe.
Likewise, would be nicer if we could just relink a single executable for both kind of systems, both 32-bit and 64-bit, if there were 32-bit INTEGER and ADDRESS and 128-bit LONGINT and LONGADDRESS and 128-bit LONGCARD I think it could make a better precision arithmetic or double-length at less.
Thanks in advance

--- El dom, 13/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] libXaw.so.6 again
> Para: m3devel at elegosoft.com
> Fecha: domingo, 13 de mayo, 2012 12:47
> I just installed the AMD64 LINUX deb
> on my aging Debian stable system, 
> tried it out, and got the familiar=from-years-ago message
> 
>  -> linking PgMdb
> /usr/bin/ld: warning: libXaw.so.6, needed by 
> /usr/local/cm3/pkg/formsvbt/AMD64_LINUX/libm3formsvbt.so,
> not found (try 
> using -rpath or -rpath-link)
> collect2: ld returned 1 exit status
>   m3_link => 1
> linker failed linking: PgMdb
> 
> Now the obvious thing to do is to install libXaw.so.6.
> 
> Except that the only libXaw packages available are libXaw7,
> libXaw7-dev, 
> and similar for libXaw8.
> 
> So it  looks as if the .deb needs updating, presumably
> with a new Debian 
> version number affixed.
> 
> -- hendrik
> 
> 


From hendrik at topoi.pooq.com  Mon May 14 04:52:18 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Sun, 13 May 2012 22:52:18 -0400
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <20120514025218.GA32463@topoi.pooq.com>

On Sun, May 13, 2012 at 07:06:44PM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all:
> I think the packages in deb already do that so.6, so.7 thing for that 
> purposes, you don't need to that for yourself, I believe.

Whatever do you mean?  It wants libXaw.so.6, which no longer exists and 
has been replaced by libXaw.so.7.  Whatever "that so.6, so.7 thing" is 
that the packages in deb already do, the modula 2 in the debian package 
I downloaded just now from the Modula 3 website insists that my 
executable needs libXaw.so.6, not the one I have available.

Maybe if the .deb were recompiled and repackaged from source it would 
find libXaw.so.7, but the one now available does not.

-- hendrik

> Likewise, would be nicer if we could just relink a single executable 
> for both kind of systems, both 32-bit and 64-bit, if there were 32-bit 
> INTEGER and ADDRESS and 128-bit LONGINT and LONGADDRESS and 128-bit 
> LONGCARD I think it could make a better precision arithmetic or 
> double-length at less.

This has nothing to do with the question.

-- hendrik


From dabenavidesd at yahoo.es  Mon May 14 07:24:11 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 May 2012 06:24:11 +0100 (BST)
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120514025218.GA32463@topoi.pooq.com>
Message-ID: <1336973051.28791.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
OK, thanks for the message, I meant what I think is the case for say Ubuntu 8.04 Dapper LTS (Long time support), have libXaw6 and libXaw7 packages in .deb.
I don't think that you need to relink the all package (or worse than that rebuild to link .so.7) but just use your OS for that (because we will loose support for other OSes that don't have literally have such version).
And to make a smarter solution I would use LONG (adress) arithmetic to relink same executable for two kind of "different" architectures. You think isn't the same, but I think they are but one is just an extension of the other so why not support that as well.
Then why would you need to test I386, and AMD64 versions (then the question is the name of that target x86-32AMD64), but just the same executable and the same thing (again, use your OS for that, don't change your build conf).
Certainly this are configuration management issues, that the software engineer shouldn't care, should you?
Thanks in advance


--- El dom, 13/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] libXaw.so.6 again
> Para: m3devel at elegosoft.com
> Fecha: domingo, 13 de mayo, 2012 21:52
> On Sun, May 13, 2012 at 07:06:44PM
> +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I think the packages in deb already do that so.6, so.7
> thing for that 
> > purposes, you don't need to that for yourself, I
> believe.
> 
> Whatever do you mean?  It wants libXaw.so.6, which no
> longer exists and 
> has been replaced by libXaw.so.7.  Whatever "that so.6,
> so.7 thing" is 
> that the packages in deb already do, the modula 2 in the
> debian package 
> I downloaded just now from the Modula 3 website insists that
> my 
> executable needs libXaw.so.6, not the one I have available.
> 
> Maybe if the .deb were recompiled and repackaged from source
> it would 
> find libXaw.so.7, but the one now available does not.
> 
> -- hendrik
> 
> > Likewise, would be nicer if we could just relink a
> single executable 
> > for both kind of systems, both 32-bit and 64-bit, if
> there were 32-bit 
> > INTEGER and ADDRESS and 128-bit LONGINT and LONGADDRESS
> and 128-bit 
> > LONGCARD I think it could make a better precision
> arithmetic or 
> > double-length at less.
> 
> This has nothing to do with the question.
> 
> -- hendrik
> 


From dragisha at m3w.org  Mon May 14 07:32:49 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 14 May 2012 07:32:49 +0200
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120514025218.GA32463@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
Message-ID: <C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>

Source change (relevant m3makefile) is one path.

Another is to ln -s existing libXaw.so.7 to libXaw.so.6

dd

On May 14, 2012, at 4:52 AM, Hendrik Boom wrote:

> On Sun, May 13, 2012 at 07:06:44PM +0100, Daniel Alejandro Benavides D. wrote:
>> Hi all:
>> I think the packages in deb already do that so.6, so.7 thing for that 
>> purposes, you don't need to that for yourself, I believe.
> 
> Whatever do you mean?  It wants libXaw.so.6, which no longer exists and 
> has been replaced by libXaw.so.7.  Whatever "that so.6, so.7 thing" is 
> that the packages in deb already do, the modula 2 in the debian package 
> I downloaded just now from the Modula 3 website insists that my 
> executable needs libXaw.so.6, not the one I have available.
> 
> Maybe if the .deb were recompiled and repackaged from source it would 
> find libXaw.so.7, but the one now available does not.
> 
> -- hendrik
> 
>> Likewise, would be nicer if we could just relink a single executable 
>> for both kind of systems, both 32-bit and 64-bit, if there were 32-bit 
>> INTEGER and ADDRESS and 128-bit LONGINT and LONGADDRESS and 128-bit 
>> LONGCARD I think it could make a better precision arithmetic or 
>> double-length at less.
> 
> This has nothing to do with the question.
> 
> -- hendrik



From mika at async.caltech.edu  Mon May 14 08:51:15 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sun, 13 May 2012 23:51:15 -0700
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org> 
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
Message-ID: <20120514065115.6FD231A205B@async.async.caltech.edu>

=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
...
>Another is to ln -s existing libXaw.so.7 to libXaw.so.6
...

"Not guaranteed to work" but almost always does, right?


From jay.krell at cornell.edu  Mon May 14 09:20:08 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 May 2012 07:20:08 +0000
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120514065115.6FD231A205B@async.async.caltech.edu>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>,
	<20120514025218.GA32463@topoi.pooq.com>,
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>,
	<20120514065115.6FD231A205B@async.async.caltech.edu>
Message-ID: <COL101-W216A71B993859824CC43E5E61A0@phx.gbl>


Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
I find this very surprising, crazy, disappointing, but apparently true.
We must distribute source to achieve the usual expected portability.
 C source at that, to achieve the usual expected buildability.
Or maybe I'm confused.
The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.


 - Jay


> To: dragisha at m3w.org
> Date: Sun, 13 May 2012 23:51:15 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] libXaw.so.6 again
> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/2798e2e1/attachment.html>

From dragisha at m3w.org  Mon May 14 10:04:15 2012
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 14 May 2012 10:04:15 +0200
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120514065115.6FD231A205B@async.async.caltech.edu>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
Message-ID: <1336982655.1500.9.camel@boromir.m3w.org>

Depends on how major are changes from .6 to .7. At my Fedora box package
version is 1.0.8 and library is libXaw.so.7. Looks like it is minor
change (source/package wise) but number was bumped (probably after
XFree86 schism).


As for binary compatibility Jay mentioned... I don't think many Windows
98 programs will work without hickups on Windows 8. YMMV :).

Under Linux minor version number changes are expected to be binary
compatible. Major version number changes indicate API changes or
additions. Package using libXaw.so.6 is probably revised ages ago. Error
you are getting now says, to me, "Time to check source/API changes".

Belief in eternally invariant API anywhere is naive.

On Sun, 2012-05-13 at 23:51 -0700, Mika Nystrom wrote:
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?

As long as API is not changed, link time will show would it work or not.
Execution is ultimate test :).

-- 
Dragi?a Duri? <dragisha at m3w.org>



From dabenavidesd at yahoo.es  Mon May 14 14:24:47 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 May 2012 13:24:47 +0100 (BST)
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
Message-ID: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler, but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
Thanks in advance

?

--- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] libXaw.so.6 again
Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de mayo, 2012 02:20




Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
I find this very surprising, crazy, disappointing, but apparently true.
We must distribute source to achieve the usual expected portability.
?C source at that, to achieve the usual expected buildability.
Or maybe I'm confused.
The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.


?- Jay


> To: dragisha at m3w.org
> Date: Sun, 13 May 2012 23:51:15 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] libXaw.so.6 again
> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/81764fc1/attachment.html>

From microcode at zoho.com  Mon May 14 14:41:02 2012
From: microcode at zoho.com (microcode at zoho.com)
Date: Mon, 14 May 2012 12:41:02 +0000
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
	<1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <575839211-1336999209-cardhu_decombobulator_blackberry.rim.net-1028218551-@b1.c1.bise3.blackberry>

I think this could be solved by static linking mostly, but there could still be problems with libc/glibc as I found out with FPC recently. Surely somebody who knows UNIX/Linux ought to be able to figure a way around this. 

-----Original Message-----
From: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
Date: Mon, 14 May 2012 13:24:47 
To: Mika Nystrom<mika at async.caltech.edu>; <dragisha at m3w.org>; Jay K<jay.krell at cornell.edu>
Cc: m3devel<m3devel at elegosoft.com>
Subject: Re: [M3devel] libXaw.so.6 again

Hi all:
'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler, but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
Thanks in advance

?

--- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] libXaw.so.6 again
Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de mayo, 2012 02:20




Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
I find this very surprising, crazy, disappointing, but apparently true.
We must distribute source to achieve the usual expected portability.
?C source at that, to achieve the usual expected buildability.
Or maybe I'm confused.
The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.


?- Jay


> To: dragisha at m3w.org
> Date: Sun, 13 May 2012 23:51:15 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] libXaw.so.6 again
> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?
 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/2ab44f33/attachment.html>

From dabenavidesd at yahoo.es  Mon May 14 15:37:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 May 2012 14:37:24 +0100 (BST)
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <575839211-1336999209-cardhu_decombobulator_blackberry.rim.net-1028218551-@b1.c1.bise3.blackberry>
Message-ID: <1337002644.8248.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
respect of this:
http://compilers.iecc.com/comparch/article/94-11-053

The quest is to have a machine-independent compiler at the end but I think nobody cares that, and with industry making ever user machine C dependent it just calls for breaking the rules and make an improvement here.
Dec had an industrial compiler optimization system for all languages but I don't know if Modula-3 was ported to that as well, assuming they never used it for years just says how bad the computers evolved in C-ism, as DEC tried to imitate:
http://compilers.iecc.com/comparch/article/92-06-037

I think it didn't achieved it as far as It appears. 
Thanks in advance

--- El lun, 14/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

De: microcode at zoho.com <microcode at zoho.com>
Asunto: Re: [M3devel] libXaw.so.6 again
Para: m3devel at elegosoft.com
Fecha: lunes, 14 de mayo, 2012 07:41

I think this could be solved by static linking mostly, but there could still be problems with libc/glibc as I found out with FPC recently. Surely somebody who knows UNIX/Linux ought to be able to figure a way around this. 
From:  "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
Date: Mon, 14 May 2012 13:24:47 +0100 (BST)To: Mika Nystrom<mika at async.caltech.edu>; <dragisha at m3w.org>; Jay K<jay.krell at cornell.edu>Cc: m3devel<m3devel at elegosoft.com>Subject: Re: [M3devel] libXaw.so.6 again
Hi all:
'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler,
 but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
Thanks in advance

?

--- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] libXaw.so.6 again
Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de mayo, 2012 02:20




Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
I find this very surprising, crazy, disappointing, but apparently true.
We must distribute source to achieve the usual expected portability.
?C source at that, to achieve the usual expected buildability.
Or maybe I'm confused.
The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.


?- Jay


> To: dragisha at m3w.org
> Date: Sun, 13 May 2012 23:51:15 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] libXaw.so.6 again
> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?
 		
 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/f1edbad1/attachment.html>

From hendrik at topoi.pooq.com  Mon May 14 17:44:41 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 14 May 2012 11:44:41 -0400
Subject: [M3devel] libXaw.so.7
In-Reply-To: <COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
	<COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
Message-ID: <20120514154441.GA26098@topoi.pooq.com>

On Mon, May 14, 2012 at 07:20:08AM +0000, Jay K wrote:
> 
> Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
> I find this very surprising, crazy, disappointing, but apparently true.
> We must distribute source to achieve the usual expected portability.
>  C source at that, to achieve the usual expected buildability.
> Or maybe I'm confused.
> The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.

Here's what aptitude has to say about libXaw7:

libXaW7 provides the second versin of XaW, the Athena Widgets toolkit, which is
largely used by legacy X applications.  This version is the most common
version, ass version 6 is considered deprecated, and vesion 8, which adds
Xprint support, is unsupported and not widely used. In geneeral use of a more
modern toolkit such as GTK+ is recommended

Now I'm not going to suggest that we abolish all use of libXaw in favour of 
GTK+.  But whatever other systems it runs on, the deb package for Modula 
3 does not work on any current version of Debian (neither  stable, 
testing, nor sid).  A new .deb needs to be made, if ti is to work 
properly on debian (surely the canonical userr of .deb packages)

I might add that if modula3 were still part of Debian, it should have 
had a dependdency on libXaw6, and that might have sufficed either to 
keep libXaw6 alive as a legacy package in additino to libXaw7, or to 
alert the maintainer that the Modula3 package needed to be updated 
somewhere early in the Debian deployment process -- certainly long 
before the advend of squeeze. 

But getting modula 3 back into Debian is another project, and possibly a 
big one.  Even the current modula 3 debs, though adequate for my 
purposes if updatad, are not nearly adequate for distribution via Debian 
because of matters like the file system standard and the like.

Now I'm guessing the code that is run to create the .deb files is still
around somewhere.  Are there clear instructions how to go about 
finding it and using it to make a debian source package and debian 
binary packages?

-- hendrik



From jay.krell at cornell.edu  Mon May 14 22:00:20 2012
From: jay.krell at cornell.edu (Jay)
Date: Mon, 14 May 2012 13:00:20 -0700
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <2FEF5A4D-F529-4F18-8927-7F99EAC92D4D@gmail.com>

The age of the toolchain is not the problem. And gcc has little/nothing to do with it (unless you worry about C++ exceptionhandling/RTTI ABI) Linux/OpenBSD/FreeBSD/NetBSD seemingly don't try to retain binary compatibility. I don't know if security fixes are too blame but I doubt it.


Shipping assembly source would help -- where the breakage is only the .so name. I want to ship C source.

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 14, 2012, at 5:24 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> 'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
> Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler, but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
> Thanks in advance
> 
>  
> 
> --- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] libXaw.so.6 again
> Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 14 de mayo, 2012 02:20
> 
> Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
> I find this very surprising, crazy, disappointing, but apparently true.
> We must distribute source to achieve the usual expected portability.
>  C source at that, to achieve the usual expected buildability.
> Or maybe I'm confused.
> The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.
> 
> 
>  - Jay
> 
> 
> > To: dragisha at m3w.org
> > Date: Sun, 13 May 2012 23:51:15 -0700
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] libXaw.so.6 again
> > 
> > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> > ...
> > >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> > ...
> > 
> > "Not guaranteed to work" but almost always does, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/00c540b1/attachment.html>

From hendrik at topoi.pooq.com  Tue May 15 00:09:33 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 14 May 2012 18:09:33 -0400
Subject: [M3devel] Where is libXaw6 even used?
In-Reply-To: <20120514154441.GA26098@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
	<COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
	<20120514154441.GA26098@topoi.pooq.com>
Message-ID: <20120514220933.GA31311@topoi.pooq.com>

On Mon, May 14, 2012 at 11:44:41AM -0400, Hendrik Boom wrote:

I've been grepping through the src directories in the ...src-all-... archive, and the only mentions of Xaw I've found is in the Tetris game, and in a file called m3-comm/sharedobjgen/test/trackerpos/src/PATHTracker, whicch seems to be a  list of interface names and directory paths,
some with '@' signs.

What needs to be changed so it will find libXaw.so.7?  Or if I just need 
to recompile something so that it can fine libXaw.so.7, what do I need 
to recompile?

-- hendrik



From jay.krell at cornell.edu  Tue May 15 00:52:55 2012
From: jay.krell at cornell.edu (Jay)
Date: Mon, 14 May 2012 15:52:55 -0700
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <2FEF5A4D-F529-4F18-8927-7F99EAC92D4D@gmail.com>
References: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<2FEF5A4D-F529-4F18-8927-7F99EAC92D4D@gmail.com>
Message-ID: <6C826E60-81C2-4D63-859A-5BC799F9B80E@gmail.com>

Clarification: shipping assembly source would include, in today's structuring, shipping a little C too. Heck, we could ship .o files and some .c, & that would fix the entire binary compatibility problem for us (assembly or .o). Playing a little fast&loose wrt Xlib.h but probably ok.


My plan to ship C would probably ship strange low level C that doesn't improve things wrt binary compatibility. Unless someone has a scheme in mind for a backend that generates #include sys/types & such?


There is a point to ship C, just not likely relevant to binary compatibility.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 14, 2012, at 1:00 PM, Jay <jay.krell at cornell.edu> wrote:

> The age of the toolchain is not the problem. And gcc has little/nothing to do with it (unless you worry about C++ exceptionhandling/RTTI ABI) Linux/OpenBSD/FreeBSD/NetBSD seemingly don't try to retain binary compatibility. I don't know if security fixes are too blame but I doubt it.
> 
> 
> Shipping assembly source would help -- where the breakage is only the .so name. I want to ship C source.
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On May 14, 2012, at 5:24 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:
> 
>> Hi all:
>> 'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
>> Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler, but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
>> Thanks in advance
>> 
>>  
>> 
>> --- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:
>> 
>> De: Jay K <jay.krell at cornell.edu>
>> Asunto: Re: [M3devel] libXaw.so.6 again
>> Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
>> CC: "m3devel" <m3devel at elegosoft.com>
>> Fecha: lunes, 14 de mayo, 2012 02:20
>> 
>> Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
>> I find this very surprising, crazy, disappointing, but apparently true.
>> We must distribute source to achieve the usual expected portability.
>>  C source at that, to achieve the usual expected buildability.
>> Or maybe I'm confused.
>> The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.
>> 
>> 
>>  - Jay
>> 
>> 
>> > To: dragisha at m3w.org
>> > Date: Sun, 13 May 2012 23:51:15 -0700
>> > From: mika at async.caltech.edu
>> > CC: m3devel at elegosoft.com
>> > Subject: Re: [M3devel] libXaw.so.6 again
>> > 
>> > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
>> > ...
>> > >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
>> > ...
>> > 
>> > "Not guaranteed to work" but almost always does, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/1a8fa988/attachment.html>

From dragisha at m3w.org  Tue May 15 01:58:19 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 15 May 2012 01:58:19 +0200
Subject: [M3devel] Where is libXaw6 even used?
In-Reply-To: <20120514220933.GA31311@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
	<COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
	<20120514154441.GA26098@topoi.pooq.com>
	<20120514220933.GA31311@topoi.pooq.com>
Message-ID: <63183557-3F71-445A-B860-BDEE84A250F3@m3w.org>

Maybe you just need to link libXaw.so.7 on your system to libXaw.so

cm3 handlig of system shared libs? :)

On May 15, 2012, at 12:09 AM, Hendrik Boom wrote:

> On Mon, May 14, 2012 at 11:44:41AM -0400, Hendrik Boom wrote:
> 
> I've been grepping through the src directories in the ...src-all-... archive, and the only mentions of Xaw I've found is in the Tetris game, and in a file called m3-comm/sharedobjgen/test/trackerpos/src/PATHTracker, whicch seems to be a  list of interface names and directory paths,
> some with '@' signs.
> 
> What needs to be changed so it will find libXaw.so.7?  Or if I just need 
> to recompile something so that it can fine libXaw.so.7, what do I need 
> to recompile?
> 
> -- hendrik
> 



From hendrik at topoi.pooq.com  Tue May 15 05:14:37 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 14 May 2012 23:14:37 -0400
Subject: [M3devel] libXaw
In-Reply-To: <63183557-3F71-445A-B860-BDEE84A250F3@m3w.org>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
	<COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
	<20120514154441.GA26098@topoi.pooq.com>
	<20120514220933.GA31311@topoi.pooq.com>
	<63183557-3F71-445A-B860-BDEE84A250F3@m3w.org>
Message-ID: <20120515031437.GA1025@topoi.pooq.com>

On Tue, May 15, 2012 at 01:58:19AM +0200, Dragi?a Duri? wrote:
> Maybe you just need to link libXaw.so.7 on your system to libXaw.so

You mean like this?

hendrik at notlookedfor:/farhome/hendrik/cm3/src-all$ ls /usr/lib/i386-linux-gnu/*Xaw* -l
-rw-r--r-- 1 root root 540512 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw7.a
lrwxrwxrwx 1 root root     16 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw7.so -> libXaw7.so.7.0.0
lrwxrwxrwx 1 root root     16 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw7.so.7 -> libXaw7.so.7.0.0
-rw-r--r-- 1 root root 428900 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw7.so.7.0.0
lrwxrwxrwx 1 root root     10 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw.so -> libXaw7.so
lrwxrwxrwx 1 root root     12 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw.so.7 -> libXaw7.so.7
hendrik at notlookedfor:/farhome/hendrik/cm3/src-all$ 

Already done by the system.  The compiler is quite clear that it wants
libXaw.so.6.

The reference to libXaw has to occur in the code base, no? 

Presumably I have to recompile something that refers to Xaw, 
so it will find these links while building one of the m3 libraries 
(and maybe everything that depends on it)and end up with a dependency 
on libXaw7 in the binary.

But I can't find it.

-- hendrik


From hendrik at topoi.pooq.com  Tue May 15 17:12:18 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Tue, 15 May 2012 11:12:18 -0400
Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
In-Reply-To: <20120513174747.GA25729@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
Message-ID: <20120515151217.GA23964@topoi.pooq.com>

I got it to recognise libXaw.se.7.

I downloaded and untarred the src-all archive.

I used cm3 to compile and ship several libraries:

 m3-ui/formsvbt
 m3-ui/videovbt
 m3-ui/vbtkit
 m3-ui/ui
 m3-ui/X11R4

Each one was simple, like
   cd formsvbt
   cm3
   cm3 -ship

I identified the libraries that needed recompilation fron the 
compilation error messages I got whein compiling the program I was 
originally trying to work on.  A message like:

/usr/bin/ld: warning: libXaw.so.6, needed by /usr/local/cm3/pkg/vbtkit/AMD64_LINUX/libm3vbtkit.so, not found (try using -rpath or -rpath-link)

indicated recompiling  m3-ui/vbtkit (I had to look around in src-all too 
figure out the m3-ui part).

At least these libraries work now.  So my immediate objective is 
accomplished.

But the job is  not done.  This is simply too much to inflict on an 
inexperienced beginner.  He'd pretty well have to desperately want to 
use Modula 3 to go to all this trouble AND have the advice of an 
experienced Modula 3 user (such as me, and I had trouble!) to get this 
far.

The next steps, which I *will* need help with if I am to do them, are:

figure out which other libraries have similar obsolete dependencies.

recompile them

Prepare new distribution archives and a new .deb file, suitably 
annotated as to which Debian release they work with.

The .deb is surely the easiest way for a beginner to install Modula 3 on 
Debian.

Make the .deb spread its contents over the file system, as required for 
it to be accepted into Debian again.  Modula 3 has been absent from 
Debian for far too long.

-- hendrik


From dabenavidesd at yahoo.es  Tue May 15 18:37:08 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 15 May 2012 17:37:08 +0100 (BST)
Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
In-Reply-To: <20120515151217.GA23964@topoi.pooq.com>
Message-ID: <1337099828.15747.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I agree, but wherever they depended on must be configured by hand >= so.7 or around base versions >= so.6, so maybe just create a link command cm3 -relink to use a grater version, sometimes I have seen linker warnings at compile time so kind of show dependencies linker if possible at compile time should help.
Win32 older version m3loader go option help says ' CmdFunc { "go", "", "Relink any new modules, then run", go } }; '
The all program module by module, so this could be better than that, but we must redistribute (to the extent possible) pre-compiled versions of major or minor sub-versions. Besides work in the experimental version for UNIX.
Thanks in advance 

--- El mar, 15/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] Success with  libXaw.so.7, but more help needed.
> Para: m3devel at elegosoft.com
> Fecha: martes, 15 de mayo, 2012 10:12
> I got it to recognise libXaw.se.7.
> 
> I downloaded and untarred the src-all archive.
> 
> I used cm3 to compile and ship several libraries:
> 
>  m3-ui/formsvbt
>  m3-ui/videovbt
>  m3-ui/vbtkit
>  m3-ui/ui
>  m3-ui/X11R4
> 
> Each one was simple, like
>    cd formsvbt
>    cm3
>    cm3 -ship
> 
> I identified the libraries that needed recompilation fron
> the 
> compilation error messages I got whein compiling the program
> I was 
> originally trying to work on.  A message like:
> 
> /usr/bin/ld: warning: libXaw.so.6, needed by
> /usr/local/cm3/pkg/vbtkit/AMD64_LINUX/libm3vbtkit.so, not
> found (try using -rpath or -rpath-link)
> 
> indicated recompiling  m3-ui/vbtkit (I had to look
> around in src-all too 
> figure out the m3-ui part).
> 
> At least these libraries work now.  So my immediate
> objective is 
> accomplished.
> 
> But the job is  not done.  This is simply too much
> to inflict on an 
> inexperienced beginner.  He'd pretty well have to
> desperately want to 
> use Modula 3 to go to all this trouble AND have the advice
> of an 
> experienced Modula 3 user (such as me, and I had trouble!)
> to get this 
> far.
> 
> The next steps, which I *will* need help with if I am to do
> them, are:
> 
> figure out which other libraries have similar obsolete
> dependencies.
> 
> recompile them
> 
> Prepare new distribution archives and a new .deb file,
> suitably 
> annotated as to which Debian release they work with.
> 
> The .deb is surely the easiest way for a beginner to install
> Modula 3 on 
> Debian.
> 
> Make the .deb spread its contents over the file system, as
> required for 
> it to be accepted into Debian again.  Modula 3 has been
> absent from 
> Debian for far too long.
> 
> -- hendrik
> 


From jay.krell at cornell.edu  Wed May 16 00:33:12 2012
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 15 May 2012 22:33:12 +0000
Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
In-Reply-To: <20120515151217.GA23964@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>
Message-ID: <COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>


You might as well just use something in scripts to rebuild the entire system.It isn't so difficult nor takes very long.     Get a working cm3 on any system.      cd scripts/python      ./boot1.py <target-such-as-I386_LINUX>      That will produce a "bootstrap" archive.    Copy it to the "new" system.      Extract it.      Cd into it.      Look at the top of Makefile and see if it seems reasonable (we should use autoconf here).    run make.     That should give you a working cm3 for the new system.      Put that on path, e.g.:       su        rm -rf /usr/local/cm3       mkdir -p /usr/local/cm3/bin        cp cm3 /usr/local/cm3/bin        exit         PATH=/usr/local/cm3/bin:$PATH     cd to scripts/python in the source tree on the new system.    Then run ./boot2.sh       Then ./make-dist.py.    That should give you the entire system newly built, and a .deb.  If you already have a working cm3 on the system you want to run it on  cd scripts/python   ./upgrade.py    ./make-dist.py     I'd really like to get to the point of:  extract    ./configure    make    make install  or make deb   To make this work how people really want, we have to have a C-generating backend.Or else provide binary packages for "every" system, which isn't viable.   If Linux distributions took binary compatibility seriously, we wouldn't have this problem.They seem to encourage/require rebuilds for every revision.But surely this is not true, as there exist some closed source products like Adobe Acrobat?There is no such problem on Windows, nor I suspect Solaris, nor hypothetically on Irix, AIX, VMS, HP-UX, Tru64, etc.   - Jay
> Date: Tue, 15 May 2012 11:12:18 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
> 
> I got it to recognise libXaw.se.7.
> 
> I downloaded and untarred the src-all archive.
> 
> I used cm3 to compile and ship several libraries:
> 
>  m3-ui/formsvbt
>  m3-ui/videovbt
>  m3-ui/vbtkit
>  m3-ui/ui
>  m3-ui/X11R4
> 
> Each one was simple, like
>    cd formsvbt
>    cm3
>    cm3 -ship
> 
> I identified the libraries that needed recompilation fron the 
> compilation error messages I got whein compiling the program I was 
> originally trying to work on.  A message like:
> 
> /usr/bin/ld: warning: libXaw.so.6, needed by /usr/local/cm3/pkg/vbtkit/AMD64_LINUX/libm3vbtkit.so, not found (try using -rpath or -rpath-link)
> 
> indicated recompiling  m3-ui/vbtkit (I had to look around in src-all too 
> figure out the m3-ui part).
> 
> At least these libraries work now.  So my immediate objective is 
> accomplished.
> 
> But the job is  not done.  This is simply too much to inflict on an 
> inexperienced beginner.  He'd pretty well have to desperately want to 
> use Modula 3 to go to all this trouble AND have the advice of an 
> experienced Modula 3 user (such as me, and I had trouble!) to get this 
> far.
> 
> The next steps, which I *will* need help with if I am to do them, are:
> 
> figure out which other libraries have similar obsolete dependencies.
> 
> recompile them
> 
> Prepare new distribution archives and a new .deb file, suitably 
> annotated as to which Debian release they work with.
> 
> The .deb is surely the easiest way for a beginner to install Modula 3 on 
> Debian.
> 
> Make the .deb spread its contents over the file system, as required for 
> it to be accepted into Debian again.  Modula 3 has been absent from 
> Debian for far too long.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120515/872c95c3/attachment.html>

From hendrik at topoi.pooq.com  Wed May 16 16:56:53 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 10:56:53 -0400
Subject: [M3devel] Building packages
In-Reply-To: <COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
Message-ID: <20120516145653.GA19959@topoi.pooq.com>

On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote, and hendrik reformatted:
> 
> You might as well just use something in scripts to rebuild the entire 
> system.It isn't so difficult nor takes very long.
>
> Get a working cm3 on any system.
>      cd scripts/python
>      ./boot1.py <target-such-as-I386_LINUX>

So any cm3 system is capable of creating a bootstrap archive for any other cm3 system

> That will produce a "bootstrap" archive.  Copy it to the "new" system.
> Extract it.
> Cd into it.
> Look at the top of Makefile and see if it seems reasonable (we 
> should use autoconf here).
> run make.
> That should give you a working cm3 for the new system.

just the compiler (and what it needs to work), presumably.

> Put that on path, e.g.:
>      su
>      rm -rf /usr/local/cm3

clearing out any old cm3 system completely

>      mkdir -p /usr/local/cm3/bin
>      cp cm3 /usr/local/cm3/bin

And putting the noew one where it can be executed.

>      exit
>      PATH=/usr/local/cm3/bin:$PATH

And this then builds everything, and makes a .deb

> cd to scripts/python in the source tree on the new system.
> Then run ./boot2.sh
> Then ./make-dist.py.
> That should give you the entire system newly built, and a .deb.

I recal there are a few place in the Modula 3 build p[rocess where it 
requires other resources to already exit (the data base stuff is one I 
recall).  If they are not available, will the process fail, or will if 
just build an incomplete .deb?

>
>  If you already have a working cm3 on the system you want to run it on

Which is what I've got on my two machines, so this is what I'll be 
trying.

>     cd scripts/python
>     ./upgrade.py

this script recompiles everything from the complete source tree?  Does 
it ship it?  Or place it somewhere else on the system?  Is it important 
for the already working cm3 compiler to be the same version as the one 
in the source tree being packaged?  And is there also a source package 
built?  Because the source package is what's needed for uploading to 
Debian.

>     ./make-dist.py

And this packages it from the shipped location?

> I'd really like to get to the point of:
>  extract
>    ./configure
>    make
>    make install  or make deb
>
> To make this work how people really want, we have to have a 
> C-generating backend.Or else provide binary packages for "every" 
> system, which isn't viable.  If Linux distributions took binary 
> compatibility seriously, we wouldn't have this problem.

That is. apparently, deliberate policy.  Linux aims for source-code 
compatibility.

Even the kernel calls aren't really guaranteed to stay the same, but 
there's a run-time library that's supposed to be used to call them.  And 
that's Unix policy, from way back in the 70's.

Binary-based distributions routinely compile the entire Linux system 
for each major release.  They do it package by package, but they do it.

I wonder how gcc does its bootstrap.  Presumably it's a package thet 
build-depends on itself, or something like that.

> They seem to 
> encourage/require rebuilds for every revision.But surely this is not 
> true, as there exist some closed source products like Adobe 
> Acrobat?

Such products try to have very few library dependencies.

> There is no such problem on Windows, nor I suspect Solaris, 
> nor hypothetically on Irix, AIX, VMS, HP-UX, Tru64, etc.

And that's been one of the major problems Microsoft has had with 
developing Windows.  When things need to change, you get legacy 
compatibility hacks like making the details of the storage 
allocation system calls depend on the name of the application 
being executed.

It also enables and encourages third-party developers to distribute 
application in binary only, making source code inavailable.  And that in 
turn makes it necessary to remain long-term compatible with ancient 
bugs.

-- hendrik


From hendrik at topoi.pooq.com  Wed May 16 17:26:35 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 11:26:35 -0400
Subject: [M3devel] Building packages
In-Reply-To: <20120516145653.GA19959@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
Message-ID: <20120516152635.GA20806@topoi.pooq.com>

On Wed, May 16, 2012 at 10:56:53AM -0400, Hendrik Boom wrote:
> On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote, and hendrik reformatted:

So this is what I did:
> 
> >
> >  If you already have a working cm3 on the system you want to run it on
> 
> Which is what I've got on my two machines, so this is what I'll be 
> trying.
> 
> >     cd scripts/python
> >     ./upgrade.py

It ran for a while, conpiling some Modula 3 stuff and apparently a lot 
of C code (this part seemed to use autoconf tools), and then stopped 
with

cd . && cd libcpp && make  CFLAGS="-g -O2"   MAKE=make  AUTOCONF=: 
AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a 
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
/bin/sh: line 0: cd: libcpp: No such file or directory
"/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile", line 312: 
quake runtime error: exit 1: cd . && cd libcpp && make  CFLAGS="-g -O2"   
MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: 
libcpp.a | tee -a 
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log

--procedure--  -line-  -file---
exec               --  <builtin>
m3cc_Run          312  
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
include_dir       586  
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
                    8  
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/m3make.args

Fatal Error: package build failed
 *** execution of [<function _BuildGlobalFunction at 0x7f298eea9050>, 
<function _ShipFunction at 0x7f298eea90c8>] failed ***
hendrik at april:~/cm3/src-all/scripts/python$ 


Did I start upgrade.py with an incomplete cm3 system?  Plainly I should 
have started it using script so I'd have a complete log.

-- hendrik


From hendrik at topoi.pooq.com  Wed May 16 18:59:27 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 12:59:27 -0400
Subject: [M3devel] problem building packages -- preliminary analysis.
In-Reply-To: <20120516152635.GA20806@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
Message-ID: <20120516165926.GA3955@topoi.pooq.com>

On Wed, May 16, 2012 at 11:26:35AM -0400, Hendrik Boom wrote:
> On Wed, May 16, 2012 at 10:56:53AM -0400, Hendrik Boom wrote:
> > On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote, and hendrik reformatted:
> 
> So this is what I did:
> > 
> > >
> > >  If you already have a working cm3 on the system you want to run it on
> > 
> > Which is what I've got on my two machines, so this is what I'll be 
> > trying.
> > 
> > >     cd scripts/python
> > >     ./upgrade.py
> 
> It ran for a while, conpiling some Modula 3 stuff and apparently a lot 
> of C code (this part seemed to use autoconf tools), and then stopped 
> with
> 
> cd . && cd libcpp && make  CFLAGS="-g -O2"   MAKE=make  AUTOCONF=: 
> AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a 
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
> /bin/sh: line 0: cd: libcpp: No such file or directory
> "/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile", line 312: 
> quake runtime error: exit 1: cd . && cd libcpp && make  CFLAGS="-g -O2"   
> MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: 
> libcpp.a | tee -a 
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
> 
> --procedure--  -line-  -file---
> exec               --  <builtin>
> m3cc_Run          312  
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
> include_dir       586  
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
>                     8  
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/m3make.args
> 
> Fatal Error: package build failed
>  *** execution of [<function _BuildGlobalFunction at 0x7f298eea9050>, 
> <function _ShipFunction at 0x7f298eea90c8>] failed ***
> hendrik at april:~/cm3/src-all/scripts/python$ 

Looking at the python code in src-all/m3-sys/m3cc/src/m3makefile, I 
find line 586:

m3cc_Run (["cd " & build_dir & " && cd libcpp && " & M3CC_MAKE & " 
libcpp.a | tee -a " & Log])

Now seeng what appears to be the actual command line in the error 
message: 

cd . && cd libcpp && make  CFLAGS="-g -O2" MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a

it appears that the variable bild_dir has the value "."

At some time, "." probably was the build directory.  But at the moment 
we execute this command, I suspect the build dir is actually 
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/

since a recent message was 

make[1]: Leaving directory 
`/farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/libdecnumber'

There is no libcpp directory there.  locate tells me there are libcpp 
directories at
src-all/m3-sys/m3cc/gcc-apple/libcpp

and

src-all/m3-sys/m3cc/gcc/libcpp

and that's about it.  (yes, I reran locatedb to make sure it was up to 
date).

Could it be that the build_dir variable should contain an absolute 
rather than a relative path?

Or should I rerun everything using scipt to generate a huge log?

-- hendrik


From jay.krell at cornell.edu  Wed May 16 22:24:52 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 20:24:52 +0000
Subject: [M3devel] problem building packages -- preliminary analysis.
In-Reply-To: <20120516165926.GA3955@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>
Message-ID: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>


Your CVS tree is maybe incomplete or out of date? Try this:
   cd m3-sys   
   rm -rf m3cc  
   cvs -z3 upd -dAP m3cc   
   cd m3cc   
   cm3  
 

Or just checkout a whole new tree.


Yes, there is a lot of C code, that uses autoconf -- the gcc backend.


 - Jay

> Date: Wed, 16 May 2012 12:59:27 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] problem building packages -- preliminary analysis.
> 
> On Wed, May 16, 2012 at 11:26:35AM -0400, Hendrik Boom wrote:
> > On Wed, May 16, 2012 at 10:56:53AM -0400, Hendrik Boom wrote:
> > > On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote, and hendrik reformatted:
> > 
> > So this is what I did:
> > > 
> > > >
> > > >  If you already have a working cm3 on the system you want to run it on
> > > 
> > > Which is what I've got on my two machines, so this is what I'll be 
> > > trying.
> > > 
> > > >     cd scripts/python
> > > >     ./upgrade.py
> > 
> > It ran for a while, conpiling some Modula 3 stuff and apparently a lot 
> > of C code (this part seemed to use autoconf tools), and then stopped 
> > with
> > 
> > cd . && cd libcpp && make  CFLAGS="-g -O2"   MAKE=make  AUTOCONF=: 
> > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a 
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
> > /bin/sh: line 0: cd: libcpp: No such file or directory
> > "/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile", line 312: 
> > quake runtime error: exit 1: cd . && cd libcpp && make  CFLAGS="-g -O2"   
> > MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: 
> > libcpp.a | tee -a 
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
> > 
> > --procedure--  -line-  -file---
> > exec               --  <builtin>
> > m3cc_Run          312  
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
> > include_dir       586  
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
> >                     8  
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/m3make.args
> > 
> > Fatal Error: package build failed
> >  *** execution of [<function _BuildGlobalFunction at 0x7f298eea9050>, 
> > <function _ShipFunction at 0x7f298eea90c8>] failed ***
> > hendrik at april:~/cm3/src-all/scripts/python$ 
> 
> Looking at the python code in src-all/m3-sys/m3cc/src/m3makefile, I 
> find line 586:
> 
> m3cc_Run (["cd " & build_dir & " && cd libcpp && " & M3CC_MAKE & " 
> libcpp.a | tee -a " & Log])
> 
> Now seeng what appears to be the actual command line in the error 
> message: 
> 
> cd . && cd libcpp && make  CFLAGS="-g -O2" MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a
> 
> it appears that the variable bild_dir has the value "."
> 
> At some time, "." probably was the build directory.  But at the moment 
> we execute this command, I suspect the build dir is actually 
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/
> 
> since a recent message was 
> 
> make[1]: Leaving directory 
> `/farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/libdecnumber'
> 
> There is no libcpp directory there.  locate tells me there are libcpp 
> directories at
> src-all/m3-sys/m3cc/gcc-apple/libcpp
> 
> and
> 
> src-all/m3-sys/m3cc/gcc/libcpp
> 
> and that's about it.  (yes, I reran locatedb to make sure it was up to 
> date).
> 
> Could it be that the build_dir variable should contain an absolute 
> rather than a relative path?
> 
> Or should I rerun everything using scipt to generate a huge log?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/7dd134ed/attachment.html>

From jay.krell at cornell.edu  Wed May 16 22:40:51 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 20:40:51 +0000
Subject: [M3devel] Building packages
In-Reply-To: <20120516145653.GA19959@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>
Message-ID: <COL101-W2557FFC4969C25FB708C06E6180@phx.gbl>


[inline, maybe to myself in places out of ambiguity]


> So any cm3 system is capable of creating a bootstrap archive for any other cm3 system


 Yes. Except you need Cygwin on NT to cross to non-NT.


> > That should give you a working cm3 for the new system.
> 
> just the compiler (and what it needs to work), presumably.


Yes. But not the backend. Ok.
That gets built later on the target system.

 
  > >      rm -rf /usr/local/cm3 
  >  
  > clearing out any old cm3 system completely 


 Correct. Or pick another location. 


> >      mkdir -p /usr/local/cm3/bin
> >      cp cm3 /usr/local/cm3/bin
> 
> And putting the noew one where it can be executed.


Correct. Or pick another location.


> >      exit
> >      PATH=/usr/local/cm3/bin:$PATH
> 
> And this then builds everything, and makes a .deb
> 
> > cd to scripts/python in the source tree on the new system.
> > Then run ./boot2.sh
> > Then ./make-dist.py.
> > That should give you the entire system newly built, and a .deb.
> 
> I recal there are a few place in the Modula 3 build p[rocess where it 
> requires other resources to already exit (the data base stuff is one I 
> recall).  If they are not available, will the process fail, or will if 
> just build an incomplete .deb?



Good point. In the scripts directory, you can always safely remove PKGSDB
and it will be recreated. It goes out of date occasionally. I've been meaning
to make that automatic by putting a version and/or date in it or such.


> >
> >  If you already have a working cm3 on the system you want to run it on
> 
> Which is what I've got on my two machines, so this is what I'll be 
> trying.
> 
> >     cd scripts/python
> >     ./upgrade.py
> 
> this script recompiles everything from the complete source tree?


I think so. It might only build the compiler.
There is ./do-cm3-all.py if unsure.


> Does it ship it?


Yes

.
 >  Is it important  for the already working cm3 compiler to be the same version as the one 
 > in the source tree being packaged?


 Definitely not. This is how we upgrade from old to new. Or possibly new to told.


 >  And is there also a source package built?


 No. It would be C code anyway, so not source from most people's point of view.

 
> Because the source package is what's needed for uploading to 
> Debian.


They wouldn't like it anyway.
 What do they do with stuff written in Haskell, C#, etc.?


> 
> >     ./make-dist.py
> 
> And this packages it from the shipped location?


I think it builds it from scratch. Read it?


> That is. apparently, deliberate policy.  Linux aims for source-code 
> compatibility.


Very lame.


> I wonder how gcc does its bootstrap.


Right, relevant question.


> Such products try to have very few library dependencies.


As do we..but we do have optional GUI..


> And that's been one of the major problems Microsoft has had with 


It is not that difficult and it is worth it.
The Linux/BSD folks break things seemingly gratuitously.


> compatibility hacks like making the details of the storage 
> allocation system calls depend on the name of the application 
> being executed.


It doesn't work quite that way.
There is an appcompat database that checks things like name and version and yes changes the heap allocator.
Just recompiling the relevant buggy third party code wouldn't make it work either.
There is code out there that uses freed memory or uses memory past the allocation or double frees (same as using freed memory)
Heap implementations are always necessarily at least somewhat lenient, and then once you
are lenient a certain amount or in a certain way, you are stuck.


This isn't source compatibility. It is overly precise behavioral compatibility the likes of which very few
programmers would advocate, but which is necessary in a system with so many applications.


There are security aspects too, like if the stack should be executable.
Again though, this is precise behavior compatibility. Just recompiling the code wouldn't fix it.


> It also enables and encourages third-party developers to distribute 
> application in binary only, making source code inavailable.  And that in 
> turn makes it necessary to remain long-term compatible with ancient 
> bugs.


The bugs are in the third party code and you'd have to change a lot of third party source
to keep it working..


The trade off is a more active (at least historically) third party software market.


Anyway, please try out the various scripts until you get it working.
Then we can document it and make it better.
Perhaps the goal should ship only bootstrap packages for the next release?
Make everyone here experience them and approve them?
Autoconf-ize them a bit?
Or verify they work well enough and worry about it if they ever stop working?
(Autoconf is sometimes overkill.)



It'd be nice if the assembly code wasn't e.g. Linux-specific but only x86-specific.
We could maybe blow up the jmpbuf size per-architectures instead of per architecture+kernel?
Maybe.




 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/6eb0b9b9/attachment.html>

From jay.krell at cornell.edu  Wed May 16 22:55:20 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 20:55:20 +0000
Subject: [M3devel] distribution format?
Message-ID: <COL101-W2222C4AA8CB67F3F46D9E2E6180@phx.gbl>


What distribution format or formats should we aim for?


One thing to consider, in our various preferences for a source/assembly distribution,
is that there is the large gcc backend.


How many people, even if they build stuff from source, build gcc?
How many of those attempts are deemed onerously slow? Or fail and onerous to debug? etc.
And people give up?
Consider that OpenBSD discourages its users from building from source.
Instead they provide binary packages for "everything".


Yes yes a C-generating backend would fix that and merely require the user have gcc or such.
Is the middle step worthwhile?


Is a gcc plugin viable at this point?
I'm not too interested in that really.


Maybe the answer is to "get into" the distributions, into the package systems.
Put rebuild work on the distributions?
They do handle gcc already, somehow, e.g. via a cross into a new/empty file system, presumably.
Can anyone else research that?


Thank you,
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/b220efce/attachment.html>

From hendrik at topoi.pooq.com  Wed May 16 23:07:06 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 17:07:06 -0400
Subject: [M3devel] Package dependencies.
In-Reply-To: <COL101-W2557FFC4969C25FB708C06E6180@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<COL101-W2557FFC4969C25FB708C06E6180@phx.gbl>
Message-ID: <20120516210706.GA8654@topoi.pooq.com>

On Wed, May 16, 2012 at 08:40:51PM +0000, Jay K wrote:
> 
>  >  And is there also a source package built?
> 
> 
>  No. It would be C code anyway, so not source from most 
> people's point of view.
> 
>  
> > Because the source package is what's needed for uploading to 
> > Debian.
> 
> 
> They wouldn't like it anyway.
>  What do they do with stuff written in Haskell, C#, etc.?
> 

They'd be happy with it provided they have Haskel, C#, etc. 
implementations already in the system.  A Debian package 
can have build-dependencies, which is other packages that 
have to be installed to builld it.  I don't know how this works 
with bootstrapping self-hosting languages.  Maybe it takes 
ad-hockery.  Maybe a new release build-depends on the 
previous one.  Or on anything aat least as up-to-date as 
the previous one.

-- hendrik



From hendrik at topoi.pooq.com  Wed May 16 23:15:26 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 17:15:26 -0400
Subject: [M3devel] building packages
In-Reply-To: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
Message-ID: <20120516211526.GB8654@topoi.pooq.com>

On Wed, May 16, 2012 at 08:24:52PM +0000, Jay K wrote:
> 
> Your CVS tree is maybe incomplete or out of date? Try this:
>    cd m3-sys   
>    rm -rf m3cc  
>    cvs -z3 upd -dAP m3cc   
>    cd m3cc   
>    cm3  

I wsn't using the CVS tree.  I was using 
cm3-src-all-5.8.6-REL.tgz, downloaded from 
http://modula3.elegosoft.com/cm3/releng/download.html.

Maybe your instructions apply only to a still-newer source 
tree.

>  
> 
> Or just checkout a whole new tree.

That's what I'll do.  Is the current head in good 
enough shape?

> 
> 
> Yes, there is a lot of C code, that uses autoconf -- the gcc backend.

So you compile the gcc backend.  Presumably cross-compile 
it if necessary.  Does gcc on one platform also produce 
object code for another?  Or does the script custom-pick 
the backend depending on the target platform?

-- hendrik

> 
> 
>  - Jay
> 


From hendrik at topoi.pooq.com  Wed May 16 23:28:59 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 17:28:59 -0400
Subject: [M3devel] distribution format?
In-Reply-To: <COL101-W2222C4AA8CB67F3F46D9E2E6180@phx.gbl>
References: <COL101-W2222C4AA8CB67F3F46D9E2E6180@phx.gbl>
Message-ID: <20120516212859.GD8654@topoi.pooq.com>

On Wed, May 16, 2012 at 08:55:20PM +0000, Jay K wrote:
> 
> What distribution format or formats should we aim for?
> 
> 
> One thing to consider, in our various preferences for a source/assembly distribution,
> is that there is the large gcc backend.
> 
> 
> How many people, even if they build stuff from source, build gcc?
> How many of those attempts are deemed onerously slow? Or fail and onerous to debug? etc.
> And people give up?
> Consider that OpenBSD discourages its users from building from source.
> Instead they provide binary packages for "everything".
> 
> 
> Yes yes a C-generating backend would fix that and merely require the user have gcc or such.
> Is the middle step worthwhile?
> 
> 
> Is a gcc plugin viable at this point?
> I'm not too interested in that really.
> 
> 
> Maybe the answer is to "get into" the distributions, into the package systems.
> Put rebuild work on the distributions?
> They do handle gcc already, somehow, e.g. via a cross into a new/empty file system, presumably.
> Can anyone else research that?

gentoo has a minimal binary distribution and they use that 
to build everything else, possibly including a newer gcc.  
But then gentoo is for the fanatics that want to build 
everything themselves from source code.

I've recently read through the Debian packaging tutorial, 
enough to make my eyes glaze over.  I'll have another look 
to see if I manage to understand anything relevant.

-- hendrik

> 
> Thank you,
>  - Jay

You're welcome!

-- hendrik


From hendrik at topoi.pooq.com  Thu May 17 00:31:23 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 18:31:23 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
Message-ID: <20120516223123.GA25611@topoi.pooq.com>

On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote:
> 
> You might as well just use something in scripts to rebuild the entire system.It isn't so difficult nor takes very long.     Get a working cm3 on any system.
      cd scripts/python
      ./boot1.py <target-such-as-I386_LINUX>

Is I386_LINUX no longer called LINUXLIBC6?

-- hendrik


From jay.krell at cornell.edu  Thu May 17 01:40:53 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 23:40:53 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <20120516223123.GA25611@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516223123.GA25611@topoi.pooq.com>
Message-ID: <COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>


 LINUXLIBC6 is supported, but I'd really like to drop it.  The following are supported and work: 
   I386_NT    I386_CYGWIN    I386_NETBSD    I386_FREEBSD    I386_LINUX    SPARC32_SOLARIS ?   The following I'd like to get rid of, but they are pretty cheap to carry along:   NetBSDi386 or somesuch     FreeBSD4      LINUXLIBC6       SOLgnu      SOLsun     You can cross build from any to any, and then leave the old stuff behind...     But heck, really, if we generate C, then targets largely drop away.    Not entirely, not without other changes.     cm3 knows very very little about any targets, mainly their word size, endianness, and jmpbuf size.     jmpbuf size is high on my list to remove. I had it almost fixed, but not quite right.     Target dependencies are mostly in other places:     1) quake code        2) #ifdef C       3) the gcc backend       The quake code and #ifdefed C can largely be merged into just #ifdefed C, and thatlargely goes away if/when we have preemptive suspend.Ok ok, that's only for garbage collection. File I/O and GUI are still forked Win32 vs. Posix,and always will be in Trestle. Maybe we'll layer over Qt or such someday...  In the present structuring there is also some need/want for "user threads" targets:  I386_LINUX    I386_LINUX_USERTHREADS    but I'd rather make that a compile/link/runtime option instead.Currently anyone needing/wanting userthreads gets to recompile the world.   - Jay
 > Date: Wed, 16 May 2012 18:31:23 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] LINUXLIBC6
> 
> On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote:
> > 
> > You might as well just use something in scripts to rebuild the entire system.It isn't so difficult nor takes very long.     Get a working cm3 on any system.
>       cd scripts/python
>       ./boot1.py <target-such-as-I386_LINUX>
> 
> Is I386_LINUX no longer called LINUXLIBC6?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/10efe6f3/attachment.html>

From hendrik at topoi.pooq.com  Thu May 17 01:55:49 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 19:55:49 -0400
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <20120516211526.GB8654@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
Message-ID: <20120516235549.GB3955@topoi.pooq.com>

On Wed, May 16, 2012 at 05:15:26PM -0400, Hendrik Boom wrote:
> On Wed, May 16, 2012 at 08:24:52PM +0000, Jay K wrote:
> > 
> > Your CVS tree is maybe incomplete or out of date? Try this:
> >    cd m3-sys   
> >    rm -rf m3cc  
> >    cvs -z3 upd -dAP m3cc   
> >    cd m3cc   
> >    cm3  
> 
> I wsn't using the CVS tree.  I was using 
> cm3-src-all-5.8.6-REL.tgz, downloaded from 
> http://modula3.elegosoft.com/cm3/releng/download.html.
> 
> Maybe your instructions apply only to a still-newer source 
> tree.
> 
> >  
> > 
> > Or just checkout a whole new tree.
> 
> That's what I'll do.  Is the current head in good 
> enough shape?

Just checked out a whole new source tree.

cd scripts/python
./upgrade.py

and got 1504 lines of messages (yes, I saved them this time) ending with:

configure: creating ./config.status
config.status: creating Makefile
cd . && make  MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: c
onfigure-host
cd . && make  MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host
mkdir -p -- ./gcc
Configuring in ./gcc
configure: creating cache ./config.cache
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking LIBRARY_PATH variable... contains current directory
configure: error: 
*** LIBRARY_PATH shouldn't contain the current directory when
*** building gcc. Please change the environment variable
*** and run configure again.
make: *** [configure-gcc] Error 1
"/farhome/hendrik/cm3/cm3/m3-sys/m3cc/src/m3makefile", line 281: quake runtime error: exit 2: cd . && make  MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host

--procedure--  -line-  -file---
exec               --  <builtin>
m3cc_Run          281  /farhome/hendrik/cm3/cm3/m3-sys/m3cc/src/m3makefile
include_dir       475  /farhome/hendrik/cm3/cm3/m3-sys/m3cc/src/m3makefile
                    5  /farhome/hendrik/cm3/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args

Fatal Error: package build failed
 *** execution of [<function _BuildGlobalFunction at 0x7f70063d6848>, <function _ShipFunction at 0x7f70063d68c0>] failed ***
hendrik at april:~/cm3/cm3/scripts/python$ 


I'm not out of the woods yet.

By the way, the LIBRARY_PATH in the shell from which I ran upgrade.py
was 

hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH
:/usr/local/Gambit-C/lib
hendrik at april:~/cm3/cm3/scripts/python$ 

and seems to have nothing to do with anything, 
so I'll have to investigate further.

-- hendrik


From jay.krell at cornell.edu  Thu May 17 01:58:15 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 23:58:15 +0000
Subject: [M3devel] building packages
In-Reply-To: <20120516211526.GB8654@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>
Message-ID: <COL101-W3674E59BA09B552B45BAE4E6180@phx.gbl>


  > From: hendrik at topoi.pooq.com     > I wasn't using the CVS tree. I was using   
  > cm3-src-all-5.8.6-REL.tgz, downloaded from   
  
 cm3-src-all-5.8.6-REL.tgz really ought to work.     
 But I don't know.    
 I can try later.   
 
  
  
  > That's what I'll do. Is the current head in good   
  > enough shape?     I think so, but please try it, and we'll see.    
  I've actively using it lately (working on moving to gcc 4.6, making good progress)      
 
  > So you compile the gcc backend. Presumably cross-compile   
  > it if necessary. Does gcc on one platform also produce   
  > object code for another? Or does the script custom-pick   
  > the backend depending on the target platform?  
It works. Trust me. Try it.   Details:
 
  if you read m3cc/src/m3makefile, you see that "build_dir" is either "." or "../<host>-<target>"      "." is really host or target -- the same thing, for a native build.    cm3 automatically creates and cd's into it, rending it as just ".".     We configure gcc appropriately (--host, --target) and run the cm3cg by full path, as I recall.     We aren't cross-compiling gcc. We are building a cross-compiler.  
  The following is confusing, but makes sense once you get your head around it:  
  There are potentially up to 3 machines: "build", "host", "target".  
  "build" is the machine you are sitting on "now". The one you are building the compiler on.  
  The machine you are building the compiler on.    
  "host" is the machine that the resulting compiler will run on. It will "host" the compiler.    
  "target" is the machine that will run the compiler's output -- that the compiler will "target".       In common practise, all 3 are the same and things are nice and simple.  
    
  But it can be that any two of three are the same or that all three are the same.
    In the context of the Modula-3 build scripts, build and host are always the same.    
  
  When host and target are different, that is a cross compiler.
  When build and host are different, you are cross compiling the compiler.    
  When all three are different, you are cross compiling a cross compiler.  
  When build and target are the same but not equal to host, I don't know a term for that, I call it "cross back" -- you are     building a compiler that will run on a different system but which will produce code for the system you are building it on.  
  
     
  The challenge in various "cross " scenarios is having/getting the headers and libraries (libc) and linker and assembler,   
  and related, building libgcc2.   
  Often-times but not always, the GNU linker/assembler help.    
  Sometimes GNU libc helps.    
  But I for example haven't been able to build an ia64-linux toolset, due to the headers/libraries.  
  
  Building the C frontend/backend (and gcc driver for that matter) for build==host is actually always very easy.  
 
  
  If you program is just:
  int add(int a, int b) { return a + b }        and you have gcc source, it is easy to convert it to assembly for any target,
  without any headers/libraries/linker/assembler. That is all Modula-3 uses gcc for.    
  But throw in an #include <stdio.h> or try to link to anything, and you need a lot more.      In the Modula-3 system, how it was mostly structured at the start, and now, we cheat.  
  "final compilation/assembly/linking" can be deferred to the target system, which is  
  dependend upon to have a working native toolset. That is what my "bootstrap" archives do.
  That is what the "bootstrap" archives of olden times (circa 3.6/1996) did I believe. 
  Also quake was written in C back then.   
  Targeting something like iPhone/iPad doesn't fit...except that C cross tools are available  
  enough, so the same structuring works fine.  
  You typically just have to run different toplevel gcc/ld or add a switch like gcc -arch arm.      We also cheat these days in that where #include <stdio.h> (for C runtime/kernel) was needed, I rewrote the code in C.    This protects us from stdio.h changing or varying per-target. It was a big porting and maintenance and safety problem.    <windows.h> and <Xlib.h> we still clone in Modula-3. They don't change so much. But maybe we should    do something different there too.  
   Make some sense?      - Jay   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/b84cf658/attachment.html>

From jay.krell at cornell.edu  Thu May 17 01:59:51 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 23:59:51 +0000
Subject: [M3devel] distribution format?
In-Reply-To: <20120516212859.GD8654@topoi.pooq.com>
References: <COL101-W2222C4AA8CB67F3F46D9E2E6180@phx.gbl>,
	<20120516212859.GD8654@topoi.pooq.com>
Message-ID: <COL101-W23A02FD30BF2BCE47AEB94E6180@phx.gbl>


Agreed both: I haven't gotten Gentoo to work, despit trying. Debian developer manual is a lot to read.  - Jay
 > Date: Wed, 16 May 2012 17:28:59 -0400
> From: hendrik at topoi.pooq.com
> 
> gentoo has a minimal binary distribution and they use that 
> to build everything else, possibly including a newer gcc.  
> But then gentoo is for the fanatics that want to build 
> everything themselves from source code.
> 
> I've recently read through the Debian packaging tutorial, 
> enough to make my eyes glaze over.  I'll have another look 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/a21e5127/attachment.html>

From jay.krell at cornell.edu  Thu May 17 02:03:23 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 00:03:23 +0000
Subject: [M3devel] Package dependencies.
In-Reply-To: <20120516210706.GA8654@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<COL101-W2557FFC4969C25FB708C06E6180@phx.gbl>,
	<20120516210706.GA8654@topoi.pooq.com>
Message-ID: <COL101-W17DBAC2F81606B73A0A39CE6190@phx.gbl>


 >> I don't know how this works with bootstrapping self-hosting languages    I think you hit the nail on the head -- "bootstrapping self-hosting languages". Good!    Keep using that phrase if you email folks asking about this, and make sure they understand it.         Meanwhile, I still want to generate fairly portable C or C++ to get around the problem. :)        First I'm going to upgrade to gcc 4.6 backend, and then maybe 4.7..stalling... :)         >  What do they do with stuff written in Haskell, C#, etc.?  
   > They'd be happy with it provided they have Haskel, C#, etc.     
 Right: I should have said a C# compiler written in C#, a Haskell compiler written in Haskell, etc.   - Jay
 > Date: Wed, 16 May 2012 17:07:06 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Package dependencies.
> 
> On Wed, May 16, 2012 at 08:40:51PM +0000, Jay K wrote:
> > 
> >  >  And is there also a source package built?
> > 
> > 
> >  No. It would be C code anyway, so not source from most 
> > people's point of view.
> > 
> >  
> > > Because the source package is what's needed for uploading to 
> > > Debian.
> > 
> > 
> > They wouldn't like it anyway.
> >  What do they do with stuff written in Haskell, C#, etc.?
> > 
> 
> They'd be happy with it provided they have Haskel, C#, etc. 
> implementations already in the system.  A Debian package 
> can have build-dependencies, which is other packages that 
> have to be installed to builld it.  I don't know how this works 
> with bootstrapping self-hosting languages.  Maybe it takes 
> ad-hockery.  Maybe a new release build-depends on the 
> previous one.  Or on anything aat least as up-to-date as 
> the previous one.
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/7a8daeed/attachment.html>

From jay.krell at cornell.edu  Thu May 17 02:06:00 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 00:06:00 +0000
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <20120516235549.GB3955@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>
Message-ID: <COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>


     > *** LIBRARY_PATH shouldn't contain the current directory when  
     > *** building gcc. Please change the environment variable  
     > *** and run configure again.  
    hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
  :/usr/local/Gambit-C/lib  
 Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/d863e4e0/attachment.html>

From hendrik at topoi.pooq.com  Thu May 17 02:48:25 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 20:48:25 -0400
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
Message-ID: <20120517004825.GA30435@topoi.pooq.com>

On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> 
>      > *** LIBRARY_PATH shouldn't contain the current directory when  
>      > *** building gcc. Please change the environment variable  
>      > *** and run configure again.  
>     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
>   :/usr/local/Gambit-C/lib  
>  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  

Interesting.  I thought you had to say . to get the current directory, and that the 
empty string meant nothing at all.  Evidently the  standard way of appending something 
to LIBRARY_PATH has a bug in the empty case.  Strings aren't the best way of doing lots 
of things, but they're ubiquitous, are oftern the only thing available, and lead to bugs 
like this.

-- hendrik




From jay.krell at cornell.edu  Thu May 17 02:59:31 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 00:59:31 +0000
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <20120517004825.GA30435@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>,
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>,
	<20120517004825.GA30435@topoi.pooq.com>
Message-ID: <COL101-W28EDF0AAE2AE13133B4948E6190@phx.gbl>


 > From: hendrik at topoi.pooq.com 
 > Strings aren't the best way of doing lots  
 > of things, but they're ubiquitous, are oftern the only thing available, and lead to bugs  
 Definitely.  A classic example is the command line, for various reasons.On Windows for example, the lower layers pass the command line as one flat string.So then it has to be split up to form argv. On spaces. Which have to be quoted if they are in individual elements. But quotes can occur too. Mess. Even on Unix where the kernel accepts an array, it doesn't work well, like if you are passing any "special" characters, at least if there is an intervening /bin/sh. There are length limits, at least on Windows, so compilers/linkers accept their commands in files as well, and long command lines are stuffed into files.  Strongly typed function calls work much better.Over RPC if necessary.  URLs have similar problems.  I see problems caused by this stuff pretty frequently..   - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/a78ddb09/attachment.html>

From hendrik at topoi.pooq.com  Thu May 17 03:49:03 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 21:49:03 -0400
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
Message-ID: <20120517014903.GA19546@topoi.pooq.com>

On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> 
>      > *** LIBRARY_PATH shouldn't contain the current directory when  
>      > *** building gcc. Please change the environment variable  
>      > *** and run configure again.  
>     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
>   :/usr/local/Gambit-C/lib  
>  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  

Yes, emptying LIBRARY_PATH enabled uprade.py to complete successfully.
Thanks.  It would have taken me many ages to figure this out.

-- hendrik



From dabenavidesd at yahoo.es  Thu May 17 03:58:50 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 17 May 2012 02:58:50 +0100 (BST)
Subject: [M3devel] Package dependencies.
In-Reply-To: <COL101-W17DBAC2F81606B73A0A39CE6190@phx.gbl>
Message-ID: <1337219930.11755.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
correct but since 70's anybody could use a CG machine to reproduce the language in any environment and then port it from there to any other machine of similar characteristics.
I think most of M3CG was inspired by Titan RISC DEC chip, but it came first by an effort to emulate the VAX on a RISC and if Modula-3 ever succeeded by running a VAX instruction it doesn't need to be such, so don't raise a concern on the language it was born and so, but in the language it had to be arise in.
That said, Modula-3 or anything is much compact in a RISC machine than in any other CISC-like machine, which is for what C was created in first place as Macro-package then used as a Programming language on its own. Modula-3 was a ready Programming environment for the VAX native back-end for a RISC. This was an? environment in for which you could see the benefits of a good small language enough powerful to run a native system in and so.
Thanks in advance


?

--- El mi?, 16/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Package dependencies.
Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 16 de mayo, 2012 19:03




?>> I don't know how this works with bootstrapping self-hosting languages
?
?
? I think you hit the nail on the?head -- "bootstrapping self-hosting languages". Good!? 
? Keep using that phrase if you email folks asking?about this, and make sure they understand it.? 
?
?
??? ?Meanwhile, I still want to generate fairly portable C or C++ to get around the problem. :)?? 
??? ?First I'm going to upgrade to gcc 4.6 backend, and then maybe 4.7..stalling... :)??? 
?
?
? ?>  What do they do with stuff written in Haskell, C#, etc.?? 
? ?> They'd be happy with it provided they have Haskel, C#, etc.???? 

?
Right: I should have said a C# compiler written in C#, a Haskell compiler written in Haskell, etc.
?
?
?- Jay
?
> Date: Wed, 16 May 2012 17:07:06 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Package dependencies.
> 
> On Wed, May 16, 2012 at 08:40:51PM +0000, Jay K wrote:
> > 
> >  >  And is there also a source package built?
> > 
> > 
> >  No. It would be C code anyway, so not source from most 
> > people's point of view.
> > 
> >  
> > > Because the source package is what's needed for uploading to 
> > > Debian.
> > 
> > 
> > They wouldn't like it anyway.
> >  What do they do with stuff written in Haskell, C#, etc.?
> > 
> 
> They'd be happy with it provided they have Haskel, C#, etc. 
> implementations already in the system.  A Debian package 
> can have build-dependencies, which is other packages that 
> have to be installed to builld it.  I don't know how this works 
> with bootstrapping self-hosting languages.  Maybe it takes 
> ad-hockery.  Maybe a new release build-depends on the 
> previous one.  Or on anything aat least as up-to-date as 
> the previous one.
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/cb176be8/attachment.html>

From hendrik at topoi.pooq.com  Thu May 17 04:35:33 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 22:35:33 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517014903.GA19546@topoi.pooq.com>
References: <20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
Message-ID: <20120517023533.GB19546@topoi.pooq.com>

On Wed, May 16, 2012 at 09:49:03PM -0400, Hendrik Boom wrote:
> On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> > 
> >      > *** LIBRARY_PATH shouldn't contain the current directory when  
> >      > *** building gcc. Please change the environment variable  
> >      > *** and run configure again.  
> >     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
> >   :/usr/local/Gambit-C/lib  
> >  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  
> 
> Yes, emptying LIBRARY_PATH enabled uprade.py to complete successfully.
> Thanks.  It would have taken me many ages to figure this out.
> 
> -- hendrik
> 
Now I'm onto ./make-dist.py

It fails in teh data base stuff.

First becaues it didn't have libodbc.  So I installed package unixodbc.
But then:

== package /farhome/hendrik/cm3/cm3/m3-db/odbc ==

 +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3    -build -DROOT=/farhome/hendrik/cm3/cm3 +++
--- building in AMD64_LINUX ---

ignoring ../src/m3overrides

 ==> /farhome/hendrik/cm3/cm3/m3-db/odbc done

 +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3  -ship -DROOT=/farhome/hendrik/cm3/cm3 +++
--- shipping from AMD64_LINUX ---

. => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
  .M3EXPORTS      
. => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib
  libm3odbc.so.5  "/farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP", line 4: quake runtime error: unable to copy "libm3odbc.so.5" to "/tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib/libm3odbc.so.5": errno=2

--procedure--  -line-  -file---
install_file       --  <builtin>
                    4  /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP

Fatal Error: package build failed
 *** execution of [<function _BuildGlobalFunction at 0x1a56de8>, <function _ShipFunction at 0x1a56c80>] failed ***
hendrik at april:~/cm3/cm3/scripts/python$ 


It doesn't seem to build libm3odbc.so.5

hendrik at april:~/cm3/cm3/m3-db/odbc$ ls AMD64_LINUX/
libm3odbc.a    libm3odbc.so  SQLext.mo  SQLtypes.io
libm3odbc.m3x  SQLext.io     SQL.io
hendrik at april:~/cm3/cm3/m3-db/odbc$ 

There's nothing at all in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
There are lots of files in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib,
but nothing resembling libm3odbc>

-- hendrik




From jay.krell at cornell.edu  Thu May 17 08:01:19 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 06:01:19 +0000
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517023533.GB19546@topoi.pooq.com>
References: <20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>,
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>,
	<20120517014903.GA19546@topoi.pooq.com>,
	<20120517023533.GB19546@topoi.pooq.com>
Message-ID: <COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>


Good.
Wasn't the error message from configure obvious though?


Anyway:
  I think there's a "minor" incrementality bug here.   
  Incremental build isn't picking back up where it left off/failed.  

Try this:
   rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
   rm -rf /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516 
   ./make-dist.py  


OR:  
   rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
   Look at make-dist.py/pylib.py -- get it to point at the same output as before and then just:  
  ./make-dist.py 



That is -- I think every run of make-dist.py is clean to a new temporary timestamp-based location.
This is good and bad.


Note also, I think it is obvious, but I wrote make-dist.py to always package up everything possible
for the target platform. So it is up to you as the "builder" to have all the dependencies already installed.
It isn't great.
I don't believe there is a perfect option here.
Another release form we have yields a bunch of per-target packages.
I find that confusing -- too many.
My form yields just one largeish per-target package.
Over-size, monolithic, but simpler, less choices to confuse people.


Of course ultimately we don't want per-target stuff at all. :)
Or at least we want both "source" and "binary" distributions.


Still I am confused.
Don't people have binary distributions of programs with GUIs for Linux?
Like Komodo IDE, Komodo Edit, Acrobat Reader?


Maybe we should really have a java-generating backend...one binary distribution for all..and a better Android story?
I know, there is a funny tradeoff here. Modula-3 is kind of lower-level than Java.
You'd want such a backend/port to throw out our garbage collector..and heck..all unsafe code....
 (or generate C for those and use JNI or such...interesting..theoretically possible..unlikely to happen..)


 - Jay


> Date: Wed, 16 May 2012 22:35:33 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] building packages from source from cvs -- odbc
> 
> On Wed, May 16, 2012 at 09:49:03PM -0400, Hendrik Boom wrote:
> > On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> > > 
> > >      > *** LIBRARY_PATH shouldn't contain the current directory when  
> > >      > *** building gcc. Please change the environment variable  
> > >      > *** and run configure again.  
> > >     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
> > >   :/usr/local/Gambit-C/lib  
> > >  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  
> > 
> > Yes, emptying LIBRARY_PATH enabled uprade.py to complete successfully.
> > Thanks.  It would have taken me many ages to figure this out.
> > 
> > -- hendrik
> > 
> Now I'm onto ./make-dist.py
> 
> It fails in teh data base stuff.
> 
> First becaues it didn't have libodbc.  So I installed package unixodbc.
> But then:
> 
> == package /farhome/hendrik/cm3/cm3/m3-db/odbc ==
> 
>  +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3    -build -DROOT=/farhome/hendrik/cm3/cm3 +++
> --- building in AMD64_LINUX ---
> 
> ignoring ../src/m3overrides
> 
>  ==> /farhome/hendrik/cm3/cm3/m3-db/odbc done
> 
>  +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3  -ship -DROOT=/farhome/hendrik/cm3/cm3 +++
> --- shipping from AMD64_LINUX ---
> 
> . => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
>   .M3EXPORTS      
> . => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib
>   libm3odbc.so.5  "/farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP", line 4: quake runtime error: unable to copy "libm3odbc.so.5" to "/tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib/libm3odbc.so.5": errno=2
> 
> --procedure--  -line-  -file---
> install_file       --  <builtin>
>                     4  /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP
> 
> Fatal Error: package build failed
>  *** execution of [<function _BuildGlobalFunction at 0x1a56de8>, <function _ShipFunction at 0x1a56c80>] failed ***
> hendrik at april:~/cm3/cm3/scripts/python$ 
> 
> 
> It doesn't seem to build libm3odbc.so.5
> 
> hendrik at april:~/cm3/cm3/m3-db/odbc$ ls AMD64_LINUX/
> libm3odbc.a    libm3odbc.so  SQLext.mo  SQLtypes.io
> libm3odbc.m3x  SQLext.io     SQL.io
> hendrik at april:~/cm3/cm3/m3-db/odbc$ 
> 
> There's nothing at all in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> There are lots of files in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib,
> but nothing resembling libm3odbc>
> 
> -- hendrik
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/e2bd275d/attachment.html>

From jay.krell at cornell.edu  Thu May 17 08:10:40 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 06:10:40 +0000
Subject: [M3devel] C99 FloatMode stuff
Message-ID: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl>


Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/de246aa3/attachment.html>

From hendrik at topoi.pooq.com  Thu May 17 17:48:37 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 17 May 2012 11:48:37 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
References: <20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
Message-ID: <20120517154836.GA20605@topoi.pooq.com>

On Thu, May 17, 2012 at 06:01:19AM +0000, Jay K wrote:
> 
> Good.
> Wasn't the error message from configure obvious though?

Evidently not.  Or I was too much asleep last night.  Or I didn't get 
one. I'm looking for one now.  I find none in my most recent script 
output.  In one of the old ones I find

checking for modern makeinfo... no
configure: WARNING:
*** Makeinfo is missing or too old.
*** Info documentation will not be built.
checking for recent Pod::Man... yes

but I suspect that may be irrelevant.  Unless packageing fails later 
because it tries to package the info docs, which I hate anyway.

No, I don't find any messages.  But then, I'm simply using my old, 
working cm3 compiler as a bootstrap to build the whole system for the 
same machine.  I didn't have a specific 'configure' step.

I found a bunch of compilation warnings about
* labels and other names  being defined but not used.
* comparisons always false due to limited range of data type
* invalid conversion type characters.  Might these actually cause 
run-time failures?
* right-hand operand of comma has no effect

These are unlikely to be the problems I'm contending with, but might 
it be worth going through the entire build sometime and tracking 
then all down?  Grepping my script output for "warning" would 
probably find them all.


> 
> 
> Anyway:
>   I think there's a "minor" incrementality bug here.   
>   Incremental build isn't picking back up where it left off/failed.  
> 
> Try this:
>    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
>    rm -rf /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516 
>    ./make-dist.py  

Will do.  I had planned to do something like this when I was awake this 
morning, but I was unsure just which files needed to be deleted.

> 
> 
> OR:  
>    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
>    Look at make-dist.py/pylib.py -- get it to point at the same output as before and then just:  
>   ./make-dist.py 
> 
> 
> 
> That is -- I think every run of make-dist.py is clean to a new temporary timestamp-based location.
> This is good and bad.
> 
> 
> Note also, I think it is obvious, but I wrote make-dist.py to always package up everything possible
> for the target platform. So it is up to you as the "builder" to have all the dependencies already installed.
> It isn't great.
> I don't believe there is a perfect option here.
> Another release form we have yields a bunch of per-target packages.

This is the way other languages have gone in Debian.  The main reason 
seems to be to reduce the amount of other packages that have to be installed via 
dependencies that the user might not have any interest in.  Essentially 
a distinction between the language, the applications, and the 
libraries.  Something like what Modula3 does with its tgz'ed 
binary "packages".

> I find that confusing -- too many.
> My form yields just one largeish per-target package.
> Over-size, monolithic, but simpler, less choices to confuse people.
> 
> 
> Of course ultimately we don't want per-target stuff at all. :)
> Or at least we want both "source" and "binary" distributions.
> 
> 
> Still I am confused.
> Don't people have binary distributions of programs with GUIs for Linux?
> Like Komodo IDE, Komodo Edit, Acrobat Reader?
> 
> 
> Maybe we should really have a java-generating backend...one binary distribution for all..and a better Android story?

That could be useful on Android.  But it *is* possible to get package C 
or at least C object code to run on Android.  I think that's the 
approach being used to get Python to run on Android.

> I know, there is a funny tradeoff here. Modula-3 is kind of lower-level than Java.
> You'd want such a backend/port to throw out our garbage collector..and heck..all unsafe code....
>  (or generate C for those and use JNI or such...interesting..theoretically possible..unlikely to happen..)
> 
> 
>  - Jay


From dabenavidesd at yahoo.es  Thu May 17 18:18:52 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 17 May 2012 17:18:52 +0100 (BST)
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl>
Message-ID: <1337271532.47137.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I believe they are in system limits.h aren't they.
BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
Thanks in advance.

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] C99 FloatMode stuff
Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 01:10




Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

?- Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/c995d0eb/attachment.html>

From jay.krell at cornell.edu  Thu May 17 20:46:14 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 18:46:14 +0000
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <1337271532.47137.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl>,
	<1337271532.47137.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <COL101-W4BF60E04E5B4DB1D35477E6190@phx.gbl>


No Daniel. 


Date: Thu, 17 May 2012 17:18:52 +0100
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] C99 FloatMode stuff
To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I believe they are in system limits.h aren't they.
BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
Thanks in advance.

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] C99 FloatMode stuff
Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 01:10




Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

 - Jay
 		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/8b0d5a49/attachment.html>

From hendrik at topoi.pooq.com  Thu May 17 20:57:53 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 17 May 2012 14:57:53 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517154836.GA20605@topoi.pooq.com>
References: <20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
Message-ID: <20120517185753.GA5741@topoi.pooq.com>

On Thu, May 17, 2012 at 11:48:37AM -0400, Hendrik Boom wrote:
> On Thu, May 17, 2012 at 06:01:19AM +0000, Jay K wrote:
> > 
> > Good.
> > Wasn't the error message from configure obvious though?
> 
> Evidently not.  Or I was too much asleep last night.  Or I didn't get 
> one. I'm looking for one now.  I find none in my most recent script 
> output.  In one of the old ones I find
> 
> checking for modern makeinfo... no
> configure: WARNING:
> *** Makeinfo is missing or too old.
> *** Info documentation will not be built.
> checking for recent Pod::Man... yes
> 
> but I suspect that may be irrelevant.  Unless packageing fails later 
> because it tries to package the info docs, which I hate anyway.
> 
> No, I don't find any messages.  But then, I'm simply using my old, 
> working cm3 compiler as a bootstrap to build the whole system for the 
> same machine.  I didn't have a specific 'configure' step.
> 
> I found a bunch of compilation warnings about
> * labels and other names  being defined but not used.
> * comparisons always false due to limited range of data type
> * invalid conversion type characters.  Might these actually cause 
> run-time failures?
> * right-hand operand of comma has no effect
> 
> These are unlikely to be the problems I'm contending with, but might 
> it be worth going through the entire build sometime and tracking 
> then all down?  Grepping my script output for "warning" would 
> probably find them all.
> 
> 
> > 
> > 
> > Anyway:
> >   I think there's a "minor" incrementality bug here.   
> >   Incremental build isn't picking back up where it left off/failed.  
> > 
> > Try this:
> >    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
> >    rm -rf /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516 
> >    ./make-dist.py  
> 
> Will do.  I had planned to do something like this when I was awake this 
> morning, but I was unsure just which files needed to be deleted.
> 

It definitely got past odbc now.  But it stopped within ESC.  I was 
surprised to find it her; I had thought the source code to be long lost.
I don't see am error message except for the failure to find .M3EXPORTS, 
ahich is probably something that cm3 should have generated.

The m3makefile 
/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile
seems to have trouble finding 
/tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/pkg/prover/AMD64_LINUX/.M3EXPORTS
which seems to me to be one level out in the source code.  Just what 
determines the order that these things are to be compiled?  The 
compilation log makes it look as if the outer one (prover) needed to be 
compiled first, so as to enerate the .M3EXPORTS file, but that the inner 
one (prover/test) actually got compiled first. 

Here's the output, starting with the first line of log contianing either 
the words "Simplify" or "prover".


== package /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test ==

 +++ /tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/bin/cm3    
-build -DROOT=/farhome/hendrik/cm3/cm3 +++
--- building in AMD64_LINUX ---

ignoring ../src/m3overrides

"/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile", line 
1: quake runtime error: unable to open 
"/tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/pkg/prover/AMD64_LINUX/.M3EXPORTS" 
for reading

--procedure--  -line-  -file---
import             --  <builtin>
include_dir         1  
/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile
                    5  
/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/AMD64_LINUX/m3make.args

Fatal Error: package build failed
 *** execution of [<function _BuildGlobalFunction at 0x10d0de8>, 
<function _ShipFunction at 0x10d0c80>] failed ***
hendrik at april:~/cm3/cm3/scripts/python$ exit

-- hendrik



From dabenavidesd at yahoo.es  Fri May 18 00:27:25 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 17 May 2012 23:27:25 +0100 (BST)
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <COL101-W4BF60E04E5B4DB1D35477E6190@phx.gbl>
Message-ID: <1337293645.96958.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
if not then either that value doesn't sound as a machine value since the OS must care at least of constant values in memory (you can't allow values larger than what memory supports) or (whichever library they had created) is "their standard" , I don't think C standards are very precise, in fact, they are bad, who needs C standards, who created or thinks knows the standards.
What the argot I would like to see are:
Infinity values, epsilon, and? memory limits under such that limit values holds, that is, you can't represent epsilon with little value of memory.
This would be the jargon of such libraries, instead they just make them a internal operation of their own calculation, which I can't trust, in summary this thing is unsound. Then the interface is UNSAFE for real which can't be a very standard thing by the way.
Thanks in advance

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] C99 FloatMode stuff
Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 13:46




No Daniel. 


Date: Thu, 17 May 2012 17:18:52 +0100
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] C99 FloatMode stuff
To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I believe they are in system limits.h aren't they.
BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
Thanks in advance.

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] C99 FloatMode stuff
Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 01:10




Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

?- Jay
 		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/6ab41119/attachment.html>

From jay.krell at cornell.edu  Fri May 18 01:29:16 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 23:29:16 +0000
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517185753.GA5741@topoi.pooq.com>
References: <20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>,
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>,
	<20120517014903.GA19546@topoi.pooq.com>,
	<20120517023533.GB19546@topoi.pooq.com>,
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>,
	<20120517154836.GA20605@topoi.pooq.com>,
	<20120517185753.GA5741@topoi.pooq.com>
Message-ID: <COL101-W47988370CD738A644D7366E6190@phx.gbl>


I have not built the entire tree since that stuff came in.Oops.  If the goal is to get some sort of .deb, to see what it is, to give it to someone else, do this:    cd scripts    rm PKGSDB    edit down pkginfo.txt     hm, oops, this stuff isn't in there?      The same information might be duplicated in pylib.py?   I think I fixed that..based on a quick read.       Maybe we pickup all m3makefiles? Maybe.    Just rm -rf from your tree anything that is giving you trouble now, as you've already built lots of stuff.     - Jay

 > Date: Thu, 17 May 2012 14:57:53 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] building packages from source from cvs -- odbc
> 
> On Thu, May 17, 2012 at 11:48:37AM -0400, Hendrik Boom wrote:
> > On Thu, May 17, 2012 at 06:01:19AM +0000, Jay K wrote:
> > > 
> > > Good.
> > > Wasn't the error message from configure obvious though?
> > 
> > Evidently not.  Or I was too much asleep last night.  Or I didn't get 
> > one. I'm looking for one now.  I find none in my most recent script 
> > output.  In one of the old ones I find
> > 
> > checking for modern makeinfo... no
> > configure: WARNING:
> > *** Makeinfo is missing or too old.
> > *** Info documentation will not be built.
> > checking for recent Pod::Man... yes
> > 
> > but I suspect that may be irrelevant.  Unless packageing fails later 
> > because it tries to package the info docs, which I hate anyway.
> > 
> > No, I don't find any messages.  But then, I'm simply using my old, 
> > working cm3 compiler as a bootstrap to build the whole system for the 
> > same machine.  I didn't have a specific 'configure' step.
> > 
> > I found a bunch of compilation warnings about
> > * labels and other names  being defined but not used.
> > * comparisons always false due to limited range of data type
> > * invalid conversion type characters.  Might these actually cause 
> > run-time failures?
> > * right-hand operand of comma has no effect
> > 
> > These are unlikely to be the problems I'm contending with, but might 
> > it be worth going through the entire build sometime and tracking 
> > then all down?  Grepping my script output for "warning" would 
> > probably find them all.
> > 
> > 
> > > 
> > > 
> > > Anyway:
> > >   I think there's a "minor" incrementality bug here.   
> > >   Incremental build isn't picking back up where it left off/failed.  
> > > 
> > > Try this:
> > >    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
> > >    rm -rf /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516 
> > >    ./make-dist.py  
> > 
> > Will do.  I had planned to do something like this when I was awake this 
> > morning, but I was unsure just which files needed to be deleted.
> > 
> 
> It definitely got past odbc now.  But it stopped within ESC.  I was 
> surprised to find it her; I had thought the source code to be long lost.
> I don't see am error message except for the failure to find .M3EXPORTS, 
> ahich is probably something that cm3 should have generated.
> 
> The m3makefile 
> /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile
> seems to have trouble finding 
> /tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/pkg/prover/AMD64_LINUX/.M3EXPORTS
> which seems to me to be one level out in the source code.  Just what 
> determines the order that these things are to be compiled?  The 
> compilation log makes it look as if the outer one (prover) needed to be 
> compiled first, so as to enerate the .M3EXPORTS file, but that the inner 
> one (prover/test) actually got compiled first. 
> 
> Here's the output, starting with the first line of log contianing either 
> the words "Simplify" or "prover".
> 
> 
> == package /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test ==
> 
>  +++ /tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/bin/cm3    
> -build -DROOT=/farhome/hendrik/cm3/cm3 +++
> --- building in AMD64_LINUX ---
> 
> ignoring ../src/m3overrides
> 
> "/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile", line 
> 1: quake runtime error: unable to open 
> "/tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/pkg/prover/AMD64_LINUX/.M3EXPORTS" 
> for reading
> 
> --procedure--  -line-  -file---
> import             --  <builtin>
> include_dir         1  
> /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile
>                     5  
> /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/AMD64_LINUX/m3make.args
> 
> Fatal Error: package build failed
>  *** execution of [<function _BuildGlobalFunction at 0x10d0de8>, 
> <function _ShipFunction at 0x10d0c80>] failed ***
> hendrik at april:~/cm3/cm3/scripts/python$ exit
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/bca8ff44/attachment.html>

From hendrik at topoi.pooq.com  Fri May 18 03:17:34 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 17 May 2012 21:17:34 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <COL101-W47988370CD738A644D7366E6190@phx.gbl>
References: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
	<COL101-W47988370CD738A644D7366E6190@phx.gbl>
Message-ID: <20120518011734.GA735@topoi.pooq.com>

On Thu, May 17, 2012 at 11:29:16PM +0000, Jay K wrote:
> 
> I have not built the entire tree since that stuff came in.Oops.  

My saying this year seems to be "That which is not tested is broken".

> If the goal is to get some sort of .deb, to see what it is, to give it to someone else, do this:    cd scripts    rm PKGSDB    edit down pkginfo.txt     hm, oops, this stuff isn't in there?      The same information might be duplicated in pylib.py?   I think I fixed that..based on a quick read.       Maybe we pickup all m3makefiles? Maybe.    Just rm -rf from your tree anything that is giving you trouble now, as you've already built lots of stuff.     - Jay

That's the way to get ahead at this point, yes.

I will have to take a look at ESC sometime, though.  It looks like fun.  
This is the stuff that processes all the mutex comments in Trestle, 
right?

I really had thought it was long-lost code, never to be seen again.  Or 
has someone started writing it anew?

-- hendrik


From jay.krell at cornell.edu  Fri May 18 03:31:59 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 01:31:59 +0000
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518011734.GA735@topoi.pooq.com>
References: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>,
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>,
	<20120517014903.GA19546@topoi.pooq.com>,
	<20120517023533.GB19546@topoi.pooq.com>,
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>,
	<20120517154836.GA20605@topoi.pooq.com>,
	<20120517185753.GA5741@topoi.pooq.com>,
	<COL101-W47988370CD738A644D7366E6190@phx.gbl>,
	<20120518011734.GA735@topoi.pooq.com>
Message-ID: <COL101-W35FD639411DD4E2EF83685E61E0@phx.gbl>


> My saying this year seems to be "That which is not tested is broken".  In the face of any change, including the mere passage of time (e.g. y2k):   That which is not tested often and recently is probably broken.    Running automated tests daily, or at least in a loop that might take over a day, is how you know what is working.   I believe someone recently recovered the ESC stuff. Probably Olaf.   - Jay
 > Date: Thu, 17 May 2012 21:17:34 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] building packages from source from cvs -- odbc
> 
> On Thu, May 17, 2012 at 11:29:16PM +0000, Jay K wrote:
> > 
> > I have not built the entire tree since that stuff came in.Oops.  
> 
> My saying this year seems to be "That which is not tested is broken".
> 
> > If the goal is to get some sort of .deb, to see what it is, to give it to someone else, do this:    cd scripts    rm PKGSDB    edit down pkginfo.txt     hm, oops, this stuff isn't in there?      The same information might be duplicated in pylib.py?   I think I fixed that..based on a quick read.       Maybe we pickup all m3makefiles? Maybe.    Just rm -rf from your tree anything that is giving you trouble now, as you've already built lots of stuff.     - Jay
> 
> That's the way to get ahead at this point, yes.
> 
> I will have to take a look at ESC sometime, though.  It looks like fun.  
> This is the stuff that processes all the mutex comments in Trestle, 
> right?
> 
> I really had thought it was long-lost code, never to be seen again.  Or 
> has someone started writing it anew?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/b1685039/attachment.html>

From jay.krell at cornell.edu  Fri May 18 04:49:39 2012
From: jay.krell at cornell.edu (Jay)
Date: Thu, 17 May 2012 19:49:39 -0700
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <1337293645.96958.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <1337293645.96958.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <1301C8B3-DD12-46EE-BC17-0184E187A8A3@gmail.com>

I'm sorry Daniel, but almost all your emails make no sense or at best are just wrong.

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 17, 2012, at 3:27 PM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> if not then either that value doesn't sound as a machine value since the OS must care at least of constant values in memory (you can't allow values larger than what memory supports) or (whichever library they had created) is "their standard" , I don't think C standards are very precise, in fact, they are bad, who needs C standards, who created or thinks knows the standards.
> What the argot I would like to see are:
> Infinity values, epsilon, and  memory limits under such that limit values holds, that is, you can't represent epsilon with little value of memory.
> This would be the jargon of such libraries, instead they just make them a internal operation of their own calculation, which I can't trust, in summary this thing is unsound. Then the interface is UNSAFE for real which can't be a very standard thing by the way.
> Thanks in advance
> 
> --- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] C99 FloatMode stuff
> Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
> Fecha: jueves, 17 de mayo, 2012 13:46
> 
> No Daniel. 
> 
> 
> Date: Thu, 17 May 2012 17:18:52 +0100
> From: dabenavidesd at yahoo.es
> Subject: Re: [M3devel] C99 FloatMode stuff
> To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu
> 
> Hi all:
> I believe they are in system limits.h aren't they.
> BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
> Thanks in advance.
> 
> --- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] C99 FloatMode stuff
> Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
> Fecha: jueves, 17 de mayo, 2012 01:10
> 
> Mika, are FE_UNDERFLOW and such constants?
> Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
> see m3core/src/unix/Common/Uconstants.c
> 
> There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.
> 
>  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/46b853f6/attachment.html>

From jay.krell at cornell.edu  Fri May 18 09:38:15 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 07:38:15 +0000
Subject: [M3devel] uninitialized vs. init_var?
Message-ID: <COL101-W19D4C919EC527186CC9B70E61E0@phx.gbl>


This seems dubious, doesn't it, to state something is not initiallized, and then initialize it?
It triggers an assertion failure in gcc 4.6 backend.

RTCollector.m3

(479) declare_global name:null size:0X4000000(67108864) align:0X40(64) type:struct type_id:0x747D8491 exported:false initialized:false var:0x3B m3name:L_2
(14190) init_var offset:0X2280(8832) var:0x3B:L_2 0 one_field: offset:0x2280 size:0x20


Yes I realize it is initialized to zero.
I don't know if it is obviously initialized to all zeros, as I don't see the size in declare_global..er..rather, yes, there is a size there...is it real, or just some large guess..? I haven't looked..


I'm going to try this little hack:


M3CG_HANDLER (INIT_VAR)
{
  tree f = { 0 };
  tree v = { 0 };

#if GCC46
  if (DECL_COMMON (var))
  {
    if (option_trace_all)
      fprintf (stderr, " clearing DECL_COMMON on %s", m3_get_var_trace_name (var));
    DECL_COMMON (var) = false;
  }
#endif

  TREE_USED (var) = true;
  one_field (offset, POINTER_SIZE, t_addr, &f, &v);
  TREE_VALUE (v) = m3_build2 (POINTER_PLUS_EXPR, t_addr,
                              m3_build1 (ADDR_EXPR, t_addr, var),
                              size_int (b));
}

The assertion is in gcc-4.6/gcc/config/darwin.c

darwin_asm_output_aligned_decl_local

  /* .. and it should be suitable for placement in local mem.  */
  gcc_assert(!TREE_PUBLIC (decl) && !DECL_COMMON (decl));
  /* .. and any initializer must be all-zero.  */
  gcc_assert ((DECL_INITIAL (decl) == NULL) 
           || (DECL_INITIAL (decl) == error_mark_node) 
           || initializer_zerop (DECL_INITIAL (decl)));


The first one I think. I think it is common.


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/892b5595/attachment.html>

From dabenavidesd at yahoo.es  Fri May 18 17:36:40 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 18 May 2012 16:36:40 +0100 (BST)
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <1301C8B3-DD12-46EE-BC17-0184E187A8A3@gmail.com>
Message-ID: <1337355400.39333.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
The problem (and I don't think this for personal reasons, that I write at all), is as as Dr. Nelson rule of the thumb:
"If there is one paper about a problem, it has been solved, but If there are 100 papers it probably hasn't been solved"
Thanks in advance

--- El jue, 17/5/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] C99 FloatMode stuff
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: jueves, 17 de mayo, 2012 21:49

I'm sorry Daniel, but almost all your emails make no sense or at best are just wrong.
?- Jay (briefly/pocket-sized-computer-aka-phone)
On May 17, 2012, at 3:27 PM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
if not then either that value doesn't sound as a machine value since the OS must care at least of constant values in memory (you can't allow values larger than what memory supports) or (whichever library they had created) is "their standard" , I don't think C standards are very precise, in fact, they are bad, who needs C standards, who created or thinks knows the standards.
What the argot I would like to see are:
Infinity values, epsilon, and? memory limits under such that limit values holds, that is, you can't represent epsilon with little value of memory.
This would be the jargon of such libraries, instead they just make them a internal operation of their own calculation, which I can't trust, in summary this thing is unsound. Then the interface is UNSAFE for real which can't be a very standard thing by the way.
Thanks in
 advance

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] C99 FloatMode stuff
Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 13:46




No Daniel. 


Date: Thu, 17 May 2012 17:18:52 +0100
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] C99 FloatMode stuff
To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I believe they are in system limits.h aren't they.
BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
Thanks in advance.

--- El jue, 17/5/12, Jay K
 <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] C99 FloatMode stuff
Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 01:10




Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

?- Jay
 		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/265f116f/attachment.html>

From mika at async.caltech.edu  Fri May 18 18:28:56 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Fri, 18 May 2012 09:28:56 -0700
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl> 
References: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl>
Message-ID: <20120518162856.4B3BD1A205B@async.async.caltech.edu>

Jay,

Yes I think FE_OVERFLOW et al. are required to be macros that expand
to integer constants.  So yes..

    Mika

Jay K writes:
>--_9cde7264-29bf-49d4-826d-6091d2cdb722_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Mika=2C are FE_UNDERFLOW and such constants?
>Specifically=2C if so=2C we can implement them more efficiently=2C as const=
>ant data=2C instead of via functions.
>see m3core/src/unix/Common/Uconstants.c
>
>There is a certain elegant generality to using functions=2C but exposing co=
>nstant data should be /slightly/ more efficient.
>
> - Jay
> 		 	   		  =
>
>--_9cde7264-29bf-49d4-826d-6091d2cdb722_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Tahoma
>}
>--></style></head>
><body class=3D'hmmessage'><div dir=3D'ltr'>
>Mika=2C are FE_UNDERFLOW and such constants?<br>Specifically=2C if so=2C we=
> can implement them more efficiently=2C as constant data=2C instead of via =
>functions.<br>see m3core/src/unix/Common/Uconstants.c<br><br>There is a cer=
>tain elegant generality to using functions=2C but exposing constant data sh=
>ould be /slightly/ more efficient.<br><br>&nbsp=3B- Jay<br> 		 
>	   		  </di=
>v></body>
></html>=
>
>--_9cde7264-29bf-49d4-826d-6091d2cdb722_--


From hendrik at topoi.pooq.com  Fri May 18 18:34:10 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 12:34:10 -0400
Subject: [M3devel] packages for AMD64-LINUX stable.
In-Reply-To: <20120518011734.GA735@topoi.pooq.com>
References: <20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
	<COL101-W47988370CD738A644D7366E6190@phx.gbl>
	<20120518011734.GA735@topoi.pooq.com>
Message-ID: <20120518163410.GA28229@topoi.pooq.com>

On Thu, May 17, 2012 at 09:17:34PM -0400, Hendrik Boom wrote:
> On Thu, May 17, 2012 at 11:29:16PM +0000, Jay K wrote:
> > 
> > I have not built the entire tree since that stuff came in.Oops.  
> 
> My saying this year seems to be "That which is not tested is broken".
> 
> > If the goal is to get some sort of .deb, to see what it is, to give it to someone else, do this:    cd scripts    rm PKGSDB    edit down pkginfo.txt     hm, oops, this stuff isn't in there?      The same information might be duplicated in pylib.py?   I think I fixed that..based on a quick read.       Maybe we pickup all m3makefiles? Maybe.    Just rm -rf from your tree anything that is giving you trouble now, as you've already built lots of stuff.     - Jay
> 
> That's the way to get ahead at this point, yes.

I now have packages 

cm3-all-AMD64_LINUX-d5.9.0-20120518.deb
cm3-all-AMD64_LINUX-d5.9.0-20120518.tar.gz
cm3-min-AMD64_LINUX-d5.9.0-20120518
cm3-min-AMD64_LINUX-d5.9.0-20120518.tar.gz

and a few huge directories under /tmp.  I presume those huge directories
contain the files that were archived into these packages and that I can 
discard them.  Have all the executables in them been shipped?  Or should 
I delete /usr/local/cm3 and install the package?

Is the verion number right?  And will debian's package mamager collate 
it becode, for example, cm3-all-AMD64_LINUX-5.9.0 when it finally comes 
out?  If not, the right version number for Debian is probably something 
like 5.9.0~20120518 instead of d5.9.0-20120518 (note the tilde).  I'll 
look at the version-numbering stuff in the packaging manual and see if I 
draw any conclusions, and whether the version number that's in the file 
name has any relevance to the one the package manager uses.
And the binary package just might have to contain the AMD64_LINUX 
information in another form.

And, of course, I'll have to do a test install, because that which is 
not tested is broken.

If I get these things sorted out, it's probably ready to make available 
as a package that works on current debian stable, though it'll be a lot 
more work to get it to conform to all the debian packaging 
rules.

Oh, yes, the package leaves out ESC.  My guess is that the package 
builder builds its modules in the wrong order, presumably because it 
needs some clues that should be present in the ESC source directories 
but isn't.  Anyone know what information find-packages.sh and pkginfo.sh 
need to do the job properly?  How do these nested program direcoties 
work, anyway?

-- hendrik

> 
> I will have to take a look at ESC sometime, though.  It looks like fun.  
> This is the stuff that processes all the mutex comments in Trestle, 
> right?
> 
> I really had thought it was long-lost code, never to be seen again.  Or 
> has someone started writing it anew?
> 
> -- hendrik


From dragisha at m3w.org  Fri May 18 18:58:26 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 18 May 2012 18:58:26 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516223123.GA25611@topoi.pooq.com>
	<COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>
Message-ID: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>

One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.

On May 17, 2012, at 1:40 AM, Jay K wrote:

>   But heck, really, if we generate C, then targets largely drop away.  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/01be4ef6/attachment.html>

From mika at async.caltech.edu  Fri May 18 19:11:11 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Fri, 18 May 2012 10:11:11 -0700
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517185753.GA5741@topoi.pooq.com> 
References: <20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
Message-ID: <20120518171111.C803A1A205B@async.async.caltech.edu>

Hendrik Boom writes:
...
>It definitely got past odbc now.  But it stopped within ESC.  I was 
>surprised to find it her; I had thought the source code to be long lost.
...

It's not.  I was promised it and started to set up the directories but the
gentleman who promised me the code seems to have fallen off the earth.

    Mika


From dabenavidesd at yahoo.es  Fri May 18 19:16:59 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 18 May 2012 18:16:59 +0100 (BST)
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
Message-ID: <1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
After ESC we do need much debugger at all, in fact it was designed for that for avoiding put much time on it.
Still if we generate C is for super-optimization (but verified also mechanically), so I don't mind that, but for code quality I prefer C, I agree absolutely in that we should support it again for that purpose (as originally).
As for not verified code we should stick with C--, as it is written for that purposes, but for portability specially with implicit safety.
And for not verified nor optimal and not common use code (like mentor) we should make them source packages (in fact If they are written in Obliq we don't want to redistribute that as non-source), instead part of m3-demo package subdirectory or so.
I think for M3CG is that we need a LLVM or so back-end for JIT.
Thanks in advance

--- El vie, 18/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] LINUXLIBC6
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 18 de mayo, 2012 11:58

One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.
On May 17, 2012, at 1:40 AM, Jay K wrote:
??But heck, really, if we generate C, then targets largely drop away.??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/55302ae7/attachment.html>

From hendrik at topoi.pooq.com  Fri May 18 19:23:00 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 13:23:00 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518171111.C803A1A205B@async.async.caltech.edu>
References: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
	<20120518171111.C803A1A205B@async.async.caltech.edu>
Message-ID: <20120518172300.GA28507@topoi.pooq.com>

On Fri, May 18, 2012 at 10:11:11AM -0700, Mika Nystrom wrote:
> Hendrik Boom writes:
> ...
. I was surprised to find it here; I had thought the source code to be 
> long lost.
> ...
> 
> It's not.  I was promised it and started to set up the directories but the
> gentleman who promised me the code seems to have fallen off the earth.

So the ESC directory isn't ESC yet?  Did the gentleman send you some 
but not all of it? 

-- hendrik


From hendrik at topoi.pooq.com  Fri May 18 19:26:06 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 13:26:06 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516223123.GA25611@topoi.pooq.com>
	<COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>
	<F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
Message-ID: <20120518172606.GB28507@topoi.pooq.com>

On Fri, May 18, 2012 at 06:58:26PM +0200, Dragi?a Duri? wrote:
> One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.

It's possible to generate C code full of #line preprocessor commands, 
so that debuggers get references to the original source code, not the 
generated C code.  The variable names would possibly be obscure, 
though.

> 
> On May 17, 2012, at 1:40 AM, Jay K wrote:
> 
> >   But heck, really, if we generate C, then targets largely drop away.  
> 


From dabenavidesd at yahoo.es  Fri May 18 19:27:27 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 18 May 2012 18:27:27 +0100 (BST)
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518171111.C803A1A205B@async.async.caltech.edu>
Message-ID: <1337362047.35503.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
we should be more aware that today H-P annually from now will drop 30.000 jobs there in total, so I hope this can go on smoothly.
If not, we should ask them which projects made them release their source code on the last ancient Mobile OS.
Thanks in advance


--- El vie, 18/5/12, Mika Nystrom <mika at async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] building packages from source from cvs -- odbc
> Para: "Hendrik Boom" <hendrik at topoi.pooq.com>
> CC: m3devel at elegosoft.com
> Fecha: viernes, 18 de mayo, 2012 12:11
> Hendrik Boom writes:
> ...
> >It definitely got past odbc now.  But it stopped
> within ESC.  I was 
> >surprised to find it her; I had thought the source code
> to be long lost.
> ...
> 
> It's not.  I was promised it and started to set up the
> directories but the
> gentleman who promised me the code seems to have fallen off
> the earth.
> 
>     Mika
> 


From mika at async.caltech.edu  Fri May 18 20:03:30 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Fri, 18 May 2012 11:03:30 -0700
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518172300.GA28507@topoi.pooq.com> 
References: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
	<20120518171111.C803A1A205B@async.async.caltech.edu>
	<20120518172300.GA28507@topoi.pooq.com>
Message-ID: <20120518180330.4CDB21A205B@async.async.caltech.edu>

Hendrik Boom writes:
>On Fri, May 18, 2012 at 10:11:11AM -0700, Mika Nystrom wrote:
>> Hendrik Boom writes:
>> ...
>. I was surprised to find it here; I had thought the source code to be 
>> long lost.
>> ...
>> 
>> It's not.  I was promised it and started to set up the directories but the
>> gentleman who promised me the code seems to have fallen off the earth.
>
>So the ESC directory isn't ESC yet?  Did the gentleman send you some 
>but not all of it? 
>
>-- hendrik

What's in there is Simplify, which has been distributed with other projects
(specifically with ESC/Java).  It's also part of the original ESC.

     Mika


From jay.krell at cornell.edu  Fri May 18 21:23:24 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 19:23:24 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516223123.GA25611@topoi.pooq.com>
	<COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>,
	<F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
Message-ID: <COL101-W45E1537E67C2E81FC1A9C4E61E0@phx.gbl>


The debugging experience is already poor on systems that don't support stabs, e.g. Darwin, NT, HP-UX (maybe only certain processors therein). Also it requires building a custom gdb. Our gdb fork is old. Is anyone going to update it ever?#line directives will help.Stock gdb will be much more useful than it is today.But yes, it won't be great idiomatic Modula-3 debugging.   - Jay Subject: Re: [M3devel] LINUXLIBC6
From: dragisha at m3w.org
Date: Fri, 18 May 2012 18:58:26 +0200
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.
On May 17, 2012, at 1:40 AM, Jay K wrote:  But heck, really, if we generate C, then targets largely drop away.  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/74eeb691/attachment.html>

From jay.krell at cornell.edu  Fri May 18 21:49:44 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 19:49:44 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>,
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W1466668864A79F0C274528E61E0@phx.gbl>


C-- is not actively maintained I believe, so not a good idea to use.  C and C++ are much more portable and "maintained" (C++ gives us more portable efficient exception handling.)  (There is a good C and C++ compiler for every mainstream system in use today  LLVM isn't a bad idea, but there is more expertise out there (and in me) with C and C++, so C and C++ are easier to generate.It is a bit of a chore to learn and use.  JIT isn't a crazy idea either..or rather, an interpreter.If you look at parse.c..and you add a few thread locals..I think it's not hard to turn it into an interpreter.  (In reality you don't want to start with parse.c because of the GPL.)  And, interesting point as well, an interpreter in Java or C# or whatever is "more native" on e.g. Android and Windows Phone, is also not too difficult. You could do it in a low level fashion that is viable in "safe" environments.Search the web for "XML VM". I know it is nonsense term, but the project is/was real, despite the name, it is a viable approach.  What they did is this:  "convert" (i.e. dump faithfully and without optimization or fitting any uniform scheme) Java .class files and .NET IL into XML.  Write XML Style Sheets (XSL) to transform to whatever -- including JavaScript and C.  Write some supporting libraries.  As a result, they could "compile" Java to C and run on iPhone, "compile" Java to JavaScript and run in browser (Yes, I know about Google Web Toolkit.)    - Jay
 Date: Fri, 18 May 2012 18:16:59 +0100
From: dabenavidesd at yahoo.es
To: dragisha at m3w.org
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] LINUXLIBC6

Hi all:
After ESC we do need much debugger at all, in fact it was designed for that for avoiding put much time on it.
Still if we generate C is for super-optimization (but verified also mechanically), so I don't mind that, but for code quality I prefer C, I agree absolutely in that we should support it again for that purpose (as originally).
As for not verified code we should stick with C--, as it is written for that purposes, but for portability specially with implicit safety.
And for not verified nor optimal and not common use code (like mentor) we should make them source packages (in fact If they are written in Obliq we don't want to redistribute that as non-source), instead part of m3-demo package subdirectory or so.
I think for M3CG is that we need a LLVM or so back-end for JIT.
Thanks in advance

--- El vie, 18/5/12, Dragi?a
 Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] LINUXLIBC6
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 18 de mayo, 2012 11:58

One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.
On May 17, 2012, at 1:40 AM, Jay K wrote:  But heck, really, if we generate C, then targets largely drop away.  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/33fcf5fa/attachment.html>

From hendrik at topoi.pooq.com  Fri May 18 22:56:49 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 16:56:49 -0400
Subject: [M3devel] more Debian packages?
Message-ID: <20120518205649.GA26162@topoi.pooq.com>

Having succeeded at producing a binary .deb packages for Debian squeeze 
(though I still have to try it out), I'm now looking at my other 
machines.  I have a 32-bit Intel machine with wheeze (testing), and one 
that can run squeeze (stable).  All of them have access to the same 
NFS-mounted source tree.  Is it practical to use the same tree for two 
different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
be kept separate?  Or do I need to clean it out or copy it?

(by the way, I expect making packages for different Debian releases on 
the same hardware architecture will require a new source tree, or a 
cleaned-out one.  In my case they'll both be LINUXLIBC6)

-- hendrik



From jay.krell at cornell.edu  Fri May 18 23:50:24 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 21:50:24 +0000
Subject: [M3devel] more Debian packages?
In-Reply-To: <20120518205649.GA26162@topoi.pooq.com>
References: <20120518205649.GA26162@topoi.pooq.com>
Message-ID: <COL101-W81D30A014D472E089333EE61E0@phx.gbl>


Yes and yes.LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.  Please try to use I386_LINUX.I really want to stop this LINUXLIBC6 stuff...   You can share the source. But we also have outputs in the source tree (unfortunately!).    You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...   Do this to switch:  ./do-cm3-all.py realclean   - Jay
 > Date: Fri, 18 May 2012 16:56:49 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] more Debian packages?
> 
> Having succeeded at producing a binary .deb packages for Debian squeeze 
> (though I still have to try it out), I'm now looking at my other 
> machines.  I have a 32-bit Intel machine with wheeze (testing), and one 
> that can run squeeze (stable).  All of them have access to the same 
> NFS-mounted source tree.  Is it practical to use the same tree for two 
> different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> be kept separate?  Or do I need to clean it out or copy it?
> 
> (by the way, I expect making packages for different Debian releases on 
> the same hardware architecture will require a new source tree, or a 
> cleaned-out one.  In my case they'll both be LINUXLIBC6)
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/93b0a19f/attachment.html>

From hendrik at topoi.pooq.com  Sat May 19 01:29:59 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 19:29:59 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
References: <20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
Message-ID: <20120518232959.GB26422@topoi.pooq.com>

On Thu, May 17, 2012 at 06:01:19AM +0000, Jay K wrote:
> 
> Note also, I think it is obvious, but I wrote make-dist.py to always package up everything possible
> for the target platform. So it is up to you as the "builder" to have all the dependencies already installed.
> It isn't great.
> I don't believe there is a perfect option here.
> Another release form we have yields a bunch of per-target packages.
> I find that confusing -- too many.
> My form yields just one largeish per-target package.
> Over-size, monolithic, but simpler, less choices to confuse people.

Debian splits things up a lot more, and has explicit package-dependencies.

There's usually an omnibus package the depends on all the others, for 
the simple souls who just want everything.  Sometimes they are amazed 
how much everything entails.  More often the don't notice.  I, for 
example, got a complete set of video drivers for just about every 
video card ever made, as a result of installing one package I was 
actually interested in.  Threatening to take one out (I didn't have 
that card) resulted in aptitude trying to remove my window manager.  
Clearly a poor situation.  But that's what an all-inclusive policy can 
cause.

In addition, there's a main package that contains everything you just 
couldn't do without, and you have to add other packages as you need 
them.  For the video situation above, the user could take this approach, 
but it would require him to know just what hardware he had in his 
machine.  Most users don't know this and don't care to find out.

So applying this philosophy to Modula 3, it would probably end up 
split up at least as much as the multipackage offering on the download 
site.  And these packages would have dependencies on one another, so 
you wouldn't end up installing one without its prerequisites.

One package would clearly be the compiler and its minimal run-time 
system.

Others would provide applications and libraries.

And each libraries would be split further -- one package (perhaps 
called foo) that provides what you need to run a program using it, and 
another (foo-dev) that provides what you need to cmopile a program 
that needs it.  THer are interested in making the disk requirements 
of a Debian system as small as possible.  Even in C, if you aren't 
going to use a library for developmentt, you can get rid of a lot of 
h-files.

It's quite possible for one source package to generate several binary 
packages, by the way.

---

The other thing that separates our packages from ordinary, official 
Debian packages it that ours install everything to one place in the 
file system, and Debian follows a standard tthat spreads it all over 
the place.

I'd have to learn and do a lot to get something acceptable to Debian.  
I certianly won't get it all done by the expected wheezy freeze in a 
few months, and, other things being important too, I may not get 
around to it at all.

-- hendrik 

> 
> 
> Of course ultimately we don't want per-target stuff at all. :)
> Or at least we want both "source" and "binary" distributions.

-- hendrik

> 
> 
> Still I am confused.
> Don't people have binary distributions of programs with GUIs for Linux?
> Like Komodo IDE, Komodo Edit, Acrobat Reader?
> 
> 
> Maybe we should really have a java-generating backend...one binary distribution for all..and a better Android story?
> I know, there is a funny tradeoff here. Modula-3 is kind of lower-level than Java.
> You'd want such a backend/port to throw out our garbage collector..and heck..all unsafe code....
>  (or generate C for those and use JNI or such...interesting..theoretically possible..unlikely to happen..)
> 
> 
>  - Jay
> 
> 
> > Date: Wed, 16 May 2012 22:35:33 -0400
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] building packages from source from cvs -- odbc
> > 
> > On Wed, May 16, 2012 at 09:49:03PM -0400, Hendrik Boom wrote:
> > > On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> > > > 
> > > >      > *** LIBRARY_PATH shouldn't contain the current directory when  
> > > >      > *** building gcc. Please change the environment variable  
> > > >      > *** and run configure again.  
> > > >     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
> > > >   :/usr/local/Gambit-C/lib  
> > > >  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  
> > > 
> > > Yes, emptying LIBRARY_PATH enabled uprade.py to complete successfully.
> > > Thanks.  It would have taken me many ages to figure this out.
> > > 
> > > -- hendrik
> > > 
> > Now I'm onto ./make-dist.py
> > 
> > It fails in teh data base stuff.
> > 
> > First becaues it didn't have libodbc.  So I installed package unixodbc.
> > But then:
> > 
> > == package /farhome/hendrik/cm3/cm3/m3-db/odbc ==
> > 
> >  +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3    -build -DROOT=/farhome/hendrik/cm3/cm3 +++
> > --- building in AMD64_LINUX ---
> > 
> > ignoring ../src/m3overrides
> > 
> >  ==> /farhome/hendrik/cm3/cm3/m3-db/odbc done
> > 
> >  +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3  -ship -DROOT=/farhome/hendrik/cm3/cm3 +++
> > --- shipping from AMD64_LINUX ---
> > 
> > . => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> >   .M3EXPORTS      
> > . => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib
> >   libm3odbc.so.5  "/farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP", line 4: quake runtime error: unable to copy "libm3odbc.so.5" to "/tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib/libm3odbc.so.5": errno=2
> > 
> > --procedure--  -line-  -file---
> > install_file       --  <builtin>
> >                     4  /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP
> > 
> > Fatal Error: package build failed
> >  *** execution of [<function _BuildGlobalFunction at 0x1a56de8>, <function _ShipFunction at 0x1a56c80>] failed ***
> > hendrik at april:~/cm3/cm3/scripts/python$ 
> > 
> > 
> > It doesn't seem to build libm3odbc.so.5
> > 
> > hendrik at april:~/cm3/cm3/m3-db/odbc$ ls AMD64_LINUX/
> > libm3odbc.a    libm3odbc.so  SQLext.mo  SQLtypes.io
> > libm3odbc.m3x  SQLext.io     SQL.io
> > hendrik at april:~/cm3/cm3/m3-db/odbc$ 
> > 
> > There's nothing at all in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> > There are lots of files in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib,
> > but nothing resembling libm3odbc>
> > 
> > -- hendrik
> > 
> > 
>  		 	   		  


From dabenavidesd at yahoo.es  Sat May 19 16:38:48 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 19 May 2012 15:38:48 +0100 (BST)
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518232959.GB26422@topoi.pooq.com>
Message-ID: <1337438328.39377.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
if the .deb package doesn't overrides another location or content of .io files in another .deb then it shouldn't go inside the same PKG_ROOT but just as is any other non-Modula3 built library. But if they are, they should go to cm3 paths because you could require to re-link and generate updated packages from a specific location you choose from deb-src.
Something akin linux modules and kernel, if you compile a new module you need to rebuild against the kernel (isn't like that) to re-link and use. Normally this modules are just libraries and kernel is just compiled in very old stable kernels. That's what I learned from Ubuntu.
Thanks in advance 

--- El vie, 18/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] building packages from source from cvs -- odbc
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 18 de mayo, 2012 18:29
> On Thu, May 17, 2012 at 06:01:19AM
> +0000, Jay K wrote:
> > 
> > Note also, I think it is obvious, but I wrote
> make-dist.py to always package up everything possible
> > for the target platform. So it is up to you as the
> "builder" to have all the dependencies already installed.
> > It isn't great.
> > I don't believe there is a perfect option here.
> > Another release form we have yields a bunch of
> per-target packages.
> > I find that confusing -- too many.
> > My form yields just one largeish per-target package.
> > Over-size, monolithic, but simpler, less choices to
> confuse people.
> 
> Debian splits things up a lot more, and has explicit
> package-dependencies.
> 
> There's usually an omnibus package the depends on all the
> others, for 
> the simple souls who just want everything.  Sometimes
> they are amazed 
> how much everything entails.  More often the don't
> notice.  I, for 
> example, got a complete set of video drivers for just about
> every 
> video card ever made, as a result of installing one package
> I was 
> actually interested in.  Threatening to take one out (I
> didn't have 
> that card) resulted in aptitude trying to remove my window
> manager.  
> Clearly a poor situation.  But that's what an
> all-inclusive policy can 
> cause.
> 
> In addition, there's a main package that contains everything
> you just 
> couldn't do without, and you have to add other packages as
> you need 
> them.  For the video situation above, the user could
> take this approach, 
> but it would require him to know just what hardware he had
> in his 
> machine.  Most users don't know this and don't care to
> find out.
> 
> So applying this philosophy to Modula 3, it would probably
> end up 
> split up at least as much as the multipackage offering on
> the download 
> site.  And these packages would have dependencies on
> one another, so 
> you wouldn't end up installing one without its
> prerequisites.
> 
> One package would clearly be the compiler and its minimal
> run-time 
> system.
> 
> Others would provide applications and libraries.
> 
> And each libraries would be split further -- one package
> (perhaps 
> called foo) that provides what you need to run a program
> using it, and 
> another (foo-dev) that provides what you need to cmopile a
> program 
> that needs it.  THer are interested in making the disk
> requirements 
> of a Debian system as small as possible.  Even in C, if
> you aren't 
> going to use a library for developmentt, you can get rid of
> a lot of 
> h-files.
> 
> It's quite possible for one source package to generate
> several binary 
> packages, by the way.
> 
> ---
> 
> The other thing that separates our packages from ordinary,
> official 
> Debian packages it that ours install everything to one place
> in the 
> file system, and Debian follows a standard tthat spreads it
> all over 
> the place.
> 
> I'd have to learn and do a lot to get something acceptable
> to Debian.  
> I certianly won't get it all done by the expected wheezy
> freeze in a 
> few months, and, other things being important too, I may not
> get 
> around to it at all.
> 
> -- hendrik 
> 
> > 
> > 
> > Of course ultimately we don't want per-target stuff at
> all. :)
> > Or at least we want both "source" and "binary"
> distributions.
> 
> -- hendrik
> 
> > 
> > 
> > Still I am confused.
> > Don't people have binary distributions of programs with
> GUIs for Linux?
> > Like Komodo IDE, Komodo Edit, Acrobat Reader?
> > 
> > 
> > Maybe we should really have a java-generating
> backend...one binary distribution for all..and a better
> Android story?
> > I know, there is a funny tradeoff here. Modula-3 is
> kind of lower-level than Java.
> > You'd want such a backend/port to throw out our garbage
> collector..and heck..all unsafe code....
> >  (or generate C for those and use JNI or
> such...interesting..theoretically possible..unlikely to
> happen..)
> > 
> > 
> >  - Jay
> > 
> > 
> > > Date: Wed, 16 May 2012 22:35:33 -0400
> > > From: hendrik at topoi.pooq.com
> > > To: m3devel at elegosoft.com
> > > Subject: Re: [M3devel] building packages from
> source from cvs -- odbc
> > > 
> > > On Wed, May 16, 2012 at 09:49:03PM -0400, Hendrik
> Boom wrote:
> > > > On Thu, May 17, 2012 at 12:06:00AM +0000, Jay
> K wrote:
> > > > > 
> > > > >      > ***
> LIBRARY_PATH shouldn't contain the current directory
> when  
> > > > >      > *** building
> gcc. Please change the environment variable  
> > > > >      > *** and run
> configure again.  
> > > > > 
>    hendrik at april:~/cm3/cm3/scripts/python$
> echo $LIBRARY_PATH  
> > > >
> >   :/usr/local/Gambit-C/lib  
> > > > >  Please either clear the variable,
> or at least remove the leading :.The leading : makes there
> be an empty entry, which is interpreted as current
> directory, which is dangerous and fragile. I think.This is a
> local problem on your machine. Easily
> fixed.   It might be reasonable for us to
> clear it in m3cc/src/m3makefile.   - Jay
>    
>         
>           
>   
> > > > 
> > > > Yes, emptying LIBRARY_PATH enabled uprade.py
> to complete successfully.
> > > > Thanks.  It would have taken me many
> ages to figure this out.
> > > > 
> > > > -- hendrik
> > > > 
> > > Now I'm onto ./make-dist.py
> > > 
> > > It fails in teh data base stuff.
> > > 
> > > First becaues it didn't have libodbc.  So I
> installed package unixodbc.
> > > But then:
> > > 
> > > == package /farhome/hendrik/cm3/cm3/m3-db/odbc ==
> > > 
> > >  +++
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3 
>   -build -DROOT=/farhome/hendrik/cm3/cm3 +++
> > > --- building in AMD64_LINUX ---
> > > 
> > > ignoring ../src/m3overrides
> > > 
> > >  ==> /farhome/hendrik/cm3/cm3/m3-db/odbc
> done
> > > 
> > >  +++
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3 
> -ship -DROOT=/farhome/hendrik/cm3/cm3 +++
> > > --- shipping from AMD64_LINUX ---
> > > 
> > > . =>
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> > >   .M3EXPORTS      
> > > . =>
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib
> > >   libm3odbc.so.5 
> "/farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP",
> line 4: quake runtime error: unable to copy "libm3odbc.so.5"
> to
> "/tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib/libm3odbc.so.5":
> errno=2
> > > 
> > > --procedure--  -line-  -file---
> > > install_file   
>    --  <builtin>
> > >             
>        4 
> /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP
> > > 
> > > Fatal Error: package build failed
> > >  *** execution of [<function
> _BuildGlobalFunction at 0x1a56de8>, <function
> _ShipFunction at 0x1a56c80>] failed ***
> > > hendrik at april:~/cm3/cm3/scripts/python$ 
> > > 
> > > 
> > > It doesn't seem to build libm3odbc.so.5
> > > 
> > > hendrik at april:~/cm3/cm3/m3-db/odbc$ ls
> AMD64_LINUX/
> > > libm3odbc.a    libm3odbc.so 
> SQLext.mo  SQLtypes.io
> > > libm3odbc.m3x  SQLext.io 
>    SQL.io
> > > hendrik at april:~/cm3/cm3/m3-db/odbc$ 
> > > 
> > > There's nothing at all in
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> > > There are lots of files in
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib,
> > > but nothing resembling libm3odbc>
> > > 
> > > -- hendrik
> > > 
> > > 
> >     
>         
>           
>   
> 


From dabenavidesd at yahoo.es  Sat May 19 18:41:03 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 19 May 2012 17:41:03 +0100 (BST)
Subject: [M3devel] building packages from source from cvs -- odbc
Message-ID: <1337445663.91287.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
there seems to be a relation between Modula-3 GUI INTERFACE specification of a pen-handling UI that allowed to type letters from uni-strokes:
http://www.leagle.com/xmlResult.aspx?page=11&xmldoc=2001481198FSupp2d283_1453.xml&docbase=CSLWAR2-1986-2006&SizeDisp=7

3com argued that the Modula-3's XEROX Patent wasn't infringed since the OS hadn't specified that functionality but settled the case with a money deal and a 7-year peace deal over mutual patents from 3com:
http://findarticles.com/p/articles/mi_m0EIN/is_2006_June_28/ai_n26909742/

Now that next year deal will be over they might be interested in pursuing another set of questions over XEROX's OS using Modula-3 code in ESC (because they would still need to proof full-integrity of Modula-3 ESC tool) and libraries use by XEROX OS:
http://www.google.com/patents/US5596656

I think we could ask if they want to litigate over the XEROX' OS again.
Thanks in advance

--- El vie, 18/5/12, Mika Nystrom <mika at async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] building packages from source from cvs -- odbc
> Para: "Hendrik Boom" <hendrik at topoi.pooq.com>
> CC: m3devel at elegosoft.com
> Fecha: viernes, 18 de mayo, 2012 13:03
> Hendrik Boom writes:
> >On Fri, May 18, 2012 at 10:11:11AM -0700, Mika Nystrom
> wrote:
> >> Hendrik Boom writes:
> >> ...
> >. I was surprised to find it here; I had thought the
> source code to be 
> >> long lost.
> >> ...
> >> 
> >> It's not.  I was promised it and started to
> set up the directories but the
> >> gentleman who promised me the code seems to have
> fallen off the earth.
> >
> >So the ESC directory isn't ESC yet?  Did the
> gentleman send you some 
> >but not all of it? 
> >
> >-- hendrik
> 
> What's in there is Simplify, which has been distributed with
> other projects
> (specifically with ESC/Java).  It's also part of the
> original ESC.
> 
>      Mika
>




From dabenavidesd at yahoo.es  Sat May 19 20:32:10 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 19 May 2012 19:32:10 +0100 (BST)
Subject: [M3devel] more Debian packages?
In-Reply-To: <COL101-W81D30A014D472E089333EE61E0@phx.gbl>
Message-ID: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:

?I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,

for instance to allow and or LINUX_I8086, etc LINUX_I387 

For VAXen computers:

VMS_VAX__

for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11

Alpha's: OSF_ALPHA

For Unixes:

FBSD-GENERIC_I_86___--

To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64

Also could be managed by Manufacturer Model code-name, like

DEC_AQUARIUS or DEC_10000.



Also if we are gonna take macro assembly for cross-platform distributions then, we would need? something akin:

NT_XASM-I_86___

So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)

This would allow to compile CVSup at least is what one would like to
Thanks in advance

 --- El vie, 18/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] more Debian packages?
Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 18 de mayo, 2012 16:50




Yes and yes.
LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.
But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.
?
?
Please try to use I386_LINUX.
I really want to stop this LINUXLIBC6 stuff...
?
?
?You can share the source.
?But we also have outputs in the source tree (unfortunately!).
??? You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...
?
?
?Do this to switch:
?
?./do-cm3-all.py realclean 
?
?- Jay
?
> Date: Fri, 18 May 2012 16:56:49 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] more Debian packages?
> 
> Having succeeded at producing a binary .deb packages for Debian squeeze 
> (though I still have to try it out), I'm now looking at my other 
> machines.  I have a 32-bit Intel machine with wheeze (testing), and one 
> that can run squeeze (stable).  All of them have access to the same 
> NFS-mounted source tree.  Is it practical to use the same tree for two 
> different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> be kept separate?  Or do I need to clean it out or copy it?
> 
> (by the way, I expect making packages for different Debian releases on 
> the same hardware architecture will require a new source tree, or a 
> cleaned-out one.  In my case they'll both be LINUXLIBC6)
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120519/5c7b0dfb/attachment.html>

From peter.mckinna at gmail.com  Sun May 20 02:48:08 2012
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Sun, 20 May 2012 10:48:08 +1000
Subject: [M3devel] Linker override
Message-ID: <CAEy6uxqLdrGOydLBc=QgeB7Z5ZswOdYrsZL62D0i+cKC-9p9jw@mail.gmail.com>

Hi,

  I have had to override the default linker in my m3makefile to the
C++ linker to link
against a C++ library as in

SYSTEM_LD = "g++ -gstabs+ -m64 -fPIC -mno-align-double"

is there a more portable way to do this? I'm sure it wont work on windows!!

Peter


From jay.krell at cornell.edu  Sun May 20 03:31:16 2012
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 May 2012 01:31:16 +0000
Subject: [M3devel] Linker override
In-Reply-To: <CAEy6uxqLdrGOydLBc=QgeB7Z5ZswOdYrsZL62D0i+cKC-9p9jw@mail.gmail.com>
References: <CAEy6uxqLdrGOydLBc=QgeB7Z5ZswOdYrsZL62D0i+cKC-9p9jw@mail.gmail.com>
Message-ID: <COL101-W6496D86AAFB9672E062B10E61C0@phx.gbl>


I don't know what is the ideal design here.

Of course you can easily skip the code on Windows:

if equal(OS_TYPE, "POSIX")
? SYSTEM_LD = "g++ -gstabs+ -m64 -fPIC -mno-align-double"
end

There is no gcc vs. g++ analog on Windows. Good.

I know we could hack and slash at it gradually:

m3makefile:
?USE_GPLUSPLUS = TRUE? ?
?USE_CPLUSPLUS_LINKER = TRUE ?
?USE_CPLUSPLUS = TRUE ?


and then check that wherever in the config files.


There is a need for some sort of modularity / additivity here.
But I don't know what the design and interface should look like.

Most likely this notion of "use cplusplus" needs to be unioned across all libraries being linked together.


?- Jay




----------------------------------------
> Date: Sun, 20 May 2012 10:48:08 +1000
> From: peter.mckinna at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Linker override
>
> Hi,
>
> I have had to override the default linker in my m3makefile to the
> C++ linker to link
> against a C++ library as in
>
> SYSTEM_LD = "g++ -gstabs+ -m64 -fPIC -mno-align-double"
>
> is there a more portable way to do this? I'm sure it wont work on windows!!
>
> Peter
 		 	   		  

From dragisha at m3w.org  Sun May 20 22:09:46 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 20 May 2012 22:09:46 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <20120518172606.GB28507@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516223123.GA25611@topoi.pooq.com>
	<COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>
	<F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<20120518172606.GB28507@topoi.pooq.com>
Message-ID: <DE38D246-53B8-4105-9281-BC395B2E7920@m3w.org>


On May 18, 2012, at 7:26 PM, Hendrik Boom wrote:

> On Fri, May 18, 2012 at 06:58:26PM +0200, Dragi?a Duri? wrote:
>> One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.
> 
> It's possible to generate C code full of #line preprocessor commands, 
> so that debuggers get references to the original source code, not the 
> generated C code.  The variable names would possibly be obscure, 
> though.
> 
Exactly.

>> 
>> On May 17, 2012, at 1:40 AM, Jay K wrote:
>> 
>>>  But heck, really, if we generate C, then targets largely drop away.  
>> 



From dragisha at m3w.org  Sun May 20 22:11:39 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 20 May 2012 22:11:39 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W1466668864A79F0C274528E61E0@phx.gbl>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>,
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
Message-ID: <B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>


On May 18, 2012, at 9:49 PM, Jay K wrote:

> LLVM isn't a bad idea, but there is more expertise out there (and in me) with C and C++, so C and C++ are easier to generate.
> It is a bit of a chore to learn and use.
>  
>  
> JIT isn't a crazy idea either..or rather, an interpreter.
> If you look at parse.c..and you add a few thread locals..I think it's not hard to turn it into an interpreter.
>   (In reality you don't want to start with parse.c because of the GPL.)

LLVM and JIT are close enough. You do LLVM, you get JIT.

Also, for debugging we need DWARF. Not incompatible with LLVM. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/6048caf8/attachment.html>

From jay.krell at cornell.edu  Sun May 20 23:28:27 2012
From: jay.krell at cornell.edu (Jay)
Date: Sun, 20 May 2012 14:28:27 -0700
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
Message-ID: <7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>

For dwarf et al: there "nothing" to it: "just" generate reasonable "code" (LLVM whatever, gcc "tree", C, etc) and the next level down handles it. Er, but for some bigger & smaller problems. 


Currently cm3cg -g for dwarf crashes. That is a small problem actually. But even if fixed, not a good experience -- no type information.


Larger "problem" & "good thing" is that the "front end" is more of a compiler than you might expect. It does "low level" things like "layout" and generates "variable plus offset" references "instead of" "field accesses".


That isn't necessarily bad. It is why/how we get away with giving gcc so little type information though.
And it might otherwise hurt debugging.


But ok. I have some ideas & plans, & some procrastination-enabling diversions.


 1. Update to gcc 4.6. Making good progress recently. This buys nothing. Procrastination.
 2. Update to gcc 4.7. Ditto.


Then there are a few more valuable things to get on to.


A. Better type info for gcc, so stock gdb much more useful. I'll probably NOT do this.


B. Use LLVM. I probably won't. But if there is a C-backend, then maybe, as that accomplishes two things at once (newer?better?cleaner?faster backend, portable C distribution)


C. Remove jmpbuf size knowledge from front end.
C.1 and maybe word size
C.2 and maybe endian
I.e. remove target dependentness


D. cooperative suspend 
i.e. again drastically increase portability


E. A C-generating backend.


The idea is, if these are all done, the system becomes "automatically" portable to "all" systems, with a pretty broad definition of "all": having a C?C++ compiler, being Posix but not too fancy (pthreads/open/read/write/close/send/recv/fork/exec, but nothing signal/semaphore related nor extensions to direct suspend threads or get stack pointer), or Win32, and optionally X Windows. 
At that point, time permitting, I might try again AIX, OpenVMS, Irix, iPhone/iPad, etc.


The remaining nagging portability concerns would be just: systems without public C compiler (windows phone, browser), and getting the second stack pointer on Itanium.


AT that point, if we ever get there, backends targeting Java, C#, JavaScript become maybe interesting (threads in JavaScript??). & the project could be considered very much more done. Maybe write other integrated backends, or linker, or target kernel interfaces instead of libc (esp. regarding threads on Linux)


Other projects at that time could include better interop between C, C++, and Modula-3. I'd like to see an end to fragile hand-written interop.


It'd also be good to move Trestle to the new X C bindings (xcb?).


I need to go back & explain something. Normally gcc compilers don't know anything about debug formats: stabs, coff, dwarf, etc. The reason cm3cg is different because what it does is mostly ignore all debugging infrastructure and generate its own custom information, for consumption by associated custom code in m3gdb. It just uses stabs as container or transport, for arbitrary data.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 20, 2012, at 1:11 PM, Dragi?a Duri? <dragisha at m3w.org> wrote:

> 
> On May 18, 2012, at 9:49 PM, Jay K wrote:
> 
>> LLVM isn't a bad idea, but there is more expertise out there (and in me) with C and C++, so C and C++ are easier to generate.
>> It is a bit of a chore to learn and use.
>>  
>>  
>> JIT isn't a crazy idea either..or rather, an interpreter.
>> If you look at parse.c..and you add a few thread locals..I think it's not hard to turn it into an interpreter.
>>   (In reality you don't want to start with parse.c because of the GPL.)
> 
> LLVM and JIT are close enough. You do LLVM, you get JIT.
> 
> Also, for debugging we need DWARF. Not incompatible with LLVM. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/57a5410d/attachment.html>

From jay.krell at cornell.edu  Sun May 20 23:34:20 2012
From: jay.krell at cornell.edu (Jay)
Date: Sun, 20 May 2012 14:34:20 -0700
Subject: [M3devel] more Debian packages?
In-Reply-To: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>
References: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>
Message-ID: <05B9609B-9A70-405A-9A59-4D3896AAD28F@gmail.com>

No Daniel. 

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 19, 2012, at 11:32 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
>  I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,
> for instance to allow and or LINUX_I8086, etc LINUX_I387 
> For VAXen computers:
> VMS_VAX__
> for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11
> Alpha's: OSF_ALPHA
> For Unixes:
> FBSD-GENERIC_I_86___--
> To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64
> Also could be managed by Manufacturer Model code-name, like
> DEC_AQUARIUS or DEC_10000.
> 
> Also if we are gonna take macro assembly for cross-platform distributions then, we would need  something akin:
> NT_XASM-I_86___
> So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)
> 
> This would allow to compile CVSup at least is what one would like to
> Thanks in advance
> 
> --- El vie, 18/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] more Debian packages?
> Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 18 de mayo, 2012 16:50
> 
> Yes and yes.
> LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.
> But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.
>  
>  
> Please try to use I386_LINUX.
> I really want to stop this LINUXLIBC6 stuff...
>  
>  
>  You can share the source.
>  But we also have outputs in the source tree (unfortunately!).
>     You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...
>  
>  
>  Do this to switch:
>  
>  ./do-cm3-all.py realclean 
>  
>  - Jay
>  
> > Date: Fri, 18 May 2012 16:56:49 -0400
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] more Debian packages?
> > 
> > Having succeeded at producing a binary .deb packages for Debian squeeze 
> > (though I still have to try it out), I'm now looking at my other 
> > machines. I have a 32-bit Intel machine with wheeze (testing), and one 
> > that can run squeeze (stable). All of them have access to the same 
> > NFS-mounted source tree. Is it practical to use the same tree for two 
> > different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> > be kept separate? Or do I need to clean it out or copy it?
> > 
> > (by the way, I expect making packages for different Debian releases on 
> > the same hardware architecture will require a new source tree, or a 
> > cleaned-out one. In my case they'll both be LINUXLIBC6)
> > 
> > -- hendrik
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/9edf6c44/attachment.html>

From jay.krell at cornell.edu  Sun May 20 23:32:14 2012
From: jay.krell at cornell.edu (Jay)
Date: Sun, 20 May 2012 14:32:14 -0700
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
Message-ID: <C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>

I meant "gcc frontends", which Modula-3 is structured as, in a somewhat backward-seeming way.


Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 20, 2012, at 2:28 PM, Jay <jay.krell at cornell.edu> wrote:

> Normally gcc compilers


From jay.krell at cornell.edu  Sun May 20 23:43:52 2012
From: jay.krell at cornell.edu (Jay)
Date: Sun, 20 May 2012 14:43:52 -0700
Subject: [M3devel] more Debian packages?
In-Reply-To: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>
References: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>
Message-ID: <B05C5D37-CAE3-4271-80EF-EBB2627444D4@gmail.com>

No no no.
We will not have an explosion of targets like this. We hopefully will have a drastic reduction.
Processor: C or C++
Threads: pthreads or Win32 or maybe ucontext or setjmp
GUI: X Windows or Win32 or none or maybe other
Suspension: cooperative and probably no other


If the right level of #ifdef and/or autoconf and/or libtool use can makes its way into the "object code", maybe just target completely. (imagine one C source distribution for ALL targets and what that requires).
We have rather replaced autoconf & libtool with our carefully researched & written quake code, for better & worse & I am torn as to if this is a good thing. Autoconf & libtool are slow & obscure but ubiquitous, get the job done, are actively maintained by others.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 19, 2012, at 11:32 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
>  I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,
> for instance to allow and or LINUX_I8086, etc LINUX_I387 
> For VAXen computers:
> VMS_VAX__
> for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11
> Alpha's: OSF_ALPHA
> For Unixes:
> FBSD-GENERIC_I_86___--
> To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64
> Also could be managed by Manufacturer Model code-name, like
> DEC_AQUARIUS or DEC_10000.
> 
> Also if we are gonna take macro assembly for cross-platform distributions then, we would need  something akin:
> NT_XASM-I_86___
> So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)
> 
> This would allow to compile CVSup at least is what one would like to
> Thanks in advance
> 
> --- El vie, 18/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] more Debian packages?
> Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 18 de mayo, 2012 16:50
> 
> Yes and yes.
> LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.
> But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.
>  
>  
> Please try to use I386_LINUX.
> I really want to stop this LINUXLIBC6 stuff...
>  
>  
>  You can share the source.
>  But we also have outputs in the source tree (unfortunately!).
>     You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...
>  
>  
>  Do this to switch:
>  
>  ./do-cm3-all.py realclean 
>  
>  - Jay
>  
> > Date: Fri, 18 May 2012 16:56:49 -0400
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] more Debian packages?
> > 
> > Having succeeded at producing a binary .deb packages for Debian squeeze 
> > (though I still have to try it out), I'm now looking at my other 
> > machines. I have a 32-bit Intel machine with wheeze (testing), and one 
> > that can run squeeze (stable). All of them have access to the same 
> > NFS-mounted source tree. Is it practical to use the same tree for two 
> > different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> > be kept separate? Or do I need to clean it out or copy it?
> > 
> > (by the way, I expect making packages for different Debian releases on 
> > the same hardware architecture will require a new source tree, or a 
> > cleaned-out one. In my case they'll both be LINUXLIBC6)
> > 
> > -- hendrik
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/5fe49c86/attachment.html>

From dabenavidesd at yahoo.es  Mon May 21 01:25:38 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 21 May 2012 00:25:38 +0100 (BST)
Subject: [M3devel] more Debian packages?
In-Reply-To: <B05C5D37-CAE3-4271-80EF-EBB2627444D4@gmail.com>
Message-ID: <1337556338.98126.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I got your point, but even after that the need for product-quality inter-opeartion with C code, specially, because everything else in the market is C, is desperately needed, we don't have some framework to actually using code from C-RT as is. I know DEC somehow lacked more effort towards producing for us that, although C interoperability was very good, they studied the problem for C and Modula-3, which is nice, and also I think they worked in their GEM compiler for Fortran, Cobol, C, .. so they should used basic concepts like 'program cell' for those compilers.
That said I know of an incremental code generator and linker for typeful programming languages for database machines, so I know producing some compiler target wouldn't be hard so much work like currently we had to even when there are many languages that we would match, say SQL, etc. 

Thanks in advance

--- El dom, 20/5/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] more Debian packages?
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "<hendrik at topoi.pooq.com>" <hendrik at topoi.pooq.com>, "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: domingo, 20 de mayo, 2012 16:43

No no no.We will not have an explosion of targets like this. We hopefully will have a drastic reduction.Processor: C or C++Threads: pthreads or Win32 or maybe ucontext or setjmpGUI: X Windows or Win32 or none or maybe otherSuspension: cooperative and probably no other

If the right level of #ifdef and/or autoconf and/or libtool use can makes its way into the "object code", maybe just target completely. (imagine one C source distribution for ALL targets and what that requires).We have rather replaced autoconf & libtool with our carefully researched & written quake code, for better & worse & I am torn as to if this is a good thing. Autoconf & libtool are slow & obscure but ubiquitous, get the job done, are actively maintained by others.

?- Jay (briefly/pocket-sized-computer-aka-phone)
On May 19, 2012, at 11:32 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:

?I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,

for instance to allow and or LINUX_I8086, etc LINUX_I387 

For VAXen computers:

VMS_VAX__

for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11

Alpha's: OSF_ALPHA

For Unixes:

FBSD-GENERIC_I_86___--

To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64

Also could be managed by Manufacturer Model code-name, like

DEC_AQUARIUS or DEC_10000.



Also if we are gonna take macro assembly for cross-platform distributions then, we would need? something akin:

NT_XASM-I_86___

So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)

This would allow to compile CVSup at least is what one would like to
Thanks in advance

 --- El vie, 18/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] more Debian packages?
Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 18 de mayo, 2012 16:50




Yes and yes.
LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.
But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.
?
?
Please try to use I386_LINUX.
I really want to stop this LINUXLIBC6 stuff...
?
?
?You can share the source.
?But we also have outputs in the source tree (unfortunately!).
??? You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...
?
?
?Do this to switch:
?
?./do-cm3-all.py realclean 
?
?- Jay
?
> Date: Fri, 18 May 2012 16:56:49 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] more Debian packages?
> 
> Having succeeded at producing a binary .deb packages for Debian squeeze 
> (though I still have to try it out), I'm now looking at my other 
> machines.  I have a 32-bit Intel machine with wheeze (testing), and one 
> that can run squeeze (stable).  All of them have access to the same 
> NFS-mounted source tree.  Is it practical to use the same tree for two 
> different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> be kept separate?  Or do I need to clean it out or copy it?
> 
> (by the way, I expect making packages for different Debian releases on 
> the same hardware architecture will require a new source tree, or a 
> cleaned-out one.  In my case they'll
 both be LINUXLIBC6)
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120521/976f78b7/attachment.html>

From jay.krell at cornell.edu  Mon May 21 09:50:49 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 May 2012 07:50:49 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>,
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>,
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
Message-ID: <COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>


My point was a bit different -- an interpreter could easily be built from the current intermediate representation.
But heck, then again, the frontend is fast..build an interpreter over source?
Well..hm..actually it might not be fast enough.
This gets rambly/philosophical fast...static checking is useful, but when do you do it?
"static and dynamic are relative".
Before the program runs? Every time before it runs?
When/where do you "save away" decisions/checks that have been made, to avoid them on repeat visits?

Nevermind..I'm not making a clear point..


?- Jay

________________________________
> Subject: Re: [M3devel] LINUXLIBC6 
> From: dragisha at m3w.org 
> Date: Sun, 20 May 2012 22:11:39 +0200 
> CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com 
> To: jay.krell at cornell.edu 
>  
>  
> On May 18, 2012, at 9:49 PM, Jay K wrote: 
>  
> LLVM isn't a bad idea, but there is more expertise out there (and in  
> me) with C and C++, so C and C++ are easier to generate. 
> It is a bit of a chore to learn and use. 
>  
>  
> JIT isn't a crazy idea either..or rather, an interpreter. 
> If you look at parse.c..and you add a few thread locals..I think it's  
> not hard to turn it into an interpreter. 
>    (In reality you don't want to start with parse.c because of the GPL.) 
>  
> LLVM and JIT are close enough. You do LLVM, you get JIT. 
>  
> Also, for debugging we need DWARF. Not incompatible with LLVM. 
 		 	   		  

From dragisha at m3w.org  Mon May 21 10:00:04 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 21 May 2012 10:00:04 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
	<C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>
Message-ID: <08D7AEDF-8B13-4139-B059-4EC66975AD9B@m3w.org>

And why would you/we do it? To be less portable? To escape direct knowledge of endian/word_size/jmpbuf/whatever by cpp and run into C/C++/Java?


On May 20, 2012, at 11:32 PM, Jay wrote:

> I meant "gcc frontends", which Modula-3 is structured as, in a somewhat backward-seeming way.
> 
> 
> Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.
> 
> 
> - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On May 20, 2012, at 2:28 PM, Jay <jay.krell at cornell.edu> wrote:
> 
>> Normally gcc compilers



From dragisha at m3w.org  Mon May 21 10:02:11 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 21 May 2012 10:02:11 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
Message-ID: <721848E0-B0C2-4C51-BD37-1A4BA9A58E7C@m3w.org>

You can't generate reasonable stabs based debug info and expect it to survive optimization steps. DWARF is another thing, optimizer gets data to work on, as well as code. DWARF decorations have a chance to survive optimizations. Stabs, esp heavily idiosyncratic ones - do not.

On May 20, 2012, at 11:28 PM, Jay wrote:

> For dwarf et al: there "nothing" to it: "just" generate reasonable "code" (LLVM whatever, gcc "tree", C, etc) and the next level down handles it. Er, but for some bigger & smaller problems. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120521/04223a33/attachment.html>

From jay.krell at cornell.edu  Mon May 21 10:38:37 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 May 2012 08:38:37 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <721848E0-B0C2-4C51-BD37-1A4BA9A58E7C@m3w.org>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>,
	<721848E0-B0C2-4C51-BD37-1A4BA9A58E7C@m3w.org>
Message-ID: <COL101-W588C5940AE8A443065C0C9E61D0@phx.gbl>


Again, stabs in the context of Modula-3/cm3cg/m3gdb I believe has almost nothing to do with stabs in any other "normal" context.
We use it just to transport our own custom data.
That data may or may not be compromised by optimization.


For example, what are the types of parameters to functions?
Assuming the optimizer does not change the signature of any function?


This data is NOT available at all to stock gdb for Modula-3.
It is available to m3gdb via a completely custom/private data form.


And by "types" here, I mean pretty complete information -- if records are involved,
then all their fields are described.


It is likely the case that on systems that don't support stabs (MacOSX/Darwin), the custom data
could be transported via some other mechanism. Heck, put it in data files on the side.


ok ok, the data does have *something* to do with stabs, but not much.
e.g. that function signature is associated with a function at some address/offset.


Line number information is presumably represented in dwarf/stabs/coff "natively" via gcc's normal paths,
as we do give gcc source line information (at least mostly).


It is when you go beyond mere line number information where things are different.


?- Jay



________________________________
> Subject: Re: [M3devel] LINUXLIBC6 
> From: dragisha at m3w.org 
> Date: Mon, 21 May 2012 10:02:11 +0200 
> CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com 
> To: jay.krell at cornell.edu 
>  
> You can't generate reasonable stabs based debug info and expect it to  
> survive optimization steps. DWARF is another thing, optimizer gets data  
> to work on, as well as code. DWARF decorations have a chance to survive  
> optimizations. Stabs, esp heavily idiosyncratic ones - do not. 
>  
> On May 20, 2012, at 11:28 PM, Jay wrote: 
>  
> For dwarf et al: there "nothing" to it: "just" generate reasonable  
> "code" (LLVM whatever, gcc "tree", C, etc) and the next level down  
> handles it. Er, but for some bigger & smaller problems. 
>  
 		 	   		  

From jay.krell at cornell.edu  Mon May 21 10:40:25 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 May 2012 08:40:25 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <08D7AEDF-8B13-4139-B059-4EC66975AD9B@m3w.org>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
	<C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>,
	<08D7AEDF-8B13-4139-B059-4EC66975AD9B@m3w.org>
Message-ID: <COL101-W25AC411E4510D3BE846C95E61D0@phx.gbl>


To be more portable, and get out of the "problem" of being self-hosting.
I realize self-hosting has major benefits too.
Someone just needs to see if Debian et. al. have a general story for compilers that compile themselves.
And I need to really implement the C backend I talk forever and ever about....


?- Jay


----------------------------------------
> Subject: Re: [M3devel] LINUXLIBC6
> From: dragisha at m3w.org
> Date: Mon, 21 May 2012 10:00:04 +0200
> CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> And why would you/we do it? To be less portable? To escape direct knowledge of endian/word_size/jmpbuf/whatever by cpp and run into C/C++/Java?
>
>
> On May 20, 2012, at 11:32 PM, Jay wrote:
>
> > I meant "gcc frontends", which Modula-3 is structured as, in a somewhat backward-seeming way.
> >
> >
> > Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.
> >
> >
> > - Jay (briefly/pocket-sized-computer-aka-phone)
> >
> > On May 20, 2012, at 2:28 PM, Jay <jay.krell at cornell.edu> wrote:
> >
> >> Normally gcc compilers
>
 		 	   		  

From dragisha at m3w.org  Mon May 21 13:17:44 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 21 May 2012 13:17:44 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W25AC411E4510D3BE846C95E61D0@phx.gbl>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
	<C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>,
	<08D7AEDF-8B13-4139-B059-4EC66975AD9B@m3w.org>
	<COL101-W25AC411E4510D3BE846C95E61D0@phx.gbl>
Message-ID: <1CDC02DA-54C1-43ED-9737-4BCA39C4E87B@m3w.org>

Once it was a big thing for Modula-3 to become self-hosted.

Now, step forward is to undo that :).

I understand - you feel better with (well known and full commanded) C/C++ than with (mostly unknown LLVM). I only hope you will use current provisions of Modula-3 system to implement C/C++ backend in same fashion (using CG* object hierarchy) as other current backends are implemented. That way, someone can go LLVM without changing GCC based backend, or fast Win32 backend, or your future C/C++ backend.

On May 21, 2012, at 10:40 AM, Jay K wrote:

> 
> To be more portable, and get out of the "problem" of being self-hosting.
> I realize self-hosting has major benefits too.
> Someone just needs to see if Debian et. al. have a general story for compilers that compile themselves.
> And I need to really implement the C backend I talk forever and ever about....
> 
> 
>  - Jay
> 
> 
> ----------------------------------------
>> Subject: Re: [M3devel] LINUXLIBC6
>> From: dragisha at m3w.org
>> Date: Mon, 21 May 2012 10:00:04 +0200
>> CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> And why would you/we do it? To be less portable? To escape direct knowledge of endian/word_size/jmpbuf/whatever by cpp and run into C/C++/Java?
>> 
>> 
>> On May 20, 2012, at 11:32 PM, Jay wrote:
>> 
>>> I meant "gcc frontends", which Modula-3 is structured as, in a somewhat backward-seeming way.
>>> 
>>> 
>>> Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.
>>> 
>>> 
>>> - Jay (briefly/pocket-sized-computer-aka-phone)
>>> 
>>> On May 20, 2012, at 2:28 PM, Jay <jay.krell at cornell.edu> wrote:
>>> 
>>>> Normally gcc compilers
>> 
> 		 	   		  



From hendrik at topoi.pooq.com  Mon May 21 20:43:17 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 14:43:17 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
Message-ID: <20120521184316.GA10750@topoi.pooq.com>

On Mon, May 21, 2012 at 07:50:49AM +0000, Jay K wrote:
> 
> Nevermind..I'm not making a clear point..

Maybe this point will do:

So regardless of whether the production compiler generates machine code 
or anythine else, it would be possible to have a single, portable 
interpreter written in C to use as a bootstrap tool to avoid having to 
bootstrap from machine-dependent machine code whenever installing (or 
packaging) foor another platform?  The build-dependency of the real 
Modula 3 compiler could then be itself OR the interpreter.

And the interpreter could be made to interpret some kind of efficient, 
intermediate code that is easy to interpret fast.  Does the existing 
codebase have anything that sould be used for this?  OR could easily be 
changed into this?

-- hendrik


From hendrik at topoi.pooq.com  Mon May 21 23:10:45 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 17:10:45 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <20120521184316.GA10750@topoi.pooq.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
	<20120521184316.GA10750@topoi.pooq.com>
Message-ID: <20120521211045.GA7596@topoi.pooq.com>

On Mon, May 21, 2012 at 02:43:17PM -0400, Hendrik Boom wrote:
> On Mon, May 21, 2012 at 07:50:49AM +0000, Jay K wrote:
> > 
> > Nevermind..I'm not making a clear point..
> 
> Maybe this point will do:
> 
> So regardless of whether the production compiler generates machine code 
> or anythine else, it would be possible to have a single, portable 
> interpreter written in C to use as a bootstrap tool to avoid having to 
> bootstrap from machine-dependent machine code whenever installing (or 
> packaging) foor another platform?  The build-dependency of the real 
> Modula 3 compiler could then be itself OR the interpreter.
> 
> And the interpreter could be made to interpret some kind of efficient, 
> intermediate code that is easy to interpret fast.  Does the existing 
> codebase have anything that sould be used for this?  OR could easily be 
> changed into this?
> 
> -- hendrik

C--, I believe, is implemented as a compiler for several platforms, and 
also as an interpreter.  So generating C-- code would satisfy our 
requirements for a bootstrap.  If we want to hook into a run-time 
system that has at least thought seriously about the issues of 
garbage-collection and stack-walking, this might be it.  But I don't 
know to what extent these essential features have beein implemented. 

OCAML also had an interpreter and compilers to several machine codes.  
This would seem to be a viable mechanism.

I've been using an OCAML-written Algol W compiler using the interpreted 
OCAML implementation, and it still compiles Algol W to C faster than 
the C compiler translates its output code to machine code. 

-- hendrik




From jay.krell at cornell.edu  Tue May 22 00:50:44 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 May 2012 22:50:44 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <20120521211045.GA7596@topoi.pooq.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>,
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>,
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>,
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>,
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>,
	<20120521184316.GA10750@topoi.pooq.com>,
	<20120521211045.GA7596@topoi.pooq.com>
Message-ID: <COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>


Is C-- adequately maintained? I don't think so.
I'm also not super keen on depending on other projects.
We'll see..


Regarding runtime designed for garbage collection... in the interest of simplicity, correctness,
and laziness-ignoring-performance, I'd initially try something like this:

?- don't optimize, or at least make all writes volatile 
?? or make everything volatile 
While currently we have some support for the gcc optimizer, and we don't make everything volatile,
we also had a long history of using a lot of volatile. I think nobody but me and possibly Tony
noticed the poor codegen and probably
?
?- form all frames as structs 
? - so that the frame layout can be known by the frontend


We already do something similar to the last, I think.


One of the wierd points here..and I really really really really have to get on and code instead of talk,
is "what our C would look like".
It would look strange.


Consider all the inserted "probes" (I forget what they are called).
Consider as I said that there are no field references from the backend's point of view, just variable + offset + cast.


Anyway..later...


?- Jay



----------------------------------------
> Date: Mon, 21 May 2012 17:10:45 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] LINUXLIBC6
>
> On Mon, May 21, 2012 at 02:43:17PM -0400, Hendrik Boom wrote:
> > On Mon, May 21, 2012 at 07:50:49AM +0000, Jay K wrote:
> > >
> > > Nevermind..I'm not making a clear point..
> >
> > Maybe this point will do:
> >
> > So regardless of whether the production compiler generates machine code
> > or anythine else, it would be possible to have a single, portable
> > interpreter written in C to use as a bootstrap tool to avoid having to
> > bootstrap from machine-dependent machine code whenever installing (or
> > packaging) foor another platform? The build-dependency of the real
> > Modula 3 compiler could then be itself OR the interpreter.
> >
> > And the interpreter could be made to interpret some kind of efficient,
> > intermediate code that is easy to interpret fast. Does the existing
> > codebase have anything that sould be used for this? OR could easily be
> > changed into this?
> >
> > -- hendrik
>
> C--, I believe, is implemented as a compiler for several platforms, and
> also as an interpreter. So generating C-- code would satisfy our
> requirements for a bootstrap. If we want to hook into a run-time
> system that has at least thought seriously about the issues of
> garbage-collection and stack-walking, this might be it. But I don't
> know to what extent these essential features have beein implemented.
>
> OCAML also had an interpreter and compilers to several machine codes.
> This would seem to be a viable mechanism.
>
> I've been using an OCAML-written Algol W compiler using the interpreted
> OCAML implementation, and it still compiles Algol W to C faster than
> the C compiler translates its output code to machine code.
>
> -- hendrik
>
>
 		 	   		  

From dabenavidesd at yahoo.es  Tue May 22 02:47:59 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 22 May 2012 01:47:59 +0100 (BST)
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
Message-ID: <1337647679.52945.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all: 
none interpreter product I have seen lately, that tries such a way C, I know there was a product of 25+ years called C-terp, but they don't do it anymore.  
I don't think they just tried to debug code and safely execute but execute it safely and prudently fast but none else have seemingly been keen to that, so if they thought was a good idea way before all this, I guess we can try to do that. Seems a good one. Which compiler does that, just C--?
They distributed some gcc freely and had MS VS4 versions and all of that.
Thanks in advance


--- El lun, 21/5/12, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] LINUXLIBC6
> Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 21 de mayo, 2012 17:50
> 
> Is C-- adequately maintained? I don't think so.
> I'm also not super keen on depending on other projects.
> We'll see..
> 
> 
> Regarding runtime designed for garbage collection... in the
> interest of simplicity, correctness,
> and laziness-ignoring-performance, I'd initially try
> something like this:
> 
> ?- don't optimize, or at least make all writes volatile 
> ?? or make everything volatile 
> While currently we have some support for the gcc optimizer,
> and we don't make everything volatile,
> we also had a long history of using a lot of volatile. I
> think nobody but me and possibly Tony
> noticed the poor codegen and probably
> ?
> ?- form all frames as structs 
> ? - so that the frame layout can be known by the frontend
> 
> 
> We already do something similar to the last, I think.
> 
> 
> One of the wierd points here..and I really really really
> really have to get on and code instead of talk,
> is "what our C would look like".
> It would look strange.
> 
> 
> Consider all the inserted "probes" (I forget what they are
> called).
> Consider as I said that there are no field references from
> the backend's point of view, just variable + offset + cast.
> 
> 
> Anyway..later...
> 
> 
> ?- Jay
> 
> 
> 
> ----------------------------------------
> > Date: Mon, 21 May 2012 17:10:45 -0400
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] LINUXLIBC6
> >
> > On Mon, May 21, 2012 at 02:43:17PM -0400, Hendrik Boom
> wrote:
> > > On Mon, May 21, 2012 at 07:50:49AM +0000, Jay K
> wrote:
> > > >
> > > > Nevermind..I'm not making a clear point..
> > >
> > > Maybe this point will do:
> > >
> > > So regardless of whether the production compiler
> generates machine code
> > > or anythine else, it would be possible to have a
> single, portable
> > > interpreter written in C to use as a bootstrap
> tool to avoid having to
> > > bootstrap from machine-dependent machine code
> whenever installing (or
> > > packaging) foor another platform? The
> build-dependency of the real
> > > Modula 3 compiler could then be itself OR the
> interpreter.
> > >
> > > And the interpreter could be made to interpret
> some kind of efficient,
> > > intermediate code that is easy to interpret fast.
> Does the existing
> > > codebase have anything that sould be used for
> this? OR could easily be
> > > changed into this?
> > >
> > > -- hendrik
> >
> > C--, I believe, is implemented as a compiler for
> several platforms, and
> > also as an interpreter. So generating C-- code would
> satisfy our
> > requirements for a bootstrap. If we want to hook into a
> run-time
> > system that has at least thought seriously about the
> issues of
> > garbage-collection and stack-walking, this might be it.
> But I don't
> > know to what extent these essential features have beein
> implemented.
> >
> > OCAML also had an interpreter and compilers to several
> machine codes.
> > This would seem to be a viable mechanism.
> >
> > I've been using an OCAML-written Algol W compiler using
> the interpreted
> > OCAML implementation, and it still compiles Algol W to
> C faster than
> > the C compiler translates its output code to machine
> code.
> >
> > -- hendrik
> >
> >
>  ???
> ????????
> ?????? ???
> ? 


From hendrik at topoi.pooq.com  Tue May 22 04:44:55 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 22:44:55 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
	<20120521184316.GA10750@topoi.pooq.com>
	<20120521211045.GA7596@topoi.pooq.com>
	<COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
Message-ID: <20120522024455.GA9667@topoi.pooq.com>

On Mon, May 21, 2012 at 10:50:44PM +0000, Jay K wrote:
> 
> Is C-- adequately maintained? I don't think so.

Bugs get fixed.  And there's very few of them reported.  But it's not 
clear to me whether that's because it's so well-written, or because 
almost no one uses it.

Active development seems to be at a stendstill.

> I'm also not super keen on depending on other projects.
> We'll see..

I mentioned C-- because its implementation exists in both interpreted 
and compiled versions.  That seems to be a way to bootstrap the whole 
thing.  We could interpret the compiler using some portable 
intermediate code -- we could even restrict the interpreter to provide 
only a 32-bit machine, and then cross-compile from the interpreted 
compiler to whatever machine we're installing on.  Since every Modula 
3 compiler seems to be able to generate code for every platform, 
this is a way to avoid having a separate binary bootstrap for every 
platform.

And a distro, like Debian, could have a source package that doesn't 
need to have itself installed before it it can be installed.

-- hendrik

> 
> 
> Regarding runtime designed for garbage collection... in the interest of simplicity, correctness,
> and laziness-ignoring-performance, I'd initially try something like this:
> 
> ?- don't optimize, or at least make all writes volatile 
> ?? or make everything volatile 
> While currently we have some support for the gcc optimizer, and we don't make everything volatile,
> we also had a long history of using a lot of volatile. I think nobody but me and possibly Tony
> noticed the poor codegen and probably
> ?
> ?- form all frames as structs 
> ? - so that the frame layout can be known by the frontend
>
> 
> 
> We already do something similar to the last, I think.
> 
> 
> One of the wierd points here..and I really really really really have to get on and code instead of talk,
> is "what our C would look like".
> It would look strange.
> 
> 
> Consider all the inserted "probes" (I forget what they are called).
> Consider as I said that there are no field references from the 
> backend's point of view, just variable + offset + cast.

That's basically the  way that C-- accesses memory.

-- hendrik


From hendrik at topoi.pooq.com  Tue May 22 04:57:50 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 22:57:50 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <1337647679.52945.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
	<1337647679.52945.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <20120522025750.GB9667@topoi.pooq.com>

On Tue, May 22, 2012 at 01:47:59AM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all: 
> none interpreter product I have seen lately, that tries such a way C, I know there was a product of 25+ years called C-terp, but they don't do it anymore.  
> I don't think they just tried to debug code and safely execute but execute it safely and prudently fast but none else have seemingly been keen to that, so if they thought was a good idea way before all this, I guess we can try to do that. Seems a good one. Which compiler does that, just C--?

I think OCaml did an interpreter-compiler combination, whhere one 
could be used to implement the other.  Though I'm not sure.

I worked on C and C++ interpreters once.  All proprietary, 
unfortunately.

Gambit-C is a compiler from Scheme to C.  It's written in its own 
language, and it also provides an interpreter for its own language,
also written in Scheme and compiled to C, I believe.  It manages to do 
an efficient implementation of continuations despite running in C.

> They distributed some gcc freely and had MS VS4 versions and all of that.
> Thanks in advance

-- hendrik


From hendrik at topoi.pooq.com  Tue May 22 05:32:16 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 23:32:16 -0400
Subject: [M3devel] use of LLVM
In-Reply-To: <1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <20120522033216.GC9667@topoi.pooq.com>

On Fri, May 18, 2012 at 06:16:59PM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all:
> After ESC we do need much debugger at all, in fact it was designed for that for avoiding put much time on it.
> Still if we generate C is for super-optimization (but verified also mechanically), so I don't mind that, but for code quality I prefer C, I agree absolutely in that we should support it again for that purpose (as originally).
> As for not verified code we should stick with C--, as it is written for that purposes, but for portability specially with implicit safety.
> And for not verified nor optimal and not common use code (like mentor) we should make them source packages (in fact If they are written in Obliq we don't want to redistribute that as non-source), instead part of m3-demo package subdirectory or so.
> I think for M3CG is that we need a LLVM or so back-end for JIT.

The problem I had with LLVM for Algol 68 was that I couldn't use a type 
before it was completely defined.  THis means that there are stark 
constraints on the use of incomplete types.  I wanted to build a 
structure to represent a stack frame, containing local variables and 
the like, and having the field offsets afailable for type descriptors 
for the garbage collector.  But even though LLVM could have computed 
field offsets along the way, as they were contributed to the structure, 
instead it decided to diallow all use of the structure until its 
definition was complete.  UNfortunately, I didn't know what all the 
fields would be until I got to finish generating the code that used the 
stack frame.

This was a restriction in using LLVM as a JIT.  You get to build the 
LLVM abstract syntax in pretty well any order you want, sticking extra 
bits in here, there, everywhere, except for this one bizarre 
restriction.  I have to build all the abstract syntax for a type 
definition before I can refer to any of it elsewhere in the parse tree.  
Well, thare are a few exceptions for defining recursive types, but they 
don't do enough to make this work.

It's different when writing LLVM code as an ASCII text file.  Then you 
can write out the type definitions on one file and the code that uses 
then in an other file, and cocatenate them before passing them too 
LLVM.

Mind you that's not a lot worse than in C--, where you *have* to write 
out text file (and I do write it out of order).  But it irks to 
have the entire LLVM JIT interface reduced to uselessness.  At least 
with C-- you're not *expecting* to get a JIT.

-- hendrik


From dragisha at m3w.org  Tue May 22 10:59:24 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 22 May 2012 10:59:24 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
Message-ID: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>


***
*** runtime error:
***    <*ASSERT*> failed.
***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
***
...
#17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
    at ../src/thread/PTHREAD/ThreadPThread.m3:586
#18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
#19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
?

And so on? Looks like I reported this earlier, here: 

https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html

Any progress? Maybe I missed something.

dd




From lemming at henning-thielemann.de  Tue May 22 10:45:24 2012
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 22 May 2012 10:45:24 +0200 (CEST)
Subject: [M3devel] use of LLVM
In-Reply-To: <20120522033216.GC9667@topoi.pooq.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<20120522033216.GC9667@topoi.pooq.com>
Message-ID: <alpine.DEB.2.00.1205221044001.12948@anubis.informatik.uni-halle.de>


On Mon, 21 May 2012, Hendrik Boom wrote:

> The problem I had with LLVM for Algol 68 was that I couldn't use a type
> before it was completely defined.  THis means that there are stark
> constraints on the use of incomplete types.  I wanted to build a
> structure to represent a stack frame, containing local variables and
> the like, and having the field offsets afailable for type descriptors
> for the garbage collector.  But even though LLVM could have computed
> field offsets along the way, as they were contributed to the structure,
> instead it decided to diallow all use of the structure until its
> definition was complete.  UNfortunately, I didn't know what all the
> fields would be until I got to finish generating the code that used the
> stack frame.

I thought that you can disable pointer type checking completely by using 
i8* and cast it forth and back as you need it.


From dragisha at m3w.org  Tue May 22 17:16:30 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 22 May 2012 17:16:30 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
In-Reply-To: <E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
Message-ID: <16020041-89DE-47A7-AD6C-A04ECAB9991D@m3w.org>

This is 5.8.6 release code. You probably did not read a message I referenced.

On May 22, 2012, at 4:59 PM, Antony Hosking wrote:

> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
> 
> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
> 
>> 
>> ***
>> *** runtime error:
>> ***    <*ASSERT*> failed.
>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>> ***
>> ...
>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>   at ../src/thread/PTHREAD/ThreadPThread.m3:586
>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>> ?
>> 
>> And so on? Looks like I reported this earlier, here: 
>> 
>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>> 
>> Any progress? Maybe I missed something.
>> 
>> dd
>> 
>> 
> 



From dragisha at m3w.org  Tue May 22 17:23:31 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 22 May 2012 17:23:31 +0200
Subject: [M3devel]
 =?windows-1252?q?pthreads_problem=2C_LINUXLIBC6=2C_RHEL?=
 =?windows-1252?q?_5=2E8=85_random_observation?=
In-Reply-To: <16020041-89DE-47A7-AD6C-A04ECAB9991D@m3w.org>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
	<16020041-89DE-47A7-AD6C-A04ECAB9991D@m3w.org>
Message-ID: <D1D53D02-1EC9-4227-96DF-A245B5988F6A@m3w.org>

<* ASSERT r = 0 *>

is probably better as:

IF r # 0 THEN
  <* DEBUG "r = " & Fmt.Int? *>
  <* ASSERT FALSE *>
END;

On May 22, 2012, at 5:16 PM, Dragi?a Duri? wrote:

> This is 5.8.6 release code. You probably did not read a message I referenced.
> 
> On May 22, 2012, at 4:59 PM, Antony Hosking wrote:
> 
>> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
>> 
>> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
>> 
>>> 
>>> ***
>>> *** runtime error:
>>> ***    <*ASSERT*> failed.
>>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>>> ***
>>> ...
>>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>>  at ../src/thread/PTHREAD/ThreadPThread.m3:586
>>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>>> ?
>>> 
>>> And so on? Looks like I reported this earlier, here: 
>>> 
>>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>>> 
>>> Any progress? Maybe I missed something.
>>> 
>>> dd
>>> 
>>> 
>> 
> 



From hendrik at topoi.pooq.com  Tue May 22 17:56:51 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Tue, 22 May 2012 11:56:51 -0400
Subject: [M3devel] use of LLVM
In-Reply-To: <alpine.DEB.2.00.1205221044001.12948@anubis.informatik.uni-halle.de>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<20120522033216.GC9667@topoi.pooq.com>
	<alpine.DEB.2.00.1205221044001.12948@anubis.informatik.uni-halle.de>
Message-ID: <20120522155651.GA12326@topoi.pooq.com>

On Tue, May 22, 2012 at 10:45:24AM +0200, Henning Thielemann wrote:
> 
> On Mon, 21 May 2012, Hendrik Boom wrote:
> 
> >The problem I had with LLVM for Algol 68 was that I couldn't use a type
> >before it was completely defined.  THis means that there are stark
> >constraints on the use of incomplete types.  I wanted to build a
> >structure to represent a stack frame, containing local variables and
> >the like, and having the field offsets afailable for type descriptors
> >for the garbage collector.  But even though LLVM could have computed
> >field offsets along the way, as they were contributed to the structure,
> >instead it decided to diallow all use of the structure until its
> >definition was complete.  UNfortunately, I didn't know what all the
> >fields would be until I got to finish generating the code that used the
> >stack frame.
> 
> I thought that you can disable pointer type checking completely by
> using i8* and cast it forth and back as you need it.

But I still can't generate code that does anything more than mention 
these types until they are completely defined.  I can't make the 
abtstract syntax tree for sizeof(foo) before I've completed the 
definition of foo.  I can't mention any of the field names until I've 
completed the definition of foo....

Yes, i8* might get around some limitations, if I do all the field 
offset calculations myself and embed the numbers in the generated 
code.  But that's not how LLVM is supposed to work.  It's supposed to 
be rather more machine-independent than that.

-- hendrik


From dragisha at m3w.org  Tue May 22 18:20:35 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 22 May 2012 18:20:35 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
In-Reply-To: <39DE377C-56A0-4F0F-B459-1E8953F889B8@gmail.com>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
	<16020041-89DE-47A7-AD6C-A04ECAB9991D@m3w.org>
	<39DE377C-56A0-4F0F-B459-1E8953F889B8@gmail.com>
Message-ID: <F72BE040-3ABC-4FB0-8EC6-96C70A92FC39@m3w.org>

Probably :)

I just tried to rebuild cm3-5.8.6 on this system, from source. Same problem.

I will try some 5.9.* next.

Interim release would be good idea. If only we can have functional m3gdb? gcc version used is not priority, to me.

On May 22, 2012, at 5:43 PM, Antony Hosking wrote:

> The release contains a number of known problems.
> Time for an interim release?
> 
> 
> On May 22, 2012, at 11:16 AM, Dragi?a Duri? wrote:
> 
>> This is 5.8.6 release code. You probably did not read a message I referenced.
>> 
>> On May 22, 2012, at 4:59 PM, Antony Hosking wrote:
>> 
>>> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
>>> 
>>> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
>>> 
>>>> 
>>>> ***
>>>> *** runtime error:
>>>> ***    <*ASSERT*> failed.
>>>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>>>> ***
>>>> ...
>>>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>>> at ../src/thread/PTHREAD/ThreadPThread.m3:586
>>>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>>>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>>>> ?
>>>> 
>>>> And so on? Looks like I reported this earlier, here: 
>>>> 
>>>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>>>> 
>>>> Any progress? Maybe I missed something.
>>>> 
>>>> dd
>>>> 
>>>> 
>>> 
>> 
> 



From dragisha at m3w.org  Wed May 23 10:36:05 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 23 May 2012 10:36:05 +0200
Subject: [M3devel] cm3, NOPTHREAD
Message-ID: <9E51EE23-0A0E-459F-BC97-9CC447728A2A@m3w.org>

Anyone made cm3 with -DNOPTHREAD ? 5.8.6 release version.


From dragisha at m3w.org  Wed May 23 12:03:37 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 23 May 2012 12:03:37 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
In-Reply-To: <E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
Message-ID: <6FA05B91-4425-4164-8A08-B033920FE45E@m3w.org>

Return code in question is 22, EINVAL, code is

      WITH r = pthread_cond_timedwait(self.cond, self.mutex, until) DO
        IF r = Uerror.ETIMEDOUT THEN
          WITH r = pthread_mutex_unlock(self.mutex) DO <*ASSERT r=0*> END;
          IF perfOn THEN PerfRunning() END;
          RETURN;
        END;
        IF r # 0 THEN
          RTIO.PutText("r="); RTIO.PutInt(r); RTIO.PutText("\n");
          RTIO.Flush();
        END;
        <*ASSERT r=0*> --- former line 586

...
       The pthread_cond_timedwait() and pthread_cond_wait() functions may fail if:

       EINVAL The value specified by cond, mutex, or abstime is invalid.

       EINVAL Different  mutexes  were supplied for concurrent pthread_cond_timedwait() or pthread_cond_wait() operations on the
              same condition variable.

On May 22, 2012, at 4:59 PM, Antony Hosking wrote:

> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
> 
> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
> 
>> 
>> ***
>> *** runtime error:
>> ***    <*ASSERT*> failed.
>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>> ***
>> ...
>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>   at ../src/thread/PTHREAD/ThreadPThread.m3:586
>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>> ?
>> 
>> And so on? Looks like I reported this earlier, here: 
>> 
>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>> 
>> Any progress? Maybe I missed something.
>> 
>> dd
>> 
>> 
> 



From dragisha at m3w.org  Wed May 23 14:36:02 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 23 May 2012 14:36:02 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
In-Reply-To: <6FA05B91-4425-4164-8A08-B033920FE45E@m3w.org>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
	<6FA05B91-4425-4164-8A08-B033920FE45E@m3w.org>
Message-ID: <1CE45569-8335-4BFD-A08F-30D60A9EA18E@m3w.org>

Good news is: it was only range check error missing in generated code.

Input argument to Thread.Pause() was 1.0d9 (safe infinity idea on 64bit :)). When added to Time.Now(), it overflows 32bit component timespec. Negative components in timespec - EINVAL on pthread_cond_timedwait.

Good news II: No need for interim release because of this "bug". 

On May 23, 2012, at 12:03 PM, Dragi?a Duri? wrote:

> Return code in question is 22, EINVAL, code is
> 
>      WITH r = pthread_cond_timedwait(self.cond, self.mutex, until) DO
>        IF r = Uerror.ETIMEDOUT THEN
>          WITH r = pthread_mutex_unlock(self.mutex) DO <*ASSERT r=0*> END;
>          IF perfOn THEN PerfRunning() END;
>          RETURN;
>        END;
>        IF r # 0 THEN
>          RTIO.PutText("r="); RTIO.PutInt(r); RTIO.PutText("\n");
>          RTIO.Flush();
>        END;
>        <*ASSERT r=0*> --- former line 586
> 
> ...
>       The pthread_cond_timedwait() and pthread_cond_wait() functions may fail if:
> 
>       EINVAL The value specified by cond, mutex, or abstime is invalid.
> 
>       EINVAL Different  mutexes  were supplied for concurrent pthread_cond_timedwait() or pthread_cond_wait() operations on the
>              same condition variable.
> 
> On May 22, 2012, at 4:59 PM, Antony Hosking wrote:
> 
>> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
>> 
>> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
>> 
>>> 
>>> ***
>>> *** runtime error:
>>> ***    <*ASSERT*> failed.
>>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>>> ***
>>> ...
>>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>>  at ../src/thread/PTHREAD/ThreadPThread.m3:586
>>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>>> ?
>>> 
>>> And so on? Looks like I reported this earlier, here: 
>>> 
>>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>>> 
>>> Any progress? Maybe I missed something.
>>> 
>>> dd
>>> 
>>> 
>> 
> 



From dabenavidesd at yahoo.es  Thu May 24 00:41:41 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 23 May 2012 23:41:41 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <9E51EE23-0A0E-459F-BC97-9CC447728A2A@m3w.org>
Message-ID: <1337812901.82672.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi:
What I remember is last release was done with switch, but before was built by that target so, I don't know, I think there isn't such now, maybe I'm wrong.
In the end, what is the difference for build time, none probably, so use what you build, or what do you want to build? 
Thanks in advance

--- El mi?, 23/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: [M3devel] cm3, NOPTHREAD
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 23 de mayo, 2012 03:36
> Anyone made cm3 with -DNOPTHREAD ?
> 5.8.6 release version.
> 


From jay.krell at cornell.edu  Thu May 24 01:07:46 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 23 May 2012 23:07:46 +0000
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <1337812901.82672.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <9E51EE23-0A0E-459F-BC97-9CC447728A2A@m3w.org>,
	<1337812901.82672.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W464C8A70B5346462747BEBE6030@phx.gbl>


Do you mean did we make something "official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.  Do it yourself?  (Try out scripts/python/make-dist.py?)   It has always been easy from a m3makefile point of view to do it.You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.   - Jay
 > Date: Wed, 23 May 2012 23:41:41 +0100
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; dragisha at m3w.org
> Subject: Re: [M3devel] cm3, NOPTHREAD
> 
> Hi:
> What I remember is last release was done with switch, but before was built by that target so, I don't know, I think there isn't such now, maybe I'm wrong.
> In the end, what is the difference for build time, none probably, so use what you build, or what do you want to build? 
> Thanks in advance
> 
> --- El mi?, 23/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> > De: Dragi?a Duri? <dragisha at m3w.org>
> > Asunto: [M3devel] cm3, NOPTHREAD
> > Para: "m3devel" <m3devel at elegosoft.com>
> > Fecha: mi?rcoles, 23 de mayo, 2012 03:36
> > Anyone made cm3 with -DNOPTHREAD ?
> > 5.8.6 release version.
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120523/b4297d35/attachment.html>

From dabenavidesd at yahoo.es  Thu May 24 01:31:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 24 May 2012 00:31:34 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <COL101-W464C8A70B5346462747BEBE6030@phx.gbl>
Message-ID: <1337815894.98672.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I was remembering that last release was able to switch, but proving the theory that something is better, I don't remember any reason rather than by broken builds, so that's why I say use what you have.
In my mind there is any reason for such target to be very different in compile time, perhaps in RT the GC may help something if so. But Dragisha wants to 'build', so I don't know.
Thanks in advance

--- El mi?, 23/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] cm3, NOPTHREAD
Para: dabenavidesd at yahoo.es, "m3devel" <m3devel at elegosoft.com>, dragisha at m3w.org
Fecha: mi?rcoles, 23 de mayo, 2012 18:07




Do you mean did we make something?"official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
?
?
Do it yourself?
? (Try out scripts/python/make-dist.py?) 
?
?
It has always been easy from a m3makefile point of view to do it.
You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.
?
?
?- Jay
?
> Date: Wed, 23 May 2012 23:41:41 +0100
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; dragisha at m3w.org
> Subject: Re: [M3devel] cm3, NOPTHREAD
> 
> Hi:
> What I remember is last release was done with switch, but before was built by that target so, I don't know, I think there isn't such now, maybe I'm wrong.
> In the end, what is the difference for build time, none probably, so use what you build, or what do you want to build? 
> Thanks in advance
> 
> --- El mi?, 23/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> > De: Dragi?a Duri? <dragisha at m3w.org>
> > Asunto: [M3devel] cm3, NOPTHREAD
> > Para: "m3devel" <m3devel at elegosoft.com>
> > Fecha: mi?rcoles, 23 de mayo, 2012 03:36
> > Anyone made cm3 with -DNOPTHREAD ?
> > 5.8.6 release version.
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120524/5e996ec2/attachment.html>

From dragisha at m3w.org  Thu May 24 10:43:41 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 24 May 2012 10:43:41 +0200
Subject: [M3devel] cm3, NOPTHREAD
Message-ID: <F2C6F642-0ED9-4A79-9E67-256DAE06EB64@m3w.org>

I did

export BUILDARGS="-DNOPTHREAD"

before building packages/compiler.

Didn't work. Built cm3 failed on first invocation with stack of three elements, topmost being NoteStackLocations. No other data.

On May 24, 2012, at 1:07 AM, Jay K wrote:

> Do you mean did we make something "official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
>  
>  
> Do it yourself?
>   (Try out scripts/python/make-dist.py?) 
>  
>  
> It has always been easy from a m3makefile point of view to do it.
> You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120524/67a65fad/attachment.html>

From dragisha at m3w.org  Fri May 25 22:51:34 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 25 May 2012 22:51:34 +0200
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <1337978790.36404.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1337978790.36404.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <555EDB08-5E0A-472A-9D93-FD890F924303@m3w.org>

Daniel,

BUILDARGS is applied to all builds occuring while it's set.

Have a nice day.

dd

On May 25, 2012, at 10:46 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> such system will not compile everything using NOPTHREAD thing, but merely the compiler, so this doesn't help anything else than the compiler, if you want to build with your compiler that then you need a correct boot image.
> Thanks in advance
> 
> 
> --- El jue, 24/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] cm3, NOPTHREAD
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: jueves, 24 de mayo, 2012 03:43
> 
> I did
> 
> export BUILDARGS="-DNOPTHREAD"
> 
> before building packages/compiler.
> 
> Didn't work. Built cm3 failed on first invocation with stack of three elements, topmost being NoteStackLocations. No other data.
> 
> On May 24, 2012, at 1:07 AM, Jay K wrote:
> 
>> Do you mean did we make something "official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
>>  
>>  
>> Do it yourself?
>>   (Try out scripts/python/make-dist.py?) 
>>  
>>  
>> It has always been easy from a m3makefile point of view to do it.
>> You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120525/235f57e2/attachment.html>

From dabenavidesd at yahoo.es  Fri May 25 22:46:30 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 25 May 2012 21:46:30 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <F2C6F642-0ED9-4A79-9E67-256DAE06EB64@m3w.org>
Message-ID: <1337978790.36404.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
such system will not compile everything using NOPTHREAD thing, but merely the compiler, so this doesn't help anything else than the compiler, if you want to build with your compiler that then you need a correct boot image.
Thanks in advance


--- El jue, 24/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] cm3, NOPTHREAD
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 24 de mayo, 2012 03:43

I did
export BUILDARGS="-DNOPTHREAD"
before building packages/compiler.
Didn't work. Built cm3 failed on first invocation with stack of three elements, topmost being NoteStackLocations. No other data.
On May 24, 2012, at 1:07 AM, Jay K wrote:
Do you mean did we make something?"official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
?
?
Do it yourself?
? (Try out scripts/python/make-dist.py?)?
?
?
It has always been easy from a m3makefile point of view to do it.
You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120525/520b424b/attachment.html>

From dabenavidesd at yahoo.es  Fri May 25 22:57:56 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 25 May 2012 21:57:56 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <555EDB08-5E0A-472A-9D93-FD890F924303@m3w.org>
Message-ID: <1337979476.29484.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
no, since we've lost self-hosted compiler (because PTHREADS is C code) when compiling using PTHREADS capabilities.
You need a new compiler image and a new RT image, if you want to do that; what you say, sounds like you can change that at build time, this is not the case.
Thanks in advance


--- El vie, 25/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] cm3, NOPTHREAD
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay K" <jay.krell at cornell.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 25 de mayo, 2012 15:51

Daniel,
BUILDARGS is applied to all builds occuring while it's set.
Have a nice day.
dd
On May 25, 2012, at 10:46 PM, Daniel Alejandro Benavides D. wrote:
Hi all:
such system will not compile everything using NOPTHREAD thing, but merely the compiler, so this doesn't help anything else than the compiler, if you want to build with your compiler that then you need a correct boot image.
Thanks in advance


--- El jue, 24/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] cm3, NOPTHREAD
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 24 de mayo, 2012 03:43

I did
export BUILDARGS="-DNOPTHREAD"
before building packages/compiler.
Didn't work. Built
 cm3 failed on first invocation with stack of three elements, topmost being NoteStackLocations. No other data.
On May 24, 2012, at 1:07 AM, Jay K wrote:
Do you mean did we make something?"official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
?
?
Do it yourself?
? (Try out
 scripts/python/make-dist.py?)?
?
?
It has always been easy from a m3makefile point of view to do it.
You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120525/c760a07b/attachment.html>

From jay.krell at cornell.edu  Sat May 26 00:09:12 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 25 May 2012 22:09:12 +0000
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <1337979476.29484.YahooMailClassic@web29703.mail.ird.yahoo.com>
References: <555EDB08-5E0A-472A-9D93-FD890F924303@m3w.org>,
	<1337979476.29484.YahooMailClassic@web29703.mail.ird.yahoo.com>
Message-ID: <COL101-W1C8E7FBA8B4CC5793DC42E6010@phx.gbl>


?> no, since we've lost self-hosted compiler (because PTHREADS is C code)  
?> when compiling using PTHREADS capabilities. 
?

?Again Daniel, this make no sense to me. 


> You need a new compiler image 


?
?Again Daniel, this is wrong.?  


?
? >? and a new RT image 




? Again Daniel, this doesn't make complete sense to me.?  
? What do you mean "new RT image"? 


?You need m3core, and then because its interface essentially changes (different type ids for thread and/or lock), you have to recompile everything else that you are going to use, with this new m3core -- i.e.? the entire dependency graph up to and including the executable.


You do NOT need a new compiler.
If it works, great. But you don't need it.


If we hide the types behind object or such, then only m3core will need to be rebuild. That is the plan. And more so -- a command line to change between them.
For now, the type ids vary.


-DNOPTHREAD only directly changes m3core.
The rest of the system can be compiled w/ or w/o it. But the new m3core causes a need for some rebuild.


?- Jay


________________________________
> Date: Fri, 25 May 2012 21:57:56 +0100 
> From: dabenavidesd at yahoo.es 
> Subject: Re: [M3devel] cm3, NOPTHREAD 
> To: dragisha at m3w.org 
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com 
>  
> Hi all: 
> no, since we've lost self-hosted compiler (because PTHREADS is C code)  
> when compiling using PTHREADS capabilities. 
> You need a new compiler image and a new RT image, if you want to do  
> that; what you say, sounds like you can change that at build time, this  
> is not the case. 
> Thanks in advance 
>  
>  
> --- El vie, 25/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?: 
>  
> De: Dragi?a Duri? <dragisha at m3w.org> 
> Asunto: Re: [M3devel] cm3, NOPTHREAD 
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 
> CC: "Jay K" <jay.krell at cornell.edu>, "m3devel" <m3devel at elegosoft.com> 
> Fecha: viernes, 25 de mayo, 2012 15:51 
>  
> Daniel, 
>  
> BUILDARGS is applied to all builds occuring while it's set. 
>  
> Have a nice day. 
>  
> dd 
>  
> On May 25, 2012, at 10:46 PM, Daniel Alejandro Benavides D. wrote: 
>  
> Hi all: 
> such system will not compile everything using NOPTHREAD thing, but  
> merely the compiler, so this doesn't help anything else than the  
> compiler, if you want to build with your compiler that then you need a  
> correct boot image. 
> Thanks in advance 
>  
>  
> --- El jue, 24/5/12, Dragi?a Duri?  
> <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>> escribi?: 
>  
> De: Dragi?a Duri?  
> <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>> 
> Asunto: Re: [M3devel] cm3, NOPTHREAD 
> Para: "Jay K"  
> <jay.krell at cornell.edu<http:///mc/compose?to=jay.krell%40cornell.edu>> 
> CC: "m3devel"  
> <m3devel at elegosoft.com<http:///mc/compose?to=m3devel%40elegosoft.com>> 
> Fecha: jueves, 24 de mayo, 2012 03:43 
>  
> I did 
>  
> export BUILDARGS="-DNOPTHREAD" 
>  
> before building packages/compiler. 
>  
> Didn't work. Built cm3 failed on first invocation with stack of three  
> elements, topmost being NoteStackLocations. No other data. 
>  
> On May 24, 2012, at 1:07 AM, Jay K wrote: 
>  
> Do you mean did we make something "official" and put it somewhere to be  
> tested and downloaded by the masses of Modula-3 programmers who want to  
> use both Modula-3 and user threads? I don't think so. 
>  
>  
> Do it yourself? 
>    (Try out scripts/python/make-dist.py?) 
>  
>  
> It has always been easy from a m3makefile point of view to do it. 
> You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile. 
>  
>  
>  
>  
 		 	   		  

From dabenavidesd at yahoo.es  Sat May 26 00:38:07 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 25 May 2012 23:38:07 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <COL101-W1C8E7FBA8B4CC5793DC42E6010@phx.gbl>
Message-ID: <1337985487.13774.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
I'm thinking can press a key command to compile m3core with that option, no, you need to change the sources of the thing. That's for me new RT and new compiler, and if you want that do it, it's OK but for me, don't think it makes sense to do that in an automatic environment, that's why I tell you you can't do that in Modula-3 alone. If it were pure Modula-3 yes you could override a Thread interface with that option, but not here certainly.
Thanks advance


--- El vie, 25/5/12, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] cm3, NOPTHREAD
> Para: dabenavidesd at yahoo.es, dragisha at m3w.org
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 25 de mayo, 2012 17:09
> 
>  > no, since we've lost self-hosted compiler (because
> PTHREADS is C code)  
>  > when compiling using PTHREADS capabilities. 
>  
> 
>  Again Daniel, this make no sense to me. 
> 
> 
> > You need a new compiler image 
> 
> 
>  
>  Again Daniel, this is wrong.   
> 
> 
>  
>   >  and a new RT image 
> 
> 
> 
> 
>   Again Daniel, this doesn't make complete sense to
> me.   
>   What do you mean "new RT image"? 
> 
> 
>  You need m3core, and then because its interface
> essentially changes (different type ids for thread and/or
> lock), you have to recompile everything else that you are
> going to use, with this new m3core -- i.e.  the entire
> dependency graph up to and including the executable.
> 
> 
> You do NOT need a new compiler.
> If it works, great. But you don't need it.
> 
> 
> If we hide the types behind object or such, then only m3core
> will need to be rebuild. That is the plan. And more so -- a
> command line to change between them.
> For now, the type ids vary.
> 
> 
> -DNOPTHREAD only directly changes m3core.
> The rest of the system can be compiled w/ or w/o it. But the
> new m3core causes a need for some rebuild.
> 
> 
>  - Jay
> 
> 
> ________________________________
> > Date: Fri, 25 May 2012 21:57:56 +0100 
> > From: dabenavidesd at yahoo.es
> 
> > Subject: Re: [M3devel] cm3, NOPTHREAD 
> > To: dragisha at m3w.org
> 
> > CC: jay.krell at cornell.edu;
> m3devel at elegosoft.com
> 
> >  
> > Hi all: 
> > no, since we've lost self-hosted compiler (because
> PTHREADS is C code)  
> > when compiling using PTHREADS capabilities. 
> > You need a new compiler image and a new RT image, if
> you want to do  
> > that; what you say, sounds like you can change that at
> build time, this  
> > is not the case. 
> > Thanks in advance 
> >  
> >  
> > --- El vie, 25/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?: 
> >  
> > De: Dragi?a Duri? <dragisha at m3w.org>
> 
> > Asunto: Re: [M3devel] cm3, NOPTHREAD 
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> 
> > CC: "Jay K" <jay.krell at cornell.edu>,
> "m3devel" <m3devel at elegosoft.com>
> 
> > Fecha: viernes, 25 de mayo, 2012 15:51 
> >  
> > Daniel, 
> >  
> > BUILDARGS is applied to all builds occuring while it's
> set. 
> >  
> > Have a nice day. 
> >  
> > dd 
> >  
> > On May 25, 2012, at 10:46 PM, Daniel Alejandro
> Benavides D. wrote: 
> >  
> > Hi all: 
> > such system will not compile everything using NOPTHREAD
> thing, but  
> > merely the compiler, so this doesn't help anything else
> than the  
> > compiler, if you want to build with your compiler that
> then you need a  
> > correct boot image. 
> > Thanks in advance 
> >  
> >  
> > --- El jue, 24/5/12, Dragi?a Duri?  
> > <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>>
> escribi?: 
> >  
> > De: Dragi?a Duri?  
> > <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>> 
> > Asunto: Re: [M3devel] cm3, NOPTHREAD 
> > Para: "Jay K"  
> > <jay.krell at cornell.edu<http:///mc/compose?to=jay.krell%40cornell.edu>> 
> > CC: "m3devel"  
> > <m3devel at elegosoft.com<http:///mc/compose?to=m3devel%40elegosoft.com>> 
> > Fecha: jueves, 24 de mayo, 2012 03:43 
> >  
> > I did 
> >  
> > export BUILDARGS="-DNOPTHREAD" 
> >  
> > before building packages/compiler. 
> >  
> > Didn't work. Built cm3 failed on first invocation with
> stack of three  
> > elements, topmost being NoteStackLocations. No other
> data. 
> >  
> > On May 24, 2012, at 1:07 AM, Jay K wrote: 
> >  
> > Do you mean did we make something "official" and put it
> somewhere to be  
> > tested and downloaded by the masses of Modula-3
> programmers who want to  
> > use both Modula-3 and user threads? I don't think so. 
> >  
> >  
> > Do it yourself? 
> >    (Try out scripts/python/make-dist.py?) 
> >  
> >  
> > It has always been easy from a m3makefile point of view
> to do it. 
> > You either use -DNOPTHREAD or such, or edit
> m3core/src/thread/m3makefile. 
> >  
> >  
> >  
> >  
>     
>         
>           
>   


From dabenavidesd at yahoo.es  Sat May 26 00:58:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 25 May 2012 23:58:34 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <1337985487.13774.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <1337986714.57733.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I think that you don't want that unless you want to use the OS source, I don't think this libraries make that sense, this libraries are just if you want is use this interface of your OS (Modula-3 are essentially different of theirs that's the main issue here).
I think we can do it, but the first alternative to test would be a NT since you can provide several schedulers in an OS version called RiAlto (you need to compile an relink everything). But then you wouldn't be using Win32 alone, you need to license not that EULA, or ULA, guess if DEC/Compaq did that, what did they paid for?
I don't know any other OS with that function, but perhaps I'm wrong.
Thanks in advance


--- El vie, 25/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] cm3, NOPTHREAD
> Para: dragisha at m3w.org, "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 25 de mayo, 2012 17:38
> Hi all:
> I'm thinking can press a key command to compile m3core with
> that option, no, you need to change the sources of the
> thing. That's for me new RT and new compiler, and if you
> want that do it, it's OK but for me, don't think it makes
> sense to do that in an automatic environment, that's why I
> tell you you can't do that in Modula-3 alone. If it were
> pure Modula-3 yes you could override a Thread interface with
> that option, but not here certainly.
> Thanks advance
> 
> 
> --- El vie, 25/5/12, Jay K <jay.krell at cornell.edu>
> escribi?:
> 
> > De: Jay K <jay.krell at cornell.edu>
> > Asunto: RE: [M3devel] cm3, NOPTHREAD
> > Para: dabenavidesd at yahoo.es,
> dragisha at m3w.org
> > CC: "m3devel" <m3devel at elegosoft.com>
> > Fecha: viernes, 25 de mayo, 2012 17:09
> > 
> >  > no, since we've lost self-hosted compiler
> (because
> > PTHREADS is C code)  
> >  > when compiling using PTHREADS capabilities.
> 
> >  
> > 
> >  Again Daniel, this make no sense to me. 
> > 
> > 
> > > You need a new compiler image 
> > 
> > 
> >  
> >  Again Daniel, this is wrong.   
> > 
> > 
> >  
> >   >  and a new RT image 
> > 
> > 
> > 
> > 
> >   Again Daniel, this doesn't make
> complete sense to
> > me.   
> >   What do you mean "new RT image"? 
> > 
> > 
> >  You need m3core, and then because its interface
> > essentially changes (different type ids for thread
> and/or
> > lock), you have to recompile everything else that you
> are
> > going to use, with this new m3core -- i.e.  the
> entire
> > dependency graph up to and including the executable.
> > 
> > 
> > You do NOT need a new compiler.
> > If it works, great. But you don't need it.
> > 
> > 
> > If we hide the types behind object or such, then only
> m3core
> > will need to be rebuild. That is the plan. And more so
> -- a
> > command line to change between them.
> > For now, the type ids vary.
> > 
> > 
> > -DNOPTHREAD only directly changes m3core.
> > The rest of the system can be compiled w/ or w/o it.
> But the
> > new m3core causes a need for some rebuild.
> > 
> > 
> >  - Jay
> > 
> > 
> > ________________________________
> > > Date: Fri, 25 May 2012 21:57:56 +0100 
> > > From: dabenavidesd at yahoo.es
> > 
> > > Subject: Re: [M3devel] cm3, NOPTHREAD 
> > > To: dragisha at m3w.org
> > 
> > > CC: jay.krell at cornell.edu;
> > m3devel at elegosoft.com
> > 
> > >  
> > > Hi all: 
> > > no, since we've lost self-hosted compiler
> (because
> > PTHREADS is C code)  
> > > when compiling using PTHREADS capabilities. 
> > > You need a new compiler image and a new RT image,
> if
> > you want to do  
> > > that; what you say, sounds like you can change
> that at
> > build time, this  
> > > is not the case. 
> > > Thanks in advance 
> > >  
> > >  
> > > --- El vie, 25/5/12, Dragi?a Duri? <dragisha at m3w.org>
> > escribi?: 
> > >  
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > 
> > > Asunto: Re: [M3devel] cm3, NOPTHREAD 
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > 
> > > CC: "Jay K" <jay.krell at cornell.edu>,
> > "m3devel" <m3devel at elegosoft.com>
> > 
> > > Fecha: viernes, 25 de mayo, 2012 15:51 
> > >  
> > > Daniel, 
> > >  
> > > BUILDARGS is applied to all builds occuring while
> it's
> > set. 
> > >  
> > > Have a nice day. 
> > >  
> > > dd 
> > >  
> > > On May 25, 2012, at 10:46 PM, Daniel Alejandro
> > Benavides D. wrote: 
> > >  
> > > Hi all: 
> > > such system will not compile everything using
> NOPTHREAD
> > thing, but  
> > > merely the compiler, so this doesn't help anything
> else
> > than the  
> > > compiler, if you want to build with your compiler
> that
> > then you need a  
> > > correct boot image. 
> > > Thanks in advance 
> > >  
> > >  
> > > --- El jue, 24/5/12, Dragi?a Duri?  
> > > <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>>
> > escribi?: 
> > >  
> > > De: Dragi?a Duri?  
> > > <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>> 
> > > Asunto: Re: [M3devel] cm3, NOPTHREAD 
> > > Para: "Jay K"  
> > > <jay.krell at cornell.edu<http:///mc/compose?to=jay.krell%40cornell.edu>> 
> > > CC: "m3devel"  
> > > <m3devel at elegosoft.com<http:///mc/compose?to=m3devel%40elegosoft.com>> 
> > > Fecha: jueves, 24 de mayo, 2012 03:43 
> > >  
> > > I did 
> > >  
> > > export BUILDARGS="-DNOPTHREAD" 
> > >  
> > > before building packages/compiler. 
> > >  
> > > Didn't work. Built cm3 failed on first invocation
> with
> > stack of three  
> > > elements, topmost being NoteStackLocations. No
> other
> > data. 
> > >  
> > > On May 24, 2012, at 1:07 AM, Jay K wrote: 
> > >  
> > > Do you mean did we make something "official" and
> put it
> > somewhere to be  
> > > tested and downloaded by the masses of Modula-3
> > programmers who want to  
> > > use both Modula-3 and user threads? I don't think
> so. 
> > >  
> > >  
> > > Do it yourself? 
> > >    (Try out
> scripts/python/make-dist.py?) 
> > >  
> > >  
> > > It has always been easy from a m3makefile point of
> view
> > to do it. 
> > > You either use -DNOPTHREAD or such, or edit
> > m3core/src/thread/m3makefile. 
> > >  
> > >  
> > >  
> > >  
> >     
> >         
> >           
> >
> 


From dabenavidesd at yahoo.es  Mon May 28 16:22:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 May 2012 15:22:24 +0100 (BST)
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20120528084705.E13302474003@birch.elegosoft.com>
Message-ID: <1338214944.4326.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi Jay:
Where are you testing this, or have you tested this on an Alpha, I might get access, but I notice you dropped the libdecnumber, stuff right?
Thanks in advance

--- El lun, 28/5/12, Jay Krell <jkrell at elego.de> escribi?:

> De: Jay Krell <jkrell at elego.de>
> Asunto: [M3commit] CVS Update: cm3
> Para: m3commit at elegosoft.com
> Fecha: lunes, 28 de mayo, 2012 05:47
> CVSROOT:    /usr/cvs
> Changes by:   
> jkrell at birch.    12/05/28 10:47:05
> 
> Modified files:
>     cm3/m3-sys/m3cc/gcc-4.6/: configure 
>     ./: configure 
>     cm3/m3-sys/m3cc/gcc-4.6/gcc/: Makefile.in
> auto-inc-dec.c 
>                
>                
>   basic-block.h builtins.c 
>                
>                
>   c-aux-info.c c-convert.c c-decl.c 
>                
>                
>   c-errors.c c-lang.c c-lang.h 
>                
>                
>   c-objc-common.c c-parser.c 
>                
>                
>   c-tree.h c-typeck.c calls.c 
>                
>                
>   cfgexpand.c cfgloop.h cgraph.c 
>                
>                
>   cgraph.h cgraphbuild.c 
>                
>                
>   cgraphunit.c combine.c configure 
>                
>                
>   configure.ac cppdefault.c 
>                
>                
>   cppdefault.h cppspec.c cse.c 
>                
>                
>   expr.c final.c fold-const.c gcc.c 
>                
>                
>   gccspec.c gcse.c gengtype-lex.c 
>                
>                
>   gengtype-lex.l gengtype.c 
>                
>                
>   gimple-fold.c gimple.c gimplify.c 
>                
>                
>   incpath.c intl.c ipa-cp.c 
>                
>                
>   ipa-inline.c ipa-prop.c ipa-prop.h 
>                
>                
>   ipa-ref.h ipa-utils.c ipa.c 
>                
>                
>   ira-build.c ira-conflicts.c 
>                
>                
>   ira-int.h ira.c ira.h libgcov.c 
>                
>                
>   loop-iv.c loop-unswitch.c opts.c 
>                
>                
>   passes.c postreload.c predict.c 
>                
>                
>   profile.c sched-vis.c 
>                
>                
>   sel-sched-dump.c store-motion.c 
>                
>                
>   stringpool.c targhooks.c toplev.c 
>                
>                
>   tree-cfg.c tree-chrec.c 
>                
>                
>   tree-complex.c tree-eh.c 
>                
>                
>   tree-flow.h tree-inline.c 
>                
>                
>   tree-nested.c tree-object-size.c 
>                
>                
>   tree-outof-ssa.c tree-parloops.c 
>                
>                
>   tree-pass.h tree-pretty-print.c 
>                
>                
>   tree-profile.c 
>                
>                
>   tree-scalar-evolution.c tree-sra.c 
>                
>                
>   tree-ssa-address.c 
>                
>                
>   tree-ssa-alias.c 
>                
>                
>   tree-ssa-copyrename.c 
>                
>                
>   tree-ssa-dce.c tree-ssa-dom.c 
>                
>                
>   tree-ssa-loop-ivopts.c 
>                
>                
>   tree-ssa-loop-manip.c 
>                
>                
>   tree-ssa-loop.c tree-ssa-phiopt.c 
>                
>                
>   tree-ssa-structalias.c 
>                
>                
>   tree-ssa-uncprop.c tree-ssa.c 
>                
>                
>   tree-vect-data-refs.c 
>                
>                
>   tree-vect-generic.c 
>                
>                
>   tree-vect-loop-manip.c 
>                
>                
>   tree-vect-loop.c 
>                
>                
>   tree-vect-patterns.c 
>                
>                
>   tree-vect-slp.c tree-vect-stmts.c 
>                
>                
>   tree-vrp.c tree.h unwind-c.c 
>                
>                
>   unwind-compat.c unwind-compat.h 
>                
>                
>   unwind-dw2-fde-compat.c 
>                
>                
>   unwind-dw2-fde-darwin.c 
>                
>                
>   unwind-dw2-fde-glibc.c 
>                
>                
>   unwind-dw2-fde.c unwind-dw2-fde.h 
>                
>                
>   unwind-dw2.c unwind-dw2.h 
>                
>                
>   unwind-generic.h unwind-pe.h 
>                
>                
>   unwind-sjlj.c value-prof.c 
>                
>                
>   var-tracking.c varpool.c web.c 
>     ./: Makefile.in auto-inc-dec.c
> basic-block.h builtins.c 
>         c-aux-info.c c-convert.c
> c-decl.c c-errors.c c-lang.c 
>         c-lang.h c-objc-common.c
> c-parser.c c-tree.h c-typeck.c 
>         calls.c cfgexpand.c
> cfgloop.h cgraph.c cgraph.h 
>         cgraphbuild.c cgraphunit.c
> combine.c configure configure.ac 
>         cppdefault.c cppdefault.h
> cppspec.c cse.c expr.c final.c 
>         fold-const.c gcc.c
> gccspec.c gcse.c gengtype-lex.c 
>         gengtype-lex.l gengtype.c
> gimple-fold.c gimple.c gimplify.c 
>         incpath.c intl.c ipa-cp.c
> ipa-inline.c ipa-prop.c ipa-prop.h 
>         ipa-ref.h ipa-utils.c ipa.c
> ira-build.c ira-conflicts.c 
>         ira-int.h ira.c ira.h
> libgcov.c loop-iv.c loop-unswitch.c 
>         opts.c passes.c
> postreload.c predict.c profile.c sched-vis.c 
>         sel-sched-dump.c
> store-motion.c stringpool.c targhooks.c 
>         toplev.c tree-cfg.c
> tree-chrec.c tree-complex.c tree-eh.c 
>         tree-flow.h tree-inline.c
> tree-nested.c tree-object-size.c 
>         tree-outof-ssa.c
> tree-parloops.c tree-pass.h 
>         tree-pretty-print.c
> tree-profile.c tree-scalar-evolution.c 
>         tree-sra.c
> tree-ssa-address.c tree-ssa-alias.c 
>         tree-ssa-copyrename.c
> tree-ssa-dce.c tree-ssa-dom.c 
>         tree-ssa-loop-ivopts.c
> tree-ssa-loop-manip.c tree-ssa-loop.c 
>         tree-ssa-phiopt.c
> tree-ssa-structalias.c tree-ssa-uncprop.c 
>         tree-ssa.c
> tree-vect-data-refs.c tree-vect-generic.c 
>         tree-vect-loop-manip.c
> tree-vect-loop.c tree-vect-patterns.c 
>         tree-vect-slp.c
> tree-vect-stmts.c tree-vrp.c tree.h 
>         unwind-c.c unwind-compat.c
> unwind-compat.h 
>         unwind-dw2-fde-compat.c
> unwind-dw2-fde-darwin.c 
>         unwind-dw2-fde-glibc.c
> unwind-dw2-fde.c unwind-dw2-fde.h 
>         unwind-dw2.c unwind-dw2.h
> unwind-generic.h unwind-pe.h 
>         unwind-sjlj.c value-prof.c
> var-tracking.c varpool.c web.c 
>     cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
> darwin-protos.h darwin.c 
>                
>                
>          darwin.h 
>     ./: darwin-protos.h darwin.c darwin.h 
>     cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
> crtfastmath.c 
>                
>                
>               crtprec.c 
>                
>                
>              
> cygming-crtbegin.c 
>                
>                
>              
> cygming-crtend.c 
>                
>                
>               darwin.h
> driver-i386.c 
>                
>                
>               gmon-sol2.c
> i386.c 
>                
>                
>              
> netware-crt0.c 
>     ./: crtfastmath.c crtprec.c
> cygming-crtbegin.c cygming-crtend.c 
>         darwin.h driver-i386.c
> gmon-sol2.c i386.c netware-crt0.c 
>     cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/: lto.c 
>     ./: lto.c 
>     cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
> line-map.h 
> 
> Log message:
>     work in progress -- can compile
> everything now, but float exception right away
> 
> 


From hendrik at topoi.pooq.com  Mon May 28 18:50:24 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 12:50:24 -0400
Subject: [M3devel] portable hosting
In-Reply-To: <C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
	<C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>
Message-ID: <20120528165024.GA7021@topoi.pooq.com>

On Sun, May 20, 2012 at 02:32:14PM -0700, Jay wrote:
> 
> Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.

Would it be more or less difficult than writing a code generator that 
generated C or C++ code?  THe code generator could do the rewrite for 
you.  Bt it wouldn't be very readable code.


From hendrik at topoi.pooq.com  Mon May 28 18:55:44 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 12:55:44 -0400
Subject: [M3devel] using interpreter as a bootstrap
In-Reply-To: <20120522024455.GA9667@topoi.pooq.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
	<20120521184316.GA10750@topoi.pooq.com>
	<20120521211045.GA7596@topoi.pooq.com>
	<COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
	<20120522024455.GA9667@topoi.pooq.com>
Message-ID: <20120528165544.GB7021@topoi.pooq.com>

On Mon, May 21, 2012 at 10:44:55PM -0400, Hendrik Boom wrote:
> On Mon, May 21, 2012 at 10:50:44PM +0000, Jay K wrote:
> > 
> > Is C-- adequately maintained? I don't think so.
> 
> Bugs get fixed.  And there's very few of them reported.  But it's not 
> clear to me whether that's because it's so well-written, or because 
> almost no one uses it.
> 
> Active development seems to be at a stendstill.
> 
> > I'm also not super keen on depending on other projects.
> > We'll see..
> 
> I mentioned C-- because its implementation exists in both interpreted 
> and compiled versions.  That seems to be a way to bootstrap the whole 
> thing.  We could interpret the compiler using some portable 
> intermediate code -- we could even restrict the interpreter to provide 
> only a 32-bit machine, and then cross-compile from the interpreted 
> compiler to whatever machine we're installing on.  Since every Modula 
> 3 compiler seems to be able to generate code for every platform, 
> this is a way to avoid having a separate binary bootstrap for every 
> platform.

Of all the machies we already generatte code for, which has the easiest 
machine code to interpret?  We don't really have to invent a new 
interpretable object code -- we already have one.  Remember, the 
bootstrap only has to implement enough system resources to compile the 
core system.

-- hendrik


> 
> And a distro, like Debian, could have a source package that doesn't 
> need to have itself installed before it it can be installed.
> 
> -- hendrik
> 


From hendrik at topoi.pooq.com  Mon May 28 19:47:00 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 13:47:00 -0400
Subject: [M3devel] Packaging for Debian
Message-ID: <20120528174700.GA7249@topoi.pooq.com>

Wasn't there a modula 3 package for Debian long long ago (maybe in the 
days of woody?), based on pm3?  Would it be possible to examine it and 
figure out how to adapt it to currently maintained cm3?  How did then 
solve tthe bootstrap problem?

-- hendrik


From dabenavidesd at yahoo.es  Mon May 28 21:17:43 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 May 2012 20:17:43 +0100 (BST)
Subject: [M3devel] Packaging for Debian
In-Reply-To: <20120528174700.GA7249@topoi.pooq.com>
Message-ID: <1338232663.14445.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
Yes, and you could use it as in a low priority package in later releases I believe, but that said, I still miss the how much of it could boot cm3, I remember I tried to recompile NT386GNU for use m3browser (pm3 had it only  for Unix targets) and I could but failed after executing due some broken dynamic libraries issue, and couldn't understand why, but you could easily bootstrap from Unix targets to NT386GNU, I remember you couldn't do it viceversa, that is, from a NT386GNU to a Unix target, I still think that cross-boot problem was essential to understand the differences among a Unix and a Win32 API in general, but I didn't have many platforms to test it for that matter, you know, sort of making a cross product might get to the point to which is the quintessential bootstrap code for a Modula-3 compiler.
Thanks in advance

PD I still have the 20+ CD's of the Distro if somebody wants a copy or so I could post it on-line  

--- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] Packaging for Debian
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 28 de mayo, 2012 12:47
> Wasn't there a modula 3 package for
> Debian long long ago (maybe in the 
> days of woody?), based on pm3?  Would it be possible to
> examine it and 
> figure out how to adapt it to currently maintained
> cm3?  How did then 
> solve tthe bootstrap problem?
> 
> -- hendrik
> 


From dabenavidesd at yahoo.es  Mon May 28 23:04:41 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 May 2012 22:04:41 +0100 (BST)
Subject: [M3devel] using interpreter as a bootstrap
In-Reply-To: <20120528165544.GB7021@topoi.pooq.com>
Message-ID: <1338239081.37249.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I guess that is the same as asking with a high-degree of compatibility a X mating machine core of a M3CG, and I believe it is the VAX-9000, it supported a CISC/RISC-core, but this was a huge machine, and so I think could be handy to get a sample of execution traces and match to  every other possible one.
I believe they made a RR on that machine:

http://books.google.com.co/books?id=U8QpAQAAMAAJ&q=%22DEC+has%22#search_anchor

Thanks in advance


--- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] using interpreter as a bootstrap
> Para: m3devel at elegosoft.com
> Fecha: lunes, 28 de mayo, 2012 11:55
> On Mon, May 21, 2012 at 10:44:55PM
> -0400, Hendrik Boom wrote:
> > On Mon, May 21, 2012 at 10:50:44PM +0000, Jay K wrote:
> > > 
> > > Is C-- adequately maintained? I don't think so.
> > 
> > Bugs get fixed.  And there's very few of them
> reported.  But it's not 
> > clear to me whether that's because it's so
> well-written, or because 
> > almost no one uses it.
> > 
> > Active development seems to be at a stendstill.
> > 
> > > I'm also not super keen on depending on other
> projects.
> > > We'll see..
> > 
> > I mentioned C-- because its implementation exists in
> both interpreted 
> > and compiled versions.  That seems to be a way to
> bootstrap the whole 
> > thing.  We could interpret the compiler using some
> portable 
> > intermediate code -- we could even restrict the
> interpreter to provide 
> > only a 32-bit machine, and then cross-compile from the
> interpreted 
> > compiler to whatever machine we're installing on. 
> Since every Modula 
> > 3 compiler seems to be able to generate code for every
> platform, 
> > this is a way to avoid having a separate binary
> bootstrap for every 
> > platform.
> 
> Of all the machies we already generatte code for, which has
> the easiest 
> machine code to interpret?  We don't really have to
> invent a new 
> interpretable object code -- we already have one. 
> Remember, the 
> bootstrap only has to implement enough system resources to
> compile the 
> core system.
> 
> -- hendrik
> 
> 
> > 
> > And a distro, like Debian, could have a source package
> that doesn't 
> > need to have itself installed before it it can be
> installed.
> > 
> > -- hendrik
> > 
> 


From dabenavidesd at yahoo.es  Mon May 28 23:22:36 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 May 2012 22:22:36 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <20120528165024.GA7021@topoi.pooq.com>
Message-ID: <1338240156.6219.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
or better make an assembly-coded C compiler in a Java language processor, and cross-boot assemble from a Modula-3 environment there so you could bootstrap a M3CG-system there.
Thanks in advance

--- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] portable hosting
> Para: m3devel at elegosoft.com
> Fecha: lunes, 28 de mayo, 2012 11:50
> On Sun, May 20, 2012 at 02:32:14PM
> -0700, Jay wrote:
> > 
> > Btw, rewriting all of m3front in C or C++ or Java
> probably wouldn't be very difficult.
> 
> Would it be more or less difficult than writing a code
> generator that 
> generated C or C++ code?  THe code generator could do
> the rewrite for 
> you.  Bt it wouldn't be very readable code.
> 


From hendrik at topoi.pooq.com  Tue May 29 00:55:45 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 18:55:45 -0400
Subject: [M3devel] Packaging for Debian
In-Reply-To: <1338232663.14445.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <20120528174700.GA7249@topoi.pooq.com>
	<1338232663.14445.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <20120528225545.GB10489@topoi.pooq.com>

On Mon, May 28, 2012 at 08:17:43PM +0100, Daniel Alejandro Benavides D. wrote:
> 
> PD I still have the 20+ CD's of the Distro if somebody wants a copy or so I could post it on-line  

20+ CD's of Which distro?  I was thinking of getting a source package 
from Debian woody.  They still have packages for those ancient releases 
in an archive somewhere.

-- hendrik


From hendrik at topoi.pooq.com  Tue May 29 01:05:05 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 19:05:05 -0400
Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
In-Reply-To: <COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
Message-ID: <20120528230505.GC10489@topoi.pooq.com>

Trying a cross-compilation now.

On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote:
> 
> You might as well just use something in scripts to rebuild the entire 
> system.It isn't so difficult nor takes very long.     
>
> Get a working > cm3 on any system.
      cd scripts/python
      ./boot1.py <target-such-as-I386_LINUX>      That will produce a "bootstrap" archive.    Copy it to the "new" system.      Extract it.      Cd into it.      Look at the top of Makefile and see if it seems reasonable (we should use autoconf here).    run make.     That should give you a working cm3 for the new system.      Put that on path, e.g.:       su        rm -rf /usr/local/cm3       mkdir -p /usr/local/cm3/bin        cp cm3 /usr/local/cm3/bin        exit         PATH=/usr/local/cm3/bin:$PATH     cd to scripts/python in the source tree on the new system.    Then run ./boot2.sh       Then ./make-dist.py.    That should give you the entire system newly built, and a .deb.  If you already have a working cm3 on the system you want to run it on  cd scripts/python   ./upgrade.py    ./make-dist.py     I'd really like to get to the

Did that, as 
hendrik at april:~/cm3/cm3/scripts/python$ export LIBRARY_PATH=
hendrik at april:~/cm3/cm3/scripts/python$ ./boot1.py I386_LINUX

and it compiled for a ling time, then failed with

new source -> compiling Utils.m3
new source -> compiling WebFile.m3
new source -> compiling Main.m3
building makefile -> make.cm3
 ==> /farhome/hendrik/cm3/cm3/m3-sys/cm3 done

Traceback (most recent call last):
  File "./boot1.py", line 18, in <module>
    Boot();
  File "/farhome/hendrik/cm3/cm3/scripts/python/pylib.py", line 1248, in Boot
    for a in os.listdir(os.path.join(Root, dir, Config)):
OSError: [Errno 2] No such file or directory: '/farhome/hendrik/cm3/cm3/m3-sys/m3cc/I386_LINUX'
hendrik at april:~/cm3/cm3/scripts/python$


So I took a look for /farhome/hendrik/cm3/cm3/m3-sys/m3cc/I386_LINUX

and in directory /farhome/hendrik/cm3/cm3/m3-sys/m3cc/

I found 

drwxr-xr-x 12 hendrik hendrik 4096 May 28 14:39 .
  drwxr-xr-x 27 hendrik hendrik 4096 May 16 18:08 ..
  drwxr-xr-x  6 hendrik hendrik 4096 May 28 14:56 AMD64_LINUX
  drwxr-xr-x  6 hendrik hendrik 4096 May 28 15:21 AMD64_LINUX-I386_LINUX
  drwxr-xr-x  2 hendrik hendrik 4096 May 16 17:50 CVS
  
but no I386-LINUX

-- hendrik


From hendrik at topoi.pooq.com  Tue May 29 01:08:24 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 19:08:24 -0400
Subject: [M3devel] failure to cross-install
In-Reply-To: <20120528230505.GC10489@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120528230505.GC10489@topoi.pooq.com>
Message-ID: <20120528230824.GA24085@topoi.pooq.com>

(forgot to change the subject)

(It's possible that the weird directory name had been generated earlier 
when I tried to do the same thing without having emptied LIBRARY_PATH, 
but I definietly specified it for this run.

-- hendrik

On Mon, May 28, 2012 at 07:05:05PM -0400, Hendrik Boom wrote:
> Trying a cross-compilation now.
> 
> On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote:
> > 
> > You might as well just use something in scripts to rebuild the entire 
> > system.It isn't so difficult nor takes very long.     
> >
> > Get a working > cm3 on any system.
>       cd scripts/python
>       ./boot1.py <target-such-as-I386_LINUX>      That will produce a "bootstrap" archive.    Copy it to the "new" system.      Extract it.      Cd into it.      Look at the top of Makefile and see if it seems reasonable (we should use autoconf here).    run make.     That should give you a working cm3 for the new system.      Put that on path, e.g.:       su        rm -rf /usr/local/cm3       mkdir -p /usr/local/cm3/bin        cp cm3 /usr/local/cm3/bin        exit         PATH=/usr/local/cm3/bin:$PATH     cd to scripts/python in the source tree on the new system.    Then run ./boot2.sh       Then ./make-dist.py.    That should give you the entire system newly built, and a .deb.  If you already have a working cm3 on the system you want to run it on  cd scripts/python   ./upgrade.py    ./make-dist.py     I'd really like to get to the
> 
> Did that, as 
> hendrik at april:~/cm3/cm3/scripts/python$ export LIBRARY_PATH=
> hendrik at april:~/cm3/cm3/scripts/python$ ./boot1.py I386_LINUX
> 
> and it compiled for a ling time, then failed with
> 
> new source -> compiling Utils.m3
> new source -> compiling WebFile.m3
> new source -> compiling Main.m3
> building makefile -> make.cm3
>  ==> /farhome/hendrik/cm3/cm3/m3-sys/cm3 done
> 
> Traceback (most recent call last):
>   File "./boot1.py", line 18, in <module>
>     Boot();
>   File "/farhome/hendrik/cm3/cm3/scripts/python/pylib.py", line 1248, in Boot
>     for a in os.listdir(os.path.join(Root, dir, Config)):
> OSError: [Errno 2] No such file or directory: '/farhome/hendrik/cm3/cm3/m3-sys/m3cc/I386_LINUX'
> hendrik at april:~/cm3/cm3/scripts/python$
> 
> 
> So I took a look for /farhome/hendrik/cm3/cm3/m3-sys/m3cc/I386_LINUX
> 
> and in directory /farhome/hendrik/cm3/cm3/m3-sys/m3cc/
> 
> I found 
> 
> drwxr-xr-x 12 hendrik hendrik 4096 May 28 14:39 .
>   drwxr-xr-x 27 hendrik hendrik 4096 May 16 18:08 ..
>   drwxr-xr-x  6 hendrik hendrik 4096 May 28 14:56 AMD64_LINUX
>   drwxr-xr-x  6 hendrik hendrik 4096 May 28 15:21 AMD64_LINUX-I386_LINUX
>   drwxr-xr-x  2 hendrik hendrik 4096 May 16 17:50 CVS
>   
> but no I386-LINUX
> 
> -- hendrik


From dabenavidesd at yahoo.es  Tue May 29 01:22:45 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 May 2012 00:22:45 +0100 (BST)
Subject: [M3devel] Packaging for Debian
In-Reply-To: <20120528225545.GB10489@topoi.pooq.com>
Message-ID: <1338247365.16482.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
Debian Woody src and i386 distribution (3.0) succesor Sarge 3.1 in CD's, but you can boot with two floppies, etc ...
This was the last distro that worked with that packaged pm3 that I know
Thanks in advance

--- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] Packaging for Debian
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 28 de mayo, 2012 17:55
> On Mon, May 28, 2012 at 08:17:43PM
> +0100, Daniel Alejandro Benavides D. wrote:
> > 
> > PD I still have the 20+ CD's of the Distro if somebody
> wants a copy or so I could post it on-line  
> 
> 20+ CD's of Which distro?  I was thinking of getting a
> source package 
> from Debian woody.  They still have packages for those
> ancient releases 
> in an archive somewhere.
> 
> -- hendrik
> 


From jay.krell at cornell.edu  Tue May 29 06:30:00 2012
From: jay.krell at cornell.edu (Jay)
Date: Mon, 28 May 2012 21:30:00 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <1338214944.4326.YahooMailClassic@web29705.mail.ird.yahoo.com>
References: <1338214944.4326.YahooMailClassic@web29705.mail.ird.yahoo.com>
Message-ID: <07F31967-EDA5-4CD7-975C-11F428381AB8@gmail.com>

Don't worry about it. I will test each platform or get others to before enabling, at least some popular majority of them. I no longer have any Alphas. Eventually I might ask for ssh access to an Alpha or reacquire hardware. Anyway, don't worry. I generally know what I'm doing.

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 28, 2012, at 7:22 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi Jay:
> Where are you testing this, or have you tested this on an Alpha, I might get access, but I notice you dropped the libdecnumber, stuff right?
> Thanks in advance
> 
> --- El lun, 28/5/12, Jay Krell <jkrell at elego.de> escribi?:
> 
>> De: Jay Krell <jkrell at elego.de>
>> Asunto: [M3commit] CVS Update: cm3
>> Para: m3commit at elegosoft.com
>> Fecha: lunes, 28 de mayo, 2012 05:47
>> CVSROOT:    /usr/cvs
>> Changes by:   
>> jkrell at birch.    12/05/28 10:47:05
>> 
>> Modified files:
>>    cm3/m3-sys/m3cc/gcc-4.6/: configure 
>>    ./: configure 
>>    cm3/m3-sys/m3cc/gcc-4.6/gcc/: Makefile.in
>> auto-inc-dec.c 
>> 
>> 
>>  basic-block.h builtins.c 
>> 
>> 
>>  c-aux-info.c c-convert.c c-decl.c 
>> 
>> 
>>  c-errors.c c-lang.c c-lang.h 
>> 
>> 
>>  c-objc-common.c c-parser.c 
>> 
>> 
>>  c-tree.h c-typeck.c calls.c 
>> 
>> 
>>  cfgexpand.c cfgloop.h cgraph.c 
>> 
>> 
>>  cgraph.h cgraphbuild.c 
>> 
>> 
>>  cgraphunit.c combine.c configure 
>> 
>> 
>>  configure.ac cppdefault.c 
>> 
>> 
>>  cppdefault.h cppspec.c cse.c 
>> 
>> 
>>  expr.c final.c fold-const.c gcc.c 
>> 
>> 
>>  gccspec.c gcse.c gengtype-lex.c 
>> 
>> 
>>  gengtype-lex.l gengtype.c 
>> 
>> 
>>  gimple-fold.c gimple.c gimplify.c 
>> 
>> 
>>  incpath.c intl.c ipa-cp.c 
>> 
>> 
>>  ipa-inline.c ipa-prop.c ipa-prop.h 
>> 
>> 
>>  ipa-ref.h ipa-utils.c ipa.c 
>> 
>> 
>>  ira-build.c ira-conflicts.c 
>> 
>> 
>>  ira-int.h ira.c ira.h libgcov.c 
>> 
>> 
>>  loop-iv.c loop-unswitch.c opts.c 
>> 
>> 
>>  passes.c postreload.c predict.c 
>> 
>> 
>>  profile.c sched-vis.c 
>> 
>> 
>>  sel-sched-dump.c store-motion.c 
>> 
>> 
>>  stringpool.c targhooks.c toplev.c 
>> 
>> 
>>  tree-cfg.c tree-chrec.c 
>> 
>> 
>>  tree-complex.c tree-eh.c 
>> 
>> 
>>  tree-flow.h tree-inline.c 
>> 
>> 
>>  tree-nested.c tree-object-size.c 
>> 
>> 
>>  tree-outof-ssa.c tree-parloops.c 
>> 
>> 
>>  tree-pass.h tree-pretty-print.c 
>> 
>> 
>>  tree-profile.c 
>> 
>> 
>>  tree-scalar-evolution.c tree-sra.c 
>> 
>> 
>>  tree-ssa-address.c 
>> 
>> 
>>  tree-ssa-alias.c 
>> 
>> 
>>  tree-ssa-copyrename.c 
>> 
>> 
>>  tree-ssa-dce.c tree-ssa-dom.c 
>> 
>> 
>>  tree-ssa-loop-ivopts.c 
>> 
>> 
>>  tree-ssa-loop-manip.c 
>> 
>> 
>>  tree-ssa-loop.c tree-ssa-phiopt.c 
>> 
>> 
>>  tree-ssa-structalias.c 
>> 
>> 
>>  tree-ssa-uncprop.c tree-ssa.c 
>> 
>> 
>>  tree-vect-data-refs.c 
>> 
>> 
>>  tree-vect-generic.c 
>> 
>> 
>>  tree-vect-loop-manip.c 
>> 
>> 
>>  tree-vect-loop.c 
>> 
>> 
>>  tree-vect-patterns.c 
>> 
>> 
>>  tree-vect-slp.c tree-vect-stmts.c 
>> 
>> 
>>  tree-vrp.c tree.h unwind-c.c 
>> 
>> 
>>  unwind-compat.c unwind-compat.h 
>> 
>> 
>>  unwind-dw2-fde-compat.c 
>> 
>> 
>>  unwind-dw2-fde-darwin.c 
>> 
>> 
>>  unwind-dw2-fde-glibc.c 
>> 
>> 
>>  unwind-dw2-fde.c unwind-dw2-fde.h 
>> 
>> 
>>  unwind-dw2.c unwind-dw2.h 
>> 
>> 
>>  unwind-generic.h unwind-pe.h 
>> 
>> 
>>  unwind-sjlj.c value-prof.c 
>> 
>> 
>>  var-tracking.c varpool.c web.c 
>>    ./: Makefile.in auto-inc-dec.c
>> basic-block.h builtins.c 
>>        c-aux-info.c c-convert.c
>> c-decl.c c-errors.c c-lang.c 
>>        c-lang.h c-objc-common.c
>> c-parser.c c-tree.h c-typeck.c 
>>        calls.c cfgexpand.c
>> cfgloop.h cgraph.c cgraph.h 
>>        cgraphbuild.c cgraphunit.c
>> combine.c configure configure.ac 
>>        cppdefault.c cppdefault.h
>> cppspec.c cse.c expr.c final.c 
>>        fold-const.c gcc.c
>> gccspec.c gcse.c gengtype-lex.c 
>>        gengtype-lex.l gengtype.c
>> gimple-fold.c gimple.c gimplify.c 
>>        incpath.c intl.c ipa-cp.c
>> ipa-inline.c ipa-prop.c ipa-prop.h 
>>        ipa-ref.h ipa-utils.c ipa.c
>> ira-build.c ira-conflicts.c 
>>        ira-int.h ira.c ira.h
>> libgcov.c loop-iv.c loop-unswitch.c 
>>        opts.c passes.c
>> postreload.c predict.c profile.c sched-vis.c 
>>        sel-sched-dump.c
>> store-motion.c stringpool.c targhooks.c 
>>        toplev.c tree-cfg.c
>> tree-chrec.c tree-complex.c tree-eh.c 
>>        tree-flow.h tree-inline.c
>> tree-nested.c tree-object-size.c 
>>        tree-outof-ssa.c
>> tree-parloops.c tree-pass.h 
>>        tree-pretty-print.c
>> tree-profile.c tree-scalar-evolution.c 
>>        tree-sra.c
>> tree-ssa-address.c tree-ssa-alias.c 
>>        tree-ssa-copyrename.c
>> tree-ssa-dce.c tree-ssa-dom.c 
>>        tree-ssa-loop-ivopts.c
>> tree-ssa-loop-manip.c tree-ssa-loop.c 
>>        tree-ssa-phiopt.c
>> tree-ssa-structalias.c tree-ssa-uncprop.c 
>>        tree-ssa.c
>> tree-vect-data-refs.c tree-vect-generic.c 
>>        tree-vect-loop-manip.c
>> tree-vect-loop.c tree-vect-patterns.c 
>>        tree-vect-slp.c
>> tree-vect-stmts.c tree-vrp.c tree.h 
>>        unwind-c.c unwind-compat.c
>> unwind-compat.h 
>>        unwind-dw2-fde-compat.c
>> unwind-dw2-fde-darwin.c 
>>        unwind-dw2-fde-glibc.c
>> unwind-dw2-fde.c unwind-dw2-fde.h 
>>        unwind-dw2.c unwind-dw2.h
>> unwind-generic.h unwind-pe.h 
>>        unwind-sjlj.c value-prof.c
>> var-tracking.c varpool.c web.c 
>>    cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
>> darwin-protos.h darwin.c 
>> 
>> 
>>         darwin.h 
>>    ./: darwin-protos.h darwin.c darwin.h 
>>    cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
>> crtfastmath.c 
>> 
>> 
>>              crtprec.c 
>> 
>> 
>> 
>> cygming-crtbegin.c 
>> 
>> 
>> 
>> cygming-crtend.c 
>> 
>> 
>>              darwin.h
>> driver-i386.c 
>> 
>> 
>>              gmon-sol2.c
>> i386.c 
>> 
>> 
>> 
>> netware-crt0.c 
>>    ./: crtfastmath.c crtprec.c
>> cygming-crtbegin.c cygming-crtend.c 
>>        darwin.h driver-i386.c
>> gmon-sol2.c i386.c netware-crt0.c 
>>    cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/: lto.c 
>>    ./: lto.c 
>>    cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
>> line-map.h 
>> 
>> Log message:
>>    work in progress -- can compile
>> everything now, but float exception right away
>> 
>> 


From dabenavidesd at yahoo.es  Tue May 29 20:44:26 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 May 2012 19:44:26 +0100 (BST)
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <07F31967-EDA5-4CD7-975C-11F428381AB8@gmail.com>
Message-ID: <1338317066.3447.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
good one, there isn't high-end user needs lately here, so I guess we shouldn't ask if we want to support other machines than just PC, perhaps, we should check more platforms at that level.
Any NT would not be affected but anything else is, HW for testing purposes isn't supported by NT (like debuggers), so there it isn't too much to support for that (lying on MIPS32, and Portable devices sometimes are RISC systems, now what is not aiming NT are desktops but bigger machines) but they are growing down so I don't know if they will become available again.
Thanks of Modula-3 hackers there is still more systems to check for all if interested in any. 
Thanks in advance

--- El lun, 28/5/12, Jay <jay.krell at cornell.edu> escribi?:

> De: Jay <jay.krell at cornell.edu>
> Asunto: Re: [M3commit] CVS Update: cm3
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "<m3commit at elegosoft.com>" <m3commit at elegosoft.com>, "<m3devel at elegosoft.com>" <m3devel at elegosoft.com>
> Fecha: lunes, 28 de mayo, 2012 23:30
> Don't worry about it. I will test
> each platform or get others to before enabling, at least
> some popular majority of them. I no longer have any Alphas.
> Eventually I might ask for ssh access to an Alpha or
> reacquire hardware. Anyway, don't worry. I generally know
> what I'm doing.
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On May 28, 2012, at 7:22 AM, "Daniel Alejandro Benavides D."
> <dabenavidesd at yahoo.es>
> wrote:
> 
> > Hi Jay:
> > Where are you testing this, or have you tested this on
> an Alpha, I might get access, but I notice you dropped the
> libdecnumber, stuff right?
> > Thanks in advance
> > 
> > --- El lun, 28/5/12, Jay Krell <jkrell at elego.de>
> escribi?:
> > 
> >> De: Jay Krell <jkrell at elego.de>
> >> Asunto: [M3commit] CVS Update: cm3
> >> Para: m3commit at elegosoft.com
> >> Fecha: lunes, 28 de mayo, 2012 05:47
> >> CVSROOT:    /usr/cvs
> >> Changes by:   
> >> jkrell at birch.    12/05/28 10:47:05
> >> 
> >> Modified files:
> >>    cm3/m3-sys/m3cc/gcc-4.6/: configure 
> >>    ./: configure 
> >>    cm3/m3-sys/m3cc/gcc-4.6/gcc/:
> Makefile.in
> >> auto-inc-dec.c 
> >> 
> >> 
> >>  basic-block.h builtins.c 
> >> 
> >> 
> >>  c-aux-info.c c-convert.c c-decl.c 
> >> 
> >> 
> >>  c-errors.c c-lang.c c-lang.h 
> >> 
> >> 
> >>  c-objc-common.c c-parser.c 
> >> 
> >> 
> >>  c-tree.h c-typeck.c calls.c 
> >> 
> >> 
> >>  cfgexpand.c cfgloop.h cgraph.c 
> >> 
> >> 
> >>  cgraph.h cgraphbuild.c 
> >> 
> >> 
> >>  cgraphunit.c combine.c configure 
> >> 
> >> 
> >>  configure.ac cppdefault.c 
> >> 
> >> 
> >>  cppdefault.h cppspec.c cse.c 
> >> 
> >> 
> >>  expr.c final.c fold-const.c gcc.c 
> >> 
> >> 
> >>  gccspec.c gcse.c gengtype-lex.c 
> >> 
> >> 
> >>  gengtype-lex.l gengtype.c 
> >> 
> >> 
> >>  gimple-fold.c gimple.c gimplify.c 
> >> 
> >> 
> >>  incpath.c intl.c ipa-cp.c 
> >> 
> >> 
> >>  ipa-inline.c ipa-prop.c ipa-prop.h 
> >> 
> >> 
> >>  ipa-ref.h ipa-utils.c ipa.c 
> >> 
> >> 
> >>  ira-build.c ira-conflicts.c 
> >> 
> >> 
> >>  ira-int.h ira.c ira.h libgcov.c 
> >> 
> >> 
> >>  loop-iv.c loop-unswitch.c opts.c 
> >> 
> >> 
> >>  passes.c postreload.c predict.c 
> >> 
> >> 
> >>  profile.c sched-vis.c 
> >> 
> >> 
> >>  sel-sched-dump.c store-motion.c 
> >> 
> >> 
> >>  stringpool.c targhooks.c toplev.c 
> >> 
> >> 
> >>  tree-cfg.c tree-chrec.c 
> >> 
> >> 
> >>  tree-complex.c tree-eh.c 
> >> 
> >> 
> >>  tree-flow.h tree-inline.c 
> >> 
> >> 
> >>  tree-nested.c tree-object-size.c 
> >> 
> >> 
> >>  tree-outof-ssa.c tree-parloops.c 
> >> 
> >> 
> >>  tree-pass.h tree-pretty-print.c 
> >> 
> >> 
> >>  tree-profile.c 
> >> 
> >> 
> >>  tree-scalar-evolution.c tree-sra.c 
> >> 
> >> 
> >>  tree-ssa-address.c 
> >> 
> >> 
> >>  tree-ssa-alias.c 
> >> 
> >> 
> >>  tree-ssa-copyrename.c 
> >> 
> >> 
> >>  tree-ssa-dce.c tree-ssa-dom.c 
> >> 
> >> 
> >>  tree-ssa-loop-ivopts.c 
> >> 
> >> 
> >>  tree-ssa-loop-manip.c 
> >> 
> >> 
> >>  tree-ssa-loop.c tree-ssa-phiopt.c 
> >> 
> >> 
> >>  tree-ssa-structalias.c 
> >> 
> >> 
> >>  tree-ssa-uncprop.c tree-ssa.c 
> >> 
> >> 
> >>  tree-vect-data-refs.c 
> >> 
> >> 
> >>  tree-vect-generic.c 
> >> 
> >> 
> >>  tree-vect-loop-manip.c 
> >> 
> >> 
> >>  tree-vect-loop.c 
> >> 
> >> 
> >>  tree-vect-patterns.c 
> >> 
> >> 
> >>  tree-vect-slp.c tree-vect-stmts.c 
> >> 
> >> 
> >>  tree-vrp.c tree.h unwind-c.c 
> >> 
> >> 
> >>  unwind-compat.c unwind-compat.h 
> >> 
> >> 
> >>  unwind-dw2-fde-compat.c 
> >> 
> >> 
> >>  unwind-dw2-fde-darwin.c 
> >> 
> >> 
> >>  unwind-dw2-fde-glibc.c 
> >> 
> >> 
> >>  unwind-dw2-fde.c unwind-dw2-fde.h 
> >> 
> >> 
> >>  unwind-dw2.c unwind-dw2.h 
> >> 
> >> 
> >>  unwind-generic.h unwind-pe.h 
> >> 
> >> 
> >>  unwind-sjlj.c value-prof.c 
> >> 
> >> 
> >>  var-tracking.c varpool.c web.c 
> >>    ./: Makefile.in auto-inc-dec.c
> >> basic-block.h builtins.c 
> >>        c-aux-info.c
> c-convert.c
> >> c-decl.c c-errors.c c-lang.c 
> >>        c-lang.h
> c-objc-common.c
> >> c-parser.c c-tree.h c-typeck.c 
> >>        calls.c cfgexpand.c
> >> cfgloop.h cgraph.c cgraph.h 
> >>        cgraphbuild.c
> cgraphunit.c
> >> combine.c configure configure.ac 
> >>        cppdefault.c
> cppdefault.h
> >> cppspec.c cse.c expr.c final.c 
> >>        fold-const.c gcc.c
> >> gccspec.c gcse.c gengtype-lex.c 
> >>        gengtype-lex.l
> gengtype.c
> >> gimple-fold.c gimple.c gimplify.c 
> >>        incpath.c intl.c
> ipa-cp.c
> >> ipa-inline.c ipa-prop.c ipa-prop.h 
> >>        ipa-ref.h ipa-utils.c
> ipa.c
> >> ira-build.c ira-conflicts.c 
> >>        ira-int.h ira.c ira.h
> >> libgcov.c loop-iv.c loop-unswitch.c 
> >>        opts.c passes.c
> >> postreload.c predict.c profile.c sched-vis.c 
> >>        sel-sched-dump.c
> >> store-motion.c stringpool.c targhooks.c 
> >>        toplev.c tree-cfg.c
> >> tree-chrec.c tree-complex.c tree-eh.c 
> >>        tree-flow.h
> tree-inline.c
> >> tree-nested.c tree-object-size.c 
> >>        tree-outof-ssa.c
> >> tree-parloops.c tree-pass.h 
> >>        tree-pretty-print.c
> >> tree-profile.c tree-scalar-evolution.c 
> >>        tree-sra.c
> >> tree-ssa-address.c tree-ssa-alias.c 
> >>        tree-ssa-copyrename.c
> >> tree-ssa-dce.c tree-ssa-dom.c 
> >>        tree-ssa-loop-ivopts.c
> >> tree-ssa-loop-manip.c tree-ssa-loop.c 
> >>        tree-ssa-phiopt.c
> >> tree-ssa-structalias.c tree-ssa-uncprop.c 
> >>        tree-ssa.c
> >> tree-vect-data-refs.c tree-vect-generic.c 
> >>        tree-vect-loop-manip.c
> >> tree-vect-loop.c tree-vect-patterns.c 
> >>        tree-vect-slp.c
> >> tree-vect-stmts.c tree-vrp.c tree.h 
> >>        unwind-c.c
> unwind-compat.c
> >> unwind-compat.h 
> >>        unwind-dw2-fde-compat.c
> >> unwind-dw2-fde-darwin.c 
> >>        unwind-dw2-fde-glibc.c
> >> unwind-dw2-fde.c unwind-dw2-fde.h 
> >>        unwind-dw2.c
> unwind-dw2.h
> >> unwind-generic.h unwind-pe.h 
> >>        unwind-sjlj.c
> value-prof.c
> >> var-tracking.c varpool.c web.c 
> >>    cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
> >> darwin-protos.h darwin.c 
> >> 
> >> 
> >>         darwin.h 
> >>    ./: darwin-protos.h darwin.c darwin.h
> 
> >>   
> cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
> >> crtfastmath.c 
> >> 
> >> 
> >>             
> crtprec.c 
> >> 
> >> 
> >> 
> >> cygming-crtbegin.c 
> >> 
> >> 
> >> 
> >> cygming-crtend.c 
> >> 
> >> 
> >>             
> darwin.h
> >> driver-i386.c 
> >> 
> >> 
> >>             
> gmon-sol2.c
> >> i386.c 
> >> 
> >> 
> >> 
> >> netware-crt0.c 
> >>    ./: crtfastmath.c crtprec.c
> >> cygming-crtbegin.c cygming-crtend.c 
> >>        darwin.h driver-i386.c
> >> gmon-sol2.c i386.c netware-crt0.c 
> >>    cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/:
> lto.c 
> >>    ./: lto.c 
> >>   
> cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
> >> line-map.h 
> >> 
> >> Log message:
> >>    work in progress -- can compile
> >> everything now, but float exception right away
> >> 
> >> 
> 


From jay.krell at cornell.edu  Wed May 30 01:15:48 2012
From: jay.krell at cornell.edu (Jay)
Date: Tue, 29 May 2012 16:15:48 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <1338317066.3447.YahooMailClassic@web29704.mail.ird.yahoo.com>
References: <1338317066.3447.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <1572EB44-615A-4224-948B-DDC3DB23E57C@gmail.com>

Daniel you don't make sense.

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 29, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> good one, there isn't high-end user needs lately here, so I guess we shouldn't ask if we want to support other machines than just PC, perhaps, we should check more platforms at that level.
> Any NT would not be affected but anything else is, HW for testing purposes isn't supported by NT (like debuggers), so there it isn't too much to support for that (lying on MIPS32, and Portable devices sometimes are RISC systems, now what is not aiming NT are desktops but bigger machines) but they are growing down so I don't know if they will become available again.
> Thanks of Modula-3 hackers there is still more systems to check for all if interested in any. 
> Thanks in advance
> 
> --- El lun, 28/5/12, Jay <jay.krell at cornell.edu> escribi?:
> 
>> De: Jay <jay.krell at cornell.edu>
>> Asunto: Re: [M3commit] CVS Update: cm3
>> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
>> CC: "<m3commit at elegosoft.com>" <m3commit at elegosoft.com>, "<m3devel at elegosoft.com>" <m3devel at elegosoft.com>
>> Fecha: lunes, 28 de mayo, 2012 23:30
>> Don't worry about it. I will test
>> each platform or get others to before enabling, at least
>> some popular majority of them. I no longer have any Alphas.
>> Eventually I might ask for ssh access to an Alpha or
>> reacquire hardware. Anyway, don't worry. I generally know
>> what I'm doing.
>> 
>> - Jay (briefly/pocket-sized-computer-aka-phone)
>> 
>> On May 28, 2012, at 7:22 AM, "Daniel Alejandro Benavides D."
>> <dabenavidesd at yahoo.es>
>> wrote:
>> 
>>> Hi Jay:
>>> Where are you testing this, or have you tested this on
>> an Alpha, I might get access, but I notice you dropped the
>> libdecnumber, stuff right?
>>> Thanks in advance
>>> 
>>> --- El lun, 28/5/12, Jay Krell <jkrell at elego.de>
>> escribi?:
>>> 
>>>> De: Jay Krell <jkrell at elego.de>
>>>> Asunto: [M3commit] CVS Update: cm3
>>>> Para: m3commit at elegosoft.com
>>>> Fecha: lunes, 28 de mayo, 2012 05:47
>>>> CVSROOT:    /usr/cvs
>>>> Changes by:   
>>>> jkrell at birch.    12/05/28 10:47:05
>>>> 
>>>> Modified files:
>>>>   cm3/m3-sys/m3cc/gcc-4.6/: configure 
>>>>   ./: configure 
>>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/:
>> Makefile.in
>>>> auto-inc-dec.c 
>>>> 
>>>> 
>>>> basic-block.h builtins.c 
>>>> 
>>>> 
>>>> c-aux-info.c c-convert.c c-decl.c 
>>>> 
>>>> 
>>>> c-errors.c c-lang.c c-lang.h 
>>>> 
>>>> 
>>>> c-objc-common.c c-parser.c 
>>>> 
>>>> 
>>>> c-tree.h c-typeck.c calls.c 
>>>> 
>>>> 
>>>> cfgexpand.c cfgloop.h cgraph.c 
>>>> 
>>>> 
>>>> cgraph.h cgraphbuild.c 
>>>> 
>>>> 
>>>> cgraphunit.c combine.c configure 
>>>> 
>>>> 
>>>> configure.ac cppdefault.c 
>>>> 
>>>> 
>>>> cppdefault.h cppspec.c cse.c 
>>>> 
>>>> 
>>>> expr.c final.c fold-const.c gcc.c 
>>>> 
>>>> 
>>>> gccspec.c gcse.c gengtype-lex.c 
>>>> 
>>>> 
>>>> gengtype-lex.l gengtype.c 
>>>> 
>>>> 
>>>> gimple-fold.c gimple.c gimplify.c 
>>>> 
>>>> 
>>>> incpath.c intl.c ipa-cp.c 
>>>> 
>>>> 
>>>> ipa-inline.c ipa-prop.c ipa-prop.h 
>>>> 
>>>> 
>>>> ipa-ref.h ipa-utils.c ipa.c 
>>>> 
>>>> 
>>>> ira-build.c ira-conflicts.c 
>>>> 
>>>> 
>>>> ira-int.h ira.c ira.h libgcov.c 
>>>> 
>>>> 
>>>> loop-iv.c loop-unswitch.c opts.c 
>>>> 
>>>> 
>>>> passes.c postreload.c predict.c 
>>>> 
>>>> 
>>>> profile.c sched-vis.c 
>>>> 
>>>> 
>>>> sel-sched-dump.c store-motion.c 
>>>> 
>>>> 
>>>> stringpool.c targhooks.c toplev.c 
>>>> 
>>>> 
>>>> tree-cfg.c tree-chrec.c 
>>>> 
>>>> 
>>>> tree-complex.c tree-eh.c 
>>>> 
>>>> 
>>>> tree-flow.h tree-inline.c 
>>>> 
>>>> 
>>>> tree-nested.c tree-object-size.c 
>>>> 
>>>> 
>>>> tree-outof-ssa.c tree-parloops.c 
>>>> 
>>>> 
>>>> tree-pass.h tree-pretty-print.c 
>>>> 
>>>> 
>>>> tree-profile.c 
>>>> 
>>>> 
>>>> tree-scalar-evolution.c tree-sra.c 
>>>> 
>>>> 
>>>> tree-ssa-address.c 
>>>> 
>>>> 
>>>> tree-ssa-alias.c 
>>>> 
>>>> 
>>>> tree-ssa-copyrename.c 
>>>> 
>>>> 
>>>> tree-ssa-dce.c tree-ssa-dom.c 
>>>> 
>>>> 
>>>> tree-ssa-loop-ivopts.c 
>>>> 
>>>> 
>>>> tree-ssa-loop-manip.c 
>>>> 
>>>> 
>>>> tree-ssa-loop.c tree-ssa-phiopt.c 
>>>> 
>>>> 
>>>> tree-ssa-structalias.c 
>>>> 
>>>> 
>>>> tree-ssa-uncprop.c tree-ssa.c 
>>>> 
>>>> 
>>>> tree-vect-data-refs.c 
>>>> 
>>>> 
>>>> tree-vect-generic.c 
>>>> 
>>>> 
>>>> tree-vect-loop-manip.c 
>>>> 
>>>> 
>>>> tree-vect-loop.c 
>>>> 
>>>> 
>>>> tree-vect-patterns.c 
>>>> 
>>>> 
>>>> tree-vect-slp.c tree-vect-stmts.c 
>>>> 
>>>> 
>>>> tree-vrp.c tree.h unwind-c.c 
>>>> 
>>>> 
>>>> unwind-compat.c unwind-compat.h 
>>>> 
>>>> 
>>>> unwind-dw2-fde-compat.c 
>>>> 
>>>> 
>>>> unwind-dw2-fde-darwin.c 
>>>> 
>>>> 
>>>> unwind-dw2-fde-glibc.c 
>>>> 
>>>> 
>>>> unwind-dw2-fde.c unwind-dw2-fde.h 
>>>> 
>>>> 
>>>> unwind-dw2.c unwind-dw2.h 
>>>> 
>>>> 
>>>> unwind-generic.h unwind-pe.h 
>>>> 
>>>> 
>>>> unwind-sjlj.c value-prof.c 
>>>> 
>>>> 
>>>> var-tracking.c varpool.c web.c 
>>>>   ./: Makefile.in auto-inc-dec.c
>>>> basic-block.h builtins.c 
>>>>       c-aux-info.c
>> c-convert.c
>>>> c-decl.c c-errors.c c-lang.c 
>>>>       c-lang.h
>> c-objc-common.c
>>>> c-parser.c c-tree.h c-typeck.c 
>>>>       calls.c cfgexpand.c
>>>> cfgloop.h cgraph.c cgraph.h 
>>>>       cgraphbuild.c
>> cgraphunit.c
>>>> combine.c configure configure.ac 
>>>>       cppdefault.c
>> cppdefault.h
>>>> cppspec.c cse.c expr.c final.c 
>>>>       fold-const.c gcc.c
>>>> gccspec.c gcse.c gengtype-lex.c 
>>>>       gengtype-lex.l
>> gengtype.c
>>>> gimple-fold.c gimple.c gimplify.c 
>>>>       incpath.c intl.c
>> ipa-cp.c
>>>> ipa-inline.c ipa-prop.c ipa-prop.h 
>>>>       ipa-ref.h ipa-utils.c
>> ipa.c
>>>> ira-build.c ira-conflicts.c 
>>>>       ira-int.h ira.c ira.h
>>>> libgcov.c loop-iv.c loop-unswitch.c 
>>>>       opts.c passes.c
>>>> postreload.c predict.c profile.c sched-vis.c 
>>>>       sel-sched-dump.c
>>>> store-motion.c stringpool.c targhooks.c 
>>>>       toplev.c tree-cfg.c
>>>> tree-chrec.c tree-complex.c tree-eh.c 
>>>>       tree-flow.h
>> tree-inline.c
>>>> tree-nested.c tree-object-size.c 
>>>>       tree-outof-ssa.c
>>>> tree-parloops.c tree-pass.h 
>>>>       tree-pretty-print.c
>>>> tree-profile.c tree-scalar-evolution.c 
>>>>       tree-sra.c
>>>> tree-ssa-address.c tree-ssa-alias.c 
>>>>       tree-ssa-copyrename.c
>>>> tree-ssa-dce.c tree-ssa-dom.c 
>>>>       tree-ssa-loop-ivopts.c
>>>> tree-ssa-loop-manip.c tree-ssa-loop.c 
>>>>       tree-ssa-phiopt.c
>>>> tree-ssa-structalias.c tree-ssa-uncprop.c 
>>>>       tree-ssa.c
>>>> tree-vect-data-refs.c tree-vect-generic.c 
>>>>       tree-vect-loop-manip.c
>>>> tree-vect-loop.c tree-vect-patterns.c 
>>>>       tree-vect-slp.c
>>>> tree-vect-stmts.c tree-vrp.c tree.h 
>>>>       unwind-c.c
>> unwind-compat.c
>>>> unwind-compat.h 
>>>>       unwind-dw2-fde-compat.c
>>>> unwind-dw2-fde-darwin.c 
>>>>       unwind-dw2-fde-glibc.c
>>>> unwind-dw2-fde.c unwind-dw2-fde.h 
>>>>       unwind-dw2.c
>> unwind-dw2.h
>>>> unwind-generic.h unwind-pe.h 
>>>>       unwind-sjlj.c
>> value-prof.c
>>>> var-tracking.c varpool.c web.c 
>>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
>>>> darwin-protos.h darwin.c 
>>>> 
>>>> 
>>>>        darwin.h 
>>>>   ./: darwin-protos.h darwin.c darwin.h
>> 
>>>> 
>> cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
>>>> crtfastmath.c 
>>>> 
>>>> 
>>>> 
>> crtprec.c 
>>>> 
>>>> 
>>>> 
>>>> cygming-crtbegin.c 
>>>> 
>>>> 
>>>> 
>>>> cygming-crtend.c 
>>>> 
>>>> 
>>>> 
>> darwin.h
>>>> driver-i386.c 
>>>> 
>>>> 
>>>> 
>> gmon-sol2.c
>>>> i386.c 
>>>> 
>>>> 
>>>> 
>>>> netware-crt0.c 
>>>>   ./: crtfastmath.c crtprec.c
>>>> cygming-crtbegin.c cygming-crtend.c 
>>>>       darwin.h driver-i386.c
>>>> gmon-sol2.c i386.c netware-crt0.c 
>>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/:
>> lto.c 
>>>>   ./: lto.c 
>>>> 
>> cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
>>>> line-map.h 
>>>> 
>>>> Log message:
>>>>   work in progress -- can compile
>>>> everything now, but float exception right away
>>>> 
>>>> 
>> 


From dabenavidesd at yahoo.es  Wed May 30 02:03:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 01:03:34 +0100 (BST)
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <1572EB44-615A-4224-948B-DDC3DB23E57C@gmail.com>
Message-ID: <1338336214.27113.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
in reality PC AT aren't 64 bits wide, I guess in reality you can add a memory board to a i386 and that's it. Is just that same thing.
Bigger registers aren't a difference (the double number of registers and that's it for a register-based machine, like another ix86, the 82786 GPU for coprocessor and that's all), this is the same concept for a GPGPU nowadays, and they don't care at all to maintain compatibility to it so nobody has created a real 64-bit system after Tru64 and some other Unixes are, like Monterey project.
I mean there aren't real 64 bit systems, so I guess there isn't anything to test here in Gcc targets for real for PCs, they are the same that long before.
We don't have any new real HW or SW adapted for real so I don't know what else can be test.
Thanks in advance


--- El mar, 29/5/12, Jay <jay.krell at cornell.edu> escribi?:

> De: Jay <jay.krell at cornell.edu>
> Asunto: Re: [M3commit] CVS Update: cm3
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "Jay" <jay.krell at cornell.edu>, "<m3commit at elegosoft.com>" <m3commit at elegosoft.com>, "<m3devel at elegosoft.com>" <m3devel at elegosoft.com>
> Fecha: martes, 29 de mayo, 2012 18:15
> Daniel you don't make sense.
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On May 29, 2012, at 11:44 AM, "Daniel Alejandro Benavides
> D." <dabenavidesd at yahoo.es>
> wrote:
> 
> > Hi all:
> > good one, there isn't high-end user needs lately here,
> so I guess we shouldn't ask if we want to support other
> machines than just PC, perhaps, we should check more
> platforms at that level.
> > Any NT would not be affected but anything else is, HW
> for testing purposes isn't supported by NT (like debuggers),
> so there it isn't too much to support for that (lying on
> MIPS32, and Portable devices sometimes are RISC systems, now
> what is not aiming NT are desktops but bigger machines) but
> they are growing down so I don't know if they will become
> available again.
> > Thanks of Modula-3 hackers there is still more systems
> to check for all if interested in any. 
> > Thanks in advance
> > 
> > --- El lun, 28/5/12, Jay <jay.krell at cornell.edu>
> escribi?:
> > 
> >> De: Jay <jay.krell at cornell.edu>
> >> Asunto: Re: [M3commit] CVS Update: cm3
> >> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> >> CC: "<m3commit at elegosoft.com>"
> <m3commit at elegosoft.com>,
> "<m3devel at elegosoft.com>"
> <m3devel at elegosoft.com>
> >> Fecha: lunes, 28 de mayo, 2012 23:30
> >> Don't worry about it. I will test
> >> each platform or get others to before enabling, at
> least
> >> some popular majority of them. I no longer have any
> Alphas.
> >> Eventually I might ask for ssh access to an Alpha
> or
> >> reacquire hardware. Anyway, don't worry. I
> generally know
> >> what I'm doing.
> >> 
> >> - Jay (briefly/pocket-sized-computer-aka-phone)
> >> 
> >> On May 28, 2012, at 7:22 AM, "Daniel Alejandro
> Benavides D."
> >> <dabenavidesd at yahoo.es>
> >> wrote:
> >> 
> >>> Hi Jay:
> >>> Where are you testing this, or have you tested
> this on
> >> an Alpha, I might get access, but I notice you
> dropped the
> >> libdecnumber, stuff right?
> >>> Thanks in advance
> >>> 
> >>> --- El lun, 28/5/12, Jay Krell <jkrell at elego.de>
> >> escribi?:
> >>> 
> >>>> De: Jay Krell <jkrell at elego.de>
> >>>> Asunto: [M3commit] CVS Update: cm3
> >>>> Para: m3commit at elegosoft.com
> >>>> Fecha: lunes, 28 de mayo, 2012 05:47
> >>>> CVSROOT:    /usr/cvs
> >>>> Changes by:   
> >>>> jkrell at birch.    12/05/28
> 10:47:05
> >>>> 
> >>>> Modified files:
> >>>>   cm3/m3-sys/m3cc/gcc-4.6/:
> configure 
> >>>>   ./: configure 
> >>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/:
> >> Makefile.in
> >>>> auto-inc-dec.c 
> >>>> 
> >>>> 
> >>>> basic-block.h builtins.c 
> >>>> 
> >>>> 
> >>>> c-aux-info.c c-convert.c c-decl.c 
> >>>> 
> >>>> 
> >>>> c-errors.c c-lang.c c-lang.h 
> >>>> 
> >>>> 
> >>>> c-objc-common.c c-parser.c 
> >>>> 
> >>>> 
> >>>> c-tree.h c-typeck.c calls.c 
> >>>> 
> >>>> 
> >>>> cfgexpand.c cfgloop.h cgraph.c 
> >>>> 
> >>>> 
> >>>> cgraph.h cgraphbuild.c 
> >>>> 
> >>>> 
> >>>> cgraphunit.c combine.c configure 
> >>>> 
> >>>> 
> >>>> configure.ac cppdefault.c 
> >>>> 
> >>>> 
> >>>> cppdefault.h cppspec.c cse.c 
> >>>> 
> >>>> 
> >>>> expr.c final.c fold-const.c gcc.c 
> >>>> 
> >>>> 
> >>>> gccspec.c gcse.c gengtype-lex.c 
> >>>> 
> >>>> 
> >>>> gengtype-lex.l gengtype.c 
> >>>> 
> >>>> 
> >>>> gimple-fold.c gimple.c gimplify.c 
> >>>> 
> >>>> 
> >>>> incpath.c intl.c ipa-cp.c 
> >>>> 
> >>>> 
> >>>> ipa-inline.c ipa-prop.c ipa-prop.h 
> >>>> 
> >>>> 
> >>>> ipa-ref.h ipa-utils.c ipa.c 
> >>>> 
> >>>> 
> >>>> ira-build.c ira-conflicts.c 
> >>>> 
> >>>> 
> >>>> ira-int.h ira.c ira.h libgcov.c 
> >>>> 
> >>>> 
> >>>> loop-iv.c loop-unswitch.c opts.c 
> >>>> 
> >>>> 
> >>>> passes.c postreload.c predict.c 
> >>>> 
> >>>> 
> >>>> profile.c sched-vis.c 
> >>>> 
> >>>> 
> >>>> sel-sched-dump.c store-motion.c 
> >>>> 
> >>>> 
> >>>> stringpool.c targhooks.c toplev.c 
> >>>> 
> >>>> 
> >>>> tree-cfg.c tree-chrec.c 
> >>>> 
> >>>> 
> >>>> tree-complex.c tree-eh.c 
> >>>> 
> >>>> 
> >>>> tree-flow.h tree-inline.c 
> >>>> 
> >>>> 
> >>>> tree-nested.c tree-object-size.c 
> >>>> 
> >>>> 
> >>>> tree-outof-ssa.c tree-parloops.c 
> >>>> 
> >>>> 
> >>>> tree-pass.h tree-pretty-print.c 
> >>>> 
> >>>> 
> >>>> tree-profile.c 
> >>>> 
> >>>> 
> >>>> tree-scalar-evolution.c tree-sra.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-address.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-alias.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-copyrename.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-dce.c tree-ssa-dom.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-loop-ivopts.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-loop-manip.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-loop.c tree-ssa-phiopt.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-structalias.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-uncprop.c tree-ssa.c 
> >>>> 
> >>>> 
> >>>> tree-vect-data-refs.c 
> >>>> 
> >>>> 
> >>>> tree-vect-generic.c 
> >>>> 
> >>>> 
> >>>> tree-vect-loop-manip.c 
> >>>> 
> >>>> 
> >>>> tree-vect-loop.c 
> >>>> 
> >>>> 
> >>>> tree-vect-patterns.c 
> >>>> 
> >>>> 
> >>>> tree-vect-slp.c tree-vect-stmts.c 
> >>>> 
> >>>> 
> >>>> tree-vrp.c tree.h unwind-c.c 
> >>>> 
> >>>> 
> >>>> unwind-compat.c unwind-compat.h 
> >>>> 
> >>>> 
> >>>> unwind-dw2-fde-compat.c 
> >>>> 
> >>>> 
> >>>> unwind-dw2-fde-darwin.c 
> >>>> 
> >>>> 
> >>>> unwind-dw2-fde-glibc.c 
> >>>> 
> >>>> 
> >>>> unwind-dw2-fde.c unwind-dw2-fde.h 
> >>>> 
> >>>> 
> >>>> unwind-dw2.c unwind-dw2.h 
> >>>> 
> >>>> 
> >>>> unwind-generic.h unwind-pe.h 
> >>>> 
> >>>> 
> >>>> unwind-sjlj.c value-prof.c 
> >>>> 
> >>>> 
> >>>> var-tracking.c varpool.c web.c 
> >>>>   ./: Makefile.in
> auto-inc-dec.c
> >>>> basic-block.h builtins.c 
> >>>>   
>    c-aux-info.c
> >> c-convert.c
> >>>> c-decl.c c-errors.c c-lang.c 
> >>>>       c-lang.h
> >> c-objc-common.c
> >>>> c-parser.c c-tree.h c-typeck.c 
> >>>>       calls.c
> cfgexpand.c
> >>>> cfgloop.h cgraph.c cgraph.h 
> >>>>   
>    cgraphbuild.c
> >> cgraphunit.c
> >>>> combine.c configure configure.ac 
> >>>>   
>    cppdefault.c
> >> cppdefault.h
> >>>> cppspec.c cse.c expr.c final.c 
> >>>>       fold-const.c
> gcc.c
> >>>> gccspec.c gcse.c gengtype-lex.c 
> >>>>   
>    gengtype-lex.l
> >> gengtype.c
> >>>> gimple-fold.c gimple.c gimplify.c 
> >>>>       incpath.c
> intl.c
> >> ipa-cp.c
> >>>> ipa-inline.c ipa-prop.c ipa-prop.h 
> >>>>       ipa-ref.h
> ipa-utils.c
> >> ipa.c
> >>>> ira-build.c ira-conflicts.c 
> >>>>       ira-int.h
> ira.c ira.h
> >>>> libgcov.c loop-iv.c loop-unswitch.c 
> >>>>       opts.c
> passes.c
> >>>> postreload.c predict.c profile.c
> sched-vis.c 
> >>>>   
>    sel-sched-dump.c
> >>>> store-motion.c stringpool.c targhooks.c 
> >>>>       toplev.c
> tree-cfg.c
> >>>> tree-chrec.c tree-complex.c tree-eh.c 
> >>>>       tree-flow.h
> >> tree-inline.c
> >>>> tree-nested.c tree-object-size.c 
> >>>>   
>    tree-outof-ssa.c
> >>>> tree-parloops.c tree-pass.h 
> >>>>   
>    tree-pretty-print.c
> >>>> tree-profile.c tree-scalar-evolution.c 
> >>>>       tree-sra.c
> >>>> tree-ssa-address.c tree-ssa-alias.c 
> >>>>   
>    tree-ssa-copyrename.c
> >>>> tree-ssa-dce.c tree-ssa-dom.c 
> >>>>   
>    tree-ssa-loop-ivopts.c
> >>>> tree-ssa-loop-manip.c tree-ssa-loop.c 
> >>>>   
>    tree-ssa-phiopt.c
> >>>> tree-ssa-structalias.c tree-ssa-uncprop.c 
> >>>>       tree-ssa.c
> >>>> tree-vect-data-refs.c tree-vect-generic.c 
> >>>>   
>    tree-vect-loop-manip.c
> >>>> tree-vect-loop.c tree-vect-patterns.c 
> >>>>   
>    tree-vect-slp.c
> >>>> tree-vect-stmts.c tree-vrp.c tree.h 
> >>>>       unwind-c.c
> >> unwind-compat.c
> >>>> unwind-compat.h 
> >>>>   
>    unwind-dw2-fde-compat.c
> >>>> unwind-dw2-fde-darwin.c 
> >>>>   
>    unwind-dw2-fde-glibc.c
> >>>> unwind-dw2-fde.c unwind-dw2-fde.h 
> >>>>   
>    unwind-dw2.c
> >> unwind-dw2.h
> >>>> unwind-generic.h unwind-pe.h 
> >>>>   
>    unwind-sjlj.c
> >> value-prof.c
> >>>> var-tracking.c varpool.c web.c 
> >>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
> >>>> darwin-protos.h darwin.c 
> >>>> 
> >>>> 
> >>>>        darwin.h 
> >>>>   ./: darwin-protos.h
> darwin.c darwin.h
> >> 
> >>>> 
> >> cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
> >>>> crtfastmath.c 
> >>>> 
> >>>> 
> >>>> 
> >> crtprec.c 
> >>>> 
> >>>> 
> >>>> 
> >>>> cygming-crtbegin.c 
> >>>> 
> >>>> 
> >>>> 
> >>>> cygming-crtend.c 
> >>>> 
> >>>> 
> >>>> 
> >> darwin.h
> >>>> driver-i386.c 
> >>>> 
> >>>> 
> >>>> 
> >> gmon-sol2.c
> >>>> i386.c 
> >>>> 
> >>>> 
> >>>> 
> >>>> netware-crt0.c 
> >>>>   ./: crtfastmath.c
> crtprec.c
> >>>> cygming-crtbegin.c cygming-crtend.c 
> >>>>       darwin.h
> driver-i386.c
> >>>> gmon-sol2.c i386.c netware-crt0.c 
> >>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/:
> >> lto.c 
> >>>>   ./: lto.c 
> >>>> 
> >> cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
> >>>> line-map.h 
> >>>> 
> >>>> Log message:
> >>>>   work in progress -- can
> compile
> >>>> everything now, but float exception right
> away
> >>>> 
> >>>> 
> >> 
> 


From dragisha at m3w.org  Wed May 30 10:54:08 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 30 May 2012 10:54:08 +0200
Subject: [M3devel] portable hosting
In-Reply-To: <1338240156.6219.YahooMailClassic@web29704.mail.ird.yahoo.com>
References: <1338240156.6219.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>

Daniel,

I like your project. Please inform us on updates, when available!

Thanks in advance,
dd

p.s. :)

On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> or better make an assembly-coded C compiler in a Java language processor, and cross-boot assemble from a Modula-3 environment there so you could bootstrap a M3CG-system there.
> Thanks in advance
> 
> --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:
> 
>> De: Hendrik Boom <hendrik at topoi.pooq.com>
>> Asunto: [M3devel] portable hosting
>> Para: m3devel at elegosoft.com
>> Fecha: lunes, 28 de mayo, 2012 11:50
>> On Sun, May 20, 2012 at 02:32:14PM
>> -0700, Jay wrote:
>>> 
>>> Btw, rewriting all of m3front in C or C++ or Java
>> probably wouldn't be very difficult.
>> 
>> Would it be more or less difficult than writing a code
>> generator that 
>> generated C or C++ code?  THe code generator could do
>> the rewrite for 
>> you.  Bt it wouldn't be very readable code.
>> 



From dabenavidesd at yahoo.es  Wed May 30 13:34:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 12:34:24 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
Message-ID: <1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I like the option but because there isn't more than that in a featured phone, which is the most common kind of thing in this world; S40, has its own JVM, if this about popularity.
Crazy and simple as it is.

Thanks in advance

--- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] portable hosting
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> Daniel,
> 
> I like your project. Please inform us on updates, when
> available!
> 
> Thanks in advance,
> dd
> 
> p.s. :)
> 
> On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> wrote:
> 
> > Hi all:
> > or better make an assembly-coded C compiler in a Java
> language processor, and cross-boot assemble from a Modula-3
> environment there so you could bootstrap a M3CG-system
> there.
> > Thanks in advance
> > 
> > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> escribi?:
> > 
> >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> >> Asunto: [M3devel] portable hosting
> >> Para: m3devel at elegosoft.com
> >> Fecha: lunes, 28 de mayo, 2012 11:50
> >> On Sun, May 20, 2012 at 02:32:14PM
> >> -0700, Jay wrote:
> >>> 
> >>> Btw, rewriting all of m3front in C or C++ or
> Java
> >> probably wouldn't be very difficult.
> >> 
> >> Would it be more or less difficult than writing a
> code
> >> generator that 
> >> generated C or C++ code?  THe code generator
> could do
> >> the rewrite for 
> >> you.  Bt it wouldn't be very readable code.
> >> 
> 
> 


From dragisha at m3w.org  Wed May 30 14:03:39 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 30 May 2012 14:03:39 +0200
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <COL101-W1C8E7FBA8B4CC5793DC42E6010@phx.gbl>
References: <555EDB08-5E0A-472A-9D93-FD890F924303@m3w.org>,
	<1337979476.29484.YahooMailClassic@web29703.mail.ird.yahoo.com>
	<COL101-W1C8E7FBA8B4CC5793DC42E6010@phx.gbl>
Message-ID: <0F4CD174-3D70-4A2C-8F11-461E1C4A1C5E@m3w.org>

Of course.


On May 26, 2012, at 12:09 AM, Jay K wrote:

> -DNOPTHREAD only directly changes m3core.
> The rest of the system can be compiled w/ or w/o it. But the new m3core causes a need for some rebuild.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120530/02a4f856/attachment.html>

From hendrik at topoi.pooq.com  Wed May 30 14:20:57 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 30 May 2012 08:20:57 -0400
Subject: [M3devel] portable hosting
In-Reply-To: <1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
	<1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <20120530122057.GA28287@topoi.pooq.com>

I've only heard of two different Java virtual machines -- the one Sun 
wrote, which I believe has been independently implementedonce or twice, 
and the one Google wrote as part of Android, which is designed for 
efficient JIT compilation.

Is this one of these, or is there yet another?

-- hendrik

On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all:
> I like the option but because there isn't more than that in a featured 
> phone, which is the most common kind of thing in this world; S40, has 
> its own JVM, if this about popularity.
> Crazy and simple as it is.
> 
> Thanks in advance
> 
> --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> > De: Dragi?a Duri? <dragisha at m3w.org>
> > Asunto: Re: [M3devel] portable hosting
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > Daniel,
> > 
> > I like your project. Please inform us on updates, when
> > available!
> > 
> > Thanks in advance,
> > dd
> > 
> > p.s. :)
> > 
> > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > wrote:
> > 
> > > Hi all:
> > > or better make an assembly-coded C compiler in a Java
> > language processor, and cross-boot assemble from a Modula-3
> > environment there so you could bootstrap a M3CG-system
> > there.
> > > Thanks in advance
> > > 
> > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > escribi?:
> > > 
> > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > >> Asunto: [M3devel] portable hosting
> > >> Para: m3devel at elegosoft.com
> > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > >> On Sun, May 20, 2012 at 02:32:14PM
> > >> -0700, Jay wrote:
> > >>> 
> > >>> Btw, rewriting all of m3front in C or C++ or
> > Java
> > >> probably wouldn't be very difficult.
> > >> 
> > >> Would it be more or less difficult than writing a
> > code
> > >> generator that 
> > >> generated C or C++ code?  THe code generator
> > could do
> > >> the rewrite for 
> > >> you.  Bt it wouldn't be very readable code.
> > >> 
> > 
> >


From dabenavidesd at yahoo.es  Wed May 30 14:53:41 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 13:53:41 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <20120530122057.GA28287@topoi.pooq.com>
Message-ID: <1338382421.96630.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
It theirs original EPL, but wasn't further developed because for S60 as a JVM able phone, contrary to CM J-V-M) isn't able to be used as a library, So I thought this was great news for us. 
I have the package for S60.
Thanks in advance


--- El mi?, 30/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] portable hosting
> Para: m3devel at elegosoft.com
> Fecha: mi?rcoles, 30 de mayo, 2012 07:20
> I've only heard of two different Java
> virtual machines -- the one Sun 
> wrote, which I believe has been independently
> implementedonce or twice, 
> and the one Google wrote as part of Android, which is
> designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro
> Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than
> that in a featured 
> > phone, which is the most common kind of thing in this
> world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com,
> "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates,
> when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro
> Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler
> in a Java
> > > language processor, and cross-boot assemble from a
> Modula-3
> > > environment there so you could bootstrap a
> M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or
> C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than
> writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?  THe code
> generator
> > > could do
> > > >> the rewrite for 
> > > >> you.  Bt it wouldn't be very
> readable code.
> > > >> 
> > > 
> > >
> 


From dabenavidesd at yahoo.es  Wed May 30 15:10:42 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 14:10:42 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <1338382421.96630.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <1338383442.54852.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
in fact there is one else more, A 16-bit IBM java tool set:
http://books.google.com.co/books?id=vj4EAAAAMBAJ&lpg=PA12&dq=java%20s40&pg=PA12#v=onepage&q&f=false

Thanks in advance

--- El mi?, 30/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] portable hosting
> Para: "Hendrik Boom" <hendrik at topoi.pooq.com>
> CC: m3devel at elegosoft.com
> Fecha: mi?rcoles, 30 de mayo, 2012 07:53
> Hi all:
> It theirs original EPL, but wasn't further developed because
> for S60 as a JVM able phone, contrary to CM J-V-M) isn't
> able to be used as a library, So I thought this was great
> news for us. 
> I have the package for S60.
> Thanks in advance
> 
> 
> --- El mi?, 30/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> escribi?:
> 
> > De: Hendrik Boom <hendrik at topoi.pooq.com>
> > Asunto: Re: [M3devel] portable hosting
> > Para: m3devel at elegosoft.com
> > Fecha: mi?rcoles, 30 de mayo, 2012 07:20
> > I've only heard of two different Java
> > virtual machines -- the one Sun 
> > wrote, which I believe has been independently
> > implementedonce or twice, 
> > and the one Google wrote as part of Android, which is
> > designed for 
> > efficient JIT compilation.
> > 
> > Is this one of these, or is there yet another?
> > 
> > -- hendrik
> > 
> > On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel
> Alejandro
> > Benavides D. wrote:
> > > Hi all:
> > > I like the option but because there isn't more
> than
> > that in a featured 
> > > phone, which is the most common kind of thing in
> this
> > world; S40, has 
> > > its own JVM, if this about popularity.
> > > Crazy and simple as it is.
> > > 
> > > Thanks in advance
> > > 
> > > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org>
> > escribi?:
> > > 
> > > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > > Asunto: Re: [M3devel] portable hosting
> > > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > > CC: m3devel at elegosoft.com,
> > "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > > Daniel,
> > > > 
> > > > I like your project. Please inform us on
> updates,
> > when
> > > > available!
> > > > 
> > > > Thanks in advance,
> > > > dd
> > > > 
> > > > p.s. :)
> > > > 
> > > > On May 28, 2012, at 11:22 PM, Daniel
> Alejandro
> > Benavides D.
> > > > wrote:
> > > > 
> > > > > Hi all:
> > > > > or better make an assembly-coded C
> compiler
> > in a Java
> > > > language processor, and cross-boot assemble
> from a
> > Modula-3
> > > > environment there so you could bootstrap a
> > M3CG-system
> > > > there.
> > > > > Thanks in advance
> > > > > 
> > > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > > escribi?:
> > > > > 
> > > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > > >> Asunto: [M3devel] portable hosting
> > > > >> Para: m3devel at elegosoft.com
> > > > >> Fecha: lunes, 28 de mayo, 2012
> 11:50
> > > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > > >> -0700, Jay wrote:
> > > > >>> 
> > > > >>> Btw, rewriting all of m3front in
> C or
> > C++ or
> > > > Java
> > > > >> probably wouldn't be very
> difficult.
> > > > >> 
> > > > >> Would it be more or less difficult
> than
> > writing a
> > > > code
> > > > >> generator that 
> > > > >> generated C or C++ code?  THe
> code
> > generator
> > > > could do
> > > > >> the rewrite for 
> > > > >> you.  Bt it wouldn't be very
> > readable code.
> > > > >> 
> > > > 
> > > >
> >
> 


From microcode at zoho.com  Wed May 30 15:26:04 2012
From: microcode at zoho.com (microcode at zoho.com)
Date: Wed, 30 May 2012 13:26:04 +0000
Subject: [M3devel] portable hosting
In-Reply-To: <20120530122057.GA28287@topoi.pooq.com>
References: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
	<1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120530122057.GA28287@topoi.pooq.com>
Message-ID: <1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>

There are tons of Java JVMs. IBM wrote at least two. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 08:20:57 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

I've only heard of two different Java virtual machines -- the one Sun 
wrote, which I believe has been independently implementedonce or twice, 
and the one Google wrote as part of Android, which is designed for 
efficient JIT compilation.

Is this one of these, or is there yet another?

-- hendrik

On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all:
> I like the option but because there isn't more than that in a featured 
> phone, which is the most common kind of thing in this world; S40, has 
> its own JVM, if this about popularity.
> Crazy and simple as it is.
> 
> Thanks in advance
> 
> --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> > De: Dragi?a Duri? <dragisha at m3w.org>
> > Asunto: Re: [M3devel] portable hosting
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > Daniel,
> > 
> > I like your project. Please inform us on updates, when
> > available!
> > 
> > Thanks in advance,
> > dd
> > 
> > p.s. :)
> > 
> > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > wrote:
> > 
> > > Hi all:
> > > or better make an assembly-coded C compiler in a Java
> > language processor, and cross-boot assemble from a Modula-3
> > environment there so you could bootstrap a M3CG-system
> > there.
> > > Thanks in advance
> > > 
> > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > escribi?:
> > > 
> > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > >> Asunto: [M3devel] portable hosting
> > >> Para: m3devel at elegosoft.com
> > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > >> On Sun, May 20, 2012 at 02:32:14PM
> > >> -0700, Jay wrote:
> > >>> 
> > >>> Btw, rewriting all of m3front in C or C++ or
> > Java
> > >> probably wouldn't be very difficult.
> > >> 
> > >> Would it be more or less difficult than writing a
> > code
> > >> generator that 
> > >> generated C or C++ code?  THe code generator
> > could do
> > >> the rewrite for 
> > >> you.  Bt it wouldn't be very readable code.
> > >> 
> > 
> >

From hendrik at topoi.pooq.com  Wed May 30 15:51:14 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 30 May 2012 09:51:14 -0400
Subject: [M3devel] portable hosting
In-Reply-To: <1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>
References: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
	<1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120530122057.GA28287@topoi.pooq.com>
	<1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>
Message-ID: <20120530135114.GB28287@topoi.pooq.com>

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?  Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?  THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.  Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >


From dabenavidesd at yahoo.es  Wed May 30 16:08:32 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 15:08:32 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>
Message-ID: <1338386912.57598.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
But original for reference for a platform, I think as Modula-3 was VAX mostly, and Olivetti Modula-3 was ARM mostly.
Thanks in advance

--- El mi?, 30/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

> De: microcode at zoho.com <microcode at zoho.com>
> Asunto: Re: [M3devel] portable hosting
> Para: m3devel at elegosoft.com
> Fecha: mi?rcoles, 30 de mayo, 2012 08:26
> There are tons of Java JVMs. IBM
> wrote at least two. 
> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines --
> the one Sun 
> wrote, which I believe has been independently
> implementedonce or twice, 
> and the one Google wrote as part of Android, which is
> designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro
> Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than
> that in a featured 
> > phone, which is the most common kind of thing in this
> world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com,
> "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates,
> when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro
> Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler
> in a Java
> > > language processor, and cross-boot assemble from a
> Modula-3
> > > environment there so you could bootstrap a
> M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or
> C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than
> writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?  THe code
> generator
> > > could do
> > > >> the rewrite for 
> > > >> you.  Bt it wouldn't be very
> readable code.
> > > >> 
> > > 
> > >
> 


From microcode at zoho.com  Wed May 30 16:11:39 2012
From: microcode at zoho.com (microcode at zoho.com)
Date: Wed, 30 May 2012 14:11:39 +0000
Subject: [M3devel] portable hosting
In-Reply-To: <20120530135114.GB28287@topoi.pooq.com>
References: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
	<1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120530122057.GA28287@topoi.pooq.com>
	<1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>
	<20120530135114.GB28287@topoi.pooq.com>
Message-ID: <754448862-1338387100-cardhu_decombobulator_blackberry.rim.net-349729625-@b1.c1.bise3.blackberry>

I'm sorry, I don't understand what you are asking. 

As much as I loathe WikiPedia

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

Is a good starting point. I am pretty sure there are dozens more not listed there though. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 09:51:14 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?  Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?  THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.  Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >

From dabenavidesd at yahoo.es  Wed May 30 17:13:13 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 16:13:13 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <754448862-1338387100-cardhu_decombobulator_blackberry.rim.net-349729625-@b1.c1.bise3.blackberry>
Message-ID: <1338390793.36979.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
I think the issue is back to the stream media, since a JVM ready product was only to be Sun JVM ready, so, any other implementation was both a product officially unrelated and JVM ready. I don't know how SUN thought about JIT-compilers, etc.
Thanks in advance


--- El mi?, 30/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

De: microcode at zoho.com <microcode at zoho.com>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com
Fecha: mi?rcoles, 30 de mayo, 2012 09:11

I'm sorry, I don't understand what you are asking. 

As much as I loathe WikiPedia

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


Is a good starting point. I am pretty sure there are dozens more not listed there though. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 09:51:14 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?? Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?? THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.? Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120530/d325b80d/attachment.html>

From dabenavidesd at yahoo.es  Wed May 30 18:30:47 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 17:30:47 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <1338390793.36979.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <1338395447.59773.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
this is to say, JVM non-SUN are not JVM products compatible, CM J-V-M but I don't know how it was related to it.
Something akin PC AT, the latter are not clones, so you know. Now, if Compaq did the same thing with their Compaq Fast VM, as it did with Compaq deskpro, that would be managing the JVM to produce another IR, that was the idea if the memory issues were corrected, as JVm leaked for years, I think Dragisha sent that article about it, didn't he?
Thanks in advance

--- El mi?, 30/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com, microcode at zoho.com
Fecha: mi?rcoles, 30 de mayo, 2012 10:13

Hi all:
I think the issue is back to the stream media, since a JVM ready product was only to be Sun JVM ready, so, any other implementation was both a product officially unrelated and JVM ready. I don't know how SUN thought about JIT-compilers, etc.
Thanks in advance


--- El mi?, 30/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

De: microcode at zoho.com <microcode at zoho.com>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com
Fecha: mi?rcoles, 30 de mayo, 2012 09:11

I'm sorry, I don't understand what you are asking. 

As much as I loathe WikiPedia

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


Is a good starting point. I am pretty sure there are dozens more not listed there though. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 09:51:14 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?? Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of
 thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >>
 Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?? THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.? Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120530/30a30073/attachment.html>

From dabenavidesd at yahoo.es  Wed May 30 21:33:13 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 20:33:13 +0100 (BST)
Subject: [M3devel] X86/97 targets? [was: Re:  portable hosting]
In-Reply-To: <1338395447.59773.YahooMailClassic@web29705.mail.ird.yahoo.com>
Message-ID: <1338406393.56947.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
Someone has checked what is a x97?
Was x97 another take by i86 something akin, they created a 300 million fund for anyone experimenting on it? (Old strategy for companies Elego folks something to say ...) Do we want this:
http://confidential.eetimes.com/news-updates/4373963/Ultrabooks-duel-ultralights-at-Computex

P.S: If you need this article to see complete text please create a free account, else I can send it upon request. 

Thanks in advance

--- El mi?, 30/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com, microcode at zoho.com
Fecha: mi?rcoles, 30 de mayo, 2012 11:30

Hi all:
this is to say, JVM non-SUN are not JVM products compatible, CM J-V-M but I don't know how it was related to it.
Something akin PC AT, the latter are not clones, so you know. Now, if Compaq did the same thing with their Compaq Fast VM, as it did with Compaq deskpro, that would be managing the JVM to produce another IR, that was the idea if the memory issues were corrected, as JVm leaked for years, I think Dragisha sent that article about it, didn't he?
Thanks in advance

--- El mi?, 30/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com,
 microcode at zoho.com
Fecha: mi?rcoles, 30 de mayo, 2012 10:13

Hi all:
I think the issue is back to the stream media, since a JVM ready product was only to be Sun JVM ready, so, any other implementation was both a product officially unrelated and JVM ready. I don't know how SUN thought about JIT-compilers, etc.
Thanks in advance


--- El mi?, 30/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

De: microcode at zoho.com <microcode at zoho.com>
Asunto: Re: [M3devel] portable hosting
Para:
 m3devel at elegosoft.com
Fecha: mi?rcoles, 30 de mayo, 2012 09:11

I'm sorry, I don't understand what you are asking. 

As much as I loathe WikiPedia

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


Is a good starting point. I am pretty sure there are dozens more not listed there though. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 09:51:14 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?? Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of
 two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of
 thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> >
 > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > >
 >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >>
 Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?? THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.? Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120530/023e42ea/attachment.html>

From dabenavidesd at yahoo.es  Thu May 31 15:13:39 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 31 May 2012 14:13:39 +0100 (BST)
Subject: [M3devel] Renewed interest in Modula-3 in HP Labs
Message-ID: <1338470019.63945.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
I see there is some products coming from HP, and others, but specially HP, claiming that provide lower consumption in data center power management.
As I see they are working in Tycoon as a Data processor (created in Germany and Europe).
As Greg Nelson wrote code for profiling the Alphas and Itanium, perhaps they are interested in work on ESC, but nevertheless Modula-3 and family languages (Quest) as Tycoon is based on them.
If I may say so, Quest was defined by its simple denotational semantics, which is the natural deduction system of Baby Modula-3 (though it lacks more than that, but you can process the language of it through the former)
Do we want to confirm that, if anyone interested in the TML - TVM please write me for any other questions or comments
Thanks in advance

http://www.eetimes.com/electronics-news/4373994/HP-cuts-data-center-power-in-lab-tests?cid=NL_EETimesDaily

http://tycoon.hpl.hp.com/~tycoon/doc/users_manual_en/ch-intro.html

http://wwwmatthes.in.tum.de/file/Publications/1992/Math92/paper.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120531/3d6c107d/attachment.html>

From dabenavidesd at yahoo.es  Wed May  2 18:07:02 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 2 May 2012 17:07:02 +0100 (BST)
Subject: [M3devel] About something we shouldn't care?
Message-ID: <1335974822.36880.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
http://app.reg.techweb.com/e/es.aspx?s=2150&e=50711&elq=cef656ee4d6c4bca996b337620b98f85

Oracle is/seems to be claiming no one except them can implement their API without a license, being Android a not JVM-compatible product, then what is this for Modula-3, threads, are still of them?
IMHO I don't think this is something we should care as Modula- has received any recovery of investment of this APIs, then we could make tons of money, or me not but at least DEC, etc.
Thanks in advance


From dataf4l at gmail.com  Wed May  2 18:57:20 2012
From: dataf4l at gmail.com (felipe valdez)
Date: Wed, 2 May 2012 11:57:20 -0500
Subject: [M3devel] About something we shouldn't care?
In-Reply-To: <1335974822.36880.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <1335974822.36880.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <CAGi-_-9fCmreApLkUGZJ5-CXNGYVWuELXVrL0p=Agnx70Q37WQ@mail.gmail.com>

if oracle wins, then IBM can sue them for their SQL.



On Wed, May 2, 2012 at 11:07 AM, Daniel Alejandro Benavides D. <
dabenavidesd at yahoo.es> wrote:

> Hi all:
>
> http://app.reg.techweb.com/e/es.aspx?s=2150&e=50711&elq=cef656ee4d6c4bca996b337620b98f85
>
> Oracle is/seems to be claiming no one except them can implement their API
> without a license, being Android a not JVM-compatible product, then what is
> this for Modula-3, threads, are still of them?
> IMHO I don't think this is something we should care as Modula- has
> received any recovery of investment of this APIs, then we could make tons
> of money, or me not but at least DEC, etc.
> Thanks in advance
>



-- 
312-444-2124
Skype: f3l.headhunter
Casa: 8043901
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120502/d6e9d22b/attachment-0001.html>

From dabenavidesd at yahoo.es  Wed May  2 19:27:37 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 2 May 2012 18:27:37 +0100 (BST)
Subject: [M3devel] About something we shouldn't care?
In-Reply-To: <CAGi-_-9fCmreApLkUGZJ5-CXNGYVWuELXVrL0p=Agnx70Q37WQ@mail.gmail.com>
Message-ID: <1335979657.75013.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all.
Talking about IBM, they constructed an incremental computation system in Modula-3, so guess what does it care to be written in Modula-3
Thanks in advance

--- El mi?, 2/5/12, felipe valdez <dataf4l at gmail.com> escribi?:

De: felipe valdez <dataf4l at gmail.com>
Asunto: Re: [M3devel] About something we shouldn't care?
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: m3devel at elegosoft.com
Fecha: mi?rcoles, 2 de mayo, 2012 11:57

if oracle wins, then IBM can sue them for their SQL.



On Wed, May 2, 2012 at 11:07 AM, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:


Hi all:

http://app.reg.techweb.com/e/es.aspx?s=2150&e=50711&elq=cef656ee4d6c4bca996b337620b98f85





Oracle is/seems to be claiming no one except them can implement their API without a license, being Android a not JVM-compatible product, then what is this for Modula-3, threads, are still of them?

IMHO I don't think this is something we should care as Modula- has received any recovery of investment of this APIs, then we could make tons of money, or me not but at least DEC, etc.

Thanks in advance




-- 
312-444-2124Skype: f3l.headhunterCasa: 8043901


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120502/726b8e28/attachment-0001.html>

From dabenavidesd at yahoo.es  Wed May  2 21:24:49 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 2 May 2012 20:24:49 +0100 (BST)
Subject: [M3devel] About something we shouldn't care?
In-Reply-To: <CAGi-_-9fCmreApLkUGZJ5-CXNGYVWuELXVrL0p=Agnx70Q37WQ@mail.gmail.com>
Message-ID: <1335986689.43364.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
Besides RMI, we have exceptions, interfaces, garbage collection of references of modular type system (because this was demonstrated in Java-class like languages), which everything is an object except the object itself that is not classic language BTW, classic is Modula-3, so I don't know why they claim, C-like structures are classic:

ftp://cs.stanford.edu/cs/theory/katiyar/papers/PhDThesis.ps

And the most basic thing in Java languages are objects so, I don't know how they claim that they invented that.

Instead Modula-3 Objects are pure Object type systems, functional like Baby Modula-3, or Modular, like Modula-3 itself. But aside of that Java is not-centric object-oriented, just Modular, but Modula-3 is purely Modular, and if you want Module oriented development you are thinking in wise understood language, not in an unproven "Object-oriented" language.

Thanks in advance

--- El mi?, 2/5/12, felipe valdez <dataf4l at gmail.com> escribi?:

De: felipe valdez <dataf4l at gmail.com>
Asunto: Re: [M3devel] About something we shouldn't care?
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: m3devel at elegosoft.com
Fecha: mi?rcoles, 2 de mayo, 2012 11:57

if oracle wins, then IBM can sue them for their SQL.



On Wed, May 2, 2012 at 11:07 AM, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:


Hi all:

http://app.reg.techweb.com/e/es.aspx?s=2150&e=50711&elq=cef656ee4d6c4bca996b337620b98f85





Oracle is/seems to be claiming no one except them can implement their API without a license, being Android a not JVM-compatible product, then what is this for Modula-3, threads, are still of them?

IMHO I don't think this is something we should care as Modula- has received any recovery of investment of this APIs, then we could make tons of money, or me not but at least DEC, etc.

Thanks in advance




-- 
312-444-2124Skype: f3l.headhunterCasa: 8043901


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120502/c15d61ba/attachment-0001.html>

From dragisha at m3w.org  Fri May  4 22:37:19 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 4 May 2012 22:37:19 +0200
Subject: [M3devel] GC algorithm
Message-ID: <488CE4EB-8FAA-4D43-8481-D5DD3B3BE3FB@m3w.org>

I am not very fluent with RTCollector source, but it looks to me there is at least one possible race condition situation possible.

RTHooks.CheckStoreTraced() explicitly marks object & its page dirty/not-clean. Everything with heap locked. But - next thing is - heaps is unlocked and this method returns. What if collector from other thread "hijacks" heap right at end of CheckStoreTraced()/well before mutator changes some reference field in object? 

Similar situaction is with "read barrier" in CheckLoadTraceRef(). Or at least it looks like one to me :).

dd



From dragisha at m3w.org  Fri May  4 22:55:03 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 4 May 2012 22:55:03 +0200
Subject: [M3devel] GC algorithm
In-Reply-To: <488CE4EB-8FAA-4D43-8481-D5DD3B3BE3FB@m3w.org>
References: <488CE4EB-8FAA-4D43-8481-D5DD3B3BE3FB@m3w.org>
Message-ID: <2397638D-5AA9-4C9F-B286-452AED50F769@m3w.org>

.. Getting at this. Probably not a problem because reference is, in case when this is emitted by compiler, on stack/registers. As ambiguous root - object/page will not be altered. So, probably not race, when called as a hook from compiler emitted code?

On May 4, 2012, at 10:37 PM, Dragi?a Duri? wrote:

> I am not very fluent with RTCollector source, but it looks to me there is at least one possible race condition situation possible.
> 
> RTHooks.CheckStoreTraced() explicitly marks object & its page dirty/not-clean. Everything with heap locked. But - next thing is - heaps is unlocked and this method returns. What if collector from other thread "hijacks" heap right at end of CheckStoreTraced()/well before mutator changes some reference field in object? 
> 
> Similar situaction is with "read barrier" in CheckLoadTraceRef(). Or at least it looks like one to me :).
> 
> dd
> 



From dabenavidesd at yahoo.es  Fri May  4 23:30:32 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 4 May 2012 22:30:32 +0100 (BST)
Subject: [M3devel] A possible grammar overstrictness or ambiguity problem
Message-ID: <1336167032.54236.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
Please take a look at p. 18:
http://math.guc.edu.eg/Wafik/Characterizing%20Unambiguity.pdf

I have recreated in a small program not particulary useful to you but to the example:
///////////////////////// Main.m3 /////////////////////////////////
MODULE Main;
VAR a, b :=FALSE;

BEGIN

IF b = (NOT a)
 THEN a:=b;
END 

END Main.

It works as theory expresses but in my small program's alphabet it's overstrict, isn't it? Line 6 is a bad expression without parenthesis.

 Thanks in advance


From rodney_bates at lcwb.coop  Sun May  6 01:27:31 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 05 May 2012 18:27:31 -0500
Subject: [M3devel] A possible grammar overstrictness or ambiguity problem
In-Reply-To: <1336167032.54236.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1336167032.54236.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <4FA5B763.5030205@lcwb.coop>

Hmm, interesting.  If the expression were  NOT a = b, (and no precedence rules),
there would be two ways to parenthesize: (NOT a) = b and NOT (a = b), an
ambiguity.  Making NOT have lower precedence than = resolves this in favor
of the latter.  Equivalently, the grammar is written so that = demands each
of its operands be E4 or higher, which NOT E3 is not, it's an E2.  This fixes
this and other potential ambiguities.

But in the example, since NOT is only a prefix operator, there is only way
to parenthesize, i.e. nothing like (b =) NOT a.  So the precedence would not be
necessary in this case.  But the grammar is written to apply the precedence
rule consistently, leaving the unparenthesized version b = NOT a
underivable.  Overly strict, but maybe not worth the trouble to weaken.

An interesting exercise that I do not have the energy to do would be to
rewrite the M3 expression grammar to allow b = NOT a, without introducing
ambiguity elsewhere.  And make it work on the other prefix operators + and -.
Would be good for a textbook.

I don't think postfix operators (Selector in the grammar) can get into
a counterpart problem because they have the highest precedence.

On 05/04/2012 04:30 PM, Daniel Alejandro Benavides D. wrote:
> Hi all:
> Please take a look at p. 18:
> http://math.guc.edu.eg/Wafik/Characterizing%20Unambiguity.pdf
>
> I have recreated in a small program not particulary useful to you but to the example:
> ///////////////////////// Main.m3 /////////////////////////////////
> MODULE Main;
> VAR a, b :=FALSE;
>
> BEGIN
>
> IF b = (NOT a)
>   THEN a:=b;
> END
>
> END Main.
>
> It works as theory expresses but in my small program's alphabet it's overstrict, isn't it? Line 6 is a bad expression without parenthesis.
>
>   Thanks in advance
>


From dabenavidesd at yahoo.es  Tue May  8 22:43:13 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 21:43:13 +0100 (BST)
Subject: [M3devel] A possible grammar overstrictness or ambiguity problem
In-Reply-To: <4FA5B763.5030205@lcwb.coop>
Message-ID: <1336509793.29460.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
Thanks for the hints I have just re-read your message, I think you can purpose a multi-value suitable solution:
IF NOT a=b, 
which is in semantic analysis 
same as 
IF b = NOT a
then I think would make the case for the "fix" or vice versa, but I think language definition has no assumptions over this (or at least I can't see them).

I was thinking that we could sort of avoid this by defining a core grammar, in top of which we can put the rest, but this is the harder solution as you say. But I'm thinking along this lines, since I'm a true proposer of Baby Modula-3 be in some form (along the lines) in the Modula-3 language definition.

I wish we could talk more than in typing texts by email, but the other diea I had about this is to introduce animations (Obliq, Trestle, whatever fills our purposes, or better, Juno ones) of the Modula-3 SPWM3 book, since most of the interfaces are in the code base, I think by making a Baby Modula-3 implementation we could insert it in the Chapter 1, in same way (succinctly because Baby is small by language definition) and by allow information on it to be explained incrementally by the language itself in a cool manner.

OK, I will let you know the details, as soon I get into it, but hope you can give more hints or some opinion on anyones behalf.

Thanks in advance

--- El s?b, 5/5/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] A possible grammar overstrictness or ambiguity problem
> Para: m3devel at elegosoft.com
> Fecha: s?bado, 5 de mayo, 2012 18:27
> Hmm, interesting.  If the
> expression were  NOT a = b, (and no precedence rules),
> there would be two ways to parenthesize: (NOT a) = b and NOT
> (a = b), an
> ambiguity.  Making NOT have lower precedence than =
> resolves this in favor
> of the latter.  Equivalently, the grammar is written so
> that = demands each
> of its operands be E4 or higher, which NOT E3 is not, it's
> an E2.  This fixes
> this and other potential ambiguities.
> 
> But in the example, since NOT is only a prefix operator,
> there is only way
> to parenthesize, i.e. nothing like (b =) NOT a.  So the
> precedence would not be
> necessary in this case.  But the grammar is written to
> apply the precedence
> rule consistently, leaving the unparenthesized version b =
> NOT a
> underivable.  Overly strict, but maybe not worth the
> trouble to weaken.
> 
> An interesting exercise that I do not have the energy to do
> would be to
> rewrite the M3 expression grammar to allow b = NOT a,
> without introducing
> ambiguity elsewhere.  And make it work on the other
> prefix operators + and -.
> Would be good for a textbook.
> 
> I don't think postfix operators (Selector in the grammar)
> can get into
> a counterpart problem because they have the highest
> precedence.
> 
> On 05/04/2012 04:30 PM, Daniel Alejandro Benavides D.
> wrote:
> > Hi all:
> > Please take a look at p. 18:
> > http://math.guc.edu.eg/Wafik/Characterizing%20Unambiguity.pdf
> >
> > I have recreated in a small program not particulary
> useful to you but to the example:
> > ///////////////////////// Main.m3
> /////////////////////////////////
> > MODULE Main;
> > VAR a, b :=FALSE;
> >
> > BEGIN
> >
> > IF b = (NOT a)
> >   THEN a:=b;
> > END
> >
> > END Main.
> >
> > It works as theory expresses but in my small program's
> alphabet it's overstrict, isn't it? Line 6 is a bad
> expression without parenthesis.
> >
> >   Thanks in advance
> >
> 


From dabenavidesd at yahoo.es  Tue May  8 22:58:05 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 21:58:05 +0100 (BST)
Subject: [M3devel] GC algorithm
In-Reply-To: <2397638D-5AA9-4C9F-B286-452AED50F769@m3w.org>
Message-ID: <1336510685.96265.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
Dragisha I can't be quite sure what are you talking about but assuming arbitrary implementations must be the best way to talk respect of the language itself. (This is to me ask the same question but in a garbage Collector-less way)
Thanks in advance

--- El vie, 4/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 4 de mayo, 2012 15:55
> .. Getting at this. Probably not a
> problem because reference is, in case when this is emitted
> by compiler, on stack/registers. As ambiguous root -
> object/page will not be altered. So, probably not race, when
> called as a hook from compiler emitted code?
> 
> On May 4, 2012, at 10:37 PM, Dragi?a Duri? wrote:
> 
> > I am not very fluent with RTCollector source, but it
> looks to me there is at least one possible race condition
> situation possible.
> > 
> > RTHooks.CheckStoreTraced() explicitly marks object
> & its page dirty/not-clean. Everything with heap locked.
> But - next thing is - heaps is unlocked and this method
> returns. What if collector from other thread "hijacks" heap
> right at end of CheckStoreTraced()/well before mutator
> changes some reference field in object? 
> > 
> > Similar situaction is with "read barrier" in
> CheckLoadTraceRef(). Or at least it looks like one to me
> :).
> > 
> > dd
> > 
> 
> 


From dragisha at m3w.org  Tue May  8 23:21:45 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 8 May 2012 23:21:45 +0200
Subject: [M3devel] GC algorithm
In-Reply-To: <F1D953B3-6D64-4A07-B983-7DDC91C6C363@gmail.com>
References: <488CE4EB-8FAA-4D43-8481-D5DD3B3BE3FB@m3w.org>
	<F1D953B3-6D64-4A07-B983-7DDC91C6C363@gmail.com>
Message-ID: <E63127A8-6383-4A46-AF8A-3B6F2CCCF561@m3w.org>

Got that. You pointed write barrier to me few yrs ago, and that's it.

I am reading through RTCollector.m3 in pieces of time I have to spare. Lots of legacy code there. Any good reaosn to keep several different functionalities in single source module? Like RTWeakRef, lots of differentable mutator/collector code and so on?

On May 8, 2012, at 11:12 PM, Antony Hosking wrote:

> Just following up quickly while extremely rushed.
> Indeed, the fact that the mutator has the references on its stack will cause their targets to be pinned (not copied) if a collection intervenes between the marking and before the store.  So, they will be retained.
> 
> On May 4, 2012, at 4:37 PM, Dragi?a Duri? wrote:
> 
>> I am not very fluent with RTCollector source, but it looks to me there is at least one possible race condition situation possible.
>> 
>> RTHooks.CheckStoreTraced() explicitly marks object & its page dirty/not-clean. Everything with heap locked. But - next thing is - heaps is unlocked and this method returns. What if collector from other thread "hijacks" heap right at end of CheckStoreTraced()/well before mutator changes some reference field in object? 
>> 
>> Similar situaction is with "read barrier" in CheckLoadTraceRef(). Or at least it looks like one to me :).
>> 
>> dd
>> 
> 



From dabenavidesd at yahoo.es  Wed May  9 00:02:56 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 23:02:56 +0100 (BST)
Subject: [M3devel] GC algorithm
In-Reply-To: <E63127A8-6383-4A46-AF8A-3B6F2CCCF561@m3w.org>
Message-ID: <1336514576.13662.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
for my God sake, I think is better to be useful than useless, and if that's different from general than specific, that's better, but be careful, we could loose some Boehm GC correspondence in Gcc GC, which would in turn be useful for timing and short cutting the native Modula-3 Collector, specially RTCollector SRC and perhaps the SUN test suite module (more on this later). Tony and his team did that:

http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html

Thanks in advance

--- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "Antony Hosking" <antony.hosking at gmail.com>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 8 de mayo, 2012 16:21
> Got that. You pointed write barrier
> to me few yrs ago, and that's it.
> 
> I am reading through RTCollector.m3 in pieces of time I have
> to spare. Lots of legacy code there. Any good reaosn to keep
> several different functionalities in single source module?
> Like RTWeakRef, lots of differentable mutator/collector code
> and so on?
> 
> On May 8, 2012, at 11:12 PM, Antony Hosking wrote:
> 
> > Just following up quickly while extremely rushed.
> > Indeed, the fact that the mutator has the references on
> its stack will cause their targets to be pinned (not copied)
> if a collection intervenes between the marking and before
> the store.  So, they will be retained.
> > 
> > On May 4, 2012, at 4:37 PM, Dragi?a Duri? wrote:
> > 
> >> I am not very fluent with RTCollector source, but
> it looks to me there is at least one possible race condition
> situation possible.
> >> 
> >> RTHooks.CheckStoreTraced() explicitly marks object
> & its page dirty/not-clean. Everything with heap locked.
> But - next thing is - heaps is unlocked and this method
> returns. What if collector from other thread "hijacks" heap
> right at end of CheckStoreTraced()/well before mutator
> changes some reference field in object? 
> >> 
> >> Similar situaction is with "read barrier" in
> CheckLoadTraceRef(). Or at least it looks like one to me
> :).
> >> 
> >> dd
> >> 
> > 
> 
> 


From dabenavidesd at yahoo.es  Wed May  9 00:20:16 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 23:20:16 +0100 (BST)
Subject: [M3devel] "The New Native Languages" time for us to code a Modula-3
	JIT compiler?
Message-ID: <1336515616.28079.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:

http://app.reg.techweb.com/e/es.aspx?s=2150&e=52494&elq=b491fb8f21d64a28ab346c4bc41650e6

I know of a "unclassified" tool for doing that but end support is a need symbolically speaking.

A guy was working on a LLVM backend, but I don't know, does anyone plans some sort of M3CG related project?

Thanks in advance


From dragisha at m3w.org  Wed May  9 00:20:30 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 9 May 2012 00:20:30 +0200
Subject: [M3devel] GC algorithm
In-Reply-To: <1336514576.13662.YahooMailClassic@web29703.mail.ird.yahoo.com>
References: <1336514576.13662.YahooMailClassic@web29703.mail.ird.yahoo.com>
Message-ID: <F3E03E0F-AD87-4573-8280-A802AAA34C7B@m3w.org>

G1 collector sounds interesting, and funny. Pause prediction - good luck with that.

Fast sweep through blurb on that page and I think this collector of theirs is a bit behind what we have in Modula-3. No wonder - Modula-3 had what they are describing and few things more years before Java existed.

Interesting tidbit, maybe. If they can collect with multiple threads at same time, that _is_ something new. But they danced around that on that page.

Also, G1 is not what Antony and his team did. They made real-time collector, and G1 is not. I think link was posted here some time ago.

On May 9, 2012, at 12:02 AM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> for my God sake, I think is better to be useful than useless, and if that's different from general than specific, that's better, but be careful, we could loose some Boehm GC correspondence in Gcc GC, which would in turn be useful for timing and short cutting the native Modula-3 Collector, specially RTCollector SRC and perhaps the SUN test suite module (more on this later). Tony and his team did that:
> 
> http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
> 
> Thanks in advance
> 
> --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
>> De: Dragi?a Duri? <dragisha at m3w.org>
>> Asunto: Re: [M3devel] GC algorithm
>> Para: "Antony Hosking" <antony.hosking at gmail.com>
>> CC: "m3devel" <m3devel at elegosoft.com>
>> Fecha: martes, 8 de mayo, 2012 16:21
>> Got that. You pointed write barrier
>> to me few yrs ago, and that's it.
>> 
>> I am reading through RTCollector.m3 in pieces of time I have
>> to spare. Lots of legacy code there. Any good reaosn to keep
>> several different functionalities in single source module?
>> Like RTWeakRef, lots of differentable mutator/collector code
>> and so on?
>> 
>> On May 8, 2012, at 11:12 PM, Antony Hosking wrote:
>> 
>>> Just following up quickly while extremely rushed.
>>> Indeed, the fact that the mutator has the references on
>> its stack will cause their targets to be pinned (not copied)
>> if a collection intervenes between the marking and before
>> the store.  So, they will be retained.
>>> 
>>> On May 4, 2012, at 4:37 PM, Dragi?a Duri? wrote:
>>> 
>>>> I am not very fluent with RTCollector source, but
>> it looks to me there is at least one possible race condition
>> situation possible.
>>>> 
>>>> RTHooks.CheckStoreTraced() explicitly marks object
>> & its page dirty/not-clean. Everything with heap locked.
>> But - next thing is - heaps is unlocked and this method
>> returns. What if collector from other thread "hijacks" heap
>> right at end of CheckStoreTraced()/well before mutator
>> changes some reference field in object? 
>>>> 
>>>> Similar situaction is with "read barrier" in
>> CheckLoadTraceRef(). Or at least it looks like one to me
>> :).
>>>> 
>>>> dd
>>>> 
>>> 
>> 
>> 



From dabenavidesd at yahoo.es  Wed May  9 00:36:27 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 23:36:27 +0100 (BST)
Subject: [M3devel] GC algorithm
In-Reply-To: <F3E03E0F-AD87-4573-8280-A802AAA34C7B@m3w.org>
Message-ID: <1336516587.51821.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
OK, understood, I think this kind of philosophy is smoother:
http://static.usenix.org/events/coots99/full_papers/liang/liang.pdf

Similarly the CM JVM  can be applied to this test too.

Look at this old news (it seems they didn't believe it that much, probably that's why they never released it):
http://www.informationweek.com/newsflash/nf655/1105_st9.htm

Thanks in advance

--- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "Antony Hosking" <antony.hosking at gmail.com>, "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 8 de mayo, 2012 17:20
> G1 collector sounds interesting, and
> funny. Pause prediction - good luck with that.
> 
> Fast sweep through blurb on that page and I think this
> collector of theirs is a bit behind what we have in
> Modula-3. No wonder - Modula-3 had what they are describing
> and few things more years before Java existed.
> 
> Interesting tidbit, maybe. If they can collect with multiple
> threads at same time, that _is_ something new. But they
> danced around that on that page.
> 
> Also, G1 is not what Antony and his team did. They made
> real-time collector, and G1 is not. I think link was posted
> here some time ago.
> 
> On May 9, 2012, at 12:02 AM, Daniel Alejandro Benavides D.
> wrote:
> 
> > Hi all:
> > for my God sake, I think is better to be useful than
> useless, and if that's different from general than specific,
> that's better, but be careful, we could loose some Boehm GC
> correspondence in Gcc GC, which would in turn be useful for
> timing and short cutting the native Modula-3 Collector,
> specially RTCollector SRC and perhaps the SUN test suite
> module (more on this later). Tony and his team did that:
> > 
> > http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
> > 
> > Thanks in advance
> > 
> > --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> >> De: Dragi?a Duri? <dragisha at m3w.org>
> >> Asunto: Re: [M3devel] GC algorithm
> >> Para: "Antony Hosking" <antony.hosking at gmail.com>
> >> CC: "m3devel" <m3devel at elegosoft.com>
> >> Fecha: martes, 8 de mayo, 2012 16:21
> >> Got that. You pointed write barrier
> >> to me few yrs ago, and that's it.
> >> 
> >> I am reading through RTCollector.m3 in pieces of
> time I have
> >> to spare. Lots of legacy code there. Any good
> reaosn to keep
> >> several different functionalities in single source
> module?
> >> Like RTWeakRef, lots of differentable
> mutator/collector code
> >> and so on?
> >> 
> >> On May 8, 2012, at 11:12 PM, Antony Hosking wrote:
> >> 
> >>> Just following up quickly while extremely
> rushed.
> >>> Indeed, the fact that the mutator has the
> references on
> >> its stack will cause their targets to be pinned
> (not copied)
> >> if a collection intervenes between the marking and
> before
> >> the store.  So, they will be retained.
> >>> 
> >>> On May 4, 2012, at 4:37 PM, Dragi?a Duri?
> wrote:
> >>> 
> >>>> I am not very fluent with RTCollector
> source, but
> >> it looks to me there is at least one possible race
> condition
> >> situation possible.
> >>>> 
> >>>> RTHooks.CheckStoreTraced() explicitly marks
> object
> >> & its page dirty/not-clean. Everything with
> heap locked.
> >> But - next thing is - heaps is unlocked and this
> method
> >> returns. What if collector from other thread
> "hijacks" heap
> >> right at end of CheckStoreTraced()/well before
> mutator
> >> changes some reference field in object? 
> >>>> 
> >>>> Similar situaction is with "read barrier"
> in
> >> CheckLoadTraceRef(). Or at least it looks like one
> to me
> >> :).
> >>>> 
> >>>> dd
> >>>> 
> >>> 
> >> 
> >> 
> 
> 


From dragisha at m3w.org  Wed May  9 00:40:17 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 9 May 2012 00:40:17 +0200
Subject: [M3devel] GC algorithm
In-Reply-To: <1336516587.51821.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1336516587.51821.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <325641F7-37AF-4BCC-AB5C-78C1172090F0@m3w.org>

Very old news. In JVM world - five years is a lot. 13yrs are another age :).
 
On May 9, 2012, at 12:36 AM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> OK, understood, I think this kind of philosophy is smoother:
> http://static.usenix.org/events/coots99/full_papers/liang/liang.pdf
> 
> Similarly the CM JVM  can be applied to this test too.
> 
> Look at this old news (it seems they didn't believe it that much, probably that's why they never released it):
> http://www.informationweek.com/newsflash/nf655/1105_st9.htm
> 
> Thanks in advance
> 
> --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
>> De: Dragi?a Duri? <dragisha at m3w.org>
>> Asunto: Re: [M3devel] GC algorithm
>> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
>> CC: "Antony Hosking" <antony.hosking at gmail.com>, "m3devel" <m3devel at elegosoft.com>
>> Fecha: martes, 8 de mayo, 2012 17:20
>> G1 collector sounds interesting, and
>> funny. Pause prediction - good luck with that.
>> 
>> Fast sweep through blurb on that page and I think this
>> collector of theirs is a bit behind what we have in
>> Modula-3. No wonder - Modula-3 had what they are describing
>> and few things more years before Java existed.
>> 
>> Interesting tidbit, maybe. If they can collect with multiple
>> threads at same time, that _is_ something new. But they
>> danced around that on that page.
>> 
>> Also, G1 is not what Antony and his team did. They made
>> real-time collector, and G1 is not. I think link was posted
>> here some time ago.
>> 
>> On May 9, 2012, at 12:02 AM, Daniel Alejandro Benavides D.
>> wrote:
>> 
>>> Hi all:
>>> for my God sake, I think is better to be useful than
>> useless, and if that's different from general than specific,
>> that's better, but be careful, we could loose some Boehm GC
>> correspondence in Gcc GC, which would in turn be useful for
>> timing and short cutting the native Modula-3 Collector,
>> specially RTCollector SRC and perhaps the SUN test suite
>> module (more on this later). Tony and his team did that:
>>> 
>>> http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
>>> 
>>> Thanks in advance
>>> 
>>> --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org>
>> escribi?:
>>> 
>>>> De: Dragi?a Duri? <dragisha at m3w.org>
>>>> Asunto: Re: [M3devel] GC algorithm
>>>> Para: "Antony Hosking" <antony.hosking at gmail.com>
>>>> CC: "m3devel" <m3devel at elegosoft.com>
>>>> Fecha: martes, 8 de mayo, 2012 16:21
>>>> Got that. You pointed write barrier
>>>> to me few yrs ago, and that's it.
>>>> 
>>>> I am reading through RTCollector.m3 in pieces of
>> time I have
>>>> to spare. Lots of legacy code there. Any good
>> reaosn to keep
>>>> several different functionalities in single source
>> module?
>>>> Like RTWeakRef, lots of differentable
>> mutator/collector code
>>>> and so on?
>>>> 
>>>> On May 8, 2012, at 11:12 PM, Antony Hosking wrote:
>>>> 
>>>>> Just following up quickly while extremely
>> rushed.
>>>>> Indeed, the fact that the mutator has the
>> references on
>>>> its stack will cause their targets to be pinned
>> (not copied)
>>>> if a collection intervenes between the marking and
>> before
>>>> the store.  So, they will be retained.
>>>>> 
>>>>> On May 4, 2012, at 4:37 PM, Dragi?a Duri?
>> wrote:
>>>>> 
>>>>>> I am not very fluent with RTCollector
>> source, but
>>>> it looks to me there is at least one possible race
>> condition
>>>> situation possible.
>>>>>> 
>>>>>> RTHooks.CheckStoreTraced() explicitly marks
>> object
>>>> & its page dirty/not-clean. Everything with
>> heap locked.
>>>> But - next thing is - heaps is unlocked and this
>> method
>>>> returns. What if collector from other thread
>> "hijacks" heap
>>>> right at end of CheckStoreTraced()/well before
>> mutator
>>>> changes some reference field in object? 
>>>>>> 
>>>>>> Similar situaction is with "read barrier"
>> in
>>>> CheckLoadTraceRef(). Or at least it looks like one
>> to me
>>>> :).
>>>>>> 
>>>>>> dd
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>> 



From dabenavidesd at yahoo.es  Wed May  9 00:47:29 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 23:47:29 +0100 (BST)
Subject: [M3devel] GC algorithm
In-Reply-To: <325641F7-37AF-4BCC-AB5C-78C1172090F0@m3w.org>
Message-ID: <1336517249.96878.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:

but contemporary of the SUN's profiler article.

Thanks in advance


--- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "Antony Hosking" <antony.hosking at gmail.com>, "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 8 de mayo, 2012 17:40
> Very old news. In JVM world - five
> years is a lot. 13yrs are another age :).
>  
> On May 9, 2012, at 12:36 AM, Daniel Alejandro Benavides D.
> wrote:
> 
> > Hi all:
> > OK, understood, I think this kind of philosophy is
> smoother:
> > http://static.usenix.org/events/coots99/full_papers/liang/liang.pdf
> > 
> > Similarly the CM JVM  can be applied to this test
> too.
> > 
> > Look at this old news (it seems they didn't believe it
> that much, probably that's why they never released it):
> > http://www.informationweek.com/newsflash/nf655/1105_st9.htm
> > 
> > Thanks in advance
> > 
> > --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> >> De: Dragi?a Duri? <dragisha at m3w.org>
> >> Asunto: Re: [M3devel] GC algorithm
> >> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> >> CC: "Antony Hosking" <antony.hosking at gmail.com>,
> "m3devel" <m3devel at elegosoft.com>
> >> Fecha: martes, 8 de mayo, 2012 17:20
> >> G1 collector sounds interesting, and
> >> funny. Pause prediction - good luck with that.
> >> 
> >> Fast sweep through blurb on that page and I think
> this
> >> collector of theirs is a bit behind what we have
> in
> >> Modula-3. No wonder - Modula-3 had what they are
> describing
> >> and few things more years before Java existed.
> >> 
> >> Interesting tidbit, maybe. If they can collect with
> multiple
> >> threads at same time, that _is_ something new. But
> they
> >> danced around that on that page.
> >> 
> >> Also, G1 is not what Antony and his team did. They
> made
> >> real-time collector, and G1 is not. I think link
> was posted
> >> here some time ago.
> >> 
> >> On May 9, 2012, at 12:02 AM, Daniel Alejandro
> Benavides D.
> >> wrote:
> >> 
> >>> Hi all:
> >>> for my God sake, I think is better to be useful
> than
> >> useless, and if that's different from general than
> specific,
> >> that's better, but be careful, we could loose some
> Boehm GC
> >> correspondence in Gcc GC, which would in turn be
> useful for
> >> timing and short cutting the native Modula-3
> Collector,
> >> specially RTCollector SRC and perhaps the SUN test
> suite
> >> module (more on this later). Tony and his team did
> that:
> >>> 
> >>> http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
> >>> 
> >>> Thanks in advance
> >>> 
> >>> --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org>
> >> escribi?:
> >>> 
> >>>> De: Dragi?a Duri? <dragisha at m3w.org>
> >>>> Asunto: Re: [M3devel] GC algorithm
> >>>> Para: "Antony Hosking" <antony.hosking at gmail.com>
> >>>> CC: "m3devel" <m3devel at elegosoft.com>
> >>>> Fecha: martes, 8 de mayo, 2012 16:21
> >>>> Got that. You pointed write barrier
> >>>> to me few yrs ago, and that's it.
> >>>> 
> >>>> I am reading through RTCollector.m3 in
> pieces of
> >> time I have
> >>>> to spare. Lots of legacy code there. Any
> good
> >> reaosn to keep
> >>>> several different functionalities in single
> source
> >> module?
> >>>> Like RTWeakRef, lots of differentable
> >> mutator/collector code
> >>>> and so on?
> >>>> 
> >>>> On May 8, 2012, at 11:12 PM, Antony Hosking
> wrote:
> >>>> 
> >>>>> Just following up quickly while
> extremely
> >> rushed.
> >>>>> Indeed, the fact that the mutator has
> the
> >> references on
> >>>> its stack will cause their targets to be
> pinned
> >> (not copied)
> >>>> if a collection intervenes between the
> marking and
> >> before
> >>>> the store.  So, they will be
> retained.
> >>>>> 
> >>>>> On May 4, 2012, at 4:37 PM, Dragi?a
> Duri?
> >> wrote:
> >>>>> 
> >>>>>> I am not very fluent with
> RTCollector
> >> source, but
> >>>> it looks to me there is at least one
> possible race
> >> condition
> >>>> situation possible.
> >>>>>> 
> >>>>>> RTHooks.CheckStoreTraced()
> explicitly marks
> >> object
> >>>> & its page dirty/not-clean. Everything
> with
> >> heap locked.
> >>>> But - next thing is - heaps is unlocked and
> this
> >> method
> >>>> returns. What if collector from other
> thread
> >> "hijacks" heap
> >>>> right at end of CheckStoreTraced()/well
> before
> >> mutator
> >>>> changes some reference field in object? 
> >>>>>> 
> >>>>>> Similar situaction is with "read
> barrier"
> >> in
> >>>> CheckLoadTraceRef(). Or at least it looks
> like one
> >> to me
> >>>> :).
> >>>>>> 
> >>>>>> dd
> >>>>>> 
> >>>>> 
> >>>> 
> >>>> 
> >> 
> >> 
> 
> 


From dragisha at m3w.org  Fri May 11 09:44:17 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 11 May 2012 09:44:17 +0200
Subject: [M3devel] Proposal for new pragma
Message-ID: <A1D021C3-0B10-4D2C-B0E2-FADCF857850E@m3w.org>

DEBUG and ASSERT pragmas are good examples of very helpful and almost non-intrusive debug features. UNUSED is also worth mention.

Another good one can be a way to tell compiler where some object is expected to be referenced. I am just reading big source and part of what I do is to add comments - in particular I comment where from is some procedure called/variable used. Putting this in pragma will not change language at all, but will help writing correct programs a lot.

Also, once we establish a framework for such attributes, steps can be taken towards further ways to ensure correctness of code we write.



From dragisha at m3w.org  Fri May 11 09:49:41 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 11 May 2012 09:49:41 +0200
Subject: [M3devel] Proposal for new pragma
Message-ID: <1EB31CDB-C6DC-4A42-B9EE-3CA0743028A0@m3w.org>

DEBUG and ASSERT pragmas are good examples of very helpful and almost non-intrusive debug features. UNUSED is also worth mention.

Another good one can be a way to tell compiler where some object is expected to be referenced. I am just reading big source and part of what I do is to add comments - in particular I comment where from is some procedure called/variable used. Putting this in pragma will not change language at all, but will help writing correct programs a lot.

Also, once we establish a framework for such attributes, steps can be taken towards further ways to ensure correctness of code we write.



From dabenavidesd at yahoo.es  Fri May 11 17:08:03 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 11 May 2012 16:08:03 +0100 (BST)
Subject: [M3devel] Proposal for new pragma
In-Reply-To: <82A6C364-C699-4C7C-B482-F197EF4D4D1B@m3w.org>
Message-ID: <1336748883.38986.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
any program can have such construct? The main con is if it does what does it mean to be undetected side-effects, sort of writing for your self. Also what does the program needs to do to ensure safety under such considerations. For instance does it allows a program to be checked?
It is not moral correct to write something to hide details of the implementation to it but to your self?
OK, you can ignore some details I guess but then who cares what you don't know, more than we don't know. This is the ideal; isn't to expose the structure of an operation towards getting the correct answer, if you can't make both something is wrong, both your program or your language.
In certain sense we can avoid undetected side-effects, but your responsibility is about it where there are ones. If your program can check or know that I think is wrong respect of that programmer, since he should read it without that help. Right? 
Thanks in advance
 

--- El vie, 11/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] Proposal for new pragma
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> Fecha: viernes, 11 de mayo, 2012 09:31
> Code readability will be nice effect
> of such a pragma. And - if written correctly, all pragmas
> have no to minimal side-effects.
> 
> On May 11, 2012, at 4:26 PM, Daniel Alejandro Benavides D.
> wrote:
> 
> > Hi all:
> > I'm not sure whether you want to handle inter
> procedural side effects, if that's the case Modula-3 done
> code needs arbitrary annotations of such constructs isn't
> guaranteed to be safely isolated since every annotation is
> side-effected then it could led towards the not sound
> Modular checking of ESC/Modula-3, etc. This is a natural
> deduction system.
> > Having said that I think is a good idea to allow
> recursion logic to Modula-3 procedures but this is precisely
> what Baby Modula-3 is about.
> > I don't have more details at hand but I think the idea
> if is yours the same has better compression of code,
> optimization and safe execution.
> > The good news is that object-code view of objects in
> Baby Modula-3 and Modula-3 is the same so all benefits are
> applicable.
> > Perhaps the other approach is just use the M3 AST and
> someone has done something akin to localize uncalled
> procedures, etc.
> > Thanks in advance
> > 
> > --- El vie, 11/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> >> De: Dragi?a Duri? <dragisha at m3w.org>
> >> Asunto: [M3devel] Proposal for new pragma
> >> Para: "m3devel" <m3devel at elegosoft.com>
> >> Fecha: viernes, 11 de mayo, 2012 02:49
> >> DEBUG and ASSERT pragmas are good
> >> examples of very helpful and almost non-intrusive
> debug
> >> features. UNUSED is also worth mention.
> >> 
> >> Another good one can be a way to tell compiler
> where some
> >> object is expected to be referenced. I am just
> reading big
> >> source and part of what I do is to add comments -
> in
> >> particular I comment where from is some procedure
> >> called/variable used. Putting this in pragma will
> not change
> >> language at all, but will help writing correct
> programs a
> >> lot.
> >> 
> >> Also, once we establish a framework for such
> attributes,
> >> steps can be taken towards further ways to ensure
> >> correctness of code we write.
> >> 
> >> 
> 
> 


From dragisha at m3w.org  Fri May 11 19:29:35 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 11 May 2012 19:29:35 +0200
Subject: [M3devel] Proposal for new pragma
In-Reply-To: <1336748883.38986.YahooMailClassic@web29704.mail.ird.yahoo.com>
References: <1336748883.38986.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <4B5415DB-107E-49EC-9AE7-7DCFB5088114@m3w.org>

It would ne kind of DEBUG/ASSERT/UNUSED.

Obviously, it is meant to be used in implementation. And to be optional. You may use it, but you don't have to.

As for moral? I'll no comment it :).

Side-effects are possible with DEBUG/ASSERT. They will be possible with this new pragma. Take care.

On May 11, 2012, at 5:08 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> any program can have such construct? The main con is if it does what does it mean to be undetected side-effects, sort of writing for your self. Also what does the program needs to do to ensure safety under such considerations. For instance does it allows a program to be checked?
> It is not moral correct to write something to hide details of the implementation to it but to your self?
> OK, you can ignore some details I guess but then who cares what you don't know, more than we don't know. This is the ideal; isn't to expose the structure of an operation towards getting the correct answer, if you can't make both something is wrong, both your program or your language.
> In certain sense we can avoid undetected side-effects, but your responsibility is about it where there are ones. If your program can check or know that I think is wrong respect of that programmer, since he should read it without that help. Right? 
> Thanks in advance
> 
> 
> --- El vie, 11/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
>> De: Dragi?a Duri? <dragisha at m3w.org>
>> Asunto: Re: [M3devel] Proposal for new pragma
>> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
>> Fecha: viernes, 11 de mayo, 2012 09:31
>> Code readability will be nice effect
>> of such a pragma. And - if written correctly, all pragmas
>> have no to minimal side-effects.
>> 
>> On May 11, 2012, at 4:26 PM, Daniel Alejandro Benavides D.
>> wrote:
>> 
>>> Hi all:
>>> I'm not sure whether you want to handle inter
>> procedural side effects, if that's the case Modula-3 done
>> code needs arbitrary annotations of such constructs isn't
>> guaranteed to be safely isolated since every annotation is
>> side-effected then it could led towards the not sound
>> Modular checking of ESC/Modula-3, etc. This is a natural
>> deduction system.
>>> Having said that I think is a good idea to allow
>> recursion logic to Modula-3 procedures but this is precisely
>> what Baby Modula-3 is about.
>>> I don't have more details at hand but I think the idea
>> if is yours the same has better compression of code,
>> optimization and safe execution.
>>> The good news is that object-code view of objects in
>> Baby Modula-3 and Modula-3 is the same so all benefits are
>> applicable.
>>> Perhaps the other approach is just use the M3 AST and
>> someone has done something akin to localize uncalled
>> procedures, etc.
>>> Thanks in advance
>>> 
>>> --- El vie, 11/5/12, Dragi?a Duri? <dragisha at m3w.org>
>> escribi?:
>>> 
>>>> De: Dragi?a Duri? <dragisha at m3w.org>
>>>> Asunto: [M3devel] Proposal for new pragma
>>>> Para: "m3devel" <m3devel at elegosoft.com>
>>>> Fecha: viernes, 11 de mayo, 2012 02:49
>>>> DEBUG and ASSERT pragmas are good
>>>> examples of very helpful and almost non-intrusive
>> debug
>>>> features. UNUSED is also worth mention.
>>>> 
>>>> Another good one can be a way to tell compiler
>> where some
>>>> object is expected to be referenced. I am just
>> reading big
>>>> source and part of what I do is to add comments -
>> in
>>>> particular I comment where from is some procedure
>>>> called/variable used. Putting this in pragma will
>> not change
>>>> language at all, but will help writing correct
>> programs a
>>>> lot.
>>>> 
>>>> Also, once we establish a framework for such
>> attributes,
>>>> steps can be taken towards further ways to ensure
>>>> correctness of code we write.
>>>> 
>>>> 
>> 
>> 



From hendrik at topoi.pooq.com  Sun May 13 19:47:47 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Sun, 13 May 2012 13:47:47 -0400
Subject: [M3devel] libXaw.so.6 again
Message-ID: <20120513174747.GA25729@topoi.pooq.com>

I just installed the AMD64 LINUX deb on my aging Debian stable system, 
tried it out, and got the familiar=from-years-ago message

 -> linking PgMdb
/usr/bin/ld: warning: libXaw.so.6, needed by 
/usr/local/cm3/pkg/formsvbt/AMD64_LINUX/libm3formsvbt.so, not found (try 
using -rpath or -rpath-link)
collect2: ld returned 1 exit status
  m3_link => 1
linker failed linking: PgMdb

Now the obvious thing to do is to install libXaw.so.6.

Except that the only libXaw packages available are libXaw7, libXaw7-dev, 
and similar for libXaw8.

So it  looks as if the .deb needs updating, presumably with a new Debian 
version number affixed.

-- hendrik



From hendrik at topoi.pooq.com  Sun May 13 19:50:49 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Sun, 13 May 2012 13:50:49 -0400
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120513174747.GA25729@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
Message-ID: <20120513175049.GA25774@topoi.pooq.com>

On Sun, May 13, 2012 at 01:47:47PM -0400, Hendrik Boom wrote:
> I just installed the AMD64 LINUX deb on my aging Debian stable system, 
> tried it out, and got the familiar=from-years-ago message
> 
>  -> linking PgMdb
> /usr/bin/ld: warning: libXaw.so.6, needed by 
> /usr/local/cm3/pkg/formsvbt/AMD64_LINUX/libm3formsvbt.so, not found (try 
> using -rpath or -rpath-link)
> collect2: ld returned 1 exit status
>   m3_link => 1
> linker failed linking: PgMdb
> 
> Now the obvious thing to do is to install libXaw.so.6.
> 
> Except that the only libXaw packages available are libXaw7, libXaw7-dev, 
> and similar for libXaw8.

Correction: no libXaw8-dev.
> 
> So it  looks as if the .deb needs updating, presumably with a new Debian 
> version number affixed.
> 
> -- hendrik
> 

The situation is pretty well the same on Debian testing i386.

-- hendrik



From dabenavidesd at yahoo.es  Sun May 13 20:06:44 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 13 May 2012 19:06:44 +0100 (BST)
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120513174747.GA25729@topoi.pooq.com>
Message-ID: <1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I think the packages in deb already do that so.6, so.7 thing for that purposes, you don't need to that for yourself, I believe.
Likewise, would be nicer if we could just relink a single executable for both kind of systems, both 32-bit and 64-bit, if there were 32-bit INTEGER and ADDRESS and 128-bit LONGINT and LONGADDRESS and 128-bit LONGCARD I think it could make a better precision arithmetic or double-length at less.
Thanks in advance

--- El dom, 13/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] libXaw.so.6 again
> Para: m3devel at elegosoft.com
> Fecha: domingo, 13 de mayo, 2012 12:47
> I just installed the AMD64 LINUX deb
> on my aging Debian stable system, 
> tried it out, and got the familiar=from-years-ago message
> 
>  -> linking PgMdb
> /usr/bin/ld: warning: libXaw.so.6, needed by 
> /usr/local/cm3/pkg/formsvbt/AMD64_LINUX/libm3formsvbt.so,
> not found (try 
> using -rpath or -rpath-link)
> collect2: ld returned 1 exit status
>   m3_link => 1
> linker failed linking: PgMdb
> 
> Now the obvious thing to do is to install libXaw.so.6.
> 
> Except that the only libXaw packages available are libXaw7,
> libXaw7-dev, 
> and similar for libXaw8.
> 
> So it  looks as if the .deb needs updating, presumably
> with a new Debian 
> version number affixed.
> 
> -- hendrik
> 
> 


From hendrik at topoi.pooq.com  Mon May 14 04:52:18 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Sun, 13 May 2012 22:52:18 -0400
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <20120514025218.GA32463@topoi.pooq.com>

On Sun, May 13, 2012 at 07:06:44PM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all:
> I think the packages in deb already do that so.6, so.7 thing for that 
> purposes, you don't need to that for yourself, I believe.

Whatever do you mean?  It wants libXaw.so.6, which no longer exists and 
has been replaced by libXaw.so.7.  Whatever "that so.6, so.7 thing" is 
that the packages in deb already do, the modula 2 in the debian package 
I downloaded just now from the Modula 3 website insists that my 
executable needs libXaw.so.6, not the one I have available.

Maybe if the .deb were recompiled and repackaged from source it would 
find libXaw.so.7, but the one now available does not.

-- hendrik

> Likewise, would be nicer if we could just relink a single executable 
> for both kind of systems, both 32-bit and 64-bit, if there were 32-bit 
> INTEGER and ADDRESS and 128-bit LONGINT and LONGADDRESS and 128-bit 
> LONGCARD I think it could make a better precision arithmetic or 
> double-length at less.

This has nothing to do with the question.

-- hendrik


From dabenavidesd at yahoo.es  Mon May 14 07:24:11 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 May 2012 06:24:11 +0100 (BST)
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120514025218.GA32463@topoi.pooq.com>
Message-ID: <1336973051.28791.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
OK, thanks for the message, I meant what I think is the case for say Ubuntu 8.04 Dapper LTS (Long time support), have libXaw6 and libXaw7 packages in .deb.
I don't think that you need to relink the all package (or worse than that rebuild to link .so.7) but just use your OS for that (because we will loose support for other OSes that don't have literally have such version).
And to make a smarter solution I would use LONG (adress) arithmetic to relink same executable for two kind of "different" architectures. You think isn't the same, but I think they are but one is just an extension of the other so why not support that as well.
Then why would you need to test I386, and AMD64 versions (then the question is the name of that target x86-32AMD64), but just the same executable and the same thing (again, use your OS for that, don't change your build conf).
Certainly this are configuration management issues, that the software engineer shouldn't care, should you?
Thanks in advance


--- El dom, 13/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] libXaw.so.6 again
> Para: m3devel at elegosoft.com
> Fecha: domingo, 13 de mayo, 2012 21:52
> On Sun, May 13, 2012 at 07:06:44PM
> +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I think the packages in deb already do that so.6, so.7
> thing for that 
> > purposes, you don't need to that for yourself, I
> believe.
> 
> Whatever do you mean?  It wants libXaw.so.6, which no
> longer exists and 
> has been replaced by libXaw.so.7.  Whatever "that so.6,
> so.7 thing" is 
> that the packages in deb already do, the modula 2 in the
> debian package 
> I downloaded just now from the Modula 3 website insists that
> my 
> executable needs libXaw.so.6, not the one I have available.
> 
> Maybe if the .deb were recompiled and repackaged from source
> it would 
> find libXaw.so.7, but the one now available does not.
> 
> -- hendrik
> 
> > Likewise, would be nicer if we could just relink a
> single executable 
> > for both kind of systems, both 32-bit and 64-bit, if
> there were 32-bit 
> > INTEGER and ADDRESS and 128-bit LONGINT and LONGADDRESS
> and 128-bit 
> > LONGCARD I think it could make a better precision
> arithmetic or 
> > double-length at less.
> 
> This has nothing to do with the question.
> 
> -- hendrik
> 


From dragisha at m3w.org  Mon May 14 07:32:49 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 14 May 2012 07:32:49 +0200
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120514025218.GA32463@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
Message-ID: <C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>

Source change (relevant m3makefile) is one path.

Another is to ln -s existing libXaw.so.7 to libXaw.so.6

dd

On May 14, 2012, at 4:52 AM, Hendrik Boom wrote:

> On Sun, May 13, 2012 at 07:06:44PM +0100, Daniel Alejandro Benavides D. wrote:
>> Hi all:
>> I think the packages in deb already do that so.6, so.7 thing for that 
>> purposes, you don't need to that for yourself, I believe.
> 
> Whatever do you mean?  It wants libXaw.so.6, which no longer exists and 
> has been replaced by libXaw.so.7.  Whatever "that so.6, so.7 thing" is 
> that the packages in deb already do, the modula 2 in the debian package 
> I downloaded just now from the Modula 3 website insists that my 
> executable needs libXaw.so.6, not the one I have available.
> 
> Maybe if the .deb were recompiled and repackaged from source it would 
> find libXaw.so.7, but the one now available does not.
> 
> -- hendrik
> 
>> Likewise, would be nicer if we could just relink a single executable 
>> for both kind of systems, both 32-bit and 64-bit, if there were 32-bit 
>> INTEGER and ADDRESS and 128-bit LONGINT and LONGADDRESS and 128-bit 
>> LONGCARD I think it could make a better precision arithmetic or 
>> double-length at less.
> 
> This has nothing to do with the question.
> 
> -- hendrik



From mika at async.caltech.edu  Mon May 14 08:51:15 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sun, 13 May 2012 23:51:15 -0700
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org> 
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
Message-ID: <20120514065115.6FD231A205B@async.async.caltech.edu>

=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
...
>Another is to ln -s existing libXaw.so.7 to libXaw.so.6
...

"Not guaranteed to work" but almost always does, right?


From jay.krell at cornell.edu  Mon May 14 09:20:08 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 May 2012 07:20:08 +0000
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120514065115.6FD231A205B@async.async.caltech.edu>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>,
	<20120514025218.GA32463@topoi.pooq.com>,
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>,
	<20120514065115.6FD231A205B@async.async.caltech.edu>
Message-ID: <COL101-W216A71B993859824CC43E5E61A0@phx.gbl>


Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
I find this very surprising, crazy, disappointing, but apparently true.
We must distribute source to achieve the usual expected portability.
 C source at that, to achieve the usual expected buildability.
Or maybe I'm confused.
The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.


 - Jay


> To: dragisha at m3w.org
> Date: Sun, 13 May 2012 23:51:15 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] libXaw.so.6 again
> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/2798e2e1/attachment-0001.html>

From dragisha at m3w.org  Mon May 14 10:04:15 2012
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 14 May 2012 10:04:15 +0200
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120514065115.6FD231A205B@async.async.caltech.edu>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
Message-ID: <1336982655.1500.9.camel@boromir.m3w.org>

Depends on how major are changes from .6 to .7. At my Fedora box package
version is 1.0.8 and library is libXaw.so.7. Looks like it is minor
change (source/package wise) but number was bumped (probably after
XFree86 schism).


As for binary compatibility Jay mentioned... I don't think many Windows
98 programs will work without hickups on Windows 8. YMMV :).

Under Linux minor version number changes are expected to be binary
compatible. Major version number changes indicate API changes or
additions. Package using libXaw.so.6 is probably revised ages ago. Error
you are getting now says, to me, "Time to check source/API changes".

Belief in eternally invariant API anywhere is naive.

On Sun, 2012-05-13 at 23:51 -0700, Mika Nystrom wrote:
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?

As long as API is not changed, link time will show would it work or not.
Execution is ultimate test :).

-- 
Dragi?a Duri? <dragisha at m3w.org>



From dabenavidesd at yahoo.es  Mon May 14 14:24:47 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 May 2012 13:24:47 +0100 (BST)
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
Message-ID: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler, but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
Thanks in advance

?

--- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] libXaw.so.6 again
Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de mayo, 2012 02:20




Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
I find this very surprising, crazy, disappointing, but apparently true.
We must distribute source to achieve the usual expected portability.
?C source at that, to achieve the usual expected buildability.
Or maybe I'm confused.
The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.


?- Jay


> To: dragisha at m3w.org
> Date: Sun, 13 May 2012 23:51:15 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] libXaw.so.6 again
> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/81764fc1/attachment-0001.html>

From microcode at zoho.com  Mon May 14 14:41:02 2012
From: microcode at zoho.com (microcode at zoho.com)
Date: Mon, 14 May 2012 12:41:02 +0000
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
	<1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <575839211-1336999209-cardhu_decombobulator_blackberry.rim.net-1028218551-@b1.c1.bise3.blackberry>

I think this could be solved by static linking mostly, but there could still be problems with libc/glibc as I found out with FPC recently. Surely somebody who knows UNIX/Linux ought to be able to figure a way around this. 

-----Original Message-----
From: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
Date: Mon, 14 May 2012 13:24:47 
To: Mika Nystrom<mika at async.caltech.edu>; <dragisha at m3w.org>; Jay K<jay.krell at cornell.edu>
Cc: m3devel<m3devel at elegosoft.com>
Subject: Re: [M3devel] libXaw.so.6 again

Hi all:
'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler, but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
Thanks in advance

?

--- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] libXaw.so.6 again
Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de mayo, 2012 02:20




Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
I find this very surprising, crazy, disappointing, but apparently true.
We must distribute source to achieve the usual expected portability.
?C source at that, to achieve the usual expected buildability.
Or maybe I'm confused.
The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.


?- Jay


> To: dragisha at m3w.org
> Date: Sun, 13 May 2012 23:51:15 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] libXaw.so.6 again
> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?
 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/2ab44f33/attachment-0001.html>

From dabenavidesd at yahoo.es  Mon May 14 15:37:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 May 2012 14:37:24 +0100 (BST)
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <575839211-1336999209-cardhu_decombobulator_blackberry.rim.net-1028218551-@b1.c1.bise3.blackberry>
Message-ID: <1337002644.8248.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
respect of this:
http://compilers.iecc.com/comparch/article/94-11-053

The quest is to have a machine-independent compiler at the end but I think nobody cares that, and with industry making ever user machine C dependent it just calls for breaking the rules and make an improvement here.
Dec had an industrial compiler optimization system for all languages but I don't know if Modula-3 was ported to that as well, assuming they never used it for years just says how bad the computers evolved in C-ism, as DEC tried to imitate:
http://compilers.iecc.com/comparch/article/92-06-037

I think it didn't achieved it as far as It appears. 
Thanks in advance

--- El lun, 14/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

De: microcode at zoho.com <microcode at zoho.com>
Asunto: Re: [M3devel] libXaw.so.6 again
Para: m3devel at elegosoft.com
Fecha: lunes, 14 de mayo, 2012 07:41

I think this could be solved by static linking mostly, but there could still be problems with libc/glibc as I found out with FPC recently. Surely somebody who knows UNIX/Linux ought to be able to figure a way around this. 
From:  "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
Date: Mon, 14 May 2012 13:24:47 +0100 (BST)To: Mika Nystrom<mika at async.caltech.edu>; <dragisha at m3w.org>; Jay K<jay.krell at cornell.edu>Cc: m3devel<m3devel at elegosoft.com>Subject: Re: [M3devel] libXaw.so.6 again
Hi all:
'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler,
 but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
Thanks in advance

?

--- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] libXaw.so.6 again
Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de mayo, 2012 02:20




Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
I find this very surprising, crazy, disappointing, but apparently true.
We must distribute source to achieve the usual expected portability.
?C source at that, to achieve the usual expected buildability.
Or maybe I'm confused.
The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.


?- Jay


> To: dragisha at m3w.org
> Date: Sun, 13 May 2012 23:51:15 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] libXaw.so.6 again
> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?
 		
 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/f1edbad1/attachment-0001.html>

From hendrik at topoi.pooq.com  Mon May 14 17:44:41 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 14 May 2012 11:44:41 -0400
Subject: [M3devel] libXaw.so.7
In-Reply-To: <COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
	<COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
Message-ID: <20120514154441.GA26098@topoi.pooq.com>

On Mon, May 14, 2012 at 07:20:08AM +0000, Jay K wrote:
> 
> Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
> I find this very surprising, crazy, disappointing, but apparently true.
> We must distribute source to achieve the usual expected portability.
>  C source at that, to achieve the usual expected buildability.
> Or maybe I'm confused.
> The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.

Here's what aptitude has to say about libXaw7:

libXaW7 provides the second versin of XaW, the Athena Widgets toolkit, which is
largely used by legacy X applications.  This version is the most common
version, ass version 6 is considered deprecated, and vesion 8, which adds
Xprint support, is unsupported and not widely used. In geneeral use of a more
modern toolkit such as GTK+ is recommended

Now I'm not going to suggest that we abolish all use of libXaw in favour of 
GTK+.  But whatever other systems it runs on, the deb package for Modula 
3 does not work on any current version of Debian (neither  stable, 
testing, nor sid).  A new .deb needs to be made, if ti is to work 
properly on debian (surely the canonical userr of .deb packages)

I might add that if modula3 were still part of Debian, it should have 
had a dependdency on libXaw6, and that might have sufficed either to 
keep libXaw6 alive as a legacy package in additino to libXaw7, or to 
alert the maintainer that the Modula3 package needed to be updated 
somewhere early in the Debian deployment process -- certainly long 
before the advend of squeeze. 

But getting modula 3 back into Debian is another project, and possibly a 
big one.  Even the current modula 3 debs, though adequate for my 
purposes if updatad, are not nearly adequate for distribution via Debian 
because of matters like the file system standard and the like.

Now I'm guessing the code that is run to create the .deb files is still
around somewhere.  Are there clear instructions how to go about 
finding it and using it to make a debian source package and debian 
binary packages?

-- hendrik



From jay.krell at cornell.edu  Mon May 14 22:00:20 2012
From: jay.krell at cornell.edu (Jay)
Date: Mon, 14 May 2012 13:00:20 -0700
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <2FEF5A4D-F529-4F18-8927-7F99EAC92D4D@gmail.com>

The age of the toolchain is not the problem. And gcc has little/nothing to do with it (unless you worry about C++ exceptionhandling/RTTI ABI) Linux/OpenBSD/FreeBSD/NetBSD seemingly don't try to retain binary compatibility. I don't know if security fixes are too blame but I doubt it.


Shipping assembly source would help -- where the breakage is only the .so name. I want to ship C source.

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 14, 2012, at 5:24 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> 'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
> Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler, but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
> Thanks in advance
> 
>  
> 
> --- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] libXaw.so.6 again
> Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 14 de mayo, 2012 02:20
> 
> Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
> I find this very surprising, crazy, disappointing, but apparently true.
> We must distribute source to achieve the usual expected portability.
>  C source at that, to achieve the usual expected buildability.
> Or maybe I'm confused.
> The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.
> 
> 
>  - Jay
> 
> 
> > To: dragisha at m3w.org
> > Date: Sun, 13 May 2012 23:51:15 -0700
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] libXaw.so.6 again
> > 
> > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> > ...
> > >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> > ...
> > 
> > "Not guaranteed to work" but almost always does, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/00c540b1/attachment-0001.html>

From hendrik at topoi.pooq.com  Tue May 15 00:09:33 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 14 May 2012 18:09:33 -0400
Subject: [M3devel] Where is libXaw6 even used?
In-Reply-To: <20120514154441.GA26098@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
	<COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
	<20120514154441.GA26098@topoi.pooq.com>
Message-ID: <20120514220933.GA31311@topoi.pooq.com>

On Mon, May 14, 2012 at 11:44:41AM -0400, Hendrik Boom wrote:

I've been grepping through the src directories in the ...src-all-... archive, and the only mentions of Xaw I've found is in the Tetris game, and in a file called m3-comm/sharedobjgen/test/trackerpos/src/PATHTracker, whicch seems to be a  list of interface names and directory paths,
some with '@' signs.

What needs to be changed so it will find libXaw.so.7?  Or if I just need 
to recompile something so that it can fine libXaw.so.7, what do I need 
to recompile?

-- hendrik



From jay.krell at cornell.edu  Tue May 15 00:52:55 2012
From: jay.krell at cornell.edu (Jay)
Date: Mon, 14 May 2012 15:52:55 -0700
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <2FEF5A4D-F529-4F18-8927-7F99EAC92D4D@gmail.com>
References: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<2FEF5A4D-F529-4F18-8927-7F99EAC92D4D@gmail.com>
Message-ID: <6C826E60-81C2-4D63-859A-5BC799F9B80E@gmail.com>

Clarification: shipping assembly source would include, in today's structuring, shipping a little C too. Heck, we could ship .o files and some .c, & that would fix the entire binary compatibility problem for us (assembly or .o). Playing a little fast&loose wrt Xlib.h but probably ok.


My plan to ship C would probably ship strange low level C that doesn't improve things wrt binary compatibility. Unless someone has a scheme in mind for a backend that generates #include sys/types & such?


There is a point to ship C, just not likely relevant to binary compatibility.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 14, 2012, at 1:00 PM, Jay <jay.krell at cornell.edu> wrote:

> The age of the toolchain is not the problem. And gcc has little/nothing to do with it (unless you worry about C++ exceptionhandling/RTTI ABI) Linux/OpenBSD/FreeBSD/NetBSD seemingly don't try to retain binary compatibility. I don't know if security fixes are too blame but I doubt it.
> 
> 
> Shipping assembly source would help -- where the breakage is only the .so name. I want to ship C source.
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On May 14, 2012, at 5:24 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:
> 
>> Hi all:
>> 'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
>> Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler, but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
>> Thanks in advance
>> 
>>  
>> 
>> --- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:
>> 
>> De: Jay K <jay.krell at cornell.edu>
>> Asunto: Re: [M3devel] libXaw.so.6 again
>> Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
>> CC: "m3devel" <m3devel at elegosoft.com>
>> Fecha: lunes, 14 de mayo, 2012 02:20
>> 
>> Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
>> I find this very surprising, crazy, disappointing, but apparently true.
>> We must distribute source to achieve the usual expected portability.
>>  C source at that, to achieve the usual expected buildability.
>> Or maybe I'm confused.
>> The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.
>> 
>> 
>>  - Jay
>> 
>> 
>> > To: dragisha at m3w.org
>> > Date: Sun, 13 May 2012 23:51:15 -0700
>> > From: mika at async.caltech.edu
>> > CC: m3devel at elegosoft.com
>> > Subject: Re: [M3devel] libXaw.so.6 again
>> > 
>> > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
>> > ...
>> > >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
>> > ...
>> > 
>> > "Not guaranteed to work" but almost always does, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/1a8fa988/attachment-0001.html>

From dragisha at m3w.org  Tue May 15 01:58:19 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 15 May 2012 01:58:19 +0200
Subject: [M3devel] Where is libXaw6 even used?
In-Reply-To: <20120514220933.GA31311@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
	<COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
	<20120514154441.GA26098@topoi.pooq.com>
	<20120514220933.GA31311@topoi.pooq.com>
Message-ID: <63183557-3F71-445A-B860-BDEE84A250F3@m3w.org>

Maybe you just need to link libXaw.so.7 on your system to libXaw.so

cm3 handlig of system shared libs? :)

On May 15, 2012, at 12:09 AM, Hendrik Boom wrote:

> On Mon, May 14, 2012 at 11:44:41AM -0400, Hendrik Boom wrote:
> 
> I've been grepping through the src directories in the ...src-all-... archive, and the only mentions of Xaw I've found is in the Tetris game, and in a file called m3-comm/sharedobjgen/test/trackerpos/src/PATHTracker, whicch seems to be a  list of interface names and directory paths,
> some with '@' signs.
> 
> What needs to be changed so it will find libXaw.so.7?  Or if I just need 
> to recompile something so that it can fine libXaw.so.7, what do I need 
> to recompile?
> 
> -- hendrik
> 



From hendrik at topoi.pooq.com  Tue May 15 05:14:37 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 14 May 2012 23:14:37 -0400
Subject: [M3devel] libXaw
In-Reply-To: <63183557-3F71-445A-B860-BDEE84A250F3@m3w.org>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
	<COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
	<20120514154441.GA26098@topoi.pooq.com>
	<20120514220933.GA31311@topoi.pooq.com>
	<63183557-3F71-445A-B860-BDEE84A250F3@m3w.org>
Message-ID: <20120515031437.GA1025@topoi.pooq.com>

On Tue, May 15, 2012 at 01:58:19AM +0200, Dragi?a Duri? wrote:
> Maybe you just need to link libXaw.so.7 on your system to libXaw.so

You mean like this?

hendrik at notlookedfor:/farhome/hendrik/cm3/src-all$ ls /usr/lib/i386-linux-gnu/*Xaw* -l
-rw-r--r-- 1 root root 540512 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw7.a
lrwxrwxrwx 1 root root     16 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw7.so -> libXaw7.so.7.0.0
lrwxrwxrwx 1 root root     16 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw7.so.7 -> libXaw7.so.7.0.0
-rw-r--r-- 1 root root 428900 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw7.so.7.0.0
lrwxrwxrwx 1 root root     10 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw.so -> libXaw7.so
lrwxrwxrwx 1 root root     12 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw.so.7 -> libXaw7.so.7
hendrik at notlookedfor:/farhome/hendrik/cm3/src-all$ 

Already done by the system.  The compiler is quite clear that it wants
libXaw.so.6.

The reference to libXaw has to occur in the code base, no? 

Presumably I have to recompile something that refers to Xaw, 
so it will find these links while building one of the m3 libraries 
(and maybe everything that depends on it)and end up with a dependency 
on libXaw7 in the binary.

But I can't find it.

-- hendrik


From hendrik at topoi.pooq.com  Tue May 15 17:12:18 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Tue, 15 May 2012 11:12:18 -0400
Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
In-Reply-To: <20120513174747.GA25729@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
Message-ID: <20120515151217.GA23964@topoi.pooq.com>

I got it to recognise libXaw.se.7.

I downloaded and untarred the src-all archive.

I used cm3 to compile and ship several libraries:

 m3-ui/formsvbt
 m3-ui/videovbt
 m3-ui/vbtkit
 m3-ui/ui
 m3-ui/X11R4

Each one was simple, like
   cd formsvbt
   cm3
   cm3 -ship

I identified the libraries that needed recompilation fron the 
compilation error messages I got whein compiling the program I was 
originally trying to work on.  A message like:

/usr/bin/ld: warning: libXaw.so.6, needed by /usr/local/cm3/pkg/vbtkit/AMD64_LINUX/libm3vbtkit.so, not found (try using -rpath or -rpath-link)

indicated recompiling  m3-ui/vbtkit (I had to look around in src-all too 
figure out the m3-ui part).

At least these libraries work now.  So my immediate objective is 
accomplished.

But the job is  not done.  This is simply too much to inflict on an 
inexperienced beginner.  He'd pretty well have to desperately want to 
use Modula 3 to go to all this trouble AND have the advice of an 
experienced Modula 3 user (such as me, and I had trouble!) to get this 
far.

The next steps, which I *will* need help with if I am to do them, are:

figure out which other libraries have similar obsolete dependencies.

recompile them

Prepare new distribution archives and a new .deb file, suitably 
annotated as to which Debian release they work with.

The .deb is surely the easiest way for a beginner to install Modula 3 on 
Debian.

Make the .deb spread its contents over the file system, as required for 
it to be accepted into Debian again.  Modula 3 has been absent from 
Debian for far too long.

-- hendrik


From dabenavidesd at yahoo.es  Tue May 15 18:37:08 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 15 May 2012 17:37:08 +0100 (BST)
Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
In-Reply-To: <20120515151217.GA23964@topoi.pooq.com>
Message-ID: <1337099828.15747.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I agree, but wherever they depended on must be configured by hand >= so.7 or around base versions >= so.6, so maybe just create a link command cm3 -relink to use a grater version, sometimes I have seen linker warnings at compile time so kind of show dependencies linker if possible at compile time should help.
Win32 older version m3loader go option help says ' CmdFunc { "go", "", "Relink any new modules, then run", go } }; '
The all program module by module, so this could be better than that, but we must redistribute (to the extent possible) pre-compiled versions of major or minor sub-versions. Besides work in the experimental version for UNIX.
Thanks in advance 

--- El mar, 15/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] Success with  libXaw.so.7, but more help needed.
> Para: m3devel at elegosoft.com
> Fecha: martes, 15 de mayo, 2012 10:12
> I got it to recognise libXaw.se.7.
> 
> I downloaded and untarred the src-all archive.
> 
> I used cm3 to compile and ship several libraries:
> 
>  m3-ui/formsvbt
>  m3-ui/videovbt
>  m3-ui/vbtkit
>  m3-ui/ui
>  m3-ui/X11R4
> 
> Each one was simple, like
>    cd formsvbt
>    cm3
>    cm3 -ship
> 
> I identified the libraries that needed recompilation fron
> the 
> compilation error messages I got whein compiling the program
> I was 
> originally trying to work on.  A message like:
> 
> /usr/bin/ld: warning: libXaw.so.6, needed by
> /usr/local/cm3/pkg/vbtkit/AMD64_LINUX/libm3vbtkit.so, not
> found (try using -rpath or -rpath-link)
> 
> indicated recompiling  m3-ui/vbtkit (I had to look
> around in src-all too 
> figure out the m3-ui part).
> 
> At least these libraries work now.  So my immediate
> objective is 
> accomplished.
> 
> But the job is  not done.  This is simply too much
> to inflict on an 
> inexperienced beginner.  He'd pretty well have to
> desperately want to 
> use Modula 3 to go to all this trouble AND have the advice
> of an 
> experienced Modula 3 user (such as me, and I had trouble!)
> to get this 
> far.
> 
> The next steps, which I *will* need help with if I am to do
> them, are:
> 
> figure out which other libraries have similar obsolete
> dependencies.
> 
> recompile them
> 
> Prepare new distribution archives and a new .deb file,
> suitably 
> annotated as to which Debian release they work with.
> 
> The .deb is surely the easiest way for a beginner to install
> Modula 3 on 
> Debian.
> 
> Make the .deb spread its contents over the file system, as
> required for 
> it to be accepted into Debian again.  Modula 3 has been
> absent from 
> Debian for far too long.
> 
> -- hendrik
> 


From jay.krell at cornell.edu  Wed May 16 00:33:12 2012
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 15 May 2012 22:33:12 +0000
Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
In-Reply-To: <20120515151217.GA23964@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>
Message-ID: <COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>


You might as well just use something in scripts to rebuild the entire system.It isn't so difficult nor takes very long.     Get a working cm3 on any system.      cd scripts/python      ./boot1.py <target-such-as-I386_LINUX>      That will produce a "bootstrap" archive.    Copy it to the "new" system.      Extract it.      Cd into it.      Look at the top of Makefile and see if it seems reasonable (we should use autoconf here).    run make.     That should give you a working cm3 for the new system.      Put that on path, e.g.:       su        rm -rf /usr/local/cm3       mkdir -p /usr/local/cm3/bin        cp cm3 /usr/local/cm3/bin        exit         PATH=/usr/local/cm3/bin:$PATH     cd to scripts/python in the source tree on the new system.    Then run ./boot2.sh       Then ./make-dist.py.    That should give you the entire system newly built, and a .deb.  If you already have a working cm3 on the system you want to run it on  cd scripts/python   ./upgrade.py    ./make-dist.py     I'd really like to get to the point of:  extract    ./configure    make    make install  or make deb   To make this work how people really want, we have to have a C-generating backend.Or else provide binary packages for "every" system, which isn't viable.   If Linux distributions took binary compatibility seriously, we wouldn't have this problem.They seem to encourage/require rebuilds for every revision.But surely this is not true, as there exist some closed source products like Adobe Acrobat?There is no such problem on Windows, nor I suspect Solaris, nor hypothetically on Irix, AIX, VMS, HP-UX, Tru64, etc.   - Jay
> Date: Tue, 15 May 2012 11:12:18 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
> 
> I got it to recognise libXaw.se.7.
> 
> I downloaded and untarred the src-all archive.
> 
> I used cm3 to compile and ship several libraries:
> 
>  m3-ui/formsvbt
>  m3-ui/videovbt
>  m3-ui/vbtkit
>  m3-ui/ui
>  m3-ui/X11R4
> 
> Each one was simple, like
>    cd formsvbt
>    cm3
>    cm3 -ship
> 
> I identified the libraries that needed recompilation fron the 
> compilation error messages I got whein compiling the program I was 
> originally trying to work on.  A message like:
> 
> /usr/bin/ld: warning: libXaw.so.6, needed by /usr/local/cm3/pkg/vbtkit/AMD64_LINUX/libm3vbtkit.so, not found (try using -rpath or -rpath-link)
> 
> indicated recompiling  m3-ui/vbtkit (I had to look around in src-all too 
> figure out the m3-ui part).
> 
> At least these libraries work now.  So my immediate objective is 
> accomplished.
> 
> But the job is  not done.  This is simply too much to inflict on an 
> inexperienced beginner.  He'd pretty well have to desperately want to 
> use Modula 3 to go to all this trouble AND have the advice of an 
> experienced Modula 3 user (such as me, and I had trouble!) to get this 
> far.
> 
> The next steps, which I *will* need help with if I am to do them, are:
> 
> figure out which other libraries have similar obsolete dependencies.
> 
> recompile them
> 
> Prepare new distribution archives and a new .deb file, suitably 
> annotated as to which Debian release they work with.
> 
> The .deb is surely the easiest way for a beginner to install Modula 3 on 
> Debian.
> 
> Make the .deb spread its contents over the file system, as required for 
> it to be accepted into Debian again.  Modula 3 has been absent from 
> Debian for far too long.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120515/872c95c3/attachment-0001.html>

From hendrik at topoi.pooq.com  Wed May 16 16:56:53 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 10:56:53 -0400
Subject: [M3devel] Building packages
In-Reply-To: <COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
Message-ID: <20120516145653.GA19959@topoi.pooq.com>

On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote, and hendrik reformatted:
> 
> You might as well just use something in scripts to rebuild the entire 
> system.It isn't so difficult nor takes very long.
>
> Get a working cm3 on any system.
>      cd scripts/python
>      ./boot1.py <target-such-as-I386_LINUX>

So any cm3 system is capable of creating a bootstrap archive for any other cm3 system

> That will produce a "bootstrap" archive.  Copy it to the "new" system.
> Extract it.
> Cd into it.
> Look at the top of Makefile and see if it seems reasonable (we 
> should use autoconf here).
> run make.
> That should give you a working cm3 for the new system.

just the compiler (and what it needs to work), presumably.

> Put that on path, e.g.:
>      su
>      rm -rf /usr/local/cm3

clearing out any old cm3 system completely

>      mkdir -p /usr/local/cm3/bin
>      cp cm3 /usr/local/cm3/bin

And putting the noew one where it can be executed.

>      exit
>      PATH=/usr/local/cm3/bin:$PATH

And this then builds everything, and makes a .deb

> cd to scripts/python in the source tree on the new system.
> Then run ./boot2.sh
> Then ./make-dist.py.
> That should give you the entire system newly built, and a .deb.

I recal there are a few place in the Modula 3 build p[rocess where it 
requires other resources to already exit (the data base stuff is one I 
recall).  If they are not available, will the process fail, or will if 
just build an incomplete .deb?

>
>  If you already have a working cm3 on the system you want to run it on

Which is what I've got on my two machines, so this is what I'll be 
trying.

>     cd scripts/python
>     ./upgrade.py

this script recompiles everything from the complete source tree?  Does 
it ship it?  Or place it somewhere else on the system?  Is it important 
for the already working cm3 compiler to be the same version as the one 
in the source tree being packaged?  And is there also a source package 
built?  Because the source package is what's needed for uploading to 
Debian.

>     ./make-dist.py

And this packages it from the shipped location?

> I'd really like to get to the point of:
>  extract
>    ./configure
>    make
>    make install  or make deb
>
> To make this work how people really want, we have to have a 
> C-generating backend.Or else provide binary packages for "every" 
> system, which isn't viable.  If Linux distributions took binary 
> compatibility seriously, we wouldn't have this problem.

That is. apparently, deliberate policy.  Linux aims for source-code 
compatibility.

Even the kernel calls aren't really guaranteed to stay the same, but 
there's a run-time library that's supposed to be used to call them.  And 
that's Unix policy, from way back in the 70's.

Binary-based distributions routinely compile the entire Linux system 
for each major release.  They do it package by package, but they do it.

I wonder how gcc does its bootstrap.  Presumably it's a package thet 
build-depends on itself, or something like that.

> They seem to 
> encourage/require rebuilds for every revision.But surely this is not 
> true, as there exist some closed source products like Adobe 
> Acrobat?

Such products try to have very few library dependencies.

> There is no such problem on Windows, nor I suspect Solaris, 
> nor hypothetically on Irix, AIX, VMS, HP-UX, Tru64, etc.

And that's been one of the major problems Microsoft has had with 
developing Windows.  When things need to change, you get legacy 
compatibility hacks like making the details of the storage 
allocation system calls depend on the name of the application 
being executed.

It also enables and encourages third-party developers to distribute 
application in binary only, making source code inavailable.  And that in 
turn makes it necessary to remain long-term compatible with ancient 
bugs.

-- hendrik


From hendrik at topoi.pooq.com  Wed May 16 17:26:35 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 11:26:35 -0400
Subject: [M3devel] Building packages
In-Reply-To: <20120516145653.GA19959@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
Message-ID: <20120516152635.GA20806@topoi.pooq.com>

On Wed, May 16, 2012 at 10:56:53AM -0400, Hendrik Boom wrote:
> On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote, and hendrik reformatted:

So this is what I did:
> 
> >
> >  If you already have a working cm3 on the system you want to run it on
> 
> Which is what I've got on my two machines, so this is what I'll be 
> trying.
> 
> >     cd scripts/python
> >     ./upgrade.py

It ran for a while, conpiling some Modula 3 stuff and apparently a lot 
of C code (this part seemed to use autoconf tools), and then stopped 
with

cd . && cd libcpp && make  CFLAGS="-g -O2"   MAKE=make  AUTOCONF=: 
AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a 
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
/bin/sh: line 0: cd: libcpp: No such file or directory
"/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile", line 312: 
quake runtime error: exit 1: cd . && cd libcpp && make  CFLAGS="-g -O2"   
MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: 
libcpp.a | tee -a 
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log

--procedure--  -line-  -file---
exec               --  <builtin>
m3cc_Run          312  
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
include_dir       586  
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
                    8  
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/m3make.args

Fatal Error: package build failed
 *** execution of [<function _BuildGlobalFunction at 0x7f298eea9050>, 
<function _ShipFunction at 0x7f298eea90c8>] failed ***
hendrik at april:~/cm3/src-all/scripts/python$ 


Did I start upgrade.py with an incomplete cm3 system?  Plainly I should 
have started it using script so I'd have a complete log.

-- hendrik


From hendrik at topoi.pooq.com  Wed May 16 18:59:27 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 12:59:27 -0400
Subject: [M3devel] problem building packages -- preliminary analysis.
In-Reply-To: <20120516152635.GA20806@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
Message-ID: <20120516165926.GA3955@topoi.pooq.com>

On Wed, May 16, 2012 at 11:26:35AM -0400, Hendrik Boom wrote:
> On Wed, May 16, 2012 at 10:56:53AM -0400, Hendrik Boom wrote:
> > On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote, and hendrik reformatted:
> 
> So this is what I did:
> > 
> > >
> > >  If you already have a working cm3 on the system you want to run it on
> > 
> > Which is what I've got on my two machines, so this is what I'll be 
> > trying.
> > 
> > >     cd scripts/python
> > >     ./upgrade.py
> 
> It ran for a while, conpiling some Modula 3 stuff and apparently a lot 
> of C code (this part seemed to use autoconf tools), and then stopped 
> with
> 
> cd . && cd libcpp && make  CFLAGS="-g -O2"   MAKE=make  AUTOCONF=: 
> AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a 
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
> /bin/sh: line 0: cd: libcpp: No such file or directory
> "/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile", line 312: 
> quake runtime error: exit 1: cd . && cd libcpp && make  CFLAGS="-g -O2"   
> MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: 
> libcpp.a | tee -a 
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
> 
> --procedure--  -line-  -file---
> exec               --  <builtin>
> m3cc_Run          312  
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
> include_dir       586  
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
>                     8  
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/m3make.args
> 
> Fatal Error: package build failed
>  *** execution of [<function _BuildGlobalFunction at 0x7f298eea9050>, 
> <function _ShipFunction at 0x7f298eea90c8>] failed ***
> hendrik at april:~/cm3/src-all/scripts/python$ 

Looking at the python code in src-all/m3-sys/m3cc/src/m3makefile, I 
find line 586:

m3cc_Run (["cd " & build_dir & " && cd libcpp && " & M3CC_MAKE & " 
libcpp.a | tee -a " & Log])

Now seeng what appears to be the actual command line in the error 
message: 

cd . && cd libcpp && make  CFLAGS="-g -O2" MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a

it appears that the variable bild_dir has the value "."

At some time, "." probably was the build directory.  But at the moment 
we execute this command, I suspect the build dir is actually 
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/

since a recent message was 

make[1]: Leaving directory 
`/farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/libdecnumber'

There is no libcpp directory there.  locate tells me there are libcpp 
directories at
src-all/m3-sys/m3cc/gcc-apple/libcpp

and

src-all/m3-sys/m3cc/gcc/libcpp

and that's about it.  (yes, I reran locatedb to make sure it was up to 
date).

Could it be that the build_dir variable should contain an absolute 
rather than a relative path?

Or should I rerun everything using scipt to generate a huge log?

-- hendrik


From jay.krell at cornell.edu  Wed May 16 22:24:52 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 20:24:52 +0000
Subject: [M3devel] problem building packages -- preliminary analysis.
In-Reply-To: <20120516165926.GA3955@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>
Message-ID: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>


Your CVS tree is maybe incomplete or out of date? Try this:
   cd m3-sys   
   rm -rf m3cc  
   cvs -z3 upd -dAP m3cc   
   cd m3cc   
   cm3  
 

Or just checkout a whole new tree.


Yes, there is a lot of C code, that uses autoconf -- the gcc backend.


 - Jay

> Date: Wed, 16 May 2012 12:59:27 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] problem building packages -- preliminary analysis.
> 
> On Wed, May 16, 2012 at 11:26:35AM -0400, Hendrik Boom wrote:
> > On Wed, May 16, 2012 at 10:56:53AM -0400, Hendrik Boom wrote:
> > > On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote, and hendrik reformatted:
> > 
> > So this is what I did:
> > > 
> > > >
> > > >  If you already have a working cm3 on the system you want to run it on
> > > 
> > > Which is what I've got on my two machines, so this is what I'll be 
> > > trying.
> > > 
> > > >     cd scripts/python
> > > >     ./upgrade.py
> > 
> > It ran for a while, conpiling some Modula 3 stuff and apparently a lot 
> > of C code (this part seemed to use autoconf tools), and then stopped 
> > with
> > 
> > cd . && cd libcpp && make  CFLAGS="-g -O2"   MAKE=make  AUTOCONF=: 
> > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a 
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
> > /bin/sh: line 0: cd: libcpp: No such file or directory
> > "/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile", line 312: 
> > quake runtime error: exit 1: cd . && cd libcpp && make  CFLAGS="-g -O2"   
> > MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: 
> > libcpp.a | tee -a 
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
> > 
> > --procedure--  -line-  -file---
> > exec               --  <builtin>
> > m3cc_Run          312  
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
> > include_dir       586  
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
> >                     8  
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/m3make.args
> > 
> > Fatal Error: package build failed
> >  *** execution of [<function _BuildGlobalFunction at 0x7f298eea9050>, 
> > <function _ShipFunction at 0x7f298eea90c8>] failed ***
> > hendrik at april:~/cm3/src-all/scripts/python$ 
> 
> Looking at the python code in src-all/m3-sys/m3cc/src/m3makefile, I 
> find line 586:
> 
> m3cc_Run (["cd " & build_dir & " && cd libcpp && " & M3CC_MAKE & " 
> libcpp.a | tee -a " & Log])
> 
> Now seeng what appears to be the actual command line in the error 
> message: 
> 
> cd . && cd libcpp && make  CFLAGS="-g -O2" MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a
> 
> it appears that the variable bild_dir has the value "."
> 
> At some time, "." probably was the build directory.  But at the moment 
> we execute this command, I suspect the build dir is actually 
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/
> 
> since a recent message was 
> 
> make[1]: Leaving directory 
> `/farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/libdecnumber'
> 
> There is no libcpp directory there.  locate tells me there are libcpp 
> directories at
> src-all/m3-sys/m3cc/gcc-apple/libcpp
> 
> and
> 
> src-all/m3-sys/m3cc/gcc/libcpp
> 
> and that's about it.  (yes, I reran locatedb to make sure it was up to 
> date).
> 
> Could it be that the build_dir variable should contain an absolute 
> rather than a relative path?
> 
> Or should I rerun everything using scipt to generate a huge log?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/7dd134ed/attachment-0001.html>

From jay.krell at cornell.edu  Wed May 16 22:40:51 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 20:40:51 +0000
Subject: [M3devel] Building packages
In-Reply-To: <20120516145653.GA19959@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>
Message-ID: <COL101-W2557FFC4969C25FB708C06E6180@phx.gbl>


[inline, maybe to myself in places out of ambiguity]


> So any cm3 system is capable of creating a bootstrap archive for any other cm3 system


 Yes. Except you need Cygwin on NT to cross to non-NT.


> > That should give you a working cm3 for the new system.
> 
> just the compiler (and what it needs to work), presumably.


Yes. But not the backend. Ok.
That gets built later on the target system.

 
  > >      rm -rf /usr/local/cm3 
  >  
  > clearing out any old cm3 system completely 


 Correct. Or pick another location. 


> >      mkdir -p /usr/local/cm3/bin
> >      cp cm3 /usr/local/cm3/bin
> 
> And putting the noew one where it can be executed.


Correct. Or pick another location.


> >      exit
> >      PATH=/usr/local/cm3/bin:$PATH
> 
> And this then builds everything, and makes a .deb
> 
> > cd to scripts/python in the source tree on the new system.
> > Then run ./boot2.sh
> > Then ./make-dist.py.
> > That should give you the entire system newly built, and a .deb.
> 
> I recal there are a few place in the Modula 3 build p[rocess where it 
> requires other resources to already exit (the data base stuff is one I 
> recall).  If they are not available, will the process fail, or will if 
> just build an incomplete .deb?



Good point. In the scripts directory, you can always safely remove PKGSDB
and it will be recreated. It goes out of date occasionally. I've been meaning
to make that automatic by putting a version and/or date in it or such.


> >
> >  If you already have a working cm3 on the system you want to run it on
> 
> Which is what I've got on my two machines, so this is what I'll be 
> trying.
> 
> >     cd scripts/python
> >     ./upgrade.py
> 
> this script recompiles everything from the complete source tree?


I think so. It might only build the compiler.
There is ./do-cm3-all.py if unsure.


> Does it ship it?


Yes

.
 >  Is it important  for the already working cm3 compiler to be the same version as the one 
 > in the source tree being packaged?


 Definitely not. This is how we upgrade from old to new. Or possibly new to told.


 >  And is there also a source package built?


 No. It would be C code anyway, so not source from most people's point of view.

 
> Because the source package is what's needed for uploading to 
> Debian.


They wouldn't like it anyway.
 What do they do with stuff written in Haskell, C#, etc.?


> 
> >     ./make-dist.py
> 
> And this packages it from the shipped location?


I think it builds it from scratch. Read it?


> That is. apparently, deliberate policy.  Linux aims for source-code 
> compatibility.


Very lame.


> I wonder how gcc does its bootstrap.


Right, relevant question.


> Such products try to have very few library dependencies.


As do we..but we do have optional GUI..


> And that's been one of the major problems Microsoft has had with 


It is not that difficult and it is worth it.
The Linux/BSD folks break things seemingly gratuitously.


> compatibility hacks like making the details of the storage 
> allocation system calls depend on the name of the application 
> being executed.


It doesn't work quite that way.
There is an appcompat database that checks things like name and version and yes changes the heap allocator.
Just recompiling the relevant buggy third party code wouldn't make it work either.
There is code out there that uses freed memory or uses memory past the allocation or double frees (same as using freed memory)
Heap implementations are always necessarily at least somewhat lenient, and then once you
are lenient a certain amount or in a certain way, you are stuck.


This isn't source compatibility. It is overly precise behavioral compatibility the likes of which very few
programmers would advocate, but which is necessary in a system with so many applications.


There are security aspects too, like if the stack should be executable.
Again though, this is precise behavior compatibility. Just recompiling the code wouldn't fix it.


> It also enables and encourages third-party developers to distribute 
> application in binary only, making source code inavailable.  And that in 
> turn makes it necessary to remain long-term compatible with ancient 
> bugs.


The bugs are in the third party code and you'd have to change a lot of third party source
to keep it working..


The trade off is a more active (at least historically) third party software market.


Anyway, please try out the various scripts until you get it working.
Then we can document it and make it better.
Perhaps the goal should ship only bootstrap packages for the next release?
Make everyone here experience them and approve them?
Autoconf-ize them a bit?
Or verify they work well enough and worry about it if they ever stop working?
(Autoconf is sometimes overkill.)



It'd be nice if the assembly code wasn't e.g. Linux-specific but only x86-specific.
We could maybe blow up the jmpbuf size per-architectures instead of per architecture+kernel?
Maybe.




 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/6eb0b9b9/attachment-0001.html>

From jay.krell at cornell.edu  Wed May 16 22:55:20 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 20:55:20 +0000
Subject: [M3devel] distribution format?
Message-ID: <COL101-W2222C4AA8CB67F3F46D9E2E6180@phx.gbl>


What distribution format or formats should we aim for?


One thing to consider, in our various preferences for a source/assembly distribution,
is that there is the large gcc backend.


How many people, even if they build stuff from source, build gcc?
How many of those attempts are deemed onerously slow? Or fail and onerous to debug? etc.
And people give up?
Consider that OpenBSD discourages its users from building from source.
Instead they provide binary packages for "everything".


Yes yes a C-generating backend would fix that and merely require the user have gcc or such.
Is the middle step worthwhile?


Is a gcc plugin viable at this point?
I'm not too interested in that really.


Maybe the answer is to "get into" the distributions, into the package systems.
Put rebuild work on the distributions?
They do handle gcc already, somehow, e.g. via a cross into a new/empty file system, presumably.
Can anyone else research that?


Thank you,
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/b220efce/attachment-0001.html>

From hendrik at topoi.pooq.com  Wed May 16 23:07:06 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 17:07:06 -0400
Subject: [M3devel] Package dependencies.
In-Reply-To: <COL101-W2557FFC4969C25FB708C06E6180@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<COL101-W2557FFC4969C25FB708C06E6180@phx.gbl>
Message-ID: <20120516210706.GA8654@topoi.pooq.com>

On Wed, May 16, 2012 at 08:40:51PM +0000, Jay K wrote:
> 
>  >  And is there also a source package built?
> 
> 
>  No. It would be C code anyway, so not source from most 
> people's point of view.
> 
>  
> > Because the source package is what's needed for uploading to 
> > Debian.
> 
> 
> They wouldn't like it anyway.
>  What do they do with stuff written in Haskell, C#, etc.?
> 

They'd be happy with it provided they have Haskel, C#, etc. 
implementations already in the system.  A Debian package 
can have build-dependencies, which is other packages that 
have to be installed to builld it.  I don't know how this works 
with bootstrapping self-hosting languages.  Maybe it takes 
ad-hockery.  Maybe a new release build-depends on the 
previous one.  Or on anything aat least as up-to-date as 
the previous one.

-- hendrik



From hendrik at topoi.pooq.com  Wed May 16 23:15:26 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 17:15:26 -0400
Subject: [M3devel] building packages
In-Reply-To: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
Message-ID: <20120516211526.GB8654@topoi.pooq.com>

On Wed, May 16, 2012 at 08:24:52PM +0000, Jay K wrote:
> 
> Your CVS tree is maybe incomplete or out of date? Try this:
>    cd m3-sys   
>    rm -rf m3cc  
>    cvs -z3 upd -dAP m3cc   
>    cd m3cc   
>    cm3  

I wsn't using the CVS tree.  I was using 
cm3-src-all-5.8.6-REL.tgz, downloaded from 
http://modula3.elegosoft.com/cm3/releng/download.html.

Maybe your instructions apply only to a still-newer source 
tree.

>  
> 
> Or just checkout a whole new tree.

That's what I'll do.  Is the current head in good 
enough shape?

> 
> 
> Yes, there is a lot of C code, that uses autoconf -- the gcc backend.

So you compile the gcc backend.  Presumably cross-compile 
it if necessary.  Does gcc on one platform also produce 
object code for another?  Or does the script custom-pick 
the backend depending on the target platform?

-- hendrik

> 
> 
>  - Jay
> 


From hendrik at topoi.pooq.com  Wed May 16 23:28:59 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 17:28:59 -0400
Subject: [M3devel] distribution format?
In-Reply-To: <COL101-W2222C4AA8CB67F3F46D9E2E6180@phx.gbl>
References: <COL101-W2222C4AA8CB67F3F46D9E2E6180@phx.gbl>
Message-ID: <20120516212859.GD8654@topoi.pooq.com>

On Wed, May 16, 2012 at 08:55:20PM +0000, Jay K wrote:
> 
> What distribution format or formats should we aim for?
> 
> 
> One thing to consider, in our various preferences for a source/assembly distribution,
> is that there is the large gcc backend.
> 
> 
> How many people, even if they build stuff from source, build gcc?
> How many of those attempts are deemed onerously slow? Or fail and onerous to debug? etc.
> And people give up?
> Consider that OpenBSD discourages its users from building from source.
> Instead they provide binary packages for "everything".
> 
> 
> Yes yes a C-generating backend would fix that and merely require the user have gcc or such.
> Is the middle step worthwhile?
> 
> 
> Is a gcc plugin viable at this point?
> I'm not too interested in that really.
> 
> 
> Maybe the answer is to "get into" the distributions, into the package systems.
> Put rebuild work on the distributions?
> They do handle gcc already, somehow, e.g. via a cross into a new/empty file system, presumably.
> Can anyone else research that?

gentoo has a minimal binary distribution and they use that 
to build everything else, possibly including a newer gcc.  
But then gentoo is for the fanatics that want to build 
everything themselves from source code.

I've recently read through the Debian packaging tutorial, 
enough to make my eyes glaze over.  I'll have another look 
to see if I manage to understand anything relevant.

-- hendrik

> 
> Thank you,
>  - Jay

You're welcome!

-- hendrik


From hendrik at topoi.pooq.com  Thu May 17 00:31:23 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 18:31:23 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
Message-ID: <20120516223123.GA25611@topoi.pooq.com>

On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote:
> 
> You might as well just use something in scripts to rebuild the entire system.It isn't so difficult nor takes very long.     Get a working cm3 on any system.
      cd scripts/python
      ./boot1.py <target-such-as-I386_LINUX>

Is I386_LINUX no longer called LINUXLIBC6?

-- hendrik


From jay.krell at cornell.edu  Thu May 17 01:40:53 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 23:40:53 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <20120516223123.GA25611@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516223123.GA25611@topoi.pooq.com>
Message-ID: <COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>


 LINUXLIBC6 is supported, but I'd really like to drop it.  The following are supported and work: 
   I386_NT    I386_CYGWIN    I386_NETBSD    I386_FREEBSD    I386_LINUX    SPARC32_SOLARIS ?   The following I'd like to get rid of, but they are pretty cheap to carry along:   NetBSDi386 or somesuch     FreeBSD4      LINUXLIBC6       SOLgnu      SOLsun     You can cross build from any to any, and then leave the old stuff behind...     But heck, really, if we generate C, then targets largely drop away.    Not entirely, not without other changes.     cm3 knows very very little about any targets, mainly their word size, endianness, and jmpbuf size.     jmpbuf size is high on my list to remove. I had it almost fixed, but not quite right.     Target dependencies are mostly in other places:     1) quake code        2) #ifdef C       3) the gcc backend       The quake code and #ifdefed C can largely be merged into just #ifdefed C, and thatlargely goes away if/when we have preemptive suspend.Ok ok, that's only for garbage collection. File I/O and GUI are still forked Win32 vs. Posix,and always will be in Trestle. Maybe we'll layer over Qt or such someday...  In the present structuring there is also some need/want for "user threads" targets:  I386_LINUX    I386_LINUX_USERTHREADS    but I'd rather make that a compile/link/runtime option instead.Currently anyone needing/wanting userthreads gets to recompile the world.   - Jay
 > Date: Wed, 16 May 2012 18:31:23 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] LINUXLIBC6
> 
> On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote:
> > 
> > You might as well just use something in scripts to rebuild the entire system.It isn't so difficult nor takes very long.     Get a working cm3 on any system.
>       cd scripts/python
>       ./boot1.py <target-such-as-I386_LINUX>
> 
> Is I386_LINUX no longer called LINUXLIBC6?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/10efe6f3/attachment-0001.html>

From hendrik at topoi.pooq.com  Thu May 17 01:55:49 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 19:55:49 -0400
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <20120516211526.GB8654@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
Message-ID: <20120516235549.GB3955@topoi.pooq.com>

On Wed, May 16, 2012 at 05:15:26PM -0400, Hendrik Boom wrote:
> On Wed, May 16, 2012 at 08:24:52PM +0000, Jay K wrote:
> > 
> > Your CVS tree is maybe incomplete or out of date? Try this:
> >    cd m3-sys   
> >    rm -rf m3cc  
> >    cvs -z3 upd -dAP m3cc   
> >    cd m3cc   
> >    cm3  
> 
> I wsn't using the CVS tree.  I was using 
> cm3-src-all-5.8.6-REL.tgz, downloaded from 
> http://modula3.elegosoft.com/cm3/releng/download.html.
> 
> Maybe your instructions apply only to a still-newer source 
> tree.
> 
> >  
> > 
> > Or just checkout a whole new tree.
> 
> That's what I'll do.  Is the current head in good 
> enough shape?

Just checked out a whole new source tree.

cd scripts/python
./upgrade.py

and got 1504 lines of messages (yes, I saved them this time) ending with:

configure: creating ./config.status
config.status: creating Makefile
cd . && make  MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: c
onfigure-host
cd . && make  MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host
mkdir -p -- ./gcc
Configuring in ./gcc
configure: creating cache ./config.cache
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking LIBRARY_PATH variable... contains current directory
configure: error: 
*** LIBRARY_PATH shouldn't contain the current directory when
*** building gcc. Please change the environment variable
*** and run configure again.
make: *** [configure-gcc] Error 1
"/farhome/hendrik/cm3/cm3/m3-sys/m3cc/src/m3makefile", line 281: quake runtime error: exit 2: cd . && make  MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host

--procedure--  -line-  -file---
exec               --  <builtin>
m3cc_Run          281  /farhome/hendrik/cm3/cm3/m3-sys/m3cc/src/m3makefile
include_dir       475  /farhome/hendrik/cm3/cm3/m3-sys/m3cc/src/m3makefile
                    5  /farhome/hendrik/cm3/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args

Fatal Error: package build failed
 *** execution of [<function _BuildGlobalFunction at 0x7f70063d6848>, <function _ShipFunction at 0x7f70063d68c0>] failed ***
hendrik at april:~/cm3/cm3/scripts/python$ 


I'm not out of the woods yet.

By the way, the LIBRARY_PATH in the shell from which I ran upgrade.py
was 

hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH
:/usr/local/Gambit-C/lib
hendrik at april:~/cm3/cm3/scripts/python$ 

and seems to have nothing to do with anything, 
so I'll have to investigate further.

-- hendrik


From jay.krell at cornell.edu  Thu May 17 01:58:15 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 23:58:15 +0000
Subject: [M3devel] building packages
In-Reply-To: <20120516211526.GB8654@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>
Message-ID: <COL101-W3674E59BA09B552B45BAE4E6180@phx.gbl>


  > From: hendrik at topoi.pooq.com     > I wasn't using the CVS tree. I was using   
  > cm3-src-all-5.8.6-REL.tgz, downloaded from   
  
 cm3-src-all-5.8.6-REL.tgz really ought to work.     
 But I don't know.    
 I can try later.   
 
  
  
  > That's what I'll do. Is the current head in good   
  > enough shape?     I think so, but please try it, and we'll see.    
  I've actively using it lately (working on moving to gcc 4.6, making good progress)      
 
  > So you compile the gcc backend. Presumably cross-compile   
  > it if necessary. Does gcc on one platform also produce   
  > object code for another? Or does the script custom-pick   
  > the backend depending on the target platform?  
It works. Trust me. Try it.   Details:
 
  if you read m3cc/src/m3makefile, you see that "build_dir" is either "." or "../<host>-<target>"      "." is really host or target -- the same thing, for a native build.    cm3 automatically creates and cd's into it, rending it as just ".".     We configure gcc appropriately (--host, --target) and run the cm3cg by full path, as I recall.     We aren't cross-compiling gcc. We are building a cross-compiler.  
  The following is confusing, but makes sense once you get your head around it:  
  There are potentially up to 3 machines: "build", "host", "target".  
  "build" is the machine you are sitting on "now". The one you are building the compiler on.  
  The machine you are building the compiler on.    
  "host" is the machine that the resulting compiler will run on. It will "host" the compiler.    
  "target" is the machine that will run the compiler's output -- that the compiler will "target".       In common practise, all 3 are the same and things are nice and simple.  
    
  But it can be that any two of three are the same or that all three are the same.
    In the context of the Modula-3 build scripts, build and host are always the same.    
  
  When host and target are different, that is a cross compiler.
  When build and host are different, you are cross compiling the compiler.    
  When all three are different, you are cross compiling a cross compiler.  
  When build and target are the same but not equal to host, I don't know a term for that, I call it "cross back" -- you are     building a compiler that will run on a different system but which will produce code for the system you are building it on.  
  
     
  The challenge in various "cross " scenarios is having/getting the headers and libraries (libc) and linker and assembler,   
  and related, building libgcc2.   
  Often-times but not always, the GNU linker/assembler help.    
  Sometimes GNU libc helps.    
  But I for example haven't been able to build an ia64-linux toolset, due to the headers/libraries.  
  
  Building the C frontend/backend (and gcc driver for that matter) for build==host is actually always very easy.  
 
  
  If you program is just:
  int add(int a, int b) { return a + b }        and you have gcc source, it is easy to convert it to assembly for any target,
  without any headers/libraries/linker/assembler. That is all Modula-3 uses gcc for.    
  But throw in an #include <stdio.h> or try to link to anything, and you need a lot more.      In the Modula-3 system, how it was mostly structured at the start, and now, we cheat.  
  "final compilation/assembly/linking" can be deferred to the target system, which is  
  dependend upon to have a working native toolset. That is what my "bootstrap" archives do.
  That is what the "bootstrap" archives of olden times (circa 3.6/1996) did I believe. 
  Also quake was written in C back then.   
  Targeting something like iPhone/iPad doesn't fit...except that C cross tools are available  
  enough, so the same structuring works fine.  
  You typically just have to run different toplevel gcc/ld or add a switch like gcc -arch arm.      We also cheat these days in that where #include <stdio.h> (for C runtime/kernel) was needed, I rewrote the code in C.    This protects us from stdio.h changing or varying per-target. It was a big porting and maintenance and safety problem.    <windows.h> and <Xlib.h> we still clone in Modula-3. They don't change so much. But maybe we should    do something different there too.  
   Make some sense?      - Jay   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/b84cf658/attachment-0001.html>

From jay.krell at cornell.edu  Thu May 17 01:59:51 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 23:59:51 +0000
Subject: [M3devel] distribution format?
In-Reply-To: <20120516212859.GD8654@topoi.pooq.com>
References: <COL101-W2222C4AA8CB67F3F46D9E2E6180@phx.gbl>,
	<20120516212859.GD8654@topoi.pooq.com>
Message-ID: <COL101-W23A02FD30BF2BCE47AEB94E6180@phx.gbl>


Agreed both: I haven't gotten Gentoo to work, despit trying. Debian developer manual is a lot to read.  - Jay
 > Date: Wed, 16 May 2012 17:28:59 -0400
> From: hendrik at topoi.pooq.com
> 
> gentoo has a minimal binary distribution and they use that 
> to build everything else, possibly including a newer gcc.  
> But then gentoo is for the fanatics that want to build 
> everything themselves from source code.
> 
> I've recently read through the Debian packaging tutorial, 
> enough to make my eyes glaze over.  I'll have another look 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/a21e5127/attachment-0001.html>

From jay.krell at cornell.edu  Thu May 17 02:03:23 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 00:03:23 +0000
Subject: [M3devel] Package dependencies.
In-Reply-To: <20120516210706.GA8654@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<COL101-W2557FFC4969C25FB708C06E6180@phx.gbl>,
	<20120516210706.GA8654@topoi.pooq.com>
Message-ID: <COL101-W17DBAC2F81606B73A0A39CE6190@phx.gbl>


 >> I don't know how this works with bootstrapping self-hosting languages    I think you hit the nail on the head -- "bootstrapping self-hosting languages". Good!    Keep using that phrase if you email folks asking about this, and make sure they understand it.         Meanwhile, I still want to generate fairly portable C or C++ to get around the problem. :)        First I'm going to upgrade to gcc 4.6 backend, and then maybe 4.7..stalling... :)         >  What do they do with stuff written in Haskell, C#, etc.?  
   > They'd be happy with it provided they have Haskel, C#, etc.     
 Right: I should have said a C# compiler written in C#, a Haskell compiler written in Haskell, etc.   - Jay
 > Date: Wed, 16 May 2012 17:07:06 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Package dependencies.
> 
> On Wed, May 16, 2012 at 08:40:51PM +0000, Jay K wrote:
> > 
> >  >  And is there also a source package built?
> > 
> > 
> >  No. It would be C code anyway, so not source from most 
> > people's point of view.
> > 
> >  
> > > Because the source package is what's needed for uploading to 
> > > Debian.
> > 
> > 
> > They wouldn't like it anyway.
> >  What do they do with stuff written in Haskell, C#, etc.?
> > 
> 
> They'd be happy with it provided they have Haskel, C#, etc. 
> implementations already in the system.  A Debian package 
> can have build-dependencies, which is other packages that 
> have to be installed to builld it.  I don't know how this works 
> with bootstrapping self-hosting languages.  Maybe it takes 
> ad-hockery.  Maybe a new release build-depends on the 
> previous one.  Or on anything aat least as up-to-date as 
> the previous one.
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/7a8daeed/attachment-0001.html>

From jay.krell at cornell.edu  Thu May 17 02:06:00 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 00:06:00 +0000
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <20120516235549.GB3955@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>
Message-ID: <COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>


     > *** LIBRARY_PATH shouldn't contain the current directory when  
     > *** building gcc. Please change the environment variable  
     > *** and run configure again.  
    hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
  :/usr/local/Gambit-C/lib  
 Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/d863e4e0/attachment-0001.html>

From hendrik at topoi.pooq.com  Thu May 17 02:48:25 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 20:48:25 -0400
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
Message-ID: <20120517004825.GA30435@topoi.pooq.com>

On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> 
>      > *** LIBRARY_PATH shouldn't contain the current directory when  
>      > *** building gcc. Please change the environment variable  
>      > *** and run configure again.  
>     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
>   :/usr/local/Gambit-C/lib  
>  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  

Interesting.  I thought you had to say . to get the current directory, and that the 
empty string meant nothing at all.  Evidently the  standard way of appending something 
to LIBRARY_PATH has a bug in the empty case.  Strings aren't the best way of doing lots 
of things, but they're ubiquitous, are oftern the only thing available, and lead to bugs 
like this.

-- hendrik




From jay.krell at cornell.edu  Thu May 17 02:59:31 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 00:59:31 +0000
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <20120517004825.GA30435@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>,
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>,
	<20120517004825.GA30435@topoi.pooq.com>
Message-ID: <COL101-W28EDF0AAE2AE13133B4948E6190@phx.gbl>


 > From: hendrik at topoi.pooq.com 
 > Strings aren't the best way of doing lots  
 > of things, but they're ubiquitous, are oftern the only thing available, and lead to bugs  
 Definitely.  A classic example is the command line, for various reasons.On Windows for example, the lower layers pass the command line as one flat string.So then it has to be split up to form argv. On spaces. Which have to be quoted if they are in individual elements. But quotes can occur too. Mess. Even on Unix where the kernel accepts an array, it doesn't work well, like if you are passing any "special" characters, at least if there is an intervening /bin/sh. There are length limits, at least on Windows, so compilers/linkers accept their commands in files as well, and long command lines are stuffed into files.  Strongly typed function calls work much better.Over RPC if necessary.  URLs have similar problems.  I see problems caused by this stuff pretty frequently..   - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/a78ddb09/attachment-0001.html>

From hendrik at topoi.pooq.com  Thu May 17 03:49:03 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 21:49:03 -0400
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
Message-ID: <20120517014903.GA19546@topoi.pooq.com>

On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> 
>      > *** LIBRARY_PATH shouldn't contain the current directory when  
>      > *** building gcc. Please change the environment variable  
>      > *** and run configure again.  
>     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
>   :/usr/local/Gambit-C/lib  
>  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  

Yes, emptying LIBRARY_PATH enabled uprade.py to complete successfully.
Thanks.  It would have taken me many ages to figure this out.

-- hendrik



From dabenavidesd at yahoo.es  Thu May 17 03:58:50 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 17 May 2012 02:58:50 +0100 (BST)
Subject: [M3devel] Package dependencies.
In-Reply-To: <COL101-W17DBAC2F81606B73A0A39CE6190@phx.gbl>
Message-ID: <1337219930.11755.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
correct but since 70's anybody could use a CG machine to reproduce the language in any environment and then port it from there to any other machine of similar characteristics.
I think most of M3CG was inspired by Titan RISC DEC chip, but it came first by an effort to emulate the VAX on a RISC and if Modula-3 ever succeeded by running a VAX instruction it doesn't need to be such, so don't raise a concern on the language it was born and so, but in the language it had to be arise in.
That said, Modula-3 or anything is much compact in a RISC machine than in any other CISC-like machine, which is for what C was created in first place as Macro-package then used as a Programming language on its own. Modula-3 was a ready Programming environment for the VAX native back-end for a RISC. This was an? environment in for which you could see the benefits of a good small language enough powerful to run a native system in and so.
Thanks in advance


?

--- El mi?, 16/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Package dependencies.
Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 16 de mayo, 2012 19:03




?>> I don't know how this works with bootstrapping self-hosting languages
?
?
? I think you hit the nail on the?head -- "bootstrapping self-hosting languages". Good!? 
? Keep using that phrase if you email folks asking?about this, and make sure they understand it.? 
?
?
??? ?Meanwhile, I still want to generate fairly portable C or C++ to get around the problem. :)?? 
??? ?First I'm going to upgrade to gcc 4.6 backend, and then maybe 4.7..stalling... :)??? 
?
?
? ?>  What do they do with stuff written in Haskell, C#, etc.?? 
? ?> They'd be happy with it provided they have Haskel, C#, etc.???? 

?
Right: I should have said a C# compiler written in C#, a Haskell compiler written in Haskell, etc.
?
?
?- Jay
?
> Date: Wed, 16 May 2012 17:07:06 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Package dependencies.
> 
> On Wed, May 16, 2012 at 08:40:51PM +0000, Jay K wrote:
> > 
> >  >  And is there also a source package built?
> > 
> > 
> >  No. It would be C code anyway, so not source from most 
> > people's point of view.
> > 
> >  
> > > Because the source package is what's needed for uploading to 
> > > Debian.
> > 
> > 
> > They wouldn't like it anyway.
> >  What do they do with stuff written in Haskell, C#, etc.?
> > 
> 
> They'd be happy with it provided they have Haskel, C#, etc. 
> implementations already in the system.  A Debian package 
> can have build-dependencies, which is other packages that 
> have to be installed to builld it.  I don't know how this works 
> with bootstrapping self-hosting languages.  Maybe it takes 
> ad-hockery.  Maybe a new release build-depends on the 
> previous one.  Or on anything aat least as up-to-date as 
> the previous one.
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/cb176be8/attachment-0001.html>

From hendrik at topoi.pooq.com  Thu May 17 04:35:33 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 22:35:33 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517014903.GA19546@topoi.pooq.com>
References: <20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
Message-ID: <20120517023533.GB19546@topoi.pooq.com>

On Wed, May 16, 2012 at 09:49:03PM -0400, Hendrik Boom wrote:
> On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> > 
> >      > *** LIBRARY_PATH shouldn't contain the current directory when  
> >      > *** building gcc. Please change the environment variable  
> >      > *** and run configure again.  
> >     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
> >   :/usr/local/Gambit-C/lib  
> >  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  
> 
> Yes, emptying LIBRARY_PATH enabled uprade.py to complete successfully.
> Thanks.  It would have taken me many ages to figure this out.
> 
> -- hendrik
> 
Now I'm onto ./make-dist.py

It fails in teh data base stuff.

First becaues it didn't have libodbc.  So I installed package unixodbc.
But then:

== package /farhome/hendrik/cm3/cm3/m3-db/odbc ==

 +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3    -build -DROOT=/farhome/hendrik/cm3/cm3 +++
--- building in AMD64_LINUX ---

ignoring ../src/m3overrides

 ==> /farhome/hendrik/cm3/cm3/m3-db/odbc done

 +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3  -ship -DROOT=/farhome/hendrik/cm3/cm3 +++
--- shipping from AMD64_LINUX ---

. => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
  .M3EXPORTS      
. => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib
  libm3odbc.so.5  "/farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP", line 4: quake runtime error: unable to copy "libm3odbc.so.5" to "/tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib/libm3odbc.so.5": errno=2

--procedure--  -line-  -file---
install_file       --  <builtin>
                    4  /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP

Fatal Error: package build failed
 *** execution of [<function _BuildGlobalFunction at 0x1a56de8>, <function _ShipFunction at 0x1a56c80>] failed ***
hendrik at april:~/cm3/cm3/scripts/python$ 


It doesn't seem to build libm3odbc.so.5

hendrik at april:~/cm3/cm3/m3-db/odbc$ ls AMD64_LINUX/
libm3odbc.a    libm3odbc.so  SQLext.mo  SQLtypes.io
libm3odbc.m3x  SQLext.io     SQL.io
hendrik at april:~/cm3/cm3/m3-db/odbc$ 

There's nothing at all in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
There are lots of files in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib,
but nothing resembling libm3odbc>

-- hendrik




From jay.krell at cornell.edu  Thu May 17 08:01:19 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 06:01:19 +0000
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517023533.GB19546@topoi.pooq.com>
References: <20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>,
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>,
	<20120517014903.GA19546@topoi.pooq.com>,
	<20120517023533.GB19546@topoi.pooq.com>
Message-ID: <COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>


Good.
Wasn't the error message from configure obvious though?


Anyway:
  I think there's a "minor" incrementality bug here.   
  Incremental build isn't picking back up where it left off/failed.  

Try this:
   rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
   rm -rf /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516 
   ./make-dist.py  


OR:  
   rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
   Look at make-dist.py/pylib.py -- get it to point at the same output as before and then just:  
  ./make-dist.py 



That is -- I think every run of make-dist.py is clean to a new temporary timestamp-based location.
This is good and bad.


Note also, I think it is obvious, but I wrote make-dist.py to always package up everything possible
for the target platform. So it is up to you as the "builder" to have all the dependencies already installed.
It isn't great.
I don't believe there is a perfect option here.
Another release form we have yields a bunch of per-target packages.
I find that confusing -- too many.
My form yields just one largeish per-target package.
Over-size, monolithic, but simpler, less choices to confuse people.


Of course ultimately we don't want per-target stuff at all. :)
Or at least we want both "source" and "binary" distributions.


Still I am confused.
Don't people have binary distributions of programs with GUIs for Linux?
Like Komodo IDE, Komodo Edit, Acrobat Reader?


Maybe we should really have a java-generating backend...one binary distribution for all..and a better Android story?
I know, there is a funny tradeoff here. Modula-3 is kind of lower-level than Java.
You'd want such a backend/port to throw out our garbage collector..and heck..all unsafe code....
 (or generate C for those and use JNI or such...interesting..theoretically possible..unlikely to happen..)


 - Jay


> Date: Wed, 16 May 2012 22:35:33 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] building packages from source from cvs -- odbc
> 
> On Wed, May 16, 2012 at 09:49:03PM -0400, Hendrik Boom wrote:
> > On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> > > 
> > >      > *** LIBRARY_PATH shouldn't contain the current directory when  
> > >      > *** building gcc. Please change the environment variable  
> > >      > *** and run configure again.  
> > >     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
> > >   :/usr/local/Gambit-C/lib  
> > >  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  
> > 
> > Yes, emptying LIBRARY_PATH enabled uprade.py to complete successfully.
> > Thanks.  It would have taken me many ages to figure this out.
> > 
> > -- hendrik
> > 
> Now I'm onto ./make-dist.py
> 
> It fails in teh data base stuff.
> 
> First becaues it didn't have libodbc.  So I installed package unixodbc.
> But then:
> 
> == package /farhome/hendrik/cm3/cm3/m3-db/odbc ==
> 
>  +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3    -build -DROOT=/farhome/hendrik/cm3/cm3 +++
> --- building in AMD64_LINUX ---
> 
> ignoring ../src/m3overrides
> 
>  ==> /farhome/hendrik/cm3/cm3/m3-db/odbc done
> 
>  +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3  -ship -DROOT=/farhome/hendrik/cm3/cm3 +++
> --- shipping from AMD64_LINUX ---
> 
> . => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
>   .M3EXPORTS      
> . => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib
>   libm3odbc.so.5  "/farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP", line 4: quake runtime error: unable to copy "libm3odbc.so.5" to "/tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib/libm3odbc.so.5": errno=2
> 
> --procedure--  -line-  -file---
> install_file       --  <builtin>
>                     4  /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP
> 
> Fatal Error: package build failed
>  *** execution of [<function _BuildGlobalFunction at 0x1a56de8>, <function _ShipFunction at 0x1a56c80>] failed ***
> hendrik at april:~/cm3/cm3/scripts/python$ 
> 
> 
> It doesn't seem to build libm3odbc.so.5
> 
> hendrik at april:~/cm3/cm3/m3-db/odbc$ ls AMD64_LINUX/
> libm3odbc.a    libm3odbc.so  SQLext.mo  SQLtypes.io
> libm3odbc.m3x  SQLext.io     SQL.io
> hendrik at april:~/cm3/cm3/m3-db/odbc$ 
> 
> There's nothing at all in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> There are lots of files in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib,
> but nothing resembling libm3odbc>
> 
> -- hendrik
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/e2bd275d/attachment-0001.html>

From jay.krell at cornell.edu  Thu May 17 08:10:40 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 06:10:40 +0000
Subject: [M3devel] C99 FloatMode stuff
Message-ID: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl>


Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/de246aa3/attachment-0001.html>

From hendrik at topoi.pooq.com  Thu May 17 17:48:37 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 17 May 2012 11:48:37 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
References: <20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
Message-ID: <20120517154836.GA20605@topoi.pooq.com>

On Thu, May 17, 2012 at 06:01:19AM +0000, Jay K wrote:
> 
> Good.
> Wasn't the error message from configure obvious though?

Evidently not.  Or I was too much asleep last night.  Or I didn't get 
one. I'm looking for one now.  I find none in my most recent script 
output.  In one of the old ones I find

checking for modern makeinfo... no
configure: WARNING:
*** Makeinfo is missing or too old.
*** Info documentation will not be built.
checking for recent Pod::Man... yes

but I suspect that may be irrelevant.  Unless packageing fails later 
because it tries to package the info docs, which I hate anyway.

No, I don't find any messages.  But then, I'm simply using my old, 
working cm3 compiler as a bootstrap to build the whole system for the 
same machine.  I didn't have a specific 'configure' step.

I found a bunch of compilation warnings about
* labels and other names  being defined but not used.
* comparisons always false due to limited range of data type
* invalid conversion type characters.  Might these actually cause 
run-time failures?
* right-hand operand of comma has no effect

These are unlikely to be the problems I'm contending with, but might 
it be worth going through the entire build sometime and tracking 
then all down?  Grepping my script output for "warning" would 
probably find them all.


> 
> 
> Anyway:
>   I think there's a "minor" incrementality bug here.   
>   Incremental build isn't picking back up where it left off/failed.  
> 
> Try this:
>    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
>    rm -rf /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516 
>    ./make-dist.py  

Will do.  I had planned to do something like this when I was awake this 
morning, but I was unsure just which files needed to be deleted.

> 
> 
> OR:  
>    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
>    Look at make-dist.py/pylib.py -- get it to point at the same output as before and then just:  
>   ./make-dist.py 
> 
> 
> 
> That is -- I think every run of make-dist.py is clean to a new temporary timestamp-based location.
> This is good and bad.
> 
> 
> Note also, I think it is obvious, but I wrote make-dist.py to always package up everything possible
> for the target platform. So it is up to you as the "builder" to have all the dependencies already installed.
> It isn't great.
> I don't believe there is a perfect option here.
> Another release form we have yields a bunch of per-target packages.

This is the way other languages have gone in Debian.  The main reason 
seems to be to reduce the amount of other packages that have to be installed via 
dependencies that the user might not have any interest in.  Essentially 
a distinction between the language, the applications, and the 
libraries.  Something like what Modula3 does with its tgz'ed 
binary "packages".

> I find that confusing -- too many.
> My form yields just one largeish per-target package.
> Over-size, monolithic, but simpler, less choices to confuse people.
> 
> 
> Of course ultimately we don't want per-target stuff at all. :)
> Or at least we want both "source" and "binary" distributions.
> 
> 
> Still I am confused.
> Don't people have binary distributions of programs with GUIs for Linux?
> Like Komodo IDE, Komodo Edit, Acrobat Reader?
> 
> 
> Maybe we should really have a java-generating backend...one binary distribution for all..and a better Android story?

That could be useful on Android.  But it *is* possible to get package C 
or at least C object code to run on Android.  I think that's the 
approach being used to get Python to run on Android.

> I know, there is a funny tradeoff here. Modula-3 is kind of lower-level than Java.
> You'd want such a backend/port to throw out our garbage collector..and heck..all unsafe code....
>  (or generate C for those and use JNI or such...interesting..theoretically possible..unlikely to happen..)
> 
> 
>  - Jay


From dabenavidesd at yahoo.es  Thu May 17 18:18:52 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 17 May 2012 17:18:52 +0100 (BST)
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl>
Message-ID: <1337271532.47137.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I believe they are in system limits.h aren't they.
BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
Thanks in advance.

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] C99 FloatMode stuff
Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 01:10




Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

?- Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/c995d0eb/attachment-0001.html>

From jay.krell at cornell.edu  Thu May 17 20:46:14 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 18:46:14 +0000
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <1337271532.47137.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl>,
	<1337271532.47137.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <COL101-W4BF60E04E5B4DB1D35477E6190@phx.gbl>


No Daniel. 


Date: Thu, 17 May 2012 17:18:52 +0100
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] C99 FloatMode stuff
To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I believe they are in system limits.h aren't they.
BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
Thanks in advance.

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] C99 FloatMode stuff
Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 01:10




Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

 - Jay
 		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/8b0d5a49/attachment-0001.html>

From hendrik at topoi.pooq.com  Thu May 17 20:57:53 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 17 May 2012 14:57:53 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517154836.GA20605@topoi.pooq.com>
References: <20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
Message-ID: <20120517185753.GA5741@topoi.pooq.com>

On Thu, May 17, 2012 at 11:48:37AM -0400, Hendrik Boom wrote:
> On Thu, May 17, 2012 at 06:01:19AM +0000, Jay K wrote:
> > 
> > Good.
> > Wasn't the error message from configure obvious though?
> 
> Evidently not.  Or I was too much asleep last night.  Or I didn't get 
> one. I'm looking for one now.  I find none in my most recent script 
> output.  In one of the old ones I find
> 
> checking for modern makeinfo... no
> configure: WARNING:
> *** Makeinfo is missing or too old.
> *** Info documentation will not be built.
> checking for recent Pod::Man... yes
> 
> but I suspect that may be irrelevant.  Unless packageing fails later 
> because it tries to package the info docs, which I hate anyway.
> 
> No, I don't find any messages.  But then, I'm simply using my old, 
> working cm3 compiler as a bootstrap to build the whole system for the 
> same machine.  I didn't have a specific 'configure' step.
> 
> I found a bunch of compilation warnings about
> * labels and other names  being defined but not used.
> * comparisons always false due to limited range of data type
> * invalid conversion type characters.  Might these actually cause 
> run-time failures?
> * right-hand operand of comma has no effect
> 
> These are unlikely to be the problems I'm contending with, but might 
> it be worth going through the entire build sometime and tracking 
> then all down?  Grepping my script output for "warning" would 
> probably find them all.
> 
> 
> > 
> > 
> > Anyway:
> >   I think there's a "minor" incrementality bug here.   
> >   Incremental build isn't picking back up where it left off/failed.  
> > 
> > Try this:
> >    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
> >    rm -rf /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516 
> >    ./make-dist.py  
> 
> Will do.  I had planned to do something like this when I was awake this 
> morning, but I was unsure just which files needed to be deleted.
> 

It definitely got past odbc now.  But it stopped within ESC.  I was 
surprised to find it her; I had thought the source code to be long lost.
I don't see am error message except for the failure to find .M3EXPORTS, 
ahich is probably something that cm3 should have generated.

The m3makefile 
/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile
seems to have trouble finding 
/tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/pkg/prover/AMD64_LINUX/.M3EXPORTS
which seems to me to be one level out in the source code.  Just what 
determines the order that these things are to be compiled?  The 
compilation log makes it look as if the outer one (prover) needed to be 
compiled first, so as to enerate the .M3EXPORTS file, but that the inner 
one (prover/test) actually got compiled first. 

Here's the output, starting with the first line of log contianing either 
the words "Simplify" or "prover".


== package /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test ==

 +++ /tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/bin/cm3    
-build -DROOT=/farhome/hendrik/cm3/cm3 +++
--- building in AMD64_LINUX ---

ignoring ../src/m3overrides

"/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile", line 
1: quake runtime error: unable to open 
"/tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/pkg/prover/AMD64_LINUX/.M3EXPORTS" 
for reading

--procedure--  -line-  -file---
import             --  <builtin>
include_dir         1  
/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile
                    5  
/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/AMD64_LINUX/m3make.args

Fatal Error: package build failed
 *** execution of [<function _BuildGlobalFunction at 0x10d0de8>, 
<function _ShipFunction at 0x10d0c80>] failed ***
hendrik at april:~/cm3/cm3/scripts/python$ exit

-- hendrik



From dabenavidesd at yahoo.es  Fri May 18 00:27:25 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 17 May 2012 23:27:25 +0100 (BST)
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <COL101-W4BF60E04E5B4DB1D35477E6190@phx.gbl>
Message-ID: <1337293645.96958.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
if not then either that value doesn't sound as a machine value since the OS must care at least of constant values in memory (you can't allow values larger than what memory supports) or (whichever library they had created) is "their standard" , I don't think C standards are very precise, in fact, they are bad, who needs C standards, who created or thinks knows the standards.
What the argot I would like to see are:
Infinity values, epsilon, and? memory limits under such that limit values holds, that is, you can't represent epsilon with little value of memory.
This would be the jargon of such libraries, instead they just make them a internal operation of their own calculation, which I can't trust, in summary this thing is unsound. Then the interface is UNSAFE for real which can't be a very standard thing by the way.
Thanks in advance

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] C99 FloatMode stuff
Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 13:46




No Daniel. 


Date: Thu, 17 May 2012 17:18:52 +0100
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] C99 FloatMode stuff
To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I believe they are in system limits.h aren't they.
BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
Thanks in advance.

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] C99 FloatMode stuff
Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 01:10




Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

?- Jay
 		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/6ab41119/attachment-0001.html>

From jay.krell at cornell.edu  Fri May 18 01:29:16 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 23:29:16 +0000
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517185753.GA5741@topoi.pooq.com>
References: <20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>,
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>,
	<20120517014903.GA19546@topoi.pooq.com>,
	<20120517023533.GB19546@topoi.pooq.com>,
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>,
	<20120517154836.GA20605@topoi.pooq.com>,
	<20120517185753.GA5741@topoi.pooq.com>
Message-ID: <COL101-W47988370CD738A644D7366E6190@phx.gbl>


I have not built the entire tree since that stuff came in.Oops.  If the goal is to get some sort of .deb, to see what it is, to give it to someone else, do this:    cd scripts    rm PKGSDB    edit down pkginfo.txt     hm, oops, this stuff isn't in there?      The same information might be duplicated in pylib.py?   I think I fixed that..based on a quick read.       Maybe we pickup all m3makefiles? Maybe.    Just rm -rf from your tree anything that is giving you trouble now, as you've already built lots of stuff.     - Jay

 > Date: Thu, 17 May 2012 14:57:53 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] building packages from source from cvs -- odbc
> 
> On Thu, May 17, 2012 at 11:48:37AM -0400, Hendrik Boom wrote:
> > On Thu, May 17, 2012 at 06:01:19AM +0000, Jay K wrote:
> > > 
> > > Good.
> > > Wasn't the error message from configure obvious though?
> > 
> > Evidently not.  Or I was too much asleep last night.  Or I didn't get 
> > one. I'm looking for one now.  I find none in my most recent script 
> > output.  In one of the old ones I find
> > 
> > checking for modern makeinfo... no
> > configure: WARNING:
> > *** Makeinfo is missing or too old.
> > *** Info documentation will not be built.
> > checking for recent Pod::Man... yes
> > 
> > but I suspect that may be irrelevant.  Unless packageing fails later 
> > because it tries to package the info docs, which I hate anyway.
> > 
> > No, I don't find any messages.  But then, I'm simply using my old, 
> > working cm3 compiler as a bootstrap to build the whole system for the 
> > same machine.  I didn't have a specific 'configure' step.
> > 
> > I found a bunch of compilation warnings about
> > * labels and other names  being defined but not used.
> > * comparisons always false due to limited range of data type
> > * invalid conversion type characters.  Might these actually cause 
> > run-time failures?
> > * right-hand operand of comma has no effect
> > 
> > These are unlikely to be the problems I'm contending with, but might 
> > it be worth going through the entire build sometime and tracking 
> > then all down?  Grepping my script output for "warning" would 
> > probably find them all.
> > 
> > 
> > > 
> > > 
> > > Anyway:
> > >   I think there's a "minor" incrementality bug here.   
> > >   Incremental build isn't picking back up where it left off/failed.  
> > > 
> > > Try this:
> > >    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
> > >    rm -rf /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516 
> > >    ./make-dist.py  
> > 
> > Will do.  I had planned to do something like this when I was awake this 
> > morning, but I was unsure just which files needed to be deleted.
> > 
> 
> It definitely got past odbc now.  But it stopped within ESC.  I was 
> surprised to find it her; I had thought the source code to be long lost.
> I don't see am error message except for the failure to find .M3EXPORTS, 
> ahich is probably something that cm3 should have generated.
> 
> The m3makefile 
> /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile
> seems to have trouble finding 
> /tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/pkg/prover/AMD64_LINUX/.M3EXPORTS
> which seems to me to be one level out in the source code.  Just what 
> determines the order that these things are to be compiled?  The 
> compilation log makes it look as if the outer one (prover) needed to be 
> compiled first, so as to enerate the .M3EXPORTS file, but that the inner 
> one (prover/test) actually got compiled first. 
> 
> Here's the output, starting with the first line of log contianing either 
> the words "Simplify" or "prover".
> 
> 
> == package /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test ==
> 
>  +++ /tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/bin/cm3    
> -build -DROOT=/farhome/hendrik/cm3/cm3 +++
> --- building in AMD64_LINUX ---
> 
> ignoring ../src/m3overrides
> 
> "/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile", line 
> 1: quake runtime error: unable to open 
> "/tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/pkg/prover/AMD64_LINUX/.M3EXPORTS" 
> for reading
> 
> --procedure--  -line-  -file---
> import             --  <builtin>
> include_dir         1  
> /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile
>                     5  
> /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/AMD64_LINUX/m3make.args
> 
> Fatal Error: package build failed
>  *** execution of [<function _BuildGlobalFunction at 0x10d0de8>, 
> <function _ShipFunction at 0x10d0c80>] failed ***
> hendrik at april:~/cm3/cm3/scripts/python$ exit
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/bca8ff44/attachment-0001.html>

From hendrik at topoi.pooq.com  Fri May 18 03:17:34 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 17 May 2012 21:17:34 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <COL101-W47988370CD738A644D7366E6190@phx.gbl>
References: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
	<COL101-W47988370CD738A644D7366E6190@phx.gbl>
Message-ID: <20120518011734.GA735@topoi.pooq.com>

On Thu, May 17, 2012 at 11:29:16PM +0000, Jay K wrote:
> 
> I have not built the entire tree since that stuff came in.Oops.  

My saying this year seems to be "That which is not tested is broken".

> If the goal is to get some sort of .deb, to see what it is, to give it to someone else, do this:    cd scripts    rm PKGSDB    edit down pkginfo.txt     hm, oops, this stuff isn't in there?      The same information might be duplicated in pylib.py?   I think I fixed that..based on a quick read.       Maybe we pickup all m3makefiles? Maybe.    Just rm -rf from your tree anything that is giving you trouble now, as you've already built lots of stuff.     - Jay

That's the way to get ahead at this point, yes.

I will have to take a look at ESC sometime, though.  It looks like fun.  
This is the stuff that processes all the mutex comments in Trestle, 
right?

I really had thought it was long-lost code, never to be seen again.  Or 
has someone started writing it anew?

-- hendrik


From jay.krell at cornell.edu  Fri May 18 03:31:59 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 01:31:59 +0000
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518011734.GA735@topoi.pooq.com>
References: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>,
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>,
	<20120517014903.GA19546@topoi.pooq.com>,
	<20120517023533.GB19546@topoi.pooq.com>,
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>,
	<20120517154836.GA20605@topoi.pooq.com>,
	<20120517185753.GA5741@topoi.pooq.com>,
	<COL101-W47988370CD738A644D7366E6190@phx.gbl>,
	<20120518011734.GA735@topoi.pooq.com>
Message-ID: <COL101-W35FD639411DD4E2EF83685E61E0@phx.gbl>


> My saying this year seems to be "That which is not tested is broken".  In the face of any change, including the mere passage of time (e.g. y2k):   That which is not tested often and recently is probably broken.    Running automated tests daily, or at least in a loop that might take over a day, is how you know what is working.   I believe someone recently recovered the ESC stuff. Probably Olaf.   - Jay
 > Date: Thu, 17 May 2012 21:17:34 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] building packages from source from cvs -- odbc
> 
> On Thu, May 17, 2012 at 11:29:16PM +0000, Jay K wrote:
> > 
> > I have not built the entire tree since that stuff came in.Oops.  
> 
> My saying this year seems to be "That which is not tested is broken".
> 
> > If the goal is to get some sort of .deb, to see what it is, to give it to someone else, do this:    cd scripts    rm PKGSDB    edit down pkginfo.txt     hm, oops, this stuff isn't in there?      The same information might be duplicated in pylib.py?   I think I fixed that..based on a quick read.       Maybe we pickup all m3makefiles? Maybe.    Just rm -rf from your tree anything that is giving you trouble now, as you've already built lots of stuff.     - Jay
> 
> That's the way to get ahead at this point, yes.
> 
> I will have to take a look at ESC sometime, though.  It looks like fun.  
> This is the stuff that processes all the mutex comments in Trestle, 
> right?
> 
> I really had thought it was long-lost code, never to be seen again.  Or 
> has someone started writing it anew?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/b1685039/attachment-0001.html>

From jay.krell at cornell.edu  Fri May 18 04:49:39 2012
From: jay.krell at cornell.edu (Jay)
Date: Thu, 17 May 2012 19:49:39 -0700
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <1337293645.96958.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <1337293645.96958.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <1301C8B3-DD12-46EE-BC17-0184E187A8A3@gmail.com>

I'm sorry Daniel, but almost all your emails make no sense or at best are just wrong.

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 17, 2012, at 3:27 PM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> if not then either that value doesn't sound as a machine value since the OS must care at least of constant values in memory (you can't allow values larger than what memory supports) or (whichever library they had created) is "their standard" , I don't think C standards are very precise, in fact, they are bad, who needs C standards, who created or thinks knows the standards.
> What the argot I would like to see are:
> Infinity values, epsilon, and  memory limits under such that limit values holds, that is, you can't represent epsilon with little value of memory.
> This would be the jargon of such libraries, instead they just make them a internal operation of their own calculation, which I can't trust, in summary this thing is unsound. Then the interface is UNSAFE for real which can't be a very standard thing by the way.
> Thanks in advance
> 
> --- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] C99 FloatMode stuff
> Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
> Fecha: jueves, 17 de mayo, 2012 13:46
> 
> No Daniel. 
> 
> 
> Date: Thu, 17 May 2012 17:18:52 +0100
> From: dabenavidesd at yahoo.es
> Subject: Re: [M3devel] C99 FloatMode stuff
> To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu
> 
> Hi all:
> I believe they are in system limits.h aren't they.
> BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
> Thanks in advance.
> 
> --- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] C99 FloatMode stuff
> Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
> Fecha: jueves, 17 de mayo, 2012 01:10
> 
> Mika, are FE_UNDERFLOW and such constants?
> Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
> see m3core/src/unix/Common/Uconstants.c
> 
> There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.
> 
>  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/46b853f6/attachment-0001.html>

From jay.krell at cornell.edu  Fri May 18 09:38:15 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 07:38:15 +0000
Subject: [M3devel] uninitialized vs. init_var?
Message-ID: <COL101-W19D4C919EC527186CC9B70E61E0@phx.gbl>


This seems dubious, doesn't it, to state something is not initiallized, and then initialize it?
It triggers an assertion failure in gcc 4.6 backend.

RTCollector.m3

(479) declare_global name:null size:0X4000000(67108864) align:0X40(64) type:struct type_id:0x747D8491 exported:false initialized:false var:0x3B m3name:L_2
(14190) init_var offset:0X2280(8832) var:0x3B:L_2 0 one_field: offset:0x2280 size:0x20


Yes I realize it is initialized to zero.
I don't know if it is obviously initialized to all zeros, as I don't see the size in declare_global..er..rather, yes, there is a size there...is it real, or just some large guess..? I haven't looked..


I'm going to try this little hack:


M3CG_HANDLER (INIT_VAR)
{
  tree f = { 0 };
  tree v = { 0 };

#if GCC46
  if (DECL_COMMON (var))
  {
    if (option_trace_all)
      fprintf (stderr, " clearing DECL_COMMON on %s", m3_get_var_trace_name (var));
    DECL_COMMON (var) = false;
  }
#endif

  TREE_USED (var) = true;
  one_field (offset, POINTER_SIZE, t_addr, &f, &v);
  TREE_VALUE (v) = m3_build2 (POINTER_PLUS_EXPR, t_addr,
                              m3_build1 (ADDR_EXPR, t_addr, var),
                              size_int (b));
}

The assertion is in gcc-4.6/gcc/config/darwin.c

darwin_asm_output_aligned_decl_local

  /* .. and it should be suitable for placement in local mem.  */
  gcc_assert(!TREE_PUBLIC (decl) && !DECL_COMMON (decl));
  /* .. and any initializer must be all-zero.  */
  gcc_assert ((DECL_INITIAL (decl) == NULL) 
           || (DECL_INITIAL (decl) == error_mark_node) 
           || initializer_zerop (DECL_INITIAL (decl)));


The first one I think. I think it is common.


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/892b5595/attachment-0001.html>

From dabenavidesd at yahoo.es  Fri May 18 17:36:40 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 18 May 2012 16:36:40 +0100 (BST)
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <1301C8B3-DD12-46EE-BC17-0184E187A8A3@gmail.com>
Message-ID: <1337355400.39333.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
The problem (and I don't think this for personal reasons, that I write at all), is as as Dr. Nelson rule of the thumb:
"If there is one paper about a problem, it has been solved, but If there are 100 papers it probably hasn't been solved"
Thanks in advance

--- El jue, 17/5/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] C99 FloatMode stuff
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: jueves, 17 de mayo, 2012 21:49

I'm sorry Daniel, but almost all your emails make no sense or at best are just wrong.
?- Jay (briefly/pocket-sized-computer-aka-phone)
On May 17, 2012, at 3:27 PM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
if not then either that value doesn't sound as a machine value since the OS must care at least of constant values in memory (you can't allow values larger than what memory supports) or (whichever library they had created) is "their standard" , I don't think C standards are very precise, in fact, they are bad, who needs C standards, who created or thinks knows the standards.
What the argot I would like to see are:
Infinity values, epsilon, and? memory limits under such that limit values holds, that is, you can't represent epsilon with little value of memory.
This would be the jargon of such libraries, instead they just make them a internal operation of their own calculation, which I can't trust, in summary this thing is unsound. Then the interface is UNSAFE for real which can't be a very standard thing by the way.
Thanks in
 advance

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] C99 FloatMode stuff
Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 13:46




No Daniel. 


Date: Thu, 17 May 2012 17:18:52 +0100
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] C99 FloatMode stuff
To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I believe they are in system limits.h aren't they.
BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
Thanks in advance.

--- El jue, 17/5/12, Jay K
 <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] C99 FloatMode stuff
Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 01:10




Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

?- Jay
 		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/265f116f/attachment-0001.html>

From mika at async.caltech.edu  Fri May 18 18:28:56 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Fri, 18 May 2012 09:28:56 -0700
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl> 
References: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl>
Message-ID: <20120518162856.4B3BD1A205B@async.async.caltech.edu>

Jay,

Yes I think FE_OVERFLOW et al. are required to be macros that expand
to integer constants.  So yes..

    Mika

Jay K writes:
>--_9cde7264-29bf-49d4-826d-6091d2cdb722_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Mika=2C are FE_UNDERFLOW and such constants?
>Specifically=2C if so=2C we can implement them more efficiently=2C as const=
>ant data=2C instead of via functions.
>see m3core/src/unix/Common/Uconstants.c
>
>There is a certain elegant generality to using functions=2C but exposing co=
>nstant data should be /slightly/ more efficient.
>
> - Jay
> 		 	   		  =
>
>--_9cde7264-29bf-49d4-826d-6091d2cdb722_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Tahoma
>}
>--></style></head>
><body class=3D'hmmessage'><div dir=3D'ltr'>
>Mika=2C are FE_UNDERFLOW and such constants?<br>Specifically=2C if so=2C we=
> can implement them more efficiently=2C as constant data=2C instead of via =
>functions.<br>see m3core/src/unix/Common/Uconstants.c<br><br>There is a cer=
>tain elegant generality to using functions=2C but exposing constant data sh=
>ould be /slightly/ more efficient.<br><br>&nbsp=3B- Jay<br> 		 
>	   		  </di=
>v></body>
></html>=
>
>--_9cde7264-29bf-49d4-826d-6091d2cdb722_--


From hendrik at topoi.pooq.com  Fri May 18 18:34:10 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 12:34:10 -0400
Subject: [M3devel] packages for AMD64-LINUX stable.
In-Reply-To: <20120518011734.GA735@topoi.pooq.com>
References: <20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
	<COL101-W47988370CD738A644D7366E6190@phx.gbl>
	<20120518011734.GA735@topoi.pooq.com>
Message-ID: <20120518163410.GA28229@topoi.pooq.com>

On Thu, May 17, 2012 at 09:17:34PM -0400, Hendrik Boom wrote:
> On Thu, May 17, 2012 at 11:29:16PM +0000, Jay K wrote:
> > 
> > I have not built the entire tree since that stuff came in.Oops.  
> 
> My saying this year seems to be "That which is not tested is broken".
> 
> > If the goal is to get some sort of .deb, to see what it is, to give it to someone else, do this:    cd scripts    rm PKGSDB    edit down pkginfo.txt     hm, oops, this stuff isn't in there?      The same information might be duplicated in pylib.py?   I think I fixed that..based on a quick read.       Maybe we pickup all m3makefiles? Maybe.    Just rm -rf from your tree anything that is giving you trouble now, as you've already built lots of stuff.     - Jay
> 
> That's the way to get ahead at this point, yes.

I now have packages 

cm3-all-AMD64_LINUX-d5.9.0-20120518.deb
cm3-all-AMD64_LINUX-d5.9.0-20120518.tar.gz
cm3-min-AMD64_LINUX-d5.9.0-20120518
cm3-min-AMD64_LINUX-d5.9.0-20120518.tar.gz

and a few huge directories under /tmp.  I presume those huge directories
contain the files that were archived into these packages and that I can 
discard them.  Have all the executables in them been shipped?  Or should 
I delete /usr/local/cm3 and install the package?

Is the verion number right?  And will debian's package mamager collate 
it becode, for example, cm3-all-AMD64_LINUX-5.9.0 when it finally comes 
out?  If not, the right version number for Debian is probably something 
like 5.9.0~20120518 instead of d5.9.0-20120518 (note the tilde).  I'll 
look at the version-numbering stuff in the packaging manual and see if I 
draw any conclusions, and whether the version number that's in the file 
name has any relevance to the one the package manager uses.
And the binary package just might have to contain the AMD64_LINUX 
information in another form.

And, of course, I'll have to do a test install, because that which is 
not tested is broken.

If I get these things sorted out, it's probably ready to make available 
as a package that works on current debian stable, though it'll be a lot 
more work to get it to conform to all the debian packaging 
rules.

Oh, yes, the package leaves out ESC.  My guess is that the package 
builder builds its modules in the wrong order, presumably because it 
needs some clues that should be present in the ESC source directories 
but isn't.  Anyone know what information find-packages.sh and pkginfo.sh 
need to do the job properly?  How do these nested program direcoties 
work, anyway?

-- hendrik

> 
> I will have to take a look at ESC sometime, though.  It looks like fun.  
> This is the stuff that processes all the mutex comments in Trestle, 
> right?
> 
> I really had thought it was long-lost code, never to be seen again.  Or 
> has someone started writing it anew?
> 
> -- hendrik


From dragisha at m3w.org  Fri May 18 18:58:26 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 18 May 2012 18:58:26 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516223123.GA25611@topoi.pooq.com>
	<COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>
Message-ID: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>

One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.

On May 17, 2012, at 1:40 AM, Jay K wrote:

>   But heck, really, if we generate C, then targets largely drop away.  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/01be4ef6/attachment-0001.html>

From mika at async.caltech.edu  Fri May 18 19:11:11 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Fri, 18 May 2012 10:11:11 -0700
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517185753.GA5741@topoi.pooq.com> 
References: <20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
Message-ID: <20120518171111.C803A1A205B@async.async.caltech.edu>

Hendrik Boom writes:
...
>It definitely got past odbc now.  But it stopped within ESC.  I was 
>surprised to find it her; I had thought the source code to be long lost.
...

It's not.  I was promised it and started to set up the directories but the
gentleman who promised me the code seems to have fallen off the earth.

    Mika


From dabenavidesd at yahoo.es  Fri May 18 19:16:59 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 18 May 2012 18:16:59 +0100 (BST)
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
Message-ID: <1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
After ESC we do need much debugger at all, in fact it was designed for that for avoiding put much time on it.
Still if we generate C is for super-optimization (but verified also mechanically), so I don't mind that, but for code quality I prefer C, I agree absolutely in that we should support it again for that purpose (as originally).
As for not verified code we should stick with C--, as it is written for that purposes, but for portability specially with implicit safety.
And for not verified nor optimal and not common use code (like mentor) we should make them source packages (in fact If they are written in Obliq we don't want to redistribute that as non-source), instead part of m3-demo package subdirectory or so.
I think for M3CG is that we need a LLVM or so back-end for JIT.
Thanks in advance

--- El vie, 18/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] LINUXLIBC6
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 18 de mayo, 2012 11:58

One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.
On May 17, 2012, at 1:40 AM, Jay K wrote:
??But heck, really, if we generate C, then targets largely drop away.??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/55302ae7/attachment-0001.html>

From hendrik at topoi.pooq.com  Fri May 18 19:23:00 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 13:23:00 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518171111.C803A1A205B@async.async.caltech.edu>
References: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
	<20120518171111.C803A1A205B@async.async.caltech.edu>
Message-ID: <20120518172300.GA28507@topoi.pooq.com>

On Fri, May 18, 2012 at 10:11:11AM -0700, Mika Nystrom wrote:
> Hendrik Boom writes:
> ...
. I was surprised to find it here; I had thought the source code to be 
> long lost.
> ...
> 
> It's not.  I was promised it and started to set up the directories but the
> gentleman who promised me the code seems to have fallen off the earth.

So the ESC directory isn't ESC yet?  Did the gentleman send you some 
but not all of it? 

-- hendrik


From hendrik at topoi.pooq.com  Fri May 18 19:26:06 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 13:26:06 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516223123.GA25611@topoi.pooq.com>
	<COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>
	<F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
Message-ID: <20120518172606.GB28507@topoi.pooq.com>

On Fri, May 18, 2012 at 06:58:26PM +0200, Dragi?a Duri? wrote:
> One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.

It's possible to generate C code full of #line preprocessor commands, 
so that debuggers get references to the original source code, not the 
generated C code.  The variable names would possibly be obscure, 
though.

> 
> On May 17, 2012, at 1:40 AM, Jay K wrote:
> 
> >   But heck, really, if we generate C, then targets largely drop away.  
> 


From dabenavidesd at yahoo.es  Fri May 18 19:27:27 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 18 May 2012 18:27:27 +0100 (BST)
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518171111.C803A1A205B@async.async.caltech.edu>
Message-ID: <1337362047.35503.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
we should be more aware that today H-P annually from now will drop 30.000 jobs there in total, so I hope this can go on smoothly.
If not, we should ask them which projects made them release their source code on the last ancient Mobile OS.
Thanks in advance


--- El vie, 18/5/12, Mika Nystrom <mika at async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] building packages from source from cvs -- odbc
> Para: "Hendrik Boom" <hendrik at topoi.pooq.com>
> CC: m3devel at elegosoft.com
> Fecha: viernes, 18 de mayo, 2012 12:11
> Hendrik Boom writes:
> ...
> >It definitely got past odbc now.  But it stopped
> within ESC.  I was 
> >surprised to find it her; I had thought the source code
> to be long lost.
> ...
> 
> It's not.  I was promised it and started to set up the
> directories but the
> gentleman who promised me the code seems to have fallen off
> the earth.
> 
>     Mika
> 


From mika at async.caltech.edu  Fri May 18 20:03:30 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Fri, 18 May 2012 11:03:30 -0700
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518172300.GA28507@topoi.pooq.com> 
References: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
	<20120518171111.C803A1A205B@async.async.caltech.edu>
	<20120518172300.GA28507@topoi.pooq.com>
Message-ID: <20120518180330.4CDB21A205B@async.async.caltech.edu>

Hendrik Boom writes:
>On Fri, May 18, 2012 at 10:11:11AM -0700, Mika Nystrom wrote:
>> Hendrik Boom writes:
>> ...
>. I was surprised to find it here; I had thought the source code to be 
>> long lost.
>> ...
>> 
>> It's not.  I was promised it and started to set up the directories but the
>> gentleman who promised me the code seems to have fallen off the earth.
>
>So the ESC directory isn't ESC yet?  Did the gentleman send you some 
>but not all of it? 
>
>-- hendrik

What's in there is Simplify, which has been distributed with other projects
(specifically with ESC/Java).  It's also part of the original ESC.

     Mika


From jay.krell at cornell.edu  Fri May 18 21:23:24 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 19:23:24 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516223123.GA25611@topoi.pooq.com>
	<COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>,
	<F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
Message-ID: <COL101-W45E1537E67C2E81FC1A9C4E61E0@phx.gbl>


The debugging experience is already poor on systems that don't support stabs, e.g. Darwin, NT, HP-UX (maybe only certain processors therein). Also it requires building a custom gdb. Our gdb fork is old. Is anyone going to update it ever?#line directives will help.Stock gdb will be much more useful than it is today.But yes, it won't be great idiomatic Modula-3 debugging.   - Jay Subject: Re: [M3devel] LINUXLIBC6
From: dragisha at m3w.org
Date: Fri, 18 May 2012 18:58:26 +0200
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.
On May 17, 2012, at 1:40 AM, Jay K wrote:  But heck, really, if we generate C, then targets largely drop away.  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/74eeb691/attachment-0001.html>

From jay.krell at cornell.edu  Fri May 18 21:49:44 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 19:49:44 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>,
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W1466668864A79F0C274528E61E0@phx.gbl>


C-- is not actively maintained I believe, so not a good idea to use.  C and C++ are much more portable and "maintained" (C++ gives us more portable efficient exception handling.)  (There is a good C and C++ compiler for every mainstream system in use today  LLVM isn't a bad idea, but there is more expertise out there (and in me) with C and C++, so C and C++ are easier to generate.It is a bit of a chore to learn and use.  JIT isn't a crazy idea either..or rather, an interpreter.If you look at parse.c..and you add a few thread locals..I think it's not hard to turn it into an interpreter.  (In reality you don't want to start with parse.c because of the GPL.)  And, interesting point as well, an interpreter in Java or C# or whatever is "more native" on e.g. Android and Windows Phone, is also not too difficult. You could do it in a low level fashion that is viable in "safe" environments.Search the web for "XML VM". I know it is nonsense term, but the project is/was real, despite the name, it is a viable approach.  What they did is this:  "convert" (i.e. dump faithfully and without optimization or fitting any uniform scheme) Java .class files and .NET IL into XML.  Write XML Style Sheets (XSL) to transform to whatever -- including JavaScript and C.  Write some supporting libraries.  As a result, they could "compile" Java to C and run on iPhone, "compile" Java to JavaScript and run in browser (Yes, I know about Google Web Toolkit.)    - Jay
 Date: Fri, 18 May 2012 18:16:59 +0100
From: dabenavidesd at yahoo.es
To: dragisha at m3w.org
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] LINUXLIBC6

Hi all:
After ESC we do need much debugger at all, in fact it was designed for that for avoiding put much time on it.
Still if we generate C is for super-optimization (but verified also mechanically), so I don't mind that, but for code quality I prefer C, I agree absolutely in that we should support it again for that purpose (as originally).
As for not verified code we should stick with C--, as it is written for that purposes, but for portability specially with implicit safety.
And for not verified nor optimal and not common use code (like mentor) we should make them source packages (in fact If they are written in Obliq we don't want to redistribute that as non-source), instead part of m3-demo package subdirectory or so.
I think for M3CG is that we need a LLVM or so back-end for JIT.
Thanks in advance

--- El vie, 18/5/12, Dragi?a
 Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] LINUXLIBC6
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 18 de mayo, 2012 11:58

One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.
On May 17, 2012, at 1:40 AM, Jay K wrote:  But heck, really, if we generate C, then targets largely drop away.  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/33fcf5fa/attachment-0001.html>

From hendrik at topoi.pooq.com  Fri May 18 22:56:49 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 16:56:49 -0400
Subject: [M3devel] more Debian packages?
Message-ID: <20120518205649.GA26162@topoi.pooq.com>

Having succeeded at producing a binary .deb packages for Debian squeeze 
(though I still have to try it out), I'm now looking at my other 
machines.  I have a 32-bit Intel machine with wheeze (testing), and one 
that can run squeeze (stable).  All of them have access to the same 
NFS-mounted source tree.  Is it practical to use the same tree for two 
different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
be kept separate?  Or do I need to clean it out or copy it?

(by the way, I expect making packages for different Debian releases on 
the same hardware architecture will require a new source tree, or a 
cleaned-out one.  In my case they'll both be LINUXLIBC6)

-- hendrik



From jay.krell at cornell.edu  Fri May 18 23:50:24 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 21:50:24 +0000
Subject: [M3devel] more Debian packages?
In-Reply-To: <20120518205649.GA26162@topoi.pooq.com>
References: <20120518205649.GA26162@topoi.pooq.com>
Message-ID: <COL101-W81D30A014D472E089333EE61E0@phx.gbl>


Yes and yes.LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.  Please try to use I386_LINUX.I really want to stop this LINUXLIBC6 stuff...   You can share the source. But we also have outputs in the source tree (unfortunately!).    You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...   Do this to switch:  ./do-cm3-all.py realclean   - Jay
 > Date: Fri, 18 May 2012 16:56:49 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] more Debian packages?
> 
> Having succeeded at producing a binary .deb packages for Debian squeeze 
> (though I still have to try it out), I'm now looking at my other 
> machines.  I have a 32-bit Intel machine with wheeze (testing), and one 
> that can run squeeze (stable).  All of them have access to the same 
> NFS-mounted source tree.  Is it practical to use the same tree for two 
> different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> be kept separate?  Or do I need to clean it out or copy it?
> 
> (by the way, I expect making packages for different Debian releases on 
> the same hardware architecture will require a new source tree, or a 
> cleaned-out one.  In my case they'll both be LINUXLIBC6)
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/93b0a19f/attachment-0001.html>

From hendrik at topoi.pooq.com  Sat May 19 01:29:59 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 19:29:59 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
References: <20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
Message-ID: <20120518232959.GB26422@topoi.pooq.com>

On Thu, May 17, 2012 at 06:01:19AM +0000, Jay K wrote:
> 
> Note also, I think it is obvious, but I wrote make-dist.py to always package up everything possible
> for the target platform. So it is up to you as the "builder" to have all the dependencies already installed.
> It isn't great.
> I don't believe there is a perfect option here.
> Another release form we have yields a bunch of per-target packages.
> I find that confusing -- too many.
> My form yields just one largeish per-target package.
> Over-size, monolithic, but simpler, less choices to confuse people.

Debian splits things up a lot more, and has explicit package-dependencies.

There's usually an omnibus package the depends on all the others, for 
the simple souls who just want everything.  Sometimes they are amazed 
how much everything entails.  More often the don't notice.  I, for 
example, got a complete set of video drivers for just about every 
video card ever made, as a result of installing one package I was 
actually interested in.  Threatening to take one out (I didn't have 
that card) resulted in aptitude trying to remove my window manager.  
Clearly a poor situation.  But that's what an all-inclusive policy can 
cause.

In addition, there's a main package that contains everything you just 
couldn't do without, and you have to add other packages as you need 
them.  For the video situation above, the user could take this approach, 
but it would require him to know just what hardware he had in his 
machine.  Most users don't know this and don't care to find out.

So applying this philosophy to Modula 3, it would probably end up 
split up at least as much as the multipackage offering on the download 
site.  And these packages would have dependencies on one another, so 
you wouldn't end up installing one without its prerequisites.

One package would clearly be the compiler and its minimal run-time 
system.

Others would provide applications and libraries.

And each libraries would be split further -- one package (perhaps 
called foo) that provides what you need to run a program using it, and 
another (foo-dev) that provides what you need to cmopile a program 
that needs it.  THer are interested in making the disk requirements 
of a Debian system as small as possible.  Even in C, if you aren't 
going to use a library for developmentt, you can get rid of a lot of 
h-files.

It's quite possible for one source package to generate several binary 
packages, by the way.

---

The other thing that separates our packages from ordinary, official 
Debian packages it that ours install everything to one place in the 
file system, and Debian follows a standard tthat spreads it all over 
the place.

I'd have to learn and do a lot to get something acceptable to Debian.  
I certianly won't get it all done by the expected wheezy freeze in a 
few months, and, other things being important too, I may not get 
around to it at all.

-- hendrik 

> 
> 
> Of course ultimately we don't want per-target stuff at all. :)
> Or at least we want both "source" and "binary" distributions.

-- hendrik

> 
> 
> Still I am confused.
> Don't people have binary distributions of programs with GUIs for Linux?
> Like Komodo IDE, Komodo Edit, Acrobat Reader?
> 
> 
> Maybe we should really have a java-generating backend...one binary distribution for all..and a better Android story?
> I know, there is a funny tradeoff here. Modula-3 is kind of lower-level than Java.
> You'd want such a backend/port to throw out our garbage collector..and heck..all unsafe code....
>  (or generate C for those and use JNI or such...interesting..theoretically possible..unlikely to happen..)
> 
> 
>  - Jay
> 
> 
> > Date: Wed, 16 May 2012 22:35:33 -0400
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] building packages from source from cvs -- odbc
> > 
> > On Wed, May 16, 2012 at 09:49:03PM -0400, Hendrik Boom wrote:
> > > On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> > > > 
> > > >      > *** LIBRARY_PATH shouldn't contain the current directory when  
> > > >      > *** building gcc. Please change the environment variable  
> > > >      > *** and run configure again.  
> > > >     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
> > > >   :/usr/local/Gambit-C/lib  
> > > >  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  
> > > 
> > > Yes, emptying LIBRARY_PATH enabled uprade.py to complete successfully.
> > > Thanks.  It would have taken me many ages to figure this out.
> > > 
> > > -- hendrik
> > > 
> > Now I'm onto ./make-dist.py
> > 
> > It fails in teh data base stuff.
> > 
> > First becaues it didn't have libodbc.  So I installed package unixodbc.
> > But then:
> > 
> > == package /farhome/hendrik/cm3/cm3/m3-db/odbc ==
> > 
> >  +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3    -build -DROOT=/farhome/hendrik/cm3/cm3 +++
> > --- building in AMD64_LINUX ---
> > 
> > ignoring ../src/m3overrides
> > 
> >  ==> /farhome/hendrik/cm3/cm3/m3-db/odbc done
> > 
> >  +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3  -ship -DROOT=/farhome/hendrik/cm3/cm3 +++
> > --- shipping from AMD64_LINUX ---
> > 
> > . => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> >   .M3EXPORTS      
> > . => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib
> >   libm3odbc.so.5  "/farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP", line 4: quake runtime error: unable to copy "libm3odbc.so.5" to "/tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib/libm3odbc.so.5": errno=2
> > 
> > --procedure--  -line-  -file---
> > install_file       --  <builtin>
> >                     4  /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP
> > 
> > Fatal Error: package build failed
> >  *** execution of [<function _BuildGlobalFunction at 0x1a56de8>, <function _ShipFunction at 0x1a56c80>] failed ***
> > hendrik at april:~/cm3/cm3/scripts/python$ 
> > 
> > 
> > It doesn't seem to build libm3odbc.so.5
> > 
> > hendrik at april:~/cm3/cm3/m3-db/odbc$ ls AMD64_LINUX/
> > libm3odbc.a    libm3odbc.so  SQLext.mo  SQLtypes.io
> > libm3odbc.m3x  SQLext.io     SQL.io
> > hendrik at april:~/cm3/cm3/m3-db/odbc$ 
> > 
> > There's nothing at all in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> > There are lots of files in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib,
> > but nothing resembling libm3odbc>
> > 
> > -- hendrik
> > 
> > 
>  		 	   		  


From dabenavidesd at yahoo.es  Sat May 19 16:38:48 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 19 May 2012 15:38:48 +0100 (BST)
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518232959.GB26422@topoi.pooq.com>
Message-ID: <1337438328.39377.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
if the .deb package doesn't overrides another location or content of .io files in another .deb then it shouldn't go inside the same PKG_ROOT but just as is any other non-Modula3 built library. But if they are, they should go to cm3 paths because you could require to re-link and generate updated packages from a specific location you choose from deb-src.
Something akin linux modules and kernel, if you compile a new module you need to rebuild against the kernel (isn't like that) to re-link and use. Normally this modules are just libraries and kernel is just compiled in very old stable kernels. That's what I learned from Ubuntu.
Thanks in advance 

--- El vie, 18/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] building packages from source from cvs -- odbc
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 18 de mayo, 2012 18:29
> On Thu, May 17, 2012 at 06:01:19AM
> +0000, Jay K wrote:
> > 
> > Note also, I think it is obvious, but I wrote
> make-dist.py to always package up everything possible
> > for the target platform. So it is up to you as the
> "builder" to have all the dependencies already installed.
> > It isn't great.
> > I don't believe there is a perfect option here.
> > Another release form we have yields a bunch of
> per-target packages.
> > I find that confusing -- too many.
> > My form yields just one largeish per-target package.
> > Over-size, monolithic, but simpler, less choices to
> confuse people.
> 
> Debian splits things up a lot more, and has explicit
> package-dependencies.
> 
> There's usually an omnibus package the depends on all the
> others, for 
> the simple souls who just want everything.  Sometimes
> they are amazed 
> how much everything entails.  More often the don't
> notice.  I, for 
> example, got a complete set of video drivers for just about
> every 
> video card ever made, as a result of installing one package
> I was 
> actually interested in.  Threatening to take one out (I
> didn't have 
> that card) resulted in aptitude trying to remove my window
> manager.  
> Clearly a poor situation.  But that's what an
> all-inclusive policy can 
> cause.
> 
> In addition, there's a main package that contains everything
> you just 
> couldn't do without, and you have to add other packages as
> you need 
> them.  For the video situation above, the user could
> take this approach, 
> but it would require him to know just what hardware he had
> in his 
> machine.  Most users don't know this and don't care to
> find out.
> 
> So applying this philosophy to Modula 3, it would probably
> end up 
> split up at least as much as the multipackage offering on
> the download 
> site.  And these packages would have dependencies on
> one another, so 
> you wouldn't end up installing one without its
> prerequisites.
> 
> One package would clearly be the compiler and its minimal
> run-time 
> system.
> 
> Others would provide applications and libraries.
> 
> And each libraries would be split further -- one package
> (perhaps 
> called foo) that provides what you need to run a program
> using it, and 
> another (foo-dev) that provides what you need to cmopile a
> program 
> that needs it.  THer are interested in making the disk
> requirements 
> of a Debian system as small as possible.  Even in C, if
> you aren't 
> going to use a library for developmentt, you can get rid of
> a lot of 
> h-files.
> 
> It's quite possible for one source package to generate
> several binary 
> packages, by the way.
> 
> ---
> 
> The other thing that separates our packages from ordinary,
> official 
> Debian packages it that ours install everything to one place
> in the 
> file system, and Debian follows a standard tthat spreads it
> all over 
> the place.
> 
> I'd have to learn and do a lot to get something acceptable
> to Debian.  
> I certianly won't get it all done by the expected wheezy
> freeze in a 
> few months, and, other things being important too, I may not
> get 
> around to it at all.
> 
> -- hendrik 
> 
> > 
> > 
> > Of course ultimately we don't want per-target stuff at
> all. :)
> > Or at least we want both "source" and "binary"
> distributions.
> 
> -- hendrik
> 
> > 
> > 
> > Still I am confused.
> > Don't people have binary distributions of programs with
> GUIs for Linux?
> > Like Komodo IDE, Komodo Edit, Acrobat Reader?
> > 
> > 
> > Maybe we should really have a java-generating
> backend...one binary distribution for all..and a better
> Android story?
> > I know, there is a funny tradeoff here. Modula-3 is
> kind of lower-level than Java.
> > You'd want such a backend/port to throw out our garbage
> collector..and heck..all unsafe code....
> >  (or generate C for those and use JNI or
> such...interesting..theoretically possible..unlikely to
> happen..)
> > 
> > 
> >  - Jay
> > 
> > 
> > > Date: Wed, 16 May 2012 22:35:33 -0400
> > > From: hendrik at topoi.pooq.com
> > > To: m3devel at elegosoft.com
> > > Subject: Re: [M3devel] building packages from
> source from cvs -- odbc
> > > 
> > > On Wed, May 16, 2012 at 09:49:03PM -0400, Hendrik
> Boom wrote:
> > > > On Thu, May 17, 2012 at 12:06:00AM +0000, Jay
> K wrote:
> > > > > 
> > > > >      > ***
> LIBRARY_PATH shouldn't contain the current directory
> when  
> > > > >      > *** building
> gcc. Please change the environment variable  
> > > > >      > *** and run
> configure again.  
> > > > > 
>    hendrik at april:~/cm3/cm3/scripts/python$
> echo $LIBRARY_PATH  
> > > >
> >   :/usr/local/Gambit-C/lib  
> > > > >  Please either clear the variable,
> or at least remove the leading :.The leading : makes there
> be an empty entry, which is interpreted as current
> directory, which is dangerous and fragile. I think.This is a
> local problem on your machine. Easily
> fixed.   It might be reasonable for us to
> clear it in m3cc/src/m3makefile.   - Jay
>    
>         
>           
>   
> > > > 
> > > > Yes, emptying LIBRARY_PATH enabled uprade.py
> to complete successfully.
> > > > Thanks.  It would have taken me many
> ages to figure this out.
> > > > 
> > > > -- hendrik
> > > > 
> > > Now I'm onto ./make-dist.py
> > > 
> > > It fails in teh data base stuff.
> > > 
> > > First becaues it didn't have libodbc.  So I
> installed package unixodbc.
> > > But then:
> > > 
> > > == package /farhome/hendrik/cm3/cm3/m3-db/odbc ==
> > > 
> > >  +++
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3 
>   -build -DROOT=/farhome/hendrik/cm3/cm3 +++
> > > --- building in AMD64_LINUX ---
> > > 
> > > ignoring ../src/m3overrides
> > > 
> > >  ==> /farhome/hendrik/cm3/cm3/m3-db/odbc
> done
> > > 
> > >  +++
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3 
> -ship -DROOT=/farhome/hendrik/cm3/cm3 +++
> > > --- shipping from AMD64_LINUX ---
> > > 
> > > . =>
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> > >   .M3EXPORTS      
> > > . =>
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib
> > >   libm3odbc.so.5 
> "/farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP",
> line 4: quake runtime error: unable to copy "libm3odbc.so.5"
> to
> "/tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib/libm3odbc.so.5":
> errno=2
> > > 
> > > --procedure--  -line-  -file---
> > > install_file   
>    --  <builtin>
> > >             
>        4 
> /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP
> > > 
> > > Fatal Error: package build failed
> > >  *** execution of [<function
> _BuildGlobalFunction at 0x1a56de8>, <function
> _ShipFunction at 0x1a56c80>] failed ***
> > > hendrik at april:~/cm3/cm3/scripts/python$ 
> > > 
> > > 
> > > It doesn't seem to build libm3odbc.so.5
> > > 
> > > hendrik at april:~/cm3/cm3/m3-db/odbc$ ls
> AMD64_LINUX/
> > > libm3odbc.a    libm3odbc.so 
> SQLext.mo  SQLtypes.io
> > > libm3odbc.m3x  SQLext.io 
>    SQL.io
> > > hendrik at april:~/cm3/cm3/m3-db/odbc$ 
> > > 
> > > There's nothing at all in
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> > > There are lots of files in
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib,
> > > but nothing resembling libm3odbc>
> > > 
> > > -- hendrik
> > > 
> > > 
> >     
>         
>           
>   
> 


From dabenavidesd at yahoo.es  Sat May 19 18:41:03 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 19 May 2012 17:41:03 +0100 (BST)
Subject: [M3devel] building packages from source from cvs -- odbc
Message-ID: <1337445663.91287.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
there seems to be a relation between Modula-3 GUI INTERFACE specification of a pen-handling UI that allowed to type letters from uni-strokes:
http://www.leagle.com/xmlResult.aspx?page=11&xmldoc=2001481198FSupp2d283_1453.xml&docbase=CSLWAR2-1986-2006&SizeDisp=7

3com argued that the Modula-3's XEROX Patent wasn't infringed since the OS hadn't specified that functionality but settled the case with a money deal and a 7-year peace deal over mutual patents from 3com:
http://findarticles.com/p/articles/mi_m0EIN/is_2006_June_28/ai_n26909742/

Now that next year deal will be over they might be interested in pursuing another set of questions over XEROX's OS using Modula-3 code in ESC (because they would still need to proof full-integrity of Modula-3 ESC tool) and libraries use by XEROX OS:
http://www.google.com/patents/US5596656

I think we could ask if they want to litigate over the XEROX' OS again.
Thanks in advance

--- El vie, 18/5/12, Mika Nystrom <mika at async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] building packages from source from cvs -- odbc
> Para: "Hendrik Boom" <hendrik at topoi.pooq.com>
> CC: m3devel at elegosoft.com
> Fecha: viernes, 18 de mayo, 2012 13:03
> Hendrik Boom writes:
> >On Fri, May 18, 2012 at 10:11:11AM -0700, Mika Nystrom
> wrote:
> >> Hendrik Boom writes:
> >> ...
> >. I was surprised to find it here; I had thought the
> source code to be 
> >> long lost.
> >> ...
> >> 
> >> It's not.  I was promised it and started to
> set up the directories but the
> >> gentleman who promised me the code seems to have
> fallen off the earth.
> >
> >So the ESC directory isn't ESC yet?  Did the
> gentleman send you some 
> >but not all of it? 
> >
> >-- hendrik
> 
> What's in there is Simplify, which has been distributed with
> other projects
> (specifically with ESC/Java).  It's also part of the
> original ESC.
> 
>      Mika
>




From dabenavidesd at yahoo.es  Sat May 19 20:32:10 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 19 May 2012 19:32:10 +0100 (BST)
Subject: [M3devel] more Debian packages?
In-Reply-To: <COL101-W81D30A014D472E089333EE61E0@phx.gbl>
Message-ID: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:

?I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,

for instance to allow and or LINUX_I8086, etc LINUX_I387 

For VAXen computers:

VMS_VAX__

for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11

Alpha's: OSF_ALPHA

For Unixes:

FBSD-GENERIC_I_86___--

To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64

Also could be managed by Manufacturer Model code-name, like

DEC_AQUARIUS or DEC_10000.



Also if we are gonna take macro assembly for cross-platform distributions then, we would need? something akin:

NT_XASM-I_86___

So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)

This would allow to compile CVSup at least is what one would like to
Thanks in advance

 --- El vie, 18/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] more Debian packages?
Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 18 de mayo, 2012 16:50




Yes and yes.
LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.
But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.
?
?
Please try to use I386_LINUX.
I really want to stop this LINUXLIBC6 stuff...
?
?
?You can share the source.
?But we also have outputs in the source tree (unfortunately!).
??? You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...
?
?
?Do this to switch:
?
?./do-cm3-all.py realclean 
?
?- Jay
?
> Date: Fri, 18 May 2012 16:56:49 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] more Debian packages?
> 
> Having succeeded at producing a binary .deb packages for Debian squeeze 
> (though I still have to try it out), I'm now looking at my other 
> machines.  I have a 32-bit Intel machine with wheeze (testing), and one 
> that can run squeeze (stable).  All of them have access to the same 
> NFS-mounted source tree.  Is it practical to use the same tree for two 
> different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> be kept separate?  Or do I need to clean it out or copy it?
> 
> (by the way, I expect making packages for different Debian releases on 
> the same hardware architecture will require a new source tree, or a 
> cleaned-out one.  In my case they'll both be LINUXLIBC6)
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120519/5c7b0dfb/attachment-0001.html>

From peter.mckinna at gmail.com  Sun May 20 02:48:08 2012
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Sun, 20 May 2012 10:48:08 +1000
Subject: [M3devel] Linker override
Message-ID: <CAEy6uxqLdrGOydLBc=QgeB7Z5ZswOdYrsZL62D0i+cKC-9p9jw@mail.gmail.com>

Hi,

  I have had to override the default linker in my m3makefile to the
C++ linker to link
against a C++ library as in

SYSTEM_LD = "g++ -gstabs+ -m64 -fPIC -mno-align-double"

is there a more portable way to do this? I'm sure it wont work on windows!!

Peter


From jay.krell at cornell.edu  Sun May 20 03:31:16 2012
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 May 2012 01:31:16 +0000
Subject: [M3devel] Linker override
In-Reply-To: <CAEy6uxqLdrGOydLBc=QgeB7Z5ZswOdYrsZL62D0i+cKC-9p9jw@mail.gmail.com>
References: <CAEy6uxqLdrGOydLBc=QgeB7Z5ZswOdYrsZL62D0i+cKC-9p9jw@mail.gmail.com>
Message-ID: <COL101-W6496D86AAFB9672E062B10E61C0@phx.gbl>


I don't know what is the ideal design here.

Of course you can easily skip the code on Windows:

if equal(OS_TYPE, "POSIX")
? SYSTEM_LD = "g++ -gstabs+ -m64 -fPIC -mno-align-double"
end

There is no gcc vs. g++ analog on Windows. Good.

I know we could hack and slash at it gradually:

m3makefile:
?USE_GPLUSPLUS = TRUE? ?
?USE_CPLUSPLUS_LINKER = TRUE ?
?USE_CPLUSPLUS = TRUE ?


and then check that wherever in the config files.


There is a need for some sort of modularity / additivity here.
But I don't know what the design and interface should look like.

Most likely this notion of "use cplusplus" needs to be unioned across all libraries being linked together.


?- Jay




----------------------------------------
> Date: Sun, 20 May 2012 10:48:08 +1000
> From: peter.mckinna at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Linker override
>
> Hi,
>
> I have had to override the default linker in my m3makefile to the
> C++ linker to link
> against a C++ library as in
>
> SYSTEM_LD = "g++ -gstabs+ -m64 -fPIC -mno-align-double"
>
> is there a more portable way to do this? I'm sure it wont work on windows!!
>
> Peter
 		 	   		  

From dragisha at m3w.org  Sun May 20 22:09:46 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 20 May 2012 22:09:46 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <20120518172606.GB28507@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516223123.GA25611@topoi.pooq.com>
	<COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>
	<F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<20120518172606.GB28507@topoi.pooq.com>
Message-ID: <DE38D246-53B8-4105-9281-BC395B2E7920@m3w.org>


On May 18, 2012, at 7:26 PM, Hendrik Boom wrote:

> On Fri, May 18, 2012 at 06:58:26PM +0200, Dragi?a Duri? wrote:
>> One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.
> 
> It's possible to generate C code full of #line preprocessor commands, 
> so that debuggers get references to the original source code, not the 
> generated C code.  The variable names would possibly be obscure, 
> though.
> 
Exactly.

>> 
>> On May 17, 2012, at 1:40 AM, Jay K wrote:
>> 
>>>  But heck, really, if we generate C, then targets largely drop away.  
>> 



From dragisha at m3w.org  Sun May 20 22:11:39 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 20 May 2012 22:11:39 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W1466668864A79F0C274528E61E0@phx.gbl>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>,
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
Message-ID: <B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>


On May 18, 2012, at 9:49 PM, Jay K wrote:

> LLVM isn't a bad idea, but there is more expertise out there (and in me) with C and C++, so C and C++ are easier to generate.
> It is a bit of a chore to learn and use.
>  
>  
> JIT isn't a crazy idea either..or rather, an interpreter.
> If you look at parse.c..and you add a few thread locals..I think it's not hard to turn it into an interpreter.
>   (In reality you don't want to start with parse.c because of the GPL.)

LLVM and JIT are close enough. You do LLVM, you get JIT.

Also, for debugging we need DWARF. Not incompatible with LLVM. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/6048caf8/attachment-0001.html>

From jay.krell at cornell.edu  Sun May 20 23:28:27 2012
From: jay.krell at cornell.edu (Jay)
Date: Sun, 20 May 2012 14:28:27 -0700
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
Message-ID: <7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>

For dwarf et al: there "nothing" to it: "just" generate reasonable "code" (LLVM whatever, gcc "tree", C, etc) and the next level down handles it. Er, but for some bigger & smaller problems. 


Currently cm3cg -g for dwarf crashes. That is a small problem actually. But even if fixed, not a good experience -- no type information.


Larger "problem" & "good thing" is that the "front end" is more of a compiler than you might expect. It does "low level" things like "layout" and generates "variable plus offset" references "instead of" "field accesses".


That isn't necessarily bad. It is why/how we get away with giving gcc so little type information though.
And it might otherwise hurt debugging.


But ok. I have some ideas & plans, & some procrastination-enabling diversions.


 1. Update to gcc 4.6. Making good progress recently. This buys nothing. Procrastination.
 2. Update to gcc 4.7. Ditto.


Then there are a few more valuable things to get on to.


A. Better type info for gcc, so stock gdb much more useful. I'll probably NOT do this.


B. Use LLVM. I probably won't. But if there is a C-backend, then maybe, as that accomplishes two things at once (newer?better?cleaner?faster backend, portable C distribution)


C. Remove jmpbuf size knowledge from front end.
C.1 and maybe word size
C.2 and maybe endian
I.e. remove target dependentness


D. cooperative suspend 
i.e. again drastically increase portability


E. A C-generating backend.


The idea is, if these are all done, the system becomes "automatically" portable to "all" systems, with a pretty broad definition of "all": having a C?C++ compiler, being Posix but not too fancy (pthreads/open/read/write/close/send/recv/fork/exec, but nothing signal/semaphore related nor extensions to direct suspend threads or get stack pointer), or Win32, and optionally X Windows. 
At that point, time permitting, I might try again AIX, OpenVMS, Irix, iPhone/iPad, etc.


The remaining nagging portability concerns would be just: systems without public C compiler (windows phone, browser), and getting the second stack pointer on Itanium.


AT that point, if we ever get there, backends targeting Java, C#, JavaScript become maybe interesting (threads in JavaScript??). & the project could be considered very much more done. Maybe write other integrated backends, or linker, or target kernel interfaces instead of libc (esp. regarding threads on Linux)


Other projects at that time could include better interop between C, C++, and Modula-3. I'd like to see an end to fragile hand-written interop.


It'd also be good to move Trestle to the new X C bindings (xcb?).


I need to go back & explain something. Normally gcc compilers don't know anything about debug formats: stabs, coff, dwarf, etc. The reason cm3cg is different because what it does is mostly ignore all debugging infrastructure and generate its own custom information, for consumption by associated custom code in m3gdb. It just uses stabs as container or transport, for arbitrary data.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 20, 2012, at 1:11 PM, Dragi?a Duri? <dragisha at m3w.org> wrote:

> 
> On May 18, 2012, at 9:49 PM, Jay K wrote:
> 
>> LLVM isn't a bad idea, but there is more expertise out there (and in me) with C and C++, so C and C++ are easier to generate.
>> It is a bit of a chore to learn and use.
>>  
>>  
>> JIT isn't a crazy idea either..or rather, an interpreter.
>> If you look at parse.c..and you add a few thread locals..I think it's not hard to turn it into an interpreter.
>>   (In reality you don't want to start with parse.c because of the GPL.)
> 
> LLVM and JIT are close enough. You do LLVM, you get JIT.
> 
> Also, for debugging we need DWARF. Not incompatible with LLVM. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/57a5410d/attachment-0001.html>

From jay.krell at cornell.edu  Sun May 20 23:34:20 2012
From: jay.krell at cornell.edu (Jay)
Date: Sun, 20 May 2012 14:34:20 -0700
Subject: [M3devel] more Debian packages?
In-Reply-To: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>
References: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>
Message-ID: <05B9609B-9A70-405A-9A59-4D3896AAD28F@gmail.com>

No Daniel. 

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 19, 2012, at 11:32 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
>  I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,
> for instance to allow and or LINUX_I8086, etc LINUX_I387 
> For VAXen computers:
> VMS_VAX__
> for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11
> Alpha's: OSF_ALPHA
> For Unixes:
> FBSD-GENERIC_I_86___--
> To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64
> Also could be managed by Manufacturer Model code-name, like
> DEC_AQUARIUS or DEC_10000.
> 
> Also if we are gonna take macro assembly for cross-platform distributions then, we would need  something akin:
> NT_XASM-I_86___
> So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)
> 
> This would allow to compile CVSup at least is what one would like to
> Thanks in advance
> 
> --- El vie, 18/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] more Debian packages?
> Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 18 de mayo, 2012 16:50
> 
> Yes and yes.
> LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.
> But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.
>  
>  
> Please try to use I386_LINUX.
> I really want to stop this LINUXLIBC6 stuff...
>  
>  
>  You can share the source.
>  But we also have outputs in the source tree (unfortunately!).
>     You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...
>  
>  
>  Do this to switch:
>  
>  ./do-cm3-all.py realclean 
>  
>  - Jay
>  
> > Date: Fri, 18 May 2012 16:56:49 -0400
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] more Debian packages?
> > 
> > Having succeeded at producing a binary .deb packages for Debian squeeze 
> > (though I still have to try it out), I'm now looking at my other 
> > machines. I have a 32-bit Intel machine with wheeze (testing), and one 
> > that can run squeeze (stable). All of them have access to the same 
> > NFS-mounted source tree. Is it practical to use the same tree for two 
> > different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> > be kept separate? Or do I need to clean it out or copy it?
> > 
> > (by the way, I expect making packages for different Debian releases on 
> > the same hardware architecture will require a new source tree, or a 
> > cleaned-out one. In my case they'll both be LINUXLIBC6)
> > 
> > -- hendrik
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/9edf6c44/attachment-0001.html>

From jay.krell at cornell.edu  Sun May 20 23:32:14 2012
From: jay.krell at cornell.edu (Jay)
Date: Sun, 20 May 2012 14:32:14 -0700
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
Message-ID: <C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>

I meant "gcc frontends", which Modula-3 is structured as, in a somewhat backward-seeming way.


Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 20, 2012, at 2:28 PM, Jay <jay.krell at cornell.edu> wrote:

> Normally gcc compilers


From jay.krell at cornell.edu  Sun May 20 23:43:52 2012
From: jay.krell at cornell.edu (Jay)
Date: Sun, 20 May 2012 14:43:52 -0700
Subject: [M3devel] more Debian packages?
In-Reply-To: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>
References: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>
Message-ID: <B05C5D37-CAE3-4271-80EF-EBB2627444D4@gmail.com>

No no no.
We will not have an explosion of targets like this. We hopefully will have a drastic reduction.
Processor: C or C++
Threads: pthreads or Win32 or maybe ucontext or setjmp
GUI: X Windows or Win32 or none or maybe other
Suspension: cooperative and probably no other


If the right level of #ifdef and/or autoconf and/or libtool use can makes its way into the "object code", maybe just target completely. (imagine one C source distribution for ALL targets and what that requires).
We have rather replaced autoconf & libtool with our carefully researched & written quake code, for better & worse & I am torn as to if this is a good thing. Autoconf & libtool are slow & obscure but ubiquitous, get the job done, are actively maintained by others.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 19, 2012, at 11:32 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
>  I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,
> for instance to allow and or LINUX_I8086, etc LINUX_I387 
> For VAXen computers:
> VMS_VAX__
> for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11
> Alpha's: OSF_ALPHA
> For Unixes:
> FBSD-GENERIC_I_86___--
> To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64
> Also could be managed by Manufacturer Model code-name, like
> DEC_AQUARIUS or DEC_10000.
> 
> Also if we are gonna take macro assembly for cross-platform distributions then, we would need  something akin:
> NT_XASM-I_86___
> So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)
> 
> This would allow to compile CVSup at least is what one would like to
> Thanks in advance
> 
> --- El vie, 18/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] more Debian packages?
> Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 18 de mayo, 2012 16:50
> 
> Yes and yes.
> LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.
> But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.
>  
>  
> Please try to use I386_LINUX.
> I really want to stop this LINUXLIBC6 stuff...
>  
>  
>  You can share the source.
>  But we also have outputs in the source tree (unfortunately!).
>     You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...
>  
>  
>  Do this to switch:
>  
>  ./do-cm3-all.py realclean 
>  
>  - Jay
>  
> > Date: Fri, 18 May 2012 16:56:49 -0400
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] more Debian packages?
> > 
> > Having succeeded at producing a binary .deb packages for Debian squeeze 
> > (though I still have to try it out), I'm now looking at my other 
> > machines. I have a 32-bit Intel machine with wheeze (testing), and one 
> > that can run squeeze (stable). All of them have access to the same 
> > NFS-mounted source tree. Is it practical to use the same tree for two 
> > different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> > be kept separate? Or do I need to clean it out or copy it?
> > 
> > (by the way, I expect making packages for different Debian releases on 
> > the same hardware architecture will require a new source tree, or a 
> > cleaned-out one. In my case they'll both be LINUXLIBC6)
> > 
> > -- hendrik
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/5fe49c86/attachment-0001.html>

From dabenavidesd at yahoo.es  Mon May 21 01:25:38 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 21 May 2012 00:25:38 +0100 (BST)
Subject: [M3devel] more Debian packages?
In-Reply-To: <B05C5D37-CAE3-4271-80EF-EBB2627444D4@gmail.com>
Message-ID: <1337556338.98126.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I got your point, but even after that the need for product-quality inter-opeartion with C code, specially, because everything else in the market is C, is desperately needed, we don't have some framework to actually using code from C-RT as is. I know DEC somehow lacked more effort towards producing for us that, although C interoperability was very good, they studied the problem for C and Modula-3, which is nice, and also I think they worked in their GEM compiler for Fortran, Cobol, C, .. so they should used basic concepts like 'program cell' for those compilers.
That said I know of an incremental code generator and linker for typeful programming languages for database machines, so I know producing some compiler target wouldn't be hard so much work like currently we had to even when there are many languages that we would match, say SQL, etc. 

Thanks in advance

--- El dom, 20/5/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] more Debian packages?
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "<hendrik at topoi.pooq.com>" <hendrik at topoi.pooq.com>, "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: domingo, 20 de mayo, 2012 16:43

No no no.We will not have an explosion of targets like this. We hopefully will have a drastic reduction.Processor: C or C++Threads: pthreads or Win32 or maybe ucontext or setjmpGUI: X Windows or Win32 or none or maybe otherSuspension: cooperative and probably no other

If the right level of #ifdef and/or autoconf and/or libtool use can makes its way into the "object code", maybe just target completely. (imagine one C source distribution for ALL targets and what that requires).We have rather replaced autoconf & libtool with our carefully researched & written quake code, for better & worse & I am torn as to if this is a good thing. Autoconf & libtool are slow & obscure but ubiquitous, get the job done, are actively maintained by others.

?- Jay (briefly/pocket-sized-computer-aka-phone)
On May 19, 2012, at 11:32 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:

?I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,

for instance to allow and or LINUX_I8086, etc LINUX_I387 

For VAXen computers:

VMS_VAX__

for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11

Alpha's: OSF_ALPHA

For Unixes:

FBSD-GENERIC_I_86___--

To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64

Also could be managed by Manufacturer Model code-name, like

DEC_AQUARIUS or DEC_10000.



Also if we are gonna take macro assembly for cross-platform distributions then, we would need? something akin:

NT_XASM-I_86___

So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)

This would allow to compile CVSup at least is what one would like to
Thanks in advance

 --- El vie, 18/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] more Debian packages?
Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 18 de mayo, 2012 16:50




Yes and yes.
LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.
But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.
?
?
Please try to use I386_LINUX.
I really want to stop this LINUXLIBC6 stuff...
?
?
?You can share the source.
?But we also have outputs in the source tree (unfortunately!).
??? You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...
?
?
?Do this to switch:
?
?./do-cm3-all.py realclean 
?
?- Jay
?
> Date: Fri, 18 May 2012 16:56:49 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] more Debian packages?
> 
> Having succeeded at producing a binary .deb packages for Debian squeeze 
> (though I still have to try it out), I'm now looking at my other 
> machines.  I have a 32-bit Intel machine with wheeze (testing), and one 
> that can run squeeze (stable).  All of them have access to the same 
> NFS-mounted source tree.  Is it practical to use the same tree for two 
> different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> be kept separate?  Or do I need to clean it out or copy it?
> 
> (by the way, I expect making packages for different Debian releases on 
> the same hardware architecture will require a new source tree, or a 
> cleaned-out one.  In my case they'll
 both be LINUXLIBC6)
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120521/976f78b7/attachment-0001.html>

From jay.krell at cornell.edu  Mon May 21 09:50:49 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 May 2012 07:50:49 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>,
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>,
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
Message-ID: <COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>


My point was a bit different -- an interpreter could easily be built from the current intermediate representation.
But heck, then again, the frontend is fast..build an interpreter over source?
Well..hm..actually it might not be fast enough.
This gets rambly/philosophical fast...static checking is useful, but when do you do it?
"static and dynamic are relative".
Before the program runs? Every time before it runs?
When/where do you "save away" decisions/checks that have been made, to avoid them on repeat visits?

Nevermind..I'm not making a clear point..


?- Jay

________________________________
> Subject: Re: [M3devel] LINUXLIBC6 
> From: dragisha at m3w.org 
> Date: Sun, 20 May 2012 22:11:39 +0200 
> CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com 
> To: jay.krell at cornell.edu 
>  
>  
> On May 18, 2012, at 9:49 PM, Jay K wrote: 
>  
> LLVM isn't a bad idea, but there is more expertise out there (and in  
> me) with C and C++, so C and C++ are easier to generate. 
> It is a bit of a chore to learn and use. 
>  
>  
> JIT isn't a crazy idea either..or rather, an interpreter. 
> If you look at parse.c..and you add a few thread locals..I think it's  
> not hard to turn it into an interpreter. 
>    (In reality you don't want to start with parse.c because of the GPL.) 
>  
> LLVM and JIT are close enough. You do LLVM, you get JIT. 
>  
> Also, for debugging we need DWARF. Not incompatible with LLVM. 
 		 	   		  

From dragisha at m3w.org  Mon May 21 10:00:04 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 21 May 2012 10:00:04 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
	<C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>
Message-ID: <08D7AEDF-8B13-4139-B059-4EC66975AD9B@m3w.org>

And why would you/we do it? To be less portable? To escape direct knowledge of endian/word_size/jmpbuf/whatever by cpp and run into C/C++/Java?


On May 20, 2012, at 11:32 PM, Jay wrote:

> I meant "gcc frontends", which Modula-3 is structured as, in a somewhat backward-seeming way.
> 
> 
> Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.
> 
> 
> - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On May 20, 2012, at 2:28 PM, Jay <jay.krell at cornell.edu> wrote:
> 
>> Normally gcc compilers



From dragisha at m3w.org  Mon May 21 10:02:11 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 21 May 2012 10:02:11 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
Message-ID: <721848E0-B0C2-4C51-BD37-1A4BA9A58E7C@m3w.org>

You can't generate reasonable stabs based debug info and expect it to survive optimization steps. DWARF is another thing, optimizer gets data to work on, as well as code. DWARF decorations have a chance to survive optimizations. Stabs, esp heavily idiosyncratic ones - do not.

On May 20, 2012, at 11:28 PM, Jay wrote:

> For dwarf et al: there "nothing" to it: "just" generate reasonable "code" (LLVM whatever, gcc "tree", C, etc) and the next level down handles it. Er, but for some bigger & smaller problems. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120521/04223a33/attachment-0001.html>

From jay.krell at cornell.edu  Mon May 21 10:38:37 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 May 2012 08:38:37 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <721848E0-B0C2-4C51-BD37-1A4BA9A58E7C@m3w.org>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>,
	<721848E0-B0C2-4C51-BD37-1A4BA9A58E7C@m3w.org>
Message-ID: <COL101-W588C5940AE8A443065C0C9E61D0@phx.gbl>


Again, stabs in the context of Modula-3/cm3cg/m3gdb I believe has almost nothing to do with stabs in any other "normal" context.
We use it just to transport our own custom data.
That data may or may not be compromised by optimization.


For example, what are the types of parameters to functions?
Assuming the optimizer does not change the signature of any function?


This data is NOT available at all to stock gdb for Modula-3.
It is available to m3gdb via a completely custom/private data form.


And by "types" here, I mean pretty complete information -- if records are involved,
then all their fields are described.


It is likely the case that on systems that don't support stabs (MacOSX/Darwin), the custom data
could be transported via some other mechanism. Heck, put it in data files on the side.


ok ok, the data does have *something* to do with stabs, but not much.
e.g. that function signature is associated with a function at some address/offset.


Line number information is presumably represented in dwarf/stabs/coff "natively" via gcc's normal paths,
as we do give gcc source line information (at least mostly).


It is when you go beyond mere line number information where things are different.


?- Jay



________________________________
> Subject: Re: [M3devel] LINUXLIBC6 
> From: dragisha at m3w.org 
> Date: Mon, 21 May 2012 10:02:11 +0200 
> CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com 
> To: jay.krell at cornell.edu 
>  
> You can't generate reasonable stabs based debug info and expect it to  
> survive optimization steps. DWARF is another thing, optimizer gets data  
> to work on, as well as code. DWARF decorations have a chance to survive  
> optimizations. Stabs, esp heavily idiosyncratic ones - do not. 
>  
> On May 20, 2012, at 11:28 PM, Jay wrote: 
>  
> For dwarf et al: there "nothing" to it: "just" generate reasonable  
> "code" (LLVM whatever, gcc "tree", C, etc) and the next level down  
> handles it. Er, but for some bigger & smaller problems. 
>  
 		 	   		  

From jay.krell at cornell.edu  Mon May 21 10:40:25 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 May 2012 08:40:25 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <08D7AEDF-8B13-4139-B059-4EC66975AD9B@m3w.org>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
	<C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>,
	<08D7AEDF-8B13-4139-B059-4EC66975AD9B@m3w.org>
Message-ID: <COL101-W25AC411E4510D3BE846C95E61D0@phx.gbl>


To be more portable, and get out of the "problem" of being self-hosting.
I realize self-hosting has major benefits too.
Someone just needs to see if Debian et. al. have a general story for compilers that compile themselves.
And I need to really implement the C backend I talk forever and ever about....


?- Jay


----------------------------------------
> Subject: Re: [M3devel] LINUXLIBC6
> From: dragisha at m3w.org
> Date: Mon, 21 May 2012 10:00:04 +0200
> CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> And why would you/we do it? To be less portable? To escape direct knowledge of endian/word_size/jmpbuf/whatever by cpp and run into C/C++/Java?
>
>
> On May 20, 2012, at 11:32 PM, Jay wrote:
>
> > I meant "gcc frontends", which Modula-3 is structured as, in a somewhat backward-seeming way.
> >
> >
> > Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.
> >
> >
> > - Jay (briefly/pocket-sized-computer-aka-phone)
> >
> > On May 20, 2012, at 2:28 PM, Jay <jay.krell at cornell.edu> wrote:
> >
> >> Normally gcc compilers
>
 		 	   		  

From dragisha at m3w.org  Mon May 21 13:17:44 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 21 May 2012 13:17:44 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W25AC411E4510D3BE846C95E61D0@phx.gbl>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
	<C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>,
	<08D7AEDF-8B13-4139-B059-4EC66975AD9B@m3w.org>
	<COL101-W25AC411E4510D3BE846C95E61D0@phx.gbl>
Message-ID: <1CDC02DA-54C1-43ED-9737-4BCA39C4E87B@m3w.org>

Once it was a big thing for Modula-3 to become self-hosted.

Now, step forward is to undo that :).

I understand - you feel better with (well known and full commanded) C/C++ than with (mostly unknown LLVM). I only hope you will use current provisions of Modula-3 system to implement C/C++ backend in same fashion (using CG* object hierarchy) as other current backends are implemented. That way, someone can go LLVM without changing GCC based backend, or fast Win32 backend, or your future C/C++ backend.

On May 21, 2012, at 10:40 AM, Jay K wrote:

> 
> To be more portable, and get out of the "problem" of being self-hosting.
> I realize self-hosting has major benefits too.
> Someone just needs to see if Debian et. al. have a general story for compilers that compile themselves.
> And I need to really implement the C backend I talk forever and ever about....
> 
> 
>  - Jay
> 
> 
> ----------------------------------------
>> Subject: Re: [M3devel] LINUXLIBC6
>> From: dragisha at m3w.org
>> Date: Mon, 21 May 2012 10:00:04 +0200
>> CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> And why would you/we do it? To be less portable? To escape direct knowledge of endian/word_size/jmpbuf/whatever by cpp and run into C/C++/Java?
>> 
>> 
>> On May 20, 2012, at 11:32 PM, Jay wrote:
>> 
>>> I meant "gcc frontends", which Modula-3 is structured as, in a somewhat backward-seeming way.
>>> 
>>> 
>>> Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.
>>> 
>>> 
>>> - Jay (briefly/pocket-sized-computer-aka-phone)
>>> 
>>> On May 20, 2012, at 2:28 PM, Jay <jay.krell at cornell.edu> wrote:
>>> 
>>>> Normally gcc compilers
>> 
> 		 	   		  



From hendrik at topoi.pooq.com  Mon May 21 20:43:17 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 14:43:17 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
Message-ID: <20120521184316.GA10750@topoi.pooq.com>

On Mon, May 21, 2012 at 07:50:49AM +0000, Jay K wrote:
> 
> Nevermind..I'm not making a clear point..

Maybe this point will do:

So regardless of whether the production compiler generates machine code 
or anythine else, it would be possible to have a single, portable 
interpreter written in C to use as a bootstrap tool to avoid having to 
bootstrap from machine-dependent machine code whenever installing (or 
packaging) foor another platform?  The build-dependency of the real 
Modula 3 compiler could then be itself OR the interpreter.

And the interpreter could be made to interpret some kind of efficient, 
intermediate code that is easy to interpret fast.  Does the existing 
codebase have anything that sould be used for this?  OR could easily be 
changed into this?

-- hendrik


From hendrik at topoi.pooq.com  Mon May 21 23:10:45 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 17:10:45 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <20120521184316.GA10750@topoi.pooq.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
	<20120521184316.GA10750@topoi.pooq.com>
Message-ID: <20120521211045.GA7596@topoi.pooq.com>

On Mon, May 21, 2012 at 02:43:17PM -0400, Hendrik Boom wrote:
> On Mon, May 21, 2012 at 07:50:49AM +0000, Jay K wrote:
> > 
> > Nevermind..I'm not making a clear point..
> 
> Maybe this point will do:
> 
> So regardless of whether the production compiler generates machine code 
> or anythine else, it would be possible to have a single, portable 
> interpreter written in C to use as a bootstrap tool to avoid having to 
> bootstrap from machine-dependent machine code whenever installing (or 
> packaging) foor another platform?  The build-dependency of the real 
> Modula 3 compiler could then be itself OR the interpreter.
> 
> And the interpreter could be made to interpret some kind of efficient, 
> intermediate code that is easy to interpret fast.  Does the existing 
> codebase have anything that sould be used for this?  OR could easily be 
> changed into this?
> 
> -- hendrik

C--, I believe, is implemented as a compiler for several platforms, and 
also as an interpreter.  So generating C-- code would satisfy our 
requirements for a bootstrap.  If we want to hook into a run-time 
system that has at least thought seriously about the issues of 
garbage-collection and stack-walking, this might be it.  But I don't 
know to what extent these essential features have beein implemented. 

OCAML also had an interpreter and compilers to several machine codes.  
This would seem to be a viable mechanism.

I've been using an OCAML-written Algol W compiler using the interpreted 
OCAML implementation, and it still compiles Algol W to C faster than 
the C compiler translates its output code to machine code. 

-- hendrik




From jay.krell at cornell.edu  Tue May 22 00:50:44 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 May 2012 22:50:44 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <20120521211045.GA7596@topoi.pooq.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>,
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>,
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>,
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>,
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>,
	<20120521184316.GA10750@topoi.pooq.com>,
	<20120521211045.GA7596@topoi.pooq.com>
Message-ID: <COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>


Is C-- adequately maintained? I don't think so.
I'm also not super keen on depending on other projects.
We'll see..


Regarding runtime designed for garbage collection... in the interest of simplicity, correctness,
and laziness-ignoring-performance, I'd initially try something like this:

?- don't optimize, or at least make all writes volatile 
?? or make everything volatile 
While currently we have some support for the gcc optimizer, and we don't make everything volatile,
we also had a long history of using a lot of volatile. I think nobody but me and possibly Tony
noticed the poor codegen and probably
?
?- form all frames as structs 
? - so that the frame layout can be known by the frontend


We already do something similar to the last, I think.


One of the wierd points here..and I really really really really have to get on and code instead of talk,
is "what our C would look like".
It would look strange.


Consider all the inserted "probes" (I forget what they are called).
Consider as I said that there are no field references from the backend's point of view, just variable + offset + cast.


Anyway..later...


?- Jay



----------------------------------------
> Date: Mon, 21 May 2012 17:10:45 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] LINUXLIBC6
>
> On Mon, May 21, 2012 at 02:43:17PM -0400, Hendrik Boom wrote:
> > On Mon, May 21, 2012 at 07:50:49AM +0000, Jay K wrote:
> > >
> > > Nevermind..I'm not making a clear point..
> >
> > Maybe this point will do:
> >
> > So regardless of whether the production compiler generates machine code
> > or anythine else, it would be possible to have a single, portable
> > interpreter written in C to use as a bootstrap tool to avoid having to
> > bootstrap from machine-dependent machine code whenever installing (or
> > packaging) foor another platform? The build-dependency of the real
> > Modula 3 compiler could then be itself OR the interpreter.
> >
> > And the interpreter could be made to interpret some kind of efficient,
> > intermediate code that is easy to interpret fast. Does the existing
> > codebase have anything that sould be used for this? OR could easily be
> > changed into this?
> >
> > -- hendrik
>
> C--, I believe, is implemented as a compiler for several platforms, and
> also as an interpreter. So generating C-- code would satisfy our
> requirements for a bootstrap. If we want to hook into a run-time
> system that has at least thought seriously about the issues of
> garbage-collection and stack-walking, this might be it. But I don't
> know to what extent these essential features have beein implemented.
>
> OCAML also had an interpreter and compilers to several machine codes.
> This would seem to be a viable mechanism.
>
> I've been using an OCAML-written Algol W compiler using the interpreted
> OCAML implementation, and it still compiles Algol W to C faster than
> the C compiler translates its output code to machine code.
>
> -- hendrik
>
>
 		 	   		  

From dabenavidesd at yahoo.es  Tue May 22 02:47:59 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 22 May 2012 01:47:59 +0100 (BST)
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
Message-ID: <1337647679.52945.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all: 
none interpreter product I have seen lately, that tries such a way C, I know there was a product of 25+ years called C-terp, but they don't do it anymore.  
I don't think they just tried to debug code and safely execute but execute it safely and prudently fast but none else have seemingly been keen to that, so if they thought was a good idea way before all this, I guess we can try to do that. Seems a good one. Which compiler does that, just C--?
They distributed some gcc freely and had MS VS4 versions and all of that.
Thanks in advance


--- El lun, 21/5/12, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] LINUXLIBC6
> Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 21 de mayo, 2012 17:50
> 
> Is C-- adequately maintained? I don't think so.
> I'm also not super keen on depending on other projects.
> We'll see..
> 
> 
> Regarding runtime designed for garbage collection... in the
> interest of simplicity, correctness,
> and laziness-ignoring-performance, I'd initially try
> something like this:
> 
> ?- don't optimize, or at least make all writes volatile 
> ?? or make everything volatile 
> While currently we have some support for the gcc optimizer,
> and we don't make everything volatile,
> we also had a long history of using a lot of volatile. I
> think nobody but me and possibly Tony
> noticed the poor codegen and probably
> ?
> ?- form all frames as structs 
> ? - so that the frame layout can be known by the frontend
> 
> 
> We already do something similar to the last, I think.
> 
> 
> One of the wierd points here..and I really really really
> really have to get on and code instead of talk,
> is "what our C would look like".
> It would look strange.
> 
> 
> Consider all the inserted "probes" (I forget what they are
> called).
> Consider as I said that there are no field references from
> the backend's point of view, just variable + offset + cast.
> 
> 
> Anyway..later...
> 
> 
> ?- Jay
> 
> 
> 
> ----------------------------------------
> > Date: Mon, 21 May 2012 17:10:45 -0400
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] LINUXLIBC6
> >
> > On Mon, May 21, 2012 at 02:43:17PM -0400, Hendrik Boom
> wrote:
> > > On Mon, May 21, 2012 at 07:50:49AM +0000, Jay K
> wrote:
> > > >
> > > > Nevermind..I'm not making a clear point..
> > >
> > > Maybe this point will do:
> > >
> > > So regardless of whether the production compiler
> generates machine code
> > > or anythine else, it would be possible to have a
> single, portable
> > > interpreter written in C to use as a bootstrap
> tool to avoid having to
> > > bootstrap from machine-dependent machine code
> whenever installing (or
> > > packaging) foor another platform? The
> build-dependency of the real
> > > Modula 3 compiler could then be itself OR the
> interpreter.
> > >
> > > And the interpreter could be made to interpret
> some kind of efficient,
> > > intermediate code that is easy to interpret fast.
> Does the existing
> > > codebase have anything that sould be used for
> this? OR could easily be
> > > changed into this?
> > >
> > > -- hendrik
> >
> > C--, I believe, is implemented as a compiler for
> several platforms, and
> > also as an interpreter. So generating C-- code would
> satisfy our
> > requirements for a bootstrap. If we want to hook into a
> run-time
> > system that has at least thought seriously about the
> issues of
> > garbage-collection and stack-walking, this might be it.
> But I don't
> > know to what extent these essential features have beein
> implemented.
> >
> > OCAML also had an interpreter and compilers to several
> machine codes.
> > This would seem to be a viable mechanism.
> >
> > I've been using an OCAML-written Algol W compiler using
> the interpreted
> > OCAML implementation, and it still compiles Algol W to
> C faster than
> > the C compiler translates its output code to machine
> code.
> >
> > -- hendrik
> >
> >
>  ???
> ????????
> ?????? ???
> ? 


From hendrik at topoi.pooq.com  Tue May 22 04:44:55 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 22:44:55 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
	<20120521184316.GA10750@topoi.pooq.com>
	<20120521211045.GA7596@topoi.pooq.com>
	<COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
Message-ID: <20120522024455.GA9667@topoi.pooq.com>

On Mon, May 21, 2012 at 10:50:44PM +0000, Jay K wrote:
> 
> Is C-- adequately maintained? I don't think so.

Bugs get fixed.  And there's very few of them reported.  But it's not 
clear to me whether that's because it's so well-written, or because 
almost no one uses it.

Active development seems to be at a stendstill.

> I'm also not super keen on depending on other projects.
> We'll see..

I mentioned C-- because its implementation exists in both interpreted 
and compiled versions.  That seems to be a way to bootstrap the whole 
thing.  We could interpret the compiler using some portable 
intermediate code -- we could even restrict the interpreter to provide 
only a 32-bit machine, and then cross-compile from the interpreted 
compiler to whatever machine we're installing on.  Since every Modula 
3 compiler seems to be able to generate code for every platform, 
this is a way to avoid having a separate binary bootstrap for every 
platform.

And a distro, like Debian, could have a source package that doesn't 
need to have itself installed before it it can be installed.

-- hendrik

> 
> 
> Regarding runtime designed for garbage collection... in the interest of simplicity, correctness,
> and laziness-ignoring-performance, I'd initially try something like this:
> 
> ?- don't optimize, or at least make all writes volatile 
> ?? or make everything volatile 
> While currently we have some support for the gcc optimizer, and we don't make everything volatile,
> we also had a long history of using a lot of volatile. I think nobody but me and possibly Tony
> noticed the poor codegen and probably
> ?
> ?- form all frames as structs 
> ? - so that the frame layout can be known by the frontend
>
> 
> 
> We already do something similar to the last, I think.
> 
> 
> One of the wierd points here..and I really really really really have to get on and code instead of talk,
> is "what our C would look like".
> It would look strange.
> 
> 
> Consider all the inserted "probes" (I forget what they are called).
> Consider as I said that there are no field references from the 
> backend's point of view, just variable + offset + cast.

That's basically the  way that C-- accesses memory.

-- hendrik


From hendrik at topoi.pooq.com  Tue May 22 04:57:50 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 22:57:50 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <1337647679.52945.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
	<1337647679.52945.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <20120522025750.GB9667@topoi.pooq.com>

On Tue, May 22, 2012 at 01:47:59AM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all: 
> none interpreter product I have seen lately, that tries such a way C, I know there was a product of 25+ years called C-terp, but they don't do it anymore.  
> I don't think they just tried to debug code and safely execute but execute it safely and prudently fast but none else have seemingly been keen to that, so if they thought was a good idea way before all this, I guess we can try to do that. Seems a good one. Which compiler does that, just C--?

I think OCaml did an interpreter-compiler combination, whhere one 
could be used to implement the other.  Though I'm not sure.

I worked on C and C++ interpreters once.  All proprietary, 
unfortunately.

Gambit-C is a compiler from Scheme to C.  It's written in its own 
language, and it also provides an interpreter for its own language,
also written in Scheme and compiled to C, I believe.  It manages to do 
an efficient implementation of continuations despite running in C.

> They distributed some gcc freely and had MS VS4 versions and all of that.
> Thanks in advance

-- hendrik


From hendrik at topoi.pooq.com  Tue May 22 05:32:16 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 23:32:16 -0400
Subject: [M3devel] use of LLVM
In-Reply-To: <1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <20120522033216.GC9667@topoi.pooq.com>

On Fri, May 18, 2012 at 06:16:59PM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all:
> After ESC we do need much debugger at all, in fact it was designed for that for avoiding put much time on it.
> Still if we generate C is for super-optimization (but verified also mechanically), so I don't mind that, but for code quality I prefer C, I agree absolutely in that we should support it again for that purpose (as originally).
> As for not verified code we should stick with C--, as it is written for that purposes, but for portability specially with implicit safety.
> And for not verified nor optimal and not common use code (like mentor) we should make them source packages (in fact If they are written in Obliq we don't want to redistribute that as non-source), instead part of m3-demo package subdirectory or so.
> I think for M3CG is that we need a LLVM or so back-end for JIT.

The problem I had with LLVM for Algol 68 was that I couldn't use a type 
before it was completely defined.  THis means that there are stark 
constraints on the use of incomplete types.  I wanted to build a 
structure to represent a stack frame, containing local variables and 
the like, and having the field offsets afailable for type descriptors 
for the garbage collector.  But even though LLVM could have computed 
field offsets along the way, as they were contributed to the structure, 
instead it decided to diallow all use of the structure until its 
definition was complete.  UNfortunately, I didn't know what all the 
fields would be until I got to finish generating the code that used the 
stack frame.

This was a restriction in using LLVM as a JIT.  You get to build the 
LLVM abstract syntax in pretty well any order you want, sticking extra 
bits in here, there, everywhere, except for this one bizarre 
restriction.  I have to build all the abstract syntax for a type 
definition before I can refer to any of it elsewhere in the parse tree.  
Well, thare are a few exceptions for defining recursive types, but they 
don't do enough to make this work.

It's different when writing LLVM code as an ASCII text file.  Then you 
can write out the type definitions on one file and the code that uses 
then in an other file, and cocatenate them before passing them too 
LLVM.

Mind you that's not a lot worse than in C--, where you *have* to write 
out text file (and I do write it out of order).  But it irks to 
have the entire LLVM JIT interface reduced to uselessness.  At least 
with C-- you're not *expecting* to get a JIT.

-- hendrik


From dragisha at m3w.org  Tue May 22 10:59:24 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 22 May 2012 10:59:24 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
Message-ID: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>


***
*** runtime error:
***    <*ASSERT*> failed.
***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
***
...
#17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
    at ../src/thread/PTHREAD/ThreadPThread.m3:586
#18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
#19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
?

And so on? Looks like I reported this earlier, here: 

https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html

Any progress? Maybe I missed something.

dd




From lemming at henning-thielemann.de  Tue May 22 10:45:24 2012
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 22 May 2012 10:45:24 +0200 (CEST)
Subject: [M3devel] use of LLVM
In-Reply-To: <20120522033216.GC9667@topoi.pooq.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<20120522033216.GC9667@topoi.pooq.com>
Message-ID: <alpine.DEB.2.00.1205221044001.12948@anubis.informatik.uni-halle.de>


On Mon, 21 May 2012, Hendrik Boom wrote:

> The problem I had with LLVM for Algol 68 was that I couldn't use a type
> before it was completely defined.  THis means that there are stark
> constraints on the use of incomplete types.  I wanted to build a
> structure to represent a stack frame, containing local variables and
> the like, and having the field offsets afailable for type descriptors
> for the garbage collector.  But even though LLVM could have computed
> field offsets along the way, as they were contributed to the structure,
> instead it decided to diallow all use of the structure until its
> definition was complete.  UNfortunately, I didn't know what all the
> fields would be until I got to finish generating the code that used the
> stack frame.

I thought that you can disable pointer type checking completely by using 
i8* and cast it forth and back as you need it.


From dragisha at m3w.org  Tue May 22 17:16:30 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 22 May 2012 17:16:30 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
In-Reply-To: <E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
Message-ID: <16020041-89DE-47A7-AD6C-A04ECAB9991D@m3w.org>

This is 5.8.6 release code. You probably did not read a message I referenced.

On May 22, 2012, at 4:59 PM, Antony Hosking wrote:

> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
> 
> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
> 
>> 
>> ***
>> *** runtime error:
>> ***    <*ASSERT*> failed.
>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>> ***
>> ...
>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>   at ../src/thread/PTHREAD/ThreadPThread.m3:586
>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>> ?
>> 
>> And so on? Looks like I reported this earlier, here: 
>> 
>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>> 
>> Any progress? Maybe I missed something.
>> 
>> dd
>> 
>> 
> 



From dragisha at m3w.org  Tue May 22 17:23:31 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 22 May 2012 17:23:31 +0200
Subject: [M3devel]
 =?windows-1252?q?pthreads_problem=2C_LINUXLIBC6=2C_RHEL?=
 =?windows-1252?q?_5=2E8=85_random_observation?=
In-Reply-To: <16020041-89DE-47A7-AD6C-A04ECAB9991D@m3w.org>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
	<16020041-89DE-47A7-AD6C-A04ECAB9991D@m3w.org>
Message-ID: <D1D53D02-1EC9-4227-96DF-A245B5988F6A@m3w.org>

<* ASSERT r = 0 *>

is probably better as:

IF r # 0 THEN
  <* DEBUG "r = " & Fmt.Int? *>
  <* ASSERT FALSE *>
END;

On May 22, 2012, at 5:16 PM, Dragi?a Duri? wrote:

> This is 5.8.6 release code. You probably did not read a message I referenced.
> 
> On May 22, 2012, at 4:59 PM, Antony Hosking wrote:
> 
>> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
>> 
>> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
>> 
>>> 
>>> ***
>>> *** runtime error:
>>> ***    <*ASSERT*> failed.
>>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>>> ***
>>> ...
>>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>>  at ../src/thread/PTHREAD/ThreadPThread.m3:586
>>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>>> ?
>>> 
>>> And so on? Looks like I reported this earlier, here: 
>>> 
>>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>>> 
>>> Any progress? Maybe I missed something.
>>> 
>>> dd
>>> 
>>> 
>> 
> 



From hendrik at topoi.pooq.com  Tue May 22 17:56:51 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Tue, 22 May 2012 11:56:51 -0400
Subject: [M3devel] use of LLVM
In-Reply-To: <alpine.DEB.2.00.1205221044001.12948@anubis.informatik.uni-halle.de>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<20120522033216.GC9667@topoi.pooq.com>
	<alpine.DEB.2.00.1205221044001.12948@anubis.informatik.uni-halle.de>
Message-ID: <20120522155651.GA12326@topoi.pooq.com>

On Tue, May 22, 2012 at 10:45:24AM +0200, Henning Thielemann wrote:
> 
> On Mon, 21 May 2012, Hendrik Boom wrote:
> 
> >The problem I had with LLVM for Algol 68 was that I couldn't use a type
> >before it was completely defined.  THis means that there are stark
> >constraints on the use of incomplete types.  I wanted to build a
> >structure to represent a stack frame, containing local variables and
> >the like, and having the field offsets afailable for type descriptors
> >for the garbage collector.  But even though LLVM could have computed
> >field offsets along the way, as they were contributed to the structure,
> >instead it decided to diallow all use of the structure until its
> >definition was complete.  UNfortunately, I didn't know what all the
> >fields would be until I got to finish generating the code that used the
> >stack frame.
> 
> I thought that you can disable pointer type checking completely by
> using i8* and cast it forth and back as you need it.

But I still can't generate code that does anything more than mention 
these types until they are completely defined.  I can't make the 
abtstract syntax tree for sizeof(foo) before I've completed the 
definition of foo.  I can't mention any of the field names until I've 
completed the definition of foo....

Yes, i8* might get around some limitations, if I do all the field 
offset calculations myself and embed the numbers in the generated 
code.  But that's not how LLVM is supposed to work.  It's supposed to 
be rather more machine-independent than that.

-- hendrik


From dragisha at m3w.org  Tue May 22 18:20:35 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 22 May 2012 18:20:35 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
In-Reply-To: <39DE377C-56A0-4F0F-B459-1E8953F889B8@gmail.com>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
	<16020041-89DE-47A7-AD6C-A04ECAB9991D@m3w.org>
	<39DE377C-56A0-4F0F-B459-1E8953F889B8@gmail.com>
Message-ID: <F72BE040-3ABC-4FB0-8EC6-96C70A92FC39@m3w.org>

Probably :)

I just tried to rebuild cm3-5.8.6 on this system, from source. Same problem.

I will try some 5.9.* next.

Interim release would be good idea. If only we can have functional m3gdb? gcc version used is not priority, to me.

On May 22, 2012, at 5:43 PM, Antony Hosking wrote:

> The release contains a number of known problems.
> Time for an interim release?
> 
> 
> On May 22, 2012, at 11:16 AM, Dragi?a Duri? wrote:
> 
>> This is 5.8.6 release code. You probably did not read a message I referenced.
>> 
>> On May 22, 2012, at 4:59 PM, Antony Hosking wrote:
>> 
>>> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
>>> 
>>> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
>>> 
>>>> 
>>>> ***
>>>> *** runtime error:
>>>> ***    <*ASSERT*> failed.
>>>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>>>> ***
>>>> ...
>>>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>>> at ../src/thread/PTHREAD/ThreadPThread.m3:586
>>>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>>>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>>>> ?
>>>> 
>>>> And so on? Looks like I reported this earlier, here: 
>>>> 
>>>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>>>> 
>>>> Any progress? Maybe I missed something.
>>>> 
>>>> dd
>>>> 
>>>> 
>>> 
>> 
> 



From dragisha at m3w.org  Wed May 23 10:36:05 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 23 May 2012 10:36:05 +0200
Subject: [M3devel] cm3, NOPTHREAD
Message-ID: <9E51EE23-0A0E-459F-BC97-9CC447728A2A@m3w.org>

Anyone made cm3 with -DNOPTHREAD ? 5.8.6 release version.


From dragisha at m3w.org  Wed May 23 12:03:37 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 23 May 2012 12:03:37 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
In-Reply-To: <E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
Message-ID: <6FA05B91-4425-4164-8A08-B033920FE45E@m3w.org>

Return code in question is 22, EINVAL, code is

      WITH r = pthread_cond_timedwait(self.cond, self.mutex, until) DO
        IF r = Uerror.ETIMEDOUT THEN
          WITH r = pthread_mutex_unlock(self.mutex) DO <*ASSERT r=0*> END;
          IF perfOn THEN PerfRunning() END;
          RETURN;
        END;
        IF r # 0 THEN
          RTIO.PutText("r="); RTIO.PutInt(r); RTIO.PutText("\n");
          RTIO.Flush();
        END;
        <*ASSERT r=0*> --- former line 586

...
       The pthread_cond_timedwait() and pthread_cond_wait() functions may fail if:

       EINVAL The value specified by cond, mutex, or abstime is invalid.

       EINVAL Different  mutexes  were supplied for concurrent pthread_cond_timedwait() or pthread_cond_wait() operations on the
              same condition variable.

On May 22, 2012, at 4:59 PM, Antony Hosking wrote:

> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
> 
> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
> 
>> 
>> ***
>> *** runtime error:
>> ***    <*ASSERT*> failed.
>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>> ***
>> ...
>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>   at ../src/thread/PTHREAD/ThreadPThread.m3:586
>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>> ?
>> 
>> And so on? Looks like I reported this earlier, here: 
>> 
>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>> 
>> Any progress? Maybe I missed something.
>> 
>> dd
>> 
>> 
> 



From dragisha at m3w.org  Wed May 23 14:36:02 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 23 May 2012 14:36:02 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
In-Reply-To: <6FA05B91-4425-4164-8A08-B033920FE45E@m3w.org>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
	<6FA05B91-4425-4164-8A08-B033920FE45E@m3w.org>
Message-ID: <1CE45569-8335-4BFD-A08F-30D60A9EA18E@m3w.org>

Good news is: it was only range check error missing in generated code.

Input argument to Thread.Pause() was 1.0d9 (safe infinity idea on 64bit :)). When added to Time.Now(), it overflows 32bit component timespec. Negative components in timespec - EINVAL on pthread_cond_timedwait.

Good news II: No need for interim release because of this "bug". 

On May 23, 2012, at 12:03 PM, Dragi?a Duri? wrote:

> Return code in question is 22, EINVAL, code is
> 
>      WITH r = pthread_cond_timedwait(self.cond, self.mutex, until) DO
>        IF r = Uerror.ETIMEDOUT THEN
>          WITH r = pthread_mutex_unlock(self.mutex) DO <*ASSERT r=0*> END;
>          IF perfOn THEN PerfRunning() END;
>          RETURN;
>        END;
>        IF r # 0 THEN
>          RTIO.PutText("r="); RTIO.PutInt(r); RTIO.PutText("\n");
>          RTIO.Flush();
>        END;
>        <*ASSERT r=0*> --- former line 586
> 
> ...
>       The pthread_cond_timedwait() and pthread_cond_wait() functions may fail if:
> 
>       EINVAL The value specified by cond, mutex, or abstime is invalid.
> 
>       EINVAL Different  mutexes  were supplied for concurrent pthread_cond_timedwait() or pthread_cond_wait() operations on the
>              same condition variable.
> 
> On May 22, 2012, at 4:59 PM, Antony Hosking wrote:
> 
>> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
>> 
>> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
>> 
>>> 
>>> ***
>>> *** runtime error:
>>> ***    <*ASSERT*> failed.
>>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>>> ***
>>> ...
>>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>>  at ../src/thread/PTHREAD/ThreadPThread.m3:586
>>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>>> ?
>>> 
>>> And so on? Looks like I reported this earlier, here: 
>>> 
>>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>>> 
>>> Any progress? Maybe I missed something.
>>> 
>>> dd
>>> 
>>> 
>> 
> 



From dabenavidesd at yahoo.es  Thu May 24 00:41:41 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 23 May 2012 23:41:41 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <9E51EE23-0A0E-459F-BC97-9CC447728A2A@m3w.org>
Message-ID: <1337812901.82672.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi:
What I remember is last release was done with switch, but before was built by that target so, I don't know, I think there isn't such now, maybe I'm wrong.
In the end, what is the difference for build time, none probably, so use what you build, or what do you want to build? 
Thanks in advance

--- El mi?, 23/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: [M3devel] cm3, NOPTHREAD
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 23 de mayo, 2012 03:36
> Anyone made cm3 with -DNOPTHREAD ?
> 5.8.6 release version.
> 


From jay.krell at cornell.edu  Thu May 24 01:07:46 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 23 May 2012 23:07:46 +0000
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <1337812901.82672.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <9E51EE23-0A0E-459F-BC97-9CC447728A2A@m3w.org>,
	<1337812901.82672.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W464C8A70B5346462747BEBE6030@phx.gbl>


Do you mean did we make something "official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.  Do it yourself?  (Try out scripts/python/make-dist.py?)   It has always been easy from a m3makefile point of view to do it.You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.   - Jay
 > Date: Wed, 23 May 2012 23:41:41 +0100
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; dragisha at m3w.org
> Subject: Re: [M3devel] cm3, NOPTHREAD
> 
> Hi:
> What I remember is last release was done with switch, but before was built by that target so, I don't know, I think there isn't such now, maybe I'm wrong.
> In the end, what is the difference for build time, none probably, so use what you build, or what do you want to build? 
> Thanks in advance
> 
> --- El mi?, 23/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> > De: Dragi?a Duri? <dragisha at m3w.org>
> > Asunto: [M3devel] cm3, NOPTHREAD
> > Para: "m3devel" <m3devel at elegosoft.com>
> > Fecha: mi?rcoles, 23 de mayo, 2012 03:36
> > Anyone made cm3 with -DNOPTHREAD ?
> > 5.8.6 release version.
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120523/b4297d35/attachment-0001.html>

From dabenavidesd at yahoo.es  Thu May 24 01:31:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 24 May 2012 00:31:34 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <COL101-W464C8A70B5346462747BEBE6030@phx.gbl>
Message-ID: <1337815894.98672.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I was remembering that last release was able to switch, but proving the theory that something is better, I don't remember any reason rather than by broken builds, so that's why I say use what you have.
In my mind there is any reason for such target to be very different in compile time, perhaps in RT the GC may help something if so. But Dragisha wants to 'build', so I don't know.
Thanks in advance

--- El mi?, 23/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] cm3, NOPTHREAD
Para: dabenavidesd at yahoo.es, "m3devel" <m3devel at elegosoft.com>, dragisha at m3w.org
Fecha: mi?rcoles, 23 de mayo, 2012 18:07




Do you mean did we make something?"official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
?
?
Do it yourself?
? (Try out scripts/python/make-dist.py?) 
?
?
It has always been easy from a m3makefile point of view to do it.
You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.
?
?
?- Jay
?
> Date: Wed, 23 May 2012 23:41:41 +0100
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; dragisha at m3w.org
> Subject: Re: [M3devel] cm3, NOPTHREAD
> 
> Hi:
> What I remember is last release was done with switch, but before was built by that target so, I don't know, I think there isn't such now, maybe I'm wrong.
> In the end, what is the difference for build time, none probably, so use what you build, or what do you want to build? 
> Thanks in advance
> 
> --- El mi?, 23/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> > De: Dragi?a Duri? <dragisha at m3w.org>
> > Asunto: [M3devel] cm3, NOPTHREAD
> > Para: "m3devel" <m3devel at elegosoft.com>
> > Fecha: mi?rcoles, 23 de mayo, 2012 03:36
> > Anyone made cm3 with -DNOPTHREAD ?
> > 5.8.6 release version.
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120524/5e996ec2/attachment-0001.html>

From dragisha at m3w.org  Thu May 24 10:43:41 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 24 May 2012 10:43:41 +0200
Subject: [M3devel] cm3, NOPTHREAD
Message-ID: <F2C6F642-0ED9-4A79-9E67-256DAE06EB64@m3w.org>

I did

export BUILDARGS="-DNOPTHREAD"

before building packages/compiler.

Didn't work. Built cm3 failed on first invocation with stack of three elements, topmost being NoteStackLocations. No other data.

On May 24, 2012, at 1:07 AM, Jay K wrote:

> Do you mean did we make something "official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
>  
>  
> Do it yourself?
>   (Try out scripts/python/make-dist.py?) 
>  
>  
> It has always been easy from a m3makefile point of view to do it.
> You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120524/67a65fad/attachment-0001.html>

From dragisha at m3w.org  Fri May 25 22:51:34 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 25 May 2012 22:51:34 +0200
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <1337978790.36404.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1337978790.36404.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <555EDB08-5E0A-472A-9D93-FD890F924303@m3w.org>

Daniel,

BUILDARGS is applied to all builds occuring while it's set.

Have a nice day.

dd

On May 25, 2012, at 10:46 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> such system will not compile everything using NOPTHREAD thing, but merely the compiler, so this doesn't help anything else than the compiler, if you want to build with your compiler that then you need a correct boot image.
> Thanks in advance
> 
> 
> --- El jue, 24/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] cm3, NOPTHREAD
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: jueves, 24 de mayo, 2012 03:43
> 
> I did
> 
> export BUILDARGS="-DNOPTHREAD"
> 
> before building packages/compiler.
> 
> Didn't work. Built cm3 failed on first invocation with stack of three elements, topmost being NoteStackLocations. No other data.
> 
> On May 24, 2012, at 1:07 AM, Jay K wrote:
> 
>> Do you mean did we make something "official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
>>  
>>  
>> Do it yourself?
>>   (Try out scripts/python/make-dist.py?) 
>>  
>>  
>> It has always been easy from a m3makefile point of view to do it.
>> You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120525/235f57e2/attachment-0001.html>

From dabenavidesd at yahoo.es  Fri May 25 22:46:30 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 25 May 2012 21:46:30 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <F2C6F642-0ED9-4A79-9E67-256DAE06EB64@m3w.org>
Message-ID: <1337978790.36404.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
such system will not compile everything using NOPTHREAD thing, but merely the compiler, so this doesn't help anything else than the compiler, if you want to build with your compiler that then you need a correct boot image.
Thanks in advance


--- El jue, 24/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] cm3, NOPTHREAD
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 24 de mayo, 2012 03:43

I did
export BUILDARGS="-DNOPTHREAD"
before building packages/compiler.
Didn't work. Built cm3 failed on first invocation with stack of three elements, topmost being NoteStackLocations. No other data.
On May 24, 2012, at 1:07 AM, Jay K wrote:
Do you mean did we make something?"official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
?
?
Do it yourself?
? (Try out scripts/python/make-dist.py?)?
?
?
It has always been easy from a m3makefile point of view to do it.
You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120525/520b424b/attachment-0001.html>

From dabenavidesd at yahoo.es  Fri May 25 22:57:56 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 25 May 2012 21:57:56 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <555EDB08-5E0A-472A-9D93-FD890F924303@m3w.org>
Message-ID: <1337979476.29484.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
no, since we've lost self-hosted compiler (because PTHREADS is C code) when compiling using PTHREADS capabilities.
You need a new compiler image and a new RT image, if you want to do that; what you say, sounds like you can change that at build time, this is not the case.
Thanks in advance


--- El vie, 25/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] cm3, NOPTHREAD
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay K" <jay.krell at cornell.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 25 de mayo, 2012 15:51

Daniel,
BUILDARGS is applied to all builds occuring while it's set.
Have a nice day.
dd
On May 25, 2012, at 10:46 PM, Daniel Alejandro Benavides D. wrote:
Hi all:
such system will not compile everything using NOPTHREAD thing, but merely the compiler, so this doesn't help anything else than the compiler, if you want to build with your compiler that then you need a correct boot image.
Thanks in advance


--- El jue, 24/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] cm3, NOPTHREAD
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 24 de mayo, 2012 03:43

I did
export BUILDARGS="-DNOPTHREAD"
before building packages/compiler.
Didn't work. Built
 cm3 failed on first invocation with stack of three elements, topmost being NoteStackLocations. No other data.
On May 24, 2012, at 1:07 AM, Jay K wrote:
Do you mean did we make something?"official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
?
?
Do it yourself?
? (Try out
 scripts/python/make-dist.py?)?
?
?
It has always been easy from a m3makefile point of view to do it.
You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120525/c760a07b/attachment-0001.html>

From jay.krell at cornell.edu  Sat May 26 00:09:12 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 25 May 2012 22:09:12 +0000
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <1337979476.29484.YahooMailClassic@web29703.mail.ird.yahoo.com>
References: <555EDB08-5E0A-472A-9D93-FD890F924303@m3w.org>,
	<1337979476.29484.YahooMailClassic@web29703.mail.ird.yahoo.com>
Message-ID: <COL101-W1C8E7FBA8B4CC5793DC42E6010@phx.gbl>


?> no, since we've lost self-hosted compiler (because PTHREADS is C code)  
?> when compiling using PTHREADS capabilities. 
?

?Again Daniel, this make no sense to me. 


> You need a new compiler image 


?
?Again Daniel, this is wrong.?  


?
? >? and a new RT image 




? Again Daniel, this doesn't make complete sense to me.?  
? What do you mean "new RT image"? 


?You need m3core, and then because its interface essentially changes (different type ids for thread and/or lock), you have to recompile everything else that you are going to use, with this new m3core -- i.e.? the entire dependency graph up to and including the executable.


You do NOT need a new compiler.
If it works, great. But you don't need it.


If we hide the types behind object or such, then only m3core will need to be rebuild. That is the plan. And more so -- a command line to change between them.
For now, the type ids vary.


-DNOPTHREAD only directly changes m3core.
The rest of the system can be compiled w/ or w/o it. But the new m3core causes a need for some rebuild.


?- Jay


________________________________
> Date: Fri, 25 May 2012 21:57:56 +0100 
> From: dabenavidesd at yahoo.es 
> Subject: Re: [M3devel] cm3, NOPTHREAD 
> To: dragisha at m3w.org 
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com 
>  
> Hi all: 
> no, since we've lost self-hosted compiler (because PTHREADS is C code)  
> when compiling using PTHREADS capabilities. 
> You need a new compiler image and a new RT image, if you want to do  
> that; what you say, sounds like you can change that at build time, this  
> is not the case. 
> Thanks in advance 
>  
>  
> --- El vie, 25/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?: 
>  
> De: Dragi?a Duri? <dragisha at m3w.org> 
> Asunto: Re: [M3devel] cm3, NOPTHREAD 
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 
> CC: "Jay K" <jay.krell at cornell.edu>, "m3devel" <m3devel at elegosoft.com> 
> Fecha: viernes, 25 de mayo, 2012 15:51 
>  
> Daniel, 
>  
> BUILDARGS is applied to all builds occuring while it's set. 
>  
> Have a nice day. 
>  
> dd 
>  
> On May 25, 2012, at 10:46 PM, Daniel Alejandro Benavides D. wrote: 
>  
> Hi all: 
> such system will not compile everything using NOPTHREAD thing, but  
> merely the compiler, so this doesn't help anything else than the  
> compiler, if you want to build with your compiler that then you need a  
> correct boot image. 
> Thanks in advance 
>  
>  
> --- El jue, 24/5/12, Dragi?a Duri?  
> <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>> escribi?: 
>  
> De: Dragi?a Duri?  
> <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>> 
> Asunto: Re: [M3devel] cm3, NOPTHREAD 
> Para: "Jay K"  
> <jay.krell at cornell.edu<http:///mc/compose?to=jay.krell%40cornell.edu>> 
> CC: "m3devel"  
> <m3devel at elegosoft.com<http:///mc/compose?to=m3devel%40elegosoft.com>> 
> Fecha: jueves, 24 de mayo, 2012 03:43 
>  
> I did 
>  
> export BUILDARGS="-DNOPTHREAD" 
>  
> before building packages/compiler. 
>  
> Didn't work. Built cm3 failed on first invocation with stack of three  
> elements, topmost being NoteStackLocations. No other data. 
>  
> On May 24, 2012, at 1:07 AM, Jay K wrote: 
>  
> Do you mean did we make something "official" and put it somewhere to be  
> tested and downloaded by the masses of Modula-3 programmers who want to  
> use both Modula-3 and user threads? I don't think so. 
>  
>  
> Do it yourself? 
>    (Try out scripts/python/make-dist.py?) 
>  
>  
> It has always been easy from a m3makefile point of view to do it. 
> You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile. 
>  
>  
>  
>  
 		 	   		  

From dabenavidesd at yahoo.es  Sat May 26 00:38:07 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 25 May 2012 23:38:07 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <COL101-W1C8E7FBA8B4CC5793DC42E6010@phx.gbl>
Message-ID: <1337985487.13774.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
I'm thinking can press a key command to compile m3core with that option, no, you need to change the sources of the thing. That's for me new RT and new compiler, and if you want that do it, it's OK but for me, don't think it makes sense to do that in an automatic environment, that's why I tell you you can't do that in Modula-3 alone. If it were pure Modula-3 yes you could override a Thread interface with that option, but not here certainly.
Thanks advance


--- El vie, 25/5/12, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] cm3, NOPTHREAD
> Para: dabenavidesd at yahoo.es, dragisha at m3w.org
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 25 de mayo, 2012 17:09
> 
>  > no, since we've lost self-hosted compiler (because
> PTHREADS is C code)  
>  > when compiling using PTHREADS capabilities. 
>  
> 
>  Again Daniel, this make no sense to me. 
> 
> 
> > You need a new compiler image 
> 
> 
>  
>  Again Daniel, this is wrong.   
> 
> 
>  
>   >  and a new RT image 
> 
> 
> 
> 
>   Again Daniel, this doesn't make complete sense to
> me.   
>   What do you mean "new RT image"? 
> 
> 
>  You need m3core, and then because its interface
> essentially changes (different type ids for thread and/or
> lock), you have to recompile everything else that you are
> going to use, with this new m3core -- i.e.  the entire
> dependency graph up to and including the executable.
> 
> 
> You do NOT need a new compiler.
> If it works, great. But you don't need it.
> 
> 
> If we hide the types behind object or such, then only m3core
> will need to be rebuild. That is the plan. And more so -- a
> command line to change between them.
> For now, the type ids vary.
> 
> 
> -DNOPTHREAD only directly changes m3core.
> The rest of the system can be compiled w/ or w/o it. But the
> new m3core causes a need for some rebuild.
> 
> 
>  - Jay
> 
> 
> ________________________________
> > Date: Fri, 25 May 2012 21:57:56 +0100 
> > From: dabenavidesd at yahoo.es
> 
> > Subject: Re: [M3devel] cm3, NOPTHREAD 
> > To: dragisha at m3w.org
> 
> > CC: jay.krell at cornell.edu;
> m3devel at elegosoft.com
> 
> >  
> > Hi all: 
> > no, since we've lost self-hosted compiler (because
> PTHREADS is C code)  
> > when compiling using PTHREADS capabilities. 
> > You need a new compiler image and a new RT image, if
> you want to do  
> > that; what you say, sounds like you can change that at
> build time, this  
> > is not the case. 
> > Thanks in advance 
> >  
> >  
> > --- El vie, 25/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?: 
> >  
> > De: Dragi?a Duri? <dragisha at m3w.org>
> 
> > Asunto: Re: [M3devel] cm3, NOPTHREAD 
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> 
> > CC: "Jay K" <jay.krell at cornell.edu>,
> "m3devel" <m3devel at elegosoft.com>
> 
> > Fecha: viernes, 25 de mayo, 2012 15:51 
> >  
> > Daniel, 
> >  
> > BUILDARGS is applied to all builds occuring while it's
> set. 
> >  
> > Have a nice day. 
> >  
> > dd 
> >  
> > On May 25, 2012, at 10:46 PM, Daniel Alejandro
> Benavides D. wrote: 
> >  
> > Hi all: 
> > such system will not compile everything using NOPTHREAD
> thing, but  
> > merely the compiler, so this doesn't help anything else
> than the  
> > compiler, if you want to build with your compiler that
> then you need a  
> > correct boot image. 
> > Thanks in advance 
> >  
> >  
> > --- El jue, 24/5/12, Dragi?a Duri?  
> > <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>>
> escribi?: 
> >  
> > De: Dragi?a Duri?  
> > <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>> 
> > Asunto: Re: [M3devel] cm3, NOPTHREAD 
> > Para: "Jay K"  
> > <jay.krell at cornell.edu<http:///mc/compose?to=jay.krell%40cornell.edu>> 
> > CC: "m3devel"  
> > <m3devel at elegosoft.com<http:///mc/compose?to=m3devel%40elegosoft.com>> 
> > Fecha: jueves, 24 de mayo, 2012 03:43 
> >  
> > I did 
> >  
> > export BUILDARGS="-DNOPTHREAD" 
> >  
> > before building packages/compiler. 
> >  
> > Didn't work. Built cm3 failed on first invocation with
> stack of three  
> > elements, topmost being NoteStackLocations. No other
> data. 
> >  
> > On May 24, 2012, at 1:07 AM, Jay K wrote: 
> >  
> > Do you mean did we make something "official" and put it
> somewhere to be  
> > tested and downloaded by the masses of Modula-3
> programmers who want to  
> > use both Modula-3 and user threads? I don't think so. 
> >  
> >  
> > Do it yourself? 
> >    (Try out scripts/python/make-dist.py?) 
> >  
> >  
> > It has always been easy from a m3makefile point of view
> to do it. 
> > You either use -DNOPTHREAD or such, or edit
> m3core/src/thread/m3makefile. 
> >  
> >  
> >  
> >  
>     
>         
>           
>   


From dabenavidesd at yahoo.es  Sat May 26 00:58:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 25 May 2012 23:58:34 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <1337985487.13774.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <1337986714.57733.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I think that you don't want that unless you want to use the OS source, I don't think this libraries make that sense, this libraries are just if you want is use this interface of your OS (Modula-3 are essentially different of theirs that's the main issue here).
I think we can do it, but the first alternative to test would be a NT since you can provide several schedulers in an OS version called RiAlto (you need to compile an relink everything). But then you wouldn't be using Win32 alone, you need to license not that EULA, or ULA, guess if DEC/Compaq did that, what did they paid for?
I don't know any other OS with that function, but perhaps I'm wrong.
Thanks in advance


--- El vie, 25/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] cm3, NOPTHREAD
> Para: dragisha at m3w.org, "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 25 de mayo, 2012 17:38
> Hi all:
> I'm thinking can press a key command to compile m3core with
> that option, no, you need to change the sources of the
> thing. That's for me new RT and new compiler, and if you
> want that do it, it's OK but for me, don't think it makes
> sense to do that in an automatic environment, that's why I
> tell you you can't do that in Modula-3 alone. If it were
> pure Modula-3 yes you could override a Thread interface with
> that option, but not here certainly.
> Thanks advance
> 
> 
> --- El vie, 25/5/12, Jay K <jay.krell at cornell.edu>
> escribi?:
> 
> > De: Jay K <jay.krell at cornell.edu>
> > Asunto: RE: [M3devel] cm3, NOPTHREAD
> > Para: dabenavidesd at yahoo.es,
> dragisha at m3w.org
> > CC: "m3devel" <m3devel at elegosoft.com>
> > Fecha: viernes, 25 de mayo, 2012 17:09
> > 
> >  > no, since we've lost self-hosted compiler
> (because
> > PTHREADS is C code)  
> >  > when compiling using PTHREADS capabilities.
> 
> >  
> > 
> >  Again Daniel, this make no sense to me. 
> > 
> > 
> > > You need a new compiler image 
> > 
> > 
> >  
> >  Again Daniel, this is wrong.   
> > 
> > 
> >  
> >   >  and a new RT image 
> > 
> > 
> > 
> > 
> >   Again Daniel, this doesn't make
> complete sense to
> > me.   
> >   What do you mean "new RT image"? 
> > 
> > 
> >  You need m3core, and then because its interface
> > essentially changes (different type ids for thread
> and/or
> > lock), you have to recompile everything else that you
> are
> > going to use, with this new m3core -- i.e.  the
> entire
> > dependency graph up to and including the executable.
> > 
> > 
> > You do NOT need a new compiler.
> > If it works, great. But you don't need it.
> > 
> > 
> > If we hide the types behind object or such, then only
> m3core
> > will need to be rebuild. That is the plan. And more so
> -- a
> > command line to change between them.
> > For now, the type ids vary.
> > 
> > 
> > -DNOPTHREAD only directly changes m3core.
> > The rest of the system can be compiled w/ or w/o it.
> But the
> > new m3core causes a need for some rebuild.
> > 
> > 
> >  - Jay
> > 
> > 
> > ________________________________
> > > Date: Fri, 25 May 2012 21:57:56 +0100 
> > > From: dabenavidesd at yahoo.es
> > 
> > > Subject: Re: [M3devel] cm3, NOPTHREAD 
> > > To: dragisha at m3w.org
> > 
> > > CC: jay.krell at cornell.edu;
> > m3devel at elegosoft.com
> > 
> > >  
> > > Hi all: 
> > > no, since we've lost self-hosted compiler
> (because
> > PTHREADS is C code)  
> > > when compiling using PTHREADS capabilities. 
> > > You need a new compiler image and a new RT image,
> if
> > you want to do  
> > > that; what you say, sounds like you can change
> that at
> > build time, this  
> > > is not the case. 
> > > Thanks in advance 
> > >  
> > >  
> > > --- El vie, 25/5/12, Dragi?a Duri? <dragisha at m3w.org>
> > escribi?: 
> > >  
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > 
> > > Asunto: Re: [M3devel] cm3, NOPTHREAD 
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > 
> > > CC: "Jay K" <jay.krell at cornell.edu>,
> > "m3devel" <m3devel at elegosoft.com>
> > 
> > > Fecha: viernes, 25 de mayo, 2012 15:51 
> > >  
> > > Daniel, 
> > >  
> > > BUILDARGS is applied to all builds occuring while
> it's
> > set. 
> > >  
> > > Have a nice day. 
> > >  
> > > dd 
> > >  
> > > On May 25, 2012, at 10:46 PM, Daniel Alejandro
> > Benavides D. wrote: 
> > >  
> > > Hi all: 
> > > such system will not compile everything using
> NOPTHREAD
> > thing, but  
> > > merely the compiler, so this doesn't help anything
> else
> > than the  
> > > compiler, if you want to build with your compiler
> that
> > then you need a  
> > > correct boot image. 
> > > Thanks in advance 
> > >  
> > >  
> > > --- El jue, 24/5/12, Dragi?a Duri?  
> > > <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>>
> > escribi?: 
> > >  
> > > De: Dragi?a Duri?  
> > > <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>> 
> > > Asunto: Re: [M3devel] cm3, NOPTHREAD 
> > > Para: "Jay K"  
> > > <jay.krell at cornell.edu<http:///mc/compose?to=jay.krell%40cornell.edu>> 
> > > CC: "m3devel"  
> > > <m3devel at elegosoft.com<http:///mc/compose?to=m3devel%40elegosoft.com>> 
> > > Fecha: jueves, 24 de mayo, 2012 03:43 
> > >  
> > > I did 
> > >  
> > > export BUILDARGS="-DNOPTHREAD" 
> > >  
> > > before building packages/compiler. 
> > >  
> > > Didn't work. Built cm3 failed on first invocation
> with
> > stack of three  
> > > elements, topmost being NoteStackLocations. No
> other
> > data. 
> > >  
> > > On May 24, 2012, at 1:07 AM, Jay K wrote: 
> > >  
> > > Do you mean did we make something "official" and
> put it
> > somewhere to be  
> > > tested and downloaded by the masses of Modula-3
> > programmers who want to  
> > > use both Modula-3 and user threads? I don't think
> so. 
> > >  
> > >  
> > > Do it yourself? 
> > >    (Try out
> scripts/python/make-dist.py?) 
> > >  
> > >  
> > > It has always been easy from a m3makefile point of
> view
> > to do it. 
> > > You either use -DNOPTHREAD or such, or edit
> > m3core/src/thread/m3makefile. 
> > >  
> > >  
> > >  
> > >  
> >     
> >         
> >           
> >
> 


From dabenavidesd at yahoo.es  Mon May 28 16:22:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 May 2012 15:22:24 +0100 (BST)
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20120528084705.E13302474003@birch.elegosoft.com>
Message-ID: <1338214944.4326.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi Jay:
Where are you testing this, or have you tested this on an Alpha, I might get access, but I notice you dropped the libdecnumber, stuff right?
Thanks in advance

--- El lun, 28/5/12, Jay Krell <jkrell at elego.de> escribi?:

> De: Jay Krell <jkrell at elego.de>
> Asunto: [M3commit] CVS Update: cm3
> Para: m3commit at elegosoft.com
> Fecha: lunes, 28 de mayo, 2012 05:47
> CVSROOT:    /usr/cvs
> Changes by:   
> jkrell at birch.    12/05/28 10:47:05
> 
> Modified files:
>     cm3/m3-sys/m3cc/gcc-4.6/: configure 
>     ./: configure 
>     cm3/m3-sys/m3cc/gcc-4.6/gcc/: Makefile.in
> auto-inc-dec.c 
>                
>                
>   basic-block.h builtins.c 
>                
>                
>   c-aux-info.c c-convert.c c-decl.c 
>                
>                
>   c-errors.c c-lang.c c-lang.h 
>                
>                
>   c-objc-common.c c-parser.c 
>                
>                
>   c-tree.h c-typeck.c calls.c 
>                
>                
>   cfgexpand.c cfgloop.h cgraph.c 
>                
>                
>   cgraph.h cgraphbuild.c 
>                
>                
>   cgraphunit.c combine.c configure 
>                
>                
>   configure.ac cppdefault.c 
>                
>                
>   cppdefault.h cppspec.c cse.c 
>                
>                
>   expr.c final.c fold-const.c gcc.c 
>                
>                
>   gccspec.c gcse.c gengtype-lex.c 
>                
>                
>   gengtype-lex.l gengtype.c 
>                
>                
>   gimple-fold.c gimple.c gimplify.c 
>                
>                
>   incpath.c intl.c ipa-cp.c 
>                
>                
>   ipa-inline.c ipa-prop.c ipa-prop.h 
>                
>                
>   ipa-ref.h ipa-utils.c ipa.c 
>                
>                
>   ira-build.c ira-conflicts.c 
>                
>                
>   ira-int.h ira.c ira.h libgcov.c 
>                
>                
>   loop-iv.c loop-unswitch.c opts.c 
>                
>                
>   passes.c postreload.c predict.c 
>                
>                
>   profile.c sched-vis.c 
>                
>                
>   sel-sched-dump.c store-motion.c 
>                
>                
>   stringpool.c targhooks.c toplev.c 
>                
>                
>   tree-cfg.c tree-chrec.c 
>                
>                
>   tree-complex.c tree-eh.c 
>                
>                
>   tree-flow.h tree-inline.c 
>                
>                
>   tree-nested.c tree-object-size.c 
>                
>                
>   tree-outof-ssa.c tree-parloops.c 
>                
>                
>   tree-pass.h tree-pretty-print.c 
>                
>                
>   tree-profile.c 
>                
>                
>   tree-scalar-evolution.c tree-sra.c 
>                
>                
>   tree-ssa-address.c 
>                
>                
>   tree-ssa-alias.c 
>                
>                
>   tree-ssa-copyrename.c 
>                
>                
>   tree-ssa-dce.c tree-ssa-dom.c 
>                
>                
>   tree-ssa-loop-ivopts.c 
>                
>                
>   tree-ssa-loop-manip.c 
>                
>                
>   tree-ssa-loop.c tree-ssa-phiopt.c 
>                
>                
>   tree-ssa-structalias.c 
>                
>                
>   tree-ssa-uncprop.c tree-ssa.c 
>                
>                
>   tree-vect-data-refs.c 
>                
>                
>   tree-vect-generic.c 
>                
>                
>   tree-vect-loop-manip.c 
>                
>                
>   tree-vect-loop.c 
>                
>                
>   tree-vect-patterns.c 
>                
>                
>   tree-vect-slp.c tree-vect-stmts.c 
>                
>                
>   tree-vrp.c tree.h unwind-c.c 
>                
>                
>   unwind-compat.c unwind-compat.h 
>                
>                
>   unwind-dw2-fde-compat.c 
>                
>                
>   unwind-dw2-fde-darwin.c 
>                
>                
>   unwind-dw2-fde-glibc.c 
>                
>                
>   unwind-dw2-fde.c unwind-dw2-fde.h 
>                
>                
>   unwind-dw2.c unwind-dw2.h 
>                
>                
>   unwind-generic.h unwind-pe.h 
>                
>                
>   unwind-sjlj.c value-prof.c 
>                
>                
>   var-tracking.c varpool.c web.c 
>     ./: Makefile.in auto-inc-dec.c
> basic-block.h builtins.c 
>         c-aux-info.c c-convert.c
> c-decl.c c-errors.c c-lang.c 
>         c-lang.h c-objc-common.c
> c-parser.c c-tree.h c-typeck.c 
>         calls.c cfgexpand.c
> cfgloop.h cgraph.c cgraph.h 
>         cgraphbuild.c cgraphunit.c
> combine.c configure configure.ac 
>         cppdefault.c cppdefault.h
> cppspec.c cse.c expr.c final.c 
>         fold-const.c gcc.c
> gccspec.c gcse.c gengtype-lex.c 
>         gengtype-lex.l gengtype.c
> gimple-fold.c gimple.c gimplify.c 
>         incpath.c intl.c ipa-cp.c
> ipa-inline.c ipa-prop.c ipa-prop.h 
>         ipa-ref.h ipa-utils.c ipa.c
> ira-build.c ira-conflicts.c 
>         ira-int.h ira.c ira.h
> libgcov.c loop-iv.c loop-unswitch.c 
>         opts.c passes.c
> postreload.c predict.c profile.c sched-vis.c 
>         sel-sched-dump.c
> store-motion.c stringpool.c targhooks.c 
>         toplev.c tree-cfg.c
> tree-chrec.c tree-complex.c tree-eh.c 
>         tree-flow.h tree-inline.c
> tree-nested.c tree-object-size.c 
>         tree-outof-ssa.c
> tree-parloops.c tree-pass.h 
>         tree-pretty-print.c
> tree-profile.c tree-scalar-evolution.c 
>         tree-sra.c
> tree-ssa-address.c tree-ssa-alias.c 
>         tree-ssa-copyrename.c
> tree-ssa-dce.c tree-ssa-dom.c 
>         tree-ssa-loop-ivopts.c
> tree-ssa-loop-manip.c tree-ssa-loop.c 
>         tree-ssa-phiopt.c
> tree-ssa-structalias.c tree-ssa-uncprop.c 
>         tree-ssa.c
> tree-vect-data-refs.c tree-vect-generic.c 
>         tree-vect-loop-manip.c
> tree-vect-loop.c tree-vect-patterns.c 
>         tree-vect-slp.c
> tree-vect-stmts.c tree-vrp.c tree.h 
>         unwind-c.c unwind-compat.c
> unwind-compat.h 
>         unwind-dw2-fde-compat.c
> unwind-dw2-fde-darwin.c 
>         unwind-dw2-fde-glibc.c
> unwind-dw2-fde.c unwind-dw2-fde.h 
>         unwind-dw2.c unwind-dw2.h
> unwind-generic.h unwind-pe.h 
>         unwind-sjlj.c value-prof.c
> var-tracking.c varpool.c web.c 
>     cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
> darwin-protos.h darwin.c 
>                
>                
>          darwin.h 
>     ./: darwin-protos.h darwin.c darwin.h 
>     cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
> crtfastmath.c 
>                
>                
>               crtprec.c 
>                
>                
>              
> cygming-crtbegin.c 
>                
>                
>              
> cygming-crtend.c 
>                
>                
>               darwin.h
> driver-i386.c 
>                
>                
>               gmon-sol2.c
> i386.c 
>                
>                
>              
> netware-crt0.c 
>     ./: crtfastmath.c crtprec.c
> cygming-crtbegin.c cygming-crtend.c 
>         darwin.h driver-i386.c
> gmon-sol2.c i386.c netware-crt0.c 
>     cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/: lto.c 
>     ./: lto.c 
>     cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
> line-map.h 
> 
> Log message:
>     work in progress -- can compile
> everything now, but float exception right away
> 
> 


From hendrik at topoi.pooq.com  Mon May 28 18:50:24 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 12:50:24 -0400
Subject: [M3devel] portable hosting
In-Reply-To: <C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
	<C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>
Message-ID: <20120528165024.GA7021@topoi.pooq.com>

On Sun, May 20, 2012 at 02:32:14PM -0700, Jay wrote:
> 
> Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.

Would it be more or less difficult than writing a code generator that 
generated C or C++ code?  THe code generator could do the rewrite for 
you.  Bt it wouldn't be very readable code.


From hendrik at topoi.pooq.com  Mon May 28 18:55:44 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 12:55:44 -0400
Subject: [M3devel] using interpreter as a bootstrap
In-Reply-To: <20120522024455.GA9667@topoi.pooq.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
	<20120521184316.GA10750@topoi.pooq.com>
	<20120521211045.GA7596@topoi.pooq.com>
	<COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
	<20120522024455.GA9667@topoi.pooq.com>
Message-ID: <20120528165544.GB7021@topoi.pooq.com>

On Mon, May 21, 2012 at 10:44:55PM -0400, Hendrik Boom wrote:
> On Mon, May 21, 2012 at 10:50:44PM +0000, Jay K wrote:
> > 
> > Is C-- adequately maintained? I don't think so.
> 
> Bugs get fixed.  And there's very few of them reported.  But it's not 
> clear to me whether that's because it's so well-written, or because 
> almost no one uses it.
> 
> Active development seems to be at a stendstill.
> 
> > I'm also not super keen on depending on other projects.
> > We'll see..
> 
> I mentioned C-- because its implementation exists in both interpreted 
> and compiled versions.  That seems to be a way to bootstrap the whole 
> thing.  We could interpret the compiler using some portable 
> intermediate code -- we could even restrict the interpreter to provide 
> only a 32-bit machine, and then cross-compile from the interpreted 
> compiler to whatever machine we're installing on.  Since every Modula 
> 3 compiler seems to be able to generate code for every platform, 
> this is a way to avoid having a separate binary bootstrap for every 
> platform.

Of all the machies we already generatte code for, which has the easiest 
machine code to interpret?  We don't really have to invent a new 
interpretable object code -- we already have one.  Remember, the 
bootstrap only has to implement enough system resources to compile the 
core system.

-- hendrik


> 
> And a distro, like Debian, could have a source package that doesn't 
> need to have itself installed before it it can be installed.
> 
> -- hendrik
> 


From hendrik at topoi.pooq.com  Mon May 28 19:47:00 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 13:47:00 -0400
Subject: [M3devel] Packaging for Debian
Message-ID: <20120528174700.GA7249@topoi.pooq.com>

Wasn't there a modula 3 package for Debian long long ago (maybe in the 
days of woody?), based on pm3?  Would it be possible to examine it and 
figure out how to adapt it to currently maintained cm3?  How did then 
solve tthe bootstrap problem?

-- hendrik


From dabenavidesd at yahoo.es  Mon May 28 21:17:43 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 May 2012 20:17:43 +0100 (BST)
Subject: [M3devel] Packaging for Debian
In-Reply-To: <20120528174700.GA7249@topoi.pooq.com>
Message-ID: <1338232663.14445.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
Yes, and you could use it as in a low priority package in later releases I believe, but that said, I still miss the how much of it could boot cm3, I remember I tried to recompile NT386GNU for use m3browser (pm3 had it only  for Unix targets) and I could but failed after executing due some broken dynamic libraries issue, and couldn't understand why, but you could easily bootstrap from Unix targets to NT386GNU, I remember you couldn't do it viceversa, that is, from a NT386GNU to a Unix target, I still think that cross-boot problem was essential to understand the differences among a Unix and a Win32 API in general, but I didn't have many platforms to test it for that matter, you know, sort of making a cross product might get to the point to which is the quintessential bootstrap code for a Modula-3 compiler.
Thanks in advance

PD I still have the 20+ CD's of the Distro if somebody wants a copy or so I could post it on-line  

--- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] Packaging for Debian
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 28 de mayo, 2012 12:47
> Wasn't there a modula 3 package for
> Debian long long ago (maybe in the 
> days of woody?), based on pm3?  Would it be possible to
> examine it and 
> figure out how to adapt it to currently maintained
> cm3?  How did then 
> solve tthe bootstrap problem?
> 
> -- hendrik
> 


From dabenavidesd at yahoo.es  Mon May 28 23:04:41 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 May 2012 22:04:41 +0100 (BST)
Subject: [M3devel] using interpreter as a bootstrap
In-Reply-To: <20120528165544.GB7021@topoi.pooq.com>
Message-ID: <1338239081.37249.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I guess that is the same as asking with a high-degree of compatibility a X mating machine core of a M3CG, and I believe it is the VAX-9000, it supported a CISC/RISC-core, but this was a huge machine, and so I think could be handy to get a sample of execution traces and match to  every other possible one.
I believe they made a RR on that machine:

http://books.google.com.co/books?id=U8QpAQAAMAAJ&q=%22DEC+has%22#search_anchor

Thanks in advance


--- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] using interpreter as a bootstrap
> Para: m3devel at elegosoft.com
> Fecha: lunes, 28 de mayo, 2012 11:55
> On Mon, May 21, 2012 at 10:44:55PM
> -0400, Hendrik Boom wrote:
> > On Mon, May 21, 2012 at 10:50:44PM +0000, Jay K wrote:
> > > 
> > > Is C-- adequately maintained? I don't think so.
> > 
> > Bugs get fixed.  And there's very few of them
> reported.  But it's not 
> > clear to me whether that's because it's so
> well-written, or because 
> > almost no one uses it.
> > 
> > Active development seems to be at a stendstill.
> > 
> > > I'm also not super keen on depending on other
> projects.
> > > We'll see..
> > 
> > I mentioned C-- because its implementation exists in
> both interpreted 
> > and compiled versions.  That seems to be a way to
> bootstrap the whole 
> > thing.  We could interpret the compiler using some
> portable 
> > intermediate code -- we could even restrict the
> interpreter to provide 
> > only a 32-bit machine, and then cross-compile from the
> interpreted 
> > compiler to whatever machine we're installing on. 
> Since every Modula 
> > 3 compiler seems to be able to generate code for every
> platform, 
> > this is a way to avoid having a separate binary
> bootstrap for every 
> > platform.
> 
> Of all the machies we already generatte code for, which has
> the easiest 
> machine code to interpret?  We don't really have to
> invent a new 
> interpretable object code -- we already have one. 
> Remember, the 
> bootstrap only has to implement enough system resources to
> compile the 
> core system.
> 
> -- hendrik
> 
> 
> > 
> > And a distro, like Debian, could have a source package
> that doesn't 
> > need to have itself installed before it it can be
> installed.
> > 
> > -- hendrik
> > 
> 


From dabenavidesd at yahoo.es  Mon May 28 23:22:36 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 May 2012 22:22:36 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <20120528165024.GA7021@topoi.pooq.com>
Message-ID: <1338240156.6219.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
or better make an assembly-coded C compiler in a Java language processor, and cross-boot assemble from a Modula-3 environment there so you could bootstrap a M3CG-system there.
Thanks in advance

--- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] portable hosting
> Para: m3devel at elegosoft.com
> Fecha: lunes, 28 de mayo, 2012 11:50
> On Sun, May 20, 2012 at 02:32:14PM
> -0700, Jay wrote:
> > 
> > Btw, rewriting all of m3front in C or C++ or Java
> probably wouldn't be very difficult.
> 
> Would it be more or less difficult than writing a code
> generator that 
> generated C or C++ code?  THe code generator could do
> the rewrite for 
> you.  Bt it wouldn't be very readable code.
> 


From hendrik at topoi.pooq.com  Tue May 29 00:55:45 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 18:55:45 -0400
Subject: [M3devel] Packaging for Debian
In-Reply-To: <1338232663.14445.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <20120528174700.GA7249@topoi.pooq.com>
	<1338232663.14445.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <20120528225545.GB10489@topoi.pooq.com>

On Mon, May 28, 2012 at 08:17:43PM +0100, Daniel Alejandro Benavides D. wrote:
> 
> PD I still have the 20+ CD's of the Distro if somebody wants a copy or so I could post it on-line  

20+ CD's of Which distro?  I was thinking of getting a source package 
from Debian woody.  They still have packages for those ancient releases 
in an archive somewhere.

-- hendrik


From hendrik at topoi.pooq.com  Tue May 29 01:05:05 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 19:05:05 -0400
Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
In-Reply-To: <COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
Message-ID: <20120528230505.GC10489@topoi.pooq.com>

Trying a cross-compilation now.

On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote:
> 
> You might as well just use something in scripts to rebuild the entire 
> system.It isn't so difficult nor takes very long.     
>
> Get a working > cm3 on any system.
      cd scripts/python
      ./boot1.py <target-such-as-I386_LINUX>      That will produce a "bootstrap" archive.    Copy it to the "new" system.      Extract it.      Cd into it.      Look at the top of Makefile and see if it seems reasonable (we should use autoconf here).    run make.     That should give you a working cm3 for the new system.      Put that on path, e.g.:       su        rm -rf /usr/local/cm3       mkdir -p /usr/local/cm3/bin        cp cm3 /usr/local/cm3/bin        exit         PATH=/usr/local/cm3/bin:$PATH     cd to scripts/python in the source tree on the new system.    Then run ./boot2.sh       Then ./make-dist.py.    That should give you the entire system newly built, and a .deb.  If you already have a working cm3 on the system you want to run it on  cd scripts/python   ./upgrade.py    ./make-dist.py     I'd really like to get to the

Did that, as 
hendrik at april:~/cm3/cm3/scripts/python$ export LIBRARY_PATH=
hendrik at april:~/cm3/cm3/scripts/python$ ./boot1.py I386_LINUX

and it compiled for a ling time, then failed with

new source -> compiling Utils.m3
new source -> compiling WebFile.m3
new source -> compiling Main.m3
building makefile -> make.cm3
 ==> /farhome/hendrik/cm3/cm3/m3-sys/cm3 done

Traceback (most recent call last):
  File "./boot1.py", line 18, in <module>
    Boot();
  File "/farhome/hendrik/cm3/cm3/scripts/python/pylib.py", line 1248, in Boot
    for a in os.listdir(os.path.join(Root, dir, Config)):
OSError: [Errno 2] No such file or directory: '/farhome/hendrik/cm3/cm3/m3-sys/m3cc/I386_LINUX'
hendrik at april:~/cm3/cm3/scripts/python$


So I took a look for /farhome/hendrik/cm3/cm3/m3-sys/m3cc/I386_LINUX

and in directory /farhome/hendrik/cm3/cm3/m3-sys/m3cc/

I found 

drwxr-xr-x 12 hendrik hendrik 4096 May 28 14:39 .
  drwxr-xr-x 27 hendrik hendrik 4096 May 16 18:08 ..
  drwxr-xr-x  6 hendrik hendrik 4096 May 28 14:56 AMD64_LINUX
  drwxr-xr-x  6 hendrik hendrik 4096 May 28 15:21 AMD64_LINUX-I386_LINUX
  drwxr-xr-x  2 hendrik hendrik 4096 May 16 17:50 CVS
  
but no I386-LINUX

-- hendrik


From hendrik at topoi.pooq.com  Tue May 29 01:08:24 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 19:08:24 -0400
Subject: [M3devel] failure to cross-install
In-Reply-To: <20120528230505.GC10489@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120528230505.GC10489@topoi.pooq.com>
Message-ID: <20120528230824.GA24085@topoi.pooq.com>

(forgot to change the subject)

(It's possible that the weird directory name had been generated earlier 
when I tried to do the same thing without having emptied LIBRARY_PATH, 
but I definietly specified it for this run.

-- hendrik

On Mon, May 28, 2012 at 07:05:05PM -0400, Hendrik Boom wrote:
> Trying a cross-compilation now.
> 
> On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote:
> > 
> > You might as well just use something in scripts to rebuild the entire 
> > system.It isn't so difficult nor takes very long.     
> >
> > Get a working > cm3 on any system.
>       cd scripts/python
>       ./boot1.py <target-such-as-I386_LINUX>      That will produce a "bootstrap" archive.    Copy it to the "new" system.      Extract it.      Cd into it.      Look at the top of Makefile and see if it seems reasonable (we should use autoconf here).    run make.     That should give you a working cm3 for the new system.      Put that on path, e.g.:       su        rm -rf /usr/local/cm3       mkdir -p /usr/local/cm3/bin        cp cm3 /usr/local/cm3/bin        exit         PATH=/usr/local/cm3/bin:$PATH     cd to scripts/python in the source tree on the new system.    Then run ./boot2.sh       Then ./make-dist.py.    That should give you the entire system newly built, and a .deb.  If you already have a working cm3 on the system you want to run it on  cd scripts/python   ./upgrade.py    ./make-dist.py     I'd really like to get to the
> 
> Did that, as 
> hendrik at april:~/cm3/cm3/scripts/python$ export LIBRARY_PATH=
> hendrik at april:~/cm3/cm3/scripts/python$ ./boot1.py I386_LINUX
> 
> and it compiled for a ling time, then failed with
> 
> new source -> compiling Utils.m3
> new source -> compiling WebFile.m3
> new source -> compiling Main.m3
> building makefile -> make.cm3
>  ==> /farhome/hendrik/cm3/cm3/m3-sys/cm3 done
> 
> Traceback (most recent call last):
>   File "./boot1.py", line 18, in <module>
>     Boot();
>   File "/farhome/hendrik/cm3/cm3/scripts/python/pylib.py", line 1248, in Boot
>     for a in os.listdir(os.path.join(Root, dir, Config)):
> OSError: [Errno 2] No such file or directory: '/farhome/hendrik/cm3/cm3/m3-sys/m3cc/I386_LINUX'
> hendrik at april:~/cm3/cm3/scripts/python$
> 
> 
> So I took a look for /farhome/hendrik/cm3/cm3/m3-sys/m3cc/I386_LINUX
> 
> and in directory /farhome/hendrik/cm3/cm3/m3-sys/m3cc/
> 
> I found 
> 
> drwxr-xr-x 12 hendrik hendrik 4096 May 28 14:39 .
>   drwxr-xr-x 27 hendrik hendrik 4096 May 16 18:08 ..
>   drwxr-xr-x  6 hendrik hendrik 4096 May 28 14:56 AMD64_LINUX
>   drwxr-xr-x  6 hendrik hendrik 4096 May 28 15:21 AMD64_LINUX-I386_LINUX
>   drwxr-xr-x  2 hendrik hendrik 4096 May 16 17:50 CVS
>   
> but no I386-LINUX
> 
> -- hendrik


From dabenavidesd at yahoo.es  Tue May 29 01:22:45 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 May 2012 00:22:45 +0100 (BST)
Subject: [M3devel] Packaging for Debian
In-Reply-To: <20120528225545.GB10489@topoi.pooq.com>
Message-ID: <1338247365.16482.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
Debian Woody src and i386 distribution (3.0) succesor Sarge 3.1 in CD's, but you can boot with two floppies, etc ...
This was the last distro that worked with that packaged pm3 that I know
Thanks in advance

--- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] Packaging for Debian
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 28 de mayo, 2012 17:55
> On Mon, May 28, 2012 at 08:17:43PM
> +0100, Daniel Alejandro Benavides D. wrote:
> > 
> > PD I still have the 20+ CD's of the Distro if somebody
> wants a copy or so I could post it on-line  
> 
> 20+ CD's of Which distro?  I was thinking of getting a
> source package 
> from Debian woody.  They still have packages for those
> ancient releases 
> in an archive somewhere.
> 
> -- hendrik
> 


From jay.krell at cornell.edu  Tue May 29 06:30:00 2012
From: jay.krell at cornell.edu (Jay)
Date: Mon, 28 May 2012 21:30:00 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <1338214944.4326.YahooMailClassic@web29705.mail.ird.yahoo.com>
References: <1338214944.4326.YahooMailClassic@web29705.mail.ird.yahoo.com>
Message-ID: <07F31967-EDA5-4CD7-975C-11F428381AB8@gmail.com>

Don't worry about it. I will test each platform or get others to before enabling, at least some popular majority of them. I no longer have any Alphas. Eventually I might ask for ssh access to an Alpha or reacquire hardware. Anyway, don't worry. I generally know what I'm doing.

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 28, 2012, at 7:22 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi Jay:
> Where are you testing this, or have you tested this on an Alpha, I might get access, but I notice you dropped the libdecnumber, stuff right?
> Thanks in advance
> 
> --- El lun, 28/5/12, Jay Krell <jkrell at elego.de> escribi?:
> 
>> De: Jay Krell <jkrell at elego.de>
>> Asunto: [M3commit] CVS Update: cm3
>> Para: m3commit at elegosoft.com
>> Fecha: lunes, 28 de mayo, 2012 05:47
>> CVSROOT:    /usr/cvs
>> Changes by:   
>> jkrell at birch.    12/05/28 10:47:05
>> 
>> Modified files:
>>    cm3/m3-sys/m3cc/gcc-4.6/: configure 
>>    ./: configure 
>>    cm3/m3-sys/m3cc/gcc-4.6/gcc/: Makefile.in
>> auto-inc-dec.c 
>> 
>> 
>>  basic-block.h builtins.c 
>> 
>> 
>>  c-aux-info.c c-convert.c c-decl.c 
>> 
>> 
>>  c-errors.c c-lang.c c-lang.h 
>> 
>> 
>>  c-objc-common.c c-parser.c 
>> 
>> 
>>  c-tree.h c-typeck.c calls.c 
>> 
>> 
>>  cfgexpand.c cfgloop.h cgraph.c 
>> 
>> 
>>  cgraph.h cgraphbuild.c 
>> 
>> 
>>  cgraphunit.c combine.c configure 
>> 
>> 
>>  configure.ac cppdefault.c 
>> 
>> 
>>  cppdefault.h cppspec.c cse.c 
>> 
>> 
>>  expr.c final.c fold-const.c gcc.c 
>> 
>> 
>>  gccspec.c gcse.c gengtype-lex.c 
>> 
>> 
>>  gengtype-lex.l gengtype.c 
>> 
>> 
>>  gimple-fold.c gimple.c gimplify.c 
>> 
>> 
>>  incpath.c intl.c ipa-cp.c 
>> 
>> 
>>  ipa-inline.c ipa-prop.c ipa-prop.h 
>> 
>> 
>>  ipa-ref.h ipa-utils.c ipa.c 
>> 
>> 
>>  ira-build.c ira-conflicts.c 
>> 
>> 
>>  ira-int.h ira.c ira.h libgcov.c 
>> 
>> 
>>  loop-iv.c loop-unswitch.c opts.c 
>> 
>> 
>>  passes.c postreload.c predict.c 
>> 
>> 
>>  profile.c sched-vis.c 
>> 
>> 
>>  sel-sched-dump.c store-motion.c 
>> 
>> 
>>  stringpool.c targhooks.c toplev.c 
>> 
>> 
>>  tree-cfg.c tree-chrec.c 
>> 
>> 
>>  tree-complex.c tree-eh.c 
>> 
>> 
>>  tree-flow.h tree-inline.c 
>> 
>> 
>>  tree-nested.c tree-object-size.c 
>> 
>> 
>>  tree-outof-ssa.c tree-parloops.c 
>> 
>> 
>>  tree-pass.h tree-pretty-print.c 
>> 
>> 
>>  tree-profile.c 
>> 
>> 
>>  tree-scalar-evolution.c tree-sra.c 
>> 
>> 
>>  tree-ssa-address.c 
>> 
>> 
>>  tree-ssa-alias.c 
>> 
>> 
>>  tree-ssa-copyrename.c 
>> 
>> 
>>  tree-ssa-dce.c tree-ssa-dom.c 
>> 
>> 
>>  tree-ssa-loop-ivopts.c 
>> 
>> 
>>  tree-ssa-loop-manip.c 
>> 
>> 
>>  tree-ssa-loop.c tree-ssa-phiopt.c 
>> 
>> 
>>  tree-ssa-structalias.c 
>> 
>> 
>>  tree-ssa-uncprop.c tree-ssa.c 
>> 
>> 
>>  tree-vect-data-refs.c 
>> 
>> 
>>  tree-vect-generic.c 
>> 
>> 
>>  tree-vect-loop-manip.c 
>> 
>> 
>>  tree-vect-loop.c 
>> 
>> 
>>  tree-vect-patterns.c 
>> 
>> 
>>  tree-vect-slp.c tree-vect-stmts.c 
>> 
>> 
>>  tree-vrp.c tree.h unwind-c.c 
>> 
>> 
>>  unwind-compat.c unwind-compat.h 
>> 
>> 
>>  unwind-dw2-fde-compat.c 
>> 
>> 
>>  unwind-dw2-fde-darwin.c 
>> 
>> 
>>  unwind-dw2-fde-glibc.c 
>> 
>> 
>>  unwind-dw2-fde.c unwind-dw2-fde.h 
>> 
>> 
>>  unwind-dw2.c unwind-dw2.h 
>> 
>> 
>>  unwind-generic.h unwind-pe.h 
>> 
>> 
>>  unwind-sjlj.c value-prof.c 
>> 
>> 
>>  var-tracking.c varpool.c web.c 
>>    ./: Makefile.in auto-inc-dec.c
>> basic-block.h builtins.c 
>>        c-aux-info.c c-convert.c
>> c-decl.c c-errors.c c-lang.c 
>>        c-lang.h c-objc-common.c
>> c-parser.c c-tree.h c-typeck.c 
>>        calls.c cfgexpand.c
>> cfgloop.h cgraph.c cgraph.h 
>>        cgraphbuild.c cgraphunit.c
>> combine.c configure configure.ac 
>>        cppdefault.c cppdefault.h
>> cppspec.c cse.c expr.c final.c 
>>        fold-const.c gcc.c
>> gccspec.c gcse.c gengtype-lex.c 
>>        gengtype-lex.l gengtype.c
>> gimple-fold.c gimple.c gimplify.c 
>>        incpath.c intl.c ipa-cp.c
>> ipa-inline.c ipa-prop.c ipa-prop.h 
>>        ipa-ref.h ipa-utils.c ipa.c
>> ira-build.c ira-conflicts.c 
>>        ira-int.h ira.c ira.h
>> libgcov.c loop-iv.c loop-unswitch.c 
>>        opts.c passes.c
>> postreload.c predict.c profile.c sched-vis.c 
>>        sel-sched-dump.c
>> store-motion.c stringpool.c targhooks.c 
>>        toplev.c tree-cfg.c
>> tree-chrec.c tree-complex.c tree-eh.c 
>>        tree-flow.h tree-inline.c
>> tree-nested.c tree-object-size.c 
>>        tree-outof-ssa.c
>> tree-parloops.c tree-pass.h 
>>        tree-pretty-print.c
>> tree-profile.c tree-scalar-evolution.c 
>>        tree-sra.c
>> tree-ssa-address.c tree-ssa-alias.c 
>>        tree-ssa-copyrename.c
>> tree-ssa-dce.c tree-ssa-dom.c 
>>        tree-ssa-loop-ivopts.c
>> tree-ssa-loop-manip.c tree-ssa-loop.c 
>>        tree-ssa-phiopt.c
>> tree-ssa-structalias.c tree-ssa-uncprop.c 
>>        tree-ssa.c
>> tree-vect-data-refs.c tree-vect-generic.c 
>>        tree-vect-loop-manip.c
>> tree-vect-loop.c tree-vect-patterns.c 
>>        tree-vect-slp.c
>> tree-vect-stmts.c tree-vrp.c tree.h 
>>        unwind-c.c unwind-compat.c
>> unwind-compat.h 
>>        unwind-dw2-fde-compat.c
>> unwind-dw2-fde-darwin.c 
>>        unwind-dw2-fde-glibc.c
>> unwind-dw2-fde.c unwind-dw2-fde.h 
>>        unwind-dw2.c unwind-dw2.h
>> unwind-generic.h unwind-pe.h 
>>        unwind-sjlj.c value-prof.c
>> var-tracking.c varpool.c web.c 
>>    cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
>> darwin-protos.h darwin.c 
>> 
>> 
>>         darwin.h 
>>    ./: darwin-protos.h darwin.c darwin.h 
>>    cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
>> crtfastmath.c 
>> 
>> 
>>              crtprec.c 
>> 
>> 
>> 
>> cygming-crtbegin.c 
>> 
>> 
>> 
>> cygming-crtend.c 
>> 
>> 
>>              darwin.h
>> driver-i386.c 
>> 
>> 
>>              gmon-sol2.c
>> i386.c 
>> 
>> 
>> 
>> netware-crt0.c 
>>    ./: crtfastmath.c crtprec.c
>> cygming-crtbegin.c cygming-crtend.c 
>>        darwin.h driver-i386.c
>> gmon-sol2.c i386.c netware-crt0.c 
>>    cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/: lto.c 
>>    ./: lto.c 
>>    cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
>> line-map.h 
>> 
>> Log message:
>>    work in progress -- can compile
>> everything now, but float exception right away
>> 
>> 


From dabenavidesd at yahoo.es  Tue May 29 20:44:26 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 May 2012 19:44:26 +0100 (BST)
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <07F31967-EDA5-4CD7-975C-11F428381AB8@gmail.com>
Message-ID: <1338317066.3447.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
good one, there isn't high-end user needs lately here, so I guess we shouldn't ask if we want to support other machines than just PC, perhaps, we should check more platforms at that level.
Any NT would not be affected but anything else is, HW for testing purposes isn't supported by NT (like debuggers), so there it isn't too much to support for that (lying on MIPS32, and Portable devices sometimes are RISC systems, now what is not aiming NT are desktops but bigger machines) but they are growing down so I don't know if they will become available again.
Thanks of Modula-3 hackers there is still more systems to check for all if interested in any. 
Thanks in advance

--- El lun, 28/5/12, Jay <jay.krell at cornell.edu> escribi?:

> De: Jay <jay.krell at cornell.edu>
> Asunto: Re: [M3commit] CVS Update: cm3
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "<m3commit at elegosoft.com>" <m3commit at elegosoft.com>, "<m3devel at elegosoft.com>" <m3devel at elegosoft.com>
> Fecha: lunes, 28 de mayo, 2012 23:30
> Don't worry about it. I will test
> each platform or get others to before enabling, at least
> some popular majority of them. I no longer have any Alphas.
> Eventually I might ask for ssh access to an Alpha or
> reacquire hardware. Anyway, don't worry. I generally know
> what I'm doing.
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On May 28, 2012, at 7:22 AM, "Daniel Alejandro Benavides D."
> <dabenavidesd at yahoo.es>
> wrote:
> 
> > Hi Jay:
> > Where are you testing this, or have you tested this on
> an Alpha, I might get access, but I notice you dropped the
> libdecnumber, stuff right?
> > Thanks in advance
> > 
> > --- El lun, 28/5/12, Jay Krell <jkrell at elego.de>
> escribi?:
> > 
> >> De: Jay Krell <jkrell at elego.de>
> >> Asunto: [M3commit] CVS Update: cm3
> >> Para: m3commit at elegosoft.com
> >> Fecha: lunes, 28 de mayo, 2012 05:47
> >> CVSROOT:    /usr/cvs
> >> Changes by:   
> >> jkrell at birch.    12/05/28 10:47:05
> >> 
> >> Modified files:
> >>    cm3/m3-sys/m3cc/gcc-4.6/: configure 
> >>    ./: configure 
> >>    cm3/m3-sys/m3cc/gcc-4.6/gcc/:
> Makefile.in
> >> auto-inc-dec.c 
> >> 
> >> 
> >>  basic-block.h builtins.c 
> >> 
> >> 
> >>  c-aux-info.c c-convert.c c-decl.c 
> >> 
> >> 
> >>  c-errors.c c-lang.c c-lang.h 
> >> 
> >> 
> >>  c-objc-common.c c-parser.c 
> >> 
> >> 
> >>  c-tree.h c-typeck.c calls.c 
> >> 
> >> 
> >>  cfgexpand.c cfgloop.h cgraph.c 
> >> 
> >> 
> >>  cgraph.h cgraphbuild.c 
> >> 
> >> 
> >>  cgraphunit.c combine.c configure 
> >> 
> >> 
> >>  configure.ac cppdefault.c 
> >> 
> >> 
> >>  cppdefault.h cppspec.c cse.c 
> >> 
> >> 
> >>  expr.c final.c fold-const.c gcc.c 
> >> 
> >> 
> >>  gccspec.c gcse.c gengtype-lex.c 
> >> 
> >> 
> >>  gengtype-lex.l gengtype.c 
> >> 
> >> 
> >>  gimple-fold.c gimple.c gimplify.c 
> >> 
> >> 
> >>  incpath.c intl.c ipa-cp.c 
> >> 
> >> 
> >>  ipa-inline.c ipa-prop.c ipa-prop.h 
> >> 
> >> 
> >>  ipa-ref.h ipa-utils.c ipa.c 
> >> 
> >> 
> >>  ira-build.c ira-conflicts.c 
> >> 
> >> 
> >>  ira-int.h ira.c ira.h libgcov.c 
> >> 
> >> 
> >>  loop-iv.c loop-unswitch.c opts.c 
> >> 
> >> 
> >>  passes.c postreload.c predict.c 
> >> 
> >> 
> >>  profile.c sched-vis.c 
> >> 
> >> 
> >>  sel-sched-dump.c store-motion.c 
> >> 
> >> 
> >>  stringpool.c targhooks.c toplev.c 
> >> 
> >> 
> >>  tree-cfg.c tree-chrec.c 
> >> 
> >> 
> >>  tree-complex.c tree-eh.c 
> >> 
> >> 
> >>  tree-flow.h tree-inline.c 
> >> 
> >> 
> >>  tree-nested.c tree-object-size.c 
> >> 
> >> 
> >>  tree-outof-ssa.c tree-parloops.c 
> >> 
> >> 
> >>  tree-pass.h tree-pretty-print.c 
> >> 
> >> 
> >>  tree-profile.c 
> >> 
> >> 
> >>  tree-scalar-evolution.c tree-sra.c 
> >> 
> >> 
> >>  tree-ssa-address.c 
> >> 
> >> 
> >>  tree-ssa-alias.c 
> >> 
> >> 
> >>  tree-ssa-copyrename.c 
> >> 
> >> 
> >>  tree-ssa-dce.c tree-ssa-dom.c 
> >> 
> >> 
> >>  tree-ssa-loop-ivopts.c 
> >> 
> >> 
> >>  tree-ssa-loop-manip.c 
> >> 
> >> 
> >>  tree-ssa-loop.c tree-ssa-phiopt.c 
> >> 
> >> 
> >>  tree-ssa-structalias.c 
> >> 
> >> 
> >>  tree-ssa-uncprop.c tree-ssa.c 
> >> 
> >> 
> >>  tree-vect-data-refs.c 
> >> 
> >> 
> >>  tree-vect-generic.c 
> >> 
> >> 
> >>  tree-vect-loop-manip.c 
> >> 
> >> 
> >>  tree-vect-loop.c 
> >> 
> >> 
> >>  tree-vect-patterns.c 
> >> 
> >> 
> >>  tree-vect-slp.c tree-vect-stmts.c 
> >> 
> >> 
> >>  tree-vrp.c tree.h unwind-c.c 
> >> 
> >> 
> >>  unwind-compat.c unwind-compat.h 
> >> 
> >> 
> >>  unwind-dw2-fde-compat.c 
> >> 
> >> 
> >>  unwind-dw2-fde-darwin.c 
> >> 
> >> 
> >>  unwind-dw2-fde-glibc.c 
> >> 
> >> 
> >>  unwind-dw2-fde.c unwind-dw2-fde.h 
> >> 
> >> 
> >>  unwind-dw2.c unwind-dw2.h 
> >> 
> >> 
> >>  unwind-generic.h unwind-pe.h 
> >> 
> >> 
> >>  unwind-sjlj.c value-prof.c 
> >> 
> >> 
> >>  var-tracking.c varpool.c web.c 
> >>    ./: Makefile.in auto-inc-dec.c
> >> basic-block.h builtins.c 
> >>        c-aux-info.c
> c-convert.c
> >> c-decl.c c-errors.c c-lang.c 
> >>        c-lang.h
> c-objc-common.c
> >> c-parser.c c-tree.h c-typeck.c 
> >>        calls.c cfgexpand.c
> >> cfgloop.h cgraph.c cgraph.h 
> >>        cgraphbuild.c
> cgraphunit.c
> >> combine.c configure configure.ac 
> >>        cppdefault.c
> cppdefault.h
> >> cppspec.c cse.c expr.c final.c 
> >>        fold-const.c gcc.c
> >> gccspec.c gcse.c gengtype-lex.c 
> >>        gengtype-lex.l
> gengtype.c
> >> gimple-fold.c gimple.c gimplify.c 
> >>        incpath.c intl.c
> ipa-cp.c
> >> ipa-inline.c ipa-prop.c ipa-prop.h 
> >>        ipa-ref.h ipa-utils.c
> ipa.c
> >> ira-build.c ira-conflicts.c 
> >>        ira-int.h ira.c ira.h
> >> libgcov.c loop-iv.c loop-unswitch.c 
> >>        opts.c passes.c
> >> postreload.c predict.c profile.c sched-vis.c 
> >>        sel-sched-dump.c
> >> store-motion.c stringpool.c targhooks.c 
> >>        toplev.c tree-cfg.c
> >> tree-chrec.c tree-complex.c tree-eh.c 
> >>        tree-flow.h
> tree-inline.c
> >> tree-nested.c tree-object-size.c 
> >>        tree-outof-ssa.c
> >> tree-parloops.c tree-pass.h 
> >>        tree-pretty-print.c
> >> tree-profile.c tree-scalar-evolution.c 
> >>        tree-sra.c
> >> tree-ssa-address.c tree-ssa-alias.c 
> >>        tree-ssa-copyrename.c
> >> tree-ssa-dce.c tree-ssa-dom.c 
> >>        tree-ssa-loop-ivopts.c
> >> tree-ssa-loop-manip.c tree-ssa-loop.c 
> >>        tree-ssa-phiopt.c
> >> tree-ssa-structalias.c tree-ssa-uncprop.c 
> >>        tree-ssa.c
> >> tree-vect-data-refs.c tree-vect-generic.c 
> >>        tree-vect-loop-manip.c
> >> tree-vect-loop.c tree-vect-patterns.c 
> >>        tree-vect-slp.c
> >> tree-vect-stmts.c tree-vrp.c tree.h 
> >>        unwind-c.c
> unwind-compat.c
> >> unwind-compat.h 
> >>        unwind-dw2-fde-compat.c
> >> unwind-dw2-fde-darwin.c 
> >>        unwind-dw2-fde-glibc.c
> >> unwind-dw2-fde.c unwind-dw2-fde.h 
> >>        unwind-dw2.c
> unwind-dw2.h
> >> unwind-generic.h unwind-pe.h 
> >>        unwind-sjlj.c
> value-prof.c
> >> var-tracking.c varpool.c web.c 
> >>    cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
> >> darwin-protos.h darwin.c 
> >> 
> >> 
> >>         darwin.h 
> >>    ./: darwin-protos.h darwin.c darwin.h
> 
> >>   
> cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
> >> crtfastmath.c 
> >> 
> >> 
> >>             
> crtprec.c 
> >> 
> >> 
> >> 
> >> cygming-crtbegin.c 
> >> 
> >> 
> >> 
> >> cygming-crtend.c 
> >> 
> >> 
> >>             
> darwin.h
> >> driver-i386.c 
> >> 
> >> 
> >>             
> gmon-sol2.c
> >> i386.c 
> >> 
> >> 
> >> 
> >> netware-crt0.c 
> >>    ./: crtfastmath.c crtprec.c
> >> cygming-crtbegin.c cygming-crtend.c 
> >>        darwin.h driver-i386.c
> >> gmon-sol2.c i386.c netware-crt0.c 
> >>    cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/:
> lto.c 
> >>    ./: lto.c 
> >>   
> cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
> >> line-map.h 
> >> 
> >> Log message:
> >>    work in progress -- can compile
> >> everything now, but float exception right away
> >> 
> >> 
> 


From jay.krell at cornell.edu  Wed May 30 01:15:48 2012
From: jay.krell at cornell.edu (Jay)
Date: Tue, 29 May 2012 16:15:48 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <1338317066.3447.YahooMailClassic@web29704.mail.ird.yahoo.com>
References: <1338317066.3447.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <1572EB44-615A-4224-948B-DDC3DB23E57C@gmail.com>

Daniel you don't make sense.

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 29, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> good one, there isn't high-end user needs lately here, so I guess we shouldn't ask if we want to support other machines than just PC, perhaps, we should check more platforms at that level.
> Any NT would not be affected but anything else is, HW for testing purposes isn't supported by NT (like debuggers), so there it isn't too much to support for that (lying on MIPS32, and Portable devices sometimes are RISC systems, now what is not aiming NT are desktops but bigger machines) but they are growing down so I don't know if they will become available again.
> Thanks of Modula-3 hackers there is still more systems to check for all if interested in any. 
> Thanks in advance
> 
> --- El lun, 28/5/12, Jay <jay.krell at cornell.edu> escribi?:
> 
>> De: Jay <jay.krell at cornell.edu>
>> Asunto: Re: [M3commit] CVS Update: cm3
>> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
>> CC: "<m3commit at elegosoft.com>" <m3commit at elegosoft.com>, "<m3devel at elegosoft.com>" <m3devel at elegosoft.com>
>> Fecha: lunes, 28 de mayo, 2012 23:30
>> Don't worry about it. I will test
>> each platform or get others to before enabling, at least
>> some popular majority of them. I no longer have any Alphas.
>> Eventually I might ask for ssh access to an Alpha or
>> reacquire hardware. Anyway, don't worry. I generally know
>> what I'm doing.
>> 
>> - Jay (briefly/pocket-sized-computer-aka-phone)
>> 
>> On May 28, 2012, at 7:22 AM, "Daniel Alejandro Benavides D."
>> <dabenavidesd at yahoo.es>
>> wrote:
>> 
>>> Hi Jay:
>>> Where are you testing this, or have you tested this on
>> an Alpha, I might get access, but I notice you dropped the
>> libdecnumber, stuff right?
>>> Thanks in advance
>>> 
>>> --- El lun, 28/5/12, Jay Krell <jkrell at elego.de>
>> escribi?:
>>> 
>>>> De: Jay Krell <jkrell at elego.de>
>>>> Asunto: [M3commit] CVS Update: cm3
>>>> Para: m3commit at elegosoft.com
>>>> Fecha: lunes, 28 de mayo, 2012 05:47
>>>> CVSROOT:    /usr/cvs
>>>> Changes by:   
>>>> jkrell at birch.    12/05/28 10:47:05
>>>> 
>>>> Modified files:
>>>>   cm3/m3-sys/m3cc/gcc-4.6/: configure 
>>>>   ./: configure 
>>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/:
>> Makefile.in
>>>> auto-inc-dec.c 
>>>> 
>>>> 
>>>> basic-block.h builtins.c 
>>>> 
>>>> 
>>>> c-aux-info.c c-convert.c c-decl.c 
>>>> 
>>>> 
>>>> c-errors.c c-lang.c c-lang.h 
>>>> 
>>>> 
>>>> c-objc-common.c c-parser.c 
>>>> 
>>>> 
>>>> c-tree.h c-typeck.c calls.c 
>>>> 
>>>> 
>>>> cfgexpand.c cfgloop.h cgraph.c 
>>>> 
>>>> 
>>>> cgraph.h cgraphbuild.c 
>>>> 
>>>> 
>>>> cgraphunit.c combine.c configure 
>>>> 
>>>> 
>>>> configure.ac cppdefault.c 
>>>> 
>>>> 
>>>> cppdefault.h cppspec.c cse.c 
>>>> 
>>>> 
>>>> expr.c final.c fold-const.c gcc.c 
>>>> 
>>>> 
>>>> gccspec.c gcse.c gengtype-lex.c 
>>>> 
>>>> 
>>>> gengtype-lex.l gengtype.c 
>>>> 
>>>> 
>>>> gimple-fold.c gimple.c gimplify.c 
>>>> 
>>>> 
>>>> incpath.c intl.c ipa-cp.c 
>>>> 
>>>> 
>>>> ipa-inline.c ipa-prop.c ipa-prop.h 
>>>> 
>>>> 
>>>> ipa-ref.h ipa-utils.c ipa.c 
>>>> 
>>>> 
>>>> ira-build.c ira-conflicts.c 
>>>> 
>>>> 
>>>> ira-int.h ira.c ira.h libgcov.c 
>>>> 
>>>> 
>>>> loop-iv.c loop-unswitch.c opts.c 
>>>> 
>>>> 
>>>> passes.c postreload.c predict.c 
>>>> 
>>>> 
>>>> profile.c sched-vis.c 
>>>> 
>>>> 
>>>> sel-sched-dump.c store-motion.c 
>>>> 
>>>> 
>>>> stringpool.c targhooks.c toplev.c 
>>>> 
>>>> 
>>>> tree-cfg.c tree-chrec.c 
>>>> 
>>>> 
>>>> tree-complex.c tree-eh.c 
>>>> 
>>>> 
>>>> tree-flow.h tree-inline.c 
>>>> 
>>>> 
>>>> tree-nested.c tree-object-size.c 
>>>> 
>>>> 
>>>> tree-outof-ssa.c tree-parloops.c 
>>>> 
>>>> 
>>>> tree-pass.h tree-pretty-print.c 
>>>> 
>>>> 
>>>> tree-profile.c 
>>>> 
>>>> 
>>>> tree-scalar-evolution.c tree-sra.c 
>>>> 
>>>> 
>>>> tree-ssa-address.c 
>>>> 
>>>> 
>>>> tree-ssa-alias.c 
>>>> 
>>>> 
>>>> tree-ssa-copyrename.c 
>>>> 
>>>> 
>>>> tree-ssa-dce.c tree-ssa-dom.c 
>>>> 
>>>> 
>>>> tree-ssa-loop-ivopts.c 
>>>> 
>>>> 
>>>> tree-ssa-loop-manip.c 
>>>> 
>>>> 
>>>> tree-ssa-loop.c tree-ssa-phiopt.c 
>>>> 
>>>> 
>>>> tree-ssa-structalias.c 
>>>> 
>>>> 
>>>> tree-ssa-uncprop.c tree-ssa.c 
>>>> 
>>>> 
>>>> tree-vect-data-refs.c 
>>>> 
>>>> 
>>>> tree-vect-generic.c 
>>>> 
>>>> 
>>>> tree-vect-loop-manip.c 
>>>> 
>>>> 
>>>> tree-vect-loop.c 
>>>> 
>>>> 
>>>> tree-vect-patterns.c 
>>>> 
>>>> 
>>>> tree-vect-slp.c tree-vect-stmts.c 
>>>> 
>>>> 
>>>> tree-vrp.c tree.h unwind-c.c 
>>>> 
>>>> 
>>>> unwind-compat.c unwind-compat.h 
>>>> 
>>>> 
>>>> unwind-dw2-fde-compat.c 
>>>> 
>>>> 
>>>> unwind-dw2-fde-darwin.c 
>>>> 
>>>> 
>>>> unwind-dw2-fde-glibc.c 
>>>> 
>>>> 
>>>> unwind-dw2-fde.c unwind-dw2-fde.h 
>>>> 
>>>> 
>>>> unwind-dw2.c unwind-dw2.h 
>>>> 
>>>> 
>>>> unwind-generic.h unwind-pe.h 
>>>> 
>>>> 
>>>> unwind-sjlj.c value-prof.c 
>>>> 
>>>> 
>>>> var-tracking.c varpool.c web.c 
>>>>   ./: Makefile.in auto-inc-dec.c
>>>> basic-block.h builtins.c 
>>>>       c-aux-info.c
>> c-convert.c
>>>> c-decl.c c-errors.c c-lang.c 
>>>>       c-lang.h
>> c-objc-common.c
>>>> c-parser.c c-tree.h c-typeck.c 
>>>>       calls.c cfgexpand.c
>>>> cfgloop.h cgraph.c cgraph.h 
>>>>       cgraphbuild.c
>> cgraphunit.c
>>>> combine.c configure configure.ac 
>>>>       cppdefault.c
>> cppdefault.h
>>>> cppspec.c cse.c expr.c final.c 
>>>>       fold-const.c gcc.c
>>>> gccspec.c gcse.c gengtype-lex.c 
>>>>       gengtype-lex.l
>> gengtype.c
>>>> gimple-fold.c gimple.c gimplify.c 
>>>>       incpath.c intl.c
>> ipa-cp.c
>>>> ipa-inline.c ipa-prop.c ipa-prop.h 
>>>>       ipa-ref.h ipa-utils.c
>> ipa.c
>>>> ira-build.c ira-conflicts.c 
>>>>       ira-int.h ira.c ira.h
>>>> libgcov.c loop-iv.c loop-unswitch.c 
>>>>       opts.c passes.c
>>>> postreload.c predict.c profile.c sched-vis.c 
>>>>       sel-sched-dump.c
>>>> store-motion.c stringpool.c targhooks.c 
>>>>       toplev.c tree-cfg.c
>>>> tree-chrec.c tree-complex.c tree-eh.c 
>>>>       tree-flow.h
>> tree-inline.c
>>>> tree-nested.c tree-object-size.c 
>>>>       tree-outof-ssa.c
>>>> tree-parloops.c tree-pass.h 
>>>>       tree-pretty-print.c
>>>> tree-profile.c tree-scalar-evolution.c 
>>>>       tree-sra.c
>>>> tree-ssa-address.c tree-ssa-alias.c 
>>>>       tree-ssa-copyrename.c
>>>> tree-ssa-dce.c tree-ssa-dom.c 
>>>>       tree-ssa-loop-ivopts.c
>>>> tree-ssa-loop-manip.c tree-ssa-loop.c 
>>>>       tree-ssa-phiopt.c
>>>> tree-ssa-structalias.c tree-ssa-uncprop.c 
>>>>       tree-ssa.c
>>>> tree-vect-data-refs.c tree-vect-generic.c 
>>>>       tree-vect-loop-manip.c
>>>> tree-vect-loop.c tree-vect-patterns.c 
>>>>       tree-vect-slp.c
>>>> tree-vect-stmts.c tree-vrp.c tree.h 
>>>>       unwind-c.c
>> unwind-compat.c
>>>> unwind-compat.h 
>>>>       unwind-dw2-fde-compat.c
>>>> unwind-dw2-fde-darwin.c 
>>>>       unwind-dw2-fde-glibc.c
>>>> unwind-dw2-fde.c unwind-dw2-fde.h 
>>>>       unwind-dw2.c
>> unwind-dw2.h
>>>> unwind-generic.h unwind-pe.h 
>>>>       unwind-sjlj.c
>> value-prof.c
>>>> var-tracking.c varpool.c web.c 
>>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
>>>> darwin-protos.h darwin.c 
>>>> 
>>>> 
>>>>        darwin.h 
>>>>   ./: darwin-protos.h darwin.c darwin.h
>> 
>>>> 
>> cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
>>>> crtfastmath.c 
>>>> 
>>>> 
>>>> 
>> crtprec.c 
>>>> 
>>>> 
>>>> 
>>>> cygming-crtbegin.c 
>>>> 
>>>> 
>>>> 
>>>> cygming-crtend.c 
>>>> 
>>>> 
>>>> 
>> darwin.h
>>>> driver-i386.c 
>>>> 
>>>> 
>>>> 
>> gmon-sol2.c
>>>> i386.c 
>>>> 
>>>> 
>>>> 
>>>> netware-crt0.c 
>>>>   ./: crtfastmath.c crtprec.c
>>>> cygming-crtbegin.c cygming-crtend.c 
>>>>       darwin.h driver-i386.c
>>>> gmon-sol2.c i386.c netware-crt0.c 
>>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/:
>> lto.c 
>>>>   ./: lto.c 
>>>> 
>> cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
>>>> line-map.h 
>>>> 
>>>> Log message:
>>>>   work in progress -- can compile
>>>> everything now, but float exception right away
>>>> 
>>>> 
>> 


From dabenavidesd at yahoo.es  Wed May 30 02:03:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 01:03:34 +0100 (BST)
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <1572EB44-615A-4224-948B-DDC3DB23E57C@gmail.com>
Message-ID: <1338336214.27113.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
in reality PC AT aren't 64 bits wide, I guess in reality you can add a memory board to a i386 and that's it. Is just that same thing.
Bigger registers aren't a difference (the double number of registers and that's it for a register-based machine, like another ix86, the 82786 GPU for coprocessor and that's all), this is the same concept for a GPGPU nowadays, and they don't care at all to maintain compatibility to it so nobody has created a real 64-bit system after Tru64 and some other Unixes are, like Monterey project.
I mean there aren't real 64 bit systems, so I guess there isn't anything to test here in Gcc targets for real for PCs, they are the same that long before.
We don't have any new real HW or SW adapted for real so I don't know what else can be test.
Thanks in advance


--- El mar, 29/5/12, Jay <jay.krell at cornell.edu> escribi?:

> De: Jay <jay.krell at cornell.edu>
> Asunto: Re: [M3commit] CVS Update: cm3
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "Jay" <jay.krell at cornell.edu>, "<m3commit at elegosoft.com>" <m3commit at elegosoft.com>, "<m3devel at elegosoft.com>" <m3devel at elegosoft.com>
> Fecha: martes, 29 de mayo, 2012 18:15
> Daniel you don't make sense.
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On May 29, 2012, at 11:44 AM, "Daniel Alejandro Benavides
> D." <dabenavidesd at yahoo.es>
> wrote:
> 
> > Hi all:
> > good one, there isn't high-end user needs lately here,
> so I guess we shouldn't ask if we want to support other
> machines than just PC, perhaps, we should check more
> platforms at that level.
> > Any NT would not be affected but anything else is, HW
> for testing purposes isn't supported by NT (like debuggers),
> so there it isn't too much to support for that (lying on
> MIPS32, and Portable devices sometimes are RISC systems, now
> what is not aiming NT are desktops but bigger machines) but
> they are growing down so I don't know if they will become
> available again.
> > Thanks of Modula-3 hackers there is still more systems
> to check for all if interested in any. 
> > Thanks in advance
> > 
> > --- El lun, 28/5/12, Jay <jay.krell at cornell.edu>
> escribi?:
> > 
> >> De: Jay <jay.krell at cornell.edu>
> >> Asunto: Re: [M3commit] CVS Update: cm3
> >> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> >> CC: "<m3commit at elegosoft.com>"
> <m3commit at elegosoft.com>,
> "<m3devel at elegosoft.com>"
> <m3devel at elegosoft.com>
> >> Fecha: lunes, 28 de mayo, 2012 23:30
> >> Don't worry about it. I will test
> >> each platform or get others to before enabling, at
> least
> >> some popular majority of them. I no longer have any
> Alphas.
> >> Eventually I might ask for ssh access to an Alpha
> or
> >> reacquire hardware. Anyway, don't worry. I
> generally know
> >> what I'm doing.
> >> 
> >> - Jay (briefly/pocket-sized-computer-aka-phone)
> >> 
> >> On May 28, 2012, at 7:22 AM, "Daniel Alejandro
> Benavides D."
> >> <dabenavidesd at yahoo.es>
> >> wrote:
> >> 
> >>> Hi Jay:
> >>> Where are you testing this, or have you tested
> this on
> >> an Alpha, I might get access, but I notice you
> dropped the
> >> libdecnumber, stuff right?
> >>> Thanks in advance
> >>> 
> >>> --- El lun, 28/5/12, Jay Krell <jkrell at elego.de>
> >> escribi?:
> >>> 
> >>>> De: Jay Krell <jkrell at elego.de>
> >>>> Asunto: [M3commit] CVS Update: cm3
> >>>> Para: m3commit at elegosoft.com
> >>>> Fecha: lunes, 28 de mayo, 2012 05:47
> >>>> CVSROOT:    /usr/cvs
> >>>> Changes by:   
> >>>> jkrell at birch.    12/05/28
> 10:47:05
> >>>> 
> >>>> Modified files:
> >>>>   cm3/m3-sys/m3cc/gcc-4.6/:
> configure 
> >>>>   ./: configure 
> >>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/:
> >> Makefile.in
> >>>> auto-inc-dec.c 
> >>>> 
> >>>> 
> >>>> basic-block.h builtins.c 
> >>>> 
> >>>> 
> >>>> c-aux-info.c c-convert.c c-decl.c 
> >>>> 
> >>>> 
> >>>> c-errors.c c-lang.c c-lang.h 
> >>>> 
> >>>> 
> >>>> c-objc-common.c c-parser.c 
> >>>> 
> >>>> 
> >>>> c-tree.h c-typeck.c calls.c 
> >>>> 
> >>>> 
> >>>> cfgexpand.c cfgloop.h cgraph.c 
> >>>> 
> >>>> 
> >>>> cgraph.h cgraphbuild.c 
> >>>> 
> >>>> 
> >>>> cgraphunit.c combine.c configure 
> >>>> 
> >>>> 
> >>>> configure.ac cppdefault.c 
> >>>> 
> >>>> 
> >>>> cppdefault.h cppspec.c cse.c 
> >>>> 
> >>>> 
> >>>> expr.c final.c fold-const.c gcc.c 
> >>>> 
> >>>> 
> >>>> gccspec.c gcse.c gengtype-lex.c 
> >>>> 
> >>>> 
> >>>> gengtype-lex.l gengtype.c 
> >>>> 
> >>>> 
> >>>> gimple-fold.c gimple.c gimplify.c 
> >>>> 
> >>>> 
> >>>> incpath.c intl.c ipa-cp.c 
> >>>> 
> >>>> 
> >>>> ipa-inline.c ipa-prop.c ipa-prop.h 
> >>>> 
> >>>> 
> >>>> ipa-ref.h ipa-utils.c ipa.c 
> >>>> 
> >>>> 
> >>>> ira-build.c ira-conflicts.c 
> >>>> 
> >>>> 
> >>>> ira-int.h ira.c ira.h libgcov.c 
> >>>> 
> >>>> 
> >>>> loop-iv.c loop-unswitch.c opts.c 
> >>>> 
> >>>> 
> >>>> passes.c postreload.c predict.c 
> >>>> 
> >>>> 
> >>>> profile.c sched-vis.c 
> >>>> 
> >>>> 
> >>>> sel-sched-dump.c store-motion.c 
> >>>> 
> >>>> 
> >>>> stringpool.c targhooks.c toplev.c 
> >>>> 
> >>>> 
> >>>> tree-cfg.c tree-chrec.c 
> >>>> 
> >>>> 
> >>>> tree-complex.c tree-eh.c 
> >>>> 
> >>>> 
> >>>> tree-flow.h tree-inline.c 
> >>>> 
> >>>> 
> >>>> tree-nested.c tree-object-size.c 
> >>>> 
> >>>> 
> >>>> tree-outof-ssa.c tree-parloops.c 
> >>>> 
> >>>> 
> >>>> tree-pass.h tree-pretty-print.c 
> >>>> 
> >>>> 
> >>>> tree-profile.c 
> >>>> 
> >>>> 
> >>>> tree-scalar-evolution.c tree-sra.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-address.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-alias.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-copyrename.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-dce.c tree-ssa-dom.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-loop-ivopts.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-loop-manip.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-loop.c tree-ssa-phiopt.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-structalias.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-uncprop.c tree-ssa.c 
> >>>> 
> >>>> 
> >>>> tree-vect-data-refs.c 
> >>>> 
> >>>> 
> >>>> tree-vect-generic.c 
> >>>> 
> >>>> 
> >>>> tree-vect-loop-manip.c 
> >>>> 
> >>>> 
> >>>> tree-vect-loop.c 
> >>>> 
> >>>> 
> >>>> tree-vect-patterns.c 
> >>>> 
> >>>> 
> >>>> tree-vect-slp.c tree-vect-stmts.c 
> >>>> 
> >>>> 
> >>>> tree-vrp.c tree.h unwind-c.c 
> >>>> 
> >>>> 
> >>>> unwind-compat.c unwind-compat.h 
> >>>> 
> >>>> 
> >>>> unwind-dw2-fde-compat.c 
> >>>> 
> >>>> 
> >>>> unwind-dw2-fde-darwin.c 
> >>>> 
> >>>> 
> >>>> unwind-dw2-fde-glibc.c 
> >>>> 
> >>>> 
> >>>> unwind-dw2-fde.c unwind-dw2-fde.h 
> >>>> 
> >>>> 
> >>>> unwind-dw2.c unwind-dw2.h 
> >>>> 
> >>>> 
> >>>> unwind-generic.h unwind-pe.h 
> >>>> 
> >>>> 
> >>>> unwind-sjlj.c value-prof.c 
> >>>> 
> >>>> 
> >>>> var-tracking.c varpool.c web.c 
> >>>>   ./: Makefile.in
> auto-inc-dec.c
> >>>> basic-block.h builtins.c 
> >>>>   
>    c-aux-info.c
> >> c-convert.c
> >>>> c-decl.c c-errors.c c-lang.c 
> >>>>       c-lang.h
> >> c-objc-common.c
> >>>> c-parser.c c-tree.h c-typeck.c 
> >>>>       calls.c
> cfgexpand.c
> >>>> cfgloop.h cgraph.c cgraph.h 
> >>>>   
>    cgraphbuild.c
> >> cgraphunit.c
> >>>> combine.c configure configure.ac 
> >>>>   
>    cppdefault.c
> >> cppdefault.h
> >>>> cppspec.c cse.c expr.c final.c 
> >>>>       fold-const.c
> gcc.c
> >>>> gccspec.c gcse.c gengtype-lex.c 
> >>>>   
>    gengtype-lex.l
> >> gengtype.c
> >>>> gimple-fold.c gimple.c gimplify.c 
> >>>>       incpath.c
> intl.c
> >> ipa-cp.c
> >>>> ipa-inline.c ipa-prop.c ipa-prop.h 
> >>>>       ipa-ref.h
> ipa-utils.c
> >> ipa.c
> >>>> ira-build.c ira-conflicts.c 
> >>>>       ira-int.h
> ira.c ira.h
> >>>> libgcov.c loop-iv.c loop-unswitch.c 
> >>>>       opts.c
> passes.c
> >>>> postreload.c predict.c profile.c
> sched-vis.c 
> >>>>   
>    sel-sched-dump.c
> >>>> store-motion.c stringpool.c targhooks.c 
> >>>>       toplev.c
> tree-cfg.c
> >>>> tree-chrec.c tree-complex.c tree-eh.c 
> >>>>       tree-flow.h
> >> tree-inline.c
> >>>> tree-nested.c tree-object-size.c 
> >>>>   
>    tree-outof-ssa.c
> >>>> tree-parloops.c tree-pass.h 
> >>>>   
>    tree-pretty-print.c
> >>>> tree-profile.c tree-scalar-evolution.c 
> >>>>       tree-sra.c
> >>>> tree-ssa-address.c tree-ssa-alias.c 
> >>>>   
>    tree-ssa-copyrename.c
> >>>> tree-ssa-dce.c tree-ssa-dom.c 
> >>>>   
>    tree-ssa-loop-ivopts.c
> >>>> tree-ssa-loop-manip.c tree-ssa-loop.c 
> >>>>   
>    tree-ssa-phiopt.c
> >>>> tree-ssa-structalias.c tree-ssa-uncprop.c 
> >>>>       tree-ssa.c
> >>>> tree-vect-data-refs.c tree-vect-generic.c 
> >>>>   
>    tree-vect-loop-manip.c
> >>>> tree-vect-loop.c tree-vect-patterns.c 
> >>>>   
>    tree-vect-slp.c
> >>>> tree-vect-stmts.c tree-vrp.c tree.h 
> >>>>       unwind-c.c
> >> unwind-compat.c
> >>>> unwind-compat.h 
> >>>>   
>    unwind-dw2-fde-compat.c
> >>>> unwind-dw2-fde-darwin.c 
> >>>>   
>    unwind-dw2-fde-glibc.c
> >>>> unwind-dw2-fde.c unwind-dw2-fde.h 
> >>>>   
>    unwind-dw2.c
> >> unwind-dw2.h
> >>>> unwind-generic.h unwind-pe.h 
> >>>>   
>    unwind-sjlj.c
> >> value-prof.c
> >>>> var-tracking.c varpool.c web.c 
> >>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
> >>>> darwin-protos.h darwin.c 
> >>>> 
> >>>> 
> >>>>        darwin.h 
> >>>>   ./: darwin-protos.h
> darwin.c darwin.h
> >> 
> >>>> 
> >> cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
> >>>> crtfastmath.c 
> >>>> 
> >>>> 
> >>>> 
> >> crtprec.c 
> >>>> 
> >>>> 
> >>>> 
> >>>> cygming-crtbegin.c 
> >>>> 
> >>>> 
> >>>> 
> >>>> cygming-crtend.c 
> >>>> 
> >>>> 
> >>>> 
> >> darwin.h
> >>>> driver-i386.c 
> >>>> 
> >>>> 
> >>>> 
> >> gmon-sol2.c
> >>>> i386.c 
> >>>> 
> >>>> 
> >>>> 
> >>>> netware-crt0.c 
> >>>>   ./: crtfastmath.c
> crtprec.c
> >>>> cygming-crtbegin.c cygming-crtend.c 
> >>>>       darwin.h
> driver-i386.c
> >>>> gmon-sol2.c i386.c netware-crt0.c 
> >>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/:
> >> lto.c 
> >>>>   ./: lto.c 
> >>>> 
> >> cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
> >>>> line-map.h 
> >>>> 
> >>>> Log message:
> >>>>   work in progress -- can
> compile
> >>>> everything now, but float exception right
> away
> >>>> 
> >>>> 
> >> 
> 


From dragisha at m3w.org  Wed May 30 10:54:08 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 30 May 2012 10:54:08 +0200
Subject: [M3devel] portable hosting
In-Reply-To: <1338240156.6219.YahooMailClassic@web29704.mail.ird.yahoo.com>
References: <1338240156.6219.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>

Daniel,

I like your project. Please inform us on updates, when available!

Thanks in advance,
dd

p.s. :)

On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> or better make an assembly-coded C compiler in a Java language processor, and cross-boot assemble from a Modula-3 environment there so you could bootstrap a M3CG-system there.
> Thanks in advance
> 
> --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:
> 
>> De: Hendrik Boom <hendrik at topoi.pooq.com>
>> Asunto: [M3devel] portable hosting
>> Para: m3devel at elegosoft.com
>> Fecha: lunes, 28 de mayo, 2012 11:50
>> On Sun, May 20, 2012 at 02:32:14PM
>> -0700, Jay wrote:
>>> 
>>> Btw, rewriting all of m3front in C or C++ or Java
>> probably wouldn't be very difficult.
>> 
>> Would it be more or less difficult than writing a code
>> generator that 
>> generated C or C++ code?  THe code generator could do
>> the rewrite for 
>> you.  Bt it wouldn't be very readable code.
>> 



From dabenavidesd at yahoo.es  Wed May 30 13:34:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 12:34:24 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
Message-ID: <1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I like the option but because there isn't more than that in a featured phone, which is the most common kind of thing in this world; S40, has its own JVM, if this about popularity.
Crazy and simple as it is.

Thanks in advance

--- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] portable hosting
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> Daniel,
> 
> I like your project. Please inform us on updates, when
> available!
> 
> Thanks in advance,
> dd
> 
> p.s. :)
> 
> On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> wrote:
> 
> > Hi all:
> > or better make an assembly-coded C compiler in a Java
> language processor, and cross-boot assemble from a Modula-3
> environment there so you could bootstrap a M3CG-system
> there.
> > Thanks in advance
> > 
> > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> escribi?:
> > 
> >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> >> Asunto: [M3devel] portable hosting
> >> Para: m3devel at elegosoft.com
> >> Fecha: lunes, 28 de mayo, 2012 11:50
> >> On Sun, May 20, 2012 at 02:32:14PM
> >> -0700, Jay wrote:
> >>> 
> >>> Btw, rewriting all of m3front in C or C++ or
> Java
> >> probably wouldn't be very difficult.
> >> 
> >> Would it be more or less difficult than writing a
> code
> >> generator that 
> >> generated C or C++ code?  THe code generator
> could do
> >> the rewrite for 
> >> you.  Bt it wouldn't be very readable code.
> >> 
> 
> 


From dragisha at m3w.org  Wed May 30 14:03:39 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 30 May 2012 14:03:39 +0200
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <COL101-W1C8E7FBA8B4CC5793DC42E6010@phx.gbl>
References: <555EDB08-5E0A-472A-9D93-FD890F924303@m3w.org>,
	<1337979476.29484.YahooMailClassic@web29703.mail.ird.yahoo.com>
	<COL101-W1C8E7FBA8B4CC5793DC42E6010@phx.gbl>
Message-ID: <0F4CD174-3D70-4A2C-8F11-461E1C4A1C5E@m3w.org>

Of course.


On May 26, 2012, at 12:09 AM, Jay K wrote:

> -DNOPTHREAD only directly changes m3core.
> The rest of the system can be compiled w/ or w/o it. But the new m3core causes a need for some rebuild.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120530/02a4f856/attachment-0001.html>

From hendrik at topoi.pooq.com  Wed May 30 14:20:57 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 30 May 2012 08:20:57 -0400
Subject: [M3devel] portable hosting
In-Reply-To: <1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
	<1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <20120530122057.GA28287@topoi.pooq.com>

I've only heard of two different Java virtual machines -- the one Sun 
wrote, which I believe has been independently implementedonce or twice, 
and the one Google wrote as part of Android, which is designed for 
efficient JIT compilation.

Is this one of these, or is there yet another?

-- hendrik

On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all:
> I like the option but because there isn't more than that in a featured 
> phone, which is the most common kind of thing in this world; S40, has 
> its own JVM, if this about popularity.
> Crazy and simple as it is.
> 
> Thanks in advance
> 
> --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> > De: Dragi?a Duri? <dragisha at m3w.org>
> > Asunto: Re: [M3devel] portable hosting
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > Daniel,
> > 
> > I like your project. Please inform us on updates, when
> > available!
> > 
> > Thanks in advance,
> > dd
> > 
> > p.s. :)
> > 
> > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > wrote:
> > 
> > > Hi all:
> > > or better make an assembly-coded C compiler in a Java
> > language processor, and cross-boot assemble from a Modula-3
> > environment there so you could bootstrap a M3CG-system
> > there.
> > > Thanks in advance
> > > 
> > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > escribi?:
> > > 
> > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > >> Asunto: [M3devel] portable hosting
> > >> Para: m3devel at elegosoft.com
> > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > >> On Sun, May 20, 2012 at 02:32:14PM
> > >> -0700, Jay wrote:
> > >>> 
> > >>> Btw, rewriting all of m3front in C or C++ or
> > Java
> > >> probably wouldn't be very difficult.
> > >> 
> > >> Would it be more or less difficult than writing a
> > code
> > >> generator that 
> > >> generated C or C++ code?  THe code generator
> > could do
> > >> the rewrite for 
> > >> you.  Bt it wouldn't be very readable code.
> > >> 
> > 
> >


From dabenavidesd at yahoo.es  Wed May 30 14:53:41 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 13:53:41 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <20120530122057.GA28287@topoi.pooq.com>
Message-ID: <1338382421.96630.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
It theirs original EPL, but wasn't further developed because for S60 as a JVM able phone, contrary to CM J-V-M) isn't able to be used as a library, So I thought this was great news for us. 
I have the package for S60.
Thanks in advance


--- El mi?, 30/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] portable hosting
> Para: m3devel at elegosoft.com
> Fecha: mi?rcoles, 30 de mayo, 2012 07:20
> I've only heard of two different Java
> virtual machines -- the one Sun 
> wrote, which I believe has been independently
> implementedonce or twice, 
> and the one Google wrote as part of Android, which is
> designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro
> Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than
> that in a featured 
> > phone, which is the most common kind of thing in this
> world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com,
> "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates,
> when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro
> Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler
> in a Java
> > > language processor, and cross-boot assemble from a
> Modula-3
> > > environment there so you could bootstrap a
> M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or
> C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than
> writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?  THe code
> generator
> > > could do
> > > >> the rewrite for 
> > > >> you.  Bt it wouldn't be very
> readable code.
> > > >> 
> > > 
> > >
> 


From dabenavidesd at yahoo.es  Wed May 30 15:10:42 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 14:10:42 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <1338382421.96630.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <1338383442.54852.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
in fact there is one else more, A 16-bit IBM java tool set:
http://books.google.com.co/books?id=vj4EAAAAMBAJ&lpg=PA12&dq=java%20s40&pg=PA12#v=onepage&q&f=false

Thanks in advance

--- El mi?, 30/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] portable hosting
> Para: "Hendrik Boom" <hendrik at topoi.pooq.com>
> CC: m3devel at elegosoft.com
> Fecha: mi?rcoles, 30 de mayo, 2012 07:53
> Hi all:
> It theirs original EPL, but wasn't further developed because
> for S60 as a JVM able phone, contrary to CM J-V-M) isn't
> able to be used as a library, So I thought this was great
> news for us. 
> I have the package for S60.
> Thanks in advance
> 
> 
> --- El mi?, 30/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> escribi?:
> 
> > De: Hendrik Boom <hendrik at topoi.pooq.com>
> > Asunto: Re: [M3devel] portable hosting
> > Para: m3devel at elegosoft.com
> > Fecha: mi?rcoles, 30 de mayo, 2012 07:20
> > I've only heard of two different Java
> > virtual machines -- the one Sun 
> > wrote, which I believe has been independently
> > implementedonce or twice, 
> > and the one Google wrote as part of Android, which is
> > designed for 
> > efficient JIT compilation.
> > 
> > Is this one of these, or is there yet another?
> > 
> > -- hendrik
> > 
> > On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel
> Alejandro
> > Benavides D. wrote:
> > > Hi all:
> > > I like the option but because there isn't more
> than
> > that in a featured 
> > > phone, which is the most common kind of thing in
> this
> > world; S40, has 
> > > its own JVM, if this about popularity.
> > > Crazy and simple as it is.
> > > 
> > > Thanks in advance
> > > 
> > > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org>
> > escribi?:
> > > 
> > > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > > Asunto: Re: [M3devel] portable hosting
> > > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > > CC: m3devel at elegosoft.com,
> > "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > > Daniel,
> > > > 
> > > > I like your project. Please inform us on
> updates,
> > when
> > > > available!
> > > > 
> > > > Thanks in advance,
> > > > dd
> > > > 
> > > > p.s. :)
> > > > 
> > > > On May 28, 2012, at 11:22 PM, Daniel
> Alejandro
> > Benavides D.
> > > > wrote:
> > > > 
> > > > > Hi all:
> > > > > or better make an assembly-coded C
> compiler
> > in a Java
> > > > language processor, and cross-boot assemble
> from a
> > Modula-3
> > > > environment there so you could bootstrap a
> > M3CG-system
> > > > there.
> > > > > Thanks in advance
> > > > > 
> > > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > > escribi?:
> > > > > 
> > > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > > >> Asunto: [M3devel] portable hosting
> > > > >> Para: m3devel at elegosoft.com
> > > > >> Fecha: lunes, 28 de mayo, 2012
> 11:50
> > > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > > >> -0700, Jay wrote:
> > > > >>> 
> > > > >>> Btw, rewriting all of m3front in
> C or
> > C++ or
> > > > Java
> > > > >> probably wouldn't be very
> difficult.
> > > > >> 
> > > > >> Would it be more or less difficult
> than
> > writing a
> > > > code
> > > > >> generator that 
> > > > >> generated C or C++ code?  THe
> code
> > generator
> > > > could do
> > > > >> the rewrite for 
> > > > >> you.  Bt it wouldn't be very
> > readable code.
> > > > >> 
> > > > 
> > > >
> >
> 


From microcode at zoho.com  Wed May 30 15:26:04 2012
From: microcode at zoho.com (microcode at zoho.com)
Date: Wed, 30 May 2012 13:26:04 +0000
Subject: [M3devel] portable hosting
In-Reply-To: <20120530122057.GA28287@topoi.pooq.com>
References: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
	<1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120530122057.GA28287@topoi.pooq.com>
Message-ID: <1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>

There are tons of Java JVMs. IBM wrote at least two. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 08:20:57 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

I've only heard of two different Java virtual machines -- the one Sun 
wrote, which I believe has been independently implementedonce or twice, 
and the one Google wrote as part of Android, which is designed for 
efficient JIT compilation.

Is this one of these, or is there yet another?

-- hendrik

On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all:
> I like the option but because there isn't more than that in a featured 
> phone, which is the most common kind of thing in this world; S40, has 
> its own JVM, if this about popularity.
> Crazy and simple as it is.
> 
> Thanks in advance
> 
> --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> > De: Dragi?a Duri? <dragisha at m3w.org>
> > Asunto: Re: [M3devel] portable hosting
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > Daniel,
> > 
> > I like your project. Please inform us on updates, when
> > available!
> > 
> > Thanks in advance,
> > dd
> > 
> > p.s. :)
> > 
> > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > wrote:
> > 
> > > Hi all:
> > > or better make an assembly-coded C compiler in a Java
> > language processor, and cross-boot assemble from a Modula-3
> > environment there so you could bootstrap a M3CG-system
> > there.
> > > Thanks in advance
> > > 
> > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > escribi?:
> > > 
> > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > >> Asunto: [M3devel] portable hosting
> > >> Para: m3devel at elegosoft.com
> > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > >> On Sun, May 20, 2012 at 02:32:14PM
> > >> -0700, Jay wrote:
> > >>> 
> > >>> Btw, rewriting all of m3front in C or C++ or
> > Java
> > >> probably wouldn't be very difficult.
> > >> 
> > >> Would it be more or less difficult than writing a
> > code
> > >> generator that 
> > >> generated C or C++ code?  THe code generator
> > could do
> > >> the rewrite for 
> > >> you.  Bt it wouldn't be very readable code.
> > >> 
> > 
> >

From hendrik at topoi.pooq.com  Wed May 30 15:51:14 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 30 May 2012 09:51:14 -0400
Subject: [M3devel] portable hosting
In-Reply-To: <1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>
References: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
	<1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120530122057.GA28287@topoi.pooq.com>
	<1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>
Message-ID: <20120530135114.GB28287@topoi.pooq.com>

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?  Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?  THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.  Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >


From dabenavidesd at yahoo.es  Wed May 30 16:08:32 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 15:08:32 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>
Message-ID: <1338386912.57598.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
But original for reference for a platform, I think as Modula-3 was VAX mostly, and Olivetti Modula-3 was ARM mostly.
Thanks in advance

--- El mi?, 30/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

> De: microcode at zoho.com <microcode at zoho.com>
> Asunto: Re: [M3devel] portable hosting
> Para: m3devel at elegosoft.com
> Fecha: mi?rcoles, 30 de mayo, 2012 08:26
> There are tons of Java JVMs. IBM
> wrote at least two. 
> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines --
> the one Sun 
> wrote, which I believe has been independently
> implementedonce or twice, 
> and the one Google wrote as part of Android, which is
> designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro
> Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than
> that in a featured 
> > phone, which is the most common kind of thing in this
> world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com,
> "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates,
> when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro
> Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler
> in a Java
> > > language processor, and cross-boot assemble from a
> Modula-3
> > > environment there so you could bootstrap a
> M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or
> C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than
> writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?  THe code
> generator
> > > could do
> > > >> the rewrite for 
> > > >> you.  Bt it wouldn't be very
> readable code.
> > > >> 
> > > 
> > >
> 


From microcode at zoho.com  Wed May 30 16:11:39 2012
From: microcode at zoho.com (microcode at zoho.com)
Date: Wed, 30 May 2012 14:11:39 +0000
Subject: [M3devel] portable hosting
In-Reply-To: <20120530135114.GB28287@topoi.pooq.com>
References: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
	<1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120530122057.GA28287@topoi.pooq.com>
	<1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>
	<20120530135114.GB28287@topoi.pooq.com>
Message-ID: <754448862-1338387100-cardhu_decombobulator_blackberry.rim.net-349729625-@b1.c1.bise3.blackberry>

I'm sorry, I don't understand what you are asking. 

As much as I loathe WikiPedia

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

Is a good starting point. I am pretty sure there are dozens more not listed there though. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 09:51:14 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?  Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?  THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.  Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >

From dabenavidesd at yahoo.es  Wed May 30 17:13:13 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 16:13:13 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <754448862-1338387100-cardhu_decombobulator_blackberry.rim.net-349729625-@b1.c1.bise3.blackberry>
Message-ID: <1338390793.36979.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
I think the issue is back to the stream media, since a JVM ready product was only to be Sun JVM ready, so, any other implementation was both a product officially unrelated and JVM ready. I don't know how SUN thought about JIT-compilers, etc.
Thanks in advance


--- El mi?, 30/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

De: microcode at zoho.com <microcode at zoho.com>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com
Fecha: mi?rcoles, 30 de mayo, 2012 09:11

I'm sorry, I don't understand what you are asking. 

As much as I loathe WikiPedia

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


Is a good starting point. I am pretty sure there are dozens more not listed there though. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 09:51:14 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?? Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?? THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.? Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120530/d325b80d/attachment-0001.html>

From dabenavidesd at yahoo.es  Wed May 30 18:30:47 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 17:30:47 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <1338390793.36979.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <1338395447.59773.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
this is to say, JVM non-SUN are not JVM products compatible, CM J-V-M but I don't know how it was related to it.
Something akin PC AT, the latter are not clones, so you know. Now, if Compaq did the same thing with their Compaq Fast VM, as it did with Compaq deskpro, that would be managing the JVM to produce another IR, that was the idea if the memory issues were corrected, as JVm leaked for years, I think Dragisha sent that article about it, didn't he?
Thanks in advance

--- El mi?, 30/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com, microcode at zoho.com
Fecha: mi?rcoles, 30 de mayo, 2012 10:13

Hi all:
I think the issue is back to the stream media, since a JVM ready product was only to be Sun JVM ready, so, any other implementation was both a product officially unrelated and JVM ready. I don't know how SUN thought about JIT-compilers, etc.
Thanks in advance


--- El mi?, 30/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

De: microcode at zoho.com <microcode at zoho.com>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com
Fecha: mi?rcoles, 30 de mayo, 2012 09:11

I'm sorry, I don't understand what you are asking. 

As much as I loathe WikiPedia

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


Is a good starting point. I am pretty sure there are dozens more not listed there though. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 09:51:14 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?? Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of
 thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >>
 Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?? THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.? Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120530/30a30073/attachment-0001.html>

From dabenavidesd at yahoo.es  Wed May 30 21:33:13 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 20:33:13 +0100 (BST)
Subject: [M3devel] X86/97 targets? [was: Re:  portable hosting]
In-Reply-To: <1338395447.59773.YahooMailClassic@web29705.mail.ird.yahoo.com>
Message-ID: <1338406393.56947.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
Someone has checked what is a x97?
Was x97 another take by i86 something akin, they created a 300 million fund for anyone experimenting on it? (Old strategy for companies Elego folks something to say ...) Do we want this:
http://confidential.eetimes.com/news-updates/4373963/Ultrabooks-duel-ultralights-at-Computex

P.S: If you need this article to see complete text please create a free account, else I can send it upon request. 

Thanks in advance

--- El mi?, 30/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com, microcode at zoho.com
Fecha: mi?rcoles, 30 de mayo, 2012 11:30

Hi all:
this is to say, JVM non-SUN are not JVM products compatible, CM J-V-M but I don't know how it was related to it.
Something akin PC AT, the latter are not clones, so you know. Now, if Compaq did the same thing with their Compaq Fast VM, as it did with Compaq deskpro, that would be managing the JVM to produce another IR, that was the idea if the memory issues were corrected, as JVm leaked for years, I think Dragisha sent that article about it, didn't he?
Thanks in advance

--- El mi?, 30/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com,
 microcode at zoho.com
Fecha: mi?rcoles, 30 de mayo, 2012 10:13

Hi all:
I think the issue is back to the stream media, since a JVM ready product was only to be Sun JVM ready, so, any other implementation was both a product officially unrelated and JVM ready. I don't know how SUN thought about JIT-compilers, etc.
Thanks in advance


--- El mi?, 30/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

De: microcode at zoho.com <microcode at zoho.com>
Asunto: Re: [M3devel] portable hosting
Para:
 m3devel at elegosoft.com
Fecha: mi?rcoles, 30 de mayo, 2012 09:11

I'm sorry, I don't understand what you are asking. 

As much as I loathe WikiPedia

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


Is a good starting point. I am pretty sure there are dozens more not listed there though. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 09:51:14 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?? Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of
 two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of
 thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> >
 > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > >
 >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >>
 Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?? THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.? Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120530/023e42ea/attachment-0001.html>

From dabenavidesd at yahoo.es  Thu May 31 15:13:39 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 31 May 2012 14:13:39 +0100 (BST)
Subject: [M3devel] Renewed interest in Modula-3 in HP Labs
Message-ID: <1338470019.63945.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
I see there is some products coming from HP, and others, but specially HP, claiming that provide lower consumption in data center power management.
As I see they are working in Tycoon as a Data processor (created in Germany and Europe).
As Greg Nelson wrote code for profiling the Alphas and Itanium, perhaps they are interested in work on ESC, but nevertheless Modula-3 and family languages (Quest) as Tycoon is based on them.
If I may say so, Quest was defined by its simple denotational semantics, which is the natural deduction system of Baby Modula-3 (though it lacks more than that, but you can process the language of it through the former)
Do we want to confirm that, if anyone interested in the TML - TVM please write me for any other questions or comments
Thanks in advance

http://www.eetimes.com/electronics-news/4373994/HP-cuts-data-center-power-in-lab-tests?cid=NL_EETimesDaily

http://tycoon.hpl.hp.com/~tycoon/doc/users_manual_en/ch-intro.html

http://wwwmatthes.in.tum.de/file/Publications/1992/Math92/paper.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120531/3d6c107d/attachment-0001.html>

From dabenavidesd at yahoo.es  Wed May  2 18:07:02 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 2 May 2012 17:07:02 +0100 (BST)
Subject: [M3devel] About something we shouldn't care?
Message-ID: <1335974822.36880.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
http://app.reg.techweb.com/e/es.aspx?s=2150&e=50711&elq=cef656ee4d6c4bca996b337620b98f85

Oracle is/seems to be claiming no one except them can implement their API without a license, being Android a not JVM-compatible product, then what is this for Modula-3, threads, are still of them?
IMHO I don't think this is something we should care as Modula- has received any recovery of investment of this APIs, then we could make tons of money, or me not but at least DEC, etc.
Thanks in advance


From dataf4l at gmail.com  Wed May  2 18:57:20 2012
From: dataf4l at gmail.com (felipe valdez)
Date: Wed, 2 May 2012 11:57:20 -0500
Subject: [M3devel] About something we shouldn't care?
In-Reply-To: <1335974822.36880.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <1335974822.36880.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <CAGi-_-9fCmreApLkUGZJ5-CXNGYVWuELXVrL0p=Agnx70Q37WQ@mail.gmail.com>

if oracle wins, then IBM can sue them for their SQL.



On Wed, May 2, 2012 at 11:07 AM, Daniel Alejandro Benavides D. <
dabenavidesd at yahoo.es> wrote:

> Hi all:
>
> http://app.reg.techweb.com/e/es.aspx?s=2150&e=50711&elq=cef656ee4d6c4bca996b337620b98f85
>
> Oracle is/seems to be claiming no one except them can implement their API
> without a license, being Android a not JVM-compatible product, then what is
> this for Modula-3, threads, are still of them?
> IMHO I don't think this is something we should care as Modula- has
> received any recovery of investment of this APIs, then we could make tons
> of money, or me not but at least DEC, etc.
> Thanks in advance
>



-- 
312-444-2124
Skype: f3l.headhunter
Casa: 8043901
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120502/d6e9d22b/attachment-0002.html>

From dabenavidesd at yahoo.es  Wed May  2 19:27:37 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 2 May 2012 18:27:37 +0100 (BST)
Subject: [M3devel] About something we shouldn't care?
In-Reply-To: <CAGi-_-9fCmreApLkUGZJ5-CXNGYVWuELXVrL0p=Agnx70Q37WQ@mail.gmail.com>
Message-ID: <1335979657.75013.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all.
Talking about IBM, they constructed an incremental computation system in Modula-3, so guess what does it care to be written in Modula-3
Thanks in advance

--- El mi?, 2/5/12, felipe valdez <dataf4l at gmail.com> escribi?:

De: felipe valdez <dataf4l at gmail.com>
Asunto: Re: [M3devel] About something we shouldn't care?
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: m3devel at elegosoft.com
Fecha: mi?rcoles, 2 de mayo, 2012 11:57

if oracle wins, then IBM can sue them for their SQL.



On Wed, May 2, 2012 at 11:07 AM, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:


Hi all:

http://app.reg.techweb.com/e/es.aspx?s=2150&e=50711&elq=cef656ee4d6c4bca996b337620b98f85





Oracle is/seems to be claiming no one except them can implement their API without a license, being Android a not JVM-compatible product, then what is this for Modula-3, threads, are still of them?

IMHO I don't think this is something we should care as Modula- has received any recovery of investment of this APIs, then we could make tons of money, or me not but at least DEC, etc.

Thanks in advance




-- 
312-444-2124Skype: f3l.headhunterCasa: 8043901


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120502/726b8e28/attachment-0002.html>

From dabenavidesd at yahoo.es  Wed May  2 21:24:49 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 2 May 2012 20:24:49 +0100 (BST)
Subject: [M3devel] About something we shouldn't care?
In-Reply-To: <CAGi-_-9fCmreApLkUGZJ5-CXNGYVWuELXVrL0p=Agnx70Q37WQ@mail.gmail.com>
Message-ID: <1335986689.43364.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
Besides RMI, we have exceptions, interfaces, garbage collection of references of modular type system (because this was demonstrated in Java-class like languages), which everything is an object except the object itself that is not classic language BTW, classic is Modula-3, so I don't know why they claim, C-like structures are classic:

ftp://cs.stanford.edu/cs/theory/katiyar/papers/PhDThesis.ps

And the most basic thing in Java languages are objects so, I don't know how they claim that they invented that.

Instead Modula-3 Objects are pure Object type systems, functional like Baby Modula-3, or Modular, like Modula-3 itself. But aside of that Java is not-centric object-oriented, just Modular, but Modula-3 is purely Modular, and if you want Module oriented development you are thinking in wise understood language, not in an unproven "Object-oriented" language.

Thanks in advance

--- El mi?, 2/5/12, felipe valdez <dataf4l at gmail.com> escribi?:

De: felipe valdez <dataf4l at gmail.com>
Asunto: Re: [M3devel] About something we shouldn't care?
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: m3devel at elegosoft.com
Fecha: mi?rcoles, 2 de mayo, 2012 11:57

if oracle wins, then IBM can sue them for their SQL.



On Wed, May 2, 2012 at 11:07 AM, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:


Hi all:

http://app.reg.techweb.com/e/es.aspx?s=2150&e=50711&elq=cef656ee4d6c4bca996b337620b98f85





Oracle is/seems to be claiming no one except them can implement their API without a license, being Android a not JVM-compatible product, then what is this for Modula-3, threads, are still of them?

IMHO I don't think this is something we should care as Modula- has received any recovery of investment of this APIs, then we could make tons of money, or me not but at least DEC, etc.

Thanks in advance




-- 
312-444-2124Skype: f3l.headhunterCasa: 8043901


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120502/c15d61ba/attachment-0002.html>

From dragisha at m3w.org  Fri May  4 22:37:19 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 4 May 2012 22:37:19 +0200
Subject: [M3devel] GC algorithm
Message-ID: <488CE4EB-8FAA-4D43-8481-D5DD3B3BE3FB@m3w.org>

I am not very fluent with RTCollector source, but it looks to me there is at least one possible race condition situation possible.

RTHooks.CheckStoreTraced() explicitly marks object & its page dirty/not-clean. Everything with heap locked. But - next thing is - heaps is unlocked and this method returns. What if collector from other thread "hijacks" heap right at end of CheckStoreTraced()/well before mutator changes some reference field in object? 

Similar situaction is with "read barrier" in CheckLoadTraceRef(). Or at least it looks like one to me :).

dd



From dragisha at m3w.org  Fri May  4 22:55:03 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 4 May 2012 22:55:03 +0200
Subject: [M3devel] GC algorithm
In-Reply-To: <488CE4EB-8FAA-4D43-8481-D5DD3B3BE3FB@m3w.org>
References: <488CE4EB-8FAA-4D43-8481-D5DD3B3BE3FB@m3w.org>
Message-ID: <2397638D-5AA9-4C9F-B286-452AED50F769@m3w.org>

.. Getting at this. Probably not a problem because reference is, in case when this is emitted by compiler, on stack/registers. As ambiguous root - object/page will not be altered. So, probably not race, when called as a hook from compiler emitted code?

On May 4, 2012, at 10:37 PM, Dragi?a Duri? wrote:

> I am not very fluent with RTCollector source, but it looks to me there is at least one possible race condition situation possible.
> 
> RTHooks.CheckStoreTraced() explicitly marks object & its page dirty/not-clean. Everything with heap locked. But - next thing is - heaps is unlocked and this method returns. What if collector from other thread "hijacks" heap right at end of CheckStoreTraced()/well before mutator changes some reference field in object? 
> 
> Similar situaction is with "read barrier" in CheckLoadTraceRef(). Or at least it looks like one to me :).
> 
> dd
> 



From dabenavidesd at yahoo.es  Fri May  4 23:30:32 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 4 May 2012 22:30:32 +0100 (BST)
Subject: [M3devel] A possible grammar overstrictness or ambiguity problem
Message-ID: <1336167032.54236.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
Please take a look at p. 18:
http://math.guc.edu.eg/Wafik/Characterizing%20Unambiguity.pdf

I have recreated in a small program not particulary useful to you but to the example:
///////////////////////// Main.m3 /////////////////////////////////
MODULE Main;
VAR a, b :=FALSE;

BEGIN

IF b = (NOT a)
 THEN a:=b;
END 

END Main.

It works as theory expresses but in my small program's alphabet it's overstrict, isn't it? Line 6 is a bad expression without parenthesis.

 Thanks in advance


From rodney_bates at lcwb.coop  Sun May  6 01:27:31 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 05 May 2012 18:27:31 -0500
Subject: [M3devel] A possible grammar overstrictness or ambiguity problem
In-Reply-To: <1336167032.54236.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1336167032.54236.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <4FA5B763.5030205@lcwb.coop>

Hmm, interesting.  If the expression were  NOT a = b, (and no precedence rules),
there would be two ways to parenthesize: (NOT a) = b and NOT (a = b), an
ambiguity.  Making NOT have lower precedence than = resolves this in favor
of the latter.  Equivalently, the grammar is written so that = demands each
of its operands be E4 or higher, which NOT E3 is not, it's an E2.  This fixes
this and other potential ambiguities.

But in the example, since NOT is only a prefix operator, there is only way
to parenthesize, i.e. nothing like (b =) NOT a.  So the precedence would not be
necessary in this case.  But the grammar is written to apply the precedence
rule consistently, leaving the unparenthesized version b = NOT a
underivable.  Overly strict, but maybe not worth the trouble to weaken.

An interesting exercise that I do not have the energy to do would be to
rewrite the M3 expression grammar to allow b = NOT a, without introducing
ambiguity elsewhere.  And make it work on the other prefix operators + and -.
Would be good for a textbook.

I don't think postfix operators (Selector in the grammar) can get into
a counterpart problem because they have the highest precedence.

On 05/04/2012 04:30 PM, Daniel Alejandro Benavides D. wrote:
> Hi all:
> Please take a look at p. 18:
> http://math.guc.edu.eg/Wafik/Characterizing%20Unambiguity.pdf
>
> I have recreated in a small program not particulary useful to you but to the example:
> ///////////////////////// Main.m3 /////////////////////////////////
> MODULE Main;
> VAR a, b :=FALSE;
>
> BEGIN
>
> IF b = (NOT a)
>   THEN a:=b;
> END
>
> END Main.
>
> It works as theory expresses but in my small program's alphabet it's overstrict, isn't it? Line 6 is a bad expression without parenthesis.
>
>   Thanks in advance
>


From dabenavidesd at yahoo.es  Tue May  8 22:43:13 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 21:43:13 +0100 (BST)
Subject: [M3devel] A possible grammar overstrictness or ambiguity problem
In-Reply-To: <4FA5B763.5030205@lcwb.coop>
Message-ID: <1336509793.29460.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
Thanks for the hints I have just re-read your message, I think you can purpose a multi-value suitable solution:
IF NOT a=b, 
which is in semantic analysis 
same as 
IF b = NOT a
then I think would make the case for the "fix" or vice versa, but I think language definition has no assumptions over this (or at least I can't see them).

I was thinking that we could sort of avoid this by defining a core grammar, in top of which we can put the rest, but this is the harder solution as you say. But I'm thinking along this lines, since I'm a true proposer of Baby Modula-3 be in some form (along the lines) in the Modula-3 language definition.

I wish we could talk more than in typing texts by email, but the other diea I had about this is to introduce animations (Obliq, Trestle, whatever fills our purposes, or better, Juno ones) of the Modula-3 SPWM3 book, since most of the interfaces are in the code base, I think by making a Baby Modula-3 implementation we could insert it in the Chapter 1, in same way (succinctly because Baby is small by language definition) and by allow information on it to be explained incrementally by the language itself in a cool manner.

OK, I will let you know the details, as soon I get into it, but hope you can give more hints or some opinion on anyones behalf.

Thanks in advance

--- El s?b, 5/5/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] A possible grammar overstrictness or ambiguity problem
> Para: m3devel at elegosoft.com
> Fecha: s?bado, 5 de mayo, 2012 18:27
> Hmm, interesting.  If the
> expression were  NOT a = b, (and no precedence rules),
> there would be two ways to parenthesize: (NOT a) = b and NOT
> (a = b), an
> ambiguity.  Making NOT have lower precedence than =
> resolves this in favor
> of the latter.  Equivalently, the grammar is written so
> that = demands each
> of its operands be E4 or higher, which NOT E3 is not, it's
> an E2.  This fixes
> this and other potential ambiguities.
> 
> But in the example, since NOT is only a prefix operator,
> there is only way
> to parenthesize, i.e. nothing like (b =) NOT a.  So the
> precedence would not be
> necessary in this case.  But the grammar is written to
> apply the precedence
> rule consistently, leaving the unparenthesized version b =
> NOT a
> underivable.  Overly strict, but maybe not worth the
> trouble to weaken.
> 
> An interesting exercise that I do not have the energy to do
> would be to
> rewrite the M3 expression grammar to allow b = NOT a,
> without introducing
> ambiguity elsewhere.  And make it work on the other
> prefix operators + and -.
> Would be good for a textbook.
> 
> I don't think postfix operators (Selector in the grammar)
> can get into
> a counterpart problem because they have the highest
> precedence.
> 
> On 05/04/2012 04:30 PM, Daniel Alejandro Benavides D.
> wrote:
> > Hi all:
> > Please take a look at p. 18:
> > http://math.guc.edu.eg/Wafik/Characterizing%20Unambiguity.pdf
> >
> > I have recreated in a small program not particulary
> useful to you but to the example:
> > ///////////////////////// Main.m3
> /////////////////////////////////
> > MODULE Main;
> > VAR a, b :=FALSE;
> >
> > BEGIN
> >
> > IF b = (NOT a)
> >   THEN a:=b;
> > END
> >
> > END Main.
> >
> > It works as theory expresses but in my small program's
> alphabet it's overstrict, isn't it? Line 6 is a bad
> expression without parenthesis.
> >
> >   Thanks in advance
> >
> 


From dabenavidesd at yahoo.es  Tue May  8 22:58:05 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 21:58:05 +0100 (BST)
Subject: [M3devel] GC algorithm
In-Reply-To: <2397638D-5AA9-4C9F-B286-452AED50F769@m3w.org>
Message-ID: <1336510685.96265.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
Dragisha I can't be quite sure what are you talking about but assuming arbitrary implementations must be the best way to talk respect of the language itself. (This is to me ask the same question but in a garbage Collector-less way)
Thanks in advance

--- El vie, 4/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 4 de mayo, 2012 15:55
> .. Getting at this. Probably not a
> problem because reference is, in case when this is emitted
> by compiler, on stack/registers. As ambiguous root -
> object/page will not be altered. So, probably not race, when
> called as a hook from compiler emitted code?
> 
> On May 4, 2012, at 10:37 PM, Dragi?a Duri? wrote:
> 
> > I am not very fluent with RTCollector source, but it
> looks to me there is at least one possible race condition
> situation possible.
> > 
> > RTHooks.CheckStoreTraced() explicitly marks object
> & its page dirty/not-clean. Everything with heap locked.
> But - next thing is - heaps is unlocked and this method
> returns. What if collector from other thread "hijacks" heap
> right at end of CheckStoreTraced()/well before mutator
> changes some reference field in object? 
> > 
> > Similar situaction is with "read barrier" in
> CheckLoadTraceRef(). Or at least it looks like one to me
> :).
> > 
> > dd
> > 
> 
> 


From dragisha at m3w.org  Tue May  8 23:21:45 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 8 May 2012 23:21:45 +0200
Subject: [M3devel] GC algorithm
In-Reply-To: <F1D953B3-6D64-4A07-B983-7DDC91C6C363@gmail.com>
References: <488CE4EB-8FAA-4D43-8481-D5DD3B3BE3FB@m3w.org>
	<F1D953B3-6D64-4A07-B983-7DDC91C6C363@gmail.com>
Message-ID: <E63127A8-6383-4A46-AF8A-3B6F2CCCF561@m3w.org>

Got that. You pointed write barrier to me few yrs ago, and that's it.

I am reading through RTCollector.m3 in pieces of time I have to spare. Lots of legacy code there. Any good reaosn to keep several different functionalities in single source module? Like RTWeakRef, lots of differentable mutator/collector code and so on?

On May 8, 2012, at 11:12 PM, Antony Hosking wrote:

> Just following up quickly while extremely rushed.
> Indeed, the fact that the mutator has the references on its stack will cause their targets to be pinned (not copied) if a collection intervenes between the marking and before the store.  So, they will be retained.
> 
> On May 4, 2012, at 4:37 PM, Dragi?a Duri? wrote:
> 
>> I am not very fluent with RTCollector source, but it looks to me there is at least one possible race condition situation possible.
>> 
>> RTHooks.CheckStoreTraced() explicitly marks object & its page dirty/not-clean. Everything with heap locked. But - next thing is - heaps is unlocked and this method returns. What if collector from other thread "hijacks" heap right at end of CheckStoreTraced()/well before mutator changes some reference field in object? 
>> 
>> Similar situaction is with "read barrier" in CheckLoadTraceRef(). Or at least it looks like one to me :).
>> 
>> dd
>> 
> 



From dabenavidesd at yahoo.es  Wed May  9 00:02:56 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 23:02:56 +0100 (BST)
Subject: [M3devel] GC algorithm
In-Reply-To: <E63127A8-6383-4A46-AF8A-3B6F2CCCF561@m3w.org>
Message-ID: <1336514576.13662.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
for my God sake, I think is better to be useful than useless, and if that's different from general than specific, that's better, but be careful, we could loose some Boehm GC correspondence in Gcc GC, which would in turn be useful for timing and short cutting the native Modula-3 Collector, specially RTCollector SRC and perhaps the SUN test suite module (more on this later). Tony and his team did that:

http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html

Thanks in advance

--- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "Antony Hosking" <antony.hosking at gmail.com>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 8 de mayo, 2012 16:21
> Got that. You pointed write barrier
> to me few yrs ago, and that's it.
> 
> I am reading through RTCollector.m3 in pieces of time I have
> to spare. Lots of legacy code there. Any good reaosn to keep
> several different functionalities in single source module?
> Like RTWeakRef, lots of differentable mutator/collector code
> and so on?
> 
> On May 8, 2012, at 11:12 PM, Antony Hosking wrote:
> 
> > Just following up quickly while extremely rushed.
> > Indeed, the fact that the mutator has the references on
> its stack will cause their targets to be pinned (not copied)
> if a collection intervenes between the marking and before
> the store.  So, they will be retained.
> > 
> > On May 4, 2012, at 4:37 PM, Dragi?a Duri? wrote:
> > 
> >> I am not very fluent with RTCollector source, but
> it looks to me there is at least one possible race condition
> situation possible.
> >> 
> >> RTHooks.CheckStoreTraced() explicitly marks object
> & its page dirty/not-clean. Everything with heap locked.
> But - next thing is - heaps is unlocked and this method
> returns. What if collector from other thread "hijacks" heap
> right at end of CheckStoreTraced()/well before mutator
> changes some reference field in object? 
> >> 
> >> Similar situaction is with "read barrier" in
> CheckLoadTraceRef(). Or at least it looks like one to me
> :).
> >> 
> >> dd
> >> 
> > 
> 
> 


From dabenavidesd at yahoo.es  Wed May  9 00:20:16 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 23:20:16 +0100 (BST)
Subject: [M3devel] "The New Native Languages" time for us to code a Modula-3
	JIT compiler?
Message-ID: <1336515616.28079.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:

http://app.reg.techweb.com/e/es.aspx?s=2150&e=52494&elq=b491fb8f21d64a28ab346c4bc41650e6

I know of a "unclassified" tool for doing that but end support is a need symbolically speaking.

A guy was working on a LLVM backend, but I don't know, does anyone plans some sort of M3CG related project?

Thanks in advance


From dragisha at m3w.org  Wed May  9 00:20:30 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 9 May 2012 00:20:30 +0200
Subject: [M3devel] GC algorithm
In-Reply-To: <1336514576.13662.YahooMailClassic@web29703.mail.ird.yahoo.com>
References: <1336514576.13662.YahooMailClassic@web29703.mail.ird.yahoo.com>
Message-ID: <F3E03E0F-AD87-4573-8280-A802AAA34C7B@m3w.org>

G1 collector sounds interesting, and funny. Pause prediction - good luck with that.

Fast sweep through blurb on that page and I think this collector of theirs is a bit behind what we have in Modula-3. No wonder - Modula-3 had what they are describing and few things more years before Java existed.

Interesting tidbit, maybe. If they can collect with multiple threads at same time, that _is_ something new. But they danced around that on that page.

Also, G1 is not what Antony and his team did. They made real-time collector, and G1 is not. I think link was posted here some time ago.

On May 9, 2012, at 12:02 AM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> for my God sake, I think is better to be useful than useless, and if that's different from general than specific, that's better, but be careful, we could loose some Boehm GC correspondence in Gcc GC, which would in turn be useful for timing and short cutting the native Modula-3 Collector, specially RTCollector SRC and perhaps the SUN test suite module (more on this later). Tony and his team did that:
> 
> http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
> 
> Thanks in advance
> 
> --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
>> De: Dragi?a Duri? <dragisha at m3w.org>
>> Asunto: Re: [M3devel] GC algorithm
>> Para: "Antony Hosking" <antony.hosking at gmail.com>
>> CC: "m3devel" <m3devel at elegosoft.com>
>> Fecha: martes, 8 de mayo, 2012 16:21
>> Got that. You pointed write barrier
>> to me few yrs ago, and that's it.
>> 
>> I am reading through RTCollector.m3 in pieces of time I have
>> to spare. Lots of legacy code there. Any good reaosn to keep
>> several different functionalities in single source module?
>> Like RTWeakRef, lots of differentable mutator/collector code
>> and so on?
>> 
>> On May 8, 2012, at 11:12 PM, Antony Hosking wrote:
>> 
>>> Just following up quickly while extremely rushed.
>>> Indeed, the fact that the mutator has the references on
>> its stack will cause their targets to be pinned (not copied)
>> if a collection intervenes between the marking and before
>> the store.  So, they will be retained.
>>> 
>>> On May 4, 2012, at 4:37 PM, Dragi?a Duri? wrote:
>>> 
>>>> I am not very fluent with RTCollector source, but
>> it looks to me there is at least one possible race condition
>> situation possible.
>>>> 
>>>> RTHooks.CheckStoreTraced() explicitly marks object
>> & its page dirty/not-clean. Everything with heap locked.
>> But - next thing is - heaps is unlocked and this method
>> returns. What if collector from other thread "hijacks" heap
>> right at end of CheckStoreTraced()/well before mutator
>> changes some reference field in object? 
>>>> 
>>>> Similar situaction is with "read barrier" in
>> CheckLoadTraceRef(). Or at least it looks like one to me
>> :).
>>>> 
>>>> dd
>>>> 
>>> 
>> 
>> 



From dabenavidesd at yahoo.es  Wed May  9 00:36:27 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 23:36:27 +0100 (BST)
Subject: [M3devel] GC algorithm
In-Reply-To: <F3E03E0F-AD87-4573-8280-A802AAA34C7B@m3w.org>
Message-ID: <1336516587.51821.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
OK, understood, I think this kind of philosophy is smoother:
http://static.usenix.org/events/coots99/full_papers/liang/liang.pdf

Similarly the CM JVM  can be applied to this test too.

Look at this old news (it seems they didn't believe it that much, probably that's why they never released it):
http://www.informationweek.com/newsflash/nf655/1105_st9.htm

Thanks in advance

--- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "Antony Hosking" <antony.hosking at gmail.com>, "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 8 de mayo, 2012 17:20
> G1 collector sounds interesting, and
> funny. Pause prediction - good luck with that.
> 
> Fast sweep through blurb on that page and I think this
> collector of theirs is a bit behind what we have in
> Modula-3. No wonder - Modula-3 had what they are describing
> and few things more years before Java existed.
> 
> Interesting tidbit, maybe. If they can collect with multiple
> threads at same time, that _is_ something new. But they
> danced around that on that page.
> 
> Also, G1 is not what Antony and his team did. They made
> real-time collector, and G1 is not. I think link was posted
> here some time ago.
> 
> On May 9, 2012, at 12:02 AM, Daniel Alejandro Benavides D.
> wrote:
> 
> > Hi all:
> > for my God sake, I think is better to be useful than
> useless, and if that's different from general than specific,
> that's better, but be careful, we could loose some Boehm GC
> correspondence in Gcc GC, which would in turn be useful for
> timing and short cutting the native Modula-3 Collector,
> specially RTCollector SRC and perhaps the SUN test suite
> module (more on this later). Tony and his team did that:
> > 
> > http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
> > 
> > Thanks in advance
> > 
> > --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> >> De: Dragi?a Duri? <dragisha at m3w.org>
> >> Asunto: Re: [M3devel] GC algorithm
> >> Para: "Antony Hosking" <antony.hosking at gmail.com>
> >> CC: "m3devel" <m3devel at elegosoft.com>
> >> Fecha: martes, 8 de mayo, 2012 16:21
> >> Got that. You pointed write barrier
> >> to me few yrs ago, and that's it.
> >> 
> >> I am reading through RTCollector.m3 in pieces of
> time I have
> >> to spare. Lots of legacy code there. Any good
> reaosn to keep
> >> several different functionalities in single source
> module?
> >> Like RTWeakRef, lots of differentable
> mutator/collector code
> >> and so on?
> >> 
> >> On May 8, 2012, at 11:12 PM, Antony Hosking wrote:
> >> 
> >>> Just following up quickly while extremely
> rushed.
> >>> Indeed, the fact that the mutator has the
> references on
> >> its stack will cause their targets to be pinned
> (not copied)
> >> if a collection intervenes between the marking and
> before
> >> the store.  So, they will be retained.
> >>> 
> >>> On May 4, 2012, at 4:37 PM, Dragi?a Duri?
> wrote:
> >>> 
> >>>> I am not very fluent with RTCollector
> source, but
> >> it looks to me there is at least one possible race
> condition
> >> situation possible.
> >>>> 
> >>>> RTHooks.CheckStoreTraced() explicitly marks
> object
> >> & its page dirty/not-clean. Everything with
> heap locked.
> >> But - next thing is - heaps is unlocked and this
> method
> >> returns. What if collector from other thread
> "hijacks" heap
> >> right at end of CheckStoreTraced()/well before
> mutator
> >> changes some reference field in object? 
> >>>> 
> >>>> Similar situaction is with "read barrier"
> in
> >> CheckLoadTraceRef(). Or at least it looks like one
> to me
> >> :).
> >>>> 
> >>>> dd
> >>>> 
> >>> 
> >> 
> >> 
> 
> 


From dragisha at m3w.org  Wed May  9 00:40:17 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 9 May 2012 00:40:17 +0200
Subject: [M3devel] GC algorithm
In-Reply-To: <1336516587.51821.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1336516587.51821.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <325641F7-37AF-4BCC-AB5C-78C1172090F0@m3w.org>

Very old news. In JVM world - five years is a lot. 13yrs are another age :).
 
On May 9, 2012, at 12:36 AM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> OK, understood, I think this kind of philosophy is smoother:
> http://static.usenix.org/events/coots99/full_papers/liang/liang.pdf
> 
> Similarly the CM JVM  can be applied to this test too.
> 
> Look at this old news (it seems they didn't believe it that much, probably that's why they never released it):
> http://www.informationweek.com/newsflash/nf655/1105_st9.htm
> 
> Thanks in advance
> 
> --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
>> De: Dragi?a Duri? <dragisha at m3w.org>
>> Asunto: Re: [M3devel] GC algorithm
>> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
>> CC: "Antony Hosking" <antony.hosking at gmail.com>, "m3devel" <m3devel at elegosoft.com>
>> Fecha: martes, 8 de mayo, 2012 17:20
>> G1 collector sounds interesting, and
>> funny. Pause prediction - good luck with that.
>> 
>> Fast sweep through blurb on that page and I think this
>> collector of theirs is a bit behind what we have in
>> Modula-3. No wonder - Modula-3 had what they are describing
>> and few things more years before Java existed.
>> 
>> Interesting tidbit, maybe. If they can collect with multiple
>> threads at same time, that _is_ something new. But they
>> danced around that on that page.
>> 
>> Also, G1 is not what Antony and his team did. They made
>> real-time collector, and G1 is not. I think link was posted
>> here some time ago.
>> 
>> On May 9, 2012, at 12:02 AM, Daniel Alejandro Benavides D.
>> wrote:
>> 
>>> Hi all:
>>> for my God sake, I think is better to be useful than
>> useless, and if that's different from general than specific,
>> that's better, but be careful, we could loose some Boehm GC
>> correspondence in Gcc GC, which would in turn be useful for
>> timing and short cutting the native Modula-3 Collector,
>> specially RTCollector SRC and perhaps the SUN test suite
>> module (more on this later). Tony and his team did that:
>>> 
>>> http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
>>> 
>>> Thanks in advance
>>> 
>>> --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org>
>> escribi?:
>>> 
>>>> De: Dragi?a Duri? <dragisha at m3w.org>
>>>> Asunto: Re: [M3devel] GC algorithm
>>>> Para: "Antony Hosking" <antony.hosking at gmail.com>
>>>> CC: "m3devel" <m3devel at elegosoft.com>
>>>> Fecha: martes, 8 de mayo, 2012 16:21
>>>> Got that. You pointed write barrier
>>>> to me few yrs ago, and that's it.
>>>> 
>>>> I am reading through RTCollector.m3 in pieces of
>> time I have
>>>> to spare. Lots of legacy code there. Any good
>> reaosn to keep
>>>> several different functionalities in single source
>> module?
>>>> Like RTWeakRef, lots of differentable
>> mutator/collector code
>>>> and so on?
>>>> 
>>>> On May 8, 2012, at 11:12 PM, Antony Hosking wrote:
>>>> 
>>>>> Just following up quickly while extremely
>> rushed.
>>>>> Indeed, the fact that the mutator has the
>> references on
>>>> its stack will cause their targets to be pinned
>> (not copied)
>>>> if a collection intervenes between the marking and
>> before
>>>> the store.  So, they will be retained.
>>>>> 
>>>>> On May 4, 2012, at 4:37 PM, Dragi?a Duri?
>> wrote:
>>>>> 
>>>>>> I am not very fluent with RTCollector
>> source, but
>>>> it looks to me there is at least one possible race
>> condition
>>>> situation possible.
>>>>>> 
>>>>>> RTHooks.CheckStoreTraced() explicitly marks
>> object
>>>> & its page dirty/not-clean. Everything with
>> heap locked.
>>>> But - next thing is - heaps is unlocked and this
>> method
>>>> returns. What if collector from other thread
>> "hijacks" heap
>>>> right at end of CheckStoreTraced()/well before
>> mutator
>>>> changes some reference field in object? 
>>>>>> 
>>>>>> Similar situaction is with "read barrier"
>> in
>>>> CheckLoadTraceRef(). Or at least it looks like one
>> to me
>>>> :).
>>>>>> 
>>>>>> dd
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>> 



From dabenavidesd at yahoo.es  Wed May  9 00:47:29 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 8 May 2012 23:47:29 +0100 (BST)
Subject: [M3devel] GC algorithm
In-Reply-To: <325641F7-37AF-4BCC-AB5C-78C1172090F0@m3w.org>
Message-ID: <1336517249.96878.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:

but contemporary of the SUN's profiler article.

Thanks in advance


--- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] GC algorithm
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "Antony Hosking" <antony.hosking at gmail.com>, "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 8 de mayo, 2012 17:40
> Very old news. In JVM world - five
> years is a lot. 13yrs are another age :).
>  
> On May 9, 2012, at 12:36 AM, Daniel Alejandro Benavides D.
> wrote:
> 
> > Hi all:
> > OK, understood, I think this kind of philosophy is
> smoother:
> > http://static.usenix.org/events/coots99/full_papers/liang/liang.pdf
> > 
> > Similarly the CM JVM  can be applied to this test
> too.
> > 
> > Look at this old news (it seems they didn't believe it
> that much, probably that's why they never released it):
> > http://www.informationweek.com/newsflash/nf655/1105_st9.htm
> > 
> > Thanks in advance
> > 
> > --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> >> De: Dragi?a Duri? <dragisha at m3w.org>
> >> Asunto: Re: [M3devel] GC algorithm
> >> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> >> CC: "Antony Hosking" <antony.hosking at gmail.com>,
> "m3devel" <m3devel at elegosoft.com>
> >> Fecha: martes, 8 de mayo, 2012 17:20
> >> G1 collector sounds interesting, and
> >> funny. Pause prediction - good luck with that.
> >> 
> >> Fast sweep through blurb on that page and I think
> this
> >> collector of theirs is a bit behind what we have
> in
> >> Modula-3. No wonder - Modula-3 had what they are
> describing
> >> and few things more years before Java existed.
> >> 
> >> Interesting tidbit, maybe. If they can collect with
> multiple
> >> threads at same time, that _is_ something new. But
> they
> >> danced around that on that page.
> >> 
> >> Also, G1 is not what Antony and his team did. They
> made
> >> real-time collector, and G1 is not. I think link
> was posted
> >> here some time ago.
> >> 
> >> On May 9, 2012, at 12:02 AM, Daniel Alejandro
> Benavides D.
> >> wrote:
> >> 
> >>> Hi all:
> >>> for my God sake, I think is better to be useful
> than
> >> useless, and if that's different from general than
> specific,
> >> that's better, but be careful, we could loose some
> Boehm GC
> >> correspondence in Gcc GC, which would in turn be
> useful for
> >> timing and short cutting the native Modula-3
> Collector,
> >> specially RTCollector SRC and perhaps the SUN test
> suite
> >> module (more on this later). Tony and his team did
> that:
> >>> 
> >>> http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
> >>> 
> >>> Thanks in advance
> >>> 
> >>> --- El mar, 8/5/12, Dragi?a Duri? <dragisha at m3w.org>
> >> escribi?:
> >>> 
> >>>> De: Dragi?a Duri? <dragisha at m3w.org>
> >>>> Asunto: Re: [M3devel] GC algorithm
> >>>> Para: "Antony Hosking" <antony.hosking at gmail.com>
> >>>> CC: "m3devel" <m3devel at elegosoft.com>
> >>>> Fecha: martes, 8 de mayo, 2012 16:21
> >>>> Got that. You pointed write barrier
> >>>> to me few yrs ago, and that's it.
> >>>> 
> >>>> I am reading through RTCollector.m3 in
> pieces of
> >> time I have
> >>>> to spare. Lots of legacy code there. Any
> good
> >> reaosn to keep
> >>>> several different functionalities in single
> source
> >> module?
> >>>> Like RTWeakRef, lots of differentable
> >> mutator/collector code
> >>>> and so on?
> >>>> 
> >>>> On May 8, 2012, at 11:12 PM, Antony Hosking
> wrote:
> >>>> 
> >>>>> Just following up quickly while
> extremely
> >> rushed.
> >>>>> Indeed, the fact that the mutator has
> the
> >> references on
> >>>> its stack will cause their targets to be
> pinned
> >> (not copied)
> >>>> if a collection intervenes between the
> marking and
> >> before
> >>>> the store.  So, they will be
> retained.
> >>>>> 
> >>>>> On May 4, 2012, at 4:37 PM, Dragi?a
> Duri?
> >> wrote:
> >>>>> 
> >>>>>> I am not very fluent with
> RTCollector
> >> source, but
> >>>> it looks to me there is at least one
> possible race
> >> condition
> >>>> situation possible.
> >>>>>> 
> >>>>>> RTHooks.CheckStoreTraced()
> explicitly marks
> >> object
> >>>> & its page dirty/not-clean. Everything
> with
> >> heap locked.
> >>>> But - next thing is - heaps is unlocked and
> this
> >> method
> >>>> returns. What if collector from other
> thread
> >> "hijacks" heap
> >>>> right at end of CheckStoreTraced()/well
> before
> >> mutator
> >>>> changes some reference field in object? 
> >>>>>> 
> >>>>>> Similar situaction is with "read
> barrier"
> >> in
> >>>> CheckLoadTraceRef(). Or at least it looks
> like one
> >> to me
> >>>> :).
> >>>>>> 
> >>>>>> dd
> >>>>>> 
> >>>>> 
> >>>> 
> >>>> 
> >> 
> >> 
> 
> 


From dragisha at m3w.org  Fri May 11 09:44:17 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 11 May 2012 09:44:17 +0200
Subject: [M3devel] Proposal for new pragma
Message-ID: <A1D021C3-0B10-4D2C-B0E2-FADCF857850E@m3w.org>

DEBUG and ASSERT pragmas are good examples of very helpful and almost non-intrusive debug features. UNUSED is also worth mention.

Another good one can be a way to tell compiler where some object is expected to be referenced. I am just reading big source and part of what I do is to add comments - in particular I comment where from is some procedure called/variable used. Putting this in pragma will not change language at all, but will help writing correct programs a lot.

Also, once we establish a framework for such attributes, steps can be taken towards further ways to ensure correctness of code we write.



From dragisha at m3w.org  Fri May 11 09:49:41 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 11 May 2012 09:49:41 +0200
Subject: [M3devel] Proposal for new pragma
Message-ID: <1EB31CDB-C6DC-4A42-B9EE-3CA0743028A0@m3w.org>

DEBUG and ASSERT pragmas are good examples of very helpful and almost non-intrusive debug features. UNUSED is also worth mention.

Another good one can be a way to tell compiler where some object is expected to be referenced. I am just reading big source and part of what I do is to add comments - in particular I comment where from is some procedure called/variable used. Putting this in pragma will not change language at all, but will help writing correct programs a lot.

Also, once we establish a framework for such attributes, steps can be taken towards further ways to ensure correctness of code we write.



From dabenavidesd at yahoo.es  Fri May 11 17:08:03 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 11 May 2012 16:08:03 +0100 (BST)
Subject: [M3devel] Proposal for new pragma
In-Reply-To: <82A6C364-C699-4C7C-B482-F197EF4D4D1B@m3w.org>
Message-ID: <1336748883.38986.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
any program can have such construct? The main con is if it does what does it mean to be undetected side-effects, sort of writing for your self. Also what does the program needs to do to ensure safety under such considerations. For instance does it allows a program to be checked?
It is not moral correct to write something to hide details of the implementation to it but to your self?
OK, you can ignore some details I guess but then who cares what you don't know, more than we don't know. This is the ideal; isn't to expose the structure of an operation towards getting the correct answer, if you can't make both something is wrong, both your program or your language.
In certain sense we can avoid undetected side-effects, but your responsibility is about it where there are ones. If your program can check or know that I think is wrong respect of that programmer, since he should read it without that help. Right? 
Thanks in advance
 

--- El vie, 11/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] Proposal for new pragma
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> Fecha: viernes, 11 de mayo, 2012 09:31
> Code readability will be nice effect
> of such a pragma. And - if written correctly, all pragmas
> have no to minimal side-effects.
> 
> On May 11, 2012, at 4:26 PM, Daniel Alejandro Benavides D.
> wrote:
> 
> > Hi all:
> > I'm not sure whether you want to handle inter
> procedural side effects, if that's the case Modula-3 done
> code needs arbitrary annotations of such constructs isn't
> guaranteed to be safely isolated since every annotation is
> side-effected then it could led towards the not sound
> Modular checking of ESC/Modula-3, etc. This is a natural
> deduction system.
> > Having said that I think is a good idea to allow
> recursion logic to Modula-3 procedures but this is precisely
> what Baby Modula-3 is about.
> > I don't have more details at hand but I think the idea
> if is yours the same has better compression of code,
> optimization and safe execution.
> > The good news is that object-code view of objects in
> Baby Modula-3 and Modula-3 is the same so all benefits are
> applicable.
> > Perhaps the other approach is just use the M3 AST and
> someone has done something akin to localize uncalled
> procedures, etc.
> > Thanks in advance
> > 
> > --- El vie, 11/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> >> De: Dragi?a Duri? <dragisha at m3w.org>
> >> Asunto: [M3devel] Proposal for new pragma
> >> Para: "m3devel" <m3devel at elegosoft.com>
> >> Fecha: viernes, 11 de mayo, 2012 02:49
> >> DEBUG and ASSERT pragmas are good
> >> examples of very helpful and almost non-intrusive
> debug
> >> features. UNUSED is also worth mention.
> >> 
> >> Another good one can be a way to tell compiler
> where some
> >> object is expected to be referenced. I am just
> reading big
> >> source and part of what I do is to add comments -
> in
> >> particular I comment where from is some procedure
> >> called/variable used. Putting this in pragma will
> not change
> >> language at all, but will help writing correct
> programs a
> >> lot.
> >> 
> >> Also, once we establish a framework for such
> attributes,
> >> steps can be taken towards further ways to ensure
> >> correctness of code we write.
> >> 
> >> 
> 
> 


From dragisha at m3w.org  Fri May 11 19:29:35 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 11 May 2012 19:29:35 +0200
Subject: [M3devel] Proposal for new pragma
In-Reply-To: <1336748883.38986.YahooMailClassic@web29704.mail.ird.yahoo.com>
References: <1336748883.38986.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <4B5415DB-107E-49EC-9AE7-7DCFB5088114@m3w.org>

It would ne kind of DEBUG/ASSERT/UNUSED.

Obviously, it is meant to be used in implementation. And to be optional. You may use it, but you don't have to.

As for moral? I'll no comment it :).

Side-effects are possible with DEBUG/ASSERT. They will be possible with this new pragma. Take care.

On May 11, 2012, at 5:08 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> any program can have such construct? The main con is if it does what does it mean to be undetected side-effects, sort of writing for your self. Also what does the program needs to do to ensure safety under such considerations. For instance does it allows a program to be checked?
> It is not moral correct to write something to hide details of the implementation to it but to your self?
> OK, you can ignore some details I guess but then who cares what you don't know, more than we don't know. This is the ideal; isn't to expose the structure of an operation towards getting the correct answer, if you can't make both something is wrong, both your program or your language.
> In certain sense we can avoid undetected side-effects, but your responsibility is about it where there are ones. If your program can check or know that I think is wrong respect of that programmer, since he should read it without that help. Right? 
> Thanks in advance
> 
> 
> --- El vie, 11/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
>> De: Dragi?a Duri? <dragisha at m3w.org>
>> Asunto: Re: [M3devel] Proposal for new pragma
>> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
>> Fecha: viernes, 11 de mayo, 2012 09:31
>> Code readability will be nice effect
>> of such a pragma. And - if written correctly, all pragmas
>> have no to minimal side-effects.
>> 
>> On May 11, 2012, at 4:26 PM, Daniel Alejandro Benavides D.
>> wrote:
>> 
>>> Hi all:
>>> I'm not sure whether you want to handle inter
>> procedural side effects, if that's the case Modula-3 done
>> code needs arbitrary annotations of such constructs isn't
>> guaranteed to be safely isolated since every annotation is
>> side-effected then it could led towards the not sound
>> Modular checking of ESC/Modula-3, etc. This is a natural
>> deduction system.
>>> Having said that I think is a good idea to allow
>> recursion logic to Modula-3 procedures but this is precisely
>> what Baby Modula-3 is about.
>>> I don't have more details at hand but I think the idea
>> if is yours the same has better compression of code,
>> optimization and safe execution.
>>> The good news is that object-code view of objects in
>> Baby Modula-3 and Modula-3 is the same so all benefits are
>> applicable.
>>> Perhaps the other approach is just use the M3 AST and
>> someone has done something akin to localize uncalled
>> procedures, etc.
>>> Thanks in advance
>>> 
>>> --- El vie, 11/5/12, Dragi?a Duri? <dragisha at m3w.org>
>> escribi?:
>>> 
>>>> De: Dragi?a Duri? <dragisha at m3w.org>
>>>> Asunto: [M3devel] Proposal for new pragma
>>>> Para: "m3devel" <m3devel at elegosoft.com>
>>>> Fecha: viernes, 11 de mayo, 2012 02:49
>>>> DEBUG and ASSERT pragmas are good
>>>> examples of very helpful and almost non-intrusive
>> debug
>>>> features. UNUSED is also worth mention.
>>>> 
>>>> Another good one can be a way to tell compiler
>> where some
>>>> object is expected to be referenced. I am just
>> reading big
>>>> source and part of what I do is to add comments -
>> in
>>>> particular I comment where from is some procedure
>>>> called/variable used. Putting this in pragma will
>> not change
>>>> language at all, but will help writing correct
>> programs a
>>>> lot.
>>>> 
>>>> Also, once we establish a framework for such
>> attributes,
>>>> steps can be taken towards further ways to ensure
>>>> correctness of code we write.
>>>> 
>>>> 
>> 
>> 



From hendrik at topoi.pooq.com  Sun May 13 19:47:47 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Sun, 13 May 2012 13:47:47 -0400
Subject: [M3devel] libXaw.so.6 again
Message-ID: <20120513174747.GA25729@topoi.pooq.com>

I just installed the AMD64 LINUX deb on my aging Debian stable system, 
tried it out, and got the familiar=from-years-ago message

 -> linking PgMdb
/usr/bin/ld: warning: libXaw.so.6, needed by 
/usr/local/cm3/pkg/formsvbt/AMD64_LINUX/libm3formsvbt.so, not found (try 
using -rpath or -rpath-link)
collect2: ld returned 1 exit status
  m3_link => 1
linker failed linking: PgMdb

Now the obvious thing to do is to install libXaw.so.6.

Except that the only libXaw packages available are libXaw7, libXaw7-dev, 
and similar for libXaw8.

So it  looks as if the .deb needs updating, presumably with a new Debian 
version number affixed.

-- hendrik



From hendrik at topoi.pooq.com  Sun May 13 19:50:49 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Sun, 13 May 2012 13:50:49 -0400
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120513174747.GA25729@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
Message-ID: <20120513175049.GA25774@topoi.pooq.com>

On Sun, May 13, 2012 at 01:47:47PM -0400, Hendrik Boom wrote:
> I just installed the AMD64 LINUX deb on my aging Debian stable system, 
> tried it out, and got the familiar=from-years-ago message
> 
>  -> linking PgMdb
> /usr/bin/ld: warning: libXaw.so.6, needed by 
> /usr/local/cm3/pkg/formsvbt/AMD64_LINUX/libm3formsvbt.so, not found (try 
> using -rpath or -rpath-link)
> collect2: ld returned 1 exit status
>   m3_link => 1
> linker failed linking: PgMdb
> 
> Now the obvious thing to do is to install libXaw.so.6.
> 
> Except that the only libXaw packages available are libXaw7, libXaw7-dev, 
> and similar for libXaw8.

Correction: no libXaw8-dev.
> 
> So it  looks as if the .deb needs updating, presumably with a new Debian 
> version number affixed.
> 
> -- hendrik
> 

The situation is pretty well the same on Debian testing i386.

-- hendrik



From dabenavidesd at yahoo.es  Sun May 13 20:06:44 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 13 May 2012 19:06:44 +0100 (BST)
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120513174747.GA25729@topoi.pooq.com>
Message-ID: <1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I think the packages in deb already do that so.6, so.7 thing for that purposes, you don't need to that for yourself, I believe.
Likewise, would be nicer if we could just relink a single executable for both kind of systems, both 32-bit and 64-bit, if there were 32-bit INTEGER and ADDRESS and 128-bit LONGINT and LONGADDRESS and 128-bit LONGCARD I think it could make a better precision arithmetic or double-length at less.
Thanks in advance

--- El dom, 13/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] libXaw.so.6 again
> Para: m3devel at elegosoft.com
> Fecha: domingo, 13 de mayo, 2012 12:47
> I just installed the AMD64 LINUX deb
> on my aging Debian stable system, 
> tried it out, and got the familiar=from-years-ago message
> 
>  -> linking PgMdb
> /usr/bin/ld: warning: libXaw.so.6, needed by 
> /usr/local/cm3/pkg/formsvbt/AMD64_LINUX/libm3formsvbt.so,
> not found (try 
> using -rpath or -rpath-link)
> collect2: ld returned 1 exit status
>   m3_link => 1
> linker failed linking: PgMdb
> 
> Now the obvious thing to do is to install libXaw.so.6.
> 
> Except that the only libXaw packages available are libXaw7,
> libXaw7-dev, 
> and similar for libXaw8.
> 
> So it  looks as if the .deb needs updating, presumably
> with a new Debian 
> version number affixed.
> 
> -- hendrik
> 
> 


From hendrik at topoi.pooq.com  Mon May 14 04:52:18 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Sun, 13 May 2012 22:52:18 -0400
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <20120514025218.GA32463@topoi.pooq.com>

On Sun, May 13, 2012 at 07:06:44PM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all:
> I think the packages in deb already do that so.6, so.7 thing for that 
> purposes, you don't need to that for yourself, I believe.

Whatever do you mean?  It wants libXaw.so.6, which no longer exists and 
has been replaced by libXaw.so.7.  Whatever "that so.6, so.7 thing" is 
that the packages in deb already do, the modula 2 in the debian package 
I downloaded just now from the Modula 3 website insists that my 
executable needs libXaw.so.6, not the one I have available.

Maybe if the .deb were recompiled and repackaged from source it would 
find libXaw.so.7, but the one now available does not.

-- hendrik

> Likewise, would be nicer if we could just relink a single executable 
> for both kind of systems, both 32-bit and 64-bit, if there were 32-bit 
> INTEGER and ADDRESS and 128-bit LONGINT and LONGADDRESS and 128-bit 
> LONGCARD I think it could make a better precision arithmetic or 
> double-length at less.

This has nothing to do with the question.

-- hendrik


From dabenavidesd at yahoo.es  Mon May 14 07:24:11 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 May 2012 06:24:11 +0100 (BST)
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120514025218.GA32463@topoi.pooq.com>
Message-ID: <1336973051.28791.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
OK, thanks for the message, I meant what I think is the case for say Ubuntu 8.04 Dapper LTS (Long time support), have libXaw6 and libXaw7 packages in .deb.
I don't think that you need to relink the all package (or worse than that rebuild to link .so.7) but just use your OS for that (because we will loose support for other OSes that don't have literally have such version).
And to make a smarter solution I would use LONG (adress) arithmetic to relink same executable for two kind of "different" architectures. You think isn't the same, but I think they are but one is just an extension of the other so why not support that as well.
Then why would you need to test I386, and AMD64 versions (then the question is the name of that target x86-32AMD64), but just the same executable and the same thing (again, use your OS for that, don't change your build conf).
Certainly this are configuration management issues, that the software engineer shouldn't care, should you?
Thanks in advance


--- El dom, 13/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] libXaw.so.6 again
> Para: m3devel at elegosoft.com
> Fecha: domingo, 13 de mayo, 2012 21:52
> On Sun, May 13, 2012 at 07:06:44PM
> +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I think the packages in deb already do that so.6, so.7
> thing for that 
> > purposes, you don't need to that for yourself, I
> believe.
> 
> Whatever do you mean?  It wants libXaw.so.6, which no
> longer exists and 
> has been replaced by libXaw.so.7.  Whatever "that so.6,
> so.7 thing" is 
> that the packages in deb already do, the modula 2 in the
> debian package 
> I downloaded just now from the Modula 3 website insists that
> my 
> executable needs libXaw.so.6, not the one I have available.
> 
> Maybe if the .deb were recompiled and repackaged from source
> it would 
> find libXaw.so.7, but the one now available does not.
> 
> -- hendrik
> 
> > Likewise, would be nicer if we could just relink a
> single executable 
> > for both kind of systems, both 32-bit and 64-bit, if
> there were 32-bit 
> > INTEGER and ADDRESS and 128-bit LONGINT and LONGADDRESS
> and 128-bit 
> > LONGCARD I think it could make a better precision
> arithmetic or 
> > double-length at less.
> 
> This has nothing to do with the question.
> 
> -- hendrik
> 


From dragisha at m3w.org  Mon May 14 07:32:49 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 14 May 2012 07:32:49 +0200
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120514025218.GA32463@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
Message-ID: <C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>

Source change (relevant m3makefile) is one path.

Another is to ln -s existing libXaw.so.7 to libXaw.so.6

dd

On May 14, 2012, at 4:52 AM, Hendrik Boom wrote:

> On Sun, May 13, 2012 at 07:06:44PM +0100, Daniel Alejandro Benavides D. wrote:
>> Hi all:
>> I think the packages in deb already do that so.6, so.7 thing for that 
>> purposes, you don't need to that for yourself, I believe.
> 
> Whatever do you mean?  It wants libXaw.so.6, which no longer exists and 
> has been replaced by libXaw.so.7.  Whatever "that so.6, so.7 thing" is 
> that the packages in deb already do, the modula 2 in the debian package 
> I downloaded just now from the Modula 3 website insists that my 
> executable needs libXaw.so.6, not the one I have available.
> 
> Maybe if the .deb were recompiled and repackaged from source it would 
> find libXaw.so.7, but the one now available does not.
> 
> -- hendrik
> 
>> Likewise, would be nicer if we could just relink a single executable 
>> for both kind of systems, both 32-bit and 64-bit, if there were 32-bit 
>> INTEGER and ADDRESS and 128-bit LONGINT and LONGADDRESS and 128-bit 
>> LONGCARD I think it could make a better precision arithmetic or 
>> double-length at less.
> 
> This has nothing to do with the question.
> 
> -- hendrik



From mika at async.caltech.edu  Mon May 14 08:51:15 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sun, 13 May 2012 23:51:15 -0700
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org> 
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
Message-ID: <20120514065115.6FD231A205B@async.async.caltech.edu>

=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
...
>Another is to ln -s existing libXaw.so.7 to libXaw.so.6
...

"Not guaranteed to work" but almost always does, right?


From jay.krell at cornell.edu  Mon May 14 09:20:08 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 May 2012 07:20:08 +0000
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120514065115.6FD231A205B@async.async.caltech.edu>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>,
	<20120514025218.GA32463@topoi.pooq.com>,
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>,
	<20120514065115.6FD231A205B@async.async.caltech.edu>
Message-ID: <COL101-W216A71B993859824CC43E5E61A0@phx.gbl>


Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
I find this very surprising, crazy, disappointing, but apparently true.
We must distribute source to achieve the usual expected portability.
 C source at that, to achieve the usual expected buildability.
Or maybe I'm confused.
The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.


 - Jay


> To: dragisha at m3w.org
> Date: Sun, 13 May 2012 23:51:15 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] libXaw.so.6 again
> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/2798e2e1/attachment-0002.html>

From dragisha at m3w.org  Mon May 14 10:04:15 2012
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 14 May 2012 10:04:15 +0200
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <20120514065115.6FD231A205B@async.async.caltech.edu>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
Message-ID: <1336982655.1500.9.camel@boromir.m3w.org>

Depends on how major are changes from .6 to .7. At my Fedora box package
version is 1.0.8 and library is libXaw.so.7. Looks like it is minor
change (source/package wise) but number was bumped (probably after
XFree86 schism).


As for binary compatibility Jay mentioned... I don't think many Windows
98 programs will work without hickups on Windows 8. YMMV :).

Under Linux minor version number changes are expected to be binary
compatible. Major version number changes indicate API changes or
additions. Package using libXaw.so.6 is probably revised ages ago. Error
you are getting now says, to me, "Time to check source/API changes".

Belief in eternally invariant API anywhere is naive.

On Sun, 2012-05-13 at 23:51 -0700, Mika Nystrom wrote:
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?

As long as API is not changed, link time will show would it work or not.
Execution is ultimate test :).

-- 
Dragi?a Duri? <dragisha at m3w.org>



From dabenavidesd at yahoo.es  Mon May 14 14:24:47 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 May 2012 13:24:47 +0100 (BST)
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
Message-ID: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler, but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
Thanks in advance

?

--- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] libXaw.so.6 again
Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de mayo, 2012 02:20




Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
I find this very surprising, crazy, disappointing, but apparently true.
We must distribute source to achieve the usual expected portability.
?C source at that, to achieve the usual expected buildability.
Or maybe I'm confused.
The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.


?- Jay


> To: dragisha at m3w.org
> Date: Sun, 13 May 2012 23:51:15 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] libXaw.so.6 again
> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/81764fc1/attachment-0002.html>

From microcode at zoho.com  Mon May 14 14:41:02 2012
From: microcode at zoho.com (microcode at zoho.com)
Date: Mon, 14 May 2012 12:41:02 +0000
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
	<1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <575839211-1336999209-cardhu_decombobulator_blackberry.rim.net-1028218551-@b1.c1.bise3.blackberry>

I think this could be solved by static linking mostly, but there could still be problems with libc/glibc as I found out with FPC recently. Surely somebody who knows UNIX/Linux ought to be able to figure a way around this. 

-----Original Message-----
From: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
Date: Mon, 14 May 2012 13:24:47 
To: Mika Nystrom<mika at async.caltech.edu>; <dragisha at m3w.org>; Jay K<jay.krell at cornell.edu>
Cc: m3devel<m3devel at elegosoft.com>
Subject: Re: [M3devel] libXaw.so.6 again

Hi all:
'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler, but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
Thanks in advance

?

--- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] libXaw.so.6 again
Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de mayo, 2012 02:20




Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
I find this very surprising, crazy, disappointing, but apparently true.
We must distribute source to achieve the usual expected portability.
?C source at that, to achieve the usual expected buildability.
Or maybe I'm confused.
The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.


?- Jay


> To: dragisha at m3w.org
> Date: Sun, 13 May 2012 23:51:15 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] libXaw.so.6 again
> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?
 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/2ab44f33/attachment-0002.html>

From dabenavidesd at yahoo.es  Mon May 14 15:37:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 May 2012 14:37:24 +0100 (BST)
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <575839211-1336999209-cardhu_decombobulator_blackberry.rim.net-1028218551-@b1.c1.bise3.blackberry>
Message-ID: <1337002644.8248.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
respect of this:
http://compilers.iecc.com/comparch/article/94-11-053

The quest is to have a machine-independent compiler at the end but I think nobody cares that, and with industry making ever user machine C dependent it just calls for breaking the rules and make an improvement here.
Dec had an industrial compiler optimization system for all languages but I don't know if Modula-3 was ported to that as well, assuming they never used it for years just says how bad the computers evolved in C-ism, as DEC tried to imitate:
http://compilers.iecc.com/comparch/article/92-06-037

I think it didn't achieved it as far as It appears. 
Thanks in advance

--- El lun, 14/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

De: microcode at zoho.com <microcode at zoho.com>
Asunto: Re: [M3devel] libXaw.so.6 again
Para: m3devel at elegosoft.com
Fecha: lunes, 14 de mayo, 2012 07:41

I think this could be solved by static linking mostly, but there could still be problems with libc/glibc as I found out with FPC recently. Surely somebody who knows UNIX/Linux ought to be able to figure a way around this. 
From:  "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
Date: Mon, 14 May 2012 13:24:47 +0100 (BST)To: Mika Nystrom<mika at async.caltech.edu>; <dragisha at m3w.org>; Jay K<jay.krell at cornell.edu>Cc: m3devel<m3devel at elegosoft.com>Subject: Re: [M3devel] libXaw.so.6 again
Hi all:
'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler,
 but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
Thanks in advance

?

--- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] libXaw.so.6 again
Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de mayo, 2012 02:20




Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
I find this very surprising, crazy, disappointing, but apparently true.
We must distribute source to achieve the usual expected portability.
?C source at that, to achieve the usual expected buildability.
Or maybe I'm confused.
The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.


?- Jay


> To: dragisha at m3w.org
> Date: Sun, 13 May 2012 23:51:15 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] libXaw.so.6 again
> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> ...
> >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> ...
> 
> "Not guaranteed to work" but almost always does, right?
 		
 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/f1edbad1/attachment-0002.html>

From hendrik at topoi.pooq.com  Mon May 14 17:44:41 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 14 May 2012 11:44:41 -0400
Subject: [M3devel] libXaw.so.7
In-Reply-To: <COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
	<COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
Message-ID: <20120514154441.GA26098@topoi.pooq.com>

On Mon, May 14, 2012 at 07:20:08AM +0000, Jay K wrote:
> 
> Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
> I find this very surprising, crazy, disappointing, but apparently true.
> We must distribute source to achieve the usual expected portability.
>  C source at that, to achieve the usual expected buildability.
> Or maybe I'm confused.
> The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.

Here's what aptitude has to say about libXaw7:

libXaW7 provides the second versin of XaW, the Athena Widgets toolkit, which is
largely used by legacy X applications.  This version is the most common
version, ass version 6 is considered deprecated, and vesion 8, which adds
Xprint support, is unsupported and not widely used. In geneeral use of a more
modern toolkit such as GTK+ is recommended

Now I'm not going to suggest that we abolish all use of libXaw in favour of 
GTK+.  But whatever other systems it runs on, the deb package for Modula 
3 does not work on any current version of Debian (neither  stable, 
testing, nor sid).  A new .deb needs to be made, if ti is to work 
properly on debian (surely the canonical userr of .deb packages)

I might add that if modula3 were still part of Debian, it should have 
had a dependdency on libXaw6, and that might have sufficed either to 
keep libXaw6 alive as a legacy package in additino to libXaw7, or to 
alert the maintainer that the Modula3 package needed to be updated 
somewhere early in the Debian deployment process -- certainly long 
before the advend of squeeze. 

But getting modula 3 back into Debian is another project, and possibly a 
big one.  Even the current modula 3 debs, though adequate for my 
purposes if updatad, are not nearly adequate for distribution via Debian 
because of matters like the file system standard and the like.

Now I'm guessing the code that is run to create the .deb files is still
around somewhere.  Are there clear instructions how to go about 
finding it and using it to make a debian source package and debian 
binary packages?

-- hendrik



From jay.krell at cornell.edu  Mon May 14 22:00:20 2012
From: jay.krell at cornell.edu (Jay)
Date: Mon, 14 May 2012 13:00:20 -0700
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <2FEF5A4D-F529-4F18-8927-7F99EAC92D4D@gmail.com>

The age of the toolchain is not the problem. And gcc has little/nothing to do with it (unless you worry about C++ exceptionhandling/RTTI ABI) Linux/OpenBSD/FreeBSD/NetBSD seemingly don't try to retain binary compatibility. I don't know if security fixes are too blame but I doubt it.


Shipping assembly source would help -- where the breakage is only the .so name. I want to ship C source.

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 14, 2012, at 5:24 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> 'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
> Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler, but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
> Thanks in advance
> 
>  
> 
> --- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] libXaw.so.6 again
> Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 14 de mayo, 2012 02:20
> 
> Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
> I find this very surprising, crazy, disappointing, but apparently true.
> We must distribute source to achieve the usual expected portability.
>  C source at that, to achieve the usual expected buildability.
> Or maybe I'm confused.
> The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.
> 
> 
>  - Jay
> 
> 
> > To: dragisha at m3w.org
> > Date: Sun, 13 May 2012 23:51:15 -0700
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] libXaw.so.6 again
> > 
> > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> > ...
> > >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
> > ...
> > 
> > "Not guaranteed to work" but almost always does, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/00c540b1/attachment-0002.html>

From hendrik at topoi.pooq.com  Tue May 15 00:09:33 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 14 May 2012 18:09:33 -0400
Subject: [M3devel] Where is libXaw6 even used?
In-Reply-To: <20120514154441.GA26098@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
	<COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
	<20120514154441.GA26098@topoi.pooq.com>
Message-ID: <20120514220933.GA31311@topoi.pooq.com>

On Mon, May 14, 2012 at 11:44:41AM -0400, Hendrik Boom wrote:

I've been grepping through the src directories in the ...src-all-... archive, and the only mentions of Xaw I've found is in the Tetris game, and in a file called m3-comm/sharedobjgen/test/trackerpos/src/PATHTracker, whicch seems to be a  list of interface names and directory paths,
some with '@' signs.

What needs to be changed so it will find libXaw.so.7?  Or if I just need 
to recompile something so that it can fine libXaw.so.7, what do I need 
to recompile?

-- hendrik



From jay.krell at cornell.edu  Tue May 15 00:52:55 2012
From: jay.krell at cornell.edu (Jay)
Date: Mon, 14 May 2012 15:52:55 -0700
Subject: [M3devel] libXaw.so.6 again
In-Reply-To: <2FEF5A4D-F529-4F18-8927-7F99EAC92D4D@gmail.com>
References: <1336998287.53757.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<2FEF5A4D-F529-4F18-8927-7F99EAC92D4D@gmail.com>
Message-ID: <6C826E60-81C2-4D63-859A-5BC799F9B80E@gmail.com>

Clarification: shipping assembly source would include, in today's structuring, shipping a little C too. Heck, we could ship .o files and some .c, & that would fix the entire binary compatibility problem for us (assembly or .o). Playing a little fast&loose wrt Xlib.h but probably ok.


My plan to ship C would probably ship strange low level C that doesn't improve things wrt binary compatibility. Unless someone has a scheme in mind for a backend that generates #include sys/types & such?


There is a point to ship C, just not likely relevant to binary compatibility.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 14, 2012, at 1:00 PM, Jay <jay.krell at cornell.edu> wrote:

> The age of the toolchain is not the problem. And gcc has little/nothing to do with it (unless you worry about C++ exceptionhandling/RTTI ABI) Linux/OpenBSD/FreeBSD/NetBSD seemingly don't try to retain binary compatibility. I don't know if security fixes are too blame but I doubt it.
> 
> 
> Shipping assembly source would help -- where the breakage is only the .so name. I want to ship C source.
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On May 14, 2012, at 5:24 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:
> 
>> Hi all:
>> 'forwards compatibility' is not achieved by any of OSes because of Gcc merits as it should be, but backwards also don't say a word as expected, mainly due "security issues", so I don't know if commercial *ix are, at least have the sources should make that easier I guess; I once tried to compile a virtual machine package and I was told that first find my distro's 'minimum common factor' and cross-compile to that system and then recompile everything on it, but I solved hacking the virtual machine sources, so my guess is that you can have 'forwards compatibility' if you can get a sufficient old version of your tool chain and OS to cross-compile from newer.
>> Modula-3 had this nice thing of emitting the "assembly sources" and emit native code for the platform in-situ and relink everything (so sort of eliminate the requisite of having an older compiler, but just native gcc nice to do). Maybe this would be a nice to have item for next releases, wouldn't be?
>> Thanks in advance
>> 
>>  
>> 
>> --- El lun, 14/5/12, Jay K <jay.krell at cornell.edu> escribi?:
>> 
>> De: Jay K <jay.krell at cornell.edu>
>> Asunto: Re: [M3devel] libXaw.so.6 again
>> Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
>> CC: "m3devel" <m3devel at elegosoft.com>
>> Fecha: lunes, 14 de mayo, 2012 02:20
>> 
>> Apparently free/open Unices (Linux, OpenBSD, FreeBSD, NetBSD) have no binary compatibility.
>> I find this very surprising, crazy, disappointing, but apparently true.
>> We must distribute source to achieve the usual expected portability.
>>  C source at that, to achieve the usual expected buildability.
>> Or maybe I'm confused.
>> The various commerical systems (Solaris, AIX, Irix, VMS, Windows, Darwin, HP-UX) do/did not have this problem.
>> 
>> 
>>  - Jay
>> 
>> 
>> > To: dragisha at m3w.org
>> > Date: Sun, 13 May 2012 23:51:15 -0700
>> > From: mika at async.caltech.edu
>> > CC: m3devel at elegosoft.com
>> > Subject: Re: [M3devel] libXaw.so.6 again
>> > 
>> > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
>> > ...
>> > >Another is to ln -s existing libXaw.so.7 to libXaw.so.6
>> > ...
>> > 
>> > "Not guaranteed to work" but almost always does, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120514/1a8fa988/attachment-0002.html>

From dragisha at m3w.org  Tue May 15 01:58:19 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 15 May 2012 01:58:19 +0200
Subject: [M3devel] Where is libXaw6 even used?
In-Reply-To: <20120514220933.GA31311@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
	<COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
	<20120514154441.GA26098@topoi.pooq.com>
	<20120514220933.GA31311@topoi.pooq.com>
Message-ID: <63183557-3F71-445A-B860-BDEE84A250F3@m3w.org>

Maybe you just need to link libXaw.so.7 on your system to libXaw.so

cm3 handlig of system shared libs? :)

On May 15, 2012, at 12:09 AM, Hendrik Boom wrote:

> On Mon, May 14, 2012 at 11:44:41AM -0400, Hendrik Boom wrote:
> 
> I've been grepping through the src directories in the ...src-all-... archive, and the only mentions of Xaw I've found is in the Tetris game, and in a file called m3-comm/sharedobjgen/test/trackerpos/src/PATHTracker, whicch seems to be a  list of interface names and directory paths,
> some with '@' signs.
> 
> What needs to be changed so it will find libXaw.so.7?  Or if I just need 
> to recompile something so that it can fine libXaw.so.7, what do I need 
> to recompile?
> 
> -- hendrik
> 



From hendrik at topoi.pooq.com  Tue May 15 05:14:37 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 14 May 2012 23:14:37 -0400
Subject: [M3devel] libXaw
In-Reply-To: <63183557-3F71-445A-B860-BDEE84A250F3@m3w.org>
References: <20120513174747.GA25729@topoi.pooq.com>
	<1336932404.37215.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120514025218.GA32463@topoi.pooq.com>
	<C05B33B0-5B07-4F03-9542-F7F232E53DE4@m3w.org>
	<20120514065115.6FD231A205B@async.async.caltech.edu>
	<COL101-W216A71B993859824CC43E5E61A0@phx.gbl>
	<20120514154441.GA26098@topoi.pooq.com>
	<20120514220933.GA31311@topoi.pooq.com>
	<63183557-3F71-445A-B860-BDEE84A250F3@m3w.org>
Message-ID: <20120515031437.GA1025@topoi.pooq.com>

On Tue, May 15, 2012 at 01:58:19AM +0200, Dragi?a Duri? wrote:
> Maybe you just need to link libXaw.so.7 on your system to libXaw.so

You mean like this?

hendrik at notlookedfor:/farhome/hendrik/cm3/src-all$ ls /usr/lib/i386-linux-gnu/*Xaw* -l
-rw-r--r-- 1 root root 540512 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw7.a
lrwxrwxrwx 1 root root     16 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw7.so -> libXaw7.so.7.0.0
lrwxrwxrwx 1 root root     16 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw7.so.7 -> libXaw7.so.7.0.0
-rw-r--r-- 1 root root 428900 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw7.so.7.0.0
lrwxrwxrwx 1 root root     10 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw.so -> libXaw7.so
lrwxrwxrwx 1 root root     12 Apr 12 08:19 /usr/lib/i386-linux-gnu/libXaw.so.7 -> libXaw7.so.7
hendrik at notlookedfor:/farhome/hendrik/cm3/src-all$ 

Already done by the system.  The compiler is quite clear that it wants
libXaw.so.6.

The reference to libXaw has to occur in the code base, no? 

Presumably I have to recompile something that refers to Xaw, 
so it will find these links while building one of the m3 libraries 
(and maybe everything that depends on it)and end up with a dependency 
on libXaw7 in the binary.

But I can't find it.

-- hendrik


From hendrik at topoi.pooq.com  Tue May 15 17:12:18 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Tue, 15 May 2012 11:12:18 -0400
Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
In-Reply-To: <20120513174747.GA25729@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
Message-ID: <20120515151217.GA23964@topoi.pooq.com>

I got it to recognise libXaw.se.7.

I downloaded and untarred the src-all archive.

I used cm3 to compile and ship several libraries:

 m3-ui/formsvbt
 m3-ui/videovbt
 m3-ui/vbtkit
 m3-ui/ui
 m3-ui/X11R4

Each one was simple, like
   cd formsvbt
   cm3
   cm3 -ship

I identified the libraries that needed recompilation fron the 
compilation error messages I got whein compiling the program I was 
originally trying to work on.  A message like:

/usr/bin/ld: warning: libXaw.so.6, needed by /usr/local/cm3/pkg/vbtkit/AMD64_LINUX/libm3vbtkit.so, not found (try using -rpath or -rpath-link)

indicated recompiling  m3-ui/vbtkit (I had to look around in src-all too 
figure out the m3-ui part).

At least these libraries work now.  So my immediate objective is 
accomplished.

But the job is  not done.  This is simply too much to inflict on an 
inexperienced beginner.  He'd pretty well have to desperately want to 
use Modula 3 to go to all this trouble AND have the advice of an 
experienced Modula 3 user (such as me, and I had trouble!) to get this 
far.

The next steps, which I *will* need help with if I am to do them, are:

figure out which other libraries have similar obsolete dependencies.

recompile them

Prepare new distribution archives and a new .deb file, suitably 
annotated as to which Debian release they work with.

The .deb is surely the easiest way for a beginner to install Modula 3 on 
Debian.

Make the .deb spread its contents over the file system, as required for 
it to be accepted into Debian again.  Modula 3 has been absent from 
Debian for far too long.

-- hendrik


From dabenavidesd at yahoo.es  Tue May 15 18:37:08 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 15 May 2012 17:37:08 +0100 (BST)
Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
In-Reply-To: <20120515151217.GA23964@topoi.pooq.com>
Message-ID: <1337099828.15747.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I agree, but wherever they depended on must be configured by hand >= so.7 or around base versions >= so.6, so maybe just create a link command cm3 -relink to use a grater version, sometimes I have seen linker warnings at compile time so kind of show dependencies linker if possible at compile time should help.
Win32 older version m3loader go option help says ' CmdFunc { "go", "", "Relink any new modules, then run", go } }; '
The all program module by module, so this could be better than that, but we must redistribute (to the extent possible) pre-compiled versions of major or minor sub-versions. Besides work in the experimental version for UNIX.
Thanks in advance 

--- El mar, 15/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] Success with  libXaw.so.7, but more help needed.
> Para: m3devel at elegosoft.com
> Fecha: martes, 15 de mayo, 2012 10:12
> I got it to recognise libXaw.se.7.
> 
> I downloaded and untarred the src-all archive.
> 
> I used cm3 to compile and ship several libraries:
> 
>  m3-ui/formsvbt
>  m3-ui/videovbt
>  m3-ui/vbtkit
>  m3-ui/ui
>  m3-ui/X11R4
> 
> Each one was simple, like
>    cd formsvbt
>    cm3
>    cm3 -ship
> 
> I identified the libraries that needed recompilation fron
> the 
> compilation error messages I got whein compiling the program
> I was 
> originally trying to work on.  A message like:
> 
> /usr/bin/ld: warning: libXaw.so.6, needed by
> /usr/local/cm3/pkg/vbtkit/AMD64_LINUX/libm3vbtkit.so, not
> found (try using -rpath or -rpath-link)
> 
> indicated recompiling  m3-ui/vbtkit (I had to look
> around in src-all too 
> figure out the m3-ui part).
> 
> At least these libraries work now.  So my immediate
> objective is 
> accomplished.
> 
> But the job is  not done.  This is simply too much
> to inflict on an 
> inexperienced beginner.  He'd pretty well have to
> desperately want to 
> use Modula 3 to go to all this trouble AND have the advice
> of an 
> experienced Modula 3 user (such as me, and I had trouble!)
> to get this 
> far.
> 
> The next steps, which I *will* need help with if I am to do
> them, are:
> 
> figure out which other libraries have similar obsolete
> dependencies.
> 
> recompile them
> 
> Prepare new distribution archives and a new .deb file,
> suitably 
> annotated as to which Debian release they work with.
> 
> The .deb is surely the easiest way for a beginner to install
> Modula 3 on 
> Debian.
> 
> Make the .deb spread its contents over the file system, as
> required for 
> it to be accepted into Debian again.  Modula 3 has been
> absent from 
> Debian for far too long.
> 
> -- hendrik
> 


From jay.krell at cornell.edu  Wed May 16 00:33:12 2012
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 15 May 2012 22:33:12 +0000
Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
In-Reply-To: <20120515151217.GA23964@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>
Message-ID: <COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>


You might as well just use something in scripts to rebuild the entire system.It isn't so difficult nor takes very long.     Get a working cm3 on any system.      cd scripts/python      ./boot1.py <target-such-as-I386_LINUX>      That will produce a "bootstrap" archive.    Copy it to the "new" system.      Extract it.      Cd into it.      Look at the top of Makefile and see if it seems reasonable (we should use autoconf here).    run make.     That should give you a working cm3 for the new system.      Put that on path, e.g.:       su        rm -rf /usr/local/cm3       mkdir -p /usr/local/cm3/bin        cp cm3 /usr/local/cm3/bin        exit         PATH=/usr/local/cm3/bin:$PATH     cd to scripts/python in the source tree on the new system.    Then run ./boot2.sh       Then ./make-dist.py.    That should give you the entire system newly built, and a .deb.  If you already have a working cm3 on the system you want to run it on  cd scripts/python   ./upgrade.py    ./make-dist.py     I'd really like to get to the point of:  extract    ./configure    make    make install  or make deb   To make this work how people really want, we have to have a C-generating backend.Or else provide binary packages for "every" system, which isn't viable.   If Linux distributions took binary compatibility seriously, we wouldn't have this problem.They seem to encourage/require rebuilds for every revision.But surely this is not true, as there exist some closed source products like Adobe Acrobat?There is no such problem on Windows, nor I suspect Solaris, nor hypothetically on Irix, AIX, VMS, HP-UX, Tru64, etc.   - Jay
> Date: Tue, 15 May 2012 11:12:18 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
> 
> I got it to recognise libXaw.se.7.
> 
> I downloaded and untarred the src-all archive.
> 
> I used cm3 to compile and ship several libraries:
> 
>  m3-ui/formsvbt
>  m3-ui/videovbt
>  m3-ui/vbtkit
>  m3-ui/ui
>  m3-ui/X11R4
> 
> Each one was simple, like
>    cd formsvbt
>    cm3
>    cm3 -ship
> 
> I identified the libraries that needed recompilation fron the 
> compilation error messages I got whein compiling the program I was 
> originally trying to work on.  A message like:
> 
> /usr/bin/ld: warning: libXaw.so.6, needed by /usr/local/cm3/pkg/vbtkit/AMD64_LINUX/libm3vbtkit.so, not found (try using -rpath or -rpath-link)
> 
> indicated recompiling  m3-ui/vbtkit (I had to look around in src-all too 
> figure out the m3-ui part).
> 
> At least these libraries work now.  So my immediate objective is 
> accomplished.
> 
> But the job is  not done.  This is simply too much to inflict on an 
> inexperienced beginner.  He'd pretty well have to desperately want to 
> use Modula 3 to go to all this trouble AND have the advice of an 
> experienced Modula 3 user (such as me, and I had trouble!) to get this 
> far.
> 
> The next steps, which I *will* need help with if I am to do them, are:
> 
> figure out which other libraries have similar obsolete dependencies.
> 
> recompile them
> 
> Prepare new distribution archives and a new .deb file, suitably 
> annotated as to which Debian release they work with.
> 
> The .deb is surely the easiest way for a beginner to install Modula 3 on 
> Debian.
> 
> Make the .deb spread its contents over the file system, as required for 
> it to be accepted into Debian again.  Modula 3 has been absent from 
> Debian for far too long.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120515/872c95c3/attachment-0002.html>

From hendrik at topoi.pooq.com  Wed May 16 16:56:53 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 10:56:53 -0400
Subject: [M3devel] Building packages
In-Reply-To: <COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
Message-ID: <20120516145653.GA19959@topoi.pooq.com>

On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote, and hendrik reformatted:
> 
> You might as well just use something in scripts to rebuild the entire 
> system.It isn't so difficult nor takes very long.
>
> Get a working cm3 on any system.
>      cd scripts/python
>      ./boot1.py <target-such-as-I386_LINUX>

So any cm3 system is capable of creating a bootstrap archive for any other cm3 system

> That will produce a "bootstrap" archive.  Copy it to the "new" system.
> Extract it.
> Cd into it.
> Look at the top of Makefile and see if it seems reasonable (we 
> should use autoconf here).
> run make.
> That should give you a working cm3 for the new system.

just the compiler (and what it needs to work), presumably.

> Put that on path, e.g.:
>      su
>      rm -rf /usr/local/cm3

clearing out any old cm3 system completely

>      mkdir -p /usr/local/cm3/bin
>      cp cm3 /usr/local/cm3/bin

And putting the noew one where it can be executed.

>      exit
>      PATH=/usr/local/cm3/bin:$PATH

And this then builds everything, and makes a .deb

> cd to scripts/python in the source tree on the new system.
> Then run ./boot2.sh
> Then ./make-dist.py.
> That should give you the entire system newly built, and a .deb.

I recal there are a few place in the Modula 3 build p[rocess where it 
requires other resources to already exit (the data base stuff is one I 
recall).  If they are not available, will the process fail, or will if 
just build an incomplete .deb?

>
>  If you already have a working cm3 on the system you want to run it on

Which is what I've got on my two machines, so this is what I'll be 
trying.

>     cd scripts/python
>     ./upgrade.py

this script recompiles everything from the complete source tree?  Does 
it ship it?  Or place it somewhere else on the system?  Is it important 
for the already working cm3 compiler to be the same version as the one 
in the source tree being packaged?  And is there also a source package 
built?  Because the source package is what's needed for uploading to 
Debian.

>     ./make-dist.py

And this packages it from the shipped location?

> I'd really like to get to the point of:
>  extract
>    ./configure
>    make
>    make install  or make deb
>
> To make this work how people really want, we have to have a 
> C-generating backend.Or else provide binary packages for "every" 
> system, which isn't viable.  If Linux distributions took binary 
> compatibility seriously, we wouldn't have this problem.

That is. apparently, deliberate policy.  Linux aims for source-code 
compatibility.

Even the kernel calls aren't really guaranteed to stay the same, but 
there's a run-time library that's supposed to be used to call them.  And 
that's Unix policy, from way back in the 70's.

Binary-based distributions routinely compile the entire Linux system 
for each major release.  They do it package by package, but they do it.

I wonder how gcc does its bootstrap.  Presumably it's a package thet 
build-depends on itself, or something like that.

> They seem to 
> encourage/require rebuilds for every revision.But surely this is not 
> true, as there exist some closed source products like Adobe 
> Acrobat?

Such products try to have very few library dependencies.

> There is no such problem on Windows, nor I suspect Solaris, 
> nor hypothetically on Irix, AIX, VMS, HP-UX, Tru64, etc.

And that's been one of the major problems Microsoft has had with 
developing Windows.  When things need to change, you get legacy 
compatibility hacks like making the details of the storage 
allocation system calls depend on the name of the application 
being executed.

It also enables and encourages third-party developers to distribute 
application in binary only, making source code inavailable.  And that in 
turn makes it necessary to remain long-term compatible with ancient 
bugs.

-- hendrik


From hendrik at topoi.pooq.com  Wed May 16 17:26:35 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 11:26:35 -0400
Subject: [M3devel] Building packages
In-Reply-To: <20120516145653.GA19959@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
Message-ID: <20120516152635.GA20806@topoi.pooq.com>

On Wed, May 16, 2012 at 10:56:53AM -0400, Hendrik Boom wrote:
> On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote, and hendrik reformatted:

So this is what I did:
> 
> >
> >  If you already have a working cm3 on the system you want to run it on
> 
> Which is what I've got on my two machines, so this is what I'll be 
> trying.
> 
> >     cd scripts/python
> >     ./upgrade.py

It ran for a while, conpiling some Modula 3 stuff and apparently a lot 
of C code (this part seemed to use autoconf tools), and then stopped 
with

cd . && cd libcpp && make  CFLAGS="-g -O2"   MAKE=make  AUTOCONF=: 
AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a 
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
/bin/sh: line 0: cd: libcpp: No such file or directory
"/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile", line 312: 
quake runtime error: exit 1: cd . && cd libcpp && make  CFLAGS="-g -O2"   
MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: 
libcpp.a | tee -a 
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log

--procedure--  -line-  -file---
exec               --  <builtin>
m3cc_Run          312  
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
include_dir       586  
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
                    8  
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/m3make.args

Fatal Error: package build failed
 *** execution of [<function _BuildGlobalFunction at 0x7f298eea9050>, 
<function _ShipFunction at 0x7f298eea90c8>] failed ***
hendrik at april:~/cm3/src-all/scripts/python$ 


Did I start upgrade.py with an incomplete cm3 system?  Plainly I should 
have started it using script so I'd have a complete log.

-- hendrik


From hendrik at topoi.pooq.com  Wed May 16 18:59:27 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 12:59:27 -0400
Subject: [M3devel] problem building packages -- preliminary analysis.
In-Reply-To: <20120516152635.GA20806@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
Message-ID: <20120516165926.GA3955@topoi.pooq.com>

On Wed, May 16, 2012 at 11:26:35AM -0400, Hendrik Boom wrote:
> On Wed, May 16, 2012 at 10:56:53AM -0400, Hendrik Boom wrote:
> > On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote, and hendrik reformatted:
> 
> So this is what I did:
> > 
> > >
> > >  If you already have a working cm3 on the system you want to run it on
> > 
> > Which is what I've got on my two machines, so this is what I'll be 
> > trying.
> > 
> > >     cd scripts/python
> > >     ./upgrade.py
> 
> It ran for a while, conpiling some Modula 3 stuff and apparently a lot 
> of C code (this part seemed to use autoconf tools), and then stopped 
> with
> 
> cd . && cd libcpp && make  CFLAGS="-g -O2"   MAKE=make  AUTOCONF=: 
> AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a 
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
> /bin/sh: line 0: cd: libcpp: No such file or directory
> "/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile", line 312: 
> quake runtime error: exit 1: cd . && cd libcpp && make  CFLAGS="-g -O2"   
> MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: 
> libcpp.a | tee -a 
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
> 
> --procedure--  -line-  -file---
> exec               --  <builtin>
> m3cc_Run          312  
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
> include_dir       586  
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
>                     8  
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/m3make.args
> 
> Fatal Error: package build failed
>  *** execution of [<function _BuildGlobalFunction at 0x7f298eea9050>, 
> <function _ShipFunction at 0x7f298eea90c8>] failed ***
> hendrik at april:~/cm3/src-all/scripts/python$ 

Looking at the python code in src-all/m3-sys/m3cc/src/m3makefile, I 
find line 586:

m3cc_Run (["cd " & build_dir & " && cd libcpp && " & M3CC_MAKE & " 
libcpp.a | tee -a " & Log])

Now seeng what appears to be the actual command line in the error 
message: 

cd . && cd libcpp && make  CFLAGS="-g -O2" MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a

it appears that the variable bild_dir has the value "."

At some time, "." probably was the build directory.  But at the moment 
we execute this command, I suspect the build dir is actually 
/farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/

since a recent message was 

make[1]: Leaving directory 
`/farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/libdecnumber'

There is no libcpp directory there.  locate tells me there are libcpp 
directories at
src-all/m3-sys/m3cc/gcc-apple/libcpp

and

src-all/m3-sys/m3cc/gcc/libcpp

and that's about it.  (yes, I reran locatedb to make sure it was up to 
date).

Could it be that the build_dir variable should contain an absolute 
rather than a relative path?

Or should I rerun everything using scipt to generate a huge log?

-- hendrik


From jay.krell at cornell.edu  Wed May 16 22:24:52 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 20:24:52 +0000
Subject: [M3devel] problem building packages -- preliminary analysis.
In-Reply-To: <20120516165926.GA3955@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>
Message-ID: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>


Your CVS tree is maybe incomplete or out of date? Try this:
   cd m3-sys   
   rm -rf m3cc  
   cvs -z3 upd -dAP m3cc   
   cd m3cc   
   cm3  
 

Or just checkout a whole new tree.


Yes, there is a lot of C code, that uses autoconf -- the gcc backend.


 - Jay

> Date: Wed, 16 May 2012 12:59:27 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] problem building packages -- preliminary analysis.
> 
> On Wed, May 16, 2012 at 11:26:35AM -0400, Hendrik Boom wrote:
> > On Wed, May 16, 2012 at 10:56:53AM -0400, Hendrik Boom wrote:
> > > On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote, and hendrik reformatted:
> > 
> > So this is what I did:
> > > 
> > > >
> > > >  If you already have a working cm3 on the system you want to run it on
> > > 
> > > Which is what I've got on my two machines, so this is what I'll be 
> > > trying.
> > > 
> > > >     cd scripts/python
> > > >     ./upgrade.py
> > 
> > It ran for a while, conpiling some Modula 3 stuff and apparently a lot 
> > of C code (this part seemed to use autoconf tools), and then stopped 
> > with
> > 
> > cd . && cd libcpp && make  CFLAGS="-g -O2"   MAKE=make  AUTOCONF=: 
> > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a 
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
> > /bin/sh: line 0: cd: libcpp: No such file or directory
> > "/farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile", line 312: 
> > quake runtime error: exit 1: cd . && cd libcpp && make  CFLAGS="-g -O2"   
> > MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: 
> > libcpp.a | tee -a 
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/../AMD64_LINUX/_m3.log
> > 
> > --procedure--  -line-  -file---
> > exec               --  <builtin>
> > m3cc_Run          312  
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
> > include_dir       586  
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/src/m3makefile
> >                     8  
> > /farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/m3make.args
> > 
> > Fatal Error: package build failed
> >  *** execution of [<function _BuildGlobalFunction at 0x7f298eea9050>, 
> > <function _ShipFunction at 0x7f298eea90c8>] failed ***
> > hendrik at april:~/cm3/src-all/scripts/python$ 
> 
> Looking at the python code in src-all/m3-sys/m3cc/src/m3makefile, I 
> find line 586:
> 
> m3cc_Run (["cd " & build_dir & " && cd libcpp && " & M3CC_MAKE & " 
> libcpp.a | tee -a " & Log])
> 
> Now seeng what appears to be the actual command line in the error 
> message: 
> 
> cd . && cd libcpp && make  CFLAGS="-g -O2" MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a
> 
> it appears that the variable bild_dir has the value "."
> 
> At some time, "." probably was the build directory.  But at the moment 
> we execute this command, I suspect the build dir is actually 
> /farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/
> 
> since a recent message was 
> 
> make[1]: Leaving directory 
> `/farhome/hendrik/cm3/src-all/m3-sys/m3cc/AMD64_LINUX/libdecnumber'
> 
> There is no libcpp directory there.  locate tells me there are libcpp 
> directories at
> src-all/m3-sys/m3cc/gcc-apple/libcpp
> 
> and
> 
> src-all/m3-sys/m3cc/gcc/libcpp
> 
> and that's about it.  (yes, I reran locatedb to make sure it was up to 
> date).
> 
> Could it be that the build_dir variable should contain an absolute 
> rather than a relative path?
> 
> Or should I rerun everything using scipt to generate a huge log?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/7dd134ed/attachment-0002.html>

From jay.krell at cornell.edu  Wed May 16 22:40:51 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 20:40:51 +0000
Subject: [M3devel] Building packages
In-Reply-To: <20120516145653.GA19959@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>
Message-ID: <COL101-W2557FFC4969C25FB708C06E6180@phx.gbl>


[inline, maybe to myself in places out of ambiguity]


> So any cm3 system is capable of creating a bootstrap archive for any other cm3 system


 Yes. Except you need Cygwin on NT to cross to non-NT.


> > That should give you a working cm3 for the new system.
> 
> just the compiler (and what it needs to work), presumably.


Yes. But not the backend. Ok.
That gets built later on the target system.

 
  > >      rm -rf /usr/local/cm3 
  >  
  > clearing out any old cm3 system completely 


 Correct. Or pick another location. 


> >      mkdir -p /usr/local/cm3/bin
> >      cp cm3 /usr/local/cm3/bin
> 
> And putting the noew one where it can be executed.


Correct. Or pick another location.


> >      exit
> >      PATH=/usr/local/cm3/bin:$PATH
> 
> And this then builds everything, and makes a .deb
> 
> > cd to scripts/python in the source tree on the new system.
> > Then run ./boot2.sh
> > Then ./make-dist.py.
> > That should give you the entire system newly built, and a .deb.
> 
> I recal there are a few place in the Modula 3 build p[rocess where it 
> requires other resources to already exit (the data base stuff is one I 
> recall).  If they are not available, will the process fail, or will if 
> just build an incomplete .deb?



Good point. In the scripts directory, you can always safely remove PKGSDB
and it will be recreated. It goes out of date occasionally. I've been meaning
to make that automatic by putting a version and/or date in it or such.


> >
> >  If you already have a working cm3 on the system you want to run it on
> 
> Which is what I've got on my two machines, so this is what I'll be 
> trying.
> 
> >     cd scripts/python
> >     ./upgrade.py
> 
> this script recompiles everything from the complete source tree?


I think so. It might only build the compiler.
There is ./do-cm3-all.py if unsure.


> Does it ship it?


Yes

.
 >  Is it important  for the already working cm3 compiler to be the same version as the one 
 > in the source tree being packaged?


 Definitely not. This is how we upgrade from old to new. Or possibly new to told.


 >  And is there also a source package built?


 No. It would be C code anyway, so not source from most people's point of view.

 
> Because the source package is what's needed for uploading to 
> Debian.


They wouldn't like it anyway.
 What do they do with stuff written in Haskell, C#, etc.?


> 
> >     ./make-dist.py
> 
> And this packages it from the shipped location?


I think it builds it from scratch. Read it?


> That is. apparently, deliberate policy.  Linux aims for source-code 
> compatibility.


Very lame.


> I wonder how gcc does its bootstrap.


Right, relevant question.


> Such products try to have very few library dependencies.


As do we..but we do have optional GUI..


> And that's been one of the major problems Microsoft has had with 


It is not that difficult and it is worth it.
The Linux/BSD folks break things seemingly gratuitously.


> compatibility hacks like making the details of the storage 
> allocation system calls depend on the name of the application 
> being executed.


It doesn't work quite that way.
There is an appcompat database that checks things like name and version and yes changes the heap allocator.
Just recompiling the relevant buggy third party code wouldn't make it work either.
There is code out there that uses freed memory or uses memory past the allocation or double frees (same as using freed memory)
Heap implementations are always necessarily at least somewhat lenient, and then once you
are lenient a certain amount or in a certain way, you are stuck.


This isn't source compatibility. It is overly precise behavioral compatibility the likes of which very few
programmers would advocate, but which is necessary in a system with so many applications.


There are security aspects too, like if the stack should be executable.
Again though, this is precise behavior compatibility. Just recompiling the code wouldn't fix it.


> It also enables and encourages third-party developers to distribute 
> application in binary only, making source code inavailable.  And that in 
> turn makes it necessary to remain long-term compatible with ancient 
> bugs.


The bugs are in the third party code and you'd have to change a lot of third party source
to keep it working..


The trade off is a more active (at least historically) third party software market.


Anyway, please try out the various scripts until you get it working.
Then we can document it and make it better.
Perhaps the goal should ship only bootstrap packages for the next release?
Make everyone here experience them and approve them?
Autoconf-ize them a bit?
Or verify they work well enough and worry about it if they ever stop working?
(Autoconf is sometimes overkill.)



It'd be nice if the assembly code wasn't e.g. Linux-specific but only x86-specific.
We could maybe blow up the jmpbuf size per-architectures instead of per architecture+kernel?
Maybe.




 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/6eb0b9b9/attachment-0002.html>

From jay.krell at cornell.edu  Wed May 16 22:55:20 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 20:55:20 +0000
Subject: [M3devel] distribution format?
Message-ID: <COL101-W2222C4AA8CB67F3F46D9E2E6180@phx.gbl>


What distribution format or formats should we aim for?


One thing to consider, in our various preferences for a source/assembly distribution,
is that there is the large gcc backend.


How many people, even if they build stuff from source, build gcc?
How many of those attempts are deemed onerously slow? Or fail and onerous to debug? etc.
And people give up?
Consider that OpenBSD discourages its users from building from source.
Instead they provide binary packages for "everything".


Yes yes a C-generating backend would fix that and merely require the user have gcc or such.
Is the middle step worthwhile?


Is a gcc plugin viable at this point?
I'm not too interested in that really.


Maybe the answer is to "get into" the distributions, into the package systems.
Put rebuild work on the distributions?
They do handle gcc already, somehow, e.g. via a cross into a new/empty file system, presumably.
Can anyone else research that?


Thank you,
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/b220efce/attachment-0002.html>

From hendrik at topoi.pooq.com  Wed May 16 23:07:06 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 17:07:06 -0400
Subject: [M3devel] Package dependencies.
In-Reply-To: <COL101-W2557FFC4969C25FB708C06E6180@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<COL101-W2557FFC4969C25FB708C06E6180@phx.gbl>
Message-ID: <20120516210706.GA8654@topoi.pooq.com>

On Wed, May 16, 2012 at 08:40:51PM +0000, Jay K wrote:
> 
>  >  And is there also a source package built?
> 
> 
>  No. It would be C code anyway, so not source from most 
> people's point of view.
> 
>  
> > Because the source package is what's needed for uploading to 
> > Debian.
> 
> 
> They wouldn't like it anyway.
>  What do they do with stuff written in Haskell, C#, etc.?
> 

They'd be happy with it provided they have Haskel, C#, etc. 
implementations already in the system.  A Debian package 
can have build-dependencies, which is other packages that 
have to be installed to builld it.  I don't know how this works 
with bootstrapping self-hosting languages.  Maybe it takes 
ad-hockery.  Maybe a new release build-depends on the 
previous one.  Or on anything aat least as up-to-date as 
the previous one.

-- hendrik



From hendrik at topoi.pooq.com  Wed May 16 23:15:26 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 17:15:26 -0400
Subject: [M3devel] building packages
In-Reply-To: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
Message-ID: <20120516211526.GB8654@topoi.pooq.com>

On Wed, May 16, 2012 at 08:24:52PM +0000, Jay K wrote:
> 
> Your CVS tree is maybe incomplete or out of date? Try this:
>    cd m3-sys   
>    rm -rf m3cc  
>    cvs -z3 upd -dAP m3cc   
>    cd m3cc   
>    cm3  

I wsn't using the CVS tree.  I was using 
cm3-src-all-5.8.6-REL.tgz, downloaded from 
http://modula3.elegosoft.com/cm3/releng/download.html.

Maybe your instructions apply only to a still-newer source 
tree.

>  
> 
> Or just checkout a whole new tree.

That's what I'll do.  Is the current head in good 
enough shape?

> 
> 
> Yes, there is a lot of C code, that uses autoconf -- the gcc backend.

So you compile the gcc backend.  Presumably cross-compile 
it if necessary.  Does gcc on one platform also produce 
object code for another?  Or does the script custom-pick 
the backend depending on the target platform?

-- hendrik

> 
> 
>  - Jay
> 


From hendrik at topoi.pooq.com  Wed May 16 23:28:59 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 17:28:59 -0400
Subject: [M3devel] distribution format?
In-Reply-To: <COL101-W2222C4AA8CB67F3F46D9E2E6180@phx.gbl>
References: <COL101-W2222C4AA8CB67F3F46D9E2E6180@phx.gbl>
Message-ID: <20120516212859.GD8654@topoi.pooq.com>

On Wed, May 16, 2012 at 08:55:20PM +0000, Jay K wrote:
> 
> What distribution format or formats should we aim for?
> 
> 
> One thing to consider, in our various preferences for a source/assembly distribution,
> is that there is the large gcc backend.
> 
> 
> How many people, even if they build stuff from source, build gcc?
> How many of those attempts are deemed onerously slow? Or fail and onerous to debug? etc.
> And people give up?
> Consider that OpenBSD discourages its users from building from source.
> Instead they provide binary packages for "everything".
> 
> 
> Yes yes a C-generating backend would fix that and merely require the user have gcc or such.
> Is the middle step worthwhile?
> 
> 
> Is a gcc plugin viable at this point?
> I'm not too interested in that really.
> 
> 
> Maybe the answer is to "get into" the distributions, into the package systems.
> Put rebuild work on the distributions?
> They do handle gcc already, somehow, e.g. via a cross into a new/empty file system, presumably.
> Can anyone else research that?

gentoo has a minimal binary distribution and they use that 
to build everything else, possibly including a newer gcc.  
But then gentoo is for the fanatics that want to build 
everything themselves from source code.

I've recently read through the Debian packaging tutorial, 
enough to make my eyes glaze over.  I'll have another look 
to see if I manage to understand anything relevant.

-- hendrik

> 
> Thank you,
>  - Jay

You're welcome!

-- hendrik


From hendrik at topoi.pooq.com  Thu May 17 00:31:23 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 18:31:23 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
Message-ID: <20120516223123.GA25611@topoi.pooq.com>

On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote:
> 
> You might as well just use something in scripts to rebuild the entire system.It isn't so difficult nor takes very long.     Get a working cm3 on any system.
      cd scripts/python
      ./boot1.py <target-such-as-I386_LINUX>

Is I386_LINUX no longer called LINUXLIBC6?

-- hendrik


From jay.krell at cornell.edu  Thu May 17 01:40:53 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 23:40:53 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <20120516223123.GA25611@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516223123.GA25611@topoi.pooq.com>
Message-ID: <COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>


 LINUXLIBC6 is supported, but I'd really like to drop it.  The following are supported and work: 
   I386_NT    I386_CYGWIN    I386_NETBSD    I386_FREEBSD    I386_LINUX    SPARC32_SOLARIS ?   The following I'd like to get rid of, but they are pretty cheap to carry along:   NetBSDi386 or somesuch     FreeBSD4      LINUXLIBC6       SOLgnu      SOLsun     You can cross build from any to any, and then leave the old stuff behind...     But heck, really, if we generate C, then targets largely drop away.    Not entirely, not without other changes.     cm3 knows very very little about any targets, mainly their word size, endianness, and jmpbuf size.     jmpbuf size is high on my list to remove. I had it almost fixed, but not quite right.     Target dependencies are mostly in other places:     1) quake code        2) #ifdef C       3) the gcc backend       The quake code and #ifdefed C can largely be merged into just #ifdefed C, and thatlargely goes away if/when we have preemptive suspend.Ok ok, that's only for garbage collection. File I/O and GUI are still forked Win32 vs. Posix,and always will be in Trestle. Maybe we'll layer over Qt or such someday...  In the present structuring there is also some need/want for "user threads" targets:  I386_LINUX    I386_LINUX_USERTHREADS    but I'd rather make that a compile/link/runtime option instead.Currently anyone needing/wanting userthreads gets to recompile the world.   - Jay
 > Date: Wed, 16 May 2012 18:31:23 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] LINUXLIBC6
> 
> On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote:
> > 
> > You might as well just use something in scripts to rebuild the entire system.It isn't so difficult nor takes very long.     Get a working cm3 on any system.
>       cd scripts/python
>       ./boot1.py <target-such-as-I386_LINUX>
> 
> Is I386_LINUX no longer called LINUXLIBC6?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/10efe6f3/attachment-0002.html>

From hendrik at topoi.pooq.com  Thu May 17 01:55:49 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 19:55:49 -0400
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <20120516211526.GB8654@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
Message-ID: <20120516235549.GB3955@topoi.pooq.com>

On Wed, May 16, 2012 at 05:15:26PM -0400, Hendrik Boom wrote:
> On Wed, May 16, 2012 at 08:24:52PM +0000, Jay K wrote:
> > 
> > Your CVS tree is maybe incomplete or out of date? Try this:
> >    cd m3-sys   
> >    rm -rf m3cc  
> >    cvs -z3 upd -dAP m3cc   
> >    cd m3cc   
> >    cm3  
> 
> I wsn't using the CVS tree.  I was using 
> cm3-src-all-5.8.6-REL.tgz, downloaded from 
> http://modula3.elegosoft.com/cm3/releng/download.html.
> 
> Maybe your instructions apply only to a still-newer source 
> tree.
> 
> >  
> > 
> > Or just checkout a whole new tree.
> 
> That's what I'll do.  Is the current head in good 
> enough shape?

Just checked out a whole new source tree.

cd scripts/python
./upgrade.py

and got 1504 lines of messages (yes, I saved them this time) ending with:

configure: creating ./config.status
config.status: creating Makefile
cd . && make  MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: c
onfigure-host
cd . && make  MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host
mkdir -p -- ./gcc
Configuring in ./gcc
configure: creating cache ./config.cache
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking LIBRARY_PATH variable... contains current directory
configure: error: 
*** LIBRARY_PATH shouldn't contain the current directory when
*** building gcc. Please change the environment variable
*** and run configure again.
make: *** [configure-gcc] Error 1
"/farhome/hendrik/cm3/cm3/m3-sys/m3cc/src/m3makefile", line 281: quake runtime error: exit 2: cd . && make  MAKE=make  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host

--procedure--  -line-  -file---
exec               --  <builtin>
m3cc_Run          281  /farhome/hendrik/cm3/cm3/m3-sys/m3cc/src/m3makefile
include_dir       475  /farhome/hendrik/cm3/cm3/m3-sys/m3cc/src/m3makefile
                    5  /farhome/hendrik/cm3/cm3/m3-sys/m3cc/AMD64_LINUX/m3make.args

Fatal Error: package build failed
 *** execution of [<function _BuildGlobalFunction at 0x7f70063d6848>, <function _ShipFunction at 0x7f70063d68c0>] failed ***
hendrik at april:~/cm3/cm3/scripts/python$ 


I'm not out of the woods yet.

By the way, the LIBRARY_PATH in the shell from which I ran upgrade.py
was 

hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH
:/usr/local/Gambit-C/lib
hendrik at april:~/cm3/cm3/scripts/python$ 

and seems to have nothing to do with anything, 
so I'll have to investigate further.

-- hendrik


From jay.krell at cornell.edu  Thu May 17 01:58:15 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 23:58:15 +0000
Subject: [M3devel] building packages
In-Reply-To: <20120516211526.GB8654@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>
Message-ID: <COL101-W3674E59BA09B552B45BAE4E6180@phx.gbl>


  > From: hendrik at topoi.pooq.com     > I wasn't using the CVS tree. I was using   
  > cm3-src-all-5.8.6-REL.tgz, downloaded from   
  
 cm3-src-all-5.8.6-REL.tgz really ought to work.     
 But I don't know.    
 I can try later.   
 
  
  
  > That's what I'll do. Is the current head in good   
  > enough shape?     I think so, but please try it, and we'll see.    
  I've actively using it lately (working on moving to gcc 4.6, making good progress)      
 
  > So you compile the gcc backend. Presumably cross-compile   
  > it if necessary. Does gcc on one platform also produce   
  > object code for another? Or does the script custom-pick   
  > the backend depending on the target platform?  
It works. Trust me. Try it.   Details:
 
  if you read m3cc/src/m3makefile, you see that "build_dir" is either "." or "../<host>-<target>"      "." is really host or target -- the same thing, for a native build.    cm3 automatically creates and cd's into it, rending it as just ".".     We configure gcc appropriately (--host, --target) and run the cm3cg by full path, as I recall.     We aren't cross-compiling gcc. We are building a cross-compiler.  
  The following is confusing, but makes sense once you get your head around it:  
  There are potentially up to 3 machines: "build", "host", "target".  
  "build" is the machine you are sitting on "now". The one you are building the compiler on.  
  The machine you are building the compiler on.    
  "host" is the machine that the resulting compiler will run on. It will "host" the compiler.    
  "target" is the machine that will run the compiler's output -- that the compiler will "target".       In common practise, all 3 are the same and things are nice and simple.  
    
  But it can be that any two of three are the same or that all three are the same.
    In the context of the Modula-3 build scripts, build and host are always the same.    
  
  When host and target are different, that is a cross compiler.
  When build and host are different, you are cross compiling the compiler.    
  When all three are different, you are cross compiling a cross compiler.  
  When build and target are the same but not equal to host, I don't know a term for that, I call it "cross back" -- you are     building a compiler that will run on a different system but which will produce code for the system you are building it on.  
  
     
  The challenge in various "cross " scenarios is having/getting the headers and libraries (libc) and linker and assembler,   
  and related, building libgcc2.   
  Often-times but not always, the GNU linker/assembler help.    
  Sometimes GNU libc helps.    
  But I for example haven't been able to build an ia64-linux toolset, due to the headers/libraries.  
  
  Building the C frontend/backend (and gcc driver for that matter) for build==host is actually always very easy.  
 
  
  If you program is just:
  int add(int a, int b) { return a + b }        and you have gcc source, it is easy to convert it to assembly for any target,
  without any headers/libraries/linker/assembler. That is all Modula-3 uses gcc for.    
  But throw in an #include <stdio.h> or try to link to anything, and you need a lot more.      In the Modula-3 system, how it was mostly structured at the start, and now, we cheat.  
  "final compilation/assembly/linking" can be deferred to the target system, which is  
  dependend upon to have a working native toolset. That is what my "bootstrap" archives do.
  That is what the "bootstrap" archives of olden times (circa 3.6/1996) did I believe. 
  Also quake was written in C back then.   
  Targeting something like iPhone/iPad doesn't fit...except that C cross tools are available  
  enough, so the same structuring works fine.  
  You typically just have to run different toplevel gcc/ld or add a switch like gcc -arch arm.      We also cheat these days in that where #include <stdio.h> (for C runtime/kernel) was needed, I rewrote the code in C.    This protects us from stdio.h changing or varying per-target. It was a big porting and maintenance and safety problem.    <windows.h> and <Xlib.h> we still clone in Modula-3. They don't change so much. But maybe we should    do something different there too.  
   Make some sense?      - Jay   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/b84cf658/attachment-0002.html>

From jay.krell at cornell.edu  Thu May 17 01:59:51 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 May 2012 23:59:51 +0000
Subject: [M3devel] distribution format?
In-Reply-To: <20120516212859.GD8654@topoi.pooq.com>
References: <COL101-W2222C4AA8CB67F3F46D9E2E6180@phx.gbl>,
	<20120516212859.GD8654@topoi.pooq.com>
Message-ID: <COL101-W23A02FD30BF2BCE47AEB94E6180@phx.gbl>


Agreed both: I haven't gotten Gentoo to work, despit trying. Debian developer manual is a lot to read.  - Jay
 > Date: Wed, 16 May 2012 17:28:59 -0400
> From: hendrik at topoi.pooq.com
> 
> gentoo has a minimal binary distribution and they use that 
> to build everything else, possibly including a newer gcc.  
> But then gentoo is for the fanatics that want to build 
> everything themselves from source code.
> 
> I've recently read through the Debian packaging tutorial, 
> enough to make my eyes glaze over.  I'll have another look 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/a21e5127/attachment-0002.html>

From jay.krell at cornell.edu  Thu May 17 02:03:23 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 00:03:23 +0000
Subject: [M3devel] Package dependencies.
In-Reply-To: <20120516210706.GA8654@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<COL101-W2557FFC4969C25FB708C06E6180@phx.gbl>,
	<20120516210706.GA8654@topoi.pooq.com>
Message-ID: <COL101-W17DBAC2F81606B73A0A39CE6190@phx.gbl>


 >> I don't know how this works with bootstrapping self-hosting languages    I think you hit the nail on the head -- "bootstrapping self-hosting languages". Good!    Keep using that phrase if you email folks asking about this, and make sure they understand it.         Meanwhile, I still want to generate fairly portable C or C++ to get around the problem. :)        First I'm going to upgrade to gcc 4.6 backend, and then maybe 4.7..stalling... :)         >  What do they do with stuff written in Haskell, C#, etc.?  
   > They'd be happy with it provided they have Haskel, C#, etc.     
 Right: I should have said a C# compiler written in C#, a Haskell compiler written in Haskell, etc.   - Jay
 > Date: Wed, 16 May 2012 17:07:06 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Package dependencies.
> 
> On Wed, May 16, 2012 at 08:40:51PM +0000, Jay K wrote:
> > 
> >  >  And is there also a source package built?
> > 
> > 
> >  No. It would be C code anyway, so not source from most 
> > people's point of view.
> > 
> >  
> > > Because the source package is what's needed for uploading to 
> > > Debian.
> > 
> > 
> > They wouldn't like it anyway.
> >  What do they do with stuff written in Haskell, C#, etc.?
> > 
> 
> They'd be happy with it provided they have Haskel, C#, etc. 
> implementations already in the system.  A Debian package 
> can have build-dependencies, which is other packages that 
> have to be installed to builld it.  I don't know how this works 
> with bootstrapping self-hosting languages.  Maybe it takes 
> ad-hockery.  Maybe a new release build-depends on the 
> previous one.  Or on anything aat least as up-to-date as 
> the previous one.
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/7a8daeed/attachment-0002.html>

From jay.krell at cornell.edu  Thu May 17 02:06:00 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 00:06:00 +0000
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <20120516235549.GB3955@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>
Message-ID: <COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>


     > *** LIBRARY_PATH shouldn't contain the current directory when  
     > *** building gcc. Please change the environment variable  
     > *** and run configure again.  
    hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
  :/usr/local/Gambit-C/lib  
 Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/d863e4e0/attachment-0002.html>

From hendrik at topoi.pooq.com  Thu May 17 02:48:25 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 20:48:25 -0400
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
Message-ID: <20120517004825.GA30435@topoi.pooq.com>

On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> 
>      > *** LIBRARY_PATH shouldn't contain the current directory when  
>      > *** building gcc. Please change the environment variable  
>      > *** and run configure again.  
>     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
>   :/usr/local/Gambit-C/lib  
>  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  

Interesting.  I thought you had to say . to get the current directory, and that the 
empty string meant nothing at all.  Evidently the  standard way of appending something 
to LIBRARY_PATH has a bug in the empty case.  Strings aren't the best way of doing lots 
of things, but they're ubiquitous, are oftern the only thing available, and lead to bugs 
like this.

-- hendrik




From jay.krell at cornell.edu  Thu May 17 02:59:31 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 00:59:31 +0000
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <20120517004825.GA30435@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>,
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>,
	<20120517004825.GA30435@topoi.pooq.com>
Message-ID: <COL101-W28EDF0AAE2AE13133B4948E6190@phx.gbl>


 > From: hendrik at topoi.pooq.com 
 > Strings aren't the best way of doing lots  
 > of things, but they're ubiquitous, are oftern the only thing available, and lead to bugs  
 Definitely.  A classic example is the command line, for various reasons.On Windows for example, the lower layers pass the command line as one flat string.So then it has to be split up to form argv. On spaces. Which have to be quoted if they are in individual elements. But quotes can occur too. Mess. Even on Unix where the kernel accepts an array, it doesn't work well, like if you are passing any "special" characters, at least if there is an intervening /bin/sh. There are length limits, at least on Windows, so compilers/linkers accept their commands in files as well, and long command lines are stuffed into files.  Strongly typed function calls work much better.Over RPC if necessary.  URLs have similar problems.  I see problems caused by this stuff pretty frequently..   - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/a78ddb09/attachment-0002.html>

From hendrik at topoi.pooq.com  Thu May 17 03:49:03 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 21:49:03 -0400
Subject: [M3devel] building packages from source from cvs
In-Reply-To: <COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
Message-ID: <20120517014903.GA19546@topoi.pooq.com>

On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> 
>      > *** LIBRARY_PATH shouldn't contain the current directory when  
>      > *** building gcc. Please change the environment variable  
>      > *** and run configure again.  
>     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
>   :/usr/local/Gambit-C/lib  
>  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  

Yes, emptying LIBRARY_PATH enabled uprade.py to complete successfully.
Thanks.  It would have taken me many ages to figure this out.

-- hendrik



From dabenavidesd at yahoo.es  Thu May 17 03:58:50 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 17 May 2012 02:58:50 +0100 (BST)
Subject: [M3devel] Package dependencies.
In-Reply-To: <COL101-W17DBAC2F81606B73A0A39CE6190@phx.gbl>
Message-ID: <1337219930.11755.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
correct but since 70's anybody could use a CG machine to reproduce the language in any environment and then port it from there to any other machine of similar characteristics.
I think most of M3CG was inspired by Titan RISC DEC chip, but it came first by an effort to emulate the VAX on a RISC and if Modula-3 ever succeeded by running a VAX instruction it doesn't need to be such, so don't raise a concern on the language it was born and so, but in the language it had to be arise in.
That said, Modula-3 or anything is much compact in a RISC machine than in any other CISC-like machine, which is for what C was created in first place as Macro-package then used as a Programming language on its own. Modula-3 was a ready Programming environment for the VAX native back-end for a RISC. This was an? environment in for which you could see the benefits of a good small language enough powerful to run a native system in and so.
Thanks in advance


?

--- El mi?, 16/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Package dependencies.
Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 16 de mayo, 2012 19:03




?>> I don't know how this works with bootstrapping self-hosting languages
?
?
? I think you hit the nail on the?head -- "bootstrapping self-hosting languages". Good!? 
? Keep using that phrase if you email folks asking?about this, and make sure they understand it.? 
?
?
??? ?Meanwhile, I still want to generate fairly portable C or C++ to get around the problem. :)?? 
??? ?First I'm going to upgrade to gcc 4.6 backend, and then maybe 4.7..stalling... :)??? 
?
?
? ?>  What do they do with stuff written in Haskell, C#, etc.?? 
? ?> They'd be happy with it provided they have Haskel, C#, etc.???? 

?
Right: I should have said a C# compiler written in C#, a Haskell compiler written in Haskell, etc.
?
?
?- Jay
?
> Date: Wed, 16 May 2012 17:07:06 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Package dependencies.
> 
> On Wed, May 16, 2012 at 08:40:51PM +0000, Jay K wrote:
> > 
> >  >  And is there also a source package built?
> > 
> > 
> >  No. It would be C code anyway, so not source from most 
> > people's point of view.
> > 
> >  
> > > Because the source package is what's needed for uploading to 
> > > Debian.
> > 
> > 
> > They wouldn't like it anyway.
> >  What do they do with stuff written in Haskell, C#, etc.?
> > 
> 
> They'd be happy with it provided they have Haskel, C#, etc. 
> implementations already in the system.  A Debian package 
> can have build-dependencies, which is other packages that 
> have to be installed to builld it.  I don't know how this works 
> with bootstrapping self-hosting languages.  Maybe it takes 
> ad-hockery.  Maybe a new release build-depends on the 
> previous one.  Or on anything aat least as up-to-date as 
> the previous one.
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/cb176be8/attachment-0002.html>

From hendrik at topoi.pooq.com  Thu May 17 04:35:33 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 16 May 2012 22:35:33 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517014903.GA19546@topoi.pooq.com>
References: <20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
Message-ID: <20120517023533.GB19546@topoi.pooq.com>

On Wed, May 16, 2012 at 09:49:03PM -0400, Hendrik Boom wrote:
> On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> > 
> >      > *** LIBRARY_PATH shouldn't contain the current directory when  
> >      > *** building gcc. Please change the environment variable  
> >      > *** and run configure again.  
> >     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
> >   :/usr/local/Gambit-C/lib  
> >  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  
> 
> Yes, emptying LIBRARY_PATH enabled uprade.py to complete successfully.
> Thanks.  It would have taken me many ages to figure this out.
> 
> -- hendrik
> 
Now I'm onto ./make-dist.py

It fails in teh data base stuff.

First becaues it didn't have libodbc.  So I installed package unixodbc.
But then:

== package /farhome/hendrik/cm3/cm3/m3-db/odbc ==

 +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3    -build -DROOT=/farhome/hendrik/cm3/cm3 +++
--- building in AMD64_LINUX ---

ignoring ../src/m3overrides

 ==> /farhome/hendrik/cm3/cm3/m3-db/odbc done

 +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3  -ship -DROOT=/farhome/hendrik/cm3/cm3 +++
--- shipping from AMD64_LINUX ---

. => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
  .M3EXPORTS      
. => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib
  libm3odbc.so.5  "/farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP", line 4: quake runtime error: unable to copy "libm3odbc.so.5" to "/tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib/libm3odbc.so.5": errno=2

--procedure--  -line-  -file---
install_file       --  <builtin>
                    4  /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP

Fatal Error: package build failed
 *** execution of [<function _BuildGlobalFunction at 0x1a56de8>, <function _ShipFunction at 0x1a56c80>] failed ***
hendrik at april:~/cm3/cm3/scripts/python$ 


It doesn't seem to build libm3odbc.so.5

hendrik at april:~/cm3/cm3/m3-db/odbc$ ls AMD64_LINUX/
libm3odbc.a    libm3odbc.so  SQLext.mo  SQLtypes.io
libm3odbc.m3x  SQLext.io     SQL.io
hendrik at april:~/cm3/cm3/m3-db/odbc$ 

There's nothing at all in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
There are lots of files in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib,
but nothing resembling libm3odbc>

-- hendrik




From jay.krell at cornell.edu  Thu May 17 08:01:19 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 06:01:19 +0000
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517023533.GB19546@topoi.pooq.com>
References: <20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516145653.GA19959@topoi.pooq.com>,
	<20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>,
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>,
	<20120517014903.GA19546@topoi.pooq.com>,
	<20120517023533.GB19546@topoi.pooq.com>
Message-ID: <COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>


Good.
Wasn't the error message from configure obvious though?


Anyway:
  I think there's a "minor" incrementality bug here.   
  Incremental build isn't picking back up where it left off/failed.  

Try this:
   rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
   rm -rf /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516 
   ./make-dist.py  


OR:  
   rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
   Look at make-dist.py/pylib.py -- get it to point at the same output as before and then just:  
  ./make-dist.py 



That is -- I think every run of make-dist.py is clean to a new temporary timestamp-based location.
This is good and bad.


Note also, I think it is obvious, but I wrote make-dist.py to always package up everything possible
for the target platform. So it is up to you as the "builder" to have all the dependencies already installed.
It isn't great.
I don't believe there is a perfect option here.
Another release form we have yields a bunch of per-target packages.
I find that confusing -- too many.
My form yields just one largeish per-target package.
Over-size, monolithic, but simpler, less choices to confuse people.


Of course ultimately we don't want per-target stuff at all. :)
Or at least we want both "source" and "binary" distributions.


Still I am confused.
Don't people have binary distributions of programs with GUIs for Linux?
Like Komodo IDE, Komodo Edit, Acrobat Reader?


Maybe we should really have a java-generating backend...one binary distribution for all..and a better Android story?
I know, there is a funny tradeoff here. Modula-3 is kind of lower-level than Java.
You'd want such a backend/port to throw out our garbage collector..and heck..all unsafe code....
 (or generate C for those and use JNI or such...interesting..theoretically possible..unlikely to happen..)


 - Jay


> Date: Wed, 16 May 2012 22:35:33 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] building packages from source from cvs -- odbc
> 
> On Wed, May 16, 2012 at 09:49:03PM -0400, Hendrik Boom wrote:
> > On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> > > 
> > >      > *** LIBRARY_PATH shouldn't contain the current directory when  
> > >      > *** building gcc. Please change the environment variable  
> > >      > *** and run configure again.  
> > >     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
> > >   :/usr/local/Gambit-C/lib  
> > >  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  
> > 
> > Yes, emptying LIBRARY_PATH enabled uprade.py to complete successfully.
> > Thanks.  It would have taken me many ages to figure this out.
> > 
> > -- hendrik
> > 
> Now I'm onto ./make-dist.py
> 
> It fails in teh data base stuff.
> 
> First becaues it didn't have libodbc.  So I installed package unixodbc.
> But then:
> 
> == package /farhome/hendrik/cm3/cm3/m3-db/odbc ==
> 
>  +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3    -build -DROOT=/farhome/hendrik/cm3/cm3 +++
> --- building in AMD64_LINUX ---
> 
> ignoring ../src/m3overrides
> 
>  ==> /farhome/hendrik/cm3/cm3/m3-db/odbc done
> 
>  +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3  -ship -DROOT=/farhome/hendrik/cm3/cm3 +++
> --- shipping from AMD64_LINUX ---
> 
> . => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
>   .M3EXPORTS      
> . => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib
>   libm3odbc.so.5  "/farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP", line 4: quake runtime error: unable to copy "libm3odbc.so.5" to "/tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib/libm3odbc.so.5": errno=2
> 
> --procedure--  -line-  -file---
> install_file       --  <builtin>
>                     4  /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP
> 
> Fatal Error: package build failed
>  *** execution of [<function _BuildGlobalFunction at 0x1a56de8>, <function _ShipFunction at 0x1a56c80>] failed ***
> hendrik at april:~/cm3/cm3/scripts/python$ 
> 
> 
> It doesn't seem to build libm3odbc.so.5
> 
> hendrik at april:~/cm3/cm3/m3-db/odbc$ ls AMD64_LINUX/
> libm3odbc.a    libm3odbc.so  SQLext.mo  SQLtypes.io
> libm3odbc.m3x  SQLext.io     SQL.io
> hendrik at april:~/cm3/cm3/m3-db/odbc$ 
> 
> There's nothing at all in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> There are lots of files in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib,
> but nothing resembling libm3odbc>
> 
> -- hendrik
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/e2bd275d/attachment-0002.html>

From jay.krell at cornell.edu  Thu May 17 08:10:40 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 06:10:40 +0000
Subject: [M3devel] C99 FloatMode stuff
Message-ID: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl>


Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/de246aa3/attachment-0002.html>

From hendrik at topoi.pooq.com  Thu May 17 17:48:37 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 17 May 2012 11:48:37 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
References: <20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
Message-ID: <20120517154836.GA20605@topoi.pooq.com>

On Thu, May 17, 2012 at 06:01:19AM +0000, Jay K wrote:
> 
> Good.
> Wasn't the error message from configure obvious though?

Evidently not.  Or I was too much asleep last night.  Or I didn't get 
one. I'm looking for one now.  I find none in my most recent script 
output.  In one of the old ones I find

checking for modern makeinfo... no
configure: WARNING:
*** Makeinfo is missing or too old.
*** Info documentation will not be built.
checking for recent Pod::Man... yes

but I suspect that may be irrelevant.  Unless packageing fails later 
because it tries to package the info docs, which I hate anyway.

No, I don't find any messages.  But then, I'm simply using my old, 
working cm3 compiler as a bootstrap to build the whole system for the 
same machine.  I didn't have a specific 'configure' step.

I found a bunch of compilation warnings about
* labels and other names  being defined but not used.
* comparisons always false due to limited range of data type
* invalid conversion type characters.  Might these actually cause 
run-time failures?
* right-hand operand of comma has no effect

These are unlikely to be the problems I'm contending with, but might 
it be worth going through the entire build sometime and tracking 
then all down?  Grepping my script output for "warning" would 
probably find them all.


> 
> 
> Anyway:
>   I think there's a "minor" incrementality bug here.   
>   Incremental build isn't picking back up where it left off/failed.  
> 
> Try this:
>    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
>    rm -rf /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516 
>    ./make-dist.py  

Will do.  I had planned to do something like this when I was awake this 
morning, but I was unsure just which files needed to be deleted.

> 
> 
> OR:  
>    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
>    Look at make-dist.py/pylib.py -- get it to point at the same output as before and then just:  
>   ./make-dist.py 
> 
> 
> 
> That is -- I think every run of make-dist.py is clean to a new temporary timestamp-based location.
> This is good and bad.
> 
> 
> Note also, I think it is obvious, but I wrote make-dist.py to always package up everything possible
> for the target platform. So it is up to you as the "builder" to have all the dependencies already installed.
> It isn't great.
> I don't believe there is a perfect option here.
> Another release form we have yields a bunch of per-target packages.

This is the way other languages have gone in Debian.  The main reason 
seems to be to reduce the amount of other packages that have to be installed via 
dependencies that the user might not have any interest in.  Essentially 
a distinction between the language, the applications, and the 
libraries.  Something like what Modula3 does with its tgz'ed 
binary "packages".

> I find that confusing -- too many.
> My form yields just one largeish per-target package.
> Over-size, monolithic, but simpler, less choices to confuse people.
> 
> 
> Of course ultimately we don't want per-target stuff at all. :)
> Or at least we want both "source" and "binary" distributions.
> 
> 
> Still I am confused.
> Don't people have binary distributions of programs with GUIs for Linux?
> Like Komodo IDE, Komodo Edit, Acrobat Reader?
> 
> 
> Maybe we should really have a java-generating backend...one binary distribution for all..and a better Android story?

That could be useful on Android.  But it *is* possible to get package C 
or at least C object code to run on Android.  I think that's the 
approach being used to get Python to run on Android.

> I know, there is a funny tradeoff here. Modula-3 is kind of lower-level than Java.
> You'd want such a backend/port to throw out our garbage collector..and heck..all unsafe code....
>  (or generate C for those and use JNI or such...interesting..theoretically possible..unlikely to happen..)
> 
> 
>  - Jay


From dabenavidesd at yahoo.es  Thu May 17 18:18:52 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 17 May 2012 17:18:52 +0100 (BST)
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl>
Message-ID: <1337271532.47137.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I believe they are in system limits.h aren't they.
BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
Thanks in advance.

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] C99 FloatMode stuff
Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 01:10




Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

?- Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/c995d0eb/attachment-0002.html>

From jay.krell at cornell.edu  Thu May 17 20:46:14 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 18:46:14 +0000
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <1337271532.47137.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl>,
	<1337271532.47137.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <COL101-W4BF60E04E5B4DB1D35477E6190@phx.gbl>


No Daniel. 


Date: Thu, 17 May 2012 17:18:52 +0100
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] C99 FloatMode stuff
To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I believe they are in system limits.h aren't they.
BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
Thanks in advance.

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] C99 FloatMode stuff
Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 01:10




Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

 - Jay
 		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/8b0d5a49/attachment-0002.html>

From hendrik at topoi.pooq.com  Thu May 17 20:57:53 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 17 May 2012 14:57:53 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517154836.GA20605@topoi.pooq.com>
References: <20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
Message-ID: <20120517185753.GA5741@topoi.pooq.com>

On Thu, May 17, 2012 at 11:48:37AM -0400, Hendrik Boom wrote:
> On Thu, May 17, 2012 at 06:01:19AM +0000, Jay K wrote:
> > 
> > Good.
> > Wasn't the error message from configure obvious though?
> 
> Evidently not.  Or I was too much asleep last night.  Or I didn't get 
> one. I'm looking for one now.  I find none in my most recent script 
> output.  In one of the old ones I find
> 
> checking for modern makeinfo... no
> configure: WARNING:
> *** Makeinfo is missing or too old.
> *** Info documentation will not be built.
> checking for recent Pod::Man... yes
> 
> but I suspect that may be irrelevant.  Unless packageing fails later 
> because it tries to package the info docs, which I hate anyway.
> 
> No, I don't find any messages.  But then, I'm simply using my old, 
> working cm3 compiler as a bootstrap to build the whole system for the 
> same machine.  I didn't have a specific 'configure' step.
> 
> I found a bunch of compilation warnings about
> * labels and other names  being defined but not used.
> * comparisons always false due to limited range of data type
> * invalid conversion type characters.  Might these actually cause 
> run-time failures?
> * right-hand operand of comma has no effect
> 
> These are unlikely to be the problems I'm contending with, but might 
> it be worth going through the entire build sometime and tracking 
> then all down?  Grepping my script output for "warning" would 
> probably find them all.
> 
> 
> > 
> > 
> > Anyway:
> >   I think there's a "minor" incrementality bug here.   
> >   Incremental build isn't picking back up where it left off/failed.  
> > 
> > Try this:
> >    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
> >    rm -rf /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516 
> >    ./make-dist.py  
> 
> Will do.  I had planned to do something like this when I was awake this 
> morning, but I was unsure just which files needed to be deleted.
> 

It definitely got past odbc now.  But it stopped within ESC.  I was 
surprised to find it her; I had thought the source code to be long lost.
I don't see am error message except for the failure to find .M3EXPORTS, 
ahich is probably something that cm3 should have generated.

The m3makefile 
/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile
seems to have trouble finding 
/tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/pkg/prover/AMD64_LINUX/.M3EXPORTS
which seems to me to be one level out in the source code.  Just what 
determines the order that these things are to be compiled?  The 
compilation log makes it look as if the outer one (prover) needed to be 
compiled first, so as to enerate the .M3EXPORTS file, but that the inner 
one (prover/test) actually got compiled first. 

Here's the output, starting with the first line of log contianing either 
the words "Simplify" or "prover".


== package /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test ==

 +++ /tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/bin/cm3    
-build -DROOT=/farhome/hendrik/cm3/cm3 +++
--- building in AMD64_LINUX ---

ignoring ../src/m3overrides

"/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile", line 
1: quake runtime error: unable to open 
"/tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/pkg/prover/AMD64_LINUX/.M3EXPORTS" 
for reading

--procedure--  -line-  -file---
import             --  <builtin>
include_dir         1  
/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile
                    5  
/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/AMD64_LINUX/m3make.args

Fatal Error: package build failed
 *** execution of [<function _BuildGlobalFunction at 0x10d0de8>, 
<function _ShipFunction at 0x10d0c80>] failed ***
hendrik at april:~/cm3/cm3/scripts/python$ exit

-- hendrik



From dabenavidesd at yahoo.es  Fri May 18 00:27:25 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 17 May 2012 23:27:25 +0100 (BST)
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <COL101-W4BF60E04E5B4DB1D35477E6190@phx.gbl>
Message-ID: <1337293645.96958.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
if not then either that value doesn't sound as a machine value since the OS must care at least of constant values in memory (you can't allow values larger than what memory supports) or (whichever library they had created) is "their standard" , I don't think C standards are very precise, in fact, they are bad, who needs C standards, who created or thinks knows the standards.
What the argot I would like to see are:
Infinity values, epsilon, and? memory limits under such that limit values holds, that is, you can't represent epsilon with little value of memory.
This would be the jargon of such libraries, instead they just make them a internal operation of their own calculation, which I can't trust, in summary this thing is unsound. Then the interface is UNSAFE for real which can't be a very standard thing by the way.
Thanks in advance

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] C99 FloatMode stuff
Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 13:46




No Daniel. 


Date: Thu, 17 May 2012 17:18:52 +0100
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] C99 FloatMode stuff
To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I believe they are in system limits.h aren't they.
BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
Thanks in advance.

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] C99 FloatMode stuff
Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 01:10




Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

?- Jay
 		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/6ab41119/attachment-0002.html>

From jay.krell at cornell.edu  Fri May 18 01:29:16 2012
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 17 May 2012 23:29:16 +0000
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517185753.GA5741@topoi.pooq.com>
References: <20120516152635.GA20806@topoi.pooq.com>,
	<20120516165926.GA3955@topoi.pooq.com>,
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>,
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>,
	<20120517014903.GA19546@topoi.pooq.com>,
	<20120517023533.GB19546@topoi.pooq.com>,
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>,
	<20120517154836.GA20605@topoi.pooq.com>,
	<20120517185753.GA5741@topoi.pooq.com>
Message-ID: <COL101-W47988370CD738A644D7366E6190@phx.gbl>


I have not built the entire tree since that stuff came in.Oops.  If the goal is to get some sort of .deb, to see what it is, to give it to someone else, do this:    cd scripts    rm PKGSDB    edit down pkginfo.txt     hm, oops, this stuff isn't in there?      The same information might be duplicated in pylib.py?   I think I fixed that..based on a quick read.       Maybe we pickup all m3makefiles? Maybe.    Just rm -rf from your tree anything that is giving you trouble now, as you've already built lots of stuff.     - Jay

 > Date: Thu, 17 May 2012 14:57:53 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] building packages from source from cvs -- odbc
> 
> On Thu, May 17, 2012 at 11:48:37AM -0400, Hendrik Boom wrote:
> > On Thu, May 17, 2012 at 06:01:19AM +0000, Jay K wrote:
> > > 
> > > Good.
> > > Wasn't the error message from configure obvious though?
> > 
> > Evidently not.  Or I was too much asleep last night.  Or I didn't get 
> > one. I'm looking for one now.  I find none in my most recent script 
> > output.  In one of the old ones I find
> > 
> > checking for modern makeinfo... no
> > configure: WARNING:
> > *** Makeinfo is missing or too old.
> > *** Info documentation will not be built.
> > checking for recent Pod::Man... yes
> > 
> > but I suspect that may be irrelevant.  Unless packageing fails later 
> > because it tries to package the info docs, which I hate anyway.
> > 
> > No, I don't find any messages.  But then, I'm simply using my old, 
> > working cm3 compiler as a bootstrap to build the whole system for the 
> > same machine.  I didn't have a specific 'configure' step.
> > 
> > I found a bunch of compilation warnings about
> > * labels and other names  being defined but not used.
> > * comparisons always false due to limited range of data type
> > * invalid conversion type characters.  Might these actually cause 
> > run-time failures?
> > * right-hand operand of comma has no effect
> > 
> > These are unlikely to be the problems I'm contending with, but might 
> > it be worth going through the entire build sometime and tracking 
> > then all down?  Grepping my script output for "warning" would 
> > probably find them all.
> > 
> > 
> > > 
> > > 
> > > Anyway:
> > >   I think there's a "minor" incrementality bug here.   
> > >   Incremental build isn't picking back up where it left off/failed.  
> > > 
> > > Try this:
> > >    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
> > >    rm -rf /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516 
> > >    ./make-dist.py  
> > 
> > Will do.  I had planned to do something like this when I was awake this 
> > morning, but I was unsure just which files needed to be deleted.
> > 
> 
> It definitely got past odbc now.  But it stopped within ESC.  I was 
> surprised to find it her; I had thought the source code to be long lost.
> I don't see am error message except for the failure to find .M3EXPORTS, 
> ahich is probably something that cm3 should have generated.
> 
> The m3makefile 
> /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile
> seems to have trouble finding 
> /tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/pkg/prover/AMD64_LINUX/.M3EXPORTS
> which seems to me to be one level out in the source code.  Just what 
> determines the order that these things are to be compiled?  The 
> compilation log makes it look as if the outer one (prover) needed to be 
> compiled first, so as to enerate the .M3EXPORTS file, but that the inner 
> one (prover/test) actually got compiled first. 
> 
> Here's the output, starting with the first line of log contianing either 
> the words "Simplify" or "prover".
> 
> 
> == package /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test ==
> 
>  +++ /tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/bin/cm3    
> -build -DROOT=/farhome/hendrik/cm3/cm3 +++
> --- building in AMD64_LINUX ---
> 
> ignoring ../src/m3overrides
> 
> "/farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile", line 
> 1: quake runtime error: unable to open 
> "/tmp/tmpua41ba/cm3-all-AMD64_LINUX-d5.9.0-20120517/pkg/prover/AMD64_LINUX/.M3EXPORTS" 
> for reading
> 
> --procedure--  -line-  -file---
> import             --  <builtin>
> include_dir         1  
> /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/src/m3makefile
>                     5  
> /farhome/hendrik/cm3/cm3/ESC/Simplify/prover/test/AMD64_LINUX/m3make.args
> 
> Fatal Error: package build failed
>  *** execution of [<function _BuildGlobalFunction at 0x10d0de8>, 
> <function _ShipFunction at 0x10d0c80>] failed ***
> hendrik at april:~/cm3/cm3/scripts/python$ exit
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/bca8ff44/attachment-0002.html>

From hendrik at topoi.pooq.com  Fri May 18 03:17:34 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 17 May 2012 21:17:34 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <COL101-W47988370CD738A644D7366E6190@phx.gbl>
References: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
	<COL101-W47988370CD738A644D7366E6190@phx.gbl>
Message-ID: <20120518011734.GA735@topoi.pooq.com>

On Thu, May 17, 2012 at 11:29:16PM +0000, Jay K wrote:
> 
> I have not built the entire tree since that stuff came in.Oops.  

My saying this year seems to be "That which is not tested is broken".

> If the goal is to get some sort of .deb, to see what it is, to give it to someone else, do this:    cd scripts    rm PKGSDB    edit down pkginfo.txt     hm, oops, this stuff isn't in there?      The same information might be duplicated in pylib.py?   I think I fixed that..based on a quick read.       Maybe we pickup all m3makefiles? Maybe.    Just rm -rf from your tree anything that is giving you trouble now, as you've already built lots of stuff.     - Jay

That's the way to get ahead at this point, yes.

I will have to take a look at ESC sometime, though.  It looks like fun.  
This is the stuff that processes all the mutex comments in Trestle, 
right?

I really had thought it was long-lost code, never to be seen again.  Or 
has someone started writing it anew?

-- hendrik


From jay.krell at cornell.edu  Fri May 18 03:31:59 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 01:31:59 +0000
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518011734.GA735@topoi.pooq.com>
References: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>,
	<20120516211526.GB8654@topoi.pooq.com>,
	<20120516235549.GB3955@topoi.pooq.com>,
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>,
	<20120517014903.GA19546@topoi.pooq.com>,
	<20120517023533.GB19546@topoi.pooq.com>,
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>,
	<20120517154836.GA20605@topoi.pooq.com>,
	<20120517185753.GA5741@topoi.pooq.com>,
	<COL101-W47988370CD738A644D7366E6190@phx.gbl>,
	<20120518011734.GA735@topoi.pooq.com>
Message-ID: <COL101-W35FD639411DD4E2EF83685E61E0@phx.gbl>


> My saying this year seems to be "That which is not tested is broken".  In the face of any change, including the mere passage of time (e.g. y2k):   That which is not tested often and recently is probably broken.    Running automated tests daily, or at least in a loop that might take over a day, is how you know what is working.   I believe someone recently recovered the ESC stuff. Probably Olaf.   - Jay
 > Date: Thu, 17 May 2012 21:17:34 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] building packages from source from cvs -- odbc
> 
> On Thu, May 17, 2012 at 11:29:16PM +0000, Jay K wrote:
> > 
> > I have not built the entire tree since that stuff came in.Oops.  
> 
> My saying this year seems to be "That which is not tested is broken".
> 
> > If the goal is to get some sort of .deb, to see what it is, to give it to someone else, do this:    cd scripts    rm PKGSDB    edit down pkginfo.txt     hm, oops, this stuff isn't in there?      The same information might be duplicated in pylib.py?   I think I fixed that..based on a quick read.       Maybe we pickup all m3makefiles? Maybe.    Just rm -rf from your tree anything that is giving you trouble now, as you've already built lots of stuff.     - Jay
> 
> That's the way to get ahead at this point, yes.
> 
> I will have to take a look at ESC sometime, though.  It looks like fun.  
> This is the stuff that processes all the mutex comments in Trestle, 
> right?
> 
> I really had thought it was long-lost code, never to be seen again.  Or 
> has someone started writing it anew?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/b1685039/attachment-0002.html>

From jay.krell at cornell.edu  Fri May 18 04:49:39 2012
From: jay.krell at cornell.edu (Jay)
Date: Thu, 17 May 2012 19:49:39 -0700
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <1337293645.96958.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <1337293645.96958.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <1301C8B3-DD12-46EE-BC17-0184E187A8A3@gmail.com>

I'm sorry Daniel, but almost all your emails make no sense or at best are just wrong.

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 17, 2012, at 3:27 PM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> if not then either that value doesn't sound as a machine value since the OS must care at least of constant values in memory (you can't allow values larger than what memory supports) or (whichever library they had created) is "their standard" , I don't think C standards are very precise, in fact, they are bad, who needs C standards, who created or thinks knows the standards.
> What the argot I would like to see are:
> Infinity values, epsilon, and  memory limits under such that limit values holds, that is, you can't represent epsilon with little value of memory.
> This would be the jargon of such libraries, instead they just make them a internal operation of their own calculation, which I can't trust, in summary this thing is unsound. Then the interface is UNSAFE for real which can't be a very standard thing by the way.
> Thanks in advance
> 
> --- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] C99 FloatMode stuff
> Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
> Fecha: jueves, 17 de mayo, 2012 13:46
> 
> No Daniel. 
> 
> 
> Date: Thu, 17 May 2012 17:18:52 +0100
> From: dabenavidesd at yahoo.es
> Subject: Re: [M3devel] C99 FloatMode stuff
> To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu
> 
> Hi all:
> I believe they are in system limits.h aren't they.
> BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
> Thanks in advance.
> 
> --- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] C99 FloatMode stuff
> Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
> Fecha: jueves, 17 de mayo, 2012 01:10
> 
> Mika, are FE_UNDERFLOW and such constants?
> Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
> see m3core/src/unix/Common/Uconstants.c
> 
> There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.
> 
>  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120517/46b853f6/attachment-0002.html>

From jay.krell at cornell.edu  Fri May 18 09:38:15 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 07:38:15 +0000
Subject: [M3devel] uninitialized vs. init_var?
Message-ID: <COL101-W19D4C919EC527186CC9B70E61E0@phx.gbl>


This seems dubious, doesn't it, to state something is not initiallized, and then initialize it?
It triggers an assertion failure in gcc 4.6 backend.

RTCollector.m3

(479) declare_global name:null size:0X4000000(67108864) align:0X40(64) type:struct type_id:0x747D8491 exported:false initialized:false var:0x3B m3name:L_2
(14190) init_var offset:0X2280(8832) var:0x3B:L_2 0 one_field: offset:0x2280 size:0x20


Yes I realize it is initialized to zero.
I don't know if it is obviously initialized to all zeros, as I don't see the size in declare_global..er..rather, yes, there is a size there...is it real, or just some large guess..? I haven't looked..


I'm going to try this little hack:


M3CG_HANDLER (INIT_VAR)
{
  tree f = { 0 };
  tree v = { 0 };

#if GCC46
  if (DECL_COMMON (var))
  {
    if (option_trace_all)
      fprintf (stderr, " clearing DECL_COMMON on %s", m3_get_var_trace_name (var));
    DECL_COMMON (var) = false;
  }
#endif

  TREE_USED (var) = true;
  one_field (offset, POINTER_SIZE, t_addr, &f, &v);
  TREE_VALUE (v) = m3_build2 (POINTER_PLUS_EXPR, t_addr,
                              m3_build1 (ADDR_EXPR, t_addr, var),
                              size_int (b));
}

The assertion is in gcc-4.6/gcc/config/darwin.c

darwin_asm_output_aligned_decl_local

  /* .. and it should be suitable for placement in local mem.  */
  gcc_assert(!TREE_PUBLIC (decl) && !DECL_COMMON (decl));
  /* .. and any initializer must be all-zero.  */
  gcc_assert ((DECL_INITIAL (decl) == NULL) 
           || (DECL_INITIAL (decl) == error_mark_node) 
           || initializer_zerop (DECL_INITIAL (decl)));


The first one I think. I think it is common.


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/892b5595/attachment-0002.html>

From dabenavidesd at yahoo.es  Fri May 18 17:36:40 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 18 May 2012 16:36:40 +0100 (BST)
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <1301C8B3-DD12-46EE-BC17-0184E187A8A3@gmail.com>
Message-ID: <1337355400.39333.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
The problem (and I don't think this for personal reasons, that I write at all), is as as Dr. Nelson rule of the thumb:
"If there is one paper about a problem, it has been solved, but If there are 100 papers it probably hasn't been solved"
Thanks in advance

--- El jue, 17/5/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] C99 FloatMode stuff
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: jueves, 17 de mayo, 2012 21:49

I'm sorry Daniel, but almost all your emails make no sense or at best are just wrong.
?- Jay (briefly/pocket-sized-computer-aka-phone)
On May 17, 2012, at 3:27 PM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
if not then either that value doesn't sound as a machine value since the OS must care at least of constant values in memory (you can't allow values larger than what memory supports) or (whichever library they had created) is "their standard" , I don't think C standards are very precise, in fact, they are bad, who needs C standards, who created or thinks knows the standards.
What the argot I would like to see are:
Infinity values, epsilon, and? memory limits under such that limit values holds, that is, you can't represent epsilon with little value of memory.
This would be the jargon of such libraries, instead they just make them a internal operation of their own calculation, which I can't trust, in summary this thing is unsound. Then the interface is UNSAFE for real which can't be a very standard thing by the way.
Thanks in
 advance

--- El jue, 17/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] C99 FloatMode stuff
Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 13:46




No Daniel. 


Date: Thu, 17 May 2012 17:18:52 +0100
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] C99 FloatMode stuff
To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I believe they are in system limits.h aren't they.
BTW, such max value should be violated by RT checks for the same value? If it isn't then you need to use a long address value to represent its numerical value without violating anything, right? Anyway you would need an unsigned Word for doing that, that is a LongWord.
Thanks in advance.

--- El jue, 17/5/12, Jay K
 <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] C99 FloatMode stuff
Para: "Mika Nystrom" <mika at async.caltech.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de mayo, 2012 01:10




Mika, are FE_UNDERFLOW and such constants?
Specifically, if so, we can implement them more efficiently, as constant data, instead of via functions.
see m3core/src/unix/Common/Uconstants.c

There is a certain elegant generality to using functions, but exposing constant data should be /slightly/ more efficient.

?- Jay
 		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/265f116f/attachment-0002.html>

From mika at async.caltech.edu  Fri May 18 18:28:56 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Fri, 18 May 2012 09:28:56 -0700
Subject: [M3devel] C99 FloatMode stuff
In-Reply-To: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl> 
References: <COL101-W5277388A9CDEA1A1A50FD7E6190@phx.gbl>
Message-ID: <20120518162856.4B3BD1A205B@async.async.caltech.edu>

Jay,

Yes I think FE_OVERFLOW et al. are required to be macros that expand
to integer constants.  So yes..

    Mika

Jay K writes:
>--_9cde7264-29bf-49d4-826d-6091d2cdb722_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Mika=2C are FE_UNDERFLOW and such constants?
>Specifically=2C if so=2C we can implement them more efficiently=2C as const=
>ant data=2C instead of via functions.
>see m3core/src/unix/Common/Uconstants.c
>
>There is a certain elegant generality to using functions=2C but exposing co=
>nstant data should be /slightly/ more efficient.
>
> - Jay
> 		 	   		  =
>
>--_9cde7264-29bf-49d4-826d-6091d2cdb722_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Tahoma
>}
>--></style></head>
><body class=3D'hmmessage'><div dir=3D'ltr'>
>Mika=2C are FE_UNDERFLOW and such constants?<br>Specifically=2C if so=2C we=
> can implement them more efficiently=2C as constant data=2C instead of via =
>functions.<br>see m3core/src/unix/Common/Uconstants.c<br><br>There is a cer=
>tain elegant generality to using functions=2C but exposing constant data sh=
>ould be /slightly/ more efficient.<br><br>&nbsp=3B- Jay<br> 		 
>	   		  </di=
>v></body>
></html>=
>
>--_9cde7264-29bf-49d4-826d-6091d2cdb722_--


From hendrik at topoi.pooq.com  Fri May 18 18:34:10 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 12:34:10 -0400
Subject: [M3devel] packages for AMD64-LINUX stable.
In-Reply-To: <20120518011734.GA735@topoi.pooq.com>
References: <20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
	<COL101-W47988370CD738A644D7366E6190@phx.gbl>
	<20120518011734.GA735@topoi.pooq.com>
Message-ID: <20120518163410.GA28229@topoi.pooq.com>

On Thu, May 17, 2012 at 09:17:34PM -0400, Hendrik Boom wrote:
> On Thu, May 17, 2012 at 11:29:16PM +0000, Jay K wrote:
> > 
> > I have not built the entire tree since that stuff came in.Oops.  
> 
> My saying this year seems to be "That which is not tested is broken".
> 
> > If the goal is to get some sort of .deb, to see what it is, to give it to someone else, do this:    cd scripts    rm PKGSDB    edit down pkginfo.txt     hm, oops, this stuff isn't in there?      The same information might be duplicated in pylib.py?   I think I fixed that..based on a quick read.       Maybe we pickup all m3makefiles? Maybe.    Just rm -rf from your tree anything that is giving you trouble now, as you've already built lots of stuff.     - Jay
> 
> That's the way to get ahead at this point, yes.

I now have packages 

cm3-all-AMD64_LINUX-d5.9.0-20120518.deb
cm3-all-AMD64_LINUX-d5.9.0-20120518.tar.gz
cm3-min-AMD64_LINUX-d5.9.0-20120518
cm3-min-AMD64_LINUX-d5.9.0-20120518.tar.gz

and a few huge directories under /tmp.  I presume those huge directories
contain the files that were archived into these packages and that I can 
discard them.  Have all the executables in them been shipped?  Or should 
I delete /usr/local/cm3 and install the package?

Is the verion number right?  And will debian's package mamager collate 
it becode, for example, cm3-all-AMD64_LINUX-5.9.0 when it finally comes 
out?  If not, the right version number for Debian is probably something 
like 5.9.0~20120518 instead of d5.9.0-20120518 (note the tilde).  I'll 
look at the version-numbering stuff in the packaging manual and see if I 
draw any conclusions, and whether the version number that's in the file 
name has any relevance to the one the package manager uses.
And the binary package just might have to contain the AMD64_LINUX 
information in another form.

And, of course, I'll have to do a test install, because that which is 
not tested is broken.

If I get these things sorted out, it's probably ready to make available 
as a package that works on current debian stable, though it'll be a lot 
more work to get it to conform to all the debian packaging 
rules.

Oh, yes, the package leaves out ESC.  My guess is that the package 
builder builds its modules in the wrong order, presumably because it 
needs some clues that should be present in the ESC source directories 
but isn't.  Anyone know what information find-packages.sh and pkginfo.sh 
need to do the job properly?  How do these nested program direcoties 
work, anyway?

-- hendrik

> 
> I will have to take a look at ESC sometime, though.  It looks like fun.  
> This is the stuff that processes all the mutex comments in Trestle, 
> right?
> 
> I really had thought it was long-lost code, never to be seen again.  Or 
> has someone started writing it anew?
> 
> -- hendrik


From dragisha at m3w.org  Fri May 18 18:58:26 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 18 May 2012 18:58:26 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516223123.GA25611@topoi.pooq.com>
	<COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>
Message-ID: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>

One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.

On May 17, 2012, at 1:40 AM, Jay K wrote:

>   But heck, really, if we generate C, then targets largely drop away.  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/01be4ef6/attachment-0002.html>

From mika at async.caltech.edu  Fri May 18 19:11:11 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Fri, 18 May 2012 10:11:11 -0700
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120517185753.GA5741@topoi.pooq.com> 
References: <20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
Message-ID: <20120518171111.C803A1A205B@async.async.caltech.edu>

Hendrik Boom writes:
...
>It definitely got past odbc now.  But it stopped within ESC.  I was 
>surprised to find it her; I had thought the source code to be long lost.
...

It's not.  I was promised it and started to set up the directories but the
gentleman who promised me the code seems to have fallen off the earth.

    Mika


From dabenavidesd at yahoo.es  Fri May 18 19:16:59 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 18 May 2012 18:16:59 +0100 (BST)
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
Message-ID: <1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
After ESC we do need much debugger at all, in fact it was designed for that for avoiding put much time on it.
Still if we generate C is for super-optimization (but verified also mechanically), so I don't mind that, but for code quality I prefer C, I agree absolutely in that we should support it again for that purpose (as originally).
As for not verified code we should stick with C--, as it is written for that purposes, but for portability specially with implicit safety.
And for not verified nor optimal and not common use code (like mentor) we should make them source packages (in fact If they are written in Obliq we don't want to redistribute that as non-source), instead part of m3-demo package subdirectory or so.
I think for M3CG is that we need a LLVM or so back-end for JIT.
Thanks in advance

--- El vie, 18/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] LINUXLIBC6
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 18 de mayo, 2012 11:58

One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.
On May 17, 2012, at 1:40 AM, Jay K wrote:
??But heck, really, if we generate C, then targets largely drop away.??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/55302ae7/attachment-0002.html>

From hendrik at topoi.pooq.com  Fri May 18 19:23:00 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 13:23:00 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518171111.C803A1A205B@async.async.caltech.edu>
References: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
	<20120518171111.C803A1A205B@async.async.caltech.edu>
Message-ID: <20120518172300.GA28507@topoi.pooq.com>

On Fri, May 18, 2012 at 10:11:11AM -0700, Mika Nystrom wrote:
> Hendrik Boom writes:
> ...
. I was surprised to find it here; I had thought the source code to be 
> long lost.
> ...
> 
> It's not.  I was promised it and started to set up the directories but the
> gentleman who promised me the code seems to have fallen off the earth.

So the ESC directory isn't ESC yet?  Did the gentleman send you some 
but not all of it? 

-- hendrik


From hendrik at topoi.pooq.com  Fri May 18 19:26:06 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 13:26:06 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516223123.GA25611@topoi.pooq.com>
	<COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>
	<F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
Message-ID: <20120518172606.GB28507@topoi.pooq.com>

On Fri, May 18, 2012 at 06:58:26PM +0200, Dragi?a Duri? wrote:
> One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.

It's possible to generate C code full of #line preprocessor commands, 
so that debuggers get references to the original source code, not the 
generated C code.  The variable names would possibly be obscure, 
though.

> 
> On May 17, 2012, at 1:40 AM, Jay K wrote:
> 
> >   But heck, really, if we generate C, then targets largely drop away.  
> 


From dabenavidesd at yahoo.es  Fri May 18 19:27:27 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 18 May 2012 18:27:27 +0100 (BST)
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518171111.C803A1A205B@async.async.caltech.edu>
Message-ID: <1337362047.35503.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
we should be more aware that today H-P annually from now will drop 30.000 jobs there in total, so I hope this can go on smoothly.
If not, we should ask them which projects made them release their source code on the last ancient Mobile OS.
Thanks in advance


--- El vie, 18/5/12, Mika Nystrom <mika at async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] building packages from source from cvs -- odbc
> Para: "Hendrik Boom" <hendrik at topoi.pooq.com>
> CC: m3devel at elegosoft.com
> Fecha: viernes, 18 de mayo, 2012 12:11
> Hendrik Boom writes:
> ...
> >It definitely got past odbc now.  But it stopped
> within ESC.  I was 
> >surprised to find it her; I had thought the source code
> to be long lost.
> ...
> 
> It's not.  I was promised it and started to set up the
> directories but the
> gentleman who promised me the code seems to have fallen off
> the earth.
> 
>     Mika
> 


From mika at async.caltech.edu  Fri May 18 20:03:30 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Fri, 18 May 2012 11:03:30 -0700
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518172300.GA28507@topoi.pooq.com> 
References: <COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
	<20120517154836.GA20605@topoi.pooq.com>
	<20120517185753.GA5741@topoi.pooq.com>
	<20120518171111.C803A1A205B@async.async.caltech.edu>
	<20120518172300.GA28507@topoi.pooq.com>
Message-ID: <20120518180330.4CDB21A205B@async.async.caltech.edu>

Hendrik Boom writes:
>On Fri, May 18, 2012 at 10:11:11AM -0700, Mika Nystrom wrote:
>> Hendrik Boom writes:
>> ...
>. I was surprised to find it here; I had thought the source code to be 
>> long lost.
>> ...
>> 
>> It's not.  I was promised it and started to set up the directories but the
>> gentleman who promised me the code seems to have fallen off the earth.
>
>So the ESC directory isn't ESC yet?  Did the gentleman send you some 
>but not all of it? 
>
>-- hendrik

What's in there is Simplify, which has been distributed with other projects
(specifically with ESC/Java).  It's also part of the original ESC.

     Mika


From jay.krell at cornell.edu  Fri May 18 21:23:24 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 19:23:24 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
References: <20120513174747.GA25729@topoi.pooq.com>,
	<20120515151217.GA23964@topoi.pooq.com>,
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>,
	<20120516223123.GA25611@topoi.pooq.com>
	<COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>,
	<F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
Message-ID: <COL101-W45E1537E67C2E81FC1A9C4E61E0@phx.gbl>


The debugging experience is already poor on systems that don't support stabs, e.g. Darwin, NT, HP-UX (maybe only certain processors therein). Also it requires building a custom gdb. Our gdb fork is old. Is anyone going to update it ever?#line directives will help.Stock gdb will be much more useful than it is today.But yes, it won't be great idiomatic Modula-3 debugging.   - Jay Subject: Re: [M3devel] LINUXLIBC6
From: dragisha at m3w.org
Date: Fri, 18 May 2012 18:58:26 +0200
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.
On May 17, 2012, at 1:40 AM, Jay K wrote:  But heck, really, if we generate C, then targets largely drop away.  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/74eeb691/attachment-0002.html>

From jay.krell at cornell.edu  Fri May 18 21:49:44 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 19:49:44 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>,
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W1466668864A79F0C274528E61E0@phx.gbl>


C-- is not actively maintained I believe, so not a good idea to use.  C and C++ are much more portable and "maintained" (C++ gives us more portable efficient exception handling.)  (There is a good C and C++ compiler for every mainstream system in use today  LLVM isn't a bad idea, but there is more expertise out there (and in me) with C and C++, so C and C++ are easier to generate.It is a bit of a chore to learn and use.  JIT isn't a crazy idea either..or rather, an interpreter.If you look at parse.c..and you add a few thread locals..I think it's not hard to turn it into an interpreter.  (In reality you don't want to start with parse.c because of the GPL.)  And, interesting point as well, an interpreter in Java or C# or whatever is "more native" on e.g. Android and Windows Phone, is also not too difficult. You could do it in a low level fashion that is viable in "safe" environments.Search the web for "XML VM". I know it is nonsense term, but the project is/was real, despite the name, it is a viable approach.  What they did is this:  "convert" (i.e. dump faithfully and without optimization or fitting any uniform scheme) Java .class files and .NET IL into XML.  Write XML Style Sheets (XSL) to transform to whatever -- including JavaScript and C.  Write some supporting libraries.  As a result, they could "compile" Java to C and run on iPhone, "compile" Java to JavaScript and run in browser (Yes, I know about Google Web Toolkit.)    - Jay
 Date: Fri, 18 May 2012 18:16:59 +0100
From: dabenavidesd at yahoo.es
To: dragisha at m3w.org
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] LINUXLIBC6

Hi all:
After ESC we do need much debugger at all, in fact it was designed for that for avoiding put much time on it.
Still if we generate C is for super-optimization (but verified also mechanically), so I don't mind that, but for code quality I prefer C, I agree absolutely in that we should support it again for that purpose (as originally).
As for not verified code we should stick with C--, as it is written for that purposes, but for portability specially with implicit safety.
And for not verified nor optimal and not common use code (like mentor) we should make them source packages (in fact If they are written in Obliq we don't want to redistribute that as non-source), instead part of m3-demo package subdirectory or so.
I think for M3CG is that we need a LLVM or so back-end for JIT.
Thanks in advance

--- El vie, 18/5/12, Dragi?a
 Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] LINUXLIBC6
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 18 de mayo, 2012 11:58

One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.
On May 17, 2012, at 1:40 AM, Jay K wrote:  But heck, really, if we generate C, then targets largely drop away.  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/33fcf5fa/attachment-0002.html>

From hendrik at topoi.pooq.com  Fri May 18 22:56:49 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 16:56:49 -0400
Subject: [M3devel] more Debian packages?
Message-ID: <20120518205649.GA26162@topoi.pooq.com>

Having succeeded at producing a binary .deb packages for Debian squeeze 
(though I still have to try it out), I'm now looking at my other 
machines.  I have a 32-bit Intel machine with wheeze (testing), and one 
that can run squeeze (stable).  All of them have access to the same 
NFS-mounted source tree.  Is it practical to use the same tree for two 
different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
be kept separate?  Or do I need to clean it out or copy it?

(by the way, I expect making packages for different Debian releases on 
the same hardware architecture will require a new source tree, or a 
cleaned-out one.  In my case they'll both be LINUXLIBC6)

-- hendrik



From jay.krell at cornell.edu  Fri May 18 23:50:24 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 May 2012 21:50:24 +0000
Subject: [M3devel] more Debian packages?
In-Reply-To: <20120518205649.GA26162@topoi.pooq.com>
References: <20120518205649.GA26162@topoi.pooq.com>
Message-ID: <COL101-W81D30A014D472E089333EE61E0@phx.gbl>


Yes and yes.LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.  Please try to use I386_LINUX.I really want to stop this LINUXLIBC6 stuff...   You can share the source. But we also have outputs in the source tree (unfortunately!).    You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...   Do this to switch:  ./do-cm3-all.py realclean   - Jay
 > Date: Fri, 18 May 2012 16:56:49 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] more Debian packages?
> 
> Having succeeded at producing a binary .deb packages for Debian squeeze 
> (though I still have to try it out), I'm now looking at my other 
> machines.  I have a 32-bit Intel machine with wheeze (testing), and one 
> that can run squeeze (stable).  All of them have access to the same 
> NFS-mounted source tree.  Is it practical to use the same tree for two 
> different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> be kept separate?  Or do I need to clean it out or copy it?
> 
> (by the way, I expect making packages for different Debian releases on 
> the same hardware architecture will require a new source tree, or a 
> cleaned-out one.  In my case they'll both be LINUXLIBC6)
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/93b0a19f/attachment-0002.html>

From hendrik at topoi.pooq.com  Sat May 19 01:29:59 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 18 May 2012 19:29:59 -0400
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
References: <20120516145653.GA19959@topoi.pooq.com>
	<20120516152635.GA20806@topoi.pooq.com>
	<20120516165926.GA3955@topoi.pooq.com>
	<COL101-W6095FDBB9410420D3C405DE6180@phx.gbl>
	<20120516211526.GB8654@topoi.pooq.com>
	<20120516235549.GB3955@topoi.pooq.com>
	<COL101-W56F152DB5E8A183B434E24E6190@phx.gbl>
	<20120517014903.GA19546@topoi.pooq.com>
	<20120517023533.GB19546@topoi.pooq.com>
	<COL101-W41477E24FA6A2C5D82B7B0E6190@phx.gbl>
Message-ID: <20120518232959.GB26422@topoi.pooq.com>

On Thu, May 17, 2012 at 06:01:19AM +0000, Jay K wrote:
> 
> Note also, I think it is obvious, but I wrote make-dist.py to always package up everything possible
> for the target platform. So it is up to you as the "builder" to have all the dependencies already installed.
> It isn't great.
> I don't believe there is a perfect option here.
> Another release form we have yields a bunch of per-target packages.
> I find that confusing -- too many.
> My form yields just one largeish per-target package.
> Over-size, monolithic, but simpler, less choices to confuse people.

Debian splits things up a lot more, and has explicit package-dependencies.

There's usually an omnibus package the depends on all the others, for 
the simple souls who just want everything.  Sometimes they are amazed 
how much everything entails.  More often the don't notice.  I, for 
example, got a complete set of video drivers for just about every 
video card ever made, as a result of installing one package I was 
actually interested in.  Threatening to take one out (I didn't have 
that card) resulted in aptitude trying to remove my window manager.  
Clearly a poor situation.  But that's what an all-inclusive policy can 
cause.

In addition, there's a main package that contains everything you just 
couldn't do without, and you have to add other packages as you need 
them.  For the video situation above, the user could take this approach, 
but it would require him to know just what hardware he had in his 
machine.  Most users don't know this and don't care to find out.

So applying this philosophy to Modula 3, it would probably end up 
split up at least as much as the multipackage offering on the download 
site.  And these packages would have dependencies on one another, so 
you wouldn't end up installing one without its prerequisites.

One package would clearly be the compiler and its minimal run-time 
system.

Others would provide applications and libraries.

And each libraries would be split further -- one package (perhaps 
called foo) that provides what you need to run a program using it, and 
another (foo-dev) that provides what you need to cmopile a program 
that needs it.  THer are interested in making the disk requirements 
of a Debian system as small as possible.  Even in C, if you aren't 
going to use a library for developmentt, you can get rid of a lot of 
h-files.

It's quite possible for one source package to generate several binary 
packages, by the way.

---

The other thing that separates our packages from ordinary, official 
Debian packages it that ours install everything to one place in the 
file system, and Debian follows a standard tthat spreads it all over 
the place.

I'd have to learn and do a lot to get something acceptable to Debian.  
I certianly won't get it all done by the expected wheezy freeze in a 
few months, and, other things being important too, I may not get 
around to it at all.

-- hendrik 

> 
> 
> Of course ultimately we don't want per-target stuff at all. :)
> Or at least we want both "source" and "binary" distributions.

-- hendrik

> 
> 
> Still I am confused.
> Don't people have binary distributions of programs with GUIs for Linux?
> Like Komodo IDE, Komodo Edit, Acrobat Reader?
> 
> 
> Maybe we should really have a java-generating backend...one binary distribution for all..and a better Android story?
> I know, there is a funny tradeoff here. Modula-3 is kind of lower-level than Java.
> You'd want such a backend/port to throw out our garbage collector..and heck..all unsafe code....
>  (or generate C for those and use JNI or such...interesting..theoretically possible..unlikely to happen..)
> 
> 
>  - Jay
> 
> 
> > Date: Wed, 16 May 2012 22:35:33 -0400
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] building packages from source from cvs -- odbc
> > 
> > On Wed, May 16, 2012 at 09:49:03PM -0400, Hendrik Boom wrote:
> > > On Thu, May 17, 2012 at 12:06:00AM +0000, Jay K wrote:
> > > > 
> > > >      > *** LIBRARY_PATH shouldn't contain the current directory when  
> > > >      > *** building gcc. Please change the environment variable  
> > > >      > *** and run configure again.  
> > > >     hendrik at april:~/cm3/cm3/scripts/python$ echo $LIBRARY_PATH  
> > > >   :/usr/local/Gambit-C/lib  
> > > >  Please either clear the variable, or at least remove the leading :.The leading : makes there be an empty entry, which is interpreted as current directory, which is dangerous and fragile. I think.This is a local problem on your machine. Easily fixed.   It might be reasonable for us to clear it in m3cc/src/m3makefile.   - Jay 		 	   		  
> > > 
> > > Yes, emptying LIBRARY_PATH enabled uprade.py to complete successfully.
> > > Thanks.  It would have taken me many ages to figure this out.
> > > 
> > > -- hendrik
> > > 
> > Now I'm onto ./make-dist.py
> > 
> > It fails in teh data base stuff.
> > 
> > First becaues it didn't have libodbc.  So I installed package unixodbc.
> > But then:
> > 
> > == package /farhome/hendrik/cm3/cm3/m3-db/odbc ==
> > 
> >  +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3    -build -DROOT=/farhome/hendrik/cm3/cm3 +++
> > --- building in AMD64_LINUX ---
> > 
> > ignoring ../src/m3overrides
> > 
> >  ==> /farhome/hendrik/cm3/cm3/m3-db/odbc done
> > 
> >  +++ /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3  -ship -DROOT=/farhome/hendrik/cm3/cm3 +++
> > --- shipping from AMD64_LINUX ---
> > 
> > . => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> >   .M3EXPORTS      
> > . => /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib
> >   libm3odbc.so.5  "/farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP", line 4: quake runtime error: unable to copy "libm3odbc.so.5" to "/tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib/libm3odbc.so.5": errno=2
> > 
> > --procedure--  -line-  -file---
> > install_file       --  <builtin>
> >                     4  /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP
> > 
> > Fatal Error: package build failed
> >  *** execution of [<function _BuildGlobalFunction at 0x1a56de8>, <function _ShipFunction at 0x1a56c80>] failed ***
> > hendrik at april:~/cm3/cm3/scripts/python$ 
> > 
> > 
> > It doesn't seem to build libm3odbc.so.5
> > 
> > hendrik at april:~/cm3/cm3/m3-db/odbc$ ls AMD64_LINUX/
> > libm3odbc.a    libm3odbc.so  SQLext.mo  SQLtypes.io
> > libm3odbc.m3x  SQLext.io     SQL.io
> > hendrik at april:~/cm3/cm3/m3-db/odbc$ 
> > 
> > There's nothing at all in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> > There are lots of files in /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib,
> > but nothing resembling libm3odbc>
> > 
> > -- hendrik
> > 
> > 
>  		 	   		  


From dabenavidesd at yahoo.es  Sat May 19 16:38:48 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 19 May 2012 15:38:48 +0100 (BST)
Subject: [M3devel] building packages from source from cvs -- odbc
In-Reply-To: <20120518232959.GB26422@topoi.pooq.com>
Message-ID: <1337438328.39377.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
if the .deb package doesn't overrides another location or content of .io files in another .deb then it shouldn't go inside the same PKG_ROOT but just as is any other non-Modula3 built library. But if they are, they should go to cm3 paths because you could require to re-link and generate updated packages from a specific location you choose from deb-src.
Something akin linux modules and kernel, if you compile a new module you need to rebuild against the kernel (isn't like that) to re-link and use. Normally this modules are just libraries and kernel is just compiled in very old stable kernels. That's what I learned from Ubuntu.
Thanks in advance 

--- El vie, 18/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] building packages from source from cvs -- odbc
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 18 de mayo, 2012 18:29
> On Thu, May 17, 2012 at 06:01:19AM
> +0000, Jay K wrote:
> > 
> > Note also, I think it is obvious, but I wrote
> make-dist.py to always package up everything possible
> > for the target platform. So it is up to you as the
> "builder" to have all the dependencies already installed.
> > It isn't great.
> > I don't believe there is a perfect option here.
> > Another release form we have yields a bunch of
> per-target packages.
> > I find that confusing -- too many.
> > My form yields just one largeish per-target package.
> > Over-size, monolithic, but simpler, less choices to
> confuse people.
> 
> Debian splits things up a lot more, and has explicit
> package-dependencies.
> 
> There's usually an omnibus package the depends on all the
> others, for 
> the simple souls who just want everything.  Sometimes
> they are amazed 
> how much everything entails.  More often the don't
> notice.  I, for 
> example, got a complete set of video drivers for just about
> every 
> video card ever made, as a result of installing one package
> I was 
> actually interested in.  Threatening to take one out (I
> didn't have 
> that card) resulted in aptitude trying to remove my window
> manager.  
> Clearly a poor situation.  But that's what an
> all-inclusive policy can 
> cause.
> 
> In addition, there's a main package that contains everything
> you just 
> couldn't do without, and you have to add other packages as
> you need 
> them.  For the video situation above, the user could
> take this approach, 
> but it would require him to know just what hardware he had
> in his 
> machine.  Most users don't know this and don't care to
> find out.
> 
> So applying this philosophy to Modula 3, it would probably
> end up 
> split up at least as much as the multipackage offering on
> the download 
> site.  And these packages would have dependencies on
> one another, so 
> you wouldn't end up installing one without its
> prerequisites.
> 
> One package would clearly be the compiler and its minimal
> run-time 
> system.
> 
> Others would provide applications and libraries.
> 
> And each libraries would be split further -- one package
> (perhaps 
> called foo) that provides what you need to run a program
> using it, and 
> another (foo-dev) that provides what you need to cmopile a
> program 
> that needs it.  THer are interested in making the disk
> requirements 
> of a Debian system as small as possible.  Even in C, if
> you aren't 
> going to use a library for developmentt, you can get rid of
> a lot of 
> h-files.
> 
> It's quite possible for one source package to generate
> several binary 
> packages, by the way.
> 
> ---
> 
> The other thing that separates our packages from ordinary,
> official 
> Debian packages it that ours install everything to one place
> in the 
> file system, and Debian follows a standard tthat spreads it
> all over 
> the place.
> 
> I'd have to learn and do a lot to get something acceptable
> to Debian.  
> I certianly won't get it all done by the expected wheezy
> freeze in a 
> few months, and, other things being important too, I may not
> get 
> around to it at all.
> 
> -- hendrik 
> 
> > 
> > 
> > Of course ultimately we don't want per-target stuff at
> all. :)
> > Or at least we want both "source" and "binary"
> distributions.
> 
> -- hendrik
> 
> > 
> > 
> > Still I am confused.
> > Don't people have binary distributions of programs with
> GUIs for Linux?
> > Like Komodo IDE, Komodo Edit, Acrobat Reader?
> > 
> > 
> > Maybe we should really have a java-generating
> backend...one binary distribution for all..and a better
> Android story?
> > I know, there is a funny tradeoff here. Modula-3 is
> kind of lower-level than Java.
> > You'd want such a backend/port to throw out our garbage
> collector..and heck..all unsafe code....
> >  (or generate C for those and use JNI or
> such...interesting..theoretically possible..unlikely to
> happen..)
> > 
> > 
> >  - Jay
> > 
> > 
> > > Date: Wed, 16 May 2012 22:35:33 -0400
> > > From: hendrik at topoi.pooq.com
> > > To: m3devel at elegosoft.com
> > > Subject: Re: [M3devel] building packages from
> source from cvs -- odbc
> > > 
> > > On Wed, May 16, 2012 at 09:49:03PM -0400, Hendrik
> Boom wrote:
> > > > On Thu, May 17, 2012 at 12:06:00AM +0000, Jay
> K wrote:
> > > > > 
> > > > >      > ***
> LIBRARY_PATH shouldn't contain the current directory
> when  
> > > > >      > *** building
> gcc. Please change the environment variable  
> > > > >      > *** and run
> configure again.  
> > > > > 
>    hendrik at april:~/cm3/cm3/scripts/python$
> echo $LIBRARY_PATH  
> > > >
> >   :/usr/local/Gambit-C/lib  
> > > > >  Please either clear the variable,
> or at least remove the leading :.The leading : makes there
> be an empty entry, which is interpreted as current
> directory, which is dangerous and fragile. I think.This is a
> local problem on your machine. Easily
> fixed.   It might be reasonable for us to
> clear it in m3cc/src/m3makefile.   - Jay
>    
>         
>           
>   
> > > > 
> > > > Yes, emptying LIBRARY_PATH enabled uprade.py
> to complete successfully.
> > > > Thanks.  It would have taken me many
> ages to figure this out.
> > > > 
> > > > -- hendrik
> > > > 
> > > Now I'm onto ./make-dist.py
> > > 
> > > It fails in teh data base stuff.
> > > 
> > > First becaues it didn't have libodbc.  So I
> installed package unixodbc.
> > > But then:
> > > 
> > > == package /farhome/hendrik/cm3/cm3/m3-db/odbc ==
> > > 
> > >  +++
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3 
>   -build -DROOT=/farhome/hendrik/cm3/cm3 +++
> > > --- building in AMD64_LINUX ---
> > > 
> > > ignoring ../src/m3overrides
> > > 
> > >  ==> /farhome/hendrik/cm3/cm3/m3-db/odbc
> done
> > > 
> > >  +++
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3 
> -ship -DROOT=/farhome/hendrik/cm3/cm3 +++
> > > --- shipping from AMD64_LINUX ---
> > > 
> > > . =>
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> > >   .M3EXPORTS      
> > > . =>
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib
> > >   libm3odbc.so.5 
> "/farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP",
> line 4: quake runtime error: unable to copy "libm3odbc.so.5"
> to
> "/tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib/libm3odbc.so.5":
> errno=2
> > > 
> > > --procedure--  -line-  -file---
> > > install_file   
>    --  <builtin>
> > >             
>        4 
> /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP
> > > 
> > > Fatal Error: package build failed
> > >  *** execution of [<function
> _BuildGlobalFunction at 0x1a56de8>, <function
> _ShipFunction at 0x1a56c80>] failed ***
> > > hendrik at april:~/cm3/cm3/scripts/python$ 
> > > 
> > > 
> > > It doesn't seem to build libm3odbc.so.5
> > > 
> > > hendrik at april:~/cm3/cm3/m3-db/odbc$ ls
> AMD64_LINUX/
> > > libm3odbc.a    libm3odbc.so 
> SQLext.mo  SQLtypes.io
> > > libm3odbc.m3x  SQLext.io 
>    SQL.io
> > > hendrik at april:~/cm3/cm3/m3-db/odbc$ 
> > > 
> > > There's nothing at all in
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> > > There are lots of files in
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib,
> > > but nothing resembling libm3odbc>
> > > 
> > > -- hendrik
> > > 
> > > 
> >     
>         
>           
>   
> 


From dabenavidesd at yahoo.es  Sat May 19 18:41:03 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 19 May 2012 17:41:03 +0100 (BST)
Subject: [M3devel] building packages from source from cvs -- odbc
Message-ID: <1337445663.91287.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
there seems to be a relation between Modula-3 GUI INTERFACE specification of a pen-handling UI that allowed to type letters from uni-strokes:
http://www.leagle.com/xmlResult.aspx?page=11&xmldoc=2001481198FSupp2d283_1453.xml&docbase=CSLWAR2-1986-2006&SizeDisp=7

3com argued that the Modula-3's XEROX Patent wasn't infringed since the OS hadn't specified that functionality but settled the case with a money deal and a 7-year peace deal over mutual patents from 3com:
http://findarticles.com/p/articles/mi_m0EIN/is_2006_June_28/ai_n26909742/

Now that next year deal will be over they might be interested in pursuing another set of questions over XEROX's OS using Modula-3 code in ESC (because they would still need to proof full-integrity of Modula-3 ESC tool) and libraries use by XEROX OS:
http://www.google.com/patents/US5596656

I think we could ask if they want to litigate over the XEROX' OS again.
Thanks in advance

--- El vie, 18/5/12, Mika Nystrom <mika at async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] building packages from source from cvs -- odbc
> Para: "Hendrik Boom" <hendrik at topoi.pooq.com>
> CC: m3devel at elegosoft.com
> Fecha: viernes, 18 de mayo, 2012 13:03
> Hendrik Boom writes:
> >On Fri, May 18, 2012 at 10:11:11AM -0700, Mika Nystrom
> wrote:
> >> Hendrik Boom writes:
> >> ...
> >. I was surprised to find it here; I had thought the
> source code to be 
> >> long lost.
> >> ...
> >> 
> >> It's not.  I was promised it and started to
> set up the directories but the
> >> gentleman who promised me the code seems to have
> fallen off the earth.
> >
> >So the ESC directory isn't ESC yet?  Did the
> gentleman send you some 
> >but not all of it? 
> >
> >-- hendrik
> 
> What's in there is Simplify, which has been distributed with
> other projects
> (specifically with ESC/Java).  It's also part of the
> original ESC.
> 
>      Mika
>




From dabenavidesd at yahoo.es  Sat May 19 20:32:10 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 19 May 2012 19:32:10 +0100 (BST)
Subject: [M3devel] more Debian packages?
In-Reply-To: <COL101-W81D30A014D472E089333EE61E0@phx.gbl>
Message-ID: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:

?I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,

for instance to allow and or LINUX_I8086, etc LINUX_I387 

For VAXen computers:

VMS_VAX__

for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11

Alpha's: OSF_ALPHA

For Unixes:

FBSD-GENERIC_I_86___--

To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64

Also could be managed by Manufacturer Model code-name, like

DEC_AQUARIUS or DEC_10000.



Also if we are gonna take macro assembly for cross-platform distributions then, we would need? something akin:

NT_XASM-I_86___

So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)

This would allow to compile CVSup at least is what one would like to
Thanks in advance

 --- El vie, 18/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] more Debian packages?
Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 18 de mayo, 2012 16:50




Yes and yes.
LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.
But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.
?
?
Please try to use I386_LINUX.
I really want to stop this LINUXLIBC6 stuff...
?
?
?You can share the source.
?But we also have outputs in the source tree (unfortunately!).
??? You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...
?
?
?Do this to switch:
?
?./do-cm3-all.py realclean 
?
?- Jay
?
> Date: Fri, 18 May 2012 16:56:49 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] more Debian packages?
> 
> Having succeeded at producing a binary .deb packages for Debian squeeze 
> (though I still have to try it out), I'm now looking at my other 
> machines.  I have a 32-bit Intel machine with wheeze (testing), and one 
> that can run squeeze (stable).  All of them have access to the same 
> NFS-mounted source tree.  Is it practical to use the same tree for two 
> different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> be kept separate?  Or do I need to clean it out or copy it?
> 
> (by the way, I expect making packages for different Debian releases on 
> the same hardware architecture will require a new source tree, or a 
> cleaned-out one.  In my case they'll both be LINUXLIBC6)
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120519/5c7b0dfb/attachment-0002.html>

From peter.mckinna at gmail.com  Sun May 20 02:48:08 2012
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Sun, 20 May 2012 10:48:08 +1000
Subject: [M3devel] Linker override
Message-ID: <CAEy6uxqLdrGOydLBc=QgeB7Z5ZswOdYrsZL62D0i+cKC-9p9jw@mail.gmail.com>

Hi,

  I have had to override the default linker in my m3makefile to the
C++ linker to link
against a C++ library as in

SYSTEM_LD = "g++ -gstabs+ -m64 -fPIC -mno-align-double"

is there a more portable way to do this? I'm sure it wont work on windows!!

Peter


From jay.krell at cornell.edu  Sun May 20 03:31:16 2012
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 May 2012 01:31:16 +0000
Subject: [M3devel] Linker override
In-Reply-To: <CAEy6uxqLdrGOydLBc=QgeB7Z5ZswOdYrsZL62D0i+cKC-9p9jw@mail.gmail.com>
References: <CAEy6uxqLdrGOydLBc=QgeB7Z5ZswOdYrsZL62D0i+cKC-9p9jw@mail.gmail.com>
Message-ID: <COL101-W6496D86AAFB9672E062B10E61C0@phx.gbl>


I don't know what is the ideal design here.

Of course you can easily skip the code on Windows:

if equal(OS_TYPE, "POSIX")
? SYSTEM_LD = "g++ -gstabs+ -m64 -fPIC -mno-align-double"
end

There is no gcc vs. g++ analog on Windows. Good.

I know we could hack and slash at it gradually:

m3makefile:
?USE_GPLUSPLUS = TRUE? ?
?USE_CPLUSPLUS_LINKER = TRUE ?
?USE_CPLUSPLUS = TRUE ?


and then check that wherever in the config files.


There is a need for some sort of modularity / additivity here.
But I don't know what the design and interface should look like.

Most likely this notion of "use cplusplus" needs to be unioned across all libraries being linked together.


?- Jay




----------------------------------------
> Date: Sun, 20 May 2012 10:48:08 +1000
> From: peter.mckinna at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Linker override
>
> Hi,
>
> I have had to override the default linker in my m3makefile to the
> C++ linker to link
> against a C++ library as in
>
> SYSTEM_LD = "g++ -gstabs+ -m64 -fPIC -mno-align-double"
>
> is there a more portable way to do this? I'm sure it wont work on windows!!
>
> Peter
 		 	   		  

From dragisha at m3w.org  Sun May 20 22:09:46 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 20 May 2012 22:09:46 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <20120518172606.GB28507@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120516223123.GA25611@topoi.pooq.com>
	<COL101-W45E9B9ABD73C532DB661F4E6180@phx.gbl>
	<F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<20120518172606.GB28507@topoi.pooq.com>
Message-ID: <DE38D246-53B8-4105-9281-BC395B2E7920@m3w.org>


On May 18, 2012, at 7:26 PM, Hendrik Boom wrote:

> On Fri, May 18, 2012 at 06:58:26PM +0200, Dragi?a Duri? wrote:
>> One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.
> 
> It's possible to generate C code full of #line preprocessor commands, 
> so that debuggers get references to the original source code, not the 
> generated C code.  The variable names would possibly be obscure, 
> though.
> 
Exactly.

>> 
>> On May 17, 2012, at 1:40 AM, Jay K wrote:
>> 
>>>  But heck, really, if we generate C, then targets largely drop away.  
>> 



From dragisha at m3w.org  Sun May 20 22:11:39 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 20 May 2012 22:11:39 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W1466668864A79F0C274528E61E0@phx.gbl>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>,
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
Message-ID: <B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>


On May 18, 2012, at 9:49 PM, Jay K wrote:

> LLVM isn't a bad idea, but there is more expertise out there (and in me) with C and C++, so C and C++ are easier to generate.
> It is a bit of a chore to learn and use.
>  
>  
> JIT isn't a crazy idea either..or rather, an interpreter.
> If you look at parse.c..and you add a few thread locals..I think it's not hard to turn it into an interpreter.
>   (In reality you don't want to start with parse.c because of the GPL.)

LLVM and JIT are close enough. You do LLVM, you get JIT.

Also, for debugging we need DWARF. Not incompatible with LLVM. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/6048caf8/attachment-0002.html>

From jay.krell at cornell.edu  Sun May 20 23:28:27 2012
From: jay.krell at cornell.edu (Jay)
Date: Sun, 20 May 2012 14:28:27 -0700
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
Message-ID: <7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>

For dwarf et al: there "nothing" to it: "just" generate reasonable "code" (LLVM whatever, gcc "tree", C, etc) and the next level down handles it. Er, but for some bigger & smaller problems. 


Currently cm3cg -g for dwarf crashes. That is a small problem actually. But even if fixed, not a good experience -- no type information.


Larger "problem" & "good thing" is that the "front end" is more of a compiler than you might expect. It does "low level" things like "layout" and generates "variable plus offset" references "instead of" "field accesses".


That isn't necessarily bad. It is why/how we get away with giving gcc so little type information though.
And it might otherwise hurt debugging.


But ok. I have some ideas & plans, & some procrastination-enabling diversions.


 1. Update to gcc 4.6. Making good progress recently. This buys nothing. Procrastination.
 2. Update to gcc 4.7. Ditto.


Then there are a few more valuable things to get on to.


A. Better type info for gcc, so stock gdb much more useful. I'll probably NOT do this.


B. Use LLVM. I probably won't. But if there is a C-backend, then maybe, as that accomplishes two things at once (newer?better?cleaner?faster backend, portable C distribution)


C. Remove jmpbuf size knowledge from front end.
C.1 and maybe word size
C.2 and maybe endian
I.e. remove target dependentness


D. cooperative suspend 
i.e. again drastically increase portability


E. A C-generating backend.


The idea is, if these are all done, the system becomes "automatically" portable to "all" systems, with a pretty broad definition of "all": having a C?C++ compiler, being Posix but not too fancy (pthreads/open/read/write/close/send/recv/fork/exec, but nothing signal/semaphore related nor extensions to direct suspend threads or get stack pointer), or Win32, and optionally X Windows. 
At that point, time permitting, I might try again AIX, OpenVMS, Irix, iPhone/iPad, etc.


The remaining nagging portability concerns would be just: systems without public C compiler (windows phone, browser), and getting the second stack pointer on Itanium.


AT that point, if we ever get there, backends targeting Java, C#, JavaScript become maybe interesting (threads in JavaScript??). & the project could be considered very much more done. Maybe write other integrated backends, or linker, or target kernel interfaces instead of libc (esp. regarding threads on Linux)


Other projects at that time could include better interop between C, C++, and Modula-3. I'd like to see an end to fragile hand-written interop.


It'd also be good to move Trestle to the new X C bindings (xcb?).


I need to go back & explain something. Normally gcc compilers don't know anything about debug formats: stabs, coff, dwarf, etc. The reason cm3cg is different because what it does is mostly ignore all debugging infrastructure and generate its own custom information, for consumption by associated custom code in m3gdb. It just uses stabs as container or transport, for arbitrary data.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 20, 2012, at 1:11 PM, Dragi?a Duri? <dragisha at m3w.org> wrote:

> 
> On May 18, 2012, at 9:49 PM, Jay K wrote:
> 
>> LLVM isn't a bad idea, but there is more expertise out there (and in me) with C and C++, so C and C++ are easier to generate.
>> It is a bit of a chore to learn and use.
>>  
>>  
>> JIT isn't a crazy idea either..or rather, an interpreter.
>> If you look at parse.c..and you add a few thread locals..I think it's not hard to turn it into an interpreter.
>>   (In reality you don't want to start with parse.c because of the GPL.)
> 
> LLVM and JIT are close enough. You do LLVM, you get JIT.
> 
> Also, for debugging we need DWARF. Not incompatible with LLVM. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/57a5410d/attachment-0002.html>

From jay.krell at cornell.edu  Sun May 20 23:34:20 2012
From: jay.krell at cornell.edu (Jay)
Date: Sun, 20 May 2012 14:34:20 -0700
Subject: [M3devel] more Debian packages?
In-Reply-To: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>
References: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>
Message-ID: <05B9609B-9A70-405A-9A59-4D3896AAD28F@gmail.com>

No Daniel. 

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 19, 2012, at 11:32 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
>  I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,
> for instance to allow and or LINUX_I8086, etc LINUX_I387 
> For VAXen computers:
> VMS_VAX__
> for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11
> Alpha's: OSF_ALPHA
> For Unixes:
> FBSD-GENERIC_I_86___--
> To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64
> Also could be managed by Manufacturer Model code-name, like
> DEC_AQUARIUS or DEC_10000.
> 
> Also if we are gonna take macro assembly for cross-platform distributions then, we would need  something akin:
> NT_XASM-I_86___
> So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)
> 
> This would allow to compile CVSup at least is what one would like to
> Thanks in advance
> 
> --- El vie, 18/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] more Debian packages?
> Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 18 de mayo, 2012 16:50
> 
> Yes and yes.
> LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.
> But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.
>  
>  
> Please try to use I386_LINUX.
> I really want to stop this LINUXLIBC6 stuff...
>  
>  
>  You can share the source.
>  But we also have outputs in the source tree (unfortunately!).
>     You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...
>  
>  
>  Do this to switch:
>  
>  ./do-cm3-all.py realclean 
>  
>  - Jay
>  
> > Date: Fri, 18 May 2012 16:56:49 -0400
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] more Debian packages?
> > 
> > Having succeeded at producing a binary .deb packages for Debian squeeze 
> > (though I still have to try it out), I'm now looking at my other 
> > machines. I have a 32-bit Intel machine with wheeze (testing), and one 
> > that can run squeeze (stable). All of them have access to the same 
> > NFS-mounted source tree. Is it practical to use the same tree for two 
> > different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> > be kept separate? Or do I need to clean it out or copy it?
> > 
> > (by the way, I expect making packages for different Debian releases on 
> > the same hardware architecture will require a new source tree, or a 
> > cleaned-out one. In my case they'll both be LINUXLIBC6)
> > 
> > -- hendrik
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/9edf6c44/attachment-0002.html>

From jay.krell at cornell.edu  Sun May 20 23:32:14 2012
From: jay.krell at cornell.edu (Jay)
Date: Sun, 20 May 2012 14:32:14 -0700
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
Message-ID: <C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>

I meant "gcc frontends", which Modula-3 is structured as, in a somewhat backward-seeming way.


Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 20, 2012, at 2:28 PM, Jay <jay.krell at cornell.edu> wrote:

> Normally gcc compilers


From jay.krell at cornell.edu  Sun May 20 23:43:52 2012
From: jay.krell at cornell.edu (Jay)
Date: Sun, 20 May 2012 14:43:52 -0700
Subject: [M3devel] more Debian packages?
In-Reply-To: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>
References: <1337452330.61657.YahooMailClassic@web29703.mail.ird.yahoo.com>
Message-ID: <B05C5D37-CAE3-4271-80EF-EBB2627444D4@gmail.com>

No no no.
We will not have an explosion of targets like this. We hopefully will have a drastic reduction.
Processor: C or C++
Threads: pthreads or Win32 or maybe ucontext or setjmp
GUI: X Windows or Win32 or none or maybe other
Suspension: cooperative and probably no other


If the right level of #ifdef and/or autoconf and/or libtool use can makes its way into the "object code", maybe just target completely. (imagine one C source distribution for ALL targets and what that requires).
We have rather replaced autoconf & libtool with our carefully researched & written quake code, for better & worse & I am torn as to if this is a good thing. Autoconf & libtool are slow & obscure but ubiquitous, get the job done, are actively maintained by others.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 19, 2012, at 11:32 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
>  I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,
> for instance to allow and or LINUX_I8086, etc LINUX_I387 
> For VAXen computers:
> VMS_VAX__
> for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11
> Alpha's: OSF_ALPHA
> For Unixes:
> FBSD-GENERIC_I_86___--
> To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64
> Also could be managed by Manufacturer Model code-name, like
> DEC_AQUARIUS or DEC_10000.
> 
> Also if we are gonna take macro assembly for cross-platform distributions then, we would need  something akin:
> NT_XASM-I_86___
> So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)
> 
> This would allow to compile CVSup at least is what one would like to
> Thanks in advance
> 
> --- El vie, 18/5/12, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] more Debian packages?
> Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 18 de mayo, 2012 16:50
> 
> Yes and yes.
> LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.
> But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.
>  
>  
> Please try to use I386_LINUX.
> I really want to stop this LINUXLIBC6 stuff...
>  
>  
>  You can share the source.
>  But we also have outputs in the source tree (unfortunately!).
>     You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...
>  
>  
>  Do this to switch:
>  
>  ./do-cm3-all.py realclean 
>  
>  - Jay
>  
> > Date: Fri, 18 May 2012 16:56:49 -0400
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] more Debian packages?
> > 
> > Having succeeded at producing a binary .deb packages for Debian squeeze 
> > (though I still have to try it out), I'm now looking at my other 
> > machines. I have a 32-bit Intel machine with wheeze (testing), and one 
> > that can run squeeze (stable). All of them have access to the same 
> > NFS-mounted source tree. Is it practical to use the same tree for two 
> > different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> > be kept separate? Or do I need to clean it out or copy it?
> > 
> > (by the way, I expect making packages for different Debian releases on 
> > the same hardware architecture will require a new source tree, or a 
> > cleaned-out one. In my case they'll both be LINUXLIBC6)
> > 
> > -- hendrik
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/5fe49c86/attachment-0002.html>

From dabenavidesd at yahoo.es  Mon May 21 01:25:38 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 21 May 2012 00:25:38 +0100 (BST)
Subject: [M3devel] more Debian packages?
In-Reply-To: <B05C5D37-CAE3-4271-80EF-EBB2627444D4@gmail.com>
Message-ID: <1337556338.98126.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I got your point, but even after that the need for product-quality inter-opeartion with C code, specially, because everything else in the market is C, is desperately needed, we don't have some framework to actually using code from C-RT as is. I know DEC somehow lacked more effort towards producing for us that, although C interoperability was very good, they studied the problem for C and Modula-3, which is nice, and also I think they worked in their GEM compiler for Fortran, Cobol, C, .. so they should used basic concepts like 'program cell' for those compilers.
That said I know of an incremental code generator and linker for typeful programming languages for database machines, so I know producing some compiler target wouldn't be hard so much work like currently we had to even when there are many languages that we would match, say SQL, etc. 

Thanks in advance

--- El dom, 20/5/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] more Debian packages?
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "<hendrik at topoi.pooq.com>" <hendrik at topoi.pooq.com>, "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: domingo, 20 de mayo, 2012 16:43

No no no.We will not have an explosion of targets like this. We hopefully will have a drastic reduction.Processor: C or C++Threads: pthreads or Win32 or maybe ucontext or setjmpGUI: X Windows or Win32 or none or maybe otherSuspension: cooperative and probably no other

If the right level of #ifdef and/or autoconf and/or libtool use can makes its way into the "object code", maybe just target completely. (imagine one C source distribution for ALL targets and what that requires).We have rather replaced autoconf & libtool with our carefully researched & written quake code, for better & worse & I am torn as to if this is a good thing. Autoconf & libtool are slow & obscure but ubiquitous, get the job done, are actively maintained by others.

?- Jay (briefly/pocket-sized-computer-aka-phone)
On May 19, 2012, at 11:32 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:

?I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,

for instance to allow and or LINUX_I8086, etc LINUX_I387 

For VAXen computers:

VMS_VAX__

for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11

Alpha's: OSF_ALPHA

For Unixes:

FBSD-GENERIC_I_86___--

To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64

Also could be managed by Manufacturer Model code-name, like

DEC_AQUARIUS or DEC_10000.



Also if we are gonna take macro assembly for cross-platform distributions then, we would need? something akin:

NT_XASM-I_86___

So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)

This would allow to compile CVSup at least is what one would like to
Thanks in advance

 --- El vie, 18/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] more Debian packages?
Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 18 de mayo, 2012 16:50




Yes and yes.
LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.
But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.
?
?
Please try to use I386_LINUX.
I really want to stop this LINUXLIBC6 stuff...
?
?
?You can share the source.
?But we also have outputs in the source tree (unfortunately!).
??? You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...
?
?
?Do this to switch:
?
?./do-cm3-all.py realclean 
?
?- Jay
?
> Date: Fri, 18 May 2012 16:56:49 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] more Debian packages?
> 
> Having succeeded at producing a binary .deb packages for Debian squeeze 
> (though I still have to try it out), I'm now looking at my other 
> machines.  I have a 32-bit Intel machine with wheeze (testing), and one 
> that can run squeeze (stable).  All of them have access to the same 
> NFS-mounted source tree.  Is it practical to use the same tree for two 
> different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> be kept separate?  Or do I need to clean it out or copy it?
> 
> (by the way, I expect making packages for different Debian releases on 
> the same hardware architecture will require a new source tree, or a 
> cleaned-out one.  In my case they'll
 both be LINUXLIBC6)
> 
> -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120521/976f78b7/attachment-0002.html>

From jay.krell at cornell.edu  Mon May 21 09:50:49 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 May 2012 07:50:49 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>,
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>,
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
Message-ID: <COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>


My point was a bit different -- an interpreter could easily be built from the current intermediate representation.
But heck, then again, the frontend is fast..build an interpreter over source?
Well..hm..actually it might not be fast enough.
This gets rambly/philosophical fast...static checking is useful, but when do you do it?
"static and dynamic are relative".
Before the program runs? Every time before it runs?
When/where do you "save away" decisions/checks that have been made, to avoid them on repeat visits?

Nevermind..I'm not making a clear point..


?- Jay

________________________________
> Subject: Re: [M3devel] LINUXLIBC6 
> From: dragisha at m3w.org 
> Date: Sun, 20 May 2012 22:11:39 +0200 
> CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com 
> To: jay.krell at cornell.edu 
>  
>  
> On May 18, 2012, at 9:49 PM, Jay K wrote: 
>  
> LLVM isn't a bad idea, but there is more expertise out there (and in  
> me) with C and C++, so C and C++ are easier to generate. 
> It is a bit of a chore to learn and use. 
>  
>  
> JIT isn't a crazy idea either..or rather, an interpreter. 
> If you look at parse.c..and you add a few thread locals..I think it's  
> not hard to turn it into an interpreter. 
>    (In reality you don't want to start with parse.c because of the GPL.) 
>  
> LLVM and JIT are close enough. You do LLVM, you get JIT. 
>  
> Also, for debugging we need DWARF. Not incompatible with LLVM. 
 		 	   		  

From dragisha at m3w.org  Mon May 21 10:00:04 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 21 May 2012 10:00:04 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
	<C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>
Message-ID: <08D7AEDF-8B13-4139-B059-4EC66975AD9B@m3w.org>

And why would you/we do it? To be less portable? To escape direct knowledge of endian/word_size/jmpbuf/whatever by cpp and run into C/C++/Java?


On May 20, 2012, at 11:32 PM, Jay wrote:

> I meant "gcc frontends", which Modula-3 is structured as, in a somewhat backward-seeming way.
> 
> 
> Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.
> 
> 
> - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On May 20, 2012, at 2:28 PM, Jay <jay.krell at cornell.edu> wrote:
> 
>> Normally gcc compilers



From dragisha at m3w.org  Mon May 21 10:02:11 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 21 May 2012 10:02:11 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
Message-ID: <721848E0-B0C2-4C51-BD37-1A4BA9A58E7C@m3w.org>

You can't generate reasonable stabs based debug info and expect it to survive optimization steps. DWARF is another thing, optimizer gets data to work on, as well as code. DWARF decorations have a chance to survive optimizations. Stabs, esp heavily idiosyncratic ones - do not.

On May 20, 2012, at 11:28 PM, Jay wrote:

> For dwarf et al: there "nothing" to it: "just" generate reasonable "code" (LLVM whatever, gcc "tree", C, etc) and the next level down handles it. Er, but for some bigger & smaller problems. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120521/04223a33/attachment-0002.html>

From jay.krell at cornell.edu  Mon May 21 10:38:37 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 May 2012 08:38:37 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <721848E0-B0C2-4C51-BD37-1A4BA9A58E7C@m3w.org>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>,
	<721848E0-B0C2-4C51-BD37-1A4BA9A58E7C@m3w.org>
Message-ID: <COL101-W588C5940AE8A443065C0C9E61D0@phx.gbl>


Again, stabs in the context of Modula-3/cm3cg/m3gdb I believe has almost nothing to do with stabs in any other "normal" context.
We use it just to transport our own custom data.
That data may or may not be compromised by optimization.


For example, what are the types of parameters to functions?
Assuming the optimizer does not change the signature of any function?


This data is NOT available at all to stock gdb for Modula-3.
It is available to m3gdb via a completely custom/private data form.


And by "types" here, I mean pretty complete information -- if records are involved,
then all their fields are described.


It is likely the case that on systems that don't support stabs (MacOSX/Darwin), the custom data
could be transported via some other mechanism. Heck, put it in data files on the side.


ok ok, the data does have *something* to do with stabs, but not much.
e.g. that function signature is associated with a function at some address/offset.


Line number information is presumably represented in dwarf/stabs/coff "natively" via gcc's normal paths,
as we do give gcc source line information (at least mostly).


It is when you go beyond mere line number information where things are different.


?- Jay



________________________________
> Subject: Re: [M3devel] LINUXLIBC6 
> From: dragisha at m3w.org 
> Date: Mon, 21 May 2012 10:02:11 +0200 
> CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com 
> To: jay.krell at cornell.edu 
>  
> You can't generate reasonable stabs based debug info and expect it to  
> survive optimization steps. DWARF is another thing, optimizer gets data  
> to work on, as well as code. DWARF decorations have a chance to survive  
> optimizations. Stabs, esp heavily idiosyncratic ones - do not. 
>  
> On May 20, 2012, at 11:28 PM, Jay wrote: 
>  
> For dwarf et al: there "nothing" to it: "just" generate reasonable  
> "code" (LLVM whatever, gcc "tree", C, etc) and the next level down  
> handles it. Er, but for some bigger & smaller problems. 
>  
 		 	   		  

From jay.krell at cornell.edu  Mon May 21 10:40:25 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 May 2012 08:40:25 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <08D7AEDF-8B13-4139-B059-4EC66975AD9B@m3w.org>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
	<C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>,
	<08D7AEDF-8B13-4139-B059-4EC66975AD9B@m3w.org>
Message-ID: <COL101-W25AC411E4510D3BE846C95E61D0@phx.gbl>


To be more portable, and get out of the "problem" of being self-hosting.
I realize self-hosting has major benefits too.
Someone just needs to see if Debian et. al. have a general story for compilers that compile themselves.
And I need to really implement the C backend I talk forever and ever about....


?- Jay


----------------------------------------
> Subject: Re: [M3devel] LINUXLIBC6
> From: dragisha at m3w.org
> Date: Mon, 21 May 2012 10:00:04 +0200
> CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> And why would you/we do it? To be less portable? To escape direct knowledge of endian/word_size/jmpbuf/whatever by cpp and run into C/C++/Java?
>
>
> On May 20, 2012, at 11:32 PM, Jay wrote:
>
> > I meant "gcc frontends", which Modula-3 is structured as, in a somewhat backward-seeming way.
> >
> >
> > Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.
> >
> >
> > - Jay (briefly/pocket-sized-computer-aka-phone)
> >
> > On May 20, 2012, at 2:28 PM, Jay <jay.krell at cornell.edu> wrote:
> >
> >> Normally gcc compilers
>
 		 	   		  

From dragisha at m3w.org  Mon May 21 13:17:44 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 21 May 2012 13:17:44 +0200
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W25AC411E4510D3BE846C95E61D0@phx.gbl>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
	<C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>,
	<08D7AEDF-8B13-4139-B059-4EC66975AD9B@m3w.org>
	<COL101-W25AC411E4510D3BE846C95E61D0@phx.gbl>
Message-ID: <1CDC02DA-54C1-43ED-9737-4BCA39C4E87B@m3w.org>

Once it was a big thing for Modula-3 to become self-hosted.

Now, step forward is to undo that :).

I understand - you feel better with (well known and full commanded) C/C++ than with (mostly unknown LLVM). I only hope you will use current provisions of Modula-3 system to implement C/C++ backend in same fashion (using CG* object hierarchy) as other current backends are implemented. That way, someone can go LLVM without changing GCC based backend, or fast Win32 backend, or your future C/C++ backend.

On May 21, 2012, at 10:40 AM, Jay K wrote:

> 
> To be more portable, and get out of the "problem" of being self-hosting.
> I realize self-hosting has major benefits too.
> Someone just needs to see if Debian et. al. have a general story for compilers that compile themselves.
> And I need to really implement the C backend I talk forever and ever about....
> 
> 
>  - Jay
> 
> 
> ----------------------------------------
>> Subject: Re: [M3devel] LINUXLIBC6
>> From: dragisha at m3w.org
>> Date: Mon, 21 May 2012 10:00:04 +0200
>> CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> And why would you/we do it? To be less portable? To escape direct knowledge of endian/word_size/jmpbuf/whatever by cpp and run into C/C++/Java?
>> 
>> 
>> On May 20, 2012, at 11:32 PM, Jay wrote:
>> 
>>> I meant "gcc frontends", which Modula-3 is structured as, in a somewhat backward-seeming way.
>>> 
>>> 
>>> Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.
>>> 
>>> 
>>> - Jay (briefly/pocket-sized-computer-aka-phone)
>>> 
>>> On May 20, 2012, at 2:28 PM, Jay <jay.krell at cornell.edu> wrote:
>>> 
>>>> Normally gcc compilers
>> 
> 		 	   		  



From hendrik at topoi.pooq.com  Mon May 21 20:43:17 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 14:43:17 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
Message-ID: <20120521184316.GA10750@topoi.pooq.com>

On Mon, May 21, 2012 at 07:50:49AM +0000, Jay K wrote:
> 
> Nevermind..I'm not making a clear point..

Maybe this point will do:

So regardless of whether the production compiler generates machine code 
or anythine else, it would be possible to have a single, portable 
interpreter written in C to use as a bootstrap tool to avoid having to 
bootstrap from machine-dependent machine code whenever installing (or 
packaging) foor another platform?  The build-dependency of the real 
Modula 3 compiler could then be itself OR the interpreter.

And the interpreter could be made to interpret some kind of efficient, 
intermediate code that is easy to interpret fast.  Does the existing 
codebase have anything that sould be used for this?  OR could easily be 
changed into this?

-- hendrik


From hendrik at topoi.pooq.com  Mon May 21 23:10:45 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 17:10:45 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <20120521184316.GA10750@topoi.pooq.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
	<20120521184316.GA10750@topoi.pooq.com>
Message-ID: <20120521211045.GA7596@topoi.pooq.com>

On Mon, May 21, 2012 at 02:43:17PM -0400, Hendrik Boom wrote:
> On Mon, May 21, 2012 at 07:50:49AM +0000, Jay K wrote:
> > 
> > Nevermind..I'm not making a clear point..
> 
> Maybe this point will do:
> 
> So regardless of whether the production compiler generates machine code 
> or anythine else, it would be possible to have a single, portable 
> interpreter written in C to use as a bootstrap tool to avoid having to 
> bootstrap from machine-dependent machine code whenever installing (or 
> packaging) foor another platform?  The build-dependency of the real 
> Modula 3 compiler could then be itself OR the interpreter.
> 
> And the interpreter could be made to interpret some kind of efficient, 
> intermediate code that is easy to interpret fast.  Does the existing 
> codebase have anything that sould be used for this?  OR could easily be 
> changed into this?
> 
> -- hendrik

C--, I believe, is implemented as a compiler for several platforms, and 
also as an interpreter.  So generating C-- code would satisfy our 
requirements for a bootstrap.  If we want to hook into a run-time 
system that has at least thought seriously about the issues of 
garbage-collection and stack-walking, this might be it.  But I don't 
know to what extent these essential features have beein implemented. 

OCAML also had an interpreter and compilers to several machine codes.  
This would seem to be a viable mechanism.

I've been using an OCAML-written Algol W compiler using the interpreted 
OCAML implementation, and it still compiles Algol W to C faster than 
the C compiler translates its output code to machine code. 

-- hendrik




From jay.krell at cornell.edu  Tue May 22 00:50:44 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 May 2012 22:50:44 +0000
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <20120521211045.GA7596@topoi.pooq.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>,
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>,
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>,
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>,
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>,
	<20120521184316.GA10750@topoi.pooq.com>,
	<20120521211045.GA7596@topoi.pooq.com>
Message-ID: <COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>


Is C-- adequately maintained? I don't think so.
I'm also not super keen on depending on other projects.
We'll see..


Regarding runtime designed for garbage collection... in the interest of simplicity, correctness,
and laziness-ignoring-performance, I'd initially try something like this:

?- don't optimize, or at least make all writes volatile 
?? or make everything volatile 
While currently we have some support for the gcc optimizer, and we don't make everything volatile,
we also had a long history of using a lot of volatile. I think nobody but me and possibly Tony
noticed the poor codegen and probably
?
?- form all frames as structs 
? - so that the frame layout can be known by the frontend


We already do something similar to the last, I think.


One of the wierd points here..and I really really really really have to get on and code instead of talk,
is "what our C would look like".
It would look strange.


Consider all the inserted "probes" (I forget what they are called).
Consider as I said that there are no field references from the backend's point of view, just variable + offset + cast.


Anyway..later...


?- Jay



----------------------------------------
> Date: Mon, 21 May 2012 17:10:45 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] LINUXLIBC6
>
> On Mon, May 21, 2012 at 02:43:17PM -0400, Hendrik Boom wrote:
> > On Mon, May 21, 2012 at 07:50:49AM +0000, Jay K wrote:
> > >
> > > Nevermind..I'm not making a clear point..
> >
> > Maybe this point will do:
> >
> > So regardless of whether the production compiler generates machine code
> > or anythine else, it would be possible to have a single, portable
> > interpreter written in C to use as a bootstrap tool to avoid having to
> > bootstrap from machine-dependent machine code whenever installing (or
> > packaging) foor another platform? The build-dependency of the real
> > Modula 3 compiler could then be itself OR the interpreter.
> >
> > And the interpreter could be made to interpret some kind of efficient,
> > intermediate code that is easy to interpret fast. Does the existing
> > codebase have anything that sould be used for this? OR could easily be
> > changed into this?
> >
> > -- hendrik
>
> C--, I believe, is implemented as a compiler for several platforms, and
> also as an interpreter. So generating C-- code would satisfy our
> requirements for a bootstrap. If we want to hook into a run-time
> system that has at least thought seriously about the issues of
> garbage-collection and stack-walking, this might be it. But I don't
> know to what extent these essential features have beein implemented.
>
> OCAML also had an interpreter and compilers to several machine codes.
> This would seem to be a viable mechanism.
>
> I've been using an OCAML-written Algol W compiler using the interpreted
> OCAML implementation, and it still compiles Algol W to C faster than
> the C compiler translates its output code to machine code.
>
> -- hendrik
>
>
 		 	   		  

From dabenavidesd at yahoo.es  Tue May 22 02:47:59 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 22 May 2012 01:47:59 +0100 (BST)
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
Message-ID: <1337647679.52945.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all: 
none interpreter product I have seen lately, that tries such a way C, I know there was a product of 25+ years called C-terp, but they don't do it anymore.  
I don't think they just tried to debug code and safely execute but execute it safely and prudently fast but none else have seemingly been keen to that, so if they thought was a good idea way before all this, I guess we can try to do that. Seems a good one. Which compiler does that, just C--?
They distributed some gcc freely and had MS VS4 versions and all of that.
Thanks in advance


--- El lun, 21/5/12, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] LINUXLIBC6
> Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 21 de mayo, 2012 17:50
> 
> Is C-- adequately maintained? I don't think so.
> I'm also not super keen on depending on other projects.
> We'll see..
> 
> 
> Regarding runtime designed for garbage collection... in the
> interest of simplicity, correctness,
> and laziness-ignoring-performance, I'd initially try
> something like this:
> 
> ?- don't optimize, or at least make all writes volatile 
> ?? or make everything volatile 
> While currently we have some support for the gcc optimizer,
> and we don't make everything volatile,
> we also had a long history of using a lot of volatile. I
> think nobody but me and possibly Tony
> noticed the poor codegen and probably
> ?
> ?- form all frames as structs 
> ? - so that the frame layout can be known by the frontend
> 
> 
> We already do something similar to the last, I think.
> 
> 
> One of the wierd points here..and I really really really
> really have to get on and code instead of talk,
> is "what our C would look like".
> It would look strange.
> 
> 
> Consider all the inserted "probes" (I forget what they are
> called).
> Consider as I said that there are no field references from
> the backend's point of view, just variable + offset + cast.
> 
> 
> Anyway..later...
> 
> 
> ?- Jay
> 
> 
> 
> ----------------------------------------
> > Date: Mon, 21 May 2012 17:10:45 -0400
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] LINUXLIBC6
> >
> > On Mon, May 21, 2012 at 02:43:17PM -0400, Hendrik Boom
> wrote:
> > > On Mon, May 21, 2012 at 07:50:49AM +0000, Jay K
> wrote:
> > > >
> > > > Nevermind..I'm not making a clear point..
> > >
> > > Maybe this point will do:
> > >
> > > So regardless of whether the production compiler
> generates machine code
> > > or anythine else, it would be possible to have a
> single, portable
> > > interpreter written in C to use as a bootstrap
> tool to avoid having to
> > > bootstrap from machine-dependent machine code
> whenever installing (or
> > > packaging) foor another platform? The
> build-dependency of the real
> > > Modula 3 compiler could then be itself OR the
> interpreter.
> > >
> > > And the interpreter could be made to interpret
> some kind of efficient,
> > > intermediate code that is easy to interpret fast.
> Does the existing
> > > codebase have anything that sould be used for
> this? OR could easily be
> > > changed into this?
> > >
> > > -- hendrik
> >
> > C--, I believe, is implemented as a compiler for
> several platforms, and
> > also as an interpreter. So generating C-- code would
> satisfy our
> > requirements for a bootstrap. If we want to hook into a
> run-time
> > system that has at least thought seriously about the
> issues of
> > garbage-collection and stack-walking, this might be it.
> But I don't
> > know to what extent these essential features have beein
> implemented.
> >
> > OCAML also had an interpreter and compilers to several
> machine codes.
> > This would seem to be a viable mechanism.
> >
> > I've been using an OCAML-written Algol W compiler using
> the interpreted
> > OCAML implementation, and it still compiles Algol W to
> C faster than
> > the C compiler translates its output code to machine
> code.
> >
> > -- hendrik
> >
> >
>  ???
> ????????
> ?????? ???
> ? 


From hendrik at topoi.pooq.com  Tue May 22 04:44:55 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 22:44:55 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
	<20120521184316.GA10750@topoi.pooq.com>
	<20120521211045.GA7596@topoi.pooq.com>
	<COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
Message-ID: <20120522024455.GA9667@topoi.pooq.com>

On Mon, May 21, 2012 at 10:50:44PM +0000, Jay K wrote:
> 
> Is C-- adequately maintained? I don't think so.

Bugs get fixed.  And there's very few of them reported.  But it's not 
clear to me whether that's because it's so well-written, or because 
almost no one uses it.

Active development seems to be at a stendstill.

> I'm also not super keen on depending on other projects.
> We'll see..

I mentioned C-- because its implementation exists in both interpreted 
and compiled versions.  That seems to be a way to bootstrap the whole 
thing.  We could interpret the compiler using some portable 
intermediate code -- we could even restrict the interpreter to provide 
only a 32-bit machine, and then cross-compile from the interpreted 
compiler to whatever machine we're installing on.  Since every Modula 
3 compiler seems to be able to generate code for every platform, 
this is a way to avoid having a separate binary bootstrap for every 
platform.

And a distro, like Debian, could have a source package that doesn't 
need to have itself installed before it it can be installed.

-- hendrik

> 
> 
> Regarding runtime designed for garbage collection... in the interest of simplicity, correctness,
> and laziness-ignoring-performance, I'd initially try something like this:
> 
> ?- don't optimize, or at least make all writes volatile 
> ?? or make everything volatile 
> While currently we have some support for the gcc optimizer, and we don't make everything volatile,
> we also had a long history of using a lot of volatile. I think nobody but me and possibly Tony
> noticed the poor codegen and probably
> ?
> ?- form all frames as structs 
> ? - so that the frame layout can be known by the frontend
>
> 
> 
> We already do something similar to the last, I think.
> 
> 
> One of the wierd points here..and I really really really really have to get on and code instead of talk,
> is "what our C would look like".
> It would look strange.
> 
> 
> Consider all the inserted "probes" (I forget what they are called).
> Consider as I said that there are no field references from the 
> backend's point of view, just variable + offset + cast.

That's basically the  way that C-- accesses memory.

-- hendrik


From hendrik at topoi.pooq.com  Tue May 22 04:57:50 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 22:57:50 -0400
Subject: [M3devel] LINUXLIBC6
In-Reply-To: <1337647679.52945.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
	<1337647679.52945.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <20120522025750.GB9667@topoi.pooq.com>

On Tue, May 22, 2012 at 01:47:59AM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all: 
> none interpreter product I have seen lately, that tries such a way C, I know there was a product of 25+ years called C-terp, but they don't do it anymore.  
> I don't think they just tried to debug code and safely execute but execute it safely and prudently fast but none else have seemingly been keen to that, so if they thought was a good idea way before all this, I guess we can try to do that. Seems a good one. Which compiler does that, just C--?

I think OCaml did an interpreter-compiler combination, whhere one 
could be used to implement the other.  Though I'm not sure.

I worked on C and C++ interpreters once.  All proprietary, 
unfortunately.

Gambit-C is a compiler from Scheme to C.  It's written in its own 
language, and it also provides an interpreter for its own language,
also written in Scheme and compiled to C, I believe.  It manages to do 
an efficient implementation of continuations despite running in C.

> They distributed some gcc freely and had MS VS4 versions and all of that.
> Thanks in advance

-- hendrik


From hendrik at topoi.pooq.com  Tue May 22 05:32:16 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 21 May 2012 23:32:16 -0400
Subject: [M3devel] use of LLVM
In-Reply-To: <1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <20120522033216.GC9667@topoi.pooq.com>

On Fri, May 18, 2012 at 06:16:59PM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all:
> After ESC we do need much debugger at all, in fact it was designed for that for avoiding put much time on it.
> Still if we generate C is for super-optimization (but verified also mechanically), so I don't mind that, but for code quality I prefer C, I agree absolutely in that we should support it again for that purpose (as originally).
> As for not verified code we should stick with C--, as it is written for that purposes, but for portability specially with implicit safety.
> And for not verified nor optimal and not common use code (like mentor) we should make them source packages (in fact If they are written in Obliq we don't want to redistribute that as non-source), instead part of m3-demo package subdirectory or so.
> I think for M3CG is that we need a LLVM or so back-end for JIT.

The problem I had with LLVM for Algol 68 was that I couldn't use a type 
before it was completely defined.  THis means that there are stark 
constraints on the use of incomplete types.  I wanted to build a 
structure to represent a stack frame, containing local variables and 
the like, and having the field offsets afailable for type descriptors 
for the garbage collector.  But even though LLVM could have computed 
field offsets along the way, as they were contributed to the structure, 
instead it decided to diallow all use of the structure until its 
definition was complete.  UNfortunately, I didn't know what all the 
fields would be until I got to finish generating the code that used the 
stack frame.

This was a restriction in using LLVM as a JIT.  You get to build the 
LLVM abstract syntax in pretty well any order you want, sticking extra 
bits in here, there, everywhere, except for this one bizarre 
restriction.  I have to build all the abstract syntax for a type 
definition before I can refer to any of it elsewhere in the parse tree.  
Well, thare are a few exceptions for defining recursive types, but they 
don't do enough to make this work.

It's different when writing LLVM code as an ASCII text file.  Then you 
can write out the type definitions on one file and the code that uses 
then in an other file, and cocatenate them before passing them too 
LLVM.

Mind you that's not a lot worse than in C--, where you *have* to write 
out text file (and I do write it out of order).  But it irks to 
have the entire LLVM JIT interface reduced to uselessness.  At least 
with C-- you're not *expecting* to get a JIT.

-- hendrik


From dragisha at m3w.org  Tue May 22 10:59:24 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 22 May 2012 10:59:24 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
Message-ID: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>


***
*** runtime error:
***    <*ASSERT*> failed.
***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
***
...
#17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
    at ../src/thread/PTHREAD/ThreadPThread.m3:586
#18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
#19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
?

And so on? Looks like I reported this earlier, here: 

https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html

Any progress? Maybe I missed something.

dd




From lemming at henning-thielemann.de  Tue May 22 10:45:24 2012
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 22 May 2012 10:45:24 +0200 (CEST)
Subject: [M3devel] use of LLVM
In-Reply-To: <20120522033216.GC9667@topoi.pooq.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<20120522033216.GC9667@topoi.pooq.com>
Message-ID: <alpine.DEB.2.00.1205221044001.12948@anubis.informatik.uni-halle.de>


On Mon, 21 May 2012, Hendrik Boom wrote:

> The problem I had with LLVM for Algol 68 was that I couldn't use a type
> before it was completely defined.  THis means that there are stark
> constraints on the use of incomplete types.  I wanted to build a
> structure to represent a stack frame, containing local variables and
> the like, and having the field offsets afailable for type descriptors
> for the garbage collector.  But even though LLVM could have computed
> field offsets along the way, as they were contributed to the structure,
> instead it decided to diallow all use of the structure until its
> definition was complete.  UNfortunately, I didn't know what all the
> fields would be until I got to finish generating the code that used the
> stack frame.

I thought that you can disable pointer type checking completely by using 
i8* and cast it forth and back as you need it.


From dragisha at m3w.org  Tue May 22 17:16:30 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 22 May 2012 17:16:30 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
In-Reply-To: <E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
Message-ID: <16020041-89DE-47A7-AD6C-A04ECAB9991D@m3w.org>

This is 5.8.6 release code. You probably did not read a message I referenced.

On May 22, 2012, at 4:59 PM, Antony Hosking wrote:

> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
> 
> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
> 
>> 
>> ***
>> *** runtime error:
>> ***    <*ASSERT*> failed.
>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>> ***
>> ...
>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>   at ../src/thread/PTHREAD/ThreadPThread.m3:586
>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>> ?
>> 
>> And so on? Looks like I reported this earlier, here: 
>> 
>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>> 
>> Any progress? Maybe I missed something.
>> 
>> dd
>> 
>> 
> 



From dragisha at m3w.org  Tue May 22 17:23:31 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 22 May 2012 17:23:31 +0200
Subject: [M3devel]
 =?windows-1252?q?pthreads_problem=2C_LINUXLIBC6=2C_RHEL?=
 =?windows-1252?q?_5=2E8=85_random_observation?=
In-Reply-To: <16020041-89DE-47A7-AD6C-A04ECAB9991D@m3w.org>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
	<16020041-89DE-47A7-AD6C-A04ECAB9991D@m3w.org>
Message-ID: <D1D53D02-1EC9-4227-96DF-A245B5988F6A@m3w.org>

<* ASSERT r = 0 *>

is probably better as:

IF r # 0 THEN
  <* DEBUG "r = " & Fmt.Int? *>
  <* ASSERT FALSE *>
END;

On May 22, 2012, at 5:16 PM, Dragi?a Duri? wrote:

> This is 5.8.6 release code. You probably did not read a message I referenced.
> 
> On May 22, 2012, at 4:59 PM, Antony Hosking wrote:
> 
>> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
>> 
>> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
>> 
>>> 
>>> ***
>>> *** runtime error:
>>> ***    <*ASSERT*> failed.
>>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>>> ***
>>> ...
>>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>>  at ../src/thread/PTHREAD/ThreadPThread.m3:586
>>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>>> ?
>>> 
>>> And so on? Looks like I reported this earlier, here: 
>>> 
>>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>>> 
>>> Any progress? Maybe I missed something.
>>> 
>>> dd
>>> 
>>> 
>> 
> 



From hendrik at topoi.pooq.com  Tue May 22 17:56:51 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Tue, 22 May 2012 11:56:51 -0400
Subject: [M3devel] use of LLVM
In-Reply-To: <alpine.DEB.2.00.1205221044001.12948@anubis.informatik.uni-halle.de>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<20120522033216.GC9667@topoi.pooq.com>
	<alpine.DEB.2.00.1205221044001.12948@anubis.informatik.uni-halle.de>
Message-ID: <20120522155651.GA12326@topoi.pooq.com>

On Tue, May 22, 2012 at 10:45:24AM +0200, Henning Thielemann wrote:
> 
> On Mon, 21 May 2012, Hendrik Boom wrote:
> 
> >The problem I had with LLVM for Algol 68 was that I couldn't use a type
> >before it was completely defined.  THis means that there are stark
> >constraints on the use of incomplete types.  I wanted to build a
> >structure to represent a stack frame, containing local variables and
> >the like, and having the field offsets afailable for type descriptors
> >for the garbage collector.  But even though LLVM could have computed
> >field offsets along the way, as they were contributed to the structure,
> >instead it decided to diallow all use of the structure until its
> >definition was complete.  UNfortunately, I didn't know what all the
> >fields would be until I got to finish generating the code that used the
> >stack frame.
> 
> I thought that you can disable pointer type checking completely by
> using i8* and cast it forth and back as you need it.

But I still can't generate code that does anything more than mention 
these types until they are completely defined.  I can't make the 
abtstract syntax tree for sizeof(foo) before I've completed the 
definition of foo.  I can't mention any of the field names until I've 
completed the definition of foo....

Yes, i8* might get around some limitations, if I do all the field 
offset calculations myself and embed the numbers in the generated 
code.  But that's not how LLVM is supposed to work.  It's supposed to 
be rather more machine-independent than that.

-- hendrik


From dragisha at m3w.org  Tue May 22 18:20:35 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 22 May 2012 18:20:35 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
In-Reply-To: <39DE377C-56A0-4F0F-B459-1E8953F889B8@gmail.com>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
	<16020041-89DE-47A7-AD6C-A04ECAB9991D@m3w.org>
	<39DE377C-56A0-4F0F-B459-1E8953F889B8@gmail.com>
Message-ID: <F72BE040-3ABC-4FB0-8EC6-96C70A92FC39@m3w.org>

Probably :)

I just tried to rebuild cm3-5.8.6 on this system, from source. Same problem.

I will try some 5.9.* next.

Interim release would be good idea. If only we can have functional m3gdb? gcc version used is not priority, to me.

On May 22, 2012, at 5:43 PM, Antony Hosking wrote:

> The release contains a number of known problems.
> Time for an interim release?
> 
> 
> On May 22, 2012, at 11:16 AM, Dragi?a Duri? wrote:
> 
>> This is 5.8.6 release code. You probably did not read a message I referenced.
>> 
>> On May 22, 2012, at 4:59 PM, Antony Hosking wrote:
>> 
>>> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
>>> 
>>> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
>>> 
>>>> 
>>>> ***
>>>> *** runtime error:
>>>> ***    <*ASSERT*> failed.
>>>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>>>> ***
>>>> ...
>>>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>>> at ../src/thread/PTHREAD/ThreadPThread.m3:586
>>>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>>>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>>>> ?
>>>> 
>>>> And so on? Looks like I reported this earlier, here: 
>>>> 
>>>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>>>> 
>>>> Any progress? Maybe I missed something.
>>>> 
>>>> dd
>>>> 
>>>> 
>>> 
>> 
> 



From dragisha at m3w.org  Wed May 23 10:36:05 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 23 May 2012 10:36:05 +0200
Subject: [M3devel] cm3, NOPTHREAD
Message-ID: <9E51EE23-0A0E-459F-BC97-9CC447728A2A@m3w.org>

Anyone made cm3 with -DNOPTHREAD ? 5.8.6 release version.


From dragisha at m3w.org  Wed May 23 12:03:37 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 23 May 2012 12:03:37 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
In-Reply-To: <E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
Message-ID: <6FA05B91-4425-4164-8A08-B033920FE45E@m3w.org>

Return code in question is 22, EINVAL, code is

      WITH r = pthread_cond_timedwait(self.cond, self.mutex, until) DO
        IF r = Uerror.ETIMEDOUT THEN
          WITH r = pthread_mutex_unlock(self.mutex) DO <*ASSERT r=0*> END;
          IF perfOn THEN PerfRunning() END;
          RETURN;
        END;
        IF r # 0 THEN
          RTIO.PutText("r="); RTIO.PutInt(r); RTIO.PutText("\n");
          RTIO.Flush();
        END;
        <*ASSERT r=0*> --- former line 586

...
       The pthread_cond_timedwait() and pthread_cond_wait() functions may fail if:

       EINVAL The value specified by cond, mutex, or abstime is invalid.

       EINVAL Different  mutexes  were supplied for concurrent pthread_cond_timedwait() or pthread_cond_wait() operations on the
              same condition variable.

On May 22, 2012, at 4:59 PM, Antony Hosking wrote:

> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
> 
> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
> 
>> 
>> ***
>> *** runtime error:
>> ***    <*ASSERT*> failed.
>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>> ***
>> ...
>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>   at ../src/thread/PTHREAD/ThreadPThread.m3:586
>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>> ?
>> 
>> And so on? Looks like I reported this earlier, here: 
>> 
>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>> 
>> Any progress? Maybe I missed something.
>> 
>> dd
>> 
>> 
> 



From dragisha at m3w.org  Wed May 23 14:36:02 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 23 May 2012 14:36:02 +0200
Subject: [M3devel] pthreads problem, LINUXLIBC6, RHEL 5.8
In-Reply-To: <6FA05B91-4425-4164-8A08-B033920FE45E@m3w.org>
References: <73D59EB8-74F4-485B-A7AD-2DB87DD6CAA0@m3w.org>
	<E50EE2A2-0DB3-4093-A162-8B96DA9FFBA5@gmail.com>
	<6FA05B91-4425-4164-8A08-B033920FE45E@m3w.org>
Message-ID: <1CE45569-8335-4BFD-A08F-30D60A9EA18E@m3w.org>

Good news is: it was only range check error missing in generated code.

Input argument to Thread.Pause() was 1.0d9 (safe infinity idea on 64bit :)). When added to Time.Now(), it overflows 32bit component timespec. Negative components in timespec - EINVAL on pthread_cond_timedwait.

Good news II: No need for interim release because of this "bug". 

On May 23, 2012, at 12:03 PM, Dragi?a Duri? wrote:

> Return code in question is 22, EINVAL, code is
> 
>      WITH r = pthread_cond_timedwait(self.cond, self.mutex, until) DO
>        IF r = Uerror.ETIMEDOUT THEN
>          WITH r = pthread_mutex_unlock(self.mutex) DO <*ASSERT r=0*> END;
>          IF perfOn THEN PerfRunning() END;
>          RETURN;
>        END;
>        IF r # 0 THEN
>          RTIO.PutText("r="); RTIO.PutInt(r); RTIO.PutText("\n");
>          RTIO.Flush();
>        END;
>        <*ASSERT r=0*> --- former line 586
> 
> ...
>       The pthread_cond_timedwait() and pthread_cond_wait() functions may fail if:
> 
>       EINVAL The value specified by cond, mutex, or abstime is invalid.
> 
>       EINVAL Different  mutexes  were supplied for concurrent pthread_cond_timedwait() or pthread_cond_wait() operations on the
>              same condition variable.
> 
> On May 22, 2012, at 4:59 PM, Antony Hosking wrote:
> 
>> That looks like an old version of ThreadPThread.  In the current version I don?t see any code at line 595.
>> 
>> On May 22, 2012, at 4:59 AM, Dragi?a Duri? wrote:
>> 
>>> 
>>> ***
>>> *** runtime error:
>>> ***    <*ASSERT*> failed.
>>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 586
>>> ***
>>> ...
>>> #17 0x00ebd21d in ThreadPThread__XPause (M3_DMxDjQ_self=0x8052018, M3_CtKayy_n=1000000000, M3_AicXUJ_alertable=0 '\000')
>>>  at ../src/thread/PTHREAD/ThreadPThread.m3:586
>>> #18 0x00ebd287 in Thread__Pause (M3_CtKayy_n=1000000000) at ../src/thread/PTHREAD/ThreadPThread.m3:595
>>> #19 0x006e142f in XLModuleMain__Delay (M3_D6v54n_frame=0xb7ebf180, M3_AZx9O5_args=0xb7ec0e58) at ../src/modules/XLModuleMain.m3:213
>>> ?
>>> 
>>> And so on? Looks like I reported this earlier, here: 
>>> 
>>> https://mail.elegosoft.com/pipermail/m3devel/2011-April/008757.html
>>> 
>>> Any progress? Maybe I missed something.
>>> 
>>> dd
>>> 
>>> 
>> 
> 



From dabenavidesd at yahoo.es  Thu May 24 00:41:41 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 23 May 2012 23:41:41 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <9E51EE23-0A0E-459F-BC97-9CC447728A2A@m3w.org>
Message-ID: <1337812901.82672.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi:
What I remember is last release was done with switch, but before was built by that target so, I don't know, I think there isn't such now, maybe I'm wrong.
In the end, what is the difference for build time, none probably, so use what you build, or what do you want to build? 
Thanks in advance

--- El mi?, 23/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: [M3devel] cm3, NOPTHREAD
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 23 de mayo, 2012 03:36
> Anyone made cm3 with -DNOPTHREAD ?
> 5.8.6 release version.
> 


From jay.krell at cornell.edu  Thu May 24 01:07:46 2012
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 23 May 2012 23:07:46 +0000
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <1337812901.82672.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <9E51EE23-0A0E-459F-BC97-9CC447728A2A@m3w.org>,
	<1337812901.82672.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W464C8A70B5346462747BEBE6030@phx.gbl>


Do you mean did we make something "official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.  Do it yourself?  (Try out scripts/python/make-dist.py?)   It has always been easy from a m3makefile point of view to do it.You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.   - Jay
 > Date: Wed, 23 May 2012 23:41:41 +0100
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; dragisha at m3w.org
> Subject: Re: [M3devel] cm3, NOPTHREAD
> 
> Hi:
> What I remember is last release was done with switch, but before was built by that target so, I don't know, I think there isn't such now, maybe I'm wrong.
> In the end, what is the difference for build time, none probably, so use what you build, or what do you want to build? 
> Thanks in advance
> 
> --- El mi?, 23/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> > De: Dragi?a Duri? <dragisha at m3w.org>
> > Asunto: [M3devel] cm3, NOPTHREAD
> > Para: "m3devel" <m3devel at elegosoft.com>
> > Fecha: mi?rcoles, 23 de mayo, 2012 03:36
> > Anyone made cm3 with -DNOPTHREAD ?
> > 5.8.6 release version.
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120523/b4297d35/attachment-0002.html>

From dabenavidesd at yahoo.es  Thu May 24 01:31:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 24 May 2012 00:31:34 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <COL101-W464C8A70B5346462747BEBE6030@phx.gbl>
Message-ID: <1337815894.98672.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I was remembering that last release was able to switch, but proving the theory that something is better, I don't remember any reason rather than by broken builds, so that's why I say use what you have.
In my mind there is any reason for such target to be very different in compile time, perhaps in RT the GC may help something if so. But Dragisha wants to 'build', so I don't know.
Thanks in advance

--- El mi?, 23/5/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] cm3, NOPTHREAD
Para: dabenavidesd at yahoo.es, "m3devel" <m3devel at elegosoft.com>, dragisha at m3w.org
Fecha: mi?rcoles, 23 de mayo, 2012 18:07




Do you mean did we make something?"official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
?
?
Do it yourself?
? (Try out scripts/python/make-dist.py?) 
?
?
It has always been easy from a m3makefile point of view to do it.
You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.
?
?
?- Jay
?
> Date: Wed, 23 May 2012 23:41:41 +0100
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; dragisha at m3w.org
> Subject: Re: [M3devel] cm3, NOPTHREAD
> 
> Hi:
> What I remember is last release was done with switch, but before was built by that target so, I don't know, I think there isn't such now, maybe I'm wrong.
> In the end, what is the difference for build time, none probably, so use what you build, or what do you want to build? 
> Thanks in advance
> 
> --- El mi?, 23/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> > De: Dragi?a Duri? <dragisha at m3w.org>
> > Asunto: [M3devel] cm3, NOPTHREAD
> > Para: "m3devel" <m3devel at elegosoft.com>
> > Fecha: mi?rcoles, 23 de mayo, 2012 03:36
> > Anyone made cm3 with -DNOPTHREAD ?
> > 5.8.6 release version.
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120524/5e996ec2/attachment-0002.html>

From dragisha at m3w.org  Thu May 24 10:43:41 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 24 May 2012 10:43:41 +0200
Subject: [M3devel] cm3, NOPTHREAD
Message-ID: <F2C6F642-0ED9-4A79-9E67-256DAE06EB64@m3w.org>

I did

export BUILDARGS="-DNOPTHREAD"

before building packages/compiler.

Didn't work. Built cm3 failed on first invocation with stack of three elements, topmost being NoteStackLocations. No other data.

On May 24, 2012, at 1:07 AM, Jay K wrote:

> Do you mean did we make something "official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
>  
>  
> Do it yourself?
>   (Try out scripts/python/make-dist.py?) 
>  
>  
> It has always been easy from a m3makefile point of view to do it.
> You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120524/67a65fad/attachment-0002.html>

From dragisha at m3w.org  Fri May 25 22:51:34 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 25 May 2012 22:51:34 +0200
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <1337978790.36404.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1337978790.36404.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <555EDB08-5E0A-472A-9D93-FD890F924303@m3w.org>

Daniel,

BUILDARGS is applied to all builds occuring while it's set.

Have a nice day.

dd

On May 25, 2012, at 10:46 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> such system will not compile everything using NOPTHREAD thing, but merely the compiler, so this doesn't help anything else than the compiler, if you want to build with your compiler that then you need a correct boot image.
> Thanks in advance
> 
> 
> --- El jue, 24/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] cm3, NOPTHREAD
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: jueves, 24 de mayo, 2012 03:43
> 
> I did
> 
> export BUILDARGS="-DNOPTHREAD"
> 
> before building packages/compiler.
> 
> Didn't work. Built cm3 failed on first invocation with stack of three elements, topmost being NoteStackLocations. No other data.
> 
> On May 24, 2012, at 1:07 AM, Jay K wrote:
> 
>> Do you mean did we make something "official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
>>  
>>  
>> Do it yourself?
>>   (Try out scripts/python/make-dist.py?) 
>>  
>>  
>> It has always been easy from a m3makefile point of view to do it.
>> You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120525/235f57e2/attachment-0002.html>

From dabenavidesd at yahoo.es  Fri May 25 22:46:30 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 25 May 2012 21:46:30 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <F2C6F642-0ED9-4A79-9E67-256DAE06EB64@m3w.org>
Message-ID: <1337978790.36404.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
such system will not compile everything using NOPTHREAD thing, but merely the compiler, so this doesn't help anything else than the compiler, if you want to build with your compiler that then you need a correct boot image.
Thanks in advance


--- El jue, 24/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] cm3, NOPTHREAD
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 24 de mayo, 2012 03:43

I did
export BUILDARGS="-DNOPTHREAD"
before building packages/compiler.
Didn't work. Built cm3 failed on first invocation with stack of three elements, topmost being NoteStackLocations. No other data.
On May 24, 2012, at 1:07 AM, Jay K wrote:
Do you mean did we make something?"official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
?
?
Do it yourself?
? (Try out scripts/python/make-dist.py?)?
?
?
It has always been easy from a m3makefile point of view to do it.
You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120525/520b424b/attachment-0002.html>

From dabenavidesd at yahoo.es  Fri May 25 22:57:56 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 25 May 2012 21:57:56 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <555EDB08-5E0A-472A-9D93-FD890F924303@m3w.org>
Message-ID: <1337979476.29484.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
no, since we've lost self-hosted compiler (because PTHREADS is C code) when compiling using PTHREADS capabilities.
You need a new compiler image and a new RT image, if you want to do that; what you say, sounds like you can change that at build time, this is not the case.
Thanks in advance


--- El vie, 25/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] cm3, NOPTHREAD
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay K" <jay.krell at cornell.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 25 de mayo, 2012 15:51

Daniel,
BUILDARGS is applied to all builds occuring while it's set.
Have a nice day.
dd
On May 25, 2012, at 10:46 PM, Daniel Alejandro Benavides D. wrote:
Hi all:
such system will not compile everything using NOPTHREAD thing, but merely the compiler, so this doesn't help anything else than the compiler, if you want to build with your compiler that then you need a correct boot image.
Thanks in advance


--- El jue, 24/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] cm3, NOPTHREAD
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 24 de mayo, 2012 03:43

I did
export BUILDARGS="-DNOPTHREAD"
before building packages/compiler.
Didn't work. Built
 cm3 failed on first invocation with stack of three elements, topmost being NoteStackLocations. No other data.
On May 24, 2012, at 1:07 AM, Jay K wrote:
Do you mean did we make something?"official" and put it somewhere to be tested and downloaded by the masses of Modula-3 programmers who want to use both Modula-3 and user threads? I don't think so.
?
?
Do it yourself?
? (Try out
 scripts/python/make-dist.py?)?
?
?
It has always been easy from a m3makefile point of view to do it.
You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120525/c760a07b/attachment-0002.html>

From jay.krell at cornell.edu  Sat May 26 00:09:12 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 25 May 2012 22:09:12 +0000
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <1337979476.29484.YahooMailClassic@web29703.mail.ird.yahoo.com>
References: <555EDB08-5E0A-472A-9D93-FD890F924303@m3w.org>,
	<1337979476.29484.YahooMailClassic@web29703.mail.ird.yahoo.com>
Message-ID: <COL101-W1C8E7FBA8B4CC5793DC42E6010@phx.gbl>


?> no, since we've lost self-hosted compiler (because PTHREADS is C code)  
?> when compiling using PTHREADS capabilities. 
?

?Again Daniel, this make no sense to me. 


> You need a new compiler image 


?
?Again Daniel, this is wrong.?  


?
? >? and a new RT image 




? Again Daniel, this doesn't make complete sense to me.?  
? What do you mean "new RT image"? 


?You need m3core, and then because its interface essentially changes (different type ids for thread and/or lock), you have to recompile everything else that you are going to use, with this new m3core -- i.e.? the entire dependency graph up to and including the executable.


You do NOT need a new compiler.
If it works, great. But you don't need it.


If we hide the types behind object or such, then only m3core will need to be rebuild. That is the plan. And more so -- a command line to change between them.
For now, the type ids vary.


-DNOPTHREAD only directly changes m3core.
The rest of the system can be compiled w/ or w/o it. But the new m3core causes a need for some rebuild.


?- Jay


________________________________
> Date: Fri, 25 May 2012 21:57:56 +0100 
> From: dabenavidesd at yahoo.es 
> Subject: Re: [M3devel] cm3, NOPTHREAD 
> To: dragisha at m3w.org 
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com 
>  
> Hi all: 
> no, since we've lost self-hosted compiler (because PTHREADS is C code)  
> when compiling using PTHREADS capabilities. 
> You need a new compiler image and a new RT image, if you want to do  
> that; what you say, sounds like you can change that at build time, this  
> is not the case. 
> Thanks in advance 
>  
>  
> --- El vie, 25/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?: 
>  
> De: Dragi?a Duri? <dragisha at m3w.org> 
> Asunto: Re: [M3devel] cm3, NOPTHREAD 
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 
> CC: "Jay K" <jay.krell at cornell.edu>, "m3devel" <m3devel at elegosoft.com> 
> Fecha: viernes, 25 de mayo, 2012 15:51 
>  
> Daniel, 
>  
> BUILDARGS is applied to all builds occuring while it's set. 
>  
> Have a nice day. 
>  
> dd 
>  
> On May 25, 2012, at 10:46 PM, Daniel Alejandro Benavides D. wrote: 
>  
> Hi all: 
> such system will not compile everything using NOPTHREAD thing, but  
> merely the compiler, so this doesn't help anything else than the  
> compiler, if you want to build with your compiler that then you need a  
> correct boot image. 
> Thanks in advance 
>  
>  
> --- El jue, 24/5/12, Dragi?a Duri?  
> <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>> escribi?: 
>  
> De: Dragi?a Duri?  
> <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>> 
> Asunto: Re: [M3devel] cm3, NOPTHREAD 
> Para: "Jay K"  
> <jay.krell at cornell.edu<http:///mc/compose?to=jay.krell%40cornell.edu>> 
> CC: "m3devel"  
> <m3devel at elegosoft.com<http:///mc/compose?to=m3devel%40elegosoft.com>> 
> Fecha: jueves, 24 de mayo, 2012 03:43 
>  
> I did 
>  
> export BUILDARGS="-DNOPTHREAD" 
>  
> before building packages/compiler. 
>  
> Didn't work. Built cm3 failed on first invocation with stack of three  
> elements, topmost being NoteStackLocations. No other data. 
>  
> On May 24, 2012, at 1:07 AM, Jay K wrote: 
>  
> Do you mean did we make something "official" and put it somewhere to be  
> tested and downloaded by the masses of Modula-3 programmers who want to  
> use both Modula-3 and user threads? I don't think so. 
>  
>  
> Do it yourself? 
>    (Try out scripts/python/make-dist.py?) 
>  
>  
> It has always been easy from a m3makefile point of view to do it. 
> You either use -DNOPTHREAD or such, or edit m3core/src/thread/m3makefile. 
>  
>  
>  
>  
 		 	   		  

From dabenavidesd at yahoo.es  Sat May 26 00:38:07 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 25 May 2012 23:38:07 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <COL101-W1C8E7FBA8B4CC5793DC42E6010@phx.gbl>
Message-ID: <1337985487.13774.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
I'm thinking can press a key command to compile m3core with that option, no, you need to change the sources of the thing. That's for me new RT and new compiler, and if you want that do it, it's OK but for me, don't think it makes sense to do that in an automatic environment, that's why I tell you you can't do that in Modula-3 alone. If it were pure Modula-3 yes you could override a Thread interface with that option, but not here certainly.
Thanks advance


--- El vie, 25/5/12, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] cm3, NOPTHREAD
> Para: dabenavidesd at yahoo.es, dragisha at m3w.org
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 25 de mayo, 2012 17:09
> 
>  > no, since we've lost self-hosted compiler (because
> PTHREADS is C code)  
>  > when compiling using PTHREADS capabilities. 
>  
> 
>  Again Daniel, this make no sense to me. 
> 
> 
> > You need a new compiler image 
> 
> 
>  
>  Again Daniel, this is wrong.   
> 
> 
>  
>   >  and a new RT image 
> 
> 
> 
> 
>   Again Daniel, this doesn't make complete sense to
> me.   
>   What do you mean "new RT image"? 
> 
> 
>  You need m3core, and then because its interface
> essentially changes (different type ids for thread and/or
> lock), you have to recompile everything else that you are
> going to use, with this new m3core -- i.e.  the entire
> dependency graph up to and including the executable.
> 
> 
> You do NOT need a new compiler.
> If it works, great. But you don't need it.
> 
> 
> If we hide the types behind object or such, then only m3core
> will need to be rebuild. That is the plan. And more so -- a
> command line to change between them.
> For now, the type ids vary.
> 
> 
> -DNOPTHREAD only directly changes m3core.
> The rest of the system can be compiled w/ or w/o it. But the
> new m3core causes a need for some rebuild.
> 
> 
>  - Jay
> 
> 
> ________________________________
> > Date: Fri, 25 May 2012 21:57:56 +0100 
> > From: dabenavidesd at yahoo.es
> 
> > Subject: Re: [M3devel] cm3, NOPTHREAD 
> > To: dragisha at m3w.org
> 
> > CC: jay.krell at cornell.edu;
> m3devel at elegosoft.com
> 
> >  
> > Hi all: 
> > no, since we've lost self-hosted compiler (because
> PTHREADS is C code)  
> > when compiling using PTHREADS capabilities. 
> > You need a new compiler image and a new RT image, if
> you want to do  
> > that; what you say, sounds like you can change that at
> build time, this  
> > is not the case. 
> > Thanks in advance 
> >  
> >  
> > --- El vie, 25/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?: 
> >  
> > De: Dragi?a Duri? <dragisha at m3w.org>
> 
> > Asunto: Re: [M3devel] cm3, NOPTHREAD 
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> 
> > CC: "Jay K" <jay.krell at cornell.edu>,
> "m3devel" <m3devel at elegosoft.com>
> 
> > Fecha: viernes, 25 de mayo, 2012 15:51 
> >  
> > Daniel, 
> >  
> > BUILDARGS is applied to all builds occuring while it's
> set. 
> >  
> > Have a nice day. 
> >  
> > dd 
> >  
> > On May 25, 2012, at 10:46 PM, Daniel Alejandro
> Benavides D. wrote: 
> >  
> > Hi all: 
> > such system will not compile everything using NOPTHREAD
> thing, but  
> > merely the compiler, so this doesn't help anything else
> than the  
> > compiler, if you want to build with your compiler that
> then you need a  
> > correct boot image. 
> > Thanks in advance 
> >  
> >  
> > --- El jue, 24/5/12, Dragi?a Duri?  
> > <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>>
> escribi?: 
> >  
> > De: Dragi?a Duri?  
> > <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>> 
> > Asunto: Re: [M3devel] cm3, NOPTHREAD 
> > Para: "Jay K"  
> > <jay.krell at cornell.edu<http:///mc/compose?to=jay.krell%40cornell.edu>> 
> > CC: "m3devel"  
> > <m3devel at elegosoft.com<http:///mc/compose?to=m3devel%40elegosoft.com>> 
> > Fecha: jueves, 24 de mayo, 2012 03:43 
> >  
> > I did 
> >  
> > export BUILDARGS="-DNOPTHREAD" 
> >  
> > before building packages/compiler. 
> >  
> > Didn't work. Built cm3 failed on first invocation with
> stack of three  
> > elements, topmost being NoteStackLocations. No other
> data. 
> >  
> > On May 24, 2012, at 1:07 AM, Jay K wrote: 
> >  
> > Do you mean did we make something "official" and put it
> somewhere to be  
> > tested and downloaded by the masses of Modula-3
> programmers who want to  
> > use both Modula-3 and user threads? I don't think so. 
> >  
> >  
> > Do it yourself? 
> >    (Try out scripts/python/make-dist.py?) 
> >  
> >  
> > It has always been easy from a m3makefile point of view
> to do it. 
> > You either use -DNOPTHREAD or such, or edit
> m3core/src/thread/m3makefile. 
> >  
> >  
> >  
> >  
>     
>         
>           
>   


From dabenavidesd at yahoo.es  Sat May 26 00:58:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 25 May 2012 23:58:34 +0100 (BST)
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <1337985487.13774.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <1337986714.57733.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I think that you don't want that unless you want to use the OS source, I don't think this libraries make that sense, this libraries are just if you want is use this interface of your OS (Modula-3 are essentially different of theirs that's the main issue here).
I think we can do it, but the first alternative to test would be a NT since you can provide several schedulers in an OS version called RiAlto (you need to compile an relink everything). But then you wouldn't be using Win32 alone, you need to license not that EULA, or ULA, guess if DEC/Compaq did that, what did they paid for?
I don't know any other OS with that function, but perhaps I'm wrong.
Thanks in advance


--- El vie, 25/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] cm3, NOPTHREAD
> Para: dragisha at m3w.org, "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 25 de mayo, 2012 17:38
> Hi all:
> I'm thinking can press a key command to compile m3core with
> that option, no, you need to change the sources of the
> thing. That's for me new RT and new compiler, and if you
> want that do it, it's OK but for me, don't think it makes
> sense to do that in an automatic environment, that's why I
> tell you you can't do that in Modula-3 alone. If it were
> pure Modula-3 yes you could override a Thread interface with
> that option, but not here certainly.
> Thanks advance
> 
> 
> --- El vie, 25/5/12, Jay K <jay.krell at cornell.edu>
> escribi?:
> 
> > De: Jay K <jay.krell at cornell.edu>
> > Asunto: RE: [M3devel] cm3, NOPTHREAD
> > Para: dabenavidesd at yahoo.es,
> dragisha at m3w.org
> > CC: "m3devel" <m3devel at elegosoft.com>
> > Fecha: viernes, 25 de mayo, 2012 17:09
> > 
> >  > no, since we've lost self-hosted compiler
> (because
> > PTHREADS is C code)  
> >  > when compiling using PTHREADS capabilities.
> 
> >  
> > 
> >  Again Daniel, this make no sense to me. 
> > 
> > 
> > > You need a new compiler image 
> > 
> > 
> >  
> >  Again Daniel, this is wrong.   
> > 
> > 
> >  
> >   >  and a new RT image 
> > 
> > 
> > 
> > 
> >   Again Daniel, this doesn't make
> complete sense to
> > me.   
> >   What do you mean "new RT image"? 
> > 
> > 
> >  You need m3core, and then because its interface
> > essentially changes (different type ids for thread
> and/or
> > lock), you have to recompile everything else that you
> are
> > going to use, with this new m3core -- i.e.  the
> entire
> > dependency graph up to and including the executable.
> > 
> > 
> > You do NOT need a new compiler.
> > If it works, great. But you don't need it.
> > 
> > 
> > If we hide the types behind object or such, then only
> m3core
> > will need to be rebuild. That is the plan. And more so
> -- a
> > command line to change between them.
> > For now, the type ids vary.
> > 
> > 
> > -DNOPTHREAD only directly changes m3core.
> > The rest of the system can be compiled w/ or w/o it.
> But the
> > new m3core causes a need for some rebuild.
> > 
> > 
> >  - Jay
> > 
> > 
> > ________________________________
> > > Date: Fri, 25 May 2012 21:57:56 +0100 
> > > From: dabenavidesd at yahoo.es
> > 
> > > Subject: Re: [M3devel] cm3, NOPTHREAD 
> > > To: dragisha at m3w.org
> > 
> > > CC: jay.krell at cornell.edu;
> > m3devel at elegosoft.com
> > 
> > >  
> > > Hi all: 
> > > no, since we've lost self-hosted compiler
> (because
> > PTHREADS is C code)  
> > > when compiling using PTHREADS capabilities. 
> > > You need a new compiler image and a new RT image,
> if
> > you want to do  
> > > that; what you say, sounds like you can change
> that at
> > build time, this  
> > > is not the case. 
> > > Thanks in advance 
> > >  
> > >  
> > > --- El vie, 25/5/12, Dragi?a Duri? <dragisha at m3w.org>
> > escribi?: 
> > >  
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > 
> > > Asunto: Re: [M3devel] cm3, NOPTHREAD 
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > 
> > > CC: "Jay K" <jay.krell at cornell.edu>,
> > "m3devel" <m3devel at elegosoft.com>
> > 
> > > Fecha: viernes, 25 de mayo, 2012 15:51 
> > >  
> > > Daniel, 
> > >  
> > > BUILDARGS is applied to all builds occuring while
> it's
> > set. 
> > >  
> > > Have a nice day. 
> > >  
> > > dd 
> > >  
> > > On May 25, 2012, at 10:46 PM, Daniel Alejandro
> > Benavides D. wrote: 
> > >  
> > > Hi all: 
> > > such system will not compile everything using
> NOPTHREAD
> > thing, but  
> > > merely the compiler, so this doesn't help anything
> else
> > than the  
> > > compiler, if you want to build with your compiler
> that
> > then you need a  
> > > correct boot image. 
> > > Thanks in advance 
> > >  
> > >  
> > > --- El jue, 24/5/12, Dragi?a Duri?  
> > > <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>>
> > escribi?: 
> > >  
> > > De: Dragi?a Duri?  
> > > <dragisha at m3w.org<http:///mc/compose?to=dragisha%40m3w.org>> 
> > > Asunto: Re: [M3devel] cm3, NOPTHREAD 
> > > Para: "Jay K"  
> > > <jay.krell at cornell.edu<http:///mc/compose?to=jay.krell%40cornell.edu>> 
> > > CC: "m3devel"  
> > > <m3devel at elegosoft.com<http:///mc/compose?to=m3devel%40elegosoft.com>> 
> > > Fecha: jueves, 24 de mayo, 2012 03:43 
> > >  
> > > I did 
> > >  
> > > export BUILDARGS="-DNOPTHREAD" 
> > >  
> > > before building packages/compiler. 
> > >  
> > > Didn't work. Built cm3 failed on first invocation
> with
> > stack of three  
> > > elements, topmost being NoteStackLocations. No
> other
> > data. 
> > >  
> > > On May 24, 2012, at 1:07 AM, Jay K wrote: 
> > >  
> > > Do you mean did we make something "official" and
> put it
> > somewhere to be  
> > > tested and downloaded by the masses of Modula-3
> > programmers who want to  
> > > use both Modula-3 and user threads? I don't think
> so. 
> > >  
> > >  
> > > Do it yourself? 
> > >    (Try out
> scripts/python/make-dist.py?) 
> > >  
> > >  
> > > It has always been easy from a m3makefile point of
> view
> > to do it. 
> > > You either use -DNOPTHREAD or such, or edit
> > m3core/src/thread/m3makefile. 
> > >  
> > >  
> > >  
> > >  
> >     
> >         
> >           
> >
> 


From dabenavidesd at yahoo.es  Mon May 28 16:22:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 May 2012 15:22:24 +0100 (BST)
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20120528084705.E13302474003@birch.elegosoft.com>
Message-ID: <1338214944.4326.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi Jay:
Where are you testing this, or have you tested this on an Alpha, I might get access, but I notice you dropped the libdecnumber, stuff right?
Thanks in advance

--- El lun, 28/5/12, Jay Krell <jkrell at elego.de> escribi?:

> De: Jay Krell <jkrell at elego.de>
> Asunto: [M3commit] CVS Update: cm3
> Para: m3commit at elegosoft.com
> Fecha: lunes, 28 de mayo, 2012 05:47
> CVSROOT:    /usr/cvs
> Changes by:   
> jkrell at birch.    12/05/28 10:47:05
> 
> Modified files:
>     cm3/m3-sys/m3cc/gcc-4.6/: configure 
>     ./: configure 
>     cm3/m3-sys/m3cc/gcc-4.6/gcc/: Makefile.in
> auto-inc-dec.c 
>                
>                
>   basic-block.h builtins.c 
>                
>                
>   c-aux-info.c c-convert.c c-decl.c 
>                
>                
>   c-errors.c c-lang.c c-lang.h 
>                
>                
>   c-objc-common.c c-parser.c 
>                
>                
>   c-tree.h c-typeck.c calls.c 
>                
>                
>   cfgexpand.c cfgloop.h cgraph.c 
>                
>                
>   cgraph.h cgraphbuild.c 
>                
>                
>   cgraphunit.c combine.c configure 
>                
>                
>   configure.ac cppdefault.c 
>                
>                
>   cppdefault.h cppspec.c cse.c 
>                
>                
>   expr.c final.c fold-const.c gcc.c 
>                
>                
>   gccspec.c gcse.c gengtype-lex.c 
>                
>                
>   gengtype-lex.l gengtype.c 
>                
>                
>   gimple-fold.c gimple.c gimplify.c 
>                
>                
>   incpath.c intl.c ipa-cp.c 
>                
>                
>   ipa-inline.c ipa-prop.c ipa-prop.h 
>                
>                
>   ipa-ref.h ipa-utils.c ipa.c 
>                
>                
>   ira-build.c ira-conflicts.c 
>                
>                
>   ira-int.h ira.c ira.h libgcov.c 
>                
>                
>   loop-iv.c loop-unswitch.c opts.c 
>                
>                
>   passes.c postreload.c predict.c 
>                
>                
>   profile.c sched-vis.c 
>                
>                
>   sel-sched-dump.c store-motion.c 
>                
>                
>   stringpool.c targhooks.c toplev.c 
>                
>                
>   tree-cfg.c tree-chrec.c 
>                
>                
>   tree-complex.c tree-eh.c 
>                
>                
>   tree-flow.h tree-inline.c 
>                
>                
>   tree-nested.c tree-object-size.c 
>                
>                
>   tree-outof-ssa.c tree-parloops.c 
>                
>                
>   tree-pass.h tree-pretty-print.c 
>                
>                
>   tree-profile.c 
>                
>                
>   tree-scalar-evolution.c tree-sra.c 
>                
>                
>   tree-ssa-address.c 
>                
>                
>   tree-ssa-alias.c 
>                
>                
>   tree-ssa-copyrename.c 
>                
>                
>   tree-ssa-dce.c tree-ssa-dom.c 
>                
>                
>   tree-ssa-loop-ivopts.c 
>                
>                
>   tree-ssa-loop-manip.c 
>                
>                
>   tree-ssa-loop.c tree-ssa-phiopt.c 
>                
>                
>   tree-ssa-structalias.c 
>                
>                
>   tree-ssa-uncprop.c tree-ssa.c 
>                
>                
>   tree-vect-data-refs.c 
>                
>                
>   tree-vect-generic.c 
>                
>                
>   tree-vect-loop-manip.c 
>                
>                
>   tree-vect-loop.c 
>                
>                
>   tree-vect-patterns.c 
>                
>                
>   tree-vect-slp.c tree-vect-stmts.c 
>                
>                
>   tree-vrp.c tree.h unwind-c.c 
>                
>                
>   unwind-compat.c unwind-compat.h 
>                
>                
>   unwind-dw2-fde-compat.c 
>                
>                
>   unwind-dw2-fde-darwin.c 
>                
>                
>   unwind-dw2-fde-glibc.c 
>                
>                
>   unwind-dw2-fde.c unwind-dw2-fde.h 
>                
>                
>   unwind-dw2.c unwind-dw2.h 
>                
>                
>   unwind-generic.h unwind-pe.h 
>                
>                
>   unwind-sjlj.c value-prof.c 
>                
>                
>   var-tracking.c varpool.c web.c 
>     ./: Makefile.in auto-inc-dec.c
> basic-block.h builtins.c 
>         c-aux-info.c c-convert.c
> c-decl.c c-errors.c c-lang.c 
>         c-lang.h c-objc-common.c
> c-parser.c c-tree.h c-typeck.c 
>         calls.c cfgexpand.c
> cfgloop.h cgraph.c cgraph.h 
>         cgraphbuild.c cgraphunit.c
> combine.c configure configure.ac 
>         cppdefault.c cppdefault.h
> cppspec.c cse.c expr.c final.c 
>         fold-const.c gcc.c
> gccspec.c gcse.c gengtype-lex.c 
>         gengtype-lex.l gengtype.c
> gimple-fold.c gimple.c gimplify.c 
>         incpath.c intl.c ipa-cp.c
> ipa-inline.c ipa-prop.c ipa-prop.h 
>         ipa-ref.h ipa-utils.c ipa.c
> ira-build.c ira-conflicts.c 
>         ira-int.h ira.c ira.h
> libgcov.c loop-iv.c loop-unswitch.c 
>         opts.c passes.c
> postreload.c predict.c profile.c sched-vis.c 
>         sel-sched-dump.c
> store-motion.c stringpool.c targhooks.c 
>         toplev.c tree-cfg.c
> tree-chrec.c tree-complex.c tree-eh.c 
>         tree-flow.h tree-inline.c
> tree-nested.c tree-object-size.c 
>         tree-outof-ssa.c
> tree-parloops.c tree-pass.h 
>         tree-pretty-print.c
> tree-profile.c tree-scalar-evolution.c 
>         tree-sra.c
> tree-ssa-address.c tree-ssa-alias.c 
>         tree-ssa-copyrename.c
> tree-ssa-dce.c tree-ssa-dom.c 
>         tree-ssa-loop-ivopts.c
> tree-ssa-loop-manip.c tree-ssa-loop.c 
>         tree-ssa-phiopt.c
> tree-ssa-structalias.c tree-ssa-uncprop.c 
>         tree-ssa.c
> tree-vect-data-refs.c tree-vect-generic.c 
>         tree-vect-loop-manip.c
> tree-vect-loop.c tree-vect-patterns.c 
>         tree-vect-slp.c
> tree-vect-stmts.c tree-vrp.c tree.h 
>         unwind-c.c unwind-compat.c
> unwind-compat.h 
>         unwind-dw2-fde-compat.c
> unwind-dw2-fde-darwin.c 
>         unwind-dw2-fde-glibc.c
> unwind-dw2-fde.c unwind-dw2-fde.h 
>         unwind-dw2.c unwind-dw2.h
> unwind-generic.h unwind-pe.h 
>         unwind-sjlj.c value-prof.c
> var-tracking.c varpool.c web.c 
>     cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
> darwin-protos.h darwin.c 
>                
>                
>          darwin.h 
>     ./: darwin-protos.h darwin.c darwin.h 
>     cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
> crtfastmath.c 
>                
>                
>               crtprec.c 
>                
>                
>              
> cygming-crtbegin.c 
>                
>                
>              
> cygming-crtend.c 
>                
>                
>               darwin.h
> driver-i386.c 
>                
>                
>               gmon-sol2.c
> i386.c 
>                
>                
>              
> netware-crt0.c 
>     ./: crtfastmath.c crtprec.c
> cygming-crtbegin.c cygming-crtend.c 
>         darwin.h driver-i386.c
> gmon-sol2.c i386.c netware-crt0.c 
>     cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/: lto.c 
>     ./: lto.c 
>     cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
> line-map.h 
> 
> Log message:
>     work in progress -- can compile
> everything now, but float exception right away
> 
> 


From hendrik at topoi.pooq.com  Mon May 28 18:50:24 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 12:50:24 -0400
Subject: [M3devel] portable hosting
In-Reply-To: <C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<7B709FE4-31D7-450C-A3DD-BF41F485679A@gmail.com>
	<C53C3516-240E-470A-9E97-857048EBD39D@gmail.com>
Message-ID: <20120528165024.GA7021@topoi.pooq.com>

On Sun, May 20, 2012 at 02:32:14PM -0700, Jay wrote:
> 
> Btw, rewriting all of m3front in C or C++ or Java probably wouldn't be very difficult.

Would it be more or less difficult than writing a code generator that 
generated C or C++ code?  THe code generator could do the rewrite for 
you.  Bt it wouldn't be very readable code.


From hendrik at topoi.pooq.com  Mon May 28 18:55:44 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 12:55:44 -0400
Subject: [M3devel] using interpreter as a bootstrap
In-Reply-To: <20120522024455.GA9667@topoi.pooq.com>
References: <F0666647-CE06-401F-84A3-E6D712E401E7@m3w.org>
	<1337361419.42128.YahooMailClassic@web29706.mail.ird.yahoo.com>
	<COL101-W1466668864A79F0C274528E61E0@phx.gbl>
	<B8661F83-17C5-4177-B0F1-BB923C1E73CB@m3w.org>
	<COL101-W60E54D7B19DE6BE856EB54E61D0@phx.gbl>
	<20120521184316.GA10750@topoi.pooq.com>
	<20120521211045.GA7596@topoi.pooq.com>
	<COL101-W26376A2B9F70804F3A3B92E61D0@phx.gbl>
	<20120522024455.GA9667@topoi.pooq.com>
Message-ID: <20120528165544.GB7021@topoi.pooq.com>

On Mon, May 21, 2012 at 10:44:55PM -0400, Hendrik Boom wrote:
> On Mon, May 21, 2012 at 10:50:44PM +0000, Jay K wrote:
> > 
> > Is C-- adequately maintained? I don't think so.
> 
> Bugs get fixed.  And there's very few of them reported.  But it's not 
> clear to me whether that's because it's so well-written, or because 
> almost no one uses it.
> 
> Active development seems to be at a stendstill.
> 
> > I'm also not super keen on depending on other projects.
> > We'll see..
> 
> I mentioned C-- because its implementation exists in both interpreted 
> and compiled versions.  That seems to be a way to bootstrap the whole 
> thing.  We could interpret the compiler using some portable 
> intermediate code -- we could even restrict the interpreter to provide 
> only a 32-bit machine, and then cross-compile from the interpreted 
> compiler to whatever machine we're installing on.  Since every Modula 
> 3 compiler seems to be able to generate code for every platform, 
> this is a way to avoid having a separate binary bootstrap for every 
> platform.

Of all the machies we already generatte code for, which has the easiest 
machine code to interpret?  We don't really have to invent a new 
interpretable object code -- we already have one.  Remember, the 
bootstrap only has to implement enough system resources to compile the 
core system.

-- hendrik


> 
> And a distro, like Debian, could have a source package that doesn't 
> need to have itself installed before it it can be installed.
> 
> -- hendrik
> 


From hendrik at topoi.pooq.com  Mon May 28 19:47:00 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 13:47:00 -0400
Subject: [M3devel] Packaging for Debian
Message-ID: <20120528174700.GA7249@topoi.pooq.com>

Wasn't there a modula 3 package for Debian long long ago (maybe in the 
days of woody?), based on pm3?  Would it be possible to examine it and 
figure out how to adapt it to currently maintained cm3?  How did then 
solve tthe bootstrap problem?

-- hendrik


From dabenavidesd at yahoo.es  Mon May 28 21:17:43 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 May 2012 20:17:43 +0100 (BST)
Subject: [M3devel] Packaging for Debian
In-Reply-To: <20120528174700.GA7249@topoi.pooq.com>
Message-ID: <1338232663.14445.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
Yes, and you could use it as in a low priority package in later releases I believe, but that said, I still miss the how much of it could boot cm3, I remember I tried to recompile NT386GNU for use m3browser (pm3 had it only  for Unix targets) and I could but failed after executing due some broken dynamic libraries issue, and couldn't understand why, but you could easily bootstrap from Unix targets to NT386GNU, I remember you couldn't do it viceversa, that is, from a NT386GNU to a Unix target, I still think that cross-boot problem was essential to understand the differences among a Unix and a Win32 API in general, but I didn't have many platforms to test it for that matter, you know, sort of making a cross product might get to the point to which is the quintessential bootstrap code for a Modula-3 compiler.
Thanks in advance

PD I still have the 20+ CD's of the Distro if somebody wants a copy or so I could post it on-line  

--- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] Packaging for Debian
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 28 de mayo, 2012 12:47
> Wasn't there a modula 3 package for
> Debian long long ago (maybe in the 
> days of woody?), based on pm3?  Would it be possible to
> examine it and 
> figure out how to adapt it to currently maintained
> cm3?  How did then 
> solve tthe bootstrap problem?
> 
> -- hendrik
> 


From dabenavidesd at yahoo.es  Mon May 28 23:04:41 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 May 2012 22:04:41 +0100 (BST)
Subject: [M3devel] using interpreter as a bootstrap
In-Reply-To: <20120528165544.GB7021@topoi.pooq.com>
Message-ID: <1338239081.37249.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I guess that is the same as asking with a high-degree of compatibility a X mating machine core of a M3CG, and I believe it is the VAX-9000, it supported a CISC/RISC-core, but this was a huge machine, and so I think could be handy to get a sample of execution traces and match to  every other possible one.
I believe they made a RR on that machine:

http://books.google.com.co/books?id=U8QpAQAAMAAJ&q=%22DEC+has%22#search_anchor

Thanks in advance


--- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] using interpreter as a bootstrap
> Para: m3devel at elegosoft.com
> Fecha: lunes, 28 de mayo, 2012 11:55
> On Mon, May 21, 2012 at 10:44:55PM
> -0400, Hendrik Boom wrote:
> > On Mon, May 21, 2012 at 10:50:44PM +0000, Jay K wrote:
> > > 
> > > Is C-- adequately maintained? I don't think so.
> > 
> > Bugs get fixed.  And there's very few of them
> reported.  But it's not 
> > clear to me whether that's because it's so
> well-written, or because 
> > almost no one uses it.
> > 
> > Active development seems to be at a stendstill.
> > 
> > > I'm also not super keen on depending on other
> projects.
> > > We'll see..
> > 
> > I mentioned C-- because its implementation exists in
> both interpreted 
> > and compiled versions.  That seems to be a way to
> bootstrap the whole 
> > thing.  We could interpret the compiler using some
> portable 
> > intermediate code -- we could even restrict the
> interpreter to provide 
> > only a 32-bit machine, and then cross-compile from the
> interpreted 
> > compiler to whatever machine we're installing on. 
> Since every Modula 
> > 3 compiler seems to be able to generate code for every
> platform, 
> > this is a way to avoid having a separate binary
> bootstrap for every 
> > platform.
> 
> Of all the machies we already generatte code for, which has
> the easiest 
> machine code to interpret?  We don't really have to
> invent a new 
> interpretable object code -- we already have one. 
> Remember, the 
> bootstrap only has to implement enough system resources to
> compile the 
> core system.
> 
> -- hendrik
> 
> 
> > 
> > And a distro, like Debian, could have a source package
> that doesn't 
> > need to have itself installed before it it can be
> installed.
> > 
> > -- hendrik
> > 
> 


From dabenavidesd at yahoo.es  Mon May 28 23:22:36 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 May 2012 22:22:36 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <20120528165024.GA7021@topoi.pooq.com>
Message-ID: <1338240156.6219.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
or better make an assembly-coded C compiler in a Java language processor, and cross-boot assemble from a Modula-3 environment there so you could bootstrap a M3CG-system there.
Thanks in advance

--- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] portable hosting
> Para: m3devel at elegosoft.com
> Fecha: lunes, 28 de mayo, 2012 11:50
> On Sun, May 20, 2012 at 02:32:14PM
> -0700, Jay wrote:
> > 
> > Btw, rewriting all of m3front in C or C++ or Java
> probably wouldn't be very difficult.
> 
> Would it be more or less difficult than writing a code
> generator that 
> generated C or C++ code?  THe code generator could do
> the rewrite for 
> you.  Bt it wouldn't be very readable code.
> 


From hendrik at topoi.pooq.com  Tue May 29 00:55:45 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 18:55:45 -0400
Subject: [M3devel] Packaging for Debian
In-Reply-To: <1338232663.14445.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <20120528174700.GA7249@topoi.pooq.com>
	<1338232663.14445.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <20120528225545.GB10489@topoi.pooq.com>

On Mon, May 28, 2012 at 08:17:43PM +0100, Daniel Alejandro Benavides D. wrote:
> 
> PD I still have the 20+ CD's of the Distro if somebody wants a copy or so I could post it on-line  

20+ CD's of Which distro?  I was thinking of getting a source package 
from Debian woody.  They still have packages for those ancient releases 
in an archive somewhere.

-- hendrik


From hendrik at topoi.pooq.com  Tue May 29 01:05:05 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 19:05:05 -0400
Subject: [M3devel] Success with  libXaw.so.7, but more help needed.
In-Reply-To: <COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
Message-ID: <20120528230505.GC10489@topoi.pooq.com>

Trying a cross-compilation now.

On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote:
> 
> You might as well just use something in scripts to rebuild the entire 
> system.It isn't so difficult nor takes very long.     
>
> Get a working > cm3 on any system.
      cd scripts/python
      ./boot1.py <target-such-as-I386_LINUX>      That will produce a "bootstrap" archive.    Copy it to the "new" system.      Extract it.      Cd into it.      Look at the top of Makefile and see if it seems reasonable (we should use autoconf here).    run make.     That should give you a working cm3 for the new system.      Put that on path, e.g.:       su        rm -rf /usr/local/cm3       mkdir -p /usr/local/cm3/bin        cp cm3 /usr/local/cm3/bin        exit         PATH=/usr/local/cm3/bin:$PATH     cd to scripts/python in the source tree on the new system.    Then run ./boot2.sh       Then ./make-dist.py.    That should give you the entire system newly built, and a .deb.  If you already have a working cm3 on the system you want to run it on  cd scripts/python   ./upgrade.py    ./make-dist.py     I'd really like to get to the

Did that, as 
hendrik at april:~/cm3/cm3/scripts/python$ export LIBRARY_PATH=
hendrik at april:~/cm3/cm3/scripts/python$ ./boot1.py I386_LINUX

and it compiled for a ling time, then failed with

new source -> compiling Utils.m3
new source -> compiling WebFile.m3
new source -> compiling Main.m3
building makefile -> make.cm3
 ==> /farhome/hendrik/cm3/cm3/m3-sys/cm3 done

Traceback (most recent call last):
  File "./boot1.py", line 18, in <module>
    Boot();
  File "/farhome/hendrik/cm3/cm3/scripts/python/pylib.py", line 1248, in Boot
    for a in os.listdir(os.path.join(Root, dir, Config)):
OSError: [Errno 2] No such file or directory: '/farhome/hendrik/cm3/cm3/m3-sys/m3cc/I386_LINUX'
hendrik at april:~/cm3/cm3/scripts/python$


So I took a look for /farhome/hendrik/cm3/cm3/m3-sys/m3cc/I386_LINUX

and in directory /farhome/hendrik/cm3/cm3/m3-sys/m3cc/

I found 

drwxr-xr-x 12 hendrik hendrik 4096 May 28 14:39 .
  drwxr-xr-x 27 hendrik hendrik 4096 May 16 18:08 ..
  drwxr-xr-x  6 hendrik hendrik 4096 May 28 14:56 AMD64_LINUX
  drwxr-xr-x  6 hendrik hendrik 4096 May 28 15:21 AMD64_LINUX-I386_LINUX
  drwxr-xr-x  2 hendrik hendrik 4096 May 16 17:50 CVS
  
but no I386-LINUX

-- hendrik


From hendrik at topoi.pooq.com  Tue May 29 01:08:24 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 28 May 2012 19:08:24 -0400
Subject: [M3devel] failure to cross-install
In-Reply-To: <20120528230505.GC10489@topoi.pooq.com>
References: <20120513174747.GA25729@topoi.pooq.com>
	<20120515151217.GA23964@topoi.pooq.com>
	<COL101-W2646F795E6D5810FBE8ECCE61B0@phx.gbl>
	<20120528230505.GC10489@topoi.pooq.com>
Message-ID: <20120528230824.GA24085@topoi.pooq.com>

(forgot to change the subject)

(It's possible that the weird directory name had been generated earlier 
when I tried to do the same thing without having emptied LIBRARY_PATH, 
but I definietly specified it for this run.

-- hendrik

On Mon, May 28, 2012 at 07:05:05PM -0400, Hendrik Boom wrote:
> Trying a cross-compilation now.
> 
> On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote:
> > 
> > You might as well just use something in scripts to rebuild the entire 
> > system.It isn't so difficult nor takes very long.     
> >
> > Get a working > cm3 on any system.
>       cd scripts/python
>       ./boot1.py <target-such-as-I386_LINUX>      That will produce a "bootstrap" archive.    Copy it to the "new" system.      Extract it.      Cd into it.      Look at the top of Makefile and see if it seems reasonable (we should use autoconf here).    run make.     That should give you a working cm3 for the new system.      Put that on path, e.g.:       su        rm -rf /usr/local/cm3       mkdir -p /usr/local/cm3/bin        cp cm3 /usr/local/cm3/bin        exit         PATH=/usr/local/cm3/bin:$PATH     cd to scripts/python in the source tree on the new system.    Then run ./boot2.sh       Then ./make-dist.py.    That should give you the entire system newly built, and a .deb.  If you already have a working cm3 on the system you want to run it on  cd scripts/python   ./upgrade.py    ./make-dist.py     I'd really like to get to the
> 
> Did that, as 
> hendrik at april:~/cm3/cm3/scripts/python$ export LIBRARY_PATH=
> hendrik at april:~/cm3/cm3/scripts/python$ ./boot1.py I386_LINUX
> 
> and it compiled for a ling time, then failed with
> 
> new source -> compiling Utils.m3
> new source -> compiling WebFile.m3
> new source -> compiling Main.m3
> building makefile -> make.cm3
>  ==> /farhome/hendrik/cm3/cm3/m3-sys/cm3 done
> 
> Traceback (most recent call last):
>   File "./boot1.py", line 18, in <module>
>     Boot();
>   File "/farhome/hendrik/cm3/cm3/scripts/python/pylib.py", line 1248, in Boot
>     for a in os.listdir(os.path.join(Root, dir, Config)):
> OSError: [Errno 2] No such file or directory: '/farhome/hendrik/cm3/cm3/m3-sys/m3cc/I386_LINUX'
> hendrik at april:~/cm3/cm3/scripts/python$
> 
> 
> So I took a look for /farhome/hendrik/cm3/cm3/m3-sys/m3cc/I386_LINUX
> 
> and in directory /farhome/hendrik/cm3/cm3/m3-sys/m3cc/
> 
> I found 
> 
> drwxr-xr-x 12 hendrik hendrik 4096 May 28 14:39 .
>   drwxr-xr-x 27 hendrik hendrik 4096 May 16 18:08 ..
>   drwxr-xr-x  6 hendrik hendrik 4096 May 28 14:56 AMD64_LINUX
>   drwxr-xr-x  6 hendrik hendrik 4096 May 28 15:21 AMD64_LINUX-I386_LINUX
>   drwxr-xr-x  2 hendrik hendrik 4096 May 16 17:50 CVS
>   
> but no I386-LINUX
> 
> -- hendrik


From dabenavidesd at yahoo.es  Tue May 29 01:22:45 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 May 2012 00:22:45 +0100 (BST)
Subject: [M3devel] Packaging for Debian
In-Reply-To: <20120528225545.GB10489@topoi.pooq.com>
Message-ID: <1338247365.16482.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
Debian Woody src and i386 distribution (3.0) succesor Sarge 3.1 in CD's, but you can boot with two floppies, etc ...
This was the last distro that worked with that packaged pm3 that I know
Thanks in advance

--- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] Packaging for Debian
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 28 de mayo, 2012 17:55
> On Mon, May 28, 2012 at 08:17:43PM
> +0100, Daniel Alejandro Benavides D. wrote:
> > 
> > PD I still have the 20+ CD's of the Distro if somebody
> wants a copy or so I could post it on-line  
> 
> 20+ CD's of Which distro?  I was thinking of getting a
> source package 
> from Debian woody.  They still have packages for those
> ancient releases 
> in an archive somewhere.
> 
> -- hendrik
> 


From jay.krell at cornell.edu  Tue May 29 06:30:00 2012
From: jay.krell at cornell.edu (Jay)
Date: Mon, 28 May 2012 21:30:00 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <1338214944.4326.YahooMailClassic@web29705.mail.ird.yahoo.com>
References: <1338214944.4326.YahooMailClassic@web29705.mail.ird.yahoo.com>
Message-ID: <07F31967-EDA5-4CD7-975C-11F428381AB8@gmail.com>

Don't worry about it. I will test each platform or get others to before enabling, at least some popular majority of them. I no longer have any Alphas. Eventually I might ask for ssh access to an Alpha or reacquire hardware. Anyway, don't worry. I generally know what I'm doing.

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 28, 2012, at 7:22 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi Jay:
> Where are you testing this, or have you tested this on an Alpha, I might get access, but I notice you dropped the libdecnumber, stuff right?
> Thanks in advance
> 
> --- El lun, 28/5/12, Jay Krell <jkrell at elego.de> escribi?:
> 
>> De: Jay Krell <jkrell at elego.de>
>> Asunto: [M3commit] CVS Update: cm3
>> Para: m3commit at elegosoft.com
>> Fecha: lunes, 28 de mayo, 2012 05:47
>> CVSROOT:    /usr/cvs
>> Changes by:   
>> jkrell at birch.    12/05/28 10:47:05
>> 
>> Modified files:
>>    cm3/m3-sys/m3cc/gcc-4.6/: configure 
>>    ./: configure 
>>    cm3/m3-sys/m3cc/gcc-4.6/gcc/: Makefile.in
>> auto-inc-dec.c 
>> 
>> 
>>  basic-block.h builtins.c 
>> 
>> 
>>  c-aux-info.c c-convert.c c-decl.c 
>> 
>> 
>>  c-errors.c c-lang.c c-lang.h 
>> 
>> 
>>  c-objc-common.c c-parser.c 
>> 
>> 
>>  c-tree.h c-typeck.c calls.c 
>> 
>> 
>>  cfgexpand.c cfgloop.h cgraph.c 
>> 
>> 
>>  cgraph.h cgraphbuild.c 
>> 
>> 
>>  cgraphunit.c combine.c configure 
>> 
>> 
>>  configure.ac cppdefault.c 
>> 
>> 
>>  cppdefault.h cppspec.c cse.c 
>> 
>> 
>>  expr.c final.c fold-const.c gcc.c 
>> 
>> 
>>  gccspec.c gcse.c gengtype-lex.c 
>> 
>> 
>>  gengtype-lex.l gengtype.c 
>> 
>> 
>>  gimple-fold.c gimple.c gimplify.c 
>> 
>> 
>>  incpath.c intl.c ipa-cp.c 
>> 
>> 
>>  ipa-inline.c ipa-prop.c ipa-prop.h 
>> 
>> 
>>  ipa-ref.h ipa-utils.c ipa.c 
>> 
>> 
>>  ira-build.c ira-conflicts.c 
>> 
>> 
>>  ira-int.h ira.c ira.h libgcov.c 
>> 
>> 
>>  loop-iv.c loop-unswitch.c opts.c 
>> 
>> 
>>  passes.c postreload.c predict.c 
>> 
>> 
>>  profile.c sched-vis.c 
>> 
>> 
>>  sel-sched-dump.c store-motion.c 
>> 
>> 
>>  stringpool.c targhooks.c toplev.c 
>> 
>> 
>>  tree-cfg.c tree-chrec.c 
>> 
>> 
>>  tree-complex.c tree-eh.c 
>> 
>> 
>>  tree-flow.h tree-inline.c 
>> 
>> 
>>  tree-nested.c tree-object-size.c 
>> 
>> 
>>  tree-outof-ssa.c tree-parloops.c 
>> 
>> 
>>  tree-pass.h tree-pretty-print.c 
>> 
>> 
>>  tree-profile.c 
>> 
>> 
>>  tree-scalar-evolution.c tree-sra.c 
>> 
>> 
>>  tree-ssa-address.c 
>> 
>> 
>>  tree-ssa-alias.c 
>> 
>> 
>>  tree-ssa-copyrename.c 
>> 
>> 
>>  tree-ssa-dce.c tree-ssa-dom.c 
>> 
>> 
>>  tree-ssa-loop-ivopts.c 
>> 
>> 
>>  tree-ssa-loop-manip.c 
>> 
>> 
>>  tree-ssa-loop.c tree-ssa-phiopt.c 
>> 
>> 
>>  tree-ssa-structalias.c 
>> 
>> 
>>  tree-ssa-uncprop.c tree-ssa.c 
>> 
>> 
>>  tree-vect-data-refs.c 
>> 
>> 
>>  tree-vect-generic.c 
>> 
>> 
>>  tree-vect-loop-manip.c 
>> 
>> 
>>  tree-vect-loop.c 
>> 
>> 
>>  tree-vect-patterns.c 
>> 
>> 
>>  tree-vect-slp.c tree-vect-stmts.c 
>> 
>> 
>>  tree-vrp.c tree.h unwind-c.c 
>> 
>> 
>>  unwind-compat.c unwind-compat.h 
>> 
>> 
>>  unwind-dw2-fde-compat.c 
>> 
>> 
>>  unwind-dw2-fde-darwin.c 
>> 
>> 
>>  unwind-dw2-fde-glibc.c 
>> 
>> 
>>  unwind-dw2-fde.c unwind-dw2-fde.h 
>> 
>> 
>>  unwind-dw2.c unwind-dw2.h 
>> 
>> 
>>  unwind-generic.h unwind-pe.h 
>> 
>> 
>>  unwind-sjlj.c value-prof.c 
>> 
>> 
>>  var-tracking.c varpool.c web.c 
>>    ./: Makefile.in auto-inc-dec.c
>> basic-block.h builtins.c 
>>        c-aux-info.c c-convert.c
>> c-decl.c c-errors.c c-lang.c 
>>        c-lang.h c-objc-common.c
>> c-parser.c c-tree.h c-typeck.c 
>>        calls.c cfgexpand.c
>> cfgloop.h cgraph.c cgraph.h 
>>        cgraphbuild.c cgraphunit.c
>> combine.c configure configure.ac 
>>        cppdefault.c cppdefault.h
>> cppspec.c cse.c expr.c final.c 
>>        fold-const.c gcc.c
>> gccspec.c gcse.c gengtype-lex.c 
>>        gengtype-lex.l gengtype.c
>> gimple-fold.c gimple.c gimplify.c 
>>        incpath.c intl.c ipa-cp.c
>> ipa-inline.c ipa-prop.c ipa-prop.h 
>>        ipa-ref.h ipa-utils.c ipa.c
>> ira-build.c ira-conflicts.c 
>>        ira-int.h ira.c ira.h
>> libgcov.c loop-iv.c loop-unswitch.c 
>>        opts.c passes.c
>> postreload.c predict.c profile.c sched-vis.c 
>>        sel-sched-dump.c
>> store-motion.c stringpool.c targhooks.c 
>>        toplev.c tree-cfg.c
>> tree-chrec.c tree-complex.c tree-eh.c 
>>        tree-flow.h tree-inline.c
>> tree-nested.c tree-object-size.c 
>>        tree-outof-ssa.c
>> tree-parloops.c tree-pass.h 
>>        tree-pretty-print.c
>> tree-profile.c tree-scalar-evolution.c 
>>        tree-sra.c
>> tree-ssa-address.c tree-ssa-alias.c 
>>        tree-ssa-copyrename.c
>> tree-ssa-dce.c tree-ssa-dom.c 
>>        tree-ssa-loop-ivopts.c
>> tree-ssa-loop-manip.c tree-ssa-loop.c 
>>        tree-ssa-phiopt.c
>> tree-ssa-structalias.c tree-ssa-uncprop.c 
>>        tree-ssa.c
>> tree-vect-data-refs.c tree-vect-generic.c 
>>        tree-vect-loop-manip.c
>> tree-vect-loop.c tree-vect-patterns.c 
>>        tree-vect-slp.c
>> tree-vect-stmts.c tree-vrp.c tree.h 
>>        unwind-c.c unwind-compat.c
>> unwind-compat.h 
>>        unwind-dw2-fde-compat.c
>> unwind-dw2-fde-darwin.c 
>>        unwind-dw2-fde-glibc.c
>> unwind-dw2-fde.c unwind-dw2-fde.h 
>>        unwind-dw2.c unwind-dw2.h
>> unwind-generic.h unwind-pe.h 
>>        unwind-sjlj.c value-prof.c
>> var-tracking.c varpool.c web.c 
>>    cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
>> darwin-protos.h darwin.c 
>> 
>> 
>>         darwin.h 
>>    ./: darwin-protos.h darwin.c darwin.h 
>>    cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
>> crtfastmath.c 
>> 
>> 
>>              crtprec.c 
>> 
>> 
>> 
>> cygming-crtbegin.c 
>> 
>> 
>> 
>> cygming-crtend.c 
>> 
>> 
>>              darwin.h
>> driver-i386.c 
>> 
>> 
>>              gmon-sol2.c
>> i386.c 
>> 
>> 
>> 
>> netware-crt0.c 
>>    ./: crtfastmath.c crtprec.c
>> cygming-crtbegin.c cygming-crtend.c 
>>        darwin.h driver-i386.c
>> gmon-sol2.c i386.c netware-crt0.c 
>>    cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/: lto.c 
>>    ./: lto.c 
>>    cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
>> line-map.h 
>> 
>> Log message:
>>    work in progress -- can compile
>> everything now, but float exception right away
>> 
>> 


From dabenavidesd at yahoo.es  Tue May 29 20:44:26 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 May 2012 19:44:26 +0100 (BST)
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <07F31967-EDA5-4CD7-975C-11F428381AB8@gmail.com>
Message-ID: <1338317066.3447.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
good one, there isn't high-end user needs lately here, so I guess we shouldn't ask if we want to support other machines than just PC, perhaps, we should check more platforms at that level.
Any NT would not be affected but anything else is, HW for testing purposes isn't supported by NT (like debuggers), so there it isn't too much to support for that (lying on MIPS32, and Portable devices sometimes are RISC systems, now what is not aiming NT are desktops but bigger machines) but they are growing down so I don't know if they will become available again.
Thanks of Modula-3 hackers there is still more systems to check for all if interested in any. 
Thanks in advance

--- El lun, 28/5/12, Jay <jay.krell at cornell.edu> escribi?:

> De: Jay <jay.krell at cornell.edu>
> Asunto: Re: [M3commit] CVS Update: cm3
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "<m3commit at elegosoft.com>" <m3commit at elegosoft.com>, "<m3devel at elegosoft.com>" <m3devel at elegosoft.com>
> Fecha: lunes, 28 de mayo, 2012 23:30
> Don't worry about it. I will test
> each platform or get others to before enabling, at least
> some popular majority of them. I no longer have any Alphas.
> Eventually I might ask for ssh access to an Alpha or
> reacquire hardware. Anyway, don't worry. I generally know
> what I'm doing.
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On May 28, 2012, at 7:22 AM, "Daniel Alejandro Benavides D."
> <dabenavidesd at yahoo.es>
> wrote:
> 
> > Hi Jay:
> > Where are you testing this, or have you tested this on
> an Alpha, I might get access, but I notice you dropped the
> libdecnumber, stuff right?
> > Thanks in advance
> > 
> > --- El lun, 28/5/12, Jay Krell <jkrell at elego.de>
> escribi?:
> > 
> >> De: Jay Krell <jkrell at elego.de>
> >> Asunto: [M3commit] CVS Update: cm3
> >> Para: m3commit at elegosoft.com
> >> Fecha: lunes, 28 de mayo, 2012 05:47
> >> CVSROOT:    /usr/cvs
> >> Changes by:   
> >> jkrell at birch.    12/05/28 10:47:05
> >> 
> >> Modified files:
> >>    cm3/m3-sys/m3cc/gcc-4.6/: configure 
> >>    ./: configure 
> >>    cm3/m3-sys/m3cc/gcc-4.6/gcc/:
> Makefile.in
> >> auto-inc-dec.c 
> >> 
> >> 
> >>  basic-block.h builtins.c 
> >> 
> >> 
> >>  c-aux-info.c c-convert.c c-decl.c 
> >> 
> >> 
> >>  c-errors.c c-lang.c c-lang.h 
> >> 
> >> 
> >>  c-objc-common.c c-parser.c 
> >> 
> >> 
> >>  c-tree.h c-typeck.c calls.c 
> >> 
> >> 
> >>  cfgexpand.c cfgloop.h cgraph.c 
> >> 
> >> 
> >>  cgraph.h cgraphbuild.c 
> >> 
> >> 
> >>  cgraphunit.c combine.c configure 
> >> 
> >> 
> >>  configure.ac cppdefault.c 
> >> 
> >> 
> >>  cppdefault.h cppspec.c cse.c 
> >> 
> >> 
> >>  expr.c final.c fold-const.c gcc.c 
> >> 
> >> 
> >>  gccspec.c gcse.c gengtype-lex.c 
> >> 
> >> 
> >>  gengtype-lex.l gengtype.c 
> >> 
> >> 
> >>  gimple-fold.c gimple.c gimplify.c 
> >> 
> >> 
> >>  incpath.c intl.c ipa-cp.c 
> >> 
> >> 
> >>  ipa-inline.c ipa-prop.c ipa-prop.h 
> >> 
> >> 
> >>  ipa-ref.h ipa-utils.c ipa.c 
> >> 
> >> 
> >>  ira-build.c ira-conflicts.c 
> >> 
> >> 
> >>  ira-int.h ira.c ira.h libgcov.c 
> >> 
> >> 
> >>  loop-iv.c loop-unswitch.c opts.c 
> >> 
> >> 
> >>  passes.c postreload.c predict.c 
> >> 
> >> 
> >>  profile.c sched-vis.c 
> >> 
> >> 
> >>  sel-sched-dump.c store-motion.c 
> >> 
> >> 
> >>  stringpool.c targhooks.c toplev.c 
> >> 
> >> 
> >>  tree-cfg.c tree-chrec.c 
> >> 
> >> 
> >>  tree-complex.c tree-eh.c 
> >> 
> >> 
> >>  tree-flow.h tree-inline.c 
> >> 
> >> 
> >>  tree-nested.c tree-object-size.c 
> >> 
> >> 
> >>  tree-outof-ssa.c tree-parloops.c 
> >> 
> >> 
> >>  tree-pass.h tree-pretty-print.c 
> >> 
> >> 
> >>  tree-profile.c 
> >> 
> >> 
> >>  tree-scalar-evolution.c tree-sra.c 
> >> 
> >> 
> >>  tree-ssa-address.c 
> >> 
> >> 
> >>  tree-ssa-alias.c 
> >> 
> >> 
> >>  tree-ssa-copyrename.c 
> >> 
> >> 
> >>  tree-ssa-dce.c tree-ssa-dom.c 
> >> 
> >> 
> >>  tree-ssa-loop-ivopts.c 
> >> 
> >> 
> >>  tree-ssa-loop-manip.c 
> >> 
> >> 
> >>  tree-ssa-loop.c tree-ssa-phiopt.c 
> >> 
> >> 
> >>  tree-ssa-structalias.c 
> >> 
> >> 
> >>  tree-ssa-uncprop.c tree-ssa.c 
> >> 
> >> 
> >>  tree-vect-data-refs.c 
> >> 
> >> 
> >>  tree-vect-generic.c 
> >> 
> >> 
> >>  tree-vect-loop-manip.c 
> >> 
> >> 
> >>  tree-vect-loop.c 
> >> 
> >> 
> >>  tree-vect-patterns.c 
> >> 
> >> 
> >>  tree-vect-slp.c tree-vect-stmts.c 
> >> 
> >> 
> >>  tree-vrp.c tree.h unwind-c.c 
> >> 
> >> 
> >>  unwind-compat.c unwind-compat.h 
> >> 
> >> 
> >>  unwind-dw2-fde-compat.c 
> >> 
> >> 
> >>  unwind-dw2-fde-darwin.c 
> >> 
> >> 
> >>  unwind-dw2-fde-glibc.c 
> >> 
> >> 
> >>  unwind-dw2-fde.c unwind-dw2-fde.h 
> >> 
> >> 
> >>  unwind-dw2.c unwind-dw2.h 
> >> 
> >> 
> >>  unwind-generic.h unwind-pe.h 
> >> 
> >> 
> >>  unwind-sjlj.c value-prof.c 
> >> 
> >> 
> >>  var-tracking.c varpool.c web.c 
> >>    ./: Makefile.in auto-inc-dec.c
> >> basic-block.h builtins.c 
> >>        c-aux-info.c
> c-convert.c
> >> c-decl.c c-errors.c c-lang.c 
> >>        c-lang.h
> c-objc-common.c
> >> c-parser.c c-tree.h c-typeck.c 
> >>        calls.c cfgexpand.c
> >> cfgloop.h cgraph.c cgraph.h 
> >>        cgraphbuild.c
> cgraphunit.c
> >> combine.c configure configure.ac 
> >>        cppdefault.c
> cppdefault.h
> >> cppspec.c cse.c expr.c final.c 
> >>        fold-const.c gcc.c
> >> gccspec.c gcse.c gengtype-lex.c 
> >>        gengtype-lex.l
> gengtype.c
> >> gimple-fold.c gimple.c gimplify.c 
> >>        incpath.c intl.c
> ipa-cp.c
> >> ipa-inline.c ipa-prop.c ipa-prop.h 
> >>        ipa-ref.h ipa-utils.c
> ipa.c
> >> ira-build.c ira-conflicts.c 
> >>        ira-int.h ira.c ira.h
> >> libgcov.c loop-iv.c loop-unswitch.c 
> >>        opts.c passes.c
> >> postreload.c predict.c profile.c sched-vis.c 
> >>        sel-sched-dump.c
> >> store-motion.c stringpool.c targhooks.c 
> >>        toplev.c tree-cfg.c
> >> tree-chrec.c tree-complex.c tree-eh.c 
> >>        tree-flow.h
> tree-inline.c
> >> tree-nested.c tree-object-size.c 
> >>        tree-outof-ssa.c
> >> tree-parloops.c tree-pass.h 
> >>        tree-pretty-print.c
> >> tree-profile.c tree-scalar-evolution.c 
> >>        tree-sra.c
> >> tree-ssa-address.c tree-ssa-alias.c 
> >>        tree-ssa-copyrename.c
> >> tree-ssa-dce.c tree-ssa-dom.c 
> >>        tree-ssa-loop-ivopts.c
> >> tree-ssa-loop-manip.c tree-ssa-loop.c 
> >>        tree-ssa-phiopt.c
> >> tree-ssa-structalias.c tree-ssa-uncprop.c 
> >>        tree-ssa.c
> >> tree-vect-data-refs.c tree-vect-generic.c 
> >>        tree-vect-loop-manip.c
> >> tree-vect-loop.c tree-vect-patterns.c 
> >>        tree-vect-slp.c
> >> tree-vect-stmts.c tree-vrp.c tree.h 
> >>        unwind-c.c
> unwind-compat.c
> >> unwind-compat.h 
> >>        unwind-dw2-fde-compat.c
> >> unwind-dw2-fde-darwin.c 
> >>        unwind-dw2-fde-glibc.c
> >> unwind-dw2-fde.c unwind-dw2-fde.h 
> >>        unwind-dw2.c
> unwind-dw2.h
> >> unwind-generic.h unwind-pe.h 
> >>        unwind-sjlj.c
> value-prof.c
> >> var-tracking.c varpool.c web.c 
> >>    cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
> >> darwin-protos.h darwin.c 
> >> 
> >> 
> >>         darwin.h 
> >>    ./: darwin-protos.h darwin.c darwin.h
> 
> >>   
> cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
> >> crtfastmath.c 
> >> 
> >> 
> >>             
> crtprec.c 
> >> 
> >> 
> >> 
> >> cygming-crtbegin.c 
> >> 
> >> 
> >> 
> >> cygming-crtend.c 
> >> 
> >> 
> >>             
> darwin.h
> >> driver-i386.c 
> >> 
> >> 
> >>             
> gmon-sol2.c
> >> i386.c 
> >> 
> >> 
> >> 
> >> netware-crt0.c 
> >>    ./: crtfastmath.c crtprec.c
> >> cygming-crtbegin.c cygming-crtend.c 
> >>        darwin.h driver-i386.c
> >> gmon-sol2.c i386.c netware-crt0.c 
> >>    cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/:
> lto.c 
> >>    ./: lto.c 
> >>   
> cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
> >> line-map.h 
> >> 
> >> Log message:
> >>    work in progress -- can compile
> >> everything now, but float exception right away
> >> 
> >> 
> 


From jay.krell at cornell.edu  Wed May 30 01:15:48 2012
From: jay.krell at cornell.edu (Jay)
Date: Tue, 29 May 2012 16:15:48 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <1338317066.3447.YahooMailClassic@web29704.mail.ird.yahoo.com>
References: <1338317066.3447.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <1572EB44-615A-4224-948B-DDC3DB23E57C@gmail.com>

Daniel you don't make sense.

 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 29, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> good one, there isn't high-end user needs lately here, so I guess we shouldn't ask if we want to support other machines than just PC, perhaps, we should check more platforms at that level.
> Any NT would not be affected but anything else is, HW for testing purposes isn't supported by NT (like debuggers), so there it isn't too much to support for that (lying on MIPS32, and Portable devices sometimes are RISC systems, now what is not aiming NT are desktops but bigger machines) but they are growing down so I don't know if they will become available again.
> Thanks of Modula-3 hackers there is still more systems to check for all if interested in any. 
> Thanks in advance
> 
> --- El lun, 28/5/12, Jay <jay.krell at cornell.edu> escribi?:
> 
>> De: Jay <jay.krell at cornell.edu>
>> Asunto: Re: [M3commit] CVS Update: cm3
>> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
>> CC: "<m3commit at elegosoft.com>" <m3commit at elegosoft.com>, "<m3devel at elegosoft.com>" <m3devel at elegosoft.com>
>> Fecha: lunes, 28 de mayo, 2012 23:30
>> Don't worry about it. I will test
>> each platform or get others to before enabling, at least
>> some popular majority of them. I no longer have any Alphas.
>> Eventually I might ask for ssh access to an Alpha or
>> reacquire hardware. Anyway, don't worry. I generally know
>> what I'm doing.
>> 
>> - Jay (briefly/pocket-sized-computer-aka-phone)
>> 
>> On May 28, 2012, at 7:22 AM, "Daniel Alejandro Benavides D."
>> <dabenavidesd at yahoo.es>
>> wrote:
>> 
>>> Hi Jay:
>>> Where are you testing this, or have you tested this on
>> an Alpha, I might get access, but I notice you dropped the
>> libdecnumber, stuff right?
>>> Thanks in advance
>>> 
>>> --- El lun, 28/5/12, Jay Krell <jkrell at elego.de>
>> escribi?:
>>> 
>>>> De: Jay Krell <jkrell at elego.de>
>>>> Asunto: [M3commit] CVS Update: cm3
>>>> Para: m3commit at elegosoft.com
>>>> Fecha: lunes, 28 de mayo, 2012 05:47
>>>> CVSROOT:    /usr/cvs
>>>> Changes by:   
>>>> jkrell at birch.    12/05/28 10:47:05
>>>> 
>>>> Modified files:
>>>>   cm3/m3-sys/m3cc/gcc-4.6/: configure 
>>>>   ./: configure 
>>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/:
>> Makefile.in
>>>> auto-inc-dec.c 
>>>> 
>>>> 
>>>> basic-block.h builtins.c 
>>>> 
>>>> 
>>>> c-aux-info.c c-convert.c c-decl.c 
>>>> 
>>>> 
>>>> c-errors.c c-lang.c c-lang.h 
>>>> 
>>>> 
>>>> c-objc-common.c c-parser.c 
>>>> 
>>>> 
>>>> c-tree.h c-typeck.c calls.c 
>>>> 
>>>> 
>>>> cfgexpand.c cfgloop.h cgraph.c 
>>>> 
>>>> 
>>>> cgraph.h cgraphbuild.c 
>>>> 
>>>> 
>>>> cgraphunit.c combine.c configure 
>>>> 
>>>> 
>>>> configure.ac cppdefault.c 
>>>> 
>>>> 
>>>> cppdefault.h cppspec.c cse.c 
>>>> 
>>>> 
>>>> expr.c final.c fold-const.c gcc.c 
>>>> 
>>>> 
>>>> gccspec.c gcse.c gengtype-lex.c 
>>>> 
>>>> 
>>>> gengtype-lex.l gengtype.c 
>>>> 
>>>> 
>>>> gimple-fold.c gimple.c gimplify.c 
>>>> 
>>>> 
>>>> incpath.c intl.c ipa-cp.c 
>>>> 
>>>> 
>>>> ipa-inline.c ipa-prop.c ipa-prop.h 
>>>> 
>>>> 
>>>> ipa-ref.h ipa-utils.c ipa.c 
>>>> 
>>>> 
>>>> ira-build.c ira-conflicts.c 
>>>> 
>>>> 
>>>> ira-int.h ira.c ira.h libgcov.c 
>>>> 
>>>> 
>>>> loop-iv.c loop-unswitch.c opts.c 
>>>> 
>>>> 
>>>> passes.c postreload.c predict.c 
>>>> 
>>>> 
>>>> profile.c sched-vis.c 
>>>> 
>>>> 
>>>> sel-sched-dump.c store-motion.c 
>>>> 
>>>> 
>>>> stringpool.c targhooks.c toplev.c 
>>>> 
>>>> 
>>>> tree-cfg.c tree-chrec.c 
>>>> 
>>>> 
>>>> tree-complex.c tree-eh.c 
>>>> 
>>>> 
>>>> tree-flow.h tree-inline.c 
>>>> 
>>>> 
>>>> tree-nested.c tree-object-size.c 
>>>> 
>>>> 
>>>> tree-outof-ssa.c tree-parloops.c 
>>>> 
>>>> 
>>>> tree-pass.h tree-pretty-print.c 
>>>> 
>>>> 
>>>> tree-profile.c 
>>>> 
>>>> 
>>>> tree-scalar-evolution.c tree-sra.c 
>>>> 
>>>> 
>>>> tree-ssa-address.c 
>>>> 
>>>> 
>>>> tree-ssa-alias.c 
>>>> 
>>>> 
>>>> tree-ssa-copyrename.c 
>>>> 
>>>> 
>>>> tree-ssa-dce.c tree-ssa-dom.c 
>>>> 
>>>> 
>>>> tree-ssa-loop-ivopts.c 
>>>> 
>>>> 
>>>> tree-ssa-loop-manip.c 
>>>> 
>>>> 
>>>> tree-ssa-loop.c tree-ssa-phiopt.c 
>>>> 
>>>> 
>>>> tree-ssa-structalias.c 
>>>> 
>>>> 
>>>> tree-ssa-uncprop.c tree-ssa.c 
>>>> 
>>>> 
>>>> tree-vect-data-refs.c 
>>>> 
>>>> 
>>>> tree-vect-generic.c 
>>>> 
>>>> 
>>>> tree-vect-loop-manip.c 
>>>> 
>>>> 
>>>> tree-vect-loop.c 
>>>> 
>>>> 
>>>> tree-vect-patterns.c 
>>>> 
>>>> 
>>>> tree-vect-slp.c tree-vect-stmts.c 
>>>> 
>>>> 
>>>> tree-vrp.c tree.h unwind-c.c 
>>>> 
>>>> 
>>>> unwind-compat.c unwind-compat.h 
>>>> 
>>>> 
>>>> unwind-dw2-fde-compat.c 
>>>> 
>>>> 
>>>> unwind-dw2-fde-darwin.c 
>>>> 
>>>> 
>>>> unwind-dw2-fde-glibc.c 
>>>> 
>>>> 
>>>> unwind-dw2-fde.c unwind-dw2-fde.h 
>>>> 
>>>> 
>>>> unwind-dw2.c unwind-dw2.h 
>>>> 
>>>> 
>>>> unwind-generic.h unwind-pe.h 
>>>> 
>>>> 
>>>> unwind-sjlj.c value-prof.c 
>>>> 
>>>> 
>>>> var-tracking.c varpool.c web.c 
>>>>   ./: Makefile.in auto-inc-dec.c
>>>> basic-block.h builtins.c 
>>>>       c-aux-info.c
>> c-convert.c
>>>> c-decl.c c-errors.c c-lang.c 
>>>>       c-lang.h
>> c-objc-common.c
>>>> c-parser.c c-tree.h c-typeck.c 
>>>>       calls.c cfgexpand.c
>>>> cfgloop.h cgraph.c cgraph.h 
>>>>       cgraphbuild.c
>> cgraphunit.c
>>>> combine.c configure configure.ac 
>>>>       cppdefault.c
>> cppdefault.h
>>>> cppspec.c cse.c expr.c final.c 
>>>>       fold-const.c gcc.c
>>>> gccspec.c gcse.c gengtype-lex.c 
>>>>       gengtype-lex.l
>> gengtype.c
>>>> gimple-fold.c gimple.c gimplify.c 
>>>>       incpath.c intl.c
>> ipa-cp.c
>>>> ipa-inline.c ipa-prop.c ipa-prop.h 
>>>>       ipa-ref.h ipa-utils.c
>> ipa.c
>>>> ira-build.c ira-conflicts.c 
>>>>       ira-int.h ira.c ira.h
>>>> libgcov.c loop-iv.c loop-unswitch.c 
>>>>       opts.c passes.c
>>>> postreload.c predict.c profile.c sched-vis.c 
>>>>       sel-sched-dump.c
>>>> store-motion.c stringpool.c targhooks.c 
>>>>       toplev.c tree-cfg.c
>>>> tree-chrec.c tree-complex.c tree-eh.c 
>>>>       tree-flow.h
>> tree-inline.c
>>>> tree-nested.c tree-object-size.c 
>>>>       tree-outof-ssa.c
>>>> tree-parloops.c tree-pass.h 
>>>>       tree-pretty-print.c
>>>> tree-profile.c tree-scalar-evolution.c 
>>>>       tree-sra.c
>>>> tree-ssa-address.c tree-ssa-alias.c 
>>>>       tree-ssa-copyrename.c
>>>> tree-ssa-dce.c tree-ssa-dom.c 
>>>>       tree-ssa-loop-ivopts.c
>>>> tree-ssa-loop-manip.c tree-ssa-loop.c 
>>>>       tree-ssa-phiopt.c
>>>> tree-ssa-structalias.c tree-ssa-uncprop.c 
>>>>       tree-ssa.c
>>>> tree-vect-data-refs.c tree-vect-generic.c 
>>>>       tree-vect-loop-manip.c
>>>> tree-vect-loop.c tree-vect-patterns.c 
>>>>       tree-vect-slp.c
>>>> tree-vect-stmts.c tree-vrp.c tree.h 
>>>>       unwind-c.c
>> unwind-compat.c
>>>> unwind-compat.h 
>>>>       unwind-dw2-fde-compat.c
>>>> unwind-dw2-fde-darwin.c 
>>>>       unwind-dw2-fde-glibc.c
>>>> unwind-dw2-fde.c unwind-dw2-fde.h 
>>>>       unwind-dw2.c
>> unwind-dw2.h
>>>> unwind-generic.h unwind-pe.h 
>>>>       unwind-sjlj.c
>> value-prof.c
>>>> var-tracking.c varpool.c web.c 
>>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
>>>> darwin-protos.h darwin.c 
>>>> 
>>>> 
>>>>        darwin.h 
>>>>   ./: darwin-protos.h darwin.c darwin.h
>> 
>>>> 
>> cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
>>>> crtfastmath.c 
>>>> 
>>>> 
>>>> 
>> crtprec.c 
>>>> 
>>>> 
>>>> 
>>>> cygming-crtbegin.c 
>>>> 
>>>> 
>>>> 
>>>> cygming-crtend.c 
>>>> 
>>>> 
>>>> 
>> darwin.h
>>>> driver-i386.c 
>>>> 
>>>> 
>>>> 
>> gmon-sol2.c
>>>> i386.c 
>>>> 
>>>> 
>>>> 
>>>> netware-crt0.c 
>>>>   ./: crtfastmath.c crtprec.c
>>>> cygming-crtbegin.c cygming-crtend.c 
>>>>       darwin.h driver-i386.c
>>>> gmon-sol2.c i386.c netware-crt0.c 
>>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/:
>> lto.c 
>>>>   ./: lto.c 
>>>> 
>> cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
>>>> line-map.h 
>>>> 
>>>> Log message:
>>>>   work in progress -- can compile
>>>> everything now, but float exception right away
>>>> 
>>>> 
>> 


From dabenavidesd at yahoo.es  Wed May 30 02:03:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 01:03:34 +0100 (BST)
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <1572EB44-615A-4224-948B-DDC3DB23E57C@gmail.com>
Message-ID: <1338336214.27113.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
in reality PC AT aren't 64 bits wide, I guess in reality you can add a memory board to a i386 and that's it. Is just that same thing.
Bigger registers aren't a difference (the double number of registers and that's it for a register-based machine, like another ix86, the 82786 GPU for coprocessor and that's all), this is the same concept for a GPGPU nowadays, and they don't care at all to maintain compatibility to it so nobody has created a real 64-bit system after Tru64 and some other Unixes are, like Monterey project.
I mean there aren't real 64 bit systems, so I guess there isn't anything to test here in Gcc targets for real for PCs, they are the same that long before.
We don't have any new real HW or SW adapted for real so I don't know what else can be test.
Thanks in advance


--- El mar, 29/5/12, Jay <jay.krell at cornell.edu> escribi?:

> De: Jay <jay.krell at cornell.edu>
> Asunto: Re: [M3commit] CVS Update: cm3
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "Jay" <jay.krell at cornell.edu>, "<m3commit at elegosoft.com>" <m3commit at elegosoft.com>, "<m3devel at elegosoft.com>" <m3devel at elegosoft.com>
> Fecha: martes, 29 de mayo, 2012 18:15
> Daniel you don't make sense.
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On May 29, 2012, at 11:44 AM, "Daniel Alejandro Benavides
> D." <dabenavidesd at yahoo.es>
> wrote:
> 
> > Hi all:
> > good one, there isn't high-end user needs lately here,
> so I guess we shouldn't ask if we want to support other
> machines than just PC, perhaps, we should check more
> platforms at that level.
> > Any NT would not be affected but anything else is, HW
> for testing purposes isn't supported by NT (like debuggers),
> so there it isn't too much to support for that (lying on
> MIPS32, and Portable devices sometimes are RISC systems, now
> what is not aiming NT are desktops but bigger machines) but
> they are growing down so I don't know if they will become
> available again.
> > Thanks of Modula-3 hackers there is still more systems
> to check for all if interested in any. 
> > Thanks in advance
> > 
> > --- El lun, 28/5/12, Jay <jay.krell at cornell.edu>
> escribi?:
> > 
> >> De: Jay <jay.krell at cornell.edu>
> >> Asunto: Re: [M3commit] CVS Update: cm3
> >> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> >> CC: "<m3commit at elegosoft.com>"
> <m3commit at elegosoft.com>,
> "<m3devel at elegosoft.com>"
> <m3devel at elegosoft.com>
> >> Fecha: lunes, 28 de mayo, 2012 23:30
> >> Don't worry about it. I will test
> >> each platform or get others to before enabling, at
> least
> >> some popular majority of them. I no longer have any
> Alphas.
> >> Eventually I might ask for ssh access to an Alpha
> or
> >> reacquire hardware. Anyway, don't worry. I
> generally know
> >> what I'm doing.
> >> 
> >> - Jay (briefly/pocket-sized-computer-aka-phone)
> >> 
> >> On May 28, 2012, at 7:22 AM, "Daniel Alejandro
> Benavides D."
> >> <dabenavidesd at yahoo.es>
> >> wrote:
> >> 
> >>> Hi Jay:
> >>> Where are you testing this, or have you tested
> this on
> >> an Alpha, I might get access, but I notice you
> dropped the
> >> libdecnumber, stuff right?
> >>> Thanks in advance
> >>> 
> >>> --- El lun, 28/5/12, Jay Krell <jkrell at elego.de>
> >> escribi?:
> >>> 
> >>>> De: Jay Krell <jkrell at elego.de>
> >>>> Asunto: [M3commit] CVS Update: cm3
> >>>> Para: m3commit at elegosoft.com
> >>>> Fecha: lunes, 28 de mayo, 2012 05:47
> >>>> CVSROOT:    /usr/cvs
> >>>> Changes by:   
> >>>> jkrell at birch.    12/05/28
> 10:47:05
> >>>> 
> >>>> Modified files:
> >>>>   cm3/m3-sys/m3cc/gcc-4.6/:
> configure 
> >>>>   ./: configure 
> >>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/:
> >> Makefile.in
> >>>> auto-inc-dec.c 
> >>>> 
> >>>> 
> >>>> basic-block.h builtins.c 
> >>>> 
> >>>> 
> >>>> c-aux-info.c c-convert.c c-decl.c 
> >>>> 
> >>>> 
> >>>> c-errors.c c-lang.c c-lang.h 
> >>>> 
> >>>> 
> >>>> c-objc-common.c c-parser.c 
> >>>> 
> >>>> 
> >>>> c-tree.h c-typeck.c calls.c 
> >>>> 
> >>>> 
> >>>> cfgexpand.c cfgloop.h cgraph.c 
> >>>> 
> >>>> 
> >>>> cgraph.h cgraphbuild.c 
> >>>> 
> >>>> 
> >>>> cgraphunit.c combine.c configure 
> >>>> 
> >>>> 
> >>>> configure.ac cppdefault.c 
> >>>> 
> >>>> 
> >>>> cppdefault.h cppspec.c cse.c 
> >>>> 
> >>>> 
> >>>> expr.c final.c fold-const.c gcc.c 
> >>>> 
> >>>> 
> >>>> gccspec.c gcse.c gengtype-lex.c 
> >>>> 
> >>>> 
> >>>> gengtype-lex.l gengtype.c 
> >>>> 
> >>>> 
> >>>> gimple-fold.c gimple.c gimplify.c 
> >>>> 
> >>>> 
> >>>> incpath.c intl.c ipa-cp.c 
> >>>> 
> >>>> 
> >>>> ipa-inline.c ipa-prop.c ipa-prop.h 
> >>>> 
> >>>> 
> >>>> ipa-ref.h ipa-utils.c ipa.c 
> >>>> 
> >>>> 
> >>>> ira-build.c ira-conflicts.c 
> >>>> 
> >>>> 
> >>>> ira-int.h ira.c ira.h libgcov.c 
> >>>> 
> >>>> 
> >>>> loop-iv.c loop-unswitch.c opts.c 
> >>>> 
> >>>> 
> >>>> passes.c postreload.c predict.c 
> >>>> 
> >>>> 
> >>>> profile.c sched-vis.c 
> >>>> 
> >>>> 
> >>>> sel-sched-dump.c store-motion.c 
> >>>> 
> >>>> 
> >>>> stringpool.c targhooks.c toplev.c 
> >>>> 
> >>>> 
> >>>> tree-cfg.c tree-chrec.c 
> >>>> 
> >>>> 
> >>>> tree-complex.c tree-eh.c 
> >>>> 
> >>>> 
> >>>> tree-flow.h tree-inline.c 
> >>>> 
> >>>> 
> >>>> tree-nested.c tree-object-size.c 
> >>>> 
> >>>> 
> >>>> tree-outof-ssa.c tree-parloops.c 
> >>>> 
> >>>> 
> >>>> tree-pass.h tree-pretty-print.c 
> >>>> 
> >>>> 
> >>>> tree-profile.c 
> >>>> 
> >>>> 
> >>>> tree-scalar-evolution.c tree-sra.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-address.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-alias.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-copyrename.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-dce.c tree-ssa-dom.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-loop-ivopts.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-loop-manip.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-loop.c tree-ssa-phiopt.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-structalias.c 
> >>>> 
> >>>> 
> >>>> tree-ssa-uncprop.c tree-ssa.c 
> >>>> 
> >>>> 
> >>>> tree-vect-data-refs.c 
> >>>> 
> >>>> 
> >>>> tree-vect-generic.c 
> >>>> 
> >>>> 
> >>>> tree-vect-loop-manip.c 
> >>>> 
> >>>> 
> >>>> tree-vect-loop.c 
> >>>> 
> >>>> 
> >>>> tree-vect-patterns.c 
> >>>> 
> >>>> 
> >>>> tree-vect-slp.c tree-vect-stmts.c 
> >>>> 
> >>>> 
> >>>> tree-vrp.c tree.h unwind-c.c 
> >>>> 
> >>>> 
> >>>> unwind-compat.c unwind-compat.h 
> >>>> 
> >>>> 
> >>>> unwind-dw2-fde-compat.c 
> >>>> 
> >>>> 
> >>>> unwind-dw2-fde-darwin.c 
> >>>> 
> >>>> 
> >>>> unwind-dw2-fde-glibc.c 
> >>>> 
> >>>> 
> >>>> unwind-dw2-fde.c unwind-dw2-fde.h 
> >>>> 
> >>>> 
> >>>> unwind-dw2.c unwind-dw2.h 
> >>>> 
> >>>> 
> >>>> unwind-generic.h unwind-pe.h 
> >>>> 
> >>>> 
> >>>> unwind-sjlj.c value-prof.c 
> >>>> 
> >>>> 
> >>>> var-tracking.c varpool.c web.c 
> >>>>   ./: Makefile.in
> auto-inc-dec.c
> >>>> basic-block.h builtins.c 
> >>>>   
>    c-aux-info.c
> >> c-convert.c
> >>>> c-decl.c c-errors.c c-lang.c 
> >>>>       c-lang.h
> >> c-objc-common.c
> >>>> c-parser.c c-tree.h c-typeck.c 
> >>>>       calls.c
> cfgexpand.c
> >>>> cfgloop.h cgraph.c cgraph.h 
> >>>>   
>    cgraphbuild.c
> >> cgraphunit.c
> >>>> combine.c configure configure.ac 
> >>>>   
>    cppdefault.c
> >> cppdefault.h
> >>>> cppspec.c cse.c expr.c final.c 
> >>>>       fold-const.c
> gcc.c
> >>>> gccspec.c gcse.c gengtype-lex.c 
> >>>>   
>    gengtype-lex.l
> >> gengtype.c
> >>>> gimple-fold.c gimple.c gimplify.c 
> >>>>       incpath.c
> intl.c
> >> ipa-cp.c
> >>>> ipa-inline.c ipa-prop.c ipa-prop.h 
> >>>>       ipa-ref.h
> ipa-utils.c
> >> ipa.c
> >>>> ira-build.c ira-conflicts.c 
> >>>>       ira-int.h
> ira.c ira.h
> >>>> libgcov.c loop-iv.c loop-unswitch.c 
> >>>>       opts.c
> passes.c
> >>>> postreload.c predict.c profile.c
> sched-vis.c 
> >>>>   
>    sel-sched-dump.c
> >>>> store-motion.c stringpool.c targhooks.c 
> >>>>       toplev.c
> tree-cfg.c
> >>>> tree-chrec.c tree-complex.c tree-eh.c 
> >>>>       tree-flow.h
> >> tree-inline.c
> >>>> tree-nested.c tree-object-size.c 
> >>>>   
>    tree-outof-ssa.c
> >>>> tree-parloops.c tree-pass.h 
> >>>>   
>    tree-pretty-print.c
> >>>> tree-profile.c tree-scalar-evolution.c 
> >>>>       tree-sra.c
> >>>> tree-ssa-address.c tree-ssa-alias.c 
> >>>>   
>    tree-ssa-copyrename.c
> >>>> tree-ssa-dce.c tree-ssa-dom.c 
> >>>>   
>    tree-ssa-loop-ivopts.c
> >>>> tree-ssa-loop-manip.c tree-ssa-loop.c 
> >>>>   
>    tree-ssa-phiopt.c
> >>>> tree-ssa-structalias.c tree-ssa-uncprop.c 
> >>>>       tree-ssa.c
> >>>> tree-vect-data-refs.c tree-vect-generic.c 
> >>>>   
>    tree-vect-loop-manip.c
> >>>> tree-vect-loop.c tree-vect-patterns.c 
> >>>>   
>    tree-vect-slp.c
> >>>> tree-vect-stmts.c tree-vrp.c tree.h 
> >>>>       unwind-c.c
> >> unwind-compat.c
> >>>> unwind-compat.h 
> >>>>   
>    unwind-dw2-fde-compat.c
> >>>> unwind-dw2-fde-darwin.c 
> >>>>   
>    unwind-dw2-fde-glibc.c
> >>>> unwind-dw2-fde.c unwind-dw2-fde.h 
> >>>>   
>    unwind-dw2.c
> >> unwind-dw2.h
> >>>> unwind-generic.h unwind-pe.h 
> >>>>   
>    unwind-sjlj.c
> >> value-prof.c
> >>>> var-tracking.c varpool.c web.c 
> >>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/config/:
> >>>> darwin-protos.h darwin.c 
> >>>> 
> >>>> 
> >>>>        darwin.h 
> >>>>   ./: darwin-protos.h
> darwin.c darwin.h
> >> 
> >>>> 
> >> cm3/m3-sys/m3cc/gcc-4.6/gcc/config/i386/:
> >>>> crtfastmath.c 
> >>>> 
> >>>> 
> >>>> 
> >> crtprec.c 
> >>>> 
> >>>> 
> >>>> 
> >>>> cygming-crtbegin.c 
> >>>> 
> >>>> 
> >>>> 
> >>>> cygming-crtend.c 
> >>>> 
> >>>> 
> >>>> 
> >> darwin.h
> >>>> driver-i386.c 
> >>>> 
> >>>> 
> >>>> 
> >> gmon-sol2.c
> >>>> i386.c 
> >>>> 
> >>>> 
> >>>> 
> >>>> netware-crt0.c 
> >>>>   ./: crtfastmath.c
> crtprec.c
> >>>> cygming-crtbegin.c cygming-crtend.c 
> >>>>       darwin.h
> driver-i386.c
> >>>> gmon-sol2.c i386.c netware-crt0.c 
> >>>>   cm3/m3-sys/m3cc/gcc-4.6/gcc/lto/:
> >> lto.c 
> >>>>   ./: lto.c 
> >>>> 
> >> cm3/m3-sys/m3cc/gcc-4.6/libcpp/include/:
> >>>> line-map.h 
> >>>> 
> >>>> Log message:
> >>>>   work in progress -- can
> compile
> >>>> everything now, but float exception right
> away
> >>>> 
> >>>> 
> >> 
> 


From dragisha at m3w.org  Wed May 30 10:54:08 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 30 May 2012 10:54:08 +0200
Subject: [M3devel] portable hosting
In-Reply-To: <1338240156.6219.YahooMailClassic@web29704.mail.ird.yahoo.com>
References: <1338240156.6219.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>

Daniel,

I like your project. Please inform us on updates, when available!

Thanks in advance,
dd

p.s. :)

On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> or better make an assembly-coded C compiler in a Java language processor, and cross-boot assemble from a Modula-3 environment there so you could bootstrap a M3CG-system there.
> Thanks in advance
> 
> --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:
> 
>> De: Hendrik Boom <hendrik at topoi.pooq.com>
>> Asunto: [M3devel] portable hosting
>> Para: m3devel at elegosoft.com
>> Fecha: lunes, 28 de mayo, 2012 11:50
>> On Sun, May 20, 2012 at 02:32:14PM
>> -0700, Jay wrote:
>>> 
>>> Btw, rewriting all of m3front in C or C++ or Java
>> probably wouldn't be very difficult.
>> 
>> Would it be more or less difficult than writing a code
>> generator that 
>> generated C or C++ code?  THe code generator could do
>> the rewrite for 
>> you.  Bt it wouldn't be very readable code.
>> 



From dabenavidesd at yahoo.es  Wed May 30 13:34:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 12:34:24 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
Message-ID: <1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
I like the option but because there isn't more than that in a featured phone, which is the most common kind of thing in this world; S40, has its own JVM, if this about popularity.
Crazy and simple as it is.

Thanks in advance

--- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] portable hosting
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> Daniel,
> 
> I like your project. Please inform us on updates, when
> available!
> 
> Thanks in advance,
> dd
> 
> p.s. :)
> 
> On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> wrote:
> 
> > Hi all:
> > or better make an assembly-coded C compiler in a Java
> language processor, and cross-boot assemble from a Modula-3
> environment there so you could bootstrap a M3CG-system
> there.
> > Thanks in advance
> > 
> > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> escribi?:
> > 
> >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> >> Asunto: [M3devel] portable hosting
> >> Para: m3devel at elegosoft.com
> >> Fecha: lunes, 28 de mayo, 2012 11:50
> >> On Sun, May 20, 2012 at 02:32:14PM
> >> -0700, Jay wrote:
> >>> 
> >>> Btw, rewriting all of m3front in C or C++ or
> Java
> >> probably wouldn't be very difficult.
> >> 
> >> Would it be more or less difficult than writing a
> code
> >> generator that 
> >> generated C or C++ code?  THe code generator
> could do
> >> the rewrite for 
> >> you.  Bt it wouldn't be very readable code.
> >> 
> 
> 


From dragisha at m3w.org  Wed May 30 14:03:39 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 30 May 2012 14:03:39 +0200
Subject: [M3devel] cm3, NOPTHREAD
In-Reply-To: <COL101-W1C8E7FBA8B4CC5793DC42E6010@phx.gbl>
References: <555EDB08-5E0A-472A-9D93-FD890F924303@m3w.org>,
	<1337979476.29484.YahooMailClassic@web29703.mail.ird.yahoo.com>
	<COL101-W1C8E7FBA8B4CC5793DC42E6010@phx.gbl>
Message-ID: <0F4CD174-3D70-4A2C-8F11-461E1C4A1C5E@m3w.org>

Of course.


On May 26, 2012, at 12:09 AM, Jay K wrote:

> -DNOPTHREAD only directly changes m3core.
> The rest of the system can be compiled w/ or w/o it. But the new m3core causes a need for some rebuild.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120530/02a4f856/attachment-0002.html>

From hendrik at topoi.pooq.com  Wed May 30 14:20:57 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 30 May 2012 08:20:57 -0400
Subject: [M3devel] portable hosting
In-Reply-To: <1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
	<1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <20120530122057.GA28287@topoi.pooq.com>

I've only heard of two different Java virtual machines -- the one Sun 
wrote, which I believe has been independently implementedonce or twice, 
and the one Google wrote as part of Android, which is designed for 
efficient JIT compilation.

Is this one of these, or is there yet another?

-- hendrik

On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all:
> I like the option but because there isn't more than that in a featured 
> phone, which is the most common kind of thing in this world; S40, has 
> its own JVM, if this about popularity.
> Crazy and simple as it is.
> 
> Thanks in advance
> 
> --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> > De: Dragi?a Duri? <dragisha at m3w.org>
> > Asunto: Re: [M3devel] portable hosting
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > Daniel,
> > 
> > I like your project. Please inform us on updates, when
> > available!
> > 
> > Thanks in advance,
> > dd
> > 
> > p.s. :)
> > 
> > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > wrote:
> > 
> > > Hi all:
> > > or better make an assembly-coded C compiler in a Java
> > language processor, and cross-boot assemble from a Modula-3
> > environment there so you could bootstrap a M3CG-system
> > there.
> > > Thanks in advance
> > > 
> > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > escribi?:
> > > 
> > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > >> Asunto: [M3devel] portable hosting
> > >> Para: m3devel at elegosoft.com
> > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > >> On Sun, May 20, 2012 at 02:32:14PM
> > >> -0700, Jay wrote:
> > >>> 
> > >>> Btw, rewriting all of m3front in C or C++ or
> > Java
> > >> probably wouldn't be very difficult.
> > >> 
> > >> Would it be more or less difficult than writing a
> > code
> > >> generator that 
> > >> generated C or C++ code?  THe code generator
> > could do
> > >> the rewrite for 
> > >> you.  Bt it wouldn't be very readable code.
> > >> 
> > 
> >


From dabenavidesd at yahoo.es  Wed May 30 14:53:41 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 13:53:41 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <20120530122057.GA28287@topoi.pooq.com>
Message-ID: <1338382421.96630.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
It theirs original EPL, but wasn't further developed because for S60 as a JVM able phone, contrary to CM J-V-M) isn't able to be used as a library, So I thought this was great news for us. 
I have the package for S60.
Thanks in advance


--- El mi?, 30/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] portable hosting
> Para: m3devel at elegosoft.com
> Fecha: mi?rcoles, 30 de mayo, 2012 07:20
> I've only heard of two different Java
> virtual machines -- the one Sun 
> wrote, which I believe has been independently
> implementedonce or twice, 
> and the one Google wrote as part of Android, which is
> designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro
> Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than
> that in a featured 
> > phone, which is the most common kind of thing in this
> world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com,
> "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates,
> when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro
> Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler
> in a Java
> > > language processor, and cross-boot assemble from a
> Modula-3
> > > environment there so you could bootstrap a
> M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or
> C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than
> writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?  THe code
> generator
> > > could do
> > > >> the rewrite for 
> > > >> you.  Bt it wouldn't be very
> readable code.
> > > >> 
> > > 
> > >
> 


From dabenavidesd at yahoo.es  Wed May 30 15:10:42 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 14:10:42 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <1338382421.96630.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <1338383442.54852.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
in fact there is one else more, A 16-bit IBM java tool set:
http://books.google.com.co/books?id=vj4EAAAAMBAJ&lpg=PA12&dq=java%20s40&pg=PA12#v=onepage&q&f=false

Thanks in advance

--- El mi?, 30/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] portable hosting
> Para: "Hendrik Boom" <hendrik at topoi.pooq.com>
> CC: m3devel at elegosoft.com
> Fecha: mi?rcoles, 30 de mayo, 2012 07:53
> Hi all:
> It theirs original EPL, but wasn't further developed because
> for S60 as a JVM able phone, contrary to CM J-V-M) isn't
> able to be used as a library, So I thought this was great
> news for us. 
> I have the package for S60.
> Thanks in advance
> 
> 
> --- El mi?, 30/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> escribi?:
> 
> > De: Hendrik Boom <hendrik at topoi.pooq.com>
> > Asunto: Re: [M3devel] portable hosting
> > Para: m3devel at elegosoft.com
> > Fecha: mi?rcoles, 30 de mayo, 2012 07:20
> > I've only heard of two different Java
> > virtual machines -- the one Sun 
> > wrote, which I believe has been independently
> > implementedonce or twice, 
> > and the one Google wrote as part of Android, which is
> > designed for 
> > efficient JIT compilation.
> > 
> > Is this one of these, or is there yet another?
> > 
> > -- hendrik
> > 
> > On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel
> Alejandro
> > Benavides D. wrote:
> > > Hi all:
> > > I like the option but because there isn't more
> than
> > that in a featured 
> > > phone, which is the most common kind of thing in
> this
> > world; S40, has 
> > > its own JVM, if this about popularity.
> > > Crazy and simple as it is.
> > > 
> > > Thanks in advance
> > > 
> > > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org>
> > escribi?:
> > > 
> > > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > > Asunto: Re: [M3devel] portable hosting
> > > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > > CC: m3devel at elegosoft.com,
> > "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > > Daniel,
> > > > 
> > > > I like your project. Please inform us on
> updates,
> > when
> > > > available!
> > > > 
> > > > Thanks in advance,
> > > > dd
> > > > 
> > > > p.s. :)
> > > > 
> > > > On May 28, 2012, at 11:22 PM, Daniel
> Alejandro
> > Benavides D.
> > > > wrote:
> > > > 
> > > > > Hi all:
> > > > > or better make an assembly-coded C
> compiler
> > in a Java
> > > > language processor, and cross-boot assemble
> from a
> > Modula-3
> > > > environment there so you could bootstrap a
> > M3CG-system
> > > > there.
> > > > > Thanks in advance
> > > > > 
> > > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > > escribi?:
> > > > > 
> > > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > > >> Asunto: [M3devel] portable hosting
> > > > >> Para: m3devel at elegosoft.com
> > > > >> Fecha: lunes, 28 de mayo, 2012
> 11:50
> > > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > > >> -0700, Jay wrote:
> > > > >>> 
> > > > >>> Btw, rewriting all of m3front in
> C or
> > C++ or
> > > > Java
> > > > >> probably wouldn't be very
> difficult.
> > > > >> 
> > > > >> Would it be more or less difficult
> than
> > writing a
> > > > code
> > > > >> generator that 
> > > > >> generated C or C++ code?  THe
> code
> > generator
> > > > could do
> > > > >> the rewrite for 
> > > > >> you.  Bt it wouldn't be very
> > readable code.
> > > > >> 
> > > > 
> > > >
> >
> 


From microcode at zoho.com  Wed May 30 15:26:04 2012
From: microcode at zoho.com (microcode at zoho.com)
Date: Wed, 30 May 2012 13:26:04 +0000
Subject: [M3devel] portable hosting
In-Reply-To: <20120530122057.GA28287@topoi.pooq.com>
References: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
	<1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120530122057.GA28287@topoi.pooq.com>
Message-ID: <1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>

There are tons of Java JVMs. IBM wrote at least two. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 08:20:57 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

I've only heard of two different Java virtual machines -- the one Sun 
wrote, which I believe has been independently implementedonce or twice, 
and the one Google wrote as part of Android, which is designed for 
efficient JIT compilation.

Is this one of these, or is there yet another?

-- hendrik

On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> Hi all:
> I like the option but because there isn't more than that in a featured 
> phone, which is the most common kind of thing in this world; S40, has 
> its own JVM, if this about popularity.
> Crazy and simple as it is.
> 
> Thanks in advance
> 
> --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> > De: Dragi?a Duri? <dragisha at m3w.org>
> > Asunto: Re: [M3devel] portable hosting
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > Daniel,
> > 
> > I like your project. Please inform us on updates, when
> > available!
> > 
> > Thanks in advance,
> > dd
> > 
> > p.s. :)
> > 
> > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > wrote:
> > 
> > > Hi all:
> > > or better make an assembly-coded C compiler in a Java
> > language processor, and cross-boot assemble from a Modula-3
> > environment there so you could bootstrap a M3CG-system
> > there.
> > > Thanks in advance
> > > 
> > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > escribi?:
> > > 
> > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > >> Asunto: [M3devel] portable hosting
> > >> Para: m3devel at elegosoft.com
> > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > >> On Sun, May 20, 2012 at 02:32:14PM
> > >> -0700, Jay wrote:
> > >>> 
> > >>> Btw, rewriting all of m3front in C or C++ or
> > Java
> > >> probably wouldn't be very difficult.
> > >> 
> > >> Would it be more or less difficult than writing a
> > code
> > >> generator that 
> > >> generated C or C++ code?  THe code generator
> > could do
> > >> the rewrite for 
> > >> you.  Bt it wouldn't be very readable code.
> > >> 
> > 
> >

From hendrik at topoi.pooq.com  Wed May 30 15:51:14 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Wed, 30 May 2012 09:51:14 -0400
Subject: [M3devel] portable hosting
In-Reply-To: <1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>
References: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
	<1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120530122057.GA28287@topoi.pooq.com>
	<1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>
Message-ID: <20120530135114.GB28287@topoi.pooq.com>

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?  Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?  THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.  Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >


From dabenavidesd at yahoo.es  Wed May 30 16:08:32 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 15:08:32 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>
Message-ID: <1338386912.57598.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
But original for reference for a platform, I think as Modula-3 was VAX mostly, and Olivetti Modula-3 was ARM mostly.
Thanks in advance

--- El mi?, 30/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

> De: microcode at zoho.com <microcode at zoho.com>
> Asunto: Re: [M3devel] portable hosting
> Para: m3devel at elegosoft.com
> Fecha: mi?rcoles, 30 de mayo, 2012 08:26
> There are tons of Java JVMs. IBM
> wrote at least two. 
> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines --
> the one Sun 
> wrote, which I believe has been independently
> implementedonce or twice, 
> and the one Google wrote as part of Android, which is
> designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro
> Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than
> that in a featured 
> > phone, which is the most common kind of thing in this
> world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org>
> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com,
> "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates,
> when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro
> Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler
> in a Java
> > > language processor, and cross-boot assemble from a
> Modula-3
> > > environment there so you could bootstrap a
> M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or
> C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than
> writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?  THe code
> generator
> > > could do
> > > >> the rewrite for 
> > > >> you.  Bt it wouldn't be very
> readable code.
> > > >> 
> > > 
> > >
> 


From microcode at zoho.com  Wed May 30 16:11:39 2012
From: microcode at zoho.com (microcode at zoho.com)
Date: Wed, 30 May 2012 14:11:39 +0000
Subject: [M3devel] portable hosting
In-Reply-To: <20120530135114.GB28287@topoi.pooq.com>
References: <60481A39-F55E-48E8-A3A1-A935FBC45A9B@m3w.org>
	<1338377664.78165.YahooMailClassic@web29701.mail.ird.yahoo.com>
	<20120530122057.GA28287@topoi.pooq.com>
	<1007964955-1338384364-cardhu_decombobulator_blackberry.rim.net-2079489430-@b1.c1.bise3.blackberry>
	<20120530135114.GB28287@topoi.pooq.com>
Message-ID: <754448862-1338387100-cardhu_decombobulator_blackberry.rim.net-349729625-@b1.c1.bise3.blackberry>

I'm sorry, I don't understand what you are asking. 

As much as I loathe WikiPedia

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

Is a good starting point. I am pretty sure there are dozens more not listed there though. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 09:51:14 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?  Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?  THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.  Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >

From dabenavidesd at yahoo.es  Wed May 30 17:13:13 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 16:13:13 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <754448862-1338387100-cardhu_decombobulator_blackberry.rim.net-349729625-@b1.c1.bise3.blackberry>
Message-ID: <1338390793.36979.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
I think the issue is back to the stream media, since a JVM ready product was only to be Sun JVM ready, so, any other implementation was both a product officially unrelated and JVM ready. I don't know how SUN thought about JIT-compilers, etc.
Thanks in advance


--- El mi?, 30/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

De: microcode at zoho.com <microcode at zoho.com>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com
Fecha: mi?rcoles, 30 de mayo, 2012 09:11

I'm sorry, I don't understand what you are asking. 

As much as I loathe WikiPedia

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


Is a good starting point. I am pretty sure there are dozens more not listed there though. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 09:51:14 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?? Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >> Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?? THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.? Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120530/d325b80d/attachment-0002.html>

From dabenavidesd at yahoo.es  Wed May 30 18:30:47 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 17:30:47 +0100 (BST)
Subject: [M3devel] portable hosting
In-Reply-To: <1338390793.36979.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <1338395447.59773.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
this is to say, JVM non-SUN are not JVM products compatible, CM J-V-M but I don't know how it was related to it.
Something akin PC AT, the latter are not clones, so you know. Now, if Compaq did the same thing with their Compaq Fast VM, as it did with Compaq deskpro, that would be managing the JVM to produce another IR, that was the idea if the memory issues were corrected, as JVm leaked for years, I think Dragisha sent that article about it, didn't he?
Thanks in advance

--- El mi?, 30/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com, microcode at zoho.com
Fecha: mi?rcoles, 30 de mayo, 2012 10:13

Hi all:
I think the issue is back to the stream media, since a JVM ready product was only to be Sun JVM ready, so, any other implementation was both a product officially unrelated and JVM ready. I don't know how SUN thought about JIT-compilers, etc.
Thanks in advance


--- El mi?, 30/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

De: microcode at zoho.com <microcode at zoho.com>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com
Fecha: mi?rcoles, 30 de mayo, 2012 09:11

I'm sorry, I don't understand what you are asking. 

As much as I loathe WikiPedia

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


Is a good starting point. I am pretty sure there are dozens more not listed there though. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 09:51:14 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?? Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of
 thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> > > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > > >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >>
 Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?? THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.? Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120530/30a30073/attachment-0002.html>

From dabenavidesd at yahoo.es  Wed May 30 21:33:13 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 May 2012 20:33:13 +0100 (BST)
Subject: [M3devel] X86/97 targets? [was: Re:  portable hosting]
In-Reply-To: <1338395447.59773.YahooMailClassic@web29705.mail.ird.yahoo.com>
Message-ID: <1338406393.56947.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
Someone has checked what is a x97?
Was x97 another take by i86 something akin, they created a 300 million fund for anyone experimenting on it? (Old strategy for companies Elego folks something to say ...) Do we want this:
http://confidential.eetimes.com/news-updates/4373963/Ultrabooks-duel-ultralights-at-Computex

P.S: If you need this article to see complete text please create a free account, else I can send it upon request. 

Thanks in advance

--- El mi?, 30/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com, microcode at zoho.com
Fecha: mi?rcoles, 30 de mayo, 2012 11:30

Hi all:
this is to say, JVM non-SUN are not JVM products compatible, CM J-V-M but I don't know how it was related to it.
Something akin PC AT, the latter are not clones, so you know. Now, if Compaq did the same thing with their Compaq Fast VM, as it did with Compaq deskpro, that would be managing the JVM to produce another IR, that was the idea if the memory issues were corrected, as JVm leaked for years, I think Dragisha sent that article about it, didn't he?
Thanks in advance

--- El mi?, 30/5/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] portable hosting
Para: m3devel at elegosoft.com,
 microcode at zoho.com
Fecha: mi?rcoles, 30 de mayo, 2012 10:13

Hi all:
I think the issue is back to the stream media, since a JVM ready product was only to be Sun JVM ready, so, any other implementation was both a product officially unrelated and JVM ready. I don't know how SUN thought about JIT-compilers, etc.
Thanks in advance


--- El mi?, 30/5/12, microcode at zoho.com <microcode at zoho.com> escribi?:

De: microcode at zoho.com <microcode at zoho.com>
Asunto: Re: [M3devel] portable hosting
Para:
 m3devel at elegosoft.com
Fecha: mi?rcoles, 30 de mayo, 2012 09:11

I'm sorry, I don't understand what you are asking. 

As much as I loathe WikiPedia

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


Is a good starting point. I am pretty sure there are dozens more not listed there though. 

-----Original Message-----
From: Hendrik Boom <hendrik at topoi.pooq.com>
Date: Wed, 30 May 2012 09:51:14 
To: <m3devel at elegosoft.com>
Subject: Re: [M3devel] portable hosting

On Wed, May 30, 2012 at 01:26:04PM +0000, microcode at zoho.com wrote:
> There are tons of Java JVMs. IBM wrote at least two. 

Arethese multiple implementatioa of the same intermediate code?? Or 
completely different intermediate codes?

-- hendrik

> 
> -----Original Message-----
> From: Hendrik Boom <hendrik at topoi.pooq.com>
> Date: Wed, 30 May 2012 08:20:57 
> To: <m3devel at elegosoft.com>
> Subject: Re: [M3devel] portable hosting
> 
> I've only heard of
 two different Java virtual machines -- the one Sun 
> wrote, which I believe has been independently implementedonce or twice, 
> and the one Google wrote as part of Android, which is designed for 
> efficient JIT compilation.
> 
> Is this one of these, or is there yet another?
> 
> -- hendrik
> 
> On Wed, May 30, 2012 at 12:34:24PM +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > I like the option but because there isn't more than that in a featured 
> > phone, which is the most common kind of
 thing in this world; S40, has 
> > its own JVM, if this about popularity.
> > Crazy and simple as it is.
> > 
> > Thanks in advance
> > 
> > --- El mi?, 30/5/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> > 
> > > De: Dragi?a Duri? <dragisha at m3w.org>
> > > Asunto: Re: [M3devel] portable hosting
> > > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > > CC: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> > > Fecha: mi?rcoles, 30 de mayo, 2012 03:54
> > > Daniel,
> > > 
> > > I like your project. Please inform us on updates, when
> > > available!
> > > 
> > > Thanks in advance,
> >
 > dd
> > > 
> > > p.s. :)
> > > 
> > > On May 28, 2012, at 11:22 PM, Daniel Alejandro Benavides D.
> > > wrote:
> > > 
> > > > Hi all:
> > > > or better make an assembly-coded C compiler in a Java
> > > language processor, and cross-boot assemble from a Modula-3
> > > environment there so you could bootstrap a M3CG-system
> > > there.
> > > > Thanks in advance
> > > > 
> > > > --- El lun, 28/5/12, Hendrik Boom <hendrik at topoi.pooq.com>
> > > escribi?:
> > > > 
> > > >> De: Hendrik Boom <hendrik at topoi.pooq.com>
> > > >> Asunto: [M3devel] portable hosting
> > > >> Para: m3devel at elegosoft.com
> > >
 >> Fecha: lunes, 28 de mayo, 2012 11:50
> > > >> On Sun, May 20, 2012 at 02:32:14PM
> > > >> -0700, Jay wrote:
> > > >>> 
> > > >>> Btw, rewriting all of m3front in C or C++ or
> > > Java
> > > >> probably wouldn't be very difficult.
> > > >> 
> > > >>
 Would it be more or less difficult than writing a
> > > code
> > > >> generator that 
> > > >> generated C or C++ code?? THe code generator
> > > could do
> > > >> the rewrite for 
> > > >> you.? Bt it wouldn't be very readable code.
> > > >> 
> > > 
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120530/023e42ea/attachment-0002.html>

From dabenavidesd at yahoo.es  Thu May 31 15:13:39 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 31 May 2012 14:13:39 +0100 (BST)
Subject: [M3devel] Renewed interest in Modula-3 in HP Labs
Message-ID: <1338470019.63945.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
I see there is some products coming from HP, and others, but specially HP, claiming that provide lower consumption in data center power management.
As I see they are working in Tycoon as a Data processor (created in Germany and Europe).
As Greg Nelson wrote code for profiling the Alphas and Itanium, perhaps they are interested in work on ESC, but nevertheless Modula-3 and family languages (Quest) as Tycoon is based on them.
If I may say so, Quest was defined by its simple denotational semantics, which is the natural deduction system of Baby Modula-3 (though it lacks more than that, but you can process the language of it through the former)
Do we want to confirm that, if anyone interested in the TML - TVM please write me for any other questions or comments
Thanks in advance

http://www.eetimes.com/electronics-news/4373994/HP-cuts-data-center-power-in-lab-tests?cid=NL_EETimesDaily

http://tycoon.hpl.hp.com/~tycoon/doc/users_manual_en/ch-intro.html

http://wwwmatthes.in.tum.de/file/Publications/1992/Math92/paper.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120531/3d6c107d/attachment-0002.html>