From jay.krell at cornell.edu Fri May 1 00:12:58 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 30 Apr 2009 22:12:58 +0000 Subject: [M3devel] dynamic unload? Message-ID: Does any care what the following do? int main() { while(1) { { void* = dlopen("libm3core.so"); /* more stuff here */ dlclose(x); } return 0; } int main() { while(1) { void* x = dlopen("some-standalone-m3.so"); /* more stuff here */ dlclose(x); } return 0; } int main() { while(1) { void* x = dlopen("some-not-standalone-m3.so"); /* more stuff here */ dlclose(x); } return 0; } (On Windows, these are called LoadLibrary and FreeLibrary.) I haven't run them but I expect they all behave poorly, leaking, leaking thread locals, crashing in the garbage collector thread, etc. A lot of code out there in the world is ok to unload, and I guess a lot is not. I think the above code shouldn't leak or crash. I'm pretty certain they do, probably crash, or at least leak. - Jay From jay.krell at cornell.edu Mon May 4 12:09:12 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 4 May 2009 10:09:12 +0000 Subject: [M3devel] coping with low memory/resources? Message-ID: I invented a policy of one immediate retry for EAGAIN. I'm not sure that will help but it won't hurt much. I'm leary of infinite retry. This will be active maybe tonight. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: coping with low memory/resources? > Date: Wed, 29 Apr 2009 12:27:48 +0000 > > > coping with low memory/resources? > > > We have code that does like > r := pthread_do_something() > assert(r == 0); > > > where for example: > [EAGAIN] > The system lacked the necessary resources (other than memory) to initialise another mutex. > [ENOMEM] > Insufficient memory exists to initialise the mutex. > > > I'll fix it to raise an out of memory exception for ENOMEM. Ok. > But what about EAGAIN? > Retry? That is what "again" means, right? > In an infinite loop? > Or just a few times? > You know -- overall system might be low but other parts might reduce, > or the Modula-3 code itself might be hogging resources and retry might > just sit there forever. > Raise some other exception? > > For now I'll leave it asserting. > > > - Jay From wagner at elegosoft.com Mon May 4 16:46:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 04 May 2009 16:46:57 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> Message-ID: <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> Now it's May 4th, and I feel we should turn to the official release again. Have any of the open issues been closed? Offhand I remember o REFANY/TAGGED REF extensions o alternative TEXT implementation o complete switch to new Unix headers o working cvsup (OK AFAIK) o formsvbt crashes o performance issues: threads, exception frames, texts, ... There are probably more. A short status from those who know would be great. We must also decide which platforms _must_ be part of the release. I'd suggest AMD64_LINUX, LINUXLIBC6, FreeBSD(4/7?), SOLgnu, I386_DARWIN (and/or AMD64_DARWIN?), and of course Windows (native and Cygwin, however these are called these days ;-) Should we add more? I'll need support to build several of them. I suggest that we use the old make_bin_dist_min.sh scripts with the core distribution. Or is something better already completely automated (possibly by Jay)? I'll just try to coordinate things, assign error reports, make some tests myself and setup release candidate access when we start. Or should we postpone one or two weeks? Olaf Quoting Olaf Wagner : > If anybody could test Rodney's TEXT changes and provide some > information on the impacts on our applications, that would help a lot. > > I also wasn't able to read and understand all the mails about small objects. > (Guessing, I'd say I'd need another day for that :-) > Can anybody summarize? > Has a conclusion been reached and what will be done/implemented? > Is this relevant for the next release, or will it take longer? > > Olaf > > Quoting Randy Coleburn : > >> Rodney, sorry but I haven't tried your changes. If your test >> program is available, I would be glad to compile and run it on >> Windows to obtain results for that platform. Just let me know how >> to obtain/install your TEXT changes and the test program. >> >> I am ok with Olaf's suggestion of starting the release process in May. >> >> Again, I will be glad to help on Windows platforms. If necessary, >> I can also test cygwin on Windows. >> >> If we need to test/build/release on HPUX, I have an old v10 system >> I can pull out of storage (note that v10 is an older version of >> HPUX and not current). >> >> Regards, >> Randy Coleburn >> >>>>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> >> Any opinions about the TEXT branch? Anybody tried it? To summarize: >> >> - I have tested it extensively on LINUXLIBC6, with a large random >> test program and two successive rebuilds of CM3. >> >> - It makes no changes in data structure, neither to static declarations >> nor to invariants. Thus it creates no compatibility problems with >> existing >> pickles, etc. >> >> - It slows down concatenation, but more than makes it up in other >> string accessing operations, if the numbers of concatenations and >> accessing operations are equal. >> >> - It cuts down on tree depth and even more or recursion depth >> (which implies needed stack space.) >> >> - This effect is dramatic when strings are built by "linear" concatenations, >> i.e., strictly left-to-right, or vice versa. Gains are moderate when >> concatenations are random. >> >> - It allocates a lot more storage, but abandons a lot more garbage, >> retaining somewhat more space when lots of old strings are retained >> along with newly-built ones. It probably retains less when operand >> strings of concatenations are not kept, but I haven't measured that. >> >> - Strategies are partial rebalancing of concatenation trees, flattening >> of short concatenations, elimination of a lot of tail-recursion, and >> recursing on the shorter side. >> >> >> >> Olaf Wagner wrote: >>> Well, that's a quite long list; but many things are bug fixes anyway, >>> and wouldn't be affected by a code freeze, while others are already >>> finished (as integrating CVSup, as I understand). >>> >>> The only thing we should not do is introduce new platforms while >>> trying to get the system stable. We should concentrate on installation >>> support and bug fixing. >>> >>> I'd suggest to start the release process in about two weeks at the >>> start of May. That should give everybody enough time to either finish >>> their ongoing work that shall make it into the release or decide to >>> postpone it ;-) >>> >>> Any objections? >>> >>> Olaf >>> >>> Quoting Jay : >>> >>>> >>>> > > o When should we start? I.e. wha changes would you like to complete >>>> > > before we start the release process? >>>> >>>> >>>> >>>> >>>> I'd like to see the formsvbt crash debugged and fixed, unless I'm >>>> the only one seeing it. >>>> >>>> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >>>> >>>> I'll try to get this. >>>> >>>> >>>> >>>> >>>> >>>> I'd also like to see: >>>> >>>> >>>> >>>> >>>> >>>> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >>>> >>>> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >>>> >>>> >>>> >>>> >>>> >>>> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >>>> little work (I'll do this). >>>> >>>> Basically just 1) put buildlocal back how it was 2) push it across >>>> more platforms e.g. I think FreeBSD/x86 is the main one missing, >>>> but I'll get to it. >>>> >>>> >>>> >>>> >>>> >>>> cvsup building and in "std" (I'll do this, probably very little >>>> left here really. >>>> >>>> >>>> >>>> >>>> >>>> -- beyond this, not required for release -- >>>> >>>> >>>> >>>> >>>> >>>> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >>>> >>>> (could be "mingw64" is good enough to try AMD64_NT now). >>>> >>>> >>>> >>>> >>>> >>>> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >>>> by me) >>>> >>>> >>>> >>>> >>>> >>>> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >>>> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >>>> seat to important fixes in existing platforms. >>>> >>>> >>>> >>>> >>>> >>>> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >>>> skip C __finally blocks. I've just been very lazy here, should >>>> demonstrate the behavior with a test case, then fix it.. >>>> >>>> >>>> >>>> >>>> >>>> Maybe fix cm3cg so other -g options besides -gstabs works, like >>>> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >>>> leaving nothing, because others cause internal compiler errors, like >>>> on HPPA64_HPUX. >>>> >>>> >>>> >>>> >>>> >>>> Oh, and NT386GNU probably switched back to Win32 threads. >>>> Otherwise one of the test cases hangs and it doesn't look easy to >>>> figure out. I'll do this shortly if I remember. >>>> >>>> But I also wouldn't mind if this platform isn't officially released >>>> either (unless someone else wants to support it). >>>> >>>> >>>> >>>> >>>> >>>> Debug why many NT386MINGNU gui apps crash..but also probably just >>>> don't release this platform and ok asis. >>>> >>>> >>>> >>>> >>>> >>>> - Jay >>>> >>> >>> >>> >> >> >> >> CONFIDENTIALITY NOTICE: This email and any attachments are >> intended solely for the use of the named recipient(s). This e-mail >> may contain confidential and/or proprietary information of >> Scientific Research Corporation. If you are not a named >> recipient, you are prohibited from making any use of the >> information in the email and attachments. If you believe you have >> received this email in error, please notify the sender >> immediately and permanently delete the email, any attachments, >> and all copies thereof from any drives or storage media and >> destroy any printouts of the email or attachments. >> >> EXPORT COMPLIANCE NOTICE: This email and any attachments may >> contain technical data subject to U.S export restrictions under the >> International Traffic in Arms Regulations (ITAR) or the Export >> Administration Regulations (EAR). Export or transfer of this >> technical data and/or related information to any foreign person(s) >> or entity(ies), either within the U.S. or outside of the U.S., may >> require export authorization by the appropriate U.S. Government >> agency prior to export or transfer. In addition, technical data >> may not be exported or transferred to certain countries or >> specified designated nationals identified by U.S. embargo controls >> without prior export authorization. By accepting this email and >> any attachments, all recipients confirm that they understand and >> will comply with all applicable ITAR, EAR and embargo compliance >> requirements. >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon May 4 18:39:09 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 4 May 2009 16:39:09 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> Message-ID: > o complete switch to new Unix headers I386_DARWIN and AMD64_DARWIN not switched. ok though either way. > o working cvsup (OK AFAIK) ok, though I didn't add it to build automation. > o formsvbt crashes Not solved. I couldn't get an older release to work to verify against. > o performance issues: threads, exception frames, texts, ... A little better. I don't think regressed wrt cm3 though. Can release asis I think. > We must also decide which platforms _must_ be part of the release. > I'd suggest AMD64_LINUX, LINUXLIBC6, FreeBSD(4/7?), SOLgnu, > I386_DARWIN (and/or AMD64_DARWIN?), and of course Windows (native and > Cygwin, however these are called these days ;-) I'd just as soon skip Cygwin. Maybe we can have some sort of "tiers"? All of PPC_DARWIN, I386_DARWIN, AMD64_DARWIN can be included. Many others /can/ be included, but I don't know what must/should be included. > Should we add more? I'll need support to build several of them. > > I suggest that we use the old make_bin_dist_min.sh scripts with > the core distribution. Or is something better already completely > automated (possibly by Jay)? I have good automation, with some caveats: No cminstall. A few packages should be added: m3gdb, cm3ide, cvsup There might be a few copyrights missing, and they might be so numerous that a directory should be created, if that is "prominent" enough. There is always more work to do.. - Jay From hosking at cs.purdue.edu Tue May 5 01:13:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 5 May 2009 09:13:57 +1000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> Message-ID: On 5 May 2009, at 00:46, Olaf Wagner wrote: > Now it's May 4th, and I feel we should turn to the official release > again. > > Have any of the open issues been closed? Offhand I remember > > o REFANY/TAGGED REF extensions I have the minimalist version almost ready for checkin. > o alternative TEXT implementation > > o complete switch to new Unix headers > > o working cvsup (OK AFAIK) > > o formsvbt crashes > > o performance issues: threads, exception frames, texts, ... I'd prefer to see stability here for now, rather than on over-the-top performance drive -- there are better solutions out there that we can engineer in, but getting them in may require a stabilization period. > There are probably more. A short status from those who know would > be great. > > We must also decide which platforms _must_ be part of the release. > I'd suggest AMD64_LINUX, LINUXLIBC6, FreeBSD(4/7?), SOLgnu, > I386_DARWIN (and/or AMD64_DARWIN?), and of course Windows (native and > Cygwin, however these are called these days ;-) > > Should we add more? I'll need support to build several of them. > > I suggest that we use the old make_bin_dist_min.sh scripts with > the core distribution. Or is something better already completely > automated (possibly by Jay)? > > I'll just try to coordinate things, assign error reports, make > some tests myself and setup release candidate access when we start. > Or should we postpone one or two weeks? > > Olaf > > > Quoting Olaf Wagner : > >> If anybody could test Rodney's TEXT changes and provide some >> information on the impacts on our applications, that would help a >> lot. >> >> I also wasn't able to read and understand all the mails about small >> objects. >> (Guessing, I'd say I'd need another day for that :-) >> Can anybody summarize? >> Has a conclusion been reached and what will be done/implemented? >> Is this relevant for the next release, or will it take longer? >> >> Olaf >> >> Quoting Randy Coleburn : >> >>> Rodney, sorry but I haven't tried your changes. If your test >>> program is available, I would be glad to compile and run it on >>> Windows to obtain results for that platform. Just let me know >>> how to obtain/install your TEXT changes and the test program. >>> >>> I am ok with Olaf's suggestion of starting the release process in >>> May. >>> >>> Again, I will be glad to help on Windows platforms. If >>> necessary, I can also test cygwin on Windows. >>> >>> If we need to test/build/release on HPUX, I have an old v10 >>> system I can pull out of storage (note that v10 is an older >>> version of HPUX and not current). >>> >>> Regards, >>> Randy Coleburn >>> >>>>>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> >>> Any opinions about the TEXT branch? Anybody tried it? To summarize: >>> >>> - I have tested it extensively on LINUXLIBC6, with a large random >>> test program and two successive rebuilds of CM3. >>> >>> - It makes no changes in data structure, neither to static >>> declarations >>> nor to invariants. Thus it creates no compatibility problems with >>> existing >>> pickles, etc. >>> >>> - It slows down concatenation, but more than makes it up in other >>> string accessing operations, if the numbers of concatenations and >>> accessing operations are equal. >>> >>> - It cuts down on tree depth and even more or recursion depth >>> (which implies needed stack space.) >>> >>> - This effect is dramatic when strings are built by "linear" >>> concatenations, >>> i.e., strictly left-to-right, or vice versa. Gains are moderate >>> when >>> concatenations are random. >>> >>> - It allocates a lot more storage, but abandons a lot more garbage, >>> retaining somewhat more space when lots of old strings are retained >>> along with newly-built ones. It probably retains less when operand >>> strings of concatenations are not kept, but I haven't measured that. >>> >>> - Strategies are partial rebalancing of concatenation trees, >>> flattening >>> of short concatenations, elimination of a lot of tail-recursion, and >>> recursing on the shorter side. >>> >>> >>> >>> Olaf Wagner wrote: >>>> Well, that's a quite long list; but many things are bug fixes >>>> anyway, >>>> and wouldn't be affected by a code freeze, while others are already >>>> finished (as integrating CVSup, as I understand). >>>> >>>> The only thing we should not do is introduce new platforms while >>>> trying to get the system stable. We should concentrate on >>>> installation >>>> support and bug fixing. >>>> >>>> I'd suggest to start the release process in about two weeks at the >>>> start of May. That should give everybody enough time to either >>>> finish >>>> their ongoing work that shall make it into the release or decide to >>>> postpone it ;-) >>>> >>>> Any objections? >>>> >>>> Olaf >>>> >>>> Quoting Jay : >>>> >>>>> >>>>> > > o When should we start? I.e. wha changes would you like to >>>>> complete >>>>> > > before we start the release process? >>>>> >>>>> >>>>> >>>>> >>>>> I'd like to see the formsvbt crash debugged and fixed, unless I'm >>>>> the only one seeing it. >>>>> >>>>> I only see it on Solaris and PPC_DARWIN but haven't tried >>>>> "everything". >>>>> >>>>> I'll try to get this. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I'd also like to see: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >>>>> >>>>> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the >>>>> hardware. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >>>>> little work (I'll do this). >>>>> >>>>> Basically just 1) put buildlocal back how it was 2) push it across >>>>> more platforms e.g. I think FreeBSD/x86 is the main one missing, >>>>> but I'll get to it. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> cvsup building and in "std" (I'll do this, probably very little >>>>> left here really. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- beyond this, not required for release -- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to >>>>> it). >>>>> >>>>> (could be "mingw64" is good enough to try AMD64_NT now). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >>>>> by me) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >>>>> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >>>>> seat to important fixes in existing platforms. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >>>>> skip C __finally blocks. I've just been very lazy here, should >>>>> demonstrate the behavior with a test case, then fix it.. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Maybe fix cm3cg so other -g options besides -gstabs works, like >>>>> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >>>>> leaving nothing, because others cause internal compiler errors, >>>>> like >>>>> on HPPA64_HPUX. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Oh, and NT386GNU probably switched back to Win32 threads. >>>>> Otherwise one of the test cases hangs and it doesn't look easy to >>>>> figure out. I'll do this shortly if I remember. >>>>> >>>>> But I also wouldn't mind if this platform isn't officially >>>>> released >>>>> either (unless someone else wants to support it). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Debug why many NT386MINGNU gui apps crash..but also probably just >>>>> don't release this platform and ok asis. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> - Jay >>>>> >>>> >>>> >>>> >>> >>> >>> >>> CONFIDENTIALITY NOTICE: This email and any attachments are >>> intended solely for the use of the named recipient(s). This e- >>> mail may contain confidential and/or proprietary information of >>> Scientific Research Corporation. If you are not a named >>> recipient, you are prohibited from making any use of the >>> information in the email and attachments. If you believe you >>> have received this email in error, please notify the sender >>> immediately and permanently delete the email, any attachments, >>> and all copies thereof from any drives or storage media and >>> destroy any printouts of the email or attachments. >>> >>> EXPORT COMPLIANCE NOTICE: This email and any attachments may >>> contain technical data subject to U.S export restrictions under >>> the International Traffic in Arms Regulations (ITAR) or the >>> Export Administration Regulations (EAR). Export or transfer of >>> this technical data and/or related information to any foreign >>> person(s) or entity(ies), either within the U.S. or outside of >>> the U.S., may require export authorization by the appropriate >>> U.S. Government agency prior to export or transfer. In >>> addition, technical data may not be exported or transferred to >>> certain countries or specified designated nationals identified >>> by U.S. embargo controls without prior export authorization. By >>> accepting this email and any attachments, all recipients confirm >>> that they understand and will comply with all applicable ITAR, >>> EAR and embargo compliance requirements. >>> >>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Tue May 5 01:14:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 5 May 2009 09:14:37 +1000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> Message-ID: <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> On 5 May 2009, at 02:39, Jay wrote: > >> o complete switch to new Unix headers > > > I386_DARWIN and AMD64_DARWIN not switched. > ok though either way. > > >> o working cvsup (OK AFAIK) > > > ok, though I didn't add it to build automation. > > >> o formsvbt crashes > > Not solved. > I couldn't get an older release to work to verify against. Can you provide a way to repeat your crash? I will try to diagnose and fix. > > > >> o performance issues: threads, exception frames, texts, ... > > > A little better. > I don't think regressed wrt cm3 though. > Can release asis I think. > > >> We must also decide which platforms _must_ be part of the release. >> I'd suggest AMD64_LINUX, LINUXLIBC6, FreeBSD(4/7?), SOLgnu, >> I386_DARWIN (and/or AMD64_DARWIN?), and of course Windows (native and >> Cygwin, however these are called these days ;-) > > > I'd just as soon skip Cygwin. > Maybe we can have some sort of "tiers"? > All of PPC_DARWIN, I386_DARWIN, AMD64_DARWIN can be included. > Many others /can/ be included, but I don't know what must/should be > included. > > >> Should we add more? I'll need support to build several of them. >> >> I suggest that we use the old make_bin_dist_min.sh scripts with >> the core distribution. Or is something better already completely >> automated (possibly by Jay)? > > > I have good automation, with some caveats: > > No cminstall. > A few packages should be added: > m3gdb, cm3ide, cvsup > > > There might be a few copyrights missing, and they might be so > numerous that a directory should be created, if that is "prominent" > enough. > > There is always more work to do.. > > - Jay From jay.krell at cornell.edu Tue May 5 02:07:07 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 5 May 2009 00:07:07 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> Message-ID: >>> o formsvbt crashes >> >> Not solved. >> I couldn't get an older release to work to verify against. > > Can you provide a way to repeat your crash? I will try to diagnose > and fix. while (true) Start up formsvbt. Wait a few seconds. If it doesn't crash, exit it. It happens at least half the time. On PPC_DARWIN and SOL..not sure it was SOLgnu or SOLsun. Did not repro on..I think..LINUXLIBC6, FreeBSD/x86..not sure what all I tried. It seems to somehow be specific to only some platforms. 5.4.0 release had bigger problems here that I forget (on SOLgnu or SOLsun). I only test out X stuff remotely (and don't use X otherwise, what a mess..), though I doubt that matters. I added an assert(foo # NIL) right where the crash is, so now the crash is that assertion failing. - Jay From jay.krell at cornell.edu Tue May 5 09:49:45 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 5 May 2009 07:49:45 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> Message-ID: I meant formedit, not formsvbt. I've seen it now on LINUXLIBC6 but only once in more than 10 runs. jay at localhost ~/dev2/cm3/m3-obliq/obliqlibanim $ /cm3/bin/formsedit *** *** runtime error: *** failed. *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 *** Aborted I added the assertion. It would be followed by a null dereference. C:\dev2\cm3.2\m3-ui\vbtkit\src\lego\POSIX PROCEDURE PaintViewWithShadows (v: T) = ... (* Paint the stripe. *) r := Rect.Inset(stripe, v.shadowPixels); ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, r, stripe); here VBT.PaintTint(v, r, v.shadow.bg); END PaintViewWithShadows; - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release > Date: Tue, 5 May 2009 00:07:07 +0000 > > >>>> o formsvbt crashes >>> >>> Not solved. >>> I couldn't get an older release to work to verify against. >> >> Can you provide a way to repeat your crash? I will try to diagnose >> and fix. > > while (true) > Start up formsvbt. > Wait a few seconds. > If it doesn't crash, exit it. > > > It happens at least half the time. > On PPC_DARWIN and SOL..not sure it was SOLgnu or SOLsun. > Did not repro on..I think..LINUXLIBC6, FreeBSD/x86..not sure what all I tried. > It seems to somehow be specific to only some platforms. > > > 5.4.0 release had bigger problems here that I forget (on SOLgnu or SOLsun). > > > I only test out X stuff remotely (and don't use X otherwise, what a mess..), though I doubt that matters. > I added an assert(foo # NIL) right where the crash is, so now the crash is that assertion failing. > > > > - Jay From jay.krell at cornell.edu Tue May 5 09:54:36 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 5 May 2009 07:54:36 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> Message-ID: seen it on FreeBSD/x86 7.0 now too but also rare. Seemed much more common on Solaris and PPC_DARWIN, which I will try again shortly. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release > Date: Tue, 5 May 2009 07:49:45 +0000 > > > I meant formedit, not formsvbt. > I've seen it now on LINUXLIBC6 but only once in more than 10 runs. > > > jay at localhost ~/dev2/cm3/m3-obliq/obliqlibanim $ /cm3/bin/formsedit > > > *** > *** runtime error: > *** failed. > *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 > *** > Aborted > > > I added the assertion. > It would be followed by a null dereference. > > > C:\dev2\cm3.2\m3-ui\vbtkit\src\lego\POSIX > > > > PROCEDURE PaintViewWithShadows (v: T) = > ... > (* Paint the stripe. *) > r := Rect.Inset(stripe, v.shadowPixels); > ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, > r, stripe); > > here > > > VBT.PaintTint(v, r, v.shadow.bg); > END PaintViewWithShadows; > > > > - Jay > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release >> Date: Tue, 5 May 2009 00:07:07 +0000 >> >> >>>>> o formsvbt crashes >>>> >>>> Not solved. >>>> I couldn't get an older release to work to verify against. >>> >>> Can you provide a way to repeat your crash? I will try to diagnose >>> and fix. >> >> while (true) >> Start up formsvbt. >> Wait a few seconds. >> If it doesn't crash, exit it. >> >> >> It happens at least half the time. >> On PPC_DARWIN and SOL..not sure it was SOLgnu or SOLsun. >> Did not repro on..I think..LINUXLIBC6, FreeBSD/x86..not sure what all I tried. >> It seems to somehow be specific to only some platforms. >> >> >> 5.4.0 release had bigger problems here that I forget (on SOLgnu or SOLsun). >> >> >> I only test out X stuff remotely (and don't use X otherwise, what a mess..), though I doubt that matters. >> I added an assert(foo # NIL) right where the crash is, so now the crash is that assertion failing. >> >> >> >> - Jay From martinbishop at bellsouth.net Wed May 6 02:57:43 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Tue, 05 May 2009 19:57:43 -0500 Subject: [M3devel] Possible Bug? Message-ID: <4A00E087.2000100@bellsouth.net> I have this code, for finding the roots of a quadratic equation: MODULE Quad EXPORTS Main; IMPORT IO, Fmt, RealSqrt; TYPE Roots = ARRAY [1..2] OF REAL; VAR r: Roots; PROCEDURE Solve(a, b, c: REAL): Roots = VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); x: REAL; BEGIN IF b < 0.0 THEN x := (-b + sd) / 2.0 * a; RETURN Roots{x, c / (a * x)}; ELSE x := (-b - sd) / 2.0 * a; RETURN Roots{c / (a * x), x}; END; END Solve; BEGIN r := Solve(1.0, -10.0E5, 1.0); IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); END Quad. When I try to build it, I get: *** *** runtime error: *** <*ASSERT*> failed: FloatMode.SetRounding not implemented *** file "../src/float/IEEE-default/FloatMode.m3", line 14 *** Aborted I'm using: martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version Critical Mass Modula-3 version d5.7.1 last updated: 2009-01-21 compiled: 2009-04-01 13:11:43 configuration: /usr/local/bin/cm3.cfg which was installed from Jay's "std" binary package. From jay.krell at cornell.edu Wed May 6 03:31:29 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 6 May 2009 01:31:29 +0000 Subject: [M3devel] Possible Bug? In-Reply-To: <4A00E087.2000100@bellsouth.net> References: <4A00E087.2000100@bellsouth.net> Message-ID: This has never worked on most platforms. We even deliberately stopped it working where it did -- e.g. SPARC. We could fix it maybe. Please try RealFloat.sqrt instead. It is almost the same thing, but for lack of ability to use single precision, and is likely to be much much faster (how common is hardware sqrt? Anyway, vendor software sqrt is presumably excellent). In future please give callstacks. Run it under gdb or dbx, etc. - Jay ---------------------------------------- > Date: Tue, 5 May 2009 19:57:43 -0500 > From: martinbishop at bellsouth.net > To: m3devel at elegosoft.com > Subject: [M3devel] Possible Bug? > > I have this code, for finding the roots of a quadratic equation: > > MODULE Quad EXPORTS Main; > > IMPORT IO, Fmt, RealSqrt; > > TYPE Roots = ARRAY [1..2] OF REAL; > > VAR r: Roots; > > PROCEDURE Solve(a, b, c: REAL): Roots = > VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); > x: REAL; > BEGIN > IF b < 0.0 THEN > x := (-b + sd) / 2.0 * a; > RETURN Roots{x, c / (a * x)}; > ELSE > x := (-b - sd) / 2.0 * a; > RETURN Roots{c / (a * x), x}; > END; > END Solve; > > BEGIN > r := Solve(1.0, -10.0E5, 1.0); > IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); > END Quad. > > When I try to build it, I get: > > *** > *** runtime error: > *** failed: FloatMode.SetRounding not implemented > *** file "../src/float/IEEE-default/FloatMode.m3", line 14 > *** > > Aborted > > > I'm using: > > martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version > Critical Mass Modula-3 version d5.7.1 > last updated: 2009-01-21 > compiled: 2009-04-01 13:11:43 > configuration: /usr/local/bin/cm3.cfg > > which was installed from Jay's "std" binary package. From jay.krell at cornell.edu Wed May 6 03:38:47 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 6 May 2009 01:38:47 +0000 Subject: [M3devel] Possible Bug? In-Reply-To: <4A00E087.2000100@bellsouth.net> References: <4A00E087.2000100@bellsouth.net> Message-ID: I suggest we provide Cmath.i3 and/or Cfloat.i3 to provide trivial portable wrappers to some of this stuff in an easier to find location instead of buried. Granted, the buriers were trying to make things better in their way. And by portable, I'd limit myself probably to double foo(double); and not likely delve into single precision functions, unless maybe float foof(float) is fairly portable. Eh, since they'd all be external, you can delcare them all and not necessarily implement all of them. In any case the perf might stink compared to C. Visual C++ for example can generate FPU instructions inline such as for sqrt. gcc probably does a good job here too. We'll likely incur function calls for portability. Imho we need to do better with keeping up with "builtin functions" that C compilers gradually accrue and implement very well. It is difficult though, for reasons of portability. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: martinbishop at bellsouth.net; m3devel at elegosoft.com > Subject: RE: [M3devel] Possible Bug? > Date: Wed, 6 May 2009 01:31:29 +0000 > > > This has never worked on most platforms. > We even deliberately stopped it working where it did -- e.g. SPARC. > We could fix it maybe. > > > Please try RealFloat.sqrt instead. > > > It is almost the same thing, but for lack of ability to use single precision, and is likely to be much much faster (how common is hardware sqrt? Anyway, vendor software sqrt is presumably excellent). > > > In future please give callstacks. > Run it under gdb or dbx, etc. > > > - Jay > > > > ---------------------------------------- >> Date: Tue, 5 May 2009 19:57:43 -0500 >> From: martinbishop at bellsouth.net >> To: m3devel at elegosoft.com >> Subject: [M3devel] Possible Bug? >> >> I have this code, for finding the roots of a quadratic equation: >> >> MODULE Quad EXPORTS Main; >> >> IMPORT IO, Fmt, RealSqrt; >> >> TYPE Roots = ARRAY [1..2] OF REAL; >> >> VAR r: Roots; >> >> PROCEDURE Solve(a, b, c: REAL): Roots = >> VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); >> x: REAL; >> BEGIN >> IF b < 0.0 THEN >> x := (-b + sd) / 2.0 * a; >> RETURN Roots{x, c / (a * x)}; >> ELSE >> x := (-b - sd) / 2.0 * a; >> RETURN Roots{c / (a * x), x}; >> END; >> END Solve; >> >> BEGIN >> r := Solve(1.0, -10.0E5, 1.0); >> IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); >> END Quad. >> >> When I try to build it, I get: >> >> *** >> *** runtime error: >> *** failed: FloatMode.SetRounding not implemented >> *** file "../src/float/IEEE-default/FloatMode.m3", line 14 >> *** >> >> Aborted >> >> >> I'm using: >> >> martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version >> Critical Mass Modula-3 version d5.7.1 >> last updated: 2009-01-21 >> compiled: 2009-04-01 13:11:43 >> configuration: /usr/local/bin/cm3.cfg >> >> which was installed from Jay's "std" binary package. From mika at async.caltech.edu Wed May 6 04:24:31 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 05 May 2009 19:24:31 -0700 Subject: [M3devel] Possible Bug? In-Reply-To: Your message of "Wed, 06 May 2009 01:38:47 -0000." Message-ID: <200905060224.n462OVIR060238@camembert.async.caltech.edu> I don't think it's particularly hard to find...? The interface I almost always use is "Math.i3" and it has things like this in it: <*EXTERNAL*> PROCEDURE sqrt (x: LONGREAL): LONGREAL; (* returns the square root of x. *) I think you get pretty good performance with that. If you want speed on x86, you code in f77 and use Intel's ifort (-sse2, or whatever hardware you have in your machine). You can get it free for Linux. I compile -S on Linux and then use GNU as on FreeBSD to get my objects. It's really easy to link that code with M3 if you want to do that. All you have to remember is that all the arrays are transposed and in Fortran they start from 1, of course. Then you just pass ADR(a[0,..,0]) to the f77 code. But my experience has been that Modula-3 code really doesn't perform that poorly on numerical work. If you turn on optimization, that is. Mika Jay writes: > >I suggest we provide Cmath.i3 and/or Cfloat.i3 to provide trivial portable wrappers to some of this stuff in an easier to find location instead of buried. Granted, the buriers were trying to make things bette >r in their way. > > >And by portable, I'd limit myself probably to >double foo(double); > > >and not likely delve into single precision functions, unless maybe >float foof(float) is fairly portable. > >Eh, since they'd all be external, you can delcare them all and not necessarily implement all of them. > > >In any case the perf might stink compared to C. >Visual C++ for example can generate FPU instructions inline such as for sqrt. >gcc probably does a good job here too. >We'll likely incur function calls for portability. > > >Imho we need to do better with keeping up with "builtin functions" that C compilers gradually accrue and implement very well. >It is difficult though, for reasons of portability. > > > - Jay > >---------------------------------------- >> From: jay.krell at cornell.edu >> To: martinbishop at bellsouth.net; m3devel at elegosoft.com >> Subject: RE: [M3devel] Possible Bug? >> Date: Wed, 6 May 2009 01:31:29 +0000 >> >> >> This has never worked on most platforms. >> We even deliberately stopped it working where it did -- e.g. SPARC. >> We could fix it maybe. >> >> >> Please try RealFloat.sqrt instead. >> >> >> It is almost the same thing, but for lack of ability to use single precision, and is likely to be much much faster (how common is hardware sqrt? Anyway, vendor software sqrt is presumably excellent). >> >> >> In future please give callstacks. >> Run it under gdb or dbx, etc. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Tue, 5 May 2009 19:57:43 -0500 >>> From: martinbishop at bellsouth.net >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] Possible Bug? >>> >>> I have this code, for finding the roots of a quadratic equation: >>> >>> MODULE Quad EXPORTS Main; >>> >>> IMPORT IO, Fmt, RealSqrt; >>> >>> TYPE Roots = ARRAY [1..2] OF REAL; >>> >>> VAR r: Roots; >>> >>> PROCEDURE Solve(a, b, c: REAL): Roots = >>> VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); >>> x: REAL; >>> BEGIN >>> IF b < 0.0 THEN >>> x := (-b + sd) / 2.0 * a; >>> RETURN Roots{x, c / (a * x)}; >>> ELSE >>> x := (-b - sd) / 2.0 * a; >>> RETURN Roots{c / (a * x), x}; >>> END; >>> END Solve; >>> >>> BEGIN >>> r := Solve(1.0, -10.0E5, 1.0); >>> IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); >>> END Quad. >>> >>> When I try to build it, I get: >>> >>> *** >>> *** runtime error: >>> *** failed: FloatMode.SetRounding not implemented >>> *** file "../src/float/IEEE-default/FloatMode.m3", line 14 >>> *** >>> >>> Aborted >>> >>> >>> I'm using: >>> >>> martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version >>> Critical Mass Modula-3 version d5.7.1 >>> last updated: 2009-01-21 >>> compiled: 2009-04-01 13:11:43 >>> configuration: /usr/local/bin/cm3.cfg >>> >>> which was installed from Jay's "std" binary package. From jay.krell at cornell.edu Wed May 6 15:53:25 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 6 May 2009 13:53:25 +0000 Subject: [M3devel] heapalloc/try during initialization In-Reply-To: References: <20090506002150.A15FECC3B4@birch.elegosoft.com> <46F424EA-6C63-42C4-A120-C1B0FD394AA6@cs.purdue.edu> <54967B00-3878-4147-AA90-FBD09F98161B@cs.purdue.edu> Message-ID: Something like the attached? (I don't trust email to be formated as expected, so the attachment is canonical and the rest might not be readable.) The idea is to provide a split CollectEnough for AllocTraced to call. It's a little lose on the locking but it should be ok and slows down the slow path with extra unlock/relock. It's good to get the try out of the fast path in either case. PROCEDURE LockedCollectEnough (allocator := FALSE) = BEGIN TRY CollectEnough(allocator); FINALLY RTOS.UnlockHeap(); END; END LockedCollectEnough; AllocTraced calls this: PROCEDURE UnlockedCollectEnough (allocator := FALSE) = BEGIN RTOS.LockHeap(); IF collectorOn THEN RTOS.UnlockHeap(); RETURN END; (* duplicated from CollectEnough *) IF NOT Behind() THEN RTOS.UnlockHeap(); RETURN END; (* duplicated from CollectEnough *) ThreadF.Init shouldn't get here: LockedCollectEnough(allocator); END UnlockedCollectEnough; AllocTraced slow path excerpt: IF nextPtr> thread.newPool.limit THEN (* not enough space left in the pool, take the long route *) res := NIL; nextPtr := NIL; (* in case of GC... *) DEC(thread.inCritical); (* make sure the collector gets a chance to keep up with NEW... *) UnlockedCollectEnough(allocator := TRUE); (***) RTOS.LockHeap(); (***) res := LongAlloc (dataSize, dataAlignment, thread.newPool, Note.Allocated, pure := FALSE); IF res = NIL THEN RTOS.UnlockHeap(); (***) RuntimeError.Raise(RuntimeError.T.OutOfMemory); END; INC(thread.inCritical); LOOPHOLE(res - ADRSIZE(Header), RefHeader)^ := Header{typecode := def.typecode, dirty := TRUE}; IF initProc # NIL THEN initProc (res) END; RTOS.UnlockHeap(); (***) DEC(thread.inCritical); RETURN LOOPHOLE(res, REFANY); This is all for user threads. There /may/ have been issues with pthreads/ntthreads, but I don't there are now. Your changed didn't break cygwin pthreads but it did break FreeBSD user threads. I only checked each case once so might have made mistakes and gotten it backwards or whatever. Ignorant question/suggestion similar to previous: Thread.T vs. Activation? Userthreads does traced allocations where pthreads/win32threads don't. Maybe change userthreads? Maybe give up on userthreads? This isn't a great reason, granted. I actually would hope the traced thread.t vs. activation could go away, it is ugly. Kudos for user threads for not having it?? (I wonder if there is something around the fact that thread locals aren't visible to the garbage collector..?) - Jay -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RTCollector.m3 URL: From rodney.m.bates at cox.net Wed May 6 16:01:11 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 06 May 2009 09:01:11 -0500 Subject: [M3devel] Possible Bug? In-Reply-To: <4A00E087.2000100@bellsouth.net> References: <4A00E087.2000100@bellsouth.net> Message-ID: <4A019827.4000702@cox.net> Still, if we have library functions that crash, we should document that somewhere reasonably conspicuous. It is really false advertising and a trap for a programmer to put something in an interface and then disable it. It is not enough to just have alternative square root functions that work. A newcomer to the language should not have to ferret this kind of thing out by systematic linear search of all the libraries. The same place that documents the broken functions should give pointers to the alternatives. Martin Bishop wrote: > I have this code, for finding the roots of a quadratic equation: > > MODULE Quad EXPORTS Main; > > IMPORT IO, Fmt, RealSqrt; > > TYPE Roots = ARRAY [1..2] OF REAL; > > VAR r: Roots; > > PROCEDURE Solve(a, b, c: REAL): Roots = > VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); > x: REAL; > BEGIN > IF b < 0.0 THEN > x := (-b + sd) / 2.0 * a; > RETURN Roots{x, c / (a * x)}; > ELSE > x := (-b - sd) / 2.0 * a; > RETURN Roots{c / (a * x), x}; > END; > END Solve; > > BEGIN > r := Solve(1.0, -10.0E5, 1.0); > IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); > END Quad. > > When I try to build it, I get: > > *** > *** runtime error: > *** <*ASSERT*> failed: FloatMode.SetRounding not implemented > *** file "../src/float/IEEE-default/FloatMode.m3", line 14 > *** > > Aborted > > > I'm using: > > martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version > Critical Mass Modula-3 version d5.7.1 > last updated: 2009-01-21 > compiled: 2009-04-01 13:11:43 > configuration: /usr/local/bin/cm3.cfg > > which was installed from Jay's "std" binary package. > From eiserlohpp at yahoo.com Wed May 6 19:04:12 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 6 May 2009 10:04:12 -0700 (PDT) Subject: [M3devel] [Modula-3] Release engineering Message-ID: <164357.23058.qm@web56803.mail.re3.yahoo.com> Hi Olaf, Please help support distribution packaging (various Linux, or BSD ports) by adding to your list: o Design the cm3 installation to be long term. o Allow cm3 to be installed into /usr, instead of /usr/local. o Allow installation to temporary root during package building. o Specify guidelines for which m3.pkgs go into which distribution packages (rpm, deb). List the suggested package names. o Documentation: Write manual page for cm3. o Conform where possible to the FHS. o Allow easy cross compiling. o (lower priority) Use long form options. Explaination: (0) Only the administrator should install packages into the system. If a user wants to play with a recent version of CM3, they should be able to install into their home directory. This will allow the other users of the machine to continue using the known good compiler even though one user is experimenting with buggy new features of the compiler. This will also allow easier cross compiling. (1) /usr/local is only for files/packages manually installed by the superuser. Distributions are expected (in debian, required) to install into "/usr" (or if required to boot, into "/", eg., /sbin/mount). (2) The build process of a package usually installs all files into a subdirectory where the internal paths mimic the final installation paths (/home/peter/src/modula3/cm3/src-all-20090506/debian/cm3-compiler). Libraries and executable's link paths should be adjusted to their final installation paths, not the temporary. (3) May I suggest this start: cm3-compiler, cm3-corelibs (minimal install: m3core, libm3 binaries), cm3-devel (source code to m3core, and libm3), ..., etc. What I don't want to see is the mass installation of a complete development system simply because the user wanted to use a program written in Modula-3. (4) Debian at least requires a manual page for executables. A bug will be written against any package that installs user (or superuser) binaries without a manual page. (5) The Filesystem Hierarchy Standard (FHS) http://www.pathname.com/fhs/ says things such as libraries are not execuables invocable by the user so don't put them in $(prefix)/bin. Okay, MS-Windows violates this all the time, but they are "special". Can we move cm3.cfg out of the binary directory (where there should only be executables), and into ${CM3_PATH}/etc. Something like: mypath := FindAbsolutePath(argv[0]); cm3_bin_path := DirName(mypath); cm3_path := DirName(cm3_bin_path); cm3_etc_path := cm3_path & "/etc"; cm3_config_filename = cm3_etc_path & "/cm3.cfg"; (6) Cross compiling: the cm3.cfg should be a one liner, which includes the configuration of the installed target machine . cm3.cfg: Include("AMD64_LINUX"); When cross compiling the user should be able to specify the actual config file for the desired TARGET machine. (7) Although each program is free to define is command line arguments and options, a set of conventions has been in place for at least 15 years or more. GCC of course (being an older program) violates these "recent" conventions. Options start with a dash. Single letter options start with a single dash, and multiple options may be collected into one sequence (ie, "-shared", means -s, -h, -a, -r, -e, -d). Long options use two dashes and signify that the sequence of characters are to be used as a complete string (ie, "--shared" means generate a "shared" library). Long options that take an argument are formed with an equal sign (eg. "--config=/home/peter/cm3/etc/cm3.cfg"). Instead of "-version" with a single dash, long form options use two dashes "--version", a single dash "-v" could also be mapped to be an alias of that option. Sorry for being long winded, but my system administrator is a real hard ass, every time I see myself in the mirror, he reminds me of that. Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From michael.anderson at elego.de Wed May 6 22:23:06 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 06 May 2009 22:23:06 +0200 Subject: [M3devel] Modula3 Trac Message-ID: <20090506222306.3s9jhiyqmsoo0gg8@mail.elego.de> Greetings Modula3 Devs and Users, For those who don't know about it already, the cm3 bug/issue tracking system is at: https://projects.elegosoft.com/cm3 If you haven't visited this site recently, your browser will most likely make some noise about our self-signed certificate. For the paranoid: SHA1 Fingerprint=0C:D2:67:0D:AF:BD:88:1D:DE:E8:0A:CA:27:B3:F2:36:91:FE:C6:AC MD5 Fingerprint=54:66:21:EF:6A:2A:6E:83:F4:D3:C0:E3:55:0C:EE:01 -Mike -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From hosking at cs.purdue.edu Wed May 6 23:27:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 7 May 2009 07:27:29 +1000 Subject: [M3devel] heapalloc/try during initialization In-Reply-To: References: <20090506002150.A15FECC3B4@birch.elegosoft.com> <46F424EA-6C63-42C4-A120-C1B0FD394AA6@cs.purdue.edu> <54967B00-3878-4147-AA90-FBD09F98161B@cs.purdue.edu> Message-ID: <7413A449-0E6B-40CB-9D4E-213DFB417143@cs.purdue.edu> I'm working on this today. Let me get back to you. On 6 May 2009, at 23:53, Jay wrote: > > Something like the attached? > > (I don't trust email to be formated as expected, so the attachment > is canonical and the rest might not be readable.) > > > The idea is to provide a split CollectEnough for AllocTraced to call. > It's a little lose on the locking but it should be ok and slows down > the slow path with extra unlock/relock. > > > > It's good to get the try out of the fast path in either case. > > > > PROCEDURE LockedCollectEnough (allocator := FALSE) = > BEGIN > TRY > CollectEnough(allocator); > FINALLY > RTOS.UnlockHeap(); > END; > END LockedCollectEnough; > > > > AllocTraced calls this: > > > > PROCEDURE UnlockedCollectEnough (allocator := FALSE) = > BEGIN > RTOS.LockHeap(); > IF collectorOn THEN RTOS.UnlockHeap(); RETURN END; (* duplicated > from CollectEnough *) > IF NOT Behind() THEN RTOS.UnlockHeap(); RETURN END; (* duplicated > from CollectEnough *) > > ThreadF.Init shouldn't get here: > > > > LockedCollectEnough(allocator); > END UnlockedCollectEnough; > > > AllocTraced slow path excerpt: > > > IF nextPtr> thread.newPool.limit THEN > (* not enough space left in the pool, take the long route *) > res := NIL; nextPtr := NIL; (* in case of GC... *) > DEC(thread.inCritical); > (* make sure the collector gets a chance to keep up with NEW... > *) > UnlockedCollectEnough(allocator := TRUE); (***) > RTOS.LockHeap(); (***) > res := LongAlloc (dataSize, dataAlignment, thread.newPool, > Note.Allocated, pure := FALSE); > IF res = NIL THEN > RTOS.UnlockHeap(); (***) > RuntimeError.Raise(RuntimeError.T.OutOfMemory); > END; > INC(thread.inCritical); > LOOPHOLE(res - ADRSIZE(Header), RefHeader)^ := > Header{typecode := def.typecode, dirty := TRUE}; > IF initProc # NIL THEN initProc (res) END; > RTOS.UnlockHeap(); (***) > > DEC(thread.inCritical); > RETURN LOOPHOLE(res, REFANY); > > > This is all for user threads. > There /may/ have been issues with pthreads/ntthreads, but I don't > there are now. > Your changed didn't break cygwin pthreads but it did break FreeBSD > user threads. > I only checked each case once so might have made mistakes and gotten > it backwards or whatever. > > > Ignorant question/suggestion similar to previous: > Thread.T vs. Activation? Userthreads does traced allocations where > pthreads/win32threads don't. Maybe change userthreads? > Maybe give up on userthreads? This isn't a great reason, granted. > I actually would hope the traced thread.t vs. activation could go > away, it is ugly. Kudos for user threads for not having it?? (I > wonder if there is something around the fact that thread locals > aren't visible to the garbage collector..?) > > > - Jay From jay.krell at cornell.edu Wed May 6 23:40:24 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 6 May 2009 21:40:24 +0000 Subject: [M3devel] [Modula-3] Release engineering In-Reply-To: <164357.23058.qm@web56803.mail.re3.yahoo.com> References: <164357.23058.qm@web56803.mail.re3.yahoo.com> Message-ID: ---------------------------------------- > Date: Wed, 6 May 2009 10:04:12 -0700 > From: eiserlohpp > > Hi Olaf, > > Please help support distribution packaging (various Linux, or BSD ports) > by adding to your list: apt-get install cm3 would be nice, agreed. You have to be an official Debian developer though, right? As would cd /usr/ports/lang/cm3; make; make install. There is ezm3 but.. > o Design the cm3 installation to be long term. Specifically? > o Allow cm3 to be installed into /usr, instead of /usr/local. Doesn't that already work? I don't do it, but it should work. > o Allow installation to temporary root during package building. This does work in a fashion, but maybe not sufficiently or easily enough. But maybe both too. :) Specifically, you can install the entire system to a temporary root. You "have to" put the compiler, m3core, libm3 there, then you can also put your own stuff there. My automation does this and I think Olaf's does too. Actually I think you can start out with just the compiler. Look at make-dist.py? And the others? > o Specify guidelines for which m3.pkgs go into which distribution > packages (rpm, deb). List the suggested package names. There is a delineation of "std" and "min". The sh code is nicely data driven. The Python actually is not currently. More package sets could be defined, but it gets confusing. Is it good that X was broken down into a bajillion packages or not? Not clear to me. > o Documentation: Write manual page for cm3. Yep. > o Conform where possible to the FHS. Don't we? Is carving out /usr/local/cm3 against that? Isn't conforming to FHS a matter of what we use, not where we install, as long as we don't litter all over the system? > o Allow easy cross compiling. We do already, sort of, and for some definition of "easy". In particular, cross /compilation/ of Modula-3 is easy. There is some C code and there is some linking. Cross building involves cross compile the Modula-3, to assembly. tar it up copy it over to target system extract make -- which compiles C and links Doing a "full" cross build should just be a matter of either altering $PATH or the config file to find a different C compiler and linker. You also need a cm3cg per target. My config files (now the config files) do probe around in "reasonable" way (a little too haphazard really) so that you can have multiple cm3cgs, don't have to edit $PATH or copy files aorund. > o (lower priority) Use long form options. We have so few options and personally I think -long is fine. The only advantage of -a -b -c vs. -long is you can combine -abc unambiguously. Heck even configure supports -long even though the usage doesn't say so. > > (2) The build process of a package usually installs all files into a > subdirectory where the internal paths mimic the final installation paths > (/home/peter/src/modula3/cm3/src-all-20090506/debian/cm3-compiler). > Libraries and executable's link paths should be adjusted to their > final installation paths, not the temporary. This is already fixed or in progress. I've been mucking with "runpath" lately. I'd like to do more here, soon. There isn't one answer though. We have "buildlocal" and "buildglobal". And people want to be able to run "unshipped" (not installed) binaries. Currently the compromise: buildlocal has those paths buildglobal does not if you want to run uninstalled buildglobal, use build_standalone relinking upon install has been discussed but so far isn't done. I know some systems do that (via libtool). > (3) May I suggest this start: cm3-compiler, cm3-corelibs (minimal > install: m3core, libm3 binaries), cm3-devel (source code to m3core, > and libm3), ..., etc. > > What I don't want to see is the mass installation of a complete > development system simply because the user wanted to use a program > written in Modula-3. Understood. There are a lot shared libs though. The "min" package set satisfies many programs, but not all. build_standalone is available but not great. > Something like: > mypath := FindAbsolutePath(argv[0]); > cm3_bin_path := DirName(mypath); > cm3_path := DirName(cm3_bin_path); > cm3_etc_path := cm3_path & "/etc"; > cm3_config_filename = cm3_etc_path & "/cm3.cfg"; Ah. Not sure. /etc vs. next to the binary. I do probe around for next to the binary + target platform, for the configuration and the backend. Probing for ../etc I guess is reasonable. That way you can rm -rf the "installation" without losing the configuration. However, another idea is to declare that the configuration is not in fact user editable. I have tried to write configuration files that work for everyone. But maybe that is impossible. The actual parts that cminstall asks about to make edits aren't really user settings. They are OS settings that a better system would just get correct. Like with autoconf -- do you expect to edit its output? Only if desperate. But it is gray. Using "gcc" from $PATH vs. a full path to gcc? Using gcc-3 or gcc-4 (Cygwin and MacOSX have such). Are those "machine" settings decided during install? Or user settings? Go with the binary or in etc? I'm not sure. > (6) Cross compiling: the cm3.cfg should be a one liner, which includes > the configuration of the installed target machine . > cm3.cfg: > Include("AMD64_LINUX"); That's how I do things already, long time now. > When cross compiling the user should be able to specify the actual config file for the desired TARGET machine. My Python scripts accept a target machine on the command line. cd scripts/python ./do-cm3-core.py buildship FreeBSD4 usually with boot: ./do-cm3-core.py buildship FreeBSD4 boot but also when it is somewhat ambiguous like NT386 or NT386GNU. This guides chosing a config file. Granted, this should be in cm3, not layered on. I've been "afraid" to take such big steps without working through getting a large consensus. Layering on with Python, I can do whatever the heck I want when I want. :) Can you help? - Jay From jay.krell at cornell.edu Wed May 6 23:56:56 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 6 May 2009 21:56:56 +0000 Subject: [M3devel] heapalloc/try during initialization In-Reply-To: <7413A449-0E6B-40CB-9D4E-213DFB417143@cs.purdue.edu> References: <20090506002150.A15FECC3B4@birch.elegosoft.com> <46F424EA-6C63-42C4-A120-C1B0FD394AA6@cs.purdue.edu> <54967B00-3878-4147-AA90-FBD09F98161B@cs.purdue.edu> <7413A449-0E6B-40CB-9D4E-213DFB417143@cs.purdue.edu> Message-ID: Ok. I commited my version that seems ok and seems to work but you can overwrite it. Something that only takes the lock once would be preferred. And perhaps always uses/try/finally when it does take the lock instead of my less consistent harder to maintain form. Probably move yours away, update, copy yours on top of mine, compare. Resolving conflicts in cvs is lame.. Also, another obvious approach is to duplicate the LongAlloc initialization, such that the fast path works for the first allocation. Or even for all allocations until the GC is ready. I was reluctant to duplicate that tricky coe, but it's only a few lines really and could be moved into a shared function. Either way I think AllocTraced should not have TRY, to speed up the fast path. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 7 May 2009 07:27:29 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] heapalloc/try during initialization > > I'm working on this today. Let me get back to you. > > On 6 May 2009, at 23:53, Jay wrote: > >> >> Something like the attached? >> >> (I don't trust email to be formated as expected, so the attachment >> is canonical and the rest might not be readable.) >> >> >> The idea is to provide a split CollectEnough for AllocTraced to call. >> It's a little lose on the locking but it should be ok and slows down >> the slow path with extra unlock/relock. >> >> >> >> It's good to get the try out of the fast path in either case. >> >> >> >> PROCEDURE LockedCollectEnough (allocator := FALSE) = >> BEGIN >> TRY >> CollectEnough(allocator); >> FINALLY >> RTOS.UnlockHeap(); >> END; >> END LockedCollectEnough; >> >> >> >> AllocTraced calls this: >> >> >> >> PROCEDURE UnlockedCollectEnough (allocator := FALSE) = >> BEGIN >> RTOS.LockHeap(); >> IF collectorOn THEN RTOS.UnlockHeap(); RETURN END; (* duplicated >> from CollectEnough *) >> IF NOT Behind() THEN RTOS.UnlockHeap(); RETURN END; (* duplicated >> from CollectEnough *) >> >> ThreadF.Init shouldn't get here: >> >> >> >> LockedCollectEnough(allocator); >> END UnlockedCollectEnough; >> >> >> AllocTraced slow path excerpt: >> >> >> IF nextPtr> thread.newPool.limit THEN >> (* not enough space left in the pool, take the long route *) >> res := NIL; nextPtr := NIL; (* in case of GC... *) >> DEC(thread.inCritical); >> (* make sure the collector gets a chance to keep up with NEW... >> *) >> UnlockedCollectEnough(allocator := TRUE); (***) >> RTOS.LockHeap(); (***) >> res := LongAlloc (dataSize, dataAlignment, thread.newPool, >> Note.Allocated, pure := FALSE); >> IF res = NIL THEN >> RTOS.UnlockHeap(); (***) >> RuntimeError.Raise(RuntimeError.T.OutOfMemory); >> END; >> INC(thread.inCritical); >> LOOPHOLE(res - ADRSIZE(Header), RefHeader)^ := >> Header{typecode := def.typecode, dirty := TRUE}; >> IF initProc # NIL THEN initProc (res) END; >> RTOS.UnlockHeap(); (***) >> >> DEC(thread.inCritical); >> RETURN LOOPHOLE(res, REFANY); >> >> >> This is all for user threads. >> There /may/ have been issues with pthreads/ntthreads, but I don't >> there are now. >> Your changed didn't break cygwin pthreads but it did break FreeBSD >> user threads. >> I only checked each case once so might have made mistakes and gotten >> it backwards or whatever. >> >> >> Ignorant question/suggestion similar to previous: >> Thread.T vs. Activation? Userthreads does traced allocations where >> pthreads/win32threads don't. Maybe change userthreads? >> Maybe give up on userthreads? This isn't a great reason, granted. >> I actually would hope the traced thread.t vs. activation could go >> away, it is ugly. Kudos for user threads for not having it?? (I >> wonder if there is something around the fact that thread locals >> aren't visible to the garbage collector..?) >> >> >> - Jay > From hendrik at topoi.pooq.com Thu May 7 02:41:30 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 6 May 2009 20:41:30 -0400 Subject: [M3devel] [Modula-3] Release engineering In-Reply-To: References: <164357.23058.qm@web56803.mail.re3.yahoo.com> Message-ID: <20090507004130.GA30632@topoi.pooq.com> On Wed, May 06, 2009 at 09:40:24PM +0000, Jay wrote: > > apt-get install cm3 would be nice, agreed. > You have to be an official Debian developer though, right? No. It takes a Debian developer to put the package into the official Debian distribution. But you can get a user to update his /etc/apt/sources.list file to include your Debian-compatible repository as well as the official ones. And after that, the usual upgrade commands will detect when there's a new release, and so forth. That's not an unusual thing for upstream developers to do; it's easy on the users, and it gives a Official Debian Developer something to examine when deciding whether it conforms to Debian's standards. -- hendrik From wagner at elegosoft.com Thu May 7 18:05:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 07 May 2009 18:05:12 +0200 Subject: [M3devel] [Modula-3] Release engineering In-Reply-To: <164357.23058.qm@web56803.mail.re3.yahoo.com> References: <164357.23058.qm@web56803.mail.re3.yahoo.com> Message-ID: <20090507180512.8lvj3piqokcckook@mail.elegosoft.com> That's quite a long wish list you've got there, and as it is not Christmas, I'm afraid that we won't be able to fulfill all of them :-) The release engineering I volunteered to undertake was not supposed to add significant functionality to the existing code base; I'll only try to package what is there, perform some tests, and urge others to correct the bugs and shortcomings I find. So if something isn't there and nobody volunteers to write it, it will probably not make its way into the distribution. Indeed it would be rather late for the now planned release to add new features. Jay already made some comments, I'll add some more below, too. Quoting Peter Eiserloh : > > Hi Olaf, > > Please help support distribution packaging (various Linux, or BSD ports) > by adding to your list: > > o Design the cm3 installation to be long term. Hm. This is rather vague... > o Allow cm3 to be installed into /usr, instead of /usr/local. That should already be possible; AFAIK there is no need to install to a certain location. > o Allow installation to temporary root during package building. Jay commented on it, but I'm not sure if that was what you meant. > o Specify guidelines for which m3.pkgs go into which distribution > packages (rpm, deb). List the suggested package names. Sure we can suggest a classification of M3 packages for installation packages; I cannot build system dependent package formats though (unless we automate that at a central and publicly reachable location). > o Documentation: Write manual page for cm3. I can do that. > o Conform where possible to the FHS. Don't we? You don't mean we should split up all the packages into different locations, do you? > o Allow easy cross compiling. Cross-compilation is never easy in my experience, but Jay has done a lot of work in this area. > o (lower priority) Use long form options. Where exactly? Perhaps we can add some additional long options where you would most need them? > Explaination: > > (0) Only the administrator should install packages into the system. > If a user wants to play with a recent version of CM3, they should be > able to install into their home directory. This will allow the > other users of the machine to continue using the known good compiler > even though one user is experimenting with buggy new features of > the compiler. This will also allow easier cross compiling. > > (1) /usr/local is only for files/packages manually installed > by the superuser. Distributions are expected (in debian, required) to > install into "/usr" (or if required to boot, into "/", eg., /sbin/mount). That's exactly because the default installation of CM3 is /usr/local ;-) We've never provided system-specific package formats until now. Of course system packages should install into their preferred locations. > (2) The build process of a package usually installs all files into a > subdirectory where the internal paths mimic the final installation paths > (/home/peter/src/modula3/cm3/src-all-20090506/debian/cm3-compiler). > Libraries and executable's link paths should be adjusted to their > final installation paths, not the temporary. I doubt that I will be able to do something about the paths problems. I hope that Jay's $ORIGIN uses will somehow be adequate. > (3) May I suggest this start: cm3-compiler, cm3-corelibs (minimal > install: m3core, libm3 binaries), cm3-devel (source code to m3core, > and libm3), ..., etc. CM3 always installs the complete source code along with the package targets (libraries or programs), as there are many tools that rely on it. > What I don't want to see is the mass installation of a complete > development system simply because the user wanted to use a program > written in Modula-3. We always offered a minimal binary package. I'll think about a useful classification of packages. > (4) Debian at least requires a manual page for executables. A bug > will be written against any package that installs user (or superuser) > binaries without a manual page. I won't be able to provide manual pages for all M3 programs. > (5) The Filesystem Hierarchy Standard (FHS) http://www.pathname.com/fhs/ > says things such as libraries are not execuables invocable by the user > so don't put them in $(prefix)/bin. Okay, MS-Windows violates this all > the time, but they are "special". Can we move cm3.cfg out of the binary > directory (where there should only be executables), and into > ${CM3_PATH}/etc. I won't change anything concerning the configuration files at the last minute. This will most likely result in weeks of delay (as it will break lots of scripts and regression tests). The location of configuration files can always be overridden by the environment; system-specific packages should use this feature if necessary. As I've said, several provided scripts will break, but they aren't usually end-user relevant. > Something like: > mypath := FindAbsolutePath(argv[0]); > cm3_bin_path := DirName(mypath); > cm3_path := DirName(cm3_bin_path); > cm3_etc_path := cm3_path & "/etc"; > cm3_config_filename = cm3_etc_path & "/cm3.cfg"; I'm not against such changes, but they won't make it into this release, and somebody will have to volunteer to do them. > (6) Cross compiling: the cm3.cfg should be a one liner, which includes > the configuration of the installed target machine . > cm3.cfg: > Include("AMD64_LINUX"); > > When cross compiling the user should be able to specify the actual > config file for the desired TARGET machine. Nice wish, but maybe Jay will deliver something here. > (7) Although each program is free to define is command line arguments > and options, a set of conventions has been in place for at least > 15 years or more. GCC of course (being an older program) violates > these "recent" conventions. > > Options start with a dash. Single letter options start with a > single dash, and multiple options may be collected into one > sequence (ie, "-shared", means -s, -h, -a, -r, -e, -d). Long > options use two dashes and signify that the sequence of characters > are to be used as a complete string (ie, "--shared" means generate > a "shared" library). Long options that take an argument are formed > with an equal sign (eg. "--config=/home/peter/cm3/etc/cm3.cfg"). > > Instead of "-version" with a single dash, long form options use > two dashes "--version", a single dash "-v" could also be mapped > to be an alias of that option. We can add some long options, as said before, but I'm not going to break all backward compatibility by removing or changing existing ones. Someone will have to write an extended ParseParams module though :-) Could you provide one? > Sorry for being long winded, but my system administrator is a > real hard ass, every time I see myself in the mirror, he reminds > me of that. Well, I hope he won't be too dissatisfied, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri May 8 00:01:42 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 7 May 2009 18:01:42 -0400 Subject: [M3devel] XML? Message-ID: <20090507220142.GA32564@topoi.pooq.com> Is there a standard library for Modula 3 that reads and writes XML files? With or without DTD definitions? -- hendrik From mika at async.caltech.edu Fri May 8 00:53:53 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 07 May 2009 15:53:53 -0700 Subject: [M3devel] XML? In-Reply-To: Your message of "Thu, 07 May 2009 18:01:42 EDT." <20090507220142.GA32564@topoi.pooq.com> Message-ID: <200905072253.n47Mrrmu059675@camembert.async.caltech.edu> Hendrik, I use the following nasty hack to read XML (only): http://www.async.caltech.edu/~mika/xmlparse.tgz cit_util is probably compatible with the one inside caltech_parser in the CM3 dist. Not sure if it uses anything beyond the Debug interface from there. Mika hendrik at topoi.pooq.com writes: >Is there a standard library for Modula 3 that reads and writes XML >files? With or without DTD definitions? > >-- hendrik From dabenavidesd at yahoo.es Fri May 8 02:02:41 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 7 May 2009 17:02:41 -0700 (PDT) Subject: [M3devel] XML? In-Reply-To: <20090507220142.GA32564@topoi.pooq.com> Message-ID: <367599.3562.qm@web24708.mail.ird.yahoo.com> Hi: You can take a? look of the originally pm3 SGML parser that could work for your need: cm3/m3-libs/sgml see on http://opencm3.net/doc/help/gen_html/sgml/INDEX.html It needs Deep copy library: cm3/m3-libs/deepcopy for building see on http://opencm3.net/doc/help/gen_html/deepcopy/INDEX.html A shorter help of parser from m3doc http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/sgml/src/index.html Hope that helps --- El jue, 7/5/09, hendrik at topoi.pooq.com escribi?: De: hendrik at topoi.pooq.com Asunto: [M3devel] XML? Para: m3devel at elegosoft.com Fecha: jueves, 7 mayo, 2009 5:01 Is there a standard library for Modula 3 that reads and writes XML files? With or without DTD definitions? -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri May 8 04:31:35 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 7 May 2009 19:31:35 -0700 Subject: [M3devel] XML? In-Reply-To: <367599.3562.qm@web24708.mail.ird.yahoo.com> References: <367599.3562.qm@web24708.mail.ird.yahoo.com> Message-ID: <5BEB3EED-7B84-4598-8984-19685D84ABB2@hotmail.com> We should probably wrap up something like expat.. - Jay (phone) On May 7, 2009, at 5:02 PM, "Daniel Alejandro Benavides D." wrote: > Hi: > You can take a look of the originally pm3 SGML parser that could > work for your need: cm3/m3-libs/sgml see on http://opencm3.net/doc/help/gen_html/sgml/INDEX.html > > It needs Deep copy library: cm3/m3-libs/deepcopy for building see on http://opencm3.net/doc/help/gen_html/deepcopy/INDEX.html > > A shorter help of parser from m3doc http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/sgml/src/index.html > > Hope that helps > > --- El jue, 7/5/09, hendrik at topoi.pooq.com > escribi?: > De: hendrik at topoi.pooq.com > Asunto: [M3devel] XML? > Para: m3devel at elegosoft.com > Fecha: jueves, 7 mayo, 2009 5:01 > > Is there a standard library for Modula 3 that reads and writes > XML > files? With or without DTD definitions? > > -- hendrik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Fri May 8 04:46:39 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 7 May 2009 22:46:39 -0400 Subject: [M3devel] XML? In-Reply-To: <200905072253.n47Mrrmu059675@camembert.async.caltech.edu> References: <20090507220142.GA32564@topoi.pooq.com> <200905072253.n47Mrrmu059675@camembert.async.caltech.edu> Message-ID: <20090508024638.GB418@topoi.pooq.com> On Thu, May 07, 2009 at 03:53:53PM -0700, Mika Nystrom wrote: > Hendrik, > > I use the following nasty hack to read XML (only): > > http://www.async.caltech.edu/~mika/xmlparse.tgz > > cit_util is probably compatible with the one inside caltech_parser > in the CM3 dist. Not sure if it uses anything beyond the Debug > interface from there. > > Mika This is a M3 wrapper to use an existing C library, right? -- hendrik From hendrik at topoi.pooq.com Fri May 8 04:58:25 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 7 May 2009 22:58:25 -0400 Subject: [M3devel] XML? In-Reply-To: <367599.3562.qm@web24708.mail.ird.yahoo.com> References: <20090507220142.GA32564@topoi.pooq.com> <367599.3562.qm@web24708.mail.ird.yahoo.com> Message-ID: <20090508025825.GC418@topoi.pooq.com> On Thu, May 07, 2009 at 05:02:41PM -0700, Daniel Alejandro Benavides D. wrote: > Hi: > You can take a? look of the originally pm3 SGML parser that could work > for your need: cm3/m3-libs/sgml see on > http://opencm3.net/doc/help/gen_html/sgml/INDEX.html This one does SGML, which XML is compatible with, but not the same as. There was a big effort to make sure that SGML and XML had a very viable intersection (that's what they used to write the standard). But SGML has a lot of conventions whereby you can leave out tags. XML does not. I gather a lot of this might have to be handled by the user's Application object class. Will look further. Much of the stuff I have to process today are .fodt files, which are quite strictly conforming to the spec, and other ad-hoc XMLish files, which don't even have a DTD. > > It needs Deep copy library: cm3/m3-libs/deepcopy for building see on > http://opencm3.net/doc/help/gen_html/deepcopy/INDEX.html > > A shorter help of parser from m3doc > http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/sgml/src/index.html This one actually seems to be designed for XML as well as SGML. It looks as if the SGML part of it makes it more complicated than would be necessary if it just did XML. In any case, the XML standard specifies both what a validating XML processor has to do, and what a nonvalidating processor has to do. So there is some wiggle room in the spec here. -- hendrik > > Hope that helps > > --- El jue, 7/5/09, hendrik at topoi.pooq.com escribi?: > De: hendrik at topoi.pooq.com > Asunto: [M3devel] XML? > Para: m3devel at elegosoft.com > Fecha: jueves, 7 mayo, 2009 5:01 > > Is there a standard library for Modula 3 that reads and writes XML > files? With or without DTD definitions? > > -- hendrik > > > > > From mika at async.caltech.edu Fri May 8 05:22:38 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 07 May 2009 20:22:38 -0700 Subject: [M3devel] XML? In-Reply-To: Your message of "Thu, 07 May 2009 22:46:39 EDT." <20090508024638.GB418@topoi.pooq.com> Message-ID: <200905080322.n483MdBQ069069@camembert.async.caltech.edu> Yes, and not a very capable one, sorry. Works for what I was doing... shouldn't be too hard to extend. Mika hendrik at topoi.pooq.com writes: >On Thu, May 07, 2009 at 03:53:53PM -0700, Mika Nystrom wrote: >> Hendrik, >> >> I use the following nasty hack to read XML (only): >> >> http://www.async.caltech.edu/~mika/xmlparse.tgz >> >> cit_util is probably compatible with the one inside caltech_parser >> in the CM3 dist. Not sure if it uses anything beyond the Debug >> interface from there. >> >> Mika > >This is a M3 wrapper to use an existing C library, right? > >-- hendrik From dragisha at m3w.org Fri May 8 13:50:06 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 08 May 2009 13:50:06 +0200 Subject: [M3devel] ***SPAM*** Re: XML? In-Reply-To: <5BEB3EED-7B84-4598-8984-19685D84ABB2@hotmail.com> References: <367599.3562.qm@web24708.mail.ird.yahoo.com> <5BEB3EED-7B84-4598-8984-19685D84ABB2@hotmail.com> Message-ID: <1241783406.15444.3.camel@faramir.m3w.org> I have it wrapped, but it looks like there is strong resistance in "m3 movement" for including anything that can not work on, or assume some C porting work for specific m3 platform. On Thu, 2009-05-07 at 19:31 -0700, jay.krell at cornell.edu wrote: > We should probably wrap up something like expat.. > > - Jay (phone) > > On May 7, 2009, at 5:02 PM, "Daniel Alejandro Benavides D." > wrote: > > > > > Hi: > > You can take a look of the originally pm3 SGML parser that could > > work for your need: cm3/m3-libs/sgml see on > > http://opencm3.net/doc/help/gen_html/sgml/INDEX.html > > > > It needs Deep copy library: cm3/m3-libs/deepcopy for building see on > > http://opencm3.net/doc/help/gen_html/deepcopy/INDEX.html > > > > A shorter help of parser from m3doc > > http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/sgml/src/index.html > > > > Hope that helps > > > > --- El jue, 7/5/09, hendrik at topoi.pooq.com > > escribi?: > > De: hendrik at topoi.pooq.com > > Asunto: [M3devel] XML? > > Para: m3devel at elegosoft.com > > Fecha: jueves, 7 mayo, 2009 5:01 > > > > Is there a standard library for Modula 3 that reads and writes > > XML > > files? With or without DTD definitions? > > > > -- hendrik > > > > > > -- Dragi?a Duri? From dragisha at m3w.org Fri May 8 13:54:25 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 08 May 2009 13:54:25 +0200 Subject: [M3devel] release engineering etc Message-ID: <1241783665.15444.8.camel@faramir.m3w.org> expat (an UTF8 before) makes me think we need to allow some flexibility in development process - se we can allow some packages not being available on all platforms - for some period of time while we find somebody to tune it to platforms with initial issues. Somehow we must track packages that need more work on specific platform (probably already done throgh tinderbox) and use that information to keep loose ends under control. Some packages will then be tagged beta or something while work is in progress. -- Dragi?a Duri? From hendrik at topoi.pooq.com Fri May 8 15:46:04 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 8 May 2009 09:46:04 -0400 Subject: [M3devel] ***SPAM*** Re: XML? In-Reply-To: <1241783406.15444.3.camel@faramir.m3w.org> References: <367599.3562.qm@web24708.mail.ird.yahoo.com> <5BEB3EED-7B84-4598-8984-19685D84ABB2@hotmail.com> <1241783406.15444.3.camel@faramir.m3w.org> Message-ID: <20090508134604.GA1190@topoi.pooq.com> On Fri, May 08, 2009 at 01:50:06PM +0200, Dragi?a Duri? wrote: > I have it wrapped, but it looks like there is strong resistance in "m3 > movement" for including anything that can not work on, or assume some C > porting work for specific m3 platform. There is, and it's probably because M3 arose from a strong tradition of self-sufficiency. Way back then, people were designing systems languages -- languages that could be used to implement an entire system, including its own run-time system. It means that M3 is a viable language for bootstrapping onto a new machine. Except, as far as I know, that it still relies on gcc's back end (written in C) for its code generation, and which causes license incompatibilities with the SRC license. Didn't M3 once generate C code, as Eiffel still does? And did it generate anything else before those C-generating days? What was M3 originally written in? MESA? -- hendrik > > On Thu, 2009-05-07 at 19:31 -0700, jay.krell at cornell.edu wrote: > > We should probably wrap up something like expat.. > > > > - Jay (phone) > > > > On May 7, 2009, at 5:02 PM, "Daniel Alejandro Benavides D." > > wrote: > > > > > > > > > Hi: > > > You can take a look of the originally pm3 SGML parser that could > > > work for your need: cm3/m3-libs/sgml see on > > > http://opencm3.net/doc/help/gen_html/sgml/INDEX.html > > > > > > It needs Deep copy library: cm3/m3-libs/deepcopy for building see on > > > http://opencm3.net/doc/help/gen_html/deepcopy/INDEX.html > > > > > > A shorter help of parser from m3doc > > > http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/sgml/src/index.html > > > > > > Hope that helps > > > > > > --- El jue, 7/5/09, hendrik at topoi.pooq.com > > > escribi?: > > > De: hendrik at topoi.pooq.com > > > Asunto: [M3devel] XML? > > > Para: m3devel at elegosoft.com > > > Fecha: jueves, 7 mayo, 2009 5:01 > > > > > > Is there a standard library for Modula 3 that reads and writes > > > XML > > > files? With or without DTD definitions? > > > > > > -- hendrik > > > > > > > > > > -- > Dragi?a Duri? > From wagner at elegosoft.com Fri May 8 16:03:10 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 08 May 2009 16:03:10 +0200 Subject: [M3devel] XML? In-Reply-To: <1241783406.15444.3.camel@faramir.m3w.org> References: <367599.3562.qm@web24708.mail.ird.yahoo.com> <5BEB3EED-7B84-4598-8984-19685D84ABB2@hotmail.com> <1241783406.15444.3.camel@faramir.m3w.org> Message-ID: <20090508160310.0zq70ex1nossgwkg@mail.elegosoft.com> Quoting Dragi?a Duri? : > I have it wrapped, but it looks like there is strong resistance in "m3 > movement" for including anything that can not work on, or assume some C > porting work for specific m3 platform. There are no objections from my side to add expat interfaces. We should probably add expat to the external SYSTEM_LIBRARIES then. Why not just check-in the package and see where we can get it to compile? It's probably not relevant for the current release though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Fri May 8 20:22:12 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 08 May 2009 11:22:12 -0700 Subject: [M3devel] ***SPAM*** Re: XML? In-Reply-To: Your message of "Fri, 08 May 2009 09:46:04 EDT." <20090508134604.GA1190@topoi.pooq.com> Message-ID: <200905081822.n48IMCxl002447@camembert.async.caltech.edu> Here's my understanding, and it may be incorrect in places: I think there were originally two separate implementations of Modula-3, one from DEC and one from Olivetti (ORL/Palo Alto). I think they both generated C code. The DEC one later became a native compiler, both with a native back end and by modifying gcc. (So it's not accurate to say that M3 relies on gcc---Jay's work on Windows doesn't use gcc at all.) That's what you get if you run "cm3". The Olivetti one moved with Mick Jordan to PARC when ORL closed, and most of it is still in the tree under "m3tk". Look in m3tk/src/target. There seem to be back ends for C code on i386 (running System V), mips, sparc, sun3, and vax (running BSD Unix). There's a very brief man page for a program called "m3cbe". The M3 system has all kinds of hooks for different types of machines, e.g., pre-OSX Mac and VMS. Not sure to what extent it ever worked on those. There is also a back end for C-code generation on the Caltech Mosaic-C multicomputer and probably others I'm unaware of. I think the problem with pulling in things like expat isn't that "people use it" but that there's a temptation to use it for building Modula-3 itself. That's the sort of thing that needs to be guarded against, I think. I would suggest putting things that create outside dependencies in some separate, clearly marked subtree, so that they can't sneak into the base system. Mika hendrik at topoi.pooq.com writes: >On Fri, May 08, 2009 at 01:50:06PM +0200, Dragi??a Duri?? wrote: >> I have it wrapped, but it looks like there is strong resistance in "m3 >> movement" for including anything that can not work on, or assume some C >> porting work for specific m3 platform. > >There is, and it's probably because M3 arose from a strong tradition of >self-sufficiency. Way back then, people were designing systems >languages -- languages that could be used to implement an entire system, >including its own run-time system. It means that M3 is a viable >language for bootstrapping onto a new machine. > >Except, as far as I know, that it still relies on gcc's back end >(written in C) for its code generation, and which causes license >incompatibilities with the SRC license. > >Didn't M3 once generate C code, as Eiffel still does? And did it >generate anything else before those C-generating days? > >What was M3 originally written in? MESA? > >-- hendrik > >> >> On Thu, 2009-05-07 at 19:31 -0700, jay.krell at cornell.edu wrote: >> > We should probably wrap up something like expat.. >> > >> > - Jay (phone) >> > >> > On May 7, 2009, at 5:02 PM, "Daniel Alejandro Benavides D." >> > wrote: >> > >> > >> > >> > > Hi: >> > > You can take a look of the originally pm3 SGML parser that could >> > > work for your need: cm3/m3-libs/sgml see on >> > > http://opencm3.net/doc/help/gen_html/sgml/INDEX.html >> > > >> > > It needs Deep copy library: cm3/m3-libs/deepcopy for building see on >> > > http://opencm3.net/doc/help/gen_html/deepcopy/INDEX.html >> > > >> > > A shorter help of parser from m3doc >> > > http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/sgml/src/index.html >> > > >> > > Hope that helps >> > > >> > > --- El jue, 7/5/09, hendrik at topoi.pooq.com >> > > escribi??: >> > > De: hendrik at topoi.pooq.com >> > > Asunto: [M3devel] XML? >> > > Para: m3devel at elegosoft.com >> > > Fecha: jueves, 7 mayo, 2009 5:01 >> > > >> > > Is there a standard library for Modula 3 that reads and writes >> > > XML >> > > files? With or without DTD definitions? >> > > >> > > -- hendrik >> > > >> > > >> > > >> -- >> Dragi??a Duri?? >> From hendrik at topoi.pooq.com Sat May 9 04:15:25 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 8 May 2009 22:15:25 -0400 Subject: [M3devel] release engineering etc In-Reply-To: <1241783665.15444.8.camel@faramir.m3w.org> References: <1241783665.15444.8.camel@faramir.m3w.org> Message-ID: <20090509021525.GB2642@topoi.pooq.com> On Fri, May 08, 2009 at 01:54:25PM +0200, Dragi?a Duri? wrote: > expat (an UTF8 before) makes me think we need to allow some flexibility > in development process - se we can allow some packages not being > available on all platforms - for some period of time while we find > somebody to tune it to platforms with initial issues. Somehow we must > track packages that need more work on specific platform (probably > already done throgh tinderbox) and use that information to keep loose > ends under control. > Some packages will then be tagged beta or something while work is in > progress. I browsed the source ttree for expat online earlier today, and there seem to be a lot of directories withougt any current files. Most of these are directories that seem to be for specific platforms, leaving me to wonder if they have been abandoned, or whether the developers have succeeded in unifying them, so they don't need system specific code any more. There may turn out to be fewer variants than you think. -- hendrik From eiserlohpp at yahoo.com Sat May 9 05:44:20 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 8 May 2009 20:44:20 -0700 (PDT) Subject: [M3devel] Release engineering Message-ID: <172161.40937.qm@web56807.mail.re3.yahoo.com> Hi Jay and Everyone, > from: Jay jay.krell at cornell.edu > date: Wed May 6 23:40:24 CEST 2009 >apt-get install cm3 would be nice, agreed. >You have to be an official Debian developer though, right? In order to submit a debian package for inclusion into the Debian distribution. Even so, one can become a new maintainer and study under a mentor. Regardless of that, we can create our own packages and put them in our own repository, until one of us does become involved in the debian, ubuntu, linux-mint, ..., etc distributions. I myself, have built a number of debian packages, these were intended for local operations, and never sent out of the work area. Actually, the *.deb files were burnt to CD, and installed on a target machine. >> o Allow cm3 to be installed into /usr, instead of /usr/local. > >Doesn't that already work? >I don't do it, but it should work. Okay, I will attempt to ship into a path like /usr/opt/cm3 just to exercise that ablility. After testing to verify the installation, I will delete it. Then I will attempt to install into temporary directory, followed by copying into a final destination /usr/opt/cm3, and test. > Look at make-dist.py? And the others? Okay, when I will before attempting the above. >> o Documentation: Write manual page for cm3. >Yep. Okay I did this. It can be downloaded from the link below. http://www.eiserloh.org/~peter/modula3/ >> o Allow easy cross compiling. > > We do already, sort of, and for some definition of "easy". > In particular, cross /compilation/ of Modula-3 is easy. > There is some C code and there is some linking. > Cross building involves > cross compile the Modula-3, to assembly. > tar it up > copy it over to target system > extract > make -- which compiles C and links > > Doing a "full" cross build should just be a matter of > either altering $PATH or the config file to find a different > C compiler and linker. > You also need a cm3cg per target. > My config files (now the config files) do probe around > in "reasonable" way (a little too haphazard really) > so that you can have multiple cm3cgs, don't have to edit $PATH > or copy files aorund. > However, another idea is to declare that the configuration > is not in fact user editable. Now you are getting the IDEA. Currently to do a cross compile the user has to change a global (system) configuration file. This would interfere with any other user on the system, and of course require super-user privileges. The important part is that it would INTERFERE with the OTHER users. (Sorry for shouting). Okay, what I would like to see, is something like # apt-get install cm3-compiler-ppc-darwin # apt-get install cm3-compiler-amd64-darwin # apt-get install cm3-compiler-amd64-freebsd # apt-get install cm3-compiler-sparc64-solaris # apt-get install cm3-compiler-nt386 # exit $ ls /usr/cm3/bin cm3 cm3cg-AMD64_DARWIN cm3cg-AMD64_FREEBSD cm3cg-AMD64_LINUX cm3cg-NT386 cm3cg-PPC_DARWIN cm3cg-SPARC64_SOLARIS $ls /usr/cm3/etc cm3.cfg AMD64_DARWIN AMD64_FREEBSD AMD64_LINUX NT386 PPC_DARWIN SPARC64_SOLARIS Now cm3.cfg contains one line Include("AMD64_LINUX"); Because this is the architecture of the host machine. > That's how I do things already, long time now. Yes, I like the idea of the main configuration simply including the real one. It is conceptually easier to understand. When I saw that about a year ago, I really liked it, thanks. I just took that idea one step further. The other TARGET files in ${CM3PATH}/etc, are designed for cross compiling, they use the linker on the host computer. cm3 --use-config=NT386 would invoke assembler: i586-mingw32msvc-as and linker: i586-mingw32msvc-ld. Then any of the many users on the machine may attempt a cross compile without interfering with any other user. By using either a command line argument, or the environment variable M3CONFIG, the compiler will be informed which target is requested. NOTE: I think the cm3 frontend is currently target independent, after parsing the source code, it calls a backend (eg, cm3cg-PPC_DARWIN) to generate the object code. For example with M3CONFIG $ M3CONFIG=PPC_DARWIN cm3 -build Alternatively using an argument (here I invent --use-config, it looks cleaner). $ cm3 --use-config=PPC_DARWIN -build Lastly, if I (a normal user) were experimenting with different config files cm3 --use-config=/home/peter/src/experiment/mysuper.cfg -build > Can you help? Step one (the easy one) was to write a manual page for cm3. Please comment, so that we can flush out any problems and add anything. Maybe document the runtime @m3options. Again http://www.eiserloh.org/~peter/modula3/ BTW: I got my example m3hexdump.m3 program to work, but only if I don't specify the desired program name, so the resulting executable is "../AMD64_LINUX/prog". peter at black:~/modula-3/m3hexdump/src $ cm3 -o M3Hexdump --- building in ../AMD64_LINUX --- -> linking M3Hexdump Fatal Error: incomplete program missing "Main" module Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From eiserlohpp at yahoo.com Sat May 9 07:07:02 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 8 May 2009 22:07:02 -0700 (PDT) Subject: [M3devel] Release engineering Message-ID: <527913.7261.qm@web56808.mail.re3.yahoo.com> Hi Olaf, > That's quite a long wish list you've got there, and as it is not > Christmas, I'm afraid that we won't be able to fulfill all of them :-) True, version 6.0 is only a couple years away. If we start planning things now, then they have a chance of happening. > That's exactly because the default installation of CM3 is /usr/local ;-) > We've never provided system-specific package formats until now. > Of course system packages should install into their preferred locations. Yes! A distribution is not supposed to install anything into /usr/local. This is for the administrator to installing from a source package, and manually installing them. Like what we have done. Download the a min install, and a source tarball, or do a CVS checkout. Build and ship. These days we want to play with the distribution's mechanisms for installing software. >> o Allow installation to temporary root during package building. > > Jay commented on it, but I'm not sure if that was what you meant. During the building of a debian package (probably similar in an RPM) all the binary executables and libraries are built, but instead of installing them into their final destination (which is on the host system), they are installed into a temporary tree Some source packages can use their own makefile install target specifying a DEST_DIR. We would probably want to do something like For example, for package cm3-compiler_5.8 rules would contain pkg_cm3=/home/peter/src/modula3/cm3/src-all/debian/tmp-cm3/ bin_dir=${pkg_cm3}/usr/cm3/bin etc_dir=${pkg_cm3}/usr/cm3/etc lib_dir=${pkg_cm3}/usr/cm3/lib pkgs_dir=${pkg_cm3}/usr/cm3/pkg mkdir -p ${bin_dir} mkdir -p ${lib_dir} mkdir -p ${pkg_cm3}/usr/cm3/pkg install m3-sys/cm3/${TARGET}/cm3 ${bin-dir} install m3-sys/m3cc/${TARGET}/m3cc ${bin_dir} A number of administrative files are also installed into here such as "DEBIAN/control", and "DEBIAN/confiles". Once the directory tree has been built, then it is archived up. Debian's *.deb file use "ar" for this. Then when a package is installed by the super-user, all files are installed to their destinations (except configuration files, they get another stage). >> o Documentation: Write manual page for cm3. > >I can do that. Ah.., I already did. Just cm3, still need to write modula3.man, m3makefile.man, and m3overrides.man. It would be bad form to suggest all sorts of things, and then not actually do anything myself. http://www.eiserloh.org/~peter/modula3/#mydocs > I won't be able to provide manual pages for all M3 programs. Didn't expect that for all programs, but then we aren't talking about installing all those programs in the m3 repository. Sure zeus, and obliq and so forth are cool, but they are not the Modula-3 compiler, nor libm3. Those would be in packages such as "zeus", and "obliq". >I'm not against such changes, but they won't make it into this release, >and somebody will have to volunteer to do them. Again, I agree that a release of 5.8 should be soon. And soon, means no significant changes. BTW: I imported the CVS repository as a GIT repository, I intend to make this visible externally, but in the mean time it is in a private directory. I looked at the cm3-releases branch, wow it has been a long time since the last release, which according to the repository, 5.1 was released (2001-01-24). Cool you got gcc-4.3, after 5.8 is released, are we going to update the gcc backend to 4.3? What version is currently in the backend. BTW(2): When I built the cm3.man manual page, I saw the -config option which simply wrote the version number, instead of the configuration info. Could it at least print the TARGET architecture? > Well, I hope he won't be too dissatisfied, Well, I (<-<-) he does understand exactly where I am, and what I am attempting. I have been playing on the extreme periphery of M3 development for the past 14 or 15 years, when I first heard of it. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Sat May 9 13:03:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 09 May 2009 13:03:55 +0200 Subject: [M3devel] Release engineering In-Reply-To: <527913.7261.qm@web56808.mail.re3.yahoo.com> References: <527913.7261.qm@web56808.mail.re3.yahoo.com> Message-ID: <20090509130355.3la6r1ds00sgcoss@mail.elegosoft.com> Quoting Peter Eiserloh : >>>> o Documentation: Write manual page for cm3. >> >> I can do that. > > Ah.., I already did. Just cm3, still need to write > modula3.man, m3makefile.man, and m3overrides.man. > > It would be bad form to suggest all sorts of things, and then > not actually do anything myself. > > http://www.eiserloh.org/~peter/modula3/#mydocs I just added that to the repository. > Again, I agree that a release of 5.8 should be soon. And soon, > means no significant changes. > BTW: I imported the CVS repository as a GIT repository, > I intend to make this visible externally, but in the > mean time it is in a private directory. I looked at the > cm3-releases branch, wow it has been a long time since > the last release, which according to the repository, > 5.1 was released (2001-01-24). That's just the branch where the old releases from Critical Mass were imported. IIRC, the last CM3 release was around 2006 :-) > Cool you got gcc-4.3, after 5.8 is released, are we going > to update the gcc backend to 4.3? What version is currently > in the backend. > > BTW(2): When I built the cm3.man manual page, I saw the > -config option which simply wrote the version number, instead > of the configuration info. Could it at least print the > TARGET architecture? Should be no problem. >> Well, I hope he won't be too dissatisfied, > Well, I (<-<-) he does understand exactly where I am, > and what I am attempting. > > I have been playing on the extreme periphery of M3 development > for the past 14 or 15 years, when I first heard of it. Then this might be a good time to become more involved? :-)) Any help is welcome. I've been thinking today about using the .M3SHIP files for installation purposes. Curently, the paths they contain are all resolved like this: make_dir("/usr/local/cm3/pkg/test/FreeBSD4") install_file(".M3EXPORTS", "/usr/local/cm3/pkg/test/FreeBSD4", "0644") install_file(".M3WEB", "/usr/local/cm3/pkg/test/FreeBSD4", "0644") make_dir("/usr/local/cm3/pkg/test/src") install_file("../src/Test.m3", "/usr/local/cm3/pkg/test/src", "0644") install_file("Test", "/usr/local/cm3/pkg/test/FreeBSD4", "0644") If we use the variables defined in the cm3 config file, we can defer path resolution to installation time: make_dir(PKG_INSTALL & "/test/FreeBSD4") install_file(".M3EXPORTS", PKG_INSTALL & "/test/FreeBSD4", "0644") install_file(".M3WEB", PKG_INSTALL & "/test/FreeBSD4", "0644") make_dir(PKG_INSTALL & "/test/src") install_file("../src/Test.m3", PKG_INSTALL & "/test/src", "0644") install_file("Test", PKG_INSTALL & "/test/FreeBSD4", "0644") Not really a good example, as its just a test package; others could also use BIN_INSTALL, LIB_INSTALL, MAN_INSTALL, DOC_INSTALL, HTML_INSTALL etc. We could even add ETC_INSTALL if you like ;-) Then we could just run cm3 -ship for any package installation, and perhaps even provide system-specific overrides for the install routines in quake if needed. Installation packages could contain a workspace with precompiled packages, and actual package installation is done on the target system by cm3 itself. I haven't really thought it through nor tested it though. It looks as if it wouldn't be too difficult to implement. Comments welcome, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat May 9 21:08:27 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 9 May 2009 19:08:27 +0000 Subject: [M3devel] Release engineering In-Reply-To: <20090509130355.3la6r1ds00sgcoss@mail.elegosoft.com> References: <527913.7261.qm@web56808.mail.re3.yahoo.com> <20090509130355.3la6r1ds00sgcoss@mail.elegosoft.com> Message-ID: > From: wagner > I've been thinking today about using the .M3SHIP files for > installation purposes. Curently, the paths they contain are all > resolved like this: > > install_file(".M3EXPORTS", "/usr/local/cm3/pkg/test/FreeBSD4", "0644") > > If we use the variables defined in the cm3 config file, we can > defer path resolution to installation time: > > install_file(".M3EXPORTS", PKG_INSTALL & "/test/FreeBSD4", "0644") I think: This is an ok idea. Like if you want merge cminstall functionality into cm3. I think the SRC releases pretty much worked this way, with the advantage that cm3 was implemented in C and could be built at install time. Heck, cm3 -ship could try to do diskspace checking. :) But I don't think this solves a problem anyone has yet brought up. The two solutions are, to the problem I think brought up: - link at ship time -- which you'd combine with this idea - use $ORIGIN I think most systems support that now. One exception is NetBSD 4.0. 5.0 supports it. MacOSX has something different. They added stuff in 10.5 and I think 10.4, and I think the 10.4 feature suffices. I'd still like to switch to hard links here so that $ORIGIN use is just $ORIGIN/../lib for all shared objects and executables, and "hidden" executables will ship to (hard link to) lib. $ORIGIN/../lib seemed to already work on Linux but that was surprising and it didn't work on other systems (I think Solaris?) Ok, hm, I tell you what this can help though. It can help bootstrapping. It can help "large" distributing bootstrap archives. The advantage of distributing bootstrap archives is that "FreeBSD" can resolve at install time to 4.x, 5.x, 6.x, 7.x, whatever. There'd still be, like, my Makefile for building cm3 on the target. But then cm3 can ship everything else into place. This, like, saves me from writing Python to convert the .m3ship files into a makefile or sh or such. Also not difficult. Normally I just bootstrap cm3 and then build everything else on the target. However for distribution purposes, for building something that is a hybrid between "precompiled binary package for install speed" and "source that is more portable to various systems"..this is not a bad idea. There's still the sticking point as to when cm3cg is built and/or if the user has to wait for it to be built. You'd end up being able to run all the Modula-3 stuff, but can't build anything until you first build cm3cg. Maybe not a terrible idea. It doesn't take TOO long except on cygwin or old machines. Maybe we can use the system's gmp/mpfr if they exist, that saves a lot. This makes me wonder also if "distribution builders" should do cross builds targeting older releases, like FreeBSD 5.x, Linux whatever, etc. It's a bit of a pain though. And only viable where cc/ld are open source, and even then probably only where they are both GNU (even if Apple and Sun are also open source). - Jay From jay.krell at cornell.edu Sat May 9 21:17:49 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 9 May 2009 19:17:49 +0000 Subject: [M3devel] cross build file system layout? Message-ID: [unnecessarily long-winded sorry] We should consider where files should be placed regarding cross builds? installroot/bin/host/target/cm3cg installroot/bin/host/config/target or installroot/bin/host/config/target.cfg or installroot/bin/host/target.cfg or installroot/bin/etc/target.cfg or installroot/etc/cm3/target.cfg ? installroot/bin/host/cm3 installroot/bin/cm3 is a little sh? (and also cm3.cmd) installroot/lib/target/libfoo.so installroot/pkg unchanged, already contains target ? or host is implied in installroot? installroot/bin/target/cm3cg installroot/bin//config/target (file) installroot/bin/host/cm3 installroot/bin/cm3 is a little sh? (and also cm3.cmd) installroot/lib/target/libfoo.so installroot/pkg unchanged, already contains target ? If you don't imply host in installroot, there could be like one large "repository" (file system tree) that package building and install merely subsets according to what hosts/targets are desired. Maybe that's pointless. Or, it doesn't require this layout anyway. My config file roughly or the intent is, probe first the source tree, then the install tree. In the source tree there is already precedent for where things are: sourceroot/m3-sys/m3cc/host/cm3cg (native) sourceroot/m3-sys/m3cc/host-target/cm3cg sourceroot/m3-sys/cminstall/src/config-no-install/target sourceroot/m3-sys/cminstall/src/config/target I kind of favor slashes for separators. But I guess dashes or underscores are ok. Slashes offer - same overall length path - possible increased portability to systems with limited length filenames, e.g. MS-DOS I guess the reason to get some consensus is so that cm3 target can work. So the probing can move from my config file to cm3? You could maybe do -DTARGET=target. There might be a problem where -D is processed too late. We could move that earlier, at least partially. My source tree use could be implemented by me just replacing all the "installed" files with ones that include over to my source tree. - Jay From jay.krell at cornell.edu Sat May 9 21:23:53 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 9 May 2009 19:23:53 +0000 Subject: [M3devel] Release engineering In-Reply-To: <172161.40937.qm@web56807.mail.re3.yahoo.com> References: <172161.40937.qm@web56807.mail.re3.yahoo.com> Message-ID: > NOTE: I think the cm3 frontend is currently target independent, Correct. It knows about all the targets. word size, endian, alignment, jmpbuf size, whether or not there is a stack walker It does layout all the types/variables. Maybe not as high level as you'd expect. The NT386 backend is integrated into the front/middle end. So we have: NT386: run cm3 get a bunch of .obj files just one process goes all the way from out of date sources to .obj files It is quite fast. And the codegen is somewhat optimized even. everything else run cm3 and then for every out of date source file output an intermediate file run cm3cg read intermediate file write assembly run assembler read assembly write .o file Someday maybe we can port the integrated backend to more targets. - Jay From eiserlohpp at yahoo.com Sun May 10 02:13:57 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 9 May 2009 17:13:57 -0700 (PDT) Subject: [M3devel] release engineering etc Message-ID: <166673.26496.qm@web56806.mail.re3.yahoo.com> Yes, when building the src-all source tree on a Macintosh (OSX-10.5.x), I have to delete the entry for the Postgress database. > expat (an UTF8 before) makes me think we need to allow some flexibility > in development process - se we can allow some packages not being > available on all platforms - for some period of time while we find > somebody to tune it to platforms with initial issues. Somehow we must > track packages that need more work on specific platform (probably > already done throgh tinderbox) and use that information to keep loose > ends under control. > Some packages will then be tagged beta or something while work is in > progress. > -- > Dragi?a Duri? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sun May 10 23:32:25 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 10 May 2009 21:32:25 +0000 Subject: [M3devel] how to find dependent .so files? In-Reply-To: <200904280900.27606.vapier@gentoo.org> References: <200904280900.27606.vapier@gentoo.org> Message-ID: Any dissent on changing the symlinks to hardlinks? I plan to try this pretty soon. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: vapier at gentoo.org; m3devel at elegosoft.com > Subject: RE: [M3devel] how to find dependent .so files? > Date: Tue, 28 Apr 2009 13:15:06 +0000 > > > If you take one of my suggestions, then yes you can do that for .sos. > But $ORIGIN/../lib is one generic perhaps inefficient runpath for .sos and executables, and hypothetically also for non-public shipped executables (with my suggestion that they go to lib, if they don't already), that's why. > > > The next step is just to smush lib and bin together, as is done on NT386. > Probably people won't like that, keep files out of $PATH. > > > I don't believe $ORIGIN works asis. > if /cm3/lib/libfoo.so symlinks to /cm3/pkg/foo/target/libfoo.so > then $ORIGIN is /cm3/pkg/foo/target, not /cm3/lib. > I'd like to be wrong here but I don't think I am. > > > So reversing the symlinks or making them hardlinks is ok? > > > - Jay > > > ---------------------------------------- >> From: vapier at gentoo.org >> To: m3devel at elegosoft.com >> Date: Tue, 28 Apr 2009 09:00:26 -0400 >> CC: jay.krell at cornell.edu >> Subject: Re: [M3devel] how to find dependent .so files? >> >> On Tuesday 28 April 2009 04:03:13 Jay wrote: >>> Normally we have: >>> >>> /usr/local/cm3/bin/someexe >>> /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so >>> /usr/local/cm3/lib/libbar.so symlink to ../pkg/bar/target/libbar.so >>> >>> Linking from someexe to $ORIGIN/../lib works, ok. >>> But from libfoo to libbar requires $ORIGIN/../../../lib. >>> or $ORIGIN/../../bar/target. >> >> what's wrong with just $ORIGIN ? they're in the same directory already. >> -mike From jay.krell at cornell.edu Mon May 11 00:33:29 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 10 May 2009 22:33:29 +0000 Subject: [M3devel] I386_DARWIN GetPC, rep prefix? Message-ID: Tony, to get RTSignalC.c to compile on Darwin (not MacOSX) 8.0.1 (aka 10.4). jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ uname -a Darwin jdar1.local 8.0.1 Darwin Kernel Version 8.0.1: Fri Apr 29 12:18:40 PDT 2005; root:xnu-792.obj /RELEASE_I386 x86 i386 jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ Probably that's a not very interesting target, but I don't yet have "real" x86/AMD64/Apple/Darwin hardware (just PPC/ARM). I had to: =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/POSIX/RTSignalC.c,v retrieving revision 1.11 diff -r1.11 RTSignalC.c 71c71 < pc = Context->uc_mcontext->ss.eip; --- > pc = Context->uc_mcontext->sc.sc_eip; Did you test ss.eip? And presumably sc.sc_eip doesn't work for you? Unless they have #defines for compat (on such short names..)? Maybe this changed from 10.4 to 10.5? I just want to change over the Unix/*.i3 files. I can leave my change uncommited till I get a real MacOSX>=10.5 system. I also get problems even in native builds with "rep" prefixes using the "builtin" tools (as). I'll change cm3cg to 586, or 486, or 386, whatever it takes, to workaround that. Also not commit that. Or maybe build a newer "cctools". - Jay From hosking at cs.purdue.edu Mon May 11 01:26:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 May 2009 09:26:36 +1000 Subject: [M3devel] I386_DARWIN GetPC, rep prefix? In-Reply-To: References: Message-ID: <3EB1F53C-5837-4DB4-8F1E-5D7EDC27201F@cs.purdue.edu> Hmm. Not sure I did test that. I don't have any 10.4 systems around anymore. On 11 May 2009, at 08:33, Jay wrote: > Tony, to get RTSignalC.c to compile on Darwin (not MacOSX) 8.0.1 > (aka 10.4). > > > > jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ uname -a > Darwin jdar1.local 8.0.1 Darwin Kernel Version 8.0.1: Fri Apr 29 > 12:18:40 PDT 2005; root:xnu-792.obj > /RELEASE_I386 x86 i386 > jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ > > > Probably that's a not very interesting target, but I don't yet have > "real" x86/AMD64/Apple/Darwin hardware (just PPC/ARM). > > > I had to: > > > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/POSIX/RTSignalC.c,v > retrieving revision 1.11 > diff -r1.11 RTSignalC.c > 71c71 > < pc = Context->uc_mcontext->ss.eip; > --- >> pc = Context->uc_mcontext->sc.sc_eip; > > > Did you test ss.eip? > And presumably sc.sc_eip doesn't work for you? Unless they have > #defines for compat (on such short names..)? > Maybe this changed from 10.4 to 10.5? > I just want to change over the Unix/*.i3 files. > I can leave my change uncommited till I get a real MacOSX>=10.5 > system. > > > I also get problems even in native builds with "rep" prefixes using > the "builtin" tools (as). > I'll change cm3cg to 586, or 486, or 386, whatever it takes, to > workaround that. > Also not commit that. > Or maybe build a newer "cctools". > > > - Jay From jay.krell at cornell.edu Mon May 11 02:00:40 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 11 May 2009 00:00:40 +0000 Subject: [M3devel] I386_DARWIN GetPC, rep prefix? In-Reply-To: <3EB1F53C-5837-4DB4-8F1E-5D7EDC27201F@cs.purdue.edu> References: <3EB1F53C-5837-4DB4-8F1E-5D7EDC27201F@cs.purdue.edu> Message-ID: ok. What is the story on 10.5? Your version works? My version works? - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: I386_DARWIN GetPC, rep prefix? > Date: Mon, 11 May 2009 09:26:36 +1000 > > Hmm. Not sure I did test that. I don't have any 10.4 systems around > anymore. > > On 11 May 2009, at 08:33, Jay wrote: > >> Tony, to get RTSignalC.c to compile on Darwin (not MacOSX) 8.0.1 >> (aka 10.4). >> >> >> >> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ uname -a >> Darwin jdar1.local 8.0.1 Darwin Kernel Version 8.0.1: Fri Apr 29 >> 12:18:40 PDT 2005; root:xnu-792.obj >> /RELEASE_I386 x86 i386 >> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ >> >> >> Probably that's a not very interesting target, but I don't yet have >> "real" x86/AMD64/Apple/Darwin hardware (just PPC/ARM). >> >> >> I had to: >> >> >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/POSIX/RTSignalC.c,v >> retrieving revision 1.11 >> diff -r1.11 RTSignalC.c >> 71c71 >> < pc = Context->uc_mcontext->ss.eip; >> --- >>> pc = Context->uc_mcontext->sc.sc_eip; >> >> >> Did you test ss.eip? >> And presumably sc.sc_eip doesn't work for you? Unless they have >> #defines for compat (on such short names..)? >> Maybe this changed from 10.4 to 10.5? >> I just want to change over the Unix/*.i3 files. >> I can leave my change uncommited till I get a real MacOSX>=10.5 >> system. >> >> >> I also get problems even in native builds with "rep" prefixes using >> the "builtin" tools (as). >> I'll change cm3cg to 586, or 486, or 386, whatever it takes, to >> workaround that. >> Also not commit that. >> Or maybe build a newer "cctools". >> >> >> - Jay > From hosking at cs.purdue.edu Mon May 11 02:52:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 May 2009 10:52:59 +1000 Subject: [M3devel] I386_DARWIN GetPC, rep prefix? In-Reply-To: References: <3EB1F53C-5837-4DB4-8F1E-5D7EDC27201F@cs.purdue.edu> Message-ID: <67A25A63-2C3A-4926-8068-848436BC45AE@cs.purdue.edu> This works on 10.5: pc = Context->uc_mcontext->__ss.__eip; On 11 May 2009, at 10:00, Jay wrote: > > ok. What is the story on 10.5? > Your version works? My version works? > > - Jay > > ---------------------------------------- >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: I386_DARWIN GetPC, rep prefix? >> Date: Mon, 11 May 2009 09:26:36 +1000 >> >> Hmm. Not sure I did test that. I don't have any 10.4 systems around >> anymore. >> >> On 11 May 2009, at 08:33, Jay wrote: >> >>> Tony, to get RTSignalC.c to compile on Darwin (not MacOSX) 8.0.1 >>> (aka 10.4). >>> >>> >>> >>> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ uname -a >>> Darwin jdar1.local 8.0.1 Darwin Kernel Version 8.0.1: Fri Apr 29 >>> 12:18:40 PDT 2005; root:xnu-792.obj >>> /RELEASE_I386 x86 i386 >>> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ >>> >>> >>> Probably that's a not very interesting target, but I don't yet have >>> "real" x86/AMD64/Apple/Darwin hardware (just PPC/ARM). >>> >>> >>> I had to: >>> >>> >>> =================================================================== >>> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/POSIX/ >>> RTSignalC.c,v >>> retrieving revision 1.11 >>> diff -r1.11 RTSignalC.c >>> 71c71 >>> < pc = Context->uc_mcontext->ss.eip; >>> --- >>>> pc = Context->uc_mcontext->sc.sc_eip; >>> >>> >>> Did you test ss.eip? >>> And presumably sc.sc_eip doesn't work for you? Unless they have >>> #defines for compat (on such short names..)? >>> Maybe this changed from 10.4 to 10.5? >>> I just want to change over the Unix/*.i3 files. >>> I can leave my change uncommited till I get a real MacOSX>=10.5 >>> system. >>> >>> >>> I also get problems even in native builds with "rep" prefixes using >>> the "builtin" tools (as). >>> I'll change cm3cg to 586, or 486, or 386, whatever it takes, to >>> workaround that. >>> Also not commit that. >>> Or maybe build a newer "cctools". >>> >>> >>> - Jay >> From jay.krell at cornell.edu Mon May 11 03:51:20 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 11 May 2009 01:51:20 +0000 Subject: [M3devel] I386_DARWIN GetPC, rep prefix? In-Reply-To: <67A25A63-2C3A-4926-8068-848436BC45AE@cs.purdue.edu> References: <3EB1F53C-5837-4DB4-8F1E-5D7EDC27201F@cs.purdue.edu> <67A25A63-2C3A-4926-8068-848436BC45AE@cs.purdue.edu> Message-ID: And the #if is always true on 10.5, with a default command line? Or even no matter the command line? If so, therefore I'm free to do whatever in the #else? - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 11 May 2009 10:52:59 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] I386_DARWIN GetPC, rep prefix? > > This works on 10.5: > > pc = Context->uc_mcontext->__ss.__eip; > > On 11 May 2009, at 10:00, Jay wrote: > > > > > ok. What is the story on 10.5? > > Your version works? My version works? > > > > - Jay > > > > ---------------------------------------- > >> CC: m3devel at elegosoft.com > >> From: hosking at cs.purdue.edu > >> To: jay.krell at cornell.edu > >> Subject: Re: I386_DARWIN GetPC, rep prefix? > >> Date: Mon, 11 May 2009 09:26:36 +1000 > >> > >> Hmm. Not sure I did test that. I don't have any 10.4 systems around > >> anymore. > >> > >> On 11 May 2009, at 08:33, Jay wrote: > >> > >>> Tony, to get RTSignalC.c to compile on Darwin (not MacOSX) 8.0.1 > >>> (aka 10.4). > >>> > >>> > >>> > >>> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ uname -a > >>> Darwin jdar1.local 8.0.1 Darwin Kernel Version 8.0.1: Fri Apr 29 > >>> 12:18:40 PDT 2005; root:xnu-792.obj > >>> /RELEASE_I386 x86 i386 > >>> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ > >>> > >>> > >>> Probably that's a not very interesting target, but I don't yet have > >>> "real" x86/AMD64/Apple/Darwin hardware (just PPC/ARM). > >>> > >>> > >>> I had to: > >>> > >>> > >>> =================================================================== > >>> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/POSIX/ > >>> RTSignalC.c,v > >>> retrieving revision 1.11 > >>> diff -r1.11 RTSignalC.c > >>> 71c71 > >>> < pc = Context->uc_mcontext->ss.eip; > >>> --- > >>>> pc = Context->uc_mcontext->sc.sc_eip; > >>> > >>> > >>> Did you test ss.eip? > >>> And presumably sc.sc_eip doesn't work for you? Unless they have > >>> #defines for compat (on such short names..)? > >>> Maybe this changed from 10.4 to 10.5? > >>> I just want to change over the Unix/*.i3 files. > >>> I can leave my change uncommited till I get a real MacOSX>=10.5 > >>> system. > >>> > >>> > >>> I also get problems even in native builds with "rep" prefixes using > >>> the "builtin" tools (as). > >>> I'll change cm3cg to 586, or 486, or 386, whatever it takes, to > >>> workaround that. > >>> Also not commit that. > >>> Or maybe build a newer "cctools". > >>> > >>> > >>> - Jay > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon May 11 04:14:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 May 2009 12:14:56 +1000 Subject: [M3devel] I386_DARWIN GetPC, rep prefix? In-Reply-To: References: <3EB1F53C-5837-4DB4-8F1E-5D7EDC27201F@cs.purdue.edu> <67A25A63-2C3A-4926-8068-848436BC45AE@cs.purdue.edu> Message-ID: On 11 May 2009, at 11:51, Jay wrote: > And the #if is always true on 10.5, with a default command line? Yes, I believe so, but you should check what 10.4 does. Is there not a def you can use for your version of Darwin? > > Or even no matter the command line? > If so, therefore I'm free to do whatever in the #else? > > - Jay > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Mon, 11 May 2009 10:52:59 +1000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] I386_DARWIN GetPC, rep prefix? > > > > This works on 10.5: > > > > pc = Context->uc_mcontext->__ss.__eip; > > > > On 11 May 2009, at 10:00, Jay wrote: > > > > > > > > ok. What is the story on 10.5? > > > Your version works? My version works? > > > > > > - Jay > > > > > > ---------------------------------------- > > >> CC: m3devel at elegosoft.com > > >> From: hosking at cs.purdue.edu > > >> To: jay.krell at cornell.edu > > >> Subject: Re: I386_DARWIN GetPC, rep prefix? > > >> Date: Mon, 11 May 2009 09:26:36 +1000 > > >> > > >> Hmm. Not sure I did test that. I don't have any 10.4 systems > around > > >> anymore. > > >> > > >> On 11 May 2009, at 08:33, Jay wrote: > > >> > > >>> Tony, to get RTSignalC.c to compile on Darwin (not MacOSX) 8.0.1 > > >>> (aka 10.4). > > >>> > > >>> > > >>> > > >>> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ uname -a > > >>> Darwin jdar1.local 8.0.1 Darwin Kernel Version 8.0.1: Fri Apr 29 > > >>> 12:18:40 PDT 2005; root:xnu-792.obj > > >>> /RELEASE_I386 x86 i386 > > >>> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ > > >>> > > >>> > > >>> Probably that's a not very interesting target, but I don't yet > have > > >>> "real" x86/AMD64/Apple/Darwin hardware (just PPC/ARM). > > >>> > > >>> > > >>> I had to: > > >>> > > >>> > > >>> > =================================================================== > > >>> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/POSIX/ > > >>> RTSignalC.c,v > > >>> retrieving revision 1.11 > > >>> diff -r1.11 RTSignalC.c > > >>> 71c71 > > >>> < pc = Context->uc_mcontext->ss.eip; > > >>> --- > > >>>> pc = Context->uc_mcontext->sc.sc_eip; > > >>> > > >>> > > >>> Did you test ss.eip? > > >>> And presumably sc.sc_eip doesn't work for you? Unless they have > > >>> #defines for compat (on such short names..)? > > >>> Maybe this changed from 10.4 to 10.5? > > >>> I just want to change over the Unix/*.i3 files. > > >>> I can leave my change uncommited till I get a real MacOSX>=10.5 > > >>> system. > > >>> > > >>> > > >>> I also get problems even in native builds with "rep" prefixes > using > > >>> the "builtin" tools (as). > > >>> I'll change cm3cg to 586, or 486, or 386, whatever it takes, to > > >>> workaround that. > > >>> Also not commit that. > > >>> Or maybe build a newer "cctools". > > >>> > > >>> > > >>> - Jay > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue May 12 03:21:47 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 May 2009 11:21:47 +1000 Subject: [M3devel] Problems with setjmp/longjmp exception-handling and optimization Message-ID: <3C44BE4A-0836-431D-A044-4CB2CDA358BD@cs.purdue.edu> Just to summarise the status of optimization and setjmp/longjmp exception handling. Currently, optimizing breaks for setjmp/longjmp exceptions because register locals that are live across the setjmp call will revert to their value at the time of the setjmp instead of having the value at the time of the longjmp. The fix is to force the compiler front-end to allocate variables assigned inside TRY blocks to memory, so that those updates are not lost. This is only necessary for the setjmp/longjmp scheme. I am working on this right now. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue May 12 11:02:23 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 12 May 2009 09:02:23 +0000 Subject: [M3devel] how to find dependent .so files? In-Reply-To: <200904280900.27606.vapier@gentoo.org> References: <200904280900.27606.vapier@gentoo.org> Message-ID: This is in. I only tested on AMD64_LINUX. - Jay > From: jay.krell at cornell.edu > To: vapier at gentoo.org; m3devel at elegosoft.com > Subject: RE: [M3devel] how to find dependent .so files? > Date: Sun, 10 May 2009 21:32:25 +0000 > > > Any dissent on changing the symlinks to hardlinks? > I plan to try this pretty soon. > > - Jay > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: vapier at gentoo.org; m3devel at elegosoft.com > > Subject: RE: [M3devel] how to find dependent .so files? > > Date: Tue, 28 Apr 2009 13:15:06 +0000 > > > > > > If you take one of my suggestions, then yes you can do that for .sos. > > But $ORIGIN/../lib is one generic perhaps inefficient runpath for .sos and executables, and hypothetically also for non-public shipped executables (with my suggestion that they go to lib, if they don't already), that's why. > > > > > > The next step is just to smush lib and bin together, as is done on NT386. > > Probably people won't like that, keep files out of $PATH. > > > > > > I don't believe $ORIGIN works asis. > > if /cm3/lib/libfoo.so symlinks to /cm3/pkg/foo/target/libfoo.so > > then $ORIGIN is /cm3/pkg/foo/target, not /cm3/lib. > > I'd like to be wrong here but I don't think I am. > > > > > > So reversing the symlinks or making them hardlinks is ok? > > > > > > - Jay > > > > > > ---------------------------------------- > >> From: vapier at gentoo.org > >> To: m3devel at elegosoft.com > >> Date: Tue, 28 Apr 2009 09:00:26 -0400 > >> CC: jay.krell at cornell.edu > >> Subject: Re: [M3devel] how to find dependent .so files? > >> > >> On Tuesday 28 April 2009 04:03:13 Jay wrote: > >>> Normally we have: > >>> > >>> /usr/local/cm3/bin/someexe > >>> /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so > >>> /usr/local/cm3/lib/libbar.so symlink to ../pkg/bar/target/libbar.so > >>> > >>> Linking from someexe to $ORIGIN/../lib works, ok. > >>> But from libfoo to libbar requires $ORIGIN/../../../lib. > >>> or $ORIGIN/../../bar/target. > >> > >> what's wrong with just $ORIGIN ? they're in the same directory already. > >> -mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue May 12 12:32:42 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 12 May 2009 10:32:42 +0000 Subject: [M3devel] advise on handling iphone/ARM_DARWIN? (long version) Message-ID: so..I have an iphone. (Jail broken but also in use with AT&T as a real phone/computer.) No Intel Mac yet to do official development on. I built a C cross compiler on a PPC Mac. The various directions out there say it'll work on a variety of platforms but I had not great luck. I'm looking through Apple's "gcc-5490" for "Apple local". There are 11,000+ instances. Usually/always in begin/end pairs, so 5,500+. Skimming through some of them...lots of stuff to ignore..: some are to enable #pragmas in C/C++ front end some are Objective C specific some are for compatibility with CodeWarrior assembly blocks some are specific to PowerPC, AMD64, etc. lots are specific to ARM -- that is what is of interest some are in the testsuite some are for kernel code some are for "cfstrings" and "pascal strings" some is to adapt for use with their linker some I think is the "driver", which we don't use Ok, so let's just delete some directories (testsuite, doc, ada, cp, doc, libstdc++, libjava, libiberty (not very interesting generally), i386, rs6000, pa (yes, really, they have changes here), ia64 (yes, really), c-* (though really, reviewing the i386 and rs6000 directories, could be some important fixes?)) That gets it down to around 4,000. Anyone have any suggestions for what to do? I'm not even sure what the gcc base is for this stuff. I think it is 4.0.1, judging from the changelog. Maybe we should import their code into cvs and apply our patches? I know it'd really bloat up our tree, but I think it might be one of the better options. We could prune it down heavily as indicated, just striving for enough to target ARM_DARWIN, or maybe *_DARWIN, but still dropping the other front-ends for example. Note that this isn't even the toolset I built. That is something else. I think maybe llvm based. Btw, gcc has a "plugin" interface now. I don't know what all it can do. But I wonder..this might be an avenue that helps us, at least where cc=gcc (ie: where gcc is already available). On the other hand, I'm still very tempted by a C-generating backend, for greater portability.. - Jay From jay.krell at cornell.edu Tue May 12 12:35:26 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 12 May 2009 10:35:26 +0000 Subject: [M3devel] advise on handling iphone/ARM_DARWIN? (short version) Message-ID: I'm not sure what to do regarding targeting iphone/ARM_DARWIN. Would it be reasonablye and easy to, say, import Apple's "gcc-5490", maybe subset some, like rip out most of the libraries and front-ends, and apply our changes, and use this just for iphone/ARM_DARWIN? m3-sys/m3cc-iphone? m3-sys/m3cc-apple? Apple has thousands of changes, even if they mostly aren't relevant. We have hardly any at all, right? There is also an llvm based toolset for iphone. - Jay From wagner at elegosoft.com Tue May 12 18:15:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 May 2009 18:15:35 +0200 Subject: [M3devel] tinderbox error: ld: fatal: symbol `Unix__fcntl? is multiply-defined Message-ID: <20090512181535.z93nmrugsg8k0o8o@mail.elegosoft.com> error in SunOS build, see: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1242125700.7850 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed May 13 00:54:06 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 12 May 2009 22:54:06 +0000 Subject: [M3devel] tinderbox error: ld: fatal: symbol `Unix__fcntl? is multiply-defined In-Reply-To: <20090512181535.z93nmrugsg8k0o8o@mail.elegosoft.com> References: <20090512181535.z93nmrugsg8k0o8o@mail.elegosoft.com> Message-ID: should be ok now - Jay ---------------------------------------- > Date: Tue, 12 May 2009 18:15:35 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] tinderbox error: ld: fatal: symbol `Unix__fcntl? is multiply-defined > > error in SunOS build, see: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1242125700.7850 > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hendrik at topoi.pooq.com Thu May 14 04:07:13 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 13 May 2009 22:07:13 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090414171133.GB3460@topoi.pooq.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> Message-ID: <20090514020713.GA13442@topoi.pooq.com> On Tue, Apr 14, 2009 at 01:11:33PM -0400, hendrik at topoi.pooq.com wrote: > On Sat, Apr 11, 2009 at 11:26:11AM +0200, Olaf Wagner wrote: > > > > I'd rather avoid creating a branch too early, as that means more work > > by selecting and merging fixes from trunk to branch. So here my questions: > > > > o Do we all agree on a temporary code freeze? > > o When should we start? I.e. wha changes would you like to complete > > before we start the release process? > > One thing that's essential is to debug the documentation -- > specifically, the installation instructions, the various README files, > and so forth. A naive user. competent in the ways of computers, but not > yet in the ways of Modula 3, should be able to follow the instructions > and succeed. In a previous post, I emphasized that it was important for the installation instructions to be usable by a prospective user of Modula 3. If he has trouble installing it, he'll never get around to discovering its practical advantages over C. So I decided to play the part of a naive user, and thereby to make it clear what, if any, obstacles he would encounter. Here are my results. When these problems are cleared up, I have real naive user in mind whom I'll ask to install Modula 3 on his system, keeping a log of difficulties. I hope you'll take this in the spirit it was intended, as a form of constructive criticism, as a bug report, not as a rant. I started pretending I had just heard about Modula 3 and decided to try it. So I did the obvious and looked for Modula 3 on googlee. I found www.modula3.org. It had a link to the download page (second or third message in main panel) Because of advice there to get the latest patch level, tried to download current development snapshot CM3 d5.5.0 -- no such thing, link broken. Went to look for current stable release. Went to installation instructions Went to more specific instructions for Ubuntu or Debian (I am running Debian squeeze). Noticed that the instructions mentioned Ubuntu everywhere, but rarely Debian. established my ownership of /usr/local install flex and libncurses5-dev install libpq-dev, freeglut3-dev,unixodbc-dev, libmotif-dev, libx11-dev installed stow to manage symbolic links stow was kind of complicated, so I used the ln -s as in the instructions to link libXmu.so and libXaw.so. Now download. The link to opencm3.net didn't point to a page containing obvious downloads of tar archives. But its installation link pointed to a page with a download link, which led to a pane that contained downloadable looking links far down the page The link cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz led nowhere. But cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz seems OK It seems my browser chooses which directory to download to; mine chose ~/Desktop without telling me, which occasioned a bit of a search. Go back to the instruction page, where I discover that "most earlier minimal binaries do not work, so stick with d5.5.1 or later. These are known to succeed: then a few .tgz file names, which are *not* links." So time to discard what I've just downloaded. But where am I to find the one that works? At this point the naive user would start to get annoyed. But there were several other links immediately above this warning. Maybe it's time to try them. Why was I first directed to www.opencm3.net then, and not to one of the other directories more directly? try http://www.opencm3.net/download.html It looks like I've been here before. Under current development snapshots there's a d5.5.0 link, but that's too old. follow the uploaded archive page: find a cm3-min-LINUXLIBC6-d5.7.1.tar.gz That's a lot more recent, and it leads to an actual fila! remove the obsolete one, to avoid confusion later. But there's no checksum for the new one on the checksums page, http://www.opencm3.net/checksums.php3. I guess I'll just assume I downloaded it correctly. The untar command from the installation instructions created a directory cm3-min-LINUXLIBC6-d5.7.1 within ~/cm3-min. This means that the next command, ./cminstall will not work. Nor is there a cm3install inside ~/cm3-min/cm3-min-LINUXLIBC6-d5.7.1 or anywhere else in sight. The would-be user is now thoroughly stymied. If he were to persist, he might do so by posting a message like this in the comp.lang.modula3 newsgroup. Does anyone still read that? -- hendrik From wagner at elegosoft.com Thu May 14 08:44:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 14 May 2009 08:44:56 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090514020713.GA13442@topoi.pooq.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> Message-ID: <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Tue, Apr 14, 2009 at 01:11:33PM -0400, hendrik at topoi.pooq.com wrote: >> On Sat, Apr 11, 2009 at 11:26:11AM +0200, Olaf Wagner wrote: >> > >> > I'd rather avoid creating a branch too early, as that means more work >> > by selecting and merging fixes from trunk to branch. So here my questions: >> > >> > o Do we all agree on a temporary code freeze? >> > o When should we start? I.e. wha changes would you like to complete >> > before we start the release process? >> >> One thing that's essential is to debug the documentation -- >> specifically, the installation instructions, the various README files, >> and so forth. A naive user. competent in the ways of computers, but not >> yet in the ways of Modula 3, should be able to follow the instructions >> and succeed. Thank you for this description of your experience. I'll try to address at least some of the issues during the next days; not sure how far I'll get. Some of the problems are still caused by the server crash, where many old archives were simply lost and haven't been reconstructed until now. Others are caused by two types of installation archives (legacy format and Jay's new format), which are both found there. Others are simply caused by out-of-date documentation, which nobody cares for much :-/ I think it will be best to provide a complete new set of archives, but this may still take some time, and then update the documentation appropriately. Progress is much slower than I hoped for (completely my fault). Olaf > In a previous post, I emphasized that it was important for the > installation instructions to be usable by a prospective user of Modula > 3. If he has trouble installing it, he'll never get around to > discovering its practical advantages over C. So I decided to play the > part of a naive user, and thereby to make it clear what, if any, > obstacles he would encounter. Here are my results. When these problems > are cleared up, I have real naive user in mind whom I'll ask to install > Modula 3 on his system, keeping a log of difficulties. > > I hope you'll take this in the spirit it was intended, as a form of > constructive criticism, as a bug report, not as a rant. > > > > I started pretending I had just heard about Modula 3 and decided to try > it. So I did the obvious and looked for Modula 3 on googlee. I found > www.modula3.org. > > It had a link to the download page (second or third message in main > panel) > > Because of advice there to get the latest patch level, tried to download > current development snapshot CM3 d5.5.0 -- no such thing, link broken. > > Went to look for current stable release. > Went to installation instructions > Went to more specific instructions for Ubuntu or Debian (I am running > Debian squeeze). Noticed that the instructions mentioned Ubuntu > everywhere, but rarely Debian. > > established my ownership of /usr/local > > install flex and libncurses5-dev > install libpq-dev, freeglut3-dev,unixodbc-dev, libmotif-dev, libx11-dev > > installed stow to manage symbolic links > > stow was kind of complicated, so I used the ln -s as in the instructions > to link libXmu.so and libXaw.so. > > Now download. > > The link to opencm3.net didn't point to a page containing obvious > downloads of tar archives. > But its installation link pointed to a page with a download link, which > led to a pane that contained downloadable looking links far down the > page > > The link cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz led nowhere. > > But cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz seems OK > > It seems my browser chooses which directory to download to; mine chose > ~/Desktop without telling me, which occasioned a bit of a search. > > Go back to the instruction page, where I discover that "most earlier > minimal binaries do not work, so stick with d5.5.1 or later. These are > known to succeed: > then a few .tgz file names, which are *not* links." So time to discard > what I've just downloaded. But where am I to find the one that works? > > At this point the naive user would start to get annoyed. > But there were several other links immediately above this warning. > Maybe it's time to try them. Why was I first directed to > www.opencm3.net then, and not to one of the other directories more > directly? > > try http://www.opencm3.net/download.html > It looks like I've been here before. > Under current development snapshots there's a d5.5.0 link, but that's > too old. > > follow the uploaded archive page: > find a cm3-min-LINUXLIBC6-d5.7.1.tar.gz > That's a lot more recent, and it leads to an actual fila! > remove the obsolete one, to avoid confusion later. > > But there's no checksum for the new one on the checksums page, > http://www.opencm3.net/checksums.php3. I guess I'll just assume I > downloaded it correctly. > > The untar command from the installation instructions created a directory > cm3-min-LINUXLIBC6-d5.7.1 within ~/cm3-min. This means that the next > command, ./cminstall will not work. > > Nor is there a cm3install inside ~/cm3-min/cm3-min-LINUXLIBC6-d5.7.1 or > anywhere else in sight. > > The would-be user is now thoroughly stymied. > > If he were to persist, he might do so by posting a message like this in > the comp.lang.modula3 newsgroup. Does anyone still read that? > > -- hendrik > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Thu May 14 17:51:30 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 May 2009 11:51:30 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> Message-ID: <20090514155129.GA15181@topoi.pooq.com> On Thu, May 14, 2009 at 08:44:56AM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Tue, Apr 14, 2009 at 01:11:33PM -0400, hendrik at topoi.pooq.com wrote: > >>On Sat, Apr 11, 2009 at 11:26:11AM +0200, Olaf Wagner wrote: > >>> > >>> I'd rather avoid creating a branch too early, as that means more work > >>> by selecting and merging fixes from trunk to branch. So here my > >>questions: > >>> > >>> o Do we all agree on a temporary code freeze? > >>> o When should we start? I.e. wha changes would you like to complete > >>> before we start the release process? > >> > >>One thing that's essential is to debug the documentation -- > >>specifically, the installation instructions, the various README files, > >>and so forth. A naive user. competent in the ways of computers, but not > >>yet in the ways of Modula 3, should be able to follow the instructions > >>and succeed. > > Thank you for this description of your experience. You're welcome. > I'll try to address > at least some of the issues during the next days; not sure how far I'll > get. Take your time; get it right! > > Some of the problems are still caused by the server crash, where many > old archives were simply lost and haven't been reconstructed until now. Of course. > Others are caused by two types of installation archives (legacy format > and Jay's new format), which are both found there. Others are simply > caused by out-of-date documentation, which nobody cares for much :-/ > > I think it will be best to provide a complete new set of archives, but > this may still take some time, and then update the documentation > appropriately. Progress is much slower than I hoped for (completely > my fault). It will take time. But getting this right is an essential part of preparing a new release. When you think you've fixed this round of problems, IO have a friend who does not know Modula 3. I'll try and get him to install it on his machine and report on the problems. He's pretty good at finding problems, but I don't know when he'll have time. If I have the time, I'll try a first Windows XP install on Modula 3. Let me know when it would best help you get the release ready. Windows being Windows, I doubt I could do a second first install. -- hendrik From martinbishop at bellsouth.net Thu May 14 20:25:02 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 14 May 2009 13:25:02 -0500 Subject: [M3devel] Man or Boy test Message-ID: <4A0C61FE.9080107@bellsouth.net> I tried implementing Knuth's Man or Boy test in Modula-3, but I can't get it to work. I assumed the code I had wouldn't work (and I was right), but eventually I fiddled enough and got it to compile, but now it just segfaults when run. MODULE ManOrBoy EXPORTS Main; IMPORT IO, Fmt; PROCEDURE Zero(): INTEGER = BEGIN RETURN 0; END Zero; PROCEDURE One(): INTEGER = BEGIN RETURN 1; END One; PROCEDURE Neg(): INTEGER = BEGIN RETURN -1; END Neg; PROCEDURE A(k:INTEGER; x1, x2, x3, x4, x5: INTEGER): INTEGER = PROCEDURE B(): INTEGER = BEGIN DEC(k); RETURN A(k, B(), x1, x2, x3, x4); END B; BEGIN IF k <= 0 THEN RETURN x4 + x5; ELSE RETURN B(); END; END A; BEGIN IO.Put(Fmt.Int(A(10, One(), Neg(), Neg(), One(), Zero())) & "\n"); END ManOrBoy. All I know is that it segfaults at procedure B. From martinbishop at bellsouth.net Thu May 14 20:31:08 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 14 May 2009 13:31:08 -0500 Subject: [M3devel] Man or Boy test In-Reply-To: <4A0C61FE.9080107@bellsouth.net> References: <4A0C61FE.9080107@bellsouth.net> Message-ID: <4A0C636C.6000803@bellsouth.net> Sorry if I wasn't clean, but what I am asking is for why specifically it segfaults, I'm sure it's something to do with the recursive nature of the problem, just not sure how Modula-3 handles it. Martin Bishop wrote: > I tried implementing Knuth's Man or Boy test in Modula-3, but I can't > get it to work. > > I assumed the code I had wouldn't work (and I was right), but > eventually I fiddled enough and got it to compile, but now it just > segfaults when run. > > MODULE ManOrBoy EXPORTS Main; > > IMPORT IO, Fmt; > > PROCEDURE Zero(): INTEGER = BEGIN RETURN 0; END Zero; > PROCEDURE One(): INTEGER = BEGIN RETURN 1; END One; > PROCEDURE Neg(): INTEGER = BEGIN RETURN -1; END Neg; > > PROCEDURE A(k:INTEGER; x1, x2, x3, x4, x5: INTEGER): INTEGER = > > PROCEDURE B(): INTEGER = > BEGIN > DEC(k); > RETURN A(k, B(), x1, x2, x3, x4); > END B; > > BEGIN > IF k <= 0 THEN > RETURN x4 + x5; > ELSE > RETURN B(); > END; > END A; > > BEGIN > IO.Put(Fmt.Int(A(10, One(), Neg(), Neg(), One(), Zero())) & "\n"); > END ManOrBoy. > > All I know is that it segfaults at procedure B. > From rcoleburn at scires.com Thu May 14 21:23:01 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 14 May 2009 15:23:01 -0400 Subject: [M3devel] Man or Boy test In-Reply-To: <4A0C61FE.9080107@bellsouth.net> References: <4A0C61FE.9080107@bellsouth.net> Message-ID: <4A0C3751.1E75.00D7.1@scires.com> Martin: I've only scanned your code briefly here, but I would suspect that you are running out of stack space due to infinite recursion. I may be wrong here, but I think you have an infinite loop. Reason is that in B() you call A() again, but in the call to A() you also recursively call B() as one of the parameters to A(). Since all the parameters have to be evaluated before you can call A(), you wind up calling B() recursively with no termination condition since the test for k<=0 only occurs in A(), not B(). Regards, Randy Coleburn >>> Martin Bishop 5/14/2009 2:25 PM >>> I tried implementing Knuth's Man or Boy test in Modula-3, but I can't get it to work. I assumed the code I had wouldn't work (and I was right), but eventually I fiddled enough and got it to compile, but now it just segfaults when run. MODULE ManOrBoy EXPORTS Main; IMPORT IO, Fmt; PROCEDURE Zero(): INTEGER = BEGIN RETURN 0; END Zero; PROCEDURE One(): INTEGER = BEGIN RETURN 1; END One; PROCEDURE Neg(): INTEGER = BEGIN RETURN -1; END Neg; PROCEDURE A(k:INTEGER; x1, x2, x3, x4, x5: INTEGER): INTEGER = PROCEDURE B(): INTEGER = BEGIN DEC(k); RETURN A(k, B(), x1, x2, x3, x4); END B; BEGIN IF k <= 0 THEN RETURN x4 + x5; ELSE RETURN B(); END; END A; BEGIN IO.Put(Fmt.Int(A(10, One(), Neg(), Neg(), One(), Zero())) & "\n"); END ManOrBoy. All I know is that it segfaults at procedure B. CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu May 14 22:13:42 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 May 2009 16:13:42 -0400 Subject: [M3devel] Man or Boy test In-Reply-To: <4A0C61FE.9080107@bellsouth.net> References: <4A0C61FE.9080107@bellsouth.net> Message-ID: <20090514201341.GA15546@topoi.pooq.com> On Thu, May 14, 2009 at 01:25:02PM -0500, Martin Bishop wrote: > I tried implementing Knuth's Man or Boy test in Modula-3, but I can't > get it to work. > > I assumed the code I had wouldn't work (and I was right), but eventually > I fiddled enough and got it to compile, but now it just segfaults when run. > > MODULE ManOrBoy EXPORTS Main; > > IMPORT IO, Fmt; > > PROCEDURE Zero(): INTEGER = BEGIN RETURN 0; END Zero; > PROCEDURE One(): INTEGER = BEGIN RETURN 1; END One; > PROCEDURE Neg(): INTEGER = BEGIN RETURN -1; END Neg; > > PROCEDURE A(k:INTEGER; x1, x2, x3, x4, x5: INTEGER): INTEGER = > > PROCEDURE B(): INTEGER = > BEGIN > DEC(k); > RETURN A(k, B(), x1, x2, x3, x4); > END B; > > BEGIN > IF k <= 0 THEN > RETURN x4 + x5; > ELSE > RETURN B(); > END; > END A; > > BEGIN > IO.Put(Fmt.Int(A(10, One(), Neg(), Neg(), One(), Zero())) & "\n"); > END ManOrBoy. > > All I know is that it segfaults at procedure B. Probably because it contains an infinite recursion. I may remember wrongly, but I believe that in the original man-or-boy program, all parameters were passed by name, not by value. This means that the call to B() inside the call to A(...B()...) would be performed only if A itself used that parameter, and then as many times as A actually used it (dynamically). This the IF in A will break the recursion in B. The same does not happen with call-by-value. -- hendrik From jay.krell at cornell.edu Fri May 15 05:00:57 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 14 May 2009 20:00:57 -0700 Subject: [M3devel] optimizer In-Reply-To: <20090514044731.48A37CC3C1@birch.elegosoft.com> References: <20090514044731.48A37CC3C1@birch.elegosoft.com> Message-ID: <20499A8B-E85C-49C9-8840-F716A23E8BE2@hotmail.com> In the absence of anything else yet, sorry, how about twiddle the config files and watch the tinderbox? On a larger project that might be bad form. - Jay (phone) > Changes by: hosking@ > Feedback on experiences optimizing on other platforms would be > appreciated. From hosking at cs.purdue.edu Fri May 15 06:24:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 May 2009 14:24:03 +1000 Subject: [M3devel] optimizer In-Reply-To: <20499A8B-E85C-49C9-8840-F716A23E8BE2@hotmail.com> References: <20090514044731.48A37CC3C1@birch.elegosoft.com> <20499A8B-E85C-49C9-8840-F716A23E8BE2@hotmail.com> Message-ID: Sure, I just didn't want to get yelled at if tinderbox broke. On 15 May 2009, at 13:00, jay.krell at cornell.edu wrote: > In the absence of anything else yet, sorry, how about twiddle the > config files and watch the tinderbox? On a larger project that might > be bad form. > > - Jay (phone) > >> Changes by: hosking@ >> Feedback on experiences optimizing on other platforms would be >> appreciated. From wagner at elegosoft.com Fri May 15 08:42:30 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 15 May 2009 08:42:30 +0200 Subject: [M3devel] optimizer In-Reply-To: References: <20090514044731.48A37CC3C1@birch.elegosoft.com> <20499A8B-E85C-49C9-8840-F716A23E8BE2@hotmail.com> Message-ID: <20090515084230.mrha81n7k4gw8wgg@mail.elegosoft.com> Quoting Tony Hosking : > Sure, I just didn't want to get yelled at if tinderbox broke. Breakage is normal during software development. I hope nobody really minds any reminders here if we notice a problem; it's never meant to be personal. > On 15 May 2009, at 13:00, jay.krell at cornell.edu wrote: > >> In the absence of anything else yet, sorry, how about twiddle the >> config files and watch the tinderbox? On a larger project that >> might be bad form. >> >> - Jay (phone) >> >>> Changes by: hosking@ >>> Feedback on experiences optimizing on other platforms would be >>> appreciated. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri May 15 08:46:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 May 2009 16:46:25 +1000 Subject: [M3devel] optimizer In-Reply-To: <20090515084230.mrha81n7k4gw8wgg@mail.elegosoft.com> References: <20090514044731.48A37CC3C1@birch.elegosoft.com> <20499A8B-E85C-49C9-8840-F716A23E8BE2@hotmail.com> <20090515084230.mrha81n7k4gw8wgg@mail.elegosoft.com> Message-ID: <04498D7F-F5C0-4656-B4DB-4BED9A003282@cs.purdue.edu> I was being facetious. I'm generally not shy about being yelled at. ;-) On 15 May 2009, at 16:42, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Sure, I just didn't want to get yelled at if tinderbox broke. > > Breakage is normal during software development. I hope nobody really > minds any reminders here if we notice a problem; it's never meant to > be personal. > >> On 15 May 2009, at 13:00, jay.krell at cornell.edu wrote: >> >>> In the absence of anything else yet, sorry, how about twiddle the >>> config files and watch the tinderbox? On a larger project that >>> might be bad form. >>> >>> - Jay (phone) >>> >>>> Changes by: hosking@ >>>> Feedback on experiences optimizing on other platforms would be >>>> appreciated. > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From eiserlohpp at yahoo.com Fri May 15 23:00:58 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 15 May 2009 14:00:58 -0700 (PDT) Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides Message-ID: <362049.22100.qm@web56801.mail.re3.yahoo.com> Hi Guys, I downloaded a new archive: cm3-src-all-d5.8.0-2009-05-15-06-57-11.tgz, as I wanted to look at Olaf's changes. I attempted to "./scripts/do-cm3-std.sh build", and while it did build m3core, it failed to build libm3. Its 'm3overrides' file attempts to append ( using += ) to a variable (M3_FRONT_FLAGS), but since the variable doesn't exist it fails. Should an obliq script fail like that, if you attempt to append to a non-existing variable, or should it silently create that variable? Log follows: *** excerpt from Build.log *** new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 -> archiving libm3core.a ==> m3-libs/m3core done === package m3-libs/libm3 === +++ /usr/local/cm3/bin/cm3 -build -override -DROOT='/data/peter3/src/modula-3/cm3/src-all-20090515' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-05-06' +++ --- building in AMD64_LINUX --- "/data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides", line 7: quake runtime error: undefined variable: M3_FRONT_FLAGS --procedure-- -line- -file--- 7 /data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides Fatal Error: package build failed ==> m3-libs/libm3 done *** END excerpt Build.log *** *** m3overrides *** %%XXDIR = { "WIN32" : "N:\\m3-libs", "POSIX" : "/proj/cmass/src.2/m3-libs" } %%WORKDIR = XXDIR {OS_TYPE} % override ("m3core", WORKDIR) override("m3core", ROOT & "/m3-libs") M3_FRONT_FLAGS += "-vsdebug" _M3BUNDLE_OVERRIDE = "T" ** END m3overrides *** +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat May 16 00:25:25 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 15 May 2009 22:25:25 +0000 Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: <362049.22100.qm@web56801.mail.re3.yahoo.com> References: <362049.22100.qm@web56801.mail.re3.yahoo.com> Message-ID: I "fixed" this I guess, but as it was working for me, maybe your config files are not right? It is "quake" by the way, which I assume means "quick make" but I don't know. obliq is something else, like for scripting network objects? The file now reads: override("m3core", ROOT & "/m3-libs") if defined("M3_FRONT_FLAGS") M3_FRONT_FLAGS += "-vsdebug" else M3_FRONT_FLAGS = ["-vsdebug"] end _M3BUNDLE_OVERRIDE = "T" - Jay ---------------------------------------- > Date: Fri, 15 May 2009 14:00:58 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides > > > Hi Guys, > > I downloaded a new archive: cm3-src-all-d5.8.0-2009-05-15-06-57-11.tgz, > as I wanted to look at Olaf's changes. > > I attempted to "./scripts/do-cm3-std.sh build", and while > it did build m3core, it failed to build libm3. > > Its 'm3overrides' file attempts to append ( using += ) to a > variable (M3_FRONT_FLAGS), but since the variable doesn't > exist it fails. Should an obliq script fail like that, if > you attempt to append to a non-existing variable, or should > it silently create that variable? > > Log follows: > > *** excerpt from Build.log *** > new exporters -> recompiling Date.i3 > new exporters -> recompiling Text.i3 > -> archiving libm3core.a > ==> m3-libs/m3core done > > === package m3-libs/libm3 === > +++ /usr/local/cm3/bin/cm3 -build -override -DROOT='/data/peter3/src/modula-3/cm3/src-all-20090515' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-05-06' +++ > --- building in AMD64_LINUX --- > > "/data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides", line 7: quake runtime error: undefined variable: M3_FRONT_FLAGS > > --procedure-- -line- -file--- > 7 /data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides > > Fatal Error: package build failed > ==> m3-libs/libm3 done > *** END excerpt Build.log *** > > > *** m3overrides *** > > > %%XXDIR = { "WIN32" : "N:\\m3-libs", "POSIX" : "/proj/cmass/src.2/m3-libs" } > %%WORKDIR = XXDIR {OS_TYPE} > > % override ("m3core", WORKDIR) > override("m3core", ROOT & "/m3-libs") > M3_FRONT_FLAGS += "-vsdebug" > _M3BUNDLE_OVERRIDE = "T" > ** END m3overrides *** > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > From jay.krell at cornell.edu Sat May 16 00:27:08 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 15 May 2009 22:27:08 +0000 Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: <362049.22100.qm@web56801.mail.re3.yahoo.com> References: <362049.22100.qm@web56801.mail.re3.yahoo.com> Message-ID: specifically: C:\dev2\cm3.2\m3-sys\cminstall\src\config-no-install\cm3cfg.common if equal(M3_BACKEND_MODE, "0") or equal(M3_BACKEND_MODE, "1") or equal(M3_BACKEND_MODE, "IntegratedObject") or equal(M3_BACKEND_MODE, "IntegratedAssembly") M3_FRONT_FLAGS = ["-unfold_nested_procs", "-check_procs"] % --- internal configuration options passed directly to the Modula-3 front-end else M3_FRONT_FLAGS = [ ] end - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: eiserlohpp at yahoo.com; m3devel at elegosoft.com > Subject: RE: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides > Date: Fri, 15 May 2009 22:25:25 +0000 > > > I "fixed" this I guess, but as it was working for me, maybe your config files are not right? > It is "quake" by the way, which I assume means "quick make" but I don't know. > obliq is something else, like for scripting network objects? > > The file now reads: > > override("m3core", ROOT & "/m3-libs") > if defined("M3_FRONT_FLAGS") > M3_FRONT_FLAGS += "-vsdebug" > else > M3_FRONT_FLAGS = ["-vsdebug"] > end > _M3BUNDLE_OVERRIDE = "T" > > > - Jay > > ---------------------------------------- >> Date: Fri, 15 May 2009 14:00:58 -0700 >> From: eiserlohpp at yahoo.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides >> >> >> Hi Guys, >> >> I downloaded a new archive: cm3-src-all-d5.8.0-2009-05-15-06-57-11.tgz, >> as I wanted to look at Olaf's changes. >> >> I attempted to "./scripts/do-cm3-std.sh build", and while >> it did build m3core, it failed to build libm3. >> >> Its 'm3overrides' file attempts to append ( using += ) to a >> variable (M3_FRONT_FLAGS), but since the variable doesn't >> exist it fails. Should an obliq script fail like that, if >> you attempt to append to a non-existing variable, or should >> it silently create that variable? >> >> Log follows: >> >> *** excerpt from Build.log *** >> new exporters -> recompiling Date.i3 >> new exporters -> recompiling Text.i3 >> -> archiving libm3core.a >> ==> m3-libs/m3core done >> >> === package m3-libs/libm3 === >> +++ /usr/local/cm3/bin/cm3 -build -override -DROOT='/data/peter3/src/modula-3/cm3/src-all-20090515' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-05-06' +++ >> --- building in AMD64_LINUX --- >> >> "/data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides", line 7: quake runtime error: undefined variable: M3_FRONT_FLAGS >> >> --procedure-- -line- -file--- >> 7 /data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides >> >> Fatal Error: package build failed >> ==> m3-libs/libm3 done >> *** END excerpt Build.log *** >> >> >> *** m3overrides *** >> >> >> %%XXDIR = { "WIN32" : "N:\\m3-libs", "POSIX" : "/proj/cmass/src.2/m3-libs" } >> %%WORKDIR = XXDIR {OS_TYPE} >> >> % override ("m3core", WORKDIR) >> override("m3core", ROOT & "/m3-libs") >> M3_FRONT_FLAGS += "-vsdebug" >> _M3BUNDLE_OVERRIDE = "T" >> ** END m3overrides *** >> >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> From jay.krell at cornell.edu Sat May 16 00:28:30 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 15 May 2009 22:28:30 +0000 Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: References: <362049.22100.qm@web56801.mail.re3.yahoo.com> Message-ID: ok, I put it back to "broken" per the other mail.. ---------------------------------------- > From: jay.krell at cornell.edu > To: eiserlohpp at yahoo.com; m3devel at elegosoft.com > Date: Fri, 15 May 2009 22:25:25 +0000 > Subject: Re: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides > > > I "fixed" this I guess, but as it was working for me, maybe your config files are not right? > It is "quake" by the way, which I assume means "quick make" but I don't know. > obliq is something else, like for scripting network objects? > > The file now reads: > > override("m3core", ROOT & "/m3-libs") > if defined("M3_FRONT_FLAGS") > M3_FRONT_FLAGS += "-vsdebug" > else > M3_FRONT_FLAGS = ["-vsdebug"] > end > _M3BUNDLE_OVERRIDE = "T" > > > - Jay > > ---------------------------------------- >> Date: Fri, 15 May 2009 14:00:58 -0700 >> From: eiserlohpp at yahoo.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides >> >> >> Hi Guys, >> >> I downloaded a new archive: cm3-src-all-d5.8.0-2009-05-15-06-57-11.tgz, >> as I wanted to look at Olaf's changes. >> >> I attempted to "./scripts/do-cm3-std.sh build", and while >> it did build m3core, it failed to build libm3. >> >> Its 'm3overrides' file attempts to append ( using += ) to a >> variable (M3_FRONT_FLAGS), but since the variable doesn't >> exist it fails. Should an obliq script fail like that, if >> you attempt to append to a non-existing variable, or should >> it silently create that variable? >> >> Log follows: >> >> *** excerpt from Build.log *** >> new exporters -> recompiling Date.i3 >> new exporters -> recompiling Text.i3 >> -> archiving libm3core.a >> ==> m3-libs/m3core done >> >> === package m3-libs/libm3 === >> +++ /usr/local/cm3/bin/cm3 -build -override -DROOT='/data/peter3/src/modula-3/cm3/src-all-20090515' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-05-06' +++ >> --- building in AMD64_LINUX --- >> >> "/data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides", line 7: quake runtime error: undefined variable: M3_FRONT_FLAGS >> >> --procedure-- -line- -file--- >> 7 /data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides >> >> Fatal Error: package build failed >> ==> m3-libs/libm3 done >> *** END excerpt Build.log *** >> >> >> *** m3overrides *** >> >> >> %%XXDIR = { "WIN32" : "N:\\m3-libs", "POSIX" : "/proj/cmass/src.2/m3-libs" } >> %%WORKDIR = XXDIR {OS_TYPE} >> >> % override ("m3core", WORKDIR) >> override("m3core", ROOT & "/m3-libs") >> M3_FRONT_FLAGS += "-vsdebug" >> _M3BUNDLE_OVERRIDE = "T" >> ** END m3overrides *** >> >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> From eiserlohpp at yahoo.com Sat May 16 20:55:03 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 16 May 2009 11:55:03 -0700 (PDT) Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides Message-ID: <765542.63695.qm@web56805.mail.re3.yahoo.com> Jay, Thank you Jay for looking into this. Oops, you are right s/obliq/quake/. BTW: It builds all the way even in the same source tree when I do an "./scripts/upgrade.sh", I did a "realclean" first. I guess this (upgrade.sh) is what most people are using these days to build the compiler, rather than the old "do-cm3-foo" scripts. Okay, I downloaded cm3-src-all-d5.8.0-2009-05-16-12-07-46.tgz, and did an upgrade.sh, then after a "do-cm3-std.sh realclean", I re-tryed the "do-cm3.std.sh build", and it failed again with the same error. This is with cm3 (5.8.0) built with this mornings source tree. I inserted your change into libm3/src/m3override, and it is currently building. > The file now reads: > > override("m3core", ROOT & "/m3-libs") > if defined("M3_FRONT_FLAGS") > M3_FRONT_FLAGS += "-vsdebug" > else > M3_FRONT_FLAGS = ["-vsdebug"] > end > _M3BUNDLE_OVERRIDE = "T" This is worked for me. I suggest you check it into the repository. Peter > From: jay.krell at cornell.edu > To: eiserlohpp at yahoo.com; m3devel at elegosoft.com > Subject: RE: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides > Date: Sat May 16 00:27:08 CEST 2009 > >specifically: > > >C:\dev2\cm3.2\m3-sys\cminstall\src\config-no-install\cm3cfg.common > > > >if equal(M3_BACKEND_MODE, "0") or equal(M3_BACKEND_MODE, "1") > or equal(M3_BACKEND_MODE, "IntegratedObject") or equal(M3_BACKEND_MODE, "IntegratedAssembly") > M3_FRONT_FLAGS = ["-unfold_nested_procs", "-check_procs"] >% --- internal configuration options passed directly to the Modula-3 front-end >else > M3_FRONT_FLAGS = [ ] >end > > > - Jay > +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat May 16 23:52:07 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 16 May 2009 21:52:07 +0000 Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: <765542.63695.qm@web56805.mail.re3.yahoo.com> References: <765542.63695.qm@web56805.mail.re3.yahoo.com> Message-ID: Peter can you can roughly backup your config file send me/us your config file (attachment to m3devel ok) cp src/cm3/m3-sys/cminstall/src/config-no-install/* /usr/local/cm3/bin ? cm3.cfg might be in the neighboring config directory. I'm not entirely comfortable with the user-editability of config files and you seem to have either a user-edited one or an old one. Or did you start from scratch and run cminstall?? I don't think so but not sure. The user-editability of config files is partly to allow adapting to inevitably local conditions but I think also a bit of a cop-out to not encode things in cm3. If you correlate the number of questions cminstall asks with the editability of the config file, compare that to the number of questions or amount of editing or command line parameters typically involved with ./configure or apt-get install (often those are zero). In my own "programming", the config files are a cop out related to my lack of comfort with Modula-3. - Jay ---------------------------------------- > Date: Sat, 16 May 2009 11:55:03 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides > > > Jay, > > Thank you Jay for looking into this. Oops, you are right > s/obliq/quake/. > > BTW: It builds all the way even in the same source tree when I do an "./scripts/upgrade.sh", I did a "realclean" first. I guess this > (upgrade.sh) is what most people are using these days to build the > compiler, rather than the old "do-cm3-foo" scripts. > > Okay, I downloaded cm3-src-all-d5.8.0-2009-05-16-12-07-46.tgz, > and did an upgrade.sh, then after a "do-cm3-std.sh realclean", > I re-tryed the "do-cm3.std.sh build", and it failed again with > the same error. This is with cm3 (5.8.0) built with this mornings > source tree. > > I inserted your change into libm3/src/m3override, and it is currently > building. > >> The file now reads: >> >> override("m3core", ROOT & "/m3-libs") >> if defined("M3_FRONT_FLAGS") >> M3_FRONT_FLAGS += "-vsdebug" >> else >> M3_FRONT_FLAGS = ["-vsdebug"] >> end >> _M3BUNDLE_OVERRIDE = "T" > > This is worked for me. I suggest you check it into the repository. > > > Peter > > >> From: jay.krell at cornell.edu >> To: eiserlohpp at yahoo.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides >> Date: Sat May 16 00:27:08 CEST 2009 >> >>specifically: >> >> >>C:\dev2\cm3.2\m3-sys\cminstall\src\config-no-install\cm3cfg.common >> >> >> >>if equal(M3_BACKEND_MODE, "0") or equal(M3_BACKEND_MODE, "1") >> or equal(M3_BACKEND_MODE, "IntegratedObject") or equal(M3_BACKEND_MODE, "IntegratedAssembly") >> M3_FRONT_FLAGS = ["-unfold_nested_procs", "-check_procs"] >>% --- internal configuration options passed directly to the Modula-3 front-end >>else >> M3_FRONT_FLAGS = [ ] >>end >> >> >> - Jay >> > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > From jay.krell at cornell.edu Sun May 17 05:22:06 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 17 May 2009 03:22:06 +0000 Subject: [M3devel] humor: How to do "math" in quake (or at least add one). Message-ID: You might find this amusing. Task: implement a counter, in order to give temp files somewhat unique but not excessively random names caveats: it can exhibit "wraparound" behavior, but it should provide more than just 0-9 solution: m3cc_ResponseFileCounter0 = "0" m3cc_ResponseFileCounter1 = "0" m3cc_ResponseFileCounter2 = "0" local ShLeaf = "_m3" & m3cc_ResponseFileCounter0 & m3cc_ResponseFileCounter1 & m3cc_ResponseFileCounter2 & ".sh" Inc is a table/map/hashtable. Left of colon is key, right of colon is value. local Inc = { "0":"1","1":"2","2":"3","3":"4","4":"5", "5":"6","6":"7","7":"8","8":"9","9":"0" } m3cc_ResponseFileCounter2 = Inc{m3cc_ResponseFileCounter2} if equal(m3cc_ResponseFileCounter2, "0") m3cc_ResponseFileCounter1 = Inc{m3cc_ResponseFileCounter1} if equal(m3cc_ResponseFileCounter1, "0") m3cc_ResponseFileCounter0 = Inc{m3cc_ResponseFileCounter0} end end - Jay From eiserlohpp at yahoo.com Sun May 17 10:11:40 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 17 May 2009 01:11:40 -0700 (PDT) Subject: [M3devel] Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides Message-ID: <645259.70994.qm@web56801.mail.re3.yahoo.com> Hi Jay, Attached AMD64_LINUX (dated: 2008-10-30), Unix.common (dated: 2008-10-30). Hmm, I guess, I have fallen into the Modula-3 config file cess-pool. Okay, I copied the config files to a temporary directory, and the corresponding ones from the current source tree, and diff'ed them. Quite a number of changes. I will grab the new config files from the source tree, ... (hours pass), ..., okay things are working nicely. It failed midway through, complaining that it could not find a certain library. I don't want to install that library, so... I had to remove a couple lines from $ROOT/scripts/pkginfo.txt, specifically odbc, and while I was at it postgres95, I know I don't have Postgress95. That allowed me to build "std". So, then I decided to build everything with "do-cm3-all.sh", and I got an immediate: package cit_common not found *** cannot find package cit_common / Okay, back to editing pkginfo.txt, and removing cit_common, and while I am at it all the caltech parser packages. Darn, I was hoping to play with those. We need to document the fact that we have a number of bindings to libraries that may not exist on any particular machine, and when that occurs, the pkginfo.txt file should be edited to remove those packages from being compiled. Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ --- On Sat, 5/16/09, Jay wrote: > From: Jay > Subject: RE: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides > To: eiserlohpp at yahoo.com, "m3devel" > Date: Saturday, May 16, 2009, 2:52 PM > > Peter can you can roughly > backup your config file > send me/us your config file (attachment to m3devel ok) > cp src/cm3/m3-sys/cminstall/src/config-no-install/* > /usr/local/cm3/bin > > ? > > cm3.cfg might be in the neighboring config directory. > > I'm not entirely comfortable with the user-editability of > config files and you seem to have either a user-edited one > or an old one. > > > Or did you start from scratch and run cminstall?? I don't > think so but not sure. > > > The user-editability of config files is partly to allow > adapting to inevitably local conditions but I think also a > bit of a cop-out to not encode things in cm3. > If you correlate the number of questions cminstall asks > with the editability of the config file, compare that to the > number of questions or amount of editing or command line > parameters typically involved with ./configure or apt-get > install (often those are zero). > > In my own "programming", the config files are a cop out > related to my lack of comfort with Modula-3. > > - Jay > > > ---------------------------------------- > > Date: Sat, 16 May 2009 11:55:03 -0700 > > From: eiserlohpp at yahoo.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] missing M3_FRONT_FLAGS from > libm3: m3overrides > > > > > > Jay, > > > > Thank you Jay for looking into this. Oops, you are > right > > s/obliq/quake/. > > > > BTW: It builds all the way even in the same source > tree when I do an "./scripts/upgrade.sh", I did a > "realclean" first. I guess this > > (upgrade.sh) is what most people are using these days > to build the > > compiler, rather than the old "do-cm3-foo" scripts. > > > > Okay, I downloaded > cm3-src-all-d5.8.0-2009-05-16-12-07-46.tgz, > > and did an upgrade.sh, then after a "do-cm3-std.sh > realclean", > > I re-tryed the "do-cm3.std.sh build", and it failed > again with > > the same error. This is with cm3 (5.8.0) built with > this mornings > > source tree. > > > > I inserted your change into libm3/src/m3override, and > it is currently > > building. > > > >> The file now reads: > >> > >> override("m3core", ROOT & "/m3-libs") > >> if defined("M3_FRONT_FLAGS") > >> M3_FRONT_FLAGS += "-vsdebug" > >> else > >> M3_FRONT_FLAGS = ["-vsdebug"] > >> end > >> _M3BUNDLE_OVERRIDE = "T" > > > > This is worked for me. I suggest you check it into the > repository. > > > > > > Peter > > > > > >> From: jay.krell at cornell.edu > >> To: eiserlohpp at yahoo.com; m3devel at > elegosoft.com > >> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from > libm3: m3overrides > >> Date: Sat May 16 00:27:08 CEST 2009 > >> > >>specifically: > >> > >> > >>C:\dev2\cm3.2\m3-sys\cminstall\src\config-no-install\cm3cfg.common > >> > >> > >> > >>if equal(M3_BACKEND_MODE, "0") or > equal(M3_BACKEND_MODE, "1") > >> or equal(M3_BACKEND_MODE, "IntegratedObject") or > equal(M3_BACKEND_MODE, "IntegratedAssembly") > >> M3_FRONT_FLAGS = ["-unfold_nested_procs", > "-check_procs"] > >>% --- internal configuration options passed > directly to the Modula-3 front-end > >>else > >> M3_FRONT_FLAGS = [ ] > >>end > >> > >> > >> - Jay > >> > > > > > > > +--------------------------------------------------------+ > > | Peter P. Eiserloh | > > > +--------------------------------------------------------+ > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: AMD64_LINUX Type: application/octet-stream Size: 733 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Unix.common Type: application/octet-stream Size: 14515 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cm3.cfg Type: application/octet-stream Size: 23 bytes Desc: not available URL: From jay.krell at cornell.edu Sun May 17 11:39:26 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 17 May 2009 09:39:26 +0000 Subject: [M3devel] Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: <645259.70994.qm@web56801.mail.re3.yahoo.com> References: <645259.70994.qm@web56801.mail.re3.yahoo.com> Message-ID: I know this is a problem and not sure what to do about it. To backtrack, I think the original design is that the config file will put the libraries in system_libraries or system_liborder, and the m3makefile for the dependent packages will check for the presence in them. So, the reason I said "backtrack" is because this is another reason to edit config files, one that I haven't eliminated. You know, my config files are pretty good at being very portable, but not in this way. And they still have the lib/lib32/lib64 problem. Obviously pkginfo.txt wasn't in the original design. :) However the caltech/cit stuff is not this problem. The odbc/postgres stuff is. I generally go and do install the stuff, so I can build larger more featureful distributions. But you could classify that as the obligation of a distribution builder vs. a "normal" user. For caltech/cit, do this: cd to the root of source tree cvs -z3 upd -dAP rm scripts/PKGS and then try again. "all" I don't think works in general, for building. It works for "clean". "std" is the "all that works for buiding", I think. That is how I use them. But I still have a separate list of packages, oops. pylib.py doesn't yet read pkginfo.txt, oops. (This is an area where I complained about and fixed glaring redundancy in the sh files, and then put in my own similar redundancy, but also fixed the other.) Could be, simply, we define two package sets: all-that-tends-to-build-on-stock-systems all-with-extra-dependencies for some definition of "stock" -- does it include X Windows? I frequently hit missing X Windows stuff, but like with odbc/postgres I go and install it. Which devolves to: all-stock-nogui all-stock-gui all but this is getting messy and maybe go back to the original design. OR, maybe this isn't so bad -- you know, in the model where we have apt-get install modula3-this, apt-get install modula3-that, you do end up breaking it down into a lot of smaller pieces. Again I point to the example of what they did with X Windows. And maybe with KDE -- broken things down into many packages. Perhaps we should do that. ?? - Jay ---------------------------------------- > Date: Sun, 17 May 2009 01:11:40 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: [M3devel] Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides > > Hi Jay, > > Attached AMD64_LINUX (dated: 2008-10-30), > Unix.common (dated: 2008-10-30). > > Hmm, I guess, I have fallen into the Modula-3 config file > cess-pool. > > > Okay, I copied the config files to a temporary directory, > and the corresponding ones from the current source tree, > and diff'ed them. > > Quite a number of changes. I will grab the new config files from the > source tree, ... (hours pass), ..., okay things are working nicely. > > It failed midway through, complaining that it could not find > a certain library. I don't want to install that library, so... > > I had to remove a couple lines from $ROOT/scripts/pkginfo.txt, > specifically odbc, and while I was at it postgres95, I know I > don't have Postgress95. That allowed me to build "std". > > So, then I decided to build everything with "do-cm3-all.sh", > and I got an immediate: > > package cit_common not found > *** cannot find package cit_common / > > Okay, back to editing pkginfo.txt, and removing cit_common, and while > I am at it all the caltech parser packages. Darn, I was hoping to play > with those. > > We need to document the fact that we have a number of bindings to > libraries that may not exist on any particular machine, and when > that occurs, the pkginfo.txt file should be edited to remove those > packages from being compiled. > > > Peter > > > > > > > > > > > > > > > > > > > > > > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > --- On Sat, 5/16/09, Jay wrote: > >> From: Jay >> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides >> To: eiserlohpp at yahoo.com, "m3devel" >> Date: Saturday, May 16, 2009, 2:52 PM >> >> Peter can you can roughly >> backup your config file >> send me/us your config file (attachment to m3devel ok) >> cp src/cm3/m3-sys/cminstall/src/config-no-install/* >> /usr/local/cm3/bin >> >> ? >> >> cm3.cfg might be in the neighboring config directory. >> >> I'm not entirely comfortable with the user-editability of >> config files and you seem to have either a user-edited one >> or an old one. >> >> >> Or did you start from scratch and run cminstall?? I don't >> think so but not sure. >> >> >> The user-editability of config files is partly to allow >> adapting to inevitably local conditions but I think also a >> bit of a cop-out to not encode things in cm3. >> If you correlate the number of questions cminstall asks >> with the editability of the config file, compare that to the >> number of questions or amount of editing or command line >> parameters typically involved with ./configure or apt-get >> install (often those are zero). >> >> In my own "programming", the config files are a cop out >> related to my lack of comfort with Modula-3. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Sat, 16 May 2009 11:55:03 -0700 >>> From: eiserlohpp at yahoo.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] missing M3_FRONT_FLAGS from >> libm3: m3overrides >>> >>> >>> Jay, >>> >>> Thank you Jay for looking into this. Oops, you are >> right >>> s/obliq/quake/. >>> >>> BTW: It builds all the way even in the same source >> tree when I do an "./scripts/upgrade.sh", I did a >> "realclean" first. I guess this >>> (upgrade.sh) is what most people are using these days >> to build the >>> compiler, rather than the old "do-cm3-foo" scripts. >>> >>> Okay, I downloaded >> cm3-src-all-d5.8.0-2009-05-16-12-07-46.tgz, >>> and did an upgrade.sh, then after a "do-cm3-std.sh >> realclean", >>> I re-tryed the "do-cm3.std.sh build", and it failed >> again with >>> the same error. This is with cm3 (5.8.0) built with >> this mornings >>> source tree. >>> >>> I inserted your change into libm3/src/m3override, and >> it is currently >>> building. >>> >>>> The file now reads: >>>> >>>> override("m3core", ROOT & "/m3-libs") >>>> if defined("M3_FRONT_FLAGS") >>>> M3_FRONT_FLAGS += "-vsdebug" >>>> else >>>> M3_FRONT_FLAGS = ["-vsdebug"] >>>> end >>>> _M3BUNDLE_OVERRIDE = "T" >>> >>> This is worked for me. I suggest you check it into the >> repository. >>> >>> >>> Peter >>> >>> >>>> From: jay.krell at cornell.edu >>>> To: eiserlohpp at yahoo.com; m3devel at >> elegosoft.com >>>> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from >> libm3: m3overrides >>>> Date: Sat May 16 00:27:08 CEST 2009 >>>> >>>>specifically: >>>> >>>> >>>>C:\dev2\cm3.2\m3-sys\cminstall\src\config-no-install\cm3cfg.common >>>> >>>> >>>> >>>>if equal(M3_BACKEND_MODE, "0") or >> equal(M3_BACKEND_MODE, "1") >>>> or equal(M3_BACKEND_MODE, "IntegratedObject") or >> equal(M3_BACKEND_MODE, "IntegratedAssembly") >>>> M3_FRONT_FLAGS = ["-unfold_nested_procs", >> "-check_procs"] >>>>% --- internal configuration options passed >> directly to the Modula-3 front-end >>>>else >>>> M3_FRONT_FLAGS = [ ] >>>>end >>>> >>>> >>>> - Jay >>>> >>> >>> >>> >> +--------------------------------------------------------+ >>> | Peter P. Eiserloh | >>> >> +--------------------------------------------------------+ >>> >>> >>> > > > From jay.krell at cornell.edu Sun May 17 15:17:42 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 17 May 2009 13:17:42 +0000 Subject: [M3devel] optimizer vs. SOLgnu? Message-ID: Tony can you try building a cross compiler for SOLgnu and see how that fairs with -O2 or -O3? I get: new source -> compiling RTCollector.m3 ../src/runtime/common/RTCollector.m3: In function 'RTHeapRep__RegisterFinalCleanup': ../src/runtime/common/RTCollector.m3:2167: internal compiler error: in lookup_subvars_for_var, at tr ee-flow-inline.h:1591 also with -O2 (probably had it in -O3 also) ../src/runtime/common/RTAllocator.m3: In function 'RTAllocCnts__BumpSize': ../src/runtime/common/RTAllocator.m3:361: internal compiler error: in lookup_subvars_for_var, at tre e-flow-inline.h:1591 ../src/float/Common/DragonInt.m3: In function 'DragonInt__EndSession': ../src/float/Common/DragonInt.m3:90: internal compiler error: in lookup_subvars_for_var, at tree-flo w-inline.h:1591 and lots of success on other source. I am seeing success so far on AMD64_LINUX and LINUXLIBC6. - Jay From jay.krell at cornell.edu Sun May 17 15:35:00 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 17 May 2009 13:35:00 +0000 Subject: [M3devel] optimizer vs. SOLgnu? In-Reply-To: References: Message-ID: a little more info: dbx /dev2/cm3/m3-sys/m3cc/SOLgnu/gcc/m3cgc1 stop in fancy_abort run -quiet -O2 -fno-reorder-blocks RTCollector.mc -o RTCollector.ms where =>[1] fancy_abort(file = 0x813b28 "../../gcc/gcc/tree-flow-inline.h", line = 1591, function = 0x813b 88 "lookup_subvars_for_var"), line 660 in "diagnostic.c" [2] lookup_subvars_for_var(var = 0xfed10a90), line 1591 in "tree-flow-inline.h" [3] get_subvars_for_var(var = 0xfed10a90), line 1608 in "tree-flow-inline.h" [4] create_structure_vars(), line 4165 in "tree-ssa-alias.c" [5] execute_one_pass(pass = 0x860400), line 1122 in "passes.c" [6] execute_pass_list(pass = 0x860400), line 1175 in "passes.c" [7] execute_pass_list(pass = 0x86016c), line 1176 in "passes.c" [8] tree_rest_of_compilation(fndecl = 0xfefbbc00), line 404 in "tree-optimize.c" [9] cgraph_expand_function(node = 0xff149a48), line 1157 in "cgraphunit.c" [10] cgraph_expand_all_functions(), line 1220 in "cgraphunit.c" [11] cgraph_optimize(), line 1427 in "cgraphunit.c" [12] m3_parse_file(xx = 0), line 5241 in "parse.c" [13] compile_file(), line 1042 in "toplev.c" [14] do_compile(), line 2247 in "toplev.c" [15] toplev_main(argc = 7U, argv = 0xffbffbdc), line 2279 in "toplev.c" [16] main(argc = 7, argv = 0xffbffbdc), line 35 in "main.c" (dbx) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 17 May 2009 13:17:42 +0000 > Subject: [M3devel] optimizer vs. SOLgnu? > > > Tony can you try building a cross compiler for SOLgnu and see how that fairs with -O2 or -O3? I get: > > > new source -> compiling RTCollector.m3 > ../src/runtime/common/RTCollector.m3: In function 'RTHeapRep__RegisterFinalCleanup': > ../src/runtime/common/RTCollector.m3:2167: internal compiler error: in lookup_subvars_for_var, at tr > ee-flow-inline.h:1591 > > > also with -O2 (probably had it in -O3 also) > ../src/runtime/common/RTAllocator.m3: In function 'RTAllocCnts__BumpSize': > ../src/runtime/common/RTAllocator.m3:361: internal compiler error: in lookup_subvars_for_var, at tre > e-flow-inline.h:1591 > > > ../src/float/Common/DragonInt.m3: In function 'DragonInt__EndSession': > ../src/float/Common/DragonInt.m3:90: internal compiler error: in lookup_subvars_for_var, at tree-flo > w-inline.h:1591 > > and lots of success on other source. > > > I am seeing success so far on AMD64_LINUX and LINUXLIBC6. > > > - Jay From jay.krell at cornell.edu Sun May 17 15:40:15 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 17 May 2009 13:40:15 +0000 Subject: [M3devel] optimizer vs. SOLgnu/AMD64_LINUX? In-Reply-To: References: Message-ID: AMD64_LINUX (birch): --- building in AMD64_LINUX --- ignoring ../src/m3overrides /home/jkrell/cm3/bin/m3bundle -name B -F/tmp/qk new source -> compiling B.i3 new source -> compiling B.m3 new source -> compiling m3totex.m3 ../src/m3totex.m3: In function 'm3totex__Undisplay': ../src/m3totex.m3:210: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: m3totex.mc compilation failed => not building program "m3totex" Fatal Error: package build failed *** execution of [, ] failed *** birch [~/dev2/cm3/scripts/python] jkrell cd /home/jkrell/dev2/cm3/m3-tools/m3totex cm3 -keep -commands cd AMD64_LINUX gdb --args $HOME/dev2/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cgc1 -quiet -O3 -fno-reorder-blocks m3totex.mc -o m3totex.ms (gdb) r Starting program: /home/jkrell/dev2/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cgc1 -quiet -O3 -fno-reorder-blocks m3totex.mc -o m3totex.ms Program received signal SIGSEGV, Segmentation fault. 0x00000000006814f4 in remove_phi_node (phi=0x2b8f63d8ce80, prev=0x0, release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461 461 *loc != phi; (gdb) where #0 0x00000000006814f4 in remove_phi_node (phi=0x2b8f63d8ce80, prev=0x0, release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461 #1 0x00000000007039fb in remove_dead_inserted_code () at ../../gcc/gcc/tree-ssa-pre.c:3775 #2 0x00000000007042b2 in execute_pre (do_fre=0 '\0') at ../../gcc/gcc/tree-ssa-pre.c:3975 #3 0x00000000007042cc in do_pre () at ../../gcc/gcc/tree-ssa-pre.c:3987 #4 0x000000000058be1b in execute_one_pass (pass=0xe46860) at ../../gcc/gcc/passes.c:1122 #5 0x000000000058bf73 in execute_pass_list (pass=0xe46860) at ../../gcc/gcc/passes.c:1175 #6 0x000000000058bf91 in execute_pass_list (pass=0xe45420) at ../../gcc/gcc/passes.c:1176 #7 0x0000000000676bbd in tree_rest_of_compilation (fndecl=0x2b8f63b24000) at ../../gcc/gcc/tree-optimize.c:404 #8 0x00000000007cedf1 in cgraph_expand_function (node=0x2b8f63ac5d00) at ../../gcc/gcc/cgraphunit.c:1157 #9 0x00000000007cef9e in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1220 #10 0x00000000007cf551 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1427 #11 0x000000000040f875 in m3_parse_file (xx=0) at ../../gcc/gcc/m3cg/parse.c:5241 #12 0x000000000062feec in compile_file () at ../../gcc/gcc/toplev.c:1042 #13 0x0000000000631a26 in do_compile () at ../../gcc/gcc/toplev.c:2247 #14 0x0000000000631a8a in toplev_main (argc=7, argv=0x7fff47342e88) at ../../gcc/gcc/toplev.c:2279 #15 0x0000000000417ecf in main (argc=7, argv=0x7fff47342e88) at ../../gcc/gcc/main.c:35 (gdb) Same thing with -O2. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] optimizer vs. SOLgnu? > Date: Sun, 17 May 2009 13:35:00 +0000 > > > a little more info: > > > dbx /dev2/cm3/m3-sys/m3cc/SOLgnu/gcc/m3cgc1 > stop in fancy_abort > run -quiet -O2 -fno-reorder-blocks RTCollector.mc -o RTCollector.ms > where > > > =>[1] fancy_abort(file = 0x813b28 "../../gcc/gcc/tree-flow-inline.h", line = 1591, function = 0x813b > 88 "lookup_subvars_for_var"), line 660 in "diagnostic.c" > [2] lookup_subvars_for_var(var = 0xfed10a90), line 1591 in "tree-flow-inline.h" > [3] get_subvars_for_var(var = 0xfed10a90), line 1608 in "tree-flow-inline.h" > [4] create_structure_vars(), line 4165 in "tree-ssa-alias.c" > [5] execute_one_pass(pass = 0x860400), line 1122 in "passes.c" > [6] execute_pass_list(pass = 0x860400), line 1175 in "passes.c" > [7] execute_pass_list(pass = 0x86016c), line 1176 in "passes.c" > [8] tree_rest_of_compilation(fndecl = 0xfefbbc00), line 404 in "tree-optimize.c" > [9] cgraph_expand_function(node = 0xff149a48), line 1157 in "cgraphunit.c" > [10] cgraph_expand_all_functions(), line 1220 in "cgraphunit.c" > [11] cgraph_optimize(), line 1427 in "cgraphunit.c" > [12] m3_parse_file(xx = 0), line 5241 in "parse.c" > [13] compile_file(), line 1042 in "toplev.c" > [14] do_compile(), line 2247 in "toplev.c" > [15] toplev_main(argc = 7U, argv = 0xffbffbdc), line 2279 in "toplev.c" > [16] main(argc = 7, argv = 0xffbffbdc), line 35 in "main.c" > (dbx) > > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >> Date: Sun, 17 May 2009 13:17:42 +0000 >> Subject: [M3devel] optimizer vs. SOLgnu? >> >> >> Tony can you try building a cross compiler for SOLgnu and see how that fairs with -O2 or -O3? I get: >> >> >> new source -> compiling RTCollector.m3 >> ../src/runtime/common/RTCollector.m3: In function 'RTHeapRep__RegisterFinalCleanup': >> ../src/runtime/common/RTCollector.m3:2167: internal compiler error: in lookup_subvars_for_var, at tr >> ee-flow-inline.h:1591 >> >> >> also with -O2 (probably had it in -O3 also) >> ../src/runtime/common/RTAllocator.m3: In function 'RTAllocCnts__BumpSize': >> ../src/runtime/common/RTAllocator.m3:361: internal compiler error: in lookup_subvars_for_var, at tre >> e-flow-inline.h:1591 >> >> >> ../src/float/Common/DragonInt.m3: In function 'DragonInt__EndSession': >> ../src/float/Common/DragonInt.m3:90: internal compiler error: in lookup_subvars_for_var, at tree-flo >> w-inline.h:1591 >> >> and lots of success on other source. >> >> >> I am seeing success so far on AMD64_LINUX and LINUXLIBC6. >> >> >> - Jay From wagner at elegosoft.com Sun May 17 16:47:43 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 May 2009 16:47:43 +0200 Subject: [M3devel] humor: How to do "math" in quake (or at least add one). In-Reply-To: References: Message-ID: <20090517164743.1uigqjqfk88s8sg0@mail.elegosoft.com> I think we should just add a function for temporary filenames and implement it in M3. Olaf Quoting Jay : > You might find this amusing. > > > Task: > implement a counter, in order to give > temp files somewhat unique but not excessively > random names > > > caveats: > it can exhibit "wraparound" behavior, but > it should provide more than just 0-9 > > > solution: > > m3cc_ResponseFileCounter0 = "0" > m3cc_ResponseFileCounter1 = "0" > m3cc_ResponseFileCounter2 = "0" > > local ShLeaf = "_m3" & m3cc_ResponseFileCounter0 & > m3cc_ResponseFileCounter1 & m3cc_ResponseFileCounter2 & ".sh" > > > Inc is a table/map/hashtable. > Left of colon is key, right of colon is value. > > > local Inc = { "0":"1","1":"2","2":"3","3":"4","4":"5", > "5":"6","6":"7","7":"8","8":"9","9":"0" } > m3cc_ResponseFileCounter2 = Inc{m3cc_ResponseFileCounter2} > if equal(m3cc_ResponseFileCounter2, "0") > m3cc_ResponseFileCounter1 = Inc{m3cc_ResponseFileCounter1} > if equal(m3cc_ResponseFileCounter1, "0") > m3cc_ResponseFileCounter0 = Inc{m3cc_ResponseFileCounter0} > end > end > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun May 17 17:07:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 May 2009 17:07:14 +0200 Subject: [M3devel] Installation package collections, was: Re: Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: References: <645259.70994.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090517170714.w64nyj44o4884w8s@mail.elegosoft.com> Since Jay's touching the topic below, I thought I'd just tell you all of the first attempt to bundle the M3 packages into installation packages. I didn't want to end up with an installation package for every M3 package, but maybe the granularity is still too coarse. Currently I've got these: % for c in min core devlib m3devtool m3gdb webdev gui anim database cvsup obliq juno caltech-parser demo tool math game; do echo; echo "collection $c"; fgrep " $c" scripts/pkginfo.txt | awk '{print $1}' > x-$c; cat x-$c; done collection min # minimal m3 installation (together with the compiler) import-libs m3core libm3 collection core # a usable system able to bootstrap itself with some additional libraries import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3staloneback m3front m3quake cm3 m3scanner m3tools m3cgcat m3cggen m3bundle mklib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl tcp collection devlib # libraries for various development work windowsResources udp libsio libbuf debug listfuncs m3tk-misc binIO commandrw tapi serial m3tk m3scan m3markup events rdwr PEX deepcopy sgml collection m3devtool # M3 development tools complementing the compiler cm3ide m3totex m3tohtml m3browser netobj netobjd stubgen sharedobj sharedobjgen stablegen stable formsview formsedit recordheap rehearsecode replayheap showheap shownew showthread pp collection m3gdb # the GNU debugger for M3 (rather large, so it has its own package) m3gdb collection webdev # web development packages http m3-www/web m3-www/proxy webvbt deckscape webscape webcat collection gui # gui libraries import-libs tcp X11R4 ui vbtkit cmvbt jvideo videovbt formsvbtpixmaps formsvbt formsview formsedit opengl webvbt kate m3-ui/bicycle collection anim # animation libraries, tools and demo codeview mg mgkit anim3D zeus m3zume mentor collection database # database packages and interfaces odbc postgres95 db smalldb collection cvsup # CVSup cvsup/suplib cvsup/client cvsup/server cvsup/cvpasswd collection obliq # Obliq implementation embutils synloc synex metasyn obliqrt obliqparse obliqprint obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim obliqlib3D visualobliq vocgi voquery vorun collection juno # The Juno graphical constraint-based editor pkl-fonts juno-machine juno-compiler juno-app collection caltech-parser # Caltech parser generator import-libs cit_common m3tmplhack cit_util term paneman paneman/kemacs drawcontext drawcontext/dcpane drawcontext/kgv hack m3browserhack parserlib/ktoklib parserlib/klexlib parserlib/kyacclib parserlib/ktok parserlib/klex parserlib/kyacc parserlib/kext parserlib/parserlib parserlib/parserlib/test collection demo # some demo programs cube calculator fisheye collection tool # more or less useful tools mtex cmpdir cmpfp dirfp uniq collection math # mathematical libraries arithmetic unittest-numeric collection game # games and game support m3-ui/bicycle m3-games/badbricks m3-games/columns m3-games/fours m3-games/maze m3-games/solitaire m3-games/tetris Comments welcome. Olaf Quoting Jay : > I know this is a problem and not sure what to do about it. > > > To backtrack, I think the original design is that the config file will > put the libraries in system_libraries or system_liborder, and the m3makefile > for the dependent packages will check for the presence in them. > > So, the reason I said "backtrack" is because this is another reason > to edit config files, one that I haven't eliminated. > You know, my config files are pretty good at being very portable, > but not in this way. And they still have the lib/lib32/lib64 problem. > > Obviously pkginfo.txt wasn't in the original design. :) > > However the caltech/cit stuff is not this problem. > The odbc/postgres stuff is. > I generally go and do install the stuff, so I can build larger > more featureful distributions. But you could classify that > as the obligation of a distribution builder vs. a "normal" user. > > For caltech/cit, do this: > > cd to the root of source tree > cvs -z3 upd -dAP > rm scripts/PKGS > > and then try again. > > "all" I don't think works in general, for building. > It works for "clean". > "std" is the "all that works for buiding", I think. > That is how I use them. But I still have a separate list of packages, oops. > pylib.py doesn't yet read pkginfo.txt, oops. > (This is an area where I complained about and fixed glaring > redundancy in the sh files, and then put in my own similar > redundancy, but also fixed the other.) > > Could be, simply, we define two package sets: > all-that-tends-to-build-on-stock-systems > all-with-extra-dependencies > > for some definition of "stock" -- does it include X Windows? > I frequently hit missing X Windows stuff, but like with odbc/postgres > I go and install it. > > > Which devolves to: > > all-stock-nogui > all-stock-gui > all > > but this is getting messy and maybe go back to the original design. > OR, maybe this isn't so bad -- you know, in the model where we > have apt-get install modula3-this, apt-get install modula3-that, > you do end up breaking it down into a lot of smaller pieces. > Again I point to the example of what they did with X Windows. > And maybe with KDE -- broken things down into many packages. > Perhaps we should do that. > ?? > > > - Jay > > > ---------------------------------------- >> Date: Sun, 17 May 2009 01:11:40 -0700 >> From: eiserlohpp at yahoo.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] Missing packages, Was: missing M3_FRONT_FLAGS >> from libm3: m3overrides >> >> Hi Jay, >> >> Attached AMD64_LINUX (dated: 2008-10-30), >> Unix.common (dated: 2008-10-30). >> >> Hmm, I guess, I have fallen into the Modula-3 config file >> cess-pool. >> >> >> Okay, I copied the config files to a temporary directory, >> and the corresponding ones from the current source tree, >> and diff'ed them. >> >> Quite a number of changes. I will grab the new config files from the >> source tree, ... (hours pass), ..., okay things are working nicely. >> >> It failed midway through, complaining that it could not find >> a certain library. I don't want to install that library, so... >> >> I had to remove a couple lines from $ROOT/scripts/pkginfo.txt, >> specifically odbc, and while I was at it postgres95, I know I >> don't have Postgress95. That allowed me to build "std". >> >> So, then I decided to build everything with "do-cm3-all.sh", >> and I got an immediate: >> >> package cit_common not found >> *** cannot find package cit_common / >> >> Okay, back to editing pkginfo.txt, and removing cit_common, and while >> I am at it all the caltech parser packages. Darn, I was hoping to play >> with those. >> >> We need to document the fact that we have a number of bindings to >> libraries that may not exist on any particular machine, and when >> that occurs, the pkginfo.txt file should be edited to remove those >> packages from being compiled. >> >> >> Peter >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> --- On Sat, 5/16/09, Jay wrote: >> >>> From: Jay >>> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides >>> To: eiserlohpp at yahoo.com, "m3devel" >>> Date: Saturday, May 16, 2009, 2:52 PM >>> >>> Peter can you can roughly >>> backup your config file >>> send me/us your config file (attachment to m3devel ok) >>> cp src/cm3/m3-sys/cminstall/src/config-no-install/* >>> /usr/local/cm3/bin >>> >>> ? >>> >>> cm3.cfg might be in the neighboring config directory. >>> >>> I'm not entirely comfortable with the user-editability of >>> config files and you seem to have either a user-edited one >>> or an old one. >>> >>> >>> Or did you start from scratch and run cminstall?? I don't >>> think so but not sure. >>> >>> >>> The user-editability of config files is partly to allow >>> adapting to inevitably local conditions but I think also a >>> bit of a cop-out to not encode things in cm3. >>> If you correlate the number of questions cminstall asks >>> with the editability of the config file, compare that to the >>> number of questions or amount of editing or command line >>> parameters typically involved with ./configure or apt-get >>> install (often those are zero). >>> >>> In my own "programming", the config files are a cop out >>> related to my lack of comfort with Modula-3. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Sat, 16 May 2009 11:55:03 -0700 >>>> From: eiserlohpp at yahoo.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] missing M3_FRONT_FLAGS from >>> libm3: m3overrides >>>> >>>> >>>> Jay, >>>> >>>> Thank you Jay for looking into this. Oops, you are >>> right >>>> s/obliq/quake/. >>>> >>>> BTW: It builds all the way even in the same source >>> tree when I do an "./scripts/upgrade.sh", I did a >>> "realclean" first. I guess this >>>> (upgrade.sh) is what most people are using these days >>> to build the >>>> compiler, rather than the old "do-cm3-foo" scripts. >>>> >>>> Okay, I downloaded >>> cm3-src-all-d5.8.0-2009-05-16-12-07-46.tgz, >>>> and did an upgrade.sh, then after a "do-cm3-std.sh >>> realclean", >>>> I re-tryed the "do-cm3.std.sh build", and it failed >>> again with >>>> the same error. This is with cm3 (5.8.0) built with >>> this mornings >>>> source tree. >>>> >>>> I inserted your change into libm3/src/m3override, and >>> it is currently >>>> building. >>>> >>>>> The file now reads: >>>>> >>>>> override("m3core", ROOT & "/m3-libs") >>>>> if defined("M3_FRONT_FLAGS") >>>>> M3_FRONT_FLAGS += "-vsdebug" >>>>> else >>>>> M3_FRONT_FLAGS = ["-vsdebug"] >>>>> end >>>>> _M3BUNDLE_OVERRIDE = "T" >>>> >>>> This is worked for me. I suggest you check it into the >>> repository. >>>> >>>> >>>> Peter >>>> >>>> >>>>> From: jay.krell at cornell.edu >>>>> To: eiserlohpp at yahoo.com; m3devel at >>> elegosoft.com >>>>> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from >>> libm3: m3overrides >>>>> Date: Sat May 16 00:27:08 CEST 2009 >>>>> >>>>> specifically: >>>>> >>>>> >>>>> C:\dev2\cm3.2\m3-sys\cminstall\src\config-no-install\cm3cfg.common >>>>> >>>>> >>>>> >>>>> if equal(M3_BACKEND_MODE, "0") or >>> equal(M3_BACKEND_MODE, "1") >>>>> or equal(M3_BACKEND_MODE, "IntegratedObject") or >>> equal(M3_BACKEND_MODE, "IntegratedAssembly") >>>>> M3_FRONT_FLAGS = ["-unfold_nested_procs", >>> "-check_procs"] >>>>> % --- internal configuration options passed >>> directly to the Modula-3 front-end >>>>> else >>>>> M3_FRONT_FLAGS = [ ] >>>>> end >>>>> >>>>> >>>>> - Jay >>>>> >>>> >>>> >>>> >>> +--------------------------------------------------------+ >>>> | Peter P. Eiserloh | >>>> >>> +--------------------------------------------------------+ >>>> >>>> >>>> >> >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon May 18 02:12:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 May 2009 10:12:56 +1000 Subject: [M3devel] optimizer vs. SOLgnu? In-Reply-To: References: Message-ID: This one sounds familiar. I'll try to track it down. On 17 May 2009, at 23:17, Jay wrote: > > Tony can you try building a cross compiler for SOLgnu and see how > that fairs with -O2 or -O3? I get: > > > new source -> compiling RTCollector.m3 > ../src/runtime/common/RTCollector.m3: In function > 'RTHeapRep__RegisterFinalCleanup': > ../src/runtime/common/RTCollector.m3:2167: internal compiler error: > in lookup_subvars_for_var, at tr > ee-flow-inline.h:1591 > > > also with -O2 (probably had it in -O3 also) > ../src/runtime/common/RTAllocator.m3: In function > 'RTAllocCnts__BumpSize': > ../src/runtime/common/RTAllocator.m3:361: internal compiler error: > in lookup_subvars_for_var, at tre > e-flow-inline.h:1591 > > > ../src/float/Common/DragonInt.m3: In function 'DragonInt__EndSession': > ../src/float/Common/DragonInt.m3:90: internal compiler error: in > lookup_subvars_for_var, at tree-flo > w-inline.h:1591 > > and lots of success on other source. > > > I am seeing success so far on AMD64_LINUX and LINUXLIBC6. > > > - Jay From hosking at cs.purdue.edu Mon May 18 02:13:42 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 May 2009 10:13:42 +1000 Subject: [M3devel] optimizer vs. SOLgnu/AMD64_LINUX? In-Reply-To: References: Message-ID: <66DE48A4-130D-4990-9E34-1437E74FEC5A@cs.purdue.edu> This one also sounds familiar. On 17 May 2009, at 23:40, Jay wrote: > > AMD64_LINUX (birch): > > --- building in AMD64_LINUX --- > ignoring ../src/m3overrides > /home/jkrell/cm3/bin/m3bundle -name B -F/tmp/qk > new source -> compiling B.i3 > new source -> compiling B.m3 > new source -> compiling m3totex.m3 > ../src/m3totex.m3: In function 'm3totex__Undisplay': > ../src/m3totex.m3:210: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: m3totex.mc > compilation failed => not building program "m3totex" > Fatal Error: package build failed > *** execution of [, ] failed *** > birch [~/dev2/cm3/scripts/python] jkrell > > > cd /home/jkrell/dev2/cm3/m3-tools/m3totex > cm3 -keep -commands > cd AMD64_LINUX > gdb --args $HOME/dev2/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cgc1 -quiet - > O3 -fno-reorder-blocks m3totex.mc -o m3totex.ms > (gdb) r > Starting program: /home/jkrell/dev2/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/ > m3cgc1 -quiet -O3 -fno-reorder-blocks m3totex.mc -o m3totex.ms > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000006814f4 in remove_phi_node (phi=0x2b8f63d8ce80, prev=0x0, > release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461 > 461 *loc != phi; > > (gdb) where > #0 0x00000000006814f4 in remove_phi_node (phi=0x2b8f63d8ce80, > prev=0x0, > release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461 > #1 0x00000000007039fb in remove_dead_inserted_code () > at ../../gcc/gcc/tree-ssa-pre.c:3775 > #2 0x00000000007042b2 in execute_pre (do_fre=0 '\0') > at ../../gcc/gcc/tree-ssa-pre.c:3975 > #3 0x00000000007042cc in do_pre () at ../../gcc/gcc/tree-ssa-pre.c: > 3987 > #4 0x000000000058be1b in execute_one_pass (pass=0xe46860) > at ../../gcc/gcc/passes.c:1122 > #5 0x000000000058bf73 in execute_pass_list (pass=0xe46860) > at ../../gcc/gcc/passes.c:1175 > #6 0x000000000058bf91 in execute_pass_list (pass=0xe45420) > at ../../gcc/gcc/passes.c:1176 > #7 0x0000000000676bbd in tree_rest_of_compilation > (fndecl=0x2b8f63b24000) > at ../../gcc/gcc/tree-optimize.c:404 > #8 0x00000000007cedf1 in cgraph_expand_function (node=0x2b8f63ac5d00) > at ../../gcc/gcc/cgraphunit.c:1157 > #9 0x00000000007cef9e in cgraph_expand_all_functions () > at ../../gcc/gcc/cgraphunit.c:1220 > #10 0x00000000007cf551 in cgraph_optimize () > at ../../gcc/gcc/cgraphunit.c:1427 > #11 0x000000000040f875 in m3_parse_file (xx=0) > at ../../gcc/gcc/m3cg/parse.c:5241 > #12 0x000000000062feec in compile_file () at ../../gcc/gcc/toplev.c: > 1042 > #13 0x0000000000631a26 in do_compile () at ../../gcc/gcc/toplev.c:2247 > #14 0x0000000000631a8a in toplev_main (argc=7, argv=0x7fff47342e88) > at ../../gcc/gcc/toplev.c:2279 > #15 0x0000000000417ecf in main (argc=7, argv=0x7fff47342e88) > at ../../gcc/gcc/main.c:35 > (gdb) > > > Same thing with -O2. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >> Subject: RE: [M3devel] optimizer vs. SOLgnu? >> Date: Sun, 17 May 2009 13:35:00 +0000 >> >> >> a little more info: >> >> >> dbx /dev2/cm3/m3-sys/m3cc/SOLgnu/gcc/m3cgc1 >> stop in fancy_abort >> run -quiet -O2 -fno-reorder-blocks RTCollector.mc -o RTCollector.ms >> where >> >> >> =>[1] fancy_abort(file = 0x813b28 "../../gcc/gcc/tree-flow- >> inline.h", line = 1591, function = 0x813b >> 88 "lookup_subvars_for_var"), line 660 in "diagnostic.c" >> [2] lookup_subvars_for_var(var = 0xfed10a90), line 1591 in "tree- >> flow-inline.h" >> [3] get_subvars_for_var(var = 0xfed10a90), line 1608 in "tree-flow- >> inline.h" >> [4] create_structure_vars(), line 4165 in "tree-ssa-alias.c" >> [5] execute_one_pass(pass = 0x860400), line 1122 in "passes.c" >> [6] execute_pass_list(pass = 0x860400), line 1175 in "passes.c" >> [7] execute_pass_list(pass = 0x86016c), line 1176 in "passes.c" >> [8] tree_rest_of_compilation(fndecl = 0xfefbbc00), line 404 in >> "tree-optimize.c" >> [9] cgraph_expand_function(node = 0xff149a48), line 1157 in >> "cgraphunit.c" >> [10] cgraph_expand_all_functions(), line 1220 in "cgraphunit.c" >> [11] cgraph_optimize(), line 1427 in "cgraphunit.c" >> [12] m3_parse_file(xx = 0), line 5241 in "parse.c" >> [13] compile_file(), line 1042 in "toplev.c" >> [14] do_compile(), line 2247 in "toplev.c" >> [15] toplev_main(argc = 7U, argv = 0xffbffbdc), line 2279 in >> "toplev.c" >> [16] main(argc = 7, argv = 0xffbffbdc), line 35 in "main.c" >> (dbx) >> >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Date: Sun, 17 May 2009 13:17:42 +0000 >>> Subject: [M3devel] optimizer vs. SOLgnu? >>> >>> >>> Tony can you try building a cross compiler for SOLgnu and see how >>> that fairs with -O2 or -O3? I get: >>> >>> >>> new source -> compiling RTCollector.m3 >>> ../src/runtime/common/RTCollector.m3: In function >>> 'RTHeapRep__RegisterFinalCleanup': >>> ../src/runtime/common/RTCollector.m3:2167: internal compiler >>> error: in lookup_subvars_for_var, at tr >>> ee-flow-inline.h:1591 >>> >>> >>> also with -O2 (probably had it in -O3 also) >>> ../src/runtime/common/RTAllocator.m3: In function >>> 'RTAllocCnts__BumpSize': >>> ../src/runtime/common/RTAllocator.m3:361: internal compiler error: >>> in lookup_subvars_for_var, at tre >>> e-flow-inline.h:1591 >>> >>> >>> ../src/float/Common/DragonInt.m3: In function >>> 'DragonInt__EndSession': >>> ../src/float/Common/DragonInt.m3:90: internal compiler error: in >>> lookup_subvars_for_var, at tree-flo >>> w-inline.h:1591 >>> >>> and lots of success on other source. >>> >>> >>> I am seeing success so far on AMD64_LINUX and LINUXLIBC6. >>> >>> >>> - Jay From jay.krell at cornell.edu Mon May 18 04:23:03 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 18 May 2009 02:23:03 +0000 Subject: [M3devel] version number Message-ID: Did we burn through 5.7.x too fast maybe? I know it hardly matters... - Jay From wagner at elegosoft.com Mon May 18 10:53:59 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 May 2009 10:53:59 +0200 Subject: [M3devel] version number In-Reply-To: References: Message-ID: <20090518105359.e9qguctgsowg4k0o@mail.elegosoft.com> Quoting Jay : > Did we burn through 5.7.x too fast maybe? > I know it hardly matters... I'm using the version number for release engineering now. Whenever there is change until the release, I'll increase the patch level. I still lhope that the other activities calm down when the first RC is there; otherwise I'll have to create a branch. I hope this does not interfere with anything else. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Mon May 18 12:47:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 18 May 2009 06:47:48 -0400 Subject: [M3devel] Installation package collections, was: Re: Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: <20090517170714.w64nyj44o4884w8s@mail.elegosoft.com> References: <645259.70994.qm@web56801.mail.re3.yahoo.com> <20090517170714.w64nyj44o4884w8s@mail.elegosoft.com> Message-ID: <20090518104747.GB24011@topoi.pooq.com> On Sun, May 17, 2009 at 05:07:14PM +0200, Olaf Wagner wrote: > > collection gui # gui libraries > m3-ui/bicycle > > collection game # games and game support > m3-ui/bicycle One m3 package is in two different collections. If eash collection turns into a Debian package, they will conflict. -- hendrik From dragisha at m3w.org Mon May 18 14:29:12 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 18 May 2009 14:29:12 +0200 Subject: [M3devel] Pickle related incompatible changes in last six months, anybody? Message-ID: <1242649752.9969.9.camel@faramir.m3w.org> As subjest line says, are there some incompatibilies incorporated into Pickle subsystem in last six months? I have a database, unused for some time, last changed some six months ago... TIA, -- Dragi?a Duri? From wagner at elegosoft.com Mon May 18 19:47:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 May 2009 19:47:36 +0200 Subject: [M3devel] Installation package collections, was: Re: Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: <20090518104747.GB24011@topoi.pooq.com> References: <645259.70994.qm@web56801.mail.re3.yahoo.com> <20090517170714.w64nyj44o4884w8s@mail.elegosoft.com> <20090518104747.GB24011@topoi.pooq.com> Message-ID: <20090518194736.g2xtpy06m8soocw8@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Sun, May 17, 2009 at 05:07:14PM +0200, Olaf Wagner wrote: >> >> collection gui # gui libraries >> m3-ui/bicycle >> >> collection game # games and game support >> m3-ui/bicycle > > One m3 package is in two different collections. If eash collection > turns into a Debian package, they will conflict. Any preferences where to remove the conflicting package(s)? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue May 19 15:50:19 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 19 May 2009 06:50:19 -0700 Subject: [M3devel] Cm3 on iPhone (or iPod touch) Message-ID: <3C3602DD-4C3D-4A34-B228-E822DBA483E8@hotmail.com> Cm3 gets to the of saying like "no config file found" which is correct. - Jay (phone) From dragisha at m3w.org Tue May 19 19:27:28 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 19 May 2009 19:27:28 +0200 Subject: [M3devel] Probably missing too much of development sycle, but WTF? Message-ID: <1242754048.3061.1.camel@faramir.m3w.org> VARIABLES? Now every1 who was using CASE with error results has to adapt one's code? What is rationale here? Portability? TIA! INTERFACE Uerror; FROM Ctypes IMPORT int; (* CONST *) <*EXTERNAL "Uerror__EACCES"*> VAR EACCES: int; <*EXTERNAL "Uerror__EADDRINUSE"*> VAR EADDRINUSE: int; <*EXTERNAL "Uerror__EADDRNOTAVAIL"*> VAR EADDRNOTAVAIL: int; <*EXTERNAL "Uerror__EAGAIN"*> VAR EAGAIN: int; -- Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Tue May 19 23:32:24 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Tue, 19 May 2009 16:32:24 -0500 Subject: [M3devel] subrange value not constant? Message-ID: <4A132568.4060206@bellsouth.net> I've written this procedure (an implementation of counting sort): PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = VAR count := ARRAY [min..max] OF INTEGER {0, ..}; z := 0; BEGIN FOR i := FIRST(a) TO LAST(a) DO count[i - min] := count[i - min] + 1; END; FOR i := min TO max DO WHILE count[i - min] > 0 DO a[z] := i; INC(z); count[i - min] := count[i - min] - 1; END; END; END Sort; However, when I try to compile I get: "../Counting.m3", line 8: subrange lower bound is not constant "../Counting.m3", line 8: subrange upper bound is not constant Line 8 is: VAR count := ARRAY [min..max] OF INTEGER {0, ..}; I don't see what's wrong? From hosking at cs.purdue.edu Tue May 19 23:48:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 20 May 2009 07:48:34 +1000 Subject: [M3devel] subrange value not constant? In-Reply-To: <4A132568.4060206@bellsouth.net> References: <4A132568.4060206@bellsouth.net> Message-ID: <0D3047B2-96B1-464E-9774-A861ABF373B5@cs.purdue.edu> min is a variable argument to Sort. You should use an open array argument to Sort: ARRAY OF INTEGER. Modula-3 does not support alloca style of allocation. You need to allocate the count array in the heap. count := NEW(ARRAY OF INTEGER, NUMBER(a)). On 20 May 2009, at 07:32, Martin Bishop wrote: > I've written this procedure (an implementation of counting sort): > > PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = > VAR count := ARRAY [min..max] OF INTEGER {0, ..}; > z := 0; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > count[i - min] := count[i - min] + 1; > END; > FOR i := min TO max DO > WHILE count[i - min] > 0 DO > a[z] := i; > INC(z); > count[i - min] := count[i - min] - 1; > END; > END; > END Sort; > > However, when I try to compile I get: > > "../Counting.m3", line 8: subrange lower bound is not constant > "../Counting.m3", line 8: subrange upper bound is not constant > > Line 8 is: > > VAR count := ARRAY [min..max] OF INTEGER {0, ..}; > > I don't see what's wrong? From jay.krell at cornell.edu Tue May 19 23:37:12 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 19 May 2009 14:37:12 -0700 Subject: [M3devel] Probably missing too much of development sycle, but WTF? In-Reply-To: <1242754048.3061.1.camel@faramir.m3w.org> References: <1242754048.3061.1.camel@faramir.m3w.org> Message-ID: <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> Yes a little unfortunate but very portable. - Jay (phone) On May 19, 2009, at 10:27 AM, Dragi?a Duri? wrote: > VARIABLES? > > Now every1 who was using CASE with error results has to adapt one's > code? > > What is rationale here? Portability? > > TIA! > > INTERFACE Uerror; > > FROM Ctypes IMPORT int; > > (* CONST *) > <*EXTERNAL "Uerror__EACCES"*> VAR EACCES: int; > <*EXTERNAL "Uerror__EADDRINUSE"*> VAR EADDRINUSE: int; > <*EXTERNAL "Uerror__EADDRNOTAVAIL"*> VAR EADDRNOTAVAIL: int; > <*EXTERNAL "Uerror__EAGAIN"*> VAR EAGAIN: int; > > > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed May 20 00:59:18 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 19 May 2009 18:59:18 -0400 Subject: [M3devel] Probably missing too much of development sycle, but WTF? In-Reply-To: <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> Message-ID: <4A130147.1E75.00D7.1@scires.com> Why is this more portable than using constants? especially since it breaks existing code? --Randy >>> 5/19/2009 5:37 PM >>> Yes a little unfortunate but very portable. - Jay (phone) On May 19, 2009, at 10:27 AM, Dragi?a Duri* wrote: VARIABLES? Now every1 who was using CASE with error results has to adapt one's code? What is rationale here? Portability? TIA! INTERFACE Uerror; FROM Ctypes IMPORT int; (* CONST *) <*EXTERNAL "Uerror__EACCES"*> VAR EACCES: int; <*EXTERNAL "Uerror__EADDRINUSE"*> VAR EADDRINUSE: int; <*EXTERNAL "Uerror__EADDRNOTAVAIL"*> VAR EADDRNOTAVAIL: int; <*EXTERNAL "Uerror__EAGAIN"*> VAR EAGAIN: int; -- Dragi?a Duri* CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed May 20 01:05:49 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 19 May 2009 23:05:49 +0000 Subject: [M3devel] Probably missing too much of development sycle, but WTF? In-Reply-To: <4A130147.1E75.00D7.1@scires.com> References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> <4A130147.1E75.00D7.1@scires.com> Message-ID: It is portable to all target platforms. The approach with constants makes you have to "rewrite" Uerror.i3 for each target platform. Rewriting headers is tedious, error prone, and very dangerous. The approach with variables has just one implementation for all targets. This approach is much safer. I change the switch statements to if/elseif ladders. Yes it is less efficient, but it is also usually an error path. Yes it is source incompatible and I'm not happy about that, but I also like to keep platform specific code to a small minimum. It is a tradeoff. - Jay ________________________________ > Date: Tue, 19 May 2009 18:59:18 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Probably missing too much of development sycle, but WTF? > > > > > > > > Why is this more portable than using constants? especially since it breaks existing code? > > --Randy > >>>> 5/19/2009 5:37 PM>>> > > Yes a little unfortunate but very portable. > > - Jay (phone) > > > On May 19, 2009, at 10:27 AM, Dragi?a Duric> wrote: > > > > > VARIABLES? > > Now every1 who was using CASE with error results has to adapt one's code? > > What is rationale here? Portability? > > TIA! > > INTERFACE Uerror; > > FROM Ctypes IMPORT int; > > (* CONST *) > VAR EACCES: int; > VAR EADDRINUSE: int; > VAR EADDRNOTAVAIL: int; > VAR EAGAIN: int; > > > > > > > -- > Dragi?a Duric From jay.krell at cornell.edu Wed May 20 01:05:51 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 19 May 2009 23:05:51 +0000 Subject: [M3devel] Probably missing too much of development sycle, but WTF? In-Reply-To: <4A130147.1E75.00D7.1@scires.com> References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> <4A130147.1E75.00D7.1@scires.com> Message-ID: It is portable to all target platforms. The approach with constants makes you have to "rewrite" Uerror.i3 for each target platform. Rewriting headers is tedious, error prone, and very dangerous. The approach with variables has just one implementation for all targets. This approach is much safer. I change the switch statements to if/elseif ladders. Yes it is less efficient, but it is also usually an error path. Yes it is source incompatible and I'm not happy about that, but I also like to keep platform specific code to a small minimum. It is a tradeoff. - Jay ________________________________ > Date: Tue, 19 May 2009 18:59:18 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Probably missing too much of development sycle, but WTF? > > > > > > > > Why is this more portable than using constants? especially since it breaks existing code? > > --Randy > >>>> 5/19/2009 5:37 PM>>> > > Yes a little unfortunate but very portable. > > - Jay (phone) > > > On May 19, 2009, at 10:27 AM, Dragi?a Duric> wrote: > > > > > VARIABLES? > > Now every1 who was using CASE with error results has to adapt one's code? > > What is rationale here? Portability? > > TIA! > > INTERFACE Uerror; > > FROM Ctypes IMPORT int; > > (* CONST *) > VAR EACCES: int; > VAR EADDRINUSE: int; > VAR EADDRNOTAVAIL: int; > VAR EAGAIN: int; > > > > > > > -- > Dragi?a Duric From jay.krell at cornell.edu Wed May 20 01:14:36 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 19 May 2009 23:14:36 +0000 Subject: [M3devel] m3_load/store using bitfields for everything Message-ID: m3_load/store using bitfields for everything caused module-global references to disappear on MIPS64_OPENBSD (all MIPS?). I worked around that by declaring that the module-globals are at least of size 2 * biggest_alignment. It caused module-global references to disappear on ARM_DARWIN as well. I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't occur and PutChar eventually failed an array bounds check. Is this just too fragile and the failsafe form should always be used? Or, it fails spectacularly consistently enough that it must also be working consistently enough and leave it? Would "component ref" (ie: struct) and declaring more type information about module segments be a good compromise maybe? Probably. - Jay From hosking at cs.purdue.edu Wed May 20 02:23:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 20 May 2009 10:23:33 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: What optimization level are you using? I think what it comes down to is figuring out why the backend eliminates those globals and setting them up so it doesn't. There is usually some gcc incantation that will do the trick, but it often involves deep reading of the gcc source code. I am in the middle of that for the SOLgnu optimization failures (that we did not used to see until I upgraded to gcc 4.3.0 last year. I wonder if the TREE_THIS_VOLATILE bit is no longer sufficient. Can you see what happens if you replace that with m3_volatilize_decl instead? This was needed for the variables used in functions calling setjmp and may be necessary here too. On 20 May 2009, at 09:14, Jay wrote: > m3_load/store using bitfields for everything caused module-global > references to disappear on MIPS64_OPENBSD (all MIPS?). I worked > around that by declaring that the module-globals are at least of > size 2 * biggest_alignment. > > It caused module-global references to disappear on ARM_DARWIN as well. > I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't > occur and PutChar eventually failed an array bounds check. > > Is this just too fragile and the failsafe form should always be used? > > Or, it fails spectacularly consistently enough that it must also be > working consistently enough and leave it? > > Would "component ref" (ie: struct) and declaring more type > information about module segments be a good compromise maybe? > Probably. > > - Jay From jay.krell at cornell.edu Wed May 20 04:20:12 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 20 May 2009 02:20:12 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: This is with no optimization at all. I haven't tried replacing it with volatize. The problem on MIPS64_OPENBSD was the notion that bitfields fit in a register so any offset beyond a register was thrown out, or something. I do think a "component ref" would be appropriate, but don't know if it is a lot of work, to get the typeinfo through. - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: m3_load/store using bitfields for everything > Date: Wed, 20 May 2009 10:23:33 +1000 > > What optimization level are you using? > > I think what it comes down to is figuring out why the backend > eliminates those globals and setting them up so it doesn't. There is > usually some gcc incantation that will do the trick, but it often > involves deep reading of the gcc source code. > > I am in the middle of that for the SOLgnu optimization failures (that > we did not used to see until I upgraded to gcc 4.3.0 last year. I > wonder if the TREE_THIS_VOLATILE bit is no longer sufficient. Can you > see what happens if you replace that with m3_volatilize_decl instead? > This was needed for the variables used in functions calling setjmp and > may be necessary here too. > > On 20 May 2009, at 09:14, Jay wrote: > >> m3_load/store using bitfields for everything caused module-global >> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >> around that by declaring that the module-globals are at least of >> size 2 * biggest_alignment. >> >> It caused module-global references to disappear on ARM_DARWIN as well. >> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >> occur and PutChar eventually failed an array bounds check. >> >> Is this just too fragile and the failsafe form should always be used? >> >> Or, it fails spectacularly consistently enough that it must also be >> working consistently enough and leave it? >> >> Would "component ref" (ie: struct) and declaring more type >> information about module segments be a good compromise maybe? >> Probably. >> >> - Jay > From hosking at cs.purdue.edu Wed May 20 05:03:54 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 20 May 2009 13:03:54 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: I'm working on it. On 20 May 2009, at 12:20, Jay wrote: > > This is with no optimization at all. > > I haven't tried replacing it with volatize. > The problem on MIPS64_OPENBSD was the notion that bitfields fit in a > register so any offset beyond a register was thrown out, or something. > > I do think a "component ref" would be appropriate, but don't know if > it is a lot of work, to get the typeinfo through. > > - Jay > > ---------------------------------------- >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: m3_load/store using bitfields for everything >> Date: Wed, 20 May 2009 10:23:33 +1000 >> >> What optimization level are you using? >> >> I think what it comes down to is figuring out why the backend >> eliminates those globals and setting them up so it doesn't. There is >> usually some gcc incantation that will do the trick, but it often >> involves deep reading of the gcc source code. >> >> I am in the middle of that for the SOLgnu optimization failures (that >> we did not used to see until I upgraded to gcc 4.3.0 last year. I >> wonder if the TREE_THIS_VOLATILE bit is no longer sufficient. Can you >> see what happens if you replace that with m3_volatilize_decl instead? >> This was needed for the variables used in functions calling setjmp >> and >> may be necessary here too. >> >> On 20 May 2009, at 09:14, Jay wrote: >> >>> m3_load/store using bitfields for everything caused module-global >>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >>> around that by declaring that the module-globals are at least of >>> size 2 * biggest_alignment. >>> >>> It caused module-global references to disappear on ARM_DARWIN as >>> well. >>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >>> occur and PutChar eventually failed an array bounds check. >>> >>> Is this just too fragile and the failsafe form should always be >>> used? >>> >>> Or, it fails spectacularly consistently enough that it must also be >>> working consistently enough and leave it? >>> >>> Would "component ref" (ie: struct) and declaring more type >>> information about module segments be a good compromise maybe? >>> Probably. >>> >>> - Jay >> From dragisha at m3w.org Wed May 20 07:41:34 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 20 May 2009 07:41:34 +0200 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> Message-ID: <1242798094.3061.7.camel@faramir.m3w.org> Then please be complete :) AF_UNIX is missing, and also stuct_sockaddr_un structure. Yes I know how to add it. Yes you're pretty radical these days, so please do it your way so you don't have to edit my patch :) Also - you maybe remember make_dir problem I've reported few months (?) ago... I've narrowed it to situation where my earlier patch sets CM3_INSTALL_PREFIX. It started to happen some months after I patched it, and it happens only when shipping m3core. On Tue, 2009-05-19 at 14:37 -0700, jay.krell at cornell.edu wrote: > Yes a little unfortunate but very portable. > > - Jay (phone) > > On May 19, 2009, at 10:27 AM, Dragi?a Duri? wrote: > > > > > VARIABLES? > > > > Now every1 who was using CASE with error results has to adapt one's > > code? > > > > What is rationale here? Portability? > > > > TIA! > > > > INTERFACE Uerror; > > > > FROM Ctypes IMPORT int; > > > > (* CONST *) > > <*EXTERNAL "Uerror__EACCES"*> VAR EACCES: int; > > <*EXTERNAL "Uerror__EADDRINUSE"*> VAR EADDRINUSE: int; > > <*EXTERNAL "Uerror__EADDRNOTAVAIL"*> VAR EADDRNOTAVAIL: int; > > <*EXTERNAL "Uerror__EAGAIN"*> VAR EAGAIN: int; > > > > > > -- > > Dragi?a Duri? -- Dragi?a Duri? From jay.krell at cornell.edu Wed May 20 08:33:52 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 20 May 2009 06:33:52 +0000 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: <1242798094.3061.7.camel@faramir.m3w.org> References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> <1242798094.3061.7.camel@faramir.m3w.org> Message-ID: > AF_UNIX I'll try to make another pass through and put back unused constants, I guess. At some point I erred toward removing unused stuff, because everything present was a correctness and portability issue. Though I mainly only did such removal with Cygwin, on the basis of it never really existing as a port so the initial version could be minimal. I think, maybe I removed other? I also removed userthread support from PPC_LINUX and maybe NetBSD/i386. It was broken for all platforms and remains so for all Linux platforms. Later I developed more portable techniques so it becomes more acceptable to leave stuff in, but convert it to be correct and portable. Constants are easy. > stuct_sockaddr_un structure Structs though are problematic. You end up wanting to wrap all the functions that use them. Unless they are large structs and then you don't want the waste and you are either stuck, or you maybe wrap at the next level up. This is an area actually where we still clone the headers, still work to do to make it portable and safe. > make_dir No I had forgotten but I see it searching the web. You need the dots smushed out? - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Wed, 20 May 2009 07:41:34 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? > > Then please be complete :) > > AF_UNIX is missing, and also stuct_sockaddr_un structure. > > Yes I know how to add it. Yes you're pretty radical these days, so > please do it your way so you don't have to edit my patch :) > > Also - you maybe remember make_dir problem I've reported few months (?) > ago... I've narrowed it to situation where my earlier patch sets > CM3_INSTALL_PREFIX. It started to happen some months after I patched it, > and it happens only when shipping m3core. > > On Tue, 2009-05-19 at 14:37 -0700, jay.krell at cornell.edu wrote: >> Yes a little unfortunate but very portable. >> >> - Jay (phone) >> >> On May 19, 2009, at 10:27 AM, Dragi?a Duri? wrote: >> >> >> >>> VARIABLES? >>> >>> Now every1 who was using CASE with error results has to adapt one's >>> code? >>> >>> What is rationale here? Portability? >>> >>> TIA! >>> >>> INTERFACE Uerror; >>> >>> FROM Ctypes IMPORT int; >>> >>> (* CONST *) >>> VAR EACCES: int; >>> VAR EADDRINUSE: int; >>> VAR EADDRNOTAVAIL: int; >>> VAR EAGAIN: int; >>> >>> >>> -- >>> Dragi?a Duri? > -- > Dragi?a Duri? > From jay.krell at cornell.edu Wed May 20 08:38:34 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 20 May 2009 06:38:34 +0000 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> <1242798094.3061.7.camel@faramir.m3w.org> Message-ID: Oops, I guess it is the switch to the new headers (m3core/src/unix/Comon/*.i3) that causes the removal of unused stuff. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: dragisha at m3w.org > Date: Wed, 20 May 2009 06:33:52 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? > > >> AF_UNIX > > > I'll try to make another pass through and put back unused constants, I guess. > > > At some point I erred toward removing unused stuff, because everything present was a correctness and portability issue. > > Though I mainly only did such removal with Cygwin, on the basis of it never really existing as a port so the initial version could be minimal. > I think, maybe I removed other? > I also removed userthread support from PPC_LINUX and maybe NetBSD/i386. > It was broken for all platforms and remains so for all Linux platforms. > > > Later I developed more portable techniques so it becomes more acceptable to leave stuff in, but convert it to be correct and portable. > > > Constants are easy. > > >> stuct_sockaddr_un structure > > > Structs though are problematic. > You end up wanting to wrap all the functions that use them. > Unless they are large structs and then you don't want the waste and you are either stuck, or you maybe wrap at the next level up. > > > This is an area actually where we still clone the headers, still work to do to make it portable and safe. > > >> make_dir > > > No I had forgotten but I see it searching the web. > You need the dots smushed out? > > > - Jay > > > > ---------------------------------------- >> From: dragisha at m3w.org >> To: jay.krell at cornell.edu >> Date: Wed, 20 May 2009 07:41:34 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? >> >> Then please be complete :) >> >> AF_UNIX is missing, and also stuct_sockaddr_un structure. >> >> Yes I know how to add it. Yes you're pretty radical these days, so >> please do it your way so you don't have to edit my patch :) >> >> Also - you maybe remember make_dir problem I've reported few months (?) >> ago... I've narrowed it to situation where my earlier patch sets >> CM3_INSTALL_PREFIX. It started to happen some months after I patched it, >> and it happens only when shipping m3core. >> >> On Tue, 2009-05-19 at 14:37 -0700, jay.krell at cornell.edu wrote: >>> Yes a little unfortunate but very portable. >>> >>> - Jay (phone) >>> >>> On May 19, 2009, at 10:27 AM, Dragi?a Duri? wrote: >>> >>> >>> >>>> VARIABLES? >>>> >>>> Now every1 who was using CASE with error results has to adapt one's >>>> code? >>>> >>>> What is rationale here? Portability? >>>> >>>> TIA! >>>> >>>> INTERFACE Uerror; >>>> >>>> FROM Ctypes IMPORT int; >>>> >>>> (* CONST *) >>>> VAR EACCES: int; >>>> VAR EADDRINUSE: int; >>>> VAR EADDRNOTAVAIL: int; >>>> VAR EAGAIN: int; >>>> >>>> >>>> -- >>>> Dragi?a Duri? >> -- >> Dragi?a Duri? >> From mika at async.caltech.edu Wed May 20 08:44:08 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 19 May 2009 23:44:08 -0700 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: Your message of "Wed, 20 May 2009 06:33:52 -0000." Message-ID: <200905200644.n4K6i8x5088520@camembert.async.caltech.edu> These things are constant for a given binary distribution, aren't they? Can they be left to some sort of bootstrapping step on the target system, or at least (if cross-compiling) in an environment where target C headers are available? I mean printing out an M3 interface based on the C header's defined values. Mika Jay writes: > >> AF_UNIX > > >I'll try to make another pass through and put back unused constants, I guess. > > >At some point I erred toward removing unused stuff, because everything present was a correctness and portability issue. > >Though I mainly only did such removal with Cygwin, on the basis of it never really existing as a port so the initial version could be minimal. >I think, maybe I removed other? >I also removed userthread support from PPC_LINUX and maybe NetBSD/i386. >It was broken for all platforms and remains so for all Linux platforms. > > >Later I developed more portable techniques so it becomes more acceptable to leave stuff in, but convert it to be correct and portable. > > >Constants are easy. > > >> stuct_sockaddr_un structure > > >Structs though are problematic. >You end up wanting to wrap all the functions that use them. >Unless they are large structs and then you don't want the waste and you are either stuck, or you maybe wrap at the next level up. > > >This is an area actually where we still clone the headers, still work to do to make it portable and safe. > > >> make_dir > > >No I had forgotten but I see it searching the web. >You need the dots smushed out? > > > - Jay > > > >---------------------------------------- >> From: dragisha at m3w.org >> To: jay.krell at cornell.edu >> Date: Wed, 20 May 2009 07:41:34 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? >> >> Then please be complete :) >> >> AF_UNIX is missing, and also stuct_sockaddr_un structure. >> >> Yes I know how to add it. Yes you're pretty radical these days, so >> please do it your way so you don't have to edit my patch :) >> >> Also - you maybe remember make_dir problem I've reported few months (?) >> ago... I've narrowed it to situation where my earlier patch sets >> CM3_INSTALL_PREFIX. It started to happen some months after I patched it, >> and it happens only when shipping m3core. >> >> On Tue, 2009-05-19 at 14:37 -0700, jay.krell at cornell.edu wrote: >>> Yes a little unfortunate but very portable. >>> >>> - Jay (phone) >>> >>> On May 19, 2009, at 10:27 AM, Dragi?a Duri? wrote: >> >>> >>> >>>> VARIABLES? >>>> >>>> Now every1 who was using CASE with error results has to adapt one's >>>> code? >>>> >>>> What is rationale here? Portability? >>>> >>>> TIA! >>>> >>>> INTERFACE Uerror; >>>> >>>> FROM Ctypes IMPORT int; >>>> >>>> (* CONST *) >>>> VAR EACCES: int; >>>> VAR EADDRINUSE: int; >>>> VAR EADDRNOTAVAIL: int; >>>> VAR EAGAIN: int; >>>> >>>> >>>> -- >>>> Dragi?a Duri? >> -- >> Dragi?a Duri? >> From dragisha at m3w.org Wed May 20 08:48:52 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 20 May 2009 08:48:52 +0200 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> <1242798094.3061.7.camel@faramir.m3w.org> Message-ID: <1242802132.3061.9.camel@faramir.m3w.org> On Wed, 2009-05-20 at 06:33 +0000, Jay wrote: > > stuct_sockaddr_un structure > > > Structs though are problematic. > You end up wanting to wrap all the functions that use them. > Unless they are large structs and then you don't want the waste and > you are either stuck, or you maybe wrap at the next level up. > This struct uses same headers as struct_sockaddr_in - it's easy one. > > This is an area actually where we still clone the headers, still work > to do to make it portable and safe. > > > > make_dir > > > No I had forgotten but I see it searching the web. > You need the dots smushed out? I think so. I am out of cycle there, can you debug it with CM3_INSTALL_PREFIX set before buildship m3core? That is my problem case, narrowed as much as possible till now. > > -- Dragi?a Duri? From dragisha at m3w.org Wed May 20 08:50:26 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 20 May 2009 08:50:26 +0200 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: <200905200644.n4K6i8x5088520@camembert.async.caltech.edu> References: <200905200644.n4K6i8x5088520@camembert.async.caltech.edu> Message-ID: <1242802226.3061.11.camel@faramir.m3w.org> This is nice idea, but I think it means much more C code than current Uconstants... Actually, I like new approach. It's only it's (in)completeness that disturbs me :) On Tue, 2009-05-19 at 23:44 -0700, Mika Nystrom wrote: > These things are constant for a given binary distribution, aren't > they? Can they be left to some sort of bootstrapping step on the > target system, or at least (if cross-compiling) in an environment > where target C headers are available? > > I mean printing out an M3 interface based on the C header's defined > values. > > Mika -- Dragi?a Duri? From jay.krell at cornell.edu Wed May 20 09:21:40 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 20 May 2009 07:21:40 +0000 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: <1242802226.3061.11.camel@faramir.m3w.org> References: <200905200644.n4K6i8x5088520@camembert.async.caltech.edu> <1242802226.3061.11.camel@faramir.m3w.org> Message-ID: I think it's a similar amount of code. One is full of: printf("CONST FOO := %u\n", FOO); the other is: extern const int Interface__Foo = FOO; Both probably easily well factored with macros to like X(int,Interface,FOO) I don't know. Would the generated files get commited, or regenerated in every build? They'd need to be commited for cross builds. Or maybe fallback to a variable approach, with its source incompat. They should be regenerated to make sure they are correct. Maybe both? Regenerate them in native builds and compare for equality with the commited copy, and error if they vary? But again, it is easier for constants. You do need to devise a system to glean struct definitions. Or to verify the correctness of ones that you have. They don't have to be perfectly accurate. For example, you can use arrays of bytes for padding for fields whose presence you didn't anticipate. It'd be good to get alignment correct. That was sometimes wrong in the old system. But for stuff individuall heap allocated, no matter. It's probably not too difficult. Something like store the size/offset of every known field of a struct. Sort them by offset. Fill in padding when offset+size doesn't equal the next offset. In C you can pick integer types accurately enough by size and signedness, picking arbitrarily when any types are the "same". Using C++ overloading you can do better. I put some experiments here in scripts/config, and if you look through some of the history in m3core/src/unix you can see other simpler examples. It's a bit of a dilemna. But I also really didn't like the way it is. New platforms involved rewriting /usr/include, tedious, error prone, unsafe, and even mostly unused -- for all the parts I removed that people want back, there's probably a few times that much content I removed and nobody noticed. Actually it's even a little worse than I said. It isn't enough to get constants and structs. There's a real larger generality of inlines and I think #pragmas. Look at NetBSD. I think they use #pragmas to give everything an explicit and different name. stat is also notoriously complicated. C headers seem to provide far more of a common "source interface" than a common "binary appearance" (I don't call it "interface" since for example there is endian, calling convention, processor architecture..) - Jay ---------------------------------------- > From: dragisha at m3w.org > To: mika at async.caltech.edu > Date: Wed, 20 May 2009 08:50:26 +0200 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? > > This is nice idea, but I think it means much more C code than current > Uconstants... > > Actually, I like new approach. It's only it's (in)completeness that > disturbs me :) > > On Tue, 2009-05-19 at 23:44 -0700, Mika Nystrom wrote: >> These things are constant for a given binary distribution, aren't >> they? Can they be left to some sort of bootstrapping step on the >> target system, or at least (if cross-compiling) in an environment >> where target C headers are available? >> >> I mean printing out an M3 interface based on the C header's defined >> values. >> >> Mika > -- > Dragi?a Duri? > From martinbishop at bellsouth.net Thu May 21 01:19:57 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Wed, 20 May 2009 18:19:57 -0500 Subject: [M3devel] subrange value not constant? In-Reply-To: <4A132568.4060206@bellsouth.net> References: <4A132568.4060206@bellsouth.net> Message-ID: <4A14901D.7090106@bellsouth.net> By the way, in case anyone cares, here's the proper code: PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = VAR range := max - min + 1; count := NEW(REF ARRAY OF INTEGER, range); z := 0; BEGIN FOR i := FIRST(a) TO LAST(a) DO count[a[i] - min] := count[a[i] - min] + 1; END; FOR i := min TO max DO WHILE (count[i - min] > 0) DO a[z] := i; INC(z); count[i - min] := count[i - min] - 1; END; END; END Sort; Martin Bishop wrote: > I've written this procedure (an implementation of counting sort): > > PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = > VAR count := ARRAY [min..max] OF INTEGER {0, ..}; > z := 0; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > count[i - min] := count[i - min] + 1; > END; > FOR i := min TO max DO > WHILE count[i - min] > 0 DO > a[z] := i; > INC(z); > count[i - min] := count[i - min] - 1; > END; > END; > END Sort; > > However, when I try to compile I get: > > "../Counting.m3", line 8: subrange lower bound is not constant > "../Counting.m3", line 8: subrange upper bound is not constant > > Line 8 is: > > VAR count := ARRAY [min..max] OF INTEGER {0, ..}; > > I don't see what's wrong? > > From mika at async.caltech.edu Thu May 21 07:27:43 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 20 May 2009 22:27:43 -0700 Subject: [M3devel] subrange value not constant? In-Reply-To: Your message of "Wed, 20 May 2009 18:19:57 CDT." <4A14901D.7090106@bellsouth.net> Message-ID: <200905210527.n4L5Rhwg038846@camembert.async.caltech.edu> Martin, you have one bug: you don't initialize count. Per 2.6.9 in the Green Book, NEW returns "an arbitrary value of its type" Also, for slightly more clarity, count can be a REF ARRAY OF CARDINAL. INC and DEC would make the code a bit easier to read, perhaps. Finally, you can dispense with min and max completely by just using min, initialized to a[0], and re-allocating the array whenever the new value is greater than min + NUMBER(count^) :-) But maybe you already know what min and max are by some means that doesn't involve scanning the array. Mika Martin Bishop writes: >By the way, in case anyone cares, here's the proper code: > >PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = > VAR range := max - min + 1; > count := NEW(REF ARRAY OF INTEGER, range); > z := 0; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > count[a[i] - min] := count[a[i] - min] + 1; > END; > FOR i := min TO max DO > WHILE (count[i - min] > 0) DO > a[z] := i; > INC(z); > count[i - min] := count[i - min] - 1; > END; > END; > END Sort; > >Martin Bishop wrote: >> I've written this procedure (an implementation of counting sort): >> >> PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >> z := 0; >> BEGIN >> FOR i := FIRST(a) TO LAST(a) DO >> count[i - min] := count[i - min] + 1; >> END; >> FOR i := min TO max DO >> WHILE count[i - min] > 0 DO >> a[z] := i; >> INC(z); >> count[i - min] := count[i - min] - 1; >> END; >> END; >> END Sort; >> >> However, when I try to compile I get: >> >> "../Counting.m3", line 8: subrange lower bound is not constant >> "../Counting.m3", line 8: subrange upper bound is not constant >> >> Line 8 is: >> >> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >> >> I don't see what's wrong? >> >> From jay.krell at cornell.edu Thu May 21 08:43:56 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 21 May 2009 06:43:56 +0000 Subject: [M3devel] subrange value not constant? In-Reply-To: <200905210527.n4L5Rhwg038846@camembert.async.caltech.edu> References: Your message of "Wed, 20 May 2009 18:19:57 CDT." <4A14901D.7090106@bellsouth.net> <200905210527.n4L5Rhwg038846@camembert.async.caltech.edu> Message-ID: INC and DEC? Oh for += and -=. It's not just clarity though, it is also to avoid the cost of evaluating the expression twice. - Jay ---------------------------------------- > To: martinbishop at bellsouth.net > Date: Wed, 20 May 2009 22:27:43 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] subrange value not constant? > > > Martin, you have one bug: you don't initialize count. Per 2.6.9 in the > Green Book, NEW returns "an arbitrary value of its type" > > Also, for slightly more clarity, count can be a REF ARRAY OF CARDINAL. > > INC and DEC would make the code a bit easier to read, perhaps. > > Finally, you can dispense with min and max completely by just using > min, initialized to a[0], and re-allocating the array whenever the > new value is greater than min + NUMBER(count^) :-) But maybe you > already know what min and max are by some means that doesn't involve > scanning the array. > > Mika > > > > > Martin Bishop writes: >>By the way, in case anyone cares, here's the proper code: >> >>PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >> VAR range := max - min + 1; >> count := NEW(REF ARRAY OF INTEGER, range); >> z := 0; >> BEGIN >> FOR i := FIRST(a) TO LAST(a) DO >> count[a[i] - min] := count[a[i] - min] + 1; >> END; >> FOR i := min TO max DO >> WHILE (count[i - min]> 0) DO >> a[z] := i; >> INC(z); >> count[i - min] := count[i - min] - 1; >> END; >> END; >> END Sort; >> >>Martin Bishop wrote: >>> I've written this procedure (an implementation of counting sort): >>> >>> PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >>> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >>> z := 0; >>> BEGIN >>> FOR i := FIRST(a) TO LAST(a) DO >>> count[i - min] := count[i - min] + 1; >>> END; >>> FOR i := min TO max DO >>> WHILE count[i - min]> 0 DO >>> a[z] := i; >>> INC(z); >>> count[i - min] := count[i - min] - 1; >>> END; >>> END; >>> END Sort; >>> >>> However, when I try to compile I get: >>> >>> "../Counting.m3", line 8: subrange lower bound is not constant >>> "../Counting.m3", line 8: subrange upper bound is not constant >>> >>> Line 8 is: >>> >>> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >>> >>> I don't see what's wrong? >>> >>> From mika at async.caltech.edu Thu May 21 09:34:48 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 21 May 2009 00:34:48 -0700 Subject: [M3devel] subrange value not constant? In-Reply-To: Your message of "Thu, 21 May 2009 06:43:56 -0000." Message-ID: <200905210734.n4L7YmIA043161@camembert.async.caltech.edu> In general you're right but often, such expressions generate precisely the same assembly on my machine, so I think it's mostly a clarity issue. I don't even have to use -O. Hmm, it's possible this is only true if the compiler can statically determine that the range checks are OK. The range checks inserted by cm3 seem to inhibit the optimization (i.e., the range checks are carried out for every "evaluation"). Mika (226)rover:~/src>cat P.m3 MODULE P EXPORTS Main; VAR x : ARRAY [0..10] OF INTEGER; PROCEDURE P() = BEGIN INC(x[5]) END P; PROCEDURE Q() = BEGIN x[5] := x[5]+1 END Q; BEGIN END P. (227)rover:~/src>cm3 --- building in ../FreeBSD4 --- new source -> compiling P.m3 "../src/P.m3", line 5: warning: not used (P) "../src/P.m3", line 8: warning: not used (Q) 2 warnings encountered new "P.mo" -> linking prog (228)rover:~/src>objdump --disassemble ../FreeBSD4/P.mo ../FreeBSD4/P.mo: file format elf32-i386-freebsd Disassembly of section .text: 00000000 : 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: a1 88 00 00 00 mov 0x88,%eax 8: 8d 50 01 lea 0x1(%eax),%edx b: a1 88 00 00 00 mov 0x88,%eax 10: 83 e0 00 and $0x0,%eax 13: 09 d0 or %edx,%eax 15: a3 88 00 00 00 mov %eax,0x88 1a: 5d pop %ebp 1b: c3 ret 0000001c : 1c: 55 push %ebp 1d: 89 e5 mov %esp,%ebp 1f: a1 88 00 00 00 mov 0x88,%eax 24: 8d 50 01 lea 0x1(%eax),%edx 27: a1 88 00 00 00 mov 0x88,%eax 2c: 83 e0 00 and $0x0,%eax 2f: 09 d0 or %edx,%eax 31: a3 88 00 00 00 mov %eax,0x88 36: 5d pop %ebp 37: c3 ret 00000038 : 38: 55 push %ebp 39: 89 e5 mov %esp,%ebp 3b: 83 ec 04 sub $0x4,%esp 3e: 8b 45 08 mov 0x8(%ebp),%eax 41: b8 40 00 00 00 mov $0x40,%eax 46: c9 leave 47: c3 ret Jay writes: > >INC and DEC? >Oh for += and -=. > >It's not just clarity though, it is also to avoid the cost of evaluating the expression twice. > > - Jay > > >---------------------------------------- >> To: martinbishop at bellsouth.net >> Date: Wed, 20 May 2009 22:27:43 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] subrange value not constant? >> >> >> Martin, you have one bug: you don't initialize count. Per 2.6.9 in the >> Green Book, NEW returns "an arbitrary value of its type" >> >> Also, for slightly more clarity, count can be a REF ARRAY OF CARDINAL. >> >> INC and DEC would make the code a bit easier to read, perhaps. >> >> Finally, you can dispense with min and max completely by just using >> min, initialized to a[0], and re-allocating the array whenever the >> new value is greater than min + NUMBER(count^) :-) But maybe you >> already know what min and max are by some means that doesn't involve >> scanning the array. >> >> Mika >> >> >> >> >> Martin Bishop writes: >>>By the way, in case anyone cares, here's the proper code: >>> >>>PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >>> VAR range := max - min + 1; >>> count := NEW(REF ARRAY OF INTEGER, range); >>> z := 0; >>> BEGIN >>> FOR i := FIRST(a) TO LAST(a) DO >>> count[a[i] - min] := count[a[i] - min] + 1; >>> END; >>> FOR i := min TO max DO >>> WHILE (count[i - min]> 0) DO >>> a[z] := i; >>> INC(z); >>> count[i - min] := count[i - min] - 1; >>> END; >>> END; >>> END Sort; >>> >>>Martin Bishop wrote: >>>> I've written this procedure (an implementation of counting sort): >>>> >>>> PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >>>> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >>>> z := 0; >>>> BEGIN >>>> FOR i := FIRST(a) TO LAST(a) DO >>>> count[i - min] := count[i - min] + 1; >>>> END; >>>> FOR i := min TO max DO >>>> WHILE count[i - min]> 0 DO >>>> a[z] := i; >>>> INC(z); >>>> count[i - min] := count[i - min] - 1; >>>> END; >>>> END; >>>> END Sort; >>>> >>>> However, when I try to compile I get: >>>> >>>> "../Counting.m3", line 8: subrange lower bound is not constant >>>> "../Counting.m3", line 8: subrange upper bound is not constant >>>> >>>> Line 8 is: >>>> >>>> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >>>> >>>> I don't see what's wrong? >>>> >>>> From martinbishop at bellsouth.net Thu May 21 20:08:13 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 21 May 2009 13:08:13 -0500 Subject: [M3devel] subrange value not constant? In-Reply-To: <200905210527.n4L5Rhwg038846@camembert.async.caltech.edu> References: <200905210527.n4L5Rhwg038846@camembert.async.caltech.edu> Message-ID: <4A15988D.7030305@bellsouth.net> Hmm, good point about count. Originally I did initialize to 0, but in the process of trying to get it to work, I must have removed it. As for min and max, yes the point of the Counting Sort (http://en.wikipedia.org/wiki/Counting_sort) is that min and max are known. Thanks for the help :) Mika Nystrom wrote: > Martin, you have one bug: you don't initialize count. Per 2.6.9 in the > Green Book, NEW returns "an arbitrary value of its type" > > Also, for slightly more clarity, count can be a REF ARRAY OF CARDINAL. > > INC and DEC would make the code a bit easier to read, perhaps. > > Finally, you can dispense with min and max completely by just using > min, initialized to a[0], and re-allocating the array whenever the > new value is greater than min + NUMBER(count^) :-) But maybe you > already know what min and max are by some means that doesn't involve > scanning the array. > > Mika > > > > > Martin Bishop writes: > >> By the way, in case anyone cares, here's the proper code: >> >> PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >> VAR range := max - min + 1; >> count := NEW(REF ARRAY OF INTEGER, range); >> z := 0; >> BEGIN >> FOR i := FIRST(a) TO LAST(a) DO >> count[a[i] - min] := count[a[i] - min] + 1; >> END; >> FOR i := min TO max DO >> WHILE (count[i - min] > 0) DO >> a[z] := i; >> INC(z); >> count[i - min] := count[i - min] - 1; >> END; >> END; >> END Sort; >> >> Martin Bishop wrote: >> >>> I've written this procedure (an implementation of counting sort): >>> >>> PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >>> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >>> z := 0; >>> BEGIN >>> FOR i := FIRST(a) TO LAST(a) DO >>> count[i - min] := count[i - min] + 1; >>> END; >>> FOR i := min TO max DO >>> WHILE count[i - min] > 0 DO >>> a[z] := i; >>> INC(z); >>> count[i - min] := count[i - min] - 1; >>> END; >>> END; >>> END Sort; >>> >>> However, when I try to compile I get: >>> >>> "../Counting.m3", line 8: subrange lower bound is not constant >>> "../Counting.m3", line 8: subrange upper bound is not constant >>> >>> Line 8 is: >>> >>> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >>> >>> I don't see what's wrong? >>> >>> >>> > > From mika at async.caltech.edu Thu May 21 20:39:57 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 21 May 2009 11:39:57 -0700 Subject: [M3devel] subrange value not constant? In-Reply-To: Your message of "Thu, 21 May 2009 13:08:13 CDT." <4A15988D.7030305@bellsouth.net> Message-ID: <200905211839.n4LIdv8W068308@camembert.async.caltech.edu> Martin Bishop writes: >Hmm, good point about count. Originally I did initialize to 0, but in >the process of trying to get it to work, I must have removed it. > >As for min and max, yes the point of the Counting Sort >(http://en.wikipedia.org/wiki/Counting_sort) is that min and max are known. > >Thanks for the help :) Well what I mean is this. Assume you know that counting sort is appropriate for your data, i.e., that n + k <= n log n for the data in question (using Wikipedia's notation). There are two approaches I can think of for implementing the sort. 1. Figure out min and max before calling Sort, by a linear scan, or some other mechanism. If this mechanism adds any code at all, it's likely to add O(n) runtime to the algorithm (because you are making it look at every element before it goes in). 2. Dispense with min and max and instead generate these dynamically within the sort. Initialize them to the first element, and re-allocate the array when you see any element outside the current range. This approach also has O(n) (amortized) cost. So you'd do, say, PROCEDURE Sort(VAR a : ARRAY OF INTEGER) = PROCEDURE ReLimit(newmin, newmax : INTEGER) = BEGIN WITH newcount = NEW(REF ARRAY OF CARDINAL, newmax - newmin + 1) DO FOR i := FIRST(newcount^) TO min-newmin-1 DO newcount[i] := 0 END; FOR i := newmax-max TO LAST(newcount^) DO newcount[i] := 0 END; SUBARRAY(newcount^, min-newmin, max-min+1) := count^; END; count := newcount; min := newmin; max := newmax END ReLimit; PROCEDURE Tally(v : INTEGER) = CONST GrowFactor = 2; BEGIN IF v < min THEN ReLimit(min-(min-v)*GrowFactor, max) ELSIF v > max THEN ReLimit(min, max+(v-max)*GrowFactor) END; INC(count[v-min]) END Tally; PROCEDURE Initialize() = BEGIN min := a[0]; max := a[0]; count := NEW(REF ARRAY OF CARDINAL, 1); END Initialize; PROCEDURE Reconstruct() = VAR ai := FIRST(a); BEGIN FOR i := FIRST(count^) TO LAST(count^) DO WHILE count[i] > 0 DO a[ai] := i+min; DEC(count[i]); INC(ai) END END END Reconstruct; VAR min, max : INTEGER; count : REF ARRAY OF INTEGER; BEGIN Initialize(); FOR i := FIRST(a) TO LAST(a) DO Tally(a[i]) END; Reconstruct() END Sort; The asymptotic runtime of this version is the same as yours and it encapsulates all the min, max knowledge, giving a simpler interface, and it usually means you can remove some min, max code from the caller. Modula-3 is really good for this sort of coding. I find that the extra effort of simplifying interfaces and making sure the code works for any input is paid off handsomely and very quickly... As it says in the Algol-60 report, the code above "has not been run on a computer". Mika From jay.krell at cornell.edu Fri May 22 02:09:46 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 22 May 2009 00:09:46 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: Yes I will test some variations, esp. targets not historically affected by the bitfield behavior but that haven't passed -O3 yet, since they are easier for a few reasons and more numerous (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.) ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I haven't booted the machine in months and it is very slow (my /plan/ is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX}, but it's slow going, I had difficulty installing some of them, only got Irix and OpenBSD running, and some of those combinations are invalid e.g. MIPS32_OPENBSD -- OpenBSD never has "biarch" systems, only ever pure 32bit or pure 64bit). Moving ARM_DARWIN forward to 4.3 isn't impossible but I think easier to track and wait for Apple here than anything else. I ran an AMD64_LINUX test on birch but didn't wait for it. SPARC32_LINUX also has a wierd problem that I can retest. When I compile with -fPIC I get I think crashes during initialization. I haven't figured out the problem. Without -fPIC works ok, even for shared libraries, surprising. - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: m3_load/store using bitfields for everything > Date: Fri, 22 May 2009 09:45:08 +1000 > > Jay, can you try these again with the latest fix I put in place? > > On 20 May 2009, at 09:14, Jay wrote: > >> >> m3_load/store using bitfields for everything caused module-global >> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >> around that by declaring that the module-globals are at least of >> size 2 * biggest_alignment. >> >> It caused module-global references to disappear on ARM_DARWIN as well. >> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >> occur and PutChar eventually failed an array bounds check. >> >> Is this just too fragile and the failsafe form should always be used? >> >> Or, it fails spectacularly consistently enough that it must also be >> working consistently enough and leave it? >> >> Would "component ref" (ie: struct) and declaring more type >> information about module segments be a good compromise maybe? >> Probably. >> >> - Jay > From hosking at cs.purdue.edu Fri May 22 01:45:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 22 May 2009 09:45:08 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: Jay, can you try these again with the latest fix I put in place? On 20 May 2009, at 09:14, Jay wrote: > > m3_load/store using bitfields for everything caused module-global > references to disappear on MIPS64_OPENBSD (all MIPS?). I worked > around that by declaring that the module-globals are at least of > size 2 * biggest_alignment. > > It caused module-global references to disappear on ARM_DARWIN as well. > I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't > occur and PutChar eventually failed an array bounds check. > > Is this just too fragile and the failsafe form should always be used? > > Or, it fails spectacularly consistently enough that it must also be > working consistently enough and leave it? > > Would "component ref" (ie: struct) and declaring more type > information about module segments be a good compromise maybe? > Probably. > > - Jay From hosking at cs.purdue.edu Fri May 22 03:18:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 22 May 2009 11:18:05 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> PPC_DARWIN did work for me at one point. I can check it. On 22 May 2009, at 10:09, Jay wrote: > > Yes I will test some variations, esp. targets not historically > affected by the bitfield behavior but that haven't passed -O3 yet, > since they are easier for a few reasons and more numerous > (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.) > > > ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I > haven't booted the machine in months and it is very slow (my /plan/ > is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX}, but it's > slow going, I had difficulty installing some of them, only got Irix > and OpenBSD running, and some of those combinations are invalid e.g. > MIPS32_OPENBSD -- OpenBSD never > has "biarch" systems, only ever pure 32bit or pure 64bit). > > > Moving ARM_DARWIN forward to 4.3 isn't impossible but I think easier > to track and wait for Apple here than anything else. > > > I ran an AMD64_LINUX test on birch but didn't wait for it. > > > SPARC32_LINUX also has a wierd problem that I can retest. > When I compile with -fPIC I get I think crashes during initialization. > I haven't figured out the problem. > Without -fPIC works ok, even for shared libraries, surprising. > > > - Jay > > > ---------------------------------------- >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: m3_load/store using bitfields for everything >> Date: Fri, 22 May 2009 09:45:08 +1000 >> >> Jay, can you try these again with the latest fix I put in place? >> >> On 20 May 2009, at 09:14, Jay wrote: >> >>> >>> m3_load/store using bitfields for everything caused module-global >>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >>> around that by declaring that the module-globals are at least of >>> size 2 * biggest_alignment. >>> >>> It caused module-global references to disappear on ARM_DARWIN as >>> well. >>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >>> occur and PutChar eventually failed an array bounds check. >>> >>> Is this just too fragile and the failsafe form should always be >>> used? >>> >>> Or, it fails spectacularly consistently enough that it must also be >>> working consistently enough and leave it? >>> >>> Would "component ref" (ie: struct) and declaring more type >>> information about module segments be a good compromise maybe? >>> Probably. >>> >>> - Jay >> From hosking at cs.purdue.edu Fri May 22 03:38:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 22 May 2009 11:38:10 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> References: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> Message-ID: <25294219-236C-474F-874F-22B0B8B9A9F6@cs.purdue.edu> I think my old PPC_DARWIN installs are pre-LONGINT. Is there a LONGINT-capable bootstrap archive for PPC_DARWIN lying around anywhere? On 22 May 2009, at 11:18, Tony Hosking wrote: > PPC_DARWIN did work for me at one point. I can check it. > > On 22 May 2009, at 10:09, Jay wrote: > >> >> Yes I will test some variations, esp. targets not historically >> affected by the bitfield behavior but that haven't passed -O3 yet, >> since they are easier for a few reasons and more numerous >> (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.) >> >> >> ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I >> haven't booted the machine in months and it is very slow (my /plan/ >> is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX}, but it's >> slow going, I had difficulty installing some of them, only got Irix >> and OpenBSD running, and some of those combinations are invalid >> e.g. MIPS32_OPENBSD -- OpenBSD never >> has "biarch" systems, only ever pure 32bit or pure 64bit). >> >> >> Moving ARM_DARWIN forward to 4.3 isn't impossible but I think >> easier to track and wait for Apple here than anything else. >> >> >> I ran an AMD64_LINUX test on birch but didn't wait for it. >> >> >> SPARC32_LINUX also has a wierd problem that I can retest. >> When I compile with -fPIC I get I think crashes during >> initialization. >> I haven't figured out the problem. >> Without -fPIC works ok, even for shared libraries, surprising. >> >> >> - Jay >> >> >> ---------------------------------------- >>> CC: m3devel at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: m3_load/store using bitfields for everything >>> Date: Fri, 22 May 2009 09:45:08 +1000 >>> >>> Jay, can you try these again with the latest fix I put in place? >>> >>> On 20 May 2009, at 09:14, Jay wrote: >>> >>>> >>>> m3_load/store using bitfields for everything caused module-global >>>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >>>> around that by declaring that the module-globals are at least of >>>> size 2 * biggest_alignment. >>>> >>>> It caused module-global references to disappear on ARM_DARWIN as >>>> well. >>>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >>>> occur and PutChar eventually failed an array bounds check. >>>> >>>> Is this just too fragile and the failsafe form should always be >>>> used? >>>> >>>> Or, it fails spectacularly consistently enough that it must also be >>>> working consistently enough and leave it? >>>> >>>> Would "component ref" (ie: struct) and declaring more type >>>> information about module segments be a good compromise maybe? >>>> Probably. >>>> >>>> - Jay >>> From hosking at cs.purdue.edu Fri May 22 03:41:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 22 May 2009 11:41:25 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <25294219-236C-474F-874F-22B0B8B9A9F6@cs.purdue.edu> References: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> <25294219-236C-474F-874F-22B0B8B9A9F6@cs.purdue.edu> Message-ID: <70E5C90F-6795-4D3F-A776-B045372D31C9@cs.purdue.edu> Don't worry --- I found one. On 22 May 2009, at 11:38, Tony Hosking wrote: > I think my old PPC_DARWIN installs are pre-LONGINT. Is there a > LONGINT-capable bootstrap archive for PPC_DARWIN lying around > anywhere? > > On 22 May 2009, at 11:18, Tony Hosking wrote: > >> PPC_DARWIN did work for me at one point. I can check it. >> >> On 22 May 2009, at 10:09, Jay wrote: >> >>> >>> Yes I will test some variations, esp. targets not historically >>> affected by the bitfield behavior but that haven't passed -O3 yet, >>> since they are easier for a few reasons and more numerous >>> (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.) >>> >>> >>> ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I >>> haven't booted the machine in months and it is very slow (my / >>> plan/ is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX}, >>> but it's slow going, I had difficulty installing some of them, >>> only got Irix and OpenBSD running, and some of those combinations >>> are invalid e.g. MIPS32_OPENBSD -- OpenBSD never >>> has "biarch" systems, only ever pure 32bit or pure 64bit). >>> >>> >>> Moving ARM_DARWIN forward to 4.3 isn't impossible but I think >>> easier to track and wait for Apple here than anything else. >>> >>> >>> I ran an AMD64_LINUX test on birch but didn't wait for it. >>> >>> >>> SPARC32_LINUX also has a wierd problem that I can retest. >>> When I compile with -fPIC I get I think crashes during >>> initialization. >>> I haven't figured out the problem. >>> Without -fPIC works ok, even for shared libraries, surprising. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> CC: m3devel at elegosoft.com >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Subject: Re: m3_load/store using bitfields for everything >>>> Date: Fri, 22 May 2009 09:45:08 +1000 >>>> >>>> Jay, can you try these again with the latest fix I put in place? >>>> >>>> On 20 May 2009, at 09:14, Jay wrote: >>>> >>>>> >>>>> m3_load/store using bitfields for everything caused module-global >>>>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >>>>> around that by declaring that the module-globals are at least of >>>>> size 2 * biggest_alignment. >>>>> >>>>> It caused module-global references to disappear on ARM_DARWIN as >>>>> well. >>>>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 >>>>> didn't >>>>> occur and PutChar eventually failed an array bounds check. >>>>> >>>>> Is this just too fragile and the failsafe form should always be >>>>> used? >>>>> >>>>> Or, it fails spectacularly consistently enough that it must also >>>>> be >>>>> working consistently enough and leave it? >>>>> >>>>> Would "component ref" (ie: struct) and declaring more type >>>>> information about module segments be a good compromise maybe? >>>>> Probably. >>>>> >>>>> - Jay >>>> From jay.krell at cornell.edu Fri May 22 03:48:50 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 21 May 2009 18:48:50 -0700 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> References: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> Message-ID: <5AEE6485-5622-4797-B1D5-6282E8BABDC7@hotmail.com> Didn't mean to imply it not working, but I don't think I have tried it yet. - Jay (phone) On May 21, 2009, at 6:18 PM, Tony Hosking wrote: > PPC_DARWIN did work for me at one point. I can check it. > > On 22 May 2009, at 10:09, Jay wrote: > >> >> Yes I will test some variations, esp. targets not historically >> affected by the bitfield behavior but that haven't passed -O3 yet, >> since they are easier for a few reasons and more numerous >> (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.) >> >> >> ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I >> haven't booted the machine in months and it is very slow (my /plan/ >> is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX}, but it's >> slow going, I had difficulty installing some of them, only got Irix >> and OpenBSD running, and some of those combinations are invalid >> e.g. MIPS32_OPENBSD -- OpenBSD never >> has "biarch" systems, only ever pure 32bit or pure 64bit). >> >> >> Moving ARM_DARWIN forward to 4.3 isn't impossible but I think >> easier to track and wait for Apple here than anything else. >> >> >> I ran an AMD64_LINUX test on birch but didn't wait for it. >> >> >> SPARC32_LINUX also has a wierd problem that I can retest. >> When I compile with -fPIC I get I think crashes during >> initialization. >> I haven't figured out the problem. >> Without -fPIC works ok, even for shared libraries, surprising. >> >> >> - Jay >> >> >> ---------------------------------------- >>> CC: m3devel at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: m3_load/store using bitfields for everything >>> Date: Fri, 22 May 2009 09:45:08 +1000 >>> >>> Jay, can you try these again with the latest fix I put in place? >>> >>> On 20 May 2009, at 09:14, Jay wrote: >>> >>>> >>>> m3_load/store using bitfields for everything caused module-global >>>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >>>> around that by declaring that the module-globals are at least of >>>> size 2 * biggest_alignment. >>>> >>>> It caused module-global references to disappear on ARM_DARWIN as >>>> well. >>>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >>>> occur and PutChar eventually failed an array bounds check. >>>> >>>> Is this just too fragile and the failsafe form should always be >>>> used? >>>> >>>> Or, it fails spectacularly consistently enough that it must also be >>>> working consistently enough and leave it? >>>> >>>> Would "component ref" (ie: struct) and declaring more type >>>> information about module segments be a good compromise maybe? >>>> Probably. >>>> >>>> - Jay >>> > > From jay.krell at cornell.edu Fri May 22 03:58:32 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 21 May 2009 18:58:32 -0700 Subject: [M3devel] Tinderbox Message-ID: There is out of diskspace error in tinderbox. - Jay (phone) From jay.krell at cornell.edu Fri May 22 07:28:09 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 22 May 2009 05:28:09 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <70E5C90F-6795-4D3F-A776-B045372D31C9@cs.purdue.edu> References: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> <25294219-236C-474F-874F-22B0B8B9A9F6@cs.purdue.edu> <70E5C90F-6795-4D3F-A776-B045372D31C9@cs.purdue.edu> Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives/index.html has one and really cross-building is not a terrible option, I've done it many times including recently (ARM_DARWIN). cd m3-sys/m3cc cm3 -DM3CC_TARGET=foo cd scripts/python ./boot1.py foo gives you cm3-boot-foo-1.tar.gz copy that to "target" machine (aka machine with C compiler/linker) extract it there cd cm3-boot-foo-1 make That gives you cm3, with which you can build the rest of the system. boot1.py recognizes target names on the command line (using a builtin list and formating them processor/os combinations). My config files probe around for a viable backend, which coincides with where -DM3CC_TARGET puts it. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Fri, 22 May 2009 11:41:25 +1000 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] m3_load/store using bitfields for everything > > Don't worry --- I found one. > > On 22 May 2009, at 11:38, Tony Hosking wrote: > >> I think my old PPC_DARWIN installs are pre-LONGINT. Is there a >> LONGINT-capable bootstrap archive for PPC_DARWIN lying around >> anywhere? >> >> On 22 May 2009, at 11:18, Tony Hosking wrote: >> >>> PPC_DARWIN did work for me at one point. I can check it. >>> >>> On 22 May 2009, at 10:09, Jay wrote: >>> >>>> >>>> Yes I will test some variations, esp. targets not historically >>>> affected by the bitfield behavior but that haven't passed -O3 yet, >>>> since they are easier for a few reasons and more numerous >>>> (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.) >>>> >>>> >>>> ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I >>>> haven't booted the machine in months and it is very slow (my / >>>> plan/ is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX}, >>>> but it's slow going, I had difficulty installing some of them, >>>> only got Irix and OpenBSD running, and some of those combinations >>>> are invalid e.g. MIPS32_OPENBSD -- OpenBSD never >>>> has "biarch" systems, only ever pure 32bit or pure 64bit). >>>> >>>> >>>> Moving ARM_DARWIN forward to 4.3 isn't impossible but I think >>>> easier to track and wait for Apple here than anything else. >>>> >>>> >>>> I ran an AMD64_LINUX test on birch but didn't wait for it. >>>> >>>> >>>> SPARC32_LINUX also has a wierd problem that I can retest. >>>> When I compile with -fPIC I get I think crashes during >>>> initialization. >>>> I haven't figured out the problem. >>>> Without -fPIC works ok, even for shared libraries, surprising. >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> CC: m3devel at elegosoft.com >>>>> From: hosking at cs.purdue.edu >>>>> To: jay.krell at cornell.edu >>>>> Subject: Re: m3_load/store using bitfields for everything >>>>> Date: Fri, 22 May 2009 09:45:08 +1000 >>>>> >>>>> Jay, can you try these again with the latest fix I put in place? >>>>> >>>>> On 20 May 2009, at 09:14, Jay wrote: >>>>> >>>>>> >>>>>> m3_load/store using bitfields for everything caused module-global >>>>>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >>>>>> around that by declaring that the module-globals are at least of >>>>>> size 2 * biggest_alignment. >>>>>> >>>>>> It caused module-global references to disappear on ARM_DARWIN as >>>>>> well. >>>>>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 >>>>>> didn't >>>>>> occur and PutChar eventually failed an array bounds check. >>>>>> >>>>>> Is this just too fragile and the failsafe form should always be >>>>>> used? >>>>>> >>>>>> Or, it fails spectacularly consistently enough that it must also >>>>>> be >>>>>> working consistently enough and leave it? >>>>>> >>>>>> Would "component ref" (ie: struct) and declaring more type >>>>>> information about module segments be a good compromise maybe? >>>>>> Probably. >>>>>> >>>>>> - Jay >>>>> > From jay.krell at cornell.edu Fri May 22 13:17:48 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 22 May 2009 11:17:48 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: Looks like AMD64_LINUX is still failing similarly to how it was (NOT bitfield/global related, but optimization related). -O2 also crashes. -O1 does not. birch [~/dev2/cm3/m3-libs/slisp/AMD64_LINUX] jkrell % gdb --args cm3cg SLisp.mc -O3 -quiet GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /home/jkrell/cm3/bin/cm3cg SLisp.mc -O3 -quiet cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack exception handli ng Program received signal SIGSEGV, Segmentation fault. 0x00000000006814f4 in remove_phi_node (phi=0x2b17b7ac7100, prev=0x0, release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461 461 *loc != phi; (gdb) bt #0 0x00000000006814f4 in remove_phi_node (phi=0x2b17b7ac7100, prev=0x0, release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461 #1 0x00000000007039fb in remove_dead_inserted_code () at ../../gcc/gcc/tree-ssa-pre.c:3775 #2 0x00000000007042b2 in execute_pre (do_fre=0 '\0') at ../../gcc/gcc/tree-ssa-pre.c:3975 #3 0x00000000007042cc in do_pre () at ../../gcc/gcc/tree-ssa-pre.c:3987 #4 0x000000000058be1b in execute_one_pass (pass=0xe46860) at ../../gcc/gcc/passes.c:1122 #5 0x000000000058bf73 in execute_pass_list (pass=0xe46860) at ../../gcc/gcc/passes.c:1175 #6 0x000000000058bf91 in execute_pass_list (pass=0xe45420) at ../../gcc/gcc/passes.c:1176 #7 0x0000000000676bbd in tree_rest_of_compilation (fndecl=0x2b17b624b750) at ../../gcc/gcc/tree-optimize.c:404 #8 0x00000000007cee01 in cgraph_expand_function (node=0x2b17b6663200) at ../../gcc/gcc/cgraphunit.c:1157 #9 0x00000000007cefae in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1220 #10 0x00000000007cf561 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1427 #11 0x000000000040f875 in m3_parse_file (xx=0) at ../../gcc/gcc/m3cg/parse.c:5220 #12 0x000000000062feec in compile_file () at ../../gcc/gcc/toplev.c:1042 #13 0x0000000000631a26 in do_compile () at ../../gcc/gcc/toplev.c:2247 #14 0x0000000000631a8a in toplev_main (argc=4, argv=0x7ffff4c3a7f8) at ../../gcc/gcc/toplev.c:2279 #15 0x0000000000417ecf in main (argc=4, argv=0x7ffff4c3a7f8) at ../../gcc/gcc/main.c:35 (gdb) I'm pretty sure this is with current code. - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: m3_load/store using bitfields for everything > Date: Fri, 22 May 2009 09:45:08 +1000 > > Jay, can you try these again with the latest fix I put in place? > > On 20 May 2009, at 09:14, Jay wrote: > >> >> m3_load/store using bitfields for everything caused module-global >> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >> around that by declaring that the module-globals are at least of >> size 2 * biggest_alignment. >> >> It caused module-global references to disappear on ARM_DARWIN as well. >> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >> occur and PutChar eventually failed an array bounds check. >> >> Is this just too fragile and the failsafe form should always be used? >> >> Or, it fails spectacularly consistently enough that it must also be >> working consistently enough and leave it? >> >> Would "component ref" (ie: struct) and declaring more type >> information about module segments be a good compromise maybe? >> Probably. >> >> - Jay > From dragisha at m3w.org Sat May 23 09:12:28 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 23 May 2009 09:12:28 +0200 Subject: [M3devel] ".." in INSTALL_ROOT derivates, LINUXLIBC6 & AMD64_LINUX, not serious but nasty one Message-ID: <1243062748.6410.37.camel@faramir.m3w.org> When ran with CM3_INSTALL_PREFIX set, cm3 -ship fails for first package being shipped. Repeating cm3 -ship with same package, or any other, succeeds, and all subsequent cm3 -ship are ok. Most important thing which differs such "cm3 -ship" from others is unpopulated directory tree. I've tracked this % export CM3_INSTALL_PREFIX=/tmp/123 % cm3 -ship ... . => /usr/local/cm3/pkg/pdf/LINUXLIBC6 .M3EXPORTS libhm3pdf.so.5 "/home/dragisha/m3/pdf/LINUXLIBC6/.M3SHIP", line 5: quake runtime error: unable to create directory "/tmp/123/usr/local/cm3/bin/..": errno=17 to problem with non-existent /tmp/123/usr/local/cm3/bin. This first unsuccessful cm3 -ship creates it, and after that cm3 -ship works. One fix is to "mkdir -p" this folder before first shipping, and my first was to sed .M3SHIP a bit... Neither one is too elegant. -- Dragi?a Duri? From mika at async.caltech.edu Sat May 23 22:34:16 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 23 May 2009 13:34:16 -0700 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? Message-ID: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> Hi Modula-3ers, especially Tony, I'm seeing the following behavior a lot in a program I'm running: #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. ) at ../src/runtime/common/RTCollector.m3:674 #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. ) at ../src/runtime/common/RTCollector.m3:2271 #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. ) at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 Is it normal for CheckLoadTracedRef to make system calls? Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): PROCEDURE Get ( tbl : Default; READONLY k : Key.T; VAR(*OUT*) v : Value.T): BOOLEAN = VAR x : Node := tbl.h.hi; cmp : Cmp; BEGIN WHILE (x # NIL) DO cmp := tbl.keyCompare (k, x.key); IF cmp = 0 THEN v := x.value; RETURN TRUE; END; IF (cmp < 0) THEN x := x.lo; (* line 145 *) ELSE x := x.hi; END; END; RETURN FALSE; END Get; where Node is defined as TYPE Node = REF RECORD key : Key.T; value : Value.T; lo : Node := NIL; hi : Node := NIL; priority: INTEGER (* random num; tree is a heap on these *) END; It seems odd to me that, under these circumstances, x := x.lo would cause any sort of checking activity... I'm using a CM3 that's about a month old, on FreeBSD4. Mika P.S. Needless to say, the code in question runs about 10x faster under PM3 than with this relatively new CM3... but my m3gdb is having trouble with PM3's LONGREALs for some reason. From jay.krell at cornell.edu Sat May 23 23:38:33 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 23 May 2009 21:38:33 +0000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> References: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> Message-ID: It does appear to be making policy decisions based on elapsed time, not just collecting times to report. Does gettimeofday on your system make a syscall or read a global? - Jay Maybe since the intent is just to process one object/page, the CollectorOn/Off calls can be replaced by just collectorOn := TRUE or FALSE ? For CollectorOff that isn't clear since it does more, but CollectorOn is just that plus time recording plus an assertion. Still, given that the intent is some limited processing, I think the time collection could be avoided and might not even be a good thing? - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Sat, 23 May 2009 13:34:16 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? > > > Hi Modula-3ers, especially Tony, > > I'm seeing the following behavior a lot in a program I'm running: > > #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 > #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 > #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. > ) at ../src/runtime/common/RTCollector.m3:674 > #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. > ) at ../src/runtime/common/RTCollector.m3:2271 > #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. > ) > at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 > > Is it normal for CheckLoadTracedRef to make system calls? > > Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): > > > PROCEDURE Get ( tbl : Default; > READONLY k : Key.T; > VAR(*OUT*) v : Value.T): BOOLEAN = > VAR > x : Node := tbl.h.hi; > cmp : Cmp; > BEGIN > WHILE (x # NIL) DO > cmp := tbl.keyCompare (k, x.key); > IF cmp = 0 THEN v := x.value; RETURN TRUE; END; > IF (cmp < 0) > THEN x := x.lo; (* line 145 *) > ELSE x := x.hi; > END; > END; > RETURN FALSE; > END Get; > > where Node is defined as > > TYPE > Node = REF RECORD > key : Key.T; > value : Value.T; > lo : Node := NIL; > hi : Node := NIL; > priority: INTEGER (* random num; tree is a heap on these *) > END; > > It seems odd to me that, under these circumstances, x := x.lo would > cause any sort of checking activity... > > I'm using a CM3 that's about a month old, on FreeBSD4. > > Mika > > P.S. Needless to say, the code in question runs about 10x faster under > PM3 than with this relatively new CM3... but my m3gdb is having trouble > with PM3's LONGREALs for some reason. From rodney.m.bates at cox.net Sun May 24 15:50:14 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 24 May 2009 08:50:14 -0500 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> References: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> Message-ID: <4A195096.2030502@cox.net> Floating point values in m3gdb is one area I have never done any work on at all, but I have been aware for a long time that it probably needs some. It just uses stock gdb's code, which also just uses the C builtin arithmetic on C floating types. At the very least, the mapping between C's two and Modula-3's three floating types, on the various targets, is purely an accident right now. I recall there is something wrong in the formatting too. Mika Nystrom wrote: > Hi Modula-3ers, especially Tony, > > I'm seeing the following behavior a lot in a program I'm running: > > #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 > #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 > #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. > ) at ../src/runtime/common/RTCollector.m3:674 > #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. > ) at ../src/runtime/common/RTCollector.m3:2271 > #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. > ) > at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 > > Is it normal for CheckLoadTracedRef to make system calls? > > Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): > > > PROCEDURE Get ( tbl : Default; > READONLY k : Key.T; > VAR(*OUT*) v : Value.T): BOOLEAN = > VAR > x : Node := tbl.h.hi; > cmp : Cmp; > BEGIN > WHILE (x # NIL) DO > cmp := tbl.keyCompare (k, x.key); > IF cmp = 0 THEN v := x.value; RETURN TRUE; END; > IF (cmp < 0) > THEN x := x.lo; (* line 145 *) > ELSE x := x.hi; > END; > END; > RETURN FALSE; > END Get; > > where Node is defined as > > TYPE > Node = REF RECORD > key : Key.T; > value : Value.T; > lo : Node := NIL; > hi : Node := NIL; > priority: INTEGER (* random num; tree is a heap on these *) > END; > > It seems odd to me that, under these circumstances, x := x.lo would > cause any sort of checking activity... > > I'm using a CM3 that's about a month old, on FreeBSD4. > > Mika > > P.S. Needless to say, the code in question runs about 10x faster under > PM3 than with this relatively new CM3... but my m3gdb is having trouble > with PM3's LONGREALs for some reason. > > From mika at async.caltech.edu Sun May 24 20:15:51 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 May 2009 11:15:51 -0700 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: Your message of "Sat, 23 May 2009 21:38:33 -0000." Message-ID: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> It makes a syscall. A slow one! Mika Jay writes: > >It does appear to be making policy decisions based on elapsed time, not just collecting times to report. > >Does gettimeofday on your system make a syscall or read a global? > > - Jay > >Maybe since the intent is just to process one object/page, the CollectorOn/Off calls can be replaced by just > collectorOn := TRUE or FALSE > > ? For CollectorOff that isn't clear since it does more, but CollectorOn is just that plus time recording plus an assertion. Still, given that the intent is some limited processing, I think the time collection could be avoided and might not even be a good thing? > > > - Jay > > >---------------------------------------- >> To: m3devel at elegosoft.com >> Date: Sat, 23 May 2009 13:34:16 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? >> >> >> Hi Modula-3ers, especially Tony, >> >> I'm seeing the following behavior a lot in a program I'm running: >> >> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >> ) at ../src/runtime/common/RTCollector.m3:674 >> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >> ) at ../src/runtime/common/RTCollector.m3:2271 >> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >> ) >> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >> >> Is it normal for CheckLoadTracedRef to make system calls? >> >> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >> >> >> PROCEDURE Get ( tbl : Default; >> READONLY k : Key.T; >> VAR(*OUT*) v : Value.T): BOOLEAN = >> VAR >> x : Node := tbl.h.hi; >> cmp : Cmp; >> BEGIN >> WHILE (x # NIL) DO >> cmp := tbl.keyCompare (k, x.key); >> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >> IF (cmp < 0) >> THEN x := x.lo; (* line 145 *) >> ELSE x := x.hi; >> END; >> END; >> RETURN FALSE; >> END Get; >> >> where Node is defined as >> >> TYPE >> Node = REF RECORD >> key : Key.T; >> value : Value.T; >> lo : Node := NIL; >> hi : Node := NIL; >> priority: INTEGER (* random num; tree is a heap on these *) >> END; >> >> It seems odd to me that, under these circumstances, x := x.lo would >> cause any sort of checking activity... >> >> I'm using a CM3 that's about a month old, on FreeBSD4. >> >> Mika >> >> P.S. Needless to say, the code in question runs about 10x faster under >> PM3 than with this relatively new CM3... but my m3gdb is having trouble >> with PM3's LONGREALs for some reason. From jay.krell at cornell.edu Sun May 24 20:20:50 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 24 May 2009 18:20:50 +0000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> References: Your message of "Sat, 23 May 2009 21:38:33 -0000." <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> Message-ID: I can send you a diff to try later but I won't likely have confidence in it. Tony will have to judge. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Sun, 24 May 2009 11:15:51 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gettimeofday called from CheckLoadTracedRef? > > It makes a syscall. A slow one! > > Mika > > Jay writes: >> >>It does appear to be making policy decisions based on elapsed time, not just collecting times to report. >> >>Does gettimeofday on your system make a syscall or read a global? >> >> - Jay >> >>Maybe since the intent is just to process one object/page, the CollectorOn/Off calls can be replaced by just >> collectorOn := TRUE or FALSE >> >> ? For CollectorOff that isn't clear since it does more, but CollectorOn is just that plus time recording plus an assertion. Still, given that the intent is some limited processing, I think the time collection could be avoided and might not even be a good thing? >> >> >> - Jay >> >> >>---------------------------------------- >>> To: m3devel at elegosoft.com >>> Date: Sat, 23 May 2009 13:34:16 -0700 >>> From: mika at async.caltech.edu >>> CC: mika at camembert.async.caltech.edu >>> Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? >>> >>> >>> Hi Modula-3ers, especially Tony, >>> >>> I'm seeing the following behavior a lot in a program I'm running: >>> >>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:674 >>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:2271 >>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >>> ) >>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >>> >>> Is it normal for CheckLoadTracedRef to make system calls? >>> >>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >>> >>> >>> PROCEDURE Get ( tbl : Default; >>> READONLY k : Key.T; >>> VAR(*OUT*) v : Value.T): BOOLEAN = >>> VAR >>> x : Node := tbl.h.hi; >>> cmp : Cmp; >>> BEGIN >>> WHILE (x # NIL) DO >>> cmp := tbl.keyCompare (k, x.key); >>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>> IF (cmp < 0) >>> THEN x := x.lo; (* line 145 *) >>> ELSE x := x.hi; >>> END; >>> END; >>> RETURN FALSE; >>> END Get; >>> >>> where Node is defined as >>> >>> TYPE >>> Node = REF RECORD >>> key : Key.T; >>> value : Value.T; >>> lo : Node := NIL; >>> hi : Node := NIL; >>> priority: INTEGER (* random num; tree is a heap on these *) >>> END; >>> >>> It seems odd to me that, under these circumstances, x := x.lo would >>> cause any sort of checking activity... >>> >>> I'm using a CM3 that's about a month old, on FreeBSD4. >>> >>> Mika >>> >>> P.S. Needless to say, the code in question runs about 10x faster under >>> PM3 than with this relatively new CM3... but my m3gdb is having trouble >>> with PM3's LONGREALs for some reason. From jay.krell at cornell.edu Sun May 24 20:19:46 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 24 May 2009 18:19:46 +0000 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: <4A195096.2030502@cox.net> References: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> <4A195096.2030502@cox.net> Message-ID: Modula-3 only actually implements two floating point formats. The language spec and frontend might support three "names", but two of them are the same. - Jay ---------------------------------------- > Date: Sun, 24 May 2009 08:50:14 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) > > Floating point values in m3gdb is one area I have never done any > work on at all, but I have been aware for a long time that it probably > needs some. It just uses stock gdb's code, which also just uses > the C builtin arithmetic on C floating types. At the very least, the > mapping between C's two and Modula-3's three floating types, on > the various targets, is purely an accident right now. I recall there > is something wrong in the formatting too. > > Mika Nystrom wrote: >> Hi Modula-3ers, especially Tony, >> >> I'm seeing the following behavior a lot in a program I'm running: >> >> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >> ) at ../src/runtime/common/RTCollector.m3:674 >> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >> ) at ../src/runtime/common/RTCollector.m3:2271 >> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >> ) >> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >> >> Is it normal for CheckLoadTracedRef to make system calls? >> >> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >> >> >> PROCEDURE Get ( tbl : Default; >> READONLY k : Key.T; >> VAR(*OUT*) v : Value.T): BOOLEAN = >> VAR >> x : Node := tbl.h.hi; >> cmp : Cmp; >> BEGIN >> WHILE (x # NIL) DO >> cmp := tbl.keyCompare (k, x.key); >> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >> IF (cmp < 0) >> THEN x := x.lo; (* line 145 *) >> ELSE x := x.hi; >> END; >> END; >> RETURN FALSE; >> END Get; >> >> where Node is defined as >> >> TYPE >> Node = REF RECORD >> key : Key.T; >> value : Value.T; >> lo : Node := NIL; >> hi : Node := NIL; >> priority: INTEGER (* random num; tree is a heap on these *) >> END; >> >> It seems odd to me that, under these circumstances, x := x.lo would >> cause any sort of checking activity... >> >> I'm using a CM3 that's about a month old, on FreeBSD4. >> >> Mika >> >> P.S. Needless to say, the code in question runs about 10x faster under >> PM3 than with this relatively new CM3... but my m3gdb is having trouble >> with PM3's LONGREALs for some reason. >> >> > From mika at async.caltech.edu Sun May 24 20:48:33 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 May 2009 11:48:33 -0700 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: Your message of "Sun, 24 May 2009 08:50:14 CDT." <4A195096.2030502@cox.net> Message-ID: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> The weird thing is that it works really well SOMETIMES. Are there any workarounds? Where would I go poke if I wanted to fix it? My code is mostly floating point (double precision). I find myself typing garbage like print (double *)(M3_adsf23_myVar+8) into the normal C gdb.... In m3gdb I am now getting the following error: (m3gdb) print self.srThreshold $2 = Invalid C/C++ type code 44 in symbol table. This is trying to print a field of type LONGREAL in an OBJECT: (m3gdb) print self $3 = (*16_14838244*) OBJECT orderManager = 16_148382ec; marketDataManager = 16_14838224; tickers = 16_14838ab4; limitsMap = NIL; orderSizeMap = NIL; rangeMult = ; invTilt = ; perfSmooth = ; times = {RECORD hour = 10; minute = 12; second = 0; END, RECORD hour = 15; minute = 55; second = 0; END, RECORD hour = 15; minute = 30; second = 0; END, RECORD hour = 9; minute = 30; second = 0; END, RECORD hour = 16; minute = 0; second = 0; END}; tz = 16_1a7bc7b0; midnites = 16_1a7bc7dc; firstPeriod = 12638; initialPeriods = 390; limitsMap = 16_14838b18; orderSizeMap = 16_14838b38; singleStockMarketMaker = NIL; ssTbl = 16_14833818; unitsPortfolioTilt = ; portTiltMode = UNITS; srThreshold = ; dollarUnit = ; unitsPortTilt = ; grossLimit = ; overnightLimitMultiplier = ; rangeMultiplier = ; closeSmooth = ; END Mika "Rodney M. Bates" writes: >Floating point values in m3gdb is one area I have never done any >work on at all, but I have been aware for a long time that it probably >needs some. It just uses stock gdb's code, which also just uses >the C builtin arithmetic on C floating types. At the very least, the >mapping between C's two and Modula-3's three floating types, on >the various targets, is purely an accident right now. I recall there >is something wrong in the formatting too. > >Mika Nystrom wrote: > Hi Modula-3ers, especially Tony, >> >> I'm seeing the following behavior a lot in a program I'm running: >> >> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >> ) at ../src/runtime/common/RTCollector.m3:674 >> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >> ) at ../src/runtime/common/RTCollector.m3:2271 >> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >> ) >> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >> >> Is it normal for CheckLoadTracedRef to make system calls? >> >> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >> >> >> PROCEDURE Get ( tbl : Default; >> READONLY k : Key.T; >> VAR(*OUT*) v : Value.T): BOOLEAN = >> VAR >> x : Node := tbl.h.hi; >> cmp : Cmp; >> BEGIN >> WHILE (x # NIL) DO >> cmp := tbl.keyCompare (k, x.key); >> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >> IF (cmp < 0) >> THEN x := x.lo; (* line 145 *) >> ELSE x := x.hi; >> END; >> END; >> RETURN FALSE; >> END Get; >> >> where Node is defined as >> >> TYPE >> Node = REF RECORD >> key : Key.T; >> value : Value.T; >> lo : Node := NIL; >> hi : Node := NIL; >> priority: INTEGER (* random num; tree is a heap on these *) >> END; >> >> It seems odd to me that, under these circumstances, x := x.lo would >> cause any sort of checking activity... >> >> I'm using a CM3 that's about a month old, on FreeBSD4. >> >> Mika >> >> P.S. Needless to say, the code in question runs about 10x faster under >> PM3 than with this relatively new CM3... but my m3gdb is having trouble >> with PM3's LONGREALs for some reason. >> >> From dragisha at m3w.org Sun May 24 22:41:25 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 24 May 2009 22:41:25 +0200 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> References: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> Message-ID: <1243197685.28115.4.camel@faramir.m3w.org> I have this straced many times on my LInUXLIBC6... Being strace - it's syscall.. And slow??? Can we live without it? On Sun, 2009-05-24 at 11:15 -0700, Mika Nystrom wrote: > It makes a syscall. A slow one! > > Mika -- Dragi?a Duri? From mika at async.caltech.edu Sun May 24 22:45:44 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 May 2009 13:45:44 -0700 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: Your message of "Sun, 24 May 2009 18:19:46 -0000." Message-ID: <200905242045.n4OKji3w024683@camembert.async.caltech.edu> Hrmph this is a bit silly. 80-bit FP ought to be supported on x86, at least, since that's the native precision of the i387 (and 68881?)... Mika Jay writes: > >Modula-3 only actually implements two floating point formats. >The language spec and frontend might support three "names", but two of them are the same. > > - Jay > > >---------------------------------------- >> Date: Sun, 24 May 2009 08:50:14 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) >> >> Floating point values in m3gdb is one area I have never done any >> work on at all, but I have been aware for a long time that it probably >> needs some. It just uses stock gdb's code, which also just uses >> the C builtin arithmetic on C floating types. At the very least, the >> mapping between C's two and Modula-3's three floating types, on >> the various targets, is purely an accident right now. I recall there >> is something wrong in the formatting too. >> >> Mika Nystrom wrote: >>> Hi Modula-3ers, especially Tony, >>> >>> I'm seeing the following behavior a lot in a program I'm running: >>> >>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:674 >>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:2271 >>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >>> ) >>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >>> >>> Is it normal for CheckLoadTracedRef to make system calls? >>> >>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >>> >>> >>> PROCEDURE Get ( tbl : Default; >>> READONLY k : Key.T; >>> VAR(*OUT*) v : Value.T): BOOLEAN = >>> VAR >>> x : Node := tbl.h.hi; >>> cmp : Cmp; >>> BEGIN >>> WHILE (x # NIL) DO >>> cmp := tbl.keyCompare (k, x.key); >>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>> IF (cmp < 0) >>> THEN x := x.lo; (* line 145 *) >>> ELSE x := x.hi; >>> END; >>> END; >>> RETURN FALSE; >>> END Get; >>> >>> where Node is defined as >>> >>> TYPE >>> Node = REF RECORD >>> key : Key.T; >>> value : Value.T; >>> lo : Node := NIL; >>> hi : Node := NIL; >>> priority: INTEGER (* random num; tree is a heap on these *) >>> END; >>> >>> It seems odd to me that, under these circumstances, x := x.lo would >>> cause any sort of checking activity... >>> >>> I'm using a CM3 that's about a month old, on FreeBSD4. >>> >>> Mika >>> >>> P.S. Needless to say, the code in question runs about 10x faster under >>> PM3 than with this relatively new CM3... but my m3gdb is having trouble >>> with PM3's LONGREALs for some reason. >>> >>> >> From mika at async.caltech.edu Sun May 24 23:56:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 May 2009 14:56:18 -0700 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: Your message of "Sun, 24 May 2009 14:10:25 PDT." <42F3F7C8-6184-4174-94E9-5AF06223A028@hotmail.com> Message-ID: <200905242156.n4OLuIam027199@camembert.async.caltech.edu> Haha, FP isn't weird! It's just... FP! This is a bit disappointing... here's FreeBSD4: (552)rover:~/fp/src>./a.out sizeof(float) = 4 sizeof(double) = 8 sizeof(long double) = 12 (553)rover:~/fp/src>../FreeBSD4/fp BITSIZE(REAL) = 32 BITSIZE(LONGREAL) = 64 BITSIZE(EXTENDED) = 64 I think the "12" is just to get them word-aligned. i387 supports 10-byte extended format in hardware (in fact that is the *only* format it supports, which may cause subtle bugs and/or inefficiencies when using other sizes). PowerPC does 128-bit but is that normally provided in hardware? In any case it seems to me that on i386, Modula-3's EXTENDED ought to be Intel 80-bit FP, possibly padded with two extra bytes like in C. Easiest seems to just make it match C's long double... If the backend compiler optimizer knows what it's doing, 80-bit FP can run faster on i387 than 32- or 64-bit. Because in the narrower formats, the 387 has to convert results to the narrower format on every operation, which it normally does by storing the result and re-loading it. That's not necessary if the code stays in 80-bit extended; instead it keep the intermediate results in registers. Mika jay.krell at cornell.edu writes: >What does 'long double' give you in C? On Windows I'm sure it is 64 >bits. I was just reading that powerpc has a 128 bit long double but I >don't know if always/everywhere and it is in software via two doubles >and lacks various features.On x86 there is something somehow >supposedly much better for FP via SSE/2/3/whatever. Imho FP is just >all around wierd and to be avoided.. > > - Jay (phone) > >On May 24, 2009, at 1:45 PM, Mika Nystrom >wrote: > >> Hrmph this is a bit silly. >> >> 80-bit FP ought to be supported on x86, at least, since that's the >> native precision of the i387 (and 68881?)... >> >> Mika >> >> Jay writes: >>> >>> Modula-3 only actually implements two floating point formats. >>> The language spec and frontend might support three "names", but two >>> of them are the same. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Sun, 24 May 2009 08:50:14 -0500 >>>> From: rodney.m.bates at cox.net >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] LONGREAL and m3gdb (was gettimeofday called >>>> from CheckLoadTracedRef?) >>>> >>>> Floating point values in m3gdb is one area I have never done any >>>> work on at all, but I have been aware for a long time that it >>>> probably >>>> needs some. It just uses stock gdb's code, which also just uses >>>> the C builtin arithmetic on C floating types. At the very least, the >>>> mapping between C's two and Modula-3's three floating types, on >>>> the various targets, is purely an accident right now. I recall there >>>> is something wrong in the formatting too. >>>> >>>> Mika Nystrom wrote: >>>>> Hi Modula-3ers, especially Tony, >>>>> >>>>> I'm seeing the following behavior a lot in a program I'm running: >>>>> >>>>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>>>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>>>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code >>>>> 30 in symbol table. >>>>> ) at ../src/runtime/common/RTCollector.m3:674 >>>>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code >>>>> 46 in symbol table. >>>>> ) at ../src/runtime/common/RTCollector.m3:2271 >>>>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol >>>>> table. >>>>> ) >>>>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ >>>>> libm3/src/sortedtable/SortedTable.mg:145 >>>>> >>>>> Is it normal for CheckLoadTracedRef to make system calls? >>>>> >>>>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code >>>>> (from SortedTable.mg): >>>>> >>>>> >>>>> PROCEDURE Get ( tbl : Default; >>>>> READONLY k : Key.T; >>>>> VAR(*OUT*) v : Value.T): BOOLEAN = >>>>> VAR >>>>> x : Node := tbl.h.hi; >>>>> cmp : Cmp; >>>>> BEGIN >>>>> WHILE (x # NIL) DO >>>>> cmp := tbl.keyCompare (k, x.key); >>>>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>>>> IF (cmp < 0) >>>>> THEN x := x.lo; (* line 145 *) >>>>> ELSE x := x.hi; >>>>> END; >>>>> END; >>>>> RETURN FALSE; >>>>> END Get; >>>>> >>>>> where Node is defined as >>>>> >>>>> TYPE >>>>> Node = REF RECORD >>>>> key : Key.T; >>>>> value : Value.T; >>>>> lo : Node := NIL; >>>>> hi : Node := NIL; >>>>> priority: INTEGER (* random num; tree is a heap on these *) >>>>> END; >>>>> >>>>> It seems odd to me that, under these circumstances, x := x.lo would >>>>> cause any sort of checking activity... >>>>> >>>>> I'm using a CM3 that's about a month old, on FreeBSD4. >>>>> >>>>> Mika >>>>> >>>>> P.S. Needless to say, the code in question runs about 10x faster >>>>> under >>>>> PM3 than with this relatively new CM3... but my m3gdb is having >>>>> trouble >>>>> with PM3's LONGREALs for some reason. >>>>> >>>>> >>>> >> From jay.krell at cornell.edu Sun May 24 23:10:25 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 24 May 2009 14:10:25 -0700 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: <200905242045.n4OKji3w024683@camembert.async.caltech.edu> References: <200905242045.n4OKji3w024683@camembert.async.caltech.edu> Message-ID: <42F3F7C8-6184-4174-94E9-5AF06223A028@hotmail.com> What does 'long double' give you in C? On Windows I'm sure it is 64 bits. I was just reading that powerpc has a 128 bit long double but I don't know if always/everywhere and it is in software via two doubles and lacks various features.On x86 there is something somehow supposedly much better for FP via SSE/2/3/whatever. Imho FP is just all around wierd and to be avoided.. - Jay (phone) On May 24, 2009, at 1:45 PM, Mika Nystrom wrote: > Hrmph this is a bit silly. > > 80-bit FP ought to be supported on x86, at least, since that's the > native precision of the i387 (and 68881?)... > > Mika > > Jay writes: >> >> Modula-3 only actually implements two floating point formats. >> The language spec and frontend might support three "names", but two >> of them are the same. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Sun, 24 May 2009 08:50:14 -0500 >>> From: rodney.m.bates at cox.net >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] LONGREAL and m3gdb (was gettimeofday called >>> from CheckLoadTracedRef?) >>> >>> Floating point values in m3gdb is one area I have never done any >>> work on at all, but I have been aware for a long time that it >>> probably >>> needs some. It just uses stock gdb's code, which also just uses >>> the C builtin arithmetic on C floating types. At the very least, the >>> mapping between C's two and Modula-3's three floating types, on >>> the various targets, is purely an accident right now. I recall there >>> is something wrong in the formatting too. >>> >>> Mika Nystrom wrote: >>>> Hi Modula-3ers, especially Tony, >>>> >>>> I'm seeing the following behavior a lot in a program I'm running: >>>> >>>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code >>>> 30 in symbol table. >>>> ) at ../src/runtime/common/RTCollector.m3:674 >>>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code >>>> 46 in symbol table. >>>> ) at ../src/runtime/common/RTCollector.m3:2271 >>>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol >>>> table. >>>> ) >>>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ >>>> libm3/src/sortedtable/SortedTable.mg:145 >>>> >>>> Is it normal for CheckLoadTracedRef to make system calls? >>>> >>>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code >>>> (from SortedTable.mg): >>>> >>>> >>>> PROCEDURE Get ( tbl : Default; >>>> READONLY k : Key.T; >>>> VAR(*OUT*) v : Value.T): BOOLEAN = >>>> VAR >>>> x : Node := tbl.h.hi; >>>> cmp : Cmp; >>>> BEGIN >>>> WHILE (x # NIL) DO >>>> cmp := tbl.keyCompare (k, x.key); >>>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>>> IF (cmp < 0) >>>> THEN x := x.lo; (* line 145 *) >>>> ELSE x := x.hi; >>>> END; >>>> END; >>>> RETURN FALSE; >>>> END Get; >>>> >>>> where Node is defined as >>>> >>>> TYPE >>>> Node = REF RECORD >>>> key : Key.T; >>>> value : Value.T; >>>> lo : Node := NIL; >>>> hi : Node := NIL; >>>> priority: INTEGER (* random num; tree is a heap on these *) >>>> END; >>>> >>>> It seems odd to me that, under these circumstances, x := x.lo would >>>> cause any sort of checking activity... >>>> >>>> I'm using a CM3 that's about a month old, on FreeBSD4. >>>> >>>> Mika >>>> >>>> P.S. Needless to say, the code in question runs about 10x faster >>>> under >>>> PM3 than with this relatively new CM3... but my m3gdb is having >>>> trouble >>>> with PM3's LONGREALs for some reason. >>>> >>>> >>> > From jay.krell at cornell.edu Mon May 25 00:02:37 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 24 May 2009 22:02:37 +0000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> References: Your message of "Sat, 23 May 2009 21:38:33 -0000." <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> Message-ID: Can you try like this? I haven't even compiled it. --- RTCollector.m3 2009-05-24 14:56:43.510632700 -0700 +++ RTCollector.m3.mine1 2009-05-24 15:00:25.323132700 -0700 @@ -687,12 +687,11 @@ IF impureCopy.page # NIL THEN END; - END CollectorOn; + END CollectorOnWithoutTimeKeeping; PROCEDURE CollectorOn (VAR timeOnEntry: Time.T) = (* LL>= RTOS.LockHeap *) BEGIN - CollectorOnWithoutTimeKeeping(); timeOnEntry := Time.Now(); END CollectorOn; @@ -713,16 +712,14 @@ signalWeak := FALSE; RTOS.BroadcastHeap(); END; - END CollectorOff; + END CollectorOffWithoutTimeKeeping; PROCEDURE CollectorOff (VAR timeOnEntry: Time.T; allocator := FALSE) = (* LL>= RTOS.LockHeap *) VAR timeOnExit := Time.Now(); BEGIN - CollectorOffWithoutTimeKeeping(); - cycleCost := cycleCost + (timeOnExit - timeOnEntry); IF allocator AND tsIndex>= 0 THEN tStamps[tsIndex] := timeOnEntry; INC(tsIndex); @@ -2259,7 +2256,6 @@ to heap state. *) VAR p := Word.RightShift (LOOPHOLE(ref, Word.T), LogBytesPerPage); - t0: Time.T; thread := ThreadF.MyHeapState(); BEGIN INC(checkLoadTracedRef); (* race, so only approximate *) ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] gettimeofday called from CheckLoadTracedRef? > Date: Sun, 24 May 2009 18:20:50 +0000 > > > I can send you a diff to try later but I won't likely have confidence in it. Tony will have to judge. > > > - Jay > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Sun, 24 May 2009 11:15:51 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] gettimeofday called from CheckLoadTracedRef? >> >> It makes a syscall. A slow one! >> >> Mika >> >> Jay writes: >>> >>>It does appear to be making policy decisions based on elapsed time, not just collecting times to report. >>> >>>Does gettimeofday on your system make a syscall or read a global? >>> >>> - Jay >>> >>>Maybe since the intent is just to process one object/page, the CollectorOn/Off calls can be replaced by just >>> collectorOn := TRUE or FALSE >>> >>> ? For CollectorOff that isn't clear since it does more, but CollectorOn is just that plus time recording plus an assertion. Still, given that the intent is some limited processing, I think the time collection could be avoided and might not even be a good thing? >>> >>> >>> - Jay >>> >>> >>>---------------------------------------- >>>> To: m3devel at elegosoft.com >>>> Date: Sat, 23 May 2009 13:34:16 -0700 >>>> From: mika at async.caltech.edu >>>> CC: mika at camembert.async.caltech.edu >>>> Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? >>>> >>>> >>>> Hi Modula-3ers, especially Tony, >>>> >>>> I'm seeing the following behavior a lot in a program I'm running: >>>> >>>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >>>> ) at ../src/runtime/common/RTCollector.m3:674 >>>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >>>> ) at ../src/runtime/common/RTCollector.m3:2271 >>>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >>>> ) >>>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >>>> >>>> Is it normal for CheckLoadTracedRef to make system calls? >>>> >>>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >>>> >>>> >>>> PROCEDURE Get ( tbl : Default; >>>> READONLY k : Key.T; >>>> VAR(*OUT*) v : Value.T): BOOLEAN = >>>> VAR >>>> x : Node := tbl.h.hi; >>>> cmp : Cmp; >>>> BEGIN >>>> WHILE (x # NIL) DO >>>> cmp := tbl.keyCompare (k, x.key); >>>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>>> IF (cmp < 0) >>>> THEN x := x.lo; (* line 145 *) >>>> ELSE x := x.hi; >>>> END; >>>> END; >>>> RETURN FALSE; >>>> END Get; >>>> >>>> where Node is defined as >>>> >>>> TYPE >>>> Node = REF RECORD >>>> key : Key.T; >>>> value : Value.T; >>>> lo : Node := NIL; >>>> hi : Node := NIL; >>>> priority: INTEGER (* random num; tree is a heap on these *) >>>> END; >>>> >>>> It seems odd to me that, under these circumstances, x := x.lo would >>>> cause any sort of checking activity... >>>> >>>> I'm using a CM3 that's about a month old, on FreeBSD4. >>>> >>>> Mika >>>> >>>> P.S. Needless to say, the code in question runs about 10x faster under >>>> PM3 than with this relatively new CM3... but my m3gdb is having trouble >>>> with PM3's LONGREALs for some reason. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RTCollector.m3.orig URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RTCollector.m3.mine1 URL: From rodney.m.bates at cox.net Mon May 25 00:27:29 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 24 May 2009 17:27:29 -0500 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> References: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> Message-ID: <4A19C9D1.2030106@cox.net> Mika Nystrom wrote: > The weird thing is that it works really well SOMETIMES. > > Are there any workarounds? Where would I go poke if I wanted to fix it? > > My code is mostly floating point (double precision). I find myself typing > garbage like > > print (double *)(M3_adsf23_myVar+8) > > into the normal C gdb.... > > In m3gdb I am now getting the following error: > > (m3gdb) print self.srThreshold > $2 = Invalid C/C++ type code 44 in symbol table. > Ah yes, I am beginning to remember. This is a result of a half-fix I did a while back that made m3gdb at least not crash. m3gdb has Modula-3-specific type codes (no relation to TYPECODE) for floating types, but passes expressions to stock gdb code for printing, which knows nothing about the codes. > This is trying to print a field of type LONGREAL in an OBJECT: > > (m3gdb) print self > $3 = (*16_14838244*) OBJECT orderManager = 16_148382ec; marketDataManager = 16_14838224; tickers = 16_14838ab4; > limitsMap = NIL; orderSizeMap = NIL; rangeMult = ; invTilt = ; perfSmooth = ; times = {RECORD hour = 10; minute = 12; > second = 0; END, RECORD hour = 15; minute = 55; second = 0; END, RECORD hour = 15; minute = 30; second = 0; END, > RECORD hour = 9; minute = 30; second = 0; END, RECORD hour = 16; minute = 0; second = 0; END}; tz = 16_1a7bc7b0; > midnites = 16_1a7bc7dc; firstPeriod = 12638; initialPeriods = 390; limitsMap = 16_14838b18; orderSizeMap = 16_14838b38; > singleStockMarketMaker = NIL; ssTbl = 16_14833818; unitsPortfolioTilt = ; portTiltMode = UNITS; srThreshold = ; > dollarUnit = ; unitsPortTilt = ; grossLimit = ; overnightLimitMultiplier = ; rangeMultiplier = ; closeSmooth = ; END > > Mika > > "Rodney M. Bates" writes: > >> Floating point values in m3gdb is one area I have never done any >> work on at all, but I have been aware for a long time that it probably >> needs some. It just uses stock gdb's code, which also just uses >> the C builtin arithmetic on C floating types. At the very least, the >> mapping between C's two and Modula-3's three floating types, on >> the various targets, is purely an accident right now. I recall there >> is something wrong in the formatting too. >> >> Mika Nystrom wrote: >> Hi Modula-3ers, especially Tony, >> >>> I'm seeing the following behavior a lot in a program I'm running: >>> >>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:674 >>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:2271 >>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >>> ) >>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >>> >>> Is it normal for CheckLoadTracedRef to make system calls? >>> >>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >>> >>> >>> PROCEDURE Get ( tbl : Default; >>> READONLY k : Key.T; >>> VAR(*OUT*) v : Value.T): BOOLEAN = >>> VAR >>> x : Node := tbl.h.hi; >>> cmp : Cmp; >>> BEGIN >>> WHILE (x # NIL) DO >>> cmp := tbl.keyCompare (k, x.key); >>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>> IF (cmp < 0) >>> THEN x := x.lo; (* line 145 *) >>> ELSE x := x.hi; >>> END; >>> END; >>> RETURN FALSE; >>> END Get; >>> >>> where Node is defined as >>> >>> TYPE >>> Node = REF RECORD >>> key : Key.T; >>> value : Value.T; >>> lo : Node := NIL; >>> hi : Node := NIL; >>> priority: INTEGER (* random num; tree is a heap on these *) >>> END; >>> >>> It seems odd to me that, under these circumstances, x := x.lo would >>> cause any sort of checking activity... >>> >>> I'm using a CM3 that's about a month old, on FreeBSD4. >>> >>> Mika >>> >>> P.S. Needless to say, the code in question runs about 10x faster under >>> PM3 than with this relatively new CM3... but my m3gdb is having trouble >>> with PM3's LONGREALs for some reason. >>> >>> >>> > > From rodney.m.bates at cox.net Mon May 25 01:12:22 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 24 May 2009 18:12:22 -0500 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> References: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> Message-ID: <4A19D456.7040109@cox.net> Mika Nystrom wrote: > The weird thing is that it works really well SOMETIMES. > > Are there any workarounds? Where would I go poke if I wanted to fix it? > Look at the most recent changes to gdbtypes.h and m3-lang.c. Prior to this, m3gdb was segfaulting on requests to print floating values. I see I have a change to c-valprint.c that is not checked in: rodney at yellowstone:~/proj/m3/cm3-new/cm3/m3-sys/m3gdb/gdb/gdb$ ll c-valprint.c -rw-r--r-- 1 rodney rodney 18464 2009-02-26 16:08 c-valprint.c rodney at yellowstone:~/proj/m3/cm3-new/cm3/m3-sys/m3gdb/gdb/gdb$ cvs diff c-valprint.c Index: c-valprint.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3gdb/gdb/gdb/c-valprint.c,v retrieving revision 1.3 diff -r1.3 c-valprint.c 427a428,432 > #ifdef _LANG_m3 > case TYPE_CODE_M3_REAL: > case TYPE_CODE_M3_LONGREAL: > case TYPE_CODE_M3_EXTENDED: > #endif However, this just forces it through a path that prints *really* wrong values, which is no doubt why I didn't check it in. c-valprint.c is the place to start looking. I will try to look at this too, but may not get time for a while. > My code is mostly floating point (double precision). I find myself typing > garbage like > > print (double *)(M3_adsf23_myVar+8) > > into the normal C gdb.... > > In m3gdb I am now getting the following error: > > (m3gdb) print self.srThreshold > $2 = Invalid C/C++ type code 44 in symbol table. > > This is trying to print a field of type LONGREAL in an OBJECT: > > (m3gdb) print self > $3 = (*16_14838244*) OBJECT orderManager = 16_148382ec; marketDataManager = 16_14838224; tickers = 16_14838ab4; > limitsMap = NIL; orderSizeMap = NIL; rangeMult = ; invTilt = ; perfSmooth = ; times = {RECORD hour = 10; minute = 12; > second = 0; END, RECORD hour = 15; minute = 55; second = 0; END, RECORD hour = 15; minute = 30; second = 0; END, > RECORD hour = 9; minute = 30; second = 0; END, RECORD hour = 16; minute = 0; second = 0; END}; tz = 16_1a7bc7b0; > midnites = 16_1a7bc7dc; firstPeriod = 12638; initialPeriods = 390; limitsMap = 16_14838b18; orderSizeMap = 16_14838b38; > singleStockMarketMaker = NIL; ssTbl = 16_14833818; unitsPortfolioTilt = ; portTiltMode = UNITS; srThreshold = ; > dollarUnit = ; unitsPortTilt = ; grossLimit = ; overnightLimitMultiplier = ; rangeMultiplier = ; closeSmooth = ; END > > Mika > > "Rodney M. Bates" writes: > >> Floating point values in m3gdb is one area I have never done any >> work on at all, but I have been aware for a long time that it probably >> needs some. It just uses stock gdb's code, which also just uses >> the C builtin arithmetic on C floating types. At the very least, the >> mapping between C's two and Modula-3's three floating types, on >> the various targets, is purely an accident right now. I recall there >> is something wrong in the formatting too. >> >> Mika Nystrom wrote: >> Hi Modula-3ers, especially Tony, >> >>> I'm seeing the following behavior a lot in a program I'm running: >>> >>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:674 >>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:2271 >>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >>> ) >>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >>> >>> Is it normal for CheckLoadTracedRef to make system calls? >>> >>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >>> >>> >>> PROCEDURE Get ( tbl : Default; >>> READONLY k : Key.T; >>> VAR(*OUT*) v : Value.T): BOOLEAN = >>> VAR >>> x : Node := tbl.h.hi; >>> cmp : Cmp; >>> BEGIN >>> WHILE (x # NIL) DO >>> cmp := tbl.keyCompare (k, x.key); >>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>> IF (cmp < 0) >>> THEN x := x.lo; (* line 145 *) >>> ELSE x := x.hi; >>> END; >>> END; >>> RETURN FALSE; >>> END Get; >>> >>> where Node is defined as >>> >>> TYPE >>> Node = REF RECORD >>> key : Key.T; >>> value : Value.T; >>> lo : Node := NIL; >>> hi : Node := NIL; >>> priority: INTEGER (* random num; tree is a heap on these *) >>> END; >>> >>> It seems odd to me that, under these circumstances, x := x.lo would >>> cause any sort of checking activity... >>> >>> I'm using a CM3 that's about a month old, on FreeBSD4. >>> >>> Mika >>> >>> P.S. Needless to say, the code in question runs about 10x faster under >>> PM3 than with this relatively new CM3... but my m3gdb is having trouble >>> with PM3's LONGREALs for some reason. >>> >>> >>> > > From hosking at cs.purdue.edu Mon May 25 01:28:04 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 09:28:04 +1000 Subject: [M3devel] Rodney's letter to CACM Message-ID: <6A2B7D59-F4D4-47B3-A9AF-3AE8D2C02165@cs.purdue.edu> Kudos to Rodney Bates for his letter in CACM this last month lamenting that safe systems languages like Modula-3 still are not on the radar of the average developer out there. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon May 25 01:43:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 09:43:06 +1000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> References: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> Message-ID: <5B2975E7-016E-4B07-9AE5-CD0FC3FD0BB4@cs.purdue.edu> On 24 May 2009, at 06:34, Mika Nystrom wrote: > > Hi Modula-3ers, especially Tony, > > I'm seeing the following behavior a lot in a program I'm running: > > #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 > #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 > #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code > 30 in symbol table. > ) at ../src/runtime/common/RTCollector.m3:674 > #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 > in symbol table. > ) at ../src/runtime/common/RTCollector.m3:2271 > #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. > ) > at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ > libm3/src/sortedtable/SortedTable.mg:145 > > Is it normal for CheckLoadTracedRef to make system calls? > > Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from > SortedTable.mg): > > > PROCEDURE Get ( tbl : Default; > READONLY k : Key.T; > VAR(*OUT*) v : Value.T): BOOLEAN = > VAR > x : Node := tbl.h.hi; > cmp : Cmp; > BEGIN > WHILE (x # NIL) DO > cmp := tbl.keyCompare (k, x.key); > IF cmp = 0 THEN v := x.value; RETURN TRUE; END; > IF (cmp < 0) > THEN x := x.lo; (* line 145 *) This line is loading a reference from the lo field of the x record in the heap. To enter the call to the CheckLoadTracedRef routine x must have been marked gray (which means that it might contain references to white objects in the heap). In GC parlance, a gray object is one that the collector has not yet scanned to process its references (and copy their targets). White objects are uncopied (unmarked) objects, and so candidates for freeing at the end of the GC cycle. Because we cannot control what mutators do with white references (to white objects) -- i.e., where they store them, etc. -- we make sure that the mutator can never get a hold of one. > > ELSE x := x.hi; > END; > END; > RETURN FALSE; > END Get; > > where Node is defined as > > TYPE > Node = REF RECORD > key : Key.T; > value : Value.T; > lo : Node := NIL; > hi : Node := NIL; > priority: INTEGER (* random num; tree is a heap on these *) > END; > > It seems odd to me that, under these circumstances, x := x.lo would > cause any sort of checking activity... > > I'm using a CM3 that's about a month old, on FreeBSD4. > > Mika > > P.S. Needless to say, the code in question runs about 10x faster under > PM3 than with this relatively new CM3... but my m3gdb is having > trouble > with PM3's LONGREALs for some reason. From hosking at cs.purdue.edu Mon May 25 01:13:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 09:13:07 +1000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> References: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> Message-ID: The syscall is on the slow path in the barrier, but still perhaps too frequent. I will delete the accounting from the barrier (it's not really very useful there anyway). I hope the result is a big speedup! On 25 May 2009, at 04:15, Mika Nystrom wrote: > It makes a syscall. A slow one! > > Mika > > Jay writes: >> >> It does appear to be making policy decisions based on elapsed time, >> not just collecting times to report. >> >> Does gettimeofday on your system make a syscall or read a global? >> >> - Jay >> >> Maybe since the intent is just to process one object/page, the >> CollectorOn/Off calls can be replaced by just >> collectorOn := TRUE or FALSE >> >> ? For CollectorOff that isn't clear since it does more, but >> CollectorOn is just that plus time recording plus an assertion. >> Still, given that the intent is some limited processing, I think >> the time collection could be avoided and might not even be a good >> thing? >> >> >> - Jay >> >> >> ---------------------------------------- >>> To: m3devel at elegosoft.com >>> Date: Sat, 23 May 2009 13:34:16 -0700 >>> From: mika at async.caltech.edu >>> CC: mika at camembert.async.caltech.edu >>> Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? >>> >>> >>> Hi Modula-3ers, especially Tony, >>> >>> I'm seeing the following behavior a lot in a program I'm running: >>> >>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code >>> 30 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:674 >>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code >>> 46 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:2271 >>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol >>> table. >>> ) >>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ >>> libm3/src/sortedtable/SortedTable.mg:145 >>> >>> Is it normal for CheckLoadTracedRef to make system calls? >>> >>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code >>> (from SortedTable.mg): >>> >>> >>> PROCEDURE Get ( tbl : Default; >>> READONLY k : Key.T; >>> VAR(*OUT*) v : Value.T): BOOLEAN = >>> VAR >>> x : Node := tbl.h.hi; >>> cmp : Cmp; >>> BEGIN >>> WHILE (x # NIL) DO >>> cmp := tbl.keyCompare (k, x.key); >>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>> IF (cmp < 0) >>> THEN x := x.lo; (* line 145 *) >>> ELSE x := x.hi; >>> END; >>> END; >>> RETURN FALSE; >>> END Get; >>> >>> where Node is defined as >>> >>> TYPE >>> Node = REF RECORD >>> key : Key.T; >>> value : Value.T; >>> lo : Node := NIL; >>> hi : Node := NIL; >>> priority: INTEGER (* random num; tree is a heap on these *) >>> END; >>> >>> It seems odd to me that, under these circumstances, x := x.lo would >>> cause any sort of checking activity... >>> >>> I'm using a CM3 that's about a month old, on FreeBSD4. >>> >>> Mika >>> >>> P.S. Needless to say, the code in question runs about 10x faster >>> under >>> PM3 than with this relatively new CM3... but my m3gdb is having >>> trouble >>> with PM3's LONGREALs for some reason. From hosking at cs.purdue.edu Mon May 25 01:19:11 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 09:19:11 +1000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <1243197685.28115.4.camel@faramir.m3w.org> References: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> <1243197685.28115.4.camel@faramir.m3w.org> Message-ID: <70201A5C-3D01-4545-9CE9-2CF45831CFE5@cs.purdue.edu> All fixed -- I blew away the syscall. On 25 May 2009, at 06:41, Dragi?a Duri? wrote: > I have this straced many times on my LInUXLIBC6... Being strace - it's > syscall.. And slow??? Can we live without it? > > On Sun, 2009-05-24 at 11:15 -0700, Mika Nystrom wrote: >> It makes a syscall. A slow one! >> >> Mika > -- > Dragi?a Duri? From hosking at cs.purdue.edu Mon May 25 03:19:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 11:19:22 +1000 Subject: [M3devel] cm3 -O (cm3cg -O3) Message-ID: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> I've successfully bootstrapped with -O now for AMD64_DARWIN, PPC_DARWIN, I386_DARWIN, and SOLgnu, so I think the gcc-based backend is now in much better shape. The only common target missing here is x86/amd64 linux. I'll try to get around to those sometime soon. From hosking at cs.purdue.edu Mon May 25 03:22:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 11:22:45 +1000 Subject: [M3devel] cm3 -O (cm3cg -O3) In-Reply-To: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> References: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> Message-ID: <6D3FD65E-6106-4115-9DC8-05C1D9A89F9A@cs.purdue.edu> PS Where do I look in the Tinderbox configurations to have things build cm3 -O? I might be good to make that the default. On 25 May 2009, at 11:19, Tony Hosking wrote: > I've successfully bootstrapped with -O now for > > AMD64_DARWIN, > PPC_DARWIN, > I386_DARWIN, and > SOLgnu, > > so I think the gcc-based backend is now in much better shape. > > The only common target missing here is x86/amd64 linux. > > I'll try to get around to those sometime soon. From rodney.m.bates at cox.net Mon May 25 04:21:02 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 24 May 2009 21:21:02 -0500 Subject: [M3devel] LONGREAL and m3gdb--slight progress In-Reply-To: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> References: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> Message-ID: <4A1A008E.8090203@cox.net> Mika Nystrom wrote: > The weird thing is that it works really well SOMETIMES. > > Are there any workarounds? Where would I go poke if I wanted to fix it? > I just committed my previously mentioned change, after some experimentation. If you use the command "print/f floatvar", you will get the right value in floating notation. Just "print floatvar" displays garbage because it uses the wrong format. This might be a hint how to get the fix right also, but for now, it's a workaround, if you build the updated m3gdb. > My code is mostly floating point (double precision). I find myself typing > garbage like > > print (double *)(M3_adsf23_myVar+8) > > into the normal C gdb.... > > In m3gdb I am now getting the following error: > > (m3gdb) print self.srThreshold > $2 = Invalid C/C++ type code 44 in symbol table. > > This is trying to print a field of type LONGREAL in an OBJECT: > > (m3gdb) print self > $3 = (*16_14838244*) OBJECT orderManager = 16_148382ec; marketDataManager = 16_14838224; tickers = 16_14838ab4; > limitsMap = NIL; orderSizeMap = NIL; rangeMult = ; invTilt = ; perfSmooth = ; times = {RECORD hour = 10; minute = 12; > second = 0; END, RECORD hour = 15; minute = 55; second = 0; END, RECORD hour = 15; minute = 30; second = 0; END, > RECORD hour = 9; minute = 30; second = 0; END, RECORD hour = 16; minute = 0; second = 0; END}; tz = 16_1a7bc7b0; > midnites = 16_1a7bc7dc; firstPeriod = 12638; initialPeriods = 390; limitsMap = 16_14838b18; orderSizeMap = 16_14838b38; > singleStockMarketMaker = NIL; ssTbl = 16_14833818; unitsPortfolioTilt = ; portTiltMode = UNITS; srThreshold = ; > dollarUnit = ; unitsPortTilt = ; grossLimit = ; overnightLimitMultiplier = ; rangeMultiplier = ; closeSmooth = ; END > > Mika > > "Rodney M. Bates" writes: > >> Floating point values in m3gdb is one area I have never done any >> work on at all, but I have been aware for a long time that it probably >> needs some. It just uses stock gdb's code, which also just uses >> the C builtin arithmetic on C floating types. At the very least, the >> mapping between C's two and Modula-3's three floating types, on >> the various targets, is purely an accident right now. I recall there >> is something wrong in the formatting too. >> >> Mika Nystrom wrote: >> Hi Modula-3ers, especially Tony, >> >>> I'm seeing the following behavior a lot in a program I'm running: >>> >>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:674 >>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:2271 >>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >>> ) >>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >>> >>> Is it normal for CheckLoadTracedRef to make system calls? >>> >>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >>> >>> >>> PROCEDURE Get ( tbl : Default; >>> READONLY k : Key.T; >>> VAR(*OUT*) v : Value.T): BOOLEAN = >>> VAR >>> x : Node := tbl.h.hi; >>> cmp : Cmp; >>> BEGIN >>> WHILE (x # NIL) DO >>> cmp := tbl.keyCompare (k, x.key); >>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>> IF (cmp < 0) >>> THEN x := x.lo; (* line 145 *) >>> ELSE x := x.hi; >>> END; >>> END; >>> RETURN FALSE; >>> END Get; >>> >>> where Node is defined as >>> >>> TYPE >>> Node = REF RECORD >>> key : Key.T; >>> value : Value.T; >>> lo : Node := NIL; >>> hi : Node := NIL; >>> priority: INTEGER (* random num; tree is a heap on these *) >>> END; >>> >>> It seems odd to me that, under these circumstances, x := x.lo would >>> cause any sort of checking activity... >>> >>> I'm using a CM3 that's about a month old, on FreeBSD4. >>> >>> Mika >>> >>> P.S. Needless to say, the code in question runs about 10x faster under >>> PM3 than with this relatively new CM3... but my m3gdb is having trouble >>> with PM3's LONGREALs for some reason. >>> >>> >>> > > From jay.krell at cornell.edu Mon May 25 04:46:27 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 25 May 2009 02:46:27 +0000 Subject: [M3devel] cm3 -O (cm3cg -O3) In-Reply-To: <6D3FD65E-6106-4115-9DC8-05C1D9A89F9A@cs.purdue.edu> References: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> <6D3FD65E-6106-4115-9DC8-05C1D9A89F9A@cs.purdue.edu> Message-ID: -O is not interpreted as -O3 currently. One place to twiddle is m3-sys/cminstall/src/config-no-install/Unix.common proc m3_backend(source, object, optimize, debug) is ... < return try_exec (m3back, args, source, "-o", object) > return try_exec (m3back, "-O3", args, source, "-o", object) end I realize that's not ideal. I think if you: a) restore that so optimize => -O3 b) and then maybe, I'm just looking/guessing just now scripts/regression/defs.sh BUILDSCRIPT="./scripts/do-cm3-${BSET}.sh" .. OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 .. OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 probably omit one of them -- the one that uses the older compiler. Adding -O to these should get through with Olaf's recent changes. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Mon, 25 May 2009 11:22:45 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 -O (cm3cg -O3) > > PS Where do I look in the Tinderbox configurations to have things > build cm3 -O? I might be good to make that the default. > > On 25 May 2009, at 11:19, Tony Hosking wrote: > >> I've successfully bootstrapped with -O now for >> >> AMD64_DARWIN, >> PPC_DARWIN, >> I386_DARWIN, and >> SOLgnu, >> >> so I think the gcc-based backend is now in much better shape. >> >> The only common target missing here is x86/amd64 linux. >> >> I'll try to get around to those sometime soon. > From hosking at cs.purdue.edu Mon May 25 06:05:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 14:05:52 +1000 Subject: [M3devel] cm3 -O (cm3cg -O3) In-Reply-To: References: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> Message-ID: <40B2B113-D699-4B47-9704-99CF03430A9A@cs.purdue.edu> FYI: The bootstrapped compiler components (cm3.cfg, cm3cg.gz, cm3.gz) are available at ftp://ftp.cs.purdue.edu/pub/hosking/m3 in subdirectories drwxr-xr-x 2 hosking hosking 512 May 25 00:01 AMD64_DARWIN drwxr-xr-x 2 hosking hosking 512 May 25 00:01 AMD64_LINUX drwxr-xr-x 2 hosking hosking 512 May 25 00:01 I386_DARWIN drwxr-xr-x 2 hosking hosking 512 May 25 00:01 LINUXLIBC6 drwxr-xr-x 2 hosking hosking 512 May 25 00:01 PPC_DARWIN drwxr-xr-x 2 hosking hosking 512 May 25 00:02 SOLgnu On 25 May 2009, at 13:48, Tony Hosking wrote: > > > On 25 May 2009, at 11:19, Tony Hosking wrote: > >> I've successfully bootstrapped with -O now for >> >> AMD64_DARWIN, >> PPC_DARWIN, >> I386_DARWIN, and >> SOLgnu, >> >> so I think the gcc-based backend is now in much better shape. >> >> The only common target missing here is x86/amd64 linux. > > Ditto for > > LINUXLIBC6, and > AMD64_LINUX. > >> >> >> I'll try to get around to those sometime soon. >> From hosking at cs.purdue.edu Mon May 25 05:48:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 13:48:07 +1000 Subject: [M3devel] cm3 -O (cm3cg -O3) In-Reply-To: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> References: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> Message-ID: On 25 May 2009, at 11:19, Tony Hosking wrote: > I've successfully bootstrapped with -O now for > > AMD64_DARWIN, > PPC_DARWIN, > I386_DARWIN, and > SOLgnu, > > so I think the gcc-based backend is now in much better shape. > > The only common target missing here is x86/amd64 linux. Ditto for LINUXLIBC6, and AMD64_LINUX. > > > I'll try to get around to those sometime soon. > From hosking at cs.purdue.edu Mon May 25 06:19:42 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 14:19:42 +1000 Subject: [M3devel] cm3 -O (cm3cg -O3) In-Reply-To: References: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> <6D3FD65E-6106-4115-9DC8-05C1D9A89F9A@cs.purdue.edu> Message-ID: Hmm. Not sure exactly where to put -O in the boot scripts... On 25 May 2009, at 12:46, Jay wrote: > > -O is not interpreted as -O3 currently. > One place to twiddle is > m3-sys/cminstall/src/config-no-install/Unix.common > > proc m3_backend(source, object, optimize, debug) is > ... > < return try_exec (m3back, args, source, "-o", object) >> return try_exec (m3back, "-O3", args, source, "-o", object) > end > > I realize that's not ideal. > > I think if you: > a) restore that so optimize => -O3 > > b) and then maybe, I'm just looking/guessing just now > > scripts/regression/defs.sh > > BUILDSCRIPT="./scripts/do-cm3-${BSET}.sh" > .. > OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 > .. > OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 > > probably omit one of them -- the one that uses the older compiler. > Adding -O to these should get through with Olaf's recent changes. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: hosking at cs.purdue.edu >> Date: Mon, 25 May 2009 11:22:45 +1000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] cm3 -O (cm3cg -O3) >> >> PS Where do I look in the Tinderbox configurations to have things >> build cm3 -O? I might be good to make that the default. >> >> On 25 May 2009, at 11:19, Tony Hosking wrote: >> >>> I've successfully bootstrapped with -O now for >>> >>> AMD64_DARWIN, >>> PPC_DARWIN, >>> I386_DARWIN, and >>> SOLgnu, >>> >>> so I think the gcc-based backend is now in much better shape. >>> >>> The only common target missing here is x86/amd64 linux. >>> >>> I'll try to get around to those sometime soon. >> From jay.krell at cornell.edu Mon May 25 07:39:20 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 24 May 2009 22:39:20 -0700 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: References: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> Message-ID: <636DC9D9-FEFF-4504-9572-EB10845E0F5A@hotmail.com> It looked to me it was not slow path but every run. Also always setjmp/ pushframe/popframe too. I need to understand libunwind -- it seems to promise pretty portable stack walking. - Jay (phone) On May 24, 2009, at 4:13 PM, Tony Hosking wrote: > The syscall is on the slow path in the barrier, but still perhaps > too frequent. I will delete the accounting from the barrier (it's > not really very useful there anyway). I hope the result is a big > speedup! > > On 25 May 2009, at 04:15, Mika Nystrom wrote: > >> It makes a syscall. A slow one! >> >> Mika >> >> Jay writes: >>> >>> It does appear to be making policy decisions based on elapsed >>> time, not just collecting times to report. >>> >>> Does gettimeofday on your system make a syscall or read a global? >>> >>> - Jay >>> >>> Maybe since the intent is just to process one object/page, the >>> CollectorOn/Off calls can be replaced by just >>> collectorOn := TRUE or FALSE >>> >>> ? For CollectorOff that isn't clear since it does more, but >>> CollectorOn is just that plus time recording plus an assertion. >>> Still, given that the intent is some limited processing, I think >>> the time collection could be avoided and might not even be a good >>> thing? >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> To: m3devel at elegosoft.com >>>> Date: Sat, 23 May 2009 13:34:16 -0700 >>>> From: mika at async.caltech.edu >>>> CC: mika at camembert.async.caltech.edu >>>> Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? >>>> >>>> >>>> Hi Modula-3ers, especially Tony, >>>> >>>> I'm seeing the following behavior a lot in a program I'm running: >>>> >>>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code >>>> 30 in symbol table. >>>> ) at ../src/runtime/common/RTCollector.m3:674 >>>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code >>>> 46 in symbol table. >>>> ) at ../src/runtime/common/RTCollector.m3:2271 >>>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol >>>> table. >>>> ) >>>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ >>>> libm3/src/sortedtable/SortedTable.mg:145 >>>> >>>> Is it normal for CheckLoadTracedRef to make system calls? >>>> >>>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code >>>> (from SortedTable.mg): >>>> >>>> >>>> PROCEDURE Get ( tbl : Default; >>>> READONLY k : Key.T; >>>> VAR(*OUT*) v : Value.T): BOOLEAN = >>>> VAR >>>> x : Node := tbl.h.hi; >>>> cmp : Cmp; >>>> BEGIN >>>> WHILE (x # NIL) DO >>>> cmp := tbl.keyCompare (k, x.key); >>>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>>> IF (cmp < 0) >>>> THEN x := x.lo; (* line 145 *) >>>> ELSE x := x.hi; >>>> END; >>>> END; >>>> RETURN FALSE; >>>> END Get; >>>> >>>> where Node is defined as >>>> >>>> TYPE >>>> Node = REF RECORD >>>> key : Key.T; >>>> value : Value.T; >>>> lo : Node := NIL; >>>> hi : Node := NIL; >>>> priority: INTEGER (* random num; tree is a heap on these *) >>>> END; >>>> >>>> It seems odd to me that, under these circumstances, x := x.lo would >>>> cause any sort of checking activity... >>>> >>>> I'm using a CM3 that's about a month old, on FreeBSD4. >>>> >>>> Mika >>>> >>>> P.S. Needless to say, the code in question runs about 10x faster >>>> under >>>> PM3 than with this relatively new CM3... but my m3gdb is having >>>> trouble >>>> with PM3's LONGREALs for some reason. > > From hosking at cs.purdue.edu Mon May 25 09:07:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 17:07:13 +1000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <636DC9D9-FEFF-4504-9572-EB10845E0F5A@hotmail.com> References: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> <636DC9D9-FEFF-4504-9572-EB10845E0F5A@hotmail.com> Message-ID: <15E8B704-6E76-4766-B384-F74B4CCB620A@cs.purdue.edu> There is an inline fast path inserted by the compiler that checks the grayness of the object being loaded from. The call to CheckLoadTracedRef should *not* occur on every pointer load from the heap, only on those from gray objects. The TRY block is necessary for now because the cleaner might throw and exception. This is an area I am going to revisit soon, so hopefully we can dispense with it. On 25 May 2009, at 15:39, jay.krell at cornell.edu wrote: > It looked to me it was not slow path but every run. Also always > setjmp/pushframe/popframe too. I need to understand libunwind -- it > seems to promise pretty portable stack walking. > > - Jay (phone) > > On May 24, 2009, at 4:13 PM, Tony Hosking > wrote: > >> The syscall is on the slow path in the barrier, but still perhaps >> too frequent. I will delete the accounting from the barrier (it's >> not really very useful there anyway). I hope the result is a big >> speedup! >> >> On 25 May 2009, at 04:15, Mika Nystrom wrote: >> >>> It makes a syscall. A slow one! >>> >>> Mika >>> >>> Jay writes: >>>> >>>> It does appear to be making policy decisions based on elapsed >>>> time, not just collecting times to report. >>>> >>>> Does gettimeofday on your system make a syscall or read a global? >>>> >>>> - Jay >>>> >>>> Maybe since the intent is just to process one object/page, the >>>> CollectorOn/Off calls can be replaced by just >>>> collectorOn := TRUE or FALSE >>>> >>>> ? For CollectorOff that isn't clear since it does more, but >>>> CollectorOn is just that plus time recording plus an assertion. >>>> Still, given that the intent is some limited processing, I think >>>> the time collection could be avoided and might not even be a good >>>> thing? >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> To: m3devel at elegosoft.com >>>>> Date: Sat, 23 May 2009 13:34:16 -0700 >>>>> From: mika at async.caltech.edu >>>>> CC: mika at camembert.async.caltech.edu >>>>> Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? >>>>> >>>>> >>>>> Hi Modula-3ers, especially Tony, >>>>> >>>>> I'm seeing the following behavior a lot in a program I'm running: >>>>> >>>>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>>>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>>>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type >>>>> code 30 in symbol table. >>>>> ) at ../src/runtime/common/RTCollector.m3:674 >>>>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code >>>>> 46 in symbol table. >>>>> ) at ../src/runtime/common/RTCollector.m3:2271 >>>>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol >>>>> table. >>>>> ) >>>>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ >>>>> libm3/src/sortedtable/SortedTable.mg:145 >>>>> >>>>> Is it normal for CheckLoadTracedRef to make system calls? >>>>> >>>>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code >>>>> (from SortedTable.mg): >>>>> >>>>> >>>>> PROCEDURE Get ( tbl : Default; >>>>> READONLY k : Key.T; >>>>> VAR(*OUT*) v : Value.T): BOOLEAN = >>>>> VAR >>>>> x : Node := tbl.h.hi; >>>>> cmp : Cmp; >>>>> BEGIN >>>>> WHILE (x # NIL) DO >>>>> cmp := tbl.keyCompare (k, x.key); >>>>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>>>> IF (cmp < 0) >>>>> THEN x := x.lo; (* line 145 *) >>>>> ELSE x := x.hi; >>>>> END; >>>>> END; >>>>> RETURN FALSE; >>>>> END Get; >>>>> >>>>> where Node is defined as >>>>> >>>>> TYPE >>>>> Node = REF RECORD >>>>> key : Key.T; >>>>> value : Value.T; >>>>> lo : Node := NIL; >>>>> hi : Node := NIL; >>>>> priority: INTEGER (* random num; tree is a heap on these *) >>>>> END; >>>>> >>>>> It seems odd to me that, under these circumstances, x := x.lo >>>>> would >>>>> cause any sort of checking activity... >>>>> >>>>> I'm using a CM3 that's about a month old, on FreeBSD4. >>>>> >>>>> Mika >>>>> >>>>> P.S. Needless to say, the code in question runs about 10x faster >>>>> under >>>>> PM3 than with this relatively new CM3... but my m3gdb is having >>>>> trouble >>>>> with PM3's LONGREALs for some reason. >> >> From wagner at elegosoft.com Mon May 25 15:59:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 25 May 2009 15:59:53 +0200 Subject: [M3devel] cm3 -O (cm3cg -O3) In-Reply-To: References: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> <6D3FD65E-6106-4115-9DC8-05C1D9A89F9A@cs.purdue.edu> Message-ID: <20090525155953.qvn7zk2cgkss0c08@mail.elegosoft.com> Quoting Tony Hosking : > Hmm. Not sure exactly where to put -O in the boot scripts... Sorry, I was out of town for some days and had no proper internet connection, so I couldn't respond earlier. Globablly setting BUILDARGS=-O in regression/defs.sh should do the trick. Please try that; I cannot test myself before tomorrow evening... Olaf > On 25 May 2009, at 12:46, Jay wrote: > >> >> -O is not interpreted as -O3 currently. >> One place to twiddle is >> m3-sys/cminstall/src/config-no-install/Unix.common >> >> proc m3_backend(source, object, optimize, debug) is >> ... >> < return try_exec (m3back, args, source, "-o", object) >>> return try_exec (m3back, "-O3", args, source, "-o", object) >> end >> >> I realize that's not ideal. >> >> I think if you: >> a) restore that so optimize => -O3 >> >> b) and then maybe, I'm just looking/guessing just now >> >> scripts/regression/defs.sh >> >> BUILDSCRIPT="./scripts/do-cm3-${BSET}.sh" >> .. >> OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 >> .. >> OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 >> >> probably omit one of them -- the one that uses the older compiler. >> Adding -O to these should get through with Olaf's recent changes. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: hosking at cs.purdue.edu >>> Date: Mon, 25 May 2009 11:22:45 +1000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] cm3 -O (cm3cg -O3) >>> >>> PS Where do I look in the Tinderbox configurations to have things >>> build cm3 -O? I might be good to make that the default. >>> >>> On 25 May 2009, at 11:19, Tony Hosking wrote: >>> >>>> I've successfully bootstrapped with -O now for >>>> >>>> AMD64_DARWIN, >>>> PPC_DARWIN, >>>> I386_DARWIN, and >>>> SOLgnu, >>>> >>>> so I think the gcc-based backend is now in much better shape. >>>> >>>> The only common target missing here is x86/amd64 linux. >>>> >>>> I'll try to get around to those sometime soon. >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From eiserlohpp at yahoo.com Wed May 27 03:44:47 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Tue, 26 May 2009 18:44:47 -0700 (PDT) Subject: [M3devel] [m3devel] Packaged AMD64_LINUX for debian Message-ID: <205613.68479.qm@web56801.mail.re3.yahoo.com> Hi Gang, Okay, here is my take on packaging CM3 for the Debian distribution of Linux. http://www.eiserloh.org/~peter/modula3/#debian-pkg I did install this onto my laptop It is built against cm3-5.8.1.20090522. Could those of you with Debian distributions check it out, and send me any comment for improving the packaging. Please add the following to your /etc/apt/sources.list deb http://www.eiserloh.org/mirrors/modula3/debian lenny main deb-src http://www.eiserloh.org/mirrors/modula3/debian lenny main NOTE-0: You will have to change your CM3 environment variable. I also created a MANPATH to include "/usr/cm3/man". NOTE-1: I have explicitly omitted obliq, juno and anything that depends upon them. NOTE-2: I have moved most of the config files to /usr/cm3/etc, the only one remaining in the binary directory is cm3.cfg. These invoke include("../etc/foo.common"). Changing the location of "cm3.cfg" would require actually changing the code of cm3. Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Wed May 27 08:57:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 27 May 2009 08:57:27 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages Message-ID: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> Hi everybody, I've uploaded some packages for FreeBSD and AMD64_LINUX to http://www.opencm3.net/releng/ for evaluation. For both platforms there are two base archives, which can be used to install a working CM3 system. I'll use the FreeBSD packages as examples: cm3-bin-core-FreeBSD4-d5.8.1-RC1.tgz 100% 16MB 57.8KB/s 04:50 cm3-bin-min-FreeBSD4-d5.8.1-RC1.tgz 100% 7480KB 58.0KB/s 02:09 -min- is just the minimal working system with cm3, m3core and libm3 which we had in all previous releases, too. -core- is a more useful system which contains some additional tools and libraries and could be the base for something like a standard CM3 setup. These packages include the installer (though it does not do much more than copying files) and Jay's new configuration files. All other available software has been archived in binary packages which contain parts of a CM3 _workspace_ (*-bin-ws-*). These packages are pre-compiled and can be shipped with multiple calls to cm3; for convenience a small installation script has been added. The classification of packages is somewhat arbitrary, though I tried to make some meaningful distinctions; it is open for discussion. cm3-bin-ws-anim-FreeBSD4-d5.8.1-RC1.tgz 100% 25MB 57.3KB/s 07:20 cm3-bin-ws-caltech-parser-FreeBSD4-d5.8.1-RC1 100% 4441KB 60.0KB/s 01:14 cm3-bin-ws-core-FreeBSD4-d5.8.1-RC1.tgz 100% 99MB 57.5KB/s 29:21 cm3-bin-ws-cvsup-FreeBSD4-d5.8.1-RC1.tgz 100% 1584KB 66.0KB/s 00:24 cm3-bin-ws-database-FreeBSD4-d5.8.1-RC1.tgz 100% 330KB 109.9KB/s 00:03 cm3-bin-ws-demo-FreeBSD4-d5.8.1-RC1.tgz 100% 512KB 102.5KB/s 00:05 cm3-bin-ws-devlib-FreeBSD4-d5.8.1-RC1.tgz 100% 4539KB 60.5KB/s 01:15 cm3-bin-ws-game-FreeBSD4-d5.8.1-RC1.tgz 100% 2069KB 62.7KB/s 00:33 cm3-bin-ws-gui-FreeBSD4-d5.8.1-RC1.tgz 100% 6322KB 59.1KB/s 01:47 cm3-bin-ws-juno-FreeBSD4-d5.8.1-RC1.tgz 100% 3545KB 61.1KB/s 00:58 cm3-bin-ws-m3devtool-FreeBSD4-d5.8.1-RC1.tgz 100% 20MB 57.9KB/s 05:56 cm3-bin-ws-m3gdb-FreeBSD4-d5.8.1-RC1.tgz 100% 36MB 58.0KB/s 10:35 cm3-bin-ws-math-FreeBSD4-d5.8.1-RC1.tgz 100% 2378KB 62.6KB/s 00:38 cm3-bin-ws-obliq-FreeBSD4-d5.8.1-RC1.tgz 100% 4399KB 60.3KB/s 01:13 cm3-bin-ws-tool-FreeBSD4-d5.8.1-RC1.tgz 100% 1796KB 64.2KB/s 00:28 cm3-bin-ws-webdev-FreeBSD4-d5.8.1-RC1.tgz 100% 986KB 65.8KB/s 00:15 These packages can simply be built with the script make-dist.sh which should work on all target platforms. With SHIPRC=yes all results will be shipped via scp, too. Before others start to contribute their release candidates for other platforms, I'd like to do the following: 1. make sure that we all agree on the distribution format and details. 2. Actually move the default for configuration files to cm3/etc, though I objected that change for this release previously. But it won't get easier if we wait, and I think we can built in some backward compatibility that should help during the migration. It will take some more time though. 3. Write up some user documentation on how to use the release. (Actually, this is one of the more important points.) 4. If everything is settled, set a tag for others to build their packages (something like RELENG_5_8_1_RC1 or similar). 5. Try to integrate available system-dependent packages like those provided by Peter Eiserloh for Debian. Then we can add everything to the CM3 WWW pages and publicly announce the release candidate. Of course we need to test the packages carefully, and fix all deficiencies found in RC2 or RC3. (I haven't done any tests yet, just watched the regression tests in Tinderbox.) Please test and comment, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Wed May 27 09:04:49 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 27 May 2009 09:04:49 +0200 Subject: [M3devel] [m3devel] Packaged AMD64_LINUX for debian In-Reply-To: <205613.68479.qm@web56801.mail.re3.yahoo.com> References: <205613.68479.qm@web56801.mail.re3.yahoo.com> Message-ID: <1243407889.6124.20.camel@faramir.m3w.org> I have work-in-progress rpm creation, my distro is Fedora but no reason for your .debs or my .rpms to have any issues running on any deb/rpm distro. But - I see problem here with any changing of source for packaging needs. Only change I've made was for CM3_INSTALL_PREFIX so I can make rpms incrementally. Almost every of my m3 projects is rpm packaged and I don't like to have all-inclusive rpm. So I am working on scripts to make rpm recipes for small sets of packages. My current recipes are for cm3 (compiler, m3core, libm3, tcp, udp, set, tempfiles, patternmatching, parseparams) divided to cm3 and cm3-devel, separate rpm with m3gdb and cvsup (binary rpms are suplib, suplib-devel, cvsup). And all of them are building LINUXLIBC6 and AMD64_LINUX binary rpms. One issue with how-cm3-does-it is, IMO, /usr/local/cm3/lib directory... It must be lib64 on AMD64_LINUX, at least because we may need both LINUXLIBC6 and AMD64_LINUX libraries present on same system. In my case, I need it because some of C support librarires like panda (basic PDF creation primitives) are not 64 bit clean. Along the way I am making template recipes and working on deriving of dependicies from m3makefiles. Don't know if there is exact recipe translator for rpm-deb...? On Tue, 2009-05-26 at 18:44 -0700, Peter Eiserloh wrote: > NOTE-2: I have moved most of the config files to /usr/cm3/etc, > the only one remaining in the binary directory is cm3.cfg. > These invoke include("../etc/foo.common"). Changing the > location of "cm3.cfg" would require actually changing the > code of cm3. > -- Dragi?a Duri? From dragisha at m3w.org Wed May 27 12:36:34 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 27 May 2009 12:36:34 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> Message-ID: <1243420594.6124.36.camel@faramir.m3w.org> Long time ago, I was Modula-2 programmer with lots of my own libraries doing everything from keyboard input handling and textual windows, relational database, to complex data browsing and input and postscript reporting... After a while (2-3 yrs of dev) I had a problem sorting out library packages and dependicies - same as we have right now. Solution to this is order detection, and some topological sorting voodoo with result grouping... In my (historical) case I've got six groups of modules with controlled inter-group dependicies. My math terminology is a bit rusty, but partially ordered set of all packages is our input data, and output data we get from such a process is partially ordered set of groups of packages. Each element of this final set is one of our release packages. min, std, core, .... is going to my nerves since long time ago. I am surely not only one involved with same reaction :). On Wed, 2009-05-27 at 08:57 +0200, Olaf Wagner wrote: > > The classification of packages is somewhat arbitrary, though I tried > to make some meaningful distinctions; it is open for discussion. -- Dragi?a Duri? From hendrik at topoi.pooq.com Wed May 27 22:17:02 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 27 May 2009 16:17:02 -0400 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> Message-ID: <20090527201702.GA20296@topoi.pooq.com> On Wed, May 27, 2009 at 08:57:27AM +0200, Olaf Wagner wrote: > > 2. Actually move the default for configuration files to cm3/etc, Debian may well insist that configuration files be in /etc/cm3. > though I objected that change for this release previously. But it won't > get easier if we wait, and I think we can built in some backward > compatibility that should help during the migration. It will take some > more time though. -- hendrik From hendrik at topoi.pooq.com Wed May 27 23:37:21 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 27 May 2009 17:37:21 -0400 Subject: [M3devel] [m3devel] Packaged AMD64_LINUX for debian In-Reply-To: <205613.68479.qm@web56801.mail.re3.yahoo.com> References: <205613.68479.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090527213721.GB20296@topoi.pooq.com> On Tue, May 26, 2009 at 06:44:47PM -0700, Peter Eiserloh wrote: > > Please add the following to your /etc/apt/sources.list > > deb http://www.eiserloh.org/mirrors/modula3/debian lenny main > deb-src http://www.eiserloh.org/mirrors/modula3/debian lenny main Did this, got nowhere, perhaps because it was a 32-bit system running squeeze. I got messages like: http://www.eiserloh.org lenny Release.gpg [IGNORED] Just about everything from that site was [IGNORED], except for http://www.eiserloh.org lenny/main Packages [ERROR] 404 Not Found http://www.eiserloh.org lenny/main Sources [ERROR] Is it worth trying on my AMD64, which runs etch instead of Lenny (becasue after upgrading a working copy of my system, the NFS server stopped working)? -- hendrik From jay.krell at cornell.edu Thu May 28 02:28:04 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 28 May 2009 00:28:04 +0000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <1243420594.6124.36.camel@faramir.m3w.org> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> Message-ID: > problem sorting out library packages and > dependicies - same as we have right now. We have a problem sorting out dependencies? I thought the main dilemna was one of "taste" -- too many installable packages vs. too few. Or is it that "taste" and "dependencies" clash? > Solution to this is order detection, and some topological > sorting voodoo If you are satisfied with a linear order that works, pkginfo.txt has one. If you want something that allows for concurrency, well, we don't have infrastructure currently to take advantage of it. I believe a non-linearized graph is not difficult to build given what cm3 knows by reading the m3makefiles. Graphs often make my head hurt though. We should probably, in some future release, 1) move package-to-source-directory feature into cm3 2) allow cm3 to build multiple packages concurrently. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: wagner at elegosoft.com > Date: Wed, 27 May 2009 12:36:34 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages > > Long time ago, I was Modula-2 programmer with lots of my own libraries > doing everything from keyboard input handling and textual windows, > relational database, to complex data browsing and input and postscript > reporting... After a while (2-3 yrs of dev) I had a problem sorting out > library packages and dependicies - same as we have right now. > > Solution to this is order detection, and some topological sorting voodoo > with result grouping... In my (historical) case I've got six groups of > modules with controlled inter-group dependicies. My math terminology is > a bit rusty, but partially ordered set of all packages is our input > data, and output data we get from such a process is partially ordered > set of groups of packages. Each element of this final set is one of our > release packages. > > min, std, core, .... is going to my nerves since long time ago. I am > surely not only one involved with same reaction :). > > > On Wed, 2009-05-27 at 08:57 +0200, Olaf Wagner wrote: >> >> The classification of packages is somewhat arbitrary, though I tried >> to make some meaningful distinctions; it is open for discussion. > -- > Dragi?a Duri? > From jay.krell at cornell.edu Thu May 28 02:35:57 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 28 May 2009 00:35:57 +0000 Subject: [M3devel] [m3devel] Packaged AMD64_LINUX for debian In-Reply-To: <1243407889.6124.20.camel@faramir.m3w.org> References: <205613.68479.qm@web56801.mail.re3.yahoo.com> <1243407889.6124.20.camel@faramir.m3w.org> Message-ID: > One issue with how-cm3-does-it is, IMO, > /usr/local/cm3/lib directory...It must be lib64 on AMD64_LINUX Is this always true or only sometimes? Are there "pure" 64bit systems? Should be if exist or unconditional? Also, do you know about hypothetical PPC64_LINUX, MIP64_LINUX, SPARC64_LINUX? (I only have sparc64 running so far.) That is, all 64bit Linux or only AMD64? Thanks, - Jay ---------------------------------------- > From: dragisha at m3w.org > To: eiserlohpp at yahoo.com > Date: Wed, 27 May 2009 09:04:49 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [m3devel] Packaged AMD64_LINUX for debian > > I have work-in-progress rpm creation, my distro is Fedora but no reason > for your .debs or my .rpms to have any issues running on any deb/rpm > distro. > > But - I see problem here with any changing of source for packaging > needs. Only change I've made was for CM3_INSTALL_PREFIX so I can make > rpms incrementally. Almost every of my m3 projects is rpm packaged and I > don't like to have all-inclusive rpm. So I am working on scripts to make > rpm recipes for small sets of packages. My current recipes are for cm3 > (compiler, m3core, libm3, tcp, udp, set, tempfiles, patternmatching, > parseparams) divided to cm3 and cm3-devel, separate rpm with m3gdb and > cvsup (binary rpms are suplib, suplib-devel, cvsup). And all of them are > building LINUXLIBC6 and AMD64_LINUX binary rpms. > > One issue with how-cm3-does-it is, IMO, /usr/local/cm3/lib directory... > It must be lib64 on AMD64_LINUX, at least because we may need both > LINUXLIBC6 and AMD64_LINUX libraries present on same system. In my case, > I need it because some of C support librarires like panda (basic PDF > creation primitives) are not 64 bit clean. > > Along the way I am making template recipes and working on deriving of > dependicies from m3makefiles. Don't know if there is exact recipe > translator for rpm-deb...? > > On Tue, 2009-05-26 at 18:44 -0700, Peter Eiserloh wrote: >> NOTE-2: I have moved most of the config files to /usr/cm3/etc, >> the only one remaining in the binary directory is cm3.cfg. >> These invoke include("../etc/foo.common"). Changing the >> location of "cm3.cfg" would require actually changing the >> code of cm3. >> > -- > Dragi?a Duri? > From jay.krell at cornell.edu Thu May 28 02:32:20 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 28 May 2009 00:32:20 +0000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090527201702.GA20296@topoi.pooq.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> Message-ID: I'm still of the opinion that these might not be configuration files. Just because they are text, doesn't make it so. Just because /some/ people edit them, doesn't make it so. If lots of people edit them, then it is more convincing. It is a gray, but I suspect the mere naming of the files, and the fact that install used to always change them (but it doesn't now) has everyone convinced. One of the questions is, what happens upon "upgrade"? Is that supposed to leave /etc alone, and keep working with whatever is out there? I'd maybe rather not be limited like that. (But I actually build-in a lot of backward compat so that I can bootstrap using current config files, which I can control, instead of whatever the old releases came with; this is however a difference between the Tinderbox and my own workflow..) Or keep churn low so that upgrade can do some merge? Ditto. - Jay ---------------------------------------- > Date: Wed, 27 May 2009 16:17:02 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages > > On Wed, May 27, 2009 at 08:57:27AM +0200, Olaf Wagner wrote: >> >> 2. Actually move the default for configuration files to cm3/etc, > > Debian may well insist that configuration files be in /etc/cm3. > >> though I objected that change for this release previously. But it won't >> get easier if we wait, and I think we can built in some backward >> compatibility that should help during the migration. It will take some >> more time though. > > -- hendrik > From hendrik at topoi.pooq.com Thu May 28 05:00:20 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 27 May 2009 23:00:20 -0400 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> Message-ID: <20090528030020.GA20885@topoi.pooq.com> On Thu, May 28, 2009 at 12:32:20AM +0000, Jay wrote: > > I'm still of the opinion that these might not be configuration files. > Just because they are text, doesn't make it so. > Just because /some/ people edit them, doesn't make it so. > If lots of people edit them, then it is more convincing. > > It is a gray, but I suspect the mere naming of the files, and the fact that install used to always change them (but it doesn't now) has everyone convinced. > > One of the questions is, what happens upon "upgrade"? > Is that supposed to leave /etc alone, and keep working with whatever is out there? I'd maybe rather not be limited like that. (But I actually build-in a lot of backward compat so that I can bootstrap using current config files, which I can control, instead of whatever the old releases came with; this is however a difference between the Tinderbox and my own workflow..) > Or keep churn low so that upgrade can do some merge? Ditto. If theyre not configuration files, then, of course they should *not* be in /etc. Is there any chance that the cm3 user might want to change them? I'm not talking about making an entirely new set while cross-building for another system here. -- hendrik From hosking at cs.purdue.edu Thu May 28 05:54:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 May 2009 13:54:32 +1000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528030020.GA20885@topoi.pooq.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528030020.GA20885@topoi.pooq.com> Message-ID: <690E4B4C-BE47-4A7B-BBB5-3A33E97F6ADE@cs.purdue.edu> I would argue strongly that a use would *not* want to change the config file. It's definitions are intrinsic to the installation. On 28 May 2009, at 13:00, hendrik at topoi.pooq.com wrote: > On Thu, May 28, 2009 at 12:32:20AM +0000, Jay wrote: >> >> I'm still of the opinion that these might not be configuration files. >> Just because they are text, doesn't make it so. >> Just because /some/ people edit them, doesn't make it so. >> If lots of people edit them, then it is more convincing. >> >> It is a gray, but I suspect the mere naming of the files, and the >> fact that install used to always change them (but it doesn't now) >> has everyone convinced. >> >> One of the questions is, what happens upon "upgrade"? >> Is that supposed to leave /etc alone, and keep working with >> whatever is out there? I'd maybe rather not be limited like that. >> (But I actually build-in a lot of backward compat so that I can >> bootstrap using current config files, which I can control, instead >> of whatever the old releases came with; this is however a >> difference between the Tinderbox and my own workflow..) >> Or keep churn low so that upgrade can do some merge? Ditto. > > If theyre not configuration files, then, of course they should *not* > be > in /etc. Is there any chance that the cm3 user might want to change > them? I'm not talking about making an entirely new set while > cross-building for another system here. > > -- hendrik From hosking at cs.purdue.edu Thu May 28 06:00:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 May 2009 14:00:30 +1000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <690E4B4C-BE47-4A7B-BBB5-3A33E97F6ADE@cs.purdue.edu> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528030020.GA20885@topoi.pooq.com> <690E4B4C-BE47-4A7B-BBB5-3A33E97F6ADE@cs.purdue.edu> Message-ID: <2E2B406C-B232-43A7-9E5F-D09961F8BAB5@cs.purdue.edu> On 28 May 2009, at 13:54, Tony Hosking wrote: > I would argue strongly that a use would *not* want to change the > config file. It's definitions are intrinsic to the installation. ^^^^ ordinary user > > > On 28 May 2009, at 13:00, hendrik at topoi.pooq.com wrote: > >> On Thu, May 28, 2009 at 12:32:20AM +0000, Jay wrote: >>> >>> I'm still of the opinion that these might not be configuration >>> files. >>> Just because they are text, doesn't make it so. >>> Just because /some/ people edit them, doesn't make it so. >>> If lots of people edit them, then it is more convincing. >>> >>> It is a gray, but I suspect the mere naming of the files, and the >>> fact that install used to always change them (but it doesn't now) >>> has everyone convinced. >>> >>> One of the questions is, what happens upon "upgrade"? >>> Is that supposed to leave /etc alone, and keep working with >>> whatever is out there? I'd maybe rather not be limited like that. >>> (But I actually build-in a lot of backward compat so that I can >>> bootstrap using current config files, which I can control, instead >>> of whatever the old releases came with; this is however a >>> difference between the Tinderbox and my own workflow..) >>> Or keep churn low so that upgrade can do some merge? Ditto. >> >> If theyre not configuration files, then, of course they should >> *not* be >> in /etc. Is there any chance that the cm3 user might want to change >> them? I'm not talking about making an entirely new set while >> cross-building for another system here. >> >> -- hendrik From wagner at elegosoft.com Thu May 28 08:34:19 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2009 08:34:19 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090527201702.GA20296@topoi.pooq.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> Message-ID: <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, May 27, 2009 at 08:57:27AM +0200, Olaf Wagner wrote: >> >> 2. Actually move the default for configuration files to cm3/etc, > > Debian may well insist that configuration files be in /etc/cm3. Understood. I'd think that something like $ORIGIN/../etc/cm3.cfg:$ORIGIN/cm3.cfg:/usr/local/etc:/usr/etc as a default may be reasonable. For more exotic setups, the binaries must either be recompiled or the environment variable M3CONFIG must be used. >> though I objected that change for this release previously. But it won't >> get easier if we wait, and I think we can built in some backward >> compatibility that should help during the migration. It will take some >> more time though. > > -- hendrik > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu May 28 08:37:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 May 2009 16:37:17 +1000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> Message-ID: <2B4C1BD4-22D5-41CF-B4B6-93AB4D6A4DF9@cs.purdue.edu> Again, I don't see why the config file should be thought of as something that users should edit. It is specific to a given installation, not to configuration of the packages after installation. On 28 May 2009, at 16:34, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> On Wed, May 27, 2009 at 08:57:27AM +0200, Olaf Wagner wrote: >>> >>> 2. Actually move the default for configuration files to cm3/etc, >> >> Debian may well insist that configuration files be in /etc/cm3. > > Understood. I'd think that something like > > $ORIGIN/../etc/cm3.cfg:$ORIGIN/cm3.cfg:/usr/local/etc:/usr/etc > > as a default may be reasonable. For more exotic setups, the > binaries must either be recompiled or the environment variable > M3CONFIG must be used. > >>> though I objected that change for this release previously. But >>> it won't >>> get easier if we wait, and I think we can built in some backward >>> compatibility that should help during the migration. It will >>> take some >>> more time though. >> >> -- hendrik >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From wagner at elegosoft.com Thu May 28 08:44:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2009 08:44:55 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <2B4C1BD4-22D5-41CF-B4B6-93AB4D6A4DF9@cs.purdue.edu> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> <2B4C1BD4-22D5-41CF-B4B6-93AB4D6A4DF9@cs.purdue.edu> Message-ID: <20090528084455.26ipgni96o0kos08@mail.elegosoft.com> Quoting Tony Hosking : > Again, I don't see why the config file should be thought of as > something that users should edit. It is specific to a given > installation, not to configuration of the packages after installation. I'd second that, too, but then almost all software configuration files living in .../etc on Unix systems should not be edited by ordinary users. They're there so that the software can be adapted to different system setups and conventions, that is, they should and must be edited by the system administrator. I think this is true for at least the part that defines the global paths used by the installation: PKG_INSTALL, BIN_INSTALL, PKG_USE, etc. It is criticised, if I understand it correctly, that CM3 is not flexible enough in allowing this kind of customization currently. And that we do not comply to the file system hierarchy standards. Moving (part of) our config files into some etc directory would be a step into this direction. Olaf > On 28 May 2009, at 16:34, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: >> >>> On Wed, May 27, 2009 at 08:57:27AM +0200, Olaf Wagner wrote: >>>> >>>> 2. Actually move the default for configuration files to cm3/etc, >>> >>> Debian may well insist that configuration files be in /etc/cm3. >> >> Understood. I'd think that something like >> >> $ORIGIN/../etc/cm3.cfg:$ORIGIN/cm3.cfg:/usr/local/etc:/usr/etc >> >> as a default may be reasonable. For more exotic setups, the >> binaries must either be recompiled or the environment variable >> M3CONFIG must be used. >> >>>> though I objected that change for this release previously. But it won't >>>> get easier if we wait, and I think we can built in some backward >>>> compatibility that should help during the migration. It will take some >>>> more time though. >>> >>> -- hendrik >>> >>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From eiserlohpp at yahoo.com Thu May 28 08:46:53 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 27 May 2009 23:46:53 -0700 (PDT) Subject: [M3devel] M3devel Digest, Vol 31, Issue 38 Message-ID: <175728.17785.qm@web56807.mail.re3.yahoo.com> Ah, yes, I only built binaries for AMD64_LINUX, against debian-lenny (Debian 5.0). Which goes in the directory "dists/lenny/main/binary-amd64", but your system was looking for a directory "dists/squeeze/main/binary-i386", and failing to find the Packages file. To get up and running quickly, use "$apt-get source cm3", which will work as a normal user. --- Oops, sorry about that, okay those files are there now. --- from http://www.eiserloh.org/mirrors/modula3/debian/dists/lenny/main/sources/ along with the other two files. As root, tell apt-get to update its list of . $ sudo apt-get update $ apt-get source cm3 apt-get will not only download the source and diff, but also apply those diffs, giving you my source tree. Now cd into the source tree, and make everything. Unfortunately, I didn't use fakeroot, so you will have be root to build the *.debs. $ sudo make -f debian/rules binary Once that is done, cd to the parent directory, and find all the *.deb files. Install that to a local repository and make the index files. $ sudo mkdir /usr/local/packages $ sudo cp *.deb /usr/local/packages I created a Makefile that builds those for me, here is a copy of my Makefile. --- BEGIN Makefile --- # -------------------------------------------------------------------- # /usr/local/packages/Makefile # Use this to build the Packages file for all the debian packages. # -------------------------------------------------------------------- subdirs = binary-amd64 prefix = dists/lenny/main/ # ---------------------------------------------- all: package_index sources_index clean: for dir in $(subdirs) ; do \ $(RM) $${dir}/Packages* ; \ done $(RM) sources/Source* # ------------- package_index: for dir in $(subdirs) ; do \ dpkg-scanpackages $${dir} /dev/null $(prefix) >$${dir}/Packages ; \ gzip -9 -c $${dir}/Packages >$${dir}/Packages.gz ; \ done sources_index: dpkg-scansources source /dev/null $(prefix) >source/Sources gzip -9 -c source/Sources >source/Sources.gz --- END Makefile --- Now, how could I make those *.deb files for etch, or even squeeze (debian-unstable). I could create a chroot, and install etch onto that, and rebuild an AMD64_LINUX (debian-etch). Basically, the only difference would be that everything gets linked against a different version of libc. I don't think I could get a 32-bit OS chrooted, as my kernel is 64-bit, and expecting syscalls from a 64-bit user space. Hmm, thoughts of QEMU come to mind. Actually, QEMU brings the ability to port everything, as I could run a PPC, ARM, or any other host machine supported by QEMU. More work, oh well! I should be able to find a chunk of time this weekend to start playing with QEMU. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ > ------------------------------ > > Message: 3 > Date: Wed, 27 May 2009 17:37:21 -0400 > From: hendrik at topoi.pooq.com > Subject: Re: [M3devel] [m3devel] Packaged AMD64_LINUX for > debian > To: m3devel at elegosoft.com > Message-ID: <20090527213721.GB20296 at topoi.pooq.com> > Content-Type: text/plain; charset=us-ascii > > On Tue, May 26, 2009 at 06:44:47PM -0700, Peter Eiserloh > wrote: > > > > Please add the following to your > /etc/apt/sources.list > > > >? ? deb http://www.eiserloh.org/mirrors/modula3/debian lenny > main > >? ? deb-src http://www.eiserloh.org/mirrors/modula3/debian lenny > main > > Did this, got nowhere, perhaps because it was a 32-bit > system running > squeeze.? I got messages like: > > http://www.eiserloh.org lenny Release.gpg [IGNORED] > > Just about everything from that site was [IGNORED], except > for > > http://www.eiserloh.org lenny/main Packages [ERROR] > 404 Not Found > http://www.eiserloh.org lenny/main Sources [ERROR] > > Is it worth trying on my AMD64, which runs etch instead of > Lenny > (becasue after upgrading a working copy of my system, the > NFS server > stopped working)? > > -- hendrik > From dragisha at m3w.org Thu May 28 08:58:41 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 May 2009 08:58:41 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> Message-ID: <1243493921.8596.10.camel@faramir.m3w.org> On Thu, 2009-05-28 at 00:28 +0000, Jay wrote: > > > problem sorting out library packages and > > dependicies - same as we have right now. > > We have a problem sorting out dependencies? > I thought the main dilemna was one of "taste" -- too many installable > packages vs. too few. Or is it that "taste" and "dependencies" clash? My English can be hectic, but I think i wrote something like "partially ordered set of groups of packages". People usually do edit scripts when selecting what they need - and things like juno, mentor, games,, go out... My proposal is to make logical groups - neither "too many" nor "too few". And obviously not min "vs." "core" vs. "std" where variants are subsets.. pkginfo.txt is part of one solution I do not find optimal. As we are still talking RELENG - obviously not only I. -- Dragi?a Duri? From wagner at elegosoft.com Thu May 28 11:42:19 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2009 11:42:19 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <1243493921.8596.10.camel@faramir.m3w.org> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> Message-ID: <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> Quoting Dragi?a Duri? : > On Thu, 2009-05-28 at 00:28 +0000, Jay wrote: >> >> > problem sorting out library packages and >> > dependicies - same as we have right now. >> >> We have a problem sorting out dependencies? >> I thought the main dilemna was one of "taste" -- too many installable >> packages vs. too few. Or is it that "taste" and "dependencies" clash? > > My English can be hectic, but I think i wrote something like "partially > ordered set of groups of packages". People usually do edit scripts when > selecting what they need - and things like juno, mentor, games,, go > out... My proposal is to make logical groups - neither "too many" nor > "too few". And obviously not min "vs." "core" vs. "std" where variants > are subsets.. Well, I made a suggestion how to classify the packages into disjunct sets -- the only overlap is (should be?) between the base installation packages (either min or core). There is no min, std, core in the -bin-ws- packages. So far I only got one comment about the bicycle package being in two sets, which has been corrected. Olaf > pkginfo.txt is part of one solution I do not find optimal. As we are > still talking RELENG - obviously not only I. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Thu May 28 14:40:34 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 May 2009 14:40:34 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> Message-ID: <1243514434.8596.16.camel@faramir.m3w.org> Do we have some txt files where these packages are listed by content? Or only way to see them is download? Second... In cvsup package you have suplib AND cvsup? How do you build it? By shipping suplib to /usr/local/cm3/... and then building cvsup? On Thu, 2009-05-28 at 11:42 +0200, Olaf Wagner wrote: > Well, I made a suggestion how to classify the packages into disjunct > sets -- the only overlap is (should be?) between the base installation > packages (either min or core). There is no min, std, core in the > -bin-ws- > packages. > > So far I only got one comment about the bicycle package being in > two sets, which has been corrected. > > Olaf -- Dragi?a Duri? From jay.krell at cornell.edu Thu May 28 14:50:57 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 28 May 2009 12:50:57 +0000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <1243514434.8596.16.camel@faramir.m3w.org> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> Message-ID: Yes we have suplib and cvsup. In general yes, if you are going to ship something, you first have to build and ship its dependencies. If you are not going to ship something, then you just have build its dependencies, with overrides, and can't ship them. I believe this does force like an alternating build, ship, build, ship cycle, which then leads to the ship/install/admin/su problem that I've almost never seen well solved. You can build as root, or you can ship to $HOME, or you can be very interactive. Some of the BSD package systems have something where they can become root back and forth. OR you can ship to a temporary place, targz it up, su, untargz to the real install place, that's not bad. I just have to fix that ".." bug. I will. cvsup had something strange about it but I think we removed its strangeness. Like, it could never be shipped. > Do we have some txt files where these packages are listed by content? Or Not that I know of. > Or only way to see them is download? Browse the CVS repository or the hyperlinked source that is also there? There's also a package download page I haven't tried. I admit the need to ship a static lib seems dubious. But it does have to be built with overrides or not. Furthermore I'm not sure this whole system is as good as it could be, but I also know it's not likely a well solved problem by anyone. For example if you read the diy-linux list you'll see they have a problem using gcc without running install. It used to work for them but then it bot broken. > not a well solved problem by anyone People fiddle around with chroot, "jail", installing to $HOME, static linking, but I'm not sure any of these are satisfactory, certainly not static linking. There are difficult problems around "just what is meant to be shared". - Jay ---------------------------------------- > From: dragisha at m3w.org > To: wagner at elegosoft.com > Date: Thu, 28 May 2009 14:40:34 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages > > Do we have some txt files where these packages are listed by content? Or > only way to see them is download? > > Second... In cvsup package you have suplib AND cvsup? How do you build > it? By shipping suplib to /usr/local/cm3/... and then building cvsup? > > On Thu, 2009-05-28 at 11:42 +0200, Olaf Wagner wrote: >> Well, I made a suggestion how to classify the packages into disjunct >> sets -- the only overlap is (should be?) between the base installation >> packages (either min or core). There is no min, std, core in the >> -bin-ws- >> packages. >> >> So far I only got one comment about the bicycle package being in >> two sets, which has been corrected. >> >> Olaf > -- > Dragi?a Duri? > From dragisha at m3w.org Thu May 28 14:51:53 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 May 2009 14:51:53 +0200 Subject: [M3devel] [m3devel] Packaged AMD64_LINUX for debian In-Reply-To: References: <205613.68479.qm@web56801.mail.re3.yahoo.com> <1243407889.6124.20.camel@faramir.m3w.org> Message-ID: <1243515113.8596.25.camel@faramir.m3w.org> Very good question, http://proton.pathname.com/fhs/pub/fhs-2.3.html#LIB64 sez: /lib64 and /lib32 : 64/32-bit libraries (architecture dependent) The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib. The 64-bit architecture IA64 must place 64-bit libraries in /lib. Tip Rationale This is a refinement of the general rules for /lib and /usr/lib. The architectures PPC64, s390x, sparc64 and AMD64 support support both 32-bit (for s390 more precise 31-bit) and 64-bit programs. Using lib for 32-bit binaries allows existing binaries from the 32-bit systems to work without any changes: such binaries are expected to be numerous. IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries (and hence libraries) on that architecture. On Thu, 2009-05-28 at 00:35 +0000, Jay wrote: > > One issue with how-cm3-does-it is, IMO, > > /usr/local/cm3/lib directory...It must be lib64 on AMD64_LINUX > > > Is this always true or only sometimes? > Are there "pure" 64bit systems? > Should be if exist or unconditional? > Also, do you know about hypothetical PPC64_LINUX, MIP64_LINUX, > SPARC64_LINUX? > (I only have sparc64 running so far.) > That is, all 64bit Linux or only AMD64? -- Dragi?a Duri? From dragisha at m3w.org Thu May 28 15:06:47 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 May 2009 15:06:47 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> Message-ID: <1243516007.8596.38.camel@faramir.m3w.org> On Thu, 2009-05-28 at 12:50 +0000, Jay wrote: > > OR you can ship to a temporary place, targz it up, su, untargz to the > real install place, that's not bad. I just have to fix that ".." bug. > I will. > This is solved, with CM3_INSTALL_PREFIX, for simple cases. Can be done for less simple ones, but that solution is insufficient for package groups like this one - suplib and cvsup in same package, and to build cvsup correctly you must ship suplib. What I did in my rpm system so far is to make suplib source rpm create two packages, suplib and suplib-devel. For building of cvsup I need both, for running - only first. Following this train of thought, I think we need more packages, and have them obviously grouped, like: cm3-cvsup-suplib cm3-cvsup-suplib-devel cm3-cvsup (cvsup proper, we escape cm3-cvsup-cvsup here) cm3-cvsupd (also instead of cvsup-cvsupd, it's obvious) In RPM lingo I can have (and do): suplib suplib-devel cvsup And for Group I can have some more info, visible while querying/browsing packages. % rpm -q suplib -i Name : suplib Relocations: (not relocatable) Version : 5.8.1 Vendor: (none) Release : 1 Build Date: Sun 24 May 2009 01:20:55 PM CEST Install Date: Sun 24 May 2009 01:22:27 PM CEST Build Host: faramir.m3w.org Group : Applications/Internet Source RPM: suplib-5.8.1-1.src.rpm Size : 2308450 License: Copyright 1996-2003 John D. Polstra. All rights reserved. Signature : (none) Packager : dragisha at m3w.org URL : http://www.cvsup.org Summary : CVSup support library Description : CVSup support library In RPM spec file we can put nice info for group, once we have package grouping sorted out. > > cvsup had something strange about it but I think we removed its > strangeness. > Like, it could never be shipped. :) It is not strange, it only has it's own libraries. It's until we sort "standard" packages out and learn it's normal to have fancy hierarchy of libraries and modules in out projects as we have in cm3. -- Dragi?a Duri? From wagner at elegosoft.com Thu May 28 15:24:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2009 15:24:13 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <1243514434.8596.16.camel@faramir.m3w.org> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> Message-ID: <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> Quoting Dragi?a Duri? : > Do we have some txt files where these packages are listed by content? Or > only way to see them is download? All groups are listed in pkginfo.txt. > Second... In cvsup package you have suplib AND cvsup? How do you build > it? By shipping suplib to /usr/local/cm3/... and then building cvsup? All bin packages are pre-built and can be installed with the included install.sh (which simply executes cm3 -ship multiple times). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Thu May 28 15:31:20 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 May 2009 15:31:20 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> Message-ID: <1243517480.8596.39.camel@faramir.m3w.org> This is not something we can "sell" to Linux people. On Thu, 2009-05-28 at 15:24 +0200, Olaf Wagner wrote: > > Second... In cvsup package you have suplib AND cvsup? How do you > build > > it? By shipping suplib to /usr/local/cm3/... and then building > cvsup? > > All bin packages are pre-built and can be installed with the > included install.sh (which simply executes cm3 -ship multiple times). > > Olaf -- Dragi?a Duri? From dragisha at m3w.org Thu May 28 15:57:02 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 May 2009 15:57:02 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> Message-ID: <1243519022.8596.47.camel@faramir.m3w.org> On Thu, 2009-05-28 at 15:24 +0200, Olaf Wagner wrote: > All bin packages are pre-built and can be installed with the > included install.sh (which simply executes cm3 -ship multiple times). As I said, this kind of binary packages are not something Linux people want. Also, in standard RPM based distro (and most are, except ones which are Debian based but they have similar packaging philosophy) we have features which make handling of big number of interdependent packages easy task. Installation of cvsup on fresh system will pull suplib and also package(s) with m3core/libm3/set/parseparams/patternmatching libs... Big number of packages or not, it's something RPM (system) will do for me. I have some (RPM spec file) templates developed which enable making packages which contain interdependent packages and once I get content of your packages (combined with some free time) I will make spec files with same content. -- Dragi?a Duri? From jay.krell at cornell.edu Thu May 28 17:19:34 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 28 May 2009 15:19:34 +0000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <1243519022.8596.47.camel@faramir.m3w.org> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> <1243519022.8596.47.camel@faramir.m3w.org> Message-ID: > we have features which make handling of big number of interdependent packages So, maybe we should just have a package per directory, cm3-foo (cm3-cm3, cm3-m3cc, cm3-m3core, cm3-libm3, cm3-ui, m3-vbt, cm3-formsedit, etc.), and leave just the old min and all for people not using packages? Is that ok or obnoxious? When we get really advanced, cm3 -ship will have flags -rpm and -deb or such (and -addtar?)? On the matter of config files btw, there are maybe three "levels": 1 not edited by anyone 2 edited by (every/many) root/admin/installer 3 edited by every user I wasn't trying to distinguish between 2 and 3, but rather 1 and 2. If few root/admin/installers edit the files, just like they don't edit "binaries", then it is #1. If every/many do, then #2. Just because it is a text file, doesn't mean it is meant to be edited. It is a gray line between compiled code in cm3 and script in cm3.cfg. Ultimately root can edit any file anywhere, be they text files outside of /etc or binaries in /usr/bin. I do think though there is a question of what "upgrades" do, if "upgrade" is free to overwrite files, is obligated to leave them alone, or is obligated to merge. Here again, as in many things, I think many people (not necessarily here and certainly not limited to here) believe in a truth that they believe is obvious but in fact there is probably no good answer. There may be other issues here. I don't know what all is implied by a file being in /etc vs. /usr/local/etc vs. /usr/local/bin. To be more constructive though..maybe we should discuss just how people tend to edit their config files? Do you put in full paths to cc, gcc, ld? Or is $PATH search a good compromise that folks can live with? I'm a little conflicted on this matter, because often for cross builds you have platform-gcc instead of gcc. I could make a symlink and alter path, but I don't know if there is a clear best. Maybe cm3 should do something here? Maybe $CC environment variable is the way? Do you edit the compile/link flags? Maybe $CFLAGS/$LDFLAGS we should use?? Have you rewritten them entirely? :) Have you further factored/merged some of the reduncancies or odd factoring I have left in? (Unix.common vs. Darwin.common vs. Solaris.common vs. HPUX.common is still a bit wierd and not always the right balance.) Are there just a few environment variables or command line switches we can put to capture what people do? I know about lib64. - Jay > From: dragisha at m3w.org > To: wagner at elegosoft.com > Date: Thu, 28 May 2009 15:57:02 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages > > On Thu, 2009-05-28 at 15:24 +0200, Olaf Wagner wrote: > > All bin packages are pre-built and can be installed with the > > included install.sh (which simply executes cm3 -ship multiple times). > > As I said, this kind of binary packages are not something Linux people > want. > > Also, in standard RPM based distro (and most are, except ones which are > Debian based but they have similar packaging philosophy) we have > features which make handling of big number of interdependent packages > easy task. Installation of cvsup on fresh system will pull suplib and > also package(s) with m3core/libm3/set/parseparams/patternmatching > libs... Big number of packages or not, it's something RPM (system) will > do for me. > > I have some (RPM spec file) templates developed which enable making > packages which contain interdependent packages and once I get content of > your packages (combined with some free time) I will make spec files with > same content. > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu May 28 17:52:49 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 28 May 2009 11:52:49 -0400 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528084455.26ipgni96o0kos08@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> <2B4C1BD4-22D5-41CF-B4B6-93AB4D6A4DF9@cs.purdue.edu> <20090528084455.26ipgni96o0kos08@mail.elegosoft.com> Message-ID: <4A1E7B02.1E75.00D7.1@scires.com> Of course, there are platforms that don't use etc, like Windows. I'm ok with whatever approach makes sense for the given platforms wrt configuration files; however, I will point out that for those of us who've been using Modula-3 for a long time, that we are used to having to mess around with the config files to get things to work correctly. I'm all for simplifying things and would love NOT to HAVE to mess with the config files, as long as whatever approach is taken allows for adequate flexibility in adapting to particular installation requirements. On a Windows platform, most programs are stored in %ProgramFiles%, typically "C:\Program Files", but CM3 is more than a program, it is a repository of packages etc. Typically, ordinary users don't get write privileges to %ProgramFiles%. So, I've always put my installation in "C:\cm3", but then some folks might have multiple drives and partitions and want to put it somewhere else. Indeed, I once used "D:\cm3". Another thing that the config files had to be adapted for in the past was where to find the C compiler, libraries, and linker. Today, we have the free Microsoft Visual Studio tools, but there are other vendors of C compilers and linkers. Which of these will the config files support? Critical Mass also adapted the config file to tell "Reactor" where to find certain things. Of course, now we have CM3IDE as the replacement for Reactor and I've tried to adapt the code to deal with some of Jay's changes to the config files. My 2 cents: Whatever is decided, we need to document it, and make it widely known (i.e., publicize it) so that us old timers understand whether we should or should not keep tweaking the config files. I know Jay has been making great strides with the config files, but I don't believe everyone is "clued-into" what has been done and the rationale behind it, hence the need for some publicized documentation. Then, we need to go back and revise old documentation, such as that with CM3IDE, to reflect the new reality. I can make doc changes, but I need to understand new content first. Regards, Randy >>> Olaf Wagner 5/28/2009 2:44 AM >>> Quoting Tony Hosking : > Again, I don't see why the config file should be thought of as > something that users should edit. It is specific to a given > installation, not to configuration of the packages after installation. I'd second that, too, but then almost all software configuration files living in .../etc on Unix systems should not be edited by ordinary users. They're there so that the software can be adapted to different system setups and conventions, that is, they should and must be edited by the system administrator. I think this is true for at least the part that defines the global paths used by the installation: PKG_INSTALL, BIN_INSTALL, PKG_USE, etc. It is criticised, if I understand it correctly, that CM3 is not flexible enough in allowing this kind of customization currently. And that we do not comply to the file system hierarchy standards. Moving (part of) our config files into some etc directory would be a step into this direction. Olaf > On 28 May 2009, at 16:34, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: >> >>> On Wed, May 27, 2009 at 08:57:27AM +0200, Olaf Wagner wrote: >>>> >>>> 2. Actually move the default for configuration files to cm3/etc, >>> >>> Debian may well insist that configuration files be in /etc/cm3. >> >> Understood. I'd think that something like >> >> $ORIGIN/../etc/cm3.cfg:$ORIGIN/cm3.cfg:/usr/local/etc:/usr/etc >> >> as a default may be reasonable. For more exotic setups, the >> binaries must either be recompiled or the environment variable >> M3CONFIG must be used. >> >>>> though I objected that change for this release previously. But it won't >>>> get easier if we wait, and I think we can built in some backward >>>> compatibility that should help during the migration. It will take some >>>> more time though. >>> >>> -- hendrik >>> >>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu May 28 22:20:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2009 22:20:27 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <1243519022.8596.47.camel@faramir.m3w.org> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> <1243519022.8596.47.camel@faramir.m3w.org> Message-ID: <20090528222027.py10dhgckggcwccc@mail.elegosoft.com> Quoting Dragi?a Duri? : > On Thu, 2009-05-28 at 15:24 +0200, Olaf Wagner wrote: >> All bin packages are pre-built and can be installed with the >> included install.sh (which simply executes cm3 -ship multiple times). > > As I said, this kind of binary packages are not something Linux people > want. Why? > Also, in standard RPM based distro (and most are, except ones which are > Debian based but they have similar packaging philosophy) we have > features which make handling of big number of interdependent packages > easy task. Installation of cvsup on fresh system will pull suplib and > also package(s) with m3core/libm3/set/parseparams/patternmatching > libs... Big number of packages or not, it's something RPM (system) will > do for me. > > I have some (RPM spec file) templates developed which enable making > packages which contain interdependent packages and once I get content of > your packages (combined with some free time) I will make spec files with > same content. If nobody thinks these bin packages are useful, we can leave them out without any problem. I thought they would be a good compromise as they provide both sources and binaries and may be used as the base for both kinds of system dependent packages. As I said before, I don't really intend to provide packages for Debian, Ubuntu, RedHat, Solaris, MacOS, Windows, Solaris etc. That's something I cannot manage and maintain. Elego can provide web and disk resources, but everything else needs to be done by dedicated users. If the packaging and installation process for these systems will be completely decoupled from any kind of standard release packages, that's fine too. Nonetheless I'd like to get to the point where there's a working release again which can be used by anyone in the same way. So if there is anything such a standard distribution should provide which can be done without much efforts, I'd like to hear about it. I tried to conform to Peter Eiserloh's wishes, as far as it they can be reasonably fulfilled within some weeks. Now I'm not really sure what it is that's wanted. Thanks for your input, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Thu May 28 22:39:33 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 28 May 2009 16:39:33 -0400 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528222027.py10dhgckggcwccc@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> <1243519022.8596.47.camel@faramir.m3w.org> <20090528222027.py10dhgckggcwccc@mail.elegosoft.com> Message-ID: <4A1EBE33.1E75.00D7.1@scires.com> Olaf: I'll be glad to provide Windows distributions once we settle on a release. I can also test now any pre-release on Windows. Just let me know what to check out using TortoiseCVS so I get the right sources. I'll also document everything I do so we can use that for helping people who want to build from scratch on Windows. My idea is to provide GZIP TAR archives at a minimum, plus a Windows install program for those who want to go that route. Regards, Randy >>> Olaf Wagner 5/28/2009 4:20 PM >>> As I said before, I don't really intend to provide packages for Debian, Ubuntu, RedHat, Solaris, MacOS, Windows, Solaris etc. That's something I cannot manage and maintain. Elego can provide web and disk resources, but everything else needs to be done by dedicated users. CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri May 29 03:17:08 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 29 May 2009 01:17:08 +0000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <4A1E7B02.1E75.00D7.1@scires.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> <2B4C1BD4-22D5-41CF-B4B6-93AB4D6A4DF9@cs.purdue.edu> <20090528084455.26ipgni96o0kos08@mail.elegosoft.com> <4A1E7B02.1E75.00D7.1@scires.com> Message-ID: > I know Jay has been making great strides with the config files, but > I don't believe everyone is "clued-into" what has been done and the rationale behind it Here's a summary: - The config files used to each be independent, but /highly/ redundant. They had a lot of identical or nearly-and-could-be code. I factored a lot, so there is shared code. Worse -- besides the redundancy between the different platforms, every config file was duplicated twice in the tree with very minor differences. It was confusing and a maintenance problem. - The installer would write full paths to compiler/linker. That is one viable approach. If people really like that, we should factor it in somehow. What I do instead is just run leaf "gcc", "cl", etc. and depend on $PATH search. Also regarding paths to libraries, I found what they were on each of my system and assume they are pretty well standardized. If someone really has a custom layout, they will need to edit the files. If someone doesn't want the gcc that comes first in $PATH, they will either need to change $PATH or edit the file. At some point, you know, if someone wants something different, they can also edit the source to cm3 and rebuild it. If the config files can be made correct enough for enough people, you can consider these things in the same category. You know, you don't install all *.sh, *.pl, *.py code to /etc. You pick some "knobs". Not too many, not too few. There were generally more than necessary before I believe. But maybe I'm wrong here? On *BSD some things would not be in the default install, but there'd be a port/package, so where the port installed, I'd use that path. This is grayer, since you can also install things yourself and the default from "upstream" might be different. On Mac OSX I would generally get the third party package and find its default. e.g. postgresql. Something more is probably needed here, like file existance checks. - Full path to the cm3 install implemented via path() and walking from there. path() is the path of the quake config file that calls it. cm3.cfg knows it is next to the compiler, or maybe in a sibling directory to it, that the install root is path()/.. - I have some semantic changes such as use of $ORIGIN, use of hardlinks instead of symlinks (so $ORIGIN works better), updating NT386 for use with current and older tools, to statically link in shared data (the set/hand stuff). - I introduced an optional toplevel cm3.cfg that probes around for the "real" config file, such as to use the current one in the source tree, so I don't have to keep copying it around, or or to use one based on an an environment variable specifying target platform. Probing around in the source tree is not appropriate for a "release" version and that is taken into account. There is also probing around in the release directory. There is also probing for a backend, again for cross build purposes. The exact probed paths and their sequence is certainly up to debate. - In terms of compatibility, there are also runtime checks, so that older cm3cg isn't given an -m32 flag that is rejects, stuff like that. Also workarounds for bootstraping from a compiler with the old GC implementation. After this release I think we'll declare that you can only bootstrap from this release or newer and remove various compatibility hacks. Maybe. - Jay Date: Thu, 28 May 2009 11:52:49 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages Of course, there are platforms that don't use etc, like Windows. I'm ok with whatever approach makes sense for the given platforms wrt configuration files; however, I will point out that for those of us who've been using Modula-3 for a long time, that we are used to having to mess around with the config files to get things to work correctly. I'm all for simplifying things and would love NOT to HAVE to mess with the config files, as long as whatever approach is taken allows for adequate flexibility in adapting to particular installation requirements. On a Windows platform, most programs are stored in %ProgramFiles%, typically "C:\Program Files", but CM3 is more than a program, it is a repository of packages etc. Typically, ordinary users don't get write privileges to %ProgramFiles%. So, I've always put my installation in "C:\cm3", but then some folks might have multiple drives and partitions and want to put it somewhere else. Indeed, I once used "D:\cm3". Another thing that the config files had to be adapted for in the past was where to find the C compiler, libraries, and linker. Today, we have the free Microsoft Visual Studio tools, but there are other vendors of C compilers and linkers. Which of these will the config files support? Critical Mass also adapted the config file to tell "Reactor" where to find certain things. Of course, now we have CM3IDE as the replacement for Reactor and I've tried to adapt the code to deal with some of Jay's changes to the config files. My 2 cents: Whatever is decided, we need to document it, and make it widely known (i.e., publicize it) so that us old timers understand whether we should or should not keep tweaking the config files. I know Jay has been making great strides with the config files, but I don't believe everyone is "clued-into" what has been done and the rationale behind it, hence the need for some publicized documentation. Then, we need to go back and revise old documentation, such as that with CM3IDE, to reflect the new reality. I can make doc changes, but I need to understand new content first. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri May 29 04:48:02 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 28 May 2009 19:48:02 -0700 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> <2B4C1BD4-22D5-41CF-B4B6-93AB4D6A4DF9@cs.purdue.edu> <20090528084455.26ipgni96o0kos08@mail.elegosoft.com> <4A1E7B02.1E75.00D7.1@scires.com> Message-ID: I missed a question: we only currently support Microsoft Visual C++ for NT386, pretty much any version, and gcc for MIN/GNU but consider those maybe not well supported by me. I am aware of a number of alternatives such as OpenWatcom, Digital Mars, Borland, lcc, old Symantec, old Metrowerks, I have used them all some but nothing real yet and not near top of my list by far. - Jay (phone) On May 28, 2009, at 6:17 PM, Jay wrote: > > I know Jay has been making great strides with the config files, > but > > I don't believe everyone is "clued-into" what has been done and > the rationale behind it > > Here's a summary: > > - The config files used to each be > independent, but /highly/ redundant. > They had a lot of identical or nearly-and-could-be code. > I factored a lot, so there is shared code. > Worse -- besides the redundancy between the > different platforms, every config file was duplicated > twice in the tree with very minor differences. > It was confusing and a maintenance problem. > > - The installer would write full paths > to compiler/linker. That is one viable approach. > If people really like that, we should factor it in somehow. > What I do instead is just run leaf "gcc", "cl", etc. > and depend on $PATH search. > Also regarding paths to libraries, I found what > they were on each of my system and assume they > are pretty well standardized. If someone really > has a custom layout, they will need to edit the files. > If someone doesn't want the gcc that comes first > in $PATH, they will either need to change $PATH > or edit the file. > > At some point, you know, if someone wants something > different, they can also edit the source to cm3 and rebuild it. > If the config files can be made correct enough > for enough people, you can consider these things > in the same category. > > You know, you don't install all *.sh, *.pl, *.py code to /etc. > You pick some "knobs". Not too many, not too few. > There were generally more than necessary before I believe. > But maybe I'm wrong here? > > On *BSD some things would not be in the default install, but > there'd be a port/package, so where the port installed, I'd use > that path. > This is grayer, since you can also install things yourself and the > default from "upstream" might be different. > > On Mac OSX I would generally get the third party package and > find its default. > > e.g. postgresql. > > Something more is probably needed here, like file existance checks. > > - Full path to the cm3 install implemented via path() and walking > from there. path() is the path of the quake config file > that calls it. cm3.cfg knows it is next to the compiler, or maybe > in a sibling directory to it, that the install root is path()/.. > > - I have some semantic changes such as use of $ORIGIN, > use of hardlinks instead of symlinks (so $ORIGIN works better), > updating NT386 for use with current and older tools, to > statically link in shared data (the set/hand stuff). > > > - I introduced an optional toplevel cm3.cfg that > probes around for the "real" config file, such > as to use the current one in the source tree, > so I don't have to keep copying it around, or > or to use one based on an an environment variable > specifying target platform. Probing around > in the source tree is not appropriate for > a "release" version and that is taken into > account. There is also probing around in the release > directory. There is also probing for a backend, > again for cross build purposes. The exact probed > paths and their sequence is certainly up to debate. > > - In terms of compatibility, there are also runtime checks, so that > older cm3cg isn't given an -m32 flag that is rejects, stuff like > that. > Also workarounds for bootstraping from a compiler with the old GC > implementation. > > After this release I think we'll declare that you can only > bootstrap from > this release or newer and remove various compatibility hacks. > Maybe. > > - Jay > > > Date: Thu, 28 May 2009 11:52:49 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution > packages > > Of course, there are platforms that don't use etc, like Windows. > > I'm ok with whatever approach makes sense for the given platforms > wrt configuration files; however, I will point out that for those of > us who've been using Modula-3 for a long time, that we are used to > having to mess around with the config files to get things to work > correctly. I'm all for simplifying things and would love NOT to > HAVE to mess with the config files, as long as whatever approach is > taken allows for adequate flexibility in adapting to particular > installation requirements. > > On a Windows platform, most programs are stored in %ProgramFiles%, > typically "C:\Program Files", but CM3 is more than a program, it is > a repository of packages etc. Typically, ordinary users don't get > write privileges to %ProgramFiles%. So, I've always put my > installation in "C:\cm3", but then some folks might have multiple > drives and partitions and want to put it somewhere else. Indeed, I > once used "D:\cm3". > > Another thing that the config files had to be adapted for in the > past was where to find the C compiler, libraries, and linker. > Today, we have the free Microsoft Visual Studio tools, but there are > other vendors of C compilers and linkers. Which of these will the > config files support? > > Critical Mass also adapted the config file to tell "Reactor" where > to find certain things. Of course, now we have CM3IDE as the > replacement for Reactor and I've tried to adapt the code to deal > with some of Jay's changes to the config files. > > My 2 cents: Whatever is decided, we need to document it, and make > it widely known (i.e., publicize it) so that us old timers > understand whether we should or should not keep tweaking the config > files. I know Jay has been making great strides with the config > files, but I don't believe everyone is "clued-into" what has been > done and the rationale behind it, hence the need for some publicized > documentation. Then, we need to go back and revise old > documentation, such as that with CM3IDE, to reflect the new > reality. I can make doc changes, but I need to understand new > content first. > > Regards, > Randy > From jay.krell at cornell.edu Sun May 31 16:49:21 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 31 May 2009 14:49:21 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: The bitfield problem still seems present. m3-libs/m3core/src/runtime/common/RTIO.m3: PROCEDURE Flush () = BEGIN IF (len > 0) THEN RTOS.Write (ADR (buf[0]), len); len := 0; END; END Flush. In question is just the line "len := 0", it is line 79, len is a module-global. Without any optimization, the bitfield code yields: .stabd 68,0,79 ldr r3, L53+12 @ tmp110, L51: add r3, pc, r3 @ tmp110, tmp110 ; r3 contains the address of the module globals mov r2, r3 @ tmp109, tmp110 ; now r2 does ldr r3, [r2, #52] @, ; r3 now contains the address of len str r3, [sp, #0] @, ldr r3, [sp, #0] @ tmp112, str r3, [sp, #0] @ tmp112, ldr r3, [sp, #0] @, str r3, [r2, #52] @, which I believe never actually stores to the global -- at least not any value it doesn't already have. The non-bitfield code, again, not optimized, yields: .stabd 68,0,79 ldr r3, L53+12 @ tmp113, L51: add r3, pc, r3 @ tmp113, tmp113 add r3, r3, #52 @ D.789, tmp113, ; r3 now contains the address of len mov r2, r3 @ D.790, D.789 ; now r2 does mov r3, #0 @ tmp114, ; r3=0 str r3, [r2, #0] @ tmp114,* D.790 ; len=0 Which is pretty clearly ok -- it is actually putting zero in a register and storing that in the global. Granted, this is using gcc 4.2 (the gcc-apple directory). Some/all of the volitization is skipped, but has that ever been a problem when not optimizing? (actually I think it has, I remember debugging an m3/cygwin problem early on where code got thrown out because the compiler didn't think it did anything, I don't remember the details) Anyway, the #ifndef GCC_APPLE does workaround this successfully -- cm3 does startup ok on my iphone :). It's that this bitfield stuff also caused problems on Mips so I'm leary of it, I wonder if it is just not a great idea. - Jay > > >> > >> m3_load/store using bitfields for everything caused module-global > >> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked > >> around that by declaring that the module-globals are at least of > >> size 2 * biggest_alignment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Sun May 31 20:57:44 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 31 May 2009 11:57:44 -0700 (PDT) Subject: [M3devel] [M3Devel] Bug report: compiler output option "-o" not working Message-ID: <690137.5674.qm@web56807.mail.re3.yahoo.com> Hi Guys, A simple hello world program MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("Hello Modula-3 World.\n"); END Hello. Compiles and links when the compiler is invoked as $ cm3 but fails when invoked as $ cm3 -o Hello With the following error message: peter at black:~/modula-3/m3hello $ cm3 -o Hello --- building in AMD64_LINUX --- -> linking Hello Fatal Error: incomplete program missing "Main" module +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From eiserlohpp at yahoo.com Sun May 31 21:41:12 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 31 May 2009 12:41:12 -0700 (PDT) Subject: [M3devel] [M3Devel] failure to find scripts/version, due to root not set Message-ID: <391441.99767.qm@web56805.mail.re3.yahoo.com> In recent builds, I noticed that the compiler pkg (cm3) was not getting installed into the pkg directory. The build log indicated that "/scripts/version" could not be found. This is understandable, "scripts" is not in my root directory, but rather it is rooted in the source tree. Examining further sysinfo.sh is relying upon a variable "root" to exist. The script sysinfo.sh is a script invoked not by users, but by other scripts. These top level scripts when simply invoked by a user works well, but those top level scripts can be called by other than a user, say a makefile. My "Makefile" sets ROOT (uppercase), so the toplevel scripts never go through the search process, and never set "root" lower case. My fix was easy, if simplistic. ---- BEGIN ---- if [ -n "$ROOT" -a -d "$ROOT" ] ; then sysinfo="$ROOT/scripts/sysinfo.sh" + export root=${ROOT} else root=`pwd` while [ -n "$root" -a ! -f "$root/scripts/sysinfo.sh" ] ; do ---- END ---- +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Fri May 1 00:12:58 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 30 Apr 2009 22:12:58 +0000 Subject: [M3devel] dynamic unload? Message-ID: Does any care what the following do? int main() { while(1) { { void* = dlopen("libm3core.so"); /* more stuff here */ dlclose(x); } return 0; } int main() { while(1) { void* x = dlopen("some-standalone-m3.so"); /* more stuff here */ dlclose(x); } return 0; } int main() { while(1) { void* x = dlopen("some-not-standalone-m3.so"); /* more stuff here */ dlclose(x); } return 0; } (On Windows, these are called LoadLibrary and FreeLibrary.) I haven't run them but I expect they all behave poorly, leaking, leaking thread locals, crashing in the garbage collector thread, etc. A lot of code out there in the world is ok to unload, and I guess a lot is not. I think the above code shouldn't leak or crash. I'm pretty certain they do, probably crash, or at least leak. - Jay From jay.krell at cornell.edu Mon May 4 12:09:12 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 4 May 2009 10:09:12 +0000 Subject: [M3devel] coping with low memory/resources? Message-ID: I invented a policy of one immediate retry for EAGAIN. I'm not sure that will help but it won't hurt much. I'm leary of infinite retry. This will be active maybe tonight. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: coping with low memory/resources? > Date: Wed, 29 Apr 2009 12:27:48 +0000 > > > coping with low memory/resources? > > > We have code that does like > r := pthread_do_something() > assert(r == 0); > > > where for example: > [EAGAIN] > The system lacked the necessary resources (other than memory) to initialise another mutex. > [ENOMEM] > Insufficient memory exists to initialise the mutex. > > > I'll fix it to raise an out of memory exception for ENOMEM. Ok. > But what about EAGAIN? > Retry? That is what "again" means, right? > In an infinite loop? > Or just a few times? > You know -- overall system might be low but other parts might reduce, > or the Modula-3 code itself might be hogging resources and retry might > just sit there forever. > Raise some other exception? > > For now I'll leave it asserting. > > > - Jay From wagner at elegosoft.com Mon May 4 16:46:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 04 May 2009 16:46:57 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> Message-ID: <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> Now it's May 4th, and I feel we should turn to the official release again. Have any of the open issues been closed? Offhand I remember o REFANY/TAGGED REF extensions o alternative TEXT implementation o complete switch to new Unix headers o working cvsup (OK AFAIK) o formsvbt crashes o performance issues: threads, exception frames, texts, ... There are probably more. A short status from those who know would be great. We must also decide which platforms _must_ be part of the release. I'd suggest AMD64_LINUX, LINUXLIBC6, FreeBSD(4/7?), SOLgnu, I386_DARWIN (and/or AMD64_DARWIN?), and of course Windows (native and Cygwin, however these are called these days ;-) Should we add more? I'll need support to build several of them. I suggest that we use the old make_bin_dist_min.sh scripts with the core distribution. Or is something better already completely automated (possibly by Jay)? I'll just try to coordinate things, assign error reports, make some tests myself and setup release candidate access when we start. Or should we postpone one or two weeks? Olaf Quoting Olaf Wagner : > If anybody could test Rodney's TEXT changes and provide some > information on the impacts on our applications, that would help a lot. > > I also wasn't able to read and understand all the mails about small objects. > (Guessing, I'd say I'd need another day for that :-) > Can anybody summarize? > Has a conclusion been reached and what will be done/implemented? > Is this relevant for the next release, or will it take longer? > > Olaf > > Quoting Randy Coleburn : > >> Rodney, sorry but I haven't tried your changes. If your test >> program is available, I would be glad to compile and run it on >> Windows to obtain results for that platform. Just let me know how >> to obtain/install your TEXT changes and the test program. >> >> I am ok with Olaf's suggestion of starting the release process in May. >> >> Again, I will be glad to help on Windows platforms. If necessary, >> I can also test cygwin on Windows. >> >> If we need to test/build/release on HPUX, I have an old v10 system >> I can pull out of storage (note that v10 is an older version of >> HPUX and not current). >> >> Regards, >> Randy Coleburn >> >>>>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> >> Any opinions about the TEXT branch? Anybody tried it? To summarize: >> >> - I have tested it extensively on LINUXLIBC6, with a large random >> test program and two successive rebuilds of CM3. >> >> - It makes no changes in data structure, neither to static declarations >> nor to invariants. Thus it creates no compatibility problems with >> existing >> pickles, etc. >> >> - It slows down concatenation, but more than makes it up in other >> string accessing operations, if the numbers of concatenations and >> accessing operations are equal. >> >> - It cuts down on tree depth and even more or recursion depth >> (which implies needed stack space.) >> >> - This effect is dramatic when strings are built by "linear" concatenations, >> i.e., strictly left-to-right, or vice versa. Gains are moderate when >> concatenations are random. >> >> - It allocates a lot more storage, but abandons a lot more garbage, >> retaining somewhat more space when lots of old strings are retained >> along with newly-built ones. It probably retains less when operand >> strings of concatenations are not kept, but I haven't measured that. >> >> - Strategies are partial rebalancing of concatenation trees, flattening >> of short concatenations, elimination of a lot of tail-recursion, and >> recursing on the shorter side. >> >> >> >> Olaf Wagner wrote: >>> Well, that's a quite long list; but many things are bug fixes anyway, >>> and wouldn't be affected by a code freeze, while others are already >>> finished (as integrating CVSup, as I understand). >>> >>> The only thing we should not do is introduce new platforms while >>> trying to get the system stable. We should concentrate on installation >>> support and bug fixing. >>> >>> I'd suggest to start the release process in about two weeks at the >>> start of May. That should give everybody enough time to either finish >>> their ongoing work that shall make it into the release or decide to >>> postpone it ;-) >>> >>> Any objections? >>> >>> Olaf >>> >>> Quoting Jay : >>> >>>> >>>> > > o When should we start? I.e. wha changes would you like to complete >>>> > > before we start the release process? >>>> >>>> >>>> >>>> >>>> I'd like to see the formsvbt crash debugged and fixed, unless I'm >>>> the only one seeing it. >>>> >>>> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >>>> >>>> I'll try to get this. >>>> >>>> >>>> >>>> >>>> >>>> I'd also like to see: >>>> >>>> >>>> >>>> >>>> >>>> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >>>> >>>> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >>>> >>>> >>>> >>>> >>>> >>>> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >>>> little work (I'll do this). >>>> >>>> Basically just 1) put buildlocal back how it was 2) push it across >>>> more platforms e.g. I think FreeBSD/x86 is the main one missing, >>>> but I'll get to it. >>>> >>>> >>>> >>>> >>>> >>>> cvsup building and in "std" (I'll do this, probably very little >>>> left here really. >>>> >>>> >>>> >>>> >>>> >>>> -- beyond this, not required for release -- >>>> >>>> >>>> >>>> >>>> >>>> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >>>> >>>> (could be "mingw64" is good enough to try AMD64_NT now). >>>> >>>> >>>> >>>> >>>> >>>> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >>>> by me) >>>> >>>> >>>> >>>> >>>> >>>> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >>>> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >>>> seat to important fixes in existing platforms. >>>> >>>> >>>> >>>> >>>> >>>> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >>>> skip C __finally blocks. I've just been very lazy here, should >>>> demonstrate the behavior with a test case, then fix it.. >>>> >>>> >>>> >>>> >>>> >>>> Maybe fix cm3cg so other -g options besides -gstabs works, like >>>> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >>>> leaving nothing, because others cause internal compiler errors, like >>>> on HPPA64_HPUX. >>>> >>>> >>>> >>>> >>>> >>>> Oh, and NT386GNU probably switched back to Win32 threads. >>>> Otherwise one of the test cases hangs and it doesn't look easy to >>>> figure out. I'll do this shortly if I remember. >>>> >>>> But I also wouldn't mind if this platform isn't officially released >>>> either (unless someone else wants to support it). >>>> >>>> >>>> >>>> >>>> >>>> Debug why many NT386MINGNU gui apps crash..but also probably just >>>> don't release this platform and ok asis. >>>> >>>> >>>> >>>> >>>> >>>> - Jay >>>> >>> >>> >>> >> >> >> >> CONFIDENTIALITY NOTICE: This email and any attachments are >> intended solely for the use of the named recipient(s). This e-mail >> may contain confidential and/or proprietary information of >> Scientific Research Corporation. If you are not a named >> recipient, you are prohibited from making any use of the >> information in the email and attachments. If you believe you have >> received this email in error, please notify the sender >> immediately and permanently delete the email, any attachments, >> and all copies thereof from any drives or storage media and >> destroy any printouts of the email or attachments. >> >> EXPORT COMPLIANCE NOTICE: This email and any attachments may >> contain technical data subject to U.S export restrictions under the >> International Traffic in Arms Regulations (ITAR) or the Export >> Administration Regulations (EAR). Export or transfer of this >> technical data and/or related information to any foreign person(s) >> or entity(ies), either within the U.S. or outside of the U.S., may >> require export authorization by the appropriate U.S. Government >> agency prior to export or transfer. In addition, technical data >> may not be exported or transferred to certain countries or >> specified designated nationals identified by U.S. embargo controls >> without prior export authorization. By accepting this email and >> any attachments, all recipients confirm that they understand and >> will comply with all applicable ITAR, EAR and embargo compliance >> requirements. >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon May 4 18:39:09 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 4 May 2009 16:39:09 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> Message-ID: > o complete switch to new Unix headers I386_DARWIN and AMD64_DARWIN not switched. ok though either way. > o working cvsup (OK AFAIK) ok, though I didn't add it to build automation. > o formsvbt crashes Not solved. I couldn't get an older release to work to verify against. > o performance issues: threads, exception frames, texts, ... A little better. I don't think regressed wrt cm3 though. Can release asis I think. > We must also decide which platforms _must_ be part of the release. > I'd suggest AMD64_LINUX, LINUXLIBC6, FreeBSD(4/7?), SOLgnu, > I386_DARWIN (and/or AMD64_DARWIN?), and of course Windows (native and > Cygwin, however these are called these days ;-) I'd just as soon skip Cygwin. Maybe we can have some sort of "tiers"? All of PPC_DARWIN, I386_DARWIN, AMD64_DARWIN can be included. Many others /can/ be included, but I don't know what must/should be included. > Should we add more? I'll need support to build several of them. > > I suggest that we use the old make_bin_dist_min.sh scripts with > the core distribution. Or is something better already completely > automated (possibly by Jay)? I have good automation, with some caveats: No cminstall. A few packages should be added: m3gdb, cm3ide, cvsup There might be a few copyrights missing, and they might be so numerous that a directory should be created, if that is "prominent" enough. There is always more work to do.. - Jay From hosking at cs.purdue.edu Tue May 5 01:13:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 5 May 2009 09:13:57 +1000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> Message-ID: On 5 May 2009, at 00:46, Olaf Wagner wrote: > Now it's May 4th, and I feel we should turn to the official release > again. > > Have any of the open issues been closed? Offhand I remember > > o REFANY/TAGGED REF extensions I have the minimalist version almost ready for checkin. > o alternative TEXT implementation > > o complete switch to new Unix headers > > o working cvsup (OK AFAIK) > > o formsvbt crashes > > o performance issues: threads, exception frames, texts, ... I'd prefer to see stability here for now, rather than on over-the-top performance drive -- there are better solutions out there that we can engineer in, but getting them in may require a stabilization period. > There are probably more. A short status from those who know would > be great. > > We must also decide which platforms _must_ be part of the release. > I'd suggest AMD64_LINUX, LINUXLIBC6, FreeBSD(4/7?), SOLgnu, > I386_DARWIN (and/or AMD64_DARWIN?), and of course Windows (native and > Cygwin, however these are called these days ;-) > > Should we add more? I'll need support to build several of them. > > I suggest that we use the old make_bin_dist_min.sh scripts with > the core distribution. Or is something better already completely > automated (possibly by Jay)? > > I'll just try to coordinate things, assign error reports, make > some tests myself and setup release candidate access when we start. > Or should we postpone one or two weeks? > > Olaf > > > Quoting Olaf Wagner : > >> If anybody could test Rodney's TEXT changes and provide some >> information on the impacts on our applications, that would help a >> lot. >> >> I also wasn't able to read and understand all the mails about small >> objects. >> (Guessing, I'd say I'd need another day for that :-) >> Can anybody summarize? >> Has a conclusion been reached and what will be done/implemented? >> Is this relevant for the next release, or will it take longer? >> >> Olaf >> >> Quoting Randy Coleburn : >> >>> Rodney, sorry but I haven't tried your changes. If your test >>> program is available, I would be glad to compile and run it on >>> Windows to obtain results for that platform. Just let me know >>> how to obtain/install your TEXT changes and the test program. >>> >>> I am ok with Olaf's suggestion of starting the release process in >>> May. >>> >>> Again, I will be glad to help on Windows platforms. If >>> necessary, I can also test cygwin on Windows. >>> >>> If we need to test/build/release on HPUX, I have an old v10 >>> system I can pull out of storage (note that v10 is an older >>> version of HPUX and not current). >>> >>> Regards, >>> Randy Coleburn >>> >>>>>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> >>> Any opinions about the TEXT branch? Anybody tried it? To summarize: >>> >>> - I have tested it extensively on LINUXLIBC6, with a large random >>> test program and two successive rebuilds of CM3. >>> >>> - It makes no changes in data structure, neither to static >>> declarations >>> nor to invariants. Thus it creates no compatibility problems with >>> existing >>> pickles, etc. >>> >>> - It slows down concatenation, but more than makes it up in other >>> string accessing operations, if the numbers of concatenations and >>> accessing operations are equal. >>> >>> - It cuts down on tree depth and even more or recursion depth >>> (which implies needed stack space.) >>> >>> - This effect is dramatic when strings are built by "linear" >>> concatenations, >>> i.e., strictly left-to-right, or vice versa. Gains are moderate >>> when >>> concatenations are random. >>> >>> - It allocates a lot more storage, but abandons a lot more garbage, >>> retaining somewhat more space when lots of old strings are retained >>> along with newly-built ones. It probably retains less when operand >>> strings of concatenations are not kept, but I haven't measured that. >>> >>> - Strategies are partial rebalancing of concatenation trees, >>> flattening >>> of short concatenations, elimination of a lot of tail-recursion, and >>> recursing on the shorter side. >>> >>> >>> >>> Olaf Wagner wrote: >>>> Well, that's a quite long list; but many things are bug fixes >>>> anyway, >>>> and wouldn't be affected by a code freeze, while others are already >>>> finished (as integrating CVSup, as I understand). >>>> >>>> The only thing we should not do is introduce new platforms while >>>> trying to get the system stable. We should concentrate on >>>> installation >>>> support and bug fixing. >>>> >>>> I'd suggest to start the release process in about two weeks at the >>>> start of May. That should give everybody enough time to either >>>> finish >>>> their ongoing work that shall make it into the release or decide to >>>> postpone it ;-) >>>> >>>> Any objections? >>>> >>>> Olaf >>>> >>>> Quoting Jay : >>>> >>>>> >>>>> > > o When should we start? I.e. wha changes would you like to >>>>> complete >>>>> > > before we start the release process? >>>>> >>>>> >>>>> >>>>> >>>>> I'd like to see the formsvbt crash debugged and fixed, unless I'm >>>>> the only one seeing it. >>>>> >>>>> I only see it on Solaris and PPC_DARWIN but haven't tried >>>>> "everything". >>>>> >>>>> I'll try to get this. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I'd also like to see: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >>>>> >>>>> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the >>>>> hardware. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >>>>> little work (I'll do this). >>>>> >>>>> Basically just 1) put buildlocal back how it was 2) push it across >>>>> more platforms e.g. I think FreeBSD/x86 is the main one missing, >>>>> but I'll get to it. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> cvsup building and in "std" (I'll do this, probably very little >>>>> left here really. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- beyond this, not required for release -- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to >>>>> it). >>>>> >>>>> (could be "mingw64" is good enough to try AMD64_NT now). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >>>>> by me) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >>>>> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >>>>> seat to important fixes in existing platforms. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >>>>> skip C __finally blocks. I've just been very lazy here, should >>>>> demonstrate the behavior with a test case, then fix it.. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Maybe fix cm3cg so other -g options besides -gstabs works, like >>>>> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >>>>> leaving nothing, because others cause internal compiler errors, >>>>> like >>>>> on HPPA64_HPUX. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Oh, and NT386GNU probably switched back to Win32 threads. >>>>> Otherwise one of the test cases hangs and it doesn't look easy to >>>>> figure out. I'll do this shortly if I remember. >>>>> >>>>> But I also wouldn't mind if this platform isn't officially >>>>> released >>>>> either (unless someone else wants to support it). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Debug why many NT386MINGNU gui apps crash..but also probably just >>>>> don't release this platform and ok asis. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> - Jay >>>>> >>>> >>>> >>>> >>> >>> >>> >>> CONFIDENTIALITY NOTICE: This email and any attachments are >>> intended solely for the use of the named recipient(s). This e- >>> mail may contain confidential and/or proprietary information of >>> Scientific Research Corporation. If you are not a named >>> recipient, you are prohibited from making any use of the >>> information in the email and attachments. If you believe you >>> have received this email in error, please notify the sender >>> immediately and permanently delete the email, any attachments, >>> and all copies thereof from any drives or storage media and >>> destroy any printouts of the email or attachments. >>> >>> EXPORT COMPLIANCE NOTICE: This email and any attachments may >>> contain technical data subject to U.S export restrictions under >>> the International Traffic in Arms Regulations (ITAR) or the >>> Export Administration Regulations (EAR). Export or transfer of >>> this technical data and/or related information to any foreign >>> person(s) or entity(ies), either within the U.S. or outside of >>> the U.S., may require export authorization by the appropriate >>> U.S. Government agency prior to export or transfer. In >>> addition, technical data may not be exported or transferred to >>> certain countries or specified designated nationals identified >>> by U.S. embargo controls without prior export authorization. By >>> accepting this email and any attachments, all recipients confirm >>> that they understand and will comply with all applicable ITAR, >>> EAR and embargo compliance requirements. >>> >>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Tue May 5 01:14:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 5 May 2009 09:14:37 +1000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> Message-ID: <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> On 5 May 2009, at 02:39, Jay wrote: > >> o complete switch to new Unix headers > > > I386_DARWIN and AMD64_DARWIN not switched. > ok though either way. > > >> o working cvsup (OK AFAIK) > > > ok, though I didn't add it to build automation. > > >> o formsvbt crashes > > Not solved. > I couldn't get an older release to work to verify against. Can you provide a way to repeat your crash? I will try to diagnose and fix. > > > >> o performance issues: threads, exception frames, texts, ... > > > A little better. > I don't think regressed wrt cm3 though. > Can release asis I think. > > >> We must also decide which platforms _must_ be part of the release. >> I'd suggest AMD64_LINUX, LINUXLIBC6, FreeBSD(4/7?), SOLgnu, >> I386_DARWIN (and/or AMD64_DARWIN?), and of course Windows (native and >> Cygwin, however these are called these days ;-) > > > I'd just as soon skip Cygwin. > Maybe we can have some sort of "tiers"? > All of PPC_DARWIN, I386_DARWIN, AMD64_DARWIN can be included. > Many others /can/ be included, but I don't know what must/should be > included. > > >> Should we add more? I'll need support to build several of them. >> >> I suggest that we use the old make_bin_dist_min.sh scripts with >> the core distribution. Or is something better already completely >> automated (possibly by Jay)? > > > I have good automation, with some caveats: > > No cminstall. > A few packages should be added: > m3gdb, cm3ide, cvsup > > > There might be a few copyrights missing, and they might be so > numerous that a directory should be created, if that is "prominent" > enough. > > There is always more work to do.. > > - Jay From jay.krell at cornell.edu Tue May 5 02:07:07 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 5 May 2009 00:07:07 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> Message-ID: >>> o formsvbt crashes >> >> Not solved. >> I couldn't get an older release to work to verify against. > > Can you provide a way to repeat your crash? I will try to diagnose > and fix. while (true) Start up formsvbt. Wait a few seconds. If it doesn't crash, exit it. It happens at least half the time. On PPC_DARWIN and SOL..not sure it was SOLgnu or SOLsun. Did not repro on..I think..LINUXLIBC6, FreeBSD/x86..not sure what all I tried. It seems to somehow be specific to only some platforms. 5.4.0 release had bigger problems here that I forget (on SOLgnu or SOLsun). I only test out X stuff remotely (and don't use X otherwise, what a mess..), though I doubt that matters. I added an assert(foo # NIL) right where the crash is, so now the crash is that assertion failing. - Jay From jay.krell at cornell.edu Tue May 5 09:49:45 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 5 May 2009 07:49:45 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> Message-ID: I meant formedit, not formsvbt. I've seen it now on LINUXLIBC6 but only once in more than 10 runs. jay at localhost ~/dev2/cm3/m3-obliq/obliqlibanim $ /cm3/bin/formsedit *** *** runtime error: *** failed. *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 *** Aborted I added the assertion. It would be followed by a null dereference. C:\dev2\cm3.2\m3-ui\vbtkit\src\lego\POSIX PROCEDURE PaintViewWithShadows (v: T) = ... (* Paint the stripe. *) r := Rect.Inset(stripe, v.shadowPixels); ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, r, stripe); here VBT.PaintTint(v, r, v.shadow.bg); END PaintViewWithShadows; - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release > Date: Tue, 5 May 2009 00:07:07 +0000 > > >>>> o formsvbt crashes >>> >>> Not solved. >>> I couldn't get an older release to work to verify against. >> >> Can you provide a way to repeat your crash? I will try to diagnose >> and fix. > > while (true) > Start up formsvbt. > Wait a few seconds. > If it doesn't crash, exit it. > > > It happens at least half the time. > On PPC_DARWIN and SOL..not sure it was SOLgnu or SOLsun. > Did not repro on..I think..LINUXLIBC6, FreeBSD/x86..not sure what all I tried. > It seems to somehow be specific to only some platforms. > > > 5.4.0 release had bigger problems here that I forget (on SOLgnu or SOLsun). > > > I only test out X stuff remotely (and don't use X otherwise, what a mess..), though I doubt that matters. > I added an assert(foo # NIL) right where the crash is, so now the crash is that assertion failing. > > > > - Jay From jay.krell at cornell.edu Tue May 5 09:54:36 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 5 May 2009 07:54:36 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> Message-ID: seen it on FreeBSD/x86 7.0 now too but also rare. Seemed much more common on Solaris and PPC_DARWIN, which I will try again shortly. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release > Date: Tue, 5 May 2009 07:49:45 +0000 > > > I meant formedit, not formsvbt. > I've seen it now on LINUXLIBC6 but only once in more than 10 runs. > > > jay at localhost ~/dev2/cm3/m3-obliq/obliqlibanim $ /cm3/bin/formsedit > > > *** > *** runtime error: > *** failed. > *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 > *** > Aborted > > > I added the assertion. > It would be followed by a null dereference. > > > C:\dev2\cm3.2\m3-ui\vbtkit\src\lego\POSIX > > > > PROCEDURE PaintViewWithShadows (v: T) = > ... > (* Paint the stripe. *) > r := Rect.Inset(stripe, v.shadowPixels); > ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, > r, stripe); > > here > > > VBT.PaintTint(v, r, v.shadow.bg); > END PaintViewWithShadows; > > > > - Jay > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release >> Date: Tue, 5 May 2009 00:07:07 +0000 >> >> >>>>> o formsvbt crashes >>>> >>>> Not solved. >>>> I couldn't get an older release to work to verify against. >>> >>> Can you provide a way to repeat your crash? I will try to diagnose >>> and fix. >> >> while (true) >> Start up formsvbt. >> Wait a few seconds. >> If it doesn't crash, exit it. >> >> >> It happens at least half the time. >> On PPC_DARWIN and SOL..not sure it was SOLgnu or SOLsun. >> Did not repro on..I think..LINUXLIBC6, FreeBSD/x86..not sure what all I tried. >> It seems to somehow be specific to only some platforms. >> >> >> 5.4.0 release had bigger problems here that I forget (on SOLgnu or SOLsun). >> >> >> I only test out X stuff remotely (and don't use X otherwise, what a mess..), though I doubt that matters. >> I added an assert(foo # NIL) right where the crash is, so now the crash is that assertion failing. >> >> >> >> - Jay From martinbishop at bellsouth.net Wed May 6 02:57:43 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Tue, 05 May 2009 19:57:43 -0500 Subject: [M3devel] Possible Bug? Message-ID: <4A00E087.2000100@bellsouth.net> I have this code, for finding the roots of a quadratic equation: MODULE Quad EXPORTS Main; IMPORT IO, Fmt, RealSqrt; TYPE Roots = ARRAY [1..2] OF REAL; VAR r: Roots; PROCEDURE Solve(a, b, c: REAL): Roots = VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); x: REAL; BEGIN IF b < 0.0 THEN x := (-b + sd) / 2.0 * a; RETURN Roots{x, c / (a * x)}; ELSE x := (-b - sd) / 2.0 * a; RETURN Roots{c / (a * x), x}; END; END Solve; BEGIN r := Solve(1.0, -10.0E5, 1.0); IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); END Quad. When I try to build it, I get: *** *** runtime error: *** <*ASSERT*> failed: FloatMode.SetRounding not implemented *** file "../src/float/IEEE-default/FloatMode.m3", line 14 *** Aborted I'm using: martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version Critical Mass Modula-3 version d5.7.1 last updated: 2009-01-21 compiled: 2009-04-01 13:11:43 configuration: /usr/local/bin/cm3.cfg which was installed from Jay's "std" binary package. From jay.krell at cornell.edu Wed May 6 03:31:29 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 6 May 2009 01:31:29 +0000 Subject: [M3devel] Possible Bug? In-Reply-To: <4A00E087.2000100@bellsouth.net> References: <4A00E087.2000100@bellsouth.net> Message-ID: This has never worked on most platforms. We even deliberately stopped it working where it did -- e.g. SPARC. We could fix it maybe. Please try RealFloat.sqrt instead. It is almost the same thing, but for lack of ability to use single precision, and is likely to be much much faster (how common is hardware sqrt? Anyway, vendor software sqrt is presumably excellent). In future please give callstacks. Run it under gdb or dbx, etc. - Jay ---------------------------------------- > Date: Tue, 5 May 2009 19:57:43 -0500 > From: martinbishop at bellsouth.net > To: m3devel at elegosoft.com > Subject: [M3devel] Possible Bug? > > I have this code, for finding the roots of a quadratic equation: > > MODULE Quad EXPORTS Main; > > IMPORT IO, Fmt, RealSqrt; > > TYPE Roots = ARRAY [1..2] OF REAL; > > VAR r: Roots; > > PROCEDURE Solve(a, b, c: REAL): Roots = > VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); > x: REAL; > BEGIN > IF b < 0.0 THEN > x := (-b + sd) / 2.0 * a; > RETURN Roots{x, c / (a * x)}; > ELSE > x := (-b - sd) / 2.0 * a; > RETURN Roots{c / (a * x), x}; > END; > END Solve; > > BEGIN > r := Solve(1.0, -10.0E5, 1.0); > IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); > END Quad. > > When I try to build it, I get: > > *** > *** runtime error: > *** failed: FloatMode.SetRounding not implemented > *** file "../src/float/IEEE-default/FloatMode.m3", line 14 > *** > > Aborted > > > I'm using: > > martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version > Critical Mass Modula-3 version d5.7.1 > last updated: 2009-01-21 > compiled: 2009-04-01 13:11:43 > configuration: /usr/local/bin/cm3.cfg > > which was installed from Jay's "std" binary package. From jay.krell at cornell.edu Wed May 6 03:38:47 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 6 May 2009 01:38:47 +0000 Subject: [M3devel] Possible Bug? In-Reply-To: <4A00E087.2000100@bellsouth.net> References: <4A00E087.2000100@bellsouth.net> Message-ID: I suggest we provide Cmath.i3 and/or Cfloat.i3 to provide trivial portable wrappers to some of this stuff in an easier to find location instead of buried. Granted, the buriers were trying to make things better in their way. And by portable, I'd limit myself probably to double foo(double); and not likely delve into single precision functions, unless maybe float foof(float) is fairly portable. Eh, since they'd all be external, you can delcare them all and not necessarily implement all of them. In any case the perf might stink compared to C. Visual C++ for example can generate FPU instructions inline such as for sqrt. gcc probably does a good job here too. We'll likely incur function calls for portability. Imho we need to do better with keeping up with "builtin functions" that C compilers gradually accrue and implement very well. It is difficult though, for reasons of portability. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: martinbishop at bellsouth.net; m3devel at elegosoft.com > Subject: RE: [M3devel] Possible Bug? > Date: Wed, 6 May 2009 01:31:29 +0000 > > > This has never worked on most platforms. > We even deliberately stopped it working where it did -- e.g. SPARC. > We could fix it maybe. > > > Please try RealFloat.sqrt instead. > > > It is almost the same thing, but for lack of ability to use single precision, and is likely to be much much faster (how common is hardware sqrt? Anyway, vendor software sqrt is presumably excellent). > > > In future please give callstacks. > Run it under gdb or dbx, etc. > > > - Jay > > > > ---------------------------------------- >> Date: Tue, 5 May 2009 19:57:43 -0500 >> From: martinbishop at bellsouth.net >> To: m3devel at elegosoft.com >> Subject: [M3devel] Possible Bug? >> >> I have this code, for finding the roots of a quadratic equation: >> >> MODULE Quad EXPORTS Main; >> >> IMPORT IO, Fmt, RealSqrt; >> >> TYPE Roots = ARRAY [1..2] OF REAL; >> >> VAR r: Roots; >> >> PROCEDURE Solve(a, b, c: REAL): Roots = >> VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); >> x: REAL; >> BEGIN >> IF b < 0.0 THEN >> x := (-b + sd) / 2.0 * a; >> RETURN Roots{x, c / (a * x)}; >> ELSE >> x := (-b - sd) / 2.0 * a; >> RETURN Roots{c / (a * x), x}; >> END; >> END Solve; >> >> BEGIN >> r := Solve(1.0, -10.0E5, 1.0); >> IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); >> END Quad. >> >> When I try to build it, I get: >> >> *** >> *** runtime error: >> *** failed: FloatMode.SetRounding not implemented >> *** file "../src/float/IEEE-default/FloatMode.m3", line 14 >> *** >> >> Aborted >> >> >> I'm using: >> >> martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version >> Critical Mass Modula-3 version d5.7.1 >> last updated: 2009-01-21 >> compiled: 2009-04-01 13:11:43 >> configuration: /usr/local/bin/cm3.cfg >> >> which was installed from Jay's "std" binary package. From mika at async.caltech.edu Wed May 6 04:24:31 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 05 May 2009 19:24:31 -0700 Subject: [M3devel] Possible Bug? In-Reply-To: Your message of "Wed, 06 May 2009 01:38:47 -0000." Message-ID: <200905060224.n462OVIR060238@camembert.async.caltech.edu> I don't think it's particularly hard to find...? The interface I almost always use is "Math.i3" and it has things like this in it: <*EXTERNAL*> PROCEDURE sqrt (x: LONGREAL): LONGREAL; (* returns the square root of x. *) I think you get pretty good performance with that. If you want speed on x86, you code in f77 and use Intel's ifort (-sse2, or whatever hardware you have in your machine). You can get it free for Linux. I compile -S on Linux and then use GNU as on FreeBSD to get my objects. It's really easy to link that code with M3 if you want to do that. All you have to remember is that all the arrays are transposed and in Fortran they start from 1, of course. Then you just pass ADR(a[0,..,0]) to the f77 code. But my experience has been that Modula-3 code really doesn't perform that poorly on numerical work. If you turn on optimization, that is. Mika Jay writes: > >I suggest we provide Cmath.i3 and/or Cfloat.i3 to provide trivial portable wrappers to some of this stuff in an easier to find location instead of buried. Granted, the buriers were trying to make things bette >r in their way. > > >And by portable, I'd limit myself probably to >double foo(double); > > >and not likely delve into single precision functions, unless maybe >float foof(float) is fairly portable. > >Eh, since they'd all be external, you can delcare them all and not necessarily implement all of them. > > >In any case the perf might stink compared to C. >Visual C++ for example can generate FPU instructions inline such as for sqrt. >gcc probably does a good job here too. >We'll likely incur function calls for portability. > > >Imho we need to do better with keeping up with "builtin functions" that C compilers gradually accrue and implement very well. >It is difficult though, for reasons of portability. > > > - Jay > >---------------------------------------- >> From: jay.krell at cornell.edu >> To: martinbishop at bellsouth.net; m3devel at elegosoft.com >> Subject: RE: [M3devel] Possible Bug? >> Date: Wed, 6 May 2009 01:31:29 +0000 >> >> >> This has never worked on most platforms. >> We even deliberately stopped it working where it did -- e.g. SPARC. >> We could fix it maybe. >> >> >> Please try RealFloat.sqrt instead. >> >> >> It is almost the same thing, but for lack of ability to use single precision, and is likely to be much much faster (how common is hardware sqrt? Anyway, vendor software sqrt is presumably excellent). >> >> >> In future please give callstacks. >> Run it under gdb or dbx, etc. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Tue, 5 May 2009 19:57:43 -0500 >>> From: martinbishop at bellsouth.net >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] Possible Bug? >>> >>> I have this code, for finding the roots of a quadratic equation: >>> >>> MODULE Quad EXPORTS Main; >>> >>> IMPORT IO, Fmt, RealSqrt; >>> >>> TYPE Roots = ARRAY [1..2] OF REAL; >>> >>> VAR r: Roots; >>> >>> PROCEDURE Solve(a, b, c: REAL): Roots = >>> VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); >>> x: REAL; >>> BEGIN >>> IF b < 0.0 THEN >>> x := (-b + sd) / 2.0 * a; >>> RETURN Roots{x, c / (a * x)}; >>> ELSE >>> x := (-b - sd) / 2.0 * a; >>> RETURN Roots{c / (a * x), x}; >>> END; >>> END Solve; >>> >>> BEGIN >>> r := Solve(1.0, -10.0E5, 1.0); >>> IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); >>> END Quad. >>> >>> When I try to build it, I get: >>> >>> *** >>> *** runtime error: >>> *** failed: FloatMode.SetRounding not implemented >>> *** file "../src/float/IEEE-default/FloatMode.m3", line 14 >>> *** >>> >>> Aborted >>> >>> >>> I'm using: >>> >>> martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version >>> Critical Mass Modula-3 version d5.7.1 >>> last updated: 2009-01-21 >>> compiled: 2009-04-01 13:11:43 >>> configuration: /usr/local/bin/cm3.cfg >>> >>> which was installed from Jay's "std" binary package. From jay.krell at cornell.edu Wed May 6 15:53:25 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 6 May 2009 13:53:25 +0000 Subject: [M3devel] heapalloc/try during initialization In-Reply-To: References: <20090506002150.A15FECC3B4@birch.elegosoft.com> <46F424EA-6C63-42C4-A120-C1B0FD394AA6@cs.purdue.edu> <54967B00-3878-4147-AA90-FBD09F98161B@cs.purdue.edu> Message-ID: Something like the attached? (I don't trust email to be formated as expected, so the attachment is canonical and the rest might not be readable.) The idea is to provide a split CollectEnough for AllocTraced to call. It's a little lose on the locking but it should be ok and slows down the slow path with extra unlock/relock. It's good to get the try out of the fast path in either case. PROCEDURE LockedCollectEnough (allocator := FALSE) = BEGIN TRY CollectEnough(allocator); FINALLY RTOS.UnlockHeap(); END; END LockedCollectEnough; AllocTraced calls this: PROCEDURE UnlockedCollectEnough (allocator := FALSE) = BEGIN RTOS.LockHeap(); IF collectorOn THEN RTOS.UnlockHeap(); RETURN END; (* duplicated from CollectEnough *) IF NOT Behind() THEN RTOS.UnlockHeap(); RETURN END; (* duplicated from CollectEnough *) ThreadF.Init shouldn't get here: LockedCollectEnough(allocator); END UnlockedCollectEnough; AllocTraced slow path excerpt: IF nextPtr> thread.newPool.limit THEN (* not enough space left in the pool, take the long route *) res := NIL; nextPtr := NIL; (* in case of GC... *) DEC(thread.inCritical); (* make sure the collector gets a chance to keep up with NEW... *) UnlockedCollectEnough(allocator := TRUE); (***) RTOS.LockHeap(); (***) res := LongAlloc (dataSize, dataAlignment, thread.newPool, Note.Allocated, pure := FALSE); IF res = NIL THEN RTOS.UnlockHeap(); (***) RuntimeError.Raise(RuntimeError.T.OutOfMemory); END; INC(thread.inCritical); LOOPHOLE(res - ADRSIZE(Header), RefHeader)^ := Header{typecode := def.typecode, dirty := TRUE}; IF initProc # NIL THEN initProc (res) END; RTOS.UnlockHeap(); (***) DEC(thread.inCritical); RETURN LOOPHOLE(res, REFANY); This is all for user threads. There /may/ have been issues with pthreads/ntthreads, but I don't there are now. Your changed didn't break cygwin pthreads but it did break FreeBSD user threads. I only checked each case once so might have made mistakes and gotten it backwards or whatever. Ignorant question/suggestion similar to previous: Thread.T vs. Activation? Userthreads does traced allocations where pthreads/win32threads don't. Maybe change userthreads? Maybe give up on userthreads? This isn't a great reason, granted. I actually would hope the traced thread.t vs. activation could go away, it is ugly. Kudos for user threads for not having it?? (I wonder if there is something around the fact that thread locals aren't visible to the garbage collector..?) - Jay -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RTCollector.m3 URL: From rodney.m.bates at cox.net Wed May 6 16:01:11 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 06 May 2009 09:01:11 -0500 Subject: [M3devel] Possible Bug? In-Reply-To: <4A00E087.2000100@bellsouth.net> References: <4A00E087.2000100@bellsouth.net> Message-ID: <4A019827.4000702@cox.net> Still, if we have library functions that crash, we should document that somewhere reasonably conspicuous. It is really false advertising and a trap for a programmer to put something in an interface and then disable it. It is not enough to just have alternative square root functions that work. A newcomer to the language should not have to ferret this kind of thing out by systematic linear search of all the libraries. The same place that documents the broken functions should give pointers to the alternatives. Martin Bishop wrote: > I have this code, for finding the roots of a quadratic equation: > > MODULE Quad EXPORTS Main; > > IMPORT IO, Fmt, RealSqrt; > > TYPE Roots = ARRAY [1..2] OF REAL; > > VAR r: Roots; > > PROCEDURE Solve(a, b, c: REAL): Roots = > VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); > x: REAL; > BEGIN > IF b < 0.0 THEN > x := (-b + sd) / 2.0 * a; > RETURN Roots{x, c / (a * x)}; > ELSE > x := (-b - sd) / 2.0 * a; > RETURN Roots{c / (a * x), x}; > END; > END Solve; > > BEGIN > r := Solve(1.0, -10.0E5, 1.0); > IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); > END Quad. > > When I try to build it, I get: > > *** > *** runtime error: > *** <*ASSERT*> failed: FloatMode.SetRounding not implemented > *** file "../src/float/IEEE-default/FloatMode.m3", line 14 > *** > > Aborted > > > I'm using: > > martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version > Critical Mass Modula-3 version d5.7.1 > last updated: 2009-01-21 > compiled: 2009-04-01 13:11:43 > configuration: /usr/local/bin/cm3.cfg > > which was installed from Jay's "std" binary package. > From eiserlohpp at yahoo.com Wed May 6 19:04:12 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 6 May 2009 10:04:12 -0700 (PDT) Subject: [M3devel] [Modula-3] Release engineering Message-ID: <164357.23058.qm@web56803.mail.re3.yahoo.com> Hi Olaf, Please help support distribution packaging (various Linux, or BSD ports) by adding to your list: o Design the cm3 installation to be long term. o Allow cm3 to be installed into /usr, instead of /usr/local. o Allow installation to temporary root during package building. o Specify guidelines for which m3.pkgs go into which distribution packages (rpm, deb). List the suggested package names. o Documentation: Write manual page for cm3. o Conform where possible to the FHS. o Allow easy cross compiling. o (lower priority) Use long form options. Explaination: (0) Only the administrator should install packages into the system. If a user wants to play with a recent version of CM3, they should be able to install into their home directory. This will allow the other users of the machine to continue using the known good compiler even though one user is experimenting with buggy new features of the compiler. This will also allow easier cross compiling. (1) /usr/local is only for files/packages manually installed by the superuser. Distributions are expected (in debian, required) to install into "/usr" (or if required to boot, into "/", eg., /sbin/mount). (2) The build process of a package usually installs all files into a subdirectory where the internal paths mimic the final installation paths (/home/peter/src/modula3/cm3/src-all-20090506/debian/cm3-compiler). Libraries and executable's link paths should be adjusted to their final installation paths, not the temporary. (3) May I suggest this start: cm3-compiler, cm3-corelibs (minimal install: m3core, libm3 binaries), cm3-devel (source code to m3core, and libm3), ..., etc. What I don't want to see is the mass installation of a complete development system simply because the user wanted to use a program written in Modula-3. (4) Debian at least requires a manual page for executables. A bug will be written against any package that installs user (or superuser) binaries without a manual page. (5) The Filesystem Hierarchy Standard (FHS) http://www.pathname.com/fhs/ says things such as libraries are not execuables invocable by the user so don't put them in $(prefix)/bin. Okay, MS-Windows violates this all the time, but they are "special". Can we move cm3.cfg out of the binary directory (where there should only be executables), and into ${CM3_PATH}/etc. Something like: mypath := FindAbsolutePath(argv[0]); cm3_bin_path := DirName(mypath); cm3_path := DirName(cm3_bin_path); cm3_etc_path := cm3_path & "/etc"; cm3_config_filename = cm3_etc_path & "/cm3.cfg"; (6) Cross compiling: the cm3.cfg should be a one liner, which includes the configuration of the installed target machine . cm3.cfg: Include("AMD64_LINUX"); When cross compiling the user should be able to specify the actual config file for the desired TARGET machine. (7) Although each program is free to define is command line arguments and options, a set of conventions has been in place for at least 15 years or more. GCC of course (being an older program) violates these "recent" conventions. Options start with a dash. Single letter options start with a single dash, and multiple options may be collected into one sequence (ie, "-shared", means -s, -h, -a, -r, -e, -d). Long options use two dashes and signify that the sequence of characters are to be used as a complete string (ie, "--shared" means generate a "shared" library). Long options that take an argument are formed with an equal sign (eg. "--config=/home/peter/cm3/etc/cm3.cfg"). Instead of "-version" with a single dash, long form options use two dashes "--version", a single dash "-v" could also be mapped to be an alias of that option. Sorry for being long winded, but my system administrator is a real hard ass, every time I see myself in the mirror, he reminds me of that. Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From michael.anderson at elego.de Wed May 6 22:23:06 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 06 May 2009 22:23:06 +0200 Subject: [M3devel] Modula3 Trac Message-ID: <20090506222306.3s9jhiyqmsoo0gg8@mail.elego.de> Greetings Modula3 Devs and Users, For those who don't know about it already, the cm3 bug/issue tracking system is at: https://projects.elegosoft.com/cm3 If you haven't visited this site recently, your browser will most likely make some noise about our self-signed certificate. For the paranoid: SHA1 Fingerprint=0C:D2:67:0D:AF:BD:88:1D:DE:E8:0A:CA:27:B3:F2:36:91:FE:C6:AC MD5 Fingerprint=54:66:21:EF:6A:2A:6E:83:F4:D3:C0:E3:55:0C:EE:01 -Mike -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From hosking at cs.purdue.edu Wed May 6 23:27:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 7 May 2009 07:27:29 +1000 Subject: [M3devel] heapalloc/try during initialization In-Reply-To: References: <20090506002150.A15FECC3B4@birch.elegosoft.com> <46F424EA-6C63-42C4-A120-C1B0FD394AA6@cs.purdue.edu> <54967B00-3878-4147-AA90-FBD09F98161B@cs.purdue.edu> Message-ID: <7413A449-0E6B-40CB-9D4E-213DFB417143@cs.purdue.edu> I'm working on this today. Let me get back to you. On 6 May 2009, at 23:53, Jay wrote: > > Something like the attached? > > (I don't trust email to be formated as expected, so the attachment > is canonical and the rest might not be readable.) > > > The idea is to provide a split CollectEnough for AllocTraced to call. > It's a little lose on the locking but it should be ok and slows down > the slow path with extra unlock/relock. > > > > It's good to get the try out of the fast path in either case. > > > > PROCEDURE LockedCollectEnough (allocator := FALSE) = > BEGIN > TRY > CollectEnough(allocator); > FINALLY > RTOS.UnlockHeap(); > END; > END LockedCollectEnough; > > > > AllocTraced calls this: > > > > PROCEDURE UnlockedCollectEnough (allocator := FALSE) = > BEGIN > RTOS.LockHeap(); > IF collectorOn THEN RTOS.UnlockHeap(); RETURN END; (* duplicated > from CollectEnough *) > IF NOT Behind() THEN RTOS.UnlockHeap(); RETURN END; (* duplicated > from CollectEnough *) > > ThreadF.Init shouldn't get here: > > > > LockedCollectEnough(allocator); > END UnlockedCollectEnough; > > > AllocTraced slow path excerpt: > > > IF nextPtr> thread.newPool.limit THEN > (* not enough space left in the pool, take the long route *) > res := NIL; nextPtr := NIL; (* in case of GC... *) > DEC(thread.inCritical); > (* make sure the collector gets a chance to keep up with NEW... > *) > UnlockedCollectEnough(allocator := TRUE); (***) > RTOS.LockHeap(); (***) > res := LongAlloc (dataSize, dataAlignment, thread.newPool, > Note.Allocated, pure := FALSE); > IF res = NIL THEN > RTOS.UnlockHeap(); (***) > RuntimeError.Raise(RuntimeError.T.OutOfMemory); > END; > INC(thread.inCritical); > LOOPHOLE(res - ADRSIZE(Header), RefHeader)^ := > Header{typecode := def.typecode, dirty := TRUE}; > IF initProc # NIL THEN initProc (res) END; > RTOS.UnlockHeap(); (***) > > DEC(thread.inCritical); > RETURN LOOPHOLE(res, REFANY); > > > This is all for user threads. > There /may/ have been issues with pthreads/ntthreads, but I don't > there are now. > Your changed didn't break cygwin pthreads but it did break FreeBSD > user threads. > I only checked each case once so might have made mistakes and gotten > it backwards or whatever. > > > Ignorant question/suggestion similar to previous: > Thread.T vs. Activation? Userthreads does traced allocations where > pthreads/win32threads don't. Maybe change userthreads? > Maybe give up on userthreads? This isn't a great reason, granted. > I actually would hope the traced thread.t vs. activation could go > away, it is ugly. Kudos for user threads for not having it?? (I > wonder if there is something around the fact that thread locals > aren't visible to the garbage collector..?) > > > - Jay From jay.krell at cornell.edu Wed May 6 23:40:24 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 6 May 2009 21:40:24 +0000 Subject: [M3devel] [Modula-3] Release engineering In-Reply-To: <164357.23058.qm@web56803.mail.re3.yahoo.com> References: <164357.23058.qm@web56803.mail.re3.yahoo.com> Message-ID: ---------------------------------------- > Date: Wed, 6 May 2009 10:04:12 -0700 > From: eiserlohpp > > Hi Olaf, > > Please help support distribution packaging (various Linux, or BSD ports) > by adding to your list: apt-get install cm3 would be nice, agreed. You have to be an official Debian developer though, right? As would cd /usr/ports/lang/cm3; make; make install. There is ezm3 but.. > o Design the cm3 installation to be long term. Specifically? > o Allow cm3 to be installed into /usr, instead of /usr/local. Doesn't that already work? I don't do it, but it should work. > o Allow installation to temporary root during package building. This does work in a fashion, but maybe not sufficiently or easily enough. But maybe both too. :) Specifically, you can install the entire system to a temporary root. You "have to" put the compiler, m3core, libm3 there, then you can also put your own stuff there. My automation does this and I think Olaf's does too. Actually I think you can start out with just the compiler. Look at make-dist.py? And the others? > o Specify guidelines for which m3.pkgs go into which distribution > packages (rpm, deb). List the suggested package names. There is a delineation of "std" and "min". The sh code is nicely data driven. The Python actually is not currently. More package sets could be defined, but it gets confusing. Is it good that X was broken down into a bajillion packages or not? Not clear to me. > o Documentation: Write manual page for cm3. Yep. > o Conform where possible to the FHS. Don't we? Is carving out /usr/local/cm3 against that? Isn't conforming to FHS a matter of what we use, not where we install, as long as we don't litter all over the system? > o Allow easy cross compiling. We do already, sort of, and for some definition of "easy". In particular, cross /compilation/ of Modula-3 is easy. There is some C code and there is some linking. Cross building involves cross compile the Modula-3, to assembly. tar it up copy it over to target system extract make -- which compiles C and links Doing a "full" cross build should just be a matter of either altering $PATH or the config file to find a different C compiler and linker. You also need a cm3cg per target. My config files (now the config files) do probe around in "reasonable" way (a little too haphazard really) so that you can have multiple cm3cgs, don't have to edit $PATH or copy files aorund. > o (lower priority) Use long form options. We have so few options and personally I think -long is fine. The only advantage of -a -b -c vs. -long is you can combine -abc unambiguously. Heck even configure supports -long even though the usage doesn't say so. > > (2) The build process of a package usually installs all files into a > subdirectory where the internal paths mimic the final installation paths > (/home/peter/src/modula3/cm3/src-all-20090506/debian/cm3-compiler). > Libraries and executable's link paths should be adjusted to their > final installation paths, not the temporary. This is already fixed or in progress. I've been mucking with "runpath" lately. I'd like to do more here, soon. There isn't one answer though. We have "buildlocal" and "buildglobal". And people want to be able to run "unshipped" (not installed) binaries. Currently the compromise: buildlocal has those paths buildglobal does not if you want to run uninstalled buildglobal, use build_standalone relinking upon install has been discussed but so far isn't done. I know some systems do that (via libtool). > (3) May I suggest this start: cm3-compiler, cm3-corelibs (minimal > install: m3core, libm3 binaries), cm3-devel (source code to m3core, > and libm3), ..., etc. > > What I don't want to see is the mass installation of a complete > development system simply because the user wanted to use a program > written in Modula-3. Understood. There are a lot shared libs though. The "min" package set satisfies many programs, but not all. build_standalone is available but not great. > Something like: > mypath := FindAbsolutePath(argv[0]); > cm3_bin_path := DirName(mypath); > cm3_path := DirName(cm3_bin_path); > cm3_etc_path := cm3_path & "/etc"; > cm3_config_filename = cm3_etc_path & "/cm3.cfg"; Ah. Not sure. /etc vs. next to the binary. I do probe around for next to the binary + target platform, for the configuration and the backend. Probing for ../etc I guess is reasonable. That way you can rm -rf the "installation" without losing the configuration. However, another idea is to declare that the configuration is not in fact user editable. I have tried to write configuration files that work for everyone. But maybe that is impossible. The actual parts that cminstall asks about to make edits aren't really user settings. They are OS settings that a better system would just get correct. Like with autoconf -- do you expect to edit its output? Only if desperate. But it is gray. Using "gcc" from $PATH vs. a full path to gcc? Using gcc-3 or gcc-4 (Cygwin and MacOSX have such). Are those "machine" settings decided during install? Or user settings? Go with the binary or in etc? I'm not sure. > (6) Cross compiling: the cm3.cfg should be a one liner, which includes > the configuration of the installed target machine . > cm3.cfg: > Include("AMD64_LINUX"); That's how I do things already, long time now. > When cross compiling the user should be able to specify the actual config file for the desired TARGET machine. My Python scripts accept a target machine on the command line. cd scripts/python ./do-cm3-core.py buildship FreeBSD4 usually with boot: ./do-cm3-core.py buildship FreeBSD4 boot but also when it is somewhat ambiguous like NT386 or NT386GNU. This guides chosing a config file. Granted, this should be in cm3, not layered on. I've been "afraid" to take such big steps without working through getting a large consensus. Layering on with Python, I can do whatever the heck I want when I want. :) Can you help? - Jay From jay.krell at cornell.edu Wed May 6 23:56:56 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 6 May 2009 21:56:56 +0000 Subject: [M3devel] heapalloc/try during initialization In-Reply-To: <7413A449-0E6B-40CB-9D4E-213DFB417143@cs.purdue.edu> References: <20090506002150.A15FECC3B4@birch.elegosoft.com> <46F424EA-6C63-42C4-A120-C1B0FD394AA6@cs.purdue.edu> <54967B00-3878-4147-AA90-FBD09F98161B@cs.purdue.edu> <7413A449-0E6B-40CB-9D4E-213DFB417143@cs.purdue.edu> Message-ID: Ok. I commited my version that seems ok and seems to work but you can overwrite it. Something that only takes the lock once would be preferred. And perhaps always uses/try/finally when it does take the lock instead of my less consistent harder to maintain form. Probably move yours away, update, copy yours on top of mine, compare. Resolving conflicts in cvs is lame.. Also, another obvious approach is to duplicate the LongAlloc initialization, such that the fast path works for the first allocation. Or even for all allocations until the GC is ready. I was reluctant to duplicate that tricky coe, but it's only a few lines really and could be moved into a shared function. Either way I think AllocTraced should not have TRY, to speed up the fast path. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 7 May 2009 07:27:29 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] heapalloc/try during initialization > > I'm working on this today. Let me get back to you. > > On 6 May 2009, at 23:53, Jay wrote: > >> >> Something like the attached? >> >> (I don't trust email to be formated as expected, so the attachment >> is canonical and the rest might not be readable.) >> >> >> The idea is to provide a split CollectEnough for AllocTraced to call. >> It's a little lose on the locking but it should be ok and slows down >> the slow path with extra unlock/relock. >> >> >> >> It's good to get the try out of the fast path in either case. >> >> >> >> PROCEDURE LockedCollectEnough (allocator := FALSE) = >> BEGIN >> TRY >> CollectEnough(allocator); >> FINALLY >> RTOS.UnlockHeap(); >> END; >> END LockedCollectEnough; >> >> >> >> AllocTraced calls this: >> >> >> >> PROCEDURE UnlockedCollectEnough (allocator := FALSE) = >> BEGIN >> RTOS.LockHeap(); >> IF collectorOn THEN RTOS.UnlockHeap(); RETURN END; (* duplicated >> from CollectEnough *) >> IF NOT Behind() THEN RTOS.UnlockHeap(); RETURN END; (* duplicated >> from CollectEnough *) >> >> ThreadF.Init shouldn't get here: >> >> >> >> LockedCollectEnough(allocator); >> END UnlockedCollectEnough; >> >> >> AllocTraced slow path excerpt: >> >> >> IF nextPtr> thread.newPool.limit THEN >> (* not enough space left in the pool, take the long route *) >> res := NIL; nextPtr := NIL; (* in case of GC... *) >> DEC(thread.inCritical); >> (* make sure the collector gets a chance to keep up with NEW... >> *) >> UnlockedCollectEnough(allocator := TRUE); (***) >> RTOS.LockHeap(); (***) >> res := LongAlloc (dataSize, dataAlignment, thread.newPool, >> Note.Allocated, pure := FALSE); >> IF res = NIL THEN >> RTOS.UnlockHeap(); (***) >> RuntimeError.Raise(RuntimeError.T.OutOfMemory); >> END; >> INC(thread.inCritical); >> LOOPHOLE(res - ADRSIZE(Header), RefHeader)^ := >> Header{typecode := def.typecode, dirty := TRUE}; >> IF initProc # NIL THEN initProc (res) END; >> RTOS.UnlockHeap(); (***) >> >> DEC(thread.inCritical); >> RETURN LOOPHOLE(res, REFANY); >> >> >> This is all for user threads. >> There /may/ have been issues with pthreads/ntthreads, but I don't >> there are now. >> Your changed didn't break cygwin pthreads but it did break FreeBSD >> user threads. >> I only checked each case once so might have made mistakes and gotten >> it backwards or whatever. >> >> >> Ignorant question/suggestion similar to previous: >> Thread.T vs. Activation? Userthreads does traced allocations where >> pthreads/win32threads don't. Maybe change userthreads? >> Maybe give up on userthreads? This isn't a great reason, granted. >> I actually would hope the traced thread.t vs. activation could go >> away, it is ugly. Kudos for user threads for not having it?? (I >> wonder if there is something around the fact that thread locals >> aren't visible to the garbage collector..?) >> >> >> - Jay > From hendrik at topoi.pooq.com Thu May 7 02:41:30 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 6 May 2009 20:41:30 -0400 Subject: [M3devel] [Modula-3] Release engineering In-Reply-To: References: <164357.23058.qm@web56803.mail.re3.yahoo.com> Message-ID: <20090507004130.GA30632@topoi.pooq.com> On Wed, May 06, 2009 at 09:40:24PM +0000, Jay wrote: > > apt-get install cm3 would be nice, agreed. > You have to be an official Debian developer though, right? No. It takes a Debian developer to put the package into the official Debian distribution. But you can get a user to update his /etc/apt/sources.list file to include your Debian-compatible repository as well as the official ones. And after that, the usual upgrade commands will detect when there's a new release, and so forth. That's not an unusual thing for upstream developers to do; it's easy on the users, and it gives a Official Debian Developer something to examine when deciding whether it conforms to Debian's standards. -- hendrik From wagner at elegosoft.com Thu May 7 18:05:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 07 May 2009 18:05:12 +0200 Subject: [M3devel] [Modula-3] Release engineering In-Reply-To: <164357.23058.qm@web56803.mail.re3.yahoo.com> References: <164357.23058.qm@web56803.mail.re3.yahoo.com> Message-ID: <20090507180512.8lvj3piqokcckook@mail.elegosoft.com> That's quite a long wish list you've got there, and as it is not Christmas, I'm afraid that we won't be able to fulfill all of them :-) The release engineering I volunteered to undertake was not supposed to add significant functionality to the existing code base; I'll only try to package what is there, perform some tests, and urge others to correct the bugs and shortcomings I find. So if something isn't there and nobody volunteers to write it, it will probably not make its way into the distribution. Indeed it would be rather late for the now planned release to add new features. Jay already made some comments, I'll add some more below, too. Quoting Peter Eiserloh : > > Hi Olaf, > > Please help support distribution packaging (various Linux, or BSD ports) > by adding to your list: > > o Design the cm3 installation to be long term. Hm. This is rather vague... > o Allow cm3 to be installed into /usr, instead of /usr/local. That should already be possible; AFAIK there is no need to install to a certain location. > o Allow installation to temporary root during package building. Jay commented on it, but I'm not sure if that was what you meant. > o Specify guidelines for which m3.pkgs go into which distribution > packages (rpm, deb). List the suggested package names. Sure we can suggest a classification of M3 packages for installation packages; I cannot build system dependent package formats though (unless we automate that at a central and publicly reachable location). > o Documentation: Write manual page for cm3. I can do that. > o Conform where possible to the FHS. Don't we? You don't mean we should split up all the packages into different locations, do you? > o Allow easy cross compiling. Cross-compilation is never easy in my experience, but Jay has done a lot of work in this area. > o (lower priority) Use long form options. Where exactly? Perhaps we can add some additional long options where you would most need them? > Explaination: > > (0) Only the administrator should install packages into the system. > If a user wants to play with a recent version of CM3, they should be > able to install into their home directory. This will allow the > other users of the machine to continue using the known good compiler > even though one user is experimenting with buggy new features of > the compiler. This will also allow easier cross compiling. > > (1) /usr/local is only for files/packages manually installed > by the superuser. Distributions are expected (in debian, required) to > install into "/usr" (or if required to boot, into "/", eg., /sbin/mount). That's exactly because the default installation of CM3 is /usr/local ;-) We've never provided system-specific package formats until now. Of course system packages should install into their preferred locations. > (2) The build process of a package usually installs all files into a > subdirectory where the internal paths mimic the final installation paths > (/home/peter/src/modula3/cm3/src-all-20090506/debian/cm3-compiler). > Libraries and executable's link paths should be adjusted to their > final installation paths, not the temporary. I doubt that I will be able to do something about the paths problems. I hope that Jay's $ORIGIN uses will somehow be adequate. > (3) May I suggest this start: cm3-compiler, cm3-corelibs (minimal > install: m3core, libm3 binaries), cm3-devel (source code to m3core, > and libm3), ..., etc. CM3 always installs the complete source code along with the package targets (libraries or programs), as there are many tools that rely on it. > What I don't want to see is the mass installation of a complete > development system simply because the user wanted to use a program > written in Modula-3. We always offered a minimal binary package. I'll think about a useful classification of packages. > (4) Debian at least requires a manual page for executables. A bug > will be written against any package that installs user (or superuser) > binaries without a manual page. I won't be able to provide manual pages for all M3 programs. > (5) The Filesystem Hierarchy Standard (FHS) http://www.pathname.com/fhs/ > says things such as libraries are not execuables invocable by the user > so don't put them in $(prefix)/bin. Okay, MS-Windows violates this all > the time, but they are "special". Can we move cm3.cfg out of the binary > directory (where there should only be executables), and into > ${CM3_PATH}/etc. I won't change anything concerning the configuration files at the last minute. This will most likely result in weeks of delay (as it will break lots of scripts and regression tests). The location of configuration files can always be overridden by the environment; system-specific packages should use this feature if necessary. As I've said, several provided scripts will break, but they aren't usually end-user relevant. > Something like: > mypath := FindAbsolutePath(argv[0]); > cm3_bin_path := DirName(mypath); > cm3_path := DirName(cm3_bin_path); > cm3_etc_path := cm3_path & "/etc"; > cm3_config_filename = cm3_etc_path & "/cm3.cfg"; I'm not against such changes, but they won't make it into this release, and somebody will have to volunteer to do them. > (6) Cross compiling: the cm3.cfg should be a one liner, which includes > the configuration of the installed target machine . > cm3.cfg: > Include("AMD64_LINUX"); > > When cross compiling the user should be able to specify the actual > config file for the desired TARGET machine. Nice wish, but maybe Jay will deliver something here. > (7) Although each program is free to define is command line arguments > and options, a set of conventions has been in place for at least > 15 years or more. GCC of course (being an older program) violates > these "recent" conventions. > > Options start with a dash. Single letter options start with a > single dash, and multiple options may be collected into one > sequence (ie, "-shared", means -s, -h, -a, -r, -e, -d). Long > options use two dashes and signify that the sequence of characters > are to be used as a complete string (ie, "--shared" means generate > a "shared" library). Long options that take an argument are formed > with an equal sign (eg. "--config=/home/peter/cm3/etc/cm3.cfg"). > > Instead of "-version" with a single dash, long form options use > two dashes "--version", a single dash "-v" could also be mapped > to be an alias of that option. We can add some long options, as said before, but I'm not going to break all backward compatibility by removing or changing existing ones. Someone will have to write an extended ParseParams module though :-) Could you provide one? > Sorry for being long winded, but my system administrator is a > real hard ass, every time I see myself in the mirror, he reminds > me of that. Well, I hope he won't be too dissatisfied, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri May 8 00:01:42 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 7 May 2009 18:01:42 -0400 Subject: [M3devel] XML? Message-ID: <20090507220142.GA32564@topoi.pooq.com> Is there a standard library for Modula 3 that reads and writes XML files? With or without DTD definitions? -- hendrik From mika at async.caltech.edu Fri May 8 00:53:53 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 07 May 2009 15:53:53 -0700 Subject: [M3devel] XML? In-Reply-To: Your message of "Thu, 07 May 2009 18:01:42 EDT." <20090507220142.GA32564@topoi.pooq.com> Message-ID: <200905072253.n47Mrrmu059675@camembert.async.caltech.edu> Hendrik, I use the following nasty hack to read XML (only): http://www.async.caltech.edu/~mika/xmlparse.tgz cit_util is probably compatible with the one inside caltech_parser in the CM3 dist. Not sure if it uses anything beyond the Debug interface from there. Mika hendrik at topoi.pooq.com writes: >Is there a standard library for Modula 3 that reads and writes XML >files? With or without DTD definitions? > >-- hendrik From dabenavidesd at yahoo.es Fri May 8 02:02:41 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 7 May 2009 17:02:41 -0700 (PDT) Subject: [M3devel] XML? In-Reply-To: <20090507220142.GA32564@topoi.pooq.com> Message-ID: <367599.3562.qm@web24708.mail.ird.yahoo.com> Hi: You can take a? look of the originally pm3 SGML parser that could work for your need: cm3/m3-libs/sgml see on http://opencm3.net/doc/help/gen_html/sgml/INDEX.html It needs Deep copy library: cm3/m3-libs/deepcopy for building see on http://opencm3.net/doc/help/gen_html/deepcopy/INDEX.html A shorter help of parser from m3doc http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/sgml/src/index.html Hope that helps --- El jue, 7/5/09, hendrik at topoi.pooq.com escribi?: De: hendrik at topoi.pooq.com Asunto: [M3devel] XML? Para: m3devel at elegosoft.com Fecha: jueves, 7 mayo, 2009 5:01 Is there a standard library for Modula 3 that reads and writes XML files? With or without DTD definitions? -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri May 8 04:31:35 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 7 May 2009 19:31:35 -0700 Subject: [M3devel] XML? In-Reply-To: <367599.3562.qm@web24708.mail.ird.yahoo.com> References: <367599.3562.qm@web24708.mail.ird.yahoo.com> Message-ID: <5BEB3EED-7B84-4598-8984-19685D84ABB2@hotmail.com> We should probably wrap up something like expat.. - Jay (phone) On May 7, 2009, at 5:02 PM, "Daniel Alejandro Benavides D." wrote: > Hi: > You can take a look of the originally pm3 SGML parser that could > work for your need: cm3/m3-libs/sgml see on http://opencm3.net/doc/help/gen_html/sgml/INDEX.html > > It needs Deep copy library: cm3/m3-libs/deepcopy for building see on http://opencm3.net/doc/help/gen_html/deepcopy/INDEX.html > > A shorter help of parser from m3doc http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/sgml/src/index.html > > Hope that helps > > --- El jue, 7/5/09, hendrik at topoi.pooq.com > escribi?: > De: hendrik at topoi.pooq.com > Asunto: [M3devel] XML? > Para: m3devel at elegosoft.com > Fecha: jueves, 7 mayo, 2009 5:01 > > Is there a standard library for Modula 3 that reads and writes > XML > files? With or without DTD definitions? > > -- hendrik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Fri May 8 04:46:39 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 7 May 2009 22:46:39 -0400 Subject: [M3devel] XML? In-Reply-To: <200905072253.n47Mrrmu059675@camembert.async.caltech.edu> References: <20090507220142.GA32564@topoi.pooq.com> <200905072253.n47Mrrmu059675@camembert.async.caltech.edu> Message-ID: <20090508024638.GB418@topoi.pooq.com> On Thu, May 07, 2009 at 03:53:53PM -0700, Mika Nystrom wrote: > Hendrik, > > I use the following nasty hack to read XML (only): > > http://www.async.caltech.edu/~mika/xmlparse.tgz > > cit_util is probably compatible with the one inside caltech_parser > in the CM3 dist. Not sure if it uses anything beyond the Debug > interface from there. > > Mika This is a M3 wrapper to use an existing C library, right? -- hendrik From hendrik at topoi.pooq.com Fri May 8 04:58:25 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 7 May 2009 22:58:25 -0400 Subject: [M3devel] XML? In-Reply-To: <367599.3562.qm@web24708.mail.ird.yahoo.com> References: <20090507220142.GA32564@topoi.pooq.com> <367599.3562.qm@web24708.mail.ird.yahoo.com> Message-ID: <20090508025825.GC418@topoi.pooq.com> On Thu, May 07, 2009 at 05:02:41PM -0700, Daniel Alejandro Benavides D. wrote: > Hi: > You can take a? look of the originally pm3 SGML parser that could work > for your need: cm3/m3-libs/sgml see on > http://opencm3.net/doc/help/gen_html/sgml/INDEX.html This one does SGML, which XML is compatible with, but not the same as. There was a big effort to make sure that SGML and XML had a very viable intersection (that's what they used to write the standard). But SGML has a lot of conventions whereby you can leave out tags. XML does not. I gather a lot of this might have to be handled by the user's Application object class. Will look further. Much of the stuff I have to process today are .fodt files, which are quite strictly conforming to the spec, and other ad-hoc XMLish files, which don't even have a DTD. > > It needs Deep copy library: cm3/m3-libs/deepcopy for building see on > http://opencm3.net/doc/help/gen_html/deepcopy/INDEX.html > > A shorter help of parser from m3doc > http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/sgml/src/index.html This one actually seems to be designed for XML as well as SGML. It looks as if the SGML part of it makes it more complicated than would be necessary if it just did XML. In any case, the XML standard specifies both what a validating XML processor has to do, and what a nonvalidating processor has to do. So there is some wiggle room in the spec here. -- hendrik > > Hope that helps > > --- El jue, 7/5/09, hendrik at topoi.pooq.com escribi?: > De: hendrik at topoi.pooq.com > Asunto: [M3devel] XML? > Para: m3devel at elegosoft.com > Fecha: jueves, 7 mayo, 2009 5:01 > > Is there a standard library for Modula 3 that reads and writes XML > files? With or without DTD definitions? > > -- hendrik > > > > > From mika at async.caltech.edu Fri May 8 05:22:38 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 07 May 2009 20:22:38 -0700 Subject: [M3devel] XML? In-Reply-To: Your message of "Thu, 07 May 2009 22:46:39 EDT." <20090508024638.GB418@topoi.pooq.com> Message-ID: <200905080322.n483MdBQ069069@camembert.async.caltech.edu> Yes, and not a very capable one, sorry. Works for what I was doing... shouldn't be too hard to extend. Mika hendrik at topoi.pooq.com writes: >On Thu, May 07, 2009 at 03:53:53PM -0700, Mika Nystrom wrote: >> Hendrik, >> >> I use the following nasty hack to read XML (only): >> >> http://www.async.caltech.edu/~mika/xmlparse.tgz >> >> cit_util is probably compatible with the one inside caltech_parser >> in the CM3 dist. Not sure if it uses anything beyond the Debug >> interface from there. >> >> Mika > >This is a M3 wrapper to use an existing C library, right? > >-- hendrik From dragisha at m3w.org Fri May 8 13:50:06 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 08 May 2009 13:50:06 +0200 Subject: [M3devel] ***SPAM*** Re: XML? In-Reply-To: <5BEB3EED-7B84-4598-8984-19685D84ABB2@hotmail.com> References: <367599.3562.qm@web24708.mail.ird.yahoo.com> <5BEB3EED-7B84-4598-8984-19685D84ABB2@hotmail.com> Message-ID: <1241783406.15444.3.camel@faramir.m3w.org> I have it wrapped, but it looks like there is strong resistance in "m3 movement" for including anything that can not work on, or assume some C porting work for specific m3 platform. On Thu, 2009-05-07 at 19:31 -0700, jay.krell at cornell.edu wrote: > We should probably wrap up something like expat.. > > - Jay (phone) > > On May 7, 2009, at 5:02 PM, "Daniel Alejandro Benavides D." > wrote: > > > > > Hi: > > You can take a look of the originally pm3 SGML parser that could > > work for your need: cm3/m3-libs/sgml see on > > http://opencm3.net/doc/help/gen_html/sgml/INDEX.html > > > > It needs Deep copy library: cm3/m3-libs/deepcopy for building see on > > http://opencm3.net/doc/help/gen_html/deepcopy/INDEX.html > > > > A shorter help of parser from m3doc > > http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/sgml/src/index.html > > > > Hope that helps > > > > --- El jue, 7/5/09, hendrik at topoi.pooq.com > > escribi?: > > De: hendrik at topoi.pooq.com > > Asunto: [M3devel] XML? > > Para: m3devel at elegosoft.com > > Fecha: jueves, 7 mayo, 2009 5:01 > > > > Is there a standard library for Modula 3 that reads and writes > > XML > > files? With or without DTD definitions? > > > > -- hendrik > > > > > > -- Dragi?a Duri? From dragisha at m3w.org Fri May 8 13:54:25 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 08 May 2009 13:54:25 +0200 Subject: [M3devel] release engineering etc Message-ID: <1241783665.15444.8.camel@faramir.m3w.org> expat (an UTF8 before) makes me think we need to allow some flexibility in development process - se we can allow some packages not being available on all platforms - for some period of time while we find somebody to tune it to platforms with initial issues. Somehow we must track packages that need more work on specific platform (probably already done throgh tinderbox) and use that information to keep loose ends under control. Some packages will then be tagged beta or something while work is in progress. -- Dragi?a Duri? From hendrik at topoi.pooq.com Fri May 8 15:46:04 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 8 May 2009 09:46:04 -0400 Subject: [M3devel] ***SPAM*** Re: XML? In-Reply-To: <1241783406.15444.3.camel@faramir.m3w.org> References: <367599.3562.qm@web24708.mail.ird.yahoo.com> <5BEB3EED-7B84-4598-8984-19685D84ABB2@hotmail.com> <1241783406.15444.3.camel@faramir.m3w.org> Message-ID: <20090508134604.GA1190@topoi.pooq.com> On Fri, May 08, 2009 at 01:50:06PM +0200, Dragi?a Duri? wrote: > I have it wrapped, but it looks like there is strong resistance in "m3 > movement" for including anything that can not work on, or assume some C > porting work for specific m3 platform. There is, and it's probably because M3 arose from a strong tradition of self-sufficiency. Way back then, people were designing systems languages -- languages that could be used to implement an entire system, including its own run-time system. It means that M3 is a viable language for bootstrapping onto a new machine. Except, as far as I know, that it still relies on gcc's back end (written in C) for its code generation, and which causes license incompatibilities with the SRC license. Didn't M3 once generate C code, as Eiffel still does? And did it generate anything else before those C-generating days? What was M3 originally written in? MESA? -- hendrik > > On Thu, 2009-05-07 at 19:31 -0700, jay.krell at cornell.edu wrote: > > We should probably wrap up something like expat.. > > > > - Jay (phone) > > > > On May 7, 2009, at 5:02 PM, "Daniel Alejandro Benavides D." > > wrote: > > > > > > > > > Hi: > > > You can take a look of the originally pm3 SGML parser that could > > > work for your need: cm3/m3-libs/sgml see on > > > http://opencm3.net/doc/help/gen_html/sgml/INDEX.html > > > > > > It needs Deep copy library: cm3/m3-libs/deepcopy for building see on > > > http://opencm3.net/doc/help/gen_html/deepcopy/INDEX.html > > > > > > A shorter help of parser from m3doc > > > http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/sgml/src/index.html > > > > > > Hope that helps > > > > > > --- El jue, 7/5/09, hendrik at topoi.pooq.com > > > escribi?: > > > De: hendrik at topoi.pooq.com > > > Asunto: [M3devel] XML? > > > Para: m3devel at elegosoft.com > > > Fecha: jueves, 7 mayo, 2009 5:01 > > > > > > Is there a standard library for Modula 3 that reads and writes > > > XML > > > files? With or without DTD definitions? > > > > > > -- hendrik > > > > > > > > > > -- > Dragi?a Duri? > From wagner at elegosoft.com Fri May 8 16:03:10 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 08 May 2009 16:03:10 +0200 Subject: [M3devel] XML? In-Reply-To: <1241783406.15444.3.camel@faramir.m3w.org> References: <367599.3562.qm@web24708.mail.ird.yahoo.com> <5BEB3EED-7B84-4598-8984-19685D84ABB2@hotmail.com> <1241783406.15444.3.camel@faramir.m3w.org> Message-ID: <20090508160310.0zq70ex1nossgwkg@mail.elegosoft.com> Quoting Dragi?a Duri? : > I have it wrapped, but it looks like there is strong resistance in "m3 > movement" for including anything that can not work on, or assume some C > porting work for specific m3 platform. There are no objections from my side to add expat interfaces. We should probably add expat to the external SYSTEM_LIBRARIES then. Why not just check-in the package and see where we can get it to compile? It's probably not relevant for the current release though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Fri May 8 20:22:12 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 08 May 2009 11:22:12 -0700 Subject: [M3devel] ***SPAM*** Re: XML? In-Reply-To: Your message of "Fri, 08 May 2009 09:46:04 EDT." <20090508134604.GA1190@topoi.pooq.com> Message-ID: <200905081822.n48IMCxl002447@camembert.async.caltech.edu> Here's my understanding, and it may be incorrect in places: I think there were originally two separate implementations of Modula-3, one from DEC and one from Olivetti (ORL/Palo Alto). I think they both generated C code. The DEC one later became a native compiler, both with a native back end and by modifying gcc. (So it's not accurate to say that M3 relies on gcc---Jay's work on Windows doesn't use gcc at all.) That's what you get if you run "cm3". The Olivetti one moved with Mick Jordan to PARC when ORL closed, and most of it is still in the tree under "m3tk". Look in m3tk/src/target. There seem to be back ends for C code on i386 (running System V), mips, sparc, sun3, and vax (running BSD Unix). There's a very brief man page for a program called "m3cbe". The M3 system has all kinds of hooks for different types of machines, e.g., pre-OSX Mac and VMS. Not sure to what extent it ever worked on those. There is also a back end for C-code generation on the Caltech Mosaic-C multicomputer and probably others I'm unaware of. I think the problem with pulling in things like expat isn't that "people use it" but that there's a temptation to use it for building Modula-3 itself. That's the sort of thing that needs to be guarded against, I think. I would suggest putting things that create outside dependencies in some separate, clearly marked subtree, so that they can't sneak into the base system. Mika hendrik at topoi.pooq.com writes: >On Fri, May 08, 2009 at 01:50:06PM +0200, Dragi??a Duri?? wrote: >> I have it wrapped, but it looks like there is strong resistance in "m3 >> movement" for including anything that can not work on, or assume some C >> porting work for specific m3 platform. > >There is, and it's probably because M3 arose from a strong tradition of >self-sufficiency. Way back then, people were designing systems >languages -- languages that could be used to implement an entire system, >including its own run-time system. It means that M3 is a viable >language for bootstrapping onto a new machine. > >Except, as far as I know, that it still relies on gcc's back end >(written in C) for its code generation, and which causes license >incompatibilities with the SRC license. > >Didn't M3 once generate C code, as Eiffel still does? And did it >generate anything else before those C-generating days? > >What was M3 originally written in? MESA? > >-- hendrik > >> >> On Thu, 2009-05-07 at 19:31 -0700, jay.krell at cornell.edu wrote: >> > We should probably wrap up something like expat.. >> > >> > - Jay (phone) >> > >> > On May 7, 2009, at 5:02 PM, "Daniel Alejandro Benavides D." >> > wrote: >> > >> > >> > >> > > Hi: >> > > You can take a look of the originally pm3 SGML parser that could >> > > work for your need: cm3/m3-libs/sgml see on >> > > http://opencm3.net/doc/help/gen_html/sgml/INDEX.html >> > > >> > > It needs Deep copy library: cm3/m3-libs/deepcopy for building see on >> > > http://opencm3.net/doc/help/gen_html/deepcopy/INDEX.html >> > > >> > > A shorter help of parser from m3doc >> > > http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/sgml/src/index.html >> > > >> > > Hope that helps >> > > >> > > --- El jue, 7/5/09, hendrik at topoi.pooq.com >> > > escribi??: >> > > De: hendrik at topoi.pooq.com >> > > Asunto: [M3devel] XML? >> > > Para: m3devel at elegosoft.com >> > > Fecha: jueves, 7 mayo, 2009 5:01 >> > > >> > > Is there a standard library for Modula 3 that reads and writes >> > > XML >> > > files? With or without DTD definitions? >> > > >> > > -- hendrik >> > > >> > > >> > > >> -- >> Dragi??a Duri?? >> From hendrik at topoi.pooq.com Sat May 9 04:15:25 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 8 May 2009 22:15:25 -0400 Subject: [M3devel] release engineering etc In-Reply-To: <1241783665.15444.8.camel@faramir.m3w.org> References: <1241783665.15444.8.camel@faramir.m3w.org> Message-ID: <20090509021525.GB2642@topoi.pooq.com> On Fri, May 08, 2009 at 01:54:25PM +0200, Dragi?a Duri? wrote: > expat (an UTF8 before) makes me think we need to allow some flexibility > in development process - se we can allow some packages not being > available on all platforms - for some period of time while we find > somebody to tune it to platforms with initial issues. Somehow we must > track packages that need more work on specific platform (probably > already done throgh tinderbox) and use that information to keep loose > ends under control. > Some packages will then be tagged beta or something while work is in > progress. I browsed the source ttree for expat online earlier today, and there seem to be a lot of directories withougt any current files. Most of these are directories that seem to be for specific platforms, leaving me to wonder if they have been abandoned, or whether the developers have succeeded in unifying them, so they don't need system specific code any more. There may turn out to be fewer variants than you think. -- hendrik From eiserlohpp at yahoo.com Sat May 9 05:44:20 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 8 May 2009 20:44:20 -0700 (PDT) Subject: [M3devel] Release engineering Message-ID: <172161.40937.qm@web56807.mail.re3.yahoo.com> Hi Jay and Everyone, > from: Jay jay.krell at cornell.edu > date: Wed May 6 23:40:24 CEST 2009 >apt-get install cm3 would be nice, agreed. >You have to be an official Debian developer though, right? In order to submit a debian package for inclusion into the Debian distribution. Even so, one can become a new maintainer and study under a mentor. Regardless of that, we can create our own packages and put them in our own repository, until one of us does become involved in the debian, ubuntu, linux-mint, ..., etc distributions. I myself, have built a number of debian packages, these were intended for local operations, and never sent out of the work area. Actually, the *.deb files were burnt to CD, and installed on a target machine. >> o Allow cm3 to be installed into /usr, instead of /usr/local. > >Doesn't that already work? >I don't do it, but it should work. Okay, I will attempt to ship into a path like /usr/opt/cm3 just to exercise that ablility. After testing to verify the installation, I will delete it. Then I will attempt to install into temporary directory, followed by copying into a final destination /usr/opt/cm3, and test. > Look at make-dist.py? And the others? Okay, when I will before attempting the above. >> o Documentation: Write manual page for cm3. >Yep. Okay I did this. It can be downloaded from the link below. http://www.eiserloh.org/~peter/modula3/ >> o Allow easy cross compiling. > > We do already, sort of, and for some definition of "easy". > In particular, cross /compilation/ of Modula-3 is easy. > There is some C code and there is some linking. > Cross building involves > cross compile the Modula-3, to assembly. > tar it up > copy it over to target system > extract > make -- which compiles C and links > > Doing a "full" cross build should just be a matter of > either altering $PATH or the config file to find a different > C compiler and linker. > You also need a cm3cg per target. > My config files (now the config files) do probe around > in "reasonable" way (a little too haphazard really) > so that you can have multiple cm3cgs, don't have to edit $PATH > or copy files aorund. > However, another idea is to declare that the configuration > is not in fact user editable. Now you are getting the IDEA. Currently to do a cross compile the user has to change a global (system) configuration file. This would interfere with any other user on the system, and of course require super-user privileges. The important part is that it would INTERFERE with the OTHER users. (Sorry for shouting). Okay, what I would like to see, is something like # apt-get install cm3-compiler-ppc-darwin # apt-get install cm3-compiler-amd64-darwin # apt-get install cm3-compiler-amd64-freebsd # apt-get install cm3-compiler-sparc64-solaris # apt-get install cm3-compiler-nt386 # exit $ ls /usr/cm3/bin cm3 cm3cg-AMD64_DARWIN cm3cg-AMD64_FREEBSD cm3cg-AMD64_LINUX cm3cg-NT386 cm3cg-PPC_DARWIN cm3cg-SPARC64_SOLARIS $ls /usr/cm3/etc cm3.cfg AMD64_DARWIN AMD64_FREEBSD AMD64_LINUX NT386 PPC_DARWIN SPARC64_SOLARIS Now cm3.cfg contains one line Include("AMD64_LINUX"); Because this is the architecture of the host machine. > That's how I do things already, long time now. Yes, I like the idea of the main configuration simply including the real one. It is conceptually easier to understand. When I saw that about a year ago, I really liked it, thanks. I just took that idea one step further. The other TARGET files in ${CM3PATH}/etc, are designed for cross compiling, they use the linker on the host computer. cm3 --use-config=NT386 would invoke assembler: i586-mingw32msvc-as and linker: i586-mingw32msvc-ld. Then any of the many users on the machine may attempt a cross compile without interfering with any other user. By using either a command line argument, or the environment variable M3CONFIG, the compiler will be informed which target is requested. NOTE: I think the cm3 frontend is currently target independent, after parsing the source code, it calls a backend (eg, cm3cg-PPC_DARWIN) to generate the object code. For example with M3CONFIG $ M3CONFIG=PPC_DARWIN cm3 -build Alternatively using an argument (here I invent --use-config, it looks cleaner). $ cm3 --use-config=PPC_DARWIN -build Lastly, if I (a normal user) were experimenting with different config files cm3 --use-config=/home/peter/src/experiment/mysuper.cfg -build > Can you help? Step one (the easy one) was to write a manual page for cm3. Please comment, so that we can flush out any problems and add anything. Maybe document the runtime @m3options. Again http://www.eiserloh.org/~peter/modula3/ BTW: I got my example m3hexdump.m3 program to work, but only if I don't specify the desired program name, so the resulting executable is "../AMD64_LINUX/prog". peter at black:~/modula-3/m3hexdump/src $ cm3 -o M3Hexdump --- building in ../AMD64_LINUX --- -> linking M3Hexdump Fatal Error: incomplete program missing "Main" module Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From eiserlohpp at yahoo.com Sat May 9 07:07:02 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 8 May 2009 22:07:02 -0700 (PDT) Subject: [M3devel] Release engineering Message-ID: <527913.7261.qm@web56808.mail.re3.yahoo.com> Hi Olaf, > That's quite a long wish list you've got there, and as it is not > Christmas, I'm afraid that we won't be able to fulfill all of them :-) True, version 6.0 is only a couple years away. If we start planning things now, then they have a chance of happening. > That's exactly because the default installation of CM3 is /usr/local ;-) > We've never provided system-specific package formats until now. > Of course system packages should install into their preferred locations. Yes! A distribution is not supposed to install anything into /usr/local. This is for the administrator to installing from a source package, and manually installing them. Like what we have done. Download the a min install, and a source tarball, or do a CVS checkout. Build and ship. These days we want to play with the distribution's mechanisms for installing software. >> o Allow installation to temporary root during package building. > > Jay commented on it, but I'm not sure if that was what you meant. During the building of a debian package (probably similar in an RPM) all the binary executables and libraries are built, but instead of installing them into their final destination (which is on the host system), they are installed into a temporary tree Some source packages can use their own makefile install target specifying a DEST_DIR. We would probably want to do something like For example, for package cm3-compiler_5.8 rules would contain pkg_cm3=/home/peter/src/modula3/cm3/src-all/debian/tmp-cm3/ bin_dir=${pkg_cm3}/usr/cm3/bin etc_dir=${pkg_cm3}/usr/cm3/etc lib_dir=${pkg_cm3}/usr/cm3/lib pkgs_dir=${pkg_cm3}/usr/cm3/pkg mkdir -p ${bin_dir} mkdir -p ${lib_dir} mkdir -p ${pkg_cm3}/usr/cm3/pkg install m3-sys/cm3/${TARGET}/cm3 ${bin-dir} install m3-sys/m3cc/${TARGET}/m3cc ${bin_dir} A number of administrative files are also installed into here such as "DEBIAN/control", and "DEBIAN/confiles". Once the directory tree has been built, then it is archived up. Debian's *.deb file use "ar" for this. Then when a package is installed by the super-user, all files are installed to their destinations (except configuration files, they get another stage). >> o Documentation: Write manual page for cm3. > >I can do that. Ah.., I already did. Just cm3, still need to write modula3.man, m3makefile.man, and m3overrides.man. It would be bad form to suggest all sorts of things, and then not actually do anything myself. http://www.eiserloh.org/~peter/modula3/#mydocs > I won't be able to provide manual pages for all M3 programs. Didn't expect that for all programs, but then we aren't talking about installing all those programs in the m3 repository. Sure zeus, and obliq and so forth are cool, but they are not the Modula-3 compiler, nor libm3. Those would be in packages such as "zeus", and "obliq". >I'm not against such changes, but they won't make it into this release, >and somebody will have to volunteer to do them. Again, I agree that a release of 5.8 should be soon. And soon, means no significant changes. BTW: I imported the CVS repository as a GIT repository, I intend to make this visible externally, but in the mean time it is in a private directory. I looked at the cm3-releases branch, wow it has been a long time since the last release, which according to the repository, 5.1 was released (2001-01-24). Cool you got gcc-4.3, after 5.8 is released, are we going to update the gcc backend to 4.3? What version is currently in the backend. BTW(2): When I built the cm3.man manual page, I saw the -config option which simply wrote the version number, instead of the configuration info. Could it at least print the TARGET architecture? > Well, I hope he won't be too dissatisfied, Well, I (<-<-) he does understand exactly where I am, and what I am attempting. I have been playing on the extreme periphery of M3 development for the past 14 or 15 years, when I first heard of it. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Sat May 9 13:03:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 09 May 2009 13:03:55 +0200 Subject: [M3devel] Release engineering In-Reply-To: <527913.7261.qm@web56808.mail.re3.yahoo.com> References: <527913.7261.qm@web56808.mail.re3.yahoo.com> Message-ID: <20090509130355.3la6r1ds00sgcoss@mail.elegosoft.com> Quoting Peter Eiserloh : >>>> o Documentation: Write manual page for cm3. >> >> I can do that. > > Ah.., I already did. Just cm3, still need to write > modula3.man, m3makefile.man, and m3overrides.man. > > It would be bad form to suggest all sorts of things, and then > not actually do anything myself. > > http://www.eiserloh.org/~peter/modula3/#mydocs I just added that to the repository. > Again, I agree that a release of 5.8 should be soon. And soon, > means no significant changes. > BTW: I imported the CVS repository as a GIT repository, > I intend to make this visible externally, but in the > mean time it is in a private directory. I looked at the > cm3-releases branch, wow it has been a long time since > the last release, which according to the repository, > 5.1 was released (2001-01-24). That's just the branch where the old releases from Critical Mass were imported. IIRC, the last CM3 release was around 2006 :-) > Cool you got gcc-4.3, after 5.8 is released, are we going > to update the gcc backend to 4.3? What version is currently > in the backend. > > BTW(2): When I built the cm3.man manual page, I saw the > -config option which simply wrote the version number, instead > of the configuration info. Could it at least print the > TARGET architecture? Should be no problem. >> Well, I hope he won't be too dissatisfied, > Well, I (<-<-) he does understand exactly where I am, > and what I am attempting. > > I have been playing on the extreme periphery of M3 development > for the past 14 or 15 years, when I first heard of it. Then this might be a good time to become more involved? :-)) Any help is welcome. I've been thinking today about using the .M3SHIP files for installation purposes. Curently, the paths they contain are all resolved like this: make_dir("/usr/local/cm3/pkg/test/FreeBSD4") install_file(".M3EXPORTS", "/usr/local/cm3/pkg/test/FreeBSD4", "0644") install_file(".M3WEB", "/usr/local/cm3/pkg/test/FreeBSD4", "0644") make_dir("/usr/local/cm3/pkg/test/src") install_file("../src/Test.m3", "/usr/local/cm3/pkg/test/src", "0644") install_file("Test", "/usr/local/cm3/pkg/test/FreeBSD4", "0644") If we use the variables defined in the cm3 config file, we can defer path resolution to installation time: make_dir(PKG_INSTALL & "/test/FreeBSD4") install_file(".M3EXPORTS", PKG_INSTALL & "/test/FreeBSD4", "0644") install_file(".M3WEB", PKG_INSTALL & "/test/FreeBSD4", "0644") make_dir(PKG_INSTALL & "/test/src") install_file("../src/Test.m3", PKG_INSTALL & "/test/src", "0644") install_file("Test", PKG_INSTALL & "/test/FreeBSD4", "0644") Not really a good example, as its just a test package; others could also use BIN_INSTALL, LIB_INSTALL, MAN_INSTALL, DOC_INSTALL, HTML_INSTALL etc. We could even add ETC_INSTALL if you like ;-) Then we could just run cm3 -ship for any package installation, and perhaps even provide system-specific overrides for the install routines in quake if needed. Installation packages could contain a workspace with precompiled packages, and actual package installation is done on the target system by cm3 itself. I haven't really thought it through nor tested it though. It looks as if it wouldn't be too difficult to implement. Comments welcome, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat May 9 21:08:27 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 9 May 2009 19:08:27 +0000 Subject: [M3devel] Release engineering In-Reply-To: <20090509130355.3la6r1ds00sgcoss@mail.elegosoft.com> References: <527913.7261.qm@web56808.mail.re3.yahoo.com> <20090509130355.3la6r1ds00sgcoss@mail.elegosoft.com> Message-ID: > From: wagner > I've been thinking today about using the .M3SHIP files for > installation purposes. Curently, the paths they contain are all > resolved like this: > > install_file(".M3EXPORTS", "/usr/local/cm3/pkg/test/FreeBSD4", "0644") > > If we use the variables defined in the cm3 config file, we can > defer path resolution to installation time: > > install_file(".M3EXPORTS", PKG_INSTALL & "/test/FreeBSD4", "0644") I think: This is an ok idea. Like if you want merge cminstall functionality into cm3. I think the SRC releases pretty much worked this way, with the advantage that cm3 was implemented in C and could be built at install time. Heck, cm3 -ship could try to do diskspace checking. :) But I don't think this solves a problem anyone has yet brought up. The two solutions are, to the problem I think brought up: - link at ship time -- which you'd combine with this idea - use $ORIGIN I think most systems support that now. One exception is NetBSD 4.0. 5.0 supports it. MacOSX has something different. They added stuff in 10.5 and I think 10.4, and I think the 10.4 feature suffices. I'd still like to switch to hard links here so that $ORIGIN use is just $ORIGIN/../lib for all shared objects and executables, and "hidden" executables will ship to (hard link to) lib. $ORIGIN/../lib seemed to already work on Linux but that was surprising and it didn't work on other systems (I think Solaris?) Ok, hm, I tell you what this can help though. It can help bootstrapping. It can help "large" distributing bootstrap archives. The advantage of distributing bootstrap archives is that "FreeBSD" can resolve at install time to 4.x, 5.x, 6.x, 7.x, whatever. There'd still be, like, my Makefile for building cm3 on the target. But then cm3 can ship everything else into place. This, like, saves me from writing Python to convert the .m3ship files into a makefile or sh or such. Also not difficult. Normally I just bootstrap cm3 and then build everything else on the target. However for distribution purposes, for building something that is a hybrid between "precompiled binary package for install speed" and "source that is more portable to various systems"..this is not a bad idea. There's still the sticking point as to when cm3cg is built and/or if the user has to wait for it to be built. You'd end up being able to run all the Modula-3 stuff, but can't build anything until you first build cm3cg. Maybe not a terrible idea. It doesn't take TOO long except on cygwin or old machines. Maybe we can use the system's gmp/mpfr if they exist, that saves a lot. This makes me wonder also if "distribution builders" should do cross builds targeting older releases, like FreeBSD 5.x, Linux whatever, etc. It's a bit of a pain though. And only viable where cc/ld are open source, and even then probably only where they are both GNU (even if Apple and Sun are also open source). - Jay From jay.krell at cornell.edu Sat May 9 21:17:49 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 9 May 2009 19:17:49 +0000 Subject: [M3devel] cross build file system layout? Message-ID: [unnecessarily long-winded sorry] We should consider where files should be placed regarding cross builds? installroot/bin/host/target/cm3cg installroot/bin/host/config/target or installroot/bin/host/config/target.cfg or installroot/bin/host/target.cfg or installroot/bin/etc/target.cfg or installroot/etc/cm3/target.cfg ? installroot/bin/host/cm3 installroot/bin/cm3 is a little sh? (and also cm3.cmd) installroot/lib/target/libfoo.so installroot/pkg unchanged, already contains target ? or host is implied in installroot? installroot/bin/target/cm3cg installroot/bin//config/target (file) installroot/bin/host/cm3 installroot/bin/cm3 is a little sh? (and also cm3.cmd) installroot/lib/target/libfoo.so installroot/pkg unchanged, already contains target ? If you don't imply host in installroot, there could be like one large "repository" (file system tree) that package building and install merely subsets according to what hosts/targets are desired. Maybe that's pointless. Or, it doesn't require this layout anyway. My config file roughly or the intent is, probe first the source tree, then the install tree. In the source tree there is already precedent for where things are: sourceroot/m3-sys/m3cc/host/cm3cg (native) sourceroot/m3-sys/m3cc/host-target/cm3cg sourceroot/m3-sys/cminstall/src/config-no-install/target sourceroot/m3-sys/cminstall/src/config/target I kind of favor slashes for separators. But I guess dashes or underscores are ok. Slashes offer - same overall length path - possible increased portability to systems with limited length filenames, e.g. MS-DOS I guess the reason to get some consensus is so that cm3 target can work. So the probing can move from my config file to cm3? You could maybe do -DTARGET=target. There might be a problem where -D is processed too late. We could move that earlier, at least partially. My source tree use could be implemented by me just replacing all the "installed" files with ones that include over to my source tree. - Jay From jay.krell at cornell.edu Sat May 9 21:23:53 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 9 May 2009 19:23:53 +0000 Subject: [M3devel] Release engineering In-Reply-To: <172161.40937.qm@web56807.mail.re3.yahoo.com> References: <172161.40937.qm@web56807.mail.re3.yahoo.com> Message-ID: > NOTE: I think the cm3 frontend is currently target independent, Correct. It knows about all the targets. word size, endian, alignment, jmpbuf size, whether or not there is a stack walker It does layout all the types/variables. Maybe not as high level as you'd expect. The NT386 backend is integrated into the front/middle end. So we have: NT386: run cm3 get a bunch of .obj files just one process goes all the way from out of date sources to .obj files It is quite fast. And the codegen is somewhat optimized even. everything else run cm3 and then for every out of date source file output an intermediate file run cm3cg read intermediate file write assembly run assembler read assembly write .o file Someday maybe we can port the integrated backend to more targets. - Jay From eiserlohpp at yahoo.com Sun May 10 02:13:57 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 9 May 2009 17:13:57 -0700 (PDT) Subject: [M3devel] release engineering etc Message-ID: <166673.26496.qm@web56806.mail.re3.yahoo.com> Yes, when building the src-all source tree on a Macintosh (OSX-10.5.x), I have to delete the entry for the Postgress database. > expat (an UTF8 before) makes me think we need to allow some flexibility > in development process - se we can allow some packages not being > available on all platforms - for some period of time while we find > somebody to tune it to platforms with initial issues. Somehow we must > track packages that need more work on specific platform (probably > already done throgh tinderbox) and use that information to keep loose > ends under control. > Some packages will then be tagged beta or something while work is in > progress. > -- > Dragi?a Duri? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sun May 10 23:32:25 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 10 May 2009 21:32:25 +0000 Subject: [M3devel] how to find dependent .so files? In-Reply-To: <200904280900.27606.vapier@gentoo.org> References: <200904280900.27606.vapier@gentoo.org> Message-ID: Any dissent on changing the symlinks to hardlinks? I plan to try this pretty soon. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: vapier at gentoo.org; m3devel at elegosoft.com > Subject: RE: [M3devel] how to find dependent .so files? > Date: Tue, 28 Apr 2009 13:15:06 +0000 > > > If you take one of my suggestions, then yes you can do that for .sos. > But $ORIGIN/../lib is one generic perhaps inefficient runpath for .sos and executables, and hypothetically also for non-public shipped executables (with my suggestion that they go to lib, if they don't already), that's why. > > > The next step is just to smush lib and bin together, as is done on NT386. > Probably people won't like that, keep files out of $PATH. > > > I don't believe $ORIGIN works asis. > if /cm3/lib/libfoo.so symlinks to /cm3/pkg/foo/target/libfoo.so > then $ORIGIN is /cm3/pkg/foo/target, not /cm3/lib. > I'd like to be wrong here but I don't think I am. > > > So reversing the symlinks or making them hardlinks is ok? > > > - Jay > > > ---------------------------------------- >> From: vapier at gentoo.org >> To: m3devel at elegosoft.com >> Date: Tue, 28 Apr 2009 09:00:26 -0400 >> CC: jay.krell at cornell.edu >> Subject: Re: [M3devel] how to find dependent .so files? >> >> On Tuesday 28 April 2009 04:03:13 Jay wrote: >>> Normally we have: >>> >>> /usr/local/cm3/bin/someexe >>> /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so >>> /usr/local/cm3/lib/libbar.so symlink to ../pkg/bar/target/libbar.so >>> >>> Linking from someexe to $ORIGIN/../lib works, ok. >>> But from libfoo to libbar requires $ORIGIN/../../../lib. >>> or $ORIGIN/../../bar/target. >> >> what's wrong with just $ORIGIN ? they're in the same directory already. >> -mike From jay.krell at cornell.edu Mon May 11 00:33:29 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 10 May 2009 22:33:29 +0000 Subject: [M3devel] I386_DARWIN GetPC, rep prefix? Message-ID: Tony, to get RTSignalC.c to compile on Darwin (not MacOSX) 8.0.1 (aka 10.4). jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ uname -a Darwin jdar1.local 8.0.1 Darwin Kernel Version 8.0.1: Fri Apr 29 12:18:40 PDT 2005; root:xnu-792.obj /RELEASE_I386 x86 i386 jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ Probably that's a not very interesting target, but I don't yet have "real" x86/AMD64/Apple/Darwin hardware (just PPC/ARM). I had to: =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/POSIX/RTSignalC.c,v retrieving revision 1.11 diff -r1.11 RTSignalC.c 71c71 < pc = Context->uc_mcontext->ss.eip; --- > pc = Context->uc_mcontext->sc.sc_eip; Did you test ss.eip? And presumably sc.sc_eip doesn't work for you? Unless they have #defines for compat (on such short names..)? Maybe this changed from 10.4 to 10.5? I just want to change over the Unix/*.i3 files. I can leave my change uncommited till I get a real MacOSX>=10.5 system. I also get problems even in native builds with "rep" prefixes using the "builtin" tools (as). I'll change cm3cg to 586, or 486, or 386, whatever it takes, to workaround that. Also not commit that. Or maybe build a newer "cctools". - Jay From hosking at cs.purdue.edu Mon May 11 01:26:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 May 2009 09:26:36 +1000 Subject: [M3devel] I386_DARWIN GetPC, rep prefix? In-Reply-To: References: Message-ID: <3EB1F53C-5837-4DB4-8F1E-5D7EDC27201F@cs.purdue.edu> Hmm. Not sure I did test that. I don't have any 10.4 systems around anymore. On 11 May 2009, at 08:33, Jay wrote: > Tony, to get RTSignalC.c to compile on Darwin (not MacOSX) 8.0.1 > (aka 10.4). > > > > jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ uname -a > Darwin jdar1.local 8.0.1 Darwin Kernel Version 8.0.1: Fri Apr 29 > 12:18:40 PDT 2005; root:xnu-792.obj > /RELEASE_I386 x86 i386 > jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ > > > Probably that's a not very interesting target, but I don't yet have > "real" x86/AMD64/Apple/Darwin hardware (just PPC/ARM). > > > I had to: > > > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/POSIX/RTSignalC.c,v > retrieving revision 1.11 > diff -r1.11 RTSignalC.c > 71c71 > < pc = Context->uc_mcontext->ss.eip; > --- >> pc = Context->uc_mcontext->sc.sc_eip; > > > Did you test ss.eip? > And presumably sc.sc_eip doesn't work for you? Unless they have > #defines for compat (on such short names..)? > Maybe this changed from 10.4 to 10.5? > I just want to change over the Unix/*.i3 files. > I can leave my change uncommited till I get a real MacOSX>=10.5 > system. > > > I also get problems even in native builds with "rep" prefixes using > the "builtin" tools (as). > I'll change cm3cg to 586, or 486, or 386, whatever it takes, to > workaround that. > Also not commit that. > Or maybe build a newer "cctools". > > > - Jay From jay.krell at cornell.edu Mon May 11 02:00:40 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 11 May 2009 00:00:40 +0000 Subject: [M3devel] I386_DARWIN GetPC, rep prefix? In-Reply-To: <3EB1F53C-5837-4DB4-8F1E-5D7EDC27201F@cs.purdue.edu> References: <3EB1F53C-5837-4DB4-8F1E-5D7EDC27201F@cs.purdue.edu> Message-ID: ok. What is the story on 10.5? Your version works? My version works? - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: I386_DARWIN GetPC, rep prefix? > Date: Mon, 11 May 2009 09:26:36 +1000 > > Hmm. Not sure I did test that. I don't have any 10.4 systems around > anymore. > > On 11 May 2009, at 08:33, Jay wrote: > >> Tony, to get RTSignalC.c to compile on Darwin (not MacOSX) 8.0.1 >> (aka 10.4). >> >> >> >> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ uname -a >> Darwin jdar1.local 8.0.1 Darwin Kernel Version 8.0.1: Fri Apr 29 >> 12:18:40 PDT 2005; root:xnu-792.obj >> /RELEASE_I386 x86 i386 >> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ >> >> >> Probably that's a not very interesting target, but I don't yet have >> "real" x86/AMD64/Apple/Darwin hardware (just PPC/ARM). >> >> >> I had to: >> >> >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/POSIX/RTSignalC.c,v >> retrieving revision 1.11 >> diff -r1.11 RTSignalC.c >> 71c71 >> < pc = Context->uc_mcontext->ss.eip; >> --- >>> pc = Context->uc_mcontext->sc.sc_eip; >> >> >> Did you test ss.eip? >> And presumably sc.sc_eip doesn't work for you? Unless they have >> #defines for compat (on such short names..)? >> Maybe this changed from 10.4 to 10.5? >> I just want to change over the Unix/*.i3 files. >> I can leave my change uncommited till I get a real MacOSX>=10.5 >> system. >> >> >> I also get problems even in native builds with "rep" prefixes using >> the "builtin" tools (as). >> I'll change cm3cg to 586, or 486, or 386, whatever it takes, to >> workaround that. >> Also not commit that. >> Or maybe build a newer "cctools". >> >> >> - Jay > From hosking at cs.purdue.edu Mon May 11 02:52:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 May 2009 10:52:59 +1000 Subject: [M3devel] I386_DARWIN GetPC, rep prefix? In-Reply-To: References: <3EB1F53C-5837-4DB4-8F1E-5D7EDC27201F@cs.purdue.edu> Message-ID: <67A25A63-2C3A-4926-8068-848436BC45AE@cs.purdue.edu> This works on 10.5: pc = Context->uc_mcontext->__ss.__eip; On 11 May 2009, at 10:00, Jay wrote: > > ok. What is the story on 10.5? > Your version works? My version works? > > - Jay > > ---------------------------------------- >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: I386_DARWIN GetPC, rep prefix? >> Date: Mon, 11 May 2009 09:26:36 +1000 >> >> Hmm. Not sure I did test that. I don't have any 10.4 systems around >> anymore. >> >> On 11 May 2009, at 08:33, Jay wrote: >> >>> Tony, to get RTSignalC.c to compile on Darwin (not MacOSX) 8.0.1 >>> (aka 10.4). >>> >>> >>> >>> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ uname -a >>> Darwin jdar1.local 8.0.1 Darwin Kernel Version 8.0.1: Fri Apr 29 >>> 12:18:40 PDT 2005; root:xnu-792.obj >>> /RELEASE_I386 x86 i386 >>> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ >>> >>> >>> Probably that's a not very interesting target, but I don't yet have >>> "real" x86/AMD64/Apple/Darwin hardware (just PPC/ARM). >>> >>> >>> I had to: >>> >>> >>> =================================================================== >>> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/POSIX/ >>> RTSignalC.c,v >>> retrieving revision 1.11 >>> diff -r1.11 RTSignalC.c >>> 71c71 >>> < pc = Context->uc_mcontext->ss.eip; >>> --- >>>> pc = Context->uc_mcontext->sc.sc_eip; >>> >>> >>> Did you test ss.eip? >>> And presumably sc.sc_eip doesn't work for you? Unless they have >>> #defines for compat (on such short names..)? >>> Maybe this changed from 10.4 to 10.5? >>> I just want to change over the Unix/*.i3 files. >>> I can leave my change uncommited till I get a real MacOSX>=10.5 >>> system. >>> >>> >>> I also get problems even in native builds with "rep" prefixes using >>> the "builtin" tools (as). >>> I'll change cm3cg to 586, or 486, or 386, whatever it takes, to >>> workaround that. >>> Also not commit that. >>> Or maybe build a newer "cctools". >>> >>> >>> - Jay >> From jay.krell at cornell.edu Mon May 11 03:51:20 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 11 May 2009 01:51:20 +0000 Subject: [M3devel] I386_DARWIN GetPC, rep prefix? In-Reply-To: <67A25A63-2C3A-4926-8068-848436BC45AE@cs.purdue.edu> References: <3EB1F53C-5837-4DB4-8F1E-5D7EDC27201F@cs.purdue.edu> <67A25A63-2C3A-4926-8068-848436BC45AE@cs.purdue.edu> Message-ID: And the #if is always true on 10.5, with a default command line? Or even no matter the command line? If so, therefore I'm free to do whatever in the #else? - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 11 May 2009 10:52:59 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] I386_DARWIN GetPC, rep prefix? > > This works on 10.5: > > pc = Context->uc_mcontext->__ss.__eip; > > On 11 May 2009, at 10:00, Jay wrote: > > > > > ok. What is the story on 10.5? > > Your version works? My version works? > > > > - Jay > > > > ---------------------------------------- > >> CC: m3devel at elegosoft.com > >> From: hosking at cs.purdue.edu > >> To: jay.krell at cornell.edu > >> Subject: Re: I386_DARWIN GetPC, rep prefix? > >> Date: Mon, 11 May 2009 09:26:36 +1000 > >> > >> Hmm. Not sure I did test that. I don't have any 10.4 systems around > >> anymore. > >> > >> On 11 May 2009, at 08:33, Jay wrote: > >> > >>> Tony, to get RTSignalC.c to compile on Darwin (not MacOSX) 8.0.1 > >>> (aka 10.4). > >>> > >>> > >>> > >>> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ uname -a > >>> Darwin jdar1.local 8.0.1 Darwin Kernel Version 8.0.1: Fri Apr 29 > >>> 12:18:40 PDT 2005; root:xnu-792.obj > >>> /RELEASE_I386 x86 i386 > >>> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ > >>> > >>> > >>> Probably that's a not very interesting target, but I don't yet have > >>> "real" x86/AMD64/Apple/Darwin hardware (just PPC/ARM). > >>> > >>> > >>> I had to: > >>> > >>> > >>> =================================================================== > >>> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/POSIX/ > >>> RTSignalC.c,v > >>> retrieving revision 1.11 > >>> diff -r1.11 RTSignalC.c > >>> 71c71 > >>> < pc = Context->uc_mcontext->ss.eip; > >>> --- > >>>> pc = Context->uc_mcontext->sc.sc_eip; > >>> > >>> > >>> Did you test ss.eip? > >>> And presumably sc.sc_eip doesn't work for you? Unless they have > >>> #defines for compat (on such short names..)? > >>> Maybe this changed from 10.4 to 10.5? > >>> I just want to change over the Unix/*.i3 files. > >>> I can leave my change uncommited till I get a real MacOSX>=10.5 > >>> system. > >>> > >>> > >>> I also get problems even in native builds with "rep" prefixes using > >>> the "builtin" tools (as). > >>> I'll change cm3cg to 586, or 486, or 386, whatever it takes, to > >>> workaround that. > >>> Also not commit that. > >>> Or maybe build a newer "cctools". > >>> > >>> > >>> - Jay > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon May 11 04:14:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 May 2009 12:14:56 +1000 Subject: [M3devel] I386_DARWIN GetPC, rep prefix? In-Reply-To: References: <3EB1F53C-5837-4DB4-8F1E-5D7EDC27201F@cs.purdue.edu> <67A25A63-2C3A-4926-8068-848436BC45AE@cs.purdue.edu> Message-ID: On 11 May 2009, at 11:51, Jay wrote: > And the #if is always true on 10.5, with a default command line? Yes, I believe so, but you should check what 10.4 does. Is there not a def you can use for your version of Darwin? > > Or even no matter the command line? > If so, therefore I'm free to do whatever in the #else? > > - Jay > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Mon, 11 May 2009 10:52:59 +1000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] I386_DARWIN GetPC, rep prefix? > > > > This works on 10.5: > > > > pc = Context->uc_mcontext->__ss.__eip; > > > > On 11 May 2009, at 10:00, Jay wrote: > > > > > > > > ok. What is the story on 10.5? > > > Your version works? My version works? > > > > > > - Jay > > > > > > ---------------------------------------- > > >> CC: m3devel at elegosoft.com > > >> From: hosking at cs.purdue.edu > > >> To: jay.krell at cornell.edu > > >> Subject: Re: I386_DARWIN GetPC, rep prefix? > > >> Date: Mon, 11 May 2009 09:26:36 +1000 > > >> > > >> Hmm. Not sure I did test that. I don't have any 10.4 systems > around > > >> anymore. > > >> > > >> On 11 May 2009, at 08:33, Jay wrote: > > >> > > >>> Tony, to get RTSignalC.c to compile on Darwin (not MacOSX) 8.0.1 > > >>> (aka 10.4). > > >>> > > >>> > > >>> > > >>> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ uname -a > > >>> Darwin jdar1.local 8.0.1 Darwin Kernel Version 8.0.1: Fri Apr 29 > > >>> 12:18:40 PDT 2005; root:xnu-792.obj > > >>> /RELEASE_I386 x86 i386 > > >>> jdar1:/dev2/cm3/m3-libs/m3core/src/runtime/POSIX jay$ > > >>> > > >>> > > >>> Probably that's a not very interesting target, but I don't yet > have > > >>> "real" x86/AMD64/Apple/Darwin hardware (just PPC/ARM). > > >>> > > >>> > > >>> I had to: > > >>> > > >>> > > >>> > =================================================================== > > >>> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/POSIX/ > > >>> RTSignalC.c,v > > >>> retrieving revision 1.11 > > >>> diff -r1.11 RTSignalC.c > > >>> 71c71 > > >>> < pc = Context->uc_mcontext->ss.eip; > > >>> --- > > >>>> pc = Context->uc_mcontext->sc.sc_eip; > > >>> > > >>> > > >>> Did you test ss.eip? > > >>> And presumably sc.sc_eip doesn't work for you? Unless they have > > >>> #defines for compat (on such short names..)? > > >>> Maybe this changed from 10.4 to 10.5? > > >>> I just want to change over the Unix/*.i3 files. > > >>> I can leave my change uncommited till I get a real MacOSX>=10.5 > > >>> system. > > >>> > > >>> > > >>> I also get problems even in native builds with "rep" prefixes > using > > >>> the "builtin" tools (as). > > >>> I'll change cm3cg to 586, or 486, or 386, whatever it takes, to > > >>> workaround that. > > >>> Also not commit that. > > >>> Or maybe build a newer "cctools". > > >>> > > >>> > > >>> - Jay > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue May 12 03:21:47 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 May 2009 11:21:47 +1000 Subject: [M3devel] Problems with setjmp/longjmp exception-handling and optimization Message-ID: <3C44BE4A-0836-431D-A044-4CB2CDA358BD@cs.purdue.edu> Just to summarise the status of optimization and setjmp/longjmp exception handling. Currently, optimizing breaks for setjmp/longjmp exceptions because register locals that are live across the setjmp call will revert to their value at the time of the setjmp instead of having the value at the time of the longjmp. The fix is to force the compiler front-end to allocate variables assigned inside TRY blocks to memory, so that those updates are not lost. This is only necessary for the setjmp/longjmp scheme. I am working on this right now. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue May 12 11:02:23 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 12 May 2009 09:02:23 +0000 Subject: [M3devel] how to find dependent .so files? In-Reply-To: <200904280900.27606.vapier@gentoo.org> References: <200904280900.27606.vapier@gentoo.org> Message-ID: This is in. I only tested on AMD64_LINUX. - Jay > From: jay.krell at cornell.edu > To: vapier at gentoo.org; m3devel at elegosoft.com > Subject: RE: [M3devel] how to find dependent .so files? > Date: Sun, 10 May 2009 21:32:25 +0000 > > > Any dissent on changing the symlinks to hardlinks? > I plan to try this pretty soon. > > - Jay > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: vapier at gentoo.org; m3devel at elegosoft.com > > Subject: RE: [M3devel] how to find dependent .so files? > > Date: Tue, 28 Apr 2009 13:15:06 +0000 > > > > > > If you take one of my suggestions, then yes you can do that for .sos. > > But $ORIGIN/../lib is one generic perhaps inefficient runpath for .sos and executables, and hypothetically also for non-public shipped executables (with my suggestion that they go to lib, if they don't already), that's why. > > > > > > The next step is just to smush lib and bin together, as is done on NT386. > > Probably people won't like that, keep files out of $PATH. > > > > > > I don't believe $ORIGIN works asis. > > if /cm3/lib/libfoo.so symlinks to /cm3/pkg/foo/target/libfoo.so > > then $ORIGIN is /cm3/pkg/foo/target, not /cm3/lib. > > I'd like to be wrong here but I don't think I am. > > > > > > So reversing the symlinks or making them hardlinks is ok? > > > > > > - Jay > > > > > > ---------------------------------------- > >> From: vapier at gentoo.org > >> To: m3devel at elegosoft.com > >> Date: Tue, 28 Apr 2009 09:00:26 -0400 > >> CC: jay.krell at cornell.edu > >> Subject: Re: [M3devel] how to find dependent .so files? > >> > >> On Tuesday 28 April 2009 04:03:13 Jay wrote: > >>> Normally we have: > >>> > >>> /usr/local/cm3/bin/someexe > >>> /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so > >>> /usr/local/cm3/lib/libbar.so symlink to ../pkg/bar/target/libbar.so > >>> > >>> Linking from someexe to $ORIGIN/../lib works, ok. > >>> But from libfoo to libbar requires $ORIGIN/../../../lib. > >>> or $ORIGIN/../../bar/target. > >> > >> what's wrong with just $ORIGIN ? they're in the same directory already. > >> -mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue May 12 12:32:42 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 12 May 2009 10:32:42 +0000 Subject: [M3devel] advise on handling iphone/ARM_DARWIN? (long version) Message-ID: so..I have an iphone. (Jail broken but also in use with AT&T as a real phone/computer.) No Intel Mac yet to do official development on. I built a C cross compiler on a PPC Mac. The various directions out there say it'll work on a variety of platforms but I had not great luck. I'm looking through Apple's "gcc-5490" for "Apple local". There are 11,000+ instances. Usually/always in begin/end pairs, so 5,500+. Skimming through some of them...lots of stuff to ignore..: some are to enable #pragmas in C/C++ front end some are Objective C specific some are for compatibility with CodeWarrior assembly blocks some are specific to PowerPC, AMD64, etc. lots are specific to ARM -- that is what is of interest some are in the testsuite some are for kernel code some are for "cfstrings" and "pascal strings" some is to adapt for use with their linker some I think is the "driver", which we don't use Ok, so let's just delete some directories (testsuite, doc, ada, cp, doc, libstdc++, libjava, libiberty (not very interesting generally), i386, rs6000, pa (yes, really, they have changes here), ia64 (yes, really), c-* (though really, reviewing the i386 and rs6000 directories, could be some important fixes?)) That gets it down to around 4,000. Anyone have any suggestions for what to do? I'm not even sure what the gcc base is for this stuff. I think it is 4.0.1, judging from the changelog. Maybe we should import their code into cvs and apply our patches? I know it'd really bloat up our tree, but I think it might be one of the better options. We could prune it down heavily as indicated, just striving for enough to target ARM_DARWIN, or maybe *_DARWIN, but still dropping the other front-ends for example. Note that this isn't even the toolset I built. That is something else. I think maybe llvm based. Btw, gcc has a "plugin" interface now. I don't know what all it can do. But I wonder..this might be an avenue that helps us, at least where cc=gcc (ie: where gcc is already available). On the other hand, I'm still very tempted by a C-generating backend, for greater portability.. - Jay From jay.krell at cornell.edu Tue May 12 12:35:26 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 12 May 2009 10:35:26 +0000 Subject: [M3devel] advise on handling iphone/ARM_DARWIN? (short version) Message-ID: I'm not sure what to do regarding targeting iphone/ARM_DARWIN. Would it be reasonablye and easy to, say, import Apple's "gcc-5490", maybe subset some, like rip out most of the libraries and front-ends, and apply our changes, and use this just for iphone/ARM_DARWIN? m3-sys/m3cc-iphone? m3-sys/m3cc-apple? Apple has thousands of changes, even if they mostly aren't relevant. We have hardly any at all, right? There is also an llvm based toolset for iphone. - Jay From wagner at elegosoft.com Tue May 12 18:15:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 May 2009 18:15:35 +0200 Subject: [M3devel] tinderbox error: ld: fatal: symbol `Unix__fcntl? is multiply-defined Message-ID: <20090512181535.z93nmrugsg8k0o8o@mail.elegosoft.com> error in SunOS build, see: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1242125700.7850 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed May 13 00:54:06 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 12 May 2009 22:54:06 +0000 Subject: [M3devel] tinderbox error: ld: fatal: symbol `Unix__fcntl? is multiply-defined In-Reply-To: <20090512181535.z93nmrugsg8k0o8o@mail.elegosoft.com> References: <20090512181535.z93nmrugsg8k0o8o@mail.elegosoft.com> Message-ID: should be ok now - Jay ---------------------------------------- > Date: Tue, 12 May 2009 18:15:35 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] tinderbox error: ld: fatal: symbol `Unix__fcntl? is multiply-defined > > error in SunOS build, see: > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1242125700.7850 > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hendrik at topoi.pooq.com Thu May 14 04:07:13 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 13 May 2009 22:07:13 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090414171133.GB3460@topoi.pooq.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> Message-ID: <20090514020713.GA13442@topoi.pooq.com> On Tue, Apr 14, 2009 at 01:11:33PM -0400, hendrik at topoi.pooq.com wrote: > On Sat, Apr 11, 2009 at 11:26:11AM +0200, Olaf Wagner wrote: > > > > I'd rather avoid creating a branch too early, as that means more work > > by selecting and merging fixes from trunk to branch. So here my questions: > > > > o Do we all agree on a temporary code freeze? > > o When should we start? I.e. wha changes would you like to complete > > before we start the release process? > > One thing that's essential is to debug the documentation -- > specifically, the installation instructions, the various README files, > and so forth. A naive user. competent in the ways of computers, but not > yet in the ways of Modula 3, should be able to follow the instructions > and succeed. In a previous post, I emphasized that it was important for the installation instructions to be usable by a prospective user of Modula 3. If he has trouble installing it, he'll never get around to discovering its practical advantages over C. So I decided to play the part of a naive user, and thereby to make it clear what, if any, obstacles he would encounter. Here are my results. When these problems are cleared up, I have real naive user in mind whom I'll ask to install Modula 3 on his system, keeping a log of difficulties. I hope you'll take this in the spirit it was intended, as a form of constructive criticism, as a bug report, not as a rant. I started pretending I had just heard about Modula 3 and decided to try it. So I did the obvious and looked for Modula 3 on googlee. I found www.modula3.org. It had a link to the download page (second or third message in main panel) Because of advice there to get the latest patch level, tried to download current development snapshot CM3 d5.5.0 -- no such thing, link broken. Went to look for current stable release. Went to installation instructions Went to more specific instructions for Ubuntu or Debian (I am running Debian squeeze). Noticed that the instructions mentioned Ubuntu everywhere, but rarely Debian. established my ownership of /usr/local install flex and libncurses5-dev install libpq-dev, freeglut3-dev,unixodbc-dev, libmotif-dev, libx11-dev installed stow to manage symbolic links stow was kind of complicated, so I used the ln -s as in the instructions to link libXmu.so and libXaw.so. Now download. The link to opencm3.net didn't point to a page containing obvious downloads of tar archives. But its installation link pointed to a page with a download link, which led to a pane that contained downloadable looking links far down the page The link cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz led nowhere. But cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz seems OK It seems my browser chooses which directory to download to; mine chose ~/Desktop without telling me, which occasioned a bit of a search. Go back to the instruction page, where I discover that "most earlier minimal binaries do not work, so stick with d5.5.1 or later. These are known to succeed: then a few .tgz file names, which are *not* links." So time to discard what I've just downloaded. But where am I to find the one that works? At this point the naive user would start to get annoyed. But there were several other links immediately above this warning. Maybe it's time to try them. Why was I first directed to www.opencm3.net then, and not to one of the other directories more directly? try http://www.opencm3.net/download.html It looks like I've been here before. Under current development snapshots there's a d5.5.0 link, but that's too old. follow the uploaded archive page: find a cm3-min-LINUXLIBC6-d5.7.1.tar.gz That's a lot more recent, and it leads to an actual fila! remove the obsolete one, to avoid confusion later. But there's no checksum for the new one on the checksums page, http://www.opencm3.net/checksums.php3. I guess I'll just assume I downloaded it correctly. The untar command from the installation instructions created a directory cm3-min-LINUXLIBC6-d5.7.1 within ~/cm3-min. This means that the next command, ./cminstall will not work. Nor is there a cm3install inside ~/cm3-min/cm3-min-LINUXLIBC6-d5.7.1 or anywhere else in sight. The would-be user is now thoroughly stymied. If he were to persist, he might do so by posting a message like this in the comp.lang.modula3 newsgroup. Does anyone still read that? -- hendrik From wagner at elegosoft.com Thu May 14 08:44:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 14 May 2009 08:44:56 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090514020713.GA13442@topoi.pooq.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> Message-ID: <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Tue, Apr 14, 2009 at 01:11:33PM -0400, hendrik at topoi.pooq.com wrote: >> On Sat, Apr 11, 2009 at 11:26:11AM +0200, Olaf Wagner wrote: >> > >> > I'd rather avoid creating a branch too early, as that means more work >> > by selecting and merging fixes from trunk to branch. So here my questions: >> > >> > o Do we all agree on a temporary code freeze? >> > o When should we start? I.e. wha changes would you like to complete >> > before we start the release process? >> >> One thing that's essential is to debug the documentation -- >> specifically, the installation instructions, the various README files, >> and so forth. A naive user. competent in the ways of computers, but not >> yet in the ways of Modula 3, should be able to follow the instructions >> and succeed. Thank you for this description of your experience. I'll try to address at least some of the issues during the next days; not sure how far I'll get. Some of the problems are still caused by the server crash, where many old archives were simply lost and haven't been reconstructed until now. Others are caused by two types of installation archives (legacy format and Jay's new format), which are both found there. Others are simply caused by out-of-date documentation, which nobody cares for much :-/ I think it will be best to provide a complete new set of archives, but this may still take some time, and then update the documentation appropriately. Progress is much slower than I hoped for (completely my fault). Olaf > In a previous post, I emphasized that it was important for the > installation instructions to be usable by a prospective user of Modula > 3. If he has trouble installing it, he'll never get around to > discovering its practical advantages over C. So I decided to play the > part of a naive user, and thereby to make it clear what, if any, > obstacles he would encounter. Here are my results. When these problems > are cleared up, I have real naive user in mind whom I'll ask to install > Modula 3 on his system, keeping a log of difficulties. > > I hope you'll take this in the spirit it was intended, as a form of > constructive criticism, as a bug report, not as a rant. > > > > I started pretending I had just heard about Modula 3 and decided to try > it. So I did the obvious and looked for Modula 3 on googlee. I found > www.modula3.org. > > It had a link to the download page (second or third message in main > panel) > > Because of advice there to get the latest patch level, tried to download > current development snapshot CM3 d5.5.0 -- no such thing, link broken. > > Went to look for current stable release. > Went to installation instructions > Went to more specific instructions for Ubuntu or Debian (I am running > Debian squeeze). Noticed that the instructions mentioned Ubuntu > everywhere, but rarely Debian. > > established my ownership of /usr/local > > install flex and libncurses5-dev > install libpq-dev, freeglut3-dev,unixodbc-dev, libmotif-dev, libx11-dev > > installed stow to manage symbolic links > > stow was kind of complicated, so I used the ln -s as in the instructions > to link libXmu.so and libXaw.so. > > Now download. > > The link to opencm3.net didn't point to a page containing obvious > downloads of tar archives. > But its installation link pointed to a page with a download link, which > led to a pane that contained downloadable looking links far down the > page > > The link cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz led nowhere. > > But cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz seems OK > > It seems my browser chooses which directory to download to; mine chose > ~/Desktop without telling me, which occasioned a bit of a search. > > Go back to the instruction page, where I discover that "most earlier > minimal binaries do not work, so stick with d5.5.1 or later. These are > known to succeed: > then a few .tgz file names, which are *not* links." So time to discard > what I've just downloaded. But where am I to find the one that works? > > At this point the naive user would start to get annoyed. > But there were several other links immediately above this warning. > Maybe it's time to try them. Why was I first directed to > www.opencm3.net then, and not to one of the other directories more > directly? > > try http://www.opencm3.net/download.html > It looks like I've been here before. > Under current development snapshots there's a d5.5.0 link, but that's > too old. > > follow the uploaded archive page: > find a cm3-min-LINUXLIBC6-d5.7.1.tar.gz > That's a lot more recent, and it leads to an actual fila! > remove the obsolete one, to avoid confusion later. > > But there's no checksum for the new one on the checksums page, > http://www.opencm3.net/checksums.php3. I guess I'll just assume I > downloaded it correctly. > > The untar command from the installation instructions created a directory > cm3-min-LINUXLIBC6-d5.7.1 within ~/cm3-min. This means that the next > command, ./cminstall will not work. > > Nor is there a cm3install inside ~/cm3-min/cm3-min-LINUXLIBC6-d5.7.1 or > anywhere else in sight. > > The would-be user is now thoroughly stymied. > > If he were to persist, he might do so by posting a message like this in > the comp.lang.modula3 newsgroup. Does anyone still read that? > > -- hendrik > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Thu May 14 17:51:30 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 May 2009 11:51:30 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> Message-ID: <20090514155129.GA15181@topoi.pooq.com> On Thu, May 14, 2009 at 08:44:56AM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Tue, Apr 14, 2009 at 01:11:33PM -0400, hendrik at topoi.pooq.com wrote: > >>On Sat, Apr 11, 2009 at 11:26:11AM +0200, Olaf Wagner wrote: > >>> > >>> I'd rather avoid creating a branch too early, as that means more work > >>> by selecting and merging fixes from trunk to branch. So here my > >>questions: > >>> > >>> o Do we all agree on a temporary code freeze? > >>> o When should we start? I.e. wha changes would you like to complete > >>> before we start the release process? > >> > >>One thing that's essential is to debug the documentation -- > >>specifically, the installation instructions, the various README files, > >>and so forth. A naive user. competent in the ways of computers, but not > >>yet in the ways of Modula 3, should be able to follow the instructions > >>and succeed. > > Thank you for this description of your experience. You're welcome. > I'll try to address > at least some of the issues during the next days; not sure how far I'll > get. Take your time; get it right! > > Some of the problems are still caused by the server crash, where many > old archives were simply lost and haven't been reconstructed until now. Of course. > Others are caused by two types of installation archives (legacy format > and Jay's new format), which are both found there. Others are simply > caused by out-of-date documentation, which nobody cares for much :-/ > > I think it will be best to provide a complete new set of archives, but > this may still take some time, and then update the documentation > appropriately. Progress is much slower than I hoped for (completely > my fault). It will take time. But getting this right is an essential part of preparing a new release. When you think you've fixed this round of problems, IO have a friend who does not know Modula 3. I'll try and get him to install it on his machine and report on the problems. He's pretty good at finding problems, but I don't know when he'll have time. If I have the time, I'll try a first Windows XP install on Modula 3. Let me know when it would best help you get the release ready. Windows being Windows, I doubt I could do a second first install. -- hendrik From martinbishop at bellsouth.net Thu May 14 20:25:02 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 14 May 2009 13:25:02 -0500 Subject: [M3devel] Man or Boy test Message-ID: <4A0C61FE.9080107@bellsouth.net> I tried implementing Knuth's Man or Boy test in Modula-3, but I can't get it to work. I assumed the code I had wouldn't work (and I was right), but eventually I fiddled enough and got it to compile, but now it just segfaults when run. MODULE ManOrBoy EXPORTS Main; IMPORT IO, Fmt; PROCEDURE Zero(): INTEGER = BEGIN RETURN 0; END Zero; PROCEDURE One(): INTEGER = BEGIN RETURN 1; END One; PROCEDURE Neg(): INTEGER = BEGIN RETURN -1; END Neg; PROCEDURE A(k:INTEGER; x1, x2, x3, x4, x5: INTEGER): INTEGER = PROCEDURE B(): INTEGER = BEGIN DEC(k); RETURN A(k, B(), x1, x2, x3, x4); END B; BEGIN IF k <= 0 THEN RETURN x4 + x5; ELSE RETURN B(); END; END A; BEGIN IO.Put(Fmt.Int(A(10, One(), Neg(), Neg(), One(), Zero())) & "\n"); END ManOrBoy. All I know is that it segfaults at procedure B. From martinbishop at bellsouth.net Thu May 14 20:31:08 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 14 May 2009 13:31:08 -0500 Subject: [M3devel] Man or Boy test In-Reply-To: <4A0C61FE.9080107@bellsouth.net> References: <4A0C61FE.9080107@bellsouth.net> Message-ID: <4A0C636C.6000803@bellsouth.net> Sorry if I wasn't clean, but what I am asking is for why specifically it segfaults, I'm sure it's something to do with the recursive nature of the problem, just not sure how Modula-3 handles it. Martin Bishop wrote: > I tried implementing Knuth's Man or Boy test in Modula-3, but I can't > get it to work. > > I assumed the code I had wouldn't work (and I was right), but > eventually I fiddled enough and got it to compile, but now it just > segfaults when run. > > MODULE ManOrBoy EXPORTS Main; > > IMPORT IO, Fmt; > > PROCEDURE Zero(): INTEGER = BEGIN RETURN 0; END Zero; > PROCEDURE One(): INTEGER = BEGIN RETURN 1; END One; > PROCEDURE Neg(): INTEGER = BEGIN RETURN -1; END Neg; > > PROCEDURE A(k:INTEGER; x1, x2, x3, x4, x5: INTEGER): INTEGER = > > PROCEDURE B(): INTEGER = > BEGIN > DEC(k); > RETURN A(k, B(), x1, x2, x3, x4); > END B; > > BEGIN > IF k <= 0 THEN > RETURN x4 + x5; > ELSE > RETURN B(); > END; > END A; > > BEGIN > IO.Put(Fmt.Int(A(10, One(), Neg(), Neg(), One(), Zero())) & "\n"); > END ManOrBoy. > > All I know is that it segfaults at procedure B. > From rcoleburn at scires.com Thu May 14 21:23:01 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 14 May 2009 15:23:01 -0400 Subject: [M3devel] Man or Boy test In-Reply-To: <4A0C61FE.9080107@bellsouth.net> References: <4A0C61FE.9080107@bellsouth.net> Message-ID: <4A0C3751.1E75.00D7.1@scires.com> Martin: I've only scanned your code briefly here, but I would suspect that you are running out of stack space due to infinite recursion. I may be wrong here, but I think you have an infinite loop. Reason is that in B() you call A() again, but in the call to A() you also recursively call B() as one of the parameters to A(). Since all the parameters have to be evaluated before you can call A(), you wind up calling B() recursively with no termination condition since the test for k<=0 only occurs in A(), not B(). Regards, Randy Coleburn >>> Martin Bishop 5/14/2009 2:25 PM >>> I tried implementing Knuth's Man or Boy test in Modula-3, but I can't get it to work. I assumed the code I had wouldn't work (and I was right), but eventually I fiddled enough and got it to compile, but now it just segfaults when run. MODULE ManOrBoy EXPORTS Main; IMPORT IO, Fmt; PROCEDURE Zero(): INTEGER = BEGIN RETURN 0; END Zero; PROCEDURE One(): INTEGER = BEGIN RETURN 1; END One; PROCEDURE Neg(): INTEGER = BEGIN RETURN -1; END Neg; PROCEDURE A(k:INTEGER; x1, x2, x3, x4, x5: INTEGER): INTEGER = PROCEDURE B(): INTEGER = BEGIN DEC(k); RETURN A(k, B(), x1, x2, x3, x4); END B; BEGIN IF k <= 0 THEN RETURN x4 + x5; ELSE RETURN B(); END; END A; BEGIN IO.Put(Fmt.Int(A(10, One(), Neg(), Neg(), One(), Zero())) & "\n"); END ManOrBoy. All I know is that it segfaults at procedure B. CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu May 14 22:13:42 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 May 2009 16:13:42 -0400 Subject: [M3devel] Man or Boy test In-Reply-To: <4A0C61FE.9080107@bellsouth.net> References: <4A0C61FE.9080107@bellsouth.net> Message-ID: <20090514201341.GA15546@topoi.pooq.com> On Thu, May 14, 2009 at 01:25:02PM -0500, Martin Bishop wrote: > I tried implementing Knuth's Man or Boy test in Modula-3, but I can't > get it to work. > > I assumed the code I had wouldn't work (and I was right), but eventually > I fiddled enough and got it to compile, but now it just segfaults when run. > > MODULE ManOrBoy EXPORTS Main; > > IMPORT IO, Fmt; > > PROCEDURE Zero(): INTEGER = BEGIN RETURN 0; END Zero; > PROCEDURE One(): INTEGER = BEGIN RETURN 1; END One; > PROCEDURE Neg(): INTEGER = BEGIN RETURN -1; END Neg; > > PROCEDURE A(k:INTEGER; x1, x2, x3, x4, x5: INTEGER): INTEGER = > > PROCEDURE B(): INTEGER = > BEGIN > DEC(k); > RETURN A(k, B(), x1, x2, x3, x4); > END B; > > BEGIN > IF k <= 0 THEN > RETURN x4 + x5; > ELSE > RETURN B(); > END; > END A; > > BEGIN > IO.Put(Fmt.Int(A(10, One(), Neg(), Neg(), One(), Zero())) & "\n"); > END ManOrBoy. > > All I know is that it segfaults at procedure B. Probably because it contains an infinite recursion. I may remember wrongly, but I believe that in the original man-or-boy program, all parameters were passed by name, not by value. This means that the call to B() inside the call to A(...B()...) would be performed only if A itself used that parameter, and then as many times as A actually used it (dynamically). This the IF in A will break the recursion in B. The same does not happen with call-by-value. -- hendrik From jay.krell at cornell.edu Fri May 15 05:00:57 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 14 May 2009 20:00:57 -0700 Subject: [M3devel] optimizer In-Reply-To: <20090514044731.48A37CC3C1@birch.elegosoft.com> References: <20090514044731.48A37CC3C1@birch.elegosoft.com> Message-ID: <20499A8B-E85C-49C9-8840-F716A23E8BE2@hotmail.com> In the absence of anything else yet, sorry, how about twiddle the config files and watch the tinderbox? On a larger project that might be bad form. - Jay (phone) > Changes by: hosking@ > Feedback on experiences optimizing on other platforms would be > appreciated. From hosking at cs.purdue.edu Fri May 15 06:24:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 May 2009 14:24:03 +1000 Subject: [M3devel] optimizer In-Reply-To: <20499A8B-E85C-49C9-8840-F716A23E8BE2@hotmail.com> References: <20090514044731.48A37CC3C1@birch.elegosoft.com> <20499A8B-E85C-49C9-8840-F716A23E8BE2@hotmail.com> Message-ID: Sure, I just didn't want to get yelled at if tinderbox broke. On 15 May 2009, at 13:00, jay.krell at cornell.edu wrote: > In the absence of anything else yet, sorry, how about twiddle the > config files and watch the tinderbox? On a larger project that might > be bad form. > > - Jay (phone) > >> Changes by: hosking@ >> Feedback on experiences optimizing on other platforms would be >> appreciated. From wagner at elegosoft.com Fri May 15 08:42:30 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 15 May 2009 08:42:30 +0200 Subject: [M3devel] optimizer In-Reply-To: References: <20090514044731.48A37CC3C1@birch.elegosoft.com> <20499A8B-E85C-49C9-8840-F716A23E8BE2@hotmail.com> Message-ID: <20090515084230.mrha81n7k4gw8wgg@mail.elegosoft.com> Quoting Tony Hosking : > Sure, I just didn't want to get yelled at if tinderbox broke. Breakage is normal during software development. I hope nobody really minds any reminders here if we notice a problem; it's never meant to be personal. > On 15 May 2009, at 13:00, jay.krell at cornell.edu wrote: > >> In the absence of anything else yet, sorry, how about twiddle the >> config files and watch the tinderbox? On a larger project that >> might be bad form. >> >> - Jay (phone) >> >>> Changes by: hosking@ >>> Feedback on experiences optimizing on other platforms would be >>> appreciated. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri May 15 08:46:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 May 2009 16:46:25 +1000 Subject: [M3devel] optimizer In-Reply-To: <20090515084230.mrha81n7k4gw8wgg@mail.elegosoft.com> References: <20090514044731.48A37CC3C1@birch.elegosoft.com> <20499A8B-E85C-49C9-8840-F716A23E8BE2@hotmail.com> <20090515084230.mrha81n7k4gw8wgg@mail.elegosoft.com> Message-ID: <04498D7F-F5C0-4656-B4DB-4BED9A003282@cs.purdue.edu> I was being facetious. I'm generally not shy about being yelled at. ;-) On 15 May 2009, at 16:42, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Sure, I just didn't want to get yelled at if tinderbox broke. > > Breakage is normal during software development. I hope nobody really > minds any reminders here if we notice a problem; it's never meant to > be personal. > >> On 15 May 2009, at 13:00, jay.krell at cornell.edu wrote: >> >>> In the absence of anything else yet, sorry, how about twiddle the >>> config files and watch the tinderbox? On a larger project that >>> might be bad form. >>> >>> - Jay (phone) >>> >>>> Changes by: hosking@ >>>> Feedback on experiences optimizing on other platforms would be >>>> appreciated. > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From eiserlohpp at yahoo.com Fri May 15 23:00:58 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 15 May 2009 14:00:58 -0700 (PDT) Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides Message-ID: <362049.22100.qm@web56801.mail.re3.yahoo.com> Hi Guys, I downloaded a new archive: cm3-src-all-d5.8.0-2009-05-15-06-57-11.tgz, as I wanted to look at Olaf's changes. I attempted to "./scripts/do-cm3-std.sh build", and while it did build m3core, it failed to build libm3. Its 'm3overrides' file attempts to append ( using += ) to a variable (M3_FRONT_FLAGS), but since the variable doesn't exist it fails. Should an obliq script fail like that, if you attempt to append to a non-existing variable, or should it silently create that variable? Log follows: *** excerpt from Build.log *** new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 -> archiving libm3core.a ==> m3-libs/m3core done === package m3-libs/libm3 === +++ /usr/local/cm3/bin/cm3 -build -override -DROOT='/data/peter3/src/modula-3/cm3/src-all-20090515' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-05-06' +++ --- building in AMD64_LINUX --- "/data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides", line 7: quake runtime error: undefined variable: M3_FRONT_FLAGS --procedure-- -line- -file--- 7 /data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides Fatal Error: package build failed ==> m3-libs/libm3 done *** END excerpt Build.log *** *** m3overrides *** %%XXDIR = { "WIN32" : "N:\\m3-libs", "POSIX" : "/proj/cmass/src.2/m3-libs" } %%WORKDIR = XXDIR {OS_TYPE} % override ("m3core", WORKDIR) override("m3core", ROOT & "/m3-libs") M3_FRONT_FLAGS += "-vsdebug" _M3BUNDLE_OVERRIDE = "T" ** END m3overrides *** +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat May 16 00:25:25 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 15 May 2009 22:25:25 +0000 Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: <362049.22100.qm@web56801.mail.re3.yahoo.com> References: <362049.22100.qm@web56801.mail.re3.yahoo.com> Message-ID: I "fixed" this I guess, but as it was working for me, maybe your config files are not right? It is "quake" by the way, which I assume means "quick make" but I don't know. obliq is something else, like for scripting network objects? The file now reads: override("m3core", ROOT & "/m3-libs") if defined("M3_FRONT_FLAGS") M3_FRONT_FLAGS += "-vsdebug" else M3_FRONT_FLAGS = ["-vsdebug"] end _M3BUNDLE_OVERRIDE = "T" - Jay ---------------------------------------- > Date: Fri, 15 May 2009 14:00:58 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides > > > Hi Guys, > > I downloaded a new archive: cm3-src-all-d5.8.0-2009-05-15-06-57-11.tgz, > as I wanted to look at Olaf's changes. > > I attempted to "./scripts/do-cm3-std.sh build", and while > it did build m3core, it failed to build libm3. > > Its 'm3overrides' file attempts to append ( using += ) to a > variable (M3_FRONT_FLAGS), but since the variable doesn't > exist it fails. Should an obliq script fail like that, if > you attempt to append to a non-existing variable, or should > it silently create that variable? > > Log follows: > > *** excerpt from Build.log *** > new exporters -> recompiling Date.i3 > new exporters -> recompiling Text.i3 > -> archiving libm3core.a > ==> m3-libs/m3core done > > === package m3-libs/libm3 === > +++ /usr/local/cm3/bin/cm3 -build -override -DROOT='/data/peter3/src/modula-3/cm3/src-all-20090515' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-05-06' +++ > --- building in AMD64_LINUX --- > > "/data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides", line 7: quake runtime error: undefined variable: M3_FRONT_FLAGS > > --procedure-- -line- -file--- > 7 /data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides > > Fatal Error: package build failed > ==> m3-libs/libm3 done > *** END excerpt Build.log *** > > > *** m3overrides *** > > > %%XXDIR = { "WIN32" : "N:\\m3-libs", "POSIX" : "/proj/cmass/src.2/m3-libs" } > %%WORKDIR = XXDIR {OS_TYPE} > > % override ("m3core", WORKDIR) > override("m3core", ROOT & "/m3-libs") > M3_FRONT_FLAGS += "-vsdebug" > _M3BUNDLE_OVERRIDE = "T" > ** END m3overrides *** > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > From jay.krell at cornell.edu Sat May 16 00:27:08 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 15 May 2009 22:27:08 +0000 Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: <362049.22100.qm@web56801.mail.re3.yahoo.com> References: <362049.22100.qm@web56801.mail.re3.yahoo.com> Message-ID: specifically: C:\dev2\cm3.2\m3-sys\cminstall\src\config-no-install\cm3cfg.common if equal(M3_BACKEND_MODE, "0") or equal(M3_BACKEND_MODE, "1") or equal(M3_BACKEND_MODE, "IntegratedObject") or equal(M3_BACKEND_MODE, "IntegratedAssembly") M3_FRONT_FLAGS = ["-unfold_nested_procs", "-check_procs"] % --- internal configuration options passed directly to the Modula-3 front-end else M3_FRONT_FLAGS = [ ] end - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: eiserlohpp at yahoo.com; m3devel at elegosoft.com > Subject: RE: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides > Date: Fri, 15 May 2009 22:25:25 +0000 > > > I "fixed" this I guess, but as it was working for me, maybe your config files are not right? > It is "quake" by the way, which I assume means "quick make" but I don't know. > obliq is something else, like for scripting network objects? > > The file now reads: > > override("m3core", ROOT & "/m3-libs") > if defined("M3_FRONT_FLAGS") > M3_FRONT_FLAGS += "-vsdebug" > else > M3_FRONT_FLAGS = ["-vsdebug"] > end > _M3BUNDLE_OVERRIDE = "T" > > > - Jay > > ---------------------------------------- >> Date: Fri, 15 May 2009 14:00:58 -0700 >> From: eiserlohpp at yahoo.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides >> >> >> Hi Guys, >> >> I downloaded a new archive: cm3-src-all-d5.8.0-2009-05-15-06-57-11.tgz, >> as I wanted to look at Olaf's changes. >> >> I attempted to "./scripts/do-cm3-std.sh build", and while >> it did build m3core, it failed to build libm3. >> >> Its 'm3overrides' file attempts to append ( using += ) to a >> variable (M3_FRONT_FLAGS), but since the variable doesn't >> exist it fails. Should an obliq script fail like that, if >> you attempt to append to a non-existing variable, or should >> it silently create that variable? >> >> Log follows: >> >> *** excerpt from Build.log *** >> new exporters -> recompiling Date.i3 >> new exporters -> recompiling Text.i3 >> -> archiving libm3core.a >> ==> m3-libs/m3core done >> >> === package m3-libs/libm3 === >> +++ /usr/local/cm3/bin/cm3 -build -override -DROOT='/data/peter3/src/modula-3/cm3/src-all-20090515' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-05-06' +++ >> --- building in AMD64_LINUX --- >> >> "/data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides", line 7: quake runtime error: undefined variable: M3_FRONT_FLAGS >> >> --procedure-- -line- -file--- >> 7 /data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides >> >> Fatal Error: package build failed >> ==> m3-libs/libm3 done >> *** END excerpt Build.log *** >> >> >> *** m3overrides *** >> >> >> %%XXDIR = { "WIN32" : "N:\\m3-libs", "POSIX" : "/proj/cmass/src.2/m3-libs" } >> %%WORKDIR = XXDIR {OS_TYPE} >> >> % override ("m3core", WORKDIR) >> override("m3core", ROOT & "/m3-libs") >> M3_FRONT_FLAGS += "-vsdebug" >> _M3BUNDLE_OVERRIDE = "T" >> ** END m3overrides *** >> >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> From jay.krell at cornell.edu Sat May 16 00:28:30 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 15 May 2009 22:28:30 +0000 Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: References: <362049.22100.qm@web56801.mail.re3.yahoo.com> Message-ID: ok, I put it back to "broken" per the other mail.. ---------------------------------------- > From: jay.krell at cornell.edu > To: eiserlohpp at yahoo.com; m3devel at elegosoft.com > Date: Fri, 15 May 2009 22:25:25 +0000 > Subject: Re: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides > > > I "fixed" this I guess, but as it was working for me, maybe your config files are not right? > It is "quake" by the way, which I assume means "quick make" but I don't know. > obliq is something else, like for scripting network objects? > > The file now reads: > > override("m3core", ROOT & "/m3-libs") > if defined("M3_FRONT_FLAGS") > M3_FRONT_FLAGS += "-vsdebug" > else > M3_FRONT_FLAGS = ["-vsdebug"] > end > _M3BUNDLE_OVERRIDE = "T" > > > - Jay > > ---------------------------------------- >> Date: Fri, 15 May 2009 14:00:58 -0700 >> From: eiserlohpp at yahoo.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides >> >> >> Hi Guys, >> >> I downloaded a new archive: cm3-src-all-d5.8.0-2009-05-15-06-57-11.tgz, >> as I wanted to look at Olaf's changes. >> >> I attempted to "./scripts/do-cm3-std.sh build", and while >> it did build m3core, it failed to build libm3. >> >> Its 'm3overrides' file attempts to append ( using += ) to a >> variable (M3_FRONT_FLAGS), but since the variable doesn't >> exist it fails. Should an obliq script fail like that, if >> you attempt to append to a non-existing variable, or should >> it silently create that variable? >> >> Log follows: >> >> *** excerpt from Build.log *** >> new exporters -> recompiling Date.i3 >> new exporters -> recompiling Text.i3 >> -> archiving libm3core.a >> ==> m3-libs/m3core done >> >> === package m3-libs/libm3 === >> +++ /usr/local/cm3/bin/cm3 -build -override -DROOT='/data/peter3/src/modula-3/cm3/src-all-20090515' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-05-06' +++ >> --- building in AMD64_LINUX --- >> >> "/data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides", line 7: quake runtime error: undefined variable: M3_FRONT_FLAGS >> >> --procedure-- -line- -file--- >> 7 /data/peter3/src/modula-3/cm3/src-all-20090515/m3-libs/libm3/AMD64_LINUX/../src/m3overrides >> >> Fatal Error: package build failed >> ==> m3-libs/libm3 done >> *** END excerpt Build.log *** >> >> >> *** m3overrides *** >> >> >> %%XXDIR = { "WIN32" : "N:\\m3-libs", "POSIX" : "/proj/cmass/src.2/m3-libs" } >> %%WORKDIR = XXDIR {OS_TYPE} >> >> % override ("m3core", WORKDIR) >> override("m3core", ROOT & "/m3-libs") >> M3_FRONT_FLAGS += "-vsdebug" >> _M3BUNDLE_OVERRIDE = "T" >> ** END m3overrides *** >> >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> From eiserlohpp at yahoo.com Sat May 16 20:55:03 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 16 May 2009 11:55:03 -0700 (PDT) Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides Message-ID: <765542.63695.qm@web56805.mail.re3.yahoo.com> Jay, Thank you Jay for looking into this. Oops, you are right s/obliq/quake/. BTW: It builds all the way even in the same source tree when I do an "./scripts/upgrade.sh", I did a "realclean" first. I guess this (upgrade.sh) is what most people are using these days to build the compiler, rather than the old "do-cm3-foo" scripts. Okay, I downloaded cm3-src-all-d5.8.0-2009-05-16-12-07-46.tgz, and did an upgrade.sh, then after a "do-cm3-std.sh realclean", I re-tryed the "do-cm3.std.sh build", and it failed again with the same error. This is with cm3 (5.8.0) built with this mornings source tree. I inserted your change into libm3/src/m3override, and it is currently building. > The file now reads: > > override("m3core", ROOT & "/m3-libs") > if defined("M3_FRONT_FLAGS") > M3_FRONT_FLAGS += "-vsdebug" > else > M3_FRONT_FLAGS = ["-vsdebug"] > end > _M3BUNDLE_OVERRIDE = "T" This is worked for me. I suggest you check it into the repository. Peter > From: jay.krell at cornell.edu > To: eiserlohpp at yahoo.com; m3devel at elegosoft.com > Subject: RE: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides > Date: Sat May 16 00:27:08 CEST 2009 > >specifically: > > >C:\dev2\cm3.2\m3-sys\cminstall\src\config-no-install\cm3cfg.common > > > >if equal(M3_BACKEND_MODE, "0") or equal(M3_BACKEND_MODE, "1") > or equal(M3_BACKEND_MODE, "IntegratedObject") or equal(M3_BACKEND_MODE, "IntegratedAssembly") > M3_FRONT_FLAGS = ["-unfold_nested_procs", "-check_procs"] >% --- internal configuration options passed directly to the Modula-3 front-end >else > M3_FRONT_FLAGS = [ ] >end > > > - Jay > +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat May 16 23:52:07 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 16 May 2009 21:52:07 +0000 Subject: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: <765542.63695.qm@web56805.mail.re3.yahoo.com> References: <765542.63695.qm@web56805.mail.re3.yahoo.com> Message-ID: Peter can you can roughly backup your config file send me/us your config file (attachment to m3devel ok) cp src/cm3/m3-sys/cminstall/src/config-no-install/* /usr/local/cm3/bin ? cm3.cfg might be in the neighboring config directory. I'm not entirely comfortable with the user-editability of config files and you seem to have either a user-edited one or an old one. Or did you start from scratch and run cminstall?? I don't think so but not sure. The user-editability of config files is partly to allow adapting to inevitably local conditions but I think also a bit of a cop-out to not encode things in cm3. If you correlate the number of questions cminstall asks with the editability of the config file, compare that to the number of questions or amount of editing or command line parameters typically involved with ./configure or apt-get install (often those are zero). In my own "programming", the config files are a cop out related to my lack of comfort with Modula-3. - Jay ---------------------------------------- > Date: Sat, 16 May 2009 11:55:03 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides > > > Jay, > > Thank you Jay for looking into this. Oops, you are right > s/obliq/quake/. > > BTW: It builds all the way even in the same source tree when I do an "./scripts/upgrade.sh", I did a "realclean" first. I guess this > (upgrade.sh) is what most people are using these days to build the > compiler, rather than the old "do-cm3-foo" scripts. > > Okay, I downloaded cm3-src-all-d5.8.0-2009-05-16-12-07-46.tgz, > and did an upgrade.sh, then after a "do-cm3-std.sh realclean", > I re-tryed the "do-cm3.std.sh build", and it failed again with > the same error. This is with cm3 (5.8.0) built with this mornings > source tree. > > I inserted your change into libm3/src/m3override, and it is currently > building. > >> The file now reads: >> >> override("m3core", ROOT & "/m3-libs") >> if defined("M3_FRONT_FLAGS") >> M3_FRONT_FLAGS += "-vsdebug" >> else >> M3_FRONT_FLAGS = ["-vsdebug"] >> end >> _M3BUNDLE_OVERRIDE = "T" > > This is worked for me. I suggest you check it into the repository. > > > Peter > > >> From: jay.krell at cornell.edu >> To: eiserlohpp at yahoo.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides >> Date: Sat May 16 00:27:08 CEST 2009 >> >>specifically: >> >> >>C:\dev2\cm3.2\m3-sys\cminstall\src\config-no-install\cm3cfg.common >> >> >> >>if equal(M3_BACKEND_MODE, "0") or equal(M3_BACKEND_MODE, "1") >> or equal(M3_BACKEND_MODE, "IntegratedObject") or equal(M3_BACKEND_MODE, "IntegratedAssembly") >> M3_FRONT_FLAGS = ["-unfold_nested_procs", "-check_procs"] >>% --- internal configuration options passed directly to the Modula-3 front-end >>else >> M3_FRONT_FLAGS = [ ] >>end >> >> >> - Jay >> > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > From jay.krell at cornell.edu Sun May 17 05:22:06 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 17 May 2009 03:22:06 +0000 Subject: [M3devel] humor: How to do "math" in quake (or at least add one). Message-ID: You might find this amusing. Task: implement a counter, in order to give temp files somewhat unique but not excessively random names caveats: it can exhibit "wraparound" behavior, but it should provide more than just 0-9 solution: m3cc_ResponseFileCounter0 = "0" m3cc_ResponseFileCounter1 = "0" m3cc_ResponseFileCounter2 = "0" local ShLeaf = "_m3" & m3cc_ResponseFileCounter0 & m3cc_ResponseFileCounter1 & m3cc_ResponseFileCounter2 & ".sh" Inc is a table/map/hashtable. Left of colon is key, right of colon is value. local Inc = { "0":"1","1":"2","2":"3","3":"4","4":"5", "5":"6","6":"7","7":"8","8":"9","9":"0" } m3cc_ResponseFileCounter2 = Inc{m3cc_ResponseFileCounter2} if equal(m3cc_ResponseFileCounter2, "0") m3cc_ResponseFileCounter1 = Inc{m3cc_ResponseFileCounter1} if equal(m3cc_ResponseFileCounter1, "0") m3cc_ResponseFileCounter0 = Inc{m3cc_ResponseFileCounter0} end end - Jay From eiserlohpp at yahoo.com Sun May 17 10:11:40 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 17 May 2009 01:11:40 -0700 (PDT) Subject: [M3devel] Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides Message-ID: <645259.70994.qm@web56801.mail.re3.yahoo.com> Hi Jay, Attached AMD64_LINUX (dated: 2008-10-30), Unix.common (dated: 2008-10-30). Hmm, I guess, I have fallen into the Modula-3 config file cess-pool. Okay, I copied the config files to a temporary directory, and the corresponding ones from the current source tree, and diff'ed them. Quite a number of changes. I will grab the new config files from the source tree, ... (hours pass), ..., okay things are working nicely. It failed midway through, complaining that it could not find a certain library. I don't want to install that library, so... I had to remove a couple lines from $ROOT/scripts/pkginfo.txt, specifically odbc, and while I was at it postgres95, I know I don't have Postgress95. That allowed me to build "std". So, then I decided to build everything with "do-cm3-all.sh", and I got an immediate: package cit_common not found *** cannot find package cit_common / Okay, back to editing pkginfo.txt, and removing cit_common, and while I am at it all the caltech parser packages. Darn, I was hoping to play with those. We need to document the fact that we have a number of bindings to libraries that may not exist on any particular machine, and when that occurs, the pkginfo.txt file should be edited to remove those packages from being compiled. Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ --- On Sat, 5/16/09, Jay wrote: > From: Jay > Subject: RE: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides > To: eiserlohpp at yahoo.com, "m3devel" > Date: Saturday, May 16, 2009, 2:52 PM > > Peter can you can roughly > backup your config file > send me/us your config file (attachment to m3devel ok) > cp src/cm3/m3-sys/cminstall/src/config-no-install/* > /usr/local/cm3/bin > > ? > > cm3.cfg might be in the neighboring config directory. > > I'm not entirely comfortable with the user-editability of > config files and you seem to have either a user-edited one > or an old one. > > > Or did you start from scratch and run cminstall?? I don't > think so but not sure. > > > The user-editability of config files is partly to allow > adapting to inevitably local conditions but I think also a > bit of a cop-out to not encode things in cm3. > If you correlate the number of questions cminstall asks > with the editability of the config file, compare that to the > number of questions or amount of editing or command line > parameters typically involved with ./configure or apt-get > install (often those are zero). > > In my own "programming", the config files are a cop out > related to my lack of comfort with Modula-3. > > - Jay > > > ---------------------------------------- > > Date: Sat, 16 May 2009 11:55:03 -0700 > > From: eiserlohpp at yahoo.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] missing M3_FRONT_FLAGS from > libm3: m3overrides > > > > > > Jay, > > > > Thank you Jay for looking into this. Oops, you are > right > > s/obliq/quake/. > > > > BTW: It builds all the way even in the same source > tree when I do an "./scripts/upgrade.sh", I did a > "realclean" first. I guess this > > (upgrade.sh) is what most people are using these days > to build the > > compiler, rather than the old "do-cm3-foo" scripts. > > > > Okay, I downloaded > cm3-src-all-d5.8.0-2009-05-16-12-07-46.tgz, > > and did an upgrade.sh, then after a "do-cm3-std.sh > realclean", > > I re-tryed the "do-cm3.std.sh build", and it failed > again with > > the same error. This is with cm3 (5.8.0) built with > this mornings > > source tree. > > > > I inserted your change into libm3/src/m3override, and > it is currently > > building. > > > >> The file now reads: > >> > >> override("m3core", ROOT & "/m3-libs") > >> if defined("M3_FRONT_FLAGS") > >> M3_FRONT_FLAGS += "-vsdebug" > >> else > >> M3_FRONT_FLAGS = ["-vsdebug"] > >> end > >> _M3BUNDLE_OVERRIDE = "T" > > > > This is worked for me. I suggest you check it into the > repository. > > > > > > Peter > > > > > >> From: jay.krell at cornell.edu > >> To: eiserlohpp at yahoo.com; m3devel at > elegosoft.com > >> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from > libm3: m3overrides > >> Date: Sat May 16 00:27:08 CEST 2009 > >> > >>specifically: > >> > >> > >>C:\dev2\cm3.2\m3-sys\cminstall\src\config-no-install\cm3cfg.common > >> > >> > >> > >>if equal(M3_BACKEND_MODE, "0") or > equal(M3_BACKEND_MODE, "1") > >> or equal(M3_BACKEND_MODE, "IntegratedObject") or > equal(M3_BACKEND_MODE, "IntegratedAssembly") > >> M3_FRONT_FLAGS = ["-unfold_nested_procs", > "-check_procs"] > >>% --- internal configuration options passed > directly to the Modula-3 front-end > >>else > >> M3_FRONT_FLAGS = [ ] > >>end > >> > >> > >> - Jay > >> > > > > > > > +--------------------------------------------------------+ > > | Peter P. Eiserloh | > > > +--------------------------------------------------------+ > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: AMD64_LINUX Type: application/octet-stream Size: 733 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Unix.common Type: application/octet-stream Size: 14515 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cm3.cfg Type: application/octet-stream Size: 23 bytes Desc: not available URL: From jay.krell at cornell.edu Sun May 17 11:39:26 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 17 May 2009 09:39:26 +0000 Subject: [M3devel] Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: <645259.70994.qm@web56801.mail.re3.yahoo.com> References: <645259.70994.qm@web56801.mail.re3.yahoo.com> Message-ID: I know this is a problem and not sure what to do about it. To backtrack, I think the original design is that the config file will put the libraries in system_libraries or system_liborder, and the m3makefile for the dependent packages will check for the presence in them. So, the reason I said "backtrack" is because this is another reason to edit config files, one that I haven't eliminated. You know, my config files are pretty good at being very portable, but not in this way. And they still have the lib/lib32/lib64 problem. Obviously pkginfo.txt wasn't in the original design. :) However the caltech/cit stuff is not this problem. The odbc/postgres stuff is. I generally go and do install the stuff, so I can build larger more featureful distributions. But you could classify that as the obligation of a distribution builder vs. a "normal" user. For caltech/cit, do this: cd to the root of source tree cvs -z3 upd -dAP rm scripts/PKGS and then try again. "all" I don't think works in general, for building. It works for "clean". "std" is the "all that works for buiding", I think. That is how I use them. But I still have a separate list of packages, oops. pylib.py doesn't yet read pkginfo.txt, oops. (This is an area where I complained about and fixed glaring redundancy in the sh files, and then put in my own similar redundancy, but also fixed the other.) Could be, simply, we define two package sets: all-that-tends-to-build-on-stock-systems all-with-extra-dependencies for some definition of "stock" -- does it include X Windows? I frequently hit missing X Windows stuff, but like with odbc/postgres I go and install it. Which devolves to: all-stock-nogui all-stock-gui all but this is getting messy and maybe go back to the original design. OR, maybe this isn't so bad -- you know, in the model where we have apt-get install modula3-this, apt-get install modula3-that, you do end up breaking it down into a lot of smaller pieces. Again I point to the example of what they did with X Windows. And maybe with KDE -- broken things down into many packages. Perhaps we should do that. ?? - Jay ---------------------------------------- > Date: Sun, 17 May 2009 01:11:40 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: [M3devel] Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides > > Hi Jay, > > Attached AMD64_LINUX (dated: 2008-10-30), > Unix.common (dated: 2008-10-30). > > Hmm, I guess, I have fallen into the Modula-3 config file > cess-pool. > > > Okay, I copied the config files to a temporary directory, > and the corresponding ones from the current source tree, > and diff'ed them. > > Quite a number of changes. I will grab the new config files from the > source tree, ... (hours pass), ..., okay things are working nicely. > > It failed midway through, complaining that it could not find > a certain library. I don't want to install that library, so... > > I had to remove a couple lines from $ROOT/scripts/pkginfo.txt, > specifically odbc, and while I was at it postgres95, I know I > don't have Postgress95. That allowed me to build "std". > > So, then I decided to build everything with "do-cm3-all.sh", > and I got an immediate: > > package cit_common not found > *** cannot find package cit_common / > > Okay, back to editing pkginfo.txt, and removing cit_common, and while > I am at it all the caltech parser packages. Darn, I was hoping to play > with those. > > We need to document the fact that we have a number of bindings to > libraries that may not exist on any particular machine, and when > that occurs, the pkginfo.txt file should be edited to remove those > packages from being compiled. > > > Peter > > > > > > > > > > > > > > > > > > > > > > > > > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > --- On Sat, 5/16/09, Jay wrote: > >> From: Jay >> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides >> To: eiserlohpp at yahoo.com, "m3devel" >> Date: Saturday, May 16, 2009, 2:52 PM >> >> Peter can you can roughly >> backup your config file >> send me/us your config file (attachment to m3devel ok) >> cp src/cm3/m3-sys/cminstall/src/config-no-install/* >> /usr/local/cm3/bin >> >> ? >> >> cm3.cfg might be in the neighboring config directory. >> >> I'm not entirely comfortable with the user-editability of >> config files and you seem to have either a user-edited one >> or an old one. >> >> >> Or did you start from scratch and run cminstall?? I don't >> think so but not sure. >> >> >> The user-editability of config files is partly to allow >> adapting to inevitably local conditions but I think also a >> bit of a cop-out to not encode things in cm3. >> If you correlate the number of questions cminstall asks >> with the editability of the config file, compare that to the >> number of questions or amount of editing or command line >> parameters typically involved with ./configure or apt-get >> install (often those are zero). >> >> In my own "programming", the config files are a cop out >> related to my lack of comfort with Modula-3. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Sat, 16 May 2009 11:55:03 -0700 >>> From: eiserlohpp at yahoo.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] missing M3_FRONT_FLAGS from >> libm3: m3overrides >>> >>> >>> Jay, >>> >>> Thank you Jay for looking into this. Oops, you are >> right >>> s/obliq/quake/. >>> >>> BTW: It builds all the way even in the same source >> tree when I do an "./scripts/upgrade.sh", I did a >> "realclean" first. I guess this >>> (upgrade.sh) is what most people are using these days >> to build the >>> compiler, rather than the old "do-cm3-foo" scripts. >>> >>> Okay, I downloaded >> cm3-src-all-d5.8.0-2009-05-16-12-07-46.tgz, >>> and did an upgrade.sh, then after a "do-cm3-std.sh >> realclean", >>> I re-tryed the "do-cm3.std.sh build", and it failed >> again with >>> the same error. This is with cm3 (5.8.0) built with >> this mornings >>> source tree. >>> >>> I inserted your change into libm3/src/m3override, and >> it is currently >>> building. >>> >>>> The file now reads: >>>> >>>> override("m3core", ROOT & "/m3-libs") >>>> if defined("M3_FRONT_FLAGS") >>>> M3_FRONT_FLAGS += "-vsdebug" >>>> else >>>> M3_FRONT_FLAGS = ["-vsdebug"] >>>> end >>>> _M3BUNDLE_OVERRIDE = "T" >>> >>> This is worked for me. I suggest you check it into the >> repository. >>> >>> >>> Peter >>> >>> >>>> From: jay.krell at cornell.edu >>>> To: eiserlohpp at yahoo.com; m3devel at >> elegosoft.com >>>> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from >> libm3: m3overrides >>>> Date: Sat May 16 00:27:08 CEST 2009 >>>> >>>>specifically: >>>> >>>> >>>>C:\dev2\cm3.2\m3-sys\cminstall\src\config-no-install\cm3cfg.common >>>> >>>> >>>> >>>>if equal(M3_BACKEND_MODE, "0") or >> equal(M3_BACKEND_MODE, "1") >>>> or equal(M3_BACKEND_MODE, "IntegratedObject") or >> equal(M3_BACKEND_MODE, "IntegratedAssembly") >>>> M3_FRONT_FLAGS = ["-unfold_nested_procs", >> "-check_procs"] >>>>% --- internal configuration options passed >> directly to the Modula-3 front-end >>>>else >>>> M3_FRONT_FLAGS = [ ] >>>>end >>>> >>>> >>>> - Jay >>>> >>> >>> >>> >> +--------------------------------------------------------+ >>> | Peter P. Eiserloh | >>> >> +--------------------------------------------------------+ >>> >>> >>> > > > From jay.krell at cornell.edu Sun May 17 15:17:42 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 17 May 2009 13:17:42 +0000 Subject: [M3devel] optimizer vs. SOLgnu? Message-ID: Tony can you try building a cross compiler for SOLgnu and see how that fairs with -O2 or -O3? I get: new source -> compiling RTCollector.m3 ../src/runtime/common/RTCollector.m3: In function 'RTHeapRep__RegisterFinalCleanup': ../src/runtime/common/RTCollector.m3:2167: internal compiler error: in lookup_subvars_for_var, at tr ee-flow-inline.h:1591 also with -O2 (probably had it in -O3 also) ../src/runtime/common/RTAllocator.m3: In function 'RTAllocCnts__BumpSize': ../src/runtime/common/RTAllocator.m3:361: internal compiler error: in lookup_subvars_for_var, at tre e-flow-inline.h:1591 ../src/float/Common/DragonInt.m3: In function 'DragonInt__EndSession': ../src/float/Common/DragonInt.m3:90: internal compiler error: in lookup_subvars_for_var, at tree-flo w-inline.h:1591 and lots of success on other source. I am seeing success so far on AMD64_LINUX and LINUXLIBC6. - Jay From jay.krell at cornell.edu Sun May 17 15:35:00 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 17 May 2009 13:35:00 +0000 Subject: [M3devel] optimizer vs. SOLgnu? In-Reply-To: References: Message-ID: a little more info: dbx /dev2/cm3/m3-sys/m3cc/SOLgnu/gcc/m3cgc1 stop in fancy_abort run -quiet -O2 -fno-reorder-blocks RTCollector.mc -o RTCollector.ms where =>[1] fancy_abort(file = 0x813b28 "../../gcc/gcc/tree-flow-inline.h", line = 1591, function = 0x813b 88 "lookup_subvars_for_var"), line 660 in "diagnostic.c" [2] lookup_subvars_for_var(var = 0xfed10a90), line 1591 in "tree-flow-inline.h" [3] get_subvars_for_var(var = 0xfed10a90), line 1608 in "tree-flow-inline.h" [4] create_structure_vars(), line 4165 in "tree-ssa-alias.c" [5] execute_one_pass(pass = 0x860400), line 1122 in "passes.c" [6] execute_pass_list(pass = 0x860400), line 1175 in "passes.c" [7] execute_pass_list(pass = 0x86016c), line 1176 in "passes.c" [8] tree_rest_of_compilation(fndecl = 0xfefbbc00), line 404 in "tree-optimize.c" [9] cgraph_expand_function(node = 0xff149a48), line 1157 in "cgraphunit.c" [10] cgraph_expand_all_functions(), line 1220 in "cgraphunit.c" [11] cgraph_optimize(), line 1427 in "cgraphunit.c" [12] m3_parse_file(xx = 0), line 5241 in "parse.c" [13] compile_file(), line 1042 in "toplev.c" [14] do_compile(), line 2247 in "toplev.c" [15] toplev_main(argc = 7U, argv = 0xffbffbdc), line 2279 in "toplev.c" [16] main(argc = 7, argv = 0xffbffbdc), line 35 in "main.c" (dbx) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 17 May 2009 13:17:42 +0000 > Subject: [M3devel] optimizer vs. SOLgnu? > > > Tony can you try building a cross compiler for SOLgnu and see how that fairs with -O2 or -O3? I get: > > > new source -> compiling RTCollector.m3 > ../src/runtime/common/RTCollector.m3: In function 'RTHeapRep__RegisterFinalCleanup': > ../src/runtime/common/RTCollector.m3:2167: internal compiler error: in lookup_subvars_for_var, at tr > ee-flow-inline.h:1591 > > > also with -O2 (probably had it in -O3 also) > ../src/runtime/common/RTAllocator.m3: In function 'RTAllocCnts__BumpSize': > ../src/runtime/common/RTAllocator.m3:361: internal compiler error: in lookup_subvars_for_var, at tre > e-flow-inline.h:1591 > > > ../src/float/Common/DragonInt.m3: In function 'DragonInt__EndSession': > ../src/float/Common/DragonInt.m3:90: internal compiler error: in lookup_subvars_for_var, at tree-flo > w-inline.h:1591 > > and lots of success on other source. > > > I am seeing success so far on AMD64_LINUX and LINUXLIBC6. > > > - Jay From jay.krell at cornell.edu Sun May 17 15:40:15 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 17 May 2009 13:40:15 +0000 Subject: [M3devel] optimizer vs. SOLgnu/AMD64_LINUX? In-Reply-To: References: Message-ID: AMD64_LINUX (birch): --- building in AMD64_LINUX --- ignoring ../src/m3overrides /home/jkrell/cm3/bin/m3bundle -name B -F/tmp/qk new source -> compiling B.i3 new source -> compiling B.m3 new source -> compiling m3totex.m3 ../src/m3totex.m3: In function 'm3totex__Undisplay': ../src/m3totex.m3:210: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: m3totex.mc compilation failed => not building program "m3totex" Fatal Error: package build failed *** execution of [, ] failed *** birch [~/dev2/cm3/scripts/python] jkrell cd /home/jkrell/dev2/cm3/m3-tools/m3totex cm3 -keep -commands cd AMD64_LINUX gdb --args $HOME/dev2/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cgc1 -quiet -O3 -fno-reorder-blocks m3totex.mc -o m3totex.ms (gdb) r Starting program: /home/jkrell/dev2/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cgc1 -quiet -O3 -fno-reorder-blocks m3totex.mc -o m3totex.ms Program received signal SIGSEGV, Segmentation fault. 0x00000000006814f4 in remove_phi_node (phi=0x2b8f63d8ce80, prev=0x0, release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461 461 *loc != phi; (gdb) where #0 0x00000000006814f4 in remove_phi_node (phi=0x2b8f63d8ce80, prev=0x0, release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461 #1 0x00000000007039fb in remove_dead_inserted_code () at ../../gcc/gcc/tree-ssa-pre.c:3775 #2 0x00000000007042b2 in execute_pre (do_fre=0 '\0') at ../../gcc/gcc/tree-ssa-pre.c:3975 #3 0x00000000007042cc in do_pre () at ../../gcc/gcc/tree-ssa-pre.c:3987 #4 0x000000000058be1b in execute_one_pass (pass=0xe46860) at ../../gcc/gcc/passes.c:1122 #5 0x000000000058bf73 in execute_pass_list (pass=0xe46860) at ../../gcc/gcc/passes.c:1175 #6 0x000000000058bf91 in execute_pass_list (pass=0xe45420) at ../../gcc/gcc/passes.c:1176 #7 0x0000000000676bbd in tree_rest_of_compilation (fndecl=0x2b8f63b24000) at ../../gcc/gcc/tree-optimize.c:404 #8 0x00000000007cedf1 in cgraph_expand_function (node=0x2b8f63ac5d00) at ../../gcc/gcc/cgraphunit.c:1157 #9 0x00000000007cef9e in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1220 #10 0x00000000007cf551 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1427 #11 0x000000000040f875 in m3_parse_file (xx=0) at ../../gcc/gcc/m3cg/parse.c:5241 #12 0x000000000062feec in compile_file () at ../../gcc/gcc/toplev.c:1042 #13 0x0000000000631a26 in do_compile () at ../../gcc/gcc/toplev.c:2247 #14 0x0000000000631a8a in toplev_main (argc=7, argv=0x7fff47342e88) at ../../gcc/gcc/toplev.c:2279 #15 0x0000000000417ecf in main (argc=7, argv=0x7fff47342e88) at ../../gcc/gcc/main.c:35 (gdb) Same thing with -O2. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] optimizer vs. SOLgnu? > Date: Sun, 17 May 2009 13:35:00 +0000 > > > a little more info: > > > dbx /dev2/cm3/m3-sys/m3cc/SOLgnu/gcc/m3cgc1 > stop in fancy_abort > run -quiet -O2 -fno-reorder-blocks RTCollector.mc -o RTCollector.ms > where > > > =>[1] fancy_abort(file = 0x813b28 "../../gcc/gcc/tree-flow-inline.h", line = 1591, function = 0x813b > 88 "lookup_subvars_for_var"), line 660 in "diagnostic.c" > [2] lookup_subvars_for_var(var = 0xfed10a90), line 1591 in "tree-flow-inline.h" > [3] get_subvars_for_var(var = 0xfed10a90), line 1608 in "tree-flow-inline.h" > [4] create_structure_vars(), line 4165 in "tree-ssa-alias.c" > [5] execute_one_pass(pass = 0x860400), line 1122 in "passes.c" > [6] execute_pass_list(pass = 0x860400), line 1175 in "passes.c" > [7] execute_pass_list(pass = 0x86016c), line 1176 in "passes.c" > [8] tree_rest_of_compilation(fndecl = 0xfefbbc00), line 404 in "tree-optimize.c" > [9] cgraph_expand_function(node = 0xff149a48), line 1157 in "cgraphunit.c" > [10] cgraph_expand_all_functions(), line 1220 in "cgraphunit.c" > [11] cgraph_optimize(), line 1427 in "cgraphunit.c" > [12] m3_parse_file(xx = 0), line 5241 in "parse.c" > [13] compile_file(), line 1042 in "toplev.c" > [14] do_compile(), line 2247 in "toplev.c" > [15] toplev_main(argc = 7U, argv = 0xffbffbdc), line 2279 in "toplev.c" > [16] main(argc = 7, argv = 0xffbffbdc), line 35 in "main.c" > (dbx) > > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >> Date: Sun, 17 May 2009 13:17:42 +0000 >> Subject: [M3devel] optimizer vs. SOLgnu? >> >> >> Tony can you try building a cross compiler for SOLgnu and see how that fairs with -O2 or -O3? I get: >> >> >> new source -> compiling RTCollector.m3 >> ../src/runtime/common/RTCollector.m3: In function 'RTHeapRep__RegisterFinalCleanup': >> ../src/runtime/common/RTCollector.m3:2167: internal compiler error: in lookup_subvars_for_var, at tr >> ee-flow-inline.h:1591 >> >> >> also with -O2 (probably had it in -O3 also) >> ../src/runtime/common/RTAllocator.m3: In function 'RTAllocCnts__BumpSize': >> ../src/runtime/common/RTAllocator.m3:361: internal compiler error: in lookup_subvars_for_var, at tre >> e-flow-inline.h:1591 >> >> >> ../src/float/Common/DragonInt.m3: In function 'DragonInt__EndSession': >> ../src/float/Common/DragonInt.m3:90: internal compiler error: in lookup_subvars_for_var, at tree-flo >> w-inline.h:1591 >> >> and lots of success on other source. >> >> >> I am seeing success so far on AMD64_LINUX and LINUXLIBC6. >> >> >> - Jay From wagner at elegosoft.com Sun May 17 16:47:43 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 May 2009 16:47:43 +0200 Subject: [M3devel] humor: How to do "math" in quake (or at least add one). In-Reply-To: References: Message-ID: <20090517164743.1uigqjqfk88s8sg0@mail.elegosoft.com> I think we should just add a function for temporary filenames and implement it in M3. Olaf Quoting Jay : > You might find this amusing. > > > Task: > implement a counter, in order to give > temp files somewhat unique but not excessively > random names > > > caveats: > it can exhibit "wraparound" behavior, but > it should provide more than just 0-9 > > > solution: > > m3cc_ResponseFileCounter0 = "0" > m3cc_ResponseFileCounter1 = "0" > m3cc_ResponseFileCounter2 = "0" > > local ShLeaf = "_m3" & m3cc_ResponseFileCounter0 & > m3cc_ResponseFileCounter1 & m3cc_ResponseFileCounter2 & ".sh" > > > Inc is a table/map/hashtable. > Left of colon is key, right of colon is value. > > > local Inc = { "0":"1","1":"2","2":"3","3":"4","4":"5", > "5":"6","6":"7","7":"8","8":"9","9":"0" } > m3cc_ResponseFileCounter2 = Inc{m3cc_ResponseFileCounter2} > if equal(m3cc_ResponseFileCounter2, "0") > m3cc_ResponseFileCounter1 = Inc{m3cc_ResponseFileCounter1} > if equal(m3cc_ResponseFileCounter1, "0") > m3cc_ResponseFileCounter0 = Inc{m3cc_ResponseFileCounter0} > end > end > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun May 17 17:07:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 May 2009 17:07:14 +0200 Subject: [M3devel] Installation package collections, was: Re: Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: References: <645259.70994.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090517170714.w64nyj44o4884w8s@mail.elegosoft.com> Since Jay's touching the topic below, I thought I'd just tell you all of the first attempt to bundle the M3 packages into installation packages. I didn't want to end up with an installation package for every M3 package, but maybe the granularity is still too coarse. Currently I've got these: % for c in min core devlib m3devtool m3gdb webdev gui anim database cvsup obliq juno caltech-parser demo tool math game; do echo; echo "collection $c"; fgrep " $c" scripts/pkginfo.txt | awk '{print $1}' > x-$c; cat x-$c; done collection min # minimal m3 installation (together with the compiler) import-libs m3core libm3 collection core # a usable system able to bootstrap itself with some additional libraries import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3staloneback m3front m3quake cm3 m3scanner m3tools m3cgcat m3cggen m3bundle mklib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl tcp collection devlib # libraries for various development work windowsResources udp libsio libbuf debug listfuncs m3tk-misc binIO commandrw tapi serial m3tk m3scan m3markup events rdwr PEX deepcopy sgml collection m3devtool # M3 development tools complementing the compiler cm3ide m3totex m3tohtml m3browser netobj netobjd stubgen sharedobj sharedobjgen stablegen stable formsview formsedit recordheap rehearsecode replayheap showheap shownew showthread pp collection m3gdb # the GNU debugger for M3 (rather large, so it has its own package) m3gdb collection webdev # web development packages http m3-www/web m3-www/proxy webvbt deckscape webscape webcat collection gui # gui libraries import-libs tcp X11R4 ui vbtkit cmvbt jvideo videovbt formsvbtpixmaps formsvbt formsview formsedit opengl webvbt kate m3-ui/bicycle collection anim # animation libraries, tools and demo codeview mg mgkit anim3D zeus m3zume mentor collection database # database packages and interfaces odbc postgres95 db smalldb collection cvsup # CVSup cvsup/suplib cvsup/client cvsup/server cvsup/cvpasswd collection obliq # Obliq implementation embutils synloc synex metasyn obliqrt obliqparse obliqprint obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim obliqlib3D visualobliq vocgi voquery vorun collection juno # The Juno graphical constraint-based editor pkl-fonts juno-machine juno-compiler juno-app collection caltech-parser # Caltech parser generator import-libs cit_common m3tmplhack cit_util term paneman paneman/kemacs drawcontext drawcontext/dcpane drawcontext/kgv hack m3browserhack parserlib/ktoklib parserlib/klexlib parserlib/kyacclib parserlib/ktok parserlib/klex parserlib/kyacc parserlib/kext parserlib/parserlib parserlib/parserlib/test collection demo # some demo programs cube calculator fisheye collection tool # more or less useful tools mtex cmpdir cmpfp dirfp uniq collection math # mathematical libraries arithmetic unittest-numeric collection game # games and game support m3-ui/bicycle m3-games/badbricks m3-games/columns m3-games/fours m3-games/maze m3-games/solitaire m3-games/tetris Comments welcome. Olaf Quoting Jay : > I know this is a problem and not sure what to do about it. > > > To backtrack, I think the original design is that the config file will > put the libraries in system_libraries or system_liborder, and the m3makefile > for the dependent packages will check for the presence in them. > > So, the reason I said "backtrack" is because this is another reason > to edit config files, one that I haven't eliminated. > You know, my config files are pretty good at being very portable, > but not in this way. And they still have the lib/lib32/lib64 problem. > > Obviously pkginfo.txt wasn't in the original design. :) > > However the caltech/cit stuff is not this problem. > The odbc/postgres stuff is. > I generally go and do install the stuff, so I can build larger > more featureful distributions. But you could classify that > as the obligation of a distribution builder vs. a "normal" user. > > For caltech/cit, do this: > > cd to the root of source tree > cvs -z3 upd -dAP > rm scripts/PKGS > > and then try again. > > "all" I don't think works in general, for building. > It works for "clean". > "std" is the "all that works for buiding", I think. > That is how I use them. But I still have a separate list of packages, oops. > pylib.py doesn't yet read pkginfo.txt, oops. > (This is an area where I complained about and fixed glaring > redundancy in the sh files, and then put in my own similar > redundancy, but also fixed the other.) > > Could be, simply, we define two package sets: > all-that-tends-to-build-on-stock-systems > all-with-extra-dependencies > > for some definition of "stock" -- does it include X Windows? > I frequently hit missing X Windows stuff, but like with odbc/postgres > I go and install it. > > > Which devolves to: > > all-stock-nogui > all-stock-gui > all > > but this is getting messy and maybe go back to the original design. > OR, maybe this isn't so bad -- you know, in the model where we > have apt-get install modula3-this, apt-get install modula3-that, > you do end up breaking it down into a lot of smaller pieces. > Again I point to the example of what they did with X Windows. > And maybe with KDE -- broken things down into many packages. > Perhaps we should do that. > ?? > > > - Jay > > > ---------------------------------------- >> Date: Sun, 17 May 2009 01:11:40 -0700 >> From: eiserlohpp at yahoo.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] Missing packages, Was: missing M3_FRONT_FLAGS >> from libm3: m3overrides >> >> Hi Jay, >> >> Attached AMD64_LINUX (dated: 2008-10-30), >> Unix.common (dated: 2008-10-30). >> >> Hmm, I guess, I have fallen into the Modula-3 config file >> cess-pool. >> >> >> Okay, I copied the config files to a temporary directory, >> and the corresponding ones from the current source tree, >> and diff'ed them. >> >> Quite a number of changes. I will grab the new config files from the >> source tree, ... (hours pass), ..., okay things are working nicely. >> >> It failed midway through, complaining that it could not find >> a certain library. I don't want to install that library, so... >> >> I had to remove a couple lines from $ROOT/scripts/pkginfo.txt, >> specifically odbc, and while I was at it postgres95, I know I >> don't have Postgress95. That allowed me to build "std". >> >> So, then I decided to build everything with "do-cm3-all.sh", >> and I got an immediate: >> >> package cit_common not found >> *** cannot find package cit_common / >> >> Okay, back to editing pkginfo.txt, and removing cit_common, and while >> I am at it all the caltech parser packages. Darn, I was hoping to play >> with those. >> >> We need to document the fact that we have a number of bindings to >> libraries that may not exist on any particular machine, and when >> that occurs, the pkginfo.txt file should be edited to remove those >> packages from being compiled. >> >> >> Peter >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> +--------------------------------------------------------+ >> | Peter P. Eiserloh | >> +--------------------------------------------------------+ >> >> >> --- On Sat, 5/16/09, Jay wrote: >> >>> From: Jay >>> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides >>> To: eiserlohpp at yahoo.com, "m3devel" >>> Date: Saturday, May 16, 2009, 2:52 PM >>> >>> Peter can you can roughly >>> backup your config file >>> send me/us your config file (attachment to m3devel ok) >>> cp src/cm3/m3-sys/cminstall/src/config-no-install/* >>> /usr/local/cm3/bin >>> >>> ? >>> >>> cm3.cfg might be in the neighboring config directory. >>> >>> I'm not entirely comfortable with the user-editability of >>> config files and you seem to have either a user-edited one >>> or an old one. >>> >>> >>> Or did you start from scratch and run cminstall?? I don't >>> think so but not sure. >>> >>> >>> The user-editability of config files is partly to allow >>> adapting to inevitably local conditions but I think also a >>> bit of a cop-out to not encode things in cm3. >>> If you correlate the number of questions cminstall asks >>> with the editability of the config file, compare that to the >>> number of questions or amount of editing or command line >>> parameters typically involved with ./configure or apt-get >>> install (often those are zero). >>> >>> In my own "programming", the config files are a cop out >>> related to my lack of comfort with Modula-3. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Sat, 16 May 2009 11:55:03 -0700 >>>> From: eiserlohpp at yahoo.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] missing M3_FRONT_FLAGS from >>> libm3: m3overrides >>>> >>>> >>>> Jay, >>>> >>>> Thank you Jay for looking into this. Oops, you are >>> right >>>> s/obliq/quake/. >>>> >>>> BTW: It builds all the way even in the same source >>> tree when I do an "./scripts/upgrade.sh", I did a >>> "realclean" first. I guess this >>>> (upgrade.sh) is what most people are using these days >>> to build the >>>> compiler, rather than the old "do-cm3-foo" scripts. >>>> >>>> Okay, I downloaded >>> cm3-src-all-d5.8.0-2009-05-16-12-07-46.tgz, >>>> and did an upgrade.sh, then after a "do-cm3-std.sh >>> realclean", >>>> I re-tryed the "do-cm3.std.sh build", and it failed >>> again with >>>> the same error. This is with cm3 (5.8.0) built with >>> this mornings >>>> source tree. >>>> >>>> I inserted your change into libm3/src/m3override, and >>> it is currently >>>> building. >>>> >>>>> The file now reads: >>>>> >>>>> override("m3core", ROOT & "/m3-libs") >>>>> if defined("M3_FRONT_FLAGS") >>>>> M3_FRONT_FLAGS += "-vsdebug" >>>>> else >>>>> M3_FRONT_FLAGS = ["-vsdebug"] >>>>> end >>>>> _M3BUNDLE_OVERRIDE = "T" >>>> >>>> This is worked for me. I suggest you check it into the >>> repository. >>>> >>>> >>>> Peter >>>> >>>> >>>>> From: jay.krell at cornell.edu >>>>> To: eiserlohpp at yahoo.com; m3devel at >>> elegosoft.com >>>>> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from >>> libm3: m3overrides >>>>> Date: Sat May 16 00:27:08 CEST 2009 >>>>> >>>>> specifically: >>>>> >>>>> >>>>> C:\dev2\cm3.2\m3-sys\cminstall\src\config-no-install\cm3cfg.common >>>>> >>>>> >>>>> >>>>> if equal(M3_BACKEND_MODE, "0") or >>> equal(M3_BACKEND_MODE, "1") >>>>> or equal(M3_BACKEND_MODE, "IntegratedObject") or >>> equal(M3_BACKEND_MODE, "IntegratedAssembly") >>>>> M3_FRONT_FLAGS = ["-unfold_nested_procs", >>> "-check_procs"] >>>>> % --- internal configuration options passed >>> directly to the Modula-3 front-end >>>>> else >>>>> M3_FRONT_FLAGS = [ ] >>>>> end >>>>> >>>>> >>>>> - Jay >>>>> >>>> >>>> >>>> >>> +--------------------------------------------------------+ >>>> | Peter P. Eiserloh | >>>> >>> +--------------------------------------------------------+ >>>> >>>> >>>> >> >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon May 18 02:12:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 May 2009 10:12:56 +1000 Subject: [M3devel] optimizer vs. SOLgnu? In-Reply-To: References: Message-ID: This one sounds familiar. I'll try to track it down. On 17 May 2009, at 23:17, Jay wrote: > > Tony can you try building a cross compiler for SOLgnu and see how > that fairs with -O2 or -O3? I get: > > > new source -> compiling RTCollector.m3 > ../src/runtime/common/RTCollector.m3: In function > 'RTHeapRep__RegisterFinalCleanup': > ../src/runtime/common/RTCollector.m3:2167: internal compiler error: > in lookup_subvars_for_var, at tr > ee-flow-inline.h:1591 > > > also with -O2 (probably had it in -O3 also) > ../src/runtime/common/RTAllocator.m3: In function > 'RTAllocCnts__BumpSize': > ../src/runtime/common/RTAllocator.m3:361: internal compiler error: > in lookup_subvars_for_var, at tre > e-flow-inline.h:1591 > > > ../src/float/Common/DragonInt.m3: In function 'DragonInt__EndSession': > ../src/float/Common/DragonInt.m3:90: internal compiler error: in > lookup_subvars_for_var, at tree-flo > w-inline.h:1591 > > and lots of success on other source. > > > I am seeing success so far on AMD64_LINUX and LINUXLIBC6. > > > - Jay From hosking at cs.purdue.edu Mon May 18 02:13:42 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 May 2009 10:13:42 +1000 Subject: [M3devel] optimizer vs. SOLgnu/AMD64_LINUX? In-Reply-To: References: Message-ID: <66DE48A4-130D-4990-9E34-1437E74FEC5A@cs.purdue.edu> This one also sounds familiar. On 17 May 2009, at 23:40, Jay wrote: > > AMD64_LINUX (birch): > > --- building in AMD64_LINUX --- > ignoring ../src/m3overrides > /home/jkrell/cm3/bin/m3bundle -name B -F/tmp/qk > new source -> compiling B.i3 > new source -> compiling B.m3 > new source -> compiling m3totex.m3 > ../src/m3totex.m3: In function 'm3totex__Undisplay': > ../src/m3totex.m3:210: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: m3totex.mc > compilation failed => not building program "m3totex" > Fatal Error: package build failed > *** execution of [, ] failed *** > birch [~/dev2/cm3/scripts/python] jkrell > > > cd /home/jkrell/dev2/cm3/m3-tools/m3totex > cm3 -keep -commands > cd AMD64_LINUX > gdb --args $HOME/dev2/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cgc1 -quiet - > O3 -fno-reorder-blocks m3totex.mc -o m3totex.ms > (gdb) r > Starting program: /home/jkrell/dev2/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/ > m3cgc1 -quiet -O3 -fno-reorder-blocks m3totex.mc -o m3totex.ms > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000006814f4 in remove_phi_node (phi=0x2b8f63d8ce80, prev=0x0, > release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461 > 461 *loc != phi; > > (gdb) where > #0 0x00000000006814f4 in remove_phi_node (phi=0x2b8f63d8ce80, > prev=0x0, > release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461 > #1 0x00000000007039fb in remove_dead_inserted_code () > at ../../gcc/gcc/tree-ssa-pre.c:3775 > #2 0x00000000007042b2 in execute_pre (do_fre=0 '\0') > at ../../gcc/gcc/tree-ssa-pre.c:3975 > #3 0x00000000007042cc in do_pre () at ../../gcc/gcc/tree-ssa-pre.c: > 3987 > #4 0x000000000058be1b in execute_one_pass (pass=0xe46860) > at ../../gcc/gcc/passes.c:1122 > #5 0x000000000058bf73 in execute_pass_list (pass=0xe46860) > at ../../gcc/gcc/passes.c:1175 > #6 0x000000000058bf91 in execute_pass_list (pass=0xe45420) > at ../../gcc/gcc/passes.c:1176 > #7 0x0000000000676bbd in tree_rest_of_compilation > (fndecl=0x2b8f63b24000) > at ../../gcc/gcc/tree-optimize.c:404 > #8 0x00000000007cedf1 in cgraph_expand_function (node=0x2b8f63ac5d00) > at ../../gcc/gcc/cgraphunit.c:1157 > #9 0x00000000007cef9e in cgraph_expand_all_functions () > at ../../gcc/gcc/cgraphunit.c:1220 > #10 0x00000000007cf551 in cgraph_optimize () > at ../../gcc/gcc/cgraphunit.c:1427 > #11 0x000000000040f875 in m3_parse_file (xx=0) > at ../../gcc/gcc/m3cg/parse.c:5241 > #12 0x000000000062feec in compile_file () at ../../gcc/gcc/toplev.c: > 1042 > #13 0x0000000000631a26 in do_compile () at ../../gcc/gcc/toplev.c:2247 > #14 0x0000000000631a8a in toplev_main (argc=7, argv=0x7fff47342e88) > at ../../gcc/gcc/toplev.c:2279 > #15 0x0000000000417ecf in main (argc=7, argv=0x7fff47342e88) > at ../../gcc/gcc/main.c:35 > (gdb) > > > Same thing with -O2. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >> Subject: RE: [M3devel] optimizer vs. SOLgnu? >> Date: Sun, 17 May 2009 13:35:00 +0000 >> >> >> a little more info: >> >> >> dbx /dev2/cm3/m3-sys/m3cc/SOLgnu/gcc/m3cgc1 >> stop in fancy_abort >> run -quiet -O2 -fno-reorder-blocks RTCollector.mc -o RTCollector.ms >> where >> >> >> =>[1] fancy_abort(file = 0x813b28 "../../gcc/gcc/tree-flow- >> inline.h", line = 1591, function = 0x813b >> 88 "lookup_subvars_for_var"), line 660 in "diagnostic.c" >> [2] lookup_subvars_for_var(var = 0xfed10a90), line 1591 in "tree- >> flow-inline.h" >> [3] get_subvars_for_var(var = 0xfed10a90), line 1608 in "tree-flow- >> inline.h" >> [4] create_structure_vars(), line 4165 in "tree-ssa-alias.c" >> [5] execute_one_pass(pass = 0x860400), line 1122 in "passes.c" >> [6] execute_pass_list(pass = 0x860400), line 1175 in "passes.c" >> [7] execute_pass_list(pass = 0x86016c), line 1176 in "passes.c" >> [8] tree_rest_of_compilation(fndecl = 0xfefbbc00), line 404 in >> "tree-optimize.c" >> [9] cgraph_expand_function(node = 0xff149a48), line 1157 in >> "cgraphunit.c" >> [10] cgraph_expand_all_functions(), line 1220 in "cgraphunit.c" >> [11] cgraph_optimize(), line 1427 in "cgraphunit.c" >> [12] m3_parse_file(xx = 0), line 5241 in "parse.c" >> [13] compile_file(), line 1042 in "toplev.c" >> [14] do_compile(), line 2247 in "toplev.c" >> [15] toplev_main(argc = 7U, argv = 0xffbffbdc), line 2279 in >> "toplev.c" >> [16] main(argc = 7, argv = 0xffbffbdc), line 35 in "main.c" >> (dbx) >> >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Date: Sun, 17 May 2009 13:17:42 +0000 >>> Subject: [M3devel] optimizer vs. SOLgnu? >>> >>> >>> Tony can you try building a cross compiler for SOLgnu and see how >>> that fairs with -O2 or -O3? I get: >>> >>> >>> new source -> compiling RTCollector.m3 >>> ../src/runtime/common/RTCollector.m3: In function >>> 'RTHeapRep__RegisterFinalCleanup': >>> ../src/runtime/common/RTCollector.m3:2167: internal compiler >>> error: in lookup_subvars_for_var, at tr >>> ee-flow-inline.h:1591 >>> >>> >>> also with -O2 (probably had it in -O3 also) >>> ../src/runtime/common/RTAllocator.m3: In function >>> 'RTAllocCnts__BumpSize': >>> ../src/runtime/common/RTAllocator.m3:361: internal compiler error: >>> in lookup_subvars_for_var, at tre >>> e-flow-inline.h:1591 >>> >>> >>> ../src/float/Common/DragonInt.m3: In function >>> 'DragonInt__EndSession': >>> ../src/float/Common/DragonInt.m3:90: internal compiler error: in >>> lookup_subvars_for_var, at tree-flo >>> w-inline.h:1591 >>> >>> and lots of success on other source. >>> >>> >>> I am seeing success so far on AMD64_LINUX and LINUXLIBC6. >>> >>> >>> - Jay From jay.krell at cornell.edu Mon May 18 04:23:03 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 18 May 2009 02:23:03 +0000 Subject: [M3devel] version number Message-ID: Did we burn through 5.7.x too fast maybe? I know it hardly matters... - Jay From wagner at elegosoft.com Mon May 18 10:53:59 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 May 2009 10:53:59 +0200 Subject: [M3devel] version number In-Reply-To: References: Message-ID: <20090518105359.e9qguctgsowg4k0o@mail.elegosoft.com> Quoting Jay : > Did we burn through 5.7.x too fast maybe? > I know it hardly matters... I'm using the version number for release engineering now. Whenever there is change until the release, I'll increase the patch level. I still lhope that the other activities calm down when the first RC is there; otherwise I'll have to create a branch. I hope this does not interfere with anything else. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Mon May 18 12:47:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 18 May 2009 06:47:48 -0400 Subject: [M3devel] Installation package collections, was: Re: Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: <20090517170714.w64nyj44o4884w8s@mail.elegosoft.com> References: <645259.70994.qm@web56801.mail.re3.yahoo.com> <20090517170714.w64nyj44o4884w8s@mail.elegosoft.com> Message-ID: <20090518104747.GB24011@topoi.pooq.com> On Sun, May 17, 2009 at 05:07:14PM +0200, Olaf Wagner wrote: > > collection gui # gui libraries > m3-ui/bicycle > > collection game # games and game support > m3-ui/bicycle One m3 package is in two different collections. If eash collection turns into a Debian package, they will conflict. -- hendrik From dragisha at m3w.org Mon May 18 14:29:12 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 18 May 2009 14:29:12 +0200 Subject: [M3devel] Pickle related incompatible changes in last six months, anybody? Message-ID: <1242649752.9969.9.camel@faramir.m3w.org> As subjest line says, are there some incompatibilies incorporated into Pickle subsystem in last six months? I have a database, unused for some time, last changed some six months ago... TIA, -- Dragi?a Duri? From wagner at elegosoft.com Mon May 18 19:47:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 May 2009 19:47:36 +0200 Subject: [M3devel] Installation package collections, was: Re: Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides In-Reply-To: <20090518104747.GB24011@topoi.pooq.com> References: <645259.70994.qm@web56801.mail.re3.yahoo.com> <20090517170714.w64nyj44o4884w8s@mail.elegosoft.com> <20090518104747.GB24011@topoi.pooq.com> Message-ID: <20090518194736.g2xtpy06m8soocw8@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Sun, May 17, 2009 at 05:07:14PM +0200, Olaf Wagner wrote: >> >> collection gui # gui libraries >> m3-ui/bicycle >> >> collection game # games and game support >> m3-ui/bicycle > > One m3 package is in two different collections. If eash collection > turns into a Debian package, they will conflict. Any preferences where to remove the conflicting package(s)? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue May 19 15:50:19 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 19 May 2009 06:50:19 -0700 Subject: [M3devel] Cm3 on iPhone (or iPod touch) Message-ID: <3C3602DD-4C3D-4A34-B228-E822DBA483E8@hotmail.com> Cm3 gets to the of saying like "no config file found" which is correct. - Jay (phone) From dragisha at m3w.org Tue May 19 19:27:28 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 19 May 2009 19:27:28 +0200 Subject: [M3devel] Probably missing too much of development sycle, but WTF? Message-ID: <1242754048.3061.1.camel@faramir.m3w.org> VARIABLES? Now every1 who was using CASE with error results has to adapt one's code? What is rationale here? Portability? TIA! INTERFACE Uerror; FROM Ctypes IMPORT int; (* CONST *) <*EXTERNAL "Uerror__EACCES"*> VAR EACCES: int; <*EXTERNAL "Uerror__EADDRINUSE"*> VAR EADDRINUSE: int; <*EXTERNAL "Uerror__EADDRNOTAVAIL"*> VAR EADDRNOTAVAIL: int; <*EXTERNAL "Uerror__EAGAIN"*> VAR EAGAIN: int; -- Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Tue May 19 23:32:24 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Tue, 19 May 2009 16:32:24 -0500 Subject: [M3devel] subrange value not constant? Message-ID: <4A132568.4060206@bellsouth.net> I've written this procedure (an implementation of counting sort): PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = VAR count := ARRAY [min..max] OF INTEGER {0, ..}; z := 0; BEGIN FOR i := FIRST(a) TO LAST(a) DO count[i - min] := count[i - min] + 1; END; FOR i := min TO max DO WHILE count[i - min] > 0 DO a[z] := i; INC(z); count[i - min] := count[i - min] - 1; END; END; END Sort; However, when I try to compile I get: "../Counting.m3", line 8: subrange lower bound is not constant "../Counting.m3", line 8: subrange upper bound is not constant Line 8 is: VAR count := ARRAY [min..max] OF INTEGER {0, ..}; I don't see what's wrong? From hosking at cs.purdue.edu Tue May 19 23:48:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 20 May 2009 07:48:34 +1000 Subject: [M3devel] subrange value not constant? In-Reply-To: <4A132568.4060206@bellsouth.net> References: <4A132568.4060206@bellsouth.net> Message-ID: <0D3047B2-96B1-464E-9774-A861ABF373B5@cs.purdue.edu> min is a variable argument to Sort. You should use an open array argument to Sort: ARRAY OF INTEGER. Modula-3 does not support alloca style of allocation. You need to allocate the count array in the heap. count := NEW(ARRAY OF INTEGER, NUMBER(a)). On 20 May 2009, at 07:32, Martin Bishop wrote: > I've written this procedure (an implementation of counting sort): > > PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = > VAR count := ARRAY [min..max] OF INTEGER {0, ..}; > z := 0; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > count[i - min] := count[i - min] + 1; > END; > FOR i := min TO max DO > WHILE count[i - min] > 0 DO > a[z] := i; > INC(z); > count[i - min] := count[i - min] - 1; > END; > END; > END Sort; > > However, when I try to compile I get: > > "../Counting.m3", line 8: subrange lower bound is not constant > "../Counting.m3", line 8: subrange upper bound is not constant > > Line 8 is: > > VAR count := ARRAY [min..max] OF INTEGER {0, ..}; > > I don't see what's wrong? From jay.krell at cornell.edu Tue May 19 23:37:12 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 19 May 2009 14:37:12 -0700 Subject: [M3devel] Probably missing too much of development sycle, but WTF? In-Reply-To: <1242754048.3061.1.camel@faramir.m3w.org> References: <1242754048.3061.1.camel@faramir.m3w.org> Message-ID: <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> Yes a little unfortunate but very portable. - Jay (phone) On May 19, 2009, at 10:27 AM, Dragi?a Duri? wrote: > VARIABLES? > > Now every1 who was using CASE with error results has to adapt one's > code? > > What is rationale here? Portability? > > TIA! > > INTERFACE Uerror; > > FROM Ctypes IMPORT int; > > (* CONST *) > <*EXTERNAL "Uerror__EACCES"*> VAR EACCES: int; > <*EXTERNAL "Uerror__EADDRINUSE"*> VAR EADDRINUSE: int; > <*EXTERNAL "Uerror__EADDRNOTAVAIL"*> VAR EADDRNOTAVAIL: int; > <*EXTERNAL "Uerror__EAGAIN"*> VAR EAGAIN: int; > > > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed May 20 00:59:18 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 19 May 2009 18:59:18 -0400 Subject: [M3devel] Probably missing too much of development sycle, but WTF? In-Reply-To: <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> Message-ID: <4A130147.1E75.00D7.1@scires.com> Why is this more portable than using constants? especially since it breaks existing code? --Randy >>> 5/19/2009 5:37 PM >>> Yes a little unfortunate but very portable. - Jay (phone) On May 19, 2009, at 10:27 AM, Dragi?a Duri* wrote: VARIABLES? Now every1 who was using CASE with error results has to adapt one's code? What is rationale here? Portability? TIA! INTERFACE Uerror; FROM Ctypes IMPORT int; (* CONST *) <*EXTERNAL "Uerror__EACCES"*> VAR EACCES: int; <*EXTERNAL "Uerror__EADDRINUSE"*> VAR EADDRINUSE: int; <*EXTERNAL "Uerror__EADDRNOTAVAIL"*> VAR EADDRNOTAVAIL: int; <*EXTERNAL "Uerror__EAGAIN"*> VAR EAGAIN: int; -- Dragi?a Duri* CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed May 20 01:05:49 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 19 May 2009 23:05:49 +0000 Subject: [M3devel] Probably missing too much of development sycle, but WTF? In-Reply-To: <4A130147.1E75.00D7.1@scires.com> References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> <4A130147.1E75.00D7.1@scires.com> Message-ID: It is portable to all target platforms. The approach with constants makes you have to "rewrite" Uerror.i3 for each target platform. Rewriting headers is tedious, error prone, and very dangerous. The approach with variables has just one implementation for all targets. This approach is much safer. I change the switch statements to if/elseif ladders. Yes it is less efficient, but it is also usually an error path. Yes it is source incompatible and I'm not happy about that, but I also like to keep platform specific code to a small minimum. It is a tradeoff. - Jay ________________________________ > Date: Tue, 19 May 2009 18:59:18 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Probably missing too much of development sycle, but WTF? > > > > > > > > Why is this more portable than using constants? especially since it breaks existing code? > > --Randy > >>>> 5/19/2009 5:37 PM>>> > > Yes a little unfortunate but very portable. > > - Jay (phone) > > > On May 19, 2009, at 10:27 AM, Dragi?a Duric> wrote: > > > > > VARIABLES? > > Now every1 who was using CASE with error results has to adapt one's code? > > What is rationale here? Portability? > > TIA! > > INTERFACE Uerror; > > FROM Ctypes IMPORT int; > > (* CONST *) > VAR EACCES: int; > VAR EADDRINUSE: int; > VAR EADDRNOTAVAIL: int; > VAR EAGAIN: int; > > > > > > > -- > Dragi?a Duric From jay.krell at cornell.edu Wed May 20 01:05:51 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 19 May 2009 23:05:51 +0000 Subject: [M3devel] Probably missing too much of development sycle, but WTF? In-Reply-To: <4A130147.1E75.00D7.1@scires.com> References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> <4A130147.1E75.00D7.1@scires.com> Message-ID: It is portable to all target platforms. The approach with constants makes you have to "rewrite" Uerror.i3 for each target platform. Rewriting headers is tedious, error prone, and very dangerous. The approach with variables has just one implementation for all targets. This approach is much safer. I change the switch statements to if/elseif ladders. Yes it is less efficient, but it is also usually an error path. Yes it is source incompatible and I'm not happy about that, but I also like to keep platform specific code to a small minimum. It is a tradeoff. - Jay ________________________________ > Date: Tue, 19 May 2009 18:59:18 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Probably missing too much of development sycle, but WTF? > > > > > > > > Why is this more portable than using constants? especially since it breaks existing code? > > --Randy > >>>> 5/19/2009 5:37 PM>>> > > Yes a little unfortunate but very portable. > > - Jay (phone) > > > On May 19, 2009, at 10:27 AM, Dragi?a Duric> wrote: > > > > > VARIABLES? > > Now every1 who was using CASE with error results has to adapt one's code? > > What is rationale here? Portability? > > TIA! > > INTERFACE Uerror; > > FROM Ctypes IMPORT int; > > (* CONST *) > VAR EACCES: int; > VAR EADDRINUSE: int; > VAR EADDRNOTAVAIL: int; > VAR EAGAIN: int; > > > > > > > -- > Dragi?a Duric From jay.krell at cornell.edu Wed May 20 01:14:36 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 19 May 2009 23:14:36 +0000 Subject: [M3devel] m3_load/store using bitfields for everything Message-ID: m3_load/store using bitfields for everything caused module-global references to disappear on MIPS64_OPENBSD (all MIPS?). I worked around that by declaring that the module-globals are at least of size 2 * biggest_alignment. It caused module-global references to disappear on ARM_DARWIN as well. I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't occur and PutChar eventually failed an array bounds check. Is this just too fragile and the failsafe form should always be used? Or, it fails spectacularly consistently enough that it must also be working consistently enough and leave it? Would "component ref" (ie: struct) and declaring more type information about module segments be a good compromise maybe? Probably. - Jay From hosking at cs.purdue.edu Wed May 20 02:23:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 20 May 2009 10:23:33 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: What optimization level are you using? I think what it comes down to is figuring out why the backend eliminates those globals and setting them up so it doesn't. There is usually some gcc incantation that will do the trick, but it often involves deep reading of the gcc source code. I am in the middle of that for the SOLgnu optimization failures (that we did not used to see until I upgraded to gcc 4.3.0 last year. I wonder if the TREE_THIS_VOLATILE bit is no longer sufficient. Can you see what happens if you replace that with m3_volatilize_decl instead? This was needed for the variables used in functions calling setjmp and may be necessary here too. On 20 May 2009, at 09:14, Jay wrote: > m3_load/store using bitfields for everything caused module-global > references to disappear on MIPS64_OPENBSD (all MIPS?). I worked > around that by declaring that the module-globals are at least of > size 2 * biggest_alignment. > > It caused module-global references to disappear on ARM_DARWIN as well. > I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't > occur and PutChar eventually failed an array bounds check. > > Is this just too fragile and the failsafe form should always be used? > > Or, it fails spectacularly consistently enough that it must also be > working consistently enough and leave it? > > Would "component ref" (ie: struct) and declaring more type > information about module segments be a good compromise maybe? > Probably. > > - Jay From jay.krell at cornell.edu Wed May 20 04:20:12 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 20 May 2009 02:20:12 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: This is with no optimization at all. I haven't tried replacing it with volatize. The problem on MIPS64_OPENBSD was the notion that bitfields fit in a register so any offset beyond a register was thrown out, or something. I do think a "component ref" would be appropriate, but don't know if it is a lot of work, to get the typeinfo through. - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: m3_load/store using bitfields for everything > Date: Wed, 20 May 2009 10:23:33 +1000 > > What optimization level are you using? > > I think what it comes down to is figuring out why the backend > eliminates those globals and setting them up so it doesn't. There is > usually some gcc incantation that will do the trick, but it often > involves deep reading of the gcc source code. > > I am in the middle of that for the SOLgnu optimization failures (that > we did not used to see until I upgraded to gcc 4.3.0 last year. I > wonder if the TREE_THIS_VOLATILE bit is no longer sufficient. Can you > see what happens if you replace that with m3_volatilize_decl instead? > This was needed for the variables used in functions calling setjmp and > may be necessary here too. > > On 20 May 2009, at 09:14, Jay wrote: > >> m3_load/store using bitfields for everything caused module-global >> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >> around that by declaring that the module-globals are at least of >> size 2 * biggest_alignment. >> >> It caused module-global references to disappear on ARM_DARWIN as well. >> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >> occur and PutChar eventually failed an array bounds check. >> >> Is this just too fragile and the failsafe form should always be used? >> >> Or, it fails spectacularly consistently enough that it must also be >> working consistently enough and leave it? >> >> Would "component ref" (ie: struct) and declaring more type >> information about module segments be a good compromise maybe? >> Probably. >> >> - Jay > From hosking at cs.purdue.edu Wed May 20 05:03:54 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 20 May 2009 13:03:54 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: I'm working on it. On 20 May 2009, at 12:20, Jay wrote: > > This is with no optimization at all. > > I haven't tried replacing it with volatize. > The problem on MIPS64_OPENBSD was the notion that bitfields fit in a > register so any offset beyond a register was thrown out, or something. > > I do think a "component ref" would be appropriate, but don't know if > it is a lot of work, to get the typeinfo through. > > - Jay > > ---------------------------------------- >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: m3_load/store using bitfields for everything >> Date: Wed, 20 May 2009 10:23:33 +1000 >> >> What optimization level are you using? >> >> I think what it comes down to is figuring out why the backend >> eliminates those globals and setting them up so it doesn't. There is >> usually some gcc incantation that will do the trick, but it often >> involves deep reading of the gcc source code. >> >> I am in the middle of that for the SOLgnu optimization failures (that >> we did not used to see until I upgraded to gcc 4.3.0 last year. I >> wonder if the TREE_THIS_VOLATILE bit is no longer sufficient. Can you >> see what happens if you replace that with m3_volatilize_decl instead? >> This was needed for the variables used in functions calling setjmp >> and >> may be necessary here too. >> >> On 20 May 2009, at 09:14, Jay wrote: >> >>> m3_load/store using bitfields for everything caused module-global >>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >>> around that by declaring that the module-globals are at least of >>> size 2 * biggest_alignment. >>> >>> It caused module-global references to disappear on ARM_DARWIN as >>> well. >>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >>> occur and PutChar eventually failed an array bounds check. >>> >>> Is this just too fragile and the failsafe form should always be >>> used? >>> >>> Or, it fails spectacularly consistently enough that it must also be >>> working consistently enough and leave it? >>> >>> Would "component ref" (ie: struct) and declaring more type >>> information about module segments be a good compromise maybe? >>> Probably. >>> >>> - Jay >> From dragisha at m3w.org Wed May 20 07:41:34 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 20 May 2009 07:41:34 +0200 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> Message-ID: <1242798094.3061.7.camel@faramir.m3w.org> Then please be complete :) AF_UNIX is missing, and also stuct_sockaddr_un structure. Yes I know how to add it. Yes you're pretty radical these days, so please do it your way so you don't have to edit my patch :) Also - you maybe remember make_dir problem I've reported few months (?) ago... I've narrowed it to situation where my earlier patch sets CM3_INSTALL_PREFIX. It started to happen some months after I patched it, and it happens only when shipping m3core. On Tue, 2009-05-19 at 14:37 -0700, jay.krell at cornell.edu wrote: > Yes a little unfortunate but very portable. > > - Jay (phone) > > On May 19, 2009, at 10:27 AM, Dragi?a Duri? wrote: > > > > > VARIABLES? > > > > Now every1 who was using CASE with error results has to adapt one's > > code? > > > > What is rationale here? Portability? > > > > TIA! > > > > INTERFACE Uerror; > > > > FROM Ctypes IMPORT int; > > > > (* CONST *) > > <*EXTERNAL "Uerror__EACCES"*> VAR EACCES: int; > > <*EXTERNAL "Uerror__EADDRINUSE"*> VAR EADDRINUSE: int; > > <*EXTERNAL "Uerror__EADDRNOTAVAIL"*> VAR EADDRNOTAVAIL: int; > > <*EXTERNAL "Uerror__EAGAIN"*> VAR EAGAIN: int; > > > > > > -- > > Dragi?a Duri? -- Dragi?a Duri? From jay.krell at cornell.edu Wed May 20 08:33:52 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 20 May 2009 06:33:52 +0000 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: <1242798094.3061.7.camel@faramir.m3w.org> References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> <1242798094.3061.7.camel@faramir.m3w.org> Message-ID: > AF_UNIX I'll try to make another pass through and put back unused constants, I guess. At some point I erred toward removing unused stuff, because everything present was a correctness and portability issue. Though I mainly only did such removal with Cygwin, on the basis of it never really existing as a port so the initial version could be minimal. I think, maybe I removed other? I also removed userthread support from PPC_LINUX and maybe NetBSD/i386. It was broken for all platforms and remains so for all Linux platforms. Later I developed more portable techniques so it becomes more acceptable to leave stuff in, but convert it to be correct and portable. Constants are easy. > stuct_sockaddr_un structure Structs though are problematic. You end up wanting to wrap all the functions that use them. Unless they are large structs and then you don't want the waste and you are either stuck, or you maybe wrap at the next level up. This is an area actually where we still clone the headers, still work to do to make it portable and safe. > make_dir No I had forgotten but I see it searching the web. You need the dots smushed out? - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Wed, 20 May 2009 07:41:34 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? > > Then please be complete :) > > AF_UNIX is missing, and also stuct_sockaddr_un structure. > > Yes I know how to add it. Yes you're pretty radical these days, so > please do it your way so you don't have to edit my patch :) > > Also - you maybe remember make_dir problem I've reported few months (?) > ago... I've narrowed it to situation where my earlier patch sets > CM3_INSTALL_PREFIX. It started to happen some months after I patched it, > and it happens only when shipping m3core. > > On Tue, 2009-05-19 at 14:37 -0700, jay.krell at cornell.edu wrote: >> Yes a little unfortunate but very portable. >> >> - Jay (phone) >> >> On May 19, 2009, at 10:27 AM, Dragi?a Duri? wrote: >> >> >> >>> VARIABLES? >>> >>> Now every1 who was using CASE with error results has to adapt one's >>> code? >>> >>> What is rationale here? Portability? >>> >>> TIA! >>> >>> INTERFACE Uerror; >>> >>> FROM Ctypes IMPORT int; >>> >>> (* CONST *) >>> VAR EACCES: int; >>> VAR EADDRINUSE: int; >>> VAR EADDRNOTAVAIL: int; >>> VAR EAGAIN: int; >>> >>> >>> -- >>> Dragi?a Duri? > -- > Dragi?a Duri? > From jay.krell at cornell.edu Wed May 20 08:38:34 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 20 May 2009 06:38:34 +0000 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> <1242798094.3061.7.camel@faramir.m3w.org> Message-ID: Oops, I guess it is the switch to the new headers (m3core/src/unix/Comon/*.i3) that causes the removal of unused stuff. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: dragisha at m3w.org > Date: Wed, 20 May 2009 06:33:52 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? > > >> AF_UNIX > > > I'll try to make another pass through and put back unused constants, I guess. > > > At some point I erred toward removing unused stuff, because everything present was a correctness and portability issue. > > Though I mainly only did such removal with Cygwin, on the basis of it never really existing as a port so the initial version could be minimal. > I think, maybe I removed other? > I also removed userthread support from PPC_LINUX and maybe NetBSD/i386. > It was broken for all platforms and remains so for all Linux platforms. > > > Later I developed more portable techniques so it becomes more acceptable to leave stuff in, but convert it to be correct and portable. > > > Constants are easy. > > >> stuct_sockaddr_un structure > > > Structs though are problematic. > You end up wanting to wrap all the functions that use them. > Unless they are large structs and then you don't want the waste and you are either stuck, or you maybe wrap at the next level up. > > > This is an area actually where we still clone the headers, still work to do to make it portable and safe. > > >> make_dir > > > No I had forgotten but I see it searching the web. > You need the dots smushed out? > > > - Jay > > > > ---------------------------------------- >> From: dragisha at m3w.org >> To: jay.krell at cornell.edu >> Date: Wed, 20 May 2009 07:41:34 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? >> >> Then please be complete :) >> >> AF_UNIX is missing, and also stuct_sockaddr_un structure. >> >> Yes I know how to add it. Yes you're pretty radical these days, so >> please do it your way so you don't have to edit my patch :) >> >> Also - you maybe remember make_dir problem I've reported few months (?) >> ago... I've narrowed it to situation where my earlier patch sets >> CM3_INSTALL_PREFIX. It started to happen some months after I patched it, >> and it happens only when shipping m3core. >> >> On Tue, 2009-05-19 at 14:37 -0700, jay.krell at cornell.edu wrote: >>> Yes a little unfortunate but very portable. >>> >>> - Jay (phone) >>> >>> On May 19, 2009, at 10:27 AM, Dragi?a Duri? wrote: >>> >>> >>> >>>> VARIABLES? >>>> >>>> Now every1 who was using CASE with error results has to adapt one's >>>> code? >>>> >>>> What is rationale here? Portability? >>>> >>>> TIA! >>>> >>>> INTERFACE Uerror; >>>> >>>> FROM Ctypes IMPORT int; >>>> >>>> (* CONST *) >>>> VAR EACCES: int; >>>> VAR EADDRINUSE: int; >>>> VAR EADDRNOTAVAIL: int; >>>> VAR EAGAIN: int; >>>> >>>> >>>> -- >>>> Dragi?a Duri? >> -- >> Dragi?a Duri? >> From mika at async.caltech.edu Wed May 20 08:44:08 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 19 May 2009 23:44:08 -0700 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: Your message of "Wed, 20 May 2009 06:33:52 -0000." Message-ID: <200905200644.n4K6i8x5088520@camembert.async.caltech.edu> These things are constant for a given binary distribution, aren't they? Can they be left to some sort of bootstrapping step on the target system, or at least (if cross-compiling) in an environment where target C headers are available? I mean printing out an M3 interface based on the C header's defined values. Mika Jay writes: > >> AF_UNIX > > >I'll try to make another pass through and put back unused constants, I guess. > > >At some point I erred toward removing unused stuff, because everything present was a correctness and portability issue. > >Though I mainly only did such removal with Cygwin, on the basis of it never really existing as a port so the initial version could be minimal. >I think, maybe I removed other? >I also removed userthread support from PPC_LINUX and maybe NetBSD/i386. >It was broken for all platforms and remains so for all Linux platforms. > > >Later I developed more portable techniques so it becomes more acceptable to leave stuff in, but convert it to be correct and portable. > > >Constants are easy. > > >> stuct_sockaddr_un structure > > >Structs though are problematic. >You end up wanting to wrap all the functions that use them. >Unless they are large structs and then you don't want the waste and you are either stuck, or you maybe wrap at the next level up. > > >This is an area actually where we still clone the headers, still work to do to make it portable and safe. > > >> make_dir > > >No I had forgotten but I see it searching the web. >You need the dots smushed out? > > > - Jay > > > >---------------------------------------- >> From: dragisha at m3w.org >> To: jay.krell at cornell.edu >> Date: Wed, 20 May 2009 07:41:34 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? >> >> Then please be complete :) >> >> AF_UNIX is missing, and also stuct_sockaddr_un structure. >> >> Yes I know how to add it. Yes you're pretty radical these days, so >> please do it your way so you don't have to edit my patch :) >> >> Also - you maybe remember make_dir problem I've reported few months (?) >> ago... I've narrowed it to situation where my earlier patch sets >> CM3_INSTALL_PREFIX. It started to happen some months after I patched it, >> and it happens only when shipping m3core. >> >> On Tue, 2009-05-19 at 14:37 -0700, jay.krell at cornell.edu wrote: >>> Yes a little unfortunate but very portable. >>> >>> - Jay (phone) >>> >>> On May 19, 2009, at 10:27 AM, Dragi?a Duri? wrote: >> >>> >>> >>>> VARIABLES? >>>> >>>> Now every1 who was using CASE with error results has to adapt one's >>>> code? >>>> >>>> What is rationale here? Portability? >>>> >>>> TIA! >>>> >>>> INTERFACE Uerror; >>>> >>>> FROM Ctypes IMPORT int; >>>> >>>> (* CONST *) >>>> VAR EACCES: int; >>>> VAR EADDRINUSE: int; >>>> VAR EADDRNOTAVAIL: int; >>>> VAR EAGAIN: int; >>>> >>>> >>>> -- >>>> Dragi?a Duri? >> -- >> Dragi?a Duri? >> From dragisha at m3w.org Wed May 20 08:48:52 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 20 May 2009 08:48:52 +0200 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: References: <1242754048.3061.1.camel@faramir.m3w.org> <37D5E493-DE98-4D7B-B96A-A8451A3FE3DC@hotmail.com> <1242798094.3061.7.camel@faramir.m3w.org> Message-ID: <1242802132.3061.9.camel@faramir.m3w.org> On Wed, 2009-05-20 at 06:33 +0000, Jay wrote: > > stuct_sockaddr_un structure > > > Structs though are problematic. > You end up wanting to wrap all the functions that use them. > Unless they are large structs and then you don't want the waste and > you are either stuck, or you maybe wrap at the next level up. > This struct uses same headers as struct_sockaddr_in - it's easy one. > > This is an area actually where we still clone the headers, still work > to do to make it portable and safe. > > > > make_dir > > > No I had forgotten but I see it searching the web. > You need the dots smushed out? I think so. I am out of cycle there, can you debug it with CM3_INSTALL_PREFIX set before buildship m3core? That is my problem case, narrowed as much as possible till now. > > -- Dragi?a Duri? From dragisha at m3w.org Wed May 20 08:50:26 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 20 May 2009 08:50:26 +0200 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: <200905200644.n4K6i8x5088520@camembert.async.caltech.edu> References: <200905200644.n4K6i8x5088520@camembert.async.caltech.edu> Message-ID: <1242802226.3061.11.camel@faramir.m3w.org> This is nice idea, but I think it means much more C code than current Uconstants... Actually, I like new approach. It's only it's (in)completeness that disturbs me :) On Tue, 2009-05-19 at 23:44 -0700, Mika Nystrom wrote: > These things are constant for a given binary distribution, aren't > they? Can they be left to some sort of bootstrapping step on the > target system, or at least (if cross-compiling) in an environment > where target C headers are available? > > I mean printing out an M3 interface based on the C header's defined > values. > > Mika -- Dragi?a Duri? From jay.krell at cornell.edu Wed May 20 09:21:40 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 20 May 2009 07:21:40 +0000 Subject: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? In-Reply-To: <1242802226.3061.11.camel@faramir.m3w.org> References: <200905200644.n4K6i8x5088520@camembert.async.caltech.edu> <1242802226.3061.11.camel@faramir.m3w.org> Message-ID: I think it's a similar amount of code. One is full of: printf("CONST FOO := %u\n", FOO); the other is: extern const int Interface__Foo = FOO; Both probably easily well factored with macros to like X(int,Interface,FOO) I don't know. Would the generated files get commited, or regenerated in every build? They'd need to be commited for cross builds. Or maybe fallback to a variable approach, with its source incompat. They should be regenerated to make sure they are correct. Maybe both? Regenerate them in native builds and compare for equality with the commited copy, and error if they vary? But again, it is easier for constants. You do need to devise a system to glean struct definitions. Or to verify the correctness of ones that you have. They don't have to be perfectly accurate. For example, you can use arrays of bytes for padding for fields whose presence you didn't anticipate. It'd be good to get alignment correct. That was sometimes wrong in the old system. But for stuff individuall heap allocated, no matter. It's probably not too difficult. Something like store the size/offset of every known field of a struct. Sort them by offset. Fill in padding when offset+size doesn't equal the next offset. In C you can pick integer types accurately enough by size and signedness, picking arbitrarily when any types are the "same". Using C++ overloading you can do better. I put some experiments here in scripts/config, and if you look through some of the history in m3core/src/unix you can see other simpler examples. It's a bit of a dilemna. But I also really didn't like the way it is. New platforms involved rewriting /usr/include, tedious, error prone, unsafe, and even mostly unused -- for all the parts I removed that people want back, there's probably a few times that much content I removed and nobody noticed. Actually it's even a little worse than I said. It isn't enough to get constants and structs. There's a real larger generality of inlines and I think #pragmas. Look at NetBSD. I think they use #pragmas to give everything an explicit and different name. stat is also notoriously complicated. C headers seem to provide far more of a common "source interface" than a common "binary appearance" (I don't call it "interface" since for example there is endian, calling convention, processor architecture..) - Jay ---------------------------------------- > From: dragisha at m3w.org > To: mika at async.caltech.edu > Date: Wed, 20 May 2009 08:50:26 +0200 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF? > > This is nice idea, but I think it means much more C code than current > Uconstants... > > Actually, I like new approach. It's only it's (in)completeness that > disturbs me :) > > On Tue, 2009-05-19 at 23:44 -0700, Mika Nystrom wrote: >> These things are constant for a given binary distribution, aren't >> they? Can they be left to some sort of bootstrapping step on the >> target system, or at least (if cross-compiling) in an environment >> where target C headers are available? >> >> I mean printing out an M3 interface based on the C header's defined >> values. >> >> Mika > -- > Dragi?a Duri? > From martinbishop at bellsouth.net Thu May 21 01:19:57 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Wed, 20 May 2009 18:19:57 -0500 Subject: [M3devel] subrange value not constant? In-Reply-To: <4A132568.4060206@bellsouth.net> References: <4A132568.4060206@bellsouth.net> Message-ID: <4A14901D.7090106@bellsouth.net> By the way, in case anyone cares, here's the proper code: PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = VAR range := max - min + 1; count := NEW(REF ARRAY OF INTEGER, range); z := 0; BEGIN FOR i := FIRST(a) TO LAST(a) DO count[a[i] - min] := count[a[i] - min] + 1; END; FOR i := min TO max DO WHILE (count[i - min] > 0) DO a[z] := i; INC(z); count[i - min] := count[i - min] - 1; END; END; END Sort; Martin Bishop wrote: > I've written this procedure (an implementation of counting sort): > > PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = > VAR count := ARRAY [min..max] OF INTEGER {0, ..}; > z := 0; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > count[i - min] := count[i - min] + 1; > END; > FOR i := min TO max DO > WHILE count[i - min] > 0 DO > a[z] := i; > INC(z); > count[i - min] := count[i - min] - 1; > END; > END; > END Sort; > > However, when I try to compile I get: > > "../Counting.m3", line 8: subrange lower bound is not constant > "../Counting.m3", line 8: subrange upper bound is not constant > > Line 8 is: > > VAR count := ARRAY [min..max] OF INTEGER {0, ..}; > > I don't see what's wrong? > > From mika at async.caltech.edu Thu May 21 07:27:43 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 20 May 2009 22:27:43 -0700 Subject: [M3devel] subrange value not constant? In-Reply-To: Your message of "Wed, 20 May 2009 18:19:57 CDT." <4A14901D.7090106@bellsouth.net> Message-ID: <200905210527.n4L5Rhwg038846@camembert.async.caltech.edu> Martin, you have one bug: you don't initialize count. Per 2.6.9 in the Green Book, NEW returns "an arbitrary value of its type" Also, for slightly more clarity, count can be a REF ARRAY OF CARDINAL. INC and DEC would make the code a bit easier to read, perhaps. Finally, you can dispense with min and max completely by just using min, initialized to a[0], and re-allocating the array whenever the new value is greater than min + NUMBER(count^) :-) But maybe you already know what min and max are by some means that doesn't involve scanning the array. Mika Martin Bishop writes: >By the way, in case anyone cares, here's the proper code: > >PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = > VAR range := max - min + 1; > count := NEW(REF ARRAY OF INTEGER, range); > z := 0; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > count[a[i] - min] := count[a[i] - min] + 1; > END; > FOR i := min TO max DO > WHILE (count[i - min] > 0) DO > a[z] := i; > INC(z); > count[i - min] := count[i - min] - 1; > END; > END; > END Sort; > >Martin Bishop wrote: >> I've written this procedure (an implementation of counting sort): >> >> PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >> z := 0; >> BEGIN >> FOR i := FIRST(a) TO LAST(a) DO >> count[i - min] := count[i - min] + 1; >> END; >> FOR i := min TO max DO >> WHILE count[i - min] > 0 DO >> a[z] := i; >> INC(z); >> count[i - min] := count[i - min] - 1; >> END; >> END; >> END Sort; >> >> However, when I try to compile I get: >> >> "../Counting.m3", line 8: subrange lower bound is not constant >> "../Counting.m3", line 8: subrange upper bound is not constant >> >> Line 8 is: >> >> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >> >> I don't see what's wrong? >> >> From jay.krell at cornell.edu Thu May 21 08:43:56 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 21 May 2009 06:43:56 +0000 Subject: [M3devel] subrange value not constant? In-Reply-To: <200905210527.n4L5Rhwg038846@camembert.async.caltech.edu> References: Your message of "Wed, 20 May 2009 18:19:57 CDT." <4A14901D.7090106@bellsouth.net> <200905210527.n4L5Rhwg038846@camembert.async.caltech.edu> Message-ID: INC and DEC? Oh for += and -=. It's not just clarity though, it is also to avoid the cost of evaluating the expression twice. - Jay ---------------------------------------- > To: martinbishop at bellsouth.net > Date: Wed, 20 May 2009 22:27:43 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] subrange value not constant? > > > Martin, you have one bug: you don't initialize count. Per 2.6.9 in the > Green Book, NEW returns "an arbitrary value of its type" > > Also, for slightly more clarity, count can be a REF ARRAY OF CARDINAL. > > INC and DEC would make the code a bit easier to read, perhaps. > > Finally, you can dispense with min and max completely by just using > min, initialized to a[0], and re-allocating the array whenever the > new value is greater than min + NUMBER(count^) :-) But maybe you > already know what min and max are by some means that doesn't involve > scanning the array. > > Mika > > > > > Martin Bishop writes: >>By the way, in case anyone cares, here's the proper code: >> >>PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >> VAR range := max - min + 1; >> count := NEW(REF ARRAY OF INTEGER, range); >> z := 0; >> BEGIN >> FOR i := FIRST(a) TO LAST(a) DO >> count[a[i] - min] := count[a[i] - min] + 1; >> END; >> FOR i := min TO max DO >> WHILE (count[i - min]> 0) DO >> a[z] := i; >> INC(z); >> count[i - min] := count[i - min] - 1; >> END; >> END; >> END Sort; >> >>Martin Bishop wrote: >>> I've written this procedure (an implementation of counting sort): >>> >>> PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >>> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >>> z := 0; >>> BEGIN >>> FOR i := FIRST(a) TO LAST(a) DO >>> count[i - min] := count[i - min] + 1; >>> END; >>> FOR i := min TO max DO >>> WHILE count[i - min]> 0 DO >>> a[z] := i; >>> INC(z); >>> count[i - min] := count[i - min] - 1; >>> END; >>> END; >>> END Sort; >>> >>> However, when I try to compile I get: >>> >>> "../Counting.m3", line 8: subrange lower bound is not constant >>> "../Counting.m3", line 8: subrange upper bound is not constant >>> >>> Line 8 is: >>> >>> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >>> >>> I don't see what's wrong? >>> >>> From mika at async.caltech.edu Thu May 21 09:34:48 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 21 May 2009 00:34:48 -0700 Subject: [M3devel] subrange value not constant? In-Reply-To: Your message of "Thu, 21 May 2009 06:43:56 -0000." Message-ID: <200905210734.n4L7YmIA043161@camembert.async.caltech.edu> In general you're right but often, such expressions generate precisely the same assembly on my machine, so I think it's mostly a clarity issue. I don't even have to use -O. Hmm, it's possible this is only true if the compiler can statically determine that the range checks are OK. The range checks inserted by cm3 seem to inhibit the optimization (i.e., the range checks are carried out for every "evaluation"). Mika (226)rover:~/src>cat P.m3 MODULE P EXPORTS Main; VAR x : ARRAY [0..10] OF INTEGER; PROCEDURE P() = BEGIN INC(x[5]) END P; PROCEDURE Q() = BEGIN x[5] := x[5]+1 END Q; BEGIN END P. (227)rover:~/src>cm3 --- building in ../FreeBSD4 --- new source -> compiling P.m3 "../src/P.m3", line 5: warning: not used (P) "../src/P.m3", line 8: warning: not used (Q) 2 warnings encountered new "P.mo" -> linking prog (228)rover:~/src>objdump --disassemble ../FreeBSD4/P.mo ../FreeBSD4/P.mo: file format elf32-i386-freebsd Disassembly of section .text: 00000000 : 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: a1 88 00 00 00 mov 0x88,%eax 8: 8d 50 01 lea 0x1(%eax),%edx b: a1 88 00 00 00 mov 0x88,%eax 10: 83 e0 00 and $0x0,%eax 13: 09 d0 or %edx,%eax 15: a3 88 00 00 00 mov %eax,0x88 1a: 5d pop %ebp 1b: c3 ret 0000001c : 1c: 55 push %ebp 1d: 89 e5 mov %esp,%ebp 1f: a1 88 00 00 00 mov 0x88,%eax 24: 8d 50 01 lea 0x1(%eax),%edx 27: a1 88 00 00 00 mov 0x88,%eax 2c: 83 e0 00 and $0x0,%eax 2f: 09 d0 or %edx,%eax 31: a3 88 00 00 00 mov %eax,0x88 36: 5d pop %ebp 37: c3 ret 00000038 : 38: 55 push %ebp 39: 89 e5 mov %esp,%ebp 3b: 83 ec 04 sub $0x4,%esp 3e: 8b 45 08 mov 0x8(%ebp),%eax 41: b8 40 00 00 00 mov $0x40,%eax 46: c9 leave 47: c3 ret Jay writes: > >INC and DEC? >Oh for += and -=. > >It's not just clarity though, it is also to avoid the cost of evaluating the expression twice. > > - Jay > > >---------------------------------------- >> To: martinbishop at bellsouth.net >> Date: Wed, 20 May 2009 22:27:43 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] subrange value not constant? >> >> >> Martin, you have one bug: you don't initialize count. Per 2.6.9 in the >> Green Book, NEW returns "an arbitrary value of its type" >> >> Also, for slightly more clarity, count can be a REF ARRAY OF CARDINAL. >> >> INC and DEC would make the code a bit easier to read, perhaps. >> >> Finally, you can dispense with min and max completely by just using >> min, initialized to a[0], and re-allocating the array whenever the >> new value is greater than min + NUMBER(count^) :-) But maybe you >> already know what min and max are by some means that doesn't involve >> scanning the array. >> >> Mika >> >> >> >> >> Martin Bishop writes: >>>By the way, in case anyone cares, here's the proper code: >>> >>>PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >>> VAR range := max - min + 1; >>> count := NEW(REF ARRAY OF INTEGER, range); >>> z := 0; >>> BEGIN >>> FOR i := FIRST(a) TO LAST(a) DO >>> count[a[i] - min] := count[a[i] - min] + 1; >>> END; >>> FOR i := min TO max DO >>> WHILE (count[i - min]> 0) DO >>> a[z] := i; >>> INC(z); >>> count[i - min] := count[i - min] - 1; >>> END; >>> END; >>> END Sort; >>> >>>Martin Bishop wrote: >>>> I've written this procedure (an implementation of counting sort): >>>> >>>> PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >>>> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >>>> z := 0; >>>> BEGIN >>>> FOR i := FIRST(a) TO LAST(a) DO >>>> count[i - min] := count[i - min] + 1; >>>> END; >>>> FOR i := min TO max DO >>>> WHILE count[i - min]> 0 DO >>>> a[z] := i; >>>> INC(z); >>>> count[i - min] := count[i - min] - 1; >>>> END; >>>> END; >>>> END Sort; >>>> >>>> However, when I try to compile I get: >>>> >>>> "../Counting.m3", line 8: subrange lower bound is not constant >>>> "../Counting.m3", line 8: subrange upper bound is not constant >>>> >>>> Line 8 is: >>>> >>>> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >>>> >>>> I don't see what's wrong? >>>> >>>> From martinbishop at bellsouth.net Thu May 21 20:08:13 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 21 May 2009 13:08:13 -0500 Subject: [M3devel] subrange value not constant? In-Reply-To: <200905210527.n4L5Rhwg038846@camembert.async.caltech.edu> References: <200905210527.n4L5Rhwg038846@camembert.async.caltech.edu> Message-ID: <4A15988D.7030305@bellsouth.net> Hmm, good point about count. Originally I did initialize to 0, but in the process of trying to get it to work, I must have removed it. As for min and max, yes the point of the Counting Sort (http://en.wikipedia.org/wiki/Counting_sort) is that min and max are known. Thanks for the help :) Mika Nystrom wrote: > Martin, you have one bug: you don't initialize count. Per 2.6.9 in the > Green Book, NEW returns "an arbitrary value of its type" > > Also, for slightly more clarity, count can be a REF ARRAY OF CARDINAL. > > INC and DEC would make the code a bit easier to read, perhaps. > > Finally, you can dispense with min and max completely by just using > min, initialized to a[0], and re-allocating the array whenever the > new value is greater than min + NUMBER(count^) :-) But maybe you > already know what min and max are by some means that doesn't involve > scanning the array. > > Mika > > > > > Martin Bishop writes: > >> By the way, in case anyone cares, here's the proper code: >> >> PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >> VAR range := max - min + 1; >> count := NEW(REF ARRAY OF INTEGER, range); >> z := 0; >> BEGIN >> FOR i := FIRST(a) TO LAST(a) DO >> count[a[i] - min] := count[a[i] - min] + 1; >> END; >> FOR i := min TO max DO >> WHILE (count[i - min] > 0) DO >> a[z] := i; >> INC(z); >> count[i - min] := count[i - min] - 1; >> END; >> END; >> END Sort; >> >> Martin Bishop wrote: >> >>> I've written this procedure (an implementation of counting sort): >>> >>> PROCEDURE Sort(VAR a: ARRAY OF INTEGER; min, max: INTEGER) = >>> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >>> z := 0; >>> BEGIN >>> FOR i := FIRST(a) TO LAST(a) DO >>> count[i - min] := count[i - min] + 1; >>> END; >>> FOR i := min TO max DO >>> WHILE count[i - min] > 0 DO >>> a[z] := i; >>> INC(z); >>> count[i - min] := count[i - min] - 1; >>> END; >>> END; >>> END Sort; >>> >>> However, when I try to compile I get: >>> >>> "../Counting.m3", line 8: subrange lower bound is not constant >>> "../Counting.m3", line 8: subrange upper bound is not constant >>> >>> Line 8 is: >>> >>> VAR count := ARRAY [min..max] OF INTEGER {0, ..}; >>> >>> I don't see what's wrong? >>> >>> >>> > > From mika at async.caltech.edu Thu May 21 20:39:57 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 21 May 2009 11:39:57 -0700 Subject: [M3devel] subrange value not constant? In-Reply-To: Your message of "Thu, 21 May 2009 13:08:13 CDT." <4A15988D.7030305@bellsouth.net> Message-ID: <200905211839.n4LIdv8W068308@camembert.async.caltech.edu> Martin Bishop writes: >Hmm, good point about count. Originally I did initialize to 0, but in >the process of trying to get it to work, I must have removed it. > >As for min and max, yes the point of the Counting Sort >(http://en.wikipedia.org/wiki/Counting_sort) is that min and max are known. > >Thanks for the help :) Well what I mean is this. Assume you know that counting sort is appropriate for your data, i.e., that n + k <= n log n for the data in question (using Wikipedia's notation). There are two approaches I can think of for implementing the sort. 1. Figure out min and max before calling Sort, by a linear scan, or some other mechanism. If this mechanism adds any code at all, it's likely to add O(n) runtime to the algorithm (because you are making it look at every element before it goes in). 2. Dispense with min and max and instead generate these dynamically within the sort. Initialize them to the first element, and re-allocate the array when you see any element outside the current range. This approach also has O(n) (amortized) cost. So you'd do, say, PROCEDURE Sort(VAR a : ARRAY OF INTEGER) = PROCEDURE ReLimit(newmin, newmax : INTEGER) = BEGIN WITH newcount = NEW(REF ARRAY OF CARDINAL, newmax - newmin + 1) DO FOR i := FIRST(newcount^) TO min-newmin-1 DO newcount[i] := 0 END; FOR i := newmax-max TO LAST(newcount^) DO newcount[i] := 0 END; SUBARRAY(newcount^, min-newmin, max-min+1) := count^; END; count := newcount; min := newmin; max := newmax END ReLimit; PROCEDURE Tally(v : INTEGER) = CONST GrowFactor = 2; BEGIN IF v < min THEN ReLimit(min-(min-v)*GrowFactor, max) ELSIF v > max THEN ReLimit(min, max+(v-max)*GrowFactor) END; INC(count[v-min]) END Tally; PROCEDURE Initialize() = BEGIN min := a[0]; max := a[0]; count := NEW(REF ARRAY OF CARDINAL, 1); END Initialize; PROCEDURE Reconstruct() = VAR ai := FIRST(a); BEGIN FOR i := FIRST(count^) TO LAST(count^) DO WHILE count[i] > 0 DO a[ai] := i+min; DEC(count[i]); INC(ai) END END END Reconstruct; VAR min, max : INTEGER; count : REF ARRAY OF INTEGER; BEGIN Initialize(); FOR i := FIRST(a) TO LAST(a) DO Tally(a[i]) END; Reconstruct() END Sort; The asymptotic runtime of this version is the same as yours and it encapsulates all the min, max knowledge, giving a simpler interface, and it usually means you can remove some min, max code from the caller. Modula-3 is really good for this sort of coding. I find that the extra effort of simplifying interfaces and making sure the code works for any input is paid off handsomely and very quickly... As it says in the Algol-60 report, the code above "has not been run on a computer". Mika From jay.krell at cornell.edu Fri May 22 02:09:46 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 22 May 2009 00:09:46 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: Yes I will test some variations, esp. targets not historically affected by the bitfield behavior but that haven't passed -O3 yet, since they are easier for a few reasons and more numerous (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.) ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I haven't booted the machine in months and it is very slow (my /plan/ is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX}, but it's slow going, I had difficulty installing some of them, only got Irix and OpenBSD running, and some of those combinations are invalid e.g. MIPS32_OPENBSD -- OpenBSD never has "biarch" systems, only ever pure 32bit or pure 64bit). Moving ARM_DARWIN forward to 4.3 isn't impossible but I think easier to track and wait for Apple here than anything else. I ran an AMD64_LINUX test on birch but didn't wait for it. SPARC32_LINUX also has a wierd problem that I can retest. When I compile with -fPIC I get I think crashes during initialization. I haven't figured out the problem. Without -fPIC works ok, even for shared libraries, surprising. - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: m3_load/store using bitfields for everything > Date: Fri, 22 May 2009 09:45:08 +1000 > > Jay, can you try these again with the latest fix I put in place? > > On 20 May 2009, at 09:14, Jay wrote: > >> >> m3_load/store using bitfields for everything caused module-global >> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >> around that by declaring that the module-globals are at least of >> size 2 * biggest_alignment. >> >> It caused module-global references to disappear on ARM_DARWIN as well. >> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >> occur and PutChar eventually failed an array bounds check. >> >> Is this just too fragile and the failsafe form should always be used? >> >> Or, it fails spectacularly consistently enough that it must also be >> working consistently enough and leave it? >> >> Would "component ref" (ie: struct) and declaring more type >> information about module segments be a good compromise maybe? >> Probably. >> >> - Jay > From hosking at cs.purdue.edu Fri May 22 01:45:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 22 May 2009 09:45:08 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: Jay, can you try these again with the latest fix I put in place? On 20 May 2009, at 09:14, Jay wrote: > > m3_load/store using bitfields for everything caused module-global > references to disappear on MIPS64_OPENBSD (all MIPS?). I worked > around that by declaring that the module-globals are at least of > size 2 * biggest_alignment. > > It caused module-global references to disappear on ARM_DARWIN as well. > I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't > occur and PutChar eventually failed an array bounds check. > > Is this just too fragile and the failsafe form should always be used? > > Or, it fails spectacularly consistently enough that it must also be > working consistently enough and leave it? > > Would "component ref" (ie: struct) and declaring more type > information about module segments be a good compromise maybe? > Probably. > > - Jay From hosking at cs.purdue.edu Fri May 22 03:18:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 22 May 2009 11:18:05 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> PPC_DARWIN did work for me at one point. I can check it. On 22 May 2009, at 10:09, Jay wrote: > > Yes I will test some variations, esp. targets not historically > affected by the bitfield behavior but that haven't passed -O3 yet, > since they are easier for a few reasons and more numerous > (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.) > > > ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I > haven't booted the machine in months and it is very slow (my /plan/ > is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX}, but it's > slow going, I had difficulty installing some of them, only got Irix > and OpenBSD running, and some of those combinations are invalid e.g. > MIPS32_OPENBSD -- OpenBSD never > has "biarch" systems, only ever pure 32bit or pure 64bit). > > > Moving ARM_DARWIN forward to 4.3 isn't impossible but I think easier > to track and wait for Apple here than anything else. > > > I ran an AMD64_LINUX test on birch but didn't wait for it. > > > SPARC32_LINUX also has a wierd problem that I can retest. > When I compile with -fPIC I get I think crashes during initialization. > I haven't figured out the problem. > Without -fPIC works ok, even for shared libraries, surprising. > > > - Jay > > > ---------------------------------------- >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: m3_load/store using bitfields for everything >> Date: Fri, 22 May 2009 09:45:08 +1000 >> >> Jay, can you try these again with the latest fix I put in place? >> >> On 20 May 2009, at 09:14, Jay wrote: >> >>> >>> m3_load/store using bitfields for everything caused module-global >>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >>> around that by declaring that the module-globals are at least of >>> size 2 * biggest_alignment. >>> >>> It caused module-global references to disappear on ARM_DARWIN as >>> well. >>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >>> occur and PutChar eventually failed an array bounds check. >>> >>> Is this just too fragile and the failsafe form should always be >>> used? >>> >>> Or, it fails spectacularly consistently enough that it must also be >>> working consistently enough and leave it? >>> >>> Would "component ref" (ie: struct) and declaring more type >>> information about module segments be a good compromise maybe? >>> Probably. >>> >>> - Jay >> From hosking at cs.purdue.edu Fri May 22 03:38:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 22 May 2009 11:38:10 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> References: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> Message-ID: <25294219-236C-474F-874F-22B0B8B9A9F6@cs.purdue.edu> I think my old PPC_DARWIN installs are pre-LONGINT. Is there a LONGINT-capable bootstrap archive for PPC_DARWIN lying around anywhere? On 22 May 2009, at 11:18, Tony Hosking wrote: > PPC_DARWIN did work for me at one point. I can check it. > > On 22 May 2009, at 10:09, Jay wrote: > >> >> Yes I will test some variations, esp. targets not historically >> affected by the bitfield behavior but that haven't passed -O3 yet, >> since they are easier for a few reasons and more numerous >> (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.) >> >> >> ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I >> haven't booted the machine in months and it is very slow (my /plan/ >> is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX}, but it's >> slow going, I had difficulty installing some of them, only got Irix >> and OpenBSD running, and some of those combinations are invalid >> e.g. MIPS32_OPENBSD -- OpenBSD never >> has "biarch" systems, only ever pure 32bit or pure 64bit). >> >> >> Moving ARM_DARWIN forward to 4.3 isn't impossible but I think >> easier to track and wait for Apple here than anything else. >> >> >> I ran an AMD64_LINUX test on birch but didn't wait for it. >> >> >> SPARC32_LINUX also has a wierd problem that I can retest. >> When I compile with -fPIC I get I think crashes during >> initialization. >> I haven't figured out the problem. >> Without -fPIC works ok, even for shared libraries, surprising. >> >> >> - Jay >> >> >> ---------------------------------------- >>> CC: m3devel at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: m3_load/store using bitfields for everything >>> Date: Fri, 22 May 2009 09:45:08 +1000 >>> >>> Jay, can you try these again with the latest fix I put in place? >>> >>> On 20 May 2009, at 09:14, Jay wrote: >>> >>>> >>>> m3_load/store using bitfields for everything caused module-global >>>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >>>> around that by declaring that the module-globals are at least of >>>> size 2 * biggest_alignment. >>>> >>>> It caused module-global references to disappear on ARM_DARWIN as >>>> well. >>>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >>>> occur and PutChar eventually failed an array bounds check. >>>> >>>> Is this just too fragile and the failsafe form should always be >>>> used? >>>> >>>> Or, it fails spectacularly consistently enough that it must also be >>>> working consistently enough and leave it? >>>> >>>> Would "component ref" (ie: struct) and declaring more type >>>> information about module segments be a good compromise maybe? >>>> Probably. >>>> >>>> - Jay >>> From hosking at cs.purdue.edu Fri May 22 03:41:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 22 May 2009 11:41:25 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <25294219-236C-474F-874F-22B0B8B9A9F6@cs.purdue.edu> References: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> <25294219-236C-474F-874F-22B0B8B9A9F6@cs.purdue.edu> Message-ID: <70E5C90F-6795-4D3F-A776-B045372D31C9@cs.purdue.edu> Don't worry --- I found one. On 22 May 2009, at 11:38, Tony Hosking wrote: > I think my old PPC_DARWIN installs are pre-LONGINT. Is there a > LONGINT-capable bootstrap archive for PPC_DARWIN lying around > anywhere? > > On 22 May 2009, at 11:18, Tony Hosking wrote: > >> PPC_DARWIN did work for me at one point. I can check it. >> >> On 22 May 2009, at 10:09, Jay wrote: >> >>> >>> Yes I will test some variations, esp. targets not historically >>> affected by the bitfield behavior but that haven't passed -O3 yet, >>> since they are easier for a few reasons and more numerous >>> (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.) >>> >>> >>> ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I >>> haven't booted the machine in months and it is very slow (my / >>> plan/ is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX}, >>> but it's slow going, I had difficulty installing some of them, >>> only got Irix and OpenBSD running, and some of those combinations >>> are invalid e.g. MIPS32_OPENBSD -- OpenBSD never >>> has "biarch" systems, only ever pure 32bit or pure 64bit). >>> >>> >>> Moving ARM_DARWIN forward to 4.3 isn't impossible but I think >>> easier to track and wait for Apple here than anything else. >>> >>> >>> I ran an AMD64_LINUX test on birch but didn't wait for it. >>> >>> >>> SPARC32_LINUX also has a wierd problem that I can retest. >>> When I compile with -fPIC I get I think crashes during >>> initialization. >>> I haven't figured out the problem. >>> Without -fPIC works ok, even for shared libraries, surprising. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> CC: m3devel at elegosoft.com >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Subject: Re: m3_load/store using bitfields for everything >>>> Date: Fri, 22 May 2009 09:45:08 +1000 >>>> >>>> Jay, can you try these again with the latest fix I put in place? >>>> >>>> On 20 May 2009, at 09:14, Jay wrote: >>>> >>>>> >>>>> m3_load/store using bitfields for everything caused module-global >>>>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >>>>> around that by declaring that the module-globals are at least of >>>>> size 2 * biggest_alignment. >>>>> >>>>> It caused module-global references to disappear on ARM_DARWIN as >>>>> well. >>>>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 >>>>> didn't >>>>> occur and PutChar eventually failed an array bounds check. >>>>> >>>>> Is this just too fragile and the failsafe form should always be >>>>> used? >>>>> >>>>> Or, it fails spectacularly consistently enough that it must also >>>>> be >>>>> working consistently enough and leave it? >>>>> >>>>> Would "component ref" (ie: struct) and declaring more type >>>>> information about module segments be a good compromise maybe? >>>>> Probably. >>>>> >>>>> - Jay >>>> From jay.krell at cornell.edu Fri May 22 03:48:50 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 21 May 2009 18:48:50 -0700 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> References: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> Message-ID: <5AEE6485-5622-4797-B1D5-6282E8BABDC7@hotmail.com> Didn't mean to imply it not working, but I don't think I have tried it yet. - Jay (phone) On May 21, 2009, at 6:18 PM, Tony Hosking wrote: > PPC_DARWIN did work for me at one point. I can check it. > > On 22 May 2009, at 10:09, Jay wrote: > >> >> Yes I will test some variations, esp. targets not historically >> affected by the bitfield behavior but that haven't passed -O3 yet, >> since they are easier for a few reasons and more numerous >> (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.) >> >> >> ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I >> haven't booted the machine in months and it is very slow (my /plan/ >> is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX}, but it's >> slow going, I had difficulty installing some of them, only got Irix >> and OpenBSD running, and some of those combinations are invalid >> e.g. MIPS32_OPENBSD -- OpenBSD never >> has "biarch" systems, only ever pure 32bit or pure 64bit). >> >> >> Moving ARM_DARWIN forward to 4.3 isn't impossible but I think >> easier to track and wait for Apple here than anything else. >> >> >> I ran an AMD64_LINUX test on birch but didn't wait for it. >> >> >> SPARC32_LINUX also has a wierd problem that I can retest. >> When I compile with -fPIC I get I think crashes during >> initialization. >> I haven't figured out the problem. >> Without -fPIC works ok, even for shared libraries, surprising. >> >> >> - Jay >> >> >> ---------------------------------------- >>> CC: m3devel at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: m3_load/store using bitfields for everything >>> Date: Fri, 22 May 2009 09:45:08 +1000 >>> >>> Jay, can you try these again with the latest fix I put in place? >>> >>> On 20 May 2009, at 09:14, Jay wrote: >>> >>>> >>>> m3_load/store using bitfields for everything caused module-global >>>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >>>> around that by declaring that the module-globals are at least of >>>> size 2 * biggest_alignment. >>>> >>>> It caused module-global references to disappear on ARM_DARWIN as >>>> well. >>>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >>>> occur and PutChar eventually failed an array bounds check. >>>> >>>> Is this just too fragile and the failsafe form should always be >>>> used? >>>> >>>> Or, it fails spectacularly consistently enough that it must also be >>>> working consistently enough and leave it? >>>> >>>> Would "component ref" (ie: struct) and declaring more type >>>> information about module segments be a good compromise maybe? >>>> Probably. >>>> >>>> - Jay >>> > > From jay.krell at cornell.edu Fri May 22 03:58:32 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 21 May 2009 18:58:32 -0700 Subject: [M3devel] Tinderbox Message-ID: There is out of diskspace error in tinderbox. - Jay (phone) From jay.krell at cornell.edu Fri May 22 07:28:09 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 22 May 2009 05:28:09 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <70E5C90F-6795-4D3F-A776-B045372D31C9@cs.purdue.edu> References: <5BDC9B72-A53A-4EBC-9802-F6B8169522A4@cs.purdue.edu> <25294219-236C-474F-874F-22B0B8B9A9F6@cs.purdue.edu> <70E5C90F-6795-4D3F-A776-B045372D31C9@cs.purdue.edu> Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives/index.html has one and really cross-building is not a terrible option, I've done it many times including recently (ARM_DARWIN). cd m3-sys/m3cc cm3 -DM3CC_TARGET=foo cd scripts/python ./boot1.py foo gives you cm3-boot-foo-1.tar.gz copy that to "target" machine (aka machine with C compiler/linker) extract it there cd cm3-boot-foo-1 make That gives you cm3, with which you can build the rest of the system. boot1.py recognizes target names on the command line (using a builtin list and formating them processor/os combinations). My config files probe around for a viable backend, which coincides with where -DM3CC_TARGET puts it. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Fri, 22 May 2009 11:41:25 +1000 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] m3_load/store using bitfields for everything > > Don't worry --- I found one. > > On 22 May 2009, at 11:38, Tony Hosking wrote: > >> I think my old PPC_DARWIN installs are pre-LONGINT. Is there a >> LONGINT-capable bootstrap archive for PPC_DARWIN lying around >> anywhere? >> >> On 22 May 2009, at 11:18, Tony Hosking wrote: >> >>> PPC_DARWIN did work for me at one point. I can check it. >>> >>> On 22 May 2009, at 10:09, Jay wrote: >>> >>>> >>>> Yes I will test some variations, esp. targets not historically >>>> affected by the bitfield behavior but that haven't passed -O3 yet, >>>> since they are easier for a few reasons and more numerous >>>> (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.) >>>> >>>> >>>> ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I >>>> haven't booted the machine in months and it is very slow (my / >>>> plan/ is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX}, >>>> but it's slow going, I had difficulty installing some of them, >>>> only got Irix and OpenBSD running, and some of those combinations >>>> are invalid e.g. MIPS32_OPENBSD -- OpenBSD never >>>> has "biarch" systems, only ever pure 32bit or pure 64bit). >>>> >>>> >>>> Moving ARM_DARWIN forward to 4.3 isn't impossible but I think >>>> easier to track and wait for Apple here than anything else. >>>> >>>> >>>> I ran an AMD64_LINUX test on birch but didn't wait for it. >>>> >>>> >>>> SPARC32_LINUX also has a wierd problem that I can retest. >>>> When I compile with -fPIC I get I think crashes during >>>> initialization. >>>> I haven't figured out the problem. >>>> Without -fPIC works ok, even for shared libraries, surprising. >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> CC: m3devel at elegosoft.com >>>>> From: hosking at cs.purdue.edu >>>>> To: jay.krell at cornell.edu >>>>> Subject: Re: m3_load/store using bitfields for everything >>>>> Date: Fri, 22 May 2009 09:45:08 +1000 >>>>> >>>>> Jay, can you try these again with the latest fix I put in place? >>>>> >>>>> On 20 May 2009, at 09:14, Jay wrote: >>>>> >>>>>> >>>>>> m3_load/store using bitfields for everything caused module-global >>>>>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >>>>>> around that by declaring that the module-globals are at least of >>>>>> size 2 * biggest_alignment. >>>>>> >>>>>> It caused module-global references to disappear on ARM_DARWIN as >>>>>> well. >>>>>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 >>>>>> didn't >>>>>> occur and PutChar eventually failed an array bounds check. >>>>>> >>>>>> Is this just too fragile and the failsafe form should always be >>>>>> used? >>>>>> >>>>>> Or, it fails spectacularly consistently enough that it must also >>>>>> be >>>>>> working consistently enough and leave it? >>>>>> >>>>>> Would "component ref" (ie: struct) and declaring more type >>>>>> information about module segments be a good compromise maybe? >>>>>> Probably. >>>>>> >>>>>> - Jay >>>>> > From jay.krell at cornell.edu Fri May 22 13:17:48 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 22 May 2009 11:17:48 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: Looks like AMD64_LINUX is still failing similarly to how it was (NOT bitfield/global related, but optimization related). -O2 also crashes. -O1 does not. birch [~/dev2/cm3/m3-libs/slisp/AMD64_LINUX] jkrell % gdb --args cm3cg SLisp.mc -O3 -quiet GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /home/jkrell/cm3/bin/cm3cg SLisp.mc -O3 -quiet cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack exception handli ng Program received signal SIGSEGV, Segmentation fault. 0x00000000006814f4 in remove_phi_node (phi=0x2b17b7ac7100, prev=0x0, release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461 461 *loc != phi; (gdb) bt #0 0x00000000006814f4 in remove_phi_node (phi=0x2b17b7ac7100, prev=0x0, release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461 #1 0x00000000007039fb in remove_dead_inserted_code () at ../../gcc/gcc/tree-ssa-pre.c:3775 #2 0x00000000007042b2 in execute_pre (do_fre=0 '\0') at ../../gcc/gcc/tree-ssa-pre.c:3975 #3 0x00000000007042cc in do_pre () at ../../gcc/gcc/tree-ssa-pre.c:3987 #4 0x000000000058be1b in execute_one_pass (pass=0xe46860) at ../../gcc/gcc/passes.c:1122 #5 0x000000000058bf73 in execute_pass_list (pass=0xe46860) at ../../gcc/gcc/passes.c:1175 #6 0x000000000058bf91 in execute_pass_list (pass=0xe45420) at ../../gcc/gcc/passes.c:1176 #7 0x0000000000676bbd in tree_rest_of_compilation (fndecl=0x2b17b624b750) at ../../gcc/gcc/tree-optimize.c:404 #8 0x00000000007cee01 in cgraph_expand_function (node=0x2b17b6663200) at ../../gcc/gcc/cgraphunit.c:1157 #9 0x00000000007cefae in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1220 #10 0x00000000007cf561 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1427 #11 0x000000000040f875 in m3_parse_file (xx=0) at ../../gcc/gcc/m3cg/parse.c:5220 #12 0x000000000062feec in compile_file () at ../../gcc/gcc/toplev.c:1042 #13 0x0000000000631a26 in do_compile () at ../../gcc/gcc/toplev.c:2247 #14 0x0000000000631a8a in toplev_main (argc=4, argv=0x7ffff4c3a7f8) at ../../gcc/gcc/toplev.c:2279 #15 0x0000000000417ecf in main (argc=4, argv=0x7ffff4c3a7f8) at ../../gcc/gcc/main.c:35 (gdb) I'm pretty sure this is with current code. - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: m3_load/store using bitfields for everything > Date: Fri, 22 May 2009 09:45:08 +1000 > > Jay, can you try these again with the latest fix I put in place? > > On 20 May 2009, at 09:14, Jay wrote: > >> >> m3_load/store using bitfields for everything caused module-global >> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked >> around that by declaring that the module-globals are at least of >> size 2 * biggest_alignment. >> >> It caused module-global references to disappear on ARM_DARWIN as well. >> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't >> occur and PutChar eventually failed an array bounds check. >> >> Is this just too fragile and the failsafe form should always be used? >> >> Or, it fails spectacularly consistently enough that it must also be >> working consistently enough and leave it? >> >> Would "component ref" (ie: struct) and declaring more type >> information about module segments be a good compromise maybe? >> Probably. >> >> - Jay > From dragisha at m3w.org Sat May 23 09:12:28 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 23 May 2009 09:12:28 +0200 Subject: [M3devel] ".." in INSTALL_ROOT derivates, LINUXLIBC6 & AMD64_LINUX, not serious but nasty one Message-ID: <1243062748.6410.37.camel@faramir.m3w.org> When ran with CM3_INSTALL_PREFIX set, cm3 -ship fails for first package being shipped. Repeating cm3 -ship with same package, or any other, succeeds, and all subsequent cm3 -ship are ok. Most important thing which differs such "cm3 -ship" from others is unpopulated directory tree. I've tracked this % export CM3_INSTALL_PREFIX=/tmp/123 % cm3 -ship ... . => /usr/local/cm3/pkg/pdf/LINUXLIBC6 .M3EXPORTS libhm3pdf.so.5 "/home/dragisha/m3/pdf/LINUXLIBC6/.M3SHIP", line 5: quake runtime error: unable to create directory "/tmp/123/usr/local/cm3/bin/..": errno=17 to problem with non-existent /tmp/123/usr/local/cm3/bin. This first unsuccessful cm3 -ship creates it, and after that cm3 -ship works. One fix is to "mkdir -p" this folder before first shipping, and my first was to sed .M3SHIP a bit... Neither one is too elegant. -- Dragi?a Duri? From mika at async.caltech.edu Sat May 23 22:34:16 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 23 May 2009 13:34:16 -0700 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? Message-ID: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> Hi Modula-3ers, especially Tony, I'm seeing the following behavior a lot in a program I'm running: #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. ) at ../src/runtime/common/RTCollector.m3:674 #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. ) at ../src/runtime/common/RTCollector.m3:2271 #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. ) at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 Is it normal for CheckLoadTracedRef to make system calls? Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): PROCEDURE Get ( tbl : Default; READONLY k : Key.T; VAR(*OUT*) v : Value.T): BOOLEAN = VAR x : Node := tbl.h.hi; cmp : Cmp; BEGIN WHILE (x # NIL) DO cmp := tbl.keyCompare (k, x.key); IF cmp = 0 THEN v := x.value; RETURN TRUE; END; IF (cmp < 0) THEN x := x.lo; (* line 145 *) ELSE x := x.hi; END; END; RETURN FALSE; END Get; where Node is defined as TYPE Node = REF RECORD key : Key.T; value : Value.T; lo : Node := NIL; hi : Node := NIL; priority: INTEGER (* random num; tree is a heap on these *) END; It seems odd to me that, under these circumstances, x := x.lo would cause any sort of checking activity... I'm using a CM3 that's about a month old, on FreeBSD4. Mika P.S. Needless to say, the code in question runs about 10x faster under PM3 than with this relatively new CM3... but my m3gdb is having trouble with PM3's LONGREALs for some reason. From jay.krell at cornell.edu Sat May 23 23:38:33 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 23 May 2009 21:38:33 +0000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> References: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> Message-ID: It does appear to be making policy decisions based on elapsed time, not just collecting times to report. Does gettimeofday on your system make a syscall or read a global? - Jay Maybe since the intent is just to process one object/page, the CollectorOn/Off calls can be replaced by just collectorOn := TRUE or FALSE ? For CollectorOff that isn't clear since it does more, but CollectorOn is just that plus time recording plus an assertion. Still, given that the intent is some limited processing, I think the time collection could be avoided and might not even be a good thing? - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Sat, 23 May 2009 13:34:16 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? > > > Hi Modula-3ers, especially Tony, > > I'm seeing the following behavior a lot in a program I'm running: > > #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 > #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 > #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. > ) at ../src/runtime/common/RTCollector.m3:674 > #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. > ) at ../src/runtime/common/RTCollector.m3:2271 > #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. > ) > at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 > > Is it normal for CheckLoadTracedRef to make system calls? > > Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): > > > PROCEDURE Get ( tbl : Default; > READONLY k : Key.T; > VAR(*OUT*) v : Value.T): BOOLEAN = > VAR > x : Node := tbl.h.hi; > cmp : Cmp; > BEGIN > WHILE (x # NIL) DO > cmp := tbl.keyCompare (k, x.key); > IF cmp = 0 THEN v := x.value; RETURN TRUE; END; > IF (cmp < 0) > THEN x := x.lo; (* line 145 *) > ELSE x := x.hi; > END; > END; > RETURN FALSE; > END Get; > > where Node is defined as > > TYPE > Node = REF RECORD > key : Key.T; > value : Value.T; > lo : Node := NIL; > hi : Node := NIL; > priority: INTEGER (* random num; tree is a heap on these *) > END; > > It seems odd to me that, under these circumstances, x := x.lo would > cause any sort of checking activity... > > I'm using a CM3 that's about a month old, on FreeBSD4. > > Mika > > P.S. Needless to say, the code in question runs about 10x faster under > PM3 than with this relatively new CM3... but my m3gdb is having trouble > with PM3's LONGREALs for some reason. From rodney.m.bates at cox.net Sun May 24 15:50:14 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 24 May 2009 08:50:14 -0500 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> References: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> Message-ID: <4A195096.2030502@cox.net> Floating point values in m3gdb is one area I have never done any work on at all, but I have been aware for a long time that it probably needs some. It just uses stock gdb's code, which also just uses the C builtin arithmetic on C floating types. At the very least, the mapping between C's two and Modula-3's three floating types, on the various targets, is purely an accident right now. I recall there is something wrong in the formatting too. Mika Nystrom wrote: > Hi Modula-3ers, especially Tony, > > I'm seeing the following behavior a lot in a program I'm running: > > #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 > #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 > #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. > ) at ../src/runtime/common/RTCollector.m3:674 > #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. > ) at ../src/runtime/common/RTCollector.m3:2271 > #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. > ) > at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 > > Is it normal for CheckLoadTracedRef to make system calls? > > Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): > > > PROCEDURE Get ( tbl : Default; > READONLY k : Key.T; > VAR(*OUT*) v : Value.T): BOOLEAN = > VAR > x : Node := tbl.h.hi; > cmp : Cmp; > BEGIN > WHILE (x # NIL) DO > cmp := tbl.keyCompare (k, x.key); > IF cmp = 0 THEN v := x.value; RETURN TRUE; END; > IF (cmp < 0) > THEN x := x.lo; (* line 145 *) > ELSE x := x.hi; > END; > END; > RETURN FALSE; > END Get; > > where Node is defined as > > TYPE > Node = REF RECORD > key : Key.T; > value : Value.T; > lo : Node := NIL; > hi : Node := NIL; > priority: INTEGER (* random num; tree is a heap on these *) > END; > > It seems odd to me that, under these circumstances, x := x.lo would > cause any sort of checking activity... > > I'm using a CM3 that's about a month old, on FreeBSD4. > > Mika > > P.S. Needless to say, the code in question runs about 10x faster under > PM3 than with this relatively new CM3... but my m3gdb is having trouble > with PM3's LONGREALs for some reason. > > From mika at async.caltech.edu Sun May 24 20:15:51 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 May 2009 11:15:51 -0700 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: Your message of "Sat, 23 May 2009 21:38:33 -0000." Message-ID: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> It makes a syscall. A slow one! Mika Jay writes: > >It does appear to be making policy decisions based on elapsed time, not just collecting times to report. > >Does gettimeofday on your system make a syscall or read a global? > > - Jay > >Maybe since the intent is just to process one object/page, the CollectorOn/Off calls can be replaced by just > collectorOn := TRUE or FALSE > > ? For CollectorOff that isn't clear since it does more, but CollectorOn is just that plus time recording plus an assertion. Still, given that the intent is some limited processing, I think the time collection could be avoided and might not even be a good thing? > > > - Jay > > >---------------------------------------- >> To: m3devel at elegosoft.com >> Date: Sat, 23 May 2009 13:34:16 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? >> >> >> Hi Modula-3ers, especially Tony, >> >> I'm seeing the following behavior a lot in a program I'm running: >> >> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >> ) at ../src/runtime/common/RTCollector.m3:674 >> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >> ) at ../src/runtime/common/RTCollector.m3:2271 >> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >> ) >> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >> >> Is it normal for CheckLoadTracedRef to make system calls? >> >> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >> >> >> PROCEDURE Get ( tbl : Default; >> READONLY k : Key.T; >> VAR(*OUT*) v : Value.T): BOOLEAN = >> VAR >> x : Node := tbl.h.hi; >> cmp : Cmp; >> BEGIN >> WHILE (x # NIL) DO >> cmp := tbl.keyCompare (k, x.key); >> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >> IF (cmp < 0) >> THEN x := x.lo; (* line 145 *) >> ELSE x := x.hi; >> END; >> END; >> RETURN FALSE; >> END Get; >> >> where Node is defined as >> >> TYPE >> Node = REF RECORD >> key : Key.T; >> value : Value.T; >> lo : Node := NIL; >> hi : Node := NIL; >> priority: INTEGER (* random num; tree is a heap on these *) >> END; >> >> It seems odd to me that, under these circumstances, x := x.lo would >> cause any sort of checking activity... >> >> I'm using a CM3 that's about a month old, on FreeBSD4. >> >> Mika >> >> P.S. Needless to say, the code in question runs about 10x faster under >> PM3 than with this relatively new CM3... but my m3gdb is having trouble >> with PM3's LONGREALs for some reason. From jay.krell at cornell.edu Sun May 24 20:20:50 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 24 May 2009 18:20:50 +0000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> References: Your message of "Sat, 23 May 2009 21:38:33 -0000." <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> Message-ID: I can send you a diff to try later but I won't likely have confidence in it. Tony will have to judge. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Sun, 24 May 2009 11:15:51 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gettimeofday called from CheckLoadTracedRef? > > It makes a syscall. A slow one! > > Mika > > Jay writes: >> >>It does appear to be making policy decisions based on elapsed time, not just collecting times to report. >> >>Does gettimeofday on your system make a syscall or read a global? >> >> - Jay >> >>Maybe since the intent is just to process one object/page, the CollectorOn/Off calls can be replaced by just >> collectorOn := TRUE or FALSE >> >> ? For CollectorOff that isn't clear since it does more, but CollectorOn is just that plus time recording plus an assertion. Still, given that the intent is some limited processing, I think the time collection could be avoided and might not even be a good thing? >> >> >> - Jay >> >> >>---------------------------------------- >>> To: m3devel at elegosoft.com >>> Date: Sat, 23 May 2009 13:34:16 -0700 >>> From: mika at async.caltech.edu >>> CC: mika at camembert.async.caltech.edu >>> Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? >>> >>> >>> Hi Modula-3ers, especially Tony, >>> >>> I'm seeing the following behavior a lot in a program I'm running: >>> >>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:674 >>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:2271 >>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >>> ) >>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >>> >>> Is it normal for CheckLoadTracedRef to make system calls? >>> >>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >>> >>> >>> PROCEDURE Get ( tbl : Default; >>> READONLY k : Key.T; >>> VAR(*OUT*) v : Value.T): BOOLEAN = >>> VAR >>> x : Node := tbl.h.hi; >>> cmp : Cmp; >>> BEGIN >>> WHILE (x # NIL) DO >>> cmp := tbl.keyCompare (k, x.key); >>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>> IF (cmp < 0) >>> THEN x := x.lo; (* line 145 *) >>> ELSE x := x.hi; >>> END; >>> END; >>> RETURN FALSE; >>> END Get; >>> >>> where Node is defined as >>> >>> TYPE >>> Node = REF RECORD >>> key : Key.T; >>> value : Value.T; >>> lo : Node := NIL; >>> hi : Node := NIL; >>> priority: INTEGER (* random num; tree is a heap on these *) >>> END; >>> >>> It seems odd to me that, under these circumstances, x := x.lo would >>> cause any sort of checking activity... >>> >>> I'm using a CM3 that's about a month old, on FreeBSD4. >>> >>> Mika >>> >>> P.S. Needless to say, the code in question runs about 10x faster under >>> PM3 than with this relatively new CM3... but my m3gdb is having trouble >>> with PM3's LONGREALs for some reason. From jay.krell at cornell.edu Sun May 24 20:19:46 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 24 May 2009 18:19:46 +0000 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: <4A195096.2030502@cox.net> References: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> <4A195096.2030502@cox.net> Message-ID: Modula-3 only actually implements two floating point formats. The language spec and frontend might support three "names", but two of them are the same. - Jay ---------------------------------------- > Date: Sun, 24 May 2009 08:50:14 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) > > Floating point values in m3gdb is one area I have never done any > work on at all, but I have been aware for a long time that it probably > needs some. It just uses stock gdb's code, which also just uses > the C builtin arithmetic on C floating types. At the very least, the > mapping between C's two and Modula-3's three floating types, on > the various targets, is purely an accident right now. I recall there > is something wrong in the formatting too. > > Mika Nystrom wrote: >> Hi Modula-3ers, especially Tony, >> >> I'm seeing the following behavior a lot in a program I'm running: >> >> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >> ) at ../src/runtime/common/RTCollector.m3:674 >> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >> ) at ../src/runtime/common/RTCollector.m3:2271 >> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >> ) >> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >> >> Is it normal for CheckLoadTracedRef to make system calls? >> >> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >> >> >> PROCEDURE Get ( tbl : Default; >> READONLY k : Key.T; >> VAR(*OUT*) v : Value.T): BOOLEAN = >> VAR >> x : Node := tbl.h.hi; >> cmp : Cmp; >> BEGIN >> WHILE (x # NIL) DO >> cmp := tbl.keyCompare (k, x.key); >> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >> IF (cmp < 0) >> THEN x := x.lo; (* line 145 *) >> ELSE x := x.hi; >> END; >> END; >> RETURN FALSE; >> END Get; >> >> where Node is defined as >> >> TYPE >> Node = REF RECORD >> key : Key.T; >> value : Value.T; >> lo : Node := NIL; >> hi : Node := NIL; >> priority: INTEGER (* random num; tree is a heap on these *) >> END; >> >> It seems odd to me that, under these circumstances, x := x.lo would >> cause any sort of checking activity... >> >> I'm using a CM3 that's about a month old, on FreeBSD4. >> >> Mika >> >> P.S. Needless to say, the code in question runs about 10x faster under >> PM3 than with this relatively new CM3... but my m3gdb is having trouble >> with PM3's LONGREALs for some reason. >> >> > From mika at async.caltech.edu Sun May 24 20:48:33 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 May 2009 11:48:33 -0700 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: Your message of "Sun, 24 May 2009 08:50:14 CDT." <4A195096.2030502@cox.net> Message-ID: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> The weird thing is that it works really well SOMETIMES. Are there any workarounds? Where would I go poke if I wanted to fix it? My code is mostly floating point (double precision). I find myself typing garbage like print (double *)(M3_adsf23_myVar+8) into the normal C gdb.... In m3gdb I am now getting the following error: (m3gdb) print self.srThreshold $2 = Invalid C/C++ type code 44 in symbol table. This is trying to print a field of type LONGREAL in an OBJECT: (m3gdb) print self $3 = (*16_14838244*) OBJECT orderManager = 16_148382ec; marketDataManager = 16_14838224; tickers = 16_14838ab4; limitsMap = NIL; orderSizeMap = NIL; rangeMult = ; invTilt = ; perfSmooth = ; times = {RECORD hour = 10; minute = 12; second = 0; END, RECORD hour = 15; minute = 55; second = 0; END, RECORD hour = 15; minute = 30; second = 0; END, RECORD hour = 9; minute = 30; second = 0; END, RECORD hour = 16; minute = 0; second = 0; END}; tz = 16_1a7bc7b0; midnites = 16_1a7bc7dc; firstPeriod = 12638; initialPeriods = 390; limitsMap = 16_14838b18; orderSizeMap = 16_14838b38; singleStockMarketMaker = NIL; ssTbl = 16_14833818; unitsPortfolioTilt = ; portTiltMode = UNITS; srThreshold = ; dollarUnit = ; unitsPortTilt = ; grossLimit = ; overnightLimitMultiplier = ; rangeMultiplier = ; closeSmooth = ; END Mika "Rodney M. Bates" writes: >Floating point values in m3gdb is one area I have never done any >work on at all, but I have been aware for a long time that it probably >needs some. It just uses stock gdb's code, which also just uses >the C builtin arithmetic on C floating types. At the very least, the >mapping between C's two and Modula-3's three floating types, on >the various targets, is purely an accident right now. I recall there >is something wrong in the formatting too. > >Mika Nystrom wrote: > Hi Modula-3ers, especially Tony, >> >> I'm seeing the following behavior a lot in a program I'm running: >> >> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >> ) at ../src/runtime/common/RTCollector.m3:674 >> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >> ) at ../src/runtime/common/RTCollector.m3:2271 >> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >> ) >> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >> >> Is it normal for CheckLoadTracedRef to make system calls? >> >> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >> >> >> PROCEDURE Get ( tbl : Default; >> READONLY k : Key.T; >> VAR(*OUT*) v : Value.T): BOOLEAN = >> VAR >> x : Node := tbl.h.hi; >> cmp : Cmp; >> BEGIN >> WHILE (x # NIL) DO >> cmp := tbl.keyCompare (k, x.key); >> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >> IF (cmp < 0) >> THEN x := x.lo; (* line 145 *) >> ELSE x := x.hi; >> END; >> END; >> RETURN FALSE; >> END Get; >> >> where Node is defined as >> >> TYPE >> Node = REF RECORD >> key : Key.T; >> value : Value.T; >> lo : Node := NIL; >> hi : Node := NIL; >> priority: INTEGER (* random num; tree is a heap on these *) >> END; >> >> It seems odd to me that, under these circumstances, x := x.lo would >> cause any sort of checking activity... >> >> I'm using a CM3 that's about a month old, on FreeBSD4. >> >> Mika >> >> P.S. Needless to say, the code in question runs about 10x faster under >> PM3 than with this relatively new CM3... but my m3gdb is having trouble >> with PM3's LONGREALs for some reason. >> >> From dragisha at m3w.org Sun May 24 22:41:25 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 24 May 2009 22:41:25 +0200 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> References: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> Message-ID: <1243197685.28115.4.camel@faramir.m3w.org> I have this straced many times on my LInUXLIBC6... Being strace - it's syscall.. And slow??? Can we live without it? On Sun, 2009-05-24 at 11:15 -0700, Mika Nystrom wrote: > It makes a syscall. A slow one! > > Mika -- Dragi?a Duri? From mika at async.caltech.edu Sun May 24 22:45:44 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 May 2009 13:45:44 -0700 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: Your message of "Sun, 24 May 2009 18:19:46 -0000." Message-ID: <200905242045.n4OKji3w024683@camembert.async.caltech.edu> Hrmph this is a bit silly. 80-bit FP ought to be supported on x86, at least, since that's the native precision of the i387 (and 68881?)... Mika Jay writes: > >Modula-3 only actually implements two floating point formats. >The language spec and frontend might support three "names", but two of them are the same. > > - Jay > > >---------------------------------------- >> Date: Sun, 24 May 2009 08:50:14 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) >> >> Floating point values in m3gdb is one area I have never done any >> work on at all, but I have been aware for a long time that it probably >> needs some. It just uses stock gdb's code, which also just uses >> the C builtin arithmetic on C floating types. At the very least, the >> mapping between C's two and Modula-3's three floating types, on >> the various targets, is purely an accident right now. I recall there >> is something wrong in the formatting too. >> >> Mika Nystrom wrote: >>> Hi Modula-3ers, especially Tony, >>> >>> I'm seeing the following behavior a lot in a program I'm running: >>> >>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:674 >>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:2271 >>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >>> ) >>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >>> >>> Is it normal for CheckLoadTracedRef to make system calls? >>> >>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >>> >>> >>> PROCEDURE Get ( tbl : Default; >>> READONLY k : Key.T; >>> VAR(*OUT*) v : Value.T): BOOLEAN = >>> VAR >>> x : Node := tbl.h.hi; >>> cmp : Cmp; >>> BEGIN >>> WHILE (x # NIL) DO >>> cmp := tbl.keyCompare (k, x.key); >>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>> IF (cmp < 0) >>> THEN x := x.lo; (* line 145 *) >>> ELSE x := x.hi; >>> END; >>> END; >>> RETURN FALSE; >>> END Get; >>> >>> where Node is defined as >>> >>> TYPE >>> Node = REF RECORD >>> key : Key.T; >>> value : Value.T; >>> lo : Node := NIL; >>> hi : Node := NIL; >>> priority: INTEGER (* random num; tree is a heap on these *) >>> END; >>> >>> It seems odd to me that, under these circumstances, x := x.lo would >>> cause any sort of checking activity... >>> >>> I'm using a CM3 that's about a month old, on FreeBSD4. >>> >>> Mika >>> >>> P.S. Needless to say, the code in question runs about 10x faster under >>> PM3 than with this relatively new CM3... but my m3gdb is having trouble >>> with PM3's LONGREALs for some reason. >>> >>> >> From mika at async.caltech.edu Sun May 24 23:56:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 May 2009 14:56:18 -0700 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: Your message of "Sun, 24 May 2009 14:10:25 PDT." <42F3F7C8-6184-4174-94E9-5AF06223A028@hotmail.com> Message-ID: <200905242156.n4OLuIam027199@camembert.async.caltech.edu> Haha, FP isn't weird! It's just... FP! This is a bit disappointing... here's FreeBSD4: (552)rover:~/fp/src>./a.out sizeof(float) = 4 sizeof(double) = 8 sizeof(long double) = 12 (553)rover:~/fp/src>../FreeBSD4/fp BITSIZE(REAL) = 32 BITSIZE(LONGREAL) = 64 BITSIZE(EXTENDED) = 64 I think the "12" is just to get them word-aligned. i387 supports 10-byte extended format in hardware (in fact that is the *only* format it supports, which may cause subtle bugs and/or inefficiencies when using other sizes). PowerPC does 128-bit but is that normally provided in hardware? In any case it seems to me that on i386, Modula-3's EXTENDED ought to be Intel 80-bit FP, possibly padded with two extra bytes like in C. Easiest seems to just make it match C's long double... If the backend compiler optimizer knows what it's doing, 80-bit FP can run faster on i387 than 32- or 64-bit. Because in the narrower formats, the 387 has to convert results to the narrower format on every operation, which it normally does by storing the result and re-loading it. That's not necessary if the code stays in 80-bit extended; instead it keep the intermediate results in registers. Mika jay.krell at cornell.edu writes: >What does 'long double' give you in C? On Windows I'm sure it is 64 >bits. I was just reading that powerpc has a 128 bit long double but I >don't know if always/everywhere and it is in software via two doubles >and lacks various features.On x86 there is something somehow >supposedly much better for FP via SSE/2/3/whatever. Imho FP is just >all around wierd and to be avoided.. > > - Jay (phone) > >On May 24, 2009, at 1:45 PM, Mika Nystrom >wrote: > >> Hrmph this is a bit silly. >> >> 80-bit FP ought to be supported on x86, at least, since that's the >> native precision of the i387 (and 68881?)... >> >> Mika >> >> Jay writes: >>> >>> Modula-3 only actually implements two floating point formats. >>> The language spec and frontend might support three "names", but two >>> of them are the same. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Sun, 24 May 2009 08:50:14 -0500 >>>> From: rodney.m.bates at cox.net >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] LONGREAL and m3gdb (was gettimeofday called >>>> from CheckLoadTracedRef?) >>>> >>>> Floating point values in m3gdb is one area I have never done any >>>> work on at all, but I have been aware for a long time that it >>>> probably >>>> needs some. It just uses stock gdb's code, which also just uses >>>> the C builtin arithmetic on C floating types. At the very least, the >>>> mapping between C's two and Modula-3's three floating types, on >>>> the various targets, is purely an accident right now. I recall there >>>> is something wrong in the formatting too. >>>> >>>> Mika Nystrom wrote: >>>>> Hi Modula-3ers, especially Tony, >>>>> >>>>> I'm seeing the following behavior a lot in a program I'm running: >>>>> >>>>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>>>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>>>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code >>>>> 30 in symbol table. >>>>> ) at ../src/runtime/common/RTCollector.m3:674 >>>>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code >>>>> 46 in symbol table. >>>>> ) at ../src/runtime/common/RTCollector.m3:2271 >>>>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol >>>>> table. >>>>> ) >>>>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ >>>>> libm3/src/sortedtable/SortedTable.mg:145 >>>>> >>>>> Is it normal for CheckLoadTracedRef to make system calls? >>>>> >>>>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code >>>>> (from SortedTable.mg): >>>>> >>>>> >>>>> PROCEDURE Get ( tbl : Default; >>>>> READONLY k : Key.T; >>>>> VAR(*OUT*) v : Value.T): BOOLEAN = >>>>> VAR >>>>> x : Node := tbl.h.hi; >>>>> cmp : Cmp; >>>>> BEGIN >>>>> WHILE (x # NIL) DO >>>>> cmp := tbl.keyCompare (k, x.key); >>>>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>>>> IF (cmp < 0) >>>>> THEN x := x.lo; (* line 145 *) >>>>> ELSE x := x.hi; >>>>> END; >>>>> END; >>>>> RETURN FALSE; >>>>> END Get; >>>>> >>>>> where Node is defined as >>>>> >>>>> TYPE >>>>> Node = REF RECORD >>>>> key : Key.T; >>>>> value : Value.T; >>>>> lo : Node := NIL; >>>>> hi : Node := NIL; >>>>> priority: INTEGER (* random num; tree is a heap on these *) >>>>> END; >>>>> >>>>> It seems odd to me that, under these circumstances, x := x.lo would >>>>> cause any sort of checking activity... >>>>> >>>>> I'm using a CM3 that's about a month old, on FreeBSD4. >>>>> >>>>> Mika >>>>> >>>>> P.S. Needless to say, the code in question runs about 10x faster >>>>> under >>>>> PM3 than with this relatively new CM3... but my m3gdb is having >>>>> trouble >>>>> with PM3's LONGREALs for some reason. >>>>> >>>>> >>>> >> From jay.krell at cornell.edu Sun May 24 23:10:25 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 24 May 2009 14:10:25 -0700 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: <200905242045.n4OKji3w024683@camembert.async.caltech.edu> References: <200905242045.n4OKji3w024683@camembert.async.caltech.edu> Message-ID: <42F3F7C8-6184-4174-94E9-5AF06223A028@hotmail.com> What does 'long double' give you in C? On Windows I'm sure it is 64 bits. I was just reading that powerpc has a 128 bit long double but I don't know if always/everywhere and it is in software via two doubles and lacks various features.On x86 there is something somehow supposedly much better for FP via SSE/2/3/whatever. Imho FP is just all around wierd and to be avoided.. - Jay (phone) On May 24, 2009, at 1:45 PM, Mika Nystrom wrote: > Hrmph this is a bit silly. > > 80-bit FP ought to be supported on x86, at least, since that's the > native precision of the i387 (and 68881?)... > > Mika > > Jay writes: >> >> Modula-3 only actually implements two floating point formats. >> The language spec and frontend might support three "names", but two >> of them are the same. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Sun, 24 May 2009 08:50:14 -0500 >>> From: rodney.m.bates at cox.net >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] LONGREAL and m3gdb (was gettimeofday called >>> from CheckLoadTracedRef?) >>> >>> Floating point values in m3gdb is one area I have never done any >>> work on at all, but I have been aware for a long time that it >>> probably >>> needs some. It just uses stock gdb's code, which also just uses >>> the C builtin arithmetic on C floating types. At the very least, the >>> mapping between C's two and Modula-3's three floating types, on >>> the various targets, is purely an accident right now. I recall there >>> is something wrong in the formatting too. >>> >>> Mika Nystrom wrote: >>>> Hi Modula-3ers, especially Tony, >>>> >>>> I'm seeing the following behavior a lot in a program I'm running: >>>> >>>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code >>>> 30 in symbol table. >>>> ) at ../src/runtime/common/RTCollector.m3:674 >>>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code >>>> 46 in symbol table. >>>> ) at ../src/runtime/common/RTCollector.m3:2271 >>>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol >>>> table. >>>> ) >>>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ >>>> libm3/src/sortedtable/SortedTable.mg:145 >>>> >>>> Is it normal for CheckLoadTracedRef to make system calls? >>>> >>>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code >>>> (from SortedTable.mg): >>>> >>>> >>>> PROCEDURE Get ( tbl : Default; >>>> READONLY k : Key.T; >>>> VAR(*OUT*) v : Value.T): BOOLEAN = >>>> VAR >>>> x : Node := tbl.h.hi; >>>> cmp : Cmp; >>>> BEGIN >>>> WHILE (x # NIL) DO >>>> cmp := tbl.keyCompare (k, x.key); >>>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>>> IF (cmp < 0) >>>> THEN x := x.lo; (* line 145 *) >>>> ELSE x := x.hi; >>>> END; >>>> END; >>>> RETURN FALSE; >>>> END Get; >>>> >>>> where Node is defined as >>>> >>>> TYPE >>>> Node = REF RECORD >>>> key : Key.T; >>>> value : Value.T; >>>> lo : Node := NIL; >>>> hi : Node := NIL; >>>> priority: INTEGER (* random num; tree is a heap on these *) >>>> END; >>>> >>>> It seems odd to me that, under these circumstances, x := x.lo would >>>> cause any sort of checking activity... >>>> >>>> I'm using a CM3 that's about a month old, on FreeBSD4. >>>> >>>> Mika >>>> >>>> P.S. Needless to say, the code in question runs about 10x faster >>>> under >>>> PM3 than with this relatively new CM3... but my m3gdb is having >>>> trouble >>>> with PM3's LONGREALs for some reason. >>>> >>>> >>> > From jay.krell at cornell.edu Mon May 25 00:02:37 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 24 May 2009 22:02:37 +0000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> References: Your message of "Sat, 23 May 2009 21:38:33 -0000." <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> Message-ID: Can you try like this? I haven't even compiled it. --- RTCollector.m3 2009-05-24 14:56:43.510632700 -0700 +++ RTCollector.m3.mine1 2009-05-24 15:00:25.323132700 -0700 @@ -687,12 +687,11 @@ IF impureCopy.page # NIL THEN END; - END CollectorOn; + END CollectorOnWithoutTimeKeeping; PROCEDURE CollectorOn (VAR timeOnEntry: Time.T) = (* LL>= RTOS.LockHeap *) BEGIN - CollectorOnWithoutTimeKeeping(); timeOnEntry := Time.Now(); END CollectorOn; @@ -713,16 +712,14 @@ signalWeak := FALSE; RTOS.BroadcastHeap(); END; - END CollectorOff; + END CollectorOffWithoutTimeKeeping; PROCEDURE CollectorOff (VAR timeOnEntry: Time.T; allocator := FALSE) = (* LL>= RTOS.LockHeap *) VAR timeOnExit := Time.Now(); BEGIN - CollectorOffWithoutTimeKeeping(); - cycleCost := cycleCost + (timeOnExit - timeOnEntry); IF allocator AND tsIndex>= 0 THEN tStamps[tsIndex] := timeOnEntry; INC(tsIndex); @@ -2259,7 +2256,6 @@ to heap state. *) VAR p := Word.RightShift (LOOPHOLE(ref, Word.T), LogBytesPerPage); - t0: Time.T; thread := ThreadF.MyHeapState(); BEGIN INC(checkLoadTracedRef); (* race, so only approximate *) ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] gettimeofday called from CheckLoadTracedRef? > Date: Sun, 24 May 2009 18:20:50 +0000 > > > I can send you a diff to try later but I won't likely have confidence in it. Tony will have to judge. > > > - Jay > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Sun, 24 May 2009 11:15:51 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] gettimeofday called from CheckLoadTracedRef? >> >> It makes a syscall. A slow one! >> >> Mika >> >> Jay writes: >>> >>>It does appear to be making policy decisions based on elapsed time, not just collecting times to report. >>> >>>Does gettimeofday on your system make a syscall or read a global? >>> >>> - Jay >>> >>>Maybe since the intent is just to process one object/page, the CollectorOn/Off calls can be replaced by just >>> collectorOn := TRUE or FALSE >>> >>> ? For CollectorOff that isn't clear since it does more, but CollectorOn is just that plus time recording plus an assertion. Still, given that the intent is some limited processing, I think the time collection could be avoided and might not even be a good thing? >>> >>> >>> - Jay >>> >>> >>>---------------------------------------- >>>> To: m3devel at elegosoft.com >>>> Date: Sat, 23 May 2009 13:34:16 -0700 >>>> From: mika at async.caltech.edu >>>> CC: mika at camembert.async.caltech.edu >>>> Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? >>>> >>>> >>>> Hi Modula-3ers, especially Tony, >>>> >>>> I'm seeing the following behavior a lot in a program I'm running: >>>> >>>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >>>> ) at ../src/runtime/common/RTCollector.m3:674 >>>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >>>> ) at ../src/runtime/common/RTCollector.m3:2271 >>>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >>>> ) >>>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >>>> >>>> Is it normal for CheckLoadTracedRef to make system calls? >>>> >>>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >>>> >>>> >>>> PROCEDURE Get ( tbl : Default; >>>> READONLY k : Key.T; >>>> VAR(*OUT*) v : Value.T): BOOLEAN = >>>> VAR >>>> x : Node := tbl.h.hi; >>>> cmp : Cmp; >>>> BEGIN >>>> WHILE (x # NIL) DO >>>> cmp := tbl.keyCompare (k, x.key); >>>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>>> IF (cmp < 0) >>>> THEN x := x.lo; (* line 145 *) >>>> ELSE x := x.hi; >>>> END; >>>> END; >>>> RETURN FALSE; >>>> END Get; >>>> >>>> where Node is defined as >>>> >>>> TYPE >>>> Node = REF RECORD >>>> key : Key.T; >>>> value : Value.T; >>>> lo : Node := NIL; >>>> hi : Node := NIL; >>>> priority: INTEGER (* random num; tree is a heap on these *) >>>> END; >>>> >>>> It seems odd to me that, under these circumstances, x := x.lo would >>>> cause any sort of checking activity... >>>> >>>> I'm using a CM3 that's about a month old, on FreeBSD4. >>>> >>>> Mika >>>> >>>> P.S. Needless to say, the code in question runs about 10x faster under >>>> PM3 than with this relatively new CM3... but my m3gdb is having trouble >>>> with PM3's LONGREALs for some reason. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RTCollector.m3.orig URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RTCollector.m3.mine1 URL: From rodney.m.bates at cox.net Mon May 25 00:27:29 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 24 May 2009 17:27:29 -0500 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> References: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> Message-ID: <4A19C9D1.2030106@cox.net> Mika Nystrom wrote: > The weird thing is that it works really well SOMETIMES. > > Are there any workarounds? Where would I go poke if I wanted to fix it? > > My code is mostly floating point (double precision). I find myself typing > garbage like > > print (double *)(M3_adsf23_myVar+8) > > into the normal C gdb.... > > In m3gdb I am now getting the following error: > > (m3gdb) print self.srThreshold > $2 = Invalid C/C++ type code 44 in symbol table. > Ah yes, I am beginning to remember. This is a result of a half-fix I did a while back that made m3gdb at least not crash. m3gdb has Modula-3-specific type codes (no relation to TYPECODE) for floating types, but passes expressions to stock gdb code for printing, which knows nothing about the codes. > This is trying to print a field of type LONGREAL in an OBJECT: > > (m3gdb) print self > $3 = (*16_14838244*) OBJECT orderManager = 16_148382ec; marketDataManager = 16_14838224; tickers = 16_14838ab4; > limitsMap = NIL; orderSizeMap = NIL; rangeMult = ; invTilt = ; perfSmooth = ; times = {RECORD hour = 10; minute = 12; > second = 0; END, RECORD hour = 15; minute = 55; second = 0; END, RECORD hour = 15; minute = 30; second = 0; END, > RECORD hour = 9; minute = 30; second = 0; END, RECORD hour = 16; minute = 0; second = 0; END}; tz = 16_1a7bc7b0; > midnites = 16_1a7bc7dc; firstPeriod = 12638; initialPeriods = 390; limitsMap = 16_14838b18; orderSizeMap = 16_14838b38; > singleStockMarketMaker = NIL; ssTbl = 16_14833818; unitsPortfolioTilt = ; portTiltMode = UNITS; srThreshold = ; > dollarUnit = ; unitsPortTilt = ; grossLimit = ; overnightLimitMultiplier = ; rangeMultiplier = ; closeSmooth = ; END > > Mika > > "Rodney M. Bates" writes: > >> Floating point values in m3gdb is one area I have never done any >> work on at all, but I have been aware for a long time that it probably >> needs some. It just uses stock gdb's code, which also just uses >> the C builtin arithmetic on C floating types. At the very least, the >> mapping between C's two and Modula-3's three floating types, on >> the various targets, is purely an accident right now. I recall there >> is something wrong in the formatting too. >> >> Mika Nystrom wrote: >> Hi Modula-3ers, especially Tony, >> >>> I'm seeing the following behavior a lot in a program I'm running: >>> >>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:674 >>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:2271 >>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >>> ) >>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >>> >>> Is it normal for CheckLoadTracedRef to make system calls? >>> >>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >>> >>> >>> PROCEDURE Get ( tbl : Default; >>> READONLY k : Key.T; >>> VAR(*OUT*) v : Value.T): BOOLEAN = >>> VAR >>> x : Node := tbl.h.hi; >>> cmp : Cmp; >>> BEGIN >>> WHILE (x # NIL) DO >>> cmp := tbl.keyCompare (k, x.key); >>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>> IF (cmp < 0) >>> THEN x := x.lo; (* line 145 *) >>> ELSE x := x.hi; >>> END; >>> END; >>> RETURN FALSE; >>> END Get; >>> >>> where Node is defined as >>> >>> TYPE >>> Node = REF RECORD >>> key : Key.T; >>> value : Value.T; >>> lo : Node := NIL; >>> hi : Node := NIL; >>> priority: INTEGER (* random num; tree is a heap on these *) >>> END; >>> >>> It seems odd to me that, under these circumstances, x := x.lo would >>> cause any sort of checking activity... >>> >>> I'm using a CM3 that's about a month old, on FreeBSD4. >>> >>> Mika >>> >>> P.S. Needless to say, the code in question runs about 10x faster under >>> PM3 than with this relatively new CM3... but my m3gdb is having trouble >>> with PM3's LONGREALs for some reason. >>> >>> >>> > > From rodney.m.bates at cox.net Mon May 25 01:12:22 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 24 May 2009 18:12:22 -0500 Subject: [M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?) In-Reply-To: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> References: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> Message-ID: <4A19D456.7040109@cox.net> Mika Nystrom wrote: > The weird thing is that it works really well SOMETIMES. > > Are there any workarounds? Where would I go poke if I wanted to fix it? > Look at the most recent changes to gdbtypes.h and m3-lang.c. Prior to this, m3gdb was segfaulting on requests to print floating values. I see I have a change to c-valprint.c that is not checked in: rodney at yellowstone:~/proj/m3/cm3-new/cm3/m3-sys/m3gdb/gdb/gdb$ ll c-valprint.c -rw-r--r-- 1 rodney rodney 18464 2009-02-26 16:08 c-valprint.c rodney at yellowstone:~/proj/m3/cm3-new/cm3/m3-sys/m3gdb/gdb/gdb$ cvs diff c-valprint.c Index: c-valprint.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3gdb/gdb/gdb/c-valprint.c,v retrieving revision 1.3 diff -r1.3 c-valprint.c 427a428,432 > #ifdef _LANG_m3 > case TYPE_CODE_M3_REAL: > case TYPE_CODE_M3_LONGREAL: > case TYPE_CODE_M3_EXTENDED: > #endif However, this just forces it through a path that prints *really* wrong values, which is no doubt why I didn't check it in. c-valprint.c is the place to start looking. I will try to look at this too, but may not get time for a while. > My code is mostly floating point (double precision). I find myself typing > garbage like > > print (double *)(M3_adsf23_myVar+8) > > into the normal C gdb.... > > In m3gdb I am now getting the following error: > > (m3gdb) print self.srThreshold > $2 = Invalid C/C++ type code 44 in symbol table. > > This is trying to print a field of type LONGREAL in an OBJECT: > > (m3gdb) print self > $3 = (*16_14838244*) OBJECT orderManager = 16_148382ec; marketDataManager = 16_14838224; tickers = 16_14838ab4; > limitsMap = NIL; orderSizeMap = NIL; rangeMult = ; invTilt = ; perfSmooth = ; times = {RECORD hour = 10; minute = 12; > second = 0; END, RECORD hour = 15; minute = 55; second = 0; END, RECORD hour = 15; minute = 30; second = 0; END, > RECORD hour = 9; minute = 30; second = 0; END, RECORD hour = 16; minute = 0; second = 0; END}; tz = 16_1a7bc7b0; > midnites = 16_1a7bc7dc; firstPeriod = 12638; initialPeriods = 390; limitsMap = 16_14838b18; orderSizeMap = 16_14838b38; > singleStockMarketMaker = NIL; ssTbl = 16_14833818; unitsPortfolioTilt = ; portTiltMode = UNITS; srThreshold = ; > dollarUnit = ; unitsPortTilt = ; grossLimit = ; overnightLimitMultiplier = ; rangeMultiplier = ; closeSmooth = ; END > > Mika > > "Rodney M. Bates" writes: > >> Floating point values in m3gdb is one area I have never done any >> work on at all, but I have been aware for a long time that it probably >> needs some. It just uses stock gdb's code, which also just uses >> the C builtin arithmetic on C floating types. At the very least, the >> mapping between C's two and Modula-3's three floating types, on >> the various targets, is purely an accident right now. I recall there >> is something wrong in the formatting too. >> >> Mika Nystrom wrote: >> Hi Modula-3ers, especially Tony, >> >>> I'm seeing the following behavior a lot in a program I'm running: >>> >>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:674 >>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:2271 >>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >>> ) >>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >>> >>> Is it normal for CheckLoadTracedRef to make system calls? >>> >>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >>> >>> >>> PROCEDURE Get ( tbl : Default; >>> READONLY k : Key.T; >>> VAR(*OUT*) v : Value.T): BOOLEAN = >>> VAR >>> x : Node := tbl.h.hi; >>> cmp : Cmp; >>> BEGIN >>> WHILE (x # NIL) DO >>> cmp := tbl.keyCompare (k, x.key); >>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>> IF (cmp < 0) >>> THEN x := x.lo; (* line 145 *) >>> ELSE x := x.hi; >>> END; >>> END; >>> RETURN FALSE; >>> END Get; >>> >>> where Node is defined as >>> >>> TYPE >>> Node = REF RECORD >>> key : Key.T; >>> value : Value.T; >>> lo : Node := NIL; >>> hi : Node := NIL; >>> priority: INTEGER (* random num; tree is a heap on these *) >>> END; >>> >>> It seems odd to me that, under these circumstances, x := x.lo would >>> cause any sort of checking activity... >>> >>> I'm using a CM3 that's about a month old, on FreeBSD4. >>> >>> Mika >>> >>> P.S. Needless to say, the code in question runs about 10x faster under >>> PM3 than with this relatively new CM3... but my m3gdb is having trouble >>> with PM3's LONGREALs for some reason. >>> >>> >>> > > From hosking at cs.purdue.edu Mon May 25 01:28:04 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 09:28:04 +1000 Subject: [M3devel] Rodney's letter to CACM Message-ID: <6A2B7D59-F4D4-47B3-A9AF-3AE8D2C02165@cs.purdue.edu> Kudos to Rodney Bates for his letter in CACM this last month lamenting that safe systems languages like Modula-3 still are not on the radar of the average developer out there. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon May 25 01:43:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 09:43:06 +1000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> References: <200905232034.n4NKYGMk075963@camembert.async.caltech.edu> Message-ID: <5B2975E7-016E-4B07-9AE5-CD0FC3FD0BB4@cs.purdue.edu> On 24 May 2009, at 06:34, Mika Nystrom wrote: > > Hi Modula-3ers, especially Tony, > > I'm seeing the following behavior a lot in a program I'm running: > > #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 > #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 > #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code > 30 in symbol table. > ) at ../src/runtime/common/RTCollector.m3:674 > #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 > in symbol table. > ) at ../src/runtime/common/RTCollector.m3:2271 > #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. > ) > at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ > libm3/src/sortedtable/SortedTable.mg:145 > > Is it normal for CheckLoadTracedRef to make system calls? > > Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from > SortedTable.mg): > > > PROCEDURE Get ( tbl : Default; > READONLY k : Key.T; > VAR(*OUT*) v : Value.T): BOOLEAN = > VAR > x : Node := tbl.h.hi; > cmp : Cmp; > BEGIN > WHILE (x # NIL) DO > cmp := tbl.keyCompare (k, x.key); > IF cmp = 0 THEN v := x.value; RETURN TRUE; END; > IF (cmp < 0) > THEN x := x.lo; (* line 145 *) This line is loading a reference from the lo field of the x record in the heap. To enter the call to the CheckLoadTracedRef routine x must have been marked gray (which means that it might contain references to white objects in the heap). In GC parlance, a gray object is one that the collector has not yet scanned to process its references (and copy their targets). White objects are uncopied (unmarked) objects, and so candidates for freeing at the end of the GC cycle. Because we cannot control what mutators do with white references (to white objects) -- i.e., where they store them, etc. -- we make sure that the mutator can never get a hold of one. > > ELSE x := x.hi; > END; > END; > RETURN FALSE; > END Get; > > where Node is defined as > > TYPE > Node = REF RECORD > key : Key.T; > value : Value.T; > lo : Node := NIL; > hi : Node := NIL; > priority: INTEGER (* random num; tree is a heap on these *) > END; > > It seems odd to me that, under these circumstances, x := x.lo would > cause any sort of checking activity... > > I'm using a CM3 that's about a month old, on FreeBSD4. > > Mika > > P.S. Needless to say, the code in question runs about 10x faster under > PM3 than with this relatively new CM3... but my m3gdb is having > trouble > with PM3's LONGREALs for some reason. From hosking at cs.purdue.edu Mon May 25 01:13:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 09:13:07 +1000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> References: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> Message-ID: The syscall is on the slow path in the barrier, but still perhaps too frequent. I will delete the accounting from the barrier (it's not really very useful there anyway). I hope the result is a big speedup! On 25 May 2009, at 04:15, Mika Nystrom wrote: > It makes a syscall. A slow one! > > Mika > > Jay writes: >> >> It does appear to be making policy decisions based on elapsed time, >> not just collecting times to report. >> >> Does gettimeofday on your system make a syscall or read a global? >> >> - Jay >> >> Maybe since the intent is just to process one object/page, the >> CollectorOn/Off calls can be replaced by just >> collectorOn := TRUE or FALSE >> >> ? For CollectorOff that isn't clear since it does more, but >> CollectorOn is just that plus time recording plus an assertion. >> Still, given that the intent is some limited processing, I think >> the time collection could be avoided and might not even be a good >> thing? >> >> >> - Jay >> >> >> ---------------------------------------- >>> To: m3devel at elegosoft.com >>> Date: Sat, 23 May 2009 13:34:16 -0700 >>> From: mika at async.caltech.edu >>> CC: mika at camembert.async.caltech.edu >>> Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? >>> >>> >>> Hi Modula-3ers, especially Tony, >>> >>> I'm seeing the following behavior a lot in a program I'm running: >>> >>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code >>> 30 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:674 >>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code >>> 46 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:2271 >>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol >>> table. >>> ) >>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ >>> libm3/src/sortedtable/SortedTable.mg:145 >>> >>> Is it normal for CheckLoadTracedRef to make system calls? >>> >>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code >>> (from SortedTable.mg): >>> >>> >>> PROCEDURE Get ( tbl : Default; >>> READONLY k : Key.T; >>> VAR(*OUT*) v : Value.T): BOOLEAN = >>> VAR >>> x : Node := tbl.h.hi; >>> cmp : Cmp; >>> BEGIN >>> WHILE (x # NIL) DO >>> cmp := tbl.keyCompare (k, x.key); >>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>> IF (cmp < 0) >>> THEN x := x.lo; (* line 145 *) >>> ELSE x := x.hi; >>> END; >>> END; >>> RETURN FALSE; >>> END Get; >>> >>> where Node is defined as >>> >>> TYPE >>> Node = REF RECORD >>> key : Key.T; >>> value : Value.T; >>> lo : Node := NIL; >>> hi : Node := NIL; >>> priority: INTEGER (* random num; tree is a heap on these *) >>> END; >>> >>> It seems odd to me that, under these circumstances, x := x.lo would >>> cause any sort of checking activity... >>> >>> I'm using a CM3 that's about a month old, on FreeBSD4. >>> >>> Mika >>> >>> P.S. Needless to say, the code in question runs about 10x faster >>> under >>> PM3 than with this relatively new CM3... but my m3gdb is having >>> trouble >>> with PM3's LONGREALs for some reason. From hosking at cs.purdue.edu Mon May 25 01:19:11 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 09:19:11 +1000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <1243197685.28115.4.camel@faramir.m3w.org> References: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> <1243197685.28115.4.camel@faramir.m3w.org> Message-ID: <70201A5C-3D01-4545-9CE9-2CF45831CFE5@cs.purdue.edu> All fixed -- I blew away the syscall. On 25 May 2009, at 06:41, Dragi?a Duri? wrote: > I have this straced many times on my LInUXLIBC6... Being strace - it's > syscall.. And slow??? Can we live without it? > > On Sun, 2009-05-24 at 11:15 -0700, Mika Nystrom wrote: >> It makes a syscall. A slow one! >> >> Mika > -- > Dragi?a Duri? From hosking at cs.purdue.edu Mon May 25 03:19:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 11:19:22 +1000 Subject: [M3devel] cm3 -O (cm3cg -O3) Message-ID: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> I've successfully bootstrapped with -O now for AMD64_DARWIN, PPC_DARWIN, I386_DARWIN, and SOLgnu, so I think the gcc-based backend is now in much better shape. The only common target missing here is x86/amd64 linux. I'll try to get around to those sometime soon. From hosking at cs.purdue.edu Mon May 25 03:22:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 11:22:45 +1000 Subject: [M3devel] cm3 -O (cm3cg -O3) In-Reply-To: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> References: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> Message-ID: <6D3FD65E-6106-4115-9DC8-05C1D9A89F9A@cs.purdue.edu> PS Where do I look in the Tinderbox configurations to have things build cm3 -O? I might be good to make that the default. On 25 May 2009, at 11:19, Tony Hosking wrote: > I've successfully bootstrapped with -O now for > > AMD64_DARWIN, > PPC_DARWIN, > I386_DARWIN, and > SOLgnu, > > so I think the gcc-based backend is now in much better shape. > > The only common target missing here is x86/amd64 linux. > > I'll try to get around to those sometime soon. From rodney.m.bates at cox.net Mon May 25 04:21:02 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 24 May 2009 21:21:02 -0500 Subject: [M3devel] LONGREAL and m3gdb--slight progress In-Reply-To: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> References: <200905241848.n4OImXqC020671@camembert.async.caltech.edu> Message-ID: <4A1A008E.8090203@cox.net> Mika Nystrom wrote: > The weird thing is that it works really well SOMETIMES. > > Are there any workarounds? Where would I go poke if I wanted to fix it? > I just committed my previously mentioned change, after some experimentation. If you use the command "print/f floatvar", you will get the right value in floating notation. Just "print floatvar" displays garbage because it uses the wrong format. This might be a hint how to get the fix right also, but for now, it's a workaround, if you build the updated m3gdb. > My code is mostly floating point (double precision). I find myself typing > garbage like > > print (double *)(M3_adsf23_myVar+8) > > into the normal C gdb.... > > In m3gdb I am now getting the following error: > > (m3gdb) print self.srThreshold > $2 = Invalid C/C++ type code 44 in symbol table. > > This is trying to print a field of type LONGREAL in an OBJECT: > > (m3gdb) print self > $3 = (*16_14838244*) OBJECT orderManager = 16_148382ec; marketDataManager = 16_14838224; tickers = 16_14838ab4; > limitsMap = NIL; orderSizeMap = NIL; rangeMult = ; invTilt = ; perfSmooth = ; times = {RECORD hour = 10; minute = 12; > second = 0; END, RECORD hour = 15; minute = 55; second = 0; END, RECORD hour = 15; minute = 30; second = 0; END, > RECORD hour = 9; minute = 30; second = 0; END, RECORD hour = 16; minute = 0; second = 0; END}; tz = 16_1a7bc7b0; > midnites = 16_1a7bc7dc; firstPeriod = 12638; initialPeriods = 390; limitsMap = 16_14838b18; orderSizeMap = 16_14838b38; > singleStockMarketMaker = NIL; ssTbl = 16_14833818; unitsPortfolioTilt = ; portTiltMode = UNITS; srThreshold = ; > dollarUnit = ; unitsPortTilt = ; grossLimit = ; overnightLimitMultiplier = ; rangeMultiplier = ; closeSmooth = ; END > > Mika > > "Rodney M. Bates" writes: > >> Floating point values in m3gdb is one area I have never done any >> work on at all, but I have been aware for a long time that it probably >> needs some. It just uses stock gdb's code, which also just uses >> the C builtin arithmetic on C floating types. At the very least, the >> mapping between C's two and Modula-3's three floating types, on >> the various targets, is purely an accident right now. I recall there >> is something wrong in the formatting too. >> >> Mika Nystrom wrote: >> Hi Modula-3ers, especially Tony, >> >>> I'm seeing the following behavior a lot in a program I'm running: >>> >>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:674 >>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table. >>> ) at ../src/runtime/common/RTCollector.m3:2271 >>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table. >>> ) >>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145 >>> >>> Is it normal for CheckLoadTracedRef to make system calls? >>> >>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code (from SortedTable.mg): >>> >>> >>> PROCEDURE Get ( tbl : Default; >>> READONLY k : Key.T; >>> VAR(*OUT*) v : Value.T): BOOLEAN = >>> VAR >>> x : Node := tbl.h.hi; >>> cmp : Cmp; >>> BEGIN >>> WHILE (x # NIL) DO >>> cmp := tbl.keyCompare (k, x.key); >>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>> IF (cmp < 0) >>> THEN x := x.lo; (* line 145 *) >>> ELSE x := x.hi; >>> END; >>> END; >>> RETURN FALSE; >>> END Get; >>> >>> where Node is defined as >>> >>> TYPE >>> Node = REF RECORD >>> key : Key.T; >>> value : Value.T; >>> lo : Node := NIL; >>> hi : Node := NIL; >>> priority: INTEGER (* random num; tree is a heap on these *) >>> END; >>> >>> It seems odd to me that, under these circumstances, x := x.lo would >>> cause any sort of checking activity... >>> >>> I'm using a CM3 that's about a month old, on FreeBSD4. >>> >>> Mika >>> >>> P.S. Needless to say, the code in question runs about 10x faster under >>> PM3 than with this relatively new CM3... but my m3gdb is having trouble >>> with PM3's LONGREALs for some reason. >>> >>> >>> > > From jay.krell at cornell.edu Mon May 25 04:46:27 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 25 May 2009 02:46:27 +0000 Subject: [M3devel] cm3 -O (cm3cg -O3) In-Reply-To: <6D3FD65E-6106-4115-9DC8-05C1D9A89F9A@cs.purdue.edu> References: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> <6D3FD65E-6106-4115-9DC8-05C1D9A89F9A@cs.purdue.edu> Message-ID: -O is not interpreted as -O3 currently. One place to twiddle is m3-sys/cminstall/src/config-no-install/Unix.common proc m3_backend(source, object, optimize, debug) is ... < return try_exec (m3back, args, source, "-o", object) > return try_exec (m3back, "-O3", args, source, "-o", object) end I realize that's not ideal. I think if you: a) restore that so optimize => -O3 b) and then maybe, I'm just looking/guessing just now scripts/regression/defs.sh BUILDSCRIPT="./scripts/do-cm3-${BSET}.sh" .. OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 .. OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 probably omit one of them -- the one that uses the older compiler. Adding -O to these should get through with Olaf's recent changes. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Mon, 25 May 2009 11:22:45 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 -O (cm3cg -O3) > > PS Where do I look in the Tinderbox configurations to have things > build cm3 -O? I might be good to make that the default. > > On 25 May 2009, at 11:19, Tony Hosking wrote: > >> I've successfully bootstrapped with -O now for >> >> AMD64_DARWIN, >> PPC_DARWIN, >> I386_DARWIN, and >> SOLgnu, >> >> so I think the gcc-based backend is now in much better shape. >> >> The only common target missing here is x86/amd64 linux. >> >> I'll try to get around to those sometime soon. > From hosking at cs.purdue.edu Mon May 25 06:05:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 14:05:52 +1000 Subject: [M3devel] cm3 -O (cm3cg -O3) In-Reply-To: References: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> Message-ID: <40B2B113-D699-4B47-9704-99CF03430A9A@cs.purdue.edu> FYI: The bootstrapped compiler components (cm3.cfg, cm3cg.gz, cm3.gz) are available at ftp://ftp.cs.purdue.edu/pub/hosking/m3 in subdirectories drwxr-xr-x 2 hosking hosking 512 May 25 00:01 AMD64_DARWIN drwxr-xr-x 2 hosking hosking 512 May 25 00:01 AMD64_LINUX drwxr-xr-x 2 hosking hosking 512 May 25 00:01 I386_DARWIN drwxr-xr-x 2 hosking hosking 512 May 25 00:01 LINUXLIBC6 drwxr-xr-x 2 hosking hosking 512 May 25 00:01 PPC_DARWIN drwxr-xr-x 2 hosking hosking 512 May 25 00:02 SOLgnu On 25 May 2009, at 13:48, Tony Hosking wrote: > > > On 25 May 2009, at 11:19, Tony Hosking wrote: > >> I've successfully bootstrapped with -O now for >> >> AMD64_DARWIN, >> PPC_DARWIN, >> I386_DARWIN, and >> SOLgnu, >> >> so I think the gcc-based backend is now in much better shape. >> >> The only common target missing here is x86/amd64 linux. > > Ditto for > > LINUXLIBC6, and > AMD64_LINUX. > >> >> >> I'll try to get around to those sometime soon. >> From hosking at cs.purdue.edu Mon May 25 05:48:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 13:48:07 +1000 Subject: [M3devel] cm3 -O (cm3cg -O3) In-Reply-To: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> References: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> Message-ID: On 25 May 2009, at 11:19, Tony Hosking wrote: > I've successfully bootstrapped with -O now for > > AMD64_DARWIN, > PPC_DARWIN, > I386_DARWIN, and > SOLgnu, > > so I think the gcc-based backend is now in much better shape. > > The only common target missing here is x86/amd64 linux. Ditto for LINUXLIBC6, and AMD64_LINUX. > > > I'll try to get around to those sometime soon. > From hosking at cs.purdue.edu Mon May 25 06:19:42 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 14:19:42 +1000 Subject: [M3devel] cm3 -O (cm3cg -O3) In-Reply-To: References: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> <6D3FD65E-6106-4115-9DC8-05C1D9A89F9A@cs.purdue.edu> Message-ID: Hmm. Not sure exactly where to put -O in the boot scripts... On 25 May 2009, at 12:46, Jay wrote: > > -O is not interpreted as -O3 currently. > One place to twiddle is > m3-sys/cminstall/src/config-no-install/Unix.common > > proc m3_backend(source, object, optimize, debug) is > ... > < return try_exec (m3back, args, source, "-o", object) >> return try_exec (m3back, "-O3", args, source, "-o", object) > end > > I realize that's not ideal. > > I think if you: > a) restore that so optimize => -O3 > > b) and then maybe, I'm just looking/guessing just now > > scripts/regression/defs.sh > > BUILDSCRIPT="./scripts/do-cm3-${BSET}.sh" > .. > OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 > .. > OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 > > probably omit one of them -- the one that uses the older compiler. > Adding -O to these should get through with Olaf's recent changes. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: hosking at cs.purdue.edu >> Date: Mon, 25 May 2009 11:22:45 +1000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] cm3 -O (cm3cg -O3) >> >> PS Where do I look in the Tinderbox configurations to have things >> build cm3 -O? I might be good to make that the default. >> >> On 25 May 2009, at 11:19, Tony Hosking wrote: >> >>> I've successfully bootstrapped with -O now for >>> >>> AMD64_DARWIN, >>> PPC_DARWIN, >>> I386_DARWIN, and >>> SOLgnu, >>> >>> so I think the gcc-based backend is now in much better shape. >>> >>> The only common target missing here is x86/amd64 linux. >>> >>> I'll try to get around to those sometime soon. >> From jay.krell at cornell.edu Mon May 25 07:39:20 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 24 May 2009 22:39:20 -0700 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: References: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> Message-ID: <636DC9D9-FEFF-4504-9572-EB10845E0F5A@hotmail.com> It looked to me it was not slow path but every run. Also always setjmp/ pushframe/popframe too. I need to understand libunwind -- it seems to promise pretty portable stack walking. - Jay (phone) On May 24, 2009, at 4:13 PM, Tony Hosking wrote: > The syscall is on the slow path in the barrier, but still perhaps > too frequent. I will delete the accounting from the barrier (it's > not really very useful there anyway). I hope the result is a big > speedup! > > On 25 May 2009, at 04:15, Mika Nystrom wrote: > >> It makes a syscall. A slow one! >> >> Mika >> >> Jay writes: >>> >>> It does appear to be making policy decisions based on elapsed >>> time, not just collecting times to report. >>> >>> Does gettimeofday on your system make a syscall or read a global? >>> >>> - Jay >>> >>> Maybe since the intent is just to process one object/page, the >>> CollectorOn/Off calls can be replaced by just >>> collectorOn := TRUE or FALSE >>> >>> ? For CollectorOff that isn't clear since it does more, but >>> CollectorOn is just that plus time recording plus an assertion. >>> Still, given that the intent is some limited processing, I think >>> the time collection could be avoided and might not even be a good >>> thing? >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> To: m3devel at elegosoft.com >>>> Date: Sat, 23 May 2009 13:34:16 -0700 >>>> From: mika at async.caltech.edu >>>> CC: mika at camembert.async.caltech.edu >>>> Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? >>>> >>>> >>>> Hi Modula-3ers, especially Tony, >>>> >>>> I'm seeing the following behavior a lot in a program I'm running: >>>> >>>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code >>>> 30 in symbol table. >>>> ) at ../src/runtime/common/RTCollector.m3:674 >>>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code >>>> 46 in symbol table. >>>> ) at ../src/runtime/common/RTCollector.m3:2271 >>>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol >>>> table. >>>> ) >>>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ >>>> libm3/src/sortedtable/SortedTable.mg:145 >>>> >>>> Is it normal for CheckLoadTracedRef to make system calls? >>>> >>>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code >>>> (from SortedTable.mg): >>>> >>>> >>>> PROCEDURE Get ( tbl : Default; >>>> READONLY k : Key.T; >>>> VAR(*OUT*) v : Value.T): BOOLEAN = >>>> VAR >>>> x : Node := tbl.h.hi; >>>> cmp : Cmp; >>>> BEGIN >>>> WHILE (x # NIL) DO >>>> cmp := tbl.keyCompare (k, x.key); >>>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>>> IF (cmp < 0) >>>> THEN x := x.lo; (* line 145 *) >>>> ELSE x := x.hi; >>>> END; >>>> END; >>>> RETURN FALSE; >>>> END Get; >>>> >>>> where Node is defined as >>>> >>>> TYPE >>>> Node = REF RECORD >>>> key : Key.T; >>>> value : Value.T; >>>> lo : Node := NIL; >>>> hi : Node := NIL; >>>> priority: INTEGER (* random num; tree is a heap on these *) >>>> END; >>>> >>>> It seems odd to me that, under these circumstances, x := x.lo would >>>> cause any sort of checking activity... >>>> >>>> I'm using a CM3 that's about a month old, on FreeBSD4. >>>> >>>> Mika >>>> >>>> P.S. Needless to say, the code in question runs about 10x faster >>>> under >>>> PM3 than with this relatively new CM3... but my m3gdb is having >>>> trouble >>>> with PM3's LONGREALs for some reason. > > From hosking at cs.purdue.edu Mon May 25 09:07:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 25 May 2009 17:07:13 +1000 Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? In-Reply-To: <636DC9D9-FEFF-4504-9572-EB10845E0F5A@hotmail.com> References: <200905241815.n4OIFpSN019294@camembert.async.caltech.edu> <636DC9D9-FEFF-4504-9572-EB10845E0F5A@hotmail.com> Message-ID: <15E8B704-6E76-4766-B384-F74B4CCB620A@cs.purdue.edu> There is an inline fast path inserted by the compiler that checks the grayness of the object being loaded from. The call to CheckLoadTracedRef should *not* occur on every pointer load from the heap, only on those from gray objects. The TRY block is necessary for now because the cleaner might throw and exception. This is an area I am going to revisit soon, so hopefully we can dispense with it. On 25 May 2009, at 15:39, jay.krell at cornell.edu wrote: > It looked to me it was not slow path but every run. Also always > setjmp/pushframe/popframe too. I need to understand libunwind -- it > seems to promise pretty portable stack walking. > > - Jay (phone) > > On May 24, 2009, at 4:13 PM, Tony Hosking > wrote: > >> The syscall is on the slow path in the barrier, but still perhaps >> too frequent. I will delete the accounting from the barrier (it's >> not really very useful there anyway). I hope the result is a big >> speedup! >> >> On 25 May 2009, at 04:15, Mika Nystrom wrote: >> >>> It makes a syscall. A slow one! >>> >>> Mika >>> >>> Jay writes: >>>> >>>> It does appear to be making policy decisions based on elapsed >>>> time, not just collecting times to report. >>>> >>>> Does gettimeofday on your system make a syscall or read a global? >>>> >>>> - Jay >>>> >>>> Maybe since the intent is just to process one object/page, the >>>> CollectorOn/Off calls can be replaced by just >>>> collectorOn := TRUE or FALSE >>>> >>>> ? For CollectorOff that isn't clear since it does more, but >>>> CollectorOn is just that plus time recording plus an assertion. >>>> Still, given that the intent is some limited processing, I think >>>> the time collection could be avoided and might not even be a good >>>> thing? >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> To: m3devel at elegosoft.com >>>>> Date: Sat, 23 May 2009 13:34:16 -0700 >>>>> From: mika at async.caltech.edu >>>>> CC: mika at camembert.async.caltech.edu >>>>> Subject: [M3devel] gettimeofday called from CheckLoadTracedRef? >>>>> >>>>> >>>>> Hi Modula-3ers, especially Tony, >>>>> >>>>> I'm seeing the following behavior a lot in a program I'm running: >>>>> >>>>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5 >>>>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16 >>>>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type >>>>> code 30 in symbol table. >>>>> ) at ../src/runtime/common/RTCollector.m3:674 >>>>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code >>>>> 46 in symbol table. >>>>> ) at ../src/runtime/common/RTCollector.m3:2271 >>>>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol >>>>> table. >>>>> ) >>>>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ >>>>> libm3/src/sortedtable/SortedTable.mg:145 >>>>> >>>>> Is it normal for CheckLoadTracedRef to make system calls? >>>>> >>>>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code >>>>> (from SortedTable.mg): >>>>> >>>>> >>>>> PROCEDURE Get ( tbl : Default; >>>>> READONLY k : Key.T; >>>>> VAR(*OUT*) v : Value.T): BOOLEAN = >>>>> VAR >>>>> x : Node := tbl.h.hi; >>>>> cmp : Cmp; >>>>> BEGIN >>>>> WHILE (x # NIL) DO >>>>> cmp := tbl.keyCompare (k, x.key); >>>>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END; >>>>> IF (cmp < 0) >>>>> THEN x := x.lo; (* line 145 *) >>>>> ELSE x := x.hi; >>>>> END; >>>>> END; >>>>> RETURN FALSE; >>>>> END Get; >>>>> >>>>> where Node is defined as >>>>> >>>>> TYPE >>>>> Node = REF RECORD >>>>> key : Key.T; >>>>> value : Value.T; >>>>> lo : Node := NIL; >>>>> hi : Node := NIL; >>>>> priority: INTEGER (* random num; tree is a heap on these *) >>>>> END; >>>>> >>>>> It seems odd to me that, under these circumstances, x := x.lo >>>>> would >>>>> cause any sort of checking activity... >>>>> >>>>> I'm using a CM3 that's about a month old, on FreeBSD4. >>>>> >>>>> Mika >>>>> >>>>> P.S. Needless to say, the code in question runs about 10x faster >>>>> under >>>>> PM3 than with this relatively new CM3... but my m3gdb is having >>>>> trouble >>>>> with PM3's LONGREALs for some reason. >> >> From wagner at elegosoft.com Mon May 25 15:59:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 25 May 2009 15:59:53 +0200 Subject: [M3devel] cm3 -O (cm3cg -O3) In-Reply-To: References: <645015A9-CFA4-43F6-A4DC-2FB50AC1CD6E@cs.purdue.edu> <6D3FD65E-6106-4115-9DC8-05C1D9A89F9A@cs.purdue.edu> Message-ID: <20090525155953.qvn7zk2cgkss0c08@mail.elegosoft.com> Quoting Tony Hosking : > Hmm. Not sure exactly where to put -O in the boot scripts... Sorry, I was out of town for some days and had no proper internet connection, so I couldn't respond earlier. Globablly setting BUILDARGS=-O in regression/defs.sh should do the trick. Please try that; I cannot test myself before tomorrow evening... Olaf > On 25 May 2009, at 12:46, Jay wrote: > >> >> -O is not interpreted as -O3 currently. >> One place to twiddle is >> m3-sys/cminstall/src/config-no-install/Unix.common >> >> proc m3_backend(source, object, optimize, debug) is >> ... >> < return try_exec (m3back, args, source, "-o", object) >>> return try_exec (m3back, "-O3", args, source, "-o", object) >> end >> >> I realize that's not ideal. >> >> I think if you: >> a) restore that so optimize => -O3 >> >> b) and then maybe, I'm just looking/guessing just now >> >> scripts/regression/defs.sh >> >> BUILDSCRIPT="./scripts/do-cm3-${BSET}.sh" >> .. >> OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 >> .. >> OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 >> >> probably omit one of them -- the one that uses the older compiler. >> Adding -O to these should get through with Olaf's recent changes. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: hosking at cs.purdue.edu >>> Date: Mon, 25 May 2009 11:22:45 +1000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] cm3 -O (cm3cg -O3) >>> >>> PS Where do I look in the Tinderbox configurations to have things >>> build cm3 -O? I might be good to make that the default. >>> >>> On 25 May 2009, at 11:19, Tony Hosking wrote: >>> >>>> I've successfully bootstrapped with -O now for >>>> >>>> AMD64_DARWIN, >>>> PPC_DARWIN, >>>> I386_DARWIN, and >>>> SOLgnu, >>>> >>>> so I think the gcc-based backend is now in much better shape. >>>> >>>> The only common target missing here is x86/amd64 linux. >>>> >>>> I'll try to get around to those sometime soon. >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From eiserlohpp at yahoo.com Wed May 27 03:44:47 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Tue, 26 May 2009 18:44:47 -0700 (PDT) Subject: [M3devel] [m3devel] Packaged AMD64_LINUX for debian Message-ID: <205613.68479.qm@web56801.mail.re3.yahoo.com> Hi Gang, Okay, here is my take on packaging CM3 for the Debian distribution of Linux. http://www.eiserloh.org/~peter/modula3/#debian-pkg I did install this onto my laptop It is built against cm3-5.8.1.20090522. Could those of you with Debian distributions check it out, and send me any comment for improving the packaging. Please add the following to your /etc/apt/sources.list deb http://www.eiserloh.org/mirrors/modula3/debian lenny main deb-src http://www.eiserloh.org/mirrors/modula3/debian lenny main NOTE-0: You will have to change your CM3 environment variable. I also created a MANPATH to include "/usr/cm3/man". NOTE-1: I have explicitly omitted obliq, juno and anything that depends upon them. NOTE-2: I have moved most of the config files to /usr/cm3/etc, the only one remaining in the binary directory is cm3.cfg. These invoke include("../etc/foo.common"). Changing the location of "cm3.cfg" would require actually changing the code of cm3. Peter +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From wagner at elegosoft.com Wed May 27 08:57:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 27 May 2009 08:57:27 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages Message-ID: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> Hi everybody, I've uploaded some packages for FreeBSD and AMD64_LINUX to http://www.opencm3.net/releng/ for evaluation. For both platforms there are two base archives, which can be used to install a working CM3 system. I'll use the FreeBSD packages as examples: cm3-bin-core-FreeBSD4-d5.8.1-RC1.tgz 100% 16MB 57.8KB/s 04:50 cm3-bin-min-FreeBSD4-d5.8.1-RC1.tgz 100% 7480KB 58.0KB/s 02:09 -min- is just the minimal working system with cm3, m3core and libm3 which we had in all previous releases, too. -core- is a more useful system which contains some additional tools and libraries and could be the base for something like a standard CM3 setup. These packages include the installer (though it does not do much more than copying files) and Jay's new configuration files. All other available software has been archived in binary packages which contain parts of a CM3 _workspace_ (*-bin-ws-*). These packages are pre-compiled and can be shipped with multiple calls to cm3; for convenience a small installation script has been added. The classification of packages is somewhat arbitrary, though I tried to make some meaningful distinctions; it is open for discussion. cm3-bin-ws-anim-FreeBSD4-d5.8.1-RC1.tgz 100% 25MB 57.3KB/s 07:20 cm3-bin-ws-caltech-parser-FreeBSD4-d5.8.1-RC1 100% 4441KB 60.0KB/s 01:14 cm3-bin-ws-core-FreeBSD4-d5.8.1-RC1.tgz 100% 99MB 57.5KB/s 29:21 cm3-bin-ws-cvsup-FreeBSD4-d5.8.1-RC1.tgz 100% 1584KB 66.0KB/s 00:24 cm3-bin-ws-database-FreeBSD4-d5.8.1-RC1.tgz 100% 330KB 109.9KB/s 00:03 cm3-bin-ws-demo-FreeBSD4-d5.8.1-RC1.tgz 100% 512KB 102.5KB/s 00:05 cm3-bin-ws-devlib-FreeBSD4-d5.8.1-RC1.tgz 100% 4539KB 60.5KB/s 01:15 cm3-bin-ws-game-FreeBSD4-d5.8.1-RC1.tgz 100% 2069KB 62.7KB/s 00:33 cm3-bin-ws-gui-FreeBSD4-d5.8.1-RC1.tgz 100% 6322KB 59.1KB/s 01:47 cm3-bin-ws-juno-FreeBSD4-d5.8.1-RC1.tgz 100% 3545KB 61.1KB/s 00:58 cm3-bin-ws-m3devtool-FreeBSD4-d5.8.1-RC1.tgz 100% 20MB 57.9KB/s 05:56 cm3-bin-ws-m3gdb-FreeBSD4-d5.8.1-RC1.tgz 100% 36MB 58.0KB/s 10:35 cm3-bin-ws-math-FreeBSD4-d5.8.1-RC1.tgz 100% 2378KB 62.6KB/s 00:38 cm3-bin-ws-obliq-FreeBSD4-d5.8.1-RC1.tgz 100% 4399KB 60.3KB/s 01:13 cm3-bin-ws-tool-FreeBSD4-d5.8.1-RC1.tgz 100% 1796KB 64.2KB/s 00:28 cm3-bin-ws-webdev-FreeBSD4-d5.8.1-RC1.tgz 100% 986KB 65.8KB/s 00:15 These packages can simply be built with the script make-dist.sh which should work on all target platforms. With SHIPRC=yes all results will be shipped via scp, too. Before others start to contribute their release candidates for other platforms, I'd like to do the following: 1. make sure that we all agree on the distribution format and details. 2. Actually move the default for configuration files to cm3/etc, though I objected that change for this release previously. But it won't get easier if we wait, and I think we can built in some backward compatibility that should help during the migration. It will take some more time though. 3. Write up some user documentation on how to use the release. (Actually, this is one of the more important points.) 4. If everything is settled, set a tag for others to build their packages (something like RELENG_5_8_1_RC1 or similar). 5. Try to integrate available system-dependent packages like those provided by Peter Eiserloh for Debian. Then we can add everything to the CM3 WWW pages and publicly announce the release candidate. Of course we need to test the packages carefully, and fix all deficiencies found in RC2 or RC3. (I haven't done any tests yet, just watched the regression tests in Tinderbox.) Please test and comment, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Wed May 27 09:04:49 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 27 May 2009 09:04:49 +0200 Subject: [M3devel] [m3devel] Packaged AMD64_LINUX for debian In-Reply-To: <205613.68479.qm@web56801.mail.re3.yahoo.com> References: <205613.68479.qm@web56801.mail.re3.yahoo.com> Message-ID: <1243407889.6124.20.camel@faramir.m3w.org> I have work-in-progress rpm creation, my distro is Fedora but no reason for your .debs or my .rpms to have any issues running on any deb/rpm distro. But - I see problem here with any changing of source for packaging needs. Only change I've made was for CM3_INSTALL_PREFIX so I can make rpms incrementally. Almost every of my m3 projects is rpm packaged and I don't like to have all-inclusive rpm. So I am working on scripts to make rpm recipes for small sets of packages. My current recipes are for cm3 (compiler, m3core, libm3, tcp, udp, set, tempfiles, patternmatching, parseparams) divided to cm3 and cm3-devel, separate rpm with m3gdb and cvsup (binary rpms are suplib, suplib-devel, cvsup). And all of them are building LINUXLIBC6 and AMD64_LINUX binary rpms. One issue with how-cm3-does-it is, IMO, /usr/local/cm3/lib directory... It must be lib64 on AMD64_LINUX, at least because we may need both LINUXLIBC6 and AMD64_LINUX libraries present on same system. In my case, I need it because some of C support librarires like panda (basic PDF creation primitives) are not 64 bit clean. Along the way I am making template recipes and working on deriving of dependicies from m3makefiles. Don't know if there is exact recipe translator for rpm-deb...? On Tue, 2009-05-26 at 18:44 -0700, Peter Eiserloh wrote: > NOTE-2: I have moved most of the config files to /usr/cm3/etc, > the only one remaining in the binary directory is cm3.cfg. > These invoke include("../etc/foo.common"). Changing the > location of "cm3.cfg" would require actually changing the > code of cm3. > -- Dragi?a Duri? From dragisha at m3w.org Wed May 27 12:36:34 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 27 May 2009 12:36:34 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> Message-ID: <1243420594.6124.36.camel@faramir.m3w.org> Long time ago, I was Modula-2 programmer with lots of my own libraries doing everything from keyboard input handling and textual windows, relational database, to complex data browsing and input and postscript reporting... After a while (2-3 yrs of dev) I had a problem sorting out library packages and dependicies - same as we have right now. Solution to this is order detection, and some topological sorting voodoo with result grouping... In my (historical) case I've got six groups of modules with controlled inter-group dependicies. My math terminology is a bit rusty, but partially ordered set of all packages is our input data, and output data we get from such a process is partially ordered set of groups of packages. Each element of this final set is one of our release packages. min, std, core, .... is going to my nerves since long time ago. I am surely not only one involved with same reaction :). On Wed, 2009-05-27 at 08:57 +0200, Olaf Wagner wrote: > > The classification of packages is somewhat arbitrary, though I tried > to make some meaningful distinctions; it is open for discussion. -- Dragi?a Duri? From hendrik at topoi.pooq.com Wed May 27 22:17:02 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 27 May 2009 16:17:02 -0400 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> Message-ID: <20090527201702.GA20296@topoi.pooq.com> On Wed, May 27, 2009 at 08:57:27AM +0200, Olaf Wagner wrote: > > 2. Actually move the default for configuration files to cm3/etc, Debian may well insist that configuration files be in /etc/cm3. > though I objected that change for this release previously. But it won't > get easier if we wait, and I think we can built in some backward > compatibility that should help during the migration. It will take some > more time though. -- hendrik From hendrik at topoi.pooq.com Wed May 27 23:37:21 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 27 May 2009 17:37:21 -0400 Subject: [M3devel] [m3devel] Packaged AMD64_LINUX for debian In-Reply-To: <205613.68479.qm@web56801.mail.re3.yahoo.com> References: <205613.68479.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090527213721.GB20296@topoi.pooq.com> On Tue, May 26, 2009 at 06:44:47PM -0700, Peter Eiserloh wrote: > > Please add the following to your /etc/apt/sources.list > > deb http://www.eiserloh.org/mirrors/modula3/debian lenny main > deb-src http://www.eiserloh.org/mirrors/modula3/debian lenny main Did this, got nowhere, perhaps because it was a 32-bit system running squeeze. I got messages like: http://www.eiserloh.org lenny Release.gpg [IGNORED] Just about everything from that site was [IGNORED], except for http://www.eiserloh.org lenny/main Packages [ERROR] 404 Not Found http://www.eiserloh.org lenny/main Sources [ERROR] Is it worth trying on my AMD64, which runs etch instead of Lenny (becasue after upgrading a working copy of my system, the NFS server stopped working)? -- hendrik From jay.krell at cornell.edu Thu May 28 02:28:04 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 28 May 2009 00:28:04 +0000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <1243420594.6124.36.camel@faramir.m3w.org> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> Message-ID: > problem sorting out library packages and > dependicies - same as we have right now. We have a problem sorting out dependencies? I thought the main dilemna was one of "taste" -- too many installable packages vs. too few. Or is it that "taste" and "dependencies" clash? > Solution to this is order detection, and some topological > sorting voodoo If you are satisfied with a linear order that works, pkginfo.txt has one. If you want something that allows for concurrency, well, we don't have infrastructure currently to take advantage of it. I believe a non-linearized graph is not difficult to build given what cm3 knows by reading the m3makefiles. Graphs often make my head hurt though. We should probably, in some future release, 1) move package-to-source-directory feature into cm3 2) allow cm3 to build multiple packages concurrently. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: wagner at elegosoft.com > Date: Wed, 27 May 2009 12:36:34 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages > > Long time ago, I was Modula-2 programmer with lots of my own libraries > doing everything from keyboard input handling and textual windows, > relational database, to complex data browsing and input and postscript > reporting... After a while (2-3 yrs of dev) I had a problem sorting out > library packages and dependicies - same as we have right now. > > Solution to this is order detection, and some topological sorting voodoo > with result grouping... In my (historical) case I've got six groups of > modules with controlled inter-group dependicies. My math terminology is > a bit rusty, but partially ordered set of all packages is our input > data, and output data we get from such a process is partially ordered > set of groups of packages. Each element of this final set is one of our > release packages. > > min, std, core, .... is going to my nerves since long time ago. I am > surely not only one involved with same reaction :). > > > On Wed, 2009-05-27 at 08:57 +0200, Olaf Wagner wrote: >> >> The classification of packages is somewhat arbitrary, though I tried >> to make some meaningful distinctions; it is open for discussion. > -- > Dragi?a Duri? > From jay.krell at cornell.edu Thu May 28 02:35:57 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 28 May 2009 00:35:57 +0000 Subject: [M3devel] [m3devel] Packaged AMD64_LINUX for debian In-Reply-To: <1243407889.6124.20.camel@faramir.m3w.org> References: <205613.68479.qm@web56801.mail.re3.yahoo.com> <1243407889.6124.20.camel@faramir.m3w.org> Message-ID: > One issue with how-cm3-does-it is, IMO, > /usr/local/cm3/lib directory...It must be lib64 on AMD64_LINUX Is this always true or only sometimes? Are there "pure" 64bit systems? Should be if exist or unconditional? Also, do you know about hypothetical PPC64_LINUX, MIP64_LINUX, SPARC64_LINUX? (I only have sparc64 running so far.) That is, all 64bit Linux or only AMD64? Thanks, - Jay ---------------------------------------- > From: dragisha at m3w.org > To: eiserlohpp at yahoo.com > Date: Wed, 27 May 2009 09:04:49 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [m3devel] Packaged AMD64_LINUX for debian > > I have work-in-progress rpm creation, my distro is Fedora but no reason > for your .debs or my .rpms to have any issues running on any deb/rpm > distro. > > But - I see problem here with any changing of source for packaging > needs. Only change I've made was for CM3_INSTALL_PREFIX so I can make > rpms incrementally. Almost every of my m3 projects is rpm packaged and I > don't like to have all-inclusive rpm. So I am working on scripts to make > rpm recipes for small sets of packages. My current recipes are for cm3 > (compiler, m3core, libm3, tcp, udp, set, tempfiles, patternmatching, > parseparams) divided to cm3 and cm3-devel, separate rpm with m3gdb and > cvsup (binary rpms are suplib, suplib-devel, cvsup). And all of them are > building LINUXLIBC6 and AMD64_LINUX binary rpms. > > One issue with how-cm3-does-it is, IMO, /usr/local/cm3/lib directory... > It must be lib64 on AMD64_LINUX, at least because we may need both > LINUXLIBC6 and AMD64_LINUX libraries present on same system. In my case, > I need it because some of C support librarires like panda (basic PDF > creation primitives) are not 64 bit clean. > > Along the way I am making template recipes and working on deriving of > dependicies from m3makefiles. Don't know if there is exact recipe > translator for rpm-deb...? > > On Tue, 2009-05-26 at 18:44 -0700, Peter Eiserloh wrote: >> NOTE-2: I have moved most of the config files to /usr/cm3/etc, >> the only one remaining in the binary directory is cm3.cfg. >> These invoke include("../etc/foo.common"). Changing the >> location of "cm3.cfg" would require actually changing the >> code of cm3. >> > -- > Dragi?a Duri? > From jay.krell at cornell.edu Thu May 28 02:32:20 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 28 May 2009 00:32:20 +0000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090527201702.GA20296@topoi.pooq.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> Message-ID: I'm still of the opinion that these might not be configuration files. Just because they are text, doesn't make it so. Just because /some/ people edit them, doesn't make it so. If lots of people edit them, then it is more convincing. It is a gray, but I suspect the mere naming of the files, and the fact that install used to always change them (but it doesn't now) has everyone convinced. One of the questions is, what happens upon "upgrade"? Is that supposed to leave /etc alone, and keep working with whatever is out there? I'd maybe rather not be limited like that. (But I actually build-in a lot of backward compat so that I can bootstrap using current config files, which I can control, instead of whatever the old releases came with; this is however a difference between the Tinderbox and my own workflow..) Or keep churn low so that upgrade can do some merge? Ditto. - Jay ---------------------------------------- > Date: Wed, 27 May 2009 16:17:02 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages > > On Wed, May 27, 2009 at 08:57:27AM +0200, Olaf Wagner wrote: >> >> 2. Actually move the default for configuration files to cm3/etc, > > Debian may well insist that configuration files be in /etc/cm3. > >> though I objected that change for this release previously. But it won't >> get easier if we wait, and I think we can built in some backward >> compatibility that should help during the migration. It will take some >> more time though. > > -- hendrik > From hendrik at topoi.pooq.com Thu May 28 05:00:20 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 27 May 2009 23:00:20 -0400 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> Message-ID: <20090528030020.GA20885@topoi.pooq.com> On Thu, May 28, 2009 at 12:32:20AM +0000, Jay wrote: > > I'm still of the opinion that these might not be configuration files. > Just because they are text, doesn't make it so. > Just because /some/ people edit them, doesn't make it so. > If lots of people edit them, then it is more convincing. > > It is a gray, but I suspect the mere naming of the files, and the fact that install used to always change them (but it doesn't now) has everyone convinced. > > One of the questions is, what happens upon "upgrade"? > Is that supposed to leave /etc alone, and keep working with whatever is out there? I'd maybe rather not be limited like that. (But I actually build-in a lot of backward compat so that I can bootstrap using current config files, which I can control, instead of whatever the old releases came with; this is however a difference between the Tinderbox and my own workflow..) > Or keep churn low so that upgrade can do some merge? Ditto. If theyre not configuration files, then, of course they should *not* be in /etc. Is there any chance that the cm3 user might want to change them? I'm not talking about making an entirely new set while cross-building for another system here. -- hendrik From hosking at cs.purdue.edu Thu May 28 05:54:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 May 2009 13:54:32 +1000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528030020.GA20885@topoi.pooq.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528030020.GA20885@topoi.pooq.com> Message-ID: <690E4B4C-BE47-4A7B-BBB5-3A33E97F6ADE@cs.purdue.edu> I would argue strongly that a use would *not* want to change the config file. It's definitions are intrinsic to the installation. On 28 May 2009, at 13:00, hendrik at topoi.pooq.com wrote: > On Thu, May 28, 2009 at 12:32:20AM +0000, Jay wrote: >> >> I'm still of the opinion that these might not be configuration files. >> Just because they are text, doesn't make it so. >> Just because /some/ people edit them, doesn't make it so. >> If lots of people edit them, then it is more convincing. >> >> It is a gray, but I suspect the mere naming of the files, and the >> fact that install used to always change them (but it doesn't now) >> has everyone convinced. >> >> One of the questions is, what happens upon "upgrade"? >> Is that supposed to leave /etc alone, and keep working with >> whatever is out there? I'd maybe rather not be limited like that. >> (But I actually build-in a lot of backward compat so that I can >> bootstrap using current config files, which I can control, instead >> of whatever the old releases came with; this is however a >> difference between the Tinderbox and my own workflow..) >> Or keep churn low so that upgrade can do some merge? Ditto. > > If theyre not configuration files, then, of course they should *not* > be > in /etc. Is there any chance that the cm3 user might want to change > them? I'm not talking about making an entirely new set while > cross-building for another system here. > > -- hendrik From hosking at cs.purdue.edu Thu May 28 06:00:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 May 2009 14:00:30 +1000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <690E4B4C-BE47-4A7B-BBB5-3A33E97F6ADE@cs.purdue.edu> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528030020.GA20885@topoi.pooq.com> <690E4B4C-BE47-4A7B-BBB5-3A33E97F6ADE@cs.purdue.edu> Message-ID: <2E2B406C-B232-43A7-9E5F-D09961F8BAB5@cs.purdue.edu> On 28 May 2009, at 13:54, Tony Hosking wrote: > I would argue strongly that a use would *not* want to change the > config file. It's definitions are intrinsic to the installation. ^^^^ ordinary user > > > On 28 May 2009, at 13:00, hendrik at topoi.pooq.com wrote: > >> On Thu, May 28, 2009 at 12:32:20AM +0000, Jay wrote: >>> >>> I'm still of the opinion that these might not be configuration >>> files. >>> Just because they are text, doesn't make it so. >>> Just because /some/ people edit them, doesn't make it so. >>> If lots of people edit them, then it is more convincing. >>> >>> It is a gray, but I suspect the mere naming of the files, and the >>> fact that install used to always change them (but it doesn't now) >>> has everyone convinced. >>> >>> One of the questions is, what happens upon "upgrade"? >>> Is that supposed to leave /etc alone, and keep working with >>> whatever is out there? I'd maybe rather not be limited like that. >>> (But I actually build-in a lot of backward compat so that I can >>> bootstrap using current config files, which I can control, instead >>> of whatever the old releases came with; this is however a >>> difference between the Tinderbox and my own workflow..) >>> Or keep churn low so that upgrade can do some merge? Ditto. >> >> If theyre not configuration files, then, of course they should >> *not* be >> in /etc. Is there any chance that the cm3 user might want to change >> them? I'm not talking about making an entirely new set while >> cross-building for another system here. >> >> -- hendrik From wagner at elegosoft.com Thu May 28 08:34:19 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2009 08:34:19 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090527201702.GA20296@topoi.pooq.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> Message-ID: <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, May 27, 2009 at 08:57:27AM +0200, Olaf Wagner wrote: >> >> 2. Actually move the default for configuration files to cm3/etc, > > Debian may well insist that configuration files be in /etc/cm3. Understood. I'd think that something like $ORIGIN/../etc/cm3.cfg:$ORIGIN/cm3.cfg:/usr/local/etc:/usr/etc as a default may be reasonable. For more exotic setups, the binaries must either be recompiled or the environment variable M3CONFIG must be used. >> though I objected that change for this release previously. But it won't >> get easier if we wait, and I think we can built in some backward >> compatibility that should help during the migration. It will take some >> more time though. > > -- hendrik > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu May 28 08:37:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 May 2009 16:37:17 +1000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> Message-ID: <2B4C1BD4-22D5-41CF-B4B6-93AB4D6A4DF9@cs.purdue.edu> Again, I don't see why the config file should be thought of as something that users should edit. It is specific to a given installation, not to configuration of the packages after installation. On 28 May 2009, at 16:34, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> On Wed, May 27, 2009 at 08:57:27AM +0200, Olaf Wagner wrote: >>> >>> 2. Actually move the default for configuration files to cm3/etc, >> >> Debian may well insist that configuration files be in /etc/cm3. > > Understood. I'd think that something like > > $ORIGIN/../etc/cm3.cfg:$ORIGIN/cm3.cfg:/usr/local/etc:/usr/etc > > as a default may be reasonable. For more exotic setups, the > binaries must either be recompiled or the environment variable > M3CONFIG must be used. > >>> though I objected that change for this release previously. But >>> it won't >>> get easier if we wait, and I think we can built in some backward >>> compatibility that should help during the migration. It will >>> take some >>> more time though. >> >> -- hendrik >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From wagner at elegosoft.com Thu May 28 08:44:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2009 08:44:55 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <2B4C1BD4-22D5-41CF-B4B6-93AB4D6A4DF9@cs.purdue.edu> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> <2B4C1BD4-22D5-41CF-B4B6-93AB4D6A4DF9@cs.purdue.edu> Message-ID: <20090528084455.26ipgni96o0kos08@mail.elegosoft.com> Quoting Tony Hosking : > Again, I don't see why the config file should be thought of as > something that users should edit. It is specific to a given > installation, not to configuration of the packages after installation. I'd second that, too, but then almost all software configuration files living in .../etc on Unix systems should not be edited by ordinary users. They're there so that the software can be adapted to different system setups and conventions, that is, they should and must be edited by the system administrator. I think this is true for at least the part that defines the global paths used by the installation: PKG_INSTALL, BIN_INSTALL, PKG_USE, etc. It is criticised, if I understand it correctly, that CM3 is not flexible enough in allowing this kind of customization currently. And that we do not comply to the file system hierarchy standards. Moving (part of) our config files into some etc directory would be a step into this direction. Olaf > On 28 May 2009, at 16:34, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: >> >>> On Wed, May 27, 2009 at 08:57:27AM +0200, Olaf Wagner wrote: >>>> >>>> 2. Actually move the default for configuration files to cm3/etc, >>> >>> Debian may well insist that configuration files be in /etc/cm3. >> >> Understood. I'd think that something like >> >> $ORIGIN/../etc/cm3.cfg:$ORIGIN/cm3.cfg:/usr/local/etc:/usr/etc >> >> as a default may be reasonable. For more exotic setups, the >> binaries must either be recompiled or the environment variable >> M3CONFIG must be used. >> >>>> though I objected that change for this release previously. But it won't >>>> get easier if we wait, and I think we can built in some backward >>>> compatibility that should help during the migration. It will take some >>>> more time though. >>> >>> -- hendrik >>> >>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From eiserlohpp at yahoo.com Thu May 28 08:46:53 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Wed, 27 May 2009 23:46:53 -0700 (PDT) Subject: [M3devel] M3devel Digest, Vol 31, Issue 38 Message-ID: <175728.17785.qm@web56807.mail.re3.yahoo.com> Ah, yes, I only built binaries for AMD64_LINUX, against debian-lenny (Debian 5.0). Which goes in the directory "dists/lenny/main/binary-amd64", but your system was looking for a directory "dists/squeeze/main/binary-i386", and failing to find the Packages file. To get up and running quickly, use "$apt-get source cm3", which will work as a normal user. --- Oops, sorry about that, okay those files are there now. --- from http://www.eiserloh.org/mirrors/modula3/debian/dists/lenny/main/sources/ along with the other two files. As root, tell apt-get to update its list of . $ sudo apt-get update $ apt-get source cm3 apt-get will not only download the source and diff, but also apply those diffs, giving you my source tree. Now cd into the source tree, and make everything. Unfortunately, I didn't use fakeroot, so you will have be root to build the *.debs. $ sudo make -f debian/rules binary Once that is done, cd to the parent directory, and find all the *.deb files. Install that to a local repository and make the index files. $ sudo mkdir /usr/local/packages $ sudo cp *.deb /usr/local/packages I created a Makefile that builds those for me, here is a copy of my Makefile. --- BEGIN Makefile --- # -------------------------------------------------------------------- # /usr/local/packages/Makefile # Use this to build the Packages file for all the debian packages. # -------------------------------------------------------------------- subdirs = binary-amd64 prefix = dists/lenny/main/ # ---------------------------------------------- all: package_index sources_index clean: for dir in $(subdirs) ; do \ $(RM) $${dir}/Packages* ; \ done $(RM) sources/Source* # ------------- package_index: for dir in $(subdirs) ; do \ dpkg-scanpackages $${dir} /dev/null $(prefix) >$${dir}/Packages ; \ gzip -9 -c $${dir}/Packages >$${dir}/Packages.gz ; \ done sources_index: dpkg-scansources source /dev/null $(prefix) >source/Sources gzip -9 -c source/Sources >source/Sources.gz --- END Makefile --- Now, how could I make those *.deb files for etch, or even squeeze (debian-unstable). I could create a chroot, and install etch onto that, and rebuild an AMD64_LINUX (debian-etch). Basically, the only difference would be that everything gets linked against a different version of libc. I don't think I could get a 32-bit OS chrooted, as my kernel is 64-bit, and expecting syscalls from a 64-bit user space. Hmm, thoughts of QEMU come to mind. Actually, QEMU brings the ability to port everything, as I could run a PPC, ARM, or any other host machine supported by QEMU. More work, oh well! I should be able to find a chunk of time this weekend to start playing with QEMU. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ > ------------------------------ > > Message: 3 > Date: Wed, 27 May 2009 17:37:21 -0400 > From: hendrik at topoi.pooq.com > Subject: Re: [M3devel] [m3devel] Packaged AMD64_LINUX for > debian > To: m3devel at elegosoft.com > Message-ID: <20090527213721.GB20296 at topoi.pooq.com> > Content-Type: text/plain; charset=us-ascii > > On Tue, May 26, 2009 at 06:44:47PM -0700, Peter Eiserloh > wrote: > > > > Please add the following to your > /etc/apt/sources.list > > > >? ? deb http://www.eiserloh.org/mirrors/modula3/debian lenny > main > >? ? deb-src http://www.eiserloh.org/mirrors/modula3/debian lenny > main > > Did this, got nowhere, perhaps because it was a 32-bit > system running > squeeze.? I got messages like: > > http://www.eiserloh.org lenny Release.gpg [IGNORED] > > Just about everything from that site was [IGNORED], except > for > > http://www.eiserloh.org lenny/main Packages [ERROR] > 404 Not Found > http://www.eiserloh.org lenny/main Sources [ERROR] > > Is it worth trying on my AMD64, which runs etch instead of > Lenny > (becasue after upgrading a working copy of my system, the > NFS server > stopped working)? > > -- hendrik > From dragisha at m3w.org Thu May 28 08:58:41 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 May 2009 08:58:41 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> Message-ID: <1243493921.8596.10.camel@faramir.m3w.org> On Thu, 2009-05-28 at 00:28 +0000, Jay wrote: > > > problem sorting out library packages and > > dependicies - same as we have right now. > > We have a problem sorting out dependencies? > I thought the main dilemna was one of "taste" -- too many installable > packages vs. too few. Or is it that "taste" and "dependencies" clash? My English can be hectic, but I think i wrote something like "partially ordered set of groups of packages". People usually do edit scripts when selecting what they need - and things like juno, mentor, games,, go out... My proposal is to make logical groups - neither "too many" nor "too few". And obviously not min "vs." "core" vs. "std" where variants are subsets.. pkginfo.txt is part of one solution I do not find optimal. As we are still talking RELENG - obviously not only I. -- Dragi?a Duri? From wagner at elegosoft.com Thu May 28 11:42:19 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2009 11:42:19 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <1243493921.8596.10.camel@faramir.m3w.org> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> Message-ID: <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> Quoting Dragi?a Duri? : > On Thu, 2009-05-28 at 00:28 +0000, Jay wrote: >> >> > problem sorting out library packages and >> > dependicies - same as we have right now. >> >> We have a problem sorting out dependencies? >> I thought the main dilemna was one of "taste" -- too many installable >> packages vs. too few. Or is it that "taste" and "dependencies" clash? > > My English can be hectic, but I think i wrote something like "partially > ordered set of groups of packages". People usually do edit scripts when > selecting what they need - and things like juno, mentor, games,, go > out... My proposal is to make logical groups - neither "too many" nor > "too few". And obviously not min "vs." "core" vs. "std" where variants > are subsets.. Well, I made a suggestion how to classify the packages into disjunct sets -- the only overlap is (should be?) between the base installation packages (either min or core). There is no min, std, core in the -bin-ws- packages. So far I only got one comment about the bicycle package being in two sets, which has been corrected. Olaf > pkginfo.txt is part of one solution I do not find optimal. As we are > still talking RELENG - obviously not only I. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Thu May 28 14:40:34 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 May 2009 14:40:34 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> Message-ID: <1243514434.8596.16.camel@faramir.m3w.org> Do we have some txt files where these packages are listed by content? Or only way to see them is download? Second... In cvsup package you have suplib AND cvsup? How do you build it? By shipping suplib to /usr/local/cm3/... and then building cvsup? On Thu, 2009-05-28 at 11:42 +0200, Olaf Wagner wrote: > Well, I made a suggestion how to classify the packages into disjunct > sets -- the only overlap is (should be?) between the base installation > packages (either min or core). There is no min, std, core in the > -bin-ws- > packages. > > So far I only got one comment about the bicycle package being in > two sets, which has been corrected. > > Olaf -- Dragi?a Duri? From jay.krell at cornell.edu Thu May 28 14:50:57 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 28 May 2009 12:50:57 +0000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <1243514434.8596.16.camel@faramir.m3w.org> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> Message-ID: Yes we have suplib and cvsup. In general yes, if you are going to ship something, you first have to build and ship its dependencies. If you are not going to ship something, then you just have build its dependencies, with overrides, and can't ship them. I believe this does force like an alternating build, ship, build, ship cycle, which then leads to the ship/install/admin/su problem that I've almost never seen well solved. You can build as root, or you can ship to $HOME, or you can be very interactive. Some of the BSD package systems have something where they can become root back and forth. OR you can ship to a temporary place, targz it up, su, untargz to the real install place, that's not bad. I just have to fix that ".." bug. I will. cvsup had something strange about it but I think we removed its strangeness. Like, it could never be shipped. > Do we have some txt files where these packages are listed by content? Or Not that I know of. > Or only way to see them is download? Browse the CVS repository or the hyperlinked source that is also there? There's also a package download page I haven't tried. I admit the need to ship a static lib seems dubious. But it does have to be built with overrides or not. Furthermore I'm not sure this whole system is as good as it could be, but I also know it's not likely a well solved problem by anyone. For example if you read the diy-linux list you'll see they have a problem using gcc without running install. It used to work for them but then it bot broken. > not a well solved problem by anyone People fiddle around with chroot, "jail", installing to $HOME, static linking, but I'm not sure any of these are satisfactory, certainly not static linking. There are difficult problems around "just what is meant to be shared". - Jay ---------------------------------------- > From: dragisha at m3w.org > To: wagner at elegosoft.com > Date: Thu, 28 May 2009 14:40:34 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages > > Do we have some txt files where these packages are listed by content? Or > only way to see them is download? > > Second... In cvsup package you have suplib AND cvsup? How do you build > it? By shipping suplib to /usr/local/cm3/... and then building cvsup? > > On Thu, 2009-05-28 at 11:42 +0200, Olaf Wagner wrote: >> Well, I made a suggestion how to classify the packages into disjunct >> sets -- the only overlap is (should be?) between the base installation >> packages (either min or core). There is no min, std, core in the >> -bin-ws- >> packages. >> >> So far I only got one comment about the bicycle package being in >> two sets, which has been corrected. >> >> Olaf > -- > Dragi?a Duri? > From dragisha at m3w.org Thu May 28 14:51:53 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 May 2009 14:51:53 +0200 Subject: [M3devel] [m3devel] Packaged AMD64_LINUX for debian In-Reply-To: References: <205613.68479.qm@web56801.mail.re3.yahoo.com> <1243407889.6124.20.camel@faramir.m3w.org> Message-ID: <1243515113.8596.25.camel@faramir.m3w.org> Very good question, http://proton.pathname.com/fhs/pub/fhs-2.3.html#LIB64 sez: /lib64 and /lib32 : 64/32-bit libraries (architecture dependent) The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib. The 64-bit architecture IA64 must place 64-bit libraries in /lib. Tip Rationale This is a refinement of the general rules for /lib and /usr/lib. The architectures PPC64, s390x, sparc64 and AMD64 support support both 32-bit (for s390 more precise 31-bit) and 64-bit programs. Using lib for 32-bit binaries allows existing binaries from the 32-bit systems to work without any changes: such binaries are expected to be numerous. IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries (and hence libraries) on that architecture. On Thu, 2009-05-28 at 00:35 +0000, Jay wrote: > > One issue with how-cm3-does-it is, IMO, > > /usr/local/cm3/lib directory...It must be lib64 on AMD64_LINUX > > > Is this always true or only sometimes? > Are there "pure" 64bit systems? > Should be if exist or unconditional? > Also, do you know about hypothetical PPC64_LINUX, MIP64_LINUX, > SPARC64_LINUX? > (I only have sparc64 running so far.) > That is, all 64bit Linux or only AMD64? -- Dragi?a Duri? From dragisha at m3w.org Thu May 28 15:06:47 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 May 2009 15:06:47 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> Message-ID: <1243516007.8596.38.camel@faramir.m3w.org> On Thu, 2009-05-28 at 12:50 +0000, Jay wrote: > > OR you can ship to a temporary place, targz it up, su, untargz to the > real install place, that's not bad. I just have to fix that ".." bug. > I will. > This is solved, with CM3_INSTALL_PREFIX, for simple cases. Can be done for less simple ones, but that solution is insufficient for package groups like this one - suplib and cvsup in same package, and to build cvsup correctly you must ship suplib. What I did in my rpm system so far is to make suplib source rpm create two packages, suplib and suplib-devel. For building of cvsup I need both, for running - only first. Following this train of thought, I think we need more packages, and have them obviously grouped, like: cm3-cvsup-suplib cm3-cvsup-suplib-devel cm3-cvsup (cvsup proper, we escape cm3-cvsup-cvsup here) cm3-cvsupd (also instead of cvsup-cvsupd, it's obvious) In RPM lingo I can have (and do): suplib suplib-devel cvsup And for Group I can have some more info, visible while querying/browsing packages. % rpm -q suplib -i Name : suplib Relocations: (not relocatable) Version : 5.8.1 Vendor: (none) Release : 1 Build Date: Sun 24 May 2009 01:20:55 PM CEST Install Date: Sun 24 May 2009 01:22:27 PM CEST Build Host: faramir.m3w.org Group : Applications/Internet Source RPM: suplib-5.8.1-1.src.rpm Size : 2308450 License: Copyright 1996-2003 John D. Polstra. All rights reserved. Signature : (none) Packager : dragisha at m3w.org URL : http://www.cvsup.org Summary : CVSup support library Description : CVSup support library In RPM spec file we can put nice info for group, once we have package grouping sorted out. > > cvsup had something strange about it but I think we removed its > strangeness. > Like, it could never be shipped. :) It is not strange, it only has it's own libraries. It's until we sort "standard" packages out and learn it's normal to have fancy hierarchy of libraries and modules in out projects as we have in cm3. -- Dragi?a Duri? From wagner at elegosoft.com Thu May 28 15:24:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2009 15:24:13 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <1243514434.8596.16.camel@faramir.m3w.org> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> Message-ID: <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> Quoting Dragi?a Duri? : > Do we have some txt files where these packages are listed by content? Or > only way to see them is download? All groups are listed in pkginfo.txt. > Second... In cvsup package you have suplib AND cvsup? How do you build > it? By shipping suplib to /usr/local/cm3/... and then building cvsup? All bin packages are pre-built and can be installed with the included install.sh (which simply executes cm3 -ship multiple times). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Thu May 28 15:31:20 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 May 2009 15:31:20 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> Message-ID: <1243517480.8596.39.camel@faramir.m3w.org> This is not something we can "sell" to Linux people. On Thu, 2009-05-28 at 15:24 +0200, Olaf Wagner wrote: > > Second... In cvsup package you have suplib AND cvsup? How do you > build > > it? By shipping suplib to /usr/local/cm3/... and then building > cvsup? > > All bin packages are pre-built and can be installed with the > included install.sh (which simply executes cm3 -ship multiple times). > > Olaf -- Dragi?a Duri? From dragisha at m3w.org Thu May 28 15:57:02 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 May 2009 15:57:02 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> Message-ID: <1243519022.8596.47.camel@faramir.m3w.org> On Thu, 2009-05-28 at 15:24 +0200, Olaf Wagner wrote: > All bin packages are pre-built and can be installed with the > included install.sh (which simply executes cm3 -ship multiple times). As I said, this kind of binary packages are not something Linux people want. Also, in standard RPM based distro (and most are, except ones which are Debian based but they have similar packaging philosophy) we have features which make handling of big number of interdependent packages easy task. Installation of cvsup on fresh system will pull suplib and also package(s) with m3core/libm3/set/parseparams/patternmatching libs... Big number of packages or not, it's something RPM (system) will do for me. I have some (RPM spec file) templates developed which enable making packages which contain interdependent packages and once I get content of your packages (combined with some free time) I will make spec files with same content. -- Dragi?a Duri? From jay.krell at cornell.edu Thu May 28 17:19:34 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 28 May 2009 15:19:34 +0000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <1243519022.8596.47.camel@faramir.m3w.org> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> <1243519022.8596.47.camel@faramir.m3w.org> Message-ID: > we have features which make handling of big number of interdependent packages So, maybe we should just have a package per directory, cm3-foo (cm3-cm3, cm3-m3cc, cm3-m3core, cm3-libm3, cm3-ui, m3-vbt, cm3-formsedit, etc.), and leave just the old min and all for people not using packages? Is that ok or obnoxious? When we get really advanced, cm3 -ship will have flags -rpm and -deb or such (and -addtar?)? On the matter of config files btw, there are maybe three "levels": 1 not edited by anyone 2 edited by (every/many) root/admin/installer 3 edited by every user I wasn't trying to distinguish between 2 and 3, but rather 1 and 2. If few root/admin/installers edit the files, just like they don't edit "binaries", then it is #1. If every/many do, then #2. Just because it is a text file, doesn't mean it is meant to be edited. It is a gray line between compiled code in cm3 and script in cm3.cfg. Ultimately root can edit any file anywhere, be they text files outside of /etc or binaries in /usr/bin. I do think though there is a question of what "upgrades" do, if "upgrade" is free to overwrite files, is obligated to leave them alone, or is obligated to merge. Here again, as in many things, I think many people (not necessarily here and certainly not limited to here) believe in a truth that they believe is obvious but in fact there is probably no good answer. There may be other issues here. I don't know what all is implied by a file being in /etc vs. /usr/local/etc vs. /usr/local/bin. To be more constructive though..maybe we should discuss just how people tend to edit their config files? Do you put in full paths to cc, gcc, ld? Or is $PATH search a good compromise that folks can live with? I'm a little conflicted on this matter, because often for cross builds you have platform-gcc instead of gcc. I could make a symlink and alter path, but I don't know if there is a clear best. Maybe cm3 should do something here? Maybe $CC environment variable is the way? Do you edit the compile/link flags? Maybe $CFLAGS/$LDFLAGS we should use?? Have you rewritten them entirely? :) Have you further factored/merged some of the reduncancies or odd factoring I have left in? (Unix.common vs. Darwin.common vs. Solaris.common vs. HPUX.common is still a bit wierd and not always the right balance.) Are there just a few environment variables or command line switches we can put to capture what people do? I know about lib64. - Jay > From: dragisha at m3w.org > To: wagner at elegosoft.com > Date: Thu, 28 May 2009 15:57:02 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages > > On Thu, 2009-05-28 at 15:24 +0200, Olaf Wagner wrote: > > All bin packages are pre-built and can be installed with the > > included install.sh (which simply executes cm3 -ship multiple times). > > As I said, this kind of binary packages are not something Linux people > want. > > Also, in standard RPM based distro (and most are, except ones which are > Debian based but they have similar packaging philosophy) we have > features which make handling of big number of interdependent packages > easy task. Installation of cvsup on fresh system will pull suplib and > also package(s) with m3core/libm3/set/parseparams/patternmatching > libs... Big number of packages or not, it's something RPM (system) will > do for me. > > I have some (RPM spec file) templates developed which enable making > packages which contain interdependent packages and once I get content of > your packages (combined with some free time) I will make spec files with > same content. > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu May 28 17:52:49 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 28 May 2009 11:52:49 -0400 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528084455.26ipgni96o0kos08@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> <2B4C1BD4-22D5-41CF-B4B6-93AB4D6A4DF9@cs.purdue.edu> <20090528084455.26ipgni96o0kos08@mail.elegosoft.com> Message-ID: <4A1E7B02.1E75.00D7.1@scires.com> Of course, there are platforms that don't use etc, like Windows. I'm ok with whatever approach makes sense for the given platforms wrt configuration files; however, I will point out that for those of us who've been using Modula-3 for a long time, that we are used to having to mess around with the config files to get things to work correctly. I'm all for simplifying things and would love NOT to HAVE to mess with the config files, as long as whatever approach is taken allows for adequate flexibility in adapting to particular installation requirements. On a Windows platform, most programs are stored in %ProgramFiles%, typically "C:\Program Files", but CM3 is more than a program, it is a repository of packages etc. Typically, ordinary users don't get write privileges to %ProgramFiles%. So, I've always put my installation in "C:\cm3", but then some folks might have multiple drives and partitions and want to put it somewhere else. Indeed, I once used "D:\cm3". Another thing that the config files had to be adapted for in the past was where to find the C compiler, libraries, and linker. Today, we have the free Microsoft Visual Studio tools, but there are other vendors of C compilers and linkers. Which of these will the config files support? Critical Mass also adapted the config file to tell "Reactor" where to find certain things. Of course, now we have CM3IDE as the replacement for Reactor and I've tried to adapt the code to deal with some of Jay's changes to the config files. My 2 cents: Whatever is decided, we need to document it, and make it widely known (i.e., publicize it) so that us old timers understand whether we should or should not keep tweaking the config files. I know Jay has been making great strides with the config files, but I don't believe everyone is "clued-into" what has been done and the rationale behind it, hence the need for some publicized documentation. Then, we need to go back and revise old documentation, such as that with CM3IDE, to reflect the new reality. I can make doc changes, but I need to understand new content first. Regards, Randy >>> Olaf Wagner 5/28/2009 2:44 AM >>> Quoting Tony Hosking : > Again, I don't see why the config file should be thought of as > something that users should edit. It is specific to a given > installation, not to configuration of the packages after installation. I'd second that, too, but then almost all software configuration files living in .../etc on Unix systems should not be edited by ordinary users. They're there so that the software can be adapted to different system setups and conventions, that is, they should and must be edited by the system administrator. I think this is true for at least the part that defines the global paths used by the installation: PKG_INSTALL, BIN_INSTALL, PKG_USE, etc. It is criticised, if I understand it correctly, that CM3 is not flexible enough in allowing this kind of customization currently. And that we do not comply to the file system hierarchy standards. Moving (part of) our config files into some etc directory would be a step into this direction. Olaf > On 28 May 2009, at 16:34, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: >> >>> On Wed, May 27, 2009 at 08:57:27AM +0200, Olaf Wagner wrote: >>>> >>>> 2. Actually move the default for configuration files to cm3/etc, >>> >>> Debian may well insist that configuration files be in /etc/cm3. >> >> Understood. I'd think that something like >> >> $ORIGIN/../etc/cm3.cfg:$ORIGIN/cm3.cfg:/usr/local/etc:/usr/etc >> >> as a default may be reasonable. For more exotic setups, the >> binaries must either be recompiled or the environment variable >> M3CONFIG must be used. >> >>>> though I objected that change for this release previously. But it won't >>>> get easier if we wait, and I think we can built in some backward >>>> compatibility that should help during the migration. It will take some >>>> more time though. >>> >>> -- hendrik >>> >>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu May 28 22:20:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2009 22:20:27 +0200 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <1243519022.8596.47.camel@faramir.m3w.org> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> <1243519022.8596.47.camel@faramir.m3w.org> Message-ID: <20090528222027.py10dhgckggcwccc@mail.elegosoft.com> Quoting Dragi?a Duri? : > On Thu, 2009-05-28 at 15:24 +0200, Olaf Wagner wrote: >> All bin packages are pre-built and can be installed with the >> included install.sh (which simply executes cm3 -ship multiple times). > > As I said, this kind of binary packages are not something Linux people > want. Why? > Also, in standard RPM based distro (and most are, except ones which are > Debian based but they have similar packaging philosophy) we have > features which make handling of big number of interdependent packages > easy task. Installation of cvsup on fresh system will pull suplib and > also package(s) with m3core/libm3/set/parseparams/patternmatching > libs... Big number of packages or not, it's something RPM (system) will > do for me. > > I have some (RPM spec file) templates developed which enable making > packages which contain interdependent packages and once I get content of > your packages (combined with some free time) I will make spec files with > same content. If nobody thinks these bin packages are useful, we can leave them out without any problem. I thought they would be a good compromise as they provide both sources and binaries and may be used as the base for both kinds of system dependent packages. As I said before, I don't really intend to provide packages for Debian, Ubuntu, RedHat, Solaris, MacOS, Windows, Solaris etc. That's something I cannot manage and maintain. Elego can provide web and disk resources, but everything else needs to be done by dedicated users. If the packaging and installation process for these systems will be completely decoupled from any kind of standard release packages, that's fine too. Nonetheless I'd like to get to the point where there's a working release again which can be used by anyone in the same way. So if there is anything such a standard distribution should provide which can be done without much efforts, I'd like to hear about it. I tried to conform to Peter Eiserloh's wishes, as far as it they can be reasonably fulfilled within some weeks. Now I'm not really sure what it is that's wanted. Thanks for your input, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Thu May 28 22:39:33 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 28 May 2009 16:39:33 -0400 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <20090528222027.py10dhgckggcwccc@mail.elegosoft.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <1243420594.6124.36.camel@faramir.m3w.org> <1243493921.8596.10.camel@faramir.m3w.org> <20090528114219.18dghfbk04w88gsw@mail.elegosoft.com> <1243514434.8596.16.camel@faramir.m3w.org> <20090528152413.86e5t6huok0w4ow4@mail.elegosoft.com> <1243519022.8596.47.camel@faramir.m3w.org> <20090528222027.py10dhgckggcwccc@mail.elegosoft.com> Message-ID: <4A1EBE33.1E75.00D7.1@scires.com> Olaf: I'll be glad to provide Windows distributions once we settle on a release. I can also test now any pre-release on Windows. Just let me know what to check out using TortoiseCVS so I get the right sources. I'll also document everything I do so we can use that for helping people who want to build from scratch on Windows. My idea is to provide GZIP TAR archives at a minimum, plus a Windows install program for those who want to go that route. Regards, Randy >>> Olaf Wagner 5/28/2009 4:20 PM >>> As I said before, I don't really intend to provide packages for Debian, Ubuntu, RedHat, Solaris, MacOS, Windows, Solaris etc. That's something I cannot manage and maintain. Elego can provide web and disk resources, but everything else needs to be done by dedicated users. CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri May 29 03:17:08 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 29 May 2009 01:17:08 +0000 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: <4A1E7B02.1E75.00D7.1@scires.com> References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> <2B4C1BD4-22D5-41CF-B4B6-93AB4D6A4DF9@cs.purdue.edu> <20090528084455.26ipgni96o0kos08@mail.elegosoft.com> <4A1E7B02.1E75.00D7.1@scires.com> Message-ID: > I know Jay has been making great strides with the config files, but > I don't believe everyone is "clued-into" what has been done and the rationale behind it Here's a summary: - The config files used to each be independent, but /highly/ redundant. They had a lot of identical or nearly-and-could-be code. I factored a lot, so there is shared code. Worse -- besides the redundancy between the different platforms, every config file was duplicated twice in the tree with very minor differences. It was confusing and a maintenance problem. - The installer would write full paths to compiler/linker. That is one viable approach. If people really like that, we should factor it in somehow. What I do instead is just run leaf "gcc", "cl", etc. and depend on $PATH search. Also regarding paths to libraries, I found what they were on each of my system and assume they are pretty well standardized. If someone really has a custom layout, they will need to edit the files. If someone doesn't want the gcc that comes first in $PATH, they will either need to change $PATH or edit the file. At some point, you know, if someone wants something different, they can also edit the source to cm3 and rebuild it. If the config files can be made correct enough for enough people, you can consider these things in the same category. You know, you don't install all *.sh, *.pl, *.py code to /etc. You pick some "knobs". Not too many, not too few. There were generally more than necessary before I believe. But maybe I'm wrong here? On *BSD some things would not be in the default install, but there'd be a port/package, so where the port installed, I'd use that path. This is grayer, since you can also install things yourself and the default from "upstream" might be different. On Mac OSX I would generally get the third party package and find its default. e.g. postgresql. Something more is probably needed here, like file existance checks. - Full path to the cm3 install implemented via path() and walking from there. path() is the path of the quake config file that calls it. cm3.cfg knows it is next to the compiler, or maybe in a sibling directory to it, that the install root is path()/.. - I have some semantic changes such as use of $ORIGIN, use of hardlinks instead of symlinks (so $ORIGIN works better), updating NT386 for use with current and older tools, to statically link in shared data (the set/hand stuff). - I introduced an optional toplevel cm3.cfg that probes around for the "real" config file, such as to use the current one in the source tree, so I don't have to keep copying it around, or or to use one based on an an environment variable specifying target platform. Probing around in the source tree is not appropriate for a "release" version and that is taken into account. There is also probing around in the release directory. There is also probing for a backend, again for cross build purposes. The exact probed paths and their sequence is certainly up to debate. - In terms of compatibility, there are also runtime checks, so that older cm3cg isn't given an -m32 flag that is rejects, stuff like that. Also workarounds for bootstraping from a compiler with the old GC implementation. After this release I think we'll declare that you can only bootstrap from this release or newer and remove various compatibility hacks. Maybe. - Jay Date: Thu, 28 May 2009 11:52:49 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages Of course, there are platforms that don't use etc, like Windows. I'm ok with whatever approach makes sense for the given platforms wrt configuration files; however, I will point out that for those of us who've been using Modula-3 for a long time, that we are used to having to mess around with the config files to get things to work correctly. I'm all for simplifying things and would love NOT to HAVE to mess with the config files, as long as whatever approach is taken allows for adequate flexibility in adapting to particular installation requirements. On a Windows platform, most programs are stored in %ProgramFiles%, typically "C:\Program Files", but CM3 is more than a program, it is a repository of packages etc. Typically, ordinary users don't get write privileges to %ProgramFiles%. So, I've always put my installation in "C:\cm3", but then some folks might have multiple drives and partitions and want to put it somewhere else. Indeed, I once used "D:\cm3". Another thing that the config files had to be adapted for in the past was where to find the C compiler, libraries, and linker. Today, we have the free Microsoft Visual Studio tools, but there are other vendors of C compilers and linkers. Which of these will the config files support? Critical Mass also adapted the config file to tell "Reactor" where to find certain things. Of course, now we have CM3IDE as the replacement for Reactor and I've tried to adapt the code to deal with some of Jay's changes to the config files. My 2 cents: Whatever is decided, we need to document it, and make it widely known (i.e., publicize it) so that us old timers understand whether we should or should not keep tweaking the config files. I know Jay has been making great strides with the config files, but I don't believe everyone is "clued-into" what has been done and the rationale behind it, hence the need for some publicized documentation. Then, we need to go back and revise old documentation, such as that with CM3IDE, to reflect the new reality. I can make doc changes, but I need to understand new content first. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri May 29 04:48:02 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 28 May 2009 19:48:02 -0700 Subject: [M3devel] CM3 RELENG: suggestion for distribution packages In-Reply-To: References: <20090527085727.4fvvard4owskc080@mail.elegosoft.com> <20090527201702.GA20296@topoi.pooq.com> <20090528083419.nrs6gjm60wkg4wwk@mail.elegosoft.com> <2B4C1BD4-22D5-41CF-B4B6-93AB4D6A4DF9@cs.purdue.edu> <20090528084455.26ipgni96o0kos08@mail.elegosoft.com> <4A1E7B02.1E75.00D7.1@scires.com> Message-ID: I missed a question: we only currently support Microsoft Visual C++ for NT386, pretty much any version, and gcc for MIN/GNU but consider those maybe not well supported by me. I am aware of a number of alternatives such as OpenWatcom, Digital Mars, Borland, lcc, old Symantec, old Metrowerks, I have used them all some but nothing real yet and not near top of my list by far. - Jay (phone) On May 28, 2009, at 6:17 PM, Jay wrote: > > I know Jay has been making great strides with the config files, > but > > I don't believe everyone is "clued-into" what has been done and > the rationale behind it > > Here's a summary: > > - The config files used to each be > independent, but /highly/ redundant. > They had a lot of identical or nearly-and-could-be code. > I factored a lot, so there is shared code. > Worse -- besides the redundancy between the > different platforms, every config file was duplicated > twice in the tree with very minor differences. > It was confusing and a maintenance problem. > > - The installer would write full paths > to compiler/linker. That is one viable approach. > If people really like that, we should factor it in somehow. > What I do instead is just run leaf "gcc", "cl", etc. > and depend on $PATH search. > Also regarding paths to libraries, I found what > they were on each of my system and assume they > are pretty well standardized. If someone really > has a custom layout, they will need to edit the files. > If someone doesn't want the gcc that comes first > in $PATH, they will either need to change $PATH > or edit the file. > > At some point, you know, if someone wants something > different, they can also edit the source to cm3 and rebuild it. > If the config files can be made correct enough > for enough people, you can consider these things > in the same category. > > You know, you don't install all *.sh, *.pl, *.py code to /etc. > You pick some "knobs". Not too many, not too few. > There were generally more than necessary before I believe. > But maybe I'm wrong here? > > On *BSD some things would not be in the default install, but > there'd be a port/package, so where the port installed, I'd use > that path. > This is grayer, since you can also install things yourself and the > default from "upstream" might be different. > > On Mac OSX I would generally get the third party package and > find its default. > > e.g. postgresql. > > Something more is probably needed here, like file existance checks. > > - Full path to the cm3 install implemented via path() and walking > from there. path() is the path of the quake config file > that calls it. cm3.cfg knows it is next to the compiler, or maybe > in a sibling directory to it, that the install root is path()/.. > > - I have some semantic changes such as use of $ORIGIN, > use of hardlinks instead of symlinks (so $ORIGIN works better), > updating NT386 for use with current and older tools, to > statically link in shared data (the set/hand stuff). > > > - I introduced an optional toplevel cm3.cfg that > probes around for the "real" config file, such > as to use the current one in the source tree, > so I don't have to keep copying it around, or > or to use one based on an an environment variable > specifying target platform. Probing around > in the source tree is not appropriate for > a "release" version and that is taken into > account. There is also probing around in the release > directory. There is also probing for a backend, > again for cross build purposes. The exact probed > paths and their sequence is certainly up to debate. > > - In terms of compatibility, there are also runtime checks, so that > older cm3cg isn't given an -m32 flag that is rejects, stuff like > that. > Also workarounds for bootstraping from a compiler with the old GC > implementation. > > After this release I think we'll declare that you can only > bootstrap from > this release or newer and remove various compatibility hacks. > Maybe. > > - Jay > > > Date: Thu, 28 May 2009 11:52:49 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution > packages > > Of course, there are platforms that don't use etc, like Windows. > > I'm ok with whatever approach makes sense for the given platforms > wrt configuration files; however, I will point out that for those of > us who've been using Modula-3 for a long time, that we are used to > having to mess around with the config files to get things to work > correctly. I'm all for simplifying things and would love NOT to > HAVE to mess with the config files, as long as whatever approach is > taken allows for adequate flexibility in adapting to particular > installation requirements. > > On a Windows platform, most programs are stored in %ProgramFiles%, > typically "C:\Program Files", but CM3 is more than a program, it is > a repository of packages etc. Typically, ordinary users don't get > write privileges to %ProgramFiles%. So, I've always put my > installation in "C:\cm3", but then some folks might have multiple > drives and partitions and want to put it somewhere else. Indeed, I > once used "D:\cm3". > > Another thing that the config files had to be adapted for in the > past was where to find the C compiler, libraries, and linker. > Today, we have the free Microsoft Visual Studio tools, but there are > other vendors of C compilers and linkers. Which of these will the > config files support? > > Critical Mass also adapted the config file to tell "Reactor" where > to find certain things. Of course, now we have CM3IDE as the > replacement for Reactor and I've tried to adapt the code to deal > with some of Jay's changes to the config files. > > My 2 cents: Whatever is decided, we need to document it, and make > it widely known (i.e., publicize it) so that us old timers > understand whether we should or should not keep tweaking the config > files. I know Jay has been making great strides with the config > files, but I don't believe everyone is "clued-into" what has been > done and the rationale behind it, hence the need for some publicized > documentation. Then, we need to go back and revise old > documentation, such as that with CM3IDE, to reflect the new > reality. I can make doc changes, but I need to understand new > content first. > > Regards, > Randy > From jay.krell at cornell.edu Sun May 31 16:49:21 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 31 May 2009 14:49:21 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: The bitfield problem still seems present. m3-libs/m3core/src/runtime/common/RTIO.m3: PROCEDURE Flush () = BEGIN IF (len > 0) THEN RTOS.Write (ADR (buf[0]), len); len := 0; END; END Flush. In question is just the line "len := 0", it is line 79, len is a module-global. Without any optimization, the bitfield code yields: .stabd 68,0,79 ldr r3, L53+12 @ tmp110, L51: add r3, pc, r3 @ tmp110, tmp110 ; r3 contains the address of the module globals mov r2, r3 @ tmp109, tmp110 ; now r2 does ldr r3, [r2, #52] @, ; r3 now contains the address of len str r3, [sp, #0] @, ldr r3, [sp, #0] @ tmp112, str r3, [sp, #0] @ tmp112, ldr r3, [sp, #0] @, str r3, [r2, #52] @, which I believe never actually stores to the global -- at least not any value it doesn't already have. The non-bitfield code, again, not optimized, yields: .stabd 68,0,79 ldr r3, L53+12 @ tmp113, L51: add r3, pc, r3 @ tmp113, tmp113 add r3, r3, #52 @ D.789, tmp113, ; r3 now contains the address of len mov r2, r3 @ D.790, D.789 ; now r2 does mov r3, #0 @ tmp114, ; r3=0 str r3, [r2, #0] @ tmp114,* D.790 ; len=0 Which is pretty clearly ok -- it is actually putting zero in a register and storing that in the global. Granted, this is using gcc 4.2 (the gcc-apple directory). Some/all of the volitization is skipped, but has that ever been a problem when not optimizing? (actually I think it has, I remember debugging an m3/cygwin problem early on where code got thrown out because the compiler didn't think it did anything, I don't remember the details) Anyway, the #ifndef GCC_APPLE does workaround this successfully -- cm3 does startup ok on my iphone :). It's that this bitfield stuff also caused problems on Mips so I'm leary of it, I wonder if it is just not a great idea. - Jay > > >> > >> m3_load/store using bitfields for everything caused module-global > >> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked > >> around that by declaring that the module-globals are at least of > >> size 2 * biggest_alignment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Sun May 31 20:57:44 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 31 May 2009 11:57:44 -0700 (PDT) Subject: [M3devel] [M3Devel] Bug report: compiler output option "-o" not working Message-ID: <690137.5674.qm@web56807.mail.re3.yahoo.com> Hi Guys, A simple hello world program MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("Hello Modula-3 World.\n"); END Hello. Compiles and links when the compiler is invoked as $ cm3 but fails when invoked as $ cm3 -o Hello With the following error message: peter at black:~/modula-3/m3hello $ cm3 -o Hello --- building in AMD64_LINUX --- -> linking Hello Fatal Error: incomplete program missing "Main" module +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From eiserlohpp at yahoo.com Sun May 31 21:41:12 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 31 May 2009 12:41:12 -0700 (PDT) Subject: [M3devel] [M3Devel] failure to find scripts/version, due to root not set Message-ID: <391441.99767.qm@web56805.mail.re3.yahoo.com> In recent builds, I noticed that the compiler pkg (cm3) was not getting installed into the pkg directory. The build log indicated that "/scripts/version" could not be found. This is understandable, "scripts" is not in my root directory, but rather it is rooted in the source tree. Examining further sysinfo.sh is relying upon a variable "root" to exist. The script sysinfo.sh is a script invoked not by users, but by other scripts. These top level scripts when simply invoked by a user works well, but those top level scripts can be called by other than a user, say a makefile. My "Makefile" sets ROOT (uppercase), so the toplevel scripts never go through the search process, and never set "root" lower case. My fix was easy, if simplistic. ---- BEGIN ---- if [ -n "$ROOT" -a -d "$ROOT" ] ; then sysinfo="$ROOT/scripts/sysinfo.sh" + export root=${ROOT} else root=`pwd` while [ -n "$root" -a ! -f "$root/scripts/sysinfo.sh" ] ; do ---- END ---- +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Fri May 1 00:12:58 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 30 Apr 2009 22:12:58 +0000 Subject: [M3devel] dynamic unload? Message-ID: Does any care what the following do? int main() { while(1) { { void* = dlopen("libm3core.so"); /* more stuff here */ dlclose(x); } return 0; } int main() { while(1) { void* x = dlopen("some-standalone-m3.so"); /* more stuff here */ dlclose(x); } return 0; } int main() { while(1) { void* x = dlopen("some-not-standalone-m3.so"); /* more stuff here */ dlclose(x); } return 0; } (On Windows, these are called LoadLibrary and FreeLibrary.) I haven't run them but I expect they all behave poorly, leaking, leaking thread locals, crashing in the garbage collector thread, etc. A lot of code out there in the world is ok to unload, and I guess a lot is not. I think the above code shouldn't leak or crash. I'm pretty certain they do, probably crash, or at least leak. - Jay From jay.krell at cornell.edu Mon May 4 12:09:12 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 4 May 2009 10:09:12 +0000 Subject: [M3devel] coping with low memory/resources? Message-ID: I invented a policy of one immediate retry for EAGAIN. I'm not sure that will help but it won't hurt much. I'm leary of infinite retry. This will be active maybe tonight. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: coping with low memory/resources? > Date: Wed, 29 Apr 2009 12:27:48 +0000 > > > coping with low memory/resources? > > > We have code that does like > r := pthread_do_something() > assert(r == 0); > > > where for example: > [EAGAIN] > The system lacked the necessary resources (other than memory) to initialise another mutex. > [ENOMEM] > Insufficient memory exists to initialise the mutex. > > > I'll fix it to raise an out of memory exception for ENOMEM. Ok. > But what about EAGAIN? > Retry? That is what "again" means, right? > In an infinite loop? > Or just a few times? > You know -- overall system might be low but other parts might reduce, > or the Modula-3 code itself might be hogging resources and retry might > just sit there forever. > Raise some other exception? > > For now I'll leave it asserting. > > > - Jay From wagner at elegosoft.com Mon May 4 16:46:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 04 May 2009 16:46:57 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> Message-ID: <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> Now it's May 4th, and I feel we should turn to the official release again. Have any of the open issues been closed? Offhand I remember o REFANY/TAGGED REF extensions o alternative TEXT implementation o complete switch to new Unix headers o working cvsup (OK AFAIK) o formsvbt crashes o performance issues: threads, exception frames, texts, ... There are probably more. A short status from those who know would be great. We must also decide which platforms _must_ be part of the release. I'd suggest AMD64_LINUX, LINUXLIBC6, FreeBSD(4/7?), SOLgnu, I386_DARWIN (and/or AMD64_DARWIN?), and of course Windows (native and Cygwin, however these are called these days ;-) Should we add more? I'll need support to build several of them. I suggest that we use the old make_bin_dist_min.sh scripts with the core distribution. Or is something better already completely automated (possibly by Jay)? I'll just try to coordinate things, assign error reports, make some tests myself and setup release candidate access when we start. Or should we postpone one or two weeks? Olaf Quoting Olaf Wagner : > If anybody could test Rodney's TEXT changes and provide some > information on the impacts on our applications, that would help a lot. > > I also wasn't able to read and understand all the mails about small objects. > (Guessing, I'd say I'd need another day for that :-) > Can anybody summarize? > Has a conclusion been reached and what will be done/implemented? > Is this relevant for the next release, or will it take longer? > > Olaf > > Quoting Randy Coleburn : > >> Rodney, sorry but I haven't tried your changes. If your test >> program is available, I would be glad to compile and run it on >> Windows to obtain results for that platform. Just let me know how >> to obtain/install your TEXT changes and the test program. >> >> I am ok with Olaf's suggestion of starting the release process in May. >> >> Again, I will be glad to help on Windows platforms. If necessary, >> I can also test cygwin on Windows. >> >> If we need to test/build/release on HPUX, I have an old v10 system >> I can pull out of storage (note that v10 is an older version of >> HPUX and not current). >> >> Regards, >> Randy Coleburn >> >>>>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> >> Any opinions about the TEXT branch? Anybody tried it? To summarize: >> >> - I have tested it extensively on LINUXLIBC6, with a large random >> test program and two successive rebuilds of CM3. >> >> - It makes no changes in data structure, neither to static declarations >> nor to invariants. Thus it creates no compatibility problems with >> existing >> pickles, etc. >> >> - It slows down concatenation, but more than makes it up in other >> string accessing operations, if the numbers of concatenations and >> accessing operations are equal. >> >> - It cuts down on tree depth and even more or recursion depth >> (which implies needed stack space.) >> >> - This effect is dramatic when strings are built by "linear" concatenations, >> i.e., strictly left-to-right, or vice versa. Gains are moderate when >> concatenations are random. >> >> - It allocates a lot more storage, but abandons a lot more garbage, >> retaining somewhat more space when lots of old strings are retained >> along with newly-built ones. It probably retains less when operand >> strings of concatenations are not kept, but I haven't measured that. >> >> - Strategies are partial rebalancing of concatenation trees, flattening >> of short concatenations, elimination of a lot of tail-recursion, and >> recursing on the shorter side. >> >> >> >> Olaf Wagner wrote: >>> Well, that's a quite long list; but many things are bug fixes anyway, >>> and wouldn't be affected by a code freeze, while others are already >>> finished (as integrating CVSup, as I understand). >>> >>> The only thing we should not do is introduce new platforms while >>> trying to get the system stable. We should concentrate on installation >>> support and bug fixing. >>> >>> I'd suggest to start the release process in about two weeks at the >>> start of May. That should give everybody enough time to either finish >>> their ongoing work that shall make it into the release or decide to >>> postpone it ;-) >>> >>> Any objections? >>> >>> Olaf >>> >>> Quoting Jay : >>> >>>> >>>> > > o When should we start? I.e. wha changes would you like to complete >>>> > > before we start the release process? >>>> >>>> >>>> >>>> >>>> I'd like to see the formsvbt crash debugged and fixed, unless I'm >>>> the only one seeing it. >>>> >>>> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >>>> >>>> I'll try to get this. >>>> >>>> >>>> >>>> >>>> >>>> I'd also like to see: >>>> >>>> >>>> >>>> >>>> >>>> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >>>> >>>> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >>>> >>>> >>>> >>>> >>>> >>>> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >>>> little work (I'll do this). >>>> >>>> Basically just 1) put buildlocal back how it was 2) push it across >>>> more platforms e.g. I think FreeBSD/x86 is the main one missing, >>>> but I'll get to it. >>>> >>>> >>>> >>>> >>>> >>>> cvsup building and in "std" (I'll do this, probably very little >>>> left here really. >>>> >>>> >>>> >>>> >>>> >>>> -- beyond this, not required for release -- >>>> >>>> >>>> >>>> >>>> >>>> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >>>> >>>> (could be "mingw64" is good enough to try AMD64_NT now). >>>> >>>> >>>> >>>> >>>> >>>> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >>>> by me) >>>> >>>> >>>> >>>> >>>> >>>> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >>>> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >>>> seat to important fixes in existing platforms. >>>> >>>> >>>> >>>> >>>> >>>> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >>>> skip C __finally blocks. I've just been very lazy here, should >>>> demonstrate the behavior with a test case, then fix it.. >>>> >>>> >>>> >>>> >>>> >>>> Maybe fix cm3cg so other -g options besides -gstabs works, like >>>> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >>>> leaving nothing, because others cause internal compiler errors, like >>>> on HPPA64_HPUX. >>>> >>>> >>>> >>>> >>>> >>>> Oh, and NT386GNU probably switched back to Win32 threads. >>>> Otherwise one of the test cases hangs and it doesn't look easy to >>>> figure out. I'll do this shortly if I remember. >>>> >>>> But I also wouldn't mind if this platform isn't officially released >>>> either (unless someone else wants to support it). >>>> >>>> >>>> >>>> >>>> >>>> Debug why many NT386MINGNU gui apps crash..but also probably just >>>> don't release this platform and ok asis. >>>> >>>> >>>> >>>> >>>> >>>> - Jay >>>> >>> >>> >>> >> >> >> >> CONFIDENTIALITY NOTICE: This email and any attachments are >> intended solely for the use of the named recipient(s). This e-mail >> may contain confidential and/or proprietary information of >> Scientific Research Corporation. If you are not a named >> recipient, you are prohibited from making any use of the >> information in the email and attachments. If you believe you have >> received this email in error, please notify the sender >> immediately and permanently delete the email, any attachments, >> and all copies thereof from any drives or storage media and >> destroy any printouts of the email or attachments. >> >> EXPORT COMPLIANCE NOTICE: This email and any attachments may >> contain technical data subject to U.S export restrictions under the >> International Traffic in Arms Regulations (ITAR) or the Export >> Administration Regulations (EAR). Export or transfer of this >> technical data and/or related information to any foreign person(s) >> or entity(ies), either within the U.S. or outside of the U.S., may >> require export authorization by the appropriate U.S. Government >> agency prior to export or transfer. In addition, technical data >> may not be exported or transferred to certain countries or >> specified designated nationals identified by U.S. embargo controls >> without prior export authorization. By accepting this email and >> any attachments, all recipients confirm that they understand and >> will comply with all applicable ITAR, EAR and embargo compliance >> requirements. >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon May 4 18:39:09 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 4 May 2009 16:39:09 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> Message-ID: > o complete switch to new Unix headers I386_DARWIN and AMD64_DARWIN not switched. ok though either way. > o working cvsup (OK AFAIK) ok, though I didn't add it to build automation. > o formsvbt crashes Not solved. I couldn't get an older release to work to verify against. > o performance issues: threads, exception frames, texts, ... A little better. I don't think regressed wrt cm3 though. Can release asis I think. > We must also decide which platforms _must_ be part of the release. > I'd suggest AMD64_LINUX, LINUXLIBC6, FreeBSD(4/7?), SOLgnu, > I386_DARWIN (and/or AMD64_DARWIN?), and of course Windows (native and > Cygwin, however these are called these days ;-) I'd just as soon skip Cygwin. Maybe we can have some sort of "tiers"? All of PPC_DARWIN, I386_DARWIN, AMD64_DARWIN can be included. Many others /can/ be included, but I don't know what must/should be included. > Should we add more? I'll need support to build several of them. > > I suggest that we use the old make_bin_dist_min.sh scripts with > the core distribution. Or is something better already completely > automated (possibly by Jay)? I have good automation, with some caveats: No cminstall. A few packages should be added: m3gdb, cm3ide, cvsup There might be a few copyrights missing, and they might be so numerous that a directory should be created, if that is "prominent" enough. There is always more work to do.. - Jay From hosking at cs.purdue.edu Tue May 5 01:13:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 5 May 2009 09:13:57 +1000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> Message-ID: On 5 May 2009, at 00:46, Olaf Wagner wrote: > Now it's May 4th, and I feel we should turn to the official release > again. > > Have any of the open issues been closed? Offhand I remember > > o REFANY/TAGGED REF extensions I have the minimalist version almost ready for checkin. > o alternative TEXT implementation > > o complete switch to new Unix headers > > o working cvsup (OK AFAIK) > > o formsvbt crashes > > o performance issues: threads, exception frames, texts, ... I'd prefer to see stability here for now, rather than on over-the-top performance drive -- there are better solutions out there that we can engineer in, but getting them in may require a stabilization period. > There are probably more. A short status from those who know would > be great. > > We must also decide which platforms _must_ be part of the release. > I'd suggest AMD64_LINUX, LINUXLIBC6, FreeBSD(4/7?), SOLgnu, > I386_DARWIN (and/or AMD64_DARWIN?), and of course Windows (native and > Cygwin, however these are called these days ;-) > > Should we add more? I'll need support to build several of them. > > I suggest that we use the old make_bin_dist_min.sh scripts with > the core distribution. Or is something better already completely > automated (possibly by Jay)? > > I'll just try to coordinate things, assign error reports, make > some tests myself and setup release candidate access when we start. > Or should we postpone one or two weeks? > > Olaf > > > Quoting Olaf Wagner : > >> If anybody could test Rodney's TEXT changes and provide some >> information on the impacts on our applications, that would help a >> lot. >> >> I also wasn't able to read and understand all the mails about small >> objects. >> (Guessing, I'd say I'd need another day for that :-) >> Can anybody summarize? >> Has a conclusion been reached and what will be done/implemented? >> Is this relevant for the next release, or will it take longer? >> >> Olaf >> >> Quoting Randy Coleburn : >> >>> Rodney, sorry but I haven't tried your changes. If your test >>> program is available, I would be glad to compile and run it on >>> Windows to obtain results for that platform. Just let me know >>> how to obtain/install your TEXT changes and the test program. >>> >>> I am ok with Olaf's suggestion of starting the release process in >>> May. >>> >>> Again, I will be glad to help on Windows platforms. If >>> necessary, I can also test cygwin on Windows. >>> >>> If we need to test/build/release on HPUX, I have an old v10 >>> system I can pull out of storage (note that v10 is an older >>> version of HPUX and not current). >>> >>> Regards, >>> Randy Coleburn >>> >>>>>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> >>> Any opinions about the TEXT branch? Anybody tried it? To summarize: >>> >>> - I have tested it extensively on LINUXLIBC6, with a large random >>> test program and two successive rebuilds of CM3. >>> >>> - It makes no changes in data structure, neither to static >>> declarations >>> nor to invariants. Thus it creates no compatibility problems with >>> existing >>> pickles, etc. >>> >>> - It slows down concatenation, but more than makes it up in other >>> string accessing operations, if the numbers of concatenations and >>> accessing operations are equal. >>> >>> - It cuts down on tree depth and even more or recursion depth >>> (which implies needed stack space.) >>> >>> - This effect is dramatic when strings are built by "linear" >>> concatenations, >>> i.e., strictly left-to-right, or vice versa. Gains are moderate >>> when >>> concatenations are random. >>> >>> - It allocates a lot more storage, but abandons a lot more garbage, >>> retaining somewhat more space when lots of old strings are retained >>> along with newly-built ones. It probably retains less when operand >>> strings of concatenations are not kept, but I haven't measured that. >>> >>> - Strategies are partial rebalancing of concatenation trees, >>> flattening >>> of short concatenations, elimination of a lot of tail-recursion, and >>> recursing on the shorter side. >>> >>> >>> >>> Olaf Wagner wrote: >>>> Well, that's a quite long list; but many things are bug fixes >>>> anyway, >>>> and wouldn't be affected by a code freeze, while others are already >>>> finished (as integrating CVSup, as I understand). >>>> >>>> The only thing we should not do is introduce new platforms while >>>> trying to get the system stable. We should concentrate on >>>> installation >>>> support and bug fixing. >>>> >>>> I'd suggest to start the release process in about two weeks at the >>>> start of May. That should give everybody enough time to either >>>> finish >>>> their ongoing work that shall make it into the release or decide to >>>> postpone it ;-) >>>> >>>> Any objections? >>>> >>>> Olaf >>>> >>>> Quoting Jay : >>>> >>>>> >>>>> > > o When should we start? I.e. wha changes would you like to >>>>> complete >>>>> > > before we start the release process? >>>>> >>>>> >>>>> >>>>> >>>>> I'd like to see the formsvbt crash debugged and fixed, unless I'm >>>>> the only one seeing it. >>>>> >>>>> I only see it on Solaris and PPC_DARWIN but haven't tried >>>>> "everything". >>>>> >>>>> I'll try to get this. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I'd also like to see: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >>>>> >>>>> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the >>>>> hardware. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >>>>> little work (I'll do this). >>>>> >>>>> Basically just 1) put buildlocal back how it was 2) push it across >>>>> more platforms e.g. I think FreeBSD/x86 is the main one missing, >>>>> but I'll get to it. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> cvsup building and in "std" (I'll do this, probably very little >>>>> left here really. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- beyond this, not required for release -- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to >>>>> it). >>>>> >>>>> (could be "mingw64" is good enough to try AMD64_NT now). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >>>>> by me) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >>>>> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >>>>> seat to important fixes in existing platforms. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >>>>> skip C __finally blocks. I've just been very lazy here, should >>>>> demonstrate the behavior with a test case, then fix it.. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Maybe fix cm3cg so other -g options besides -gstabs works, like >>>>> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >>>>> leaving nothing, because others cause internal compiler errors, >>>>> like >>>>> on HPPA64_HPUX. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Oh, and NT386GNU probably switched back to Win32 threads. >>>>> Otherwise one of the test cases hangs and it doesn't look easy to >>>>> figure out. I'll do this shortly if I remember. >>>>> >>>>> But I also wouldn't mind if this platform isn't officially >>>>> released >>>>> either (unless someone else wants to support it). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Debug why many NT386MINGNU gui apps crash..but also probably just >>>>> don't release this platform and ok asis. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> - Jay >>>>> >>>> >>>> >>>> >>> >>> >>> >>> CONFIDENTIALITY NOTICE: This email and any attachments are >>> intended solely for the use of the named recipient(s). This e- >>> mail may contain confidential and/or proprietary information of >>> Scientific Research Corporation. If you are not a named >>> recipient, you are prohibited from making any use of the >>> information in the email and attachments. If you believe you >>> have received this email in error, please notify the sender >>> immediately and permanently delete the email, any attachments, >>> and all copies thereof from any drives or storage media and >>> destroy any printouts of the email or attachments. >>> >>> EXPORT COMPLIANCE NOTICE: This email and any attachments may >>> contain technical data subject to U.S export restrictions under >>> the International Traffic in Arms Regulations (ITAR) or the >>> Export Administration Regulations (EAR). Export or transfer of >>> this technical data and/or related information to any foreign >>> person(s) or entity(ies), either within the U.S. or outside of >>> the U.S., may require export authorization by the appropriate >>> U.S. Government agency prior to export or transfer. In >>> addition, technical data may not be exported or transferred to >>> certain countries or specified designated nationals identified >>> by U.S. embargo controls without prior export authorization. By >>> accepting this email and any attachments, all recipients confirm >>> that they understand and will comply with all applicable ITAR, >>> EAR and embargo compliance requirements. >>> >>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Tue May 5 01:14:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 5 May 2009 09:14:37 +1000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> Message-ID: <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> On 5 May 2009, at 02:39, Jay wrote: > >> o complete switch to new Unix headers > > > I386_DARWIN and AMD64_DARWIN not switched. > ok though either way. > > >> o working cvsup (OK AFAIK) > > > ok, though I didn't add it to build automation. > > >> o formsvbt crashes > > Not solved. > I couldn't get an older release to work to verify against. Can you provide a way to repeat your crash? I will try to diagnose and fix. > > > >> o performance issues: threads, exception frames, texts, ... > > > A little better. > I don't think regressed wrt cm3 though. > Can release asis I think. > > >> We must also decide which platforms _must_ be part of the release. >> I'd suggest AMD64_LINUX, LINUXLIBC6, FreeBSD(4/7?), SOLgnu, >> I386_DARWIN (and/or AMD64_DARWIN?), and of course Windows (native and >> Cygwin, however these are called these days ;-) > > > I'd just as soon skip Cygwin. > Maybe we can have some sort of "tiers"? > All of PPC_DARWIN, I386_DARWIN, AMD64_DARWIN can be included. > Many others /can/ be included, but I don't know what must/should be > included. > > >> Should we add more? I'll need support to build several of them. >> >> I suggest that we use the old make_bin_dist_min.sh scripts with >> the core distribution. Or is something better already completely >> automated (possibly by Jay)? > > > I have good automation, with some caveats: > > No cminstall. > A few packages should be added: > m3gdb, cm3ide, cvsup > > > There might be a few copyrights missing, and they might be so > numerous that a directory should be created, if that is "prominent" > enough. > > There is always more work to do.. > > - Jay From jay.krell at cornell.edu Tue May 5 02:07:07 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 5 May 2009 00:07:07 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> Message-ID: >>> o formsvbt crashes >> >> Not solved. >> I couldn't get an older release to work to verify against. > > Can you provide a way to repeat your crash? I will try to diagnose > and fix. while (true) Start up formsvbt. Wait a few seconds. If it doesn't crash, exit it. It happens at least half the time. On PPC_DARWIN and SOL..not sure it was SOLgnu or SOLsun. Did not repro on..I think..LINUXLIBC6, FreeBSD/x86..not sure what all I tried. It seems to somehow be specific to only some platforms. 5.4.0 release had bigger problems here that I forget (on SOLgnu or SOLsun). I only test out X stuff remotely (and don't use X otherwise, what a mess..), though I doubt that matters. I added an assert(foo # NIL) right where the crash is, so now the crash is that assertion failing. - Jay From jay.krell at cornell.edu Tue May 5 09:49:45 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 5 May 2009 07:49:45 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> Message-ID: I meant formedit, not formsvbt. I've seen it now on LINUXLIBC6 but only once in more than 10 runs. jay at localhost ~/dev2/cm3/m3-obliq/obliqlibanim $ /cm3/bin/formsedit *** *** runtime error: *** failed. *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 *** Aborted I added the assertion. It would be followed by a null dereference. C:\dev2\cm3.2\m3-ui\vbtkit\src\lego\POSIX PROCEDURE PaintViewWithShadows (v: T) = ... (* Paint the stripe. *) r := Rect.Inset(stripe, v.shadowPixels); ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, r, stripe); here VBT.PaintTint(v, r, v.shadow.bg); END PaintViewWithShadows; - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release > Date: Tue, 5 May 2009 00:07:07 +0000 > > >>>> o formsvbt crashes >>> >>> Not solved. >>> I couldn't get an older release to work to verify against. >> >> Can you provide a way to repeat your crash? I will try to diagnose >> and fix. > > while (true) > Start up formsvbt. > Wait a few seconds. > If it doesn't crash, exit it. > > > It happens at least half the time. > On PPC_DARWIN and SOL..not sure it was SOLgnu or SOLsun. > Did not repro on..I think..LINUXLIBC6, FreeBSD/x86..not sure what all I tried. > It seems to somehow be specific to only some platforms. > > > 5.4.0 release had bigger problems here that I forget (on SOLgnu or SOLsun). > > > I only test out X stuff remotely (and don't use X otherwise, what a mess..), though I doubt that matters. > I added an assert(foo # NIL) right where the crash is, so now the crash is that assertion failing. > > > > - Jay From jay.krell at cornell.edu Tue May 5 09:54:36 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 5 May 2009 07:54:36 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> <20090504164657.1jkipn31w84ccw08@mail.elegosoft.com> <77301372-B1C1-456E-8F51-0725FFF49AE2@cs.purdue.edu> Message-ID: seen it on FreeBSD/x86 7.0 now too but also rare. Seemed much more common on Solaris and PPC_DARWIN, which I will try again shortly. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release > Date: Tue, 5 May 2009 07:49:45 +0000 > > > I meant formedit, not formsvbt. > I've seen it now on LINUXLIBC6 but only once in more than 10 runs. > > > jay at localhost ~/dev2/cm3/m3-obliq/obliqlibanim $ /cm3/bin/formsedit > > > *** > *** runtime error: > *** failed. > *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 > *** > Aborted > > > I added the assertion. > It would be followed by a null dereference. > > > C:\dev2\cm3.2\m3-ui\vbtkit\src\lego\POSIX > > > > PROCEDURE PaintViewWithShadows (v: T) = > ... > (* Paint the stripe. *) > r := Rect.Inset(stripe, v.shadowPixels); > ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, > r, stripe); > > here > > > VBT.PaintTint(v, r, v.shadow.bg); > END PaintViewWithShadows; > > > > - Jay > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release >> Date: Tue, 5 May 2009 00:07:07 +0000 >> >> >>>>> o formsvbt crashes >>>> >>>> Not solved. >>>> I couldn't get an older release to work to verify against. >>> >>> Can you provide a way to repeat your crash? I will try to diagnose >>> and fix. >> >> while (true) >> Start up formsvbt. >> Wait a few seconds. >> If it doesn't crash, exit it. >> >> >> It happens at least half the time. >> On PPC_DARWIN and SOL..not sure it was SOLgnu or SOLsun. >> Did not repro on..I think..LINUXLIBC6, FreeBSD/x86..not sure what all I tried. >> It seems to somehow be specific to only some platforms. >> >> >> 5.4.0 release had bigger problems here that I forget (on SOLgnu or SOLsun). >> >> >> I only test out X stuff remotely (and don't use X otherwise, what a mess..), though I doubt that matters. >> I added an assert(foo # NIL) right where the crash is, so now the crash is that assertion failing. >> >> >> >> - Jay From martinbishop at bellsouth.net Wed May 6 02:57:43 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Tue, 05 May 2009 19:57:43 -0500 Subject: [M3devel] Possible Bug? Message-ID: <4A00E087.2000100@bellsouth.net> I have this code, for finding the roots of a quadratic equation: MODULE Quad EXPORTS Main; IMPORT IO, Fmt, RealSqrt; TYPE Roots = ARRAY [1..2] OF REAL; VAR r: Roots; PROCEDURE Solve(a, b, c: REAL): Roots = VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); x: REAL; BEGIN IF b < 0.0 THEN x := (-b + sd) / 2.0 * a; RETURN Roots{x, c / (a * x)}; ELSE x := (-b - sd) / 2.0 * a; RETURN Roots{c / (a * x), x}; END; END Solve; BEGIN r := Solve(1.0, -10.0E5, 1.0); IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); END Quad. When I try to build it, I get: *** *** runtime error: *** <*ASSERT*> failed: FloatMode.SetRounding not implemented *** file "../src/float/IEEE-default/FloatMode.m3", line 14 *** Aborted I'm using: martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version Critical Mass Modula-3 version d5.7.1 last updated: 2009-01-21 compiled: 2009-04-01 13:11:43 configuration: /usr/local/bin/cm3.cfg which was installed from Jay's "std" binary package. From jay.krell at cornell.edu Wed May 6 03:31:29 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 6 May 2009 01:31:29 +0000 Subject: [M3devel] Possible Bug? In-Reply-To: <4A00E087.2000100@bellsouth.net> References: <4A00E087.2000100@bellsouth.net> Message-ID: This has never worked on most platforms. We even deliberately stopped it working where it did -- e.g. SPARC. We could fix it maybe. Please try RealFloat.sqrt instead. It is almost the same thing, but for lack of ability to use single precision, and is likely to be much much faster (how common is hardware sqrt? Anyway, vendor software sqrt is presumably excellent). In future please give callstacks. Run it under gdb or dbx, etc. - Jay ---------------------------------------- > Date: Tue, 5 May 2009 19:57:43 -0500 > From: martinbishop at bellsouth.net > To: m3devel at elegosoft.com > Subject: [M3devel] Possible Bug? > > I have this code, for finding the roots of a quadratic equation: > > MODULE Quad EXPORTS Main; > > IMPORT IO, Fmt, RealSqrt; > > TYPE Roots = ARRAY [1..2] OF REAL; > > VAR r: Roots; > > PROCEDURE Solve(a, b, c: REAL): Roots = > VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); > x: REAL; > BEGIN > IF b < 0.0 THEN > x := (-b + sd) / 2.0 * a; > RETURN Roots{x, c / (a * x)}; > ELSE > x := (-b - sd) / 2.0 * a; > RETURN Roots{c / (a * x), x}; > END; > END Solve; > > BEGIN > r := Solve(1.0, -10.0E5, 1.0); > IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); > END Quad. > > When I try to build it, I get: > > *** > *** runtime error: > *** failed: FloatMode.SetRounding not implemented > *** file "../src/float/IEEE-default/FloatMode.m3", line 14 > *** > > Aborted > > > I'm using: > > martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version > Critical Mass Modula-3 version d5.7.1 > last updated: 2009-01-21 > compiled: 2009-04-01 13:11:43 > configuration: /usr/local/bin/cm3.cfg > > which was installed from Jay's "std" binary package. From jay.krell at cornell.edu Wed May 6 03:38:47 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 6 May 2009 01:38:47 +0000 Subject: [M3devel] Possible Bug? In-Reply-To: <4A00E087.2000100@bellsouth.net> References: <4A00E087.2000100@bellsouth.net> Message-ID: I suggest we provide Cmath.i3 and/or Cfloat.i3 to provide trivial portable wrappers to some of this stuff in an easier to find location instead of buried. Granted, the buriers were trying to make things better in their way. And by portable, I'd limit myself probably to double foo(double); and not likely delve into single precision functions, unless maybe float foof(float) is fairly portable. Eh, since they'd all be external, you can delcare them all and not necessarily implement all of them. In any case the perf might stink compared to C. Visual C++ for example can generate FPU instructions inline such as for sqrt. gcc probably does a good job here too. We'll likely incur function calls for portability. Imho we need to do better with keeping up with "builtin functions" that C compilers gradually accrue and implement very well. It is difficult though, for reasons of portability. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: martinbishop at bellsouth.net; m3devel at elegosoft.com > Subject: RE: [M3devel] Possible Bug? > Date: Wed, 6 May 2009 01:31:29 +0000 > > > This has never worked on most platforms. > We even deliberately stopped it working where it did -- e.g. SPARC. > We could fix it maybe. > > > Please try RealFloat.sqrt instead. > > > It is almost the same thing, but for lack of ability to use single precision, and is likely to be much much faster (how common is hardware sqrt? Anyway, vendor software sqrt is presumably excellent). > > > In future please give callstacks. > Run it under gdb or dbx, etc. > > > - Jay > > > > ---------------------------------------- >> Date: Tue, 5 May 2009 19:57:43 -0500 >> From: martinbishop at bellsouth.net >> To: m3devel at elegosoft.com >> Subject: [M3devel] Possible Bug? >> >> I have this code, for finding the roots of a quadratic equation: >> >> MODULE Quad EXPORTS Main; >> >> IMPORT IO, Fmt, RealSqrt; >> >> TYPE Roots = ARRAY [1..2] OF REAL; >> >> VAR r: Roots; >> >> PROCEDURE Solve(a, b, c: REAL): Roots = >> VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); >> x: REAL; >> BEGIN >> IF b < 0.0 THEN >> x := (-b + sd) / 2.0 * a; >> RETURN Roots{x, c / (a * x)}; >> ELSE >> x := (-b - sd) / 2.0 * a; >> RETURN Roots{c / (a * x), x}; >> END; >> END Solve; >> >> BEGIN >> r := Solve(1.0, -10.0E5, 1.0); >> IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); >> END Quad. >> >> When I try to build it, I get: >> >> *** >> *** runtime error: >> *** failed: FloatMode.SetRounding not implemented >> *** file "../src/float/IEEE-default/FloatMode.m3", line 14 >> *** >> >> Aborted >> >> >> I'm using: >> >> martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version >> Critical Mass Modula-3 version d5.7.1 >> last updated: 2009-01-21 >> compiled: 2009-04-01 13:11:43 >> configuration: /usr/local/bin/cm3.cfg >> >> which was installed from Jay's "std" binary package. From mika at async.caltech.edu Wed May 6 04:24:31 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 05 May 2009 19:24:31 -0700 Subject: [M3devel] Possible Bug? In-Reply-To: Your message of "Wed, 06 May 2009 01:38:47 -0000." Message-ID: <200905060224.n462OVIR060238@camembert.async.caltech.edu> I don't think it's particularly hard to find...? The interface I almost always use is "Math.i3" and it has things like this in it: <*EXTERNAL*> PROCEDURE sqrt (x: LONGREAL): LONGREAL; (* returns the square root of x. *) I think you get pretty good performance with that. If you want speed on x86, you code in f77 and use Intel's ifort (-sse2, or whatever hardware you have in your machine). You can get it free for Linux. I compile -S on Linux and then use GNU as on FreeBSD to get my objects. It's really easy to link that code with M3 if you want to do that. All you have to remember is that all the arrays are transposed and in Fortran they start from 1, of course. Then you just pass ADR(a[0,..,0]) to the f77 code. But my experience has been that Modula-3 code really doesn't perform that poorly on numerical work. If you turn on optimization, that is. Mika Jay writes: > >I suggest we provide Cmath.i3 and/or Cfloat.i3 to provide trivial portable wrappers to some of this stuff in an easier to find location instead of buried. Granted, the buriers were trying to make things bette >r in their way. > > >And by portable, I'd limit myself probably to >double foo(double); > > >and not likely delve into single precision functions, unless maybe >float foof(float) is fairly portable. > >Eh, since they'd all be external, you can delcare them all and not necessarily implement all of them. > > >In any case the perf might stink compared to C. >Visual C++ for example can generate FPU instructions inline such as for sqrt. >gcc probably does a good job here too. >We'll likely incur function calls for portability. > > >Imho we need to do better with keeping up with "builtin functions" that C compilers gradually accrue and implement very well. >It is difficult though, for reasons of portability. > > > - Jay > >---------------------------------------- >> From: jay.krell at cornell.edu >> To: martinbishop at bellsouth.net; m3devel at elegosoft.com >> Subject: RE: [M3devel] Possible Bug? >> Date: Wed, 6 May 2009 01:31:29 +0000 >> >> >> This has never worked on most platforms. >> We even deliberately stopped it working where it did -- e.g. SPARC. >> We could fix it maybe. >> >> >> Please try RealFloat.sqrt instead. >> >> >> It is almost the same thing, but for lack of ability to use single precision, and is likely to be much much faster (how common is hardware sqrt? Anyway, vendor software sqrt is presumably excellent). >> >> >> In future please give callstacks. >> Run it under gdb or dbx, etc. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Tue, 5 May 2009 19:57:43 -0500 >>> From: martinbishop at bellsouth.net >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] Possible Bug? >>> >>> I have this code, for finding the roots of a quadratic equation: >>> >>> MODULE Quad EXPORTS Main; >>> >>> IMPORT IO, Fmt, RealSqrt; >>> >>> TYPE Roots = ARRAY [1..2] OF REAL; >>> >>> VAR r: Roots; >>> >>> PROCEDURE Solve(a, b, c: REAL): Roots = >>> VAR sd: REAL := RealSqrt.Sqrt(b * b - 4.0 * a * c); >>> x: REAL; >>> BEGIN >>> IF b < 0.0 THEN >>> x := (-b + sd) / 2.0 * a; >>> RETURN Roots{x, c / (a * x)}; >>> ELSE >>> x := (-b - sd) / 2.0 * a; >>> RETURN Roots{c / (a * x), x}; >>> END; >>> END Solve; >>> >>> BEGIN >>> r := Solve(1.0, -10.0E5, 1.0); >>> IO.Put("X1 = " & Fmt.Real(r[1]) & " X2 = " & Fmt.Real(r[2]) & "\n"); >>> END Quad. >>> >>> When I try to build it, I get: >>> >>> *** >>> *** runtime error: >>> *** failed: FloatMode.SetRounding not implemented >>> *** file "../src/float/IEEE-default/FloatMode.m3", line 14 >>> *** >>> >>> Aborted >>> >>> >>> I'm using: >>> >>> martin at thinkpad:~/Code/Modula-3/Test$ cm3 -version >>> Critical Mass Modula-3 version d5.7.1 >>> last updated: 2009-01-21 >>> compiled: 2009-04-01 13:11:43 >>> configuration: /usr/local/bin/cm3.cfg >>> >>> which was installed from Jay's "std" binary package. From jay.krell at cornell.edu Wed May 6 15:53:25 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 6 May 2009 13:53:25 +0000 Subject: [M3devel] heapalloc/try during initialization In-Reply-To: References: <20090506002150.A15FECC3B4@birch.elegosoft.com> <46F424EA-6C63-42C4-A120-C1B0FD394AA6@cs.purdue.edu> <54967B00-3878-4147-AA90-FBD09F98161B@cs.purdue.edu> Message-ID: Something like the attached? (I don't trust email to be formated as expected, so the attachment is canonical and the rest might not be readable.) The idea is to provide a split CollectEnough for AllocTraced to call. It's a little lose on the locking but it should be ok and slows down the slow path with extra unlock/relock. It's good to get the try out of the fast path in either case. PROCEDURE LockedCollectEnough (allocator := FALSE) = BEGIN TRY CollectEnough(allocator); FINALLY RTOS.UnlockHeap(); END; END LockedCollectEnough; AllocTraced calls this: PROCEDURE UnlockedCollectEnough (allocator := FALSE) = BEGIN RTOS.LockHeap(); IF collectorOn THEN RTOS.UnlockHeap(); RETURN END; (* duplicated from CollectEnough *) IF NOT Behind() THEN RTOS.UnlockHeap(); RETURN END; (* duplicated from CollectEnough *) ThreadF.Init shouldn't get here: LockedCollectEnough(allocator); END UnlockedCollectEnough; AllocTraced slow path excerpt: IF nextPtr> thread.newPool.limit THEN (* not enough space left in the pool, take the long route *) res := NIL; nextPtr := NIL; (* in case of GC... *) DEC(thread.inCritical); (* make sure the collector gets a chance to keep up with NEW... *) UnlockedCollectEnough(allocator := TRUE); (***) RTOS.LockHeap(); (***) res := LongAlloc (dataSize, dataAlignment, thread.newPool, Note.Allocated, pure := FALSE); IF