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: References: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> Message-ID: <20120202210445.6c03d7d9@wenus.next.com.pl> Dnia 2012-01-31, o godz. 02:21:56 Jay K 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 escribi?: > De: Dariusz Knoci?ski > 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 > 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. escribi?: > De: Daniel Alejandro Benavides D. > 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" > 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 > escribi?: > > > De: Dariusz Knoci?ski > > 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 > > 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: 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. escribi?: > > > De: Daniel Alejandro Benavides D. > > 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" > > 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 > > escribi?: > > > > > De: Dariusz Knoci?ski > > > 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 > > > 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: 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: 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: References: 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: 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? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] open array parameter passing, to external C procedure > Para: "m3devel" > 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? To: m3devel 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: 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? > To: m3devel > 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 escribi?: > De: Hendrik Boom > 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: 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: References: Message-ID: 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 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: 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: 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 escribi?: De: felipe valdez Asunto: Re: [M3devel] Think we need a new release. Para: "Peter McKinna" 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 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: 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: References: Message-ID: I can provide testing on Windows 2000, XP, and 7 platforms. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: 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 escribi?: > De: Vintage Coder > 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: 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: 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: 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 escribi?: De: Dirk Muysers 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: 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: 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 escribi?: > > > De: Vintage Coder > > 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: 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. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] platform-independent object file linking Para: m3devel at elegosoft.com, "Dirk Muysers" 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 escribi?: De: Dirk Muysers 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: 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. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] platform-independent object file linking Para: m3devel at elegosoft.com, "Dirk Muysers" 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. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] platform-independent object file linking Para: m3devel at elegosoft.com, "Dirk Muysers" 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 escribi?: De: Dirk Muysers 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: 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: 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 escribi?: De: felipe valdez Asunto: Re: [M3devel] Think we need a new release. Para: "Daniel Alejandro Benavides D." 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. 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 escribi?: > De: Vintage Coder > 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: 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: 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: 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 escribi?: > De: m3 at sol42.com > Asunto: Re: [M3devel] Think we need a new release. > Para: "m3devel" > 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. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] Think we need a new release. > Para: "m3devel" , 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 > escribi?: > > > De: m3 at sol42.com > > Asunto: Re: [M3devel] Think we need a new release. > > Para: "m3devel" > > 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 escribi?: > De: Hendrik Boom > 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: 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: 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 escribi?: > De: 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: References: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.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 Date: Mon, 13 Feb 2012 11:03:33 To: Cc: 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, 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: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com> Message-ID: I recommend the video tutorial format, as I always have. On Mon, Feb 13, 2012 at 9:33 AM, 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: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com> Message-ID: >>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 escribi?: > De: Rodney M. Bates > 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: References: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com> Message-ID: 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: References: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com> 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: 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 escribi?: > De: Henning Thielemann > Asunto: Re: [M3devel] Think we need a new release. > Para: "Coleburn, Randy" > CC: "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: > 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: 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: 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: References: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>, <4F3948D8.6000004@lcwb.coop> 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: 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Jay K" CC: "m3devel" 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: 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." 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? escribi?: > > De: Dragi?a Duri? > Asunto: Re: [M3devel] Think we need a new release. C target > Para: "Jay K" > CC: "m3devel" > 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: 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Jay K" CC: "m3devel" 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: 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: 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." 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 escribi?: > > De: Jay > Asunto: Re: [M3devel] Think we need a new release. C target > Para: "Daniel Alejandro Benavides D." > CC: "Jay K" , "Dragi?a Duri?" , "m3devel" > 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." 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? escribi?: >> >> De: Dragi?a Duri? >> Asunto: Re: [M3devel] Think we need a new release. C target >> Para: "Jay K" >> CC: "m3devel" >> 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: 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: 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay" , "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Jay K" CC: "m3devel" 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: 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: 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay" , "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Jay K" CC: "m3devel" 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: 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: 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: 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: 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay" , "m3devel" 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: 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: 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: 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: 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: References: <4F3EBCBD.2030802@lcwb.coop> 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: 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 escribi?: De: Coleburn, Randy Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" 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: 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: <1329575083.11740.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: 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 > escribi?: De: Coleburn, Randy > Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" > 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: 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: 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 escribi?: De: Coleburn, Randy Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" 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: 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: , <1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com> Message-ID: 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 escribi?: De: Coleburn, Randy Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" 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: 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: 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 escribi?: De: Jay K Asunto: RE: [M3devel] compile errors in m3front's Formal.m3 Para: dabenavidesd at yahoo.es, "m3devel" , rcolebur at scires.com, "Tony" 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 escribi?: De: Coleburn, Randy Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" 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: 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. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] Think we need a new release. C target Para: "Dragi?a Duri?" CC: "m3devel" , "Jay" 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay" , "m3devel" 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: 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: References: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com> 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 escribi?: > De: Rodney M. Bates > 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. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] Think we need a new release. C target > Para: m3devel at elegosoft.com, "Rodney M. Bates" > 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 > escribi?: > > > De: Rodney M. Bates > > 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> <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> <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 escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] An awkward interaction of language properties > Para: "Antony Hosking" > 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 . 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? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] atomic operations in cm3 > Para: "m3devel" > Fecha: viernes, 24 de febrero, 2012 15:27 > I cannot find any hint on how to make > use of . 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: 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 . What would I like is to communicate with worker threads without LOCK? Possible? > > TIA, > dd > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>, Message-ID: > 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 . What would I like is to communicate with worker threads without LOCK? Possible? > > TIA, > dd > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>, 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: 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>, <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: 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>, <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: 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>, <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: 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX) Para: "Antony Hosking" CC: "m3devel" , "Jay K" 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: 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 escribi?: De: Antony Hosking Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX) Para: "Daniel Alejandro Benavides D." CC: "Dragi?a Duri?" , "m3devel" , "Jay K" 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX) Para: "Antony Hosking" CC: "m3devel" , "Jay K" 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: 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: References: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> Message-ID: <20120202210445.6c03d7d9@wenus.next.com.pl> Dnia 2012-01-31, o godz. 02:21:56 Jay K 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 escribi?: > De: Dariusz Knoci?ski > 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 > 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. escribi?: > De: Daniel Alejandro Benavides D. > 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" > 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 > escribi?: > > > De: Dariusz Knoci?ski > > 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 > > 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: 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. escribi?: > > > De: Daniel Alejandro Benavides D. > > 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" > > 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 > > escribi?: > > > > > De: Dariusz Knoci?ski > > > 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 > > > 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: 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: 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: References: 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: 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? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] open array parameter passing, to external C procedure > Para: "m3devel" > 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? To: m3devel 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: 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? > To: m3devel > 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 escribi?: > De: Hendrik Boom > 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: 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: References: Message-ID: 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 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: 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: 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 escribi?: De: felipe valdez Asunto: Re: [M3devel] Think we need a new release. Para: "Peter McKinna" 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 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: 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: References: Message-ID: I can provide testing on Windows 2000, XP, and 7 platforms. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: 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 escribi?: > De: Vintage Coder > 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: 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: 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: 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 escribi?: De: Dirk Muysers 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: 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: 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 escribi?: > > > De: Vintage Coder > > 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: 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. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] platform-independent object file linking Para: m3devel at elegosoft.com, "Dirk Muysers" 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 escribi?: De: Dirk Muysers 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: 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. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] platform-independent object file linking Para: m3devel at elegosoft.com, "Dirk Muysers" 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. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] platform-independent object file linking Para: m3devel at elegosoft.com, "Dirk Muysers" 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 escribi?: De: Dirk Muysers 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: 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: 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 escribi?: De: felipe valdez Asunto: Re: [M3devel] Think we need a new release. Para: "Daniel Alejandro Benavides D." 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. 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 escribi?: > De: Vintage Coder > 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: 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: 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: 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 escribi?: > De: m3 at sol42.com > Asunto: Re: [M3devel] Think we need a new release. > Para: "m3devel" > 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. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] Think we need a new release. > Para: "m3devel" , 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 > escribi?: > > > De: m3 at sol42.com > > Asunto: Re: [M3devel] Think we need a new release. > > Para: "m3devel" > > 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 escribi?: > De: Hendrik Boom > 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: 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: 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 escribi?: > De: 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: References: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.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 Date: Mon, 13 Feb 2012 11:03:33 To: Cc: 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, 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: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com> Message-ID: I recommend the video tutorial format, as I always have. On Mon, Feb 13, 2012 at 9:33 AM, 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: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com> Message-ID: >>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 escribi?: > De: Rodney M. Bates > 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: References: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com> Message-ID: 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: References: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com> 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: 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 escribi?: > De: Henning Thielemann > Asunto: Re: [M3devel] Think we need a new release. > Para: "Coleburn, Randy" > CC: "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: > 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: 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: 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: References: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>, <4F3948D8.6000004@lcwb.coop> 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: 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Jay K" CC: "m3devel" 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: 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." 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? escribi?: > > De: Dragi?a Duri? > Asunto: Re: [M3devel] Think we need a new release. C target > Para: "Jay K" > CC: "m3devel" > 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: 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Jay K" CC: "m3devel" 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: 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: 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." 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 escribi?: > > De: Jay > Asunto: Re: [M3devel] Think we need a new release. C target > Para: "Daniel Alejandro Benavides D." > CC: "Jay K" , "Dragi?a Duri?" , "m3devel" > 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." 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? escribi?: >> >> De: Dragi?a Duri? >> Asunto: Re: [M3devel] Think we need a new release. C target >> Para: "Jay K" >> CC: "m3devel" >> 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: 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: 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay" , "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Jay K" CC: "m3devel" 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: 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: 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay" , "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Jay K" CC: "m3devel" 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: 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: 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: 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: 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay" , "m3devel" 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: 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: 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: 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: 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: References: <4F3EBCBD.2030802@lcwb.coop> 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: 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 escribi?: De: Coleburn, Randy Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" 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: 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: <1329575083.11740.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: 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 > escribi?: De: Coleburn, Randy > Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" > 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: 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: 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 escribi?: De: Coleburn, Randy Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" 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: 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: , <1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com> Message-ID: 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 escribi?: De: Coleburn, Randy Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" 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: 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: 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 escribi?: De: Jay K Asunto: RE: [M3devel] compile errors in m3front's Formal.m3 Para: dabenavidesd at yahoo.es, "m3devel" , rcolebur at scires.com, "Tony" 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 escribi?: De: Coleburn, Randy Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" 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: 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. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] Think we need a new release. C target Para: "Dragi?a Duri?" CC: "m3devel" , "Jay" 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay" , "m3devel" 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: 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: References: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com> 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 escribi?: > De: Rodney M. Bates > 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. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] Think we need a new release. C target > Para: m3devel at elegosoft.com, "Rodney M. Bates" > 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 > escribi?: > > > De: Rodney M. Bates > > 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> <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> <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 escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] An awkward interaction of language properties > Para: "Antony Hosking" > 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 . 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? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] atomic operations in cm3 > Para: "m3devel" > Fecha: viernes, 24 de febrero, 2012 15:27 > I cannot find any hint on how to make > use of . 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: 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 . What would I like is to communicate with worker threads without LOCK? Possible? > > TIA, > dd > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>, Message-ID: > 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 . What would I like is to communicate with worker threads without LOCK? Possible? > > TIA, > dd > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>, 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: 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>, <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: 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>, <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: 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>, <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: 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX) Para: "Antony Hosking" CC: "m3devel" , "Jay K" 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: 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 escribi?: De: Antony Hosking Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX) Para: "Daniel Alejandro Benavides D." CC: "Dragi?a Duri?" , "m3devel" , "Jay K" 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX) Para: "Antony Hosking" CC: "m3devel" , "Jay K" 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: 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: References: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> Message-ID: <20120202210445.6c03d7d9@wenus.next.com.pl> Dnia 2012-01-31, o godz. 02:21:56 Jay K 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 escribi?: > De: Dariusz Knoci?ski > 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 > 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. escribi?: > De: Daniel Alejandro Benavides D. > 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" > 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 > escribi?: > > > De: Dariusz Knoci?ski > > 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 > > 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: 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. escribi?: > > > De: Daniel Alejandro Benavides D. > > 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" > > 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 > > escribi?: > > > > > De: Dariusz Knoci?ski > > > 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 > > > 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: 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: 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: References: 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: 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? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] open array parameter passing, to external C procedure > Para: "m3devel" > 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? To: m3devel 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: 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? > To: m3devel > 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 escribi?: > De: Hendrik Boom > 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: 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: References: Message-ID: 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 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: 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: 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 escribi?: De: felipe valdez Asunto: Re: [M3devel] Think we need a new release. Para: "Peter McKinna" 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 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: 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: References: Message-ID: I can provide testing on Windows 2000, XP, and 7 platforms. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: 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 escribi?: > De: Vintage Coder > 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: 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: 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: 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 escribi?: De: Dirk Muysers 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: 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: 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 escribi?: > > > De: Vintage Coder > > 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: 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. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] platform-independent object file linking Para: m3devel at elegosoft.com, "Dirk Muysers" 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 escribi?: De: Dirk Muysers 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: 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. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] platform-independent object file linking Para: m3devel at elegosoft.com, "Dirk Muysers" 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. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] platform-independent object file linking Para: m3devel at elegosoft.com, "Dirk Muysers" 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 escribi?: De: Dirk Muysers 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: 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: 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 escribi?: De: felipe valdez Asunto: Re: [M3devel] Think we need a new release. Para: "Daniel Alejandro Benavides D." 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. 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 escribi?: > De: Vintage Coder > 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: 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: 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: 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 escribi?: > De: m3 at sol42.com > Asunto: Re: [M3devel] Think we need a new release. > Para: "m3devel" > 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. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] Think we need a new release. > Para: "m3devel" , 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 > escribi?: > > > De: m3 at sol42.com > > Asunto: Re: [M3devel] Think we need a new release. > > Para: "m3devel" > > 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 escribi?: > De: Hendrik Boom > 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: 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: 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 escribi?: > De: 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: References: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.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 Date: Mon, 13 Feb 2012 11:03:33 To: Cc: 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, 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: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com> Message-ID: I recommend the video tutorial format, as I always have. On Mon, Feb 13, 2012 at 9:33 AM, 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: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com> Message-ID: >>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 escribi?: > De: Rodney M. Bates > 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: References: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com> Message-ID: 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: References: <201202131433.q1DEXO6q014538@imr-db02.mx.aol.com> 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: 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 escribi?: > De: Henning Thielemann > Asunto: Re: [M3devel] Think we need a new release. > Para: "Coleburn, Randy" > CC: "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: > 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: 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: 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: References: <201202131406.q1DE6YBR021657@imr-da06.mx.aol.com>, <4F3948D8.6000004@lcwb.coop> 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: 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Jay K" CC: "m3devel" 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: 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." 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? escribi?: > > De: Dragi?a Duri? > Asunto: Re: [M3devel] Think we need a new release. C target > Para: "Jay K" > CC: "m3devel" > 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: 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Jay K" CC: "m3devel" 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: 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: 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." 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 escribi?: > > De: Jay > Asunto: Re: [M3devel] Think we need a new release. C target > Para: "Daniel Alejandro Benavides D." > CC: "Jay K" , "Dragi?a Duri?" , "m3devel" > 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." 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? escribi?: >> >> De: Dragi?a Duri? >> Asunto: Re: [M3devel] Think we need a new release. C target >> Para: "Jay K" >> CC: "m3devel" >> 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: 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: 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay" , "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Jay K" CC: "m3devel" 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: 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: 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay" , "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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 escribi?: De: Jay Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay K" , "Dragi?a Duri?" , "m3devel" 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." 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Jay K" CC: "m3devel" 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: 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: 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: 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: 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay" , "m3devel" 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: 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: 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: 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: 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: References: <4F3EBCBD.2030802@lcwb.coop> 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: 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 escribi?: De: Coleburn, Randy Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" 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: 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: <1329575083.11740.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: 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 > escribi?: De: Coleburn, Randy > Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" > 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: 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: 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 escribi?: De: Coleburn, Randy Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" 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: 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: , <1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com> Message-ID: 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 escribi?: De: Coleburn, Randy Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" 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: 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: 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 escribi?: De: Jay K Asunto: RE: [M3devel] compile errors in m3front's Formal.m3 Para: dabenavidesd at yahoo.es, "m3devel" , rcolebur at scires.com, "Tony" 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 escribi?: De: Coleburn, Randy Asunto: [M3devel] compile errors in m3front's Formal.m3 Para: "m3devel" 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: 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. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] Think we need a new release. C target Para: "Dragi?a Duri?" CC: "m3devel" , "Jay" 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] Think we need a new release. C target Para: "Daniel Alejandro Benavides D." CC: "Jay" , "m3devel" 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: 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: References: <1329335856.39372.YahooMailClassic@web29702.mail.ird.yahoo.com> 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 escribi?: > De: Rodney M. Bates > 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. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] Think we need a new release. C target > Para: m3devel at elegosoft.com, "Rodney M. Bates" > 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 > escribi?: > > > De: Rodney M. Bates > > 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> <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> <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 escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] An awkward interaction of language properties > Para: "Antony Hosking" > 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 . 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? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] atomic operations in cm3 > Para: "m3devel" > Fecha: viernes, 24 de febrero, 2012 15:27 > I cannot find any hint on how to make > use of . 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: 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 . What would I like is to communicate with worker threads without LOCK? Possible? > > TIA, > dd > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>, Message-ID: > 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 . What would I like is to communicate with worker threads without LOCK? Possible? > > TIA, > dd > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <65CC43E2-5AA8-4116-9A98-938C46E6E59F@m3w.org>, 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: 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>, <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: 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>, <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: 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>, <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: 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX) Para: "Antony Hosking" CC: "m3devel" , "Jay K" 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: 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 escribi?: De: Antony Hosking Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX) Para: "Daniel Alejandro Benavides D." CC: "Dragi?a Duri?" , "m3devel" , "Jay K" 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? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] atomic operations in cm3 (also fails on AMD64_LINUX) Para: "Antony Hosking" CC: "m3devel" , "Jay K" 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: