From dknoto at next.com.pl  Thu Feb  2 21:04:45 2012
From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?B?S25vY2nxc2tp?=)
Date: Thu, 2 Feb 2012 21:04:45 +0100
Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling
 problem
In-Reply-To: <COL101-W2279CBB33BFAF0CEE87DC1E6720@phx.gbl>
References: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com>
	<COL101-W2279CBB33BFAF0CEE87DC1E6720@phx.gbl>
Message-ID: <20120202210445.6c03d7d9@wenus.next.com.pl>

Dnia 2012-01-31, o godz. 02:21:56
Jay K <jay.krell at cornell.edu> napisa?(a):

> 
>   > $ tar -zxf /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > *** cannot
>   > find package import-libs / m3-win/import-libs
> You don't have the full source tree.Among m3-sys, m3-tools, m3-ui, etc., you
> are missing m3-win.If there is an "all" archive, try it?

I tried compiling from full sources. I have not achieved success. After
compiling backend process dumps lot of errors like this:

ranlib  libbackend.a
g++  -g  -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wc++-compat -fno-common  -DHAVE_CONFIG_H  -o m3cgc1 m3cg/parse.o attribs.o
main.o tree-browser.o
libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a ../libiberty/libiberty.a
-rdynamic -ldl --- shipping from AMD64_LINUX ---

. => /usr/local/cm3/bin
  cm3cg           
 ==> /home/dknoto/Projekty/CM3-5.9.0-devel/m3-sys/m3cc done

=== package /home/dknoto/Projekty/CM3-5.9.0-devel/m3-libs/m3core ===
 +++ cm3 -build -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' $RARGS  && cm3
-ship $RARGS -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel'  +++ --- building
in AMD64_LINUX ---

ignoring ../src/m3overrides

new source -> compiling RTHooks.i3
m3cgc1: fatal error:  *** illegal type: 0x17, at m3cg_lineno 4
compilation terminated.
  m3_backend => 1
m3cc (aka cm3cg) failed compiling: RTHooks.ic
new source -> compiling RT0.i3
m3cgc1: fatal error:  *** illegal type: 0x17, at m3cg_lineno 4
compilation terminated.
...

Best regards
Dariusz. 


From dabenavidesd at yahoo.es  Thu Feb  2 22:47:13 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 2 Feb 2012 21:47:13 +0000 (GMT)
Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling
	problem
In-Reply-To: <20120202210445.6c03d7d9@wenus.next.com.pl>
Message-ID: <1328219233.94197.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
Well, Jay I pass that one onto you, because we still miss back end testing, but nevertheless this is better than before. 
Anyway, I guess we can make some proofs at least statically with compile time asserts, just to make an idea, but needs investigation (Jay do you have some idea? I might try myself).
Thanks in advance 

--- El jue, 2/2/12, Dariusz Knoci?ski <dknoto at next.com.pl> escribi?:

> De: Dariusz Knoci?ski <dknoto at next.com.pl>
> Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem
> Para: m3devel at elegosoft.com
> Fecha: jueves, 2 de febrero, 2012 15:04
> Dnia 2012-01-31, o godz. 02:21:56
> Jay K <jay.krell at cornell.edu>
> napisa?(a):
> 
> > 
> >   > $ tar -zxf
> /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > ***
> cannot
> >   > find package import-libs /
> m3-win/import-libs
> > You don't have the full source tree.Among m3-sys,
> m3-tools, m3-ui, etc., you
> > are missing m3-win.If there is an "all" archive, try
> it?
> 
> I tried compiling from full sources. I have not achieved
> success. After
> compiling backend process dumps lot of errors like this:
> 
> ranlib  libbackend.a
> g++  -g  -DIN_GCC   -W -Wall
> -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wmissing-format-attribute -pedantic
> -Wno-long-long
> -Wno-variadic-macros -Wno-overlength-strings
> -Wold-style-definition
> -Wc++-compat -fno-common  -DHAVE_CONFIG_H  -o
> m3cgc1 m3cg/parse.o attribs.o
> main.o tree-browser.o
> libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a
> ../libiberty/libiberty.a
> -rdynamic -ldl --- shipping from AMD64_LINUX ---
> 
> . => /usr/local/cm3/bin
>   cm3cg           
>  ==> /home/dknoto/Projekty/CM3-5.9.0-devel/m3-sys/m3cc
> done
> 
> === package
> /home/dknoto/Projekty/CM3-5.9.0-devel/m3-libs/m3core ===
>  +++ cm3 -build
> -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' $RARGS 
> && cm3
> -ship $RARGS
> -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel'  +++ ---
> building
> in AMD64_LINUX ---
> 
> ignoring ../src/m3overrides
> 
> new source -> compiling RTHooks.i3
> m3cgc1: fatal error:  *** illegal type: 0x17, at
> m3cg_lineno 4
> compilation terminated.
>   m3_backend => 1
> m3cc (aka cm3cg) failed compiling: RTHooks.ic
> new source -> compiling RT0.i3
> m3cgc1: fatal error:  *** illegal type: 0x17, at
> m3cg_lineno 4
> compilation terminated.
> ...
> 
> Best regards
> Dariusz. 
> 


From dabenavidesd at yahoo.es  Thu Feb  2 23:12:57 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 2 Feb 2012 22:12:57 +0000 (GMT)
Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling
	problem
In-Reply-To: <1328219233.94197.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <1328220777.53225.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I read somewhere m3cg or m3cc or "m3gcc" is just an automata. If I knew the class I would be able to print out its current state at compile time which will provide enough source for any compiler hacker to correct it, right?
Now, I need a tool to check what compilation is right or not to automate that process.
I will need to look for alternatives for doing that.
Thanks in advance

--- El jue, 2/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem
> Para: m3devel at elegosoft.com, "Dariusz Knoci?ski" <dknoto at next.com.pl>
> Fecha: jueves, 2 de febrero, 2012 16:47
> Hi all:
> Well, Jay I pass that one onto you, because we still miss
> back end testing, but nevertheless this is better than
> before. 
> Anyway, I guess we can make some proofs at least statically
> with compile time asserts, just to make an idea, but needs
> investigation (Jay do you have some idea? I might try
> myself).
> Thanks in advance 
> 
> --- El jue, 2/2/12, Dariusz Knoci?ski <dknoto at next.com.pl>
> escribi?:
> 
> > De: Dariusz Knoci?ski <dknoto at next.com.pl>
> > Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0
> 2011-11-19-02-40-49 compilling problem
> > Para: m3devel at elegosoft.com
> > Fecha: jueves, 2 de febrero, 2012 15:04
> > Dnia 2012-01-31, o godz. 02:21:56
> > Jay K <jay.krell at cornell.edu>
> > napisa?(a):
> > 
> > > 
> > >   > $ tar -zxf
> > /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > ***
> > cannot
> > >   > find package import-libs /
> > m3-win/import-libs
> > > You don't have the full source tree.Among m3-sys,
> > m3-tools, m3-ui, etc., you
> > > are missing m3-win.If there is an "all" archive,
> try
> > it?
> > 
> > I tried compiling from full sources. I have not
> achieved
> > success. After
> > compiling backend process dumps lot of errors like
> this:
> > 
> > ranlib  libbackend.a
> > g++  -g  -DIN_GCC   -W -Wall
> > -Wwrite-strings -Wstrict-prototypes
> > -Wmissing-prototypes -Wmissing-format-attribute
> -pedantic
> > -Wno-long-long
> > -Wno-variadic-macros -Wno-overlength-strings
> > -Wold-style-definition
> > -Wc++-compat -fno-common  -DHAVE_CONFIG_H 
> -o
> > m3cgc1 m3cg/parse.o attribs.o
> > main.o tree-browser.o
> > libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a
> > ../libiberty/libiberty.a
> > -rdynamic -ldl --- shipping from AMD64_LINUX ---
> > 
> > . => /usr/local/cm3/bin
> >   cm3cg       
>    
> >  ==>
> /home/dknoto/Projekty/CM3-5.9.0-devel/m3-sys/m3cc
> > done
> > 
> > === package
> > /home/dknoto/Projekty/CM3-5.9.0-devel/m3-libs/m3core
> ===
> >  +++ cm3 -build
> > -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' $RARGS 
> > && cm3
> > -ship $RARGS
> > -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' 
> +++ ---
> > building
> > in AMD64_LINUX ---
> > 
> > ignoring ../src/m3overrides
> > 
> > new source -> compiling RTHooks.i3
> > m3cgc1: fatal error:  *** illegal type: 0x17, at
> > m3cg_lineno 4
> > compilation terminated.
> >   m3_backend => 1
> > m3cc (aka cm3cg) failed compiling: RTHooks.ic
> > new source -> compiling RT0.i3
> > m3cgc1: fatal error:  *** illegal type: 0x17, at
> > m3cg_lineno 4
> > compilation terminated.
> > ...
> > 
> > Best regards
> > Dariusz. 
> >
> 


From jay.krell at cornell.edu  Fri Feb  3 17:13:55 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 3 Feb 2012 16:13:55 +0000
Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling
 problem
In-Reply-To: <1328220777.53225.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <1328219233.94197.YahooMailClassic@web29702.mail.ird.yahoo.com>,
	<1328220777.53225.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W582443CDE1FFAE46B12899E6710@phx.gbl>


Daniel, no.

Darious, how about cm3 -commands -keep?
This sort of error indicates either the wrong cm3cg is being run or it is being passed the wrong file, like mixing up .ic and .io files or somesuch.
Try adding -v to the cm3cg commands.
  You'll have to cd to the target directory as well (AMD64_LINUX).


 - Jay

> Date: Thu, 2 Feb 2012 22:12:57 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; dknoto at next.com.pl
> Subject: Re: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling	problem
> 
> Hi all:
> I read somewhere m3cg or m3cc or "m3gcc" is just an automata. If I knew the class I would be able to print out its current state at compile time which will provide enough source for any compiler hacker to correct it, right?
> Now, I need a tool to check what compilation is right or not to automate that process.
> I will need to look for alternatives for doing that.
> Thanks in advance
> 
> --- El jue, 2/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:
> 
> > De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> > Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem
> > Para: m3devel at elegosoft.com, "Dariusz Knoci?ski" <dknoto at next.com.pl>
> > Fecha: jueves, 2 de febrero, 2012 16:47
> > Hi all:
> > Well, Jay I pass that one onto you, because we still miss
> > back end testing, but nevertheless this is better than
> > before. 
> > Anyway, I guess we can make some proofs at least statically
> > with compile time asserts, just to make an idea, but needs
> > investigation (Jay do you have some idea? I might try
> > myself).
> > Thanks in advance 
> > 
> > --- El jue, 2/2/12, Dariusz Knoci?ski <dknoto at next.com.pl>
> > escribi?:
> > 
> > > De: Dariusz Knoci?ski <dknoto at next.com.pl>
> > > Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0
> > 2011-11-19-02-40-49 compilling problem
> > > Para: m3devel at elegosoft.com
> > > Fecha: jueves, 2 de febrero, 2012 15:04
> > > Dnia 2012-01-31, o godz. 02:21:56
> > > Jay K <jay.krell at cornell.edu>
> > > napisa?(a):
> > > 
> > > > 
> > > >   > $ tar -zxf
> > > /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > ***
> > > cannot
> > > >   > find package import-libs /
> > > m3-win/import-libs
> > > > You don't have the full source tree.Among m3-sys,
> > > m3-tools, m3-ui, etc., you
> > > > are missing m3-win.If there is an "all" archive,
> > try
> > > it?
> > > 
> > > I tried compiling from full sources. I have not
> > achieved
> > > success. After
> > > compiling backend process dumps lot of errors like
> > this:
> > > 
> > > ranlib  libbackend.a
> > > g++  -g  -DIN_GCC   -W -Wall
> > > -Wwrite-strings -Wstrict-prototypes
> > > -Wmissing-prototypes -Wmissing-format-attribute
> > -pedantic
> > > -Wno-long-long
> > > -Wno-variadic-macros -Wno-overlength-strings
> > > -Wold-style-definition
> > > -Wc++-compat -fno-common  -DHAVE_CONFIG_H 
> > -o
> > > m3cgc1 m3cg/parse.o attribs.o
> > > main.o tree-browser.o
> > > libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a
> > > ../libiberty/libiberty.a
> > > -rdynamic -ldl --- shipping from AMD64_LINUX ---
> > > 
> > > . => /usr/local/cm3/bin
> > >   cm3cg       
> >    
> > >  ==>
> > /home/dknoto/Projekty/CM3-5.9.0-devel/m3-sys/m3cc
> > > done
> > > 
> > > === package
> > > /home/dknoto/Projekty/CM3-5.9.0-devel/m3-libs/m3core
> > ===
> > >  +++ cm3 -build
> > > -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' $RARGS 
> > > && cm3
> > > -ship $RARGS
> > > -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' 
> > +++ ---
> > > building
> > > in AMD64_LINUX ---
> > > 
> > > ignoring ../src/m3overrides
> > > 
> > > new source -> compiling RTHooks.i3
> > > m3cgc1: fatal error:  *** illegal type: 0x17, at
> > > m3cg_lineno 4
> > > compilation terminated.
> > >   m3_backend => 1
> > > m3cc (aka cm3cg) failed compiling: RTHooks.ic
> > > new source -> compiling RT0.i3
> > > m3cgc1: fatal error:  *** illegal type: 0x17, at
> > > m3cg_lineno 4
> > > compilation terminated.
> > > ...
> > > 
> > > Best regards
> > > Dariusz. 
> > >
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120203/3e757b50/attachment.html>

From dragisha at m3w.org  Mon Feb  6 09:50:51 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 6 Feb 2012 09:50:51 +0100
Subject: [M3devel] open array parameter passing, to external C procedure
Message-ID: <C39EBA6D-0A62-44C5-ABA1-123EB7998453@m3w.org>

I have this case:

extern int epoll_wait (int __epfd, struct epoll_event *__events,
                       int __maxevents, int __timeout);

And I would like to do it like:

<*EXTERNAL*> 
PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF epoll_event; timeout: int := -1): int;

?
VAR
  events: ARRAY [0..MaxEvents-1] OF epoll_event;

?

WITH res = epoll_wait(epfd, events, 2) DO
  ?
END;

Can I expect cm3 to do "right thing". Or I have to place parameters "by hand" using ADR and SIZE?

TIA,
dd



From mika at async.caltech.edu  Mon Feb  6 14:40:29 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Mon, 06 Feb 2012 05:40:29 -0800
Subject: [M3devel] open array parameter passing, to external C procedure
In-Reply-To: <C39EBA6D-0A62-44C5-ABA1-123EB7998453@m3w.org> 
References: <C39EBA6D-0A62-44C5-ABA1-123EB7998453@m3w.org>
Message-ID: <20120206134029.949A01A205B@async.async.caltech.edu>


I don't think it's going to work.  The Modula-3 compiler usually inserts
metadata at ADR(x) where x is an array of any type.

I know using ADDRESS works for the declaration, and then ADR(events[0]) 
for passing.  No need for SIZE, though.

If you like the type checking (we do, right?) you can of course
encapsulate it in a layer of UNSAFE Modula-3 with a safe interface.

    Mika

=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
>I have this case:
>
>extern int epoll_wait (int __epfd, struct epoll_event *__events,
>                       int __maxevents, int __timeout);
>
>And I would like to do it like:
>
><*EXTERNAL*>=20
>PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF epoll_event; =
>timeout: int :=3D -1): int;
>
>=85
>VAR
>  events: ARRAY [0..MaxEvents-1] OF epoll_event;
>
>=85
>
>WITH res =3D epoll_wait(epfd, events, 2) DO
>  =85
>END;
>
>Can I expect cm3 to do "right thing". Or I have to place parameters "by =
>hand" using ADR and SIZE?
>
>TIA,
>dd


From dabenavidesd at yahoo.es  Mon Feb  6 17:06:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 6 Feb 2012 16:06:24 +0000 (GMT)
Subject: [M3devel] open array parameter passing, to external C procedure
In-Reply-To: <C39EBA6D-0A62-44C5-ABA1-123EB7998453@m3w.org>
Message-ID: <1328544384.14121.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
given C no standard parameter by reference passing style, it should be not that easy. But how about WeakRef, where an open array of weak ref is easier to match with in Modula-3 words.
I don't know if Modula-3 has stronger types for that. Anyway, I don't know what kind of such struct is that either.
Thanks in advance

--- El lun, 6/2/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: [M3devel] open array parameter passing, to external C procedure
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 6 de febrero, 2012 03:50
> I have this case:
> 
> extern int epoll_wait (int __epfd, struct epoll_event
> *__events,
>                
>        int __maxevents, int
> __timeout);
> 
> And I would like to do it like:
> 
> <*EXTERNAL*> 
> PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF
> epoll_event; timeout: int := -1): int;
> 
> ?
> VAR
>   events: ARRAY [0..MaxEvents-1] OF epoll_event;
> 
> ?
> 
> WITH res = epoll_wait(epfd, events, 2) DO
>   ?
> END;
> 
> Can I expect cm3 to do "right thing". Or I have to place
> parameters "by hand" using ADR and SIZE?
> 
> TIA,
> dd
> 
> 


From rodney_bates at lcwb.coop  Mon Feb  6 17:43:11 2012
From: rodney_bates at lcwb.coop (Rodney Bates)
Date: Mon, 6 Feb 2012 08:43:11 -0800
Subject: [M3devel] open array parameter passing, to external C procedure
Message-ID: <20120206084311.D4AF2D80@m0005310.ppops.net>

All the compilers pass open arrays as a pointer to metadata.
The metadata consists of a pointer to actual element zero, followed
by a "shape", which is an array of element counts in each open dimension.
The number of open dimensions is a static property of the type, so
it is not passed, but hard-coded where needed. 

The actual elements can be anywhere, and indeed must be somewhere
else in the case of a SUBARRAY.   

I suppose they could have made this into separate parameters for
address of element zero and for each shape component, but I'm not 
sure right off hand how that would interact with heap-allocated open
arrays and subarrays of either heap-allocated or local variables.  
I've been ambivalent about this representation, but it can be used
consistently everywhere.  For a heap-allocated open array, the
metadata is immediately followed by the elements.  

So, no, it won't work the way you hope.  For your example, you 
would pass ADR(events[0]) and NUMBER(events) as separate parameters. 
(ADR(events) would pass the address of the metadata.)    

Of course, usually, the array you will have is not necessarily entirely 
full.  If that were the case, to do it in the Modula-3 way you had hoped, 
you would have had to pass SUBARRAY(events,0,event_count).  As it is,
the actuals in this case would be ADR(events[0]) and event_count.   

-Rodney Bates

--- dragisha at m3w.org wrote:

From: Dragi?a Duri? <dragisha at m3w.org>
To: m3devel <m3devel at elegosoft.com>
Subject: [M3devel] open array parameter passing, to external C procedure
Date: Mon, 6 Feb 2012 09:50:51 +0100

I have this case:

extern int epoll_wait (int __epfd, struct epoll_event *__events,
                       int __maxevents, int __timeout);

And I would like to do it like:

<*EXTERNAL*> 
PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF epoll_event; timeout: int := -1): int;

?
VAR
  events: ARRAY [0..MaxEvents-1] OF epoll_event;

?

WITH res = epoll_wait(epfd, events, 2) DO
  ?
END;

Can I expect cm3 to do "right thing". Or I have to place parameters "by hand" using ADR and SIZE?

TIA,
dd






From dragisha at m3w.org  Tue Feb  7 13:17:28 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 7 Feb 2012 13:17:28 +0100
Subject: [M3devel] open array parameter passing, to external C procedure
In-Reply-To: <20120206084311.D4AF2D80@m0005310.ppops.net>
References: <20120206084311.D4AF2D80@m0005310.ppops.net>
Message-ID: <BEC583C6-CAC1-44B1-A3D5-DAFB94A0A270@m3w.org>

Thanks to all for replies, it (does not) work as expected. Test showed it, reasoning is ok.

In gm2, interfacing is explicitly to C, so it's how it would and will work there. No big deal to make it by hand, but anyway - it's good to be sure :).

BTW, while googling some time ago, I found "ALIGNED  n FOR" construct from SPIN compiler? Interesting way to ensure alignment, esp in light of overaligning we have in cm3 now :).

dd

On Feb 6, 2012, at 5:43 PM, Rodney Bates wrote:

> All the compilers pass open arrays as a pointer to metadata.
> The metadata consists of a pointer to actual element zero, followed
> by a "shape", which is an array of element counts in each open dimension.
> The number of open dimensions is a static property of the type, so
> it is not passed, but hard-coded where needed. 
> 
> The actual elements can be anywhere, and indeed must be somewhere
> else in the case of a SUBARRAY.   
> 
> I suppose they could have made this into separate parameters for
> address of element zero and for each shape component, but I'm not 
> sure right off hand how that would interact with heap-allocated open
> arrays and subarrays of either heap-allocated or local variables.  
> I've been ambivalent about this representation, but it can be used
> consistently everywhere.  For a heap-allocated open array, the
> metadata is immediately followed by the elements.  
> 
> So, no, it won't work the way you hope.  For your example, you 
> would pass ADR(events[0]) and NUMBER(events) as separate parameters. 
> (ADR(events) would pass the address of the metadata.)    
> 
> Of course, usually, the array you will have is not necessarily entirely 
> full.  If that were the case, to do it in the Modula-3 way you had hoped, 
> you would have had to pass SUBARRAY(events,0,event_count).  As it is,
> the actuals in this case would be ADR(events[0]) and event_count.   
> 
> -Rodney Bates
> 
> --- dragisha at m3w.org wrote:
> 
> From: Dragi?a Duri? <dragisha at m3w.org>
> To: m3devel <m3devel at elegosoft.com>
> Subject: [M3devel] open array parameter passing, to external C procedure
> Date: Mon, 6 Feb 2012 09:50:51 +0100
> 
> I have this case:
> 
> extern int epoll_wait (int __epfd, struct epoll_event *__events,
>                       int __maxevents, int __timeout);
> 
> And I would like to do it like:
> 
> <*EXTERNAL*> 
> PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF epoll_event; timeout: int := -1): int;
> 
> ?
> VAR
>  events: ARRAY [0..MaxEvents-1] OF epoll_event;
> 
> ?
> 
> WITH res = epoll_wait(epfd, events, 2) DO
>  ?
> END;
> 
> Can I expect cm3 to do "right thing". Or I have to place parameters "by hand" using ADR and SIZE?
> 
> TIA,
> dd
> 
> 
> 
> 
> 



From hendrik at topoi.pooq.com  Thu Feb  9 17:56:24 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 9 Feb 2012 11:56:24 -0500
Subject: [M3devel] Assertion failed to complain
Message-ID: <20120209165624.GA13717@topoi.pooq.com>

Presumably there's something I have to do (or make sure I don't do) to 
make assertion chacking work. 

With the following two lines in my program:


  <* assert segment.end + 1 >= segment.start *>    

  indices := NEW(REF ARRAY OF INTEGER, segment.end - segment.start + 
1);

I get a runtime error

***
*** runtime error:
***    An enumeration or subrange value was out of range.
***    file "../src/runtime/common/RTAllocator.m3", line 340
***

Running this in m3gdb, I see that line 340 is indeed the assignment to 
'indices' above, and that the assertion has sowehow failed to complain.

Printing out a few expressions in the debugger, I get

(m3gdb) up
#19 0x080498ba in sortsegment (segment=16_b6be01b8) at 
../src/Main.m3:218
218	  indices := NEW(REF ARRAY OF INTEGER, segment.end - 
segment.start + 1);
(m3gdb) print segment.end
$1 = 0
(m3gdb) print segment.start
$2 = 3
(m3gdb) print segment.end + 1 >= segment.start
$3 = FALSE
(m3gdb) print segment.end - segment.start + 1
$4 = 4294967294

Yes, the 'end' and 'start' fields are declared INTEGER.

Somehow, this slipped past the ASSERT statement.

-- hendrik



From hendrik at topoi.pooq.com  Thu Feb  9 18:52:20 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 9 Feb 2012 12:52:20 -0500
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <20120209165624.GA13717@topoi.pooq.com>
References: <20120209165624.GA13717@topoi.pooq.com>
Message-ID: <20120209175220.GB13717@topoi.pooq.com>

On Thu, Feb 09, 2012 at 11:56:24AM -0500, Hendrik Boom wrote:
> Presumably there's something I have to do (or make sure I don't do) to 
> make assertion chacking work. 
> 
> With the following two lines in my program:
> 
> 
>   <* assert segment.end + 1 >= segment.start *>    
> 
>   indices := NEW(REF ARRAY OF INTEGER, segment.end - segment.start + 
> 1);
> 
> I get a runtime error
> 
> ***
> *** runtime error:
> ***    An enumeration or subrange value was out of range.
> ***    file "../src/runtime/common/RTAllocator.m3", line 340
> ***
> 
> Running this in m3gdb, I see that line 340 is indeed the assignment to 
> 'indices' above, and that the assertion has sowehow failed to complain.
> 
> Printing out a few expressions in the debugger, I get
> 
> (m3gdb) up
> #19 0x080498ba in sortsegment (segment=16_b6be01b8) at 
> ../src/Main.m3:218
> 218	  indices := NEW(REF ARRAY OF INTEGER, segment.end - 
> segment.start + 1);
> (m3gdb) print segment.end
> $1 = 0
> (m3gdb) print segment.start
> $2 = 3
> (m3gdb) print segment.end + 1 >= segment.start
> $3 = FALSE
> (m3gdb) print segment.end - segment.start + 1
> $4 = 4294967294
> 
> Yes, the 'end' and 'start' fields are declared INTEGER.
> 
> Somehow, this slipped past the ASSERT statement.
> 

For the record, I'm running 

Critical Mass Modula-3 version 5.8.4
  last updated: 2009-11-02
  compiled: 2009-11-03 13:57:35
  configuration: /usr/local/cm3/bin/cm3.cfg
  host: LINUXLIBC6
  target: LINUXLIBC6

-- hendrik



From dabenavidesd at yahoo.es  Thu Feb  9 18:51:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 9 Feb 2012 17:51:24 +0000 (GMT)
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <20120209165624.GA13717@topoi.pooq.com>
Message-ID: <1328809884.5392.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
It might be that needs to be uppercase (in case compiler doesn't warn but I guess that would desired behavior, or not, since it would be unknown at compile time).
<*ASSERT exp*>

Thanks in advance

--- El jue, 9/2/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] Assertion failed to complain
> Para: m3devel at elegosoft.com
> Fecha: jueves, 9 de febrero, 2012 11:56
> Presumably there's something I have
> to do (or make sure I don't do) to 
> make assertion chacking work. 
> 
> With the following two lines in my program:
> 
> 
>   <* assert segment.end + 1 >= segment.start
> *>    
> 
>   indices := NEW(REF ARRAY OF INTEGER, segment.end -
> segment.start + 
> 1);
> 
> I get a runtime error
> 
> ***
> *** runtime error:
> ***    An enumeration or subrange value was out of
> range.
> ***    file
> "../src/runtime/common/RTAllocator.m3", line 340
> ***
> 
> Running this in m3gdb, I see that line 340 is indeed the
> assignment to 
> 'indices' above, and that the assertion has sowehow failed
> to complain.
> 
> Printing out a few expressions in the debugger, I get
> 
> (m3gdb) up
> #19 0x080498ba in sortsegment (segment=16_b6be01b8) at 
> ../src/Main.m3:218
> 218      indices := NEW(REF ARRAY OF
> INTEGER, segment.end - 
> segment.start + 1);
> (m3gdb) print segment.end
> $1 = 0
> (m3gdb) print segment.start
> $2 = 3
> (m3gdb) print segment.end + 1 >= segment.start
> $3 = FALSE
> (m3gdb) print segment.end - segment.start + 1
> $4 = 4294967294
> 
> Yes, the 'end' and 'start' fields are declared INTEGER.
> 
> Somehow, this slipped past the ASSERT statement.
> 
> -- hendrik
> 
> 


From hendrik at topoi.pooq.com  Thu Feb  9 18:59:08 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 9 Feb 2012 12:59:08 -0500
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <1328809884.5392.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <20120209165624.GA13717@topoi.pooq.com>
	<1328809884.5392.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <20120209175908.GC13717@topoi.pooq.com>

On Thu, Feb 09, 2012 at 05:51:24PM +0000, Daniel Alejandro Benavides D. wrote:
> Hi all:
> It might be that needs to be uppercase (in case compiler doesn't warn but I guess that would desired behavior, or not, since it would be unknown at compile time).
> <*ASSERT exp*>
> 
> Thanks in advance

That was exactly it.  One of the few places where things are 
case-sensitive, but a wrong case doesn't cause an error message.
(in fact, it suppressed it)

Things are failing properly now.

-- hendrik


From peter.mckinna at gmail.com  Fri Feb 10 06:01:00 2012
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Fri, 10 Feb 2012 16:01:00 +1100
Subject: [M3devel] Think we need a new release.
Message-ID: <CAEy6uxr=Qt6oktH60NGVByyjM9=Dtoy5OocjEOh=fC=YhbUn=Q@mail.gmail.com>

Been a long time between releases. Must be about time.

Firefox is doing 6 weekly releases we are lucky if we get one every 6
years. Sorry thats a bit harsh, all the same we need some new
commitment.

Regards Peter


From dataf4l at gmail.com  Fri Feb 10 06:22:58 2012
From: dataf4l at gmail.com (felipe valdez)
Date: Fri, 10 Feb 2012 00:22:58 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAEy6uxr=Qt6oktH60NGVByyjM9=Dtoy5OocjEOh=fC=YhbUn=Q@mail.gmail.com>
References: <CAEy6uxr=Qt6oktH60NGVByyjM9=Dtoy5OocjEOh=fC=YhbUn=Q@mail.gmail.com>
Message-ID: <CAGi-_--zaetAw_FiUK3F=twE_ba3cKDgmhUZg5B5tBO4-TQcTA@mail.gmail.com>

I'd love to help beta-testing whatever you guys throw at me.
I have linux, windows and mac (11.6) boxes for this purpose.


if testing can be automated, so much the better.

I know it is perhaps not much, but I'd like to help, and this is the only
thing I can think of.

if you guys have a more specific task, I'd like to take a crack at it, but
be indulgent, I'm just a newbie, so "making compiler not leak" type bugs
are probably not what I'll be most effective at.

I think the project could use some help, concerning the webpage (it looks
dated, a little), and also with documentatino on to how to get started
(screencast anyone?).

if more people could get behind the project, perhaps it would be easier to
make releases more often.

perhaps ideas conecrning what the selling points of M3, tha differentiate
it from other languages, would be a nice thng to be able to mention in the
videos.


I remember that Ruby on rails had some traction going on, after the creator
posted some 15 minutes videos concerning how to make a blog, and that kind
of stuff.

is it possible, to make a 15 mins video, of the main M3 features, that
would help convince more people to join the project.

is this a good idea?




On Fri, Feb 10, 2012 at 12:01 AM, Peter McKinna <peter.mckinna at gmail.com>wrote:

> Been a long time between releases. Must be about time.
>
> Firefox is doing 6 weekly releases we are lucky if we get one every 6
> years. Sorry thats a bit harsh, all the same we need some new
> commitment.
>
> Regards Peter
>



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

From dabenavidesd at yahoo.es  Fri Feb 10 14:22:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 13:22:34 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_--zaetAw_FiUK3F=twE_ba3cKDgmhUZg5B5tBO4-TQcTA@mail.gmail.com>
Message-ID: <1328880154.79634.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
Elego wanted to make a CM3IDE instance for free browsing of sources like the "Free Critical Mass Modula-3 (CM3)" since this the only excuse of a non-Modula-3 user, "I can't wait to use the compiler", or, "Do I have a platform enabled system " and we will give you a bootstrap image testable on-line, perhaps you would want to start from that. I think that anybody with modula-3 problems will appreciate that. I know of some Emulators for old platforms like Pdp-8e, Pdp-10, CDC, will anyone be keen to integrate those platforms as for have testing changes on those systems (besides showing that Modula-3 can emulate really basic and complex systems).
Personally I would love to fix the m3-obliq system and related tools to work across several platforms, you know, NetObj testing and some C-level coding inside m3cc , hopefully to make testing but will need to do some C-like clearer version, since this is hard for a non-artistic computer brain also would help to have syntax and grammar rules of M3CG whatever is available (Including M3CG- Clef - C/Assembly compiler for exploratory targets). 
I guess there  is room for more things to be done.
Thanks in advance

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

De: felipe valdez <dataf4l at gmail.com>
Asunto: Re: [M3devel] Think we need a new release.
Para: "Peter McKinna" <peter.mckinna at gmail.com>
CC: m3devel at elegosoft.com
Fecha: viernes, 10 de febrero, 2012 00:22

I'd love to help beta-testing whatever you guys throw at me.I have linux, windows and mac (11.6) boxes for this purpose.



if testing can be automated, so much the better.


I know it is perhaps not much, but I'd like to help, and this is the only thing I can think of.


if you guys have a more specific task, I'd like to take a crack at it, but be indulgent, I'm just a newbie, so "making compiler not leak" type bugs are probably not what I'll be most effective at.


I think the project could use some help, concerning the webpage (it looks dated, a little), and also with documentatino on to how to get started (screencast anyone?).


if more people could get behind the project, perhaps it would be easier to make releases more often.


perhaps ideas conecrning what the selling points of M3, tha differentiate it from other languages, would be a nice thng to be able to mention in the videos.



I remember that Ruby on rails had some traction going on, after the creator posted some 15 minutes videos concerning how to make a blog, and that kind of stuff.


is it possible, to make a 15 mins video, of the main M3 features, that would help convince more people to join the project.


is this a good idea?





On Fri, Feb 10, 2012 at 12:01 AM, Peter McKinna <peter.mckinna at gmail.com> wrote:


Been a long time between releases. Must be about time.



Firefox is doing 6 weekly releases we are lucky if we get one every 6

years. Sorry thats a bit harsh, all the same we need some new

commitment.



Regards Peter




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



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

From vintagecoder at aol.com  Fri Feb 10 15:14:35 2012
From: vintagecoder at aol.com (Vintage Coder)
Date: Fri, 10 Feb 2012 14:14:35 +0000
Subject: [M3devel] Think we need a new release.
Message-ID: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>

What is the purpose of a new release? A compiler and runtime that work presumably only need fixes. Are you talking about a major new version or a mod level or what? The last release on cm3 I see is from 2010. 

Are there bug fixes in the pipeline that haven't been verified? Are there fixes ready to go that no builds have been done for? What is the problem more frequent releases will solve? Personally I see no benefit (indeed I see many disadvantges) to frequent releases of stable software. But I often run backlevel intentionally.  

Firefox is being updated for many reasons including security holes, bug fixes, new standards, and more. If the Modula-3 standard hasn't been updated, what is driving the need for new release(s)?

It looks like cm3 supports more platforms than I have. I would be willing to help out (I am not a UNIX developer) any way I could. I have Solaris Intel and SPARC boxes. 

------Original Message------
From: Peter McKinna
To: m3devel at elegosoft.com
Subject: [M3devel] Think we need a new release.
Sent: 10 Feb 2012 05:01

Been a long time between releases. Must be about time.

Firefox is doing 6 weekly releases we are lucky if we get one every 6
years. Sorry thats a bit harsh, all the same we need some new
commitment.

Regards Peter


From rcolebur at SCIRES.COM  Fri Feb 10 15:29:52 2012
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 10 Feb 2012 09:29:52 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_--zaetAw_FiUK3F=twE_ba3cKDgmhUZg5B5tBO4-TQcTA@mail.gmail.com>
References: <CAEy6uxr=Qt6oktH60NGVByyjM9=Dtoy5OocjEOh=fC=YhbUn=Q@mail.gmail.com>
	<CAGi-_--zaetAw_FiUK3F=twE_ba3cKDgmhUZg5B5tBO4-TQcTA@mail.gmail.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6034A5AF263@atlex02-srv>

I can provide testing on Windows 2000, XP, and 7 platforms.
Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/6a833467/attachment.html>

From dabenavidesd at yahoo.es  Fri Feb 10 15:31:25 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 14:31:25 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>
Message-ID: <1328884285.44537.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
I think one of the purposes of that is more cross platform compatibility, perhaps put in place everything to a major update on platform but for alpha testing new JIT RTCG or so (arguably we could stay in odd numbers being platform development until we get to a new even number for product release), while most of developers might want or not to migrate it's necessary to establish priorities and so for having such a thing.
Thanks in advance

--- El vie, 10/2/12, Vintage Coder <vintagecoder at aol.com> escribi?:

> De: Vintage Coder <vintagecoder at aol.com>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: m3devel at elegosoft.com
> Fecha: viernes, 10 de febrero, 2012 09:14
> What is the purpose of a new release?
> A compiler and runtime that work presumably only need fixes.
> Are you talking about a major new version or a mod level or
> what? The last release on cm3 I see is from 2010. 
> 
> Are there bug fixes in the pipeline that haven't been
> verified? Are there fixes ready to go that no builds have
> been done for? What is the problem more frequent releases
> will solve? Personally I see no benefit (indeed I see many
> disadvantges) to frequent releases of stable software. But I
> often run backlevel intentionally.  
> 
> Firefox is being updated for many reasons including security
> holes, bug fixes, new standards, and more. If the Modula-3
> standard hasn't been updated, what is driving the need for
> new release(s)?
> 
> It looks like cm3 supports more platforms than I have. I
> would be willing to help out (I am not a UNIX developer) any
> way I could. I have Solaris Intel and SPARC boxes. 
> 
> ------Original Message------
> From: Peter McKinna
> To: m3devel at elegosoft.com
> Subject: [M3devel] Think we need a new release.
> Sent: 10 Feb 2012 05:01
> 
> Been a long time between releases. Must be about time.
> 
> Firefox is doing 6 weekly releases we are lucky if we get
> one every 6
> years. Sorry thats a bit harsh, all the same we need some
> new
> commitment.
> 
> Regards Peter
> 
> 


From dmuysers at hotmail.com  Fri Feb 10 15:54:59 2012
From: dmuysers at hotmail.com (Dirk Muysers)
Date: Fri, 10 Feb 2012 15:54:59 +0100
Subject: [M3devel] platform-independent object file linking
Message-ID: <SNT109-DS775C44A0CC94BF3376EE2DD780@phx.gbl>

I recently came across an article that might interest the community:

A Compiler-Supported Unification of Static and Dynamic Loading
by Felix Friedrich and Florian Negele

It is about platform-independent linking and loading of modules.
The mechanism is explained in context of the A2 (ex-Bluebottle)
OS and the Active Oberon language, but it is easily portable to
other programming environments and languages.
Its adoption, at the cost of rewriting the backend and parts of
m3core, would significantly simplify the maintenance of M3 and
also render it independent from proprietary tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/568e505e/attachment.html>

From dabenavidesd at yahoo.es  Fri Feb 10 16:17:46 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 15:17:46 +0000 (GMT)
Subject: [M3devel] platform-independent object file linking
In-Reply-To: <SNT109-DS775C44A0CC94BF3376EE2DD780@phx.gbl>
Message-ID: <1328887066.93948.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
nice idea, once it's inly functional would it work for procedural languages?
The nice idea of this would port it to Module system of Modula-3 which as I understand (unless it's not Modula-3 own one) is a simplified version (most of researchers didn't concentrate on a single-separate compilation, but distributed aware compilation specially in Modula-2+, in Canada, one can ask the copy and they will send to you once you identify its name).
Thanks in advance

--- El vie, 10/2/12, Dirk Muysers <dmuysers at hotmail.com> escribi?:

De: Dirk Muysers <dmuysers at hotmail.com>
Asunto: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com
Fecha: viernes, 10 de febrero, 2012 09:54



 


I recently came across an article that might 
interest the community:
?
A 
Compiler-Supported Unification of Static and Dynamic Loading
by Felix Friedrich and Florian Negele
?
It is about platform-independent linking and 
loading of modules.
The mechanism is explained?in context of 
the?A2 (ex-Bluebottle)
OS and the?Active Oberon language, but it is 
easily portable to
other?programming environments and 
languages.
Its adoption, at the cost of rewriting the backend 
and parts of
m3core,?would significantly?simplify the maintenance of M3 and
also render it independent from proprietary 
tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/05703dc7/attachment.html>

From dataf4l at gmail.com  Fri Feb 10 16:42:40 2012
From: dataf4l at gmail.com (felipe valdez)
Date: Fri, 10 Feb 2012 10:42:40 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <1328884285.44537.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>
	<1328884285.44537.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>

Mr VintageCoder,


> What is the purpose of a new release?


from a technical perspective, probably not much
but from a marketing perspective (language adoption, language value
perception), there could be a few.


> A compiler and runtime that work presumably only need fixes.


that is correct.


> Are you talking about a major new version or a mod level or what? The last
> release on cm3 I see is from 2010.


this probably disproves the argument of "6 years between releases",
however, in the fast moving tech world, some people could consider 2010 to
be a long time ago.



> Are there bug fixes in the pipeline that haven't been verified? Are there
> fixes ready to go that no builds have been done for? What is the problem
> more frequent releases will solve?


I think, it makes people perceive that the language has support, is being
actively developed, is growing , and also
that it is not dead.

I used to use tcl a lot, but I haven't got a new release in a while, and
8.6 took forever (5 years?) to get done.
this made me move away from the technology, since I saw it at the time, as
stagnating, stale, old and unsupported.

had they put a "new" brand on it ever so often, I would have been more
insterested.

in general terms, once you know perl 5.10, would you be more exicet about
learning perl 6.0 or 5.10.1 ?
I mean, seriously, who gives a damn about a 0.0.1 release anyway?

the problem I see a new release would solve, is that you get to fix stuff
(like the string broken stuff) that needs fixing, without having to
maintain 100% backwards compatibility, this can lead to a cleaner language,
like python3000 broke a lot of things, for instance.


> Personally I see no benefit (indeed I see many disadvantges) to frequent
> releases of stable software.



this is als true, there are disadvantages and I also suffer a little from
this.
but surely not something we cannot live through, especially if there is
some kind of guide (3to4 ?)




> But I often run backlevel intentionally. Firefox is being updated for many
> reasons including security holes, bug fixes, new standards, and more. If
> the Modula-3 standard hasn't been updated, what is driving the need for new
> release(s)?


if the language does not evolve, is it bound to die?
if the standard does not evolve, should one consider it to be dead?
see c++ for instance, recently, there have been changes to the language.
this motivates a lot of tuff:
conferences, new compilers, new books, new blogposts, and in general, a lot
of "hype"
if m3 was hyped a little, perhaps it could gain developers.
by gaining such developers, perhaps more bugs could be removed and features
could be added as well (for instance, in the library space, where I see
that other language have better, more tested, and easier to use LIbraries,
but this is , of course, a subjective declaration, and I don't expect
anyone to agree with me).



> It looks like cm3 supports more platforms than I have. I would be willing
> to help out (I am not a UNIX developer) any way I could. I have Solaris
> Intel and SPARC boxes.


that Is wonderful news, I appreciate the offer, I hope the language
improves, and your boxes serve the purpose!




On Fri, Feb 10, 2012 at 9:31 AM, Daniel Alejandro Benavides D. <
dabenavidesd at yahoo.es> wrote:

> Hi all:
> I think one of the purposes of that is more cross platform compatibility,
> perhaps put in place everything to a major update on platform but for alpha
> testing new JIT RTCG or so (arguably we could stay in odd numbers being
> platform development until we get to a new even number for product
> release), while most of developers might want or not to migrate it's
> necessary to establish priorities and so for having such a thing.
> Thanks in advance
>
> --- El vie, 10/2/12, Vintage Coder <vintagecoder at aol.com> escribi?:
>
> > De: Vintage Coder <vintagecoder at aol.com>
> > Asunto: Re: [M3devel] Think we need a new release.
> > Para: m3devel at elegosoft.com
> > Fecha: viernes, 10 de febrero, 2012 09:14
> > What is the purpose of a new release?
> > A compiler and runtime that work presumably only need fixes.
> > Are you talking about a major new version or a mod level or
> > what? The last release on cm3 I see is from 2010.
> >
> > Are there bug fixes in the pipeline that haven't been
> > verified? Are there fixes ready to go that no builds have
> > been done for? What is the problem more frequent releases
> > will solve? Personally I see no benefit (indeed I see many
> > disadvantges) to frequent releases of stable software. But I
> > often run backlevel intentionally.
> >
> > Firefox is being updated for many reasons including security
> > holes, bug fixes, new standards, and more. If the Modula-3
> > standard hasn't been updated, what is driving the need for
> > new release(s)?
> >
> > It looks like cm3 supports more platforms than I have. I
> > would be willing to help out (I am not a UNIX developer) any
> > way I could. I have Solaris Intel and SPARC boxes.
> >
> > ------Original Message------
> > From: Peter McKinna
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] Think we need a new release.
> > Sent: 10 Feb 2012 05:01
> >
> > Been a long time between releases. Must be about time.
> >
> > Firefox is doing 6 weekly releases we are lucky if we get
> > one every 6
> > years. Sorry thats a bit harsh, all the same we need some
> > new
> > commitment.
> >
> > Regards Peter
> >
> >
>



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

From dabenavidesd at yahoo.es  Fri Feb 10 18:00:42 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 17:00:42 +0000 (GMT)
Subject: [M3devel] platform-independent object file linking
In-Reply-To: <1328887066.93948.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <1328893242.4700.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
in the sense of if at all wanted porting functionality to Modula-3 minimal functional subset language to allow such dynamic implementation and later on pass on Modula-3. 
There are some available Models of graft Modular concepts in functional-like languages worth of writing OSes on it (concurrent ones already objected oriented) like Clean and Concurrent Clean and Gofer:
http://www4.in.tum.de/~sihling/publications/1995/DA_Sihling.ps.gz

ftp://ftp.cs.york.ac.uk/pub/malcolm/thesis.ps.Z

Anyway just a possible path of action 
Thanks in advance

--- El vie, 10/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com, "Dirk Muysers" <dmuysers at hotmail.com>
Fecha: viernes, 10 de febrero, 2012 10:17

Hi all:
nice idea, once it's inly functional would it work for procedural languages?
The nice idea of this would port it to Module system of Modula-3 which as I understand (unless it's not Modula-3 own one) is a simplified version (most of researchers didn't concentrate on a single-separate compilation, but distributed aware compilation specially in Modula-2+, in Canada, one can ask the copy and they will send to you once you identify its name).
Thanks in advance

--- El vie, 10/2/12, Dirk Muysers <dmuysers at hotmail.com> escribi?:

De: Dirk Muysers <dmuysers at hotmail.com>
Asunto: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com
Fecha: viernes, 10 de febrero, 2012 09:54



 


I recently came across an article that might 
interest the community:
?
A 
Compiler-Supported Unification of Static and Dynamic Loading
by Felix Friedrich and Florian Negele
?
It is about platform-independent linking and 
loading of modules.
The mechanism is explained?in context of 
the?A2 (ex-Bluebottle)
OS and the?Active Oberon language, but it is 
easily portable to
other?programming environments and 
languages.
Its adoption, at the cost of rewriting the backend 
and parts of
m3core,?would significantly?simplify the maintenance of M3 and
also render it independent from proprietary 
tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/edf5aa7d/attachment.html>

From dabenavidesd at yahoo.es  Fri Feb 10 18:27:16 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 17:27:16 +0000 (GMT)
Subject: [M3devel] platform-independent object file linking
In-Reply-To: <1328893242.4700.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <1328894836.11850.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
in fact highly advanced mainframes with Micro-code like capabilities have been developed with companies such as NEC behind it, the Lisp Machine Engine LIME was one of them, for scheduling of JAR Japan airlines staff and we already have appliances of that kind in Modula-3:
http://www.iste.uni-stuttgart.de/fileadmin/user_upload/iste/se/research/publications/download/PraktLehr5.pdf

So I guess connecting the points there is room for that sort of work, nevertheless it's a kind of hard and brave project.
In any event C++ and others are pursuing Lambda Expressions in their Standards I want to allow such kind of work but in DEC-SRC style like Baby Modula-3 (that's where hard part comes from, since it needs work and more work). But first the first, describe the Modula-3 in a sound way is one part of it, formalization of the Language Semantics is just another so one we can be absolutely sure of what we are doing (BTW the original implementation of it failed to finish, but LIME was 2 to 10 times faster than any of this market of the day, who knows what would like today be for doing that):
http://museum.ipsj.or.jp/en/computer/other/0008.html

Thanks in advance


--- El vie, 10/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com, "Dirk Muysers" <dmuysers at hotmail.com>
Fecha: viernes, 10 de febrero, 2012 12:00

Hi all:
in the sense of if at all wanted porting functionality to Modula-3 minimal functional subset language to allow such dynamic implementation and later on pass on Modula-3. 
There are some available Models of graft Modular concepts in functional-like languages worth of writing OSes on it (concurrent ones already objected oriented) like Clean and Concurrent Clean and Gofer:
http://www4.in.tum.de/~sihling/publications/1995/DA_Sihling.ps.gz

ftp://ftp.cs.york.ac.uk/pub/malcolm/thesis.ps.Z

Anyway just a possible path of action 
Thanks in advance

--- El vie, 10/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto:
 Re: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com, "Dirk Muysers" <dmuysers at hotmail.com>
Fecha: viernes, 10 de febrero, 2012 10:17

Hi all:
nice idea, once it's inly functional would it work for procedural languages?
The nice idea of this would port it to Module system of Modula-3 which as I understand (unless it's not Modula-3 own one) is a simplified version (most of researchers didn't concentrate on a single-separate compilation, but distributed aware compilation specially in Modula-2+, in Canada, one can ask the copy and they will send to you once you identify its name).
Thanks in advance

--- El
 vie, 10/2/12, Dirk Muysers <dmuysers at hotmail.com> escribi?:

De: Dirk Muysers <dmuysers at hotmail.com>
Asunto: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com
Fecha: viernes, 10 de febrero, 2012 09:54



 


I recently came across an article that might 
interest the community:
?
A 
Compiler-Supported Unification of Static and Dynamic Loading
by Felix Friedrich and Florian Negele
?
It is about platform-independent linking and 
loading of modules.
The mechanism is explained?in context of 
the?A2 (ex-Bluebottle)
OS and the?Active Oberon language, but it is 
easily portable to
other?programming environments and 
languages.
Its adoption, at the cost of rewriting the backend 
and parts of
m3core,?would significantly?simplify the maintenance of M3 and
also render it independent from proprietary 
tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/0c74d194/attachment.html>

From dabenavidesd at yahoo.es  Fri Feb 10 21:21:26 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 20:21:26 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
Message-ID: <1328905286.88292.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
It's not correct to release a product for bug fixing (unless is ESC annotations), but because that can be embarrassing, of course SW Engineering based on that is just ridiculous (and by the way the release cycle is something that community should decide, I agree with the idea of that way of releasing "bug fixes" rather than functional implementation correction and documentation in the other side).
But in any event, the idea of experimental platforms is not bad at all in a new release, since several backends have been like that and so, it needs to give more thought if it's? valuable? or not is debatable.
Thanks in advance 

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

De: felipe valdez <dataf4l at gmail.com>
Asunto: Re: [M3devel] Think we need a new release.
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: m3devel at elegosoft.com, vintagecoder at aol.com
Fecha: viernes, 10 de febrero, 2012 10:42

Mr VintageCoder, What is the purpose of a new release? 
from a technical perspective, probably not much

but from a marketing perspective (language adoption, language value perception), there could be a few. 

A compiler and runtime that work presumably only need fixes. 
that is correct. 

Are you talking about a major new version or a mod level or what? The last release on cm3 I see is from 2010.

 
this probably disproves the argument of "6 years between releases", however, in the fast moving tech world, some people could consider 2010 to be a long time ago.


 Are there bug fixes in the pipeline that haven't been verified? Are there fixes ready to go that no builds have been done for? What is the problem more frequent releases will solve? 


I think, it makes people perceive that the language has support, is being actively developed, is growing , and alsothat it is not dead.
I used to use tcl a lot, but I haven't got a new release in a while, and 8.6 took forever (5 years?) to get done.

this made me move away from the technology, since I saw it at the time, as stagnating, stale, old and unsupported.
had they put a "new" brand on it ever so often, I would have been more insterested.


in general terms, once you know perl 5.10, would you be more exicet about learning perl 6.0 or 5.10.1 ?I mean, seriously, who gives a damn about a 0.0.1 release anyway?


the problem I see a new release would solve, is that you get to fix stuff (like the string broken stuff) that needs fixing, without having to maintain 100% backwards compatibility, this can lead to a cleaner language, like python3000 broke a lot of things, for instance.

 Personally I see no benefit (indeed I see many disadvantges) to frequent releases of stable software.



this is als true, there are disadvantages and I also suffer a little from this.but surely not something we cannot live through, especially if there is some kind of guide (3to4 ?)



  But I often run backlevel intentionally.

 Firefox is being updated for many reasons including security holes, bug fixes, new standards, and more. If the Modula-3 standard hasn't been updated, what is driving the need for new release(s)?


if the language does not evolve, is it bound to die?if the standard does not evolve, should one consider it to be dead?see c++ for instance, recently, there have been changes to the language.

this motivates a lot of tuff:conferences, new compilers, new books, new blogposts, and in general, a lot of "hype"if m3 was hyped a little, perhaps it could gain developers.

by gaining such developers, perhaps more bugs could be removed and features could be added as well (for instance, in the library space, where I see that other language have better, more tested, and easier to use LIbraries, but this is , of course, a subjective declaration, and I don't expect anyone to agree with me).


 

 It looks like cm3 supports more platforms than I have. I would be willing to help out (I am not a UNIX developer) any way I could. I have Solaris Intel and SPARC boxes.
that Is wonderful news, I appreciate the offer, I hope the language improves, and your boxes serve the purpose!



 
On Fri, Feb 10, 2012 at 9:31 AM, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:


Hi all:

I think one of the purposes of that is more cross platform compatibility, perhaps put in place everything to a major update on platform but for alpha testing new JIT RTCG or so (arguably we could stay in odd numbers being platform development until we get to a new even number for product release), while most of developers might want or not to migrate it's necessary to establish priorities and so for having such a thing.



Thanks in advance



--- El vie, 10/2/12, Vintage Coder <vintagecoder at aol.com> escribi?:



> De: Vintage Coder <vintagecoder at aol.com>

> Asunto: Re: [M3devel] Think we need a new release.

> Para: m3devel at elegosoft.com

> Fecha: viernes, 10 de febrero, 2012 09:14

> What is the purpose of a new release?

> A compiler and runtime that work presumably only need fixes.

> Are you talking about a major new version or a mod level or

> what? The last release on cm3 I see is from 2010.

>

> Are there bug fixes in the pipeline that haven't been

> verified? Are there fixes ready to go that no builds have

> been done for? What is the problem more frequent releases

> will solve? Personally I see no benefit (indeed I see many

> disadvantges) to frequent releases of stable software. But I

> often run backlevel intentionally.

>

> Firefox is being updated for many reasons including security

> holes, bug fixes, new standards, and more. If the Modula-3

> standard hasn't been updated, what is driving the need for

> new release(s)?

>

> It looks like cm3 supports more platforms than I have. I

> would be willing to help out (I am not a UNIX developer) any

> way I could. I have Solaris Intel and SPARC boxes.

>

> ------Original Message------

> From: Peter McKinna

> To: m3devel at elegosoft.com

> Subject: [M3devel] Think we need a new release.

> Sent: 10 Feb 2012 05:01

>

> Been a long time between releases. Must be about time.

>

> Firefox is doing 6 weekly releases we are lucky if we get

> one every 6

> years. Sorry thats a bit harsh, all the same we need some

> new

> commitment.

>

> Regards Peter

>

>




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


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

From m3 at sol42.com  Fri Feb 10 22:50:13 2012
From: m3 at sol42.com (m3 at sol42.com)
Date: Fri, 10 Feb 2012 22:50:13 +0100
Subject: [M3devel] Think we need a new release.
In-Reply-To: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>
References: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>
Message-ID: <A0DF2CB8-A6D9-44B1-BC9B-B03DEEC9A52E@sol42.com>

On 10 Feb 2012, at 15:14, Vintage Coder wrote:
> What is the purpose of a new release? A compiler and runtime that work presumably only need fixes.

Agreed.  I can think of two reasons: adding "must have" stuff to the standard library, and fixing bugs or improving library, compiler, or runtime.  Note that "must have" should probably be evaluated in the context of systems programming, which is what Modula-3 is for.

Even adding new platforms should not require bumping the version number if it is the existing infrastructure that is being ported.

There are loads of "greatest next thing" languages out there that you have to re-learn every few releases.  Modula-3 is thankfully not one of them.  Want new stuff in the language?  Then you want Modula-3+ or Modula-4.

Regards.
-Daniel




From dabenavidesd at yahoo.es  Sat Feb 11 00:30:23 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 23:30:23 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <A0DF2CB8-A6D9-44B1-BC9B-B03DEEC9A52E@sol42.com>
Message-ID: <1328916623.650.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
Modula-2+ distributed compiler didn't require languages changes but extensive testing and some distributed setting, which is why you need some sort of engineering process, at least is what I think that happens.
If you don't want dynamic compilation/interpretation that's up to one's needs, but currently most compilers do have some sort of dynamic interpretation capabilities, and being Modula-3 and innovative platform, it must have one. That's again what I think. I guess the way of not interrupting is just is m3-obliq stuff (since it's the scripting expression of Modula-3 RT) and prepare for the needed changes in the next big release. So for me would be like v 5.10 < 6.0
Thanks in advance

--- El vie, 10/2/12, m3 at sol42.com <m3 at sol42.com> escribi?:

> De: m3 at sol42.com <m3 at sol42.com>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 10 de febrero, 2012 16:50
> On 10 Feb 2012, at 15:14, Vintage
> Coder wrote:
> > What is the purpose of a new release? A compiler and
> runtime that work presumably only need fixes.
> 
> Agreed.  I can think of two reasons: adding "must have"
> stuff to the standard library, and fixing bugs or improving
> library, compiler, or runtime.  Note that "must have"
> should probably be evaluated in the context of systems
> programming, which is what Modula-3 is for.
> 
> Even adding new platforms should not require bumping the
> version number if it is the existing infrastructure that is
> being ported.
> 
> There are loads of "greatest next thing" languages out there
> that you have to re-learn every few releases.  Modula-3
> is thankfully not one of them.  Want new stuff in the
> language?  Then you want Modula-3+ or Modula-4.
> 
> Regards.
> -Daniel
> 
> 
> 


From dabenavidesd at yahoo.es  Sat Feb 11 02:37:37 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 11 Feb 2012 01:37:37 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <1328916623.650.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <1328924257.76277.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:

In case, you want the reference, and plus [1]:

At the time it was a kind of important to investigate [1] (for instance the ARX operating system it was a real issue for the day to day development) about Acorn in the 80's:
http://www.legacy.com/guestbook/mercurynews/guestbook.aspx?n=steve-glassman&pid=144489261&page=3

I guess in the case of a Microkernel and a huge UI libraries it might matter (Interfaces of 250k loc would would be good test case in terms of Modular verification it might matter, if the upper limit is O(n^5) actually to make that calculation makes an unknown prefix for that number power of ten, 26th order).

In the other hand you might want to leave like that but being one of the most important features to be able to program in the large, I feel this is better that the pain to wait that kind of operations (usually ESC ten times slower than compilation time).

[1] U. Postavsky, ?Distributed Compilation Using Distributed Shared Memory,? M.Sc., University of Toronto (Canada), Canada, 1990.


--- El vie, 10/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: "m3devel" <m3devel at elegosoft.com>, m3 at sol42.com
> Fecha: viernes, 10 de febrero, 2012 18:30
> Hi all:
> Modula-2+ distributed compiler didn't require languages
> changes but extensive testing and some distributed setting,
> which is why you need some sort of engineering process, at
> least is what I think that happens.
> If you don't want dynamic compilation/interpretation that's
> up to one's needs, but currently most compilers do have some
> sort of dynamic interpretation capabilities, and being
> Modula-3 and innovative platform, it must have one. That's
> again what I think. I guess the way of not interrupting is
> just is m3-obliq stuff (since it's the scripting expression
> of Modula-3 RT) and prepare for the needed changes in the
> next big release. So for me would be like v 5.10 < 6.0
> Thanks in advance
> 
> --- El vie, 10/2/12, m3 at sol42.com <m3 at sol42.com>
> escribi?:
> 
> > De: m3 at sol42.com <m3 at sol42.com>
> > Asunto: Re: [M3devel] Think we need a new release.
> > Para: "m3devel" <m3devel at elegosoft.com>
> > Fecha: viernes, 10 de febrero, 2012 16:50
> > On 10 Feb 2012, at 15:14, Vintage
> > Coder wrote:
> > > What is the purpose of a new release? A compiler
> and
> > runtime that work presumably only need fixes.
> > 
> > Agreed.  I can think of two reasons: adding "must
> have"
> > stuff to the standard library, and fixing bugs or
> improving
> > library, compiler, or runtime.  Note that "must
> have"
> > should probably be evaluated in the context of systems
> > programming, which is what Modula-3 is for.
> > 
> > Even adding new platforms should not require bumping
> the
> > version number if it is the existing infrastructure
> that is
> > being ported.
> > 
> > There are loads of "greatest next thing" languages out
> there
> > that you have to re-learn every few releases. 
> Modula-3
> > is thankfully not one of them.  Want new stuff in
> the
> > language?  Then you want Modula-3+ or Modula-4.
> > 
> > Regards.
> > -Daniel
> > 
> > 
> >
> 


From dabenavidesd at yahoo.es  Sun Feb 12 22:36:20 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 12 Feb 2012 21:36:20 +0000 (GMT)
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <20120209175908.GC13717@topoi.pooq.com>
Message-ID: <1329082580.11381.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
There is a compile-time switch to not generate code for <*ASSERT exp*> back in DEC-SRC days ("Front-end options"):
http://homepages.cs.ncl.ac.uk/c.r.snow/home.formal/html/oldmod3/html/m3/options.html#first-pass

And it's still there is CM3 ("compile options") if you care:
http://opencm3.net/doc/help/cm3/m3build/options.html

Good to know, I bet if you try it, it would "work" as you first results. Wouldn't it?

Thanks in advance

--- El jue, 9/2/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] Assertion failed to complain
> Para: m3devel at elegosoft.com
> Fecha: jueves, 9 de febrero, 2012 12:59
> On Thu, Feb 09, 2012 at 05:51:24PM
> +0000, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > It might be that needs to be uppercase (in case
> compiler doesn't warn but I guess that would desired
> behavior, or not, since it would be unknown at compile
> time).
> > <*ASSERT exp*>
> > 
> > Thanks in advance
> 
> That was exactly it.  One of the few places where
> things are 
> case-sensitive, but a wrong case doesn't cause an error
> message.
> (in fact, it suppressed it)
> 
> Things are failing properly now.
> 
> -- hendrik
> 


From vintagecoder at aol.com  Mon Feb 13 15:06:30 2012
From: vintagecoder at aol.com (vintagecoder at aol.com)
Date: Mon, 13 Feb 2012 14:06:30 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <A0DF2CB8-A6D9-44B1-BC9B-B03DEEC9A52E@sol42.com>
Message-ID: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>

Hello Daniel,

> Agreed.  I can think of two reasons: adding "must have" stuff to the
> standard library, and fixing bugs or improving library, compiler, or
> runtime.  Note that "must have" should probably be evaluated in the
> context of systems programming, which is what Modula-3 is for.

For myself I tend to be very careful when it comes to "must have" in
language design. If you feel the language spec is outdated or insufficient,
then I think it's a dangerous, slippery slope to start adding features to
the language even if they are a must have, without a standards committee.
If people are not careful, they can turn a language that was designed well
into a junk heap before they know it. The threat to the death of a language
through inappropriate changes is far greater than the threat of death by
lack of changes.

If people agree the current spec is not sufficient, or wrong, it seems to
me the first step is to form a language specification committee where the
language can be carefully controlled- and this has to be from a purist
view of the language with no concern for implementation and no "baggage"
other than the existing language spec has to be respected- all the changes
have to be aligned and harmonious with the original purpose and intentions
and direction of Modula-3, otherwise what you said later about a new
language comes into play. Optional features have to be clearly optional-
extensions to the standard that don't make sense in the core have to be
clearly deliniated and the spec has to be amended cleanly to separate core
language, optional extensions, etc. The Ada specification is a good
document to look at for examples of how to do this.

> Even adding new platforms should not require bumping the version number
> if it is the existing infrastructure that is being ported.

Agreed.

> There are loads of "greatest next thing" languages out there that you
> have to re-learn every few releases.  Modula-3 is thankfully not one of
> them.

Agreed!

> Want new stuff in the language?  Then you want Modula-3+ or Modula-4.

Agreed again!

People are so used to constant turmoil because of Linux. I come from a much
different background and I value stability and evolution, not revolution.
New is not necessarily good just like old is not necessarily bad. Good
things pass the test of time and don't need constant changes. If we are
talking about changing the underlying implementation without changing the
language then of course this is fine and should not be held back. My
concern is about letting the implementation drive the specification- I feel
that is wrong, dangerous, and should be resisted.

Many languages today are out of control. To grow a language properly is an
extremely big challenge that has to be taken with a great deal of respect
and concern.


From vintagecoder at aol.com  Mon Feb 13 15:33:20 2012
From: vintagecoder at aol.com (vintagecoder at aol.com)
Date: Mon, 13 Feb 2012 14:33:20 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
Message-ID: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>

>> What is the purpose of a new release?
>
> from a technical perspective, probably not much but from a marketing
> perspective (language adoption, language value perception), there could
> be a few.

I realize my opinion is not the majority, but I'm less inclined to like
something that changes constantly or is popular. I try to find things that
are well designed and work. Constant releases are not on my list of
priorities.

>> Are you talking about a major new version or a mod level or what? The
>> last release on cm3 I see is from 2010.

> this probably disproves the argument of "6 years between releases",
> however, in the fast moving tech world, some people could consider 2010
> to be a long time ago.

Ok but anyone looking for Modula-3 should understand the history and
realize they are not interested in the latest language, if they were, they
wouldn't be in our group. I think that greatly lessens the impact of not
having frequent or regular releases. It's one of the reasons I joined the
development mailing list even though I probably have nothing to contribute
as a developer. I wanted to see if the project is alive. For me is seems it
is.

>> Are there bug fixes in the pipeline that haven't been verified? Are
>> there fixes ready to go that no builds have been done for? What is the
>> problem more frequent releases will solve?

> I think, it makes people perceive that the language has support, is being
> actively developed, is growing , and also that it is not dead.

For myself I was interested in those answers also, so I joined the mailing
list. I saw from the releases the project is going ahead. I see from the
fact they have so much platform support this is a serious and big project.
I have seen many other famous projects without nearly as much platform
support. I think anybody who is sincerely interested in Modula-3 can learn
you guys are serious and work is happening.

> I used to use tcl a lot, but I haven't got a new release in a while, and
> 8.6 took forever (5 years?) to get done. this made me move away from the
> technology, since I saw it at the time, as stagnating, stale, old and
> unsupported. 

That is very interesting because as someone looking for a new scripting
language, I found tcl very encouraging! I did the same thing as I did for
Modula-3. I followed the newsgroups and I saw people are using it. I saw
the releases and saw they are continuing to fix bugs. I don't need
something new, I need something good. Of course it's important the project
is alive and well so I don't find something good but dead. I saw tcl has
native support for sqlite and other interesting features. To me it looks
very much alive.

> had they put a "new" brand on it ever so often, I would have been more
> insterested. 

Ok but I think at some point people have to break the myth of constant
change as something favorable. 

> in general terms, once you know perl 5.10, would you be more exicet about
> learning perl 6.0 or 5.10.1 ? I mean, seriously, who gives a damn about a
> 0.0.1 release anyway?

It's not my view. I'm personally more happy with evolutionary growth. If
something isn't any good, I don't use it (unless I have to for work!) If
something is good, it doesn't need major changes, and changes are what
usually make things worse, not better. I realize my view might not be so
popular, but this is my view.

> the problem I see a new release would solve, is that you get to fix stuff
> (like the string broken stuff) that needs fixing, without having to
> maintain 100% backwards compatibility, this can lead to a cleaner
> language, like python3000 broke a lot of things, for instance.

I don't know Modula-3 (trying to learn it) enough to say what is broken.
But I do get nervous when I hear people say backwards compatibility isn't
important, and stands in the way of the future. For that I say if that is
really true, a group of people who really understand these things need to
carefully decide whether the language spec is broken or whether the
implementation is broken or both. And it has to be addressed based on the
outcome of that discussion, not by taking the situation too lightly. Just
to give you some idea of why I am saying this is because most of the
software I work on is 20 or more years old and I saw the value in having
experts who understand the purpose and the foundation involved in deciding
whether a new feature is good or not. Sometimes something looks very good
but it goes against the core direction. In this case a hard decision has to
be made to fork the product, or develop a new version. For a language it's
a very very serious process. If the spec is broken then perhaps it's time
to develop a new language as Daniel said. If the implementation is broken,
then sure it should be fixed to conform to the spec. But the main thing is
I believe especially for languages but for most software it is wrong and a
mistake to let the implentation drive the specification. You need to have
qualified good people managing the spec, and the implementation must come
after that.

>> Personally I see no benefit (indeed I see many disadvantges) to frequent
>> releases of stable software. 

> this is als true, there are disadvantages and I also suffer a little from
> this. but surely not something we cannot live through, especially if
> there is some kind of guide (3to4 ?)

I think I understand your point, but I feel this view is looking at the
language more like an OS. Languages and OS are very different creations. An
OS has to provide services to get work done. It doesn't necessarily have to
be pure because the end is more important than the means. But a language is
all about purity, otherwise all languages converge (indeed that is
happening!) and there becomes little value in any language since they all
do pretty much the same thing.

Language has to be about elegance and clarity in expression, and safety in
implementation so that the intent of the person using the language is
carried out as he expects, with no side effects or smoke and mirrors. For
this reason I am very opposed to growing languages without very careful
study by people who know the history and tradition of the language and give
it some degree of reverence.


>> But I often run backlevel intentionally. Firefox is being updated for
>> many reasons including security holes, bug fixes, new standards, and
>> more. If the Modula-3 standard hasn't been updated, what is driving the
>> need for new release(s)?

> if the language does not evolve, is it bound to die?

Not as far as I am concerned. But I still run programs in SNOBOL4 from
1969. YMMV ;-)

> if the standard does not evolve, should one consider it to be dead?

It might be dead, it might not. It all depends on whether the language is
still useful and people actually use it.

> see c++ for instance, recently, there have been changes to the language.
> this motivates a lot of tuff: conferences, new compilers, new books, new
> blogposts, and in general, a lot of "hype"

Right, but C++ has many problems and has popularity and issues Modula-3
happily doesn't have. If you are trying to compete with a mainstream
language you'll probably not be satisfied.

> if m3 was hyped a little, perhaps it could gain developers.

I think people who attracted by hype aren't the type of people who will
appreciate Modula-3.

> by gaining such developers, perhaps more bugs could be removed and
> features could be added as well (for instance, in the library space,
> where I see that other language have better, more tested, and easier to
> use LIbraries, but this is , of course, a subjective declaration, and I
> don't expect anyone to agree with me). 

I think it's important, just like in some other successful but maybe not so
elegant languages (C++, Java) to make a distinction between language and
libraries. Free Pascal seems to do this pretty well also. You (usually)
don't have to change the language spec or implementation to offer usable
libraries. If you do, it should be done carefully. But the language spec
should not be changed without much study and thought.

>> It looks like cm3 supports more platforms than I have. I would be
>> willing to help out (I am not a UNIX developer) any way I could. I have
>> Solaris Intel and SPARC boxes.
>
>that Is wonderful news, I appreciate the offer, I hope the language
>improves, and your boxes serve the purpose!

I see they already have SPARC Solaris support and I think x86 so I am not
able to offer anything new, but if I can help I will be glad to.

For me I am having a hard time finding learning materials. I think the
biggest boost to the language would come not from changing it or making new
releases, but to put together a really good book on Modula-3 and also
showing how cm3 implements it. The book should break these two things out
clearly so it could serve as a reference and guide to Modula-3 itself as
well as how to use cm3 to code in Modula-3. The main barrier to adoption
and new fans of Modula-3 is the lack of educational materials. You can
books on almost any topic on the net, but Modula-3 has almost nothing
available.



From dabenavidesd at yahoo.es  Mon Feb 13 17:08:53 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 13 Feb 2012 16:08:53 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>
Message-ID: <1329149333.68679.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:

To be honest, to make a language change (and of course I'm looking forward but respecting and acknowledging and respecting the path that brigs here) I'm not involved I'm not interested (so I realize your concern).
That's why, you know, I mentioned that we need to care about some issues so whoever comes later (in some time sadly or not many of our brains will be with more decades and some other will take that job of making it better this) will do it rightly.
Although I seem not care about us in the future I understand that we need more than a language revision (I'm not saying changes or update), we need:
1) Make the best effort we can (even that means some money) to try to recover design meetings, since there is already some bits in the SPWM3, I would like to recover the damaged tapes, if they ever really are somewhere and make the effort to at least recover the most of it. This to preserve that for posterity. I don't care more than if they are lost forever
2) Define Languages changes without experimenting makes no sense, so my thinking is that we need to implement gradually baby Modula-3 and start from there a serious (although painful) top down language definition according to the same rules defined or at least type compatible. If that needs human revision or machine learning I guess we would do that.
3) Whatever conclusion is taken a path of action will follow so anyone can always return to the point 1) until some agreement is made between all people.


Thanks in advance

--- El lun, 13/2/12, vintagecoder at aol.com <vintagecoder at aol.com> escribi?:

> De: vintagecoder at aol.com <vintagecoder at aol.com>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: m3devel at elegosoft.com
> Fecha: lunes, 13 de febrero, 2012 09:06
> Hello Daniel,
> 
> > Agreed.  I can think of two reasons: adding "must
> have" stuff to the
> > standard library, and fixing bugs or improving library,
> compiler, or
> > runtime.  Note that "must have" should probably be
> evaluated in the
> > context of systems programming, which is what Modula-3
> is for.
> 
> For myself I tend to be very careful when it comes to "must
> have" in
> language design. If you feel the language spec is outdated
> or insufficient,
> then I think it's a dangerous, slippery slope to start
> adding features to
> the language even if they are a must have, without a
> standards committee.
> If people are not careful, they can turn a language that was
> designed well
> into a junk heap before they know it. The threat to the
> death of a language
> through inappropriate changes is far greater than the threat
> of death by
> lack of changes.
> 
> If people agree the current spec is not sufficient, or
> wrong, it seems to
> me the first step is to form a language specification
> committee where the
> language can be carefully controlled- and this has to be
> from a purist
> view of the language with no concern for implementation and
> no "baggage"
> other than the existing language spec has to be respected-
> all the changes
> have to be aligned and harmonious with the original purpose
> and intentions
> and direction of Modula-3, otherwise what you said later
> about a new
> language comes into play. Optional features have to be
> clearly optional-
> extensions to the standard that don't make sense in the core
> have to be
> clearly deliniated and the spec has to be amended cleanly to
> separate core
> language, optional extensions, etc. The Ada specification is
> a good
> document to look at for examples of how to do this.
> 
> > Even adding new platforms should not require bumping
> the version number
> > if it is the existing infrastructure that is being
> ported.
> 
> Agreed.
> 
> > There are loads of "greatest next thing" languages out
> there that you
> > have to re-learn every few releases.  Modula-3 is
> thankfully not one of
> > them.
> 
> Agreed!
> 
> > Want new stuff in the language?  Then you want
> Modula-3+ or Modula-4.
> 
> Agreed again!
> 
> People are so used to constant turmoil because of Linux. I
> come from a much
> different background and I value stability and evolution,
> not revolution.
> New is not necessarily good just like old is not necessarily
> bad. Good
> things pass the test of time and don't need constant
> changes. If we are
> talking about changing the underlying implementation without
> changing the
> language then of course this is fine and should not be held
> back. My
> concern is about letting the implementation drive the
> specification- I feel
> that is wrong, dangerous, and should be resisted.
> 
> Many languages today are out of control. To grow a language
> properly is an
> extremely big challenge that has to be taken with a great
> deal of respect
> and concern.
> 


From vintagecoder at aol.com  Mon Feb 13 17:31:41 2012
From: vintagecoder at aol.com (Vintage Coder)
Date: Mon, 13 Feb 2012 16:31:41 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_-8bycGnCQekUFbABoYy1u9e0Otujvh-985CV90Wc5cH6g@mail.gmail.com>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
	<CAGi-_-8bycGnCQekUFbABoYy1u9e0Otujvh-985CV90Wc5cH6g@mail.gmail.com>
Message-ID: <367439191-1329150681-cardhu_decombobulator_blackberry.rim.net-766960143-@b15.c1.bise3.blackberry>

A video is "nice to have" but it wasn't what I am talking about. Nothing can replace a good book when it comes to learning a new language. 

The Ada wikibook is an example of a possible starting point. 

-----Original Message-----
From: felipe valdez <dataf4l at gmail.com>
Date: Mon, 13 Feb 2012 11:03:33 
To: <vintagecoder at aol.com>
Cc: <m3devel at elegosoft.com>
Subject: Re: [M3devel] Think we need a new release.

I recommend the video tutorial format, as I always have.


On Mon, Feb 13, 2012 at 9:33 AM,  <vintagecoder at aol.com> wrote:
>>> What is the purpose of a new release?
>>
>> from a technical perspective, probably not much but from a marketing
>> perspective (language adoption, language value perception), there could
>> be a few.
>
> I realize my opinion is not the majority, but I'm less inclined to like
> something that changes constantly or is popular. I try to find things that
> are well designed and work. Constant releases are not on my list of
> priorities.
>
>>> Are you talking about a major new version or a mod level or what? The
>>> last release on cm3 I see is from 2010.
>
>> this probably disproves the argument of "6 years between releases",
>> however, in the fast moving tech world, some people could consider 2010
>> to be a long time ago.
>
> Ok but anyone looking for Modula-3 should understand the history and
> realize they are not interested in the latest language, if they were, they
> wouldn't be in our group. I think that greatly lessens the impact of not
> having frequent or regular releases. It's one of the reasons I joined the
> development mailing list even though I probably have nothing to contribute
> as a developer. I wanted to see if the project is alive. For me is seems it
> is.
>
>>> Are there bug fixes in the pipeline that haven't been verified? Are
>>> there fixes ready to go that no builds have been done for? What is the
>>> problem more frequent releases will solve?
>
>> I think, it makes people perceive that the language has support, is being
>> actively developed, is growing , and also that it is not dead.
>
> For myself I was interested in those answers also, so I joined the mailing
> list. I saw from the releases the project is going ahead. I see from the
> fact they have so much platform support this is a serious and big project.
> I have seen many other famous projects without nearly as much platform
> support. I think anybody who is sincerely interested in Modula-3 can learn
> you guys are serious and work is happening.
>
>> I used to use tcl a lot, but I haven't got a new release in a while, and
>> 8.6 took forever (5 years?) to get done. this made me move away from the
>> technology, since I saw it at the time, as stagnating, stale, old and
>> unsupported.
>
> That is very interesting because as someone looking for a new scripting
> language, I found tcl very encouraging! I did the same thing as I did for
> Modula-3. I followed the newsgroups and I saw people are using it. I saw
> the releases and saw they are continuing to fix bugs. I don't need
> something new, I need something good. Of course it's important the project
> is alive and well so I don't find something good but dead. I saw tcl has
> native support for sqlite and other interesting features. To me it looks
> very much alive.
>
>> had they put a "new" brand on it ever so often, I would have been more
>> insterested.
>
> Ok but I think at some point people have to break the myth of constant
> change as something favorable.
>
>> in general terms, once you know perl 5.10, would you be more exicet about
>> learning perl 6.0 or 5.10.1 ? I mean, seriously, who gives a damn about a
>> 0.0.1 release anyway?
>
> It's not my view. I'm personally more happy with evolutionary growth. If
> something isn't any good, I don't use it (unless I have to for work!) If
> something is good, it doesn't need major changes, and changes are what
> usually make things worse, not better. I realize my view might not be so
> popular, but this is my view.
>
>> the problem I see a new release would solve, is that you get to fix stuff
>> (like the string broken stuff) that needs fixing, without having to
>> maintain 100% backwards compatibility, this can lead to a cleaner
>> language, like python3000 broke a lot of things, for instance.
>
> I don't know Modula-3 (trying to learn it) enough to say what is broken.
> But I do get nervous when I hear people say backwards compatibility isn't
> important, and stands in the way of the future. For that I say if that is
> really true, a group of people who really understand these things need to
> carefully decide whether the language spec is broken or whether the
> implementation is broken or both. And it has to be addressed based on the
> outcome of that discussion, not by taking the situation too lightly. Just
> to give you some idea of why I am saying this is because most of the
> software I work on is 20 or more years old and I saw the value in having
> experts who understand the purpose and the foundation involved in deciding
> whether a new feature is good or not. Sometimes something looks very good
> but it goes against the core direction. In this case a hard decision has to
> be made to fork the product, or develop a new version. For a language it's
> a very very serious process. If the spec is broken then perhaps it's time
> to develop a new language as Daniel said. If the implementation is broken,
> then sure it should be fixed to conform to the spec. But the main thing is
> I believe especially for languages but for most software it is wrong and a
> mistake to let the implentation drive the specification. You need to have
> qualified good people managing the spec, and the implementation must come
> after that.
>
>>> Personally I see no benefit (indeed I see many disadvantges) to frequent
>>> releases of stable software.
>
>> this is als true, there are disadvantages and I also suffer a little from
>> this. but surely not something we cannot live through, especially if
>> there is some kind of guide (3to4 ?)
>
> I think I understand your point, but I feel this view is looking at the
> language more like an OS. Languages and OS are very different creations. An
> OS has to provide services to get work done. It doesn't necessarily have to
> be pure because the end is more important than the means. But a language is
> all about purity, otherwise all languages converge (indeed that is
> happening!) and there becomes little value in any language since they all
> do pretty much the same thing.
>
> Language has to be about elegance and clarity in expression, and safety in
> implementation so that the intent of the person using the language is
> carried out as he expects, with no side effects or smoke and mirrors. For
> this reason I am very opposed to growing languages without very careful
> study by people who know the history and tradition of the language and give
> it some degree of reverence.
>
>
>>> But I often run backlevel intentionally. Firefox is being updated for
>>> many reasons including security holes, bug fixes, new standards, and
>>> more. If the Modula-3 standard hasn't been updated, what is driving the
>>> need for new release(s)?
>
>> if the language does not evolve, is it bound to die?
>
> Not as far as I am concerned. But I still run programs in SNOBOL4 from
> 1969. YMMV ;-)
>
>> if the standard does not evolve, should one consider it to be dead?
>
> It might be dead, it might not. It all depends on whether the language is
> still useful and people actually use it.
>
>> see c++ for instance, recently, there have been changes to the language.
>> this motivates a lot of tuff: conferences, new compilers, new books, new
>> blogposts, and in general, a lot of "hype"
>
> Right, but C++ has many problems and has popularity and issues Modula-3
> happily doesn't have. If you are trying to compete with a mainstream
> language you'll probably not be satisfied.
>
>> if m3 was hyped a little, perhaps it could gain developers.
>
> I think people who attracted by hype aren't the type of people who will
> appreciate Modula-3.
>
>> by gaining such developers, perhaps more bugs could be removed and
>> features could be added as well (for instance, in the library space,
>> where I see that other language have better, more tested, and easier to
>> use LIbraries, but this is , of course, a subjective declaration, and I
>> don't expect anyone to agree with me).
>
> I think it's important, just like in some other successful but maybe not so
> elegant languages (C++, Java) to make a distinction between language and
> libraries. Free Pascal seems to do this pretty well also. You (usually)
> don't have to change the language spec or implementation to offer usable
> libraries. If you do, it should be done carefully. But the language spec
> should not be changed without much study and thought.
>
>>> It looks like cm3 supports more platforms than I have. I would be
>>> willing to help out (I am not a UNIX developer) any way I could. I have
>>> Solaris Intel and SPARC boxes.
>>
>>that Is wonderful news, I appreciate the offer, I hope the language
>>improves, and your boxes serve the purpose!
>
> I see they already have SPARC Solaris support and I think x86 so I am not
> able to offer anything new, but if I can help I will be glad to.
>
> For me I am having a hard time finding learning materials. I think the
> biggest boost to the language would come not from changing it or making new
> releases, but to put together a really good book on Modula-3 and also
> showing how cm3 implements it. The book should break these two things out
> clearly so it could serve as a reference and guide to Modula-3 itself as
> well as how to use cm3 to code in Modula-3. The main barrier to adoption
> and new fans of Modula-3 is the lack of educational materials. You can
> books on almost any topic on the net, but Modula-3 has almost nothing
> available.
>



-- 
312-444-2124
Skype: f3l.headhunter
Casa: 8043901

From dataf4l at gmail.com  Mon Feb 13 17:03:33 2012
From: dataf4l at gmail.com (felipe valdez)
Date: Mon, 13 Feb 2012 11:03:33 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
Message-ID: <CAGi-_-8bycGnCQekUFbABoYy1u9e0Otujvh-985CV90Wc5cH6g@mail.gmail.com>

I recommend the video tutorial format, as I always have.


On Mon, Feb 13, 2012 at 9:33 AM,  <vintagecoder at aol.com> wrote:
>>> What is the purpose of a new release?
>>
>> from a technical perspective, probably not much but from a marketing
>> perspective (language adoption, language value perception), there could
>> be a few.
>
> I realize my opinion is not the majority, but I'm less inclined to like
> something that changes constantly or is popular. I try to find things that
> are well designed and work. Constant releases are not on my list of
> priorities.
>
>>> Are you talking about a major new version or a mod level or what? The
>>> last release on cm3 I see is from 2010.
>
>> this probably disproves the argument of "6 years between releases",
>> however, in the fast moving tech world, some people could consider 2010
>> to be a long time ago.
>
> Ok but anyone looking for Modula-3 should understand the history and
> realize they are not interested in the latest language, if they were, they
> wouldn't be in our group. I think that greatly lessens the impact of not
> having frequent or regular releases. It's one of the reasons I joined the
> development mailing list even though I probably have nothing to contribute
> as a developer. I wanted to see if the project is alive. For me is seems it
> is.
>
>>> Are there bug fixes in the pipeline that haven't been verified? Are
>>> there fixes ready to go that no builds have been done for? What is the
>>> problem more frequent releases will solve?
>
>> I think, it makes people perceive that the language has support, is being
>> actively developed, is growing , and also that it is not dead.
>
> For myself I was interested in those answers also, so I joined the mailing
> list. I saw from the releases the project is going ahead. I see from the
> fact they have so much platform support this is a serious and big project.
> I have seen many other famous projects without nearly as much platform
> support. I think anybody who is sincerely interested in Modula-3 can learn
> you guys are serious and work is happening.
>
>> I used to use tcl a lot, but I haven't got a new release in a while, and
>> 8.6 took forever (5 years?) to get done. this made me move away from the
>> technology, since I saw it at the time, as stagnating, stale, old and
>> unsupported.
>
> That is very interesting because as someone looking for a new scripting
> language, I found tcl very encouraging! I did the same thing as I did for
> Modula-3. I followed the newsgroups and I saw people are using it. I saw
> the releases and saw they are continuing to fix bugs. I don't need
> something new, I need something good. Of course it's important the project
> is alive and well so I don't find something good but dead. I saw tcl has
> native support for sqlite and other interesting features. To me it looks
> very much alive.
>
>> had they put a "new" brand on it ever so often, I would have been more
>> insterested.
>
> Ok but I think at some point people have to break the myth of constant
> change as something favorable.
>
>> in general terms, once you know perl 5.10, would you be more exicet about
>> learning perl 6.0 or 5.10.1 ? I mean, seriously, who gives a damn about a
>> 0.0.1 release anyway?
>
> It's not my view. I'm personally more happy with evolutionary growth. If
> something isn't any good, I don't use it (unless I have to for work!) If
> something is good, it doesn't need major changes, and changes are what
> usually make things worse, not better. I realize my view might not be so
> popular, but this is my view.
>
>> the problem I see a new release would solve, is that you get to fix stuff
>> (like the string broken stuff) that needs fixing, without having to
>> maintain 100% backwards compatibility, this can lead to a cleaner
>> language, like python3000 broke a lot of things, for instance.
>
> I don't know Modula-3 (trying to learn it) enough to say what is broken.
> But I do get nervous when I hear people say backwards compatibility isn't
> important, and stands in the way of the future. For that I say if that is
> really true, a group of people who really understand these things need to
> carefully decide whether the language spec is broken or whether the
> implementation is broken or both. And it has to be addressed based on the
> outcome of that discussion, not by taking the situation too lightly. Just
> to give you some idea of why I am saying this is because most of the
> software I work on is 20 or more years old and I saw the value in having
> experts who understand the purpose and the foundation involved in deciding
> whether a new feature is good or not. Sometimes something looks very good
> but it goes against the core direction. In this case a hard decision has to
> be made to fork the product, or develop a new version. For a language it's
> a very very serious process. If the spec is broken then perhaps it's time
> to develop a new language as Daniel said. If the implementation is broken,
> then sure it should be fixed to conform to the spec. But the main thing is
> I believe especially for languages but for most software it is wrong and a
> mistake to let the implentation drive the specification. You need to have
> qualified good people managing the spec, and the implementation must come
> after that.
>
>>> Personally I see no benefit (indeed I see many disadvantges) to frequent
>>> releases of stable software.
>
>> this is als true, there are disadvantages and I also suffer a little from
>> this. but surely not something we cannot live through, especially if
>> there is some kind of guide (3to4 ?)
>
> I think I understand your point, but I feel this view is looking at the
> language more like an OS. Languages and OS are very different creations. An
> OS has to provide services to get work done. It doesn't necessarily have to
> be pure because the end is more important than the means. But a language is
> all about purity, otherwise all languages converge (indeed that is
> happening!) and there becomes little value in any language since they all
> do pretty much the same thing.
>
> Language has to be about elegance and clarity in expression, and safety in
> implementation so that the intent of the person using the language is
> carried out as he expects, with no side effects or smoke and mirrors. For
> this reason I am very opposed to growing languages without very careful
> study by people who know the history and tradition of the language and give
> it some degree of reverence.
>
>
>>> But I often run backlevel intentionally. Firefox is being updated for
>>> many reasons including security holes, bug fixes, new standards, and
>>> more. If the Modula-3 standard hasn't been updated, what is driving the
>>> need for new release(s)?
>
>> if the language does not evolve, is it bound to die?
>
> Not as far as I am concerned. But I still run programs in SNOBOL4 from
> 1969. YMMV ;-)
>
>> if the standard does not evolve, should one consider it to be dead?
>
> It might be dead, it might not. It all depends on whether the language is
> still useful and people actually use it.
>
>> see c++ for instance, recently, there have been changes to the language.
>> this motivates a lot of tuff: conferences, new compilers, new books, new
>> blogposts, and in general, a lot of "hype"
>
> Right, but C++ has many problems and has popularity and issues Modula-3
> happily doesn't have. If you are trying to compete with a mainstream
> language you'll probably not be satisfied.
>
>> if m3 was hyped a little, perhaps it could gain developers.
>
> I think people who attracted by hype aren't the type of people who will
> appreciate Modula-3.
>
>> by gaining such developers, perhaps more bugs could be removed and
>> features could be added as well (for instance, in the library space,
>> where I see that other language have better, more tested, and easier to
>> use LIbraries, but this is , of course, a subjective declaration, and I
>> don't expect anyone to agree with me).
>
> I think it's important, just like in some other successful but maybe not so
> elegant languages (C++, Java) to make a distinction between language and
> libraries. Free Pascal seems to do this pretty well also. You (usually)
> don't have to change the language spec or implementation to offer usable
> libraries. If you do, it should be done carefully. But the language spec
> should not be changed without much study and thought.
>
>>> It looks like cm3 supports more platforms than I have. I would be
>>> willing to help out (I am not a UNIX developer) any way I could. I have
>>> Solaris Intel and SPARC boxes.
>>
>>that Is wonderful news, I appreciate the offer, I hope the language
>>improves, and your boxes serve the purpose!
>
> I see they already have SPARC Solaris support and I think x86 so I am not
> able to offer anything new, but if I can help I will be glad to.
>
> For me I am having a hard time finding learning materials. I think the
> biggest boost to the language would come not from changing it or making new
> releases, but to put together a really good book on Modula-3 and also
> showing how cm3 implements it. The book should break these two things out
> clearly so it could serve as a reference and guide to Modula-3 itself as
> well as how to use cm3 to code in Modula-3. The main barrier to adoption
> and new fans of Modula-3 is the lack of educational materials. You can
> books on almost any topic on the net, but Modula-3 has almost nothing
> available.
>



-- 
312-444-2124
Skype: f3l.headhunter
Casa: 8043901


From rodney_bates at lcwb.coop  Mon Feb 13 18:31:04 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 13 Feb 2012 11:31:04 -0600
Subject: [M3devel] Think we need a new release.
In-Reply-To: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>
References: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>
Message-ID: <4F3948D8.6000004@lcwb.coop>

This discussion reminds me of my first full-time software job.  The
division manager had a graph on his wall of bugs fixed per month.  He
considered a high fix rate evidence of success.  Some of us sat around
laughing about the incentives that created.

I also recall a wonderfully-written story about an aging programmer
who protected his job against the youth-is-smartest culture by keeping
carefully planned bugs in code that only he could fix.

I really do think the low level of activity in both the language
and its implementations reflects their having been done well to begin
with.  Unfortunately, I don't know how to sell that idea.  A lot of
people think like that division manager.

On 02/13/2012 08:06 AM, vintagecoder at aol.com wrote:
> Hello Daniel,
>
>> Agreed.  I can think of two reasons: adding "must have" stuff to the
>> standard library, and fixing bugs or improving library, compiler, or
>> runtime.  Note that "must have" should probably be evaluated in the
>> context of systems programming, which is what Modula-3 is for.
>
> For myself I tend to be very careful when it comes to "must have" in
> language design. If you feel the language spec is outdated or insufficient,
> then I think it's a dangerous, slippery slope to start adding features to
> the language even if they are a must have, without a standards committee.
> If people are not careful, they can turn a language that was designed well
> into a junk heap before they know it. The threat to the death of a language
> through inappropriate changes is far greater than the threat of death by
> lack of changes.
>
> If people agree the current spec is not sufficient, or wrong, it seems to
> me the first step is to form a language specification committee where the
> language can be carefully controlled- and this has to be from a purist
> view of the language with no concern for implementation and no "baggage"
> other than the existing language spec has to be respected- all the changes
> have to be aligned and harmonious with the original purpose and intentions
> and direction of Modula-3, otherwise what you said later about a new
> language comes into play. Optional features have to be clearly optional-
> extensions to the standard that don't make sense in the core have to be
> clearly deliniated and the spec has to be amended cleanly to separate core
> language, optional extensions, etc. The Ada specification is a good
> document to look at for examples of how to do this.
>
>> Even adding new platforms should not require bumping the version number
>> if it is the existing infrastructure that is being ported.
>
> Agreed.
>
>> There are loads of "greatest next thing" languages out there that you
>> have to re-learn every few releases.  Modula-3 is thankfully not one of
>> them.
>
> Agreed!
>
>> Want new stuff in the language?  Then you want Modula-3+ or Modula-4.
>
> Agreed again!
>
> People are so used to constant turmoil because of Linux. I come from a much
> different background and I value stability and evolution, not revolution.
> New is not necessarily good just like old is not necessarily bad. Good
> things pass the test of time and don't need constant changes. If we are
> talking about changing the underlying implementation without changing the
> language then of course this is fine and should not be held back. My
> concern is about letting the implementation drive the specification- I feel
> that is wrong, dangerous, and should be resisted.
>
> Many languages today are out of control. To grow a language properly is an
> extremely big challenge that has to be taken with a great deal of respect
> and concern.
>


From rcolebur at SCIRES.COM  Mon Feb 13 21:32:10 2012
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 13 Feb 2012 15:32:10 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>


>>For me I am having a hard time finding learning materials. I think the biggest boost to the language would 

Dear Vintage Coder:

The best books I have read on learning Modula-3 are:

1. Systems Programming with Modula-3, ed. Greg Nelson, ISBN 0-13-590464-1

2. Modula-3, Samuel P. Harbison, ISBN 0-13-596396-6

3. Programming in Modula-3, An Introduction in Programming with Style, Laszlo Boszormenyi & Carsten Weich, ISBN 3-540-57912-5

4. Algorithms in Modula-3, Robert Sedgewick, ISBN 0-201-53351-0

Regards,
Randy Coleburn


From dabenavidesd at yahoo.es  Mon Feb 13 21:36:08 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 13 Feb 2012 20:36:08 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <4F3948D8.6000004@lcwb.coop>
Message-ID: <1329165368.51042.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
In any case wondering whether he looses or not, fixing bugs is an important task in all computer programs, that's why ESC and others are important. But if you see those technologies back then were unsuccessful to find much use (because Modula-3 sources had not much RT errors, in Rd/Wr implementations, more in UI libraries), but just because doing annotations that restriction eases the test automation but costs are somehow seen as too high for doing that (even as relaxed in ESC/Java) respect of fixing them in the later stages (something they can compare because if they didn't use that tool they would know how much burden can be for doing that).
In reality people don't code faster but making painfully "slow releases" shows the "importance" of their work (and by that lack of productivity which is an symptom of the Crisis, and one of Objective of ESC).
GN asked why not produce code checkers that spend more computer time (even if they take extra time than night builds), well that's the reason, because they don't want to do that, they want short releases and bug-fixing by hand. 
That's why in the other hand Software Engineering is in Crisis, spending time in bugs fixes rather than writing code is another symptom Software crisis itself..
I will replay Greg Nelson lecture in U of Washington, I assume some principles are applied aside of checkers in systems development like in VHDL and some other tools:
http://www.uwtv.org/video/player.aspx?mediaid=1577083988

Of course there is a possible answer to that question, in the context of another Static checker, but my knowledge of that is it isn't operated  with that other checker or anything else (which was necessary in ESC case). This is if the program makes a big O() function I don't know.

Thanks in advance  



--- El lun, 13/2/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: m3devel at elegosoft.com
> Fecha: lunes, 13 de febrero, 2012 12:31
> This discussion reminds me of my
> first full-time software job.  The
> division manager had a graph on his wall of bugs fixed per
> month.  He
> considered a high fix rate evidence of success.  Some
> of us sat around
> laughing about the incentives that created.
> 
> I also recall a wonderfully-written story about an aging
> programmer
> who protected his job against the youth-is-smartest culture
> by keeping
> carefully planned bugs in code that only he could fix.
> 
> I really do think the low level of activity in both the
> language
> and its implementations reflects their having been done well
> to begin
> with.  Unfortunately, I don't know how to sell that
> idea.  A lot of
> people think like that division manager.
> 
> On 02/13/2012 08:06 AM, vintagecoder at aol.com
> wrote:
> > Hello Daniel,
> >
> >> Agreed.  I can think of two reasons: adding
> "must have" stuff to the
> >> standard library, and fixing bugs or improving
> library, compiler, or
> >> runtime.  Note that "must have" should
> probably be evaluated in the
> >> context of systems programming, which is what
> Modula-3 is for.
> >
> > For myself I tend to be very careful when it comes to
> "must have" in
> > language design. If you feel the language spec is
> outdated or insufficient,
> > then I think it's a dangerous, slippery slope to start
> adding features to
> > the language even if they are a must have, without a
> standards committee.
> > If people are not careful, they can turn a language
> that was designed well
> > into a junk heap before they know it. The threat to the
> death of a language
> > through inappropriate changes is far greater than the
> threat of death by
> > lack of changes.
> >
> > If people agree the current spec is not sufficient, or
> wrong, it seems to
> > me the first step is to form a language specification
> committee where the
> > language can be carefully controlled- and this has to
> be from a purist
> > view of the language with no concern for implementation
> and no "baggage"
> > other than the existing language spec has to be
> respected- all the changes
> > have to be aligned and harmonious with the original
> purpose and intentions
> > and direction of Modula-3, otherwise what you said
> later about a new
> > language comes into play. Optional features have to be
> clearly optional-
> > extensions to the standard that don't make sense in the
> core have to be
> > clearly deliniated and the spec has to be amended
> cleanly to separate core
> > language, optional extensions, etc. The Ada
> specification is a good
> > document to look at for examples of how to do this.
> >
> >> Even adding new platforms should not require
> bumping the version number
> >> if it is the existing infrastructure that is being
> ported.
> >
> > Agreed.
> >
> >> There are loads of "greatest next thing" languages
> out there that you
> >> have to re-learn every few releases.  Modula-3
> is thankfully not one of
> >> them.
> >
> > Agreed!
> >
> >> Want new stuff in the language?  Then you want
> Modula-3+ or Modula-4.
> >
> > Agreed again!
> >
> > People are so used to constant turmoil because of
> Linux. I come from a much
> > different background and I value stability and
> evolution, not revolution.
> > New is not necessarily good just like old is not
> necessarily bad. Good
> > things pass the test of time and don't need constant
> changes. If we are
> > talking about changing the underlying implementation
> without changing the
> > language then of course this is fine and should not be
> held back. My
> > concern is about letting the implementation drive the
> specification- I feel
> > that is wrong, dangerous, and should be resisted.
> >
> > Many languages today are out of control. To grow a
> language properly is an
> > extremely big challenge that has to be taken with a
> great deal of respect
> > and concern.
> >
> 


From lemming at henning-thielemann.de  Mon Feb 13 22:03:12 2012
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 13 Feb 2012 22:03:12 +0100 (CET)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
	<D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>
Message-ID: <alpine.DEB.2.00.1202132200360.16675@anubis.informatik.uni-halle.de>


On Mon, 13 Feb 2012, Coleburn, Randy wrote:

> 1. Systems Programming with Modula-3, ed. Greg Nelson, ISBN 0-13-590464-1
>
> 2. Modula-3, Samuel P. Harbison, ISBN 0-13-596396-6
>
> 3. Programming in Modula-3, An Introduction in Programming with Style, Laszlo Boszormenyi & Carsten Weich, ISBN 3-540-57912-5
>
> 4. Algorithms in Modula-3, Robert Sedgewick, ISBN 0-201-53351-0

I must say, that I was disappointed about the Sedgewick book, because it 
does not use any Modula-3 feature, no enumerations, no NEW, but instead 
global variables. Thus nothing you can learn good style Modula-3 
programming from.


From mika at async.caltech.edu  Mon Feb 13 22:28:43 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Mon, 13 Feb 2012 13:28:43 -0800
Subject: [M3devel] Think we need a new release.
In-Reply-To: <alpine.DEB.2.00.1202132200360.16675@anubis.informatik.uni-halle.de>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
	<D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>
	<alpine.DEB.2.00.1202132200360.16675@anubis.informatik.uni-halle.de>
Message-ID: <20120213212843.80A2F1A205B@async.async.caltech.edu>


I must say I have found few resources better for learning decent software
engineering techniques than just reading some of the sources from SRC.
The Modula-3 library (libm3) in particular.

    Mika


Henning Thielemann writes:
>
>On Mon, 13 Feb 2012, Coleburn, Randy wrote:
>
>> 1. Systems Programming with Modula-3, ed. Greg Nelson, ISBN 0-13-590464-1
>>
>> 2. Modula-3, Samuel P. Harbison, ISBN 0-13-596396-6
>>
>> 3. Programming in Modula-3, An Introduction in Programming with Style, Laszlo Boszormenyi & Carsten Weich, ISBN 3-540-57912-5
>>
>> 4. Algorithms in Modula-3, Robert Sedgewick, ISBN 0-201-53351-0
>
>I must say, that I was disappointed about the Sedgewick book, because it 
>does not use any Modula-3 feature, no enumerations, no NEW, but instead 
>global variables. Thus nothing you can learn good style Modula-3 
>programming from.


From dabenavidesd at yahoo.es  Mon Feb 13 22:26:37 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 13 Feb 2012 21:26:37 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <alpine.DEB.2.00.1202132200360.16675@anubis.informatik.uni-halle.de>
Message-ID: <1329168397.15682.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
in defense of the author's work I have read that someones () wanted a library of Algorithm Animations for accompanying the book and DEC-SRC distribution or so.
Since the Algorithm animations festivals held in DEC-SRC were before 1994, and some animations done before were decommissioned some time ago, it remains uncertain how many animations were done with Modula-3 at DEC-SRC:
http://www.internotesstrategy.com/softwareengg.php#

Perhpas the most advanced are there.
Thanks in advance 
 

--- El lun, 13/2/12, Henning Thielemann <lemming at henning-thielemann.de> escribi?:

> De: Henning Thielemann <lemming at henning-thielemann.de>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: "Coleburn, Randy" <rcolebur at SCIRES.COM>
> CC: "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: lunes, 13 de febrero, 2012 16:03
> 
> On Mon, 13 Feb 2012, Coleburn, Randy wrote:
> 
> > 1. Systems Programming with Modula-3, ed. Greg Nelson,
> ISBN 0-13-590464-1
> >
> > 2. Modula-3, Samuel P. Harbison, ISBN 0-13-596396-6
> >
> > 3. Programming in Modula-3, An Introduction in
> Programming with Style, Laszlo Boszormenyi & Carsten
> Weich, ISBN 3-540-57912-5
> >
> > 4. Algorithms in Modula-3, Robert Sedgewick, ISBN
> 0-201-53351-0
> 
> I must say, that I was disappointed about the Sedgewick
> book, because it 
> does not use any Modula-3 feature, no enumerations, no NEW,
> but instead 
> global variables. Thus nothing you can learn good style
> Modula-3 
> programming from.
> 


From jay.krell at cornell.edu  Tue Feb 14 02:21:23 2012
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 14 Feb 2012 01:21:23 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <4F3948D8.6000004@lcwb.coop>
References: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>,
	<4F3948D8.6000004@lcwb.coop>
Message-ID: <COL101-W552255EAA304C6746012F7E67C0@phx.gbl>


> I really do think the low level of activity in both the language
> and its implementations reflects their having been done well to begin
> with.  Unfortunately, I don't know how to sell that idea.  A lot of
> people think like that division manager.
I agree.But there is still work to do.Mainly increase portability and decrease platform-dependentness.    backend: such as via the existing M3x86, or LLVM     library: cooperative suspend   And/or at least update to newer gcc.  Improve debugging with stock gdb.  A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...  - Jay > Date: Mon, 13 Feb 2012 11:31:04 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Think we need a new release.
> 
> This discussion reminds me of my first full-time software job.  The
> division manager had a graph on his wall of bugs fixed per month.  He
> considered a high fix rate evidence of success.  Some of us sat around
> laughing about the incentives that created.
> 
> I also recall a wonderfully-written story about an aging programmer
> who protected his job against the youth-is-smartest culture by keeping
> carefully planned bugs in code that only he could fix.
> 
> I really do think the low level of activity in both the language
> and its implementations reflects their having been done well to begin
> with.  Unfortunately, I don't know how to sell that idea.  A lot of
> people think like that division manager.
> 
> On 02/13/2012 08:06 AM, vintagecoder at aol.com wrote:
> > Hello Daniel,
> >
> >> Agreed.  I can think of two reasons: adding "must have" stuff to the
> >> standard library, and fixing bugs or improving library, compiler, or
> >> runtime.  Note that "must have" should probably be evaluated in the
> >> context of systems programming, which is what Modula-3 is for.
> >
> > For myself I tend to be very careful when it comes to "must have" in
> > language design. If you feel the language spec is outdated or insufficient,
> > then I think it's a dangerous, slippery slope to start adding features to
> > the language even if they are a must have, without a standards committee.
> > If people are not careful, they can turn a language that was designed well
> > into a junk heap before they know it. The threat to the death of a language
> > through inappropriate changes is far greater than the threat of death by
> > lack of changes.
> >
> > If people agree the current spec is not sufficient, or wrong, it seems to
> > me the first step is to form a language specification committee where the
> > language can be carefully controlled- and this has to be from a purist
> > view of the language with no concern for implementation and no "baggage"
> > other than the existing language spec has to be respected- all the changes
> > have to be aligned and harmonious with the original purpose and intentions
> > and direction of Modula-3, otherwise what you said later about a new
> > language comes into play. Optional features have to be clearly optional-
> > extensions to the standard that don't make sense in the core have to be
> > clearly deliniated and the spec has to be amended cleanly to separate core
> > language, optional extensions, etc. The Ada specification is a good
> > document to look at for examples of how to do this.
> >
> >> Even adding new platforms should not require bumping the version number
> >> if it is the existing infrastructure that is being ported.
> >
> > Agreed.
> >
> >> There are loads of "greatest next thing" languages out there that you
> >> have to re-learn every few releases.  Modula-3 is thankfully not one of
> >> them.
> >
> > Agreed!
> >
> >> Want new stuff in the language?  Then you want Modula-3+ or Modula-4.
> >
> > Agreed again!
> >
> > People are so used to constant turmoil because of Linux. I come from a much
> > different background and I value stability and evolution, not revolution.
> > New is not necessarily good just like old is not necessarily bad. Good
> > things pass the test of time and don't need constant changes. If we are
> > talking about changing the underlying implementation without changing the
> > language then of course this is fine and should not be held back. My
> > concern is about letting the implementation drive the specification- I feel
> > that is wrong, dangerous, and should be resisted.
> >
> > Many languages today are out of control. To grow a language properly is an
> > extremely big challenge that has to be taken with a great deal of respect
> > and concern.
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120214/8a7f85a2/attachment.html>

From hendrik at topoi.pooq.com  Tue Feb 14 03:59:21 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 13 Feb 2012 21:59:21 -0500
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <289840BF-8FA7-4CD8-9908-9A65B4717F3F@gmail.com>
References: <20120209165624.GA13717@topoi.pooq.com>
	<289840BF-8FA7-4CD8-9908-9A65B4717F3F@gmail.com>
Message-ID: <20120214025921.GB11163@topoi.pooq.com>

On Thu, Feb 09, 2012 at 09:08:37PM -0500, Antony Hosking wrote:
> It?s supposed to warn for unrecognized pragma.

And I might have missed the warning.

Anyway, once I got the case right for ASSERT, I was able to finish 
debugging the program and get it running.  It's a rudimentary program 
that reads several similar text files and produces a variorum edition
-- one that says which lines all share, and which lines are now shared.
It's no limited to two files, like diff, and I can get it to produce 
useful output, unlike the mdiff I got from the FSF website and from a 
debian package.

It still needs cleaning up to be generally useful.  It's rather tuned 
to the particular files I'm dealing with.

-- hendrik


From vintagecoder at aol.com  Tue Feb 14 12:10:16 2012
From: vintagecoder at aol.com (vintagecoder at aol.com)
Date: Tue, 14 Feb 2012 11:10:16 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>
Message-ID: <201202141110.q1EBAK0i003441@imr-da02.mx.aol.com>

Thank you Randy, Henning, Mika for the notes on educational materials.

To Jay, don't forget Solaris builds work better with a non-gcc compiler. I
would hope cm3 would never require gcc or use gcc-specific extensions or it
will cause problems (with GPL3 in the newer versions of gcc) and also on
platforms where gcc isn't the best choice for various reasons.


From dragisha at m3w.org  Tue Feb 14 12:20:52 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 14 Feb 2012 12:20:52 +0100
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <COL101-W552255EAA304C6746012F7E67C0@phx.gbl>
References: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>,
	<4F3948D8.6000004@lcwb.coop>
	<COL101-W552255EAA304C6746012F7E67C0@phx.gbl>
Message-ID: <4DE3D685-C8B6-42E0-B4FA-0BA68594292E@m3w.org>

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).

With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).

Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?

On Feb 14, 2012, at 2:21 AM, Jay K wrote:

> A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...

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

From dabenavidesd at yahoo.es  Tue Feb 14 20:44:59 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 14 Feb 2012 19:44:59 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <4DE3D685-C8B6-42E0-B4FA-0BA68594292E@m3w.org>
Message-ID: <1329248699.74657.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
According to this it might be not p 20
ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf

In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829

Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.

Thanks in advance and please make any comments you may have

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 06:20

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
On Feb 14, 2012, at 2:21 AM, Jay K wrote:
A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120214/cbc375f3/attachment.html>

From jay.krell at cornell.edu  Wed Feb 15 01:23:58 2012
From: jay.krell at cornell.edu (Jay)
Date: Tue, 14 Feb 2012 16:23:58 -0800
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329248699.74657.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <1329248699.74657.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <5CF3B8E7-21C6-4CA7-89C5-B0542BFF2492@gmail.com>

You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...

 - Jay (phone)

On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> According to this it might be not p 20
> ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf
> 
> In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
> http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829
> 
> Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.
> 
> Thanks in advance and please make any comments you may have
> 
> --- El mar, 14/2/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] Think we need a new release. C target
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 14 de febrero, 2012 06:20
> 
> I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
> 
> With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
> 
> Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
> 
> On Feb 14, 2012, at 2:21 AM, Jay K wrote:
> 
>> A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120214/638d1942/attachment.html>

From dabenavidesd at yahoo.es  Wed Feb 15 20:10:56 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 15 Feb 2012 19:10:56 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <5CF3B8E7-21C6-4CA7-89C5-B0542BFF2492@gmail.com>
Message-ID: <1329333056.64488.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
doing by that method do I have compatibility with something else, meaning C? CM JVM? Yes, it achieved it through high compatibility using C language so you could migrate your Java code via CM JVM (without JNI, a kind of nightmare) to Modula-3 and C, now if we generate C, what would be gaining in terms of compatibility, gaining compatibility with those C Compilers, who cares that, just people writing C Code, if they don't or don't want to code in Modula-3, will be attracted by that offer? In CM JVM case it might be interested to migrate to C, but they need a good RT support, they don't need compilers to C. They have many ones already.
Now, if is you the one who want to migrate to C platforms well, Modula-3 can directly interface with C.
I wanted to make clear that my route will be Obliq, since the new real intermediate language becoming mainstream is JavaScript, and certainly the dear good M3 friend new that if it not were by one hair Obliq would be become the standard of the web. Now, why would we want to make a non-standard thing a product of our catalog, well, I pass that one into you, what is the main difference between C and Obliq if I tell you that FailSafe-C is project built on a Obliq JVM product?
Please have a look at DDJ about the "The JVM as a Language Farm Club" :
http://app.reg.techweb.com/e/es.aspx?s=2150&e=27044&elq=66547688035b4bc99ab7612af687575

Thanks in advance

--- El mar, 14/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay K" <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 19:23

You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...

?- Jay (phone)
On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
According to this it might be not p 20
ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf

In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829

Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.

Thanks in advance and please make any comments you may have

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we
 need a new release. C target
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 06:20

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
On Feb 14, 2012, at 2:21 AM, Jay K wrote:
A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120215/93ba8de9/attachment.html>

From jay.krell at cornell.edu  Wed Feb 15 20:43:47 2012
From: jay.krell at cornell.edu (Jay)
Date: Wed, 15 Feb 2012 11:43:47 -0800
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329333056.64488.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1329333056.64488.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <FDD14D29-1813-47B5-ADB1-2BB1BF25BD57@gmail.com>

No. None of this is the point, if it even makes sense.

The point is to use C as portable target.

If you want to run Obliq in a browser, compile it to JavaScript, possibly via something else, e.g. Java.

JavaScript isn't such a bad language though. The main difference among most languages is amount of static checking. People translate Java to JavaScript partly to get that static checking.

A C target would open up many old and new targets. And help debugging a lot, esp. on systems w/o m3gdb -- there are several.

A Java target and C# target would also be interesting.

 - Jay (phone)

On Feb 15, 2012, at 11:10 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> doing by that method do I have compatibility with something else, meaning C? CM JVM? Yes, it achieved it through high compatibility using C language so you could migrate your Java code via CM JVM (without JNI, a kind of nightmare) to Modula-3 and C, now if we generate C, what would be gaining in terms of compatibility, gaining compatibility with those C Compilers, who cares that, just people writing C Code, if they don't or don't want to code in Modula-3, will be attracted by that offer? In CM JVM case it might be interested to migrate to C, but they need a good RT support, they don't need compilers to C. They have many ones already.
> Now, if is you the one who want to migrate to C platforms well, Modula-3 can directly interface with C.
> I wanted to make clear that my route will be Obliq, since the new real intermediate language becoming mainstream is JavaScript, and certainly the dear good M3 friend new that if it not were by one hair Obliq would be become the standard of the web. Now, why would we want to make a non-standard thing a product of our catalog, well, I pass that one into you, what is the main difference between C and Obliq if I tell you that FailSafe-C is project built on a Obliq JVM product?
> Please have a look at DDJ about the "The JVM as a Language Farm Club" :
> http://app.reg.techweb.com/e/es.aspx?s=2150&e=27044&elq=66547688035b4bc99ab7612af687575
> 
> Thanks in advance
> 
> --- El mar, 14/2/12, Jay <jay.krell at cornell.edu> escribi?:
> 
> De: Jay <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] Think we need a new release. C target
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "Jay K" <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 14 de febrero, 2012 19:23
> 
> You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...
> 
>  - Jay (phone)
> 
> On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:
> 
>> Hi all:
>> According to this it might be not p 20
>> ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf
>> 
>> In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
>> http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829
>> 
>> Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.
>> 
>> Thanks in advance and please make any comments you may have
>> 
>> --- El mar, 14/2/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
>> 
>> De: Dragi?a Duri? <dragisha at m3w.org>
>> Asunto: Re: [M3devel] Think we need a new release. C target
>> Para: "Jay K" <jay.krell at cornell.edu>
>> CC: "m3devel" <m3devel at elegosoft.com>
>> Fecha: martes, 14 de febrero, 2012 06:20
>> 
>> I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
>> 
>> With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
>> 
>> Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
>> 
>> On Feb 14, 2012, at 2:21 AM, Jay K wrote:
>> 
>>> A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120215/73ab29f6/attachment.html>

From dabenavidesd at yahoo.es  Wed Feb 15 20:57:36 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 15 Feb 2012 19:57:36 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <FDD14D29-1813-47B5-ADB1-2BB1BF25BD57@gmail.com>
Message-ID: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.
If you want to code the RT for C, I don't know that well but Olivetti did that just as you say, but what we want is to be a member of The Language farm Club (aren't we).
If you want to make compilers to C or assembly, that's good but the it has been done in CLEF via M3CG->CLEF, CLEF compiler is written in java, nice!
I mean repeating this over and over doesn't make sense for me, what's the point here? The only thing left is Obliq to code for.
Thanks in advance

--- El mi?, 15/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay" <jay.krell at cornell.edu>, "Jay K" <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 15 de febrero, 2012 14:43

No. None of this is the point, if it even makes sense.
The point is to use C as portable target.
If you want to run Obliq in a browser, compile it to JavaScript, possibly via something else, e.g. Java.
JavaScript isn't such a bad language though. The main difference among most languages is amount of static checking. People translate Java to JavaScript partly to get that static checking.
A C target would open up many old and new targets. And help debugging a lot, esp. on systems w/o m3gdb -- there are several.
A Java target and C# target would also be interesting.
?- Jay (phone)
On Feb 15, 2012, at 11:10 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
doing by that method do I have compatibility with something else, meaning C? CM JVM? Yes, it achieved it through high compatibility using C language so you could migrate your Java code via CM JVM (without JNI, a kind of nightmare) to Modula-3 and C, now if we generate C, what would be gaining in terms of compatibility, gaining compatibility with those C Compilers, who cares that, just people writing C Code, if they don't or don't want to code in Modula-3, will be attracted by that offer? In CM JVM case it might be interested to migrate to C, but they need a good RT support, they don't need compilers to C. They have many ones already.
Now, if is you the one who want to migrate to C platforms well, Modula-3 can directly interface with C.
I wanted to make clear that my route will be Obliq, since the new real intermediate language becoming
 mainstream is JavaScript, and certainly the dear good M3 friend new that if it not were by one hair Obliq would be become the standard of the web. Now, why would we want to make a non-standard thing a product of our catalog, well, I pass that one into you, what is the main difference between C and Obliq if I tell you that FailSafe-C is project built on a Obliq JVM product?
Please have a look at DDJ about the "The JVM as a Language Farm Club" :
http://app.reg.techweb.com/e/es.aspx?s=2150&e=27044&elq=66547688035b4bc99ab7612af687575

Thanks in advance

--- El mar, 14/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay K"
 <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 19:23

You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...

?- Jay (phone)
On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
According to this it might be not p 20
ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf

In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829

Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.

Thanks in advance and please make any comments you may have

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we
 need a new release. C target
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 06:20

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
On Feb 14, 2012, at 2:21 AM, Jay K wrote:
A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120215/7a30d4d1/attachment.html>

From dabenavidesd at yahoo.es  Wed Feb 15 23:10:47 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 15 Feb 2012 22:10:47 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <FDD14D29-1813-47B5-ADB1-2BB1BF25BD57@gmail.com>
Message-ID: <1329343847.90050.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
think about not only back-ports, the only work usable of a C backend would be optimization for it, though it's hard we could make a case for that, see:
http://www.cs.tufts.edu/~nr/cs257/archive/craig-chambers/millstein-pldi03-draft.ps

I know of one work of C#-like compiler with Modula-3 constructs in lcc:
http://research.microsoft.com/pubs/70004/tr-2003-32.pdf

OK, maybe that would optimize hard Modula-3 programs I like that approach, since it would make a case for old (slower platforms) and of course of Big programs in newer machines.
In the Olivetti Modula-3, the speed of the backend was the main issue of not releasing it.
Thanks in advance


--- El mi?, 15/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay" <jay.krell at cornell.edu>, "Jay K" <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 15 de febrero, 2012 14:43

No. None of this is the point, if it even makes sense.
The point is to use C as portable target.
If you want to run Obliq in a browser, compile it to JavaScript, possibly via something else, e.g. Java.
JavaScript isn't such a bad language though. The main difference among most languages is amount of static checking. People translate Java to JavaScript partly to get that static checking.
A C target would open up many old and new targets. And help debugging a lot, esp. on systems w/o m3gdb -- there are several.
A Java target and C# target would also be interesting.
?- Jay (phone)
On Feb 15, 2012, at 11:10 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
doing by that method do I have compatibility with something else, meaning C? CM JVM? Yes, it achieved it through high compatibility using C language so you could migrate your Java code via CM JVM (without JNI, a kind of nightmare) to Modula-3 and C, now if we generate C, what would be gaining in terms of compatibility, gaining compatibility with those C Compilers, who cares that, just people writing C Code, if they don't or don't want to code in Modula-3, will be attracted by that offer? In CM JVM case it might be interested to migrate to C, but they need a good RT support, they don't need compilers to C. They have many ones already.
Now, if is you the one who want to migrate to C platforms well, Modula-3 can directly interface with C.
I wanted to make clear that my route will be Obliq, since the new real intermediate language becoming
 mainstream is JavaScript, and certainly the dear good M3 friend new that if it not were by one hair Obliq would be become the standard of the web. Now, why would we want to make a non-standard thing a product of our catalog, well, I pass that one into you, what is the main difference between C and Obliq if I tell you that FailSafe-C is project built on a Obliq JVM product?
Please have a look at DDJ about the "The JVM as a Language Farm Club" :
http://app.reg.techweb.com/e/es.aspx?s=2150&e=27044&elq=66547688035b4bc99ab7612af687575

Thanks in advance

--- El mar, 14/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay K"
 <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 19:23

You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...

?- Jay (phone)
On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
According to this it might be not p 20
ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf

In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829

Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.

Thanks in advance and please make any comments you may have

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we
 need a new release. C target
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 06:20

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
On Feb 14, 2012, at 2:21 AM, Jay K wrote:
A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120215/cad18a88/attachment.html>

From dragisha at m3w.org  Fri Feb 17 12:29:58 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 17 Feb 2012 12:29:58 +0100
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <B4107FAB-6385-480C-889F-BB904CDF4754@m3w.org>

To port to JVM or Javascript, you have to throw through the window a lot of what Modula-3 is. You will get, in best case, part of Modula-3.

On the other side, targeting to C (or C++) and losing object model from sight (while debugging), ie losing or distorting, also looks like an horrible side effect to me.

It looks like the best direction to concentrate effort is current GCC (a lot of platforms) and LLVM ((almost) new kid on the block with many good promises). The best thing about LLVM target is - IM is standardized and fully documented. Since we all know what pain is tagging along behind GCC IM (thanks to RMS losing licensing battle to SRC), LLVM looks like a promise of future freedom for Modula-3. Maye some day we will not be traumatized by every major (and most minor) GCC releases.

BTW, freepascal has it's own backend infrastructure. Maybe worth a try.

dd


On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.

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

From dabenavidesd at yahoo.es  Fri Feb 17 13:26:17 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 17 Feb 2012 12:26:17 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <B4107FAB-6385-480C-889F-BB904CDF4754@m3w.org>
Message-ID: <1329481577.26677.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
I don't think that's the case, Java has a JNI and it can work, but CM JVM is just a lot safer and easier to use, direct access to C code of the RT and you know what is better than that out there, in case of an attack? Modula-3 + Java seems the combination to win for me, ESC for both, I mean and what else do you need?

The point of what is Modula-3 a Systems Programming Language doesn't change that it is easier to deal with UNSAFE code, still we could add a keyword for say PROVED to allow the back-end check only for correct optimizations on it or to check UNSAFE code allowed to do so in either Java or Modula-3 or C. I don't care too much about PROVED or UNSAFE modules but more normal code and that's where Modula-3 could be helped by JVM dynamic verification (that said, it is not the best thing to do because this requires a lot of smart checking, I can give you an example of a program in Java that still manages to corrupt any class file in the cd, fooling the JVM) without JVM doing that much. That said compiler verification is much harder than normal checking, still there is research to allow one to do so.
Thanks in advance

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay" <jay.krell at cornell.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 06:29

To port to JVM or Javascript, you have to throw through the window a lot of what Modula-3 is. You will get, in best case, part of Modula-3.
On the other side, targeting to C (or C++) and losing object model from sight (while debugging), ie losing or distorting, also looks like an horrible side effect to me.
It looks like the best direction to concentrate effort is current GCC (a lot of platforms) and LLVM ((almost) new kid on the block with many good promises). The best thing about LLVM target is - IM is standardized and fully documented. Since we all know what pain is tagging along behind GCC IM (thanks to RMS losing licensing battle to SRC), LLVM looks like a promise of future freedom for Modula-3. Maye some day we will not be traumatized by every major (and most minor) GCC releases.
BTW, freepascal has it's own backend infrastructure. Maybe worth a try.
dd

On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides D. wrote:
Hi all:
The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120217/2a2e48a3/attachment.html>

From rodney_bates at lcwb.coop  Fri Feb 17 21:46:53 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 17 Feb 2012 14:46:53 -0600
Subject: [M3devel] An awkward interaction of language properties
Message-ID: <4F3EBCBD.2030802@lcwb.coop>

So, I have the following mutually recursive types:
----------------------------------------------------------------------------
DataStruct.i3:
INTERFACE DataStruct
; TYPE T = RECORD
              Relatives : ListRef
            (* Other fields. *)
            END
; TYPE ListRef = REF List
; TYPE List = ARRAY OF T
; END DataStruct
.
----------------------------------------------------------------------------

This works fine in Modula-3, if all three types are declared in the same scope.

Now suppose instead of builtin type constructor ARRAY OF, I need my set of
relatives to be an instantiation of a complex container data structure,
with a generic parameter for the type of its elements:

----------------------------------------------------------------------------
Container.ig:
GENERIC INTERFACE Container ( Elem )
(* Where Elem exports Elem.T, a type other than an open array type. *)
; TYPE T <: ROOT (* A container of Elem.T. *)
; PROCEDURE Get ( C : T ; Selector : INTEGER ; VAR Element : Elem . T )
; END Container
.
----------------------------------------------------------------------------
INTERFACE DTContainer = Container(DataStruct2) END DTContainer .
----------------------------------------------------------------------------
DataStruct2.i3:
INTERFACE DataStruct2
; IMPORT DTContainer
; TYPE Node = RECORD
                 Relatives : DTContainer . T
               (* Other fields. *)
               END
; END DataStruct2
.
----------------------------------------------------------------------------

This has cyclic imports and won't compile.  (A generic actual interface is
implicitly an import, which is made explicit by the rewrite rule for an
instantiation, 2.5.5)

The rule that recursive types have to be in the same scope and the fact that
an instantiation is a separate interface are irreconcilable.

The only way I can think of is to make the Relatives field be a REFANY,
and not import DTContainer into DataStruct2.  This loses static safety,
but at least it will be replaced by dynamic safety, at the cost of
runtime narrow checks every time I use Relatives.

Of course, I can cut down some on the frequency of RT type checks by grouping
nearby accesses to a Relatives field with a TYPECASE or assignment to a
variable (declared inside a module) of type DTContainer.T.

Anybody have any other thoughts on how to handle this?





From lemming at henning-thielemann.de  Fri Feb 17 21:57:13 2012
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 17 Feb 2012 21:57:13 +0100 (CET)
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <4F3EBCBD.2030802@lcwb.coop>
References: <4F3EBCBD.2030802@lcwb.coop>
Message-ID: <alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>


On Fri, 17 Feb 2012, Rodney M. Bates wrote:

> The only way I can think of is to make the Relatives field be a REFANY,
> and not import DTContainer into DataStruct2.  This loses static safety,
> but at least it will be replaced by dynamic safety, at the cost of
> runtime narrow checks every time I use Relatives.

Some REVEAL tricks instead of REFANY?


From rcolebur at SCIRES.COM  Fri Feb 17 23:51:06 2012
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 17 Feb 2012 17:51:06 -0500
Subject: [M3devel] compile errors in m3front's Formal.m3
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>

I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.

new source -> compiling Formal.m3
"..\src\values\Formal.m3", line 353: parameter not specified (traced)
"..\src\values\Formal.m3", line 432: unknown parameter (rhs)
"..\src\values\Formal.m3", line 432: incompatible types (traced)
"..\src\values\Formal.m3", line 437: parameter not specified (traced)
"..\src\values\Formal.m3", line 492: unknown parameter (rhs)
"..\src\values\Formal.m3", line 492: incompatible types (traced)
"..\src\values\Formal.m3", line 498: parameter not specified (traced)
"..\src\values\Formal.m3", line 512: unknown parameter (rhs)
"..\src\values\Formal.m3", line 512: incompatible types (traced)
"..\src\values\Formal.m3", line 515: parameter not specified (traced)
"..\src\values\Formal.m3", line 530: unknown parameter (rhs)
"..\src\values\Formal.m3", line 530: incompatible types (traced)
"..\src\values\Formal.m3", line 536: parameter not specified (traced)
"..\src\values\Formal.m3", line 552: unknown parameter (rhs)
"..\src\values\Formal.m3", line 552: incompatible types (traced)
"..\src\values\Formal.m3", line 555: parameter not specified (traced)
"..\src\values\Formal.m3", line 608: unknown parameter (rhs)
"..\src\values\Formal.m3", line 608: incompatible types (traced)
"..\src\values\Formal.m3", line 611: parameter not specified (traced)
"..\src\values\Formal.m3", line 627: unknown parameter (rhs)
"..\src\values\Formal.m3", line 627: incompatible types (traced)
"..\src\values\Formal.m3", line 630: parameter not specified (traced)
"..\src\values\Formal.m3", line 649: unknown parameter (rhs)
"..\src\values\Formal.m3", line 649: incompatible types (traced)
"..\src\values\Formal.m3", line 656: parameter not specified (traced)
25 errors encountered

Apparently, someone has checked in a change to Formal.m3 that
has compile errors.

Can whoever made the change please take a look and correct the problem.

Thanks,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120217/9e38c505/attachment.html>

From mika at async.caltech.edu  Sat Feb 18 06:37:13 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Fri, 17 Feb 2012 21:37:13 -0800
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>
References: <4F3EBCBD.2030802@lcwb.coop>
	<alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>
Message-ID: <20120218053713.890011A205B@async.async.caltech.edu>


Yes I should think if you declare the Container type in one interface,
to be <: ROOT you can then refer to that from the other interfaces.
Then you REVEAL the actual details in another interface that's not
imported by the others but only where it is needed.  Both the interfaces
you have can be generic.

    Mika


Henning Thielemann writes:
>
>On Fri, 17 Feb 2012, Rodney M. Bates wrote:
>
>> The only way I can think of is to make the Relatives field be a REFANY,
>> and not import DTContainer into DataStruct2.  This loses static safety,
>> but at least it will be replaced by dynamic safety, at the cost of
>> runtime narrow checks every time I use Relatives.
>
>Some REVEAL tricks instead of REFANY?


From dabenavidesd at yahoo.es  Sat Feb 18 15:24:43 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 18 Feb 2012 14:24:43 +0000 (GMT)
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>
Message-ID: <1329575083.11740.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
I think you can't "rebuild" but bootstrap with a step 0 bootstrap compiler and then proceed.
Thus you will get new compiler to build itself but not old building new. Hope it helps.

Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 17:51


 
 




I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.
?
new source -> compiling Formal.m3

"..\src\values\Formal.m3", line 353: parameter not specified (traced)

"..\src\values\Formal.m3", line 432: unknown parameter (rhs)

"..\src\values\Formal.m3", line 432: incompatible types (traced)

"..\src\values\Formal.m3", line 437: parameter not specified (traced)

"..\src\values\Formal.m3", line 492: unknown parameter (rhs)

"..\src\values\Formal.m3", line 492: incompatible types (traced)

"..\src\values\Formal.m3", line 498: parameter not specified (traced)

"..\src\values\Formal.m3", line 512: unknown parameter (rhs)

"..\src\values\Formal.m3", line 512: incompatible types (traced)

"..\src\values\Formal.m3", line 515: parameter not specified (traced)

"..\src\values\Formal.m3", line 530: unknown parameter (rhs)

"..\src\values\Formal.m3", line 530: incompatible types (traced)

"..\src\values\Formal.m3", line 536: parameter not specified (traced)

"..\src\values\Formal.m3", line 552: unknown parameter (rhs)

"..\src\values\Formal.m3", line 552: incompatible types (traced)

"..\src\values\Formal.m3", line 555: parameter not specified (traced)

"..\src\values\Formal.m3", line 608: unknown parameter (rhs)

"..\src\values\Formal.m3", line 608: incompatible types (traced)

"..\src\values\Formal.m3", line 611: parameter not specified (traced)

"..\src\values\Formal.m3", line 627: unknown parameter (rhs)

"..\src\values\Formal.m3", line 627: incompatible types (traced)

"..\src\values\Formal.m3", line 630: parameter not specified (traced)

"..\src\values\Formal.m3", line 649: unknown parameter (rhs)

"..\src\values\Formal.m3", line 649: incompatible types (traced)

"..\src\values\Formal.m3", line 656: parameter not specified (traced)

25 errors encountered
?
Apparently, someone has checked in a change to Formal.m3 that
has compile errors.
?
Can whoever made the change please take a look and correct the problem.
?
Thanks,
Randy Coleburn


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

From rcolebur at SCIRES.COM  Sat Feb 18 21:05:58 2012
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 18 Feb 2012 15:05:58 -0500
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <1329575083.11740.YahooMailClassic@web29704.mail.ird.yahoo.com>
References: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>
	<1329575083.11740.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6034A68D41C@atlex02-srv>

Daniel:

I do not understand your post.

I am following the same procedure and script that I've used for years with success.

It appears that someone has checked in code that doesn't compile, so the Formal.m3 file needs correction to make it compile.

Regards,
Randy Coleburn

From: Daniel Alejandro Benavides D.
Sent: Saturday, February 18, 2012 9:25 AM
To: m3devel; Coleburn, Randy
Subject: Re: [M3devel] compile errors in m3front's Formal.m3

Hi all:
I think you can't "rebuild" but bootstrap with a step 0 bootstrap compiler and then proceed.
Thus you will get new compiler to build itself but not old building new. Hope it helps.

Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>>
Fecha: viernes, 17 de febrero, 2012 17:51
I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.

new source -> compiling Formal.m3
"..\src\values\Formal.m3", line 353: parameter not specified (traced)
"..\src\values\Formal.m3", line 432: unknown parameter (rhs)
"..\src\values\Formal.m3", line 432: incompatible types (traced)
"..\src\values\Formal.m3", line 437: parameter not specified (traced)
"..\src\values\Formal.m3", line 492: unknown parameter (rhs)
"..\src\values\Formal.m3", line 492: incompatible types (traced)
"..\src\values\Formal.m3", line 498: parameter not specified (traced)
"..\src\values\Formal.m3", line 512: unknown parameter (rhs)
"..\src\values\Formal.m3", line 512: incompatible types (traced)
"..\src\values\Formal.m3", line 515: parameter not specified (traced)
"..\src\values\Formal.m3", line 530: unknown parameter (rhs)
"..\src\values\Formal.m3", line 530: incompatible types (traced)
"..\src\values\Formal.m3", line 536: parameter not specified (traced)
"..\src\values\Formal.m3", line 552: unknown parameter (rhs)
"..\src\values\Formal.m3", line 552: incompatible types (traced)
"..\src\values\Formal.m3", line 555: parameter not specified (traced)
"..\src\values\Formal.m3", line 608: unknown parameter (rhs)
"..\src\values\Formal.m3", line 608: incompatible types (traced)
"..\src\values\Formal.m3", line 611: parameter not specified (traced)
"..\src\values\Formal.m3", line 627: unknown parameter (rhs)
"..\src\values\Formal.m3", line 627: incompatible types (traced)
"..\src\values\Formal.m3", line 630: parameter not specified (traced)
"..\src\values\Formal.m3", line 649: unknown parameter (rhs)
"..\src\values\Formal.m3", line 649: incompatible types (traced)
"..\src\values\Formal.m3", line 656: parameter not specified (traced)
25 errors encountered

Apparently, someone has checked in a change to Formal.m3 that
has compile errors.

Can whoever made the change please take a look and correct the problem.

Thanks,
Randy Coleburn


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

From dabenavidesd at yahoo.es  Sat Feb 18 21:20:26 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 18 Feb 2012 20:20:26 +0000 (GMT)
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>
Message-ID: <1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:

Randy; I'm trying to verify with head all is OK but currently I can't bootstrap since I hit the same errors.

The other option will be trying to restore the old version (rev 1.13, I
assume I have that already, but I refuse to downgrade unless it is a real error, who knows if the compiler has that error, I
guess there is a way to bootstrap that again, but I can't do anything
else if the compiler can't compile it) in any event:

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/m3front/src/values/Formal.m3?rev=1.13;content-type=text%2Fplain



Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 17:51


 
 




I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.
?
new source -> compiling Formal.m3

"..\src\values\Formal.m3", line 353: parameter not specified (traced)

"..\src\values\Formal.m3", line 432: unknown parameter (rhs)

"..\src\values\Formal.m3", line 432: incompatible types (traced)

"..\src\values\Formal.m3", line 437: parameter not specified (traced)

"..\src\values\Formal.m3", line 492: unknown parameter (rhs)

"..\src\values\Formal.m3", line 492: incompatible types (traced)

"..\src\values\Formal.m3", line 498: parameter not specified (traced)

"..\src\values\Formal.m3", line 512: unknown parameter (rhs)

"..\src\values\Formal.m3", line 512: incompatible types (traced)

"..\src\values\Formal.m3", line 515: parameter not specified (traced)

"..\src\values\Formal.m3", line 530: unknown parameter (rhs)

"..\src\values\Formal.m3", line 530: incompatible types (traced)

"..\src\values\Formal.m3", line 536: parameter not specified (traced)

"..\src\values\Formal.m3", line 552: unknown parameter (rhs)

"..\src\values\Formal.m3", line 552: incompatible types (traced)

"..\src\values\Formal.m3", line 555: parameter not specified (traced)

"..\src\values\Formal.m3", line 608: unknown parameter (rhs)

"..\src\values\Formal.m3", line 608: incompatible types (traced)

"..\src\values\Formal.m3", line 611: parameter not specified (traced)

"..\src\values\Formal.m3", line 627: unknown parameter (rhs)

"..\src\values\Formal.m3", line 627: incompatible types (traced)

"..\src\values\Formal.m3", line 630: parameter not specified (traced)

"..\src\values\Formal.m3", line 649: unknown parameter (rhs)

"..\src\values\Formal.m3", line 649: incompatible types (traced)

"..\src\values\Formal.m3", line 656: parameter not specified (traced)

25 errors encountered
?
Apparently, someone has checked in a change to Formal.m3 that
has compile errors.
?
Can whoever made the change please take a look and correct the problem.
?
Thanks,
Randy Coleburn


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

From jay.krell at cornell.edu  Sat Feb 18 23:14:07 2012
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Feb 2012 22:14:07 +0000
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>,
	<1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W39A29D6DF3628F2E4A345CE6600@phx.gbl>


Tony broke this in December. https://mail.elegosoft.com/pipermail/m3commit/2011-December/date.html  - Jay
 Date: Sat, 18 Feb 2012 20:20:26 +0000
From: dabenavidesd at yahoo.es
To: m3devel at elegosoft.com; rcolebur at SCIRES.COM
Subject: Re: [M3devel] compile errors in m3front's Formal.m3

Hi all:

Randy; I'm trying to verify with head all is OK but currently I can't bootstrap since I hit the same errors.

The other option will be trying to restore the old version (rev 1.13, I
assume I have that already, but I refuse to downgrade unless it is a real error, who knows if the compiler has that error, I
guess there is a way to bootstrap that again, but I can't do anything
else if the compiler can't compile it) in any event:

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/m3front/src/values/Formal.m3?rev=1.13;content-type=text%2Fplain



Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 17:51


 
 




I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.
 
new source -> compiling Formal.m3

"..\src\values\Formal.m3", line 353: parameter not specified (traced)

"..\src\values\Formal.m3", line 432: unknown parameter (rhs)

"..\src\values\Formal.m3", line 432: incompatible types (traced)

"..\src\values\Formal.m3", line 437: parameter not specified (traced)

"..\src\values\Formal.m3", line 492: unknown parameter (rhs)

"..\src\values\Formal.m3", line 492: incompatible types (traced)

"..\src\values\Formal.m3", line 498: parameter not specified (traced)

"..\src\values\Formal.m3", line 512: unknown parameter (rhs)

"..\src\values\Formal.m3", line 512: incompatible types (traced)

"..\src\values\Formal.m3", line 515: parameter not specified (traced)

"..\src\values\Formal.m3", line 530: unknown parameter (rhs)

"..\src\values\Formal.m3", line 530: incompatible types (traced)

"..\src\values\Formal.m3", line 536: parameter not specified (traced)

"..\src\values\Formal.m3", line 552: unknown parameter (rhs)

"..\src\values\Formal.m3", line 552: incompatible types (traced)

"..\src\values\Formal.m3", line 555: parameter not specified (traced)

"..\src\values\Formal.m3", line 608: unknown parameter (rhs)

"..\src\values\Formal.m3", line 608: incompatible types (traced)

"..\src\values\Formal.m3", line 611: parameter not specified (traced)

"..\src\values\Formal.m3", line 627: unknown parameter (rhs)

"..\src\values\Formal.m3", line 627: incompatible types (traced)

"..\src\values\Formal.m3", line 630: parameter not specified (traced)

"..\src\values\Formal.m3", line 649: unknown parameter (rhs)

"..\src\values\Formal.m3", line 649: incompatible types (traced)

"..\src\values\Formal.m3", line 656: parameter not specified (traced)

25 errors encountered
 
Apparently, someone has checked in a change to Formal.m3 that
has compile errors.
 
Can whoever made the change please take a look and correct the problem.
 
Thanks,
Randy Coleburn


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

From dabenavidesd at yahoo.es  Sat Feb 18 23:36:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 18 Feb 2012 22:36:34 +0000 (GMT)
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <COL101-W39A29D6DF3628F2E4A345CE6600@phx.gbl>
Message-ID: <1329604594.68674.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
Without trying to spam (sorry if anybody thinks so), the problem might be in the compiler itself rather than in the source code in last revision.
But now, who can give it a try of compiling that with the Modula-3 front-end and verify that the compiler is wrong (and the only thing that comes to mind is the Olivetti? Modula-3 pragmas, somehow we should develop verification condition generator for that in an effort to correct this), perhaps that's easier to proof I assume, rather than trying to check for erasing changes over and over (I mean one would never finish as C-based SE has proved).

Thanks in advance

Thanks in advance

--- El s?b, 18/2/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] compile errors in m3front's Formal.m3
Para: dabenavidesd at yahoo.es, "m3devel" <m3devel at elegosoft.com>, rcolebur at scires.com, "Tony" <hosking at cs.purdue.edu>
Fecha: s?bado, 18 de febrero, 2012 17:14




Tony broke this in December.
?
https://mail.elegosoft.com/pipermail/m3commit/2011-December/date.html
?
?- Jay
?
Date: Sat, 18 Feb 2012 20:20:26 +0000
From: dabenavidesd at yahoo.es
To: m3devel at elegosoft.com; rcolebur at SCIRES.COM
Subject: Re: [M3devel] compile errors in m3front's Formal.m3

Hi all:

Randy; I'm trying to verify with head all is OK but currently I can't bootstrap since I hit the same errors.

The other option will be trying to restore the old version (rev 1.13, I
assume I have that already, but I refuse to downgrade unless it is a real error, who knows if the compiler has that error, I
guess there is a way to bootstrap that again, but I can't do anything
else if the compiler can't compile it) in any event:

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/m3front/src/values/Formal.m3?rev=1.13;content-type=text%2Fplain



Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 17:51


 
 


#yiv1612936010 .yiv1612936010ExternalClass #yiv1612936010ecxyiv1293036 P
{margin-bottom:0px;}





I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.
?
new source -> compiling Formal.m3

"..\src\values\Formal.m3", line 353: parameter not specified (traced)

"..\src\values\Formal.m3", line 432: unknown parameter (rhs)

"..\src\values\Formal.m3", line 432: incompatible types (traced)

"..\src\values\Formal.m3", line 437: parameter not specified (traced)

"..\src\values\Formal.m3", line 492: unknown parameter (rhs)

"..\src\values\Formal.m3", line 492: incompatible types (traced)

"..\src\values\Formal.m3", line 498: parameter not specified (traced)

"..\src\values\Formal.m3", line 512: unknown parameter (rhs)

"..\src\values\Formal.m3", line 512: incompatible types (traced)

"..\src\values\Formal.m3", line 515: parameter not specified (traced)

"..\src\values\Formal.m3", line 530: unknown parameter (rhs)

"..\src\values\Formal.m3", line 530: incompatible types (traced)

"..\src\values\Formal.m3", line 536: parameter not specified (traced)

"..\src\values\Formal.m3", line 552: unknown parameter (rhs)

"..\src\values\Formal.m3", line 552: incompatible types (traced)

"..\src\values\Formal.m3", line 555: parameter not specified (traced)

"..\src\values\Formal.m3", line 608: unknown parameter (rhs)

"..\src\values\Formal.m3", line 608: incompatible types (traced)

"..\src\values\Formal.m3", line 611: parameter not specified (traced)

"..\src\values\Formal.m3", line 627: unknown parameter (rhs)

"..\src\values\Formal.m3", line 627: incompatible types (traced)

"..\src\values\Formal.m3", line 630: parameter not specified (traced)

"..\src\values\Formal.m3", line 649: unknown parameter (rhs)

"..\src\values\Formal.m3", line 649: incompatible types (traced)

"..\src\values\Formal.m3", line 656: parameter not specified (traced)

25 errors encountered
?
Apparently, someone has checked in a change to Formal.m3 that
has compile errors.
?
Can whoever made the change please take a look and correct the problem.
?
Thanks,
Randy Coleburn


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

From dabenavidesd at yahoo.es  Sat Feb 18 23:40:29 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 18 Feb 2012 22:40:29 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329481577.26677.YahooMailClassic@web29705.mail.ird.yahoo.com>
Message-ID: <1329604829.41174.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
Interestingly Java had (along ago) UNSAFE extensions into the language:

http://groups.google.com/group/microsoft.public.dotnet.general/browse_thread/thread/bdbaaafa49579931/d9a25710e7e1cdc4%3Fq%3D%2522David%2BChase%2522%23d9a25710e7e1cdc4&ei=iGwTS6eaOpW8Qpmqic0O&sa=t&ct=res&cd=49&source=groups&usg=AFQjCNGAFKXr0Lh9Zhp47J8i8nnVUMePyw

I insist we should get back the Original test suite of SUN, this would help so much the Modula-3 RT (remember this guys worked hard in Modula-3 until the compiler got unsupported or at least until they thought it wouldn't get that much support).

Thanks in advance


--- El vie, 17/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Dragi?a Duri?" <dragisha at m3w.org>
CC: "m3devel" <m3devel at elegosoft.com>, "Jay" <jay.krell at cornell.edu>
Fecha: viernes, 17 de febrero, 2012 07:26

Hi all:
I don't think that's the case, Java has a JNI and it can work, but CM JVM is just a lot safer and easier to use, direct access to C code of the RT and you know what is better than that out there, in case of an attack? Modula-3 + Java seems the combination to win for me, ESC for both, I mean and what else do you need?

The point of what is Modula-3 a Systems Programming Language doesn't change that it is easier to deal with UNSAFE code, still we could add a keyword for say PROVED to allow the back-end check only for correct optimizations on it or to check UNSAFE code allowed to do so in either Java or Modula-3 or C. I don't care too much about PROVED or UNSAFE modules but more normal code and that's where Modula-3 could be helped by JVM dynamic verification (that said, it is not the best thing to do because this requires a lot of smart checking,
 I can give you an example of a program in Java that still manages to corrupt any class file in the cd, fooling the JVM) without JVM doing that much. That said compiler verification is much harder than normal checking, still there is research to allow one to do so.
Thanks in advance

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay" <jay.krell at cornell.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 06:29

To port to JVM or Javascript, you have to throw through the window a lot of what Modula-3 is. You will get, in best case, part of
 Modula-3.
On the other side, targeting to C (or C++) and losing object model from sight (while debugging), ie losing or distorting, also looks like an horrible side effect to me.
It looks like the best direction to concentrate effort is current GCC (a lot of platforms) and LLVM ((almost) new kid on the block with many good promises). The best thing about LLVM target is - IM is standardized and fully documented. Since we all know what pain is tagging along behind GCC IM (thanks to RMS losing licensing battle to SRC), LLVM looks like a promise of future freedom for Modula-3. Maye some day we will not be traumatized by every major (and most minor) GCC releases.
BTW, freepascal has it's own backend infrastructure. Maybe worth a try.
dd

On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides D. wrote:
Hi all:
The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120218/4a4c9d5c/attachment.html>

From rodney_bates at lcwb.coop  Sun Feb 19 19:18:02 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 19 Feb 2012 12:18:02 -0600
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <B4107FAB-6385-480C-889F-BB904CDF4754@m3w.org>
References: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com>
	<B4107FAB-6385-480C-889F-BB904CDF4754@m3w.org>
Message-ID: <4F413CDA.8080006@lcwb.coop>



On 02/17/2012 05:29 AM, Dragi?a Duri? wrote:
> To port to JVM or Javascript, you have to throw through the window a lot of what Modula-3 is. You will get, in best case, part of Modula-3.
>

Once, I was peripherally involved in a project that was planning to translate
Ada to JVM code.  After a bit of design work, they quickly abandoned that idea.

Java reflects the popular procrustean philosophy that object-oriented constructs
should be almost the only tool in your box.  As a result, the set of non-heap-allocated
types is highly impoverished, with no programmer-defined type constructors at all.
This is reflected in the JVM.  It doesn't have the constructs to support the richer
type system of Ada or Modula-3.  At the very least, some other bytecode design
would be needed.

> On the other side, targeting to C (or C++) and losing object model from sight (while debugging), ie losing or distorting, also looks like an horrible side effect to me.
>
> It looks like the best direction to concentrate effort is current GCC (a lot of platforms) and LLVM ((almost) new kid on the block with many good promises). The best thing about LLVM target is - IM is standardized and fully documented. Since we all know what pain is tagging along behind GCC IM (thanks to RMS losing licensing battle to SRC), LLVM looks like a promise of future freedom for Modula-3. Maye some day we will not be traumatized by every major (and most minor) GCC releases.
>
> BTW, freepascal has it's own backend infrastructure. Maybe worth a try.
>
> dd
>
>
> On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides D. wrote:
>
>> Hi all:
>> The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.
>>
>


From dabenavidesd at yahoo.es  Sun Feb 19 19:43:23 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 19 Feb 2012 18:43:23 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <4F413CDA.8080006@lcwb.coop>
Message-ID: <1329677003.22402.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
Thankfully some theoretical work towards unifying JavaScript Object model to the one of Obliq (did some work on that), and some of the harder work has been done in optimization (Google V8, Safari, etc) and JS VM has been written in JavaScript, then I still don't get why we can't if both theoretically and practically has been done.
I have studied in some form the JVM and I can say very clearly that it's a CISC architecture, I don't see too much of the object model in it bundled (like Uniform treatment of Integer, Scalar types and just the fact that vectorial types are like so, makes conclude that).
Thanks in advance

--- El dom, 19/2/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] Think we need a new release. C target
> Para: m3devel at elegosoft.com
> Fecha: domingo, 19 de febrero, 2012 13:18
> 
> 
> On 02/17/2012 05:29 AM, Dragi?a Duri? wrote:
> > To port to JVM or Javascript, you have to throw through
> the window a lot of what Modula-3 is. You will get, in best
> case, part of Modula-3.
> >
> 
> Once, I was peripherally involved in a project that was
> planning to translate
> Ada to JVM code.  After a bit of design work, they
> quickly abandoned that idea.
> 
> Java reflects the popular procrustean philosophy that
> object-oriented constructs
> should be almost the only tool in your box.  As a
> result, the set of non-heap-allocated
> types is highly impoverished, with no programmer-defined
> type constructors at all.
> This is reflected in the JVM.  It doesn't have the
> constructs to support the richer
> type system of Ada or Modula-3.  At the very least,
> some other bytecode design
> would be needed.
> 
> > On the other side, targeting to C (or C++) and losing
> object model from sight (while debugging), ie losing or
> distorting, also looks like an horrible side effect to me.
> >
> > It looks like the best direction to concentrate effort
> is current GCC (a lot of platforms) and LLVM ((almost) new
> kid on the block with many good promises). The best thing
> about LLVM target is - IM is standardized and fully
> documented. Since we all know what pain is tagging along
> behind GCC IM (thanks to RMS losing licensing battle to
> SRC), LLVM looks like a promise of future freedom for
> Modula-3. Maye some day we will not be traumatized by every
> major (and most minor) GCC releases.
> >
> > BTW, freepascal has it's own backend infrastructure.
> Maybe worth a try.
> >
> > dd
> >
> >
> > On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides
> D. wrote:
> >
> >> Hi all:
> >> The point is whether we want to migrate our current
> RT to C or JavaScript, my question is why not (Java/) JVM or
> Obliq.
> >>
> >
> 


From dabenavidesd at yahoo.es  Mon Feb 20 22:02:08 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 20 Feb 2012 21:02:08 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329677003.22402.YahooMailClassic@web29705.mail.ird.yahoo.com>
Message-ID: <1329771728.2749.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
in the other way Jay has proposed could be realized nicely with M3CG to extend CLEF compiler to do that, making type inference explicit could aid the JVM smartly check the IL to avoid gcc IR step and add extended static checking on it, to check for lower level RT errors in case it's necessary to. For instance check integer overflows, etc.
Thanks in advance 

--- El dom, 19/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] Think we need a new release. C target
> Para: m3devel at elegosoft.com, "Rodney M. Bates" <rodney_bates at lcwb.coop>
> Fecha: domingo, 19 de febrero, 2012 13:43
> Hi all:
> Thankfully some theoretical work towards unifying JavaScript
> Object model to the one of Obliq (did some work on that),
> and some of the harder work has been done in optimization
> (Google V8, Safari, etc) and JS VM has been written in
> JavaScript, then I still don't get why we can't if both
> theoretically and practically has been done.
> I have studied in some form the JVM and I can say very
> clearly that it's a CISC architecture, I don't see too much
> of the object model in it bundled (like Uniform treatment of
> Integer, Scalar types and just the fact that vectorial types
> are like so, makes conclude that).
> Thanks in advance
> 
> --- El dom, 19/2/12, Rodney M. Bates <rodney_bates at lcwb.coop>
> escribi?:
> 
> > De: Rodney M. Bates <rodney_bates at lcwb.coop>
> > Asunto: Re: [M3devel] Think we need a new release. C
> target
> > Para: m3devel at elegosoft.com
> > Fecha: domingo, 19 de febrero, 2012 13:18
> > 
> > 
> > On 02/17/2012 05:29 AM, Dragi?a Duri? wrote:
> > > To port to JVM or Javascript, you have to throw
> through
> > the window a lot of what Modula-3 is. You will get, in
> best
> > case, part of Modula-3.
> > >
> > 
> > Once, I was peripherally involved in a project that
> was
> > planning to translate
> > Ada to JVM code.  After a bit of design work,
> they
> > quickly abandoned that idea.
> > 
> > Java reflects the popular procrustean philosophy that
> > object-oriented constructs
> > should be almost the only tool in your box.  As a
> > result, the set of non-heap-allocated
> > types is highly impoverished, with no
> programmer-defined
> > type constructors at all.
> > This is reflected in the JVM.  It doesn't have
> the
> > constructs to support the richer
> > type system of Ada or Modula-3.  At the very
> least,
> > some other bytecode design
> > would be needed.
> > 
> > > On the other side, targeting to C (or C++) and
> losing
> > object model from sight (while debugging), ie losing
> or
> > distorting, also looks like an horrible side effect to
> me.
> > >
> > > It looks like the best direction to concentrate
> effort
> > is current GCC (a lot of platforms) and LLVM ((almost)
> new
> > kid on the block with many good promises). The best
> thing
> > about LLVM target is - IM is standardized and fully
> > documented. Since we all know what pain is tagging
> along
> > behind GCC IM (thanks to RMS losing licensing battle
> to
> > SRC), LLVM looks like a promise of future freedom for
> > Modula-3. Maye some day we will not be traumatized by
> every
> > major (and most minor) GCC releases.
> > >
> > > BTW, freepascal has it's own backend
> infrastructure.
> > Maybe worth a try.
> > >
> > > dd
> > >
> > >
> > > On Feb 15, 2012, at 8:57 PM, Daniel Alejandro
> Benavides
> > D. wrote:
> > >
> > >> Hi all:
> > >> The point is whether we want to migrate our
> current
> > RT to C or JavaScript, my question is why not (Java/)
> JVM or
> > Obliq.
> > >>
> > >
> >
> 


From rodney_bates at lcwb.coop  Tue Feb 21 21:59:17 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 21 Feb 2012 14:59:17 -0600
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <20120218053713.890011A205B@async.async.caltech.edu>
References: <4F3EBCBD.2030802@lcwb.coop>	<alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>
	<20120218053713.890011A205B@async.async.caltech.edu>
Message-ID: <4F4405A5.50706@lcwb.coop>

At first I thought this was the answer, but. alas, on closer look no.
If I make Relatives opaque, I would need to reveal it as DTContainer.T.
But a revelation must be a type constructor, not just a type name.
I would have to have two different types, Container.T and the type of
Relatives, each opaque, both revealed as the same type.  You can't do
that, because every opaque type declaration creates a unique type and
requires a unique type expression as its revelation. (It has to be
BRANDED too.)

I could break the cycle differently by making DataStruct2.Node
opaque.  Container has no need to know about the field Relatives,
so that could be in a revelation of Node, not imported by Container.
But that would require that Node be a reference type, and
I really want not to have to make values of Node be separately
heap-allocated.

On 02/17/2012 11:37 PM, Mika Nystrom wrote:
> Yes I should think if you declare the Container type in one interface,
> to be<: ROOT you can then refer to that from the other interfaces.
> Then you REVEAL the actual details in another interface that's not
> imported by the others but only where it is needed.  Both the interfaces
> you have can be generic.
>
>      Mika
>
>
> Henning Thielemann writes:
>>
>> On Fri, 17 Feb 2012, Rodney M. Bates wrote:
>>
>>> The only way I can think of is to make the Relatives field be a REFANY,
>>> and not import DTContainer into DataStruct2.  This loses static safety,
>>> but at least it will be replaced by dynamic safety, at the cost of
>>> runtime narrow checks every time I use Relatives.
>>
>> Some REVEAL tricks instead of REFANY?
>


From rodney_bates at lcwb.coop  Wed Feb 22 18:45:50 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 22 Feb 2012 11:45:50 -0600
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <5807BC3C-E467-49C1-AE3F-7695B6B0CB86@gmail.com>
References: <4F3EBCBD.2030802@lcwb.coop>	<alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>
	<20120218053713.890011A205B@async.async.caltech.edu>
	<4F4405A5.50706@lcwb.coop>
	<5807BC3C-E467-49C1-AE3F-7695B6B0CB86@gmail.com>
Message-ID: <4F4529CE.8050504@lcwb.coop>

Yes.

2.4.7: A complete revelation has the form:

REVEAL T = V

where V is a type expression (not just a name) ...

Whether this could be relaxed without introducing semantic problems would take
careful thought, but I have been aware of how using what is popularly misnamed
"name equivalence" for opaque types is needed instead of Modula-3's usual
structural equivalence for other types.

On 02/21/2012 07:44 PM, Antony Hosking wrote:
> Is that really true?  I would have thought that so long as the type name can be resolved to a concrete type then it would work.
>
> On Feb 21, 2012, at 3:59 PM, Rodney M. Bates wrote:
>
>> But a revelation must be a type constructor, not just a type name.
>
>


From dabenavidesd at yahoo.es  Fri Feb 24 18:27:53 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 24 Feb 2012 17:27:53 +0000 (GMT)
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <4F4529CE.8050504@lcwb.coop>
Message-ID: <1330104473.68021.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I would recall your attention on (just read the abstract if you may please modular soundness, that is to say 'safe' data abstraction and information hiding):
http://dl.acm.org/citation.cfm?id=570886.570888

What you can awkward features, I would call 'inherent' parametric polymorphism undecidability which is not at all a bad thing (remember ESC targets undecidable RT errors in all program universe), but in any case we can proof some properties because of that all program space you can still find errors if still are there (symbolic simulation is part of that technique I believe).

Thanks in advance



--- El mi?, 22/2/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] An awkward interaction of language properties
> Para: "Antony Hosking" <antony.hosking at gmail.com>
> CC: m3devel at elegosoft.com
> Fecha: mi?rcoles, 22 de febrero, 2012 12:45
> Yes.
> 
> 2.4.7: A complete revelation has the form:
> 
> REVEAL T = V
> 
> where V is a type expression (not just a name) ...
> 
> Whether this could be relaxed without introducing semantic
> problems would take
> careful thought, but I have been aware of how using what is
> popularly misnamed
> "name equivalence" for opaque types is needed instead of
> Modula-3's usual
> structural equivalence for other types.
> 
> On 02/21/2012 07:44 PM, Antony Hosking wrote:
> > Is that really true?  I would have thought that so
> long as the type name can be resolved to a concrete type
> then it would work.
> >
> > On Feb 21, 2012, at 3:59 PM, Rodney M. Bates wrote:
> >
> >> But a revelation must be a type constructor, not
> just a type name.
> >
> >
> 


From dragisha at m3w.org  Fri Feb 24 21:27:13 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 24 Feb 2012 21:27:13 +0100
Subject: [M3devel] atomic operations in cm3
Message-ID: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>

I cannot find any hint on how to make use of <subject>. What would I like is to communicate with worker threads without LOCK? Possible?

TIA,
dd



From dabenavidesd at yahoo.es  Fri Feb 24 22:36:42 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 24 Feb 2012 21:36:42 +0000 (GMT)
Subject: [M3devel] atomic operations in cm3
In-Reply-To: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>
Message-ID: <1330119402.19915.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
Threads are not common class citizens but its users are, so we can't use normal constructs, perhaps await statements or tell/ask method to that thread may be useful like in ModSim/ModLog (p. 108) or Modula-3 respectively:

http://www.cs.rug.nl/~wim/pub/whh217.ps.gz

https://docs.google.com/open?id=1Y3JFsvlPFp0n17xWyH-HnywN1t6C3SAC-aFGdghakbS_Q8iWPszqtdFwM49H

or what is the same in:
http://www.erg.abdn.ac.uk/~former/harini/refman2.eps
 
Thanks in advance

--- El vieHi/2/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: [M3devel] atomic operations in cm3
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 24 de febrero, 2012 15:27
> I cannot find any hint on how to make
> use of <subject>. What would I like is to communicate
> with worker threads without LOCK? Possible?
> 
> TIA,
> dd
> 
> 


From jay.krell at cornell.edu  Sat Feb 25 03:24:14 2012
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 25 Feb 2012 02:24:14 +0000
Subject: [M3devel] atomic operations in cm3
In-Reply-To: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>
Message-ID: <COL101-W523161ADAA60673252C914E66B0@phx.gbl>


I checked in a test case. Can you look at it?Yes it is possible.  I forget the details, but some operations do require locks on some targets.There is an interface to determine if the target supports lock-free operation.  As long as you are only dealing in INTEGER or REFANY, I think you are ok across the board.  Some 32bit targets don't support 64bit atomtic, like Powerpc.SPARC32 and x86 have supported 64bit atomic operations for a long time.    Linux and Solaris kernels don't run on 32bit SPARC any longer, so 64bit instructions are available in 32bit usermode.HPPA is problematic for all atomics I recall. The instruction set support is very limited.Linux has good support somehow, something dependent on the kernel, but I don't know what gcc/HP-UX/OpenBSD/NetBSD story is.  Look in m3-libs/m3core/src/atomic/m3makefile for a record of what I found.  And ask Bing.   - Jay
 > From: dragisha at m3w.org
> Date: Fri, 24 Feb 2012 21:27:13 +0100
> To: m3devel at elegosoft.com
> Subject: [M3devel] atomic operations in cm3
> 
> I cannot find any hint on how to make use of <subject>. What would I like is to communicate with worker threads without LOCK? Possible?
> 
> TIA,
> dd
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120225/d6bf49af/attachment.html>

From jay.krell at cornell.edu  Mon Feb 27 01:37:56 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 27 Feb 2012 00:37:56 +0000
Subject: [M3devel] atomic operations in cm3
In-Reply-To: <COL101-W523161ADAA60673252C914E66B0@phx.gbl>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
Message-ID: <COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>


  > Look in m3-libs/m3core/src/atomic/m3makefile for a record of what I found.
 http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/atomic/m3makefile?rev=1.14;content-type=text%2Fplain confusing, but goodness:
 Almost anything anyone would want is supported. 
 Except for ARMEL_LINUX: 
All targets support atomic INTEGER and REFANY. 
All LINUX targets support atomic for all types (8/16/32/64). 
All I386 targets support atomic for all types (8/16/32/64).
  This includes NT386 and probably I386_NT/I386_CYGWIN/I386_INTERIX. 
All 64bit targets support atomic for LONGINT (64).
 The missing stuff is generally in unfinished or unused targets.
PPC_DARWIN missing atomic LONGINT is the most glaring omission.
SPARc32_LINUX is next -- it should work as well as SPARc32_SOLARIS/SOLsun/SOLnu.  
Where not supported, there is pattern where you fallback to using a LOCK.I'd venture a guess that PA{32,64}_{HPUX,LINUX} also don't have good atomic support. 


 > I checked in a test case. Can you look at it?  http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile?rev=1.105;content-type=text%2Fplain  => look for "atomic"  => http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/p2/p226/Main.m3?rev=1.10;content-type=text%2Fplain Shows how to use it all. It is disabled. Let's try it.. 
 - JayFrom: jay.krell at cornell.edu
To: dragisha at m3w.org; m3devel at elegosoft.com
Subject: RE: [M3devel] atomic operations in cm3
Date: Sat, 25 Feb 2012 02:24:14 +0000







I checked in a test case. Can you look at it?
Yes it is possible.
 
 
I forget the details, but some operations do require locks on some targets.
There is an interface to determine if the target supports lock-free operation.
 
 
As long as you are only dealing in INTEGER or REFANY, I think you are ok across the board.
 
 
Some 32bit targets don't support 64bit atomtic, like Powerpc.
SPARC32 and x86 have supported 64bit atomic operations for a long time.
    Linux and Solaris kernels don't run on 32bit SPARC any longer, so 64bit instructions are available in 32bit usermode.
HPPA is problematic for all atomics I recall. The instruction set support is very limited.
Linux has good support somehow, something dependent on the kernel, but I don't know what gcc/HP-UX/OpenBSD/NetBSD story is.
 
 
Look in m3-libs/m3core/src/atomic/m3makefile for a record of what I found.
 
 
And ask Bing.
 
 
 - Jay
 
> From: dragisha at m3w.org
> Date: Fri, 24 Feb 2012 21:27:13 +0100
> To: m3devel at elegosoft.com
> Subject: [M3devel] atomic operations in cm3
> 
> I cannot find any hint on how to make use of <subject>. What would I like is to communicate with worker threads without LOCK? Possible?
> 
> TIA,
> dd
> 
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120227/a0cba8a9/attachment.html>

From dragisha at m3w.org  Mon Feb 27 08:15:00 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 27 Feb 2012 08:15:00 +0100
Subject: [M3devel] atomic operations in cm3
In-Reply-To: <COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
	<COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
Message-ID: <2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>

m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.


On Feb 27, 2012, at 1:37 AM, Jay K wrote:

> Shows how to use it all.
>  
> It is disabled. Let's try it..

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

From dragisha at m3w.org  Tue Feb 28 14:15:16 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 28 Feb 2012 14:15:16 +0100
Subject: [M3devel] atomic operations in cm3 (fails on AMD64_DARWIN)
In-Reply-To: <2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
	<COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
	<2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>
Message-ID: <87DB10DC-D7D1-4C7E-BF67-9D5B2D19CC56@m3w.org>

% cm3
--- building in ../AMD64_DARWIN ---

new source -> compiling Proxy.m3
"../src/Proxy.m3", line 13: warning: not used (JobHandler)
1 warning encountered
new source -> compiling AtomicAddress.i3
new source -> compiling AtomicAddress.m3
"../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack:  expected [ Int64    ] got [ Addr  Int64   ]


***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3
***

zsh: abort      cm3

On Feb 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:

> m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.
> 
> 
> On Feb 27, 2012, at 1:37 AM, Jay K wrote:
> 
>> Shows how to use it all.
>>  
>> It is disabled. Let's try it..
> 

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

From dragisha at m3w.org  Tue Feb 28 15:08:17 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 28 Feb 2012 15:08:17 +0100
Subject: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
In-Reply-To: <9C0959B3-53C1-4147-A1E3-CC08EF0F4FAF@gmail.com>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
	<COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
	<2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>
	<87DB10DC-D7D1-4C7E-BF67-9D5B2D19CC56@m3w.org>
	<9C0959B3-53C1-4147-A1E3-CC08EF0F4FAF@gmail.com>
Message-ID: <98191695-F733-46F5-B51C-B4F6FAC710B6@m3w.org>

% cm3
--- building in ../AMD64_LINUX ---

new source -> compiling AtomicAddress.m3
"../AMD64_LINUX/AtomicAddress.m3", line 3:  18 code generation errors
1 error encountered
new exporters -> recompiling AtomicAddress.i3
compilation failed => not building program "test"
Fatal Error: package build failed

% cat m3makefile 
import("libm3")

...

Generic_module("Atomic")
template("atomic")
Atomic("Address")

program ("test")

On Feb 28, 2012, at 2:25 PM, Antony Hosking wrote:

> Yes, this is a known bug.
> 
> On Feb 28, 2012, at 8:15 AM, Dragi?a Duri? wrote:
> 
>> % cm3
>> --- building in ../AMD64_DARWIN ---
>> 
>> new source -> compiling Proxy.m3
>> "../src/Proxy.m3", line 13: warning: not used (JobHandler)
>> 1 warning encountered
>> new source -> compiling AtomicAddress.i3
>> new source -> compiling AtomicAddress.m3
>> "../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack:  expected [ Int64    ] got [ Addr  Int64   ]
>> 
>> 
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3
>> ***
>> 
>> zsh: abort      cm3
>> 
>> On Feb 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:
>> 
>>> m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.
>>> 
>>> 
>>> On Feb 27, 2012, at 1:37 AM, Jay K wrote:
>>> 
>>>> Shows how to use it all.
>>>>  
>>>> It is disabled. Let's try it..
>>> 
>> 
> 

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

From dragisha at m3w.org  Tue Feb 28 15:23:32 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 28 Feb 2012 15:23:32 +0100
Subject: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
In-Reply-To: <5272CAF6-2F21-4516-83F6-3ABFFFB2145E@gmail.com>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
	<COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
	<2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>
	<87DB10DC-D7D1-4C7E-BF67-9D5B2D19CC56@m3w.org>
	<9C0959B3-53C1-4147-A1E3-CC08EF0F4FAF@gmail.com>
	<98191695-F733-46F5-B51C-B4F6FAC710B6@m3w.org>
	<5272CAF6-2F21-4516-83F6-3ABFFFB2145E@gmail.com>
Message-ID: <4F234746-BBC5-4F23-A9FC-C39EC2D78284@m3w.org>

LINUXLIBC6 does not have Address.i3, at least my version does not.

But, Atomic("Refany") passess at LINUXLIBC6. But, call to AtomicRefany.IsLockFree() fails - looks like infinite recursion happens inside.

On Feb 28, 2012, at 3:13 PM, Antony Hosking wrote:

> Same error as before.  We need more compile-time type information to be maintained to make sure that we are operating on addresses not integers.
> 
> On Feb 28, 2012, at 9:08 AM, Dragi?a Duri? wrote:
> 
>> % cm3
>> --- building in ../AMD64_LINUX ---
>> 
>> new source -> compiling AtomicAddress.m3
>> "../AMD64_LINUX/AtomicAddress.m3", line 3:  18 code generation errors
>> 1 error encountered
>> new exporters -> recompiling AtomicAddress.i3
>> compilation failed => not building program "test"
>> Fatal Error: package build failed
>> 
>> % cat m3makefile 
>> import("libm3")
>> 
>> ...
>> 
>> Generic_module("Atomic")
>> template("atomic")
>> Atomic("Address")
>> 
>> program ("test")
>> 
>> On Feb 28, 2012, at 2:25 PM, Antony Hosking wrote:
>> 
>>> Yes, this is a known bug.
>>> 
>>> On Feb 28, 2012, at 8:15 AM, Dragi?a Duri? wrote:
>>> 
>>>> % cm3
>>>> --- building in ../AMD64_DARWIN ---
>>>> 
>>>> new source -> compiling Proxy.m3
>>>> "../src/Proxy.m3", line 13: warning: not used (JobHandler)
>>>> 1 warning encountered
>>>> new source -> compiling AtomicAddress.i3
>>>> new source -> compiling AtomicAddress.m3
>>>> "../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack:  expected [ Int64    ] got [ Addr  Int64   ]
>>>> 
>>>> 
>>>> ***
>>>> *** runtime error:
>>>> ***    Segmentation violation - possible attempt to dereference NIL
>>>> ***    pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3
>>>> ***
>>>> 
>>>> zsh: abort      cm3
>>>> 
>>>> On Feb 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:
>>>> 
>>>>> m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.
>>>>> 
>>>>> 
>>>>> On Feb 27, 2012, at 1:37 AM, Jay K wrote:
>>>>> 
>>>>>> Shows how to use it all.
>>>>>>  
>>>>>> It is disabled. Let's try it..
>>>>> 
>>>> 
>>> 
>> 
> 

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

From dabenavidesd at yahoo.es  Tue Feb 28 19:09:01 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 28 Feb 2012 18:09:01 +0000 (GMT)
Subject: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
In-Reply-To: <98191695-F733-46F5-B51C-B4F6FAC710B6@m3w.org>
Message-ID: <1330452541.3684.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I don't understand it, what is breaking, the compiler front end, the backend or both or what else? Besides platform feature instability, means that you are doing UNSAFE MODULEs? Question, is your machine SMP? I have one 32 and 64 UP LINUXLIBC6 capable, does it matter if is in one or in the other?
Thanks in advance

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
Para: "Antony Hosking" <antony.hosking at gmail.com>
CC: "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: martes, 28 de febrero, 2012 09:08

% cm3--- building in ../AMD64_LINUX ---
new source -> compiling AtomicAddress.m3"../AMD64_LINUX/AtomicAddress.m3", line 3: ?18 code generation errors1 error encounterednew exporters -> recompiling AtomicAddress.i3compilation failed => not building program "test"Fatal Error: package build failed
% cat m3makefile?import("libm3")
...
Generic_module("Atomic")template("atomic")Atomic("Address")
program ("test")
On Feb 28, 2012, at 2:25 PM, Antony Hosking wrote:
Yes, this is a known bug.
On Feb 28, 2012, at 8:15 AM, Dragi?a Duri? wrote:
% cm3--- building in ../AMD64_DARWIN ---
new source -> compiling Proxy.m3"../src/Proxy.m3", line 13: warning: not used (JobHandler)1 warning encounterednew source -> compiling AtomicAddress.i3new source -> compiling AtomicAddress.m3"../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack: ?expected [ Int64 ? ?] got [ Addr ?Int64 ? ]

****** runtime error:*** ? ?Segmentation violation - possible attempt to dereference NIL*** ? ?pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3***
zsh: abort ? ? ?cm3
On Feb 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:
m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.

On Feb 27, 2012, at 1:37 AM, Jay K wrote:
Shows how to use it all.
?
It is disabled. Let's try it..



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

From dabenavidesd at yahoo.es  Tue Feb 28 22:53:33 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 28 Feb 2012 21:53:33 +0000 (GMT)
Subject: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
In-Reply-To: <8D6408D2-7FDF-47B4-96D3-39A921ED419F@gmail.com>
Message-ID: <1330466013.93631.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
Thanks for the message and now I caught it, I have found a thesis on the <* FIELDS *> specification feature, perhaps would be a nice idea to use it to verify the trees in both Olivetti and CM3 front end, and to convert back and forth (for instance when select ESC-ing a program so just doing it once and for all is faster).

And thinking it more, I guess similarly this could be the way to watch the back end to reconstruct/infer the types same from the gcc assembly (and the CLEF tree) and compare and match if they truly match to prove it's correct.

Thanks in advance

--- El mar, 28/2/12, Antony Hosking <antony.hosking at gmail.com> escribi?:

De: Antony Hosking <antony.hosking at gmail.com>
Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: martes, 28 de febrero, 2012 15:46

It is the front end outputting badly typed IR.
On Feb 28, 2012, at 1:09 PM, Daniel Alejandro Benavides D. wrote:
Hi all:
I don't understand it, what is breaking, the compiler front end, the backend or both or what else? Besides platform feature instability, means that you are doing UNSAFE MODULEs? Question, is your machine SMP? I have one 32 and 64 UP LINUXLIBC6 capable, does it matter if is in one or in the other?
Thanks in advance

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
Para: "Antony Hosking" <antony.hosking at gmail.com>
CC: "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: martes, 28 de febrero, 2012 09:08

% cm3--- building in ../AMD64_LINUX ---
new source -> compiling AtomicAddress.m3"../AMD64_LINUX/AtomicAddress.m3", line 3: ?18 code generation errors1 error encounterednew exporters -> recompiling AtomicAddress.i3compilation failed => not building program "test"Fatal Error: package build failed
% cat m3makefile?import("libm3")
...
Generic_module("Atomic")template("atomic")Atomic("Address")
program ("test")
On Feb 28, 2012, at 2:25 PM, Antony Hosking wrote:
Yes, this is a known bug.
On Feb 28, 2012, at 8:15 AM, Dragi?a Duri? wrote:
% cm3--- building in ../AMD64_DARWIN ---
new source -> compiling Proxy.m3"../src/Proxy.m3", line 13: warning: not used (JobHandler)1 warning encounterednew source -> compiling AtomicAddress.i3new source -> compiling AtomicAddress.m3"../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack: ?expected [ Int64 ? ?] got [ Addr ?Int64 ? ]

****** runtime error:*** ? ?Segmentation violation - possible attempt to dereference NIL*** ? ?pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3***
zsh: abort ? ? ?cm3
On Feb
 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:
m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.

On Feb 27, 2012, at 1:37 AM, Jay K wrote:
Shows how to use it all.
?
It is disabled. Let's try
 it..




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

From dknoto at next.com.pl  Thu Feb  2 21:04:45 2012
From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?B?S25vY2nxc2tp?=)
Date: Thu, 2 Feb 2012 21:04:45 +0100
Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling
 problem
In-Reply-To: <COL101-W2279CBB33BFAF0CEE87DC1E6720@phx.gbl>
References: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com>
	<COL101-W2279CBB33BFAF0CEE87DC1E6720@phx.gbl>
Message-ID: <20120202210445.6c03d7d9@wenus.next.com.pl>

Dnia 2012-01-31, o godz. 02:21:56
Jay K <jay.krell at cornell.edu> napisa?(a):

> 
>   > $ tar -zxf /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > *** cannot
>   > find package import-libs / m3-win/import-libs
> You don't have the full source tree.Among m3-sys, m3-tools, m3-ui, etc., you
> are missing m3-win.If there is an "all" archive, try it?

I tried compiling from full sources. I have not achieved success. After
compiling backend process dumps lot of errors like this:

ranlib  libbackend.a
g++  -g  -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wc++-compat -fno-common  -DHAVE_CONFIG_H  -o m3cgc1 m3cg/parse.o attribs.o
main.o tree-browser.o
libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a ../libiberty/libiberty.a
-rdynamic -ldl --- shipping from AMD64_LINUX ---

. => /usr/local/cm3/bin
  cm3cg           
 ==> /home/dknoto/Projekty/CM3-5.9.0-devel/m3-sys/m3cc done

=== package /home/dknoto/Projekty/CM3-5.9.0-devel/m3-libs/m3core ===
 +++ cm3 -build -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' $RARGS  && cm3
-ship $RARGS -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel'  +++ --- building
in AMD64_LINUX ---

ignoring ../src/m3overrides

new source -> compiling RTHooks.i3
m3cgc1: fatal error:  *** illegal type: 0x17, at m3cg_lineno 4
compilation terminated.
  m3_backend => 1
m3cc (aka cm3cg) failed compiling: RTHooks.ic
new source -> compiling RT0.i3
m3cgc1: fatal error:  *** illegal type: 0x17, at m3cg_lineno 4
compilation terminated.
...

Best regards
Dariusz. 


From dabenavidesd at yahoo.es  Thu Feb  2 22:47:13 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 2 Feb 2012 21:47:13 +0000 (GMT)
Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling
	problem
In-Reply-To: <20120202210445.6c03d7d9@wenus.next.com.pl>
Message-ID: <1328219233.94197.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
Well, Jay I pass that one onto you, because we still miss back end testing, but nevertheless this is better than before. 
Anyway, I guess we can make some proofs at least statically with compile time asserts, just to make an idea, but needs investigation (Jay do you have some idea? I might try myself).
Thanks in advance 

--- El jue, 2/2/12, Dariusz Knoci?ski <dknoto at next.com.pl> escribi?:

> De: Dariusz Knoci?ski <dknoto at next.com.pl>
> Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem
> Para: m3devel at elegosoft.com
> Fecha: jueves, 2 de febrero, 2012 15:04
> Dnia 2012-01-31, o godz. 02:21:56
> Jay K <jay.krell at cornell.edu>
> napisa?(a):
> 
> > 
> >   > $ tar -zxf
> /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > ***
> cannot
> >   > find package import-libs /
> m3-win/import-libs
> > You don't have the full source tree.Among m3-sys,
> m3-tools, m3-ui, etc., you
> > are missing m3-win.If there is an "all" archive, try
> it?
> 
> I tried compiling from full sources. I have not achieved
> success. After
> compiling backend process dumps lot of errors like this:
> 
> ranlib  libbackend.a
> g++  -g  -DIN_GCC   -W -Wall
> -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wmissing-format-attribute -pedantic
> -Wno-long-long
> -Wno-variadic-macros -Wno-overlength-strings
> -Wold-style-definition
> -Wc++-compat -fno-common  -DHAVE_CONFIG_H  -o
> m3cgc1 m3cg/parse.o attribs.o
> main.o tree-browser.o
> libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a
> ../libiberty/libiberty.a
> -rdynamic -ldl --- shipping from AMD64_LINUX ---
> 
> . => /usr/local/cm3/bin
>   cm3cg           
>  ==> /home/dknoto/Projekty/CM3-5.9.0-devel/m3-sys/m3cc
> done
> 
> === package
> /home/dknoto/Projekty/CM3-5.9.0-devel/m3-libs/m3core ===
>  +++ cm3 -build
> -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' $RARGS 
> && cm3
> -ship $RARGS
> -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel'  +++ ---
> building
> in AMD64_LINUX ---
> 
> ignoring ../src/m3overrides
> 
> new source -> compiling RTHooks.i3
> m3cgc1: fatal error:  *** illegal type: 0x17, at
> m3cg_lineno 4
> compilation terminated.
>   m3_backend => 1
> m3cc (aka cm3cg) failed compiling: RTHooks.ic
> new source -> compiling RT0.i3
> m3cgc1: fatal error:  *** illegal type: 0x17, at
> m3cg_lineno 4
> compilation terminated.
> ...
> 
> Best regards
> Dariusz. 
> 


From dabenavidesd at yahoo.es  Thu Feb  2 23:12:57 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 2 Feb 2012 22:12:57 +0000 (GMT)
Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling
	problem
In-Reply-To: <1328219233.94197.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <1328220777.53225.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I read somewhere m3cg or m3cc or "m3gcc" is just an automata. If I knew the class I would be able to print out its current state at compile time which will provide enough source for any compiler hacker to correct it, right?
Now, I need a tool to check what compilation is right or not to automate that process.
I will need to look for alternatives for doing that.
Thanks in advance

--- El jue, 2/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem
> Para: m3devel at elegosoft.com, "Dariusz Knoci?ski" <dknoto at next.com.pl>
> Fecha: jueves, 2 de febrero, 2012 16:47
> Hi all:
> Well, Jay I pass that one onto you, because we still miss
> back end testing, but nevertheless this is better than
> before. 
> Anyway, I guess we can make some proofs at least statically
> with compile time asserts, just to make an idea, but needs
> investigation (Jay do you have some idea? I might try
> myself).
> Thanks in advance 
> 
> --- El jue, 2/2/12, Dariusz Knoci?ski <dknoto at next.com.pl>
> escribi?:
> 
> > De: Dariusz Knoci?ski <dknoto at next.com.pl>
> > Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0
> 2011-11-19-02-40-49 compilling problem
> > Para: m3devel at elegosoft.com
> > Fecha: jueves, 2 de febrero, 2012 15:04
> > Dnia 2012-01-31, o godz. 02:21:56
> > Jay K <jay.krell at cornell.edu>
> > napisa?(a):
> > 
> > > 
> > >   > $ tar -zxf
> > /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > ***
> > cannot
> > >   > find package import-libs /
> > m3-win/import-libs
> > > You don't have the full source tree.Among m3-sys,
> > m3-tools, m3-ui, etc., you
> > > are missing m3-win.If there is an "all" archive,
> try
> > it?
> > 
> > I tried compiling from full sources. I have not
> achieved
> > success. After
> > compiling backend process dumps lot of errors like
> this:
> > 
> > ranlib  libbackend.a
> > g++  -g  -DIN_GCC   -W -Wall
> > -Wwrite-strings -Wstrict-prototypes
> > -Wmissing-prototypes -Wmissing-format-attribute
> -pedantic
> > -Wno-long-long
> > -Wno-variadic-macros -Wno-overlength-strings
> > -Wold-style-definition
> > -Wc++-compat -fno-common  -DHAVE_CONFIG_H 
> -o
> > m3cgc1 m3cg/parse.o attribs.o
> > main.o tree-browser.o
> > libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a
> > ../libiberty/libiberty.a
> > -rdynamic -ldl --- shipping from AMD64_LINUX ---
> > 
> > . => /usr/local/cm3/bin
> >   cm3cg       
>    
> >  ==>
> /home/dknoto/Projekty/CM3-5.9.0-devel/m3-sys/m3cc
> > done
> > 
> > === package
> > /home/dknoto/Projekty/CM3-5.9.0-devel/m3-libs/m3core
> ===
> >  +++ cm3 -build
> > -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' $RARGS 
> > && cm3
> > -ship $RARGS
> > -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' 
> +++ ---
> > building
> > in AMD64_LINUX ---
> > 
> > ignoring ../src/m3overrides
> > 
> > new source -> compiling RTHooks.i3
> > m3cgc1: fatal error:  *** illegal type: 0x17, at
> > m3cg_lineno 4
> > compilation terminated.
> >   m3_backend => 1
> > m3cc (aka cm3cg) failed compiling: RTHooks.ic
> > new source -> compiling RT0.i3
> > m3cgc1: fatal error:  *** illegal type: 0x17, at
> > m3cg_lineno 4
> > compilation terminated.
> > ...
> > 
> > Best regards
> > Dariusz. 
> >
> 


From jay.krell at cornell.edu  Fri Feb  3 17:13:55 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 3 Feb 2012 16:13:55 +0000
Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling
 problem
In-Reply-To: <1328220777.53225.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <1328219233.94197.YahooMailClassic@web29702.mail.ird.yahoo.com>,
	<1328220777.53225.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W582443CDE1FFAE46B12899E6710@phx.gbl>


Daniel, no.

Darious, how about cm3 -commands -keep?
This sort of error indicates either the wrong cm3cg is being run or it is being passed the wrong file, like mixing up .ic and .io files or somesuch.
Try adding -v to the cm3cg commands.
  You'll have to cd to the target directory as well (AMD64_LINUX).


 - Jay

> Date: Thu, 2 Feb 2012 22:12:57 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; dknoto at next.com.pl
> Subject: Re: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling	problem
> 
> Hi all:
> I read somewhere m3cg or m3cc or "m3gcc" is just an automata. If I knew the class I would be able to print out its current state at compile time which will provide enough source for any compiler hacker to correct it, right?
> Now, I need a tool to check what compilation is right or not to automate that process.
> I will need to look for alternatives for doing that.
> Thanks in advance
> 
> --- El jue, 2/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:
> 
> > De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> > Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem
> > Para: m3devel at elegosoft.com, "Dariusz Knoci?ski" <dknoto at next.com.pl>
> > Fecha: jueves, 2 de febrero, 2012 16:47
> > Hi all:
> > Well, Jay I pass that one onto you, because we still miss
> > back end testing, but nevertheless this is better than
> > before. 
> > Anyway, I guess we can make some proofs at least statically
> > with compile time asserts, just to make an idea, but needs
> > investigation (Jay do you have some idea? I might try
> > myself).
> > Thanks in advance 
> > 
> > --- El jue, 2/2/12, Dariusz Knoci?ski <dknoto at next.com.pl>
> > escribi?:
> > 
> > > De: Dariusz Knoci?ski <dknoto at next.com.pl>
> > > Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0
> > 2011-11-19-02-40-49 compilling problem
> > > Para: m3devel at elegosoft.com
> > > Fecha: jueves, 2 de febrero, 2012 15:04
> > > Dnia 2012-01-31, o godz. 02:21:56
> > > Jay K <jay.krell at cornell.edu>
> > > napisa?(a):
> > > 
> > > > 
> > > >   > $ tar -zxf
> > > /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > ***
> > > cannot
> > > >   > find package import-libs /
> > > m3-win/import-libs
> > > > You don't have the full source tree.Among m3-sys,
> > > m3-tools, m3-ui, etc., you
> > > > are missing m3-win.If there is an "all" archive,
> > try
> > > it?
> > > 
> > > I tried compiling from full sources. I have not
> > achieved
> > > success. After
> > > compiling backend process dumps lot of errors like
> > this:
> > > 
> > > ranlib  libbackend.a
> > > g++  -g  -DIN_GCC   -W -Wall
> > > -Wwrite-strings -Wstrict-prototypes
> > > -Wmissing-prototypes -Wmissing-format-attribute
> > -pedantic
> > > -Wno-long-long
> > > -Wno-variadic-macros -Wno-overlength-strings
> > > -Wold-style-definition
> > > -Wc++-compat -fno-common  -DHAVE_CONFIG_H 
> > -o
> > > m3cgc1 m3cg/parse.o attribs.o
> > > main.o tree-browser.o
> > > libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a
> > > ../libiberty/libiberty.a
> > > -rdynamic -ldl --- shipping from AMD64_LINUX ---
> > > 
> > > . => /usr/local/cm3/bin
> > >   cm3cg       
> >    
> > >  ==>
> > /home/dknoto/Projekty/CM3-5.9.0-devel/m3-sys/m3cc
> > > done
> > > 
> > > === package
> > > /home/dknoto/Projekty/CM3-5.9.0-devel/m3-libs/m3core
> > ===
> > >  +++ cm3 -build
> > > -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' $RARGS 
> > > && cm3
> > > -ship $RARGS
> > > -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' 
> > +++ ---
> > > building
> > > in AMD64_LINUX ---
> > > 
> > > ignoring ../src/m3overrides
> > > 
> > > new source -> compiling RTHooks.i3
> > > m3cgc1: fatal error:  *** illegal type: 0x17, at
> > > m3cg_lineno 4
> > > compilation terminated.
> > >   m3_backend => 1
> > > m3cc (aka cm3cg) failed compiling: RTHooks.ic
> > > new source -> compiling RT0.i3
> > > m3cgc1: fatal error:  *** illegal type: 0x17, at
> > > m3cg_lineno 4
> > > compilation terminated.
> > > ...
> > > 
> > > Best regards
> > > Dariusz. 
> > >
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120203/3e757b50/attachment-0001.html>

From dragisha at m3w.org  Mon Feb  6 09:50:51 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 6 Feb 2012 09:50:51 +0100
Subject: [M3devel] open array parameter passing, to external C procedure
Message-ID: <C39EBA6D-0A62-44C5-ABA1-123EB7998453@m3w.org>

I have this case:

extern int epoll_wait (int __epfd, struct epoll_event *__events,
                       int __maxevents, int __timeout);

And I would like to do it like:

<*EXTERNAL*> 
PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF epoll_event; timeout: int := -1): int;

?
VAR
  events: ARRAY [0..MaxEvents-1] OF epoll_event;

?

WITH res = epoll_wait(epfd, events, 2) DO
  ?
END;

Can I expect cm3 to do "right thing". Or I have to place parameters "by hand" using ADR and SIZE?

TIA,
dd



From mika at async.caltech.edu  Mon Feb  6 14:40:29 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Mon, 06 Feb 2012 05:40:29 -0800
Subject: [M3devel] open array parameter passing, to external C procedure
In-Reply-To: <C39EBA6D-0A62-44C5-ABA1-123EB7998453@m3w.org> 
References: <C39EBA6D-0A62-44C5-ABA1-123EB7998453@m3w.org>
Message-ID: <20120206134029.949A01A205B@async.async.caltech.edu>


I don't think it's going to work.  The Modula-3 compiler usually inserts
metadata at ADR(x) where x is an array of any type.

I know using ADDRESS works for the declaration, and then ADR(events[0]) 
for passing.  No need for SIZE, though.

If you like the type checking (we do, right?) you can of course
encapsulate it in a layer of UNSAFE Modula-3 with a safe interface.

    Mika

=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
>I have this case:
>
>extern int epoll_wait (int __epfd, struct epoll_event *__events,
>                       int __maxevents, int __timeout);
>
>And I would like to do it like:
>
><*EXTERNAL*>=20
>PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF epoll_event; =
>timeout: int :=3D -1): int;
>
>=85
>VAR
>  events: ARRAY [0..MaxEvents-1] OF epoll_event;
>
>=85
>
>WITH res =3D epoll_wait(epfd, events, 2) DO
>  =85
>END;
>
>Can I expect cm3 to do "right thing". Or I have to place parameters "by =
>hand" using ADR and SIZE?
>
>TIA,
>dd


From dabenavidesd at yahoo.es  Mon Feb  6 17:06:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 6 Feb 2012 16:06:24 +0000 (GMT)
Subject: [M3devel] open array parameter passing, to external C procedure
In-Reply-To: <C39EBA6D-0A62-44C5-ABA1-123EB7998453@m3w.org>
Message-ID: <1328544384.14121.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
given C no standard parameter by reference passing style, it should be not that easy. But how about WeakRef, where an open array of weak ref is easier to match with in Modula-3 words.
I don't know if Modula-3 has stronger types for that. Anyway, I don't know what kind of such struct is that either.
Thanks in advance

--- El lun, 6/2/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: [M3devel] open array parameter passing, to external C procedure
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 6 de febrero, 2012 03:50
> I have this case:
> 
> extern int epoll_wait (int __epfd, struct epoll_event
> *__events,
>                
>        int __maxevents, int
> __timeout);
> 
> And I would like to do it like:
> 
> <*EXTERNAL*> 
> PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF
> epoll_event; timeout: int := -1): int;
> 
> ?
> VAR
>   events: ARRAY [0..MaxEvents-1] OF epoll_event;
> 
> ?
> 
> WITH res = epoll_wait(epfd, events, 2) DO
>   ?
> END;
> 
> Can I expect cm3 to do "right thing". Or I have to place
> parameters "by hand" using ADR and SIZE?
> 
> TIA,
> dd
> 
> 


From rodney_bates at lcwb.coop  Mon Feb  6 17:43:11 2012
From: rodney_bates at lcwb.coop (Rodney Bates)
Date: Mon, 6 Feb 2012 08:43:11 -0800
Subject: [M3devel] open array parameter passing, to external C procedure
Message-ID: <20120206084311.D4AF2D80@m0005310.ppops.net>

All the compilers pass open arrays as a pointer to metadata.
The metadata consists of a pointer to actual element zero, followed
by a "shape", which is an array of element counts in each open dimension.
The number of open dimensions is a static property of the type, so
it is not passed, but hard-coded where needed. 

The actual elements can be anywhere, and indeed must be somewhere
else in the case of a SUBARRAY.   

I suppose they could have made this into separate parameters for
address of element zero and for each shape component, but I'm not 
sure right off hand how that would interact with heap-allocated open
arrays and subarrays of either heap-allocated or local variables.  
I've been ambivalent about this representation, but it can be used
consistently everywhere.  For a heap-allocated open array, the
metadata is immediately followed by the elements.  

So, no, it won't work the way you hope.  For your example, you 
would pass ADR(events[0]) and NUMBER(events) as separate parameters. 
(ADR(events) would pass the address of the metadata.)    

Of course, usually, the array you will have is not necessarily entirely 
full.  If that were the case, to do it in the Modula-3 way you had hoped, 
you would have had to pass SUBARRAY(events,0,event_count).  As it is,
the actuals in this case would be ADR(events[0]) and event_count.   

-Rodney Bates

--- dragisha at m3w.org wrote:

From: Dragi?a Duri? <dragisha at m3w.org>
To: m3devel <m3devel at elegosoft.com>
Subject: [M3devel] open array parameter passing, to external C procedure
Date: Mon, 6 Feb 2012 09:50:51 +0100

I have this case:

extern int epoll_wait (int __epfd, struct epoll_event *__events,
                       int __maxevents, int __timeout);

And I would like to do it like:

<*EXTERNAL*> 
PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF epoll_event; timeout: int := -1): int;

?
VAR
  events: ARRAY [0..MaxEvents-1] OF epoll_event;

?

WITH res = epoll_wait(epfd, events, 2) DO
  ?
END;

Can I expect cm3 to do "right thing". Or I have to place parameters "by hand" using ADR and SIZE?

TIA,
dd






From dragisha at m3w.org  Tue Feb  7 13:17:28 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 7 Feb 2012 13:17:28 +0100
Subject: [M3devel] open array parameter passing, to external C procedure
In-Reply-To: <20120206084311.D4AF2D80@m0005310.ppops.net>
References: <20120206084311.D4AF2D80@m0005310.ppops.net>
Message-ID: <BEC583C6-CAC1-44B1-A3D5-DAFB94A0A270@m3w.org>

Thanks to all for replies, it (does not) work as expected. Test showed it, reasoning is ok.

In gm2, interfacing is explicitly to C, so it's how it would and will work there. No big deal to make it by hand, but anyway - it's good to be sure :).

BTW, while googling some time ago, I found "ALIGNED  n FOR" construct from SPIN compiler? Interesting way to ensure alignment, esp in light of overaligning we have in cm3 now :).

dd

On Feb 6, 2012, at 5:43 PM, Rodney Bates wrote:

> All the compilers pass open arrays as a pointer to metadata.
> The metadata consists of a pointer to actual element zero, followed
> by a "shape", which is an array of element counts in each open dimension.
> The number of open dimensions is a static property of the type, so
> it is not passed, but hard-coded where needed. 
> 
> The actual elements can be anywhere, and indeed must be somewhere
> else in the case of a SUBARRAY.   
> 
> I suppose they could have made this into separate parameters for
> address of element zero and for each shape component, but I'm not 
> sure right off hand how that would interact with heap-allocated open
> arrays and subarrays of either heap-allocated or local variables.  
> I've been ambivalent about this representation, but it can be used
> consistently everywhere.  For a heap-allocated open array, the
> metadata is immediately followed by the elements.  
> 
> So, no, it won't work the way you hope.  For your example, you 
> would pass ADR(events[0]) and NUMBER(events) as separate parameters. 
> (ADR(events) would pass the address of the metadata.)    
> 
> Of course, usually, the array you will have is not necessarily entirely 
> full.  If that were the case, to do it in the Modula-3 way you had hoped, 
> you would have had to pass SUBARRAY(events,0,event_count).  As it is,
> the actuals in this case would be ADR(events[0]) and event_count.   
> 
> -Rodney Bates
> 
> --- dragisha at m3w.org wrote:
> 
> From: Dragi?a Duri? <dragisha at m3w.org>
> To: m3devel <m3devel at elegosoft.com>
> Subject: [M3devel] open array parameter passing, to external C procedure
> Date: Mon, 6 Feb 2012 09:50:51 +0100
> 
> I have this case:
> 
> extern int epoll_wait (int __epfd, struct epoll_event *__events,
>                       int __maxevents, int __timeout);
> 
> And I would like to do it like:
> 
> <*EXTERNAL*> 
> PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF epoll_event; timeout: int := -1): int;
> 
> ?
> VAR
>  events: ARRAY [0..MaxEvents-1] OF epoll_event;
> 
> ?
> 
> WITH res = epoll_wait(epfd, events, 2) DO
>  ?
> END;
> 
> Can I expect cm3 to do "right thing". Or I have to place parameters "by hand" using ADR and SIZE?
> 
> TIA,
> dd
> 
> 
> 
> 
> 



From hendrik at topoi.pooq.com  Thu Feb  9 17:56:24 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 9 Feb 2012 11:56:24 -0500
Subject: [M3devel] Assertion failed to complain
Message-ID: <20120209165624.GA13717@topoi.pooq.com>

Presumably there's something I have to do (or make sure I don't do) to 
make assertion chacking work. 

With the following two lines in my program:


  <* assert segment.end + 1 >= segment.start *>    

  indices := NEW(REF ARRAY OF INTEGER, segment.end - segment.start + 
1);

I get a runtime error

***
*** runtime error:
***    An enumeration or subrange value was out of range.
***    file "../src/runtime/common/RTAllocator.m3", line 340
***

Running this in m3gdb, I see that line 340 is indeed the assignment to 
'indices' above, and that the assertion has sowehow failed to complain.

Printing out a few expressions in the debugger, I get

(m3gdb) up
#19 0x080498ba in sortsegment (segment=16_b6be01b8) at 
../src/Main.m3:218
218	  indices := NEW(REF ARRAY OF INTEGER, segment.end - 
segment.start + 1);
(m3gdb) print segment.end
$1 = 0
(m3gdb) print segment.start
$2 = 3
(m3gdb) print segment.end + 1 >= segment.start
$3 = FALSE
(m3gdb) print segment.end - segment.start + 1
$4 = 4294967294

Yes, the 'end' and 'start' fields are declared INTEGER.

Somehow, this slipped past the ASSERT statement.

-- hendrik



From hendrik at topoi.pooq.com  Thu Feb  9 18:52:20 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 9 Feb 2012 12:52:20 -0500
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <20120209165624.GA13717@topoi.pooq.com>
References: <20120209165624.GA13717@topoi.pooq.com>
Message-ID: <20120209175220.GB13717@topoi.pooq.com>

On Thu, Feb 09, 2012 at 11:56:24AM -0500, Hendrik Boom wrote:
> Presumably there's something I have to do (or make sure I don't do) to 
> make assertion chacking work. 
> 
> With the following two lines in my program:
> 
> 
>   <* assert segment.end + 1 >= segment.start *>    
> 
>   indices := NEW(REF ARRAY OF INTEGER, segment.end - segment.start + 
> 1);
> 
> I get a runtime error
> 
> ***
> *** runtime error:
> ***    An enumeration or subrange value was out of range.
> ***    file "../src/runtime/common/RTAllocator.m3", line 340
> ***
> 
> Running this in m3gdb, I see that line 340 is indeed the assignment to 
> 'indices' above, and that the assertion has sowehow failed to complain.
> 
> Printing out a few expressions in the debugger, I get
> 
> (m3gdb) up
> #19 0x080498ba in sortsegment (segment=16_b6be01b8) at 
> ../src/Main.m3:218
> 218	  indices := NEW(REF ARRAY OF INTEGER, segment.end - 
> segment.start + 1);
> (m3gdb) print segment.end
> $1 = 0
> (m3gdb) print segment.start
> $2 = 3
> (m3gdb) print segment.end + 1 >= segment.start
> $3 = FALSE
> (m3gdb) print segment.end - segment.start + 1
> $4 = 4294967294
> 
> Yes, the 'end' and 'start' fields are declared INTEGER.
> 
> Somehow, this slipped past the ASSERT statement.
> 

For the record, I'm running 

Critical Mass Modula-3 version 5.8.4
  last updated: 2009-11-02
  compiled: 2009-11-03 13:57:35
  configuration: /usr/local/cm3/bin/cm3.cfg
  host: LINUXLIBC6
  target: LINUXLIBC6

-- hendrik



From dabenavidesd at yahoo.es  Thu Feb  9 18:51:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 9 Feb 2012 17:51:24 +0000 (GMT)
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <20120209165624.GA13717@topoi.pooq.com>
Message-ID: <1328809884.5392.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
It might be that needs to be uppercase (in case compiler doesn't warn but I guess that would desired behavior, or not, since it would be unknown at compile time).
<*ASSERT exp*>

Thanks in advance

--- El jue, 9/2/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] Assertion failed to complain
> Para: m3devel at elegosoft.com
> Fecha: jueves, 9 de febrero, 2012 11:56
> Presumably there's something I have
> to do (or make sure I don't do) to 
> make assertion chacking work. 
> 
> With the following two lines in my program:
> 
> 
>   <* assert segment.end + 1 >= segment.start
> *>    
> 
>   indices := NEW(REF ARRAY OF INTEGER, segment.end -
> segment.start + 
> 1);
> 
> I get a runtime error
> 
> ***
> *** runtime error:
> ***    An enumeration or subrange value was out of
> range.
> ***    file
> "../src/runtime/common/RTAllocator.m3", line 340
> ***
> 
> Running this in m3gdb, I see that line 340 is indeed the
> assignment to 
> 'indices' above, and that the assertion has sowehow failed
> to complain.
> 
> Printing out a few expressions in the debugger, I get
> 
> (m3gdb) up
> #19 0x080498ba in sortsegment (segment=16_b6be01b8) at 
> ../src/Main.m3:218
> 218      indices := NEW(REF ARRAY OF
> INTEGER, segment.end - 
> segment.start + 1);
> (m3gdb) print segment.end
> $1 = 0
> (m3gdb) print segment.start
> $2 = 3
> (m3gdb) print segment.end + 1 >= segment.start
> $3 = FALSE
> (m3gdb) print segment.end - segment.start + 1
> $4 = 4294967294
> 
> Yes, the 'end' and 'start' fields are declared INTEGER.
> 
> Somehow, this slipped past the ASSERT statement.
> 
> -- hendrik
> 
> 


From hendrik at topoi.pooq.com  Thu Feb  9 18:59:08 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 9 Feb 2012 12:59:08 -0500
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <1328809884.5392.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <20120209165624.GA13717@topoi.pooq.com>
	<1328809884.5392.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <20120209175908.GC13717@topoi.pooq.com>

On Thu, Feb 09, 2012 at 05:51:24PM +0000, Daniel Alejandro Benavides D. wrote:
> Hi all:
> It might be that needs to be uppercase (in case compiler doesn't warn but I guess that would desired behavior, or not, since it would be unknown at compile time).
> <*ASSERT exp*>
> 
> Thanks in advance

That was exactly it.  One of the few places where things are 
case-sensitive, but a wrong case doesn't cause an error message.
(in fact, it suppressed it)

Things are failing properly now.

-- hendrik


From peter.mckinna at gmail.com  Fri Feb 10 06:01:00 2012
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Fri, 10 Feb 2012 16:01:00 +1100
Subject: [M3devel] Think we need a new release.
Message-ID: <CAEy6uxr=Qt6oktH60NGVByyjM9=Dtoy5OocjEOh=fC=YhbUn=Q@mail.gmail.com>

Been a long time between releases. Must be about time.

Firefox is doing 6 weekly releases we are lucky if we get one every 6
years. Sorry thats a bit harsh, all the same we need some new
commitment.

Regards Peter


From dataf4l at gmail.com  Fri Feb 10 06:22:58 2012
From: dataf4l at gmail.com (felipe valdez)
Date: Fri, 10 Feb 2012 00:22:58 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAEy6uxr=Qt6oktH60NGVByyjM9=Dtoy5OocjEOh=fC=YhbUn=Q@mail.gmail.com>
References: <CAEy6uxr=Qt6oktH60NGVByyjM9=Dtoy5OocjEOh=fC=YhbUn=Q@mail.gmail.com>
Message-ID: <CAGi-_--zaetAw_FiUK3F=twE_ba3cKDgmhUZg5B5tBO4-TQcTA@mail.gmail.com>

I'd love to help beta-testing whatever you guys throw at me.
I have linux, windows and mac (11.6) boxes for this purpose.


if testing can be automated, so much the better.

I know it is perhaps not much, but I'd like to help, and this is the only
thing I can think of.

if you guys have a more specific task, I'd like to take a crack at it, but
be indulgent, I'm just a newbie, so "making compiler not leak" type bugs
are probably not what I'll be most effective at.

I think the project could use some help, concerning the webpage (it looks
dated, a little), and also with documentatino on to how to get started
(screencast anyone?).

if more people could get behind the project, perhaps it would be easier to
make releases more often.

perhaps ideas conecrning what the selling points of M3, tha differentiate
it from other languages, would be a nice thng to be able to mention in the
videos.


I remember that Ruby on rails had some traction going on, after the creator
posted some 15 minutes videos concerning how to make a blog, and that kind
of stuff.

is it possible, to make a 15 mins video, of the main M3 features, that
would help convince more people to join the project.

is this a good idea?




On Fri, Feb 10, 2012 at 12:01 AM, Peter McKinna <peter.mckinna at gmail.com>wrote:

> Been a long time between releases. Must be about time.
>
> Firefox is doing 6 weekly releases we are lucky if we get one every 6
> years. Sorry thats a bit harsh, all the same we need some new
> commitment.
>
> Regards Peter
>



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

From dabenavidesd at yahoo.es  Fri Feb 10 14:22:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 13:22:34 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_--zaetAw_FiUK3F=twE_ba3cKDgmhUZg5B5tBO4-TQcTA@mail.gmail.com>
Message-ID: <1328880154.79634.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
Elego wanted to make a CM3IDE instance for free browsing of sources like the "Free Critical Mass Modula-3 (CM3)" since this the only excuse of a non-Modula-3 user, "I can't wait to use the compiler", or, "Do I have a platform enabled system " and we will give you a bootstrap image testable on-line, perhaps you would want to start from that. I think that anybody with modula-3 problems will appreciate that. I know of some Emulators for old platforms like Pdp-8e, Pdp-10, CDC, will anyone be keen to integrate those platforms as for have testing changes on those systems (besides showing that Modula-3 can emulate really basic and complex systems).
Personally I would love to fix the m3-obliq system and related tools to work across several platforms, you know, NetObj testing and some C-level coding inside m3cc , hopefully to make testing but will need to do some C-like clearer version, since this is hard for a non-artistic computer brain also would help to have syntax and grammar rules of M3CG whatever is available (Including M3CG- Clef - C/Assembly compiler for exploratory targets). 
I guess there  is room for more things to be done.
Thanks in advance

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

De: felipe valdez <dataf4l at gmail.com>
Asunto: Re: [M3devel] Think we need a new release.
Para: "Peter McKinna" <peter.mckinna at gmail.com>
CC: m3devel at elegosoft.com
Fecha: viernes, 10 de febrero, 2012 00:22

I'd love to help beta-testing whatever you guys throw at me.I have linux, windows and mac (11.6) boxes for this purpose.



if testing can be automated, so much the better.


I know it is perhaps not much, but I'd like to help, and this is the only thing I can think of.


if you guys have a more specific task, I'd like to take a crack at it, but be indulgent, I'm just a newbie, so "making compiler not leak" type bugs are probably not what I'll be most effective at.


I think the project could use some help, concerning the webpage (it looks dated, a little), and also with documentatino on to how to get started (screencast anyone?).


if more people could get behind the project, perhaps it would be easier to make releases more often.


perhaps ideas conecrning what the selling points of M3, tha differentiate it from other languages, would be a nice thng to be able to mention in the videos.



I remember that Ruby on rails had some traction going on, after the creator posted some 15 minutes videos concerning how to make a blog, and that kind of stuff.


is it possible, to make a 15 mins video, of the main M3 features, that would help convince more people to join the project.


is this a good idea?





On Fri, Feb 10, 2012 at 12:01 AM, Peter McKinna <peter.mckinna at gmail.com> wrote:


Been a long time between releases. Must be about time.



Firefox is doing 6 weekly releases we are lucky if we get one every 6

years. Sorry thats a bit harsh, all the same we need some new

commitment.



Regards Peter




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



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

From vintagecoder at aol.com  Fri Feb 10 15:14:35 2012
From: vintagecoder at aol.com (Vintage Coder)
Date: Fri, 10 Feb 2012 14:14:35 +0000
Subject: [M3devel] Think we need a new release.
Message-ID: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>

What is the purpose of a new release? A compiler and runtime that work presumably only need fixes. Are you talking about a major new version or a mod level or what? The last release on cm3 I see is from 2010. 

Are there bug fixes in the pipeline that haven't been verified? Are there fixes ready to go that no builds have been done for? What is the problem more frequent releases will solve? Personally I see no benefit (indeed I see many disadvantges) to frequent releases of stable software. But I often run backlevel intentionally.  

Firefox is being updated for many reasons including security holes, bug fixes, new standards, and more. If the Modula-3 standard hasn't been updated, what is driving the need for new release(s)?

It looks like cm3 supports more platforms than I have. I would be willing to help out (I am not a UNIX developer) any way I could. I have Solaris Intel and SPARC boxes. 

------Original Message------
From: Peter McKinna
To: m3devel at elegosoft.com
Subject: [M3devel] Think we need a new release.
Sent: 10 Feb 2012 05:01

Been a long time between releases. Must be about time.

Firefox is doing 6 weekly releases we are lucky if we get one every 6
years. Sorry thats a bit harsh, all the same we need some new
commitment.

Regards Peter


From rcolebur at SCIRES.COM  Fri Feb 10 15:29:52 2012
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 10 Feb 2012 09:29:52 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_--zaetAw_FiUK3F=twE_ba3cKDgmhUZg5B5tBO4-TQcTA@mail.gmail.com>
References: <CAEy6uxr=Qt6oktH60NGVByyjM9=Dtoy5OocjEOh=fC=YhbUn=Q@mail.gmail.com>
	<CAGi-_--zaetAw_FiUK3F=twE_ba3cKDgmhUZg5B5tBO4-TQcTA@mail.gmail.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6034A5AF263@atlex02-srv>

I can provide testing on Windows 2000, XP, and 7 platforms.
Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/6a833467/attachment-0001.html>

From dabenavidesd at yahoo.es  Fri Feb 10 15:31:25 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 14:31:25 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>
Message-ID: <1328884285.44537.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
I think one of the purposes of that is more cross platform compatibility, perhaps put in place everything to a major update on platform but for alpha testing new JIT RTCG or so (arguably we could stay in odd numbers being platform development until we get to a new even number for product release), while most of developers might want or not to migrate it's necessary to establish priorities and so for having such a thing.
Thanks in advance

--- El vie, 10/2/12, Vintage Coder <vintagecoder at aol.com> escribi?:

> De: Vintage Coder <vintagecoder at aol.com>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: m3devel at elegosoft.com
> Fecha: viernes, 10 de febrero, 2012 09:14
> What is the purpose of a new release?
> A compiler and runtime that work presumably only need fixes.
> Are you talking about a major new version or a mod level or
> what? The last release on cm3 I see is from 2010. 
> 
> Are there bug fixes in the pipeline that haven't been
> verified? Are there fixes ready to go that no builds have
> been done for? What is the problem more frequent releases
> will solve? Personally I see no benefit (indeed I see many
> disadvantges) to frequent releases of stable software. But I
> often run backlevel intentionally.  
> 
> Firefox is being updated for many reasons including security
> holes, bug fixes, new standards, and more. If the Modula-3
> standard hasn't been updated, what is driving the need for
> new release(s)?
> 
> It looks like cm3 supports more platforms than I have. I
> would be willing to help out (I am not a UNIX developer) any
> way I could. I have Solaris Intel and SPARC boxes. 
> 
> ------Original Message------
> From: Peter McKinna
> To: m3devel at elegosoft.com
> Subject: [M3devel] Think we need a new release.
> Sent: 10 Feb 2012 05:01
> 
> Been a long time between releases. Must be about time.
> 
> Firefox is doing 6 weekly releases we are lucky if we get
> one every 6
> years. Sorry thats a bit harsh, all the same we need some
> new
> commitment.
> 
> Regards Peter
> 
> 


From dmuysers at hotmail.com  Fri Feb 10 15:54:59 2012
From: dmuysers at hotmail.com (Dirk Muysers)
Date: Fri, 10 Feb 2012 15:54:59 +0100
Subject: [M3devel] platform-independent object file linking
Message-ID: <SNT109-DS775C44A0CC94BF3376EE2DD780@phx.gbl>

I recently came across an article that might interest the community:

A Compiler-Supported Unification of Static and Dynamic Loading
by Felix Friedrich and Florian Negele

It is about platform-independent linking and loading of modules.
The mechanism is explained in context of the A2 (ex-Bluebottle)
OS and the Active Oberon language, but it is easily portable to
other programming environments and languages.
Its adoption, at the cost of rewriting the backend and parts of
m3core, would significantly simplify the maintenance of M3 and
also render it independent from proprietary tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/568e505e/attachment-0001.html>

From dabenavidesd at yahoo.es  Fri Feb 10 16:17:46 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 15:17:46 +0000 (GMT)
Subject: [M3devel] platform-independent object file linking
In-Reply-To: <SNT109-DS775C44A0CC94BF3376EE2DD780@phx.gbl>
Message-ID: <1328887066.93948.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
nice idea, once it's inly functional would it work for procedural languages?
The nice idea of this would port it to Module system of Modula-3 which as I understand (unless it's not Modula-3 own one) is a simplified version (most of researchers didn't concentrate on a single-separate compilation, but distributed aware compilation specially in Modula-2+, in Canada, one can ask the copy and they will send to you once you identify its name).
Thanks in advance

--- El vie, 10/2/12, Dirk Muysers <dmuysers at hotmail.com> escribi?:

De: Dirk Muysers <dmuysers at hotmail.com>
Asunto: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com
Fecha: viernes, 10 de febrero, 2012 09:54



 


I recently came across an article that might 
interest the community:
?
A 
Compiler-Supported Unification of Static and Dynamic Loading
by Felix Friedrich and Florian Negele
?
It is about platform-independent linking and 
loading of modules.
The mechanism is explained?in context of 
the?A2 (ex-Bluebottle)
OS and the?Active Oberon language, but it is 
easily portable to
other?programming environments and 
languages.
Its adoption, at the cost of rewriting the backend 
and parts of
m3core,?would significantly?simplify the maintenance of M3 and
also render it independent from proprietary 
tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/05703dc7/attachment-0001.html>

From dataf4l at gmail.com  Fri Feb 10 16:42:40 2012
From: dataf4l at gmail.com (felipe valdez)
Date: Fri, 10 Feb 2012 10:42:40 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <1328884285.44537.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>
	<1328884285.44537.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>

Mr VintageCoder,


> What is the purpose of a new release?


from a technical perspective, probably not much
but from a marketing perspective (language adoption, language value
perception), there could be a few.


> A compiler and runtime that work presumably only need fixes.


that is correct.


> Are you talking about a major new version or a mod level or what? The last
> release on cm3 I see is from 2010.


this probably disproves the argument of "6 years between releases",
however, in the fast moving tech world, some people could consider 2010 to
be a long time ago.



> Are there bug fixes in the pipeline that haven't been verified? Are there
> fixes ready to go that no builds have been done for? What is the problem
> more frequent releases will solve?


I think, it makes people perceive that the language has support, is being
actively developed, is growing , and also
that it is not dead.

I used to use tcl a lot, but I haven't got a new release in a while, and
8.6 took forever (5 years?) to get done.
this made me move away from the technology, since I saw it at the time, as
stagnating, stale, old and unsupported.

had they put a "new" brand on it ever so often, I would have been more
insterested.

in general terms, once you know perl 5.10, would you be more exicet about
learning perl 6.0 or 5.10.1 ?
I mean, seriously, who gives a damn about a 0.0.1 release anyway?

the problem I see a new release would solve, is that you get to fix stuff
(like the string broken stuff) that needs fixing, without having to
maintain 100% backwards compatibility, this can lead to a cleaner language,
like python3000 broke a lot of things, for instance.


> Personally I see no benefit (indeed I see many disadvantges) to frequent
> releases of stable software.



this is als true, there are disadvantages and I also suffer a little from
this.
but surely not something we cannot live through, especially if there is
some kind of guide (3to4 ?)




> But I often run backlevel intentionally. Firefox is being updated for many
> reasons including security holes, bug fixes, new standards, and more. If
> the Modula-3 standard hasn't been updated, what is driving the need for new
> release(s)?


if the language does not evolve, is it bound to die?
if the standard does not evolve, should one consider it to be dead?
see c++ for instance, recently, there have been changes to the language.
this motivates a lot of tuff:
conferences, new compilers, new books, new blogposts, and in general, a lot
of "hype"
if m3 was hyped a little, perhaps it could gain developers.
by gaining such developers, perhaps more bugs could be removed and features
could be added as well (for instance, in the library space, where I see
that other language have better, more tested, and easier to use LIbraries,
but this is , of course, a subjective declaration, and I don't expect
anyone to agree with me).



> It looks like cm3 supports more platforms than I have. I would be willing
> to help out (I am not a UNIX developer) any way I could. I have Solaris
> Intel and SPARC boxes.


that Is wonderful news, I appreciate the offer, I hope the language
improves, and your boxes serve the purpose!




On Fri, Feb 10, 2012 at 9:31 AM, Daniel Alejandro Benavides D. <
dabenavidesd at yahoo.es> wrote:

> Hi all:
> I think one of the purposes of that is more cross platform compatibility,
> perhaps put in place everything to a major update on platform but for alpha
> testing new JIT RTCG or so (arguably we could stay in odd numbers being
> platform development until we get to a new even number for product
> release), while most of developers might want or not to migrate it's
> necessary to establish priorities and so for having such a thing.
> Thanks in advance
>
> --- El vie, 10/2/12, Vintage Coder <vintagecoder at aol.com> escribi?:
>
> > De: Vintage Coder <vintagecoder at aol.com>
> > Asunto: Re: [M3devel] Think we need a new release.
> > Para: m3devel at elegosoft.com
> > Fecha: viernes, 10 de febrero, 2012 09:14
> > What is the purpose of a new release?
> > A compiler and runtime that work presumably only need fixes.
> > Are you talking about a major new version or a mod level or
> > what? The last release on cm3 I see is from 2010.
> >
> > Are there bug fixes in the pipeline that haven't been
> > verified? Are there fixes ready to go that no builds have
> > been done for? What is the problem more frequent releases
> > will solve? Personally I see no benefit (indeed I see many
> > disadvantges) to frequent releases of stable software. But I
> > often run backlevel intentionally.
> >
> > Firefox is being updated for many reasons including security
> > holes, bug fixes, new standards, and more. If the Modula-3
> > standard hasn't been updated, what is driving the need for
> > new release(s)?
> >
> > It looks like cm3 supports more platforms than I have. I
> > would be willing to help out (I am not a UNIX developer) any
> > way I could. I have Solaris Intel and SPARC boxes.
> >
> > ------Original Message------
> > From: Peter McKinna
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] Think we need a new release.
> > Sent: 10 Feb 2012 05:01
> >
> > Been a long time between releases. Must be about time.
> >
> > Firefox is doing 6 weekly releases we are lucky if we get
> > one every 6
> > years. Sorry thats a bit harsh, all the same we need some
> > new
> > commitment.
> >
> > Regards Peter
> >
> >
>



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

From dabenavidesd at yahoo.es  Fri Feb 10 18:00:42 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 17:00:42 +0000 (GMT)
Subject: [M3devel] platform-independent object file linking
In-Reply-To: <1328887066.93948.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <1328893242.4700.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
in the sense of if at all wanted porting functionality to Modula-3 minimal functional subset language to allow such dynamic implementation and later on pass on Modula-3. 
There are some available Models of graft Modular concepts in functional-like languages worth of writing OSes on it (concurrent ones already objected oriented) like Clean and Concurrent Clean and Gofer:
http://www4.in.tum.de/~sihling/publications/1995/DA_Sihling.ps.gz

ftp://ftp.cs.york.ac.uk/pub/malcolm/thesis.ps.Z

Anyway just a possible path of action 
Thanks in advance

--- El vie, 10/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com, "Dirk Muysers" <dmuysers at hotmail.com>
Fecha: viernes, 10 de febrero, 2012 10:17

Hi all:
nice idea, once it's inly functional would it work for procedural languages?
The nice idea of this would port it to Module system of Modula-3 which as I understand (unless it's not Modula-3 own one) is a simplified version (most of researchers didn't concentrate on a single-separate compilation, but distributed aware compilation specially in Modula-2+, in Canada, one can ask the copy and they will send to you once you identify its name).
Thanks in advance

--- El vie, 10/2/12, Dirk Muysers <dmuysers at hotmail.com> escribi?:

De: Dirk Muysers <dmuysers at hotmail.com>
Asunto: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com
Fecha: viernes, 10 de febrero, 2012 09:54



 


I recently came across an article that might 
interest the community:
?
A 
Compiler-Supported Unification of Static and Dynamic Loading
by Felix Friedrich and Florian Negele
?
It is about platform-independent linking and 
loading of modules.
The mechanism is explained?in context of 
the?A2 (ex-Bluebottle)
OS and the?Active Oberon language, but it is 
easily portable to
other?programming environments and 
languages.
Its adoption, at the cost of rewriting the backend 
and parts of
m3core,?would significantly?simplify the maintenance of M3 and
also render it independent from proprietary 
tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/edf5aa7d/attachment-0001.html>

From dabenavidesd at yahoo.es  Fri Feb 10 18:27:16 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 17:27:16 +0000 (GMT)
Subject: [M3devel] platform-independent object file linking
In-Reply-To: <1328893242.4700.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <1328894836.11850.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
in fact highly advanced mainframes with Micro-code like capabilities have been developed with companies such as NEC behind it, the Lisp Machine Engine LIME was one of them, for scheduling of JAR Japan airlines staff and we already have appliances of that kind in Modula-3:
http://www.iste.uni-stuttgart.de/fileadmin/user_upload/iste/se/research/publications/download/PraktLehr5.pdf

So I guess connecting the points there is room for that sort of work, nevertheless it's a kind of hard and brave project.
In any event C++ and others are pursuing Lambda Expressions in their Standards I want to allow such kind of work but in DEC-SRC style like Baby Modula-3 (that's where hard part comes from, since it needs work and more work). But first the first, describe the Modula-3 in a sound way is one part of it, formalization of the Language Semantics is just another so one we can be absolutely sure of what we are doing (BTW the original implementation of it failed to finish, but LIME was 2 to 10 times faster than any of this market of the day, who knows what would like today be for doing that):
http://museum.ipsj.or.jp/en/computer/other/0008.html

Thanks in advance


--- El vie, 10/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com, "Dirk Muysers" <dmuysers at hotmail.com>
Fecha: viernes, 10 de febrero, 2012 12:00

Hi all:
in the sense of if at all wanted porting functionality to Modula-3 minimal functional subset language to allow such dynamic implementation and later on pass on Modula-3. 
There are some available Models of graft Modular concepts in functional-like languages worth of writing OSes on it (concurrent ones already objected oriented) like Clean and Concurrent Clean and Gofer:
http://www4.in.tum.de/~sihling/publications/1995/DA_Sihling.ps.gz

ftp://ftp.cs.york.ac.uk/pub/malcolm/thesis.ps.Z

Anyway just a possible path of action 
Thanks in advance

--- El vie, 10/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto:
 Re: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com, "Dirk Muysers" <dmuysers at hotmail.com>
Fecha: viernes, 10 de febrero, 2012 10:17

Hi all:
nice idea, once it's inly functional would it work for procedural languages?
The nice idea of this would port it to Module system of Modula-3 which as I understand (unless it's not Modula-3 own one) is a simplified version (most of researchers didn't concentrate on a single-separate compilation, but distributed aware compilation specially in Modula-2+, in Canada, one can ask the copy and they will send to you once you identify its name).
Thanks in advance

--- El
 vie, 10/2/12, Dirk Muysers <dmuysers at hotmail.com> escribi?:

De: Dirk Muysers <dmuysers at hotmail.com>
Asunto: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com
Fecha: viernes, 10 de febrero, 2012 09:54



 


I recently came across an article that might 
interest the community:
?
A 
Compiler-Supported Unification of Static and Dynamic Loading
by Felix Friedrich and Florian Negele
?
It is about platform-independent linking and 
loading of modules.
The mechanism is explained?in context of 
the?A2 (ex-Bluebottle)
OS and the?Active Oberon language, but it is 
easily portable to
other?programming environments and 
languages.
Its adoption, at the cost of rewriting the backend 
and parts of
m3core,?would significantly?simplify the maintenance of M3 and
also render it independent from proprietary 
tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/0c74d194/attachment-0001.html>

From dabenavidesd at yahoo.es  Fri Feb 10 21:21:26 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 20:21:26 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
Message-ID: <1328905286.88292.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
It's not correct to release a product for bug fixing (unless is ESC annotations), but because that can be embarrassing, of course SW Engineering based on that is just ridiculous (and by the way the release cycle is something that community should decide, I agree with the idea of that way of releasing "bug fixes" rather than functional implementation correction and documentation in the other side).
But in any event, the idea of experimental platforms is not bad at all in a new release, since several backends have been like that and so, it needs to give more thought if it's? valuable? or not is debatable.
Thanks in advance 

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

De: felipe valdez <dataf4l at gmail.com>
Asunto: Re: [M3devel] Think we need a new release.
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: m3devel at elegosoft.com, vintagecoder at aol.com
Fecha: viernes, 10 de febrero, 2012 10:42

Mr VintageCoder, What is the purpose of a new release? 
from a technical perspective, probably not much

but from a marketing perspective (language adoption, language value perception), there could be a few. 

A compiler and runtime that work presumably only need fixes. 
that is correct. 

Are you talking about a major new version or a mod level or what? The last release on cm3 I see is from 2010.

 
this probably disproves the argument of "6 years between releases", however, in the fast moving tech world, some people could consider 2010 to be a long time ago.


 Are there bug fixes in the pipeline that haven't been verified? Are there fixes ready to go that no builds have been done for? What is the problem more frequent releases will solve? 


I think, it makes people perceive that the language has support, is being actively developed, is growing , and alsothat it is not dead.
I used to use tcl a lot, but I haven't got a new release in a while, and 8.6 took forever (5 years?) to get done.

this made me move away from the technology, since I saw it at the time, as stagnating, stale, old and unsupported.
had they put a "new" brand on it ever so often, I would have been more insterested.


in general terms, once you know perl 5.10, would you be more exicet about learning perl 6.0 or 5.10.1 ?I mean, seriously, who gives a damn about a 0.0.1 release anyway?


the problem I see a new release would solve, is that you get to fix stuff (like the string broken stuff) that needs fixing, without having to maintain 100% backwards compatibility, this can lead to a cleaner language, like python3000 broke a lot of things, for instance.

 Personally I see no benefit (indeed I see many disadvantges) to frequent releases of stable software.



this is als true, there are disadvantages and I also suffer a little from this.but surely not something we cannot live through, especially if there is some kind of guide (3to4 ?)



  But I often run backlevel intentionally.

 Firefox is being updated for many reasons including security holes, bug fixes, new standards, and more. If the Modula-3 standard hasn't been updated, what is driving the need for new release(s)?


if the language does not evolve, is it bound to die?if the standard does not evolve, should one consider it to be dead?see c++ for instance, recently, there have been changes to the language.

this motivates a lot of tuff:conferences, new compilers, new books, new blogposts, and in general, a lot of "hype"if m3 was hyped a little, perhaps it could gain developers.

by gaining such developers, perhaps more bugs could be removed and features could be added as well (for instance, in the library space, where I see that other language have better, more tested, and easier to use LIbraries, but this is , of course, a subjective declaration, and I don't expect anyone to agree with me).


 

 It looks like cm3 supports more platforms than I have. I would be willing to help out (I am not a UNIX developer) any way I could. I have Solaris Intel and SPARC boxes.
that Is wonderful news, I appreciate the offer, I hope the language improves, and your boxes serve the purpose!



 
On Fri, Feb 10, 2012 at 9:31 AM, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:


Hi all:

I think one of the purposes of that is more cross platform compatibility, perhaps put in place everything to a major update on platform but for alpha testing new JIT RTCG or so (arguably we could stay in odd numbers being platform development until we get to a new even number for product release), while most of developers might want or not to migrate it's necessary to establish priorities and so for having such a thing.



Thanks in advance



--- El vie, 10/2/12, Vintage Coder <vintagecoder at aol.com> escribi?:



> De: Vintage Coder <vintagecoder at aol.com>

> Asunto: Re: [M3devel] Think we need a new release.

> Para: m3devel at elegosoft.com

> Fecha: viernes, 10 de febrero, 2012 09:14

> What is the purpose of a new release?

> A compiler and runtime that work presumably only need fixes.

> Are you talking about a major new version or a mod level or

> what? The last release on cm3 I see is from 2010.

>

> Are there bug fixes in the pipeline that haven't been

> verified? Are there fixes ready to go that no builds have

> been done for? What is the problem more frequent releases

> will solve? Personally I see no benefit (indeed I see many

> disadvantges) to frequent releases of stable software. But I

> often run backlevel intentionally.

>

> Firefox is being updated for many reasons including security

> holes, bug fixes, new standards, and more. If the Modula-3

> standard hasn't been updated, what is driving the need for

> new release(s)?

>

> It looks like cm3 supports more platforms than I have. I

> would be willing to help out (I am not a UNIX developer) any

> way I could. I have Solaris Intel and SPARC boxes.

>

> ------Original Message------

> From: Peter McKinna

> To: m3devel at elegosoft.com

> Subject: [M3devel] Think we need a new release.

> Sent: 10 Feb 2012 05:01

>

> Been a long time between releases. Must be about time.

>

> Firefox is doing 6 weekly releases we are lucky if we get

> one every 6

> years. Sorry thats a bit harsh, all the same we need some

> new

> commitment.

>

> Regards Peter

>

>




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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/98d168e2/attachment-0001.html>

From m3 at sol42.com  Fri Feb 10 22:50:13 2012
From: m3 at sol42.com (m3 at sol42.com)
Date: Fri, 10 Feb 2012 22:50:13 +0100
Subject: [M3devel] Think we need a new release.
In-Reply-To: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>
References: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>
Message-ID: <A0DF2CB8-A6D9-44B1-BC9B-B03DEEC9A52E@sol42.com>

On 10 Feb 2012, at 15:14, Vintage Coder wrote:
> What is the purpose of a new release? A compiler and runtime that work presumably only need fixes.

Agreed.  I can think of two reasons: adding "must have" stuff to the standard library, and fixing bugs or improving library, compiler, or runtime.  Note that "must have" should probably be evaluated in the context of systems programming, which is what Modula-3 is for.

Even adding new platforms should not require bumping the version number if it is the existing infrastructure that is being ported.

There are loads of "greatest next thing" languages out there that you have to re-learn every few releases.  Modula-3 is thankfully not one of them.  Want new stuff in the language?  Then you want Modula-3+ or Modula-4.

Regards.
-Daniel




From dabenavidesd at yahoo.es  Sat Feb 11 00:30:23 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 23:30:23 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <A0DF2CB8-A6D9-44B1-BC9B-B03DEEC9A52E@sol42.com>
Message-ID: <1328916623.650.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
Modula-2+ distributed compiler didn't require languages changes but extensive testing and some distributed setting, which is why you need some sort of engineering process, at least is what I think that happens.
If you don't want dynamic compilation/interpretation that's up to one's needs, but currently most compilers do have some sort of dynamic interpretation capabilities, and being Modula-3 and innovative platform, it must have one. That's again what I think. I guess the way of not interrupting is just is m3-obliq stuff (since it's the scripting expression of Modula-3 RT) and prepare for the needed changes in the next big release. So for me would be like v 5.10 < 6.0
Thanks in advance

--- El vie, 10/2/12, m3 at sol42.com <m3 at sol42.com> escribi?:

> De: m3 at sol42.com <m3 at sol42.com>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 10 de febrero, 2012 16:50
> On 10 Feb 2012, at 15:14, Vintage
> Coder wrote:
> > What is the purpose of a new release? A compiler and
> runtime that work presumably only need fixes.
> 
> Agreed.  I can think of two reasons: adding "must have"
> stuff to the standard library, and fixing bugs or improving
> library, compiler, or runtime.  Note that "must have"
> should probably be evaluated in the context of systems
> programming, which is what Modula-3 is for.
> 
> Even adding new platforms should not require bumping the
> version number if it is the existing infrastructure that is
> being ported.
> 
> There are loads of "greatest next thing" languages out there
> that you have to re-learn every few releases.  Modula-3
> is thankfully not one of them.  Want new stuff in the
> language?  Then you want Modula-3+ or Modula-4.
> 
> Regards.
> -Daniel
> 
> 
> 


From dabenavidesd at yahoo.es  Sat Feb 11 02:37:37 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 11 Feb 2012 01:37:37 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <1328916623.650.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <1328924257.76277.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:

In case, you want the reference, and plus [1]:

At the time it was a kind of important to investigate [1] (for instance the ARX operating system it was a real issue for the day to day development) about Acorn in the 80's:
http://www.legacy.com/guestbook/mercurynews/guestbook.aspx?n=steve-glassman&pid=144489261&page=3

I guess in the case of a Microkernel and a huge UI libraries it might matter (Interfaces of 250k loc would would be good test case in terms of Modular verification it might matter, if the upper limit is O(n^5) actually to make that calculation makes an unknown prefix for that number power of ten, 26th order).

In the other hand you might want to leave like that but being one of the most important features to be able to program in the large, I feel this is better that the pain to wait that kind of operations (usually ESC ten times slower than compilation time).

[1] U. Postavsky, ?Distributed Compilation Using Distributed Shared Memory,? M.Sc., University of Toronto (Canada), Canada, 1990.


--- El vie, 10/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: "m3devel" <m3devel at elegosoft.com>, m3 at sol42.com
> Fecha: viernes, 10 de febrero, 2012 18:30
> Hi all:
> Modula-2+ distributed compiler didn't require languages
> changes but extensive testing and some distributed setting,
> which is why you need some sort of engineering process, at
> least is what I think that happens.
> If you don't want dynamic compilation/interpretation that's
> up to one's needs, but currently most compilers do have some
> sort of dynamic interpretation capabilities, and being
> Modula-3 and innovative platform, it must have one. That's
> again what I think. I guess the way of not interrupting is
> just is m3-obliq stuff (since it's the scripting expression
> of Modula-3 RT) and prepare for the needed changes in the
> next big release. So for me would be like v 5.10 < 6.0
> Thanks in advance
> 
> --- El vie, 10/2/12, m3 at sol42.com <m3 at sol42.com>
> escribi?:
> 
> > De: m3 at sol42.com <m3 at sol42.com>
> > Asunto: Re: [M3devel] Think we need a new release.
> > Para: "m3devel" <m3devel at elegosoft.com>
> > Fecha: viernes, 10 de febrero, 2012 16:50
> > On 10 Feb 2012, at 15:14, Vintage
> > Coder wrote:
> > > What is the purpose of a new release? A compiler
> and
> > runtime that work presumably only need fixes.
> > 
> > Agreed.  I can think of two reasons: adding "must
> have"
> > stuff to the standard library, and fixing bugs or
> improving
> > library, compiler, or runtime.  Note that "must
> have"
> > should probably be evaluated in the context of systems
> > programming, which is what Modula-3 is for.
> > 
> > Even adding new platforms should not require bumping
> the
> > version number if it is the existing infrastructure
> that is
> > being ported.
> > 
> > There are loads of "greatest next thing" languages out
> there
> > that you have to re-learn every few releases. 
> Modula-3
> > is thankfully not one of them.  Want new stuff in
> the
> > language?  Then you want Modula-3+ or Modula-4.
> > 
> > Regards.
> > -Daniel
> > 
> > 
> >
> 


From dabenavidesd at yahoo.es  Sun Feb 12 22:36:20 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 12 Feb 2012 21:36:20 +0000 (GMT)
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <20120209175908.GC13717@topoi.pooq.com>
Message-ID: <1329082580.11381.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
There is a compile-time switch to not generate code for <*ASSERT exp*> back in DEC-SRC days ("Front-end options"):
http://homepages.cs.ncl.ac.uk/c.r.snow/home.formal/html/oldmod3/html/m3/options.html#first-pass

And it's still there is CM3 ("compile options") if you care:
http://opencm3.net/doc/help/cm3/m3build/options.html

Good to know, I bet if you try it, it would "work" as you first results. Wouldn't it?

Thanks in advance

--- El jue, 9/2/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] Assertion failed to complain
> Para: m3devel at elegosoft.com
> Fecha: jueves, 9 de febrero, 2012 12:59
> On Thu, Feb 09, 2012 at 05:51:24PM
> +0000, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > It might be that needs to be uppercase (in case
> compiler doesn't warn but I guess that would desired
> behavior, or not, since it would be unknown at compile
> time).
> > <*ASSERT exp*>
> > 
> > Thanks in advance
> 
> That was exactly it.  One of the few places where
> things are 
> case-sensitive, but a wrong case doesn't cause an error
> message.
> (in fact, it suppressed it)
> 
> Things are failing properly now.
> 
> -- hendrik
> 


From vintagecoder at aol.com  Mon Feb 13 15:06:30 2012
From: vintagecoder at aol.com (vintagecoder at aol.com)
Date: Mon, 13 Feb 2012 14:06:30 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <A0DF2CB8-A6D9-44B1-BC9B-B03DEEC9A52E@sol42.com>
Message-ID: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>

Hello Daniel,

> Agreed.  I can think of two reasons: adding "must have" stuff to the
> standard library, and fixing bugs or improving library, compiler, or
> runtime.  Note that "must have" should probably be evaluated in the
> context of systems programming, which is what Modula-3 is for.

For myself I tend to be very careful when it comes to "must have" in
language design. If you feel the language spec is outdated or insufficient,
then I think it's a dangerous, slippery slope to start adding features to
the language even if they are a must have, without a standards committee.
If people are not careful, they can turn a language that was designed well
into a junk heap before they know it. The threat to the death of a language
through inappropriate changes is far greater than the threat of death by
lack of changes.

If people agree the current spec is not sufficient, or wrong, it seems to
me the first step is to form a language specification committee where the
language can be carefully controlled- and this has to be from a purist
view of the language with no concern for implementation and no "baggage"
other than the existing language spec has to be respected- all the changes
have to be aligned and harmonious with the original purpose and intentions
and direction of Modula-3, otherwise what you said later about a new
language comes into play. Optional features have to be clearly optional-
extensions to the standard that don't make sense in the core have to be
clearly deliniated and the spec has to be amended cleanly to separate core
language, optional extensions, etc. The Ada specification is a good
document to look at for examples of how to do this.

> Even adding new platforms should not require bumping the version number
> if it is the existing infrastructure that is being ported.

Agreed.

> There are loads of "greatest next thing" languages out there that you
> have to re-learn every few releases.  Modula-3 is thankfully not one of
> them.

Agreed!

> Want new stuff in the language?  Then you want Modula-3+ or Modula-4.

Agreed again!

People are so used to constant turmoil because of Linux. I come from a much
different background and I value stability and evolution, not revolution.
New is not necessarily good just like old is not necessarily bad. Good
things pass the test of time and don't need constant changes. If we are
talking about changing the underlying implementation without changing the
language then of course this is fine and should not be held back. My
concern is about letting the implementation drive the specification- I feel
that is wrong, dangerous, and should be resisted.

Many languages today are out of control. To grow a language properly is an
extremely big challenge that has to be taken with a great deal of respect
and concern.


From vintagecoder at aol.com  Mon Feb 13 15:33:20 2012
From: vintagecoder at aol.com (vintagecoder at aol.com)
Date: Mon, 13 Feb 2012 14:33:20 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
Message-ID: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>

>> What is the purpose of a new release?
>
> from a technical perspective, probably not much but from a marketing
> perspective (language adoption, language value perception), there could
> be a few.

I realize my opinion is not the majority, but I'm less inclined to like
something that changes constantly or is popular. I try to find things that
are well designed and work. Constant releases are not on my list of
priorities.

>> Are you talking about a major new version or a mod level or what? The
>> last release on cm3 I see is from 2010.

> this probably disproves the argument of "6 years between releases",
> however, in the fast moving tech world, some people could consider 2010
> to be a long time ago.

Ok but anyone looking for Modula-3 should understand the history and
realize they are not interested in the latest language, if they were, they
wouldn't be in our group. I think that greatly lessens the impact of not
having frequent or regular releases. It's one of the reasons I joined the
development mailing list even though I probably have nothing to contribute
as a developer. I wanted to see if the project is alive. For me is seems it
is.

>> Are there bug fixes in the pipeline that haven't been verified? Are
>> there fixes ready to go that no builds have been done for? What is the
>> problem more frequent releases will solve?

> I think, it makes people perceive that the language has support, is being
> actively developed, is growing , and also that it is not dead.

For myself I was interested in those answers also, so I joined the mailing
list. I saw from the releases the project is going ahead. I see from the
fact they have so much platform support this is a serious and big project.
I have seen many other famous projects without nearly as much platform
support. I think anybody who is sincerely interested in Modula-3 can learn
you guys are serious and work is happening.

> I used to use tcl a lot, but I haven't got a new release in a while, and
> 8.6 took forever (5 years?) to get done. this made me move away from the
> technology, since I saw it at the time, as stagnating, stale, old and
> unsupported. 

That is very interesting because as someone looking for a new scripting
language, I found tcl very encouraging! I did the same thing as I did for
Modula-3. I followed the newsgroups and I saw people are using it. I saw
the releases and saw they are continuing to fix bugs. I don't need
something new, I need something good. Of course it's important the project
is alive and well so I don't find something good but dead. I saw tcl has
native support for sqlite and other interesting features. To me it looks
very much alive.

> had they put a "new" brand on it ever so often, I would have been more
> insterested. 

Ok but I think at some point people have to break the myth of constant
change as something favorable. 

> in general terms, once you know perl 5.10, would you be more exicet about
> learning perl 6.0 or 5.10.1 ? I mean, seriously, who gives a damn about a
> 0.0.1 release anyway?

It's not my view. I'm personally more happy with evolutionary growth. If
something isn't any good, I don't use it (unless I have to for work!) If
something is good, it doesn't need major changes, and changes are what
usually make things worse, not better. I realize my view might not be so
popular, but this is my view.

> the problem I see a new release would solve, is that you get to fix stuff
> (like the string broken stuff) that needs fixing, without having to
> maintain 100% backwards compatibility, this can lead to a cleaner
> language, like python3000 broke a lot of things, for instance.

I don't know Modula-3 (trying to learn it) enough to say what is broken.
But I do get nervous when I hear people say backwards compatibility isn't
important, and stands in the way of the future. For that I say if that is
really true, a group of people who really understand these things need to
carefully decide whether the language spec is broken or whether the
implementation is broken or both. And it has to be addressed based on the
outcome of that discussion, not by taking the situation too lightly. Just
to give you some idea of why I am saying this is because most of the
software I work on is 20 or more years old and I saw the value in having
experts who understand the purpose and the foundation involved in deciding
whether a new feature is good or not. Sometimes something looks very good
but it goes against the core direction. In this case a hard decision has to
be made to fork the product, or develop a new version. For a language it's
a very very serious process. If the spec is broken then perhaps it's time
to develop a new language as Daniel said. If the implementation is broken,
then sure it should be fixed to conform to the spec. But the main thing is
I believe especially for languages but for most software it is wrong and a
mistake to let the implentation drive the specification. You need to have
qualified good people managing the spec, and the implementation must come
after that.

>> Personally I see no benefit (indeed I see many disadvantges) to frequent
>> releases of stable software. 

> this is als true, there are disadvantages and I also suffer a little from
> this. but surely not something we cannot live through, especially if
> there is some kind of guide (3to4 ?)

I think I understand your point, but I feel this view is looking at the
language more like an OS. Languages and OS are very different creations. An
OS has to provide services to get work done. It doesn't necessarily have to
be pure because the end is more important than the means. But a language is
all about purity, otherwise all languages converge (indeed that is
happening!) and there becomes little value in any language since they all
do pretty much the same thing.

Language has to be about elegance and clarity in expression, and safety in
implementation so that the intent of the person using the language is
carried out as he expects, with no side effects or smoke and mirrors. For
this reason I am very opposed to growing languages without very careful
study by people who know the history and tradition of the language and give
it some degree of reverence.


>> But I often run backlevel intentionally. Firefox is being updated for
>> many reasons including security holes, bug fixes, new standards, and
>> more. If the Modula-3 standard hasn't been updated, what is driving the
>> need for new release(s)?

> if the language does not evolve, is it bound to die?

Not as far as I am concerned. But I still run programs in SNOBOL4 from
1969. YMMV ;-)

> if the standard does not evolve, should one consider it to be dead?

It might be dead, it might not. It all depends on whether the language is
still useful and people actually use it.

> see c++ for instance, recently, there have been changes to the language.
> this motivates a lot of tuff: conferences, new compilers, new books, new
> blogposts, and in general, a lot of "hype"

Right, but C++ has many problems and has popularity and issues Modula-3
happily doesn't have. If you are trying to compete with a mainstream
language you'll probably not be satisfied.

> if m3 was hyped a little, perhaps it could gain developers.

I think people who attracted by hype aren't the type of people who will
appreciate Modula-3.

> by gaining such developers, perhaps more bugs could be removed and
> features could be added as well (for instance, in the library space,
> where I see that other language have better, more tested, and easier to
> use LIbraries, but this is , of course, a subjective declaration, and I
> don't expect anyone to agree with me). 

I think it's important, just like in some other successful but maybe not so
elegant languages (C++, Java) to make a distinction between language and
libraries. Free Pascal seems to do this pretty well also. You (usually)
don't have to change the language spec or implementation to offer usable
libraries. If you do, it should be done carefully. But the language spec
should not be changed without much study and thought.

>> It looks like cm3 supports more platforms than I have. I would be
>> willing to help out (I am not a UNIX developer) any way I could. I have
>> Solaris Intel and SPARC boxes.
>
>that Is wonderful news, I appreciate the offer, I hope the language
>improves, and your boxes serve the purpose!

I see they already have SPARC Solaris support and I think x86 so I am not
able to offer anything new, but if I can help I will be glad to.

For me I am having a hard time finding learning materials. I think the
biggest boost to the language would come not from changing it or making new
releases, but to put together a really good book on Modula-3 and also
showing how cm3 implements it. The book should break these two things out
clearly so it could serve as a reference and guide to Modula-3 itself as
well as how to use cm3 to code in Modula-3. The main barrier to adoption
and new fans of Modula-3 is the lack of educational materials. You can
books on almost any topic on the net, but Modula-3 has almost nothing
available.



From dabenavidesd at yahoo.es  Mon Feb 13 17:08:53 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 13 Feb 2012 16:08:53 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>
Message-ID: <1329149333.68679.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:

To be honest, to make a language change (and of course I'm looking forward but respecting and acknowledging and respecting the path that brigs here) I'm not involved I'm not interested (so I realize your concern).
That's why, you know, I mentioned that we need to care about some issues so whoever comes later (in some time sadly or not many of our brains will be with more decades and some other will take that job of making it better this) will do it rightly.
Although I seem not care about us in the future I understand that we need more than a language revision (I'm not saying changes or update), we need:
1) Make the best effort we can (even that means some money) to try to recover design meetings, since there is already some bits in the SPWM3, I would like to recover the damaged tapes, if they ever really are somewhere and make the effort to at least recover the most of it. This to preserve that for posterity. I don't care more than if they are lost forever
2) Define Languages changes without experimenting makes no sense, so my thinking is that we need to implement gradually baby Modula-3 and start from there a serious (although painful) top down language definition according to the same rules defined or at least type compatible. If that needs human revision or machine learning I guess we would do that.
3) Whatever conclusion is taken a path of action will follow so anyone can always return to the point 1) until some agreement is made between all people.


Thanks in advance

--- El lun, 13/2/12, vintagecoder at aol.com <vintagecoder at aol.com> escribi?:

> De: vintagecoder at aol.com <vintagecoder at aol.com>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: m3devel at elegosoft.com
> Fecha: lunes, 13 de febrero, 2012 09:06
> Hello Daniel,
> 
> > Agreed.  I can think of two reasons: adding "must
> have" stuff to the
> > standard library, and fixing bugs or improving library,
> compiler, or
> > runtime.  Note that "must have" should probably be
> evaluated in the
> > context of systems programming, which is what Modula-3
> is for.
> 
> For myself I tend to be very careful when it comes to "must
> have" in
> language design. If you feel the language spec is outdated
> or insufficient,
> then I think it's a dangerous, slippery slope to start
> adding features to
> the language even if they are a must have, without a
> standards committee.
> If people are not careful, they can turn a language that was
> designed well
> into a junk heap before they know it. The threat to the
> death of a language
> through inappropriate changes is far greater than the threat
> of death by
> lack of changes.
> 
> If people agree the current spec is not sufficient, or
> wrong, it seems to
> me the first step is to form a language specification
> committee where the
> language can be carefully controlled- and this has to be
> from a purist
> view of the language with no concern for implementation and
> no "baggage"
> other than the existing language spec has to be respected-
> all the changes
> have to be aligned and harmonious with the original purpose
> and intentions
> and direction of Modula-3, otherwise what you said later
> about a new
> language comes into play. Optional features have to be
> clearly optional-
> extensions to the standard that don't make sense in the core
> have to be
> clearly deliniated and the spec has to be amended cleanly to
> separate core
> language, optional extensions, etc. The Ada specification is
> a good
> document to look at for examples of how to do this.
> 
> > Even adding new platforms should not require bumping
> the version number
> > if it is the existing infrastructure that is being
> ported.
> 
> Agreed.
> 
> > There are loads of "greatest next thing" languages out
> there that you
> > have to re-learn every few releases.  Modula-3 is
> thankfully not one of
> > them.
> 
> Agreed!
> 
> > Want new stuff in the language?  Then you want
> Modula-3+ or Modula-4.
> 
> Agreed again!
> 
> People are so used to constant turmoil because of Linux. I
> come from a much
> different background and I value stability and evolution,
> not revolution.
> New is not necessarily good just like old is not necessarily
> bad. Good
> things pass the test of time and don't need constant
> changes. If we are
> talking about changing the underlying implementation without
> changing the
> language then of course this is fine and should not be held
> back. My
> concern is about letting the implementation drive the
> specification- I feel
> that is wrong, dangerous, and should be resisted.
> 
> Many languages today are out of control. To grow a language
> properly is an
> extremely big challenge that has to be taken with a great
> deal of respect
> and concern.
> 


From vintagecoder at aol.com  Mon Feb 13 17:31:41 2012
From: vintagecoder at aol.com (Vintage Coder)
Date: Mon, 13 Feb 2012 16:31:41 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_-8bycGnCQekUFbABoYy1u9e0Otujvh-985CV90Wc5cH6g@mail.gmail.com>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
	<CAGi-_-8bycGnCQekUFbABoYy1u9e0Otujvh-985CV90Wc5cH6g@mail.gmail.com>
Message-ID: <367439191-1329150681-cardhu_decombobulator_blackberry.rim.net-766960143-@b15.c1.bise3.blackberry>

A video is "nice to have" but it wasn't what I am talking about. Nothing can replace a good book when it comes to learning a new language. 

The Ada wikibook is an example of a possible starting point. 

-----Original Message-----
From: felipe valdez <dataf4l at gmail.com>
Date: Mon, 13 Feb 2012 11:03:33 
To: <vintagecoder at aol.com>
Cc: <m3devel at elegosoft.com>
Subject: Re: [M3devel] Think we need a new release.

I recommend the video tutorial format, as I always have.


On Mon, Feb 13, 2012 at 9:33 AM,  <vintagecoder at aol.com> wrote:
>>> What is the purpose of a new release?
>>
>> from a technical perspective, probably not much but from a marketing
>> perspective (language adoption, language value perception), there could
>> be a few.
>
> I realize my opinion is not the majority, but I'm less inclined to like
> something that changes constantly or is popular. I try to find things that
> are well designed and work. Constant releases are not on my list of
> priorities.
>
>>> Are you talking about a major new version or a mod level or what? The
>>> last release on cm3 I see is from 2010.
>
>> this probably disproves the argument of "6 years between releases",
>> however, in the fast moving tech world, some people could consider 2010
>> to be a long time ago.
>
> Ok but anyone looking for Modula-3 should understand the history and
> realize they are not interested in the latest language, if they were, they
> wouldn't be in our group. I think that greatly lessens the impact of not
> having frequent or regular releases. It's one of the reasons I joined the
> development mailing list even though I probably have nothing to contribute
> as a developer. I wanted to see if the project is alive. For me is seems it
> is.
>
>>> Are there bug fixes in the pipeline that haven't been verified? Are
>>> there fixes ready to go that no builds have been done for? What is the
>>> problem more frequent releases will solve?
>
>> I think, it makes people perceive that the language has support, is being
>> actively developed, is growing , and also that it is not dead.
>
> For myself I was interested in those answers also, so I joined the mailing
> list. I saw from the releases the project is going ahead. I see from the
> fact they have so much platform support this is a serious and big project.
> I have seen many other famous projects without nearly as much platform
> support. I think anybody who is sincerely interested in Modula-3 can learn
> you guys are serious and work is happening.
>
>> I used to use tcl a lot, but I haven't got a new release in a while, and
>> 8.6 took forever (5 years?) to get done. this made me move away from the
>> technology, since I saw it at the time, as stagnating, stale, old and
>> unsupported.
>
> That is very interesting because as someone looking for a new scripting
> language, I found tcl very encouraging! I did the same thing as I did for
> Modula-3. I followed the newsgroups and I saw people are using it. I saw
> the releases and saw they are continuing to fix bugs. I don't need
> something new, I need something good. Of course it's important the project
> is alive and well so I don't find something good but dead. I saw tcl has
> native support for sqlite and other interesting features. To me it looks
> very much alive.
>
>> had they put a "new" brand on it ever so often, I would have been more
>> insterested.
>
> Ok but I think at some point people have to break the myth of constant
> change as something favorable.
>
>> in general terms, once you know perl 5.10, would you be more exicet about
>> learning perl 6.0 or 5.10.1 ? I mean, seriously, who gives a damn about a
>> 0.0.1 release anyway?
>
> It's not my view. I'm personally more happy with evolutionary growth. If
> something isn't any good, I don't use it (unless I have to for work!) If
> something is good, it doesn't need major changes, and changes are what
> usually make things worse, not better. I realize my view might not be so
> popular, but this is my view.
>
>> the problem I see a new release would solve, is that you get to fix stuff
>> (like the string broken stuff) that needs fixing, without having to
>> maintain 100% backwards compatibility, this can lead to a cleaner
>> language, like python3000 broke a lot of things, for instance.
>
> I don't know Modula-3 (trying to learn it) enough to say what is broken.
> But I do get nervous when I hear people say backwards compatibility isn't
> important, and stands in the way of the future. For that I say if that is
> really true, a group of people who really understand these things need to
> carefully decide whether the language spec is broken or whether the
> implementation is broken or both. And it has to be addressed based on the
> outcome of that discussion, not by taking the situation too lightly. Just
> to give you some idea of why I am saying this is because most of the
> software I work on is 20 or more years old and I saw the value in having
> experts who understand the purpose and the foundation involved in deciding
> whether a new feature is good or not. Sometimes something looks very good
> but it goes against the core direction. In this case a hard decision has to
> be made to fork the product, or develop a new version. For a language it's
> a very very serious process. If the spec is broken then perhaps it's time
> to develop a new language as Daniel said. If the implementation is broken,
> then sure it should be fixed to conform to the spec. But the main thing is
> I believe especially for languages but for most software it is wrong and a
> mistake to let the implentation drive the specification. You need to have
> qualified good people managing the spec, and the implementation must come
> after that.
>
>>> Personally I see no benefit (indeed I see many disadvantges) to frequent
>>> releases of stable software.
>
>> this is als true, there are disadvantages and I also suffer a little from
>> this. but surely not something we cannot live through, especially if
>> there is some kind of guide (3to4 ?)
>
> I think I understand your point, but I feel this view is looking at the
> language more like an OS. Languages and OS are very different creations. An
> OS has to provide services to get work done. It doesn't necessarily have to
> be pure because the end is more important than the means. But a language is
> all about purity, otherwise all languages converge (indeed that is
> happening!) and there becomes little value in any language since they all
> do pretty much the same thing.
>
> Language has to be about elegance and clarity in expression, and safety in
> implementation so that the intent of the person using the language is
> carried out as he expects, with no side effects or smoke and mirrors. For
> this reason I am very opposed to growing languages without very careful
> study by people who know the history and tradition of the language and give
> it some degree of reverence.
>
>
>>> But I often run backlevel intentionally. Firefox is being updated for
>>> many reasons including security holes, bug fixes, new standards, and
>>> more. If the Modula-3 standard hasn't been updated, what is driving the
>>> need for new release(s)?
>
>> if the language does not evolve, is it bound to die?
>
> Not as far as I am concerned. But I still run programs in SNOBOL4 from
> 1969. YMMV ;-)
>
>> if the standard does not evolve, should one consider it to be dead?
>
> It might be dead, it might not. It all depends on whether the language is
> still useful and people actually use it.
>
>> see c++ for instance, recently, there have been changes to the language.
>> this motivates a lot of tuff: conferences, new compilers, new books, new
>> blogposts, and in general, a lot of "hype"
>
> Right, but C++ has many problems and has popularity and issues Modula-3
> happily doesn't have. If you are trying to compete with a mainstream
> language you'll probably not be satisfied.
>
>> if m3 was hyped a little, perhaps it could gain developers.
>
> I think people who attracted by hype aren't the type of people who will
> appreciate Modula-3.
>
>> by gaining such developers, perhaps more bugs could be removed and
>> features could be added as well (for instance, in the library space,
>> where I see that other language have better, more tested, and easier to
>> use LIbraries, but this is , of course, a subjective declaration, and I
>> don't expect anyone to agree with me).
>
> I think it's important, just like in some other successful but maybe not so
> elegant languages (C++, Java) to make a distinction between language and
> libraries. Free Pascal seems to do this pretty well also. You (usually)
> don't have to change the language spec or implementation to offer usable
> libraries. If you do, it should be done carefully. But the language spec
> should not be changed without much study and thought.
>
>>> It looks like cm3 supports more platforms than I have. I would be
>>> willing to help out (I am not a UNIX developer) any way I could. I have
>>> Solaris Intel and SPARC boxes.
>>
>>that Is wonderful news, I appreciate the offer, I hope the language
>>improves, and your boxes serve the purpose!
>
> I see they already have SPARC Solaris support and I think x86 so I am not
> able to offer anything new, but if I can help I will be glad to.
>
> For me I am having a hard time finding learning materials. I think the
> biggest boost to the language would come not from changing it or making new
> releases, but to put together a really good book on Modula-3 and also
> showing how cm3 implements it. The book should break these two things out
> clearly so it could serve as a reference and guide to Modula-3 itself as
> well as how to use cm3 to code in Modula-3. The main barrier to adoption
> and new fans of Modula-3 is the lack of educational materials. You can
> books on almost any topic on the net, but Modula-3 has almost nothing
> available.
>



-- 
312-444-2124
Skype: f3l.headhunter
Casa: 8043901

From dataf4l at gmail.com  Mon Feb 13 17:03:33 2012
From: dataf4l at gmail.com (felipe valdez)
Date: Mon, 13 Feb 2012 11:03:33 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
Message-ID: <CAGi-_-8bycGnCQekUFbABoYy1u9e0Otujvh-985CV90Wc5cH6g@mail.gmail.com>

I recommend the video tutorial format, as I always have.


On Mon, Feb 13, 2012 at 9:33 AM,  <vintagecoder at aol.com> wrote:
>>> What is the purpose of a new release?
>>
>> from a technical perspective, probably not much but from a marketing
>> perspective (language adoption, language value perception), there could
>> be a few.
>
> I realize my opinion is not the majority, but I'm less inclined to like
> something that changes constantly or is popular. I try to find things that
> are well designed and work. Constant releases are not on my list of
> priorities.
>
>>> Are you talking about a major new version or a mod level or what? The
>>> last release on cm3 I see is from 2010.
>
>> this probably disproves the argument of "6 years between releases",
>> however, in the fast moving tech world, some people could consider 2010
>> to be a long time ago.
>
> Ok but anyone looking for Modula-3 should understand the history and
> realize they are not interested in the latest language, if they were, they
> wouldn't be in our group. I think that greatly lessens the impact of not
> having frequent or regular releases. It's one of the reasons I joined the
> development mailing list even though I probably have nothing to contribute
> as a developer. I wanted to see if the project is alive. For me is seems it
> is.
>
>>> Are there bug fixes in the pipeline that haven't been verified? Are
>>> there fixes ready to go that no builds have been done for? What is the
>>> problem more frequent releases will solve?
>
>> I think, it makes people perceive that the language has support, is being
>> actively developed, is growing , and also that it is not dead.
>
> For myself I was interested in those answers also, so I joined the mailing
> list. I saw from the releases the project is going ahead. I see from the
> fact they have so much platform support this is a serious and big project.
> I have seen many other famous projects without nearly as much platform
> support. I think anybody who is sincerely interested in Modula-3 can learn
> you guys are serious and work is happening.
>
>> I used to use tcl a lot, but I haven't got a new release in a while, and
>> 8.6 took forever (5 years?) to get done. this made me move away from the
>> technology, since I saw it at the time, as stagnating, stale, old and
>> unsupported.
>
> That is very interesting because as someone looking for a new scripting
> language, I found tcl very encouraging! I did the same thing as I did for
> Modula-3. I followed the newsgroups and I saw people are using it. I saw
> the releases and saw they are continuing to fix bugs. I don't need
> something new, I need something good. Of course it's important the project
> is alive and well so I don't find something good but dead. I saw tcl has
> native support for sqlite and other interesting features. To me it looks
> very much alive.
>
>> had they put a "new" brand on it ever so often, I would have been more
>> insterested.
>
> Ok but I think at some point people have to break the myth of constant
> change as something favorable.
>
>> in general terms, once you know perl 5.10, would you be more exicet about
>> learning perl 6.0 or 5.10.1 ? I mean, seriously, who gives a damn about a
>> 0.0.1 release anyway?
>
> It's not my view. I'm personally more happy with evolutionary growth. If
> something isn't any good, I don't use it (unless I have to for work!) If
> something is good, it doesn't need major changes, and changes are what
> usually make things worse, not better. I realize my view might not be so
> popular, but this is my view.
>
>> the problem I see a new release would solve, is that you get to fix stuff
>> (like the string broken stuff) that needs fixing, without having to
>> maintain 100% backwards compatibility, this can lead to a cleaner
>> language, like python3000 broke a lot of things, for instance.
>
> I don't know Modula-3 (trying to learn it) enough to say what is broken.
> But I do get nervous when I hear people say backwards compatibility isn't
> important, and stands in the way of the future. For that I say if that is
> really true, a group of people who really understand these things need to
> carefully decide whether the language spec is broken or whether the
> implementation is broken or both. And it has to be addressed based on the
> outcome of that discussion, not by taking the situation too lightly. Just
> to give you some idea of why I am saying this is because most of the
> software I work on is 20 or more years old and I saw the value in having
> experts who understand the purpose and the foundation involved in deciding
> whether a new feature is good or not. Sometimes something looks very good
> but it goes against the core direction. In this case a hard decision has to
> be made to fork the product, or develop a new version. For a language it's
> a very very serious process. If the spec is broken then perhaps it's time
> to develop a new language as Daniel said. If the implementation is broken,
> then sure it should be fixed to conform to the spec. But the main thing is
> I believe especially for languages but for most software it is wrong and a
> mistake to let the implentation drive the specification. You need to have
> qualified good people managing the spec, and the implementation must come
> after that.
>
>>> Personally I see no benefit (indeed I see many disadvantges) to frequent
>>> releases of stable software.
>
>> this is als true, there are disadvantages and I also suffer a little from
>> this. but surely not something we cannot live through, especially if
>> there is some kind of guide (3to4 ?)
>
> I think I understand your point, but I feel this view is looking at the
> language more like an OS. Languages and OS are very different creations. An
> OS has to provide services to get work done. It doesn't necessarily have to
> be pure because the end is more important than the means. But a language is
> all about purity, otherwise all languages converge (indeed that is
> happening!) and there becomes little value in any language since they all
> do pretty much the same thing.
>
> Language has to be about elegance and clarity in expression, and safety in
> implementation so that the intent of the person using the language is
> carried out as he expects, with no side effects or smoke and mirrors. For
> this reason I am very opposed to growing languages without very careful
> study by people who know the history and tradition of the language and give
> it some degree of reverence.
>
>
>>> But I often run backlevel intentionally. Firefox is being updated for
>>> many reasons including security holes, bug fixes, new standards, and
>>> more. If the Modula-3 standard hasn't been updated, what is driving the
>>> need for new release(s)?
>
>> if the language does not evolve, is it bound to die?
>
> Not as far as I am concerned. But I still run programs in SNOBOL4 from
> 1969. YMMV ;-)
>
>> if the standard does not evolve, should one consider it to be dead?
>
> It might be dead, it might not. It all depends on whether the language is
> still useful and people actually use it.
>
>> see c++ for instance, recently, there have been changes to the language.
>> this motivates a lot of tuff: conferences, new compilers, new books, new
>> blogposts, and in general, a lot of "hype"
>
> Right, but C++ has many problems and has popularity and issues Modula-3
> happily doesn't have. If you are trying to compete with a mainstream
> language you'll probably not be satisfied.
>
>> if m3 was hyped a little, perhaps it could gain developers.
>
> I think people who attracted by hype aren't the type of people who will
> appreciate Modula-3.
>
>> by gaining such developers, perhaps more bugs could be removed and
>> features could be added as well (for instance, in the library space,
>> where I see that other language have better, more tested, and easier to
>> use LIbraries, but this is , of course, a subjective declaration, and I
>> don't expect anyone to agree with me).
>
> I think it's important, just like in some other successful but maybe not so
> elegant languages (C++, Java) to make a distinction between language and
> libraries. Free Pascal seems to do this pretty well also. You (usually)
> don't have to change the language spec or implementation to offer usable
> libraries. If you do, it should be done carefully. But the language spec
> should not be changed without much study and thought.
>
>>> It looks like cm3 supports more platforms than I have. I would be
>>> willing to help out (I am not a UNIX developer) any way I could. I have
>>> Solaris Intel and SPARC boxes.
>>
>>that Is wonderful news, I appreciate the offer, I hope the language
>>improves, and your boxes serve the purpose!
>
> I see they already have SPARC Solaris support and I think x86 so I am not
> able to offer anything new, but if I can help I will be glad to.
>
> For me I am having a hard time finding learning materials. I think the
> biggest boost to the language would come not from changing it or making new
> releases, but to put together a really good book on Modula-3 and also
> showing how cm3 implements it. The book should break these two things out
> clearly so it could serve as a reference and guide to Modula-3 itself as
> well as how to use cm3 to code in Modula-3. The main barrier to adoption
> and new fans of Modula-3 is the lack of educational materials. You can
> books on almost any topic on the net, but Modula-3 has almost nothing
> available.
>



-- 
312-444-2124
Skype: f3l.headhunter
Casa: 8043901


From rodney_bates at lcwb.coop  Mon Feb 13 18:31:04 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 13 Feb 2012 11:31:04 -0600
Subject: [M3devel] Think we need a new release.
In-Reply-To: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>
References: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>
Message-ID: <4F3948D8.6000004@lcwb.coop>

This discussion reminds me of my first full-time software job.  The
division manager had a graph on his wall of bugs fixed per month.  He
considered a high fix rate evidence of success.  Some of us sat around
laughing about the incentives that created.

I also recall a wonderfully-written story about an aging programmer
who protected his job against the youth-is-smartest culture by keeping
carefully planned bugs in code that only he could fix.

I really do think the low level of activity in both the language
and its implementations reflects their having been done well to begin
with.  Unfortunately, I don't know how to sell that idea.  A lot of
people think like that division manager.

On 02/13/2012 08:06 AM, vintagecoder at aol.com wrote:
> Hello Daniel,
>
>> Agreed.  I can think of two reasons: adding "must have" stuff to the
>> standard library, and fixing bugs or improving library, compiler, or
>> runtime.  Note that "must have" should probably be evaluated in the
>> context of systems programming, which is what Modula-3 is for.
>
> For myself I tend to be very careful when it comes to "must have" in
> language design. If you feel the language spec is outdated or insufficient,
> then I think it's a dangerous, slippery slope to start adding features to
> the language even if they are a must have, without a standards committee.
> If people are not careful, they can turn a language that was designed well
> into a junk heap before they know it. The threat to the death of a language
> through inappropriate changes is far greater than the threat of death by
> lack of changes.
>
> If people agree the current spec is not sufficient, or wrong, it seems to
> me the first step is to form a language specification committee where the
> language can be carefully controlled- and this has to be from a purist
> view of the language with no concern for implementation and no "baggage"
> other than the existing language spec has to be respected- all the changes
> have to be aligned and harmonious with the original purpose and intentions
> and direction of Modula-3, otherwise what you said later about a new
> language comes into play. Optional features have to be clearly optional-
> extensions to the standard that don't make sense in the core have to be
> clearly deliniated and the spec has to be amended cleanly to separate core
> language, optional extensions, etc. The Ada specification is a good
> document to look at for examples of how to do this.
>
>> Even adding new platforms should not require bumping the version number
>> if it is the existing infrastructure that is being ported.
>
> Agreed.
>
>> There are loads of "greatest next thing" languages out there that you
>> have to re-learn every few releases.  Modula-3 is thankfully not one of
>> them.
>
> Agreed!
>
>> Want new stuff in the language?  Then you want Modula-3+ or Modula-4.
>
> Agreed again!
>
> People are so used to constant turmoil because of Linux. I come from a much
> different background and I value stability and evolution, not revolution.
> New is not necessarily good just like old is not necessarily bad. Good
> things pass the test of time and don't need constant changes. If we are
> talking about changing the underlying implementation without changing the
> language then of course this is fine and should not be held back. My
> concern is about letting the implementation drive the specification- I feel
> that is wrong, dangerous, and should be resisted.
>
> Many languages today are out of control. To grow a language properly is an
> extremely big challenge that has to be taken with a great deal of respect
> and concern.
>


From rcolebur at SCIRES.COM  Mon Feb 13 21:32:10 2012
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 13 Feb 2012 15:32:10 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>


>>For me I am having a hard time finding learning materials. I think the biggest boost to the language would 

Dear Vintage Coder:

The best books I have read on learning Modula-3 are:

1. Systems Programming with Modula-3, ed. Greg Nelson, ISBN 0-13-590464-1

2. Modula-3, Samuel P. Harbison, ISBN 0-13-596396-6

3. Programming in Modula-3, An Introduction in Programming with Style, Laszlo Boszormenyi & Carsten Weich, ISBN 3-540-57912-5

4. Algorithms in Modula-3, Robert Sedgewick, ISBN 0-201-53351-0

Regards,
Randy Coleburn


From dabenavidesd at yahoo.es  Mon Feb 13 21:36:08 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 13 Feb 2012 20:36:08 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <4F3948D8.6000004@lcwb.coop>
Message-ID: <1329165368.51042.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
In any case wondering whether he looses or not, fixing bugs is an important task in all computer programs, that's why ESC and others are important. But if you see those technologies back then were unsuccessful to find much use (because Modula-3 sources had not much RT errors, in Rd/Wr implementations, more in UI libraries), but just because doing annotations that restriction eases the test automation but costs are somehow seen as too high for doing that (even as relaxed in ESC/Java) respect of fixing them in the later stages (something they can compare because if they didn't use that tool they would know how much burden can be for doing that).
In reality people don't code faster but making painfully "slow releases" shows the "importance" of their work (and by that lack of productivity which is an symptom of the Crisis, and one of Objective of ESC).
GN asked why not produce code checkers that spend more computer time (even if they take extra time than night builds), well that's the reason, because they don't want to do that, they want short releases and bug-fixing by hand. 
That's why in the other hand Software Engineering is in Crisis, spending time in bugs fixes rather than writing code is another symptom Software crisis itself..
I will replay Greg Nelson lecture in U of Washington, I assume some principles are applied aside of checkers in systems development like in VHDL and some other tools:
http://www.uwtv.org/video/player.aspx?mediaid=1577083988

Of course there is a possible answer to that question, in the context of another Static checker, but my knowledge of that is it isn't operated  with that other checker or anything else (which was necessary in ESC case). This is if the program makes a big O() function I don't know.

Thanks in advance  



--- El lun, 13/2/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: m3devel at elegosoft.com
> Fecha: lunes, 13 de febrero, 2012 12:31
> This discussion reminds me of my
> first full-time software job.  The
> division manager had a graph on his wall of bugs fixed per
> month.  He
> considered a high fix rate evidence of success.  Some
> of us sat around
> laughing about the incentives that created.
> 
> I also recall a wonderfully-written story about an aging
> programmer
> who protected his job against the youth-is-smartest culture
> by keeping
> carefully planned bugs in code that only he could fix.
> 
> I really do think the low level of activity in both the
> language
> and its implementations reflects their having been done well
> to begin
> with.  Unfortunately, I don't know how to sell that
> idea.  A lot of
> people think like that division manager.
> 
> On 02/13/2012 08:06 AM, vintagecoder at aol.com
> wrote:
> > Hello Daniel,
> >
> >> Agreed.  I can think of two reasons: adding
> "must have" stuff to the
> >> standard library, and fixing bugs or improving
> library, compiler, or
> >> runtime.  Note that "must have" should
> probably be evaluated in the
> >> context of systems programming, which is what
> Modula-3 is for.
> >
> > For myself I tend to be very careful when it comes to
> "must have" in
> > language design. If you feel the language spec is
> outdated or insufficient,
> > then I think it's a dangerous, slippery slope to start
> adding features to
> > the language even if they are a must have, without a
> standards committee.
> > If people are not careful, they can turn a language
> that was designed well
> > into a junk heap before they know it. The threat to the
> death of a language
> > through inappropriate changes is far greater than the
> threat of death by
> > lack of changes.
> >
> > If people agree the current spec is not sufficient, or
> wrong, it seems to
> > me the first step is to form a language specification
> committee where the
> > language can be carefully controlled- and this has to
> be from a purist
> > view of the language with no concern for implementation
> and no "baggage"
> > other than the existing language spec has to be
> respected- all the changes
> > have to be aligned and harmonious with the original
> purpose and intentions
> > and direction of Modula-3, otherwise what you said
> later about a new
> > language comes into play. Optional features have to be
> clearly optional-
> > extensions to the standard that don't make sense in the
> core have to be
> > clearly deliniated and the spec has to be amended
> cleanly to separate core
> > language, optional extensions, etc. The Ada
> specification is a good
> > document to look at for examples of how to do this.
> >
> >> Even adding new platforms should not require
> bumping the version number
> >> if it is the existing infrastructure that is being
> ported.
> >
> > Agreed.
> >
> >> There are loads of "greatest next thing" languages
> out there that you
> >> have to re-learn every few releases.  Modula-3
> is thankfully not one of
> >> them.
> >
> > Agreed!
> >
> >> Want new stuff in the language?  Then you want
> Modula-3+ or Modula-4.
> >
> > Agreed again!
> >
> > People are so used to constant turmoil because of
> Linux. I come from a much
> > different background and I value stability and
> evolution, not revolution.
> > New is not necessarily good just like old is not
> necessarily bad. Good
> > things pass the test of time and don't need constant
> changes. If we are
> > talking about changing the underlying implementation
> without changing the
> > language then of course this is fine and should not be
> held back. My
> > concern is about letting the implementation drive the
> specification- I feel
> > that is wrong, dangerous, and should be resisted.
> >
> > Many languages today are out of control. To grow a
> language properly is an
> > extremely big challenge that has to be taken with a
> great deal of respect
> > and concern.
> >
> 


From lemming at henning-thielemann.de  Mon Feb 13 22:03:12 2012
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 13 Feb 2012 22:03:12 +0100 (CET)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
	<D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>
Message-ID: <alpine.DEB.2.00.1202132200360.16675@anubis.informatik.uni-halle.de>


On Mon, 13 Feb 2012, Coleburn, Randy wrote:

> 1. Systems Programming with Modula-3, ed. Greg Nelson, ISBN 0-13-590464-1
>
> 2. Modula-3, Samuel P. Harbison, ISBN 0-13-596396-6
>
> 3. Programming in Modula-3, An Introduction in Programming with Style, Laszlo Boszormenyi & Carsten Weich, ISBN 3-540-57912-5
>
> 4. Algorithms in Modula-3, Robert Sedgewick, ISBN 0-201-53351-0

I must say, that I was disappointed about the Sedgewick book, because it 
does not use any Modula-3 feature, no enumerations, no NEW, but instead 
global variables. Thus nothing you can learn good style Modula-3 
programming from.


From mika at async.caltech.edu  Mon Feb 13 22:28:43 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Mon, 13 Feb 2012 13:28:43 -0800
Subject: [M3devel] Think we need a new release.
In-Reply-To: <alpine.DEB.2.00.1202132200360.16675@anubis.informatik.uni-halle.de>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
	<D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>
	<alpine.DEB.2.00.1202132200360.16675@anubis.informatik.uni-halle.de>
Message-ID: <20120213212843.80A2F1A205B@async.async.caltech.edu>


I must say I have found few resources better for learning decent software
engineering techniques than just reading some of the sources from SRC.
The Modula-3 library (libm3) in particular.

    Mika


Henning Thielemann writes:
>
>On Mon, 13 Feb 2012, Coleburn, Randy wrote:
>
>> 1. Systems Programming with Modula-3, ed. Greg Nelson, ISBN 0-13-590464-1
>>
>> 2. Modula-3, Samuel P. Harbison, ISBN 0-13-596396-6
>>
>> 3. Programming in Modula-3, An Introduction in Programming with Style, Laszlo Boszormenyi & Carsten Weich, ISBN 3-540-57912-5
>>
>> 4. Algorithms in Modula-3, Robert Sedgewick, ISBN 0-201-53351-0
>
>I must say, that I was disappointed about the Sedgewick book, because it 
>does not use any Modula-3 feature, no enumerations, no NEW, but instead 
>global variables. Thus nothing you can learn good style Modula-3 
>programming from.


From dabenavidesd at yahoo.es  Mon Feb 13 22:26:37 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 13 Feb 2012 21:26:37 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <alpine.DEB.2.00.1202132200360.16675@anubis.informatik.uni-halle.de>
Message-ID: <1329168397.15682.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
in defense of the author's work I have read that someones () wanted a library of Algorithm Animations for accompanying the book and DEC-SRC distribution or so.
Since the Algorithm animations festivals held in DEC-SRC were before 1994, and some animations done before were decommissioned some time ago, it remains uncertain how many animations were done with Modula-3 at DEC-SRC:
http://www.internotesstrategy.com/softwareengg.php#

Perhpas the most advanced are there.
Thanks in advance 
 

--- El lun, 13/2/12, Henning Thielemann <lemming at henning-thielemann.de> escribi?:

> De: Henning Thielemann <lemming at henning-thielemann.de>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: "Coleburn, Randy" <rcolebur at SCIRES.COM>
> CC: "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: lunes, 13 de febrero, 2012 16:03
> 
> On Mon, 13 Feb 2012, Coleburn, Randy wrote:
> 
> > 1. Systems Programming with Modula-3, ed. Greg Nelson,
> ISBN 0-13-590464-1
> >
> > 2. Modula-3, Samuel P. Harbison, ISBN 0-13-596396-6
> >
> > 3. Programming in Modula-3, An Introduction in
> Programming with Style, Laszlo Boszormenyi & Carsten
> Weich, ISBN 3-540-57912-5
> >
> > 4. Algorithms in Modula-3, Robert Sedgewick, ISBN
> 0-201-53351-0
> 
> I must say, that I was disappointed about the Sedgewick
> book, because it 
> does not use any Modula-3 feature, no enumerations, no NEW,
> but instead 
> global variables. Thus nothing you can learn good style
> Modula-3 
> programming from.
> 


From jay.krell at cornell.edu  Tue Feb 14 02:21:23 2012
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 14 Feb 2012 01:21:23 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <4F3948D8.6000004@lcwb.coop>
References: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>,
	<4F3948D8.6000004@lcwb.coop>
Message-ID: <COL101-W552255EAA304C6746012F7E67C0@phx.gbl>


> I really do think the low level of activity in both the language
> and its implementations reflects their having been done well to begin
> with.  Unfortunately, I don't know how to sell that idea.  A lot of
> people think like that division manager.
I agree.But there is still work to do.Mainly increase portability and decrease platform-dependentness.    backend: such as via the existing M3x86, or LLVM     library: cooperative suspend   And/or at least update to newer gcc.  Improve debugging with stock gdb.  A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...  - Jay > Date: Mon, 13 Feb 2012 11:31:04 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Think we need a new release.
> 
> This discussion reminds me of my first full-time software job.  The
> division manager had a graph on his wall of bugs fixed per month.  He
> considered a high fix rate evidence of success.  Some of us sat around
> laughing about the incentives that created.
> 
> I also recall a wonderfully-written story about an aging programmer
> who protected his job against the youth-is-smartest culture by keeping
> carefully planned bugs in code that only he could fix.
> 
> I really do think the low level of activity in both the language
> and its implementations reflects their having been done well to begin
> with.  Unfortunately, I don't know how to sell that idea.  A lot of
> people think like that division manager.
> 
> On 02/13/2012 08:06 AM, vintagecoder at aol.com wrote:
> > Hello Daniel,
> >
> >> Agreed.  I can think of two reasons: adding "must have" stuff to the
> >> standard library, and fixing bugs or improving library, compiler, or
> >> runtime.  Note that "must have" should probably be evaluated in the
> >> context of systems programming, which is what Modula-3 is for.
> >
> > For myself I tend to be very careful when it comes to "must have" in
> > language design. If you feel the language spec is outdated or insufficient,
> > then I think it's a dangerous, slippery slope to start adding features to
> > the language even if they are a must have, without a standards committee.
> > If people are not careful, they can turn a language that was designed well
> > into a junk heap before they know it. The threat to the death of a language
> > through inappropriate changes is far greater than the threat of death by
> > lack of changes.
> >
> > If people agree the current spec is not sufficient, or wrong, it seems to
> > me the first step is to form a language specification committee where the
> > language can be carefully controlled- and this has to be from a purist
> > view of the language with no concern for implementation and no "baggage"
> > other than the existing language spec has to be respected- all the changes
> > have to be aligned and harmonious with the original purpose and intentions
> > and direction of Modula-3, otherwise what you said later about a new
> > language comes into play. Optional features have to be clearly optional-
> > extensions to the standard that don't make sense in the core have to be
> > clearly deliniated and the spec has to be amended cleanly to separate core
> > language, optional extensions, etc. The Ada specification is a good
> > document to look at for examples of how to do this.
> >
> >> Even adding new platforms should not require bumping the version number
> >> if it is the existing infrastructure that is being ported.
> >
> > Agreed.
> >
> >> There are loads of "greatest next thing" languages out there that you
> >> have to re-learn every few releases.  Modula-3 is thankfully not one of
> >> them.
> >
> > Agreed!
> >
> >> Want new stuff in the language?  Then you want Modula-3+ or Modula-4.
> >
> > Agreed again!
> >
> > People are so used to constant turmoil because of Linux. I come from a much
> > different background and I value stability and evolution, not revolution.
> > New is not necessarily good just like old is not necessarily bad. Good
> > things pass the test of time and don't need constant changes. If we are
> > talking about changing the underlying implementation without changing the
> > language then of course this is fine and should not be held back. My
> > concern is about letting the implementation drive the specification- I feel
> > that is wrong, dangerous, and should be resisted.
> >
> > Many languages today are out of control. To grow a language properly is an
> > extremely big challenge that has to be taken with a great deal of respect
> > and concern.
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120214/8a7f85a2/attachment-0001.html>

From hendrik at topoi.pooq.com  Tue Feb 14 03:59:21 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 13 Feb 2012 21:59:21 -0500
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <289840BF-8FA7-4CD8-9908-9A65B4717F3F@gmail.com>
References: <20120209165624.GA13717@topoi.pooq.com>
	<289840BF-8FA7-4CD8-9908-9A65B4717F3F@gmail.com>
Message-ID: <20120214025921.GB11163@topoi.pooq.com>

On Thu, Feb 09, 2012 at 09:08:37PM -0500, Antony Hosking wrote:
> It?s supposed to warn for unrecognized pragma.

And I might have missed the warning.

Anyway, once I got the case right for ASSERT, I was able to finish 
debugging the program and get it running.  It's a rudimentary program 
that reads several similar text files and produces a variorum edition
-- one that says which lines all share, and which lines are now shared.
It's no limited to two files, like diff, and I can get it to produce 
useful output, unlike the mdiff I got from the FSF website and from a 
debian package.

It still needs cleaning up to be generally useful.  It's rather tuned 
to the particular files I'm dealing with.

-- hendrik


From vintagecoder at aol.com  Tue Feb 14 12:10:16 2012
From: vintagecoder at aol.com (vintagecoder at aol.com)
Date: Tue, 14 Feb 2012 11:10:16 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>
Message-ID: <201202141110.q1EBAK0i003441@imr-da02.mx.aol.com>

Thank you Randy, Henning, Mika for the notes on educational materials.

To Jay, don't forget Solaris builds work better with a non-gcc compiler. I
would hope cm3 would never require gcc or use gcc-specific extensions or it
will cause problems (with GPL3 in the newer versions of gcc) and also on
platforms where gcc isn't the best choice for various reasons.


From dragisha at m3w.org  Tue Feb 14 12:20:52 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 14 Feb 2012 12:20:52 +0100
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <COL101-W552255EAA304C6746012F7E67C0@phx.gbl>
References: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>,
	<4F3948D8.6000004@lcwb.coop>
	<COL101-W552255EAA304C6746012F7E67C0@phx.gbl>
Message-ID: <4DE3D685-C8B6-42E0-B4FA-0BA68594292E@m3w.org>

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).

With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).

Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?

On Feb 14, 2012, at 2:21 AM, Jay K wrote:

> A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120214/45feabb7/attachment-0001.html>

From dabenavidesd at yahoo.es  Tue Feb 14 20:44:59 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 14 Feb 2012 19:44:59 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <4DE3D685-C8B6-42E0-B4FA-0BA68594292E@m3w.org>
Message-ID: <1329248699.74657.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
According to this it might be not p 20
ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf

In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829

Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.

Thanks in advance and please make any comments you may have

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 06:20

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
On Feb 14, 2012, at 2:21 AM, Jay K wrote:
A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120214/cbc375f3/attachment-0001.html>

From jay.krell at cornell.edu  Wed Feb 15 01:23:58 2012
From: jay.krell at cornell.edu (Jay)
Date: Tue, 14 Feb 2012 16:23:58 -0800
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329248699.74657.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <1329248699.74657.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <5CF3B8E7-21C6-4CA7-89C5-B0542BFF2492@gmail.com>

You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...

 - Jay (phone)

On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> According to this it might be not p 20
> ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf
> 
> In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
> http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829
> 
> Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.
> 
> Thanks in advance and please make any comments you may have
> 
> --- El mar, 14/2/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] Think we need a new release. C target
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 14 de febrero, 2012 06:20
> 
> I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
> 
> With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
> 
> Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
> 
> On Feb 14, 2012, at 2:21 AM, Jay K wrote:
> 
>> A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120214/638d1942/attachment-0001.html>

From dabenavidesd at yahoo.es  Wed Feb 15 20:10:56 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 15 Feb 2012 19:10:56 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <5CF3B8E7-21C6-4CA7-89C5-B0542BFF2492@gmail.com>
Message-ID: <1329333056.64488.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
doing by that method do I have compatibility with something else, meaning C? CM JVM? Yes, it achieved it through high compatibility using C language so you could migrate your Java code via CM JVM (without JNI, a kind of nightmare) to Modula-3 and C, now if we generate C, what would be gaining in terms of compatibility, gaining compatibility with those C Compilers, who cares that, just people writing C Code, if they don't or don't want to code in Modula-3, will be attracted by that offer? In CM JVM case it might be interested to migrate to C, but they need a good RT support, they don't need compilers to C. They have many ones already.
Now, if is you the one who want to migrate to C platforms well, Modula-3 can directly interface with C.
I wanted to make clear that my route will be Obliq, since the new real intermediate language becoming mainstream is JavaScript, and certainly the dear good M3 friend new that if it not were by one hair Obliq would be become the standard of the web. Now, why would we want to make a non-standard thing a product of our catalog, well, I pass that one into you, what is the main difference between C and Obliq if I tell you that FailSafe-C is project built on a Obliq JVM product?
Please have a look at DDJ about the "The JVM as a Language Farm Club" :
http://app.reg.techweb.com/e/es.aspx?s=2150&e=27044&elq=66547688035b4bc99ab7612af687575

Thanks in advance

--- El mar, 14/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay K" <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 19:23

You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...

?- Jay (phone)
On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
According to this it might be not p 20
ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf

In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829

Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.

Thanks in advance and please make any comments you may have

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we
 need a new release. C target
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 06:20

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
On Feb 14, 2012, at 2:21 AM, Jay K wrote:
A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120215/93ba8de9/attachment-0001.html>

From jay.krell at cornell.edu  Wed Feb 15 20:43:47 2012
From: jay.krell at cornell.edu (Jay)
Date: Wed, 15 Feb 2012 11:43:47 -0800
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329333056.64488.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1329333056.64488.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <FDD14D29-1813-47B5-ADB1-2BB1BF25BD57@gmail.com>

No. None of this is the point, if it even makes sense.

The point is to use C as portable target.

If you want to run Obliq in a browser, compile it to JavaScript, possibly via something else, e.g. Java.

JavaScript isn't such a bad language though. The main difference among most languages is amount of static checking. People translate Java to JavaScript partly to get that static checking.

A C target would open up many old and new targets. And help debugging a lot, esp. on systems w/o m3gdb -- there are several.

A Java target and C# target would also be interesting.

 - Jay (phone)

On Feb 15, 2012, at 11:10 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> doing by that method do I have compatibility with something else, meaning C? CM JVM? Yes, it achieved it through high compatibility using C language so you could migrate your Java code via CM JVM (without JNI, a kind of nightmare) to Modula-3 and C, now if we generate C, what would be gaining in terms of compatibility, gaining compatibility with those C Compilers, who cares that, just people writing C Code, if they don't or don't want to code in Modula-3, will be attracted by that offer? In CM JVM case it might be interested to migrate to C, but they need a good RT support, they don't need compilers to C. They have many ones already.
> Now, if is you the one who want to migrate to C platforms well, Modula-3 can directly interface with C.
> I wanted to make clear that my route will be Obliq, since the new real intermediate language becoming mainstream is JavaScript, and certainly the dear good M3 friend new that if it not were by one hair Obliq would be become the standard of the web. Now, why would we want to make a non-standard thing a product of our catalog, well, I pass that one into you, what is the main difference between C and Obliq if I tell you that FailSafe-C is project built on a Obliq JVM product?
> Please have a look at DDJ about the "The JVM as a Language Farm Club" :
> http://app.reg.techweb.com/e/es.aspx?s=2150&e=27044&elq=66547688035b4bc99ab7612af687575
> 
> Thanks in advance
> 
> --- El mar, 14/2/12, Jay <jay.krell at cornell.edu> escribi?:
> 
> De: Jay <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] Think we need a new release. C target
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "Jay K" <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 14 de febrero, 2012 19:23
> 
> You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...
> 
>  - Jay (phone)
> 
> On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:
> 
>> Hi all:
>> According to this it might be not p 20
>> ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf
>> 
>> In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
>> http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829
>> 
>> Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.
>> 
>> Thanks in advance and please make any comments you may have
>> 
>> --- El mar, 14/2/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
>> 
>> De: Dragi?a Duri? <dragisha at m3w.org>
>> Asunto: Re: [M3devel] Think we need a new release. C target
>> Para: "Jay K" <jay.krell at cornell.edu>
>> CC: "m3devel" <m3devel at elegosoft.com>
>> Fecha: martes, 14 de febrero, 2012 06:20
>> 
>> I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
>> 
>> With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
>> 
>> Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
>> 
>> On Feb 14, 2012, at 2:21 AM, Jay K wrote:
>> 
>>> A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120215/73ab29f6/attachment-0001.html>

From dabenavidesd at yahoo.es  Wed Feb 15 20:57:36 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 15 Feb 2012 19:57:36 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <FDD14D29-1813-47B5-ADB1-2BB1BF25BD57@gmail.com>
Message-ID: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.
If you want to code the RT for C, I don't know that well but Olivetti did that just as you say, but what we want is to be a member of The Language farm Club (aren't we).
If you want to make compilers to C or assembly, that's good but the it has been done in CLEF via M3CG->CLEF, CLEF compiler is written in java, nice!
I mean repeating this over and over doesn't make sense for me, what's the point here? The only thing left is Obliq to code for.
Thanks in advance

--- El mi?, 15/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay" <jay.krell at cornell.edu>, "Jay K" <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 15 de febrero, 2012 14:43

No. None of this is the point, if it even makes sense.
The point is to use C as portable target.
If you want to run Obliq in a browser, compile it to JavaScript, possibly via something else, e.g. Java.
JavaScript isn't such a bad language though. The main difference among most languages is amount of static checking. People translate Java to JavaScript partly to get that static checking.
A C target would open up many old and new targets. And help debugging a lot, esp. on systems w/o m3gdb -- there are several.
A Java target and C# target would also be interesting.
?- Jay (phone)
On Feb 15, 2012, at 11:10 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
doing by that method do I have compatibility with something else, meaning C? CM JVM? Yes, it achieved it through high compatibility using C language so you could migrate your Java code via CM JVM (without JNI, a kind of nightmare) to Modula-3 and C, now if we generate C, what would be gaining in terms of compatibility, gaining compatibility with those C Compilers, who cares that, just people writing C Code, if they don't or don't want to code in Modula-3, will be attracted by that offer? In CM JVM case it might be interested to migrate to C, but they need a good RT support, they don't need compilers to C. They have many ones already.
Now, if is you the one who want to migrate to C platforms well, Modula-3 can directly interface with C.
I wanted to make clear that my route will be Obliq, since the new real intermediate language becoming
 mainstream is JavaScript, and certainly the dear good M3 friend new that if it not were by one hair Obliq would be become the standard of the web. Now, why would we want to make a non-standard thing a product of our catalog, well, I pass that one into you, what is the main difference between C and Obliq if I tell you that FailSafe-C is project built on a Obliq JVM product?
Please have a look at DDJ about the "The JVM as a Language Farm Club" :
http://app.reg.techweb.com/e/es.aspx?s=2150&e=27044&elq=66547688035b4bc99ab7612af687575

Thanks in advance

--- El mar, 14/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay K"
 <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 19:23

You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...

?- Jay (phone)
On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
According to this it might be not p 20
ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf

In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829

Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.

Thanks in advance and please make any comments you may have

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we
 need a new release. C target
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 06:20

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
On Feb 14, 2012, at 2:21 AM, Jay K wrote:
A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120215/7a30d4d1/attachment-0001.html>

From dabenavidesd at yahoo.es  Wed Feb 15 23:10:47 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 15 Feb 2012 22:10:47 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <FDD14D29-1813-47B5-ADB1-2BB1BF25BD57@gmail.com>
Message-ID: <1329343847.90050.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
think about not only back-ports, the only work usable of a C backend would be optimization for it, though it's hard we could make a case for that, see:
http://www.cs.tufts.edu/~nr/cs257/archive/craig-chambers/millstein-pldi03-draft.ps

I know of one work of C#-like compiler with Modula-3 constructs in lcc:
http://research.microsoft.com/pubs/70004/tr-2003-32.pdf

OK, maybe that would optimize hard Modula-3 programs I like that approach, since it would make a case for old (slower platforms) and of course of Big programs in newer machines.
In the Olivetti Modula-3, the speed of the backend was the main issue of not releasing it.
Thanks in advance


--- El mi?, 15/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay" <jay.krell at cornell.edu>, "Jay K" <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 15 de febrero, 2012 14:43

No. None of this is the point, if it even makes sense.
The point is to use C as portable target.
If you want to run Obliq in a browser, compile it to JavaScript, possibly via something else, e.g. Java.
JavaScript isn't such a bad language though. The main difference among most languages is amount of static checking. People translate Java to JavaScript partly to get that static checking.
A C target would open up many old and new targets. And help debugging a lot, esp. on systems w/o m3gdb -- there are several.
A Java target and C# target would also be interesting.
?- Jay (phone)
On Feb 15, 2012, at 11:10 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
doing by that method do I have compatibility with something else, meaning C? CM JVM? Yes, it achieved it through high compatibility using C language so you could migrate your Java code via CM JVM (without JNI, a kind of nightmare) to Modula-3 and C, now if we generate C, what would be gaining in terms of compatibility, gaining compatibility with those C Compilers, who cares that, just people writing C Code, if they don't or don't want to code in Modula-3, will be attracted by that offer? In CM JVM case it might be interested to migrate to C, but they need a good RT support, they don't need compilers to C. They have many ones already.
Now, if is you the one who want to migrate to C platforms well, Modula-3 can directly interface with C.
I wanted to make clear that my route will be Obliq, since the new real intermediate language becoming
 mainstream is JavaScript, and certainly the dear good M3 friend new that if it not were by one hair Obliq would be become the standard of the web. Now, why would we want to make a non-standard thing a product of our catalog, well, I pass that one into you, what is the main difference between C and Obliq if I tell you that FailSafe-C is project built on a Obliq JVM product?
Please have a look at DDJ about the "The JVM as a Language Farm Club" :
http://app.reg.techweb.com/e/es.aspx?s=2150&e=27044&elq=66547688035b4bc99ab7612af687575

Thanks in advance

--- El mar, 14/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay K"
 <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 19:23

You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...

?- Jay (phone)
On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
According to this it might be not p 20
ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf

In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829

Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.

Thanks in advance and please make any comments you may have

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we
 need a new release. C target
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 06:20

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
On Feb 14, 2012, at 2:21 AM, Jay K wrote:
A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120215/cad18a88/attachment-0001.html>

From dragisha at m3w.org  Fri Feb 17 12:29:58 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 17 Feb 2012 12:29:58 +0100
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <B4107FAB-6385-480C-889F-BB904CDF4754@m3w.org>

To port to JVM or Javascript, you have to throw through the window a lot of what Modula-3 is. You will get, in best case, part of Modula-3.

On the other side, targeting to C (or C++) and losing object model from sight (while debugging), ie losing or distorting, also looks like an horrible side effect to me.

It looks like the best direction to concentrate effort is current GCC (a lot of platforms) and LLVM ((almost) new kid on the block with many good promises). The best thing about LLVM target is - IM is standardized and fully documented. Since we all know what pain is tagging along behind GCC IM (thanks to RMS losing licensing battle to SRC), LLVM looks like a promise of future freedom for Modula-3. Maye some day we will not be traumatized by every major (and most minor) GCC releases.

BTW, freepascal has it's own backend infrastructure. Maybe worth a try.

dd


On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120217/8d3ed464/attachment-0001.html>

From dabenavidesd at yahoo.es  Fri Feb 17 13:26:17 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 17 Feb 2012 12:26:17 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <B4107FAB-6385-480C-889F-BB904CDF4754@m3w.org>
Message-ID: <1329481577.26677.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
I don't think that's the case, Java has a JNI and it can work, but CM JVM is just a lot safer and easier to use, direct access to C code of the RT and you know what is better than that out there, in case of an attack? Modula-3 + Java seems the combination to win for me, ESC for both, I mean and what else do you need?

The point of what is Modula-3 a Systems Programming Language doesn't change that it is easier to deal with UNSAFE code, still we could add a keyword for say PROVED to allow the back-end check only for correct optimizations on it or to check UNSAFE code allowed to do so in either Java or Modula-3 or C. I don't care too much about PROVED or UNSAFE modules but more normal code and that's where Modula-3 could be helped by JVM dynamic verification (that said, it is not the best thing to do because this requires a lot of smart checking, I can give you an example of a program in Java that still manages to corrupt any class file in the cd, fooling the JVM) without JVM doing that much. That said compiler verification is much harder than normal checking, still there is research to allow one to do so.
Thanks in advance

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay" <jay.krell at cornell.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 06:29

To port to JVM or Javascript, you have to throw through the window a lot of what Modula-3 is. You will get, in best case, part of Modula-3.
On the other side, targeting to C (or C++) and losing object model from sight (while debugging), ie losing or distorting, also looks like an horrible side effect to me.
It looks like the best direction to concentrate effort is current GCC (a lot of platforms) and LLVM ((almost) new kid on the block with many good promises). The best thing about LLVM target is - IM is standardized and fully documented. Since we all know what pain is tagging along behind GCC IM (thanks to RMS losing licensing battle to SRC), LLVM looks like a promise of future freedom for Modula-3. Maye some day we will not be traumatized by every major (and most minor) GCC releases.
BTW, freepascal has it's own backend infrastructure. Maybe worth a try.
dd

On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides D. wrote:
Hi all:
The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120217/2a2e48a3/attachment-0001.html>

From rodney_bates at lcwb.coop  Fri Feb 17 21:46:53 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 17 Feb 2012 14:46:53 -0600
Subject: [M3devel] An awkward interaction of language properties
Message-ID: <4F3EBCBD.2030802@lcwb.coop>

So, I have the following mutually recursive types:
----------------------------------------------------------------------------
DataStruct.i3:
INTERFACE DataStruct
; TYPE T = RECORD
              Relatives : ListRef
            (* Other fields. *)
            END
; TYPE ListRef = REF List
; TYPE List = ARRAY OF T
; END DataStruct
.
----------------------------------------------------------------------------

This works fine in Modula-3, if all three types are declared in the same scope.

Now suppose instead of builtin type constructor ARRAY OF, I need my set of
relatives to be an instantiation of a complex container data structure,
with a generic parameter for the type of its elements:

----------------------------------------------------------------------------
Container.ig:
GENERIC INTERFACE Container ( Elem )
(* Where Elem exports Elem.T, a type other than an open array type. *)
; TYPE T <: ROOT (* A container of Elem.T. *)
; PROCEDURE Get ( C : T ; Selector : INTEGER ; VAR Element : Elem . T )
; END Container
.
----------------------------------------------------------------------------
INTERFACE DTContainer = Container(DataStruct2) END DTContainer .
----------------------------------------------------------------------------
DataStruct2.i3:
INTERFACE DataStruct2
; IMPORT DTContainer
; TYPE Node = RECORD
                 Relatives : DTContainer . T
               (* Other fields. *)
               END
; END DataStruct2
.
----------------------------------------------------------------------------

This has cyclic imports and won't compile.  (A generic actual interface is
implicitly an import, which is made explicit by the rewrite rule for an
instantiation, 2.5.5)

The rule that recursive types have to be in the same scope and the fact that
an instantiation is a separate interface are irreconcilable.

The only way I can think of is to make the Relatives field be a REFANY,
and not import DTContainer into DataStruct2.  This loses static safety,
but at least it will be replaced by dynamic safety, at the cost of
runtime narrow checks every time I use Relatives.

Of course, I can cut down some on the frequency of RT type checks by grouping
nearby accesses to a Relatives field with a TYPECASE or assignment to a
variable (declared inside a module) of type DTContainer.T.

Anybody have any other thoughts on how to handle this?





From lemming at henning-thielemann.de  Fri Feb 17 21:57:13 2012
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 17 Feb 2012 21:57:13 +0100 (CET)
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <4F3EBCBD.2030802@lcwb.coop>
References: <4F3EBCBD.2030802@lcwb.coop>
Message-ID: <alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>


On Fri, 17 Feb 2012, Rodney M. Bates wrote:

> The only way I can think of is to make the Relatives field be a REFANY,
> and not import DTContainer into DataStruct2.  This loses static safety,
> but at least it will be replaced by dynamic safety, at the cost of
> runtime narrow checks every time I use Relatives.

Some REVEAL tricks instead of REFANY?


From rcolebur at SCIRES.COM  Fri Feb 17 23:51:06 2012
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 17 Feb 2012 17:51:06 -0500
Subject: [M3devel] compile errors in m3front's Formal.m3
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>

I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.

new source -> compiling Formal.m3
"..\src\values\Formal.m3", line 353: parameter not specified (traced)
"..\src\values\Formal.m3", line 432: unknown parameter (rhs)
"..\src\values\Formal.m3", line 432: incompatible types (traced)
"..\src\values\Formal.m3", line 437: parameter not specified (traced)
"..\src\values\Formal.m3", line 492: unknown parameter (rhs)
"..\src\values\Formal.m3", line 492: incompatible types (traced)
"..\src\values\Formal.m3", line 498: parameter not specified (traced)
"..\src\values\Formal.m3", line 512: unknown parameter (rhs)
"..\src\values\Formal.m3", line 512: incompatible types (traced)
"..\src\values\Formal.m3", line 515: parameter not specified (traced)
"..\src\values\Formal.m3", line 530: unknown parameter (rhs)
"..\src\values\Formal.m3", line 530: incompatible types (traced)
"..\src\values\Formal.m3", line 536: parameter not specified (traced)
"..\src\values\Formal.m3", line 552: unknown parameter (rhs)
"..\src\values\Formal.m3", line 552: incompatible types (traced)
"..\src\values\Formal.m3", line 555: parameter not specified (traced)
"..\src\values\Formal.m3", line 608: unknown parameter (rhs)
"..\src\values\Formal.m3", line 608: incompatible types (traced)
"..\src\values\Formal.m3", line 611: parameter not specified (traced)
"..\src\values\Formal.m3", line 627: unknown parameter (rhs)
"..\src\values\Formal.m3", line 627: incompatible types (traced)
"..\src\values\Formal.m3", line 630: parameter not specified (traced)
"..\src\values\Formal.m3", line 649: unknown parameter (rhs)
"..\src\values\Formal.m3", line 649: incompatible types (traced)
"..\src\values\Formal.m3", line 656: parameter not specified (traced)
25 errors encountered

Apparently, someone has checked in a change to Formal.m3 that
has compile errors.

Can whoever made the change please take a look and correct the problem.

Thanks,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120217/9e38c505/attachment-0001.html>

From mika at async.caltech.edu  Sat Feb 18 06:37:13 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Fri, 17 Feb 2012 21:37:13 -0800
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>
References: <4F3EBCBD.2030802@lcwb.coop>
	<alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>
Message-ID: <20120218053713.890011A205B@async.async.caltech.edu>


Yes I should think if you declare the Container type in one interface,
to be <: ROOT you can then refer to that from the other interfaces.
Then you REVEAL the actual details in another interface that's not
imported by the others but only where it is needed.  Both the interfaces
you have can be generic.

    Mika


Henning Thielemann writes:
>
>On Fri, 17 Feb 2012, Rodney M. Bates wrote:
>
>> The only way I can think of is to make the Relatives field be a REFANY,
>> and not import DTContainer into DataStruct2.  This loses static safety,
>> but at least it will be replaced by dynamic safety, at the cost of
>> runtime narrow checks every time I use Relatives.
>
>Some REVEAL tricks instead of REFANY?


From dabenavidesd at yahoo.es  Sat Feb 18 15:24:43 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 18 Feb 2012 14:24:43 +0000 (GMT)
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>
Message-ID: <1329575083.11740.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
I think you can't "rebuild" but bootstrap with a step 0 bootstrap compiler and then proceed.
Thus you will get new compiler to build itself but not old building new. Hope it helps.

Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 17:51


 
 




I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.
?
new source -> compiling Formal.m3

"..\src\values\Formal.m3", line 353: parameter not specified (traced)

"..\src\values\Formal.m3", line 432: unknown parameter (rhs)

"..\src\values\Formal.m3", line 432: incompatible types (traced)

"..\src\values\Formal.m3", line 437: parameter not specified (traced)

"..\src\values\Formal.m3", line 492: unknown parameter (rhs)

"..\src\values\Formal.m3", line 492: incompatible types (traced)

"..\src\values\Formal.m3", line 498: parameter not specified (traced)

"..\src\values\Formal.m3", line 512: unknown parameter (rhs)

"..\src\values\Formal.m3", line 512: incompatible types (traced)

"..\src\values\Formal.m3", line 515: parameter not specified (traced)

"..\src\values\Formal.m3", line 530: unknown parameter (rhs)

"..\src\values\Formal.m3", line 530: incompatible types (traced)

"..\src\values\Formal.m3", line 536: parameter not specified (traced)

"..\src\values\Formal.m3", line 552: unknown parameter (rhs)

"..\src\values\Formal.m3", line 552: incompatible types (traced)

"..\src\values\Formal.m3", line 555: parameter not specified (traced)

"..\src\values\Formal.m3", line 608: unknown parameter (rhs)

"..\src\values\Formal.m3", line 608: incompatible types (traced)

"..\src\values\Formal.m3", line 611: parameter not specified (traced)

"..\src\values\Formal.m3", line 627: unknown parameter (rhs)

"..\src\values\Formal.m3", line 627: incompatible types (traced)

"..\src\values\Formal.m3", line 630: parameter not specified (traced)

"..\src\values\Formal.m3", line 649: unknown parameter (rhs)

"..\src\values\Formal.m3", line 649: incompatible types (traced)

"..\src\values\Formal.m3", line 656: parameter not specified (traced)

25 errors encountered
?
Apparently, someone has checked in a change to Formal.m3 that
has compile errors.
?
Can whoever made the change please take a look and correct the problem.
?
Thanks,
Randy Coleburn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120218/283df375/attachment-0001.html>

From rcolebur at SCIRES.COM  Sat Feb 18 21:05:58 2012
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 18 Feb 2012 15:05:58 -0500
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <1329575083.11740.YahooMailClassic@web29704.mail.ird.yahoo.com>
References: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>
	<1329575083.11740.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6034A68D41C@atlex02-srv>

Daniel:

I do not understand your post.

I am following the same procedure and script that I've used for years with success.

It appears that someone has checked in code that doesn't compile, so the Formal.m3 file needs correction to make it compile.

Regards,
Randy Coleburn

From: Daniel Alejandro Benavides D.
Sent: Saturday, February 18, 2012 9:25 AM
To: m3devel; Coleburn, Randy
Subject: Re: [M3devel] compile errors in m3front's Formal.m3

Hi all:
I think you can't "rebuild" but bootstrap with a step 0 bootstrap compiler and then proceed.
Thus you will get new compiler to build itself but not old building new. Hope it helps.

Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>>
Fecha: viernes, 17 de febrero, 2012 17:51
I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.

new source -> compiling Formal.m3
"..\src\values\Formal.m3", line 353: parameter not specified (traced)
"..\src\values\Formal.m3", line 432: unknown parameter (rhs)
"..\src\values\Formal.m3", line 432: incompatible types (traced)
"..\src\values\Formal.m3", line 437: parameter not specified (traced)
"..\src\values\Formal.m3", line 492: unknown parameter (rhs)
"..\src\values\Formal.m3", line 492: incompatible types (traced)
"..\src\values\Formal.m3", line 498: parameter not specified (traced)
"..\src\values\Formal.m3", line 512: unknown parameter (rhs)
"..\src\values\Formal.m3", line 512: incompatible types (traced)
"..\src\values\Formal.m3", line 515: parameter not specified (traced)
"..\src\values\Formal.m3", line 530: unknown parameter (rhs)
"..\src\values\Formal.m3", line 530: incompatible types (traced)
"..\src\values\Formal.m3", line 536: parameter not specified (traced)
"..\src\values\Formal.m3", line 552: unknown parameter (rhs)
"..\src\values\Formal.m3", line 552: incompatible types (traced)
"..\src\values\Formal.m3", line 555: parameter not specified (traced)
"..\src\values\Formal.m3", line 608: unknown parameter (rhs)
"..\src\values\Formal.m3", line 608: incompatible types (traced)
"..\src\values\Formal.m3", line 611: parameter not specified (traced)
"..\src\values\Formal.m3", line 627: unknown parameter (rhs)
"..\src\values\Formal.m3", line 627: incompatible types (traced)
"..\src\values\Formal.m3", line 630: parameter not specified (traced)
"..\src\values\Formal.m3", line 649: unknown parameter (rhs)
"..\src\values\Formal.m3", line 649: incompatible types (traced)
"..\src\values\Formal.m3", line 656: parameter not specified (traced)
25 errors encountered

Apparently, someone has checked in a change to Formal.m3 that
has compile errors.

Can whoever made the change please take a look and correct the problem.

Thanks,
Randy Coleburn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120218/6f8ddd9a/attachment-0001.html>

From dabenavidesd at yahoo.es  Sat Feb 18 21:20:26 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 18 Feb 2012 20:20:26 +0000 (GMT)
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>
Message-ID: <1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:

Randy; I'm trying to verify with head all is OK but currently I can't bootstrap since I hit the same errors.

The other option will be trying to restore the old version (rev 1.13, I
assume I have that already, but I refuse to downgrade unless it is a real error, who knows if the compiler has that error, I
guess there is a way to bootstrap that again, but I can't do anything
else if the compiler can't compile it) in any event:

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/m3front/src/values/Formal.m3?rev=1.13;content-type=text%2Fplain



Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 17:51


 
 




I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.
?
new source -> compiling Formal.m3

"..\src\values\Formal.m3", line 353: parameter not specified (traced)

"..\src\values\Formal.m3", line 432: unknown parameter (rhs)

"..\src\values\Formal.m3", line 432: incompatible types (traced)

"..\src\values\Formal.m3", line 437: parameter not specified (traced)

"..\src\values\Formal.m3", line 492: unknown parameter (rhs)

"..\src\values\Formal.m3", line 492: incompatible types (traced)

"..\src\values\Formal.m3", line 498: parameter not specified (traced)

"..\src\values\Formal.m3", line 512: unknown parameter (rhs)

"..\src\values\Formal.m3", line 512: incompatible types (traced)

"..\src\values\Formal.m3", line 515: parameter not specified (traced)

"..\src\values\Formal.m3", line 530: unknown parameter (rhs)

"..\src\values\Formal.m3", line 530: incompatible types (traced)

"..\src\values\Formal.m3", line 536: parameter not specified (traced)

"..\src\values\Formal.m3", line 552: unknown parameter (rhs)

"..\src\values\Formal.m3", line 552: incompatible types (traced)

"..\src\values\Formal.m3", line 555: parameter not specified (traced)

"..\src\values\Formal.m3", line 608: unknown parameter (rhs)

"..\src\values\Formal.m3", line 608: incompatible types (traced)

"..\src\values\Formal.m3", line 611: parameter not specified (traced)

"..\src\values\Formal.m3", line 627: unknown parameter (rhs)

"..\src\values\Formal.m3", line 627: incompatible types (traced)

"..\src\values\Formal.m3", line 630: parameter not specified (traced)

"..\src\values\Formal.m3", line 649: unknown parameter (rhs)

"..\src\values\Formal.m3", line 649: incompatible types (traced)

"..\src\values\Formal.m3", line 656: parameter not specified (traced)

25 errors encountered
?
Apparently, someone has checked in a change to Formal.m3 that
has compile errors.
?
Can whoever made the change please take a look and correct the problem.
?
Thanks,
Randy Coleburn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120218/0ef49410/attachment-0001.html>

From jay.krell at cornell.edu  Sat Feb 18 23:14:07 2012
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Feb 2012 22:14:07 +0000
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>,
	<1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W39A29D6DF3628F2E4A345CE6600@phx.gbl>


Tony broke this in December. https://mail.elegosoft.com/pipermail/m3commit/2011-December/date.html  - Jay
 Date: Sat, 18 Feb 2012 20:20:26 +0000
From: dabenavidesd at yahoo.es
To: m3devel at elegosoft.com; rcolebur at SCIRES.COM
Subject: Re: [M3devel] compile errors in m3front's Formal.m3

Hi all:

Randy; I'm trying to verify with head all is OK but currently I can't bootstrap since I hit the same errors.

The other option will be trying to restore the old version (rev 1.13, I
assume I have that already, but I refuse to downgrade unless it is a real error, who knows if the compiler has that error, I
guess there is a way to bootstrap that again, but I can't do anything
else if the compiler can't compile it) in any event:

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/m3front/src/values/Formal.m3?rev=1.13;content-type=text%2Fplain



Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 17:51


 
 




I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.
 
new source -> compiling Formal.m3

"..\src\values\Formal.m3", line 353: parameter not specified (traced)

"..\src\values\Formal.m3", line 432: unknown parameter (rhs)

"..\src\values\Formal.m3", line 432: incompatible types (traced)

"..\src\values\Formal.m3", line 437: parameter not specified (traced)

"..\src\values\Formal.m3", line 492: unknown parameter (rhs)

"..\src\values\Formal.m3", line 492: incompatible types (traced)

"..\src\values\Formal.m3", line 498: parameter not specified (traced)

"..\src\values\Formal.m3", line 512: unknown parameter (rhs)

"..\src\values\Formal.m3", line 512: incompatible types (traced)

"..\src\values\Formal.m3", line 515: parameter not specified (traced)

"..\src\values\Formal.m3", line 530: unknown parameter (rhs)

"..\src\values\Formal.m3", line 530: incompatible types (traced)

"..\src\values\Formal.m3", line 536: parameter not specified (traced)

"..\src\values\Formal.m3", line 552: unknown parameter (rhs)

"..\src\values\Formal.m3", line 552: incompatible types (traced)

"..\src\values\Formal.m3", line 555: parameter not specified (traced)

"..\src\values\Formal.m3", line 608: unknown parameter (rhs)

"..\src\values\Formal.m3", line 608: incompatible types (traced)

"..\src\values\Formal.m3", line 611: parameter not specified (traced)

"..\src\values\Formal.m3", line 627: unknown parameter (rhs)

"..\src\values\Formal.m3", line 627: incompatible types (traced)

"..\src\values\Formal.m3", line 630: parameter not specified (traced)

"..\src\values\Formal.m3", line 649: unknown parameter (rhs)

"..\src\values\Formal.m3", line 649: incompatible types (traced)

"..\src\values\Formal.m3", line 656: parameter not specified (traced)

25 errors encountered
 
Apparently, someone has checked in a change to Formal.m3 that
has compile errors.
 
Can whoever made the change please take a look and correct the problem.
 
Thanks,
Randy Coleburn


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120218/32326fad/attachment-0001.html>

From dabenavidesd at yahoo.es  Sat Feb 18 23:36:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 18 Feb 2012 22:36:34 +0000 (GMT)
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <COL101-W39A29D6DF3628F2E4A345CE6600@phx.gbl>
Message-ID: <1329604594.68674.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
Without trying to spam (sorry if anybody thinks so), the problem might be in the compiler itself rather than in the source code in last revision.
But now, who can give it a try of compiling that with the Modula-3 front-end and verify that the compiler is wrong (and the only thing that comes to mind is the Olivetti? Modula-3 pragmas, somehow we should develop verification condition generator for that in an effort to correct this), perhaps that's easier to proof I assume, rather than trying to check for erasing changes over and over (I mean one would never finish as C-based SE has proved).

Thanks in advance

Thanks in advance

--- El s?b, 18/2/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] compile errors in m3front's Formal.m3
Para: dabenavidesd at yahoo.es, "m3devel" <m3devel at elegosoft.com>, rcolebur at scires.com, "Tony" <hosking at cs.purdue.edu>
Fecha: s?bado, 18 de febrero, 2012 17:14




Tony broke this in December.
?
https://mail.elegosoft.com/pipermail/m3commit/2011-December/date.html
?
?- Jay
?
Date: Sat, 18 Feb 2012 20:20:26 +0000
From: dabenavidesd at yahoo.es
To: m3devel at elegosoft.com; rcolebur at SCIRES.COM
Subject: Re: [M3devel] compile errors in m3front's Formal.m3

Hi all:

Randy; I'm trying to verify with head all is OK but currently I can't bootstrap since I hit the same errors.

The other option will be trying to restore the old version (rev 1.13, I
assume I have that already, but I refuse to downgrade unless it is a real error, who knows if the compiler has that error, I
guess there is a way to bootstrap that again, but I can't do anything
else if the compiler can't compile it) in any event:

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/m3front/src/values/Formal.m3?rev=1.13;content-type=text%2Fplain



Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 17:51


 
 


#yiv1612936010 .yiv1612936010ExternalClass #yiv1612936010ecxyiv1293036 P
{margin-bottom:0px;}





I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.
?
new source -> compiling Formal.m3

"..\src\values\Formal.m3", line 353: parameter not specified (traced)

"..\src\values\Formal.m3", line 432: unknown parameter (rhs)

"..\src\values\Formal.m3", line 432: incompatible types (traced)

"..\src\values\Formal.m3", line 437: parameter not specified (traced)

"..\src\values\Formal.m3", line 492: unknown parameter (rhs)

"..\src\values\Formal.m3", line 492: incompatible types (traced)

"..\src\values\Formal.m3", line 498: parameter not specified (traced)

"..\src\values\Formal.m3", line 512: unknown parameter (rhs)

"..\src\values\Formal.m3", line 512: incompatible types (traced)

"..\src\values\Formal.m3", line 515: parameter not specified (traced)

"..\src\values\Formal.m3", line 530: unknown parameter (rhs)

"..\src\values\Formal.m3", line 530: incompatible types (traced)

"..\src\values\Formal.m3", line 536: parameter not specified (traced)

"..\src\values\Formal.m3", line 552: unknown parameter (rhs)

"..\src\values\Formal.m3", line 552: incompatible types (traced)

"..\src\values\Formal.m3", line 555: parameter not specified (traced)

"..\src\values\Formal.m3", line 608: unknown parameter (rhs)

"..\src\values\Formal.m3", line 608: incompatible types (traced)

"..\src\values\Formal.m3", line 611: parameter not specified (traced)

"..\src\values\Formal.m3", line 627: unknown parameter (rhs)

"..\src\values\Formal.m3", line 627: incompatible types (traced)

"..\src\values\Formal.m3", line 630: parameter not specified (traced)

"..\src\values\Formal.m3", line 649: unknown parameter (rhs)

"..\src\values\Formal.m3", line 649: incompatible types (traced)

"..\src\values\Formal.m3", line 656: parameter not specified (traced)

25 errors encountered
?
Apparently, someone has checked in a change to Formal.m3 that
has compile errors.
?
Can whoever made the change please take a look and correct the problem.
?
Thanks,
Randy Coleburn


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120218/38beb1ae/attachment-0001.html>

From dabenavidesd at yahoo.es  Sat Feb 18 23:40:29 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 18 Feb 2012 22:40:29 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329481577.26677.YahooMailClassic@web29705.mail.ird.yahoo.com>
Message-ID: <1329604829.41174.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
Interestingly Java had (along ago) UNSAFE extensions into the language:

http://groups.google.com/group/microsoft.public.dotnet.general/browse_thread/thread/bdbaaafa49579931/d9a25710e7e1cdc4%3Fq%3D%2522David%2BChase%2522%23d9a25710e7e1cdc4&ei=iGwTS6eaOpW8Qpmqic0O&sa=t&ct=res&cd=49&source=groups&usg=AFQjCNGAFKXr0Lh9Zhp47J8i8nnVUMePyw

I insist we should get back the Original test suite of SUN, this would help so much the Modula-3 RT (remember this guys worked hard in Modula-3 until the compiler got unsupported or at least until they thought it wouldn't get that much support).

Thanks in advance


--- El vie, 17/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Dragi?a Duri?" <dragisha at m3w.org>
CC: "m3devel" <m3devel at elegosoft.com>, "Jay" <jay.krell at cornell.edu>
Fecha: viernes, 17 de febrero, 2012 07:26

Hi all:
I don't think that's the case, Java has a JNI and it can work, but CM JVM is just a lot safer and easier to use, direct access to C code of the RT and you know what is better than that out there, in case of an attack? Modula-3 + Java seems the combination to win for me, ESC for both, I mean and what else do you need?

The point of what is Modula-3 a Systems Programming Language doesn't change that it is easier to deal with UNSAFE code, still we could add a keyword for say PROVED to allow the back-end check only for correct optimizations on it or to check UNSAFE code allowed to do so in either Java or Modula-3 or C. I don't care too much about PROVED or UNSAFE modules but more normal code and that's where Modula-3 could be helped by JVM dynamic verification (that said, it is not the best thing to do because this requires a lot of smart checking,
 I can give you an example of a program in Java that still manages to corrupt any class file in the cd, fooling the JVM) without JVM doing that much. That said compiler verification is much harder than normal checking, still there is research to allow one to do so.
Thanks in advance

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay" <jay.krell at cornell.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 06:29

To port to JVM or Javascript, you have to throw through the window a lot of what Modula-3 is. You will get, in best case, part of
 Modula-3.
On the other side, targeting to C (or C++) and losing object model from sight (while debugging), ie losing or distorting, also looks like an horrible side effect to me.
It looks like the best direction to concentrate effort is current GCC (a lot of platforms) and LLVM ((almost) new kid on the block with many good promises). The best thing about LLVM target is - IM is standardized and fully documented. Since we all know what pain is tagging along behind GCC IM (thanks to RMS losing licensing battle to SRC), LLVM looks like a promise of future freedom for Modula-3. Maye some day we will not be traumatized by every major (and most minor) GCC releases.
BTW, freepascal has it's own backend infrastructure. Maybe worth a try.
dd

On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides D. wrote:
Hi all:
The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120218/4a4c9d5c/attachment-0001.html>

From rodney_bates at lcwb.coop  Sun Feb 19 19:18:02 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 19 Feb 2012 12:18:02 -0600
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <B4107FAB-6385-480C-889F-BB904CDF4754@m3w.org>
References: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com>
	<B4107FAB-6385-480C-889F-BB904CDF4754@m3w.org>
Message-ID: <4F413CDA.8080006@lcwb.coop>



On 02/17/2012 05:29 AM, Dragi?a Duri? wrote:
> To port to JVM or Javascript, you have to throw through the window a lot of what Modula-3 is. You will get, in best case, part of Modula-3.
>

Once, I was peripherally involved in a project that was planning to translate
Ada to JVM code.  After a bit of design work, they quickly abandoned that idea.

Java reflects the popular procrustean philosophy that object-oriented constructs
should be almost the only tool in your box.  As a result, the set of non-heap-allocated
types is highly impoverished, with no programmer-defined type constructors at all.
This is reflected in the JVM.  It doesn't have the constructs to support the richer
type system of Ada or Modula-3.  At the very least, some other bytecode design
would be needed.

> On the other side, targeting to C (or C++) and losing object model from sight (while debugging), ie losing or distorting, also looks like an horrible side effect to me.
>
> It looks like the best direction to concentrate effort is current GCC (a lot of platforms) and LLVM ((almost) new kid on the block with many good promises). The best thing about LLVM target is - IM is standardized and fully documented. Since we all know what pain is tagging along behind GCC IM (thanks to RMS losing licensing battle to SRC), LLVM looks like a promise of future freedom for Modula-3. Maye some day we will not be traumatized by every major (and most minor) GCC releases.
>
> BTW, freepascal has it's own backend infrastructure. Maybe worth a try.
>
> dd
>
>
> On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides D. wrote:
>
>> Hi all:
>> The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.
>>
>


From dabenavidesd at yahoo.es  Sun Feb 19 19:43:23 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 19 Feb 2012 18:43:23 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <4F413CDA.8080006@lcwb.coop>
Message-ID: <1329677003.22402.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
Thankfully some theoretical work towards unifying JavaScript Object model to the one of Obliq (did some work on that), and some of the harder work has been done in optimization (Google V8, Safari, etc) and JS VM has been written in JavaScript, then I still don't get why we can't if both theoretically and practically has been done.
I have studied in some form the JVM and I can say very clearly that it's a CISC architecture, I don't see too much of the object model in it bundled (like Uniform treatment of Integer, Scalar types and just the fact that vectorial types are like so, makes conclude that).
Thanks in advance

--- El dom, 19/2/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] Think we need a new release. C target
> Para: m3devel at elegosoft.com
> Fecha: domingo, 19 de febrero, 2012 13:18
> 
> 
> On 02/17/2012 05:29 AM, Dragi?a Duri? wrote:
> > To port to JVM or Javascript, you have to throw through
> the window a lot of what Modula-3 is. You will get, in best
> case, part of Modula-3.
> >
> 
> Once, I was peripherally involved in a project that was
> planning to translate
> Ada to JVM code.  After a bit of design work, they
> quickly abandoned that idea.
> 
> Java reflects the popular procrustean philosophy that
> object-oriented constructs
> should be almost the only tool in your box.  As a
> result, the set of non-heap-allocated
> types is highly impoverished, with no programmer-defined
> type constructors at all.
> This is reflected in the JVM.  It doesn't have the
> constructs to support the richer
> type system of Ada or Modula-3.  At the very least,
> some other bytecode design
> would be needed.
> 
> > On the other side, targeting to C (or C++) and losing
> object model from sight (while debugging), ie losing or
> distorting, also looks like an horrible side effect to me.
> >
> > It looks like the best direction to concentrate effort
> is current GCC (a lot of platforms) and LLVM ((almost) new
> kid on the block with many good promises). The best thing
> about LLVM target is - IM is standardized and fully
> documented. Since we all know what pain is tagging along
> behind GCC IM (thanks to RMS losing licensing battle to
> SRC), LLVM looks like a promise of future freedom for
> Modula-3. Maye some day we will not be traumatized by every
> major (and most minor) GCC releases.
> >
> > BTW, freepascal has it's own backend infrastructure.
> Maybe worth a try.
> >
> > dd
> >
> >
> > On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides
> D. wrote:
> >
> >> Hi all:
> >> The point is whether we want to migrate our current
> RT to C or JavaScript, my question is why not (Java/) JVM or
> Obliq.
> >>
> >
> 


From dabenavidesd at yahoo.es  Mon Feb 20 22:02:08 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 20 Feb 2012 21:02:08 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329677003.22402.YahooMailClassic@web29705.mail.ird.yahoo.com>
Message-ID: <1329771728.2749.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
in the other way Jay has proposed could be realized nicely with M3CG to extend CLEF compiler to do that, making type inference explicit could aid the JVM smartly check the IL to avoid gcc IR step and add extended static checking on it, to check for lower level RT errors in case it's necessary to. For instance check integer overflows, etc.
Thanks in advance 

--- El dom, 19/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] Think we need a new release. C target
> Para: m3devel at elegosoft.com, "Rodney M. Bates" <rodney_bates at lcwb.coop>
> Fecha: domingo, 19 de febrero, 2012 13:43
> Hi all:
> Thankfully some theoretical work towards unifying JavaScript
> Object model to the one of Obliq (did some work on that),
> and some of the harder work has been done in optimization
> (Google V8, Safari, etc) and JS VM has been written in
> JavaScript, then I still don't get why we can't if both
> theoretically and practically has been done.
> I have studied in some form the JVM and I can say very
> clearly that it's a CISC architecture, I don't see too much
> of the object model in it bundled (like Uniform treatment of
> Integer, Scalar types and just the fact that vectorial types
> are like so, makes conclude that).
> Thanks in advance
> 
> --- El dom, 19/2/12, Rodney M. Bates <rodney_bates at lcwb.coop>
> escribi?:
> 
> > De: Rodney M. Bates <rodney_bates at lcwb.coop>
> > Asunto: Re: [M3devel] Think we need a new release. C
> target
> > Para: m3devel at elegosoft.com
> > Fecha: domingo, 19 de febrero, 2012 13:18
> > 
> > 
> > On 02/17/2012 05:29 AM, Dragi?a Duri? wrote:
> > > To port to JVM or Javascript, you have to throw
> through
> > the window a lot of what Modula-3 is. You will get, in
> best
> > case, part of Modula-3.
> > >
> > 
> > Once, I was peripherally involved in a project that
> was
> > planning to translate
> > Ada to JVM code.  After a bit of design work,
> they
> > quickly abandoned that idea.
> > 
> > Java reflects the popular procrustean philosophy that
> > object-oriented constructs
> > should be almost the only tool in your box.  As a
> > result, the set of non-heap-allocated
> > types is highly impoverished, with no
> programmer-defined
> > type constructors at all.
> > This is reflected in the JVM.  It doesn't have
> the
> > constructs to support the richer
> > type system of Ada or Modula-3.  At the very
> least,
> > some other bytecode design
> > would be needed.
> > 
> > > On the other side, targeting to C (or C++) and
> losing
> > object model from sight (while debugging), ie losing
> or
> > distorting, also looks like an horrible side effect to
> me.
> > >
> > > It looks like the best direction to concentrate
> effort
> > is current GCC (a lot of platforms) and LLVM ((almost)
> new
> > kid on the block with many good promises). The best
> thing
> > about LLVM target is - IM is standardized and fully
> > documented. Since we all know what pain is tagging
> along
> > behind GCC IM (thanks to RMS losing licensing battle
> to
> > SRC), LLVM looks like a promise of future freedom for
> > Modula-3. Maye some day we will not be traumatized by
> every
> > major (and most minor) GCC releases.
> > >
> > > BTW, freepascal has it's own backend
> infrastructure.
> > Maybe worth a try.
> > >
> > > dd
> > >
> > >
> > > On Feb 15, 2012, at 8:57 PM, Daniel Alejandro
> Benavides
> > D. wrote:
> > >
> > >> Hi all:
> > >> The point is whether we want to migrate our
> current
> > RT to C or JavaScript, my question is why not (Java/)
> JVM or
> > Obliq.
> > >>
> > >
> >
> 


From rodney_bates at lcwb.coop  Tue Feb 21 21:59:17 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 21 Feb 2012 14:59:17 -0600
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <20120218053713.890011A205B@async.async.caltech.edu>
References: <4F3EBCBD.2030802@lcwb.coop>	<alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>
	<20120218053713.890011A205B@async.async.caltech.edu>
Message-ID: <4F4405A5.50706@lcwb.coop>

At first I thought this was the answer, but. alas, on closer look no.
If I make Relatives opaque, I would need to reveal it as DTContainer.T.
But a revelation must be a type constructor, not just a type name.
I would have to have two different types, Container.T and the type of
Relatives, each opaque, both revealed as the same type.  You can't do
that, because every opaque type declaration creates a unique type and
requires a unique type expression as its revelation. (It has to be
BRANDED too.)

I could break the cycle differently by making DataStruct2.Node
opaque.  Container has no need to know about the field Relatives,
so that could be in a revelation of Node, not imported by Container.
But that would require that Node be a reference type, and
I really want not to have to make values of Node be separately
heap-allocated.

On 02/17/2012 11:37 PM, Mika Nystrom wrote:
> Yes I should think if you declare the Container type in one interface,
> to be<: ROOT you can then refer to that from the other interfaces.
> Then you REVEAL the actual details in another interface that's not
> imported by the others but only where it is needed.  Both the interfaces
> you have can be generic.
>
>      Mika
>
>
> Henning Thielemann writes:
>>
>> On Fri, 17 Feb 2012, Rodney M. Bates wrote:
>>
>>> The only way I can think of is to make the Relatives field be a REFANY,
>>> and not import DTContainer into DataStruct2.  This loses static safety,
>>> but at least it will be replaced by dynamic safety, at the cost of
>>> runtime narrow checks every time I use Relatives.
>>
>> Some REVEAL tricks instead of REFANY?
>


From rodney_bates at lcwb.coop  Wed Feb 22 18:45:50 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 22 Feb 2012 11:45:50 -0600
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <5807BC3C-E467-49C1-AE3F-7695B6B0CB86@gmail.com>
References: <4F3EBCBD.2030802@lcwb.coop>	<alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>
	<20120218053713.890011A205B@async.async.caltech.edu>
	<4F4405A5.50706@lcwb.coop>
	<5807BC3C-E467-49C1-AE3F-7695B6B0CB86@gmail.com>
Message-ID: <4F4529CE.8050504@lcwb.coop>

Yes.

2.4.7: A complete revelation has the form:

REVEAL T = V

where V is a type expression (not just a name) ...

Whether this could be relaxed without introducing semantic problems would take
careful thought, but I have been aware of how using what is popularly misnamed
"name equivalence" for opaque types is needed instead of Modula-3's usual
structural equivalence for other types.

On 02/21/2012 07:44 PM, Antony Hosking wrote:
> Is that really true?  I would have thought that so long as the type name can be resolved to a concrete type then it would work.
>
> On Feb 21, 2012, at 3:59 PM, Rodney M. Bates wrote:
>
>> But a revelation must be a type constructor, not just a type name.
>
>


From dabenavidesd at yahoo.es  Fri Feb 24 18:27:53 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 24 Feb 2012 17:27:53 +0000 (GMT)
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <4F4529CE.8050504@lcwb.coop>
Message-ID: <1330104473.68021.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I would recall your attention on (just read the abstract if you may please modular soundness, that is to say 'safe' data abstraction and information hiding):
http://dl.acm.org/citation.cfm?id=570886.570888

What you can awkward features, I would call 'inherent' parametric polymorphism undecidability which is not at all a bad thing (remember ESC targets undecidable RT errors in all program universe), but in any case we can proof some properties because of that all program space you can still find errors if still are there (symbolic simulation is part of that technique I believe).

Thanks in advance



--- El mi?, 22/2/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] An awkward interaction of language properties
> Para: "Antony Hosking" <antony.hosking at gmail.com>
> CC: m3devel at elegosoft.com
> Fecha: mi?rcoles, 22 de febrero, 2012 12:45
> Yes.
> 
> 2.4.7: A complete revelation has the form:
> 
> REVEAL T = V
> 
> where V is a type expression (not just a name) ...
> 
> Whether this could be relaxed without introducing semantic
> problems would take
> careful thought, but I have been aware of how using what is
> popularly misnamed
> "name equivalence" for opaque types is needed instead of
> Modula-3's usual
> structural equivalence for other types.
> 
> On 02/21/2012 07:44 PM, Antony Hosking wrote:
> > Is that really true?  I would have thought that so
> long as the type name can be resolved to a concrete type
> then it would work.
> >
> > On Feb 21, 2012, at 3:59 PM, Rodney M. Bates wrote:
> >
> >> But a revelation must be a type constructor, not
> just a type name.
> >
> >
> 


From dragisha at m3w.org  Fri Feb 24 21:27:13 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 24 Feb 2012 21:27:13 +0100
Subject: [M3devel] atomic operations in cm3
Message-ID: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>

I cannot find any hint on how to make use of <subject>. What would I like is to communicate with worker threads without LOCK? Possible?

TIA,
dd



From dabenavidesd at yahoo.es  Fri Feb 24 22:36:42 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 24 Feb 2012 21:36:42 +0000 (GMT)
Subject: [M3devel] atomic operations in cm3
In-Reply-To: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>
Message-ID: <1330119402.19915.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
Threads are not common class citizens but its users are, so we can't use normal constructs, perhaps await statements or tell/ask method to that thread may be useful like in ModSim/ModLog (p. 108) or Modula-3 respectively:

http://www.cs.rug.nl/~wim/pub/whh217.ps.gz

https://docs.google.com/open?id=1Y3JFsvlPFp0n17xWyH-HnywN1t6C3SAC-aFGdghakbS_Q8iWPszqtdFwM49H

or what is the same in:
http://www.erg.abdn.ac.uk/~former/harini/refman2.eps
 
Thanks in advance

--- El vieHi/2/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: [M3devel] atomic operations in cm3
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 24 de febrero, 2012 15:27
> I cannot find any hint on how to make
> use of <subject>. What would I like is to communicate
> with worker threads without LOCK? Possible?
> 
> TIA,
> dd
> 
> 


From jay.krell at cornell.edu  Sat Feb 25 03:24:14 2012
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 25 Feb 2012 02:24:14 +0000
Subject: [M3devel] atomic operations in cm3
In-Reply-To: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>
Message-ID: <COL101-W523161ADAA60673252C914E66B0@phx.gbl>


I checked in a test case. Can you look at it?Yes it is possible.  I forget the details, but some operations do require locks on some targets.There is an interface to determine if the target supports lock-free operation.  As long as you are only dealing in INTEGER or REFANY, I think you are ok across the board.  Some 32bit targets don't support 64bit atomtic, like Powerpc.SPARC32 and x86 have supported 64bit atomic operations for a long time.    Linux and Solaris kernels don't run on 32bit SPARC any longer, so 64bit instructions are available in 32bit usermode.HPPA is problematic for all atomics I recall. The instruction set support is very limited.Linux has good support somehow, something dependent on the kernel, but I don't know what gcc/HP-UX/OpenBSD/NetBSD story is.  Look in m3-libs/m3core/src/atomic/m3makefile for a record of what I found.  And ask Bing.   - Jay
 > From: dragisha at m3w.org
> Date: Fri, 24 Feb 2012 21:27:13 +0100
> To: m3devel at elegosoft.com
> Subject: [M3devel] atomic operations in cm3
> 
> I cannot find any hint on how to make use of <subject>. What would I like is to communicate with worker threads without LOCK? Possible?
> 
> TIA,
> dd
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120225/d6bf49af/attachment-0001.html>

From jay.krell at cornell.edu  Mon Feb 27 01:37:56 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 27 Feb 2012 00:37:56 +0000
Subject: [M3devel] atomic operations in cm3
In-Reply-To: <COL101-W523161ADAA60673252C914E66B0@phx.gbl>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
Message-ID: <COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>


  > Look in m3-libs/m3core/src/atomic/m3makefile for a record of what I found.
 http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/atomic/m3makefile?rev=1.14;content-type=text%2Fplain confusing, but goodness:
 Almost anything anyone would want is supported. 
 Except for ARMEL_LINUX: 
All targets support atomic INTEGER and REFANY. 
All LINUX targets support atomic for all types (8/16/32/64). 
All I386 targets support atomic for all types (8/16/32/64).
  This includes NT386 and probably I386_NT/I386_CYGWIN/I386_INTERIX. 
All 64bit targets support atomic for LONGINT (64).
 The missing stuff is generally in unfinished or unused targets.
PPC_DARWIN missing atomic LONGINT is the most glaring omission.
SPARc32_LINUX is next -- it should work as well as SPARc32_SOLARIS/SOLsun/SOLnu.  
Where not supported, there is pattern where you fallback to using a LOCK.I'd venture a guess that PA{32,64}_{HPUX,LINUX} also don't have good atomic support. 


 > I checked in a test case. Can you look at it?  http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile?rev=1.105;content-type=text%2Fplain  => look for "atomic"  => http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/p2/p226/Main.m3?rev=1.10;content-type=text%2Fplain Shows how to use it all. It is disabled. Let's try it.. 
 - JayFrom: jay.krell at cornell.edu
To: dragisha at m3w.org; m3devel at elegosoft.com
Subject: RE: [M3devel] atomic operations in cm3
Date: Sat, 25 Feb 2012 02:24:14 +0000







I checked in a test case. Can you look at it?
Yes it is possible.
 
 
I forget the details, but some operations do require locks on some targets.
There is an interface to determine if the target supports lock-free operation.
 
 
As long as you are only dealing in INTEGER or REFANY, I think you are ok across the board.
 
 
Some 32bit targets don't support 64bit atomtic, like Powerpc.
SPARC32 and x86 have supported 64bit atomic operations for a long time.
    Linux and Solaris kernels don't run on 32bit SPARC any longer, so 64bit instructions are available in 32bit usermode.
HPPA is problematic for all atomics I recall. The instruction set support is very limited.
Linux has good support somehow, something dependent on the kernel, but I don't know what gcc/HP-UX/OpenBSD/NetBSD story is.
 
 
Look in m3-libs/m3core/src/atomic/m3makefile for a record of what I found.
 
 
And ask Bing.
 
 
 - Jay
 
> From: dragisha at m3w.org
> Date: Fri, 24 Feb 2012 21:27:13 +0100
> To: m3devel at elegosoft.com
> Subject: [M3devel] atomic operations in cm3
> 
> I cannot find any hint on how to make use of <subject>. What would I like is to communicate with worker threads without LOCK? Possible?
> 
> TIA,
> dd
> 
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120227/a0cba8a9/attachment-0001.html>

From dragisha at m3w.org  Mon Feb 27 08:15:00 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 27 Feb 2012 08:15:00 +0100
Subject: [M3devel] atomic operations in cm3
In-Reply-To: <COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
	<COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
Message-ID: <2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>

m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.


On Feb 27, 2012, at 1:37 AM, Jay K wrote:

> Shows how to use it all.
>  
> It is disabled. Let's try it..

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120227/64bdef84/attachment-0001.html>

From dragisha at m3w.org  Tue Feb 28 14:15:16 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 28 Feb 2012 14:15:16 +0100
Subject: [M3devel] atomic operations in cm3 (fails on AMD64_DARWIN)
In-Reply-To: <2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
	<COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
	<2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>
Message-ID: <87DB10DC-D7D1-4C7E-BF67-9D5B2D19CC56@m3w.org>

% cm3
--- building in ../AMD64_DARWIN ---

new source -> compiling Proxy.m3
"../src/Proxy.m3", line 13: warning: not used (JobHandler)
1 warning encountered
new source -> compiling AtomicAddress.i3
new source -> compiling AtomicAddress.m3
"../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack:  expected [ Int64    ] got [ Addr  Int64   ]


***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3
***

zsh: abort      cm3

On Feb 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:

> m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.
> 
> 
> On Feb 27, 2012, at 1:37 AM, Jay K wrote:
> 
>> Shows how to use it all.
>>  
>> It is disabled. Let's try it..
> 

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

From dragisha at m3w.org  Tue Feb 28 15:08:17 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 28 Feb 2012 15:08:17 +0100
Subject: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
In-Reply-To: <9C0959B3-53C1-4147-A1E3-CC08EF0F4FAF@gmail.com>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
	<COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
	<2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>
	<87DB10DC-D7D1-4C7E-BF67-9D5B2D19CC56@m3w.org>
	<9C0959B3-53C1-4147-A1E3-CC08EF0F4FAF@gmail.com>
Message-ID: <98191695-F733-46F5-B51C-B4F6FAC710B6@m3w.org>

% cm3
--- building in ../AMD64_LINUX ---

new source -> compiling AtomicAddress.m3
"../AMD64_LINUX/AtomicAddress.m3", line 3:  18 code generation errors
1 error encountered
new exporters -> recompiling AtomicAddress.i3
compilation failed => not building program "test"
Fatal Error: package build failed

% cat m3makefile 
import("libm3")

...

Generic_module("Atomic")
template("atomic")
Atomic("Address")

program ("test")

On Feb 28, 2012, at 2:25 PM, Antony Hosking wrote:

> Yes, this is a known bug.
> 
> On Feb 28, 2012, at 8:15 AM, Dragi?a Duri? wrote:
> 
>> % cm3
>> --- building in ../AMD64_DARWIN ---
>> 
>> new source -> compiling Proxy.m3
>> "../src/Proxy.m3", line 13: warning: not used (JobHandler)
>> 1 warning encountered
>> new source -> compiling AtomicAddress.i3
>> new source -> compiling AtomicAddress.m3
>> "../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack:  expected [ Int64    ] got [ Addr  Int64   ]
>> 
>> 
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3
>> ***
>> 
>> zsh: abort      cm3
>> 
>> On Feb 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:
>> 
>>> m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.
>>> 
>>> 
>>> On Feb 27, 2012, at 1:37 AM, Jay K wrote:
>>> 
>>>> Shows how to use it all.
>>>>  
>>>> It is disabled. Let's try it..
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120228/055f5064/attachment-0001.html>

From dragisha at m3w.org  Tue Feb 28 15:23:32 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 28 Feb 2012 15:23:32 +0100
Subject: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
In-Reply-To: <5272CAF6-2F21-4516-83F6-3ABFFFB2145E@gmail.com>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
	<COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
	<2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>
	<87DB10DC-D7D1-4C7E-BF67-9D5B2D19CC56@m3w.org>
	<9C0959B3-53C1-4147-A1E3-CC08EF0F4FAF@gmail.com>
	<98191695-F733-46F5-B51C-B4F6FAC710B6@m3w.org>
	<5272CAF6-2F21-4516-83F6-3ABFFFB2145E@gmail.com>
Message-ID: <4F234746-BBC5-4F23-A9FC-C39EC2D78284@m3w.org>

LINUXLIBC6 does not have Address.i3, at least my version does not.

But, Atomic("Refany") passess at LINUXLIBC6. But, call to AtomicRefany.IsLockFree() fails - looks like infinite recursion happens inside.

On Feb 28, 2012, at 3:13 PM, Antony Hosking wrote:

> Same error as before.  We need more compile-time type information to be maintained to make sure that we are operating on addresses not integers.
> 
> On Feb 28, 2012, at 9:08 AM, Dragi?a Duri? wrote:
> 
>> % cm3
>> --- building in ../AMD64_LINUX ---
>> 
>> new source -> compiling AtomicAddress.m3
>> "../AMD64_LINUX/AtomicAddress.m3", line 3:  18 code generation errors
>> 1 error encountered
>> new exporters -> recompiling AtomicAddress.i3
>> compilation failed => not building program "test"
>> Fatal Error: package build failed
>> 
>> % cat m3makefile 
>> import("libm3")
>> 
>> ...
>> 
>> Generic_module("Atomic")
>> template("atomic")
>> Atomic("Address")
>> 
>> program ("test")
>> 
>> On Feb 28, 2012, at 2:25 PM, Antony Hosking wrote:
>> 
>>> Yes, this is a known bug.
>>> 
>>> On Feb 28, 2012, at 8:15 AM, Dragi?a Duri? wrote:
>>> 
>>>> % cm3
>>>> --- building in ../AMD64_DARWIN ---
>>>> 
>>>> new source -> compiling Proxy.m3
>>>> "../src/Proxy.m3", line 13: warning: not used (JobHandler)
>>>> 1 warning encountered
>>>> new source -> compiling AtomicAddress.i3
>>>> new source -> compiling AtomicAddress.m3
>>>> "../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack:  expected [ Int64    ] got [ Addr  Int64   ]
>>>> 
>>>> 
>>>> ***
>>>> *** runtime error:
>>>> ***    Segmentation violation - possible attempt to dereference NIL
>>>> ***    pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3
>>>> ***
>>>> 
>>>> zsh: abort      cm3
>>>> 
>>>> On Feb 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:
>>>> 
>>>>> m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.
>>>>> 
>>>>> 
>>>>> On Feb 27, 2012, at 1:37 AM, Jay K wrote:
>>>>> 
>>>>>> Shows how to use it all.
>>>>>>  
>>>>>> It is disabled. Let's try it..
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120228/51d7121b/attachment-0001.html>

From dabenavidesd at yahoo.es  Tue Feb 28 19:09:01 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 28 Feb 2012 18:09:01 +0000 (GMT)
Subject: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
In-Reply-To: <98191695-F733-46F5-B51C-B4F6FAC710B6@m3w.org>
Message-ID: <1330452541.3684.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I don't understand it, what is breaking, the compiler front end, the backend or both or what else? Besides platform feature instability, means that you are doing UNSAFE MODULEs? Question, is your machine SMP? I have one 32 and 64 UP LINUXLIBC6 capable, does it matter if is in one or in the other?
Thanks in advance

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
Para: "Antony Hosking" <antony.hosking at gmail.com>
CC: "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: martes, 28 de febrero, 2012 09:08

% cm3--- building in ../AMD64_LINUX ---
new source -> compiling AtomicAddress.m3"../AMD64_LINUX/AtomicAddress.m3", line 3: ?18 code generation errors1 error encounterednew exporters -> recompiling AtomicAddress.i3compilation failed => not building program "test"Fatal Error: package build failed
% cat m3makefile?import("libm3")
...
Generic_module("Atomic")template("atomic")Atomic("Address")
program ("test")
On Feb 28, 2012, at 2:25 PM, Antony Hosking wrote:
Yes, this is a known bug.
On Feb 28, 2012, at 8:15 AM, Dragi?a Duri? wrote:
% cm3--- building in ../AMD64_DARWIN ---
new source -> compiling Proxy.m3"../src/Proxy.m3", line 13: warning: not used (JobHandler)1 warning encounterednew source -> compiling AtomicAddress.i3new source -> compiling AtomicAddress.m3"../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack: ?expected [ Int64 ? ?] got [ Addr ?Int64 ? ]

****** runtime error:*** ? ?Segmentation violation - possible attempt to dereference NIL*** ? ?pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3***
zsh: abort ? ? ?cm3
On Feb 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:
m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.

On Feb 27, 2012, at 1:37 AM, Jay K wrote:
Shows how to use it all.
?
It is disabled. Let's try it..



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

From dabenavidesd at yahoo.es  Tue Feb 28 22:53:33 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 28 Feb 2012 21:53:33 +0000 (GMT)
Subject: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
In-Reply-To: <8D6408D2-7FDF-47B4-96D3-39A921ED419F@gmail.com>
Message-ID: <1330466013.93631.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
Thanks for the message and now I caught it, I have found a thesis on the <* FIELDS *> specification feature, perhaps would be a nice idea to use it to verify the trees in both Olivetti and CM3 front end, and to convert back and forth (for instance when select ESC-ing a program so just doing it once and for all is faster).

And thinking it more, I guess similarly this could be the way to watch the back end to reconstruct/infer the types same from the gcc assembly (and the CLEF tree) and compare and match if they truly match to prove it's correct.

Thanks in advance

--- El mar, 28/2/12, Antony Hosking <antony.hosking at gmail.com> escribi?:

De: Antony Hosking <antony.hosking at gmail.com>
Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: martes, 28 de febrero, 2012 15:46

It is the front end outputting badly typed IR.
On Feb 28, 2012, at 1:09 PM, Daniel Alejandro Benavides D. wrote:
Hi all:
I don't understand it, what is breaking, the compiler front end, the backend or both or what else? Besides platform feature instability, means that you are doing UNSAFE MODULEs? Question, is your machine SMP? I have one 32 and 64 UP LINUXLIBC6 capable, does it matter if is in one or in the other?
Thanks in advance

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
Para: "Antony Hosking" <antony.hosking at gmail.com>
CC: "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: martes, 28 de febrero, 2012 09:08

% cm3--- building in ../AMD64_LINUX ---
new source -> compiling AtomicAddress.m3"../AMD64_LINUX/AtomicAddress.m3", line 3: ?18 code generation errors1 error encounterednew exporters -> recompiling AtomicAddress.i3compilation failed => not building program "test"Fatal Error: package build failed
% cat m3makefile?import("libm3")
...
Generic_module("Atomic")template("atomic")Atomic("Address")
program ("test")
On Feb 28, 2012, at 2:25 PM, Antony Hosking wrote:
Yes, this is a known bug.
On Feb 28, 2012, at 8:15 AM, Dragi?a Duri? wrote:
% cm3--- building in ../AMD64_DARWIN ---
new source -> compiling Proxy.m3"../src/Proxy.m3", line 13: warning: not used (JobHandler)1 warning encounterednew source -> compiling AtomicAddress.i3new source -> compiling AtomicAddress.m3"../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack: ?expected [ Int64 ? ?] got [ Addr ?Int64 ? ]

****** runtime error:*** ? ?Segmentation violation - possible attempt to dereference NIL*** ? ?pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3***
zsh: abort ? ? ?cm3
On Feb
 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:
m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.

On Feb 27, 2012, at 1:37 AM, Jay K wrote:
Shows how to use it all.
?
It is disabled. Let's try
 it..




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120228/1dc64095/attachment-0001.html>

From dknoto at next.com.pl  Thu Feb  2 21:04:45 2012
From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?B?S25vY2nxc2tp?=)
Date: Thu, 2 Feb 2012 21:04:45 +0100
Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling
 problem
In-Reply-To: <COL101-W2279CBB33BFAF0CEE87DC1E6720@phx.gbl>
References: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com>
	<COL101-W2279CBB33BFAF0CEE87DC1E6720@phx.gbl>
Message-ID: <20120202210445.6c03d7d9@wenus.next.com.pl>

Dnia 2012-01-31, o godz. 02:21:56
Jay K <jay.krell at cornell.edu> napisa?(a):

> 
>   > $ tar -zxf /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > *** cannot
>   > find package import-libs / m3-win/import-libs
> You don't have the full source tree.Among m3-sys, m3-tools, m3-ui, etc., you
> are missing m3-win.If there is an "all" archive, try it?

I tried compiling from full sources. I have not achieved success. After
compiling backend process dumps lot of errors like this:

ranlib  libbackend.a
g++  -g  -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wc++-compat -fno-common  -DHAVE_CONFIG_H  -o m3cgc1 m3cg/parse.o attribs.o
main.o tree-browser.o
libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a ../libiberty/libiberty.a
-rdynamic -ldl --- shipping from AMD64_LINUX ---

. => /usr/local/cm3/bin
  cm3cg           
 ==> /home/dknoto/Projekty/CM3-5.9.0-devel/m3-sys/m3cc done

=== package /home/dknoto/Projekty/CM3-5.9.0-devel/m3-libs/m3core ===
 +++ cm3 -build -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' $RARGS  && cm3
-ship $RARGS -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel'  +++ --- building
in AMD64_LINUX ---

ignoring ../src/m3overrides

new source -> compiling RTHooks.i3
m3cgc1: fatal error:  *** illegal type: 0x17, at m3cg_lineno 4
compilation terminated.
  m3_backend => 1
m3cc (aka cm3cg) failed compiling: RTHooks.ic
new source -> compiling RT0.i3
m3cgc1: fatal error:  *** illegal type: 0x17, at m3cg_lineno 4
compilation terminated.
...

Best regards
Dariusz. 


From dabenavidesd at yahoo.es  Thu Feb  2 22:47:13 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 2 Feb 2012 21:47:13 +0000 (GMT)
Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling
	problem
In-Reply-To: <20120202210445.6c03d7d9@wenus.next.com.pl>
Message-ID: <1328219233.94197.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
Well, Jay I pass that one onto you, because we still miss back end testing, but nevertheless this is better than before. 
Anyway, I guess we can make some proofs at least statically with compile time asserts, just to make an idea, but needs investigation (Jay do you have some idea? I might try myself).
Thanks in advance 

--- El jue, 2/2/12, Dariusz Knoci?ski <dknoto at next.com.pl> escribi?:

> De: Dariusz Knoci?ski <dknoto at next.com.pl>
> Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem
> Para: m3devel at elegosoft.com
> Fecha: jueves, 2 de febrero, 2012 15:04
> Dnia 2012-01-31, o godz. 02:21:56
> Jay K <jay.krell at cornell.edu>
> napisa?(a):
> 
> > 
> >   > $ tar -zxf
> /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > ***
> cannot
> >   > find package import-libs /
> m3-win/import-libs
> > You don't have the full source tree.Among m3-sys,
> m3-tools, m3-ui, etc., you
> > are missing m3-win.If there is an "all" archive, try
> it?
> 
> I tried compiling from full sources. I have not achieved
> success. After
> compiling backend process dumps lot of errors like this:
> 
> ranlib  libbackend.a
> g++  -g  -DIN_GCC   -W -Wall
> -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wmissing-format-attribute -pedantic
> -Wno-long-long
> -Wno-variadic-macros -Wno-overlength-strings
> -Wold-style-definition
> -Wc++-compat -fno-common  -DHAVE_CONFIG_H  -o
> m3cgc1 m3cg/parse.o attribs.o
> main.o tree-browser.o
> libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a
> ../libiberty/libiberty.a
> -rdynamic -ldl --- shipping from AMD64_LINUX ---
> 
> . => /usr/local/cm3/bin
>   cm3cg           
>  ==> /home/dknoto/Projekty/CM3-5.9.0-devel/m3-sys/m3cc
> done
> 
> === package
> /home/dknoto/Projekty/CM3-5.9.0-devel/m3-libs/m3core ===
>  +++ cm3 -build
> -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' $RARGS 
> && cm3
> -ship $RARGS
> -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel'  +++ ---
> building
> in AMD64_LINUX ---
> 
> ignoring ../src/m3overrides
> 
> new source -> compiling RTHooks.i3
> m3cgc1: fatal error:  *** illegal type: 0x17, at
> m3cg_lineno 4
> compilation terminated.
>   m3_backend => 1
> m3cc (aka cm3cg) failed compiling: RTHooks.ic
> new source -> compiling RT0.i3
> m3cgc1: fatal error:  *** illegal type: 0x17, at
> m3cg_lineno 4
> compilation terminated.
> ...
> 
> Best regards
> Dariusz. 
> 


From dabenavidesd at yahoo.es  Thu Feb  2 23:12:57 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 2 Feb 2012 22:12:57 +0000 (GMT)
Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling
	problem
In-Reply-To: <1328219233.94197.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <1328220777.53225.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I read somewhere m3cg or m3cc or "m3gcc" is just an automata. If I knew the class I would be able to print out its current state at compile time which will provide enough source for any compiler hacker to correct it, right?
Now, I need a tool to check what compilation is right or not to automate that process.
I will need to look for alternatives for doing that.
Thanks in advance

--- El jue, 2/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem
> Para: m3devel at elegosoft.com, "Dariusz Knoci?ski" <dknoto at next.com.pl>
> Fecha: jueves, 2 de febrero, 2012 16:47
> Hi all:
> Well, Jay I pass that one onto you, because we still miss
> back end testing, but nevertheless this is better than
> before. 
> Anyway, I guess we can make some proofs at least statically
> with compile time asserts, just to make an idea, but needs
> investigation (Jay do you have some idea? I might try
> myself).
> Thanks in advance 
> 
> --- El jue, 2/2/12, Dariusz Knoci?ski <dknoto at next.com.pl>
> escribi?:
> 
> > De: Dariusz Knoci?ski <dknoto at next.com.pl>
> > Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0
> 2011-11-19-02-40-49 compilling problem
> > Para: m3devel at elegosoft.com
> > Fecha: jueves, 2 de febrero, 2012 15:04
> > Dnia 2012-01-31, o godz. 02:21:56
> > Jay K <jay.krell at cornell.edu>
> > napisa?(a):
> > 
> > > 
> > >   > $ tar -zxf
> > /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > ***
> > cannot
> > >   > find package import-libs /
> > m3-win/import-libs
> > > You don't have the full source tree.Among m3-sys,
> > m3-tools, m3-ui, etc., you
> > > are missing m3-win.If there is an "all" archive,
> try
> > it?
> > 
> > I tried compiling from full sources. I have not
> achieved
> > success. After
> > compiling backend process dumps lot of errors like
> this:
> > 
> > ranlib  libbackend.a
> > g++  -g  -DIN_GCC   -W -Wall
> > -Wwrite-strings -Wstrict-prototypes
> > -Wmissing-prototypes -Wmissing-format-attribute
> -pedantic
> > -Wno-long-long
> > -Wno-variadic-macros -Wno-overlength-strings
> > -Wold-style-definition
> > -Wc++-compat -fno-common  -DHAVE_CONFIG_H 
> -o
> > m3cgc1 m3cg/parse.o attribs.o
> > main.o tree-browser.o
> > libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a
> > ../libiberty/libiberty.a
> > -rdynamic -ldl --- shipping from AMD64_LINUX ---
> > 
> > . => /usr/local/cm3/bin
> >   cm3cg       
>    
> >  ==>
> /home/dknoto/Projekty/CM3-5.9.0-devel/m3-sys/m3cc
> > done
> > 
> > === package
> > /home/dknoto/Projekty/CM3-5.9.0-devel/m3-libs/m3core
> ===
> >  +++ cm3 -build
> > -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' $RARGS 
> > && cm3
> > -ship $RARGS
> > -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' 
> +++ ---
> > building
> > in AMD64_LINUX ---
> > 
> > ignoring ../src/m3overrides
> > 
> > new source -> compiling RTHooks.i3
> > m3cgc1: fatal error:  *** illegal type: 0x17, at
> > m3cg_lineno 4
> > compilation terminated.
> >   m3_backend => 1
> > m3cc (aka cm3cg) failed compiling: RTHooks.ic
> > new source -> compiling RT0.i3
> > m3cgc1: fatal error:  *** illegal type: 0x17, at
> > m3cg_lineno 4
> > compilation terminated.
> > ...
> > 
> > Best regards
> > Dariusz. 
> >
> 


From jay.krell at cornell.edu  Fri Feb  3 17:13:55 2012
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 3 Feb 2012 16:13:55 +0000
Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling
 problem
In-Reply-To: <1328220777.53225.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <1328219233.94197.YahooMailClassic@web29702.mail.ird.yahoo.com>,
	<1328220777.53225.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W582443CDE1FFAE46B12899E6710@phx.gbl>


Daniel, no.

Darious, how about cm3 -commands -keep?
This sort of error indicates either the wrong cm3cg is being run or it is being passed the wrong file, like mixing up .ic and .io files or somesuch.
Try adding -v to the cm3cg commands.
  You'll have to cd to the target directory as well (AMD64_LINUX).


 - Jay

> Date: Thu, 2 Feb 2012 22:12:57 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; dknoto at next.com.pl
> Subject: Re: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling	problem
> 
> Hi all:
> I read somewhere m3cg or m3cc or "m3gcc" is just an automata. If I knew the class I would be able to print out its current state at compile time which will provide enough source for any compiler hacker to correct it, right?
> Now, I need a tool to check what compilation is right or not to automate that process.
> I will need to look for alternatives for doing that.
> Thanks in advance
> 
> --- El jue, 2/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:
> 
> > De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> > Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem
> > Para: m3devel at elegosoft.com, "Dariusz Knoci?ski" <dknoto at next.com.pl>
> > Fecha: jueves, 2 de febrero, 2012 16:47
> > Hi all:
> > Well, Jay I pass that one onto you, because we still miss
> > back end testing, but nevertheless this is better than
> > before. 
> > Anyway, I guess we can make some proofs at least statically
> > with compile time asserts, just to make an idea, but needs
> > investigation (Jay do you have some idea? I might try
> > myself).
> > Thanks in advance 
> > 
> > --- El jue, 2/2/12, Dariusz Knoci?ski <dknoto at next.com.pl>
> > escribi?:
> > 
> > > De: Dariusz Knoci?ski <dknoto at next.com.pl>
> > > Asunto: Re: [M3devel] Fwd: CM3 d 5.9.0
> > 2011-11-19-02-40-49 compilling problem
> > > Para: m3devel at elegosoft.com
> > > Fecha: jueves, 2 de febrero, 2012 15:04
> > > Dnia 2012-01-31, o godz. 02:21:56
> > > Jay K <jay.krell at cornell.edu>
> > > napisa?(a):
> > > 
> > > > 
> > > >   > $ tar -zxf
> > > /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > ***
> > > cannot
> > > >   > find package import-libs /
> > > m3-win/import-libs
> > > > You don't have the full source tree.Among m3-sys,
> > > m3-tools, m3-ui, etc., you
> > > > are missing m3-win.If there is an "all" archive,
> > try
> > > it?
> > > 
> > > I tried compiling from full sources. I have not
> > achieved
> > > success. After
> > > compiling backend process dumps lot of errors like
> > this:
> > > 
> > > ranlib  libbackend.a
> > > g++  -g  -DIN_GCC   -W -Wall
> > > -Wwrite-strings -Wstrict-prototypes
> > > -Wmissing-prototypes -Wmissing-format-attribute
> > -pedantic
> > > -Wno-long-long
> > > -Wno-variadic-macros -Wno-overlength-strings
> > > -Wold-style-definition
> > > -Wc++-compat -fno-common  -DHAVE_CONFIG_H 
> > -o
> > > m3cgc1 m3cg/parse.o attribs.o
> > > main.o tree-browser.o
> > > libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a
> > > ../libiberty/libiberty.a
> > > -rdynamic -ldl --- shipping from AMD64_LINUX ---
> > > 
> > > . => /usr/local/cm3/bin
> > >   cm3cg       
> >    
> > >  ==>
> > /home/dknoto/Projekty/CM3-5.9.0-devel/m3-sys/m3cc
> > > done
> > > 
> > > === package
> > > /home/dknoto/Projekty/CM3-5.9.0-devel/m3-libs/m3core
> > ===
> > >  +++ cm3 -build
> > > -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' $RARGS 
> > > && cm3
> > > -ship $RARGS
> > > -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel' 
> > +++ ---
> > > building
> > > in AMD64_LINUX ---
> > > 
> > > ignoring ../src/m3overrides
> > > 
> > > new source -> compiling RTHooks.i3
> > > m3cgc1: fatal error:  *** illegal type: 0x17, at
> > > m3cg_lineno 4
> > > compilation terminated.
> > >   m3_backend => 1
> > > m3cc (aka cm3cg) failed compiling: RTHooks.ic
> > > new source -> compiling RT0.i3
> > > m3cgc1: fatal error:  *** illegal type: 0x17, at
> > > m3cg_lineno 4
> > > compilation terminated.
> > > ...
> > > 
> > > Best regards
> > > Dariusz. 
> > >
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120203/3e757b50/attachment-0002.html>

From dragisha at m3w.org  Mon Feb  6 09:50:51 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 6 Feb 2012 09:50:51 +0100
Subject: [M3devel] open array parameter passing, to external C procedure
Message-ID: <C39EBA6D-0A62-44C5-ABA1-123EB7998453@m3w.org>

I have this case:

extern int epoll_wait (int __epfd, struct epoll_event *__events,
                       int __maxevents, int __timeout);

And I would like to do it like:

<*EXTERNAL*> 
PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF epoll_event; timeout: int := -1): int;

?
VAR
  events: ARRAY [0..MaxEvents-1] OF epoll_event;

?

WITH res = epoll_wait(epfd, events, 2) DO
  ?
END;

Can I expect cm3 to do "right thing". Or I have to place parameters "by hand" using ADR and SIZE?

TIA,
dd



From mika at async.caltech.edu  Mon Feb  6 14:40:29 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Mon, 06 Feb 2012 05:40:29 -0800
Subject: [M3devel] open array parameter passing, to external C procedure
In-Reply-To: <C39EBA6D-0A62-44C5-ABA1-123EB7998453@m3w.org> 
References: <C39EBA6D-0A62-44C5-ABA1-123EB7998453@m3w.org>
Message-ID: <20120206134029.949A01A205B@async.async.caltech.edu>


I don't think it's going to work.  The Modula-3 compiler usually inserts
metadata at ADR(x) where x is an array of any type.

I know using ADDRESS works for the declaration, and then ADR(events[0]) 
for passing.  No need for SIZE, though.

If you like the type checking (we do, right?) you can of course
encapsulate it in a layer of UNSAFE Modula-3 with a safe interface.

    Mika

=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
>I have this case:
>
>extern int epoll_wait (int __epfd, struct epoll_event *__events,
>                       int __maxevents, int __timeout);
>
>And I would like to do it like:
>
><*EXTERNAL*>=20
>PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF epoll_event; =
>timeout: int :=3D -1): int;
>
>=85
>VAR
>  events: ARRAY [0..MaxEvents-1] OF epoll_event;
>
>=85
>
>WITH res =3D epoll_wait(epfd, events, 2) DO
>  =85
>END;
>
>Can I expect cm3 to do "right thing". Or I have to place parameters "by =
>hand" using ADR and SIZE?
>
>TIA,
>dd


From dabenavidesd at yahoo.es  Mon Feb  6 17:06:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 6 Feb 2012 16:06:24 +0000 (GMT)
Subject: [M3devel] open array parameter passing, to external C procedure
In-Reply-To: <C39EBA6D-0A62-44C5-ABA1-123EB7998453@m3w.org>
Message-ID: <1328544384.14121.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
given C no standard parameter by reference passing style, it should be not that easy. But how about WeakRef, where an open array of weak ref is easier to match with in Modula-3 words.
I don't know if Modula-3 has stronger types for that. Anyway, I don't know what kind of such struct is that either.
Thanks in advance

--- El lun, 6/2/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: [M3devel] open array parameter passing, to external C procedure
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 6 de febrero, 2012 03:50
> I have this case:
> 
> extern int epoll_wait (int __epfd, struct epoll_event
> *__events,
>                
>        int __maxevents, int
> __timeout);
> 
> And I would like to do it like:
> 
> <*EXTERNAL*> 
> PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF
> epoll_event; timeout: int := -1): int;
> 
> ?
> VAR
>   events: ARRAY [0..MaxEvents-1] OF epoll_event;
> 
> ?
> 
> WITH res = epoll_wait(epfd, events, 2) DO
>   ?
> END;
> 
> Can I expect cm3 to do "right thing". Or I have to place
> parameters "by hand" using ADR and SIZE?
> 
> TIA,
> dd
> 
> 


From rodney_bates at lcwb.coop  Mon Feb  6 17:43:11 2012
From: rodney_bates at lcwb.coop (Rodney Bates)
Date: Mon, 6 Feb 2012 08:43:11 -0800
Subject: [M3devel] open array parameter passing, to external C procedure
Message-ID: <20120206084311.D4AF2D80@m0005310.ppops.net>

All the compilers pass open arrays as a pointer to metadata.
The metadata consists of a pointer to actual element zero, followed
by a "shape", which is an array of element counts in each open dimension.
The number of open dimensions is a static property of the type, so
it is not passed, but hard-coded where needed. 

The actual elements can be anywhere, and indeed must be somewhere
else in the case of a SUBARRAY.   

I suppose they could have made this into separate parameters for
address of element zero and for each shape component, but I'm not 
sure right off hand how that would interact with heap-allocated open
arrays and subarrays of either heap-allocated or local variables.  
I've been ambivalent about this representation, but it can be used
consistently everywhere.  For a heap-allocated open array, the
metadata is immediately followed by the elements.  

So, no, it won't work the way you hope.  For your example, you 
would pass ADR(events[0]) and NUMBER(events) as separate parameters. 
(ADR(events) would pass the address of the metadata.)    

Of course, usually, the array you will have is not necessarily entirely 
full.  If that were the case, to do it in the Modula-3 way you had hoped, 
you would have had to pass SUBARRAY(events,0,event_count).  As it is,
the actuals in this case would be ADR(events[0]) and event_count.   

-Rodney Bates

--- dragisha at m3w.org wrote:

From: Dragi?a Duri? <dragisha at m3w.org>
To: m3devel <m3devel at elegosoft.com>
Subject: [M3devel] open array parameter passing, to external C procedure
Date: Mon, 6 Feb 2012 09:50:51 +0100

I have this case:

extern int epoll_wait (int __epfd, struct epoll_event *__events,
                       int __maxevents, int __timeout);

And I would like to do it like:

<*EXTERNAL*> 
PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF epoll_event; timeout: int := -1): int;

?
VAR
  events: ARRAY [0..MaxEvents-1] OF epoll_event;

?

WITH res = epoll_wait(epfd, events, 2) DO
  ?
END;

Can I expect cm3 to do "right thing". Or I have to place parameters "by hand" using ADR and SIZE?

TIA,
dd






From dragisha at m3w.org  Tue Feb  7 13:17:28 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 7 Feb 2012 13:17:28 +0100
Subject: [M3devel] open array parameter passing, to external C procedure
In-Reply-To: <20120206084311.D4AF2D80@m0005310.ppops.net>
References: <20120206084311.D4AF2D80@m0005310.ppops.net>
Message-ID: <BEC583C6-CAC1-44B1-A3D5-DAFB94A0A270@m3w.org>

Thanks to all for replies, it (does not) work as expected. Test showed it, reasoning is ok.

In gm2, interfacing is explicitly to C, so it's how it would and will work there. No big deal to make it by hand, but anyway - it's good to be sure :).

BTW, while googling some time ago, I found "ALIGNED  n FOR" construct from SPIN compiler? Interesting way to ensure alignment, esp in light of overaligning we have in cm3 now :).

dd

On Feb 6, 2012, at 5:43 PM, Rodney Bates wrote:

> All the compilers pass open arrays as a pointer to metadata.
> The metadata consists of a pointer to actual element zero, followed
> by a "shape", which is an array of element counts in each open dimension.
> The number of open dimensions is a static property of the type, so
> it is not passed, but hard-coded where needed. 
> 
> The actual elements can be anywhere, and indeed must be somewhere
> else in the case of a SUBARRAY.   
> 
> I suppose they could have made this into separate parameters for
> address of element zero and for each shape component, but I'm not 
> sure right off hand how that would interact with heap-allocated open
> arrays and subarrays of either heap-allocated or local variables.  
> I've been ambivalent about this representation, but it can be used
> consistently everywhere.  For a heap-allocated open array, the
> metadata is immediately followed by the elements.  
> 
> So, no, it won't work the way you hope.  For your example, you 
> would pass ADR(events[0]) and NUMBER(events) as separate parameters. 
> (ADR(events) would pass the address of the metadata.)    
> 
> Of course, usually, the array you will have is not necessarily entirely 
> full.  If that were the case, to do it in the Modula-3 way you had hoped, 
> you would have had to pass SUBARRAY(events,0,event_count).  As it is,
> the actuals in this case would be ADR(events[0]) and event_count.   
> 
> -Rodney Bates
> 
> --- dragisha at m3w.org wrote:
> 
> From: Dragi?a Duri? <dragisha at m3w.org>
> To: m3devel <m3devel at elegosoft.com>
> Subject: [M3devel] open array parameter passing, to external C procedure
> Date: Mon, 6 Feb 2012 09:50:51 +0100
> 
> I have this case:
> 
> extern int epoll_wait (int __epfd, struct epoll_event *__events,
>                       int __maxevents, int __timeout);
> 
> And I would like to do it like:
> 
> <*EXTERNAL*> 
> PROCEDURE epoll_wait (epfd: int; VAR events: ARRAY OF epoll_event; timeout: int := -1): int;
> 
> ?
> VAR
>  events: ARRAY [0..MaxEvents-1] OF epoll_event;
> 
> ?
> 
> WITH res = epoll_wait(epfd, events, 2) DO
>  ?
> END;
> 
> Can I expect cm3 to do "right thing". Or I have to place parameters "by hand" using ADR and SIZE?
> 
> TIA,
> dd
> 
> 
> 
> 
> 



From hendrik at topoi.pooq.com  Thu Feb  9 17:56:24 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 9 Feb 2012 11:56:24 -0500
Subject: [M3devel] Assertion failed to complain
Message-ID: <20120209165624.GA13717@topoi.pooq.com>

Presumably there's something I have to do (or make sure I don't do) to 
make assertion chacking work. 

With the following two lines in my program:


  <* assert segment.end + 1 >= segment.start *>    

  indices := NEW(REF ARRAY OF INTEGER, segment.end - segment.start + 
1);

I get a runtime error

***
*** runtime error:
***    An enumeration or subrange value was out of range.
***    file "../src/runtime/common/RTAllocator.m3", line 340
***

Running this in m3gdb, I see that line 340 is indeed the assignment to 
'indices' above, and that the assertion has sowehow failed to complain.

Printing out a few expressions in the debugger, I get

(m3gdb) up
#19 0x080498ba in sortsegment (segment=16_b6be01b8) at 
../src/Main.m3:218
218	  indices := NEW(REF ARRAY OF INTEGER, segment.end - 
segment.start + 1);
(m3gdb) print segment.end
$1 = 0
(m3gdb) print segment.start
$2 = 3
(m3gdb) print segment.end + 1 >= segment.start
$3 = FALSE
(m3gdb) print segment.end - segment.start + 1
$4 = 4294967294

Yes, the 'end' and 'start' fields are declared INTEGER.

Somehow, this slipped past the ASSERT statement.

-- hendrik



From hendrik at topoi.pooq.com  Thu Feb  9 18:52:20 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 9 Feb 2012 12:52:20 -0500
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <20120209165624.GA13717@topoi.pooq.com>
References: <20120209165624.GA13717@topoi.pooq.com>
Message-ID: <20120209175220.GB13717@topoi.pooq.com>

On Thu, Feb 09, 2012 at 11:56:24AM -0500, Hendrik Boom wrote:
> Presumably there's something I have to do (or make sure I don't do) to 
> make assertion chacking work. 
> 
> With the following two lines in my program:
> 
> 
>   <* assert segment.end + 1 >= segment.start *>    
> 
>   indices := NEW(REF ARRAY OF INTEGER, segment.end - segment.start + 
> 1);
> 
> I get a runtime error
> 
> ***
> *** runtime error:
> ***    An enumeration or subrange value was out of range.
> ***    file "../src/runtime/common/RTAllocator.m3", line 340
> ***
> 
> Running this in m3gdb, I see that line 340 is indeed the assignment to 
> 'indices' above, and that the assertion has sowehow failed to complain.
> 
> Printing out a few expressions in the debugger, I get
> 
> (m3gdb) up
> #19 0x080498ba in sortsegment (segment=16_b6be01b8) at 
> ../src/Main.m3:218
> 218	  indices := NEW(REF ARRAY OF INTEGER, segment.end - 
> segment.start + 1);
> (m3gdb) print segment.end
> $1 = 0
> (m3gdb) print segment.start
> $2 = 3
> (m3gdb) print segment.end + 1 >= segment.start
> $3 = FALSE
> (m3gdb) print segment.end - segment.start + 1
> $4 = 4294967294
> 
> Yes, the 'end' and 'start' fields are declared INTEGER.
> 
> Somehow, this slipped past the ASSERT statement.
> 

For the record, I'm running 

Critical Mass Modula-3 version 5.8.4
  last updated: 2009-11-02
  compiled: 2009-11-03 13:57:35
  configuration: /usr/local/cm3/bin/cm3.cfg
  host: LINUXLIBC6
  target: LINUXLIBC6

-- hendrik



From dabenavidesd at yahoo.es  Thu Feb  9 18:51:24 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 9 Feb 2012 17:51:24 +0000 (GMT)
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <20120209165624.GA13717@topoi.pooq.com>
Message-ID: <1328809884.5392.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
It might be that needs to be uppercase (in case compiler doesn't warn but I guess that would desired behavior, or not, since it would be unknown at compile time).
<*ASSERT exp*>

Thanks in advance

--- El jue, 9/2/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] Assertion failed to complain
> Para: m3devel at elegosoft.com
> Fecha: jueves, 9 de febrero, 2012 11:56
> Presumably there's something I have
> to do (or make sure I don't do) to 
> make assertion chacking work. 
> 
> With the following two lines in my program:
> 
> 
>   <* assert segment.end + 1 >= segment.start
> *>    
> 
>   indices := NEW(REF ARRAY OF INTEGER, segment.end -
> segment.start + 
> 1);
> 
> I get a runtime error
> 
> ***
> *** runtime error:
> ***    An enumeration or subrange value was out of
> range.
> ***    file
> "../src/runtime/common/RTAllocator.m3", line 340
> ***
> 
> Running this in m3gdb, I see that line 340 is indeed the
> assignment to 
> 'indices' above, and that the assertion has sowehow failed
> to complain.
> 
> Printing out a few expressions in the debugger, I get
> 
> (m3gdb) up
> #19 0x080498ba in sortsegment (segment=16_b6be01b8) at 
> ../src/Main.m3:218
> 218      indices := NEW(REF ARRAY OF
> INTEGER, segment.end - 
> segment.start + 1);
> (m3gdb) print segment.end
> $1 = 0
> (m3gdb) print segment.start
> $2 = 3
> (m3gdb) print segment.end + 1 >= segment.start
> $3 = FALSE
> (m3gdb) print segment.end - segment.start + 1
> $4 = 4294967294
> 
> Yes, the 'end' and 'start' fields are declared INTEGER.
> 
> Somehow, this slipped past the ASSERT statement.
> 
> -- hendrik
> 
> 


From hendrik at topoi.pooq.com  Thu Feb  9 18:59:08 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Thu, 9 Feb 2012 12:59:08 -0500
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <1328809884.5392.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <20120209165624.GA13717@topoi.pooq.com>
	<1328809884.5392.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <20120209175908.GC13717@topoi.pooq.com>

On Thu, Feb 09, 2012 at 05:51:24PM +0000, Daniel Alejandro Benavides D. wrote:
> Hi all:
> It might be that needs to be uppercase (in case compiler doesn't warn but I guess that would desired behavior, or not, since it would be unknown at compile time).
> <*ASSERT exp*>
> 
> Thanks in advance

That was exactly it.  One of the few places where things are 
case-sensitive, but a wrong case doesn't cause an error message.
(in fact, it suppressed it)

Things are failing properly now.

-- hendrik


From peter.mckinna at gmail.com  Fri Feb 10 06:01:00 2012
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Fri, 10 Feb 2012 16:01:00 +1100
Subject: [M3devel] Think we need a new release.
Message-ID: <CAEy6uxr=Qt6oktH60NGVByyjM9=Dtoy5OocjEOh=fC=YhbUn=Q@mail.gmail.com>

Been a long time between releases. Must be about time.

Firefox is doing 6 weekly releases we are lucky if we get one every 6
years. Sorry thats a bit harsh, all the same we need some new
commitment.

Regards Peter


From dataf4l at gmail.com  Fri Feb 10 06:22:58 2012
From: dataf4l at gmail.com (felipe valdez)
Date: Fri, 10 Feb 2012 00:22:58 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAEy6uxr=Qt6oktH60NGVByyjM9=Dtoy5OocjEOh=fC=YhbUn=Q@mail.gmail.com>
References: <CAEy6uxr=Qt6oktH60NGVByyjM9=Dtoy5OocjEOh=fC=YhbUn=Q@mail.gmail.com>
Message-ID: <CAGi-_--zaetAw_FiUK3F=twE_ba3cKDgmhUZg5B5tBO4-TQcTA@mail.gmail.com>

I'd love to help beta-testing whatever you guys throw at me.
I have linux, windows and mac (11.6) boxes for this purpose.


if testing can be automated, so much the better.

I know it is perhaps not much, but I'd like to help, and this is the only
thing I can think of.

if you guys have a more specific task, I'd like to take a crack at it, but
be indulgent, I'm just a newbie, so "making compiler not leak" type bugs
are probably not what I'll be most effective at.

I think the project could use some help, concerning the webpage (it looks
dated, a little), and also with documentatino on to how to get started
(screencast anyone?).

if more people could get behind the project, perhaps it would be easier to
make releases more often.

perhaps ideas conecrning what the selling points of M3, tha differentiate
it from other languages, would be a nice thng to be able to mention in the
videos.


I remember that Ruby on rails had some traction going on, after the creator
posted some 15 minutes videos concerning how to make a blog, and that kind
of stuff.

is it possible, to make a 15 mins video, of the main M3 features, that
would help convince more people to join the project.

is this a good idea?




On Fri, Feb 10, 2012 at 12:01 AM, Peter McKinna <peter.mckinna at gmail.com>wrote:

> Been a long time between releases. Must be about time.
>
> Firefox is doing 6 weekly releases we are lucky if we get one every 6
> years. Sorry thats a bit harsh, all the same we need some new
> commitment.
>
> Regards Peter
>



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

From dabenavidesd at yahoo.es  Fri Feb 10 14:22:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 13:22:34 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_--zaetAw_FiUK3F=twE_ba3cKDgmhUZg5B5tBO4-TQcTA@mail.gmail.com>
Message-ID: <1328880154.79634.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
Elego wanted to make a CM3IDE instance for free browsing of sources like the "Free Critical Mass Modula-3 (CM3)" since this the only excuse of a non-Modula-3 user, "I can't wait to use the compiler", or, "Do I have a platform enabled system " and we will give you a bootstrap image testable on-line, perhaps you would want to start from that. I think that anybody with modula-3 problems will appreciate that. I know of some Emulators for old platforms like Pdp-8e, Pdp-10, CDC, will anyone be keen to integrate those platforms as for have testing changes on those systems (besides showing that Modula-3 can emulate really basic and complex systems).
Personally I would love to fix the m3-obliq system and related tools to work across several platforms, you know, NetObj testing and some C-level coding inside m3cc , hopefully to make testing but will need to do some C-like clearer version, since this is hard for a non-artistic computer brain also would help to have syntax and grammar rules of M3CG whatever is available (Including M3CG- Clef - C/Assembly compiler for exploratory targets). 
I guess there  is room for more things to be done.
Thanks in advance

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

De: felipe valdez <dataf4l at gmail.com>
Asunto: Re: [M3devel] Think we need a new release.
Para: "Peter McKinna" <peter.mckinna at gmail.com>
CC: m3devel at elegosoft.com
Fecha: viernes, 10 de febrero, 2012 00:22

I'd love to help beta-testing whatever you guys throw at me.I have linux, windows and mac (11.6) boxes for this purpose.



if testing can be automated, so much the better.


I know it is perhaps not much, but I'd like to help, and this is the only thing I can think of.


if you guys have a more specific task, I'd like to take a crack at it, but be indulgent, I'm just a newbie, so "making compiler not leak" type bugs are probably not what I'll be most effective at.


I think the project could use some help, concerning the webpage (it looks dated, a little), and also with documentatino on to how to get started (screencast anyone?).


if more people could get behind the project, perhaps it would be easier to make releases more often.


perhaps ideas conecrning what the selling points of M3, tha differentiate it from other languages, would be a nice thng to be able to mention in the videos.



I remember that Ruby on rails had some traction going on, after the creator posted some 15 minutes videos concerning how to make a blog, and that kind of stuff.


is it possible, to make a 15 mins video, of the main M3 features, that would help convince more people to join the project.


is this a good idea?





On Fri, Feb 10, 2012 at 12:01 AM, Peter McKinna <peter.mckinna at gmail.com> wrote:


Been a long time between releases. Must be about time.



Firefox is doing 6 weekly releases we are lucky if we get one every 6

years. Sorry thats a bit harsh, all the same we need some new

commitment.



Regards Peter




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



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

From vintagecoder at aol.com  Fri Feb 10 15:14:35 2012
From: vintagecoder at aol.com (Vintage Coder)
Date: Fri, 10 Feb 2012 14:14:35 +0000
Subject: [M3devel] Think we need a new release.
Message-ID: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>

What is the purpose of a new release? A compiler and runtime that work presumably only need fixes. Are you talking about a major new version or a mod level or what? The last release on cm3 I see is from 2010. 

Are there bug fixes in the pipeline that haven't been verified? Are there fixes ready to go that no builds have been done for? What is the problem more frequent releases will solve? Personally I see no benefit (indeed I see many disadvantges) to frequent releases of stable software. But I often run backlevel intentionally.  

Firefox is being updated for many reasons including security holes, bug fixes, new standards, and more. If the Modula-3 standard hasn't been updated, what is driving the need for new release(s)?

It looks like cm3 supports more platforms than I have. I would be willing to help out (I am not a UNIX developer) any way I could. I have Solaris Intel and SPARC boxes. 

------Original Message------
From: Peter McKinna
To: m3devel at elegosoft.com
Subject: [M3devel] Think we need a new release.
Sent: 10 Feb 2012 05:01

Been a long time between releases. Must be about time.

Firefox is doing 6 weekly releases we are lucky if we get one every 6
years. Sorry thats a bit harsh, all the same we need some new
commitment.

Regards Peter


From rcolebur at SCIRES.COM  Fri Feb 10 15:29:52 2012
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 10 Feb 2012 09:29:52 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_--zaetAw_FiUK3F=twE_ba3cKDgmhUZg5B5tBO4-TQcTA@mail.gmail.com>
References: <CAEy6uxr=Qt6oktH60NGVByyjM9=Dtoy5OocjEOh=fC=YhbUn=Q@mail.gmail.com>
	<CAGi-_--zaetAw_FiUK3F=twE_ba3cKDgmhUZg5B5tBO4-TQcTA@mail.gmail.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6034A5AF263@atlex02-srv>

I can provide testing on Windows 2000, XP, and 7 platforms.
Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/6a833467/attachment-0002.html>

From dabenavidesd at yahoo.es  Fri Feb 10 15:31:25 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 14:31:25 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>
Message-ID: <1328884285.44537.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
I think one of the purposes of that is more cross platform compatibility, perhaps put in place everything to a major update on platform but for alpha testing new JIT RTCG or so (arguably we could stay in odd numbers being platform development until we get to a new even number for product release), while most of developers might want or not to migrate it's necessary to establish priorities and so for having such a thing.
Thanks in advance

--- El vie, 10/2/12, Vintage Coder <vintagecoder at aol.com> escribi?:

> De: Vintage Coder <vintagecoder at aol.com>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: m3devel at elegosoft.com
> Fecha: viernes, 10 de febrero, 2012 09:14
> What is the purpose of a new release?
> A compiler and runtime that work presumably only need fixes.
> Are you talking about a major new version or a mod level or
> what? The last release on cm3 I see is from 2010. 
> 
> Are there bug fixes in the pipeline that haven't been
> verified? Are there fixes ready to go that no builds have
> been done for? What is the problem more frequent releases
> will solve? Personally I see no benefit (indeed I see many
> disadvantges) to frequent releases of stable software. But I
> often run backlevel intentionally.  
> 
> Firefox is being updated for many reasons including security
> holes, bug fixes, new standards, and more. If the Modula-3
> standard hasn't been updated, what is driving the need for
> new release(s)?
> 
> It looks like cm3 supports more platforms than I have. I
> would be willing to help out (I am not a UNIX developer) any
> way I could. I have Solaris Intel and SPARC boxes. 
> 
> ------Original Message------
> From: Peter McKinna
> To: m3devel at elegosoft.com
> Subject: [M3devel] Think we need a new release.
> Sent: 10 Feb 2012 05:01
> 
> Been a long time between releases. Must be about time.
> 
> Firefox is doing 6 weekly releases we are lucky if we get
> one every 6
> years. Sorry thats a bit harsh, all the same we need some
> new
> commitment.
> 
> Regards Peter
> 
> 


From dmuysers at hotmail.com  Fri Feb 10 15:54:59 2012
From: dmuysers at hotmail.com (Dirk Muysers)
Date: Fri, 10 Feb 2012 15:54:59 +0100
Subject: [M3devel] platform-independent object file linking
Message-ID: <SNT109-DS775C44A0CC94BF3376EE2DD780@phx.gbl>

I recently came across an article that might interest the community:

A Compiler-Supported Unification of Static and Dynamic Loading
by Felix Friedrich and Florian Negele

It is about platform-independent linking and loading of modules.
The mechanism is explained in context of the A2 (ex-Bluebottle)
OS and the Active Oberon language, but it is easily portable to
other programming environments and languages.
Its adoption, at the cost of rewriting the backend and parts of
m3core, would significantly simplify the maintenance of M3 and
also render it independent from proprietary tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/568e505e/attachment-0002.html>

From dabenavidesd at yahoo.es  Fri Feb 10 16:17:46 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 15:17:46 +0000 (GMT)
Subject: [M3devel] platform-independent object file linking
In-Reply-To: <SNT109-DS775C44A0CC94BF3376EE2DD780@phx.gbl>
Message-ID: <1328887066.93948.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
nice idea, once it's inly functional would it work for procedural languages?
The nice idea of this would port it to Module system of Modula-3 which as I understand (unless it's not Modula-3 own one) is a simplified version (most of researchers didn't concentrate on a single-separate compilation, but distributed aware compilation specially in Modula-2+, in Canada, one can ask the copy and they will send to you once you identify its name).
Thanks in advance

--- El vie, 10/2/12, Dirk Muysers <dmuysers at hotmail.com> escribi?:

De: Dirk Muysers <dmuysers at hotmail.com>
Asunto: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com
Fecha: viernes, 10 de febrero, 2012 09:54



 


I recently came across an article that might 
interest the community:
?
A 
Compiler-Supported Unification of Static and Dynamic Loading
by Felix Friedrich and Florian Negele
?
It is about platform-independent linking and 
loading of modules.
The mechanism is explained?in context of 
the?A2 (ex-Bluebottle)
OS and the?Active Oberon language, but it is 
easily portable to
other?programming environments and 
languages.
Its adoption, at the cost of rewriting the backend 
and parts of
m3core,?would significantly?simplify the maintenance of M3 and
also render it independent from proprietary 
tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/05703dc7/attachment-0002.html>

From dataf4l at gmail.com  Fri Feb 10 16:42:40 2012
From: dataf4l at gmail.com (felipe valdez)
Date: Fri, 10 Feb 2012 10:42:40 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <1328884285.44537.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>
	<1328884285.44537.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>

Mr VintageCoder,


> What is the purpose of a new release?


from a technical perspective, probably not much
but from a marketing perspective (language adoption, language value
perception), there could be a few.


> A compiler and runtime that work presumably only need fixes.


that is correct.


> Are you talking about a major new version or a mod level or what? The last
> release on cm3 I see is from 2010.


this probably disproves the argument of "6 years between releases",
however, in the fast moving tech world, some people could consider 2010 to
be a long time ago.



> Are there bug fixes in the pipeline that haven't been verified? Are there
> fixes ready to go that no builds have been done for? What is the problem
> more frequent releases will solve?


I think, it makes people perceive that the language has support, is being
actively developed, is growing , and also
that it is not dead.

I used to use tcl a lot, but I haven't got a new release in a while, and
8.6 took forever (5 years?) to get done.
this made me move away from the technology, since I saw it at the time, as
stagnating, stale, old and unsupported.

had they put a "new" brand on it ever so often, I would have been more
insterested.

in general terms, once you know perl 5.10, would you be more exicet about
learning perl 6.0 or 5.10.1 ?
I mean, seriously, who gives a damn about a 0.0.1 release anyway?

the problem I see a new release would solve, is that you get to fix stuff
(like the string broken stuff) that needs fixing, without having to
maintain 100% backwards compatibility, this can lead to a cleaner language,
like python3000 broke a lot of things, for instance.


> Personally I see no benefit (indeed I see many disadvantges) to frequent
> releases of stable software.



this is als true, there are disadvantages and I also suffer a little from
this.
but surely not something we cannot live through, especially if there is
some kind of guide (3to4 ?)




> But I often run backlevel intentionally. Firefox is being updated for many
> reasons including security holes, bug fixes, new standards, and more. If
> the Modula-3 standard hasn't been updated, what is driving the need for new
> release(s)?


if the language does not evolve, is it bound to die?
if the standard does not evolve, should one consider it to be dead?
see c++ for instance, recently, there have been changes to the language.
this motivates a lot of tuff:
conferences, new compilers, new books, new blogposts, and in general, a lot
of "hype"
if m3 was hyped a little, perhaps it could gain developers.
by gaining such developers, perhaps more bugs could be removed and features
could be added as well (for instance, in the library space, where I see
that other language have better, more tested, and easier to use LIbraries,
but this is , of course, a subjective declaration, and I don't expect
anyone to agree with me).



> It looks like cm3 supports more platforms than I have. I would be willing
> to help out (I am not a UNIX developer) any way I could. I have Solaris
> Intel and SPARC boxes.


that Is wonderful news, I appreciate the offer, I hope the language
improves, and your boxes serve the purpose!




On Fri, Feb 10, 2012 at 9:31 AM, Daniel Alejandro Benavides D. <
dabenavidesd at yahoo.es> wrote:

> Hi all:
> I think one of the purposes of that is more cross platform compatibility,
> perhaps put in place everything to a major update on platform but for alpha
> testing new JIT RTCG or so (arguably we could stay in odd numbers being
> platform development until we get to a new even number for product
> release), while most of developers might want or not to migrate it's
> necessary to establish priorities and so for having such a thing.
> Thanks in advance
>
> --- El vie, 10/2/12, Vintage Coder <vintagecoder at aol.com> escribi?:
>
> > De: Vintage Coder <vintagecoder at aol.com>
> > Asunto: Re: [M3devel] Think we need a new release.
> > Para: m3devel at elegosoft.com
> > Fecha: viernes, 10 de febrero, 2012 09:14
> > What is the purpose of a new release?
> > A compiler and runtime that work presumably only need fixes.
> > Are you talking about a major new version or a mod level or
> > what? The last release on cm3 I see is from 2010.
> >
> > Are there bug fixes in the pipeline that haven't been
> > verified? Are there fixes ready to go that no builds have
> > been done for? What is the problem more frequent releases
> > will solve? Personally I see no benefit (indeed I see many
> > disadvantges) to frequent releases of stable software. But I
> > often run backlevel intentionally.
> >
> > Firefox is being updated for many reasons including security
> > holes, bug fixes, new standards, and more. If the Modula-3
> > standard hasn't been updated, what is driving the need for
> > new release(s)?
> >
> > It looks like cm3 supports more platforms than I have. I
> > would be willing to help out (I am not a UNIX developer) any
> > way I could. I have Solaris Intel and SPARC boxes.
> >
> > ------Original Message------
> > From: Peter McKinna
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] Think we need a new release.
> > Sent: 10 Feb 2012 05:01
> >
> > Been a long time between releases. Must be about time.
> >
> > Firefox is doing 6 weekly releases we are lucky if we get
> > one every 6
> > years. Sorry thats a bit harsh, all the same we need some
> > new
> > commitment.
> >
> > Regards Peter
> >
> >
>



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

From dabenavidesd at yahoo.es  Fri Feb 10 18:00:42 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 17:00:42 +0000 (GMT)
Subject: [M3devel] platform-independent object file linking
In-Reply-To: <1328887066.93948.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <1328893242.4700.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
in the sense of if at all wanted porting functionality to Modula-3 minimal functional subset language to allow such dynamic implementation and later on pass on Modula-3. 
There are some available Models of graft Modular concepts in functional-like languages worth of writing OSes on it (concurrent ones already objected oriented) like Clean and Concurrent Clean and Gofer:
http://www4.in.tum.de/~sihling/publications/1995/DA_Sihling.ps.gz

ftp://ftp.cs.york.ac.uk/pub/malcolm/thesis.ps.Z

Anyway just a possible path of action 
Thanks in advance

--- El vie, 10/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com, "Dirk Muysers" <dmuysers at hotmail.com>
Fecha: viernes, 10 de febrero, 2012 10:17

Hi all:
nice idea, once it's inly functional would it work for procedural languages?
The nice idea of this would port it to Module system of Modula-3 which as I understand (unless it's not Modula-3 own one) is a simplified version (most of researchers didn't concentrate on a single-separate compilation, but distributed aware compilation specially in Modula-2+, in Canada, one can ask the copy and they will send to you once you identify its name).
Thanks in advance

--- El vie, 10/2/12, Dirk Muysers <dmuysers at hotmail.com> escribi?:

De: Dirk Muysers <dmuysers at hotmail.com>
Asunto: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com
Fecha: viernes, 10 de febrero, 2012 09:54



 


I recently came across an article that might 
interest the community:
?
A 
Compiler-Supported Unification of Static and Dynamic Loading
by Felix Friedrich and Florian Negele
?
It is about platform-independent linking and 
loading of modules.
The mechanism is explained?in context of 
the?A2 (ex-Bluebottle)
OS and the?Active Oberon language, but it is 
easily portable to
other?programming environments and 
languages.
Its adoption, at the cost of rewriting the backend 
and parts of
m3core,?would significantly?simplify the maintenance of M3 and
also render it independent from proprietary 
tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/edf5aa7d/attachment-0002.html>

From dabenavidesd at yahoo.es  Fri Feb 10 18:27:16 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 17:27:16 +0000 (GMT)
Subject: [M3devel] platform-independent object file linking
In-Reply-To: <1328893242.4700.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <1328894836.11850.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
in fact highly advanced mainframes with Micro-code like capabilities have been developed with companies such as NEC behind it, the Lisp Machine Engine LIME was one of them, for scheduling of JAR Japan airlines staff and we already have appliances of that kind in Modula-3:
http://www.iste.uni-stuttgart.de/fileadmin/user_upload/iste/se/research/publications/download/PraktLehr5.pdf

So I guess connecting the points there is room for that sort of work, nevertheless it's a kind of hard and brave project.
In any event C++ and others are pursuing Lambda Expressions in their Standards I want to allow such kind of work but in DEC-SRC style like Baby Modula-3 (that's where hard part comes from, since it needs work and more work). But first the first, describe the Modula-3 in a sound way is one part of it, formalization of the Language Semantics is just another so one we can be absolutely sure of what we are doing (BTW the original implementation of it failed to finish, but LIME was 2 to 10 times faster than any of this market of the day, who knows what would like today be for doing that):
http://museum.ipsj.or.jp/en/computer/other/0008.html

Thanks in advance


--- El vie, 10/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com, "Dirk Muysers" <dmuysers at hotmail.com>
Fecha: viernes, 10 de febrero, 2012 12:00

Hi all:
in the sense of if at all wanted porting functionality to Modula-3 minimal functional subset language to allow such dynamic implementation and later on pass on Modula-3. 
There are some available Models of graft Modular concepts in functional-like languages worth of writing OSes on it (concurrent ones already objected oriented) like Clean and Concurrent Clean and Gofer:
http://www4.in.tum.de/~sihling/publications/1995/DA_Sihling.ps.gz

ftp://ftp.cs.york.ac.uk/pub/malcolm/thesis.ps.Z

Anyway just a possible path of action 
Thanks in advance

--- El vie, 10/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto:
 Re: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com, "Dirk Muysers" <dmuysers at hotmail.com>
Fecha: viernes, 10 de febrero, 2012 10:17

Hi all:
nice idea, once it's inly functional would it work for procedural languages?
The nice idea of this would port it to Module system of Modula-3 which as I understand (unless it's not Modula-3 own one) is a simplified version (most of researchers didn't concentrate on a single-separate compilation, but distributed aware compilation specially in Modula-2+, in Canada, one can ask the copy and they will send to you once you identify its name).
Thanks in advance

--- El
 vie, 10/2/12, Dirk Muysers <dmuysers at hotmail.com> escribi?:

De: Dirk Muysers <dmuysers at hotmail.com>
Asunto: [M3devel] platform-independent object file linking
Para: m3devel at elegosoft.com
Fecha: viernes, 10 de febrero, 2012 09:54



 


I recently came across an article that might 
interest the community:
?
A 
Compiler-Supported Unification of Static and Dynamic Loading
by Felix Friedrich and Florian Negele
?
It is about platform-independent linking and 
loading of modules.
The mechanism is explained?in context of 
the?A2 (ex-Bluebottle)
OS and the?Active Oberon language, but it is 
easily portable to
other?programming environments and 
languages.
Its adoption, at the cost of rewriting the backend 
and parts of
m3core,?would significantly?simplify the maintenance of M3 and
also render it independent from proprietary 
tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/0c74d194/attachment-0002.html>

From dabenavidesd at yahoo.es  Fri Feb 10 21:21:26 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 20:21:26 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
Message-ID: <1328905286.88292.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
It's not correct to release a product for bug fixing (unless is ESC annotations), but because that can be embarrassing, of course SW Engineering based on that is just ridiculous (and by the way the release cycle is something that community should decide, I agree with the idea of that way of releasing "bug fixes" rather than functional implementation correction and documentation in the other side).
But in any event, the idea of experimental platforms is not bad at all in a new release, since several backends have been like that and so, it needs to give more thought if it's? valuable? or not is debatable.
Thanks in advance 

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

De: felipe valdez <dataf4l at gmail.com>
Asunto: Re: [M3devel] Think we need a new release.
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: m3devel at elegosoft.com, vintagecoder at aol.com
Fecha: viernes, 10 de febrero, 2012 10:42

Mr VintageCoder, What is the purpose of a new release? 
from a technical perspective, probably not much

but from a marketing perspective (language adoption, language value perception), there could be a few. 

A compiler and runtime that work presumably only need fixes. 
that is correct. 

Are you talking about a major new version or a mod level or what? The last release on cm3 I see is from 2010.

 
this probably disproves the argument of "6 years between releases", however, in the fast moving tech world, some people could consider 2010 to be a long time ago.


 Are there bug fixes in the pipeline that haven't been verified? Are there fixes ready to go that no builds have been done for? What is the problem more frequent releases will solve? 


I think, it makes people perceive that the language has support, is being actively developed, is growing , and alsothat it is not dead.
I used to use tcl a lot, but I haven't got a new release in a while, and 8.6 took forever (5 years?) to get done.

this made me move away from the technology, since I saw it at the time, as stagnating, stale, old and unsupported.
had they put a "new" brand on it ever so often, I would have been more insterested.


in general terms, once you know perl 5.10, would you be more exicet about learning perl 6.0 or 5.10.1 ?I mean, seriously, who gives a damn about a 0.0.1 release anyway?


the problem I see a new release would solve, is that you get to fix stuff (like the string broken stuff) that needs fixing, without having to maintain 100% backwards compatibility, this can lead to a cleaner language, like python3000 broke a lot of things, for instance.

 Personally I see no benefit (indeed I see many disadvantges) to frequent releases of stable software.



this is als true, there are disadvantages and I also suffer a little from this.but surely not something we cannot live through, especially if there is some kind of guide (3to4 ?)



  But I often run backlevel intentionally.

 Firefox is being updated for many reasons including security holes, bug fixes, new standards, and more. If the Modula-3 standard hasn't been updated, what is driving the need for new release(s)?


if the language does not evolve, is it bound to die?if the standard does not evolve, should one consider it to be dead?see c++ for instance, recently, there have been changes to the language.

this motivates a lot of tuff:conferences, new compilers, new books, new blogposts, and in general, a lot of "hype"if m3 was hyped a little, perhaps it could gain developers.

by gaining such developers, perhaps more bugs could be removed and features could be added as well (for instance, in the library space, where I see that other language have better, more tested, and easier to use LIbraries, but this is , of course, a subjective declaration, and I don't expect anyone to agree with me).


 

 It looks like cm3 supports more platforms than I have. I would be willing to help out (I am not a UNIX developer) any way I could. I have Solaris Intel and SPARC boxes.
that Is wonderful news, I appreciate the offer, I hope the language improves, and your boxes serve the purpose!



 
On Fri, Feb 10, 2012 at 9:31 AM, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:


Hi all:

I think one of the purposes of that is more cross platform compatibility, perhaps put in place everything to a major update on platform but for alpha testing new JIT RTCG or so (arguably we could stay in odd numbers being platform development until we get to a new even number for product release), while most of developers might want or not to migrate it's necessary to establish priorities and so for having such a thing.



Thanks in advance



--- El vie, 10/2/12, Vintage Coder <vintagecoder at aol.com> escribi?:



> De: Vintage Coder <vintagecoder at aol.com>

> Asunto: Re: [M3devel] Think we need a new release.

> Para: m3devel at elegosoft.com

> Fecha: viernes, 10 de febrero, 2012 09:14

> What is the purpose of a new release?

> A compiler and runtime that work presumably only need fixes.

> Are you talking about a major new version or a mod level or

> what? The last release on cm3 I see is from 2010.

>

> Are there bug fixes in the pipeline that haven't been

> verified? Are there fixes ready to go that no builds have

> been done for? What is the problem more frequent releases

> will solve? Personally I see no benefit (indeed I see many

> disadvantges) to frequent releases of stable software. But I

> often run backlevel intentionally.

>

> Firefox is being updated for many reasons including security

> holes, bug fixes, new standards, and more. If the Modula-3

> standard hasn't been updated, what is driving the need for

> new release(s)?

>

> It looks like cm3 supports more platforms than I have. I

> would be willing to help out (I am not a UNIX developer) any

> way I could. I have Solaris Intel and SPARC boxes.

>

> ------Original Message------

> From: Peter McKinna

> To: m3devel at elegosoft.com

> Subject: [M3devel] Think we need a new release.

> Sent: 10 Feb 2012 05:01

>

> Been a long time between releases. Must be about time.

>

> Firefox is doing 6 weekly releases we are lucky if we get

> one every 6

> years. Sorry thats a bit harsh, all the same we need some

> new

> commitment.

>

> Regards Peter

>

>




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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120210/98d168e2/attachment-0002.html>

From m3 at sol42.com  Fri Feb 10 22:50:13 2012
From: m3 at sol42.com (m3 at sol42.com)
Date: Fri, 10 Feb 2012 22:50:13 +0100
Subject: [M3devel] Think we need a new release.
In-Reply-To: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>
References: <1126888101-1328883259-cardhu_decombobulator_blackberry.rim.net-2101843361-@b15.c1.bise3.blackberry>
Message-ID: <A0DF2CB8-A6D9-44B1-BC9B-B03DEEC9A52E@sol42.com>

On 10 Feb 2012, at 15:14, Vintage Coder wrote:
> What is the purpose of a new release? A compiler and runtime that work presumably only need fixes.

Agreed.  I can think of two reasons: adding "must have" stuff to the standard library, and fixing bugs or improving library, compiler, or runtime.  Note that "must have" should probably be evaluated in the context of systems programming, which is what Modula-3 is for.

Even adding new platforms should not require bumping the version number if it is the existing infrastructure that is being ported.

There are loads of "greatest next thing" languages out there that you have to re-learn every few releases.  Modula-3 is thankfully not one of them.  Want new stuff in the language?  Then you want Modula-3+ or Modula-4.

Regards.
-Daniel




From dabenavidesd at yahoo.es  Sat Feb 11 00:30:23 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 10 Feb 2012 23:30:23 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <A0DF2CB8-A6D9-44B1-BC9B-B03DEEC9A52E@sol42.com>
Message-ID: <1328916623.650.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
Modula-2+ distributed compiler didn't require languages changes but extensive testing and some distributed setting, which is why you need some sort of engineering process, at least is what I think that happens.
If you don't want dynamic compilation/interpretation that's up to one's needs, but currently most compilers do have some sort of dynamic interpretation capabilities, and being Modula-3 and innovative platform, it must have one. That's again what I think. I guess the way of not interrupting is just is m3-obliq stuff (since it's the scripting expression of Modula-3 RT) and prepare for the needed changes in the next big release. So for me would be like v 5.10 < 6.0
Thanks in advance

--- El vie, 10/2/12, m3 at sol42.com <m3 at sol42.com> escribi?:

> De: m3 at sol42.com <m3 at sol42.com>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 10 de febrero, 2012 16:50
> On 10 Feb 2012, at 15:14, Vintage
> Coder wrote:
> > What is the purpose of a new release? A compiler and
> runtime that work presumably only need fixes.
> 
> Agreed.  I can think of two reasons: adding "must have"
> stuff to the standard library, and fixing bugs or improving
> library, compiler, or runtime.  Note that "must have"
> should probably be evaluated in the context of systems
> programming, which is what Modula-3 is for.
> 
> Even adding new platforms should not require bumping the
> version number if it is the existing infrastructure that is
> being ported.
> 
> There are loads of "greatest next thing" languages out there
> that you have to re-learn every few releases.  Modula-3
> is thankfully not one of them.  Want new stuff in the
> language?  Then you want Modula-3+ or Modula-4.
> 
> Regards.
> -Daniel
> 
> 
> 


From dabenavidesd at yahoo.es  Sat Feb 11 02:37:37 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 11 Feb 2012 01:37:37 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <1328916623.650.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <1328924257.76277.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:

In case, you want the reference, and plus [1]:

At the time it was a kind of important to investigate [1] (for instance the ARX operating system it was a real issue for the day to day development) about Acorn in the 80's:
http://www.legacy.com/guestbook/mercurynews/guestbook.aspx?n=steve-glassman&pid=144489261&page=3

I guess in the case of a Microkernel and a huge UI libraries it might matter (Interfaces of 250k loc would would be good test case in terms of Modular verification it might matter, if the upper limit is O(n^5) actually to make that calculation makes an unknown prefix for that number power of ten, 26th order).

In the other hand you might want to leave like that but being one of the most important features to be able to program in the large, I feel this is better that the pain to wait that kind of operations (usually ESC ten times slower than compilation time).

[1] U. Postavsky, ?Distributed Compilation Using Distributed Shared Memory,? M.Sc., University of Toronto (Canada), Canada, 1990.


--- El vie, 10/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: "m3devel" <m3devel at elegosoft.com>, m3 at sol42.com
> Fecha: viernes, 10 de febrero, 2012 18:30
> Hi all:
> Modula-2+ distributed compiler didn't require languages
> changes but extensive testing and some distributed setting,
> which is why you need some sort of engineering process, at
> least is what I think that happens.
> If you don't want dynamic compilation/interpretation that's
> up to one's needs, but currently most compilers do have some
> sort of dynamic interpretation capabilities, and being
> Modula-3 and innovative platform, it must have one. That's
> again what I think. I guess the way of not interrupting is
> just is m3-obliq stuff (since it's the scripting expression
> of Modula-3 RT) and prepare for the needed changes in the
> next big release. So for me would be like v 5.10 < 6.0
> Thanks in advance
> 
> --- El vie, 10/2/12, m3 at sol42.com <m3 at sol42.com>
> escribi?:
> 
> > De: m3 at sol42.com <m3 at sol42.com>
> > Asunto: Re: [M3devel] Think we need a new release.
> > Para: "m3devel" <m3devel at elegosoft.com>
> > Fecha: viernes, 10 de febrero, 2012 16:50
> > On 10 Feb 2012, at 15:14, Vintage
> > Coder wrote:
> > > What is the purpose of a new release? A compiler
> and
> > runtime that work presumably only need fixes.
> > 
> > Agreed.  I can think of two reasons: adding "must
> have"
> > stuff to the standard library, and fixing bugs or
> improving
> > library, compiler, or runtime.  Note that "must
> have"
> > should probably be evaluated in the context of systems
> > programming, which is what Modula-3 is for.
> > 
> > Even adding new platforms should not require bumping
> the
> > version number if it is the existing infrastructure
> that is
> > being ported.
> > 
> > There are loads of "greatest next thing" languages out
> there
> > that you have to re-learn every few releases. 
> Modula-3
> > is thankfully not one of them.  Want new stuff in
> the
> > language?  Then you want Modula-3+ or Modula-4.
> > 
> > Regards.
> > -Daniel
> > 
> > 
> >
> 


From dabenavidesd at yahoo.es  Sun Feb 12 22:36:20 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 12 Feb 2012 21:36:20 +0000 (GMT)
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <20120209175908.GC13717@topoi.pooq.com>
Message-ID: <1329082580.11381.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
There is a compile-time switch to not generate code for <*ASSERT exp*> back in DEC-SRC days ("Front-end options"):
http://homepages.cs.ncl.ac.uk/c.r.snow/home.formal/html/oldmod3/html/m3/options.html#first-pass

And it's still there is CM3 ("compile options") if you care:
http://opencm3.net/doc/help/cm3/m3build/options.html

Good to know, I bet if you try it, it would "work" as you first results. Wouldn't it?

Thanks in advance

--- El jue, 9/2/12, Hendrik Boom <hendrik at topoi.pooq.com> escribi?:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] Assertion failed to complain
> Para: m3devel at elegosoft.com
> Fecha: jueves, 9 de febrero, 2012 12:59
> On Thu, Feb 09, 2012 at 05:51:24PM
> +0000, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > It might be that needs to be uppercase (in case
> compiler doesn't warn but I guess that would desired
> behavior, or not, since it would be unknown at compile
> time).
> > <*ASSERT exp*>
> > 
> > Thanks in advance
> 
> That was exactly it.  One of the few places where
> things are 
> case-sensitive, but a wrong case doesn't cause an error
> message.
> (in fact, it suppressed it)
> 
> Things are failing properly now.
> 
> -- hendrik
> 


From vintagecoder at aol.com  Mon Feb 13 15:06:30 2012
From: vintagecoder at aol.com (vintagecoder at aol.com)
Date: Mon, 13 Feb 2012 14:06:30 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <A0DF2CB8-A6D9-44B1-BC9B-B03DEEC9A52E@sol42.com>
Message-ID: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>

Hello Daniel,

> Agreed.  I can think of two reasons: adding "must have" stuff to the
> standard library, and fixing bugs or improving library, compiler, or
> runtime.  Note that "must have" should probably be evaluated in the
> context of systems programming, which is what Modula-3 is for.

For myself I tend to be very careful when it comes to "must have" in
language design. If you feel the language spec is outdated or insufficient,
then I think it's a dangerous, slippery slope to start adding features to
the language even if they are a must have, without a standards committee.
If people are not careful, they can turn a language that was designed well
into a junk heap before they know it. The threat to the death of a language
through inappropriate changes is far greater than the threat of death by
lack of changes.

If people agree the current spec is not sufficient, or wrong, it seems to
me the first step is to form a language specification committee where the
language can be carefully controlled- and this has to be from a purist
view of the language with no concern for implementation and no "baggage"
other than the existing language spec has to be respected- all the changes
have to be aligned and harmonious with the original purpose and intentions
and direction of Modula-3, otherwise what you said later about a new
language comes into play. Optional features have to be clearly optional-
extensions to the standard that don't make sense in the core have to be
clearly deliniated and the spec has to be amended cleanly to separate core
language, optional extensions, etc. The Ada specification is a good
document to look at for examples of how to do this.

> Even adding new platforms should not require bumping the version number
> if it is the existing infrastructure that is being ported.

Agreed.

> There are loads of "greatest next thing" languages out there that you
> have to re-learn every few releases.  Modula-3 is thankfully not one of
> them.

Agreed!

> Want new stuff in the language?  Then you want Modula-3+ or Modula-4.

Agreed again!

People are so used to constant turmoil because of Linux. I come from a much
different background and I value stability and evolution, not revolution.
New is not necessarily good just like old is not necessarily bad. Good
things pass the test of time and don't need constant changes. If we are
talking about changing the underlying implementation without changing the
language then of course this is fine and should not be held back. My
concern is about letting the implementation drive the specification- I feel
that is wrong, dangerous, and should be resisted.

Many languages today are out of control. To grow a language properly is an
extremely big challenge that has to be taken with a great deal of respect
and concern.


From vintagecoder at aol.com  Mon Feb 13 15:33:20 2012
From: vintagecoder at aol.com (vintagecoder at aol.com)
Date: Mon, 13 Feb 2012 14:33:20 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
Message-ID: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>

>> What is the purpose of a new release?
>
> from a technical perspective, probably not much but from a marketing
> perspective (language adoption, language value perception), there could
> be a few.

I realize my opinion is not the majority, but I'm less inclined to like
something that changes constantly or is popular. I try to find things that
are well designed and work. Constant releases are not on my list of
priorities.

>> Are you talking about a major new version or a mod level or what? The
>> last release on cm3 I see is from 2010.

> this probably disproves the argument of "6 years between releases",
> however, in the fast moving tech world, some people could consider 2010
> to be a long time ago.

Ok but anyone looking for Modula-3 should understand the history and
realize they are not interested in the latest language, if they were, they
wouldn't be in our group. I think that greatly lessens the impact of not
having frequent or regular releases. It's one of the reasons I joined the
development mailing list even though I probably have nothing to contribute
as a developer. I wanted to see if the project is alive. For me is seems it
is.

>> Are there bug fixes in the pipeline that haven't been verified? Are
>> there fixes ready to go that no builds have been done for? What is the
>> problem more frequent releases will solve?

> I think, it makes people perceive that the language has support, is being
> actively developed, is growing , and also that it is not dead.

For myself I was interested in those answers also, so I joined the mailing
list. I saw from the releases the project is going ahead. I see from the
fact they have so much platform support this is a serious and big project.
I have seen many other famous projects without nearly as much platform
support. I think anybody who is sincerely interested in Modula-3 can learn
you guys are serious and work is happening.

> I used to use tcl a lot, but I haven't got a new release in a while, and
> 8.6 took forever (5 years?) to get done. this made me move away from the
> technology, since I saw it at the time, as stagnating, stale, old and
> unsupported. 

That is very interesting because as someone looking for a new scripting
language, I found tcl very encouraging! I did the same thing as I did for
Modula-3. I followed the newsgroups and I saw people are using it. I saw
the releases and saw they are continuing to fix bugs. I don't need
something new, I need something good. Of course it's important the project
is alive and well so I don't find something good but dead. I saw tcl has
native support for sqlite and other interesting features. To me it looks
very much alive.

> had they put a "new" brand on it ever so often, I would have been more
> insterested. 

Ok but I think at some point people have to break the myth of constant
change as something favorable. 

> in general terms, once you know perl 5.10, would you be more exicet about
> learning perl 6.0 or 5.10.1 ? I mean, seriously, who gives a damn about a
> 0.0.1 release anyway?

It's not my view. I'm personally more happy with evolutionary growth. If
something isn't any good, I don't use it (unless I have to for work!) If
something is good, it doesn't need major changes, and changes are what
usually make things worse, not better. I realize my view might not be so
popular, but this is my view.

> the problem I see a new release would solve, is that you get to fix stuff
> (like the string broken stuff) that needs fixing, without having to
> maintain 100% backwards compatibility, this can lead to a cleaner
> language, like python3000 broke a lot of things, for instance.

I don't know Modula-3 (trying to learn it) enough to say what is broken.
But I do get nervous when I hear people say backwards compatibility isn't
important, and stands in the way of the future. For that I say if that is
really true, a group of people who really understand these things need to
carefully decide whether the language spec is broken or whether the
implementation is broken or both. And it has to be addressed based on the
outcome of that discussion, not by taking the situation too lightly. Just
to give you some idea of why I am saying this is because most of the
software I work on is 20 or more years old and I saw the value in having
experts who understand the purpose and the foundation involved in deciding
whether a new feature is good or not. Sometimes something looks very good
but it goes against the core direction. In this case a hard decision has to
be made to fork the product, or develop a new version. For a language it's
a very very serious process. If the spec is broken then perhaps it's time
to develop a new language as Daniel said. If the implementation is broken,
then sure it should be fixed to conform to the spec. But the main thing is
I believe especially for languages but for most software it is wrong and a
mistake to let the implentation drive the specification. You need to have
qualified good people managing the spec, and the implementation must come
after that.

>> Personally I see no benefit (indeed I see many disadvantges) to frequent
>> releases of stable software. 

> this is als true, there are disadvantages and I also suffer a little from
> this. but surely not something we cannot live through, especially if
> there is some kind of guide (3to4 ?)

I think I understand your point, but I feel this view is looking at the
language more like an OS. Languages and OS are very different creations. An
OS has to provide services to get work done. It doesn't necessarily have to
be pure because the end is more important than the means. But a language is
all about purity, otherwise all languages converge (indeed that is
happening!) and there becomes little value in any language since they all
do pretty much the same thing.

Language has to be about elegance and clarity in expression, and safety in
implementation so that the intent of the person using the language is
carried out as he expects, with no side effects or smoke and mirrors. For
this reason I am very opposed to growing languages without very careful
study by people who know the history and tradition of the language and give
it some degree of reverence.


>> But I often run backlevel intentionally. Firefox is being updated for
>> many reasons including security holes, bug fixes, new standards, and
>> more. If the Modula-3 standard hasn't been updated, what is driving the
>> need for new release(s)?

> if the language does not evolve, is it bound to die?

Not as far as I am concerned. But I still run programs in SNOBOL4 from
1969. YMMV ;-)

> if the standard does not evolve, should one consider it to be dead?

It might be dead, it might not. It all depends on whether the language is
still useful and people actually use it.

> see c++ for instance, recently, there have been changes to the language.
> this motivates a lot of tuff: conferences, new compilers, new books, new
> blogposts, and in general, a lot of "hype"

Right, but C++ has many problems and has popularity and issues Modula-3
happily doesn't have. If you are trying to compete with a mainstream
language you'll probably not be satisfied.

> if m3 was hyped a little, perhaps it could gain developers.

I think people who attracted by hype aren't the type of people who will
appreciate Modula-3.

> by gaining such developers, perhaps more bugs could be removed and
> features could be added as well (for instance, in the library space,
> where I see that other language have better, more tested, and easier to
> use LIbraries, but this is , of course, a subjective declaration, and I
> don't expect anyone to agree with me). 

I think it's important, just like in some other successful but maybe not so
elegant languages (C++, Java) to make a distinction between language and
libraries. Free Pascal seems to do this pretty well also. You (usually)
don't have to change the language spec or implementation to offer usable
libraries. If you do, it should be done carefully. But the language spec
should not be changed without much study and thought.

>> It looks like cm3 supports more platforms than I have. I would be
>> willing to help out (I am not a UNIX developer) any way I could. I have
>> Solaris Intel and SPARC boxes.
>
>that Is wonderful news, I appreciate the offer, I hope the language
>improves, and your boxes serve the purpose!

I see they already have SPARC Solaris support and I think x86 so I am not
able to offer anything new, but if I can help I will be glad to.

For me I am having a hard time finding learning materials. I think the
biggest boost to the language would come not from changing it or making new
releases, but to put together a really good book on Modula-3 and also
showing how cm3 implements it. The book should break these two things out
clearly so it could serve as a reference and guide to Modula-3 itself as
well as how to use cm3 to code in Modula-3. The main barrier to adoption
and new fans of Modula-3 is the lack of educational materials. You can
books on almost any topic on the net, but Modula-3 has almost nothing
available.



From dabenavidesd at yahoo.es  Mon Feb 13 17:08:53 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 13 Feb 2012 16:08:53 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>
Message-ID: <1329149333.68679.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:

To be honest, to make a language change (and of course I'm looking forward but respecting and acknowledging and respecting the path that brigs here) I'm not involved I'm not interested (so I realize your concern).
That's why, you know, I mentioned that we need to care about some issues so whoever comes later (in some time sadly or not many of our brains will be with more decades and some other will take that job of making it better this) will do it rightly.
Although I seem not care about us in the future I understand that we need more than a language revision (I'm not saying changes or update), we need:
1) Make the best effort we can (even that means some money) to try to recover design meetings, since there is already some bits in the SPWM3, I would like to recover the damaged tapes, if they ever really are somewhere and make the effort to at least recover the most of it. This to preserve that for posterity. I don't care more than if they are lost forever
2) Define Languages changes without experimenting makes no sense, so my thinking is that we need to implement gradually baby Modula-3 and start from there a serious (although painful) top down language definition according to the same rules defined or at least type compatible. If that needs human revision or machine learning I guess we would do that.
3) Whatever conclusion is taken a path of action will follow so anyone can always return to the point 1) until some agreement is made between all people.


Thanks in advance

--- El lun, 13/2/12, vintagecoder at aol.com <vintagecoder at aol.com> escribi?:

> De: vintagecoder at aol.com <vintagecoder at aol.com>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: m3devel at elegosoft.com
> Fecha: lunes, 13 de febrero, 2012 09:06
> Hello Daniel,
> 
> > Agreed.  I can think of two reasons: adding "must
> have" stuff to the
> > standard library, and fixing bugs or improving library,
> compiler, or
> > runtime.  Note that "must have" should probably be
> evaluated in the
> > context of systems programming, which is what Modula-3
> is for.
> 
> For myself I tend to be very careful when it comes to "must
> have" in
> language design. If you feel the language spec is outdated
> or insufficient,
> then I think it's a dangerous, slippery slope to start
> adding features to
> the language even if they are a must have, without a
> standards committee.
> If people are not careful, they can turn a language that was
> designed well
> into a junk heap before they know it. The threat to the
> death of a language
> through inappropriate changes is far greater than the threat
> of death by
> lack of changes.
> 
> If people agree the current spec is not sufficient, or
> wrong, it seems to
> me the first step is to form a language specification
> committee where the
> language can be carefully controlled- and this has to be
> from a purist
> view of the language with no concern for implementation and
> no "baggage"
> other than the existing language spec has to be respected-
> all the changes
> have to be aligned and harmonious with the original purpose
> and intentions
> and direction of Modula-3, otherwise what you said later
> about a new
> language comes into play. Optional features have to be
> clearly optional-
> extensions to the standard that don't make sense in the core
> have to be
> clearly deliniated and the spec has to be amended cleanly to
> separate core
> language, optional extensions, etc. The Ada specification is
> a good
> document to look at for examples of how to do this.
> 
> > Even adding new platforms should not require bumping
> the version number
> > if it is the existing infrastructure that is being
> ported.
> 
> Agreed.
> 
> > There are loads of "greatest next thing" languages out
> there that you
> > have to re-learn every few releases.  Modula-3 is
> thankfully not one of
> > them.
> 
> Agreed!
> 
> > Want new stuff in the language?  Then you want
> Modula-3+ or Modula-4.
> 
> Agreed again!
> 
> People are so used to constant turmoil because of Linux. I
> come from a much
> different background and I value stability and evolution,
> not revolution.
> New is not necessarily good just like old is not necessarily
> bad. Good
> things pass the test of time and don't need constant
> changes. If we are
> talking about changing the underlying implementation without
> changing the
> language then of course this is fine and should not be held
> back. My
> concern is about letting the implementation drive the
> specification- I feel
> that is wrong, dangerous, and should be resisted.
> 
> Many languages today are out of control. To grow a language
> properly is an
> extremely big challenge that has to be taken with a great
> deal of respect
> and concern.
> 


From vintagecoder at aol.com  Mon Feb 13 17:31:41 2012
From: vintagecoder at aol.com (Vintage Coder)
Date: Mon, 13 Feb 2012 16:31:41 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <CAGi-_-8bycGnCQekUFbABoYy1u9e0Otujvh-985CV90Wc5cH6g@mail.gmail.com>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
	<CAGi-_-8bycGnCQekUFbABoYy1u9e0Otujvh-985CV90Wc5cH6g@mail.gmail.com>
Message-ID: <367439191-1329150681-cardhu_decombobulator_blackberry.rim.net-766960143-@b15.c1.bise3.blackberry>

A video is "nice to have" but it wasn't what I am talking about. Nothing can replace a good book when it comes to learning a new language. 

The Ada wikibook is an example of a possible starting point. 

-----Original Message-----
From: felipe valdez <dataf4l at gmail.com>
Date: Mon, 13 Feb 2012 11:03:33 
To: <vintagecoder at aol.com>
Cc: <m3devel at elegosoft.com>
Subject: Re: [M3devel] Think we need a new release.

I recommend the video tutorial format, as I always have.


On Mon, Feb 13, 2012 at 9:33 AM,  <vintagecoder at aol.com> wrote:
>>> What is the purpose of a new release?
>>
>> from a technical perspective, probably not much but from a marketing
>> perspective (language adoption, language value perception), there could
>> be a few.
>
> I realize my opinion is not the majority, but I'm less inclined to like
> something that changes constantly or is popular. I try to find things that
> are well designed and work. Constant releases are not on my list of
> priorities.
>
>>> Are you talking about a major new version or a mod level or what? The
>>> last release on cm3 I see is from 2010.
>
>> this probably disproves the argument of "6 years between releases",
>> however, in the fast moving tech world, some people could consider 2010
>> to be a long time ago.
>
> Ok but anyone looking for Modula-3 should understand the history and
> realize they are not interested in the latest language, if they were, they
> wouldn't be in our group. I think that greatly lessens the impact of not
> having frequent or regular releases. It's one of the reasons I joined the
> development mailing list even though I probably have nothing to contribute
> as a developer. I wanted to see if the project is alive. For me is seems it
> is.
>
>>> Are there bug fixes in the pipeline that haven't been verified? Are
>>> there fixes ready to go that no builds have been done for? What is the
>>> problem more frequent releases will solve?
>
>> I think, it makes people perceive that the language has support, is being
>> actively developed, is growing , and also that it is not dead.
>
> For myself I was interested in those answers also, so I joined the mailing
> list. I saw from the releases the project is going ahead. I see from the
> fact they have so much platform support this is a serious and big project.
> I have seen many other famous projects without nearly as much platform
> support. I think anybody who is sincerely interested in Modula-3 can learn
> you guys are serious and work is happening.
>
>> I used to use tcl a lot, but I haven't got a new release in a while, and
>> 8.6 took forever (5 years?) to get done. this made me move away from the
>> technology, since I saw it at the time, as stagnating, stale, old and
>> unsupported.
>
> That is very interesting because as someone looking for a new scripting
> language, I found tcl very encouraging! I did the same thing as I did for
> Modula-3. I followed the newsgroups and I saw people are using it. I saw
> the releases and saw they are continuing to fix bugs. I don't need
> something new, I need something good. Of course it's important the project
> is alive and well so I don't find something good but dead. I saw tcl has
> native support for sqlite and other interesting features. To me it looks
> very much alive.
>
>> had they put a "new" brand on it ever so often, I would have been more
>> insterested.
>
> Ok but I think at some point people have to break the myth of constant
> change as something favorable.
>
>> in general terms, once you know perl 5.10, would you be more exicet about
>> learning perl 6.0 or 5.10.1 ? I mean, seriously, who gives a damn about a
>> 0.0.1 release anyway?
>
> It's not my view. I'm personally more happy with evolutionary growth. If
> something isn't any good, I don't use it (unless I have to for work!) If
> something is good, it doesn't need major changes, and changes are what
> usually make things worse, not better. I realize my view might not be so
> popular, but this is my view.
>
>> the problem I see a new release would solve, is that you get to fix stuff
>> (like the string broken stuff) that needs fixing, without having to
>> maintain 100% backwards compatibility, this can lead to a cleaner
>> language, like python3000 broke a lot of things, for instance.
>
> I don't know Modula-3 (trying to learn it) enough to say what is broken.
> But I do get nervous when I hear people say backwards compatibility isn't
> important, and stands in the way of the future. For that I say if that is
> really true, a group of people who really understand these things need to
> carefully decide whether the language spec is broken or whether the
> implementation is broken or both. And it has to be addressed based on the
> outcome of that discussion, not by taking the situation too lightly. Just
> to give you some idea of why I am saying this is because most of the
> software I work on is 20 or more years old and I saw the value in having
> experts who understand the purpose and the foundation involved in deciding
> whether a new feature is good or not. Sometimes something looks very good
> but it goes against the core direction. In this case a hard decision has to
> be made to fork the product, or develop a new version. For a language it's
> a very very serious process. If the spec is broken then perhaps it's time
> to develop a new language as Daniel said. If the implementation is broken,
> then sure it should be fixed to conform to the spec. But the main thing is
> I believe especially for languages but for most software it is wrong and a
> mistake to let the implentation drive the specification. You need to have
> qualified good people managing the spec, and the implementation must come
> after that.
>
>>> Personally I see no benefit (indeed I see many disadvantges) to frequent
>>> releases of stable software.
>
>> this is als true, there are disadvantages and I also suffer a little from
>> this. but surely not something we cannot live through, especially if
>> there is some kind of guide (3to4 ?)
>
> I think I understand your point, but I feel this view is looking at the
> language more like an OS. Languages and OS are very different creations. An
> OS has to provide services to get work done. It doesn't necessarily have to
> be pure because the end is more important than the means. But a language is
> all about purity, otherwise all languages converge (indeed that is
> happening!) and there becomes little value in any language since they all
> do pretty much the same thing.
>
> Language has to be about elegance and clarity in expression, and safety in
> implementation so that the intent of the person using the language is
> carried out as he expects, with no side effects or smoke and mirrors. For
> this reason I am very opposed to growing languages without very careful
> study by people who know the history and tradition of the language and give
> it some degree of reverence.
>
>
>>> But I often run backlevel intentionally. Firefox is being updated for
>>> many reasons including security holes, bug fixes, new standards, and
>>> more. If the Modula-3 standard hasn't been updated, what is driving the
>>> need for new release(s)?
>
>> if the language does not evolve, is it bound to die?
>
> Not as far as I am concerned. But I still run programs in SNOBOL4 from
> 1969. YMMV ;-)
>
>> if the standard does not evolve, should one consider it to be dead?
>
> It might be dead, it might not. It all depends on whether the language is
> still useful and people actually use it.
>
>> see c++ for instance, recently, there have been changes to the language.
>> this motivates a lot of tuff: conferences, new compilers, new books, new
>> blogposts, and in general, a lot of "hype"
>
> Right, but C++ has many problems and has popularity and issues Modula-3
> happily doesn't have. If you are trying to compete with a mainstream
> language you'll probably not be satisfied.
>
>> if m3 was hyped a little, perhaps it could gain developers.
>
> I think people who attracted by hype aren't the type of people who will
> appreciate Modula-3.
>
>> by gaining such developers, perhaps more bugs could be removed and
>> features could be added as well (for instance, in the library space,
>> where I see that other language have better, more tested, and easier to
>> use LIbraries, but this is , of course, a subjective declaration, and I
>> don't expect anyone to agree with me).
>
> I think it's important, just like in some other successful but maybe not so
> elegant languages (C++, Java) to make a distinction between language and
> libraries. Free Pascal seems to do this pretty well also. You (usually)
> don't have to change the language spec or implementation to offer usable
> libraries. If you do, it should be done carefully. But the language spec
> should not be changed without much study and thought.
>
>>> It looks like cm3 supports more platforms than I have. I would be
>>> willing to help out (I am not a UNIX developer) any way I could. I have
>>> Solaris Intel and SPARC boxes.
>>
>>that Is wonderful news, I appreciate the offer, I hope the language
>>improves, and your boxes serve the purpose!
>
> I see they already have SPARC Solaris support and I think x86 so I am not
> able to offer anything new, but if I can help I will be glad to.
>
> For me I am having a hard time finding learning materials. I think the
> biggest boost to the language would come not from changing it or making new
> releases, but to put together a really good book on Modula-3 and also
> showing how cm3 implements it. The book should break these two things out
> clearly so it could serve as a reference and guide to Modula-3 itself as
> well as how to use cm3 to code in Modula-3. The main barrier to adoption
> and new fans of Modula-3 is the lack of educational materials. You can
> books on almost any topic on the net, but Modula-3 has almost nothing
> available.
>



-- 
312-444-2124
Skype: f3l.headhunter
Casa: 8043901

From dataf4l at gmail.com  Mon Feb 13 17:03:33 2012
From: dataf4l at gmail.com (felipe valdez)
Date: Mon, 13 Feb 2012 11:03:33 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
Message-ID: <CAGi-_-8bycGnCQekUFbABoYy1u9e0Otujvh-985CV90Wc5cH6g@mail.gmail.com>

I recommend the video tutorial format, as I always have.


On Mon, Feb 13, 2012 at 9:33 AM,  <vintagecoder at aol.com> wrote:
>>> What is the purpose of a new release?
>>
>> from a technical perspective, probably not much but from a marketing
>> perspective (language adoption, language value perception), there could
>> be a few.
>
> I realize my opinion is not the majority, but I'm less inclined to like
> something that changes constantly or is popular. I try to find things that
> are well designed and work. Constant releases are not on my list of
> priorities.
>
>>> Are you talking about a major new version or a mod level or what? The
>>> last release on cm3 I see is from 2010.
>
>> this probably disproves the argument of "6 years between releases",
>> however, in the fast moving tech world, some people could consider 2010
>> to be a long time ago.
>
> Ok but anyone looking for Modula-3 should understand the history and
> realize they are not interested in the latest language, if they were, they
> wouldn't be in our group. I think that greatly lessens the impact of not
> having frequent or regular releases. It's one of the reasons I joined the
> development mailing list even though I probably have nothing to contribute
> as a developer. I wanted to see if the project is alive. For me is seems it
> is.
>
>>> Are there bug fixes in the pipeline that haven't been verified? Are
>>> there fixes ready to go that no builds have been done for? What is the
>>> problem more frequent releases will solve?
>
>> I think, it makes people perceive that the language has support, is being
>> actively developed, is growing , and also that it is not dead.
>
> For myself I was interested in those answers also, so I joined the mailing
> list. I saw from the releases the project is going ahead. I see from the
> fact they have so much platform support this is a serious and big project.
> I have seen many other famous projects without nearly as much platform
> support. I think anybody who is sincerely interested in Modula-3 can learn
> you guys are serious and work is happening.
>
>> I used to use tcl a lot, but I haven't got a new release in a while, and
>> 8.6 took forever (5 years?) to get done. this made me move away from the
>> technology, since I saw it at the time, as stagnating, stale, old and
>> unsupported.
>
> That is very interesting because as someone looking for a new scripting
> language, I found tcl very encouraging! I did the same thing as I did for
> Modula-3. I followed the newsgroups and I saw people are using it. I saw
> the releases and saw they are continuing to fix bugs. I don't need
> something new, I need something good. Of course it's important the project
> is alive and well so I don't find something good but dead. I saw tcl has
> native support for sqlite and other interesting features. To me it looks
> very much alive.
>
>> had they put a "new" brand on it ever so often, I would have been more
>> insterested.
>
> Ok but I think at some point people have to break the myth of constant
> change as something favorable.
>
>> in general terms, once you know perl 5.10, would you be more exicet about
>> learning perl 6.0 or 5.10.1 ? I mean, seriously, who gives a damn about a
>> 0.0.1 release anyway?
>
> It's not my view. I'm personally more happy with evolutionary growth. If
> something isn't any good, I don't use it (unless I have to for work!) If
> something is good, it doesn't need major changes, and changes are what
> usually make things worse, not better. I realize my view might not be so
> popular, but this is my view.
>
>> the problem I see a new release would solve, is that you get to fix stuff
>> (like the string broken stuff) that needs fixing, without having to
>> maintain 100% backwards compatibility, this can lead to a cleaner
>> language, like python3000 broke a lot of things, for instance.
>
> I don't know Modula-3 (trying to learn it) enough to say what is broken.
> But I do get nervous when I hear people say backwards compatibility isn't
> important, and stands in the way of the future. For that I say if that is
> really true, a group of people who really understand these things need to
> carefully decide whether the language spec is broken or whether the
> implementation is broken or both. And it has to be addressed based on the
> outcome of that discussion, not by taking the situation too lightly. Just
> to give you some idea of why I am saying this is because most of the
> software I work on is 20 or more years old and I saw the value in having
> experts who understand the purpose and the foundation involved in deciding
> whether a new feature is good or not. Sometimes something looks very good
> but it goes against the core direction. In this case a hard decision has to
> be made to fork the product, or develop a new version. For a language it's
> a very very serious process. If the spec is broken then perhaps it's time
> to develop a new language as Daniel said. If the implementation is broken,
> then sure it should be fixed to conform to the spec. But the main thing is
> I believe especially for languages but for most software it is wrong and a
> mistake to let the implentation drive the specification. You need to have
> qualified good people managing the spec, and the implementation must come
> after that.
>
>>> Personally I see no benefit (indeed I see many disadvantges) to frequent
>>> releases of stable software.
>
>> this is als true, there are disadvantages and I also suffer a little from
>> this. but surely not something we cannot live through, especially if
>> there is some kind of guide (3to4 ?)
>
> I think I understand your point, but I feel this view is looking at the
> language more like an OS. Languages and OS are very different creations. An
> OS has to provide services to get work done. It doesn't necessarily have to
> be pure because the end is more important than the means. But a language is
> all about purity, otherwise all languages converge (indeed that is
> happening!) and there becomes little value in any language since they all
> do pretty much the same thing.
>
> Language has to be about elegance and clarity in expression, and safety in
> implementation so that the intent of the person using the language is
> carried out as he expects, with no side effects or smoke and mirrors. For
> this reason I am very opposed to growing languages without very careful
> study by people who know the history and tradition of the language and give
> it some degree of reverence.
>
>
>>> But I often run backlevel intentionally. Firefox is being updated for
>>> many reasons including security holes, bug fixes, new standards, and
>>> more. If the Modula-3 standard hasn't been updated, what is driving the
>>> need for new release(s)?
>
>> if the language does not evolve, is it bound to die?
>
> Not as far as I am concerned. But I still run programs in SNOBOL4 from
> 1969. YMMV ;-)
>
>> if the standard does not evolve, should one consider it to be dead?
>
> It might be dead, it might not. It all depends on whether the language is
> still useful and people actually use it.
>
>> see c++ for instance, recently, there have been changes to the language.
>> this motivates a lot of tuff: conferences, new compilers, new books, new
>> blogposts, and in general, a lot of "hype"
>
> Right, but C++ has many problems and has popularity and issues Modula-3
> happily doesn't have. If you are trying to compete with a mainstream
> language you'll probably not be satisfied.
>
>> if m3 was hyped a little, perhaps it could gain developers.
>
> I think people who attracted by hype aren't the type of people who will
> appreciate Modula-3.
>
>> by gaining such developers, perhaps more bugs could be removed and
>> features could be added as well (for instance, in the library space,
>> where I see that other language have better, more tested, and easier to
>> use LIbraries, but this is , of course, a subjective declaration, and I
>> don't expect anyone to agree with me).
>
> I think it's important, just like in some other successful but maybe not so
> elegant languages (C++, Java) to make a distinction between language and
> libraries. Free Pascal seems to do this pretty well also. You (usually)
> don't have to change the language spec or implementation to offer usable
> libraries. If you do, it should be done carefully. But the language spec
> should not be changed without much study and thought.
>
>>> It looks like cm3 supports more platforms than I have. I would be
>>> willing to help out (I am not a UNIX developer) any way I could. I have
>>> Solaris Intel and SPARC boxes.
>>
>>that Is wonderful news, I appreciate the offer, I hope the language
>>improves, and your boxes serve the purpose!
>
> I see they already have SPARC Solaris support and I think x86 so I am not
> able to offer anything new, but if I can help I will be glad to.
>
> For me I am having a hard time finding learning materials. I think the
> biggest boost to the language would come not from changing it or making new
> releases, but to put together a really good book on Modula-3 and also
> showing how cm3 implements it. The book should break these two things out
> clearly so it could serve as a reference and guide to Modula-3 itself as
> well as how to use cm3 to code in Modula-3. The main barrier to adoption
> and new fans of Modula-3 is the lack of educational materials. You can
> books on almost any topic on the net, but Modula-3 has almost nothing
> available.
>



-- 
312-444-2124
Skype: f3l.headhunter
Casa: 8043901


From rodney_bates at lcwb.coop  Mon Feb 13 18:31:04 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 13 Feb 2012 11:31:04 -0600
Subject: [M3devel] Think we need a new release.
In-Reply-To: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>
References: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>
Message-ID: <4F3948D8.6000004@lcwb.coop>

This discussion reminds me of my first full-time software job.  The
division manager had a graph on his wall of bugs fixed per month.  He
considered a high fix rate evidence of success.  Some of us sat around
laughing about the incentives that created.

I also recall a wonderfully-written story about an aging programmer
who protected his job against the youth-is-smartest culture by keeping
carefully planned bugs in code that only he could fix.

I really do think the low level of activity in both the language
and its implementations reflects their having been done well to begin
with.  Unfortunately, I don't know how to sell that idea.  A lot of
people think like that division manager.

On 02/13/2012 08:06 AM, vintagecoder at aol.com wrote:
> Hello Daniel,
>
>> Agreed.  I can think of two reasons: adding "must have" stuff to the
>> standard library, and fixing bugs or improving library, compiler, or
>> runtime.  Note that "must have" should probably be evaluated in the
>> context of systems programming, which is what Modula-3 is for.
>
> For myself I tend to be very careful when it comes to "must have" in
> language design. If you feel the language spec is outdated or insufficient,
> then I think it's a dangerous, slippery slope to start adding features to
> the language even if they are a must have, without a standards committee.
> If people are not careful, they can turn a language that was designed well
> into a junk heap before they know it. The threat to the death of a language
> through inappropriate changes is far greater than the threat of death by
> lack of changes.
>
> If people agree the current spec is not sufficient, or wrong, it seems to
> me the first step is to form a language specification committee where the
> language can be carefully controlled- and this has to be from a purist
> view of the language with no concern for implementation and no "baggage"
> other than the existing language spec has to be respected- all the changes
> have to be aligned and harmonious with the original purpose and intentions
> and direction of Modula-3, otherwise what you said later about a new
> language comes into play. Optional features have to be clearly optional-
> extensions to the standard that don't make sense in the core have to be
> clearly deliniated and the spec has to be amended cleanly to separate core
> language, optional extensions, etc. The Ada specification is a good
> document to look at for examples of how to do this.
>
>> Even adding new platforms should not require bumping the version number
>> if it is the existing infrastructure that is being ported.
>
> Agreed.
>
>> There are loads of "greatest next thing" languages out there that you
>> have to re-learn every few releases.  Modula-3 is thankfully not one of
>> them.
>
> Agreed!
>
>> Want new stuff in the language?  Then you want Modula-3+ or Modula-4.
>
> Agreed again!
>
> People are so used to constant turmoil because of Linux. I come from a much
> different background and I value stability and evolution, not revolution.
> New is not necessarily good just like old is not necessarily bad. Good
> things pass the test of time and don't need constant changes. If we are
> talking about changing the underlying implementation without changing the
> language then of course this is fine and should not be held back. My
> concern is about letting the implementation drive the specification- I feel
> that is wrong, dangerous, and should be resisted.
>
> Many languages today are out of control. To grow a language properly is an
> extremely big challenge that has to be taken with a great deal of respect
> and concern.
>


From rcolebur at SCIRES.COM  Mon Feb 13 21:32:10 2012
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 13 Feb 2012 15:32:10 -0500
Subject: [M3devel] Think we need a new release.
In-Reply-To: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>


>>For me I am having a hard time finding learning materials. I think the biggest boost to the language would 

Dear Vintage Coder:

The best books I have read on learning Modula-3 are:

1. Systems Programming with Modula-3, ed. Greg Nelson, ISBN 0-13-590464-1

2. Modula-3, Samuel P. Harbison, ISBN 0-13-596396-6

3. Programming in Modula-3, An Introduction in Programming with Style, Laszlo Boszormenyi & Carsten Weich, ISBN 3-540-57912-5

4. Algorithms in Modula-3, Robert Sedgewick, ISBN 0-201-53351-0

Regards,
Randy Coleburn


From dabenavidesd at yahoo.es  Mon Feb 13 21:36:08 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 13 Feb 2012 20:36:08 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <4F3948D8.6000004@lcwb.coop>
Message-ID: <1329165368.51042.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
In any case wondering whether he looses or not, fixing bugs is an important task in all computer programs, that's why ESC and others are important. But if you see those technologies back then were unsuccessful to find much use (because Modula-3 sources had not much RT errors, in Rd/Wr implementations, more in UI libraries), but just because doing annotations that restriction eases the test automation but costs are somehow seen as too high for doing that (even as relaxed in ESC/Java) respect of fixing them in the later stages (something they can compare because if they didn't use that tool they would know how much burden can be for doing that).
In reality people don't code faster but making painfully "slow releases" shows the "importance" of their work (and by that lack of productivity which is an symptom of the Crisis, and one of Objective of ESC).
GN asked why not produce code checkers that spend more computer time (even if they take extra time than night builds), well that's the reason, because they don't want to do that, they want short releases and bug-fixing by hand. 
That's why in the other hand Software Engineering is in Crisis, spending time in bugs fixes rather than writing code is another symptom Software crisis itself..
I will replay Greg Nelson lecture in U of Washington, I assume some principles are applied aside of checkers in systems development like in VHDL and some other tools:
http://www.uwtv.org/video/player.aspx?mediaid=1577083988

Of course there is a possible answer to that question, in the context of another Static checker, but my knowledge of that is it isn't operated  with that other checker or anything else (which was necessary in ESC case). This is if the program makes a big O() function I don't know.

Thanks in advance  



--- El lun, 13/2/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: m3devel at elegosoft.com
> Fecha: lunes, 13 de febrero, 2012 12:31
> This discussion reminds me of my
> first full-time software job.  The
> division manager had a graph on his wall of bugs fixed per
> month.  He
> considered a high fix rate evidence of success.  Some
> of us sat around
> laughing about the incentives that created.
> 
> I also recall a wonderfully-written story about an aging
> programmer
> who protected his job against the youth-is-smartest culture
> by keeping
> carefully planned bugs in code that only he could fix.
> 
> I really do think the low level of activity in both the
> language
> and its implementations reflects their having been done well
> to begin
> with.  Unfortunately, I don't know how to sell that
> idea.  A lot of
> people think like that division manager.
> 
> On 02/13/2012 08:06 AM, vintagecoder at aol.com
> wrote:
> > Hello Daniel,
> >
> >> Agreed.  I can think of two reasons: adding
> "must have" stuff to the
> >> standard library, and fixing bugs or improving
> library, compiler, or
> >> runtime.  Note that "must have" should
> probably be evaluated in the
> >> context of systems programming, which is what
> Modula-3 is for.
> >
> > For myself I tend to be very careful when it comes to
> "must have" in
> > language design. If you feel the language spec is
> outdated or insufficient,
> > then I think it's a dangerous, slippery slope to start
> adding features to
> > the language even if they are a must have, without a
> standards committee.
> > If people are not careful, they can turn a language
> that was designed well
> > into a junk heap before they know it. The threat to the
> death of a language
> > through inappropriate changes is far greater than the
> threat of death by
> > lack of changes.
> >
> > If people agree the current spec is not sufficient, or
> wrong, it seems to
> > me the first step is to form a language specification
> committee where the
> > language can be carefully controlled- and this has to
> be from a purist
> > view of the language with no concern for implementation
> and no "baggage"
> > other than the existing language spec has to be
> respected- all the changes
> > have to be aligned and harmonious with the original
> purpose and intentions
> > and direction of Modula-3, otherwise what you said
> later about a new
> > language comes into play. Optional features have to be
> clearly optional-
> > extensions to the standard that don't make sense in the
> core have to be
> > clearly deliniated and the spec has to be amended
> cleanly to separate core
> > language, optional extensions, etc. The Ada
> specification is a good
> > document to look at for examples of how to do this.
> >
> >> Even adding new platforms should not require
> bumping the version number
> >> if it is the existing infrastructure that is being
> ported.
> >
> > Agreed.
> >
> >> There are loads of "greatest next thing" languages
> out there that you
> >> have to re-learn every few releases.  Modula-3
> is thankfully not one of
> >> them.
> >
> > Agreed!
> >
> >> Want new stuff in the language?  Then you want
> Modula-3+ or Modula-4.
> >
> > Agreed again!
> >
> > People are so used to constant turmoil because of
> Linux. I come from a much
> > different background and I value stability and
> evolution, not revolution.
> > New is not necessarily good just like old is not
> necessarily bad. Good
> > things pass the test of time and don't need constant
> changes. If we are
> > talking about changing the underlying implementation
> without changing the
> > language then of course this is fine and should not be
> held back. My
> > concern is about letting the implementation drive the
> specification- I feel
> > that is wrong, dangerous, and should be resisted.
> >
> > Many languages today are out of control. To grow a
> language properly is an
> > extremely big challenge that has to be taken with a
> great deal of respect
> > and concern.
> >
> 


From lemming at henning-thielemann.de  Mon Feb 13 22:03:12 2012
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 13 Feb 2012 22:03:12 +0100 (CET)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
	<D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>
Message-ID: <alpine.DEB.2.00.1202132200360.16675@anubis.informatik.uni-halle.de>


On Mon, 13 Feb 2012, Coleburn, Randy wrote:

> 1. Systems Programming with Modula-3, ed. Greg Nelson, ISBN 0-13-590464-1
>
> 2. Modula-3, Samuel P. Harbison, ISBN 0-13-596396-6
>
> 3. Programming in Modula-3, An Introduction in Programming with Style, Laszlo Boszormenyi & Carsten Weich, ISBN 3-540-57912-5
>
> 4. Algorithms in Modula-3, Robert Sedgewick, ISBN 0-201-53351-0

I must say, that I was disappointed about the Sedgewick book, because it 
does not use any Modula-3 feature, no enumerations, no NEW, but instead 
global variables. Thus nothing you can learn good style Modula-3 
programming from.


From mika at async.caltech.edu  Mon Feb 13 22:28:43 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Mon, 13 Feb 2012 13:28:43 -0800
Subject: [M3devel] Think we need a new release.
In-Reply-To: <alpine.DEB.2.00.1202132200360.16675@anubis.informatik.uni-halle.de>
References: <CAGi-_-9sqAhEM2KfzXQ+1-YxPQ+fW4xbQyhf_yOHH7s9gE-0Yw@mail.gmail.com>
	<201202131433.q1DEXO6q014538@imr-db02.mx.aol.com>
	<D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>
	<alpine.DEB.2.00.1202132200360.16675@anubis.informatik.uni-halle.de>
Message-ID: <20120213212843.80A2F1A205B@async.async.caltech.edu>


I must say I have found few resources better for learning decent software
engineering techniques than just reading some of the sources from SRC.
The Modula-3 library (libm3) in particular.

    Mika


Henning Thielemann writes:
>
>On Mon, 13 Feb 2012, Coleburn, Randy wrote:
>
>> 1. Systems Programming with Modula-3, ed. Greg Nelson, ISBN 0-13-590464-1
>>
>> 2. Modula-3, Samuel P. Harbison, ISBN 0-13-596396-6
>>
>> 3. Programming in Modula-3, An Introduction in Programming with Style, Laszlo Boszormenyi & Carsten Weich, ISBN 3-540-57912-5
>>
>> 4. Algorithms in Modula-3, Robert Sedgewick, ISBN 0-201-53351-0
>
>I must say, that I was disappointed about the Sedgewick book, because it 
>does not use any Modula-3 feature, no enumerations, no NEW, but instead 
>global variables. Thus nothing you can learn good style Modula-3 
>programming from.


From dabenavidesd at yahoo.es  Mon Feb 13 22:26:37 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 13 Feb 2012 21:26:37 +0000 (GMT)
Subject: [M3devel] Think we need a new release.
In-Reply-To: <alpine.DEB.2.00.1202132200360.16675@anubis.informatik.uni-halle.de>
Message-ID: <1329168397.15682.YahooMailClassic@web29703.mail.ird.yahoo.com>

Hi all:
in defense of the author's work I have read that someones () wanted a library of Algorithm Animations for accompanying the book and DEC-SRC distribution or so.
Since the Algorithm animations festivals held in DEC-SRC were before 1994, and some animations done before were decommissioned some time ago, it remains uncertain how many animations were done with Modula-3 at DEC-SRC:
http://www.internotesstrategy.com/softwareengg.php#

Perhpas the most advanced are there.
Thanks in advance 
 

--- El lun, 13/2/12, Henning Thielemann <lemming at henning-thielemann.de> escribi?:

> De: Henning Thielemann <lemming at henning-thielemann.de>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: "Coleburn, Randy" <rcolebur at SCIRES.COM>
> CC: "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: lunes, 13 de febrero, 2012 16:03
> 
> On Mon, 13 Feb 2012, Coleburn, Randy wrote:
> 
> > 1. Systems Programming with Modula-3, ed. Greg Nelson,
> ISBN 0-13-590464-1
> >
> > 2. Modula-3, Samuel P. Harbison, ISBN 0-13-596396-6
> >
> > 3. Programming in Modula-3, An Introduction in
> Programming with Style, Laszlo Boszormenyi & Carsten
> Weich, ISBN 3-540-57912-5
> >
> > 4. Algorithms in Modula-3, Robert Sedgewick, ISBN
> 0-201-53351-0
> 
> I must say, that I was disappointed about the Sedgewick
> book, because it 
> does not use any Modula-3 feature, no enumerations, no NEW,
> but instead 
> global variables. Thus nothing you can learn good style
> Modula-3 
> programming from.
> 


From jay.krell at cornell.edu  Tue Feb 14 02:21:23 2012
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 14 Feb 2012 01:21:23 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <4F3948D8.6000004@lcwb.coop>
References: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>,
	<4F3948D8.6000004@lcwb.coop>
Message-ID: <COL101-W552255EAA304C6746012F7E67C0@phx.gbl>


> I really do think the low level of activity in both the language
> and its implementations reflects their having been done well to begin
> with.  Unfortunately, I don't know how to sell that idea.  A lot of
> people think like that division manager.
I agree.But there is still work to do.Mainly increase portability and decrease platform-dependentness.    backend: such as via the existing M3x86, or LLVM     library: cooperative suspend   And/or at least update to newer gcc.  Improve debugging with stock gdb.  A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...  - Jay > Date: Mon, 13 Feb 2012 11:31:04 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Think we need a new release.
> 
> This discussion reminds me of my first full-time software job.  The
> division manager had a graph on his wall of bugs fixed per month.  He
> considered a high fix rate evidence of success.  Some of us sat around
> laughing about the incentives that created.
> 
> I also recall a wonderfully-written story about an aging programmer
> who protected his job against the youth-is-smartest culture by keeping
> carefully planned bugs in code that only he could fix.
> 
> I really do think the low level of activity in both the language
> and its implementations reflects their having been done well to begin
> with.  Unfortunately, I don't know how to sell that idea.  A lot of
> people think like that division manager.
> 
> On 02/13/2012 08:06 AM, vintagecoder at aol.com wrote:
> > Hello Daniel,
> >
> >> Agreed.  I can think of two reasons: adding "must have" stuff to the
> >> standard library, and fixing bugs or improving library, compiler, or
> >> runtime.  Note that "must have" should probably be evaluated in the
> >> context of systems programming, which is what Modula-3 is for.
> >
> > For myself I tend to be very careful when it comes to "must have" in
> > language design. If you feel the language spec is outdated or insufficient,
> > then I think it's a dangerous, slippery slope to start adding features to
> > the language even if they are a must have, without a standards committee.
> > If people are not careful, they can turn a language that was designed well
> > into a junk heap before they know it. The threat to the death of a language
> > through inappropriate changes is far greater than the threat of death by
> > lack of changes.
> >
> > If people agree the current spec is not sufficient, or wrong, it seems to
> > me the first step is to form a language specification committee where the
> > language can be carefully controlled- and this has to be from a purist
> > view of the language with no concern for implementation and no "baggage"
> > other than the existing language spec has to be respected- all the changes
> > have to be aligned and harmonious with the original purpose and intentions
> > and direction of Modula-3, otherwise what you said later about a new
> > language comes into play. Optional features have to be clearly optional-
> > extensions to the standard that don't make sense in the core have to be
> > clearly deliniated and the spec has to be amended cleanly to separate core
> > language, optional extensions, etc. The Ada specification is a good
> > document to look at for examples of how to do this.
> >
> >> Even adding new platforms should not require bumping the version number
> >> if it is the existing infrastructure that is being ported.
> >
> > Agreed.
> >
> >> There are loads of "greatest next thing" languages out there that you
> >> have to re-learn every few releases.  Modula-3 is thankfully not one of
> >> them.
> >
> > Agreed!
> >
> >> Want new stuff in the language?  Then you want Modula-3+ or Modula-4.
> >
> > Agreed again!
> >
> > People are so used to constant turmoil because of Linux. I come from a much
> > different background and I value stability and evolution, not revolution.
> > New is not necessarily good just like old is not necessarily bad. Good
> > things pass the test of time and don't need constant changes. If we are
> > talking about changing the underlying implementation without changing the
> > language then of course this is fine and should not be held back. My
> > concern is about letting the implementation drive the specification- I feel
> > that is wrong, dangerous, and should be resisted.
> >
> > Many languages today are out of control. To grow a language properly is an
> > extremely big challenge that has to be taken with a great deal of respect
> > and concern.
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120214/8a7f85a2/attachment-0002.html>

From hendrik at topoi.pooq.com  Tue Feb 14 03:59:21 2012
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 13 Feb 2012 21:59:21 -0500
Subject: [M3devel] Assertion failed to complain
In-Reply-To: <289840BF-8FA7-4CD8-9908-9A65B4717F3F@gmail.com>
References: <20120209165624.GA13717@topoi.pooq.com>
	<289840BF-8FA7-4CD8-9908-9A65B4717F3F@gmail.com>
Message-ID: <20120214025921.GB11163@topoi.pooq.com>

On Thu, Feb 09, 2012 at 09:08:37PM -0500, Antony Hosking wrote:
> It?s supposed to warn for unrecognized pragma.

And I might have missed the warning.

Anyway, once I got the case right for ASSERT, I was able to finish 
debugging the program and get it running.  It's a rudimentary program 
that reads several similar text files and produces a variorum edition
-- one that says which lines all share, and which lines are now shared.
It's no limited to two files, like diff, and I can get it to produce 
useful output, unlike the mdiff I got from the FSF website and from a 
debian package.

It still needs cleaning up to be generally useful.  It's rather tuned 
to the particular files I'm dealing with.

-- hendrik


From vintagecoder at aol.com  Tue Feb 14 12:10:16 2012
From: vintagecoder at aol.com (vintagecoder at aol.com)
Date: Tue, 14 Feb 2012 11:10:16 +0000
Subject: [M3devel] Think we need a new release.
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6034A5AF59F@atlex02-srv>
Message-ID: <201202141110.q1EBAK0i003441@imr-da02.mx.aol.com>

Thank you Randy, Henning, Mika for the notes on educational materials.

To Jay, don't forget Solaris builds work better with a non-gcc compiler. I
would hope cm3 would never require gcc or use gcc-specific extensions or it
will cause problems (with GPL3 in the newer versions of gcc) and also on
platforms where gcc isn't the best choice for various reasons.


From dragisha at m3w.org  Tue Feb 14 12:20:52 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 14 Feb 2012 12:20:52 +0100
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <COL101-W552255EAA304C6746012F7E67C0@phx.gbl>
References: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>,
	<4F3948D8.6000004@lcwb.coop>
	<COL101-W552255EAA304C6746012F7E67C0@phx.gbl>
Message-ID: <4DE3D685-C8B6-42E0-B4FA-0BA68594292E@m3w.org>

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).

With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).

Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?

On Feb 14, 2012, at 2:21 AM, Jay K wrote:

> A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120214/45feabb7/attachment-0002.html>

From dabenavidesd at yahoo.es  Tue Feb 14 20:44:59 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 14 Feb 2012 19:44:59 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <4DE3D685-C8B6-42E0-B4FA-0BA68594292E@m3w.org>
Message-ID: <1329248699.74657.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
According to this it might be not p 20
ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf

In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829

Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.

Thanks in advance and please make any comments you may have

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 06:20

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
On Feb 14, 2012, at 2:21 AM, Jay K wrote:
A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120214/cbc375f3/attachment-0002.html>

From jay.krell at cornell.edu  Wed Feb 15 01:23:58 2012
From: jay.krell at cornell.edu (Jay)
Date: Tue, 14 Feb 2012 16:23:58 -0800
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329248699.74657.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <1329248699.74657.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <5CF3B8E7-21C6-4CA7-89C5-B0542BFF2492@gmail.com>

You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...

 - Jay (phone)

On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> According to this it might be not p 20
> ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf
> 
> In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
> http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829
> 
> Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.
> 
> Thanks in advance and please make any comments you may have
> 
> --- El mar, 14/2/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
> 
> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: Re: [M3devel] Think we need a new release. C target
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 14 de febrero, 2012 06:20
> 
> I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
> 
> With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
> 
> Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
> 
> On Feb 14, 2012, at 2:21 AM, Jay K wrote:
> 
>> A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120214/638d1942/attachment-0002.html>

From dabenavidesd at yahoo.es  Wed Feb 15 20:10:56 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 15 Feb 2012 19:10:56 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <5CF3B8E7-21C6-4CA7-89C5-B0542BFF2492@gmail.com>
Message-ID: <1329333056.64488.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
doing by that method do I have compatibility with something else, meaning C? CM JVM? Yes, it achieved it through high compatibility using C language so you could migrate your Java code via CM JVM (without JNI, a kind of nightmare) to Modula-3 and C, now if we generate C, what would be gaining in terms of compatibility, gaining compatibility with those C Compilers, who cares that, just people writing C Code, if they don't or don't want to code in Modula-3, will be attracted by that offer? In CM JVM case it might be interested to migrate to C, but they need a good RT support, they don't need compilers to C. They have many ones already.
Now, if is you the one who want to migrate to C platforms well, Modula-3 can directly interface with C.
I wanted to make clear that my route will be Obliq, since the new real intermediate language becoming mainstream is JavaScript, and certainly the dear good M3 friend new that if it not were by one hair Obliq would be become the standard of the web. Now, why would we want to make a non-standard thing a product of our catalog, well, I pass that one into you, what is the main difference between C and Obliq if I tell you that FailSafe-C is project built on a Obliq JVM product?
Please have a look at DDJ about the "The JVM as a Language Farm Club" :
http://app.reg.techweb.com/e/es.aspx?s=2150&e=27044&elq=66547688035b4bc99ab7612af687575

Thanks in advance

--- El mar, 14/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay K" <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 19:23

You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...

?- Jay (phone)
On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
According to this it might be not p 20
ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf

In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829

Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.

Thanks in advance and please make any comments you may have

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we
 need a new release. C target
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 06:20

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
On Feb 14, 2012, at 2:21 AM, Jay K wrote:
A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120215/93ba8de9/attachment-0002.html>

From jay.krell at cornell.edu  Wed Feb 15 20:43:47 2012
From: jay.krell at cornell.edu (Jay)
Date: Wed, 15 Feb 2012 11:43:47 -0800
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329333056.64488.YahooMailClassic@web29701.mail.ird.yahoo.com>
References: <1329333056.64488.YahooMailClassic@web29701.mail.ird.yahoo.com>
Message-ID: <FDD14D29-1813-47B5-ADB1-2BB1BF25BD57@gmail.com>

No. None of this is the point, if it even makes sense.

The point is to use C as portable target.

If you want to run Obliq in a browser, compile it to JavaScript, possibly via something else, e.g. Java.

JavaScript isn't such a bad language though. The main difference among most languages is amount of static checking. People translate Java to JavaScript partly to get that static checking.

A C target would open up many old and new targets. And help debugging a lot, esp. on systems w/o m3gdb -- there are several.

A Java target and C# target would also be interesting.

 - Jay (phone)

On Feb 15, 2012, at 11:10 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
> doing by that method do I have compatibility with something else, meaning C? CM JVM? Yes, it achieved it through high compatibility using C language so you could migrate your Java code via CM JVM (without JNI, a kind of nightmare) to Modula-3 and C, now if we generate C, what would be gaining in terms of compatibility, gaining compatibility with those C Compilers, who cares that, just people writing C Code, if they don't or don't want to code in Modula-3, will be attracted by that offer? In CM JVM case it might be interested to migrate to C, but they need a good RT support, they don't need compilers to C. They have many ones already.
> Now, if is you the one who want to migrate to C platforms well, Modula-3 can directly interface with C.
> I wanted to make clear that my route will be Obliq, since the new real intermediate language becoming mainstream is JavaScript, and certainly the dear good M3 friend new that if it not were by one hair Obliq would be become the standard of the web. Now, why would we want to make a non-standard thing a product of our catalog, well, I pass that one into you, what is the main difference between C and Obliq if I tell you that FailSafe-C is project built on a Obliq JVM product?
> Please have a look at DDJ about the "The JVM as a Language Farm Club" :
> http://app.reg.techweb.com/e/es.aspx?s=2150&e=27044&elq=66547688035b4bc99ab7612af687575
> 
> Thanks in advance
> 
> --- El mar, 14/2/12, Jay <jay.krell at cornell.edu> escribi?:
> 
> De: Jay <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] Think we need a new release. C target
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "Jay K" <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 14 de febrero, 2012 19:23
> 
> You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...
> 
>  - Jay (phone)
> 
> On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:
> 
>> Hi all:
>> According to this it might be not p 20
>> ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf
>> 
>> In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
>> http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829
>> 
>> Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.
>> 
>> Thanks in advance and please make any comments you may have
>> 
>> --- El mar, 14/2/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:
>> 
>> De: Dragi?a Duri? <dragisha at m3w.org>
>> Asunto: Re: [M3devel] Think we need a new release. C target
>> Para: "Jay K" <jay.krell at cornell.edu>
>> CC: "m3devel" <m3devel at elegosoft.com>
>> Fecha: martes, 14 de febrero, 2012 06:20
>> 
>> I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
>> 
>> With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
>> 
>> Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
>> 
>> On Feb 14, 2012, at 2:21 AM, Jay K wrote:
>> 
>>> A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120215/73ab29f6/attachment-0002.html>

From dabenavidesd at yahoo.es  Wed Feb 15 20:57:36 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 15 Feb 2012 19:57:36 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <FDD14D29-1813-47B5-ADB1-2BB1BF25BD57@gmail.com>
Message-ID: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com>

Hi all:
The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.
If you want to code the RT for C, I don't know that well but Olivetti did that just as you say, but what we want is to be a member of The Language farm Club (aren't we).
If you want to make compilers to C or assembly, that's good but the it has been done in CLEF via M3CG->CLEF, CLEF compiler is written in java, nice!
I mean repeating this over and over doesn't make sense for me, what's the point here? The only thing left is Obliq to code for.
Thanks in advance

--- El mi?, 15/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay" <jay.krell at cornell.edu>, "Jay K" <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 15 de febrero, 2012 14:43

No. None of this is the point, if it even makes sense.
The point is to use C as portable target.
If you want to run Obliq in a browser, compile it to JavaScript, possibly via something else, e.g. Java.
JavaScript isn't such a bad language though. The main difference among most languages is amount of static checking. People translate Java to JavaScript partly to get that static checking.
A C target would open up many old and new targets. And help debugging a lot, esp. on systems w/o m3gdb -- there are several.
A Java target and C# target would also be interesting.
?- Jay (phone)
On Feb 15, 2012, at 11:10 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
doing by that method do I have compatibility with something else, meaning C? CM JVM? Yes, it achieved it through high compatibility using C language so you could migrate your Java code via CM JVM (without JNI, a kind of nightmare) to Modula-3 and C, now if we generate C, what would be gaining in terms of compatibility, gaining compatibility with those C Compilers, who cares that, just people writing C Code, if they don't or don't want to code in Modula-3, will be attracted by that offer? In CM JVM case it might be interested to migrate to C, but they need a good RT support, they don't need compilers to C. They have many ones already.
Now, if is you the one who want to migrate to C platforms well, Modula-3 can directly interface with C.
I wanted to make clear that my route will be Obliq, since the new real intermediate language becoming
 mainstream is JavaScript, and certainly the dear good M3 friend new that if it not were by one hair Obliq would be become the standard of the web. Now, why would we want to make a non-standard thing a product of our catalog, well, I pass that one into you, what is the main difference between C and Obliq if I tell you that FailSafe-C is project built on a Obliq JVM product?
Please have a look at DDJ about the "The JVM as a Language Farm Club" :
http://app.reg.techweb.com/e/es.aspx?s=2150&e=27044&elq=66547688035b4bc99ab7612af687575

Thanks in advance

--- El mar, 14/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay K"
 <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 19:23

You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...

?- Jay (phone)
On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
According to this it might be not p 20
ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf

In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829

Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.

Thanks in advance and please make any comments you may have

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we
 need a new release. C target
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 06:20

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
On Feb 14, 2012, at 2:21 AM, Jay K wrote:
A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120215/7a30d4d1/attachment-0002.html>

From dabenavidesd at yahoo.es  Wed Feb 15 23:10:47 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 15 Feb 2012 22:10:47 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <FDD14D29-1813-47B5-ADB1-2BB1BF25BD57@gmail.com>
Message-ID: <1329343847.90050.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
think about not only back-ports, the only work usable of a C backend would be optimization for it, though it's hard we could make a case for that, see:
http://www.cs.tufts.edu/~nr/cs257/archive/craig-chambers/millstein-pldi03-draft.ps

I know of one work of C#-like compiler with Modula-3 constructs in lcc:
http://research.microsoft.com/pubs/70004/tr-2003-32.pdf

OK, maybe that would optimize hard Modula-3 programs I like that approach, since it would make a case for old (slower platforms) and of course of Big programs in newer machines.
In the Olivetti Modula-3, the speed of the backend was the main issue of not releasing it.
Thanks in advance


--- El mi?, 15/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay" <jay.krell at cornell.edu>, "Jay K" <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 15 de febrero, 2012 14:43

No. None of this is the point, if it even makes sense.
The point is to use C as portable target.
If you want to run Obliq in a browser, compile it to JavaScript, possibly via something else, e.g. Java.
JavaScript isn't such a bad language though. The main difference among most languages is amount of static checking. People translate Java to JavaScript partly to get that static checking.
A C target would open up many old and new targets. And help debugging a lot, esp. on systems w/o m3gdb -- there are several.
A Java target and C# target would also be interesting.
?- Jay (phone)
On Feb 15, 2012, at 11:10 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
doing by that method do I have compatibility with something else, meaning C? CM JVM? Yes, it achieved it through high compatibility using C language so you could migrate your Java code via CM JVM (without JNI, a kind of nightmare) to Modula-3 and C, now if we generate C, what would be gaining in terms of compatibility, gaining compatibility with those C Compilers, who cares that, just people writing C Code, if they don't or don't want to code in Modula-3, will be attracted by that offer? In CM JVM case it might be interested to migrate to C, but they need a good RT support, they don't need compilers to C. They have many ones already.
Now, if is you the one who want to migrate to C platforms well, Modula-3 can directly interface with C.
I wanted to make clear that my route will be Obliq, since the new real intermediate language becoming
 mainstream is JavaScript, and certainly the dear good M3 friend new that if it not were by one hair Obliq would be become the standard of the web. Now, why would we want to make a non-standard thing a product of our catalog, well, I pass that one into you, what is the main difference between C and Obliq if I tell you that FailSafe-C is project built on a Obliq JVM product?
Please have a look at DDJ about the "The JVM as a Language Farm Club" :
http://app.reg.techweb.com/e/es.aspx?s=2150&e=27044&elq=66547688035b4bc99ab7612af687575

Thanks in advance

--- El mar, 14/2/12, Jay <jay.krell at cornell.edu> escribi?:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay K"
 <jay.krell at cornell.edu>, "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 19:23

You don't need a C standard, you just need to work with a few C compilers. Really not difficult. Also #line directives would be key part of debugging. Also, debugger expression evaluation would use C syntax, and, worse, object model would show through. It might help to produce C++ instead. Anyway, I'm sure it is a good idea. Just have to find lots of time...

?- Jay (phone)
On Feb 14, 2012, at 11:44 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

Hi all:
According to this it might be not p 20
ftp://ftp.deas.harvard.edu/techreports/tr-01-05.pdf

In any case will be enough to output C code inside the RT system to provide better maintainability? I believe it isn't but just to try to nicely be compliant with "a standard" that nobody has ever claim as such:
http://www.artikcommunity.biz/showthread.php?t=8224645&page=8&p=34494829#post34494829

Sorry, if I'm being unpolitical, but anyway, you have supported my true passion, good languages.

Thanks in advance and please make any comments you may have

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we
 need a new release. C target
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 14 de febrero, 2012 06:20

I did not agree with this before? But having met mindset "but we unserrrstand C"+"who will maintain than"+"we can't control that module code"? I agree now :).
With C target we don't have to worry about gcc internal changes and we can shield our customer of horrible non-C nature of product we are selling :).
Question is: Can we pass enough information to object/executable to allow us source level debugging of Modula-3?
On Feb 14, 2012, at 2:21 AM, Jay K wrote:
A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120215/cad18a88/attachment-0002.html>

From dragisha at m3w.org  Fri Feb 17 12:29:58 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 17 Feb 2012 12:29:58 +0100
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com>
References: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com>
Message-ID: <B4107FAB-6385-480C-889F-BB904CDF4754@m3w.org>

To port to JVM or Javascript, you have to throw through the window a lot of what Modula-3 is. You will get, in best case, part of Modula-3.

On the other side, targeting to C (or C++) and losing object model from sight (while debugging), ie losing or distorting, also looks like an horrible side effect to me.

It looks like the best direction to concentrate effort is current GCC (a lot of platforms) and LLVM ((almost) new kid on the block with many good promises). The best thing about LLVM target is - IM is standardized and fully documented. Since we all know what pain is tagging along behind GCC IM (thanks to RMS losing licensing battle to SRC), LLVM looks like a promise of future freedom for Modula-3. Maye some day we will not be traumatized by every major (and most minor) GCC releases.

BTW, freepascal has it's own backend infrastructure. Maybe worth a try.

dd


On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120217/8d3ed464/attachment-0002.html>

From dabenavidesd at yahoo.es  Fri Feb 17 13:26:17 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 17 Feb 2012 12:26:17 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <B4107FAB-6385-480C-889F-BB904CDF4754@m3w.org>
Message-ID: <1329481577.26677.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
I don't think that's the case, Java has a JNI and it can work, but CM JVM is just a lot safer and easier to use, direct access to C code of the RT and you know what is better than that out there, in case of an attack? Modula-3 + Java seems the combination to win for me, ESC for both, I mean and what else do you need?

The point of what is Modula-3 a Systems Programming Language doesn't change that it is easier to deal with UNSAFE code, still we could add a keyword for say PROVED to allow the back-end check only for correct optimizations on it or to check UNSAFE code allowed to do so in either Java or Modula-3 or C. I don't care too much about PROVED or UNSAFE modules but more normal code and that's where Modula-3 could be helped by JVM dynamic verification (that said, it is not the best thing to do because this requires a lot of smart checking, I can give you an example of a program in Java that still manages to corrupt any class file in the cd, fooling the JVM) without JVM doing that much. That said compiler verification is much harder than normal checking, still there is research to allow one to do so.
Thanks in advance

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay" <jay.krell at cornell.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 06:29

To port to JVM or Javascript, you have to throw through the window a lot of what Modula-3 is. You will get, in best case, part of Modula-3.
On the other side, targeting to C (or C++) and losing object model from sight (while debugging), ie losing or distorting, also looks like an horrible side effect to me.
It looks like the best direction to concentrate effort is current GCC (a lot of platforms) and LLVM ((almost) new kid on the block with many good promises). The best thing about LLVM target is - IM is standardized and fully documented. Since we all know what pain is tagging along behind GCC IM (thanks to RMS losing licensing battle to SRC), LLVM looks like a promise of future freedom for Modula-3. Maye some day we will not be traumatized by every major (and most minor) GCC releases.
BTW, freepascal has it's own backend infrastructure. Maybe worth a try.
dd

On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides D. wrote:
Hi all:
The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120217/2a2e48a3/attachment-0002.html>

From rodney_bates at lcwb.coop  Fri Feb 17 21:46:53 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 17 Feb 2012 14:46:53 -0600
Subject: [M3devel] An awkward interaction of language properties
Message-ID: <4F3EBCBD.2030802@lcwb.coop>

So, I have the following mutually recursive types:
----------------------------------------------------------------------------
DataStruct.i3:
INTERFACE DataStruct
; TYPE T = RECORD
              Relatives : ListRef
            (* Other fields. *)
            END
; TYPE ListRef = REF List
; TYPE List = ARRAY OF T
; END DataStruct
.
----------------------------------------------------------------------------

This works fine in Modula-3, if all three types are declared in the same scope.

Now suppose instead of builtin type constructor ARRAY OF, I need my set of
relatives to be an instantiation of a complex container data structure,
with a generic parameter for the type of its elements:

----------------------------------------------------------------------------
Container.ig:
GENERIC INTERFACE Container ( Elem )
(* Where Elem exports Elem.T, a type other than an open array type. *)
; TYPE T <: ROOT (* A container of Elem.T. *)
; PROCEDURE Get ( C : T ; Selector : INTEGER ; VAR Element : Elem . T )
; END Container
.
----------------------------------------------------------------------------
INTERFACE DTContainer = Container(DataStruct2) END DTContainer .
----------------------------------------------------------------------------
DataStruct2.i3:
INTERFACE DataStruct2
; IMPORT DTContainer
; TYPE Node = RECORD
                 Relatives : DTContainer . T
               (* Other fields. *)
               END
; END DataStruct2
.
----------------------------------------------------------------------------

This has cyclic imports and won't compile.  (A generic actual interface is
implicitly an import, which is made explicit by the rewrite rule for an
instantiation, 2.5.5)

The rule that recursive types have to be in the same scope and the fact that
an instantiation is a separate interface are irreconcilable.

The only way I can think of is to make the Relatives field be a REFANY,
and not import DTContainer into DataStruct2.  This loses static safety,
but at least it will be replaced by dynamic safety, at the cost of
runtime narrow checks every time I use Relatives.

Of course, I can cut down some on the frequency of RT type checks by grouping
nearby accesses to a Relatives field with a TYPECASE or assignment to a
variable (declared inside a module) of type DTContainer.T.

Anybody have any other thoughts on how to handle this?





From lemming at henning-thielemann.de  Fri Feb 17 21:57:13 2012
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 17 Feb 2012 21:57:13 +0100 (CET)
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <4F3EBCBD.2030802@lcwb.coop>
References: <4F3EBCBD.2030802@lcwb.coop>
Message-ID: <alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>


On Fri, 17 Feb 2012, Rodney M. Bates wrote:

> The only way I can think of is to make the Relatives field be a REFANY,
> and not import DTContainer into DataStruct2.  This loses static safety,
> but at least it will be replaced by dynamic safety, at the cost of
> runtime narrow checks every time I use Relatives.

Some REVEAL tricks instead of REFANY?


From rcolebur at SCIRES.COM  Fri Feb 17 23:51:06 2012
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 17 Feb 2012 17:51:06 -0500
Subject: [M3devel] compile errors in m3front's Formal.m3
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>

I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.

new source -> compiling Formal.m3
"..\src\values\Formal.m3", line 353: parameter not specified (traced)
"..\src\values\Formal.m3", line 432: unknown parameter (rhs)
"..\src\values\Formal.m3", line 432: incompatible types (traced)
"..\src\values\Formal.m3", line 437: parameter not specified (traced)
"..\src\values\Formal.m3", line 492: unknown parameter (rhs)
"..\src\values\Formal.m3", line 492: incompatible types (traced)
"..\src\values\Formal.m3", line 498: parameter not specified (traced)
"..\src\values\Formal.m3", line 512: unknown parameter (rhs)
"..\src\values\Formal.m3", line 512: incompatible types (traced)
"..\src\values\Formal.m3", line 515: parameter not specified (traced)
"..\src\values\Formal.m3", line 530: unknown parameter (rhs)
"..\src\values\Formal.m3", line 530: incompatible types (traced)
"..\src\values\Formal.m3", line 536: parameter not specified (traced)
"..\src\values\Formal.m3", line 552: unknown parameter (rhs)
"..\src\values\Formal.m3", line 552: incompatible types (traced)
"..\src\values\Formal.m3", line 555: parameter not specified (traced)
"..\src\values\Formal.m3", line 608: unknown parameter (rhs)
"..\src\values\Formal.m3", line 608: incompatible types (traced)
"..\src\values\Formal.m3", line 611: parameter not specified (traced)
"..\src\values\Formal.m3", line 627: unknown parameter (rhs)
"..\src\values\Formal.m3", line 627: incompatible types (traced)
"..\src\values\Formal.m3", line 630: parameter not specified (traced)
"..\src\values\Formal.m3", line 649: unknown parameter (rhs)
"..\src\values\Formal.m3", line 649: incompatible types (traced)
"..\src\values\Formal.m3", line 656: parameter not specified (traced)
25 errors encountered

Apparently, someone has checked in a change to Formal.m3 that
has compile errors.

Can whoever made the change please take a look and correct the problem.

Thanks,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120217/9e38c505/attachment-0002.html>

From mika at async.caltech.edu  Sat Feb 18 06:37:13 2012
From: mika at async.caltech.edu (Mika Nystrom)
Date: Fri, 17 Feb 2012 21:37:13 -0800
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>
References: <4F3EBCBD.2030802@lcwb.coop>
	<alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>
Message-ID: <20120218053713.890011A205B@async.async.caltech.edu>


Yes I should think if you declare the Container type in one interface,
to be <: ROOT you can then refer to that from the other interfaces.
Then you REVEAL the actual details in another interface that's not
imported by the others but only where it is needed.  Both the interfaces
you have can be generic.

    Mika


Henning Thielemann writes:
>
>On Fri, 17 Feb 2012, Rodney M. Bates wrote:
>
>> The only way I can think of is to make the Relatives field be a REFANY,
>> and not import DTContainer into DataStruct2.  This loses static safety,
>> but at least it will be replaced by dynamic safety, at the cost of
>> runtime narrow checks every time I use Relatives.
>
>Some REVEAL tricks instead of REFANY?


From dabenavidesd at yahoo.es  Sat Feb 18 15:24:43 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 18 Feb 2012 14:24:43 +0000 (GMT)
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>
Message-ID: <1329575083.11740.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
I think you can't "rebuild" but bootstrap with a step 0 bootstrap compiler and then proceed.
Thus you will get new compiler to build itself but not old building new. Hope it helps.

Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 17:51


 
 




I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.
?
new source -> compiling Formal.m3

"..\src\values\Formal.m3", line 353: parameter not specified (traced)

"..\src\values\Formal.m3", line 432: unknown parameter (rhs)

"..\src\values\Formal.m3", line 432: incompatible types (traced)

"..\src\values\Formal.m3", line 437: parameter not specified (traced)

"..\src\values\Formal.m3", line 492: unknown parameter (rhs)

"..\src\values\Formal.m3", line 492: incompatible types (traced)

"..\src\values\Formal.m3", line 498: parameter not specified (traced)

"..\src\values\Formal.m3", line 512: unknown parameter (rhs)

"..\src\values\Formal.m3", line 512: incompatible types (traced)

"..\src\values\Formal.m3", line 515: parameter not specified (traced)

"..\src\values\Formal.m3", line 530: unknown parameter (rhs)

"..\src\values\Formal.m3", line 530: incompatible types (traced)

"..\src\values\Formal.m3", line 536: parameter not specified (traced)

"..\src\values\Formal.m3", line 552: unknown parameter (rhs)

"..\src\values\Formal.m3", line 552: incompatible types (traced)

"..\src\values\Formal.m3", line 555: parameter not specified (traced)

"..\src\values\Formal.m3", line 608: unknown parameter (rhs)

"..\src\values\Formal.m3", line 608: incompatible types (traced)

"..\src\values\Formal.m3", line 611: parameter not specified (traced)

"..\src\values\Formal.m3", line 627: unknown parameter (rhs)

"..\src\values\Formal.m3", line 627: incompatible types (traced)

"..\src\values\Formal.m3", line 630: parameter not specified (traced)

"..\src\values\Formal.m3", line 649: unknown parameter (rhs)

"..\src\values\Formal.m3", line 649: incompatible types (traced)

"..\src\values\Formal.m3", line 656: parameter not specified (traced)

25 errors encountered
?
Apparently, someone has checked in a change to Formal.m3 that
has compile errors.
?
Can whoever made the change please take a look and correct the problem.
?
Thanks,
Randy Coleburn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120218/283df375/attachment-0002.html>

From rcolebur at SCIRES.COM  Sat Feb 18 21:05:58 2012
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 18 Feb 2012 15:05:58 -0500
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <1329575083.11740.YahooMailClassic@web29704.mail.ird.yahoo.com>
References: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>
	<1329575083.11740.YahooMailClassic@web29704.mail.ird.yahoo.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6034A68D41C@atlex02-srv>

Daniel:

I do not understand your post.

I am following the same procedure and script that I've used for years with success.

It appears that someone has checked in code that doesn't compile, so the Formal.m3 file needs correction to make it compile.

Regards,
Randy Coleburn

From: Daniel Alejandro Benavides D.
Sent: Saturday, February 18, 2012 9:25 AM
To: m3devel; Coleburn, Randy
Subject: Re: [M3devel] compile errors in m3front's Formal.m3

Hi all:
I think you can't "rebuild" but bootstrap with a step 0 bootstrap compiler and then proceed.
Thus you will get new compiler to build itself but not old building new. Hope it helps.

Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>>
Fecha: viernes, 17 de febrero, 2012 17:51
I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.

new source -> compiling Formal.m3
"..\src\values\Formal.m3", line 353: parameter not specified (traced)
"..\src\values\Formal.m3", line 432: unknown parameter (rhs)
"..\src\values\Formal.m3", line 432: incompatible types (traced)
"..\src\values\Formal.m3", line 437: parameter not specified (traced)
"..\src\values\Formal.m3", line 492: unknown parameter (rhs)
"..\src\values\Formal.m3", line 492: incompatible types (traced)
"..\src\values\Formal.m3", line 498: parameter not specified (traced)
"..\src\values\Formal.m3", line 512: unknown parameter (rhs)
"..\src\values\Formal.m3", line 512: incompatible types (traced)
"..\src\values\Formal.m3", line 515: parameter not specified (traced)
"..\src\values\Formal.m3", line 530: unknown parameter (rhs)
"..\src\values\Formal.m3", line 530: incompatible types (traced)
"..\src\values\Formal.m3", line 536: parameter not specified (traced)
"..\src\values\Formal.m3", line 552: unknown parameter (rhs)
"..\src\values\Formal.m3", line 552: incompatible types (traced)
"..\src\values\Formal.m3", line 555: parameter not specified (traced)
"..\src\values\Formal.m3", line 608: unknown parameter (rhs)
"..\src\values\Formal.m3", line 608: incompatible types (traced)
"..\src\values\Formal.m3", line 611: parameter not specified (traced)
"..\src\values\Formal.m3", line 627: unknown parameter (rhs)
"..\src\values\Formal.m3", line 627: incompatible types (traced)
"..\src\values\Formal.m3", line 630: parameter not specified (traced)
"..\src\values\Formal.m3", line 649: unknown parameter (rhs)
"..\src\values\Formal.m3", line 649: incompatible types (traced)
"..\src\values\Formal.m3", line 656: parameter not specified (traced)
25 errors encountered

Apparently, someone has checked in a change to Formal.m3 that
has compile errors.

Can whoever made the change please take a look and correct the problem.

Thanks,
Randy Coleburn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120218/6f8ddd9a/attachment-0002.html>

From dabenavidesd at yahoo.es  Sat Feb 18 21:20:26 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 18 Feb 2012 20:20:26 +0000 (GMT)
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>
Message-ID: <1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:

Randy; I'm trying to verify with head all is OK but currently I can't bootstrap since I hit the same errors.

The other option will be trying to restore the old version (rev 1.13, I
assume I have that already, but I refuse to downgrade unless it is a real error, who knows if the compiler has that error, I
guess there is a way to bootstrap that again, but I can't do anything
else if the compiler can't compile it) in any event:

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/m3front/src/values/Formal.m3?rev=1.13;content-type=text%2Fplain



Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 17:51


 
 




I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.
?
new source -> compiling Formal.m3

"..\src\values\Formal.m3", line 353: parameter not specified (traced)

"..\src\values\Formal.m3", line 432: unknown parameter (rhs)

"..\src\values\Formal.m3", line 432: incompatible types (traced)

"..\src\values\Formal.m3", line 437: parameter not specified (traced)

"..\src\values\Formal.m3", line 492: unknown parameter (rhs)

"..\src\values\Formal.m3", line 492: incompatible types (traced)

"..\src\values\Formal.m3", line 498: parameter not specified (traced)

"..\src\values\Formal.m3", line 512: unknown parameter (rhs)

"..\src\values\Formal.m3", line 512: incompatible types (traced)

"..\src\values\Formal.m3", line 515: parameter not specified (traced)

"..\src\values\Formal.m3", line 530: unknown parameter (rhs)

"..\src\values\Formal.m3", line 530: incompatible types (traced)

"..\src\values\Formal.m3", line 536: parameter not specified (traced)

"..\src\values\Formal.m3", line 552: unknown parameter (rhs)

"..\src\values\Formal.m3", line 552: incompatible types (traced)

"..\src\values\Formal.m3", line 555: parameter not specified (traced)

"..\src\values\Formal.m3", line 608: unknown parameter (rhs)

"..\src\values\Formal.m3", line 608: incompatible types (traced)

"..\src\values\Formal.m3", line 611: parameter not specified (traced)

"..\src\values\Formal.m3", line 627: unknown parameter (rhs)

"..\src\values\Formal.m3", line 627: incompatible types (traced)

"..\src\values\Formal.m3", line 630: parameter not specified (traced)

"..\src\values\Formal.m3", line 649: unknown parameter (rhs)

"..\src\values\Formal.m3", line 649: incompatible types (traced)

"..\src\values\Formal.m3", line 656: parameter not specified (traced)

25 errors encountered
?
Apparently, someone has checked in a change to Formal.m3 that
has compile errors.
?
Can whoever made the change please take a look and correct the problem.
?
Thanks,
Randy Coleburn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120218/0ef49410/attachment-0002.html>

From jay.krell at cornell.edu  Sat Feb 18 23:14:07 2012
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Feb 2012 22:14:07 +0000
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com>
References: <D67F02DDC62F7545A6B84C285F88F3E6034A4BF69B@atlex02-srv>,
	<1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W39A29D6DF3628F2E4A345CE6600@phx.gbl>


Tony broke this in December. https://mail.elegosoft.com/pipermail/m3commit/2011-December/date.html  - Jay
 Date: Sat, 18 Feb 2012 20:20:26 +0000
From: dabenavidesd at yahoo.es
To: m3devel at elegosoft.com; rcolebur at SCIRES.COM
Subject: Re: [M3devel] compile errors in m3front's Formal.m3

Hi all:

Randy; I'm trying to verify with head all is OK but currently I can't bootstrap since I hit the same errors.

The other option will be trying to restore the old version (rev 1.13, I
assume I have that already, but I refuse to downgrade unless it is a real error, who knows if the compiler has that error, I
guess there is a way to bootstrap that again, but I can't do anything
else if the compiler can't compile it) in any event:

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/m3front/src/values/Formal.m3?rev=1.13;content-type=text%2Fplain



Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 17:51


 
 




I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.
 
new source -> compiling Formal.m3

"..\src\values\Formal.m3", line 353: parameter not specified (traced)

"..\src\values\Formal.m3", line 432: unknown parameter (rhs)

"..\src\values\Formal.m3", line 432: incompatible types (traced)

"..\src\values\Formal.m3", line 437: parameter not specified (traced)

"..\src\values\Formal.m3", line 492: unknown parameter (rhs)

"..\src\values\Formal.m3", line 492: incompatible types (traced)

"..\src\values\Formal.m3", line 498: parameter not specified (traced)

"..\src\values\Formal.m3", line 512: unknown parameter (rhs)

"..\src\values\Formal.m3", line 512: incompatible types (traced)

"..\src\values\Formal.m3", line 515: parameter not specified (traced)

"..\src\values\Formal.m3", line 530: unknown parameter (rhs)

"..\src\values\Formal.m3", line 530: incompatible types (traced)

"..\src\values\Formal.m3", line 536: parameter not specified (traced)

"..\src\values\Formal.m3", line 552: unknown parameter (rhs)

"..\src\values\Formal.m3", line 552: incompatible types (traced)

"..\src\values\Formal.m3", line 555: parameter not specified (traced)

"..\src\values\Formal.m3", line 608: unknown parameter (rhs)

"..\src\values\Formal.m3", line 608: incompatible types (traced)

"..\src\values\Formal.m3", line 611: parameter not specified (traced)

"..\src\values\Formal.m3", line 627: unknown parameter (rhs)

"..\src\values\Formal.m3", line 627: incompatible types (traced)

"..\src\values\Formal.m3", line 630: parameter not specified (traced)

"..\src\values\Formal.m3", line 649: unknown parameter (rhs)

"..\src\values\Formal.m3", line 649: incompatible types (traced)

"..\src\values\Formal.m3", line 656: parameter not specified (traced)

25 errors encountered
 
Apparently, someone has checked in a change to Formal.m3 that
has compile errors.
 
Can whoever made the change please take a look and correct the problem.
 
Thanks,
Randy Coleburn


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120218/32326fad/attachment-0002.html>

From dabenavidesd at yahoo.es  Sat Feb 18 23:36:34 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 18 Feb 2012 22:36:34 +0000 (GMT)
Subject: [M3devel] compile errors in m3front's Formal.m3
In-Reply-To: <COL101-W39A29D6DF3628F2E4A345CE6600@phx.gbl>
Message-ID: <1329604594.68674.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
Without trying to spam (sorry if anybody thinks so), the problem might be in the compiler itself rather than in the source code in last revision.
But now, who can give it a try of compiling that with the Modula-3 front-end and verify that the compiler is wrong (and the only thing that comes to mind is the Olivetti? Modula-3 pragmas, somehow we should develop verification condition generator for that in an effort to correct this), perhaps that's easier to proof I assume, rather than trying to check for erasing changes over and over (I mean one would never finish as C-based SE has proved).

Thanks in advance

Thanks in advance

--- El s?b, 18/2/12, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] compile errors in m3front's Formal.m3
Para: dabenavidesd at yahoo.es, "m3devel" <m3devel at elegosoft.com>, rcolebur at scires.com, "Tony" <hosking at cs.purdue.edu>
Fecha: s?bado, 18 de febrero, 2012 17:14




Tony broke this in December.
?
https://mail.elegosoft.com/pipermail/m3commit/2011-December/date.html
?
?- Jay
?
Date: Sat, 18 Feb 2012 20:20:26 +0000
From: dabenavidesd at yahoo.es
To: m3devel at elegosoft.com; rcolebur at SCIRES.COM
Subject: Re: [M3devel] compile errors in m3front's Formal.m3

Hi all:

Randy; I'm trying to verify with head all is OK but currently I can't bootstrap since I hit the same errors.

The other option will be trying to restore the old version (rev 1.13, I
assume I have that already, but I refuse to downgrade unless it is a real error, who knows if the compiler has that error, I
guess there is a way to bootstrap that again, but I can't do anything
else if the compiler can't compile it) in any event:

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/m3front/src/values/Formal.m3?rev=1.13;content-type=text%2Fplain



Thanks in advance

--- El vie, 17/2/12, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] compile errors in m3front's Formal.m3
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 17:51


 
 


#yiv1612936010 .yiv1612936010ExternalClass #yiv1612936010ecxyiv1293036 P
{margin-bottom:0px;}





I was rebuilding from HEAD branch and ran into following errors
trying to rebuild m3front.
?
new source -> compiling Formal.m3

"..\src\values\Formal.m3", line 353: parameter not specified (traced)

"..\src\values\Formal.m3", line 432: unknown parameter (rhs)

"..\src\values\Formal.m3", line 432: incompatible types (traced)

"..\src\values\Formal.m3", line 437: parameter not specified (traced)

"..\src\values\Formal.m3", line 492: unknown parameter (rhs)

"..\src\values\Formal.m3", line 492: incompatible types (traced)

"..\src\values\Formal.m3", line 498: parameter not specified (traced)

"..\src\values\Formal.m3", line 512: unknown parameter (rhs)

"..\src\values\Formal.m3", line 512: incompatible types (traced)

"..\src\values\Formal.m3", line 515: parameter not specified (traced)

"..\src\values\Formal.m3", line 530: unknown parameter (rhs)

"..\src\values\Formal.m3", line 530: incompatible types (traced)

"..\src\values\Formal.m3", line 536: parameter not specified (traced)

"..\src\values\Formal.m3", line 552: unknown parameter (rhs)

"..\src\values\Formal.m3", line 552: incompatible types (traced)

"..\src\values\Formal.m3", line 555: parameter not specified (traced)

"..\src\values\Formal.m3", line 608: unknown parameter (rhs)

"..\src\values\Formal.m3", line 608: incompatible types (traced)

"..\src\values\Formal.m3", line 611: parameter not specified (traced)

"..\src\values\Formal.m3", line 627: unknown parameter (rhs)

"..\src\values\Formal.m3", line 627: incompatible types (traced)

"..\src\values\Formal.m3", line 630: parameter not specified (traced)

"..\src\values\Formal.m3", line 649: unknown parameter (rhs)

"..\src\values\Formal.m3", line 649: incompatible types (traced)

"..\src\values\Formal.m3", line 656: parameter not specified (traced)

25 errors encountered
?
Apparently, someone has checked in a change to Formal.m3 that
has compile errors.
?
Can whoever made the change please take a look and correct the problem.
?
Thanks,
Randy Coleburn


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120218/38beb1ae/attachment-0002.html>

From dabenavidesd at yahoo.es  Sat Feb 18 23:40:29 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 18 Feb 2012 22:40:29 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329481577.26677.YahooMailClassic@web29705.mail.ird.yahoo.com>
Message-ID: <1329604829.41174.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
Interestingly Java had (along ago) UNSAFE extensions into the language:

http://groups.google.com/group/microsoft.public.dotnet.general/browse_thread/thread/bdbaaafa49579931/d9a25710e7e1cdc4%3Fq%3D%2522David%2BChase%2522%23d9a25710e7e1cdc4&ei=iGwTS6eaOpW8Qpmqic0O&sa=t&ct=res&cd=49&source=groups&usg=AFQjCNGAFKXr0Lh9Zhp47J8i8nnVUMePyw

I insist we should get back the Original test suite of SUN, this would help so much the Modula-3 RT (remember this guys worked hard in Modula-3 until the compiler got unsupported or at least until they thought it wouldn't get that much support).

Thanks in advance


--- El vie, 17/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Dragi?a Duri?" <dragisha at m3w.org>
CC: "m3devel" <m3devel at elegosoft.com>, "Jay" <jay.krell at cornell.edu>
Fecha: viernes, 17 de febrero, 2012 07:26

Hi all:
I don't think that's the case, Java has a JNI and it can work, but CM JVM is just a lot safer and easier to use, direct access to C code of the RT and you know what is better than that out there, in case of an attack? Modula-3 + Java seems the combination to win for me, ESC for both, I mean and what else do you need?

The point of what is Modula-3 a Systems Programming Language doesn't change that it is easier to deal with UNSAFE code, still we could add a keyword for say PROVED to allow the back-end check only for correct optimizations on it or to check UNSAFE code allowed to do so in either Java or Modula-3 or C. I don't care too much about PROVED or UNSAFE modules but more normal code and that's where Modula-3 could be helped by JVM dynamic verification (that said, it is not the best thing to do because this requires a lot of smart checking,
 I can give you an example of a program in Java that still manages to corrupt any class file in the cd, fooling the JVM) without JVM doing that much. That said compiler verification is much harder than normal checking, still there is research to allow one to do so.
Thanks in advance

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] Think we need a new release. C target
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Jay" <jay.krell at cornell.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 17 de febrero, 2012 06:29

To port to JVM or Javascript, you have to throw through the window a lot of what Modula-3 is. You will get, in best case, part of
 Modula-3.
On the other side, targeting to C (or C++) and losing object model from sight (while debugging), ie losing or distorting, also looks like an horrible side effect to me.
It looks like the best direction to concentrate effort is current GCC (a lot of platforms) and LLVM ((almost) new kid on the block with many good promises). The best thing about LLVM target is - IM is standardized and fully documented. Since we all know what pain is tagging along behind GCC IM (thanks to RMS losing licensing battle to SRC), LLVM looks like a promise of future freedom for Modula-3. Maye some day we will not be traumatized by every major (and most minor) GCC releases.
BTW, freepascal has it's own backend infrastructure. Maybe worth a try.
dd

On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides D. wrote:
Hi all:
The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120218/4a4c9d5c/attachment-0002.html>

From rodney_bates at lcwb.coop  Sun Feb 19 19:18:02 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 19 Feb 2012 12:18:02 -0600
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <B4107FAB-6385-480C-889F-BB904CDF4754@m3w.org>
References: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com>
	<B4107FAB-6385-480C-889F-BB904CDF4754@m3w.org>
Message-ID: <4F413CDA.8080006@lcwb.coop>



On 02/17/2012 05:29 AM, Dragi?a Duri? wrote:
> To port to JVM or Javascript, you have to throw through the window a lot of what Modula-3 is. You will get, in best case, part of Modula-3.
>

Once, I was peripherally involved in a project that was planning to translate
Ada to JVM code.  After a bit of design work, they quickly abandoned that idea.

Java reflects the popular procrustean philosophy that object-oriented constructs
should be almost the only tool in your box.  As a result, the set of non-heap-allocated
types is highly impoverished, with no programmer-defined type constructors at all.
This is reflected in the JVM.  It doesn't have the constructs to support the richer
type system of Ada or Modula-3.  At the very least, some other bytecode design
would be needed.

> On the other side, targeting to C (or C++) and losing object model from sight (while debugging), ie losing or distorting, also looks like an horrible side effect to me.
>
> It looks like the best direction to concentrate effort is current GCC (a lot of platforms) and LLVM ((almost) new kid on the block with many good promises). The best thing about LLVM target is - IM is standardized and fully documented. Since we all know what pain is tagging along behind GCC IM (thanks to RMS losing licensing battle to SRC), LLVM looks like a promise of future freedom for Modula-3. Maye some day we will not be traumatized by every major (and most minor) GCC releases.
>
> BTW, freepascal has it's own backend infrastructure. Maybe worth a try.
>
> dd
>
>
> On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides D. wrote:
>
>> Hi all:
>> The point is whether we want to migrate our current RT to C or JavaScript, my question is why not (Java/) JVM or Obliq.
>>
>


From dabenavidesd at yahoo.es  Sun Feb 19 19:43:23 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 19 Feb 2012 18:43:23 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <4F413CDA.8080006@lcwb.coop>
Message-ID: <1329677003.22402.YahooMailClassic@web29705.mail.ird.yahoo.com>

Hi all:
Thankfully some theoretical work towards unifying JavaScript Object model to the one of Obliq (did some work on that), and some of the harder work has been done in optimization (Google V8, Safari, etc) and JS VM has been written in JavaScript, then I still don't get why we can't if both theoretically and practically has been done.
I have studied in some form the JVM and I can say very clearly that it's a CISC architecture, I don't see too much of the object model in it bundled (like Uniform treatment of Integer, Scalar types and just the fact that vectorial types are like so, makes conclude that).
Thanks in advance

--- El dom, 19/2/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] Think we need a new release. C target
> Para: m3devel at elegosoft.com
> Fecha: domingo, 19 de febrero, 2012 13:18
> 
> 
> On 02/17/2012 05:29 AM, Dragi?a Duri? wrote:
> > To port to JVM or Javascript, you have to throw through
> the window a lot of what Modula-3 is. You will get, in best
> case, part of Modula-3.
> >
> 
> Once, I was peripherally involved in a project that was
> planning to translate
> Ada to JVM code.  After a bit of design work, they
> quickly abandoned that idea.
> 
> Java reflects the popular procrustean philosophy that
> object-oriented constructs
> should be almost the only tool in your box.  As a
> result, the set of non-heap-allocated
> types is highly impoverished, with no programmer-defined
> type constructors at all.
> This is reflected in the JVM.  It doesn't have the
> constructs to support the richer
> type system of Ada or Modula-3.  At the very least,
> some other bytecode design
> would be needed.
> 
> > On the other side, targeting to C (or C++) and losing
> object model from sight (while debugging), ie losing or
> distorting, also looks like an horrible side effect to me.
> >
> > It looks like the best direction to concentrate effort
> is current GCC (a lot of platforms) and LLVM ((almost) new
> kid on the block with many good promises). The best thing
> about LLVM target is - IM is standardized and fully
> documented. Since we all know what pain is tagging along
> behind GCC IM (thanks to RMS losing licensing battle to
> SRC), LLVM looks like a promise of future freedom for
> Modula-3. Maye some day we will not be traumatized by every
> major (and most minor) GCC releases.
> >
> > BTW, freepascal has it's own backend infrastructure.
> Maybe worth a try.
> >
> > dd
> >
> >
> > On Feb 15, 2012, at 8:57 PM, Daniel Alejandro Benavides
> D. wrote:
> >
> >> Hi all:
> >> The point is whether we want to migrate our current
> RT to C or JavaScript, my question is why not (Java/) JVM or
> Obliq.
> >>
> >
> 


From dabenavidesd at yahoo.es  Mon Feb 20 22:02:08 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 20 Feb 2012 21:02:08 +0000 (GMT)
Subject: [M3devel] Think we need a new release. C target
In-Reply-To: <1329677003.22402.YahooMailClassic@web29705.mail.ird.yahoo.com>
Message-ID: <1329771728.2749.YahooMailClassic@web29704.mail.ird.yahoo.com>

Hi all:
in the other way Jay has proposed could be realized nicely with M3CG to extend CLEF compiler to do that, making type inference explicit could aid the JVM smartly check the IL to avoid gcc IR step and add extended static checking on it, to check for lower level RT errors in case it's necessary to. For instance check integer overflows, etc.
Thanks in advance 

--- El dom, 19/2/12, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] Think we need a new release. C target
> Para: m3devel at elegosoft.com, "Rodney M. Bates" <rodney_bates at lcwb.coop>
> Fecha: domingo, 19 de febrero, 2012 13:43
> Hi all:
> Thankfully some theoretical work towards unifying JavaScript
> Object model to the one of Obliq (did some work on that),
> and some of the harder work has been done in optimization
> (Google V8, Safari, etc) and JS VM has been written in
> JavaScript, then I still don't get why we can't if both
> theoretically and practically has been done.
> I have studied in some form the JVM and I can say very
> clearly that it's a CISC architecture, I don't see too much
> of the object model in it bundled (like Uniform treatment of
> Integer, Scalar types and just the fact that vectorial types
> are like so, makes conclude that).
> Thanks in advance
> 
> --- El dom, 19/2/12, Rodney M. Bates <rodney_bates at lcwb.coop>
> escribi?:
> 
> > De: Rodney M. Bates <rodney_bates at lcwb.coop>
> > Asunto: Re: [M3devel] Think we need a new release. C
> target
> > Para: m3devel at elegosoft.com
> > Fecha: domingo, 19 de febrero, 2012 13:18
> > 
> > 
> > On 02/17/2012 05:29 AM, Dragi?a Duri? wrote:
> > > To port to JVM or Javascript, you have to throw
> through
> > the window a lot of what Modula-3 is. You will get, in
> best
> > case, part of Modula-3.
> > >
> > 
> > Once, I was peripherally involved in a project that
> was
> > planning to translate
> > Ada to JVM code.  After a bit of design work,
> they
> > quickly abandoned that idea.
> > 
> > Java reflects the popular procrustean philosophy that
> > object-oriented constructs
> > should be almost the only tool in your box.  As a
> > result, the set of non-heap-allocated
> > types is highly impoverished, with no
> programmer-defined
> > type constructors at all.
> > This is reflected in the JVM.  It doesn't have
> the
> > constructs to support the richer
> > type system of Ada or Modula-3.  At the very
> least,
> > some other bytecode design
> > would be needed.
> > 
> > > On the other side, targeting to C (or C++) and
> losing
> > object model from sight (while debugging), ie losing
> or
> > distorting, also looks like an horrible side effect to
> me.
> > >
> > > It looks like the best direction to concentrate
> effort
> > is current GCC (a lot of platforms) and LLVM ((almost)
> new
> > kid on the block with many good promises). The best
> thing
> > about LLVM target is - IM is standardized and fully
> > documented. Since we all know what pain is tagging
> along
> > behind GCC IM (thanks to RMS losing licensing battle
> to
> > SRC), LLVM looks like a promise of future freedom for
> > Modula-3. Maye some day we will not be traumatized by
> every
> > major (and most minor) GCC releases.
> > >
> > > BTW, freepascal has it's own backend
> infrastructure.
> > Maybe worth a try.
> > >
> > > dd
> > >
> > >
> > > On Feb 15, 2012, at 8:57 PM, Daniel Alejandro
> Benavides
> > D. wrote:
> > >
> > >> Hi all:
> > >> The point is whether we want to migrate our
> current
> > RT to C or JavaScript, my question is why not (Java/)
> JVM or
> > Obliq.
> > >>
> > >
> >
> 


From rodney_bates at lcwb.coop  Tue Feb 21 21:59:17 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 21 Feb 2012 14:59:17 -0600
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <20120218053713.890011A205B@async.async.caltech.edu>
References: <4F3EBCBD.2030802@lcwb.coop>	<alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>
	<20120218053713.890011A205B@async.async.caltech.edu>
Message-ID: <4F4405A5.50706@lcwb.coop>

At first I thought this was the answer, but. alas, on closer look no.
If I make Relatives opaque, I would need to reveal it as DTContainer.T.
But a revelation must be a type constructor, not just a type name.
I would have to have two different types, Container.T and the type of
Relatives, each opaque, both revealed as the same type.  You can't do
that, because every opaque type declaration creates a unique type and
requires a unique type expression as its revelation. (It has to be
BRANDED too.)

I could break the cycle differently by making DataStruct2.Node
opaque.  Container has no need to know about the field Relatives,
so that could be in a revelation of Node, not imported by Container.
But that would require that Node be a reference type, and
I really want not to have to make values of Node be separately
heap-allocated.

On 02/17/2012 11:37 PM, Mika Nystrom wrote:
> Yes I should think if you declare the Container type in one interface,
> to be<: ROOT you can then refer to that from the other interfaces.
> Then you REVEAL the actual details in another interface that's not
> imported by the others but only where it is needed.  Both the interfaces
> you have can be generic.
>
>      Mika
>
>
> Henning Thielemann writes:
>>
>> On Fri, 17 Feb 2012, Rodney M. Bates wrote:
>>
>>> The only way I can think of is to make the Relatives field be a REFANY,
>>> and not import DTContainer into DataStruct2.  This loses static safety,
>>> but at least it will be replaced by dynamic safety, at the cost of
>>> runtime narrow checks every time I use Relatives.
>>
>> Some REVEAL tricks instead of REFANY?
>


From rodney_bates at lcwb.coop  Wed Feb 22 18:45:50 2012
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 22 Feb 2012 11:45:50 -0600
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <5807BC3C-E467-49C1-AE3F-7695B6B0CB86@gmail.com>
References: <4F3EBCBD.2030802@lcwb.coop>	<alpine.DEB.2.00.1202172156370.10247@anubis.informatik.uni-halle.de>
	<20120218053713.890011A205B@async.async.caltech.edu>
	<4F4405A5.50706@lcwb.coop>
	<5807BC3C-E467-49C1-AE3F-7695B6B0CB86@gmail.com>
Message-ID: <4F4529CE.8050504@lcwb.coop>

Yes.

2.4.7: A complete revelation has the form:

REVEAL T = V

where V is a type expression (not just a name) ...

Whether this could be relaxed without introducing semantic problems would take
careful thought, but I have been aware of how using what is popularly misnamed
"name equivalence" for opaque types is needed instead of Modula-3's usual
structural equivalence for other types.

On 02/21/2012 07:44 PM, Antony Hosking wrote:
> Is that really true?  I would have thought that so long as the type name can be resolved to a concrete type then it would work.
>
> On Feb 21, 2012, at 3:59 PM, Rodney M. Bates wrote:
>
>> But a revelation must be a type constructor, not just a type name.
>
>


From dabenavidesd at yahoo.es  Fri Feb 24 18:27:53 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 24 Feb 2012 17:27:53 +0000 (GMT)
Subject: [M3devel] An awkward interaction of language properties
In-Reply-To: <4F4529CE.8050504@lcwb.coop>
Message-ID: <1330104473.68021.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I would recall your attention on (just read the abstract if you may please modular soundness, that is to say 'safe' data abstraction and information hiding):
http://dl.acm.org/citation.cfm?id=570886.570888

What you can awkward features, I would call 'inherent' parametric polymorphism undecidability which is not at all a bad thing (remember ESC targets undecidable RT errors in all program universe), but in any case we can proof some properties because of that all program space you can still find errors if still are there (symbolic simulation is part of that technique I believe).

Thanks in advance



--- El mi?, 22/2/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] An awkward interaction of language properties
> Para: "Antony Hosking" <antony.hosking at gmail.com>
> CC: m3devel at elegosoft.com
> Fecha: mi?rcoles, 22 de febrero, 2012 12:45
> Yes.
> 
> 2.4.7: A complete revelation has the form:
> 
> REVEAL T = V
> 
> where V is a type expression (not just a name) ...
> 
> Whether this could be relaxed without introducing semantic
> problems would take
> careful thought, but I have been aware of how using what is
> popularly misnamed
> "name equivalence" for opaque types is needed instead of
> Modula-3's usual
> structural equivalence for other types.
> 
> On 02/21/2012 07:44 PM, Antony Hosking wrote:
> > Is that really true?  I would have thought that so
> long as the type name can be resolved to a concrete type
> then it would work.
> >
> > On Feb 21, 2012, at 3:59 PM, Rodney M. Bates wrote:
> >
> >> But a revelation must be a type constructor, not
> just a type name.
> >
> >
> 


From dragisha at m3w.org  Fri Feb 24 21:27:13 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 24 Feb 2012 21:27:13 +0100
Subject: [M3devel] atomic operations in cm3
Message-ID: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>

I cannot find any hint on how to make use of <subject>. What would I like is to communicate with worker threads without LOCK? Possible?

TIA,
dd



From dabenavidesd at yahoo.es  Fri Feb 24 22:36:42 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 24 Feb 2012 21:36:42 +0000 (GMT)
Subject: [M3devel] atomic operations in cm3
In-Reply-To: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>
Message-ID: <1330119402.19915.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
Threads are not common class citizens but its users are, so we can't use normal constructs, perhaps await statements or tell/ask method to that thread may be useful like in ModSim/ModLog (p. 108) or Modula-3 respectively:

http://www.cs.rug.nl/~wim/pub/whh217.ps.gz

https://docs.google.com/open?id=1Y3JFsvlPFp0n17xWyH-HnywN1t6C3SAC-aFGdghakbS_Q8iWPszqtdFwM49H

or what is the same in:
http://www.erg.abdn.ac.uk/~former/harini/refman2.eps
 
Thanks in advance

--- El vieHi/2/12, Dragi?a Duri? <dragisha at m3w.org> escribi?:

> De: Dragi?a Duri? <dragisha at m3w.org>
> Asunto: [M3devel] atomic operations in cm3
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 24 de febrero, 2012 15:27
> I cannot find any hint on how to make
> use of <subject>. What would I like is to communicate
> with worker threads without LOCK? Possible?
> 
> TIA,
> dd
> 
> 


From jay.krell at cornell.edu  Sat Feb 25 03:24:14 2012
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 25 Feb 2012 02:24:14 +0000
Subject: [M3devel] atomic operations in cm3
In-Reply-To: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>
Message-ID: <COL101-W523161ADAA60673252C914E66B0@phx.gbl>


I checked in a test case. Can you look at it?Yes it is possible.  I forget the details, but some operations do require locks on some targets.There is an interface to determine if the target supports lock-free operation.  As long as you are only dealing in INTEGER or REFANY, I think you are ok across the board.  Some 32bit targets don't support 64bit atomtic, like Powerpc.SPARC32 and x86 have supported 64bit atomic operations for a long time.    Linux and Solaris kernels don't run on 32bit SPARC any longer, so 64bit instructions are available in 32bit usermode.HPPA is problematic for all atomics I recall. The instruction set support is very limited.Linux has good support somehow, something dependent on the kernel, but I don't know what gcc/HP-UX/OpenBSD/NetBSD story is.  Look in m3-libs/m3core/src/atomic/m3makefile for a record of what I found.  And ask Bing.   - Jay
 > From: dragisha at m3w.org
> Date: Fri, 24 Feb 2012 21:27:13 +0100
> To: m3devel at elegosoft.com
> Subject: [M3devel] atomic operations in cm3
> 
> I cannot find any hint on how to make use of <subject>. What would I like is to communicate with worker threads without LOCK? Possible?
> 
> TIA,
> dd
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120225/d6bf49af/attachment-0002.html>

From jay.krell at cornell.edu  Mon Feb 27 01:37:56 2012
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 27 Feb 2012 00:37:56 +0000
Subject: [M3devel] atomic operations in cm3
In-Reply-To: <COL101-W523161ADAA60673252C914E66B0@phx.gbl>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
Message-ID: <COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>


  > Look in m3-libs/m3core/src/atomic/m3makefile for a record of what I found.
 http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/atomic/m3makefile?rev=1.14;content-type=text%2Fplain confusing, but goodness:
 Almost anything anyone would want is supported. 
 Except for ARMEL_LINUX: 
All targets support atomic INTEGER and REFANY. 
All LINUX targets support atomic for all types (8/16/32/64). 
All I386 targets support atomic for all types (8/16/32/64).
  This includes NT386 and probably I386_NT/I386_CYGWIN/I386_INTERIX. 
All 64bit targets support atomic for LONGINT (64).
 The missing stuff is generally in unfinished or unused targets.
PPC_DARWIN missing atomic LONGINT is the most glaring omission.
SPARc32_LINUX is next -- it should work as well as SPARc32_SOLARIS/SOLsun/SOLnu.  
Where not supported, there is pattern where you fallback to using a LOCK.I'd venture a guess that PA{32,64}_{HPUX,LINUX} also don't have good atomic support. 


 > I checked in a test case. Can you look at it?  http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile?rev=1.105;content-type=text%2Fplain  => look for "atomic"  => http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/p2/p226/Main.m3?rev=1.10;content-type=text%2Fplain Shows how to use it all. It is disabled. Let's try it.. 
 - JayFrom: jay.krell at cornell.edu
To: dragisha at m3w.org; m3devel at elegosoft.com
Subject: RE: [M3devel] atomic operations in cm3
Date: Sat, 25 Feb 2012 02:24:14 +0000







I checked in a test case. Can you look at it?
Yes it is possible.
 
 
I forget the details, but some operations do require locks on some targets.
There is an interface to determine if the target supports lock-free operation.
 
 
As long as you are only dealing in INTEGER or REFANY, I think you are ok across the board.
 
 
Some 32bit targets don't support 64bit atomtic, like Powerpc.
SPARC32 and x86 have supported 64bit atomic operations for a long time.
    Linux and Solaris kernels don't run on 32bit SPARC any longer, so 64bit instructions are available in 32bit usermode.
HPPA is problematic for all atomics I recall. The instruction set support is very limited.
Linux has good support somehow, something dependent on the kernel, but I don't know what gcc/HP-UX/OpenBSD/NetBSD story is.
 
 
Look in m3-libs/m3core/src/atomic/m3makefile for a record of what I found.
 
 
And ask Bing.
 
 
 - Jay
 
> From: dragisha at m3w.org
> Date: Fri, 24 Feb 2012 21:27:13 +0100
> To: m3devel at elegosoft.com
> Subject: [M3devel] atomic operations in cm3
> 
> I cannot find any hint on how to make use of <subject>. What would I like is to communicate with worker threads without LOCK? Possible?
> 
> TIA,
> dd
> 
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120227/a0cba8a9/attachment-0002.html>

From dragisha at m3w.org  Mon Feb 27 08:15:00 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 27 Feb 2012 08:15:00 +0100
Subject: [M3devel] atomic operations in cm3
In-Reply-To: <COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
	<COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
Message-ID: <2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>

m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.


On Feb 27, 2012, at 1:37 AM, Jay K wrote:

> Shows how to use it all.
>  
> It is disabled. Let's try it..

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120227/64bdef84/attachment-0002.html>

From dragisha at m3w.org  Tue Feb 28 14:15:16 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 28 Feb 2012 14:15:16 +0100
Subject: [M3devel] atomic operations in cm3 (fails on AMD64_DARWIN)
In-Reply-To: <2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
	<COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
	<2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>
Message-ID: <87DB10DC-D7D1-4C7E-BF67-9D5B2D19CC56@m3w.org>

% cm3
--- building in ../AMD64_DARWIN ---

new source -> compiling Proxy.m3
"../src/Proxy.m3", line 13: warning: not used (JobHandler)
1 warning encountered
new source -> compiling AtomicAddress.i3
new source -> compiling AtomicAddress.m3
"../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack:  expected [ Int64    ] got [ Addr  Int64   ]


***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3
***

zsh: abort      cm3

On Feb 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:

> m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.
> 
> 
> On Feb 27, 2012, at 1:37 AM, Jay K wrote:
> 
>> Shows how to use it all.
>>  
>> It is disabled. Let's try it..
> 

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

From dragisha at m3w.org  Tue Feb 28 15:08:17 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 28 Feb 2012 15:08:17 +0100
Subject: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
In-Reply-To: <9C0959B3-53C1-4147-A1E3-CC08EF0F4FAF@gmail.com>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
	<COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
	<2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>
	<87DB10DC-D7D1-4C7E-BF67-9D5B2D19CC56@m3w.org>
	<9C0959B3-53C1-4147-A1E3-CC08EF0F4FAF@gmail.com>
Message-ID: <98191695-F733-46F5-B51C-B4F6FAC710B6@m3w.org>

% cm3
--- building in ../AMD64_LINUX ---

new source -> compiling AtomicAddress.m3
"../AMD64_LINUX/AtomicAddress.m3", line 3:  18 code generation errors
1 error encountered
new exporters -> recompiling AtomicAddress.i3
compilation failed => not building program "test"
Fatal Error: package build failed

% cat m3makefile 
import("libm3")

...

Generic_module("Atomic")
template("atomic")
Atomic("Address")

program ("test")

On Feb 28, 2012, at 2:25 PM, Antony Hosking wrote:

> Yes, this is a known bug.
> 
> On Feb 28, 2012, at 8:15 AM, Dragi?a Duri? wrote:
> 
>> % cm3
>> --- building in ../AMD64_DARWIN ---
>> 
>> new source -> compiling Proxy.m3
>> "../src/Proxy.m3", line 13: warning: not used (JobHandler)
>> 1 warning encountered
>> new source -> compiling AtomicAddress.i3
>> new source -> compiling AtomicAddress.m3
>> "../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack:  expected [ Int64    ] got [ Addr  Int64   ]
>> 
>> 
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3
>> ***
>> 
>> zsh: abort      cm3
>> 
>> On Feb 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:
>> 
>>> m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.
>>> 
>>> 
>>> On Feb 27, 2012, at 1:37 AM, Jay K wrote:
>>> 
>>>> Shows how to use it all.
>>>>  
>>>> It is disabled. Let's try it..
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120228/055f5064/attachment-0002.html>

From dragisha at m3w.org  Tue Feb 28 15:23:32 2012
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 28 Feb 2012 15:23:32 +0100
Subject: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
In-Reply-To: <5272CAF6-2F21-4516-83F6-3ABFFFB2145E@gmail.com>
References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>,
	<COL101-W523161ADAA60673252C914E66B0@phx.gbl>
	<COL101-W34AFBF0CA78CBDD8E80022E6690@phx.gbl>
	<2F363270-52EE-4E66-9BBC-FE4A81FF3E3A@m3w.org>
	<87DB10DC-D7D1-4C7E-BF67-9D5B2D19CC56@m3w.org>
	<9C0959B3-53C1-4147-A1E3-CC08EF0F4FAF@gmail.com>
	<98191695-F733-46F5-B51C-B4F6FAC710B6@m3w.org>
	<5272CAF6-2F21-4516-83F6-3ABFFFB2145E@gmail.com>
Message-ID: <4F234746-BBC5-4F23-A9FC-C39EC2D78284@m3w.org>

LINUXLIBC6 does not have Address.i3, at least my version does not.

But, Atomic("Refany") passess at LINUXLIBC6. But, call to AtomicRefany.IsLockFree() fails - looks like infinite recursion happens inside.

On Feb 28, 2012, at 3:13 PM, Antony Hosking wrote:

> Same error as before.  We need more compile-time type information to be maintained to make sure that we are operating on addresses not integers.
> 
> On Feb 28, 2012, at 9:08 AM, Dragi?a Duri? wrote:
> 
>> % cm3
>> --- building in ../AMD64_LINUX ---
>> 
>> new source -> compiling AtomicAddress.m3
>> "../AMD64_LINUX/AtomicAddress.m3", line 3:  18 code generation errors
>> 1 error encountered
>> new exporters -> recompiling AtomicAddress.i3
>> compilation failed => not building program "test"
>> Fatal Error: package build failed
>> 
>> % cat m3makefile 
>> import("libm3")
>> 
>> ...
>> 
>> Generic_module("Atomic")
>> template("atomic")
>> Atomic("Address")
>> 
>> program ("test")
>> 
>> On Feb 28, 2012, at 2:25 PM, Antony Hosking wrote:
>> 
>>> Yes, this is a known bug.
>>> 
>>> On Feb 28, 2012, at 8:15 AM, Dragi?a Duri? wrote:
>>> 
>>>> % cm3
>>>> --- building in ../AMD64_DARWIN ---
>>>> 
>>>> new source -> compiling Proxy.m3
>>>> "../src/Proxy.m3", line 13: warning: not used (JobHandler)
>>>> 1 warning encountered
>>>> new source -> compiling AtomicAddress.i3
>>>> new source -> compiling AtomicAddress.m3
>>>> "../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack:  expected [ Int64    ] got [ Addr  Int64   ]
>>>> 
>>>> 
>>>> ***
>>>> *** runtime error:
>>>> ***    Segmentation violation - possible attempt to dereference NIL
>>>> ***    pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3
>>>> ***
>>>> 
>>>> zsh: abort      cm3
>>>> 
>>>> On Feb 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:
>>>> 
>>>>> m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.
>>>>> 
>>>>> 
>>>>> On Feb 27, 2012, at 1:37 AM, Jay K wrote:
>>>>> 
>>>>>> Shows how to use it all.
>>>>>>  
>>>>>> It is disabled. Let's try it..
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120228/51d7121b/attachment-0002.html>

From dabenavidesd at yahoo.es  Tue Feb 28 19:09:01 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 28 Feb 2012 18:09:01 +0000 (GMT)
Subject: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
In-Reply-To: <98191695-F733-46F5-B51C-B4F6FAC710B6@m3w.org>
Message-ID: <1330452541.3684.YahooMailClassic@web29706.mail.ird.yahoo.com>

Hi all:
I don't understand it, what is breaking, the compiler front end, the backend or both or what else? Besides platform feature instability, means that you are doing UNSAFE MODULEs? Question, is your machine SMP? I have one 32 and 64 UP LINUXLIBC6 capable, does it matter if is in one or in the other?
Thanks in advance

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
Para: "Antony Hosking" <antony.hosking at gmail.com>
CC: "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: martes, 28 de febrero, 2012 09:08

% cm3--- building in ../AMD64_LINUX ---
new source -> compiling AtomicAddress.m3"../AMD64_LINUX/AtomicAddress.m3", line 3: ?18 code generation errors1 error encounterednew exporters -> recompiling AtomicAddress.i3compilation failed => not building program "test"Fatal Error: package build failed
% cat m3makefile?import("libm3")
...
Generic_module("Atomic")template("atomic")Atomic("Address")
program ("test")
On Feb 28, 2012, at 2:25 PM, Antony Hosking wrote:
Yes, this is a known bug.
On Feb 28, 2012, at 8:15 AM, Dragi?a Duri? wrote:
% cm3--- building in ../AMD64_DARWIN ---
new source -> compiling Proxy.m3"../src/Proxy.m3", line 13: warning: not used (JobHandler)1 warning encounterednew source -> compiling AtomicAddress.i3new source -> compiling AtomicAddress.m3"../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack: ?expected [ Int64 ? ?] got [ Addr ?Int64 ? ]

****** runtime error:*** ? ?Segmentation violation - possible attempt to dereference NIL*** ? ?pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3***
zsh: abort ? ? ?cm3
On Feb 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:
m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.

On Feb 27, 2012, at 1:37 AM, Jay K wrote:
Shows how to use it all.
?
It is disabled. Let's try it..



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

From dabenavidesd at yahoo.es  Tue Feb 28 22:53:33 2012
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 28 Feb 2012 21:53:33 +0000 (GMT)
Subject: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
In-Reply-To: <8D6408D2-7FDF-47B4-96D3-39A921ED419F@gmail.com>
Message-ID: <1330466013.93631.YahooMailClassic@web29701.mail.ird.yahoo.com>

Hi all:
Thanks for the message and now I caught it, I have found a thesis on the <* FIELDS *> specification feature, perhaps would be a nice idea to use it to verify the trees in both Olivetti and CM3 front end, and to convert back and forth (for instance when select ESC-ing a program so just doing it once and for all is faster).

And thinking it more, I guess similarly this could be the way to watch the back end to reconstruct/infer the types same from the gcc assembly (and the CLEF tree) and compare and match if they truly match to prove it's correct.

Thanks in advance

--- El mar, 28/2/12, Antony Hosking <antony.hosking at gmail.com> escribi?:

De: Antony Hosking <antony.hosking at gmail.com>
Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
CC: "Dragi?a Duri?" <dragisha at m3w.org>, "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: martes, 28 de febrero, 2012 15:46

It is the front end outputting badly typed IR.
On Feb 28, 2012, at 1:09 PM, Daniel Alejandro Benavides D. wrote:
Hi all:
I don't understand it, what is breaking, the compiler front end, the backend or both or what else? Besides platform feature instability, means that you are doing UNSAFE MODULEs? Question, is your machine SMP? I have one 32 and 64 UP LINUXLIBC6 capable, does it matter if is in one or in the other?
Thanks in advance

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

De: Dragi?a Duri? <dragisha at m3w.org>
Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX)
Para: "Antony Hosking" <antony.hosking at gmail.com>
CC: "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: martes, 28 de febrero, 2012 09:08

% cm3--- building in ../AMD64_LINUX ---
new source -> compiling AtomicAddress.m3"../AMD64_LINUX/AtomicAddress.m3", line 3: ?18 code generation errors1 error encounterednew exporters -> recompiling AtomicAddress.i3compilation failed => not building program "test"Fatal Error: package build failed
% cat m3makefile?import("libm3")
...
Generic_module("Atomic")template("atomic")Atomic("Address")
program ("test")
On Feb 28, 2012, at 2:25 PM, Antony Hosking wrote:
Yes, this is a known bug.
On Feb 28, 2012, at 8:15 AM, Dragi?a Duri? wrote:
% cm3--- building in ../AMD64_DARWIN ---
new source -> compiling Proxy.m3"../src/Proxy.m3", line 13: warning: not used (JobHandler)1 warning encounterednew source -> compiling AtomicAddress.i3new source -> compiling AtomicAddress.m3"../AMD64_DARWIN/AtomicAddress.m3 => ../src/Atomic.mg", line 52: ********* M3CG_Check ERROR *********** bad stack: ?expected [ Int64 ? ?] got [ Addr ?Int64 ? ]

****** runtime error:*** ? ?Segmentation violation - possible attempt to dereference NIL*** ? ?pc = 0x1002f0838 = Concat + 0x8a in ../src/text/TextCat.m3***
zsh: abort ? ? ?cm3
On Feb
 27, 2012, at 8:15 AM, Dragi?a Duri? wrote:
m3-libs/m3core/src/atomic/Atomic.ig is well commented, also.

On Feb 27, 2012, at 1:37 AM, Jay K wrote:
Shows how to use it all.
?
It is disabled. Let's try
 it..




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120228/1dc64095/attachment-0002.html>