From hosking at cs.purdue.edu Mon Jun 1 01:01:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 1 Jun 2009 09:01:55 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> Jay, things changed from gcc 3.2 to 3.3. 3.3 works fine for me on all the h/w targets I've tried using -O3 (PPC, x86, AMD64, SPARC). I suspect this is specific to your gcc-apple hybrid. On 1 Jun 2009, at 00:49, Jay wrote: > 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 jay.krell at cornell.edu Mon Jun 1 18:46:38 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 1 Jun 2009 16:46:38 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> References: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> Message-ID: It isn't related to optimization. I don't think it is 4.2/4.3 specific. I'll try to show an example later (MIPS64_OPENBSD and, never looked at them, but maybe othar arm/mips will show it). - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 1 Jun 2009 09:01:55 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] m3_load/store using bitfields for everything Jay, things changed from gcc 3.2 to 3.3. 3.3 works fine for me on all the h/w targets I've tried using -O3 (PPC, x86, AMD64, SPARC). I suspect this is specific to your gcc-apple hybrid. On 1 Jun 2009, at 00:49, Jay wrote: 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 rodney.m.bates at cox.net Mon Jun 1 21:32:33 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 01 Jun 2009 14:32:33 -0500 Subject: [M3devel] Some workarounds for m3gdb input and output of floating values. Message-ID: <4A242CD1.10504@cox.net> I recently committed a couple of changes that give m3gdb some very tenuous support of floating values. Printing them appears to work in a few tests on LINUXLIBC6. This relies on the preexisting C floating support, but this really needs some more thorough review. Moreover, Modula-3 style floating literals are not being recognized. Until it is fixed right, here are some ways to work around its limitations. They are a bit tedious, but should allow you to do what you need to do, using m3gdb calls on Modula-3 library code. The idea is just to call procedures in Lex, Fmt, etc. To print a value in Modula-3 form, do, e.g.: (m3gdb) print Fmt.Real(LF,Fmt.Style.Fix,10,FALSE) $1 = (*16_b737876c*) "1.1250000000" Note that m3gdb has no knowledge of defaulted parameters, so you have to supply them all explicitly. To assign a literal value, do, e.g.: (m3gdb) print LF := Lex.Real(TextRd.New("2.375")) $2 = 2.375 (m3gdb) p Fmt.Real(LF,Fmt.Style.Fix,10,FALSE) $3 = (*16_b73787dc*) "2.3750000000" Few or none of these calls will work unless Lex, Fmt, and TextRd are imported somewhere in the import closure of your program. Otherwise, they have uninitialized data and many will segfault or otherwise fail when called by m3gdb. Rodney Bates From hosking at cs.purdue.edu Tue Jun 2 02:04:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 2 Jun 2009 10:04:37 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> Message-ID: <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> The compiler and run-time support is already in the CVS head. On 1 Jun 2009, at 22:21, Darko wrote: > This is a great little hack. Is it available now or are you still > working on it? I don't know what other people want to use it for but > this is a great way to link memory structures with external data. It > overcomes one of the downsides of GC compared to say C, where you > can use pointer values for other purposes, but it does it safely. > > Also I'd like to add my voice for the minimalist approach where no > language changes are made. I don't think there is a semantically > clean way of incorporating this into the language and I'm not sure > there is any payoff in doing so. > > > > On 23/04/2009, at 3:07 AM, Tony Hosking wrote: > >> On 23 Apr 2009, at 09:41, Mika Nystrom wrote: >> >>> "Rodney M. Bates" writes: >>>> Tony Hosking wrote: >>>>> On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: >>>>> >>>>>> I am going to try to resummarize the various proposals, as their >>>>>> description has now gotten rather scattered around in all the >>>>>> discussion. >>>>>> --------------------------------------------------------------------- >>>>>> Mika's proposal (I'll call it the "minimalist" propsal): >>>>>> >>>>>> Mika, please correct me if I misrepresent what you are proposing. >>>>>> >>>>>> There are no language changes at all, only changes in >>>>>> implementation. >>>>>> The implementation of the existing type REFANY, and no other >>>>>> type, >>>>>> allows it to have values whose lsb is nonzero. ISTYPE, NARROW, >>>>>> TYPECASE, and narrowing assignments, when and only when applied >>>>>> to >>>>>> REFANY, have their generated code fixed so it checks the lsb, >>>>>> and, if >>>>>> it is nonzero, consider the runtime type check to have failed, in >>>>>> whichever way such a failure is already handled. >>>>>> >>>>>> The only effect is to liberalize the rules unsafe code must >>>>>> follow to >>>>>> avoid undermining the safety of safe code. Only unsafe code can >>>>>> create or detect these misaligned values. Today, it must never >>>>>> return >>>>>> them in a variable of any reference type, lest the four narrowing >>>>>> operations unexpectedly crash. In the proposal, unsafe code >>>>>> would be >>>>>> able to return such values in variables of type REFANY, but not >>>>>> any >>>>>> other type. >>> >>> This is pretty much exactly what I was proposing, yes. >>> >>> Only one point to add, and that is that you need a TYPECODE value. >> >> Yes. I currently have a full-blown implementation in the compiler >> and run-time that uses RT0.RefanyTypecode as the typecode. Since >> the only thing that will respond with the typecode are tagged >> references, and it is not legal to say TYPECODE(REFANY) we can hide >> that fact in an implementation of the tagged interface where we use >> TYPECODE(r) = RT0.RefanyTypecode, or ISTYPE(r, >> RT0.RefanyTypecode). Currently, no other type in the system will >> respond with that. >> >>> I think Tony and I discussed having all the ISTYPE etc. behave as >>> if the tagged values were of a specific opaque type that cannot be >>> dereferenced, newed, etc., in safe modules. (I.e., revealed as <: >>> REFANY only) >> >> Done (modulo what typecode to use as described above). >> >>> This seems conceptually simpler than introducing a "nonexistent" >>> type, and has the same safety properties. >>> >>>>> >>>>> I don't see why we can't have safe creation of the misaligned >>>>> values >>>>> as per Mika's interface. >>>> >>>> Well, somebody has to implement that interface, and that module >>>> will >>>> have to be UNSAFE. >>>> You weren't thinking of implementing it in C were you? ;-) >>> >>> I don't see how to do it "safely" unless you add it to the compiler >>> itself? (Which means it's no longer minimalist!) >> >> It would be hidden behind a safe interface. >> >>>>>> Already, the only things safe code can do with values of REFANY >>>>>> are >>>>>> copy them around (which would happily work on misaligned >>>>>> values) and >>>>>> narrow them. With the implementation of the narrowing operations >>>>>> changed, misaligned values can never escape from REFANY >>>>>> variables. >>>>>> >>>>>> In safe code, there is no way to detect whether a value of type >>>>>> REFANY >>>>>> is misaligned. Doing it by elimination, trying to narrow to any >>>>>> proper subtype of REFANY, is impractical, as there are an >>>>>> unbounded >>>>>> number of REF types to eliminate. >>>>> >>>>> An alternative would be to loosen the language spec to allow >>>>> TYPECODE(REFANY) and use this typecode for tagged references. >>>>> Then >>>>> one can explicitly test for it without elimination of >>>>> alternatives. >>> >>> Yes you could do this or use the specific type idea mentioned above. >>> >>> I don't see what harm there is in letting a safe module know that >>> it's holding a tagged value. Nothing it can do with that >>> information >>> anyhow... it can't extract the value. >>> >>>>> >>>>>> If there is more than one abstract data type that uses this >>>>>> mechanism, >>>>>> client code can not be prevented from mixing up values from the >>>>>> different abstractions. (Perhaps this could be fixed by a >>>>>> language >>>>>> change allowing BRANDED REFANY?) >>>>> >>>>> Indeed. >>> >>> Right. As it stands, the clients would have to sort on what's going >>> on inside. No help from compiler or runtime. You can't do anything >>> about what's checkable at runtime, but adding TAGGED could let you >>> check a lot of things at compile time. >>> >>> I still think, though (referring to what's below), that the >>> advantage >>> of not having to change existing "container" code outweighs the >>> cost of checking the LSB (which is likely to be negligble), and I >>> would >>> therefore recommend that the type called "REFANY" be able to hold >>> "TAGGED" >>> values after such a language change. >> >> Right. >> >>> >>> >>> Mika >>> >>>>> >>>>>> --------------------------------------------------------------------- >>>>>> My (Rodney's) "safe" proposal: >>>>>> >>>>>> There is a new type named TAGABLE. It is a subrange of >>>>>> INTEGER, whose >>>>>> bounds are implementation-defined. These can be queried by the >>>>>> existing FIRST and LAST functions. Similar to CARDINAL, it has >>>>>> all >>>>>> the properties of a subrange type but is not the same type as the >>>>>> corresponding subrange. >>>>>> >>>>>> There is a new type constructor TAGGED. If T is any traced or >>>>>> object >>>>>> type, including branded and opaque types, then TAGGED T is a >>>>>> new type >>>>>> whose value set is the union of the value sets of T and TAGABLE. >>>>>> Moreover, >>>>>> >>>>>> TAGABLE <: TAGGED T >>>>>> T <: TAGGED T. >>>>>> >>>>>> IF T # U, then TAGGED T and TAGGED U are not the same type and >>>>>> have no >>>>>> subtype or assignability relation to each other. >>>>>> >>>>>> The semantics of ISTYPE, NARROW, TYPECASE, and assignability of >>>>>> a type >>>>>> to a type are generalized so that their to-be-narrowed operand >>>>>> can >>>>>> have a tagged type, and if it does, their to-be-narrowed-to >>>>>> type can >>>>>> be TAGABLE. >>>>> >>>>> Hmm. It seems there is a nasty loophole in your spec. >>>>> Consider: >>>>> >>>>> TYPE T = BRANDED OBJECT END >>>>> TYPE U = BRANDED OBJECT END >>>>> >>>>> These are unrelated types. >>>>> >>>>> Now, the rules let me take: >>>>> >>>>> t: TAGGED T >>>>> >>>>> and obtain: >>>>> >>>>> i: TAGABLE := NARROW(t, TAGABLE); >>>>> >>>>> But TAGABLE <: TAGGED U >>>>> >>>>> so I can do: >>>>> >>>>> u: TAGGED U := t; >>>>> >>>>> Is that your intention? >>>>> >>>>>> >>>>>> >>>>>> Comments: >>>>>> >>>>>> Making TAGGED T have no relation to TAGGED U avoids a lot of >>>>>> really >>>>>> complicated type equality and subtype rules. The former would >>>>>> be a >>>>>> drastic departure from the current state of Modula-3. >>>>>> >>>>>> It is up to the implementation to decide the bit representation >>>>>> of >>>>>> tagged types, including how values of TAGABLE will be >>>>>> distinguished >>>>>> from reference values. Though the language would not require >>>>>> it, most >>>>>> likely a word the same size as a pointer will be used. Using >>>>>> the lsb >>>>>> as the tag bit is an efficient encoding, because in any currently >>>>>> conceivable machine, it will be zero for all pointers to heap >>>>>> objects. >>>>>> There is no reason pickles would have to use the same >>>>>> representation >>>>>> as compiler-generated code. >>>>>> >>>>>> The implementation should define the bounds of TAGABLE to be >>>>>> whatever >>>>>> it can fit in its representation, after removing the values >>>>>> that are >>>>>> true pointers. If the lsb is used as a tag, this will no doubt >>>>>> be a >>>>>> 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit >>>>>> machine. The language wouldn't even specify whether it is >>>>>> signed, >>>>>> although somehow unsigned seems nice to me. If it is unsigned >>>>>> and the >>>>>> suggested encodings are used, TAGABLE would have the same >>>>>> bounds as >>>>>> CARDINAL, but it really should be a separate type, so as not to >>>>>> overconstrain the implementation. >>>>>> >>>>>> If T is branded, then the effects of branding will propagate to >>>>>> TAGGED >>>>>> T, thus allowing independent abstract data types to ensure each >>>>>> one's >>>>>> values can't be mixed up with the other's. This will statically >>>>>> detect misuses by client code. However, TAGGED T is not a >>>>>> branded >>>>>> type. >>>>>> >>>>>> If T is an opaque type, then TAGGED T can be used to combine >>>>>> the space >>>>>> efficiency of tagging with the ability of an opaque type to >>>>>> reveal >>>>>> some but not all of its properties. To use this, client code >>>>>> will >>>>>> have to narrow a value first, since access to methods/fields >>>>>> could not >>>>>> have a definable meaning for a value in TAGABLE. >>>>>> >>>>>> On the other hand, T could be an opaque subtype of REFANY, thus >>>>>> revealing almost nothing about TAGGED T to clients. This would >>>>>> give >>>>>> tagged types the existing ability of ensuring statically, that >>>>>> the >>>>>> code in a revealed context will never get TAGGED REFANY, thus >>>>>> avoiding >>>>>> extra runtime type checks. >>>>> >>>>> >> From jay.krell at cornell.edu Tue Jun 2 12:20:30 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 2 Jun 2009 10:20:30 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> References: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> Message-ID: ARM_LINUX looks ok. Now..I experimented with the size/alignment of the module-globals. If I decrease them to 8, it infects the uses of "components" of it (bitfields). RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.102 diff -u -r1.102 parse.c @@ -2989,7 +2989,7 @@ gcc doesn't think it fits in a register, so that loads out of it do get their offsets applied. */ TREE_TYPE (v) - = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT); + = m3_build_type (T_struct, 8, 8); layout_decl (v, BIGGEST_ALIGNMENT); TYPE_UNSIGNED (TREE_TYPE (v)) = 1; TREE_STATIC (v) = 1; bl RTOS__Write(PLT) .stabn 68,0,79,.LM45-.LFBB8 .LM45: ldr r3, .L40+4 ldr r1, [fp, #-16] ldr r2, [r1, r3] ldrb r1, [r2, #52] mov r3, #0 mov r1, r3 strb r1, [r2, #52] Those "b for byte" shouldn't be there. The problem is more obvious on the reads -- lots of shifting and masking. .stabn 68,0,78,.LM44-.LFBB8 .LM44: ldr r3, .L40+4 ldr r1, [fp, #-16] ldr r2, [r1, r3] ldrb r3, [r2, #52] and r1, r3, #255 ldrb r3, [r2, #53] and r3, r3, #255 mov r3, r3, asl #8 orr r1, r3, r1 ldrb r3, [r2, #54] and r3, r3, #255 mov r3, r3, asl #16 orr r1, r3, r1 mov r3, r3, asl #16 orr r1, r3, r1 ldrb r3, [r2, #55] and r3, r3, #255 mov r3, r3, asl #24 orr r3, r3, r1 cmp r3, #0 ble .L39 Now, I grant that this "experiment" is a bit of garbage in, garbage out, but I think showing that the size/alignment of a symbol that we use merely for generating offsets from has big affects is a little worrisome. Ok, I grant, if this is just ensuring aligned reads, that's reasonable. I should twiddle just the size and not the alignment. "To be constructive" if I managed to form a patch that declared the module-globals to a be struct (record) with well described/typed/sized/aligned "components" (fields/members/etc.) and we used..hm..it seems we never access fields, just offsets? sentence was going to end "..that'd be a reasonable change?" Eh, for now probably not worth it, it does work given the large size/alignment and slow path for iphone, other stuff to do... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] m3_load/store using bitfields for everything Date: Mon, 1 Jun 2009 16:46:38 +0000 It isn't related to optimization. I don't think it is 4.2/4.3 specific. I'll try to show an example later (MIPS64_OPENBSD and, never looked at them, but maybe othar arm/mips will show it). - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 1 Jun 2009 09:01:55 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] m3_load/store using bitfields for everything Jay, things changed from gcc 3.2 to 3.3. 3.3 works fine for me on all the h/w targets I've tried using -O3 (PPC, x86, AMD64, SPARC). I suspect this is specific to your gcc-apple hybrid. On 1 Jun 2009, at 00:49, Jay wrote: 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 hendrik at topoi.pooq.com Tue Jun 2 12:31:52 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 2 Jun 2009 06:31:52 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> Message-ID: <20090602103152.GA2916@topoi.pooq.com> On Tue, Jun 02, 2009 at 10:04:37AM +1000, Tony Hosking wrote: > The compiler and run-time support is already in the CVS head. > > On 1 Jun 2009, at 22:21, Darko wrote: > > >This is a great little hack. Is it available now or are you still > >working on it? I don't know what other people want to use it for but > >this is a great way to link memory structures with external data. It > >overcomes one of the downsides of GC compared to say C, where you > >can use pointer values for other purposes, but it does it safely. > > > >Also I'd like to add my voice for the minimalist approach where no > >language changes are made. I don't think there is a semantically > >clean way of incorporating this into the language and I'm not sure > >there is any payoff in doing so. I think there is a semantically clean way of incorporating it into the language, but it's not a trivial change. It becomes an optimisable special case of a more general feature -- for any bunch of types A, B, C, ... you introduce a type UNION(A, B, C, ...). There's nothing you can do with a union except build it from an A, B, or C ..., copy it, and test its type and extract the contents -- more or less what you can do to one of our type-tagged values. These unions have a fixed size (more or less the max of the sizes of A, B, C, ... and an extra type-tag. (I don't know if there has to be a restriction on using open arrays here; I hole not.) In the special case of UNION(A, B), where B is a suitable subrange if INTEGER and A is a pointer-to-object, the compiler could choose to implement this with our low-bit-and-shift hack. -- hendrik From hosking at cs.purdue.edu Tue Jun 2 12:51:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 2 Jun 2009 20:51:31 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20090602103152.GA2916@topoi.pooq.com> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> Message-ID: <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> Union types are anathema to the design of the Modula-3 type system. On 2 Jun 2009, at 20:31, hendrik at topoi.pooq.com wrote: > On Tue, Jun 02, 2009 at 10:04:37AM +1000, Tony Hosking wrote: >> The compiler and run-time support is already in the CVS head. >> >> On 1 Jun 2009, at 22:21, Darko wrote: >> >>> This is a great little hack. Is it available now or are you still >>> working on it? I don't know what other people want to use it for but >>> this is a great way to link memory structures with external data. It >>> overcomes one of the downsides of GC compared to say C, where you >>> can use pointer values for other purposes, but it does it safely. >>> >>> Also I'd like to add my voice for the minimalist approach where no >>> language changes are made. I don't think there is a semantically >>> clean way of incorporating this into the language and I'm not sure >>> there is any payoff in doing so. > > I think there is a semantically clean way of incorporating it into the > language, but it's not a trivial change. It becomes an optimisable > special case of a more general feature -- for any bunch of types A, B, > C, ... you introduce a type UNION(A, B, C, ...). There's nothing you > can do with a union except build it from an A, B, or C ..., copy it, > and > test its type and extract the contents -- more or less what you can do > to one of our type-tagged values. These unions have a fixed size > (more > or less the max of the sizes of A, B, C, ... and an extra type-tag. > (I don't know if there has to be a restriction on using open arrays > here; I hole not.) > > In the special case of UNION(A, B), where B is a suitable subrange if > INTEGER and A is a pointer-to-object, the compiler could choose to > implement this with our low-bit-and-shift hack. > > -- hendrik From hendrik at topoi.pooq.com Tue Jun 2 13:23:53 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 2 Jun 2009 07:23:53 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> Message-ID: <20090602112353.GB2916@topoi.pooq.com> On Tue, Jun 02, 2009 at 08:51:31PM +1000, Tony Hosking wrote: > Union types are anathema to the design of the Modula-3 type system. So I have heard. But I don't understand why. Certainly variant records a la Pascal would be for security reasons. Did they get tarred with the same brush? Or were unions considered unnecessary once the language had objects and inheritance? -- hendrik From hendrik at topoi.pooq.com Tue Jun 2 17:52:47 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 2 Jun 2009 11:52:47 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <5DE9B69F-9493-4A6D-B7C8-1CEABC4BAE43@darko.org> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> <20090602112353.GB2916@topoi.pooq.com> <5DE9B69F-9493-4A6D-B7C8-1CEABC4BAE43@darko.org> Message-ID: <20090602155246.GC3481@topoi.pooq.com> On Tue, Jun 02, 2009 at 04:33:49PM +0200, Darko wrote: > Probably because some union fields disappear and you can't work out > statically if a field access is valid. That's the problem with variant records in Pascal. I don't like them either. They're not what I'm talking about. If you have a value of type UNION(A, B) you don't get to use an operation on it just because the operation happens to be valid on A. > Maybe you chose the wrong name > for your type, because they are actually just dynamically typed values > rather than unions. The unions I'm talking about are disjount unions, the things the category theorists oftern call coproducts. They are dual to Cartesion products (which are provided in Moduls 3). They are type-secure. My unions comprise a finite number of other types, which means that in one place you can see everything that can happen to them. You don't run the risk that somewhere else someone sticks more alternatives into your type by inheriting form it. (this can be a curse or a blessing, depending on how your code is organised. It tends to be awkward to do object-oriented code with these unions, just as it's awkward using objects and inheritance when you really want unions) > Maybe you should have called them 'overlays' I'm not taking about interpreting physical storage in multiple different ways. I'm not talking about tools to store a REAL and fetch an INTEGER in order to cut it up with maske to get at the exponent and mantissa. That's UNSAFE. I'm talking about a type-safe alternative mechanism in data structures. One which is more efficient is some circumstances that the one traditionally embedded in Modula 3 (else we wouldn't be having this discussion), but less efficient in others (such as unions of huge records). But what I'd like to know is why they are considered an anathema instead of just an alternative not taken. Perhaps way back then they were talking about different language features. But treating them as anathema seems to have poisoned thinking about any kind of remotely similar feature, even type-safe ones. -- hendrik > > On 02/06/2009, at 1:23 PM, hendrik at topoi.pooq.com wrote: > > >On Tue, Jun 02, 2009 at 08:51:31PM +1000, Tony Hosking wrote: > >>Union types are anathema to the design of the Modula-3 type system. > > > >So I have heard. But I don't understand why. Certainly > >variant records a la Pascal would be for security reasons. > >Did they get tarred with the same brush? Or were unions > >considered unnecessary once the language had objects and > >inheritance? > > > >-- hendrik > From jay.krell at cornell.edu Tue Jun 2 17:52:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 2 Jun 2009 15:52:43 +0000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20090602112353.GB2916@topoi.pooq.com> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> <20090602112353.GB2916@topoi.pooq.com> Message-ID: Um, but can't tagged unions be safe? Can't you tell the compiler which tag maps to which part of the union and all reads would be checked? And writes would set the tag? Something like that? Plus optimize away some of the tag checks. And then like you say, sometimes the tag can be combined with the value, nice description. After all, tagged unions are the only type in Microsoft VBScript and JScript, safe languages. Granted, as you say, objects often fit the same scenarios. - Jay > Date: Tue, 2 Jun 2009 07:23:53 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Resummary of tagged reference proposals > > On Tue, Jun 02, 2009 at 08:51:31PM +1000, Tony Hosking wrote: > > Union types are anathema to the design of the Modula-3 type system. > > So I have heard. But I don't understand why. Certainly > variant records a la Pascal would be for security reasons. > Did they get tarred with the same brush? Or were unions > considered unnecessary once the language had objects and > inheritance? > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jun 3 00:49:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Jun 2009 08:49:59 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20090602112353.GB2916@topoi.pooq.com> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> <20090602112353.GB2916@topoi.pooq.com> Message-ID: Yes, objects + inheritance. I think there is a discussion in "How the language got its spots" in "Systems Programming in Modula-3". On 2 Jun 2009, at 21:23, hendrik at topoi.pooq.com wrote: > On Tue, Jun 02, 2009 at 08:51:31PM +1000, Tony Hosking wrote: >> Union types are anathema to the design of the Modula-3 type system. > > So I have heard. But I don't understand why. Certainly > variant records a la Pascal would be for security reasons. > Did they get tarred with the same brush? Or were unions > considered unnecessary once the language had objects and > inheritance? > > -- hendrik From hendrik at topoi.pooq.com Wed Jun 3 19:14:07 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 3 Jun 2009 13:14:07 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> <20090602112353.GB2916@topoi.pooq.com> <5DE9B69F-9493-4A6D-B7C8-1CEABC4BAE43@darko.org> <20090602155246.GC3481@topoi.pooq.com> Message-ID: <20090603171407.GA7016@topoi.pooq.com> On Wed, Jun 03, 2009 at 01:20:38AM +0200, Froggy wrote: > Yes, I understand what you're proposing and agree, but if you call > them unions then people think you're talking about C style unions or > variant records, etc which are the anathema in question. Historically, it was the other way around. C took Algol 68's unions, and removed the run-time type discriminator which could make them safe. -- hendrik From jay.krell at cornell.edu Thu Jun 4 21:42:28 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 4 Jun 2009 19:42:28 +0000 Subject: [M3devel] CM3_INSTALL_PREFIX Message-ID: Dragisha, ok, even before looking into this, I think I knew what the problem is. Need to "smush out the dots" more, so that mkdir /a/b/c/d/.. acts like mkdir /a/b/c. However I am unable to reproduce the problem on either PPC_DARWIN or AMD64_LINUX. Can you show me the offending .M3SHIP files? And maybe your config files? I don't have any .. "like that" in .M3SHIP. Does it happen with current cm3 or only older cm3? (I didn't realize CM3_INSTALL_PREFIX was a relatively new thing, from early 2008.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jun 4 21:38:38 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 4 Jun 2009 19:38:38 +0000 Subject: [M3devel] cvsup/zlib/solaris Message-ID: Tony your Tinderbox runs are less successful than others, building cvsup, due to lack of libz: === package m3-tools/cvsup/suplib === --- building in SOLgnu --- 22849 22850 ignoring ../src/m3overrides 22851 22852 NEXT "/scratch/hosking/work/cm3-ws/niagara-2009-06-03-10-30-05/cm3/m3-tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake runtime error: file libz.a not found in /usr/lib /usr/local/lib /lib /usr/contrib/lib /opt/lib 22853 Can you maybe install it on your systems? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jun 5 01:13:19 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 05 Jun 2009 01:13:19 +0200 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: References: Message-ID: <1244157199.14071.265.camel@faramir.m3w.org> There is no problem in CM3_INSTALL_PREFIX, but in situations where make_dir tries to make ".bin/.." when "..bin/" still does not exist. Problem is recent, it started to happen after you make INSTALL_ROOT relative to cm3 binary location. Solution: Exterminate .. from paths in cm3cfg.common. Apropos CM3_INSTALL_PREFIX - I am maybe it's only "client" for now - as it's used to populate tree during RPM builds. But it's straightforward solution to any binary packaking problem. On Thu, 2009-06-04 at 19:42 +0000, Jay wrote: > Dragisha, > > ok, even before looking into this, I think I knew what the problem is. > Need to "smush out the dots" more, so that mkdir /a/b/c/d/.. acts like > mkdir /a/b/c. > > However I am unable to reproduce the problem on either PPC_DARWIN or > AMD64_LINUX. > > Can you show me the offending .M3SHIP files? > And maybe your config files? > > I don't have any .. "like that" in .M3SHIP. > > Does it happen with current cm3 or only older cm3? > (I didn't realize CM3_INSTALL_PREFIX was a relatively new thing, from > early 2008.) > > - Jay > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jun 5 01:21:51 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 4 Jun 2009 23:21:51 +0000 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: <1244157199.14071.265.camel@faramir.m3w.org> References: <1244157199.14071.265.camel@faramir.m3w.org> Message-ID: I made this change years ago but only recently did Olaf switch over to my stuff. It is a good change generally, because you don't have to run cminstall and stick a full path in the config file. We can fix this aspect of it, but I'd like to be able to see it fail before I fix it, and then verify my fix makes it stop failing. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 5 Jun 2009 01:13:19 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3_INSTALL_PREFIX > > There is no problem in CM3_INSTALL_PREFIX, but in situations where > make_dir tries to make ".bin/.." when "..bin/" still does not exist. > > Problem is recent, it started to happen after you make INSTALL_ROOT > relative to cm3 binary location. > > Solution: Exterminate .. from paths in cm3cfg.common. > > Apropos CM3_INSTALL_PREFIX - I am maybe it's only "client" for now - as > it's used to populate tree during RPM builds. But it's straightforward > solution to any binary packaking problem. > > On Thu, 2009-06-04 at 19:42 +0000, Jay wrote: >> Dragisha, >> >> ok, even before looking into this, I think I knew what the problem is. >> Need to "smush out the dots" more, so that mkdir /a/b/c/d/.. acts like >> mkdir /a/b/c. >> >> However I am unable to reproduce the problem on either PPC_DARWIN or >> AMD64_LINUX. >> >> Can you show me the offending .M3SHIP files? >> And maybe your config files? >> >> I don't have any .. "like that" in .M3SHIP. >> >> Does it happen with current cm3 or only older cm3? >> (I didn't realize CM3_INSTALL_PREFIX was a relatively new thing, from >> early 2008.) >> >> - Jay >> > -- > Dragi?a Duri? > From hosking at cs.purdue.edu Fri Jun 5 01:54:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 5 Jun 2009 09:54:41 +1000 Subject: [M3devel] cvsup/zlib/solaris In-Reply-To: References: Message-ID: <1C2755B6-78CF-49B7-8057-E904B7A9D253@cs.purdue.edu> I'll see what I can do to locate that. On 5 Jun 2009, at 05:38, Jay wrote: > Tony your Tinderbox runs are less successful than others, building > cvsup, due to lack of libz: > > === package m3-tools/cvsup/suplib === > --- building in SOLgnu --- > 22849 > 22850 ignoring ../src/m3overrides > 22851 > 22852 NEXT "/scratch/hosking/work/cm3-ws/ > niagara-2009-06-03-10-30-05/cm3/m3-tools/cvsup/suplib/src/../../ > quake/cvsup.quake", line 127: quake runtime error: file libz.a not > found in /usr/lib /usr/local/lib /lib /usr/contrib/lib /opt/lib > 22853 > > > Can you maybe install it on your systems? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jun 5 10:51:05 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 05 Jun 2009 10:51:05 +0200 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: References: <1244157199.14071.265.camel@faramir.m3w.org> Message-ID: <1244191865.14071.717.camel@faramir.m3w.org> This is special case, as CM3_INSTALL_PREFIX redirects installation process to empty tree... cm3 -ship fails on make_dir("/usr/local/cm3/bin/../lib") as there is no $CM3_INSTALL_PREFIX/usr/local/cm3/bin at that moment. "cm3 -ship" which fails does mkdir $CM3_INSTALL_PREFIX/usr/local/cm3/bin, though. So second time I start cm3 -ship it works fine. Also, if I "mkdir -p $CM3_INSTALL_PREFIX/usr/local/cm3/bin" before cm3 -ship it does not fail first time. Thus said - I already have fix I need, it's workaround but works. If it is problem for you to write wuake script which derives paths from INSTALL_ROOT without ".." then just forget this and we can document this "feature" on our way. It will be documented in my RPM recipes once I complete and publish them. On Thu, 2009-06-04 at 23:21 +0000, Jay wrote: > > I made this change years ago but only recently did Olaf switch over to > my stuff. It is a good change generally, because you don't have to run > cminstall and stick a full path in the config file. We can fix this > aspect of it, but I'd like to be able to see it fail before I fix it, > and then verify my fix makes it stop failing. > > > - Jay -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jun 5 19:28:51 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 5 Jun 2009 17:28:51 +0000 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: <1244191865.14071.717.camel@faramir.m3w.org> References: <1244157199.14071.265.camel@faramir.m3w.org> <1244191865.14071.717.camel@faramir.m3w.org> Message-ID: The ".." gets smushed out early for me and I don't see a failure. Even for shipping m3core into a nonexistant place, with CM3_INSTALL_PREFIX set. Is the problem without CM3_INSTALL_PREFIX? Can you show your .M3SHIP files? And maybe your config files? This is easy to fix. There is code that smushes out dots. It is maybe a problem to write the quake because quake is very limited in what it can do. There might be functions now that can do it though. But really, again, the Modula-3 code often "canonicalizes" paths internally anyway, which is possibly why I don't see the problem occuring myself. - Jay > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 5 Jun 2009 10:51:05 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3_INSTALL_PREFIX > > This is special case, as CM3_INSTALL_PREFIX redirects installation > process to empty tree... cm3 -ship fails on > make_dir("/usr/local/cm3/bin/../lib") as there is no > $CM3_INSTALL_PREFIX/usr/local/cm3/bin at that moment. "cm3 -ship" which > fails does mkdir $CM3_INSTALL_PREFIX/usr/local/cm3/bin, though. So > second time I start cm3 -ship it works fine. > > Also, if I "mkdir -p $CM3_INSTALL_PREFIX/usr/local/cm3/bin" before cm3 > -ship it does not fail first time. > > Thus said - I already have fix I need, it's workaround but works. If it > is problem for you to write wuake script which derives paths from > INSTALL_ROOT without ".." then just forget this and we can document this > "feature" on our way. It will be documented in my RPM recipes once I > complete and publish them. > > On Thu, 2009-06-04 at 23:21 +0000, Jay wrote: > > > > I made this change years ago but only recently did Olaf switch over to > > my stuff. It is a good change generally, because you don't have to run > > cminstall and stick a full path in the config file. We can fix this > > aspect of it, but I'd like to be able to see it fail before I fix it, > > and then verify my fix makes it stop failing. > > > > > > - Jay > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jun 5 21:56:15 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 05 Jun 2009 21:56:15 +0200 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: References: <1244157199.14071.265.camel@faramir.m3w.org> <1244191865.14071.717.camel@faramir.m3w.org> Message-ID: <1244231775.14071.1359.camel@faramir.m3w.org> On Fri, 2009-06-05 at 17:28 +0000, Jay wrote: > The ".." gets smushed out early for me and I don't see a failure. > Even for shipping m3core into a nonexistant place, with > CM3_INSTALL_PREFIX set. > Is the problem without CM3_INSTALL_PREFIX? I don't see how to ship to non-existent place without CM3_INSTALL_PREFIX... End of day sinrome maybe...? > Can you show your .M3SHIP files? They are just like anybody's else. > And maybe your config files? Stock. No edit. > This is easy to fix. There is code that smushes out dots. Then please do. :) -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jun 5 22:31:12 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 5 Jun 2009 20:31:12 +0000 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: <1244231775.14071.1359.camel@faramir.m3w.org> References: <1244157199.14071.265.camel@faramir.m3w.org> <1244191865.14071.717.camel@faramir.m3w.org> <1244231775.14071.1359.camel@faramir.m3w.org> Message-ID: Dragisha we are not communicating. I have set CM3_INSTALL_PREFIX to a nonexistant place. I have shiped m3core. It works. No error. If I see the error I believe I know how to fix it, but I don't want to make a change without being able to see the before and after and that the after is an improvement. Maybe I am doing something wrong though. Please send me the offending .M3SHIP file. - Jay ---------------------------------------- > Subject: RE: [M3devel] CM3_INSTALL_PREFIX > From: dragisha at m3w.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Date: Fri, 5 Jun 2009 21:56:15 +0200 > > On Fri, 2009-06-05 at 17:28 +0000, Jay wrote: >> The ".." gets smushed out early for me and I don't see a failure. >> Even for shipping m3core into a nonexistant place, with >> CM3_INSTALL_PREFIX set. >> Is the problem without CM3_INSTALL_PREFIX? > > I don't see how to ship to non-existent place without > CM3_INSTALL_PREFIX... End of day sinrome maybe...? > >> Can you show your .M3SHIP files? > > They are just like anybody's else. > >> And maybe your config files? > > Stock. No edit. > >> This is easy to fix. There is code that smushes out dots. > > Then please do. :) > > -- > Dragi?a Duri? > From eiserlohpp at yahoo.com Mon Jun 8 03:30:46 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 7 Jun 2009 18:30:46 -0700 (PDT) Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX Message-ID: <973785.75349.qm@web56804.mail.re3.yahoo.com> Hi Guys, I have been attempting to build m3gdb. A simple "do-pkg.sh m3gdb" fails with a message that the package is disabled on this platform. So, I manually went to m3-sys/m3gdb, and did a "cm3 -build", an success. Is there a reason that m3gdb is disabled on AMD64_LINUX? Or, more probably, did someone simply forget to enable it? I traced the decision down to pkginfo.sh, where yes, there is an environment variable M3GDB that could have been set to allow m3gdb to be built, but that is taking extra measures to build it. Is it a simple oversight in not, by default, building m3gdb? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From rodney.m.bates at cox.net Mon Jun 8 16:59:34 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 08 Jun 2009 09:59:34 -0500 Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX In-Reply-To: <973785.75349.qm@web56804.mail.re3.yahoo.com> References: <973785.75349.qm@web56804.mail.re3.yahoo.com> Message-ID: <4A2D2756.8010904@cox.net> I seem to have fallen into the role of default primary maintainer for m3gdb. I have never built it on anything other than LINUXLIBC6. I now have an AMD_LINUX machine, but haven't gotten a working cm3 to build with yet. I'm just guessing, but I think some platforms have had build problems in the past. Maybe it is disable except where it has been previously done successfully. I read your post to say only that it built successfully for you. Any experience trying it out? Peter Eiserloh wrote: > Hi Guys, > > I have been attempting to build m3gdb. A simple > "do-pkg.sh m3gdb" fails with a message that the package > is disabled on this platform. > > So, I manually went to m3-sys/m3gdb, and did a "cm3 -build", > an success. > > Is there a reason that m3gdb is disabled on AMD64_LINUX? > Or, more probably, did someone simply forget to enable it? > > I traced the decision down to pkginfo.sh, where yes, there > is an environment variable M3GDB that could have been > set to allow m3gdb to be built, but that is taking extra > measures to build it. > > Is it a simple oversight in not, by default, building m3gdb? > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > > From wagner at elegosoft.com Mon Jun 8 21:37:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Jun 2009 21:37:12 +0200 Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX In-Reply-To: <4A2D2756.8010904@cox.net> References: <973785.75349.qm@web56804.mail.re3.yahoo.com> <4A2D2756.8010904@cox.net> Message-ID: <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> The strategy when to build m3gdb should probably be revisited. I'm not sure if we should keep the positive list or just exclude some platforms; but then, I do not have the complete overview of all the platforms that Jay has been and is working on. Jay, can you take a look at that in pkginfo.sh? Thanks, Olaf Quoting "Rodney M. Bates" : > I seem to have fallen into the role of default primary maintainer for > m3gdb. I have never built it on anything other than LINUXLIBC6. > I now have an AMD_LINUX machine, but haven't gotten a working > cm3 to build with yet. I'm just guessing, but I think some platforms > have had build problems > in the past. Maybe it is disable except where it has been previously > done successfully. I read your post to say only that it built > successfully for you. Any > experience trying it out? Peter Eiserloh wrote: >> Hi Guys, >> >> I have been attempting to build m3gdb. A simple "do-pkg.sh m3gdb" >> fails with a message that the package >> is disabled on this platform. >> >> So, I manually went to m3-sys/m3gdb, and did a "cm3 -build", >> an success. >> >> Is there a reason that m3gdb is disabled on AMD64_LINUX? >> Or, more probably, did someone simply forget to enable it? >> >> I traced the decision down to pkginfo.sh, where yes, there >> is an environment variable M3GDB that could have been >> set to allow m3gdb to be built, but that is taking extra >> measures to build it. >> >> Is it a simple oversight in not, by default, building m3gdb? >> >> >> +--------------------------------------------------------+ >> | 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 hendrik at topoi.pooq.com Mon Jun 8 22:57:47 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 8 Jun 2009 16:57:47 -0400 Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX In-Reply-To: <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> References: <973785.75349.qm@web56804.mail.re3.yahoo.com> <4A2D2756.8010904@cox.net> <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> Message-ID: <20090608205747.GA20457@topoi.pooq.com> On Mon, Jun 08, 2009 at 09:37:12PM +0200, Olaf Wagner wrote: > The strategy when to build m3gdb should probably be revisited. > I'm not sure if we should keep the positive list or just exclude > some platforms; but then, I do not have the complete overview of > all the platforms that Jay has been and is working on. Whatever you do about including or excluding, it would be worth inserting a comment explaining why. -- hendrik From jay.krell at cornell.edu Tue Jun 9 03:00:29 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 8 Jun 2009 18:00:29 -0700 Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX In-Reply-To: <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> References: <973785.75349.qm@web56804.mail.re3.yahoo.com> <4A2D2756.8010904@cox.net> <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> Message-ID: <4B18C378-AE99-4897-B1B0-2ABB39DC7E0A@hotmail.com> I agree let it build by default. It can probably build on most platforms. The exceptions are nt386 and i think nt386mingnu. Nt386gnu can build it but cygwin is so generally slow and I never use m3gdb..on any platform.. - Jay (phone) On Jun 8, 2009, at 12:37 PM, Olaf Wagner wrote: > The strategy when to build m3gdb should probably be revisited. > I'm not sure if we should keep the positive list or just exclude > some platforms; but then, I do not have the complete overview of > all the platforms that Jay has been and is working on. > > Jay, can you take a look at that in pkginfo.sh? > > Thanks, > > Olaf > > Quoting "Rodney M. Bates" : > >> I seem to have fallen into the role of default primary maintainer for >> m3gdb. I have never built it on anything other than LINUXLIBC6. >> I now have an AMD_LINUX machine, but haven't gotten a working >> cm3 to build with yet. I'm just guessing, but I think some platforms >> have had build problems >> in the past. Maybe it is disable except where it has been previously >> done successfully. I read your post to say only that it built >> successfully for you. Any >> experience trying it out? Peter Eiserloh wrote: >>> Hi Guys, >>> >>> I have been attempting to build m3gdb. A simple "do-pkg.sh m3gdb" >>> fails with a message that the package >>> is disabled on this platform. >>> >>> So, I manually went to m3-sys/m3gdb, and did a "cm3 -build", >>> an success. >>> >>> Is there a reason that m3gdb is disabled on AMD64_LINUX? >>> Or, more probably, did someone simply forget to enable it? >>> >>> I traced the decision down to pkginfo.sh, where yes, there >>> is an environment variable M3GDB that could have been >>> set to allow m3gdb to be built, but that is taking extra >>> measures to build it. >>> >>> Is it a simple oversight in not, by default, building m3gdb? >>> >>> >>> +--------------------------------------------------------+ >>> | Peter P. Eiserloh | >>> +--------------------------------------------------------+ >>> >>> >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > 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: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From hendrik at topoi.pooq.com Tue Jun 9 23:25:43 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 9 Jun 2009 17:25:43 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090514155129.GA15181@topoi.pooq.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> <20090514155129.GA15181@topoi.pooq.com> Message-ID: <20090609212543.GA23398@topoi.pooq.com> On Thu, May 14, 2009 at 11:51:30AM -0400, hendrik at topoi.pooq.com wrote: > 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. Is it time for me to make another try at installing cm3 from scratch? In particular, do you think most of the problems I reported with documentation and archives, etc., have been solved? I really want to get m3 working on this laptop, but I also want to provide the most useful problem reports. I'm definitely trying to act like a naive user in these installation attempts (which means I'm trying to act stupider than I am). -- hendrik From estellnb at yahoo.de Wed Jun 10 16:26:09 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Wed, 10 Jun 2009 15:26:09 +0100 Subject: [M3devel] recent m3gdb does not want to compile Message-ID: <4A2FC281.1030101@yahoo.de> For any kind of reason recent m3gdbs refuse to compile at me: ../gdb/configure ... checking for x86_64-unknown-linux-gnu-ar... no checking for ar... ar ... > which ar /usr/bin/ar setting --bindir to /usr/bin or /usr does not help. full error log: see attachement Should I compile m3gdb towards 32bit on an x86_64 platform if the m3build I am using is 32bit? Besides this I am in wonder why a plain gdb can not access global Modula-3 variables using PM3/EZM3 although I have specified -gstabs in m3config/src/COMMON: ASM = ["as","--32","-gstabs","-o"] % Assembler DEBUG_FLAG = "-gstabs" % debugging info BDEBUG_FLAG = "-gstabs" % debugging info LDEBUG_FLAG = "-gstabs" i.e. > gdb -batch --directory= --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > grep myglobal smbls -> nothing found -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: m3gdb-errs.msg URL: From jay.krell at cornell.edu Wed Jun 10 23:05:55 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 10 Jun 2009 21:05:55 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A2FC281.1030101@yahoo.de> References: <4A2FC281.1030101@yahoo.de> Message-ID: The global variable behavior I think I understand, and I believe the original authors did it this way on purpose, but I agree it seems quite bad. The way the code is generated, all the internal globals for a module are in one large struct, per module. There aren't symbols for each one. The code translates like this: Modula-3: Foo.i3: INTERFACE Foo; PROCEDURE GetI() : INTEGER; PROCEDURE GetJ() : INTEGER; END Foo. Foo.m3: MODULE Foo; VAR i, j: INTEGER; PROCEDURE GetI() = BEGIN RETURN i; END GetI; PROCEDURE GetJ() = BEGIN RETURN j; END GetJ; C: foo.h: ptrdiff_t Foo__GetI(void); ptrdiff_t Foo__GetJ(void); foo.c: struct { int i, j; } Foo_M3; ptrdiff_t Foo__GetI(void) { return Foo_M3.i; } ptrdiff_t Foo__GetJ(void) { return Foo_M3.j; } I personally would much prefer one of: static int i, j; ptrdiff_t Foo__GetI(void) { return i; } ptrdiff_t Foo__GetJ(void) { return j; } or: int Foo_i, Foo_j; ptrdiff_t Foo__GetI(void) { return Foo_i; } ptrdiff_t Foo__GetJ(void) { return Foo_j; } or two underscores. Can anyone explain why it is done this way? And why it shouldn't be changed to how I showed? Here are some advantages/disadvanges: symbols, debuggability, as discussed The current way pretty much guaranteeds none of the data gets dead-stripped, for better and worse. But really, even if you changed it to "my way", there's probably another bit needed on the data to dead-strip it, so that behavior can be preserved, for better and worse. "My way" probably also allows for not using bitfields in load/store, in fact, the offseting would often go away too. > Should I compile m3gdb towards 32bit on an x86_64 platform if the > m3build I am using is 32bit? It should build either way, but for it to be useful, yes, I expect so. I believe current versions of gdb can have multiple targets though. - Jay > Date: Wed, 10 Jun 2009 15:26:09 +0100 > From: estellnb at yahoo.de > To: m3devel at elegosoft.com > Subject: [M3devel] recent m3gdb does not want to compile > > For any kind of reason recent m3gdbs refuse to compile at me: > > ../gdb/configure > ... > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > ... > > > which ar > /usr/bin/ar > > setting --bindir to /usr/bin or /usr does not help. > full error log: see attachement > > Should I compile m3gdb towards 32bit on an x86_64 platform if the > m3build I am using is 32bit? > > Besides this I am in wonder why a plain gdb can not access global > Modula-3 variables using PM3/EZM3 although I have specified -gstabs in > m3config/src/COMMON: > ASM = ["as","--32","-gstabs","-o"] % Assembler > DEBUG_FLAG = "-gstabs" % debugging info > BDEBUG_FLAG = "-gstabs" % debugging info > LDEBUG_FLAG = "-gstabs" > > i.e. > > gdb -batch --directory= > --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info > variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > > > grep myglobal smbls -> nothing found > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jun 10 23:42:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 10 Jun 2009 23:42:00 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090609212543.GA23398@topoi.pooq.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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> Message-ID: <20090610234200.xec9zguoqowogc84@mail.elego.de> Quoting hendrik at topoi.pooq.com: > On Thu, May 14, 2009 at 11:51:30AM -0400, hendrik at topoi.pooq.com wrote: > Is it time for me to make another try at installing cm3 from scratch? > In particular, do you think most of the problems I reported with > documentation and archives, etc., have been solved? I really want to > get m3 working on this laptop, but I also want to provide the most > useful problem reports. > > I'm definitely trying to act like a naive user in these installation > attempts (which means I'm trying to act stupider than I am). I'm sorry; though I've put some archives onto birch labelled as RC1, there's still no documentation. I'm currently in Madrid for a week, but I hope to spend a day for working on that when I return mid of next week. I'll let you know when to try it. Hasta luego, 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 Thu Jun 11 01:04:28 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 10 Jun 2009 23:04:28 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A2FC281.1030101@yahoo.de> References: <4A2FC281.1030101@yahoo.de> Message-ID: Slightly truncated, again >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? > > > > > > It should build either way, but for it to be useful, yes, I expect so. > > I believe current versions of gdb can have multiple targets though. > > > > > > - Jay From rodney.m.bates at cox.net Thu Jun 11 04:20:49 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 10 Jun 2009 21:20:49 -0500 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A2FC281.1030101@yahoo.de> References: <4A2FC281.1030101@yahoo.de> Message-ID: <4A306A01.5080603@cox.net> Peter Eiserloh has recently gotten it to build on AMD64_LINUX, using the do-cm3-m3gdb.sh script. You should try that method. Unfortunately, it is not recognizing executables and dynamic libraries. I have looked at this a bit, and the problem looks to be in the bfd library, which is stock from gdb. m3gdb is derived from gdb 6.4, which is by now quite old. gdb maintainers are about to make a new release, I think 6.9. I am in the throes of moving house now, but am getting odd bits of time to look at this. I have been thinking for some time that it is about time to update m3gdb to a later gdb. For one thing, gdb now has some reverse debugging support, which would be very nice for Modula-3 too. I have done it two or three times, and I believe Tony has done it at least once. It takes a fair amount of work. But it should be possible to get the current m3gdb working on AMD64 without going to that much trouble. Maybe just some updated source files from bfd will do the trick. Jay is right about global variables. You will have a very hard time finding them using stock gdb. They are located in a record with a funny compiler-generated name and have funny compiler-mangled field names. I'm not sure you can get them even if you know these. Elmar Stellnberger wrote: > For any kind of reason recent m3gdbs refuse to compile at me: > > ../gdb/configure > ... > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > ... > > >> which ar >> > /usr/bin/ar > > setting --bindir to /usr/bin or /usr does not help. > full error log: see attachement > > Should I compile m3gdb towards 32bit on an x86_64 platform if the > m3build I am using is 32bit? > > Besides this I am in wonder why a plain gdb can not access global > Modula-3 variables using PM3/EZM3 although I have specified -gstabs in > m3config/src/COMMON: > ASM = ["as","--32","-gstabs","-o"] % Assembler > DEBUG_FLAG = "-gstabs" % debugging info > BDEBUG_FLAG = "-gstabs" % debugging info > LDEBUG_FLAG = "-gstabs" > > i.e. > >> gdb -batch --directory= >> > --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info > variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > > >> grep myglobal smbls -> nothing found >> > > From jay.krell at cornell.edu Thu Jun 11 05:13:55 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 10 Jun 2009 20:13:55 -0700 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A306A01.5080603@cox.net> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> Message-ID: Do they have any field names at all? Can m3gdb see them? I suspect no to both. The struct is not TOO odd. - Jay (phone) On Jun 10, 2009, at 7:20 PM, "Rodney M. Bates" wrote: > Peter Eiserloh has recently gotten it to build on AMD64_LINUX, > using the do-cm3-m3gdb.sh script. You should try that method. > > Unfortunately, it is not recognizing executables and dynamic > libraries. I have looked at this a bit, and the problem looks to > be in the bfd library, which is stock from gdb. m3gdb is derived > from gdb 6.4, which is by now quite old. gdb maintainers are about > to make a new release, I think 6.9. I am in the throes of moving > house now, but am getting odd bits of time to look at this. > I have been thinking for some time that it is about time to update > m3gdb to a later gdb. For one thing, gdb now has some reverse > debugging support, which would be very nice for Modula-3 too. > I have done it two or three times, and I believe Tony has done it > at least once. It takes a fair amount of work. But it should be > possible to get the current m3gdb working on AMD64 without going > to that much trouble. Maybe just some updated source files from > bfd will do the trick. > Jay is right about global variables. You will have a very hard time > finding them using stock gdb. They are located in a record with a > funny compiler-generated name and have funny compiler-mangled > field names. I'm not sure you can get them even if you know these. > > > > > Elmar Stellnberger wrote: >> For any kind of reason recent m3gdbs refuse to compile at me: >> >> ../gdb/configure >> ... >> checking for x86_64-unknown-linux-gnu-ar... no >> checking for ar... ar >> ... >> >> >>> which ar >>> >> /usr/bin/ar >> >> setting --bindir to /usr/bin or /usr does not help. >> full error log: see attachement >> >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? >> >> Besides this I am in wonder why a plain gdb can not access global >> Modula-3 variables using PM3/EZM3 although I have specified -gstabs >> in >> m3config/src/COMMON: >> ASM = ["as","--32","-gstabs","-o"] % Assembler >> DEBUG_FLAG = "-gstabs" % debugging info >> BDEBUG_FLAG = "-gstabs" % debugging info >> LDEBUG_FLAG = "-gstabs" >> >> i.e. >> >>> gdb -batch --directory= >>> >> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info >> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls >> >> >>> grep myglobal smbls -> nothing found >>> >> >> > > From jay.krell at cornell.edu Thu Jun 11 10:50:08 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 11 Jun 2009 08:50:08 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> Message-ID: scripts/do-cm3-m3gdb.sh just cd's over to m3-sys/m3gdb and runs cm3. m3gdb builds and seems to work fine for me. Specifically, on AMD64_LINUX birch, I can both: mkdir -p $HOME/obj/gdb cd $HOME/obj/gdb $HOME/dev2/cm3/m3-sys/m3gdb/gdb/configure && make gdb/gdb gdb/gdb break main r and cd $HOME/dev2/cm3/m3-sys/m3gdb rm -rf AMD64_LINUX cm3 AMD64_LINUX/m3gdb AMD64_LINUX/m3gdb break main r I haven't tried with Modula-3 code and/or stabs. Updating from the 2005 6.4 release to a current 6.8 release is probably advisable anyway. But again, um, er, could we maybe adapt the generated code so that plain gdb is all anyone would need/want? Cygwin fork being so slow makes me want to optimize out such large pieces as building gdb. Maybe I can figure out a way to speed up Cygwin fork some day... - Jay > From: jay.krell at cornell.edu > To: rodney.m.bates at cox.net > Date: Wed, 10 Jun 2009 20:13:55 -0700 > CC: m3devel at elegosoft.com; estellnb at yahoo.de > Subject: Re: [M3devel] recent m3gdb does not want to compile > > Do they have any field names at all? Can m3gdb see them? I suspect no > to both. The struct is not TOO odd. > > - Jay (phone) > > On Jun 10, 2009, at 7:20 PM, "Rodney M. Bates" > wrote: > > > Peter Eiserloh has recently gotten it to build on AMD64_LINUX, > > using the do-cm3-m3gdb.sh script. You should try that method. > > > > Unfortunately, it is not recognizing executables and dynamic > > libraries. I have looked at this a bit, and the problem looks to > > be in the bfd library, which is stock from gdb. m3gdb is derived > > from gdb 6.4, which is by now quite old. gdb maintainers are about > > to make a new release, I think 6.9. I am in the throes of moving > > house now, but am getting odd bits of time to look at this. > > I have been thinking for some time that it is about time to update > > m3gdb to a later gdb. For one thing, gdb now has some reverse > > debugging support, which would be very nice for Modula-3 too. > > I have done it two or three times, and I believe Tony has done it > > at least once. It takes a fair amount of work. But it should be > > possible to get the current m3gdb working on AMD64 without going > > to that much trouble. Maybe just some updated source files from > > bfd will do the trick. > > Jay is right about global variables. You will have a very hard time > > finding them using stock gdb. They are located in a record with a > > funny compiler-generated name and have funny compiler-mangled > > field names. I'm not sure you can get them even if you know these. > > > > > > > > > > Elmar Stellnberger wrote: > >> For any kind of reason recent m3gdbs refuse to compile at me: > >> > >> ../gdb/configure > >> ... > >> checking for x86_64-unknown-linux-gnu-ar... no > >> checking for ar... ar > >> ... > >> > >> > >>> which ar > >>> > >> /usr/bin/ar > >> > >> setting --bindir to /usr/bin or /usr does not help. > >> full error log: see attachement > >> > >> Should I compile m3gdb towards 32bit on an x86_64 platform if the > >> m3build I am using is 32bit? > >> > >> Besides this I am in wonder why a plain gdb can not access global > >> Modula-3 variables using PM3/EZM3 although I have specified -gstabs > >> in > >> m3config/src/COMMON: > >> ASM = ["as","--32","-gstabs","-o"] % Assembler > >> DEBUG_FLAG = "-gstabs" % debugging info > >> BDEBUG_FLAG = "-gstabs" % debugging info > >> LDEBUG_FLAG = "-gstabs" > >> > >> i.e. > >> > >>> gdb -batch --directory= > >>> > >> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info > >> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > >> > >> > >>> grep myglobal smbls -> nothing found > >>> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at yahoo.de Thu Jun 11 14:00:12 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Thu, 11 Jun 2009 13:00:12 +0100 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A306A01.5080603@cox.net> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> Message-ID: <4A30F1CC.8040201@yahoo.de> Unfortunately I am not familiar with the complex build system of CM3 so that my chances to make do-cm3-m3gdb.sh work are very little: > scripts/do-cm3-m3gdb.sh making /src/lunger-cm3/scripts/PKGS (slow but rare) /src/lunger-cm3/scripts/pkgmap.sh -c "m3build -O -DROOT='/src/lunger-cm3' -DCM3_VERSION_TEXT='d5.8.1' -DCM3_VER SION_NUMBER='050801' -DCM3_LAST_CHANGED='2009-05-16' " m3gdb === package m3-sys/m3gdb === === package omitted on this platform === ==> m3-sys/m3gdb done > ls m3-sys/m3gdb/AMD64_LINUX > > m3build -O -DROOT='/src/lunger-cm3' -DCM3_VERSION_TEXT='d5.8.1' -DCM3_VERSION_NUMBER='050801' -DCM3_LAST_CHANGED='2009-05-16' --- building in LINUXLIBC6 --- m3build: missing ../src/m3overrides m3build: quake error: quake error: runtime error: exec failed: err#2 No such file or directory() *** CC="gcc" CFLAGS="-g" MAKEINFO=echo --procedure-- -line- -file--- exec -- m3gdb_Run 121 /home/sources/lunger-cm3/m3-sys/m3gdb/src/m3makefile 153 /home/sources/lunger-cm3/m3-sys/m3gdb/src/m3makefile Where should the overrides file come from? > ../gdb/configure CC="gcc" CFLAGS="-g" MAKEINFO="echo" configure: warning: CC=gcc: invalid host type configure: warning: CFLAGS=-g: invalid host type configure: error: can only configure for one host and one target at a time How can I invoke ../gdb/configure and make manually without having to use these scripts? Rodney M. Bates schrieb: > Peter Eiserloh has recently gotten it to build on AMD64_LINUX, > using the do-cm3-m3gdb.sh script. You should try that method. > > Unfortunately, it is not recognizing executables and dynamic > libraries. I have looked at this a bit, and the problem looks to > be in the bfd library, which is stock from gdb. m3gdb is derived > from gdb 6.4, which is by now quite old. gdb maintainers are about > to make a new release, I think 6.9. I am in the throes of moving > house now, but am getting odd bits of time to look at this. > I have been thinking for some time that it is about time to update > m3gdb to a later gdb. For one thing, gdb now has some reverse > debugging support, which would be very nice for Modula-3 too. > I have done it two or three times, and I believe Tony has done it > at least once. It takes a fair amount of work. But it should be > possible to get the current m3gdb working on AMD64 without going > to that much trouble. Maybe just some updated source files from > bfd will do the trick. > Jay is right about global variables. You will have a very hard time > finding them using stock gdb. They are located in a record with a > funny compiler-generated name and have funny compiler-mangled > field names. I'm not sure you can get them even if you know these. > > > > > Elmar Stellnberger wrote: >> For any kind of reason recent m3gdbs refuse to compile at me: >> >> ../gdb/configure >> ... >> checking for x86_64-unknown-linux-gnu-ar... no >> checking for ar... ar >> ... >> >> >>> which ar >>> >> /usr/bin/ar >> >> setting --bindir to /usr/bin or /usr does not help. >> full error log: see attachement >> >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? >> >> Besides this I am in wonder why a plain gdb can not access global >> Modula-3 variables using PM3/EZM3 although I have specified -gstabs in >> m3config/src/COMMON: >> ASM = ["as","--32","-gstabs","-o"] % Assembler >> DEBUG_FLAG = "-gstabs" % debugging info >> BDEBUG_FLAG = "-gstabs" % debugging info >> LDEBUG_FLAG = "-gstabs" >> >> i.e. >> >>> gdb -batch --directory= >>> >> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info >> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls >> >> >>> grep myglobal smbls -> nothing found >>> >> >> > > From jay.krell at cornell.edu Thu Jun 11 13:00:54 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 11 Jun 2009 04:00:54 -0700 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A2FC281.1030101@yahoo.de> References: <4A2FC281.1030101@yahoo.de> Message-ID: You are just missing texinfo or such, so building documentation fails. I can look in to hacking the m3gdb build like m3cc is, to reduce its dependencies. - Jay (phone) On Jun 10, 2009, at 7:26 AM, Elmar Stellnberger wrote: > For any kind of reason recent m3gdbs refuse to compile at me: > > ../gdb/configure > ... > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > ... > >> which ar > /usr/bin/ar > > setting --bindir to /usr/bin or /usr does not help. > full error log: see attachement > > Should I compile m3gdb towards 32bit on an x86_64 platform if the > m3build I am using is 32bit? > > Besides this I am in wonder why a plain gdb can not access global > Modula-3 variables using PM3/EZM3 although I have specified -gstabs in > m3config/src/COMMON: > ASM = ["as","--32","-gstabs","-o"] % Assembler > DEBUG_FLAG = "-gstabs" % debugging info > BDEBUG_FLAG = "-gstabs" % debugging info > LDEBUG_FLAG = "-gstabs" > > i.e. >> gdb -batch --directory= > --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info > variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > >> grep myglobal smbls -> nothing found > >> ../gdb/configure > creating cache ./config.cache > checking host system type... x86_64-unknown-linux-gnu > checking target system type... x86_64-unknown-linux-gnu > checking build system type... x86_64-unknown-linux-gnu > checking for a BSD compatible install... /usr/bin/install -c > checking whether ln works... yes > checking whether ln -s works... yes > checking for gcc... gcc > checking whether the C compiler (gcc ) works... yes > checking whether the C compiler (gcc ) is a cross-compiler... no > checking whether we are using GNU C... yes > checking whether gcc accepts -g... yes > checking for gnatbind... no > checking whether compiler driver understands Ada... no > checking how to compare bootstrapped objects... cmp --ignore- > initial=16 $$f1 $$f2 > checking for correct version of gmp.h... yes > checking for MPFR... no > checking for bison... bison > checking for bison... bison -y > checking for gm4... no > checking for gnum4... no > checking for m4... m4 > checking for flex... flex > checking for flex... flex > checking for makeinfo... makeinfo > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > checking for x86_64-unknown-linux-gnu-as... no > checking for as... as > checking for x86_64-unknown-linux-gnu-dlltool... no > checking for dlltool... no > checking for x86_64-unknown-linux-gnu-ld... /usr/lib64/gcc/x86_64- > suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld > checking for x86_64-unknown-linux-gnu-nm... no > checking for nm... nm > checking for x86_64-unknown-linux-gnu-ranlib... no > checking for ranlib... ranlib > checking for x86_64-unknown-linux-gnu-windres... no > checking for windres... no > checking for x86_64-unknown-linux-gnu-objcopy... no > checking for objcopy... objcopy > checking for x86_64-unknown-linux-gnu-objdump... no > checking for objdump... objdump > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > checking for x86_64-unknown-linux-gnu-as... no > checking for as... as > checking for x86_64-unknown-linux-gnu-cc... no > checking for cc... cc > checking for x86_64-unknown-linux-gnu-c++... no > checking for c++... c++ > checking for x86_64-unknown-linux-gnu-dlltool... no > checking for dlltool... no > checking for x86_64-unknown-linux-gnu-gcc... no > checking for gcc... gcc > checking for x86_64-unknown-linux-gnu-gcj... no > checking for gcj... no > checking for x86_64-unknown-linux-gnu-gfortran... no > checking for gfortran... no > checking for x86_64-unknown-linux-gnu-ld... no > checking for ld... ld > checking for x86_64-unknown-linux-gnu-lipo... no > checking for lipo... no > checking for x86_64-unknown-linux-gnu-nm... no > checking for nm... nm > checking for x86_64-unknown-linux-gnu-objdump... no > checking for objdump... objdump > checking for x86_64-unknown-linux-gnu-ranlib... no > checking for ranlib... ranlib > checking for x86_64-unknown-linux-gnu-strip... no > checking for strip... strip > checking for x86_64-unknown-linux-gnu-windres... no > checking for windres... no > checking whether to enable maintainer-specific portions of > Makefiles... no > checking if symbolic links between directories work... yes > updating cache ./config.cache > creating ./config.status > creating Makefile > elm:/home/sources/mm3/language/modula3/m3tools/m3gdb-cm3-2009-06-09/ > SUSE11.1> make > make[1]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1' > mkdir -p -- ./libiberty > Configuring in ./libiberty > configure: creating cache ./config.cache > checking whether to enable maintainer-specific portions of > Makefiles... no > checking for makeinfo... /home/sources/mm3/language/modula3/m3tools/ > m3gdb-cm3-2009-06-09/gdb/missing makeinfo --split-size=5000000 > configure: WARNING: > *** Makeinfo is missing. Info documentation will not be built. > checking for perl... perl > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking for x86_64-unknown-linux-gnu-ar... ar > checking for x86_64-unknown-linux-gnu-ranlib... ranlib > checking for x86_64-unknown-linux-gnu-gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking how to run the C preprocessor... gcc -E > checking whether gcc and cc understand -c and -o together... yes > checking for an ANSI C-conforming const... yes > checking for inline... inline > checking whether byte ordering is bigendian... no > checking for a BSD-compatible install... /usr/bin/install -c > checking for sys/file.h... yes > checking for sys/param.h... yes > checking for limits.h... yes > checking for stdlib.h... yes > checking for malloc.h... yes > checking for string.h... yes > checking for unistd.h... yes > checking for strings.h... yes > checking for sys/time.h... yes > checking for time.h... yes > checking for sys/resource.h... yes > checking for sys/stat.h... yes > checking for sys/mman.h... yes > checking for fcntl.h... yes > checking for alloca.h... yes > checking for sys/pstat.h... no > checking for sys/sysmp.h... no > checking for sys/sysinfo.h... yes > checking for machine/hal_sysinfo.h... no > checking for sys/table.h... no > checking for sys/sysctl.h... yes > checking for sys/systemcfg.h... no > checking for stdint.h... yes > checking for stdio_ext.h... yes > checking for sys/wait.h that is POSIX.1 compatible... yes > checking whether time.h and sys/time.h may both be included... yes > checking whether errno must be declared... no > checking for egrep... grep -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... (cached) yes > checking for stdlib.h... (cached) yes > checking for string.h... (cached) yes > checking for memory.h... yes > checking for strings.h... (cached) yes > checking for inttypes.h... yes > checking for stdint.h... (cached) yes > checking for unistd.h... (cached) yes > checking for int... yes > checking size of int... 4 > checking for uintptr_t... yes > checking for a 64-bit type... uint64_t > checking for pid_t... yes > checking for library containing strerror... none required > checking for asprintf... yes > checking for atexit... yes > checking for basename... yes > checking for bcmp... yes > checking for bcopy... yes > checking for bsearch... yes > checking for bzero... yes > checking for calloc... yes > checking for clock... yes > checking for ffs... yes > checking for getcwd... yes > checking for getpagesize... yes > checking for gettimeofday... yes > checking for index... yes > checking for insque... yes > checking for memchr... yes > checking for memcmp... yes > checking for memcpy... yes > checking for memmove... yes > checking for mempcpy... yes > checking for memset... yes > checking for mkstemps... no > checking for putenv... yes > checking for random... yes > checking for rename... yes > checking for rindex... yes > checking for setenv... yes > checking for snprintf... yes > checking for sigsetmask... yes > checking for stpcpy... yes > checking for stpncpy... yes > checking for strcasecmp... yes > checking for strchr... yes > checking for strdup... yes > checking for strncasecmp... yes > checking for strndup... yes > checking for strrchr... yes > checking for strstr... yes > checking for strtod... yes > checking for strtol... yes > checking for strtoul... yes > checking for strverscmp... yes > checking for tmpnam... yes > checking for vasprintf... yes > checking for vfprintf... yes > checking for vprintf... yes > checking for vsnprintf... yes > checking for vsprintf... yes > checking for waitpid... yes > checking whether alloca needs Cray hooks... no > checking stack direction for C alloca... -1 > checking for unistd.h... (cached) yes > checking for vfork.h... no > checking for fork... yes > checking for vfork... yes > checking for working fork... yes > checking for working vfork... (cached) yes > checking for _doprnt... no > checking for sys_errlist... yes > checking for sys_nerr... yes > checking for sys_siglist... yes > checking for external symbol _system_configuration... no > checking for getrusage... yes > checking for on_exit... yes > checking for psignal... yes > checking for strerror... yes > checking for strsignal... yes > checking for sysconf... yes > checking for times... yes > checking for sbrk... yes > checking for gettimeofday... (cached) yes > checking for realpath... yes > checking for canonicalize_file_name... yes > checking for pstat_getstatic... no > checking for pstat_getdynamic... no > checking for sysmp... no > checking for getsysinfo... no > checking for table... no > checking for sysctl... yes > checking for wait3... yes > checking for wait4... yes > checking for __fsetlocking... yes > checking whether basename is declared... no > checking whether ffs is declared... yes > checking whether asprintf is declared... no > checking whether vasprintf is declared... no > checking whether snprintf is declared... yes > checking whether vsnprintf is declared... yes > checking whether calloc is declared... yes > checking whether getenv is declared... yes > checking whether getopt is declared... yes > checking whether malloc is declared... yes > checking whether realloc is declared... yes > checking whether sbrk is declared... yes > checking whether strverscmp is declared... no > checking whether canonicalize_file_name must be declared... yes > checking for stdlib.h... (cached) yes > checking for unistd.h... (cached) yes > checking for getpagesize... (cached) yes > checking for working mmap... yes > checking for working strncmp... yes > updating cache ./config.cache > configure: creating ./config.status > config.status: creating Makefile > config.status: creating testsuite/Makefile > config.status: creating config.h > config.status: executing default commands > mkdir -p -- ./bfd > Configuring in ./bfd > configure: creating cache ./config.cache > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking target system type... x86_64-unknown-linux-gnu > checking for x86_64-unknown-linux-gnu-gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for library containing strerror... none required > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking for x86_64-unknown-linux-gnu-ar... ar > checking for x86_64-unknown-linux-gnu-ranlib... ranlib > checking for ld used by GCC... /usr/lib64/gcc/x86_64-suse-linux/ > 4.3/../../../../x86_64-suse-linux/bin/ld > checking if the linker (/usr/lib64/gcc/x86_64-suse-linux/ > 4.3/../../../../x86_64-suse-linux/bin/ld) is GNU ld... yes > checking for /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64- > suse-linux/bin/ld option to reload object files... -r > checking for BSD-compatible nm... nm > checking whether ln -s works... yes > checking how to recognise dependant libraries... file_magic ELF [0-9] > [0-9]*-bit [LM]SB (shared object|dynamic lib ) > checking for x86_64-unknown-linux-gnu-file... no > checking for file... /usr/bin/file > checking for x86_64-unknown-linux-gnu-ranlib... (cached) ranlib > checking for x86_64-unknown-linux-gnu-strip... no > checking for strip... strip > updating cache ./config.cache > loading cache ./config.cache within ltconfig > checking for objdir... .libs > checking for gcc option to produce PIC... -fPIC -DPIC > checking if gcc PIC flag -fPIC -DPIC works... yes > checking if gcc static flag -static works... yes > finding the maximum length of command line arguments... 49153 > checking if gcc supports -c -o file.o... yes > checking if gcc supports -fno-rtti -fno-exceptions ... no > checking whether the linker (/usr/lib64/gcc/x86_64-suse-linux/ > 4.3/../../../../x86_64-suse-linux/bin/ld) supports shared > libraries... yes > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking command to parse nm output... ok > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... no > checking whether to build static libraries... yes > creating libtool > updating cache ./config.cache > configure: loading cache ./config.cache > Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing- > prototypes -Werror > checking whether to enable maintainer-specific portions of > Makefiles... no > checking whether to install libbfd... yes > checking for x86_64-unknown-linux-gnu-gcc... (cached) gcc > checking whether we are using the GNU C compiler... (cached) yes > checking whether gcc accepts -g... (cached) yes > checking for gcc option to accept ANSI C... (cached) none needed > checking for x86_64-unknown-linux-gnu-ranlib... (cached) ranlib > checking how to run the C preprocessor... gcc -E > checking for egrep... grep -E > checking for ANSI C header files... yes > checking for an ANSI C-conforming const... yes > checking for inline... inline > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking for off_t... yes > checking for size_t... yes > checking for working alloca.h... yes > checking for alloca... yes > checking for stdlib.h... (cached) yes > checking for unistd.h... (cached) yes > checking for getpagesize... yes > checking for working mmap... yes > checking argz.h usability... yes > checking argz.h presence... yes > checking for argz.h... yes > checking limits.h usability... yes > checking limits.h presence... yes > checking for limits.h... yes > checking locale.h usability... yes > checking locale.h presence... yes > checking for locale.h... yes > checking nl_types.h usability... yes > checking nl_types.h presence... yes > checking for nl_types.h... yes > checking malloc.h usability... yes > checking malloc.h presence... yes > checking for malloc.h... yes > checking for string.h... (cached) yes > checking for unistd.h... (cached) yes > checking values.h usability... yes > checking values.h presence... yes > checking for values.h... yes > checking sys/param.h usability... yes > checking sys/param.h presence... yes > checking for sys/param.h... yes > checking for getcwd... yes > checking for munmap... yes > checking for putenv... yes > checking for setenv... yes > checking for setlocale... yes > checking for strchr... yes > checking for strcasecmp... yes > checking for __argz_count... yes > checking for __argz_stringify... yes > checking for __argz_next... yes > checking for stpcpy... yes > checking for LC_MESSAGES... yes > checking whether NLS is requested... yes > checking whether included gettext is requested... no > checking libintl.h usability... yes > checking libintl.h presence... yes > checking for libintl.h... yes > checking for gettext in libc... yes > checking for msgfmt... /usr/bin/msgfmt > checking for dcgettext... yes > checking for gmsgfmt... /usr/bin/msgfmt > checking for xgettext... /usr/bin/xgettext > checking for catalogs to be installed... fr tr ja es sv da zh_CN ro > rw vi > checking for a BSD-compatible install... /usr/bin/install -c > checking for long long... yes > checking for long long... yes > checking size of long long... 8 > checking for long... yes > checking size of long... 8 > checking stddef.h usability... yes > checking stddef.h presence... yes > checking for stddef.h... yes > checking for string.h... (cached) yes > checking for strings.h... (cached) yes > checking for stdlib.h... (cached) yes > checking time.h usability... yes > checking time.h presence... yes > checking for time.h... yes > checking for unistd.h... (cached) yes > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking whether time.h and sys/time.h may both be included... yes > checking for dirent.h that defines DIR... yes > checking for library containing opendir... none required > checking whether string.h and strings.h may both be included... yes > checking for fcntl... yes > checking for getpagesize... (cached) yes > checking for setitimer... yes > checking for sysconf... yes > checking for fdopen... yes > checking for getuid... yes > checking for getgid... yes > checking for strtoull... yes > checking whether basename is declared... yes > checking whether ftello is declared... yes > checking whether ftello64 is declared... yes > checking whether fseeko is declared... yes > checking whether fseeko64 is declared... yes > checking whether ffs is declared... yes > checking whether free is declared... yes > checking whether getenv is declared... yes > checking whether malloc is declared... yes > checking whether realloc is declared... yes > checking whether stpcpy is declared... yes > checking whether strstr is declared... yes > checking whether snprintf is declared... yes > checking whether vsnprintf is declared... yes > checking sys/procfs.h usability... yes > checking sys/procfs.h presence... yes > checking for sys/procfs.h... yes > checking for prstatus_t in sys/procfs.h... yes > checking for prstatus32_t in sys/procfs.h... no > checking for prstatus_t.pr_who in sys/procfs.h... no > checking for prstatus32_t.pr_who in sys/procfs.h... no > checking for pstatus_t in sys/procfs.h... no > checking for pxstatus_t in sys/procfs.h... no > checking for pstatus32_t in sys/procfs.h... no > checking for prpsinfo_t in sys/procfs.h... yes > checking for prpsinfo32_t in sys/procfs.h... no > checking for psinfo_t in sys/procfs.h... no > checking for psinfo32_t in sys/procfs.h... no > checking for lwpstatus_t in sys/procfs.h... no > checking for lwpxstatus_t in sys/procfs.h... no > checking for lwpstatus_t.pr_context in sys/procfs.h... no > checking for lwpstatus_t.pr_reg in sys/procfs.h... no > checking for win32_pstatus_t in sys/procfs.h... no > checking for gcc version with buggy 64-bit support... no > checking for ftello... yes > checking for ftello64... yes > checking for fseeko... yes > checking for fseeko64... yes > checking for fopen64... yes > checking for off_t... (cached) yes > checking size of off_t... 8 > checking file_ptr type... BFD_HOST_64_BIT > checking for stdlib.h... (cached) yes > checking for unistd.h... (cached) yes > checking for getpagesize... (cached) yes > checking for working mmap... (cached) yes > checking for madvise... yes > checking for mprotect... yes > updating cache ./config.cache > configure: creating ./config.status > config.status: creating Makefile > config.status: creating doc/Makefile > config.status: creating bfd-in3.h > config.status: creating po/Makefile.in > config.status: creating config.h > config.status: executing depfiles commands > config.status: executing default commands > make[2]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/libiberty' > if [ x"" != x ] && [ ! -d pic ]; then \ > mkdir pic; \ > else true; fi > touch stamp-picdir > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/regex.c -o pic/regex.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/regex.c -o regex.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/cplus-dem.c -o pic/cplus-dem.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/cplus-dem.c -o cplus-dem.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/cp-demangle.c -o pic/cp-demangle.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/cp-demangle.c -o cp-demangle.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/md5.c -o pic/md5.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/md5.c -o md5.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/alloca.c -o pic/alloca.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/alloca.c -o alloca.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/argv.c -o pic/argv.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/argv.c -o argv.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/choose-temp.c -o pic/choose-temp.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/choose-temp.c -o choose-temp.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/concat.c -o pic/concat.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/concat.c -o concat.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/cp-demint.c -o pic/cp-demint.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/cp-demint.c -o cp-demint.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/dyn-string.c -o pic/dyn-string.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/dyn-string.c -o dyn-string.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/fdmatch.c -o pic/fdmatch.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/fdmatch.c -o fdmatch.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/fibheap.c -o pic/fibheap.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/fibheap.c -o fibheap.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/floatformat.c -o pic/floatformat.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/floatformat.c -o floatformat.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/fnmatch.c -o pic/fnmatch.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/fnmatch.c -o fnmatch.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/fopen_unlocked.c -o pic/ > fopen_unlocked.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/fopen_unlocked.c -o fopen_unlocked.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/getopt.c -o pic/getopt.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/getopt.c -o getopt.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/getopt1.c -o pic/getopt1.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/getopt1.c -o getopt1.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/getpwd.c -o pic/getpwd.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/getpwd.c -o getpwd.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/getruntime.c -o pic/getruntime.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/getruntime.c -o getruntime.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/hashtab.c -o pic/hashtab.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/hashtab.c -o hashtab.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/hex.c -o pic/hex.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/hex.c -o hex.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/lbasename.c -o pic/lbasename.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/lbasename.c -o lbasename.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/lrealpath.c -o pic/lrealpath.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/lrealpath.c -o lrealpath.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/make-relative-prefix.c -o pic/make- > relative-prefix.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/make-relative-prefix.c -o make-relative-prefix.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/make-temp-file.c -o pic/make-temp- > file.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/make-temp-file.c -o make-temp-file.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/objalloc.c -o pic/objalloc.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/objalloc.c -o objalloc.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/obstack.c -o pic/obstack.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/obstack.c -o obstack.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/partition.c -o pic/partition.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/partition.c -o partition.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/pexecute.c -o pic/pexecute.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/pexecute.c -o pexecute.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/physmem.c -o pic/physmem.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/physmem.c -o physmem.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/pex-common.c -o pic/pex-common.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/pex-common.c -o pex-common.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/pex-one.c -o pic/pex-one.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/pex-one.c -o pex-one.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/pex-unix.c -o pic/pex-unix.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/pex-unix.c -o pex-unix.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/safe-ctype.c -o pic/safe-ctype.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/safe-ctype.c -o safe-ctype.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/sort.c -o pic/sort.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/sort.c -o sort.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/spaces.c -o pic/spaces.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/spaces.c -o spaces.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/splay-tree.c -o pic/splay-tree.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/splay-tree.c -o splay-tree.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/strerror.c -o pic/strerror.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/strerror.c -o strerror.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/strsignal.c -o pic/strsignal.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/strsignal.c -o strsignal.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/ternary.c -o pic/ternary.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/ternary.c -o ternary.o > ../../gdb/libiberty/ternary.c:144: warning: ?ternary_recursivesearch > ? defined but not used > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/unlink-if-ordinary.c -o pic/unlink- > if-ordinary.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/unlink-if-ordinary.c -o unlink-if-ordinary.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xatexit.c -o pic/xatexit.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xatexit.c -o xatexit.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xexit.c -o pic/xexit.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xexit.c -o xexit.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xmalloc.c -o pic/xmalloc.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xmalloc.c -o xmalloc.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xmemdup.c -o pic/xmemdup.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xmemdup.c -o xmemdup.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xstrdup.c -o pic/xstrdup.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xstrdup.c -o xstrdup.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xstrerror.c -o pic/xstrerror.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xstrerror.c -o xstrerror.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xstrndup.c -o pic/xstrndup.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xstrndup.c -o xstrndup.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/mkstemps.c -o pic/mkstemps.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/mkstemps.c -o mkstemps.o > rm -f ./libiberty.a pic/./libiberty.a > ar rc ./libiberty.a \ > ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./ > alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn- > string.o ./fdmatch.o ./fibheap.o ./floatformat.o ./fnmatch.o ./ > fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./ > hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative- > prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./ > pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./ > safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./ > strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./ > xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./ > xstrndup.o ./mkstemps.o > ranlib ./libiberty.a > if [ x"" != x ]; then \ > cd pic; \ > ar rc ./libiberty.a \ > ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./ > alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn- > string.o ./fdmatch.o ./fibheap.o ./floatformat.o ./fnmatch.o ./ > fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./ > hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative- > prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./ > pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./ > safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./ > strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./ > xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./ > xstrndup.o ./mkstemps.o; \ > ranlib ./libiberty.a; \ > cd ..; \ > else true; fi > rm -f needed-list; touch needed-list; \ > for f in atexit calloc memchr memcmp memcpy memmove memset > rename strchr strerror strncmp strrchr strstr strtol strtoul tmpnam > vfprintf vprintf vfork waitpid bcmp bcopy bzero; do \ > for g in ./mkstemps.o ; do \ > case "$g" in \ > *$f*) echo $g >> needed-list ;; \ > esac; \ > done; \ > done > echo ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o ./ > argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o ./ > fdmatch.o ./fibheap.o ./floatformat.o ./fnmatch.o ./ > fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./ > hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative- > prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./ > pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./ > safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./ > strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./ > xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./ > xstrndup.o > required-list > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/libiberty/testsuite' > make[3]: F?r das Ziel ?all? ist nichts zu tun. > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/libiberty/testsuite' > make[2]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/libiberty' > make[2]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd' > Making info in doc > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > make chew > make[4]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > gcc -o chew.$$ ../../../gdb/bfd/doc/chew.c \ > -g -O2 \ > -I.. -I../../../gdb/bfd/doc/.. -I../../../gdb/bfd/doc/../../ > include -I../../../gdb/bfd/doc/../../intl -I../../intl; \ > /bin/sh ../../../gdb/bfd/doc/../../move-if-change chew.$$ chew > make[4]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > ./chew -f ../../../gdb/bfd/doc/doc.str <../../../gdb/bfd/doc/../ > aoutx.h >aoutx.tmp > /bin/sh ../../../gdb/bfd/doc/../../move-if-change aoutx.tmp aoutx.texi > make chew > make[4]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > make[4]: ?chew? ist bereits aktualisiert. > make[4]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > ./chew -f ../../../gdb/bfd/doc/doc.str <../../../gdb/bfd/doc/../ > archive.c >archive.tmp > /bin/sh ../../../gdb/bfd/doc/../../move-if-change archive.tmp > archive.texi > make chew > make[4]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > make[4]: ?chew? ist bereits aktualisiert. > make[4]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > ./chew -f ../../../gdb/bfd/doc/doc.str < ../../../gdb/bfd/doc/../ > archures.c >archures.tmp > /bin/sh ../../../gdb/bfd/doc/../../move-if-change archures.tmp > archures.texi > restore=: && backupdir=".am$$" && \ > am__cwd=`pwd` && cd ../../../gdb/bfd/doc && \ > rm -rf $backupdir && mkdir $backupdir && \ > for f in ../../../gdb/bfd/doc/bfd.info ../../../gdb/bfd/doc/ > bfd.info-[0-9] ../../../gdb/bfd/doc/bfd.info-[0-9][0-9] ../../../gdb/ > bfd/doc/bfd.i[0-9] ../../../gdb/bfd/doc/bfd.i[0-9][0-9]; do \ > if test -f $f; then mv $f $backupdir; restore=mv; else :; > fi; \ > done; \ > cd "$am__cwd"; \ > if /home/sources/mm3/language/modula3/m3tools/m3gdb- > cm3-2009-06-09/gdb/missing makeinfo --split-size=5000000 --split- > size=5000000 -I ../../../gdb/bfd/doc \ > -o ../../../gdb/bfd/doc/bfd.info ../../../gdb/bfd/doc/ > bfd.texinfo; \ > then \ > rc=0; \ > cd ../../../gdb/bfd/doc; \ > else \ > rc=$?; \ > cd ../../../gdb/bfd/doc && \ > $restore $backupdir/* `echo "./../../../gdb/bfd/doc/ > bfd.info" | sed 's|[^/]*$||'`; \ > fi; \ > rm -rf $backupdir; exit $rc > WARNING: `makeinfo' is missing on your system. You should only need > it if > you modified a `.texi' or `.texinfo' file, or any other file > indirectly affecting the aspect of the manual. The spurious > call might also be the consequence of using a buggy > `make' (AIX, > DU, IRIX). You might want to install the `Texinfo' package or > the `GNU make' package. Grab either from any GNU archive > site. > make[3]: *** [../../../gdb/bfd/doc/bfd.info] Fehler 1 > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > Making info in po > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/po' > ( if test 'x../../../gdb/bfd/po' != 'x.'; then \ > posrcprefix='../../../gdb/bfd/'; \ > else \ > posrcprefix="../"; \ > fi; \ > rm -f SRC-POTFILES-t SRC-POTFILES \ > && (sed -e '/^#/d' \ > -e '/^[ ]*$/d' \ > -e "s at .*@ $posrcprefix& \\\\@" < ../../../gdb/ > bfd/po/SRC-POTFILES.in \ > | sed -e '$s/\\$//') > SRC-POTFILES-t \ > && chmod a-w SRC-POTFILES-t \ > && mv SRC-POTFILES-t SRC-POTFILES ) > ( rm -f BLD-POTFILES-t BLD-POTFILES \ > && (sed -e '/^#/d' \ > -e '/^[ ]*$/d' \ > -e "s at .*@ ../& \\\\@" < ../../../gdb/bfd/po/BLD- > POTFILES.in \ > | sed -e '$s/\\$//') > BLD-POTFILES-t \ > && chmod a-w BLD-POTFILES-t \ > && mv BLD-POTFILES-t BLD-POTFILES ) > cd .. \ > && CONFIG_FILES=po/Makefile.in:po/Make-in \ > CONFIG_HEADERS= /bin/sh ./config.status > config.status: creating po/Makefile.in > config.status: executing depfiles commands > config.status: executing default commands > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/po' > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/po' > make[3]: F?r das Ziel ?info? ist nichts zu tun. > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/po' > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd' > make[3]: F?r das Ziel ?info-am? ist nichts zu tun. > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd' > make[2]: *** [info-recursive] Fehler 1 > make[2]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd' > make[1]: *** [all-bfd] Fehler 2 > make[1]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1' > make: *** [all] Fehler 2 From estellnb at yahoo.de Thu Jun 11 15:16:56 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Thu, 11 Jun 2009 14:16:56 +0100 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: References: <4A2FC281.1030101@yahoo.de> Message-ID: <4A3103C8.10707@yahoo.de> Even if all the global variables are put into one large struct it should be possible to read this struct via gdb. Unfortunately that does not seem to be the case. Let us consider a small sample program in this regard: MODULE GlobVars EXPORTS Main; VAR aaa, bbb, ccc, ddd : INTEGER := 1; ttt : TEXT := "SampleText"; BEGIN bbb := 2; ccc := bbb + aaa; ddd := ccc + bbb; END GlobVars. If I look at the intermediate zero address code there is a well defined record for all the globals: ... # module global data declare_segment M_GlobVars -1 v.1 ... load_integer 2 store v.1 48 Int -----LINE 8 ----- load v.1 48 Int load v.1 44 Int add Int store v.1 52 Int ... # global data type descriptor declare_record -1 1248 6 declare_field M3_MAIN 320 32 2071511887 declare_field aaa 352 32 425470580 declare_field bbb 384 32 425470580 declare_field ccc 416 32 425470580 declare_field ddd 448 32 425470580 declare_field ttt 480 32 1358456180 ... whereby the record offsets in the data type definition are bit oriented and have to be devided by eight: 352/8 = 44 (var. aaa) The corresponding assembler code looks like the following: movl MM_GlobVars at GOT(%ebx), %eax movl $2, 48(%eax) # bbb:=2 However using gdb I can not access any of the members of the MM_GlobVars struct (gdb) p MM_GlobVars.aaa There is no member named aaa. (gdb) p MM_GlobVars $18 = {} Trying to access our globals directly via their offsets listed in the .mc and .ms files worked at least although there seems to exist a quite strange mismatch. At first I had to subtract from MM_GlobVars rather than adding the offset. Secondly I had to interpret the offset as hex number although it is clear that in the .mc-file offsets are meant as plain decimal integer numbers (i.e. 0x48=72, but 48 was decimal just before!: i.e. 48*8=384 and not 0x48*0x8=0x384) p *((int*)((void*)MM_GlobVars-72 $16 = 1 p *((int*)((void*)MM_GlobVars-76 $17 = 2 Apparently the inability to access global variables via gdb as members of the module structure may be a flaw m3cc; right? ... but what about the add/sub dec/hex mismatch from above? Jay schrieb: > The global variable behavior I think I understand, and I believe the original authors did it this way on purpose, but I agree it seems quite bad. > > > The way the code is generated, all the internal globals for a module are in one large struct, per module. > > There aren't symbols for each one. > > > > > > Can anyone explain why it is done this way? And why it shouldn't be changed to how I showed? > > > > Here are some advantages/disadvanges: > > symbols, debuggability, as discussed > > The current way pretty much guaranteeds none of the data gets dead-stripped, for better and worse. > > But really, even if you changed it to "my way", there's probably another bit needed on the data to dead-strip it, > > so that behavior can be preserved, for better and worse. > > "My way" probably also allows for not using bitfields in load/store, in fact, the offseting would often go away too. > > > > > >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? > > > > > > It should build either way, but for it to be useful, yes, I expect so. > > I believe current versions of gdb can have multiple targets though. > > > > > > - Jay > > >> Date: Wed, 10 Jun 2009 15:26:09 +0100 >> From: estellnb at yahoo.de >> To: m3devel at elegosoft.com >> Subject: [M3devel] recent m3gdb does not want to compile >> >> For any kind of reason recent m3gdbs refuse to compile at me: >> >> ../gdb/configure >> ... >> checking for x86_64-unknown-linux-gnu-ar... no >> checking for ar... ar >> ... >> >>> which ar >> /usr/bin/ar >> >> setting --bindir to /usr/bin or /usr does not help. >> full error log: see attachement >> >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? >> >> Besides this I am in wonder why a plain gdb can not access global >> Modula-3 variables using PM3/EZM3 although I have specified -gstabs in >> m3config/src/COMMON: >> ASM = ["as","--32","-gstabs","-o"] % Assembler >> DEBUG_FLAG = "-gstabs" % debugging info >> BDEBUG_FLAG = "-gstabs" % debugging info >> LDEBUG_FLAG = "-gstabs" >> >> i.e. >>> gdb -batch --directory= >> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info >> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls >> >>> grep myglobal smbls -> nothing found > From rodney.m.bates at cox.net Thu Jun 11 15:05:32 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 11 Jun 2009 08:05:32 -0500 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> Message-ID: <4A31011C.2070700@cox.net> Jay wrote: > scripts/do-cm3-m3gdb.sh just cd's over to m3-sys/m3gdb and runs cm3. > > m3gdb builds and seems to work fine for me. > > Specifically, on AMD64_LINUX birch, I can both: > > mkdir -p $HOME/obj/gdb > cd $HOME/obj/gdb > $HOME/dev2/cm3/m3-sys/m3gdb/gdb/configure && make > gdb/gdb gdb/gdb > break main > r > > and > > cd $HOME/dev2/cm3/m3-sys/m3gdb > rm -rf AMD64_LINUX > cm3 > > > AMD64_LINUX/m3gdb AMD64_LINUX/m3gdb > break main > r > > > I haven't tried with Modula-3 code and/or stabs. > > > Updating from the 2005 6.4 release to a current 6.8 release is > probably advisable anyway. > > > But again, um, er, could we maybe adapt the generated code so that > plain gdb is all anyone would need/want? I don't think so. There is ~ 20K lines of Modula-3-specific code in m3gdb, and I have tens of pages of handwritten lists of more that ought to be done to make it a nice M3 debugger. I think doing it all could easily double this. The variable reference rules are different from C/C++, for example, because of the link between a module and its exported interface(s). The global variable thing is just the tip of the iceberg. For example, there is a whole lot to making procedure calls and method calls work. Ditto for nested procedures, which, after several iterations, is broken again by the change to the newest gcc as the base for the code generator, although it works somewhat. Note that gdb provides no real support for nested functions in C, even though gcc supports them as an extension to C. Probably, they are little used in C. I use them a lot in M3. Then there are just all the language-specific formats for input and output values, and expression syntax. Plus, Modula-3, being a considerably higher-level language, (at least optionally,) has a significant runtime system, and m3gdb needs to know \ quite a bit about that too. Real arrays and open arrays also need support. And TEXT is a lot different. There are also some significant differences between cm3 and the earlier compilers. I have taken the position that support for the older ones should remain, along with new stuff too. What we should do, in addition to updating to newest gdb, is change from stabs to dwarf2 debug info format, which is *much* richer in what it can express. stabs was something of a cobbled up mess to begin with, and the M3-specific extensions to it only make it worse. There's a lot of what has to be seen as very arbitrary stuff, not really stabs, wrapped inside of some of the character strings that stabs has. This change would require a significant amount of code in the compiler, as well as in m3gdb. Someday, it might also be nice to try to get the m3 changes rolled in to the stock gdb. This would require a serious commitment to maintain them there. Also, there are some copyright assertions that DEC put in to some of the code that, I believe were in violation of the GPL. We would have to somehow get a determination that the copyright ownership could be transferred to FSF, to their satisfaction. All the more difficult with DEC's identity having changed twice. IANAL. > > > Cygwin fork being so slow makes me want to optimize out such large > pieces as building gdb. > Maybe I can figure out a way to speed up Cygwin fork some day... > > > - Jay > > From estellnb at yahoo.de Thu Jun 11 21:29:58 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Thu, 11 Jun 2009 20:29:58 +0100 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A31011C.2070700@cox.net> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> Message-ID: <4A315B36.9000700@yahoo.de> As I still have the old PM3/EZM3 in use I do welcome the continuing support for that kind of old compiler tech. Besides all these advanced issues I still simply wonder on how to compile a current m3gdb. As described earlier ./configure does not even find the standard utilities like ar, as, etc. although they are on path: ../gdb/configure --target i686-pc-linux-gnu checking for i686-pc-linux-gnu-ar... no checking for i686-pc-linux-gnu-as... no I will be happy as soon as I can print global integer variables. I can convert Text-vars to char* although that will cause little extra output. The thing is that even some elder m3gdb that I still have a compilate of can not print global vars for any kind of reason (perhaps it would be necessary to update the codegen). Rodney M. Bates schrieb: > Jay wrote: >> scripts/do-cm3-m3gdb.sh just cd's over to m3-sys/m3gdb and runs cm3. >> >> m3gdb builds and seems to work fine for me. >> >> Specifically, on AMD64_LINUX birch, I can both: >> >> mkdir -p $HOME/obj/gdb >> cd $HOME/obj/gdb >> $HOME/dev2/cm3/m3-sys/m3gdb/gdb/configure && make >> gdb/gdb gdb/gdb >> break main >> r >> >> and >> >> cd $HOME/dev2/cm3/m3-sys/m3gdb >> rm -rf AMD64_LINUX >> cm3 >> >> >> AMD64_LINUX/m3gdb AMD64_LINUX/m3gdb >> break main >> r >> >> >> I haven't tried with Modula-3 code and/or stabs. >> >> >> Updating from the 2005 6.4 release to a current 6.8 release is >> probably advisable anyway. >> >> >> But again, um, er, could we maybe adapt the generated code so that >> plain gdb is all anyone would need/want? > I don't think so. There is ~ 20K lines of Modula-3-specific code in > m3gdb, and I have tens of > pages of handwritten lists of more that ought to be done to make it a > nice M3 debugger. > I think doing it all could easily double this. The variable reference > rules are different > from C/C++, for example, because of the link between a module and its > exported > interface(s). > > The global variable thing is just the tip of the iceberg. For example, > there is a whole lot > to making procedure calls and method calls work. Ditto for nested > procedures, which, > after several iterations, is broken again by the change to the newest > gcc as the base for > the code generator, although it works somewhat. Note that gdb provides > no real > support for nested functions in C, even though gcc supports them as an > extension to C. > Probably, they are little used in C. I use them a lot in M3. > > Then there are just all the language-specific formats for input and > output values, > and expression syntax. Plus, Modula-3, being a considerably > higher-level language, > (at least optionally,) has a significant runtime system, and m3gdb needs > to know \ > quite a bit about that too. Real arrays and open arrays also need > support. And > TEXT is a lot different. > > > There are also some significant differences between cm3 and the earlier > compilers. > I have taken the position that support for the older ones should remain, > along with > new stuff too. > > > What we should do, in addition to updating to newest gdb, is change from > stabs to > dwarf2 debug info format, which is *much* richer in what it can > express. stabs was > something of a cobbled up mess to begin with, and the M3-specific > extensions to it > only make it worse. There's a lot of what has to be seen as very > arbitrary stuff, > not really stabs, wrapped inside of some of the character strings that > stabs has. This change would require a significant amount of code in the > compiler, as well > as in m3gdb. > > > Someday, it might also be nice to try to get the m3 changes rolled in to > the stock > gdb. This would require a serious commitment to maintain them there. > Also, there > are some copyright assertions that DEC put in to some of the code that, > I believe > were in violation of the GPL. We would have to somehow get a > determination that > the copyright ownership could be transferred to FSF, to their > satisfaction. All the > more difficult with DEC's identity having changed twice. IANAL. >> >> >> Cygwin fork being so slow makes me want to optimize out such large >> pieces as building gdb. >> Maybe I can figure out a way to speed up Cygwin fork some day... >> >> >> - Jay >> >> > > From jay.krell at cornell.edu Thu Jun 11 22:55:27 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 11 Jun 2009 13:55:27 -0700 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A315B36.9000700@yahoo.de> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> <4A315B36.9000700@yahoo.de> Message-ID: <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> Those are not necessarily errors. It looks for platform-ar and then ar. Plain ar is fine for native builds. You probably should build outside the source tree. It is strongly recommended at least for gcc. - Jay (phone) On Jun 11, 2009, at 12:29 PM, Elmar Stellnberger wrote: > As I still have the old PM3/EZM3 in use I do welcome the continuing > support for that kind of old compiler tech. Besides all these advanced > issues I still simply wonder on how to compile a current m3gdb. As > described earlier ./configure does not even find the standard > utilities > like ar, as, etc. although they are on path: > > ../gdb/configure --target i686-pc-linux-gnu > checking for i686-pc-linux-gnu-ar... no > checking for i686-pc-linux-gnu-as... no > > I will be happy as soon as I can print global integer variables. I > can > convert Text-vars to char* although that will cause little extra > output. > The thing is that even some elder m3gdb that I still have a > compilate of > can not print global vars for any kind of reason (perhaps it would be > necessary to update the codegen). > > Rodney M. Bates schrieb: >> Jay wrote: >>> scripts/do-cm3-m3gdb.sh just cd's over to m3-sys/m3gdb and runs cm3. >>> >>> m3gdb builds and seems to work fine for me. >>> >>> Specifically, on AMD64_LINUX birch, I can both: >>> >>> mkdir -p $HOME/obj/gdb >>> cd $HOME/obj/gdb >>> $HOME/dev2/cm3/m3-sys/m3gdb/gdb/configure && make >>> gdb/gdb gdb/gdb >>> break main >>> r >>> >>> and >>> >>> cd $HOME/dev2/cm3/m3-sys/m3gdb >>> rm -rf AMD64_LINUX >>> cm3 >>> >>> >>> AMD64_LINUX/m3gdb AMD64_LINUX/m3gdb >>> break main >>> r >>> >>> >>> I haven't tried with Modula-3 code and/or stabs. >>> >>> >>> Updating from the 2005 6.4 release to a current 6.8 release is >>> probably advisable anyway. >>> >>> >>> But again, um, er, could we maybe adapt the generated code so that >>> plain gdb is all anyone would need/want? >> I don't think so. There is ~ 20K lines of Modula-3-specific code in >> m3gdb, and I have tens of >> pages of handwritten lists of more that ought to be done to make it a >> nice M3 debugger. >> I think doing it all could easily double this. The variable >> reference >> rules are different >> from C/C++, for example, because of the link between a module and its >> exported >> interface(s). >> >> The global variable thing is just the tip of the iceberg. For >> example, >> there is a whole lot >> to making procedure calls and method calls work. Ditto for nested >> procedures, which, >> after several iterations, is broken again by the change to the newest >> gcc as the base for >> the code generator, although it works somewhat. Note that gdb >> provides >> no real >> support for nested functions in C, even though gcc supports them as >> an >> extension to C. >> Probably, they are little used in C. I use them a lot in M3. >> >> Then there are just all the language-specific formats for input and >> output values, >> and expression syntax. Plus, Modula-3, being a considerably >> higher-level language, >> (at least optionally,) has a significant runtime system, and m3gdb >> needs >> to know \ >> quite a bit about that too. Real arrays and open arrays also need >> support. And >> TEXT is a lot different. >> >> >> There are also some significant differences between cm3 and the >> earlier >> compilers. >> I have taken the position that support for the older ones should >> remain, >> along with >> new stuff too. >> >> >> What we should do, in addition to updating to newest gdb, is change >> from >> stabs to >> dwarf2 debug info format, which is *much* richer in what it can >> express. stabs was >> something of a cobbled up mess to begin with, and the M3-specific >> extensions to it >> only make it worse. There's a lot of what has to be seen as very >> arbitrary stuff, >> not really stabs, wrapped inside of some of the character strings >> that >> stabs has. This change would require a significant amount of code >> in the >> compiler, as well >> as in m3gdb. >> >> >> Someday, it might also be nice to try to get the m3 changes rolled >> in to >> the stock >> gdb. This would require a serious commitment to maintain them there. >> Also, there >> are some copyright assertions that DEC put in to some of the code >> that, >> I believe >> were in violation of the GPL. We would have to somehow get a >> determination that >> the copyright ownership could be transferred to FSF, to their >> satisfaction. All the >> more difficult with DEC's identity having changed twice. IANAL. >>> >>> >>> Cygwin fork being so slow makes me want to optimize out such large >>> pieces as building gdb. >>> Maybe I can figure out a way to speed up Cygwin fork some day... >>> >>> >>> - Jay >>> >>> >> >> > > From jay.krell at cornell.edu Fri Jun 12 07:09:57 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 12 Jun 2009 05:09:57 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> <4A315B36.9000700@yahoo.de> <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> Message-ID: ps: I suggest you try to get stock gdb to build first. wget ftp://sourceware.org/pub/gdb/releases/gdb-6.8.tar.gz tar xfz gdb-6.8.tar.gz mkdir -p obj/gdb cd obj/gdb ../../gdb-6.8/configure && make - Jay [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at yahoo.de Fri Jun 12 12:27:55 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Fri, 12 Jun 2009 11:27:55 +0100 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> <4A315B36.9000700@yahoo.de> <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> Message-ID: <4A322DAB.50000@yahoo.de> Compiling gdb worked on my first attempt. checking for ar... ar checking for as... as The configure script seems to find all standard utils and make compiles gdb well. Jay schrieb: > ps: I suggest you try to get stock gdb to build first. > > > > wget ftp://sourceware.org/pub/gdb/releases/gdb-6.8.tar.gz > tar xfz gdb-6.8.tar.gz > mkdir -p obj/gdb > cd obj/gdb > ../../gdb-6.8/configure && make > > > > - Jay > [snip] > > > From jay.krell at cornell.edu Sat Jun 13 04:14:11 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 13 Jun 2009 02:14:11 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A322DAB.50000@yahoo.de> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> <4A315B36.9000700@yahoo.de> <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> <4A322DAB.50000@yahoo.de> Message-ID: Ok, the difference is configure vs. configure --target i686-pc-linux-gnu. cm3 only passes --target for cross builds...er, maybe not. That's how it is for m3cc. But http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3gdb/src/m3makefile?rev=1.13;content-type=text%2Fplain appears to always pass --target. (Have I mentioned I don't pay much attention to m3gdb...?) For now, in m3-sys/m3gdb/src/m3makefile, change this: m3gdb_Run([M3GDB_CONFIG, "../gdb/configure", CONFIG_PLATFORM]) to just this: m3gdb_Run([M3GDB_CONFIG, "../gdb/configure"]) removing the CONFIG_PLATFORM part and see what happens. I expect it will work. That isn't necessarily the right change -- don't commit it. Probably what is right enough is to make it act like m3ccc -- don't give a platform for native builds, only for cross builds. But m3cc/m3gdb/binutils are all fairly unusual, and not necessarily in the same way. Even so..are you after an x86 m3gdb or AMD64? Also, what do m3-sys/m3gdb/gdb/config.guess and m3-sys/m3cc/gcc/config.guess and the current gdb you downloaded/config.guess show? - Jay ---------------------------------------- > Date: Fri, 12 Jun 2009 11:27:55 +0100 > From: estellnb at yahoo.de > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent m3gdb does not want to compile > > Compiling gdb worked on my first attempt. > > checking for ar... ar > checking for as... as > > The configure script seems to find all standard utils and > make compiles gdb well. > > Jay schrieb: >> ps: I suggest you try to get stock gdb to build first. >> >> >> >> wget ftp://sourceware.org/pub/gdb/releases/gdb-6.8.tar.gz >> tar xfz gdb-6.8.tar.gz >> mkdir -p obj/gdb >> cd obj/gdb >> ../../gdb-6.8/configure && make >> >> >> >> - Jay >> [snip] >> >> >> > From jay.krell at cornell.edu Mon Jun 15 09:13:19 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 07:13:19 +0000 Subject: [M3devel] Solaris vfork? => suggest using fork instead? Message-ID: Is this still true: C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(943):(*** vfork - spawn new process in a virtual memory efficient way ***) C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(944):(* Avoid vfork. The way it is used in ProcessPosix breaks incremental GC: ? (*** vfork - spawn new process in a virtual memory efficient way ***) (* Avoid vfork. The way it is used in ProcessPosix breaks incremental GC: RestoreHandlers in child is reflected in parent to break VM faulting *) <*EXTERNAL "fork1"*> PROCEDURE vfork (): int; If this is true, I broke it. C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX does use vfork. Should we just use fork? vfork is the same as fork on Cygwin -- both are slow. There is also reason to use fork on NetBSD. NetBSD renames nearly every single symbol at the link level via special constructs in its header files. As a result, the usual direct extern Modula-3 pragmas are rarely correct there. That is, for the sake of NetBSD, it is best to wrap every C function with our own C functions. However, wrapping functions contradicts the Posix constraints on vfork -- you are not allowed to return from the function calling vfork without calling exec or _exit. Or do no real systems care about that? So, to be clear, I suggest changing ProcessPosix.m3 from vfork to fork. As well as RTPerfTool.m3. I suggest removing vfork from Unix/*.i3, make sure everything compiles -- that nobody uses it -- and then restoring it, in case there is a later need, to avoid bootstrapping problems if there is. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jun 15 13:12:39 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 15 Jun 2009 04:12:39 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> Message-ID: <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Hi Jay, I've been seeing some new errors attempting to build m3cc on OSX 10.4 / ppc. It seems like it might... possibly... be related to some things you have done? Or at least it's happening in the same general area of the compiler. Here we go: cd ../../gcc/mpfr && : make[2]: Nothing to be done for `all-am'. make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all'. make[1]: Nothing to be done for `all'. cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 --procedure-- -line- -file--- cp_if -- postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args Fatal Error: package build failed [lapdog:~/cm3/m3-sys/m3cc] mika% Any ideas what might be causing this? Mika Jay Krell writes: >CVSROOT: /usr/cvs >Changes by: jkrell at birch. 09/06/15 11:49:14 > >Added files: > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > gengtype-yacc.h > >Log message: > Add back the lex/yacc/flex/bison outputs that Apple deleted > but didn't note in the REMOVED file. You only see their > absence cause problems if building on a machine without > lex/yacc/flex/bison, such as birch that is missing bison. > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > so the unmodified versions of these files taken from gcc 4.2.1. From jay.krell at cornell.edu Mon Jun 15 13:26:16 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 11:26:16 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> References: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: You need a newer make. I don't remember upgrading mine, and I am using 10.4, but these are the same errors that Olaf reported on 10.3, and they were fixed by upgrading make for him. If there are really only two relevant uses of patsubst, maybe we can recode them to be more compatible? - Jay > To: jkrell at elego.de; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 15 Jun 2009 04:12:39 -0700 > From: mika at async.caltech.edu > > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: > >CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/06/15 11:49:14 > > > >Added files: > > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > > gengtype-yacc.h > > > >Log message: > > Add back the lex/yacc/flex/bison outputs that Apple deleted > > but didn't note in the REMOVED file. You only see their > > absence cause problems if building on a machine without > > lex/yacc/flex/bison, such as birch that is missing bison. > > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > > so the unmodified versions of these files taken from gcc 4.2.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 15 13:56:45 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 11:56:45 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: Please try with the change to m3makefile I just made. That might reduce or eliminate the errors. The line number didn't match up for me. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:26:16 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 You need a newer make. I don't remember upgrading mine, and I am using 10.4, but these are the same errors that Olaf reported on 10.3, and they were fixed by upgrading make for him. If there are really only two relevant uses of patsubst, maybe we can recode them to be more compatible? - Jay > To: jkrell at elego.de; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 15 Jun 2009 04:12:39 -0700 > From: mika at async.caltech.edu > > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: > >CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/06/15 11:49:14 > > > >Added files: > > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > > gengtype-yacc.h > > > >Log message: > > Add back the lex/yacc/flex/bison outputs that Apple deleted > > but didn't note in the REMOVED file. You only see their > > absence cause problems if building on a machine without > > lex/yacc/flex/bison, such as birch that is missing bison. > > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > > so the unmodified versions of these files taken from gcc 4.2.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 15 13:59:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 11:59:52 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: If that has no positive effect at all, try removing this line from m3makefile: % Save some libtool wrapping layers to speed up esp. on NT? Configure = Configure & " -disable-dependency-tracking" and be sure to rm -rf the output directory after making the change (or picking up my other change). - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:56:45 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Please try with the change to m3makefile I just made. That might reduce or eliminate the errors. The line number didn't match up for me. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:26:16 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 You need a newer make. I don't remember upgrading mine, and I am using 10.4, but these are the same errors that Olaf reported on 10.3, and they were fixed by upgrading make for him. If there are really only two relevant uses of patsubst, maybe we can recode them to be more compatible? - Jay > To: jkrell at elego.de; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 15 Jun 2009 04:12:39 -0700 > From: mika at async.caltech.edu > > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: > >CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/06/15 11:49:14 > > > >Added files: > > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > > gengtype-yacc.h > > > >Log message: > > Add back the lex/yacc/flex/bison outputs that Apple deleted > > but didn't note in the REMOVED file. You only see their > > absence cause problems if building on a machine without > > lex/yacc/flex/bison, such as birch that is missing bison. > > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > > so the unmodified versions of these files taken from gcc 4.2.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 15 14:11:08 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 12:11:08 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: Can you show me: /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/libcpp/Makefile(191) and /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/gcc/Makefile(4437) and nearby? And if those don't have patsubst: cd /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN grep -r patsubst * - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Mon, 15 Jun 2009 11:59:52 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 If that has no positive effect at all, try removing this line from m3makefile: % Save some libtool wrapping layers to speed up esp. on NT? Configure = Configure & " -disable-dependency-tracking" and be sure to rm -rf the output directory after making the change (or picking up my other change). - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:56:45 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Please try with the change to m3makefile I just made. That might reduce or eliminate the errors. The line number didn't match up for me. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:26:16 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 You need a newer make. I don't remember upgrading mine, and I am using 10.4, but these are the same errors that Olaf reported on 10.3, and they were fixed by upgrading make for him. If there are really only two relevant uses of patsubst, maybe we can recode them to be more compatible? - Jay > To: jkrell at elego.de; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 15 Jun 2009 04:12:39 -0700 > From: mika at async.caltech.edu > > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: > >CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/06/15 11:49:14 > > > >Added files: > > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > > gengtype-yacc.h > > > >Log message: > > Add back the lex/yacc/flex/bison outputs that Apple deleted > > but didn't note in the REMOVED file. You only see their > > absence cause problems if building on a machine without > > lex/yacc/flex/bison, such as birch that is missing bison. > > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > > so the unmodified versions of these files taken from gcc 4.2.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jun 15 15:29:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 15 Jun 2009 09:29:39 -0400 Subject: [M3devel] Solaris vfork? => suggest using fork instead? In-Reply-To: References: Message-ID: <4CE51F26-EDE3-46F7-9857-248D435669C3@cs.purdue.edu> Signals are no longer used for inc gc so probably ok to switch to fork. On 15 Jun 2009, at 03:13, Jay wrote: > Is this still true: > > > C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(943):(*** > vfork - spawn new process in a virtual memory efficient way ***) > C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(944):(* > Avoid vfork. The way it is used in ProcessPosix breaks incremental GC: > ? > > (*** vfork - spawn new process in a virtual memory efficient way ***) > (* Avoid vfork. The way it is used in ProcessPosix breaks > incremental GC: > RestoreHandlers in child is reflected in parent to break VM faulting > *) > <*EXTERNAL "fork1"*> PROCEDURE vfork (): int; > > > If this is true, I broke it. > > > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX does use vfork. > > > Should we just use fork? > vfork is the same as fork on Cygwin -- both are slow. > > There is also reason to use fork on NetBSD. > NetBSD renames nearly every single symbol at the link level via > special constructs in its header files. > As a result, the usual direct extern Modula-3 pragmas are rarely > correct there. > That is, for the sake of NetBSD, it is best to wrap every C > function with our own C functions. > However, wrapping functions contradicts the Posix constraints on > vfork -- you are not allowed to return from the function calling > vfork without calling exec or _exit. Or do no real systems care > about that? > > > So, to be clear, I suggest changing ProcessPosix.m3 from vfork to > fork. > As well as RTPerfTool.m3. > > > I suggest removing vfork from Unix/*.i3, make sure everything > compiles -- that nobody uses it -- and then restoring it, in case > there is a later need, to avoid bootstrapping problems if there is. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jun 15 21:09:48 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 15 Jun 2009 12:09:48 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 15 Jun 2009 11:56:45 -0000." Message-ID: <200906151909.n5FJ9mJq038972@camembert.async.caltech.edu> Yep, that seems to have fixed that problem. Thanks! Mika Jay writes: >--_b2ac6846-ec7a-45ce-b56a-ddd2a77b25de_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Please try with the change to m3makefile I just made. > >That might reduce or eliminate the errors. > >The line number didn't match up for me. > >=20 > > - Jay >=20 > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu=3B jkrell at elego.de >Date: Mon=2C 15 Jun 2009 11:26:16 +0000 >CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > >You need a newer make. >I don't remember upgrading mine=2C and I am using 10.4=2C but these are the= > same errors that Olaf reported on 10.3=2C and they were fixed by upgrading= > make for him. >=20 >If there are really only two relevant uses of patsubst=2C maybe we can reco= >de them to be more compatible? >=20 > - Jay > >=20 >> To: jkrell at elego.de=3B jay.krell at cornell.edu >> CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >> Subject: Re: [M3commit] CVS Update: cm3=20 >> Date: Mon=2C 15 Jun 2009 04:12:39 -0700 >> From: mika at async.caltech.edu >>=20 >> Hi Jay=2C >>=20 >> I've been seeing some new errors attempting to build m3cc on OSX >> 10.4 / ppc. >>=20 >> It seems like it might... possibly... be related to some things you >> have done? Or at least it's happening in the same general area of >> the compiler. >>=20 >> Here we go: >>=20 >> cd ../../gcc/mpfr && : >> make[2]: Nothing to be done for `all-am'. >> make[2]: Nothing to be done for `all'. >> make[2]: Nothing to be done for `all'. >> make[1]: Nothing to be done for `all'. >> cd . && cd libcpp && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOM= >AKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/c= >m3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> cd . && cd libcpp && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOM= >AKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/c= >m3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> Makefile:191: *** Insufficient number of arguments (2) to function `patsu= >bst'. Stop. >> cd . && cd gcc && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config.h m3cg | tee -= >a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> cd . && cd gcc && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config.h m3cg | tee -= >a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> Makefile:4437: *** Insufficient number of arguments (2) to function `pats= >ubst'. Stop. >> "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile"=2C line 508: quake runtime e= >rror: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=3D2 >>=20 >> --procedure-- -line- -file--- >> cp_if -- >> postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile >> include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile >> 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args >>=20 >> Fatal Error: package build failed >> [lapdog:~/cm3/m3-sys/m3cc] mika%=20 >>=20 >> Any ideas what might be causing this? >>=20 >> Mika >>=20 >>=20 >>=20 >> Jay Krell writes: >> >CVSROOT: /usr/cvs >> >Changes by: jkrell at birch. 09/06/15 11:49:14 >> > >> >Added files: >> > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c=20 >> > gengtype-yacc.h=20 >> > >> >Log message: >> > Add back the lex/yacc/flex/bison outputs that Apple deleted >> > but didn't note in the REMOVED file. You only see their >> > absence cause problems if building on a machine without >> > lex/yacc/flex/bison=2C such as birch that is missing bison. >> > Apple didn't modify gengtype-lex.l and gentype-yacc.y=2C >> > so the unmodified versions of these files taken from gcc 4.2.1. > >--_b2ac6846-ec7a-45ce-b56a-ddd2a77b25de_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Please try with the change to m3makefile I just made.
>That might reduce or eliminate =3Bthe errors.
>The line number didn't match up for me.
> =3B
> =3B- Jay
 =3B
>
>From: jay.krell at cornell.edu
To: mika at async.caltech.edu=3B jkrell at elego.d= >e
Date: Mon=2C 15 Jun 2009 11:26:16 +0000
CC: m3devel at elegosoft.com= >=3B mika at camembert.async.caltech.edu
Subject: Re: [M3devel] [M3commit] C= >VS Update: cm3

> >You need a newer make.
I don't remember upgrading mine=2C and I am using= > 10.4=2C but these are the same errors that Olaf reported on 10.3=2C and th= >ey were fixed by upgrading make for him.
 =3B
If there are really= > only two relevant uses of patsubst=2C maybe we can recode them to be more = >compatible?
 =3B
 =3B- Jay

 =3B
>=3B To: jkre= >ll at elego.de=3B jay.krell at cornell.edu
>=3B CC: m3devel at elegosoft.com=3B= > mika at camembert.async.caltech.edu
>=3B Subject: Re: [M3commit] CVS Upd= >ate: cm3
>=3B Date: Mon=2C 15 Jun 2009 04:12:39 -0700
>=3B From:= > mika at async.caltech.edu
>=3B
>=3B Hi Jay=2C
>=3B
>=3B= > I've been seeing some new errors attempting to build m3cc on OSX
>=3B= > 10.4 / ppc.
>=3B
>=3B It seems like it might... possibly... be = >related to some things you
>=3B have done? Or at least it's happening = >in the same general area of
>=3B the compiler.
>=3B
>=3B He= >re we go:
>=3B
>=3B cd ../../gcc/mpfr &=3B&=3B :
>=3B= > make[2]: Nothing to be done for `all-am'.
>=3B make[2]: Nothing to be= > done for `all'.
>=3B make[2]: Nothing to be done for `all'.
>=3B= > make[1]: Nothing to be done for `all'.
>=3B cd . &=3B&=3B cd li= >bcpp &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/cm3/= >m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
>=3B cd . &=3B&=3B cd libc= >pp &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/cm3/= >m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
>=3B Makefile:191: *** Insuffici= >ent number of arguments (2) to function `patsubst'. Stop.
>=3B cd . &a= >mp=3B&=3B cd gcc &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCO= >NF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config= >.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
&= >gt=3B cd . &=3B&=3B cd gcc &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-= >O2 -g" AUTOCONF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-mode= >s insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN= >/_m3.log
>=3B Makefile:4437: *** Insufficient number of arguments (2) = >to function `patsubst'. Stop.
>=3B "/Users/mika/cm3/m3-sys/m3cc/src/m3= >makefile"=2C line 508: quake runtime error: unable to copy "./gcc/m3cgc1" t= >o "./cm3cg": errno=3D2
>=3B
>=3B --procedure-- -line- -file---R>>=3B cp_if -- <=3Bbuiltin>=3B
>=3B postcp 508 /Users/mika/cm3/= >m3-sys/m3cc/src/m3makefile
>=3B include_dir 592 /Users/mika/cm3/m3-sys= >/m3cc/src/m3makefile
>=3B 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3m= >ake.args
>=3B
>=3B Fatal Error: package build failed
>=3B [= >lapdog:~/cm3/m3-sys/m3cc] mika%
>=3B
>=3B Any ideas what might = >be causing this?
>=3B
>=3B Mika
>=3B
>=3B
>=3B = >
>=3B Jay Krell writes:
>=3B >=3BCVSROOT: /usr/cvs
>=3B &g= >t=3BChanges by: jkrell at birch. 09/06/15 11:49:14
>=3B >=3B
>=3B = >>=3BAdded files:
>=3B >=3B cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtyp= >e-lex.c gengtype-yacc.c
>=3B >=3B gengtype-yacc.h
>=3B >=3B= >
>=3B >=3BLog message:
>=3B >=3B Add back the lex/yacc/flex/b= >ison outputs that Apple deleted
>=3B >=3B but didn't note in the REM= >OVED file. You only see their
>=3B >=3B absence cause problems if bu= >ilding on a machine without
>=3B >=3B lex/yacc/flex/bison=2C such as= > birch that is missing bison.
>=3B >=3B Apple didn't modify gengtype= >-lex.l and gentype-yacc.y=2C
>=3B >=3B so the unmodified versions of= > these files taken from gcc 4.2.1.
>= > >--_b2ac6846-ec7a-45ce-b56a-ddd2a77b25de_-- From mika at async.caltech.edu Mon Jun 15 21:12:56 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 15 Jun 2009 12:12:56 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 15 Jun 2009 12:11:08 -0000." Message-ID: <200906151912.n5FJCu1t039130@camembert.async.caltech.edu> I already CVS updated but here is what I see now: [lapdog:m3-sys/m3cc/PPC_DARWIN] mika% grep patsubst */Makefile gcc/Makefile:srcdirify = $(patsubst $(srcdir)%,$$(gcc_srcdir)%,$(filter $(srcdir)%,$(1))) \ gcc/Makefile: $(patsubst %,$$(gcc_objdir)/%,$(filter-out $(srcdir)%,$(1))) gcc/Makefile:GTFILES_H = $(subst /,-, $(patsubst $(srcdir)/%,gt-%, $(patsubst %.c,%.h, \ gcc/Makefile:GTFILES_LANG_H = $(patsubst [%], gtype-%.h, $(filter [%], $(GTFILES))) libcpp/Makefile:-include $(patsubst %.o, $(DEPDIR)/%.Po, $(libcpp_a_OBJS) $(makedepend_OBJS)) [lapdog:m3-sys/m3cc/PPC_DARWIN] mika% Jay writes: >--_f3a3f40d-3d61-443a-b5cd-8c10d784957b_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Can you show me: > > > /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/libcpp/Makefile(191) =20 > > and =20 > > /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/gcc/Makefile(4437) =20 > >=20 > > and nearby? And if those don't have patsubst: =20 > >=20 > > cd /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN =20 > > grep -r patsubst * =20 > >=20 > > - Jay >=20 > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu >Date: Mon=2C 15 Jun 2009 11:59:52 +0000 >CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > >If that has no positive effect at all=2C try removing this line from m3make= >file: >=20 > % Save some libtool wrapping layers to speed up esp. on NT? > Configure =3D Configure & " -disable-dependency-tracking" > and be sure to rm -rf the output directory after making the change (or pick= >ing up my other change). >=20 > - Jay >=20 > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu=3B jkrell at elego.de >Date: Mon=2C 15 Jun 2009 11:56:45 +0000 >CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > >Please try with the change to m3makefile I just made. >That might reduce or eliminate the errors. >The line number didn't match up for me. >=20 > - Jay >=20 > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu=3B jkrell at elego.de >Date: Mon=2C 15 Jun 2009 11:26:16 +0000 >CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > >You need a newer make. >I don't remember upgrading mine=2C and I am using 10.4=2C but these are the= > same errors that Olaf reported on 10.3=2C and they were fixed by upgrading= > make for him. >=20 >If there are really only two relevant uses of patsubst=2C maybe we can reco= >de them to be more compatible? >=20 > - Jay > >=20 >> To: jkrell at elego.de=3B jay.krell at cornell.edu >> CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >> Subject: Re: [M3commit] CVS Update: cm3=20 >> Date: Mon=2C 15 Jun 2009 04:12:39 -0700 >> From: mika at async.caltech.edu >>=20 >> Hi Jay=2C >>=20 >> I've been seeing some new errors attempting to build m3cc on OSX >> 10.4 / ppc. >>=20 >> It seems like it might... possibly... be related to some things you >> have done? Or at least it's happening in the same general area of >> the compiler. >>=20 >> Here we go: >>=20 >> cd ../../gcc/mpfr && : >> make[2]: Nothing to be done for `all-am'. >> make[2]: Nothing to be done for `all'. >> make[2]: Nothing to be done for `all'. >> make[1]: Nothing to be done for `all'. >> cd . && cd libcpp && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOM= >AKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/c= >m3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> cd . && cd libcpp && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOM= >AKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/c= >m3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> Makefile:191: *** Insufficient number of arguments (2) to function `patsu= >bst'. Stop. >> cd . && cd gcc && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config.h m3cg | tee -= >a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> cd . && cd gcc && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config.h m3cg | tee -= >a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> Makefile:4437: *** Insufficient number of arguments (2) to function `pats= >ubst'. Stop. >> "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile"=2C line 508: quake runtime e= >rror: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=3D2 >>=20 >> --procedure-- -line- -file--- >> cp_if -- >> postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile >> include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile >> 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args >>=20 >> Fatal Error: package build failed >> [lapdog:~/cm3/m3-sys/m3cc] mika%=20 >>=20 >> Any ideas what might be causing this? >>=20 >> Mika >>=20 >>=20 >>=20 >> Jay Krell writes: >> >CVSROOT: /usr/cvs >> >Changes by: jkrell at birch. 09/06/15 11:49:14 >> > >> >Added files: >> > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c=20 >> > gengtype-yacc.h=20 >> > >> >Log message: >> > Add back the lex/yacc/flex/bison outputs that Apple deleted >> > but didn't note in the REMOVED file. You only see their >> > absence cause problems if building on a machine without >> > lex/yacc/flex/bison=2C such as birch that is missing bison. >> > Apple didn't modify gengtype-lex.l and gentype-yacc.y=2C >> > so the unmodified versions of these files taken from gcc 4.2.1. > >--_f3a3f40d-3d61-443a-b5cd-8c10d784957b_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Can you show me:
>
 =3B /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/libcpp/Makefile(191)&nb= >sp=3B
> =3B and =3B
> =3B /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/gcc/Makefile(4437) =3B = >
> =3B
> =3B and nearby? And if those don't have patsubst: =3B
> =3B
> =3B cd /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN =3B
> =3B grep -r patsubst * =3B
> =3B
> =3B- Jay
 =3B
>
>From: jay.krell at cornell.edu
To: mika at async.caltech.edu
Date: Mon=2C 1= >5 Jun 2009 11:59:52 +0000
CC: m3devel at elegosoft.com=3B mika at camembert.as= >ync.caltech.edu
Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> > >If that has no positive effect at all=2C try removing this line from m3make= >file:
 =3B
 =3B =3B =3B % Save some libtool wrapping = >layers to speed up esp. on NT?
 =3B =3B =3B Configure =3D Co= >nfigure &=3B " -disable-dependency-tracking"

and be sure to rm -r= >f the output directory after making the change (or picking up my other chan= >ge).
 =3B
 =3B- Jay
 =3B
>
>From: jay.krell at cornell.edu
To: mika at async.caltech.edu=3B jkrell at elego.d= >e
Date: Mon=2C 15 Jun 2009 11:56:45 +0000
CC: m3devel at elegosoft.com= >=3B mika at camembert.async.caltech.edu
Subject: Re: [M3devel] [M3commit] C= >VS Update: cm3

> >Please try with the change to m3makefile I just made.
That might reduce = >or eliminate =3Bthe errors.
The line number didn't match up for me.<= >BR> =3B
 =3B- Jay
 =3B
>
>From: jay.krell at cornell.edu
To: mika at async.caltech.edu=3B jkrell at elego.d= >e
Date: Mon=2C 15 Jun 2009 11:26:16 +0000
CC: m3devel at elegosoft.com= >=3B mika at camembert.async.caltech.edu
Subject: Re: [M3devel] [M3commit] C= >VS Update: cm3

> >You need a newer make.
I don't remember upgrading mine=2C and I am using= > 10.4=2C but these are the same errors that Olaf reported on 10.3=2C and th= >ey were fixed by upgrading make for him.
 =3B
If there are really= > only two relevant uses of patsubst=2C maybe we can recode them to be more = >compatible?
 =3B
 =3B- Jay

 =3B
>=3B To: jkre= >ll at elego.de=3B jay.krell at cornell.edu
>=3B CC: m3devel at elegosoft.com=3B= > mika at camembert.async.caltech.edu
>=3B Subject: Re: [M3commit] CVS Upd= >ate: cm3
>=3B Date: Mon=2C 15 Jun 2009 04:12:39 -0700
>=3B From:= > mika at async.caltech.edu
>=3B
>=3B Hi Jay=2C
>=3B
>=3B= > I've been seeing some new errors attempting to build m3cc on OSX
>=3B= > 10.4 / ppc.
>=3B
>=3B It seems like it might... possibly... be = >related to some things you
>=3B have done? Or at least it's happening = >in the same general area of
>=3B the compiler.
>=3B
>=3B He= >re we go:
>=3B
>=3B cd ../../gcc/mpfr &=3B&=3B :
>=3B= > make[2]: Nothing to be done for `all-am'.
>=3B make[2]: Nothing to be= > done for `all'.
>=3B make[2]: Nothing to be done for `all'.
>=3B= > make[1]: Nothing to be done for `all'.
>=3B cd . &=3B&=3B cd li= >bcpp &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/cm3/= >m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
>=3B cd . &=3B&=3B cd libc= >pp &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/cm3/= >m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
>=3B Makefile:191: *** Insuffici= >ent number of arguments (2) to function `patsubst'. Stop.
>=3B cd . &a= >mp=3B&=3B cd gcc &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCO= >NF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config= >.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
&= >gt=3B cd . &=3B&=3B cd gcc &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-= >O2 -g" AUTOCONF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-mode= >s insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN= >/_m3.log
>=3B Makefile:4437: *** Insufficient number of arguments (2) = >to function `patsubst'. Stop.
>=3B "/Users/mika/cm3/m3-sys/m3cc/src/m3= >makefile"=2C line 508: quake runtime error: unable to copy "./gcc/m3cgc1" t= >o "./cm3cg": errno=3D2
>=3B
>=3B --procedure-- -line- -file---R>>=3B cp_if -- <=3Bbuiltin>=3B
>=3B postcp 508 /Users/mika/cm3/= >m3-sys/m3cc/src/m3makefile
>=3B include_dir 592 /Users/mika/cm3/m3-sys= >/m3cc/src/m3makefile
>=3B 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3m= >ake.args
>=3B
>=3B Fatal Error: package build failed
>=3B [= >lapdog:~/cm3/m3-sys/m3cc] mika%
>=3B
>=3B Any ideas what might = >be causing this?
>=3B
>=3B Mika
>=3B
>=3B
>=3B = >
>=3B Jay Krell writes:
>=3B >=3BCVSROOT: /usr/cvs
>=3B &g= >t=3BChanges by: jkrell at birch. 09/06/15 11:49:14
>=3B >=3B
>=3B = >>=3BAdded files:
>=3B >=3B cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtyp= >e-lex.c gengtype-yacc.c
>=3B >=3B gengtype-yacc.h
>=3B >=3B= >
>=3B >=3BLog message:
>=3B >=3B Add back the lex/yacc/flex/b= >ison outputs that Apple deleted
>=3B >=3B but didn't note in the REM= >OVED file. You only see their
>=3B >=3B absence cause problems if bu= >ilding on a machine without
>=3B >=3B lex/yacc/flex/bison=2C such as= > birch that is missing bison.
>=3B >=3B Apple didn't modify gengtype= >-lex.l and gentype-yacc.y=2C
>=3B >=3B so the unmodified versions of= > these files taken from gcc 4.2.1.
>= > >--_f3a3f40d-3d61-443a-b5cd-8c10d784957b_-- From jay.krell at cornell.edu Mon Jun 15 21:50:39 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 19:50:39 +0000 Subject: [M3devel] tinderbox FreeBSD diskspace Message-ID: The FreeBSD tinderbox machines continue to run out of diskspace occasionally. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 15 22:47:21 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 15 Jun 2009 13:47:21 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200906151912.n5FJCu1t039130@camembert.async.caltech.edu> References: <200906151912.n5FJCu1t039130@camembert.async.caltech.edu> Message-ID: <1B731B2D-D655-44BC-A4A9-4AB274558270@hotmail.com> Ok so presumably on those lines is 'CATALOGS'? - Jay (phone) On Jun 15, 2009, at 12:12 PM, Mika Nystrom wrote: > I already CVS updated but here is what I see now: > > [lapdog:m3-sys/m3cc/PPC_DARWIN] mika% grep patsubst */Makefile > gcc/Makefile:srcdirify = $(patsubst $(srcdir)%,$$(gcc_srcdir)%,$ > (filter $(srcdir)%,$(1))) \ > gcc/Makefile: $(patsubst %,$$(gcc_objdir)/%,$(filter-out $ > (srcdir)%,$(1))) > gcc/Makefile:GTFILES_H = $(subst /,-, $(patsubst $(srcdir)/%,gt-%, $ > (patsubst %.c,%.h, \ > gcc/Makefile:GTFILES_LANG_H = $(patsubst [%], gtype-%.h, $(filter > [%], $(GTFILES))) > libcpp/Makefile:-include $(patsubst %.o, $(DEPDIR)/%.Po, $ > (libcpp_a_OBJS) $(makedepend_OBJS)) > [lapdog:m3-sys/m3cc/PPC_DARWIN] mika% > > Jay writes: >> --_f3a3f40d-3d61-443a-b5cd-8c10d784957b_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> Can you show me: >> >> >> /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/libcpp/Makefile(191) =20 >> >> and =20 >> >> /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/gcc/Makefile(4437) =20 >> >> =20 >> >> and nearby? And if those don't have patsubst: =20 >> >> =20 >> >> cd /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN =20 >> >> grep -r patsubst * =20 >> >> =20 >> >> - Jay >> =20 >> > From jay.krell at cornell.edu Tue Jun 16 07:02:48 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 15 Jun 2009 22:02:48 -0700 Subject: [M3devel] Solaris vfork? => suggest using fork instead? In-Reply-To: <4CE51F26-EDE3-46F7-9857-248D435669C3@cs.purdue.edu> References: <4CE51F26-EDE3-46F7-9857-248D435669C3@cs.purdue.edu> Message-ID: <83CA3DD2-C85B-4C1F-A14D-DC535C093B8D@hotmail.com> Ps I exaggerated netbsd. It does rename some functions though. - Jay (phone) On Jun 15, 2009, at 6:29 AM, Tony Hosking wrote: > Signals are no longer used for inc gc so probably ok to switch to > fork. > > On 15 Jun 2009, at 03:13, Jay wrote: > >> Is this still true: >> >> >> C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(943):(*** >> vfork - spawn new process in a virtual memory efficient way ***) >> C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(944):(* >> Avoid vfork. The way it is used in ProcessPosix breaks incremental >> GC: >> ? >> >> (*** vfork - spawn new process in a virtual memory efficient way ***) >> (* Avoid vfork. The way it is used in ProcessPosix breaks >> incremental GC: >> RestoreHandlers in child is reflected in parent to break VM >> faulting *) >> <*EXTERNAL "fork1"*> PROCEDURE vfork (): int; >> >> >> If this is true, I broke it. >> >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX does use vfork. >> >> >> Should we just use fork? >> vfork is the same as fork on Cygwin -- both are slow. >> >> There is also reason to use fork on NetBSD. >> NetBSD renames nearly every single symbol at the link level via >> special constructs in its header files. >> As a result, the usual direct extern Modula-3 pragmas are rarely >> correct there. >> That is, for the sake of NetBSD, it is best to wrap every C >> function with our own C functions. >> However, wrapping functions contradicts the Posix constraints on >> vfork -- you are not allowed to return from the function calling >> vfork without calling exec or _exit. Or do no real systems care >> about that? >> >> >> So, to be clear, I suggest changing ProcessPosix.m3 from vfork to >> fork. >> As well as RTPerfTool.m3. >> >> >> I suggest removing vfork from Unix/*.i3, make sure everything >> compiles -- that nobody uses it -- and then restoring it, in case >> there is a later need, to avoid bootstrapping problems if there is. >> >> >> - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Jun 16 09:01:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 16 Jun 2009 00:01:18 -0700 Subject: [M3devel] Strange behavior in recent CM3-compiled code... Message-ID: <200906160701.n5G71I8K061661@camembert.async.caltech.edu> Hello everyone, I'm trying to update to the latest CM3 again, so that I can get my Mac working, and push my project of migrating a largish codebase from PM3 to CM3 a little further. I updated CM3 today from CVS, on both my Mac and on a FreeBSD system, and ... my Scheme interpreter broke. Here's what the code looks like, with annotations: 49 Debug.Out("t.rest = NIL? " & Fmt.Bool(t.rest=NIL)); 50 Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); 51 Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); 52 53 IF t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL THEN 54 Debug.Out("in IF clause..."); 55 56 IF SymEq(t.first, "quote") THEN special := "'" 57 ELSIF SymEq(t.first, "quasiquote") THEN special := "`" 58 ELSIF SymEq(t.first, "unquote") THEN special := "," 59 ELSIF SymEq(t.first, "unquote-splicing") THEN special := ",@" 60 END 61 ELSE 62 Debug.Out("in ELSE clause...") 63 END; all you need to know is that Debug.Out prints out debugging information to the terminal. What I see is... t.rest = NIL? FALSE ISTYPE(t.rest,T)? TRUE Rest(t.rest) = NIL? TRUE in ELSE clause... What gives!? Note this behavior occurs on both the Mac and on FreeBSD4 with a compiler and runtime bootstrapped today from some previous CM3. My old CM3 compiler was timestamped... April 30, I believe, and the code behaved properly under that one. I believe I have also tried it both with and without compiler optimizations. I find it baffling that so much stuff (mentor!) can work if "AND" isn't working right. This is the only if statement in many, many source files that seems to be working wrong. Is it possible I'm missing something?? No I don't think so... here's a more explicit version: Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); Debug.Out("conjunction? " & Fmt.Bool( t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL )); IF t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL THEN ... output is: t.rest # NIL? TRUE ISTYPE(t.rest,T)? TRUE Rest(t.rest) = NIL? TRUE conjunction? FALSE in ELSE clause... TRUE AND TRUE AND TRUE is FALSE?? Note that: VAR q, w, e := TRUE; Debug.Out("conjunction? " & Fmt.Bool( q AND w AND e)); results in TRUE (as it should). Mika From jay.krell at cornell.edu Tue Jun 16 09:11:08 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 07:11:08 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: <200906160701.n5G71I8K061661@camembert.async.caltech.edu> References: <200906160701.n5G71I8K061661@camembert.async.caltech.edu> Message-ID: Kneejerk generic response: I don't know the operator precedence. Can you put in parens? Have you looked at the code? Can you mail us a small self contained repro? Can you test it on birch? (That way -- all your files are there and easily gotten/investigated by others.) Optimization enabled? Works without? I know, I shouldn't even ask this sort of thing without evidence. - Jay > To: m3devel at elegosoft.com > Date: Tue, 16 Jun 2009 00:01:18 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] Strange behavior in recent CM3-compiled code... > > > Hello everyone, > > I'm trying to update to the latest CM3 again, so that I can get my > Mac working, and push my project of migrating a largish codebase > from PM3 to CM3 a little further. > > I updated CM3 today from CVS, on both my Mac and on a FreeBSD system, > and ... my Scheme interpreter broke. Here's what the code looks like, > with annotations: > > 49 Debug.Out("t.rest = NIL? " & Fmt.Bool(t.rest=NIL)); > 50 Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); > 51 Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > 52 > 53 IF t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL THEN > 54 Debug.Out("in IF clause..."); > 55 > 56 IF SymEq(t.first, "quote") THEN special := "'" > 57 ELSIF SymEq(t.first, "quasiquote") THEN special := "`" > 58 ELSIF SymEq(t.first, "unquote") THEN special := "," > 59 ELSIF SymEq(t.first, "unquote-splicing") THEN special := ",@" > 60 END > 61 ELSE > 62 Debug.Out("in ELSE clause...") > 63 END; > > all you need to know is that Debug.Out prints out debugging information > to the terminal. What I see is... > > t.rest = NIL? FALSE > ISTYPE(t.rest,T)? TRUE > Rest(t.rest) = NIL? TRUE > in ELSE clause... > > What gives!? > > Note this behavior occurs on both the Mac and on FreeBSD4 with a > compiler and runtime bootstrapped today from some previous CM3. > My old CM3 compiler was timestamped... April 30, I believe, and the > code behaved properly under that one. > > I believe I have also tried it both with and without compiler > optimizations. > > I find it baffling that so much stuff (mentor!) can work if "AND" isn't > working right. This is the only if statement in many, many source files > that seems to be working wrong. > > Is it possible I'm missing something?? No I don't think so... here's a more > explicit version: > > Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); > Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > Debug.Out("conjunction? " & Fmt.Bool( > t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL )); > IF t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL THEN > ... > > output is: > > t.rest # NIL? TRUE > ISTYPE(t.rest,T)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > > TRUE AND TRUE AND TRUE is FALSE?? > > Note that: > > VAR q, w, e := TRUE; > > Debug.Out("conjunction? " & Fmt.Bool( > q AND w AND e)); > > results in TRUE (as it should). > > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Jun 16 09:50:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 16 Jun 2009 00:50:18 -0700 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." Message-ID: <200906160750.n5G7oIWN063277@camembert.async.caltech.edu> Operator precedence? This isn't C, you know! You can't do NIL AND x in Modula-3. Nevertheless, AND has lower precedence than anything else I'm using here. OR is the lowest. Green Book, section 2.6.2 (p. 49). But to allay your fears, I can report that adding parens around each of the terms doesn't change the behavior, either printing or the IF. My q, w, e was an attempt at isolating the problem but it didn't. I don't know what to start cutting back. I was hoping someone would see it and think "oops, I touched ... the other day and it must have broken this". And yes as I mentioned I tried both with and without optimization. Unfortunately x86 assembly is pretty much gibberish to me. It's part of a rather large software system... I'll see what I can do about getting it up on birch or making a smaller test case... Meanwhile I'll write the code at the end of this message. Mika Jay writes: >--_55f6c801-7d57-4602-a131-dda139b64dfd_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Kneejerk generic response: > >=20 > >I don't know the operator precedence. Can you put in parens? > >Have you looked at the code? > >Can you mail us a small self contained repro? > >Can you test it on birch? > > (That way -- all your files are there and easily gotten/investigated by o= >thers.) > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= >rt of thing without evidence. > >=20 > > - Jay >=20 >> To: m3devel at elegosoft.com >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... >>=20 >>=20 >> Hello everyone=2C >>=20 >> I'm trying to update to the latest CM3 again=2C so that I can get my >> Mac working=2C and push my project of migrating a largish codebase >> from PM3 to CM3 a little further. >>=20 >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C >> and ... my Scheme interpreter broke. Here's what the code looks like=2C >> with annotations: >>=20 >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B >> 52 >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN >> 54 Debug.Out("in IF clause...")=3B >> 55 >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" >> 60 END >> 61 ELSE >> 62 Debug.Out("in ELSE clause...") >> 63 END=3B >>=20 >> all you need to know is that Debug.Out prints out debugging information >> to the terminal. What I see is... >>=20 >> t.rest =3D NIL? FALSE >> ISTYPE(t.rest=2CT)? TRUE >> Rest(t.rest) =3D NIL? TRUE >> in ELSE clause... >>=20 >> What gives!? >>=20 >> Note this behavior occurs on both the Mac and on FreeBSD4 with a >> compiler and runtime bootstrapped today from some previous CM3. >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the >> code behaved properly under that one. >>=20 >> I believe I have also tried it both with and without compiler >> optimizations. >>=20 >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't >> working right. This is the only if statement in many=2C many source files >> that seems to be working wrong. >>=20 >> Is it possible I'm missing something?? No I don't think so... here's a mo= >re >> explicit version: >>=20 >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B >> Debug.Out("conjunction? " & Fmt.Bool( >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN >> ... >>=20 >> output is: >>=20 >> t.rest # NIL? TRUE >> ISTYPE(t.rest=2CT)? TRUE >> Rest(t.rest) =3D NIL? TRUE >> conjunction? FALSE >> in ELSE clause... >>=20 >> TRUE AND TRUE AND TRUE is FALSE?? >>=20 >> Note that:=20 >>=20 >> VAR q=2C w=2C e :=3D TRUE=3B >>=20 >> Debug.Out("conjunction? " & Fmt.Bool( >> q AND w AND e))=3B >>=20 >> results in TRUE (as it should). >>=20 >>=20 >> Mika >>=20 > (* $Id: SchemePair.m3,v 1.8 2009/03/29 07:27:13 mika Exp $ *) MODULE SchemePair; IMPORT Wx; IMPORT SchemeObject, SchemeUtils, SchemeSymbol; FROM Scheme IMPORT E; FROM SchemeUtils IMPORT Error, StringifyT; IMPORT RefSeq; IMPORT Debug, Fmt; PROCEDURE StringifyPair(t : T; quoted : BOOLEAN; buf : Wx.T; seen : RefSeq.T) RAISES { E } = CONST SymEq = SchemeSymbol.SymEq; StringifyB = SchemeUtils.StringifyB; Rest = SchemeUtils.Rest; Second = SchemeUtils.Second; VAR special : TEXT := NIL; BEGIN Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); Debug.Out("conjunction? " & Fmt.Bool( ( t.rest # NIL) AND (ISTYPE(t.rest,T)) AND (Rest(t.rest) = NIL) )); IF (t.rest # NIL) AND ISTYPE(t.rest,T) AND (Rest(t.rest) = NIL) THEN Debug.Out("in IF clause..."); IF SymEq(t.first, "quote") THEN special := "'" ELSIF SymEq(t.first, "quasiquote") THEN special := "`" ELSIF SymEq(t.first, "unquote") THEN special := "," ELSIF SymEq(t.first, "unquote-splicing") THEN special := ",@" END ELSE Debug.Out("in ELSE clause...") END; IF special # NIL THEN Wx.PutText(buf, special); StringifyB(Second(t), quoted, buf, seen) ELSE Wx.PutChar(buf, '('); StringifyB(t.first, quoted, buf, seen); VAR tail := t.rest; BEGIN WHILE tail # NIL AND ISTYPE(tail,T) DO Wx.PutChar(buf, ' '); StringifyB(NARROW(tail,T).first, quoted, buf, seen); tail := NARROW(tail,T).rest END; IF tail # NIL THEN Wx.PutText(buf, " . "); StringifyB(tail, quoted, buf, seen) END; Wx.PutChar(buf, ')') END END END StringifyPair; PROCEDURE Pair(x : SchemeObject.T) : T RAISES { E } = BEGIN IF ISTYPE(x,T) THEN RETURN x (* NIL is OK for Pair! *) ELSE RETURN Pair(Error("expected a pair, got: " & StringifyT(x))) END END Pair; BEGIN END SchemePair. ---------------------------------------------------------------------- .file "SchemePair.mc" .stabs "/big/home/mika/t-cm3/mscheme/FreeBSD4/",100,0,0,.Ltext0 .stabs "SchemePair.mc",100,0,0,.Ltext0 .text .Ltext0: .stabs "gcc2_compiled.",60,0,0,0 .stabs "procedures_have_extra_block.",60,0,0,0 .stabs "MP_CMGwxk_32_L1:T(0,1)=s0AAAAAA:(0,2)=r(0,2);-2147483648;2147483647;,0,32;DobPBR_t:(0,2),0,32;AicXUJ_quoted:(0,2),0,32;BYmXDz_buf:(0,2),0,32;AZx9O5_seen:(0,2),0,32;Scheme.E:(0,2),0,32;;",128,0,0,0 .stabs "MP_DkRnTw_32_L1:T(0,3)=s0DobPBR:(0,2),0,32;Af40ku_x:(0,2),0,32;Scheme.E:(0,2),0,32;;",128,0,0,0 .stabs "MX_BUgnwf_32:T(0,4)=s0DWIlZi:(0,2),0,32;;",128,0,0,0 .stabs "MX_CKMnXU_32:T(0,5)=s0Cgclyt:(0,2),0,32;;",128,0,0,0 .stabs "MX_BtKsLk_32:T(0,6)=s0C7ehAd:(0,2),0,32;;",128,0,0,0 .stabs "SchemePair__StringifyPair:F(0,7)=(0,7)",36,0,17,SchemePair__StringifyPair .stabs "M3_DobPBR_t:p(0,8)=*(0,7)",160,0,74,8 .stabs "M3_AicXUJ_quoted:p(0,9)=@s8;r(0,9);0;255;",160,0,74,12 .stabs "M3_BYmXDz_buf:p(0,8)",160,0,74,16 .stabs "M3_AZx9O5_seen:p(0,8)",160,0,74,20 .globl SchemePair__StringifyPair .type SchemePair__StringifyPair, @function SchemePair__StringifyPair: .stabd 46,0,0 .stabs "../src/SchemePair.m3",132,0,0,.Ltext1 .Ltext1: .stabn 68,0,17,.LM0-.LFBB1 .LM0: .LFBB1: pushl %ebp movl %esp, %ebp pushl %ebx subl $84, %esp .LBB2: .stabn 68,0,24,.LM1-.LFBB1 .LM1: movl $0, -40(%ebp) .stabn 68,0,27,.LM2-.LFBB1 .LM2: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -36(%ebp) movl -36(%ebp), %eax testl %eax, %eax je .L2 movl -36(%ebp), %eax andl $1, %eax testb %al, %al jne .L2 movl -36(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L2 movl -36(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L2: movl -36(%ebp), %eax testl %eax, %eax setne %al movzbl %al, %eax movl %eax, (%esp) call Fmt__Bool movl %eax, -32(%ebp) movl -32(%ebp), %eax movl $L_1+24, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -28(%ebp) movl -28(%ebp), %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,28,.LM3-.LFBB1 .LM3: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -28(%ebp) movl -28(%ebp), %eax testl %eax, %eax je .L3 movl -28(%ebp), %eax andl $1, %eax testb %al, %al jne .L3 movl -28(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L3 movl -28(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L3: movl $1, -24(%ebp) movl -28(%ebp), %eax testl %eax, %eax je .L4 movl -28(%ebp), %eax andl $1, %eax testb %al, %al jne .L5 movl -28(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L4 jmp .L6 .L5: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L4 .L6: movl $0, -24(%ebp) .L4: movl -24(%ebp), %eax movl %eax, (%esp) call Fmt__Bool movl %eax, -32(%ebp) movl -32(%ebp), %eax movl $L_1+52, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -36(%ebp) movl -36(%ebp), %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,29,.LM4-.LFBB1 .LM4: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -36(%ebp) movl -36(%ebp), %eax testl %eax, %eax je .L7 movl -36(%ebp), %eax andl $1, %eax testb %al, %al jne .L7 movl -36(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L7 movl -36(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L7: movl -36(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Rest movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax sete %al movzbl %al, %eax movl %eax, (%esp) call Fmt__Bool movl %eax, -28(%ebp) movl -28(%ebp), %eax movl $L_1+84, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -20(%ebp) movl -20(%ebp), %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,30,.LM5-.LFBB1 .LM5: movl $0, -24(%ebp) movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -20(%ebp) movl -20(%ebp), %eax testl %eax, %eax je .L8 movl -20(%ebp), %eax andl $1, %eax testb %al, %al jne .L8 movl -20(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L8 movl -20(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L8: movl -20(%ebp), %eax testl %eax, %eax je .L9 movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -28(%ebp) movl -28(%ebp), %eax testl %eax, %eax je .L10 movl -28(%ebp), %eax andl $1, %eax testb %al, %al jne .L10 movl -28(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L10 movl -28(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L10: movl -28(%ebp), %eax testl %eax, %eax je .L11 movl -28(%ebp), %eax andl $1, %eax testb %al, %al jne .L12 movl -28(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx jne .L9 .L12: movl MM_SchemePair+176, %eax cmpl $3, %eax jne .L9 .L11: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L13 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L13 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L13 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L13: movl -32(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Rest movl %eax, -36(%ebp) movl -36(%ebp), %eax testl %eax, %eax jne .L9 movl $1, -24(%ebp) .L9: movl -24(%ebp), %eax movl %eax, (%esp) call Fmt__Bool movl %eax, -16(%ebp) movl -16(%ebp), %eax movl $L_1+120, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -12(%ebp) movl -12(%ebp), %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,32,.LM6-.LFBB1 .LM6: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -12(%ebp) movl -12(%ebp), %eax testl %eax, %eax je .L14 movl -12(%ebp), %eax andl $1, %eax testb %al, %al jne .L14 movl -12(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L14 movl -12(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L14: movl -12(%ebp), %eax testl %eax, %eax je .L15 movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -16(%ebp) movl -16(%ebp), %eax testl %eax, %eax je .L16 movl -16(%ebp), %eax andl $1, %eax testb %al, %al jne .L16 movl -16(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L16 movl -16(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L16: movl -16(%ebp), %eax testl %eax, %eax je .L17 movl -16(%ebp), %eax andl $1, %eax testb %al, %al jne .L18 movl -16(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx jne .L15 .L18: movl MM_SchemePair+176, %eax cmpl $3, %eax jne .L15 .L17: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -36(%ebp) movl -36(%ebp), %eax testl %eax, %eax je .L19 movl -36(%ebp), %eax andl $1, %eax testb %al, %al jne .L19 movl -36(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L19 movl -36(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L19: movl -36(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Rest movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax jne .L15 .stabn 68,0,33,.LM7-.LFBB1 .LM7: movl $L_1+148, %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,35,.LM8-.LFBB1 .LM8: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L20 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L20 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L20 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L20: movl $L_1+176, %eax movl -32(%ebp), %edx movl %eax, 4(%esp) movl %edx, (%esp) call SchemeSymbol__SymEq movb %al, -5(%ebp) movzbl -5(%ebp), %eax xorl $1, %eax testb %al, %al jne .L21 movl $L_1+196, %eax movl %eax, -40(%ebp) jmp .L29 .L21: .stabn 68,0,36,.LM9-.LFBB1 .LM9: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L23 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L23 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L23 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L23: movl $L_1+212, %eax movl -32(%ebp), %edx movl %eax, 4(%esp) movl %edx, (%esp) call SchemeSymbol__SymEq movb %al, -5(%ebp) movzbl -5(%ebp), %eax xorl $1, %eax testb %al, %al jne .L24 movl $L_1+236, %eax movl %eax, -40(%ebp) jmp .L29 .L24: .stabn 68,0,37,.LM10-.LFBB1 .LM10: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L25 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L25 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L25 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L25: movl $L_1+252, %eax movl -32(%ebp), %edx movl %eax, 4(%esp) movl %edx, (%esp) call SchemeSymbol__SymEq movb %al, -5(%ebp) movzbl -5(%ebp), %eax xorl $1, %eax testb %al, %al jne .L26 movl $L_1+272, %eax movl %eax, -40(%ebp) jmp .L29 .L26: .stabn 68,0,38,.LM11-.LFBB1 .LM11: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L27 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L27 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L27 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L27: movl $L_1+288, %eax movl -32(%ebp), %edx movl %eax, 4(%esp) movl %edx, (%esp) call SchemeSymbol__SymEq movb %al, -5(%ebp) movzbl -5(%ebp), %eax xorl $1, %eax testb %al, %al jne .L29 movl $L_1+320, %eax movl %eax, -40(%ebp) jmp .L29 .L15: .stabn 68,0,41,.LM12-.LFBB1 .LM12: movl $L_1+336, %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .L29: .stabn 68,0,45,.LM13-.LFBB1 .LM13: movl -40(%ebp), %eax testl %eax, %eax je .L30 .stabn 68,0,46,.LM14-.LFBB1 .LM14: movl -40(%ebp), %eax movl 16(%ebp), %edx movl $0, 20(%esp) movl $0, 16(%esp) movl $0, 12(%esp) movl $0, 8(%esp) movl %eax, 4(%esp) movl %edx, (%esp) call Wx__PutText .stabn 68,0,47,.LM15-.LFBB1 .LM15: movl 8(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Second movl %eax, -32(%ebp) movl 20(%ebp), %edx movl 16(%ebp), %ecx movzbl 12(%ebp), %eax movzbl %al, %eax movl -32(%ebp), %ebx movl %edx, 12(%esp) movl %ecx, 8(%esp) movl %eax, 4(%esp) movl %ebx, (%esp) call SchemeUtils__StringifyB jmp .L47 .L30: .stabn 68,0,49,.LM16-.LFBB1 .LM16: movl 16(%ebp), %eax movl $40, 4(%esp) movl %eax, (%esp) call Wx__PutChar .stabn 68,0,50,.LM17-.LFBB1 .LM17: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L32 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L32 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L32 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L32: movl 20(%ebp), %edx movl 16(%ebp), %ecx movzbl 12(%ebp), %eax movzbl %al, %eax movl -32(%ebp), %ebx movl %edx, 12(%esp) movl %ecx, 8(%esp) movl %eax, 4(%esp) movl %ebx, (%esp) call SchemeUtils__StringifyB .LBB3: .stabn 68,0,51,.LM18-.LFBB1 .LM18: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L33 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L33 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L33 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L33: movl -32(%ebp), %eax movl %eax, -44(%ebp) jmp .L34 .L35: .stabn 68,0,54,.LM19-.LFBB1 .LM19: movl 16(%ebp), %eax movl $32, 4(%esp) movl %eax, (%esp) call Wx__PutChar .stabn 68,0,55,.LM20-.LFBB1 .LM20: movl -44(%ebp), %eax testl %eax, %eax je .L36 movl -44(%ebp), %eax andl $1, %eax testb %al, %al jne .L37 movl -44(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L36 movl $1765, (%esp) call _m3_fault .L37: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L36 movl $1765, (%esp) call _m3_fault .L36: movl -44(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L38 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L38 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L38 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L38: movl 20(%ebp), %edx movl 16(%ebp), %ecx movzbl 12(%ebp), %eax movzbl %al, %eax movl -32(%ebp), %ebx movl %edx, 12(%esp) movl %ecx, 8(%esp) movl %eax, 4(%esp) movl %ebx, (%esp) call SchemeUtils__StringifyB .stabn 68,0,56,.LM21-.LFBB1 .LM21: movl -44(%ebp), %eax testl %eax, %eax je .L39 movl -44(%ebp), %eax andl $1, %eax testb %al, %al jne .L40 movl -44(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L39 movl $1797, (%esp) call _m3_fault .L40: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L39 movl $1797, (%esp) call _m3_fault .L39: movl -44(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L41 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L41 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L41 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L41: movl -32(%ebp), %eax movl %eax, -44(%ebp) .L34: .stabn 68,0,53,.LM22-.LFBB1 .LM22: movl -44(%ebp), %eax testl %eax, %eax je .L45 movl -44(%ebp), %eax testl %eax, %eax je .L35 movl -44(%ebp), %eax andl $1, %eax testb %al, %al jne .L43 movl -44(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L35 .L43: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L35 .L45: .stabn 68,0,58,.LM23-.LFBB1 .LM23: movl -44(%ebp), %eax testl %eax, %eax je .L46 .stabn 68,0,59,.LM24-.LFBB1 .LM24: movl $L_1+368, %eax movl 16(%ebp), %edx movl $0, 20(%esp) movl $0, 16(%esp) movl $0, 12(%esp) movl $0, 8(%esp) movl %eax, 4(%esp) movl %edx, (%esp) call Wx__PutText .stabn 68,0,60,.LM25-.LFBB1 .LM25: movl 20(%ebp), %edx movl 16(%ebp), %ecx movzbl 12(%ebp), %eax movzbl %al, %eax movl -44(%ebp), %ebx movl %edx, 12(%esp) movl %ecx, 8(%esp) movl %eax, 4(%esp) movl %ebx, (%esp) call SchemeUtils__StringifyB .L46: .stabn 68,0,62,.LM26-.LFBB1 .LM26: movl 16(%ebp), %eax movl $41, 4(%esp) movl %eax, (%esp) call Wx__PutChar .L47: .LBE3: .LBE2: .stabn 68,0,65,.LM27-.LFBB1 .LM27: addl $84, %esp popl %ebx popl %ebp ret .size SchemePair__StringifyPair, .-SchemePair__StringifyPair .stabn 192,0,0,.LFBB1-.LFBB1 .stabs "M3_Bd56fi_special:(0,8)",128,0,74,-40 .stabn 192,0,0,.LBB2-.LFBB1 .stabs "M3_Af40ku_tail:(0,8)",128,0,51,-44 .stabn 192,0,0,.LBB3-.LFBB1 .stabn 224,0,0,.LBE3-.LFBB1 .stabn 224,0,0,.LBE2-.LFBB1 .stabn 224,0,0,.Lscope1-.LFBB1 .Lscope1: .stabs "",36,0,0,.Lscope1-.LFBB1 .stabd 78,0,0 .stabs "SchemePair__Pair:F(0,8)",36,0,67,SchemePair__Pair .stabs "M3_Af40ku_x:p(0,8)",160,0,74,8 .globl SchemePair__Pair .type SchemePair__Pair, @function SchemePair__Pair: .stabd 46,0,0 .stabn 68,0,67,.LM28-.LFBB2 .LM28: .LFBB2: pushl %ebp movl %esp, %ebp subl $56, %esp .LBB4: .stabn 68,0,69,.LM29-.LFBB2 .LM29: movl 8(%ebp), %eax testl %eax, %eax je .L49 movl 8(%ebp), %eax andl $1, %eax testb %al, %al jne .L50 movl 8(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx jne .L51 .L50: movl MM_SchemePair+176, %eax cmpl $3, %eax jne .L51 .L49: movl 8(%ebp), %eax testl %eax, %eax je .L52 movl 8(%ebp), %eax andl $1, %eax testb %al, %al jne .L53 movl 8(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L52 movl $2213, (%esp) call _m3_fault .L53: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L52 movl $2213, (%esp) call _m3_fault .L52: movl 8(%ebp), %eax movl %eax, -36(%ebp) jmp .L48 .L51: .stabn 68,0,70,.LM30-.LFBB2 .LM30: movl 8(%ebp), %eax movl %eax, (%esp) call SchemeUtils__StringifyT movl %eax, -20(%ebp) movl -20(%ebp), %eax movl $L_1+384, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -16(%ebp) movl -16(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Error movl %eax, -12(%ebp) movl -12(%ebp), %eax movl %eax, (%esp) call SchemePair__Pair movl %eax, -8(%ebp) movl -8(%ebp), %eax movl %eax, -36(%ebp) .L48: .LBE4: movl -36(%ebp), %eax leave ret .size SchemePair__Pair, .-SchemePair__Pair .stabn 192,0,0,.LFBB2-.LFBB2 .stabs "M3_DobPBR__result:(0,8)",128,0,74,-4 .stabn 192,0,0,.LBB4-.LFBB2 .stabn 224,0,0,.LBE4-.LFBB2 .stabn 224,0,0,.Lscope2-.LFBB2 .Lscope2: .stabs "",36,0,0,.Lscope2-.LFBB2 .stabd 78,0,0 .stabs "SchemePair_M3:F(0,8)",36,0,74,SchemePair_M3 .stabs "M3_AcxOUs_mode:p(0,2)",160,0,74,8 .globl SchemePair_M3 .type SchemePair_M3, @function SchemePair_M3: .stabd 46,0,0 .stabn 68,0,74,.LM31-.LFBB3 .LM31: .LFBB3: pushl %ebp movl %esp, %ebp subl $4, %esp .LBB5: .stabn 68,0,74,.LM32-.LFBB3 .LM32: movl 8(%ebp), %eax movl $MM_SchemePair, %eax .LBE5: leave ret .size SchemePair_M3, .-SchemePair_M3 .stabn 192,0,0,.LFBB3-.LFBB3 .stabn 192,0,0,.LBB5-.LFBB3 .stabn 224,0,0,.LBE5-.LFBB3 .stabn 224,0,0,.Lscope3-.LFBB3 .Lscope3: .stabs "",36,0,0,.Lscope3-.LFBB3 .stabd 78,0,0 .stabs "MR_zzzzzz_4032:T(0,10)=s0;",128,0,0,0 .stabs "MR_zzzzzz_1440:T(0,11)=s0;",128,0,0,0 .stabs "Mi_zzzzzz_SchemePair:T(0,12)=s0SchemePair:(0,2),0,32;;",128,0,0,0 .stabs "_m3_fault:f(0,7)",36,0,0,_m3_fault .stabs "M3_AcxOUs_arg:p(0,13)=r(0,13);0;037777777777;",160,0,55,8 .type _m3_fault, @function _m3_fault: .stabd 46,0,0 .stabn 68,0,0,.LM33-.LFBB4 .LM33: .LFBB4: pushl %ebp movl %esp, %ebp subl $8, %esp movl 8(%ebp), %eax movl %eax, 4(%esp) movl $MM_SchemePair, (%esp) call RTHooks__ReportFault leave ret .size _m3_fault, .-_m3_fault .stabn 192,0,0,.LFBB4-.LFBB4 .stabn 224,0,0,.Lscope4-.LFBB4 .Lscope4: .stabs "",36,0,0,.Lscope4-.LFBB4 .stabd 78,0,0 .data .align 32 .type L_1, @object .size L_1, 504 L_1: .long RTHooks__TextLitInfo .long RTHooks__TextLitGetChar .long RTHooks__TextLitGetWideChar .long RTHooks__TextLitGetChars .long RTHooks__TextLitGetWideChars .long 2 .long L_1 .long 14 .ascii "t.rest # NIL? " .zero 2 .long 2 .long L_1 .long 18 .ascii "ISTYPE(t.rest,T)? " .zero 2 .long 2 .long L_1 .long 20 .ascii "Rest(t.rest) = NIL? " .zero 4 .long 2 .long L_1 .long 13 .ascii "conjunction? " .zero 3 .long 2 .long L_1 .long 15 .ascii "in IF clause..." .zero 1 .long 2 .long L_1 .long 5 .ascii "quote" .zero 3 .long 2 .long L_1 .long 1 .ascii "'" .zero 3 .long 2 .long L_1 .long 10 .ascii "quasiquote" .zero 2 .long 2 .long L_1 .long 1 .ascii "`" .zero 3 .long 2 .long L_1 .long 7 .ascii "unquote" .zero 1 .long 2 .long L_1 .long 1 .ascii "," .zero 3 .long 2 .long L_1 .long 16 .ascii "unquote-splicing" .zero 4 .long 2 .long L_1 .long 2 .ascii ",@" .zero 2 .long 2 .long L_1 .long 17 .ascii "in ELSE clause..." .zero 3 .long 2 .long L_1 .long 3 .ascii " . " .zero 1 .long 2 .long L_1 .long 22 .ascii "expected a pair, got: " .zero 2 .ascii "SchemePair_M3" .zero 1 .ascii "Pair" .zero 1 .ascii "StringifyPair" .zero 4 .long SchemePair_M3 .long L_1+416 .long SchemePair__Pair .long L_1+430 .long SchemePair__StringifyPair .long L_1+435 .zero 4 .ascii "../src/SchemePair.m3" .zero 4 .align 32 .type MM_SchemePair, @object .size MM_SchemePair, 180 MM_SchemePair: .long L_1+480 .zero 4 .long MM_SchemePair+172 .zero 8 .long L_1+452 .zero 12 .long MM_SchemePair+52 .zero 4 .long SchemePair_M3 .long 3 .zero 4 .long SchemePair_I3 .long MM_SchemePair+64 .zero 4 .long Fmt_I3 .long MM_SchemePair+76 .zero 4 .long Debug_I3 .long MM_SchemePair+88 .zero 4 .long RefSeq_I3 .long MM_SchemePair+100 .zero 4 .long Scheme_I3 .long MM_SchemePair+112 .zero 4 .long SchemeSymbol_I3 .long MM_SchemePair+124 .zero 4 .long SchemeUtils_I3 .long MM_SchemePair+136 .zero 4 .long SchemeObject_I3 .long MM_SchemePair+148 .zero 4 .long Wx_I3 .long MM_SchemePair+160 .zero 4 .long RTHooks_I3 .zero 8 .long -949022765 .stabs "L_1:S(0,14)=s504;",38,0,9,L_1 .stabs "MM_SchemePair:S(0,15)=s180;",38,0,9,MM_SchemePair .text .stabs "",100,0,0,.Letext0 .Letext0: .ident "GCC: (GNU) 4.3.0" From mika at async.caltech.edu Tue Jun 16 09:59:10 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 16 Jun 2009 00:59:10 -0700 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." Message-ID: <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> This small example exhibits it! MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = BRANDED "Pair" REF RECORD first, rest : REFANY; END; PROCEDURE Rest(p : Pair) : REFANY = BEGIN IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END END Rest; VAR t := NEW(Pair, first := "first", rest := NEW(Pair, first := "second", rest := NIL)); BEGIN PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); PutLn("conjunction? " & Fmt.Bool( (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Output: (133)rover:~/testcm3/src>m3build -O --- building in ../FreeBSD4 --- m3build: missing ../src/m3overrides new source -> compiling ../src/Main.m3 -> linking prog (134)rover:~/testcm3/src>../FreeBSD4/prog t.rest # NIL? TRUE ISTYPE(t.rest,Pair)? TRUE Rest(t.rest) = NIL? TRUE conjunction? TRUE in IF clause... (135)rover:~/testcm3/src>cm3 -clean --- cleaning ../FreeBSD4 --- (136)rover:~/testcm3/src>cm3 --- building in ../FreeBSD4 --- new source -> compiling Main.m3 -> linking prog (137)rover:~/testcm3/src>../FreeBSD4/prog t.rest # NIL? TRUE ISTYPE(t.rest,Pair)? TRUE Rest(t.rest) = NIL? TRUE conjunction? FALSE in ELSE clause... (138)rover:~/testcm3/src> Jay writes: >--_55f6c801-7d57-4602-a131-dda139b64dfd_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Kneejerk generic response: > >=20 > >I don't know the operator precedence. Can you put in parens? > >Have you looked at the code? > >Can you mail us a small self contained repro? > >Can you test it on birch? > > (That way -- all your files are there and easily gotten/investigated by o= >thers.) > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= >rt of thing without evidence. > >=20 > > - Jay >=20 >> To: m3devel at elegosoft.com >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... >>=20 >>=20 >> Hello everyone=2C >>=20 >> I'm trying to update to the latest CM3 again=2C so that I can get my >> Mac working=2C and push my project of migrating a largish codebase >> from PM3 to CM3 a little further. >>=20 >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C >> and ... my Scheme interpreter broke. Here's what the code looks like=2C >> with annotations: >>=20 >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B >> 52 >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN >> 54 Debug.Out("in IF clause...")=3B >> 55 >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" >> 60 END >> 61 ELSE >> 62 Debug.Out("in ELSE clause...") >> 63 END=3B >>=20 >> all you need to know is that Debug.Out prints out debugging information >> to the terminal. What I see is... >>=20 >> t.rest =3D NIL? FALSE >> ISTYPE(t.rest=2CT)? TRUE >> Rest(t.rest) =3D NIL? TRUE >> in ELSE clause... >>=20 >> What gives!? >>=20 >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > compiler and runtime bootstrapped today from some previous CM3. >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the >> code behaved properly under that one. >>=20 >> I believe I have also tried it both with and without compiler >> optimizations. >>=20 >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't >> working right. This is the only if statement in many=2C many source files >> that seems to be working wrong. >>=20 >> Is it possible I'm missing something?? No I don't think so... here's a mo= >re >> explicit version: >>=20 >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B >> Debug.Out("conjunction? " & Fmt.Bool( >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN >> ... >>=20 >> output is: >>=20 >> t.rest # NIL? TRUE >> ISTYPE(t.rest=2CT)? TRUE >> Rest(t.rest) =3D NIL? TRUE >> conjunction? FALSE >> in ELSE clause... >>=20 >> TRUE AND TRUE AND TRUE is FALSE?? >>=20 >> Note that:=20 >>=20 >> VAR q=2C w=2C e :=3D TRUE=3B >>=20 >> Debug.Out("conjunction? " & Fmt.Bool( >> q AND w AND e))=3B >>=20 >> results in TRUE (as it should). >>=20 >>=20 >> Mika >>=20 > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Kneejerk generic response:
> =3B
>I don't know the operator precedence. Can you put in parens?
>Have you looked at the code?
>Can you mail us a small self contained repro?
>Can you test it on birch?
> =3B (That way -- all your files are there and easily gotten/investigat= >ed by others.)
>Optimization enabled? Works without? I know=2C I shouldn't even ask this so= >rt of thing without evidence.
> =3B
> =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= >eed to know is that Debug.Out prints out debugging information
>=3B to= > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= >ieve I have also tried it both with and without compiler
>=3B optimiza= >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > can work if "AND" isn't
>=3B working right. This is the only if state= >ment in many=2C many source files
>=3B that seems to be working wrong.= >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= >ka
>=3B
>= > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- From jay.krell at cornell.edu Tue Jun 16 10:44:21 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 08:44:21 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: Cool. Here is a smaller repro, on birch AMD64_LINUX. The problem is not the AND, the problem is the IF. MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = REF RECORD rest : REFANY; END; VAR t := NEW(Pair, rest := NEW(Pair, rest := NIL)); BEGIN PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); IF ISTYPE(t.rest,Pair) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Tony this is presumably your type tagging changes?? The problem in the code I think is the compare to the number 3. .L13: movq 312+MM_Main(%rip), %rax cmpq $3, %rax <==== jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT What is that for? It comes right from the IL: (118) set_source_line source line 17 (119) import_procedure procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd (120) declare_param param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 alignment 0x40 in _memory 0x0 up_level 0x0 mode 0x11 (DImode) (121) set_runtime_proc (122) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (123) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (124) load_nil (125) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (126) if_eq (127) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (128) loophole (129) load_integer integer 0x1 (130) and (131) if_true (132) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (133) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (134) extract_mn (135) if_false (136) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (137) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (138) pop_param pop param type 0xb (139) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (140) set_label (141) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (142) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (143) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (144) load_nil (145) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (146) if_eq (147) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (148) loophole (149) load_integer integer 0x1 (150) and (151) if_true (152) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (153) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (154) extract_mn (155) if_false (156) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (157) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (158) pop_param pop param type 0xb (159) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (160) set_label (161) load_integer integer 0x1 (162) declare_temp temp var type 0x7 size 0x40 alignment 0x40 (163) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (164) load_nil (165) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (166) if_eq (167) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (168) loophole (169) load_integer integer 0x1 (170) and (171) if_true (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq (177) jump (178) set_label (179) load_integer integer 0x3 (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq (182) set_label (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 alignment 0x8 in_mem ory 0x0 up_level 0x0 mode 0xe () (188) start_call_direct start call procedure Fmt__Bool, level 0x0, type 0xb (189) load m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 (190) pop_param pop param type 0x0 (191) call_direct call procedure Fmt__Bool, type 0xb (192) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (193) start_call_direct start call procedure RTHooks__Concat, level 0x0, type 0xb (194) load_address load address (L_1) offset 0x280 (195) pop_param pop param type 0xb (196) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (197) pop_param pop param type 0xb (198) call_direct call procedure RTHooks__Concat, type 0xb (199) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (200) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (201) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (202) pop_param pop param type 0xb (203) call_direct call procedure Main__PutLn, type 0xd (204) set_source_line source line 18 (205) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (206) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (207) load_nil (208) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (209) if_eq (210) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (211) loophole (212) load_integer integer 0x1 (213) and (214) if_true (215) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (216) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (217) extract_mn (218) if_false (219) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (220) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (221) pop_param pop param type 0xb (222) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (223) set_label (224) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (225) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (226) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (227) load_nil (228) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (229) if_eq (230) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (231) loophole (232) load_integer integer 0x1 (233) and (234) if_true (235) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (236) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (237) extract_mn (238) if_false (239) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (240) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (241) pop_param pop param type 0xb (242) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (243) set_label (244) load_nil (245) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (246) if_eq (247) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (248) loophole (249) load_integer integer 0x1 (250) and (251) if_true (252) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (253) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (254) extract_mn (255) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (256) if_ne (257) set_label (258) load_integer integer 0x3 <===== (259) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (260) if_ne (261) set_label (262) set_source_line source line 19 (263) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (264) load_address load address (L_1) offset 0x400 (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump (268) set_label (269) set_source_line source line 21 (270) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (271) load_address load address (L_1) offset 0x540 (272) pop_param pop param type 0xb (273) call_direct call procedure Main__PutLn, type 0xd (274) set_label (275) set_label (276) load_address load address (MM_Main) offset 0x0 (277) exit_proc (278) free_temp (279) free_temp (280) free_temp (281) free_temp (282) free_temp (283) end_procedure procedure Main_M3 (284) comment comment: `global constant type descriptor' (285) declare_record record id 0xffffffff, fields 0x0, size 0x940 (286) comment comment: `global data type descriptor' I'll dig a bit more. - Jay > To: jay.krell at cornell.edu > Date: Tue, 16 Jun 2009 00:59:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > This small example exhibits it! > > MODULE Main; > IMPORT IO, Fmt; > > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > > TYPE > Pair = BRANDED "Pair" REF RECORD > first, rest : REFANY; > END; > > PROCEDURE Rest(p : Pair) : REFANY = > BEGIN > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > END Rest; > > VAR > t := NEW(Pair, first := "first", > rest := NEW(Pair, first := "second", > rest := NIL)); > > BEGIN > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > PutLn("conjunction? " & Fmt.Bool( > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Output: > > (133)rover:~/testcm3/src>m3build -O > --- building in ../FreeBSD4 --- > m3build: missing ../src/m3overrides > new source -> compiling ../src/Main.m3 > -> linking prog > (134)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? TRUE > in IF clause... > (135)rover:~/testcm3/src>cm3 -clean > --- cleaning ../FreeBSD4 --- > > (136)rover:~/testcm3/src>cm3 > --- building in ../FreeBSD4 --- > > new source -> compiling Main.m3 > -> linking prog > (137)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > (138)rover:~/testcm3/src> > > Jay writes: > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Kneejerk generic response: > > > >=20 > > > >I don't know the operator precedence. Can you put in parens? > > > >Have you looked at the code? > > > >Can you mail us a small self contained repro? > > > >Can you test it on birch? > > > > (That way -- all your files are there and easily gotten/investigated by o= > >thers.) > > > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence. > > > >=20 > > > > - Jay > >=20 > >> To: m3devel at elegosoft.com > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... > >>=20 > >>=20 > >> Hello everyone=2C > >>=20 > >> I'm trying to update to the latest CM3 again=2C so that I can get my > >> Mac working=2C and push my project of migrating a largish codebase > >> from PM3 to CM3 a little further. > >>=20 > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C > >> and ... my Scheme interpreter broke. Here's what the code looks like=2C > >> with annotations: > >>=20 > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> 52 > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> 54 Debug.Out("in IF clause...")=3B > >> 55 > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" > >> 60 END > >> 61 ELSE > >> 62 Debug.Out("in ELSE clause...") > >> 63 END=3B > >>=20 > >> all you need to know is that Debug.Out prints out debugging information > >> to the terminal. What I see is... > >>=20 > >> t.rest =3D NIL? FALSE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> in ELSE clause... > >>=20 > >> What gives!? > >>=20 > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > compiler and runtime bootstrapped today from some previous CM3. > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the > >> code behaved properly under that one. > >>=20 > >> I believe I have also tried it both with and without compiler > >> optimizations. > >>=20 > >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't > >> working right. This is the only if statement in many=2C many source files > >> that seems to be working wrong. > >>=20 > >> Is it possible I'm missing something?? No I don't think so... here's a mo= > >re > >> explicit version: > >>=20 > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> Debug.Out("conjunction? " & Fmt.Bool( > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> ... > >>=20 > >> output is: > >>=20 > >> t.rest # NIL? TRUE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> conjunction? FALSE > >> in ELSE clause... > >>=20 > >> TRUE AND TRUE AND TRUE is FALSE?? > >>=20 > >> Note that:=20 > >>=20 > >> VAR q=2C w=2C e :=3D TRUE=3B > >>=20 > >> Debug.Out("conjunction? " & Fmt.Bool( > >> q AND w AND e))=3B > >>=20 > >> results in TRUE (as it should). > >>=20 > >>=20 > >> Mika > >>=20 > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Kneejerk generic response:
> > =3B
> >I don't know the operator precedence. Can you put in parens?
> >Have you looked at the code?
> >Can you mail us a small self contained repro?
> >Can you test it on birch?
> > =3B (That way -- all your files are there and easily gotten/investigat= > >ed by others.)
> >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence.
> > =3B
> > =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= > >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= > >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= > >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= > >eed to know is that Debug.Out prints out debugging information
>=3B to= > > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= > >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= > >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= > >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= > >ieve I have also tried it both with and without compiler
>=3B optimiza= > >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > > can work if "AND" isn't
>=3B working right. This is the only if state= > >ment in many=2C many source files
>=3B that seems to be working wrong.= > >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= > >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= > >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= > >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B >R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= > >ka
>=3B
> >= > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jun 16 10:50:02 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 08:50:02 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: Well, the number 3 is REFANY_typecode. I need to compare the if code to the printing code though.. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... Date: Tue, 16 Jun 2009 08:44:21 +0000 Cool. Here is a smaller repro, on birch AMD64_LINUX. The problem is not the AND, the problem is the IF. MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = REF RECORD rest : REFANY; END; VAR t := NEW(Pair, rest := NEW(Pair, rest := NIL)); BEGIN PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); IF ISTYPE(t.rest,Pair) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Tony this is presumably your type tagging changes?? The problem in the code I think is the compare to the number 3. .L13: movq 312+MM_Main(%rip), %rax cmpq $3, %rax <==== jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT What is that for? It comes right from the IL: (118) set_source_line source line 17 (119) import_procedure procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd (120) declare_param param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 alignment 0x40 in _memory 0x0 up_level 0x0 mode 0x11 (DImode) (121) set_runtime_proc (122) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (123) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (124) load_nil (125) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (126) if_eq (127) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (128) loophole (129) load_integer integer 0x1 (130) and (131) if_true (132) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (133) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (134) extract_mn (135) if_false (136) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (137) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (138) pop_param pop param type 0xb (139) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (140) set_label (141) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (142) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (143) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (144) load_nil (145) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (146) if_eq (147) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (148) loophole (149) load_integer integer 0x1 (150) and (151) if_true (152) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (153) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (154) extract_mn (155) if_false (156) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (157) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (158) pop_param pop param type 0xb (159) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (160) set_label (161) load_integer integer 0x1 (162) declare_temp temp var type 0x7 size 0x40 alignment 0x40 (163) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (164) load_nil (165) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (166) if_eq (167) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (168) loophole (169) load_integer integer 0x1 (170) and (171) if_true (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq (177) jump (178) set_label (179) load_integer integer 0x3 (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq (182) set_label (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 alignment 0x8 in_mem ory 0x0 up_level 0x0 mode 0xe () (188) start_call_direct start call procedure Fmt__Bool, level 0x0, type 0xb (189) load m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 (190) pop_param pop param type 0x0 (191) call_direct call procedure Fmt__Bool, type 0xb (192) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (193) start_call_direct start call procedure RTHooks__Concat, level 0x0, type 0xb (194) load_address load address (L_1) offset 0x280 (195) pop_param pop param type 0xb (196) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (197) pop_param pop param type 0xb (198) call_direct call procedure RTHooks__Concat, type 0xb (199) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (200) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (201) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (202) pop_param pop param type 0xb (203) call_direct call procedure Main__PutLn, type 0xd (204) set_source_line source line 18 (205) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (206) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (207) load_nil (208) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (209) if_eq (210) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (211) loophole (212) load_integer integer 0x1 (213) and (214) if_true (215) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (216) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (217) extract_mn (218) if_false (219) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (220) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (221) pop_param pop param type 0xb (222) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (223) set_label (224) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (225) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (226) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (227) load_nil (228) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (229) if_eq (230) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (231) loophole (232) load_integer integer 0x1 (233) and (234) if_true (235) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (236) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (237) extract_mn (238) if_false (239) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (240) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (241) pop_param pop param type 0xb (242) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (243) set_label (244) load_nil (245) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (246) if_eq (247) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (248) loophole (249) load_integer integer 0x1 (250) and (251) if_true (252) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (253) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (254) extract_mn (255) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (256) if_ne (257) set_label (258) load_integer integer 0x3 <===== (259) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (260) if_ne (261) set_label (262) set_source_line source line 19 (263) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (264) load_address load address (L_1) offset 0x400 (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump (268) set_label (269) set_source_line source line 21 (270) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (271) load_address load address (L_1) offset 0x540 (272) pop_param pop param type 0xb (273) call_direct call procedure Main__PutLn, type 0xd (274) set_label (275) set_label (276) load_address load address (MM_Main) offset 0x0 (277) exit_proc (278) free_temp (279) free_temp (280) free_temp (281) free_temp (282) free_temp (283) end_procedure procedure Main_M3 (284) comment comment: `global constant type descriptor' (285) declare_record record id 0xffffffff, fields 0x0, size 0x940 (286) comment comment: `global data type descriptor' I'll dig a bit more. - Jay > To: jay.krell at cornell.edu > Date: Tue, 16 Jun 2009 00:59:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > This small example exhibits it! > > MODULE Main; > IMPORT IO, Fmt; > > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > > TYPE > Pair = BRANDED "Pair" REF RECORD > first, rest : REFANY; > END; > > PROCEDURE Rest(p : Pair) : REFANY = > BEGIN > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > END Rest; > > VAR > t := NEW(Pair, first := "first", > rest := NEW(Pair, first := "second", > rest := NIL)); > > BEGIN > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > PutLn("conjunction? " & Fmt.Bool( > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Output: > > (133)rover:~/testcm3/src>m3build -O > --- building in ../FreeBSD4 --- > m3build: missing ../src/m3overrides > new source -> compiling ../src/Main.m3 > -> linking prog > (134)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? TRUE > in IF clause... > (135)rover:~/testcm3/src>cm3 -clean > --- cleaning ../FreeBSD4 --- > > (136)rover:~/testcm3/src>cm3 > --- building in ../FreeBSD4 --- > > new source -> compiling Main.m3 > -> linking prog > (137)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > (138)rover:~/testcm3/src> > > Jay writes: > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Kneejerk generic response: > > > >=20 > > > >I don't know the operator precedence. Can you put in parens? > > > >Have you looked at the code? > > > >Can you mail us a small self contained repro? > > > >Can you test it on birch? > > > > (That way -- all your files are there and easily gotten/investigated by o= > >thers.) > > > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence. > > > >=20 > > > > - Jay > >=20 > >> To: m3devel at elegosoft.com > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... > >>=20 > >>=20 > >> Hello everyone=2C > >>=20 > >> I'm trying to update to the latest CM3 again=2C so that I can get my > >> Mac working=2C and push my project of migrating a largish codebase > >> from PM3 to CM3 a little further. > >>=20 > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C > >> and ... my Scheme interpreter broke. Here's what the code looks like=2C > >> with annotations: > >>=20 > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> 52 > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> 54 Debug.Out("in IF clause...")=3B > >> 55 > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" > >> 60 END > >> 61 ELSE > >> 62 Debug.Out("in ELSE clause...") > >> 63 END=3B > >>=20 > >> all you need to know is that Debug.Out prints out debugging information > >> to the terminal. What I see is... > >>=20 > >> t.rest =3D NIL? FALSE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> in ELSE clause... > >>=20 > >> What gives!? > >>=20 > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > compiler and runtime bootstrapped today from some previous CM3. > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the > >> code behaved properly under that one. > >>=20 > >> I believe I have also tried it both with and without compiler > >> optimizations. > >>=20 > >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't > >> working right. This is the only if statement in many=2C many source files > >> that seems to be working wrong. > >>=20 > >> Is it possible I'm missing something?? No I don't think so... here's a mo= > >re > >> explicit version: > >>=20 > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> Debug.Out("conjunction? " & Fmt.Bool( > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> ... > >>=20 > >> output is: > >>=20 > >> t.rest # NIL? TRUE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> conjunction? FALSE > >> in ELSE clause... > >>=20 > >> TRUE AND TRUE AND TRUE is FALSE?? > >>=20 > >> Note that:=20 > >>=20 > >> VAR q=2C w=2C e :=3D TRUE=3B > >>=20 > >> Debug.Out("conjunction? " & Fmt.Bool( > >> q AND w AND e))=3B > >>=20 > >> results in TRUE (as it should). > >>=20 > >>=20 > >> Mika > >>=20 > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Kneejerk generic response:
> > =3B
> >I don't know the operator precedence. Can you put in parens?
> >Have you looked at the code?
> >Can you mail us a small self contained repro?
> >Can you test it on birch?
> > =3B (That way -- all your files are there and easily gotten/investigat= > >ed by others.)
> >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence.
> > =3B
> > =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= > >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= > >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= > >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= > >eed to know is that Debug.Out prints out debugging information
>=3B to= > > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= > >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= > >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= > >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= > >ieve I have also tried it both with and without compiler
>=3B optimiza= > >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > > can work if "AND" isn't
>=3B working right. This is the only if state= > >ment in many=2C many source files
>=3B that seems to be working wrong.= > >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= > >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= > >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= > >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B >R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= > >ka
>=3B
> >= > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jun 16 11:16:39 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 09:16:39 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: I haven't figured it out, but: Here is the code for the Fmt.Bool: .L6: ; assume the parameter to Fmt.Bool is TRUE, by ; storing 1 in the parameter place movq $1, 16(%rsp) ; do a bunch of stuff, no need to understand.. movq 32(%rsp), %rax testq %rax, %rax je .L7 movq 32(%rsp), %rax testb $1, %al jne .L8 movq 32(%rsp), %rax movq 312+MM_Main(%rip), %rdx movq -8(%rax), %rax salq $43, %rax shrq $44, %rax ; at this point, between $rdx and $rax, one is ; typecode of the object, one is the typecode of the type ; they compare equal cmpq %rdx, %rax ; This is not taken. jne .L9 ; This is taken. jmp .L7 .L8: ; This does not run. movq 312+MM_Main(%rip), %rax cmpq $3, %rax je .L7 .L9: ; Had the expression resolved to FALSE, this would be ; where FALSE is passed to Fmt.Bool movq $0, 16(%rsp) .L7: movq 16(%rsp), %rdi call Fmt__Bool at PLT And here is the code for the IF: .L11: ; just gloss over this part.. movq 40(%rsp), %rax testq %rax, %rax je .L12 movq 40(%rsp), %rax testb $1, %al jne .L13 movq 40(%rsp), %rax movq 312+MM_Main(%rip), %rdx movq -8(%rax), %rax salq $43, %rax shrq $44, %rax ; again at this point, we have the typecodes, and they compare equal cmpq %rdx, %rax ; This is not taken. jne .L14 .L13: ; At this point things have gone wrong. ; The Fmt.Bool path did not compare the typecode to 3. ; after the jne, there should have been a jmp to I guess .L12. movq 312+MM_Main(%rip), %rax cmpq $3, %rax jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT Thanks for the small test case! - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Tue, 16 Jun 2009 08:50:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... Well, the number 3 is REFANY_typecode. I need to compare the if code to the printing code though.. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... Date: Tue, 16 Jun 2009 08:44:21 +0000 Cool. Here is a smaller repro, on birch AMD64_LINUX. The problem is not the AND, the problem is the IF. MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = REF RECORD rest : REFANY; END; VAR t := NEW(Pair, rest := NEW(Pair, rest := NIL)); BEGIN PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); IF ISTYPE(t.rest,Pair) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Tony this is presumably your type tagging changes?? The problem in the code I think is the compare to the number 3. .L13: movq 312+MM_Main(%rip), %rax cmpq $3, %rax <==== jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT What is that for? It comes right from the IL: (118) set_source_line source line 17 (119) import_procedure procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd (120) declare_param param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 alignment 0x40 in _memory 0x0 up_level 0x0 mode 0x11 (DImode) (121) set_runtime_proc (122) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (123) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (124) load_nil (125) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (126) if_eq (127) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (128) loophole (129) load_integer integer 0x1 (130) and (131) if_true (132) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (133) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (134) extract_mn (135) if_false (136) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (137) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (138) pop_param pop param type 0xb (139) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (140) set_label (141) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (142) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (143) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (144) load_nil (145) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (146) if_eq (147) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (148) loophole (149) load_integer integer 0x1 (150) and (151) if_true (152) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (153) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (154) extract_mn (155) if_false (156) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (157) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (158) pop_param pop param type 0xb (159) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (160) set_label (161) load_integer integer 0x1 (162) declare_temp temp var type 0x7 size 0x40 alignment 0x40 (163) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (164) load_nil (165) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (166) if_eq (167) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (168) loophole (169) load_integer integer 0x1 (170) and (171) if_true (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq (177) jump (178) set_label (179) load_integer integer 0x3 (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq (182) set_label (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 alignment 0x8 in_mem ory 0x0 up_level 0x0 mode 0xe () (188) start_call_direct start call procedure Fmt__Bool, level 0x0, type 0xb (189) load m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 (190) pop_param pop param type 0x0 (191) call_direct call procedure Fmt__Bool, type 0xb (192) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (193) start_call_direct start call procedure RTHooks__Concat, level 0x0, type 0xb (194) load_address load address (L_1) offset 0x280 (195) pop_param pop param type 0xb (196) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (197) pop_param pop param type 0xb (198) call_direct call procedure RTHooks__Concat, type 0xb (199) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (200) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (201) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (202) pop_param pop param type 0xb (203) call_direct call procedure Main__PutLn, type 0xd (204) set_source_line source line 18 (205) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (206) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (207) load_nil (208) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (209) if_eq (210) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (211) loophole (212) load_integer integer 0x1 (213) and (214) if_true (215) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (216) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (217) extract_mn (218) if_false (219) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (220) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (221) pop_param pop param type 0xb (222) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (223) set_label (224) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (225) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (226) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (227) load_nil (228) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (229) if_eq (230) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (231) loophole (232) load_integer integer 0x1 (233) and (234) if_true (235) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (236) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (237) extract_mn (238) if_false (239) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (240) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (241) pop_param pop param type 0xb (242) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (243) set_label (244) load_nil (245) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (246) if_eq (247) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (248) loophole (249) load_integer integer 0x1 (250) and (251) if_true (252) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (253) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (254) extract_mn (255) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (256) if_ne (257) set_label (258) load_integer integer 0x3 <===== (259) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (260) if_ne (261) set_label (262) set_source_line source line 19 (263) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (264) load_address load address (L_1) offset 0x400 (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump (268) set_label (269) set_source_line source line 21 (270) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (271) load_address load address (L_1) offset 0x540 (272) pop_param pop param type 0xb (273) call_direct call procedure Main__PutLn, type 0xd (274) set_label (275) set_label (276) load_address load address (MM_Main) offset 0x0 (277) exit_proc (278) free_temp (279) free_temp (280) free_temp (281) free_temp (282) free_temp (283) end_procedure procedure Main_M3 (284) comment comment: `global constant type descriptor' (285) declare_record record id 0xffffffff, fields 0x0, size 0x940 (286) comment comment: `global data type descriptor' I'll dig a bit more. - Jay > To: jay.krell at cornell.edu > Date: Tue, 16 Jun 2009 00:59:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > This small example exhibits it! > > MODULE Main; > IMPORT IO, Fmt; > > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > > TYPE > Pair = BRANDED "Pair" REF RECORD > first, rest : REFANY; > END; > > PROCEDURE Rest(p : Pair) : REFANY = > BEGIN > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > END Rest; > > VAR > t := NEW(Pair, first := "first", > rest := NEW(Pair, first := "second", > rest := NIL)); > > BEGIN > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > PutLn("conjunction? " & Fmt.Bool( > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Output: > > (133)rover:~/testcm3/src>m3build -O > --- building in ../FreeBSD4 --- > m3build: missing ../src/m3overrides > new source -> compiling ../src/Main.m3 > -> linking prog > (134)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? TRUE > in IF clause... > (135)rover:~/testcm3/src>cm3 -clean > --- cleaning ../FreeBSD4 --- > > (136)rover:~/testcm3/src>cm3 > --- building in ../FreeBSD4 --- > > new source -> compiling Main.m3 > -> linking prog > (137)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > (138)rover:~/testcm3/src> > > Jay writes: > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Kneejerk generic response: > > > >=20 > > > >I don't know the operator precedence. Can you put in parens? > > > >Have you looked at the code? > > > >Can you mail us a small self contained repro? > > > >Can you test it on birch? > > > > (That way -- all your files are there and easily gotten/investigated by o= > >thers.) > > > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence. > > > >=20 > > > > - Jay > >=20 > >> To: m3devel at elegosoft.com > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... > >>=20 > >>=20 > >> Hello everyone=2C > >>=20 > >> I'm trying to update to the latest CM3 again=2C so that I can get my > >> Mac working=2C and push my project of migrating a largish codebase > >> from PM3 to CM3 a little further. > >>=20 > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C > >> and ... my Scheme interpreter broke. Here's what the code looks like=2C > >> with annotations: > >>=20 > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> 52 > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> 54 Debug.Out("in IF clause...")=3B > >> 55 > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" > >> 60 END > >> 61 ELSE > >> 62 Debug.Out("in ELSE clause...") > >> 63 END=3B > >>=20 > >> all you need to know is that Debug.Out prints out debugging information > >> to the terminal. What I see is... > >>=20 > >> t.rest =3D NIL? FALSE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> in ELSE clause... > >>=20 > >> What gives!? > >>=20 > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > compiler and runtime bootstrapped today from some previous CM3. > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the > >> code behaved properly under that one. > >>=20 > >> I believe I have also tried it both with and without compiler > >> optimizations. > >>=20 > >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't > >> working right. This is the only if statement in many=2C many source files > >> that seems to be working wrong. > >>=20 > >> Is it possible I'm missing something?? No I don't think so... here's a mo= > >re > >> explicit version: > >>=20 > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> Debug.Out("conjunction? " & Fmt.Bool( > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> ... > >>=20 > >> output is: > >>=20 > >> t.rest # NIL? TRUE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> conjunction? FALSE > >> in ELSE clause... > >>=20 > >> TRUE AND TRUE AND TRUE is FALSE?? > >>=20 > >> Note that:=20 > >>=20 > >> VAR q=2C w=2C e :=3D TRUE=3B > >>=20 > >> Debug.Out("conjunction? " & Fmt.Bool( > >> q AND w AND e))=3B > >>=20 > >> results in TRUE (as it should). > >>=20 > >>=20 > >> Mika > >>=20 > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Kneejerk generic response:
> > =3B
> >I don't know the operator precedence. Can you put in parens?
> >Have you looked at the code?
> >Can you mail us a small self contained repro?
> >Can you test it on birch?
> > =3B (That way -- all your files are there and easily gotten/investigat= > >ed by others.)
> >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence.
> > =3B
> > =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= > >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= > >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= > >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= > >eed to know is that Debug.Out prints out debugging information
>=3B to= > > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= > >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= > >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= > >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= > >ieve I have also tried it both with and without compiler
>=3B optimiza= > >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > > can work if "AND" isn't
>=3B working right. This is the only if state= > >ment in many=2C many source files
>=3B that seems to be working wrong.= > >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= > >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= > >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= > >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B >R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= > >ka
>=3B
> >= > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jun 16 11:59:14 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 09:59:14 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: Here is the code in the compiler, not being familiar..it seems reasonable.. ELSIF RefType.Is (t) THEN Expr.Compile (ce.args[0]); tagged := CG.Next_label (); false := CG.Next_label (); true := CG.Next_label (); ptr := CG.Pop (); Value.Load (Bool.True); CG.Force (); (* we need a temp *) ce.tmp := CG.Pop_temp (); CG.Push (ptr); CG.Load_nil (); CG.If_compare (CG.Type.Addr, CG.Cmp.EQ, true, CG.Maybe); CG.Push (ptr); CG.Loophole (CG.Type.Addr, Target.Integer.cg_type); CG.Load_integer (Target.Integer.cg_type, TInt.One); CG.And (Target.Integer.cg_type); CG.If_true (tagged, CG.Maybe); CG.Push (ptr); CG.Ref_to_info (M3RT.RH_typecode_offset, M3RT.RH_typecode_size); Type.LoadInfo (t, M3RT.TC_typecode); ; This is the comparison of the desired and actual typecode ; If it equal, we will jump to the label "true" CG.If_compare (Target.Integer.cg_type, CG.Cmp.EQ, true, CG.Always); ; otherwise, we already decided it isn't tagged, so jump ; around that to the label false ; ; This is what is missing in the IL. ; CG.Jump (false); CG.Set_label (tagged); CG.Load_intt (M3RT.REFANY_typecode); Type.LoadInfo (t, M3RT.TC_typecode); CG.If_compare (Target.Integer.cg_type, CG.Cmp.EQ, true, CG.Always); CG.Set_label (false); Value.Load (Bool.False); CG.Store_temp (ce.tmp); CG.Set_label (true); CG.Free (ptr); Let's look for jumps in the IL, there are only two: (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq label 6 (177) jump <== here label 5 (178) set_label label 4 (179) load_integer integer 0x3 <== notice this (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq label 6 (182) set_label label 5 (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label label 6 (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param That is the call to Fmt_Bool. You can see the signature value "3", that the jump goes around. and the other one: (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump label 7 not interesting -- you can't tell here, but it is after all the interesting stuff. It is for the if to skip the else. So that leaves me wondering -- what happened to the jump in the IsType? I think it should be there and it missing messes this up. We don't expect to take that jump, we expect the comparison to be equal, but I think the code gets it reversed and makes corresponding changes so this missing jump is the problem... - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... Date: Tue, 16 Jun 2009 09:16:39 +0000 I haven't figured it out, but: Here is the code for the Fmt.Bool: .L6: ; assume the parameter to Fmt.Bool is TRUE, by ; storing 1 in the parameter place movq $1, 16(%rsp) ; do a bunch of stuff, no need to understand.. movq 32(%rsp), %rax testq %rax, %rax je .L7 movq 32(%rsp), %rax testb $1, %al jne .L8 movq 32(%rsp), %rax movq 312+MM_Main(%rip), %rdx movq -8(%rax), %rax salq $43, %rax shrq $44, %rax ; at this point, between $rdx and $rax, one is ; typecode of the object, one is the typecode of the type ; they compare equal cmpq %rdx, %rax ; This is not taken. jne .L9 ; This is taken. jmp .L7 .L8: ; This does not run. movq 312+MM_Main(%rip), %rax cmpq $3, %rax je .L7 .L9: ; Had the expression resolved to FALSE, this would be ; where FALSE is passed to Fmt.Bool movq $0, 16(%rsp) .L7: movq 16(%rsp), %rdi call Fmt__Bool at PLT And here is the code for the IF: .L11: ; just gloss over this part.. movq 40(%rsp), %rax testq %rax, %rax je .L12 movq 40(%rsp), %rax testb $1, %al jne .L13 movq 40(%rsp), %rax movq 312+MM_Main(%rip), %rdx movq -8(%rax), %rax salq $43, %rax shrq $44, %rax ; again at this point, we have the typecodes, and they compare equal cmpq %rdx, %rax ; This is not taken. jne .L14 .L13: ; At this point things have gone wrong. ; The Fmt.Bool path did not compare the typecode to 3. ; after the jne, there should have been a jmp to I guess .L12. movq 312+MM_Main(%rip), %rax cmpq $3, %rax jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT Thanks for the small test case! - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Tue, 16 Jun 2009 08:50:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... Well, the number 3 is REFANY_typecode. I need to compare the if code to the printing code though.. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... Date: Tue, 16 Jun 2009 08:44:21 +0000 Cool. Here is a smaller repro, on birch AMD64_LINUX. The problem is not the AND, the problem is the IF. MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = REF RECORD rest : REFANY; END; VAR t := NEW(Pair, rest := NEW(Pair, rest := NIL)); BEGIN PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); IF ISTYPE(t.rest,Pair) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Tony this is presumably your type tagging changes?? The problem in the code I think is the compare to the number 3. .L13: movq 312+MM_Main(%rip), %rax cmpq $3, %rax <==== jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT What is that for? It comes right from the IL: (118) set_source_line source line 17 (119) import_procedure procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd (120) declare_param param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 alignment 0x40 in _memory 0x0 up_level 0x0 mode 0x11 (DImode) (121) set_runtime_proc (122) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (123) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (124) load_nil (125) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (126) if_eq (127) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (128) loophole (129) load_integer integer 0x1 (130) and (131) if_true (132) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (133) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (134) extract_mn (135) if_false (136) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (137) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (138) pop_param pop param type 0xb (139) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (140) set_label (141) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (142) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (143) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (144) load_nil (145) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (146) if_eq (147) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (148) loophole (149) load_integer integer 0x1 (150) and (151) if_true (152) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (153) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (154) extract_mn (155) if_false (156) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (157) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (158) pop_param pop param type 0xb (159) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (160) set_label (161) load_integer integer 0x1 (162) declare_temp temp var type 0x7 size 0x40 alignment 0x40 (163) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (164) load_nil (165) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (166) if_eq (167) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (168) loophole (169) load_integer integer 0x1 (170) and (171) if_true (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq (177) jump (178) set_label (179) load_integer integer 0x3 (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq (182) set_label (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 alignment 0x8 in_mem ory 0x0 up_level 0x0 mode 0xe () (188) start_call_direct start call procedure Fmt__Bool, level 0x0, type 0xb (189) load m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 (190) pop_param pop param type 0x0 (191) call_direct call procedure Fmt__Bool, type 0xb (192) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (193) start_call_direct start call procedure RTHooks__Concat, level 0x0, type 0xb (194) load_address load address (L_1) offset 0x280 (195) pop_param pop param type 0xb (196) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (197) pop_param pop param type 0xb (198) call_direct call procedure RTHooks__Concat, type 0xb (199) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (200) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (201) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (202) pop_param pop param type 0xb (203) call_direct call procedure Main__PutLn, type 0xd (204) set_source_line source line 18 (205) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (206) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (207) load_nil (208) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (209) if_eq (210) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (211) loophole (212) load_integer integer 0x1 (213) and (214) if_true (215) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (216) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (217) extract_mn (218) if_false (219) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (220) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (221) pop_param pop param type 0xb (222) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (223) set_label (224) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (225) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (226) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (227) load_nil (228) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (229) if_eq (230) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (231) loophole (232) load_integer integer 0x1 (233) and (234) if_true (235) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (236) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (237) extract_mn (238) if_false (239) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (240) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (241) pop_param pop param type 0xb (242) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (243) set_label (244) load_nil (245) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (246) if_eq (247) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (248) loophole (249) load_integer integer 0x1 (250) and (251) if_true (252) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (253) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (254) extract_mn (255) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (256) if_ne (257) set_label (258) load_integer integer 0x3 <===== (259) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (260) if_ne (261) set_label (262) set_source_line source line 19 (263) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (264) load_address load address (L_1) offset 0x400 (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump (268) set_label (269) set_source_line source line 21 (270) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (271) load_address load address (L_1) offset 0x540 (272) pop_param pop param type 0xb (273) call_direct call procedure Main__PutLn, type 0xd (274) set_label (275) set_label (276) load_address load address (MM_Main) offset 0x0 (277) exit_proc (278) free_temp (279) free_temp (280) free_temp (281) free_temp (282) free_temp (283) end_procedure procedure Main_M3 (284) comment comment: `global constant type descriptor' (285) declare_record record id 0xffffffff, fields 0x0, size 0x940 (286) comment comment: `global data type descriptor' I'll dig a bit more. - Jay > To: jay.krell at cornell.edu > Date: Tue, 16 Jun 2009 00:59:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > This small example exhibits it! > > MODULE Main; > IMPORT IO, Fmt; > > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > > TYPE > Pair = BRANDED "Pair" REF RECORD > first, rest : REFANY; > END; > > PROCEDURE Rest(p : Pair) : REFANY = > BEGIN > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > END Rest; > > VAR > t := NEW(Pair, first := "first", > rest := NEW(Pair, first := "second", > rest := NIL)); > > BEGIN > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > PutLn("conjunction? " & Fmt.Bool( > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Output: > > (133)rover:~/testcm3/src>m3build -O > --- building in ../FreeBSD4 --- > m3build: missing ../src/m3overrides > new source -> compiling ../src/Main.m3 > -> linking prog > (134)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? TRUE > in IF clause... > (135)rover:~/testcm3/src>cm3 -clean > --- cleaning ../FreeBSD4 --- > > (136)rover:~/testcm3/src>cm3 > --- building in ../FreeBSD4 --- > > new source -> compiling Main.m3 > -> linking prog > (137)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > (138)rover:~/testcm3/src> > > Jay writes: > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Kneejerk generic response: > > > >=20 > > > >I don't know the operator precedence. Can you put in parens? > > > >Have you looked at the code? > > > >Can you mail us a small self contained repro? > > > >Can you test it on birch? > > > > (That way -- all your files are there and easily gotten/investigated by o= > >thers.) > > > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence. > > > >=20 > > > > - Jay > >=20 > >> To: m3devel at elegosoft.com > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... > >>=20 > >>=20 > >> Hello everyone=2C > >>=20 > >> I'm trying to update to the latest CM3 again=2C so that I can get my > >> Mac working=2C and push my project of migrating a largish codebase > >> from PM3 to CM3 a little further. > >>=20 > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C > >> and ... my Scheme interpreter broke. Here's what the code looks like=2C > >> with annotations: > >>=20 > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> 52 > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> 54 Debug.Out("in IF clause...")=3B > >> 55 > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" > >> 60 END > >> 61 ELSE > >> 62 Debug.Out("in ELSE clause...") > >> 63 END=3B > >>=20 > >> all you need to know is that Debug.Out prints out debugging information > >> to the terminal. What I see is... > >>=20 > >> t.rest =3D NIL? FALSE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> in ELSE clause... > >>=20 > >> What gives!? > >>=20 > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > compiler and runtime bootstrapped today from some previous CM3. > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the > >> code behaved properly under that one. > >>=20 > >> I believe I have also tried it both with and without compiler > >> optimizations. > >>=20 > >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't > >> working right. This is the only if statement in many=2C many source files > >> that seems to be working wrong. > >>=20 > >> Is it possible I'm missing something?? No I don't think so... here's a mo= > >re > >> explicit version: > >>=20 > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> Debug.Out("conjunction? " & Fmt.Bool( > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> ... > >>=20 > >> output is: > >>=20 > >> t.rest # NIL? TRUE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> conjunction? FALSE > >> in ELSE clause... > >>=20 > >> TRUE AND TRUE AND TRUE is FALSE?? > >>=20 > >> Note that:=20 > >>=20 > >> VAR q=2C w=2C e :=3D TRUE=3B > >>=20 > >> Debug.Out("conjunction? " & Fmt.Bool( > >> q AND w AND e))=3B > >>=20 > >> results in TRUE (as it should). > >>=20 > >>=20 > >> Mika > >>=20 > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Kneejerk generic response:
> > =3B
> >I don't know the operator precedence. Can you put in parens?
> >Have you looked at the code?
> >Can you mail us a small self contained repro?
> >Can you test it on birch?
> > =3B (That way -- all your files are there and easily gotten/investigat= > >ed by others.)
> >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence.
> > =3B
> > =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= > >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= > >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= > >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= > >eed to know is that Debug.Out prints out debugging information
>=3B to= > > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= > >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= > >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= > >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= > >ieve I have also tried it both with and without compiler
>=3B optimiza= > >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > > can work if "AND" isn't
>=3B working right. This is the only if state= > >ment in many=2C many source files
>=3B that seems to be working wrong.= > >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= > >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= > >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= > >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B >R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= > >ka
>=3B
> >= > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jun 16 17:35:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 16 Jun 2009 11:35:29 -0400 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: I think I see the problem in the compiler. There is some strangeness in how true=CG.No_label is dealt with. On 16 Jun 2009, at 05:59, Jay wrote: > Here is the code in the compiler, not being familiar..it seems > reasonable.. > > > ELSIF RefType.Is (t) THEN > Expr.Compile (ce.args[0]); > tagged := CG.Next_label (); > false := CG.Next_label (); > true := CG.Next_label (); > ptr := CG.Pop (); > Value.Load (Bool.True); > CG.Force (); (* we need a temp *) > ce.tmp := CG.Pop_temp (); > CG.Push (ptr); > CG.Load_nil (); > CG.If_compare (CG.Type.Addr, CG.Cmp.EQ, true, CG.Maybe); > CG.Push (ptr); > CG.Loophole (CG.Type.Addr, Target.Integer.cg_type); > CG.Load_integer (Target.Integer.cg_type, TInt.One); > CG.And (Target.Integer.cg_type); > CG.If_true (tagged, CG.Maybe); > CG.Push (ptr); > CG.Ref_to_info (M3RT.RH_typecode_offset, M3RT.RH_typecode_size); > Type.LoadInfo (t, M3RT.TC_typecode); > > ; This is the comparison of the desired and actual typecode > ; If it equal, we will jump to the label "true" > CG.If_compare (Target.Integer.cg_type, CG.Cmp.EQ, true, > CG.Always); > > ; otherwise, we already decided it isn't tagged, so jump > ; around that to the label false > ; > ; This is what is missing in the IL. > ; > CG.Jump (false); > > CG.Set_label (tagged); > CG.Load_intt (M3RT.REFANY_typecode); > Type.LoadInfo (t, M3RT.TC_typecode); > CG.If_compare (Target.Integer.cg_type, CG.Cmp.EQ, true, > CG.Always); > CG.Set_label (false); > Value.Load (Bool.False); > CG.Store_temp (ce.tmp); > CG.Set_label (true); > CG.Free (ptr); > > > > Let's look for jumps in the IL, there are only two: > > (172) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (173) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (174) extract_mn > (175) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (176) if_eq > label 6 > (177) jump <== here > label 5 > (178) set_label > label 4 > (179) load_integer > integer 0x3 <== notice this > (180) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (181) if_eq > label 6 > (182) set_label > label 5 > (183) load_integer > integer 0x0 > (184) store > store (noname) offset 0x0 src_t 0x7 dst_t 0x7 > (185) set_label > label 6 > (186) import_procedure > procedure Fmt__Bool nparams 0x1 rettype 0xb > (187) declare_param > > > That is the call to Fmt_Bool. > You can see the signature value "3", that the jump goes around. > > and the other one: > > (265) pop_param > pop param type 0xb > (266) call_direct > call procedure Main__PutLn, type 0xd > (267) jump > label 7 > > not interesting -- you can't tell here, but it is after all the > interesting stuff. > It is for the if to skip the else. > > So that leaves me wondering -- what happened to the jump in the > IsType? > I think it should be there and it missing messes this up. > We don't expect to take that jump, we expect the comparison to be > equal, but I think the code gets it reversed and makes corresponding > changes so this missing jump is the problem... > > > - Jay > > > > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... > Date: Tue, 16 Jun 2009 09:16:39 +0000 > > I haven't figured it out, but: > > Here is the code for the Fmt.Bool: > > .L6: > ; assume the parameter to Fmt.Bool is TRUE, by > ; storing 1 in the parameter place > > movq $1, 16(%rsp) > > ; do a bunch of stuff, no need to understand.. > > movq 32(%rsp), %rax > testq %rax, %rax > je .L7 > movq 32(%rsp), %rax > testb $1, %al > jne .L8 > movq 32(%rsp), %rax > movq 312+MM_Main(%rip), %rdx > movq -8(%rax), %rax > salq $43, %rax > shrq $44, %rax > > ; at this point, between $rdx and $rax, one is > ; typecode of the object, one is the typecode of the type > ; they compare equal > > cmpq %rdx, %rax > > ; This is not taken. > > jne .L9 > > ; This is taken. > > jmp .L7 > > .L8: > ; This does not run. > movq 312+MM_Main(%rip), %rax > cmpq $3, %rax > je .L7 > .L9: > ; Had the expression resolved to FALSE, this would be > ; where FALSE is passed to Fmt.Bool > movq $0, 16(%rsp) > .L7: > movq 16(%rsp), %rdi > call Fmt__Bool at PLT > > > And here is the code for the IF: > > .L11: > ; just gloss over this part.. > > movq 40(%rsp), %rax > testq %rax, %rax > je .L12 > movq 40(%rsp), %rax > testb $1, %al > jne .L13 > movq 40(%rsp), %rax > movq 312+MM_Main(%rip), %rdx > movq -8(%rax), %rax > salq $43, %rax > shrq $44, %rax > > ; again at this point, we have the typecodes, and they compare equal > > cmpq %rdx, %rax > > ; This is not taken. > > jne .L14 > > .L13: > > ; At this point things have gone wrong. > ; The Fmt.Bool path did not compare the typecode to 3. > ; after the jne, there should have been a jmp to I guess .L12. > > movq 312+MM_Main(%rip), %rax > cmpq $3, %rax > jne .L14 > > .L12: > .stabn 68,0,19,.LM9-.LFBB2 > .LM9: > leaq 128+L_1(%rip), %rdi > call Main__PutLn at PLT > jmp .L15 > .p2align 4,,10 > .p2align 3 > .L14: > .stabn 68,0,21,.LM10-.LFBB2 > .LM10: > leaq 168+L_1(%rip), %rdi > call Main__PutLn at PLT > > > Thanks for the small test case! > > - Jay > > > > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > Date: Tue, 16 Jun 2009 08:50:02 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > Well, the number 3 is REFANY_typecode. > I need to compare the if code to the printing code though.. > > - Jay > > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... > Date: Tue, 16 Jun 2009 08:44:21 +0000 > > Cool. > Here is a smaller repro, on birch AMD64_LINUX. > > The problem is not the AND, the problem is the IF. > > > MODULE Main; > IMPORT IO, Fmt; > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > TYPE > Pair = REF RECORD > rest : REFANY; > END; > VAR > t := NEW(Pair, rest := NEW(Pair, rest := NIL)); > BEGIN > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > IF ISTYPE(t.rest,Pair) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Tony this is presumably your type tagging changes?? > > The problem in the code I think is the compare to the number 3. > > .L13: > movq 312+MM_Main(%rip), %rax > cmpq $3, %rax <==== > jne .L14 > .L12: > .stabn 68,0,19,.LM9-.LFBB2 > .LM9: > leaq 128+L_1(%rip), %rdi > call Main__PutLn at PLT > jmp .L15 > .p2align 4,,10 > .p2align 3 > .L14: > .stabn 68,0,21,.LM10-.LFBB2 > .LM10: > leaq 168+L_1(%rip), %rdi > call Main__PutLn at PLT > > > What is that for? > > > It comes right from the IL: > > (118) set_source_line > source line 17 > (119) import_procedure > procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd > (120) declare_param > param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 > alignment 0x40 in > _memory 0x0 up_level 0x0 > mode 0x11 (DImode) > (121) set_runtime_proc > (122) load > m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb > (123) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (124) load_nil > (125) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (126) if_eq > (127) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (128) loophole > (129) load_integer > integer 0x1 > (130) and > (131) if_true > (132) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (133) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (134) extract_mn > (135) if_false > (136) start_call_direct > start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type > 0xd > (137) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (138) pop_param > pop param type 0xb > (139) call_direct > call procedure RTHooks__CheckLoadTracedRef, type 0xd > (140) set_label > (141) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (142) load_indirect > load address offset 0x0 src_t 0xb dst_t 0xb > (143) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (144) load_nil > (145) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (146) if_eq > (147) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (148) loophole > (149) load_integer > integer 0x1 > (150) and > (151) if_true > (152) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (153) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (154) extract_mn > (155) if_false > (156) start_call_direct > start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type > 0xd > (157) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (158) pop_param > pop param type 0xb > (159) call_direct > call procedure RTHooks__CheckLoadTracedRef, type 0xd > (160) set_label > (161) load_integer > integer 0x1 > (162) declare_temp > temp var type 0x7 size 0x40 alignment 0x40 > (163) store > store (noname) offset 0x0 src_t 0x7 dst_t 0x7 > (164) load_nil > (165) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (166) if_eq > (167) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (168) loophole > (169) load_integer > integer 0x1 > (170) and > (171) if_true > (172) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (173) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (174) extract_mn > (175) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (176) if_eq > (177) jump > (178) set_label > (179) load_integer > integer 0x3 > (180) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (181) if_eq > (182) set_label > (183) load_integer > integer 0x0 > (184) store > store (noname) offset 0x0 src_t 0x7 dst_t 0x7 > (185) set_label > (186) import_procedure > procedure Fmt__Bool nparams 0x1 rettype 0xb > (187) declare_param > param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 > alignment 0x8 in_mem > ory 0x0 up_level 0x0 > mode 0xe () > (188) start_call_direct > start call procedure Fmt__Bool, level 0x0, type 0xb > (189) load > m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 > (190) pop_param > pop param type 0x0 > (191) call_direct > call procedure Fmt__Bool, type 0xb > (192) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (193) start_call_direct > start call procedure RTHooks__Concat, level 0x0, type 0xb > (194) load_address > load address (L_1) offset 0x280 > (195) pop_param > pop param type 0xb > (196) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (197) pop_param > pop param type 0xb > (198) call_direct > call procedure RTHooks__Concat, type 0xb > (199) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (200) start_call_direct > start call procedure Main__PutLn, level 0x0, type 0xd > (201) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (202) pop_param > pop param type 0xb > (203) call_direct > call procedure Main__PutLn, type 0xd > (204) set_source_line > source line 18 > (205) load > m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb > (206) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (207) load_nil > (208) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (209) if_eq > (210) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (211) loophole > (212) load_integer > integer 0x1 > (213) and > (214) if_true > (215) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (216) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (217) extract_mn > (218) if_false > (219) start_call_direct > start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type > 0xd > (220) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (221) pop_param > pop param type 0xb > (222) call_direct > call procedure RTHooks__CheckLoadTracedRef, type 0xd > (223) set_label > (224) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (225) load_indirect > load address offset 0x0 src_t 0xb dst_t 0xb > (226) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (227) load_nil > (228) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (229) if_eq > (230) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (231) loophole > (232) load_integer > integer 0x1 > (233) and > (234) if_true > (235) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (236) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (237) extract_mn > (238) if_false > (239) start_call_direct > start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type > 0xd > (240) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (241) pop_param > pop param type 0xb > (242) call_direct > call procedure RTHooks__CheckLoadTracedRef, type 0xd > (243) set_label > (244) load_nil > (245) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (246) if_eq > (247) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (248) loophole > (249) load_integer > integer 0x1 > (250) and > (251) if_true > (252) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (253) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (254) extract_mn > (255) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (256) if_ne > (257) set_label > (258) load_integer > integer 0x3 <===== > (259) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (260) if_ne > (261) set_label > (262) set_source_line > source line 19 > (263) start_call_direct > start call procedure Main__PutLn, level 0x0, type 0xd > (264) load_address > load address (L_1) offset 0x400 > (265) pop_param > pop param type 0xb > (266) call_direct > call procedure Main__PutLn, type 0xd > (267) jump > (268) set_label > (269) set_source_line > source line 21 > (270) start_call_direct > start call procedure Main__PutLn, level 0x0, type 0xd > (271) load_address > load address (L_1) offset 0x540 > (272) pop_param > pop param type 0xb > (273) call_direct > call procedure Main__PutLn, type 0xd > (274) set_label > (275) set_label > (276) load_address > load address (MM_Main) offset 0x0 > (277) exit_proc > (278) free_temp > (279) free_temp > (280) free_temp > (281) free_temp > (282) free_temp > (283) end_procedure > procedure Main_M3 > (284) comment > comment: `global constant type descriptor' > (285) declare_record > record id 0xffffffff, fields 0x0, size 0x940 > (286) comment > comment: `global data type descriptor' > > > I'll dig a bit more. > > > - Jay > > > > > > > > > To: jay.krell at cornell.edu > > Date: Tue, 16 Jun 2009 00:59:10 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled > code... > > > > This small example exhibits it! > > > > MODULE Main; > > IMPORT IO, Fmt; > > > > PROCEDURE PutLn(what : TEXT) = > > BEGIN IO.Put(what & "\n") END PutLn; > > > > > > TYPE > > Pair = BRANDED "Pair" REF RECORD > > first, rest : REFANY; > > END; > > > > PROCEDURE Rest(p : Pair) : REFANY = > > BEGIN > > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > > END Rest; > > > > VAR > > t := NEW(Pair, first := "first", > > rest := NEW(Pair, first := "second", > > rest := NIL)); > > > > BEGIN > > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > > PutLn("conjunction? " & Fmt.Bool( > > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = > NIL) )); > > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = > NIL) THEN > > PutLn("in IF clause...") > > ELSE > > PutLn("in ELSE clause...") > > END > > END Main. > > > > Output: > > > > (133)rover:~/testcm3/src>m3build -O > > --- building in ../FreeBSD4 --- > > m3build: missing ../src/m3overrides > > new source -> compiling ../src/Main.m3 > > -> linking prog > > (134)rover:~/testcm3/src>../FreeBSD4/prog > > t.rest # NIL? TRUE > > ISTYPE(t.rest,Pair)? TRUE > > Rest(t.rest) = NIL? TRUE > > conjunction? TRUE > > in IF clause... > > (135)rover:~/testcm3/src>cm3 -clean > > --- cleaning ../FreeBSD4 --- > > > > (136)rover:~/testcm3/src>cm3 > > --- building in ../FreeBSD4 --- > > > > new source -> compiling Main.m3 > > -> linking prog > > (137)rover:~/testcm3/src>../FreeBSD4/prog > > t.rest # NIL? TRUE > > ISTYPE(t.rest,Pair)? TRUE > > Rest(t.rest) = NIL? TRUE > > conjunction? FALSE > > in ELSE clause... > > (138)rover:~/testcm3/src> > > > > Jay writes: > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > > >Content-Type: text/plain; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > > > > >Kneejerk generic response: > > > > > >=20 > > > > > >I don't know the operator precedence. Can you put in parens? > > > > > >Have you looked at the code? > > > > > >Can you mail us a small self contained repro? > > > > > >Can you test it on birch? > > > > > > (That way -- all your files are there and easily gotten/ > investigated by o= > > >thers.) > > > > > >Optimization enabled? Works without? I know=2C I shouldn't even > ask this so= > > >rt of thing without evidence. > > > > > >=20 > > > > > > - Jay > > >=20 > > >> To: m3devel at elegosoft.com > > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > > >> From: mika at async.caltech.edu > > >> CC: mika at camembert.async.caltech.edu > > >> Subject: [M3devel] Strange behavior in recent CM3-compiled > code... > > >>=20 > > >>=20 > > >> Hello everyone=2C > > >>=20 > > >> I'm trying to update to the latest CM3 again=2C so that I can > get my > > >> Mac working=2C and push my project of migrating a largish > codebase > > >> from PM3 to CM3 a little further. > > >>=20 > > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD > system=2C > > >> and ... my Scheme interpreter broke. Here's what the code looks > like=2C > > >> with annotations: > > >>=20 > > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & > Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & > Fmt.Bool(Rest(t.rest)=3DNIL))=3B > > >> 52 > > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D > NIL THEN > > >> 54 Debug.Out("in IF clause...")=3B > > >> 55 > > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D > "=2C@" > > >> 60 END > > >> 61 ELSE > > >> 62 Debug.Out("in ELSE clause...") > > >> 63 END=3B > > >>=20 > > >> all you need to know is that Debug.Out prints out debugging > information > > >> to the terminal. What I see is... > > >>=20 > > >> t.rest =3D NIL? FALSE > > >> ISTYPE(t.rest=2CT)? TRUE > > >> Rest(t.rest) =3D NIL? TRUE > > >> in ELSE clause... > > >>=20 > > >> What gives!? > > >>=20 > > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > > compiler and runtime bootstrapped today from some previous CM3. > > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C > and the > > >> code behaved properly under that one. > > >>=20 > > >> I believe I have also tried it both with and without compiler > > >> optimizations. > > >>=20 > > >> I find it baffling that so much stuff (mentor!) can work if > "AND" isn't > > >> working right. This is the only if statement in many=2C many > source files > > >> that seems to be working wrong. > > >>=20 > > >> Is it possible I'm missing something?? No I don't think so... > here's a mo= > > >re > > >> explicit version: > > >>=20 > > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > > >> Debug.Out("ISTYPE(t.rest=2CT)? " & > Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > > >> Debug.Out("Rest(t.rest) =3D NIL? " & > Fmt.Bool(Rest(t.rest)=3DNIL))=3B > > >> Debug.Out("conjunction? " & Fmt.Bool( > > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D > NIL ))=3B > > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL > THEN > > >> ... > > >>=20 > > >> output is: > > >>=20 > > >> t.rest # NIL? TRUE > > >> ISTYPE(t.rest=2CT)? TRUE > > >> Rest(t.rest) =3D NIL? TRUE > > >> conjunction? FALSE > > >> in ELSE clause... > > >>=20 > > >> TRUE AND TRUE AND TRUE is FALSE?? > > >>=20 > > >> Note that:=20 > > >>=20 > > >> VAR q=2C w=2C e :=3D TRUE=3B > > >>=20 > > >> Debug.Out("conjunction? " & Fmt.Bool( > > >> q AND w AND e))=3B > > >>=20 > > >> results in TRUE (as it should). > > >>=20 > > >>=20 > > >> Mika > > >>=20 > > > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > > >Content-Type: text/html; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > > > > > > > > >Kneejerk generic response:
> > > =3B
> > >I don't know the operator precedence. Can you put in parens?
> > >Have you looked at the code?
> > >Can you mail us a small self contained repro?
> > >Can you test it on birch?
> > > =3B (That way -- all your files are there and easily gotten/ > investigat= > > >ed by others.)
> > >Optimization enabled? Works without? I know=2C I shouldn't even > ask this so= > > >rt of thing without evidence.
> > > =3B
> > > =3B- Jay
 =3B
>=3B To: > m3devel at elegosoft.com
>=3B Dat= > > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu > = > > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B > Subject: [M3devel= > > >] Strange behavior in recent CM3-compiled code...
>=3B >
>=3B
= > > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to > update to the l= > > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C > and push m= > > >y project of migrating a largish codebase
>=3B from PM3 to > CM3 a littl= > > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C > on both my = > > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme > interpreter brok= > > >e. Here's what the code looks like=2C
>=3B with > annotations:
>=3B= > > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B > Fmt.Bool(t.rest=3DNIL))= > > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B > Fmt.Bool(ISTYPE(t= > > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " > &=3B Fmt= > > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest > # NIL AND= > > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 > Debug.Out("i= > > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C > "quote") = > > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C > "quasiquote") THE= > > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") > THEN spec= > > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote- > splicing") THEN= > > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B > 62 Debug.= > > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B > all you n= > > >eed to know is that Debug.Out prints out debugging > information
>=3B to= > > > the terminal. What I see is...
>=3B
>=3B t.rest =3D > NIL? FALSE<= > > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D > NIL? TRUE
= > > >>=3B in ELSE clause...
>=3B
>=3B What gives!? >
>=3B
&g= > > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 > with a
&g= > > >t=3B compiler and runtime bootstrapped today from some previous > CM3.
>= > > >=3B My old CM3 compiler was timestamped... April 30=2C I > believe=2C and the= > > >
>=3B code behaved properly under that one.
>=3B >
>=3B I bel= > > >ieve I have also tried it both with and without > compiler
>=3B optimiza= > > >tions.
>=3B
>=3B I find it baffling that so much stuff > (mentor!)= > > > can work if "AND" isn't
>=3B working right. This is the > only if state= > > >ment in many=2C many source files
>=3B that seems to be > working wrong.= > > >
>=3B
>=3B Is it possible I'm missing something?? No I > don't thi= > > >nk so... here's a more
>=3B explicit version:
>=3B >
>=3B Deb= > > >ug.Out("t.rest # NIL? " &=3B > Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > > >t("ISTYPE(t.rest=2CT)? " &=3B > Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B > Fmt.Bool(Rest(t.rest)=3DNIL))= > > >=3B
>=3B Debug.Out("conjunction? " &=3B > Fmt.Bool(
>=3B t.rest = > > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D > NIL ))=3B
>=3B IF t.= > > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL > THEN
>=3B .= > > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # > NIL? TRUE<= > > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D > NIL? TRUE
= > > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B >
>=3B = > > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that: >
>= > > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B > Debug.Out(= > > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND > e))=3B
>=3B > >R>>=3B results in TRUE (as it should).
>=3B
>=3B >
>=3B Mi= > > >ka
>=3B
> > >= > > > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Jun 17 00:33:30 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 16 Jun 2009 15:33:30 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Tue, 16 Jun 2009 18:33:41." <20090616163341.32CFBCC308@birch.elegosoft.com> Message-ID: <200906162233.n5GMXUhZ091746@camembert.async.caltech.edu> Just wanted to report that my evidence of the bug is gone with this update. As always, many thanks! Antony Hosking writes: >CVSROOT: /usr/cvs >Changes by: hosking at birch. 09/06/16 18:33:41 > >Modified files: > cm3/m3-sys/m3front/src/builtinOps/: IsType.m3 > >Log message: > Fix bug introduced in conditional ISTYPE when tagged reference support was > added. From wagner at elegosoft.com Wed Jun 17 11:19:04 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 17 Jun 2009 11:19:04 +0200 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> References: <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: <20090617111904.nkmmsr3s0kswsg0s@mail.elegosoft.com> Quoting Mika Nystrom : > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function > `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function > `patsubst'. Stop. I had these errors, too, some weeks ago. I had to manually install the latest GNU versions of make, autoconf and automake, IIRC. These kinds of problems always kreep in by importing new gcc code, as the GNU developers of course always use all their latest tools, and Apple is somewhay more conservative with their distributions. Olaf > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake > runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 09/06/15 11:49:14 >> >> Added files: >> cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c >> gengtype-yacc.h >> >> Log message: >> Add back the lex/yacc/flex/bison outputs that Apple deleted >> but didn't note in the REMOVED file. You only see their >> absence cause problems if building on a machine without >> lex/yacc/flex/bison, such as birch that is missing bison. >> Apple didn't modify gengtype-lex.l and gentype-yacc.y, >> so the unmodified versions of these files taken from gcc 4.2.1. > -- 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 Jun 18 13:43:34 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Jun 2009 13:43:34 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090609212543.GA23398@topoi.pooq.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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> Message-ID: <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > Is it time for me to make another try at installing cm3 from scratch? > In particular, do you think most of the problems I reported with > documentation and archives, etc., have been solved? I really want to > get m3 working on this laptop, but I also want to provide the most > useful problem reports. > > I'm definitely trying to act like a naive user in these installation > attempts (which means I'm trying to act stupider than I am). I've now put some initial release engineering documentation onto birch, available at http://www.opencm3.net/releng It is not linked yet to the main web pages. There are archives for AMD64 built on birch, and current archives for FreeBSD4 should arrive within the next hours (depending on the upload speed of my home link :-). Please try one of those platforms as an example, if possible, before we proceed to perform the builds on other targets. Feel free to update/fix/extend the documentation in www/releng/index-frag.html We will also need to add some more system specifics for Windows users. Perhaps Randy or Jay will look at that. All RC1 archives can be built and shipped to birch with SHIPRC=yes ./scripts/make-dist.sh Contributions for all missing platforms are welcome; but I'd suggest to wait for the first doc and script fixes before we announce the availability for the first release candidate. I'd also like to add links for any system-specific installation packages which might be available. Of course, these should contain the same RC version as the standard archives. Please everybody, add corrections and extended information as you see fit. Thanks for your patience and continuing support, 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 Thu Jun 18 14:05:20 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 12:05:20 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618134334.njcom4fusg0ccsws@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Message-ID: 2) CM3's shared libraries and any you create and ship are in: /usr/local/cm3/lib On most Unix systems you need to set the LD_LIBRARY_PATH (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) environment variable before running programs that use these shared libraries. You don't need to do this any longer. Except on NetBSD. But even that will change with a move to NetBSD 5.0, which was recently released. I'm not certain I got to every platform yet with that change, but I definitely got to a few. AMD64_DARWIN is missing from the list. You should probably mention "Mac OSX" in the description of "Darwin", well, except for ARM_DARWIN, which should mention iPhone and iPod Touch. (cm3 does run on my phone..) Interix should mention Service for Unix (SFU) and Subsystem for Unix Applications (SUA). SOLgnu uses the GNU C compiler but I believe Sun linker. I still haven't done much with my Alpha and IA64 machines. :) Hm, so many archives per platform now. Combinatorial situations lend themselves to combinatorial thinking/work, yuck.. - Jay ---------------------------------------- > Date: Thu, 18 Jun 2009 13:43:34 +0200 > From: wagner at elegosoft.com > To: hendrik at topoi.pooq.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > http://www.opencm3.net/releng From jay.krell at cornell.edu Thu Jun 18 14:12:30 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 12:12:30 +0000 Subject: [M3devel] platform names Message-ID: The new documentation says: Except for some legacy names, all target names have the format PROCESSOR OR ARCHITECTURE_OPERATING SYSTEM. I'm not suggesting a change to the documentation or any existing "new" platform names but I'm pretty certain this system is going to break down on some platforms. In particular, I have an "ARM_LINUX" system, with uclibc, instead of the "usual" desktop/laptop/server glibc. And I have an "MIPLE_LINUX" system, also with uclibc, and worse, Linux 2.4. It is a router and apparently 2.4 is considered reasonable and "current". Linux 2.4 doesn't have the "good" native pthreads, though it does have the old bad "LinuxThreads". It's possible, esp. for Linux, we can/should target the kernel syscall interface and not the C runtime. In which case, this problem is reduced. That's very similar to static linking to libc.a. It's probably /mostly/ easy, easy for open/close/stat/seek/read/write/_exit/fork/exec which are probably all pretty thin in the C runtime. But less easy for startup and threads. It /might/ be that uclibc and glibc are binary compatible, at least partly. I don't know. - Jay From wagner at elegosoft.com Thu Jun 18 14:34:31 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Jun 2009 14:34:31 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: 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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Message-ID: <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> Quoting Jay : > > 2) CM3's shared libraries and any you create and ship are in: > /usr/local/cm3/lib > On most Unix systems you need to set the LD_LIBRARY_PATH > (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) > environment variable before running programs that use > these shared libraries. > You don't need to do this any longer. > Except on NetBSD. But even that will change with a move to NetBSD 5.0, > which was recently released. > I'm not certain I got to every platform yet with that change, but > I definitely got to a few. doc fixed > AMD64_DARWIN is missing from the list. > You should probably mention "Mac OSX" in the description of "Darwin", > well, except for ARM_DARWIN, which should mention iPhone and iPod Touch. > (cm3 does run on my phone..) There is no configuration file for it in m3-sys/cminstall/src/config-no-install I've added it nonetheless. Perhaps you need to commit it. > Interix should mention Service for Unix (SFU) and Subsystem for Unix > Applications (SUA). added > SOLgnu uses the GNU C compiler but I believe Sun linker. fixed > I still haven't done much with my Alpha and IA64 machines. :) > > > Hm, so many archives per platform now. > Combinatorial situations lend themselves to combinatorial > thinking/work, yuck.. We can also provide one complete big archive if people want that. It's just a matter of adding one line in make-dist.sh. It will put some more stress on our network links though ;-) I doubt that many people really want everything. Thanks for the comments, 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 Thu Jun 18 14:39:26 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 12:39:26 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618143431.9b3b3tmzjqww4s48@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> Message-ID: > >> AMD64_DARWIN is missing from the list. > > There is no configuration file for it in > That's because I don't have this hardware, yet. :) - Jay From jay.krell at cornell.edu Thu Jun 18 14:52:29 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 12:52:29 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618143431.9b3b3tmzjqww4s48@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> Message-ID: ps: NT386 isn't in the list. Interix btw is something you free "beer" download and install on some versions of Windows (XP, 2003, I think 2000), and is an optional component you can just enable on newer version (2003R2, Vista, 2008). So maybe Windows and/or NT should be mentioned there. Support will likely only be for 3.5 or newer, since that is when pthreads support was added, and it is already fairly old. NT386GNU and NT386MINGNU are missing also, but that's ok. I kind of like the idea of there being "tiers" of platforms. Two or maybe three. The more supported and the less supported. I would suggest: tier 1: LINUXLIBC6 (aka I386_LINUX) AMD64_LINUX FreeBSD4 (aka I386_FREEBSD) AMD64_FREEBSD AMD64_LINUX I386_LINUX SOLgnu tier 2: SPARC32_LINUX SPARC64_LINUX *_OPENBSD *_NETBSD, NetBSD2i386 SOLsun PPC_* MIPS*_* tier 3: could probably be done easily/quickly if anyone wanted and hardware made available, if gcc 4.2 or 4.3 already supports it (You see, a C backend would extend support to more systems..Plan9 for example...) This is based on apparent number of users. I don't draw a distinction between I386_DARWIN and AMD64_DARWIN because they run on nearly the exact same systems, nearly. (except non-Apple hardware, a few old x86 Macs, and maybe Apple TV). It might be reasonable as well to say a platform can only be tier 1 if has a Tinderbox running. That would knock the list down a lot though. - Jay ---------------------------------------- > Date: Thu, 18 Jun 2009 14:34:31 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: hendrik at topoi.pooq.com; m3devel at elegosoft.com > Subject: RE: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > Quoting Jay : > >> >> 2) CM3's shared libraries and any you create and ship are in: >> /usr/local/cm3/lib >> On most Unix systems you need to set the LD_LIBRARY_PATH >> (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) >> environment variable before running programs that use >> these shared libraries. >> You don't need to do this any longer. >> Except on NetBSD. But even that will change with a move to NetBSD 5.0, >> which was recently released. >> I'm not certain I got to every platform yet with that change, but >> I definitely got to a few. > > doc fixed > >> AMD64_DARWIN is missing from the list. >> You should probably mention "Mac OSX" in the description of "Darwin", >> well, except for ARM_DARWIN, which should mention iPhone and iPod Touch. >> (cm3 does run on my phone..) > > There is no configuration file for it in > > m3-sys/cminstall/src/config-no-install > > I've added it nonetheless. Perhaps you need to commit it. > >> Interix should mention Service for Unix (SFU) and Subsystem for Unix >> Applications (SUA). > > added > >> SOLgnu uses the GNU C compiler but I believe Sun linker. > > fixed > >> I still haven't done much with my Alpha and IA64 machines. :) >> >> >> Hm, so many archives per platform now. >> Combinatorial situations lend themselves to combinatorial >> thinking/work, yuck.. > > We can also provide one complete big archive if people want that. > It's just a matter of adding one line in make-dist.sh. > It will put some more stress on our network links though ;-) > I doubt that many people really want everything. > > Thanks for the comments, > > 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 wagner at elegosoft.com Thu Jun 18 15:06:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Jun 2009 15:06:36 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: 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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> Message-ID: <20090618150636.0rbmvi4g74k04cww@mail.elegosoft.com> Quoting Jay : > ps: NT386 isn't in the list. > > Interix btw is something you free "beer" download and install on > some versions of Windows (XP, 2003, I think 2000), and is an > optional component you can just enable on newer version (2003R2, > Vista, 2008). > So maybe Windows and/or NT should be mentioned there. > Support will likely only be for 3.5 or newer, since that is when > pthreads support was added, and it is already fairly old. > > > NT386GNU and NT386MINGNU are missing also, but that's ok. Jay, could you please add appropriate config files for NT386 and NT386GNU to the config-no-install directory? I was of the opinion, that your config files there were complete. I'd like to be both these platforms to be part of the release. > I kind of like the idea of there being "tiers" of platforms. > Two or maybe three. > The more supported and the less supported. > > > I would suggest: > > > tier 1: > LINUXLIBC6 (aka I386_LINUX) > AMD64_LINUX > FreeBSD4 (aka I386_FREEBSD) > AMD64_FREEBSD > AMD64_LINUX > I386_LINUX > SOLgnu +NT386 We should not ignore the Windows community. > tier 2: > SPARC32_LINUX > SPARC64_LINUX > *_OPENBSD > *_NETBSD, NetBSD2i386 > SOLsun > PPC_* > MIPS*_* > > tier 3: > could probably be done easily/quickly if anyone wanted and hardware > made available, if gcc 4.2 or 4.3 already supports it > (You see, a C backend would extend support to more systems..Plan9 > for example...) > > This is based on apparent number of users. > I don't draw a distinction between I386_DARWIN and AMD64_DARWIN > because they run on nearly the exact same systems, nearly. (except > non-Apple hardware, a few old x86 Macs, and maybe Apple TV). > > It might be reasonable as well to say a platform can only be tier 1 > if has a Tinderbox running. > That would knock the list down a lot though. That would be too constraining currently. Thanks in advance, 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 Thu Jun 18 16:07:16 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 14:07:16 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618150636.0rbmvi4g74k04cww@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> <20090618150636.0rbmvi4g74k04cww@mail.elegosoft.com> Message-ID: (Yes, of course NT386 is tier 1, I forgot, NT386GNU, NT386MINGNU, eh..there is a test case that hangs on NT386GNU that I couldn't figure out and it is slow..I386_INTERIX /might/ be a viable alternative, but it seems to have far less of a following..but NT386GNU does have 64bit LONG and NT386 does not.. :( ) - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: hendrik at topoi.pooq.com; m3devel at elegosoft.com Subject: RE: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) Date: Thu, 18 Jun 2009 14:05:28 +0000 The NT386* files are in the old config directory. My automation knows to check config-no-install first, then config. I thought moving them might break you. At least in the past. Your Tinderbox work. You know...I kind of took over these files, churned them mercilessly, felt ok about it. All the other files I forked and left the "originals" alone. But then eventually mine became the Real ones. Ok, I'll move them. At some point..maybe just after this release, I suggest we: delete all of config then move all config-no-install to config But I bet CVS can't track history across a move, lame. (Maybe after this release we switch to svn or hg or git or mtn, or can get a free p4 license, or darn near anything...) And also delete all the unused Unix/*.i3 files. I worry about the fine line between keeping stuff for historical purposes vs. deleting unused stuff for clarity. I know CVS keeps even the deleted stuff, but Attic is kind of less visible, isn't brought down by cvs upd, and the cvs web interface is poor. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jun 18 16:05:28 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 14:05:28 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618150636.0rbmvi4g74k04cww@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> <20090618150636.0rbmvi4g74k04cww@mail.elegosoft.com> Message-ID: The NT386* files are in the old config directory. My automation knows to check config-no-install first, then config. I thought moving them might break you. At least in the past. Your Tinderbox work. You know...I kind of took over these files, churned them mercilessly, felt ok about it. All the other files I forked and left the "originals" alone. But then eventually mine became the Real ones. Ok, I'll move them. At some point..maybe just after this release, I suggest we: delete all of config then move all config-no-install to config But I bet CVS can't track history across a move, lame. (Maybe after this release we switch to svn or hg or git or mtn, or can get a free p4 license, or darn near anything...) And also delete all the unused Unix/*.i3 files. I worry about the fine line between keeping stuff for historical purposes vs. deleting unused stuff for clarity. I know CVS keeps even the deleted stuff, but Attic is kind of less visible, isn't brought down by cvs upd, and the cvs web interface is poor. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jun 18 16:27:03 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 14:27:03 +0000 Subject: [M3devel] FW: Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618134334.njcom4fusg0ccsws@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Message-ID: The copy to the list was truncated, but direct to Olaf wasn't and he quoted the whole thing.. (The truncation of Olaf's original message was my deliberate doing.) - Jay > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; hendrik at topoi.pooq.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > Date: Thu, 18 Jun 2009 12:05:20 +0000 > > > 2) CM3's shared libraries and any you create and ship are in: > /usr/local/cm3/lib > On most Unix systems you need to set the LD_LIBRARY_PATH > (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) > environment variable before running programs that use > these shared libraries. > > > You don't need to do this any longer. > Except on NetBSD. But even that will change with a move to NetBSD 5.0, > which was recently released. > I'm not certain I got to every platform yet with that change, but > I definitely got to a few. > > > AMD64_DARWIN is missing from the list. > You should probably mention "Mac OSX" in the description of "Darwin", > well, except for ARM_DARWIN, which should mention iPhone and iPod Touch. > (cm3 does run on my phone..) > > > Interix should mention Service for Unix (SFU) and Subsystem for Unix Applications (SUA). > > > SOLgnu uses the GNU C compiler but I believe Sun linker. > > > I still haven't done much with my Alpha and IA64 machines. :) > > > Hm, so many archives per platform now. > Combinatorial situations lend themselves to combinatorial thinking/work, yuck.. > > > - Jay > > > > ---------------------------------------- > > Date: Thu, 18 Jun 2009 13:43:34 +0200 > > From: wagner at elegosoft.com > > To: hendrik at topoi.pooq.com > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > > > http://www.opencm3.net/releng -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 22 06:04:31 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 04:04:31 +0000 Subject: [M3devel] new distribution size? Message-ID: Olaf, The ws-core archives are quite large. Over 100meg, four times the size of bin-std. Should they be? I guess they have a lot of source? - Jay From wagner at elegosoft.com Mon Jun 22 08:17:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Jun 2009 08:17:29 +0200 Subject: [M3devel] new distribution size? In-Reply-To: References: Message-ID: <20090622081729.z6gvq7us8w8ckscs@mail.elegosoft.com> Quoting Jay : > > Olaf, > > The ws-core archives are quite large. > Over 100meg, four times the size of bin-std. > Should they be? I guess they have a lot of source? It's mostly the gcc compiler collection: % (. scripts/pkginfo.sh; for f in `grep core scripts/pkginfo.txt | awk '{print $1}'`; do p=`pkgpath $f`; du -sk $p; done) 1486 m3-win/import-libs 326892 m3-sys/m3cc 22294 m3-libs/m3core 25638 m3-libs/libm3 704 m3-libs/patternmatching 2542 m3-libs/sysutils 386 m3-libs/unittest 4492 m3-sys/m3middle 786 m3-sys/m3objfile 1334 m3-sys/m3linker 2662 m3-sys/m3back 2018 m3-sys/m3staloneback 19328 m3-sys/m3front 2082 m3-sys/m3quake 38372 m3-sys/cm3 320 m3-sys/m3scanner 1804 m3-sys/m3tools 4964 m3-sys/m3cgcat 2744 m3-sys/m3cggen 2750 m3-tools/m3bundle 1394 m3-sys/mklib 1318 m3-sys/fix_nl 348 m3-sys/libdump 702 m3-libs/bitvector 382 m3-libs/digraph 286 m3-libs/parseparams 1208 m3-libs/realgeometry 1188 m3-libs/set 1210 m3-libs/slisp 758 m3-libs/sortedtableextras 1002 m3-libs/table-list 202 m3-libs/tempfiles 206 m3-libs/tcl 794 m3-comm/tcp Perhaps we should archive that on its own, too? What do the others think? 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 Mon Jun 22 11:33:24 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 09:33:24 +0000 Subject: [M3devel] nanosleep? Message-ID: Tony, Interix doesn't have nanosleep. Suggestions? It looks like all the uses except for XPause could use usleep? - Jay From hosking at cs.purdue.edu Mon Jun 22 12:29:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Jun 2009 06:29:38 -0400 Subject: [M3devel] nanosleep? In-Reply-To: References: Message-ID: Urgh! Perhaps implement a nanosleep for Interix in terms of usleep? On 22 Jun 2009, at 05:33, Jay wrote: > > Tony, Interix doesn't have nanosleep. > Suggestions? > > It looks like all the uses except for XPause could use usleep? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 22 14:58:17 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 12:58:17 +0000 Subject: [M3devel] files larger than 2gig Message-ID: C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 TYPE Status = RECORD type: Type; modificationTime: Time.T; size: INTEGER; END; size: INTEGER causes exceptions when you use the Modula-3 gui and browse to a directory with files larger than 2 gig. I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa (out 64 bits total) and thus can represent integers very much larger than INTEGER. LONGINT is a tempting option but doesn't help on the current NT386 platform, and I think 53 bits will last a very long time. I'm just trying out such a change and I can see it is not source compatible: "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN "../src/rw/FileRd.m3", line 140: types are not assignable 2 errors encountered "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX 2 errors encountered Nevertheless I think it should be done, probably even for this release. - Jay From jay.krell at cornell.edu Mon Jun 22 15:09:25 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 13:09:25 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Message-ID: Hm, here is another approach -- leave more code alone, like don't attempt to let FileRd/FileWr work on files larger than 2gig on a 32bit system for example. But do fix the lowest level status record to have either LONGINT or LONGREAL, preferable LONGREAL for the sake of NT386 (much as I dislike floating point..). That is, an intermediate goal would be: - browing to a directory with large files with the Trestle file picker should not crash - 32bit Modula-3 code may or may not be able to read/write such files - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] files larger than 2gig > Date: Mon, 22 Jun 2009 13:05:13 +0000 > > > Hm..I'm not sure. > Integers have certain properties, like dividing an integer by an integer yields an integer, > that floating point doesn't. Integer division tends toward zero faster than floating point division. > I can try getting it all to compile with LONGINT maybe instead. > The current behavior is pretty lame. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 22 Jun 2009 12:58:17 +0000 >> Subject: [M3devel] files larger than 2gig >> >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >> >> >> TYPE >> Status = RECORD >> type: Type; >> modificationTime: Time.T; >> size: INTEGER; >> END; >> >> >> size: INTEGER causes exceptions when you use the Modula-3 gui >> and browse to a directory with files larger than 2 gig. >> >> >> I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa >> (out 64 bits total) and thus can represent integers very much larger than INTEGER. >> >> >> LONGINT is a tempting option but doesn't help on the current NT386 platform, >> and I think 53 bits will last a very long time. >> >> >> I'm just trying out such a change and I can see it is not source compatible: >> >> >> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >> "../src/rw/FileRd.m3", line 140: types are not assignable >> 2 errors encountered >> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >> 2 errors encountered >> >> >> Nevertheless I think it should be done, probably even for this release. >> >> >> - Jay From jay.krell at cornell.edu Mon Jun 22 15:05:13 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 13:05:13 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Message-ID: Hm..I'm not sure. Integers have certain properties, like dividing an integer by an integer yields an integer, that floating point doesn't. Integer division tends toward zero faster than floating point division. I can try getting it all to compile with LONGINT maybe instead. The current behavior is pretty lame. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 22 Jun 2009 12:58:17 +0000 > Subject: [M3devel] files larger than 2gig > > > C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 > > > TYPE > Status = RECORD > type: Type; > modificationTime: Time.T; > size: INTEGER; > END; > > > size: INTEGER causes exceptions when you use the Modula-3 gui > and browse to a directory with files larger than 2 gig. > > > I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa > (out 64 bits total) and thus can represent integers very much larger than INTEGER. > > > LONGINT is a tempting option but doesn't help on the current NT386 platform, > and I think 53 bits will last a very long time. > > > I'm just trying out such a change and I can see it is not source compatible: > > > "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN > "../src/rw/FileRd.m3", line 140: types are not assignable > 2 errors encountered > "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN > "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX > 2 errors encountered > > > Nevertheless I think it should be done, probably even for this release. > > > - Jay From wagner at elegosoft.com Mon Jun 22 16:30:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Jun 2009 16:30:03 +0200 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Message-ID: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> Quoting Jay : > > C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 > > > TYPE > Status = RECORD > type: Type; > modificationTime: Time.T; > size: INTEGER; > END; > > > size: INTEGER causes exceptions when you use the Modula-3 gui > and browse to a directory with files larger than 2 gig. This is a known limitation on all 32 bit platforms. > I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa > (out 64 bits total) and thus can represent integers very much larger > than INTEGER. I wouldn't like that. Sizes are no real numbers, really ;-) Either use LONGINT or rely on INTEGER being large enough (64 bit on all 64 bit targets). > LONGINT is a tempting option but doesn't help on the current NT386 platform, > and I think 53 bits will last a very long time. What exactly was the problem in makeing LONGINT work on NT386? > I'm just trying out such a change and I can see it is not source compatible: > > > "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN > "../src/rw/FileRd.m3", line 140: types are not assignable > 2 errors encountered > "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN > "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX > 2 errors encountered > > > Nevertheless I think it should be done, probably even for this release. I'm not convinced... 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 Mon Jun 22 17:36:21 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 15:36:21 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> Message-ID: The NT386 backend internally uses a stack of 32bit words to slightly optimize codegen..it seems kind of similar to what the frontend does..I wonder if it is redundant.. Anyway.. It doesn't appear easy to extend, but with years of hindsight at this point..it might be easiest to have a mode where the front end decomposes 64bit operations into multiple 32bit operations. Maybe that'd be an entire "cg layer" (it appears code generators are layerable). I'm less keen on the LONGREAL solution but still pretty keen on LONGINT. Not right now though, maybe in a few days.. - Jay ---------------------------------------- > Date: Mon, 22 Jun 2009 16:30:03 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > Quoting Jay : > >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >> >> >> TYPE >> Status = RECORD >> type: Type; >> modificationTime: Time.T; >> size: INTEGER; >> END; >> >> >> size: INTEGER causes exceptions when you use the Modula-3 gui >> and browse to a directory with files larger than 2 gig. > > This is a known limitation on all 32 bit platforms. > >> I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa >> (out 64 bits total) and thus can represent integers very much larger >> than INTEGER. > > I wouldn't like that. Sizes are no real numbers, really ;-) > Either use LONGINT or rely on INTEGER being large enough (64 bit > on all 64 bit targets). > >> LONGINT is a tempting option but doesn't help on the current NT386 platform, >> and I think 53 bits will last a very long time. > > What exactly was the problem in makeing LONGINT work on NT386? > >> I'm just trying out such a change and I can see it is not source compatible: >> >> >> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >> "../src/rw/FileRd.m3", line 140: types are not assignable >> 2 errors encountered >> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >> 2 errors encountered >> >> >> Nevertheless I think it should be done, probably even for this release. > > I'm not convinced... > > 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 hosking at cs.purdue.edu Mon Jun 22 18:58:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Jun 2009 12:58:45 -0400 Subject: [M3devel] files larger than 2gig In-Reply-To: References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> Message-ID: On 22 Jun 2009, at 11:36, Jay wrote: > > The NT386 backend internally uses a stack of 32bit words to slightly > optimize codegen..it seems kind of similar to what the frontend > does..I wonder if it is redundant.. > Anyway.. > It doesn't appear easy to extend, but with years of hindsight at > this point..it might be easiest to have a mode where the front end > decomposes 64bit operations into multiple 32bit operations. Yuck. Why not decompose in the backend? > Maybe that'd be an entire "cg layer" (it appears code generators are > layerable). > > > I'm less keen on the LONGREAL solution but still pretty keen on > LONGINT. > Not right now though, maybe in a few days.. > > > - Jay > > > ---------------------------------------- >> Date: Mon, 22 Jun 2009 16:30:03 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] files larger than 2gig >> >> Quoting Jay : >> >>> >>> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >>> >>> >>> TYPE >>> Status = RECORD >>> type: Type; >>> modificationTime: Time.T; >>> size: INTEGER; >>> END; >>> >>> >>> size: INTEGER causes exceptions when you use the Modula-3 gui >>> and browse to a directory with files larger than 2 gig. >> >> This is a known limitation on all 32 bit platforms. >> >>> I suggest size be changed to LONGREAL, which generally has a 53 >>> bit mantissa >>> (out 64 bits total) and thus can represent integers very much larger >>> than INTEGER. >> >> I wouldn't like that. Sizes are no real numbers, really ;-) >> Either use LONGINT or rely on INTEGER being large enough (64 bit >> on all 64 bit targets). >> >>> LONGINT is a tempting option but doesn't help on the current NT386 >>> platform, >>> and I think 53 bits will last a very long time. >> >> What exactly was the problem in makeing LONGINT work on NT386? >> >>> I'm just trying out such a change and I can see it is not source >>> compatible: >>> >>> >>> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >>> "../src/rw/FileRd.m3", line 140: types are not assignable >>> 2 errors encountered >>> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >>> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >>> 2 errors encountered >>> >>> >>> Nevertheless I think it should be done, probably even for this >>> release From wagner at elegosoft.com Mon Jun 22 22:31:52 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Jun 2009 22:31:52 +0200 Subject: [M3devel] compilation fails on SunOs Message-ID: <20090622223152.1u5re0mjs4c0osoo@mail.elegosoft.com> Tinderbox cannot compiler m3core on SunOS: 9884 ../src/unix/Common/UtimeC.c: In function `Utime__ctime_r?: 9885 NEXT ../src/unix/Common/UtimeC.c:101: error: too few arguments to function `ctime_r? 9886 compile_c => 1 9887 NEXT C compiler failed compiling: ../src/unix/Common/UtimeC.c 9888 new source -> compiling UnixC.c 9889 new source -> compiling UnixLink.c Please fix, 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 Mon Jun 22 23:50:59 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 21:50:59 +0000 Subject: [M3devel] compilation fails on SunOs In-Reply-To: <20090622223152.1u5re0mjs4c0osoo@mail.elegosoft.com> References: <20090622223152.1u5re0mjs4c0osoo@mail.elegosoft.com> Message-ID: > Please fix, I believe I already did. - Jay ---------------------------------------- > Date: Mon, 22 Jun 2009 22:31:52 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] compilation fails on SunOs > > Tinderbox cannot compiler m3core on SunOS: > > 9884 ../src/unix/Common/UtimeC.c: In function `Utime__ctime_r?: > 9885 NEXT ../src/unix/Common/UtimeC.c:101: error: too few > arguments to function `ctime_r? > 9886 compile_c => 1 > 9887 NEXT C compiler failed compiling: ../src/unix/Common/UtimeC.c > 9888 new source -> compiling UnixC.c > 9889 new source -> compiling UnixLink.c > > Please fix, > > 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 Tue Jun 23 11:52:15 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 23 Jun 2009 02:52:15 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: Your message of "Mon, 22 Jun 2009 13:09:25 -0000." Message-ID: <200906230952.n5N9qFdh081330@camembert.async.caltech.edu> Jay I just want to add that I've written a lot of code that "streams" files greater than 2 GB just fine in Modula-3. The trick, which I learned from Blair MacIntyre's rdwr package, is to reset the pointers periodically: (* $Id: RdWrReset.m3,v 1.1 2008/11/26 18:32:40 mika Exp $ *) MODULE RdWrReset; IMPORT Rd AS R, Wr AS W; IMPORT RdClass, WrClass; <*NOWARN*>IMPORT UnsafeWr, UnsafeRd; (* Since we need to use the Mutex properties of Rd.T and Wr.T, we should actually import UnsafeWr and UnsafeRd. We need to add the following revelations, as the comment in UnsafeRd points out, if we want to include both the Unsafe* and *Class interfaces. *) REVEAL RdClass.Private <: MUTEX; REVEAL WrClass.Private <: MUTEX; PROCEDURE Rd (rd: R.T) = BEGIN LOCK rd DO DEC(rd.cur, rd.lo); DEC(rd.hi, rd.lo); rd.lo := 0; END; END Rd; PROCEDURE Wr (wr: W.T) = BEGIN LOCK wr DO DEC(wr.cur, wr.lo); DEC(wr.hi, wr.lo); wr.lo := 0; END; END Wr; BEGIN END RdWrReset. Jay writes: > >Hm, here is another approach -- leave more code alone, like don't attempt to l >et FileRd/FileWr work on files larger than 2gig on a 32bit system for example. > But do fix the lowest level status record to have either LONGINT or LONGREAL, > preferable LONGREAL for the sake of NT386 (much as I dislike floating point.. >). >That is, an intermediate goal would be: > - browing to a directory with large files with the Trestle file picker should > not crash > - 32bit Modula-3 code may or may not be able to read/write such files > > - Jay > > > >---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: RE: [M3devel] files larger than 2gig >> Date: Mon, 22 Jun 2009 13:05:13 +0000 >> >> >> Hm..I'm not sure. >> Integers have certain properties, like dividing an integer by an integer yie >lds an integer, >> that floating point doesn't. Integer division tends toward zero faster than >floating point division. >> I can try getting it all to compile with LONGINT maybe instead. >> The current behavior is pretty lame. >> >> - Jay >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Mon, 22 Jun 2009 12:58:17 +0000 >>> Subject: [M3devel] files larger than 2gig >>> >>> >>> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >>> >>> >>> TYPE >>> Status = RECORD >>> type: Type; >>> modificationTime: Time.T; >>> size: INTEGER; >>> END; >>> >>> >>> size: INTEGER causes exceptions when you use the Modula-3 gui >>> and browse to a directory with files larger than 2 gig. >>> >>> >>> I suggest size be changed to LONGREAL, which generally has a 53 bit mantiss >a >>> (out 64 bits total) and thus can represent integers very much larger than I >NTEGER. >>> >>> >>> LONGINT is a tempting option but doesn't help on the current NT386 platform >, >>> and I think 53 bits will last a very long time. >>> >>> >>> I'm just trying out such a change and I can see it is not source compatible >: >>> >>> >>> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >>> "../src/rw/FileRd.m3", line 140: types are not assignable >>> 2 errors encountered >>> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >>> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >>> 2 errors encountered >>> >>> >>> Nevertheless I think it should be done, probably even for this release From mika at async.caltech.edu Tue Jun 23 11:54:47 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 23 Jun 2009 02:54:47 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: Your message of "Mon, 22 Jun 2009 13:05:13 -0000." Message-ID: <200906230954.n5N9slnb081383@camembert.async.caltech.edu> Also, making file handling code depend on the presence of IEEE floating point seems rather odd... As far as I know there is nothing in Modula-3 that bans implementing REAL with single precision arithmetic? By the way I think it's sad that Modula-3's wonderful floating-point support has attracted so much bit rot. I think it's better than just about any other programming language (except maybe some Fortran dialects?) Mika Jay writes: > >Hm..I'm not sure. >Integers have certain properties, like dividing an integer by an integer yield >s an integer, >that floating point doesn't. Integer division tends toward zero faster than fl >oating point division. >I can try getting it all to compile with LONGINT maybe instead. >The current behavior is pretty lame. > > - Jay > >---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 22 Jun 2009 12:58:17 +0000 >> Subject: [M3devel] files larger than 2gig >> >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >> >> >> TYPE >> Status = RECORD >> type: Type; >> modificationTime: Time.T; >> size: INTEGER; >> END; >> >> >> size: INTEGER causes exceptions when you use the Modula-3 gui >> and browse to a directory with files larger than 2 gig. >> >> >> I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa >> (out 64 bits total) and thus can represent integers very much larger than IN >TEGER. >> >> >> LONGINT is a tempting option but doesn't help on the current NT386 platform, >> and I think 53 bits will last a very long time. >> >> >> I'm just trying out such a change and I can see it is not source compatible: >> >> >> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >> "../src/rw/FileRd.m3", line 140: types are not assignable >> 2 errors encountered >> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >> 2 errors encountered >> >> >> Nevertheless I think it should be done, probably even for this release. >> >> >> - Jay From jay.krell at cornell.edu Tue Jun 23 13:02:26 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 23 Jun 2009 11:02:26 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <200906230954.n5N9slnb081383@camembert.async.caltech.edu> References: Your message of "Mon, 22 Jun 2009 13:05:13 -0000." <200906230954.n5N9slnb081383@camembert.async.caltech.edu> Message-ID: Every modern system implements IEEE 754 binary floating point in hardware, except maybe for the occasional floating point-less embedded ARM or maybe MIPS, though even still, they tend to support "what I expect" in software (heck, just look at Apple's original 6502 and 68000 IEEE 754 software environments "SANE"). REAL is typically 32 bits. LONGREAL is much more useful, 64 bits total, 53 bits of mantissa. Heck, anything more than 31 bits of mantissa is a win. EXTENDED is the same as LONGREAL. All you have to do to get an unhandled exception is use the file open gui in formedit or such and browse to a directory with a large file. It's quite lame. Granted what Olaf said -- works fine on 64 bit platforms. On later thought, I'm much less keen on LONGREAL here. LONGINT would still be good though. And then trying to fix NT386 to have a 64bit LONGINT. I am not convinced that Modula-3 is or ever was superior here, in implementation. Yeah, they made a bold statement -- here are our portable interfaces, but they weren't available on many platforms. At the same time, most C systems did document various features, usually not very portable, but perhaps the building blocks of something portable. It's just that you have/had to read a lot of documentation, test it out, etc. Someone has to do it as some level. Nothing is free. (Similarly, Modula-3 "portability" lately is greatly aided by Posix/pthreads standard/implementation catching up.) C is getting better here, what with #pragma fenv and such. And again, you could always dig into the system-specific details. The real art that I don't fully understand, is how to specify "portable interfaces" that you "know" will be viable to implement "everywhere". Just what is nearly exactly the same "everywhere" that you know you'll be able to fill in the details later? Maybe it is survey lots of systems?? But, again, "lots" isn't many any longer. Heck, it's basically just Linux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhile, my list still includes Tru64/Alpha, VMS/Alpha, maybe VMS/IA64, AIX/32, AIX/64, IRIX/32, IRIX/64, etc.. to get running... :) ) That is -- really -- we probably should try to implement all that FloatMode stuff. - Jay > To: jay.krell at cornell.edu > Date: Tue, 23 Jun 2009 02:54:47 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > > Also, making file handling code depend on the presence of IEEE floating > point seems rather odd... As far as I know there is nothing in Modula-3 > that bans implementing REAL with single precision arithmetic? > > By the way I think it's sad that Modula-3's wonderful floating-point > support has attracted so much bit rot. I think it's better than just > about any other programming language (except maybe some Fortran > dialects?) > > Mika > > Jay writes: > > > >Hm..I'm not sure. > >Integers have certain properties, like dividing an integer by an integer yield > >s an integer, > >that floating point doesn't. Integer division tends toward zero faster than fl > >oating point division. > >I can try getting it all to compile with LONGINT maybe instead. > >The current behavior is pretty lame. > > > > - Jay > > > >---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 22 Jun 2009 12:58:17 +0000 > >> Subject: [M3devel] files larger than 2gig > >> > >> > >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 > >> > >> > >> TYPE > >> Status = RECORD > >> type: Type; > >> modificationTime: Time.T; > >> size: INTEGER; > >> END; > >> > >> > >> size: INTEGER causes exceptions when you use the Modula-3 gui > >> and browse to a directory with files larger than 2 gig. > >> > >> > >> I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa > >> (out 64 bits total) and thus can represent integers very much larger than IN > >TEGER. > >> > >> > >> LONGINT is a tempting option but doesn't help on the current NT386 platform, > >> and I think 53 bits will last a very long time. > >> > >> > >> I'm just trying out such a change and I can see it is not source compatible: > >> > >> > >> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN > >> "../src/rw/FileRd.m3", line 140: types are not assignable > >> 2 errors encountered > >> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN > >> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX > >> 2 errors encountered > >> > >> > >> Nevertheless I think it should be done, probably even for this release. > >> > >> > >> - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Jun 23 13:20:53 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 23 Jun 2009 04:20:53 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: Your message of "Tue, 23 Jun 2009 11:02:26 -0000." Message-ID: <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> Jay, Just a few comments... I do have some interest in the Modula-3 implementation on the Caltech Mosaic-C (which has no floating point). M3 has run on this before---I have an old M3 compiler for it. More in general, M3 is a very nice language to bring up on new hardware. Requiring the presence of floating point makes that much more difficult. EXTENDED really should not be 64 bits. It should be 80 bits or perhaps (on some archs) 128 bits. On x86 it should definitely be 80 bits, since that is the only precision actually supported by Intel hardware. Not only would the the answers have more bits of precision but the hardware would actually run faster in many cases! (Long double is 80 bits under gcc on my FreeBSDs.) Finally my understanding is that when M3 was developed, Bill Kahan sent over one of his grad students to work on the floating point. That is what all those weird FP interfaces are about. They're not so much about portability as they are about completeness---from the point of view of the person developing numerical methods. If you read Kahan's rants about how FP "should be done" you can see that the M-3 Float interfaces closely follow the rants. I don't think they're expected to work on all hardware, only on systems that have reasonably powerful floating point (IEEE, VAX, System/370?) Mika Jay writes: >--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Every modern system implements IEEE 754 binary floating point in hardware= >=2C except maybe for the occasional floating point-less embedded ARM or may= >be MIPS=2C though even still=2C they tend to support "what I expect" in sof= >tware (heck=2C just look at Apple's original 6502 and 68000 IEEE 754 softwa= >re environments "SANE"). > > >=20 > >REAL is typically 32 bits. > >LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >=2C anything more than 31 bits of mantissa is a win. > >EXTENDED is the same as LONGREAL. > >=20 > >=20 > >All you have to do to get an unhandled exception is use the file open gui i= >n formedit or such and browse to a directory with a large file. It's quite = >lame. > >=20 > >=20 > >Granted what Olaf said -- works fine on 64 bit platforms. > >=20 > >=20 > >On later thought=2C I'm much less keen on LONGREAL here. LONGINT would stil= >l be good though. > >And then trying to fix NT386 to have a 64bit LONGINT. > >=20 > >=20 > >I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >ntation. Yeah=2C they made a bold statement -- here are our portable interf= >aces=2C but they weren't available on many platforms. At the same time=2C m= >ost C systems did document various features=2C usually not very portable=2C= > but perhaps the building blocks of something portable. > >It's just that you have/had to read a lot of documentation=2C test it out= >=2C etc. Someone has to do it as some level. Nothing is free. > >(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >ads standard/implementation catching up.) > >=20 > >=20 > >C is getting better here=2C what with #pragma fenv and such. > >And again=2C you could always dig into the system-specific details. > >=20 > >=20 > >The real art that I don't fully understand=2C is how to specify "portable i= >nterfaces" that you "know" will be viable to implement "everywhere". Just w= >hat is nearly exactly the same "everywhere" that you know you'll be able to= > fill in the details later? Maybe it is survey lots of systems?? > >But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) > >=20 > >=20 > >That is -- really -- we probably should try to implement all that FloatMode= > stuff. > >=20 > > > - Jay > > >=20 >> To: jay.krell at cornell.edu >> Date: Tue=2C 23 Jun 2009 02:54:47 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] files larger than 2gig >>=20 >>=20 >> Also=2C making file handling code depend on the presence of IEEE floating >> point seems rather odd... As far as I know there is nothing in Modula-3 >> that bans implementing REAL with single precision arithmetic? >>=20 >> By the way I think it's sad that Modula-3's wonderful floating-point >> support has attracted so much bit rot. I think it's better than just >> about any other programming language (except maybe some Fortran >> dialects?) >>=20 >> Mika >>=20 >> Jay writes: >> > >> >Hm..I'm not sure. >> >Integers have certain properties=2C like dividing an integer by an integ= >er yield >> >s an integer=2C >> >that floating point doesn't. Integer division tends toward zero faster t= >han fl >> >oating point division. >> >I can try getting it all to compile with LONGINT maybe instead. >> >The current behavior is pretty lame. >> > >> > - Jay >> > >> >---------------------------------------- >> >> From: jay.krell at cornell.edu >> >> To: m3devel at elegosoft.com >> >> Date: Mon=2C 22 Jun 2009 12:58:17 +0000 >> >> Subject: [M3devel] files larger than 2gig >> >> >> >> >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >> >> >> >> >> >> TYPE >> >> Status =3D RECORD >> >> type: Type=3B >> >> modificationTime: Time.T=3B >> >> size: INTEGER=3B >> >> END=3B >> >> >> >> >> >> size: INTEGER causes exceptions when you use the Modula-3 gui >> >> and browse to a directory with files larger than 2 gig. >> >> >> >> >> >> I suggest size be changed to LONGREAL=2C which generally has a 53 bit = >mantissa >> >> (out 64 bits total) and thus can represent integers very much larger t= >han IN >> >TEGER. >> >> >> >> >> >> LONGINT is a tempting option but doesn't help on the current NT386 pla= >tform=2C >> >> and I think 53 bits will last a very long time. >> >> >> >> >> >> I'm just trying out such a change and I can see it is not source compa= >tible: >> >> >> >> >> >> "../src/rw/FileRd.m3"=2C line 73: incompatible argument types: MIN >> >> "../src/rw/FileRd.m3"=2C line 140: types are not assignable >> >> 2 errors encountered >> >> "../src/rw/FileWr.m3"=2C line 87: incompatible argument types: MIN >> >> "../src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >> >> 2 errors encountered >> >> >> >> >> >> Nevertheless I think it should be done=2C probably even for this relea= >se. >> >> >> >> >> >> - Jay > >--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Every modern system implements IEEE 754 binary floating point in hardware= >=2C except maybe for the occasional floating point-less embedded ARM or may= >be MIPS=2C though even still=2C they tend to support "what =3BI expect"= > in software (heck=2C just look at Apple's original 6502 and 68000 IEEE 754= > software environments "SANE").

> =3B
>REAL is typically =3B32 bits.
>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >=2C anything more than 31 bits of mantissa is a win.
>EXTENDED is the same as LONGREAL.
> =3B
> =3B
>All you have to do to get an unhandled exception is use the file open gui i= >n formedit or such and browse to a directory with a large file. It's quite = >lame.
> =3B
> =3B
>Granted what Olaf said -- works fine on 64 bit platforms.
> =3B
> =3B
>On later =3Bthought=2C I'm much less keen on LONGREAL here. LONGINT wou= >ld still be good though.
>And then trying to fix NT386 to have a 64bit LONGINT.
> =3B
> =3B
>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >ntation. Yeah=2C they made a bold statement -- here are our portable interf= >aces=2C but they weren't available on many =3Bplatforms. At the same ti= >me=2C most =3BC systems did document various features=2C usually not ve= >ry portable=2C but perhaps the building blocks of something portable.
>It's just that you have/had to read a lot of documentation=2C test it out= >=2C etc. Someone has to do it as some level. Nothing is free.
>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >ads standard/implementation catching up.)
> =3B
> =3B
>C is getting better here=2C what with #pragma fenv and such.
>And again=2C you could always dig into the system-specific details.
> =3B
> =3B
>The real art that I don't fully understand=2C is how to specify "portable i= >nterfaces" that you "know" will be viable to implement "everywhere". Just w= >hat is nearly exactly the same "everywhere" that you know you'll be able to= > fill in the details later? Maybe it is survey lots of systems??
>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) )
> =3B
> =3B
>That is -- really -- we probably should try to implement all that FloatMode= > stuff.
> =3B
>
 =3B- Jay
>
 =3B
>=3B To: jay.krell at cornell.edu
>=3B Date: Tue=2C 23 = >Jun 2009 02:54:47 -0700
>=3B From: mika at async.caltech.edu
>=3B CC= >: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] files larger than = >2gig
>=3B
>=3B
>=3B Also=2C making file handling code depe= >nd on the presence of IEEE floating
>=3B point seems rather odd... As = >far as I know there is nothing in Modula-3
>=3B that bans implementing= > REAL with single precision arithmetic?
>=3B
>=3B By the way I t= >hink it's sad that Modula-3's wonderful floating-point
>=3B support ha= >s attracted so much bit rot. I think it's better than just
>=3B about = >any other programming language (except maybe some Fortran
>=3B dialect= >s?)
>=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B &g= >t=3B
>=3B >=3BHm..I'm not sure.
>=3B >=3BIntegers have certai= >n properties=2C like dividing an integer by an integer yield
>=3B >= >=3Bs an integer=2C
>=3B >=3Bthat floating point doesn't. Integer div= >ision tends toward zero faster than fl
>=3B >=3Boating point divisio= >n.
>=3B >=3BI can try getting it all to compile with LONGINT maybe i= >nstead.
>=3B >=3BThe current behavior is pretty lame.
>=3B >= >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B---------------= >-------------------------
>=3B >=3B>=3B From: jay.krell at cornell.ed= >u
>=3B >=3B>=3B To: m3devel at elegosoft.com
>=3B >=3B>=3B D= >ate: Mon=2C 22 Jun 2009 12:58:17 +0000
>=3B >=3B>=3B Subject: [M3d= >evel] files larger than 2gig
>=3B >=3B>=3B
>=3B >=3B>=3B<= >BR>>=3B >=3B>=3B C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3>>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B TYPE
= >>=3B >=3B>=3B Status =3D RECORD
>=3B >=3B>=3B type: Type=3B<= >BR>>=3B >=3B>=3B modificationTime: Time.T=3B
>=3B >=3B>=3B s= >ize: INTEGER=3B
>=3B >=3B>=3B END=3B
>=3B >=3B>=3B
>= >=3B >=3B>=3B
>=3B >=3B>=3B size: INTEGER causes exceptions whe= >n you use the Modula-3 gui
>=3B >=3B>=3B and browse to a directory= > with files larger than 2 gig.
>=3B >=3B>=3B
>=3B >=3B>= >=3B
>=3B >=3B>=3B I suggest size be changed to LONGREAL=2C which g= >enerally has a 53 bit mantissa
>=3B >=3B>=3B (out 64 bits total) a= >nd thus can represent integers very much larger than IN
>=3B >=3BTEG= >ER.
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B LO= >NGINT is a tempting option but doesn't help on the current NT386 platform= >=2C
>=3B >=3B>=3B and I think 53 bits will last a very long time.<= >BR>>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B I'm ju= >st trying out such a change and I can see it is not source compatible:
&= >gt=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B "../src/rw= >/FileRd.m3"=2C line 73: incompatible argument types: MIN
>=3B >=3B&g= >t=3B "../src/rw/FileRd.m3"=2C line 140: types are not assignable
>=3B = >>=3B>=3B 2 errors encountered
>=3B >=3B>=3B "../src/rw/FileWr.= >m3"=2C line 87: incompatible argument types: MIN
>=3B >=3B>=3B "..= >/src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX
>=3B = >>=3B>=3B 2 errors encountered
>=3B >=3B>=3B
>=3B >=3B&g= >t=3B
>=3B >=3B>=3B Nevertheless I think it should be done=2C proba= >bly even for this release.
>=3B >=3B>=3B
>=3B >=3B>=3B>>=3B >=3B>=3B - Jay
>= > >--_263ab327-88e7-4d2a-89fb-ad414fed2458_-- From jay.krell at cornell.edu Tue Jun 23 13:27:33 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 23 Jun 2009 11:27:33 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> References: Your message of "Tue, 23 Jun 2009 11:02:26 -0000." <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> Message-ID: Mika, floating point is, for better or worse, deep in Modula-3. I was surprised. The garbage collector uses it. So you'll need software floating point or somesuch. Or maybe you can change the code to use fixed point. Probably not a bad idea. But also Time.T is LONGREAL. Though again, maybe that's dubious. NT has as good time representation. It is 64bit integers, something like measured in 10,000 nanosecond units since 1601. The .NET runtime uses the same unit of precision, but starts at year 0. Time.T splits up easily into Unix seconds + milli or microseconds. Of course, all those 32bit second things are broken. I know the x87 uses 80 bit floating point numbers in hardware, but there is also SSE/SSE2/SSE3/whatever now, that might be different, and faster. You know, they have actual "registers" instead of a register stack. If you have some floating point intensive code, you might try it. More info on the Mosiac-C? I'll search the web. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Tue, 23 Jun 2009 04:20:53 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > Jay, > > Just a few comments... > > I do have some interest in the Modula-3 implementation on the Caltech > Mosaic-C (which has no floating point). M3 has run on this before---I > have an old M3 compiler for it. More in general, M3 is a very nice > language to bring up on new hardware. Requiring the presence of > floating point makes that much more difficult. > > EXTENDED really should not be 64 bits. It should be 80 bits or > perhaps (on some archs) 128 bits. On x86 it should definitely be > 80 bits, since that is the only precision actually supported by > Intel hardware. Not only would the the answers have more bits of > precision but the hardware would actually run faster in many cases! > (Long double is 80 bits under gcc on my FreeBSDs.) > > Finally my understanding is that when M3 was developed, Bill Kahan > sent over one of his grad students to work on the floating point. > That is what all those weird FP interfaces are about. They're not > so much about portability as they are about completeness---from the > point of view of the person developing numerical methods. If you > read Kahan's rants about how FP "should be done" you can see that > the M-3 Float interfaces closely follow the rants. I don't think > they're expected to work on all hardware, only on systems that have > reasonably powerful floating point (IEEE, VAX, System/370?) > > Mika > > > Jay writes: >>--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >>Content-Type: text/plain; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >>Every modern system implements IEEE 754 binary floating point in hardware= >>=2C except maybe for the occasional floating point-less embedded ARM or may= >>be MIPS=2C though even still=2C they tend to support "what I expect" in sof= >>tware (heck=2C just look at Apple's original 6502 and 68000 IEEE 754 softwa= >>re environments "SANE"). >> >> >>=20 >> >>REAL is typically 32 bits. >> >>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >>=2C anything more than 31 bits of mantissa is a win. >> >>EXTENDED is the same as LONGREAL. >> >>=20 >> >>=20 >> >>All you have to do to get an unhandled exception is use the file open gui i= >>n formedit or such and browse to a directory with a large file. It's quite = >>lame. >> >>=20 >> >>=20 >> >>Granted what Olaf said -- works fine on 64 bit platforms. >> >>=20 >> >>=20 >> >>On later thought=2C I'm much less keen on LONGREAL here. LONGINT would stil= >>l be good though. >> >>And then trying to fix NT386 to have a 64bit LONGINT. >> >>=20 >> >>=20 >> >>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >>ntation. Yeah=2C they made a bold statement -- here are our portable interf= >>aces=2C but they weren't available on many platforms. At the same time=2C m= >>ost C systems did document various features=2C usually not very portable=2C= >> but perhaps the building blocks of something portable. >> >>It's just that you have/had to read a lot of documentation=2C test it out= >>=2C etc. Someone has to do it as some level. Nothing is free. >> >>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >>ads standard/implementation catching up.) >> >>=20 >> >>=20 >> >>C is getting better here=2C what with #pragma fenv and such. >> >>And again=2C you could always dig into the system-specific details. >> >>=20 >> >>=20 >> >>The real art that I don't fully understand=2C is how to specify "portable i= >>nterfaces" that you "know" will be viable to implement "everywhere". Just w= >>hat is nearly exactly the same "everywhere" that you know you'll be able to= >> fill in the details later? Maybe it is survey lots of systems?? >> >>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) >> >>=20 >> >>=20 >> >>That is -- really -- we probably should try to implement all that FloatMode= >> stuff. >> >>=20 >> >> >> - Jay >> >> >>=20 >>> To: jay.krell at cornell.edu >>> Date: Tue=2C 23 Jun 2009 02:54:47 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] files larger than 2gig >>>=20 >>>=20 >>> Also=2C making file handling code depend on the presence of IEEE floating >>> point seems rather odd... As far as I know there is nothing in Modula-3 >>> that bans implementing REAL with single precision arithmetic? >>>=20 >>> By the way I think it's sad that Modula-3's wonderful floating-point >>> support has attracted so much bit rot. I think it's better than just >>> about any other programming language (except maybe some Fortran >>> dialects?) >>>=20 >>> Mika >>>=20 >>> Jay writes: >>>> >>>>Hm..I'm not sure. >>>>Integers have certain properties=2C like dividing an integer by an integ= >>er yield >>>>s an integer=2C >>>>that floating point doesn't. Integer division tends toward zero faster t= >>han fl >>>>oating point division. >>>>I can try getting it all to compile with LONGINT maybe instead. >>>>The current behavior is pretty lame. >>>> >>>> - Jay >>>> >>>>---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Mon=2C 22 Jun 2009 12:58:17 +0000 >>>>> Subject: [M3devel] files larger than 2gig >>>>> >>>>> >>>>> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >>>>> >>>>> >>>>> TYPE >>>>> Status =3D RECORD >>>>> type: Type=3B >>>>> modificationTime: Time.T=3B >>>>> size: INTEGER=3B >>>>> END=3B >>>>> >>>>> >>>>> size: INTEGER causes exceptions when you use the Modula-3 gui >>>>> and browse to a directory with files larger than 2 gig. >>>>> >>>>> >>>>> I suggest size be changed to LONGREAL=2C which generally has a 53 bit = >>mantissa >>>>> (out 64 bits total) and thus can represent integers very much larger t= >>han IN >>>>TEGER. >>>>> >>>>> >>>>> LONGINT is a tempting option but doesn't help on the current NT386 pla= >>tform=2C >>>>> and I think 53 bits will last a very long time. >>>>> >>>>> >>>>> I'm just trying out such a change and I can see it is not source compa= >>tible: >>>>> >>>>> >>>>> "../src/rw/FileRd.m3"=2C line 73: incompatible argument types: MIN >>>>> "../src/rw/FileRd.m3"=2C line 140: types are not assignable >>>>> 2 errors encountered >>>>> "../src/rw/FileWr.m3"=2C line 87: incompatible argument types: MIN >>>>> "../src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >>>>> 2 errors encountered >>>>> >>>>> >>>>> Nevertheless I think it should be done=2C probably even for this relea= >>se. >>>>> >>>>> >>>>> - Jay >> >>--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >>Content-Type: text/html; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >>Every modern system implements IEEE 754 binary floating point in hardware= >>=2C except maybe for the occasional floating point-less embedded ARM or may= >>be MIPS=2C though even still=2C they tend to support "what =3BI expect"= >> in software (heck=2C just look at Apple's original 6502 and 68000 IEEE 754= >> software environments "SANE"). >> =3B >>REAL is typically =3B32 bits. >>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >>=2C anything more than 31 bits of mantissa is a win. >>EXTENDED is the same as LONGREAL. >> =3B >> =3B >>All you have to do to get an unhandled exception is use the file open gui i= >>n formedit or such and browse to a directory with a large file. It's quite = >>lame. >> =3B >> =3B >>Granted what Olaf said -- works fine on 64 bit platforms. >> =3B >> =3B >>On later =3Bthought=2C I'm much less keen on LONGREAL here. LONGINT wou= >>ld still be good though. >>And then trying to fix NT386 to have a 64bit LONGINT. >> =3B >> =3B >>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >>ntation. Yeah=2C they made a bold statement -- here are our portable interf= >>aces=2C but they weren't available on many =3Bplatforms. At the same ti= >>me=2C most =3BC systems did document various features=2C usually not ve= >>ry portable=2C but perhaps the building blocks of something portable. >>It's just that you have/had to read a lot of documentation=2C test it out= >>=2C etc. Someone has to do it as some level. Nothing is free. >>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >>ads standard/implementation catching up.) >> =3B >> =3B >>C is getting better here=2C what with #pragma fenv and such. >>And again=2C you could always dig into the system-specific details. >> =3B >> =3B >>The real art that I don't fully understand=2C is how to specify "portable i= >>nterfaces" that you "know" will be viable to implement "everywhere". Just w= >>hat is nearly exactly the same "everywhere" that you know you'll be able to= >> fill in the details later? Maybe it is survey lots of systems?? >>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) >> =3B >> =3B >>That is -- really -- we probably should try to implement all that FloatMode= >> stuff. >> =3B >> =3B- Jay >> =3B >=3B To: jay.krell at cornell.edu >=3B Date: Tue=2C 23 = >>Jun 2009 02:54:47 -0700 >=3B From: mika at async.caltech.edu >=3B CC= >>: m3devel at elegosoft.com >=3B Subject: Re: [M3devel] files larger than = >>2gig >=3B >=3B >=3B Also=2C making file handling code depe= >>nd on the presence of IEEE floating >=3B point seems rather odd... As = >>far as I know there is nothing in Modula-3 >=3B that bans implementing= >> REAL with single precision arithmetic? >=3B >=3B By the way I t= >>hink it's sad that Modula-3's wonderful floating-point >=3B support ha= >>s attracted so much bit rot. I think it's better than just >=3B about = >>any other programming language (except maybe some Fortran >=3B dialect= >>s?) >=3B >=3B Mika >=3B >=3B Jay writes: >=3B &g= >>t=3B >=3B>=3BHm..I'm not sure. >=3B>=3BIntegers have certai= >>n properties=2C like dividing an integer by an integer yield >=3B>= >>=3Bs an integer=2C >=3B>=3Bthat floating point doesn't. Integer div= >>ision tends toward zero faster than fl >=3B>=3Boating point divisio= >>n. >=3B>=3BI can try getting it all to compile with LONGINT maybe i= >>nstead. >=3B>=3BThe current behavior is pretty lame. >=3B>= >>=3B >=3B>=3B - Jay >=3B>=3B >=3B>=3B---------------= >>------------------------- >=3B>=3B>=3B From: jay.krell at cornell.ed= >>u >=3B>=3B>=3B To: m3devel at elegosoft.com >=3B>=3B>=3B D= >>ate: Mon=2C 22 Jun 2009 12:58:17 +0000 >=3B>=3B>=3B Subject: [M3d= >>evel] files larger than 2gig >=3B>=3B>=3B >=3B>=3B>=3B<= >>BR>>=3B>=3B>=3B C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3>>>>=3B>=3B>=3B >=3B>=3B>=3B >=3B>=3B>=3B TYPE = >>>=3B>=3B>=3B Status =3D RECORD >=3B>=3B>=3B type: Type=3B<= >>BR>>=3B>=3B>=3B modificationTime: Time.T=3B >=3B>=3B>=3B s= >>ize: INTEGER=3B >=3B>=3B>=3B END=3B >=3B>=3B>=3B >= >>=3B>=3B>=3B >=3B>=3B>=3B size: INTEGER causes exceptions whe= >>n you use the Modula-3 gui >=3B>=3B>=3B and browse to a directory= >> with files larger than 2 gig. >=3B>=3B>=3B >=3B>=3B>= >>=3B >=3B>=3B>=3B I suggest size be changed to LONGREAL=2C which g= >>enerally has a 53 bit mantissa >=3B>=3B>=3B (out 64 bits total) a= >>nd thus can represent integers very much larger than IN >=3B>=3BTEG= >>ER. >=3B>=3B>=3B >=3B>=3B>=3B >=3B>=3B>=3B LO= >>NGINT is a tempting option but doesn't help on the current NT386 platform= >>=2C >=3B>=3B>=3B and I think 53 bits will last a very long time.<= >>BR>>=3B>=3B>=3B >=3B>=3B>=3B >=3B>=3B>=3B I'm ju= >>st trying out such a change and I can see it is not source compatible: &= >>gt=3B>=3B>=3B >=3B>=3B>=3B >=3B>=3B>=3B "../src/rw= >>/FileRd.m3"=2C line 73: incompatible argument types: MIN >=3B>=3B&g= >>t=3B "../src/rw/FileRd.m3"=2C line 140: types are not assignable >=3B = >>>=3B>=3B 2 errors encountered >=3B>=3B>=3B "../src/rw/FileWr.= >>m3"=2C line 87: incompatible argument types: MIN >=3B>=3B>=3B "..= >>/src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >=3B = >>>=3B>=3B 2 errors encountered >=3B>=3B>=3B >=3B>=3B&g= >>t=3B >=3B>=3B>=3B Nevertheless I think it should be done=2C proba= >>bly even for this release. >=3B>=3B>=3B >=3B>=3B>=3B>>>>=3B>=3B>=3B - Jay >>= >> >>--_263ab327-88e7-4d2a-89fb-ad414fed2458_-- From jay.krell at cornell.edu Tue Jun 23 13:43:11 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 23 Jun 2009 11:43:11 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Your message of "Tue, 23 Jun 2009 11:02:26 -0000." <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> Message-ID: And on that note, here is the status on I386_INTERIX, using a native cm3. :) --- building in I386_INTERIX --- ignoring ../src/m3overrides new source -> compiling SchedulerPosix.i3 Program received signal SIGSEGV, Segmentation fault. 0x00717e52 in ?? () (gdb) bt #0 0x00717e52 in ?? () #1 0x0046e28c in Convert__InternalFromLongFloat () #2 0x0046db4d in Convert__FromExtended () #3 0x004edb03 in M3Buf__PutFloat () #4 0x0062c20a in ReelExpr__GenFPLiteral () #5 0x004991bc in Expr__GenFPLiteral () #6 0x004b5702 in Formal__AddFPTag () #7 0x006f4983 in Value__AddFPTag () #8 0x005cc021 in ProcType__FPrinter () #9 0x006e801a in TypeFP__Visit_SCC () #10 0x006e7daa in TypeFP__FromType () #11 0x006e299d in Type__GlobalUID () #12 0x006eb0a9 in TypeTbl__Put () #13 0x006e2bb5 in Type__Compile () #14 0x006e2b1f in Type__CompileAll () #15 0x0057192f in Module__Compile () #16 0x00527171 in M3Front__DoCompile () #17 0x005266a4 in M3Front__Compile () #18 0x0042cd62 in Builder__RunM3 () #19 0x0042b2a9 in Builder__PushOneM3 () #20 0x0042ae8e in Builder__CompileM3 () #21 0x00429916 in Builder__CompileOne () #22 0x004295b1 in Builder__CompileEverything () #23 0x004254ef in Builder__CompileUnits () #24 0x00423c0e in Builder__BuildLib () #25 0x004f4ac6 in M3Build__DoLibrary () #26 0x005dc1cf in QMachine__DoCall () #27 0x005db078 in QMachine__Eval () #28 0x005e3bad in QMachine () #29 0x005e39e5 in QMachine () #30 0x004f1296 in M3Build () #31 0x004f2da5 in M3Build__DoIncludeDir () #32 0x005dc1cf in QMachine__DoCall () #33 0x005db078 in QMachine__Eval () #34 0x005d9895 in QMachine__Evaluate () #35 0x005f1d8e in Quake__Run () #36 0x004ef4d6 in M3Build__Run () #37 0x0055c172 in Main__DoIt () - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > Date: Tue, 23 Jun 2009 11:27:33 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > > Mika, floating point is, for better or worse, deep in Modula-3. > I was surprised. The garbage collector uses it. > So you'll need software floating point or somesuch. > Or maybe you can change the code to use fixed point. > Probably not a bad idea. > > > But also Time.T is LONGREAL. > Though again, maybe that's dubious. > NT has as good time representation. > It is 64bit integers, something like measured in 10,000 nanosecond > units since 1601. > The .NET runtime uses the same unit of precision, but starts at year 0. > > Time.T splits up easily into Unix seconds + milli or microseconds. > Of course, all those 32bit second things are broken. > > > I know the x87 uses 80 bit floating point numbers in hardware, > but there is also SSE/SSE2/SSE3/whatever now, that might be > different, and faster. > You know, they have actual "registers" instead of a register stack. > If you have some floating point intensive code, you might try it. > > > More info on the Mosiac-C? > I'll search the web. > > - Jay > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Tue, 23 Jun 2009 04:20:53 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] files larger than 2gig >> >> Jay, >> >> Just a few comments... >> >> I do have some interest in the Modula-3 implementation on the Caltech >> Mosaic-C (which has no floating point). M3 has run on this before---I >> have an old M3 compiler for it. More in general, M3 is a very nice >> language to bring up on new hardware. Requiring the presence of >> floating point makes that much more difficult. >> >> EXTENDED really should not be 64 bits. It should be 80 bits or >> perhaps (on some archs) 128 bits. On x86 it should definitely be >> 80 bits, since that is the only precision actually supported by >> Intel hardware. Not only would the the answers have more bits of >> precision but the hardware would actually run faster in many cases! >> (Long double is 80 bits under gcc on my FreeBSDs.) >> >> Finally my understanding is that when M3 was developed, Bill Kahan >> sent over one of his grad students to work on the floating point. >> That is what all those weird FP interfaces are about. They're not >> so much about portability as they are about completeness---from the >> point of view of the person developing numerical methods. If you >> read Kahan's rants about how FP "should be done" you can see that >> the M-3 Float interfaces closely follow the rants. I don't think >> they're expected to work on all hardware, only on systems that have >> reasonably powerful floating point (IEEE, VAX, System/370?) >> >> Mika >> >> >> Jay writes: >>>--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >>>Content-Type: text/plain; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>>Every modern system implements IEEE 754 binary floating point in hardware= >>>=2C except maybe for the occasional floating point-less embedded ARM or may= >>>be MIPS=2C though even still=2C they tend to support "what I expect" in sof= >>>tware (heck=2C just look at Apple's original 6502 and 68000 IEEE 754 softwa= >>>re environments "SANE"). >>> >>> >>>=20 >>> >>>REAL is typically 32 bits. >>> >>>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >>>=2C anything more than 31 bits of mantissa is a win. >>> >>>EXTENDED is the same as LONGREAL. >>> >>>=20 >>> >>>=20 >>> >>>All you have to do to get an unhandled exception is use the file open gui i= >>>n formedit or such and browse to a directory with a large file. It's quite = >>>lame. >>> >>>=20 >>> >>>=20 >>> >>>Granted what Olaf said -- works fine on 64 bit platforms. >>> >>>=20 >>> >>>=20 >>> >>>On later thought=2C I'm much less keen on LONGREAL here. LONGINT would stil= >>>l be good though. >>> >>>And then trying to fix NT386 to have a 64bit LONGINT. >>> >>>=20 >>> >>>=20 >>> >>>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >>>ntation. Yeah=2C they made a bold statement -- here are our portable interf= >>>aces=2C but they weren't available on many platforms. At the same time=2C m= >>>ost C systems did document various features=2C usually not very portable=2C= >>> but perhaps the building blocks of something portable. >>> >>>It's just that you have/had to read a lot of documentation=2C test it out= >>>=2C etc. Someone has to do it as some level. Nothing is free. >>> >>>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >>>ads standard/implementation catching up.) >>> >>>=20 >>> >>>=20 >>> >>>C is getting better here=2C what with #pragma fenv and such. >>> >>>And again=2C you could always dig into the system-specific details. >>> >>>=20 >>> >>>=20 >>> >>>The real art that I don't fully understand=2C is how to specify "portable i= >>>nterfaces" that you "know" will be viable to implement "everywhere". Just w= >>>hat is nearly exactly the same "everywhere" that you know you'll be able to= >>> fill in the details later? Maybe it is survey lots of systems?? >>> >>>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >>>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >>>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >>>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) >>> >>>=20 >>> >>>=20 >>> >>>That is -- really -- we probably should try to implement all that FloatMode= >>> stuff. >>> >>>=20 >>> >>> >>> - Jay >>> >>> >>>=20 >>>> To: jay.krell at cornell.edu >>>> Date: Tue=2C 23 Jun 2009 02:54:47 -0700 >>>> From: mika at async.caltech.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] files larger than 2gig >>>>=20 >>>>=20 >>>> Also=2C making file handling code depend on the presence of IEEE floating >>>> point seems rather odd... As far as I know there is nothing in Modula-3 >>>> that bans implementing REAL with single precision arithmetic? >>>>=20 >>>> By the way I think it's sad that Modula-3's wonderful floating-point >>>> support has attracted so much bit rot. I think it's better than just >>>> about any other programming language (except maybe some Fortran >>>> dialects?) >>>>=20 >>>> Mika >>>>=20 >>>> Jay writes: >>>>> >>>>>Hm..I'm not sure. >>>>>Integers have certain properties=2C like dividing an integer by an integ= >>>er yield >>>>>s an integer=2C >>>>>that floating point doesn't. Integer division tends toward zero faster t= >>>han fl >>>>>oating point division. >>>>>I can try getting it all to compile with LONGINT maybe instead. >>>>>The current behavior is pretty lame. >>>>> >>>>> - Jay >>>>> >>>>>---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: m3devel at elegosoft.com >>>>>> Date: Mon=2C 22 Jun 2009 12:58:17 +0000 >>>>>> Subject: [M3devel] files larger than 2gig >>>>>> >>>>>> >>>>>> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >>>>>> >>>>>> >>>>>> TYPE >>>>>> Status =3D RECORD >>>>>> type: Type=3B >>>>>> modificationTime: Time.T=3B >>>>>> size: INTEGER=3B >>>>>> END=3B >>>>>> >>>>>> >>>>>> size: INTEGER causes exceptions when you use the Modula-3 gui >>>>>> and browse to a directory with files larger than 2 gig. >>>>>> >>>>>> >>>>>> I suggest size be changed to LONGREAL=2C which generally has a 53 bit = >>>mantissa >>>>>> (out 64 bits total) and thus can represent integers very much larger t= >>>han IN >>>>>TEGER. >>>>>> >>>>>> >>>>>> LONGINT is a tempting option but doesn't help on the current NT386 pla= >>>tform=2C >>>>>> and I think 53 bits will last a very long time. >>>>>> >>>>>> >>>>>> I'm just trying out such a change and I can see it is not source compa= >>>tible: >>>>>> >>>>>> >>>>>> "../src/rw/FileRd.m3"=2C line 73: incompatible argument types: MIN >>>>>> "../src/rw/FileRd.m3"=2C line 140: types are not assignable >>>>>> 2 errors encountered >>>>>> "../src/rw/FileWr.m3"=2C line 87: incompatible argument types: MIN >>>>>> "../src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >>>>>> 2 errors encountered >>>>>> >>>>>> >>>>>> Nevertheless I think it should be done=2C probably even for this relea= >>>se. >>>>>> >>>>>> >>>>>> - Jay >>> >>>--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >>>Content-Type: text/html; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>> >>> > > >>> >>> >>>Every modern system implements IEEE 754 binary floating point in hardware= >>>=2C except maybe for the occasional floating point-less embedded ARM or may= >>>be MIPS=2C though even still=2C they tend to support "what =3BI expect"= >>> in software (heck=2C just look at Apple's original 6502 and 68000 IEEE 754= >>> software environments "SANE"). > > >>> =3B > >>>REAL is typically =3B32 bits. > >>>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >>>=2C anything more than 31 bits of mantissa is a win. > >>>EXTENDED is the same as LONGREAL. > >>> =3B > >>> =3B > >>>All you have to do to get an unhandled exception is use the file open gui i= >>>n formedit or such and browse to a directory with a large file. It's quite = >>>lame. > >>> =3B > >>> =3B > >>>Granted what Olaf said -- works fine on 64 bit platforms. > >>> =3B > >>> =3B > >>>On later =3Bthought=2C I'm much less keen on LONGREAL here. LONGINT wou= >>>ld still be good though. > >>>And then trying to fix NT386 to have a 64bit LONGINT. > >>> =3B > >>> =3B > >>>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >>>ntation. Yeah=2C they made a bold statement -- here are our portable interf= >>>aces=2C but they weren't available on many =3Bplatforms. At the same ti= >>>me=2C most =3BC systems did document various features=2C usually not ve= >>>ry portable=2C but perhaps the building blocks of something portable. > >>>It's just that you have/had to read a lot of documentation=2C test it out= >>>=2C etc. Someone has to do it as some level. Nothing is free. > >>>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >>>ads standard/implementation catching up.) > >>> =3B > >>> =3B > >>>C is getting better here=2C what with #pragma fenv and such. > >>>And again=2C you could always dig into the system-specific details. > >>> =3B > >>> =3B > >>>The real art that I don't fully understand=2C is how to specify "portable i= >>>nterfaces" that you "know" will be viable to implement "everywhere". Just w= >>>hat is nearly exactly the same "everywhere" that you know you'll be able to= >>> fill in the details later? Maybe it is survey lots of systems?? > >>>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >>>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >>>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >>>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) > >>> =3B > >>> =3B > >>>That is -- really -- we probably should try to implement all that FloatMode= >>> stuff. > >>> =3B > >>> > =3B- Jay > >>> > =3B >>=3B To: jay.krell at cornell.edu >>=3B Date: Tue=2C 23 = >>>Jun 2009 02:54:47 -0700 >>=3B From: mika at async.caltech.edu >>=3B CC= >>>: m3devel at elegosoft.com >>=3B Subject: Re: [M3devel] files larger than = >>>2gig >>=3B >>=3B >>=3B Also=2C making file handling code depe= >>>nd on the presence of IEEE floating >>=3B point seems rather odd... As = >>>far as I know there is nothing in Modula-3 >>=3B that bans implementing= >>> REAL with single precision arithmetic? >>=3B >>=3B By the way I t= >>>hink it's sad that Modula-3's wonderful floating-point >>=3B support ha= >>>s attracted so much bit rot. I think it's better than just >>=3B about = >>>any other programming language (except maybe some Fortran >>=3B dialect= >>>s?) >>=3B >>=3B Mika >>=3B >>=3B Jay writes: >>=3B &g= >>>t=3B >>=3B>=3BHm..I'm not sure. >>=3B>=3BIntegers have certai= >>>n properties=2C like dividing an integer by an integer yield >>=3B>= >>>=3Bs an integer=2C >>=3B>=3Bthat floating point doesn't. Integer div= >>>ision tends toward zero faster than fl >>=3B>=3Boating point divisio= >>>n. >>=3B>=3BI can try getting it all to compile with LONGINT maybe i= >>>nstead. >>=3B>=3BThe current behavior is pretty lame. >>=3B>= >>>=3B >>=3B>=3B - Jay >>=3B>=3B >>=3B>=3B---------------= >>>------------------------- >>=3B>=3B>=3B From: jay.krell at cornell.ed= >>>u >>=3B>=3B>=3B To: m3devel at elegosoft.com >>=3B>=3B>=3B D= >>>ate: Mon=2C 22 Jun 2009 12:58:17 +0000 >>=3B>=3B>=3B Subject: [M3d= >>>evel] files larger than 2gig >>=3B>=3B>=3B >>=3B>=3B>=3B<= >>>BR>>=3B>=3B>=3B C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3>>>>=3B>=3B>=3B >>=3B>=3B>=3B >>=3B>=3B>=3B TYPE > = >>>>=3B>=3B>=3B Status =3D RECORD >>=3B>=3B>=3B type: Type=3B<= >>>BR>>=3B>=3B>=3B modificationTime: Time.T=3B >>=3B>=3B>=3B s= >>>ize: INTEGER=3B >>=3B>=3B>=3B END=3B >>=3B>=3B>=3B >>= >>>=3B>=3B>=3B >>=3B>=3B>=3B size: INTEGER causes exceptions whe= >>>n you use the Modula-3 gui >>=3B>=3B>=3B and browse to a directory= >>> with files larger than 2 gig. >>=3B>=3B>=3B >>=3B>=3B>= >>>=3B >>=3B>=3B>=3B I suggest size be changed to LONGREAL=2C which g= >>>enerally has a 53 bit mantissa >>=3B>=3B>=3B (out 64 bits total) a= >>>nd thus can represent integers very much larger than IN >>=3B>=3BTEG= >>>ER. >>=3B>=3B>=3B >>=3B>=3B>=3B >>=3B>=3B>=3B LO= >>>NGINT is a tempting option but doesn't help on the current NT386 platform= >>>=2C >>=3B>=3B>=3B and I think 53 bits will last a very long time.<= >>>BR>>=3B>=3B>=3B >>=3B>=3B>=3B >>=3B>=3B>=3B I'm ju= >>>st trying out such a change and I can see it is not source compatible: > &= >>>gt=3B>=3B>=3B >>=3B>=3B>=3B >>=3B>=3B>=3B "../src/rw= >>>/FileRd.m3"=2C line 73: incompatible argument types: MIN >>=3B>=3B&g= >>>t=3B "../src/rw/FileRd.m3"=2C line 140: types are not assignable >>=3B = >>>>=3B>=3B 2 errors encountered >>=3B>=3B>=3B "../src/rw/FileWr.= >>>m3"=2C line 87: incompatible argument types: MIN >>=3B>=3B>=3B "..= >>>/src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >>=3B = >>>>=3B>=3B 2 errors encountered >>=3B>=3B>=3B >>=3B>=3B&g= >>>t=3B >>=3B>=3B>=3B Nevertheless I think it should be done=2C proba= >>>bly even for this release. >>=3B>=3B>=3B >>=3B>=3B>=3B>>>>=3B>=3B>=3B - Jay > >>>= >>> >>>--_263ab327-88e7-4d2a-89fb-ad414fed2458_-- From jay.krell at cornell.edu Wed Jun 24 02:45:56 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 24 Jun 2009 00:45:56 +0000 Subject: [M3devel] permissions on make-dist.sh? Message-ID: C:\dev2\cm3.2\scripts>cvs -z3 commit -m "fewer packages for Interix until/unless X issue is fixed, and cvsup uses utimes; fix name of birch dot instead of perio d" make-dist.sh /usr/cvs/cm3/scripts/make-dist.sh,v <-- make-dist.sh new revision: 1.13; previous revision: 1.12 cvs [commit aborted]: cannot rename file .new.make-dist.sh to make-dist.sh: Perm ission denied fyi: diff -u -r1.12 make-dist.sh --- make-dist.sh 20 Jun 2009 19:23:31 -0000 1.12 +++ make-dist.sh 24 Jun 2009 00:45:14 -0000 @@ -1,7 +1,7 @@ #bash # $Id: make-dist.sh,v 1.12 2009-06-20 19:23:31 jkrell Exp $ -DESTHOST=${DESTHOST:-birch,elegosoft.com} +DESTHOST=${DESTHOST:-birch.elegosoft.com} if [ -n "$ROOT" -a -d "$ROOT" ] ; then sysinfo="$ROOT/scripts/sysinfo.sh" @@ -40,7 +40,12 @@ M3_PORTABLE_RUN_PATH=1 export M3_PORTABLE_RUN_PATH -PKG_COLLECTIONS="devlib m3devtool m3gdb webdev gui anim database cvsup obliq ju no caltech-parser demo tool math game core" + +if [ `uname` = 'Interix' ]; then + PKG_COLLECTIONS="devlib m3devtool webdev obliq caltech-parser tool math game core" +else + PKG_COLLECTIONS="devlib m3devtool m3gdb webdev gui anim database cvsup obliq juno caltech-parser demo tool math game core" +fi DESC_devlib=' Miscellaneous development libraries From jay.krell at cornell.edu Wed Jun 24 03:09:45 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 24 Jun 2009 01:09:45 +0000 Subject: [M3devel] posixish environment on Windows Message-ID: People who want to use cygwin might look into Interix/SFU/SUA instead. It is a free "beer" download for Windows 2000, XP, 2003 and is included as an optional part of 2003R2, Vista, 2008, Win7. It uses the forward slashes people like. It includes gcc. 3.3 and sort of 4.2. (some versions have both, but I think 3.3 is always the default) You can also use Visual C++ with it but I haven't tried that. It includes ksh. bash and many other GNU tools are available. It includes gdb. There is a Visual Studio debugger addin, I also haven't tried that. Most importantly I think, it has an appropriately fast fork, which makes development much faster. Version 3.5 and newer support pthreads. It has .so files, including -rpath. Though maybe not -soname. It doesn't appear to support dlopen/dlsym. I have to check. These last two points are surprising. It appears to not use regular Windows static imports, link -dump -imports doesn't show much. It has an X Window client. For Modula-3 purposes, I get a few unresolved symbols building the GUI stuff, XShm*, so that isn't available (yet?). It has mixed support from various projects. Modula-3 seems to work ok on it, enough to build itself. Hm, the tests have problems, I'll look into that. There are archives on www.opencm3.net/releng. More are being uploaded. - Jay From jay.krell at cornell.edu Wed Jun 24 04:39:35 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 23 Jun 2009 19:39:35 -0700 Subject: [M3devel] X11 in system_libs? In-Reply-To: <20090623144303.F1B6ECC362@birch.elegosoft.com> References: <20090623144303.F1B6ECC362@birch.elegosoft.com> Message-ID: Should a bunch of packages check if ostype is win32 or x11 is in system_libs, else build nothing? - Jay (phone) On Jun 23, 2009, at 4:43 PM, jkrell at elego.de (Jay Krell) wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/06/23 16:43:03 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: I386_INTERIX > > Log message: > remove postgres, odbc, and x11 from SYSTEM_LIBS > at least for postgres and odbc, this causes packages that > use them to "play nice" and build nothing > no such luck for x11 though > > From mika at async.caltech.edu Wed Jun 24 06:34:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 23 Jun 2009 21:34:18 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: Your message of "Tue, 23 Jun 2009 11:27:33 -0000." Message-ID: <200906240434.n5O4YIfX017194@camembert.async.caltech.edu> Jay writes: > ... >I know the x87 uses 80 bit floating point numbers in hardware, >but there is also SSE/SSE2/SSE3/whatever now, that might be >different, and faster. >You know, they have actual "registers" instead of a register stack. >If you have some floating point intensive code, you might try it. > ... I've used SSEn using ifort (Intel Fortran), linking it with Modula-3, quite a bit. Works great. But it has two problems: it is mostly (entirely?) single-precision, and it's not portable, as in, you can compile a binary on one machine and then not run it on another machine that has the same OS and "architecture", e.g., "FreeBSD 5.5 / i386". Really annoying. > >More info on the Mosiac-C? >I'll search the web. > It's old. Well that's why there's a working m3 compiler :-) http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.6294 Mika From wagner at elegosoft.com Wed Jun 24 10:43:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 24 Jun 2009 10:43:27 +0200 Subject: [M3devel] X11 in system_libs? In-Reply-To: References: <20090623144303.F1B6ECC362@birch.elegosoft.com> Message-ID: <20090624104327.2e202q4lwk4ssg4c@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > Should a bunch of packages check if ostype is win32 or x11 is in > system_libs, else build nothing? I wouldn't mind if certain packages check their prerequisites and faile nicely to build if they aren't met, e.g. missing DB or X support. Olaf > - Jay (phone) > > On Jun 23, 2009, at 4:43 PM, jkrell at elego.de (Jay Krell) wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 09/06/23 16:43:03 >> >> Modified files: >> cm3/m3-sys/cminstall/src/config-no-install/: I386_INTERIX >> >> Log message: >> remove postgres, odbc, and x11 from SYSTEM_LIBS >> at least for postgres and odbc, this causes packages that >> use them to "play nice" and build nothing >> no such luck for x11 though >> >> -- 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 Jun 24 04:43:15 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 23 Jun 2009 19:43:15 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Your message of "Tue, 23 Jun 2009 11:02:26 -0000." <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> Message-ID: This is fixed, apparently gcc -fPIC there generates bad code for switch statements...this in C not Modula-3/m3cg. - Jay (phone) On Jun 23, 2009, at 4:43 AM, Jay wrote: > > And on that note, here is the status on I386_INTERIX, using a native > cm3. :) > > > --- building in I386_INTERIX --- > ignoring ../src/m3overrides > new source -> compiling SchedulerPosix.i3 > Program received signal SIGSEGV, Segmentation fault. > 0x00717e52 in ?? () > (gdb) bt > #0 0x00717e52 in ?? () > #1 0x0046e28c in Convert__InternalFromLongFloat () > #2 0x0046db4d in Convert__FromExtended () > #3 0x004edb03 in M3Buf__PutFloat () > #4 0x0062c20a in ReelExpr__GenFPLiteral () > #5 0x004991bc in Expr__GenFPLiteral () > #6 0x004b5702 in Formal__AddFPTag () > #7 0x006f4983 in Value__AddFPTag () > #8 0x005cc021 in ProcType__FPrinter () > #9 0x006e801a in TypeFP__Visit_SCC () > #10 0x006e7daa in TypeFP__FromType () > #11 0x006e299d in Type__GlobalUID () > #12 0x006eb0a9 in TypeTbl__Put () > #13 0x006e2bb5 in Type__Compile () > #14 0x006e2b1f in Type__CompileAll () > #15 0x0057192f in Module__Compile () > #16 0x00527171 in M3Front__DoCompile () > #17 0x005266a4 in M3Front__Compile () > #18 0x0042cd62 in Builder__RunM3 () > #19 0x0042b2a9 in Builder__PushOneM3 () > #20 0x0042ae8e in Builder__CompileM3 () > #21 0x00429916 in Builder__CompileOne () > #22 0x004295b1 in Builder__CompileEverything () > #23 0x004254ef in Builder__CompileUnits () > #24 0x00423c0e in Builder__BuildLib () > #25 0x004f4ac6 in M3Build__DoLibrary () > #26 0x005dc1cf in QMachine__DoCall () > #27 0x005db078 in QMachine__Eval () > #28 0x005e3bad in QMachine () > From rodney.m.bates at cox.net Wed Jun 24 18:18:30 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 24 Jun 2009 11:18:30 -0500 Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress Message-ID: <4A4251D6.60804@cox.net> I have tracked down the problems I have seen with m3gdb on AMD64_LINUX not recognizing object formats to a new section type SHT_GNU_HASH, (and named .gnu.hash), which is present in recent M3-compiled code. It appears to be handled by the more recent binutils that comes in gdb 6.8, but it is not handled by the binutils in gdb 6.4, from which m3gdb is derived. I briefly tried a naive substitution of the new binutils (directory 'bfd') into m3gdb, but some things have moved around and there are build problems finding them. I will work on this more when I get some time. Rodney Bates From jay.krell at cornell.edu Wed Jun 24 19:13:11 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 24 Jun 2009 17:13:11 +0000 Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress In-Reply-To: <4A4251D6.60804@cox.net> References: <4A4251D6.60804@cox.net> Message-ID: You should try using cvs import to upgrade to a newer version, of the entire gdb tree (well, maybe prune it -- testsuites, sim, cpu, intl, etc..) I personally have never done this -- only recently imported the first version of stuff but haven't yet updated anything. - Jay > Date: Wed, 24 Jun 2009 11:18:30 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress > > I have tracked down the problems I have seen with m3gdb on > AMD64_LINUX not recognizing object formats to a new section > type SHT_GNU_HASH, (and named .gnu.hash), which is present > in recent M3-compiled code. It appears to be handled by > the more recent binutils that comes in gdb 6.8, but it is > not handled by the binutils in gdb 6.4, from which m3gdb is > derived. > > I briefly tried a naive substitution of the new binutils > (directory 'bfd') into m3gdb, but some things have moved > around and there are build problems finding them. I will > work on this more when I get some time. > > Rodney Bates -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jun 25 01:10:05 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 24 Jun 2009 19:10:05 -0400 Subject: [M3devel] files larger than 2gig In-Reply-To: References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> Message-ID: <20090624231005.GA32180@topoi.pooq.com> On Mon, Jun 22, 2009 at 12:58:45PM -0400, Tony Hosking wrote: > > Yuck. Why not decompose in the backend? However we do it, large files should "just work" on systems that can handle them. -- hendrik From hendrik at topoi.pooq.com Thu Jun 25 02:06:40 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 24 Jun 2009 20:06:40 -0400 Subject: [M3devel] XML? In-Reply-To: <20090508025825.GC418@topoi.pooq.com> References: <20090507220142.GA32564@topoi.pooq.com> <367599.3562.qm@web24708.mail.ird.yahoo.com> <20090508025825.GC418@topoi.pooq.com> Message-ID: <20090625000640.GB32180@topoi.pooq.com> On Thu, May 07, 2009 at 10:58:25PM -0400, hendrik at topoi.pooq.com wrote: > 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. Looked further. The originally PM3 parser looked way more conplicated than necessary, which I attributed to haveing powerful tools available and showing the off. I decided to do somehting simpler, and XML parsing is a *lot* simpler than that. But I got curious and looked at SGML. (After all, some of the stuff I have to process isn't XML at all, but just plain formatted ASCII text with a few tags in it to indicate italics (where some would use *asterisks*)). And I discovered the following. Superficially, SGML has tags like

which match

. Lots of brackets which have to match up. Kind of like XML. It even has a Data Type Definition like XML's. (In fact XML copied the DTD from SGML for compatibility.) The DTD is obviously useful to screen incoming texts to make sure they satisfy a structural specification demanded by an application. Here the similarity ends. It turns out that in SGML you can leave out tags -- starters or enders, or even *both*, as long as that does not cause ambiguity. And *ambiguity* s interpreted in the context of a DTD, which specifies the grammar of the SGML file. This effectively convert a recursive tree walk into a parsing problem. The need for a DTD effectively means that you have to run a parser generator on DTD before you can start with the actual text. That bit of code from pm3 was pulling out all the heavy tools because it couldn't manage without them! Apparently the world abound in SGML processors readers that get details wrong, perhaps because they don't go about it with enough sophistication. Writing an SGML parser is a significant intellectual effort. Writing an XML parser (without enforcing strict conformance on the parsed documents) is, by comparison, is like falling off a log. -- hendrik From hendrik at topoi.pooq.com Thu Jun 25 15:42:33 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 25 Jun 2009 09:42:33 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618134334.njcom4fusg0ccsws@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Message-ID: <20090625134233.GA1722@topoi.pooq.com> On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >Is it time for me to make another try at installing cm3 from scratch? > >In particular, do you think most of the problems I reported with > >documentation and archives, etc., have been solved? I really want to > >get m3 working on this laptop, but I also want to provide the most > >useful problem reports. > > > >I'm definitely trying to act like a naive user in these installation > >attempts (which means I'm trying to act stupider than I am). > > I've now put some initial release engineering documentation onto > birch, available at > > http://www.opencm3.net/releng Well, I started with that page, assuming that it will be the one Google finds when the release is finally out. I'm continuing to act like a naive user (but I'm probably not naive enough to give the instructions a real test). It seems to have installed, but I'm not sure, because the installer ended with an error message. Here are the gory details. Started from http://www.opencm3.net/releng/ I found the description quite clear. It's still not clear just what packages are in cm3-core and not in cm3-min or why I would want them, but it was clear I wanted to start with cm3-core. For example, is there a UI library in cm3-core? (Oh why is it so hard to cut and paste from the web page to this emacs buffer on my laptop?) cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A beginner with Linux might have difficulty knowing whether to use the .lzma version. Ah! I clicked on the "standard, recommended" link (I hadn't realised it was a link) and found the list of what packages are in the .tgz file. One layout comment -- it consists of a series of sections, each starting with a title and ending with a browse-sources link. Each title needs to look more prominent than the text or the link. At the moment, the link is what stands out. More blank lines between the entries then within them would make them group better. Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz Again, that worked. I do find myseelf wondering it that would be the correct command line if I were uzinng Winzip on Windows, though. (that's wha tthe insstruction seems to say) Next I run ./cminstall /usr/local/cm3 It asks mme whether /home.hendrik/cm3 is to be the root directory for cm3. The naive user doesn't know what that means. Nor do I, for that matter. I'm guessing that it's where to unpack and work during installation, but that it won't be needed later. That I can even deleete the entire /home/hendrik/cm3 directory tree after installation. That in fact when I instll packages later I can download them to, say, /anywhere and install them from /anywhere and they'll still get installed in the proper place. But I don't know. For now, I'll just accept the defaults. Next problem: > Installing CM3 in: /usr/local/cm3 > This may take a few minutes... > > Unexpected problem: cannot list current directory: errno=2 > > Please feel free to contact m3-support at elego.de to troubleshoot this problem. Current directory? That's an uninformative message. Possibly it refers to /usr/local/cm3? Which really doesn't exit yet? Should your instructions say to create it and make sure it has the right write permissions? Noooo. that's not the reason. /usr/local/cm3 has been created. And populated with lots of subdirectories. /usr/local/cm3/bin contains a few executables and lots of other files. It turns out I did have permission to write on /usr/local. I don't know what directory it's referring to. What next? -- hendrik From wagner at elegosoft.com Thu Jun 25 18:52:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 25 Jun 2009 18:52:06 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625134233.GA1722@topoi.pooq.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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> Message-ID: <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: >> Quoting hendrik at topoi.pooq.com: >> >> >Is it time for me to make another try at installing cm3 from scratch? >> >In particular, do you think most of the problems I reported with >> >documentation and archives, etc., have been solved? I really want to >> >get m3 working on this laptop, but I also want to provide the most >> >useful problem reports. >> > >> >I'm definitely trying to act like a naive user in these installation >> >attempts (which means I'm trying to act stupider than I am). >> >> I've now put some initial release engineering documentation onto >> birch, available at >> >> http://www.opencm3.net/releng > > Well, I started with that page, assuming that it will be the one Google > finds when the release is finally out. I'm continuing to act like a > naive user (but I'm probably not naive enough to give the instructions a > real test). > > It seems to have installed, but I'm not sure, because the installer > ended with an error message. Here are the gory details. > > Started from http://www.opencm3.net/releng/ > > I found the description quite clear. It's still not clear just what > packages are in cm3-core and not in cm3-min or why I would want them, > but it was clear I wanted to start with cm3-core. For example, is there > a UI library in cm3-core? > > (Oh why is it so hard to cut and paste from the web page to this emacs > buffer on my laptop?) > cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A > beginner with Linux might have difficulty knowing whether to use the > .lzma version. LINUXLIBC6 along with all lmza archives were created by Jay; I'd rather have limited the available formats. Of course this needs to be documented if we provide .lzma files. > Ah! I clicked on the "standard, recommended" link (I hadn't realised it > was a link) and found the list of what packages are in the .tgz file. > One layout comment -- it consists of a series of sections, each starting > with a title and ending with a browse-sources link. Each title needs to > look more prominent than the text or the link. At the moment, the link > is what stands out. More blank lines between the entries then within > them would make them group better. > > Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz > > Again, that worked. I do find myseelf wondering it that would be the > correct command line if I were uzinng Winzip on Windows, though. > (that's wha tthe insstruction seems to say) No, Winzip of course is a GUI application where you are supposed to point and click with the mouse... > Next I run ./cminstall /usr/local/cm3 > > It asks mme whether /home.hendrik/cm3 is to be the root directory for > cm3. The naive user doesn't know what that means. Nor do I, for that This is strange. cminstall shouldn't ask any questions by default. But as mentioned before, I only built the archives for FreeBSD4 and AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package there? Or am I misunderstanding something here? > matter. I'm guessing that it's where to unpack and work during > installation, but that it won't be needed later. That I can even > deleete the entire /home/hendrik/cm3 directory tree after installation. > That in fact when I instll packages later I can download them to, say, > /anywhere and install them from /anywhere and they'll still get > installed in the proper place. But I don't know. For now, I'll just > accept the defaults. > > Next problem: > >> Installing CM3 in: /usr/local/cm3 >> This may take a few minutes... >> >> Unexpected problem: cannot list current directory: errno=2 I've never seen that. Can you provide the complete installation log? We may also need a system call trace to track this down... >> Please feel free to contact m3-support at elego.de to troubleshoot this > problem. > > Current directory? That's an uninformative message. Possibly it refers > to /usr/local/cm3? Which really doesn't exit yet? Should your > instructions say to create it and make sure it has the right write > permissions? > > Noooo. that's not the reason. /usr/local/cm3 has been created. And > populated with lots of subdirectories. /usr/local/cm3/bin contains a > few executables and lots of other files. It turns out I did have > permission to write on /usr/local. I don't know what directory it's > referring to. Strange. I tried an installation on FreeBSD which succeeded without any problems. > What next? Let's have a look at Install.log and hear what Jay has to say about LINUXLIBC6. Thanks for the feedback, 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 wagner at elegosoft.com Thu Jun 25 19:26:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 25 Jun 2009 19:26:45 +0200 Subject: [M3devel] CM3 Release Engineering Message-ID: <20090625192645.4761owc6s8kk4wko@mail.elegosoft.com> Hi all, in order to start with some serious testing and release engineering, I'd still like to have some more feedback from others, especially on the following topics: o Is the suggested archive set accepted? Should we break up or combine certain archives? Or even provide something much simpler? o Has anybody tested installation of any of these packages? Was it successful? o Has anybody tested Rodney's alternative TEXT implementation? Should we make it the default in this release? o Are there still any known show-stoppers? Crashes, broken functionality etc.? o Should we really provide multiple formats (tar/gzip and lzma)? If we don't need/want to change much, the next steps would be: 1. Some documentation fixes/extensions. 2. Application of an RC1 tag and code freeze (or releng branching; but as said earlier, I'd rather avoid that) 3. Announcement of new release candidates in WWW, news and mailing lists. 4. More extensive installation testing. 5. Fixing of all reported bugs (if there are any ;-) 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 hendrik at topoi.pooq.com Thu Jun 25 19:37:15 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 25 Jun 2009 13:37:15 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625185206.f4lc9vlpckggko4g@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: <20090625173714.GA2324@topoi.pooq.com> On Thu, Jun 25, 2009 at 06:52:06PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: > >> > >>I've now put some initial release engineering documentation onto > >>birch, available at > >> > >> http://www.opencm3.net/releng > > > >Well, I started with that page, assuming that it will be the one Google > >finds when the release is finally out. I'm continuing to act like a > >naive user (but I'm probably not naive enough to give the instructions a > >real test). > > > >It seems to have installed, but I'm not sure, because the installer > >ended with an error message. Here are the gory details. > > > >Started from http://www.opencm3.net/releng/ > > > >I found the description quite clear. It's still not clear just what > >packages are in cm3-core and not in cm3-min or why I would want them, > >but it was clear I wanted to start with cm3-core. For example, is there > >a UI library in cm3-core? > > > >(Oh why is it so hard to cut and paste from the web page to this emacs > >buffer on my laptop?) > > >cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A > >beginner with Linux might have difficulty knowing whether to use the > >.lzma version. > > LINUXLIBC6 along with all lmza archives were created by Jay; > I'd rather have limited the available formats. Of course this needs > to be documented if we provide .lzma files. > > >Ah! I clicked on the "standard, recommended" link (I hadn't realised it > >was a link) and found the list of what packages are in the .tgz file. > >One layout comment -- it consists of a series of sections, each starting > >with a title and ending with a browse-sources link. Each title needs to > >look more prominent than the text or the link. At the moment, the link > >is what stands out. More blank lines between the entries then within > >them would make them group better. > > > >Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz > > > >Again, that worked. I do find myseelf wondering it that would be the > >correct command line if I were uzinng Winzip on Windows, though. > >(that's wha tthe insstruction seems to say) > > No, Winzip of course is a GUI application where you are supposed to > point and click with the mouse... Probably needs rewording. > > >Next I run ./cminstall /usr/local/cm3 > > > >It asks mme whether /home.hendrik/cm3 is to be the root directory for > >cm3. The naive user doesn't know what that means. Nor do I, for that > > This is strange. cminstall shouldn't ask any questions by default. Looking back, it didn't actually ask; it just told me to restart if it was wrong. > But as mentioned before, I only built the archives for FreeBSD4 and > AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package > there? Or am I misunderstanding something here? > > >matter. I'm guessing that it's where to unpack and work during > >installation, but that it won't be needed later. That I can even > >deleete the entire /home/hendrik/cm3 directory tree after installation. > >That in fact when I instll packages later I can download them to, say, > >/anywhere and install them from /anywhere and they'll still get > >installed in the proper place. But I don't know. For now, I'll just > >accept the defaults. > > > >Next problem: > > > >>Installing CM3 in: /usr/local/cm3 > >>This may take a few minutes... > >> > >>Unexpected problem: cannot list current directory: errno=2 > > I've never seen that. Can you provide the complete installation log? > We may also need a system call trace to track this down... > > >>Please feel free to contact m3-support at elego.de to troubleshoot this > >problem. > > > >Current directory? That's an uninformative message. Possibly it refers > >to /usr/local/cm3? Which really doesn't exit yet? Should your > >instructions say to create it and make sure it has the right write > >permissions? > > > >Noooo. that's not the reason. /usr/local/cm3 has been created. And > >populated with lots of subdirectories. /usr/local/cm3/bin contains a > >few executables and lots of other files. It turns out I did have > >permission to write on /usr/local. I don't know what directory it's > >referring to. > > Strange. I tried an installation on FreeBSD which succeeded without > any problems. Evidently there's some directory on FreeBSD that's not so readable in Debian squeeze. What directories is it likely to want to read or write? I could go through them and see if any are missing here. > > >What next? > > Let's have a look at Install.log and hear what Jay has to say about > LINUXLIBC6. cat, cut, and paste into the mailer: hendrik at notlookedfor:~$ cat /usr/local/cm3/Install.log Thank you for using Critical Mass CM3. This program will configure and install the system. cminstall_root is set to /home/hendrik/cm3 If this is not correct, please restart the installer with -root If the installer runs interactively, it will ask you some questions about the locations of programs and libraries. Usually it will display a default inside [], which can be accepted with . If the installer has found several choices, you may cycle through them with `+' or `.' for the next and `-' for the previous one. You may of course also enter a completely different value. Installing CM3 in: /usr/local/cm3 This may take a few minutes... Unexpected problem: cannot list current directory: errno=2 Please feel free to contact m3-support at elego.de to troubleshoot this problem. hendrik at notlookedfor:~$ > > Thanks for the feedback. You're very welcome. For the record, here are a few ls's showing what there *is* now. hendrik at notlookedfor:~$ ls /usr/local bin cm3 etc games include lib man sbin share src stow hendrik at notlookedfor:~$ ls /usr/local/cm3 bin doc elisp examples Install.log lib man pkg hendrik at notlookedfor:~$ ls /usr/local/cm3/*/ /usr/local/cm3/bin/: AMD64_DARWIN Darwin.common m3bundle NT386MINGNU SOLsun AMD64_FREEBSD FreeBSD4 m3cgcat PA32_HPUX SPARC32_LINUX AMD64_LINUX gnuld.common m3cggen PA64_HPUX SPARC64_LINUX ARM_DARWIN HPUX.common MIPS64_OPENBSD PPC32_OPENBSD SPARC64_OPENBSD cm3 I386_DARWIN NetBSD2_i386 PPC_DARWIN SPARC64_SOLARIS cm3.cfg I386_INTERIX NT386 PPC_LINUX Unix.common cm3cfg.common I386_OPENBSD NT386.common Solaris.common cm3cg LINUXLIBC6 NT386GNU SOLgnu /usr/local/cm3/doc/: /usr/local/cm3/elisp/: /usr/local/cm3/examples/: /usr/local/cm3/lib/: libBitVector.so libm3slisp.so libset.so libBitVector.so.5 libm3slisp.so.5 libset.so.5 libDiGraph.so libm3.so libSortedTableExtras.so libDiGraph.so.5 libm3.so.5 libSortedTableExtras.so.5 libGeometry.so libm3tcp.so libsysutils.so libGeometry.so.5 libm3tcp.so.5 libsysutils.so.5 libm3core.so libm3unit.so libtable-list.so libm3core.so.5 libm3unit.so.5 libtable-list.so.5 libm3parseparams.so libpatternmatching.so libTempFiles.so libm3parseparams.so.5 libpatternmatching.so.5 libTempFiles.so.5 /usr/local/cm3/man/: man1 /usr/local/cm3/pkg/: bitvector m3bundle m3linker m3tools slisp tempfiles cm3 m3cgcat m3middle parseparams sortedtableextras unittest digraph m3cggen m3objfile patternmatching sysutils libm3 m3core m3quake realgeometry table-list m3back m3front m3scanner set tcp hendrik at notlookedfor:~$ From jay.krell at cornell.edu Thu Jun 25 22:43:11 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 25 Jun 2009 20:43:11 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625185206.f4lc9vlpckggko4g@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: I just ran ./make-dist.sh. I admit I didn't take the time to test out the archives. lzma I made just via gunzip foo.tgz lzma foo.tar For Interix I cut down the list of collections. It is common for multiple compression formats to be used. lzma often shrinks the files by half, though, oddly, sometimes not at all. lzma admittedly has been superceded xz. I know it is difficult and I'm not helpful here, but we should keep in mind the ideals: apt-get install foo download foo.exe and run it, hit next next next finish download foo.tar.gz, tar xf foo.tar.gz, cd foo, read INSTALL, ./configure, ./make, su, ./make install to measure ourselves by. There's no need for Winzip if we use .zip files, explorer handles them. It is also easy to make self extracting .zip files. And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. - Jay > Date: Thu, 25 Jun 2009 18:52:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > Quoting hendrik at topoi.pooq.com: > > > On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: > >> > >> >Is it time for me to make another try at installing cm3 from scratch? > >> >In particular, do you think most of the problems I reported with > >> >documentation and archives, etc., have been solved? I really want to > >> >get m3 working on this laptop, but I also want to provide the most > >> >useful problem reports. > >> > > >> >I'm definitely trying to act like a naive user in these installation > >> >attempts (which means I'm trying to act stupider than I am). > >> > >> I've now put some initial release engineering documentation onto > >> birch, available at > >> > >> http://www.opencm3.net/releng > > > > Well, I started with that page, assuming that it will be the one Google > > finds when the release is finally out. I'm continuing to act like a > > naive user (but I'm probably not naive enough to give the instructions a > > real test). > > > > It seems to have installed, but I'm not sure, because the installer > > ended with an error message. Here are the gory details. > > > > Started from http://www.opencm3.net/releng/ > > > > I found the description quite clear. It's still not clear just what > > packages are in cm3-core and not in cm3-min or why I would want them, > > but it was clear I wanted to start with cm3-core. For example, is there > > a UI library in cm3-core? > > > > (Oh why is it so hard to cut and paste from the web page to this emacs > > buffer on my laptop?) > > > cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A > > beginner with Linux might have difficulty knowing whether to use the > > .lzma version. > > LINUXLIBC6 along with all lmza archives were created by Jay; > I'd rather have limited the available formats. Of course this needs > to be documented if we provide .lzma files. > > > Ah! I clicked on the "standard, recommended" link (I hadn't realised it > > was a link) and found the list of what packages are in the .tgz file. > > One layout comment -- it consists of a series of sections, each starting > > with a title and ending with a browse-sources link. Each title needs to > > look more prominent than the text or the link. At the moment, the link > > is what stands out. More blank lines between the entries then within > > them would make them group better. > > > > Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz > > > > Again, that worked. I do find myseelf wondering it that would be the > > correct command line if I were uzinng Winzip on Windows, though. > > (that's wha tthe insstruction seems to say) > > No, Winzip of course is a GUI application where you are supposed to > point and click with the mouse... > > > Next I run ./cminstall /usr/local/cm3 > > > > It asks mme whether /home.hendrik/cm3 is to be the root directory for > > cm3. The naive user doesn't know what that means. Nor do I, for that > > This is strange. cminstall shouldn't ask any questions by default. > But as mentioned before, I only built the archives for FreeBSD4 and > AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package > there? Or am I misunderstanding something here? > > > matter. I'm guessing that it's where to unpack and work during > > installation, but that it won't be needed later. That I can even > > deleete the entire /home/hendrik/cm3 directory tree after installation. > > That in fact when I instll packages later I can download them to, say, > > /anywhere and install them from /anywhere and they'll still get > > installed in the proper place. But I don't know. For now, I'll just > > accept the defaults. > > > > Next problem: > > > >> Installing CM3 in: /usr/local/cm3 > >> This may take a few minutes... > >> > >> Unexpected problem: cannot list current directory: errno=2 > > I've never seen that. Can you provide the complete installation log? > We may also need a system call trace to track this down... > > >> Please feel free to contact m3-support at elego.de to troubleshoot this > > problem. > > > > Current directory? That's an uninformative message. Possibly it refers > > to /usr/local/cm3? Which really doesn't exit yet? Should your > > instructions say to create it and make sure it has the right write > > permissions? > > > > Noooo. that's not the reason. /usr/local/cm3 has been created. And > > populated with lots of subdirectories. /usr/local/cm3/bin contains a > > few executables and lots of other files. It turns out I did have > > permission to write on /usr/local. I don't know what directory it's > > referring to. > > Strange. I tried an installation on FreeBSD which succeeded without > any problems. > > > What next? > > Let's have a look at Install.log and hear what Jay has to say about > LINUXLIBC6. > > Thanks for the feedback, > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jun 25 23:27:20 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 25 Jun 2009 17:27:20 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: References: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: <20090625212720.GA2783@topoi.pooq.com> On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: > > I just ran ./make-dist.sh. > I admit I didn't take the time to test out the archives. > lzma I made just via > gunzip foo.tgz > lzma foo.tar No need to apologise. These archives seem to have worked better than the last ones I tried. I'm specifically trying to help you guys make it work by acting like a naive user and reporting what goes wrong or might confuse a naive user. The show-stopper for the naive user in this report was the error message that, as far as I can tell, occurs at the end of installation. If my goal was just to get cm3 working, I'd have accomplished it already, as an experienced user. IN fact, I'm still going to set my $PATH properly to find out if I already have a working cm3 from this installation. The last one I tried a few seeks ago (a version of min) was usable long before I finished the whole installation process. After juat unzipping the archives and cooking up some suitable $PATH entries, I was compiling. But from the instructions I was following, it looked like I had a long way to go yet. Half the problems I'm coming up with are probably infelicities if documentation. Like the 'if' in that sentence that should have been 'of'. > > > For Interix I cut down the list of collections. > > > It is common for multiple compression formats to be used. > lzma often shrinks the files by half, though, oddly, sometimes not at all. > lzma admittedly has been superceded xz. > > > > I know it is difficult and I'm not helpful here, but we should keep in mind the ideals: > > apt-get install foo We still have to get to this point. Only I fink it's cm3 we want, not foo. > > download foo.exe and run it, hit next next next finish > > download foo.tar.gz, tar xf foo.tar.gz, cd foo, read INSTALL, ./configure, ./make, su, ./make install > > > > to measure ourselves by. > > > > There's no need for Winzip if we use .zip files, explorer handles them. That's useful. Unless you're paranoid enough to never let your WIndows machine come near a network. It's an effective way to avoid viruses. > > It is also easy to make self extracting .zip files. > > And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. > > > - Jay > > > > Date: Thu, 25 Jun 2009 18:52:06 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > > > Quoting hendrik at topoi.pooq.com: > > > > > On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: > > >> Quoting hendrik at topoi.pooq.com: > > >> > > >> >Is it time for me to make another try at installing cm3 from scratch? > > >> >In particular, do you think most of the problems I reported with > > >> >documentation and archives, etc., have been solved? I really want to > > >> >get m3 working on this laptop, but I also want to provide the most > > >> >useful problem reports. > > >> > > > >> >I'm definitely trying to act like a naive user in these installation > > >> >attempts (which means I'm trying to act stupider than I am). > > >> > > >> I've now put some initial release engineering documentation onto > > >> birch, available at > > >> > > >> http://www.opencm3.net/releng > > > > > > Well, I started with that page, assuming that it will be the one Google > > > finds when the release is finally out. I'm continuing to act like a > > > naive user (but I'm probably not naive enough to give the instructions a > > > real test). > > > > > > It seems to have installed, but I'm not sure, because the installer > > > ended with an error message. Here are the gory details. > > > > > > Started from http://www.opencm3.net/releng/ > > > > > > I found the description quite clear. It's still not clear just what > > > packages are in cm3-core and not in cm3-min or why I would want them, > > > but it was clear I wanted to start with cm3-core. For example, is there > > > a UI library in cm3-core? > > > > > > (Oh why is it so hard to cut and paste from the web page to this emacs > > > buffer on my laptop?) > > > > > cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A > > > beginner with Linux might have difficulty knowing whether to use the > > > .lzma version. > > > > LINUXLIBC6 along with all lmza archives were created by Jay; > > I'd rather have limited the available formats. Of course this needs > > to be documented if we provide .lzma files. > > > > > Ah! I clicked on the "standard, recommended" link (I hadn't realised it > > > was a link) and found the list of what packages are in the .tgz file. > > > One layout comment -- it consists of a series of sections, each starting > > > with a title and ending with a browse-sources link. Each title needs to > > > look more prominent than the text or the link. At the moment, the link > > > is what stands out. More blank lines between the entries then within > > > them would make them group better. > > > > > > Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz > > > > > > Again, that worked. I do find myseelf wondering it that would be the > > > correct command line if I were uzinng Winzip on Windows, though. > > > (that's wha tthe insstruction seems to say) > > > > No, Winzip of course is a GUI application where you are supposed to > > point and click with the mouse... > > > > > Next I run ./cminstall /usr/local/cm3 > > > > > > It asks mme whether /home.hendrik/cm3 is to be the root directory for > > > cm3. The naive user doesn't know what that means. Nor do I, for that > > > > This is strange. cminstall shouldn't ask any questions by default. > > But as mentioned before, I only built the archives for FreeBSD4 and > > AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package > > there? Or am I misunderstanding something here? > > > > > matter. I'm guessing that it's where to unpack and work during > > > installation, but that it won't be needed later. That I can even > > > deleete the entire /home/hendrik/cm3 directory tree after installation. > > > That in fact when I instll packages later I can download them to, say, > > > /anywhere and install them from /anywhere and they'll still get > > > installed in the proper place. But I don't know. For now, I'll just > > > accept the defaults. > > > > > > Next problem: > > > > > >> Installing CM3 in: /usr/local/cm3 > > >> This may take a few minutes... > > >> > > >> Unexpected problem: cannot list current directory: errno=2 > > > > I've never seen that. Can you provide the complete installation log? > > We may also need a system call trace to track this down... > > > > >> Please feel free to contact m3-support at elego.de to troubleshoot this > > > problem. > > > > > > Current directory? That's an uninformative message. Possibly it refers > > > to /usr/local/cm3? Which really doesn't exit yet? Should your > > > instructions say to create it and make sure it has the right write > > > permissions? > > > > > > Noooo. that's not the reason. /usr/local/cm3 has been created. And > > > populated with lots of subdirectories. /usr/local/cm3/bin contains a > > > few executables and lots of other files. It turns out I did have > > > permission to write on /usr/local. I don't know what directory it's > > > referring to. > > > > Strange. I tried an installation on FreeBSD which succeeded without > > any problems. > > > > > What next? > > > > Let's have a look at Install.log and hear what Jay has to say about > > LINUXLIBC6. > > > > Thanks for the feedback, > > > > 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 Fri Jun 26 01:29:18 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 25 Jun 2009 16:29:18 -0700 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625212720.GA2783@topoi.pooq.com> References: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090625212720.GA2783@topoi.pooq.com> Message-ID: More later but: how about we drop a sh wrapper or symlink in installroot/../bin so $path usually unchanged? And ensure ld_library_path needed on the fewest systems possible. - Jay (phone) On Jun 25, 2009, at 2:27 PM, hendrik at topoi.pooq.com wrote: > On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: >> >> I just ran ./make-dist.sh. >> I admit I didn't take the time to test out the archives. >> lzma I made just via >> gunzip foo.tgz >> lzma foo.tar > > No need to apologise. These archives seem to have worked better than > the last ones I tried. > > I'm specifically trying to help you guys make it work by acting like a > naive user and reporting what goes wrong or might confuse a naive > user. > The show-stopper for the naive user in this report was the error > message > that, as far as I can tell, occurs at the end of installation. > > If my goal was just to get cm3 working, I'd have accomplished it > already, as an experienced user. IN fact, I'm still going to set my > $PATH properly to find out if I already have a working cm3 from this > installation. The last one I tried a few seeks ago (a version of min) > was usable long before I finished the whole installation process. > After > juat unzipping the archives and cooking up some suitable $PATH > entries, > I was compiling. But from the instructions I was following, it looked > like I had a long way to go yet. > > Half the problems I'm coming up with are probably infelicities if > documentation. Like the 'if' in that sentence that should have been > 'of'. > >> >> >> For Interix I cut down the list of collections. >> >> >> It is common for multiple compression formats to be used. >> lzma often shrinks the files by half, though, oddly, sometimes not >> at all. >> lzma admittedly has been superceded xz. >> >> >> >> I know it is difficult and I'm not helpful here, but we should keep >> in mind the ideals: >> >> apt-get install foo > > We still have to get to this point. Only I fink it's cm3 we want, not > foo. > >> >> download foo.exe and run it, hit next next next finish >> >> download foo.tar.gz, tar xf foo.tar.gz, cd foo, read INSTALL, ./ >> configure, ./make, su, ./make install >> >> >> >> to measure ourselves by. >> >> >> >> There's no need for Winzip if we use .zip files, explorer handles >> them. > > That's useful. Unless you're paranoid enough to never let your > WIndows > machine come near a network. It's an effective way to avoid viruses. > >> >> It is also easy to make self extracting .zip files. >> >> And untrusting users can just run unzip on them or rename them >> to .zip and open with Explorer, it's quite nice, except that for >> running, they don't run on many systems. >> >> >> - Jay >> >> >>> Date: Thu, 25 Jun 2009 18:52:06 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: >>> Release engineering) >>> >>> Quoting hendrik at topoi.pooq.com: >>> >>>> On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: >>>>> Quoting hendrik at topoi.pooq.com: >>>>> >>>>>> Is it time for me to make another try at installing cm3 from >>>>>> scratch? >>>>>> In particular, do you think most of the problems I reported with >>>>>> documentation and archives, etc., have been solved? I really >>>>>> want to >>>>>> get m3 working on this laptop, but I also want to provide the >>>>>> most >>>>>> useful problem reports. >>>>>> >>>>>> I'm definitely trying to act like a naive user in these >>>>>> installation >>>>>> attempts (which means I'm trying to act stupider than I am). >>>>> >>>>> I've now put some initial release engineering documentation onto >>>>> birch, available at >>>>> >>>>> http://www.opencm3.net/releng >>>> >>>> Well, I started with that page, assuming that it will be the one >>>> Google >>>> finds when the release is finally out. I'm continuing to act like a >>>> naive user (but I'm probably not naive enough to give the >>>> instructions a >>>> real test). >>>> >>>> It seems to have installed, but I'm not sure, because the installer >>>> ended with an error message. Here are the gory details. >>>> >>>> Started from http://www.opencm3.net/releng/ >>>> >>>> I found the description quite clear. It's still not clear just what >>>> packages are in cm3-core and not in cm3-min or why I would want >>>> them, >>>> but it was clear I wanted to start with cm3-core. For example, is >>>> there >>>> a UI library in cm3-core? >>>> >>>> (Oh why is it so hard to cut and paste from the web page to this >>>> emacs >>>> buffer on my laptop?) >>> >>>> cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a >>>> problem. A >>>> beginner with Linux might have difficulty knowing whether to use >>>> the >>>> .lzma version. >>> >>> LINUXLIBC6 along with all lmza archives were created by Jay; >>> I'd rather have limited the available formats. Of course this needs >>> to be documented if we provide .lzma files. >>> >>>> Ah! I clicked on the "standard, recommended" link (I hadn't >>>> realised it >>>> was a link) and found the list of what packages are in the .tgz >>>> file. >>>> One layout comment -- it consists of a series of sections, each >>>> starting >>>> with a title and ending with a browse-sources link. Each title >>>> needs to >>>> look more prominent than the text or the link. At the moment, the >>>> link >>>> is what stands out. More blank lines between the entries then >>>> within >>>> them would make them group better. >>>> >>>> Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz >>>> >>>> Again, that worked. I do find myseelf wondering it that would be >>>> the >>>> correct command line if I were uzinng Winzip on Windows, though. >>>> (that's wha tthe insstruction seems to say) >>> >>> No, Winzip of course is a GUI application where you are supposed to >>> point and click with the mouse... >>> >>>> Next I run ./cminstall /usr/local/cm3 >>>> >>>> It asks mme whether /home.hendrik/cm3 is to be the root directory >>>> for >>>> cm3. The naive user doesn't know what that means. Nor do I, for >>>> that >>> >>> This is strange. cminstall shouldn't ask any questions by default. >>> But as mentioned before, I only built the archives for FreeBSD4 and >>> AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you >>> package >>> there? Or am I misunderstanding something here? >>> >>>> matter. I'm guessing that it's where to unpack and work during >>>> installation, but that it won't be needed later. That I can even >>>> deleete the entire /home/hendrik/cm3 directory tree after >>>> installation. >>>> That in fact when I instll packages later I can download them to, >>>> say, >>>> /anywhere and install them from /anywhere and they'll still get >>>> installed in the proper place. But I don't know. For now, I'll just >>>> accept the defaults. >>>> >>>> Next problem: >>>> >>>>> Installing CM3 in: /usr/local/cm3 >>>>> This may take a few minutes... >>>>> >>>>> Unexpected problem: cannot list current directory: errno=2 >>> >>> I've never seen that. Can you provide the complete installation log? >>> We may also need a system call trace to track this down... >>> >>>>> Please feel free to contact m3-support at elego.de to troubleshoot >>>>> this >>>> problem. >>>> >>>> Current directory? That's an uninformative message. Possibly it >>>> refers >>>> to /usr/local/cm3? Which really doesn't exit yet? Should your >>>> instructions say to create it and make sure it has the right write >>>> permissions? >>>> >>>> Noooo. that's not the reason. /usr/local/cm3 has been created. And >>>> populated with lots of subdirectories. /usr/local/cm3/bin >>>> contains a >>>> few executables and lots of other files. It turns out I did have >>>> permission to write on /usr/local. I don't know what directory it's >>>> referring to. >>> >>> Strange. I tried an installation on FreeBSD which succeeded without >>> any problems. >>> >>>> What next? >>> >>> Let's have a look at Install.log and hear what Jay has to say about >>> LINUXLIBC6. >>> >>> Thanks for the feedback, >>> >>> 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 Fri Jun 26 08:42:31 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 06:42:31 +0000 Subject: [M3devel] upgrade.sh CFGD code seems wrong/dead? Message-ID: This block in upgrade.sh seems dead, given that nothing sets CFGD. Searching for 'CFGD'... C:\dev2\cm3.2\scripts\upgrade.sh(95): cp -v ${f} ${CFGD}/${b} if [ "${UPGRADE_CM3_CFG}" = "yes" -o "${ret}" != 0 ]; then ( .... I'd like to move the config files to root/bin/config instead of littering bin. Ok? This is one of the few places that is related to that. - Jay From jay.krell at cornell.edu Fri Jun 26 09:04:23 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 07:04:23 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <20090624231005.GA32180@topoi.pooq.com> References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> <20090624231005.GA32180@topoi.pooq.com> Message-ID: ---------------------------------------- > Date: Wed, 24 Jun 2009 19:10:05 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > On Mon, Jun 22, 2009 at 12:58:45PM -0400, Tony Hosking wrote: >> >> Yuck. Why not decompose in the backend? > > However we do it, large files should "just work" on systems that can > handle them. > > -- hendrik It should be LONGINT. I'll try to get to it. It might be a slightly breaking change, depending on where the INTEGER size is exposed. That shouldn't be difficult and will address all but one platform. I'll try to get back to revisiting LONGINT support on NT386. Then it might be interesting, though not easy, to port that backend to more platforms. :) One reason to do all those wierdo ports is to set a bar for what an integrated backend should strive for. :) Or then again again again, a C generator. That way, there'd be a chance of "no more porting work". If the IL was slightly abstracted, we could just generate portable C and release just one portable source-ish package for all platforms. There could still be binary packages for people that don't build from source, but all platforms would just be a C compiler away. - Jay From wagner at elegosoft.com Fri Jun 26 10:01:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 10:01:44 +0200 Subject: [M3devel] upgrade.sh CFGD code seems wrong/dead? In-Reply-To: References: Message-ID: <20090626100144.g3ciia3szocgsws0@mail.elegosoft.com> Quoting Jay : > > This block in upgrade.sh seems dead, given that nothing sets CFGD. > > Searching for 'CFGD'... > C:\dev2\cm3.2\scripts\upgrade.sh(95): cp -v ${f} ${CFGD}/${b} > > > if [ "${UPGRADE_CM3_CFG}" = "yes" -o "${ret}" != 0 ]; then ( > .... > > > I'd like to move the config files to root/bin/config instead of > littering bin. Ok? No. This would just be another directory which does not conform to FSH standards. I already extended cm3 to search for config files in various /etc directories, though that's still untested. I'd prefer that we don't move config files _now_ before the release, but if you want to do it, test it: o move them to cm3/etc o test cm3 with that setup on at least one platform o adapt scripts for regression etc. as you deem necessary o watch tinderbox results and fix again ;-) > > This is one of the few places that is related to that. As for your question above, I cannot say without browsing and grepping the code which I cannot do from here (isolated network); perhaps tonight... 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 wagner at elegosoft.com Fri Jun 26 10:08:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 10:08:54 +0200 Subject: [M3devel] files larger than 2gig In-Reply-To: References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> <20090624231005.GA32180@topoi.pooq.com> Message-ID: <20090626100854.ox2rmkey8o0k4gk4@mail.elegosoft.com> Quoting Jay : > > ---------------------------------------- >> Date: Wed, 24 Jun 2009 19:10:05 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] files larger than 2gig >> >> On Mon, Jun 22, 2009 at 12:58:45PM -0400, Tony Hosking wrote: >>> >>> Yuck. Why not decompose in the backend? >> >> However we do it, large files should "just work" on systems that can >> handle them. >> >> -- hendrik > > > It should be LONGINT. > I'll try to get to it. > It might be a slightly breaking change, depending on where the > INTEGER size is exposed. > > > That shouldn't be difficult and will address all but one platform. > I'll try to get back to revisiting LONGINT support on NT386. > Then it might be interesting, though not easy, to port that backend > to more platforms. :) > One reason to do all those wierdo ports is to set a bar for > what an integrated backend should strive for. :) > Or then again again again, a C generator. That way, there'd be a chance > of "no more porting work". If the IL was slightly abstracted, we could > just generate portable C and release just one > portable source-ish package for all platforms. > There could still be binary packages for people that don't build from source, > but all platforms would just be a C compiler away. It has been done that way in the first SRC compilers. m3make was just a wrapper generating makefiles, and the compiler produced C as an intermediate language. It was found to be rather suboptiomal for various reasons AFAIR: performance of the compiler, performance of the produced code (missing optimizations), missing C standardization (what exactly is portable C???), ... Of course I wouldn't object a C generating backend at all, but we should very carefully compare its benefits with the existing backends before abandoning any of them. 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 Fri Jun 26 10:38:31 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 08:38:31 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625185206.f4lc9vlpckggko4g@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: I tested the LINUXLIBC6 archive and it installed ok, no prompting. I ran it with no parameters -- unlike Henrik. It did mention the current working directory (or its directory, same thing) as the install source, which confused me. Probably as long as system.tgz exists where it expects, it shouldn't say anything. Also, even if the documentation is clear, its good to have as little to document as possible. Be as similar to other "things" as possible so nobody needs the patience to read/understand/learn. There is a time for that, but not when you are "about to make a sale" and user is just trying to get the thing working asap. - Jay ________________________________ > > >> Date: Thu, 25 Jun 2009 18:52:06 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) >> >> Quoting hendrik at topoi.pooq.com: >> >>> Next I run ./cminstall /usr/local/cm3 >>> >>> It asks mme whether /home.hendrik/cm3 is to be the root directory for >>> cm3. The naive user doesn't know what that means. Nor do I, for that >> >> This is strange. cminstall shouldn't ask any questions by default. >> But as mentioned before, I only built the archives for FreeBSD4 and >> AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package >> there? Or am I misunderstanding something here? >> >> From jay.krell at cornell.edu Fri Jun 26 11:00:22 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 09:00:22 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <20090626100854.ox2rmkey8o0k4gk4@mail.elegosoft.com> References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> <20090624231005.GA32180@topoi.pooq.com> <20090626100854.ox2rmkey8o0k4gk4@mail.elegosoft.com> Message-ID: > what exactly is portable C??? It may be a little bit elusive, but I think it is certainly possible. Think of how many packages out there that you just download, extract, configure, and make. Think of how much or how little per-system was put into them. Think of how much or how little configure (autoconf) does, and how applicable it is to CM3. > performance of the compiler > performance of the produced code (missing > optimizations) Understood the compiler would be slow. It is slow already, but this would likely be worse. It should be possible to still get reasonable optimization but I don't really know. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 10:08:54 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > Quoting Jay : > >> >> ---------------------------------------- >>> Date: Wed, 24 Jun 2009 19:10:05 -0400 >>> From: hendrik at topoi.pooq.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] files larger than 2gig >>> >>> On Mon, Jun 22, 2009 at 12:58:45PM -0400, Tony Hosking wrote: >>>> >>>> Yuck. Why not decompose in the backend? >>> >>> However we do it, large files should "just work" on systems that can >>> handle them. >>> >>> -- hendrik >> >> >> It should be LONGINT. >> I'll try to get to it. >> It might be a slightly breaking change, depending on where the >> INTEGER size is exposed. >> >> >> That shouldn't be difficult and will address all but one platform. >> I'll try to get back to revisiting LONGINT support on NT386. >> Then it might be interesting, though not easy, to port that backend >> to more platforms. :) >> One reason to do all those wierdo ports is to set a bar for >> what an integrated backend should strive for. :) >> Or then again again again, a C generator. That way, there'd be a chance >> of "no more porting work". If the IL was slightly abstracted, we could >> just generate portable C and release just one >> portable source-ish package for all platforms. >> There could still be binary packages for people that don't build from source, >> but all platforms would just be a C compiler away. > > It has been done that way in the first SRC compilers. m3make was just > a wrapper generating makefiles, and the compiler produced C as an intermediate > language. It was found to be rather suboptiomal for various reasons AFAIR: > performance of the compiler, performance of the produced code (missing > optimizations), missing C standardization (what exactly is portable C???), ... > > Of course I wouldn't object a C generating backend at all, but we should > very carefully compare its benefits with the existing backends before > abandoning any of them. > > 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 Fri Jun 26 11:01:51 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 09:01:51 +0000 Subject: [M3devel] upgrade.sh CFGD code seems wrong/dead? In-Reply-To: <20090626100144.g3ciia3szocgsws0@mail.elegosoft.com> References: <20090626100144.g3ciia3szocgsws0@mail.elegosoft.com> Message-ID: I don't think the FHS matters here. I don't want to get too far into the business of supporting people (even admins) editing these files. Nor do I want to avoid overwriting or merging their changes for later releases. Ideally, people should be as quick to edit cm3.cfg as they are to edit any bash/perl/python in /usr or to rebuild cm3 from source. But that might not be possible. There might also be decisions for which one size does not fit all. It is easy to see that. What cminstall used to prompt about are some where user /might/ want a different choice, but which there are also defaults that suit the majority of folks. It is a little unclear. Like, if postgres/odbc are in the location used by the platform's port/package system, or did user get "upstream directly" and it went in a different default like /usr/local? Or do they have a custom install location? Like, if they want to run a particular gcc by full path, or if the first in $PATH is what they want? First in $PATH is certainly very common, but so are other options, like gcc-version. I guess, ideally, more of the code is moved into cm3, leaving cm3.cfg really only for things people can edit freely. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 10:01:44 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: upgrade.sh CFGD code seems wrong/dead? > > Quoting Jay : > >> >> This block in upgrade.sh seems dead, given that nothing sets CFGD. >> >> Searching for 'CFGD'... >> C:\dev2\cm3.2\scripts\upgrade.sh(95): cp -v ${f} ${CFGD}/${b} >> >> >> if [ "${UPGRADE_CM3_CFG}" = "yes" -o "${ret}" != 0 ]; then ( >> .... >> >> >> I'd like to move the config files to root/bin/config instead of >> littering bin. Ok? > > No. This would just be another directory which does not conform to > FSH standards. I already extended cm3 to search for config files > in various /etc directories, though that's still untested. > > I'd prefer that we don't move config files _now_ before the release, > but if you want to do it, test it: > > o move them to cm3/etc > o test cm3 with that setup on at least one platform > o adapt scripts for regression etc. as you deem necessary > o watch tinderbox results and fix again ;-) > >> >> This is one of the few places that is related to that. > > As for your question above, I cannot say without browsing and grepping > the code which I cannot do from here (isolated network); perhaps tonight... > > 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 wagner at elegosoft.com Fri Jun 26 12:05:51 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 12:05:51 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: 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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> Quoting Jay : > > I tested the LINUXLIBC6 archive and it installed ok, no prompting. > > I ran it with no parameters -- unlike Henrik. It did mention the > current working directory (or its directory, same thing) as the > install source, which confused me. Probably as long as system.tgz > exists where it expects, it shouldn't say anything. Strange. Hendrik, can you reproduce the strange message? And then perhaps provide a system call trace (ktrace, truss, whatever)? Olaf > Also, even if the documentation is clear, its good to have as little > to document as possible. > Be as similar to other "things" as possible so nobody needs the > patience to read/understand/learn. > There is a time for that, but not when you are "about to make a > sale" and user is just trying to get the thing working asap. > > > - Jay > > > ________________________________ >> >> >>> Date: Thu, 25 Jun 2009 18:52:06 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: >>> Release engineering) >>> >>> Quoting hendrik at topoi.pooq.com: >>> >>>> Next I run ./cminstall /usr/local/cm3 >>>> >>>> It asks mme whether /home.hendrik/cm3 is to be the root directory for >>>> cm3. The naive user doesn't know what that means. Nor do I, for that >>> >>> This is strange. cminstall shouldn't ask any questions by default. >>> But as mentioned before, I only built the archives for FreeBSD4 and >>> AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package >>> there? Or am I misunderstanding something here? >>> > >>> -- 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 Fri Jun 26 12:08:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 12:08:47 +0200 Subject: [M3devel] files larger than 2gig In-Reply-To: References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> <20090624231005.GA32180@topoi.pooq.com> <20090626100854.ox2rmkey8o0k4gk4@mail.elegosoft.com> Message-ID: <20090626120847.4i11xyq5es4ggcg4@mail.elegosoft.com> Quoting Jay : > >> what exactly is portable C??? > > > It may be a little bit elusive, but I think it is certainly possible. > Think of how many packages out there that you just download, extract, > configure, I wasn't aware that configure is now part of the C standards ;-) > and make. Think of how much or how little per-system > was put into them. Think of how much or how little configure (autoconf) does, > and how applicable it is to CM3. -- 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 Fri Jun 26 14:00:11 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 12:00:11 +0000 Subject: [M3devel] archive bloat Message-ID: Olaf I think you should trim the archives more. They have lots of intermediate files used to build cm3cg, including the identical copy m3cgc1, various static libraries, etc. I also don't see the utility of the Modula-3 standalone libraries for which we include what they built into, e.g. libm3back.a, libm3objfile.a, libm3front.a, libm3quake.a. I'm also not sure what all the CVS files end up doing. Do the make a checkout go fast? But surely..they are slightly wrong? I realize now that the reason lzma didn't always help is because the archives contain system.tgz. - Jay From wagner at elegosoft.com Fri Jun 26 14:18:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 14:18:49 +0200 Subject: [M3devel] archive bloat In-Reply-To: References: Message-ID: <20090626141849.mw5uo0zahw4k80og@mail.elegosoft.com> Quoting Jay : > > Olaf I think you should trim the archives more. They have lots of > intermediate files used to build cm3cg, including the identical copy > m3cgc1, various static libraries, etc. That's because the archives are simply pre-built workspace parts. > I also don't see the utility of the Modula-3 standalone libraries > for which we include what they built into, e.g. libm3back.a, > libm3objfile.a, libm3front.a, libm3quake.a. These are surely needed for shipping. > I'm also not sure what all the CVS files end up doing. > Do the make a checkout go fast? > But surely..they are slightly wrong? It's the CVS meta information; we can prune that if necessary. A generic way to prune the bin-ws archives would be to remove everything that's not relevant for shipping, i.e. contained in .M3SHIP. I'll have a look at that later. > I realize now that the reason lzma didn't always help is because the > archives contain system.tgz. 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 Fri Jun 26 14:29:19 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 12:29:19 +0000 Subject: [M3devel] archive bloat In-Reply-To: <20090626141849.mw5uo0zahw4k80og@mail.elegosoft.com> References: <20090626141849.mw5uo0zahw4k80og@mail.elegosoft.com> Message-ID: > These are surely needed for shipping. They are not. shipping doesn't require shipping dependencies. Only building does. And building has already occured. Shipping cm3 doesn't do much anyway. It ships the man page, ok. And it ships the binary to a place other than where it is used, because cm3 is special. I checked, the following works: I already have a full enough package store. cd m3-sys/cm3 cm3 cm3 -ship rm -rf /cm3/pkg/m3front /cm3/pkg/middle /cm3/pkg/m3quake cm3 -ship > That's because the archives are simply pre-built workspace parts. Still... What do we gain by shipping the non-source part of the workspace? People can do incremental builds? In the future, if the package build / install split is earlier, it could ease cross packaging, but currently? Packaging the source with each architecture is wasteful, but it does address version skew. The binaries come with matching source. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 14:18:49 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] archive bloat > > Quoting Jay : > >> >> Olaf I think you should trim the archives more. They have lots of >> intermediate files used to build cm3cg, including the identical copy >> m3cgc1, various static libraries, etc. > > That's because the archives are simply pre-built workspace parts. > >> I also don't see the utility of the Modula-3 standalone libraries >> for which we include what they built into, e.g. libm3back.a, >> libm3objfile.a, libm3front.a, libm3quake.a. > > These are surely needed for shipping. > >> I'm also not sure what all the CVS files end up doing. >> Do the make a checkout go fast? >> But surely..they are slightly wrong? > > It's the CVS meta information; we can prune that if necessary. > > A generic way to prune the bin-ws archives would be to remove > everything that's not relevant for shipping, i.e. contained in > .M3SHIP. I'll have a look at that later. > >> I realize now that the reason lzma didn't always help is because the >> archives contain system.tgz. > > 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 Jun 26 14:38:28 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 26 Jun 2009 05:38:28 -0700 Subject: [M3devel] archive bloat In-Reply-To: Your message of "Fri, 26 Jun 2009 12:29:19 -0000." Message-ID: <200906261238.n5QCcSCv026471@camembert.async.caltech.edu> Woudln't not including libm3back.a (e.g.) be a special case? What if I write another program, call it "cm4", that imports the m3back package... what does it link against? Mika Jay writes: > >> These are surely needed for shipping. > >They are not. >shipping doesn't require shipping dependencies. Only building does. And buildi >ng has already occured. >Shipping cm3 doesn't do much anyway. It ships the man page, ok. And it ships t >he binary to a place other than where it is used, because cm3 is special. > >I checked, the following works: > > I already have a full enough package store. > cd m3-sys/cm3 > cm3 > cm3 -ship > rm -rf /cm3/pkg/m3front /cm3/pkg/middle /cm3/pkg/m3quake > cm3 -ship > >> That's because the archives are simply pre-built workspace parts. > >Still... > >What do we gain by shipping the non-source part of the workspace? >People can do incremental builds? >In the future, if the package build / install split is earlier, it could ease >cross packaging, but currently? > > >Packaging the source with each architecture is wasteful, but it does address v >ersion skew. >The binaries come with matching source. > > > - Jay > > >---------------------------------------- >> Date: Fri, 26 Jun 2009 14:18:49 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] archive bloat >> >> Quoting Jay : >> >>> >>> Olaf I think you should trim the archives more. They have lots of >>> intermediate files used to build cm3cg, including the identical copy >>> m3cgc1, various static libraries, etc. >> >> That's because the archives are simply pre-built workspace parts. >> >>> I also don't see the utility of the Modula-3 standalone libraries >>> for which we include what they built into, e.g. libm3back.a, >>> libm3objfile.a, libm3front.a, libm3quake.a. >> >> These are surely needed for shipping. >> >>> I'm also not sure what all the CVS files end up doing. >>> Do the make a checkout go fast? >>> But surely..they are slightly wrong? >> > It's the CVS meta information; we can prune that if necessary. >> >> A generic way to prune the bin-ws archives would be to remove >> everything that's not relevant for shipping, i.e. contained in >> .M3SHIP. I'll have a look at that later. >> >>> I realize now that the reason lzma didn't always help is because the >>> archives contain system.tgz. >> >> 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 Jun 26 14:53:15 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 26 Jun 2009 05:53:15 -0700 Subject: [M3devel] archive bloat In-Reply-To: Your message of "Fri, 26 Jun 2009 12:47:24 -0000." Message-ID: <200906261253.n5QCrFcW027024@camembert.async.caltech.edu> I'm just saying, what you're proposing is an exception to how Modula-3 works. When you make a package and ship it, you always ship it with both interface and library files. Is it really warranted making a special exception for m3back, m3front, m3quake? Besides, how are you going to re-use the m3back package unless you add "cm4" to the main compiler distribution? I want to be able to maintain my own software separately from the CM3 distribution...and then you have to keep the sources around, too? Hrmph.... Mika Jay writes: > >Is it really meant to be reusable by anything other than cm3? >Even still, the workspace includes all the source. You can just build it if yo >u really need it. > > - Jay > > >---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Fri, 26 Jun 2009 05:38:28 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] archive bloat >> >> Woudln't not including libm3back.a (e.g.) be a special case? >> >> What if I write another program, call it "cm4", that imports the >> m3back package... what does it link against? >> >> Mika From jay.krell at cornell.edu Fri Jun 26 14:47:24 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 12:47:24 +0000 Subject: [M3devel] archive bloat In-Reply-To: <200906261238.n5QCcSCv026471@camembert.async.caltech.edu> References: Your message of "Fri, 26 Jun 2009 12:29:19 -0000." <200906261238.n5QCcSCv026471@camembert.async.caltech.edu> Message-ID: Is it really meant to be reusable by anything other than cm3? Even still, the workspace includes all the source. You can just build it if you really need it. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Fri, 26 Jun 2009 05:38:28 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] archive bloat > > Woudln't not including libm3back.a (e.g.) be a special case? > > What if I write another program, call it "cm4", that imports the > m3back package... what does it link against? > > Mika From jay.krell at cornell.edu Fri Jun 26 15:21:06 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 13:21:06 +0000 Subject: [M3devel] archive bloat In-Reply-To: <200906261253.n5QCrFcW027024@camembert.async.caltech.edu> References: Your message of "Fri, 26 Jun 2009 12:47:24 -0000." <200906261253.n5QCrFcW027024@camembert.async.caltech.edu> Message-ID: I guess even m3quake is maybe reusable, for anyone who wants to implement that scripting language. And I like the notion contrary to your point that all the Modula-3 source is together. It makes for easier/better testing, and more flexibility to change things. I was really just looking around for why the new archives are so large. The new core archive is twice the size of the old std. It includes source, probably even three copies of gcc. There is /some/ reason for that, and two of the copies are minimized, though still fairly unnecessary -- I386_INTERIX and ARM_DARWIN each have their own fork of gcc, a decision I remain comfortable with, but not clearly worth making so many more copies of. Compare http://modula3.elegosoft.com/cm3/uploaded-archives/index.html to http://www.opencm3.net/releng/ core in releng is twice the size or more of std in uploaded. I realize it is somewhat apples to oranges, but the uploaded archives I think (I'm checking..) do actually have source, for debugging, in the package store, and even these not very useful static libs. I guess the gcc stuff is the real difference. There is an option to have ship not ship the source actually, for further size savings, but then debugging suffers -- it'd be cool if the binaries contained CVS paths and versions and gdb could just get the source on-demand, as long as you are on the network.. Both sets also have symbols. There is a practise of stripping out the symbols into separate packages, at least on GNU systems (gcc/ld/gdb), but I haven't looked into it and the convenience for debugging of keeping the symbols in the binary seems significant. So far I've chosen to keep that. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Fri, 26 Jun 2009 05:53:15 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] archive bloat > > > I'm just saying, what you're proposing is an exception to how Modula-3 > works. When you make a package and ship it, you always ship it with > both interface and library files. Is it really warranted making a special > exception for m3back, m3front, m3quake? > > Besides, how are you going to re-use the m3back package unless you > add "cm4" to the main compiler distribution? I want to be able to > maintain my own software separately from the CM3 distribution...and > then you have to keep the sources around, too? Hrmph.... > > Mika > > Jay writes: >> >>Is it really meant to be reusable by anything other than cm3? >>Even still, the workspace includes all the source. You can just build it if yo >>u really need it. >> >> - Jay >> >> >>---------------------------------------- >>> To: jay.krell at cornell.edu >>> Date: Fri, 26 Jun 2009 05:38:28 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] archive bloat >>> >>> Woudln't not including libm3back.a (e.g.) be a special case? >>> >>> What if I write another program, call it "cm4", that imports the >>> m3back package... what does it link against? >>> >>> Mika From jay.krell at cornell.edu Fri Jun 26 15:32:22 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 13:32:22 +0000 Subject: [M3devel] dead links Message-ID: http://www.opencm3.net/doc/help/gen_html/dirfp/INDEX.html and surely all the rest contain links to CVS files, of suspicious utility, that are actually dead. http://www.opencm3.net/releng/collection-core.html The links there to browse source don't work, er, at least specifically the first three -- m3core, m3cc, import-libs. Several others do work. Some have the CVS files, some don't. There are some unusual manual page links..which aren't exactly broken, but oddly placed and inconsistent. "Some Useful odula-3 Interfaces" is missing the M in Modula-3 (still in collection-core.html). The first link in: http://www.opencm3.net/releng/collection-obliq.html doesn't work, to polymtl. Much more to check, there's a lot of new stuff and/or stuff I've never looked at... - Jay From jay.krell at cornell.edu Fri Jun 26 15:38:54 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 13:38:54 +0000 Subject: [M3devel] suggest auto detect client architecture in web page Message-ID: You know how you go to the Firefox download page and it offers you "only" the right download for your machine, and then has a link for other systems or older versions? That'd be nice. It's presumably "just a little bit of jscript to sniff the agent string". At the least, the list of systems should link down to their files. But just hiding the whole thing like Firefox et. al. I think is much preferred. I finally found simple documentation about building Debian packages, that doesn't get bogged down in all the source building apparatus. So I'll very maybe do something there, like integrate it into make-dist.sh. You don't even need any special tools, just tar, gzip, and ar. It's so easy, for a minimal not exactly officially good enough package, I can explain it in a few sentences and it'll take very little code. - Jay From hendrik at topoi.pooq.com Fri Jun 26 17:06:45 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 26 Jun 2009 11:06:45 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: References: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: <20090626150644.GA4554@topoi.pooq.com> On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: > > There's no need for Winzip if we use .zip files, explorer handles them. > > It is also easy to make self extracting .zip files. That's the way to go -- it's the popular archive format for Windows, security be damned! > > And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. > > > - Jay From hendrik at topoi.pooq.com Fri Jun 26 17:12:38 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 26 Jun 2009 11:12:38 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> References: <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> Message-ID: <20090626151238.GB4554@topoi.pooq.com> On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: > Quoting Jay : > > > > >I tested the LINUXLIBC6 archive and it installed ok, no prompting. > > > >I ran it with no parameters -- unlike Henrik. It did mention the > >current working directory (or its directory, same thing) as the > >install source, which confused me. Probably as long as system.tgz > >exists where it expects, it shouldn't say anything. > > Strange. > > Hendrik, can you reproduce the strange message? And then perhaps > provide a system call trace (ktrace, truss, whatever)? > > Olaf I'll try. I'll probably have to rm -r /user/local/cm3 first. Anything else I need to watch out for? Now that I think of resetting ... I still had the old cm3-min unpacked somewhere else, and I add its bin directory to the $PATH on a bash startup. Could that have be affecting the results? -- hendrik From hendrik at topoi.pooq.com Fri Jun 26 17:17:07 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 26 Jun 2009 11:17:07 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: References: <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626150644.GA4554@topoi.pooq.com> Message-ID: <20090626151707.GC4554@topoi.pooq.com> On Fri, Jun 26, 2009 at 03:19:44PM +0000, Jay wrote: > > Security not be damned. > You can sign executables. > You can open them in winzip instead if you want (if they are self extracting .zips). True. But most of the WIndows users I know just execute them. Their problem. not ours. If ours executes properly, that is. > Where is the line between running the installer vs. running the code > it installs, anyway? The disaster is faster. There's less time for antivirus tools to detect trouble. But let's not start a long thread about how to make Wiondows secure. Not our job. > I guess the installer runs maybe privileged and its payload does not. > But that isn't required for cm3, you can install to $HOME. > People also often just distribute non-self-running .MSI files. > That would be a good option. > > - Jay > > > ---------------------------------------- > > Date: Fri, 26 Jun 2009 11:06:45 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > > > On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: > >> > >> There's no need for Winzip if we use .zip files, explorer handles them. > >> > >> It is also easy to make self extracting .zip files. > > > > That's the way to go -- it's the popular archive format for Windows, security > > be damned! > > > >> > >> And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. > >> > >> > >> - Jay From jay.krell at cornell.edu Fri Jun 26 17:19:44 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 15:19:44 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090626150644.GA4554@topoi.pooq.com> References: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626150644.GA4554@topoi.pooq.com> Message-ID: Security not be damned. You can sign executables. You can open them in winzip instead if you want (if they are self extracting .zips). Where is the line between running the installer vs. running the code it installs, anyway? I guess the installer runs maybe privileged and its payload does not. But that isn't required for cm3, you can install to $HOME. People also often just distribute non-self-running .MSI files. That would be a good option. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 11:06:45 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: >> >> There's no need for Winzip if we use .zip files, explorer handles them. >> >> It is also easy to make self extracting .zip files. > > That's the way to go -- it's the popular archive format for Windows, security > be damned! > >> >> And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. >> >> >> - Jay From jay.krell at cornell.edu Fri Jun 26 17:29:29 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 15:29:29 +0000 Subject: [M3devel] no need to import direct dependencies if also indirectly dependent? In-Reply-To: <20090626152312.67AE6CC360@birch.elegosoft.com> References: <20090626152312.67AE6CC360@birch.elegosoft.com> Message-ID: Hm, it looks like there is both a direct and indirect dependency here on sysutils. indirect through m3quake direct use of TextUtils Shouldn't the builder /ideally/ require you do import directly what you directly depend on? (and not import directly what you indirectly depend on, already correct) Or would that be a bit inconvenient? I don't care really, I'm not pushing for a change, but wouldn't that generally be the right design? - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 17:23:12 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/06/26 17:23:12 > > Modified files: > cm3/m3-sys/cminstall/src/: m3makefile > > Log message: > go back a version -- there is an indirect dependency on sysutils so this is ok to leave as a sort of comment, though it is not needed, and it might cause the dependency to stick even if the indirect one goes away? > From wagner at elegosoft.com Fri Jun 26 17:59:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 17:59:55 +0200 Subject: [M3devel] archive bloat In-Reply-To: References: <20090626141849.mw5uo0zahw4k80og@mail.elegosoft.com> Message-ID: <20090626175955.pvanjmxce0wgcgcw@mail.elegosoft.com> Quoting Jay : > >> These are surely needed for shipping. > > They are not. > shipping doesn't require shipping dependencies. Only building does. > And building has already occured. > Shipping cm3 doesn't do much anyway. It ships the man page, ok. And > it ships the binary to a place other than where it is used, because > cm3 is special. > > I checked, the following works: > > I already have a full enough package store. > cd m3-sys/cm3 > cm3 > cm3 -ship > rm -rf /cm3/pkg/m3front /cm3/pkg/middle /cm3/pkg/m3quake > cm3 -ship > >> That's because the archives are simply pre-built workspace parts. > > Still... > > What do we gain by shipping the non-source part of the workspace? > People can do incremental builds? > In the future, if the package build / install split is earlier, it > could ease cross packaging, but currently? > > Packaging the source with each architecture is wasteful, but it does > address version skew. > The binaries come with matching source. m3quake and m3middle etc. are packages which are useful on their own. I don't think providing partial installation packages is the way to go. 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 rcolebur at scires.com Fri Jun 26 18:24:47 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Fri, 26 Jun 2009 12:24:47 -0400 Subject: [M3devel] log messages for committed changes In-Reply-To: <20090626081242.DE6C6CC306@birch.elegosoft.com> References: <20090626081242.DE6C6CC306@birch.elegosoft.com> Message-ID: <4A44BE0C.1E75.00D7.1@scires.com> Hey, I've seen several of these type messages (see below). My question is "WHY"? Just to state that it doesn't need to be standalone begs the question why was it made standalone in the first place and what is the reason why it no longer needs to be that way. Maybe this is part of a larger rant on my part, but when folks commit changes, I would encourage everyone to provide some rationale and detail in the log message. There are few people like Olaf and Tony that have enough perspective with the whole system to be able to look at the details of what was changed and try to reverse something that goes against core principals or that will cause problems elsewhere. For the rest of us, and for documentation of the system evolution, it is important that the log messages be as detailed as possible, at least to give the rationale why a change is being made. I know documentation is not glamorous and doesn't directly affect the code, but it is nonetheless important, and if done well can be a real benefit. Thanks for listening. I'll step down off my soapbox now. Regards, Randy Coleburn >>> Jay Krell 6/26/2009 10:12 AM >>> CVSROOT:/usr/cvs Changes by:jkrell at birch.09/06/26 10:12:42 Modified files: cm3/m3-sys/m3cgcat/src/: m3makefile Log message: This doesn't need to be standalone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Fri Jun 26 18:40:35 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 16:40:35 +0000 Subject: [M3devel] [M3commit] log messages for committed changes In-Reply-To: <4A44BE0C.1E75.00D7.1@scires.com> References: <20090626081242.DE6C6CC306@birch.elegosoft.com> <4A44BE0C.1E75.00D7.1@scires.com> Message-ID: I was thinking of starting an email thread on this. I believe the reasons to make things standalone are: - unshipped built-global tools run during the build, such as m3bundle, stub generators, PklFonts, etc. I think these could be addressed but it'd take some work. - "Tony's convenience", still being discussed. A think this was a stronger case prior to -rpath where having "separate runnable backups" was more difficult. Or perhaps still since -rpath isn't yet everywhere, AMD64_DARWIN in particular. Personally when I revert to a backup I copy it back to the real place, sometimes with an entire package store, but it is reasonable to not have to do that, and even reasonable to reduce it to one file instead of roughly three in two directories. This would really only apple to cm3 and m3cgcat. For it to include m3cggen would definitely be surprising. It is also "nice to have" cm3 statically linked because when cross building to a new platform, you don't have to get shared libraries working before running cm3. But you could toggle that for this scenario. I had thought there was also a requirement around bootstrapping from an older build, where old cm3 can't build new m3core/libm3, but I don't see that now. - inability on some platforms to ship in use files, could be worked around, but partly related to previous, and more than that; in particular cm3 shouldn't ship m3core.so/libm3.so that it uses, if you intend to run that cm3 again - possibly so they can be redistributed with fewer files This is the typical reason in the larger world for reducing dynamic linking, as well to be independent of changes to those files. But I don't think "we" intend that to happen for "our" stuff. And I think we intend for now to always ship everything together, so versioning and compatibility can be ignored. I think. There are still a few sprinkled standalones, like in games. Which is why I was going to start email. If someone really wanted to copy solitaire around without installing its dependencies, rebuild it from source? - cminstall, because it runs so early Though this could be addressed via -rpath = $ORIGIN and putting the .so files it needs next to it, and not duplicating them. The reason to make things not standalone is several efficiency gains. You share the code in memory, you share it on disk, you don't copy it around as many times, locally or over the network. The savings are generally pretty large. - Jay ________________________________ > Date: Fri, 26 Jun 2009 12:24:47 -0400 > From: rcolebur at scires.com > To: m3commit at elegosoft.com; m3devel at elegosoft.com > Subject: [M3commit] log messages for committed changes > > > > > > > > Hey, I've seen several of these type messages (see below). My question is "WHY"? Just to state that it doesn't need to be standalone begs the question why was it made standalone in the first place and what is the reason why it no longer needs to be that way. > > > > Maybe this is part of a larger rant on my part, but when folks commit changes, I would encourage everyone to provide some rationale and detail in the log message. > > > > There are few people like Olaf and Tony that have enough perspective with the whole system to be able to look at the details of what was changed and try to reverse something that goes against core principals or that will cause problems elsewhere. For the rest of us, and for documentation of the system evolution, it is important that the log messages be as detailed as possible, at least to give the rationale why a change is being made. I know documentation is not glamorous and doesn't directly affect the code, but it is nonetheless important, and if done well can be a real benefit. > > > > Thanks for listening. I'll step down off my soapbox now. > > > > Regards, > > Randy Coleburn > > >>>> Jay Krell 6/26/2009 10:12 AM>>> > CVSROOT:/usr/cvs > Changes by:jkrell at birch.09/06/26 10:12:42 > > Modified files: > cm3/m3-sys/m3cgcat/src/: m3makefile > > Log message: > This doesn't need to be standalone. > > From hosking at cs.purdue.edu Fri Jun 26 20:17:21 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 26 Jun 2009 14:17:21 -0400 Subject: [M3devel] [M3commit] log messages for committed changes In-Reply-To: References: <20090626081242.DE6C6CC306@birch.elegosoft.com> <4A44BE0C.1E75.00D7.1@scires.com> Message-ID: For M3 system development tools like m3cgcat m3cggen, standalone is generally best. True, most users don't need to ship those tools. On 26 Jun 2009, at 12:40, Jay wrote: > > I was thinking of starting an email thread on this. > > > I believe the reasons to make things standalone are: > > - unshipped built-global tools run during the build, such as > m3bundle, stub generators, PklFonts, etc. > I think these could be addressed but it'd take some work. > > > - "Tony's convenience", still being discussed. > A think this was a stronger case prior to -rpath where having > "separate runnable backups" > was more difficult. Or perhaps still since -rpath isn't yet > everywhere, AMD64_DARWIN in particular. > Personally when I revert to a backup I copy it back to the real > place, sometimes > with an entire package store, > but it is reasonable to not have to do that, and even reasonable > to reduce it to one file > instead of roughly three in two directories. > This would really only apple to cm3 and m3cgcat. For it to > include m3cggen would > definitely be surprising. > It is also "nice to have" cm3 statically linked because when > cross building to a new > platform, you don't have to get shared libraries working before > running cm3. But > you could toggle that for this scenario. > > I had thought there was also a requirement around bootstrapping > from an older > build, where old cm3 can't build new m3core/libm3, but I don't > see that now. > > - inability on some platforms to ship in use files, could be worked > around, but > partly related to previous, and more than that; in particular cm3 > shouldn't ship > m3core.so/libm3.so that it uses, if you intend to run that cm3 > again > > > - possibly so they can be redistributed with fewer files > This is the typical reason in the larger world for reducing > dynamic linking, > as well to be independent of changes to those files. > But I don't think "we" intend that to happen for "our" stuff. > And I think we intend for now to always ship everything together, > so versioning and compatibility can be ignored. I think. > There are still a few sprinkled standalones, like in games. > Which is why I was going to start email. > If someone really wanted to copy solitaire around without > installing its dependencies, > rebuild it from source? > > > - cminstall, because it runs so early > Though this could be addressed via -rpath = $ORIGIN and putting > the .so files it needs next to it, and not duplicating them. > > > The reason to make things not standalone is several efficiency gains. > You share the code in memory, you share it on disk, you don't copy > it around > as many times, locally or over the network. The savings are > generally pretty large. > > > - Jay > > > ________________________________ >> Date: Fri, 26 Jun 2009 12:24:47 -0400 >> From: rcolebur at scires.com >> To: m3commit at elegosoft.com; m3devel at elegosoft.com >> Subject: [M3commit] log messages for committed changes >> >> >> >> >> >> >> >> Hey, I've seen several of these type messages (see below). My >> question is "WHY"? Just to state that it doesn't need to be >> standalone begs the question why was it made standalone in the >> first place and what is the reason why it no longer needs to be >> that way. >> >> >> >> Maybe this is part of a larger rant on my part, but when folks >> commit changes, I would encourage everyone to provide some >> rationale and detail in the log message. >> >> >> >> There are few people like Olaf and Tony that have enough >> perspective with the whole system to be able to look at the details >> of what was changed and try to reverse something that goes against >> core principals or that will cause problems elsewhere. For the rest >> of us, and for documentation of the system evolution, it is >> important that the log messages be as detailed as possible, at >> least to give the rationale why a change is being made. I know >> documentation is not glamorous and doesn't directly affect the >> code, but it is nonetheless important, and if done well can be a >> real benefit. >> >> >> >> Thanks for listening. I'll step down off my soapbox now. >> >> >> >> Regards, >> >> Randy Coleburn >> >> >>>>> Jay Krell 6/26/2009 10:12 AM>>> >> CVSROOT:/usr/cvs >> Changes by:jkrell at birch.09/06/26 10:12:42 >> >> Modified files: >> cm3/m3-sys/m3cgcat/src/: m3makefile >> >> Log message: >> This doesn't need to be standalone. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jun 26 21:12:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 21:12:32 +0200 Subject: [M3devel] dead links In-Reply-To: References: Message-ID: <20090626211232.p2z8n0bqosk44skg@mail.elegosoft.com> Quoting Jay : > http://www.opencm3.net/doc/help/gen_html/dirfp/INDEX.html > > and surely all the rest contain links to CVS files, of suspicious > utility, that are actually dead. > > http://www.opencm3.net/releng/collection-core.html > > The links there to browse source don't work, er, at least > specifically the first three -- m3core, m3cc, import-libs. Several > others do work. Some have the CVS files, some don't. > There are some unusual manual page links..which aren't exactly > broken, but oddly placed and inconsistent. > > "Some Useful odula-3 Interfaces" is missing the M in Modula-3 (still > in collection-core.html). These should be fixed now. If I've missed something, let me know... > The first link in: > http://www.opencm3.net/releng/collection-obliq.html > > doesn't work, to polymtl. Hm, we need to replace that in our doc then. I noticed other broken links to DEC amd others, too, in doc. > Much more to check, there's a lot of new stuff and/or stuff I've > never looked at... > > - 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 Fri Jun 26 22:10:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 22:10:28 +0200 Subject: [M3devel] LINUXLIBC6 on 64 bit Hardware Message-ID: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> I Installed the LINUXLIBC6 archives from Jay on birch in my home directory without problems. Trying to build package m3core fails at the last step with ... fgrep m3gcdefs /home/wagner/cm3-LINUXLIBC6/pkg/m3core/LINUXLIBC6/.M3EXPORTS 2>/dev/null >/dev/null gcc -gstabs+ -m32 -fPIC -mno-align-double -z now -z origin -Bsymbolic -Wl,--fatal-warnings -Wl,-rpath,\$ORIGIN/../lib -Wl,--warn-common -Wl,-rpath,/home/wagner/cm3-LINUXLIBC6/lib -shared -Wl,-soname,libm3core.so.5 -o libm3core.so.5 hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTTipe.io RTTipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSmmap.o RTThread.io RTThreadStk.mo RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTMachine.io RTThread.mo RTThreadC.o RTExFrame.io RTExFrame.mo RTStackC.o Thread.io Scheduler.io SchedulerPosix.io MutexRep.io ThreadEvent.io ThreadF.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo WinNTc.o UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uucontext.o Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Upthread.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Usysdep.io Usignal.io Uucontext.io Upthreadtypes.io Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io Ctypes.io M3toC.io M3toC.mo CerrnoC.o Cstring.io Cstdio.io Csignal.io Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo DateBsd.mo TimePosix.io TimePosix.mo CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo PolyBasis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo -lm -lpthread /usr/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3core Fatal Error: package build failed rm m3make.args cd .. birch [~/work/cm3] wagner % type gcc gcc is /usr/bin/gcc birch [~/work/cm3] wagner % gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) I don't see gcc_s in the link command, and on birch there _is_ /lib/libgcc_s.so.1 Any ideas? 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 Fri Jun 26 22:46:45 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 26 Jun 2009 13:46:45 -0700 Subject: [M3devel] LINUXLIBC6 on 64 bit Hardware In-Reply-To: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> References: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> Message-ID: Surely a 32 on 64 thing. Try a 32 bit system? We would probably be ok with static libgcc. - Jay (phone) On Jun 26, 2009, at 1:10 PM, Olaf Wagner wrote: > I Installed the LINUXLIBC6 archives from Jay on birch in my home > directory without problems. > > Trying to build package m3core fails at the last step with > > ... > fgrep m3gcdefs /home/wagner/cm3-LINUXLIBC6/pkg/m3core/ > LINUXLIBC6/.M3EXPORTS 2>/dev/null >/dev/null > gcc -gstabs+ -m32 -fPIC -mno-align-double -z now -z origin - > Bsymbolic -Wl,--fatal-warnings -Wl,-rpath,\$ORIGIN/../lib -Wl,--warn- > common -Wl,-rpath,/home/wagner/cm3-LINUXLIBC6/lib -shared -Wl,- > soname,libm3core.so.5 -o libm3core.so.5 hand.o dtoa.o libgcc.o > RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo > Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io > RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io > RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo > RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo > RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTLinkerX.io > RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTError.io > RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo > RTMisc.io RTMisc.mo RTModule.io RTPacking.io RTPacking.mo > RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io > RTProcess.mo RTTipe.io RTTipe.mo RTType.io RTType.mo RTTypeFP.io > RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo > RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io > RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io > RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSmmap.o RTThread.io > RTThreadStk.mo RTSignalPrivate.io RTSignalC.o RTSignalC.io > RTSignal.mo RTMachine.io RTThread.mo RTThreadC.o RTExFrame.io > RTExFrame.mo RTStackC.o Thread.io Scheduler.io SchedulerPosix.io > MutexRep.io ThreadEvent.io ThreadF.io ThreadPThread.io > ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io > WinDef.mo WinNT.io WinNT.mo WinNTc.o UtimeC.o UnixC.o UnixLink.o > Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o > Uucontext.o Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io > Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io > Upthread.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o > Usysdep.io Usignal.io Uucontext.io Upthreadtypes.io Uin.io Cerrno.io > Cstddef.io Cstdint.io Cstdlib.io Ctypes.io M3toC.io M3toC.mo > CerrnoC.o Cstring.io Cstdio.io Csignal.io Csetjmp.io BasicCtypes.io > RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io > IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io > DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io > RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io > FPU.io FPU.mo FloatMode.io FloatMode.mo Time.io Tick.io Date.io > FmtTime.io FmtTime.mo TickPortable.mo DateBsd.mo TimePosix.io > TimePosix.mo CConvert.io CConvert.mo Convert.io Convert.mo > String8.io String8.mo String16.io String16.mo Text.io Text.mo > TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io > Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo > Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io > TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo > Fingerprint.io Fingerprint.mo Poly.io Poly.mo PolyBasis.io > PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io > LongRep.io Long.io Word.mo Long.mo -lm -lpthread > /usr/bin/ld: cannot find -lgcc_s > collect2: ld returned 1 exit status > make_lib => 1 > librarian failed building: m3core > Fatal Error: package build failed > rm m3make.args > cd .. > birch [~/work/cm3] wagner > % type gcc > gcc is /usr/bin/gcc > birch [~/work/cm3] wagner > % gcc -v > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --enable-languages=c,c+ > +,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with- > system-zlib --libexecdir=/usr/lib --without-included-gettext -- > enable-threads=posix --enable-nls --program-suffix=-4.1 --enable- > __cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable- > mpfr --enable-checking=release x86_64-linux-gnu > Thread model: posix > gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) > > I don't see gcc_s in the link command, and on birch there _is_ > /lib/libgcc_s.so.1 > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > 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: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From eiserlohpp at yahoo.com Sat Jun 27 01:09:16 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 26 Jun 2009 16:09:16 -0700 (PDT) Subject: [M3devel] Manual Page for Quake Message-ID: <528453.41864.qm@web56801.mail.re3.yahoo.com> Okay guys, I took the web page describing the quake language, and formated it as a man page. http://www.eiserloh.org/~peter/modula3/#mydocs I hereby submit this for inclusion within the modula-3 archives. I hereby relinquish any rights to the (quake.man) and any derived files. This document is now in the public domain. NOTE: The original content was authored by Stephen Harrison, not me. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat Jun 27 02:45:34 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 00:45:34 +0000 Subject: [M3devel] link options (was LINUXLIBC6 on 64 bit Hardware) (rambly) In-Reply-To: <20090626232034.nbt6xg4sgws4w440@mail.elegosoft.com> References: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> <20090626232034.nbt6xg4sgws4w440@mail.elegosoft.com> Message-ID: [adding m3devel] ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: link options (was LINUXLIBC6 on 64 bit Hardware) (rambly) > Date: Sat, 27 Jun 2009 00:43:58 +0000 > > > ps: You don't see -lc there either. > Change SYSTEM_CC to include -Wl,-v or such and you can see what gcc feeds to ld, surely it'll have hints of -lc and -lgcc_s. Or gcc -dump-specs or somesuch. > You could try running that then without the -lgcc_s but you'll likely have unresolved externals related to 64 bit integers. libgcc is about more than 64 bit integers, also like C++ and Ada exception handling, but it seems like overkill for us. 64 bit systems shouldn't need it for 64 bit math, at least. > THe thing is, choice of shared libgcc or not, is that, you know, you /might/ be (static) linking your Modula-3 with some C++ code that uses exceptions, and you /might/ be /dynamically/ linking to other C++ code that throws exceptions and you might want interop, in which case shared libgcc is desired. > > > But then the common case is the "opposite" -- all Modula-3. > > > I think it is tenuous to have exceptions go across dynamic link boundaries, but some people think the line between dynamic and static linking should be quite blurry and things should work the "same" either way. > (Thus why the older symbol resolution algorithms where all symbols looked across all .so files, to emulate static linking, eventually/gradually replaced with "two level namespace". That is Apple's term and I think a good description of what everyone now favors even if they don't call it that; but then the defaults often unchanged for compatibility, Apple changed the default, NT was always this way (except maybe Interix)). > > > Actually, now that I think about it...this is stuff that actually needs to be controllable from each m3makefile, and possibly from the cm3 command line. > > I used to think it was a config file thing and I'd try to make a reasonable choice for everyone, but now I think it's not even a per-machine thing but more granular. Anyway, the default is reasonable, just that it should probably be changable. > > > So probably we should have new Quake directives that mimic gcc's command line options, like: > SharedLibGcc(); > StaticLibGcc(); > > > and they'd just be ignored on SOLsun, NT386, etc. > They'd just be trivially implemented in cm3cfg.common and set a global that m3_link adds to the link command line, very simple. > > > I guess this is a general exercise: See what switches in gcc/ld people tend to vary on a project by project basis, see which ones are relevant to Modula-3 (ie: more linking flags, not compile flags) and expose them in Quake. > AND/OR ensure it is/remains viable for people to use Makefiles, combine Modula-3 with gcc using Makefiles and gcc, and just using cm3 to build some pieces of their project. Personally I've never tried that. > That way, you know, they can just form their own link commands in a Makefile and Quake doesn' t have to provide full access. > Also we could make SYSTEM_LD not readonly and leaf m3makefiles could just munge it. > That is an easy way to add flexibility. > > > - Jay > > ---------------------------------------- >> Date: Fri, 26 Jun 2009 23:20:34 +0200 >> From: wagner >>>> >>>> I don't see gcc_s in the link command, and on birch there _is_ >>>> /lib/libgcc_s.so.1 >>>> >>>> Any ideas? >>>> >>>> Olaf From jay.krell at cornell.edu Sat Jun 27 03:35:49 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 01:35:49 +0000 Subject: [M3devel] PPC_DARWIN tinderbox Message-ID: Tony, this is your machine? It is only run once, in a while, and failed. Maybe an error in your defs.sh? - Jay From jay.krell at cornell.edu Sat Jun 27 06:33:12 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 04:33:12 +0000 Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress In-Reply-To: <4A45868C.3020001@cox.net> References: <4A4251D6.60804@cox.net> <4A45868C.3020001@cox.net> Message-ID: Right, definitely good to make the invasive changes minimal. Our diffs within gcc are quite small I found. Almost everything is adding the file parse.c CVS is supposed to help here, three way merge and all that, but there is only so much it can do. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 21:40:12 -0500 > From: rodney.m.bates at cox.net > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3gdb/AMD64_LINUX, a little progress > > Jay wrote: >> You should try using cvs import to upgrade to a newer version, of the >> entire gdb tree (well, maybe prune it -- testsuites, sim, cpu, intl, >> etc..) >> I personally have never done this -- only recently imported the first >> version of stuff but haven't yet updated anything. > There is a _lot_ of merging work to get the m3gdb changes into a newer gdb > base, including a lot of manual cleanup. I've done it. More than > once. I plan to > do it again, real soon now, but this was a reckless attempt at something > quick > and dirty. Also, there is a newest gdb release 6/9 forthcoming soon, and I > think it would be nice to wait for it. > > I have been gradually pulling m3 support code out of gdb source files > and putting > into m3-*.c files, with only calls, etc in the original gdb source. > This should help > a bit for the next time around. But there is always lots of rework in > a later gdb > that requires corresponding rework to m3gdb. Things go away or are > replaced > by something redesigned, and it takes work to figure out what the > replacement is > and how to use it. >> >> - Jay >> >> >>> Date: Wed, 24 Jun 2009 11:18:30 -0500 >>> From: rodney.m.bates at cox.net >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress >>> >>> I have tracked down the problems I have seen with m3gdb on >>> AMD64_LINUX not recognizing object formats to a new section >>> type SHT_GNU_HASH, (and named .gnu.hash), which is present >>> in recent M3-compiled code. It appears to be handled by >>> the more recent binutils that comes in gdb 6.8, but it is >>> not handled by the binutils in gdb 6.4, from which m3gdb is >>> derived. >>> >>> I briefly tried a naive substitution of the new binutils >>> (directory 'bfd') into m3gdb, but some things have moved >>> around and there are build problems finding them. I will >>> work on this more when I get some time. >>> >>> Rodney Bates > From rodney.m.bates at cox.net Sat Jun 27 04:40:12 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Fri, 26 Jun 2009 21:40:12 -0500 Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress In-Reply-To: References: <4A4251D6.60804@cox.net> Message-ID: <4A45868C.3020001@cox.net> Jay wrote: > You should try using cvs import to upgrade to a newer version, of the > entire gdb tree (well, maybe prune it -- testsuites, sim, cpu, intl, > etc..) > I personally have never done this -- only recently imported the first > version of stuff but haven't yet updated anything. There is a _lot_ of merging work to get the m3gdb changes into a newer gdb base, including a lot of manual cleanup. I've done it. More than once. I plan to do it again, real soon now, but this was a reckless attempt at something quick and dirty. Also, there is a newest gdb release 6/9 forthcoming soon, and I think it would be nice to wait for it. I have been gradually pulling m3 support code out of gdb source files and putting into m3-*.c files, with only calls, etc in the original gdb source. This should help a bit for the next time around. But there is always lots of rework in a later gdb that requires corresponding rework to m3gdb. Things go away or are replaced by something redesigned, and it takes work to figure out what the replacement is and how to use it. > > - Jay > > > > Date: Wed, 24 Jun 2009 11:18:30 -0500 > > From: rodney.m.bates at cox.net > > To: m3devel at elegosoft.com > > Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress > > > > I have tracked down the problems I have seen with m3gdb on > > AMD64_LINUX not recognizing object formats to a new section > > type SHT_GNU_HASH, (and named .gnu.hash), which is present > > in recent M3-compiled code. It appears to be handled by > > the more recent binutils that comes in gdb 6.8, but it is > > not handled by the binutils in gdb 6.4, from which m3gdb is > > derived. > > > > I briefly tried a naive substitution of the new binutils > > (directory 'bfd') into m3gdb, but some things have moved > > around and there are build problems finding them. I will > > work on this more when I get some time. > > > > Rodney Bates From wagner at elegosoft.com Sat Jun 27 12:48:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 27 Jun 2009 12:48:03 +0200 Subject: [M3devel] link options (was LINUXLIBC6 on 64 bit Hardware) (rambly) In-Reply-To: References: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> <20090626232034.nbt6xg4sgws4w440@mail.elegosoft.com> Message-ID: <20090627124803.10mmxzjs0ks00040@mail.elegosoft.com> Quoting Jay : > [adding m3devel] > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> Subject: RE: link options (was LINUXLIBC6 on 64 bit Hardware) (rambly) >> Date: Sat, 27 Jun 2009 00:43:58 +0000 >> [...] >> Actually, now that I think about it...this is stuff that actually >> needs to be controllable from each m3makefile, and possibly from >> the cm3 command line. >> >> I used to think it was a config file thing and I'd try to make a >> reasonable choice for everyone, but now I think it's not even a >> per-machine thing but more granular. Anyway, the default is >> reasonable, just that it should probably be changable. >> >> So probably we should have new Quake directives that mimic gcc's >> command line options, like: >> SharedLibGcc(); >> StaticLibGcc(); Well, I'd have preferred some common abstraction, but then (a) making it more flexible for a certain backend is better than no flexibility at all and (b) perhaps common abstractions need to evolve gradually over time (or maybe there aren't any at all). So yes, I'm all for providing new quake switches, even if they are backend or system dependent. Of course they need to be documented in the operations guide and the quake language description, too. >> and they'd just be ignored on SOLsun, NT386, etc. >> They'd just be trivially implemented in cm3cfg.common and set a >> global that m3_link adds to the link command line, very simple. >> >> I guess this is a general exercise: See what switches in gcc/ld >> people tend to vary on a project by project basis, see which ones >> are relevant to Modula-3 (ie: more linking flags, not compile >> flags) and expose them in Quake. >> AND/OR ensure it is/remains viable for people to use Makefiles, >> combine Modula-3 with gcc using Makefiles and gcc, and just using >> cm3 to build some pieces of their project. Personally I've never >> tried that. >> That way, you know, they can just form their own link commands in a >> Makefile and Quake doesn' t have to provide full access. >> Also we could make SYSTEM_LD not readonly and leaf m3makefiles >> could just munge it. >> That is an easy way to add flexibility. Yes, I wouldn't object to that, too. 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 hosking at cs.purdue.edu Sat Jun 27 14:31:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Jun 2009 08:31:10 -0400 Subject: [M3devel] PPC_DARWIN tinderbox In-Reply-To: References: Message-ID: It just got booted up after a year away. Probably need to update. On 26 Jun 2009, at 21:35, Jay wrote: > > Tony, this is your machine? It is only run once, in a while, and > failed. > Maybe an error in your defs.sh? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jun 27 16:48:56 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 14:48:56 +0000 Subject: [M3devel] canonicalizepath?? Message-ID: DoMakeDir 1: /cm3/bin/../pkg/m3cggen/PPC_LINUX DoMakeDir 2: /cm3/bin/m3cggen/PPC_LINUX C:\dev2\cm3.2\m3-sys\m3quake\src\QMachine.m3 PROCEDURE DoMakeDir (t: T; n_args: INTEGER) RAISES {Error} = VAR val: QValue.T; dir, prefix: TEXT; BEGIN Pop (t, val); dir := QVal.ToText (t, val); prefix := Env.Get("CM3_INSTALL_PREFIX"); IF prefix # NIL THEN dir := prefix & dir; END; RTIO.PutText("DoMakeDir 1: " & dir & "\n"); dir := Pathname.Compose (CanonicalizePath (Pathname.Decompose (dir))); RTIO.PutText("DoMakeDir 2: " & dir & "\n"); RTIO.Flush(); MakeDir (t, dir); END DoMakeDir; huh? I don't think I've ever change this.. Am I expected to reverse the path before passing it through here? I'll just avoid this function.. - Jay From eiserlohpp at yahoo.com Sat Jun 27 17:04:50 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 27 Jun 2009 08:04:50 -0700 (PDT) Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Message-ID: <400447.39315.qm@web56807.mail.re3.yahoo.com> Hi Jay, On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: > > There's no need for Winzip if we use .zip files, explorer handles them. > > It is also easy to make self extracting .zip files. For installing applications on Windows boxes, why don't you use NSIS? http://nsis.sourceforge.net/Main_Page --- Quoting: From NSIS Wiki --- NSIS (Nullsoft Scriptable Install System) is a professional open source system to create Windows installers. It is designed to be as small and flexible as possible and is therefore very suitable for internet distribution. --- END QUOTE --- Please, if you go this route, don't include the source for NSIS into the M3 source archive, but the script you write that tells NSIS how to operate, yes that should be in the source archive. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat Jun 27 19:36:07 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 17:36:07 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: In-Reply-To: <400447.39315.qm@web56807.mail.re3.yahoo.com> References: <400447.39315.qm@web56807.mail.re3.yahoo.com> Message-ID: Well, it probably is better than IExpress.exe but IExpress is super easy. I'll probably stick with it and if someone has something else to replace it with they can. - Jay ---------------------------------------- > Date: Sat, 27 Jun 2009 08:04:50 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: > > > Hi Jay, > > On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: >> >> There's no need for Winzip if we use .zip files, explorer handles them. >> >> It is also easy to make self extracting .zip files. > > > For installing applications on Windows boxes, why don't > you use NSIS? > > http://nsis.sourceforge.net/Main_Page > > > --- Quoting: From NSIS Wiki --- > > NSIS (Nullsoft Scriptable Install System) is a professional open source system to create Windows installers. It is designed to be as small and flexible as possible and is therefore very suitable for internet distribution. > > --- END QUOTE --- > > Please, if you go this route, don't include the source for > NSIS into the M3 source archive, but the script you write > that tells NSIS how to operate, yes that should be in the > source archive. > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ From eiserlohpp at yahoo.com Sun Jun 28 00:53:49 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 27 Jun 2009 15:53:49 -0700 (PDT) Subject: [M3devel] Quake documentation: readonly Message-ID: <825721.23887.qm@web56808.mail.re3.yahoo.com> In the quake documentation, in the SCOPE section the keyword "readonly" is very briefly defined in the following: To protect a name in the current scope, use readonly dec = "digital" If local or readonly are not used, all variables are located in the outermost (global) scope. Beware of side-effects! Question 1: what would happen if a script attempts to modify a readonly variable? Does it quitely fail, or verbosely complain? Question 2: if a readonly variable is declared at an outer scope, and later an inner one attempts to declare a new instance with that same name, does the new name simply cover the old name, or does the attempt to declare a conflicting local variable fail (quitely, or verbosely). Picking the last one above, can we clarify this to say: To declare a name in the local scope, and prevent any further changes to it after initialization, use "readonly". When a readonly declaration occurs in the outmost scope, then a readonly variable (i.e., a constant) is declared at the global scope, an prevents any local variable with this same name being declared locally. For example: readonly dec = "digital" Alternatively, picking new local declaration succeeds: To declare a name in the local scope, and prevent any further changes to it after initialization, use "readonly". When a readonly declaration occurs in the outermost scope, then a readonly variable (i.e., a constant) is declared at the global scope. A local declaration inside an inner scope will override the global name while in that inner scope. Specifically: I am looking at creating a user config file, intending to override some settings. Something like: ---- BEGIN example user config file ---- % override debugging format from stab+ to DWARF2 format. readonly m3back_flags = "-quiet -gdwarf2 -m64 -fPIC -mno-align-double" include("usr/cm3/etc/AMD64_LINUX") ---- END user config file ---- +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sun Jun 28 08:58:41 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 28 Jun 2009 06:58:41 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: In-Reply-To: <400447.39315.qm@web56807.mail.re3.yahoo.com> References: <400447.39315.qm@web56807.mail.re3.yahoo.com> Message-ID: Ok, I take that back. Yes. Nullsoft is probably it. Thank you for the referral. IExpress seems to have a low limit on how many files it can package. I could probably build something hierarchical, but it's getting more painful. I tried out Nullsoft and it was quick easy worked well, results already surpassing iexpress, I used the gui and I expect the command line will be easy/quick/good too. I just did the zip2exe option. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: eiserlohpp at yahoo.com; m3devel at elegosoft.com > Subject: RE: [M3devel] Getting ready for new users (Re: HEADS UP: > Date: Sat, 27 Jun 2009 17:36:07 +0000 > > > Well, it probably is better than IExpress.exe but IExpress is super easy. > I'll probably stick with it and if someone has something else to replace it with they can. > > - Jay > > > ---------------------------------------- >> Date: Sat, 27 Jun 2009 08:04:50 -0700 >> From: eiserlohpp at yahoo.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: >> >> >> Hi Jay, >> >> On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: >>> >>> There's no need for Winzip if we use .zip files, explorer handles them. >>> >>> It is also easy to make self extracting .zip files. >> >> >> For installing applications on Windows boxes, why don't >> you use NSIS? >> >> http://nsis.sourceforge.net/Main_Page From wagner at elegosoft.com Sun Jun 28 14:27:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 28 Jun 2009 14:27:39 +0200 Subject: [M3devel] canonicalizepath?? In-Reply-To: References: Message-ID: <20090628142739.ryq4td9tkwkcgkow@mail.elegosoft.com> Quoting Jay : > DoMakeDir 1: /cm3/bin/../pkg/m3cggen/PPC_LINUX > DoMakeDir 2: /cm3/bin/m3cggen/PPC_LINUX > > > C:\dev2\cm3.2\m3-sys\m3quake\src\QMachine.m3 > > PROCEDURE DoMakeDir (t: T; n_args: INTEGER) RAISES {Error} = > VAR val: QValue.T; dir, prefix: TEXT; > BEGIN > > Pop (t, val); dir := QVal.ToText (t, val); > prefix := Env.Get("CM3_INSTALL_PREFIX"); > IF prefix # NIL THEN > dir := prefix & dir; > END; > RTIO.PutText("DoMakeDir 1: " & dir & "\n"); > dir := Pathname.Compose (CanonicalizePath (Pathname.Decompose (dir))); > RTIO.PutText("DoMakeDir 2: " & dir & "\n"); > RTIO.Flush(); > MakeDir (t, dir); > END DoMakeDir; > > huh? Strange :-/ > I don't think I've ever change this.. Nor did I. > Am I expected to reverse the path before passing it through here? A quick look at the function seems to show that it only correctly removes ../.. at the start of a path, if I am not mistaken. > I'll just avoid this function.. Could you (or anybody else) fix it? I'm in a hurry and won't get to it till Tuesday night... I don't think we should leave it that way... 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 Sun Jun 28 18:48:22 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 28 Jun 2009 12:48:22 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090626151238.GB4554@topoi.pooq.com> References: <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090626151238.GB4554@topoi.pooq.com> Message-ID: <20090628164822.GA11116@topoi.pooq.com> On Fri, Jun 26, 2009 at 11:12:38AM -0400, hendrik at topoi.pooq.com wrote: > On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: > > Quoting Jay : > > > > > > > >I tested the LINUXLIBC6 archive and it installed ok, no prompting. > > > > > >I ran it with no parameters -- unlike Henrik. It did mention the > > >current working directory (or its directory, same thing) as the > > >install source, which confused me. Probably as long as system.tgz > > >exists where it expects, it shouldn't say anything. > > > > Strange. > > > > Hendrik, can you reproduce the strange message? And then perhaps > > provide a system call trace (ktrace, truss, whatever)? > > > > Olaf > > I'll try. I'll probably have to rm -r /user/local/cm3 first. Anything > else I need to watch out for? I haven't done that yet. But I have a program that works on the system I managed to set up a month or so ago just by unpacking the cm3-min .tgz archive file and setting $PATH to point to its bin directory. I set the $PATH to the version I just installed (with the strangee message) deleted LINUXLIBC6, and ran the just-(mis?)installed cm3: hendrik at notlookedfor:~/mtxt$ rm LINUXLIBC6/ -r hendrik at notlookedfor:~/mtxt$ cm3 --- building in LINUXLIBC6 --- "/home/hendrik/mtxt/src/m3makefile", line 1: quake runtime error: unable to open "/var/tmp/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 1 /home/hendrik/mtxt/src/m3makefile 4 /home/hendrik/mtxt/LINUXLIBC6/m3make.args Fatal Error: package build failed hendrik at notlookedfor:~/mtxt$ which cm3 /usr/local/cm3/bin/cm3 hendrik at notlookedfor:~/mtxt$ env | grep cm PATH=/home/hendrik/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/hendrik/bin/i686/:/usr/local/cm3/bin hendrik at notlookedfor:~/mtxt$ I don't know if this could help anyone figure out what went wrong with the installation, but it does indicate that it isn't right. There's noting at all in /var/tmp. Not even a directory /vat/tmp/cm3. -- hendrik > > Now that I think of resetting ... I still had the old cm3-min > unpacked somewhere else, and I add its bin directory to the $PATH on > a bash startup. Could that have be affecting the results? > > -- hendrik > From jay.krell at cornell.edu Sun Jun 28 19:13:48 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 28 Jun 2009 17:13:48 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090628164822.GA11116@topoi.pooq.com> References: <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090626151238.GB4554@topoi.pooq.com> <20090628164822.GA11116@topoi.pooq.com> Message-ID: The packaging process stages things in /var/tmp/cm3. I bet the cm3.cfg file says INSTALL_ROOT="/var/tmp/cm3". It should be fixed, I changed it to say INSTALL_ROOT = (path() & SL & ".."). - Jay ---------------------------------------- > Date: Sun, 28 Jun 2009 12:48:22 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > On Fri, Jun 26, 2009 at 11:12:38AM -0400, hendrik at topoi.pooq.com wrote: >> On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: >>> Quoting Jay : >>> >>>> >>>>I tested the LINUXLIBC6 archive and it installed ok, no prompting. >>>> >>>>I ran it with no parameters -- unlike Henrik. It did mention the >>>>current working directory (or its directory, same thing) as the >>>>install source, which confused me. Probably as long as system.tgz >>>>exists where it expects, it shouldn't say anything. >>> >>> Strange. >>> >>> Hendrik, can you reproduce the strange message? And then perhaps >>> provide a system call trace (ktrace, truss, whatever)? >>> >>> Olaf >> >> I'll try. I'll probably have to rm -r /user/local/cm3 first. Anything >> else I need to watch out for? > > I haven't done that yet. But I have a program that works > on the system I managed to set up a month or so ago just by > unpacking the cm3-min .tgz archive file and setting $PATH to > point to its bin directory. > > I set the $PATH to the version I just installed (with the strangee > message) deleted LINUXLIBC6, and ran the just-(mis?)installed cm3: > > hendrik at notlookedfor:~/mtxt$ rm LINUXLIBC6/ -r > hendrik at notlookedfor:~/mtxt$ cm3 > --- building in LINUXLIBC6 --- > > "/home/hendrik/mtxt/src/m3makefile", line 1: quake runtime error: unable > to open "/var/tmp/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS" for reading > > --procedure-- -line- -file--- > import -- > include_dir 1 /home/hendrik/mtxt/src/m3makefile > 4 /home/hendrik/mtxt/LINUXLIBC6/m3make.args > > Fatal Error: package build failed > hendrik at notlookedfor:~/mtxt$ which cm3 > /usr/local/cm3/bin/cm3 > hendrik at notlookedfor:~/mtxt$ env | grep cm > PATH=/home/hendrik/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/hendrik/bin/i686/:/usr/local/cm3/bin > hendrik at notlookedfor:~/mtxt$ > > > I don't know if this could help anyone figure out what went wrong with > the installation, but it does indicate that it isn't right. > > There's noting at all in /var/tmp. Not even a directory /vat/tmp/cm3. > > -- hendrik > > >> >> Now that I think of resetting ... I still had the old cm3-min >> unpacked somewhere else, and I add its bin directory to the $PATH on >> a bash startup. Could that have be affecting the results? >> >> -- hendrik >> From hendrik at topoi.pooq.com Sun Jun 28 20:34:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 28 Jun 2009 14:34:58 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> References: <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> Message-ID: <20090628183458.GA11305@topoi.pooq.com> On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: > Quoting Jay : > > > > >I tested the LINUXLIBC6 archive and it installed ok, no prompting. > > > >I ran it with no parameters -- unlike Henrik. It did mention the > >current working directory (or its directory, same thing) as the > >install source, which confused me. Probably as long as system.tgz > >exists where it expects, it shouldn't say anything. > > Strange. > > Hendrik, can you reproduce the strange message? And then perhaps > provide a system call trace (ktrace, truss, whatever)? No. I have not been able to reproduce it. Tried three times: (1) with the existing preexisting incomplete /usr/local/cm3, and no references to any cm3 stuff in $PATH (2) without any /usr/local/cm3 (I used rm -r to erase it), and no references to any cm3 stuff ini $PATH (3) witout any /usr/local/cm3, and a reference to bin within the unpacked ancient cm3-min archive in my $PATH (which is how is was when I first got the message). (And this is how I've cm3-min to compile and run even though its installation failed as reported here long ago) All these installations were from the same ~hendrik/cm3 directory resulting from the archive I had unpacked a while ago when I got the strange message. I haven't downloaded a new archive since then. Maybe I should retry creating a new unpacked archive every time? Or should I just give up? -- hendrik From eiserlohpp at yahoo.com Mon Jun 29 02:25:28 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 28 Jun 2009 17:25:28 -0700 (PDT) Subject: [M3devel] Manual page for m3makefile and m3overrides files Message-ID: <939775.74319.qm@web56802.mail.re3.yahoo.com> Hi Gang, I am on a rampage this weekend. I converted the docs on the m3makefile and m3overrides files into manual pages. http://black/~peter/modula3/#mydocs Again, I place any work here listed into the public domain. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From eiserlohpp at yahoo.com Mon Jun 29 02:54:51 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 28 Jun 2009 17:54:51 -0700 (PDT) Subject: [M3devel] (no subject) Message-ID: <160850.29538.qm@web56806.mail.re3.yahoo.com> Oops, please change the host name. - http://black/~peter/modula3/#mydocs + http://www.eiserloh.org/~peter/modula3/#mydocs +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Mon Jun 29 05:08:44 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 03:08:44 +0000 Subject: [M3devel] .msi files for Windows available Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives now contains .msi files for Windows: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi These are some of the first .msi files I have ever made. I used WiX. scripts/python/make-dist.py makes them. Some of the highlights/lowlights: They always install all of what they have. There is not (yet) support for the package sets. They always modify %PATH%. It should be an option. They append to %PATH%. My intent was to prepend. (It appears obvious how, but it didn't work.) They have an uninstaller, listed in add/remove programs. Not listed in the start menu. That seems to be go either way in practise. The uninstaller does remove c:\cm3\bin from %path%, besides deleting all the files -- that didn't take any extra work. They don't put anything in the start menu. What would it be? Oh, I need to try cm3ide, which probably isn't here. The config file still just runs cl.exe/link.exe from %path%. I think the way to address this is in the config file, not setup. The default install location is c:\cm3 but user can change it. The presentation of the licenses is quite ugly. And perhaps unnecessary? Not seemingly not easy to remove, without copy/pasting some code/data with yet another license. There are accidentally two .pdbs (symbols) in the .msis. (More geerally the symbols are: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1-symbols.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1-symbols.zip and the same content without installation is at http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip ) http://modula3.elegosoft.com/cm3/uploaded-archives is a bit messy due to the volume of files, it should probably be split up. Someone please try them out and report back. I did test them. They install/uninstall, modify $path, and cm3 runs. - Jay From jay.krell at cornell.edu Mon Jun 29 05:16:37 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 03:16:37 +0000 Subject: [M3devel] .deb files Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives contains some .deb files now, but so far only for SPARC32_LINUX. I assume nobody uses that? x86/AMD64 should be available later, not soon. Highlights/lowlights: There is just min and std, no package sets yet. They install to /usr/local/cm3. You have no choice. Official .deb files are not supposed to use /usr/local, but I don't count these as official. They don't modify $PATH for you. (They don't run cminstall either.) They overlap, install just one. Maybe missing cm3ide and m3gdb, will be fixed. They are made "as a matter of course" by scripts/python/make-dist.py, for any Linux platform. There is no apt-get install foo, I have to look up how to do that, there is download (wget) the file and dpkg -i ./foo.deb. And like apt-get remove cm3-min or apt-get remove cm3-std. .deb files are actually a trivial format. They are an ar file with three files: debian-binary little marker control.tar.gz .deb specific stuff, contains text files data.tar.gz or .bz2 or .lzma the payload in the usual form That is, we could arguably not produce the loose .tgz files. - Jay From jay.krell at cornell.edu Mon Jun 29 05:18:15 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 03:18:15 +0000 Subject: [M3devel] FW: .msi files for Windows available Message-ID: Was truncated. ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: .msi files for Windows available > Date: Mon, 29 Jun 2009 03:08:44 +0000 > > > > http://modula3.elegosoft.com/cm3/uploaded-archives > > now contains .msi files for Windows: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi > > > These are some of the first .msi files I have ever made. > I used WiX. scripts/python/make-dist.py makes them. > > > Some of the highlights/lowlights: > They always install all of what they have. There is not (yet) > support for the package sets. > They always modify %PATH%. It should be an option. > They append to %PATH%. My intent was to prepend. (It appears obvious > how, but it didn't work.) > They have an uninstaller, listed in add/remove programs. > Not listed in the start menu. That seems to be go either way in practise. > The uninstaller does remove c:\cm3\bin from %path%, besides deleting > all the files -- that didn't take any extra work. > They don't put anything in the start menu. > What would it be? Oh, I need to try cm3ide, which probably isn't here. > The config file still just runs cl.exe/link.exe from %path%. > I think the way to address this is in the config file, not setup. > The default install location is c:\cm3 but user can change it. > The presentation of the licenses is quite ugly. And perhaps unnecessary? > Not seemingly not easy to remove, without copy/pasting some code/data with yet another license. > There are accidentally two .pdbs (symbols) in the .msis. > (More geerally the symbols are: > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1-symbols.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1-symbols.zip > and the same content without installation is at > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip > ) > > > http://modula3.elegosoft.com/cm3/uploaded-archives > is a bit messy due to the volume of files, > it should probably be split up. > > > Someone please try them out and report back. > I did test them. They install/uninstall, modify $path, and cm3 runs. > > > - Jay From jay.krell at cornell.edu Mon Jun 29 05:38:28 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 03:38:28 +0000 Subject: [M3devel] pruning m3cc/gcc? Message-ID: I keep thinking of deleting m3-sys/m3cc/gcc/intl m3-sys/m3cc/gcc/libgomp m3-sys/m3cc/gcc/libmudflap m3-sys/m3cc/gcc/libssp m3-sys/m3cc/gcc/fixincludes m3-sys/m3cc/gcc/libgcc We don't use any of it. Some of these deletions would shorten our build command lines. Though some (esp. fixincludes and maybe libgcc) might break the shortest configure + make that the "real" cm3 doesn't use but can be useful. I didn't include them in gcc-interix and gcc-apple. But there are two possible contradictory goals: - just have what we use/change - have a complete merged gcc tree from which you could build gcc/cc1 and not just cm3cg Except we don't have C++, Java, Ada, Fortran, so we don't really have this, but C probably counts for something. If the second is the goal, don't delete. If the first is the goal, delete. There is also "having it all there in case it is needed or somesuch", but that's easy enough to get elsewhere. - Jay From jay.krell at cornell.edu Mon Jun 29 06:29:12 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 28 Jun 2009 21:29:12 -0700 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: References: Message-ID: Truncated again I think, can't fix right now. - Jay (phone) On Jun 28, 2009, at 8:18 PM, Jay wrote: > > Was truncated. > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: .msi files for Windows available >> Date: Mon, 29 Jun 2009 03:08:44 +0000 >> >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives >> >> now contains .msi files for Windows: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >> >> >> These are some of the first .msi files I have ever made. >> I used WiX. scripts/python/make-dist.py makes them. >> >> >> Some of the highlights/lowlights: >> They always install all of what they have. There is not (yet) >> support for the package sets. >> They always modify %PATH%. It should be an option. >> They append to %PATH%. My intent was to prepend. (It appears obvious >> how, but it didn't work.) >> They have an uninstaller, listed in add/remove programs. >> Not listed in the start menu. That seems to be go either way in >> practise. >> The uninstaller does remove c:\cm3\bin from %path%, besides deleting >> all the files -- that didn't take any extra work. >> They don't put anything in the start menu. >> What would it be? Oh, I need to try cm3ide, which probably isn't here From jay.krell at cornell.edu Mon Jun 29 06:30:57 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 28 Jun 2009 21:30:57 -0700 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: References: Message-ID: <4C1F69E7-385E-4713-9431-06B561964450@hotmail.com> This also truncated.. - Jay (phone) On Jun 28, 2009, at 8:38 PM, Jay wrote: > > I keep thinking of deleting > > m3-sys/m3cc/gcc/intl > m3-sys/m3cc/gcc/libgomp > m3-sys/m3cc/gcc/libmudflap > m3-sys/m3cc/gcc/libssp > m3-sys/m3cc/gcc/fixincludes > m3-sys/m3cc/gcc/libgcc > > > We don't use any of it. > Some of these deletions would shorten our build command lines. > Though some (esp. fixincludes and maybe libgcc) might break the > shortest configure + make that the "real" cm3 doesn't use but can be > useful From hosking at cs.purdue.edu Mon Jun 29 15:41:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 29 Jun 2009 09:41:09 -0400 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: References: Message-ID: <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu> I personally like having the ability to build C from the same source tree. It's useful for debugging the backend sometimes (looking at the equivalent code generated from C). On 28 Jun 2009, at 23:38, Jay wrote: > > I keep thinking of deleting > > m3-sys/m3cc/gcc/intl > m3-sys/m3cc/gcc/libgomp > m3-sys/m3cc/gcc/libmudflap > m3-sys/m3cc/gcc/libssp > m3-sys/m3cc/gcc/fixincludes > m3-sys/m3cc/gcc/libgcc > > > We don't use any of it. > Some of these deletions would shorten our build command lines. > Though some (esp. fixincludes and maybe libgcc) might break the > shortest configure + make that the "real" cm3 doesn't use but can be > useful. > > > I didn't include them in gcc-interix and gcc-apple. > > > But there are two possible contradictory goals: > > > - just have what we use/change > - have a complete merged gcc tree from which you > could build gcc/cc1 and not just cm3cg > Except we don't have C++, Java, Ada, Fortran, > so we don't really have this, but C probably counts for something. > > > If the second is the goal, don't delete. > If the first is the goal, delete. > > > There is also "having it all there in case it is needed > or somesuch", but that's easy enough to get elsewhere. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 29 16:42:54 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 14:42:54 +0000 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu> References: <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu> Message-ID: Ok, presumably then ok to prune it just partly, like intl, libssp, libmudflap, libgomp, treelang, beyond that (fixincludes, libgcc) would require some checking/testing. Might even be worthwhile to "simplify" the m3makefile and reach a compromise that works only by some deletion. Really I wish somehow gmp/mpfr built more quickly. I often delete their source locally but can't commit that. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 29 Jun 2009 09:41:09 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pruning m3cc/gcc? > > I personally like having the ability to build C from the same source tree. It's useful for debugging the backend sometimes (looking at the equivalent code generated from C). > > On 28 Jun 2009, at 23:38, Jay wrote: > > > I keep thinking of deleting > > m3-sys/m3cc/gcc/intl > m3-sys/m3cc/gcc/libgomp > m3-sys/m3cc/gcc/libmudflap > m3-sys/m3cc/gcc/libssp > m3-sys/m3cc/gcc/fixincludes > m3-sys/m3cc/gcc/libgcc > > > We don't use any of it. > Some of these deletions would shorten our build command lines. > Though some (esp. fixincludes and maybe libgcc) might break the > shortest configure + make that the "real" cm3 doesn't use but can be useful. > > > I didn't include them in gcc-interix and gcc-apple. > > > But there are two possible contradictory goals: > > > - just have what we use/change > - have a complete merged gcc tree from which you > could build gcc/cc1 and not just cm3cg > Except we don't have C++, Java, Ada, Fortran, > so we don't really have this, but C probably counts for something. > > > If the second is the goal, don't delete. > If the first is the goal, delete. > > > There is also "having it all there in case it is needed > or somesuch", but that's easy enough to get elsewhere. > > > - Jay > From jay.krell at cornell.edu Mon Jun 29 17:32:29 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 15:32:29 +0000 Subject: [M3devel] some testing of the new web pages Message-ID: I do like the new web pages. Here are some problems though. http://www.opencm3.net/releng/collection-core.html go down to m3-sys/cm3 the builder and freebsd manual page links aren't right. I think these are maybe just CVS merge conflicts that happen to be on the packaging machine and can just be deleted. Not clear if most of the gcc links are useful. go down to TCL interfaces for M3 The browse sources link doesn't work. Probably related to this not always building and not built. Probably need to modify this and require people doing package building to have Tcl installed, maybe even for NT386. Probably specifically make-dist.sh should set $ENABLE_TCL or somesuch. (not exactly) The source links present, e.g. the licenses oddly, but compactly and probably a good thing, e.g.: http://www.opencm3.net/doc/help/gen_html/tcp/src/common/StreamRdClass.m3.html Probably an artifact of m3tohtml. http://www.opencm3.net/releng Go down the righthand side trying everything to one level. Broken: http://www.opencm3.net/releng/collection-min.html http://www.opencm3.net/releng/collection-caltech.html But there is: http://www.opencm3.net/releng/collection-caltech-parser.html It contains m3-win/import-libs but shouldn't. I suspect the problems are rooted in: min is a non-ws package set but not a ws package set. Because it is overlys small and core subsumes it? caltech-parser contains a dash. min to me is specifically enough to start with an old release and build a current compiler and release -- m3core, libm3, m3cg, cm3, maybe sysutils specifically it is the pieces required to compile anything (cm3, m3cg) and the pieces that an old compiler may not be able to build the the current versions of (m3core/libm3) that a current compiler will need; That is, if you want to build natively build the whole system from source, this is the smallest you can start with. m3cg actually isn't in min but probably handled specially. Related couments usually but not always has one extra empty bullet, including but not limited to when the list is empty: http://www.opencm3.net/releng/collection-cvsup.html http://www.opencm3.net/releng/collection-anim.html http://www.opencm3.net/releng/collection-cvsup.html http://www.opencm3.net/releng/collection-database.html http://www.opencm3.net/releng/collection-demo.html http://www.opencm3.net/releng/collection-devlib.html http://www.opencm3.net/releng/collection-game.html http://www.opencm3.net/releng/collection-gui.html This is not all the ones with an extra bullet, and a few don't have the extra bullet. I'm on the fence on the whole ws thing. Non-ws also has matching source. The point is to provide the packages both built and buildable? If cm3 had a mode that started with assemble then link and ship, we could cross build all the ws packages, very nice. I guess the "real" problem is I feel compelled then to match this feature in make-dist.py. http://www.opencm3.net/releng/collection-tool.html Try the first few links. mtex Browse sources seems incomplete but maybe is right. The man page links are all broken. cmpdir shows a general pattern: maybe directories with no files shouldn't be shown? http://www.opencm3.net/releng/collection-demo.html fisheye The link manual page .makefile isn't right http://www.opencm3.net/releng/collection-devlib.html m3tk Several broken manpage links. pex browse sources doesn't work Probably like Tcl, not always built. http://www.opencm3.net/releng/collection-anim.html zeus contains a broken Zeus manual page, I think a CVS conflict file Might be able to search for this generally in the html. http://www.opencm3.net/releng/collection-obliq.html related documents first link, to polymtl, broken, sounds promising, maybe we can find it and host it http://www.opencm3.net/releng/collection-m3gdb.html m3gdb Like m3cc, maybe some of these READMEs not useful. - Jay From hosking at cs.purdue.edu Mon Jun 29 18:01:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 29 Jun 2009 12:01:16 -0400 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: References: <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu> Message-ID: <7D2B9349-BCBA-46DE-8465-F50EEBB70F22@cs.purdue.edu> Please leave treelang. It is a good model for building gcc IR trees as done by cm3cg. On 29 Jun 2009, at 10:42, Jay wrote: > > Ok, presumably then ok to prune it just partly, like intl, libssp, > libmudflap, libgomp, treelang, beyond that (fixincludes, libgcc) > would require some checking/testing. Might even be worthwhile to > "simplify" the m3makefile and reach a compromise that works only by > some deletion. > Really I wish somehow gmp/mpfr built more quickly. I often delete > their source locally but can't commit that. > > - Jay > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Mon, 29 Jun 2009 09:41:09 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] pruning m3cc/gcc? >> >> I personally like having the ability to build C from the same >> source tree. It's useful for debugging the backend sometimes >> (looking at the equivalent code generated from C). >> >> On 28 Jun 2009, at 23:38, Jay wrote: >> >> >> I keep thinking of deleting >> >> m3-sys/m3cc/gcc/intl >> m3-sys/m3cc/gcc/libgomp >> m3-sys/m3cc/gcc/libmudflap >> m3-sys/m3cc/gcc/libssp >> m3-sys/m3cc/gcc/fixincludes >> m3-sys/m3cc/gcc/libgcc >> >> >> We don't use any of it. >> Some of these deletions would shorten our build command lines. >> Though some (esp. fixincludes and maybe libgcc) might break the >> shortest configure + make that the "real" cm3 doesn't use but can >> be useful. >> >> >> I didn't include them in gcc-interix and gcc-apple. >> >> >> But there are two possible contradictory goals: >> >> >> - just have what we use/change >> - have a complete merged gcc tree from which you >> could build gcc/cc1 and not just cm3cg >> Except we don't have C++, Java, Ada, Fortran, >> so we don't really have this, but C probably counts for something. >> >> >> If the second is the goal, don't delete. >> If the first is the goal, delete. >> >> >> There is also "having it all there in case it is needed >> or somesuch", but that's easy enough to get elsewhere. >> >> >> - Jay >> From lists at darko.org Mon Jun 29 17:43:09 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 29 Jun 2009 17:43:09 +0200 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: References: Message-ID: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Are we going to have Installer packages for Darwin PPC/Intel too or is there some reason not too? On 29/06/2009, at 5:18 AM, Jay wrote: > > Was truncated. > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: .msi files for Windows available >> Date: Mon, 29 Jun 2009 03:08:44 +0000 >> >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives >> >> now contains .msi files for Windows: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >> >> >> These are some of the first .msi files I have ever made. >> I used WiX. scripts/python/make-dist.py makes them. >> >> >> Some of the highlights/lowlights: >> They always install all of what they have. There is not (yet) >> support for the package sets. >> They always modify %PATH%. It should be an option. >> They append to %PATH%. My intent was to prepend. (It appears obvious >> how, but it didn't work.) >> They have an uninstaller, listed in add/remove programs. >> Not listed in the start menu. That seems to be go either way in >> practise. >> The uninstaller does remove c:\cm3\bin from %path%, besides deleting >> all the files -- that didn't take any extra work. >> They don't put anything in the start menu. >> What would it be? Oh, I need to try cm3ide, which probably isn't here From jay.krell at cornell.edu Mon Jun 29 19:15:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:15:52 +0000 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> References: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Message-ID: Eventually, but not by me probably for at least a week or a month or more. RPM too. It should probably come before Mac. Except that I don't have any Suse/RedHat/YellowDog/Mandrake/Mandriva systems now, having settled pretty exclusively on Debian (plus the Fit PC that came with Gentoo preinstalled), so I don't know. *BSD also should get some attention. But I don't see me getting to that for a while. It would be nice to compete with the ezm3 port that is out there. It builds from assembly source, which is good, to see there is a precedent we can follow. There are a lot of other formats but I probably won't get to any of them. HP-UX, Solaris, AIX, Irix all have something, and no users. I don't know yet about Tru64 and VMS. Btw, the DESTDIR-like feature that (you?) added to cm3 isn't really needed. You can just $CM3_INSTALL and it does basically the same thing. Look at Olaf's make-dist.sh. It gets a lot done with little code using simple techniques. But I'm still sticking to Python. :) I don't think the DESTDIR-like feature handled runpaths or config files as well, which are mostly moot now. (Really..runpath solved by $ORIGIN, but $ORIGIN doesn't solve the problem. $ORIGIN lets you move a set of files together, good, but it doesn't help the situation where you want to move just some of them.) - Jay ---------------------------------------- > From: lists at darko.org > To: jay.krell at cornell.edu > Date: Mon, 29 Jun 2009 17:43:09 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: .msi files for Windows available > > Are we going to have Installer packages for Darwin PPC/Intel too or is > there some reason not too? > > > On 29/06/2009, at 5:18 AM, Jay wrote: > >> >> Was truncated. >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Subject: .msi files for Windows available >>> Date: Mon, 29 Jun 2009 03:08:44 +0000 >>> >>> >>> >>> http://modula3.elegosoft.com/cm3/uploaded-archives >>> >>> now contains .msi files for Windows: >>> >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>> >>> >>> These are some of the first .msi files I have ever made. >>> I used WiX. scripts/python/make-dist.py makes them. >>> >>> >>> Some of the highlights/lowlights: >>> They always install all of what they have. There is not (yet) >>> support for the package sets. >>> They always modify %PATH%. It should be an option. >>> They append to %PATH%. My intent was to prepend. (It appears obvious >>> how, but it didn't work.) >>> They have an uninstaller, listed in add/remove programs. >>> Not listed in the start menu. That seems to be go either way in >>> practise. >>> The uninstaller does remove c:\cm3\bin from %path%, besides deleting >>> all the files -- that didn't take any extra work. >>> They don't put anything in the start menu. >>> What would it be? Oh, I need to try cm3ide, which probably isn't here > From jay.krell at cornell.edu Mon Jun 29 19:23:39 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:23:39 +0000 Subject: [M3devel] pruning m3cc/gcc? Message-ID: [trying to untruncate again, though I think Tony quoted the whole thing] ---------------------------------------- > From: jay > To: m3devel; hosking > Subject: pruning m3cc/gcc? > Date: Mon, 29 Jun 2009 03:38:28 +0000 > > > I keep thinking of deleting > [snip, parts of gcc] > > We don't use any of it. > Some of these deletions would shorten our build command lines. > Though some (esp. fixincludes and maybe libgcc) might break the > shortest configure + make that the "real" cm3 doesn't use but can be useful. > > > I didn't include them in gcc-interix and gcc-apple. > > > But there are two possible contradictory goals: > > > - just have what we use/change > - have a complete merged gcc tree from which you > could build gcc/cc1 and not just cm3cg > Except we don't have C++, Java, Ada, Fortran, > so we don't really have this, but C probably counts for something. > > > If the second is the goal, don't delete. > If the first is the goal, delete. > > > There is also "having it all there in case it is needed > or somesuch", but that's easy enough to get elsewhere. > > > - Jay From jay.krell at cornell.edu Mon Jun 29 19:21:07 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:21:07 +0000 Subject: [M3devel] .msi files for Windows available Message-ID: [trying to untruncate again, I forget if it is forward or replayall that untruncates] ---------------------------------------- > From: jay > > > Was truncated. > > > ---------------------------------------- >> From: jay >> To: m3devel >> Subject: .msi files for Windows available >> Date: Mon, 29 Jun 2009 03:08:44 +0000 >> >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives >> >> now contains .msi files for Windows: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >> >> >> These are some of the first .msi files I have ever made. >> I used WiX. scripts/python/make-dist.py makes them. >> >> >> Some of the highlights/lowlights: >> They always install all of what they have. There is not (yet) >> support for the package sets. >> They always modify %PATH%. It should be an option. >> They append to %PATH%. My intent was to prepend. (It appears obvious >> how, but it didn't work.) >> They have an uninstaller, listed in add/remove programs. >> Not listed in the start menu. That seems to be go either way in practise. >> The uninstaller does remove c:\cm3\bin from %path%, besides deleting >> all the files -- that didn't take any extra work. >> They don't put anything in the start menu. [approximate point of truncation] >> What would it be? Oh, I need to try cm3ide, which probably isn't here. >> The config file still just runs cl.exe/link.exe from %path%. >> I think the way to address this is in the config file, not setup. >> The default install location is c:\cm3 but user can change it. >> The presentation of the licenses is quite ugly. And perhaps unnecessary? >> Not seemingly not easy to remove, without copy/pasting some code/data with yet another license. >> There are accidentally two .pdbs (symbols) in the .msis. >> (More geerally the symbols are: >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1-symbols.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1-symbols.zip >> and the same content without installation is at >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip >> ) >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives >> is a bit messy due to the volume of files, >> it should probably be split up. >> >> >> Someone please try them out and report back. >> I did test them. They install/uninstall, modify $path, and cm3 runs. >> >> >> - Jay From jay.krell at cornell.edu Mon Jun 29 19:40:02 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:40:02 +0000 Subject: [M3devel] .msi files for Windows available In-Reply-To: References: Message-ID: Was truncated again.. ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 29 Jun 2009 17:21:07 +0000 > Subject: Re: [M3devel] .msi files for Windows available > > > [trying to untruncate again, I forget if it is forward or replayall that untruncates] > > > ---------------------------------------- >> From: jay >> >> >> Was truncated. >> >> >> ---------------------------------------- [deliberately truncated this time] From jay.krell at cornell.edu Mon Jun 29 19:41:32 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:41:32 +0000 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> References: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Message-ID: [was severely truncated darnit] ---------------------------------------- > From: jay.krell at cornell.edu > To: lists at darko.org > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: .msi files for Windows available > Date: Mon, 29 Jun 2009 17:15:52 +0000 > > > Eventually, but not by me probably for at least a week or a month or more. > > > RPM too. It should probably come before Mac. > Except that I don't have any Suse/RedHat/YellowDog/Mandrake/Mandriva systems now, having settled pretty exclusively on Debian (plus the Fit PC that came with Gentoo preinstalled), so I don't know. > > > *BSD also should get some attention. > But I don't see me getting to that for a while. > It would be nice to compete with the ezm3 port that is out there. > It builds from assembly source, which is good, to see there is a precedent we can follow. > > > There are a lot of other formats but I probably won't get to any of them. > HP-UX, Solaris, AIX, Irix all have something, and no users. > I don't know yet about Tru64 and VMS. > > > Btw, the DESTDIR-like feature that (you?) added to cm3 isn't really needed. > You can just $CM3_INSTALL and it does basically the same thing. > Look at Olaf's make-dist.sh. > It gets a lot done with little code using simple techniques. > But I'm still sticking to Python. :) > > > I don't think the DESTDIR-like feature handled runpaths or config files as well, which are mostly moot now. > > > (Really..runpath solved by $ORIGIN, but $ORIGIN doesn't solve the problem. $ORIGIN lets you move a set of files together, good, but it doesn't help the situation where you want to move just some of them.) > > > - Jay > > > ---------------------------------------- >> From: lists at darko.org >> To: jay.krell at cornell.edu >> Date: Mon, 29 Jun 2009 17:43:09 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] FW: .msi files for Windows available >> >> Are we going to have Installer packages for Darwin PPC/Intel too or is >> there some reason not too? >> >> [deliberately truncated] From jay.krell at cornell.edu Mon Jun 29 19:52:04 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:52:04 +0000 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: References: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Message-ID: > [was severely truncated darnit trying again and with additional tactics..] I put it here assuming it is truncated again: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt http://modula3.elegosoft.com/cm3/uploaded-archives is a bit messy due to the volume of files, it should probably be split up? Someone please try them out and report back. I did test them. They install/uninstall, modify $path, and cm3 runs. Some of the highlights/lowlights: They always install all of what they have. There is not (yet) support for the package sets. They always modify %PATH%. It should be an option. They append to %PATH%. My intent was to prepend. (It appears obvious how, but it didn't work.) They have an uninstaller, listed in add/remove programs. Not listed in the start menu. That seems to be go either way in practise. The uninstaller does remove c:\cm3\bin from %path%, besides deleting all the files -- that didn't take any extra work. They don't put anything in the start menu. [approximate truncation point ...] What would it be? Oh, I need to try cm3ide, which probably isn't here. The config file still just runs cl.exe/link.exe from %path%. I think the way to address this is in the config file, not setup. The default install location is c:\cm3 but user can change it. The presentation of the licenses is quite ugly. And perhaps unnecessary? Not seemingly not easy to remove, without copy/pasting some code/data with yet another license. There are accidentally two .pdbs (symbols) in the .msis. (More geerally the symbols are: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1-symbols.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1-symbols.zip and the same content without installation is at http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip ) - Jay From lists at darko.org Mon Jun 29 22:45:08 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 29 Jun 2009 22:45:08 +0200 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: References: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Message-ID: <7B6DD6CB-BFB0-405C-A4B4-00EA1340A82E@darko.org> DESTDIR wasn't me. On 29/06/2009, at 7:15 PM, Jay wrote: > > Eventually, but not by me probably for at least a week or a month or > more. > > > RPM too. It should probably come before Mac. > Except that I don't have any Suse/RedHat/YellowDog/Mandrake/ > Mandriva systems now, having settled pretty exclusively on Debian > (plus the Fit PC that came with Gentoo preinstalled), so I don't know. > > > *BSD also should get some attention. > But I don't see me getting to that for a while. > It would be nice to compete with the ezm3 port that is out there. > It builds from assembly source, which is good, to see there is a > precedent we can follow. > > > There are a lot of other formats but I probably won't get to any of > them. > HP-UX, Solaris, AIX, Irix all have something, and no users. > I don't know yet about Tru64 and VMS. > > > Btw, the DESTDIR-like feature that (you?) added to cm3 isn't really > needed. > You can just $CM3_INSTALL and it does basically the same thing. > Look at Olaf's make-dist.sh. > It gets a lot done with little code using simple techniques. > But I'm still sticking to Python. :) > > > I don't think the DESTDIR-like feature handled runpaths or config > files as well, which are mostly moot now. > > > (Really..runpath solved by $ORIGIN, but $ORIGIN doesn't solve the > problem. $ORIGIN lets you move a set of files together, good, but it > doesn't help the situation where you want to move just some of them.) > > > - Jay > > > ---------------------------------------- >> From: lists at darko.org >> To: jay.krell at cornell.edu >> Date: Mon, 29 Jun 2009 17:43:09 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] FW: .msi files for Windows available >> >> Are we going to have Installer packages for Darwin PPC/Intel too or >> is >> there some reason not too? >> >> >> On 29/06/2009, at 5:18 AM, Jay wrote: >> >>> >>> Was truncated. >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Subject: .msi files for Windows available >>>> Date: Mon, 29 Jun 2009 03:08:44 +0000 >>>> >>>> >>>> >>>> http://modula3.elegosoft.com/cm3/uploaded-archives >>>> >>>> now contains .msi files for Windows: >>>> >>>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >>>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>>> >>>> >>>> These are some of the first .msi files I have ever made. >>>> I used WiX. scripts/python/make-dist.py makes them. >>>> >>>> >>>> Some of the highlights/lowlights: >>>> They always install all of what they have. There is not (yet) >>>> support for the package sets. >>>> They always modify %PATH%. It should be an option. >>>> They append to %PATH%. My intent was to prepend. (It appears >>>> obvious >>>> how, but it didn't work.) >>>> They have an uninstaller, listed in add/remove programs. >>>> Not listed in the start menu. That seems to be go either way in >>>> practise. >>>> The uninstaller does remove c:\cm3\bin from %path%, besides >>>> deleting >>>> all the files -- that didn't take any extra work. >>>> They don't put anything in the start menu. >>>> What would it be? Oh, I need to try cm3ide, which probably isn't >>>> here >> From wagner at elegosoft.com Tue Jun 30 09:28:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 30 Jun 2009 09:28:26 +0200 Subject: [M3devel] release build broken Message-ID: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> The last commit to pkginfo.txt broke the Tinderbox release build: End of Log File "../src/Main.m3", line 4: unable to find interface (WinNT) "../src/Main.m3", line 5: unable to find interface (WinDef) compilation failed => not building program "mklib" Fatal Error: package build failed *** execution of cm3 -build -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? -DCM3_LAST_CHANGED=?2009-05-16? $RARGS && cm3 -ship $RARGS -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? -DCM3_LAST_CHANGED=?2009-05-16? failed *** Please fix. 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 Jun 30 11:07:50 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 30 Jun 2009 09:07:50 +0000 Subject: [M3devel] release build broken In-Reply-To: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> References: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> Message-ID: Ah, only the release build but not the latest, makes sense. These weren't in m3core in older version. Will fix. After this release I can put it back. - Jay ---------------------------------------- > Date: Tue, 30 Jun 2009 09:28:26 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release build broken > > The last commit to pkginfo.txt broke the Tinderbox release build: > > End of Log File > "../src/Main.m3", line 4: unable to find interface (WinNT) > "../src/Main.m3", line 5: unable to find interface (WinDef) > compilation failed => not building program "mklib" > Fatal Error: package build failed > *** execution of cm3 -build > -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? > -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? > -DCM3_LAST_CHANGED=?2009-05-16? $RARGS && cm3 -ship $RARGS > -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? > -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? > -DCM3_LAST_CHANGED=?2009-05-16? failed *** > > > Please fix. > > 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 wagner at elegosoft.com Tue Jun 30 18:27:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 30 Jun 2009 18:27:28 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090628183458.GA11305@topoi.pooq.com> References: <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090628183458.GA11305@topoi.pooq.com> Message-ID: <20090630182728.3604voxlcsococs0@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: >> Quoting Jay : >> >> > >> >I tested the LINUXLIBC6 archive and it installed ok, no prompting. >> > >> >I ran it with no parameters -- unlike Henrik. It did mention the >> >current working directory (or its directory, same thing) as the >> >install source, which confused me. Probably as long as system.tgz >> >exists where it expects, it shouldn't say anything. >> >> Strange. >> >> Hendrik, can you reproduce the strange message? And then perhaps >> provide a system call trace (ktrace, truss, whatever)? > > No. I have not been able to reproduce it. Tried three times: > (1) with the existing preexisting incomplete /usr/local/cm3, and no > references to any cm3 stuff in $PATH > (2) without any /usr/local/cm3 (I used rm -r to erase it), and no > references to any cm3 stuff ini $PATH > (3) witout any /usr/local/cm3, and a reference to bin within the > unpacked ancient cm3-min archive in my $PATH (which is how is was when I > first got the message). (And this is how I've cm3-min to compile and > run even though its installation failed as reported here long ago) > > All these installations were from the same ~hendrik/cm3 directory > resulting from the archive I had unpacked a while ago when I got the > strange message. I haven't downloaded a new archive since then. Maybe > I should retry creating a new unpacked archive every time? Or should I > just give up? If it now just works and the problem cannot be reproduced, we should leave it that way. I wouldn't invest much time on chasing down such a spurious error now. 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 Tue Jun 30 19:52:28 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 30 Jun 2009 13:52:28 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090630182728.3604voxlcsococs0@mail.elegosoft.com> References: <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090628183458.GA11305@topoi.pooq.com> <20090630182728.3604voxlcsococs0@mail.elegosoft.com> Message-ID: <20090630175228.GA16767@topoi.pooq.com> On Tue, Jun 30, 2009 at 06:27:28PM +0200, Olaf Wagner wrote: > > If it now just works and the problem cannot be reproduced, we should > leave it that way. I wouldn't invest much time on chasing down such > a spurious error now. OK. I'll take a look at installation instructions for some of the other packages, such as the one with Trestle. -- hendrik From hosking at cs.purdue.edu Mon Jun 1 01:01:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 1 Jun 2009 09:01:55 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> Jay, things changed from gcc 3.2 to 3.3. 3.3 works fine for me on all the h/w targets I've tried using -O3 (PPC, x86, AMD64, SPARC). I suspect this is specific to your gcc-apple hybrid. On 1 Jun 2009, at 00:49, Jay wrote: > 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 jay.krell at cornell.edu Mon Jun 1 18:46:38 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 1 Jun 2009 16:46:38 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> References: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> Message-ID: It isn't related to optimization. I don't think it is 4.2/4.3 specific. I'll try to show an example later (MIPS64_OPENBSD and, never looked at them, but maybe othar arm/mips will show it). - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 1 Jun 2009 09:01:55 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] m3_load/store using bitfields for everything Jay, things changed from gcc 3.2 to 3.3. 3.3 works fine for me on all the h/w targets I've tried using -O3 (PPC, x86, AMD64, SPARC). I suspect this is specific to your gcc-apple hybrid. On 1 Jun 2009, at 00:49, Jay wrote: 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 rodney.m.bates at cox.net Mon Jun 1 21:32:33 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 01 Jun 2009 14:32:33 -0500 Subject: [M3devel] Some workarounds for m3gdb input and output of floating values. Message-ID: <4A242CD1.10504@cox.net> I recently committed a couple of changes that give m3gdb some very tenuous support of floating values. Printing them appears to work in a few tests on LINUXLIBC6. This relies on the preexisting C floating support, but this really needs some more thorough review. Moreover, Modula-3 style floating literals are not being recognized. Until it is fixed right, here are some ways to work around its limitations. They are a bit tedious, but should allow you to do what you need to do, using m3gdb calls on Modula-3 library code. The idea is just to call procedures in Lex, Fmt, etc. To print a value in Modula-3 form, do, e.g.: (m3gdb) print Fmt.Real(LF,Fmt.Style.Fix,10,FALSE) $1 = (*16_b737876c*) "1.1250000000" Note that m3gdb has no knowledge of defaulted parameters, so you have to supply them all explicitly. To assign a literal value, do, e.g.: (m3gdb) print LF := Lex.Real(TextRd.New("2.375")) $2 = 2.375 (m3gdb) p Fmt.Real(LF,Fmt.Style.Fix,10,FALSE) $3 = (*16_b73787dc*) "2.3750000000" Few or none of these calls will work unless Lex, Fmt, and TextRd are imported somewhere in the import closure of your program. Otherwise, they have uninitialized data and many will segfault or otherwise fail when called by m3gdb. Rodney Bates From hosking at cs.purdue.edu Tue Jun 2 02:04:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 2 Jun 2009 10:04:37 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> Message-ID: <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> The compiler and run-time support is already in the CVS head. On 1 Jun 2009, at 22:21, Darko wrote: > This is a great little hack. Is it available now or are you still > working on it? I don't know what other people want to use it for but > this is a great way to link memory structures with external data. It > overcomes one of the downsides of GC compared to say C, where you > can use pointer values for other purposes, but it does it safely. > > Also I'd like to add my voice for the minimalist approach where no > language changes are made. I don't think there is a semantically > clean way of incorporating this into the language and I'm not sure > there is any payoff in doing so. > > > > On 23/04/2009, at 3:07 AM, Tony Hosking wrote: > >> On 23 Apr 2009, at 09:41, Mika Nystrom wrote: >> >>> "Rodney M. Bates" writes: >>>> Tony Hosking wrote: >>>>> On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: >>>>> >>>>>> I am going to try to resummarize the various proposals, as their >>>>>> description has now gotten rather scattered around in all the >>>>>> discussion. >>>>>> --------------------------------------------------------------------- >>>>>> Mika's proposal (I'll call it the "minimalist" propsal): >>>>>> >>>>>> Mika, please correct me if I misrepresent what you are proposing. >>>>>> >>>>>> There are no language changes at all, only changes in >>>>>> implementation. >>>>>> The implementation of the existing type REFANY, and no other >>>>>> type, >>>>>> allows it to have values whose lsb is nonzero. ISTYPE, NARROW, >>>>>> TYPECASE, and narrowing assignments, when and only when applied >>>>>> to >>>>>> REFANY, have their generated code fixed so it checks the lsb, >>>>>> and, if >>>>>> it is nonzero, consider the runtime type check to have failed, in >>>>>> whichever way such a failure is already handled. >>>>>> >>>>>> The only effect is to liberalize the rules unsafe code must >>>>>> follow to >>>>>> avoid undermining the safety of safe code. Only unsafe code can >>>>>> create or detect these misaligned values. Today, it must never >>>>>> return >>>>>> them in a variable of any reference type, lest the four narrowing >>>>>> operations unexpectedly crash. In the proposal, unsafe code >>>>>> would be >>>>>> able to return such values in variables of type REFANY, but not >>>>>> any >>>>>> other type. >>> >>> This is pretty much exactly what I was proposing, yes. >>> >>> Only one point to add, and that is that you need a TYPECODE value. >> >> Yes. I currently have a full-blown implementation in the compiler >> and run-time that uses RT0.RefanyTypecode as the typecode. Since >> the only thing that will respond with the typecode are tagged >> references, and it is not legal to say TYPECODE(REFANY) we can hide >> that fact in an implementation of the tagged interface where we use >> TYPECODE(r) = RT0.RefanyTypecode, or ISTYPE(r, >> RT0.RefanyTypecode). Currently, no other type in the system will >> respond with that. >> >>> I think Tony and I discussed having all the ISTYPE etc. behave as >>> if the tagged values were of a specific opaque type that cannot be >>> dereferenced, newed, etc., in safe modules. (I.e., revealed as <: >>> REFANY only) >> >> Done (modulo what typecode to use as described above). >> >>> This seems conceptually simpler than introducing a "nonexistent" >>> type, and has the same safety properties. >>> >>>>> >>>>> I don't see why we can't have safe creation of the misaligned >>>>> values >>>>> as per Mika's interface. >>>> >>>> Well, somebody has to implement that interface, and that module >>>> will >>>> have to be UNSAFE. >>>> You weren't thinking of implementing it in C were you? ;-) >>> >>> I don't see how to do it "safely" unless you add it to the compiler >>> itself? (Which means it's no longer minimalist!) >> >> It would be hidden behind a safe interface. >> >>>>>> Already, the only things safe code can do with values of REFANY >>>>>> are >>>>>> copy them around (which would happily work on misaligned >>>>>> values) and >>>>>> narrow them. With the implementation of the narrowing operations >>>>>> changed, misaligned values can never escape from REFANY >>>>>> variables. >>>>>> >>>>>> In safe code, there is no way to detect whether a value of type >>>>>> REFANY >>>>>> is misaligned. Doing it by elimination, trying to narrow to any >>>>>> proper subtype of REFANY, is impractical, as there are an >>>>>> unbounded >>>>>> number of REF types to eliminate. >>>>> >>>>> An alternative would be to loosen the language spec to allow >>>>> TYPECODE(REFANY) and use this typecode for tagged references. >>>>> Then >>>>> one can explicitly test for it without elimination of >>>>> alternatives. >>> >>> Yes you could do this or use the specific type idea mentioned above. >>> >>> I don't see what harm there is in letting a safe module know that >>> it's holding a tagged value. Nothing it can do with that >>> information >>> anyhow... it can't extract the value. >>> >>>>> >>>>>> If there is more than one abstract data type that uses this >>>>>> mechanism, >>>>>> client code can not be prevented from mixing up values from the >>>>>> different abstractions. (Perhaps this could be fixed by a >>>>>> language >>>>>> change allowing BRANDED REFANY?) >>>>> >>>>> Indeed. >>> >>> Right. As it stands, the clients would have to sort on what's going >>> on inside. No help from compiler or runtime. You can't do anything >>> about what's checkable at runtime, but adding TAGGED could let you >>> check a lot of things at compile time. >>> >>> I still think, though (referring to what's below), that the >>> advantage >>> of not having to change existing "container" code outweighs the >>> cost of checking the LSB (which is likely to be negligble), and I >>> would >>> therefore recommend that the type called "REFANY" be able to hold >>> "TAGGED" >>> values after such a language change. >> >> Right. >> >>> >>> >>> Mika >>> >>>>> >>>>>> --------------------------------------------------------------------- >>>>>> My (Rodney's) "safe" proposal: >>>>>> >>>>>> There is a new type named TAGABLE. It is a subrange of >>>>>> INTEGER, whose >>>>>> bounds are implementation-defined. These can be queried by the >>>>>> existing FIRST and LAST functions. Similar to CARDINAL, it has >>>>>> all >>>>>> the properties of a subrange type but is not the same type as the >>>>>> corresponding subrange. >>>>>> >>>>>> There is a new type constructor TAGGED. If T is any traced or >>>>>> object >>>>>> type, including branded and opaque types, then TAGGED T is a >>>>>> new type >>>>>> whose value set is the union of the value sets of T and TAGABLE. >>>>>> Moreover, >>>>>> >>>>>> TAGABLE <: TAGGED T >>>>>> T <: TAGGED T. >>>>>> >>>>>> IF T # U, then TAGGED T and TAGGED U are not the same type and >>>>>> have no >>>>>> subtype or assignability relation to each other. >>>>>> >>>>>> The semantics of ISTYPE, NARROW, TYPECASE, and assignability of >>>>>> a type >>>>>> to a type are generalized so that their to-be-narrowed operand >>>>>> can >>>>>> have a tagged type, and if it does, their to-be-narrowed-to >>>>>> type can >>>>>> be TAGABLE. >>>>> >>>>> Hmm. It seems there is a nasty loophole in your spec. >>>>> Consider: >>>>> >>>>> TYPE T = BRANDED OBJECT END >>>>> TYPE U = BRANDED OBJECT END >>>>> >>>>> These are unrelated types. >>>>> >>>>> Now, the rules let me take: >>>>> >>>>> t: TAGGED T >>>>> >>>>> and obtain: >>>>> >>>>> i: TAGABLE := NARROW(t, TAGABLE); >>>>> >>>>> But TAGABLE <: TAGGED U >>>>> >>>>> so I can do: >>>>> >>>>> u: TAGGED U := t; >>>>> >>>>> Is that your intention? >>>>> >>>>>> >>>>>> >>>>>> Comments: >>>>>> >>>>>> Making TAGGED T have no relation to TAGGED U avoids a lot of >>>>>> really >>>>>> complicated type equality and subtype rules. The former would >>>>>> be a >>>>>> drastic departure from the current state of Modula-3. >>>>>> >>>>>> It is up to the implementation to decide the bit representation >>>>>> of >>>>>> tagged types, including how values of TAGABLE will be >>>>>> distinguished >>>>>> from reference values. Though the language would not require >>>>>> it, most >>>>>> likely a word the same size as a pointer will be used. Using >>>>>> the lsb >>>>>> as the tag bit is an efficient encoding, because in any currently >>>>>> conceivable machine, it will be zero for all pointers to heap >>>>>> objects. >>>>>> There is no reason pickles would have to use the same >>>>>> representation >>>>>> as compiler-generated code. >>>>>> >>>>>> The implementation should define the bounds of TAGABLE to be >>>>>> whatever >>>>>> it can fit in its representation, after removing the values >>>>>> that are >>>>>> true pointers. If the lsb is used as a tag, this will no doubt >>>>>> be a >>>>>> 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit >>>>>> machine. The language wouldn't even specify whether it is >>>>>> signed, >>>>>> although somehow unsigned seems nice to me. If it is unsigned >>>>>> and the >>>>>> suggested encodings are used, TAGABLE would have the same >>>>>> bounds as >>>>>> CARDINAL, but it really should be a separate type, so as not to >>>>>> overconstrain the implementation. >>>>>> >>>>>> If T is branded, then the effects of branding will propagate to >>>>>> TAGGED >>>>>> T, thus allowing independent abstract data types to ensure each >>>>>> one's >>>>>> values can't be mixed up with the other's. This will statically >>>>>> detect misuses by client code. However, TAGGED T is not a >>>>>> branded >>>>>> type. >>>>>> >>>>>> If T is an opaque type, then TAGGED T can be used to combine >>>>>> the space >>>>>> efficiency of tagging with the ability of an opaque type to >>>>>> reveal >>>>>> some but not all of its properties. To use this, client code >>>>>> will >>>>>> have to narrow a value first, since access to methods/fields >>>>>> could not >>>>>> have a definable meaning for a value in TAGABLE. >>>>>> >>>>>> On the other hand, T could be an opaque subtype of REFANY, thus >>>>>> revealing almost nothing about TAGGED T to clients. This would >>>>>> give >>>>>> tagged types the existing ability of ensuring statically, that >>>>>> the >>>>>> code in a revealed context will never get TAGGED REFANY, thus >>>>>> avoiding >>>>>> extra runtime type checks. >>>>> >>>>> >> From jay.krell at cornell.edu Tue Jun 2 12:20:30 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 2 Jun 2009 10:20:30 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> References: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> Message-ID: ARM_LINUX looks ok. Now..I experimented with the size/alignment of the module-globals. If I decrease them to 8, it infects the uses of "components" of it (bitfields). RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.102 diff -u -r1.102 parse.c @@ -2989,7 +2989,7 @@ gcc doesn't think it fits in a register, so that loads out of it do get their offsets applied. */ TREE_TYPE (v) - = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT); + = m3_build_type (T_struct, 8, 8); layout_decl (v, BIGGEST_ALIGNMENT); TYPE_UNSIGNED (TREE_TYPE (v)) = 1; TREE_STATIC (v) = 1; bl RTOS__Write(PLT) .stabn 68,0,79,.LM45-.LFBB8 .LM45: ldr r3, .L40+4 ldr r1, [fp, #-16] ldr r2, [r1, r3] ldrb r1, [r2, #52] mov r3, #0 mov r1, r3 strb r1, [r2, #52] Those "b for byte" shouldn't be there. The problem is more obvious on the reads -- lots of shifting and masking. .stabn 68,0,78,.LM44-.LFBB8 .LM44: ldr r3, .L40+4 ldr r1, [fp, #-16] ldr r2, [r1, r3] ldrb r3, [r2, #52] and r1, r3, #255 ldrb r3, [r2, #53] and r3, r3, #255 mov r3, r3, asl #8 orr r1, r3, r1 ldrb r3, [r2, #54] and r3, r3, #255 mov r3, r3, asl #16 orr r1, r3, r1 mov r3, r3, asl #16 orr r1, r3, r1 ldrb r3, [r2, #55] and r3, r3, #255 mov r3, r3, asl #24 orr r3, r3, r1 cmp r3, #0 ble .L39 Now, I grant that this "experiment" is a bit of garbage in, garbage out, but I think showing that the size/alignment of a symbol that we use merely for generating offsets from has big affects is a little worrisome. Ok, I grant, if this is just ensuring aligned reads, that's reasonable. I should twiddle just the size and not the alignment. "To be constructive" if I managed to form a patch that declared the module-globals to a be struct (record) with well described/typed/sized/aligned "components" (fields/members/etc.) and we used..hm..it seems we never access fields, just offsets? sentence was going to end "..that'd be a reasonable change?" Eh, for now probably not worth it, it does work given the large size/alignment and slow path for iphone, other stuff to do... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] m3_load/store using bitfields for everything Date: Mon, 1 Jun 2009 16:46:38 +0000 It isn't related to optimization. I don't think it is 4.2/4.3 specific. I'll try to show an example later (MIPS64_OPENBSD and, never looked at them, but maybe othar arm/mips will show it). - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 1 Jun 2009 09:01:55 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] m3_load/store using bitfields for everything Jay, things changed from gcc 3.2 to 3.3. 3.3 works fine for me on all the h/w targets I've tried using -O3 (PPC, x86, AMD64, SPARC). I suspect this is specific to your gcc-apple hybrid. On 1 Jun 2009, at 00:49, Jay wrote: 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 hendrik at topoi.pooq.com Tue Jun 2 12:31:52 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 2 Jun 2009 06:31:52 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> Message-ID: <20090602103152.GA2916@topoi.pooq.com> On Tue, Jun 02, 2009 at 10:04:37AM +1000, Tony Hosking wrote: > The compiler and run-time support is already in the CVS head. > > On 1 Jun 2009, at 22:21, Darko wrote: > > >This is a great little hack. Is it available now or are you still > >working on it? I don't know what other people want to use it for but > >this is a great way to link memory structures with external data. It > >overcomes one of the downsides of GC compared to say C, where you > >can use pointer values for other purposes, but it does it safely. > > > >Also I'd like to add my voice for the minimalist approach where no > >language changes are made. I don't think there is a semantically > >clean way of incorporating this into the language and I'm not sure > >there is any payoff in doing so. I think there is a semantically clean way of incorporating it into the language, but it's not a trivial change. It becomes an optimisable special case of a more general feature -- for any bunch of types A, B, C, ... you introduce a type UNION(A, B, C, ...). There's nothing you can do with a union except build it from an A, B, or C ..., copy it, and test its type and extract the contents -- more or less what you can do to one of our type-tagged values. These unions have a fixed size (more or less the max of the sizes of A, B, C, ... and an extra type-tag. (I don't know if there has to be a restriction on using open arrays here; I hole not.) In the special case of UNION(A, B), where B is a suitable subrange if INTEGER and A is a pointer-to-object, the compiler could choose to implement this with our low-bit-and-shift hack. -- hendrik From hosking at cs.purdue.edu Tue Jun 2 12:51:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 2 Jun 2009 20:51:31 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20090602103152.GA2916@topoi.pooq.com> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> Message-ID: <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> Union types are anathema to the design of the Modula-3 type system. On 2 Jun 2009, at 20:31, hendrik at topoi.pooq.com wrote: > On Tue, Jun 02, 2009 at 10:04:37AM +1000, Tony Hosking wrote: >> The compiler and run-time support is already in the CVS head. >> >> On 1 Jun 2009, at 22:21, Darko wrote: >> >>> This is a great little hack. Is it available now or are you still >>> working on it? I don't know what other people want to use it for but >>> this is a great way to link memory structures with external data. It >>> overcomes one of the downsides of GC compared to say C, where you >>> can use pointer values for other purposes, but it does it safely. >>> >>> Also I'd like to add my voice for the minimalist approach where no >>> language changes are made. I don't think there is a semantically >>> clean way of incorporating this into the language and I'm not sure >>> there is any payoff in doing so. > > I think there is a semantically clean way of incorporating it into the > language, but it's not a trivial change. It becomes an optimisable > special case of a more general feature -- for any bunch of types A, B, > C, ... you introduce a type UNION(A, B, C, ...). There's nothing you > can do with a union except build it from an A, B, or C ..., copy it, > and > test its type and extract the contents -- more or less what you can do > to one of our type-tagged values. These unions have a fixed size > (more > or less the max of the sizes of A, B, C, ... and an extra type-tag. > (I don't know if there has to be a restriction on using open arrays > here; I hole not.) > > In the special case of UNION(A, B), where B is a suitable subrange if > INTEGER and A is a pointer-to-object, the compiler could choose to > implement this with our low-bit-and-shift hack. > > -- hendrik From hendrik at topoi.pooq.com Tue Jun 2 13:23:53 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 2 Jun 2009 07:23:53 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> Message-ID: <20090602112353.GB2916@topoi.pooq.com> On Tue, Jun 02, 2009 at 08:51:31PM +1000, Tony Hosking wrote: > Union types are anathema to the design of the Modula-3 type system. So I have heard. But I don't understand why. Certainly variant records a la Pascal would be for security reasons. Did they get tarred with the same brush? Or were unions considered unnecessary once the language had objects and inheritance? -- hendrik From hendrik at topoi.pooq.com Tue Jun 2 17:52:47 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 2 Jun 2009 11:52:47 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <5DE9B69F-9493-4A6D-B7C8-1CEABC4BAE43@darko.org> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> <20090602112353.GB2916@topoi.pooq.com> <5DE9B69F-9493-4A6D-B7C8-1CEABC4BAE43@darko.org> Message-ID: <20090602155246.GC3481@topoi.pooq.com> On Tue, Jun 02, 2009 at 04:33:49PM +0200, Darko wrote: > Probably because some union fields disappear and you can't work out > statically if a field access is valid. That's the problem with variant records in Pascal. I don't like them either. They're not what I'm talking about. If you have a value of type UNION(A, B) you don't get to use an operation on it just because the operation happens to be valid on A. > Maybe you chose the wrong name > for your type, because they are actually just dynamically typed values > rather than unions. The unions I'm talking about are disjount unions, the things the category theorists oftern call coproducts. They are dual to Cartesion products (which are provided in Moduls 3). They are type-secure. My unions comprise a finite number of other types, which means that in one place you can see everything that can happen to them. You don't run the risk that somewhere else someone sticks more alternatives into your type by inheriting form it. (this can be a curse or a blessing, depending on how your code is organised. It tends to be awkward to do object-oriented code with these unions, just as it's awkward using objects and inheritance when you really want unions) > Maybe you should have called them 'overlays' I'm not taking about interpreting physical storage in multiple different ways. I'm not talking about tools to store a REAL and fetch an INTEGER in order to cut it up with maske to get at the exponent and mantissa. That's UNSAFE. I'm talking about a type-safe alternative mechanism in data structures. One which is more efficient is some circumstances that the one traditionally embedded in Modula 3 (else we wouldn't be having this discussion), but less efficient in others (such as unions of huge records). But what I'd like to know is why they are considered an anathema instead of just an alternative not taken. Perhaps way back then they were talking about different language features. But treating them as anathema seems to have poisoned thinking about any kind of remotely similar feature, even type-safe ones. -- hendrik > > On 02/06/2009, at 1:23 PM, hendrik at topoi.pooq.com wrote: > > >On Tue, Jun 02, 2009 at 08:51:31PM +1000, Tony Hosking wrote: > >>Union types are anathema to the design of the Modula-3 type system. > > > >So I have heard. But I don't understand why. Certainly > >variant records a la Pascal would be for security reasons. > >Did they get tarred with the same brush? Or were unions > >considered unnecessary once the language had objects and > >inheritance? > > > >-- hendrik > From jay.krell at cornell.edu Tue Jun 2 17:52:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 2 Jun 2009 15:52:43 +0000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20090602112353.GB2916@topoi.pooq.com> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> <20090602112353.GB2916@topoi.pooq.com> Message-ID: Um, but can't tagged unions be safe? Can't you tell the compiler which tag maps to which part of the union and all reads would be checked? And writes would set the tag? Something like that? Plus optimize away some of the tag checks. And then like you say, sometimes the tag can be combined with the value, nice description. After all, tagged unions are the only type in Microsoft VBScript and JScript, safe languages. Granted, as you say, objects often fit the same scenarios. - Jay > Date: Tue, 2 Jun 2009 07:23:53 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Resummary of tagged reference proposals > > On Tue, Jun 02, 2009 at 08:51:31PM +1000, Tony Hosking wrote: > > Union types are anathema to the design of the Modula-3 type system. > > So I have heard. But I don't understand why. Certainly > variant records a la Pascal would be for security reasons. > Did they get tarred with the same brush? Or were unions > considered unnecessary once the language had objects and > inheritance? > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jun 3 00:49:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Jun 2009 08:49:59 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20090602112353.GB2916@topoi.pooq.com> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> <20090602112353.GB2916@topoi.pooq.com> Message-ID: Yes, objects + inheritance. I think there is a discussion in "How the language got its spots" in "Systems Programming in Modula-3". On 2 Jun 2009, at 21:23, hendrik at topoi.pooq.com wrote: > On Tue, Jun 02, 2009 at 08:51:31PM +1000, Tony Hosking wrote: >> Union types are anathema to the design of the Modula-3 type system. > > So I have heard. But I don't understand why. Certainly > variant records a la Pascal would be for security reasons. > Did they get tarred with the same brush? Or were unions > considered unnecessary once the language had objects and > inheritance? > > -- hendrik From hendrik at topoi.pooq.com Wed Jun 3 19:14:07 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 3 Jun 2009 13:14:07 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> <20090602112353.GB2916@topoi.pooq.com> <5DE9B69F-9493-4A6D-B7C8-1CEABC4BAE43@darko.org> <20090602155246.GC3481@topoi.pooq.com> Message-ID: <20090603171407.GA7016@topoi.pooq.com> On Wed, Jun 03, 2009 at 01:20:38AM +0200, Froggy wrote: > Yes, I understand what you're proposing and agree, but if you call > them unions then people think you're talking about C style unions or > variant records, etc which are the anathema in question. Historically, it was the other way around. C took Algol 68's unions, and removed the run-time type discriminator which could make them safe. -- hendrik From jay.krell at cornell.edu Thu Jun 4 21:42:28 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 4 Jun 2009 19:42:28 +0000 Subject: [M3devel] CM3_INSTALL_PREFIX Message-ID: Dragisha, ok, even before looking into this, I think I knew what the problem is. Need to "smush out the dots" more, so that mkdir /a/b/c/d/.. acts like mkdir /a/b/c. However I am unable to reproduce the problem on either PPC_DARWIN or AMD64_LINUX. Can you show me the offending .M3SHIP files? And maybe your config files? I don't have any .. "like that" in .M3SHIP. Does it happen with current cm3 or only older cm3? (I didn't realize CM3_INSTALL_PREFIX was a relatively new thing, from early 2008.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jun 4 21:38:38 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 4 Jun 2009 19:38:38 +0000 Subject: [M3devel] cvsup/zlib/solaris Message-ID: Tony your Tinderbox runs are less successful than others, building cvsup, due to lack of libz: === package m3-tools/cvsup/suplib === --- building in SOLgnu --- 22849 22850 ignoring ../src/m3overrides 22851 22852 NEXT "/scratch/hosking/work/cm3-ws/niagara-2009-06-03-10-30-05/cm3/m3-tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake runtime error: file libz.a not found in /usr/lib /usr/local/lib /lib /usr/contrib/lib /opt/lib 22853 Can you maybe install it on your systems? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jun 5 01:13:19 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 05 Jun 2009 01:13:19 +0200 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: References: Message-ID: <1244157199.14071.265.camel@faramir.m3w.org> There is no problem in CM3_INSTALL_PREFIX, but in situations where make_dir tries to make ".bin/.." when "..bin/" still does not exist. Problem is recent, it started to happen after you make INSTALL_ROOT relative to cm3 binary location. Solution: Exterminate .. from paths in cm3cfg.common. Apropos CM3_INSTALL_PREFIX - I am maybe it's only "client" for now - as it's used to populate tree during RPM builds. But it's straightforward solution to any binary packaking problem. On Thu, 2009-06-04 at 19:42 +0000, Jay wrote: > Dragisha, > > ok, even before looking into this, I think I knew what the problem is. > Need to "smush out the dots" more, so that mkdir /a/b/c/d/.. acts like > mkdir /a/b/c. > > However I am unable to reproduce the problem on either PPC_DARWIN or > AMD64_LINUX. > > Can you show me the offending .M3SHIP files? > And maybe your config files? > > I don't have any .. "like that" in .M3SHIP. > > Does it happen with current cm3 or only older cm3? > (I didn't realize CM3_INSTALL_PREFIX was a relatively new thing, from > early 2008.) > > - Jay > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jun 5 01:21:51 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 4 Jun 2009 23:21:51 +0000 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: <1244157199.14071.265.camel@faramir.m3w.org> References: <1244157199.14071.265.camel@faramir.m3w.org> Message-ID: I made this change years ago but only recently did Olaf switch over to my stuff. It is a good change generally, because you don't have to run cminstall and stick a full path in the config file. We can fix this aspect of it, but I'd like to be able to see it fail before I fix it, and then verify my fix makes it stop failing. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 5 Jun 2009 01:13:19 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3_INSTALL_PREFIX > > There is no problem in CM3_INSTALL_PREFIX, but in situations where > make_dir tries to make ".bin/.." when "..bin/" still does not exist. > > Problem is recent, it started to happen after you make INSTALL_ROOT > relative to cm3 binary location. > > Solution: Exterminate .. from paths in cm3cfg.common. > > Apropos CM3_INSTALL_PREFIX - I am maybe it's only "client" for now - as > it's used to populate tree during RPM builds. But it's straightforward > solution to any binary packaking problem. > > On Thu, 2009-06-04 at 19:42 +0000, Jay wrote: >> Dragisha, >> >> ok, even before looking into this, I think I knew what the problem is. >> Need to "smush out the dots" more, so that mkdir /a/b/c/d/.. acts like >> mkdir /a/b/c. >> >> However I am unable to reproduce the problem on either PPC_DARWIN or >> AMD64_LINUX. >> >> Can you show me the offending .M3SHIP files? >> And maybe your config files? >> >> I don't have any .. "like that" in .M3SHIP. >> >> Does it happen with current cm3 or only older cm3? >> (I didn't realize CM3_INSTALL_PREFIX was a relatively new thing, from >> early 2008.) >> >> - Jay >> > -- > Dragi?a Duri? > From hosking at cs.purdue.edu Fri Jun 5 01:54:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 5 Jun 2009 09:54:41 +1000 Subject: [M3devel] cvsup/zlib/solaris In-Reply-To: References: Message-ID: <1C2755B6-78CF-49B7-8057-E904B7A9D253@cs.purdue.edu> I'll see what I can do to locate that. On 5 Jun 2009, at 05:38, Jay wrote: > Tony your Tinderbox runs are less successful than others, building > cvsup, due to lack of libz: > > === package m3-tools/cvsup/suplib === > --- building in SOLgnu --- > 22849 > 22850 ignoring ../src/m3overrides > 22851 > 22852 NEXT "/scratch/hosking/work/cm3-ws/ > niagara-2009-06-03-10-30-05/cm3/m3-tools/cvsup/suplib/src/../../ > quake/cvsup.quake", line 127: quake runtime error: file libz.a not > found in /usr/lib /usr/local/lib /lib /usr/contrib/lib /opt/lib > 22853 > > > Can you maybe install it on your systems? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jun 5 10:51:05 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 05 Jun 2009 10:51:05 +0200 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: References: <1244157199.14071.265.camel@faramir.m3w.org> Message-ID: <1244191865.14071.717.camel@faramir.m3w.org> This is special case, as CM3_INSTALL_PREFIX redirects installation process to empty tree... cm3 -ship fails on make_dir("/usr/local/cm3/bin/../lib") as there is no $CM3_INSTALL_PREFIX/usr/local/cm3/bin at that moment. "cm3 -ship" which fails does mkdir $CM3_INSTALL_PREFIX/usr/local/cm3/bin, though. So second time I start cm3 -ship it works fine. Also, if I "mkdir -p $CM3_INSTALL_PREFIX/usr/local/cm3/bin" before cm3 -ship it does not fail first time. Thus said - I already have fix I need, it's workaround but works. If it is problem for you to write wuake script which derives paths from INSTALL_ROOT without ".." then just forget this and we can document this "feature" on our way. It will be documented in my RPM recipes once I complete and publish them. On Thu, 2009-06-04 at 23:21 +0000, Jay wrote: > > I made this change years ago but only recently did Olaf switch over to > my stuff. It is a good change generally, because you don't have to run > cminstall and stick a full path in the config file. We can fix this > aspect of it, but I'd like to be able to see it fail before I fix it, > and then verify my fix makes it stop failing. > > > - Jay -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jun 5 19:28:51 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 5 Jun 2009 17:28:51 +0000 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: <1244191865.14071.717.camel@faramir.m3w.org> References: <1244157199.14071.265.camel@faramir.m3w.org> <1244191865.14071.717.camel@faramir.m3w.org> Message-ID: The ".." gets smushed out early for me and I don't see a failure. Even for shipping m3core into a nonexistant place, with CM3_INSTALL_PREFIX set. Is the problem without CM3_INSTALL_PREFIX? Can you show your .M3SHIP files? And maybe your config files? This is easy to fix. There is code that smushes out dots. It is maybe a problem to write the quake because quake is very limited in what it can do. There might be functions now that can do it though. But really, again, the Modula-3 code often "canonicalizes" paths internally anyway, which is possibly why I don't see the problem occuring myself. - Jay > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 5 Jun 2009 10:51:05 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3_INSTALL_PREFIX > > This is special case, as CM3_INSTALL_PREFIX redirects installation > process to empty tree... cm3 -ship fails on > make_dir("/usr/local/cm3/bin/../lib") as there is no > $CM3_INSTALL_PREFIX/usr/local/cm3/bin at that moment. "cm3 -ship" which > fails does mkdir $CM3_INSTALL_PREFIX/usr/local/cm3/bin, though. So > second time I start cm3 -ship it works fine. > > Also, if I "mkdir -p $CM3_INSTALL_PREFIX/usr/local/cm3/bin" before cm3 > -ship it does not fail first time. > > Thus said - I already have fix I need, it's workaround but works. If it > is problem for you to write wuake script which derives paths from > INSTALL_ROOT without ".." then just forget this and we can document this > "feature" on our way. It will be documented in my RPM recipes once I > complete and publish them. > > On Thu, 2009-06-04 at 23:21 +0000, Jay wrote: > > > > I made this change years ago but only recently did Olaf switch over to > > my stuff. It is a good change generally, because you don't have to run > > cminstall and stick a full path in the config file. We can fix this > > aspect of it, but I'd like to be able to see it fail before I fix it, > > and then verify my fix makes it stop failing. > > > > > > - Jay > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jun 5 21:56:15 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 05 Jun 2009 21:56:15 +0200 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: References: <1244157199.14071.265.camel@faramir.m3w.org> <1244191865.14071.717.camel@faramir.m3w.org> Message-ID: <1244231775.14071.1359.camel@faramir.m3w.org> On Fri, 2009-06-05 at 17:28 +0000, Jay wrote: > The ".." gets smushed out early for me and I don't see a failure. > Even for shipping m3core into a nonexistant place, with > CM3_INSTALL_PREFIX set. > Is the problem without CM3_INSTALL_PREFIX? I don't see how to ship to non-existent place without CM3_INSTALL_PREFIX... End of day sinrome maybe...? > Can you show your .M3SHIP files? They are just like anybody's else. > And maybe your config files? Stock. No edit. > This is easy to fix. There is code that smushes out dots. Then please do. :) -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jun 5 22:31:12 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 5 Jun 2009 20:31:12 +0000 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: <1244231775.14071.1359.camel@faramir.m3w.org> References: <1244157199.14071.265.camel@faramir.m3w.org> <1244191865.14071.717.camel@faramir.m3w.org> <1244231775.14071.1359.camel@faramir.m3w.org> Message-ID: Dragisha we are not communicating. I have set CM3_INSTALL_PREFIX to a nonexistant place. I have shiped m3core. It works. No error. If I see the error I believe I know how to fix it, but I don't want to make a change without being able to see the before and after and that the after is an improvement. Maybe I am doing something wrong though. Please send me the offending .M3SHIP file. - Jay ---------------------------------------- > Subject: RE: [M3devel] CM3_INSTALL_PREFIX > From: dragisha at m3w.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Date: Fri, 5 Jun 2009 21:56:15 +0200 > > On Fri, 2009-06-05 at 17:28 +0000, Jay wrote: >> The ".." gets smushed out early for me and I don't see a failure. >> Even for shipping m3core into a nonexistant place, with >> CM3_INSTALL_PREFIX set. >> Is the problem without CM3_INSTALL_PREFIX? > > I don't see how to ship to non-existent place without > CM3_INSTALL_PREFIX... End of day sinrome maybe...? > >> Can you show your .M3SHIP files? > > They are just like anybody's else. > >> And maybe your config files? > > Stock. No edit. > >> This is easy to fix. There is code that smushes out dots. > > Then please do. :) > > -- > Dragi?a Duri? > From eiserlohpp at yahoo.com Mon Jun 8 03:30:46 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 7 Jun 2009 18:30:46 -0700 (PDT) Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX Message-ID: <973785.75349.qm@web56804.mail.re3.yahoo.com> Hi Guys, I have been attempting to build m3gdb. A simple "do-pkg.sh m3gdb" fails with a message that the package is disabled on this platform. So, I manually went to m3-sys/m3gdb, and did a "cm3 -build", an success. Is there a reason that m3gdb is disabled on AMD64_LINUX? Or, more probably, did someone simply forget to enable it? I traced the decision down to pkginfo.sh, where yes, there is an environment variable M3GDB that could have been set to allow m3gdb to be built, but that is taking extra measures to build it. Is it a simple oversight in not, by default, building m3gdb? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From rodney.m.bates at cox.net Mon Jun 8 16:59:34 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 08 Jun 2009 09:59:34 -0500 Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX In-Reply-To: <973785.75349.qm@web56804.mail.re3.yahoo.com> References: <973785.75349.qm@web56804.mail.re3.yahoo.com> Message-ID: <4A2D2756.8010904@cox.net> I seem to have fallen into the role of default primary maintainer for m3gdb. I have never built it on anything other than LINUXLIBC6. I now have an AMD_LINUX machine, but haven't gotten a working cm3 to build with yet. I'm just guessing, but I think some platforms have had build problems in the past. Maybe it is disable except where it has been previously done successfully. I read your post to say only that it built successfully for you. Any experience trying it out? Peter Eiserloh wrote: > Hi Guys, > > I have been attempting to build m3gdb. A simple > "do-pkg.sh m3gdb" fails with a message that the package > is disabled on this platform. > > So, I manually went to m3-sys/m3gdb, and did a "cm3 -build", > an success. > > Is there a reason that m3gdb is disabled on AMD64_LINUX? > Or, more probably, did someone simply forget to enable it? > > I traced the decision down to pkginfo.sh, where yes, there > is an environment variable M3GDB that could have been > set to allow m3gdb to be built, but that is taking extra > measures to build it. > > Is it a simple oversight in not, by default, building m3gdb? > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > > From wagner at elegosoft.com Mon Jun 8 21:37:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Jun 2009 21:37:12 +0200 Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX In-Reply-To: <4A2D2756.8010904@cox.net> References: <973785.75349.qm@web56804.mail.re3.yahoo.com> <4A2D2756.8010904@cox.net> Message-ID: <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> The strategy when to build m3gdb should probably be revisited. I'm not sure if we should keep the positive list or just exclude some platforms; but then, I do not have the complete overview of all the platforms that Jay has been and is working on. Jay, can you take a look at that in pkginfo.sh? Thanks, Olaf Quoting "Rodney M. Bates" : > I seem to have fallen into the role of default primary maintainer for > m3gdb. I have never built it on anything other than LINUXLIBC6. > I now have an AMD_LINUX machine, but haven't gotten a working > cm3 to build with yet. I'm just guessing, but I think some platforms > have had build problems > in the past. Maybe it is disable except where it has been previously > done successfully. I read your post to say only that it built > successfully for you. Any > experience trying it out? Peter Eiserloh wrote: >> Hi Guys, >> >> I have been attempting to build m3gdb. A simple "do-pkg.sh m3gdb" >> fails with a message that the package >> is disabled on this platform. >> >> So, I manually went to m3-sys/m3gdb, and did a "cm3 -build", >> an success. >> >> Is there a reason that m3gdb is disabled on AMD64_LINUX? >> Or, more probably, did someone simply forget to enable it? >> >> I traced the decision down to pkginfo.sh, where yes, there >> is an environment variable M3GDB that could have been >> set to allow m3gdb to be built, but that is taking extra >> measures to build it. >> >> Is it a simple oversight in not, by default, building m3gdb? >> >> >> +--------------------------------------------------------+ >> | 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 hendrik at topoi.pooq.com Mon Jun 8 22:57:47 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 8 Jun 2009 16:57:47 -0400 Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX In-Reply-To: <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> References: <973785.75349.qm@web56804.mail.re3.yahoo.com> <4A2D2756.8010904@cox.net> <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> Message-ID: <20090608205747.GA20457@topoi.pooq.com> On Mon, Jun 08, 2009 at 09:37:12PM +0200, Olaf Wagner wrote: > The strategy when to build m3gdb should probably be revisited. > I'm not sure if we should keep the positive list or just exclude > some platforms; but then, I do not have the complete overview of > all the platforms that Jay has been and is working on. Whatever you do about including or excluding, it would be worth inserting a comment explaining why. -- hendrik From jay.krell at cornell.edu Tue Jun 9 03:00:29 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 8 Jun 2009 18:00:29 -0700 Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX In-Reply-To: <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> References: <973785.75349.qm@web56804.mail.re3.yahoo.com> <4A2D2756.8010904@cox.net> <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> Message-ID: <4B18C378-AE99-4897-B1B0-2ABB39DC7E0A@hotmail.com> I agree let it build by default. It can probably build on most platforms. The exceptions are nt386 and i think nt386mingnu. Nt386gnu can build it but cygwin is so generally slow and I never use m3gdb..on any platform.. - Jay (phone) On Jun 8, 2009, at 12:37 PM, Olaf Wagner wrote: > The strategy when to build m3gdb should probably be revisited. > I'm not sure if we should keep the positive list or just exclude > some platforms; but then, I do not have the complete overview of > all the platforms that Jay has been and is working on. > > Jay, can you take a look at that in pkginfo.sh? > > Thanks, > > Olaf > > Quoting "Rodney M. Bates" : > >> I seem to have fallen into the role of default primary maintainer for >> m3gdb. I have never built it on anything other than LINUXLIBC6. >> I now have an AMD_LINUX machine, but haven't gotten a working >> cm3 to build with yet. I'm just guessing, but I think some platforms >> have had build problems >> in the past. Maybe it is disable except where it has been previously >> done successfully. I read your post to say only that it built >> successfully for you. Any >> experience trying it out? Peter Eiserloh wrote: >>> Hi Guys, >>> >>> I have been attempting to build m3gdb. A simple "do-pkg.sh m3gdb" >>> fails with a message that the package >>> is disabled on this platform. >>> >>> So, I manually went to m3-sys/m3gdb, and did a "cm3 -build", >>> an success. >>> >>> Is there a reason that m3gdb is disabled on AMD64_LINUX? >>> Or, more probably, did someone simply forget to enable it? >>> >>> I traced the decision down to pkginfo.sh, where yes, there >>> is an environment variable M3GDB that could have been >>> set to allow m3gdb to be built, but that is taking extra >>> measures to build it. >>> >>> Is it a simple oversight in not, by default, building m3gdb? >>> >>> >>> +--------------------------------------------------------+ >>> | Peter P. Eiserloh | >>> +--------------------------------------------------------+ >>> >>> >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > 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: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From hendrik at topoi.pooq.com Tue Jun 9 23:25:43 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 9 Jun 2009 17:25:43 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090514155129.GA15181@topoi.pooq.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> <20090514155129.GA15181@topoi.pooq.com> Message-ID: <20090609212543.GA23398@topoi.pooq.com> On Thu, May 14, 2009 at 11:51:30AM -0400, hendrik at topoi.pooq.com wrote: > 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. Is it time for me to make another try at installing cm3 from scratch? In particular, do you think most of the problems I reported with documentation and archives, etc., have been solved? I really want to get m3 working on this laptop, but I also want to provide the most useful problem reports. I'm definitely trying to act like a naive user in these installation attempts (which means I'm trying to act stupider than I am). -- hendrik From estellnb at yahoo.de Wed Jun 10 16:26:09 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Wed, 10 Jun 2009 15:26:09 +0100 Subject: [M3devel] recent m3gdb does not want to compile Message-ID: <4A2FC281.1030101@yahoo.de> For any kind of reason recent m3gdbs refuse to compile at me: ../gdb/configure ... checking for x86_64-unknown-linux-gnu-ar... no checking for ar... ar ... > which ar /usr/bin/ar setting --bindir to /usr/bin or /usr does not help. full error log: see attachement Should I compile m3gdb towards 32bit on an x86_64 platform if the m3build I am using is 32bit? Besides this I am in wonder why a plain gdb can not access global Modula-3 variables using PM3/EZM3 although I have specified -gstabs in m3config/src/COMMON: ASM = ["as","--32","-gstabs","-o"] % Assembler DEBUG_FLAG = "-gstabs" % debugging info BDEBUG_FLAG = "-gstabs" % debugging info LDEBUG_FLAG = "-gstabs" i.e. > gdb -batch --directory= --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > grep myglobal smbls -> nothing found -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: m3gdb-errs.msg URL: From jay.krell at cornell.edu Wed Jun 10 23:05:55 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 10 Jun 2009 21:05:55 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A2FC281.1030101@yahoo.de> References: <4A2FC281.1030101@yahoo.de> Message-ID: The global variable behavior I think I understand, and I believe the original authors did it this way on purpose, but I agree it seems quite bad. The way the code is generated, all the internal globals for a module are in one large struct, per module. There aren't symbols for each one. The code translates like this: Modula-3: Foo.i3: INTERFACE Foo; PROCEDURE GetI() : INTEGER; PROCEDURE GetJ() : INTEGER; END Foo. Foo.m3: MODULE Foo; VAR i, j: INTEGER; PROCEDURE GetI() = BEGIN RETURN i; END GetI; PROCEDURE GetJ() = BEGIN RETURN j; END GetJ; C: foo.h: ptrdiff_t Foo__GetI(void); ptrdiff_t Foo__GetJ(void); foo.c: struct { int i, j; } Foo_M3; ptrdiff_t Foo__GetI(void) { return Foo_M3.i; } ptrdiff_t Foo__GetJ(void) { return Foo_M3.j; } I personally would much prefer one of: static int i, j; ptrdiff_t Foo__GetI(void) { return i; } ptrdiff_t Foo__GetJ(void) { return j; } or: int Foo_i, Foo_j; ptrdiff_t Foo__GetI(void) { return Foo_i; } ptrdiff_t Foo__GetJ(void) { return Foo_j; } or two underscores. Can anyone explain why it is done this way? And why it shouldn't be changed to how I showed? Here are some advantages/disadvanges: symbols, debuggability, as discussed The current way pretty much guaranteeds none of the data gets dead-stripped, for better and worse. But really, even if you changed it to "my way", there's probably another bit needed on the data to dead-strip it, so that behavior can be preserved, for better and worse. "My way" probably also allows for not using bitfields in load/store, in fact, the offseting would often go away too. > Should I compile m3gdb towards 32bit on an x86_64 platform if the > m3build I am using is 32bit? It should build either way, but for it to be useful, yes, I expect so. I believe current versions of gdb can have multiple targets though. - Jay > Date: Wed, 10 Jun 2009 15:26:09 +0100 > From: estellnb at yahoo.de > To: m3devel at elegosoft.com > Subject: [M3devel] recent m3gdb does not want to compile > > For any kind of reason recent m3gdbs refuse to compile at me: > > ../gdb/configure > ... > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > ... > > > which ar > /usr/bin/ar > > setting --bindir to /usr/bin or /usr does not help. > full error log: see attachement > > Should I compile m3gdb towards 32bit on an x86_64 platform if the > m3build I am using is 32bit? > > Besides this I am in wonder why a plain gdb can not access global > Modula-3 variables using PM3/EZM3 although I have specified -gstabs in > m3config/src/COMMON: > ASM = ["as","--32","-gstabs","-o"] % Assembler > DEBUG_FLAG = "-gstabs" % debugging info > BDEBUG_FLAG = "-gstabs" % debugging info > LDEBUG_FLAG = "-gstabs" > > i.e. > > gdb -batch --directory= > --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info > variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > > > grep myglobal smbls -> nothing found > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jun 10 23:42:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 10 Jun 2009 23:42:00 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090609212543.GA23398@topoi.pooq.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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> Message-ID: <20090610234200.xec9zguoqowogc84@mail.elego.de> Quoting hendrik at topoi.pooq.com: > On Thu, May 14, 2009 at 11:51:30AM -0400, hendrik at topoi.pooq.com wrote: > Is it time for me to make another try at installing cm3 from scratch? > In particular, do you think most of the problems I reported with > documentation and archives, etc., have been solved? I really want to > get m3 working on this laptop, but I also want to provide the most > useful problem reports. > > I'm definitely trying to act like a naive user in these installation > attempts (which means I'm trying to act stupider than I am). I'm sorry; though I've put some archives onto birch labelled as RC1, there's still no documentation. I'm currently in Madrid for a week, but I hope to spend a day for working on that when I return mid of next week. I'll let you know when to try it. Hasta luego, 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 Thu Jun 11 01:04:28 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 10 Jun 2009 23:04:28 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A2FC281.1030101@yahoo.de> References: <4A2FC281.1030101@yahoo.de> Message-ID: Slightly truncated, again >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? > > > > > > It should build either way, but for it to be useful, yes, I expect so. > > I believe current versions of gdb can have multiple targets though. > > > > > > - Jay From rodney.m.bates at cox.net Thu Jun 11 04:20:49 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 10 Jun 2009 21:20:49 -0500 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A2FC281.1030101@yahoo.de> References: <4A2FC281.1030101@yahoo.de> Message-ID: <4A306A01.5080603@cox.net> Peter Eiserloh has recently gotten it to build on AMD64_LINUX, using the do-cm3-m3gdb.sh script. You should try that method. Unfortunately, it is not recognizing executables and dynamic libraries. I have looked at this a bit, and the problem looks to be in the bfd library, which is stock from gdb. m3gdb is derived from gdb 6.4, which is by now quite old. gdb maintainers are about to make a new release, I think 6.9. I am in the throes of moving house now, but am getting odd bits of time to look at this. I have been thinking for some time that it is about time to update m3gdb to a later gdb. For one thing, gdb now has some reverse debugging support, which would be very nice for Modula-3 too. I have done it two or three times, and I believe Tony has done it at least once. It takes a fair amount of work. But it should be possible to get the current m3gdb working on AMD64 without going to that much trouble. Maybe just some updated source files from bfd will do the trick. Jay is right about global variables. You will have a very hard time finding them using stock gdb. They are located in a record with a funny compiler-generated name and have funny compiler-mangled field names. I'm not sure you can get them even if you know these. Elmar Stellnberger wrote: > For any kind of reason recent m3gdbs refuse to compile at me: > > ../gdb/configure > ... > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > ... > > >> which ar >> > /usr/bin/ar > > setting --bindir to /usr/bin or /usr does not help. > full error log: see attachement > > Should I compile m3gdb towards 32bit on an x86_64 platform if the > m3build I am using is 32bit? > > Besides this I am in wonder why a plain gdb can not access global > Modula-3 variables using PM3/EZM3 although I have specified -gstabs in > m3config/src/COMMON: > ASM = ["as","--32","-gstabs","-o"] % Assembler > DEBUG_FLAG = "-gstabs" % debugging info > BDEBUG_FLAG = "-gstabs" % debugging info > LDEBUG_FLAG = "-gstabs" > > i.e. > >> gdb -batch --directory= >> > --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info > variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > > >> grep myglobal smbls -> nothing found >> > > From jay.krell at cornell.edu Thu Jun 11 05:13:55 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 10 Jun 2009 20:13:55 -0700 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A306A01.5080603@cox.net> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> Message-ID: Do they have any field names at all? Can m3gdb see them? I suspect no to both. The struct is not TOO odd. - Jay (phone) On Jun 10, 2009, at 7:20 PM, "Rodney M. Bates" wrote: > Peter Eiserloh has recently gotten it to build on AMD64_LINUX, > using the do-cm3-m3gdb.sh script. You should try that method. > > Unfortunately, it is not recognizing executables and dynamic > libraries. I have looked at this a bit, and the problem looks to > be in the bfd library, which is stock from gdb. m3gdb is derived > from gdb 6.4, which is by now quite old. gdb maintainers are about > to make a new release, I think 6.9. I am in the throes of moving > house now, but am getting odd bits of time to look at this. > I have been thinking for some time that it is about time to update > m3gdb to a later gdb. For one thing, gdb now has some reverse > debugging support, which would be very nice for Modula-3 too. > I have done it two or three times, and I believe Tony has done it > at least once. It takes a fair amount of work. But it should be > possible to get the current m3gdb working on AMD64 without going > to that much trouble. Maybe just some updated source files from > bfd will do the trick. > Jay is right about global variables. You will have a very hard time > finding them using stock gdb. They are located in a record with a > funny compiler-generated name and have funny compiler-mangled > field names. I'm not sure you can get them even if you know these. > > > > > Elmar Stellnberger wrote: >> For any kind of reason recent m3gdbs refuse to compile at me: >> >> ../gdb/configure >> ... >> checking for x86_64-unknown-linux-gnu-ar... no >> checking for ar... ar >> ... >> >> >>> which ar >>> >> /usr/bin/ar >> >> setting --bindir to /usr/bin or /usr does not help. >> full error log: see attachement >> >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? >> >> Besides this I am in wonder why a plain gdb can not access global >> Modula-3 variables using PM3/EZM3 although I have specified -gstabs >> in >> m3config/src/COMMON: >> ASM = ["as","--32","-gstabs","-o"] % Assembler >> DEBUG_FLAG = "-gstabs" % debugging info >> BDEBUG_FLAG = "-gstabs" % debugging info >> LDEBUG_FLAG = "-gstabs" >> >> i.e. >> >>> gdb -batch --directory= >>> >> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info >> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls >> >> >>> grep myglobal smbls -> nothing found >>> >> >> > > From jay.krell at cornell.edu Thu Jun 11 10:50:08 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 11 Jun 2009 08:50:08 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> Message-ID: scripts/do-cm3-m3gdb.sh just cd's over to m3-sys/m3gdb and runs cm3. m3gdb builds and seems to work fine for me. Specifically, on AMD64_LINUX birch, I can both: mkdir -p $HOME/obj/gdb cd $HOME/obj/gdb $HOME/dev2/cm3/m3-sys/m3gdb/gdb/configure && make gdb/gdb gdb/gdb break main r and cd $HOME/dev2/cm3/m3-sys/m3gdb rm -rf AMD64_LINUX cm3 AMD64_LINUX/m3gdb AMD64_LINUX/m3gdb break main r I haven't tried with Modula-3 code and/or stabs. Updating from the 2005 6.4 release to a current 6.8 release is probably advisable anyway. But again, um, er, could we maybe adapt the generated code so that plain gdb is all anyone would need/want? Cygwin fork being so slow makes me want to optimize out such large pieces as building gdb. Maybe I can figure out a way to speed up Cygwin fork some day... - Jay > From: jay.krell at cornell.edu > To: rodney.m.bates at cox.net > Date: Wed, 10 Jun 2009 20:13:55 -0700 > CC: m3devel at elegosoft.com; estellnb at yahoo.de > Subject: Re: [M3devel] recent m3gdb does not want to compile > > Do they have any field names at all? Can m3gdb see them? I suspect no > to both. The struct is not TOO odd. > > - Jay (phone) > > On Jun 10, 2009, at 7:20 PM, "Rodney M. Bates" > wrote: > > > Peter Eiserloh has recently gotten it to build on AMD64_LINUX, > > using the do-cm3-m3gdb.sh script. You should try that method. > > > > Unfortunately, it is not recognizing executables and dynamic > > libraries. I have looked at this a bit, and the problem looks to > > be in the bfd library, which is stock from gdb. m3gdb is derived > > from gdb 6.4, which is by now quite old. gdb maintainers are about > > to make a new release, I think 6.9. I am in the throes of moving > > house now, but am getting odd bits of time to look at this. > > I have been thinking for some time that it is about time to update > > m3gdb to a later gdb. For one thing, gdb now has some reverse > > debugging support, which would be very nice for Modula-3 too. > > I have done it two or three times, and I believe Tony has done it > > at least once. It takes a fair amount of work. But it should be > > possible to get the current m3gdb working on AMD64 without going > > to that much trouble. Maybe just some updated source files from > > bfd will do the trick. > > Jay is right about global variables. You will have a very hard time > > finding them using stock gdb. They are located in a record with a > > funny compiler-generated name and have funny compiler-mangled > > field names. I'm not sure you can get them even if you know these. > > > > > > > > > > Elmar Stellnberger wrote: > >> For any kind of reason recent m3gdbs refuse to compile at me: > >> > >> ../gdb/configure > >> ... > >> checking for x86_64-unknown-linux-gnu-ar... no > >> checking for ar... ar > >> ... > >> > >> > >>> which ar > >>> > >> /usr/bin/ar > >> > >> setting --bindir to /usr/bin or /usr does not help. > >> full error log: see attachement > >> > >> Should I compile m3gdb towards 32bit on an x86_64 platform if the > >> m3build I am using is 32bit? > >> > >> Besides this I am in wonder why a plain gdb can not access global > >> Modula-3 variables using PM3/EZM3 although I have specified -gstabs > >> in > >> m3config/src/COMMON: > >> ASM = ["as","--32","-gstabs","-o"] % Assembler > >> DEBUG_FLAG = "-gstabs" % debugging info > >> BDEBUG_FLAG = "-gstabs" % debugging info > >> LDEBUG_FLAG = "-gstabs" > >> > >> i.e. > >> > >>> gdb -batch --directory= > >>> > >> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info > >> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > >> > >> > >>> grep myglobal smbls -> nothing found > >>> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at yahoo.de Thu Jun 11 14:00:12 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Thu, 11 Jun 2009 13:00:12 +0100 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A306A01.5080603@cox.net> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> Message-ID: <4A30F1CC.8040201@yahoo.de> Unfortunately I am not familiar with the complex build system of CM3 so that my chances to make do-cm3-m3gdb.sh work are very little: > scripts/do-cm3-m3gdb.sh making /src/lunger-cm3/scripts/PKGS (slow but rare) /src/lunger-cm3/scripts/pkgmap.sh -c "m3build -O -DROOT='/src/lunger-cm3' -DCM3_VERSION_TEXT='d5.8.1' -DCM3_VER SION_NUMBER='050801' -DCM3_LAST_CHANGED='2009-05-16' " m3gdb === package m3-sys/m3gdb === === package omitted on this platform === ==> m3-sys/m3gdb done > ls m3-sys/m3gdb/AMD64_LINUX > > m3build -O -DROOT='/src/lunger-cm3' -DCM3_VERSION_TEXT='d5.8.1' -DCM3_VERSION_NUMBER='050801' -DCM3_LAST_CHANGED='2009-05-16' --- building in LINUXLIBC6 --- m3build: missing ../src/m3overrides m3build: quake error: quake error: runtime error: exec failed: err#2 No such file or directory() *** CC="gcc" CFLAGS="-g" MAKEINFO=echo --procedure-- -line- -file--- exec -- m3gdb_Run 121 /home/sources/lunger-cm3/m3-sys/m3gdb/src/m3makefile 153 /home/sources/lunger-cm3/m3-sys/m3gdb/src/m3makefile Where should the overrides file come from? > ../gdb/configure CC="gcc" CFLAGS="-g" MAKEINFO="echo" configure: warning: CC=gcc: invalid host type configure: warning: CFLAGS=-g: invalid host type configure: error: can only configure for one host and one target at a time How can I invoke ../gdb/configure and make manually without having to use these scripts? Rodney M. Bates schrieb: > Peter Eiserloh has recently gotten it to build on AMD64_LINUX, > using the do-cm3-m3gdb.sh script. You should try that method. > > Unfortunately, it is not recognizing executables and dynamic > libraries. I have looked at this a bit, and the problem looks to > be in the bfd library, which is stock from gdb. m3gdb is derived > from gdb 6.4, which is by now quite old. gdb maintainers are about > to make a new release, I think 6.9. I am in the throes of moving > house now, but am getting odd bits of time to look at this. > I have been thinking for some time that it is about time to update > m3gdb to a later gdb. For one thing, gdb now has some reverse > debugging support, which would be very nice for Modula-3 too. > I have done it two or three times, and I believe Tony has done it > at least once. It takes a fair amount of work. But it should be > possible to get the current m3gdb working on AMD64 without going > to that much trouble. Maybe just some updated source files from > bfd will do the trick. > Jay is right about global variables. You will have a very hard time > finding them using stock gdb. They are located in a record with a > funny compiler-generated name and have funny compiler-mangled > field names. I'm not sure you can get them even if you know these. > > > > > Elmar Stellnberger wrote: >> For any kind of reason recent m3gdbs refuse to compile at me: >> >> ../gdb/configure >> ... >> checking for x86_64-unknown-linux-gnu-ar... no >> checking for ar... ar >> ... >> >> >>> which ar >>> >> /usr/bin/ar >> >> setting --bindir to /usr/bin or /usr does not help. >> full error log: see attachement >> >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? >> >> Besides this I am in wonder why a plain gdb can not access global >> Modula-3 variables using PM3/EZM3 although I have specified -gstabs in >> m3config/src/COMMON: >> ASM = ["as","--32","-gstabs","-o"] % Assembler >> DEBUG_FLAG = "-gstabs" % debugging info >> BDEBUG_FLAG = "-gstabs" % debugging info >> LDEBUG_FLAG = "-gstabs" >> >> i.e. >> >>> gdb -batch --directory= >>> >> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info >> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls >> >> >>> grep myglobal smbls -> nothing found >>> >> >> > > From jay.krell at cornell.edu Thu Jun 11 13:00:54 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 11 Jun 2009 04:00:54 -0700 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A2FC281.1030101@yahoo.de> References: <4A2FC281.1030101@yahoo.de> Message-ID: You are just missing texinfo or such, so building documentation fails. I can look in to hacking the m3gdb build like m3cc is, to reduce its dependencies. - Jay (phone) On Jun 10, 2009, at 7:26 AM, Elmar Stellnberger wrote: > For any kind of reason recent m3gdbs refuse to compile at me: > > ../gdb/configure > ... > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > ... > >> which ar > /usr/bin/ar > > setting --bindir to /usr/bin or /usr does not help. > full error log: see attachement > > Should I compile m3gdb towards 32bit on an x86_64 platform if the > m3build I am using is 32bit? > > Besides this I am in wonder why a plain gdb can not access global > Modula-3 variables using PM3/EZM3 although I have specified -gstabs in > m3config/src/COMMON: > ASM = ["as","--32","-gstabs","-o"] % Assembler > DEBUG_FLAG = "-gstabs" % debugging info > BDEBUG_FLAG = "-gstabs" % debugging info > LDEBUG_FLAG = "-gstabs" > > i.e. >> gdb -batch --directory= > --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info > variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > >> grep myglobal smbls -> nothing found > >> ../gdb/configure > creating cache ./config.cache > checking host system type... x86_64-unknown-linux-gnu > checking target system type... x86_64-unknown-linux-gnu > checking build system type... x86_64-unknown-linux-gnu > checking for a BSD compatible install... /usr/bin/install -c > checking whether ln works... yes > checking whether ln -s works... yes > checking for gcc... gcc > checking whether the C compiler (gcc ) works... yes > checking whether the C compiler (gcc ) is a cross-compiler... no > checking whether we are using GNU C... yes > checking whether gcc accepts -g... yes > checking for gnatbind... no > checking whether compiler driver understands Ada... no > checking how to compare bootstrapped objects... cmp --ignore- > initial=16 $$f1 $$f2 > checking for correct version of gmp.h... yes > checking for MPFR... no > checking for bison... bison > checking for bison... bison -y > checking for gm4... no > checking for gnum4... no > checking for m4... m4 > checking for flex... flex > checking for flex... flex > checking for makeinfo... makeinfo > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > checking for x86_64-unknown-linux-gnu-as... no > checking for as... as > checking for x86_64-unknown-linux-gnu-dlltool... no > checking for dlltool... no > checking for x86_64-unknown-linux-gnu-ld... /usr/lib64/gcc/x86_64- > suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld > checking for x86_64-unknown-linux-gnu-nm... no > checking for nm... nm > checking for x86_64-unknown-linux-gnu-ranlib... no > checking for ranlib... ranlib > checking for x86_64-unknown-linux-gnu-windres... no > checking for windres... no > checking for x86_64-unknown-linux-gnu-objcopy... no > checking for objcopy... objcopy > checking for x86_64-unknown-linux-gnu-objdump... no > checking for objdump... objdump > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > checking for x86_64-unknown-linux-gnu-as... no > checking for as... as > checking for x86_64-unknown-linux-gnu-cc... no > checking for cc... cc > checking for x86_64-unknown-linux-gnu-c++... no > checking for c++... c++ > checking for x86_64-unknown-linux-gnu-dlltool... no > checking for dlltool... no > checking for x86_64-unknown-linux-gnu-gcc... no > checking for gcc... gcc > checking for x86_64-unknown-linux-gnu-gcj... no > checking for gcj... no > checking for x86_64-unknown-linux-gnu-gfortran... no > checking for gfortran... no > checking for x86_64-unknown-linux-gnu-ld... no > checking for ld... ld > checking for x86_64-unknown-linux-gnu-lipo... no > checking for lipo... no > checking for x86_64-unknown-linux-gnu-nm... no > checking for nm... nm > checking for x86_64-unknown-linux-gnu-objdump... no > checking for objdump... objdump > checking for x86_64-unknown-linux-gnu-ranlib... no > checking for ranlib... ranlib > checking for x86_64-unknown-linux-gnu-strip... no > checking for strip... strip > checking for x86_64-unknown-linux-gnu-windres... no > checking for windres... no > checking whether to enable maintainer-specific portions of > Makefiles... no > checking if symbolic links between directories work... yes > updating cache ./config.cache > creating ./config.status > creating Makefile > elm:/home/sources/mm3/language/modula3/m3tools/m3gdb-cm3-2009-06-09/ > SUSE11.1> make > make[1]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1' > mkdir -p -- ./libiberty > Configuring in ./libiberty > configure: creating cache ./config.cache > checking whether to enable maintainer-specific portions of > Makefiles... no > checking for makeinfo... /home/sources/mm3/language/modula3/m3tools/ > m3gdb-cm3-2009-06-09/gdb/missing makeinfo --split-size=5000000 > configure: WARNING: > *** Makeinfo is missing. Info documentation will not be built. > checking for perl... perl > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking for x86_64-unknown-linux-gnu-ar... ar > checking for x86_64-unknown-linux-gnu-ranlib... ranlib > checking for x86_64-unknown-linux-gnu-gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking how to run the C preprocessor... gcc -E > checking whether gcc and cc understand -c and -o together... yes > checking for an ANSI C-conforming const... yes > checking for inline... inline > checking whether byte ordering is bigendian... no > checking for a BSD-compatible install... /usr/bin/install -c > checking for sys/file.h... yes > checking for sys/param.h... yes > checking for limits.h... yes > checking for stdlib.h... yes > checking for malloc.h... yes > checking for string.h... yes > checking for unistd.h... yes > checking for strings.h... yes > checking for sys/time.h... yes > checking for time.h... yes > checking for sys/resource.h... yes > checking for sys/stat.h... yes > checking for sys/mman.h... yes > checking for fcntl.h... yes > checking for alloca.h... yes > checking for sys/pstat.h... no > checking for sys/sysmp.h... no > checking for sys/sysinfo.h... yes > checking for machine/hal_sysinfo.h... no > checking for sys/table.h... no > checking for sys/sysctl.h... yes > checking for sys/systemcfg.h... no > checking for stdint.h... yes > checking for stdio_ext.h... yes > checking for sys/wait.h that is POSIX.1 compatible... yes > checking whether time.h and sys/time.h may both be included... yes > checking whether errno must be declared... no > checking for egrep... grep -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... (cached) yes > checking for stdlib.h... (cached) yes > checking for string.h... (cached) yes > checking for memory.h... yes > checking for strings.h... (cached) yes > checking for inttypes.h... yes > checking for stdint.h... (cached) yes > checking for unistd.h... (cached) yes > checking for int... yes > checking size of int... 4 > checking for uintptr_t... yes > checking for a 64-bit type... uint64_t > checking for pid_t... yes > checking for library containing strerror... none required > checking for asprintf... yes > checking for atexit... yes > checking for basename... yes > checking for bcmp... yes > checking for bcopy... yes > checking for bsearch... yes > checking for bzero... yes > checking for calloc... yes > checking for clock... yes > checking for ffs... yes > checking for getcwd... yes > checking for getpagesize... yes > checking for gettimeofday... yes > checking for index... yes > checking for insque... yes > checking for memchr... yes > checking for memcmp... yes > checking for memcpy... yes > checking for memmove... yes > checking for mempcpy... yes > checking for memset... yes > checking for mkstemps... no > checking for putenv... yes > checking for random... yes > checking for rename... yes > checking for rindex... yes > checking for setenv... yes > checking for snprintf... yes > checking for sigsetmask... yes > checking for stpcpy... yes > checking for stpncpy... yes > checking for strcasecmp... yes > checking for strchr... yes > checking for strdup... yes > checking for strncasecmp... yes > checking for strndup... yes > checking for strrchr... yes > checking for strstr... yes > checking for strtod... yes > checking for strtol... yes > checking for strtoul... yes > checking for strverscmp... yes > checking for tmpnam... yes > checking for vasprintf... yes > checking for vfprintf... yes > checking for vprintf... yes > checking for vsnprintf... yes > checking for vsprintf... yes > checking for waitpid... yes > checking whether alloca needs Cray hooks... no > checking stack direction for C alloca... -1 > checking for unistd.h... (cached) yes > checking for vfork.h... no > checking for fork... yes > checking for vfork... yes > checking for working fork... yes > checking for working vfork... (cached) yes > checking for _doprnt... no > checking for sys_errlist... yes > checking for sys_nerr... yes > checking for sys_siglist... yes > checking for external symbol _system_configuration... no > checking for getrusage... yes > checking for on_exit... yes > checking for psignal... yes > checking for strerror... yes > checking for strsignal... yes > checking for sysconf... yes > checking for times... yes > checking for sbrk... yes > checking for gettimeofday... (cached) yes > checking for realpath... yes > checking for canonicalize_file_name... yes > checking for pstat_getstatic... no > checking for pstat_getdynamic... no > checking for sysmp... no > checking for getsysinfo... no > checking for table... no > checking for sysctl... yes > checking for wait3... yes > checking for wait4... yes > checking for __fsetlocking... yes > checking whether basename is declared... no > checking whether ffs is declared... yes > checking whether asprintf is declared... no > checking whether vasprintf is declared... no > checking whether snprintf is declared... yes > checking whether vsnprintf is declared... yes > checking whether calloc is declared... yes > checking whether getenv is declared... yes > checking whether getopt is declared... yes > checking whether malloc is declared... yes > checking whether realloc is declared... yes > checking whether sbrk is declared... yes > checking whether strverscmp is declared... no > checking whether canonicalize_file_name must be declared... yes > checking for stdlib.h... (cached) yes > checking for unistd.h... (cached) yes > checking for getpagesize... (cached) yes > checking for working mmap... yes > checking for working strncmp... yes > updating cache ./config.cache > configure: creating ./config.status > config.status: creating Makefile > config.status: creating testsuite/Makefile > config.status: creating config.h > config.status: executing default commands > mkdir -p -- ./bfd > Configuring in ./bfd > configure: creating cache ./config.cache > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking target system type... x86_64-unknown-linux-gnu > checking for x86_64-unknown-linux-gnu-gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for library containing strerror... none required > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking for x86_64-unknown-linux-gnu-ar... ar > checking for x86_64-unknown-linux-gnu-ranlib... ranlib > checking for ld used by GCC... /usr/lib64/gcc/x86_64-suse-linux/ > 4.3/../../../../x86_64-suse-linux/bin/ld > checking if the linker (/usr/lib64/gcc/x86_64-suse-linux/ > 4.3/../../../../x86_64-suse-linux/bin/ld) is GNU ld... yes > checking for /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64- > suse-linux/bin/ld option to reload object files... -r > checking for BSD-compatible nm... nm > checking whether ln -s works... yes > checking how to recognise dependant libraries... file_magic ELF [0-9] > [0-9]*-bit [LM]SB (shared object|dynamic lib ) > checking for x86_64-unknown-linux-gnu-file... no > checking for file... /usr/bin/file > checking for x86_64-unknown-linux-gnu-ranlib... (cached) ranlib > checking for x86_64-unknown-linux-gnu-strip... no > checking for strip... strip > updating cache ./config.cache > loading cache ./config.cache within ltconfig > checking for objdir... .libs > checking for gcc option to produce PIC... -fPIC -DPIC > checking if gcc PIC flag -fPIC -DPIC works... yes > checking if gcc static flag -static works... yes > finding the maximum length of command line arguments... 49153 > checking if gcc supports -c -o file.o... yes > checking if gcc supports -fno-rtti -fno-exceptions ... no > checking whether the linker (/usr/lib64/gcc/x86_64-suse-linux/ > 4.3/../../../../x86_64-suse-linux/bin/ld) supports shared > libraries... yes > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking command to parse nm output... ok > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... no > checking whether to build static libraries... yes > creating libtool > updating cache ./config.cache > configure: loading cache ./config.cache > Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing- > prototypes -Werror > checking whether to enable maintainer-specific portions of > Makefiles... no > checking whether to install libbfd... yes > checking for x86_64-unknown-linux-gnu-gcc... (cached) gcc > checking whether we are using the GNU C compiler... (cached) yes > checking whether gcc accepts -g... (cached) yes > checking for gcc option to accept ANSI C... (cached) none needed > checking for x86_64-unknown-linux-gnu-ranlib... (cached) ranlib > checking how to run the C preprocessor... gcc -E > checking for egrep... grep -E > checking for ANSI C header files... yes > checking for an ANSI C-conforming const... yes > checking for inline... inline > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking for off_t... yes > checking for size_t... yes > checking for working alloca.h... yes > checking for alloca... yes > checking for stdlib.h... (cached) yes > checking for unistd.h... (cached) yes > checking for getpagesize... yes > checking for working mmap... yes > checking argz.h usability... yes > checking argz.h presence... yes > checking for argz.h... yes > checking limits.h usability... yes > checking limits.h presence... yes > checking for limits.h... yes > checking locale.h usability... yes > checking locale.h presence... yes > checking for locale.h... yes > checking nl_types.h usability... yes > checking nl_types.h presence... yes > checking for nl_types.h... yes > checking malloc.h usability... yes > checking malloc.h presence... yes > checking for malloc.h... yes > checking for string.h... (cached) yes > checking for unistd.h... (cached) yes > checking values.h usability... yes > checking values.h presence... yes > checking for values.h... yes > checking sys/param.h usability... yes > checking sys/param.h presence... yes > checking for sys/param.h... yes > checking for getcwd... yes > checking for munmap... yes > checking for putenv... yes > checking for setenv... yes > checking for setlocale... yes > checking for strchr... yes > checking for strcasecmp... yes > checking for __argz_count... yes > checking for __argz_stringify... yes > checking for __argz_next... yes > checking for stpcpy... yes > checking for LC_MESSAGES... yes > checking whether NLS is requested... yes > checking whether included gettext is requested... no > checking libintl.h usability... yes > checking libintl.h presence... yes > checking for libintl.h... yes > checking for gettext in libc... yes > checking for msgfmt... /usr/bin/msgfmt > checking for dcgettext... yes > checking for gmsgfmt... /usr/bin/msgfmt > checking for xgettext... /usr/bin/xgettext > checking for catalogs to be installed... fr tr ja es sv da zh_CN ro > rw vi > checking for a BSD-compatible install... /usr/bin/install -c > checking for long long... yes > checking for long long... yes > checking size of long long... 8 > checking for long... yes > checking size of long... 8 > checking stddef.h usability... yes > checking stddef.h presence... yes > checking for stddef.h... yes > checking for string.h... (cached) yes > checking for strings.h... (cached) yes > checking for stdlib.h... (cached) yes > checking time.h usability... yes > checking time.h presence... yes > checking for time.h... yes > checking for unistd.h... (cached) yes > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking whether time.h and sys/time.h may both be included... yes > checking for dirent.h that defines DIR... yes > checking for library containing opendir... none required > checking whether string.h and strings.h may both be included... yes > checking for fcntl... yes > checking for getpagesize... (cached) yes > checking for setitimer... yes > checking for sysconf... yes > checking for fdopen... yes > checking for getuid... yes > checking for getgid... yes > checking for strtoull... yes > checking whether basename is declared... yes > checking whether ftello is declared... yes > checking whether ftello64 is declared... yes > checking whether fseeko is declared... yes > checking whether fseeko64 is declared... yes > checking whether ffs is declared... yes > checking whether free is declared... yes > checking whether getenv is declared... yes > checking whether malloc is declared... yes > checking whether realloc is declared... yes > checking whether stpcpy is declared... yes > checking whether strstr is declared... yes > checking whether snprintf is declared... yes > checking whether vsnprintf is declared... yes > checking sys/procfs.h usability... yes > checking sys/procfs.h presence... yes > checking for sys/procfs.h... yes > checking for prstatus_t in sys/procfs.h... yes > checking for prstatus32_t in sys/procfs.h... no > checking for prstatus_t.pr_who in sys/procfs.h... no > checking for prstatus32_t.pr_who in sys/procfs.h... no > checking for pstatus_t in sys/procfs.h... no > checking for pxstatus_t in sys/procfs.h... no > checking for pstatus32_t in sys/procfs.h... no > checking for prpsinfo_t in sys/procfs.h... yes > checking for prpsinfo32_t in sys/procfs.h... no > checking for psinfo_t in sys/procfs.h... no > checking for psinfo32_t in sys/procfs.h... no > checking for lwpstatus_t in sys/procfs.h... no > checking for lwpxstatus_t in sys/procfs.h... no > checking for lwpstatus_t.pr_context in sys/procfs.h... no > checking for lwpstatus_t.pr_reg in sys/procfs.h... no > checking for win32_pstatus_t in sys/procfs.h... no > checking for gcc version with buggy 64-bit support... no > checking for ftello... yes > checking for ftello64... yes > checking for fseeko... yes > checking for fseeko64... yes > checking for fopen64... yes > checking for off_t... (cached) yes > checking size of off_t... 8 > checking file_ptr type... BFD_HOST_64_BIT > checking for stdlib.h... (cached) yes > checking for unistd.h... (cached) yes > checking for getpagesize... (cached) yes > checking for working mmap... (cached) yes > checking for madvise... yes > checking for mprotect... yes > updating cache ./config.cache > configure: creating ./config.status > config.status: creating Makefile > config.status: creating doc/Makefile > config.status: creating bfd-in3.h > config.status: creating po/Makefile.in > config.status: creating config.h > config.status: executing depfiles commands > config.status: executing default commands > make[2]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/libiberty' > if [ x"" != x ] && [ ! -d pic ]; then \ > mkdir pic; \ > else true; fi > touch stamp-picdir > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/regex.c -o pic/regex.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/regex.c -o regex.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/cplus-dem.c -o pic/cplus-dem.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/cplus-dem.c -o cplus-dem.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/cp-demangle.c -o pic/cp-demangle.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/cp-demangle.c -o cp-demangle.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/md5.c -o pic/md5.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/md5.c -o md5.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/alloca.c -o pic/alloca.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/alloca.c -o alloca.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/argv.c -o pic/argv.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/argv.c -o argv.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/choose-temp.c -o pic/choose-temp.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/choose-temp.c -o choose-temp.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/concat.c -o pic/concat.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/concat.c -o concat.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/cp-demint.c -o pic/cp-demint.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/cp-demint.c -o cp-demint.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/dyn-string.c -o pic/dyn-string.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/dyn-string.c -o dyn-string.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/fdmatch.c -o pic/fdmatch.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/fdmatch.c -o fdmatch.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/fibheap.c -o pic/fibheap.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/fibheap.c -o fibheap.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/floatformat.c -o pic/floatformat.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/floatformat.c -o floatformat.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/fnmatch.c -o pic/fnmatch.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/fnmatch.c -o fnmatch.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/fopen_unlocked.c -o pic/ > fopen_unlocked.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/fopen_unlocked.c -o fopen_unlocked.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/getopt.c -o pic/getopt.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/getopt.c -o getopt.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/getopt1.c -o pic/getopt1.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/getopt1.c -o getopt1.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/getpwd.c -o pic/getpwd.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/getpwd.c -o getpwd.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/getruntime.c -o pic/getruntime.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/getruntime.c -o getruntime.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/hashtab.c -o pic/hashtab.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/hashtab.c -o hashtab.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/hex.c -o pic/hex.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/hex.c -o hex.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/lbasename.c -o pic/lbasename.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/lbasename.c -o lbasename.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/lrealpath.c -o pic/lrealpath.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/lrealpath.c -o lrealpath.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/make-relative-prefix.c -o pic/make- > relative-prefix.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/make-relative-prefix.c -o make-relative-prefix.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/make-temp-file.c -o pic/make-temp- > file.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/make-temp-file.c -o make-temp-file.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/objalloc.c -o pic/objalloc.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/objalloc.c -o objalloc.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/obstack.c -o pic/obstack.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/obstack.c -o obstack.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/partition.c -o pic/partition.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/partition.c -o partition.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/pexecute.c -o pic/pexecute.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/pexecute.c -o pexecute.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/physmem.c -o pic/physmem.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/physmem.c -o physmem.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/pex-common.c -o pic/pex-common.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/pex-common.c -o pex-common.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/pex-one.c -o pic/pex-one.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/pex-one.c -o pex-one.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/pex-unix.c -o pic/pex-unix.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/pex-unix.c -o pex-unix.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/safe-ctype.c -o pic/safe-ctype.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/safe-ctype.c -o safe-ctype.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/sort.c -o pic/sort.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/sort.c -o sort.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/spaces.c -o pic/spaces.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/spaces.c -o spaces.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/splay-tree.c -o pic/splay-tree.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/splay-tree.c -o splay-tree.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/strerror.c -o pic/strerror.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/strerror.c -o strerror.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/strsignal.c -o pic/strsignal.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/strsignal.c -o strsignal.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/ternary.c -o pic/ternary.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/ternary.c -o ternary.o > ../../gdb/libiberty/ternary.c:144: warning: ?ternary_recursivesearch > ? defined but not used > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/unlink-if-ordinary.c -o pic/unlink- > if-ordinary.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/unlink-if-ordinary.c -o unlink-if-ordinary.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xatexit.c -o pic/xatexit.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xatexit.c -o xatexit.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xexit.c -o pic/xexit.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xexit.c -o xexit.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xmalloc.c -o pic/xmalloc.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xmalloc.c -o xmalloc.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xmemdup.c -o pic/xmemdup.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xmemdup.c -o xmemdup.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xstrdup.c -o pic/xstrdup.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xstrdup.c -o xstrdup.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xstrerror.c -o pic/xstrerror.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xstrerror.c -o xstrerror.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xstrndup.c -o pic/xstrndup.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xstrndup.c -o xstrndup.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/mkstemps.c -o pic/mkstemps.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/mkstemps.c -o mkstemps.o > rm -f ./libiberty.a pic/./libiberty.a > ar rc ./libiberty.a \ > ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./ > alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn- > string.o ./fdmatch.o ./fibheap.o ./floatformat.o ./fnmatch.o ./ > fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./ > hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative- > prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./ > pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./ > safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./ > strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./ > xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./ > xstrndup.o ./mkstemps.o > ranlib ./libiberty.a > if [ x"" != x ]; then \ > cd pic; \ > ar rc ./libiberty.a \ > ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./ > alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn- > string.o ./fdmatch.o ./fibheap.o ./floatformat.o ./fnmatch.o ./ > fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./ > hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative- > prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./ > pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./ > safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./ > strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./ > xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./ > xstrndup.o ./mkstemps.o; \ > ranlib ./libiberty.a; \ > cd ..; \ > else true; fi > rm -f needed-list; touch needed-list; \ > for f in atexit calloc memchr memcmp memcpy memmove memset > rename strchr strerror strncmp strrchr strstr strtol strtoul tmpnam > vfprintf vprintf vfork waitpid bcmp bcopy bzero; do \ > for g in ./mkstemps.o ; do \ > case "$g" in \ > *$f*) echo $g >> needed-list ;; \ > esac; \ > done; \ > done > echo ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o ./ > argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o ./ > fdmatch.o ./fibheap.o ./floatformat.o ./fnmatch.o ./ > fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./ > hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative- > prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./ > pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./ > safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./ > strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./ > xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./ > xstrndup.o > required-list > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/libiberty/testsuite' > make[3]: F?r das Ziel ?all? ist nichts zu tun. > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/libiberty/testsuite' > make[2]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/libiberty' > make[2]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd' > Making info in doc > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > make chew > make[4]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > gcc -o chew.$$ ../../../gdb/bfd/doc/chew.c \ > -g -O2 \ > -I.. -I../../../gdb/bfd/doc/.. -I../../../gdb/bfd/doc/../../ > include -I../../../gdb/bfd/doc/../../intl -I../../intl; \ > /bin/sh ../../../gdb/bfd/doc/../../move-if-change chew.$$ chew > make[4]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > ./chew -f ../../../gdb/bfd/doc/doc.str <../../../gdb/bfd/doc/../ > aoutx.h >aoutx.tmp > /bin/sh ../../../gdb/bfd/doc/../../move-if-change aoutx.tmp aoutx.texi > make chew > make[4]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > make[4]: ?chew? ist bereits aktualisiert. > make[4]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > ./chew -f ../../../gdb/bfd/doc/doc.str <../../../gdb/bfd/doc/../ > archive.c >archive.tmp > /bin/sh ../../../gdb/bfd/doc/../../move-if-change archive.tmp > archive.texi > make chew > make[4]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > make[4]: ?chew? ist bereits aktualisiert. > make[4]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > ./chew -f ../../../gdb/bfd/doc/doc.str < ../../../gdb/bfd/doc/../ > archures.c >archures.tmp > /bin/sh ../../../gdb/bfd/doc/../../move-if-change archures.tmp > archures.texi > restore=: && backupdir=".am$$" && \ > am__cwd=`pwd` && cd ../../../gdb/bfd/doc && \ > rm -rf $backupdir && mkdir $backupdir && \ > for f in ../../../gdb/bfd/doc/bfd.info ../../../gdb/bfd/doc/ > bfd.info-[0-9] ../../../gdb/bfd/doc/bfd.info-[0-9][0-9] ../../../gdb/ > bfd/doc/bfd.i[0-9] ../../../gdb/bfd/doc/bfd.i[0-9][0-9]; do \ > if test -f $f; then mv $f $backupdir; restore=mv; else :; > fi; \ > done; \ > cd "$am__cwd"; \ > if /home/sources/mm3/language/modula3/m3tools/m3gdb- > cm3-2009-06-09/gdb/missing makeinfo --split-size=5000000 --split- > size=5000000 -I ../../../gdb/bfd/doc \ > -o ../../../gdb/bfd/doc/bfd.info ../../../gdb/bfd/doc/ > bfd.texinfo; \ > then \ > rc=0; \ > cd ../../../gdb/bfd/doc; \ > else \ > rc=$?; \ > cd ../../../gdb/bfd/doc && \ > $restore $backupdir/* `echo "./../../../gdb/bfd/doc/ > bfd.info" | sed 's|[^/]*$||'`; \ > fi; \ > rm -rf $backupdir; exit $rc > WARNING: `makeinfo' is missing on your system. You should only need > it if > you modified a `.texi' or `.texinfo' file, or any other file > indirectly affecting the aspect of the manual. The spurious > call might also be the consequence of using a buggy > `make' (AIX, > DU, IRIX). You might want to install the `Texinfo' package or > the `GNU make' package. Grab either from any GNU archive > site. > make[3]: *** [../../../gdb/bfd/doc/bfd.info] Fehler 1 > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > Making info in po > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/po' > ( if test 'x../../../gdb/bfd/po' != 'x.'; then \ > posrcprefix='../../../gdb/bfd/'; \ > else \ > posrcprefix="../"; \ > fi; \ > rm -f SRC-POTFILES-t SRC-POTFILES \ > && (sed -e '/^#/d' \ > -e '/^[ ]*$/d' \ > -e "s at .*@ $posrcprefix& \\\\@" < ../../../gdb/ > bfd/po/SRC-POTFILES.in \ > | sed -e '$s/\\$//') > SRC-POTFILES-t \ > && chmod a-w SRC-POTFILES-t \ > && mv SRC-POTFILES-t SRC-POTFILES ) > ( rm -f BLD-POTFILES-t BLD-POTFILES \ > && (sed -e '/^#/d' \ > -e '/^[ ]*$/d' \ > -e "s at .*@ ../& \\\\@" < ../../../gdb/bfd/po/BLD- > POTFILES.in \ > | sed -e '$s/\\$//') > BLD-POTFILES-t \ > && chmod a-w BLD-POTFILES-t \ > && mv BLD-POTFILES-t BLD-POTFILES ) > cd .. \ > && CONFIG_FILES=po/Makefile.in:po/Make-in \ > CONFIG_HEADERS= /bin/sh ./config.status > config.status: creating po/Makefile.in > config.status: executing depfiles commands > config.status: executing default commands > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/po' > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/po' > make[3]: F?r das Ziel ?info? ist nichts zu tun. > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/po' > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd' > make[3]: F?r das Ziel ?info-am? ist nichts zu tun. > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd' > make[2]: *** [info-recursive] Fehler 1 > make[2]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd' > make[1]: *** [all-bfd] Fehler 2 > make[1]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1' > make: *** [all] Fehler 2 From estellnb at yahoo.de Thu Jun 11 15:16:56 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Thu, 11 Jun 2009 14:16:56 +0100 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: References: <4A2FC281.1030101@yahoo.de> Message-ID: <4A3103C8.10707@yahoo.de> Even if all the global variables are put into one large struct it should be possible to read this struct via gdb. Unfortunately that does not seem to be the case. Let us consider a small sample program in this regard: MODULE GlobVars EXPORTS Main; VAR aaa, bbb, ccc, ddd : INTEGER := 1; ttt : TEXT := "SampleText"; BEGIN bbb := 2; ccc := bbb + aaa; ddd := ccc + bbb; END GlobVars. If I look at the intermediate zero address code there is a well defined record for all the globals: ... # module global data declare_segment M_GlobVars -1 v.1 ... load_integer 2 store v.1 48 Int -----LINE 8 ----- load v.1 48 Int load v.1 44 Int add Int store v.1 52 Int ... # global data type descriptor declare_record -1 1248 6 declare_field M3_MAIN 320 32 2071511887 declare_field aaa 352 32 425470580 declare_field bbb 384 32 425470580 declare_field ccc 416 32 425470580 declare_field ddd 448 32 425470580 declare_field ttt 480 32 1358456180 ... whereby the record offsets in the data type definition are bit oriented and have to be devided by eight: 352/8 = 44 (var. aaa) The corresponding assembler code looks like the following: movl MM_GlobVars at GOT(%ebx), %eax movl $2, 48(%eax) # bbb:=2 However using gdb I can not access any of the members of the MM_GlobVars struct (gdb) p MM_GlobVars.aaa There is no member named aaa. (gdb) p MM_GlobVars $18 = {} Trying to access our globals directly via their offsets listed in the .mc and .ms files worked at least although there seems to exist a quite strange mismatch. At first I had to subtract from MM_GlobVars rather than adding the offset. Secondly I had to interpret the offset as hex number although it is clear that in the .mc-file offsets are meant as plain decimal integer numbers (i.e. 0x48=72, but 48 was decimal just before!: i.e. 48*8=384 and not 0x48*0x8=0x384) p *((int*)((void*)MM_GlobVars-72 $16 = 1 p *((int*)((void*)MM_GlobVars-76 $17 = 2 Apparently the inability to access global variables via gdb as members of the module structure may be a flaw m3cc; right? ... but what about the add/sub dec/hex mismatch from above? Jay schrieb: > The global variable behavior I think I understand, and I believe the original authors did it this way on purpose, but I agree it seems quite bad. > > > The way the code is generated, all the internal globals for a module are in one large struct, per module. > > There aren't symbols for each one. > > > > > > Can anyone explain why it is done this way? And why it shouldn't be changed to how I showed? > > > > Here are some advantages/disadvanges: > > symbols, debuggability, as discussed > > The current way pretty much guaranteeds none of the data gets dead-stripped, for better and worse. > > But really, even if you changed it to "my way", there's probably another bit needed on the data to dead-strip it, > > so that behavior can be preserved, for better and worse. > > "My way" probably also allows for not using bitfields in load/store, in fact, the offseting would often go away too. > > > > > >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? > > > > > > It should build either way, but for it to be useful, yes, I expect so. > > I believe current versions of gdb can have multiple targets though. > > > > > > - Jay > > >> Date: Wed, 10 Jun 2009 15:26:09 +0100 >> From: estellnb at yahoo.de >> To: m3devel at elegosoft.com >> Subject: [M3devel] recent m3gdb does not want to compile >> >> For any kind of reason recent m3gdbs refuse to compile at me: >> >> ../gdb/configure >> ... >> checking for x86_64-unknown-linux-gnu-ar... no >> checking for ar... ar >> ... >> >>> which ar >> /usr/bin/ar >> >> setting --bindir to /usr/bin or /usr does not help. >> full error log: see attachement >> >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? >> >> Besides this I am in wonder why a plain gdb can not access global >> Modula-3 variables using PM3/EZM3 although I have specified -gstabs in >> m3config/src/COMMON: >> ASM = ["as","--32","-gstabs","-o"] % Assembler >> DEBUG_FLAG = "-gstabs" % debugging info >> BDEBUG_FLAG = "-gstabs" % debugging info >> LDEBUG_FLAG = "-gstabs" >> >> i.e. >>> gdb -batch --directory= >> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info >> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls >> >>> grep myglobal smbls -> nothing found > From rodney.m.bates at cox.net Thu Jun 11 15:05:32 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 11 Jun 2009 08:05:32 -0500 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> Message-ID: <4A31011C.2070700@cox.net> Jay wrote: > scripts/do-cm3-m3gdb.sh just cd's over to m3-sys/m3gdb and runs cm3. > > m3gdb builds and seems to work fine for me. > > Specifically, on AMD64_LINUX birch, I can both: > > mkdir -p $HOME/obj/gdb > cd $HOME/obj/gdb > $HOME/dev2/cm3/m3-sys/m3gdb/gdb/configure && make > gdb/gdb gdb/gdb > break main > r > > and > > cd $HOME/dev2/cm3/m3-sys/m3gdb > rm -rf AMD64_LINUX > cm3 > > > AMD64_LINUX/m3gdb AMD64_LINUX/m3gdb > break main > r > > > I haven't tried with Modula-3 code and/or stabs. > > > Updating from the 2005 6.4 release to a current 6.8 release is > probably advisable anyway. > > > But again, um, er, could we maybe adapt the generated code so that > plain gdb is all anyone would need/want? I don't think so. There is ~ 20K lines of Modula-3-specific code in m3gdb, and I have tens of pages of handwritten lists of more that ought to be done to make it a nice M3 debugger. I think doing it all could easily double this. The variable reference rules are different from C/C++, for example, because of the link between a module and its exported interface(s). The global variable thing is just the tip of the iceberg. For example, there is a whole lot to making procedure calls and method calls work. Ditto for nested procedures, which, after several iterations, is broken again by the change to the newest gcc as the base for the code generator, although it works somewhat. Note that gdb provides no real support for nested functions in C, even though gcc supports them as an extension to C. Probably, they are little used in C. I use them a lot in M3. Then there are just all the language-specific formats for input and output values, and expression syntax. Plus, Modula-3, being a considerably higher-level language, (at least optionally,) has a significant runtime system, and m3gdb needs to know \ quite a bit about that too. Real arrays and open arrays also need support. And TEXT is a lot different. There are also some significant differences between cm3 and the earlier compilers. I have taken the position that support for the older ones should remain, along with new stuff too. What we should do, in addition to updating to newest gdb, is change from stabs to dwarf2 debug info format, which is *much* richer in what it can express. stabs was something of a cobbled up mess to begin with, and the M3-specific extensions to it only make it worse. There's a lot of what has to be seen as very arbitrary stuff, not really stabs, wrapped inside of some of the character strings that stabs has. This change would require a significant amount of code in the compiler, as well as in m3gdb. Someday, it might also be nice to try to get the m3 changes rolled in to the stock gdb. This would require a serious commitment to maintain them there. Also, there are some copyright assertions that DEC put in to some of the code that, I believe were in violation of the GPL. We would have to somehow get a determination that the copyright ownership could be transferred to FSF, to their satisfaction. All the more difficult with DEC's identity having changed twice. IANAL. > > > Cygwin fork being so slow makes me want to optimize out such large > pieces as building gdb. > Maybe I can figure out a way to speed up Cygwin fork some day... > > > - Jay > > From estellnb at yahoo.de Thu Jun 11 21:29:58 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Thu, 11 Jun 2009 20:29:58 +0100 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A31011C.2070700@cox.net> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> Message-ID: <4A315B36.9000700@yahoo.de> As I still have the old PM3/EZM3 in use I do welcome the continuing support for that kind of old compiler tech. Besides all these advanced issues I still simply wonder on how to compile a current m3gdb. As described earlier ./configure does not even find the standard utilities like ar, as, etc. although they are on path: ../gdb/configure --target i686-pc-linux-gnu checking for i686-pc-linux-gnu-ar... no checking for i686-pc-linux-gnu-as... no I will be happy as soon as I can print global integer variables. I can convert Text-vars to char* although that will cause little extra output. The thing is that even some elder m3gdb that I still have a compilate of can not print global vars for any kind of reason (perhaps it would be necessary to update the codegen). Rodney M. Bates schrieb: > Jay wrote: >> scripts/do-cm3-m3gdb.sh just cd's over to m3-sys/m3gdb and runs cm3. >> >> m3gdb builds and seems to work fine for me. >> >> Specifically, on AMD64_LINUX birch, I can both: >> >> mkdir -p $HOME/obj/gdb >> cd $HOME/obj/gdb >> $HOME/dev2/cm3/m3-sys/m3gdb/gdb/configure && make >> gdb/gdb gdb/gdb >> break main >> r >> >> and >> >> cd $HOME/dev2/cm3/m3-sys/m3gdb >> rm -rf AMD64_LINUX >> cm3 >> >> >> AMD64_LINUX/m3gdb AMD64_LINUX/m3gdb >> break main >> r >> >> >> I haven't tried with Modula-3 code and/or stabs. >> >> >> Updating from the 2005 6.4 release to a current 6.8 release is >> probably advisable anyway. >> >> >> But again, um, er, could we maybe adapt the generated code so that >> plain gdb is all anyone would need/want? > I don't think so. There is ~ 20K lines of Modula-3-specific code in > m3gdb, and I have tens of > pages of handwritten lists of more that ought to be done to make it a > nice M3 debugger. > I think doing it all could easily double this. The variable reference > rules are different > from C/C++, for example, because of the link between a module and its > exported > interface(s). > > The global variable thing is just the tip of the iceberg. For example, > there is a whole lot > to making procedure calls and method calls work. Ditto for nested > procedures, which, > after several iterations, is broken again by the change to the newest > gcc as the base for > the code generator, although it works somewhat. Note that gdb provides > no real > support for nested functions in C, even though gcc supports them as an > extension to C. > Probably, they are little used in C. I use them a lot in M3. > > Then there are just all the language-specific formats for input and > output values, > and expression syntax. Plus, Modula-3, being a considerably > higher-level language, > (at least optionally,) has a significant runtime system, and m3gdb needs > to know \ > quite a bit about that too. Real arrays and open arrays also need > support. And > TEXT is a lot different. > > > There are also some significant differences between cm3 and the earlier > compilers. > I have taken the position that support for the older ones should remain, > along with > new stuff too. > > > What we should do, in addition to updating to newest gdb, is change from > stabs to > dwarf2 debug info format, which is *much* richer in what it can > express. stabs was > something of a cobbled up mess to begin with, and the M3-specific > extensions to it > only make it worse. There's a lot of what has to be seen as very > arbitrary stuff, > not really stabs, wrapped inside of some of the character strings that > stabs has. This change would require a significant amount of code in the > compiler, as well > as in m3gdb. > > > Someday, it might also be nice to try to get the m3 changes rolled in to > the stock > gdb. This would require a serious commitment to maintain them there. > Also, there > are some copyright assertions that DEC put in to some of the code that, > I believe > were in violation of the GPL. We would have to somehow get a > determination that > the copyright ownership could be transferred to FSF, to their > satisfaction. All the > more difficult with DEC's identity having changed twice. IANAL. >> >> >> Cygwin fork being so slow makes me want to optimize out such large >> pieces as building gdb. >> Maybe I can figure out a way to speed up Cygwin fork some day... >> >> >> - Jay >> >> > > From jay.krell at cornell.edu Thu Jun 11 22:55:27 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 11 Jun 2009 13:55:27 -0700 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A315B36.9000700@yahoo.de> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> <4A315B36.9000700@yahoo.de> Message-ID: <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> Those are not necessarily errors. It looks for platform-ar and then ar. Plain ar is fine for native builds. You probably should build outside the source tree. It is strongly recommended at least for gcc. - Jay (phone) On Jun 11, 2009, at 12:29 PM, Elmar Stellnberger wrote: > As I still have the old PM3/EZM3 in use I do welcome the continuing > support for that kind of old compiler tech. Besides all these advanced > issues I still simply wonder on how to compile a current m3gdb. As > described earlier ./configure does not even find the standard > utilities > like ar, as, etc. although they are on path: > > ../gdb/configure --target i686-pc-linux-gnu > checking for i686-pc-linux-gnu-ar... no > checking for i686-pc-linux-gnu-as... no > > I will be happy as soon as I can print global integer variables. I > can > convert Text-vars to char* although that will cause little extra > output. > The thing is that even some elder m3gdb that I still have a > compilate of > can not print global vars for any kind of reason (perhaps it would be > necessary to update the codegen). > > Rodney M. Bates schrieb: >> Jay wrote: >>> scripts/do-cm3-m3gdb.sh just cd's over to m3-sys/m3gdb and runs cm3. >>> >>> m3gdb builds and seems to work fine for me. >>> >>> Specifically, on AMD64_LINUX birch, I can both: >>> >>> mkdir -p $HOME/obj/gdb >>> cd $HOME/obj/gdb >>> $HOME/dev2/cm3/m3-sys/m3gdb/gdb/configure && make >>> gdb/gdb gdb/gdb >>> break main >>> r >>> >>> and >>> >>> cd $HOME/dev2/cm3/m3-sys/m3gdb >>> rm -rf AMD64_LINUX >>> cm3 >>> >>> >>> AMD64_LINUX/m3gdb AMD64_LINUX/m3gdb >>> break main >>> r >>> >>> >>> I haven't tried with Modula-3 code and/or stabs. >>> >>> >>> Updating from the 2005 6.4 release to a current 6.8 release is >>> probably advisable anyway. >>> >>> >>> But again, um, er, could we maybe adapt the generated code so that >>> plain gdb is all anyone would need/want? >> I don't think so. There is ~ 20K lines of Modula-3-specific code in >> m3gdb, and I have tens of >> pages of handwritten lists of more that ought to be done to make it a >> nice M3 debugger. >> I think doing it all could easily double this. The variable >> reference >> rules are different >> from C/C++, for example, because of the link between a module and its >> exported >> interface(s). >> >> The global variable thing is just the tip of the iceberg. For >> example, >> there is a whole lot >> to making procedure calls and method calls work. Ditto for nested >> procedures, which, >> after several iterations, is broken again by the change to the newest >> gcc as the base for >> the code generator, although it works somewhat. Note that gdb >> provides >> no real >> support for nested functions in C, even though gcc supports them as >> an >> extension to C. >> Probably, they are little used in C. I use them a lot in M3. >> >> Then there are just all the language-specific formats for input and >> output values, >> and expression syntax. Plus, Modula-3, being a considerably >> higher-level language, >> (at least optionally,) has a significant runtime system, and m3gdb >> needs >> to know \ >> quite a bit about that too. Real arrays and open arrays also need >> support. And >> TEXT is a lot different. >> >> >> There are also some significant differences between cm3 and the >> earlier >> compilers. >> I have taken the position that support for the older ones should >> remain, >> along with >> new stuff too. >> >> >> What we should do, in addition to updating to newest gdb, is change >> from >> stabs to >> dwarf2 debug info format, which is *much* richer in what it can >> express. stabs was >> something of a cobbled up mess to begin with, and the M3-specific >> extensions to it >> only make it worse. There's a lot of what has to be seen as very >> arbitrary stuff, >> not really stabs, wrapped inside of some of the character strings >> that >> stabs has. This change would require a significant amount of code >> in the >> compiler, as well >> as in m3gdb. >> >> >> Someday, it might also be nice to try to get the m3 changes rolled >> in to >> the stock >> gdb. This would require a serious commitment to maintain them there. >> Also, there >> are some copyright assertions that DEC put in to some of the code >> that, >> I believe >> were in violation of the GPL. We would have to somehow get a >> determination that >> the copyright ownership could be transferred to FSF, to their >> satisfaction. All the >> more difficult with DEC's identity having changed twice. IANAL. >>> >>> >>> Cygwin fork being so slow makes me want to optimize out such large >>> pieces as building gdb. >>> Maybe I can figure out a way to speed up Cygwin fork some day... >>> >>> >>> - Jay >>> >>> >> >> > > From jay.krell at cornell.edu Fri Jun 12 07:09:57 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 12 Jun 2009 05:09:57 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> <4A315B36.9000700@yahoo.de> <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> Message-ID: ps: I suggest you try to get stock gdb to build first. wget ftp://sourceware.org/pub/gdb/releases/gdb-6.8.tar.gz tar xfz gdb-6.8.tar.gz mkdir -p obj/gdb cd obj/gdb ../../gdb-6.8/configure && make - Jay [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at yahoo.de Fri Jun 12 12:27:55 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Fri, 12 Jun 2009 11:27:55 +0100 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> <4A315B36.9000700@yahoo.de> <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> Message-ID: <4A322DAB.50000@yahoo.de> Compiling gdb worked on my first attempt. checking for ar... ar checking for as... as The configure script seems to find all standard utils and make compiles gdb well. Jay schrieb: > ps: I suggest you try to get stock gdb to build first. > > > > wget ftp://sourceware.org/pub/gdb/releases/gdb-6.8.tar.gz > tar xfz gdb-6.8.tar.gz > mkdir -p obj/gdb > cd obj/gdb > ../../gdb-6.8/configure && make > > > > - Jay > [snip] > > > From jay.krell at cornell.edu Sat Jun 13 04:14:11 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 13 Jun 2009 02:14:11 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A322DAB.50000@yahoo.de> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> <4A315B36.9000700@yahoo.de> <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> <4A322DAB.50000@yahoo.de> Message-ID: Ok, the difference is configure vs. configure --target i686-pc-linux-gnu. cm3 only passes --target for cross builds...er, maybe not. That's how it is for m3cc. But http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3gdb/src/m3makefile?rev=1.13;content-type=text%2Fplain appears to always pass --target. (Have I mentioned I don't pay much attention to m3gdb...?) For now, in m3-sys/m3gdb/src/m3makefile, change this: m3gdb_Run([M3GDB_CONFIG, "../gdb/configure", CONFIG_PLATFORM]) to just this: m3gdb_Run([M3GDB_CONFIG, "../gdb/configure"]) removing the CONFIG_PLATFORM part and see what happens. I expect it will work. That isn't necessarily the right change -- don't commit it. Probably what is right enough is to make it act like m3ccc -- don't give a platform for native builds, only for cross builds. But m3cc/m3gdb/binutils are all fairly unusual, and not necessarily in the same way. Even so..are you after an x86 m3gdb or AMD64? Also, what do m3-sys/m3gdb/gdb/config.guess and m3-sys/m3cc/gcc/config.guess and the current gdb you downloaded/config.guess show? - Jay ---------------------------------------- > Date: Fri, 12 Jun 2009 11:27:55 +0100 > From: estellnb at yahoo.de > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent m3gdb does not want to compile > > Compiling gdb worked on my first attempt. > > checking for ar... ar > checking for as... as > > The configure script seems to find all standard utils and > make compiles gdb well. > > Jay schrieb: >> ps: I suggest you try to get stock gdb to build first. >> >> >> >> wget ftp://sourceware.org/pub/gdb/releases/gdb-6.8.tar.gz >> tar xfz gdb-6.8.tar.gz >> mkdir -p obj/gdb >> cd obj/gdb >> ../../gdb-6.8/configure && make >> >> >> >> - Jay >> [snip] >> >> >> > From jay.krell at cornell.edu Mon Jun 15 09:13:19 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 07:13:19 +0000 Subject: [M3devel] Solaris vfork? => suggest using fork instead? Message-ID: Is this still true: C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(943):(*** vfork - spawn new process in a virtual memory efficient way ***) C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(944):(* Avoid vfork. The way it is used in ProcessPosix breaks incremental GC: ? (*** vfork - spawn new process in a virtual memory efficient way ***) (* Avoid vfork. The way it is used in ProcessPosix breaks incremental GC: RestoreHandlers in child is reflected in parent to break VM faulting *) <*EXTERNAL "fork1"*> PROCEDURE vfork (): int; If this is true, I broke it. C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX does use vfork. Should we just use fork? vfork is the same as fork on Cygwin -- both are slow. There is also reason to use fork on NetBSD. NetBSD renames nearly every single symbol at the link level via special constructs in its header files. As a result, the usual direct extern Modula-3 pragmas are rarely correct there. That is, for the sake of NetBSD, it is best to wrap every C function with our own C functions. However, wrapping functions contradicts the Posix constraints on vfork -- you are not allowed to return from the function calling vfork without calling exec or _exit. Or do no real systems care about that? So, to be clear, I suggest changing ProcessPosix.m3 from vfork to fork. As well as RTPerfTool.m3. I suggest removing vfork from Unix/*.i3, make sure everything compiles -- that nobody uses it -- and then restoring it, in case there is a later need, to avoid bootstrapping problems if there is. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jun 15 13:12:39 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 15 Jun 2009 04:12:39 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> Message-ID: <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Hi Jay, I've been seeing some new errors attempting to build m3cc on OSX 10.4 / ppc. It seems like it might... possibly... be related to some things you have done? Or at least it's happening in the same general area of the compiler. Here we go: cd ../../gcc/mpfr && : make[2]: Nothing to be done for `all-am'. make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all'. make[1]: Nothing to be done for `all'. cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 --procedure-- -line- -file--- cp_if -- postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args Fatal Error: package build failed [lapdog:~/cm3/m3-sys/m3cc] mika% Any ideas what might be causing this? Mika Jay Krell writes: >CVSROOT: /usr/cvs >Changes by: jkrell at birch. 09/06/15 11:49:14 > >Added files: > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > gengtype-yacc.h > >Log message: > Add back the lex/yacc/flex/bison outputs that Apple deleted > but didn't note in the REMOVED file. You only see their > absence cause problems if building on a machine without > lex/yacc/flex/bison, such as birch that is missing bison. > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > so the unmodified versions of these files taken from gcc 4.2.1. From jay.krell at cornell.edu Mon Jun 15 13:26:16 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 11:26:16 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> References: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: You need a newer make. I don't remember upgrading mine, and I am using 10.4, but these are the same errors that Olaf reported on 10.3, and they were fixed by upgrading make for him. If there are really only two relevant uses of patsubst, maybe we can recode them to be more compatible? - Jay > To: jkrell at elego.de; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 15 Jun 2009 04:12:39 -0700 > From: mika at async.caltech.edu > > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: > >CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/06/15 11:49:14 > > > >Added files: > > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > > gengtype-yacc.h > > > >Log message: > > Add back the lex/yacc/flex/bison outputs that Apple deleted > > but didn't note in the REMOVED file. You only see their > > absence cause problems if building on a machine without > > lex/yacc/flex/bison, such as birch that is missing bison. > > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > > so the unmodified versions of these files taken from gcc 4.2.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 15 13:56:45 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 11:56:45 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: Please try with the change to m3makefile I just made. That might reduce or eliminate the errors. The line number didn't match up for me. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:26:16 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 You need a newer make. I don't remember upgrading mine, and I am using 10.4, but these are the same errors that Olaf reported on 10.3, and they were fixed by upgrading make for him. If there are really only two relevant uses of patsubst, maybe we can recode them to be more compatible? - Jay > To: jkrell at elego.de; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 15 Jun 2009 04:12:39 -0700 > From: mika at async.caltech.edu > > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: > >CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/06/15 11:49:14 > > > >Added files: > > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > > gengtype-yacc.h > > > >Log message: > > Add back the lex/yacc/flex/bison outputs that Apple deleted > > but didn't note in the REMOVED file. You only see their > > absence cause problems if building on a machine without > > lex/yacc/flex/bison, such as birch that is missing bison. > > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > > so the unmodified versions of these files taken from gcc 4.2.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 15 13:59:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 11:59:52 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: If that has no positive effect at all, try removing this line from m3makefile: % Save some libtool wrapping layers to speed up esp. on NT? Configure = Configure & " -disable-dependency-tracking" and be sure to rm -rf the output directory after making the change (or picking up my other change). - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:56:45 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Please try with the change to m3makefile I just made. That might reduce or eliminate the errors. The line number didn't match up for me. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:26:16 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 You need a newer make. I don't remember upgrading mine, and I am using 10.4, but these are the same errors that Olaf reported on 10.3, and they were fixed by upgrading make for him. If there are really only two relevant uses of patsubst, maybe we can recode them to be more compatible? - Jay > To: jkrell at elego.de; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 15 Jun 2009 04:12:39 -0700 > From: mika at async.caltech.edu > > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: > >CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/06/15 11:49:14 > > > >Added files: > > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > > gengtype-yacc.h > > > >Log message: > > Add back the lex/yacc/flex/bison outputs that Apple deleted > > but didn't note in the REMOVED file. You only see their > > absence cause problems if building on a machine without > > lex/yacc/flex/bison, such as birch that is missing bison. > > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > > so the unmodified versions of these files taken from gcc 4.2.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 15 14:11:08 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 12:11:08 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: Can you show me: /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/libcpp/Makefile(191) and /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/gcc/Makefile(4437) and nearby? And if those don't have patsubst: cd /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN grep -r patsubst * - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Mon, 15 Jun 2009 11:59:52 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 If that has no positive effect at all, try removing this line from m3makefile: % Save some libtool wrapping layers to speed up esp. on NT? Configure = Configure & " -disable-dependency-tracking" and be sure to rm -rf the output directory after making the change (or picking up my other change). - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:56:45 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Please try with the change to m3makefile I just made. That might reduce or eliminate the errors. The line number didn't match up for me. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:26:16 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 You need a newer make. I don't remember upgrading mine, and I am using 10.4, but these are the same errors that Olaf reported on 10.3, and they were fixed by upgrading make for him. If there are really only two relevant uses of patsubst, maybe we can recode them to be more compatible? - Jay > To: jkrell at elego.de; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 15 Jun 2009 04:12:39 -0700 > From: mika at async.caltech.edu > > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: > >CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/06/15 11:49:14 > > > >Added files: > > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > > gengtype-yacc.h > > > >Log message: > > Add back the lex/yacc/flex/bison outputs that Apple deleted > > but didn't note in the REMOVED file. You only see their > > absence cause problems if building on a machine without > > lex/yacc/flex/bison, such as birch that is missing bison. > > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > > so the unmodified versions of these files taken from gcc 4.2.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jun 15 15:29:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 15 Jun 2009 09:29:39 -0400 Subject: [M3devel] Solaris vfork? => suggest using fork instead? In-Reply-To: References: Message-ID: <4CE51F26-EDE3-46F7-9857-248D435669C3@cs.purdue.edu> Signals are no longer used for inc gc so probably ok to switch to fork. On 15 Jun 2009, at 03:13, Jay wrote: > Is this still true: > > > C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(943):(*** > vfork - spawn new process in a virtual memory efficient way ***) > C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(944):(* > Avoid vfork. The way it is used in ProcessPosix breaks incremental GC: > ? > > (*** vfork - spawn new process in a virtual memory efficient way ***) > (* Avoid vfork. The way it is used in ProcessPosix breaks > incremental GC: > RestoreHandlers in child is reflected in parent to break VM faulting > *) > <*EXTERNAL "fork1"*> PROCEDURE vfork (): int; > > > If this is true, I broke it. > > > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX does use vfork. > > > Should we just use fork? > vfork is the same as fork on Cygwin -- both are slow. > > There is also reason to use fork on NetBSD. > NetBSD renames nearly every single symbol at the link level via > special constructs in its header files. > As a result, the usual direct extern Modula-3 pragmas are rarely > correct there. > That is, for the sake of NetBSD, it is best to wrap every C > function with our own C functions. > However, wrapping functions contradicts the Posix constraints on > vfork -- you are not allowed to return from the function calling > vfork without calling exec or _exit. Or do no real systems care > about that? > > > So, to be clear, I suggest changing ProcessPosix.m3 from vfork to > fork. > As well as RTPerfTool.m3. > > > I suggest removing vfork from Unix/*.i3, make sure everything > compiles -- that nobody uses it -- and then restoring it, in case > there is a later need, to avoid bootstrapping problems if there is. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jun 15 21:09:48 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 15 Jun 2009 12:09:48 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 15 Jun 2009 11:56:45 -0000." Message-ID: <200906151909.n5FJ9mJq038972@camembert.async.caltech.edu> Yep, that seems to have fixed that problem. Thanks! Mika Jay writes: >--_b2ac6846-ec7a-45ce-b56a-ddd2a77b25de_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Please try with the change to m3makefile I just made. > >That might reduce or eliminate the errors. > >The line number didn't match up for me. > >=20 > > - Jay >=20 > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu=3B jkrell at elego.de >Date: Mon=2C 15 Jun 2009 11:26:16 +0000 >CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > >You need a newer make. >I don't remember upgrading mine=2C and I am using 10.4=2C but these are the= > same errors that Olaf reported on 10.3=2C and they were fixed by upgrading= > make for him. >=20 >If there are really only two relevant uses of patsubst=2C maybe we can reco= >de them to be more compatible? >=20 > - Jay > >=20 >> To: jkrell at elego.de=3B jay.krell at cornell.edu >> CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >> Subject: Re: [M3commit] CVS Update: cm3=20 >> Date: Mon=2C 15 Jun 2009 04:12:39 -0700 >> From: mika at async.caltech.edu >>=20 >> Hi Jay=2C >>=20 >> I've been seeing some new errors attempting to build m3cc on OSX >> 10.4 / ppc. >>=20 >> It seems like it might... possibly... be related to some things you >> have done? Or at least it's happening in the same general area of >> the compiler. >>=20 >> Here we go: >>=20 >> cd ../../gcc/mpfr && : >> make[2]: Nothing to be done for `all-am'. >> make[2]: Nothing to be done for `all'. >> make[2]: Nothing to be done for `all'. >> make[1]: Nothing to be done for `all'. >> cd . && cd libcpp && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOM= >AKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/c= >m3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> cd . && cd libcpp && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOM= >AKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/c= >m3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> Makefile:191: *** Insufficient number of arguments (2) to function `patsu= >bst'. Stop. >> cd . && cd gcc && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config.h m3cg | tee -= >a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> cd . && cd gcc && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config.h m3cg | tee -= >a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> Makefile:4437: *** Insufficient number of arguments (2) to function `pats= >ubst'. Stop. >> "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile"=2C line 508: quake runtime e= >rror: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=3D2 >>=20 >> --procedure-- -line- -file--- >> cp_if -- >> postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile >> include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile >> 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args >>=20 >> Fatal Error: package build failed >> [lapdog:~/cm3/m3-sys/m3cc] mika%=20 >>=20 >> Any ideas what might be causing this? >>=20 >> Mika >>=20 >>=20 >>=20 >> Jay Krell writes: >> >CVSROOT: /usr/cvs >> >Changes by: jkrell at birch. 09/06/15 11:49:14 >> > >> >Added files: >> > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c=20 >> > gengtype-yacc.h=20 >> > >> >Log message: >> > Add back the lex/yacc/flex/bison outputs that Apple deleted >> > but didn't note in the REMOVED file. You only see their >> > absence cause problems if building on a machine without >> > lex/yacc/flex/bison=2C such as birch that is missing bison. >> > Apple didn't modify gengtype-lex.l and gentype-yacc.y=2C >> > so the unmodified versions of these files taken from gcc 4.2.1. > >--_b2ac6846-ec7a-45ce-b56a-ddd2a77b25de_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Please try with the change to m3makefile I just made.
>That might reduce or eliminate =3Bthe errors.
>The line number didn't match up for me.
> =3B
> =3B- Jay
 =3B
>
>From: jay.krell at cornell.edu
To: mika at async.caltech.edu=3B jkrell at elego.d= >e
Date: Mon=2C 15 Jun 2009 11:26:16 +0000
CC: m3devel at elegosoft.com= >=3B mika at camembert.async.caltech.edu
Subject: Re: [M3devel] [M3commit] C= >VS Update: cm3

> >You need a newer make.
I don't remember upgrading mine=2C and I am using= > 10.4=2C but these are the same errors that Olaf reported on 10.3=2C and th= >ey were fixed by upgrading make for him.
 =3B
If there are really= > only two relevant uses of patsubst=2C maybe we can recode them to be more = >compatible?
 =3B
 =3B- Jay

 =3B
>=3B To: jkre= >ll at elego.de=3B jay.krell at cornell.edu
>=3B CC: m3devel at elegosoft.com=3B= > mika at camembert.async.caltech.edu
>=3B Subject: Re: [M3commit] CVS Upd= >ate: cm3
>=3B Date: Mon=2C 15 Jun 2009 04:12:39 -0700
>=3B From:= > mika at async.caltech.edu
>=3B
>=3B Hi Jay=2C
>=3B
>=3B= > I've been seeing some new errors attempting to build m3cc on OSX
>=3B= > 10.4 / ppc.
>=3B
>=3B It seems like it might... possibly... be = >related to some things you
>=3B have done? Or at least it's happening = >in the same general area of
>=3B the compiler.
>=3B
>=3B He= >re we go:
>=3B
>=3B cd ../../gcc/mpfr &=3B&=3B :
>=3B= > make[2]: Nothing to be done for `all-am'.
>=3B make[2]: Nothing to be= > done for `all'.
>=3B make[2]: Nothing to be done for `all'.
>=3B= > make[1]: Nothing to be done for `all'.
>=3B cd . &=3B&=3B cd li= >bcpp &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/cm3/= >m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
>=3B cd . &=3B&=3B cd libc= >pp &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/cm3/= >m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
>=3B Makefile:191: *** Insuffici= >ent number of arguments (2) to function `patsubst'. Stop.
>=3B cd . &a= >mp=3B&=3B cd gcc &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCO= >NF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config= >.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
&= >gt=3B cd . &=3B&=3B cd gcc &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-= >O2 -g" AUTOCONF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-mode= >s insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN= >/_m3.log
>=3B Makefile:4437: *** Insufficient number of arguments (2) = >to function `patsubst'. Stop.
>=3B "/Users/mika/cm3/m3-sys/m3cc/src/m3= >makefile"=2C line 508: quake runtime error: unable to copy "./gcc/m3cgc1" t= >o "./cm3cg": errno=3D2
>=3B
>=3B --procedure-- -line- -file---R>>=3B cp_if -- <=3Bbuiltin>=3B
>=3B postcp 508 /Users/mika/cm3/= >m3-sys/m3cc/src/m3makefile
>=3B include_dir 592 /Users/mika/cm3/m3-sys= >/m3cc/src/m3makefile
>=3B 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3m= >ake.args
>=3B
>=3B Fatal Error: package build failed
>=3B [= >lapdog:~/cm3/m3-sys/m3cc] mika%
>=3B
>=3B Any ideas what might = >be causing this?
>=3B
>=3B Mika
>=3B
>=3B
>=3B = >
>=3B Jay Krell writes:
>=3B >=3BCVSROOT: /usr/cvs
>=3B &g= >t=3BChanges by: jkrell at birch. 09/06/15 11:49:14
>=3B >=3B
>=3B = >>=3BAdded files:
>=3B >=3B cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtyp= >e-lex.c gengtype-yacc.c
>=3B >=3B gengtype-yacc.h
>=3B >=3B= >
>=3B >=3BLog message:
>=3B >=3B Add back the lex/yacc/flex/b= >ison outputs that Apple deleted
>=3B >=3B but didn't note in the REM= >OVED file. You only see their
>=3B >=3B absence cause problems if bu= >ilding on a machine without
>=3B >=3B lex/yacc/flex/bison=2C such as= > birch that is missing bison.
>=3B >=3B Apple didn't modify gengtype= >-lex.l and gentype-yacc.y=2C
>=3B >=3B so the unmodified versions of= > these files taken from gcc 4.2.1.
>= > >--_b2ac6846-ec7a-45ce-b56a-ddd2a77b25de_-- From mika at async.caltech.edu Mon Jun 15 21:12:56 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 15 Jun 2009 12:12:56 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 15 Jun 2009 12:11:08 -0000." Message-ID: <200906151912.n5FJCu1t039130@camembert.async.caltech.edu> I already CVS updated but here is what I see now: [lapdog:m3-sys/m3cc/PPC_DARWIN] mika% grep patsubst */Makefile gcc/Makefile:srcdirify = $(patsubst $(srcdir)%,$$(gcc_srcdir)%,$(filter $(srcdir)%,$(1))) \ gcc/Makefile: $(patsubst %,$$(gcc_objdir)/%,$(filter-out $(srcdir)%,$(1))) gcc/Makefile:GTFILES_H = $(subst /,-, $(patsubst $(srcdir)/%,gt-%, $(patsubst %.c,%.h, \ gcc/Makefile:GTFILES_LANG_H = $(patsubst [%], gtype-%.h, $(filter [%], $(GTFILES))) libcpp/Makefile:-include $(patsubst %.o, $(DEPDIR)/%.Po, $(libcpp_a_OBJS) $(makedepend_OBJS)) [lapdog:m3-sys/m3cc/PPC_DARWIN] mika% Jay writes: >--_f3a3f40d-3d61-443a-b5cd-8c10d784957b_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Can you show me: > > > /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/libcpp/Makefile(191) =20 > > and =20 > > /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/gcc/Makefile(4437) =20 > >=20 > > and nearby? And if those don't have patsubst: =20 > >=20 > > cd /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN =20 > > grep -r patsubst * =20 > >=20 > > - Jay >=20 > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu >Date: Mon=2C 15 Jun 2009 11:59:52 +0000 >CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > >If that has no positive effect at all=2C try removing this line from m3make= >file: >=20 > % Save some libtool wrapping layers to speed up esp. on NT? > Configure =3D Configure & " -disable-dependency-tracking" > and be sure to rm -rf the output directory after making the change (or pick= >ing up my other change). >=20 > - Jay >=20 > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu=3B jkrell at elego.de >Date: Mon=2C 15 Jun 2009 11:56:45 +0000 >CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > >Please try with the change to m3makefile I just made. >That might reduce or eliminate the errors. >The line number didn't match up for me. >=20 > - Jay >=20 > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu=3B jkrell at elego.de >Date: Mon=2C 15 Jun 2009 11:26:16 +0000 >CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > >You need a newer make. >I don't remember upgrading mine=2C and I am using 10.4=2C but these are the= > same errors that Olaf reported on 10.3=2C and they were fixed by upgrading= > make for him. >=20 >If there are really only two relevant uses of patsubst=2C maybe we can reco= >de them to be more compatible? >=20 > - Jay > >=20 >> To: jkrell at elego.de=3B jay.krell at cornell.edu >> CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >> Subject: Re: [M3commit] CVS Update: cm3=20 >> Date: Mon=2C 15 Jun 2009 04:12:39 -0700 >> From: mika at async.caltech.edu >>=20 >> Hi Jay=2C >>=20 >> I've been seeing some new errors attempting to build m3cc on OSX >> 10.4 / ppc. >>=20 >> It seems like it might... possibly... be related to some things you >> have done? Or at least it's happening in the same general area of >> the compiler. >>=20 >> Here we go: >>=20 >> cd ../../gcc/mpfr && : >> make[2]: Nothing to be done for `all-am'. >> make[2]: Nothing to be done for `all'. >> make[2]: Nothing to be done for `all'. >> make[1]: Nothing to be done for `all'. >> cd . && cd libcpp && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOM= >AKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/c= >m3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> cd . && cd libcpp && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOM= >AKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/c= >m3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> Makefile:191: *** Insufficient number of arguments (2) to function `patsu= >bst'. Stop. >> cd . && cd gcc && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config.h m3cg | tee -= >a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> cd . && cd gcc && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config.h m3cg | tee -= >a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> Makefile:4437: *** Insufficient number of arguments (2) to function `pats= >ubst'. Stop. >> "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile"=2C line 508: quake runtime e= >rror: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=3D2 >>=20 >> --procedure-- -line- -file--- >> cp_if -- >> postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile >> include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile >> 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args >>=20 >> Fatal Error: package build failed >> [lapdog:~/cm3/m3-sys/m3cc] mika%=20 >>=20 >> Any ideas what might be causing this? >>=20 >> Mika >>=20 >>=20 >>=20 >> Jay Krell writes: >> >CVSROOT: /usr/cvs >> >Changes by: jkrell at birch. 09/06/15 11:49:14 >> > >> >Added files: >> > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c=20 >> > gengtype-yacc.h=20 >> > >> >Log message: >> > Add back the lex/yacc/flex/bison outputs that Apple deleted >> > but didn't note in the REMOVED file. You only see their >> > absence cause problems if building on a machine without >> > lex/yacc/flex/bison=2C such as birch that is missing bison. >> > Apple didn't modify gengtype-lex.l and gentype-yacc.y=2C >> > so the unmodified versions of these files taken from gcc 4.2.1. > >--_f3a3f40d-3d61-443a-b5cd-8c10d784957b_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Can you show me:
>
 =3B /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/libcpp/Makefile(191)&nb= >sp=3B
> =3B and =3B
> =3B /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/gcc/Makefile(4437) =3B = >
> =3B
> =3B and nearby? And if those don't have patsubst: =3B
> =3B
> =3B cd /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN =3B
> =3B grep -r patsubst * =3B
> =3B
> =3B- Jay
 =3B
>
>From: jay.krell at cornell.edu
To: mika at async.caltech.edu
Date: Mon=2C 1= >5 Jun 2009 11:59:52 +0000
CC: m3devel at elegosoft.com=3B mika at camembert.as= >ync.caltech.edu
Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> > >If that has no positive effect at all=2C try removing this line from m3make= >file:
 =3B
 =3B =3B =3B % Save some libtool wrapping = >layers to speed up esp. on NT?
 =3B =3B =3B Configure =3D Co= >nfigure &=3B " -disable-dependency-tracking"

and be sure to rm -r= >f the output directory after making the change (or picking up my other chan= >ge).
 =3B
 =3B- Jay
 =3B
>
>From: jay.krell at cornell.edu
To: mika at async.caltech.edu=3B jkrell at elego.d= >e
Date: Mon=2C 15 Jun 2009 11:56:45 +0000
CC: m3devel at elegosoft.com= >=3B mika at camembert.async.caltech.edu
Subject: Re: [M3devel] [M3commit] C= >VS Update: cm3

> >Please try with the change to m3makefile I just made.
That might reduce = >or eliminate =3Bthe errors.
The line number didn't match up for me.<= >BR> =3B
 =3B- Jay
 =3B
>
>From: jay.krell at cornell.edu
To: mika at async.caltech.edu=3B jkrell at elego.d= >e
Date: Mon=2C 15 Jun 2009 11:26:16 +0000
CC: m3devel at elegosoft.com= >=3B mika at camembert.async.caltech.edu
Subject: Re: [M3devel] [M3commit] C= >VS Update: cm3

> >You need a newer make.
I don't remember upgrading mine=2C and I am using= > 10.4=2C but these are the same errors that Olaf reported on 10.3=2C and th= >ey were fixed by upgrading make for him.
 =3B
If there are really= > only two relevant uses of patsubst=2C maybe we can recode them to be more = >compatible?
 =3B
 =3B- Jay

 =3B
>=3B To: jkre= >ll at elego.de=3B jay.krell at cornell.edu
>=3B CC: m3devel at elegosoft.com=3B= > mika at camembert.async.caltech.edu
>=3B Subject: Re: [M3commit] CVS Upd= >ate: cm3
>=3B Date: Mon=2C 15 Jun 2009 04:12:39 -0700
>=3B From:= > mika at async.caltech.edu
>=3B
>=3B Hi Jay=2C
>=3B
>=3B= > I've been seeing some new errors attempting to build m3cc on OSX
>=3B= > 10.4 / ppc.
>=3B
>=3B It seems like it might... possibly... be = >related to some things you
>=3B have done? Or at least it's happening = >in the same general area of
>=3B the compiler.
>=3B
>=3B He= >re we go:
>=3B
>=3B cd ../../gcc/mpfr &=3B&=3B :
>=3B= > make[2]: Nothing to be done for `all-am'.
>=3B make[2]: Nothing to be= > done for `all'.
>=3B make[2]: Nothing to be done for `all'.
>=3B= > make[1]: Nothing to be done for `all'.
>=3B cd . &=3B&=3B cd li= >bcpp &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/cm3/= >m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
>=3B cd . &=3B&=3B cd libc= >pp &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/cm3/= >m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
>=3B Makefile:191: *** Insuffici= >ent number of arguments (2) to function `patsubst'. Stop.
>=3B cd . &a= >mp=3B&=3B cd gcc &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCO= >NF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config= >.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
&= >gt=3B cd . &=3B&=3B cd gcc &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-= >O2 -g" AUTOCONF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-mode= >s insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN= >/_m3.log
>=3B Makefile:4437: *** Insufficient number of arguments (2) = >to function `patsubst'. Stop.
>=3B "/Users/mika/cm3/m3-sys/m3cc/src/m3= >makefile"=2C line 508: quake runtime error: unable to copy "./gcc/m3cgc1" t= >o "./cm3cg": errno=3D2
>=3B
>=3B --procedure-- -line- -file---R>>=3B cp_if -- <=3Bbuiltin>=3B
>=3B postcp 508 /Users/mika/cm3/= >m3-sys/m3cc/src/m3makefile
>=3B include_dir 592 /Users/mika/cm3/m3-sys= >/m3cc/src/m3makefile
>=3B 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3m= >ake.args
>=3B
>=3B Fatal Error: package build failed
>=3B [= >lapdog:~/cm3/m3-sys/m3cc] mika%
>=3B
>=3B Any ideas what might = >be causing this?
>=3B
>=3B Mika
>=3B
>=3B
>=3B = >
>=3B Jay Krell writes:
>=3B >=3BCVSROOT: /usr/cvs
>=3B &g= >t=3BChanges by: jkrell at birch. 09/06/15 11:49:14
>=3B >=3B
>=3B = >>=3BAdded files:
>=3B >=3B cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtyp= >e-lex.c gengtype-yacc.c
>=3B >=3B gengtype-yacc.h
>=3B >=3B= >
>=3B >=3BLog message:
>=3B >=3B Add back the lex/yacc/flex/b= >ison outputs that Apple deleted
>=3B >=3B but didn't note in the REM= >OVED file. You only see their
>=3B >=3B absence cause problems if bu= >ilding on a machine without
>=3B >=3B lex/yacc/flex/bison=2C such as= > birch that is missing bison.
>=3B >=3B Apple didn't modify gengtype= >-lex.l and gentype-yacc.y=2C
>=3B >=3B so the unmodified versions of= > these files taken from gcc 4.2.1.
>= > >--_f3a3f40d-3d61-443a-b5cd-8c10d784957b_-- From jay.krell at cornell.edu Mon Jun 15 21:50:39 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 19:50:39 +0000 Subject: [M3devel] tinderbox FreeBSD diskspace Message-ID: The FreeBSD tinderbox machines continue to run out of diskspace occasionally. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 15 22:47:21 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 15 Jun 2009 13:47:21 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200906151912.n5FJCu1t039130@camembert.async.caltech.edu> References: <200906151912.n5FJCu1t039130@camembert.async.caltech.edu> Message-ID: <1B731B2D-D655-44BC-A4A9-4AB274558270@hotmail.com> Ok so presumably on those lines is 'CATALOGS'? - Jay (phone) On Jun 15, 2009, at 12:12 PM, Mika Nystrom wrote: > I already CVS updated but here is what I see now: > > [lapdog:m3-sys/m3cc/PPC_DARWIN] mika% grep patsubst */Makefile > gcc/Makefile:srcdirify = $(patsubst $(srcdir)%,$$(gcc_srcdir)%,$ > (filter $(srcdir)%,$(1))) \ > gcc/Makefile: $(patsubst %,$$(gcc_objdir)/%,$(filter-out $ > (srcdir)%,$(1))) > gcc/Makefile:GTFILES_H = $(subst /,-, $(patsubst $(srcdir)/%,gt-%, $ > (patsubst %.c,%.h, \ > gcc/Makefile:GTFILES_LANG_H = $(patsubst [%], gtype-%.h, $(filter > [%], $(GTFILES))) > libcpp/Makefile:-include $(patsubst %.o, $(DEPDIR)/%.Po, $ > (libcpp_a_OBJS) $(makedepend_OBJS)) > [lapdog:m3-sys/m3cc/PPC_DARWIN] mika% > > Jay writes: >> --_f3a3f40d-3d61-443a-b5cd-8c10d784957b_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> Can you show me: >> >> >> /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/libcpp/Makefile(191) =20 >> >> and =20 >> >> /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/gcc/Makefile(4437) =20 >> >> =20 >> >> and nearby? And if those don't have patsubst: =20 >> >> =20 >> >> cd /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN =20 >> >> grep -r patsubst * =20 >> >> =20 >> >> - Jay >> =20 >> > From jay.krell at cornell.edu Tue Jun 16 07:02:48 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 15 Jun 2009 22:02:48 -0700 Subject: [M3devel] Solaris vfork? => suggest using fork instead? In-Reply-To: <4CE51F26-EDE3-46F7-9857-248D435669C3@cs.purdue.edu> References: <4CE51F26-EDE3-46F7-9857-248D435669C3@cs.purdue.edu> Message-ID: <83CA3DD2-C85B-4C1F-A14D-DC535C093B8D@hotmail.com> Ps I exaggerated netbsd. It does rename some functions though. - Jay (phone) On Jun 15, 2009, at 6:29 AM, Tony Hosking wrote: > Signals are no longer used for inc gc so probably ok to switch to > fork. > > On 15 Jun 2009, at 03:13, Jay wrote: > >> Is this still true: >> >> >> C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(943):(*** >> vfork - spawn new process in a virtual memory efficient way ***) >> C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(944):(* >> Avoid vfork. The way it is used in ProcessPosix breaks incremental >> GC: >> ? >> >> (*** vfork - spawn new process in a virtual memory efficient way ***) >> (* Avoid vfork. The way it is used in ProcessPosix breaks >> incremental GC: >> RestoreHandlers in child is reflected in parent to break VM >> faulting *) >> <*EXTERNAL "fork1"*> PROCEDURE vfork (): int; >> >> >> If this is true, I broke it. >> >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX does use vfork. >> >> >> Should we just use fork? >> vfork is the same as fork on Cygwin -- both are slow. >> >> There is also reason to use fork on NetBSD. >> NetBSD renames nearly every single symbol at the link level via >> special constructs in its header files. >> As a result, the usual direct extern Modula-3 pragmas are rarely >> correct there. >> That is, for the sake of NetBSD, it is best to wrap every C >> function with our own C functions. >> However, wrapping functions contradicts the Posix constraints on >> vfork -- you are not allowed to return from the function calling >> vfork without calling exec or _exit. Or do no real systems care >> about that? >> >> >> So, to be clear, I suggest changing ProcessPosix.m3 from vfork to >> fork. >> As well as RTPerfTool.m3. >> >> >> I suggest removing vfork from Unix/*.i3, make sure everything >> compiles -- that nobody uses it -- and then restoring it, in case >> there is a later need, to avoid bootstrapping problems if there is. >> >> >> - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Jun 16 09:01:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 16 Jun 2009 00:01:18 -0700 Subject: [M3devel] Strange behavior in recent CM3-compiled code... Message-ID: <200906160701.n5G71I8K061661@camembert.async.caltech.edu> Hello everyone, I'm trying to update to the latest CM3 again, so that I can get my Mac working, and push my project of migrating a largish codebase from PM3 to CM3 a little further. I updated CM3 today from CVS, on both my Mac and on a FreeBSD system, and ... my Scheme interpreter broke. Here's what the code looks like, with annotations: 49 Debug.Out("t.rest = NIL? " & Fmt.Bool(t.rest=NIL)); 50 Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); 51 Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); 52 53 IF t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL THEN 54 Debug.Out("in IF clause..."); 55 56 IF SymEq(t.first, "quote") THEN special := "'" 57 ELSIF SymEq(t.first, "quasiquote") THEN special := "`" 58 ELSIF SymEq(t.first, "unquote") THEN special := "," 59 ELSIF SymEq(t.first, "unquote-splicing") THEN special := ",@" 60 END 61 ELSE 62 Debug.Out("in ELSE clause...") 63 END; all you need to know is that Debug.Out prints out debugging information to the terminal. What I see is... t.rest = NIL? FALSE ISTYPE(t.rest,T)? TRUE Rest(t.rest) = NIL? TRUE in ELSE clause... What gives!? Note this behavior occurs on both the Mac and on FreeBSD4 with a compiler and runtime bootstrapped today from some previous CM3. My old CM3 compiler was timestamped... April 30, I believe, and the code behaved properly under that one. I believe I have also tried it both with and without compiler optimizations. I find it baffling that so much stuff (mentor!) can work if "AND" isn't working right. This is the only if statement in many, many source files that seems to be working wrong. Is it possible I'm missing something?? No I don't think so... here's a more explicit version: Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); Debug.Out("conjunction? " & Fmt.Bool( t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL )); IF t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL THEN ... output is: t.rest # NIL? TRUE ISTYPE(t.rest,T)? TRUE Rest(t.rest) = NIL? TRUE conjunction? FALSE in ELSE clause... TRUE AND TRUE AND TRUE is FALSE?? Note that: VAR q, w, e := TRUE; Debug.Out("conjunction? " & Fmt.Bool( q AND w AND e)); results in TRUE (as it should). Mika From jay.krell at cornell.edu Tue Jun 16 09:11:08 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 07:11:08 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: <200906160701.n5G71I8K061661@camembert.async.caltech.edu> References: <200906160701.n5G71I8K061661@camembert.async.caltech.edu> Message-ID: Kneejerk generic response: I don't know the operator precedence. Can you put in parens? Have you looked at the code? Can you mail us a small self contained repro? Can you test it on birch? (That way -- all your files are there and easily gotten/investigated by others.) Optimization enabled? Works without? I know, I shouldn't even ask this sort of thing without evidence. - Jay > To: m3devel at elegosoft.com > Date: Tue, 16 Jun 2009 00:01:18 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] Strange behavior in recent CM3-compiled code... > > > Hello everyone, > > I'm trying to update to the latest CM3 again, so that I can get my > Mac working, and push my project of migrating a largish codebase > from PM3 to CM3 a little further. > > I updated CM3 today from CVS, on both my Mac and on a FreeBSD system, > and ... my Scheme interpreter broke. Here's what the code looks like, > with annotations: > > 49 Debug.Out("t.rest = NIL? " & Fmt.Bool(t.rest=NIL)); > 50 Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); > 51 Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > 52 > 53 IF t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL THEN > 54 Debug.Out("in IF clause..."); > 55 > 56 IF SymEq(t.first, "quote") THEN special := "'" > 57 ELSIF SymEq(t.first, "quasiquote") THEN special := "`" > 58 ELSIF SymEq(t.first, "unquote") THEN special := "," > 59 ELSIF SymEq(t.first, "unquote-splicing") THEN special := ",@" > 60 END > 61 ELSE > 62 Debug.Out("in ELSE clause...") > 63 END; > > all you need to know is that Debug.Out prints out debugging information > to the terminal. What I see is... > > t.rest = NIL? FALSE > ISTYPE(t.rest,T)? TRUE > Rest(t.rest) = NIL? TRUE > in ELSE clause... > > What gives!? > > Note this behavior occurs on both the Mac and on FreeBSD4 with a > compiler and runtime bootstrapped today from some previous CM3. > My old CM3 compiler was timestamped... April 30, I believe, and the > code behaved properly under that one. > > I believe I have also tried it both with and without compiler > optimizations. > > I find it baffling that so much stuff (mentor!) can work if "AND" isn't > working right. This is the only if statement in many, many source files > that seems to be working wrong. > > Is it possible I'm missing something?? No I don't think so... here's a more > explicit version: > > Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); > Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > Debug.Out("conjunction? " & Fmt.Bool( > t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL )); > IF t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL THEN > ... > > output is: > > t.rest # NIL? TRUE > ISTYPE(t.rest,T)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > > TRUE AND TRUE AND TRUE is FALSE?? > > Note that: > > VAR q, w, e := TRUE; > > Debug.Out("conjunction? " & Fmt.Bool( > q AND w AND e)); > > results in TRUE (as it should). > > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Jun 16 09:50:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 16 Jun 2009 00:50:18 -0700 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." Message-ID: <200906160750.n5G7oIWN063277@camembert.async.caltech.edu> Operator precedence? This isn't C, you know! You can't do NIL AND x in Modula-3. Nevertheless, AND has lower precedence than anything else I'm using here. OR is the lowest. Green Book, section 2.6.2 (p. 49). But to allay your fears, I can report that adding parens around each of the terms doesn't change the behavior, either printing or the IF. My q, w, e was an attempt at isolating the problem but it didn't. I don't know what to start cutting back. I was hoping someone would see it and think "oops, I touched ... the other day and it must have broken this". And yes as I mentioned I tried both with and without optimization. Unfortunately x86 assembly is pretty much gibberish to me. It's part of a rather large software system... I'll see what I can do about getting it up on birch or making a smaller test case... Meanwhile I'll write the code at the end of this message. Mika Jay writes: >--_55f6c801-7d57-4602-a131-dda139b64dfd_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Kneejerk generic response: > >=20 > >I don't know the operator precedence. Can you put in parens? > >Have you looked at the code? > >Can you mail us a small self contained repro? > >Can you test it on birch? > > (That way -- all your files are there and easily gotten/investigated by o= >thers.) > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= >rt of thing without evidence. > >=20 > > - Jay >=20 >> To: m3devel at elegosoft.com >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... >>=20 >>=20 >> Hello everyone=2C >>=20 >> I'm trying to update to the latest CM3 again=2C so that I can get my >> Mac working=2C and push my project of migrating a largish codebase >> from PM3 to CM3 a little further. >>=20 >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C >> and ... my Scheme interpreter broke. Here's what the code looks like=2C >> with annotations: >>=20 >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B >> 52 >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN >> 54 Debug.Out("in IF clause...")=3B >> 55 >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" >> 60 END >> 61 ELSE >> 62 Debug.Out("in ELSE clause...") >> 63 END=3B >>=20 >> all you need to know is that Debug.Out prints out debugging information >> to the terminal. What I see is... >>=20 >> t.rest =3D NIL? FALSE >> ISTYPE(t.rest=2CT)? TRUE >> Rest(t.rest) =3D NIL? TRUE >> in ELSE clause... >>=20 >> What gives!? >>=20 >> Note this behavior occurs on both the Mac and on FreeBSD4 with a >> compiler and runtime bootstrapped today from some previous CM3. >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the >> code behaved properly under that one. >>=20 >> I believe I have also tried it both with and without compiler >> optimizations. >>=20 >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't >> working right. This is the only if statement in many=2C many source files >> that seems to be working wrong. >>=20 >> Is it possible I'm missing something?? No I don't think so... here's a mo= >re >> explicit version: >>=20 >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B >> Debug.Out("conjunction? " & Fmt.Bool( >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN >> ... >>=20 >> output is: >>=20 >> t.rest # NIL? TRUE >> ISTYPE(t.rest=2CT)? TRUE >> Rest(t.rest) =3D NIL? TRUE >> conjunction? FALSE >> in ELSE clause... >>=20 >> TRUE AND TRUE AND TRUE is FALSE?? >>=20 >> Note that:=20 >>=20 >> VAR q=2C w=2C e :=3D TRUE=3B >>=20 >> Debug.Out("conjunction? " & Fmt.Bool( >> q AND w AND e))=3B >>=20 >> results in TRUE (as it should). >>=20 >>=20 >> Mika >>=20 > (* $Id: SchemePair.m3,v 1.8 2009/03/29 07:27:13 mika Exp $ *) MODULE SchemePair; IMPORT Wx; IMPORT SchemeObject, SchemeUtils, SchemeSymbol; FROM Scheme IMPORT E; FROM SchemeUtils IMPORT Error, StringifyT; IMPORT RefSeq; IMPORT Debug, Fmt; PROCEDURE StringifyPair(t : T; quoted : BOOLEAN; buf : Wx.T; seen : RefSeq.T) RAISES { E } = CONST SymEq = SchemeSymbol.SymEq; StringifyB = SchemeUtils.StringifyB; Rest = SchemeUtils.Rest; Second = SchemeUtils.Second; VAR special : TEXT := NIL; BEGIN Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); Debug.Out("conjunction? " & Fmt.Bool( ( t.rest # NIL) AND (ISTYPE(t.rest,T)) AND (Rest(t.rest) = NIL) )); IF (t.rest # NIL) AND ISTYPE(t.rest,T) AND (Rest(t.rest) = NIL) THEN Debug.Out("in IF clause..."); IF SymEq(t.first, "quote") THEN special := "'" ELSIF SymEq(t.first, "quasiquote") THEN special := "`" ELSIF SymEq(t.first, "unquote") THEN special := "," ELSIF SymEq(t.first, "unquote-splicing") THEN special := ",@" END ELSE Debug.Out("in ELSE clause...") END; IF special # NIL THEN Wx.PutText(buf, special); StringifyB(Second(t), quoted, buf, seen) ELSE Wx.PutChar(buf, '('); StringifyB(t.first, quoted, buf, seen); VAR tail := t.rest; BEGIN WHILE tail # NIL AND ISTYPE(tail,T) DO Wx.PutChar(buf, ' '); StringifyB(NARROW(tail,T).first, quoted, buf, seen); tail := NARROW(tail,T).rest END; IF tail # NIL THEN Wx.PutText(buf, " . "); StringifyB(tail, quoted, buf, seen) END; Wx.PutChar(buf, ')') END END END StringifyPair; PROCEDURE Pair(x : SchemeObject.T) : T RAISES { E } = BEGIN IF ISTYPE(x,T) THEN RETURN x (* NIL is OK for Pair! *) ELSE RETURN Pair(Error("expected a pair, got: " & StringifyT(x))) END END Pair; BEGIN END SchemePair. ---------------------------------------------------------------------- .file "SchemePair.mc" .stabs "/big/home/mika/t-cm3/mscheme/FreeBSD4/",100,0,0,.Ltext0 .stabs "SchemePair.mc",100,0,0,.Ltext0 .text .Ltext0: .stabs "gcc2_compiled.",60,0,0,0 .stabs "procedures_have_extra_block.",60,0,0,0 .stabs "MP_CMGwxk_32_L1:T(0,1)=s0AAAAAA:(0,2)=r(0,2);-2147483648;2147483647;,0,32;DobPBR_t:(0,2),0,32;AicXUJ_quoted:(0,2),0,32;BYmXDz_buf:(0,2),0,32;AZx9O5_seen:(0,2),0,32;Scheme.E:(0,2),0,32;;",128,0,0,0 .stabs "MP_DkRnTw_32_L1:T(0,3)=s0DobPBR:(0,2),0,32;Af40ku_x:(0,2),0,32;Scheme.E:(0,2),0,32;;",128,0,0,0 .stabs "MX_BUgnwf_32:T(0,4)=s0DWIlZi:(0,2),0,32;;",128,0,0,0 .stabs "MX_CKMnXU_32:T(0,5)=s0Cgclyt:(0,2),0,32;;",128,0,0,0 .stabs "MX_BtKsLk_32:T(0,6)=s0C7ehAd:(0,2),0,32;;",128,0,0,0 .stabs "SchemePair__StringifyPair:F(0,7)=(0,7)",36,0,17,SchemePair__StringifyPair .stabs "M3_DobPBR_t:p(0,8)=*(0,7)",160,0,74,8 .stabs "M3_AicXUJ_quoted:p(0,9)=@s8;r(0,9);0;255;",160,0,74,12 .stabs "M3_BYmXDz_buf:p(0,8)",160,0,74,16 .stabs "M3_AZx9O5_seen:p(0,8)",160,0,74,20 .globl SchemePair__StringifyPair .type SchemePair__StringifyPair, @function SchemePair__StringifyPair: .stabd 46,0,0 .stabs "../src/SchemePair.m3",132,0,0,.Ltext1 .Ltext1: .stabn 68,0,17,.LM0-.LFBB1 .LM0: .LFBB1: pushl %ebp movl %esp, %ebp pushl %ebx subl $84, %esp .LBB2: .stabn 68,0,24,.LM1-.LFBB1 .LM1: movl $0, -40(%ebp) .stabn 68,0,27,.LM2-.LFBB1 .LM2: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -36(%ebp) movl -36(%ebp), %eax testl %eax, %eax je .L2 movl -36(%ebp), %eax andl $1, %eax testb %al, %al jne .L2 movl -36(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L2 movl -36(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L2: movl -36(%ebp), %eax testl %eax, %eax setne %al movzbl %al, %eax movl %eax, (%esp) call Fmt__Bool movl %eax, -32(%ebp) movl -32(%ebp), %eax movl $L_1+24, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -28(%ebp) movl -28(%ebp), %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,28,.LM3-.LFBB1 .LM3: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -28(%ebp) movl -28(%ebp), %eax testl %eax, %eax je .L3 movl -28(%ebp), %eax andl $1, %eax testb %al, %al jne .L3 movl -28(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L3 movl -28(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L3: movl $1, -24(%ebp) movl -28(%ebp), %eax testl %eax, %eax je .L4 movl -28(%ebp), %eax andl $1, %eax testb %al, %al jne .L5 movl -28(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L4 jmp .L6 .L5: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L4 .L6: movl $0, -24(%ebp) .L4: movl -24(%ebp), %eax movl %eax, (%esp) call Fmt__Bool movl %eax, -32(%ebp) movl -32(%ebp), %eax movl $L_1+52, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -36(%ebp) movl -36(%ebp), %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,29,.LM4-.LFBB1 .LM4: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -36(%ebp) movl -36(%ebp), %eax testl %eax, %eax je .L7 movl -36(%ebp), %eax andl $1, %eax testb %al, %al jne .L7 movl -36(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L7 movl -36(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L7: movl -36(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Rest movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax sete %al movzbl %al, %eax movl %eax, (%esp) call Fmt__Bool movl %eax, -28(%ebp) movl -28(%ebp), %eax movl $L_1+84, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -20(%ebp) movl -20(%ebp), %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,30,.LM5-.LFBB1 .LM5: movl $0, -24(%ebp) movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -20(%ebp) movl -20(%ebp), %eax testl %eax, %eax je .L8 movl -20(%ebp), %eax andl $1, %eax testb %al, %al jne .L8 movl -20(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L8 movl -20(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L8: movl -20(%ebp), %eax testl %eax, %eax je .L9 movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -28(%ebp) movl -28(%ebp), %eax testl %eax, %eax je .L10 movl -28(%ebp), %eax andl $1, %eax testb %al, %al jne .L10 movl -28(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L10 movl -28(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L10: movl -28(%ebp), %eax testl %eax, %eax je .L11 movl -28(%ebp), %eax andl $1, %eax testb %al, %al jne .L12 movl -28(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx jne .L9 .L12: movl MM_SchemePair+176, %eax cmpl $3, %eax jne .L9 .L11: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L13 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L13 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L13 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L13: movl -32(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Rest movl %eax, -36(%ebp) movl -36(%ebp), %eax testl %eax, %eax jne .L9 movl $1, -24(%ebp) .L9: movl -24(%ebp), %eax movl %eax, (%esp) call Fmt__Bool movl %eax, -16(%ebp) movl -16(%ebp), %eax movl $L_1+120, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -12(%ebp) movl -12(%ebp), %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,32,.LM6-.LFBB1 .LM6: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -12(%ebp) movl -12(%ebp), %eax testl %eax, %eax je .L14 movl -12(%ebp), %eax andl $1, %eax testb %al, %al jne .L14 movl -12(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L14 movl -12(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L14: movl -12(%ebp), %eax testl %eax, %eax je .L15 movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -16(%ebp) movl -16(%ebp), %eax testl %eax, %eax je .L16 movl -16(%ebp), %eax andl $1, %eax testb %al, %al jne .L16 movl -16(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L16 movl -16(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L16: movl -16(%ebp), %eax testl %eax, %eax je .L17 movl -16(%ebp), %eax andl $1, %eax testb %al, %al jne .L18 movl -16(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx jne .L15 .L18: movl MM_SchemePair+176, %eax cmpl $3, %eax jne .L15 .L17: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -36(%ebp) movl -36(%ebp), %eax testl %eax, %eax je .L19 movl -36(%ebp), %eax andl $1, %eax testb %al, %al jne .L19 movl -36(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L19 movl -36(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L19: movl -36(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Rest movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax jne .L15 .stabn 68,0,33,.LM7-.LFBB1 .LM7: movl $L_1+148, %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,35,.LM8-.LFBB1 .LM8: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L20 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L20 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L20 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L20: movl $L_1+176, %eax movl -32(%ebp), %edx movl %eax, 4(%esp) movl %edx, (%esp) call SchemeSymbol__SymEq movb %al, -5(%ebp) movzbl -5(%ebp), %eax xorl $1, %eax testb %al, %al jne .L21 movl $L_1+196, %eax movl %eax, -40(%ebp) jmp .L29 .L21: .stabn 68,0,36,.LM9-.LFBB1 .LM9: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L23 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L23 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L23 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L23: movl $L_1+212, %eax movl -32(%ebp), %edx movl %eax, 4(%esp) movl %edx, (%esp) call SchemeSymbol__SymEq movb %al, -5(%ebp) movzbl -5(%ebp), %eax xorl $1, %eax testb %al, %al jne .L24 movl $L_1+236, %eax movl %eax, -40(%ebp) jmp .L29 .L24: .stabn 68,0,37,.LM10-.LFBB1 .LM10: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L25 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L25 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L25 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L25: movl $L_1+252, %eax movl -32(%ebp), %edx movl %eax, 4(%esp) movl %edx, (%esp) call SchemeSymbol__SymEq movb %al, -5(%ebp) movzbl -5(%ebp), %eax xorl $1, %eax testb %al, %al jne .L26 movl $L_1+272, %eax movl %eax, -40(%ebp) jmp .L29 .L26: .stabn 68,0,38,.LM11-.LFBB1 .LM11: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L27 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L27 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L27 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L27: movl $L_1+288, %eax movl -32(%ebp), %edx movl %eax, 4(%esp) movl %edx, (%esp) call SchemeSymbol__SymEq movb %al, -5(%ebp) movzbl -5(%ebp), %eax xorl $1, %eax testb %al, %al jne .L29 movl $L_1+320, %eax movl %eax, -40(%ebp) jmp .L29 .L15: .stabn 68,0,41,.LM12-.LFBB1 .LM12: movl $L_1+336, %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .L29: .stabn 68,0,45,.LM13-.LFBB1 .LM13: movl -40(%ebp), %eax testl %eax, %eax je .L30 .stabn 68,0,46,.LM14-.LFBB1 .LM14: movl -40(%ebp), %eax movl 16(%ebp), %edx movl $0, 20(%esp) movl $0, 16(%esp) movl $0, 12(%esp) movl $0, 8(%esp) movl %eax, 4(%esp) movl %edx, (%esp) call Wx__PutText .stabn 68,0,47,.LM15-.LFBB1 .LM15: movl 8(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Second movl %eax, -32(%ebp) movl 20(%ebp), %edx movl 16(%ebp), %ecx movzbl 12(%ebp), %eax movzbl %al, %eax movl -32(%ebp), %ebx movl %edx, 12(%esp) movl %ecx, 8(%esp) movl %eax, 4(%esp) movl %ebx, (%esp) call SchemeUtils__StringifyB jmp .L47 .L30: .stabn 68,0,49,.LM16-.LFBB1 .LM16: movl 16(%ebp), %eax movl $40, 4(%esp) movl %eax, (%esp) call Wx__PutChar .stabn 68,0,50,.LM17-.LFBB1 .LM17: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L32 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L32 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L32 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L32: movl 20(%ebp), %edx movl 16(%ebp), %ecx movzbl 12(%ebp), %eax movzbl %al, %eax movl -32(%ebp), %ebx movl %edx, 12(%esp) movl %ecx, 8(%esp) movl %eax, 4(%esp) movl %ebx, (%esp) call SchemeUtils__StringifyB .LBB3: .stabn 68,0,51,.LM18-.LFBB1 .LM18: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L33 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L33 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L33 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L33: movl -32(%ebp), %eax movl %eax, -44(%ebp) jmp .L34 .L35: .stabn 68,0,54,.LM19-.LFBB1 .LM19: movl 16(%ebp), %eax movl $32, 4(%esp) movl %eax, (%esp) call Wx__PutChar .stabn 68,0,55,.LM20-.LFBB1 .LM20: movl -44(%ebp), %eax testl %eax, %eax je .L36 movl -44(%ebp), %eax andl $1, %eax testb %al, %al jne .L37 movl -44(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L36 movl $1765, (%esp) call _m3_fault .L37: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L36 movl $1765, (%esp) call _m3_fault .L36: movl -44(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L38 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L38 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L38 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L38: movl 20(%ebp), %edx movl 16(%ebp), %ecx movzbl 12(%ebp), %eax movzbl %al, %eax movl -32(%ebp), %ebx movl %edx, 12(%esp) movl %ecx, 8(%esp) movl %eax, 4(%esp) movl %ebx, (%esp) call SchemeUtils__StringifyB .stabn 68,0,56,.LM21-.LFBB1 .LM21: movl -44(%ebp), %eax testl %eax, %eax je .L39 movl -44(%ebp), %eax andl $1, %eax testb %al, %al jne .L40 movl -44(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L39 movl $1797, (%esp) call _m3_fault .L40: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L39 movl $1797, (%esp) call _m3_fault .L39: movl -44(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L41 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L41 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L41 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L41: movl -32(%ebp), %eax movl %eax, -44(%ebp) .L34: .stabn 68,0,53,.LM22-.LFBB1 .LM22: movl -44(%ebp), %eax testl %eax, %eax je .L45 movl -44(%ebp), %eax testl %eax, %eax je .L35 movl -44(%ebp), %eax andl $1, %eax testb %al, %al jne .L43 movl -44(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L35 .L43: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L35 .L45: .stabn 68,0,58,.LM23-.LFBB1 .LM23: movl -44(%ebp), %eax testl %eax, %eax je .L46 .stabn 68,0,59,.LM24-.LFBB1 .LM24: movl $L_1+368, %eax movl 16(%ebp), %edx movl $0, 20(%esp) movl $0, 16(%esp) movl $0, 12(%esp) movl $0, 8(%esp) movl %eax, 4(%esp) movl %edx, (%esp) call Wx__PutText .stabn 68,0,60,.LM25-.LFBB1 .LM25: movl 20(%ebp), %edx movl 16(%ebp), %ecx movzbl 12(%ebp), %eax movzbl %al, %eax movl -44(%ebp), %ebx movl %edx, 12(%esp) movl %ecx, 8(%esp) movl %eax, 4(%esp) movl %ebx, (%esp) call SchemeUtils__StringifyB .L46: .stabn 68,0,62,.LM26-.LFBB1 .LM26: movl 16(%ebp), %eax movl $41, 4(%esp) movl %eax, (%esp) call Wx__PutChar .L47: .LBE3: .LBE2: .stabn 68,0,65,.LM27-.LFBB1 .LM27: addl $84, %esp popl %ebx popl %ebp ret .size SchemePair__StringifyPair, .-SchemePair__StringifyPair .stabn 192,0,0,.LFBB1-.LFBB1 .stabs "M3_Bd56fi_special:(0,8)",128,0,74,-40 .stabn 192,0,0,.LBB2-.LFBB1 .stabs "M3_Af40ku_tail:(0,8)",128,0,51,-44 .stabn 192,0,0,.LBB3-.LFBB1 .stabn 224,0,0,.LBE3-.LFBB1 .stabn 224,0,0,.LBE2-.LFBB1 .stabn 224,0,0,.Lscope1-.LFBB1 .Lscope1: .stabs "",36,0,0,.Lscope1-.LFBB1 .stabd 78,0,0 .stabs "SchemePair__Pair:F(0,8)",36,0,67,SchemePair__Pair .stabs "M3_Af40ku_x:p(0,8)",160,0,74,8 .globl SchemePair__Pair .type SchemePair__Pair, @function SchemePair__Pair: .stabd 46,0,0 .stabn 68,0,67,.LM28-.LFBB2 .LM28: .LFBB2: pushl %ebp movl %esp, %ebp subl $56, %esp .LBB4: .stabn 68,0,69,.LM29-.LFBB2 .LM29: movl 8(%ebp), %eax testl %eax, %eax je .L49 movl 8(%ebp), %eax andl $1, %eax testb %al, %al jne .L50 movl 8(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx jne .L51 .L50: movl MM_SchemePair+176, %eax cmpl $3, %eax jne .L51 .L49: movl 8(%ebp), %eax testl %eax, %eax je .L52 movl 8(%ebp), %eax andl $1, %eax testb %al, %al jne .L53 movl 8(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L52 movl $2213, (%esp) call _m3_fault .L53: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L52 movl $2213, (%esp) call _m3_fault .L52: movl 8(%ebp), %eax movl %eax, -36(%ebp) jmp .L48 .L51: .stabn 68,0,70,.LM30-.LFBB2 .LM30: movl 8(%ebp), %eax movl %eax, (%esp) call SchemeUtils__StringifyT movl %eax, -20(%ebp) movl -20(%ebp), %eax movl $L_1+384, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -16(%ebp) movl -16(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Error movl %eax, -12(%ebp) movl -12(%ebp), %eax movl %eax, (%esp) call SchemePair__Pair movl %eax, -8(%ebp) movl -8(%ebp), %eax movl %eax, -36(%ebp) .L48: .LBE4: movl -36(%ebp), %eax leave ret .size SchemePair__Pair, .-SchemePair__Pair .stabn 192,0,0,.LFBB2-.LFBB2 .stabs "M3_DobPBR__result:(0,8)",128,0,74,-4 .stabn 192,0,0,.LBB4-.LFBB2 .stabn 224,0,0,.LBE4-.LFBB2 .stabn 224,0,0,.Lscope2-.LFBB2 .Lscope2: .stabs "",36,0,0,.Lscope2-.LFBB2 .stabd 78,0,0 .stabs "SchemePair_M3:F(0,8)",36,0,74,SchemePair_M3 .stabs "M3_AcxOUs_mode:p(0,2)",160,0,74,8 .globl SchemePair_M3 .type SchemePair_M3, @function SchemePair_M3: .stabd 46,0,0 .stabn 68,0,74,.LM31-.LFBB3 .LM31: .LFBB3: pushl %ebp movl %esp, %ebp subl $4, %esp .LBB5: .stabn 68,0,74,.LM32-.LFBB3 .LM32: movl 8(%ebp), %eax movl $MM_SchemePair, %eax .LBE5: leave ret .size SchemePair_M3, .-SchemePair_M3 .stabn 192,0,0,.LFBB3-.LFBB3 .stabn 192,0,0,.LBB5-.LFBB3 .stabn 224,0,0,.LBE5-.LFBB3 .stabn 224,0,0,.Lscope3-.LFBB3 .Lscope3: .stabs "",36,0,0,.Lscope3-.LFBB3 .stabd 78,0,0 .stabs "MR_zzzzzz_4032:T(0,10)=s0;",128,0,0,0 .stabs "MR_zzzzzz_1440:T(0,11)=s0;",128,0,0,0 .stabs "Mi_zzzzzz_SchemePair:T(0,12)=s0SchemePair:(0,2),0,32;;",128,0,0,0 .stabs "_m3_fault:f(0,7)",36,0,0,_m3_fault .stabs "M3_AcxOUs_arg:p(0,13)=r(0,13);0;037777777777;",160,0,55,8 .type _m3_fault, @function _m3_fault: .stabd 46,0,0 .stabn 68,0,0,.LM33-.LFBB4 .LM33: .LFBB4: pushl %ebp movl %esp, %ebp subl $8, %esp movl 8(%ebp), %eax movl %eax, 4(%esp) movl $MM_SchemePair, (%esp) call RTHooks__ReportFault leave ret .size _m3_fault, .-_m3_fault .stabn 192,0,0,.LFBB4-.LFBB4 .stabn 224,0,0,.Lscope4-.LFBB4 .Lscope4: .stabs "",36,0,0,.Lscope4-.LFBB4 .stabd 78,0,0 .data .align 32 .type L_1, @object .size L_1, 504 L_1: .long RTHooks__TextLitInfo .long RTHooks__TextLitGetChar .long RTHooks__TextLitGetWideChar .long RTHooks__TextLitGetChars .long RTHooks__TextLitGetWideChars .long 2 .long L_1 .long 14 .ascii "t.rest # NIL? " .zero 2 .long 2 .long L_1 .long 18 .ascii "ISTYPE(t.rest,T)? " .zero 2 .long 2 .long L_1 .long 20 .ascii "Rest(t.rest) = NIL? " .zero 4 .long 2 .long L_1 .long 13 .ascii "conjunction? " .zero 3 .long 2 .long L_1 .long 15 .ascii "in IF clause..." .zero 1 .long 2 .long L_1 .long 5 .ascii "quote" .zero 3 .long 2 .long L_1 .long 1 .ascii "'" .zero 3 .long 2 .long L_1 .long 10 .ascii "quasiquote" .zero 2 .long 2 .long L_1 .long 1 .ascii "`" .zero 3 .long 2 .long L_1 .long 7 .ascii "unquote" .zero 1 .long 2 .long L_1 .long 1 .ascii "," .zero 3 .long 2 .long L_1 .long 16 .ascii "unquote-splicing" .zero 4 .long 2 .long L_1 .long 2 .ascii ",@" .zero 2 .long 2 .long L_1 .long 17 .ascii "in ELSE clause..." .zero 3 .long 2 .long L_1 .long 3 .ascii " . " .zero 1 .long 2 .long L_1 .long 22 .ascii "expected a pair, got: " .zero 2 .ascii "SchemePair_M3" .zero 1 .ascii "Pair" .zero 1 .ascii "StringifyPair" .zero 4 .long SchemePair_M3 .long L_1+416 .long SchemePair__Pair .long L_1+430 .long SchemePair__StringifyPair .long L_1+435 .zero 4 .ascii "../src/SchemePair.m3" .zero 4 .align 32 .type MM_SchemePair, @object .size MM_SchemePair, 180 MM_SchemePair: .long L_1+480 .zero 4 .long MM_SchemePair+172 .zero 8 .long L_1+452 .zero 12 .long MM_SchemePair+52 .zero 4 .long SchemePair_M3 .long 3 .zero 4 .long SchemePair_I3 .long MM_SchemePair+64 .zero 4 .long Fmt_I3 .long MM_SchemePair+76 .zero 4 .long Debug_I3 .long MM_SchemePair+88 .zero 4 .long RefSeq_I3 .long MM_SchemePair+100 .zero 4 .long Scheme_I3 .long MM_SchemePair+112 .zero 4 .long SchemeSymbol_I3 .long MM_SchemePair+124 .zero 4 .long SchemeUtils_I3 .long MM_SchemePair+136 .zero 4 .long SchemeObject_I3 .long MM_SchemePair+148 .zero 4 .long Wx_I3 .long MM_SchemePair+160 .zero 4 .long RTHooks_I3 .zero 8 .long -949022765 .stabs "L_1:S(0,14)=s504;",38,0,9,L_1 .stabs "MM_SchemePair:S(0,15)=s180;",38,0,9,MM_SchemePair .text .stabs "",100,0,0,.Letext0 .Letext0: .ident "GCC: (GNU) 4.3.0" From mika at async.caltech.edu Tue Jun 16 09:59:10 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 16 Jun 2009 00:59:10 -0700 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." Message-ID: <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> This small example exhibits it! MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = BRANDED "Pair" REF RECORD first, rest : REFANY; END; PROCEDURE Rest(p : Pair) : REFANY = BEGIN IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END END Rest; VAR t := NEW(Pair, first := "first", rest := NEW(Pair, first := "second", rest := NIL)); BEGIN PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); PutLn("conjunction? " & Fmt.Bool( (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Output: (133)rover:~/testcm3/src>m3build -O --- building in ../FreeBSD4 --- m3build: missing ../src/m3overrides new source -> compiling ../src/Main.m3 -> linking prog (134)rover:~/testcm3/src>../FreeBSD4/prog t.rest # NIL? TRUE ISTYPE(t.rest,Pair)? TRUE Rest(t.rest) = NIL? TRUE conjunction? TRUE in IF clause... (135)rover:~/testcm3/src>cm3 -clean --- cleaning ../FreeBSD4 --- (136)rover:~/testcm3/src>cm3 --- building in ../FreeBSD4 --- new source -> compiling Main.m3 -> linking prog (137)rover:~/testcm3/src>../FreeBSD4/prog t.rest # NIL? TRUE ISTYPE(t.rest,Pair)? TRUE Rest(t.rest) = NIL? TRUE conjunction? FALSE in ELSE clause... (138)rover:~/testcm3/src> Jay writes: >--_55f6c801-7d57-4602-a131-dda139b64dfd_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Kneejerk generic response: > >=20 > >I don't know the operator precedence. Can you put in parens? > >Have you looked at the code? > >Can you mail us a small self contained repro? > >Can you test it on birch? > > (That way -- all your files are there and easily gotten/investigated by o= >thers.) > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= >rt of thing without evidence. > >=20 > > - Jay >=20 >> To: m3devel at elegosoft.com >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... >>=20 >>=20 >> Hello everyone=2C >>=20 >> I'm trying to update to the latest CM3 again=2C so that I can get my >> Mac working=2C and push my project of migrating a largish codebase >> from PM3 to CM3 a little further. >>=20 >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C >> and ... my Scheme interpreter broke. Here's what the code looks like=2C >> with annotations: >>=20 >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B >> 52 >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN >> 54 Debug.Out("in IF clause...")=3B >> 55 >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" >> 60 END >> 61 ELSE >> 62 Debug.Out("in ELSE clause...") >> 63 END=3B >>=20 >> all you need to know is that Debug.Out prints out debugging information >> to the terminal. What I see is... >>=20 >> t.rest =3D NIL? FALSE >> ISTYPE(t.rest=2CT)? TRUE >> Rest(t.rest) =3D NIL? TRUE >> in ELSE clause... >>=20 >> What gives!? >>=20 >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > compiler and runtime bootstrapped today from some previous CM3. >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the >> code behaved properly under that one. >>=20 >> I believe I have also tried it both with and without compiler >> optimizations. >>=20 >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't >> working right. This is the only if statement in many=2C many source files >> that seems to be working wrong. >>=20 >> Is it possible I'm missing something?? No I don't think so... here's a mo= >re >> explicit version: >>=20 >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B >> Debug.Out("conjunction? " & Fmt.Bool( >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN >> ... >>=20 >> output is: >>=20 >> t.rest # NIL? TRUE >> ISTYPE(t.rest=2CT)? TRUE >> Rest(t.rest) =3D NIL? TRUE >> conjunction? FALSE >> in ELSE clause... >>=20 >> TRUE AND TRUE AND TRUE is FALSE?? >>=20 >> Note that:=20 >>=20 >> VAR q=2C w=2C e :=3D TRUE=3B >>=20 >> Debug.Out("conjunction? " & Fmt.Bool( >> q AND w AND e))=3B >>=20 >> results in TRUE (as it should). >>=20 >>=20 >> Mika >>=20 > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Kneejerk generic response:
> =3B
>I don't know the operator precedence. Can you put in parens?
>Have you looked at the code?
>Can you mail us a small self contained repro?
>Can you test it on birch?
> =3B (That way -- all your files are there and easily gotten/investigat= >ed by others.)
>Optimization enabled? Works without? I know=2C I shouldn't even ask this so= >rt of thing without evidence.
> =3B
> =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= >eed to know is that Debug.Out prints out debugging information
>=3B to= > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= >ieve I have also tried it both with and without compiler
>=3B optimiza= >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > can work if "AND" isn't
>=3B working right. This is the only if state= >ment in many=2C many source files
>=3B that seems to be working wrong.= >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= >ka
>=3B
>= > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- From jay.krell at cornell.edu Tue Jun 16 10:44:21 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 08:44:21 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: Cool. Here is a smaller repro, on birch AMD64_LINUX. The problem is not the AND, the problem is the IF. MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = REF RECORD rest : REFANY; END; VAR t := NEW(Pair, rest := NEW(Pair, rest := NIL)); BEGIN PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); IF ISTYPE(t.rest,Pair) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Tony this is presumably your type tagging changes?? The problem in the code I think is the compare to the number 3. .L13: movq 312+MM_Main(%rip), %rax cmpq $3, %rax <==== jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT What is that for? It comes right from the IL: (118) set_source_line source line 17 (119) import_procedure procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd (120) declare_param param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 alignment 0x40 in _memory 0x0 up_level 0x0 mode 0x11 (DImode) (121) set_runtime_proc (122) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (123) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (124) load_nil (125) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (126) if_eq (127) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (128) loophole (129) load_integer integer 0x1 (130) and (131) if_true (132) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (133) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (134) extract_mn (135) if_false (136) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (137) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (138) pop_param pop param type 0xb (139) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (140) set_label (141) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (142) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (143) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (144) load_nil (145) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (146) if_eq (147) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (148) loophole (149) load_integer integer 0x1 (150) and (151) if_true (152) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (153) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (154) extract_mn (155) if_false (156) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (157) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (158) pop_param pop param type 0xb (159) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (160) set_label (161) load_integer integer 0x1 (162) declare_temp temp var type 0x7 size 0x40 alignment 0x40 (163) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (164) load_nil (165) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (166) if_eq (167) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (168) loophole (169) load_integer integer 0x1 (170) and (171) if_true (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq (177) jump (178) set_label (179) load_integer integer 0x3 (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq (182) set_label (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 alignment 0x8 in_mem ory 0x0 up_level 0x0 mode 0xe () (188) start_call_direct start call procedure Fmt__Bool, level 0x0, type 0xb (189) load m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 (190) pop_param pop param type 0x0 (191) call_direct call procedure Fmt__Bool, type 0xb (192) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (193) start_call_direct start call procedure RTHooks__Concat, level 0x0, type 0xb (194) load_address load address (L_1) offset 0x280 (195) pop_param pop param type 0xb (196) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (197) pop_param pop param type 0xb (198) call_direct call procedure RTHooks__Concat, type 0xb (199) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (200) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (201) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (202) pop_param pop param type 0xb (203) call_direct call procedure Main__PutLn, type 0xd (204) set_source_line source line 18 (205) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (206) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (207) load_nil (208) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (209) if_eq (210) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (211) loophole (212) load_integer integer 0x1 (213) and (214) if_true (215) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (216) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (217) extract_mn (218) if_false (219) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (220) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (221) pop_param pop param type 0xb (222) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (223) set_label (224) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (225) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (226) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (227) load_nil (228) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (229) if_eq (230) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (231) loophole (232) load_integer integer 0x1 (233) and (234) if_true (235) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (236) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (237) extract_mn (238) if_false (239) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (240) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (241) pop_param pop param type 0xb (242) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (243) set_label (244) load_nil (245) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (246) if_eq (247) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (248) loophole (249) load_integer integer 0x1 (250) and (251) if_true (252) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (253) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (254) extract_mn (255) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (256) if_ne (257) set_label (258) load_integer integer 0x3 <===== (259) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (260) if_ne (261) set_label (262) set_source_line source line 19 (263) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (264) load_address load address (L_1) offset 0x400 (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump (268) set_label (269) set_source_line source line 21 (270) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (271) load_address load address (L_1) offset 0x540 (272) pop_param pop param type 0xb (273) call_direct call procedure Main__PutLn, type 0xd (274) set_label (275) set_label (276) load_address load address (MM_Main) offset 0x0 (277) exit_proc (278) free_temp (279) free_temp (280) free_temp (281) free_temp (282) free_temp (283) end_procedure procedure Main_M3 (284) comment comment: `global constant type descriptor' (285) declare_record record id 0xffffffff, fields 0x0, size 0x940 (286) comment comment: `global data type descriptor' I'll dig a bit more. - Jay > To: jay.krell at cornell.edu > Date: Tue, 16 Jun 2009 00:59:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > This small example exhibits it! > > MODULE Main; > IMPORT IO, Fmt; > > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > > TYPE > Pair = BRANDED "Pair" REF RECORD > first, rest : REFANY; > END; > > PROCEDURE Rest(p : Pair) : REFANY = > BEGIN > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > END Rest; > > VAR > t := NEW(Pair, first := "first", > rest := NEW(Pair, first := "second", > rest := NIL)); > > BEGIN > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > PutLn("conjunction? " & Fmt.Bool( > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Output: > > (133)rover:~/testcm3/src>m3build -O > --- building in ../FreeBSD4 --- > m3build: missing ../src/m3overrides > new source -> compiling ../src/Main.m3 > -> linking prog > (134)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? TRUE > in IF clause... > (135)rover:~/testcm3/src>cm3 -clean > --- cleaning ../FreeBSD4 --- > > (136)rover:~/testcm3/src>cm3 > --- building in ../FreeBSD4 --- > > new source -> compiling Main.m3 > -> linking prog > (137)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > (138)rover:~/testcm3/src> > > Jay writes: > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Kneejerk generic response: > > > >=20 > > > >I don't know the operator precedence. Can you put in parens? > > > >Have you looked at the code? > > > >Can you mail us a small self contained repro? > > > >Can you test it on birch? > > > > (That way -- all your files are there and easily gotten/investigated by o= > >thers.) > > > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence. > > > >=20 > > > > - Jay > >=20 > >> To: m3devel at elegosoft.com > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... > >>=20 > >>=20 > >> Hello everyone=2C > >>=20 > >> I'm trying to update to the latest CM3 again=2C so that I can get my > >> Mac working=2C and push my project of migrating a largish codebase > >> from PM3 to CM3 a little further. > >>=20 > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C > >> and ... my Scheme interpreter broke. Here's what the code looks like=2C > >> with annotations: > >>=20 > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> 52 > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> 54 Debug.Out("in IF clause...")=3B > >> 55 > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" > >> 60 END > >> 61 ELSE > >> 62 Debug.Out("in ELSE clause...") > >> 63 END=3B > >>=20 > >> all you need to know is that Debug.Out prints out debugging information > >> to the terminal. What I see is... > >>=20 > >> t.rest =3D NIL? FALSE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> in ELSE clause... > >>=20 > >> What gives!? > >>=20 > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > compiler and runtime bootstrapped today from some previous CM3. > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the > >> code behaved properly under that one. > >>=20 > >> I believe I have also tried it both with and without compiler > >> optimizations. > >>=20 > >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't > >> working right. This is the only if statement in many=2C many source files > >> that seems to be working wrong. > >>=20 > >> Is it possible I'm missing something?? No I don't think so... here's a mo= > >re > >> explicit version: > >>=20 > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> Debug.Out("conjunction? " & Fmt.Bool( > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> ... > >>=20 > >> output is: > >>=20 > >> t.rest # NIL? TRUE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> conjunction? FALSE > >> in ELSE clause... > >>=20 > >> TRUE AND TRUE AND TRUE is FALSE?? > >>=20 > >> Note that:=20 > >>=20 > >> VAR q=2C w=2C e :=3D TRUE=3B > >>=20 > >> Debug.Out("conjunction? " & Fmt.Bool( > >> q AND w AND e))=3B > >>=20 > >> results in TRUE (as it should). > >>=20 > >>=20 > >> Mika > >>=20 > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Kneejerk generic response:
> > =3B
> >I don't know the operator precedence. Can you put in parens?
> >Have you looked at the code?
> >Can you mail us a small self contained repro?
> >Can you test it on birch?
> > =3B (That way -- all your files are there and easily gotten/investigat= > >ed by others.)
> >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence.
> > =3B
> > =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= > >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= > >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= > >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= > >eed to know is that Debug.Out prints out debugging information
>=3B to= > > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= > >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= > >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= > >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= > >ieve I have also tried it both with and without compiler
>=3B optimiza= > >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > > can work if "AND" isn't
>=3B working right. This is the only if state= > >ment in many=2C many source files
>=3B that seems to be working wrong.= > >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= > >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= > >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= > >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B >R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= > >ka
>=3B
> >= > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jun 16 10:50:02 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 08:50:02 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: Well, the number 3 is REFANY_typecode. I need to compare the if code to the printing code though.. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... Date: Tue, 16 Jun 2009 08:44:21 +0000 Cool. Here is a smaller repro, on birch AMD64_LINUX. The problem is not the AND, the problem is the IF. MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = REF RECORD rest : REFANY; END; VAR t := NEW(Pair, rest := NEW(Pair, rest := NIL)); BEGIN PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); IF ISTYPE(t.rest,Pair) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Tony this is presumably your type tagging changes?? The problem in the code I think is the compare to the number 3. .L13: movq 312+MM_Main(%rip), %rax cmpq $3, %rax <==== jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT What is that for? It comes right from the IL: (118) set_source_line source line 17 (119) import_procedure procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd (120) declare_param param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 alignment 0x40 in _memory 0x0 up_level 0x0 mode 0x11 (DImode) (121) set_runtime_proc (122) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (123) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (124) load_nil (125) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (126) if_eq (127) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (128) loophole (129) load_integer integer 0x1 (130) and (131) if_true (132) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (133) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (134) extract_mn (135) if_false (136) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (137) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (138) pop_param pop param type 0xb (139) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (140) set_label (141) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (142) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (143) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (144) load_nil (145) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (146) if_eq (147) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (148) loophole (149) load_integer integer 0x1 (150) and (151) if_true (152) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (153) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (154) extract_mn (155) if_false (156) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (157) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (158) pop_param pop param type 0xb (159) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (160) set_label (161) load_integer integer 0x1 (162) declare_temp temp var type 0x7 size 0x40 alignment 0x40 (163) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (164) load_nil (165) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (166) if_eq (167) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (168) loophole (169) load_integer integer 0x1 (170) and (171) if_true (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq (177) jump (178) set_label (179) load_integer integer 0x3 (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq (182) set_label (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 alignment 0x8 in_mem ory 0x0 up_level 0x0 mode 0xe () (188) start_call_direct start call procedure Fmt__Bool, level 0x0, type 0xb (189) load m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 (190) pop_param pop param type 0x0 (191) call_direct call procedure Fmt__Bool, type 0xb (192) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (193) start_call_direct start call procedure RTHooks__Concat, level 0x0, type 0xb (194) load_address load address (L_1) offset 0x280 (195) pop_param pop param type 0xb (196) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (197) pop_param pop param type 0xb (198) call_direct call procedure RTHooks__Concat, type 0xb (199) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (200) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (201) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (202) pop_param pop param type 0xb (203) call_direct call procedure Main__PutLn, type 0xd (204) set_source_line source line 18 (205) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (206) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (207) load_nil (208) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (209) if_eq (210) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (211) loophole (212) load_integer integer 0x1 (213) and (214) if_true (215) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (216) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (217) extract_mn (218) if_false (219) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (220) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (221) pop_param pop param type 0xb (222) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (223) set_label (224) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (225) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (226) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (227) load_nil (228) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (229) if_eq (230) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (231) loophole (232) load_integer integer 0x1 (233) and (234) if_true (235) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (236) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (237) extract_mn (238) if_false (239) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (240) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (241) pop_param pop param type 0xb (242) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (243) set_label (244) load_nil (245) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (246) if_eq (247) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (248) loophole (249) load_integer integer 0x1 (250) and (251) if_true (252) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (253) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (254) extract_mn (255) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (256) if_ne (257) set_label (258) load_integer integer 0x3 <===== (259) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (260) if_ne (261) set_label (262) set_source_line source line 19 (263) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (264) load_address load address (L_1) offset 0x400 (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump (268) set_label (269) set_source_line source line 21 (270) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (271) load_address load address (L_1) offset 0x540 (272) pop_param pop param type 0xb (273) call_direct call procedure Main__PutLn, type 0xd (274) set_label (275) set_label (276) load_address load address (MM_Main) offset 0x0 (277) exit_proc (278) free_temp (279) free_temp (280) free_temp (281) free_temp (282) free_temp (283) end_procedure procedure Main_M3 (284) comment comment: `global constant type descriptor' (285) declare_record record id 0xffffffff, fields 0x0, size 0x940 (286) comment comment: `global data type descriptor' I'll dig a bit more. - Jay > To: jay.krell at cornell.edu > Date: Tue, 16 Jun 2009 00:59:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > This small example exhibits it! > > MODULE Main; > IMPORT IO, Fmt; > > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > > TYPE > Pair = BRANDED "Pair" REF RECORD > first, rest : REFANY; > END; > > PROCEDURE Rest(p : Pair) : REFANY = > BEGIN > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > END Rest; > > VAR > t := NEW(Pair, first := "first", > rest := NEW(Pair, first := "second", > rest := NIL)); > > BEGIN > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > PutLn("conjunction? " & Fmt.Bool( > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Output: > > (133)rover:~/testcm3/src>m3build -O > --- building in ../FreeBSD4 --- > m3build: missing ../src/m3overrides > new source -> compiling ../src/Main.m3 > -> linking prog > (134)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? TRUE > in IF clause... > (135)rover:~/testcm3/src>cm3 -clean > --- cleaning ../FreeBSD4 --- > > (136)rover:~/testcm3/src>cm3 > --- building in ../FreeBSD4 --- > > new source -> compiling Main.m3 > -> linking prog > (137)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > (138)rover:~/testcm3/src> > > Jay writes: > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Kneejerk generic response: > > > >=20 > > > >I don't know the operator precedence. Can you put in parens? > > > >Have you looked at the code? > > > >Can you mail us a small self contained repro? > > > >Can you test it on birch? > > > > (That way -- all your files are there and easily gotten/investigated by o= > >thers.) > > > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence. > > > >=20 > > > > - Jay > >=20 > >> To: m3devel at elegosoft.com > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... > >>=20 > >>=20 > >> Hello everyone=2C > >>=20 > >> I'm trying to update to the latest CM3 again=2C so that I can get my > >> Mac working=2C and push my project of migrating a largish codebase > >> from PM3 to CM3 a little further. > >>=20 > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C > >> and ... my Scheme interpreter broke. Here's what the code looks like=2C > >> with annotations: > >>=20 > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> 52 > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> 54 Debug.Out("in IF clause...")=3B > >> 55 > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" > >> 60 END > >> 61 ELSE > >> 62 Debug.Out("in ELSE clause...") > >> 63 END=3B > >>=20 > >> all you need to know is that Debug.Out prints out debugging information > >> to the terminal. What I see is... > >>=20 > >> t.rest =3D NIL? FALSE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> in ELSE clause... > >>=20 > >> What gives!? > >>=20 > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > compiler and runtime bootstrapped today from some previous CM3. > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the > >> code behaved properly under that one. > >>=20 > >> I believe I have also tried it both with and without compiler > >> optimizations. > >>=20 > >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't > >> working right. This is the only if statement in many=2C many source files > >> that seems to be working wrong. > >>=20 > >> Is it possible I'm missing something?? No I don't think so... here's a mo= > >re > >> explicit version: > >>=20 > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> Debug.Out("conjunction? " & Fmt.Bool( > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> ... > >>=20 > >> output is: > >>=20 > >> t.rest # NIL? TRUE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> conjunction? FALSE > >> in ELSE clause... > >>=20 > >> TRUE AND TRUE AND TRUE is FALSE?? > >>=20 > >> Note that:=20 > >>=20 > >> VAR q=2C w=2C e :=3D TRUE=3B > >>=20 > >> Debug.Out("conjunction? " & Fmt.Bool( > >> q AND w AND e))=3B > >>=20 > >> results in TRUE (as it should). > >>=20 > >>=20 > >> Mika > >>=20 > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Kneejerk generic response:
> > =3B
> >I don't know the operator precedence. Can you put in parens?
> >Have you looked at the code?
> >Can you mail us a small self contained repro?
> >Can you test it on birch?
> > =3B (That way -- all your files are there and easily gotten/investigat= > >ed by others.)
> >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence.
> > =3B
> > =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= > >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= > >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= > >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= > >eed to know is that Debug.Out prints out debugging information
>=3B to= > > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= > >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= > >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= > >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= > >ieve I have also tried it both with and without compiler
>=3B optimiza= > >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > > can work if "AND" isn't
>=3B working right. This is the only if state= > >ment in many=2C many source files
>=3B that seems to be working wrong.= > >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= > >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= > >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= > >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B >R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= > >ka
>=3B
> >= > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jun 16 11:16:39 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 09:16:39 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: I haven't figured it out, but: Here is the code for the Fmt.Bool: .L6: ; assume the parameter to Fmt.Bool is TRUE, by ; storing 1 in the parameter place movq $1, 16(%rsp) ; do a bunch of stuff, no need to understand.. movq 32(%rsp), %rax testq %rax, %rax je .L7 movq 32(%rsp), %rax testb $1, %al jne .L8 movq 32(%rsp), %rax movq 312+MM_Main(%rip), %rdx movq -8(%rax), %rax salq $43, %rax shrq $44, %rax ; at this point, between $rdx and $rax, one is ; typecode of the object, one is the typecode of the type ; they compare equal cmpq %rdx, %rax ; This is not taken. jne .L9 ; This is taken. jmp .L7 .L8: ; This does not run. movq 312+MM_Main(%rip), %rax cmpq $3, %rax je .L7 .L9: ; Had the expression resolved to FALSE, this would be ; where FALSE is passed to Fmt.Bool movq $0, 16(%rsp) .L7: movq 16(%rsp), %rdi call Fmt__Bool at PLT And here is the code for the IF: .L11: ; just gloss over this part.. movq 40(%rsp), %rax testq %rax, %rax je .L12 movq 40(%rsp), %rax testb $1, %al jne .L13 movq 40(%rsp), %rax movq 312+MM_Main(%rip), %rdx movq -8(%rax), %rax salq $43, %rax shrq $44, %rax ; again at this point, we have the typecodes, and they compare equal cmpq %rdx, %rax ; This is not taken. jne .L14 .L13: ; At this point things have gone wrong. ; The Fmt.Bool path did not compare the typecode to 3. ; after the jne, there should have been a jmp to I guess .L12. movq 312+MM_Main(%rip), %rax cmpq $3, %rax jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT Thanks for the small test case! - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Tue, 16 Jun 2009 08:50:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... Well, the number 3 is REFANY_typecode. I need to compare the if code to the printing code though.. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... Date: Tue, 16 Jun 2009 08:44:21 +0000 Cool. Here is a smaller repro, on birch AMD64_LINUX. The problem is not the AND, the problem is the IF. MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = REF RECORD rest : REFANY; END; VAR t := NEW(Pair, rest := NEW(Pair, rest := NIL)); BEGIN PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); IF ISTYPE(t.rest,Pair) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Tony this is presumably your type tagging changes?? The problem in the code I think is the compare to the number 3. .L13: movq 312+MM_Main(%rip), %rax cmpq $3, %rax <==== jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT What is that for? It comes right from the IL: (118) set_source_line source line 17 (119) import_procedure procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd (120) declare_param param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 alignment 0x40 in _memory 0x0 up_level 0x0 mode 0x11 (DImode) (121) set_runtime_proc (122) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (123) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (124) load_nil (125) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (126) if_eq (127) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (128) loophole (129) load_integer integer 0x1 (130) and (131) if_true (132) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (133) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (134) extract_mn (135) if_false (136) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (137) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (138) pop_param pop param type 0xb (139) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (140) set_label (141) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (142) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (143) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (144) load_nil (145) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (146) if_eq (147) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (148) loophole (149) load_integer integer 0x1 (150) and (151) if_true (152) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (153) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (154) extract_mn (155) if_false (156) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (157) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (158) pop_param pop param type 0xb (159) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (160) set_label (161) load_integer integer 0x1 (162) declare_temp temp var type 0x7 size 0x40 alignment 0x40 (163) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (164) load_nil (165) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (166) if_eq (167) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (168) loophole (169) load_integer integer 0x1 (170) and (171) if_true (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq (177) jump (178) set_label (179) load_integer integer 0x3 (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq (182) set_label (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 alignment 0x8 in_mem ory 0x0 up_level 0x0 mode 0xe () (188) start_call_direct start call procedure Fmt__Bool, level 0x0, type 0xb (189) load m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 (190) pop_param pop param type 0x0 (191) call_direct call procedure Fmt__Bool, type 0xb (192) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (193) start_call_direct start call procedure RTHooks__Concat, level 0x0, type 0xb (194) load_address load address (L_1) offset 0x280 (195) pop_param pop param type 0xb (196) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (197) pop_param pop param type 0xb (198) call_direct call procedure RTHooks__Concat, type 0xb (199) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (200) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (201) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (202) pop_param pop param type 0xb (203) call_direct call procedure Main__PutLn, type 0xd (204) set_source_line source line 18 (205) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (206) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (207) load_nil (208) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (209) if_eq (210) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (211) loophole (212) load_integer integer 0x1 (213) and (214) if_true (215) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (216) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (217) extract_mn (218) if_false (219) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (220) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (221) pop_param pop param type 0xb (222) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (223) set_label (224) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (225) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (226) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (227) load_nil (228) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (229) if_eq (230) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (231) loophole (232) load_integer integer 0x1 (233) and (234) if_true (235) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (236) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (237) extract_mn (238) if_false (239) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (240) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (241) pop_param pop param type 0xb (242) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (243) set_label (244) load_nil (245) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (246) if_eq (247) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (248) loophole (249) load_integer integer 0x1 (250) and (251) if_true (252) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (253) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (254) extract_mn (255) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (256) if_ne (257) set_label (258) load_integer integer 0x3 <===== (259) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (260) if_ne (261) set_label (262) set_source_line source line 19 (263) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (264) load_address load address (L_1) offset 0x400 (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump (268) set_label (269) set_source_line source line 21 (270) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (271) load_address load address (L_1) offset 0x540 (272) pop_param pop param type 0xb (273) call_direct call procedure Main__PutLn, type 0xd (274) set_label (275) set_label (276) load_address load address (MM_Main) offset 0x0 (277) exit_proc (278) free_temp (279) free_temp (280) free_temp (281) free_temp (282) free_temp (283) end_procedure procedure Main_M3 (284) comment comment: `global constant type descriptor' (285) declare_record record id 0xffffffff, fields 0x0, size 0x940 (286) comment comment: `global data type descriptor' I'll dig a bit more. - Jay > To: jay.krell at cornell.edu > Date: Tue, 16 Jun 2009 00:59:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > This small example exhibits it! > > MODULE Main; > IMPORT IO, Fmt; > > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > > TYPE > Pair = BRANDED "Pair" REF RECORD > first, rest : REFANY; > END; > > PROCEDURE Rest(p : Pair) : REFANY = > BEGIN > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > END Rest; > > VAR > t := NEW(Pair, first := "first", > rest := NEW(Pair, first := "second", > rest := NIL)); > > BEGIN > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > PutLn("conjunction? " & Fmt.Bool( > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Output: > > (133)rover:~/testcm3/src>m3build -O > --- building in ../FreeBSD4 --- > m3build: missing ../src/m3overrides > new source -> compiling ../src/Main.m3 > -> linking prog > (134)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? TRUE > in IF clause... > (135)rover:~/testcm3/src>cm3 -clean > --- cleaning ../FreeBSD4 --- > > (136)rover:~/testcm3/src>cm3 > --- building in ../FreeBSD4 --- > > new source -> compiling Main.m3 > -> linking prog > (137)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > (138)rover:~/testcm3/src> > > Jay writes: > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Kneejerk generic response: > > > >=20 > > > >I don't know the operator precedence. Can you put in parens? > > > >Have you looked at the code? > > > >Can you mail us a small self contained repro? > > > >Can you test it on birch? > > > > (That way -- all your files are there and easily gotten/investigated by o= > >thers.) > > > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence. > > > >=20 > > > > - Jay > >=20 > >> To: m3devel at elegosoft.com > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... > >>=20 > >>=20 > >> Hello everyone=2C > >>=20 > >> I'm trying to update to the latest CM3 again=2C so that I can get my > >> Mac working=2C and push my project of migrating a largish codebase > >> from PM3 to CM3 a little further. > >>=20 > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C > >> and ... my Scheme interpreter broke. Here's what the code looks like=2C > >> with annotations: > >>=20 > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> 52 > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> 54 Debug.Out("in IF clause...")=3B > >> 55 > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" > >> 60 END > >> 61 ELSE > >> 62 Debug.Out("in ELSE clause...") > >> 63 END=3B > >>=20 > >> all you need to know is that Debug.Out prints out debugging information > >> to the terminal. What I see is... > >>=20 > >> t.rest =3D NIL? FALSE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> in ELSE clause... > >>=20 > >> What gives!? > >>=20 > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > compiler and runtime bootstrapped today from some previous CM3. > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the > >> code behaved properly under that one. > >>=20 > >> I believe I have also tried it both with and without compiler > >> optimizations. > >>=20 > >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't > >> working right. This is the only if statement in many=2C many source files > >> that seems to be working wrong. > >>=20 > >> Is it possible I'm missing something?? No I don't think so... here's a mo= > >re > >> explicit version: > >>=20 > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> Debug.Out("conjunction? " & Fmt.Bool( > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> ... > >>=20 > >> output is: > >>=20 > >> t.rest # NIL? TRUE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> conjunction? FALSE > >> in ELSE clause... > >>=20 > >> TRUE AND TRUE AND TRUE is FALSE?? > >>=20 > >> Note that:=20 > >>=20 > >> VAR q=2C w=2C e :=3D TRUE=3B > >>=20 > >> Debug.Out("conjunction? " & Fmt.Bool( > >> q AND w AND e))=3B > >>=20 > >> results in TRUE (as it should). > >>=20 > >>=20 > >> Mika > >>=20 > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Kneejerk generic response:
> > =3B
> >I don't know the operator precedence. Can you put in parens?
> >Have you looked at the code?
> >Can you mail us a small self contained repro?
> >Can you test it on birch?
> > =3B (That way -- all your files are there and easily gotten/investigat= > >ed by others.)
> >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence.
> > =3B
> > =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= > >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= > >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= > >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= > >eed to know is that Debug.Out prints out debugging information
>=3B to= > > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= > >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= > >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= > >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= > >ieve I have also tried it both with and without compiler
>=3B optimiza= > >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > > can work if "AND" isn't
>=3B working right. This is the only if state= > >ment in many=2C many source files
>=3B that seems to be working wrong.= > >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= > >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= > >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= > >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B >R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= > >ka
>=3B
> >= > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jun 16 11:59:14 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 09:59:14 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: Here is the code in the compiler, not being familiar..it seems reasonable.. ELSIF RefType.Is (t) THEN Expr.Compile (ce.args[0]); tagged := CG.Next_label (); false := CG.Next_label (); true := CG.Next_label (); ptr := CG.Pop (); Value.Load (Bool.True); CG.Force (); (* we need a temp *) ce.tmp := CG.Pop_temp (); CG.Push (ptr); CG.Load_nil (); CG.If_compare (CG.Type.Addr, CG.Cmp.EQ, true, CG.Maybe); CG.Push (ptr); CG.Loophole (CG.Type.Addr, Target.Integer.cg_type); CG.Load_integer (Target.Integer.cg_type, TInt.One); CG.And (Target.Integer.cg_type); CG.If_true (tagged, CG.Maybe); CG.Push (ptr); CG.Ref_to_info (M3RT.RH_typecode_offset, M3RT.RH_typecode_size); Type.LoadInfo (t, M3RT.TC_typecode); ; This is the comparison of the desired and actual typecode ; If it equal, we will jump to the label "true" CG.If_compare (Target.Integer.cg_type, CG.Cmp.EQ, true, CG.Always); ; otherwise, we already decided it isn't tagged, so jump ; around that to the label false ; ; This is what is missing in the IL. ; CG.Jump (false); CG.Set_label (tagged); CG.Load_intt (M3RT.REFANY_typecode); Type.LoadInfo (t, M3RT.TC_typecode); CG.If_compare (Target.Integer.cg_type, CG.Cmp.EQ, true, CG.Always); CG.Set_label (false); Value.Load (Bool.False); CG.Store_temp (ce.tmp); CG.Set_label (true); CG.Free (ptr); Let's look for jumps in the IL, there are only two: (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq label 6 (177) jump <== here label 5 (178) set_label label 4 (179) load_integer integer 0x3 <== notice this (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq label 6 (182) set_label label 5 (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label label 6 (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param That is the call to Fmt_Bool. You can see the signature value "3", that the jump goes around. and the other one: (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump label 7 not interesting -- you can't tell here, but it is after all the interesting stuff. It is for the if to skip the else. So that leaves me wondering -- what happened to the jump in the IsType? I think it should be there and it missing messes this up. We don't expect to take that jump, we expect the comparison to be equal, but I think the code gets it reversed and makes corresponding changes so this missing jump is the problem... - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... Date: Tue, 16 Jun 2009 09:16:39 +0000 I haven't figured it out, but: Here is the code for the Fmt.Bool: .L6: ; assume the parameter to Fmt.Bool is TRUE, by ; storing 1 in the parameter place movq $1, 16(%rsp) ; do a bunch of stuff, no need to understand.. movq 32(%rsp), %rax testq %rax, %rax je .L7 movq 32(%rsp), %rax testb $1, %al jne .L8 movq 32(%rsp), %rax movq 312+MM_Main(%rip), %rdx movq -8(%rax), %rax salq $43, %rax shrq $44, %rax ; at this point, between $rdx and $rax, one is ; typecode of the object, one is the typecode of the type ; they compare equal cmpq %rdx, %rax ; This is not taken. jne .L9 ; This is taken. jmp .L7 .L8: ; This does not run. movq 312+MM_Main(%rip), %rax cmpq $3, %rax je .L7 .L9: ; Had the expression resolved to FALSE, this would be ; where FALSE is passed to Fmt.Bool movq $0, 16(%rsp) .L7: movq 16(%rsp), %rdi call Fmt__Bool at PLT And here is the code for the IF: .L11: ; just gloss over this part.. movq 40(%rsp), %rax testq %rax, %rax je .L12 movq 40(%rsp), %rax testb $1, %al jne .L13 movq 40(%rsp), %rax movq 312+MM_Main(%rip), %rdx movq -8(%rax), %rax salq $43, %rax shrq $44, %rax ; again at this point, we have the typecodes, and they compare equal cmpq %rdx, %rax ; This is not taken. jne .L14 .L13: ; At this point things have gone wrong. ; The Fmt.Bool path did not compare the typecode to 3. ; after the jne, there should have been a jmp to I guess .L12. movq 312+MM_Main(%rip), %rax cmpq $3, %rax jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT Thanks for the small test case! - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Tue, 16 Jun 2009 08:50:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... Well, the number 3 is REFANY_typecode. I need to compare the if code to the printing code though.. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... Date: Tue, 16 Jun 2009 08:44:21 +0000 Cool. Here is a smaller repro, on birch AMD64_LINUX. The problem is not the AND, the problem is the IF. MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = REF RECORD rest : REFANY; END; VAR t := NEW(Pair, rest := NEW(Pair, rest := NIL)); BEGIN PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); IF ISTYPE(t.rest,Pair) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Tony this is presumably your type tagging changes?? The problem in the code I think is the compare to the number 3. .L13: movq 312+MM_Main(%rip), %rax cmpq $3, %rax <==== jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT What is that for? It comes right from the IL: (118) set_source_line source line 17 (119) import_procedure procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd (120) declare_param param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 alignment 0x40 in _memory 0x0 up_level 0x0 mode 0x11 (DImode) (121) set_runtime_proc (122) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (123) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (124) load_nil (125) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (126) if_eq (127) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (128) loophole (129) load_integer integer 0x1 (130) and (131) if_true (132) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (133) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (134) extract_mn (135) if_false (136) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (137) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (138) pop_param pop param type 0xb (139) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (140) set_label (141) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (142) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (143) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (144) load_nil (145) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (146) if_eq (147) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (148) loophole (149) load_integer integer 0x1 (150) and (151) if_true (152) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (153) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (154) extract_mn (155) if_false (156) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (157) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (158) pop_param pop param type 0xb (159) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (160) set_label (161) load_integer integer 0x1 (162) declare_temp temp var type 0x7 size 0x40 alignment 0x40 (163) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (164) load_nil (165) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (166) if_eq (167) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (168) loophole (169) load_integer integer 0x1 (170) and (171) if_true (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq (177) jump (178) set_label (179) load_integer integer 0x3 (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq (182) set_label (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 alignment 0x8 in_mem ory 0x0 up_level 0x0 mode 0xe () (188) start_call_direct start call procedure Fmt__Bool, level 0x0, type 0xb (189) load m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 (190) pop_param pop param type 0x0 (191) call_direct call procedure Fmt__Bool, type 0xb (192) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (193) start_call_direct start call procedure RTHooks__Concat, level 0x0, type 0xb (194) load_address load address (L_1) offset 0x280 (195) pop_param pop param type 0xb (196) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (197) pop_param pop param type 0xb (198) call_direct call procedure RTHooks__Concat, type 0xb (199) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (200) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (201) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (202) pop_param pop param type 0xb (203) call_direct call procedure Main__PutLn, type 0xd (204) set_source_line source line 18 (205) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (206) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (207) load_nil (208) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (209) if_eq (210) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (211) loophole (212) load_integer integer 0x1 (213) and (214) if_true (215) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (216) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (217) extract_mn (218) if_false (219) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (220) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (221) pop_param pop param type 0xb (222) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (223) set_label (224) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (225) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (226) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (227) load_nil (228) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (229) if_eq (230) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (231) loophole (232) load_integer integer 0x1 (233) and (234) if_true (235) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (236) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (237) extract_mn (238) if_false (239) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (240) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (241) pop_param pop param type 0xb (242) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (243) set_label (244) load_nil (245) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (246) if_eq (247) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (248) loophole (249) load_integer integer 0x1 (250) and (251) if_true (252) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (253) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (254) extract_mn (255) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (256) if_ne (257) set_label (258) load_integer integer 0x3 <===== (259) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (260) if_ne (261) set_label (262) set_source_line source line 19 (263) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (264) load_address load address (L_1) offset 0x400 (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump (268) set_label (269) set_source_line source line 21 (270) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (271) load_address load address (L_1) offset 0x540 (272) pop_param pop param type 0xb (273) call_direct call procedure Main__PutLn, type 0xd (274) set_label (275) set_label (276) load_address load address (MM_Main) offset 0x0 (277) exit_proc (278) free_temp (279) free_temp (280) free_temp (281) free_temp (282) free_temp (283) end_procedure procedure Main_M3 (284) comment comment: `global constant type descriptor' (285) declare_record record id 0xffffffff, fields 0x0, size 0x940 (286) comment comment: `global data type descriptor' I'll dig a bit more. - Jay > To: jay.krell at cornell.edu > Date: Tue, 16 Jun 2009 00:59:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > This small example exhibits it! > > MODULE Main; > IMPORT IO, Fmt; > > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > > TYPE > Pair = BRANDED "Pair" REF RECORD > first, rest : REFANY; > END; > > PROCEDURE Rest(p : Pair) : REFANY = > BEGIN > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > END Rest; > > VAR > t := NEW(Pair, first := "first", > rest := NEW(Pair, first := "second", > rest := NIL)); > > BEGIN > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > PutLn("conjunction? " & Fmt.Bool( > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Output: > > (133)rover:~/testcm3/src>m3build -O > --- building in ../FreeBSD4 --- > m3build: missing ../src/m3overrides > new source -> compiling ../src/Main.m3 > -> linking prog > (134)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? TRUE > in IF clause... > (135)rover:~/testcm3/src>cm3 -clean > --- cleaning ../FreeBSD4 --- > > (136)rover:~/testcm3/src>cm3 > --- building in ../FreeBSD4 --- > > new source -> compiling Main.m3 > -> linking prog > (137)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > (138)rover:~/testcm3/src> > > Jay writes: > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Kneejerk generic response: > > > >=20 > > > >I don't know the operator precedence. Can you put in parens? > > > >Have you looked at the code? > > > >Can you mail us a small self contained repro? > > > >Can you test it on birch? > > > > (That way -- all your files are there and easily gotten/investigated by o= > >thers.) > > > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence. > > > >=20 > > > > - Jay > >=20 > >> To: m3devel at elegosoft.com > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... > >>=20 > >>=20 > >> Hello everyone=2C > >>=20 > >> I'm trying to update to the latest CM3 again=2C so that I can get my > >> Mac working=2C and push my project of migrating a largish codebase > >> from PM3 to CM3 a little further. > >>=20 > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C > >> and ... my Scheme interpreter broke. Here's what the code looks like=2C > >> with annotations: > >>=20 > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> 52 > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> 54 Debug.Out("in IF clause...")=3B > >> 55 > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" > >> 60 END > >> 61 ELSE > >> 62 Debug.Out("in ELSE clause...") > >> 63 END=3B > >>=20 > >> all you need to know is that Debug.Out prints out debugging information > >> to the terminal. What I see is... > >>=20 > >> t.rest =3D NIL? FALSE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> in ELSE clause... > >>=20 > >> What gives!? > >>=20 > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > compiler and runtime bootstrapped today from some previous CM3. > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the > >> code behaved properly under that one. > >>=20 > >> I believe I have also tried it both with and without compiler > >> optimizations. > >>=20 > >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't > >> working right. This is the only if statement in many=2C many source files > >> that seems to be working wrong. > >>=20 > >> Is it possible I'm missing something?? No I don't think so... here's a mo= > >re > >> explicit version: > >>=20 > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> Debug.Out("conjunction? " & Fmt.Bool( > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> ... > >>=20 > >> output is: > >>=20 > >> t.rest # NIL? TRUE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> conjunction? FALSE > >> in ELSE clause... > >>=20 > >> TRUE AND TRUE AND TRUE is FALSE?? > >>=20 > >> Note that:=20 > >>=20 > >> VAR q=2C w=2C e :=3D TRUE=3B > >>=20 > >> Debug.Out("conjunction? " & Fmt.Bool( > >> q AND w AND e))=3B > >>=20 > >> results in TRUE (as it should). > >>=20 > >>=20 > >> Mika > >>=20 > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Kneejerk generic response:
> > =3B
> >I don't know the operator precedence. Can you put in parens?
> >Have you looked at the code?
> >Can you mail us a small self contained repro?
> >Can you test it on birch?
> > =3B (That way -- all your files are there and easily gotten/investigat= > >ed by others.)
> >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence.
> > =3B
> > =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= > >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= > >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= > >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= > >eed to know is that Debug.Out prints out debugging information
>=3B to= > > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= > >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= > >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= > >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= > >ieve I have also tried it both with and without compiler
>=3B optimiza= > >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > > can work if "AND" isn't
>=3B working right. This is the only if state= > >ment in many=2C many source files
>=3B that seems to be working wrong.= > >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= > >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= > >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= > >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B >R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= > >ka
>=3B
> >= > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jun 16 17:35:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 16 Jun 2009 11:35:29 -0400 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: I think I see the problem in the compiler. There is some strangeness in how true=CG.No_label is dealt with. On 16 Jun 2009, at 05:59, Jay wrote: > Here is the code in the compiler, not being familiar..it seems > reasonable.. > > > ELSIF RefType.Is (t) THEN > Expr.Compile (ce.args[0]); > tagged := CG.Next_label (); > false := CG.Next_label (); > true := CG.Next_label (); > ptr := CG.Pop (); > Value.Load (Bool.True); > CG.Force (); (* we need a temp *) > ce.tmp := CG.Pop_temp (); > CG.Push (ptr); > CG.Load_nil (); > CG.If_compare (CG.Type.Addr, CG.Cmp.EQ, true, CG.Maybe); > CG.Push (ptr); > CG.Loophole (CG.Type.Addr, Target.Integer.cg_type); > CG.Load_integer (Target.Integer.cg_type, TInt.One); > CG.And (Target.Integer.cg_type); > CG.If_true (tagged, CG.Maybe); > CG.Push (ptr); > CG.Ref_to_info (M3RT.RH_typecode_offset, M3RT.RH_typecode_size); > Type.LoadInfo (t, M3RT.TC_typecode); > > ; This is the comparison of the desired and actual typecode > ; If it equal, we will jump to the label "true" > CG.If_compare (Target.Integer.cg_type, CG.Cmp.EQ, true, > CG.Always); > > ; otherwise, we already decided it isn't tagged, so jump > ; around that to the label false > ; > ; This is what is missing in the IL. > ; > CG.Jump (false); > > CG.Set_label (tagged); > CG.Load_intt (M3RT.REFANY_typecode); > Type.LoadInfo (t, M3RT.TC_typecode); > CG.If_compare (Target.Integer.cg_type, CG.Cmp.EQ, true, > CG.Always); > CG.Set_label (false); > Value.Load (Bool.False); > CG.Store_temp (ce.tmp); > CG.Set_label (true); > CG.Free (ptr); > > > > Let's look for jumps in the IL, there are only two: > > (172) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (173) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (174) extract_mn > (175) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (176) if_eq > label 6 > (177) jump <== here > label 5 > (178) set_label > label 4 > (179) load_integer > integer 0x3 <== notice this > (180) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (181) if_eq > label 6 > (182) set_label > label 5 > (183) load_integer > integer 0x0 > (184) store > store (noname) offset 0x0 src_t 0x7 dst_t 0x7 > (185) set_label > label 6 > (186) import_procedure > procedure Fmt__Bool nparams 0x1 rettype 0xb > (187) declare_param > > > That is the call to Fmt_Bool. > You can see the signature value "3", that the jump goes around. > > and the other one: > > (265) pop_param > pop param type 0xb > (266) call_direct > call procedure Main__PutLn, type 0xd > (267) jump > label 7 > > not interesting -- you can't tell here, but it is after all the > interesting stuff. > It is for the if to skip the else. > > So that leaves me wondering -- what happened to the jump in the > IsType? > I think it should be there and it missing messes this up. > We don't expect to take that jump, we expect the comparison to be > equal, but I think the code gets it reversed and makes corresponding > changes so this missing jump is the problem... > > > - Jay > > > > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... > Date: Tue, 16 Jun 2009 09:16:39 +0000 > > I haven't figured it out, but: > > Here is the code for the Fmt.Bool: > > .L6: > ; assume the parameter to Fmt.Bool is TRUE, by > ; storing 1 in the parameter place > > movq $1, 16(%rsp) > > ; do a bunch of stuff, no need to understand.. > > movq 32(%rsp), %rax > testq %rax, %rax > je .L7 > movq 32(%rsp), %rax > testb $1, %al > jne .L8 > movq 32(%rsp), %rax > movq 312+MM_Main(%rip), %rdx > movq -8(%rax), %rax > salq $43, %rax > shrq $44, %rax > > ; at this point, between $rdx and $rax, one is > ; typecode of the object, one is the typecode of the type > ; they compare equal > > cmpq %rdx, %rax > > ; This is not taken. > > jne .L9 > > ; This is taken. > > jmp .L7 > > .L8: > ; This does not run. > movq 312+MM_Main(%rip), %rax > cmpq $3, %rax > je .L7 > .L9: > ; Had the expression resolved to FALSE, this would be > ; where FALSE is passed to Fmt.Bool > movq $0, 16(%rsp) > .L7: > movq 16(%rsp), %rdi > call Fmt__Bool at PLT > > > And here is the code for the IF: > > .L11: > ; just gloss over this part.. > > movq 40(%rsp), %rax > testq %rax, %rax > je .L12 > movq 40(%rsp), %rax > testb $1, %al > jne .L13 > movq 40(%rsp), %rax > movq 312+MM_Main(%rip), %rdx > movq -8(%rax), %rax > salq $43, %rax > shrq $44, %rax > > ; again at this point, we have the typecodes, and they compare equal > > cmpq %rdx, %rax > > ; This is not taken. > > jne .L14 > > .L13: > > ; At this point things have gone wrong. > ; The Fmt.Bool path did not compare the typecode to 3. > ; after the jne, there should have been a jmp to I guess .L12. > > movq 312+MM_Main(%rip), %rax > cmpq $3, %rax > jne .L14 > > .L12: > .stabn 68,0,19,.LM9-.LFBB2 > .LM9: > leaq 128+L_1(%rip), %rdi > call Main__PutLn at PLT > jmp .L15 > .p2align 4,,10 > .p2align 3 > .L14: > .stabn 68,0,21,.LM10-.LFBB2 > .LM10: > leaq 168+L_1(%rip), %rdi > call Main__PutLn at PLT > > > Thanks for the small test case! > > - Jay > > > > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > Date: Tue, 16 Jun 2009 08:50:02 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > Well, the number 3 is REFANY_typecode. > I need to compare the if code to the printing code though.. > > - Jay > > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... > Date: Tue, 16 Jun 2009 08:44:21 +0000 > > Cool. > Here is a smaller repro, on birch AMD64_LINUX. > > The problem is not the AND, the problem is the IF. > > > MODULE Main; > IMPORT IO, Fmt; > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > TYPE > Pair = REF RECORD > rest : REFANY; > END; > VAR > t := NEW(Pair, rest := NEW(Pair, rest := NIL)); > BEGIN > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > IF ISTYPE(t.rest,Pair) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Tony this is presumably your type tagging changes?? > > The problem in the code I think is the compare to the number 3. > > .L13: > movq 312+MM_Main(%rip), %rax > cmpq $3, %rax <==== > jne .L14 > .L12: > .stabn 68,0,19,.LM9-.LFBB2 > .LM9: > leaq 128+L_1(%rip), %rdi > call Main__PutLn at PLT > jmp .L15 > .p2align 4,,10 > .p2align 3 > .L14: > .stabn 68,0,21,.LM10-.LFBB2 > .LM10: > leaq 168+L_1(%rip), %rdi > call Main__PutLn at PLT > > > What is that for? > > > It comes right from the IL: > > (118) set_source_line > source line 17 > (119) import_procedure > procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd > (120) declare_param > param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 > alignment 0x40 in > _memory 0x0 up_level 0x0 > mode 0x11 (DImode) > (121) set_runtime_proc > (122) load > m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb > (123) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (124) load_nil > (125) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (126) if_eq > (127) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (128) loophole > (129) load_integer > integer 0x1 > (130) and > (131) if_true > (132) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (133) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (134) extract_mn > (135) if_false > (136) start_call_direct > start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type > 0xd > (137) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (138) pop_param > pop param type 0xb > (139) call_direct > call procedure RTHooks__CheckLoadTracedRef, type 0xd > (140) set_label > (141) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (142) load_indirect > load address offset 0x0 src_t 0xb dst_t 0xb > (143) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (144) load_nil > (145) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (146) if_eq > (147) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (148) loophole > (149) load_integer > integer 0x1 > (150) and > (151) if_true > (152) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (153) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (154) extract_mn > (155) if_false > (156) start_call_direct > start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type > 0xd > (157) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (158) pop_param > pop param type 0xb > (159) call_direct > call procedure RTHooks__CheckLoadTracedRef, type 0xd > (160) set_label > (161) load_integer > integer 0x1 > (162) declare_temp > temp var type 0x7 size 0x40 alignment 0x40 > (163) store > store (noname) offset 0x0 src_t 0x7 dst_t 0x7 > (164) load_nil > (165) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (166) if_eq > (167) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (168) loophole > (169) load_integer > integer 0x1 > (170) and > (171) if_true > (172) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (173) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (174) extract_mn > (175) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (176) if_eq > (177) jump > (178) set_label > (179) load_integer > integer 0x3 > (180) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (181) if_eq > (182) set_label > (183) load_integer > integer 0x0 > (184) store > store (noname) offset 0x0 src_t 0x7 dst_t 0x7 > (185) set_label > (186) import_procedure > procedure Fmt__Bool nparams 0x1 rettype 0xb > (187) declare_param > param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 > alignment 0x8 in_mem > ory 0x0 up_level 0x0 > mode 0xe () > (188) start_call_direct > start call procedure Fmt__Bool, level 0x0, type 0xb > (189) load > m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 > (190) pop_param > pop param type 0x0 > (191) call_direct > call procedure Fmt__Bool, type 0xb > (192) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (193) start_call_direct > start call procedure RTHooks__Concat, level 0x0, type 0xb > (194) load_address > load address (L_1) offset 0x280 > (195) pop_param > pop param type 0xb > (196) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (197) pop_param > pop param type 0xb > (198) call_direct > call procedure RTHooks__Concat, type 0xb > (199) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (200) start_call_direct > start call procedure Main__PutLn, level 0x0, type 0xd > (201) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (202) pop_param > pop param type 0xb > (203) call_direct > call procedure Main__PutLn, type 0xd > (204) set_source_line > source line 18 > (205) load > m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb > (206) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (207) load_nil > (208) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (209) if_eq > (210) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (211) loophole > (212) load_integer > integer 0x1 > (213) and > (214) if_true > (215) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (216) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (217) extract_mn > (218) if_false > (219) start_call_direct > start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type > 0xd > (220) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (221) pop_param > pop param type 0xb > (222) call_direct > call procedure RTHooks__CheckLoadTracedRef, type 0xd > (223) set_label > (224) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (225) load_indirect > load address offset 0x0 src_t 0xb dst_t 0xb > (226) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (227) load_nil > (228) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (229) if_eq > (230) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (231) loophole > (232) load_integer > integer 0x1 > (233) and > (234) if_true > (235) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (236) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (237) extract_mn > (238) if_false > (239) start_call_direct > start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type > 0xd > (240) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (241) pop_param > pop param type 0xb > (242) call_direct > call procedure RTHooks__CheckLoadTracedRef, type 0xd > (243) set_label > (244) load_nil > (245) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (246) if_eq > (247) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (248) loophole > (249) load_integer > integer 0x1 > (250) and > (251) if_true > (252) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (253) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (254) extract_mn > (255) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (256) if_ne > (257) set_label > (258) load_integer > integer 0x3 <===== > (259) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (260) if_ne > (261) set_label > (262) set_source_line > source line 19 > (263) start_call_direct > start call procedure Main__PutLn, level 0x0, type 0xd > (264) load_address > load address (L_1) offset 0x400 > (265) pop_param > pop param type 0xb > (266) call_direct > call procedure Main__PutLn, type 0xd > (267) jump > (268) set_label > (269) set_source_line > source line 21 > (270) start_call_direct > start call procedure Main__PutLn, level 0x0, type 0xd > (271) load_address > load address (L_1) offset 0x540 > (272) pop_param > pop param type 0xb > (273) call_direct > call procedure Main__PutLn, type 0xd > (274) set_label > (275) set_label > (276) load_address > load address (MM_Main) offset 0x0 > (277) exit_proc > (278) free_temp > (279) free_temp > (280) free_temp > (281) free_temp > (282) free_temp > (283) end_procedure > procedure Main_M3 > (284) comment > comment: `global constant type descriptor' > (285) declare_record > record id 0xffffffff, fields 0x0, size 0x940 > (286) comment > comment: `global data type descriptor' > > > I'll dig a bit more. > > > - Jay > > > > > > > > > To: jay.krell at cornell.edu > > Date: Tue, 16 Jun 2009 00:59:10 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled > code... > > > > This small example exhibits it! > > > > MODULE Main; > > IMPORT IO, Fmt; > > > > PROCEDURE PutLn(what : TEXT) = > > BEGIN IO.Put(what & "\n") END PutLn; > > > > > > TYPE > > Pair = BRANDED "Pair" REF RECORD > > first, rest : REFANY; > > END; > > > > PROCEDURE Rest(p : Pair) : REFANY = > > BEGIN > > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > > END Rest; > > > > VAR > > t := NEW(Pair, first := "first", > > rest := NEW(Pair, first := "second", > > rest := NIL)); > > > > BEGIN > > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > > PutLn("conjunction? " & Fmt.Bool( > > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = > NIL) )); > > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = > NIL) THEN > > PutLn("in IF clause...") > > ELSE > > PutLn("in ELSE clause...") > > END > > END Main. > > > > Output: > > > > (133)rover:~/testcm3/src>m3build -O > > --- building in ../FreeBSD4 --- > > m3build: missing ../src/m3overrides > > new source -> compiling ../src/Main.m3 > > -> linking prog > > (134)rover:~/testcm3/src>../FreeBSD4/prog > > t.rest # NIL? TRUE > > ISTYPE(t.rest,Pair)? TRUE > > Rest(t.rest) = NIL? TRUE > > conjunction? TRUE > > in IF clause... > > (135)rover:~/testcm3/src>cm3 -clean > > --- cleaning ../FreeBSD4 --- > > > > (136)rover:~/testcm3/src>cm3 > > --- building in ../FreeBSD4 --- > > > > new source -> compiling Main.m3 > > -> linking prog > > (137)rover:~/testcm3/src>../FreeBSD4/prog > > t.rest # NIL? TRUE > > ISTYPE(t.rest,Pair)? TRUE > > Rest(t.rest) = NIL? TRUE > > conjunction? FALSE > > in ELSE clause... > > (138)rover:~/testcm3/src> > > > > Jay writes: > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > > >Content-Type: text/plain; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > > > > >Kneejerk generic response: > > > > > >=20 > > > > > >I don't know the operator precedence. Can you put in parens? > > > > > >Have you looked at the code? > > > > > >Can you mail us a small self contained repro? > > > > > >Can you test it on birch? > > > > > > (That way -- all your files are there and easily gotten/ > investigated by o= > > >thers.) > > > > > >Optimization enabled? Works without? I know=2C I shouldn't even > ask this so= > > >rt of thing without evidence. > > > > > >=20 > > > > > > - Jay > > >=20 > > >> To: m3devel at elegosoft.com > > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > > >> From: mika at async.caltech.edu > > >> CC: mika at camembert.async.caltech.edu > > >> Subject: [M3devel] Strange behavior in recent CM3-compiled > code... > > >>=20 > > >>=20 > > >> Hello everyone=2C > > >>=20 > > >> I'm trying to update to the latest CM3 again=2C so that I can > get my > > >> Mac working=2C and push my project of migrating a largish > codebase > > >> from PM3 to CM3 a little further. > > >>=20 > > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD > system=2C > > >> and ... my Scheme interpreter broke. Here's what the code looks > like=2C > > >> with annotations: > > >>=20 > > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & > Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & > Fmt.Bool(Rest(t.rest)=3DNIL))=3B > > >> 52 > > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D > NIL THEN > > >> 54 Debug.Out("in IF clause...")=3B > > >> 55 > > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D > "=2C@" > > >> 60 END > > >> 61 ELSE > > >> 62 Debug.Out("in ELSE clause...") > > >> 63 END=3B > > >>=20 > > >> all you need to know is that Debug.Out prints out debugging > information > > >> to the terminal. What I see is... > > >>=20 > > >> t.rest =3D NIL? FALSE > > >> ISTYPE(t.rest=2CT)? TRUE > > >> Rest(t.rest) =3D NIL? TRUE > > >> in ELSE clause... > > >>=20 > > >> What gives!? > > >>=20 > > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > > compiler and runtime bootstrapped today from some previous CM3. > > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C > and the > > >> code behaved properly under that one. > > >>=20 > > >> I believe I have also tried it both with and without compiler > > >> optimizations. > > >>=20 > > >> I find it baffling that so much stuff (mentor!) can work if > "AND" isn't > > >> working right. This is the only if statement in many=2C many > source files > > >> that seems to be working wrong. > > >>=20 > > >> Is it possible I'm missing something?? No I don't think so... > here's a mo= > > >re > > >> explicit version: > > >>=20 > > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > > >> Debug.Out("ISTYPE(t.rest=2CT)? " & > Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > > >> Debug.Out("Rest(t.rest) =3D NIL? " & > Fmt.Bool(Rest(t.rest)=3DNIL))=3B > > >> Debug.Out("conjunction? " & Fmt.Bool( > > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D > NIL ))=3B > > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL > THEN > > >> ... > > >>=20 > > >> output is: > > >>=20 > > >> t.rest # NIL? TRUE > > >> ISTYPE(t.rest=2CT)? TRUE > > >> Rest(t.rest) =3D NIL? TRUE > > >> conjunction? FALSE > > >> in ELSE clause... > > >>=20 > > >> TRUE AND TRUE AND TRUE is FALSE?? > > >>=20 > > >> Note that:=20 > > >>=20 > > >> VAR q=2C w=2C e :=3D TRUE=3B > > >>=20 > > >> Debug.Out("conjunction? " & Fmt.Bool( > > >> q AND w AND e))=3B > > >>=20 > > >> results in TRUE (as it should). > > >>=20 > > >>=20 > > >> Mika > > >>=20 > > > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > > >Content-Type: text/html; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > > > > > > > > >Kneejerk generic response:
> > > =3B
> > >I don't know the operator precedence. Can you put in parens?
> > >Have you looked at the code?
> > >Can you mail us a small self contained repro?
> > >Can you test it on birch?
> > > =3B (That way -- all your files are there and easily gotten/ > investigat= > > >ed by others.)
> > >Optimization enabled? Works without? I know=2C I shouldn't even > ask this so= > > >rt of thing without evidence.
> > > =3B
> > > =3B- Jay
 =3B
>=3B To: > m3devel at elegosoft.com
>=3B Dat= > > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu > = > > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B > Subject: [M3devel= > > >] Strange behavior in recent CM3-compiled code...
>=3B >
>=3B
= > > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to > update to the l= > > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C > and push m= > > >y project of migrating a largish codebase
>=3B from PM3 to > CM3 a littl= > > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C > on both my = > > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme > interpreter brok= > > >e. Here's what the code looks like=2C
>=3B with > annotations:
>=3B= > > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B > Fmt.Bool(t.rest=3DNIL))= > > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B > Fmt.Bool(ISTYPE(t= > > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " > &=3B Fmt= > > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest > # NIL AND= > > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 > Debug.Out("i= > > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C > "quote") = > > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C > "quasiquote") THE= > > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") > THEN spec= > > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote- > splicing") THEN= > > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B > 62 Debug.= > > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B > all you n= > > >eed to know is that Debug.Out prints out debugging > information
>=3B to= > > > the terminal. What I see is...
>=3B
>=3B t.rest =3D > NIL? FALSE<= > > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D > NIL? TRUE
= > > >>=3B in ELSE clause...
>=3B
>=3B What gives!? >
>=3B
&g= > > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 > with a
&g= > > >t=3B compiler and runtime bootstrapped today from some previous > CM3.
>= > > >=3B My old CM3 compiler was timestamped... April 30=2C I > believe=2C and the= > > >
>=3B code behaved properly under that one.
>=3B >
>=3B I bel= > > >ieve I have also tried it both with and without > compiler
>=3B optimiza= > > >tions.
>=3B
>=3B I find it baffling that so much stuff > (mentor!)= > > > can work if "AND" isn't
>=3B working right. This is the > only if state= > > >ment in many=2C many source files
>=3B that seems to be > working wrong.= > > >
>=3B
>=3B Is it possible I'm missing something?? No I > don't thi= > > >nk so... here's a more
>=3B explicit version:
>=3B >
>=3B Deb= > > >ug.Out("t.rest # NIL? " &=3B > Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > > >t("ISTYPE(t.rest=2CT)? " &=3B > Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B > Fmt.Bool(Rest(t.rest)=3DNIL))= > > >=3B
>=3B Debug.Out("conjunction? " &=3B > Fmt.Bool(
>=3B t.rest = > > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D > NIL ))=3B
>=3B IF t.= > > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL > THEN
>=3B .= > > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # > NIL? TRUE<= > > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D > NIL? TRUE
= > > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B >
>=3B = > > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that: >
>= > > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B > Debug.Out(= > > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND > e))=3B
>=3B > >R>>=3B results in TRUE (as it should).
>=3B
>=3B >
>=3B Mi= > > >ka
>=3B
> > >= > > > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Jun 17 00:33:30 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 16 Jun 2009 15:33:30 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Tue, 16 Jun 2009 18:33:41." <20090616163341.32CFBCC308@birch.elegosoft.com> Message-ID: <200906162233.n5GMXUhZ091746@camembert.async.caltech.edu> Just wanted to report that my evidence of the bug is gone with this update. As always, many thanks! Antony Hosking writes: >CVSROOT: /usr/cvs >Changes by: hosking at birch. 09/06/16 18:33:41 > >Modified files: > cm3/m3-sys/m3front/src/builtinOps/: IsType.m3 > >Log message: > Fix bug introduced in conditional ISTYPE when tagged reference support was > added. From wagner at elegosoft.com Wed Jun 17 11:19:04 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 17 Jun 2009 11:19:04 +0200 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> References: <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: <20090617111904.nkmmsr3s0kswsg0s@mail.elegosoft.com> Quoting Mika Nystrom : > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function > `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function > `patsubst'. Stop. I had these errors, too, some weeks ago. I had to manually install the latest GNU versions of make, autoconf and automake, IIRC. These kinds of problems always kreep in by importing new gcc code, as the GNU developers of course always use all their latest tools, and Apple is somewhay more conservative with their distributions. Olaf > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake > runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 09/06/15 11:49:14 >> >> Added files: >> cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c >> gengtype-yacc.h >> >> Log message: >> Add back the lex/yacc/flex/bison outputs that Apple deleted >> but didn't note in the REMOVED file. You only see their >> absence cause problems if building on a machine without >> lex/yacc/flex/bison, such as birch that is missing bison. >> Apple didn't modify gengtype-lex.l and gentype-yacc.y, >> so the unmodified versions of these files taken from gcc 4.2.1. > -- 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 Jun 18 13:43:34 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Jun 2009 13:43:34 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090609212543.GA23398@topoi.pooq.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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> Message-ID: <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > Is it time for me to make another try at installing cm3 from scratch? > In particular, do you think most of the problems I reported with > documentation and archives, etc., have been solved? I really want to > get m3 working on this laptop, but I also want to provide the most > useful problem reports. > > I'm definitely trying to act like a naive user in these installation > attempts (which means I'm trying to act stupider than I am). I've now put some initial release engineering documentation onto birch, available at http://www.opencm3.net/releng It is not linked yet to the main web pages. There are archives for AMD64 built on birch, and current archives for FreeBSD4 should arrive within the next hours (depending on the upload speed of my home link :-). Please try one of those platforms as an example, if possible, before we proceed to perform the builds on other targets. Feel free to update/fix/extend the documentation in www/releng/index-frag.html We will also need to add some more system specifics for Windows users. Perhaps Randy or Jay will look at that. All RC1 archives can be built and shipped to birch with SHIPRC=yes ./scripts/make-dist.sh Contributions for all missing platforms are welcome; but I'd suggest to wait for the first doc and script fixes before we announce the availability for the first release candidate. I'd also like to add links for any system-specific installation packages which might be available. Of course, these should contain the same RC version as the standard archives. Please everybody, add corrections and extended information as you see fit. Thanks for your patience and continuing support, 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 Thu Jun 18 14:05:20 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 12:05:20 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618134334.njcom4fusg0ccsws@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Message-ID: 2) CM3's shared libraries and any you create and ship are in: /usr/local/cm3/lib On most Unix systems you need to set the LD_LIBRARY_PATH (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) environment variable before running programs that use these shared libraries. You don't need to do this any longer. Except on NetBSD. But even that will change with a move to NetBSD 5.0, which was recently released. I'm not certain I got to every platform yet with that change, but I definitely got to a few. AMD64_DARWIN is missing from the list. You should probably mention "Mac OSX" in the description of "Darwin", well, except for ARM_DARWIN, which should mention iPhone and iPod Touch. (cm3 does run on my phone..) Interix should mention Service for Unix (SFU) and Subsystem for Unix Applications (SUA). SOLgnu uses the GNU C compiler but I believe Sun linker. I still haven't done much with my Alpha and IA64 machines. :) Hm, so many archives per platform now. Combinatorial situations lend themselves to combinatorial thinking/work, yuck.. - Jay ---------------------------------------- > Date: Thu, 18 Jun 2009 13:43:34 +0200 > From: wagner at elegosoft.com > To: hendrik at topoi.pooq.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > http://www.opencm3.net/releng From jay.krell at cornell.edu Thu Jun 18 14:12:30 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 12:12:30 +0000 Subject: [M3devel] platform names Message-ID: The new documentation says: Except for some legacy names, all target names have the format PROCESSOR OR ARCHITECTURE_OPERATING SYSTEM. I'm not suggesting a change to the documentation or any existing "new" platform names but I'm pretty certain this system is going to break down on some platforms. In particular, I have an "ARM_LINUX" system, with uclibc, instead of the "usual" desktop/laptop/server glibc. And I have an "MIPLE_LINUX" system, also with uclibc, and worse, Linux 2.4. It is a router and apparently 2.4 is considered reasonable and "current". Linux 2.4 doesn't have the "good" native pthreads, though it does have the old bad "LinuxThreads". It's possible, esp. for Linux, we can/should target the kernel syscall interface and not the C runtime. In which case, this problem is reduced. That's very similar to static linking to libc.a. It's probably /mostly/ easy, easy for open/close/stat/seek/read/write/_exit/fork/exec which are probably all pretty thin in the C runtime. But less easy for startup and threads. It /might/ be that uclibc and glibc are binary compatible, at least partly. I don't know. - Jay From wagner at elegosoft.com Thu Jun 18 14:34:31 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Jun 2009 14:34:31 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: 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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Message-ID: <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> Quoting Jay : > > 2) CM3's shared libraries and any you create and ship are in: > /usr/local/cm3/lib > On most Unix systems you need to set the LD_LIBRARY_PATH > (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) > environment variable before running programs that use > these shared libraries. > You don't need to do this any longer. > Except on NetBSD. But even that will change with a move to NetBSD 5.0, > which was recently released. > I'm not certain I got to every platform yet with that change, but > I definitely got to a few. doc fixed > AMD64_DARWIN is missing from the list. > You should probably mention "Mac OSX" in the description of "Darwin", > well, except for ARM_DARWIN, which should mention iPhone and iPod Touch. > (cm3 does run on my phone..) There is no configuration file for it in m3-sys/cminstall/src/config-no-install I've added it nonetheless. Perhaps you need to commit it. > Interix should mention Service for Unix (SFU) and Subsystem for Unix > Applications (SUA). added > SOLgnu uses the GNU C compiler but I believe Sun linker. fixed > I still haven't done much with my Alpha and IA64 machines. :) > > > Hm, so many archives per platform now. > Combinatorial situations lend themselves to combinatorial > thinking/work, yuck.. We can also provide one complete big archive if people want that. It's just a matter of adding one line in make-dist.sh. It will put some more stress on our network links though ;-) I doubt that many people really want everything. Thanks for the comments, 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 Thu Jun 18 14:39:26 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 12:39:26 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618143431.9b3b3tmzjqww4s48@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> Message-ID: > >> AMD64_DARWIN is missing from the list. > > There is no configuration file for it in > That's because I don't have this hardware, yet. :) - Jay From jay.krell at cornell.edu Thu Jun 18 14:52:29 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 12:52:29 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618143431.9b3b3tmzjqww4s48@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> Message-ID: ps: NT386 isn't in the list. Interix btw is something you free "beer" download and install on some versions of Windows (XP, 2003, I think 2000), and is an optional component you can just enable on newer version (2003R2, Vista, 2008). So maybe Windows and/or NT should be mentioned there. Support will likely only be for 3.5 or newer, since that is when pthreads support was added, and it is already fairly old. NT386GNU and NT386MINGNU are missing also, but that's ok. I kind of like the idea of there being "tiers" of platforms. Two or maybe three. The more supported and the less supported. I would suggest: tier 1: LINUXLIBC6 (aka I386_LINUX) AMD64_LINUX FreeBSD4 (aka I386_FREEBSD) AMD64_FREEBSD AMD64_LINUX I386_LINUX SOLgnu tier 2: SPARC32_LINUX SPARC64_LINUX *_OPENBSD *_NETBSD, NetBSD2i386 SOLsun PPC_* MIPS*_* tier 3: could probably be done easily/quickly if anyone wanted and hardware made available, if gcc 4.2 or 4.3 already supports it (You see, a C backend would extend support to more systems..Plan9 for example...) This is based on apparent number of users. I don't draw a distinction between I386_DARWIN and AMD64_DARWIN because they run on nearly the exact same systems, nearly. (except non-Apple hardware, a few old x86 Macs, and maybe Apple TV). It might be reasonable as well to say a platform can only be tier 1 if has a Tinderbox running. That would knock the list down a lot though. - Jay ---------------------------------------- > Date: Thu, 18 Jun 2009 14:34:31 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: hendrik at topoi.pooq.com; m3devel at elegosoft.com > Subject: RE: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > Quoting Jay : > >> >> 2) CM3's shared libraries and any you create and ship are in: >> /usr/local/cm3/lib >> On most Unix systems you need to set the LD_LIBRARY_PATH >> (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) >> environment variable before running programs that use >> these shared libraries. >> You don't need to do this any longer. >> Except on NetBSD. But even that will change with a move to NetBSD 5.0, >> which was recently released. >> I'm not certain I got to every platform yet with that change, but >> I definitely got to a few. > > doc fixed > >> AMD64_DARWIN is missing from the list. >> You should probably mention "Mac OSX" in the description of "Darwin", >> well, except for ARM_DARWIN, which should mention iPhone and iPod Touch. >> (cm3 does run on my phone..) > > There is no configuration file for it in > > m3-sys/cminstall/src/config-no-install > > I've added it nonetheless. Perhaps you need to commit it. > >> Interix should mention Service for Unix (SFU) and Subsystem for Unix >> Applications (SUA). > > added > >> SOLgnu uses the GNU C compiler but I believe Sun linker. > > fixed > >> I still haven't done much with my Alpha and IA64 machines. :) >> >> >> Hm, so many archives per platform now. >> Combinatorial situations lend themselves to combinatorial >> thinking/work, yuck.. > > We can also provide one complete big archive if people want that. > It's just a matter of adding one line in make-dist.sh. > It will put some more stress on our network links though ;-) > I doubt that many people really want everything. > > Thanks for the comments, > > 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 wagner at elegosoft.com Thu Jun 18 15:06:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Jun 2009 15:06:36 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: 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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> Message-ID: <20090618150636.0rbmvi4g74k04cww@mail.elegosoft.com> Quoting Jay : > ps: NT386 isn't in the list. > > Interix btw is something you free "beer" download and install on > some versions of Windows (XP, 2003, I think 2000), and is an > optional component you can just enable on newer version (2003R2, > Vista, 2008). > So maybe Windows and/or NT should be mentioned there. > Support will likely only be for 3.5 or newer, since that is when > pthreads support was added, and it is already fairly old. > > > NT386GNU and NT386MINGNU are missing also, but that's ok. Jay, could you please add appropriate config files for NT386 and NT386GNU to the config-no-install directory? I was of the opinion, that your config files there were complete. I'd like to be both these platforms to be part of the release. > I kind of like the idea of there being "tiers" of platforms. > Two or maybe three. > The more supported and the less supported. > > > I would suggest: > > > tier 1: > LINUXLIBC6 (aka I386_LINUX) > AMD64_LINUX > FreeBSD4 (aka I386_FREEBSD) > AMD64_FREEBSD > AMD64_LINUX > I386_LINUX > SOLgnu +NT386 We should not ignore the Windows community. > tier 2: > SPARC32_LINUX > SPARC64_LINUX > *_OPENBSD > *_NETBSD, NetBSD2i386 > SOLsun > PPC_* > MIPS*_* > > tier 3: > could probably be done easily/quickly if anyone wanted and hardware > made available, if gcc 4.2 or 4.3 already supports it > (You see, a C backend would extend support to more systems..Plan9 > for example...) > > This is based on apparent number of users. > I don't draw a distinction between I386_DARWIN and AMD64_DARWIN > because they run on nearly the exact same systems, nearly. (except > non-Apple hardware, a few old x86 Macs, and maybe Apple TV). > > It might be reasonable as well to say a platform can only be tier 1 > if has a Tinderbox running. > That would knock the list down a lot though. That would be too constraining currently. Thanks in advance, 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 Thu Jun 18 16:07:16 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 14:07:16 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618150636.0rbmvi4g74k04cww@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> <20090618150636.0rbmvi4g74k04cww@mail.elegosoft.com> Message-ID: (Yes, of course NT386 is tier 1, I forgot, NT386GNU, NT386MINGNU, eh..there is a test case that hangs on NT386GNU that I couldn't figure out and it is slow..I386_INTERIX /might/ be a viable alternative, but it seems to have far less of a following..but NT386GNU does have 64bit LONG and NT386 does not.. :( ) - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: hendrik at topoi.pooq.com; m3devel at elegosoft.com Subject: RE: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) Date: Thu, 18 Jun 2009 14:05:28 +0000 The NT386* files are in the old config directory. My automation knows to check config-no-install first, then config. I thought moving them might break you. At least in the past. Your Tinderbox work. You know...I kind of took over these files, churned them mercilessly, felt ok about it. All the other files I forked and left the "originals" alone. But then eventually mine became the Real ones. Ok, I'll move them. At some point..maybe just after this release, I suggest we: delete all of config then move all config-no-install to config But I bet CVS can't track history across a move, lame. (Maybe after this release we switch to svn or hg or git or mtn, or can get a free p4 license, or darn near anything...) And also delete all the unused Unix/*.i3 files. I worry about the fine line between keeping stuff for historical purposes vs. deleting unused stuff for clarity. I know CVS keeps even the deleted stuff, but Attic is kind of less visible, isn't brought down by cvs upd, and the cvs web interface is poor. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jun 18 16:05:28 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 14:05:28 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618150636.0rbmvi4g74k04cww@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> <20090618150636.0rbmvi4g74k04cww@mail.elegosoft.com> Message-ID: The NT386* files are in the old config directory. My automation knows to check config-no-install first, then config. I thought moving them might break you. At least in the past. Your Tinderbox work. You know...I kind of took over these files, churned them mercilessly, felt ok about it. All the other files I forked and left the "originals" alone. But then eventually mine became the Real ones. Ok, I'll move them. At some point..maybe just after this release, I suggest we: delete all of config then move all config-no-install to config But I bet CVS can't track history across a move, lame. (Maybe after this release we switch to svn or hg or git or mtn, or can get a free p4 license, or darn near anything...) And also delete all the unused Unix/*.i3 files. I worry about the fine line between keeping stuff for historical purposes vs. deleting unused stuff for clarity. I know CVS keeps even the deleted stuff, but Attic is kind of less visible, isn't brought down by cvs upd, and the cvs web interface is poor. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jun 18 16:27:03 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 14:27:03 +0000 Subject: [M3devel] FW: Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618134334.njcom4fusg0ccsws@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Message-ID: The copy to the list was truncated, but direct to Olaf wasn't and he quoted the whole thing.. (The truncation of Olaf's original message was my deliberate doing.) - Jay > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; hendrik at topoi.pooq.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > Date: Thu, 18 Jun 2009 12:05:20 +0000 > > > 2) CM3's shared libraries and any you create and ship are in: > /usr/local/cm3/lib > On most Unix systems you need to set the LD_LIBRARY_PATH > (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) > environment variable before running programs that use > these shared libraries. > > > You don't need to do this any longer. > Except on NetBSD. But even that will change with a move to NetBSD 5.0, > which was recently released. > I'm not certain I got to every platform yet with that change, but > I definitely got to a few. > > > AMD64_DARWIN is missing from the list. > You should probably mention "Mac OSX" in the description of "Darwin", > well, except for ARM_DARWIN, which should mention iPhone and iPod Touch. > (cm3 does run on my phone..) > > > Interix should mention Service for Unix (SFU) and Subsystem for Unix Applications (SUA). > > > SOLgnu uses the GNU C compiler but I believe Sun linker. > > > I still haven't done much with my Alpha and IA64 machines. :) > > > Hm, so many archives per platform now. > Combinatorial situations lend themselves to combinatorial thinking/work, yuck.. > > > - Jay > > > > ---------------------------------------- > > Date: Thu, 18 Jun 2009 13:43:34 +0200 > > From: wagner at elegosoft.com > > To: hendrik at topoi.pooq.com > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > > > http://www.opencm3.net/releng -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 22 06:04:31 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 04:04:31 +0000 Subject: [M3devel] new distribution size? Message-ID: Olaf, The ws-core archives are quite large. Over 100meg, four times the size of bin-std. Should they be? I guess they have a lot of source? - Jay From wagner at elegosoft.com Mon Jun 22 08:17:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Jun 2009 08:17:29 +0200 Subject: [M3devel] new distribution size? In-Reply-To: References: Message-ID: <20090622081729.z6gvq7us8w8ckscs@mail.elegosoft.com> Quoting Jay : > > Olaf, > > The ws-core archives are quite large. > Over 100meg, four times the size of bin-std. > Should they be? I guess they have a lot of source? It's mostly the gcc compiler collection: % (. scripts/pkginfo.sh; for f in `grep core scripts/pkginfo.txt | awk '{print $1}'`; do p=`pkgpath $f`; du -sk $p; done) 1486 m3-win/import-libs 326892 m3-sys/m3cc 22294 m3-libs/m3core 25638 m3-libs/libm3 704 m3-libs/patternmatching 2542 m3-libs/sysutils 386 m3-libs/unittest 4492 m3-sys/m3middle 786 m3-sys/m3objfile 1334 m3-sys/m3linker 2662 m3-sys/m3back 2018 m3-sys/m3staloneback 19328 m3-sys/m3front 2082 m3-sys/m3quake 38372 m3-sys/cm3 320 m3-sys/m3scanner 1804 m3-sys/m3tools 4964 m3-sys/m3cgcat 2744 m3-sys/m3cggen 2750 m3-tools/m3bundle 1394 m3-sys/mklib 1318 m3-sys/fix_nl 348 m3-sys/libdump 702 m3-libs/bitvector 382 m3-libs/digraph 286 m3-libs/parseparams 1208 m3-libs/realgeometry 1188 m3-libs/set 1210 m3-libs/slisp 758 m3-libs/sortedtableextras 1002 m3-libs/table-list 202 m3-libs/tempfiles 206 m3-libs/tcl 794 m3-comm/tcp Perhaps we should archive that on its own, too? What do the others think? 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 Mon Jun 22 11:33:24 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 09:33:24 +0000 Subject: [M3devel] nanosleep? Message-ID: Tony, Interix doesn't have nanosleep. Suggestions? It looks like all the uses except for XPause could use usleep? - Jay From hosking at cs.purdue.edu Mon Jun 22 12:29:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Jun 2009 06:29:38 -0400 Subject: [M3devel] nanosleep? In-Reply-To: References: Message-ID: Urgh! Perhaps implement a nanosleep for Interix in terms of usleep? On 22 Jun 2009, at 05:33, Jay wrote: > > Tony, Interix doesn't have nanosleep. > Suggestions? > > It looks like all the uses except for XPause could use usleep? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 22 14:58:17 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 12:58:17 +0000 Subject: [M3devel] files larger than 2gig Message-ID: C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 TYPE Status = RECORD type: Type; modificationTime: Time.T; size: INTEGER; END; size: INTEGER causes exceptions when you use the Modula-3 gui and browse to a directory with files larger than 2 gig. I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa (out 64 bits total) and thus can represent integers very much larger than INTEGER. LONGINT is a tempting option but doesn't help on the current NT386 platform, and I think 53 bits will last a very long time. I'm just trying out such a change and I can see it is not source compatible: "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN "../src/rw/FileRd.m3", line 140: types are not assignable 2 errors encountered "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX 2 errors encountered Nevertheless I think it should be done, probably even for this release. - Jay From jay.krell at cornell.edu Mon Jun 22 15:09:25 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 13:09:25 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Message-ID: Hm, here is another approach -- leave more code alone, like don't attempt to let FileRd/FileWr work on files larger than 2gig on a 32bit system for example. But do fix the lowest level status record to have either LONGINT or LONGREAL, preferable LONGREAL for the sake of NT386 (much as I dislike floating point..). That is, an intermediate goal would be: - browing to a directory with large files with the Trestle file picker should not crash - 32bit Modula-3 code may or may not be able to read/write such files - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] files larger than 2gig > Date: Mon, 22 Jun 2009 13:05:13 +0000 > > > Hm..I'm not sure. > Integers have certain properties, like dividing an integer by an integer yields an integer, > that floating point doesn't. Integer division tends toward zero faster than floating point division. > I can try getting it all to compile with LONGINT maybe instead. > The current behavior is pretty lame. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 22 Jun 2009 12:58:17 +0000 >> Subject: [M3devel] files larger than 2gig >> >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >> >> >> TYPE >> Status = RECORD >> type: Type; >> modificationTime: Time.T; >> size: INTEGER; >> END; >> >> >> size: INTEGER causes exceptions when you use the Modula-3 gui >> and browse to a directory with files larger than 2 gig. >> >> >> I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa >> (out 64 bits total) and thus can represent integers very much larger than INTEGER. >> >> >> LONGINT is a tempting option but doesn't help on the current NT386 platform, >> and I think 53 bits will last a very long time. >> >> >> I'm just trying out such a change and I can see it is not source compatible: >> >> >> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >> "../src/rw/FileRd.m3", line 140: types are not assignable >> 2 errors encountered >> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >> 2 errors encountered >> >> >> Nevertheless I think it should be done, probably even for this release. >> >> >> - Jay From jay.krell at cornell.edu Mon Jun 22 15:05:13 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 13:05:13 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Message-ID: Hm..I'm not sure. Integers have certain properties, like dividing an integer by an integer yields an integer, that floating point doesn't. Integer division tends toward zero faster than floating point division. I can try getting it all to compile with LONGINT maybe instead. The current behavior is pretty lame. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 22 Jun 2009 12:58:17 +0000 > Subject: [M3devel] files larger than 2gig > > > C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 > > > TYPE > Status = RECORD > type: Type; > modificationTime: Time.T; > size: INTEGER; > END; > > > size: INTEGER causes exceptions when you use the Modula-3 gui > and browse to a directory with files larger than 2 gig. > > > I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa > (out 64 bits total) and thus can represent integers very much larger than INTEGER. > > > LONGINT is a tempting option but doesn't help on the current NT386 platform, > and I think 53 bits will last a very long time. > > > I'm just trying out such a change and I can see it is not source compatible: > > > "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN > "../src/rw/FileRd.m3", line 140: types are not assignable > 2 errors encountered > "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN > "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX > 2 errors encountered > > > Nevertheless I think it should be done, probably even for this release. > > > - Jay From wagner at elegosoft.com Mon Jun 22 16:30:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Jun 2009 16:30:03 +0200 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Message-ID: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> Quoting Jay : > > C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 > > > TYPE > Status = RECORD > type: Type; > modificationTime: Time.T; > size: INTEGER; > END; > > > size: INTEGER causes exceptions when you use the Modula-3 gui > and browse to a directory with files larger than 2 gig. This is a known limitation on all 32 bit platforms. > I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa > (out 64 bits total) and thus can represent integers very much larger > than INTEGER. I wouldn't like that. Sizes are no real numbers, really ;-) Either use LONGINT or rely on INTEGER being large enough (64 bit on all 64 bit targets). > LONGINT is a tempting option but doesn't help on the current NT386 platform, > and I think 53 bits will last a very long time. What exactly was the problem in makeing LONGINT work on NT386? > I'm just trying out such a change and I can see it is not source compatible: > > > "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN > "../src/rw/FileRd.m3", line 140: types are not assignable > 2 errors encountered > "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN > "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX > 2 errors encountered > > > Nevertheless I think it should be done, probably even for this release. I'm not convinced... 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 Mon Jun 22 17:36:21 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 15:36:21 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> Message-ID: The NT386 backend internally uses a stack of 32bit words to slightly optimize codegen..it seems kind of similar to what the frontend does..I wonder if it is redundant.. Anyway.. It doesn't appear easy to extend, but with years of hindsight at this point..it might be easiest to have a mode where the front end decomposes 64bit operations into multiple 32bit operations. Maybe that'd be an entire "cg layer" (it appears code generators are layerable). I'm less keen on the LONGREAL solution but still pretty keen on LONGINT. Not right now though, maybe in a few days.. - Jay ---------------------------------------- > Date: Mon, 22 Jun 2009 16:30:03 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > Quoting Jay : > >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >> >> >> TYPE >> Status = RECORD >> type: Type; >> modificationTime: Time.T; >> size: INTEGER; >> END; >> >> >> size: INTEGER causes exceptions when you use the Modula-3 gui >> and browse to a directory with files larger than 2 gig. > > This is a known limitation on all 32 bit platforms. > >> I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa >> (out 64 bits total) and thus can represent integers very much larger >> than INTEGER. > > I wouldn't like that. Sizes are no real numbers, really ;-) > Either use LONGINT or rely on INTEGER being large enough (64 bit > on all 64 bit targets). > >> LONGINT is a tempting option but doesn't help on the current NT386 platform, >> and I think 53 bits will last a very long time. > > What exactly was the problem in makeing LONGINT work on NT386? > >> I'm just trying out such a change and I can see it is not source compatible: >> >> >> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >> "../src/rw/FileRd.m3", line 140: types are not assignable >> 2 errors encountered >> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >> 2 errors encountered >> >> >> Nevertheless I think it should be done, probably even for this release. > > I'm not convinced... > > 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 hosking at cs.purdue.edu Mon Jun 22 18:58:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Jun 2009 12:58:45 -0400 Subject: [M3devel] files larger than 2gig In-Reply-To: References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> Message-ID: On 22 Jun 2009, at 11:36, Jay wrote: > > The NT386 backend internally uses a stack of 32bit words to slightly > optimize codegen..it seems kind of similar to what the frontend > does..I wonder if it is redundant.. > Anyway.. > It doesn't appear easy to extend, but with years of hindsight at > this point..it might be easiest to have a mode where the front end > decomposes 64bit operations into multiple 32bit operations. Yuck. Why not decompose in the backend? > Maybe that'd be an entire "cg layer" (it appears code generators are > layerable). > > > I'm less keen on the LONGREAL solution but still pretty keen on > LONGINT. > Not right now though, maybe in a few days.. > > > - Jay > > > ---------------------------------------- >> Date: Mon, 22 Jun 2009 16:30:03 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] files larger than 2gig >> >> Quoting Jay : >> >>> >>> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >>> >>> >>> TYPE >>> Status = RECORD >>> type: Type; >>> modificationTime: Time.T; >>> size: INTEGER; >>> END; >>> >>> >>> size: INTEGER causes exceptions when you use the Modula-3 gui >>> and browse to a directory with files larger than 2 gig. >> >> This is a known limitation on all 32 bit platforms. >> >>> I suggest size be changed to LONGREAL, which generally has a 53 >>> bit mantissa >>> (out 64 bits total) and thus can represent integers very much larger >>> than INTEGER. >> >> I wouldn't like that. Sizes are no real numbers, really ;-) >> Either use LONGINT or rely on INTEGER being large enough (64 bit >> on all 64 bit targets). >> >>> LONGINT is a tempting option but doesn't help on the current NT386 >>> platform, >>> and I think 53 bits will last a very long time. >> >> What exactly was the problem in makeing LONGINT work on NT386? >> >>> I'm just trying out such a change and I can see it is not source >>> compatible: >>> >>> >>> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >>> "../src/rw/FileRd.m3", line 140: types are not assignable >>> 2 errors encountered >>> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >>> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >>> 2 errors encountered >>> >>> >>> Nevertheless I think it should be done, probably even for this >>> release From wagner at elegosoft.com Mon Jun 22 22:31:52 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Jun 2009 22:31:52 +0200 Subject: [M3devel] compilation fails on SunOs Message-ID: <20090622223152.1u5re0mjs4c0osoo@mail.elegosoft.com> Tinderbox cannot compiler m3core on SunOS: 9884 ../src/unix/Common/UtimeC.c: In function `Utime__ctime_r?: 9885 NEXT ../src/unix/Common/UtimeC.c:101: error: too few arguments to function `ctime_r? 9886 compile_c => 1 9887 NEXT C compiler failed compiling: ../src/unix/Common/UtimeC.c 9888 new source -> compiling UnixC.c 9889 new source -> compiling UnixLink.c Please fix, 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 Mon Jun 22 23:50:59 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 21:50:59 +0000 Subject: [M3devel] compilation fails on SunOs In-Reply-To: <20090622223152.1u5re0mjs4c0osoo@mail.elegosoft.com> References: <20090622223152.1u5re0mjs4c0osoo@mail.elegosoft.com> Message-ID: > Please fix, I believe I already did. - Jay ---------------------------------------- > Date: Mon, 22 Jun 2009 22:31:52 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] compilation fails on SunOs > > Tinderbox cannot compiler m3core on SunOS: > > 9884 ../src/unix/Common/UtimeC.c: In function `Utime__ctime_r?: > 9885 NEXT ../src/unix/Common/UtimeC.c:101: error: too few > arguments to function `ctime_r? > 9886 compile_c => 1 > 9887 NEXT C compiler failed compiling: ../src/unix/Common/UtimeC.c > 9888 new source -> compiling UnixC.c > 9889 new source -> compiling UnixLink.c > > Please fix, > > 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 Tue Jun 23 11:52:15 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 23 Jun 2009 02:52:15 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: Your message of "Mon, 22 Jun 2009 13:09:25 -0000." Message-ID: <200906230952.n5N9qFdh081330@camembert.async.caltech.edu> Jay I just want to add that I've written a lot of code that "streams" files greater than 2 GB just fine in Modula-3. The trick, which I learned from Blair MacIntyre's rdwr package, is to reset the pointers periodically: (* $Id: RdWrReset.m3,v 1.1 2008/11/26 18:32:40 mika Exp $ *) MODULE RdWrReset; IMPORT Rd AS R, Wr AS W; IMPORT RdClass, WrClass; <*NOWARN*>IMPORT UnsafeWr, UnsafeRd; (* Since we need to use the Mutex properties of Rd.T and Wr.T, we should actually import UnsafeWr and UnsafeRd. We need to add the following revelations, as the comment in UnsafeRd points out, if we want to include both the Unsafe* and *Class interfaces. *) REVEAL RdClass.Private <: MUTEX; REVEAL WrClass.Private <: MUTEX; PROCEDURE Rd (rd: R.T) = BEGIN LOCK rd DO DEC(rd.cur, rd.lo); DEC(rd.hi, rd.lo); rd.lo := 0; END; END Rd; PROCEDURE Wr (wr: W.T) = BEGIN LOCK wr DO DEC(wr.cur, wr.lo); DEC(wr.hi, wr.lo); wr.lo := 0; END; END Wr; BEGIN END RdWrReset. Jay writes: > >Hm, here is another approach -- leave more code alone, like don't attempt to l >et FileRd/FileWr work on files larger than 2gig on a 32bit system for example. > But do fix the lowest level status record to have either LONGINT or LONGREAL, > preferable LONGREAL for the sake of NT386 (much as I dislike floating point.. >). >That is, an intermediate goal would be: > - browing to a directory with large files with the Trestle file picker should > not crash > - 32bit Modula-3 code may or may not be able to read/write such files > > - Jay > > > >---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: RE: [M3devel] files larger than 2gig >> Date: Mon, 22 Jun 2009 13:05:13 +0000 >> >> >> Hm..I'm not sure. >> Integers have certain properties, like dividing an integer by an integer yie >lds an integer, >> that floating point doesn't. Integer division tends toward zero faster than >floating point division. >> I can try getting it all to compile with LONGINT maybe instead. >> The current behavior is pretty lame. >> >> - Jay >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Mon, 22 Jun 2009 12:58:17 +0000 >>> Subject: [M3devel] files larger than 2gig >>> >>> >>> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >>> >>> >>> TYPE >>> Status = RECORD >>> type: Type; >>> modificationTime: Time.T; >>> size: INTEGER; >>> END; >>> >>> >>> size: INTEGER causes exceptions when you use the Modula-3 gui >>> and browse to a directory with files larger than 2 gig. >>> >>> >>> I suggest size be changed to LONGREAL, which generally has a 53 bit mantiss >a >>> (out 64 bits total) and thus can represent integers very much larger than I >NTEGER. >>> >>> >>> LONGINT is a tempting option but doesn't help on the current NT386 platform >, >>> and I think 53 bits will last a very long time. >>> >>> >>> I'm just trying out such a change and I can see it is not source compatible >: >>> >>> >>> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >>> "../src/rw/FileRd.m3", line 140: types are not assignable >>> 2 errors encountered >>> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >>> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >>> 2 errors encountered >>> >>> >>> Nevertheless I think it should be done, probably even for this release From mika at async.caltech.edu Tue Jun 23 11:54:47 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 23 Jun 2009 02:54:47 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: Your message of "Mon, 22 Jun 2009 13:05:13 -0000." Message-ID: <200906230954.n5N9slnb081383@camembert.async.caltech.edu> Also, making file handling code depend on the presence of IEEE floating point seems rather odd... As far as I know there is nothing in Modula-3 that bans implementing REAL with single precision arithmetic? By the way I think it's sad that Modula-3's wonderful floating-point support has attracted so much bit rot. I think it's better than just about any other programming language (except maybe some Fortran dialects?) Mika Jay writes: > >Hm..I'm not sure. >Integers have certain properties, like dividing an integer by an integer yield >s an integer, >that floating point doesn't. Integer division tends toward zero faster than fl >oating point division. >I can try getting it all to compile with LONGINT maybe instead. >The current behavior is pretty lame. > > - Jay > >---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 22 Jun 2009 12:58:17 +0000 >> Subject: [M3devel] files larger than 2gig >> >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >> >> >> TYPE >> Status = RECORD >> type: Type; >> modificationTime: Time.T; >> size: INTEGER; >> END; >> >> >> size: INTEGER causes exceptions when you use the Modula-3 gui >> and browse to a directory with files larger than 2 gig. >> >> >> I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa >> (out 64 bits total) and thus can represent integers very much larger than IN >TEGER. >> >> >> LONGINT is a tempting option but doesn't help on the current NT386 platform, >> and I think 53 bits will last a very long time. >> >> >> I'm just trying out such a change and I can see it is not source compatible: >> >> >> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >> "../src/rw/FileRd.m3", line 140: types are not assignable >> 2 errors encountered >> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >> 2 errors encountered >> >> >> Nevertheless I think it should be done, probably even for this release. >> >> >> - Jay From jay.krell at cornell.edu Tue Jun 23 13:02:26 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 23 Jun 2009 11:02:26 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <200906230954.n5N9slnb081383@camembert.async.caltech.edu> References: Your message of "Mon, 22 Jun 2009 13:05:13 -0000." <200906230954.n5N9slnb081383@camembert.async.caltech.edu> Message-ID: Every modern system implements IEEE 754 binary floating point in hardware, except maybe for the occasional floating point-less embedded ARM or maybe MIPS, though even still, they tend to support "what I expect" in software (heck, just look at Apple's original 6502 and 68000 IEEE 754 software environments "SANE"). REAL is typically 32 bits. LONGREAL is much more useful, 64 bits total, 53 bits of mantissa. Heck, anything more than 31 bits of mantissa is a win. EXTENDED is the same as LONGREAL. All you have to do to get an unhandled exception is use the file open gui in formedit or such and browse to a directory with a large file. It's quite lame. Granted what Olaf said -- works fine on 64 bit platforms. On later thought, I'm much less keen on LONGREAL here. LONGINT would still be good though. And then trying to fix NT386 to have a 64bit LONGINT. I am not convinced that Modula-3 is or ever was superior here, in implementation. Yeah, they made a bold statement -- here are our portable interfaces, but they weren't available on many platforms. At the same time, most C systems did document various features, usually not very portable, but perhaps the building blocks of something portable. It's just that you have/had to read a lot of documentation, test it out, etc. Someone has to do it as some level. Nothing is free. (Similarly, Modula-3 "portability" lately is greatly aided by Posix/pthreads standard/implementation catching up.) C is getting better here, what with #pragma fenv and such. And again, you could always dig into the system-specific details. The real art that I don't fully understand, is how to specify "portable interfaces" that you "know" will be viable to implement "everywhere". Just what is nearly exactly the same "everywhere" that you know you'll be able to fill in the details later? Maybe it is survey lots of systems?? But, again, "lots" isn't many any longer. Heck, it's basically just Linux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhile, my list still includes Tru64/Alpha, VMS/Alpha, maybe VMS/IA64, AIX/32, AIX/64, IRIX/32, IRIX/64, etc.. to get running... :) ) That is -- really -- we probably should try to implement all that FloatMode stuff. - Jay > To: jay.krell at cornell.edu > Date: Tue, 23 Jun 2009 02:54:47 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > > Also, making file handling code depend on the presence of IEEE floating > point seems rather odd... As far as I know there is nothing in Modula-3 > that bans implementing REAL with single precision arithmetic? > > By the way I think it's sad that Modula-3's wonderful floating-point > support has attracted so much bit rot. I think it's better than just > about any other programming language (except maybe some Fortran > dialects?) > > Mika > > Jay writes: > > > >Hm..I'm not sure. > >Integers have certain properties, like dividing an integer by an integer yield > >s an integer, > >that floating point doesn't. Integer division tends toward zero faster than fl > >oating point division. > >I can try getting it all to compile with LONGINT maybe instead. > >The current behavior is pretty lame. > > > > - Jay > > > >---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 22 Jun 2009 12:58:17 +0000 > >> Subject: [M3devel] files larger than 2gig > >> > >> > >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 > >> > >> > >> TYPE > >> Status = RECORD > >> type: Type; > >> modificationTime: Time.T; > >> size: INTEGER; > >> END; > >> > >> > >> size: INTEGER causes exceptions when you use the Modula-3 gui > >> and browse to a directory with files larger than 2 gig. > >> > >> > >> I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa > >> (out 64 bits total) and thus can represent integers very much larger than IN > >TEGER. > >> > >> > >> LONGINT is a tempting option but doesn't help on the current NT386 platform, > >> and I think 53 bits will last a very long time. > >> > >> > >> I'm just trying out such a change and I can see it is not source compatible: > >> > >> > >> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN > >> "../src/rw/FileRd.m3", line 140: types are not assignable > >> 2 errors encountered > >> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN > >> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX > >> 2 errors encountered > >> > >> > >> Nevertheless I think it should be done, probably even for this release. > >> > >> > >> - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Jun 23 13:20:53 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 23 Jun 2009 04:20:53 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: Your message of "Tue, 23 Jun 2009 11:02:26 -0000." Message-ID: <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> Jay, Just a few comments... I do have some interest in the Modula-3 implementation on the Caltech Mosaic-C (which has no floating point). M3 has run on this before---I have an old M3 compiler for it. More in general, M3 is a very nice language to bring up on new hardware. Requiring the presence of floating point makes that much more difficult. EXTENDED really should not be 64 bits. It should be 80 bits or perhaps (on some archs) 128 bits. On x86 it should definitely be 80 bits, since that is the only precision actually supported by Intel hardware. Not only would the the answers have more bits of precision but the hardware would actually run faster in many cases! (Long double is 80 bits under gcc on my FreeBSDs.) Finally my understanding is that when M3 was developed, Bill Kahan sent over one of his grad students to work on the floating point. That is what all those weird FP interfaces are about. They're not so much about portability as they are about completeness---from the point of view of the person developing numerical methods. If you read Kahan's rants about how FP "should be done" you can see that the M-3 Float interfaces closely follow the rants. I don't think they're expected to work on all hardware, only on systems that have reasonably powerful floating point (IEEE, VAX, System/370?) Mika Jay writes: >--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Every modern system implements IEEE 754 binary floating point in hardware= >=2C except maybe for the occasional floating point-less embedded ARM or may= >be MIPS=2C though even still=2C they tend to support "what I expect" in sof= >tware (heck=2C just look at Apple's original 6502 and 68000 IEEE 754 softwa= >re environments "SANE"). > > >=20 > >REAL is typically 32 bits. > >LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >=2C anything more than 31 bits of mantissa is a win. > >EXTENDED is the same as LONGREAL. > >=20 > >=20 > >All you have to do to get an unhandled exception is use the file open gui i= >n formedit or such and browse to a directory with a large file. It's quite = >lame. > >=20 > >=20 > >Granted what Olaf said -- works fine on 64 bit platforms. > >=20 > >=20 > >On later thought=2C I'm much less keen on LONGREAL here. LONGINT would stil= >l be good though. > >And then trying to fix NT386 to have a 64bit LONGINT. > >=20 > >=20 > >I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >ntation. Yeah=2C they made a bold statement -- here are our portable interf= >aces=2C but they weren't available on many platforms. At the same time=2C m= >ost C systems did document various features=2C usually not very portable=2C= > but perhaps the building blocks of something portable. > >It's just that you have/had to read a lot of documentation=2C test it out= >=2C etc. Someone has to do it as some level. Nothing is free. > >(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >ads standard/implementation catching up.) > >=20 > >=20 > >C is getting better here=2C what with #pragma fenv and such. > >And again=2C you could always dig into the system-specific details. > >=20 > >=20 > >The real art that I don't fully understand=2C is how to specify "portable i= >nterfaces" that you "know" will be viable to implement "everywhere". Just w= >hat is nearly exactly the same "everywhere" that you know you'll be able to= > fill in the details later? Maybe it is survey lots of systems?? > >But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) > >=20 > >=20 > >That is -- really -- we probably should try to implement all that FloatMode= > stuff. > >=20 > > > - Jay > > >=20 >> To: jay.krell at cornell.edu >> Date: Tue=2C 23 Jun 2009 02:54:47 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] files larger than 2gig >>=20 >>=20 >> Also=2C making file handling code depend on the presence of IEEE floating >> point seems rather odd... As far as I know there is nothing in Modula-3 >> that bans implementing REAL with single precision arithmetic? >>=20 >> By the way I think it's sad that Modula-3's wonderful floating-point >> support has attracted so much bit rot. I think it's better than just >> about any other programming language (except maybe some Fortran >> dialects?) >>=20 >> Mika >>=20 >> Jay writes: >> > >> >Hm..I'm not sure. >> >Integers have certain properties=2C like dividing an integer by an integ= >er yield >> >s an integer=2C >> >that floating point doesn't. Integer division tends toward zero faster t= >han fl >> >oating point division. >> >I can try getting it all to compile with LONGINT maybe instead. >> >The current behavior is pretty lame. >> > >> > - Jay >> > >> >---------------------------------------- >> >> From: jay.krell at cornell.edu >> >> To: m3devel at elegosoft.com >> >> Date: Mon=2C 22 Jun 2009 12:58:17 +0000 >> >> Subject: [M3devel] files larger than 2gig >> >> >> >> >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >> >> >> >> >> >> TYPE >> >> Status =3D RECORD >> >> type: Type=3B >> >> modificationTime: Time.T=3B >> >> size: INTEGER=3B >> >> END=3B >> >> >> >> >> >> size: INTEGER causes exceptions when you use the Modula-3 gui >> >> and browse to a directory with files larger than 2 gig. >> >> >> >> >> >> I suggest size be changed to LONGREAL=2C which generally has a 53 bit = >mantissa >> >> (out 64 bits total) and thus can represent integers very much larger t= >han IN >> >TEGER. >> >> >> >> >> >> LONGINT is a tempting option but doesn't help on the current NT386 pla= >tform=2C >> >> and I think 53 bits will last a very long time. >> >> >> >> >> >> I'm just trying out such a change and I can see it is not source compa= >tible: >> >> >> >> >> >> "../src/rw/FileRd.m3"=2C line 73: incompatible argument types: MIN >> >> "../src/rw/FileRd.m3"=2C line 140: types are not assignable >> >> 2 errors encountered >> >> "../src/rw/FileWr.m3"=2C line 87: incompatible argument types: MIN >> >> "../src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >> >> 2 errors encountered >> >> >> >> >> >> Nevertheless I think it should be done=2C probably even for this relea= >se. >> >> >> >> >> >> - Jay > >--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Every modern system implements IEEE 754 binary floating point in hardware= >=2C except maybe for the occasional floating point-less embedded ARM or may= >be MIPS=2C though even still=2C they tend to support "what =3BI expect"= > in software (heck=2C just look at Apple's original 6502 and 68000 IEEE 754= > software environments "SANE").

> =3B
>REAL is typically =3B32 bits.
>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >=2C anything more than 31 bits of mantissa is a win.
>EXTENDED is the same as LONGREAL.
> =3B
> =3B
>All you have to do to get an unhandled exception is use the file open gui i= >n formedit or such and browse to a directory with a large file. It's quite = >lame.
> =3B
> =3B
>Granted what Olaf said -- works fine on 64 bit platforms.
> =3B
> =3B
>On later =3Bthought=2C I'm much less keen on LONGREAL here. LONGINT wou= >ld still be good though.
>And then trying to fix NT386 to have a 64bit LONGINT.
> =3B
> =3B
>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >ntation. Yeah=2C they made a bold statement -- here are our portable interf= >aces=2C but they weren't available on many =3Bplatforms. At the same ti= >me=2C most =3BC systems did document various features=2C usually not ve= >ry portable=2C but perhaps the building blocks of something portable.
>It's just that you have/had to read a lot of documentation=2C test it out= >=2C etc. Someone has to do it as some level. Nothing is free.
>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >ads standard/implementation catching up.)
> =3B
> =3B
>C is getting better here=2C what with #pragma fenv and such.
>And again=2C you could always dig into the system-specific details.
> =3B
> =3B
>The real art that I don't fully understand=2C is how to specify "portable i= >nterfaces" that you "know" will be viable to implement "everywhere". Just w= >hat is nearly exactly the same "everywhere" that you know you'll be able to= > fill in the details later? Maybe it is survey lots of systems??
>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) )
> =3B
> =3B
>That is -- really -- we probably should try to implement all that FloatMode= > stuff.
> =3B
>
 =3B- Jay
>
 =3B
>=3B To: jay.krell at cornell.edu
>=3B Date: Tue=2C 23 = >Jun 2009 02:54:47 -0700
>=3B From: mika at async.caltech.edu
>=3B CC= >: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] files larger than = >2gig
>=3B
>=3B
>=3B Also=2C making file handling code depe= >nd on the presence of IEEE floating
>=3B point seems rather odd... As = >far as I know there is nothing in Modula-3
>=3B that bans implementing= > REAL with single precision arithmetic?
>=3B
>=3B By the way I t= >hink it's sad that Modula-3's wonderful floating-point
>=3B support ha= >s attracted so much bit rot. I think it's better than just
>=3B about = >any other programming language (except maybe some Fortran
>=3B dialect= >s?)
>=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B &g= >t=3B
>=3B >=3BHm..I'm not sure.
>=3B >=3BIntegers have certai= >n properties=2C like dividing an integer by an integer yield
>=3B >= >=3Bs an integer=2C
>=3B >=3Bthat floating point doesn't. Integer div= >ision tends toward zero faster than fl
>=3B >=3Boating point divisio= >n.
>=3B >=3BI can try getting it all to compile with LONGINT maybe i= >nstead.
>=3B >=3BThe current behavior is pretty lame.
>=3B >= >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B---------------= >-------------------------
>=3B >=3B>=3B From: jay.krell at cornell.ed= >u
>=3B >=3B>=3B To: m3devel at elegosoft.com
>=3B >=3B>=3B D= >ate: Mon=2C 22 Jun 2009 12:58:17 +0000
>=3B >=3B>=3B Subject: [M3d= >evel] files larger than 2gig
>=3B >=3B>=3B
>=3B >=3B>=3B<= >BR>>=3B >=3B>=3B C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3>>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B TYPE
= >>=3B >=3B>=3B Status =3D RECORD
>=3B >=3B>=3B type: Type=3B<= >BR>>=3B >=3B>=3B modificationTime: Time.T=3B
>=3B >=3B>=3B s= >ize: INTEGER=3B
>=3B >=3B>=3B END=3B
>=3B >=3B>=3B
>= >=3B >=3B>=3B
>=3B >=3B>=3B size: INTEGER causes exceptions whe= >n you use the Modula-3 gui
>=3B >=3B>=3B and browse to a directory= > with files larger than 2 gig.
>=3B >=3B>=3B
>=3B >=3B>= >=3B
>=3B >=3B>=3B I suggest size be changed to LONGREAL=2C which g= >enerally has a 53 bit mantissa
>=3B >=3B>=3B (out 64 bits total) a= >nd thus can represent integers very much larger than IN
>=3B >=3BTEG= >ER.
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B LO= >NGINT is a tempting option but doesn't help on the current NT386 platform= >=2C
>=3B >=3B>=3B and I think 53 bits will last a very long time.<= >BR>>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B I'm ju= >st trying out such a change and I can see it is not source compatible:
&= >gt=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B "../src/rw= >/FileRd.m3"=2C line 73: incompatible argument types: MIN
>=3B >=3B&g= >t=3B "../src/rw/FileRd.m3"=2C line 140: types are not assignable
>=3B = >>=3B>=3B 2 errors encountered
>=3B >=3B>=3B "../src/rw/FileWr.= >m3"=2C line 87: incompatible argument types: MIN
>=3B >=3B>=3B "..= >/src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX
>=3B = >>=3B>=3B 2 errors encountered
>=3B >=3B>=3B
>=3B >=3B&g= >t=3B
>=3B >=3B>=3B Nevertheless I think it should be done=2C proba= >bly even for this release.
>=3B >=3B>=3B
>=3B >=3B>=3B>>=3B >=3B>=3B - Jay
>= > >--_263ab327-88e7-4d2a-89fb-ad414fed2458_-- From jay.krell at cornell.edu Tue Jun 23 13:27:33 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 23 Jun 2009 11:27:33 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> References: Your message of "Tue, 23 Jun 2009 11:02:26 -0000." <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> Message-ID: Mika, floating point is, for better or worse, deep in Modula-3. I was surprised. The garbage collector uses it. So you'll need software floating point or somesuch. Or maybe you can change the code to use fixed point. Probably not a bad idea. But also Time.T is LONGREAL. Though again, maybe that's dubious. NT has as good time representation. It is 64bit integers, something like measured in 10,000 nanosecond units since 1601. The .NET runtime uses the same unit of precision, but starts at year 0. Time.T splits up easily into Unix seconds + milli or microseconds. Of course, all those 32bit second things are broken. I know the x87 uses 80 bit floating point numbers in hardware, but there is also SSE/SSE2/SSE3/whatever now, that might be different, and faster. You know, they have actual "registers" instead of a register stack. If you have some floating point intensive code, you might try it. More info on the Mosiac-C? I'll search the web. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Tue, 23 Jun 2009 04:20:53 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > Jay, > > Just a few comments... > > I do have some interest in the Modula-3 implementation on the Caltech > Mosaic-C (which has no floating point). M3 has run on this before---I > have an old M3 compiler for it. More in general, M3 is a very nice > language to bring up on new hardware. Requiring the presence of > floating point makes that much more difficult. > > EXTENDED really should not be 64 bits. It should be 80 bits or > perhaps (on some archs) 128 bits. On x86 it should definitely be > 80 bits, since that is the only precision actually supported by > Intel hardware. Not only would the the answers have more bits of > precision but the hardware would actually run faster in many cases! > (Long double is 80 bits under gcc on my FreeBSDs.) > > Finally my understanding is that when M3 was developed, Bill Kahan > sent over one of his grad students to work on the floating point. > That is what all those weird FP interfaces are about. They're not > so much about portability as they are about completeness---from the > point of view of the person developing numerical methods. If you > read Kahan's rants about how FP "should be done" you can see that > the M-3 Float interfaces closely follow the rants. I don't think > they're expected to work on all hardware, only on systems that have > reasonably powerful floating point (IEEE, VAX, System/370?) > > Mika > > > Jay writes: >>--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >>Content-Type: text/plain; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >>Every modern system implements IEEE 754 binary floating point in hardware= >>=2C except maybe for the occasional floating point-less embedded ARM or may= >>be MIPS=2C though even still=2C they tend to support "what I expect" in sof= >>tware (heck=2C just look at Apple's original 6502 and 68000 IEEE 754 softwa= >>re environments "SANE"). >> >> >>=20 >> >>REAL is typically 32 bits. >> >>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >>=2C anything more than 31 bits of mantissa is a win. >> >>EXTENDED is the same as LONGREAL. >> >>=20 >> >>=20 >> >>All you have to do to get an unhandled exception is use the file open gui i= >>n formedit or such and browse to a directory with a large file. It's quite = >>lame. >> >>=20 >> >>=20 >> >>Granted what Olaf said -- works fine on 64 bit platforms. >> >>=20 >> >>=20 >> >>On later thought=2C I'm much less keen on LONGREAL here. LONGINT would stil= >>l be good though. >> >>And then trying to fix NT386 to have a 64bit LONGINT. >> >>=20 >> >>=20 >> >>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >>ntation. Yeah=2C they made a bold statement -- here are our portable interf= >>aces=2C but they weren't available on many platforms. At the same time=2C m= >>ost C systems did document various features=2C usually not very portable=2C= >> but perhaps the building blocks of something portable. >> >>It's just that you have/had to read a lot of documentation=2C test it out= >>=2C etc. Someone has to do it as some level. Nothing is free. >> >>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >>ads standard/implementation catching up.) >> >>=20 >> >>=20 >> >>C is getting better here=2C what with #pragma fenv and such. >> >>And again=2C you could always dig into the system-specific details. >> >>=20 >> >>=20 >> >>The real art that I don't fully understand=2C is how to specify "portable i= >>nterfaces" that you "know" will be viable to implement "everywhere". Just w= >>hat is nearly exactly the same "everywhere" that you know you'll be able to= >> fill in the details later? Maybe it is survey lots of systems?? >> >>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) >> >>=20 >> >>=20 >> >>That is -- really -- we probably should try to implement all that FloatMode= >> stuff. >> >>=20 >> >> >> - Jay >> >> >>=20 >>> To: jay.krell at cornell.edu >>> Date: Tue=2C 23 Jun 2009 02:54:47 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] files larger than 2gig >>>=20 >>>=20 >>> Also=2C making file handling code depend on the presence of IEEE floating >>> point seems rather odd... As far as I know there is nothing in Modula-3 >>> that bans implementing REAL with single precision arithmetic? >>>=20 >>> By the way I think it's sad that Modula-3's wonderful floating-point >>> support has attracted so much bit rot. I think it's better than just >>> about any other programming language (except maybe some Fortran >>> dialects?) >>>=20 >>> Mika >>>=20 >>> Jay writes: >>>> >>>>Hm..I'm not sure. >>>>Integers have certain properties=2C like dividing an integer by an integ= >>er yield >>>>s an integer=2C >>>>that floating point doesn't. Integer division tends toward zero faster t= >>han fl >>>>oating point division. >>>>I can try getting it all to compile with LONGINT maybe instead. >>>>The current behavior is pretty lame. >>>> >>>> - Jay >>>> >>>>---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Mon=2C 22 Jun 2009 12:58:17 +0000 >>>>> Subject: [M3devel] files larger than 2gig >>>>> >>>>> >>>>> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >>>>> >>>>> >>>>> TYPE >>>>> Status =3D RECORD >>>>> type: Type=3B >>>>> modificationTime: Time.T=3B >>>>> size: INTEGER=3B >>>>> END=3B >>>>> >>>>> >>>>> size: INTEGER causes exceptions when you use the Modula-3 gui >>>>> and browse to a directory with files larger than 2 gig. >>>>> >>>>> >>>>> I suggest size be changed to LONGREAL=2C which generally has a 53 bit = >>mantissa >>>>> (out 64 bits total) and thus can represent integers very much larger t= >>han IN >>>>TEGER. >>>>> >>>>> >>>>> LONGINT is a tempting option but doesn't help on the current NT386 pla= >>tform=2C >>>>> and I think 53 bits will last a very long time. >>>>> >>>>> >>>>> I'm just trying out such a change and I can see it is not source compa= >>tible: >>>>> >>>>> >>>>> "../src/rw/FileRd.m3"=2C line 73: incompatible argument types: MIN >>>>> "../src/rw/FileRd.m3"=2C line 140: types are not assignable >>>>> 2 errors encountered >>>>> "../src/rw/FileWr.m3"=2C line 87: incompatible argument types: MIN >>>>> "../src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >>>>> 2 errors encountered >>>>> >>>>> >>>>> Nevertheless I think it should be done=2C probably even for this relea= >>se. >>>>> >>>>> >>>>> - Jay >> >>--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >>Content-Type: text/html; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >>Every modern system implements IEEE 754 binary floating point in hardware= >>=2C except maybe for the occasional floating point-less embedded ARM or may= >>be MIPS=2C though even still=2C they tend to support "what =3BI expect"= >> in software (heck=2C just look at Apple's original 6502 and 68000 IEEE 754= >> software environments "SANE"). >> =3B >>REAL is typically =3B32 bits. >>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >>=2C anything more than 31 bits of mantissa is a win. >>EXTENDED is the same as LONGREAL. >> =3B >> =3B >>All you have to do to get an unhandled exception is use the file open gui i= >>n formedit or such and browse to a directory with a large file. It's quite = >>lame. >> =3B >> =3B >>Granted what Olaf said -- works fine on 64 bit platforms. >> =3B >> =3B >>On later =3Bthought=2C I'm much less keen on LONGREAL here. LONGINT wou= >>ld still be good though. >>And then trying to fix NT386 to have a 64bit LONGINT. >> =3B >> =3B >>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >>ntation. Yeah=2C they made a bold statement -- here are our portable interf= >>aces=2C but they weren't available on many =3Bplatforms. At the same ti= >>me=2C most =3BC systems did document various features=2C usually not ve= >>ry portable=2C but perhaps the building blocks of something portable. >>It's just that you have/had to read a lot of documentation=2C test it out= >>=2C etc. Someone has to do it as some level. Nothing is free. >>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >>ads standard/implementation catching up.) >> =3B >> =3B >>C is getting better here=2C what with #pragma fenv and such. >>And again=2C you could always dig into the system-specific details. >> =3B >> =3B >>The real art that I don't fully understand=2C is how to specify "portable i= >>nterfaces" that you "know" will be viable to implement "everywhere". Just w= >>hat is nearly exactly the same "everywhere" that you know you'll be able to= >> fill in the details later? Maybe it is survey lots of systems?? >>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) >> =3B >> =3B >>That is -- really -- we probably should try to implement all that FloatMode= >> stuff. >> =3B >> =3B- Jay >> =3B >=3B To: jay.krell at cornell.edu >=3B Date: Tue=2C 23 = >>Jun 2009 02:54:47 -0700 >=3B From: mika at async.caltech.edu >=3B CC= >>: m3devel at elegosoft.com >=3B Subject: Re: [M3devel] files larger than = >>2gig >=3B >=3B >=3B Also=2C making file handling code depe= >>nd on the presence of IEEE floating >=3B point seems rather odd... As = >>far as I know there is nothing in Modula-3 >=3B that bans implementing= >> REAL with single precision arithmetic? >=3B >=3B By the way I t= >>hink it's sad that Modula-3's wonderful floating-point >=3B support ha= >>s attracted so much bit rot. I think it's better than just >=3B about = >>any other programming language (except maybe some Fortran >=3B dialect= >>s?) >=3B >=3B Mika >=3B >=3B Jay writes: >=3B &g= >>t=3B >=3B>=3BHm..I'm not sure. >=3B>=3BIntegers have certai= >>n properties=2C like dividing an integer by an integer yield >=3B>= >>=3Bs an integer=2C >=3B>=3Bthat floating point doesn't. Integer div= >>ision tends toward zero faster than fl >=3B>=3Boating point divisio= >>n. >=3B>=3BI can try getting it all to compile with LONGINT maybe i= >>nstead. >=3B>=3BThe current behavior is pretty lame. >=3B>= >>=3B >=3B>=3B - Jay >=3B>=3B >=3B>=3B---------------= >>------------------------- >=3B>=3B>=3B From: jay.krell at cornell.ed= >>u >=3B>=3B>=3B To: m3devel at elegosoft.com >=3B>=3B>=3B D= >>ate: Mon=2C 22 Jun 2009 12:58:17 +0000 >=3B>=3B>=3B Subject: [M3d= >>evel] files larger than 2gig >=3B>=3B>=3B >=3B>=3B>=3B<= >>BR>>=3B>=3B>=3B C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3>>>>=3B>=3B>=3B >=3B>=3B>=3B >=3B>=3B>=3B TYPE = >>>=3B>=3B>=3B Status =3D RECORD >=3B>=3B>=3B type: Type=3B<= >>BR>>=3B>=3B>=3B modificationTime: Time.T=3B >=3B>=3B>=3B s= >>ize: INTEGER=3B >=3B>=3B>=3B END=3B >=3B>=3B>=3B >= >>=3B>=3B>=3B >=3B>=3B>=3B size: INTEGER causes exceptions whe= >>n you use the Modula-3 gui >=3B>=3B>=3B and browse to a directory= >> with files larger than 2 gig. >=3B>=3B>=3B >=3B>=3B>= >>=3B >=3B>=3B>=3B I suggest size be changed to LONGREAL=2C which g= >>enerally has a 53 bit mantissa >=3B>=3B>=3B (out 64 bits total) a= >>nd thus can represent integers very much larger than IN >=3B>=3BTEG= >>ER. >=3B>=3B>=3B >=3B>=3B>=3B >=3B>=3B>=3B LO= >>NGINT is a tempting option but doesn't help on the current NT386 platform= >>=2C >=3B>=3B>=3B and I think 53 bits will last a very long time.<= >>BR>>=3B>=3B>=3B >=3B>=3B>=3B >=3B>=3B>=3B I'm ju= >>st trying out such a change and I can see it is not source compatible: &= >>gt=3B>=3B>=3B >=3B>=3B>=3B >=3B>=3B>=3B "../src/rw= >>/FileRd.m3"=2C line 73: incompatible argument types: MIN >=3B>=3B&g= >>t=3B "../src/rw/FileRd.m3"=2C line 140: types are not assignable >=3B = >>>=3B>=3B 2 errors encountered >=3B>=3B>=3B "../src/rw/FileWr.= >>m3"=2C line 87: incompatible argument types: MIN >=3B>=3B>=3B "..= >>/src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >=3B = >>>=3B>=3B 2 errors encountered >=3B>=3B>=3B >=3B>=3B&g= >>t=3B >=3B>=3B>=3B Nevertheless I think it should be done=2C proba= >>bly even for this release. >=3B>=3B>=3B >=3B>=3B>=3B>>>>=3B>=3B>=3B - Jay >>= >> >>--_263ab327-88e7-4d2a-89fb-ad414fed2458_-- From jay.krell at cornell.edu Tue Jun 23 13:43:11 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 23 Jun 2009 11:43:11 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Your message of "Tue, 23 Jun 2009 11:02:26 -0000." <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> Message-ID: And on that note, here is the status on I386_INTERIX, using a native cm3. :) --- building in I386_INTERIX --- ignoring ../src/m3overrides new source -> compiling SchedulerPosix.i3 Program received signal SIGSEGV, Segmentation fault. 0x00717e52 in ?? () (gdb) bt #0 0x00717e52 in ?? () #1 0x0046e28c in Convert__InternalFromLongFloat () #2 0x0046db4d in Convert__FromExtended () #3 0x004edb03 in M3Buf__PutFloat () #4 0x0062c20a in ReelExpr__GenFPLiteral () #5 0x004991bc in Expr__GenFPLiteral () #6 0x004b5702 in Formal__AddFPTag () #7 0x006f4983 in Value__AddFPTag () #8 0x005cc021 in ProcType__FPrinter () #9 0x006e801a in TypeFP__Visit_SCC () #10 0x006e7daa in TypeFP__FromType () #11 0x006e299d in Type__GlobalUID () #12 0x006eb0a9 in TypeTbl__Put () #13 0x006e2bb5 in Type__Compile () #14 0x006e2b1f in Type__CompileAll () #15 0x0057192f in Module__Compile () #16 0x00527171 in M3Front__DoCompile () #17 0x005266a4 in M3Front__Compile () #18 0x0042cd62 in Builder__RunM3 () #19 0x0042b2a9 in Builder__PushOneM3 () #20 0x0042ae8e in Builder__CompileM3 () #21 0x00429916 in Builder__CompileOne () #22 0x004295b1 in Builder__CompileEverything () #23 0x004254ef in Builder__CompileUnits () #24 0x00423c0e in Builder__BuildLib () #25 0x004f4ac6 in M3Build__DoLibrary () #26 0x005dc1cf in QMachine__DoCall () #27 0x005db078 in QMachine__Eval () #28 0x005e3bad in QMachine () #29 0x005e39e5 in QMachine () #30 0x004f1296 in M3Build () #31 0x004f2da5 in M3Build__DoIncludeDir () #32 0x005dc1cf in QMachine__DoCall () #33 0x005db078 in QMachine__Eval () #34 0x005d9895 in QMachine__Evaluate () #35 0x005f1d8e in Quake__Run () #36 0x004ef4d6 in M3Build__Run () #37 0x0055c172 in Main__DoIt () - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > Date: Tue, 23 Jun 2009 11:27:33 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > > Mika, floating point is, for better or worse, deep in Modula-3. > I was surprised. The garbage collector uses it. > So you'll need software floating point or somesuch. > Or maybe you can change the code to use fixed point. > Probably not a bad idea. > > > But also Time.T is LONGREAL. > Though again, maybe that's dubious. > NT has as good time representation. > It is 64bit integers, something like measured in 10,000 nanosecond > units since 1601. > The .NET runtime uses the same unit of precision, but starts at year 0. > > Time.T splits up easily into Unix seconds + milli or microseconds. > Of course, all those 32bit second things are broken. > > > I know the x87 uses 80 bit floating point numbers in hardware, > but there is also SSE/SSE2/SSE3/whatever now, that might be > different, and faster. > You know, they have actual "registers" instead of a register stack. > If you have some floating point intensive code, you might try it. > > > More info on the Mosiac-C? > I'll search the web. > > - Jay > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Tue, 23 Jun 2009 04:20:53 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] files larger than 2gig >> >> Jay, >> >> Just a few comments... >> >> I do have some interest in the Modula-3 implementation on the Caltech >> Mosaic-C (which has no floating point). M3 has run on this before---I >> have an old M3 compiler for it. More in general, M3 is a very nice >> language to bring up on new hardware. Requiring the presence of >> floating point makes that much more difficult. >> >> EXTENDED really should not be 64 bits. It should be 80 bits or >> perhaps (on some archs) 128 bits. On x86 it should definitely be >> 80 bits, since that is the only precision actually supported by >> Intel hardware. Not only would the the answers have more bits of >> precision but the hardware would actually run faster in many cases! >> (Long double is 80 bits under gcc on my FreeBSDs.) >> >> Finally my understanding is that when M3 was developed, Bill Kahan >> sent over one of his grad students to work on the floating point. >> That is what all those weird FP interfaces are about. They're not >> so much about portability as they are about completeness---from the >> point of view of the person developing numerical methods. If you >> read Kahan's rants about how FP "should be done" you can see that >> the M-3 Float interfaces closely follow the rants. I don't think >> they're expected to work on all hardware, only on systems that have >> reasonably powerful floating point (IEEE, VAX, System/370?) >> >> Mika >> >> >> Jay writes: >>>--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >>>Content-Type: text/plain; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>>Every modern system implements IEEE 754 binary floating point in hardware= >>>=2C except maybe for the occasional floating point-less embedded ARM or may= >>>be MIPS=2C though even still=2C they tend to support "what I expect" in sof= >>>tware (heck=2C just look at Apple's original 6502 and 68000 IEEE 754 softwa= >>>re environments "SANE"). >>> >>> >>>=20 >>> >>>REAL is typically 32 bits. >>> >>>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >>>=2C anything more than 31 bits of mantissa is a win. >>> >>>EXTENDED is the same as LONGREAL. >>> >>>=20 >>> >>>=20 >>> >>>All you have to do to get an unhandled exception is use the file open gui i= >>>n formedit or such and browse to a directory with a large file. It's quite = >>>lame. >>> >>>=20 >>> >>>=20 >>> >>>Granted what Olaf said -- works fine on 64 bit platforms. >>> >>>=20 >>> >>>=20 >>> >>>On later thought=2C I'm much less keen on LONGREAL here. LONGINT would stil= >>>l be good though. >>> >>>And then trying to fix NT386 to have a 64bit LONGINT. >>> >>>=20 >>> >>>=20 >>> >>>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >>>ntation. Yeah=2C they made a bold statement -- here are our portable interf= >>>aces=2C but they weren't available on many platforms. At the same time=2C m= >>>ost C systems did document various features=2C usually not very portable=2C= >>> but perhaps the building blocks of something portable. >>> >>>It's just that you have/had to read a lot of documentation=2C test it out= >>>=2C etc. Someone has to do it as some level. Nothing is free. >>> >>>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >>>ads standard/implementation catching up.) >>> >>>=20 >>> >>>=20 >>> >>>C is getting better here=2C what with #pragma fenv and such. >>> >>>And again=2C you could always dig into the system-specific details. >>> >>>=20 >>> >>>=20 >>> >>>The real art that I don't fully understand=2C is how to specify "portable i= >>>nterfaces" that you "know" will be viable to implement "everywhere". Just w= >>>hat is nearly exactly the same "everywhere" that you know you'll be able to= >>> fill in the details later? Maybe it is survey lots of systems?? >>> >>>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >>>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >>>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >>>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) >>> >>>=20 >>> >>>=20 >>> >>>That is -- really -- we probably should try to implement all that FloatMode= >>> stuff. >>> >>>=20 >>> >>> >>> - Jay >>> >>> >>>=20 >>>> To: jay.krell at cornell.edu >>>> Date: Tue=2C 23 Jun 2009 02:54:47 -0700 >>>> From: mika at async.caltech.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] files larger than 2gig >>>>=20 >>>>=20 >>>> Also=2C making file handling code depend on the presence of IEEE floating >>>> point seems rather odd... As far as I know there is nothing in Modula-3 >>>> that bans implementing REAL with single precision arithmetic? >>>>=20 >>>> By the way I think it's sad that Modula-3's wonderful floating-point >>>> support has attracted so much bit rot. I think it's better than just >>>> about any other programming language (except maybe some Fortran >>>> dialects?) >>>>=20 >>>> Mika >>>>=20 >>>> Jay writes: >>>>> >>>>>Hm..I'm not sure. >>>>>Integers have certain properties=2C like dividing an integer by an integ= >>>er yield >>>>>s an integer=2C >>>>>that floating point doesn't. Integer division tends toward zero faster t= >>>han fl >>>>>oating point division. >>>>>I can try getting it all to compile with LONGINT maybe instead. >>>>>The current behavior is pretty lame. >>>>> >>>>> - Jay >>>>> >>>>>---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: m3devel at elegosoft.com >>>>>> Date: Mon=2C 22 Jun 2009 12:58:17 +0000 >>>>>> Subject: [M3devel] files larger than 2gig >>>>>> >>>>>> >>>>>> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >>>>>> >>>>>> >>>>>> TYPE >>>>>> Status =3D RECORD >>>>>> type: Type=3B >>>>>> modificationTime: Time.T=3B >>>>>> size: INTEGER=3B >>>>>> END=3B >>>>>> >>>>>> >>>>>> size: INTEGER causes exceptions when you use the Modula-3 gui >>>>>> and browse to a directory with files larger than 2 gig. >>>>>> >>>>>> >>>>>> I suggest size be changed to LONGREAL=2C which generally has a 53 bit = >>>mantissa >>>>>> (out 64 bits total) and thus can represent integers very much larger t= >>>han IN >>>>>TEGER. >>>>>> >>>>>> >>>>>> LONGINT is a tempting option but doesn't help on the current NT386 pla= >>>tform=2C >>>>>> and I think 53 bits will last a very long time. >>>>>> >>>>>> >>>>>> I'm just trying out such a change and I can see it is not source compa= >>>tible: >>>>>> >>>>>> >>>>>> "../src/rw/FileRd.m3"=2C line 73: incompatible argument types: MIN >>>>>> "../src/rw/FileRd.m3"=2C line 140: types are not assignable >>>>>> 2 errors encountered >>>>>> "../src/rw/FileWr.m3"=2C line 87: incompatible argument types: MIN >>>>>> "../src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >>>>>> 2 errors encountered >>>>>> >>>>>> >>>>>> Nevertheless I think it should be done=2C probably even for this relea= >>>se. >>>>>> >>>>>> >>>>>> - Jay >>> >>>--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >>>Content-Type: text/html; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>> >>> > > >>> >>> >>>Every modern system implements IEEE 754 binary floating point in hardware= >>>=2C except maybe for the occasional floating point-less embedded ARM or may= >>>be MIPS=2C though even still=2C they tend to support "what =3BI expect"= >>> in software (heck=2C just look at Apple's original 6502 and 68000 IEEE 754= >>> software environments "SANE"). > > >>> =3B > >>>REAL is typically =3B32 bits. > >>>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >>>=2C anything more than 31 bits of mantissa is a win. > >>>EXTENDED is the same as LONGREAL. > >>> =3B > >>> =3B > >>>All you have to do to get an unhandled exception is use the file open gui i= >>>n formedit or such and browse to a directory with a large file. It's quite = >>>lame. > >>> =3B > >>> =3B > >>>Granted what Olaf said -- works fine on 64 bit platforms. > >>> =3B > >>> =3B > >>>On later =3Bthought=2C I'm much less keen on LONGREAL here. LONGINT wou= >>>ld still be good though. > >>>And then trying to fix NT386 to have a 64bit LONGINT. > >>> =3B > >>> =3B > >>>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >>>ntation. Yeah=2C they made a bold statement -- here are our portable interf= >>>aces=2C but they weren't available on many =3Bplatforms. At the same ti= >>>me=2C most =3BC systems did document various features=2C usually not ve= >>>ry portable=2C but perhaps the building blocks of something portable. > >>>It's just that you have/had to read a lot of documentation=2C test it out= >>>=2C etc. Someone has to do it as some level. Nothing is free. > >>>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >>>ads standard/implementation catching up.) > >>> =3B > >>> =3B > >>>C is getting better here=2C what with #pragma fenv and such. > >>>And again=2C you could always dig into the system-specific details. > >>> =3B > >>> =3B > >>>The real art that I don't fully understand=2C is how to specify "portable i= >>>nterfaces" that you "know" will be viable to implement "everywhere". Just w= >>>hat is nearly exactly the same "everywhere" that you know you'll be able to= >>> fill in the details later? Maybe it is survey lots of systems?? > >>>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >>>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >>>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >>>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) > >>> =3B > >>> =3B > >>>That is -- really -- we probably should try to implement all that FloatMode= >>> stuff. > >>> =3B > >>> > =3B- Jay > >>> > =3B >>=3B To: jay.krell at cornell.edu >>=3B Date: Tue=2C 23 = >>>Jun 2009 02:54:47 -0700 >>=3B From: mika at async.caltech.edu >>=3B CC= >>>: m3devel at elegosoft.com >>=3B Subject: Re: [M3devel] files larger than = >>>2gig >>=3B >>=3B >>=3B Also=2C making file handling code depe= >>>nd on the presence of IEEE floating >>=3B point seems rather odd... As = >>>far as I know there is nothing in Modula-3 >>=3B that bans implementing= >>> REAL with single precision arithmetic? >>=3B >>=3B By the way I t= >>>hink it's sad that Modula-3's wonderful floating-point >>=3B support ha= >>>s attracted so much bit rot. I think it's better than just >>=3B about = >>>any other programming language (except maybe some Fortran >>=3B dialect= >>>s?) >>=3B >>=3B Mika >>=3B >>=3B Jay writes: >>=3B &g= >>>t=3B >>=3B>=3BHm..I'm not sure. >>=3B>=3BIntegers have certai= >>>n properties=2C like dividing an integer by an integer yield >>=3B>= >>>=3Bs an integer=2C >>=3B>=3Bthat floating point doesn't. Integer div= >>>ision tends toward zero faster than fl >>=3B>=3Boating point divisio= >>>n. >>=3B>=3BI can try getting it all to compile with LONGINT maybe i= >>>nstead. >>=3B>=3BThe current behavior is pretty lame. >>=3B>= >>>=3B >>=3B>=3B - Jay >>=3B>=3B >>=3B>=3B---------------= >>>------------------------- >>=3B>=3B>=3B From: jay.krell at cornell.ed= >>>u >>=3B>=3B>=3B To: m3devel at elegosoft.com >>=3B>=3B>=3B D= >>>ate: Mon=2C 22 Jun 2009 12:58:17 +0000 >>=3B>=3B>=3B Subject: [M3d= >>>evel] files larger than 2gig >>=3B>=3B>=3B >>=3B>=3B>=3B<= >>>BR>>=3B>=3B>=3B C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3>>>>=3B>=3B>=3B >>=3B>=3B>=3B >>=3B>=3B>=3B TYPE > = >>>>=3B>=3B>=3B Status =3D RECORD >>=3B>=3B>=3B type: Type=3B<= >>>BR>>=3B>=3B>=3B modificationTime: Time.T=3B >>=3B>=3B>=3B s= >>>ize: INTEGER=3B >>=3B>=3B>=3B END=3B >>=3B>=3B>=3B >>= >>>=3B>=3B>=3B >>=3B>=3B>=3B size: INTEGER causes exceptions whe= >>>n you use the Modula-3 gui >>=3B>=3B>=3B and browse to a directory= >>> with files larger than 2 gig. >>=3B>=3B>=3B >>=3B>=3B>= >>>=3B >>=3B>=3B>=3B I suggest size be changed to LONGREAL=2C which g= >>>enerally has a 53 bit mantissa >>=3B>=3B>=3B (out 64 bits total) a= >>>nd thus can represent integers very much larger than IN >>=3B>=3BTEG= >>>ER. >>=3B>=3B>=3B >>=3B>=3B>=3B >>=3B>=3B>=3B LO= >>>NGINT is a tempting option but doesn't help on the current NT386 platform= >>>=2C >>=3B>=3B>=3B and I think 53 bits will last a very long time.<= >>>BR>>=3B>=3B>=3B >>=3B>=3B>=3B >>=3B>=3B>=3B I'm ju= >>>st trying out such a change and I can see it is not source compatible: > &= >>>gt=3B>=3B>=3B >>=3B>=3B>=3B >>=3B>=3B>=3B "../src/rw= >>>/FileRd.m3"=2C line 73: incompatible argument types: MIN >>=3B>=3B&g= >>>t=3B "../src/rw/FileRd.m3"=2C line 140: types are not assignable >>=3B = >>>>=3B>=3B 2 errors encountered >>=3B>=3B>=3B "../src/rw/FileWr.= >>>m3"=2C line 87: incompatible argument types: MIN >>=3B>=3B>=3B "..= >>>/src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >>=3B = >>>>=3B>=3B 2 errors encountered >>=3B>=3B>=3B >>=3B>=3B&g= >>>t=3B >>=3B>=3B>=3B Nevertheless I think it should be done=2C proba= >>>bly even for this release. >>=3B>=3B>=3B >>=3B>=3B>=3B>>>>=3B>=3B>=3B - Jay > >>>= >>> >>>--_263ab327-88e7-4d2a-89fb-ad414fed2458_-- From jay.krell at cornell.edu Wed Jun 24 02:45:56 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 24 Jun 2009 00:45:56 +0000 Subject: [M3devel] permissions on make-dist.sh? Message-ID: C:\dev2\cm3.2\scripts>cvs -z3 commit -m "fewer packages for Interix until/unless X issue is fixed, and cvsup uses utimes; fix name of birch dot instead of perio d" make-dist.sh /usr/cvs/cm3/scripts/make-dist.sh,v <-- make-dist.sh new revision: 1.13; previous revision: 1.12 cvs [commit aborted]: cannot rename file .new.make-dist.sh to make-dist.sh: Perm ission denied fyi: diff -u -r1.12 make-dist.sh --- make-dist.sh 20 Jun 2009 19:23:31 -0000 1.12 +++ make-dist.sh 24 Jun 2009 00:45:14 -0000 @@ -1,7 +1,7 @@ #bash # $Id: make-dist.sh,v 1.12 2009-06-20 19:23:31 jkrell Exp $ -DESTHOST=${DESTHOST:-birch,elegosoft.com} +DESTHOST=${DESTHOST:-birch.elegosoft.com} if [ -n "$ROOT" -a -d "$ROOT" ] ; then sysinfo="$ROOT/scripts/sysinfo.sh" @@ -40,7 +40,12 @@ M3_PORTABLE_RUN_PATH=1 export M3_PORTABLE_RUN_PATH -PKG_COLLECTIONS="devlib m3devtool m3gdb webdev gui anim database cvsup obliq ju no caltech-parser demo tool math game core" + +if [ `uname` = 'Interix' ]; then + PKG_COLLECTIONS="devlib m3devtool webdev obliq caltech-parser tool math game core" +else + PKG_COLLECTIONS="devlib m3devtool m3gdb webdev gui anim database cvsup obliq juno caltech-parser demo tool math game core" +fi DESC_devlib=' Miscellaneous development libraries From jay.krell at cornell.edu Wed Jun 24 03:09:45 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 24 Jun 2009 01:09:45 +0000 Subject: [M3devel] posixish environment on Windows Message-ID: People who want to use cygwin might look into Interix/SFU/SUA instead. It is a free "beer" download for Windows 2000, XP, 2003 and is included as an optional part of 2003R2, Vista, 2008, Win7. It uses the forward slashes people like. It includes gcc. 3.3 and sort of 4.2. (some versions have both, but I think 3.3 is always the default) You can also use Visual C++ with it but I haven't tried that. It includes ksh. bash and many other GNU tools are available. It includes gdb. There is a Visual Studio debugger addin, I also haven't tried that. Most importantly I think, it has an appropriately fast fork, which makes development much faster. Version 3.5 and newer support pthreads. It has .so files, including -rpath. Though maybe not -soname. It doesn't appear to support dlopen/dlsym. I have to check. These last two points are surprising. It appears to not use regular Windows static imports, link -dump -imports doesn't show much. It has an X Window client. For Modula-3 purposes, I get a few unresolved symbols building the GUI stuff, XShm*, so that isn't available (yet?). It has mixed support from various projects. Modula-3 seems to work ok on it, enough to build itself. Hm, the tests have problems, I'll look into that. There are archives on www.opencm3.net/releng. More are being uploaded. - Jay From jay.krell at cornell.edu Wed Jun 24 04:39:35 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 23 Jun 2009 19:39:35 -0700 Subject: [M3devel] X11 in system_libs? In-Reply-To: <20090623144303.F1B6ECC362@birch.elegosoft.com> References: <20090623144303.F1B6ECC362@birch.elegosoft.com> Message-ID: Should a bunch of packages check if ostype is win32 or x11 is in system_libs, else build nothing? - Jay (phone) On Jun 23, 2009, at 4:43 PM, jkrell at elego.de (Jay Krell) wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/06/23 16:43:03 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: I386_INTERIX > > Log message: > remove postgres, odbc, and x11 from SYSTEM_LIBS > at least for postgres and odbc, this causes packages that > use them to "play nice" and build nothing > no such luck for x11 though > > From mika at async.caltech.edu Wed Jun 24 06:34:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 23 Jun 2009 21:34:18 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: Your message of "Tue, 23 Jun 2009 11:27:33 -0000." Message-ID: <200906240434.n5O4YIfX017194@camembert.async.caltech.edu> Jay writes: > ... >I know the x87 uses 80 bit floating point numbers in hardware, >but there is also SSE/SSE2/SSE3/whatever now, that might be >different, and faster. >You know, they have actual "registers" instead of a register stack. >If you have some floating point intensive code, you might try it. > ... I've used SSEn using ifort (Intel Fortran), linking it with Modula-3, quite a bit. Works great. But it has two problems: it is mostly (entirely?) single-precision, and it's not portable, as in, you can compile a binary on one machine and then not run it on another machine that has the same OS and "architecture", e.g., "FreeBSD 5.5 / i386". Really annoying. > >More info on the Mosiac-C? >I'll search the web. > It's old. Well that's why there's a working m3 compiler :-) http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.6294 Mika From wagner at elegosoft.com Wed Jun 24 10:43:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 24 Jun 2009 10:43:27 +0200 Subject: [M3devel] X11 in system_libs? In-Reply-To: References: <20090623144303.F1B6ECC362@birch.elegosoft.com> Message-ID: <20090624104327.2e202q4lwk4ssg4c@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > Should a bunch of packages check if ostype is win32 or x11 is in > system_libs, else build nothing? I wouldn't mind if certain packages check their prerequisites and faile nicely to build if they aren't met, e.g. missing DB or X support. Olaf > - Jay (phone) > > On Jun 23, 2009, at 4:43 PM, jkrell at elego.de (Jay Krell) wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 09/06/23 16:43:03 >> >> Modified files: >> cm3/m3-sys/cminstall/src/config-no-install/: I386_INTERIX >> >> Log message: >> remove postgres, odbc, and x11 from SYSTEM_LIBS >> at least for postgres and odbc, this causes packages that >> use them to "play nice" and build nothing >> no such luck for x11 though >> >> -- 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 Jun 24 04:43:15 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 23 Jun 2009 19:43:15 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Your message of "Tue, 23 Jun 2009 11:02:26 -0000." <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> Message-ID: This is fixed, apparently gcc -fPIC there generates bad code for switch statements...this in C not Modula-3/m3cg. - Jay (phone) On Jun 23, 2009, at 4:43 AM, Jay wrote: > > And on that note, here is the status on I386_INTERIX, using a native > cm3. :) > > > --- building in I386_INTERIX --- > ignoring ../src/m3overrides > new source -> compiling SchedulerPosix.i3 > Program received signal SIGSEGV, Segmentation fault. > 0x00717e52 in ?? () > (gdb) bt > #0 0x00717e52 in ?? () > #1 0x0046e28c in Convert__InternalFromLongFloat () > #2 0x0046db4d in Convert__FromExtended () > #3 0x004edb03 in M3Buf__PutFloat () > #4 0x0062c20a in ReelExpr__GenFPLiteral () > #5 0x004991bc in Expr__GenFPLiteral () > #6 0x004b5702 in Formal__AddFPTag () > #7 0x006f4983 in Value__AddFPTag () > #8 0x005cc021 in ProcType__FPrinter () > #9 0x006e801a in TypeFP__Visit_SCC () > #10 0x006e7daa in TypeFP__FromType () > #11 0x006e299d in Type__GlobalUID () > #12 0x006eb0a9 in TypeTbl__Put () > #13 0x006e2bb5 in Type__Compile () > #14 0x006e2b1f in Type__CompileAll () > #15 0x0057192f in Module__Compile () > #16 0x00527171 in M3Front__DoCompile () > #17 0x005266a4 in M3Front__Compile () > #18 0x0042cd62 in Builder__RunM3 () > #19 0x0042b2a9 in Builder__PushOneM3 () > #20 0x0042ae8e in Builder__CompileM3 () > #21 0x00429916 in Builder__CompileOne () > #22 0x004295b1 in Builder__CompileEverything () > #23 0x004254ef in Builder__CompileUnits () > #24 0x00423c0e in Builder__BuildLib () > #25 0x004f4ac6 in M3Build__DoLibrary () > #26 0x005dc1cf in QMachine__DoCall () > #27 0x005db078 in QMachine__Eval () > #28 0x005e3bad in QMachine () > From rodney.m.bates at cox.net Wed Jun 24 18:18:30 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 24 Jun 2009 11:18:30 -0500 Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress Message-ID: <4A4251D6.60804@cox.net> I have tracked down the problems I have seen with m3gdb on AMD64_LINUX not recognizing object formats to a new section type SHT_GNU_HASH, (and named .gnu.hash), which is present in recent M3-compiled code. It appears to be handled by the more recent binutils that comes in gdb 6.8, but it is not handled by the binutils in gdb 6.4, from which m3gdb is derived. I briefly tried a naive substitution of the new binutils (directory 'bfd') into m3gdb, but some things have moved around and there are build problems finding them. I will work on this more when I get some time. Rodney Bates From jay.krell at cornell.edu Wed Jun 24 19:13:11 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 24 Jun 2009 17:13:11 +0000 Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress In-Reply-To: <4A4251D6.60804@cox.net> References: <4A4251D6.60804@cox.net> Message-ID: You should try using cvs import to upgrade to a newer version, of the entire gdb tree (well, maybe prune it -- testsuites, sim, cpu, intl, etc..) I personally have never done this -- only recently imported the first version of stuff but haven't yet updated anything. - Jay > Date: Wed, 24 Jun 2009 11:18:30 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress > > I have tracked down the problems I have seen with m3gdb on > AMD64_LINUX not recognizing object formats to a new section > type SHT_GNU_HASH, (and named .gnu.hash), which is present > in recent M3-compiled code. It appears to be handled by > the more recent binutils that comes in gdb 6.8, but it is > not handled by the binutils in gdb 6.4, from which m3gdb is > derived. > > I briefly tried a naive substitution of the new binutils > (directory 'bfd') into m3gdb, but some things have moved > around and there are build problems finding them. I will > work on this more when I get some time. > > Rodney Bates -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jun 25 01:10:05 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 24 Jun 2009 19:10:05 -0400 Subject: [M3devel] files larger than 2gig In-Reply-To: References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> Message-ID: <20090624231005.GA32180@topoi.pooq.com> On Mon, Jun 22, 2009 at 12:58:45PM -0400, Tony Hosking wrote: > > Yuck. Why not decompose in the backend? However we do it, large files should "just work" on systems that can handle them. -- hendrik From hendrik at topoi.pooq.com Thu Jun 25 02:06:40 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 24 Jun 2009 20:06:40 -0400 Subject: [M3devel] XML? In-Reply-To: <20090508025825.GC418@topoi.pooq.com> References: <20090507220142.GA32564@topoi.pooq.com> <367599.3562.qm@web24708.mail.ird.yahoo.com> <20090508025825.GC418@topoi.pooq.com> Message-ID: <20090625000640.GB32180@topoi.pooq.com> On Thu, May 07, 2009 at 10:58:25PM -0400, hendrik at topoi.pooq.com wrote: > 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. Looked further. The originally PM3 parser looked way more conplicated than necessary, which I attributed to haveing powerful tools available and showing the off. I decided to do somehting simpler, and XML parsing is a *lot* simpler than that. But I got curious and looked at SGML. (After all, some of the stuff I have to process isn't XML at all, but just plain formatted ASCII text with a few tags in it to indicate italics (where some would use *asterisks*)). And I discovered the following. Superficially, SGML has tags like

which match

. Lots of brackets which have to match up. Kind of like XML. It even has a Data Type Definition like XML's. (In fact XML copied the DTD from SGML for compatibility.) The DTD is obviously useful to screen incoming texts to make sure they satisfy a structural specification demanded by an application. Here the similarity ends. It turns out that in SGML you can leave out tags -- starters or enders, or even *both*, as long as that does not cause ambiguity. And *ambiguity* s interpreted in the context of a DTD, which specifies the grammar of the SGML file. This effectively convert a recursive tree walk into a parsing problem. The need for a DTD effectively means that you have to run a parser generator on DTD before you can start with the actual text. That bit of code from pm3 was pulling out all the heavy tools because it couldn't manage without them! Apparently the world abound in SGML processors readers that get details wrong, perhaps because they don't go about it with enough sophistication. Writing an SGML parser is a significant intellectual effort. Writing an XML parser (without enforcing strict conformance on the parsed documents) is, by comparison, is like falling off a log. -- hendrik From hendrik at topoi.pooq.com Thu Jun 25 15:42:33 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 25 Jun 2009 09:42:33 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618134334.njcom4fusg0ccsws@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Message-ID: <20090625134233.GA1722@topoi.pooq.com> On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >Is it time for me to make another try at installing cm3 from scratch? > >In particular, do you think most of the problems I reported with > >documentation and archives, etc., have been solved? I really want to > >get m3 working on this laptop, but I also want to provide the most > >useful problem reports. > > > >I'm definitely trying to act like a naive user in these installation > >attempts (which means I'm trying to act stupider than I am). > > I've now put some initial release engineering documentation onto > birch, available at > > http://www.opencm3.net/releng Well, I started with that page, assuming that it will be the one Google finds when the release is finally out. I'm continuing to act like a naive user (but I'm probably not naive enough to give the instructions a real test). It seems to have installed, but I'm not sure, because the installer ended with an error message. Here are the gory details. Started from http://www.opencm3.net/releng/ I found the description quite clear. It's still not clear just what packages are in cm3-core and not in cm3-min or why I would want them, but it was clear I wanted to start with cm3-core. For example, is there a UI library in cm3-core? (Oh why is it so hard to cut and paste from the web page to this emacs buffer on my laptop?) cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A beginner with Linux might have difficulty knowing whether to use the .lzma version. Ah! I clicked on the "standard, recommended" link (I hadn't realised it was a link) and found the list of what packages are in the .tgz file. One layout comment -- it consists of a series of sections, each starting with a title and ending with a browse-sources link. Each title needs to look more prominent than the text or the link. At the moment, the link is what stands out. More blank lines between the entries then within them would make them group better. Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz Again, that worked. I do find myseelf wondering it that would be the correct command line if I were uzinng Winzip on Windows, though. (that's wha tthe insstruction seems to say) Next I run ./cminstall /usr/local/cm3 It asks mme whether /home.hendrik/cm3 is to be the root directory for cm3. The naive user doesn't know what that means. Nor do I, for that matter. I'm guessing that it's where to unpack and work during installation, but that it won't be needed later. That I can even deleete the entire /home/hendrik/cm3 directory tree after installation. That in fact when I instll packages later I can download them to, say, /anywhere and install them from /anywhere and they'll still get installed in the proper place. But I don't know. For now, I'll just accept the defaults. Next problem: > Installing CM3 in: /usr/local/cm3 > This may take a few minutes... > > Unexpected problem: cannot list current directory: errno=2 > > Please feel free to contact m3-support at elego.de to troubleshoot this problem. Current directory? That's an uninformative message. Possibly it refers to /usr/local/cm3? Which really doesn't exit yet? Should your instructions say to create it and make sure it has the right write permissions? Noooo. that's not the reason. /usr/local/cm3 has been created. And populated with lots of subdirectories. /usr/local/cm3/bin contains a few executables and lots of other files. It turns out I did have permission to write on /usr/local. I don't know what directory it's referring to. What next? -- hendrik From wagner at elegosoft.com Thu Jun 25 18:52:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 25 Jun 2009 18:52:06 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625134233.GA1722@topoi.pooq.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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> Message-ID: <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: >> Quoting hendrik at topoi.pooq.com: >> >> >Is it time for me to make another try at installing cm3 from scratch? >> >In particular, do you think most of the problems I reported with >> >documentation and archives, etc., have been solved? I really want to >> >get m3 working on this laptop, but I also want to provide the most >> >useful problem reports. >> > >> >I'm definitely trying to act like a naive user in these installation >> >attempts (which means I'm trying to act stupider than I am). >> >> I've now put some initial release engineering documentation onto >> birch, available at >> >> http://www.opencm3.net/releng > > Well, I started with that page, assuming that it will be the one Google > finds when the release is finally out. I'm continuing to act like a > naive user (but I'm probably not naive enough to give the instructions a > real test). > > It seems to have installed, but I'm not sure, because the installer > ended with an error message. Here are the gory details. > > Started from http://www.opencm3.net/releng/ > > I found the description quite clear. It's still not clear just what > packages are in cm3-core and not in cm3-min or why I would want them, > but it was clear I wanted to start with cm3-core. For example, is there > a UI library in cm3-core? > > (Oh why is it so hard to cut and paste from the web page to this emacs > buffer on my laptop?) > cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A > beginner with Linux might have difficulty knowing whether to use the > .lzma version. LINUXLIBC6 along with all lmza archives were created by Jay; I'd rather have limited the available formats. Of course this needs to be documented if we provide .lzma files. > Ah! I clicked on the "standard, recommended" link (I hadn't realised it > was a link) and found the list of what packages are in the .tgz file. > One layout comment -- it consists of a series of sections, each starting > with a title and ending with a browse-sources link. Each title needs to > look more prominent than the text or the link. At the moment, the link > is what stands out. More blank lines between the entries then within > them would make them group better. > > Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz > > Again, that worked. I do find myseelf wondering it that would be the > correct command line if I were uzinng Winzip on Windows, though. > (that's wha tthe insstruction seems to say) No, Winzip of course is a GUI application where you are supposed to point and click with the mouse... > Next I run ./cminstall /usr/local/cm3 > > It asks mme whether /home.hendrik/cm3 is to be the root directory for > cm3. The naive user doesn't know what that means. Nor do I, for that This is strange. cminstall shouldn't ask any questions by default. But as mentioned before, I only built the archives for FreeBSD4 and AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package there? Or am I misunderstanding something here? > matter. I'm guessing that it's where to unpack and work during > installation, but that it won't be needed later. That I can even > deleete the entire /home/hendrik/cm3 directory tree after installation. > That in fact when I instll packages later I can download them to, say, > /anywhere and install them from /anywhere and they'll still get > installed in the proper place. But I don't know. For now, I'll just > accept the defaults. > > Next problem: > >> Installing CM3 in: /usr/local/cm3 >> This may take a few minutes... >> >> Unexpected problem: cannot list current directory: errno=2 I've never seen that. Can you provide the complete installation log? We may also need a system call trace to track this down... >> Please feel free to contact m3-support at elego.de to troubleshoot this > problem. > > Current directory? That's an uninformative message. Possibly it refers > to /usr/local/cm3? Which really doesn't exit yet? Should your > instructions say to create it and make sure it has the right write > permissions? > > Noooo. that's not the reason. /usr/local/cm3 has been created. And > populated with lots of subdirectories. /usr/local/cm3/bin contains a > few executables and lots of other files. It turns out I did have > permission to write on /usr/local. I don't know what directory it's > referring to. Strange. I tried an installation on FreeBSD which succeeded without any problems. > What next? Let's have a look at Install.log and hear what Jay has to say about LINUXLIBC6. Thanks for the feedback, 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 wagner at elegosoft.com Thu Jun 25 19:26:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 25 Jun 2009 19:26:45 +0200 Subject: [M3devel] CM3 Release Engineering Message-ID: <20090625192645.4761owc6s8kk4wko@mail.elegosoft.com> Hi all, in order to start with some serious testing and release engineering, I'd still like to have some more feedback from others, especially on the following topics: o Is the suggested archive set accepted? Should we break up or combine certain archives? Or even provide something much simpler? o Has anybody tested installation of any of these packages? Was it successful? o Has anybody tested Rodney's alternative TEXT implementation? Should we make it the default in this release? o Are there still any known show-stoppers? Crashes, broken functionality etc.? o Should we really provide multiple formats (tar/gzip and lzma)? If we don't need/want to change much, the next steps would be: 1. Some documentation fixes/extensions. 2. Application of an RC1 tag and code freeze (or releng branching; but as said earlier, I'd rather avoid that) 3. Announcement of new release candidates in WWW, news and mailing lists. 4. More extensive installation testing. 5. Fixing of all reported bugs (if there are any ;-) 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 hendrik at topoi.pooq.com Thu Jun 25 19:37:15 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 25 Jun 2009 13:37:15 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625185206.f4lc9vlpckggko4g@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: <20090625173714.GA2324@topoi.pooq.com> On Thu, Jun 25, 2009 at 06:52:06PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: > >> > >>I've now put some initial release engineering documentation onto > >>birch, available at > >> > >> http://www.opencm3.net/releng > > > >Well, I started with that page, assuming that it will be the one Google > >finds when the release is finally out. I'm continuing to act like a > >naive user (but I'm probably not naive enough to give the instructions a > >real test). > > > >It seems to have installed, but I'm not sure, because the installer > >ended with an error message. Here are the gory details. > > > >Started from http://www.opencm3.net/releng/ > > > >I found the description quite clear. It's still not clear just what > >packages are in cm3-core and not in cm3-min or why I would want them, > >but it was clear I wanted to start with cm3-core. For example, is there > >a UI library in cm3-core? > > > >(Oh why is it so hard to cut and paste from the web page to this emacs > >buffer on my laptop?) > > >cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A > >beginner with Linux might have difficulty knowing whether to use the > >.lzma version. > > LINUXLIBC6 along with all lmza archives were created by Jay; > I'd rather have limited the available formats. Of course this needs > to be documented if we provide .lzma files. > > >Ah! I clicked on the "standard, recommended" link (I hadn't realised it > >was a link) and found the list of what packages are in the .tgz file. > >One layout comment -- it consists of a series of sections, each starting > >with a title and ending with a browse-sources link. Each title needs to > >look more prominent than the text or the link. At the moment, the link > >is what stands out. More blank lines between the entries then within > >them would make them group better. > > > >Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz > > > >Again, that worked. I do find myseelf wondering it that would be the > >correct command line if I were uzinng Winzip on Windows, though. > >(that's wha tthe insstruction seems to say) > > No, Winzip of course is a GUI application where you are supposed to > point and click with the mouse... Probably needs rewording. > > >Next I run ./cminstall /usr/local/cm3 > > > >It asks mme whether /home.hendrik/cm3 is to be the root directory for > >cm3. The naive user doesn't know what that means. Nor do I, for that > > This is strange. cminstall shouldn't ask any questions by default. Looking back, it didn't actually ask; it just told me to restart if it was wrong. > But as mentioned before, I only built the archives for FreeBSD4 and > AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package > there? Or am I misunderstanding something here? > > >matter. I'm guessing that it's where to unpack and work during > >installation, but that it won't be needed later. That I can even > >deleete the entire /home/hendrik/cm3 directory tree after installation. > >That in fact when I instll packages later I can download them to, say, > >/anywhere and install them from /anywhere and they'll still get > >installed in the proper place. But I don't know. For now, I'll just > >accept the defaults. > > > >Next problem: > > > >>Installing CM3 in: /usr/local/cm3 > >>This may take a few minutes... > >> > >>Unexpected problem: cannot list current directory: errno=2 > > I've never seen that. Can you provide the complete installation log? > We may also need a system call trace to track this down... > > >>Please feel free to contact m3-support at elego.de to troubleshoot this > >problem. > > > >Current directory? That's an uninformative message. Possibly it refers > >to /usr/local/cm3? Which really doesn't exit yet? Should your > >instructions say to create it and make sure it has the right write > >permissions? > > > >Noooo. that's not the reason. /usr/local/cm3 has been created. And > >populated with lots of subdirectories. /usr/local/cm3/bin contains a > >few executables and lots of other files. It turns out I did have > >permission to write on /usr/local. I don't know what directory it's > >referring to. > > Strange. I tried an installation on FreeBSD which succeeded without > any problems. Evidently there's some directory on FreeBSD that's not so readable in Debian squeeze. What directories is it likely to want to read or write? I could go through them and see if any are missing here. > > >What next? > > Let's have a look at Install.log and hear what Jay has to say about > LINUXLIBC6. cat, cut, and paste into the mailer: hendrik at notlookedfor:~$ cat /usr/local/cm3/Install.log Thank you for using Critical Mass CM3. This program will configure and install the system. cminstall_root is set to /home/hendrik/cm3 If this is not correct, please restart the installer with -root If the installer runs interactively, it will ask you some questions about the locations of programs and libraries. Usually it will display a default inside [], which can be accepted with . If the installer has found several choices, you may cycle through them with `+' or `.' for the next and `-' for the previous one. You may of course also enter a completely different value. Installing CM3 in: /usr/local/cm3 This may take a few minutes... Unexpected problem: cannot list current directory: errno=2 Please feel free to contact m3-support at elego.de to troubleshoot this problem. hendrik at notlookedfor:~$ > > Thanks for the feedback. You're very welcome. For the record, here are a few ls's showing what there *is* now. hendrik at notlookedfor:~$ ls /usr/local bin cm3 etc games include lib man sbin share src stow hendrik at notlookedfor:~$ ls /usr/local/cm3 bin doc elisp examples Install.log lib man pkg hendrik at notlookedfor:~$ ls /usr/local/cm3/*/ /usr/local/cm3/bin/: AMD64_DARWIN Darwin.common m3bundle NT386MINGNU SOLsun AMD64_FREEBSD FreeBSD4 m3cgcat PA32_HPUX SPARC32_LINUX AMD64_LINUX gnuld.common m3cggen PA64_HPUX SPARC64_LINUX ARM_DARWIN HPUX.common MIPS64_OPENBSD PPC32_OPENBSD SPARC64_OPENBSD cm3 I386_DARWIN NetBSD2_i386 PPC_DARWIN SPARC64_SOLARIS cm3.cfg I386_INTERIX NT386 PPC_LINUX Unix.common cm3cfg.common I386_OPENBSD NT386.common Solaris.common cm3cg LINUXLIBC6 NT386GNU SOLgnu /usr/local/cm3/doc/: /usr/local/cm3/elisp/: /usr/local/cm3/examples/: /usr/local/cm3/lib/: libBitVector.so libm3slisp.so libset.so libBitVector.so.5 libm3slisp.so.5 libset.so.5 libDiGraph.so libm3.so libSortedTableExtras.so libDiGraph.so.5 libm3.so.5 libSortedTableExtras.so.5 libGeometry.so libm3tcp.so libsysutils.so libGeometry.so.5 libm3tcp.so.5 libsysutils.so.5 libm3core.so libm3unit.so libtable-list.so libm3core.so.5 libm3unit.so.5 libtable-list.so.5 libm3parseparams.so libpatternmatching.so libTempFiles.so libm3parseparams.so.5 libpatternmatching.so.5 libTempFiles.so.5 /usr/local/cm3/man/: man1 /usr/local/cm3/pkg/: bitvector m3bundle m3linker m3tools slisp tempfiles cm3 m3cgcat m3middle parseparams sortedtableextras unittest digraph m3cggen m3objfile patternmatching sysutils libm3 m3core m3quake realgeometry table-list m3back m3front m3scanner set tcp hendrik at notlookedfor:~$ From jay.krell at cornell.edu Thu Jun 25 22:43:11 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 25 Jun 2009 20:43:11 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625185206.f4lc9vlpckggko4g@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: I just ran ./make-dist.sh. I admit I didn't take the time to test out the archives. lzma I made just via gunzip foo.tgz lzma foo.tar For Interix I cut down the list of collections. It is common for multiple compression formats to be used. lzma often shrinks the files by half, though, oddly, sometimes not at all. lzma admittedly has been superceded xz. I know it is difficult and I'm not helpful here, but we should keep in mind the ideals: apt-get install foo download foo.exe and run it, hit next next next finish download foo.tar.gz, tar xf foo.tar.gz, cd foo, read INSTALL, ./configure, ./make, su, ./make install to measure ourselves by. There's no need for Winzip if we use .zip files, explorer handles them. It is also easy to make self extracting .zip files. And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. - Jay > Date: Thu, 25 Jun 2009 18:52:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > Quoting hendrik at topoi.pooq.com: > > > On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: > >> > >> >Is it time for me to make another try at installing cm3 from scratch? > >> >In particular, do you think most of the problems I reported with > >> >documentation and archives, etc., have been solved? I really want to > >> >get m3 working on this laptop, but I also want to provide the most > >> >useful problem reports. > >> > > >> >I'm definitely trying to act like a naive user in these installation > >> >attempts (which means I'm trying to act stupider than I am). > >> > >> I've now put some initial release engineering documentation onto > >> birch, available at > >> > >> http://www.opencm3.net/releng > > > > Well, I started with that page, assuming that it will be the one Google > > finds when the release is finally out. I'm continuing to act like a > > naive user (but I'm probably not naive enough to give the instructions a > > real test). > > > > It seems to have installed, but I'm not sure, because the installer > > ended with an error message. Here are the gory details. > > > > Started from http://www.opencm3.net/releng/ > > > > I found the description quite clear. It's still not clear just what > > packages are in cm3-core and not in cm3-min or why I would want them, > > but it was clear I wanted to start with cm3-core. For example, is there > > a UI library in cm3-core? > > > > (Oh why is it so hard to cut and paste from the web page to this emacs > > buffer on my laptop?) > > > cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A > > beginner with Linux might have difficulty knowing whether to use the > > .lzma version. > > LINUXLIBC6 along with all lmza archives were created by Jay; > I'd rather have limited the available formats. Of course this needs > to be documented if we provide .lzma files. > > > Ah! I clicked on the "standard, recommended" link (I hadn't realised it > > was a link) and found the list of what packages are in the .tgz file. > > One layout comment -- it consists of a series of sections, each starting > > with a title and ending with a browse-sources link. Each title needs to > > look more prominent than the text or the link. At the moment, the link > > is what stands out. More blank lines between the entries then within > > them would make them group better. > > > > Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz > > > > Again, that worked. I do find myseelf wondering it that would be the > > correct command line if I were uzinng Winzip on Windows, though. > > (that's wha tthe insstruction seems to say) > > No, Winzip of course is a GUI application where you are supposed to > point and click with the mouse... > > > Next I run ./cminstall /usr/local/cm3 > > > > It asks mme whether /home.hendrik/cm3 is to be the root directory for > > cm3. The naive user doesn't know what that means. Nor do I, for that > > This is strange. cminstall shouldn't ask any questions by default. > But as mentioned before, I only built the archives for FreeBSD4 and > AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package > there? Or am I misunderstanding something here? > > > matter. I'm guessing that it's where to unpack and work during > > installation, but that it won't be needed later. That I can even > > deleete the entire /home/hendrik/cm3 directory tree after installation. > > That in fact when I instll packages later I can download them to, say, > > /anywhere and install them from /anywhere and they'll still get > > installed in the proper place. But I don't know. For now, I'll just > > accept the defaults. > > > > Next problem: > > > >> Installing CM3 in: /usr/local/cm3 > >> This may take a few minutes... > >> > >> Unexpected problem: cannot list current directory: errno=2 > > I've never seen that. Can you provide the complete installation log? > We may also need a system call trace to track this down... > > >> Please feel free to contact m3-support at elego.de to troubleshoot this > > problem. > > > > Current directory? That's an uninformative message. Possibly it refers > > to /usr/local/cm3? Which really doesn't exit yet? Should your > > instructions say to create it and make sure it has the right write > > permissions? > > > > Noooo. that's not the reason. /usr/local/cm3 has been created. And > > populated with lots of subdirectories. /usr/local/cm3/bin contains a > > few executables and lots of other files. It turns out I did have > > permission to write on /usr/local. I don't know what directory it's > > referring to. > > Strange. I tried an installation on FreeBSD which succeeded without > any problems. > > > What next? > > Let's have a look at Install.log and hear what Jay has to say about > LINUXLIBC6. > > Thanks for the feedback, > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jun 25 23:27:20 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 25 Jun 2009 17:27:20 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: References: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: <20090625212720.GA2783@topoi.pooq.com> On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: > > I just ran ./make-dist.sh. > I admit I didn't take the time to test out the archives. > lzma I made just via > gunzip foo.tgz > lzma foo.tar No need to apologise. These archives seem to have worked better than the last ones I tried. I'm specifically trying to help you guys make it work by acting like a naive user and reporting what goes wrong or might confuse a naive user. The show-stopper for the naive user in this report was the error message that, as far as I can tell, occurs at the end of installation. If my goal was just to get cm3 working, I'd have accomplished it already, as an experienced user. IN fact, I'm still going to set my $PATH properly to find out if I already have a working cm3 from this installation. The last one I tried a few seeks ago (a version of min) was usable long before I finished the whole installation process. After juat unzipping the archives and cooking up some suitable $PATH entries, I was compiling. But from the instructions I was following, it looked like I had a long way to go yet. Half the problems I'm coming up with are probably infelicities if documentation. Like the 'if' in that sentence that should have been 'of'. > > > For Interix I cut down the list of collections. > > > It is common for multiple compression formats to be used. > lzma often shrinks the files by half, though, oddly, sometimes not at all. > lzma admittedly has been superceded xz. > > > > I know it is difficult and I'm not helpful here, but we should keep in mind the ideals: > > apt-get install foo We still have to get to this point. Only I fink it's cm3 we want, not foo. > > download foo.exe and run it, hit next next next finish > > download foo.tar.gz, tar xf foo.tar.gz, cd foo, read INSTALL, ./configure, ./make, su, ./make install > > > > to measure ourselves by. > > > > There's no need for Winzip if we use .zip files, explorer handles them. That's useful. Unless you're paranoid enough to never let your WIndows machine come near a network. It's an effective way to avoid viruses. > > It is also easy to make self extracting .zip files. > > And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. > > > - Jay > > > > Date: Thu, 25 Jun 2009 18:52:06 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > > > Quoting hendrik at topoi.pooq.com: > > > > > On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: > > >> Quoting hendrik at topoi.pooq.com: > > >> > > >> >Is it time for me to make another try at installing cm3 from scratch? > > >> >In particular, do you think most of the problems I reported with > > >> >documentation and archives, etc., have been solved? I really want to > > >> >get m3 working on this laptop, but I also want to provide the most > > >> >useful problem reports. > > >> > > > >> >I'm definitely trying to act like a naive user in these installation > > >> >attempts (which means I'm trying to act stupider than I am). > > >> > > >> I've now put some initial release engineering documentation onto > > >> birch, available at > > >> > > >> http://www.opencm3.net/releng > > > > > > Well, I started with that page, assuming that it will be the one Google > > > finds when the release is finally out. I'm continuing to act like a > > > naive user (but I'm probably not naive enough to give the instructions a > > > real test). > > > > > > It seems to have installed, but I'm not sure, because the installer > > > ended with an error message. Here are the gory details. > > > > > > Started from http://www.opencm3.net/releng/ > > > > > > I found the description quite clear. It's still not clear just what > > > packages are in cm3-core and not in cm3-min or why I would want them, > > > but it was clear I wanted to start with cm3-core. For example, is there > > > a UI library in cm3-core? > > > > > > (Oh why is it so hard to cut and paste from the web page to this emacs > > > buffer on my laptop?) > > > > > cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A > > > beginner with Linux might have difficulty knowing whether to use the > > > .lzma version. > > > > LINUXLIBC6 along with all lmza archives were created by Jay; > > I'd rather have limited the available formats. Of course this needs > > to be documented if we provide .lzma files. > > > > > Ah! I clicked on the "standard, recommended" link (I hadn't realised it > > > was a link) and found the list of what packages are in the .tgz file. > > > One layout comment -- it consists of a series of sections, each starting > > > with a title and ending with a browse-sources link. Each title needs to > > > look more prominent than the text or the link. At the moment, the link > > > is what stands out. More blank lines between the entries then within > > > them would make them group better. > > > > > > Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz > > > > > > Again, that worked. I do find myseelf wondering it that would be the > > > correct command line if I were uzinng Winzip on Windows, though. > > > (that's wha tthe insstruction seems to say) > > > > No, Winzip of course is a GUI application where you are supposed to > > point and click with the mouse... > > > > > Next I run ./cminstall /usr/local/cm3 > > > > > > It asks mme whether /home.hendrik/cm3 is to be the root directory for > > > cm3. The naive user doesn't know what that means. Nor do I, for that > > > > This is strange. cminstall shouldn't ask any questions by default. > > But as mentioned before, I only built the archives for FreeBSD4 and > > AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package > > there? Or am I misunderstanding something here? > > > > > matter. I'm guessing that it's where to unpack and work during > > > installation, but that it won't be needed later. That I can even > > > deleete the entire /home/hendrik/cm3 directory tree after installation. > > > That in fact when I instll packages later I can download them to, say, > > > /anywhere and install them from /anywhere and they'll still get > > > installed in the proper place. But I don't know. For now, I'll just > > > accept the defaults. > > > > > > Next problem: > > > > > >> Installing CM3 in: /usr/local/cm3 > > >> This may take a few minutes... > > >> > > >> Unexpected problem: cannot list current directory: errno=2 > > > > I've never seen that. Can you provide the complete installation log? > > We may also need a system call trace to track this down... > > > > >> Please feel free to contact m3-support at elego.de to troubleshoot this > > > problem. > > > > > > Current directory? That's an uninformative message. Possibly it refers > > > to /usr/local/cm3? Which really doesn't exit yet? Should your > > > instructions say to create it and make sure it has the right write > > > permissions? > > > > > > Noooo. that's not the reason. /usr/local/cm3 has been created. And > > > populated with lots of subdirectories. /usr/local/cm3/bin contains a > > > few executables and lots of other files. It turns out I did have > > > permission to write on /usr/local. I don't know what directory it's > > > referring to. > > > > Strange. I tried an installation on FreeBSD which succeeded without > > any problems. > > > > > What next? > > > > Let's have a look at Install.log and hear what Jay has to say about > > LINUXLIBC6. > > > > Thanks for the feedback, > > > > 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 Fri Jun 26 01:29:18 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 25 Jun 2009 16:29:18 -0700 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625212720.GA2783@topoi.pooq.com> References: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090625212720.GA2783@topoi.pooq.com> Message-ID: More later but: how about we drop a sh wrapper or symlink in installroot/../bin so $path usually unchanged? And ensure ld_library_path needed on the fewest systems possible. - Jay (phone) On Jun 25, 2009, at 2:27 PM, hendrik at topoi.pooq.com wrote: > On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: >> >> I just ran ./make-dist.sh. >> I admit I didn't take the time to test out the archives. >> lzma I made just via >> gunzip foo.tgz >> lzma foo.tar > > No need to apologise. These archives seem to have worked better than > the last ones I tried. > > I'm specifically trying to help you guys make it work by acting like a > naive user and reporting what goes wrong or might confuse a naive > user. > The show-stopper for the naive user in this report was the error > message > that, as far as I can tell, occurs at the end of installation. > > If my goal was just to get cm3 working, I'd have accomplished it > already, as an experienced user. IN fact, I'm still going to set my > $PATH properly to find out if I already have a working cm3 from this > installation. The last one I tried a few seeks ago (a version of min) > was usable long before I finished the whole installation process. > After > juat unzipping the archives and cooking up some suitable $PATH > entries, > I was compiling. But from the instructions I was following, it looked > like I had a long way to go yet. > > Half the problems I'm coming up with are probably infelicities if > documentation. Like the 'if' in that sentence that should have been > 'of'. > >> >> >> For Interix I cut down the list of collections. >> >> >> It is common for multiple compression formats to be used. >> lzma often shrinks the files by half, though, oddly, sometimes not >> at all. >> lzma admittedly has been superceded xz. >> >> >> >> I know it is difficult and I'm not helpful here, but we should keep >> in mind the ideals: >> >> apt-get install foo > > We still have to get to this point. Only I fink it's cm3 we want, not > foo. > >> >> download foo.exe and run it, hit next next next finish >> >> download foo.tar.gz, tar xf foo.tar.gz, cd foo, read INSTALL, ./ >> configure, ./make, su, ./make install >> >> >> >> to measure ourselves by. >> >> >> >> There's no need for Winzip if we use .zip files, explorer handles >> them. > > That's useful. Unless you're paranoid enough to never let your > WIndows > machine come near a network. It's an effective way to avoid viruses. > >> >> It is also easy to make self extracting .zip files. >> >> And untrusting users can just run unzip on them or rename them >> to .zip and open with Explorer, it's quite nice, except that for >> running, they don't run on many systems. >> >> >> - Jay >> >> >>> Date: Thu, 25 Jun 2009 18:52:06 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: >>> Release engineering) >>> >>> Quoting hendrik at topoi.pooq.com: >>> >>>> On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: >>>>> Quoting hendrik at topoi.pooq.com: >>>>> >>>>>> Is it time for me to make another try at installing cm3 from >>>>>> scratch? >>>>>> In particular, do you think most of the problems I reported with >>>>>> documentation and archives, etc., have been solved? I really >>>>>> want to >>>>>> get m3 working on this laptop, but I also want to provide the >>>>>> most >>>>>> useful problem reports. >>>>>> >>>>>> I'm definitely trying to act like a naive user in these >>>>>> installation >>>>>> attempts (which means I'm trying to act stupider than I am). >>>>> >>>>> I've now put some initial release engineering documentation onto >>>>> birch, available at >>>>> >>>>> http://www.opencm3.net/releng >>>> >>>> Well, I started with that page, assuming that it will be the one >>>> Google >>>> finds when the release is finally out. I'm continuing to act like a >>>> naive user (but I'm probably not naive enough to give the >>>> instructions a >>>> real test). >>>> >>>> It seems to have installed, but I'm not sure, because the installer >>>> ended with an error message. Here are the gory details. >>>> >>>> Started from http://www.opencm3.net/releng/ >>>> >>>> I found the description quite clear. It's still not clear just what >>>> packages are in cm3-core and not in cm3-min or why I would want >>>> them, >>>> but it was clear I wanted to start with cm3-core. For example, is >>>> there >>>> a UI library in cm3-core? >>>> >>>> (Oh why is it so hard to cut and paste from the web page to this >>>> emacs >>>> buffer on my laptop?) >>> >>>> cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a >>>> problem. A >>>> beginner with Linux might have difficulty knowing whether to use >>>> the >>>> .lzma version. >>> >>> LINUXLIBC6 along with all lmza archives were created by Jay; >>> I'd rather have limited the available formats. Of course this needs >>> to be documented if we provide .lzma files. >>> >>>> Ah! I clicked on the "standard, recommended" link (I hadn't >>>> realised it >>>> was a link) and found the list of what packages are in the .tgz >>>> file. >>>> One layout comment -- it consists of a series of sections, each >>>> starting >>>> with a title and ending with a browse-sources link. Each title >>>> needs to >>>> look more prominent than the text or the link. At the moment, the >>>> link >>>> is what stands out. More blank lines between the entries then >>>> within >>>> them would make them group better. >>>> >>>> Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz >>>> >>>> Again, that worked. I do find myseelf wondering it that would be >>>> the >>>> correct command line if I were uzinng Winzip on Windows, though. >>>> (that's wha tthe insstruction seems to say) >>> >>> No, Winzip of course is a GUI application where you are supposed to >>> point and click with the mouse... >>> >>>> Next I run ./cminstall /usr/local/cm3 >>>> >>>> It asks mme whether /home.hendrik/cm3 is to be the root directory >>>> for >>>> cm3. The naive user doesn't know what that means. Nor do I, for >>>> that >>> >>> This is strange. cminstall shouldn't ask any questions by default. >>> But as mentioned before, I only built the archives for FreeBSD4 and >>> AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you >>> package >>> there? Or am I misunderstanding something here? >>> >>>> matter. I'm guessing that it's where to unpack and work during >>>> installation, but that it won't be needed later. That I can even >>>> deleete the entire /home/hendrik/cm3 directory tree after >>>> installation. >>>> That in fact when I instll packages later I can download them to, >>>> say, >>>> /anywhere and install them from /anywhere and they'll still get >>>> installed in the proper place. But I don't know. For now, I'll just >>>> accept the defaults. >>>> >>>> Next problem: >>>> >>>>> Installing CM3 in: /usr/local/cm3 >>>>> This may take a few minutes... >>>>> >>>>> Unexpected problem: cannot list current directory: errno=2 >>> >>> I've never seen that. Can you provide the complete installation log? >>> We may also need a system call trace to track this down... >>> >>>>> Please feel free to contact m3-support at elego.de to troubleshoot >>>>> this >>>> problem. >>>> >>>> Current directory? That's an uninformative message. Possibly it >>>> refers >>>> to /usr/local/cm3? Which really doesn't exit yet? Should your >>>> instructions say to create it and make sure it has the right write >>>> permissions? >>>> >>>> Noooo. that's not the reason. /usr/local/cm3 has been created. And >>>> populated with lots of subdirectories. /usr/local/cm3/bin >>>> contains a >>>> few executables and lots of other files. It turns out I did have >>>> permission to write on /usr/local. I don't know what directory it's >>>> referring to. >>> >>> Strange. I tried an installation on FreeBSD which succeeded without >>> any problems. >>> >>>> What next? >>> >>> Let's have a look at Install.log and hear what Jay has to say about >>> LINUXLIBC6. >>> >>> Thanks for the feedback, >>> >>> 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 Fri Jun 26 08:42:31 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 06:42:31 +0000 Subject: [M3devel] upgrade.sh CFGD code seems wrong/dead? Message-ID: This block in upgrade.sh seems dead, given that nothing sets CFGD. Searching for 'CFGD'... C:\dev2\cm3.2\scripts\upgrade.sh(95): cp -v ${f} ${CFGD}/${b} if [ "${UPGRADE_CM3_CFG}" = "yes" -o "${ret}" != 0 ]; then ( .... I'd like to move the config files to root/bin/config instead of littering bin. Ok? This is one of the few places that is related to that. - Jay From jay.krell at cornell.edu Fri Jun 26 09:04:23 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 07:04:23 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <20090624231005.GA32180@topoi.pooq.com> References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> <20090624231005.GA32180@topoi.pooq.com> Message-ID: ---------------------------------------- > Date: Wed, 24 Jun 2009 19:10:05 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > On Mon, Jun 22, 2009 at 12:58:45PM -0400, Tony Hosking wrote: >> >> Yuck. Why not decompose in the backend? > > However we do it, large files should "just work" on systems that can > handle them. > > -- hendrik It should be LONGINT. I'll try to get to it. It might be a slightly breaking change, depending on where the INTEGER size is exposed. That shouldn't be difficult and will address all but one platform. I'll try to get back to revisiting LONGINT support on NT386. Then it might be interesting, though not easy, to port that backend to more platforms. :) One reason to do all those wierdo ports is to set a bar for what an integrated backend should strive for. :) Or then again again again, a C generator. That way, there'd be a chance of "no more porting work". If the IL was slightly abstracted, we could just generate portable C and release just one portable source-ish package for all platforms. There could still be binary packages for people that don't build from source, but all platforms would just be a C compiler away. - Jay From wagner at elegosoft.com Fri Jun 26 10:01:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 10:01:44 +0200 Subject: [M3devel] upgrade.sh CFGD code seems wrong/dead? In-Reply-To: References: Message-ID: <20090626100144.g3ciia3szocgsws0@mail.elegosoft.com> Quoting Jay : > > This block in upgrade.sh seems dead, given that nothing sets CFGD. > > Searching for 'CFGD'... > C:\dev2\cm3.2\scripts\upgrade.sh(95): cp -v ${f} ${CFGD}/${b} > > > if [ "${UPGRADE_CM3_CFG}" = "yes" -o "${ret}" != 0 ]; then ( > .... > > > I'd like to move the config files to root/bin/config instead of > littering bin. Ok? No. This would just be another directory which does not conform to FSH standards. I already extended cm3 to search for config files in various /etc directories, though that's still untested. I'd prefer that we don't move config files _now_ before the release, but if you want to do it, test it: o move them to cm3/etc o test cm3 with that setup on at least one platform o adapt scripts for regression etc. as you deem necessary o watch tinderbox results and fix again ;-) > > This is one of the few places that is related to that. As for your question above, I cannot say without browsing and grepping the code which I cannot do from here (isolated network); perhaps tonight... 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 wagner at elegosoft.com Fri Jun 26 10:08:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 10:08:54 +0200 Subject: [M3devel] files larger than 2gig In-Reply-To: References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> <20090624231005.GA32180@topoi.pooq.com> Message-ID: <20090626100854.ox2rmkey8o0k4gk4@mail.elegosoft.com> Quoting Jay : > > ---------------------------------------- >> Date: Wed, 24 Jun 2009 19:10:05 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] files larger than 2gig >> >> On Mon, Jun 22, 2009 at 12:58:45PM -0400, Tony Hosking wrote: >>> >>> Yuck. Why not decompose in the backend? >> >> However we do it, large files should "just work" on systems that can >> handle them. >> >> -- hendrik > > > It should be LONGINT. > I'll try to get to it. > It might be a slightly breaking change, depending on where the > INTEGER size is exposed. > > > That shouldn't be difficult and will address all but one platform. > I'll try to get back to revisiting LONGINT support on NT386. > Then it might be interesting, though not easy, to port that backend > to more platforms. :) > One reason to do all those wierdo ports is to set a bar for > what an integrated backend should strive for. :) > Or then again again again, a C generator. That way, there'd be a chance > of "no more porting work". If the IL was slightly abstracted, we could > just generate portable C and release just one > portable source-ish package for all platforms. > There could still be binary packages for people that don't build from source, > but all platforms would just be a C compiler away. It has been done that way in the first SRC compilers. m3make was just a wrapper generating makefiles, and the compiler produced C as an intermediate language. It was found to be rather suboptiomal for various reasons AFAIR: performance of the compiler, performance of the produced code (missing optimizations), missing C standardization (what exactly is portable C???), ... Of course I wouldn't object a C generating backend at all, but we should very carefully compare its benefits with the existing backends before abandoning any of them. 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 Fri Jun 26 10:38:31 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 08:38:31 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625185206.f4lc9vlpckggko4g@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: I tested the LINUXLIBC6 archive and it installed ok, no prompting. I ran it with no parameters -- unlike Henrik. It did mention the current working directory (or its directory, same thing) as the install source, which confused me. Probably as long as system.tgz exists where it expects, it shouldn't say anything. Also, even if the documentation is clear, its good to have as little to document as possible. Be as similar to other "things" as possible so nobody needs the patience to read/understand/learn. There is a time for that, but not when you are "about to make a sale" and user is just trying to get the thing working asap. - Jay ________________________________ > > >> Date: Thu, 25 Jun 2009 18:52:06 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) >> >> Quoting hendrik at topoi.pooq.com: >> >>> Next I run ./cminstall /usr/local/cm3 >>> >>> It asks mme whether /home.hendrik/cm3 is to be the root directory for >>> cm3. The naive user doesn't know what that means. Nor do I, for that >> >> This is strange. cminstall shouldn't ask any questions by default. >> But as mentioned before, I only built the archives for FreeBSD4 and >> AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package >> there? Or am I misunderstanding something here? >> >> From jay.krell at cornell.edu Fri Jun 26 11:00:22 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 09:00:22 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <20090626100854.ox2rmkey8o0k4gk4@mail.elegosoft.com> References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> <20090624231005.GA32180@topoi.pooq.com> <20090626100854.ox2rmkey8o0k4gk4@mail.elegosoft.com> Message-ID: > what exactly is portable C??? It may be a little bit elusive, but I think it is certainly possible. Think of how many packages out there that you just download, extract, configure, and make. Think of how much or how little per-system was put into them. Think of how much or how little configure (autoconf) does, and how applicable it is to CM3. > performance of the compiler > performance of the produced code (missing > optimizations) Understood the compiler would be slow. It is slow already, but this would likely be worse. It should be possible to still get reasonable optimization but I don't really know. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 10:08:54 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > Quoting Jay : > >> >> ---------------------------------------- >>> Date: Wed, 24 Jun 2009 19:10:05 -0400 >>> From: hendrik at topoi.pooq.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] files larger than 2gig >>> >>> On Mon, Jun 22, 2009 at 12:58:45PM -0400, Tony Hosking wrote: >>>> >>>> Yuck. Why not decompose in the backend? >>> >>> However we do it, large files should "just work" on systems that can >>> handle them. >>> >>> -- hendrik >> >> >> It should be LONGINT. >> I'll try to get to it. >> It might be a slightly breaking change, depending on where the >> INTEGER size is exposed. >> >> >> That shouldn't be difficult and will address all but one platform. >> I'll try to get back to revisiting LONGINT support on NT386. >> Then it might be interesting, though not easy, to port that backend >> to more platforms. :) >> One reason to do all those wierdo ports is to set a bar for >> what an integrated backend should strive for. :) >> Or then again again again, a C generator. That way, there'd be a chance >> of "no more porting work". If the IL was slightly abstracted, we could >> just generate portable C and release just one >> portable source-ish package for all platforms. >> There could still be binary packages for people that don't build from source, >> but all platforms would just be a C compiler away. > > It has been done that way in the first SRC compilers. m3make was just > a wrapper generating makefiles, and the compiler produced C as an intermediate > language. It was found to be rather suboptiomal for various reasons AFAIR: > performance of the compiler, performance of the produced code (missing > optimizations), missing C standardization (what exactly is portable C???), ... > > Of course I wouldn't object a C generating backend at all, but we should > very carefully compare its benefits with the existing backends before > abandoning any of them. > > 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 Fri Jun 26 11:01:51 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 09:01:51 +0000 Subject: [M3devel] upgrade.sh CFGD code seems wrong/dead? In-Reply-To: <20090626100144.g3ciia3szocgsws0@mail.elegosoft.com> References: <20090626100144.g3ciia3szocgsws0@mail.elegosoft.com> Message-ID: I don't think the FHS matters here. I don't want to get too far into the business of supporting people (even admins) editing these files. Nor do I want to avoid overwriting or merging their changes for later releases. Ideally, people should be as quick to edit cm3.cfg as they are to edit any bash/perl/python in /usr or to rebuild cm3 from source. But that might not be possible. There might also be decisions for which one size does not fit all. It is easy to see that. What cminstall used to prompt about are some where user /might/ want a different choice, but which there are also defaults that suit the majority of folks. It is a little unclear. Like, if postgres/odbc are in the location used by the platform's port/package system, or did user get "upstream directly" and it went in a different default like /usr/local? Or do they have a custom install location? Like, if they want to run a particular gcc by full path, or if the first in $PATH is what they want? First in $PATH is certainly very common, but so are other options, like gcc-version. I guess, ideally, more of the code is moved into cm3, leaving cm3.cfg really only for things people can edit freely. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 10:01:44 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: upgrade.sh CFGD code seems wrong/dead? > > Quoting Jay : > >> >> This block in upgrade.sh seems dead, given that nothing sets CFGD. >> >> Searching for 'CFGD'... >> C:\dev2\cm3.2\scripts\upgrade.sh(95): cp -v ${f} ${CFGD}/${b} >> >> >> if [ "${UPGRADE_CM3_CFG}" = "yes" -o "${ret}" != 0 ]; then ( >> .... >> >> >> I'd like to move the config files to root/bin/config instead of >> littering bin. Ok? > > No. This would just be another directory which does not conform to > FSH standards. I already extended cm3 to search for config files > in various /etc directories, though that's still untested. > > I'd prefer that we don't move config files _now_ before the release, > but if you want to do it, test it: > > o move them to cm3/etc > o test cm3 with that setup on at least one platform > o adapt scripts for regression etc. as you deem necessary > o watch tinderbox results and fix again ;-) > >> >> This is one of the few places that is related to that. > > As for your question above, I cannot say without browsing and grepping > the code which I cannot do from here (isolated network); perhaps tonight... > > 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 wagner at elegosoft.com Fri Jun 26 12:05:51 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 12:05:51 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: 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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> Quoting Jay : > > I tested the LINUXLIBC6 archive and it installed ok, no prompting. > > I ran it with no parameters -- unlike Henrik. It did mention the > current working directory (or its directory, same thing) as the > install source, which confused me. Probably as long as system.tgz > exists where it expects, it shouldn't say anything. Strange. Hendrik, can you reproduce the strange message? And then perhaps provide a system call trace (ktrace, truss, whatever)? Olaf > Also, even if the documentation is clear, its good to have as little > to document as possible. > Be as similar to other "things" as possible so nobody needs the > patience to read/understand/learn. > There is a time for that, but not when you are "about to make a > sale" and user is just trying to get the thing working asap. > > > - Jay > > > ________________________________ >> >> >>> Date: Thu, 25 Jun 2009 18:52:06 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: >>> Release engineering) >>> >>> Quoting hendrik at topoi.pooq.com: >>> >>>> Next I run ./cminstall /usr/local/cm3 >>>> >>>> It asks mme whether /home.hendrik/cm3 is to be the root directory for >>>> cm3. The naive user doesn't know what that means. Nor do I, for that >>> >>> This is strange. cminstall shouldn't ask any questions by default. >>> But as mentioned before, I only built the archives for FreeBSD4 and >>> AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package >>> there? Or am I misunderstanding something here? >>> > >>> -- 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 Fri Jun 26 12:08:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 12:08:47 +0200 Subject: [M3devel] files larger than 2gig In-Reply-To: References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> <20090624231005.GA32180@topoi.pooq.com> <20090626100854.ox2rmkey8o0k4gk4@mail.elegosoft.com> Message-ID: <20090626120847.4i11xyq5es4ggcg4@mail.elegosoft.com> Quoting Jay : > >> what exactly is portable C??? > > > It may be a little bit elusive, but I think it is certainly possible. > Think of how many packages out there that you just download, extract, > configure, I wasn't aware that configure is now part of the C standards ;-) > and make. Think of how much or how little per-system > was put into them. Think of how much or how little configure (autoconf) does, > and how applicable it is to CM3. -- 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 Fri Jun 26 14:00:11 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 12:00:11 +0000 Subject: [M3devel] archive bloat Message-ID: Olaf I think you should trim the archives more. They have lots of intermediate files used to build cm3cg, including the identical copy m3cgc1, various static libraries, etc. I also don't see the utility of the Modula-3 standalone libraries for which we include what they built into, e.g. libm3back.a, libm3objfile.a, libm3front.a, libm3quake.a. I'm also not sure what all the CVS files end up doing. Do the make a checkout go fast? But surely..they are slightly wrong? I realize now that the reason lzma didn't always help is because the archives contain system.tgz. - Jay From wagner at elegosoft.com Fri Jun 26 14:18:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 14:18:49 +0200 Subject: [M3devel] archive bloat In-Reply-To: References: Message-ID: <20090626141849.mw5uo0zahw4k80og@mail.elegosoft.com> Quoting Jay : > > Olaf I think you should trim the archives more. They have lots of > intermediate files used to build cm3cg, including the identical copy > m3cgc1, various static libraries, etc. That's because the archives are simply pre-built workspace parts. > I also don't see the utility of the Modula-3 standalone libraries > for which we include what they built into, e.g. libm3back.a, > libm3objfile.a, libm3front.a, libm3quake.a. These are surely needed for shipping. > I'm also not sure what all the CVS files end up doing. > Do the make a checkout go fast? > But surely..they are slightly wrong? It's the CVS meta information; we can prune that if necessary. A generic way to prune the bin-ws archives would be to remove everything that's not relevant for shipping, i.e. contained in .M3SHIP. I'll have a look at that later. > I realize now that the reason lzma didn't always help is because the > archives contain system.tgz. 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 Fri Jun 26 14:29:19 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 12:29:19 +0000 Subject: [M3devel] archive bloat In-Reply-To: <20090626141849.mw5uo0zahw4k80og@mail.elegosoft.com> References: <20090626141849.mw5uo0zahw4k80og@mail.elegosoft.com> Message-ID: > These are surely needed for shipping. They are not. shipping doesn't require shipping dependencies. Only building does. And building has already occured. Shipping cm3 doesn't do much anyway. It ships the man page, ok. And it ships the binary to a place other than where it is used, because cm3 is special. I checked, the following works: I already have a full enough package store. cd m3-sys/cm3 cm3 cm3 -ship rm -rf /cm3/pkg/m3front /cm3/pkg/middle /cm3/pkg/m3quake cm3 -ship > That's because the archives are simply pre-built workspace parts. Still... What do we gain by shipping the non-source part of the workspace? People can do incremental builds? In the future, if the package build / install split is earlier, it could ease cross packaging, but currently? Packaging the source with each architecture is wasteful, but it does address version skew. The binaries come with matching source. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 14:18:49 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] archive bloat > > Quoting Jay : > >> >> Olaf I think you should trim the archives more. They have lots of >> intermediate files used to build cm3cg, including the identical copy >> m3cgc1, various static libraries, etc. > > That's because the archives are simply pre-built workspace parts. > >> I also don't see the utility of the Modula-3 standalone libraries >> for which we include what they built into, e.g. libm3back.a, >> libm3objfile.a, libm3front.a, libm3quake.a. > > These are surely needed for shipping. > >> I'm also not sure what all the CVS files end up doing. >> Do the make a checkout go fast? >> But surely..they are slightly wrong? > > It's the CVS meta information; we can prune that if necessary. > > A generic way to prune the bin-ws archives would be to remove > everything that's not relevant for shipping, i.e. contained in > .M3SHIP. I'll have a look at that later. > >> I realize now that the reason lzma didn't always help is because the >> archives contain system.tgz. > > 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 Jun 26 14:38:28 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 26 Jun 2009 05:38:28 -0700 Subject: [M3devel] archive bloat In-Reply-To: Your message of "Fri, 26 Jun 2009 12:29:19 -0000." Message-ID: <200906261238.n5QCcSCv026471@camembert.async.caltech.edu> Woudln't not including libm3back.a (e.g.) be a special case? What if I write another program, call it "cm4", that imports the m3back package... what does it link against? Mika Jay writes: > >> These are surely needed for shipping. > >They are not. >shipping doesn't require shipping dependencies. Only building does. And buildi >ng has already occured. >Shipping cm3 doesn't do much anyway. It ships the man page, ok. And it ships t >he binary to a place other than where it is used, because cm3 is special. > >I checked, the following works: > > I already have a full enough package store. > cd m3-sys/cm3 > cm3 > cm3 -ship > rm -rf /cm3/pkg/m3front /cm3/pkg/middle /cm3/pkg/m3quake > cm3 -ship > >> That's because the archives are simply pre-built workspace parts. > >Still... > >What do we gain by shipping the non-source part of the workspace? >People can do incremental builds? >In the future, if the package build / install split is earlier, it could ease >cross packaging, but currently? > > >Packaging the source with each architecture is wasteful, but it does address v >ersion skew. >The binaries come with matching source. > > > - Jay > > >---------------------------------------- >> Date: Fri, 26 Jun 2009 14:18:49 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] archive bloat >> >> Quoting Jay : >> >>> >>> Olaf I think you should trim the archives more. They have lots of >>> intermediate files used to build cm3cg, including the identical copy >>> m3cgc1, various static libraries, etc. >> >> That's because the archives are simply pre-built workspace parts. >> >>> I also don't see the utility of the Modula-3 standalone libraries >>> for which we include what they built into, e.g. libm3back.a, >>> libm3objfile.a, libm3front.a, libm3quake.a. >> >> These are surely needed for shipping. >> >>> I'm also not sure what all the CVS files end up doing. >>> Do the make a checkout go fast? >>> But surely..they are slightly wrong? >> > It's the CVS meta information; we can prune that if necessary. >> >> A generic way to prune the bin-ws archives would be to remove >> everything that's not relevant for shipping, i.e. contained in >> .M3SHIP. I'll have a look at that later. >> >>> I realize now that the reason lzma didn't always help is because the >>> archives contain system.tgz. >> >> 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 Jun 26 14:53:15 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 26 Jun 2009 05:53:15 -0700 Subject: [M3devel] archive bloat In-Reply-To: Your message of "Fri, 26 Jun 2009 12:47:24 -0000." Message-ID: <200906261253.n5QCrFcW027024@camembert.async.caltech.edu> I'm just saying, what you're proposing is an exception to how Modula-3 works. When you make a package and ship it, you always ship it with both interface and library files. Is it really warranted making a special exception for m3back, m3front, m3quake? Besides, how are you going to re-use the m3back package unless you add "cm4" to the main compiler distribution? I want to be able to maintain my own software separately from the CM3 distribution...and then you have to keep the sources around, too? Hrmph.... Mika Jay writes: > >Is it really meant to be reusable by anything other than cm3? >Even still, the workspace includes all the source. You can just build it if yo >u really need it. > > - Jay > > >---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Fri, 26 Jun 2009 05:38:28 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] archive bloat >> >> Woudln't not including libm3back.a (e.g.) be a special case? >> >> What if I write another program, call it "cm4", that imports the >> m3back package... what does it link against? >> >> Mika From jay.krell at cornell.edu Fri Jun 26 14:47:24 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 12:47:24 +0000 Subject: [M3devel] archive bloat In-Reply-To: <200906261238.n5QCcSCv026471@camembert.async.caltech.edu> References: Your message of "Fri, 26 Jun 2009 12:29:19 -0000." <200906261238.n5QCcSCv026471@camembert.async.caltech.edu> Message-ID: Is it really meant to be reusable by anything other than cm3? Even still, the workspace includes all the source. You can just build it if you really need it. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Fri, 26 Jun 2009 05:38:28 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] archive bloat > > Woudln't not including libm3back.a (e.g.) be a special case? > > What if I write another program, call it "cm4", that imports the > m3back package... what does it link against? > > Mika From jay.krell at cornell.edu Fri Jun 26 15:21:06 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 13:21:06 +0000 Subject: [M3devel] archive bloat In-Reply-To: <200906261253.n5QCrFcW027024@camembert.async.caltech.edu> References: Your message of "Fri, 26 Jun 2009 12:47:24 -0000." <200906261253.n5QCrFcW027024@camembert.async.caltech.edu> Message-ID: I guess even m3quake is maybe reusable, for anyone who wants to implement that scripting language. And I like the notion contrary to your point that all the Modula-3 source is together. It makes for easier/better testing, and more flexibility to change things. I was really just looking around for why the new archives are so large. The new core archive is twice the size of the old std. It includes source, probably even three copies of gcc. There is /some/ reason for that, and two of the copies are minimized, though still fairly unnecessary -- I386_INTERIX and ARM_DARWIN each have their own fork of gcc, a decision I remain comfortable with, but not clearly worth making so many more copies of. Compare http://modula3.elegosoft.com/cm3/uploaded-archives/index.html to http://www.opencm3.net/releng/ core in releng is twice the size or more of std in uploaded. I realize it is somewhat apples to oranges, but the uploaded archives I think (I'm checking..) do actually have source, for debugging, in the package store, and even these not very useful static libs. I guess the gcc stuff is the real difference. There is an option to have ship not ship the source actually, for further size savings, but then debugging suffers -- it'd be cool if the binaries contained CVS paths and versions and gdb could just get the source on-demand, as long as you are on the network.. Both sets also have symbols. There is a practise of stripping out the symbols into separate packages, at least on GNU systems (gcc/ld/gdb), but I haven't looked into it and the convenience for debugging of keeping the symbols in the binary seems significant. So far I've chosen to keep that. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Fri, 26 Jun 2009 05:53:15 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] archive bloat > > > I'm just saying, what you're proposing is an exception to how Modula-3 > works. When you make a package and ship it, you always ship it with > both interface and library files. Is it really warranted making a special > exception for m3back, m3front, m3quake? > > Besides, how are you going to re-use the m3back package unless you > add "cm4" to the main compiler distribution? I want to be able to > maintain my own software separately from the CM3 distribution...and > then you have to keep the sources around, too? Hrmph.... > > Mika > > Jay writes: >> >>Is it really meant to be reusable by anything other than cm3? >>Even still, the workspace includes all the source. You can just build it if yo >>u really need it. >> >> - Jay >> >> >>---------------------------------------- >>> To: jay.krell at cornell.edu >>> Date: Fri, 26 Jun 2009 05:38:28 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] archive bloat >>> >>> Woudln't not including libm3back.a (e.g.) be a special case? >>> >>> What if I write another program, call it "cm4", that imports the >>> m3back package... what does it link against? >>> >>> Mika From jay.krell at cornell.edu Fri Jun 26 15:32:22 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 13:32:22 +0000 Subject: [M3devel] dead links Message-ID: http://www.opencm3.net/doc/help/gen_html/dirfp/INDEX.html and surely all the rest contain links to CVS files, of suspicious utility, that are actually dead. http://www.opencm3.net/releng/collection-core.html The links there to browse source don't work, er, at least specifically the first three -- m3core, m3cc, import-libs. Several others do work. Some have the CVS files, some don't. There are some unusual manual page links..which aren't exactly broken, but oddly placed and inconsistent. "Some Useful odula-3 Interfaces" is missing the M in Modula-3 (still in collection-core.html). The first link in: http://www.opencm3.net/releng/collection-obliq.html doesn't work, to polymtl. Much more to check, there's a lot of new stuff and/or stuff I've never looked at... - Jay From jay.krell at cornell.edu Fri Jun 26 15:38:54 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 13:38:54 +0000 Subject: [M3devel] suggest auto detect client architecture in web page Message-ID: You know how you go to the Firefox download page and it offers you "only" the right download for your machine, and then has a link for other systems or older versions? That'd be nice. It's presumably "just a little bit of jscript to sniff the agent string". At the least, the list of systems should link down to their files. But just hiding the whole thing like Firefox et. al. I think is much preferred. I finally found simple documentation about building Debian packages, that doesn't get bogged down in all the source building apparatus. So I'll very maybe do something there, like integrate it into make-dist.sh. You don't even need any special tools, just tar, gzip, and ar. It's so easy, for a minimal not exactly officially good enough package, I can explain it in a few sentences and it'll take very little code. - Jay From hendrik at topoi.pooq.com Fri Jun 26 17:06:45 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 26 Jun 2009 11:06:45 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: References: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: <20090626150644.GA4554@topoi.pooq.com> On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: > > There's no need for Winzip if we use .zip files, explorer handles them. > > It is also easy to make self extracting .zip files. That's the way to go -- it's the popular archive format for Windows, security be damned! > > And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. > > > - Jay From hendrik at topoi.pooq.com Fri Jun 26 17:12:38 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 26 Jun 2009 11:12:38 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> References: <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> Message-ID: <20090626151238.GB4554@topoi.pooq.com> On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: > Quoting Jay : > > > > >I tested the LINUXLIBC6 archive and it installed ok, no prompting. > > > >I ran it with no parameters -- unlike Henrik. It did mention the > >current working directory (or its directory, same thing) as the > >install source, which confused me. Probably as long as system.tgz > >exists where it expects, it shouldn't say anything. > > Strange. > > Hendrik, can you reproduce the strange message? And then perhaps > provide a system call trace (ktrace, truss, whatever)? > > Olaf I'll try. I'll probably have to rm -r /user/local/cm3 first. Anything else I need to watch out for? Now that I think of resetting ... I still had the old cm3-min unpacked somewhere else, and I add its bin directory to the $PATH on a bash startup. Could that have be affecting the results? -- hendrik From hendrik at topoi.pooq.com Fri Jun 26 17:17:07 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 26 Jun 2009 11:17:07 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: References: <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626150644.GA4554@topoi.pooq.com> Message-ID: <20090626151707.GC4554@topoi.pooq.com> On Fri, Jun 26, 2009 at 03:19:44PM +0000, Jay wrote: > > Security not be damned. > You can sign executables. > You can open them in winzip instead if you want (if they are self extracting .zips). True. But most of the WIndows users I know just execute them. Their problem. not ours. If ours executes properly, that is. > Where is the line between running the installer vs. running the code > it installs, anyway? The disaster is faster. There's less time for antivirus tools to detect trouble. But let's not start a long thread about how to make Wiondows secure. Not our job. > I guess the installer runs maybe privileged and its payload does not. > But that isn't required for cm3, you can install to $HOME. > People also often just distribute non-self-running .MSI files. > That would be a good option. > > - Jay > > > ---------------------------------------- > > Date: Fri, 26 Jun 2009 11:06:45 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > > > On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: > >> > >> There's no need for Winzip if we use .zip files, explorer handles them. > >> > >> It is also easy to make self extracting .zip files. > > > > That's the way to go -- it's the popular archive format for Windows, security > > be damned! > > > >> > >> And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. > >> > >> > >> - Jay From jay.krell at cornell.edu Fri Jun 26 17:19:44 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 15:19:44 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090626150644.GA4554@topoi.pooq.com> References: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626150644.GA4554@topoi.pooq.com> Message-ID: Security not be damned. You can sign executables. You can open them in winzip instead if you want (if they are self extracting .zips). Where is the line between running the installer vs. running the code it installs, anyway? I guess the installer runs maybe privileged and its payload does not. But that isn't required for cm3, you can install to $HOME. People also often just distribute non-self-running .MSI files. That would be a good option. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 11:06:45 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: >> >> There's no need for Winzip if we use .zip files, explorer handles them. >> >> It is also easy to make self extracting .zip files. > > That's the way to go -- it's the popular archive format for Windows, security > be damned! > >> >> And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. >> >> >> - Jay From jay.krell at cornell.edu Fri Jun 26 17:29:29 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 15:29:29 +0000 Subject: [M3devel] no need to import direct dependencies if also indirectly dependent? In-Reply-To: <20090626152312.67AE6CC360@birch.elegosoft.com> References: <20090626152312.67AE6CC360@birch.elegosoft.com> Message-ID: Hm, it looks like there is both a direct and indirect dependency here on sysutils. indirect through m3quake direct use of TextUtils Shouldn't the builder /ideally/ require you do import directly what you directly depend on? (and not import directly what you indirectly depend on, already correct) Or would that be a bit inconvenient? I don't care really, I'm not pushing for a change, but wouldn't that generally be the right design? - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 17:23:12 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/06/26 17:23:12 > > Modified files: > cm3/m3-sys/cminstall/src/: m3makefile > > Log message: > go back a version -- there is an indirect dependency on sysutils so this is ok to leave as a sort of comment, though it is not needed, and it might cause the dependency to stick even if the indirect one goes away? > From wagner at elegosoft.com Fri Jun 26 17:59:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 17:59:55 +0200 Subject: [M3devel] archive bloat In-Reply-To: References: <20090626141849.mw5uo0zahw4k80og@mail.elegosoft.com> Message-ID: <20090626175955.pvanjmxce0wgcgcw@mail.elegosoft.com> Quoting Jay : > >> These are surely needed for shipping. > > They are not. > shipping doesn't require shipping dependencies. Only building does. > And building has already occured. > Shipping cm3 doesn't do much anyway. It ships the man page, ok. And > it ships the binary to a place other than where it is used, because > cm3 is special. > > I checked, the following works: > > I already have a full enough package store. > cd m3-sys/cm3 > cm3 > cm3 -ship > rm -rf /cm3/pkg/m3front /cm3/pkg/middle /cm3/pkg/m3quake > cm3 -ship > >> That's because the archives are simply pre-built workspace parts. > > Still... > > What do we gain by shipping the non-source part of the workspace? > People can do incremental builds? > In the future, if the package build / install split is earlier, it > could ease cross packaging, but currently? > > Packaging the source with each architecture is wasteful, but it does > address version skew. > The binaries come with matching source. m3quake and m3middle etc. are packages which are useful on their own. I don't think providing partial installation packages is the way to go. 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 rcolebur at scires.com Fri Jun 26 18:24:47 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Fri, 26 Jun 2009 12:24:47 -0400 Subject: [M3devel] log messages for committed changes In-Reply-To: <20090626081242.DE6C6CC306@birch.elegosoft.com> References: <20090626081242.DE6C6CC306@birch.elegosoft.com> Message-ID: <4A44BE0C.1E75.00D7.1@scires.com> Hey, I've seen several of these type messages (see below). My question is "WHY"? Just to state that it doesn't need to be standalone begs the question why was it made standalone in the first place and what is the reason why it no longer needs to be that way. Maybe this is part of a larger rant on my part, but when folks commit changes, I would encourage everyone to provide some rationale and detail in the log message. There are few people like Olaf and Tony that have enough perspective with the whole system to be able to look at the details of what was changed and try to reverse something that goes against core principals or that will cause problems elsewhere. For the rest of us, and for documentation of the system evolution, it is important that the log messages be as detailed as possible, at least to give the rationale why a change is being made. I know documentation is not glamorous and doesn't directly affect the code, but it is nonetheless important, and if done well can be a real benefit. Thanks for listening. I'll step down off my soapbox now. Regards, Randy Coleburn >>> Jay Krell 6/26/2009 10:12 AM >>> CVSROOT:/usr/cvs Changes by:jkrell at birch.09/06/26 10:12:42 Modified files: cm3/m3-sys/m3cgcat/src/: m3makefile Log message: This doesn't need to be standalone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Fri Jun 26 18:40:35 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 16:40:35 +0000 Subject: [M3devel] [M3commit] log messages for committed changes In-Reply-To: <4A44BE0C.1E75.00D7.1@scires.com> References: <20090626081242.DE6C6CC306@birch.elegosoft.com> <4A44BE0C.1E75.00D7.1@scires.com> Message-ID: I was thinking of starting an email thread on this. I believe the reasons to make things standalone are: - unshipped built-global tools run during the build, such as m3bundle, stub generators, PklFonts, etc. I think these could be addressed but it'd take some work. - "Tony's convenience", still being discussed. A think this was a stronger case prior to -rpath where having "separate runnable backups" was more difficult. Or perhaps still since -rpath isn't yet everywhere, AMD64_DARWIN in particular. Personally when I revert to a backup I copy it back to the real place, sometimes with an entire package store, but it is reasonable to not have to do that, and even reasonable to reduce it to one file instead of roughly three in two directories. This would really only apple to cm3 and m3cgcat. For it to include m3cggen would definitely be surprising. It is also "nice to have" cm3 statically linked because when cross building to a new platform, you don't have to get shared libraries working before running cm3. But you could toggle that for this scenario. I had thought there was also a requirement around bootstrapping from an older build, where old cm3 can't build new m3core/libm3, but I don't see that now. - inability on some platforms to ship in use files, could be worked around, but partly related to previous, and more than that; in particular cm3 shouldn't ship m3core.so/libm3.so that it uses, if you intend to run that cm3 again - possibly so they can be redistributed with fewer files This is the typical reason in the larger world for reducing dynamic linking, as well to be independent of changes to those files. But I don't think "we" intend that to happen for "our" stuff. And I think we intend for now to always ship everything together, so versioning and compatibility can be ignored. I think. There are still a few sprinkled standalones, like in games. Which is why I was going to start email. If someone really wanted to copy solitaire around without installing its dependencies, rebuild it from source? - cminstall, because it runs so early Though this could be addressed via -rpath = $ORIGIN and putting the .so files it needs next to it, and not duplicating them. The reason to make things not standalone is several efficiency gains. You share the code in memory, you share it on disk, you don't copy it around as many times, locally or over the network. The savings are generally pretty large. - Jay ________________________________ > Date: Fri, 26 Jun 2009 12:24:47 -0400 > From: rcolebur at scires.com > To: m3commit at elegosoft.com; m3devel at elegosoft.com > Subject: [M3commit] log messages for committed changes > > > > > > > > Hey, I've seen several of these type messages (see below). My question is "WHY"? Just to state that it doesn't need to be standalone begs the question why was it made standalone in the first place and what is the reason why it no longer needs to be that way. > > > > Maybe this is part of a larger rant on my part, but when folks commit changes, I would encourage everyone to provide some rationale and detail in the log message. > > > > There are few people like Olaf and Tony that have enough perspective with the whole system to be able to look at the details of what was changed and try to reverse something that goes against core principals or that will cause problems elsewhere. For the rest of us, and for documentation of the system evolution, it is important that the log messages be as detailed as possible, at least to give the rationale why a change is being made. I know documentation is not glamorous and doesn't directly affect the code, but it is nonetheless important, and if done well can be a real benefit. > > > > Thanks for listening. I'll step down off my soapbox now. > > > > Regards, > > Randy Coleburn > > >>>> Jay Krell 6/26/2009 10:12 AM>>> > CVSROOT:/usr/cvs > Changes by:jkrell at birch.09/06/26 10:12:42 > > Modified files: > cm3/m3-sys/m3cgcat/src/: m3makefile > > Log message: > This doesn't need to be standalone. > > From hosking at cs.purdue.edu Fri Jun 26 20:17:21 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 26 Jun 2009 14:17:21 -0400 Subject: [M3devel] [M3commit] log messages for committed changes In-Reply-To: References: <20090626081242.DE6C6CC306@birch.elegosoft.com> <4A44BE0C.1E75.00D7.1@scires.com> Message-ID: For M3 system development tools like m3cgcat m3cggen, standalone is generally best. True, most users don't need to ship those tools. On 26 Jun 2009, at 12:40, Jay wrote: > > I was thinking of starting an email thread on this. > > > I believe the reasons to make things standalone are: > > - unshipped built-global tools run during the build, such as > m3bundle, stub generators, PklFonts, etc. > I think these could be addressed but it'd take some work. > > > - "Tony's convenience", still being discussed. > A think this was a stronger case prior to -rpath where having > "separate runnable backups" > was more difficult. Or perhaps still since -rpath isn't yet > everywhere, AMD64_DARWIN in particular. > Personally when I revert to a backup I copy it back to the real > place, sometimes > with an entire package store, > but it is reasonable to not have to do that, and even reasonable > to reduce it to one file > instead of roughly three in two directories. > This would really only apple to cm3 and m3cgcat. For it to > include m3cggen would > definitely be surprising. > It is also "nice to have" cm3 statically linked because when > cross building to a new > platform, you don't have to get shared libraries working before > running cm3. But > you could toggle that for this scenario. > > I had thought there was also a requirement around bootstrapping > from an older > build, where old cm3 can't build new m3core/libm3, but I don't > see that now. > > - inability on some platforms to ship in use files, could be worked > around, but > partly related to previous, and more than that; in particular cm3 > shouldn't ship > m3core.so/libm3.so that it uses, if you intend to run that cm3 > again > > > - possibly so they can be redistributed with fewer files > This is the typical reason in the larger world for reducing > dynamic linking, > as well to be independent of changes to those files. > But I don't think "we" intend that to happen for "our" stuff. > And I think we intend for now to always ship everything together, > so versioning and compatibility can be ignored. I think. > There are still a few sprinkled standalones, like in games. > Which is why I was going to start email. > If someone really wanted to copy solitaire around without > installing its dependencies, > rebuild it from source? > > > - cminstall, because it runs so early > Though this could be addressed via -rpath = $ORIGIN and putting > the .so files it needs next to it, and not duplicating them. > > > The reason to make things not standalone is several efficiency gains. > You share the code in memory, you share it on disk, you don't copy > it around > as many times, locally or over the network. The savings are > generally pretty large. > > > - Jay > > > ________________________________ >> Date: Fri, 26 Jun 2009 12:24:47 -0400 >> From: rcolebur at scires.com >> To: m3commit at elegosoft.com; m3devel at elegosoft.com >> Subject: [M3commit] log messages for committed changes >> >> >> >> >> >> >> >> Hey, I've seen several of these type messages (see below). My >> question is "WHY"? Just to state that it doesn't need to be >> standalone begs the question why was it made standalone in the >> first place and what is the reason why it no longer needs to be >> that way. >> >> >> >> Maybe this is part of a larger rant on my part, but when folks >> commit changes, I would encourage everyone to provide some >> rationale and detail in the log message. >> >> >> >> There are few people like Olaf and Tony that have enough >> perspective with the whole system to be able to look at the details >> of what was changed and try to reverse something that goes against >> core principals or that will cause problems elsewhere. For the rest >> of us, and for documentation of the system evolution, it is >> important that the log messages be as detailed as possible, at >> least to give the rationale why a change is being made. I know >> documentation is not glamorous and doesn't directly affect the >> code, but it is nonetheless important, and if done well can be a >> real benefit. >> >> >> >> Thanks for listening. I'll step down off my soapbox now. >> >> >> >> Regards, >> >> Randy Coleburn >> >> >>>>> Jay Krell 6/26/2009 10:12 AM>>> >> CVSROOT:/usr/cvs >> Changes by:jkrell at birch.09/06/26 10:12:42 >> >> Modified files: >> cm3/m3-sys/m3cgcat/src/: m3makefile >> >> Log message: >> This doesn't need to be standalone. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jun 26 21:12:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 21:12:32 +0200 Subject: [M3devel] dead links In-Reply-To: References: Message-ID: <20090626211232.p2z8n0bqosk44skg@mail.elegosoft.com> Quoting Jay : > http://www.opencm3.net/doc/help/gen_html/dirfp/INDEX.html > > and surely all the rest contain links to CVS files, of suspicious > utility, that are actually dead. > > http://www.opencm3.net/releng/collection-core.html > > The links there to browse source don't work, er, at least > specifically the first three -- m3core, m3cc, import-libs. Several > others do work. Some have the CVS files, some don't. > There are some unusual manual page links..which aren't exactly > broken, but oddly placed and inconsistent. > > "Some Useful odula-3 Interfaces" is missing the M in Modula-3 (still > in collection-core.html). These should be fixed now. If I've missed something, let me know... > The first link in: > http://www.opencm3.net/releng/collection-obliq.html > > doesn't work, to polymtl. Hm, we need to replace that in our doc then. I noticed other broken links to DEC amd others, too, in doc. > Much more to check, there's a lot of new stuff and/or stuff I've > never looked at... > > - 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 Fri Jun 26 22:10:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 22:10:28 +0200 Subject: [M3devel] LINUXLIBC6 on 64 bit Hardware Message-ID: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> I Installed the LINUXLIBC6 archives from Jay on birch in my home directory without problems. Trying to build package m3core fails at the last step with ... fgrep m3gcdefs /home/wagner/cm3-LINUXLIBC6/pkg/m3core/LINUXLIBC6/.M3EXPORTS 2>/dev/null >/dev/null gcc -gstabs+ -m32 -fPIC -mno-align-double -z now -z origin -Bsymbolic -Wl,--fatal-warnings -Wl,-rpath,\$ORIGIN/../lib -Wl,--warn-common -Wl,-rpath,/home/wagner/cm3-LINUXLIBC6/lib -shared -Wl,-soname,libm3core.so.5 -o libm3core.so.5 hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTTipe.io RTTipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSmmap.o RTThread.io RTThreadStk.mo RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTMachine.io RTThread.mo RTThreadC.o RTExFrame.io RTExFrame.mo RTStackC.o Thread.io Scheduler.io SchedulerPosix.io MutexRep.io ThreadEvent.io ThreadF.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo WinNTc.o UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uucontext.o Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Upthread.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Usysdep.io Usignal.io Uucontext.io Upthreadtypes.io Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io Ctypes.io M3toC.io M3toC.mo CerrnoC.o Cstring.io Cstdio.io Csignal.io Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo DateBsd.mo TimePosix.io TimePosix.mo CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo PolyBasis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo -lm -lpthread /usr/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3core Fatal Error: package build failed rm m3make.args cd .. birch [~/work/cm3] wagner % type gcc gcc is /usr/bin/gcc birch [~/work/cm3] wagner % gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) I don't see gcc_s in the link command, and on birch there _is_ /lib/libgcc_s.so.1 Any ideas? 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 Fri Jun 26 22:46:45 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 26 Jun 2009 13:46:45 -0700 Subject: [M3devel] LINUXLIBC6 on 64 bit Hardware In-Reply-To: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> References: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> Message-ID: Surely a 32 on 64 thing. Try a 32 bit system? We would probably be ok with static libgcc. - Jay (phone) On Jun 26, 2009, at 1:10 PM, Olaf Wagner wrote: > I Installed the LINUXLIBC6 archives from Jay on birch in my home > directory without problems. > > Trying to build package m3core fails at the last step with > > ... > fgrep m3gcdefs /home/wagner/cm3-LINUXLIBC6/pkg/m3core/ > LINUXLIBC6/.M3EXPORTS 2>/dev/null >/dev/null > gcc -gstabs+ -m32 -fPIC -mno-align-double -z now -z origin - > Bsymbolic -Wl,--fatal-warnings -Wl,-rpath,\$ORIGIN/../lib -Wl,--warn- > common -Wl,-rpath,/home/wagner/cm3-LINUXLIBC6/lib -shared -Wl,- > soname,libm3core.so.5 -o libm3core.so.5 hand.o dtoa.o libgcc.o > RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo > Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io > RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io > RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo > RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo > RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTLinkerX.io > RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTError.io > RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo > RTMisc.io RTMisc.mo RTModule.io RTPacking.io RTPacking.mo > RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io > RTProcess.mo RTTipe.io RTTipe.mo RTType.io RTType.mo RTTypeFP.io > RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo > RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io > RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io > RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSmmap.o RTThread.io > RTThreadStk.mo RTSignalPrivate.io RTSignalC.o RTSignalC.io > RTSignal.mo RTMachine.io RTThread.mo RTThreadC.o RTExFrame.io > RTExFrame.mo RTStackC.o Thread.io Scheduler.io SchedulerPosix.io > MutexRep.io ThreadEvent.io ThreadF.io ThreadPThread.io > ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io > WinDef.mo WinNT.io WinNT.mo WinNTc.o UtimeC.o UnixC.o UnixLink.o > Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o > Uucontext.o Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io > Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io > Upthread.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o > Usysdep.io Usignal.io Uucontext.io Upthreadtypes.io Uin.io Cerrno.io > Cstddef.io Cstdint.io Cstdlib.io Ctypes.io M3toC.io M3toC.mo > CerrnoC.o Cstring.io Cstdio.io Csignal.io Csetjmp.io BasicCtypes.io > RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io > IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io > DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io > RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io > FPU.io FPU.mo FloatMode.io FloatMode.mo Time.io Tick.io Date.io > FmtTime.io FmtTime.mo TickPortable.mo DateBsd.mo TimePosix.io > TimePosix.mo CConvert.io CConvert.mo Convert.io Convert.mo > String8.io String8.mo String16.io String16.mo Text.io Text.mo > TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io > Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo > Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io > TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo > Fingerprint.io Fingerprint.mo Poly.io Poly.mo PolyBasis.io > PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io > LongRep.io Long.io Word.mo Long.mo -lm -lpthread > /usr/bin/ld: cannot find -lgcc_s > collect2: ld returned 1 exit status > make_lib => 1 > librarian failed building: m3core > Fatal Error: package build failed > rm m3make.args > cd .. > birch [~/work/cm3] wagner > % type gcc > gcc is /usr/bin/gcc > birch [~/work/cm3] wagner > % gcc -v > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --enable-languages=c,c+ > +,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with- > system-zlib --libexecdir=/usr/lib --without-included-gettext -- > enable-threads=posix --enable-nls --program-suffix=-4.1 --enable- > __cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable- > mpfr --enable-checking=release x86_64-linux-gnu > Thread model: posix > gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) > > I don't see gcc_s in the link command, and on birch there _is_ > /lib/libgcc_s.so.1 > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > 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: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From eiserlohpp at yahoo.com Sat Jun 27 01:09:16 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 26 Jun 2009 16:09:16 -0700 (PDT) Subject: [M3devel] Manual Page for Quake Message-ID: <528453.41864.qm@web56801.mail.re3.yahoo.com> Okay guys, I took the web page describing the quake language, and formated it as a man page. http://www.eiserloh.org/~peter/modula3/#mydocs I hereby submit this for inclusion within the modula-3 archives. I hereby relinquish any rights to the (quake.man) and any derived files. This document is now in the public domain. NOTE: The original content was authored by Stephen Harrison, not me. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat Jun 27 02:45:34 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 00:45:34 +0000 Subject: [M3devel] link options (was LINUXLIBC6 on 64 bit Hardware) (rambly) In-Reply-To: <20090626232034.nbt6xg4sgws4w440@mail.elegosoft.com> References: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> <20090626232034.nbt6xg4sgws4w440@mail.elegosoft.com> Message-ID: [adding m3devel] ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: link options (was LINUXLIBC6 on 64 bit Hardware) (rambly) > Date: Sat, 27 Jun 2009 00:43:58 +0000 > > > ps: You don't see -lc there either. > Change SYSTEM_CC to include -Wl,-v or such and you can see what gcc feeds to ld, surely it'll have hints of -lc and -lgcc_s. Or gcc -dump-specs or somesuch. > You could try running that then without the -lgcc_s but you'll likely have unresolved externals related to 64 bit integers. libgcc is about more than 64 bit integers, also like C++ and Ada exception handling, but it seems like overkill for us. 64 bit systems shouldn't need it for 64 bit math, at least. > THe thing is, choice of shared libgcc or not, is that, you know, you /might/ be (static) linking your Modula-3 with some C++ code that uses exceptions, and you /might/ be /dynamically/ linking to other C++ code that throws exceptions and you might want interop, in which case shared libgcc is desired. > > > But then the common case is the "opposite" -- all Modula-3. > > > I think it is tenuous to have exceptions go across dynamic link boundaries, but some people think the line between dynamic and static linking should be quite blurry and things should work the "same" either way. > (Thus why the older symbol resolution algorithms where all symbols looked across all .so files, to emulate static linking, eventually/gradually replaced with "two level namespace". That is Apple's term and I think a good description of what everyone now favors even if they don't call it that; but then the defaults often unchanged for compatibility, Apple changed the default, NT was always this way (except maybe Interix)). > > > Actually, now that I think about it...this is stuff that actually needs to be controllable from each m3makefile, and possibly from the cm3 command line. > > I used to think it was a config file thing and I'd try to make a reasonable choice for everyone, but now I think it's not even a per-machine thing but more granular. Anyway, the default is reasonable, just that it should probably be changable. > > > So probably we should have new Quake directives that mimic gcc's command line options, like: > SharedLibGcc(); > StaticLibGcc(); > > > and they'd just be ignored on SOLsun, NT386, etc. > They'd just be trivially implemented in cm3cfg.common and set a global that m3_link adds to the link command line, very simple. > > > I guess this is a general exercise: See what switches in gcc/ld people tend to vary on a project by project basis, see which ones are relevant to Modula-3 (ie: more linking flags, not compile flags) and expose them in Quake. > AND/OR ensure it is/remains viable for people to use Makefiles, combine Modula-3 with gcc using Makefiles and gcc, and just using cm3 to build some pieces of their project. Personally I've never tried that. > That way, you know, they can just form their own link commands in a Makefile and Quake doesn' t have to provide full access. > Also we could make SYSTEM_LD not readonly and leaf m3makefiles could just munge it. > That is an easy way to add flexibility. > > > - Jay > > ---------------------------------------- >> Date: Fri, 26 Jun 2009 23:20:34 +0200 >> From: wagner >>>> >>>> I don't see gcc_s in the link command, and on birch there _is_ >>>> /lib/libgcc_s.so.1 >>>> >>>> Any ideas? >>>> >>>> Olaf From jay.krell at cornell.edu Sat Jun 27 03:35:49 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 01:35:49 +0000 Subject: [M3devel] PPC_DARWIN tinderbox Message-ID: Tony, this is your machine? It is only run once, in a while, and failed. Maybe an error in your defs.sh? - Jay From jay.krell at cornell.edu Sat Jun 27 06:33:12 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 04:33:12 +0000 Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress In-Reply-To: <4A45868C.3020001@cox.net> References: <4A4251D6.60804@cox.net> <4A45868C.3020001@cox.net> Message-ID: Right, definitely good to make the invasive changes minimal. Our diffs within gcc are quite small I found. Almost everything is adding the file parse.c CVS is supposed to help here, three way merge and all that, but there is only so much it can do. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 21:40:12 -0500 > From: rodney.m.bates at cox.net > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3gdb/AMD64_LINUX, a little progress > > Jay wrote: >> You should try using cvs import to upgrade to a newer version, of the >> entire gdb tree (well, maybe prune it -- testsuites, sim, cpu, intl, >> etc..) >> I personally have never done this -- only recently imported the first >> version of stuff but haven't yet updated anything. > There is a _lot_ of merging work to get the m3gdb changes into a newer gdb > base, including a lot of manual cleanup. I've done it. More than > once. I plan to > do it again, real soon now, but this was a reckless attempt at something > quick > and dirty. Also, there is a newest gdb release 6/9 forthcoming soon, and I > think it would be nice to wait for it. > > I have been gradually pulling m3 support code out of gdb source files > and putting > into m3-*.c files, with only calls, etc in the original gdb source. > This should help > a bit for the next time around. But there is always lots of rework in > a later gdb > that requires corresponding rework to m3gdb. Things go away or are > replaced > by something redesigned, and it takes work to figure out what the > replacement is > and how to use it. >> >> - Jay >> >> >>> Date: Wed, 24 Jun 2009 11:18:30 -0500 >>> From: rodney.m.bates at cox.net >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress >>> >>> I have tracked down the problems I have seen with m3gdb on >>> AMD64_LINUX not recognizing object formats to a new section >>> type SHT_GNU_HASH, (and named .gnu.hash), which is present >>> in recent M3-compiled code. It appears to be handled by >>> the more recent binutils that comes in gdb 6.8, but it is >>> not handled by the binutils in gdb 6.4, from which m3gdb is >>> derived. >>> >>> I briefly tried a naive substitution of the new binutils >>> (directory 'bfd') into m3gdb, but some things have moved >>> around and there are build problems finding them. I will >>> work on this more when I get some time. >>> >>> Rodney Bates > From rodney.m.bates at cox.net Sat Jun 27 04:40:12 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Fri, 26 Jun 2009 21:40:12 -0500 Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress In-Reply-To: References: <4A4251D6.60804@cox.net> Message-ID: <4A45868C.3020001@cox.net> Jay wrote: > You should try using cvs import to upgrade to a newer version, of the > entire gdb tree (well, maybe prune it -- testsuites, sim, cpu, intl, > etc..) > I personally have never done this -- only recently imported the first > version of stuff but haven't yet updated anything. There is a _lot_ of merging work to get the m3gdb changes into a newer gdb base, including a lot of manual cleanup. I've done it. More than once. I plan to do it again, real soon now, but this was a reckless attempt at something quick and dirty. Also, there is a newest gdb release 6/9 forthcoming soon, and I think it would be nice to wait for it. I have been gradually pulling m3 support code out of gdb source files and putting into m3-*.c files, with only calls, etc in the original gdb source. This should help a bit for the next time around. But there is always lots of rework in a later gdb that requires corresponding rework to m3gdb. Things go away or are replaced by something redesigned, and it takes work to figure out what the replacement is and how to use it. > > - Jay > > > > Date: Wed, 24 Jun 2009 11:18:30 -0500 > > From: rodney.m.bates at cox.net > > To: m3devel at elegosoft.com > > Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress > > > > I have tracked down the problems I have seen with m3gdb on > > AMD64_LINUX not recognizing object formats to a new section > > type SHT_GNU_HASH, (and named .gnu.hash), which is present > > in recent M3-compiled code. It appears to be handled by > > the more recent binutils that comes in gdb 6.8, but it is > > not handled by the binutils in gdb 6.4, from which m3gdb is > > derived. > > > > I briefly tried a naive substitution of the new binutils > > (directory 'bfd') into m3gdb, but some things have moved > > around and there are build problems finding them. I will > > work on this more when I get some time. > > > > Rodney Bates From wagner at elegosoft.com Sat Jun 27 12:48:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 27 Jun 2009 12:48:03 +0200 Subject: [M3devel] link options (was LINUXLIBC6 on 64 bit Hardware) (rambly) In-Reply-To: References: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> <20090626232034.nbt6xg4sgws4w440@mail.elegosoft.com> Message-ID: <20090627124803.10mmxzjs0ks00040@mail.elegosoft.com> Quoting Jay : > [adding m3devel] > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> Subject: RE: link options (was LINUXLIBC6 on 64 bit Hardware) (rambly) >> Date: Sat, 27 Jun 2009 00:43:58 +0000 >> [...] >> Actually, now that I think about it...this is stuff that actually >> needs to be controllable from each m3makefile, and possibly from >> the cm3 command line. >> >> I used to think it was a config file thing and I'd try to make a >> reasonable choice for everyone, but now I think it's not even a >> per-machine thing but more granular. Anyway, the default is >> reasonable, just that it should probably be changable. >> >> So probably we should have new Quake directives that mimic gcc's >> command line options, like: >> SharedLibGcc(); >> StaticLibGcc(); Well, I'd have preferred some common abstraction, but then (a) making it more flexible for a certain backend is better than no flexibility at all and (b) perhaps common abstractions need to evolve gradually over time (or maybe there aren't any at all). So yes, I'm all for providing new quake switches, even if they are backend or system dependent. Of course they need to be documented in the operations guide and the quake language description, too. >> and they'd just be ignored on SOLsun, NT386, etc. >> They'd just be trivially implemented in cm3cfg.common and set a >> global that m3_link adds to the link command line, very simple. >> >> I guess this is a general exercise: See what switches in gcc/ld >> people tend to vary on a project by project basis, see which ones >> are relevant to Modula-3 (ie: more linking flags, not compile >> flags) and expose them in Quake. >> AND/OR ensure it is/remains viable for people to use Makefiles, >> combine Modula-3 with gcc using Makefiles and gcc, and just using >> cm3 to build some pieces of their project. Personally I've never >> tried that. >> That way, you know, they can just form their own link commands in a >> Makefile and Quake doesn' t have to provide full access. >> Also we could make SYSTEM_LD not readonly and leaf m3makefiles >> could just munge it. >> That is an easy way to add flexibility. Yes, I wouldn't object to that, too. 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 hosking at cs.purdue.edu Sat Jun 27 14:31:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Jun 2009 08:31:10 -0400 Subject: [M3devel] PPC_DARWIN tinderbox In-Reply-To: References: Message-ID: It just got booted up after a year away. Probably need to update. On 26 Jun 2009, at 21:35, Jay wrote: > > Tony, this is your machine? It is only run once, in a while, and > failed. > Maybe an error in your defs.sh? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jun 27 16:48:56 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 14:48:56 +0000 Subject: [M3devel] canonicalizepath?? Message-ID: DoMakeDir 1: /cm3/bin/../pkg/m3cggen/PPC_LINUX DoMakeDir 2: /cm3/bin/m3cggen/PPC_LINUX C:\dev2\cm3.2\m3-sys\m3quake\src\QMachine.m3 PROCEDURE DoMakeDir (t: T; n_args: INTEGER) RAISES {Error} = VAR val: QValue.T; dir, prefix: TEXT; BEGIN Pop (t, val); dir := QVal.ToText (t, val); prefix := Env.Get("CM3_INSTALL_PREFIX"); IF prefix # NIL THEN dir := prefix & dir; END; RTIO.PutText("DoMakeDir 1: " & dir & "\n"); dir := Pathname.Compose (CanonicalizePath (Pathname.Decompose (dir))); RTIO.PutText("DoMakeDir 2: " & dir & "\n"); RTIO.Flush(); MakeDir (t, dir); END DoMakeDir; huh? I don't think I've ever change this.. Am I expected to reverse the path before passing it through here? I'll just avoid this function.. - Jay From eiserlohpp at yahoo.com Sat Jun 27 17:04:50 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 27 Jun 2009 08:04:50 -0700 (PDT) Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Message-ID: <400447.39315.qm@web56807.mail.re3.yahoo.com> Hi Jay, On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: > > There's no need for Winzip if we use .zip files, explorer handles them. > > It is also easy to make self extracting .zip files. For installing applications on Windows boxes, why don't you use NSIS? http://nsis.sourceforge.net/Main_Page --- Quoting: From NSIS Wiki --- NSIS (Nullsoft Scriptable Install System) is a professional open source system to create Windows installers. It is designed to be as small and flexible as possible and is therefore very suitable for internet distribution. --- END QUOTE --- Please, if you go this route, don't include the source for NSIS into the M3 source archive, but the script you write that tells NSIS how to operate, yes that should be in the source archive. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat Jun 27 19:36:07 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 17:36:07 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: In-Reply-To: <400447.39315.qm@web56807.mail.re3.yahoo.com> References: <400447.39315.qm@web56807.mail.re3.yahoo.com> Message-ID: Well, it probably is better than IExpress.exe but IExpress is super easy. I'll probably stick with it and if someone has something else to replace it with they can. - Jay ---------------------------------------- > Date: Sat, 27 Jun 2009 08:04:50 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: > > > Hi Jay, > > On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: >> >> There's no need for Winzip if we use .zip files, explorer handles them. >> >> It is also easy to make self extracting .zip files. > > > For installing applications on Windows boxes, why don't > you use NSIS? > > http://nsis.sourceforge.net/Main_Page > > > --- Quoting: From NSIS Wiki --- > > NSIS (Nullsoft Scriptable Install System) is a professional open source system to create Windows installers. It is designed to be as small and flexible as possible and is therefore very suitable for internet distribution. > > --- END QUOTE --- > > Please, if you go this route, don't include the source for > NSIS into the M3 source archive, but the script you write > that tells NSIS how to operate, yes that should be in the > source archive. > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ From eiserlohpp at yahoo.com Sun Jun 28 00:53:49 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 27 Jun 2009 15:53:49 -0700 (PDT) Subject: [M3devel] Quake documentation: readonly Message-ID: <825721.23887.qm@web56808.mail.re3.yahoo.com> In the quake documentation, in the SCOPE section the keyword "readonly" is very briefly defined in the following: To protect a name in the current scope, use readonly dec = "digital" If local or readonly are not used, all variables are located in the outermost (global) scope. Beware of side-effects! Question 1: what would happen if a script attempts to modify a readonly variable? Does it quitely fail, or verbosely complain? Question 2: if a readonly variable is declared at an outer scope, and later an inner one attempts to declare a new instance with that same name, does the new name simply cover the old name, or does the attempt to declare a conflicting local variable fail (quitely, or verbosely). Picking the last one above, can we clarify this to say: To declare a name in the local scope, and prevent any further changes to it after initialization, use "readonly". When a readonly declaration occurs in the outmost scope, then a readonly variable (i.e., a constant) is declared at the global scope, an prevents any local variable with this same name being declared locally. For example: readonly dec = "digital" Alternatively, picking new local declaration succeeds: To declare a name in the local scope, and prevent any further changes to it after initialization, use "readonly". When a readonly declaration occurs in the outermost scope, then a readonly variable (i.e., a constant) is declared at the global scope. A local declaration inside an inner scope will override the global name while in that inner scope. Specifically: I am looking at creating a user config file, intending to override some settings. Something like: ---- BEGIN example user config file ---- % override debugging format from stab+ to DWARF2 format. readonly m3back_flags = "-quiet -gdwarf2 -m64 -fPIC -mno-align-double" include("usr/cm3/etc/AMD64_LINUX") ---- END user config file ---- +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sun Jun 28 08:58:41 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 28 Jun 2009 06:58:41 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: In-Reply-To: <400447.39315.qm@web56807.mail.re3.yahoo.com> References: <400447.39315.qm@web56807.mail.re3.yahoo.com> Message-ID: Ok, I take that back. Yes. Nullsoft is probably it. Thank you for the referral. IExpress seems to have a low limit on how many files it can package. I could probably build something hierarchical, but it's getting more painful. I tried out Nullsoft and it was quick easy worked well, results already surpassing iexpress, I used the gui and I expect the command line will be easy/quick/good too. I just did the zip2exe option. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: eiserlohpp at yahoo.com; m3devel at elegosoft.com > Subject: RE: [M3devel] Getting ready for new users (Re: HEADS UP: > Date: Sat, 27 Jun 2009 17:36:07 +0000 > > > Well, it probably is better than IExpress.exe but IExpress is super easy. > I'll probably stick with it and if someone has something else to replace it with they can. > > - Jay > > > ---------------------------------------- >> Date: Sat, 27 Jun 2009 08:04:50 -0700 >> From: eiserlohpp at yahoo.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: >> >> >> Hi Jay, >> >> On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: >>> >>> There's no need for Winzip if we use .zip files, explorer handles them. >>> >>> It is also easy to make self extracting .zip files. >> >> >> For installing applications on Windows boxes, why don't >> you use NSIS? >> >> http://nsis.sourceforge.net/Main_Page From wagner at elegosoft.com Sun Jun 28 14:27:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 28 Jun 2009 14:27:39 +0200 Subject: [M3devel] canonicalizepath?? In-Reply-To: References: Message-ID: <20090628142739.ryq4td9tkwkcgkow@mail.elegosoft.com> Quoting Jay : > DoMakeDir 1: /cm3/bin/../pkg/m3cggen/PPC_LINUX > DoMakeDir 2: /cm3/bin/m3cggen/PPC_LINUX > > > C:\dev2\cm3.2\m3-sys\m3quake\src\QMachine.m3 > > PROCEDURE DoMakeDir (t: T; n_args: INTEGER) RAISES {Error} = > VAR val: QValue.T; dir, prefix: TEXT; > BEGIN > > Pop (t, val); dir := QVal.ToText (t, val); > prefix := Env.Get("CM3_INSTALL_PREFIX"); > IF prefix # NIL THEN > dir := prefix & dir; > END; > RTIO.PutText("DoMakeDir 1: " & dir & "\n"); > dir := Pathname.Compose (CanonicalizePath (Pathname.Decompose (dir))); > RTIO.PutText("DoMakeDir 2: " & dir & "\n"); > RTIO.Flush(); > MakeDir (t, dir); > END DoMakeDir; > > huh? Strange :-/ > I don't think I've ever change this.. Nor did I. > Am I expected to reverse the path before passing it through here? A quick look at the function seems to show that it only correctly removes ../.. at the start of a path, if I am not mistaken. > I'll just avoid this function.. Could you (or anybody else) fix it? I'm in a hurry and won't get to it till Tuesday night... I don't think we should leave it that way... 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 Sun Jun 28 18:48:22 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 28 Jun 2009 12:48:22 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090626151238.GB4554@topoi.pooq.com> References: <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090626151238.GB4554@topoi.pooq.com> Message-ID: <20090628164822.GA11116@topoi.pooq.com> On Fri, Jun 26, 2009 at 11:12:38AM -0400, hendrik at topoi.pooq.com wrote: > On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: > > Quoting Jay : > > > > > > > >I tested the LINUXLIBC6 archive and it installed ok, no prompting. > > > > > >I ran it with no parameters -- unlike Henrik. It did mention the > > >current working directory (or its directory, same thing) as the > > >install source, which confused me. Probably as long as system.tgz > > >exists where it expects, it shouldn't say anything. > > > > Strange. > > > > Hendrik, can you reproduce the strange message? And then perhaps > > provide a system call trace (ktrace, truss, whatever)? > > > > Olaf > > I'll try. I'll probably have to rm -r /user/local/cm3 first. Anything > else I need to watch out for? I haven't done that yet. But I have a program that works on the system I managed to set up a month or so ago just by unpacking the cm3-min .tgz archive file and setting $PATH to point to its bin directory. I set the $PATH to the version I just installed (with the strangee message) deleted LINUXLIBC6, and ran the just-(mis?)installed cm3: hendrik at notlookedfor:~/mtxt$ rm LINUXLIBC6/ -r hendrik at notlookedfor:~/mtxt$ cm3 --- building in LINUXLIBC6 --- "/home/hendrik/mtxt/src/m3makefile", line 1: quake runtime error: unable to open "/var/tmp/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 1 /home/hendrik/mtxt/src/m3makefile 4 /home/hendrik/mtxt/LINUXLIBC6/m3make.args Fatal Error: package build failed hendrik at notlookedfor:~/mtxt$ which cm3 /usr/local/cm3/bin/cm3 hendrik at notlookedfor:~/mtxt$ env | grep cm PATH=/home/hendrik/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/hendrik/bin/i686/:/usr/local/cm3/bin hendrik at notlookedfor:~/mtxt$ I don't know if this could help anyone figure out what went wrong with the installation, but it does indicate that it isn't right. There's noting at all in /var/tmp. Not even a directory /vat/tmp/cm3. -- hendrik > > Now that I think of resetting ... I still had the old cm3-min > unpacked somewhere else, and I add its bin directory to the $PATH on > a bash startup. Could that have be affecting the results? > > -- hendrik > From jay.krell at cornell.edu Sun Jun 28 19:13:48 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 28 Jun 2009 17:13:48 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090628164822.GA11116@topoi.pooq.com> References: <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090626151238.GB4554@topoi.pooq.com> <20090628164822.GA11116@topoi.pooq.com> Message-ID: The packaging process stages things in /var/tmp/cm3. I bet the cm3.cfg file says INSTALL_ROOT="/var/tmp/cm3". It should be fixed, I changed it to say INSTALL_ROOT = (path() & SL & ".."). - Jay ---------------------------------------- > Date: Sun, 28 Jun 2009 12:48:22 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > On Fri, Jun 26, 2009 at 11:12:38AM -0400, hendrik at topoi.pooq.com wrote: >> On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: >>> Quoting Jay : >>> >>>> >>>>I tested the LINUXLIBC6 archive and it installed ok, no prompting. >>>> >>>>I ran it with no parameters -- unlike Henrik. It did mention the >>>>current working directory (or its directory, same thing) as the >>>>install source, which confused me. Probably as long as system.tgz >>>>exists where it expects, it shouldn't say anything. >>> >>> Strange. >>> >>> Hendrik, can you reproduce the strange message? And then perhaps >>> provide a system call trace (ktrace, truss, whatever)? >>> >>> Olaf >> >> I'll try. I'll probably have to rm -r /user/local/cm3 first. Anything >> else I need to watch out for? > > I haven't done that yet. But I have a program that works > on the system I managed to set up a month or so ago just by > unpacking the cm3-min .tgz archive file and setting $PATH to > point to its bin directory. > > I set the $PATH to the version I just installed (with the strangee > message) deleted LINUXLIBC6, and ran the just-(mis?)installed cm3: > > hendrik at notlookedfor:~/mtxt$ rm LINUXLIBC6/ -r > hendrik at notlookedfor:~/mtxt$ cm3 > --- building in LINUXLIBC6 --- > > "/home/hendrik/mtxt/src/m3makefile", line 1: quake runtime error: unable > to open "/var/tmp/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS" for reading > > --procedure-- -line- -file--- > import -- > include_dir 1 /home/hendrik/mtxt/src/m3makefile > 4 /home/hendrik/mtxt/LINUXLIBC6/m3make.args > > Fatal Error: package build failed > hendrik at notlookedfor:~/mtxt$ which cm3 > /usr/local/cm3/bin/cm3 > hendrik at notlookedfor:~/mtxt$ env | grep cm > PATH=/home/hendrik/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/hendrik/bin/i686/:/usr/local/cm3/bin > hendrik at notlookedfor:~/mtxt$ > > > I don't know if this could help anyone figure out what went wrong with > the installation, but it does indicate that it isn't right. > > There's noting at all in /var/tmp. Not even a directory /vat/tmp/cm3. > > -- hendrik > > >> >> Now that I think of resetting ... I still had the old cm3-min >> unpacked somewhere else, and I add its bin directory to the $PATH on >> a bash startup. Could that have be affecting the results? >> >> -- hendrik >> From hendrik at topoi.pooq.com Sun Jun 28 20:34:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 28 Jun 2009 14:34:58 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> References: <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> Message-ID: <20090628183458.GA11305@topoi.pooq.com> On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: > Quoting Jay : > > > > >I tested the LINUXLIBC6 archive and it installed ok, no prompting. > > > >I ran it with no parameters -- unlike Henrik. It did mention the > >current working directory (or its directory, same thing) as the > >install source, which confused me. Probably as long as system.tgz > >exists where it expects, it shouldn't say anything. > > Strange. > > Hendrik, can you reproduce the strange message? And then perhaps > provide a system call trace (ktrace, truss, whatever)? No. I have not been able to reproduce it. Tried three times: (1) with the existing preexisting incomplete /usr/local/cm3, and no references to any cm3 stuff in $PATH (2) without any /usr/local/cm3 (I used rm -r to erase it), and no references to any cm3 stuff ini $PATH (3) witout any /usr/local/cm3, and a reference to bin within the unpacked ancient cm3-min archive in my $PATH (which is how is was when I first got the message). (And this is how I've cm3-min to compile and run even though its installation failed as reported here long ago) All these installations were from the same ~hendrik/cm3 directory resulting from the archive I had unpacked a while ago when I got the strange message. I haven't downloaded a new archive since then. Maybe I should retry creating a new unpacked archive every time? Or should I just give up? -- hendrik From eiserlohpp at yahoo.com Mon Jun 29 02:25:28 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 28 Jun 2009 17:25:28 -0700 (PDT) Subject: [M3devel] Manual page for m3makefile and m3overrides files Message-ID: <939775.74319.qm@web56802.mail.re3.yahoo.com> Hi Gang, I am on a rampage this weekend. I converted the docs on the m3makefile and m3overrides files into manual pages. http://black/~peter/modula3/#mydocs Again, I place any work here listed into the public domain. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From eiserlohpp at yahoo.com Mon Jun 29 02:54:51 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 28 Jun 2009 17:54:51 -0700 (PDT) Subject: [M3devel] (no subject) Message-ID: <160850.29538.qm@web56806.mail.re3.yahoo.com> Oops, please change the host name. - http://black/~peter/modula3/#mydocs + http://www.eiserloh.org/~peter/modula3/#mydocs +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Mon Jun 29 05:08:44 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 03:08:44 +0000 Subject: [M3devel] .msi files for Windows available Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives now contains .msi files for Windows: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi These are some of the first .msi files I have ever made. I used WiX. scripts/python/make-dist.py makes them. Some of the highlights/lowlights: They always install all of what they have. There is not (yet) support for the package sets. They always modify %PATH%. It should be an option. They append to %PATH%. My intent was to prepend. (It appears obvious how, but it didn't work.) They have an uninstaller, listed in add/remove programs. Not listed in the start menu. That seems to be go either way in practise. The uninstaller does remove c:\cm3\bin from %path%, besides deleting all the files -- that didn't take any extra work. They don't put anything in the start menu. What would it be? Oh, I need to try cm3ide, which probably isn't here. The config file still just runs cl.exe/link.exe from %path%. I think the way to address this is in the config file, not setup. The default install location is c:\cm3 but user can change it. The presentation of the licenses is quite ugly. And perhaps unnecessary? Not seemingly not easy to remove, without copy/pasting some code/data with yet another license. There are accidentally two .pdbs (symbols) in the .msis. (More geerally the symbols are: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1-symbols.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1-symbols.zip and the same content without installation is at http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip ) http://modula3.elegosoft.com/cm3/uploaded-archives is a bit messy due to the volume of files, it should probably be split up. Someone please try them out and report back. I did test them. They install/uninstall, modify $path, and cm3 runs. - Jay From jay.krell at cornell.edu Mon Jun 29 05:16:37 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 03:16:37 +0000 Subject: [M3devel] .deb files Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives contains some .deb files now, but so far only for SPARC32_LINUX. I assume nobody uses that? x86/AMD64 should be available later, not soon. Highlights/lowlights: There is just min and std, no package sets yet. They install to /usr/local/cm3. You have no choice. Official .deb files are not supposed to use /usr/local, but I don't count these as official. They don't modify $PATH for you. (They don't run cminstall either.) They overlap, install just one. Maybe missing cm3ide and m3gdb, will be fixed. They are made "as a matter of course" by scripts/python/make-dist.py, for any Linux platform. There is no apt-get install foo, I have to look up how to do that, there is download (wget) the file and dpkg -i ./foo.deb. And like apt-get remove cm3-min or apt-get remove cm3-std. .deb files are actually a trivial format. They are an ar file with three files: debian-binary little marker control.tar.gz .deb specific stuff, contains text files data.tar.gz or .bz2 or .lzma the payload in the usual form That is, we could arguably not produce the loose .tgz files. - Jay From jay.krell at cornell.edu Mon Jun 29 05:18:15 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 03:18:15 +0000 Subject: [M3devel] FW: .msi files for Windows available Message-ID: Was truncated. ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: .msi files for Windows available > Date: Mon, 29 Jun 2009 03:08:44 +0000 > > > > http://modula3.elegosoft.com/cm3/uploaded-archives > > now contains .msi files for Windows: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi > > > These are some of the first .msi files I have ever made. > I used WiX. scripts/python/make-dist.py makes them. > > > Some of the highlights/lowlights: > They always install all of what they have. There is not (yet) > support for the package sets. > They always modify %PATH%. It should be an option. > They append to %PATH%. My intent was to prepend. (It appears obvious > how, but it didn't work.) > They have an uninstaller, listed in add/remove programs. > Not listed in the start menu. That seems to be go either way in practise. > The uninstaller does remove c:\cm3\bin from %path%, besides deleting > all the files -- that didn't take any extra work. > They don't put anything in the start menu. > What would it be? Oh, I need to try cm3ide, which probably isn't here. > The config file still just runs cl.exe/link.exe from %path%. > I think the way to address this is in the config file, not setup. > The default install location is c:\cm3 but user can change it. > The presentation of the licenses is quite ugly. And perhaps unnecessary? > Not seemingly not easy to remove, without copy/pasting some code/data with yet another license. > There are accidentally two .pdbs (symbols) in the .msis. > (More geerally the symbols are: > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1-symbols.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1-symbols.zip > and the same content without installation is at > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip > ) > > > http://modula3.elegosoft.com/cm3/uploaded-archives > is a bit messy due to the volume of files, > it should probably be split up. > > > Someone please try them out and report back. > I did test them. They install/uninstall, modify $path, and cm3 runs. > > > - Jay From jay.krell at cornell.edu Mon Jun 29 05:38:28 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 03:38:28 +0000 Subject: [M3devel] pruning m3cc/gcc? Message-ID: I keep thinking of deleting m3-sys/m3cc/gcc/intl m3-sys/m3cc/gcc/libgomp m3-sys/m3cc/gcc/libmudflap m3-sys/m3cc/gcc/libssp m3-sys/m3cc/gcc/fixincludes m3-sys/m3cc/gcc/libgcc We don't use any of it. Some of these deletions would shorten our build command lines. Though some (esp. fixincludes and maybe libgcc) might break the shortest configure + make that the "real" cm3 doesn't use but can be useful. I didn't include them in gcc-interix and gcc-apple. But there are two possible contradictory goals: - just have what we use/change - have a complete merged gcc tree from which you could build gcc/cc1 and not just cm3cg Except we don't have C++, Java, Ada, Fortran, so we don't really have this, but C probably counts for something. If the second is the goal, don't delete. If the first is the goal, delete. There is also "having it all there in case it is needed or somesuch", but that's easy enough to get elsewhere. - Jay From jay.krell at cornell.edu Mon Jun 29 06:29:12 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 28 Jun 2009 21:29:12 -0700 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: References: Message-ID: Truncated again I think, can't fix right now. - Jay (phone) On Jun 28, 2009, at 8:18 PM, Jay wrote: > > Was truncated. > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: .msi files for Windows available >> Date: Mon, 29 Jun 2009 03:08:44 +0000 >> >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives >> >> now contains .msi files for Windows: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >> >> >> These are some of the first .msi files I have ever made. >> I used WiX. scripts/python/make-dist.py makes them. >> >> >> Some of the highlights/lowlights: >> They always install all of what they have. There is not (yet) >> support for the package sets. >> They always modify %PATH%. It should be an option. >> They append to %PATH%. My intent was to prepend. (It appears obvious >> how, but it didn't work.) >> They have an uninstaller, listed in add/remove programs. >> Not listed in the start menu. That seems to be go either way in >> practise. >> The uninstaller does remove c:\cm3\bin from %path%, besides deleting >> all the files -- that didn't take any extra work. >> They don't put anything in the start menu. >> What would it be? Oh, I need to try cm3ide, which probably isn't here From jay.krell at cornell.edu Mon Jun 29 06:30:57 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 28 Jun 2009 21:30:57 -0700 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: References: Message-ID: <4C1F69E7-385E-4713-9431-06B561964450@hotmail.com> This also truncated.. - Jay (phone) On Jun 28, 2009, at 8:38 PM, Jay wrote: > > I keep thinking of deleting > > m3-sys/m3cc/gcc/intl > m3-sys/m3cc/gcc/libgomp > m3-sys/m3cc/gcc/libmudflap > m3-sys/m3cc/gcc/libssp > m3-sys/m3cc/gcc/fixincludes > m3-sys/m3cc/gcc/libgcc > > > We don't use any of it. > Some of these deletions would shorten our build command lines. > Though some (esp. fixincludes and maybe libgcc) might break the > shortest configure + make that the "real" cm3 doesn't use but can be > useful From hosking at cs.purdue.edu Mon Jun 29 15:41:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 29 Jun 2009 09:41:09 -0400 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: References: Message-ID: <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu> I personally like having the ability to build C from the same source tree. It's useful for debugging the backend sometimes (looking at the equivalent code generated from C). On 28 Jun 2009, at 23:38, Jay wrote: > > I keep thinking of deleting > > m3-sys/m3cc/gcc/intl > m3-sys/m3cc/gcc/libgomp > m3-sys/m3cc/gcc/libmudflap > m3-sys/m3cc/gcc/libssp > m3-sys/m3cc/gcc/fixincludes > m3-sys/m3cc/gcc/libgcc > > > We don't use any of it. > Some of these deletions would shorten our build command lines. > Though some (esp. fixincludes and maybe libgcc) might break the > shortest configure + make that the "real" cm3 doesn't use but can be > useful. > > > I didn't include them in gcc-interix and gcc-apple. > > > But there are two possible contradictory goals: > > > - just have what we use/change > - have a complete merged gcc tree from which you > could build gcc/cc1 and not just cm3cg > Except we don't have C++, Java, Ada, Fortran, > so we don't really have this, but C probably counts for something. > > > If the second is the goal, don't delete. > If the first is the goal, delete. > > > There is also "having it all there in case it is needed > or somesuch", but that's easy enough to get elsewhere. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 29 16:42:54 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 14:42:54 +0000 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu> References: <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu> Message-ID: Ok, presumably then ok to prune it just partly, like intl, libssp, libmudflap, libgomp, treelang, beyond that (fixincludes, libgcc) would require some checking/testing. Might even be worthwhile to "simplify" the m3makefile and reach a compromise that works only by some deletion. Really I wish somehow gmp/mpfr built more quickly. I often delete their source locally but can't commit that. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 29 Jun 2009 09:41:09 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pruning m3cc/gcc? > > I personally like having the ability to build C from the same source tree. It's useful for debugging the backend sometimes (looking at the equivalent code generated from C). > > On 28 Jun 2009, at 23:38, Jay wrote: > > > I keep thinking of deleting > > m3-sys/m3cc/gcc/intl > m3-sys/m3cc/gcc/libgomp > m3-sys/m3cc/gcc/libmudflap > m3-sys/m3cc/gcc/libssp > m3-sys/m3cc/gcc/fixincludes > m3-sys/m3cc/gcc/libgcc > > > We don't use any of it. > Some of these deletions would shorten our build command lines. > Though some (esp. fixincludes and maybe libgcc) might break the > shortest configure + make that the "real" cm3 doesn't use but can be useful. > > > I didn't include them in gcc-interix and gcc-apple. > > > But there are two possible contradictory goals: > > > - just have what we use/change > - have a complete merged gcc tree from which you > could build gcc/cc1 and not just cm3cg > Except we don't have C++, Java, Ada, Fortran, > so we don't really have this, but C probably counts for something. > > > If the second is the goal, don't delete. > If the first is the goal, delete. > > > There is also "having it all there in case it is needed > or somesuch", but that's easy enough to get elsewhere. > > > - Jay > From jay.krell at cornell.edu Mon Jun 29 17:32:29 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 15:32:29 +0000 Subject: [M3devel] some testing of the new web pages Message-ID: I do like the new web pages. Here are some problems though. http://www.opencm3.net/releng/collection-core.html go down to m3-sys/cm3 the builder and freebsd manual page links aren't right. I think these are maybe just CVS merge conflicts that happen to be on the packaging machine and can just be deleted. Not clear if most of the gcc links are useful. go down to TCL interfaces for M3 The browse sources link doesn't work. Probably related to this not always building and not built. Probably need to modify this and require people doing package building to have Tcl installed, maybe even for NT386. Probably specifically make-dist.sh should set $ENABLE_TCL or somesuch. (not exactly) The source links present, e.g. the licenses oddly, but compactly and probably a good thing, e.g.: http://www.opencm3.net/doc/help/gen_html/tcp/src/common/StreamRdClass.m3.html Probably an artifact of m3tohtml. http://www.opencm3.net/releng Go down the righthand side trying everything to one level. Broken: http://www.opencm3.net/releng/collection-min.html http://www.opencm3.net/releng/collection-caltech.html But there is: http://www.opencm3.net/releng/collection-caltech-parser.html It contains m3-win/import-libs but shouldn't. I suspect the problems are rooted in: min is a non-ws package set but not a ws package set. Because it is overlys small and core subsumes it? caltech-parser contains a dash. min to me is specifically enough to start with an old release and build a current compiler and release -- m3core, libm3, m3cg, cm3, maybe sysutils specifically it is the pieces required to compile anything (cm3, m3cg) and the pieces that an old compiler may not be able to build the the current versions of (m3core/libm3) that a current compiler will need; That is, if you want to build natively build the whole system from source, this is the smallest you can start with. m3cg actually isn't in min but probably handled specially. Related couments usually but not always has one extra empty bullet, including but not limited to when the list is empty: http://www.opencm3.net/releng/collection-cvsup.html http://www.opencm3.net/releng/collection-anim.html http://www.opencm3.net/releng/collection-cvsup.html http://www.opencm3.net/releng/collection-database.html http://www.opencm3.net/releng/collection-demo.html http://www.opencm3.net/releng/collection-devlib.html http://www.opencm3.net/releng/collection-game.html http://www.opencm3.net/releng/collection-gui.html This is not all the ones with an extra bullet, and a few don't have the extra bullet. I'm on the fence on the whole ws thing. Non-ws also has matching source. The point is to provide the packages both built and buildable? If cm3 had a mode that started with assemble then link and ship, we could cross build all the ws packages, very nice. I guess the "real" problem is I feel compelled then to match this feature in make-dist.py. http://www.opencm3.net/releng/collection-tool.html Try the first few links. mtex Browse sources seems incomplete but maybe is right. The man page links are all broken. cmpdir shows a general pattern: maybe directories with no files shouldn't be shown? http://www.opencm3.net/releng/collection-demo.html fisheye The link manual page .makefile isn't right http://www.opencm3.net/releng/collection-devlib.html m3tk Several broken manpage links. pex browse sources doesn't work Probably like Tcl, not always built. http://www.opencm3.net/releng/collection-anim.html zeus contains a broken Zeus manual page, I think a CVS conflict file Might be able to search for this generally in the html. http://www.opencm3.net/releng/collection-obliq.html related documents first link, to polymtl, broken, sounds promising, maybe we can find it and host it http://www.opencm3.net/releng/collection-m3gdb.html m3gdb Like m3cc, maybe some of these READMEs not useful. - Jay From hosking at cs.purdue.edu Mon Jun 29 18:01:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 29 Jun 2009 12:01:16 -0400 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: References: <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu> Message-ID: <7D2B9349-BCBA-46DE-8465-F50EEBB70F22@cs.purdue.edu> Please leave treelang. It is a good model for building gcc IR trees as done by cm3cg. On 29 Jun 2009, at 10:42, Jay wrote: > > Ok, presumably then ok to prune it just partly, like intl, libssp, > libmudflap, libgomp, treelang, beyond that (fixincludes, libgcc) > would require some checking/testing. Might even be worthwhile to > "simplify" the m3makefile and reach a compromise that works only by > some deletion. > Really I wish somehow gmp/mpfr built more quickly. I often delete > their source locally but can't commit that. > > - Jay > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Mon, 29 Jun 2009 09:41:09 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] pruning m3cc/gcc? >> >> I personally like having the ability to build C from the same >> source tree. It's useful for debugging the backend sometimes >> (looking at the equivalent code generated from C). >> >> On 28 Jun 2009, at 23:38, Jay wrote: >> >> >> I keep thinking of deleting >> >> m3-sys/m3cc/gcc/intl >> m3-sys/m3cc/gcc/libgomp >> m3-sys/m3cc/gcc/libmudflap >> m3-sys/m3cc/gcc/libssp >> m3-sys/m3cc/gcc/fixincludes >> m3-sys/m3cc/gcc/libgcc >> >> >> We don't use any of it. >> Some of these deletions would shorten our build command lines. >> Though some (esp. fixincludes and maybe libgcc) might break the >> shortest configure + make that the "real" cm3 doesn't use but can >> be useful. >> >> >> I didn't include them in gcc-interix and gcc-apple. >> >> >> But there are two possible contradictory goals: >> >> >> - just have what we use/change >> - have a complete merged gcc tree from which you >> could build gcc/cc1 and not just cm3cg >> Except we don't have C++, Java, Ada, Fortran, >> so we don't really have this, but C probably counts for something. >> >> >> If the second is the goal, don't delete. >> If the first is the goal, delete. >> >> >> There is also "having it all there in case it is needed >> or somesuch", but that's easy enough to get elsewhere. >> >> >> - Jay >> From lists at darko.org Mon Jun 29 17:43:09 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 29 Jun 2009 17:43:09 +0200 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: References: Message-ID: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Are we going to have Installer packages for Darwin PPC/Intel too or is there some reason not too? On 29/06/2009, at 5:18 AM, Jay wrote: > > Was truncated. > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: .msi files for Windows available >> Date: Mon, 29 Jun 2009 03:08:44 +0000 >> >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives >> >> now contains .msi files for Windows: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >> >> >> These are some of the first .msi files I have ever made. >> I used WiX. scripts/python/make-dist.py makes them. >> >> >> Some of the highlights/lowlights: >> They always install all of what they have. There is not (yet) >> support for the package sets. >> They always modify %PATH%. It should be an option. >> They append to %PATH%. My intent was to prepend. (It appears obvious >> how, but it didn't work.) >> They have an uninstaller, listed in add/remove programs. >> Not listed in the start menu. That seems to be go either way in >> practise. >> The uninstaller does remove c:\cm3\bin from %path%, besides deleting >> all the files -- that didn't take any extra work. >> They don't put anything in the start menu. >> What would it be? Oh, I need to try cm3ide, which probably isn't here From jay.krell at cornell.edu Mon Jun 29 19:15:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:15:52 +0000 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> References: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Message-ID: Eventually, but not by me probably for at least a week or a month or more. RPM too. It should probably come before Mac. Except that I don't have any Suse/RedHat/YellowDog/Mandrake/Mandriva systems now, having settled pretty exclusively on Debian (plus the Fit PC that came with Gentoo preinstalled), so I don't know. *BSD also should get some attention. But I don't see me getting to that for a while. It would be nice to compete with the ezm3 port that is out there. It builds from assembly source, which is good, to see there is a precedent we can follow. There are a lot of other formats but I probably won't get to any of them. HP-UX, Solaris, AIX, Irix all have something, and no users. I don't know yet about Tru64 and VMS. Btw, the DESTDIR-like feature that (you?) added to cm3 isn't really needed. You can just $CM3_INSTALL and it does basically the same thing. Look at Olaf's make-dist.sh. It gets a lot done with little code using simple techniques. But I'm still sticking to Python. :) I don't think the DESTDIR-like feature handled runpaths or config files as well, which are mostly moot now. (Really..runpath solved by $ORIGIN, but $ORIGIN doesn't solve the problem. $ORIGIN lets you move a set of files together, good, but it doesn't help the situation where you want to move just some of them.) - Jay ---------------------------------------- > From: lists at darko.org > To: jay.krell at cornell.edu > Date: Mon, 29 Jun 2009 17:43:09 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: .msi files for Windows available > > Are we going to have Installer packages for Darwin PPC/Intel too or is > there some reason not too? > > > On 29/06/2009, at 5:18 AM, Jay wrote: > >> >> Was truncated. >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Subject: .msi files for Windows available >>> Date: Mon, 29 Jun 2009 03:08:44 +0000 >>> >>> >>> >>> http://modula3.elegosoft.com/cm3/uploaded-archives >>> >>> now contains .msi files for Windows: >>> >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>> >>> >>> These are some of the first .msi files I have ever made. >>> I used WiX. scripts/python/make-dist.py makes them. >>> >>> >>> Some of the highlights/lowlights: >>> They always install all of what they have. There is not (yet) >>> support for the package sets. >>> They always modify %PATH%. It should be an option. >>> They append to %PATH%. My intent was to prepend. (It appears obvious >>> how, but it didn't work.) >>> They have an uninstaller, listed in add/remove programs. >>> Not listed in the start menu. That seems to be go either way in >>> practise. >>> The uninstaller does remove c:\cm3\bin from %path%, besides deleting >>> all the files -- that didn't take any extra work. >>> They don't put anything in the start menu. >>> What would it be? Oh, I need to try cm3ide, which probably isn't here > From jay.krell at cornell.edu Mon Jun 29 19:23:39 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:23:39 +0000 Subject: [M3devel] pruning m3cc/gcc? Message-ID: [trying to untruncate again, though I think Tony quoted the whole thing] ---------------------------------------- > From: jay > To: m3devel; hosking > Subject: pruning m3cc/gcc? > Date: Mon, 29 Jun 2009 03:38:28 +0000 > > > I keep thinking of deleting > [snip, parts of gcc] > > We don't use any of it. > Some of these deletions would shorten our build command lines. > Though some (esp. fixincludes and maybe libgcc) might break the > shortest configure + make that the "real" cm3 doesn't use but can be useful. > > > I didn't include them in gcc-interix and gcc-apple. > > > But there are two possible contradictory goals: > > > - just have what we use/change > - have a complete merged gcc tree from which you > could build gcc/cc1 and not just cm3cg > Except we don't have C++, Java, Ada, Fortran, > so we don't really have this, but C probably counts for something. > > > If the second is the goal, don't delete. > If the first is the goal, delete. > > > There is also "having it all there in case it is needed > or somesuch", but that's easy enough to get elsewhere. > > > - Jay From jay.krell at cornell.edu Mon Jun 29 19:21:07 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:21:07 +0000 Subject: [M3devel] .msi files for Windows available Message-ID: [trying to untruncate again, I forget if it is forward or replayall that untruncates] ---------------------------------------- > From: jay > > > Was truncated. > > > ---------------------------------------- >> From: jay >> To: m3devel >> Subject: .msi files for Windows available >> Date: Mon, 29 Jun 2009 03:08:44 +0000 >> >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives >> >> now contains .msi files for Windows: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >> >> >> These are some of the first .msi files I have ever made. >> I used WiX. scripts/python/make-dist.py makes them. >> >> >> Some of the highlights/lowlights: >> They always install all of what they have. There is not (yet) >> support for the package sets. >> They always modify %PATH%. It should be an option. >> They append to %PATH%. My intent was to prepend. (It appears obvious >> how, but it didn't work.) >> They have an uninstaller, listed in add/remove programs. >> Not listed in the start menu. That seems to be go either way in practise. >> The uninstaller does remove c:\cm3\bin from %path%, besides deleting >> all the files -- that didn't take any extra work. >> They don't put anything in the start menu. [approximate point of truncation] >> What would it be? Oh, I need to try cm3ide, which probably isn't here. >> The config file still just runs cl.exe/link.exe from %path%. >> I think the way to address this is in the config file, not setup. >> The default install location is c:\cm3 but user can change it. >> The presentation of the licenses is quite ugly. And perhaps unnecessary? >> Not seemingly not easy to remove, without copy/pasting some code/data with yet another license. >> There are accidentally two .pdbs (symbols) in the .msis. >> (More geerally the symbols are: >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1-symbols.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1-symbols.zip >> and the same content without installation is at >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip >> ) >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives >> is a bit messy due to the volume of files, >> it should probably be split up. >> >> >> Someone please try them out and report back. >> I did test them. They install/uninstall, modify $path, and cm3 runs. >> >> >> - Jay From jay.krell at cornell.edu Mon Jun 29 19:40:02 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:40:02 +0000 Subject: [M3devel] .msi files for Windows available In-Reply-To: References: Message-ID: Was truncated again.. ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 29 Jun 2009 17:21:07 +0000 > Subject: Re: [M3devel] .msi files for Windows available > > > [trying to untruncate again, I forget if it is forward or replayall that untruncates] > > > ---------------------------------------- >> From: jay >> >> >> Was truncated. >> >> >> ---------------------------------------- [deliberately truncated this time] From jay.krell at cornell.edu Mon Jun 29 19:41:32 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:41:32 +0000 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> References: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Message-ID: [was severely truncated darnit] ---------------------------------------- > From: jay.krell at cornell.edu > To: lists at darko.org > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: .msi files for Windows available > Date: Mon, 29 Jun 2009 17:15:52 +0000 > > > Eventually, but not by me probably for at least a week or a month or more. > > > RPM too. It should probably come before Mac. > Except that I don't have any Suse/RedHat/YellowDog/Mandrake/Mandriva systems now, having settled pretty exclusively on Debian (plus the Fit PC that came with Gentoo preinstalled), so I don't know. > > > *BSD also should get some attention. > But I don't see me getting to that for a while. > It would be nice to compete with the ezm3 port that is out there. > It builds from assembly source, which is good, to see there is a precedent we can follow. > > > There are a lot of other formats but I probably won't get to any of them. > HP-UX, Solaris, AIX, Irix all have something, and no users. > I don't know yet about Tru64 and VMS. > > > Btw, the DESTDIR-like feature that (you?) added to cm3 isn't really needed. > You can just $CM3_INSTALL and it does basically the same thing. > Look at Olaf's make-dist.sh. > It gets a lot done with little code using simple techniques. > But I'm still sticking to Python. :) > > > I don't think the DESTDIR-like feature handled runpaths or config files as well, which are mostly moot now. > > > (Really..runpath solved by $ORIGIN, but $ORIGIN doesn't solve the problem. $ORIGIN lets you move a set of files together, good, but it doesn't help the situation where you want to move just some of them.) > > > - Jay > > > ---------------------------------------- >> From: lists at darko.org >> To: jay.krell at cornell.edu >> Date: Mon, 29 Jun 2009 17:43:09 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] FW: .msi files for Windows available >> >> Are we going to have Installer packages for Darwin PPC/Intel too or is >> there some reason not too? >> >> [deliberately truncated] From jay.krell at cornell.edu Mon Jun 29 19:52:04 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:52:04 +0000 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: References: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Message-ID: > [was severely truncated darnit trying again and with additional tactics..] I put it here assuming it is truncated again: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt http://modula3.elegosoft.com/cm3/uploaded-archives is a bit messy due to the volume of files, it should probably be split up? Someone please try them out and report back. I did test them. They install/uninstall, modify $path, and cm3 runs. Some of the highlights/lowlights: They always install all of what they have. There is not (yet) support for the package sets. They always modify %PATH%. It should be an option. They append to %PATH%. My intent was to prepend. (It appears obvious how, but it didn't work.) They have an uninstaller, listed in add/remove programs. Not listed in the start menu. That seems to be go either way in practise. The uninstaller does remove c:\cm3\bin from %path%, besides deleting all the files -- that didn't take any extra work. They don't put anything in the start menu. [approximate truncation point ...] What would it be? Oh, I need to try cm3ide, which probably isn't here. The config file still just runs cl.exe/link.exe from %path%. I think the way to address this is in the config file, not setup. The default install location is c:\cm3 but user can change it. The presentation of the licenses is quite ugly. And perhaps unnecessary? Not seemingly not easy to remove, without copy/pasting some code/data with yet another license. There are accidentally two .pdbs (symbols) in the .msis. (More geerally the symbols are: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1-symbols.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1-symbols.zip and the same content without installation is at http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip ) - Jay From lists at darko.org Mon Jun 29 22:45:08 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 29 Jun 2009 22:45:08 +0200 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: References: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Message-ID: <7B6DD6CB-BFB0-405C-A4B4-00EA1340A82E@darko.org> DESTDIR wasn't me. On 29/06/2009, at 7:15 PM, Jay wrote: > > Eventually, but not by me probably for at least a week or a month or > more. > > > RPM too. It should probably come before Mac. > Except that I don't have any Suse/RedHat/YellowDog/Mandrake/ > Mandriva systems now, having settled pretty exclusively on Debian > (plus the Fit PC that came with Gentoo preinstalled), so I don't know. > > > *BSD also should get some attention. > But I don't see me getting to that for a while. > It would be nice to compete with the ezm3 port that is out there. > It builds from assembly source, which is good, to see there is a > precedent we can follow. > > > There are a lot of other formats but I probably won't get to any of > them. > HP-UX, Solaris, AIX, Irix all have something, and no users. > I don't know yet about Tru64 and VMS. > > > Btw, the DESTDIR-like feature that (you?) added to cm3 isn't really > needed. > You can just $CM3_INSTALL and it does basically the same thing. > Look at Olaf's make-dist.sh. > It gets a lot done with little code using simple techniques. > But I'm still sticking to Python. :) > > > I don't think the DESTDIR-like feature handled runpaths or config > files as well, which are mostly moot now. > > > (Really..runpath solved by $ORIGIN, but $ORIGIN doesn't solve the > problem. $ORIGIN lets you move a set of files together, good, but it > doesn't help the situation where you want to move just some of them.) > > > - Jay > > > ---------------------------------------- >> From: lists at darko.org >> To: jay.krell at cornell.edu >> Date: Mon, 29 Jun 2009 17:43:09 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] FW: .msi files for Windows available >> >> Are we going to have Installer packages for Darwin PPC/Intel too or >> is >> there some reason not too? >> >> >> On 29/06/2009, at 5:18 AM, Jay wrote: >> >>> >>> Was truncated. >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Subject: .msi files for Windows available >>>> Date: Mon, 29 Jun 2009 03:08:44 +0000 >>>> >>>> >>>> >>>> http://modula3.elegosoft.com/cm3/uploaded-archives >>>> >>>> now contains .msi files for Windows: >>>> >>>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >>>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>>> >>>> >>>> These are some of the first .msi files I have ever made. >>>> I used WiX. scripts/python/make-dist.py makes them. >>>> >>>> >>>> Some of the highlights/lowlights: >>>> They always install all of what they have. There is not (yet) >>>> support for the package sets. >>>> They always modify %PATH%. It should be an option. >>>> They append to %PATH%. My intent was to prepend. (It appears >>>> obvious >>>> how, but it didn't work.) >>>> They have an uninstaller, listed in add/remove programs. >>>> Not listed in the start menu. That seems to be go either way in >>>> practise. >>>> The uninstaller does remove c:\cm3\bin from %path%, besides >>>> deleting >>>> all the files -- that didn't take any extra work. >>>> They don't put anything in the start menu. >>>> What would it be? Oh, I need to try cm3ide, which probably isn't >>>> here >> From wagner at elegosoft.com Tue Jun 30 09:28:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 30 Jun 2009 09:28:26 +0200 Subject: [M3devel] release build broken Message-ID: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> The last commit to pkginfo.txt broke the Tinderbox release build: End of Log File "../src/Main.m3", line 4: unable to find interface (WinNT) "../src/Main.m3", line 5: unable to find interface (WinDef) compilation failed => not building program "mklib" Fatal Error: package build failed *** execution of cm3 -build -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? -DCM3_LAST_CHANGED=?2009-05-16? $RARGS && cm3 -ship $RARGS -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? -DCM3_LAST_CHANGED=?2009-05-16? failed *** Please fix. 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 Jun 30 11:07:50 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 30 Jun 2009 09:07:50 +0000 Subject: [M3devel] release build broken In-Reply-To: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> References: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> Message-ID: Ah, only the release build but not the latest, makes sense. These weren't in m3core in older version. Will fix. After this release I can put it back. - Jay ---------------------------------------- > Date: Tue, 30 Jun 2009 09:28:26 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release build broken > > The last commit to pkginfo.txt broke the Tinderbox release build: > > End of Log File > "../src/Main.m3", line 4: unable to find interface (WinNT) > "../src/Main.m3", line 5: unable to find interface (WinDef) > compilation failed => not building program "mklib" > Fatal Error: package build failed > *** execution of cm3 -build > -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? > -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? > -DCM3_LAST_CHANGED=?2009-05-16? $RARGS && cm3 -ship $RARGS > -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? > -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? > -DCM3_LAST_CHANGED=?2009-05-16? failed *** > > > Please fix. > > 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 wagner at elegosoft.com Tue Jun 30 18:27:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 30 Jun 2009 18:27:28 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090628183458.GA11305@topoi.pooq.com> References: <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090628183458.GA11305@topoi.pooq.com> Message-ID: <20090630182728.3604voxlcsococs0@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: >> Quoting Jay : >> >> > >> >I tested the LINUXLIBC6 archive and it installed ok, no prompting. >> > >> >I ran it with no parameters -- unlike Henrik. It did mention the >> >current working directory (or its directory, same thing) as the >> >install source, which confused me. Probably as long as system.tgz >> >exists where it expects, it shouldn't say anything. >> >> Strange. >> >> Hendrik, can you reproduce the strange message? And then perhaps >> provide a system call trace (ktrace, truss, whatever)? > > No. I have not been able to reproduce it. Tried three times: > (1) with the existing preexisting incomplete /usr/local/cm3, and no > references to any cm3 stuff in $PATH > (2) without any /usr/local/cm3 (I used rm -r to erase it), and no > references to any cm3 stuff ini $PATH > (3) witout any /usr/local/cm3, and a reference to bin within the > unpacked ancient cm3-min archive in my $PATH (which is how is was when I > first got the message). (And this is how I've cm3-min to compile and > run even though its installation failed as reported here long ago) > > All these installations were from the same ~hendrik/cm3 directory > resulting from the archive I had unpacked a while ago when I got the > strange message. I haven't downloaded a new archive since then. Maybe > I should retry creating a new unpacked archive every time? Or should I > just give up? If it now just works and the problem cannot be reproduced, we should leave it that way. I wouldn't invest much time on chasing down such a spurious error now. 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 Tue Jun 30 19:52:28 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 30 Jun 2009 13:52:28 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090630182728.3604voxlcsococs0@mail.elegosoft.com> References: <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090628183458.GA11305@topoi.pooq.com> <20090630182728.3604voxlcsococs0@mail.elegosoft.com> Message-ID: <20090630175228.GA16767@topoi.pooq.com> On Tue, Jun 30, 2009 at 06:27:28PM +0200, Olaf Wagner wrote: > > If it now just works and the problem cannot be reproduced, we should > leave it that way. I wouldn't invest much time on chasing down such > a spurious error now. OK. I'll take a look at installation instructions for some of the other packages, such as the one with Trestle. -- hendrik From hosking at cs.purdue.edu Mon Jun 1 01:01:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 1 Jun 2009 09:01:55 +1000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: References: Message-ID: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> Jay, things changed from gcc 3.2 to 3.3. 3.3 works fine for me on all the h/w targets I've tried using -O3 (PPC, x86, AMD64, SPARC). I suspect this is specific to your gcc-apple hybrid. On 1 Jun 2009, at 00:49, Jay wrote: > 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 jay.krell at cornell.edu Mon Jun 1 18:46:38 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 1 Jun 2009 16:46:38 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> References: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> Message-ID: It isn't related to optimization. I don't think it is 4.2/4.3 specific. I'll try to show an example later (MIPS64_OPENBSD and, never looked at them, but maybe othar arm/mips will show it). - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 1 Jun 2009 09:01:55 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] m3_load/store using bitfields for everything Jay, things changed from gcc 3.2 to 3.3. 3.3 works fine for me on all the h/w targets I've tried using -O3 (PPC, x86, AMD64, SPARC). I suspect this is specific to your gcc-apple hybrid. On 1 Jun 2009, at 00:49, Jay wrote: 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 rodney.m.bates at cox.net Mon Jun 1 21:32:33 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 01 Jun 2009 14:32:33 -0500 Subject: [M3devel] Some workarounds for m3gdb input and output of floating values. Message-ID: <4A242CD1.10504@cox.net> I recently committed a couple of changes that give m3gdb some very tenuous support of floating values. Printing them appears to work in a few tests on LINUXLIBC6. This relies on the preexisting C floating support, but this really needs some more thorough review. Moreover, Modula-3 style floating literals are not being recognized. Until it is fixed right, here are some ways to work around its limitations. They are a bit tedious, but should allow you to do what you need to do, using m3gdb calls on Modula-3 library code. The idea is just to call procedures in Lex, Fmt, etc. To print a value in Modula-3 form, do, e.g.: (m3gdb) print Fmt.Real(LF,Fmt.Style.Fix,10,FALSE) $1 = (*16_b737876c*) "1.1250000000" Note that m3gdb has no knowledge of defaulted parameters, so you have to supply them all explicitly. To assign a literal value, do, e.g.: (m3gdb) print LF := Lex.Real(TextRd.New("2.375")) $2 = 2.375 (m3gdb) p Fmt.Real(LF,Fmt.Style.Fix,10,FALSE) $3 = (*16_b73787dc*) "2.3750000000" Few or none of these calls will work unless Lex, Fmt, and TextRd are imported somewhere in the import closure of your program. Otherwise, they have uninitialized data and many will segfault or otherwise fail when called by m3gdb. Rodney Bates From hosking at cs.purdue.edu Tue Jun 2 02:04:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 2 Jun 2009 10:04:37 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> Message-ID: <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> The compiler and run-time support is already in the CVS head. On 1 Jun 2009, at 22:21, Darko wrote: > This is a great little hack. Is it available now or are you still > working on it? I don't know what other people want to use it for but > this is a great way to link memory structures with external data. It > overcomes one of the downsides of GC compared to say C, where you > can use pointer values for other purposes, but it does it safely. > > Also I'd like to add my voice for the minimalist approach where no > language changes are made. I don't think there is a semantically > clean way of incorporating this into the language and I'm not sure > there is any payoff in doing so. > > > > On 23/04/2009, at 3:07 AM, Tony Hosking wrote: > >> On 23 Apr 2009, at 09:41, Mika Nystrom wrote: >> >>> "Rodney M. Bates" writes: >>>> Tony Hosking wrote: >>>>> On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: >>>>> >>>>>> I am going to try to resummarize the various proposals, as their >>>>>> description has now gotten rather scattered around in all the >>>>>> discussion. >>>>>> --------------------------------------------------------------------- >>>>>> Mika's proposal (I'll call it the "minimalist" propsal): >>>>>> >>>>>> Mika, please correct me if I misrepresent what you are proposing. >>>>>> >>>>>> There are no language changes at all, only changes in >>>>>> implementation. >>>>>> The implementation of the existing type REFANY, and no other >>>>>> type, >>>>>> allows it to have values whose lsb is nonzero. ISTYPE, NARROW, >>>>>> TYPECASE, and narrowing assignments, when and only when applied >>>>>> to >>>>>> REFANY, have their generated code fixed so it checks the lsb, >>>>>> and, if >>>>>> it is nonzero, consider the runtime type check to have failed, in >>>>>> whichever way such a failure is already handled. >>>>>> >>>>>> The only effect is to liberalize the rules unsafe code must >>>>>> follow to >>>>>> avoid undermining the safety of safe code. Only unsafe code can >>>>>> create or detect these misaligned values. Today, it must never >>>>>> return >>>>>> them in a variable of any reference type, lest the four narrowing >>>>>> operations unexpectedly crash. In the proposal, unsafe code >>>>>> would be >>>>>> able to return such values in variables of type REFANY, but not >>>>>> any >>>>>> other type. >>> >>> This is pretty much exactly what I was proposing, yes. >>> >>> Only one point to add, and that is that you need a TYPECODE value. >> >> Yes. I currently have a full-blown implementation in the compiler >> and run-time that uses RT0.RefanyTypecode as the typecode. Since >> the only thing that will respond with the typecode are tagged >> references, and it is not legal to say TYPECODE(REFANY) we can hide >> that fact in an implementation of the tagged interface where we use >> TYPECODE(r) = RT0.RefanyTypecode, or ISTYPE(r, >> RT0.RefanyTypecode). Currently, no other type in the system will >> respond with that. >> >>> I think Tony and I discussed having all the ISTYPE etc. behave as >>> if the tagged values were of a specific opaque type that cannot be >>> dereferenced, newed, etc., in safe modules. (I.e., revealed as <: >>> REFANY only) >> >> Done (modulo what typecode to use as described above). >> >>> This seems conceptually simpler than introducing a "nonexistent" >>> type, and has the same safety properties. >>> >>>>> >>>>> I don't see why we can't have safe creation of the misaligned >>>>> values >>>>> as per Mika's interface. >>>> >>>> Well, somebody has to implement that interface, and that module >>>> will >>>> have to be UNSAFE. >>>> You weren't thinking of implementing it in C were you? ;-) >>> >>> I don't see how to do it "safely" unless you add it to the compiler >>> itself? (Which means it's no longer minimalist!) >> >> It would be hidden behind a safe interface. >> >>>>>> Already, the only things safe code can do with values of REFANY >>>>>> are >>>>>> copy them around (which would happily work on misaligned >>>>>> values) and >>>>>> narrow them. With the implementation of the narrowing operations >>>>>> changed, misaligned values can never escape from REFANY >>>>>> variables. >>>>>> >>>>>> In safe code, there is no way to detect whether a value of type >>>>>> REFANY >>>>>> is misaligned. Doing it by elimination, trying to narrow to any >>>>>> proper subtype of REFANY, is impractical, as there are an >>>>>> unbounded >>>>>> number of REF types to eliminate. >>>>> >>>>> An alternative would be to loosen the language spec to allow >>>>> TYPECODE(REFANY) and use this typecode for tagged references. >>>>> Then >>>>> one can explicitly test for it without elimination of >>>>> alternatives. >>> >>> Yes you could do this or use the specific type idea mentioned above. >>> >>> I don't see what harm there is in letting a safe module know that >>> it's holding a tagged value. Nothing it can do with that >>> information >>> anyhow... it can't extract the value. >>> >>>>> >>>>>> If there is more than one abstract data type that uses this >>>>>> mechanism, >>>>>> client code can not be prevented from mixing up values from the >>>>>> different abstractions. (Perhaps this could be fixed by a >>>>>> language >>>>>> change allowing BRANDED REFANY?) >>>>> >>>>> Indeed. >>> >>> Right. As it stands, the clients would have to sort on what's going >>> on inside. No help from compiler or runtime. You can't do anything >>> about what's checkable at runtime, but adding TAGGED could let you >>> check a lot of things at compile time. >>> >>> I still think, though (referring to what's below), that the >>> advantage >>> of not having to change existing "container" code outweighs the >>> cost of checking the LSB (which is likely to be negligble), and I >>> would >>> therefore recommend that the type called "REFANY" be able to hold >>> "TAGGED" >>> values after such a language change. >> >> Right. >> >>> >>> >>> Mika >>> >>>>> >>>>>> --------------------------------------------------------------------- >>>>>> My (Rodney's) "safe" proposal: >>>>>> >>>>>> There is a new type named TAGABLE. It is a subrange of >>>>>> INTEGER, whose >>>>>> bounds are implementation-defined. These can be queried by the >>>>>> existing FIRST and LAST functions. Similar to CARDINAL, it has >>>>>> all >>>>>> the properties of a subrange type but is not the same type as the >>>>>> corresponding subrange. >>>>>> >>>>>> There is a new type constructor TAGGED. If T is any traced or >>>>>> object >>>>>> type, including branded and opaque types, then TAGGED T is a >>>>>> new type >>>>>> whose value set is the union of the value sets of T and TAGABLE. >>>>>> Moreover, >>>>>> >>>>>> TAGABLE <: TAGGED T >>>>>> T <: TAGGED T. >>>>>> >>>>>> IF T # U, then TAGGED T and TAGGED U are not the same type and >>>>>> have no >>>>>> subtype or assignability relation to each other. >>>>>> >>>>>> The semantics of ISTYPE, NARROW, TYPECASE, and assignability of >>>>>> a type >>>>>> to a type are generalized so that their to-be-narrowed operand >>>>>> can >>>>>> have a tagged type, and if it does, their to-be-narrowed-to >>>>>> type can >>>>>> be TAGABLE. >>>>> >>>>> Hmm. It seems there is a nasty loophole in your spec. >>>>> Consider: >>>>> >>>>> TYPE T = BRANDED OBJECT END >>>>> TYPE U = BRANDED OBJECT END >>>>> >>>>> These are unrelated types. >>>>> >>>>> Now, the rules let me take: >>>>> >>>>> t: TAGGED T >>>>> >>>>> and obtain: >>>>> >>>>> i: TAGABLE := NARROW(t, TAGABLE); >>>>> >>>>> But TAGABLE <: TAGGED U >>>>> >>>>> so I can do: >>>>> >>>>> u: TAGGED U := t; >>>>> >>>>> Is that your intention? >>>>> >>>>>> >>>>>> >>>>>> Comments: >>>>>> >>>>>> Making TAGGED T have no relation to TAGGED U avoids a lot of >>>>>> really >>>>>> complicated type equality and subtype rules. The former would >>>>>> be a >>>>>> drastic departure from the current state of Modula-3. >>>>>> >>>>>> It is up to the implementation to decide the bit representation >>>>>> of >>>>>> tagged types, including how values of TAGABLE will be >>>>>> distinguished >>>>>> from reference values. Though the language would not require >>>>>> it, most >>>>>> likely a word the same size as a pointer will be used. Using >>>>>> the lsb >>>>>> as the tag bit is an efficient encoding, because in any currently >>>>>> conceivable machine, it will be zero for all pointers to heap >>>>>> objects. >>>>>> There is no reason pickles would have to use the same >>>>>> representation >>>>>> as compiler-generated code. >>>>>> >>>>>> The implementation should define the bounds of TAGABLE to be >>>>>> whatever >>>>>> it can fit in its representation, after removing the values >>>>>> that are >>>>>> true pointers. If the lsb is used as a tag, this will no doubt >>>>>> be a >>>>>> 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit >>>>>> machine. The language wouldn't even specify whether it is >>>>>> signed, >>>>>> although somehow unsigned seems nice to me. If it is unsigned >>>>>> and the >>>>>> suggested encodings are used, TAGABLE would have the same >>>>>> bounds as >>>>>> CARDINAL, but it really should be a separate type, so as not to >>>>>> overconstrain the implementation. >>>>>> >>>>>> If T is branded, then the effects of branding will propagate to >>>>>> TAGGED >>>>>> T, thus allowing independent abstract data types to ensure each >>>>>> one's >>>>>> values can't be mixed up with the other's. This will statically >>>>>> detect misuses by client code. However, TAGGED T is not a >>>>>> branded >>>>>> type. >>>>>> >>>>>> If T is an opaque type, then TAGGED T can be used to combine >>>>>> the space >>>>>> efficiency of tagging with the ability of an opaque type to >>>>>> reveal >>>>>> some but not all of its properties. To use this, client code >>>>>> will >>>>>> have to narrow a value first, since access to methods/fields >>>>>> could not >>>>>> have a definable meaning for a value in TAGABLE. >>>>>> >>>>>> On the other hand, T could be an opaque subtype of REFANY, thus >>>>>> revealing almost nothing about TAGGED T to clients. This would >>>>>> give >>>>>> tagged types the existing ability of ensuring statically, that >>>>>> the >>>>>> code in a revealed context will never get TAGGED REFANY, thus >>>>>> avoiding >>>>>> extra runtime type checks. >>>>> >>>>> >> From jay.krell at cornell.edu Tue Jun 2 12:20:30 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 2 Jun 2009 10:20:30 +0000 Subject: [M3devel] m3_load/store using bitfields for everything In-Reply-To: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> References: <5A798F55-98CE-46D9-8A0D-F0852FCEBAF2@cs.purdue.edu> Message-ID: ARM_LINUX looks ok. Now..I experimented with the size/alignment of the module-globals. If I decrease them to 8, it infects the uses of "components" of it (bitfields). RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.102 diff -u -r1.102 parse.c @@ -2989,7 +2989,7 @@ gcc doesn't think it fits in a register, so that loads out of it do get their offsets applied. */ TREE_TYPE (v) - = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT); + = m3_build_type (T_struct, 8, 8); layout_decl (v, BIGGEST_ALIGNMENT); TYPE_UNSIGNED (TREE_TYPE (v)) = 1; TREE_STATIC (v) = 1; bl RTOS__Write(PLT) .stabn 68,0,79,.LM45-.LFBB8 .LM45: ldr r3, .L40+4 ldr r1, [fp, #-16] ldr r2, [r1, r3] ldrb r1, [r2, #52] mov r3, #0 mov r1, r3 strb r1, [r2, #52] Those "b for byte" shouldn't be there. The problem is more obvious on the reads -- lots of shifting and masking. .stabn 68,0,78,.LM44-.LFBB8 .LM44: ldr r3, .L40+4 ldr r1, [fp, #-16] ldr r2, [r1, r3] ldrb r3, [r2, #52] and r1, r3, #255 ldrb r3, [r2, #53] and r3, r3, #255 mov r3, r3, asl #8 orr r1, r3, r1 ldrb r3, [r2, #54] and r3, r3, #255 mov r3, r3, asl #16 orr r1, r3, r1 mov r3, r3, asl #16 orr r1, r3, r1 ldrb r3, [r2, #55] and r3, r3, #255 mov r3, r3, asl #24 orr r3, r3, r1 cmp r3, #0 ble .L39 Now, I grant that this "experiment" is a bit of garbage in, garbage out, but I think showing that the size/alignment of a symbol that we use merely for generating offsets from has big affects is a little worrisome. Ok, I grant, if this is just ensuring aligned reads, that's reasonable. I should twiddle just the size and not the alignment. "To be constructive" if I managed to form a patch that declared the module-globals to a be struct (record) with well described/typed/sized/aligned "components" (fields/members/etc.) and we used..hm..it seems we never access fields, just offsets? sentence was going to end "..that'd be a reasonable change?" Eh, for now probably not worth it, it does work given the large size/alignment and slow path for iphone, other stuff to do... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] m3_load/store using bitfields for everything Date: Mon, 1 Jun 2009 16:46:38 +0000 It isn't related to optimization. I don't think it is 4.2/4.3 specific. I'll try to show an example later (MIPS64_OPENBSD and, never looked at them, but maybe othar arm/mips will show it). - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 1 Jun 2009 09:01:55 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] m3_load/store using bitfields for everything Jay, things changed from gcc 3.2 to 3.3. 3.3 works fine for me on all the h/w targets I've tried using -O3 (PPC, x86, AMD64, SPARC). I suspect this is specific to your gcc-apple hybrid. On 1 Jun 2009, at 00:49, Jay wrote: 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 hendrik at topoi.pooq.com Tue Jun 2 12:31:52 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 2 Jun 2009 06:31:52 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> Message-ID: <20090602103152.GA2916@topoi.pooq.com> On Tue, Jun 02, 2009 at 10:04:37AM +1000, Tony Hosking wrote: > The compiler and run-time support is already in the CVS head. > > On 1 Jun 2009, at 22:21, Darko wrote: > > >This is a great little hack. Is it available now or are you still > >working on it? I don't know what other people want to use it for but > >this is a great way to link memory structures with external data. It > >overcomes one of the downsides of GC compared to say C, where you > >can use pointer values for other purposes, but it does it safely. > > > >Also I'd like to add my voice for the minimalist approach where no > >language changes are made. I don't think there is a semantically > >clean way of incorporating this into the language and I'm not sure > >there is any payoff in doing so. I think there is a semantically clean way of incorporating it into the language, but it's not a trivial change. It becomes an optimisable special case of a more general feature -- for any bunch of types A, B, C, ... you introduce a type UNION(A, B, C, ...). There's nothing you can do with a union except build it from an A, B, or C ..., copy it, and test its type and extract the contents -- more or less what you can do to one of our type-tagged values. These unions have a fixed size (more or less the max of the sizes of A, B, C, ... and an extra type-tag. (I don't know if there has to be a restriction on using open arrays here; I hole not.) In the special case of UNION(A, B), where B is a suitable subrange if INTEGER and A is a pointer-to-object, the compiler could choose to implement this with our low-bit-and-shift hack. -- hendrik From hosking at cs.purdue.edu Tue Jun 2 12:51:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 2 Jun 2009 20:51:31 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20090602103152.GA2916@topoi.pooq.com> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> Message-ID: <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> Union types are anathema to the design of the Modula-3 type system. On 2 Jun 2009, at 20:31, hendrik at topoi.pooq.com wrote: > On Tue, Jun 02, 2009 at 10:04:37AM +1000, Tony Hosking wrote: >> The compiler and run-time support is already in the CVS head. >> >> On 1 Jun 2009, at 22:21, Darko wrote: >> >>> This is a great little hack. Is it available now or are you still >>> working on it? I don't know what other people want to use it for but >>> this is a great way to link memory structures with external data. It >>> overcomes one of the downsides of GC compared to say C, where you >>> can use pointer values for other purposes, but it does it safely. >>> >>> Also I'd like to add my voice for the minimalist approach where no >>> language changes are made. I don't think there is a semantically >>> clean way of incorporating this into the language and I'm not sure >>> there is any payoff in doing so. > > I think there is a semantically clean way of incorporating it into the > language, but it's not a trivial change. It becomes an optimisable > special case of a more general feature -- for any bunch of types A, B, > C, ... you introduce a type UNION(A, B, C, ...). There's nothing you > can do with a union except build it from an A, B, or C ..., copy it, > and > test its type and extract the contents -- more or less what you can do > to one of our type-tagged values. These unions have a fixed size > (more > or less the max of the sizes of A, B, C, ... and an extra type-tag. > (I don't know if there has to be a restriction on using open arrays > here; I hole not.) > > In the special case of UNION(A, B), where B is a suitable subrange if > INTEGER and A is a pointer-to-object, the compiler could choose to > implement this with our low-bit-and-shift hack. > > -- hendrik From hendrik at topoi.pooq.com Tue Jun 2 13:23:53 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 2 Jun 2009 07:23:53 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> Message-ID: <20090602112353.GB2916@topoi.pooq.com> On Tue, Jun 02, 2009 at 08:51:31PM +1000, Tony Hosking wrote: > Union types are anathema to the design of the Modula-3 type system. So I have heard. But I don't understand why. Certainly variant records a la Pascal would be for security reasons. Did they get tarred with the same brush? Or were unions considered unnecessary once the language had objects and inheritance? -- hendrik From hendrik at topoi.pooq.com Tue Jun 2 17:52:47 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 2 Jun 2009 11:52:47 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <5DE9B69F-9493-4A6D-B7C8-1CEABC4BAE43@darko.org> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> <20090602112353.GB2916@topoi.pooq.com> <5DE9B69F-9493-4A6D-B7C8-1CEABC4BAE43@darko.org> Message-ID: <20090602155246.GC3481@topoi.pooq.com> On Tue, Jun 02, 2009 at 04:33:49PM +0200, Darko wrote: > Probably because some union fields disappear and you can't work out > statically if a field access is valid. That's the problem with variant records in Pascal. I don't like them either. They're not what I'm talking about. If you have a value of type UNION(A, B) you don't get to use an operation on it just because the operation happens to be valid on A. > Maybe you chose the wrong name > for your type, because they are actually just dynamically typed values > rather than unions. The unions I'm talking about are disjount unions, the things the category theorists oftern call coproducts. They are dual to Cartesion products (which are provided in Moduls 3). They are type-secure. My unions comprise a finite number of other types, which means that in one place you can see everything that can happen to them. You don't run the risk that somewhere else someone sticks more alternatives into your type by inheriting form it. (this can be a curse or a blessing, depending on how your code is organised. It tends to be awkward to do object-oriented code with these unions, just as it's awkward using objects and inheritance when you really want unions) > Maybe you should have called them 'overlays' I'm not taking about interpreting physical storage in multiple different ways. I'm not talking about tools to store a REAL and fetch an INTEGER in order to cut it up with maske to get at the exponent and mantissa. That's UNSAFE. I'm talking about a type-safe alternative mechanism in data structures. One which is more efficient is some circumstances that the one traditionally embedded in Modula 3 (else we wouldn't be having this discussion), but less efficient in others (such as unions of huge records). But what I'd like to know is why they are considered an anathema instead of just an alternative not taken. Perhaps way back then they were talking about different language features. But treating them as anathema seems to have poisoned thinking about any kind of remotely similar feature, even type-safe ones. -- hendrik > > On 02/06/2009, at 1:23 PM, hendrik at topoi.pooq.com wrote: > > >On Tue, Jun 02, 2009 at 08:51:31PM +1000, Tony Hosking wrote: > >>Union types are anathema to the design of the Modula-3 type system. > > > >So I have heard. But I don't understand why. Certainly > >variant records a la Pascal would be for security reasons. > >Did they get tarred with the same brush? Or were unions > >considered unnecessary once the language had objects and > >inheritance? > > > >-- hendrik > From jay.krell at cornell.edu Tue Jun 2 17:52:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 2 Jun 2009 15:52:43 +0000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20090602112353.GB2916@topoi.pooq.com> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> <20090602112353.GB2916@topoi.pooq.com> Message-ID: Um, but can't tagged unions be safe? Can't you tell the compiler which tag maps to which part of the union and all reads would be checked? And writes would set the tag? Something like that? Plus optimize away some of the tag checks. And then like you say, sometimes the tag can be combined with the value, nice description. After all, tagged unions are the only type in Microsoft VBScript and JScript, safe languages. Granted, as you say, objects often fit the same scenarios. - Jay > Date: Tue, 2 Jun 2009 07:23:53 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Resummary of tagged reference proposals > > On Tue, Jun 02, 2009 at 08:51:31PM +1000, Tony Hosking wrote: > > Union types are anathema to the design of the Modula-3 type system. > > So I have heard. But I don't understand why. Certainly > variant records a la Pascal would be for security reasons. > Did they get tarred with the same brush? Or were unions > considered unnecessary once the language had objects and > inheritance? > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jun 3 00:49:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Jun 2009 08:49:59 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20090602112353.GB2916@topoi.pooq.com> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> <20090602112353.GB2916@topoi.pooq.com> Message-ID: Yes, objects + inheritance. I think there is a discussion in "How the language got its spots" in "Systems Programming in Modula-3". On 2 Jun 2009, at 21:23, hendrik at topoi.pooq.com wrote: > On Tue, Jun 02, 2009 at 08:51:31PM +1000, Tony Hosking wrote: >> Union types are anathema to the design of the Modula-3 type system. > > So I have heard. But I don't understand why. Certainly > variant records a la Pascal would be for security reasons. > Did they get tarred with the same brush? Or were unions > considered unnecessary once the language had objects and > inheritance? > > -- hendrik From hendrik at topoi.pooq.com Wed Jun 3 19:14:07 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 3 Jun 2009 13:14:07 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> <20A3F24C-F7C7-4DAA-8916-14A9334F7CE7@darko.org> <324A8007-BF4B-4CDA-B7FC-8EEF70101441@cs.purdue.edu> <20090602103152.GA2916@topoi.pooq.com> <24E4337D-B1DF-4982-8739-4F4C672E005B@cs.purdue.edu> <20090602112353.GB2916@topoi.pooq.com> <5DE9B69F-9493-4A6D-B7C8-1CEABC4BAE43@darko.org> <20090602155246.GC3481@topoi.pooq.com> Message-ID: <20090603171407.GA7016@topoi.pooq.com> On Wed, Jun 03, 2009 at 01:20:38AM +0200, Froggy wrote: > Yes, I understand what you're proposing and agree, but if you call > them unions then people think you're talking about C style unions or > variant records, etc which are the anathema in question. Historically, it was the other way around. C took Algol 68's unions, and removed the run-time type discriminator which could make them safe. -- hendrik From jay.krell at cornell.edu Thu Jun 4 21:42:28 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 4 Jun 2009 19:42:28 +0000 Subject: [M3devel] CM3_INSTALL_PREFIX Message-ID: Dragisha, ok, even before looking into this, I think I knew what the problem is. Need to "smush out the dots" more, so that mkdir /a/b/c/d/.. acts like mkdir /a/b/c. However I am unable to reproduce the problem on either PPC_DARWIN or AMD64_LINUX. Can you show me the offending .M3SHIP files? And maybe your config files? I don't have any .. "like that" in .M3SHIP. Does it happen with current cm3 or only older cm3? (I didn't realize CM3_INSTALL_PREFIX was a relatively new thing, from early 2008.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jun 4 21:38:38 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 4 Jun 2009 19:38:38 +0000 Subject: [M3devel] cvsup/zlib/solaris Message-ID: Tony your Tinderbox runs are less successful than others, building cvsup, due to lack of libz: === package m3-tools/cvsup/suplib === --- building in SOLgnu --- 22849 22850 ignoring ../src/m3overrides 22851 22852 NEXT "/scratch/hosking/work/cm3-ws/niagara-2009-06-03-10-30-05/cm3/m3-tools/cvsup/suplib/src/../../quake/cvsup.quake", line 127: quake runtime error: file libz.a not found in /usr/lib /usr/local/lib /lib /usr/contrib/lib /opt/lib 22853 Can you maybe install it on your systems? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jun 5 01:13:19 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 05 Jun 2009 01:13:19 +0200 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: References: Message-ID: <1244157199.14071.265.camel@faramir.m3w.org> There is no problem in CM3_INSTALL_PREFIX, but in situations where make_dir tries to make ".bin/.." when "..bin/" still does not exist. Problem is recent, it started to happen after you make INSTALL_ROOT relative to cm3 binary location. Solution: Exterminate .. from paths in cm3cfg.common. Apropos CM3_INSTALL_PREFIX - I am maybe it's only "client" for now - as it's used to populate tree during RPM builds. But it's straightforward solution to any binary packaking problem. On Thu, 2009-06-04 at 19:42 +0000, Jay wrote: > Dragisha, > > ok, even before looking into this, I think I knew what the problem is. > Need to "smush out the dots" more, so that mkdir /a/b/c/d/.. acts like > mkdir /a/b/c. > > However I am unable to reproduce the problem on either PPC_DARWIN or > AMD64_LINUX. > > Can you show me the offending .M3SHIP files? > And maybe your config files? > > I don't have any .. "like that" in .M3SHIP. > > Does it happen with current cm3 or only older cm3? > (I didn't realize CM3_INSTALL_PREFIX was a relatively new thing, from > early 2008.) > > - Jay > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jun 5 01:21:51 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 4 Jun 2009 23:21:51 +0000 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: <1244157199.14071.265.camel@faramir.m3w.org> References: <1244157199.14071.265.camel@faramir.m3w.org> Message-ID: I made this change years ago but only recently did Olaf switch over to my stuff. It is a good change generally, because you don't have to run cminstall and stick a full path in the config file. We can fix this aspect of it, but I'd like to be able to see it fail before I fix it, and then verify my fix makes it stop failing. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 5 Jun 2009 01:13:19 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3_INSTALL_PREFIX > > There is no problem in CM3_INSTALL_PREFIX, but in situations where > make_dir tries to make ".bin/.." when "..bin/" still does not exist. > > Problem is recent, it started to happen after you make INSTALL_ROOT > relative to cm3 binary location. > > Solution: Exterminate .. from paths in cm3cfg.common. > > Apropos CM3_INSTALL_PREFIX - I am maybe it's only "client" for now - as > it's used to populate tree during RPM builds. But it's straightforward > solution to any binary packaking problem. > > On Thu, 2009-06-04 at 19:42 +0000, Jay wrote: >> Dragisha, >> >> ok, even before looking into this, I think I knew what the problem is. >> Need to "smush out the dots" more, so that mkdir /a/b/c/d/.. acts like >> mkdir /a/b/c. >> >> However I am unable to reproduce the problem on either PPC_DARWIN or >> AMD64_LINUX. >> >> Can you show me the offending .M3SHIP files? >> And maybe your config files? >> >> I don't have any .. "like that" in .M3SHIP. >> >> Does it happen with current cm3 or only older cm3? >> (I didn't realize CM3_INSTALL_PREFIX was a relatively new thing, from >> early 2008.) >> >> - Jay >> > -- > Dragi?a Duri? > From hosking at cs.purdue.edu Fri Jun 5 01:54:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 5 Jun 2009 09:54:41 +1000 Subject: [M3devel] cvsup/zlib/solaris In-Reply-To: References: Message-ID: <1C2755B6-78CF-49B7-8057-E904B7A9D253@cs.purdue.edu> I'll see what I can do to locate that. On 5 Jun 2009, at 05:38, Jay wrote: > Tony your Tinderbox runs are less successful than others, building > cvsup, due to lack of libz: > > === package m3-tools/cvsup/suplib === > --- building in SOLgnu --- > 22849 > 22850 ignoring ../src/m3overrides > 22851 > 22852 NEXT "/scratch/hosking/work/cm3-ws/ > niagara-2009-06-03-10-30-05/cm3/m3-tools/cvsup/suplib/src/../../ > quake/cvsup.quake", line 127: quake runtime error: file libz.a not > found in /usr/lib /usr/local/lib /lib /usr/contrib/lib /opt/lib > 22853 > > > Can you maybe install it on your systems? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jun 5 10:51:05 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 05 Jun 2009 10:51:05 +0200 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: References: <1244157199.14071.265.camel@faramir.m3w.org> Message-ID: <1244191865.14071.717.camel@faramir.m3w.org> This is special case, as CM3_INSTALL_PREFIX redirects installation process to empty tree... cm3 -ship fails on make_dir("/usr/local/cm3/bin/../lib") as there is no $CM3_INSTALL_PREFIX/usr/local/cm3/bin at that moment. "cm3 -ship" which fails does mkdir $CM3_INSTALL_PREFIX/usr/local/cm3/bin, though. So second time I start cm3 -ship it works fine. Also, if I "mkdir -p $CM3_INSTALL_PREFIX/usr/local/cm3/bin" before cm3 -ship it does not fail first time. Thus said - I already have fix I need, it's workaround but works. If it is problem for you to write wuake script which derives paths from INSTALL_ROOT without ".." then just forget this and we can document this "feature" on our way. It will be documented in my RPM recipes once I complete and publish them. On Thu, 2009-06-04 at 23:21 +0000, Jay wrote: > > I made this change years ago but only recently did Olaf switch over to > my stuff. It is a good change generally, because you don't have to run > cminstall and stick a full path in the config file. We can fix this > aspect of it, but I'd like to be able to see it fail before I fix it, > and then verify my fix makes it stop failing. > > > - Jay -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jun 5 19:28:51 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 5 Jun 2009 17:28:51 +0000 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: <1244191865.14071.717.camel@faramir.m3w.org> References: <1244157199.14071.265.camel@faramir.m3w.org> <1244191865.14071.717.camel@faramir.m3w.org> Message-ID: The ".." gets smushed out early for me and I don't see a failure. Even for shipping m3core into a nonexistant place, with CM3_INSTALL_PREFIX set. Is the problem without CM3_INSTALL_PREFIX? Can you show your .M3SHIP files? And maybe your config files? This is easy to fix. There is code that smushes out dots. It is maybe a problem to write the quake because quake is very limited in what it can do. There might be functions now that can do it though. But really, again, the Modula-3 code often "canonicalizes" paths internally anyway, which is possibly why I don't see the problem occuring myself. - Jay > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 5 Jun 2009 10:51:05 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3_INSTALL_PREFIX > > This is special case, as CM3_INSTALL_PREFIX redirects installation > process to empty tree... cm3 -ship fails on > make_dir("/usr/local/cm3/bin/../lib") as there is no > $CM3_INSTALL_PREFIX/usr/local/cm3/bin at that moment. "cm3 -ship" which > fails does mkdir $CM3_INSTALL_PREFIX/usr/local/cm3/bin, though. So > second time I start cm3 -ship it works fine. > > Also, if I "mkdir -p $CM3_INSTALL_PREFIX/usr/local/cm3/bin" before cm3 > -ship it does not fail first time. > > Thus said - I already have fix I need, it's workaround but works. If it > is problem for you to write wuake script which derives paths from > INSTALL_ROOT without ".." then just forget this and we can document this > "feature" on our way. It will be documented in my RPM recipes once I > complete and publish them. > > On Thu, 2009-06-04 at 23:21 +0000, Jay wrote: > > > > I made this change years ago but only recently did Olaf switch over to > > my stuff. It is a good change generally, because you don't have to run > > cminstall and stick a full path in the config file. We can fix this > > aspect of it, but I'd like to be able to see it fail before I fix it, > > and then verify my fix makes it stop failing. > > > > > > - Jay > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jun 5 21:56:15 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 05 Jun 2009 21:56:15 +0200 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: References: <1244157199.14071.265.camel@faramir.m3w.org> <1244191865.14071.717.camel@faramir.m3w.org> Message-ID: <1244231775.14071.1359.camel@faramir.m3w.org> On Fri, 2009-06-05 at 17:28 +0000, Jay wrote: > The ".." gets smushed out early for me and I don't see a failure. > Even for shipping m3core into a nonexistant place, with > CM3_INSTALL_PREFIX set. > Is the problem without CM3_INSTALL_PREFIX? I don't see how to ship to non-existent place without CM3_INSTALL_PREFIX... End of day sinrome maybe...? > Can you show your .M3SHIP files? They are just like anybody's else. > And maybe your config files? Stock. No edit. > This is easy to fix. There is code that smushes out dots. Then please do. :) -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jun 5 22:31:12 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 5 Jun 2009 20:31:12 +0000 Subject: [M3devel] CM3_INSTALL_PREFIX In-Reply-To: <1244231775.14071.1359.camel@faramir.m3w.org> References: <1244157199.14071.265.camel@faramir.m3w.org> <1244191865.14071.717.camel@faramir.m3w.org> <1244231775.14071.1359.camel@faramir.m3w.org> Message-ID: Dragisha we are not communicating. I have set CM3_INSTALL_PREFIX to a nonexistant place. I have shiped m3core. It works. No error. If I see the error I believe I know how to fix it, but I don't want to make a change without being able to see the before and after and that the after is an improvement. Maybe I am doing something wrong though. Please send me the offending .M3SHIP file. - Jay ---------------------------------------- > Subject: RE: [M3devel] CM3_INSTALL_PREFIX > From: dragisha at m3w.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Date: Fri, 5 Jun 2009 21:56:15 +0200 > > On Fri, 2009-06-05 at 17:28 +0000, Jay wrote: >> The ".." gets smushed out early for me and I don't see a failure. >> Even for shipping m3core into a nonexistant place, with >> CM3_INSTALL_PREFIX set. >> Is the problem without CM3_INSTALL_PREFIX? > > I don't see how to ship to non-existent place without > CM3_INSTALL_PREFIX... End of day sinrome maybe...? > >> Can you show your .M3SHIP files? > > They are just like anybody's else. > >> And maybe your config files? > > Stock. No edit. > >> This is easy to fix. There is code that smushes out dots. > > Then please do. :) > > -- > Dragi?a Duri? > From eiserlohpp at yahoo.com Mon Jun 8 03:30:46 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 7 Jun 2009 18:30:46 -0700 (PDT) Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX Message-ID: <973785.75349.qm@web56804.mail.re3.yahoo.com> Hi Guys, I have been attempting to build m3gdb. A simple "do-pkg.sh m3gdb" fails with a message that the package is disabled on this platform. So, I manually went to m3-sys/m3gdb, and did a "cm3 -build", an success. Is there a reason that m3gdb is disabled on AMD64_LINUX? Or, more probably, did someone simply forget to enable it? I traced the decision down to pkginfo.sh, where yes, there is an environment variable M3GDB that could have been set to allow m3gdb to be built, but that is taking extra measures to build it. Is it a simple oversight in not, by default, building m3gdb? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From rodney.m.bates at cox.net Mon Jun 8 16:59:34 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 08 Jun 2009 09:59:34 -0500 Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX In-Reply-To: <973785.75349.qm@web56804.mail.re3.yahoo.com> References: <973785.75349.qm@web56804.mail.re3.yahoo.com> Message-ID: <4A2D2756.8010904@cox.net> I seem to have fallen into the role of default primary maintainer for m3gdb. I have never built it on anything other than LINUXLIBC6. I now have an AMD_LINUX machine, but haven't gotten a working cm3 to build with yet. I'm just guessing, but I think some platforms have had build problems in the past. Maybe it is disable except where it has been previously done successfully. I read your post to say only that it built successfully for you. Any experience trying it out? Peter Eiserloh wrote: > Hi Guys, > > I have been attempting to build m3gdb. A simple > "do-pkg.sh m3gdb" fails with a message that the package > is disabled on this platform. > > So, I manually went to m3-sys/m3gdb, and did a "cm3 -build", > an success. > > Is there a reason that m3gdb is disabled on AMD64_LINUX? > Or, more probably, did someone simply forget to enable it? > > I traced the decision down to pkginfo.sh, where yes, there > is an environment variable M3GDB that could have been > set to allow m3gdb to be built, but that is taking extra > measures to build it. > > Is it a simple oversight in not, by default, building m3gdb? > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > > From wagner at elegosoft.com Mon Jun 8 21:37:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 08 Jun 2009 21:37:12 +0200 Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX In-Reply-To: <4A2D2756.8010904@cox.net> References: <973785.75349.qm@web56804.mail.re3.yahoo.com> <4A2D2756.8010904@cox.net> Message-ID: <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> The strategy when to build m3gdb should probably be revisited. I'm not sure if we should keep the positive list or just exclude some platforms; but then, I do not have the complete overview of all the platforms that Jay has been and is working on. Jay, can you take a look at that in pkginfo.sh? Thanks, Olaf Quoting "Rodney M. Bates" : > I seem to have fallen into the role of default primary maintainer for > m3gdb. I have never built it on anything other than LINUXLIBC6. > I now have an AMD_LINUX machine, but haven't gotten a working > cm3 to build with yet. I'm just guessing, but I think some platforms > have had build problems > in the past. Maybe it is disable except where it has been previously > done successfully. I read your post to say only that it built > successfully for you. Any > experience trying it out? Peter Eiserloh wrote: >> Hi Guys, >> >> I have been attempting to build m3gdb. A simple "do-pkg.sh m3gdb" >> fails with a message that the package >> is disabled on this platform. >> >> So, I manually went to m3-sys/m3gdb, and did a "cm3 -build", >> an success. >> >> Is there a reason that m3gdb is disabled on AMD64_LINUX? >> Or, more probably, did someone simply forget to enable it? >> >> I traced the decision down to pkginfo.sh, where yes, there >> is an environment variable M3GDB that could have been >> set to allow m3gdb to be built, but that is taking extra >> measures to build it. >> >> Is it a simple oversight in not, by default, building m3gdb? >> >> >> +--------------------------------------------------------+ >> | 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 hendrik at topoi.pooq.com Mon Jun 8 22:57:47 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 8 Jun 2009 16:57:47 -0400 Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX In-Reply-To: <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> References: <973785.75349.qm@web56804.mail.re3.yahoo.com> <4A2D2756.8010904@cox.net> <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> Message-ID: <20090608205747.GA20457@topoi.pooq.com> On Mon, Jun 08, 2009 at 09:37:12PM +0200, Olaf Wagner wrote: > The strategy when to build m3gdb should probably be revisited. > I'm not sure if we should keep the positive list or just exclude > some platforms; but then, I do not have the complete overview of > all the platforms that Jay has been and is working on. Whatever you do about including or excluding, it would be worth inserting a comment explaining why. -- hendrik From jay.krell at cornell.edu Tue Jun 9 03:00:29 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 8 Jun 2009 18:00:29 -0700 Subject: [M3devel] [M3Devel] m3gdb not automatically built on AMD64_LINUX In-Reply-To: <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> References: <973785.75349.qm@web56804.mail.re3.yahoo.com> <4A2D2756.8010904@cox.net> <20090608213712.aqsdw4dxkwco8g8w@mail.elegosoft.com> Message-ID: <4B18C378-AE99-4897-B1B0-2ABB39DC7E0A@hotmail.com> I agree let it build by default. It can probably build on most platforms. The exceptions are nt386 and i think nt386mingnu. Nt386gnu can build it but cygwin is so generally slow and I never use m3gdb..on any platform.. - Jay (phone) On Jun 8, 2009, at 12:37 PM, Olaf Wagner wrote: > The strategy when to build m3gdb should probably be revisited. > I'm not sure if we should keep the positive list or just exclude > some platforms; but then, I do not have the complete overview of > all the platforms that Jay has been and is working on. > > Jay, can you take a look at that in pkginfo.sh? > > Thanks, > > Olaf > > Quoting "Rodney M. Bates" : > >> I seem to have fallen into the role of default primary maintainer for >> m3gdb. I have never built it on anything other than LINUXLIBC6. >> I now have an AMD_LINUX machine, but haven't gotten a working >> cm3 to build with yet. I'm just guessing, but I think some platforms >> have had build problems >> in the past. Maybe it is disable except where it has been previously >> done successfully. I read your post to say only that it built >> successfully for you. Any >> experience trying it out? Peter Eiserloh wrote: >>> Hi Guys, >>> >>> I have been attempting to build m3gdb. A simple "do-pkg.sh m3gdb" >>> fails with a message that the package >>> is disabled on this platform. >>> >>> So, I manually went to m3-sys/m3gdb, and did a "cm3 -build", >>> an success. >>> >>> Is there a reason that m3gdb is disabled on AMD64_LINUX? >>> Or, more probably, did someone simply forget to enable it? >>> >>> I traced the decision down to pkginfo.sh, where yes, there >>> is an environment variable M3GDB that could have been >>> set to allow m3gdb to be built, but that is taking extra >>> measures to build it. >>> >>> Is it a simple oversight in not, by default, building m3gdb? >>> >>> >>> +--------------------------------------------------------+ >>> | Peter P. Eiserloh | >>> +--------------------------------------------------------+ >>> >>> >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > 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: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From hendrik at topoi.pooq.com Tue Jun 9 23:25:43 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 9 Jun 2009 17:25:43 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090514155129.GA15181@topoi.pooq.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> <20090514155129.GA15181@topoi.pooq.com> Message-ID: <20090609212543.GA23398@topoi.pooq.com> On Thu, May 14, 2009 at 11:51:30AM -0400, hendrik at topoi.pooq.com wrote: > 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. Is it time for me to make another try at installing cm3 from scratch? In particular, do you think most of the problems I reported with documentation and archives, etc., have been solved? I really want to get m3 working on this laptop, but I also want to provide the most useful problem reports. I'm definitely trying to act like a naive user in these installation attempts (which means I'm trying to act stupider than I am). -- hendrik From estellnb at yahoo.de Wed Jun 10 16:26:09 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Wed, 10 Jun 2009 15:26:09 +0100 Subject: [M3devel] recent m3gdb does not want to compile Message-ID: <4A2FC281.1030101@yahoo.de> For any kind of reason recent m3gdbs refuse to compile at me: ../gdb/configure ... checking for x86_64-unknown-linux-gnu-ar... no checking for ar... ar ... > which ar /usr/bin/ar setting --bindir to /usr/bin or /usr does not help. full error log: see attachement Should I compile m3gdb towards 32bit on an x86_64 platform if the m3build I am using is 32bit? Besides this I am in wonder why a plain gdb can not access global Modula-3 variables using PM3/EZM3 although I have specified -gstabs in m3config/src/COMMON: ASM = ["as","--32","-gstabs","-o"] % Assembler DEBUG_FLAG = "-gstabs" % debugging info BDEBUG_FLAG = "-gstabs" % debugging info LDEBUG_FLAG = "-gstabs" i.e. > gdb -batch --directory= --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > grep myglobal smbls -> nothing found -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: m3gdb-errs.msg URL: From jay.krell at cornell.edu Wed Jun 10 23:05:55 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 10 Jun 2009 21:05:55 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A2FC281.1030101@yahoo.de> References: <4A2FC281.1030101@yahoo.de> Message-ID: The global variable behavior I think I understand, and I believe the original authors did it this way on purpose, but I agree it seems quite bad. The way the code is generated, all the internal globals for a module are in one large struct, per module. There aren't symbols for each one. The code translates like this: Modula-3: Foo.i3: INTERFACE Foo; PROCEDURE GetI() : INTEGER; PROCEDURE GetJ() : INTEGER; END Foo. Foo.m3: MODULE Foo; VAR i, j: INTEGER; PROCEDURE GetI() = BEGIN RETURN i; END GetI; PROCEDURE GetJ() = BEGIN RETURN j; END GetJ; C: foo.h: ptrdiff_t Foo__GetI(void); ptrdiff_t Foo__GetJ(void); foo.c: struct { int i, j; } Foo_M3; ptrdiff_t Foo__GetI(void) { return Foo_M3.i; } ptrdiff_t Foo__GetJ(void) { return Foo_M3.j; } I personally would much prefer one of: static int i, j; ptrdiff_t Foo__GetI(void) { return i; } ptrdiff_t Foo__GetJ(void) { return j; } or: int Foo_i, Foo_j; ptrdiff_t Foo__GetI(void) { return Foo_i; } ptrdiff_t Foo__GetJ(void) { return Foo_j; } or two underscores. Can anyone explain why it is done this way? And why it shouldn't be changed to how I showed? Here are some advantages/disadvanges: symbols, debuggability, as discussed The current way pretty much guaranteeds none of the data gets dead-stripped, for better and worse. But really, even if you changed it to "my way", there's probably another bit needed on the data to dead-strip it, so that behavior can be preserved, for better and worse. "My way" probably also allows for not using bitfields in load/store, in fact, the offseting would often go away too. > Should I compile m3gdb towards 32bit on an x86_64 platform if the > m3build I am using is 32bit? It should build either way, but for it to be useful, yes, I expect so. I believe current versions of gdb can have multiple targets though. - Jay > Date: Wed, 10 Jun 2009 15:26:09 +0100 > From: estellnb at yahoo.de > To: m3devel at elegosoft.com > Subject: [M3devel] recent m3gdb does not want to compile > > For any kind of reason recent m3gdbs refuse to compile at me: > > ../gdb/configure > ... > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > ... > > > which ar > /usr/bin/ar > > setting --bindir to /usr/bin or /usr does not help. > full error log: see attachement > > Should I compile m3gdb towards 32bit on an x86_64 platform if the > m3build I am using is 32bit? > > Besides this I am in wonder why a plain gdb can not access global > Modula-3 variables using PM3/EZM3 although I have specified -gstabs in > m3config/src/COMMON: > ASM = ["as","--32","-gstabs","-o"] % Assembler > DEBUG_FLAG = "-gstabs" % debugging info > BDEBUG_FLAG = "-gstabs" % debugging info > LDEBUG_FLAG = "-gstabs" > > i.e. > > gdb -batch --directory= > --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info > variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > > > grep myglobal smbls -> nothing found > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jun 10 23:42:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 10 Jun 2009 23:42:00 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090609212543.GA23398@topoi.pooq.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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> Message-ID: <20090610234200.xec9zguoqowogc84@mail.elego.de> Quoting hendrik at topoi.pooq.com: > On Thu, May 14, 2009 at 11:51:30AM -0400, hendrik at topoi.pooq.com wrote: > Is it time for me to make another try at installing cm3 from scratch? > In particular, do you think most of the problems I reported with > documentation and archives, etc., have been solved? I really want to > get m3 working on this laptop, but I also want to provide the most > useful problem reports. > > I'm definitely trying to act like a naive user in these installation > attempts (which means I'm trying to act stupider than I am). I'm sorry; though I've put some archives onto birch labelled as RC1, there's still no documentation. I'm currently in Madrid for a week, but I hope to spend a day for working on that when I return mid of next week. I'll let you know when to try it. Hasta luego, 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 Thu Jun 11 01:04:28 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 10 Jun 2009 23:04:28 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A2FC281.1030101@yahoo.de> References: <4A2FC281.1030101@yahoo.de> Message-ID: Slightly truncated, again >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? > > > > > > It should build either way, but for it to be useful, yes, I expect so. > > I believe current versions of gdb can have multiple targets though. > > > > > > - Jay From rodney.m.bates at cox.net Thu Jun 11 04:20:49 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 10 Jun 2009 21:20:49 -0500 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A2FC281.1030101@yahoo.de> References: <4A2FC281.1030101@yahoo.de> Message-ID: <4A306A01.5080603@cox.net> Peter Eiserloh has recently gotten it to build on AMD64_LINUX, using the do-cm3-m3gdb.sh script. You should try that method. Unfortunately, it is not recognizing executables and dynamic libraries. I have looked at this a bit, and the problem looks to be in the bfd library, which is stock from gdb. m3gdb is derived from gdb 6.4, which is by now quite old. gdb maintainers are about to make a new release, I think 6.9. I am in the throes of moving house now, but am getting odd bits of time to look at this. I have been thinking for some time that it is about time to update m3gdb to a later gdb. For one thing, gdb now has some reverse debugging support, which would be very nice for Modula-3 too. I have done it two or three times, and I believe Tony has done it at least once. It takes a fair amount of work. But it should be possible to get the current m3gdb working on AMD64 without going to that much trouble. Maybe just some updated source files from bfd will do the trick. Jay is right about global variables. You will have a very hard time finding them using stock gdb. They are located in a record with a funny compiler-generated name and have funny compiler-mangled field names. I'm not sure you can get them even if you know these. Elmar Stellnberger wrote: > For any kind of reason recent m3gdbs refuse to compile at me: > > ../gdb/configure > ... > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > ... > > >> which ar >> > /usr/bin/ar > > setting --bindir to /usr/bin or /usr does not help. > full error log: see attachement > > Should I compile m3gdb towards 32bit on an x86_64 platform if the > m3build I am using is 32bit? > > Besides this I am in wonder why a plain gdb can not access global > Modula-3 variables using PM3/EZM3 although I have specified -gstabs in > m3config/src/COMMON: > ASM = ["as","--32","-gstabs","-o"] % Assembler > DEBUG_FLAG = "-gstabs" % debugging info > BDEBUG_FLAG = "-gstabs" % debugging info > LDEBUG_FLAG = "-gstabs" > > i.e. > >> gdb -batch --directory= >> > --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info > variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > > >> grep myglobal smbls -> nothing found >> > > From jay.krell at cornell.edu Thu Jun 11 05:13:55 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 10 Jun 2009 20:13:55 -0700 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A306A01.5080603@cox.net> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> Message-ID: Do they have any field names at all? Can m3gdb see them? I suspect no to both. The struct is not TOO odd. - Jay (phone) On Jun 10, 2009, at 7:20 PM, "Rodney M. Bates" wrote: > Peter Eiserloh has recently gotten it to build on AMD64_LINUX, > using the do-cm3-m3gdb.sh script. You should try that method. > > Unfortunately, it is not recognizing executables and dynamic > libraries. I have looked at this a bit, and the problem looks to > be in the bfd library, which is stock from gdb. m3gdb is derived > from gdb 6.4, which is by now quite old. gdb maintainers are about > to make a new release, I think 6.9. I am in the throes of moving > house now, but am getting odd bits of time to look at this. > I have been thinking for some time that it is about time to update > m3gdb to a later gdb. For one thing, gdb now has some reverse > debugging support, which would be very nice for Modula-3 too. > I have done it two or three times, and I believe Tony has done it > at least once. It takes a fair amount of work. But it should be > possible to get the current m3gdb working on AMD64 without going > to that much trouble. Maybe just some updated source files from > bfd will do the trick. > Jay is right about global variables. You will have a very hard time > finding them using stock gdb. They are located in a record with a > funny compiler-generated name and have funny compiler-mangled > field names. I'm not sure you can get them even if you know these. > > > > > Elmar Stellnberger wrote: >> For any kind of reason recent m3gdbs refuse to compile at me: >> >> ../gdb/configure >> ... >> checking for x86_64-unknown-linux-gnu-ar... no >> checking for ar... ar >> ... >> >> >>> which ar >>> >> /usr/bin/ar >> >> setting --bindir to /usr/bin or /usr does not help. >> full error log: see attachement >> >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? >> >> Besides this I am in wonder why a plain gdb can not access global >> Modula-3 variables using PM3/EZM3 although I have specified -gstabs >> in >> m3config/src/COMMON: >> ASM = ["as","--32","-gstabs","-o"] % Assembler >> DEBUG_FLAG = "-gstabs" % debugging info >> BDEBUG_FLAG = "-gstabs" % debugging info >> LDEBUG_FLAG = "-gstabs" >> >> i.e. >> >>> gdb -batch --directory= >>> >> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info >> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls >> >> >>> grep myglobal smbls -> nothing found >>> >> >> > > From jay.krell at cornell.edu Thu Jun 11 10:50:08 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 11 Jun 2009 08:50:08 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> Message-ID: scripts/do-cm3-m3gdb.sh just cd's over to m3-sys/m3gdb and runs cm3. m3gdb builds and seems to work fine for me. Specifically, on AMD64_LINUX birch, I can both: mkdir -p $HOME/obj/gdb cd $HOME/obj/gdb $HOME/dev2/cm3/m3-sys/m3gdb/gdb/configure && make gdb/gdb gdb/gdb break main r and cd $HOME/dev2/cm3/m3-sys/m3gdb rm -rf AMD64_LINUX cm3 AMD64_LINUX/m3gdb AMD64_LINUX/m3gdb break main r I haven't tried with Modula-3 code and/or stabs. Updating from the 2005 6.4 release to a current 6.8 release is probably advisable anyway. But again, um, er, could we maybe adapt the generated code so that plain gdb is all anyone would need/want? Cygwin fork being so slow makes me want to optimize out such large pieces as building gdb. Maybe I can figure out a way to speed up Cygwin fork some day... - Jay > From: jay.krell at cornell.edu > To: rodney.m.bates at cox.net > Date: Wed, 10 Jun 2009 20:13:55 -0700 > CC: m3devel at elegosoft.com; estellnb at yahoo.de > Subject: Re: [M3devel] recent m3gdb does not want to compile > > Do they have any field names at all? Can m3gdb see them? I suspect no > to both. The struct is not TOO odd. > > - Jay (phone) > > On Jun 10, 2009, at 7:20 PM, "Rodney M. Bates" > wrote: > > > Peter Eiserloh has recently gotten it to build on AMD64_LINUX, > > using the do-cm3-m3gdb.sh script. You should try that method. > > > > Unfortunately, it is not recognizing executables and dynamic > > libraries. I have looked at this a bit, and the problem looks to > > be in the bfd library, which is stock from gdb. m3gdb is derived > > from gdb 6.4, which is by now quite old. gdb maintainers are about > > to make a new release, I think 6.9. I am in the throes of moving > > house now, but am getting odd bits of time to look at this. > > I have been thinking for some time that it is about time to update > > m3gdb to a later gdb. For one thing, gdb now has some reverse > > debugging support, which would be very nice for Modula-3 too. > > I have done it two or three times, and I believe Tony has done it > > at least once. It takes a fair amount of work. But it should be > > possible to get the current m3gdb working on AMD64 without going > > to that much trouble. Maybe just some updated source files from > > bfd will do the trick. > > Jay is right about global variables. You will have a very hard time > > finding them using stock gdb. They are located in a record with a > > funny compiler-generated name and have funny compiler-mangled > > field names. I'm not sure you can get them even if you know these. > > > > > > > > > > Elmar Stellnberger wrote: > >> For any kind of reason recent m3gdbs refuse to compile at me: > >> > >> ../gdb/configure > >> ... > >> checking for x86_64-unknown-linux-gnu-ar... no > >> checking for ar... ar > >> ... > >> > >> > >>> which ar > >>> > >> /usr/bin/ar > >> > >> setting --bindir to /usr/bin or /usr does not help. > >> full error log: see attachement > >> > >> Should I compile m3gdb towards 32bit on an x86_64 platform if the > >> m3build I am using is 32bit? > >> > >> Besides this I am in wonder why a plain gdb can not access global > >> Modula-3 variables using PM3/EZM3 although I have specified -gstabs > >> in > >> m3config/src/COMMON: > >> ASM = ["as","--32","-gstabs","-o"] % Assembler > >> DEBUG_FLAG = "-gstabs" % debugging info > >> BDEBUG_FLAG = "-gstabs" % debugging info > >> LDEBUG_FLAG = "-gstabs" > >> > >> i.e. > >> > >>> gdb -batch --directory= > >>> > >> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info > >> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > >> > >> > >>> grep myglobal smbls -> nothing found > >>> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at yahoo.de Thu Jun 11 14:00:12 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Thu, 11 Jun 2009 13:00:12 +0100 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A306A01.5080603@cox.net> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> Message-ID: <4A30F1CC.8040201@yahoo.de> Unfortunately I am not familiar with the complex build system of CM3 so that my chances to make do-cm3-m3gdb.sh work are very little: > scripts/do-cm3-m3gdb.sh making /src/lunger-cm3/scripts/PKGS (slow but rare) /src/lunger-cm3/scripts/pkgmap.sh -c "m3build -O -DROOT='/src/lunger-cm3' -DCM3_VERSION_TEXT='d5.8.1' -DCM3_VER SION_NUMBER='050801' -DCM3_LAST_CHANGED='2009-05-16' " m3gdb === package m3-sys/m3gdb === === package omitted on this platform === ==> m3-sys/m3gdb done > ls m3-sys/m3gdb/AMD64_LINUX > > m3build -O -DROOT='/src/lunger-cm3' -DCM3_VERSION_TEXT='d5.8.1' -DCM3_VERSION_NUMBER='050801' -DCM3_LAST_CHANGED='2009-05-16' --- building in LINUXLIBC6 --- m3build: missing ../src/m3overrides m3build: quake error: quake error: runtime error: exec failed: err#2 No such file or directory() *** CC="gcc" CFLAGS="-g" MAKEINFO=echo --procedure-- -line- -file--- exec -- m3gdb_Run 121 /home/sources/lunger-cm3/m3-sys/m3gdb/src/m3makefile 153 /home/sources/lunger-cm3/m3-sys/m3gdb/src/m3makefile Where should the overrides file come from? > ../gdb/configure CC="gcc" CFLAGS="-g" MAKEINFO="echo" configure: warning: CC=gcc: invalid host type configure: warning: CFLAGS=-g: invalid host type configure: error: can only configure for one host and one target at a time How can I invoke ../gdb/configure and make manually without having to use these scripts? Rodney M. Bates schrieb: > Peter Eiserloh has recently gotten it to build on AMD64_LINUX, > using the do-cm3-m3gdb.sh script. You should try that method. > > Unfortunately, it is not recognizing executables and dynamic > libraries. I have looked at this a bit, and the problem looks to > be in the bfd library, which is stock from gdb. m3gdb is derived > from gdb 6.4, which is by now quite old. gdb maintainers are about > to make a new release, I think 6.9. I am in the throes of moving > house now, but am getting odd bits of time to look at this. > I have been thinking for some time that it is about time to update > m3gdb to a later gdb. For one thing, gdb now has some reverse > debugging support, which would be very nice for Modula-3 too. > I have done it two or three times, and I believe Tony has done it > at least once. It takes a fair amount of work. But it should be > possible to get the current m3gdb working on AMD64 without going > to that much trouble. Maybe just some updated source files from > bfd will do the trick. > Jay is right about global variables. You will have a very hard time > finding them using stock gdb. They are located in a record with a > funny compiler-generated name and have funny compiler-mangled > field names. I'm not sure you can get them even if you know these. > > > > > Elmar Stellnberger wrote: >> For any kind of reason recent m3gdbs refuse to compile at me: >> >> ../gdb/configure >> ... >> checking for x86_64-unknown-linux-gnu-ar... no >> checking for ar... ar >> ... >> >> >>> which ar >>> >> /usr/bin/ar >> >> setting --bindir to /usr/bin or /usr does not help. >> full error log: see attachement >> >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? >> >> Besides this I am in wonder why a plain gdb can not access global >> Modula-3 variables using PM3/EZM3 although I have specified -gstabs in >> m3config/src/COMMON: >> ASM = ["as","--32","-gstabs","-o"] % Assembler >> DEBUG_FLAG = "-gstabs" % debugging info >> BDEBUG_FLAG = "-gstabs" % debugging info >> LDEBUG_FLAG = "-gstabs" >> >> i.e. >> >>> gdb -batch --directory= >>> >> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info >> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls >> >> >>> grep myglobal smbls -> nothing found >>> >> >> > > From jay.krell at cornell.edu Thu Jun 11 13:00:54 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 11 Jun 2009 04:00:54 -0700 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A2FC281.1030101@yahoo.de> References: <4A2FC281.1030101@yahoo.de> Message-ID: You are just missing texinfo or such, so building documentation fails. I can look in to hacking the m3gdb build like m3cc is, to reduce its dependencies. - Jay (phone) On Jun 10, 2009, at 7:26 AM, Elmar Stellnberger wrote: > For any kind of reason recent m3gdbs refuse to compile at me: > > ../gdb/configure > ... > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > ... > >> which ar > /usr/bin/ar > > setting --bindir to /usr/bin or /usr does not help. > full error log: see attachement > > Should I compile m3gdb towards 32bit on an x86_64 platform if the > m3build I am using is 32bit? > > Besides this I am in wonder why a plain gdb can not access global > Modula-3 variables using PM3/EZM3 although I have specified -gstabs in > m3config/src/COMMON: > ASM = ["as","--32","-gstabs","-o"] % Assembler > DEBUG_FLAG = "-gstabs" % debugging info > BDEBUG_FLAG = "-gstabs" % debugging info > LDEBUG_FLAG = "-gstabs" > > i.e. >> gdb -batch --directory= > --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info > variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls > >> grep myglobal smbls -> nothing found > >> ../gdb/configure > creating cache ./config.cache > checking host system type... x86_64-unknown-linux-gnu > checking target system type... x86_64-unknown-linux-gnu > checking build system type... x86_64-unknown-linux-gnu > checking for a BSD compatible install... /usr/bin/install -c > checking whether ln works... yes > checking whether ln -s works... yes > checking for gcc... gcc > checking whether the C compiler (gcc ) works... yes > checking whether the C compiler (gcc ) is a cross-compiler... no > checking whether we are using GNU C... yes > checking whether gcc accepts -g... yes > checking for gnatbind... no > checking whether compiler driver understands Ada... no > checking how to compare bootstrapped objects... cmp --ignore- > initial=16 $$f1 $$f2 > checking for correct version of gmp.h... yes > checking for MPFR... no > checking for bison... bison > checking for bison... bison -y > checking for gm4... no > checking for gnum4... no > checking for m4... m4 > checking for flex... flex > checking for flex... flex > checking for makeinfo... makeinfo > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > checking for x86_64-unknown-linux-gnu-as... no > checking for as... as > checking for x86_64-unknown-linux-gnu-dlltool... no > checking for dlltool... no > checking for x86_64-unknown-linux-gnu-ld... /usr/lib64/gcc/x86_64- > suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld > checking for x86_64-unknown-linux-gnu-nm... no > checking for nm... nm > checking for x86_64-unknown-linux-gnu-ranlib... no > checking for ranlib... ranlib > checking for x86_64-unknown-linux-gnu-windres... no > checking for windres... no > checking for x86_64-unknown-linux-gnu-objcopy... no > checking for objcopy... objcopy > checking for x86_64-unknown-linux-gnu-objdump... no > checking for objdump... objdump > checking for x86_64-unknown-linux-gnu-ar... no > checking for ar... ar > checking for x86_64-unknown-linux-gnu-as... no > checking for as... as > checking for x86_64-unknown-linux-gnu-cc... no > checking for cc... cc > checking for x86_64-unknown-linux-gnu-c++... no > checking for c++... c++ > checking for x86_64-unknown-linux-gnu-dlltool... no > checking for dlltool... no > checking for x86_64-unknown-linux-gnu-gcc... no > checking for gcc... gcc > checking for x86_64-unknown-linux-gnu-gcj... no > checking for gcj... no > checking for x86_64-unknown-linux-gnu-gfortran... no > checking for gfortran... no > checking for x86_64-unknown-linux-gnu-ld... no > checking for ld... ld > checking for x86_64-unknown-linux-gnu-lipo... no > checking for lipo... no > checking for x86_64-unknown-linux-gnu-nm... no > checking for nm... nm > checking for x86_64-unknown-linux-gnu-objdump... no > checking for objdump... objdump > checking for x86_64-unknown-linux-gnu-ranlib... no > checking for ranlib... ranlib > checking for x86_64-unknown-linux-gnu-strip... no > checking for strip... strip > checking for x86_64-unknown-linux-gnu-windres... no > checking for windres... no > checking whether to enable maintainer-specific portions of > Makefiles... no > checking if symbolic links between directories work... yes > updating cache ./config.cache > creating ./config.status > creating Makefile > elm:/home/sources/mm3/language/modula3/m3tools/m3gdb-cm3-2009-06-09/ > SUSE11.1> make > make[1]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1' > mkdir -p -- ./libiberty > Configuring in ./libiberty > configure: creating cache ./config.cache > checking whether to enable maintainer-specific portions of > Makefiles... no > checking for makeinfo... /home/sources/mm3/language/modula3/m3tools/ > m3gdb-cm3-2009-06-09/gdb/missing makeinfo --split-size=5000000 > configure: WARNING: > *** Makeinfo is missing. Info documentation will not be built. > checking for perl... perl > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking for x86_64-unknown-linux-gnu-ar... ar > checking for x86_64-unknown-linux-gnu-ranlib... ranlib > checking for x86_64-unknown-linux-gnu-gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking how to run the C preprocessor... gcc -E > checking whether gcc and cc understand -c and -o together... yes > checking for an ANSI C-conforming const... yes > checking for inline... inline > checking whether byte ordering is bigendian... no > checking for a BSD-compatible install... /usr/bin/install -c > checking for sys/file.h... yes > checking for sys/param.h... yes > checking for limits.h... yes > checking for stdlib.h... yes > checking for malloc.h... yes > checking for string.h... yes > checking for unistd.h... yes > checking for strings.h... yes > checking for sys/time.h... yes > checking for time.h... yes > checking for sys/resource.h... yes > checking for sys/stat.h... yes > checking for sys/mman.h... yes > checking for fcntl.h... yes > checking for alloca.h... yes > checking for sys/pstat.h... no > checking for sys/sysmp.h... no > checking for sys/sysinfo.h... yes > checking for machine/hal_sysinfo.h... no > checking for sys/table.h... no > checking for sys/sysctl.h... yes > checking for sys/systemcfg.h... no > checking for stdint.h... yes > checking for stdio_ext.h... yes > checking for sys/wait.h that is POSIX.1 compatible... yes > checking whether time.h and sys/time.h may both be included... yes > checking whether errno must be declared... no > checking for egrep... grep -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... (cached) yes > checking for stdlib.h... (cached) yes > checking for string.h... (cached) yes > checking for memory.h... yes > checking for strings.h... (cached) yes > checking for inttypes.h... yes > checking for stdint.h... (cached) yes > checking for unistd.h... (cached) yes > checking for int... yes > checking size of int... 4 > checking for uintptr_t... yes > checking for a 64-bit type... uint64_t > checking for pid_t... yes > checking for library containing strerror... none required > checking for asprintf... yes > checking for atexit... yes > checking for basename... yes > checking for bcmp... yes > checking for bcopy... yes > checking for bsearch... yes > checking for bzero... yes > checking for calloc... yes > checking for clock... yes > checking for ffs... yes > checking for getcwd... yes > checking for getpagesize... yes > checking for gettimeofday... yes > checking for index... yes > checking for insque... yes > checking for memchr... yes > checking for memcmp... yes > checking for memcpy... yes > checking for memmove... yes > checking for mempcpy... yes > checking for memset... yes > checking for mkstemps... no > checking for putenv... yes > checking for random... yes > checking for rename... yes > checking for rindex... yes > checking for setenv... yes > checking for snprintf... yes > checking for sigsetmask... yes > checking for stpcpy... yes > checking for stpncpy... yes > checking for strcasecmp... yes > checking for strchr... yes > checking for strdup... yes > checking for strncasecmp... yes > checking for strndup... yes > checking for strrchr... yes > checking for strstr... yes > checking for strtod... yes > checking for strtol... yes > checking for strtoul... yes > checking for strverscmp... yes > checking for tmpnam... yes > checking for vasprintf... yes > checking for vfprintf... yes > checking for vprintf... yes > checking for vsnprintf... yes > checking for vsprintf... yes > checking for waitpid... yes > checking whether alloca needs Cray hooks... no > checking stack direction for C alloca... -1 > checking for unistd.h... (cached) yes > checking for vfork.h... no > checking for fork... yes > checking for vfork... yes > checking for working fork... yes > checking for working vfork... (cached) yes > checking for _doprnt... no > checking for sys_errlist... yes > checking for sys_nerr... yes > checking for sys_siglist... yes > checking for external symbol _system_configuration... no > checking for getrusage... yes > checking for on_exit... yes > checking for psignal... yes > checking for strerror... yes > checking for strsignal... yes > checking for sysconf... yes > checking for times... yes > checking for sbrk... yes > checking for gettimeofday... (cached) yes > checking for realpath... yes > checking for canonicalize_file_name... yes > checking for pstat_getstatic... no > checking for pstat_getdynamic... no > checking for sysmp... no > checking for getsysinfo... no > checking for table... no > checking for sysctl... yes > checking for wait3... yes > checking for wait4... yes > checking for __fsetlocking... yes > checking whether basename is declared... no > checking whether ffs is declared... yes > checking whether asprintf is declared... no > checking whether vasprintf is declared... no > checking whether snprintf is declared... yes > checking whether vsnprintf is declared... yes > checking whether calloc is declared... yes > checking whether getenv is declared... yes > checking whether getopt is declared... yes > checking whether malloc is declared... yes > checking whether realloc is declared... yes > checking whether sbrk is declared... yes > checking whether strverscmp is declared... no > checking whether canonicalize_file_name must be declared... yes > checking for stdlib.h... (cached) yes > checking for unistd.h... (cached) yes > checking for getpagesize... (cached) yes > checking for working mmap... yes > checking for working strncmp... yes > updating cache ./config.cache > configure: creating ./config.status > config.status: creating Makefile > config.status: creating testsuite/Makefile > config.status: creating config.h > config.status: executing default commands > mkdir -p -- ./bfd > Configuring in ./bfd > configure: creating cache ./config.cache > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking target system type... x86_64-unknown-linux-gnu > checking for x86_64-unknown-linux-gnu-gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for library containing strerror... none required > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking for x86_64-unknown-linux-gnu-ar... ar > checking for x86_64-unknown-linux-gnu-ranlib... ranlib > checking for ld used by GCC... /usr/lib64/gcc/x86_64-suse-linux/ > 4.3/../../../../x86_64-suse-linux/bin/ld > checking if the linker (/usr/lib64/gcc/x86_64-suse-linux/ > 4.3/../../../../x86_64-suse-linux/bin/ld) is GNU ld... yes > checking for /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64- > suse-linux/bin/ld option to reload object files... -r > checking for BSD-compatible nm... nm > checking whether ln -s works... yes > checking how to recognise dependant libraries... file_magic ELF [0-9] > [0-9]*-bit [LM]SB (shared object|dynamic lib ) > checking for x86_64-unknown-linux-gnu-file... no > checking for file... /usr/bin/file > checking for x86_64-unknown-linux-gnu-ranlib... (cached) ranlib > checking for x86_64-unknown-linux-gnu-strip... no > checking for strip... strip > updating cache ./config.cache > loading cache ./config.cache within ltconfig > checking for objdir... .libs > checking for gcc option to produce PIC... -fPIC -DPIC > checking if gcc PIC flag -fPIC -DPIC works... yes > checking if gcc static flag -static works... yes > finding the maximum length of command line arguments... 49153 > checking if gcc supports -c -o file.o... yes > checking if gcc supports -fno-rtti -fno-exceptions ... no > checking whether the linker (/usr/lib64/gcc/x86_64-suse-linux/ > 4.3/../../../../x86_64-suse-linux/bin/ld) supports shared > libraries... yes > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking command to parse nm output... ok > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... no > checking whether to build static libraries... yes > creating libtool > updating cache ./config.cache > configure: loading cache ./config.cache > Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing- > prototypes -Werror > checking whether to enable maintainer-specific portions of > Makefiles... no > checking whether to install libbfd... yes > checking for x86_64-unknown-linux-gnu-gcc... (cached) gcc > checking whether we are using the GNU C compiler... (cached) yes > checking whether gcc accepts -g... (cached) yes > checking for gcc option to accept ANSI C... (cached) none needed > checking for x86_64-unknown-linux-gnu-ranlib... (cached) ranlib > checking how to run the C preprocessor... gcc -E > checking for egrep... grep -E > checking for ANSI C header files... yes > checking for an ANSI C-conforming const... yes > checking for inline... inline > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking for off_t... yes > checking for size_t... yes > checking for working alloca.h... yes > checking for alloca... yes > checking for stdlib.h... (cached) yes > checking for unistd.h... (cached) yes > checking for getpagesize... yes > checking for working mmap... yes > checking argz.h usability... yes > checking argz.h presence... yes > checking for argz.h... yes > checking limits.h usability... yes > checking limits.h presence... yes > checking for limits.h... yes > checking locale.h usability... yes > checking locale.h presence... yes > checking for locale.h... yes > checking nl_types.h usability... yes > checking nl_types.h presence... yes > checking for nl_types.h... yes > checking malloc.h usability... yes > checking malloc.h presence... yes > checking for malloc.h... yes > checking for string.h... (cached) yes > checking for unistd.h... (cached) yes > checking values.h usability... yes > checking values.h presence... yes > checking for values.h... yes > checking sys/param.h usability... yes > checking sys/param.h presence... yes > checking for sys/param.h... yes > checking for getcwd... yes > checking for munmap... yes > checking for putenv... yes > checking for setenv... yes > checking for setlocale... yes > checking for strchr... yes > checking for strcasecmp... yes > checking for __argz_count... yes > checking for __argz_stringify... yes > checking for __argz_next... yes > checking for stpcpy... yes > checking for LC_MESSAGES... yes > checking whether NLS is requested... yes > checking whether included gettext is requested... no > checking libintl.h usability... yes > checking libintl.h presence... yes > checking for libintl.h... yes > checking for gettext in libc... yes > checking for msgfmt... /usr/bin/msgfmt > checking for dcgettext... yes > checking for gmsgfmt... /usr/bin/msgfmt > checking for xgettext... /usr/bin/xgettext > checking for catalogs to be installed... fr tr ja es sv da zh_CN ro > rw vi > checking for a BSD-compatible install... /usr/bin/install -c > checking for long long... yes > checking for long long... yes > checking size of long long... 8 > checking for long... yes > checking size of long... 8 > checking stddef.h usability... yes > checking stddef.h presence... yes > checking for stddef.h... yes > checking for string.h... (cached) yes > checking for strings.h... (cached) yes > checking for stdlib.h... (cached) yes > checking time.h usability... yes > checking time.h presence... yes > checking for time.h... yes > checking for unistd.h... (cached) yes > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking whether time.h and sys/time.h may both be included... yes > checking for dirent.h that defines DIR... yes > checking for library containing opendir... none required > checking whether string.h and strings.h may both be included... yes > checking for fcntl... yes > checking for getpagesize... (cached) yes > checking for setitimer... yes > checking for sysconf... yes > checking for fdopen... yes > checking for getuid... yes > checking for getgid... yes > checking for strtoull... yes > checking whether basename is declared... yes > checking whether ftello is declared... yes > checking whether ftello64 is declared... yes > checking whether fseeko is declared... yes > checking whether fseeko64 is declared... yes > checking whether ffs is declared... yes > checking whether free is declared... yes > checking whether getenv is declared... yes > checking whether malloc is declared... yes > checking whether realloc is declared... yes > checking whether stpcpy is declared... yes > checking whether strstr is declared... yes > checking whether snprintf is declared... yes > checking whether vsnprintf is declared... yes > checking sys/procfs.h usability... yes > checking sys/procfs.h presence... yes > checking for sys/procfs.h... yes > checking for prstatus_t in sys/procfs.h... yes > checking for prstatus32_t in sys/procfs.h... no > checking for prstatus_t.pr_who in sys/procfs.h... no > checking for prstatus32_t.pr_who in sys/procfs.h... no > checking for pstatus_t in sys/procfs.h... no > checking for pxstatus_t in sys/procfs.h... no > checking for pstatus32_t in sys/procfs.h... no > checking for prpsinfo_t in sys/procfs.h... yes > checking for prpsinfo32_t in sys/procfs.h... no > checking for psinfo_t in sys/procfs.h... no > checking for psinfo32_t in sys/procfs.h... no > checking for lwpstatus_t in sys/procfs.h... no > checking for lwpxstatus_t in sys/procfs.h... no > checking for lwpstatus_t.pr_context in sys/procfs.h... no > checking for lwpstatus_t.pr_reg in sys/procfs.h... no > checking for win32_pstatus_t in sys/procfs.h... no > checking for gcc version with buggy 64-bit support... no > checking for ftello... yes > checking for ftello64... yes > checking for fseeko... yes > checking for fseeko64... yes > checking for fopen64... yes > checking for off_t... (cached) yes > checking size of off_t... 8 > checking file_ptr type... BFD_HOST_64_BIT > checking for stdlib.h... (cached) yes > checking for unistd.h... (cached) yes > checking for getpagesize... (cached) yes > checking for working mmap... (cached) yes > checking for madvise... yes > checking for mprotect... yes > updating cache ./config.cache > configure: creating ./config.status > config.status: creating Makefile > config.status: creating doc/Makefile > config.status: creating bfd-in3.h > config.status: creating po/Makefile.in > config.status: creating config.h > config.status: executing depfiles commands > config.status: executing default commands > make[2]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/libiberty' > if [ x"" != x ] && [ ! -d pic ]; then \ > mkdir pic; \ > else true; fi > touch stamp-picdir > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/regex.c -o pic/regex.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/regex.c -o regex.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/cplus-dem.c -o pic/cplus-dem.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/cplus-dem.c -o cplus-dem.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/cp-demangle.c -o pic/cp-demangle.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/cp-demangle.c -o cp-demangle.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/md5.c -o pic/md5.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/md5.c -o md5.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/alloca.c -o pic/alloca.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/alloca.c -o alloca.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/argv.c -o pic/argv.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/argv.c -o argv.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/choose-temp.c -o pic/choose-temp.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/choose-temp.c -o choose-temp.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/concat.c -o pic/concat.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/concat.c -o concat.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/cp-demint.c -o pic/cp-demint.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/cp-demint.c -o cp-demint.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/dyn-string.c -o pic/dyn-string.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/dyn-string.c -o dyn-string.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/fdmatch.c -o pic/fdmatch.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/fdmatch.c -o fdmatch.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/fibheap.c -o pic/fibheap.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/fibheap.c -o fibheap.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/floatformat.c -o pic/floatformat.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/floatformat.c -o floatformat.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/fnmatch.c -o pic/fnmatch.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/fnmatch.c -o fnmatch.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/fopen_unlocked.c -o pic/ > fopen_unlocked.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/fopen_unlocked.c -o fopen_unlocked.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/getopt.c -o pic/getopt.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/getopt.c -o getopt.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/getopt1.c -o pic/getopt1.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/getopt1.c -o getopt1.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/getpwd.c -o pic/getpwd.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/getpwd.c -o getpwd.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/getruntime.c -o pic/getruntime.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/getruntime.c -o getruntime.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/hashtab.c -o pic/hashtab.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/hashtab.c -o hashtab.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/hex.c -o pic/hex.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/hex.c -o hex.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/lbasename.c -o pic/lbasename.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/lbasename.c -o lbasename.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/lrealpath.c -o pic/lrealpath.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/lrealpath.c -o lrealpath.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/make-relative-prefix.c -o pic/make- > relative-prefix.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/make-relative-prefix.c -o make-relative-prefix.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/make-temp-file.c -o pic/make-temp- > file.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/make-temp-file.c -o make-temp-file.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/objalloc.c -o pic/objalloc.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/objalloc.c -o objalloc.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/obstack.c -o pic/obstack.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/obstack.c -o obstack.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/partition.c -o pic/partition.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/partition.c -o partition.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/pexecute.c -o pic/pexecute.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/pexecute.c -o pexecute.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/physmem.c -o pic/physmem.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/physmem.c -o physmem.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/pex-common.c -o pic/pex-common.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/pex-common.c -o pex-common.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/pex-one.c -o pic/pex-one.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/pex-one.c -o pex-one.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/pex-unix.c -o pic/pex-unix.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/pex-unix.c -o pex-unix.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/safe-ctype.c -o pic/safe-ctype.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/safe-ctype.c -o safe-ctype.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/sort.c -o pic/sort.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/sort.c -o sort.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/spaces.c -o pic/spaces.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/spaces.c -o spaces.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/splay-tree.c -o pic/splay-tree.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/splay-tree.c -o splay-tree.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/strerror.c -o pic/strerror.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/strerror.c -o strerror.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/strsignal.c -o pic/strsignal.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/strsignal.c -o strsignal.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/ternary.c -o pic/ternary.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/ternary.c -o ternary.o > ../../gdb/libiberty/ternary.c:144: warning: ?ternary_recursivesearch > ? defined but not used > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/unlink-if-ordinary.c -o pic/unlink- > if-ordinary.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/unlink-if-ordinary.c -o unlink-if-ordinary.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xatexit.c -o pic/xatexit.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xatexit.c -o xatexit.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xexit.c -o pic/xexit.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xexit.c -o xexit.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xmalloc.c -o pic/xmalloc.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xmalloc.c -o xmalloc.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xmemdup.c -o pic/xmemdup.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xmemdup.c -o xmemdup.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xstrdup.c -o pic/xstrdup.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xstrdup.c -o xstrdup.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xstrerror.c -o pic/xstrerror.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xstrerror.c -o xstrerror.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/xstrndup.c -o pic/xstrndup.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/xstrndup.c -o xstrndup.o > if [ x"" != x ]; then \ > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../ > include -W -Wall -pedantic -Wwrite-strings -Wstrict- > prototypes ../../gdb/libiberty/mkstemps.c -o pic/mkstemps.o; \ > else true; fi > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gdb/libiberty/../include - > W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../gdb/ > libiberty/mkstemps.c -o mkstemps.o > rm -f ./libiberty.a pic/./libiberty.a > ar rc ./libiberty.a \ > ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./ > alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn- > string.o ./fdmatch.o ./fibheap.o ./floatformat.o ./fnmatch.o ./ > fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./ > hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative- > prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./ > pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./ > safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./ > strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./ > xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./ > xstrndup.o ./mkstemps.o > ranlib ./libiberty.a > if [ x"" != x ]; then \ > cd pic; \ > ar rc ./libiberty.a \ > ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./ > alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn- > string.o ./fdmatch.o ./fibheap.o ./floatformat.o ./fnmatch.o ./ > fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./ > hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative- > prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./ > pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./ > safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./ > strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./ > xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./ > xstrndup.o ./mkstemps.o; \ > ranlib ./libiberty.a; \ > cd ..; \ > else true; fi > rm -f needed-list; touch needed-list; \ > for f in atexit calloc memchr memcmp memcpy memmove memset > rename strchr strerror strncmp strrchr strstr strtol strtoul tmpnam > vfprintf vprintf vfork waitpid bcmp bcopy bzero; do \ > for g in ./mkstemps.o ; do \ > case "$g" in \ > *$f*) echo $g >> needed-list ;; \ > esac; \ > done; \ > done > echo ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o ./ > argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o ./ > fdmatch.o ./fibheap.o ./floatformat.o ./fnmatch.o ./ > fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./ > hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative- > prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./ > pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./ > safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./ > strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./ > xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./ > xstrndup.o > required-list > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/libiberty/testsuite' > make[3]: F?r das Ziel ?all? ist nichts zu tun. > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/libiberty/testsuite' > make[2]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/libiberty' > make[2]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd' > Making info in doc > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > make chew > make[4]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > gcc -o chew.$$ ../../../gdb/bfd/doc/chew.c \ > -g -O2 \ > -I.. -I../../../gdb/bfd/doc/.. -I../../../gdb/bfd/doc/../../ > include -I../../../gdb/bfd/doc/../../intl -I../../intl; \ > /bin/sh ../../../gdb/bfd/doc/../../move-if-change chew.$$ chew > make[4]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > ./chew -f ../../../gdb/bfd/doc/doc.str <../../../gdb/bfd/doc/../ > aoutx.h >aoutx.tmp > /bin/sh ../../../gdb/bfd/doc/../../move-if-change aoutx.tmp aoutx.texi > make chew > make[4]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > make[4]: ?chew? ist bereits aktualisiert. > make[4]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > ./chew -f ../../../gdb/bfd/doc/doc.str <../../../gdb/bfd/doc/../ > archive.c >archive.tmp > /bin/sh ../../../gdb/bfd/doc/../../move-if-change archive.tmp > archive.texi > make chew > make[4]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > make[4]: ?chew? ist bereits aktualisiert. > make[4]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > ./chew -f ../../../gdb/bfd/doc/doc.str < ../../../gdb/bfd/doc/../ > archures.c >archures.tmp > /bin/sh ../../../gdb/bfd/doc/../../move-if-change archures.tmp > archures.texi > restore=: && backupdir=".am$$" && \ > am__cwd=`pwd` && cd ../../../gdb/bfd/doc && \ > rm -rf $backupdir && mkdir $backupdir && \ > for f in ../../../gdb/bfd/doc/bfd.info ../../../gdb/bfd/doc/ > bfd.info-[0-9] ../../../gdb/bfd/doc/bfd.info-[0-9][0-9] ../../../gdb/ > bfd/doc/bfd.i[0-9] ../../../gdb/bfd/doc/bfd.i[0-9][0-9]; do \ > if test -f $f; then mv $f $backupdir; restore=mv; else :; > fi; \ > done; \ > cd "$am__cwd"; \ > if /home/sources/mm3/language/modula3/m3tools/m3gdb- > cm3-2009-06-09/gdb/missing makeinfo --split-size=5000000 --split- > size=5000000 -I ../../../gdb/bfd/doc \ > -o ../../../gdb/bfd/doc/bfd.info ../../../gdb/bfd/doc/ > bfd.texinfo; \ > then \ > rc=0; \ > cd ../../../gdb/bfd/doc; \ > else \ > rc=$?; \ > cd ../../../gdb/bfd/doc && \ > $restore $backupdir/* `echo "./../../../gdb/bfd/doc/ > bfd.info" | sed 's|[^/]*$||'`; \ > fi; \ > rm -rf $backupdir; exit $rc > WARNING: `makeinfo' is missing on your system. You should only need > it if > you modified a `.texi' or `.texinfo' file, or any other file > indirectly affecting the aspect of the manual. The spurious > call might also be the consequence of using a buggy > `make' (AIX, > DU, IRIX). You might want to install the `Texinfo' package or > the `GNU make' package. Grab either from any GNU archive > site. > make[3]: *** [../../../gdb/bfd/doc/bfd.info] Fehler 1 > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/doc' > Making info in po > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/po' > ( if test 'x../../../gdb/bfd/po' != 'x.'; then \ > posrcprefix='../../../gdb/bfd/'; \ > else \ > posrcprefix="../"; \ > fi; \ > rm -f SRC-POTFILES-t SRC-POTFILES \ > && (sed -e '/^#/d' \ > -e '/^[ ]*$/d' \ > -e "s at .*@ $posrcprefix& \\\\@" < ../../../gdb/ > bfd/po/SRC-POTFILES.in \ > | sed -e '$s/\\$//') > SRC-POTFILES-t \ > && chmod a-w SRC-POTFILES-t \ > && mv SRC-POTFILES-t SRC-POTFILES ) > ( rm -f BLD-POTFILES-t BLD-POTFILES \ > && (sed -e '/^#/d' \ > -e '/^[ ]*$/d' \ > -e "s at .*@ ../& \\\\@" < ../../../gdb/bfd/po/BLD- > POTFILES.in \ > | sed -e '$s/\\$//') > BLD-POTFILES-t \ > && chmod a-w BLD-POTFILES-t \ > && mv BLD-POTFILES-t BLD-POTFILES ) > cd .. \ > && CONFIG_FILES=po/Makefile.in:po/Make-in \ > CONFIG_HEADERS= /bin/sh ./config.status > config.status: creating po/Makefile.in > config.status: executing depfiles commands > config.status: executing default commands > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/po' > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/po' > make[3]: F?r das Ziel ?info? ist nichts zu tun. > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd/po' > make[3]: Entering directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd' > make[3]: F?r das Ziel ?info-am? ist nichts zu tun. > make[3]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd' > make[2]: *** [info-recursive] Fehler 1 > make[2]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1/bfd' > make[1]: *** [all-bfd] Fehler 2 > make[1]: Leaving directory `/home/sources/mm3/language/modula3/ > m3tools/m3gdb-cm3-2009-06-09/SUSE11.1' > make: *** [all] Fehler 2 From estellnb at yahoo.de Thu Jun 11 15:16:56 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Thu, 11 Jun 2009 14:16:56 +0100 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: References: <4A2FC281.1030101@yahoo.de> Message-ID: <4A3103C8.10707@yahoo.de> Even if all the global variables are put into one large struct it should be possible to read this struct via gdb. Unfortunately that does not seem to be the case. Let us consider a small sample program in this regard: MODULE GlobVars EXPORTS Main; VAR aaa, bbb, ccc, ddd : INTEGER := 1; ttt : TEXT := "SampleText"; BEGIN bbb := 2; ccc := bbb + aaa; ddd := ccc + bbb; END GlobVars. If I look at the intermediate zero address code there is a well defined record for all the globals: ... # module global data declare_segment M_GlobVars -1 v.1 ... load_integer 2 store v.1 48 Int -----LINE 8 ----- load v.1 48 Int load v.1 44 Int add Int store v.1 52 Int ... # global data type descriptor declare_record -1 1248 6 declare_field M3_MAIN 320 32 2071511887 declare_field aaa 352 32 425470580 declare_field bbb 384 32 425470580 declare_field ccc 416 32 425470580 declare_field ddd 448 32 425470580 declare_field ttt 480 32 1358456180 ... whereby the record offsets in the data type definition are bit oriented and have to be devided by eight: 352/8 = 44 (var. aaa) The corresponding assembler code looks like the following: movl MM_GlobVars at GOT(%ebx), %eax movl $2, 48(%eax) # bbb:=2 However using gdb I can not access any of the members of the MM_GlobVars struct (gdb) p MM_GlobVars.aaa There is no member named aaa. (gdb) p MM_GlobVars $18 = {} Trying to access our globals directly via their offsets listed in the .mc and .ms files worked at least although there seems to exist a quite strange mismatch. At first I had to subtract from MM_GlobVars rather than adding the offset. Secondly I had to interpret the offset as hex number although it is clear that in the .mc-file offsets are meant as plain decimal integer numbers (i.e. 0x48=72, but 48 was decimal just before!: i.e. 48*8=384 and not 0x48*0x8=0x384) p *((int*)((void*)MM_GlobVars-72 $16 = 1 p *((int*)((void*)MM_GlobVars-76 $17 = 2 Apparently the inability to access global variables via gdb as members of the module structure may be a flaw m3cc; right? ... but what about the add/sub dec/hex mismatch from above? Jay schrieb: > The global variable behavior I think I understand, and I believe the original authors did it this way on purpose, but I agree it seems quite bad. > > > The way the code is generated, all the internal globals for a module are in one large struct, per module. > > There aren't symbols for each one. > > > > > > Can anyone explain why it is done this way? And why it shouldn't be changed to how I showed? > > > > Here are some advantages/disadvanges: > > symbols, debuggability, as discussed > > The current way pretty much guaranteeds none of the data gets dead-stripped, for better and worse. > > But really, even if you changed it to "my way", there's probably another bit needed on the data to dead-strip it, > > so that behavior can be preserved, for better and worse. > > "My way" probably also allows for not using bitfields in load/store, in fact, the offseting would often go away too. > > > > > >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? > > > > > > It should build either way, but for it to be useful, yes, I expect so. > > I believe current versions of gdb can have multiple targets though. > > > > > > - Jay > > >> Date: Wed, 10 Jun 2009 15:26:09 +0100 >> From: estellnb at yahoo.de >> To: m3devel at elegosoft.com >> Subject: [M3devel] recent m3gdb does not want to compile >> >> For any kind of reason recent m3gdbs refuse to compile at me: >> >> ../gdb/configure >> ... >> checking for x86_64-unknown-linux-gnu-ar... no >> checking for ar... ar >> ... >> >>> which ar >> /usr/bin/ar >> >> setting --bindir to /usr/bin or /usr does not help. >> full error log: see attachement >> >> Should I compile m3gdb towards 32bit on an x86_64 platform if the >> m3build I am using is 32bit? >> >> Besides this I am in wonder why a plain gdb can not access global >> Modula-3 variables using PM3/EZM3 although I have specified -gstabs in >> m3config/src/COMMON: >> ASM = ["as","--32","-gstabs","-o"] % Assembler >> DEBUG_FLAG = "-gstabs" % debugging info >> BDEBUG_FLAG = "-gstabs" % debugging info >> LDEBUG_FLAG = "-gstabs" >> >> i.e. >>> gdb -batch --directory= >> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info >> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls >> >>> grep myglobal smbls -> nothing found > From rodney.m.bates at cox.net Thu Jun 11 15:05:32 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 11 Jun 2009 08:05:32 -0500 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> Message-ID: <4A31011C.2070700@cox.net> Jay wrote: > scripts/do-cm3-m3gdb.sh just cd's over to m3-sys/m3gdb and runs cm3. > > m3gdb builds and seems to work fine for me. > > Specifically, on AMD64_LINUX birch, I can both: > > mkdir -p $HOME/obj/gdb > cd $HOME/obj/gdb > $HOME/dev2/cm3/m3-sys/m3gdb/gdb/configure && make > gdb/gdb gdb/gdb > break main > r > > and > > cd $HOME/dev2/cm3/m3-sys/m3gdb > rm -rf AMD64_LINUX > cm3 > > > AMD64_LINUX/m3gdb AMD64_LINUX/m3gdb > break main > r > > > I haven't tried with Modula-3 code and/or stabs. > > > Updating from the 2005 6.4 release to a current 6.8 release is > probably advisable anyway. > > > But again, um, er, could we maybe adapt the generated code so that > plain gdb is all anyone would need/want? I don't think so. There is ~ 20K lines of Modula-3-specific code in m3gdb, and I have tens of pages of handwritten lists of more that ought to be done to make it a nice M3 debugger. I think doing it all could easily double this. The variable reference rules are different from C/C++, for example, because of the link between a module and its exported interface(s). The global variable thing is just the tip of the iceberg. For example, there is a whole lot to making procedure calls and method calls work. Ditto for nested procedures, which, after several iterations, is broken again by the change to the newest gcc as the base for the code generator, although it works somewhat. Note that gdb provides no real support for nested functions in C, even though gcc supports them as an extension to C. Probably, they are little used in C. I use them a lot in M3. Then there are just all the language-specific formats for input and output values, and expression syntax. Plus, Modula-3, being a considerably higher-level language, (at least optionally,) has a significant runtime system, and m3gdb needs to know \ quite a bit about that too. Real arrays and open arrays also need support. And TEXT is a lot different. There are also some significant differences between cm3 and the earlier compilers. I have taken the position that support for the older ones should remain, along with new stuff too. What we should do, in addition to updating to newest gdb, is change from stabs to dwarf2 debug info format, which is *much* richer in what it can express. stabs was something of a cobbled up mess to begin with, and the M3-specific extensions to it only make it worse. There's a lot of what has to be seen as very arbitrary stuff, not really stabs, wrapped inside of some of the character strings that stabs has. This change would require a significant amount of code in the compiler, as well as in m3gdb. Someday, it might also be nice to try to get the m3 changes rolled in to the stock gdb. This would require a serious commitment to maintain them there. Also, there are some copyright assertions that DEC put in to some of the code that, I believe were in violation of the GPL. We would have to somehow get a determination that the copyright ownership could be transferred to FSF, to their satisfaction. All the more difficult with DEC's identity having changed twice. IANAL. > > > Cygwin fork being so slow makes me want to optimize out such large > pieces as building gdb. > Maybe I can figure out a way to speed up Cygwin fork some day... > > > - Jay > > From estellnb at yahoo.de Thu Jun 11 21:29:58 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Thu, 11 Jun 2009 20:29:58 +0100 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A31011C.2070700@cox.net> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> Message-ID: <4A315B36.9000700@yahoo.de> As I still have the old PM3/EZM3 in use I do welcome the continuing support for that kind of old compiler tech. Besides all these advanced issues I still simply wonder on how to compile a current m3gdb. As described earlier ./configure does not even find the standard utilities like ar, as, etc. although they are on path: ../gdb/configure --target i686-pc-linux-gnu checking for i686-pc-linux-gnu-ar... no checking for i686-pc-linux-gnu-as... no I will be happy as soon as I can print global integer variables. I can convert Text-vars to char* although that will cause little extra output. The thing is that even some elder m3gdb that I still have a compilate of can not print global vars for any kind of reason (perhaps it would be necessary to update the codegen). Rodney M. Bates schrieb: > Jay wrote: >> scripts/do-cm3-m3gdb.sh just cd's over to m3-sys/m3gdb and runs cm3. >> >> m3gdb builds and seems to work fine for me. >> >> Specifically, on AMD64_LINUX birch, I can both: >> >> mkdir -p $HOME/obj/gdb >> cd $HOME/obj/gdb >> $HOME/dev2/cm3/m3-sys/m3gdb/gdb/configure && make >> gdb/gdb gdb/gdb >> break main >> r >> >> and >> >> cd $HOME/dev2/cm3/m3-sys/m3gdb >> rm -rf AMD64_LINUX >> cm3 >> >> >> AMD64_LINUX/m3gdb AMD64_LINUX/m3gdb >> break main >> r >> >> >> I haven't tried with Modula-3 code and/or stabs. >> >> >> Updating from the 2005 6.4 release to a current 6.8 release is >> probably advisable anyway. >> >> >> But again, um, er, could we maybe adapt the generated code so that >> plain gdb is all anyone would need/want? > I don't think so. There is ~ 20K lines of Modula-3-specific code in > m3gdb, and I have tens of > pages of handwritten lists of more that ought to be done to make it a > nice M3 debugger. > I think doing it all could easily double this. The variable reference > rules are different > from C/C++, for example, because of the link between a module and its > exported > interface(s). > > The global variable thing is just the tip of the iceberg. For example, > there is a whole lot > to making procedure calls and method calls work. Ditto for nested > procedures, which, > after several iterations, is broken again by the change to the newest > gcc as the base for > the code generator, although it works somewhat. Note that gdb provides > no real > support for nested functions in C, even though gcc supports them as an > extension to C. > Probably, they are little used in C. I use them a lot in M3. > > Then there are just all the language-specific formats for input and > output values, > and expression syntax. Plus, Modula-3, being a considerably > higher-level language, > (at least optionally,) has a significant runtime system, and m3gdb needs > to know \ > quite a bit about that too. Real arrays and open arrays also need > support. And > TEXT is a lot different. > > > There are also some significant differences between cm3 and the earlier > compilers. > I have taken the position that support for the older ones should remain, > along with > new stuff too. > > > What we should do, in addition to updating to newest gdb, is change from > stabs to > dwarf2 debug info format, which is *much* richer in what it can > express. stabs was > something of a cobbled up mess to begin with, and the M3-specific > extensions to it > only make it worse. There's a lot of what has to be seen as very > arbitrary stuff, > not really stabs, wrapped inside of some of the character strings that > stabs has. This change would require a significant amount of code in the > compiler, as well > as in m3gdb. > > > Someday, it might also be nice to try to get the m3 changes rolled in to > the stock > gdb. This would require a serious commitment to maintain them there. > Also, there > are some copyright assertions that DEC put in to some of the code that, > I believe > were in violation of the GPL. We would have to somehow get a > determination that > the copyright ownership could be transferred to FSF, to their > satisfaction. All the > more difficult with DEC's identity having changed twice. IANAL. >> >> >> Cygwin fork being so slow makes me want to optimize out such large >> pieces as building gdb. >> Maybe I can figure out a way to speed up Cygwin fork some day... >> >> >> - Jay >> >> > > From jay.krell at cornell.edu Thu Jun 11 22:55:27 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 11 Jun 2009 13:55:27 -0700 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A315B36.9000700@yahoo.de> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> <4A315B36.9000700@yahoo.de> Message-ID: <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> Those are not necessarily errors. It looks for platform-ar and then ar. Plain ar is fine for native builds. You probably should build outside the source tree. It is strongly recommended at least for gcc. - Jay (phone) On Jun 11, 2009, at 12:29 PM, Elmar Stellnberger wrote: > As I still have the old PM3/EZM3 in use I do welcome the continuing > support for that kind of old compiler tech. Besides all these advanced > issues I still simply wonder on how to compile a current m3gdb. As > described earlier ./configure does not even find the standard > utilities > like ar, as, etc. although they are on path: > > ../gdb/configure --target i686-pc-linux-gnu > checking for i686-pc-linux-gnu-ar... no > checking for i686-pc-linux-gnu-as... no > > I will be happy as soon as I can print global integer variables. I > can > convert Text-vars to char* although that will cause little extra > output. > The thing is that even some elder m3gdb that I still have a > compilate of > can not print global vars for any kind of reason (perhaps it would be > necessary to update the codegen). > > Rodney M. Bates schrieb: >> Jay wrote: >>> scripts/do-cm3-m3gdb.sh just cd's over to m3-sys/m3gdb and runs cm3. >>> >>> m3gdb builds and seems to work fine for me. >>> >>> Specifically, on AMD64_LINUX birch, I can both: >>> >>> mkdir -p $HOME/obj/gdb >>> cd $HOME/obj/gdb >>> $HOME/dev2/cm3/m3-sys/m3gdb/gdb/configure && make >>> gdb/gdb gdb/gdb >>> break main >>> r >>> >>> and >>> >>> cd $HOME/dev2/cm3/m3-sys/m3gdb >>> rm -rf AMD64_LINUX >>> cm3 >>> >>> >>> AMD64_LINUX/m3gdb AMD64_LINUX/m3gdb >>> break main >>> r >>> >>> >>> I haven't tried with Modula-3 code and/or stabs. >>> >>> >>> Updating from the 2005 6.4 release to a current 6.8 release is >>> probably advisable anyway. >>> >>> >>> But again, um, er, could we maybe adapt the generated code so that >>> plain gdb is all anyone would need/want? >> I don't think so. There is ~ 20K lines of Modula-3-specific code in >> m3gdb, and I have tens of >> pages of handwritten lists of more that ought to be done to make it a >> nice M3 debugger. >> I think doing it all could easily double this. The variable >> reference >> rules are different >> from C/C++, for example, because of the link between a module and its >> exported >> interface(s). >> >> The global variable thing is just the tip of the iceberg. For >> example, >> there is a whole lot >> to making procedure calls and method calls work. Ditto for nested >> procedures, which, >> after several iterations, is broken again by the change to the newest >> gcc as the base for >> the code generator, although it works somewhat. Note that gdb >> provides >> no real >> support for nested functions in C, even though gcc supports them as >> an >> extension to C. >> Probably, they are little used in C. I use them a lot in M3. >> >> Then there are just all the language-specific formats for input and >> output values, >> and expression syntax. Plus, Modula-3, being a considerably >> higher-level language, >> (at least optionally,) has a significant runtime system, and m3gdb >> needs >> to know \ >> quite a bit about that too. Real arrays and open arrays also need >> support. And >> TEXT is a lot different. >> >> >> There are also some significant differences between cm3 and the >> earlier >> compilers. >> I have taken the position that support for the older ones should >> remain, >> along with >> new stuff too. >> >> >> What we should do, in addition to updating to newest gdb, is change >> from >> stabs to >> dwarf2 debug info format, which is *much* richer in what it can >> express. stabs was >> something of a cobbled up mess to begin with, and the M3-specific >> extensions to it >> only make it worse. There's a lot of what has to be seen as very >> arbitrary stuff, >> not really stabs, wrapped inside of some of the character strings >> that >> stabs has. This change would require a significant amount of code >> in the >> compiler, as well >> as in m3gdb. >> >> >> Someday, it might also be nice to try to get the m3 changes rolled >> in to >> the stock >> gdb. This would require a serious commitment to maintain them there. >> Also, there >> are some copyright assertions that DEC put in to some of the code >> that, >> I believe >> were in violation of the GPL. We would have to somehow get a >> determination that >> the copyright ownership could be transferred to FSF, to their >> satisfaction. All the >> more difficult with DEC's identity having changed twice. IANAL. >>> >>> >>> Cygwin fork being so slow makes me want to optimize out such large >>> pieces as building gdb. >>> Maybe I can figure out a way to speed up Cygwin fork some day... >>> >>> >>> - Jay >>> >>> >> >> > > From jay.krell at cornell.edu Fri Jun 12 07:09:57 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 12 Jun 2009 05:09:57 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> <4A315B36.9000700@yahoo.de> <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> Message-ID: ps: I suggest you try to get stock gdb to build first. wget ftp://sourceware.org/pub/gdb/releases/gdb-6.8.tar.gz tar xfz gdb-6.8.tar.gz mkdir -p obj/gdb cd obj/gdb ../../gdb-6.8/configure && make - Jay [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at yahoo.de Fri Jun 12 12:27:55 2009 From: estellnb at yahoo.de (Elmar Stellnberger) Date: Fri, 12 Jun 2009 11:27:55 +0100 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> <4A315B36.9000700@yahoo.de> <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> Message-ID: <4A322DAB.50000@yahoo.de> Compiling gdb worked on my first attempt. checking for ar... ar checking for as... as The configure script seems to find all standard utils and make compiles gdb well. Jay schrieb: > ps: I suggest you try to get stock gdb to build first. > > > > wget ftp://sourceware.org/pub/gdb/releases/gdb-6.8.tar.gz > tar xfz gdb-6.8.tar.gz > mkdir -p obj/gdb > cd obj/gdb > ../../gdb-6.8/configure && make > > > > - Jay > [snip] > > > From jay.krell at cornell.edu Sat Jun 13 04:14:11 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 13 Jun 2009 02:14:11 +0000 Subject: [M3devel] recent m3gdb does not want to compile In-Reply-To: <4A322DAB.50000@yahoo.de> References: <4A2FC281.1030101@yahoo.de> <4A306A01.5080603@cox.net> <4A31011C.2070700@cox.net> <4A315B36.9000700@yahoo.de> <5B3C1C3C-6D0D-4086-BAD2-F5E92DDB02A7@hotmail.com> <4A322DAB.50000@yahoo.de> Message-ID: Ok, the difference is configure vs. configure --target i686-pc-linux-gnu. cm3 only passes --target for cross builds...er, maybe not. That's how it is for m3cc. But http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3gdb/src/m3makefile?rev=1.13;content-type=text%2Fplain appears to always pass --target. (Have I mentioned I don't pay much attention to m3gdb...?) For now, in m3-sys/m3gdb/src/m3makefile, change this: m3gdb_Run([M3GDB_CONFIG, "../gdb/configure", CONFIG_PLATFORM]) to just this: m3gdb_Run([M3GDB_CONFIG, "../gdb/configure"]) removing the CONFIG_PLATFORM part and see what happens. I expect it will work. That isn't necessarily the right change -- don't commit it. Probably what is right enough is to make it act like m3ccc -- don't give a platform for native builds, only for cross builds. But m3cc/m3gdb/binutils are all fairly unusual, and not necessarily in the same way. Even so..are you after an x86 m3gdb or AMD64? Also, what do m3-sys/m3gdb/gdb/config.guess and m3-sys/m3cc/gcc/config.guess and the current gdb you downloaded/config.guess show? - Jay ---------------------------------------- > Date: Fri, 12 Jun 2009 11:27:55 +0100 > From: estellnb at yahoo.de > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent m3gdb does not want to compile > > Compiling gdb worked on my first attempt. > > checking for ar... ar > checking for as... as > > The configure script seems to find all standard utils and > make compiles gdb well. > > Jay schrieb: >> ps: I suggest you try to get stock gdb to build first. >> >> >> >> wget ftp://sourceware.org/pub/gdb/releases/gdb-6.8.tar.gz >> tar xfz gdb-6.8.tar.gz >> mkdir -p obj/gdb >> cd obj/gdb >> ../../gdb-6.8/configure && make >> >> >> >> - Jay >> [snip] >> >> >> > From jay.krell at cornell.edu Mon Jun 15 09:13:19 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 07:13:19 +0000 Subject: [M3devel] Solaris vfork? => suggest using fork instead? Message-ID: Is this still true: C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(943):(*** vfork - spawn new process in a virtual memory efficient way ***) C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(944):(* Avoid vfork. The way it is used in ProcessPosix breaks incremental GC: ? (*** vfork - spawn new process in a virtual memory efficient way ***) (* Avoid vfork. The way it is used in ProcessPosix breaks incremental GC: RestoreHandlers in child is reflected in parent to break VM faulting *) <*EXTERNAL "fork1"*> PROCEDURE vfork (): int; If this is true, I broke it. C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX does use vfork. Should we just use fork? vfork is the same as fork on Cygwin -- both are slow. There is also reason to use fork on NetBSD. NetBSD renames nearly every single symbol at the link level via special constructs in its header files. As a result, the usual direct extern Modula-3 pragmas are rarely correct there. That is, for the sake of NetBSD, it is best to wrap every C function with our own C functions. However, wrapping functions contradicts the Posix constraints on vfork -- you are not allowed to return from the function calling vfork without calling exec or _exit. Or do no real systems care about that? So, to be clear, I suggest changing ProcessPosix.m3 from vfork to fork. As well as RTPerfTool.m3. I suggest removing vfork from Unix/*.i3, make sure everything compiles -- that nobody uses it -- and then restoring it, in case there is a later need, to avoid bootstrapping problems if there is. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jun 15 13:12:39 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 15 Jun 2009 04:12:39 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> Message-ID: <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Hi Jay, I've been seeing some new errors attempting to build m3cc on OSX 10.4 / ppc. It seems like it might... possibly... be related to some things you have done? Or at least it's happening in the same general area of the compiler. Here we go: cd ../../gcc/mpfr && : make[2]: Nothing to be done for `all-am'. make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all'. make[1]: Nothing to be done for `all'. cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 --procedure-- -line- -file--- cp_if -- postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args Fatal Error: package build failed [lapdog:~/cm3/m3-sys/m3cc] mika% Any ideas what might be causing this? Mika Jay Krell writes: >CVSROOT: /usr/cvs >Changes by: jkrell at birch. 09/06/15 11:49:14 > >Added files: > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > gengtype-yacc.h > >Log message: > Add back the lex/yacc/flex/bison outputs that Apple deleted > but didn't note in the REMOVED file. You only see their > absence cause problems if building on a machine without > lex/yacc/flex/bison, such as birch that is missing bison. > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > so the unmodified versions of these files taken from gcc 4.2.1. From jay.krell at cornell.edu Mon Jun 15 13:26:16 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 11:26:16 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> References: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: You need a newer make. I don't remember upgrading mine, and I am using 10.4, but these are the same errors that Olaf reported on 10.3, and they were fixed by upgrading make for him. If there are really only two relevant uses of patsubst, maybe we can recode them to be more compatible? - Jay > To: jkrell at elego.de; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 15 Jun 2009 04:12:39 -0700 > From: mika at async.caltech.edu > > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: > >CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/06/15 11:49:14 > > > >Added files: > > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > > gengtype-yacc.h > > > >Log message: > > Add back the lex/yacc/flex/bison outputs that Apple deleted > > but didn't note in the REMOVED file. You only see their > > absence cause problems if building on a machine without > > lex/yacc/flex/bison, such as birch that is missing bison. > > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > > so the unmodified versions of these files taken from gcc 4.2.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 15 13:56:45 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 11:56:45 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: Please try with the change to m3makefile I just made. That might reduce or eliminate the errors. The line number didn't match up for me. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:26:16 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 You need a newer make. I don't remember upgrading mine, and I am using 10.4, but these are the same errors that Olaf reported on 10.3, and they were fixed by upgrading make for him. If there are really only two relevant uses of patsubst, maybe we can recode them to be more compatible? - Jay > To: jkrell at elego.de; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 15 Jun 2009 04:12:39 -0700 > From: mika at async.caltech.edu > > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: > >CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/06/15 11:49:14 > > > >Added files: > > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > > gengtype-yacc.h > > > >Log message: > > Add back the lex/yacc/flex/bison outputs that Apple deleted > > but didn't note in the REMOVED file. You only see their > > absence cause problems if building on a machine without > > lex/yacc/flex/bison, such as birch that is missing bison. > > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > > so the unmodified versions of these files taken from gcc 4.2.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 15 13:59:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 11:59:52 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: If that has no positive effect at all, try removing this line from m3makefile: % Save some libtool wrapping layers to speed up esp. on NT? Configure = Configure & " -disable-dependency-tracking" and be sure to rm -rf the output directory after making the change (or picking up my other change). - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:56:45 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Please try with the change to m3makefile I just made. That might reduce or eliminate the errors. The line number didn't match up for me. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:26:16 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 You need a newer make. I don't remember upgrading mine, and I am using 10.4, but these are the same errors that Olaf reported on 10.3, and they were fixed by upgrading make for him. If there are really only two relevant uses of patsubst, maybe we can recode them to be more compatible? - Jay > To: jkrell at elego.de; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 15 Jun 2009 04:12:39 -0700 > From: mika at async.caltech.edu > > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: > >CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/06/15 11:49:14 > > > >Added files: > > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > > gengtype-yacc.h > > > >Log message: > > Add back the lex/yacc/flex/bison outputs that Apple deleted > > but didn't note in the REMOVED file. You only see their > > absence cause problems if building on a machine without > > lex/yacc/flex/bison, such as birch that is missing bison. > > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > > so the unmodified versions of these files taken from gcc 4.2.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 15 14:11:08 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 12:11:08 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 15 Jun 2009 11:49:14." <20090615094914.E34B5CC363@birch.elegosoft.com> <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: Can you show me: /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/libcpp/Makefile(191) and /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/gcc/Makefile(4437) and nearby? And if those don't have patsubst: cd /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN grep -r patsubst * - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Mon, 15 Jun 2009 11:59:52 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 If that has no positive effect at all, try removing this line from m3makefile: % Save some libtool wrapping layers to speed up esp. on NT? Configure = Configure & " -disable-dependency-tracking" and be sure to rm -rf the output directory after making the change (or picking up my other change). - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:56:45 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Please try with the change to m3makefile I just made. That might reduce or eliminate the errors. The line number didn't match up for me. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; jkrell at elego.de Date: Mon, 15 Jun 2009 11:26:16 +0000 CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 You need a newer make. I don't remember upgrading mine, and I am using 10.4, but these are the same errors that Olaf reported on 10.3, and they were fixed by upgrading make for him. If there are really only two relevant uses of patsubst, maybe we can recode them to be more compatible? - Jay > To: jkrell at elego.de; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 15 Jun 2009 04:12:39 -0700 > From: mika at async.caltech.edu > > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: > >CVSROOT: /usr/cvs > >Changes by: jkrell at birch. 09/06/15 11:49:14 > > > >Added files: > > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c > > gengtype-yacc.h > > > >Log message: > > Add back the lex/yacc/flex/bison outputs that Apple deleted > > but didn't note in the REMOVED file. You only see their > > absence cause problems if building on a machine without > > lex/yacc/flex/bison, such as birch that is missing bison. > > Apple didn't modify gengtype-lex.l and gentype-yacc.y, > > so the unmodified versions of these files taken from gcc 4.2.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jun 15 15:29:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 15 Jun 2009 09:29:39 -0400 Subject: [M3devel] Solaris vfork? => suggest using fork instead? In-Reply-To: References: Message-ID: <4CE51F26-EDE3-46F7-9857-248D435669C3@cs.purdue.edu> Signals are no longer used for inc gc so probably ok to switch to fork. On 15 Jun 2009, at 03:13, Jay wrote: > Is this still true: > > > C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(943):(*** > vfork - spawn new process in a virtual memory efficient way ***) > C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(944):(* > Avoid vfork. The way it is used in ProcessPosix breaks incremental GC: > ? > > (*** vfork - spawn new process in a virtual memory efficient way ***) > (* Avoid vfork. The way it is used in ProcessPosix breaks > incremental GC: > RestoreHandlers in child is reflected in parent to break VM faulting > *) > <*EXTERNAL "fork1"*> PROCEDURE vfork (): int; > > > If this is true, I broke it. > > > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX does use vfork. > > > Should we just use fork? > vfork is the same as fork on Cygwin -- both are slow. > > There is also reason to use fork on NetBSD. > NetBSD renames nearly every single symbol at the link level via > special constructs in its header files. > As a result, the usual direct extern Modula-3 pragmas are rarely > correct there. > That is, for the sake of NetBSD, it is best to wrap every C > function with our own C functions. > However, wrapping functions contradicts the Posix constraints on > vfork -- you are not allowed to return from the function calling > vfork without calling exec or _exit. Or do no real systems care > about that? > > > So, to be clear, I suggest changing ProcessPosix.m3 from vfork to > fork. > As well as RTPerfTool.m3. > > > I suggest removing vfork from Unix/*.i3, make sure everything > compiles -- that nobody uses it -- and then restoring it, in case > there is a later need, to avoid bootstrapping problems if there is. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jun 15 21:09:48 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 15 Jun 2009 12:09:48 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 15 Jun 2009 11:56:45 -0000." Message-ID: <200906151909.n5FJ9mJq038972@camembert.async.caltech.edu> Yep, that seems to have fixed that problem. Thanks! Mika Jay writes: >--_b2ac6846-ec7a-45ce-b56a-ddd2a77b25de_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Please try with the change to m3makefile I just made. > >That might reduce or eliminate the errors. > >The line number didn't match up for me. > >=20 > > - Jay >=20 > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu=3B jkrell at elego.de >Date: Mon=2C 15 Jun 2009 11:26:16 +0000 >CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > >You need a newer make. >I don't remember upgrading mine=2C and I am using 10.4=2C but these are the= > same errors that Olaf reported on 10.3=2C and they were fixed by upgrading= > make for him. >=20 >If there are really only two relevant uses of patsubst=2C maybe we can reco= >de them to be more compatible? >=20 > - Jay > >=20 >> To: jkrell at elego.de=3B jay.krell at cornell.edu >> CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >> Subject: Re: [M3commit] CVS Update: cm3=20 >> Date: Mon=2C 15 Jun 2009 04:12:39 -0700 >> From: mika at async.caltech.edu >>=20 >> Hi Jay=2C >>=20 >> I've been seeing some new errors attempting to build m3cc on OSX >> 10.4 / ppc. >>=20 >> It seems like it might... possibly... be related to some things you >> have done? Or at least it's happening in the same general area of >> the compiler. >>=20 >> Here we go: >>=20 >> cd ../../gcc/mpfr && : >> make[2]: Nothing to be done for `all-am'. >> make[2]: Nothing to be done for `all'. >> make[2]: Nothing to be done for `all'. >> make[1]: Nothing to be done for `all'. >> cd . && cd libcpp && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOM= >AKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/c= >m3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> cd . && cd libcpp && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOM= >AKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/c= >m3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> Makefile:191: *** Insufficient number of arguments (2) to function `patsu= >bst'. Stop. >> cd . && cd gcc && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config.h m3cg | tee -= >a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> cd . && cd gcc && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config.h m3cg | tee -= >a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> Makefile:4437: *** Insufficient number of arguments (2) to function `pats= >ubst'. Stop. >> "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile"=2C line 508: quake runtime e= >rror: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=3D2 >>=20 >> --procedure-- -line- -file--- >> cp_if -- >> postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile >> include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile >> 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args >>=20 >> Fatal Error: package build failed >> [lapdog:~/cm3/m3-sys/m3cc] mika%=20 >>=20 >> Any ideas what might be causing this? >>=20 >> Mika >>=20 >>=20 >>=20 >> Jay Krell writes: >> >CVSROOT: /usr/cvs >> >Changes by: jkrell at birch. 09/06/15 11:49:14 >> > >> >Added files: >> > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c=20 >> > gengtype-yacc.h=20 >> > >> >Log message: >> > Add back the lex/yacc/flex/bison outputs that Apple deleted >> > but didn't note in the REMOVED file. You only see their >> > absence cause problems if building on a machine without >> > lex/yacc/flex/bison=2C such as birch that is missing bison. >> > Apple didn't modify gengtype-lex.l and gentype-yacc.y=2C >> > so the unmodified versions of these files taken from gcc 4.2.1. > >--_b2ac6846-ec7a-45ce-b56a-ddd2a77b25de_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Please try with the change to m3makefile I just made.
>That might reduce or eliminate =3Bthe errors.
>The line number didn't match up for me.
> =3B
> =3B- Jay
 =3B
>
>From: jay.krell at cornell.edu
To: mika at async.caltech.edu=3B jkrell at elego.d= >e
Date: Mon=2C 15 Jun 2009 11:26:16 +0000
CC: m3devel at elegosoft.com= >=3B mika at camembert.async.caltech.edu
Subject: Re: [M3devel] [M3commit] C= >VS Update: cm3

> >You need a newer make.
I don't remember upgrading mine=2C and I am using= > 10.4=2C but these are the same errors that Olaf reported on 10.3=2C and th= >ey were fixed by upgrading make for him.
 =3B
If there are really= > only two relevant uses of patsubst=2C maybe we can recode them to be more = >compatible?
 =3B
 =3B- Jay

 =3B
>=3B To: jkre= >ll at elego.de=3B jay.krell at cornell.edu
>=3B CC: m3devel at elegosoft.com=3B= > mika at camembert.async.caltech.edu
>=3B Subject: Re: [M3commit] CVS Upd= >ate: cm3
>=3B Date: Mon=2C 15 Jun 2009 04:12:39 -0700
>=3B From:= > mika at async.caltech.edu
>=3B
>=3B Hi Jay=2C
>=3B
>=3B= > I've been seeing some new errors attempting to build m3cc on OSX
>=3B= > 10.4 / ppc.
>=3B
>=3B It seems like it might... possibly... be = >related to some things you
>=3B have done? Or at least it's happening = >in the same general area of
>=3B the compiler.
>=3B
>=3B He= >re we go:
>=3B
>=3B cd ../../gcc/mpfr &=3B&=3B :
>=3B= > make[2]: Nothing to be done for `all-am'.
>=3B make[2]: Nothing to be= > done for `all'.
>=3B make[2]: Nothing to be done for `all'.
>=3B= > make[1]: Nothing to be done for `all'.
>=3B cd . &=3B&=3B cd li= >bcpp &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/cm3/= >m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
>=3B cd . &=3B&=3B cd libc= >pp &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/cm3/= >m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
>=3B Makefile:191: *** Insuffici= >ent number of arguments (2) to function `patsubst'. Stop.
>=3B cd . &a= >mp=3B&=3B cd gcc &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCO= >NF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config= >.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
&= >gt=3B cd . &=3B&=3B cd gcc &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-= >O2 -g" AUTOCONF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-mode= >s insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN= >/_m3.log
>=3B Makefile:4437: *** Insufficient number of arguments (2) = >to function `patsubst'. Stop.
>=3B "/Users/mika/cm3/m3-sys/m3cc/src/m3= >makefile"=2C line 508: quake runtime error: unable to copy "./gcc/m3cgc1" t= >o "./cm3cg": errno=3D2
>=3B
>=3B --procedure-- -line- -file---R>>=3B cp_if -- <=3Bbuiltin>=3B
>=3B postcp 508 /Users/mika/cm3/= >m3-sys/m3cc/src/m3makefile
>=3B include_dir 592 /Users/mika/cm3/m3-sys= >/m3cc/src/m3makefile
>=3B 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3m= >ake.args
>=3B
>=3B Fatal Error: package build failed
>=3B [= >lapdog:~/cm3/m3-sys/m3cc] mika%
>=3B
>=3B Any ideas what might = >be causing this?
>=3B
>=3B Mika
>=3B
>=3B
>=3B = >
>=3B Jay Krell writes:
>=3B >=3BCVSROOT: /usr/cvs
>=3B &g= >t=3BChanges by: jkrell at birch. 09/06/15 11:49:14
>=3B >=3B
>=3B = >>=3BAdded files:
>=3B >=3B cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtyp= >e-lex.c gengtype-yacc.c
>=3B >=3B gengtype-yacc.h
>=3B >=3B= >
>=3B >=3BLog message:
>=3B >=3B Add back the lex/yacc/flex/b= >ison outputs that Apple deleted
>=3B >=3B but didn't note in the REM= >OVED file. You only see their
>=3B >=3B absence cause problems if bu= >ilding on a machine without
>=3B >=3B lex/yacc/flex/bison=2C such as= > birch that is missing bison.
>=3B >=3B Apple didn't modify gengtype= >-lex.l and gentype-yacc.y=2C
>=3B >=3B so the unmodified versions of= > these files taken from gcc 4.2.1.
>= > >--_b2ac6846-ec7a-45ce-b56a-ddd2a77b25de_-- From mika at async.caltech.edu Mon Jun 15 21:12:56 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 15 Jun 2009 12:12:56 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 15 Jun 2009 12:11:08 -0000." Message-ID: <200906151912.n5FJCu1t039130@camembert.async.caltech.edu> I already CVS updated but here is what I see now: [lapdog:m3-sys/m3cc/PPC_DARWIN] mika% grep patsubst */Makefile gcc/Makefile:srcdirify = $(patsubst $(srcdir)%,$$(gcc_srcdir)%,$(filter $(srcdir)%,$(1))) \ gcc/Makefile: $(patsubst %,$$(gcc_objdir)/%,$(filter-out $(srcdir)%,$(1))) gcc/Makefile:GTFILES_H = $(subst /,-, $(patsubst $(srcdir)/%,gt-%, $(patsubst %.c,%.h, \ gcc/Makefile:GTFILES_LANG_H = $(patsubst [%], gtype-%.h, $(filter [%], $(GTFILES))) libcpp/Makefile:-include $(patsubst %.o, $(DEPDIR)/%.Po, $(libcpp_a_OBJS) $(makedepend_OBJS)) [lapdog:m3-sys/m3cc/PPC_DARWIN] mika% Jay writes: >--_f3a3f40d-3d61-443a-b5cd-8c10d784957b_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Can you show me: > > > /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/libcpp/Makefile(191) =20 > > and =20 > > /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/gcc/Makefile(4437) =20 > >=20 > > and nearby? And if those don't have patsubst: =20 > >=20 > > cd /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN =20 > > grep -r patsubst * =20 > >=20 > > - Jay >=20 > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu >Date: Mon=2C 15 Jun 2009 11:59:52 +0000 >CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > >If that has no positive effect at all=2C try removing this line from m3make= >file: >=20 > % Save some libtool wrapping layers to speed up esp. on NT? > Configure =3D Configure & " -disable-dependency-tracking" > and be sure to rm -rf the output directory after making the change (or pick= >ing up my other change). >=20 > - Jay >=20 > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu=3B jkrell at elego.de >Date: Mon=2C 15 Jun 2009 11:56:45 +0000 >CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > >Please try with the change to m3makefile I just made. >That might reduce or eliminate the errors. >The line number didn't match up for me. >=20 > - Jay >=20 > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu=3B jkrell at elego.de >Date: Mon=2C 15 Jun 2009 11:26:16 +0000 >CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > >You need a newer make. >I don't remember upgrading mine=2C and I am using 10.4=2C but these are the= > same errors that Olaf reported on 10.3=2C and they were fixed by upgrading= > make for him. >=20 >If there are really only two relevant uses of patsubst=2C maybe we can reco= >de them to be more compatible? >=20 > - Jay > >=20 >> To: jkrell at elego.de=3B jay.krell at cornell.edu >> CC: m3devel at elegosoft.com=3B mika at camembert.async.caltech.edu >> Subject: Re: [M3commit] CVS Update: cm3=20 >> Date: Mon=2C 15 Jun 2009 04:12:39 -0700 >> From: mika at async.caltech.edu >>=20 >> Hi Jay=2C >>=20 >> I've been seeing some new errors attempting to build m3cc on OSX >> 10.4 / ppc. >>=20 >> It seems like it might... possibly... be related to some things you >> have done? Or at least it's happening in the same general area of >> the compiler. >>=20 >> Here we go: >>=20 >> cd ../../gcc/mpfr && : >> make[2]: Nothing to be done for `all-am'. >> make[2]: Nothing to be done for `all'. >> make[2]: Nothing to be done for `all'. >> make[1]: Nothing to be done for `all'. >> cd . && cd libcpp && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOM= >AKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/c= >m3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> cd . && cd libcpp && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOM= >AKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/c= >m3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> Makefile:191: *** Insufficient number of arguments (2) to function `patsu= >bst'. Stop. >> cd . && cd gcc && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config.h m3cg | tee -= >a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> cd . && cd gcc && make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config.h m3cg | tee -= >a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log >> Makefile:4437: *** Insufficient number of arguments (2) to function `pats= >ubst'. Stop. >> "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile"=2C line 508: quake runtime e= >rror: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=3D2 >>=20 >> --procedure-- -line- -file--- >> cp_if -- >> postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile >> include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile >> 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args >>=20 >> Fatal Error: package build failed >> [lapdog:~/cm3/m3-sys/m3cc] mika%=20 >>=20 >> Any ideas what might be causing this? >>=20 >> Mika >>=20 >>=20 >>=20 >> Jay Krell writes: >> >CVSROOT: /usr/cvs >> >Changes by: jkrell at birch. 09/06/15 11:49:14 >> > >> >Added files: >> > cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c=20 >> > gengtype-yacc.h=20 >> > >> >Log message: >> > Add back the lex/yacc/flex/bison outputs that Apple deleted >> > but didn't note in the REMOVED file. You only see their >> > absence cause problems if building on a machine without >> > lex/yacc/flex/bison=2C such as birch that is missing bison. >> > Apple didn't modify gengtype-lex.l and gentype-yacc.y=2C >> > so the unmodified versions of these files taken from gcc 4.2.1. > >--_f3a3f40d-3d61-443a-b5cd-8c10d784957b_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Can you show me:
>
 =3B /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/libcpp/Makefile(191)&nb= >sp=3B
> =3B and =3B
> =3B /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/gcc/Makefile(4437) =3B = >
> =3B
> =3B and nearby? And if those don't have patsubst: =3B
> =3B
> =3B cd /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN =3B
> =3B grep -r patsubst * =3B
> =3B
> =3B- Jay
 =3B
>
>From: jay.krell at cornell.edu
To: mika at async.caltech.edu
Date: Mon=2C 1= >5 Jun 2009 11:59:52 +0000
CC: m3devel at elegosoft.com=3B mika at camembert.as= >ync.caltech.edu
Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> > >If that has no positive effect at all=2C try removing this line from m3make= >file:
 =3B
 =3B =3B =3B % Save some libtool wrapping = >layers to speed up esp. on NT?
 =3B =3B =3B Configure =3D Co= >nfigure &=3B " -disable-dependency-tracking"

and be sure to rm -r= >f the output directory after making the change (or picking up my other chan= >ge).
 =3B
 =3B- Jay
 =3B
>
>From: jay.krell at cornell.edu
To: mika at async.caltech.edu=3B jkrell at elego.d= >e
Date: Mon=2C 15 Jun 2009 11:56:45 +0000
CC: m3devel at elegosoft.com= >=3B mika at camembert.async.caltech.edu
Subject: Re: [M3devel] [M3commit] C= >VS Update: cm3

> >Please try with the change to m3makefile I just made.
That might reduce = >or eliminate =3Bthe errors.
The line number didn't match up for me.<= >BR> =3B
 =3B- Jay
 =3B
>
>From: jay.krell at cornell.edu
To: mika at async.caltech.edu=3B jkrell at elego.d= >e
Date: Mon=2C 15 Jun 2009 11:26:16 +0000
CC: m3devel at elegosoft.com= >=3B mika at camembert.async.caltech.edu
Subject: Re: [M3devel] [M3commit] C= >VS Update: cm3

> >You need a newer make.
I don't remember upgrading mine=2C and I am using= > 10.4=2C but these are the same errors that Olaf reported on 10.3=2C and th= >ey were fixed by upgrading make for him.
 =3B
If there are really= > only two relevant uses of patsubst=2C maybe we can recode them to be more = >compatible?
 =3B
 =3B- Jay

 =3B
>=3B To: jkre= >ll at elego.de=3B jay.krell at cornell.edu
>=3B CC: m3devel at elegosoft.com=3B= > mika at camembert.async.caltech.edu
>=3B Subject: Re: [M3commit] CVS Upd= >ate: cm3
>=3B Date: Mon=2C 15 Jun 2009 04:12:39 -0700
>=3B From:= > mika at async.caltech.edu
>=3B
>=3B Hi Jay=2C
>=3B
>=3B= > I've been seeing some new errors attempting to build m3cc on OSX
>=3B= > 10.4 / ppc.
>=3B
>=3B It seems like it might... possibly... be = >related to some things you
>=3B have done? Or at least it's happening = >in the same general area of
>=3B the compiler.
>=3B
>=3B He= >re we go:
>=3B
>=3B cd ../../gcc/mpfr &=3B&=3B :
>=3B= > make[2]: Nothing to be done for `all-am'.
>=3B make[2]: Nothing to be= > done for `all'.
>=3B make[2]: Nothing to be done for `all'.
>=3B= > make[1]: Nothing to be done for `all'.
>=3B cd . &=3B&=3B cd li= >bcpp &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/cm3/= >m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
>=3B cd . &=3B&=3B cd libc= >pp &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCONF=3D: AUTOMAKE= >=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: libcpp.a | tee -a /Users/mika/cm3/= >m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
>=3B Makefile:191: *** Insuffici= >ent number of arguments (2) to function `patsubst'. Stop.
>=3B cd . &a= >mp=3B&=3B cd gcc &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-O2 -g" AUTOCO= >NF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-modes insn-config= >.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log
&= >gt=3B cd . &=3B&=3B cd gcc &=3B&=3B make CC=3D"gcc" CFLAGS=3D"-= >O2 -g" AUTOCONF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: s-mode= >s insn-config.h m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN= >/_m3.log
>=3B Makefile:4437: *** Insufficient number of arguments (2) = >to function `patsubst'. Stop.
>=3B "/Users/mika/cm3/m3-sys/m3cc/src/m3= >makefile"=2C line 508: quake runtime error: unable to copy "./gcc/m3cgc1" t= >o "./cm3cg": errno=3D2
>=3B
>=3B --procedure-- -line- -file---R>>=3B cp_if -- <=3Bbuiltin>=3B
>=3B postcp 508 /Users/mika/cm3/= >m3-sys/m3cc/src/m3makefile
>=3B include_dir 592 /Users/mika/cm3/m3-sys= >/m3cc/src/m3makefile
>=3B 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3m= >ake.args
>=3B
>=3B Fatal Error: package build failed
>=3B [= >lapdog:~/cm3/m3-sys/m3cc] mika%
>=3B
>=3B Any ideas what might = >be causing this?
>=3B
>=3B Mika
>=3B
>=3B
>=3B = >
>=3B Jay Krell writes:
>=3B >=3BCVSROOT: /usr/cvs
>=3B &g= >t=3BChanges by: jkrell at birch. 09/06/15 11:49:14
>=3B >=3B
>=3B = >>=3BAdded files:
>=3B >=3B cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtyp= >e-lex.c gengtype-yacc.c
>=3B >=3B gengtype-yacc.h
>=3B >=3B= >
>=3B >=3BLog message:
>=3B >=3B Add back the lex/yacc/flex/b= >ison outputs that Apple deleted
>=3B >=3B but didn't note in the REM= >OVED file. You only see their
>=3B >=3B absence cause problems if bu= >ilding on a machine without
>=3B >=3B lex/yacc/flex/bison=2C such as= > birch that is missing bison.
>=3B >=3B Apple didn't modify gengtype= >-lex.l and gentype-yacc.y=2C
>=3B >=3B so the unmodified versions of= > these files taken from gcc 4.2.1.
>= > >--_f3a3f40d-3d61-443a-b5cd-8c10d784957b_-- From jay.krell at cornell.edu Mon Jun 15 21:50:39 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 15 Jun 2009 19:50:39 +0000 Subject: [M3devel] tinderbox FreeBSD diskspace Message-ID: The FreeBSD tinderbox machines continue to run out of diskspace occasionally. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 15 22:47:21 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 15 Jun 2009 13:47:21 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200906151912.n5FJCu1t039130@camembert.async.caltech.edu> References: <200906151912.n5FJCu1t039130@camembert.async.caltech.edu> Message-ID: <1B731B2D-D655-44BC-A4A9-4AB274558270@hotmail.com> Ok so presumably on those lines is 'CATALOGS'? - Jay (phone) On Jun 15, 2009, at 12:12 PM, Mika Nystrom wrote: > I already CVS updated but here is what I see now: > > [lapdog:m3-sys/m3cc/PPC_DARWIN] mika% grep patsubst */Makefile > gcc/Makefile:srcdirify = $(patsubst $(srcdir)%,$$(gcc_srcdir)%,$ > (filter $(srcdir)%,$(1))) \ > gcc/Makefile: $(patsubst %,$$(gcc_objdir)/%,$(filter-out $ > (srcdir)%,$(1))) > gcc/Makefile:GTFILES_H = $(subst /,-, $(patsubst $(srcdir)/%,gt-%, $ > (patsubst %.c,%.h, \ > gcc/Makefile:GTFILES_LANG_H = $(patsubst [%], gtype-%.h, $(filter > [%], $(GTFILES))) > libcpp/Makefile:-include $(patsubst %.o, $(DEPDIR)/%.Po, $ > (libcpp_a_OBJS) $(makedepend_OBJS)) > [lapdog:m3-sys/m3cc/PPC_DARWIN] mika% > > Jay writes: >> --_f3a3f40d-3d61-443a-b5cd-8c10d784957b_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> Can you show me: >> >> >> /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/libcpp/Makefile(191) =20 >> >> and =20 >> >> /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/gcc/Makefile(4437) =20 >> >> =20 >> >> and nearby? And if those don't have patsubst: =20 >> >> =20 >> >> cd /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN =20 >> >> grep -r patsubst * =20 >> >> =20 >> >> - Jay >> =20 >> > From jay.krell at cornell.edu Tue Jun 16 07:02:48 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 15 Jun 2009 22:02:48 -0700 Subject: [M3devel] Solaris vfork? => suggest using fork instead? In-Reply-To: <4CE51F26-EDE3-46F7-9857-248D435669C3@cs.purdue.edu> References: <4CE51F26-EDE3-46F7-9857-248D435669C3@cs.purdue.edu> Message-ID: <83CA3DD2-C85B-4C1F-A14D-DC535C093B8D@hotmail.com> Ps I exaggerated netbsd. It does rename some functions though. - Jay (phone) On Jun 15, 2009, at 6:29 AM, Tony Hosking wrote: > Signals are no longer used for inc gc so probably ok to switch to > fork. > > On 15 Jun 2009, at 03:13, Jay wrote: > >> Is this still true: >> >> >> C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(943):(*** >> vfork - spawn new process in a virtual memory efficient way ***) >> C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(944):(* >> Avoid vfork. The way it is used in ProcessPosix breaks incremental >> GC: >> ? >> >> (*** vfork - spawn new process in a virtual memory efficient way ***) >> (* Avoid vfork. The way it is used in ProcessPosix breaks >> incremental GC: >> RestoreHandlers in child is reflected in parent to break VM >> faulting *) >> <*EXTERNAL "fork1"*> PROCEDURE vfork (): int; >> >> >> If this is true, I broke it. >> >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX does use vfork. >> >> >> Should we just use fork? >> vfork is the same as fork on Cygwin -- both are slow. >> >> There is also reason to use fork on NetBSD. >> NetBSD renames nearly every single symbol at the link level via >> special constructs in its header files. >> As a result, the usual direct extern Modula-3 pragmas are rarely >> correct there. >> That is, for the sake of NetBSD, it is best to wrap every C >> function with our own C functions. >> However, wrapping functions contradicts the Posix constraints on >> vfork -- you are not allowed to return from the function calling >> vfork without calling exec or _exit. Or do no real systems care >> about that? >> >> >> So, to be clear, I suggest changing ProcessPosix.m3 from vfork to >> fork. >> As well as RTPerfTool.m3. >> >> >> I suggest removing vfork from Unix/*.i3, make sure everything >> compiles -- that nobody uses it -- and then restoring it, in case >> there is a later need, to avoid bootstrapping problems if there is. >> >> >> - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Jun 16 09:01:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 16 Jun 2009 00:01:18 -0700 Subject: [M3devel] Strange behavior in recent CM3-compiled code... Message-ID: <200906160701.n5G71I8K061661@camembert.async.caltech.edu> Hello everyone, I'm trying to update to the latest CM3 again, so that I can get my Mac working, and push my project of migrating a largish codebase from PM3 to CM3 a little further. I updated CM3 today from CVS, on both my Mac and on a FreeBSD system, and ... my Scheme interpreter broke. Here's what the code looks like, with annotations: 49 Debug.Out("t.rest = NIL? " & Fmt.Bool(t.rest=NIL)); 50 Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); 51 Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); 52 53 IF t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL THEN 54 Debug.Out("in IF clause..."); 55 56 IF SymEq(t.first, "quote") THEN special := "'" 57 ELSIF SymEq(t.first, "quasiquote") THEN special := "`" 58 ELSIF SymEq(t.first, "unquote") THEN special := "," 59 ELSIF SymEq(t.first, "unquote-splicing") THEN special := ",@" 60 END 61 ELSE 62 Debug.Out("in ELSE clause...") 63 END; all you need to know is that Debug.Out prints out debugging information to the terminal. What I see is... t.rest = NIL? FALSE ISTYPE(t.rest,T)? TRUE Rest(t.rest) = NIL? TRUE in ELSE clause... What gives!? Note this behavior occurs on both the Mac and on FreeBSD4 with a compiler and runtime bootstrapped today from some previous CM3. My old CM3 compiler was timestamped... April 30, I believe, and the code behaved properly under that one. I believe I have also tried it both with and without compiler optimizations. I find it baffling that so much stuff (mentor!) can work if "AND" isn't working right. This is the only if statement in many, many source files that seems to be working wrong. Is it possible I'm missing something?? No I don't think so... here's a more explicit version: Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); Debug.Out("conjunction? " & Fmt.Bool( t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL )); IF t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL THEN ... output is: t.rest # NIL? TRUE ISTYPE(t.rest,T)? TRUE Rest(t.rest) = NIL? TRUE conjunction? FALSE in ELSE clause... TRUE AND TRUE AND TRUE is FALSE?? Note that: VAR q, w, e := TRUE; Debug.Out("conjunction? " & Fmt.Bool( q AND w AND e)); results in TRUE (as it should). Mika From jay.krell at cornell.edu Tue Jun 16 09:11:08 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 07:11:08 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: <200906160701.n5G71I8K061661@camembert.async.caltech.edu> References: <200906160701.n5G71I8K061661@camembert.async.caltech.edu> Message-ID: Kneejerk generic response: I don't know the operator precedence. Can you put in parens? Have you looked at the code? Can you mail us a small self contained repro? Can you test it on birch? (That way -- all your files are there and easily gotten/investigated by others.) Optimization enabled? Works without? I know, I shouldn't even ask this sort of thing without evidence. - Jay > To: m3devel at elegosoft.com > Date: Tue, 16 Jun 2009 00:01:18 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] Strange behavior in recent CM3-compiled code... > > > Hello everyone, > > I'm trying to update to the latest CM3 again, so that I can get my > Mac working, and push my project of migrating a largish codebase > from PM3 to CM3 a little further. > > I updated CM3 today from CVS, on both my Mac and on a FreeBSD system, > and ... my Scheme interpreter broke. Here's what the code looks like, > with annotations: > > 49 Debug.Out("t.rest = NIL? " & Fmt.Bool(t.rest=NIL)); > 50 Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); > 51 Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > 52 > 53 IF t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL THEN > 54 Debug.Out("in IF clause..."); > 55 > 56 IF SymEq(t.first, "quote") THEN special := "'" > 57 ELSIF SymEq(t.first, "quasiquote") THEN special := "`" > 58 ELSIF SymEq(t.first, "unquote") THEN special := "," > 59 ELSIF SymEq(t.first, "unquote-splicing") THEN special := ",@" > 60 END > 61 ELSE > 62 Debug.Out("in ELSE clause...") > 63 END; > > all you need to know is that Debug.Out prints out debugging information > to the terminal. What I see is... > > t.rest = NIL? FALSE > ISTYPE(t.rest,T)? TRUE > Rest(t.rest) = NIL? TRUE > in ELSE clause... > > What gives!? > > Note this behavior occurs on both the Mac and on FreeBSD4 with a > compiler and runtime bootstrapped today from some previous CM3. > My old CM3 compiler was timestamped... April 30, I believe, and the > code behaved properly under that one. > > I believe I have also tried it both with and without compiler > optimizations. > > I find it baffling that so much stuff (mentor!) can work if "AND" isn't > working right. This is the only if statement in many, many source files > that seems to be working wrong. > > Is it possible I'm missing something?? No I don't think so... here's a more > explicit version: > > Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); > Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > Debug.Out("conjunction? " & Fmt.Bool( > t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL )); > IF t.rest # NIL AND ISTYPE(t.rest,T) AND Rest(t.rest) = NIL THEN > ... > > output is: > > t.rest # NIL? TRUE > ISTYPE(t.rest,T)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > > TRUE AND TRUE AND TRUE is FALSE?? > > Note that: > > VAR q, w, e := TRUE; > > Debug.Out("conjunction? " & Fmt.Bool( > q AND w AND e)); > > results in TRUE (as it should). > > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Jun 16 09:50:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 16 Jun 2009 00:50:18 -0700 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." Message-ID: <200906160750.n5G7oIWN063277@camembert.async.caltech.edu> Operator precedence? This isn't C, you know! You can't do NIL AND x in Modula-3. Nevertheless, AND has lower precedence than anything else I'm using here. OR is the lowest. Green Book, section 2.6.2 (p. 49). But to allay your fears, I can report that adding parens around each of the terms doesn't change the behavior, either printing or the IF. My q, w, e was an attempt at isolating the problem but it didn't. I don't know what to start cutting back. I was hoping someone would see it and think "oops, I touched ... the other day and it must have broken this". And yes as I mentioned I tried both with and without optimization. Unfortunately x86 assembly is pretty much gibberish to me. It's part of a rather large software system... I'll see what I can do about getting it up on birch or making a smaller test case... Meanwhile I'll write the code at the end of this message. Mika Jay writes: >--_55f6c801-7d57-4602-a131-dda139b64dfd_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Kneejerk generic response: > >=20 > >I don't know the operator precedence. Can you put in parens? > >Have you looked at the code? > >Can you mail us a small self contained repro? > >Can you test it on birch? > > (That way -- all your files are there and easily gotten/investigated by o= >thers.) > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= >rt of thing without evidence. > >=20 > > - Jay >=20 >> To: m3devel at elegosoft.com >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... >>=20 >>=20 >> Hello everyone=2C >>=20 >> I'm trying to update to the latest CM3 again=2C so that I can get my >> Mac working=2C and push my project of migrating a largish codebase >> from PM3 to CM3 a little further. >>=20 >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C >> and ... my Scheme interpreter broke. Here's what the code looks like=2C >> with annotations: >>=20 >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B >> 52 >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN >> 54 Debug.Out("in IF clause...")=3B >> 55 >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" >> 60 END >> 61 ELSE >> 62 Debug.Out("in ELSE clause...") >> 63 END=3B >>=20 >> all you need to know is that Debug.Out prints out debugging information >> to the terminal. What I see is... >>=20 >> t.rest =3D NIL? FALSE >> ISTYPE(t.rest=2CT)? TRUE >> Rest(t.rest) =3D NIL? TRUE >> in ELSE clause... >>=20 >> What gives!? >>=20 >> Note this behavior occurs on both the Mac and on FreeBSD4 with a >> compiler and runtime bootstrapped today from some previous CM3. >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the >> code behaved properly under that one. >>=20 >> I believe I have also tried it both with and without compiler >> optimizations. >>=20 >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't >> working right. This is the only if statement in many=2C many source files >> that seems to be working wrong. >>=20 >> Is it possible I'm missing something?? No I don't think so... here's a mo= >re >> explicit version: >>=20 >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B >> Debug.Out("conjunction? " & Fmt.Bool( >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN >> ... >>=20 >> output is: >>=20 >> t.rest # NIL? TRUE >> ISTYPE(t.rest=2CT)? TRUE >> Rest(t.rest) =3D NIL? TRUE >> conjunction? FALSE >> in ELSE clause... >>=20 >> TRUE AND TRUE AND TRUE is FALSE?? >>=20 >> Note that:=20 >>=20 >> VAR q=2C w=2C e :=3D TRUE=3B >>=20 >> Debug.Out("conjunction? " & Fmt.Bool( >> q AND w AND e))=3B >>=20 >> results in TRUE (as it should). >>=20 >>=20 >> Mika >>=20 > (* $Id: SchemePair.m3,v 1.8 2009/03/29 07:27:13 mika Exp $ *) MODULE SchemePair; IMPORT Wx; IMPORT SchemeObject, SchemeUtils, SchemeSymbol; FROM Scheme IMPORT E; FROM SchemeUtils IMPORT Error, StringifyT; IMPORT RefSeq; IMPORT Debug, Fmt; PROCEDURE StringifyPair(t : T; quoted : BOOLEAN; buf : Wx.T; seen : RefSeq.T) RAISES { E } = CONST SymEq = SchemeSymbol.SymEq; StringifyB = SchemeUtils.StringifyB; Rest = SchemeUtils.Rest; Second = SchemeUtils.Second; VAR special : TEXT := NIL; BEGIN Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); Debug.Out("ISTYPE(t.rest,T)? " & Fmt.Bool(ISTYPE(t.rest,T))); Debug.Out("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); Debug.Out("conjunction? " & Fmt.Bool( ( t.rest # NIL) AND (ISTYPE(t.rest,T)) AND (Rest(t.rest) = NIL) )); IF (t.rest # NIL) AND ISTYPE(t.rest,T) AND (Rest(t.rest) = NIL) THEN Debug.Out("in IF clause..."); IF SymEq(t.first, "quote") THEN special := "'" ELSIF SymEq(t.first, "quasiquote") THEN special := "`" ELSIF SymEq(t.first, "unquote") THEN special := "," ELSIF SymEq(t.first, "unquote-splicing") THEN special := ",@" END ELSE Debug.Out("in ELSE clause...") END; IF special # NIL THEN Wx.PutText(buf, special); StringifyB(Second(t), quoted, buf, seen) ELSE Wx.PutChar(buf, '('); StringifyB(t.first, quoted, buf, seen); VAR tail := t.rest; BEGIN WHILE tail # NIL AND ISTYPE(tail,T) DO Wx.PutChar(buf, ' '); StringifyB(NARROW(tail,T).first, quoted, buf, seen); tail := NARROW(tail,T).rest END; IF tail # NIL THEN Wx.PutText(buf, " . "); StringifyB(tail, quoted, buf, seen) END; Wx.PutChar(buf, ')') END END END StringifyPair; PROCEDURE Pair(x : SchemeObject.T) : T RAISES { E } = BEGIN IF ISTYPE(x,T) THEN RETURN x (* NIL is OK for Pair! *) ELSE RETURN Pair(Error("expected a pair, got: " & StringifyT(x))) END END Pair; BEGIN END SchemePair. ---------------------------------------------------------------------- .file "SchemePair.mc" .stabs "/big/home/mika/t-cm3/mscheme/FreeBSD4/",100,0,0,.Ltext0 .stabs "SchemePair.mc",100,0,0,.Ltext0 .text .Ltext0: .stabs "gcc2_compiled.",60,0,0,0 .stabs "procedures_have_extra_block.",60,0,0,0 .stabs "MP_CMGwxk_32_L1:T(0,1)=s0AAAAAA:(0,2)=r(0,2);-2147483648;2147483647;,0,32;DobPBR_t:(0,2),0,32;AicXUJ_quoted:(0,2),0,32;BYmXDz_buf:(0,2),0,32;AZx9O5_seen:(0,2),0,32;Scheme.E:(0,2),0,32;;",128,0,0,0 .stabs "MP_DkRnTw_32_L1:T(0,3)=s0DobPBR:(0,2),0,32;Af40ku_x:(0,2),0,32;Scheme.E:(0,2),0,32;;",128,0,0,0 .stabs "MX_BUgnwf_32:T(0,4)=s0DWIlZi:(0,2),0,32;;",128,0,0,0 .stabs "MX_CKMnXU_32:T(0,5)=s0Cgclyt:(0,2),0,32;;",128,0,0,0 .stabs "MX_BtKsLk_32:T(0,6)=s0C7ehAd:(0,2),0,32;;",128,0,0,0 .stabs "SchemePair__StringifyPair:F(0,7)=(0,7)",36,0,17,SchemePair__StringifyPair .stabs "M3_DobPBR_t:p(0,8)=*(0,7)",160,0,74,8 .stabs "M3_AicXUJ_quoted:p(0,9)=@s8;r(0,9);0;255;",160,0,74,12 .stabs "M3_BYmXDz_buf:p(0,8)",160,0,74,16 .stabs "M3_AZx9O5_seen:p(0,8)",160,0,74,20 .globl SchemePair__StringifyPair .type SchemePair__StringifyPair, @function SchemePair__StringifyPair: .stabd 46,0,0 .stabs "../src/SchemePair.m3",132,0,0,.Ltext1 .Ltext1: .stabn 68,0,17,.LM0-.LFBB1 .LM0: .LFBB1: pushl %ebp movl %esp, %ebp pushl %ebx subl $84, %esp .LBB2: .stabn 68,0,24,.LM1-.LFBB1 .LM1: movl $0, -40(%ebp) .stabn 68,0,27,.LM2-.LFBB1 .LM2: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -36(%ebp) movl -36(%ebp), %eax testl %eax, %eax je .L2 movl -36(%ebp), %eax andl $1, %eax testb %al, %al jne .L2 movl -36(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L2 movl -36(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L2: movl -36(%ebp), %eax testl %eax, %eax setne %al movzbl %al, %eax movl %eax, (%esp) call Fmt__Bool movl %eax, -32(%ebp) movl -32(%ebp), %eax movl $L_1+24, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -28(%ebp) movl -28(%ebp), %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,28,.LM3-.LFBB1 .LM3: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -28(%ebp) movl -28(%ebp), %eax testl %eax, %eax je .L3 movl -28(%ebp), %eax andl $1, %eax testb %al, %al jne .L3 movl -28(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L3 movl -28(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L3: movl $1, -24(%ebp) movl -28(%ebp), %eax testl %eax, %eax je .L4 movl -28(%ebp), %eax andl $1, %eax testb %al, %al jne .L5 movl -28(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L4 jmp .L6 .L5: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L4 .L6: movl $0, -24(%ebp) .L4: movl -24(%ebp), %eax movl %eax, (%esp) call Fmt__Bool movl %eax, -32(%ebp) movl -32(%ebp), %eax movl $L_1+52, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -36(%ebp) movl -36(%ebp), %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,29,.LM4-.LFBB1 .LM4: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -36(%ebp) movl -36(%ebp), %eax testl %eax, %eax je .L7 movl -36(%ebp), %eax andl $1, %eax testb %al, %al jne .L7 movl -36(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L7 movl -36(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L7: movl -36(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Rest movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax sete %al movzbl %al, %eax movl %eax, (%esp) call Fmt__Bool movl %eax, -28(%ebp) movl -28(%ebp), %eax movl $L_1+84, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -20(%ebp) movl -20(%ebp), %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,30,.LM5-.LFBB1 .LM5: movl $0, -24(%ebp) movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -20(%ebp) movl -20(%ebp), %eax testl %eax, %eax je .L8 movl -20(%ebp), %eax andl $1, %eax testb %al, %al jne .L8 movl -20(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L8 movl -20(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L8: movl -20(%ebp), %eax testl %eax, %eax je .L9 movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -28(%ebp) movl -28(%ebp), %eax testl %eax, %eax je .L10 movl -28(%ebp), %eax andl $1, %eax testb %al, %al jne .L10 movl -28(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L10 movl -28(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L10: movl -28(%ebp), %eax testl %eax, %eax je .L11 movl -28(%ebp), %eax andl $1, %eax testb %al, %al jne .L12 movl -28(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx jne .L9 .L12: movl MM_SchemePair+176, %eax cmpl $3, %eax jne .L9 .L11: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L13 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L13 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L13 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L13: movl -32(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Rest movl %eax, -36(%ebp) movl -36(%ebp), %eax testl %eax, %eax jne .L9 movl $1, -24(%ebp) .L9: movl -24(%ebp), %eax movl %eax, (%esp) call Fmt__Bool movl %eax, -16(%ebp) movl -16(%ebp), %eax movl $L_1+120, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -12(%ebp) movl -12(%ebp), %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,32,.LM6-.LFBB1 .LM6: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -12(%ebp) movl -12(%ebp), %eax testl %eax, %eax je .L14 movl -12(%ebp), %eax andl $1, %eax testb %al, %al jne .L14 movl -12(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L14 movl -12(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L14: movl -12(%ebp), %eax testl %eax, %eax je .L15 movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -16(%ebp) movl -16(%ebp), %eax testl %eax, %eax je .L16 movl -16(%ebp), %eax andl $1, %eax testb %al, %al jne .L16 movl -16(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L16 movl -16(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L16: movl -16(%ebp), %eax testl %eax, %eax je .L17 movl -16(%ebp), %eax andl $1, %eax testb %al, %al jne .L18 movl -16(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx jne .L15 .L18: movl MM_SchemePair+176, %eax cmpl $3, %eax jne .L15 .L17: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -36(%ebp) movl -36(%ebp), %eax testl %eax, %eax je .L19 movl -36(%ebp), %eax andl $1, %eax testb %al, %al jne .L19 movl -36(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L19 movl -36(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L19: movl -36(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Rest movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax jne .L15 .stabn 68,0,33,.LM7-.LFBB1 .LM7: movl $L_1+148, %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .stabn 68,0,35,.LM8-.LFBB1 .LM8: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L20 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L20 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L20 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L20: movl $L_1+176, %eax movl -32(%ebp), %edx movl %eax, 4(%esp) movl %edx, (%esp) call SchemeSymbol__SymEq movb %al, -5(%ebp) movzbl -5(%ebp), %eax xorl $1, %eax testb %al, %al jne .L21 movl $L_1+196, %eax movl %eax, -40(%ebp) jmp .L29 .L21: .stabn 68,0,36,.LM9-.LFBB1 .LM9: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L23 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L23 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L23 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L23: movl $L_1+212, %eax movl -32(%ebp), %edx movl %eax, 4(%esp) movl %edx, (%esp) call SchemeSymbol__SymEq movb %al, -5(%ebp) movzbl -5(%ebp), %eax xorl $1, %eax testb %al, %al jne .L24 movl $L_1+236, %eax movl %eax, -40(%ebp) jmp .L29 .L24: .stabn 68,0,37,.LM10-.LFBB1 .LM10: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L25 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L25 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L25 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L25: movl $L_1+252, %eax movl -32(%ebp), %edx movl %eax, 4(%esp) movl %edx, (%esp) call SchemeSymbol__SymEq movb %al, -5(%ebp) movzbl -5(%ebp), %eax xorl $1, %eax testb %al, %al jne .L26 movl $L_1+272, %eax movl %eax, -40(%ebp) jmp .L29 .L26: .stabn 68,0,38,.LM11-.LFBB1 .LM11: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L27 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L27 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L27 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L27: movl $L_1+288, %eax movl -32(%ebp), %edx movl %eax, 4(%esp) movl %edx, (%esp) call SchemeSymbol__SymEq movb %al, -5(%ebp) movzbl -5(%ebp), %eax xorl $1, %eax testb %al, %al jne .L29 movl $L_1+320, %eax movl %eax, -40(%ebp) jmp .L29 .L15: .stabn 68,0,41,.LM12-.LFBB1 .LM12: movl $L_1+336, %eax movl $0, 12(%esp) movl $1, 8(%esp) movl $10, 4(%esp) movl %eax, (%esp) call Debug__Out .L29: .stabn 68,0,45,.LM13-.LFBB1 .LM13: movl -40(%ebp), %eax testl %eax, %eax je .L30 .stabn 68,0,46,.LM14-.LFBB1 .LM14: movl -40(%ebp), %eax movl 16(%ebp), %edx movl $0, 20(%esp) movl $0, 16(%esp) movl $0, 12(%esp) movl $0, 8(%esp) movl %eax, 4(%esp) movl %edx, (%esp) call Wx__PutText .stabn 68,0,47,.LM15-.LFBB1 .LM15: movl 8(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Second movl %eax, -32(%ebp) movl 20(%ebp), %edx movl 16(%ebp), %ecx movzbl 12(%ebp), %eax movzbl %al, %eax movl -32(%ebp), %ebx movl %edx, 12(%esp) movl %ecx, 8(%esp) movl %eax, 4(%esp) movl %ebx, (%esp) call SchemeUtils__StringifyB jmp .L47 .L30: .stabn 68,0,49,.LM16-.LFBB1 .LM16: movl 16(%ebp), %eax movl $40, 4(%esp) movl %eax, (%esp) call Wx__PutChar .stabn 68,0,50,.LM17-.LFBB1 .LM17: movl 8(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L32 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L32 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L32 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L32: movl 20(%ebp), %edx movl 16(%ebp), %ecx movzbl 12(%ebp), %eax movzbl %al, %eax movl -32(%ebp), %ebx movl %edx, 12(%esp) movl %ecx, 8(%esp) movl %eax, 4(%esp) movl %ebx, (%esp) call SchemeUtils__StringifyB .LBB3: .stabn 68,0,51,.LM18-.LFBB1 .LM18: movl 8(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L33 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L33 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L33 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L33: movl -32(%ebp), %eax movl %eax, -44(%ebp) jmp .L34 .L35: .stabn 68,0,54,.LM19-.LFBB1 .LM19: movl 16(%ebp), %eax movl $32, 4(%esp) movl %eax, (%esp) call Wx__PutChar .stabn 68,0,55,.LM20-.LFBB1 .LM20: movl -44(%ebp), %eax testl %eax, %eax je .L36 movl -44(%ebp), %eax andl $1, %eax testb %al, %al jne .L37 movl -44(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L36 movl $1765, (%esp) call _m3_fault .L37: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L36 movl $1765, (%esp) call _m3_fault .L36: movl -44(%ebp), %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L38 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L38 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L38 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L38: movl 20(%ebp), %edx movl 16(%ebp), %ecx movzbl 12(%ebp), %eax movzbl %al, %eax movl -32(%ebp), %ebx movl %edx, 12(%esp) movl %ecx, 8(%esp) movl %eax, 4(%esp) movl %ebx, (%esp) call SchemeUtils__StringifyB .stabn 68,0,56,.LM21-.LFBB1 .LM21: movl -44(%ebp), %eax testl %eax, %eax je .L39 movl -44(%ebp), %eax andl $1, %eax testb %al, %al jne .L40 movl -44(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L39 movl $1797, (%esp) call _m3_fault .L40: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L39 movl $1797, (%esp) call _m3_fault .L39: movl -44(%ebp), %eax addl $4, %eax movl (%eax), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax testl %eax, %eax je .L41 movl -32(%ebp), %eax andl $1, %eax testb %al, %al jne .L41 movl -32(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $9, %eax shrl $31, %eax xorl $1, %eax testb %al, %al jne .L41 movl -32(%ebp), %eax movl %eax, (%esp) call RTHooks__CheckLoadTracedRef .L41: movl -32(%ebp), %eax movl %eax, -44(%ebp) .L34: .stabn 68,0,53,.LM22-.LFBB1 .LM22: movl -44(%ebp), %eax testl %eax, %eax je .L45 movl -44(%ebp), %eax testl %eax, %eax je .L35 movl -44(%ebp), %eax andl $1, %eax testb %al, %al jne .L43 movl -44(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L35 .L43: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L35 .L45: .stabn 68,0,58,.LM23-.LFBB1 .LM23: movl -44(%ebp), %eax testl %eax, %eax je .L46 .stabn 68,0,59,.LM24-.LFBB1 .LM24: movl $L_1+368, %eax movl 16(%ebp), %edx movl $0, 20(%esp) movl $0, 16(%esp) movl $0, 12(%esp) movl $0, 8(%esp) movl %eax, 4(%esp) movl %edx, (%esp) call Wx__PutText .stabn 68,0,60,.LM25-.LFBB1 .LM25: movl 20(%ebp), %edx movl 16(%ebp), %ecx movzbl 12(%ebp), %eax movzbl %al, %eax movl -44(%ebp), %ebx movl %edx, 12(%esp) movl %ecx, 8(%esp) movl %eax, 4(%esp) movl %ebx, (%esp) call SchemeUtils__StringifyB .L46: .stabn 68,0,62,.LM26-.LFBB1 .LM26: movl 16(%ebp), %eax movl $41, 4(%esp) movl %eax, (%esp) call Wx__PutChar .L47: .LBE3: .LBE2: .stabn 68,0,65,.LM27-.LFBB1 .LM27: addl $84, %esp popl %ebx popl %ebp ret .size SchemePair__StringifyPair, .-SchemePair__StringifyPair .stabn 192,0,0,.LFBB1-.LFBB1 .stabs "M3_Bd56fi_special:(0,8)",128,0,74,-40 .stabn 192,0,0,.LBB2-.LFBB1 .stabs "M3_Af40ku_tail:(0,8)",128,0,51,-44 .stabn 192,0,0,.LBB3-.LFBB1 .stabn 224,0,0,.LBE3-.LFBB1 .stabn 224,0,0,.LBE2-.LFBB1 .stabn 224,0,0,.Lscope1-.LFBB1 .Lscope1: .stabs "",36,0,0,.Lscope1-.LFBB1 .stabd 78,0,0 .stabs "SchemePair__Pair:F(0,8)",36,0,67,SchemePair__Pair .stabs "M3_Af40ku_x:p(0,8)",160,0,74,8 .globl SchemePair__Pair .type SchemePair__Pair, @function SchemePair__Pair: .stabd 46,0,0 .stabn 68,0,67,.LM28-.LFBB2 .LM28: .LFBB2: pushl %ebp movl %esp, %ebp subl $56, %esp .LBB4: .stabn 68,0,69,.LM29-.LFBB2 .LM29: movl 8(%ebp), %eax testl %eax, %eax je .L49 movl 8(%ebp), %eax andl $1, %eax testb %al, %al jne .L50 movl 8(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx jne .L51 .L50: movl MM_SchemePair+176, %eax cmpl $3, %eax jne .L51 .L49: movl 8(%ebp), %eax testl %eax, %eax je .L52 movl 8(%ebp), %eax andl $1, %eax testb %al, %al jne .L53 movl 8(%ebp), %eax subl $4, %eax movl (%eax), %eax sall $11, %eax shrl $12, %eax movl %eax, %edx movl MM_SchemePair+176, %eax cmpl %eax, %edx je .L52 movl $2213, (%esp) call _m3_fault .L53: movl MM_SchemePair+176, %eax cmpl $3, %eax je .L52 movl $2213, (%esp) call _m3_fault .L52: movl 8(%ebp), %eax movl %eax, -36(%ebp) jmp .L48 .L51: .stabn 68,0,70,.LM30-.LFBB2 .LM30: movl 8(%ebp), %eax movl %eax, (%esp) call SchemeUtils__StringifyT movl %eax, -20(%ebp) movl -20(%ebp), %eax movl $L_1+384, %edx movl %eax, 4(%esp) movl %edx, (%esp) call RTHooks__Concat movl %eax, -16(%ebp) movl -16(%ebp), %eax movl %eax, (%esp) call SchemeUtils__Error movl %eax, -12(%ebp) movl -12(%ebp), %eax movl %eax, (%esp) call SchemePair__Pair movl %eax, -8(%ebp) movl -8(%ebp), %eax movl %eax, -36(%ebp) .L48: .LBE4: movl -36(%ebp), %eax leave ret .size SchemePair__Pair, .-SchemePair__Pair .stabn 192,0,0,.LFBB2-.LFBB2 .stabs "M3_DobPBR__result:(0,8)",128,0,74,-4 .stabn 192,0,0,.LBB4-.LFBB2 .stabn 224,0,0,.LBE4-.LFBB2 .stabn 224,0,0,.Lscope2-.LFBB2 .Lscope2: .stabs "",36,0,0,.Lscope2-.LFBB2 .stabd 78,0,0 .stabs "SchemePair_M3:F(0,8)",36,0,74,SchemePair_M3 .stabs "M3_AcxOUs_mode:p(0,2)",160,0,74,8 .globl SchemePair_M3 .type SchemePair_M3, @function SchemePair_M3: .stabd 46,0,0 .stabn 68,0,74,.LM31-.LFBB3 .LM31: .LFBB3: pushl %ebp movl %esp, %ebp subl $4, %esp .LBB5: .stabn 68,0,74,.LM32-.LFBB3 .LM32: movl 8(%ebp), %eax movl $MM_SchemePair, %eax .LBE5: leave ret .size SchemePair_M3, .-SchemePair_M3 .stabn 192,0,0,.LFBB3-.LFBB3 .stabn 192,0,0,.LBB5-.LFBB3 .stabn 224,0,0,.LBE5-.LFBB3 .stabn 224,0,0,.Lscope3-.LFBB3 .Lscope3: .stabs "",36,0,0,.Lscope3-.LFBB3 .stabd 78,0,0 .stabs "MR_zzzzzz_4032:T(0,10)=s0;",128,0,0,0 .stabs "MR_zzzzzz_1440:T(0,11)=s0;",128,0,0,0 .stabs "Mi_zzzzzz_SchemePair:T(0,12)=s0SchemePair:(0,2),0,32;;",128,0,0,0 .stabs "_m3_fault:f(0,7)",36,0,0,_m3_fault .stabs "M3_AcxOUs_arg:p(0,13)=r(0,13);0;037777777777;",160,0,55,8 .type _m3_fault, @function _m3_fault: .stabd 46,0,0 .stabn 68,0,0,.LM33-.LFBB4 .LM33: .LFBB4: pushl %ebp movl %esp, %ebp subl $8, %esp movl 8(%ebp), %eax movl %eax, 4(%esp) movl $MM_SchemePair, (%esp) call RTHooks__ReportFault leave ret .size _m3_fault, .-_m3_fault .stabn 192,0,0,.LFBB4-.LFBB4 .stabn 224,0,0,.Lscope4-.LFBB4 .Lscope4: .stabs "",36,0,0,.Lscope4-.LFBB4 .stabd 78,0,0 .data .align 32 .type L_1, @object .size L_1, 504 L_1: .long RTHooks__TextLitInfo .long RTHooks__TextLitGetChar .long RTHooks__TextLitGetWideChar .long RTHooks__TextLitGetChars .long RTHooks__TextLitGetWideChars .long 2 .long L_1 .long 14 .ascii "t.rest # NIL? " .zero 2 .long 2 .long L_1 .long 18 .ascii "ISTYPE(t.rest,T)? " .zero 2 .long 2 .long L_1 .long 20 .ascii "Rest(t.rest) = NIL? " .zero 4 .long 2 .long L_1 .long 13 .ascii "conjunction? " .zero 3 .long 2 .long L_1 .long 15 .ascii "in IF clause..." .zero 1 .long 2 .long L_1 .long 5 .ascii "quote" .zero 3 .long 2 .long L_1 .long 1 .ascii "'" .zero 3 .long 2 .long L_1 .long 10 .ascii "quasiquote" .zero 2 .long 2 .long L_1 .long 1 .ascii "`" .zero 3 .long 2 .long L_1 .long 7 .ascii "unquote" .zero 1 .long 2 .long L_1 .long 1 .ascii "," .zero 3 .long 2 .long L_1 .long 16 .ascii "unquote-splicing" .zero 4 .long 2 .long L_1 .long 2 .ascii ",@" .zero 2 .long 2 .long L_1 .long 17 .ascii "in ELSE clause..." .zero 3 .long 2 .long L_1 .long 3 .ascii " . " .zero 1 .long 2 .long L_1 .long 22 .ascii "expected a pair, got: " .zero 2 .ascii "SchemePair_M3" .zero 1 .ascii "Pair" .zero 1 .ascii "StringifyPair" .zero 4 .long SchemePair_M3 .long L_1+416 .long SchemePair__Pair .long L_1+430 .long SchemePair__StringifyPair .long L_1+435 .zero 4 .ascii "../src/SchemePair.m3" .zero 4 .align 32 .type MM_SchemePair, @object .size MM_SchemePair, 180 MM_SchemePair: .long L_1+480 .zero 4 .long MM_SchemePair+172 .zero 8 .long L_1+452 .zero 12 .long MM_SchemePair+52 .zero 4 .long SchemePair_M3 .long 3 .zero 4 .long SchemePair_I3 .long MM_SchemePair+64 .zero 4 .long Fmt_I3 .long MM_SchemePair+76 .zero 4 .long Debug_I3 .long MM_SchemePair+88 .zero 4 .long RefSeq_I3 .long MM_SchemePair+100 .zero 4 .long Scheme_I3 .long MM_SchemePair+112 .zero 4 .long SchemeSymbol_I3 .long MM_SchemePair+124 .zero 4 .long SchemeUtils_I3 .long MM_SchemePair+136 .zero 4 .long SchemeObject_I3 .long MM_SchemePair+148 .zero 4 .long Wx_I3 .long MM_SchemePair+160 .zero 4 .long RTHooks_I3 .zero 8 .long -949022765 .stabs "L_1:S(0,14)=s504;",38,0,9,L_1 .stabs "MM_SchemePair:S(0,15)=s180;",38,0,9,MM_SchemePair .text .stabs "",100,0,0,.Letext0 .Letext0: .ident "GCC: (GNU) 4.3.0" From mika at async.caltech.edu Tue Jun 16 09:59:10 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 16 Jun 2009 00:59:10 -0700 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." Message-ID: <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> This small example exhibits it! MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = BRANDED "Pair" REF RECORD first, rest : REFANY; END; PROCEDURE Rest(p : Pair) : REFANY = BEGIN IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END END Rest; VAR t := NEW(Pair, first := "first", rest := NEW(Pair, first := "second", rest := NIL)); BEGIN PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); PutLn("conjunction? " & Fmt.Bool( (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Output: (133)rover:~/testcm3/src>m3build -O --- building in ../FreeBSD4 --- m3build: missing ../src/m3overrides new source -> compiling ../src/Main.m3 -> linking prog (134)rover:~/testcm3/src>../FreeBSD4/prog t.rest # NIL? TRUE ISTYPE(t.rest,Pair)? TRUE Rest(t.rest) = NIL? TRUE conjunction? TRUE in IF clause... (135)rover:~/testcm3/src>cm3 -clean --- cleaning ../FreeBSD4 --- (136)rover:~/testcm3/src>cm3 --- building in ../FreeBSD4 --- new source -> compiling Main.m3 -> linking prog (137)rover:~/testcm3/src>../FreeBSD4/prog t.rest # NIL? TRUE ISTYPE(t.rest,Pair)? TRUE Rest(t.rest) = NIL? TRUE conjunction? FALSE in ELSE clause... (138)rover:~/testcm3/src> Jay writes: >--_55f6c801-7d57-4602-a131-dda139b64dfd_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Kneejerk generic response: > >=20 > >I don't know the operator precedence. Can you put in parens? > >Have you looked at the code? > >Can you mail us a small self contained repro? > >Can you test it on birch? > > (That way -- all your files are there and easily gotten/investigated by o= >thers.) > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= >rt of thing without evidence. > >=20 > > - Jay >=20 >> To: m3devel at elegosoft.com >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... >>=20 >>=20 >> Hello everyone=2C >>=20 >> I'm trying to update to the latest CM3 again=2C so that I can get my >> Mac working=2C and push my project of migrating a largish codebase >> from PM3 to CM3 a little further. >>=20 >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C >> and ... my Scheme interpreter broke. Here's what the code looks like=2C >> with annotations: >>=20 >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B >> 52 >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN >> 54 Debug.Out("in IF clause...")=3B >> 55 >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" >> 60 END >> 61 ELSE >> 62 Debug.Out("in ELSE clause...") >> 63 END=3B >>=20 >> all you need to know is that Debug.Out prints out debugging information >> to the terminal. What I see is... >>=20 >> t.rest =3D NIL? FALSE >> ISTYPE(t.rest=2CT)? TRUE >> Rest(t.rest) =3D NIL? TRUE >> in ELSE clause... >>=20 >> What gives!? >>=20 >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > compiler and runtime bootstrapped today from some previous CM3. >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the >> code behaved properly under that one. >>=20 >> I believe I have also tried it both with and without compiler >> optimizations. >>=20 >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't >> working right. This is the only if statement in many=2C many source files >> that seems to be working wrong. >>=20 >> Is it possible I'm missing something?? No I don't think so... here's a mo= >re >> explicit version: >>=20 >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B >> Debug.Out("conjunction? " & Fmt.Bool( >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN >> ... >>=20 >> output is: >>=20 >> t.rest # NIL? TRUE >> ISTYPE(t.rest=2CT)? TRUE >> Rest(t.rest) =3D NIL? TRUE >> conjunction? FALSE >> in ELSE clause... >>=20 >> TRUE AND TRUE AND TRUE is FALSE?? >>=20 >> Note that:=20 >>=20 >> VAR q=2C w=2C e :=3D TRUE=3B >>=20 >> Debug.Out("conjunction? " & Fmt.Bool( >> q AND w AND e))=3B >>=20 >> results in TRUE (as it should). >>=20 >>=20 >> Mika >>=20 > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Kneejerk generic response:
> =3B
>I don't know the operator precedence. Can you put in parens?
>Have you looked at the code?
>Can you mail us a small self contained repro?
>Can you test it on birch?
> =3B (That way -- all your files are there and easily gotten/investigat= >ed by others.)
>Optimization enabled? Works without? I know=2C I shouldn't even ask this so= >rt of thing without evidence.
> =3B
> =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= >eed to know is that Debug.Out prints out debugging information
>=3B to= > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= >ieve I have also tried it both with and without compiler
>=3B optimiza= >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > can work if "AND" isn't
>=3B working right. This is the only if state= >ment in many=2C many source files
>=3B that seems to be working wrong.= >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= >ka
>=3B
>= > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- From jay.krell at cornell.edu Tue Jun 16 10:44:21 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 08:44:21 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: Cool. Here is a smaller repro, on birch AMD64_LINUX. The problem is not the AND, the problem is the IF. MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = REF RECORD rest : REFANY; END; VAR t := NEW(Pair, rest := NEW(Pair, rest := NIL)); BEGIN PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); IF ISTYPE(t.rest,Pair) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Tony this is presumably your type tagging changes?? The problem in the code I think is the compare to the number 3. .L13: movq 312+MM_Main(%rip), %rax cmpq $3, %rax <==== jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT What is that for? It comes right from the IL: (118) set_source_line source line 17 (119) import_procedure procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd (120) declare_param param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 alignment 0x40 in _memory 0x0 up_level 0x0 mode 0x11 (DImode) (121) set_runtime_proc (122) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (123) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (124) load_nil (125) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (126) if_eq (127) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (128) loophole (129) load_integer integer 0x1 (130) and (131) if_true (132) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (133) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (134) extract_mn (135) if_false (136) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (137) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (138) pop_param pop param type 0xb (139) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (140) set_label (141) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (142) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (143) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (144) load_nil (145) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (146) if_eq (147) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (148) loophole (149) load_integer integer 0x1 (150) and (151) if_true (152) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (153) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (154) extract_mn (155) if_false (156) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (157) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (158) pop_param pop param type 0xb (159) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (160) set_label (161) load_integer integer 0x1 (162) declare_temp temp var type 0x7 size 0x40 alignment 0x40 (163) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (164) load_nil (165) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (166) if_eq (167) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (168) loophole (169) load_integer integer 0x1 (170) and (171) if_true (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq (177) jump (178) set_label (179) load_integer integer 0x3 (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq (182) set_label (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 alignment 0x8 in_mem ory 0x0 up_level 0x0 mode 0xe () (188) start_call_direct start call procedure Fmt__Bool, level 0x0, type 0xb (189) load m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 (190) pop_param pop param type 0x0 (191) call_direct call procedure Fmt__Bool, type 0xb (192) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (193) start_call_direct start call procedure RTHooks__Concat, level 0x0, type 0xb (194) load_address load address (L_1) offset 0x280 (195) pop_param pop param type 0xb (196) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (197) pop_param pop param type 0xb (198) call_direct call procedure RTHooks__Concat, type 0xb (199) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (200) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (201) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (202) pop_param pop param type 0xb (203) call_direct call procedure Main__PutLn, type 0xd (204) set_source_line source line 18 (205) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (206) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (207) load_nil (208) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (209) if_eq (210) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (211) loophole (212) load_integer integer 0x1 (213) and (214) if_true (215) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (216) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (217) extract_mn (218) if_false (219) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (220) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (221) pop_param pop param type 0xb (222) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (223) set_label (224) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (225) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (226) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (227) load_nil (228) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (229) if_eq (230) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (231) loophole (232) load_integer integer 0x1 (233) and (234) if_true (235) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (236) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (237) extract_mn (238) if_false (239) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (240) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (241) pop_param pop param type 0xb (242) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (243) set_label (244) load_nil (245) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (246) if_eq (247) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (248) loophole (249) load_integer integer 0x1 (250) and (251) if_true (252) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (253) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (254) extract_mn (255) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (256) if_ne (257) set_label (258) load_integer integer 0x3 <===== (259) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (260) if_ne (261) set_label (262) set_source_line source line 19 (263) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (264) load_address load address (L_1) offset 0x400 (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump (268) set_label (269) set_source_line source line 21 (270) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (271) load_address load address (L_1) offset 0x540 (272) pop_param pop param type 0xb (273) call_direct call procedure Main__PutLn, type 0xd (274) set_label (275) set_label (276) load_address load address (MM_Main) offset 0x0 (277) exit_proc (278) free_temp (279) free_temp (280) free_temp (281) free_temp (282) free_temp (283) end_procedure procedure Main_M3 (284) comment comment: `global constant type descriptor' (285) declare_record record id 0xffffffff, fields 0x0, size 0x940 (286) comment comment: `global data type descriptor' I'll dig a bit more. - Jay > To: jay.krell at cornell.edu > Date: Tue, 16 Jun 2009 00:59:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > This small example exhibits it! > > MODULE Main; > IMPORT IO, Fmt; > > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > > TYPE > Pair = BRANDED "Pair" REF RECORD > first, rest : REFANY; > END; > > PROCEDURE Rest(p : Pair) : REFANY = > BEGIN > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > END Rest; > > VAR > t := NEW(Pair, first := "first", > rest := NEW(Pair, first := "second", > rest := NIL)); > > BEGIN > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > PutLn("conjunction? " & Fmt.Bool( > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Output: > > (133)rover:~/testcm3/src>m3build -O > --- building in ../FreeBSD4 --- > m3build: missing ../src/m3overrides > new source -> compiling ../src/Main.m3 > -> linking prog > (134)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? TRUE > in IF clause... > (135)rover:~/testcm3/src>cm3 -clean > --- cleaning ../FreeBSD4 --- > > (136)rover:~/testcm3/src>cm3 > --- building in ../FreeBSD4 --- > > new source -> compiling Main.m3 > -> linking prog > (137)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > (138)rover:~/testcm3/src> > > Jay writes: > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Kneejerk generic response: > > > >=20 > > > >I don't know the operator precedence. Can you put in parens? > > > >Have you looked at the code? > > > >Can you mail us a small self contained repro? > > > >Can you test it on birch? > > > > (That way -- all your files are there and easily gotten/investigated by o= > >thers.) > > > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence. > > > >=20 > > > > - Jay > >=20 > >> To: m3devel at elegosoft.com > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... > >>=20 > >>=20 > >> Hello everyone=2C > >>=20 > >> I'm trying to update to the latest CM3 again=2C so that I can get my > >> Mac working=2C and push my project of migrating a largish codebase > >> from PM3 to CM3 a little further. > >>=20 > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C > >> and ... my Scheme interpreter broke. Here's what the code looks like=2C > >> with annotations: > >>=20 > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> 52 > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> 54 Debug.Out("in IF clause...")=3B > >> 55 > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" > >> 60 END > >> 61 ELSE > >> 62 Debug.Out("in ELSE clause...") > >> 63 END=3B > >>=20 > >> all you need to know is that Debug.Out prints out debugging information > >> to the terminal. What I see is... > >>=20 > >> t.rest =3D NIL? FALSE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> in ELSE clause... > >>=20 > >> What gives!? > >>=20 > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > compiler and runtime bootstrapped today from some previous CM3. > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the > >> code behaved properly under that one. > >>=20 > >> I believe I have also tried it both with and without compiler > >> optimizations. > >>=20 > >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't > >> working right. This is the only if statement in many=2C many source files > >> that seems to be working wrong. > >>=20 > >> Is it possible I'm missing something?? No I don't think so... here's a mo= > >re > >> explicit version: > >>=20 > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> Debug.Out("conjunction? " & Fmt.Bool( > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> ... > >>=20 > >> output is: > >>=20 > >> t.rest # NIL? TRUE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> conjunction? FALSE > >> in ELSE clause... > >>=20 > >> TRUE AND TRUE AND TRUE is FALSE?? > >>=20 > >> Note that:=20 > >>=20 > >> VAR q=2C w=2C e :=3D TRUE=3B > >>=20 > >> Debug.Out("conjunction? " & Fmt.Bool( > >> q AND w AND e))=3B > >>=20 > >> results in TRUE (as it should). > >>=20 > >>=20 > >> Mika > >>=20 > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Kneejerk generic response:
> > =3B
> >I don't know the operator precedence. Can you put in parens?
> >Have you looked at the code?
> >Can you mail us a small self contained repro?
> >Can you test it on birch?
> > =3B (That way -- all your files are there and easily gotten/investigat= > >ed by others.)
> >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence.
> > =3B
> > =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= > >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= > >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= > >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= > >eed to know is that Debug.Out prints out debugging information
>=3B to= > > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= > >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= > >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= > >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= > >ieve I have also tried it both with and without compiler
>=3B optimiza= > >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > > can work if "AND" isn't
>=3B working right. This is the only if state= > >ment in many=2C many source files
>=3B that seems to be working wrong.= > >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= > >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= > >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= > >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B >R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= > >ka
>=3B
> >= > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jun 16 10:50:02 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 08:50:02 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: Well, the number 3 is REFANY_typecode. I need to compare the if code to the printing code though.. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... Date: Tue, 16 Jun 2009 08:44:21 +0000 Cool. Here is a smaller repro, on birch AMD64_LINUX. The problem is not the AND, the problem is the IF. MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = REF RECORD rest : REFANY; END; VAR t := NEW(Pair, rest := NEW(Pair, rest := NIL)); BEGIN PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); IF ISTYPE(t.rest,Pair) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Tony this is presumably your type tagging changes?? The problem in the code I think is the compare to the number 3. .L13: movq 312+MM_Main(%rip), %rax cmpq $3, %rax <==== jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT What is that for? It comes right from the IL: (118) set_source_line source line 17 (119) import_procedure procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd (120) declare_param param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 alignment 0x40 in _memory 0x0 up_level 0x0 mode 0x11 (DImode) (121) set_runtime_proc (122) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (123) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (124) load_nil (125) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (126) if_eq (127) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (128) loophole (129) load_integer integer 0x1 (130) and (131) if_true (132) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (133) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (134) extract_mn (135) if_false (136) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (137) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (138) pop_param pop param type 0xb (139) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (140) set_label (141) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (142) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (143) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (144) load_nil (145) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (146) if_eq (147) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (148) loophole (149) load_integer integer 0x1 (150) and (151) if_true (152) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (153) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (154) extract_mn (155) if_false (156) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (157) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (158) pop_param pop param type 0xb (159) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (160) set_label (161) load_integer integer 0x1 (162) declare_temp temp var type 0x7 size 0x40 alignment 0x40 (163) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (164) load_nil (165) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (166) if_eq (167) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (168) loophole (169) load_integer integer 0x1 (170) and (171) if_true (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq (177) jump (178) set_label (179) load_integer integer 0x3 (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq (182) set_label (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 alignment 0x8 in_mem ory 0x0 up_level 0x0 mode 0xe () (188) start_call_direct start call procedure Fmt__Bool, level 0x0, type 0xb (189) load m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 (190) pop_param pop param type 0x0 (191) call_direct call procedure Fmt__Bool, type 0xb (192) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (193) start_call_direct start call procedure RTHooks__Concat, level 0x0, type 0xb (194) load_address load address (L_1) offset 0x280 (195) pop_param pop param type 0xb (196) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (197) pop_param pop param type 0xb (198) call_direct call procedure RTHooks__Concat, type 0xb (199) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (200) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (201) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (202) pop_param pop param type 0xb (203) call_direct call procedure Main__PutLn, type 0xd (204) set_source_line source line 18 (205) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (206) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (207) load_nil (208) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (209) if_eq (210) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (211) loophole (212) load_integer integer 0x1 (213) and (214) if_true (215) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (216) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (217) extract_mn (218) if_false (219) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (220) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (221) pop_param pop param type 0xb (222) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (223) set_label (224) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (225) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (226) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (227) load_nil (228) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (229) if_eq (230) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (231) loophole (232) load_integer integer 0x1 (233) and (234) if_true (235) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (236) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (237) extract_mn (238) if_false (239) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (240) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (241) pop_param pop param type 0xb (242) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (243) set_label (244) load_nil (245) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (246) if_eq (247) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (248) loophole (249) load_integer integer 0x1 (250) and (251) if_true (252) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (253) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (254) extract_mn (255) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (256) if_ne (257) set_label (258) load_integer integer 0x3 <===== (259) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (260) if_ne (261) set_label (262) set_source_line source line 19 (263) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (264) load_address load address (L_1) offset 0x400 (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump (268) set_label (269) set_source_line source line 21 (270) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (271) load_address load address (L_1) offset 0x540 (272) pop_param pop param type 0xb (273) call_direct call procedure Main__PutLn, type 0xd (274) set_label (275) set_label (276) load_address load address (MM_Main) offset 0x0 (277) exit_proc (278) free_temp (279) free_temp (280) free_temp (281) free_temp (282) free_temp (283) end_procedure procedure Main_M3 (284) comment comment: `global constant type descriptor' (285) declare_record record id 0xffffffff, fields 0x0, size 0x940 (286) comment comment: `global data type descriptor' I'll dig a bit more. - Jay > To: jay.krell at cornell.edu > Date: Tue, 16 Jun 2009 00:59:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > This small example exhibits it! > > MODULE Main; > IMPORT IO, Fmt; > > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > > TYPE > Pair = BRANDED "Pair" REF RECORD > first, rest : REFANY; > END; > > PROCEDURE Rest(p : Pair) : REFANY = > BEGIN > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > END Rest; > > VAR > t := NEW(Pair, first := "first", > rest := NEW(Pair, first := "second", > rest := NIL)); > > BEGIN > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > PutLn("conjunction? " & Fmt.Bool( > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Output: > > (133)rover:~/testcm3/src>m3build -O > --- building in ../FreeBSD4 --- > m3build: missing ../src/m3overrides > new source -> compiling ../src/Main.m3 > -> linking prog > (134)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? TRUE > in IF clause... > (135)rover:~/testcm3/src>cm3 -clean > --- cleaning ../FreeBSD4 --- > > (136)rover:~/testcm3/src>cm3 > --- building in ../FreeBSD4 --- > > new source -> compiling Main.m3 > -> linking prog > (137)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > (138)rover:~/testcm3/src> > > Jay writes: > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Kneejerk generic response: > > > >=20 > > > >I don't know the operator precedence. Can you put in parens? > > > >Have you looked at the code? > > > >Can you mail us a small self contained repro? > > > >Can you test it on birch? > > > > (That way -- all your files are there and easily gotten/investigated by o= > >thers.) > > > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence. > > > >=20 > > > > - Jay > >=20 > >> To: m3devel at elegosoft.com > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... > >>=20 > >>=20 > >> Hello everyone=2C > >>=20 > >> I'm trying to update to the latest CM3 again=2C so that I can get my > >> Mac working=2C and push my project of migrating a largish codebase > >> from PM3 to CM3 a little further. > >>=20 > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C > >> and ... my Scheme interpreter broke. Here's what the code looks like=2C > >> with annotations: > >>=20 > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> 52 > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> 54 Debug.Out("in IF clause...")=3B > >> 55 > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" > >> 60 END > >> 61 ELSE > >> 62 Debug.Out("in ELSE clause...") > >> 63 END=3B > >>=20 > >> all you need to know is that Debug.Out prints out debugging information > >> to the terminal. What I see is... > >>=20 > >> t.rest =3D NIL? FALSE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> in ELSE clause... > >>=20 > >> What gives!? > >>=20 > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > compiler and runtime bootstrapped today from some previous CM3. > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the > >> code behaved properly under that one. > >>=20 > >> I believe I have also tried it both with and without compiler > >> optimizations. > >>=20 > >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't > >> working right. This is the only if statement in many=2C many source files > >> that seems to be working wrong. > >>=20 > >> Is it possible I'm missing something?? No I don't think so... here's a mo= > >re > >> explicit version: > >>=20 > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> Debug.Out("conjunction? " & Fmt.Bool( > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> ... > >>=20 > >> output is: > >>=20 > >> t.rest # NIL? TRUE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> conjunction? FALSE > >> in ELSE clause... > >>=20 > >> TRUE AND TRUE AND TRUE is FALSE?? > >>=20 > >> Note that:=20 > >>=20 > >> VAR q=2C w=2C e :=3D TRUE=3B > >>=20 > >> Debug.Out("conjunction? " & Fmt.Bool( > >> q AND w AND e))=3B > >>=20 > >> results in TRUE (as it should). > >>=20 > >>=20 > >> Mika > >>=20 > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Kneejerk generic response:
> > =3B
> >I don't know the operator precedence. Can you put in parens?
> >Have you looked at the code?
> >Can you mail us a small self contained repro?
> >Can you test it on birch?
> > =3B (That way -- all your files are there and easily gotten/investigat= > >ed by others.)
> >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence.
> > =3B
> > =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= > >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= > >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= > >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= > >eed to know is that Debug.Out prints out debugging information
>=3B to= > > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= > >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= > >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= > >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= > >ieve I have also tried it both with and without compiler
>=3B optimiza= > >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > > can work if "AND" isn't
>=3B working right. This is the only if state= > >ment in many=2C many source files
>=3B that seems to be working wrong.= > >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= > >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= > >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= > >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B >R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= > >ka
>=3B
> >= > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jun 16 11:16:39 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 09:16:39 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: I haven't figured it out, but: Here is the code for the Fmt.Bool: .L6: ; assume the parameter to Fmt.Bool is TRUE, by ; storing 1 in the parameter place movq $1, 16(%rsp) ; do a bunch of stuff, no need to understand.. movq 32(%rsp), %rax testq %rax, %rax je .L7 movq 32(%rsp), %rax testb $1, %al jne .L8 movq 32(%rsp), %rax movq 312+MM_Main(%rip), %rdx movq -8(%rax), %rax salq $43, %rax shrq $44, %rax ; at this point, between $rdx and $rax, one is ; typecode of the object, one is the typecode of the type ; they compare equal cmpq %rdx, %rax ; This is not taken. jne .L9 ; This is taken. jmp .L7 .L8: ; This does not run. movq 312+MM_Main(%rip), %rax cmpq $3, %rax je .L7 .L9: ; Had the expression resolved to FALSE, this would be ; where FALSE is passed to Fmt.Bool movq $0, 16(%rsp) .L7: movq 16(%rsp), %rdi call Fmt__Bool at PLT And here is the code for the IF: .L11: ; just gloss over this part.. movq 40(%rsp), %rax testq %rax, %rax je .L12 movq 40(%rsp), %rax testb $1, %al jne .L13 movq 40(%rsp), %rax movq 312+MM_Main(%rip), %rdx movq -8(%rax), %rax salq $43, %rax shrq $44, %rax ; again at this point, we have the typecodes, and they compare equal cmpq %rdx, %rax ; This is not taken. jne .L14 .L13: ; At this point things have gone wrong. ; The Fmt.Bool path did not compare the typecode to 3. ; after the jne, there should have been a jmp to I guess .L12. movq 312+MM_Main(%rip), %rax cmpq $3, %rax jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT Thanks for the small test case! - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Tue, 16 Jun 2009 08:50:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... Well, the number 3 is REFANY_typecode. I need to compare the if code to the printing code though.. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... Date: Tue, 16 Jun 2009 08:44:21 +0000 Cool. Here is a smaller repro, on birch AMD64_LINUX. The problem is not the AND, the problem is the IF. MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = REF RECORD rest : REFANY; END; VAR t := NEW(Pair, rest := NEW(Pair, rest := NIL)); BEGIN PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); IF ISTYPE(t.rest,Pair) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Tony this is presumably your type tagging changes?? The problem in the code I think is the compare to the number 3. .L13: movq 312+MM_Main(%rip), %rax cmpq $3, %rax <==== jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT What is that for? It comes right from the IL: (118) set_source_line source line 17 (119) import_procedure procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd (120) declare_param param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 alignment 0x40 in _memory 0x0 up_level 0x0 mode 0x11 (DImode) (121) set_runtime_proc (122) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (123) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (124) load_nil (125) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (126) if_eq (127) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (128) loophole (129) load_integer integer 0x1 (130) and (131) if_true (132) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (133) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (134) extract_mn (135) if_false (136) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (137) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (138) pop_param pop param type 0xb (139) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (140) set_label (141) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (142) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (143) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (144) load_nil (145) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (146) if_eq (147) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (148) loophole (149) load_integer integer 0x1 (150) and (151) if_true (152) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (153) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (154) extract_mn (155) if_false (156) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (157) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (158) pop_param pop param type 0xb (159) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (160) set_label (161) load_integer integer 0x1 (162) declare_temp temp var type 0x7 size 0x40 alignment 0x40 (163) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (164) load_nil (165) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (166) if_eq (167) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (168) loophole (169) load_integer integer 0x1 (170) and (171) if_true (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq (177) jump (178) set_label (179) load_integer integer 0x3 (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq (182) set_label (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 alignment 0x8 in_mem ory 0x0 up_level 0x0 mode 0xe () (188) start_call_direct start call procedure Fmt__Bool, level 0x0, type 0xb (189) load m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 (190) pop_param pop param type 0x0 (191) call_direct call procedure Fmt__Bool, type 0xb (192) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (193) start_call_direct start call procedure RTHooks__Concat, level 0x0, type 0xb (194) load_address load address (L_1) offset 0x280 (195) pop_param pop param type 0xb (196) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (197) pop_param pop param type 0xb (198) call_direct call procedure RTHooks__Concat, type 0xb (199) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (200) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (201) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (202) pop_param pop param type 0xb (203) call_direct call procedure Main__PutLn, type 0xd (204) set_source_line source line 18 (205) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (206) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (207) load_nil (208) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (209) if_eq (210) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (211) loophole (212) load_integer integer 0x1 (213) and (214) if_true (215) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (216) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (217) extract_mn (218) if_false (219) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (220) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (221) pop_param pop param type 0xb (222) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (223) set_label (224) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (225) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (226) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (227) load_nil (228) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (229) if_eq (230) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (231) loophole (232) load_integer integer 0x1 (233) and (234) if_true (235) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (236) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (237) extract_mn (238) if_false (239) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (240) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (241) pop_param pop param type 0xb (242) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (243) set_label (244) load_nil (245) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (246) if_eq (247) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (248) loophole (249) load_integer integer 0x1 (250) and (251) if_true (252) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (253) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (254) extract_mn (255) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (256) if_ne (257) set_label (258) load_integer integer 0x3 <===== (259) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (260) if_ne (261) set_label (262) set_source_line source line 19 (263) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (264) load_address load address (L_1) offset 0x400 (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump (268) set_label (269) set_source_line source line 21 (270) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (271) load_address load address (L_1) offset 0x540 (272) pop_param pop param type 0xb (273) call_direct call procedure Main__PutLn, type 0xd (274) set_label (275) set_label (276) load_address load address (MM_Main) offset 0x0 (277) exit_proc (278) free_temp (279) free_temp (280) free_temp (281) free_temp (282) free_temp (283) end_procedure procedure Main_M3 (284) comment comment: `global constant type descriptor' (285) declare_record record id 0xffffffff, fields 0x0, size 0x940 (286) comment comment: `global data type descriptor' I'll dig a bit more. - Jay > To: jay.krell at cornell.edu > Date: Tue, 16 Jun 2009 00:59:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > This small example exhibits it! > > MODULE Main; > IMPORT IO, Fmt; > > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > > TYPE > Pair = BRANDED "Pair" REF RECORD > first, rest : REFANY; > END; > > PROCEDURE Rest(p : Pair) : REFANY = > BEGIN > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > END Rest; > > VAR > t := NEW(Pair, first := "first", > rest := NEW(Pair, first := "second", > rest := NIL)); > > BEGIN > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > PutLn("conjunction? " & Fmt.Bool( > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Output: > > (133)rover:~/testcm3/src>m3build -O > --- building in ../FreeBSD4 --- > m3build: missing ../src/m3overrides > new source -> compiling ../src/Main.m3 > -> linking prog > (134)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? TRUE > in IF clause... > (135)rover:~/testcm3/src>cm3 -clean > --- cleaning ../FreeBSD4 --- > > (136)rover:~/testcm3/src>cm3 > --- building in ../FreeBSD4 --- > > new source -> compiling Main.m3 > -> linking prog > (137)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > (138)rover:~/testcm3/src> > > Jay writes: > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Kneejerk generic response: > > > >=20 > > > >I don't know the operator precedence. Can you put in parens? > > > >Have you looked at the code? > > > >Can you mail us a small self contained repro? > > > >Can you test it on birch? > > > > (That way -- all your files are there and easily gotten/investigated by o= > >thers.) > > > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence. > > > >=20 > > > > - Jay > >=20 > >> To: m3devel at elegosoft.com > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... > >>=20 > >>=20 > >> Hello everyone=2C > >>=20 > >> I'm trying to update to the latest CM3 again=2C so that I can get my > >> Mac working=2C and push my project of migrating a largish codebase > >> from PM3 to CM3 a little further. > >>=20 > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C > >> and ... my Scheme interpreter broke. Here's what the code looks like=2C > >> with annotations: > >>=20 > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> 52 > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> 54 Debug.Out("in IF clause...")=3B > >> 55 > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" > >> 60 END > >> 61 ELSE > >> 62 Debug.Out("in ELSE clause...") > >> 63 END=3B > >>=20 > >> all you need to know is that Debug.Out prints out debugging information > >> to the terminal. What I see is... > >>=20 > >> t.rest =3D NIL? FALSE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> in ELSE clause... > >>=20 > >> What gives!? > >>=20 > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > compiler and runtime bootstrapped today from some previous CM3. > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the > >> code behaved properly under that one. > >>=20 > >> I believe I have also tried it both with and without compiler > >> optimizations. > >>=20 > >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't > >> working right. This is the only if statement in many=2C many source files > >> that seems to be working wrong. > >>=20 > >> Is it possible I'm missing something?? No I don't think so... here's a mo= > >re > >> explicit version: > >>=20 > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> Debug.Out("conjunction? " & Fmt.Bool( > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> ... > >>=20 > >> output is: > >>=20 > >> t.rest # NIL? TRUE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> conjunction? FALSE > >> in ELSE clause... > >>=20 > >> TRUE AND TRUE AND TRUE is FALSE?? > >>=20 > >> Note that:=20 > >>=20 > >> VAR q=2C w=2C e :=3D TRUE=3B > >>=20 > >> Debug.Out("conjunction? " & Fmt.Bool( > >> q AND w AND e))=3B > >>=20 > >> results in TRUE (as it should). > >>=20 > >>=20 > >> Mika > >>=20 > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Kneejerk generic response:
> > =3B
> >I don't know the operator precedence. Can you put in parens?
> >Have you looked at the code?
> >Can you mail us a small self contained repro?
> >Can you test it on birch?
> > =3B (That way -- all your files are there and easily gotten/investigat= > >ed by others.)
> >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence.
> > =3B
> > =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= > >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= > >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= > >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= > >eed to know is that Debug.Out prints out debugging information
>=3B to= > > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= > >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= > >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= > >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= > >ieve I have also tried it both with and without compiler
>=3B optimiza= > >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > > can work if "AND" isn't
>=3B working right. This is the only if state= > >ment in many=2C many source files
>=3B that seems to be working wrong.= > >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= > >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= > >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= > >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B >R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= > >ka
>=3B
> >= > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jun 16 11:59:14 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 16 Jun 2009 09:59:14 +0000 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: Here is the code in the compiler, not being familiar..it seems reasonable.. ELSIF RefType.Is (t) THEN Expr.Compile (ce.args[0]); tagged := CG.Next_label (); false := CG.Next_label (); true := CG.Next_label (); ptr := CG.Pop (); Value.Load (Bool.True); CG.Force (); (* we need a temp *) ce.tmp := CG.Pop_temp (); CG.Push (ptr); CG.Load_nil (); CG.If_compare (CG.Type.Addr, CG.Cmp.EQ, true, CG.Maybe); CG.Push (ptr); CG.Loophole (CG.Type.Addr, Target.Integer.cg_type); CG.Load_integer (Target.Integer.cg_type, TInt.One); CG.And (Target.Integer.cg_type); CG.If_true (tagged, CG.Maybe); CG.Push (ptr); CG.Ref_to_info (M3RT.RH_typecode_offset, M3RT.RH_typecode_size); Type.LoadInfo (t, M3RT.TC_typecode); ; This is the comparison of the desired and actual typecode ; If it equal, we will jump to the label "true" CG.If_compare (Target.Integer.cg_type, CG.Cmp.EQ, true, CG.Always); ; otherwise, we already decided it isn't tagged, so jump ; around that to the label false ; ; This is what is missing in the IL. ; CG.Jump (false); CG.Set_label (tagged); CG.Load_intt (M3RT.REFANY_typecode); Type.LoadInfo (t, M3RT.TC_typecode); CG.If_compare (Target.Integer.cg_type, CG.Cmp.EQ, true, CG.Always); CG.Set_label (false); Value.Load (Bool.False); CG.Store_temp (ce.tmp); CG.Set_label (true); CG.Free (ptr); Let's look for jumps in the IL, there are only two: (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq label 6 (177) jump <== here label 5 (178) set_label label 4 (179) load_integer integer 0x3 <== notice this (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq label 6 (182) set_label label 5 (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label label 6 (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param That is the call to Fmt_Bool. You can see the signature value "3", that the jump goes around. and the other one: (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump label 7 not interesting -- you can't tell here, but it is after all the interesting stuff. It is for the if to skip the else. So that leaves me wondering -- what happened to the jump in the IsType? I think it should be there and it missing messes this up. We don't expect to take that jump, we expect the comparison to be equal, but I think the code gets it reversed and makes corresponding changes so this missing jump is the problem... - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... Date: Tue, 16 Jun 2009 09:16:39 +0000 I haven't figured it out, but: Here is the code for the Fmt.Bool: .L6: ; assume the parameter to Fmt.Bool is TRUE, by ; storing 1 in the parameter place movq $1, 16(%rsp) ; do a bunch of stuff, no need to understand.. movq 32(%rsp), %rax testq %rax, %rax je .L7 movq 32(%rsp), %rax testb $1, %al jne .L8 movq 32(%rsp), %rax movq 312+MM_Main(%rip), %rdx movq -8(%rax), %rax salq $43, %rax shrq $44, %rax ; at this point, between $rdx and $rax, one is ; typecode of the object, one is the typecode of the type ; they compare equal cmpq %rdx, %rax ; This is not taken. jne .L9 ; This is taken. jmp .L7 .L8: ; This does not run. movq 312+MM_Main(%rip), %rax cmpq $3, %rax je .L7 .L9: ; Had the expression resolved to FALSE, this would be ; where FALSE is passed to Fmt.Bool movq $0, 16(%rsp) .L7: movq 16(%rsp), %rdi call Fmt__Bool at PLT And here is the code for the IF: .L11: ; just gloss over this part.. movq 40(%rsp), %rax testq %rax, %rax je .L12 movq 40(%rsp), %rax testb $1, %al jne .L13 movq 40(%rsp), %rax movq 312+MM_Main(%rip), %rdx movq -8(%rax), %rax salq $43, %rax shrq $44, %rax ; again at this point, we have the typecodes, and they compare equal cmpq %rdx, %rax ; This is not taken. jne .L14 .L13: ; At this point things have gone wrong. ; The Fmt.Bool path did not compare the typecode to 3. ; after the jne, there should have been a jmp to I guess .L12. movq 312+MM_Main(%rip), %rax cmpq $3, %rax jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT Thanks for the small test case! - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Tue, 16 Jun 2009 08:50:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... Well, the number 3 is REFANY_typecode. I need to compare the if code to the printing code though.. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... Date: Tue, 16 Jun 2009 08:44:21 +0000 Cool. Here is a smaller repro, on birch AMD64_LINUX. The problem is not the AND, the problem is the IF. MODULE Main; IMPORT IO, Fmt; PROCEDURE PutLn(what : TEXT) = BEGIN IO.Put(what & "\n") END PutLn; TYPE Pair = REF RECORD rest : REFANY; END; VAR t := NEW(Pair, rest := NEW(Pair, rest := NIL)); BEGIN PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); IF ISTYPE(t.rest,Pair) THEN PutLn("in IF clause...") ELSE PutLn("in ELSE clause...") END END Main. Tony this is presumably your type tagging changes?? The problem in the code I think is the compare to the number 3. .L13: movq 312+MM_Main(%rip), %rax cmpq $3, %rax <==== jne .L14 .L12: .stabn 68,0,19,.LM9-.LFBB2 .LM9: leaq 128+L_1(%rip), %rdi call Main__PutLn at PLT jmp .L15 .p2align 4,,10 .p2align 3 .L14: .stabn 68,0,21,.LM10-.LFBB2 .LM10: leaq 168+L_1(%rip), %rdi call Main__PutLn at PLT What is that for? It comes right from the IL: (118) set_source_line source line 17 (119) import_procedure procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd (120) declare_param param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 alignment 0x40 in _memory 0x0 up_level 0x0 mode 0x11 (DImode) (121) set_runtime_proc (122) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (123) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (124) load_nil (125) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (126) if_eq (127) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (128) loophole (129) load_integer integer 0x1 (130) and (131) if_true (132) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (133) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (134) extract_mn (135) if_false (136) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (137) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (138) pop_param pop param type 0xb (139) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (140) set_label (141) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (142) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (143) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (144) load_nil (145) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (146) if_eq (147) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (148) loophole (149) load_integer integer 0x1 (150) and (151) if_true (152) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (153) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (154) extract_mn (155) if_false (156) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (157) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (158) pop_param pop param type 0xb (159) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (160) set_label (161) load_integer integer 0x1 (162) declare_temp temp var type 0x7 size 0x40 alignment 0x40 (163) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (164) load_nil (165) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (166) if_eq (167) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (168) loophole (169) load_integer integer 0x1 (170) and (171) if_true (172) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (173) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (174) extract_mn (175) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (176) if_eq (177) jump (178) set_label (179) load_integer integer 0x3 (180) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (181) if_eq (182) set_label (183) load_integer integer 0x0 (184) store store (noname) offset 0x0 src_t 0x7 dst_t 0x7 (185) set_label (186) import_procedure procedure Fmt__Bool nparams 0x1 rettype 0xb (187) declare_param param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 alignment 0x8 in_mem ory 0x0 up_level 0x0 mode 0xe () (188) start_call_direct start call procedure Fmt__Bool, level 0x0, type 0xb (189) load m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 (190) pop_param pop param type 0x0 (191) call_direct call procedure Fmt__Bool, type 0xb (192) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (193) start_call_direct start call procedure RTHooks__Concat, level 0x0, type 0xb (194) load_address load address (L_1) offset 0x280 (195) pop_param pop param type 0xb (196) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (197) pop_param pop param type 0xb (198) call_direct call procedure RTHooks__Concat, type 0xb (199) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (200) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (201) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (202) pop_param pop param type 0xb (203) call_direct call procedure Main__PutLn, type 0xd (204) set_source_line source line 18 (205) load m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb (206) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (207) load_nil (208) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (209) if_eq (210) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (211) loophole (212) load_integer integer 0x1 (213) and (214) if_true (215) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (216) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (217) extract_mn (218) if_false (219) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (220) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (221) pop_param pop param type 0xb (222) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (223) set_label (224) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (225) load_indirect load address offset 0x0 src_t 0xb dst_t 0xb (226) store store (noname) offset 0x0 src_t 0xb dst_t 0xb (227) load_nil (228) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (229) if_eq (230) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (231) loophole (232) load_integer integer 0x1 (233) and (234) if_true (235) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (236) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (237) extract_mn (238) if_false (239) start_call_direct start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type 0xd (240) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (241) pop_param pop param type 0xb (242) call_direct call procedure RTHooks__CheckLoadTracedRef, type 0xd (243) set_label (244) load_nil (245) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (246) if_eq (247) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (248) loophole (249) load_integer integer 0x1 (250) and (251) if_true (252) load m3cg_load (noname): offset 0x0, convert 0xb -> 0xb (253) load_indirect load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 (254) extract_mn (255) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (256) if_ne (257) set_label (258) load_integer integer 0x3 <===== (259) load m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 (260) if_ne (261) set_label (262) set_source_line source line 19 (263) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (264) load_address load address (L_1) offset 0x400 (265) pop_param pop param type 0xb (266) call_direct call procedure Main__PutLn, type 0xd (267) jump (268) set_label (269) set_source_line source line 21 (270) start_call_direct start call procedure Main__PutLn, level 0x0, type 0xd (271) load_address load address (L_1) offset 0x540 (272) pop_param pop param type 0xb (273) call_direct call procedure Main__PutLn, type 0xd (274) set_label (275) set_label (276) load_address load address (MM_Main) offset 0x0 (277) exit_proc (278) free_temp (279) free_temp (280) free_temp (281) free_temp (282) free_temp (283) end_procedure procedure Main_M3 (284) comment comment: `global constant type descriptor' (285) declare_record record id 0xffffffff, fields 0x0, size 0x940 (286) comment comment: `global data type descriptor' I'll dig a bit more. - Jay > To: jay.krell at cornell.edu > Date: Tue, 16 Jun 2009 00:59:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > This small example exhibits it! > > MODULE Main; > IMPORT IO, Fmt; > > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > > TYPE > Pair = BRANDED "Pair" REF RECORD > first, rest : REFANY; > END; > > PROCEDURE Rest(p : Pair) : REFANY = > BEGIN > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > END Rest; > > VAR > t := NEW(Pair, first := "first", > rest := NEW(Pair, first := "second", > rest := NIL)); > > BEGIN > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > PutLn("conjunction? " & Fmt.Bool( > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) )); > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = NIL) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Output: > > (133)rover:~/testcm3/src>m3build -O > --- building in ../FreeBSD4 --- > m3build: missing ../src/m3overrides > new source -> compiling ../src/Main.m3 > -> linking prog > (134)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? TRUE > in IF clause... > (135)rover:~/testcm3/src>cm3 -clean > --- cleaning ../FreeBSD4 --- > > (136)rover:~/testcm3/src>cm3 > --- building in ../FreeBSD4 --- > > new source -> compiling Main.m3 > -> linking prog > (137)rover:~/testcm3/src>../FreeBSD4/prog > t.rest # NIL? TRUE > ISTYPE(t.rest,Pair)? TRUE > Rest(t.rest) = NIL? TRUE > conjunction? FALSE > in ELSE clause... > (138)rover:~/testcm3/src> > > Jay writes: > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Kneejerk generic response: > > > >=20 > > > >I don't know the operator precedence. Can you put in parens? > > > >Have you looked at the code? > > > >Can you mail us a small self contained repro? > > > >Can you test it on birch? > > > > (That way -- all your files are there and easily gotten/investigated by o= > >thers.) > > > >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence. > > > >=20 > > > > - Jay > >=20 > >> To: m3devel at elegosoft.com > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Strange behavior in recent CM3-compiled code... > >>=20 > >>=20 > >> Hello everyone=2C > >>=20 > >> I'm trying to update to the latest CM3 again=2C so that I can get my > >> Mac working=2C and push my project of migrating a largish codebase > >> from PM3 to CM3 a little further. > >>=20 > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD system=2C > >> and ... my Scheme interpreter broke. Here's what the code looks like=2C > >> with annotations: > >>=20 > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> 52 > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> 54 Debug.Out("in IF clause...")=3B > >> 55 > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D "=2C@" > >> 60 END > >> 61 ELSE > >> 62 Debug.Out("in ELSE clause...") > >> 63 END=3B > >>=20 > >> all you need to know is that Debug.Out prints out debugging information > >> to the terminal. What I see is... > >>=20 > >> t.rest =3D NIL? FALSE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> in ELSE clause... > >>=20 > >> What gives!? > >>=20 > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > compiler and runtime bootstrapped today from some previous CM3. > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C and the > >> code behaved properly under that one. > >>=20 > >> I believe I have also tried it both with and without compiler > >> optimizations. > >>=20 > >> I find it baffling that so much stuff (mentor!) can work if "AND" isn't > >> working right. This is the only if statement in many=2C many source files > >> that seems to be working wrong. > >>=20 > >> Is it possible I'm missing something?? No I don't think so... here's a mo= > >re > >> explicit version: > >>=20 > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > >> Debug.Out("ISTYPE(t.rest=2CT)? " & Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > >> Debug.Out("Rest(t.rest) =3D NIL? " & Fmt.Bool(Rest(t.rest)=3DNIL))=3B > >> Debug.Out("conjunction? " & Fmt.Bool( > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN > >> ... > >>=20 > >> output is: > >>=20 > >> t.rest # NIL? TRUE > >> ISTYPE(t.rest=2CT)? TRUE > >> Rest(t.rest) =3D NIL? TRUE > >> conjunction? FALSE > >> in ELSE clause... > >>=20 > >> TRUE AND TRUE AND TRUE is FALSE?? > >>=20 > >> Note that:=20 > >>=20 > >> VAR q=2C w=2C e :=3D TRUE=3B > >>=20 > >> Debug.Out("conjunction? " & Fmt.Bool( > >> q AND w AND e))=3B > >>=20 > >> results in TRUE (as it should). > >>=20 > >>=20 > >> Mika > >>=20 > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Kneejerk generic response:
> > =3B
> >I don't know the operator precedence. Can you put in parens?
> >Have you looked at the code?
> >Can you mail us a small self contained repro?
> >Can you test it on birch?
> > =3B (That way -- all your files are there and easily gotten/investigat= > >ed by others.)
> >Optimization enabled? Works without? I know=2C I shouldn't even ask this so= > >rt of thing without evidence.
> > =3B
> > =3B- Jay
 =3B
>=3B To: m3devel at elegosoft.com
>=3B Dat= > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3devel= > >] Strange behavior in recent CM3-compiled code...
>=3B
>=3B
= > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to update to the l= > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C and push m= > >y project of migrating a largish codebase
>=3B from PM3 to CM3 a littl= > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C on both my = > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme interpreter brok= > >e. Here's what the code looks like=2C
>=3B with annotations:
>=3B= > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B Fmt.Bool(t.rest=3DNIL))= > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t= > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt= > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest # NIL AND= > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 Debug.Out("i= > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C "quote") = > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C "quasiquote") THE= > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") THEN spec= > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN= > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B 62 Debug.= > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B all you n= > >eed to know is that Debug.Out prints out debugging information
>=3B to= > > the terminal. What I see is...
>=3B
>=3B t.rest =3D NIL? FALSE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B in ELSE clause...
>=3B
>=3B What gives!?
>=3B
&g= > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 with a
&g= > >t=3B compiler and runtime bootstrapped today from some previous CM3.
>= > >=3B My old CM3 compiler was timestamped... April 30=2C I believe=2C and the= > >
>=3B code behaved properly under that one.
>=3B
>=3B I bel= > >ieve I have also tried it both with and without compiler
>=3B optimiza= > >tions.
>=3B
>=3B I find it baffling that so much stuff (mentor!)= > > can work if "AND" isn't
>=3B working right. This is the only if state= > >ment in many=2C many source files
>=3B that seems to be working wrong.= > >
>=3B
>=3B Is it possible I'm missing something?? No I don't thi= > >nk so... here's a more
>=3B explicit version:
>=3B
>=3B Deb= > >ug.Out("t.rest # NIL? " &=3B Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > >t("ISTYPE(t.rest=2CT)? " &=3B Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B Fmt.Bool(Rest(t.rest)=3DNIL))= > >=3B
>=3B Debug.Out("conjunction? " &=3B Fmt.Bool(
>=3B t.rest = > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL ))=3B
>=3B IF t.= > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B .= > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # NIL? TRUE<= > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D NIL? TRUE
= > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B
>=3B = > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that:
>= > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B Debug.Out(= > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND e))=3B
>=3B >R>>=3B results in TRUE (as it should).
>=3B
>=3B
>=3B Mi= > >ka
>=3B
> >= > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jun 16 17:35:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 16 Jun 2009 11:35:29 -0400 Subject: [M3devel] Strange behavior in recent CM3-compiled code... In-Reply-To: References: Your message of "Tue, 16 Jun 2009 07:11:08 -0000." <200906160759.n5G7xBoe063526@camembert.async.caltech.edu> Message-ID: I think I see the problem in the compiler. There is some strangeness in how true=CG.No_label is dealt with. On 16 Jun 2009, at 05:59, Jay wrote: > Here is the code in the compiler, not being familiar..it seems > reasonable.. > > > ELSIF RefType.Is (t) THEN > Expr.Compile (ce.args[0]); > tagged := CG.Next_label (); > false := CG.Next_label (); > true := CG.Next_label (); > ptr := CG.Pop (); > Value.Load (Bool.True); > CG.Force (); (* we need a temp *) > ce.tmp := CG.Pop_temp (); > CG.Push (ptr); > CG.Load_nil (); > CG.If_compare (CG.Type.Addr, CG.Cmp.EQ, true, CG.Maybe); > CG.Push (ptr); > CG.Loophole (CG.Type.Addr, Target.Integer.cg_type); > CG.Load_integer (Target.Integer.cg_type, TInt.One); > CG.And (Target.Integer.cg_type); > CG.If_true (tagged, CG.Maybe); > CG.Push (ptr); > CG.Ref_to_info (M3RT.RH_typecode_offset, M3RT.RH_typecode_size); > Type.LoadInfo (t, M3RT.TC_typecode); > > ; This is the comparison of the desired and actual typecode > ; If it equal, we will jump to the label "true" > CG.If_compare (Target.Integer.cg_type, CG.Cmp.EQ, true, > CG.Always); > > ; otherwise, we already decided it isn't tagged, so jump > ; around that to the label false > ; > ; This is what is missing in the IL. > ; > CG.Jump (false); > > CG.Set_label (tagged); > CG.Load_intt (M3RT.REFANY_typecode); > Type.LoadInfo (t, M3RT.TC_typecode); > CG.If_compare (Target.Integer.cg_type, CG.Cmp.EQ, true, > CG.Always); > CG.Set_label (false); > Value.Load (Bool.False); > CG.Store_temp (ce.tmp); > CG.Set_label (true); > CG.Free (ptr); > > > > Let's look for jumps in the IL, there are only two: > > (172) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (173) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (174) extract_mn > (175) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (176) if_eq > label 6 > (177) jump <== here > label 5 > (178) set_label > label 4 > (179) load_integer > integer 0x3 <== notice this > (180) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (181) if_eq > label 6 > (182) set_label > label 5 > (183) load_integer > integer 0x0 > (184) store > store (noname) offset 0x0 src_t 0x7 dst_t 0x7 > (185) set_label > label 6 > (186) import_procedure > procedure Fmt__Bool nparams 0x1 rettype 0xb > (187) declare_param > > > That is the call to Fmt_Bool. > You can see the signature value "3", that the jump goes around. > > and the other one: > > (265) pop_param > pop param type 0xb > (266) call_direct > call procedure Main__PutLn, type 0xd > (267) jump > label 7 > > not interesting -- you can't tell here, but it is after all the > interesting stuff. > It is for the if to skip the else. > > So that leaves me wondering -- what happened to the jump in the > IsType? > I think it should be there and it missing messes this up. > We don't expect to take that jump, we expect the comparison to be > equal, but I think the code gets it reversed and makes corresponding > changes so this missing jump is the problem... > > > - Jay > > > > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... > Date: Tue, 16 Jun 2009 09:16:39 +0000 > > I haven't figured it out, but: > > Here is the code for the Fmt.Bool: > > .L6: > ; assume the parameter to Fmt.Bool is TRUE, by > ; storing 1 in the parameter place > > movq $1, 16(%rsp) > > ; do a bunch of stuff, no need to understand.. > > movq 32(%rsp), %rax > testq %rax, %rax > je .L7 > movq 32(%rsp), %rax > testb $1, %al > jne .L8 > movq 32(%rsp), %rax > movq 312+MM_Main(%rip), %rdx > movq -8(%rax), %rax > salq $43, %rax > shrq $44, %rax > > ; at this point, between $rdx and $rax, one is > ; typecode of the object, one is the typecode of the type > ; they compare equal > > cmpq %rdx, %rax > > ; This is not taken. > > jne .L9 > > ; This is taken. > > jmp .L7 > > .L8: > ; This does not run. > movq 312+MM_Main(%rip), %rax > cmpq $3, %rax > je .L7 > .L9: > ; Had the expression resolved to FALSE, this would be > ; where FALSE is passed to Fmt.Bool > movq $0, 16(%rsp) > .L7: > movq 16(%rsp), %rdi > call Fmt__Bool at PLT > > > And here is the code for the IF: > > .L11: > ; just gloss over this part.. > > movq 40(%rsp), %rax > testq %rax, %rax > je .L12 > movq 40(%rsp), %rax > testb $1, %al > jne .L13 > movq 40(%rsp), %rax > movq 312+MM_Main(%rip), %rdx > movq -8(%rax), %rax > salq $43, %rax > shrq $44, %rax > > ; again at this point, we have the typecodes, and they compare equal > > cmpq %rdx, %rax > > ; This is not taken. > > jne .L14 > > .L13: > > ; At this point things have gone wrong. > ; The Fmt.Bool path did not compare the typecode to 3. > ; after the jne, there should have been a jmp to I guess .L12. > > movq 312+MM_Main(%rip), %rax > cmpq $3, %rax > jne .L14 > > .L12: > .stabn 68,0,19,.LM9-.LFBB2 > .LM9: > leaq 128+L_1(%rip), %rdi > call Main__PutLn at PLT > jmp .L15 > .p2align 4,,10 > .p2align 3 > .L14: > .stabn 68,0,21,.LM10-.LFBB2 > .LM10: > leaq 168+L_1(%rip), %rdi > call Main__PutLn at PLT > > > Thanks for the small test case! > > - Jay > > > > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > Date: Tue, 16 Jun 2009 08:50:02 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled code... > > Well, the number 3 is REFANY_typecode. > I need to compare the if code to the printing code though.. > > - Jay > > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Strange behavior in recent CM3-compiled code... > Date: Tue, 16 Jun 2009 08:44:21 +0000 > > Cool. > Here is a smaller repro, on birch AMD64_LINUX. > > The problem is not the AND, the problem is the IF. > > > MODULE Main; > IMPORT IO, Fmt; > PROCEDURE PutLn(what : TEXT) = > BEGIN IO.Put(what & "\n") END PutLn; > > TYPE > Pair = REF RECORD > rest : REFANY; > END; > VAR > t := NEW(Pair, rest := NEW(Pair, rest := NIL)); > BEGIN > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > IF ISTYPE(t.rest,Pair) THEN > PutLn("in IF clause...") > ELSE > PutLn("in ELSE clause...") > END > END Main. > > Tony this is presumably your type tagging changes?? > > The problem in the code I think is the compare to the number 3. > > .L13: > movq 312+MM_Main(%rip), %rax > cmpq $3, %rax <==== > jne .L14 > .L12: > .stabn 68,0,19,.LM9-.LFBB2 > .LM9: > leaq 128+L_1(%rip), %rdi > call Main__PutLn at PLT > jmp .L15 > .p2align 4,,10 > .p2align 3 > .L14: > .stabn 68,0,21,.LM10-.LFBB2 > .LM10: > leaq 168+L_1(%rip), %rdi > call Main__PutLn at PLT > > > What is that for? > > > It comes right from the IL: > > (118) set_source_line > source line 17 > (119) import_procedure > procedure RTHooks__CheckLoadTracedRef nparams 0x1 rettype 0xd > (120) declare_param > param M3_Af40ku_ref type 0xb typeid 0x1c1c45e6 bytesize 0x40 > alignment 0x40 in > _memory 0x0 up_level 0x0 > mode 0x11 (DImode) > (121) set_runtime_proc > (122) load > m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb > (123) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (124) load_nil > (125) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (126) if_eq > (127) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (128) loophole > (129) load_integer > integer 0x1 > (130) and > (131) if_true > (132) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (133) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (134) extract_mn > (135) if_false > (136) start_call_direct > start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type > 0xd > (137) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (138) pop_param > pop param type 0xb > (139) call_direct > call procedure RTHooks__CheckLoadTracedRef, type 0xd > (140) set_label > (141) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (142) load_indirect > load address offset 0x0 src_t 0xb dst_t 0xb > (143) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (144) load_nil > (145) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (146) if_eq > (147) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (148) loophole > (149) load_integer > integer 0x1 > (150) and > (151) if_true > (152) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (153) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (154) extract_mn > (155) if_false > (156) start_call_direct > start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type > 0xd > (157) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (158) pop_param > pop param type 0xb > (159) call_direct > call procedure RTHooks__CheckLoadTracedRef, type 0xd > (160) set_label > (161) load_integer > integer 0x1 > (162) declare_temp > temp var type 0x7 size 0x40 alignment 0x40 > (163) store > store (noname) offset 0x0 src_t 0x7 dst_t 0x7 > (164) load_nil > (165) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (166) if_eq > (167) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (168) loophole > (169) load_integer > integer 0x1 > (170) and > (171) if_true > (172) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (173) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (174) extract_mn > (175) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (176) if_eq > (177) jump > (178) set_label > (179) load_integer > integer 0x3 > (180) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (181) if_eq > (182) set_label > (183) load_integer > integer 0x0 > (184) store > store (noname) offset 0x0 src_t 0x7 dst_t 0x7 > (185) set_label > (186) import_procedure > procedure Fmt__Bool nparams 0x1 rettype 0xb > (187) declare_param > param M3_AicXUJ_b type 0x0 typeid 0x1e59237d bytesize 0x8 > alignment 0x8 in_mem > ory 0x0 up_level 0x0 > mode 0xe () > (188) start_call_direct > start call procedure Fmt__Bool, level 0x0, type 0xb > (189) load > m3cg_load (noname): offset 0x0, convert 0x7 -> 0x7 > (190) pop_param > pop param type 0x0 > (191) call_direct > call procedure Fmt__Bool, type 0xb > (192) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (193) start_call_direct > start call procedure RTHooks__Concat, level 0x0, type 0xb > (194) load_address > load address (L_1) offset 0x280 > (195) pop_param > pop param type 0xb > (196) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (197) pop_param > pop param type 0xb > (198) call_direct > call procedure RTHooks__Concat, type 0xb > (199) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (200) start_call_direct > start call procedure Main__PutLn, level 0x0, type 0xd > (201) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (202) pop_param > pop param type 0xb > (203) call_direct > call procedure Main__PutLn, type 0xd > (204) set_source_line > source line 18 > (205) load > m3cg_load (MM_Main): offset 0x640, convert 0xb -> 0xb > (206) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (207) load_nil > (208) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (209) if_eq > (210) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (211) loophole > (212) load_integer > integer 0x1 > (213) and > (214) if_true > (215) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (216) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (217) extract_mn > (218) if_false > (219) start_call_direct > start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type > 0xd > (220) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (221) pop_param > pop param type 0xb > (222) call_direct > call procedure RTHooks__CheckLoadTracedRef, type 0xd > (223) set_label > (224) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (225) load_indirect > load address offset 0x0 src_t 0xb dst_t 0xb > (226) store > store (noname) offset 0x0 src_t 0xb dst_t 0xb > (227) load_nil > (228) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (229) if_eq > (230) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (231) loophole > (232) load_integer > integer 0x1 > (233) and > (234) if_true > (235) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (236) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (237) extract_mn > (238) if_false > (239) start_call_direct > start call procedure RTHooks__CheckLoadTracedRef, level 0x0, type > 0xd > (240) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (241) pop_param > pop param type 0xb > (242) call_direct > call procedure RTHooks__CheckLoadTracedRef, type 0xd > (243) set_label > (244) load_nil > (245) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (246) if_eq > (247) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (248) loophole > (249) load_integer > integer 0x1 > (250) and > (251) if_true > (252) load > m3cg_load (noname): offset 0x0, convert 0xb -> 0xb > (253) load_indirect > load address offset 0xffffffffffffffc0 src_t 0x7 dst_t 0x7 > (254) extract_mn > (255) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (256) if_ne > (257) set_label > (258) load_integer > integer 0x3 <===== > (259) load > m3cg_load (MM_Main): offset 0x9c0, convert 0x7 -> 0x7 > (260) if_ne > (261) set_label > (262) set_source_line > source line 19 > (263) start_call_direct > start call procedure Main__PutLn, level 0x0, type 0xd > (264) load_address > load address (L_1) offset 0x400 > (265) pop_param > pop param type 0xb > (266) call_direct > call procedure Main__PutLn, type 0xd > (267) jump > (268) set_label > (269) set_source_line > source line 21 > (270) start_call_direct > start call procedure Main__PutLn, level 0x0, type 0xd > (271) load_address > load address (L_1) offset 0x540 > (272) pop_param > pop param type 0xb > (273) call_direct > call procedure Main__PutLn, type 0xd > (274) set_label > (275) set_label > (276) load_address > load address (MM_Main) offset 0x0 > (277) exit_proc > (278) free_temp > (279) free_temp > (280) free_temp > (281) free_temp > (282) free_temp > (283) end_procedure > procedure Main_M3 > (284) comment > comment: `global constant type descriptor' > (285) declare_record > record id 0xffffffff, fields 0x0, size 0x940 > (286) comment > comment: `global data type descriptor' > > > I'll dig a bit more. > > > - Jay > > > > > > > > > To: jay.krell at cornell.edu > > Date: Tue, 16 Jun 2009 00:59:10 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Strange behavior in recent CM3-compiled > code... > > > > This small example exhibits it! > > > > MODULE Main; > > IMPORT IO, Fmt; > > > > PROCEDURE PutLn(what : TEXT) = > > BEGIN IO.Put(what & "\n") END PutLn; > > > > > > TYPE > > Pair = BRANDED "Pair" REF RECORD > > first, rest : REFANY; > > END; > > > > PROCEDURE Rest(p : Pair) : REFANY = > > BEGIN > > IF p = NIL THEN RETURN NIL ELSE RETURN p.rest END > > END Rest; > > > > VAR > > t := NEW(Pair, first := "first", > > rest := NEW(Pair, first := "second", > > rest := NIL)); > > > > BEGIN > > PutLn("t.rest # NIL? " & Fmt.Bool(t.rest#NIL)); > > PutLn("ISTYPE(t.rest,Pair)? " & Fmt.Bool(ISTYPE(t.rest,Pair))); > > PutLn("Rest(t.rest) = NIL? " & Fmt.Bool(Rest(t.rest)=NIL)); > > PutLn("conjunction? " & Fmt.Bool( > > (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = > NIL) )); > > IF (t.rest # NIL) AND (ISTYPE(t.rest,Pair)) AND (Rest(t.rest) = > NIL) THEN > > PutLn("in IF clause...") > > ELSE > > PutLn("in ELSE clause...") > > END > > END Main. > > > > Output: > > > > (133)rover:~/testcm3/src>m3build -O > > --- building in ../FreeBSD4 --- > > m3build: missing ../src/m3overrides > > new source -> compiling ../src/Main.m3 > > -> linking prog > > (134)rover:~/testcm3/src>../FreeBSD4/prog > > t.rest # NIL? TRUE > > ISTYPE(t.rest,Pair)? TRUE > > Rest(t.rest) = NIL? TRUE > > conjunction? TRUE > > in IF clause... > > (135)rover:~/testcm3/src>cm3 -clean > > --- cleaning ../FreeBSD4 --- > > > > (136)rover:~/testcm3/src>cm3 > > --- building in ../FreeBSD4 --- > > > > new source -> compiling Main.m3 > > -> linking prog > > (137)rover:~/testcm3/src>../FreeBSD4/prog > > t.rest # NIL? TRUE > > ISTYPE(t.rest,Pair)? TRUE > > Rest(t.rest) = NIL? TRUE > > conjunction? FALSE > > in ELSE clause... > > (138)rover:~/testcm3/src> > > > > Jay writes: > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > > >Content-Type: text/plain; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > > > > >Kneejerk generic response: > > > > > >=20 > > > > > >I don't know the operator precedence. Can you put in parens? > > > > > >Have you looked at the code? > > > > > >Can you mail us a small self contained repro? > > > > > >Can you test it on birch? > > > > > > (That way -- all your files are there and easily gotten/ > investigated by o= > > >thers.) > > > > > >Optimization enabled? Works without? I know=2C I shouldn't even > ask this so= > > >rt of thing without evidence. > > > > > >=20 > > > > > > - Jay > > >=20 > > >> To: m3devel at elegosoft.com > > >> Date: Tue=2C 16 Jun 2009 00:01:18 -0700 > > >> From: mika at async.caltech.edu > > >> CC: mika at camembert.async.caltech.edu > > >> Subject: [M3devel] Strange behavior in recent CM3-compiled > code... > > >>=20 > > >>=20 > > >> Hello everyone=2C > > >>=20 > > >> I'm trying to update to the latest CM3 again=2C so that I can > get my > > >> Mac working=2C and push my project of migrating a largish > codebase > > >> from PM3 to CM3 a little further. > > >>=20 > > >> I updated CM3 today from CVS=2C on both my Mac and on a FreeBSD > system=2C > > >> and ... my Scheme interpreter broke. Here's what the code looks > like=2C > > >> with annotations: > > >>=20 > > >> 49 Debug.Out("t.rest =3D NIL? " & Fmt.Bool(t.rest=3DNIL))=3B > > >> 50 Debug.Out("ISTYPE(t.rest=2CT)? " & > Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > > >> 51 Debug.Out("Rest(t.rest) =3D NIL? " & > Fmt.Bool(Rest(t.rest)=3DNIL))=3B > > >> 52 > > >> 53 IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D > NIL THEN > > >> 54 Debug.Out("in IF clause...")=3B > > >> 55 > > >> 56 IF SymEq(t.first=2C "quote") THEN special :=3D "'" > > >> 57 ELSIF SymEq(t.first=2C "quasiquote") THEN special :=3D "`" > > >> 58 ELSIF SymEq(t.first=2C "unquote") THEN special :=3D "=2C" > > >> 59 ELSIF SymEq(t.first=2C "unquote-splicing") THEN special :=3D > "=2C@" > > >> 60 END > > >> 61 ELSE > > >> 62 Debug.Out("in ELSE clause...") > > >> 63 END=3B > > >>=20 > > >> all you need to know is that Debug.Out prints out debugging > information > > >> to the terminal. What I see is... > > >>=20 > > >> t.rest =3D NIL? FALSE > > >> ISTYPE(t.rest=2CT)? TRUE > > >> Rest(t.rest) =3D NIL? TRUE > > >> in ELSE clause... > > >>=20 > > >> What gives!? > > >>=20 > > >> Note this behavior occurs on both the Mac and on FreeBSD4 with a > > > compiler and runtime bootstrapped today from some previous CM3. > > >> My old CM3 compiler was timestamped... April 30=2C I believe=2C > and the > > >> code behaved properly under that one. > > >>=20 > > >> I believe I have also tried it both with and without compiler > > >> optimizations. > > >>=20 > > >> I find it baffling that so much stuff (mentor!) can work if > "AND" isn't > > >> working right. This is the only if statement in many=2C many > source files > > >> that seems to be working wrong. > > >>=20 > > >> Is it possible I'm missing something?? No I don't think so... > here's a mo= > > >re > > >> explicit version: > > >>=20 > > >> Debug.Out("t.rest # NIL? " & Fmt.Bool(t.rest#NIL))=3B > > >> Debug.Out("ISTYPE(t.rest=2CT)? " & > Fmt.Bool(ISTYPE(t.rest=2CT)))=3B > > >> Debug.Out("Rest(t.rest) =3D NIL? " & > Fmt.Bool(Rest(t.rest)=3DNIL))=3B > > >> Debug.Out("conjunction? " & Fmt.Bool( > > >> t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D > NIL ))=3B > > >> IF t.rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL > THEN > > >> ... > > >>=20 > > >> output is: > > >>=20 > > >> t.rest # NIL? TRUE > > >> ISTYPE(t.rest=2CT)? TRUE > > >> Rest(t.rest) =3D NIL? TRUE > > >> conjunction? FALSE > > >> in ELSE clause... > > >>=20 > > >> TRUE AND TRUE AND TRUE is FALSE?? > > >>=20 > > >> Note that:=20 > > >>=20 > > >> VAR q=2C w=2C e :=3D TRUE=3B > > >>=20 > > >> Debug.Out("conjunction? " & Fmt.Bool( > > >> q AND w AND e))=3B > > >>=20 > > >> results in TRUE (as it should). > > >>=20 > > >>=20 > > >> Mika > > >>=20 > > > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_ > > >Content-Type: text/html; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > > > > > > > > >Kneejerk generic response:
> > > =3B
> > >I don't know the operator precedence. Can you put in parens?
> > >Have you looked at the code?
> > >Can you mail us a small self contained repro?
> > >Can you test it on birch?
> > > =3B (That way -- all your files are there and easily gotten/ > investigat= > > >ed by others.)
> > >Optimization enabled? Works without? I know=2C I shouldn't even > ask this so= > > >rt of thing without evidence.
> > > =3B
> > > =3B- Jay
 =3B
>=3B To: > m3devel at elegosoft.com
>=3B Dat= > > >e: Tue=2C 16 Jun 2009 00:01:18 -0700
>=3B From: mika at async.caltech.edu > = > > >
>=3B CC: mika at camembert.async.caltech.edu
>=3B > Subject: [M3devel= > > >] Strange behavior in recent CM3-compiled code...
>=3B >
>=3B
= > > >>=3B Hello everyone=2C
>=3B
>=3B I'm trying to > update to the l= > > >atest CM3 again=2C so that I can get my
>=3B Mac working=2C > and push m= > > >y project of migrating a largish codebase
>=3B from PM3 to > CM3 a littl= > > >e further.
>=3B
>=3B I updated CM3 today from CVS=2C > on both my = > > >Mac and on a FreeBSD system=2C
>=3B and ... my Scheme > interpreter brok= > > >e. Here's what the code looks like=2C
>=3B with > annotations:
>=3B= > > >
>=3B 49 Debug.Out("t.rest =3D NIL? " &=3B > Fmt.Bool(t.rest=3DNIL))= > > >=3B
>=3B 50 Debug.Out("ISTYPE(t.rest=2CT)? " &=3B > Fmt.Bool(ISTYPE(t= > > >.rest=2CT)))=3B
>=3B 51 Debug.Out("Rest(t.rest) =3D NIL? " > &=3B Fmt= > > >.Bool(Rest(t.rest)=3DNIL))=3B
>=3B 52
>=3B 53 IF t.rest > # NIL AND= > > > ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL THEN
>=3B 54 > Debug.Out("i= > > >n IF clause...")=3B
>=3B 55
>=3B 56 IF SymEq(t.first=2C > "quote") = > > >THEN special :=3D "'"
>=3B 57 ELSIF SymEq(t.first=2C > "quasiquote") THE= > > >N special :=3D "`"
>=3B 58 ELSIF SymEq(t.first=2C "unquote") > THEN spec= > > >ial :=3D "=2C"
>=3B 59 ELSIF SymEq(t.first=2C "unquote- > splicing") THEN= > > > special :=3D "=2C@"
>=3B 60 END
>=3B 61 ELSE
>=3B > 62 Debug.= > > >Out("in ELSE clause...")
>=3B 63 END=3B
>=3B
>=3B > all you n= > > >eed to know is that Debug.Out prints out debugging > information
>=3B to= > > > the terminal. What I see is...
>=3B
>=3B t.rest =3D > NIL? FALSE<= > > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D > NIL? TRUE
= > > >>=3B in ELSE clause...
>=3B
>=3B What gives!? >
>=3B
&g= > > >t=3B Note this behavior occurs on both the Mac and on FreeBSD4 > with a
&g= > > >t=3B compiler and runtime bootstrapped today from some previous > CM3.
>= > > >=3B My old CM3 compiler was timestamped... April 30=2C I > believe=2C and the= > > >
>=3B code behaved properly under that one.
>=3B >
>=3B I bel= > > >ieve I have also tried it both with and without > compiler
>=3B optimiza= > > >tions.
>=3B
>=3B I find it baffling that so much stuff > (mentor!)= > > > can work if "AND" isn't
>=3B working right. This is the > only if state= > > >ment in many=2C many source files
>=3B that seems to be > working wrong.= > > >
>=3B
>=3B Is it possible I'm missing something?? No I > don't thi= > > >nk so... here's a more
>=3B explicit version:
>=3B >
>=3B Deb= > > >ug.Out("t.rest # NIL? " &=3B > Fmt.Bool(t.rest#NIL))=3B
>=3B Debug.Ou= > > >t("ISTYPE(t.rest=2CT)? " &=3B > Fmt.Bool(ISTYPE(t.rest=2CT)))=3B
>=3B= > > > Debug.Out("Rest(t.rest) =3D NIL? " &=3B > Fmt.Bool(Rest(t.rest)=3DNIL))= > > >=3B
>=3B Debug.Out("conjunction? " &=3B > Fmt.Bool(
>=3B t.rest = > > ># NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D > NIL ))=3B
>=3B IF t.= > > >rest # NIL AND ISTYPE(t.rest=2CT) AND Rest(t.rest) =3D NIL > THEN
>=3B .= > > >..
>=3B
>=3B output is:
>=3B
>=3B t.rest # > NIL? TRUE<= > > >BR>>=3B ISTYPE(t.rest=2CT)? TRUE
>=3B Rest(t.rest) =3D > NIL? TRUE
= > > >>=3B conjunction? FALSE
>=3B in ELSE clause...
>=3B >
>=3B = > > >TRUE AND TRUE AND TRUE is FALSE??
>=3B
>=3B Note that: >
>= > > >=3B
>=3B VAR q=2C w=2C e :=3D TRUE=3B
>=3B
>=3B > Debug.Out(= > > >"conjunction? " &=3B Fmt.Bool(
>=3B q AND w AND > e))=3B
>=3B > >R>>=3B results in TRUE (as it should).
>=3B
>=3B >
>=3B Mi= > > >ka
>=3B
> > >= > > > > > >--_55f6c801-7d57-4602-a131-dda139b64dfd_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Jun 17 00:33:30 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 16 Jun 2009 15:33:30 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Tue, 16 Jun 2009 18:33:41." <20090616163341.32CFBCC308@birch.elegosoft.com> Message-ID: <200906162233.n5GMXUhZ091746@camembert.async.caltech.edu> Just wanted to report that my evidence of the bug is gone with this update. As always, many thanks! Antony Hosking writes: >CVSROOT: /usr/cvs >Changes by: hosking at birch. 09/06/16 18:33:41 > >Modified files: > cm3/m3-sys/m3front/src/builtinOps/: IsType.m3 > >Log message: > Fix bug introduced in conditional ISTYPE when tagged reference support was > added. From wagner at elegosoft.com Wed Jun 17 11:19:04 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 17 Jun 2009 11:19:04 +0200 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> References: <200906151112.n5FBCdFS022512@camembert.async.caltech.edu> Message-ID: <20090617111904.nkmmsr3s0kswsg0s@mail.elegosoft.com> Quoting Mika Nystrom : > Hi Jay, > > I've been seeing some new errors attempting to build m3cc on OSX > 10.4 / ppc. > > It seems like it might... possibly... be related to some things you > have done? Or at least it's happening in the same general area of > the compiler. > > Here we go: > > cd ../../gcc/mpfr && : > make[2]: Nothing to be done for `all-am'. > make[2]: Nothing to be done for `all'. > make[2]: Nothing to be done for `all'. > make[1]: Nothing to be done for `all'. > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:191: *** Insufficient number of arguments (2) to function > `patsubst'. Stop. > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: > AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /Users/mika/cm3/m3-sys/m3cc/src/../PPC_DARWIN/_m3.log > Makefile:4437: *** Insufficient number of arguments (2) to function > `patsubst'. Stop. I had these errors, too, some weeks ago. I had to manually install the latest GNU versions of make, autoconf and automake, IIRC. These kinds of problems always kreep in by importing new gcc code, as the GNU developers of course always use all their latest tools, and Apple is somewhay more conservative with their distributions. Olaf > "/Users/mika/cm3/m3-sys/m3cc/src/m3makefile", line 508: quake > runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 > > --procedure-- -line- -file--- > cp_if -- > postcp 508 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > include_dir 592 /Users/mika/cm3/m3-sys/m3cc/src/m3makefile > 4 /Users/mika/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args > > Fatal Error: package build failed > [lapdog:~/cm3/m3-sys/m3cc] mika% > > Any ideas what might be causing this? > > Mika > > > > Jay Krell writes: >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 09/06/15 11:49:14 >> >> Added files: >> cm3/m3-sys/m3cc/gcc-apple/gcc/: gengtype-lex.c gengtype-yacc.c >> gengtype-yacc.h >> >> Log message: >> Add back the lex/yacc/flex/bison outputs that Apple deleted >> but didn't note in the REMOVED file. You only see their >> absence cause problems if building on a machine without >> lex/yacc/flex/bison, such as birch that is missing bison. >> Apple didn't modify gengtype-lex.l and gentype-yacc.y, >> so the unmodified versions of these files taken from gcc 4.2.1. > -- 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 Jun 18 13:43:34 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Jun 2009 13:43:34 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090609212543.GA23398@topoi.pooq.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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> Message-ID: <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > Is it time for me to make another try at installing cm3 from scratch? > In particular, do you think most of the problems I reported with > documentation and archives, etc., have been solved? I really want to > get m3 working on this laptop, but I also want to provide the most > useful problem reports. > > I'm definitely trying to act like a naive user in these installation > attempts (which means I'm trying to act stupider than I am). I've now put some initial release engineering documentation onto birch, available at http://www.opencm3.net/releng It is not linked yet to the main web pages. There are archives for AMD64 built on birch, and current archives for FreeBSD4 should arrive within the next hours (depending on the upload speed of my home link :-). Please try one of those platforms as an example, if possible, before we proceed to perform the builds on other targets. Feel free to update/fix/extend the documentation in www/releng/index-frag.html We will also need to add some more system specifics for Windows users. Perhaps Randy or Jay will look at that. All RC1 archives can be built and shipped to birch with SHIPRC=yes ./scripts/make-dist.sh Contributions for all missing platforms are welcome; but I'd suggest to wait for the first doc and script fixes before we announce the availability for the first release candidate. I'd also like to add links for any system-specific installation packages which might be available. Of course, these should contain the same RC version as the standard archives. Please everybody, add corrections and extended information as you see fit. Thanks for your patience and continuing support, 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 Thu Jun 18 14:05:20 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 12:05:20 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618134334.njcom4fusg0ccsws@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Message-ID: 2) CM3's shared libraries and any you create and ship are in: /usr/local/cm3/lib On most Unix systems you need to set the LD_LIBRARY_PATH (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) environment variable before running programs that use these shared libraries. You don't need to do this any longer. Except on NetBSD. But even that will change with a move to NetBSD 5.0, which was recently released. I'm not certain I got to every platform yet with that change, but I definitely got to a few. AMD64_DARWIN is missing from the list. You should probably mention "Mac OSX" in the description of "Darwin", well, except for ARM_DARWIN, which should mention iPhone and iPod Touch. (cm3 does run on my phone..) Interix should mention Service for Unix (SFU) and Subsystem for Unix Applications (SUA). SOLgnu uses the GNU C compiler but I believe Sun linker. I still haven't done much with my Alpha and IA64 machines. :) Hm, so many archives per platform now. Combinatorial situations lend themselves to combinatorial thinking/work, yuck.. - Jay ---------------------------------------- > Date: Thu, 18 Jun 2009 13:43:34 +0200 > From: wagner at elegosoft.com > To: hendrik at topoi.pooq.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > http://www.opencm3.net/releng From jay.krell at cornell.edu Thu Jun 18 14:12:30 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 12:12:30 +0000 Subject: [M3devel] platform names Message-ID: The new documentation says: Except for some legacy names, all target names have the format PROCESSOR OR ARCHITECTURE_OPERATING SYSTEM. I'm not suggesting a change to the documentation or any existing "new" platform names but I'm pretty certain this system is going to break down on some platforms. In particular, I have an "ARM_LINUX" system, with uclibc, instead of the "usual" desktop/laptop/server glibc. And I have an "MIPLE_LINUX" system, also with uclibc, and worse, Linux 2.4. It is a router and apparently 2.4 is considered reasonable and "current". Linux 2.4 doesn't have the "good" native pthreads, though it does have the old bad "LinuxThreads". It's possible, esp. for Linux, we can/should target the kernel syscall interface and not the C runtime. In which case, this problem is reduced. That's very similar to static linking to libc.a. It's probably /mostly/ easy, easy for open/close/stat/seek/read/write/_exit/fork/exec which are probably all pretty thin in the C runtime. But less easy for startup and threads. It /might/ be that uclibc and glibc are binary compatible, at least partly. I don't know. - Jay From wagner at elegosoft.com Thu Jun 18 14:34:31 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Jun 2009 14:34:31 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: 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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Message-ID: <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> Quoting Jay : > > 2) CM3's shared libraries and any you create and ship are in: > /usr/local/cm3/lib > On most Unix systems you need to set the LD_LIBRARY_PATH > (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) > environment variable before running programs that use > these shared libraries. > You don't need to do this any longer. > Except on NetBSD. But even that will change with a move to NetBSD 5.0, > which was recently released. > I'm not certain I got to every platform yet with that change, but > I definitely got to a few. doc fixed > AMD64_DARWIN is missing from the list. > You should probably mention "Mac OSX" in the description of "Darwin", > well, except for ARM_DARWIN, which should mention iPhone and iPod Touch. > (cm3 does run on my phone..) There is no configuration file for it in m3-sys/cminstall/src/config-no-install I've added it nonetheless. Perhaps you need to commit it. > Interix should mention Service for Unix (SFU) and Subsystem for Unix > Applications (SUA). added > SOLgnu uses the GNU C compiler but I believe Sun linker. fixed > I still haven't done much with my Alpha and IA64 machines. :) > > > Hm, so many archives per platform now. > Combinatorial situations lend themselves to combinatorial > thinking/work, yuck.. We can also provide one complete big archive if people want that. It's just a matter of adding one line in make-dist.sh. It will put some more stress on our network links though ;-) I doubt that many people really want everything. Thanks for the comments, 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 Thu Jun 18 14:39:26 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 12:39:26 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618143431.9b3b3tmzjqww4s48@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> Message-ID: > >> AMD64_DARWIN is missing from the list. > > There is no configuration file for it in > That's because I don't have this hardware, yet. :) - Jay From jay.krell at cornell.edu Thu Jun 18 14:52:29 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 12:52:29 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618143431.9b3b3tmzjqww4s48@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> Message-ID: ps: NT386 isn't in the list. Interix btw is something you free "beer" download and install on some versions of Windows (XP, 2003, I think 2000), and is an optional component you can just enable on newer version (2003R2, Vista, 2008). So maybe Windows and/or NT should be mentioned there. Support will likely only be for 3.5 or newer, since that is when pthreads support was added, and it is already fairly old. NT386GNU and NT386MINGNU are missing also, but that's ok. I kind of like the idea of there being "tiers" of platforms. Two or maybe three. The more supported and the less supported. I would suggest: tier 1: LINUXLIBC6 (aka I386_LINUX) AMD64_LINUX FreeBSD4 (aka I386_FREEBSD) AMD64_FREEBSD AMD64_LINUX I386_LINUX SOLgnu tier 2: SPARC32_LINUX SPARC64_LINUX *_OPENBSD *_NETBSD, NetBSD2i386 SOLsun PPC_* MIPS*_* tier 3: could probably be done easily/quickly if anyone wanted and hardware made available, if gcc 4.2 or 4.3 already supports it (You see, a C backend would extend support to more systems..Plan9 for example...) This is based on apparent number of users. I don't draw a distinction between I386_DARWIN and AMD64_DARWIN because they run on nearly the exact same systems, nearly. (except non-Apple hardware, a few old x86 Macs, and maybe Apple TV). It might be reasonable as well to say a platform can only be tier 1 if has a Tinderbox running. That would knock the list down a lot though. - Jay ---------------------------------------- > Date: Thu, 18 Jun 2009 14:34:31 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: hendrik at topoi.pooq.com; m3devel at elegosoft.com > Subject: RE: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > Quoting Jay : > >> >> 2) CM3's shared libraries and any you create and ship are in: >> /usr/local/cm3/lib >> On most Unix systems you need to set the LD_LIBRARY_PATH >> (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) >> environment variable before running programs that use >> these shared libraries. >> You don't need to do this any longer. >> Except on NetBSD. But even that will change with a move to NetBSD 5.0, >> which was recently released. >> I'm not certain I got to every platform yet with that change, but >> I definitely got to a few. > > doc fixed > >> AMD64_DARWIN is missing from the list. >> You should probably mention "Mac OSX" in the description of "Darwin", >> well, except for ARM_DARWIN, which should mention iPhone and iPod Touch. >> (cm3 does run on my phone..) > > There is no configuration file for it in > > m3-sys/cminstall/src/config-no-install > > I've added it nonetheless. Perhaps you need to commit it. > >> Interix should mention Service for Unix (SFU) and Subsystem for Unix >> Applications (SUA). > > added > >> SOLgnu uses the GNU C compiler but I believe Sun linker. > > fixed > >> I still haven't done much with my Alpha and IA64 machines. :) >> >> >> Hm, so many archives per platform now. >> Combinatorial situations lend themselves to combinatorial >> thinking/work, yuck.. > > We can also provide one complete big archive if people want that. > It's just a matter of adding one line in make-dist.sh. > It will put some more stress on our network links though ;-) > I doubt that many people really want everything. > > Thanks for the comments, > > 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 wagner at elegosoft.com Thu Jun 18 15:06:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Jun 2009 15:06:36 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: 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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> Message-ID: <20090618150636.0rbmvi4g74k04cww@mail.elegosoft.com> Quoting Jay : > ps: NT386 isn't in the list. > > Interix btw is something you free "beer" download and install on > some versions of Windows (XP, 2003, I think 2000), and is an > optional component you can just enable on newer version (2003R2, > Vista, 2008). > So maybe Windows and/or NT should be mentioned there. > Support will likely only be for 3.5 or newer, since that is when > pthreads support was added, and it is already fairly old. > > > NT386GNU and NT386MINGNU are missing also, but that's ok. Jay, could you please add appropriate config files for NT386 and NT386GNU to the config-no-install directory? I was of the opinion, that your config files there were complete. I'd like to be both these platforms to be part of the release. > I kind of like the idea of there being "tiers" of platforms. > Two or maybe three. > The more supported and the less supported. > > > I would suggest: > > > tier 1: > LINUXLIBC6 (aka I386_LINUX) > AMD64_LINUX > FreeBSD4 (aka I386_FREEBSD) > AMD64_FREEBSD > AMD64_LINUX > I386_LINUX > SOLgnu +NT386 We should not ignore the Windows community. > tier 2: > SPARC32_LINUX > SPARC64_LINUX > *_OPENBSD > *_NETBSD, NetBSD2i386 > SOLsun > PPC_* > MIPS*_* > > tier 3: > could probably be done easily/quickly if anyone wanted and hardware > made available, if gcc 4.2 or 4.3 already supports it > (You see, a C backend would extend support to more systems..Plan9 > for example...) > > This is based on apparent number of users. > I don't draw a distinction between I386_DARWIN and AMD64_DARWIN > because they run on nearly the exact same systems, nearly. (except > non-Apple hardware, a few old x86 Macs, and maybe Apple TV). > > It might be reasonable as well to say a platform can only be tier 1 > if has a Tinderbox running. > That would knock the list down a lot though. That would be too constraining currently. Thanks in advance, 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 Thu Jun 18 16:07:16 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 14:07:16 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618150636.0rbmvi4g74k04cww@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> <20090618150636.0rbmvi4g74k04cww@mail.elegosoft.com> Message-ID: (Yes, of course NT386 is tier 1, I forgot, NT386GNU, NT386MINGNU, eh..there is a test case that hangs on NT386GNU that I couldn't figure out and it is slow..I386_INTERIX /might/ be a viable alternative, but it seems to have far less of a following..but NT386GNU does have 64bit LONG and NT386 does not.. :( ) - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: hendrik at topoi.pooq.com; m3devel at elegosoft.com Subject: RE: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) Date: Thu, 18 Jun 2009 14:05:28 +0000 The NT386* files are in the old config directory. My automation knows to check config-no-install first, then config. I thought moving them might break you. At least in the past. Your Tinderbox work. You know...I kind of took over these files, churned them mercilessly, felt ok about it. All the other files I forked and left the "originals" alone. But then eventually mine became the Real ones. Ok, I'll move them. At some point..maybe just after this release, I suggest we: delete all of config then move all config-no-install to config But I bet CVS can't track history across a move, lame. (Maybe after this release we switch to svn or hg or git or mtn, or can get a free p4 license, or darn near anything...) And also delete all the unused Unix/*.i3 files. I worry about the fine line between keeping stuff for historical purposes vs. deleting unused stuff for clarity. I know CVS keeps even the deleted stuff, but Attic is kind of less visible, isn't brought down by cvs upd, and the cvs web interface is poor. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jun 18 16:05:28 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 14:05:28 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618150636.0rbmvi4g74k04cww@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090618143431.9b3b3tmzjqww4s48@mail.elegosoft.com> <20090618150636.0rbmvi4g74k04cww@mail.elegosoft.com> Message-ID: The NT386* files are in the old config directory. My automation knows to check config-no-install first, then config. I thought moving them might break you. At least in the past. Your Tinderbox work. You know...I kind of took over these files, churned them mercilessly, felt ok about it. All the other files I forked and left the "originals" alone. But then eventually mine became the Real ones. Ok, I'll move them. At some point..maybe just after this release, I suggest we: delete all of config then move all config-no-install to config But I bet CVS can't track history across a move, lame. (Maybe after this release we switch to svn or hg or git or mtn, or can get a free p4 license, or darn near anything...) And also delete all the unused Unix/*.i3 files. I worry about the fine line between keeping stuff for historical purposes vs. deleting unused stuff for clarity. I know CVS keeps even the deleted stuff, but Attic is kind of less visible, isn't brought down by cvs upd, and the cvs web interface is poor. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jun 18 16:27:03 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 18 Jun 2009 14:27:03 +0000 Subject: [M3devel] FW: Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618134334.njcom4fusg0ccsws@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Message-ID: The copy to the list was truncated, but direct to Olaf wasn't and he quoted the whole thing.. (The truncation of Olaf's original message was my deliberate doing.) - Jay > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; hendrik at topoi.pooq.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > Date: Thu, 18 Jun 2009 12:05:20 +0000 > > > 2) CM3's shared libraries and any you create and ship are in: > /usr/local/cm3/lib > On most Unix systems you need to set the LD_LIBRARY_PATH > (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) > environment variable before running programs that use > these shared libraries. > > > You don't need to do this any longer. > Except on NetBSD. But even that will change with a move to NetBSD 5.0, > which was recently released. > I'm not certain I got to every platform yet with that change, but > I definitely got to a few. > > > AMD64_DARWIN is missing from the list. > You should probably mention "Mac OSX" in the description of "Darwin", > well, except for ARM_DARWIN, which should mention iPhone and iPod Touch. > (cm3 does run on my phone..) > > > Interix should mention Service for Unix (SFU) and Subsystem for Unix Applications (SUA). > > > SOLgnu uses the GNU C compiler but I believe Sun linker. > > > I still haven't done much with my Alpha and IA64 machines. :) > > > Hm, so many archives per platform now. > Combinatorial situations lend themselves to combinatorial thinking/work, yuck.. > > > - Jay > > > > ---------------------------------------- > > Date: Thu, 18 Jun 2009 13:43:34 +0200 > > From: wagner at elegosoft.com > > To: hendrik at topoi.pooq.com > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > > > http://www.opencm3.net/releng -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 22 06:04:31 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 04:04:31 +0000 Subject: [M3devel] new distribution size? Message-ID: Olaf, The ws-core archives are quite large. Over 100meg, four times the size of bin-std. Should they be? I guess they have a lot of source? - Jay From wagner at elegosoft.com Mon Jun 22 08:17:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Jun 2009 08:17:29 +0200 Subject: [M3devel] new distribution size? In-Reply-To: References: Message-ID: <20090622081729.z6gvq7us8w8ckscs@mail.elegosoft.com> Quoting Jay : > > Olaf, > > The ws-core archives are quite large. > Over 100meg, four times the size of bin-std. > Should they be? I guess they have a lot of source? It's mostly the gcc compiler collection: % (. scripts/pkginfo.sh; for f in `grep core scripts/pkginfo.txt | awk '{print $1}'`; do p=`pkgpath $f`; du -sk $p; done) 1486 m3-win/import-libs 326892 m3-sys/m3cc 22294 m3-libs/m3core 25638 m3-libs/libm3 704 m3-libs/patternmatching 2542 m3-libs/sysutils 386 m3-libs/unittest 4492 m3-sys/m3middle 786 m3-sys/m3objfile 1334 m3-sys/m3linker 2662 m3-sys/m3back 2018 m3-sys/m3staloneback 19328 m3-sys/m3front 2082 m3-sys/m3quake 38372 m3-sys/cm3 320 m3-sys/m3scanner 1804 m3-sys/m3tools 4964 m3-sys/m3cgcat 2744 m3-sys/m3cggen 2750 m3-tools/m3bundle 1394 m3-sys/mklib 1318 m3-sys/fix_nl 348 m3-sys/libdump 702 m3-libs/bitvector 382 m3-libs/digraph 286 m3-libs/parseparams 1208 m3-libs/realgeometry 1188 m3-libs/set 1210 m3-libs/slisp 758 m3-libs/sortedtableextras 1002 m3-libs/table-list 202 m3-libs/tempfiles 206 m3-libs/tcl 794 m3-comm/tcp Perhaps we should archive that on its own, too? What do the others think? 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 Mon Jun 22 11:33:24 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 09:33:24 +0000 Subject: [M3devel] nanosleep? Message-ID: Tony, Interix doesn't have nanosleep. Suggestions? It looks like all the uses except for XPause could use usleep? - Jay From hosking at cs.purdue.edu Mon Jun 22 12:29:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Jun 2009 06:29:38 -0400 Subject: [M3devel] nanosleep? In-Reply-To: References: Message-ID: Urgh! Perhaps implement a nanosleep for Interix in terms of usleep? On 22 Jun 2009, at 05:33, Jay wrote: > > Tony, Interix doesn't have nanosleep. > Suggestions? > > It looks like all the uses except for XPause could use usleep? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 22 14:58:17 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 12:58:17 +0000 Subject: [M3devel] files larger than 2gig Message-ID: C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 TYPE Status = RECORD type: Type; modificationTime: Time.T; size: INTEGER; END; size: INTEGER causes exceptions when you use the Modula-3 gui and browse to a directory with files larger than 2 gig. I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa (out 64 bits total) and thus can represent integers very much larger than INTEGER. LONGINT is a tempting option but doesn't help on the current NT386 platform, and I think 53 bits will last a very long time. I'm just trying out such a change and I can see it is not source compatible: "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN "../src/rw/FileRd.m3", line 140: types are not assignable 2 errors encountered "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX 2 errors encountered Nevertheless I think it should be done, probably even for this release. - Jay From jay.krell at cornell.edu Mon Jun 22 15:09:25 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 13:09:25 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Message-ID: Hm, here is another approach -- leave more code alone, like don't attempt to let FileRd/FileWr work on files larger than 2gig on a 32bit system for example. But do fix the lowest level status record to have either LONGINT or LONGREAL, preferable LONGREAL for the sake of NT386 (much as I dislike floating point..). That is, an intermediate goal would be: - browing to a directory with large files with the Trestle file picker should not crash - 32bit Modula-3 code may or may not be able to read/write such files - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] files larger than 2gig > Date: Mon, 22 Jun 2009 13:05:13 +0000 > > > Hm..I'm not sure. > Integers have certain properties, like dividing an integer by an integer yields an integer, > that floating point doesn't. Integer division tends toward zero faster than floating point division. > I can try getting it all to compile with LONGINT maybe instead. > The current behavior is pretty lame. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 22 Jun 2009 12:58:17 +0000 >> Subject: [M3devel] files larger than 2gig >> >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >> >> >> TYPE >> Status = RECORD >> type: Type; >> modificationTime: Time.T; >> size: INTEGER; >> END; >> >> >> size: INTEGER causes exceptions when you use the Modula-3 gui >> and browse to a directory with files larger than 2 gig. >> >> >> I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa >> (out 64 bits total) and thus can represent integers very much larger than INTEGER. >> >> >> LONGINT is a tempting option but doesn't help on the current NT386 platform, >> and I think 53 bits will last a very long time. >> >> >> I'm just trying out such a change and I can see it is not source compatible: >> >> >> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >> "../src/rw/FileRd.m3", line 140: types are not assignable >> 2 errors encountered >> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >> 2 errors encountered >> >> >> Nevertheless I think it should be done, probably even for this release. >> >> >> - Jay From jay.krell at cornell.edu Mon Jun 22 15:05:13 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 13:05:13 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Message-ID: Hm..I'm not sure. Integers have certain properties, like dividing an integer by an integer yields an integer, that floating point doesn't. Integer division tends toward zero faster than floating point division. I can try getting it all to compile with LONGINT maybe instead. The current behavior is pretty lame. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 22 Jun 2009 12:58:17 +0000 > Subject: [M3devel] files larger than 2gig > > > C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 > > > TYPE > Status = RECORD > type: Type; > modificationTime: Time.T; > size: INTEGER; > END; > > > size: INTEGER causes exceptions when you use the Modula-3 gui > and browse to a directory with files larger than 2 gig. > > > I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa > (out 64 bits total) and thus can represent integers very much larger than INTEGER. > > > LONGINT is a tempting option but doesn't help on the current NT386 platform, > and I think 53 bits will last a very long time. > > > I'm just trying out such a change and I can see it is not source compatible: > > > "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN > "../src/rw/FileRd.m3", line 140: types are not assignable > 2 errors encountered > "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN > "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX > 2 errors encountered > > > Nevertheless I think it should be done, probably even for this release. > > > - Jay From wagner at elegosoft.com Mon Jun 22 16:30:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Jun 2009 16:30:03 +0200 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Message-ID: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> Quoting Jay : > > C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 > > > TYPE > Status = RECORD > type: Type; > modificationTime: Time.T; > size: INTEGER; > END; > > > size: INTEGER causes exceptions when you use the Modula-3 gui > and browse to a directory with files larger than 2 gig. This is a known limitation on all 32 bit platforms. > I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa > (out 64 bits total) and thus can represent integers very much larger > than INTEGER. I wouldn't like that. Sizes are no real numbers, really ;-) Either use LONGINT or rely on INTEGER being large enough (64 bit on all 64 bit targets). > LONGINT is a tempting option but doesn't help on the current NT386 platform, > and I think 53 bits will last a very long time. What exactly was the problem in makeing LONGINT work on NT386? > I'm just trying out such a change and I can see it is not source compatible: > > > "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN > "../src/rw/FileRd.m3", line 140: types are not assignable > 2 errors encountered > "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN > "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX > 2 errors encountered > > > Nevertheless I think it should be done, probably even for this release. I'm not convinced... 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 Mon Jun 22 17:36:21 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 15:36:21 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> Message-ID: The NT386 backend internally uses a stack of 32bit words to slightly optimize codegen..it seems kind of similar to what the frontend does..I wonder if it is redundant.. Anyway.. It doesn't appear easy to extend, but with years of hindsight at this point..it might be easiest to have a mode where the front end decomposes 64bit operations into multiple 32bit operations. Maybe that'd be an entire "cg layer" (it appears code generators are layerable). I'm less keen on the LONGREAL solution but still pretty keen on LONGINT. Not right now though, maybe in a few days.. - Jay ---------------------------------------- > Date: Mon, 22 Jun 2009 16:30:03 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > Quoting Jay : > >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >> >> >> TYPE >> Status = RECORD >> type: Type; >> modificationTime: Time.T; >> size: INTEGER; >> END; >> >> >> size: INTEGER causes exceptions when you use the Modula-3 gui >> and browse to a directory with files larger than 2 gig. > > This is a known limitation on all 32 bit platforms. > >> I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa >> (out 64 bits total) and thus can represent integers very much larger >> than INTEGER. > > I wouldn't like that. Sizes are no real numbers, really ;-) > Either use LONGINT or rely on INTEGER being large enough (64 bit > on all 64 bit targets). > >> LONGINT is a tempting option but doesn't help on the current NT386 platform, >> and I think 53 bits will last a very long time. > > What exactly was the problem in makeing LONGINT work on NT386? > >> I'm just trying out such a change and I can see it is not source compatible: >> >> >> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >> "../src/rw/FileRd.m3", line 140: types are not assignable >> 2 errors encountered >> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >> 2 errors encountered >> >> >> Nevertheless I think it should be done, probably even for this release. > > I'm not convinced... > > 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 hosking at cs.purdue.edu Mon Jun 22 18:58:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Jun 2009 12:58:45 -0400 Subject: [M3devel] files larger than 2gig In-Reply-To: References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> Message-ID: On 22 Jun 2009, at 11:36, Jay wrote: > > The NT386 backend internally uses a stack of 32bit words to slightly > optimize codegen..it seems kind of similar to what the frontend > does..I wonder if it is redundant.. > Anyway.. > It doesn't appear easy to extend, but with years of hindsight at > this point..it might be easiest to have a mode where the front end > decomposes 64bit operations into multiple 32bit operations. Yuck. Why not decompose in the backend? > Maybe that'd be an entire "cg layer" (it appears code generators are > layerable). > > > I'm less keen on the LONGREAL solution but still pretty keen on > LONGINT. > Not right now though, maybe in a few days.. > > > - Jay > > > ---------------------------------------- >> Date: Mon, 22 Jun 2009 16:30:03 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] files larger than 2gig >> >> Quoting Jay : >> >>> >>> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >>> >>> >>> TYPE >>> Status = RECORD >>> type: Type; >>> modificationTime: Time.T; >>> size: INTEGER; >>> END; >>> >>> >>> size: INTEGER causes exceptions when you use the Modula-3 gui >>> and browse to a directory with files larger than 2 gig. >> >> This is a known limitation on all 32 bit platforms. >> >>> I suggest size be changed to LONGREAL, which generally has a 53 >>> bit mantissa >>> (out 64 bits total) and thus can represent integers very much larger >>> than INTEGER. >> >> I wouldn't like that. Sizes are no real numbers, really ;-) >> Either use LONGINT or rely on INTEGER being large enough (64 bit >> on all 64 bit targets). >> >>> LONGINT is a tempting option but doesn't help on the current NT386 >>> platform, >>> and I think 53 bits will last a very long time. >> >> What exactly was the problem in makeing LONGINT work on NT386? >> >>> I'm just trying out such a change and I can see it is not source >>> compatible: >>> >>> >>> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >>> "../src/rw/FileRd.m3", line 140: types are not assignable >>> 2 errors encountered >>> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >>> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >>> 2 errors encountered >>> >>> >>> Nevertheless I think it should be done, probably even for this >>> release From wagner at elegosoft.com Mon Jun 22 22:31:52 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Jun 2009 22:31:52 +0200 Subject: [M3devel] compilation fails on SunOs Message-ID: <20090622223152.1u5re0mjs4c0osoo@mail.elegosoft.com> Tinderbox cannot compiler m3core on SunOS: 9884 ../src/unix/Common/UtimeC.c: In function `Utime__ctime_r?: 9885 NEXT ../src/unix/Common/UtimeC.c:101: error: too few arguments to function `ctime_r? 9886 compile_c => 1 9887 NEXT C compiler failed compiling: ../src/unix/Common/UtimeC.c 9888 new source -> compiling UnixC.c 9889 new source -> compiling UnixLink.c Please fix, 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 Mon Jun 22 23:50:59 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 22 Jun 2009 21:50:59 +0000 Subject: [M3devel] compilation fails on SunOs In-Reply-To: <20090622223152.1u5re0mjs4c0osoo@mail.elegosoft.com> References: <20090622223152.1u5re0mjs4c0osoo@mail.elegosoft.com> Message-ID: > Please fix, I believe I already did. - Jay ---------------------------------------- > Date: Mon, 22 Jun 2009 22:31:52 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] compilation fails on SunOs > > Tinderbox cannot compiler m3core on SunOS: > > 9884 ../src/unix/Common/UtimeC.c: In function `Utime__ctime_r?: > 9885 NEXT ../src/unix/Common/UtimeC.c:101: error: too few > arguments to function `ctime_r? > 9886 compile_c => 1 > 9887 NEXT C compiler failed compiling: ../src/unix/Common/UtimeC.c > 9888 new source -> compiling UnixC.c > 9889 new source -> compiling UnixLink.c > > Please fix, > > 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 Tue Jun 23 11:52:15 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 23 Jun 2009 02:52:15 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: Your message of "Mon, 22 Jun 2009 13:09:25 -0000." Message-ID: <200906230952.n5N9qFdh081330@camembert.async.caltech.edu> Jay I just want to add that I've written a lot of code that "streams" files greater than 2 GB just fine in Modula-3. The trick, which I learned from Blair MacIntyre's rdwr package, is to reset the pointers periodically: (* $Id: RdWrReset.m3,v 1.1 2008/11/26 18:32:40 mika Exp $ *) MODULE RdWrReset; IMPORT Rd AS R, Wr AS W; IMPORT RdClass, WrClass; <*NOWARN*>IMPORT UnsafeWr, UnsafeRd; (* Since we need to use the Mutex properties of Rd.T and Wr.T, we should actually import UnsafeWr and UnsafeRd. We need to add the following revelations, as the comment in UnsafeRd points out, if we want to include both the Unsafe* and *Class interfaces. *) REVEAL RdClass.Private <: MUTEX; REVEAL WrClass.Private <: MUTEX; PROCEDURE Rd (rd: R.T) = BEGIN LOCK rd DO DEC(rd.cur, rd.lo); DEC(rd.hi, rd.lo); rd.lo := 0; END; END Rd; PROCEDURE Wr (wr: W.T) = BEGIN LOCK wr DO DEC(wr.cur, wr.lo); DEC(wr.hi, wr.lo); wr.lo := 0; END; END Wr; BEGIN END RdWrReset. Jay writes: > >Hm, here is another approach -- leave more code alone, like don't attempt to l >et FileRd/FileWr work on files larger than 2gig on a 32bit system for example. > But do fix the lowest level status record to have either LONGINT or LONGREAL, > preferable LONGREAL for the sake of NT386 (much as I dislike floating point.. >). >That is, an intermediate goal would be: > - browing to a directory with large files with the Trestle file picker should > not crash > - 32bit Modula-3 code may or may not be able to read/write such files > > - Jay > > > >---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: RE: [M3devel] files larger than 2gig >> Date: Mon, 22 Jun 2009 13:05:13 +0000 >> >> >> Hm..I'm not sure. >> Integers have certain properties, like dividing an integer by an integer yie >lds an integer, >> that floating point doesn't. Integer division tends toward zero faster than >floating point division. >> I can try getting it all to compile with LONGINT maybe instead. >> The current behavior is pretty lame. >> >> - Jay >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Mon, 22 Jun 2009 12:58:17 +0000 >>> Subject: [M3devel] files larger than 2gig >>> >>> >>> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >>> >>> >>> TYPE >>> Status = RECORD >>> type: Type; >>> modificationTime: Time.T; >>> size: INTEGER; >>> END; >>> >>> >>> size: INTEGER causes exceptions when you use the Modula-3 gui >>> and browse to a directory with files larger than 2 gig. >>> >>> >>> I suggest size be changed to LONGREAL, which generally has a 53 bit mantiss >a >>> (out 64 bits total) and thus can represent integers very much larger than I >NTEGER. >>> >>> >>> LONGINT is a tempting option but doesn't help on the current NT386 platform >, >>> and I think 53 bits will last a very long time. >>> >>> >>> I'm just trying out such a change and I can see it is not source compatible >: >>> >>> >>> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >>> "../src/rw/FileRd.m3", line 140: types are not assignable >>> 2 errors encountered >>> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >>> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >>> 2 errors encountered >>> >>> >>> Nevertheless I think it should be done, probably even for this release From mika at async.caltech.edu Tue Jun 23 11:54:47 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 23 Jun 2009 02:54:47 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: Your message of "Mon, 22 Jun 2009 13:05:13 -0000." Message-ID: <200906230954.n5N9slnb081383@camembert.async.caltech.edu> Also, making file handling code depend on the presence of IEEE floating point seems rather odd... As far as I know there is nothing in Modula-3 that bans implementing REAL with single precision arithmetic? By the way I think it's sad that Modula-3's wonderful floating-point support has attracted so much bit rot. I think it's better than just about any other programming language (except maybe some Fortran dialects?) Mika Jay writes: > >Hm..I'm not sure. >Integers have certain properties, like dividing an integer by an integer yield >s an integer, >that floating point doesn't. Integer division tends toward zero faster than fl >oating point division. >I can try getting it all to compile with LONGINT maybe instead. >The current behavior is pretty lame. > > - Jay > >---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 22 Jun 2009 12:58:17 +0000 >> Subject: [M3devel] files larger than 2gig >> >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >> >> >> TYPE >> Status = RECORD >> type: Type; >> modificationTime: Time.T; >> size: INTEGER; >> END; >> >> >> size: INTEGER causes exceptions when you use the Modula-3 gui >> and browse to a directory with files larger than 2 gig. >> >> >> I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa >> (out 64 bits total) and thus can represent integers very much larger than IN >TEGER. >> >> >> LONGINT is a tempting option but doesn't help on the current NT386 platform, >> and I think 53 bits will last a very long time. >> >> >> I'm just trying out such a change and I can see it is not source compatible: >> >> >> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN >> "../src/rw/FileRd.m3", line 140: types are not assignable >> 2 errors encountered >> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN >> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX >> 2 errors encountered >> >> >> Nevertheless I think it should be done, probably even for this release. >> >> >> - Jay From jay.krell at cornell.edu Tue Jun 23 13:02:26 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 23 Jun 2009 11:02:26 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <200906230954.n5N9slnb081383@camembert.async.caltech.edu> References: Your message of "Mon, 22 Jun 2009 13:05:13 -0000." <200906230954.n5N9slnb081383@camembert.async.caltech.edu> Message-ID: Every modern system implements IEEE 754 binary floating point in hardware, except maybe for the occasional floating point-less embedded ARM or maybe MIPS, though even still, they tend to support "what I expect" in software (heck, just look at Apple's original 6502 and 68000 IEEE 754 software environments "SANE"). REAL is typically 32 bits. LONGREAL is much more useful, 64 bits total, 53 bits of mantissa. Heck, anything more than 31 bits of mantissa is a win. EXTENDED is the same as LONGREAL. All you have to do to get an unhandled exception is use the file open gui in formedit or such and browse to a directory with a large file. It's quite lame. Granted what Olaf said -- works fine on 64 bit platforms. On later thought, I'm much less keen on LONGREAL here. LONGINT would still be good though. And then trying to fix NT386 to have a 64bit LONGINT. I am not convinced that Modula-3 is or ever was superior here, in implementation. Yeah, they made a bold statement -- here are our portable interfaces, but they weren't available on many platforms. At the same time, most C systems did document various features, usually not very portable, but perhaps the building blocks of something portable. It's just that you have/had to read a lot of documentation, test it out, etc. Someone has to do it as some level. Nothing is free. (Similarly, Modula-3 "portability" lately is greatly aided by Posix/pthreads standard/implementation catching up.) C is getting better here, what with #pragma fenv and such. And again, you could always dig into the system-specific details. The real art that I don't fully understand, is how to specify "portable interfaces" that you "know" will be viable to implement "everywhere". Just what is nearly exactly the same "everywhere" that you know you'll be able to fill in the details later? Maybe it is survey lots of systems?? But, again, "lots" isn't many any longer. Heck, it's basically just Linux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhile, my list still includes Tru64/Alpha, VMS/Alpha, maybe VMS/IA64, AIX/32, AIX/64, IRIX/32, IRIX/64, etc.. to get running... :) ) That is -- really -- we probably should try to implement all that FloatMode stuff. - Jay > To: jay.krell at cornell.edu > Date: Tue, 23 Jun 2009 02:54:47 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > > Also, making file handling code depend on the presence of IEEE floating > point seems rather odd... As far as I know there is nothing in Modula-3 > that bans implementing REAL with single precision arithmetic? > > By the way I think it's sad that Modula-3's wonderful floating-point > support has attracted so much bit rot. I think it's better than just > about any other programming language (except maybe some Fortran > dialects?) > > Mika > > Jay writes: > > > >Hm..I'm not sure. > >Integers have certain properties, like dividing an integer by an integer yield > >s an integer, > >that floating point doesn't. Integer division tends toward zero faster than fl > >oating point division. > >I can try getting it all to compile with LONGINT maybe instead. > >The current behavior is pretty lame. > > > > - Jay > > > >---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 22 Jun 2009 12:58:17 +0000 > >> Subject: [M3devel] files larger than 2gig > >> > >> > >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 > >> > >> > >> TYPE > >> Status = RECORD > >> type: Type; > >> modificationTime: Time.T; > >> size: INTEGER; > >> END; > >> > >> > >> size: INTEGER causes exceptions when you use the Modula-3 gui > >> and browse to a directory with files larger than 2 gig. > >> > >> > >> I suggest size be changed to LONGREAL, which generally has a 53 bit mantissa > >> (out 64 bits total) and thus can represent integers very much larger than IN > >TEGER. > >> > >> > >> LONGINT is a tempting option but doesn't help on the current NT386 platform, > >> and I think 53 bits will last a very long time. > >> > >> > >> I'm just trying out such a change and I can see it is not source compatible: > >> > >> > >> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN > >> "../src/rw/FileRd.m3", line 140: types are not assignable > >> 2 errors encountered > >> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN > >> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX > >> 2 errors encountered > >> > >> > >> Nevertheless I think it should be done, probably even for this release. > >> > >> > >> - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Jun 23 13:20:53 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 23 Jun 2009 04:20:53 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: Your message of "Tue, 23 Jun 2009 11:02:26 -0000." Message-ID: <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> Jay, Just a few comments... I do have some interest in the Modula-3 implementation on the Caltech Mosaic-C (which has no floating point). M3 has run on this before---I have an old M3 compiler for it. More in general, M3 is a very nice language to bring up on new hardware. Requiring the presence of floating point makes that much more difficult. EXTENDED really should not be 64 bits. It should be 80 bits or perhaps (on some archs) 128 bits. On x86 it should definitely be 80 bits, since that is the only precision actually supported by Intel hardware. Not only would the the answers have more bits of precision but the hardware would actually run faster in many cases! (Long double is 80 bits under gcc on my FreeBSDs.) Finally my understanding is that when M3 was developed, Bill Kahan sent over one of his grad students to work on the floating point. That is what all those weird FP interfaces are about. They're not so much about portability as they are about completeness---from the point of view of the person developing numerical methods. If you read Kahan's rants about how FP "should be done" you can see that the M-3 Float interfaces closely follow the rants. I don't think they're expected to work on all hardware, only on systems that have reasonably powerful floating point (IEEE, VAX, System/370?) Mika Jay writes: >--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Every modern system implements IEEE 754 binary floating point in hardware= >=2C except maybe for the occasional floating point-less embedded ARM or may= >be MIPS=2C though even still=2C they tend to support "what I expect" in sof= >tware (heck=2C just look at Apple's original 6502 and 68000 IEEE 754 softwa= >re environments "SANE"). > > >=20 > >REAL is typically 32 bits. > >LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >=2C anything more than 31 bits of mantissa is a win. > >EXTENDED is the same as LONGREAL. > >=20 > >=20 > >All you have to do to get an unhandled exception is use the file open gui i= >n formedit or such and browse to a directory with a large file. It's quite = >lame. > >=20 > >=20 > >Granted what Olaf said -- works fine on 64 bit platforms. > >=20 > >=20 > >On later thought=2C I'm much less keen on LONGREAL here. LONGINT would stil= >l be good though. > >And then trying to fix NT386 to have a 64bit LONGINT. > >=20 > >=20 > >I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >ntation. Yeah=2C they made a bold statement -- here are our portable interf= >aces=2C but they weren't available on many platforms. At the same time=2C m= >ost C systems did document various features=2C usually not very portable=2C= > but perhaps the building blocks of something portable. > >It's just that you have/had to read a lot of documentation=2C test it out= >=2C etc. Someone has to do it as some level. Nothing is free. > >(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >ads standard/implementation catching up.) > >=20 > >=20 > >C is getting better here=2C what with #pragma fenv and such. > >And again=2C you could always dig into the system-specific details. > >=20 > >=20 > >The real art that I don't fully understand=2C is how to specify "portable i= >nterfaces" that you "know" will be viable to implement "everywhere". Just w= >hat is nearly exactly the same "everywhere" that you know you'll be able to= > fill in the details later? Maybe it is survey lots of systems?? > >But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) > >=20 > >=20 > >That is -- really -- we probably should try to implement all that FloatMode= > stuff. > >=20 > > > - Jay > > >=20 >> To: jay.krell at cornell.edu >> Date: Tue=2C 23 Jun 2009 02:54:47 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] files larger than 2gig >>=20 >>=20 >> Also=2C making file handling code depend on the presence of IEEE floating >> point seems rather odd... As far as I know there is nothing in Modula-3 >> that bans implementing REAL with single precision arithmetic? >>=20 >> By the way I think it's sad that Modula-3's wonderful floating-point >> support has attracted so much bit rot. I think it's better than just >> about any other programming language (except maybe some Fortran >> dialects?) >>=20 >> Mika >>=20 >> Jay writes: >> > >> >Hm..I'm not sure. >> >Integers have certain properties=2C like dividing an integer by an integ= >er yield >> >s an integer=2C >> >that floating point doesn't. Integer division tends toward zero faster t= >han fl >> >oating point division. >> >I can try getting it all to compile with LONGINT maybe instead. >> >The current behavior is pretty lame. >> > >> > - Jay >> > >> >---------------------------------------- >> >> From: jay.krell at cornell.edu >> >> To: m3devel at elegosoft.com >> >> Date: Mon=2C 22 Jun 2009 12:58:17 +0000 >> >> Subject: [M3devel] files larger than 2gig >> >> >> >> >> >> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >> >> >> >> >> >> TYPE >> >> Status =3D RECORD >> >> type: Type=3B >> >> modificationTime: Time.T=3B >> >> size: INTEGER=3B >> >> END=3B >> >> >> >> >> >> size: INTEGER causes exceptions when you use the Modula-3 gui >> >> and browse to a directory with files larger than 2 gig. >> >> >> >> >> >> I suggest size be changed to LONGREAL=2C which generally has a 53 bit = >mantissa >> >> (out 64 bits total) and thus can represent integers very much larger t= >han IN >> >TEGER. >> >> >> >> >> >> LONGINT is a tempting option but doesn't help on the current NT386 pla= >tform=2C >> >> and I think 53 bits will last a very long time. >> >> >> >> >> >> I'm just trying out such a change and I can see it is not source compa= >tible: >> >> >> >> >> >> "../src/rw/FileRd.m3"=2C line 73: incompatible argument types: MIN >> >> "../src/rw/FileRd.m3"=2C line 140: types are not assignable >> >> 2 errors encountered >> >> "../src/rw/FileWr.m3"=2C line 87: incompatible argument types: MIN >> >> "../src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >> >> 2 errors encountered >> >> >> >> >> >> Nevertheless I think it should be done=2C probably even for this relea= >se. >> >> >> >> >> >> - Jay > >--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Every modern system implements IEEE 754 binary floating point in hardware= >=2C except maybe for the occasional floating point-less embedded ARM or may= >be MIPS=2C though even still=2C they tend to support "what =3BI expect"= > in software (heck=2C just look at Apple's original 6502 and 68000 IEEE 754= > software environments "SANE").

> =3B
>REAL is typically =3B32 bits.
>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >=2C anything more than 31 bits of mantissa is a win.
>EXTENDED is the same as LONGREAL.
> =3B
> =3B
>All you have to do to get an unhandled exception is use the file open gui i= >n formedit or such and browse to a directory with a large file. It's quite = >lame.
> =3B
> =3B
>Granted what Olaf said -- works fine on 64 bit platforms.
> =3B
> =3B
>On later =3Bthought=2C I'm much less keen on LONGREAL here. LONGINT wou= >ld still be good though.
>And then trying to fix NT386 to have a 64bit LONGINT.
> =3B
> =3B
>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >ntation. Yeah=2C they made a bold statement -- here are our portable interf= >aces=2C but they weren't available on many =3Bplatforms. At the same ti= >me=2C most =3BC systems did document various features=2C usually not ve= >ry portable=2C but perhaps the building blocks of something portable.
>It's just that you have/had to read a lot of documentation=2C test it out= >=2C etc. Someone has to do it as some level. Nothing is free.
>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >ads standard/implementation catching up.)
> =3B
> =3B
>C is getting better here=2C what with #pragma fenv and such.
>And again=2C you could always dig into the system-specific details.
> =3B
> =3B
>The real art that I don't fully understand=2C is how to specify "portable i= >nterfaces" that you "know" will be viable to implement "everywhere". Just w= >hat is nearly exactly the same "everywhere" that you know you'll be able to= > fill in the details later? Maybe it is survey lots of systems??
>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) )
> =3B
> =3B
>That is -- really -- we probably should try to implement all that FloatMode= > stuff.
> =3B
>
 =3B- Jay
>
 =3B
>=3B To: jay.krell at cornell.edu
>=3B Date: Tue=2C 23 = >Jun 2009 02:54:47 -0700
>=3B From: mika at async.caltech.edu
>=3B CC= >: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] files larger than = >2gig
>=3B
>=3B
>=3B Also=2C making file handling code depe= >nd on the presence of IEEE floating
>=3B point seems rather odd... As = >far as I know there is nothing in Modula-3
>=3B that bans implementing= > REAL with single precision arithmetic?
>=3B
>=3B By the way I t= >hink it's sad that Modula-3's wonderful floating-point
>=3B support ha= >s attracted so much bit rot. I think it's better than just
>=3B about = >any other programming language (except maybe some Fortran
>=3B dialect= >s?)
>=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B &g= >t=3B
>=3B >=3BHm..I'm not sure.
>=3B >=3BIntegers have certai= >n properties=2C like dividing an integer by an integer yield
>=3B >= >=3Bs an integer=2C
>=3B >=3Bthat floating point doesn't. Integer div= >ision tends toward zero faster than fl
>=3B >=3Boating point divisio= >n.
>=3B >=3BI can try getting it all to compile with LONGINT maybe i= >nstead.
>=3B >=3BThe current behavior is pretty lame.
>=3B >= >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B---------------= >-------------------------
>=3B >=3B>=3B From: jay.krell at cornell.ed= >u
>=3B >=3B>=3B To: m3devel at elegosoft.com
>=3B >=3B>=3B D= >ate: Mon=2C 22 Jun 2009 12:58:17 +0000
>=3B >=3B>=3B Subject: [M3d= >evel] files larger than 2gig
>=3B >=3B>=3B
>=3B >=3B>=3B<= >BR>>=3B >=3B>=3B C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3>>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B TYPE
= >>=3B >=3B>=3B Status =3D RECORD
>=3B >=3B>=3B type: Type=3B<= >BR>>=3B >=3B>=3B modificationTime: Time.T=3B
>=3B >=3B>=3B s= >ize: INTEGER=3B
>=3B >=3B>=3B END=3B
>=3B >=3B>=3B
>= >=3B >=3B>=3B
>=3B >=3B>=3B size: INTEGER causes exceptions whe= >n you use the Modula-3 gui
>=3B >=3B>=3B and browse to a directory= > with files larger than 2 gig.
>=3B >=3B>=3B
>=3B >=3B>= >=3B
>=3B >=3B>=3B I suggest size be changed to LONGREAL=2C which g= >enerally has a 53 bit mantissa
>=3B >=3B>=3B (out 64 bits total) a= >nd thus can represent integers very much larger than IN
>=3B >=3BTEG= >ER.
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B LO= >NGINT is a tempting option but doesn't help on the current NT386 platform= >=2C
>=3B >=3B>=3B and I think 53 bits will last a very long time.<= >BR>>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B I'm ju= >st trying out such a change and I can see it is not source compatible:
&= >gt=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B "../src/rw= >/FileRd.m3"=2C line 73: incompatible argument types: MIN
>=3B >=3B&g= >t=3B "../src/rw/FileRd.m3"=2C line 140: types are not assignable
>=3B = >>=3B>=3B 2 errors encountered
>=3B >=3B>=3B "../src/rw/FileWr.= >m3"=2C line 87: incompatible argument types: MIN
>=3B >=3B>=3B "..= >/src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX
>=3B = >>=3B>=3B 2 errors encountered
>=3B >=3B>=3B
>=3B >=3B&g= >t=3B
>=3B >=3B>=3B Nevertheless I think it should be done=2C proba= >bly even for this release.
>=3B >=3B>=3B
>=3B >=3B>=3B>>=3B >=3B>=3B - Jay
>= > >--_263ab327-88e7-4d2a-89fb-ad414fed2458_-- From jay.krell at cornell.edu Tue Jun 23 13:27:33 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 23 Jun 2009 11:27:33 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> References: Your message of "Tue, 23 Jun 2009 11:02:26 -0000." <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> Message-ID: Mika, floating point is, for better or worse, deep in Modula-3. I was surprised. The garbage collector uses it. So you'll need software floating point or somesuch. Or maybe you can change the code to use fixed point. Probably not a bad idea. But also Time.T is LONGREAL. Though again, maybe that's dubious. NT has as good time representation. It is 64bit integers, something like measured in 10,000 nanosecond units since 1601. The .NET runtime uses the same unit of precision, but starts at year 0. Time.T splits up easily into Unix seconds + milli or microseconds. Of course, all those 32bit second things are broken. I know the x87 uses 80 bit floating point numbers in hardware, but there is also SSE/SSE2/SSE3/whatever now, that might be different, and faster. You know, they have actual "registers" instead of a register stack. If you have some floating point intensive code, you might try it. More info on the Mosiac-C? I'll search the web. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Tue, 23 Jun 2009 04:20:53 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > Jay, > > Just a few comments... > > I do have some interest in the Modula-3 implementation on the Caltech > Mosaic-C (which has no floating point). M3 has run on this before---I > have an old M3 compiler for it. More in general, M3 is a very nice > language to bring up on new hardware. Requiring the presence of > floating point makes that much more difficult. > > EXTENDED really should not be 64 bits. It should be 80 bits or > perhaps (on some archs) 128 bits. On x86 it should definitely be > 80 bits, since that is the only precision actually supported by > Intel hardware. Not only would the the answers have more bits of > precision but the hardware would actually run faster in many cases! > (Long double is 80 bits under gcc on my FreeBSDs.) > > Finally my understanding is that when M3 was developed, Bill Kahan > sent over one of his grad students to work on the floating point. > That is what all those weird FP interfaces are about. They're not > so much about portability as they are about completeness---from the > point of view of the person developing numerical methods. If you > read Kahan's rants about how FP "should be done" you can see that > the M-3 Float interfaces closely follow the rants. I don't think > they're expected to work on all hardware, only on systems that have > reasonably powerful floating point (IEEE, VAX, System/370?) > > Mika > > > Jay writes: >>--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >>Content-Type: text/plain; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >>Every modern system implements IEEE 754 binary floating point in hardware= >>=2C except maybe for the occasional floating point-less embedded ARM or may= >>be MIPS=2C though even still=2C they tend to support "what I expect" in sof= >>tware (heck=2C just look at Apple's original 6502 and 68000 IEEE 754 softwa= >>re environments "SANE"). >> >> >>=20 >> >>REAL is typically 32 bits. >> >>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >>=2C anything more than 31 bits of mantissa is a win. >> >>EXTENDED is the same as LONGREAL. >> >>=20 >> >>=20 >> >>All you have to do to get an unhandled exception is use the file open gui i= >>n formedit or such and browse to a directory with a large file. It's quite = >>lame. >> >>=20 >> >>=20 >> >>Granted what Olaf said -- works fine on 64 bit platforms. >> >>=20 >> >>=20 >> >>On later thought=2C I'm much less keen on LONGREAL here. LONGINT would stil= >>l be good though. >> >>And then trying to fix NT386 to have a 64bit LONGINT. >> >>=20 >> >>=20 >> >>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >>ntation. Yeah=2C they made a bold statement -- here are our portable interf= >>aces=2C but they weren't available on many platforms. At the same time=2C m= >>ost C systems did document various features=2C usually not very portable=2C= >> but perhaps the building blocks of something portable. >> >>It's just that you have/had to read a lot of documentation=2C test it out= >>=2C etc. Someone has to do it as some level. Nothing is free. >> >>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >>ads standard/implementation catching up.) >> >>=20 >> >>=20 >> >>C is getting better here=2C what with #pragma fenv and such. >> >>And again=2C you could always dig into the system-specific details. >> >>=20 >> >>=20 >> >>The real art that I don't fully understand=2C is how to specify "portable i= >>nterfaces" that you "know" will be viable to implement "everywhere". Just w= >>hat is nearly exactly the same "everywhere" that you know you'll be able to= >> fill in the details later? Maybe it is survey lots of systems?? >> >>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) >> >>=20 >> >>=20 >> >>That is -- really -- we probably should try to implement all that FloatMode= >> stuff. >> >>=20 >> >> >> - Jay >> >> >>=20 >>> To: jay.krell at cornell.edu >>> Date: Tue=2C 23 Jun 2009 02:54:47 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] files larger than 2gig >>>=20 >>>=20 >>> Also=2C making file handling code depend on the presence of IEEE floating >>> point seems rather odd... As far as I know there is nothing in Modula-3 >>> that bans implementing REAL with single precision arithmetic? >>>=20 >>> By the way I think it's sad that Modula-3's wonderful floating-point >>> support has attracted so much bit rot. I think it's better than just >>> about any other programming language (except maybe some Fortran >>> dialects?) >>>=20 >>> Mika >>>=20 >>> Jay writes: >>>> >>>>Hm..I'm not sure. >>>>Integers have certain properties=2C like dividing an integer by an integ= >>er yield >>>>s an integer=2C >>>>that floating point doesn't. Integer division tends toward zero faster t= >>han fl >>>>oating point division. >>>>I can try getting it all to compile with LONGINT maybe instead. >>>>The current behavior is pretty lame. >>>> >>>> - Jay >>>> >>>>---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Mon=2C 22 Jun 2009 12:58:17 +0000 >>>>> Subject: [M3devel] files larger than 2gig >>>>> >>>>> >>>>> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >>>>> >>>>> >>>>> TYPE >>>>> Status =3D RECORD >>>>> type: Type=3B >>>>> modificationTime: Time.T=3B >>>>> size: INTEGER=3B >>>>> END=3B >>>>> >>>>> >>>>> size: INTEGER causes exceptions when you use the Modula-3 gui >>>>> and browse to a directory with files larger than 2 gig. >>>>> >>>>> >>>>> I suggest size be changed to LONGREAL=2C which generally has a 53 bit = >>mantissa >>>>> (out 64 bits total) and thus can represent integers very much larger t= >>han IN >>>>TEGER. >>>>> >>>>> >>>>> LONGINT is a tempting option but doesn't help on the current NT386 pla= >>tform=2C >>>>> and I think 53 bits will last a very long time. >>>>> >>>>> >>>>> I'm just trying out such a change and I can see it is not source compa= >>tible: >>>>> >>>>> >>>>> "../src/rw/FileRd.m3"=2C line 73: incompatible argument types: MIN >>>>> "../src/rw/FileRd.m3"=2C line 140: types are not assignable >>>>> 2 errors encountered >>>>> "../src/rw/FileWr.m3"=2C line 87: incompatible argument types: MIN >>>>> "../src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >>>>> 2 errors encountered >>>>> >>>>> >>>>> Nevertheless I think it should be done=2C probably even for this relea= >>se. >>>>> >>>>> >>>>> - Jay >> >>--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >>Content-Type: text/html; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >>Every modern system implements IEEE 754 binary floating point in hardware= >>=2C except maybe for the occasional floating point-less embedded ARM or may= >>be MIPS=2C though even still=2C they tend to support "what =3BI expect"= >> in software (heck=2C just look at Apple's original 6502 and 68000 IEEE 754= >> software environments "SANE"). >> =3B >>REAL is typically =3B32 bits. >>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >>=2C anything more than 31 bits of mantissa is a win. >>EXTENDED is the same as LONGREAL. >> =3B >> =3B >>All you have to do to get an unhandled exception is use the file open gui i= >>n formedit or such and browse to a directory with a large file. It's quite = >>lame. >> =3B >> =3B >>Granted what Olaf said -- works fine on 64 bit platforms. >> =3B >> =3B >>On later =3Bthought=2C I'm much less keen on LONGREAL here. LONGINT wou= >>ld still be good though. >>And then trying to fix NT386 to have a 64bit LONGINT. >> =3B >> =3B >>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >>ntation. Yeah=2C they made a bold statement -- here are our portable interf= >>aces=2C but they weren't available on many =3Bplatforms. At the same ti= >>me=2C most =3BC systems did document various features=2C usually not ve= >>ry portable=2C but perhaps the building blocks of something portable. >>It's just that you have/had to read a lot of documentation=2C test it out= >>=2C etc. Someone has to do it as some level. Nothing is free. >>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >>ads standard/implementation catching up.) >> =3B >> =3B >>C is getting better here=2C what with #pragma fenv and such. >>And again=2C you could always dig into the system-specific details. >> =3B >> =3B >>The real art that I don't fully understand=2C is how to specify "portable i= >>nterfaces" that you "know" will be viable to implement "everywhere". Just w= >>hat is nearly exactly the same "everywhere" that you know you'll be able to= >> fill in the details later? Maybe it is survey lots of systems?? >>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) >> =3B >> =3B >>That is -- really -- we probably should try to implement all that FloatMode= >> stuff. >> =3B >> =3B- Jay >> =3B >=3B To: jay.krell at cornell.edu >=3B Date: Tue=2C 23 = >>Jun 2009 02:54:47 -0700 >=3B From: mika at async.caltech.edu >=3B CC= >>: m3devel at elegosoft.com >=3B Subject: Re: [M3devel] files larger than = >>2gig >=3B >=3B >=3B Also=2C making file handling code depe= >>nd on the presence of IEEE floating >=3B point seems rather odd... As = >>far as I know there is nothing in Modula-3 >=3B that bans implementing= >> REAL with single precision arithmetic? >=3B >=3B By the way I t= >>hink it's sad that Modula-3's wonderful floating-point >=3B support ha= >>s attracted so much bit rot. I think it's better than just >=3B about = >>any other programming language (except maybe some Fortran >=3B dialect= >>s?) >=3B >=3B Mika >=3B >=3B Jay writes: >=3B &g= >>t=3B >=3B>=3BHm..I'm not sure. >=3B>=3BIntegers have certai= >>n properties=2C like dividing an integer by an integer yield >=3B>= >>=3Bs an integer=2C >=3B>=3Bthat floating point doesn't. Integer div= >>ision tends toward zero faster than fl >=3B>=3Boating point divisio= >>n. >=3B>=3BI can try getting it all to compile with LONGINT maybe i= >>nstead. >=3B>=3BThe current behavior is pretty lame. >=3B>= >>=3B >=3B>=3B - Jay >=3B>=3B >=3B>=3B---------------= >>------------------------- >=3B>=3B>=3B From: jay.krell at cornell.ed= >>u >=3B>=3B>=3B To: m3devel at elegosoft.com >=3B>=3B>=3B D= >>ate: Mon=2C 22 Jun 2009 12:58:17 +0000 >=3B>=3B>=3B Subject: [M3d= >>evel] files larger than 2gig >=3B>=3B>=3B >=3B>=3B>=3B<= >>BR>>=3B>=3B>=3B C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3>>>>=3B>=3B>=3B >=3B>=3B>=3B >=3B>=3B>=3B TYPE = >>>=3B>=3B>=3B Status =3D RECORD >=3B>=3B>=3B type: Type=3B<= >>BR>>=3B>=3B>=3B modificationTime: Time.T=3B >=3B>=3B>=3B s= >>ize: INTEGER=3B >=3B>=3B>=3B END=3B >=3B>=3B>=3B >= >>=3B>=3B>=3B >=3B>=3B>=3B size: INTEGER causes exceptions whe= >>n you use the Modula-3 gui >=3B>=3B>=3B and browse to a directory= >> with files larger than 2 gig. >=3B>=3B>=3B >=3B>=3B>= >>=3B >=3B>=3B>=3B I suggest size be changed to LONGREAL=2C which g= >>enerally has a 53 bit mantissa >=3B>=3B>=3B (out 64 bits total) a= >>nd thus can represent integers very much larger than IN >=3B>=3BTEG= >>ER. >=3B>=3B>=3B >=3B>=3B>=3B >=3B>=3B>=3B LO= >>NGINT is a tempting option but doesn't help on the current NT386 platform= >>=2C >=3B>=3B>=3B and I think 53 bits will last a very long time.<= >>BR>>=3B>=3B>=3B >=3B>=3B>=3B >=3B>=3B>=3B I'm ju= >>st trying out such a change and I can see it is not source compatible: &= >>gt=3B>=3B>=3B >=3B>=3B>=3B >=3B>=3B>=3B "../src/rw= >>/FileRd.m3"=2C line 73: incompatible argument types: MIN >=3B>=3B&g= >>t=3B "../src/rw/FileRd.m3"=2C line 140: types are not assignable >=3B = >>>=3B>=3B 2 errors encountered >=3B>=3B>=3B "../src/rw/FileWr.= >>m3"=2C line 87: incompatible argument types: MIN >=3B>=3B>=3B "..= >>/src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >=3B = >>>=3B>=3B 2 errors encountered >=3B>=3B>=3B >=3B>=3B&g= >>t=3B >=3B>=3B>=3B Nevertheless I think it should be done=2C proba= >>bly even for this release. >=3B>=3B>=3B >=3B>=3B>=3B>>>>=3B>=3B>=3B - Jay >>= >> >>--_263ab327-88e7-4d2a-89fb-ad414fed2458_-- From jay.krell at cornell.edu Tue Jun 23 13:43:11 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 23 Jun 2009 11:43:11 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Your message of "Tue, 23 Jun 2009 11:02:26 -0000." <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> Message-ID: And on that note, here is the status on I386_INTERIX, using a native cm3. :) --- building in I386_INTERIX --- ignoring ../src/m3overrides new source -> compiling SchedulerPosix.i3 Program received signal SIGSEGV, Segmentation fault. 0x00717e52 in ?? () (gdb) bt #0 0x00717e52 in ?? () #1 0x0046e28c in Convert__InternalFromLongFloat () #2 0x0046db4d in Convert__FromExtended () #3 0x004edb03 in M3Buf__PutFloat () #4 0x0062c20a in ReelExpr__GenFPLiteral () #5 0x004991bc in Expr__GenFPLiteral () #6 0x004b5702 in Formal__AddFPTag () #7 0x006f4983 in Value__AddFPTag () #8 0x005cc021 in ProcType__FPrinter () #9 0x006e801a in TypeFP__Visit_SCC () #10 0x006e7daa in TypeFP__FromType () #11 0x006e299d in Type__GlobalUID () #12 0x006eb0a9 in TypeTbl__Put () #13 0x006e2bb5 in Type__Compile () #14 0x006e2b1f in Type__CompileAll () #15 0x0057192f in Module__Compile () #16 0x00527171 in M3Front__DoCompile () #17 0x005266a4 in M3Front__Compile () #18 0x0042cd62 in Builder__RunM3 () #19 0x0042b2a9 in Builder__PushOneM3 () #20 0x0042ae8e in Builder__CompileM3 () #21 0x00429916 in Builder__CompileOne () #22 0x004295b1 in Builder__CompileEverything () #23 0x004254ef in Builder__CompileUnits () #24 0x00423c0e in Builder__BuildLib () #25 0x004f4ac6 in M3Build__DoLibrary () #26 0x005dc1cf in QMachine__DoCall () #27 0x005db078 in QMachine__Eval () #28 0x005e3bad in QMachine () #29 0x005e39e5 in QMachine () #30 0x004f1296 in M3Build () #31 0x004f2da5 in M3Build__DoIncludeDir () #32 0x005dc1cf in QMachine__DoCall () #33 0x005db078 in QMachine__Eval () #34 0x005d9895 in QMachine__Evaluate () #35 0x005f1d8e in Quake__Run () #36 0x004ef4d6 in M3Build__Run () #37 0x0055c172 in Main__DoIt () - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > Date: Tue, 23 Jun 2009 11:27:33 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > > Mika, floating point is, for better or worse, deep in Modula-3. > I was surprised. The garbage collector uses it. > So you'll need software floating point or somesuch. > Or maybe you can change the code to use fixed point. > Probably not a bad idea. > > > But also Time.T is LONGREAL. > Though again, maybe that's dubious. > NT has as good time representation. > It is 64bit integers, something like measured in 10,000 nanosecond > units since 1601. > The .NET runtime uses the same unit of precision, but starts at year 0. > > Time.T splits up easily into Unix seconds + milli or microseconds. > Of course, all those 32bit second things are broken. > > > I know the x87 uses 80 bit floating point numbers in hardware, > but there is also SSE/SSE2/SSE3/whatever now, that might be > different, and faster. > You know, they have actual "registers" instead of a register stack. > If you have some floating point intensive code, you might try it. > > > More info on the Mosiac-C? > I'll search the web. > > - Jay > > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Tue, 23 Jun 2009 04:20:53 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] files larger than 2gig >> >> Jay, >> >> Just a few comments... >> >> I do have some interest in the Modula-3 implementation on the Caltech >> Mosaic-C (which has no floating point). M3 has run on this before---I >> have an old M3 compiler for it. More in general, M3 is a very nice >> language to bring up on new hardware. Requiring the presence of >> floating point makes that much more difficult. >> >> EXTENDED really should not be 64 bits. It should be 80 bits or >> perhaps (on some archs) 128 bits. On x86 it should definitely be >> 80 bits, since that is the only precision actually supported by >> Intel hardware. Not only would the the answers have more bits of >> precision but the hardware would actually run faster in many cases! >> (Long double is 80 bits under gcc on my FreeBSDs.) >> >> Finally my understanding is that when M3 was developed, Bill Kahan >> sent over one of his grad students to work on the floating point. >> That is what all those weird FP interfaces are about. They're not >> so much about portability as they are about completeness---from the >> point of view of the person developing numerical methods. If you >> read Kahan's rants about how FP "should be done" you can see that >> the M-3 Float interfaces closely follow the rants. I don't think >> they're expected to work on all hardware, only on systems that have >> reasonably powerful floating point (IEEE, VAX, System/370?) >> >> Mika >> >> >> Jay writes: >>>--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >>>Content-Type: text/plain; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>>Every modern system implements IEEE 754 binary floating point in hardware= >>>=2C except maybe for the occasional floating point-less embedded ARM or may= >>>be MIPS=2C though even still=2C they tend to support "what I expect" in sof= >>>tware (heck=2C just look at Apple's original 6502 and 68000 IEEE 754 softwa= >>>re environments "SANE"). >>> >>> >>>=20 >>> >>>REAL is typically 32 bits. >>> >>>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >>>=2C anything more than 31 bits of mantissa is a win. >>> >>>EXTENDED is the same as LONGREAL. >>> >>>=20 >>> >>>=20 >>> >>>All you have to do to get an unhandled exception is use the file open gui i= >>>n formedit or such and browse to a directory with a large file. It's quite = >>>lame. >>> >>>=20 >>> >>>=20 >>> >>>Granted what Olaf said -- works fine on 64 bit platforms. >>> >>>=20 >>> >>>=20 >>> >>>On later thought=2C I'm much less keen on LONGREAL here. LONGINT would stil= >>>l be good though. >>> >>>And then trying to fix NT386 to have a 64bit LONGINT. >>> >>>=20 >>> >>>=20 >>> >>>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >>>ntation. Yeah=2C they made a bold statement -- here are our portable interf= >>>aces=2C but they weren't available on many platforms. At the same time=2C m= >>>ost C systems did document various features=2C usually not very portable=2C= >>> but perhaps the building blocks of something portable. >>> >>>It's just that you have/had to read a lot of documentation=2C test it out= >>>=2C etc. Someone has to do it as some level. Nothing is free. >>> >>>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >>>ads standard/implementation catching up.) >>> >>>=20 >>> >>>=20 >>> >>>C is getting better here=2C what with #pragma fenv and such. >>> >>>And again=2C you could always dig into the system-specific details. >>> >>>=20 >>> >>>=20 >>> >>>The real art that I don't fully understand=2C is how to specify "portable i= >>>nterfaces" that you "know" will be viable to implement "everywhere". Just w= >>>hat is nearly exactly the same "everywhere" that you know you'll be able to= >>> fill in the details later? Maybe it is survey lots of systems?? >>> >>>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >>>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >>>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >>>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) >>> >>>=20 >>> >>>=20 >>> >>>That is -- really -- we probably should try to implement all that FloatMode= >>> stuff. >>> >>>=20 >>> >>> >>> - Jay >>> >>> >>>=20 >>>> To: jay.krell at cornell.edu >>>> Date: Tue=2C 23 Jun 2009 02:54:47 -0700 >>>> From: mika at async.caltech.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] files larger than 2gig >>>>=20 >>>>=20 >>>> Also=2C making file handling code depend on the presence of IEEE floating >>>> point seems rather odd... As far as I know there is nothing in Modula-3 >>>> that bans implementing REAL with single precision arithmetic? >>>>=20 >>>> By the way I think it's sad that Modula-3's wonderful floating-point >>>> support has attracted so much bit rot. I think it's better than just >>>> about any other programming language (except maybe some Fortran >>>> dialects?) >>>>=20 >>>> Mika >>>>=20 >>>> Jay writes: >>>>> >>>>>Hm..I'm not sure. >>>>>Integers have certain properties=2C like dividing an integer by an integ= >>>er yield >>>>>s an integer=2C >>>>>that floating point doesn't. Integer division tends toward zero faster t= >>>han fl >>>>>oating point division. >>>>>I can try getting it all to compile with LONGINT maybe instead. >>>>>The current behavior is pretty lame. >>>>> >>>>> - Jay >>>>> >>>>>---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: m3devel at elegosoft.com >>>>>> Date: Mon=2C 22 Jun 2009 12:58:17 +0000 >>>>>> Subject: [M3devel] files larger than 2gig >>>>>> >>>>>> >>>>>> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3 >>>>>> >>>>>> >>>>>> TYPE >>>>>> Status =3D RECORD >>>>>> type: Type=3B >>>>>> modificationTime: Time.T=3B >>>>>> size: INTEGER=3B >>>>>> END=3B >>>>>> >>>>>> >>>>>> size: INTEGER causes exceptions when you use the Modula-3 gui >>>>>> and browse to a directory with files larger than 2 gig. >>>>>> >>>>>> >>>>>> I suggest size be changed to LONGREAL=2C which generally has a 53 bit = >>>mantissa >>>>>> (out 64 bits total) and thus can represent integers very much larger t= >>>han IN >>>>>TEGER. >>>>>> >>>>>> >>>>>> LONGINT is a tempting option but doesn't help on the current NT386 pla= >>>tform=2C >>>>>> and I think 53 bits will last a very long time. >>>>>> >>>>>> >>>>>> I'm just trying out such a change and I can see it is not source compa= >>>tible: >>>>>> >>>>>> >>>>>> "../src/rw/FileRd.m3"=2C line 73: incompatible argument types: MIN >>>>>> "../src/rw/FileRd.m3"=2C line 140: types are not assignable >>>>>> 2 errors encountered >>>>>> "../src/rw/FileWr.m3"=2C line 87: incompatible argument types: MIN >>>>>> "../src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >>>>>> 2 errors encountered >>>>>> >>>>>> >>>>>> Nevertheless I think it should be done=2C probably even for this relea= >>>se. >>>>>> >>>>>> >>>>>> - Jay >>> >>>--_263ab327-88e7-4d2a-89fb-ad414fed2458_ >>>Content-Type: text/html; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>> >>> > > >>> >>> >>>Every modern system implements IEEE 754 binary floating point in hardware= >>>=2C except maybe for the occasional floating point-less embedded ARM or may= >>>be MIPS=2C though even still=2C they tend to support "what =3BI expect"= >>> in software (heck=2C just look at Apple's original 6502 and 68000 IEEE 754= >>> software environments "SANE"). > > >>> =3B > >>>REAL is typically =3B32 bits. > >>>LONGREAL is much more useful=2C 64 bits total=2C 53 bits of mantissa. Heck= >>>=2C anything more than 31 bits of mantissa is a win. > >>>EXTENDED is the same as LONGREAL. > >>> =3B > >>> =3B > >>>All you have to do to get an unhandled exception is use the file open gui i= >>>n formedit or such and browse to a directory with a large file. It's quite = >>>lame. > >>> =3B > >>> =3B > >>>Granted what Olaf said -- works fine on 64 bit platforms. > >>> =3B > >>> =3B > >>>On later =3Bthought=2C I'm much less keen on LONGREAL here. LONGINT wou= >>>ld still be good though. > >>>And then trying to fix NT386 to have a 64bit LONGINT. > >>> =3B > >>> =3B > >>>I am not convinced that Modula-3 is or ever was superior here=2C in impleme= >>>ntation. Yeah=2C they made a bold statement -- here are our portable interf= >>>aces=2C but they weren't available on many =3Bplatforms. At the same ti= >>>me=2C most =3BC systems did document various features=2C usually not ve= >>>ry portable=2C but perhaps the building blocks of something portable. > >>>It's just that you have/had to read a lot of documentation=2C test it out= >>>=2C etc. Someone has to do it as some level. Nothing is free. > >>>(Similarly=2C Modula-3 "portability" lately is greatly aided by Posix/pthre= >>>ads standard/implementation catching up.) > >>> =3B > >>> =3B > >>>C is getting better here=2C what with #pragma fenv and such. > >>>And again=2C you could always dig into the system-specific details. > >>> =3B > >>> =3B > >>>The real art that I don't fully understand=2C is how to specify "portable i= >>>nterfaces" that you "know" will be viable to implement "everywhere". Just w= >>>hat is nearly exactly the same "everywhere" that you know you'll be able to= >>> fill in the details later? Maybe it is survey lots of systems?? > >>>But=2C again=2C "lots" isn't many any longer. Heck=2C it's basically just L= >>>inux and NT. :) Yeah yeah.. I know about the smattering of others. (Meanwhi= >>>le=2C my list still includes Tru64/Alpha=2C VMS/Alpha=2C maybe VMS/IA64=2C = >>>AIX/32=2C AIX/64=2C IRIX/32=2C IRIX/64=2C etc.. to get running... :) ) > >>> =3B > >>> =3B > >>>That is -- really -- we probably should try to implement all that FloatMode= >>> stuff. > >>> =3B > >>> > =3B- Jay > >>> > =3B >>=3B To: jay.krell at cornell.edu >>=3B Date: Tue=2C 23 = >>>Jun 2009 02:54:47 -0700 >>=3B From: mika at async.caltech.edu >>=3B CC= >>>: m3devel at elegosoft.com >>=3B Subject: Re: [M3devel] files larger than = >>>2gig >>=3B >>=3B >>=3B Also=2C making file handling code depe= >>>nd on the presence of IEEE floating >>=3B point seems rather odd... As = >>>far as I know there is nothing in Modula-3 >>=3B that bans implementing= >>> REAL with single precision arithmetic? >>=3B >>=3B By the way I t= >>>hink it's sad that Modula-3's wonderful floating-point >>=3B support ha= >>>s attracted so much bit rot. I think it's better than just >>=3B about = >>>any other programming language (except maybe some Fortran >>=3B dialect= >>>s?) >>=3B >>=3B Mika >>=3B >>=3B Jay writes: >>=3B &g= >>>t=3B >>=3B>=3BHm..I'm not sure. >>=3B>=3BIntegers have certai= >>>n properties=2C like dividing an integer by an integer yield >>=3B>= >>>=3Bs an integer=2C >>=3B>=3Bthat floating point doesn't. Integer div= >>>ision tends toward zero faster than fl >>=3B>=3Boating point divisio= >>>n. >>=3B>=3BI can try getting it all to compile with LONGINT maybe i= >>>nstead. >>=3B>=3BThe current behavior is pretty lame. >>=3B>= >>>=3B >>=3B>=3B - Jay >>=3B>=3B >>=3B>=3B---------------= >>>------------------------- >>=3B>=3B>=3B From: jay.krell at cornell.ed= >>>u >>=3B>=3B>=3B To: m3devel at elegosoft.com >>=3B>=3B>=3B D= >>>ate: Mon=2C 22 Jun 2009 12:58:17 +0000 >>=3B>=3B>=3B Subject: [M3d= >>>evel] files larger than 2gig >>=3B>=3B>=3B >>=3B>=3B>=3B<= >>>BR>>=3B>=3B>=3B C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3>>>>=3B>=3B>=3B >>=3B>=3B>=3B >>=3B>=3B>=3B TYPE > = >>>>=3B>=3B>=3B Status =3D RECORD >>=3B>=3B>=3B type: Type=3B<= >>>BR>>=3B>=3B>=3B modificationTime: Time.T=3B >>=3B>=3B>=3B s= >>>ize: INTEGER=3B >>=3B>=3B>=3B END=3B >>=3B>=3B>=3B >>= >>>=3B>=3B>=3B >>=3B>=3B>=3B size: INTEGER causes exceptions whe= >>>n you use the Modula-3 gui >>=3B>=3B>=3B and browse to a directory= >>> with files larger than 2 gig. >>=3B>=3B>=3B >>=3B>=3B>= >>>=3B >>=3B>=3B>=3B I suggest size be changed to LONGREAL=2C which g= >>>enerally has a 53 bit mantissa >>=3B>=3B>=3B (out 64 bits total) a= >>>nd thus can represent integers very much larger than IN >>=3B>=3BTEG= >>>ER. >>=3B>=3B>=3B >>=3B>=3B>=3B >>=3B>=3B>=3B LO= >>>NGINT is a tempting option but doesn't help on the current NT386 platform= >>>=2C >>=3B>=3B>=3B and I think 53 bits will last a very long time.<= >>>BR>>=3B>=3B>=3B >>=3B>=3B>=3B >>=3B>=3B>=3B I'm ju= >>>st trying out such a change and I can see it is not source compatible: > &= >>>gt=3B>=3B>=3B >>=3B>=3B>=3B >>=3B>=3B>=3B "../src/rw= >>>/FileRd.m3"=2C line 73: incompatible argument types: MIN >>=3B>=3B&g= >>>t=3B "../src/rw/FileRd.m3"=2C line 140: types are not assignable >>=3B = >>>>=3B>=3B 2 errors encountered >>=3B>=3B>=3B "../src/rw/FileWr.= >>>m3"=2C line 87: incompatible argument types: MIN >>=3B>=3B>=3B "..= >>>/src/rw/FileWr.m3"=2C line 103: incompatible argument types: MAX >>=3B = >>>>=3B>=3B 2 errors encountered >>=3B>=3B>=3B >>=3B>=3B&g= >>>t=3B >>=3B>=3B>=3B Nevertheless I think it should be done=2C proba= >>>bly even for this release. >>=3B>=3B>=3B >>=3B>=3B>=3B>>>>=3B>=3B>=3B - Jay > >>>= >>> >>>--_263ab327-88e7-4d2a-89fb-ad414fed2458_-- From jay.krell at cornell.edu Wed Jun 24 02:45:56 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 24 Jun 2009 00:45:56 +0000 Subject: [M3devel] permissions on make-dist.sh? Message-ID: C:\dev2\cm3.2\scripts>cvs -z3 commit -m "fewer packages for Interix until/unless X issue is fixed, and cvsup uses utimes; fix name of birch dot instead of perio d" make-dist.sh /usr/cvs/cm3/scripts/make-dist.sh,v <-- make-dist.sh new revision: 1.13; previous revision: 1.12 cvs [commit aborted]: cannot rename file .new.make-dist.sh to make-dist.sh: Perm ission denied fyi: diff -u -r1.12 make-dist.sh --- make-dist.sh 20 Jun 2009 19:23:31 -0000 1.12 +++ make-dist.sh 24 Jun 2009 00:45:14 -0000 @@ -1,7 +1,7 @@ #bash # $Id: make-dist.sh,v 1.12 2009-06-20 19:23:31 jkrell Exp $ -DESTHOST=${DESTHOST:-birch,elegosoft.com} +DESTHOST=${DESTHOST:-birch.elegosoft.com} if [ -n "$ROOT" -a -d "$ROOT" ] ; then sysinfo="$ROOT/scripts/sysinfo.sh" @@ -40,7 +40,12 @@ M3_PORTABLE_RUN_PATH=1 export M3_PORTABLE_RUN_PATH -PKG_COLLECTIONS="devlib m3devtool m3gdb webdev gui anim database cvsup obliq ju no caltech-parser demo tool math game core" + +if [ `uname` = 'Interix' ]; then + PKG_COLLECTIONS="devlib m3devtool webdev obliq caltech-parser tool math game core" +else + PKG_COLLECTIONS="devlib m3devtool m3gdb webdev gui anim database cvsup obliq juno caltech-parser demo tool math game core" +fi DESC_devlib=' Miscellaneous development libraries From jay.krell at cornell.edu Wed Jun 24 03:09:45 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 24 Jun 2009 01:09:45 +0000 Subject: [M3devel] posixish environment on Windows Message-ID: People who want to use cygwin might look into Interix/SFU/SUA instead. It is a free "beer" download for Windows 2000, XP, 2003 and is included as an optional part of 2003R2, Vista, 2008, Win7. It uses the forward slashes people like. It includes gcc. 3.3 and sort of 4.2. (some versions have both, but I think 3.3 is always the default) You can also use Visual C++ with it but I haven't tried that. It includes ksh. bash and many other GNU tools are available. It includes gdb. There is a Visual Studio debugger addin, I also haven't tried that. Most importantly I think, it has an appropriately fast fork, which makes development much faster. Version 3.5 and newer support pthreads. It has .so files, including -rpath. Though maybe not -soname. It doesn't appear to support dlopen/dlsym. I have to check. These last two points are surprising. It appears to not use regular Windows static imports, link -dump -imports doesn't show much. It has an X Window client. For Modula-3 purposes, I get a few unresolved symbols building the GUI stuff, XShm*, so that isn't available (yet?). It has mixed support from various projects. Modula-3 seems to work ok on it, enough to build itself. Hm, the tests have problems, I'll look into that. There are archives on www.opencm3.net/releng. More are being uploaded. - Jay From jay.krell at cornell.edu Wed Jun 24 04:39:35 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 23 Jun 2009 19:39:35 -0700 Subject: [M3devel] X11 in system_libs? In-Reply-To: <20090623144303.F1B6ECC362@birch.elegosoft.com> References: <20090623144303.F1B6ECC362@birch.elegosoft.com> Message-ID: Should a bunch of packages check if ostype is win32 or x11 is in system_libs, else build nothing? - Jay (phone) On Jun 23, 2009, at 4:43 PM, jkrell at elego.de (Jay Krell) wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/06/23 16:43:03 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: I386_INTERIX > > Log message: > remove postgres, odbc, and x11 from SYSTEM_LIBS > at least for postgres and odbc, this causes packages that > use them to "play nice" and build nothing > no such luck for x11 though > > From mika at async.caltech.edu Wed Jun 24 06:34:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 23 Jun 2009 21:34:18 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: Your message of "Tue, 23 Jun 2009 11:27:33 -0000." Message-ID: <200906240434.n5O4YIfX017194@camembert.async.caltech.edu> Jay writes: > ... >I know the x87 uses 80 bit floating point numbers in hardware, >but there is also SSE/SSE2/SSE3/whatever now, that might be >different, and faster. >You know, they have actual "registers" instead of a register stack. >If you have some floating point intensive code, you might try it. > ... I've used SSEn using ifort (Intel Fortran), linking it with Modula-3, quite a bit. Works great. But it has two problems: it is mostly (entirely?) single-precision, and it's not portable, as in, you can compile a binary on one machine and then not run it on another machine that has the same OS and "architecture", e.g., "FreeBSD 5.5 / i386". Really annoying. > >More info on the Mosiac-C? >I'll search the web. > It's old. Well that's why there's a working m3 compiler :-) http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.6294 Mika From wagner at elegosoft.com Wed Jun 24 10:43:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 24 Jun 2009 10:43:27 +0200 Subject: [M3devel] X11 in system_libs? In-Reply-To: References: <20090623144303.F1B6ECC362@birch.elegosoft.com> Message-ID: <20090624104327.2e202q4lwk4ssg4c@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > Should a bunch of packages check if ostype is win32 or x11 is in > system_libs, else build nothing? I wouldn't mind if certain packages check their prerequisites and faile nicely to build if they aren't met, e.g. missing DB or X support. Olaf > - Jay (phone) > > On Jun 23, 2009, at 4:43 PM, jkrell at elego.de (Jay Krell) wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 09/06/23 16:43:03 >> >> Modified files: >> cm3/m3-sys/cminstall/src/config-no-install/: I386_INTERIX >> >> Log message: >> remove postgres, odbc, and x11 from SYSTEM_LIBS >> at least for postgres and odbc, this causes packages that >> use them to "play nice" and build nothing >> no such luck for x11 though >> >> -- 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 Jun 24 04:43:15 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 23 Jun 2009 19:43:15 -0700 Subject: [M3devel] files larger than 2gig In-Reply-To: References: Your message of "Tue, 23 Jun 2009 11:02:26 -0000." <200906231120.n5NBKrFL084784@camembert.async.caltech.edu> Message-ID: This is fixed, apparently gcc -fPIC there generates bad code for switch statements...this in C not Modula-3/m3cg. - Jay (phone) On Jun 23, 2009, at 4:43 AM, Jay wrote: > > And on that note, here is the status on I386_INTERIX, using a native > cm3. :) > > > --- building in I386_INTERIX --- > ignoring ../src/m3overrides > new source -> compiling SchedulerPosix.i3 > Program received signal SIGSEGV, Segmentation fault. > 0x00717e52 in ?? () > (gdb) bt > #0 0x00717e52 in ?? () > #1 0x0046e28c in Convert__InternalFromLongFloat () > #2 0x0046db4d in Convert__FromExtended () > #3 0x004edb03 in M3Buf__PutFloat () > #4 0x0062c20a in ReelExpr__GenFPLiteral () > #5 0x004991bc in Expr__GenFPLiteral () > #6 0x004b5702 in Formal__AddFPTag () > #7 0x006f4983 in Value__AddFPTag () > #8 0x005cc021 in ProcType__FPrinter () > #9 0x006e801a in TypeFP__Visit_SCC () > #10 0x006e7daa in TypeFP__FromType () > #11 0x006e299d in Type__GlobalUID () > #12 0x006eb0a9 in TypeTbl__Put () > #13 0x006e2bb5 in Type__Compile () > #14 0x006e2b1f in Type__CompileAll () > #15 0x0057192f in Module__Compile () > #16 0x00527171 in M3Front__DoCompile () > #17 0x005266a4 in M3Front__Compile () > #18 0x0042cd62 in Builder__RunM3 () > #19 0x0042b2a9 in Builder__PushOneM3 () > #20 0x0042ae8e in Builder__CompileM3 () > #21 0x00429916 in Builder__CompileOne () > #22 0x004295b1 in Builder__CompileEverything () > #23 0x004254ef in Builder__CompileUnits () > #24 0x00423c0e in Builder__BuildLib () > #25 0x004f4ac6 in M3Build__DoLibrary () > #26 0x005dc1cf in QMachine__DoCall () > #27 0x005db078 in QMachine__Eval () > #28 0x005e3bad in QMachine () > From rodney.m.bates at cox.net Wed Jun 24 18:18:30 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 24 Jun 2009 11:18:30 -0500 Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress Message-ID: <4A4251D6.60804@cox.net> I have tracked down the problems I have seen with m3gdb on AMD64_LINUX not recognizing object formats to a new section type SHT_GNU_HASH, (and named .gnu.hash), which is present in recent M3-compiled code. It appears to be handled by the more recent binutils that comes in gdb 6.8, but it is not handled by the binutils in gdb 6.4, from which m3gdb is derived. I briefly tried a naive substitution of the new binutils (directory 'bfd') into m3gdb, but some things have moved around and there are build problems finding them. I will work on this more when I get some time. Rodney Bates From jay.krell at cornell.edu Wed Jun 24 19:13:11 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 24 Jun 2009 17:13:11 +0000 Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress In-Reply-To: <4A4251D6.60804@cox.net> References: <4A4251D6.60804@cox.net> Message-ID: You should try using cvs import to upgrade to a newer version, of the entire gdb tree (well, maybe prune it -- testsuites, sim, cpu, intl, etc..) I personally have never done this -- only recently imported the first version of stuff but haven't yet updated anything. - Jay > Date: Wed, 24 Jun 2009 11:18:30 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress > > I have tracked down the problems I have seen with m3gdb on > AMD64_LINUX not recognizing object formats to a new section > type SHT_GNU_HASH, (and named .gnu.hash), which is present > in recent M3-compiled code. It appears to be handled by > the more recent binutils that comes in gdb 6.8, but it is > not handled by the binutils in gdb 6.4, from which m3gdb is > derived. > > I briefly tried a naive substitution of the new binutils > (directory 'bfd') into m3gdb, but some things have moved > around and there are build problems finding them. I will > work on this more when I get some time. > > Rodney Bates -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jun 25 01:10:05 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 24 Jun 2009 19:10:05 -0400 Subject: [M3devel] files larger than 2gig In-Reply-To: References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> Message-ID: <20090624231005.GA32180@topoi.pooq.com> On Mon, Jun 22, 2009 at 12:58:45PM -0400, Tony Hosking wrote: > > Yuck. Why not decompose in the backend? However we do it, large files should "just work" on systems that can handle them. -- hendrik From hendrik at topoi.pooq.com Thu Jun 25 02:06:40 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 24 Jun 2009 20:06:40 -0400 Subject: [M3devel] XML? In-Reply-To: <20090508025825.GC418@topoi.pooq.com> References: <20090507220142.GA32564@topoi.pooq.com> <367599.3562.qm@web24708.mail.ird.yahoo.com> <20090508025825.GC418@topoi.pooq.com> Message-ID: <20090625000640.GB32180@topoi.pooq.com> On Thu, May 07, 2009 at 10:58:25PM -0400, hendrik at topoi.pooq.com wrote: > 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. Looked further. The originally PM3 parser looked way more conplicated than necessary, which I attributed to haveing powerful tools available and showing the off. I decided to do somehting simpler, and XML parsing is a *lot* simpler than that. But I got curious and looked at SGML. (After all, some of the stuff I have to process isn't XML at all, but just plain formatted ASCII text with a few tags in it to indicate italics (where some would use *asterisks*)). And I discovered the following. Superficially, SGML has tags like

which match

. Lots of brackets which have to match up. Kind of like XML. It even has a Data Type Definition like XML's. (In fact XML copied the DTD from SGML for compatibility.) The DTD is obviously useful to screen incoming texts to make sure they satisfy a structural specification demanded by an application. Here the similarity ends. It turns out that in SGML you can leave out tags -- starters or enders, or even *both*, as long as that does not cause ambiguity. And *ambiguity* s interpreted in the context of a DTD, which specifies the grammar of the SGML file. This effectively convert a recursive tree walk into a parsing problem. The need for a DTD effectively means that you have to run a parser generator on DTD before you can start with the actual text. That bit of code from pm3 was pulling out all the heavy tools because it couldn't manage without them! Apparently the world abound in SGML processors readers that get details wrong, perhaps because they don't go about it with enough sophistication. Writing an SGML parser is a significant intellectual effort. Writing an XML parser (without enforcing strict conformance on the parsed documents) is, by comparison, is like falling off a log. -- hendrik From hendrik at topoi.pooq.com Thu Jun 25 15:42:33 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 25 Jun 2009 09:42:33 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090618134334.njcom4fusg0ccsws@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> Message-ID: <20090625134233.GA1722@topoi.pooq.com> On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >Is it time for me to make another try at installing cm3 from scratch? > >In particular, do you think most of the problems I reported with > >documentation and archives, etc., have been solved? I really want to > >get m3 working on this laptop, but I also want to provide the most > >useful problem reports. > > > >I'm definitely trying to act like a naive user in these installation > >attempts (which means I'm trying to act stupider than I am). > > I've now put some initial release engineering documentation onto > birch, available at > > http://www.opencm3.net/releng Well, I started with that page, assuming that it will be the one Google finds when the release is finally out. I'm continuing to act like a naive user (but I'm probably not naive enough to give the instructions a real test). It seems to have installed, but I'm not sure, because the installer ended with an error message. Here are the gory details. Started from http://www.opencm3.net/releng/ I found the description quite clear. It's still not clear just what packages are in cm3-core and not in cm3-min or why I would want them, but it was clear I wanted to start with cm3-core. For example, is there a UI library in cm3-core? (Oh why is it so hard to cut and paste from the web page to this emacs buffer on my laptop?) cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A beginner with Linux might have difficulty knowing whether to use the .lzma version. Ah! I clicked on the "standard, recommended" link (I hadn't realised it was a link) and found the list of what packages are in the .tgz file. One layout comment -- it consists of a series of sections, each starting with a title and ending with a browse-sources link. Each title needs to look more prominent than the text or the link. At the moment, the link is what stands out. More blank lines between the entries then within them would make them group better. Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz Again, that worked. I do find myseelf wondering it that would be the correct command line if I were uzinng Winzip on Windows, though. (that's wha tthe insstruction seems to say) Next I run ./cminstall /usr/local/cm3 It asks mme whether /home.hendrik/cm3 is to be the root directory for cm3. The naive user doesn't know what that means. Nor do I, for that matter. I'm guessing that it's where to unpack and work during installation, but that it won't be needed later. That I can even deleete the entire /home/hendrik/cm3 directory tree after installation. That in fact when I instll packages later I can download them to, say, /anywhere and install them from /anywhere and they'll still get installed in the proper place. But I don't know. For now, I'll just accept the defaults. Next problem: > Installing CM3 in: /usr/local/cm3 > This may take a few minutes... > > Unexpected problem: cannot list current directory: errno=2 > > Please feel free to contact m3-support at elego.de to troubleshoot this problem. Current directory? That's an uninformative message. Possibly it refers to /usr/local/cm3? Which really doesn't exit yet? Should your instructions say to create it and make sure it has the right write permissions? Noooo. that's not the reason. /usr/local/cm3 has been created. And populated with lots of subdirectories. /usr/local/cm3/bin contains a few executables and lots of other files. It turns out I did have permission to write on /usr/local. I don't know what directory it's referring to. What next? -- hendrik From wagner at elegosoft.com Thu Jun 25 18:52:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 25 Jun 2009 18:52:06 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625134233.GA1722@topoi.pooq.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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> Message-ID: <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: >> Quoting hendrik at topoi.pooq.com: >> >> >Is it time for me to make another try at installing cm3 from scratch? >> >In particular, do you think most of the problems I reported with >> >documentation and archives, etc., have been solved? I really want to >> >get m3 working on this laptop, but I also want to provide the most >> >useful problem reports. >> > >> >I'm definitely trying to act like a naive user in these installation >> >attempts (which means I'm trying to act stupider than I am). >> >> I've now put some initial release engineering documentation onto >> birch, available at >> >> http://www.opencm3.net/releng > > Well, I started with that page, assuming that it will be the one Google > finds when the release is finally out. I'm continuing to act like a > naive user (but I'm probably not naive enough to give the instructions a > real test). > > It seems to have installed, but I'm not sure, because the installer > ended with an error message. Here are the gory details. > > Started from http://www.opencm3.net/releng/ > > I found the description quite clear. It's still not clear just what > packages are in cm3-core and not in cm3-min or why I would want them, > but it was clear I wanted to start with cm3-core. For example, is there > a UI library in cm3-core? > > (Oh why is it so hard to cut and paste from the web page to this emacs > buffer on my laptop?) > cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A > beginner with Linux might have difficulty knowing whether to use the > .lzma version. LINUXLIBC6 along with all lmza archives were created by Jay; I'd rather have limited the available formats. Of course this needs to be documented if we provide .lzma files. > Ah! I clicked on the "standard, recommended" link (I hadn't realised it > was a link) and found the list of what packages are in the .tgz file. > One layout comment -- it consists of a series of sections, each starting > with a title and ending with a browse-sources link. Each title needs to > look more prominent than the text or the link. At the moment, the link > is what stands out. More blank lines between the entries then within > them would make them group better. > > Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz > > Again, that worked. I do find myseelf wondering it that would be the > correct command line if I were uzinng Winzip on Windows, though. > (that's wha tthe insstruction seems to say) No, Winzip of course is a GUI application where you are supposed to point and click with the mouse... > Next I run ./cminstall /usr/local/cm3 > > It asks mme whether /home.hendrik/cm3 is to be the root directory for > cm3. The naive user doesn't know what that means. Nor do I, for that This is strange. cminstall shouldn't ask any questions by default. But as mentioned before, I only built the archives for FreeBSD4 and AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package there? Or am I misunderstanding something here? > matter. I'm guessing that it's where to unpack and work during > installation, but that it won't be needed later. That I can even > deleete the entire /home/hendrik/cm3 directory tree after installation. > That in fact when I instll packages later I can download them to, say, > /anywhere and install them from /anywhere and they'll still get > installed in the proper place. But I don't know. For now, I'll just > accept the defaults. > > Next problem: > >> Installing CM3 in: /usr/local/cm3 >> This may take a few minutes... >> >> Unexpected problem: cannot list current directory: errno=2 I've never seen that. Can you provide the complete installation log? We may also need a system call trace to track this down... >> Please feel free to contact m3-support at elego.de to troubleshoot this > problem. > > Current directory? That's an uninformative message. Possibly it refers > to /usr/local/cm3? Which really doesn't exit yet? Should your > instructions say to create it and make sure it has the right write > permissions? > > Noooo. that's not the reason. /usr/local/cm3 has been created. And > populated with lots of subdirectories. /usr/local/cm3/bin contains a > few executables and lots of other files. It turns out I did have > permission to write on /usr/local. I don't know what directory it's > referring to. Strange. I tried an installation on FreeBSD which succeeded without any problems. > What next? Let's have a look at Install.log and hear what Jay has to say about LINUXLIBC6. Thanks for the feedback, 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 wagner at elegosoft.com Thu Jun 25 19:26:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 25 Jun 2009 19:26:45 +0200 Subject: [M3devel] CM3 Release Engineering Message-ID: <20090625192645.4761owc6s8kk4wko@mail.elegosoft.com> Hi all, in order to start with some serious testing and release engineering, I'd still like to have some more feedback from others, especially on the following topics: o Is the suggested archive set accepted? Should we break up or combine certain archives? Or even provide something much simpler? o Has anybody tested installation of any of these packages? Was it successful? o Has anybody tested Rodney's alternative TEXT implementation? Should we make it the default in this release? o Are there still any known show-stoppers? Crashes, broken functionality etc.? o Should we really provide multiple formats (tar/gzip and lzma)? If we don't need/want to change much, the next steps would be: 1. Some documentation fixes/extensions. 2. Application of an RC1 tag and code freeze (or releng branching; but as said earlier, I'd rather avoid that) 3. Announcement of new release candidates in WWW, news and mailing lists. 4. More extensive installation testing. 5. Fixing of all reported bugs (if there are any ;-) 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 hendrik at topoi.pooq.com Thu Jun 25 19:37:15 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 25 Jun 2009 13:37:15 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625185206.f4lc9vlpckggko4g@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: <20090625173714.GA2324@topoi.pooq.com> On Thu, Jun 25, 2009 at 06:52:06PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: > >> > >>I've now put some initial release engineering documentation onto > >>birch, available at > >> > >> http://www.opencm3.net/releng > > > >Well, I started with that page, assuming that it will be the one Google > >finds when the release is finally out. I'm continuing to act like a > >naive user (but I'm probably not naive enough to give the instructions a > >real test). > > > >It seems to have installed, but I'm not sure, because the installer > >ended with an error message. Here are the gory details. > > > >Started from http://www.opencm3.net/releng/ > > > >I found the description quite clear. It's still not clear just what > >packages are in cm3-core and not in cm3-min or why I would want them, > >but it was clear I wanted to start with cm3-core. For example, is there > >a UI library in cm3-core? > > > >(Oh why is it so hard to cut and paste from the web page to this emacs > >buffer on my laptop?) > > >cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A > >beginner with Linux might have difficulty knowing whether to use the > >.lzma version. > > LINUXLIBC6 along with all lmza archives were created by Jay; > I'd rather have limited the available formats. Of course this needs > to be documented if we provide .lzma files. > > >Ah! I clicked on the "standard, recommended" link (I hadn't realised it > >was a link) and found the list of what packages are in the .tgz file. > >One layout comment -- it consists of a series of sections, each starting > >with a title and ending with a browse-sources link. Each title needs to > >look more prominent than the text or the link. At the moment, the link > >is what stands out. More blank lines between the entries then within > >them would make them group better. > > > >Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz > > > >Again, that worked. I do find myseelf wondering it that would be the > >correct command line if I were uzinng Winzip on Windows, though. > >(that's wha tthe insstruction seems to say) > > No, Winzip of course is a GUI application where you are supposed to > point and click with the mouse... Probably needs rewording. > > >Next I run ./cminstall /usr/local/cm3 > > > >It asks mme whether /home.hendrik/cm3 is to be the root directory for > >cm3. The naive user doesn't know what that means. Nor do I, for that > > This is strange. cminstall shouldn't ask any questions by default. Looking back, it didn't actually ask; it just told me to restart if it was wrong. > But as mentioned before, I only built the archives for FreeBSD4 and > AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package > there? Or am I misunderstanding something here? > > >matter. I'm guessing that it's where to unpack and work during > >installation, but that it won't be needed later. That I can even > >deleete the entire /home/hendrik/cm3 directory tree after installation. > >That in fact when I instll packages later I can download them to, say, > >/anywhere and install them from /anywhere and they'll still get > >installed in the proper place. But I don't know. For now, I'll just > >accept the defaults. > > > >Next problem: > > > >>Installing CM3 in: /usr/local/cm3 > >>This may take a few minutes... > >> > >>Unexpected problem: cannot list current directory: errno=2 > > I've never seen that. Can you provide the complete installation log? > We may also need a system call trace to track this down... > > >>Please feel free to contact m3-support at elego.de to troubleshoot this > >problem. > > > >Current directory? That's an uninformative message. Possibly it refers > >to /usr/local/cm3? Which really doesn't exit yet? Should your > >instructions say to create it and make sure it has the right write > >permissions? > > > >Noooo. that's not the reason. /usr/local/cm3 has been created. And > >populated with lots of subdirectories. /usr/local/cm3/bin contains a > >few executables and lots of other files. It turns out I did have > >permission to write on /usr/local. I don't know what directory it's > >referring to. > > Strange. I tried an installation on FreeBSD which succeeded without > any problems. Evidently there's some directory on FreeBSD that's not so readable in Debian squeeze. What directories is it likely to want to read or write? I could go through them and see if any are missing here. > > >What next? > > Let's have a look at Install.log and hear what Jay has to say about > LINUXLIBC6. cat, cut, and paste into the mailer: hendrik at notlookedfor:~$ cat /usr/local/cm3/Install.log Thank you for using Critical Mass CM3. This program will configure and install the system. cminstall_root is set to /home/hendrik/cm3 If this is not correct, please restart the installer with -root If the installer runs interactively, it will ask you some questions about the locations of programs and libraries. Usually it will display a default inside [], which can be accepted with . If the installer has found several choices, you may cycle through them with `+' or `.' for the next and `-' for the previous one. You may of course also enter a completely different value. Installing CM3 in: /usr/local/cm3 This may take a few minutes... Unexpected problem: cannot list current directory: errno=2 Please feel free to contact m3-support at elego.de to troubleshoot this problem. hendrik at notlookedfor:~$ > > Thanks for the feedback. You're very welcome. For the record, here are a few ls's showing what there *is* now. hendrik at notlookedfor:~$ ls /usr/local bin cm3 etc games include lib man sbin share src stow hendrik at notlookedfor:~$ ls /usr/local/cm3 bin doc elisp examples Install.log lib man pkg hendrik at notlookedfor:~$ ls /usr/local/cm3/*/ /usr/local/cm3/bin/: AMD64_DARWIN Darwin.common m3bundle NT386MINGNU SOLsun AMD64_FREEBSD FreeBSD4 m3cgcat PA32_HPUX SPARC32_LINUX AMD64_LINUX gnuld.common m3cggen PA64_HPUX SPARC64_LINUX ARM_DARWIN HPUX.common MIPS64_OPENBSD PPC32_OPENBSD SPARC64_OPENBSD cm3 I386_DARWIN NetBSD2_i386 PPC_DARWIN SPARC64_SOLARIS cm3.cfg I386_INTERIX NT386 PPC_LINUX Unix.common cm3cfg.common I386_OPENBSD NT386.common Solaris.common cm3cg LINUXLIBC6 NT386GNU SOLgnu /usr/local/cm3/doc/: /usr/local/cm3/elisp/: /usr/local/cm3/examples/: /usr/local/cm3/lib/: libBitVector.so libm3slisp.so libset.so libBitVector.so.5 libm3slisp.so.5 libset.so.5 libDiGraph.so libm3.so libSortedTableExtras.so libDiGraph.so.5 libm3.so.5 libSortedTableExtras.so.5 libGeometry.so libm3tcp.so libsysutils.so libGeometry.so.5 libm3tcp.so.5 libsysutils.so.5 libm3core.so libm3unit.so libtable-list.so libm3core.so.5 libm3unit.so.5 libtable-list.so.5 libm3parseparams.so libpatternmatching.so libTempFiles.so libm3parseparams.so.5 libpatternmatching.so.5 libTempFiles.so.5 /usr/local/cm3/man/: man1 /usr/local/cm3/pkg/: bitvector m3bundle m3linker m3tools slisp tempfiles cm3 m3cgcat m3middle parseparams sortedtableextras unittest digraph m3cggen m3objfile patternmatching sysutils libm3 m3core m3quake realgeometry table-list m3back m3front m3scanner set tcp hendrik at notlookedfor:~$ From jay.krell at cornell.edu Thu Jun 25 22:43:11 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 25 Jun 2009 20:43:11 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625185206.f4lc9vlpckggko4g@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: I just ran ./make-dist.sh. I admit I didn't take the time to test out the archives. lzma I made just via gunzip foo.tgz lzma foo.tar For Interix I cut down the list of collections. It is common for multiple compression formats to be used. lzma often shrinks the files by half, though, oddly, sometimes not at all. lzma admittedly has been superceded xz. I know it is difficult and I'm not helpful here, but we should keep in mind the ideals: apt-get install foo download foo.exe and run it, hit next next next finish download foo.tar.gz, tar xf foo.tar.gz, cd foo, read INSTALL, ./configure, ./make, su, ./make install to measure ourselves by. There's no need for Winzip if we use .zip files, explorer handles them. It is also easy to make self extracting .zip files. And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. - Jay > Date: Thu, 25 Jun 2009 18:52:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > Quoting hendrik at topoi.pooq.com: > > > On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: > >> > >> >Is it time for me to make another try at installing cm3 from scratch? > >> >In particular, do you think most of the problems I reported with > >> >documentation and archives, etc., have been solved? I really want to > >> >get m3 working on this laptop, but I also want to provide the most > >> >useful problem reports. > >> > > >> >I'm definitely trying to act like a naive user in these installation > >> >attempts (which means I'm trying to act stupider than I am). > >> > >> I've now put some initial release engineering documentation onto > >> birch, available at > >> > >> http://www.opencm3.net/releng > > > > Well, I started with that page, assuming that it will be the one Google > > finds when the release is finally out. I'm continuing to act like a > > naive user (but I'm probably not naive enough to give the instructions a > > real test). > > > > It seems to have installed, but I'm not sure, because the installer > > ended with an error message. Here are the gory details. > > > > Started from http://www.opencm3.net/releng/ > > > > I found the description quite clear. It's still not clear just what > > packages are in cm3-core and not in cm3-min or why I would want them, > > but it was clear I wanted to start with cm3-core. For example, is there > > a UI library in cm3-core? > > > > (Oh why is it so hard to cut and paste from the web page to this emacs > > buffer on my laptop?) > > > cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A > > beginner with Linux might have difficulty knowing whether to use the > > .lzma version. > > LINUXLIBC6 along with all lmza archives were created by Jay; > I'd rather have limited the available formats. Of course this needs > to be documented if we provide .lzma files. > > > Ah! I clicked on the "standard, recommended" link (I hadn't realised it > > was a link) and found the list of what packages are in the .tgz file. > > One layout comment -- it consists of a series of sections, each starting > > with a title and ending with a browse-sources link. Each title needs to > > look more prominent than the text or the link. At the moment, the link > > is what stands out. More blank lines between the entries then within > > them would make them group better. > > > > Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz > > > > Again, that worked. I do find myseelf wondering it that would be the > > correct command line if I were uzinng Winzip on Windows, though. > > (that's wha tthe insstruction seems to say) > > No, Winzip of course is a GUI application where you are supposed to > point and click with the mouse... > > > Next I run ./cminstall /usr/local/cm3 > > > > It asks mme whether /home.hendrik/cm3 is to be the root directory for > > cm3. The naive user doesn't know what that means. Nor do I, for that > > This is strange. cminstall shouldn't ask any questions by default. > But as mentioned before, I only built the archives for FreeBSD4 and > AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package > there? Or am I misunderstanding something here? > > > matter. I'm guessing that it's where to unpack and work during > > installation, but that it won't be needed later. That I can even > > deleete the entire /home/hendrik/cm3 directory tree after installation. > > That in fact when I instll packages later I can download them to, say, > > /anywhere and install them from /anywhere and they'll still get > > installed in the proper place. But I don't know. For now, I'll just > > accept the defaults. > > > > Next problem: > > > >> Installing CM3 in: /usr/local/cm3 > >> This may take a few minutes... > >> > >> Unexpected problem: cannot list current directory: errno=2 > > I've never seen that. Can you provide the complete installation log? > We may also need a system call trace to track this down... > > >> Please feel free to contact m3-support at elego.de to troubleshoot this > > problem. > > > > Current directory? That's an uninformative message. Possibly it refers > > to /usr/local/cm3? Which really doesn't exit yet? Should your > > instructions say to create it and make sure it has the right write > > permissions? > > > > Noooo. that's not the reason. /usr/local/cm3 has been created. And > > populated with lots of subdirectories. /usr/local/cm3/bin contains a > > few executables and lots of other files. It turns out I did have > > permission to write on /usr/local. I don't know what directory it's > > referring to. > > Strange. I tried an installation on FreeBSD which succeeded without > any problems. > > > What next? > > Let's have a look at Install.log and hear what Jay has to say about > LINUXLIBC6. > > Thanks for the feedback, > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jun 25 23:27:20 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 25 Jun 2009 17:27:20 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: References: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: <20090625212720.GA2783@topoi.pooq.com> On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: > > I just ran ./make-dist.sh. > I admit I didn't take the time to test out the archives. > lzma I made just via > gunzip foo.tgz > lzma foo.tar No need to apologise. These archives seem to have worked better than the last ones I tried. I'm specifically trying to help you guys make it work by acting like a naive user and reporting what goes wrong or might confuse a naive user. The show-stopper for the naive user in this report was the error message that, as far as I can tell, occurs at the end of installation. If my goal was just to get cm3 working, I'd have accomplished it already, as an experienced user. IN fact, I'm still going to set my $PATH properly to find out if I already have a working cm3 from this installation. The last one I tried a few seeks ago (a version of min) was usable long before I finished the whole installation process. After juat unzipping the archives and cooking up some suitable $PATH entries, I was compiling. But from the instructions I was following, it looked like I had a long way to go yet. Half the problems I'm coming up with are probably infelicities if documentation. Like the 'if' in that sentence that should have been 'of'. > > > For Interix I cut down the list of collections. > > > It is common for multiple compression formats to be used. > lzma often shrinks the files by half, though, oddly, sometimes not at all. > lzma admittedly has been superceded xz. > > > > I know it is difficult and I'm not helpful here, but we should keep in mind the ideals: > > apt-get install foo We still have to get to this point. Only I fink it's cm3 we want, not foo. > > download foo.exe and run it, hit next next next finish > > download foo.tar.gz, tar xf foo.tar.gz, cd foo, read INSTALL, ./configure, ./make, su, ./make install > > > > to measure ourselves by. > > > > There's no need for Winzip if we use .zip files, explorer handles them. That's useful. Unless you're paranoid enough to never let your WIndows machine come near a network. It's an effective way to avoid viruses. > > It is also easy to make self extracting .zip files. > > And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. > > > - Jay > > > > Date: Thu, 25 Jun 2009 18:52:06 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > > > Quoting hendrik at topoi.pooq.com: > > > > > On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: > > >> Quoting hendrik at topoi.pooq.com: > > >> > > >> >Is it time for me to make another try at installing cm3 from scratch? > > >> >In particular, do you think most of the problems I reported with > > >> >documentation and archives, etc., have been solved? I really want to > > >> >get m3 working on this laptop, but I also want to provide the most > > >> >useful problem reports. > > >> > > > >> >I'm definitely trying to act like a naive user in these installation > > >> >attempts (which means I'm trying to act stupider than I am). > > >> > > >> I've now put some initial release engineering documentation onto > > >> birch, available at > > >> > > >> http://www.opencm3.net/releng > > > > > > Well, I started with that page, assuming that it will be the one Google > > > finds when the release is finally out. I'm continuing to act like a > > > naive user (but I'm probably not naive enough to give the instructions a > > > real test). > > > > > > It seems to have installed, but I'm not sure, because the installer > > > ended with an error message. Here are the gory details. > > > > > > Started from http://www.opencm3.net/releng/ > > > > > > I found the description quite clear. It's still not clear just what > > > packages are in cm3-core and not in cm3-min or why I would want them, > > > but it was clear I wanted to start with cm3-core. For example, is there > > > a UI library in cm3-core? > > > > > > (Oh why is it so hard to cut and paste from the web page to this emacs > > > buffer on my laptop?) > > > > > cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a problem. A > > > beginner with Linux might have difficulty knowing whether to use the > > > .lzma version. > > > > LINUXLIBC6 along with all lmza archives were created by Jay; > > I'd rather have limited the available formats. Of course this needs > > to be documented if we provide .lzma files. > > > > > Ah! I clicked on the "standard, recommended" link (I hadn't realised it > > > was a link) and found the list of what packages are in the .tgz file. > > > One layout comment -- it consists of a series of sections, each starting > > > with a title and ending with a browse-sources link. Each title needs to > > > look more prominent than the text or the link. At the moment, the link > > > is what stands out. More blank lines between the entries then within > > > them would make them group better. > > > > > > Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz > > > > > > Again, that worked. I do find myseelf wondering it that would be the > > > correct command line if I were uzinng Winzip on Windows, though. > > > (that's wha tthe insstruction seems to say) > > > > No, Winzip of course is a GUI application where you are supposed to > > point and click with the mouse... > > > > > Next I run ./cminstall /usr/local/cm3 > > > > > > It asks mme whether /home.hendrik/cm3 is to be the root directory for > > > cm3. The naive user doesn't know what that means. Nor do I, for that > > > > This is strange. cminstall shouldn't ask any questions by default. > > But as mentioned before, I only built the archives for FreeBSD4 and > > AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package > > there? Or am I misunderstanding something here? > > > > > matter. I'm guessing that it's where to unpack and work during > > > installation, but that it won't be needed later. That I can even > > > deleete the entire /home/hendrik/cm3 directory tree after installation. > > > That in fact when I instll packages later I can download them to, say, > > > /anywhere and install them from /anywhere and they'll still get > > > installed in the proper place. But I don't know. For now, I'll just > > > accept the defaults. > > > > > > Next problem: > > > > > >> Installing CM3 in: /usr/local/cm3 > > >> This may take a few minutes... > > >> > > >> Unexpected problem: cannot list current directory: errno=2 > > > > I've never seen that. Can you provide the complete installation log? > > We may also need a system call trace to track this down... > > > > >> Please feel free to contact m3-support at elego.de to troubleshoot this > > > problem. > > > > > > Current directory? That's an uninformative message. Possibly it refers > > > to /usr/local/cm3? Which really doesn't exit yet? Should your > > > instructions say to create it and make sure it has the right write > > > permissions? > > > > > > Noooo. that's not the reason. /usr/local/cm3 has been created. And > > > populated with lots of subdirectories. /usr/local/cm3/bin contains a > > > few executables and lots of other files. It turns out I did have > > > permission to write on /usr/local. I don't know what directory it's > > > referring to. > > > > Strange. I tried an installation on FreeBSD which succeeded without > > any problems. > > > > > What next? > > > > Let's have a look at Install.log and hear what Jay has to say about > > LINUXLIBC6. > > > > Thanks for the feedback, > > > > 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 Fri Jun 26 01:29:18 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 25 Jun 2009 16:29:18 -0700 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625212720.GA2783@topoi.pooq.com> References: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090625212720.GA2783@topoi.pooq.com> Message-ID: More later but: how about we drop a sh wrapper or symlink in installroot/../bin so $path usually unchanged? And ensure ld_library_path needed on the fewest systems possible. - Jay (phone) On Jun 25, 2009, at 2:27 PM, hendrik at topoi.pooq.com wrote: > On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: >> >> I just ran ./make-dist.sh. >> I admit I didn't take the time to test out the archives. >> lzma I made just via >> gunzip foo.tgz >> lzma foo.tar > > No need to apologise. These archives seem to have worked better than > the last ones I tried. > > I'm specifically trying to help you guys make it work by acting like a > naive user and reporting what goes wrong or might confuse a naive > user. > The show-stopper for the naive user in this report was the error > message > that, as far as I can tell, occurs at the end of installation. > > If my goal was just to get cm3 working, I'd have accomplished it > already, as an experienced user. IN fact, I'm still going to set my > $PATH properly to find out if I already have a working cm3 from this > installation. The last one I tried a few seeks ago (a version of min) > was usable long before I finished the whole installation process. > After > juat unzipping the archives and cooking up some suitable $PATH > entries, > I was compiling. But from the instructions I was following, it looked > like I had a long way to go yet. > > Half the problems I'm coming up with are probably infelicities if > documentation. Like the 'if' in that sentence that should have been > 'of'. > >> >> >> For Interix I cut down the list of collections. >> >> >> It is common for multiple compression formats to be used. >> lzma often shrinks the files by half, though, oddly, sometimes not >> at all. >> lzma admittedly has been superceded xz. >> >> >> >> I know it is difficult and I'm not helpful here, but we should keep >> in mind the ideals: >> >> apt-get install foo > > We still have to get to this point. Only I fink it's cm3 we want, not > foo. > >> >> download foo.exe and run it, hit next next next finish >> >> download foo.tar.gz, tar xf foo.tar.gz, cd foo, read INSTALL, ./ >> configure, ./make, su, ./make install >> >> >> >> to measure ourselves by. >> >> >> >> There's no need for Winzip if we use .zip files, explorer handles >> them. > > That's useful. Unless you're paranoid enough to never let your > WIndows > machine come near a network. It's an effective way to avoid viruses. > >> >> It is also easy to make self extracting .zip files. >> >> And untrusting users can just run unzip on them or rename them >> to .zip and open with Explorer, it's quite nice, except that for >> running, they don't run on many systems. >> >> >> - Jay >> >> >>> Date: Thu, 25 Jun 2009 18:52:06 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: >>> Release engineering) >>> >>> Quoting hendrik at topoi.pooq.com: >>> >>>> On Thu, Jun 18, 2009 at 01:43:34PM +0200, Olaf Wagner wrote: >>>>> Quoting hendrik at topoi.pooq.com: >>>>> >>>>>> Is it time for me to make another try at installing cm3 from >>>>>> scratch? >>>>>> In particular, do you think most of the problems I reported with >>>>>> documentation and archives, etc., have been solved? I really >>>>>> want to >>>>>> get m3 working on this laptop, but I also want to provide the >>>>>> most >>>>>> useful problem reports. >>>>>> >>>>>> I'm definitely trying to act like a naive user in these >>>>>> installation >>>>>> attempts (which means I'm trying to act stupider than I am). >>>>> >>>>> I've now put some initial release engineering documentation onto >>>>> birch, available at >>>>> >>>>> http://www.opencm3.net/releng >>>> >>>> Well, I started with that page, assuming that it will be the one >>>> Google >>>> finds when the release is finally out. I'm continuing to act like a >>>> naive user (but I'm probably not naive enough to give the >>>> instructions a >>>> real test). >>>> >>>> It seems to have installed, but I'm not sure, because the installer >>>> ended with an error message. Here are the gory details. >>>> >>>> Started from http://www.opencm3.net/releng/ >>>> >>>> I found the description quite clear. It's still not clear just what >>>> packages are in cm3-core and not in cm3-min or why I would want >>>> them, >>>> but it was clear I wanted to start with cm3-core. For example, is >>>> there >>>> a UI library in cm3-core? >>>> >>>> (Oh why is it so hard to cut and paste from the web page to this >>>> emacs >>>> buffer on my laptop?) >>> >>>> cm3-bin-core-LINUXLIBC6-d5.8.1-RC1.tgz dowwnloaded without a >>>> problem. A >>>> beginner with Linux might have difficulty knowing whether to use >>>> the >>>> .lzma version. >>> >>> LINUXLIBC6 along with all lmza archives were created by Jay; >>> I'd rather have limited the available formats. Of course this needs >>> to be documented if we provide .lzma files. >>> >>>> Ah! I clicked on the "standard, recommended" link (I hadn't >>>> realised it >>>> was a link) and found the list of what packages are in the .tgz >>>> file. >>>> One layout comment -- it consists of a series of sections, each >>>> starting >>>> with a title and ending with a browse-sources link. Each title >>>> needs to >>>> look more prominent than the text or the link. At the moment, the >>>> link >>>> is what stands out. More blank lines between the entries then >>>> within >>>> them would make them group better. >>>> >>>> Next: do tar -xzvf cm3-bin-core-TARGET-VERSION.tgz >>>> >>>> Again, that worked. I do find myseelf wondering it that would be >>>> the >>>> correct command line if I were uzinng Winzip on Windows, though. >>>> (that's wha tthe insstruction seems to say) >>> >>> No, Winzip of course is a GUI application where you are supposed to >>> point and click with the mouse... >>> >>>> Next I run ./cminstall /usr/local/cm3 >>>> >>>> It asks mme whether /home.hendrik/cm3 is to be the root directory >>>> for >>>> cm3. The naive user doesn't know what that means. Nor do I, for >>>> that >>> >>> This is strange. cminstall shouldn't ask any questions by default. >>> But as mentioned before, I only built the archives for FreeBSD4 and >>> AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you >>> package >>> there? Or am I misunderstanding something here? >>> >>>> matter. I'm guessing that it's where to unpack and work during >>>> installation, but that it won't be needed later. That I can even >>>> deleete the entire /home/hendrik/cm3 directory tree after >>>> installation. >>>> That in fact when I instll packages later I can download them to, >>>> say, >>>> /anywhere and install them from /anywhere and they'll still get >>>> installed in the proper place. But I don't know. For now, I'll just >>>> accept the defaults. >>>> >>>> Next problem: >>>> >>>>> Installing CM3 in: /usr/local/cm3 >>>>> This may take a few minutes... >>>>> >>>>> Unexpected problem: cannot list current directory: errno=2 >>> >>> I've never seen that. Can you provide the complete installation log? >>> We may also need a system call trace to track this down... >>> >>>>> Please feel free to contact m3-support at elego.de to troubleshoot >>>>> this >>>> problem. >>>> >>>> Current directory? That's an uninformative message. Possibly it >>>> refers >>>> to /usr/local/cm3? Which really doesn't exit yet? Should your >>>> instructions say to create it and make sure it has the right write >>>> permissions? >>>> >>>> Noooo. that's not the reason. /usr/local/cm3 has been created. And >>>> populated with lots of subdirectories. /usr/local/cm3/bin >>>> contains a >>>> few executables and lots of other files. It turns out I did have >>>> permission to write on /usr/local. I don't know what directory it's >>>> referring to. >>> >>> Strange. I tried an installation on FreeBSD which succeeded without >>> any problems. >>> >>>> What next? >>> >>> Let's have a look at Install.log and hear what Jay has to say about >>> LINUXLIBC6. >>> >>> Thanks for the feedback, >>> >>> 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 Fri Jun 26 08:42:31 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 06:42:31 +0000 Subject: [M3devel] upgrade.sh CFGD code seems wrong/dead? Message-ID: This block in upgrade.sh seems dead, given that nothing sets CFGD. Searching for 'CFGD'... C:\dev2\cm3.2\scripts\upgrade.sh(95): cp -v ${f} ${CFGD}/${b} if [ "${UPGRADE_CM3_CFG}" = "yes" -o "${ret}" != 0 ]; then ( .... I'd like to move the config files to root/bin/config instead of littering bin. Ok? This is one of the few places that is related to that. - Jay From jay.krell at cornell.edu Fri Jun 26 09:04:23 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 07:04:23 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <20090624231005.GA32180@topoi.pooq.com> References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> <20090624231005.GA32180@topoi.pooq.com> Message-ID: ---------------------------------------- > Date: Wed, 24 Jun 2009 19:10:05 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > On Mon, Jun 22, 2009 at 12:58:45PM -0400, Tony Hosking wrote: >> >> Yuck. Why not decompose in the backend? > > However we do it, large files should "just work" on systems that can > handle them. > > -- hendrik It should be LONGINT. I'll try to get to it. It might be a slightly breaking change, depending on where the INTEGER size is exposed. That shouldn't be difficult and will address all but one platform. I'll try to get back to revisiting LONGINT support on NT386. Then it might be interesting, though not easy, to port that backend to more platforms. :) One reason to do all those wierdo ports is to set a bar for what an integrated backend should strive for. :) Or then again again again, a C generator. That way, there'd be a chance of "no more porting work". If the IL was slightly abstracted, we could just generate portable C and release just one portable source-ish package for all platforms. There could still be binary packages for people that don't build from source, but all platforms would just be a C compiler away. - Jay From wagner at elegosoft.com Fri Jun 26 10:01:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 10:01:44 +0200 Subject: [M3devel] upgrade.sh CFGD code seems wrong/dead? In-Reply-To: References: Message-ID: <20090626100144.g3ciia3szocgsws0@mail.elegosoft.com> Quoting Jay : > > This block in upgrade.sh seems dead, given that nothing sets CFGD. > > Searching for 'CFGD'... > C:\dev2\cm3.2\scripts\upgrade.sh(95): cp -v ${f} ${CFGD}/${b} > > > if [ "${UPGRADE_CM3_CFG}" = "yes" -o "${ret}" != 0 ]; then ( > .... > > > I'd like to move the config files to root/bin/config instead of > littering bin. Ok? No. This would just be another directory which does not conform to FSH standards. I already extended cm3 to search for config files in various /etc directories, though that's still untested. I'd prefer that we don't move config files _now_ before the release, but if you want to do it, test it: o move them to cm3/etc o test cm3 with that setup on at least one platform o adapt scripts for regression etc. as you deem necessary o watch tinderbox results and fix again ;-) > > This is one of the few places that is related to that. As for your question above, I cannot say without browsing and grepping the code which I cannot do from here (isolated network); perhaps tonight... 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 wagner at elegosoft.com Fri Jun 26 10:08:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 10:08:54 +0200 Subject: [M3devel] files larger than 2gig In-Reply-To: References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> <20090624231005.GA32180@topoi.pooq.com> Message-ID: <20090626100854.ox2rmkey8o0k4gk4@mail.elegosoft.com> Quoting Jay : > > ---------------------------------------- >> Date: Wed, 24 Jun 2009 19:10:05 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] files larger than 2gig >> >> On Mon, Jun 22, 2009 at 12:58:45PM -0400, Tony Hosking wrote: >>> >>> Yuck. Why not decompose in the backend? >> >> However we do it, large files should "just work" on systems that can >> handle them. >> >> -- hendrik > > > It should be LONGINT. > I'll try to get to it. > It might be a slightly breaking change, depending on where the > INTEGER size is exposed. > > > That shouldn't be difficult and will address all but one platform. > I'll try to get back to revisiting LONGINT support on NT386. > Then it might be interesting, though not easy, to port that backend > to more platforms. :) > One reason to do all those wierdo ports is to set a bar for > what an integrated backend should strive for. :) > Or then again again again, a C generator. That way, there'd be a chance > of "no more porting work". If the IL was slightly abstracted, we could > just generate portable C and release just one > portable source-ish package for all platforms. > There could still be binary packages for people that don't build from source, > but all platforms would just be a C compiler away. It has been done that way in the first SRC compilers. m3make was just a wrapper generating makefiles, and the compiler produced C as an intermediate language. It was found to be rather suboptiomal for various reasons AFAIR: performance of the compiler, performance of the produced code (missing optimizations), missing C standardization (what exactly is portable C???), ... Of course I wouldn't object a C generating backend at all, but we should very carefully compare its benefits with the existing backends before abandoning any of them. 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 Fri Jun 26 10:38:31 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 08:38:31 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090625185206.f4lc9vlpckggko4g@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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: I tested the LINUXLIBC6 archive and it installed ok, no prompting. I ran it with no parameters -- unlike Henrik. It did mention the current working directory (or its directory, same thing) as the install source, which confused me. Probably as long as system.tgz exists where it expects, it shouldn't say anything. Also, even if the documentation is clear, its good to have as little to document as possible. Be as similar to other "things" as possible so nobody needs the patience to read/understand/learn. There is a time for that, but not when you are "about to make a sale" and user is just trying to get the thing working asap. - Jay ________________________________ > > >> Date: Thu, 25 Jun 2009 18:52:06 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) >> >> Quoting hendrik at topoi.pooq.com: >> >>> Next I run ./cminstall /usr/local/cm3 >>> >>> It asks mme whether /home.hendrik/cm3 is to be the root directory for >>> cm3. The naive user doesn't know what that means. Nor do I, for that >> >> This is strange. cminstall shouldn't ask any questions by default. >> But as mentioned before, I only built the archives for FreeBSD4 and >> AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package >> there? Or am I misunderstanding something here? >> >> From jay.krell at cornell.edu Fri Jun 26 11:00:22 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 09:00:22 +0000 Subject: [M3devel] files larger than 2gig In-Reply-To: <20090626100854.ox2rmkey8o0k4gk4@mail.elegosoft.com> References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> <20090624231005.GA32180@topoi.pooq.com> <20090626100854.ox2rmkey8o0k4gk4@mail.elegosoft.com> Message-ID: > what exactly is portable C??? It may be a little bit elusive, but I think it is certainly possible. Think of how many packages out there that you just download, extract, configure, and make. Think of how much or how little per-system was put into them. Think of how much or how little configure (autoconf) does, and how applicable it is to CM3. > performance of the compiler > performance of the produced code (missing > optimizations) Understood the compiler would be slow. It is slow already, but this would likely be worse. It should be possible to still get reasonable optimization but I don't really know. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 10:08:54 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] files larger than 2gig > > Quoting Jay : > >> >> ---------------------------------------- >>> Date: Wed, 24 Jun 2009 19:10:05 -0400 >>> From: hendrik at topoi.pooq.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] files larger than 2gig >>> >>> On Mon, Jun 22, 2009 at 12:58:45PM -0400, Tony Hosking wrote: >>>> >>>> Yuck. Why not decompose in the backend? >>> >>> However we do it, large files should "just work" on systems that can >>> handle them. >>> >>> -- hendrik >> >> >> It should be LONGINT. >> I'll try to get to it. >> It might be a slightly breaking change, depending on where the >> INTEGER size is exposed. >> >> >> That shouldn't be difficult and will address all but one platform. >> I'll try to get back to revisiting LONGINT support on NT386. >> Then it might be interesting, though not easy, to port that backend >> to more platforms. :) >> One reason to do all those wierdo ports is to set a bar for >> what an integrated backend should strive for. :) >> Or then again again again, a C generator. That way, there'd be a chance >> of "no more porting work". If the IL was slightly abstracted, we could >> just generate portable C and release just one >> portable source-ish package for all platforms. >> There could still be binary packages for people that don't build from source, >> but all platforms would just be a C compiler away. > > It has been done that way in the first SRC compilers. m3make was just > a wrapper generating makefiles, and the compiler produced C as an intermediate > language. It was found to be rather suboptiomal for various reasons AFAIR: > performance of the compiler, performance of the produced code (missing > optimizations), missing C standardization (what exactly is portable C???), ... > > Of course I wouldn't object a C generating backend at all, but we should > very carefully compare its benefits with the existing backends before > abandoning any of them. > > 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 Fri Jun 26 11:01:51 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 09:01:51 +0000 Subject: [M3devel] upgrade.sh CFGD code seems wrong/dead? In-Reply-To: <20090626100144.g3ciia3szocgsws0@mail.elegosoft.com> References: <20090626100144.g3ciia3szocgsws0@mail.elegosoft.com> Message-ID: I don't think the FHS matters here. I don't want to get too far into the business of supporting people (even admins) editing these files. Nor do I want to avoid overwriting or merging their changes for later releases. Ideally, people should be as quick to edit cm3.cfg as they are to edit any bash/perl/python in /usr or to rebuild cm3 from source. But that might not be possible. There might also be decisions for which one size does not fit all. It is easy to see that. What cminstall used to prompt about are some where user /might/ want a different choice, but which there are also defaults that suit the majority of folks. It is a little unclear. Like, if postgres/odbc are in the location used by the platform's port/package system, or did user get "upstream directly" and it went in a different default like /usr/local? Or do they have a custom install location? Like, if they want to run a particular gcc by full path, or if the first in $PATH is what they want? First in $PATH is certainly very common, but so are other options, like gcc-version. I guess, ideally, more of the code is moved into cm3, leaving cm3.cfg really only for things people can edit freely. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 10:01:44 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: upgrade.sh CFGD code seems wrong/dead? > > Quoting Jay : > >> >> This block in upgrade.sh seems dead, given that nothing sets CFGD. >> >> Searching for 'CFGD'... >> C:\dev2\cm3.2\scripts\upgrade.sh(95): cp -v ${f} ${CFGD}/${b} >> >> >> if [ "${UPGRADE_CM3_CFG}" = "yes" -o "${ret}" != 0 ]; then ( >> .... >> >> >> I'd like to move the config files to root/bin/config instead of >> littering bin. Ok? > > No. This would just be another directory which does not conform to > FSH standards. I already extended cm3 to search for config files > in various /etc directories, though that's still untested. > > I'd prefer that we don't move config files _now_ before the release, > but if you want to do it, test it: > > o move them to cm3/etc > o test cm3 with that setup on at least one platform > o adapt scripts for regression etc. as you deem necessary > o watch tinderbox results and fix again ;-) > >> >> This is one of the few places that is related to that. > > As for your question above, I cannot say without browsing and grepping > the code which I cannot do from here (isolated network); perhaps tonight... > > 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 wagner at elegosoft.com Fri Jun 26 12:05:51 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 12:05:51 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: 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> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> Quoting Jay : > > I tested the LINUXLIBC6 archive and it installed ok, no prompting. > > I ran it with no parameters -- unlike Henrik. It did mention the > current working directory (or its directory, same thing) as the > install source, which confused me. Probably as long as system.tgz > exists where it expects, it shouldn't say anything. Strange. Hendrik, can you reproduce the strange message? And then perhaps provide a system call trace (ktrace, truss, whatever)? Olaf > Also, even if the documentation is clear, its good to have as little > to document as possible. > Be as similar to other "things" as possible so nobody needs the > patience to read/understand/learn. > There is a time for that, but not when you are "about to make a > sale" and user is just trying to get the thing working asap. > > > - Jay > > > ________________________________ >> >> >>> Date: Thu, 25 Jun 2009 18:52:06 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: >>> Release engineering) >>> >>> Quoting hendrik at topoi.pooq.com: >>> >>>> Next I run ./cminstall /usr/local/cm3 >>>> >>>> It asks mme whether /home.hendrik/cm3 is to be the root directory for >>>> cm3. The naive user doesn't know what that means. Nor do I, for that >>> >>> This is strange. cminstall shouldn't ask any questions by default. >>> But as mentioned before, I only built the archives for FreeBSD4 and >>> AMD64_LINUX (and later PPC_DARWIN). Jay, what exactly did you package >>> there? Or am I misunderstanding something here? >>> > >>> -- 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 Fri Jun 26 12:08:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 12:08:47 +0200 Subject: [M3devel] files larger than 2gig In-Reply-To: References: <20090622163003.q4yfbtg80kcg0k0s@mail.elegosoft.com> <20090624231005.GA32180@topoi.pooq.com> <20090626100854.ox2rmkey8o0k4gk4@mail.elegosoft.com> Message-ID: <20090626120847.4i11xyq5es4ggcg4@mail.elegosoft.com> Quoting Jay : > >> what exactly is portable C??? > > > It may be a little bit elusive, but I think it is certainly possible. > Think of how many packages out there that you just download, extract, > configure, I wasn't aware that configure is now part of the C standards ;-) > and make. Think of how much or how little per-system > was put into them. Think of how much or how little configure (autoconf) does, > and how applicable it is to CM3. -- 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 Fri Jun 26 14:00:11 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 12:00:11 +0000 Subject: [M3devel] archive bloat Message-ID: Olaf I think you should trim the archives more. They have lots of intermediate files used to build cm3cg, including the identical copy m3cgc1, various static libraries, etc. I also don't see the utility of the Modula-3 standalone libraries for which we include what they built into, e.g. libm3back.a, libm3objfile.a, libm3front.a, libm3quake.a. I'm also not sure what all the CVS files end up doing. Do the make a checkout go fast? But surely..they are slightly wrong? I realize now that the reason lzma didn't always help is because the archives contain system.tgz. - Jay From wagner at elegosoft.com Fri Jun 26 14:18:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 14:18:49 +0200 Subject: [M3devel] archive bloat In-Reply-To: References: Message-ID: <20090626141849.mw5uo0zahw4k80og@mail.elegosoft.com> Quoting Jay : > > Olaf I think you should trim the archives more. They have lots of > intermediate files used to build cm3cg, including the identical copy > m3cgc1, various static libraries, etc. That's because the archives are simply pre-built workspace parts. > I also don't see the utility of the Modula-3 standalone libraries > for which we include what they built into, e.g. libm3back.a, > libm3objfile.a, libm3front.a, libm3quake.a. These are surely needed for shipping. > I'm also not sure what all the CVS files end up doing. > Do the make a checkout go fast? > But surely..they are slightly wrong? It's the CVS meta information; we can prune that if necessary. A generic way to prune the bin-ws archives would be to remove everything that's not relevant for shipping, i.e. contained in .M3SHIP. I'll have a look at that later. > I realize now that the reason lzma didn't always help is because the > archives contain system.tgz. 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 Fri Jun 26 14:29:19 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 12:29:19 +0000 Subject: [M3devel] archive bloat In-Reply-To: <20090626141849.mw5uo0zahw4k80og@mail.elegosoft.com> References: <20090626141849.mw5uo0zahw4k80og@mail.elegosoft.com> Message-ID: > These are surely needed for shipping. They are not. shipping doesn't require shipping dependencies. Only building does. And building has already occured. Shipping cm3 doesn't do much anyway. It ships the man page, ok. And it ships the binary to a place other than where it is used, because cm3 is special. I checked, the following works: I already have a full enough package store. cd m3-sys/cm3 cm3 cm3 -ship rm -rf /cm3/pkg/m3front /cm3/pkg/middle /cm3/pkg/m3quake cm3 -ship > That's because the archives are simply pre-built workspace parts. Still... What do we gain by shipping the non-source part of the workspace? People can do incremental builds? In the future, if the package build / install split is earlier, it could ease cross packaging, but currently? Packaging the source with each architecture is wasteful, but it does address version skew. The binaries come with matching source. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 14:18:49 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] archive bloat > > Quoting Jay : > >> >> Olaf I think you should trim the archives more. They have lots of >> intermediate files used to build cm3cg, including the identical copy >> m3cgc1, various static libraries, etc. > > That's because the archives are simply pre-built workspace parts. > >> I also don't see the utility of the Modula-3 standalone libraries >> for which we include what they built into, e.g. libm3back.a, >> libm3objfile.a, libm3front.a, libm3quake.a. > > These are surely needed for shipping. > >> I'm also not sure what all the CVS files end up doing. >> Do the make a checkout go fast? >> But surely..they are slightly wrong? > > It's the CVS meta information; we can prune that if necessary. > > A generic way to prune the bin-ws archives would be to remove > everything that's not relevant for shipping, i.e. contained in > .M3SHIP. I'll have a look at that later. > >> I realize now that the reason lzma didn't always help is because the >> archives contain system.tgz. > > 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 Jun 26 14:38:28 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 26 Jun 2009 05:38:28 -0700 Subject: [M3devel] archive bloat In-Reply-To: Your message of "Fri, 26 Jun 2009 12:29:19 -0000." Message-ID: <200906261238.n5QCcSCv026471@camembert.async.caltech.edu> Woudln't not including libm3back.a (e.g.) be a special case? What if I write another program, call it "cm4", that imports the m3back package... what does it link against? Mika Jay writes: > >> These are surely needed for shipping. > >They are not. >shipping doesn't require shipping dependencies. Only building does. And buildi >ng has already occured. >Shipping cm3 doesn't do much anyway. It ships the man page, ok. And it ships t >he binary to a place other than where it is used, because cm3 is special. > >I checked, the following works: > > I already have a full enough package store. > cd m3-sys/cm3 > cm3 > cm3 -ship > rm -rf /cm3/pkg/m3front /cm3/pkg/middle /cm3/pkg/m3quake > cm3 -ship > >> That's because the archives are simply pre-built workspace parts. > >Still... > >What do we gain by shipping the non-source part of the workspace? >People can do incremental builds? >In the future, if the package build / install split is earlier, it could ease >cross packaging, but currently? > > >Packaging the source with each architecture is wasteful, but it does address v >ersion skew. >The binaries come with matching source. > > > - Jay > > >---------------------------------------- >> Date: Fri, 26 Jun 2009 14:18:49 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] archive bloat >> >> Quoting Jay : >> >>> >>> Olaf I think you should trim the archives more. They have lots of >>> intermediate files used to build cm3cg, including the identical copy >>> m3cgc1, various static libraries, etc. >> >> That's because the archives are simply pre-built workspace parts. >> >>> I also don't see the utility of the Modula-3 standalone libraries >>> for which we include what they built into, e.g. libm3back.a, >>> libm3objfile.a, libm3front.a, libm3quake.a. >> >> These are surely needed for shipping. >> >>> I'm also not sure what all the CVS files end up doing. >>> Do the make a checkout go fast? >>> But surely..they are slightly wrong? >> > It's the CVS meta information; we can prune that if necessary. >> >> A generic way to prune the bin-ws archives would be to remove >> everything that's not relevant for shipping, i.e. contained in >> .M3SHIP. I'll have a look at that later. >> >>> I realize now that the reason lzma didn't always help is because the >>> archives contain system.tgz. >> >> 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 Jun 26 14:53:15 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 26 Jun 2009 05:53:15 -0700 Subject: [M3devel] archive bloat In-Reply-To: Your message of "Fri, 26 Jun 2009 12:47:24 -0000." Message-ID: <200906261253.n5QCrFcW027024@camembert.async.caltech.edu> I'm just saying, what you're proposing is an exception to how Modula-3 works. When you make a package and ship it, you always ship it with both interface and library files. Is it really warranted making a special exception for m3back, m3front, m3quake? Besides, how are you going to re-use the m3back package unless you add "cm4" to the main compiler distribution? I want to be able to maintain my own software separately from the CM3 distribution...and then you have to keep the sources around, too? Hrmph.... Mika Jay writes: > >Is it really meant to be reusable by anything other than cm3? >Even still, the workspace includes all the source. You can just build it if yo >u really need it. > > - Jay > > >---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Fri, 26 Jun 2009 05:38:28 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] archive bloat >> >> Woudln't not including libm3back.a (e.g.) be a special case? >> >> What if I write another program, call it "cm4", that imports the >> m3back package... what does it link against? >> >> Mika From jay.krell at cornell.edu Fri Jun 26 14:47:24 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 12:47:24 +0000 Subject: [M3devel] archive bloat In-Reply-To: <200906261238.n5QCcSCv026471@camembert.async.caltech.edu> References: Your message of "Fri, 26 Jun 2009 12:29:19 -0000." <200906261238.n5QCcSCv026471@camembert.async.caltech.edu> Message-ID: Is it really meant to be reusable by anything other than cm3? Even still, the workspace includes all the source. You can just build it if you really need it. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Fri, 26 Jun 2009 05:38:28 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] archive bloat > > Woudln't not including libm3back.a (e.g.) be a special case? > > What if I write another program, call it "cm4", that imports the > m3back package... what does it link against? > > Mika From jay.krell at cornell.edu Fri Jun 26 15:21:06 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 13:21:06 +0000 Subject: [M3devel] archive bloat In-Reply-To: <200906261253.n5QCrFcW027024@camembert.async.caltech.edu> References: Your message of "Fri, 26 Jun 2009 12:47:24 -0000." <200906261253.n5QCrFcW027024@camembert.async.caltech.edu> Message-ID: I guess even m3quake is maybe reusable, for anyone who wants to implement that scripting language. And I like the notion contrary to your point that all the Modula-3 source is together. It makes for easier/better testing, and more flexibility to change things. I was really just looking around for why the new archives are so large. The new core archive is twice the size of the old std. It includes source, probably even three copies of gcc. There is /some/ reason for that, and two of the copies are minimized, though still fairly unnecessary -- I386_INTERIX and ARM_DARWIN each have their own fork of gcc, a decision I remain comfortable with, but not clearly worth making so many more copies of. Compare http://modula3.elegosoft.com/cm3/uploaded-archives/index.html to http://www.opencm3.net/releng/ core in releng is twice the size or more of std in uploaded. I realize it is somewhat apples to oranges, but the uploaded archives I think (I'm checking..) do actually have source, for debugging, in the package store, and even these not very useful static libs. I guess the gcc stuff is the real difference. There is an option to have ship not ship the source actually, for further size savings, but then debugging suffers -- it'd be cool if the binaries contained CVS paths and versions and gdb could just get the source on-demand, as long as you are on the network.. Both sets also have symbols. There is a practise of stripping out the symbols into separate packages, at least on GNU systems (gcc/ld/gdb), but I haven't looked into it and the convenience for debugging of keeping the symbols in the binary seems significant. So far I've chosen to keep that. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Fri, 26 Jun 2009 05:53:15 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] archive bloat > > > I'm just saying, what you're proposing is an exception to how Modula-3 > works. When you make a package and ship it, you always ship it with > both interface and library files. Is it really warranted making a special > exception for m3back, m3front, m3quake? > > Besides, how are you going to re-use the m3back package unless you > add "cm4" to the main compiler distribution? I want to be able to > maintain my own software separately from the CM3 distribution...and > then you have to keep the sources around, too? Hrmph.... > > Mika > > Jay writes: >> >>Is it really meant to be reusable by anything other than cm3? >>Even still, the workspace includes all the source. You can just build it if yo >>u really need it. >> >> - Jay >> >> >>---------------------------------------- >>> To: jay.krell at cornell.edu >>> Date: Fri, 26 Jun 2009 05:38:28 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] archive bloat >>> >>> Woudln't not including libm3back.a (e.g.) be a special case? >>> >>> What if I write another program, call it "cm4", that imports the >>> m3back package... what does it link against? >>> >>> Mika From jay.krell at cornell.edu Fri Jun 26 15:32:22 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 13:32:22 +0000 Subject: [M3devel] dead links Message-ID: http://www.opencm3.net/doc/help/gen_html/dirfp/INDEX.html and surely all the rest contain links to CVS files, of suspicious utility, that are actually dead. http://www.opencm3.net/releng/collection-core.html The links there to browse source don't work, er, at least specifically the first three -- m3core, m3cc, import-libs. Several others do work. Some have the CVS files, some don't. There are some unusual manual page links..which aren't exactly broken, but oddly placed and inconsistent. "Some Useful odula-3 Interfaces" is missing the M in Modula-3 (still in collection-core.html). The first link in: http://www.opencm3.net/releng/collection-obliq.html doesn't work, to polymtl. Much more to check, there's a lot of new stuff and/or stuff I've never looked at... - Jay From jay.krell at cornell.edu Fri Jun 26 15:38:54 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 13:38:54 +0000 Subject: [M3devel] suggest auto detect client architecture in web page Message-ID: You know how you go to the Firefox download page and it offers you "only" the right download for your machine, and then has a link for other systems or older versions? That'd be nice. It's presumably "just a little bit of jscript to sniff the agent string". At the least, the list of systems should link down to their files. But just hiding the whole thing like Firefox et. al. I think is much preferred. I finally found simple documentation about building Debian packages, that doesn't get bogged down in all the source building apparatus. So I'll very maybe do something there, like integrate it into make-dist.sh. You don't even need any special tools, just tar, gzip, and ar. It's so easy, for a minimal not exactly officially good enough package, I can explain it in a few sentences and it'll take very little code. - Jay From hendrik at topoi.pooq.com Fri Jun 26 17:06:45 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 26 Jun 2009 11:06:45 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: References: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> Message-ID: <20090626150644.GA4554@topoi.pooq.com> On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: > > There's no need for Winzip if we use .zip files, explorer handles them. > > It is also easy to make self extracting .zip files. That's the way to go -- it's the popular archive format for Windows, security be damned! > > And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. > > > - Jay From hendrik at topoi.pooq.com Fri Jun 26 17:12:38 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 26 Jun 2009 11:12:38 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> References: <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> Message-ID: <20090626151238.GB4554@topoi.pooq.com> On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: > Quoting Jay : > > > > >I tested the LINUXLIBC6 archive and it installed ok, no prompting. > > > >I ran it with no parameters -- unlike Henrik. It did mention the > >current working directory (or its directory, same thing) as the > >install source, which confused me. Probably as long as system.tgz > >exists where it expects, it shouldn't say anything. > > Strange. > > Hendrik, can you reproduce the strange message? And then perhaps > provide a system call trace (ktrace, truss, whatever)? > > Olaf I'll try. I'll probably have to rm -r /user/local/cm3 first. Anything else I need to watch out for? Now that I think of resetting ... I still had the old cm3-min unpacked somewhere else, and I add its bin directory to the $PATH on a bash startup. Could that have be affecting the results? -- hendrik From hendrik at topoi.pooq.com Fri Jun 26 17:17:07 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 26 Jun 2009 11:17:07 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: References: <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626150644.GA4554@topoi.pooq.com> Message-ID: <20090626151707.GC4554@topoi.pooq.com> On Fri, Jun 26, 2009 at 03:19:44PM +0000, Jay wrote: > > Security not be damned. > You can sign executables. > You can open them in winzip instead if you want (if they are self extracting .zips). True. But most of the WIndows users I know just execute them. Their problem. not ours. If ours executes properly, that is. > Where is the line between running the installer vs. running the code > it installs, anyway? The disaster is faster. There's less time for antivirus tools to detect trouble. But let's not start a long thread about how to make Wiondows secure. Not our job. > I guess the installer runs maybe privileged and its payload does not. > But that isn't required for cm3, you can install to $HOME. > People also often just distribute non-self-running .MSI files. > That would be a good option. > > - Jay > > > ---------------------------------------- > > Date: Fri, 26 Jun 2009 11:06:45 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > > > On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: > >> > >> There's no need for Winzip if we use .zip files, explorer handles them. > >> > >> It is also easy to make self extracting .zip files. > > > > That's the way to go -- it's the popular archive format for Windows, security > > be damned! > > > >> > >> And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. > >> > >> > >> - Jay From jay.krell at cornell.edu Fri Jun 26 17:19:44 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 15:19:44 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090626150644.GA4554@topoi.pooq.com> References: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626150644.GA4554@topoi.pooq.com> Message-ID: Security not be damned. You can sign executables. You can open them in winzip instead if you want (if they are self extracting .zips). Where is the line between running the installer vs. running the code it installs, anyway? I guess the installer runs maybe privileged and its payload does not. But that isn't required for cm3, you can install to $HOME. People also often just distribute non-self-running .MSI files. That would be a good option. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 11:06:45 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: >> >> There's no need for Winzip if we use .zip files, explorer handles them. >> >> It is also easy to make self extracting .zip files. > > That's the way to go -- it's the popular archive format for Windows, security > be damned! > >> >> And untrusting users can just run unzip on them or rename them to .zip and open with Explorer, it's quite nice, except that for running, they don't run on many systems. >> >> >> - Jay From jay.krell at cornell.edu Fri Jun 26 17:29:29 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 15:29:29 +0000 Subject: [M3devel] no need to import direct dependencies if also indirectly dependent? In-Reply-To: <20090626152312.67AE6CC360@birch.elegosoft.com> References: <20090626152312.67AE6CC360@birch.elegosoft.com> Message-ID: Hm, it looks like there is both a direct and indirect dependency here on sysutils. indirect through m3quake direct use of TextUtils Shouldn't the builder /ideally/ require you do import directly what you directly depend on? (and not import directly what you indirectly depend on, already correct) Or would that be a bit inconvenient? I don't care really, I'm not pushing for a change, but wouldn't that generally be the right design? - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 17:23:12 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/06/26 17:23:12 > > Modified files: > cm3/m3-sys/cminstall/src/: m3makefile > > Log message: > go back a version -- there is an indirect dependency on sysutils so this is ok to leave as a sort of comment, though it is not needed, and it might cause the dependency to stick even if the indirect one goes away? > From wagner at elegosoft.com Fri Jun 26 17:59:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 17:59:55 +0200 Subject: [M3devel] archive bloat In-Reply-To: References: <20090626141849.mw5uo0zahw4k80og@mail.elegosoft.com> Message-ID: <20090626175955.pvanjmxce0wgcgcw@mail.elegosoft.com> Quoting Jay : > >> These are surely needed for shipping. > > They are not. > shipping doesn't require shipping dependencies. Only building does. > And building has already occured. > Shipping cm3 doesn't do much anyway. It ships the man page, ok. And > it ships the binary to a place other than where it is used, because > cm3 is special. > > I checked, the following works: > > I already have a full enough package store. > cd m3-sys/cm3 > cm3 > cm3 -ship > rm -rf /cm3/pkg/m3front /cm3/pkg/middle /cm3/pkg/m3quake > cm3 -ship > >> That's because the archives are simply pre-built workspace parts. > > Still... > > What do we gain by shipping the non-source part of the workspace? > People can do incremental builds? > In the future, if the package build / install split is earlier, it > could ease cross packaging, but currently? > > Packaging the source with each architecture is wasteful, but it does > address version skew. > The binaries come with matching source. m3quake and m3middle etc. are packages which are useful on their own. I don't think providing partial installation packages is the way to go. 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 rcolebur at scires.com Fri Jun 26 18:24:47 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Fri, 26 Jun 2009 12:24:47 -0400 Subject: [M3devel] log messages for committed changes In-Reply-To: <20090626081242.DE6C6CC306@birch.elegosoft.com> References: <20090626081242.DE6C6CC306@birch.elegosoft.com> Message-ID: <4A44BE0C.1E75.00D7.1@scires.com> Hey, I've seen several of these type messages (see below). My question is "WHY"? Just to state that it doesn't need to be standalone begs the question why was it made standalone in the first place and what is the reason why it no longer needs to be that way. Maybe this is part of a larger rant on my part, but when folks commit changes, I would encourage everyone to provide some rationale and detail in the log message. There are few people like Olaf and Tony that have enough perspective with the whole system to be able to look at the details of what was changed and try to reverse something that goes against core principals or that will cause problems elsewhere. For the rest of us, and for documentation of the system evolution, it is important that the log messages be as detailed as possible, at least to give the rationale why a change is being made. I know documentation is not glamorous and doesn't directly affect the code, but it is nonetheless important, and if done well can be a real benefit. Thanks for listening. I'll step down off my soapbox now. Regards, Randy Coleburn >>> Jay Krell 6/26/2009 10:12 AM >>> CVSROOT:/usr/cvs Changes by:jkrell at birch.09/06/26 10:12:42 Modified files: cm3/m3-sys/m3cgcat/src/: m3makefile Log message: This doesn't need to be standalone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Fri Jun 26 18:40:35 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 26 Jun 2009 16:40:35 +0000 Subject: [M3devel] [M3commit] log messages for committed changes In-Reply-To: <4A44BE0C.1E75.00D7.1@scires.com> References: <20090626081242.DE6C6CC306@birch.elegosoft.com> <4A44BE0C.1E75.00D7.1@scires.com> Message-ID: I was thinking of starting an email thread on this. I believe the reasons to make things standalone are: - unshipped built-global tools run during the build, such as m3bundle, stub generators, PklFonts, etc. I think these could be addressed but it'd take some work. - "Tony's convenience", still being discussed. A think this was a stronger case prior to -rpath where having "separate runnable backups" was more difficult. Or perhaps still since -rpath isn't yet everywhere, AMD64_DARWIN in particular. Personally when I revert to a backup I copy it back to the real place, sometimes with an entire package store, but it is reasonable to not have to do that, and even reasonable to reduce it to one file instead of roughly three in two directories. This would really only apple to cm3 and m3cgcat. For it to include m3cggen would definitely be surprising. It is also "nice to have" cm3 statically linked because when cross building to a new platform, you don't have to get shared libraries working before running cm3. But you could toggle that for this scenario. I had thought there was also a requirement around bootstrapping from an older build, where old cm3 can't build new m3core/libm3, but I don't see that now. - inability on some platforms to ship in use files, could be worked around, but partly related to previous, and more than that; in particular cm3 shouldn't ship m3core.so/libm3.so that it uses, if you intend to run that cm3 again - possibly so they can be redistributed with fewer files This is the typical reason in the larger world for reducing dynamic linking, as well to be independent of changes to those files. But I don't think "we" intend that to happen for "our" stuff. And I think we intend for now to always ship everything together, so versioning and compatibility can be ignored. I think. There are still a few sprinkled standalones, like in games. Which is why I was going to start email. If someone really wanted to copy solitaire around without installing its dependencies, rebuild it from source? - cminstall, because it runs so early Though this could be addressed via -rpath = $ORIGIN and putting the .so files it needs next to it, and not duplicating them. The reason to make things not standalone is several efficiency gains. You share the code in memory, you share it on disk, you don't copy it around as many times, locally or over the network. The savings are generally pretty large. - Jay ________________________________ > Date: Fri, 26 Jun 2009 12:24:47 -0400 > From: rcolebur at scires.com > To: m3commit at elegosoft.com; m3devel at elegosoft.com > Subject: [M3commit] log messages for committed changes > > > > > > > > Hey, I've seen several of these type messages (see below). My question is "WHY"? Just to state that it doesn't need to be standalone begs the question why was it made standalone in the first place and what is the reason why it no longer needs to be that way. > > > > Maybe this is part of a larger rant on my part, but when folks commit changes, I would encourage everyone to provide some rationale and detail in the log message. > > > > There are few people like Olaf and Tony that have enough perspective with the whole system to be able to look at the details of what was changed and try to reverse something that goes against core principals or that will cause problems elsewhere. For the rest of us, and for documentation of the system evolution, it is important that the log messages be as detailed as possible, at least to give the rationale why a change is being made. I know documentation is not glamorous and doesn't directly affect the code, but it is nonetheless important, and if done well can be a real benefit. > > > > Thanks for listening. I'll step down off my soapbox now. > > > > Regards, > > Randy Coleburn > > >>>> Jay Krell 6/26/2009 10:12 AM>>> > CVSROOT:/usr/cvs > Changes by:jkrell at birch.09/06/26 10:12:42 > > Modified files: > cm3/m3-sys/m3cgcat/src/: m3makefile > > Log message: > This doesn't need to be standalone. > > From hosking at cs.purdue.edu Fri Jun 26 20:17:21 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 26 Jun 2009 14:17:21 -0400 Subject: [M3devel] [M3commit] log messages for committed changes In-Reply-To: References: <20090626081242.DE6C6CC306@birch.elegosoft.com> <4A44BE0C.1E75.00D7.1@scires.com> Message-ID: For M3 system development tools like m3cgcat m3cggen, standalone is generally best. True, most users don't need to ship those tools. On 26 Jun 2009, at 12:40, Jay wrote: > > I was thinking of starting an email thread on this. > > > I believe the reasons to make things standalone are: > > - unshipped built-global tools run during the build, such as > m3bundle, stub generators, PklFonts, etc. > I think these could be addressed but it'd take some work. > > > - "Tony's convenience", still being discussed. > A think this was a stronger case prior to -rpath where having > "separate runnable backups" > was more difficult. Or perhaps still since -rpath isn't yet > everywhere, AMD64_DARWIN in particular. > Personally when I revert to a backup I copy it back to the real > place, sometimes > with an entire package store, > but it is reasonable to not have to do that, and even reasonable > to reduce it to one file > instead of roughly three in two directories. > This would really only apple to cm3 and m3cgcat. For it to > include m3cggen would > definitely be surprising. > It is also "nice to have" cm3 statically linked because when > cross building to a new > platform, you don't have to get shared libraries working before > running cm3. But > you could toggle that for this scenario. > > I had thought there was also a requirement around bootstrapping > from an older > build, where old cm3 can't build new m3core/libm3, but I don't > see that now. > > - inability on some platforms to ship in use files, could be worked > around, but > partly related to previous, and more than that; in particular cm3 > shouldn't ship > m3core.so/libm3.so that it uses, if you intend to run that cm3 > again > > > - possibly so they can be redistributed with fewer files > This is the typical reason in the larger world for reducing > dynamic linking, > as well to be independent of changes to those files. > But I don't think "we" intend that to happen for "our" stuff. > And I think we intend for now to always ship everything together, > so versioning and compatibility can be ignored. I think. > There are still a few sprinkled standalones, like in games. > Which is why I was going to start email. > If someone really wanted to copy solitaire around without > installing its dependencies, > rebuild it from source? > > > - cminstall, because it runs so early > Though this could be addressed via -rpath = $ORIGIN and putting > the .so files it needs next to it, and not duplicating them. > > > The reason to make things not standalone is several efficiency gains. > You share the code in memory, you share it on disk, you don't copy > it around > as many times, locally or over the network. The savings are > generally pretty large. > > > - Jay > > > ________________________________ >> Date: Fri, 26 Jun 2009 12:24:47 -0400 >> From: rcolebur at scires.com >> To: m3commit at elegosoft.com; m3devel at elegosoft.com >> Subject: [M3commit] log messages for committed changes >> >> >> >> >> >> >> >> Hey, I've seen several of these type messages (see below). My >> question is "WHY"? Just to state that it doesn't need to be >> standalone begs the question why was it made standalone in the >> first place and what is the reason why it no longer needs to be >> that way. >> >> >> >> Maybe this is part of a larger rant on my part, but when folks >> commit changes, I would encourage everyone to provide some >> rationale and detail in the log message. >> >> >> >> There are few people like Olaf and Tony that have enough >> perspective with the whole system to be able to look at the details >> of what was changed and try to reverse something that goes against >> core principals or that will cause problems elsewhere. For the rest >> of us, and for documentation of the system evolution, it is >> important that the log messages be as detailed as possible, at >> least to give the rationale why a change is being made. I know >> documentation is not glamorous and doesn't directly affect the >> code, but it is nonetheless important, and if done well can be a >> real benefit. >> >> >> >> Thanks for listening. I'll step down off my soapbox now. >> >> >> >> Regards, >> >> Randy Coleburn >> >> >>>>> Jay Krell 6/26/2009 10:12 AM>>> >> CVSROOT:/usr/cvs >> Changes by:jkrell at birch.09/06/26 10:12:42 >> >> Modified files: >> cm3/m3-sys/m3cgcat/src/: m3makefile >> >> Log message: >> This doesn't need to be standalone. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jun 26 21:12:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 21:12:32 +0200 Subject: [M3devel] dead links In-Reply-To: References: Message-ID: <20090626211232.p2z8n0bqosk44skg@mail.elegosoft.com> Quoting Jay : > http://www.opencm3.net/doc/help/gen_html/dirfp/INDEX.html > > and surely all the rest contain links to CVS files, of suspicious > utility, that are actually dead. > > http://www.opencm3.net/releng/collection-core.html > > The links there to browse source don't work, er, at least > specifically the first three -- m3core, m3cc, import-libs. Several > others do work. Some have the CVS files, some don't. > There are some unusual manual page links..which aren't exactly > broken, but oddly placed and inconsistent. > > "Some Useful odula-3 Interfaces" is missing the M in Modula-3 (still > in collection-core.html). These should be fixed now. If I've missed something, let me know... > The first link in: > http://www.opencm3.net/releng/collection-obliq.html > > doesn't work, to polymtl. Hm, we need to replace that in our doc then. I noticed other broken links to DEC amd others, too, in doc. > Much more to check, there's a lot of new stuff and/or stuff I've > never looked at... > > - 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 Fri Jun 26 22:10:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Jun 2009 22:10:28 +0200 Subject: [M3devel] LINUXLIBC6 on 64 bit Hardware Message-ID: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> I Installed the LINUXLIBC6 archives from Jay on birch in my home directory without problems. Trying to build package m3core fails at the last step with ... fgrep m3gcdefs /home/wagner/cm3-LINUXLIBC6/pkg/m3core/LINUXLIBC6/.M3EXPORTS 2>/dev/null >/dev/null gcc -gstabs+ -m32 -fPIC -mno-align-double -z now -z origin -Bsymbolic -Wl,--fatal-warnings -Wl,-rpath,\$ORIGIN/../lib -Wl,--warn-common -Wl,-rpath,/home/wagner/cm3-LINUXLIBC6/lib -shared -Wl,-soname,libm3core.so.5 -o libm3core.so.5 hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTTipe.io RTTipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSmmap.o RTThread.io RTThreadStk.mo RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTMachine.io RTThread.mo RTThreadC.o RTExFrame.io RTExFrame.mo RTStackC.o Thread.io Scheduler.io SchedulerPosix.io MutexRep.io ThreadEvent.io ThreadF.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo WinNTc.o UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uucontext.o Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Upthread.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Usysdep.io Usignal.io Uucontext.io Upthreadtypes.io Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io Ctypes.io M3toC.io M3toC.mo CerrnoC.o Cstring.io Cstdio.io Csignal.io Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo DateBsd.mo TimePosix.io TimePosix.mo CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo PolyBasis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo -lm -lpthread /usr/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3core Fatal Error: package build failed rm m3make.args cd .. birch [~/work/cm3] wagner % type gcc gcc is /usr/bin/gcc birch [~/work/cm3] wagner % gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) I don't see gcc_s in the link command, and on birch there _is_ /lib/libgcc_s.so.1 Any ideas? 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 Fri Jun 26 22:46:45 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 26 Jun 2009 13:46:45 -0700 Subject: [M3devel] LINUXLIBC6 on 64 bit Hardware In-Reply-To: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> References: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> Message-ID: Surely a 32 on 64 thing. Try a 32 bit system? We would probably be ok with static libgcc. - Jay (phone) On Jun 26, 2009, at 1:10 PM, Olaf Wagner wrote: > I Installed the LINUXLIBC6 archives from Jay on birch in my home > directory without problems. > > Trying to build package m3core fails at the last step with > > ... > fgrep m3gcdefs /home/wagner/cm3-LINUXLIBC6/pkg/m3core/ > LINUXLIBC6/.M3EXPORTS 2>/dev/null >/dev/null > gcc -gstabs+ -m32 -fPIC -mno-align-double -z now -z origin - > Bsymbolic -Wl,--fatal-warnings -Wl,-rpath,\$ORIGIN/../lib -Wl,--warn- > common -Wl,-rpath,/home/wagner/cm3-LINUXLIBC6/lib -shared -Wl,- > soname,libm3core.so.5 -o libm3core.so.5 hand.o dtoa.o libgcc.o > RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo > Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io > RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io > RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo > RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo > RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTLinkerX.io > RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTError.io > RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo > RTMisc.io RTMisc.mo RTModule.io RTPacking.io RTPacking.mo > RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io > RTProcess.mo RTTipe.io RTTipe.mo RTType.io RTType.mo RTTypeFP.io > RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo > RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io > RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io > RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSmmap.o RTThread.io > RTThreadStk.mo RTSignalPrivate.io RTSignalC.o RTSignalC.io > RTSignal.mo RTMachine.io RTThread.mo RTThreadC.o RTExFrame.io > RTExFrame.mo RTStackC.o Thread.io Scheduler.io SchedulerPosix.io > MutexRep.io ThreadEvent.io ThreadF.io ThreadPThread.io > ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io > WinDef.mo WinNT.io WinNT.mo WinNTc.o UtimeC.o UnixC.o UnixLink.o > Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o > Uucontext.o Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io > Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io > Upthread.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o > Usysdep.io Usignal.io Uucontext.io Upthreadtypes.io Uin.io Cerrno.io > Cstddef.io Cstdint.io Cstdlib.io Ctypes.io M3toC.io M3toC.mo > CerrnoC.o Cstring.io Cstdio.io Csignal.io Csetjmp.io BasicCtypes.io > RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io > IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io > DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io > RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io > FPU.io FPU.mo FloatMode.io FloatMode.mo Time.io Tick.io Date.io > FmtTime.io FmtTime.mo TickPortable.mo DateBsd.mo TimePosix.io > TimePosix.mo CConvert.io CConvert.mo Convert.io Convert.mo > String8.io String8.mo String16.io String16.mo Text.io Text.mo > TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io > Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo > Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io > TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo > Fingerprint.io Fingerprint.mo Poly.io Poly.mo PolyBasis.io > PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io > LongRep.io Long.io Word.mo Long.mo -lm -lpthread > /usr/bin/ld: cannot find -lgcc_s > collect2: ld returned 1 exit status > make_lib => 1 > librarian failed building: m3core > Fatal Error: package build failed > rm m3make.args > cd .. > birch [~/work/cm3] wagner > % type gcc > gcc is /usr/bin/gcc > birch [~/work/cm3] wagner > % gcc -v > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --enable-languages=c,c+ > +,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with- > system-zlib --libexecdir=/usr/lib --without-included-gettext -- > enable-threads=posix --enable-nls --program-suffix=-4.1 --enable- > __cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable- > mpfr --enable-checking=release x86_64-linux-gnu > Thread model: posix > gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) > > I don't see gcc_s in the link command, and on birch there _is_ > /lib/libgcc_s.so.1 > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > 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: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From eiserlohpp at yahoo.com Sat Jun 27 01:09:16 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 26 Jun 2009 16:09:16 -0700 (PDT) Subject: [M3devel] Manual Page for Quake Message-ID: <528453.41864.qm@web56801.mail.re3.yahoo.com> Okay guys, I took the web page describing the quake language, and formated it as a man page. http://www.eiserloh.org/~peter/modula3/#mydocs I hereby submit this for inclusion within the modula-3 archives. I hereby relinquish any rights to the (quake.man) and any derived files. This document is now in the public domain. NOTE: The original content was authored by Stephen Harrison, not me. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat Jun 27 02:45:34 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 00:45:34 +0000 Subject: [M3devel] link options (was LINUXLIBC6 on 64 bit Hardware) (rambly) In-Reply-To: <20090626232034.nbt6xg4sgws4w440@mail.elegosoft.com> References: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> <20090626232034.nbt6xg4sgws4w440@mail.elegosoft.com> Message-ID: [adding m3devel] ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: link options (was LINUXLIBC6 on 64 bit Hardware) (rambly) > Date: Sat, 27 Jun 2009 00:43:58 +0000 > > > ps: You don't see -lc there either. > Change SYSTEM_CC to include -Wl,-v or such and you can see what gcc feeds to ld, surely it'll have hints of -lc and -lgcc_s. Or gcc -dump-specs or somesuch. > You could try running that then without the -lgcc_s but you'll likely have unresolved externals related to 64 bit integers. libgcc is about more than 64 bit integers, also like C++ and Ada exception handling, but it seems like overkill for us. 64 bit systems shouldn't need it for 64 bit math, at least. > THe thing is, choice of shared libgcc or not, is that, you know, you /might/ be (static) linking your Modula-3 with some C++ code that uses exceptions, and you /might/ be /dynamically/ linking to other C++ code that throws exceptions and you might want interop, in which case shared libgcc is desired. > > > But then the common case is the "opposite" -- all Modula-3. > > > I think it is tenuous to have exceptions go across dynamic link boundaries, but some people think the line between dynamic and static linking should be quite blurry and things should work the "same" either way. > (Thus why the older symbol resolution algorithms where all symbols looked across all .so files, to emulate static linking, eventually/gradually replaced with "two level namespace". That is Apple's term and I think a good description of what everyone now favors even if they don't call it that; but then the defaults often unchanged for compatibility, Apple changed the default, NT was always this way (except maybe Interix)). > > > Actually, now that I think about it...this is stuff that actually needs to be controllable from each m3makefile, and possibly from the cm3 command line. > > I used to think it was a config file thing and I'd try to make a reasonable choice for everyone, but now I think it's not even a per-machine thing but more granular. Anyway, the default is reasonable, just that it should probably be changable. > > > So probably we should have new Quake directives that mimic gcc's command line options, like: > SharedLibGcc(); > StaticLibGcc(); > > > and they'd just be ignored on SOLsun, NT386, etc. > They'd just be trivially implemented in cm3cfg.common and set a global that m3_link adds to the link command line, very simple. > > > I guess this is a general exercise: See what switches in gcc/ld people tend to vary on a project by project basis, see which ones are relevant to Modula-3 (ie: more linking flags, not compile flags) and expose them in Quake. > AND/OR ensure it is/remains viable for people to use Makefiles, combine Modula-3 with gcc using Makefiles and gcc, and just using cm3 to build some pieces of their project. Personally I've never tried that. > That way, you know, they can just form their own link commands in a Makefile and Quake doesn' t have to provide full access. > Also we could make SYSTEM_LD not readonly and leaf m3makefiles could just munge it. > That is an easy way to add flexibility. > > > - Jay > > ---------------------------------------- >> Date: Fri, 26 Jun 2009 23:20:34 +0200 >> From: wagner >>>> >>>> I don't see gcc_s in the link command, and on birch there _is_ >>>> /lib/libgcc_s.so.1 >>>> >>>> Any ideas? >>>> >>>> Olaf From jay.krell at cornell.edu Sat Jun 27 03:35:49 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 01:35:49 +0000 Subject: [M3devel] PPC_DARWIN tinderbox Message-ID: Tony, this is your machine? It is only run once, in a while, and failed. Maybe an error in your defs.sh? - Jay From jay.krell at cornell.edu Sat Jun 27 06:33:12 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 04:33:12 +0000 Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress In-Reply-To: <4A45868C.3020001@cox.net> References: <4A4251D6.60804@cox.net> <4A45868C.3020001@cox.net> Message-ID: Right, definitely good to make the invasive changes minimal. Our diffs within gcc are quite small I found. Almost everything is adding the file parse.c CVS is supposed to help here, three way merge and all that, but there is only so much it can do. - Jay ---------------------------------------- > Date: Fri, 26 Jun 2009 21:40:12 -0500 > From: rodney.m.bates at cox.net > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3gdb/AMD64_LINUX, a little progress > > Jay wrote: >> You should try using cvs import to upgrade to a newer version, of the >> entire gdb tree (well, maybe prune it -- testsuites, sim, cpu, intl, >> etc..) >> I personally have never done this -- only recently imported the first >> version of stuff but haven't yet updated anything. > There is a _lot_ of merging work to get the m3gdb changes into a newer gdb > base, including a lot of manual cleanup. I've done it. More than > once. I plan to > do it again, real soon now, but this was a reckless attempt at something > quick > and dirty. Also, there is a newest gdb release 6/9 forthcoming soon, and I > think it would be nice to wait for it. > > I have been gradually pulling m3 support code out of gdb source files > and putting > into m3-*.c files, with only calls, etc in the original gdb source. > This should help > a bit for the next time around. But there is always lots of rework in > a later gdb > that requires corresponding rework to m3gdb. Things go away or are > replaced > by something redesigned, and it takes work to figure out what the > replacement is > and how to use it. >> >> - Jay >> >> >>> Date: Wed, 24 Jun 2009 11:18:30 -0500 >>> From: rodney.m.bates at cox.net >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress >>> >>> I have tracked down the problems I have seen with m3gdb on >>> AMD64_LINUX not recognizing object formats to a new section >>> type SHT_GNU_HASH, (and named .gnu.hash), which is present >>> in recent M3-compiled code. It appears to be handled by >>> the more recent binutils that comes in gdb 6.8, but it is >>> not handled by the binutils in gdb 6.4, from which m3gdb is >>> derived. >>> >>> I briefly tried a naive substitution of the new binutils >>> (directory 'bfd') into m3gdb, but some things have moved >>> around and there are build problems finding them. I will >>> work on this more when I get some time. >>> >>> Rodney Bates > From rodney.m.bates at cox.net Sat Jun 27 04:40:12 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Fri, 26 Jun 2009 21:40:12 -0500 Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress In-Reply-To: References: <4A4251D6.60804@cox.net> Message-ID: <4A45868C.3020001@cox.net> Jay wrote: > You should try using cvs import to upgrade to a newer version, of the > entire gdb tree (well, maybe prune it -- testsuites, sim, cpu, intl, > etc..) > I personally have never done this -- only recently imported the first > version of stuff but haven't yet updated anything. There is a _lot_ of merging work to get the m3gdb changes into a newer gdb base, including a lot of manual cleanup. I've done it. More than once. I plan to do it again, real soon now, but this was a reckless attempt at something quick and dirty. Also, there is a newest gdb release 6/9 forthcoming soon, and I think it would be nice to wait for it. I have been gradually pulling m3 support code out of gdb source files and putting into m3-*.c files, with only calls, etc in the original gdb source. This should help a bit for the next time around. But there is always lots of rework in a later gdb that requires corresponding rework to m3gdb. Things go away or are replaced by something redesigned, and it takes work to figure out what the replacement is and how to use it. > > - Jay > > > > Date: Wed, 24 Jun 2009 11:18:30 -0500 > > From: rodney.m.bates at cox.net > > To: m3devel at elegosoft.com > > Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress > > > > I have tracked down the problems I have seen with m3gdb on > > AMD64_LINUX not recognizing object formats to a new section > > type SHT_GNU_HASH, (and named .gnu.hash), which is present > > in recent M3-compiled code. It appears to be handled by > > the more recent binutils that comes in gdb 6.8, but it is > > not handled by the binutils in gdb 6.4, from which m3gdb is > > derived. > > > > I briefly tried a naive substitution of the new binutils > > (directory 'bfd') into m3gdb, but some things have moved > > around and there are build problems finding them. I will > > work on this more when I get some time. > > > > Rodney Bates From wagner at elegosoft.com Sat Jun 27 12:48:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 27 Jun 2009 12:48:03 +0200 Subject: [M3devel] link options (was LINUXLIBC6 on 64 bit Hardware) (rambly) In-Reply-To: References: <20090626221028.zyfj8i0llww88kcc@mail.elegosoft.com> <20090626232034.nbt6xg4sgws4w440@mail.elegosoft.com> Message-ID: <20090627124803.10mmxzjs0ks00040@mail.elegosoft.com> Quoting Jay : > [adding m3devel] > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> Subject: RE: link options (was LINUXLIBC6 on 64 bit Hardware) (rambly) >> Date: Sat, 27 Jun 2009 00:43:58 +0000 >> [...] >> Actually, now that I think about it...this is stuff that actually >> needs to be controllable from each m3makefile, and possibly from >> the cm3 command line. >> >> I used to think it was a config file thing and I'd try to make a >> reasonable choice for everyone, but now I think it's not even a >> per-machine thing but more granular. Anyway, the default is >> reasonable, just that it should probably be changable. >> >> So probably we should have new Quake directives that mimic gcc's >> command line options, like: >> SharedLibGcc(); >> StaticLibGcc(); Well, I'd have preferred some common abstraction, but then (a) making it more flexible for a certain backend is better than no flexibility at all and (b) perhaps common abstractions need to evolve gradually over time (or maybe there aren't any at all). So yes, I'm all for providing new quake switches, even if they are backend or system dependent. Of course they need to be documented in the operations guide and the quake language description, too. >> and they'd just be ignored on SOLsun, NT386, etc. >> They'd just be trivially implemented in cm3cfg.common and set a >> global that m3_link adds to the link command line, very simple. >> >> I guess this is a general exercise: See what switches in gcc/ld >> people tend to vary on a project by project basis, see which ones >> are relevant to Modula-3 (ie: more linking flags, not compile >> flags) and expose them in Quake. >> AND/OR ensure it is/remains viable for people to use Makefiles, >> combine Modula-3 with gcc using Makefiles and gcc, and just using >> cm3 to build some pieces of their project. Personally I've never >> tried that. >> That way, you know, they can just form their own link commands in a >> Makefile and Quake doesn' t have to provide full access. >> Also we could make SYSTEM_LD not readonly and leaf m3makefiles >> could just munge it. >> That is an easy way to add flexibility. Yes, I wouldn't object to that, too. 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 hosking at cs.purdue.edu Sat Jun 27 14:31:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Jun 2009 08:31:10 -0400 Subject: [M3devel] PPC_DARWIN tinderbox In-Reply-To: References: Message-ID: It just got booted up after a year away. Probably need to update. On 26 Jun 2009, at 21:35, Jay wrote: > > Tony, this is your machine? It is only run once, in a while, and > failed. > Maybe an error in your defs.sh? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jun 27 16:48:56 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 14:48:56 +0000 Subject: [M3devel] canonicalizepath?? Message-ID: DoMakeDir 1: /cm3/bin/../pkg/m3cggen/PPC_LINUX DoMakeDir 2: /cm3/bin/m3cggen/PPC_LINUX C:\dev2\cm3.2\m3-sys\m3quake\src\QMachine.m3 PROCEDURE DoMakeDir (t: T; n_args: INTEGER) RAISES {Error} = VAR val: QValue.T; dir, prefix: TEXT; BEGIN Pop (t, val); dir := QVal.ToText (t, val); prefix := Env.Get("CM3_INSTALL_PREFIX"); IF prefix # NIL THEN dir := prefix & dir; END; RTIO.PutText("DoMakeDir 1: " & dir & "\n"); dir := Pathname.Compose (CanonicalizePath (Pathname.Decompose (dir))); RTIO.PutText("DoMakeDir 2: " & dir & "\n"); RTIO.Flush(); MakeDir (t, dir); END DoMakeDir; huh? I don't think I've ever change this.. Am I expected to reverse the path before passing it through here? I'll just avoid this function.. - Jay From eiserlohpp at yahoo.com Sat Jun 27 17:04:50 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 27 Jun 2009 08:04:50 -0700 (PDT) Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Message-ID: <400447.39315.qm@web56807.mail.re3.yahoo.com> Hi Jay, On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: > > There's no need for Winzip if we use .zip files, explorer handles them. > > It is also easy to make self extracting .zip files. For installing applications on Windows boxes, why don't you use NSIS? http://nsis.sourceforge.net/Main_Page --- Quoting: From NSIS Wiki --- NSIS (Nullsoft Scriptable Install System) is a professional open source system to create Windows installers. It is designed to be as small and flexible as possible and is therefore very suitable for internet distribution. --- END QUOTE --- Please, if you go this route, don't include the source for NSIS into the M3 source archive, but the script you write that tells NSIS how to operate, yes that should be in the source archive. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat Jun 27 19:36:07 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 27 Jun 2009 17:36:07 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: In-Reply-To: <400447.39315.qm@web56807.mail.re3.yahoo.com> References: <400447.39315.qm@web56807.mail.re3.yahoo.com> Message-ID: Well, it probably is better than IExpress.exe but IExpress is super easy. I'll probably stick with it and if someone has something else to replace it with they can. - Jay ---------------------------------------- > Date: Sat, 27 Jun 2009 08:04:50 -0700 > From: eiserlohpp at yahoo.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: > > > Hi Jay, > > On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: >> >> There's no need for Winzip if we use .zip files, explorer handles them. >> >> It is also easy to make self extracting .zip files. > > > For installing applications on Windows boxes, why don't > you use NSIS? > > http://nsis.sourceforge.net/Main_Page > > > --- Quoting: From NSIS Wiki --- > > NSIS (Nullsoft Scriptable Install System) is a professional open source system to create Windows installers. It is designed to be as small and flexible as possible and is therefore very suitable for internet distribution. > > --- END QUOTE --- > > Please, if you go this route, don't include the source for > NSIS into the M3 source archive, but the script you write > that tells NSIS how to operate, yes that should be in the > source archive. > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ From eiserlohpp at yahoo.com Sun Jun 28 00:53:49 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 27 Jun 2009 15:53:49 -0700 (PDT) Subject: [M3devel] Quake documentation: readonly Message-ID: <825721.23887.qm@web56808.mail.re3.yahoo.com> In the quake documentation, in the SCOPE section the keyword "readonly" is very briefly defined in the following: To protect a name in the current scope, use readonly dec = "digital" If local or readonly are not used, all variables are located in the outermost (global) scope. Beware of side-effects! Question 1: what would happen if a script attempts to modify a readonly variable? Does it quitely fail, or verbosely complain? Question 2: if a readonly variable is declared at an outer scope, and later an inner one attempts to declare a new instance with that same name, does the new name simply cover the old name, or does the attempt to declare a conflicting local variable fail (quitely, or verbosely). Picking the last one above, can we clarify this to say: To declare a name in the local scope, and prevent any further changes to it after initialization, use "readonly". When a readonly declaration occurs in the outmost scope, then a readonly variable (i.e., a constant) is declared at the global scope, an prevents any local variable with this same name being declared locally. For example: readonly dec = "digital" Alternatively, picking new local declaration succeeds: To declare a name in the local scope, and prevent any further changes to it after initialization, use "readonly". When a readonly declaration occurs in the outermost scope, then a readonly variable (i.e., a constant) is declared at the global scope. A local declaration inside an inner scope will override the global name while in that inner scope. Specifically: I am looking at creating a user config file, intending to override some settings. Something like: ---- BEGIN example user config file ---- % override debugging format from stab+ to DWARF2 format. readonly m3back_flags = "-quiet -gdwarf2 -m64 -fPIC -mno-align-double" include("usr/cm3/etc/AMD64_LINUX") ---- END user config file ---- +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sun Jun 28 08:58:41 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 28 Jun 2009 06:58:41 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: In-Reply-To: <400447.39315.qm@web56807.mail.re3.yahoo.com> References: <400447.39315.qm@web56807.mail.re3.yahoo.com> Message-ID: Ok, I take that back. Yes. Nullsoft is probably it. Thank you for the referral. IExpress seems to have a low limit on how many files it can package. I could probably build something hierarchical, but it's getting more painful. I tried out Nullsoft and it was quick easy worked well, results already surpassing iexpress, I used the gui and I expect the command line will be easy/quick/good too. I just did the zip2exe option. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: eiserlohpp at yahoo.com; m3devel at elegosoft.com > Subject: RE: [M3devel] Getting ready for new users (Re: HEADS UP: > Date: Sat, 27 Jun 2009 17:36:07 +0000 > > > Well, it probably is better than IExpress.exe but IExpress is super easy. > I'll probably stick with it and if someone has something else to replace it with they can. > > - Jay > > > ---------------------------------------- >> Date: Sat, 27 Jun 2009 08:04:50 -0700 >> From: eiserlohpp at yahoo.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: >> >> >> Hi Jay, >> >> On Thu, Jun 25, 2009 at 08:43:11PM +0000, Jay wrote: >>> >>> There's no need for Winzip if we use .zip files, explorer handles them. >>> >>> It is also easy to make self extracting .zip files. >> >> >> For installing applications on Windows boxes, why don't >> you use NSIS? >> >> http://nsis.sourceforge.net/Main_Page From wagner at elegosoft.com Sun Jun 28 14:27:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 28 Jun 2009 14:27:39 +0200 Subject: [M3devel] canonicalizepath?? In-Reply-To: References: Message-ID: <20090628142739.ryq4td9tkwkcgkow@mail.elegosoft.com> Quoting Jay : > DoMakeDir 1: /cm3/bin/../pkg/m3cggen/PPC_LINUX > DoMakeDir 2: /cm3/bin/m3cggen/PPC_LINUX > > > C:\dev2\cm3.2\m3-sys\m3quake\src\QMachine.m3 > > PROCEDURE DoMakeDir (t: T; n_args: INTEGER) RAISES {Error} = > VAR val: QValue.T; dir, prefix: TEXT; > BEGIN > > Pop (t, val); dir := QVal.ToText (t, val); > prefix := Env.Get("CM3_INSTALL_PREFIX"); > IF prefix # NIL THEN > dir := prefix & dir; > END; > RTIO.PutText("DoMakeDir 1: " & dir & "\n"); > dir := Pathname.Compose (CanonicalizePath (Pathname.Decompose (dir))); > RTIO.PutText("DoMakeDir 2: " & dir & "\n"); > RTIO.Flush(); > MakeDir (t, dir); > END DoMakeDir; > > huh? Strange :-/ > I don't think I've ever change this.. Nor did I. > Am I expected to reverse the path before passing it through here? A quick look at the function seems to show that it only correctly removes ../.. at the start of a path, if I am not mistaken. > I'll just avoid this function.. Could you (or anybody else) fix it? I'm in a hurry and won't get to it till Tuesday night... I don't think we should leave it that way... 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 Sun Jun 28 18:48:22 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 28 Jun 2009 12:48:22 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090626151238.GB4554@topoi.pooq.com> References: <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090626151238.GB4554@topoi.pooq.com> Message-ID: <20090628164822.GA11116@topoi.pooq.com> On Fri, Jun 26, 2009 at 11:12:38AM -0400, hendrik at topoi.pooq.com wrote: > On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: > > Quoting Jay : > > > > > > > >I tested the LINUXLIBC6 archive and it installed ok, no prompting. > > > > > >I ran it with no parameters -- unlike Henrik. It did mention the > > >current working directory (or its directory, same thing) as the > > >install source, which confused me. Probably as long as system.tgz > > >exists where it expects, it shouldn't say anything. > > > > Strange. > > > > Hendrik, can you reproduce the strange message? And then perhaps > > provide a system call trace (ktrace, truss, whatever)? > > > > Olaf > > I'll try. I'll probably have to rm -r /user/local/cm3 first. Anything > else I need to watch out for? I haven't done that yet. But I have a program that works on the system I managed to set up a month or so ago just by unpacking the cm3-min .tgz archive file and setting $PATH to point to its bin directory. I set the $PATH to the version I just installed (with the strangee message) deleted LINUXLIBC6, and ran the just-(mis?)installed cm3: hendrik at notlookedfor:~/mtxt$ rm LINUXLIBC6/ -r hendrik at notlookedfor:~/mtxt$ cm3 --- building in LINUXLIBC6 --- "/home/hendrik/mtxt/src/m3makefile", line 1: quake runtime error: unable to open "/var/tmp/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 1 /home/hendrik/mtxt/src/m3makefile 4 /home/hendrik/mtxt/LINUXLIBC6/m3make.args Fatal Error: package build failed hendrik at notlookedfor:~/mtxt$ which cm3 /usr/local/cm3/bin/cm3 hendrik at notlookedfor:~/mtxt$ env | grep cm PATH=/home/hendrik/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/hendrik/bin/i686/:/usr/local/cm3/bin hendrik at notlookedfor:~/mtxt$ I don't know if this could help anyone figure out what went wrong with the installation, but it does indicate that it isn't right. There's noting at all in /var/tmp. Not even a directory /vat/tmp/cm3. -- hendrik > > Now that I think of resetting ... I still had the old cm3-min > unpacked somewhere else, and I add its bin directory to the $PATH on > a bash startup. Could that have be affecting the results? > > -- hendrik > From jay.krell at cornell.edu Sun Jun 28 19:13:48 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 28 Jun 2009 17:13:48 +0000 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090628164822.GA11116@topoi.pooq.com> References: <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090626151238.GB4554@topoi.pooq.com> <20090628164822.GA11116@topoi.pooq.com> Message-ID: The packaging process stages things in /var/tmp/cm3. I bet the cm3.cfg file says INSTALL_ROOT="/var/tmp/cm3". It should be fixed, I changed it to say INSTALL_ROOT = (path() & SL & ".."). - Jay ---------------------------------------- > Date: Sun, 28 Jun 2009 12:48:22 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) > > On Fri, Jun 26, 2009 at 11:12:38AM -0400, hendrik at topoi.pooq.com wrote: >> On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: >>> Quoting Jay : >>> >>>> >>>>I tested the LINUXLIBC6 archive and it installed ok, no prompting. >>>> >>>>I ran it with no parameters -- unlike Henrik. It did mention the >>>>current working directory (or its directory, same thing) as the >>>>install source, which confused me. Probably as long as system.tgz >>>>exists where it expects, it shouldn't say anything. >>> >>> Strange. >>> >>> Hendrik, can you reproduce the strange message? And then perhaps >>> provide a system call trace (ktrace, truss, whatever)? >>> >>> Olaf >> >> I'll try. I'll probably have to rm -r /user/local/cm3 first. Anything >> else I need to watch out for? > > I haven't done that yet. But I have a program that works > on the system I managed to set up a month or so ago just by > unpacking the cm3-min .tgz archive file and setting $PATH to > point to its bin directory. > > I set the $PATH to the version I just installed (with the strangee > message) deleted LINUXLIBC6, and ran the just-(mis?)installed cm3: > > hendrik at notlookedfor:~/mtxt$ rm LINUXLIBC6/ -r > hendrik at notlookedfor:~/mtxt$ cm3 > --- building in LINUXLIBC6 --- > > "/home/hendrik/mtxt/src/m3makefile", line 1: quake runtime error: unable > to open "/var/tmp/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS" for reading > > --procedure-- -line- -file--- > import -- > include_dir 1 /home/hendrik/mtxt/src/m3makefile > 4 /home/hendrik/mtxt/LINUXLIBC6/m3make.args > > Fatal Error: package build failed > hendrik at notlookedfor:~/mtxt$ which cm3 > /usr/local/cm3/bin/cm3 > hendrik at notlookedfor:~/mtxt$ env | grep cm > PATH=/home/hendrik/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/hendrik/bin/i686/:/usr/local/cm3/bin > hendrik at notlookedfor:~/mtxt$ > > > I don't know if this could help anyone figure out what went wrong with > the installation, but it does indicate that it isn't right. > > There's noting at all in /var/tmp. Not even a directory /vat/tmp/cm3. > > -- hendrik > > >> >> Now that I think of resetting ... I still had the old cm3-min >> unpacked somewhere else, and I add its bin directory to the $PATH on >> a bash startup. Could that have be affecting the results? >> >> -- hendrik >> From hendrik at topoi.pooq.com Sun Jun 28 20:34:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 28 Jun 2009 14:34:58 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> References: <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> Message-ID: <20090628183458.GA11305@topoi.pooq.com> On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: > Quoting Jay : > > > > >I tested the LINUXLIBC6 archive and it installed ok, no prompting. > > > >I ran it with no parameters -- unlike Henrik. It did mention the > >current working directory (or its directory, same thing) as the > >install source, which confused me. Probably as long as system.tgz > >exists where it expects, it shouldn't say anything. > > Strange. > > Hendrik, can you reproduce the strange message? And then perhaps > provide a system call trace (ktrace, truss, whatever)? No. I have not been able to reproduce it. Tried three times: (1) with the existing preexisting incomplete /usr/local/cm3, and no references to any cm3 stuff in $PATH (2) without any /usr/local/cm3 (I used rm -r to erase it), and no references to any cm3 stuff ini $PATH (3) witout any /usr/local/cm3, and a reference to bin within the unpacked ancient cm3-min archive in my $PATH (which is how is was when I first got the message). (And this is how I've cm3-min to compile and run even though its installation failed as reported here long ago) All these installations were from the same ~hendrik/cm3 directory resulting from the archive I had unpacked a while ago when I got the strange message. I haven't downloaded a new archive since then. Maybe I should retry creating a new unpacked archive every time? Or should I just give up? -- hendrik From eiserlohpp at yahoo.com Mon Jun 29 02:25:28 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 28 Jun 2009 17:25:28 -0700 (PDT) Subject: [M3devel] Manual page for m3makefile and m3overrides files Message-ID: <939775.74319.qm@web56802.mail.re3.yahoo.com> Hi Gang, I am on a rampage this weekend. I converted the docs on the m3makefile and m3overrides files into manual pages. http://black/~peter/modula3/#mydocs Again, I place any work here listed into the public domain. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From eiserlohpp at yahoo.com Mon Jun 29 02:54:51 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sun, 28 Jun 2009 17:54:51 -0700 (PDT) Subject: [M3devel] (no subject) Message-ID: <160850.29538.qm@web56806.mail.re3.yahoo.com> Oops, please change the host name. - http://black/~peter/modula3/#mydocs + http://www.eiserloh.org/~peter/modula3/#mydocs +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Mon Jun 29 05:08:44 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 03:08:44 +0000 Subject: [M3devel] .msi files for Windows available Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives now contains .msi files for Windows: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi These are some of the first .msi files I have ever made. I used WiX. scripts/python/make-dist.py makes them. Some of the highlights/lowlights: They always install all of what they have. There is not (yet) support for the package sets. They always modify %PATH%. It should be an option. They append to %PATH%. My intent was to prepend. (It appears obvious how, but it didn't work.) They have an uninstaller, listed in add/remove programs. Not listed in the start menu. That seems to be go either way in practise. The uninstaller does remove c:\cm3\bin from %path%, besides deleting all the files -- that didn't take any extra work. They don't put anything in the start menu. What would it be? Oh, I need to try cm3ide, which probably isn't here. The config file still just runs cl.exe/link.exe from %path%. I think the way to address this is in the config file, not setup. The default install location is c:\cm3 but user can change it. The presentation of the licenses is quite ugly. And perhaps unnecessary? Not seemingly not easy to remove, without copy/pasting some code/data with yet another license. There are accidentally two .pdbs (symbols) in the .msis. (More geerally the symbols are: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1-symbols.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1-symbols.zip and the same content without installation is at http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip ) http://modula3.elegosoft.com/cm3/uploaded-archives is a bit messy due to the volume of files, it should probably be split up. Someone please try them out and report back. I did test them. They install/uninstall, modify $path, and cm3 runs. - Jay From jay.krell at cornell.edu Mon Jun 29 05:16:37 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 03:16:37 +0000 Subject: [M3devel] .deb files Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives contains some .deb files now, but so far only for SPARC32_LINUX. I assume nobody uses that? x86/AMD64 should be available later, not soon. Highlights/lowlights: There is just min and std, no package sets yet. They install to /usr/local/cm3. You have no choice. Official .deb files are not supposed to use /usr/local, but I don't count these as official. They don't modify $PATH for you. (They don't run cminstall either.) They overlap, install just one. Maybe missing cm3ide and m3gdb, will be fixed. They are made "as a matter of course" by scripts/python/make-dist.py, for any Linux platform. There is no apt-get install foo, I have to look up how to do that, there is download (wget) the file and dpkg -i ./foo.deb. And like apt-get remove cm3-min or apt-get remove cm3-std. .deb files are actually a trivial format. They are an ar file with three files: debian-binary little marker control.tar.gz .deb specific stuff, contains text files data.tar.gz or .bz2 or .lzma the payload in the usual form That is, we could arguably not produce the loose .tgz files. - Jay From jay.krell at cornell.edu Mon Jun 29 05:18:15 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 03:18:15 +0000 Subject: [M3devel] FW: .msi files for Windows available Message-ID: Was truncated. ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: .msi files for Windows available > Date: Mon, 29 Jun 2009 03:08:44 +0000 > > > > http://modula3.elegosoft.com/cm3/uploaded-archives > > now contains .msi files for Windows: > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi > > > These are some of the first .msi files I have ever made. > I used WiX. scripts/python/make-dist.py makes them. > > > Some of the highlights/lowlights: > They always install all of what they have. There is not (yet) > support for the package sets. > They always modify %PATH%. It should be an option. > They append to %PATH%. My intent was to prepend. (It appears obvious > how, but it didn't work.) > They have an uninstaller, listed in add/remove programs. > Not listed in the start menu. That seems to be go either way in practise. > The uninstaller does remove c:\cm3\bin from %path%, besides deleting > all the files -- that didn't take any extra work. > They don't put anything in the start menu. > What would it be? Oh, I need to try cm3ide, which probably isn't here. > The config file still just runs cl.exe/link.exe from %path%. > I think the way to address this is in the config file, not setup. > The default install location is c:\cm3 but user can change it. > The presentation of the licenses is quite ugly. And perhaps unnecessary? > Not seemingly not easy to remove, without copy/pasting some code/data with yet another license. > There are accidentally two .pdbs (symbols) in the .msis. > (More geerally the symbols are: > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1-symbols.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1-symbols.zip > and the same content without installation is at > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip > ) > > > http://modula3.elegosoft.com/cm3/uploaded-archives > is a bit messy due to the volume of files, > it should probably be split up. > > > Someone please try them out and report back. > I did test them. They install/uninstall, modify $path, and cm3 runs. > > > - Jay From jay.krell at cornell.edu Mon Jun 29 05:38:28 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 03:38:28 +0000 Subject: [M3devel] pruning m3cc/gcc? Message-ID: I keep thinking of deleting m3-sys/m3cc/gcc/intl m3-sys/m3cc/gcc/libgomp m3-sys/m3cc/gcc/libmudflap m3-sys/m3cc/gcc/libssp m3-sys/m3cc/gcc/fixincludes m3-sys/m3cc/gcc/libgcc We don't use any of it. Some of these deletions would shorten our build command lines. Though some (esp. fixincludes and maybe libgcc) might break the shortest configure + make that the "real" cm3 doesn't use but can be useful. I didn't include them in gcc-interix and gcc-apple. But there are two possible contradictory goals: - just have what we use/change - have a complete merged gcc tree from which you could build gcc/cc1 and not just cm3cg Except we don't have C++, Java, Ada, Fortran, so we don't really have this, but C probably counts for something. If the second is the goal, don't delete. If the first is the goal, delete. There is also "having it all there in case it is needed or somesuch", but that's easy enough to get elsewhere. - Jay From jay.krell at cornell.edu Mon Jun 29 06:29:12 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 28 Jun 2009 21:29:12 -0700 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: References: Message-ID: Truncated again I think, can't fix right now. - Jay (phone) On Jun 28, 2009, at 8:18 PM, Jay wrote: > > Was truncated. > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: .msi files for Windows available >> Date: Mon, 29 Jun 2009 03:08:44 +0000 >> >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives >> >> now contains .msi files for Windows: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >> >> >> These are some of the first .msi files I have ever made. >> I used WiX. scripts/python/make-dist.py makes them. >> >> >> Some of the highlights/lowlights: >> They always install all of what they have. There is not (yet) >> support for the package sets. >> They always modify %PATH%. It should be an option. >> They append to %PATH%. My intent was to prepend. (It appears obvious >> how, but it didn't work.) >> They have an uninstaller, listed in add/remove programs. >> Not listed in the start menu. That seems to be go either way in >> practise. >> The uninstaller does remove c:\cm3\bin from %path%, besides deleting >> all the files -- that didn't take any extra work. >> They don't put anything in the start menu. >> What would it be? Oh, I need to try cm3ide, which probably isn't here From jay.krell at cornell.edu Mon Jun 29 06:30:57 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 28 Jun 2009 21:30:57 -0700 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: References: Message-ID: <4C1F69E7-385E-4713-9431-06B561964450@hotmail.com> This also truncated.. - Jay (phone) On Jun 28, 2009, at 8:38 PM, Jay wrote: > > I keep thinking of deleting > > m3-sys/m3cc/gcc/intl > m3-sys/m3cc/gcc/libgomp > m3-sys/m3cc/gcc/libmudflap > m3-sys/m3cc/gcc/libssp > m3-sys/m3cc/gcc/fixincludes > m3-sys/m3cc/gcc/libgcc > > > We don't use any of it. > Some of these deletions would shorten our build command lines. > Though some (esp. fixincludes and maybe libgcc) might break the > shortest configure + make that the "real" cm3 doesn't use but can be > useful From hosking at cs.purdue.edu Mon Jun 29 15:41:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 29 Jun 2009 09:41:09 -0400 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: References: Message-ID: <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu> I personally like having the ability to build C from the same source tree. It's useful for debugging the backend sometimes (looking at the equivalent code generated from C). On 28 Jun 2009, at 23:38, Jay wrote: > > I keep thinking of deleting > > m3-sys/m3cc/gcc/intl > m3-sys/m3cc/gcc/libgomp > m3-sys/m3cc/gcc/libmudflap > m3-sys/m3cc/gcc/libssp > m3-sys/m3cc/gcc/fixincludes > m3-sys/m3cc/gcc/libgcc > > > We don't use any of it. > Some of these deletions would shorten our build command lines. > Though some (esp. fixincludes and maybe libgcc) might break the > shortest configure + make that the "real" cm3 doesn't use but can be > useful. > > > I didn't include them in gcc-interix and gcc-apple. > > > But there are two possible contradictory goals: > > > - just have what we use/change > - have a complete merged gcc tree from which you > could build gcc/cc1 and not just cm3cg > Except we don't have C++, Java, Ada, Fortran, > so we don't really have this, but C probably counts for something. > > > If the second is the goal, don't delete. > If the first is the goal, delete. > > > There is also "having it all there in case it is needed > or somesuch", but that's easy enough to get elsewhere. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 29 16:42:54 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 14:42:54 +0000 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu> References: <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu> Message-ID: Ok, presumably then ok to prune it just partly, like intl, libssp, libmudflap, libgomp, treelang, beyond that (fixincludes, libgcc) would require some checking/testing. Might even be worthwhile to "simplify" the m3makefile and reach a compromise that works only by some deletion. Really I wish somehow gmp/mpfr built more quickly. I often delete their source locally but can't commit that. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 29 Jun 2009 09:41:09 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pruning m3cc/gcc? > > I personally like having the ability to build C from the same source tree. It's useful for debugging the backend sometimes (looking at the equivalent code generated from C). > > On 28 Jun 2009, at 23:38, Jay wrote: > > > I keep thinking of deleting > > m3-sys/m3cc/gcc/intl > m3-sys/m3cc/gcc/libgomp > m3-sys/m3cc/gcc/libmudflap > m3-sys/m3cc/gcc/libssp > m3-sys/m3cc/gcc/fixincludes > m3-sys/m3cc/gcc/libgcc > > > We don't use any of it. > Some of these deletions would shorten our build command lines. > Though some (esp. fixincludes and maybe libgcc) might break the > shortest configure + make that the "real" cm3 doesn't use but can be useful. > > > I didn't include them in gcc-interix and gcc-apple. > > > But there are two possible contradictory goals: > > > - just have what we use/change > - have a complete merged gcc tree from which you > could build gcc/cc1 and not just cm3cg > Except we don't have C++, Java, Ada, Fortran, > so we don't really have this, but C probably counts for something. > > > If the second is the goal, don't delete. > If the first is the goal, delete. > > > There is also "having it all there in case it is needed > or somesuch", but that's easy enough to get elsewhere. > > > - Jay > From jay.krell at cornell.edu Mon Jun 29 17:32:29 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 15:32:29 +0000 Subject: [M3devel] some testing of the new web pages Message-ID: I do like the new web pages. Here are some problems though. http://www.opencm3.net/releng/collection-core.html go down to m3-sys/cm3 the builder and freebsd manual page links aren't right. I think these are maybe just CVS merge conflicts that happen to be on the packaging machine and can just be deleted. Not clear if most of the gcc links are useful. go down to TCL interfaces for M3 The browse sources link doesn't work. Probably related to this not always building and not built. Probably need to modify this and require people doing package building to have Tcl installed, maybe even for NT386. Probably specifically make-dist.sh should set $ENABLE_TCL or somesuch. (not exactly) The source links present, e.g. the licenses oddly, but compactly and probably a good thing, e.g.: http://www.opencm3.net/doc/help/gen_html/tcp/src/common/StreamRdClass.m3.html Probably an artifact of m3tohtml. http://www.opencm3.net/releng Go down the righthand side trying everything to one level. Broken: http://www.opencm3.net/releng/collection-min.html http://www.opencm3.net/releng/collection-caltech.html But there is: http://www.opencm3.net/releng/collection-caltech-parser.html It contains m3-win/import-libs but shouldn't. I suspect the problems are rooted in: min is a non-ws package set but not a ws package set. Because it is overlys small and core subsumes it? caltech-parser contains a dash. min to me is specifically enough to start with an old release and build a current compiler and release -- m3core, libm3, m3cg, cm3, maybe sysutils specifically it is the pieces required to compile anything (cm3, m3cg) and the pieces that an old compiler may not be able to build the the current versions of (m3core/libm3) that a current compiler will need; That is, if you want to build natively build the whole system from source, this is the smallest you can start with. m3cg actually isn't in min but probably handled specially. Related couments usually but not always has one extra empty bullet, including but not limited to when the list is empty: http://www.opencm3.net/releng/collection-cvsup.html http://www.opencm3.net/releng/collection-anim.html http://www.opencm3.net/releng/collection-cvsup.html http://www.opencm3.net/releng/collection-database.html http://www.opencm3.net/releng/collection-demo.html http://www.opencm3.net/releng/collection-devlib.html http://www.opencm3.net/releng/collection-game.html http://www.opencm3.net/releng/collection-gui.html This is not all the ones with an extra bullet, and a few don't have the extra bullet. I'm on the fence on the whole ws thing. Non-ws also has matching source. The point is to provide the packages both built and buildable? If cm3 had a mode that started with assemble then link and ship, we could cross build all the ws packages, very nice. I guess the "real" problem is I feel compelled then to match this feature in make-dist.py. http://www.opencm3.net/releng/collection-tool.html Try the first few links. mtex Browse sources seems incomplete but maybe is right. The man page links are all broken. cmpdir shows a general pattern: maybe directories with no files shouldn't be shown? http://www.opencm3.net/releng/collection-demo.html fisheye The link manual page .makefile isn't right http://www.opencm3.net/releng/collection-devlib.html m3tk Several broken manpage links. pex browse sources doesn't work Probably like Tcl, not always built. http://www.opencm3.net/releng/collection-anim.html zeus contains a broken Zeus manual page, I think a CVS conflict file Might be able to search for this generally in the html. http://www.opencm3.net/releng/collection-obliq.html related documents first link, to polymtl, broken, sounds promising, maybe we can find it and host it http://www.opencm3.net/releng/collection-m3gdb.html m3gdb Like m3cc, maybe some of these READMEs not useful. - Jay From hosking at cs.purdue.edu Mon Jun 29 18:01:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 29 Jun 2009 12:01:16 -0400 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: References: <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu> Message-ID: <7D2B9349-BCBA-46DE-8465-F50EEBB70F22@cs.purdue.edu> Please leave treelang. It is a good model for building gcc IR trees as done by cm3cg. On 29 Jun 2009, at 10:42, Jay wrote: > > Ok, presumably then ok to prune it just partly, like intl, libssp, > libmudflap, libgomp, treelang, beyond that (fixincludes, libgcc) > would require some checking/testing. Might even be worthwhile to > "simplify" the m3makefile and reach a compromise that works only by > some deletion. > Really I wish somehow gmp/mpfr built more quickly. I often delete > their source locally but can't commit that. > > - Jay > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Mon, 29 Jun 2009 09:41:09 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] pruning m3cc/gcc? >> >> I personally like having the ability to build C from the same >> source tree. It's useful for debugging the backend sometimes >> (looking at the equivalent code generated from C). >> >> On 28 Jun 2009, at 23:38, Jay wrote: >> >> >> I keep thinking of deleting >> >> m3-sys/m3cc/gcc/intl >> m3-sys/m3cc/gcc/libgomp >> m3-sys/m3cc/gcc/libmudflap >> m3-sys/m3cc/gcc/libssp >> m3-sys/m3cc/gcc/fixincludes >> m3-sys/m3cc/gcc/libgcc >> >> >> We don't use any of it. >> Some of these deletions would shorten our build command lines. >> Though some (esp. fixincludes and maybe libgcc) might break the >> shortest configure + make that the "real" cm3 doesn't use but can >> be useful. >> >> >> I didn't include them in gcc-interix and gcc-apple. >> >> >> But there are two possible contradictory goals: >> >> >> - just have what we use/change >> - have a complete merged gcc tree from which you >> could build gcc/cc1 and not just cm3cg >> Except we don't have C++, Java, Ada, Fortran, >> so we don't really have this, but C probably counts for something. >> >> >> If the second is the goal, don't delete. >> If the first is the goal, delete. >> >> >> There is also "having it all there in case it is needed >> or somesuch", but that's easy enough to get elsewhere. >> >> >> - Jay >> From lists at darko.org Mon Jun 29 17:43:09 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 29 Jun 2009 17:43:09 +0200 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: References: Message-ID: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Are we going to have Installer packages for Darwin PPC/Intel too or is there some reason not too? On 29/06/2009, at 5:18 AM, Jay wrote: > > Was truncated. > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: .msi files for Windows available >> Date: Mon, 29 Jun 2009 03:08:44 +0000 >> >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives >> >> now contains .msi files for Windows: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >> >> >> These are some of the first .msi files I have ever made. >> I used WiX. scripts/python/make-dist.py makes them. >> >> >> Some of the highlights/lowlights: >> They always install all of what they have. There is not (yet) >> support for the package sets. >> They always modify %PATH%. It should be an option. >> They append to %PATH%. My intent was to prepend. (It appears obvious >> how, but it didn't work.) >> They have an uninstaller, listed in add/remove programs. >> Not listed in the start menu. That seems to be go either way in >> practise. >> The uninstaller does remove c:\cm3\bin from %path%, besides deleting >> all the files -- that didn't take any extra work. >> They don't put anything in the start menu. >> What would it be? Oh, I need to try cm3ide, which probably isn't here From jay.krell at cornell.edu Mon Jun 29 19:15:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:15:52 +0000 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> References: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Message-ID: Eventually, but not by me probably for at least a week or a month or more. RPM too. It should probably come before Mac. Except that I don't have any Suse/RedHat/YellowDog/Mandrake/Mandriva systems now, having settled pretty exclusively on Debian (plus the Fit PC that came with Gentoo preinstalled), so I don't know. *BSD also should get some attention. But I don't see me getting to that for a while. It would be nice to compete with the ezm3 port that is out there. It builds from assembly source, which is good, to see there is a precedent we can follow. There are a lot of other formats but I probably won't get to any of them. HP-UX, Solaris, AIX, Irix all have something, and no users. I don't know yet about Tru64 and VMS. Btw, the DESTDIR-like feature that (you?) added to cm3 isn't really needed. You can just $CM3_INSTALL and it does basically the same thing. Look at Olaf's make-dist.sh. It gets a lot done with little code using simple techniques. But I'm still sticking to Python. :) I don't think the DESTDIR-like feature handled runpaths or config files as well, which are mostly moot now. (Really..runpath solved by $ORIGIN, but $ORIGIN doesn't solve the problem. $ORIGIN lets you move a set of files together, good, but it doesn't help the situation where you want to move just some of them.) - Jay ---------------------------------------- > From: lists at darko.org > To: jay.krell at cornell.edu > Date: Mon, 29 Jun 2009 17:43:09 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: .msi files for Windows available > > Are we going to have Installer packages for Darwin PPC/Intel too or is > there some reason not too? > > > On 29/06/2009, at 5:18 AM, Jay wrote: > >> >> Was truncated. >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Subject: .msi files for Windows available >>> Date: Mon, 29 Jun 2009 03:08:44 +0000 >>> >>> >>> >>> http://modula3.elegosoft.com/cm3/uploaded-archives >>> >>> now contains .msi files for Windows: >>> >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>> >>> >>> These are some of the first .msi files I have ever made. >>> I used WiX. scripts/python/make-dist.py makes them. >>> >>> >>> Some of the highlights/lowlights: >>> They always install all of what they have. There is not (yet) >>> support for the package sets. >>> They always modify %PATH%. It should be an option. >>> They append to %PATH%. My intent was to prepend. (It appears obvious >>> how, but it didn't work.) >>> They have an uninstaller, listed in add/remove programs. >>> Not listed in the start menu. That seems to be go either way in >>> practise. >>> The uninstaller does remove c:\cm3\bin from %path%, besides deleting >>> all the files -- that didn't take any extra work. >>> They don't put anything in the start menu. >>> What would it be? Oh, I need to try cm3ide, which probably isn't here > From jay.krell at cornell.edu Mon Jun 29 19:23:39 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:23:39 +0000 Subject: [M3devel] pruning m3cc/gcc? Message-ID: [trying to untruncate again, though I think Tony quoted the whole thing] ---------------------------------------- > From: jay > To: m3devel; hosking > Subject: pruning m3cc/gcc? > Date: Mon, 29 Jun 2009 03:38:28 +0000 > > > I keep thinking of deleting > [snip, parts of gcc] > > We don't use any of it. > Some of these deletions would shorten our build command lines. > Though some (esp. fixincludes and maybe libgcc) might break the > shortest configure + make that the "real" cm3 doesn't use but can be useful. > > > I didn't include them in gcc-interix and gcc-apple. > > > But there are two possible contradictory goals: > > > - just have what we use/change > - have a complete merged gcc tree from which you > could build gcc/cc1 and not just cm3cg > Except we don't have C++, Java, Ada, Fortran, > so we don't really have this, but C probably counts for something. > > > If the second is the goal, don't delete. > If the first is the goal, delete. > > > There is also "having it all there in case it is needed > or somesuch", but that's easy enough to get elsewhere. > > > - Jay From jay.krell at cornell.edu Mon Jun 29 19:21:07 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:21:07 +0000 Subject: [M3devel] .msi files for Windows available Message-ID: [trying to untruncate again, I forget if it is forward or replayall that untruncates] ---------------------------------------- > From: jay > > > Was truncated. > > > ---------------------------------------- >> From: jay >> To: m3devel >> Subject: .msi files for Windows available >> Date: Mon, 29 Jun 2009 03:08:44 +0000 >> >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives >> >> now contains .msi files for Windows: >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >> >> >> These are some of the first .msi files I have ever made. >> I used WiX. scripts/python/make-dist.py makes them. >> >> >> Some of the highlights/lowlights: >> They always install all of what they have. There is not (yet) >> support for the package sets. >> They always modify %PATH%. It should be an option. >> They append to %PATH%. My intent was to prepend. (It appears obvious >> how, but it didn't work.) >> They have an uninstaller, listed in add/remove programs. >> Not listed in the start menu. That seems to be go either way in practise. >> The uninstaller does remove c:\cm3\bin from %path%, besides deleting >> all the files -- that didn't take any extra work. >> They don't put anything in the start menu. [approximate point of truncation] >> What would it be? Oh, I need to try cm3ide, which probably isn't here. >> The config file still just runs cl.exe/link.exe from %path%. >> I think the way to address this is in the config file, not setup. >> The default install location is c:\cm3 but user can change it. >> The presentation of the licenses is quite ugly. And perhaps unnecessary? >> Not seemingly not easy to remove, without copy/pasting some code/data with yet another license. >> There are accidentally two .pdbs (symbols) in the .msis. >> (More geerally the symbols are: >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1-symbols.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1-symbols.zip >> and the same content without installation is at >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip >> ) >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives >> is a bit messy due to the volume of files, >> it should probably be split up. >> >> >> Someone please try them out and report back. >> I did test them. They install/uninstall, modify $path, and cm3 runs. >> >> >> - Jay From jay.krell at cornell.edu Mon Jun 29 19:40:02 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:40:02 +0000 Subject: [M3devel] .msi files for Windows available In-Reply-To: References: Message-ID: Was truncated again.. ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 29 Jun 2009 17:21:07 +0000 > Subject: Re: [M3devel] .msi files for Windows available > > > [trying to untruncate again, I forget if it is forward or replayall that untruncates] > > > ---------------------------------------- >> From: jay >> >> >> Was truncated. >> >> >> ---------------------------------------- [deliberately truncated this time] From jay.krell at cornell.edu Mon Jun 29 19:41:32 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:41:32 +0000 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> References: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Message-ID: [was severely truncated darnit] ---------------------------------------- > From: jay.krell at cornell.edu > To: lists at darko.org > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: .msi files for Windows available > Date: Mon, 29 Jun 2009 17:15:52 +0000 > > > Eventually, but not by me probably for at least a week or a month or more. > > > RPM too. It should probably come before Mac. > Except that I don't have any Suse/RedHat/YellowDog/Mandrake/Mandriva systems now, having settled pretty exclusively on Debian (plus the Fit PC that came with Gentoo preinstalled), so I don't know. > > > *BSD also should get some attention. > But I don't see me getting to that for a while. > It would be nice to compete with the ezm3 port that is out there. > It builds from assembly source, which is good, to see there is a precedent we can follow. > > > There are a lot of other formats but I probably won't get to any of them. > HP-UX, Solaris, AIX, Irix all have something, and no users. > I don't know yet about Tru64 and VMS. > > > Btw, the DESTDIR-like feature that (you?) added to cm3 isn't really needed. > You can just $CM3_INSTALL and it does basically the same thing. > Look at Olaf's make-dist.sh. > It gets a lot done with little code using simple techniques. > But I'm still sticking to Python. :) > > > I don't think the DESTDIR-like feature handled runpaths or config files as well, which are mostly moot now. > > > (Really..runpath solved by $ORIGIN, but $ORIGIN doesn't solve the problem. $ORIGIN lets you move a set of files together, good, but it doesn't help the situation where you want to move just some of them.) > > > - Jay > > > ---------------------------------------- >> From: lists at darko.org >> To: jay.krell at cornell.edu >> Date: Mon, 29 Jun 2009 17:43:09 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] FW: .msi files for Windows available >> >> Are we going to have Installer packages for Darwin PPC/Intel too or is >> there some reason not too? >> >> [deliberately truncated] From jay.krell at cornell.edu Mon Jun 29 19:52:04 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 29 Jun 2009 17:52:04 +0000 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: References: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Message-ID: > [was severely truncated darnit trying again and with additional tactics..] I put it here assuming it is truncated again: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-NT386-msi.txt http://modula3.elegosoft.com/cm3/uploaded-archives is a bit messy due to the volume of files, it should probably be split up? Someone please try them out and report back. I did test them. They install/uninstall, modify $path, and cm3 runs. Some of the highlights/lowlights: They always install all of what they have. There is not (yet) support for the package sets. They always modify %PATH%. It should be an option. They append to %PATH%. My intent was to prepend. (It appears obvious how, but it didn't work.) They have an uninstaller, listed in add/remove programs. Not listed in the start menu. That seems to be go either way in practise. The uninstaller does remove c:\cm3\bin from %path%, besides deleting all the files -- that didn't take any extra work. They don't put anything in the start menu. [approximate truncation point ...] What would it be? Oh, I need to try cm3ide, which probably isn't here. The config file still just runs cl.exe/link.exe from %path%. I think the way to address this is in the config file, not setup. The default install location is c:\cm3 but user can change it. The presentation of the licenses is quite ugly. And perhaps unnecessary? Not seemingly not easy to remove, without copy/pasting some code/data with yet another license. There are accidentally two .pdbs (symbols) in the .msis. (More geerally the symbols are: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1-symbols.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1-symbols.zip and the same content without installation is at http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.zip ) - Jay From lists at darko.org Mon Jun 29 22:45:08 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 29 Jun 2009 22:45:08 +0200 Subject: [M3devel] FW: .msi files for Windows available In-Reply-To: References: <015728D0-63CB-4B14-9920-5709BC73475F@darko.org> Message-ID: <7B6DD6CB-BFB0-405C-A4B4-00EA1340A82E@darko.org> DESTDIR wasn't me. On 29/06/2009, at 7:15 PM, Jay wrote: > > Eventually, but not by me probably for at least a week or a month or > more. > > > RPM too. It should probably come before Mac. > Except that I don't have any Suse/RedHat/YellowDog/Mandrake/ > Mandriva systems now, having settled pretty exclusively on Debian > (plus the Fit PC that came with Gentoo preinstalled), so I don't know. > > > *BSD also should get some attention. > But I don't see me getting to that for a while. > It would be nice to compete with the ezm3 port that is out there. > It builds from assembly source, which is good, to see there is a > precedent we can follow. > > > There are a lot of other formats but I probably won't get to any of > them. > HP-UX, Solaris, AIX, Irix all have something, and no users. > I don't know yet about Tru64 and VMS. > > > Btw, the DESTDIR-like feature that (you?) added to cm3 isn't really > needed. > You can just $CM3_INSTALL and it does basically the same thing. > Look at Olaf's make-dist.sh. > It gets a lot done with little code using simple techniques. > But I'm still sticking to Python. :) > > > I don't think the DESTDIR-like feature handled runpaths or config > files as well, which are mostly moot now. > > > (Really..runpath solved by $ORIGIN, but $ORIGIN doesn't solve the > problem. $ORIGIN lets you move a set of files together, good, but it > doesn't help the situation where you want to move just some of them.) > > > - Jay > > > ---------------------------------------- >> From: lists at darko.org >> To: jay.krell at cornell.edu >> Date: Mon, 29 Jun 2009 17:43:09 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] FW: .msi files for Windows available >> >> Are we going to have Installer packages for Darwin PPC/Intel too or >> is >> there some reason not too? >> >> >> On 29/06/2009, at 5:18 AM, Jay wrote: >> >>> >>> Was truncated. >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Subject: .msi files for Windows available >>>> Date: Mon, 29 Jun 2009 03:08:44 +0000 >>>> >>>> >>>> >>>> http://modula3.elegosoft.com/cm3/uploaded-archives >>>> >>>> now contains .msi files for Windows: >>>> >>>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-NT386-d5.8.1.msi >>>> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>>> >>>> >>>> These are some of the first .msi files I have ever made. >>>> I used WiX. scripts/python/make-dist.py makes them. >>>> >>>> >>>> Some of the highlights/lowlights: >>>> They always install all of what they have. There is not (yet) >>>> support for the package sets. >>>> They always modify %PATH%. It should be an option. >>>> They append to %PATH%. My intent was to prepend. (It appears >>>> obvious >>>> how, but it didn't work.) >>>> They have an uninstaller, listed in add/remove programs. >>>> Not listed in the start menu. That seems to be go either way in >>>> practise. >>>> The uninstaller does remove c:\cm3\bin from %path%, besides >>>> deleting >>>> all the files -- that didn't take any extra work. >>>> They don't put anything in the start menu. >>>> What would it be? Oh, I need to try cm3ide, which probably isn't >>>> here >> From wagner at elegosoft.com Tue Jun 30 09:28:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 30 Jun 2009 09:28:26 +0200 Subject: [M3devel] release build broken Message-ID: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> The last commit to pkginfo.txt broke the Tinderbox release build: End of Log File "../src/Main.m3", line 4: unable to find interface (WinNT) "../src/Main.m3", line 5: unable to find interface (WinDef) compilation failed => not building program "mklib" Fatal Error: package build failed *** execution of cm3 -build -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? -DCM3_LAST_CHANGED=?2009-05-16? $RARGS && cm3 -ship $RARGS -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? -DCM3_LAST_CHANGED=?2009-05-16? failed *** Please fix. 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 Jun 30 11:07:50 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 30 Jun 2009 09:07:50 +0000 Subject: [M3devel] release build broken In-Reply-To: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> References: <20090630092826.fv5lwat6cgcoscog@mail.elegosoft.com> Message-ID: Ah, only the release build but not the latest, makes sense. These weren't in m3core in older version. Will fix. After this release I can put it back. - Jay ---------------------------------------- > Date: Tue, 30 Jun 2009 09:28:26 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release build broken > > The last commit to pkginfo.txt broke the Tinderbox release build: > > End of Log File > "../src/Main.m3", line 4: unable to find interface (WinNT) > "../src/Main.m3", line 5: unable to find interface (WinDef) > compilation failed => not building program "mklib" > Fatal Error: package build failed > *** execution of cm3 -build > -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? > -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? > -DCM3_LAST_CHANGED=?2009-05-16? $RARGS && cm3 -ship $RARGS > -DROOT=?/Users/hosking/work/cm3-ws/tv-2009-06-30-05-15-08/cm3? > -DCM3_VERSION_TEXT=?d5.8.1? -DCM3_VERSION_NUMBER=?050801? > -DCM3_LAST_CHANGED=?2009-05-16? failed *** > > > Please fix. > > 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 wagner at elegosoft.com Tue Jun 30 18:27:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 30 Jun 2009 18:27:28 +0200 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090628183458.GA11305@topoi.pooq.com> References: <20090414171133.GB3460@topoi.pooq.com> <20090514020713.GA13442@topoi.pooq.com> <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090628183458.GA11305@topoi.pooq.com> Message-ID: <20090630182728.3604voxlcsococs0@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Fri, Jun 26, 2009 at 12:05:51PM +0200, Olaf Wagner wrote: >> Quoting Jay : >> >> > >> >I tested the LINUXLIBC6 archive and it installed ok, no prompting. >> > >> >I ran it with no parameters -- unlike Henrik. It did mention the >> >current working directory (or its directory, same thing) as the >> >install source, which confused me. Probably as long as system.tgz >> >exists where it expects, it shouldn't say anything. >> >> Strange. >> >> Hendrik, can you reproduce the strange message? And then perhaps >> provide a system call trace (ktrace, truss, whatever)? > > No. I have not been able to reproduce it. Tried three times: > (1) with the existing preexisting incomplete /usr/local/cm3, and no > references to any cm3 stuff in $PATH > (2) without any /usr/local/cm3 (I used rm -r to erase it), and no > references to any cm3 stuff ini $PATH > (3) witout any /usr/local/cm3, and a reference to bin within the > unpacked ancient cm3-min archive in my $PATH (which is how is was when I > first got the message). (And this is how I've cm3-min to compile and > run even though its installation failed as reported here long ago) > > All these installations were from the same ~hendrik/cm3 directory > resulting from the archive I had unpacked a while ago when I got the > strange message. I haven't downloaded a new archive since then. Maybe > I should retry creating a new unpacked archive every time? Or should I > just give up? If it now just works and the problem cannot be reproduced, we should leave it that way. I wouldn't invest much time on chasing down such a spurious error now. 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 Tue Jun 30 19:52:28 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 30 Jun 2009 13:52:28 -0400 Subject: [M3devel] Getting ready for new users (Re: HEADS UP: Release engineering) In-Reply-To: <20090630182728.3604voxlcsococs0@mail.elegosoft.com> References: <20090514084456.a4wd2xrd7ossoksg@mail.elegosoft.com> <20090514155129.GA15181@topoi.pooq.com> <20090609212543.GA23398@topoi.pooq.com> <20090618134334.njcom4fusg0ccsws@mail.elegosoft.com> <20090625134233.GA1722@topoi.pooq.com> <20090625185206.f4lc9vlpckggko4g@mail.elegosoft.com> <20090626120551.n9qv5f114wgs0cos@mail.elegosoft.com> <20090628183458.GA11305@topoi.pooq.com> <20090630182728.3604voxlcsococs0@mail.elegosoft.com> Message-ID: <20090630175228.GA16767@topoi.pooq.com> On Tue, Jun 30, 2009 at 06:27:28PM +0200, Olaf Wagner wrote: > > If it now just works and the problem cannot be reproduced, we should > leave it that way. I wouldn't invest much time on chasing down such > a spurious error now. OK. I'll take a look at installation instructions for some of the other packages, such as the one with Trestle. -- hendrik