From jayk123 at hotmail.com Sun Jun 1 03:40:42 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 1 Jun 2008 01:40:42 +0000 Subject: [M3devel] function pointers and comparison to nil? mis-typed function pointers? In-Reply-To: <20080531132924.GA30413@topoi.pooq.com> References: <483862F4.1E75.00D7.1@scires.com> <483A3377.7070801@wichita.edu> <48408AEE.8090405@wichita.edu> <20080531132924.GA30413@topoi.pooq.com> Message-ID: > In Modula-3, you can pass any procedure but only assign a top-level procedure. > This precludes dangling environments in yet another way, that is more liberal > than either Pascal or Modula-2,, but requires a runtime check on procedure I don't understand "can only assign a top-level procedure". My understanding is that Modula-3 does allow the "unsafe" option -- take the address of a nested function, pass it off to some code, that stores it in a global, and call it later. But of course, "Modula-3 does allow the unsafe option" does not compute. I need to read up and experiment. Maybe there is a runtime check whenever I assign a function pointer to either a global or to a field in non-local record, that it isn't a closure? That makes a fair amount of sense though hard to not make the check overly strict I think. Rodney my "problem" with your analysis is it mostly "pretends" that each language is its own independent environment. In present reality at least, Modula-3 and C interoperate a lot. That is largely a good thing. It does place restrictions on Modula-3 implementations however. Pointers to top-level Modula-3 functions can be passed to C and treated as pointers to C functions. Pointers to C functions, including gcc nested functions, can be passed to Modula-3 code as pointers. There are not separate types for pointers to C vs. Modula-3 functions. Pointers to nested Modula-3 functions cannot be passed to C code and treated as C function pointers, though enabling this, with the programmer required to notice the situation and change the code slightly, is easy enough. The compiler might also be able to recognize it and possibly error, at least if "extern" is presumed to be C, though of course..insert one level of Modula-3 code between "taking the address" and "passing it to C", and it becomes more difficult..but maybe still quite easy. If the whole world was Modula-3, then you could just change the representation of all function pointers and how they are called. The strategy of optionally heap allocated frames -- when the address is taken of a nested function -- does kill multiple birds with one expensive stone. - ability to pass function pointers to nested functions to C code, and store them anywhere - ability to call nested functions after their caller has returned - remove the check for the -1 marker which might possibly maybe just barely be unportable, and also slows down/bloats calls to function pointers (but at the cost of probably a more sever slow down) - avoid the use of generated code on the stack - still need to ensure the heap is executable but that's less of a problem, Windows for example at least exposes the ability to make the heap executable, besides the strategy of using VirtualAlloc. However it slows down existing code. Depending on which of these features is desirable, if in fact any at all, there are other options. - leave it all alone (but continue talking about it :) ) - put the code on the stack and call mprotect/VirtualProtect, as OpenBSD does for gcc nested functions - Jay > Date: Sat, 31 May 2008 09:29:24 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > On Fri, May 30, 2008 at 06:17:02PM -0500, Rodney M. Bates wrote:> > > > My one handy Algol68 book has the usual tutorial language book problem: it> > omits the cases you really need to look up. It only states that there will> > be problems if you use a dangling environment, but not whether the language> > specifies this should be detected by the language, or whether "all hell will> > break loose." I'm guessing it's the latter. The implementation technique> > Hendrik describes makes it a detected runtime error, but not unless/until> > you try to use the lost environment. This is more generous than Modula-3's > > rule.> > The actual Algol 68 definition does pronounce on this. The CDC > implementation was much more liberal than the language definition.> > Every reference/variable and every procedure has a scope. The scope of > a variable is the level on the run-time stack at which it is allocated. > Variables can be on the heap; this is global scope. The scope of a > procedure is the stack elvel at which its most local global identifier > is bound. Even if the identifier refers to an object on the heap, it is > the level at which it is bound that counts.> > There is a universal scope restriction: No object can refer to a more > local object. The constraint in the language definition is applied on > assignment.> > I know of no Algol 68 implementation that I can say for sure implements > this restriction with a run-time check. Of course it can be done, > either by tagging each pointer with an explicit mention of its stack > level (which takes space) or by comparing its value and comparing it to > various stack locations in a kind of search.> > The first release of the CDC algol 68 compiler just allocated all > variables on the heap, making the check unnecessary for safety. > Programmers almost never wrote code that passed procedures out-of-scope.> > Later releases performed static analysis to determine where it was safe > to allocate in the stack (almost all the time), and used the mechanism I > described earlier to check procedures when they were called if the > static check didn't suffice..> > > > And, of course, if your language is really dynamic, it could just say an> > environment is always accessible, requiring many or all activation records> > to be heap allocated.> > Which was a proposal made for the original Algol 68, but was turned > down. I think it should have been accepted. We would have had a > strongly-typed Scheme ahead of its time.> > -- hendrik> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Sun Jun 1 04:32:37 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 31 May 2008 21:32:37 -0500 Subject: [M3devel] function pointers and comparison to nil? mis-typed function pointers? In-Reply-To: References: <483862F4.1E75.00D7.1@scires.com> <483A3377.7070801@wichita.edu> <48408AEE.8090405@wichita.edu> <20080531132924.GA30413@topoi.pooq.com> Message-ID: <48420A45.6070401@wichita.edu> Jay wrote: > > I don't understand "can only assign a top-level procedure". > My understanding is that Modula-3 does allow the "unsafe" option -- take > the address of a nested function, pass it off to some code, that stores > it in a global, and call it later. But of course, "Modula-3 does allow > the unsafe option" does not compute. I need to read up and experiment. No, Modula-3 does not allow the above. The only thing you can do with a nested procedure is pass it as a parameter. The lifetime of the parameter will always lie within the lifetime of the current activation of the the nested procedure, so this is safe. If you try to assign a procedure to a variable/field/array-element, the language says the procedure value must be top-level. (See 2.3.1, assignability of an expression to a variable, second condition.) This is also safe. If the RHS of the assignment is a procedure constant, this can be checked statically. If the RHS is a formal parameter (thus variable at runtime), this must be a runtime check, because its value could be a nested procedure. The compiler implements the RT check by checking whether the pointer points to a closure or not, or rather, whether it points to a closure flag word. This implementation choice of representation of procedure values correctly implements the language, while still making global procedure values have the same representation as C pointers to (global) functions. > > Maybe there is a runtime check whenever I assign a function pointer to > either a global or to a field in non-local record, that it isn't a closure? > That makes a fair amount of sense though hard to not make the check > overly strict I think. Yes, this is not the loosest safe rule. Hardly anything is, in a safe language. The language designers have to make careful tradeoffs among programmer freedom, efficient implementability, and language simplicity. This is just the way Modula-3 makes the tradeoff to prevent dangling environment pointer bugs from happening. > >-- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jayk123 at hotmail.com Sun Jun 1 04:32:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 1 Jun 2008 02:32:27 +0000 Subject: [M3devel] proposal/insistence for fixed size integer types in Ctypes.i3 Message-ID: Currently the various Utypes.i3 introduce various types LIKE uint8_t = unsigned_char; uint16_t = unsigned_short; uint32_t = unsigned_int; uint64_t = unsigned_long_long; int8_t = signed_char; int16_t = short; int32_t = int; int64_t = long_long; sometimes there is an underscore after the u. There is quite some variation in which, if any, of these types are provided. When they are provided, they are always the same, with one exception I will detail. Arguably they are provided only for defining other types and function signatures within m3-libs/m3core/src/unix. I strongly strongly strongly propose that at least the above 8 types go in Ctypes, and the definitions in Utypes removed. If there was more commonality in Utypes, I'd "forward" them for compatibility, but there is little commonality. Code depending on these types would have to be forked a lot. As I said, the types are always the same, if they are defined, but they are often not defined. One variation I am open to is introducing a new .i3 file. But in general I like to colocate stuff rather than pick apart everything and decide an ideal location. There are tradeoffs either way, though most people only see the tradeoffs in the way I do it. The tradeoffs the other way are having to track down module after module, interface after interface, where to get stuff from, rather than having a "one stop shop", or "fewer shops to stop". I am also willing to have u_* types and CAPITALIZED types: uint8_t = unsigned_char; uint16_t = unsigned_short; uint32_t = unsigned_int; uint64_t = unsigned_long_long; int8_t = signed_char; int16_t = short; int32_t = int; int64_t = long_long; u_int8_t = uint8_t; u_int16_t = uint16_t; u_int32_t = uint32_t; u_int64_t = uint64_t; UINT8 = uint8_t; UINT16 = uint16_t; UINT32 = uint32_t; UINT64 = uint64_t; INT8 = int8_t; INT16 = int16_t; INT32 = int32_t; INT64 = int64_t; All built-in Modula-3 types are capitalized, as all Modula-3 keywords are. And capitalized types is a style widely used in the Windows headers. (Windows and Modula-3 share a common heritage -- Digital -- though I don't know from where the style of capitalized types originates.) The names "int8", "int16" are also obvious candidates, but I feel that some amount of typographical convention should be used to demark types. Some amount of "Hungarian", if you will. Obviously there are vehement opposing opinions on this. "Hungarian" is often too precise and precludes changing types without changing names, as well as producing unpronouncable names. A "weak" form however seems reasonable and useful. These types represent a certain point of view. It is a common point of view, but not universal. There are roughly three or four perspectives here: 1) char, short, int, long are abstractly defined and all code should live with it. char is at least 8 bits, and of unspecified signedness (limits.h defines CHAR_BIT, the number of bits in char for specified signedness, use signed char or unsigned char; I think char has actually three options for its signess -- signed, unsigned, or "half unsigned") short is at least 16 bits, signed int is at least 16 bits, signed long is at least 32 bits, signed There are not necessarily integral types that can hold pointers. size_t and ptrdiff_t perhaps, but unclear. size_t can hold the size of anything, but I think "anything" is "any variable" and not necessarily "the entire address space". ptrdiff_t can hold the result of subtracting pointers, but it is only valid to subtract pointers that point into the same array or just past it. It is common, for example, but not universal, for the "address space" to be divided between "user mode" and "kernel mode", often with a 50/50 split, so therefore size_t could be one bit smaller than a pointer, at least. Of course that's an "unnatural" size, but theoretically possible. (This kernel/user 50/50 split is usually exactly how 32 bit and I assume 64 bit Windows works, though 32 bit Windows can also have a 3 gig / 1 gig split, and 32 bit Windows code running on 64 bit Windows kernel can get a full 4 gig address space.) As well, the representation of signed integers is left unspecified. The range of "int" need only go down to -32767, not necessarily -32768. Signed magnitude and one's complement are valid representations. Overflowing a signed integer causes undefined behavior. Unsigned numbers do not have this abstraction. While this is the "most correct" view, according to (my understanding) the C standard, implementations do nail down details way beyond this, and a lot of code depends on these details. While I may have some of those details slightly wrong, you get the point. You CAN write code within this interface, but a lot of code violates it, sometimes by accident, sometimes for important practical reasons. Some amount of code assumes an int is at least or exactly 32 bits. Some amount of code assumes int or long can hold a pointer, though int probably not so much, and long probably of proportionally rapidly decreasing instance due to Win64. 2) char, short, int, long are somewhat abstractly defined char is exactly 8 bits varying perspectives on its presumed signedness short is exactly 16 bits int is exactly 32 bits long there are few perspectives on; it is exactly 32 bits ("Windows"), or it is exactly the size of a pointer ("Unix"), or it is at least the size of a pointer As well, two's complement is the only representation of signed numbers in use, and code depends on this. (I recently read that we can thank the IBM S/360 or such, in the 1960's, for introducing such modern-day architectural features that everyone takes for granted as an 8 bit byte and two's complement signed numbers.) If you need an integer with a particular exact size, either use char/short/int directly, or run them through "autoconf", or sniff "limits.h". 3) This is my recently acquired perspective, but it isn't new. Given that #1 is "correct but rare", and that #2 are full of "exact": char, short, int, long are funny names with not particularly useful specifications. #2 is a little sleazy (less so if autoconfed/limits.h) Unless you are really adhering to the strict spec, don't use them. If you are in fact indexing a "small" array, they might suffice, but is it worth it? worth having these types? Theory: 16 bit machines are irrelevant and 32 bit integers are perfectly efficient on 64 bit machines, and 64 bit integers are universally available (?) and reasonably efficient (?), so feel free to use them if there is a need. As well, 4gig remains a large capacity in most contexts, so feel free to use explictly 32 bit integers. However file sizes and offsets should really always be 64 bits. Any code still requiring 32 bit file offsets/sizes is unfortunate. That includes PE32+ imho, the file format for .exes/.dlls on Win64. Be clear and unsleazy and adopt new names that represent well their specification and actual use. int_t is exactly n bits in size and signed uint_t is exactly n bits in size and unsigned some names are chosen for unsigned and signed integers with the exact size of a pointer For n=8,16,32 all four types exist, and probably 64. And pointer-sized types exist. If you really feel your capacity limits should scale with address space size, or need to store a pointer in an integer, use size_t or uintptr_t or intptr_t, etc. Modula-3's position here adds that INTEGER is the exact size of a pointer and signed. It is identical to ptrdiff_t or intptr_t. CARDINAL is the exact size but omits the bottom "half" of the range, and does not, I believe, extend the top "half". Now, I also realize, that m3-libs/m3core/src/unix is a fairly mechanical translation of /usr/include, and /usr/include does not necessarily take perspective #3. So the "funny" names are useful for a human mechanical translation. But the precise names can still be used instead. Here is an exception I said I would detail: irix-5.2/utypes.i3: int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END; uint64_t = int64_t; This is different in at least two ways that I see. - default initialization to zero - 32 bit alignment instead of 64 bit alignment I tend to assume that the alignment is actually wrong, however all the uses in Usignal appear unaffected, as they are always preceded by a mix of int64_t and an even number of int32. Either way, it is easy enough to preserve this for compatibility. I would like to continue, where easy and clear, to reduce the "size" of m3-libs/m3core/src/unix. Making these types portable available helps that. For example -- Uin.m3 need not be duplicated at all. But then it either must use the presently more portable unsigned_short and unsigned, or uint16_t and uint32_t should be made always available, either by adding them to all the various Utypes.i3, or the one Ctypes.i3, or a new place. Darwin currently has four Upthread.i3 files (one is dead), but needs either only two, or one with the sizes abstracted out. I don't know if PPC64_DARWIN will needs its own yet, I don't have one of these machines yet. I would like to go ahead with this stuff *today*. It takes some exertion of patience for me to stop and send this first. :) - Jay From jayk123 at hotmail.com Sun Jun 1 04:35:40 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 1 Jun 2008 02:35:40 +0000 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 Message-ID: So much for trying plain text to avoid truncation, darnit.> From: jayk123 at hotmail.com> To: m3devel at elegosoft.com> Subject: proposal/insistence for fixed size integer types in Ctypes.i3> Date: Sun, 1 Jun 2008 02:32:27 +0000> > > > Currently the various Utypes.i3 introduce various types LIKE> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > sometimes there is an underscore after the u.> > > There is quite some variation in which, if any, of these types are provided.> When they are provided, they are always the same, with one exception I will detail.> > > Arguably they are provided only for defining other types and function signatures> within m3-libs/m3core/src/unix.> > > I strongly strongly strongly propose that at least the above 8 types go in> Ctypes, and the definitions in Utypes removed.> > > If there was more commonality in Utypes, I'd "forward" them for compatibility,> but there is little commonality. Code depending on these types would have to> be forked a lot. As I said, the types are always the same, if they are defined,> but they are often not defined.> > > One variation I am open to is introducing a new .i3 file.> But in general I like to colocate stuff rather than pick apart everything> and decide an ideal location. There are tradeoffs either way,> though most people only see the tradeoffs in the way I do it.> The tradeoffs the other way are having to track down module after module,> interface after interface, where to get stuff from, rather than having> a "one stop shop", or "fewer shops to stop".> > > I am also willing to have u_* types and CAPITALIZED types:> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > u_int8_t = uint8_t;> u_int16_t = uint16_t;> u_int32_t = uint32_t;> u_int64_t = uint64_t;> > > UINT8 = uint8_t;> UINT16 = uint16_t;> UINT32 = uint32_t;> UINT64 = uint64_t;> > > INT8 = int8_t;> INT16 = int16_t;> INT32 = int32_t;> INT64 = int64_t;> > > All built-in Modula-3 types are capitalized, as all Modula-3 keywords are.> And capitalized types is a style widely used in the Windows headers.> (Windows and Modula-3 share a common heritage -- Digital -- though I don't know> from where the style of capitalized types originates.)> > > The names "int8", "int16" are also obvious candidates, but I feel that some> amount of typographical convention should be used to demark types.> Some amount of "Hungarian", if you will.> Obviously there are vehement opposing opinions on this.> "Hungarian" is often too precise and precludes changing types without> changing names, as well as producing unpronouncable names.> A "weak" form however seems reasonable and useful.> > > These types represent a certain point of view.> It is a common point of view, but not universal.> > > There are roughly three or four perspectives here:> > > 1)> char, short, int, long are abstractly defined and all code should live with it.> char is at least 8 bits, and of unspecified signedness> (limits.h defines CHAR_BIT, the number of bits in char> for specified signedness, use signed char or unsigned char;> I think char has actually three options for its signess -- signed, unsigned, or "half unsigned")> short is at least 16 bits, signed> int is at least 16 bits, signed> long is at least 32 bits, signed> > > There are not necessarily integral types that can hold pointers.> size_t and ptrdiff_t perhaps, but unclear.> size_t can hold the size of anything, but I think "anything" is "any variable"> and not necessarily "the entire address space".> > > ptrdiff_t can hold the result of subtracting pointers, but it is only> valid to subtract pointers that point into the same array or just past it.> > > It is common, for example, but not universal, for the "address space"> to be divided between "user mode" and "kernel mode", often with a 50/50 split,> so therefore size_t could be one bit smaller than a pointer, at least.> Of course that's an "unnatural" size, but theoretically possible.> (This kernel/user 50/50 split is usually exactly how 32 bit and I assume> 64 bit Windows works, though 32 bit Windows can also have a 3 gig / 1 gig split,> and 32 bit Windows code running on 64 bit Windows kernel can get a> full 4 gig address space.)> > > As well, the representation of signed integers is left unspecified.> The range of "int" need only go down to -32767, not necessarily -32768.> Signed magnitude and one's complement are valid representations.> Overflowing a signed integer causes undefined behavior.> Unsigned numbers do not have this abstraction.> > > While this is the "most correct" view, according to (my understanding) the C standard,> implementations do nail down details way beyond this, and a lot of> code depends on these details.> > > While I may have some of those details slightly wrong, you get the point.> You CAN write code within this interface, but a lot of code violates it, sometimes> > > by accident, sometimes for important practical reasons.> Some amount of code assumes an int is at least or exactly 32 bits.> Some amount of code assumes int or long can hold a pointer, though> int probably not so much, and long probably of proportionally> rapidly decreasing instance due to Win64.> > > > 2)> char, short, int, long are somewhat abstractly defined> char is exactly 8 bits> varying perspectives on its presumed signedness> short is exactly 16 bits> int is exactly 32 bits> long there are few perspectives on; it is exactly 32 bits ("Windows"), or> it is exactly the size of a pointer ("Unix"), or it is at least> the size of a pointer> > > As well, two's complement is the only representation of signed numbers> in use, and code depends on this.> > > (I recently read that we can thank the IBM S/360 or such, in the 1960's,> for introducing such modern-day architectural features that everyone> takes for granted as an 8 bit byte and two's complement signed numbers.)> > > If you need an integer with a particular exact size, either use char/short/int directly,> or run them through "autoconf", or sniff "limits.h".> > > 3) This is my recently acquired perspective, but it isn't new.> > > Given that #1 is "correct but rare", and that #2 are> full of "exact":> > > char, short, int, long are funny names with not particularly> useful specifications. #2 is a little sleazy (less so if autoconfed/limits.h)> Unless you are really adhering to the strict spec, don't use them.> If you are in fact indexing a "small" array, they might suffice,> but is it worth it? worth having these types?> > > Theory: 16 bit machines are irrelevant and 32 bit integers> are perfectly efficient on 64 bit machines, and 64 bit integers> are universally available (?) and reasonably efficient (?),> so feel free to use them if there is a need.> > > As well, 4gig remains a large capacity in most contexts, so feel> free to use explictly 32 bit integers.> > > However file sizes and offsets should really always be 64 bits.> Any code still requiring 32 bit file offsets/sizes is unfortunate.> That includes PE32+ imho, the file format for .exes/.dlls on Win64.> > > Be clear and unsleazy and adopt new names that represent well> their specification and actual use.> > > int_t is exactly n bits in size and signed> uint_t is exactly n bits in size and unsigned> some names are chosen for unsigned and signed integers with> the exact size of a pointer> For n=8,16,32 all four types exist, and probably 64.> And pointer-sized types exist.> > > If you really feel your capacity limits should scale with address space size, or need> to store a pointer in an integer, use size_t or uintptr_t or intptr_t, etc.> > > Modula-3's position here adds that INTEGER is the exact> size of a pointer and signed. It is identical to ptrdiff_t> or intptr_t. CARDINAL is the exact size but omits the bottom "half"> of the range, and does not, I believe, extend the top "half".> > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly mechanical> translation of /usr/include, and /usr/include does not necessarily> take perspective #3. So the "funny" names are useful for a human> mechanical translation. But the precise names can still be used instead.> > > Here is an exception I said I would detail:> > > irix-5.2/utypes.i3:> int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END;> uint64_t = int64_t;> > > This is different in at least two ways that I see.> - default initialization to zero> - 32 bit alignment instead of 64 bit alignment> > > I tend to assume that the alignment is actually wrong,> however all the uses in Usignal appear unaffected, as they are always preceded> by a mix of int64_t and an even number of int32.> Either way, it is easy enough to preserve this for compatibility.> > > I would like to continue, where easy and clear, to reduce the "size" of m3-libs/m3core/src/unix.> Making these types portable available helps that.> For example -- Uin.m3 need not be duplicated at all.> But then it either must use the presently more portable unsigned_short and unsigned,> or uint16_t and uint32_t should be made always available, either by adding them> to all the various Utypes.i3, or the one Ctypes.i3, or a new place.> > > Darwin currently has four Upthread.i3 files (one is dead), but needs either only two, or one> with the sizes abstracted out. I don't know if PPC64_DARWIN will needs its own yet,> I don't have one of these machines yet.> > > I would like to go ahead with this stuff *today*.> It takes some exertion of patience for me to stop and send this first. :)> > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Jun 1 20:57:56 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 01 Jun 2008 11:57:56 -0700 Subject: [M3devel] function pointers and comparison to nil? mis-typed function pointers? In-Reply-To: Your message of "Sun, 01 Jun 2008 01:40:42 -0000." Message-ID: <200806011857.m51Ivu2X045935@camembert.async.caltech.edu> Jay writes: >--_c746a382-25b6-4547-9df2-927b317b6eab_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > In Modula-3, you can pass any procedure but only assign a top-level proc= >edure. > This precludes dangling environments in yet another way, that is m= >ore liberal > than either Pascal or Modula-2,, but requires a runtime check= > on procedure >I don't understand "can only assign a top-level procedure". >My understanding is that Modula-3 does allow the "unsafe" option -- take th= >e address of a nested function, pass it off to some code, that stores it in= > a global, and call it later. But of course, "Modula-3 does allow the unsaf= >e option" does not compute. I need to read up and experiment. >=20 >Maybe there is a runtime check whenever I assign a function pointer to eith= >er a global or to a field in non-local record, that it isn't a closure? >That makes a fair amount of sense though hard to not make the check overly = >strict I think. >=20 Jay, surely you remember that: "A procedure is either NIL or a triple consisting of: * the body, which is a statement, * the signature, ... * the environment, which is the scope with respect to which variable names in the body will be interpreted. A top-level procedure is a procedure declared in the outermost scope of a module. Any other procedure is a local procedure. A local procedure can be passed as a parameter but not assigned, since in a stack implementation a local procedure becomes invalid when the frame for the procedure containing it is popped. ... " The "since in a stack implementation..." clause seems superfluous to me, but I suppose it might be helpful for those who simply must think in terms of a specific implementation. From hosking at cs.purdue.edu Mon Jun 2 11:23:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jun 2008 10:23:44 +0100 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: References: Message-ID: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Are these types defined by the C standard. If not then they don't belong in Ctypes. If they are only defined by their particular platform then they do belong in Utypes. On Jun 1, 2008, at 3:35 AM, Jay wrote: > So much for trying plain text to avoid truncation, darnit. > > > > > From: jayk123 at hotmail.com > > To: m3devel at elegosoft.com > > Subject: proposal/insistence for fixed size integer types in > Ctypes.i3 > > Date: Sun, 1 Jun 2008 02:32:27 +0000 > > > > > > > > Currently the various Utypes.i3 introduce various types LIKE > > > > > > uint8_t = unsigned_char; > > uint16_t = unsigned_short; > > uint32_t = unsigned_int; > > uint64_t = unsigned_long_long; > > > > > > int8_t = signed_char; > > int16_t = short; > > int32_t = int; > > int64_t = long_long; > > > > > > sometimes there is an underscore after the u. > > > > > > There is quite some variation in which, if any, of these types are > provided. > > When they are provided, they are always the same, with one > exception I will detail. > > > > > > Arguably they are provided only for defining other types and > function signatures > > within m3-libs/m3core/src/unix. > > > > > > I strongly strongly strongly propose that at least the above 8 > types go in > > Ctypes, and the definitions in Utypes removed. > > > > > > If there was more commonality in Utypes, I'd "forward" them for > compatibility, > > but there is little commonality. Code depending on these types > would have to > > be forked a lot. As I said, the types are always the same, if they > are defined, > > but they are often not defined. > > > > > > One variation I am open to is introducing a new .i3 file. > > But in general I like to colocate stuff rather than pick apart > everything > > and decide an ideal location. There are tradeoffs either way, > > though most people only see the tradeoffs in the way I do it. > > The tradeoffs the other way are having to track down module after > module, > > interface after interface, where to get stuff from, rather than > having > > a "one stop shop", or "fewer shops to stop". > > > > > > I am also willing to have u_* types and CAPITALIZED types: > > > > > > uint8_t = unsigned_char; > > uint16_t = unsigned_short; > > uint32_t = unsigned_int; > > uint64_t = unsigned_long_long; > > > > > > int8_t = signed_char; > > int16_t = short; > > int32_t = int; > > int64_t = long_long; > > > > > > u_int8_t = uint8_t; > > u_int16_t = uint16_t; > > u_int32_t = uint32_t; > > u_int64_t = uint64_t; > > > > > > UINT8 = uint8_t; > > UINT16 = uint16_t; > > UINT32 = uint32_t; > > UINT64 = uint64_t; > > > > > > INT8 = int8_t; > > INT16 = int16_t; > > INT32 = int32_t; > > INT64 = int64_t; > > > > > > All built-in Modula-3 types are capitalized, as all Modula-3 > keywords are. > > And capitalized types is a style widely used in the Windows headers. > > (Windows and Modula-3 share a common heritage -- Digital -- though > I don't know > > from where the style of capitalized types originates.) > > > > > > The names "int8", "int16" are also obvious candidates, but I feel > that some > > amount of typographical convention should be used to demark types. > > Some amount of "Hungarian", if you will. > > Obviously there are vehement opposing opinions on this. > > "Hungarian" is often too precise and precludes changing types > without > > changing names, as well as producing unpronouncable names. > > A "weak" form however seems reasonable and useful. > > > > > > These types represent a certain point of view. > > It is a common point of view, but not universal. > > > > > > There are roughly three or four perspectives here: > > > > > > 1) > > char, short, int, long are abstractly defined and all code should > live with it. > > char is at least 8 bits, and of unspecified signedness > > (limits.h defines CHAR_BIT, the number of bits in char > > for specified signedness, use signed char or unsigned char; > > I think char has actually three options for its signess -- signed, > unsigned, or "half unsigned") > > short is at least 16 bits, signed > > int is at least 16 bits, signed > > long is at least 32 bits, signed > > > > > > There are not necessarily integral types that can hold pointers. > > size_t and ptrdiff_t perhaps, but unclear. > > size_t can hold the size of anything, but I think "anything" is > "any variable" > > and not necessarily "the entire address space". > > > > > > ptrdiff_t can hold the result of subtracting pointers, but it is > only > > valid to subtract pointers that point into the same array or just > past it. > > > > > > It is common, for example, but not universal, for the "address > space" > > to be divided between "user mode" and "kernel mode", often with a > 50/50 split, > > so therefore size_t could be one bit smaller than a pointer, at > least. > > Of course that's an "unnatural" size, but theoretically possible. > > (This kernel/user 50/50 split is usually exactly how 32 bit and I > assume > > 64 bit Windows works, though 32 bit Windows can also have a 3 > gig / 1 gig split, > > and 32 bit Windows code running on 64 bit Windows kernel can get a > > full 4 gig address space.) > > > > > > As well, the representation of signed integers is left unspecified. > > The range of "int" need only go down to -32767, not necessarily > -32768. > > Signed magnitude and one's complement are valid representations. > > Overflowing a signed integer causes undefined behavior. > > Unsigned numbers do not have this abstraction. > > > > > > While this is the "most correct" view, according to (my > understanding) the C standard, > > implementations do nail down details way beyond this, and a lot of > > code depends on these details. > > > > > > While I may have some of those details slightly wrong, you get the > point. > > You CAN write code within this interface, but a lot of code > violates it, sometimes > > > > > > by accident, sometimes for important practical reasons. > > Some amount of code assumes an int is at least or exactly 32 bits. > > Some amount of code assumes int or long can hold a pointer, though > > int probably not so much, and long probably of proportionally > > rapidly decreasing instance due to Win64. > > > > > > > > 2) > > char, short, int, long are somewhat abstractly defined > > char is exactly 8 bits > > varying perspectives on its presumed signedness > > short is exactly 16 bits > > int is exactly 32 bits > > long there are few perspectives on; it is exactly 32 bits > ("Windows"), or > > it is exactly the size of a pointer ("Unix"), or it is at least > > the size of a pointer > > > > > > As well, two's complement is the only representation of signed > numbers > > in use, and code depends on this. > > > > > > (I recently read that we can thank the IBM S/360 or such, in the > 1960's, > > for introducing such modern-day architectural features that everyone > > takes for granted as an 8 bit byte and two's complement signed > numbers.) > > > > > > If you need an integer with a particular exact size, either use > char/short/int directly, > > or run them through "autoconf", or sniff "limits.h". > > > > > > 3) This is my recently acquired perspective, but it isn't new. > > > > > > Given that #1 is "correct but rare", and that #2 are > > full of "exact": > > > > > > char, short, int, long are funny names with not particularly > > useful specifications. #2 is a little sleazy (less so if > autoconfed/limits.h) > > Unless you are really adhering to the strict spec, don't use them. > > If you are in fact indexing a "small" array, they might suffice, > > but is it worth it? worth having these types? > > > > > > Theory: 16 bit machines are irrelevant and 32 bit integers > > are perfectly efficient on 64 bit machines, and 64 bit integers > > are universally available (?) and reasonably efficient (?), > > so feel free to use them if there is a need. > > > > > > As well, 4gig remains a large capacity in most contexts, so feel > > free to use explictly 32 bit integers. > > > > > > However file sizes and offsets should really always be 64 bits. > > Any code still requiring 32 bit file offsets/sizes is unfortunate. > > That includes PE32+ imho, the file format for .exes/.dlls on Win64. > > > > > > Be clear and unsleazy and adopt new names that represent well > > their specification and actual use. > > > > > > int_t is exactly n bits in size and signed > > uint_t is exactly n bits in size and unsigned > > some names are chosen for unsigned and signed integers with > > the exact size of a pointer > > For n=8,16,32 all four types exist, and probably 64. > > And pointer-sized types exist. > > > > > > If you really feel your capacity limits should scale with address > space size, or need > > to store a pointer in an integer, use size_t or uintptr_t or > intptr_t, etc. > > > > > > Modula-3's position here adds that INTEGER is the exact > > size of a pointer and signed. It is identical to ptrdiff_t > > or intptr_t. CARDINAL is the exact size but omits the bottom "half" > > of the range, and does not, I believe, extend the top "half". > > > > > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly > mechanical > > translation of /usr/include, and /usr/include does not necessarily > > take perspective #3. So the "funny" names are useful for a human > > mechanical translation. But the precise names can still be used > instead. > > > > > > Here is an exception I said I would detail: > > > > > > irix-5.2/utypes.i3: > > int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END; > > uint64_t = int64_t; > > > > > > This is different in at least two ways that I see. > > - default initialization to zero > > - 32 bit alignment instead of 64 bit alignment > > > > > > I tend to assume that the alignment is actually wrong, > > however all the uses in Usignal appear unaffected, as they are > always preceded > > by a mix of int64_t and an even number of int32. > > Either way, it is easy enough to preserve this for compatibility. > > > > > > I would like to continue, where easy and clear, to reduce the > "size" of m3-libs/m3core/src/unix. > > Making these types portable available helps that. > > For example -- Uin.m3 need not be duplicated at all. > > But then it either must use the presently more portable > unsigned_short and unsigned, > > or uint16_t and uint32_t should be made always available, either > by adding them > > to all the various Utypes.i3, or the one Ctypes.i3, or a new place. > > > > > > Darwin currently has four Upthread.i3 files (one is dead), but > needs either only two, or one > > with the sizes abstracted out. I don't know if PPC64_DARWIN will > needs its own yet, > > I don't have one of these machines yet. > > > > > > I would like to go ahead with this stuff *today*. > > It takes some exertion of patience for me to stop and send this > first. :) > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jun 2 12:13:41 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 2 Jun 2008 10:13:41 +0000 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> References: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Message-ID: They are not from the C standard, nor are they necessarily from a particular platform. Some platforms define some of them. But all platforms could define all of them, at least 8/16/32, and could define them identically. I want to add these somewhere in m3core. They are portable enough. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3Date: Mon, 2 Jun 2008 10:23:44 +0100 Are these types defined by the C standard. If not then they don't belong in Ctypes. If they are only defined by their particular platform then they do belong in Utypes. On Jun 1, 2008, at 3:35 AM, Jay wrote: So much for trying plain text to avoid truncation, darnit.> From: jayk123 at hotmail.com> To: m3devel at elegosoft.com> Subject: proposal/insistence for fixed size integer types in Ctypes.i3> Date: Sun, 1 Jun 2008 02:32:27 +0000> > > > Currently the various Utypes.i3 introduce various types LIKE> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > sometimes there is an underscore after the u.> > > There is quite some variation in which, if any, of these types are provided.> When they are provided, they are always the same, with one exception I will detail.> > > Arguably they are provided only for defining other types and function signatures> within m3-libs/m3core/src/unix.> > > I strongly strongly strongly propose that at least the above 8 types go in> Ctypes, and the definitions in Utypes removed.> > > If there was more commonality in Utypes, I'd "forward" them for compatibility,> but there is little commonality. Code depending on these types would have to> be forked a lot. As I said, the types are always the same, if they are defined,> but they are often not defined.> > > One variation I am open to is introducing a new .i3 file.> But in general I like to colocate stuff rather than pick apart everything> and decide an ideal location. There are tradeoffs either way,> though most people only see the tradeoffs in the way I do it.> The tradeoffs the other way are having to track down module after module,> interface after interface, where to get stuff from, rather than having> a "one stop shop", or "fewer shops to stop".> > > I am also willing to have u_* types and CAPITALIZED types:> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > u_int8_t = uint8_t;> u_int16_t = uint16_t;> u_int32_t = uint32_t;> u_int64_t = uint64_t;> > > UINT8 = uint8_t;> UINT16 = uint16_t;> UINT32 = uint32_t;> UINT64 = uint64_t;> > > INT8 = int8_t;> INT16 = int16_t;> INT32 = int32_t;> INT64 = int64_t;> > > All built-in Modula-3 types are capitalized, as all Modula-3 keywords are.> And capitalized types is a style widely used in the Windows headers.> (Windows and Modula-3 share a common heritage -- Digital -- though I don't know> from where the style of capitalized types originates.)> > > The names "int8", "int16" are also obvious candidates, but I feel that some> amount of typographical convention should be used to demark types.> Some amount of "Hungarian", if you will.> Obviously there are vehement opposing opinions on this.> "Hungarian" is often too precise and precludes changing types without> changing names, as well as producing unpronouncable names.> A "weak" form however seems reasonable and useful.> > > These types represent a certain point of view.> It is a common point of view, but not universal.> > > There are roughly three or four perspectives here:> > > 1)> char, short, int, long are abstractly defined and all code should live with it.> char is at least 8 bits, and of unspecified signedness> (limits.h defines CHAR_BIT, the number of bits in char> for specified signedness, use signed char or unsigned char;> I think char has actually three options for its signess -- signed, unsigned, or "half unsigned")> short is at least 16 bits, signed> int is at least 16 bits, signed> long is at least 32 bits, signed> > > There are not necessarily integral types that can hold pointers.> size_t and ptrdiff_t perhaps, but unclear.> size_t can hold the size of anything, but I think "anything" is "any variable"> and not necessarily "the entire address space".> > > ptrdiff_t can hold the result of subtracting pointers, but it is only> valid to subtract pointers that point into the same array or just past it.> > > It is common, for example, but not universal, for the "address space"> to be divided between "user mode" and "kernel mode", often with a 50/50 split,> so therefore size_t could be one bit smaller than a pointer, at least.> Of course that's an "unnatural" size, but theoretically possible.> (This kernel/user 50/50 split is usually exactly how 32 bit and I assume> 64 bit Windows works, though 32 bit Windows can also have a 3 gig / 1 gig split,> and 32 bit Windows code running on 64 bit Windows kernel can get a> full 4 gig address space.)> > > As well, the representation of signed integers is left unspecified.> The range of "int" need only go down to -32767, not necessarily -32768.> Signed magnitude and one's complement are valid representations.> Overflowing a signed integer causes undefined behavior.> Unsigned numbers do not have this abstraction.> > > While this is the "most correct" view, according to (my understanding) the C standard,> implementations do nail down details way beyond this, and a lot of> code depends on these details.> > > While I may have some of those details slightly wrong, you get the point.> You CAN write code within this interface, but a lot of code violates it, sometimes> > > by accident, sometimes for important practical reasons.> Some amount of code assumes an int is at least or exactly 32 bits.> Some amount of code assumes int or long can hold a pointer, though> int probably not so much, and long probably of proportionally> rapidly decreasing instance due to Win64.> > > > 2)> char, short, int, long are somewhat abstractly defined> char is exactly 8 bits> varying perspectives on its presumed signedness> short is exactly 16 bits> int is exactly 32 bits> long there are few perspectives on; it is exactly 32 bits ("Windows"), or> it is exactly the size of a pointer ("Unix"), or it is at least> the size of a pointer> > > As well, two's complement is the only representation of signed numbers> in use, and code depends on this.> > > (I recently read that we can thank the IBM S/360 or such, in the 1960's,> for introducing such modern-day architectural features that everyone> takes for granted as an 8 bit byte and two's complement signed numbers.)> > > If you need an integer with a particular exact size, either use char/short/int directly,> or run them through "autoconf", or sniff "limits.h".> > > 3) This is my recently acquired perspective, but it isn't new.> > > Given that #1 is "correct but rare", and that #2 are> full of "exact":> > > char, short, int, long are funny names with not particularly> useful specifications. #2 is a little sleazy (less so if autoconfed/limits.h)> Unless you are really adhering to the strict spec, don't use them.> If you are in fact indexing a "small" array, they might suffice,> but is it worth it? worth having these types?> > > Theory: 16 bit machines are irrelevant and 32 bit integers> are perfectly efficient on 64 bit machines, and 64 bit integers> are universally available (?) and reasonably efficient (?),> so feel free to use them if there is a need.> > > As well, 4gig remains a large capacity in most contexts, so feel> free to use explictly 32 bit integers.> > > However file sizes and offsets should really always be 64 bits.> Any code still requiring 32 bit file offsets/sizes is unfortunate.> That includes PE32+ imho, the file format for .exes/.dlls on Win64.> > > Be clear and unsleazy and adopt new names that represent well> their specification and actual use.> > > int_t is exactly n bits in size and signed> uint_t is exactly n bits in size and unsigned> some names are chosen for unsigned and signed integers with> the exact size of a pointer> For n=8,16,32 all four types exist, and probably 64.> And pointer-sized types exist.> > > If you really feel your capacity limits should scale with address space size, or need> to store a pointer in an integer, use size_t or uintptr_t or intptr_t, etc.> > > Modula-3's position here adds that INTEGER is the exact> size of a pointer and signed. It is identical to ptrdiff_t> or intptr_t. CARDINAL is the exact size but omits the bottom "half"> of the range, and does not, I believe, extend the top "half".> > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly mechanical> translation of /usr/include, and /usr/include does not necessarily> take perspective #3. So the "funny" names are useful for a human> mechanical translation. But the precise names can still be used instead.> > > Here is an exception I said I would detail:> > > irix-5.2/utypes.i3:> int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END;> uint64_t = int64_t;> > > This is different in at least two ways that I see.> - default initialization to zero> - 32 bit alignment instead of 64 bit alignment> > > I tend to assume that the alignment is actually wrong,> however all the uses in Usignal appear unaffected, as they are always preceded> by a mix of int64_t and an even number of int32.> Either way, it is easy enough to preserve this for compatibility.> > > I would like to continue, where easy and clear, to reduce the "size" of m3-libs/m3core/src/unix.> Making these types portable available helps that.> For example -- Uin.m3 need not be duplicated at all.> But then it either must use the presently more portable unsigned_short and unsigned,> or uint16_t and uint32_t should be made always available, either by adding them> to all the various Utypes.i3, or the one Ctypes.i3, or a new place.> > > Darwin currently has four Upthread.i3 files (one is dead), but needs either only two, or one> with the sizes abstracted out. I don't know if PPC64_DARWIN will needs its own yet,> I don't have one of these machines yet.> > > I would like to go ahead with this stuff *today*.> It takes some exertion of patience for me to stop and send this first. :)> > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 2 12:34:32 2008 From: jay.krell at cornell.edu (Jay) Date: Mon, 2 Jun 2008 10:34:32 +0000 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> References: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Message-ID: > I want to add these somewhere in m3core. Ok, how about this? I think we can agree to this easily. INTERFACE Cstdint; IMPORT Ctypes; TYPE int8_t = Ctypes.signed_char;uint8_t = Ctypes.unsigned_char; int16_t = Ctypes.short;uint16_t = Ctypes.unsigned_short; int32_t = Ctypes.int;uint32_t = Ctypes.unsigned_int; int64_t = Ctypes.long_long;uint64_t = Ctypes.unsigned_long_long; (* from here on out I don't care much, can be removed to avoid being wrong *) intptr_t = INTEGER;uintptr_t = CARDINAL; (* ? *) (* and esp. from here on out if there is any difficulty coming up with the definitions *) CONST PTRDIFF_MIN = FIRST(intptr_t);SIZE_MAX = LAST(uintptr_t); (* Should WCHAR be wchar_t, or be 16 bits always?wchar_t is sometimes larger than 16 bits. *) WCHAR_MIN = FIRST(WIDECHAR);WCHAR_MAX = LAST(WIDECHAR); (* The rest omitted as decreasing usefulness and possibly decreasing portability. *) I would just as soon integrate all this into the language as globalsbut people like to push stuff out to libraries where possible/easy.(Some C++ libraries -- Boost -- have become very contorted because it was possible but not easy.) - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3Date: Mon, 2 Jun 2008 10:13:41 +0000 They are not from the C standard, nor are they necessarily from a particular platform.Some platforms define some of them.But all platforms could define all of them, at least 8/16/32, and could define them identically.I want to add these somewhere in m3core.They are portable enough. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3Date: Mon, 2 Jun 2008 10:23:44 +0100 Are these types defined by the C standard. If not then they don't belong in Ctypes. If they are only defined by their particular platform then they do belong in Utypes. On Jun 1, 2008, at 3:35 AM, Jay wrote: So much for trying plain text to avoid truncation, darnit.> From: jayk123 at hotmail.com> To: m3devel at elegosoft.com> Subject: proposal/insistence for fixed size integer types in Ctypes.i3> Date: Sun, 1 Jun 2008 02:32:27 +0000> > > > Currently the various Utypes.i3 introduce various types LIKE> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > sometimes there is an underscore after the u.> > > There is quite some variation in which, if any, of these types are provided.> When they are provided, they are always the same, with one exception I will detail.> > > Arguably they are provided only for defining other types and function signatures> within m3-libs/m3core/src/unix.> > > I strongly strongly strongly propose that at least the above 8 types go in> Ctypes, and the definitions in Utypes removed.> > > If there was more commonality in Utypes, I'd "forward" them for compatibility,> but there is little commonality. Code depending on these types would have to> be forked a lot. As I said, the types are always the same, if they are defined,> but they are often not defined.> > > One variation I am open to is introducing a new .i3 file.> But in general I like to colocate stuff rather than pick apart everything> and decide an ideal location. There are tradeoffs either way,> though most people only see the tradeoffs in the way I do it.> The tradeoffs the other way are having to track down module after module,> interface after interface, where to get stuff from, rather than having> a "one stop shop", or "fewer shops to stop".> > > I am also willing to have u_* types and CAPITALIZED types:> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > u_int8_t = uint8_t;> u_int16_t = uint16_t;> u_int32_t = uint32_t;> u_int64_t = uint64_t;> > > UINT8 = uint8_t;> UINT16 = uint16_t;> UINT32 = uint32_t;> UINT64 = uint64_t;> > > INT8 = int8_t;> INT16 = int16_t;> INT32 = int32_t;> INT64 = int64_t;> > > All built-in Modula-3 types are capitalized, as all Modula-3 keywords are.> And capitalized types is a style widely used in the Windows headers.> (Windows and Modula-3 share a common heritage -- Digital -- though I don't know> from where the style of capitalized types originates.)> > > The names "int8", "int16" are also obvious candidates, but I feel that some> amount of typographical convention should be used to demark types.> Some amount of "Hungarian", if you will.> Obviously there are vehement opposing opinions on this.> "Hungarian" is often too precise and precludes changing types without> changing names, as well as producing unpronouncable names.> A "weak" form however seems reasonable and useful.> > > These types represent a certain point of view.> It is a common point of view, but not universal.> > > There are roughly three or four perspectives here:> > > 1)> char, short, int, long are abstractly defined and all code should live with it.> char is at least 8 bits, and of unspecified signedness> (limits.h defines CHAR_BIT, the number of bits in char> for specified signedness, use signed char or unsigned char;> I think char has actually three options for its signess -- signed, unsigned, or "half unsigned")> short is at least 16 bits, signed> int is at least 16 bits, signed> long is at least 32 bits, signed> > > There are not necessarily integral types that can hold pointers.> size_t and ptrdiff_t perhaps, but unclear.> size_t can hold the size of anything, but I think "anything" is "any variable"> and not necessarily "the entire address space".> > > ptrdiff_t can hold the result of subtracting pointers, but it is only> valid to subtract pointers that point into the same array or just past it.> > > It is common, for example, but not universal, for the "address space"> to be divided between "user mode" and "kernel mode", often with a 50/50 split,> so therefore size_t could be one bit smaller than a pointer, at least.> Of course that's an "unnatural" size, but theoretically possible.> (This kernel/user 50/50 split is usually exactly how 32 bit and I assume> 64 bit Windows works, though 32 bit Windows can also have a 3 gig / 1 gig split,> and 32 bit Windows code running on 64 bit Windows kernel can get a> full 4 gig address space.)> > > As well, the representation of signed integers is left unspecified.> The range of "int" need only go down to -32767, not necessarily -32768.> Signed magnitude and one's complement are valid representations.> Overflowing a signed integer causes undefined behavior.> Unsigned numbers do not have this abstraction.> > > While this is the "most correct" view, according to (my understanding) the C standard,> implementations do nail down details way beyond this, and a lot of> code depends on these details.> > > While I may have some of those details slightly wrong, you get the point.> You CAN write code within this interface, but a lot of code violates it, sometimes> > > by accident, sometimes for important practical reasons.> Some amount of code assumes an int is at least or exactly 32 bits.> Some amount of code assumes int or long can hold a pointer, though> int probably not so much, and long probably of proportionally> rapidly decreasing instance due to Win64.> > > > 2)> char, short, int, long are somewhat abstractly defined> char is exactly 8 bits> varying perspectives on its presumed signedness> short is exactly 16 bits> int is exactly 32 bits> long there are few perspectives on; it is exactly 32 bits ("Windows"), or> it is exactly the size of a pointer ("Unix"), or it is at least> the size of a pointer> > > As well, two's complement is the only representation of signed numbers> in use, and code depends on this.> > > (I recently read that we can thank the IBM S/360 or such, in the 1960's,> for introducing such modern-day architectural features that everyone> takes for granted as an 8 bit byte and two's complement signed numbers.)> > > If you need an integer with a particular exact size, either use char/short/int directly,> or run them through "autoconf", or sniff "limits.h".> > > 3) This is my recently acquired perspective, but it isn't new.> > > Given that #1 is "correct but rare", and that #2 are> full of "exact":> > > char, short, int, long are funny names with not particularly> useful specifications. #2 is a little sleazy (less so if autoconfed/limits.h)> Unless you are really adhering to the strict spec, don't use them.> If you are in fact indexing a "small" array, they might suffice,> but is it worth it? worth having these types?> > > Theory: 16 bit machines are irrelevant and 32 bit integers> are perfectly efficient on 64 bit machines, and 64 bit integers> are universally available (?) and reasonably efficient (?),> so feel free to use them if there is a need.> > > As well, 4gig remains a large capacity in most contexts, so feel> free to use explictly 32 bit integers.> > > However file sizes and offsets should really always be 64 bits.> Any code still requiring 32 bit file offsets/sizes is unfortunate.> That includes PE32+ imho, the file format for .exes/.dlls on Win64.> > > Be clear and unsleazy and adopt new names that represent well> their specification and actual use.> > > int_t is exactly n bits in size and signed> uint_t is exactly n bits in size and unsigned> some names are chosen for unsigned and signed integers with> the exact size of a pointer> For n=8,16,32 all four types exist, and probably 64.> And pointer-sized types exist.> > > If you really feel your capacity limits should scale with address space size, or need> to store a pointer in an integer, use size_t or uintptr_t or intptr_t, etc.> > > Modula-3's position here adds that INTEGER is the exact> size of a pointer and signed. It is identical to ptrdiff_t> or intptr_t. CARDINAL is the exact size but omits the bottom "half"> of the range, and does not, I believe, extend the top "half".> > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly mechanical> translation of /usr/include, and /usr/include does not necessarily> take perspective #3. So the "funny" names are useful for a human> mechanical translation. But the precise names can still be used instead.> > > Here is an exception I said I would detail:> > > irix-5.2/utypes.i3:> int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END;> uint64_t = int64_t;> > > This is different in at least two ways that I see.> - default initialization to zero> - 32 bit alignment instead of 64 bit alignment> > > I tend to assume that the alignment is actually wrong,> however all the uses in Usignal appear unaffected, as they are always preceded> by a mix of int64_t and an even number of int32.> Either way, it is easy enough to preserve this for compatibility.> > > I would like to continue, where easy and clear, to reduce the "size" of m3-libs/m3core/src/unix.> Making these types portable available helps that.> For example -- Uin.m3 need not be duplicated at all.> But then it either must use the presently more portable unsigned_short and unsigned,> or uint16_t and uint32_t should be made always available, either by adding them> to all the various Utypes.i3, or the one Ctypes.i3, or a new place.> > > Darwin currently has four Upthread.i3 files (one is dead), but needs either only two, or one> with the sizes abstracted out. I don't know if PPC64_DARWIN will needs its own yet,> I don't have one of these machines yet.> > > I would like to go ahead with this stuff *today*.> It takes some exertion of patience for me to stop and send this first. :)> > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jun 2 13:03:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 02 Jun 2008 13:03:23 +0200 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: References: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Message-ID: <20080602130323.17qngqata84ow8wc@mail.elegosoft.com> Quoting Jay : > > They are not from the C standard, nor are they necessarily from a > particular platform. > Some platforms define some of them. > But all platforms could define all of them, at least 8/16/32, and > could define them identically. > I want to add these somewhere in m3core. > They are portable enough. I wouldn't object to a new interface abstracting just some type definitions for all target platforms. If that's OK with Tony, too, you may go ahead. 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 2 13:12:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jun 2008 12:12:39 +0100 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: References: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Message-ID: Cstdint.i3 seems perfectly reasonable as per: http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html On Jun 2, 2008, at 11:34 AM, Jay wrote: > > I want to add these somewhere in m3core. > > Ok, how about this? I think we can agree to this easily. > > INTERFACE Cstdint; > > IMPORT Ctypes; > > TYPE > > int8_t = Ctypes.signed_char; > uint8_t = Ctypes.unsigned_char; > > int16_t = Ctypes.short; > uint16_t = Ctypes.unsigned_short; > > int32_t = Ctypes.int; > uint32_t = Ctypes.unsigned_int; > > int64_t = Ctypes.long_long; > uint64_t = Ctypes.unsigned_long_long; > > (* from here on out I don't care much, can be removed to avoid being > wrong *) > > intptr_t = INTEGER; > uintptr_t = CARDINAL; (* ? *) > > (* and esp. from here on out if there is any difficulty coming up > with the definitions *) > > CONST > > PTRDIFF_MIN = FIRST(intptr_t); > SIZE_MAX = LAST(uintptr_t); > > (* Should WCHAR be wchar_t, or be 16 bits always? > wchar_t is sometimes larger than 16 bits. *) > > WCHAR_MIN = FIRST(WIDECHAR); > WCHAR_MAX = LAST(WIDECHAR); > > (* The rest omitted as decreasing usefulness and possibly decreasing > portability. *) > > I would just as soon integrate all this into the language as globals > but people like to push stuff out to libraries where possible/easy. > (Some C++ libraries -- Boost -- have become very contorted because > it was possible but not easy.) > > - Jay > > > > > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: proposal/insistence for fixed size > integer types in Ctypes.i3 > Date: Mon, 2 Jun 2008 10:13:41 +0000 > > They are not from the C standard, nor are they necessarily from a > particular platform. > Some platforms define some of them. > But all platforms could define all of them, at least 8/16/32, and > could define them identically. > I want to add these somewhere in m3core. > They are portable enough. > > - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] FW: proposal/insistence for fixed size > integer types in Ctypes.i3 > Date: Mon, 2 Jun 2008 10:23:44 +0100 > > Are these types defined by the C standard. If not then they don't > belong in Ctypes. If they are only defined by their particular > platform then they do belong in Utypes. > > On Jun 1, 2008, at 3:35 AM, Jay wrote: > > So much for trying plain text to avoid truncation, darnit. > > > > > From: jayk123 at hotmail.com > > To: m3devel at elegosoft.com > > Subject: proposal/insistence for fixed size integer types in > Ctypes.i3 > > Date: Sun, 1 Jun 2008 02:32:27 +0000 > > > > > > > > Currently the various Utypes.i3 introduce various types LIKE > > > > > > uint8_t = unsigned_char; > > uint16_t = unsigned_short; > > uint32_t = unsigned_int; > > uint64_t = unsigned_long_long; > > > > > > int8_t = signed_char; > > int16_t = short; > > int32_t = int; > > int64_t = long_long; > > > > > > sometimes there is an underscore after the u. > > > > > > There is quite some variation in which, if any, of these types are > provided. > > When they are provided, they are always the same, with one > exception I will detail. > > > > > > Arguably they are provided only for defining other types and > function signatures > > within m3-libs/m3core/src/unix. > > > > > > I strongly strongly strongly propose that at least the above 8 > types go in > > Ctypes, and the definitions in Utypes removed. > > > > > > If there was more commonality in Utypes, I'd "forward" them for > compatibility, > > but there is little commonality. Code depending on these types > would have to > > be forked a lot. As I said, the types are always the same, if they > are defined, > > but they are often not defined. > > > > > > One variation I am open to is introducing a new .i3 file. > > But in general I like to colocate stuff rather than pick apart > everything > > and decide an ideal location. There are tradeoffs either way, > > though most people only see the tradeoffs in the way I do it. > > The tradeoffs the other way are having to track down module after > module, > > interface after interface, where to get stuff from, rather than > having > > a "one stop shop", or "fewer shops to stop". > > > > > > I am also willing to have u_* types and CAPITALIZED types: > > > > > > uint8_t = unsigned_char; > > uint16_t = unsigned_short; > > uint32_t = unsigned_int; > > uint64_t = unsigned_long_long; > > > > > > int8_t = signed_char; > > int16_t = short; > > int32_t = int; > > int64_t = long_long; > > > > > > u_int8_t = uint8_t; > > u_int16_t = uint16_t; > > u_int32_t = uint32_t; > > u_int64_t = uint64_t; > > > > > > UINT8 = uint8_t; > > UINT16 = uint16_t; > > UINT32 = uint32_t; > > UINT64 = uint64_t; > > > > > > INT8 = int8_t; > > INT16 = int16_t; > > INT32 = int32_t; > > INT64 = int64_t; > > > > > > All built-in Modula-3 types are capitalized, as all Modula-3 > keywords are. > > And capitalized types is a style widely used in the Windows headers. > > (Windows and Modula-3 share a common heritage -- Digital -- though > I don't know > > from where the style of capitalized types originates.) > > > > > > The names "int8", "int16" are also obvious candidates, but I feel > that some > > amount of typographical convention should be used to demark types. > > Some amount of "Hungarian", if you will. > > Obviously there are vehement opposing opinions on this. > > "Hungarian" is often too precise and precludes changing types > without > > changing names, as well as producing unpronouncable names. > > A "weak" form however seems reasonable and useful. > > > > > > These types represent a certain point of view. > > It is a common point of view, but not universal. > > > > > > There are roughly three or four perspectives here: > > > > > > 1) > > char, short, int, long are abstractly defined and all code should > live with it. > > char is at least 8 bits, and of unspecified signedness > > (limits.h defines CHAR_BIT, the number of bits in char > > for specified signedness, use signed char or unsigned char; > > I think char has actually three options for its signess -- signed, > unsigned, or "half unsigned") > > short is at least 16 bits, signed > > int is at least 16 bits, signed > > long is at least 32 bits, signed > > > > > > There are not necessarily integral types that can hold pointers. > > size_t and ptrdiff_t perhaps, but unclear. > > size_t can hold the size of anything, but I think "anything" is > "any variable" > > and not necessarily "the entire address space". > > > > > > ptrdiff_t can hold the result of subtracting pointers, but it is > only > > valid to subtract pointers that point into the same array or just > past it. > > > > > > It is common, for example, but not universal, for the "address > space" > > to be divided between "user mode" and "kernel mode", often with a > 50/50 split, > > so therefore size_t could be one bit smaller than a pointer, at > least. > > Of course that's an "unnatural" size, but theoretically possible. > > (This kernel/user 50/50 split is usually exactly how 32 bit and I > assume > > 64 bit Windows works, though 32 bit Windows can also have a 3 > gig / 1 gig split, > > and 32 bit Windows code running on 64 bit Windows kernel can get a > > full 4 gig address space.) > > > > > > As well, the representation of signed integers is left unspecified. > > The range of "int" need only go down to -32767, not necessarily > -32768. > > Signed magnitude and one's complement are valid representations. > > Overflowing a signed integer causes undefined behavior. > > Unsigned numbers do not have this abstraction. > > > > > > While this is the "most correct" view, according to (my > understanding) the C standard, > > implementations do nail down details way beyond this, and a lot of > > code depends on these details. > > > > > > While I may have some of those details slightly wrong, you get the > point. > > You CAN write code within this interface, but a lot of code > violates it, sometimes > > > > > > by accident, sometimes for important practical reasons. > > Some amount of code assumes an int is at least or exactly 32 bits. > > Some amount of code assumes int or long can hold a pointer, though > > int probably not so much, and long probably of proportionally > > rapidly decreasing instance due to Win64. > > > > > > > > 2) > > char, short, int, long are somewhat abstractly defined > > char is exactly 8 bits > > varying perspectives on its presumed signedness > > short is exactly 16 bits > > int is exactly 32 bits > > long there are few perspectives on; it is exactly 32 bits > ("Windows"), or > > it is exactly the size of a pointer ("Unix"), or it is at least > > the size of a pointer > > > > > > As well, two's complement is the only representation of signed > numbers > > in use, and code depends on this. > > > > > > (I recently read that we can thank the IBM S/360 or such, in the > 1960's, > > for introducing such modern-day architectural features that everyone > > takes for granted as an 8 bit byte and two's complement signed > numbers.) > > > > > > If you need an integer with a particular exact size, either use > char/short/int directly, > > or run them through "autoconf", or sniff "limits.h". > > > > > > 3) This is my recently acquired perspective, but it isn't new. > > > > > > Given that #1 is "correct but rare", and that #2 are > > full of "exact": > > > > > > char, short, int, long are funny names with not particularly > > useful specifications. #2 is a little sleazy (less so if > autoconfed/limits.h) > > Unless you are really adhering to the strict spec, don't use them. > > If you are in fact indexing a "small" array, they might suffice, > > but is it worth it? worth having these types? > > > > > > Theory: 16 bit machines are irrelevant and 32 bit integers > > are perfectly efficient on 64 bit machines, and 64 bit integers > > are universally available (?) and reasonably efficient (?), > > so feel free to use them if there is a need. > > > > > > As well, 4gig remains a large capacity in most contexts, so feel > > free to use explictly 32 bit integers. > > > > > > However file sizes and offsets should really always be 64 bits. > > Any code still requiring 32 bit file offsets/sizes is unfortunate. > > That includes PE32+ imho, the file format for .exes/.dlls on Win64. > > > > > > Be clear and unsleazy and adopt new names that represent well > > their specification and actual use. > > > > > > int_t is exactly n bits in size and signed > > uint_t is exactly n bits in size and unsigned > > some names are chosen for unsigned and signed integers with > > the exact size of a pointer > > For n=8,16,32 all four types exist, and probably 64. > > And pointer-sized types exist. > > > > > > If you really feel your capacity limits should scale with address > space size, or need > > to store a pointer in an integer, use size_t or uintptr_t or > intptr_t, etc. > > > > > > Modula-3's position here adds that INTEGER is the exact > > size of a pointer and signed. It is identical to ptrdiff_t > > or intptr_t. CARDINAL is the exact size but omits the bottom "half" > > of the range, and does not, I believe, extend the top "half". > > > > > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly > mechanical > > translation of /usr/include, and /usr/include does not necessarily > > take perspective #3. So the "funny" names are useful for a human > > mechanical translation. But the precise names can still be used > instead. > > > > > > Here is an exception I said I would detail: > > > > > > irix-5.2/utypes.i3: > > int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END; > > uint64_t = int64_t; > > > > > > This is different in at least two ways that I see. > > - default initialization to zero > > - 32 bit alignment instead of 64 bit alignment > > > > > > I tend to assume that the alignment is actually wrong, > > however all the uses in Usignal appear unaffected, as they are > always preceded > > by a mix of int64_t and an even number of int32. > > Either way, it is easy enough to preserve this for compatibility. > > > > > > I would like to continue, where easy and clear, to reduce the > "size" of m3-libs/m3core/src/unix. > > Making these types portable available helps that. > > For example -- Uin.m3 need not be duplicated at all. > > But then it either must use the presently more portable > unsigned_short and unsigned, > > or uint16_t and uint32_t should be made always available, either > by adding them > > to all the various Utypes.i3, or the one Ctypes.i3, or a new place. > > > > > > Darwin currently has four Upthread.i3 files (one is dead), but > needs either only two, or one > > with the sizes abstracted out. I don't know if PPC64_DARWIN will > needs its own yet, > > I don't have one of these machines yet. > > > > > > I would like to go ahead with this stuff *today*. > > It takes some exertion of patience for me to stop and send this > first. :) > > > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jun 2 23:07:22 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 2 Jun 2008 21:07:22 +0000 Subject: [M3devel] unsigned integers? Message-ID: What is the status and chance of a 32 bit integer with the range 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. 0xFFFFFFFFFFFFFFFF? Already available? Impossible to provide?Only available in unsafe modules?Only available with restricted operations in safe modules, and more operations in unsafe modules? Specifically, I think looping from 0 to N is safe -- no overflow. Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow. Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow. Adding or subtracting an INTEGER to "UNSIGNED" is not safe. Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe. Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done carefully. Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL or UNSIGNED.The unsafe operations above could be runtime checked perhaps. I guess that's a different larger point/dilemna -- when to allow potentially unsafe operations but with runtime checks vs. the compiler just disallowing them entirely. e.g. adding an integer to an integer is not even safe, but checked maybe at runtime (ok, at least assignment to subrange types is checked). Yes, I know I know, the runtime checks on at least many integer operations is yet lacking. Is there any, um, value in such a type? Is it just me blindly trying to cast Modula-3 as C (yes), but there's no actual value (uncertain)? Btw, I agree there's no point in this type in representing file sizes or offsets. They should be at least 63 bit integers. One bit doesn't buy much for file sizes. It might be something for address spaces though? It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = INTEGER. It seems quite wrong. Perhaps the unsigned types larger than 16 bits just should not be defined in Cstdint. ?? But there is already Ctypes.unsigned_int, unsigned_long_long, whose underlying type I think is signed, but which convention says you just don't do signed operations on, but which the compiler doesn't enforce, right? You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED/UINT?????? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Jun 3 02:15:23 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 02 Jun 2008 17:15:23 -0700 Subject: [M3devel] unsigned integers? In-Reply-To: Your message of "Mon, 02 Jun 2008 21:07:22 -0000." Message-ID: <200806030015.m530FNvv073806@camembert.async.caltech.edu> What is it you are looking for? 1 Operator overloading of + - * DIV for this new type? 2 Runtime checks of overflow? Or both? You can obviously get #2 by writing a tiny little library of your own? (Just like the Word interface but with overflow checks.) Does it matter whether the underlying implementation uses INTEGER or ARRAY OF BITS 8 FOR [0..255]? Doesn't a : Unsigned.T := 3; b : CARDINAL := 4; c := a - b; overflow? The Green Book is quite clear on the point that Word.T operations can never overflow, that is, all operations are "safe", using your terminology, so no, they aren't the same types. But it's rather confusing that you use a different definition of the word "safe" from that used in the Green Book. (In fact the Green Book only defines "unsafe" but I assume "safe" to mean "not unsafe", which it does, too.) Mika Jay writes: >--_a753fe8a-a24d-445a-8b9d-c524a5a0a41a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >What is the status and chance of a 32 bit integer with the range 0..0xFFFFF= >FFF and of a 64 bit integer type with range 0 .. 0xFFFFFFFFFFFFFFFF? >=20 >=20 >Already available? >Impossible to provide?Only available in unsafe modules?Only available with = >restricted operations in safe modules, and more operations in unsafe module= >s? >=20 >=20 >Specifically, I think looping from 0 to N is safe -- no overflow. >Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow. >Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow. >Adding or subtracting an INTEGER to "UNSIGNED" is not safe. >Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.Comparin= >g UNSIGNED to UNSIGNED for any of =3D, <, >, !=3D, is safe. >Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done careful= >ly. > Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL or U= >NSIGNED.The unsafe operations above could be runtime checked perhaps. > I guess that's a different larger point/dilemna -- when to allow potentia= >lly unsafe operations but with runtime checks vs. the compiler just disallo= >wing them entirely. e.g. adding an integer to an integer is not even safe, = >but checked maybe at runtime (ok, at least assignment to subrange types is = >checked). Yes, I know I know, the runtime checks on at least many integer o= >perations is yet lacking. >=20 >Is there any, um, value in such a type? >Is it just me blindly trying to cast Modula-3 as C (yes), but there's no ac= >tual value (uncertain)? >=20 >Btw, I agree there's no point in this type in representing file sizes or of= >fsets. They should be at least 63 bit integers. One bit doesn't buy much fo= >r file sizes. It might be something for address spaces though? >=20 >It bugs me to define types like uintptr_t =3D CARDINAL or uintptr_t =3D INT= >EGER. It seems quite wrong. >Perhaps the unsigned types larger than 16 bits just should not be defined i= >n Cstdint. ?? >But there is already Ctypes.unsigned_int, unsigned_long_long, whose underly= >ing type I think is signed, but which convention says you just don't do sig= >ned operations on, but which the compiler doesn't enforce, right? >=20 >You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED= >/UINT?????? >=20 > - Jay= > >--_a753fe8a-a24d-445a-8b9d-c524a5a0a41a_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >What is the status and chance of a 32 bit integer= > with the range 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. = >0xFFFFFFFFFFFFFFFF?
> 
> 
>Already available?
>Impossible to provide?
Only available in unsafe modules?
Only availab= >le with restricted operations in safe modules, and more operations in unsaf= >e modules?
> 
> 
>Specifically, I think looping from 0 to N is safe -- no overflow.
>Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow.
>Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow.
>Adding or subtracting an INTEGER to "UNSIGNED" is not safe.
>Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.
Comp= >aring UNSIGNED to UNSIGNED for any of =3D, <, >, !=3D, is safe.
>Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done careful= >ly.
>  Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any = >CARDINAL or UNSIGNED.
The unsafe operations above could be runtime check= >ed perhaps.
>  I guess that's a different larger point/dilemna -- when to allow pot= >entially unsafe operations but with runtime checks vs. the compiler just di= >sallowing them entirely. e.g. adding an integer to an integer is not even s= >afe, but checked maybe at runtime (ok, at least assignment to subrange type= >s is checked). Yes, I know I know, the runtime checks on at least many inte= >ger operations is yet lacking.
> 
>Is there any, um, value in such a type?
>Is it just me blindly trying to cast Modula-3 as C (yes), but there's no ac= >tual value (uncertain)?

> 
>Btw, I agree there's no point in this type in representing file sizes or of= >fsets. They should be at least 63 bit integers. One bit doesn't buy much fo= >r file sizes. It might be something for address spaces though?
> 
>It bugs me to define types like uintptr_t =3D CARDINAL or uintptr_t =3D INT= >EGER. It seems quite wrong.
>Perhaps the unsigned types larger than 16 bits just should not be defined i= >n Cstdint. ??
>But there is already Ctypes.unsigned_int, unsigned_long_long, whose underly= >ing type I think is signed, but which convention says you just don't do sig= >ned operations on, but which the compiler doesn't enforce, right?
> 
>You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED= >/UINT??????
> 
> - Jay
>= > >--_a753fe8a-a24d-445a-8b9d-c524a5a0a41a_-- From dabenavidesd at yahoo.es Tue Jun 3 02:25:43 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 3 Jun 2008 00:25:43 +0000 (GMT) Subject: [M3devel] unsigned integers? In-Reply-To: Message-ID: <618174.58920.qm@web27102.mail.ukl.yahoo.com> Dear Jay and developers: >What is the status and chance of a 32 bit integer with the range >0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. >0xFFFFFFFFFFFFFFFF? I guess you meant like a LONGCARD, I think it was a proposal of native 64 integer language update with recent LONGINT add,  but as I understood it was no accepted (maybe it was not  needed). Did you mean UNSIGNED like a  LONGCARD? There is a Sweden site about the comparison you want to make of C++ types and Modula-3 built-in types (as I understand you want to figure out), maybe this can give you an idea of others thoughts: http://translate.google.com.co/translate?u=http%3A%2F%2Fwww.nada.kth.se%2Fdatorer%2Fhaften%2Fmodula2c%2B%2B%2Fnode9.html&sl=sv&tl=en&hl=es&ie=UTF-8 Also you can check this opinion based on comparison with Modula-2 too: http://catless.ncl.ac.uk/Risks/18.60.html#subj7.1 Also the m3devel list from 2006. And all the others about 64 native proposal of Rodney Bates and others: http://mailarchive.elegosoft.com/Zope/m3/m3devel/archive/2006/2006-09/1157492987000/index_html?fullMode=1#1158164046000 I would vote to keep simplicity even in the mapping of C types to Modula-3 types, does exist any matrix like the translated web of the url above in the documentation of cm3 to help in the implementations of mapping types? Thanks ---2/6/08, Jay <jayk123 at hotmail.com> wrote: De: Jay <jayk123 at hotmail.com> Asunto: [M3devel] unsigned integers? Para: "m3devel at elegosoft.com" <m3devel at elegosoft.com> Fecha: lunes, 2 junio, 2008 4:07 #yiv1585025748 .hmmessage P { margin:0px;padding:0px;} #yiv1585025748 .hmmessage { FONT-SIZE:10pt;FONT-FAMILY:Tahoma;} What is the status and chance of a 32 bit integer with the range 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. 0xFFFFFFFFFFFFFFFF?     Already available? Impossible to provide? Only available in unsafe modules? Only available with restricted operations in safe modules, and more operations in unsafe modules?     Specifically, I think looping from 0 to N is safe -- no overflow. Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow. Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow. Adding or subtracting an INTEGER to "UNSIGNED" is not safe. Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow. Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe. Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done carefully.   Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL or UNSIGNED. The unsafe operations above could be runtime checked perhaps.   I guess that's a different larger point/dilemna -- when to allow potentially unsafe operations but with runtime checks vs. the compiler just disallowing them entirely. e.g. adding an integer to an integer is not even safe, but checked maybe at runtime (ok, at least assignment to subrange types is checked). Yes, I know I know, the runtime checks on at least many integer operations is yet lacking.   Is there any, um, value in such a type? Is it just me blindly trying to cast Modula-3 as C (yes), but there's no actual value (uncertain)?   Btw, I agree there's no point in this type in representing file sizes or offsets. They should be at least 63 bit integers. One bit doesn't buy much for file sizes. It might be something for address spaces though?   It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = INTEGER. It seems quite wrong. Perhaps the unsigned types larger than 16 bits just should not be defined in Cstdint. ?? But there is already Ctypes.unsigned_int, unsigned_long_long, whose underlying type I think is signed, but which convention says you just don't do signed operations on, but which the compiler doesn't enforce, right?   You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED/UINT??????    - Jay ______________________________________________ Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Tue Jun 3 04:43:20 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 02 Jun 2008 21:43:20 -0500 Subject: [M3devel] unsigned integers? In-Reply-To: References: Message-ID: <4844AFC8.5060004@wichita.edu> It's already available, but takes a bit of care. Modula-2 had an INTEGER and a CARDINAL, the latter unsigned and having full unsigned range for its word size. I think it was not fully defined in the original language report. It turned out a semantic nightmare. It was a nightmare to code too. Been there, done that. Modula-3's CARDINAL, as I'm sure everybody knows is just the positive half range of INTEGER and behaves just like a subrange of INTEGER. This solves a lot of problems, at the cost of taking away half the unsigned range. For full-range unsigned, you use the type INTEGER, but use the operations in interface Word. It's the same type, but different interpretations applied to the same bit pattern. It would be a good practice to declare things as INTEGER when they are signed and Word.T when unsigned, but there is nothing in the language to require it. In the case of addition and subtraction, builtin operators "+" and "-" will produce the same results as Word.Plus and Word.Minus, respectively, except that the conditions under which overflow is detected will differ. Not that that matters much, as, AFAIK, none of the implementations detect integer overflows anyway. So use INTEGER and the unary and binary operators if you want it to be signed, and use Word.T and Word. if you want it unsigned. Of course, you are free to assign between a variable that is being treated as signed and one treated as unsigned any time, without any overflow checks, unless you program them yourself. This certainly violates the intuition about what safety means. However, on closer look, it is not at all the same degree of unsafety as, say, arrays going out of bounds. My definition of safe is that nothing can happen that cannot be explained using only the concepts of the language. For example, to understand what an array bounds error actually does, you would need to know that an array actually shares memory with other variables, code, etc., and then a huge amount about how the compiler, linker, loader, heap allocator, etc. lay things out, along with what is declared in all the code, including libraries you are not working on. None of this is part of a so-called high-level language. The INTEGER/Word.T thing can be explained knowing about binary twos-complement representation, which is definitely a machine-level concept. The Word interface defines the unsigned side of it as a language concept too, but only hints at the signed representation. But most importantly, neither the operators nor the functions in Word.T ever produce any values that are not meaningful in the value set of the type. There is no really good linguistic solution to this problem, but I think Modula-3's is definitely the least painful I have seen. Jay wrote: > What is the status and chance of a 32 bit integer with the range > 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. > 0xFFFFFFFFFFFFFFFF? > > > Already available? > Impossible to provide? > Only available in unsafe modules? > Only available with restricted operations in safe modules, and more > operations in unsafe modules? > > > Specifically, I think looping from 0 to N is safe -- no overflow. > Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow. > Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow. > Adding or subtracting an INTEGER to "UNSIGNED" is not safe. > Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow. > Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe. > Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done > carefully. > Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL > or UNSIGNED. > The unsafe operations above could be runtime checked perhaps. > I guess that's a different larger point/dilemna -- when to allow > potentially unsafe operations but with runtime checks vs. the compiler > just disallowing them entirely. e.g. adding an integer to an integer is > not even safe, but checked maybe at runtime (ok, at least assignment to > subrange types is checked). Yes, I know I know, the runtime checks on at > least many integer operations is yet lacking. > > Is there any, um, value in such a type? > Is it just me blindly trying to cast Modula-3 as C (yes), but there's no > actual value (uncertain)? > > > Btw, I agree there's no point in this type in representing file sizes or > offsets. They should be at least 63 bit integers. One bit doesn't buy > much for file sizes. It might be something for address spaces though? > > It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = > INTEGER. It seems quite wrong. > Perhaps the unsigned types larger than 16 bits just should not be > defined in Cstdint. ?? > But there is already Ctypes.unsigned_int, unsigned_long_long, whose > underlying type I think is signed, but which convention says you just > don't do signed operations on, but which the compiler doesn't enforce, > right? > > You know, maybe Word.T should not be INTEGER but this mythological > UNSIGNED/UINT?????? > > - Jay -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jayk123 at hotmail.com Tue Jun 3 05:10:40 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 3 Jun 2008 03:10:40 +0000 Subject: [M3devel] unsigned integers? In-Reply-To: <4844AFC8.5060004@wichita.edu> References: <4844AFC8.5060004@wichita.edu> Message-ID: Very interesting. The suggestion of one of the links is that the extra range of a full unsigned type isn't particularly needed, once you have 31 bits instead of only 15. Now, in C, it is common to do a manual range check, and having unsigned cuts that check in half, makes it easier to get correct. However Modula-3 does that checking for you, taking away more of the point of the full unsigned type. So I guess there's just no need. It might be nice to make Word.T != INTEGER though. ? Gotta run. - Jay> Date: Mon, 2 Jun 2008 21:43:20 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] unsigned integers?> > It's already available, but takes a bit of care.> > Modula-2 had an INTEGER and a CARDINAL, the latter unsigned and having> full unsigned range for its word size. I think it was not fully> defined in the original language report. It turned out a semantic> nightmare. It was a nightmare to code too. Been there, done that.> > Modula-3's CARDINAL, as I'm sure everybody knows is just the positive> half range of INTEGER and behaves just like a subrange of INTEGER.> This solves a lot of problems, at the cost of taking away half the> unsigned range.> > For full-range unsigned, you use the type INTEGER, but use the> operations in interface Word. It's the same type, but different> interpretations applied to the same bit pattern. It would be a> good practice to declare things as INTEGER when they are signed> and Word.T when unsigned, but there is nothing in the language to> require it.> > In the case of addition and subtraction, builtin operators "+" and> "-" will produce the same results as Word.Plus and Word.Minus,> respectively, except that the conditions under which overflow is> detected will differ. Not that that matters much, as, AFAIK, none> of the implementations detect integer overflows anyway.> > So use INTEGER and the unary and binary operators if you want it to> be signed, and use Word.T and Word. if you want it unsigned.> > Of course, you are free to assign between a variable that is being> treated as signed and one treated as unsigned any time, without any> overflow checks, unless you program them yourself. This certainly> violates the intuition about what safety means. However, on closer> look, it is not at all the same degree of unsafety as, say, arrays> going out of bounds.> > My definition of safe is that nothing can happen that cannot be> explained using only the concepts of the language. For example,> to understand what an array bounds error actually does, you would> need to know that an array actually shares memory with other variables,> code, etc., and then a huge amount about how the compiler, linker,> loader, heap allocator, etc. lay things out, along with what is> declared in all the code, including libraries you are not working on.> None of this is part of a so-called high-level language.> > The INTEGER/Word.T thing can be explained knowing about binary> twos-complement representation, which is definitely a machine-level> concept. The Word interface defines the unsigned side of it as> a language concept too, but only hints at the signed representation.> But most importantly, neither the operators nor the functions in> Word.T ever produce any values that are not meaningful in the value> set of the type.> > There is no really good linguistic solution to this problem, but> I think Modula-3's is definitely the least painful I have seen.> > > Jay wrote:> > What is the status and chance of a 32 bit integer with the range > > 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. > > 0xFFFFFFFFFFFFFFFF?> > > > > > Already available?> > Impossible to provide?> > Only available in unsafe modules?> > Only available with restricted operations in safe modules, and more > > operations in unsafe modules?> > > > > > Specifically, I think looping from 0 to N is safe -- no overflow.> > Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow.> > Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow.> > Adding or subtracting an INTEGER to "UNSIGNED" is not safe.> > Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.> > Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe.> > Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done > > carefully.> > Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL > > or UNSIGNED.> > The unsafe operations above could be runtime checked perhaps.> > I guess that's a different larger point/dilemna -- when to allow > > potentially unsafe operations but with runtime checks vs. the compiler > > just disallowing them entirely. e.g. adding an integer to an integer is > > not even safe, but checked maybe at runtime (ok, at least assignment to > > subrange types is checked). Yes, I know I know, the runtime checks on at > > least many integer operations is yet lacking.> > > > Is there any, um, value in such a type?> > Is it just me blindly trying to cast Modula-3 as C (yes), but there's no > > actual value (uncertain)?> > > > > > Btw, I agree there's no point in this type in representing file sizes or > > offsets. They should be at least 63 bit integers. One bit doesn't buy > > much for file sizes. It might be something for address spaces though?> > > > It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = > > INTEGER. It seems quite wrong.> > Perhaps the unsigned types larger than 16 bits just should not be > > defined in Cstdint. ??> > But there is already Ctypes.unsigned_int, unsigned_long_long, whose > > underlying type I think is signed, but which convention says you just > > don't do signed operations on, but which the compiler doesn't enforce, > > right?> > > > You know, maybe Word.T should not be INTEGER but this mythological > > UNSIGNED/UINT??????> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jun 3 11:34:46 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 3 Jun 2008 09:34:46 +0000 Subject: [M3devel] unaligned record fields? Message-ID: I have on my machine like: m3core/src/win32 UINT8 = BITS 8 FOR ... UINT16 = BITS 16 FOR ... UINT32 = BITS 32 FOR ...(actually via an edited Cstdint). This is turning up, as I understand, two sets of problems, one "invented" and easy to fix, one "preexisting" and I don't know how to solve. "Problem" 1: structs that require inserting padding to be aligned: FOO = RECORD a: UINT16; b: UINT32; END; => Could not find a legal alignment... Fixed with: FOO = RECORD a: UINT16; >> padding: UINT16; b: UINT32; END; I think this a good thing, however it definitely might break some code out there -- that is, the problem where I make a breaking change, rebuild all of cm3, fix things up, but that isn't all the Modula-3 code in the world. Really, this is a good thing. I TEND to think that quiet insertion of padding for alignment is a bad thing, but that it should also by default be an error to declare unaligned fields. Granted, if you are going to share binary files between architectures, you might be forced to quash the error and allow unaligned fields. Really, I'm not sure what the answer is, but I don't think the current way of doing things, in the broader C/C++ world, is correct. It causes too many headaches to be correct. I suspend judgement about Modula-3 out of ignorance. At least I found a way, accidentally, for it trigger errors for things I don't like, but I haven't found a way to let through things that while dubious, are meant to be asis (see problem #2). Problem 1b: One record was missing a field! Add that back and the warning goes away. Nice to catch that. Problem 2: types that are not "internally" naturally aligned There are at least of these. The ??? stuff is not my introducing. (*??? #pragma pack(2) *) PBITMAPFILEHEADER = UNTRACED REF BITMAPFILEHEADER; LPBITMAPFILEHEADER = UNTRACED REF BITMAPFILEHEADER; BITMAPFILEHEADER = BITS (16_E * 8) FOR RECORD bfType : UINT16; bfSize : UINT32; (* this is not aligned *) bfReserved1: UINT16; bfReserved2: UINT16; bfOffBits : UINT32; (* nor is this *) END; (*??? #pragma pack() *) (*??? #pragma pack(2) *) PMETAHEADER = UNTRACED REF METAHEADER; LPMETAHEADER = UNTRACED REF METAHEADER; METAHEADER = RECORD mtType : UINT16; mtHeaderSize : UINT16; mtVersion : UINT16; mtSize : UINT32; (* This is not aligned. *) mtNoObjects : UINT16; mtMaxRecord : UINT32; (This is ok. *) mtNoParameters: UINT16; END; (*??? #pragma pack() *) I assume/fear that Modula-3 was not previously laying these types out correctly. NOTE that I don't see evidence of them being really used, so this isn't likely related to "bitmap problems". How does one declare these? I think the best I can do for now is change the unaligned fields to be arrays of bytes and hope nobody uses them. These two programs confirm the bug: UNSAFE MODULE A EXPORTS Main; IMPORT WinGDI;IMPORT IO; VARa: WinGDI.BITMAPFILEHEADER;b: WinGDI.METAHEADER; PROCEDURE F1(a,b: ADDRESS) =BEGIN IO.PutInt(b - a); IO.Put("\n");END F1; BEGIN F1(ADR(a), ADR(a.bfSize)); F1(ADR(b), ADR(b.mtSize)); END A. This prints 4 and 8. vs. #include #include ACCEL a;IMAGE_DOS_HEADER b;TOKEN_STATISTICS c;SE_IMPERSONATION_STATE d;COMSTAT e;BITMAPFILEHEADER f;METAHEADER g;FORMAT_PARAMETERS h;FORMAT_EX_PARAMETERS i;DISK_GEOMETRY j; int main(){ return 0;} look at it in a debugger, should be 2 and 6: 0:000> ?? fstruct tagBITMAPFILEHEADER +0x000 bfType : 0 +0x002 bfSize : 0 +0x006 bfReserved1 : 0 +0x008 bfReserved2 : 0 +0x00a bfOffBits : 00:000> ?? gstruct tagMETAHEADER +0x000 mtType : 0 +0x002 mtHeaderSize : 0 +0x004 mtVersion : 0 +0x006 mtSize : 0 +0x00a mtNoObjects : 0 +0x00c mtMaxRecord : 0 +0x010 mtNoParameters : 0 Btw, regarding struct stat, I did write Modula-3 code to form a string that represents all the sizes/offsets of the fields. We could write little tests that does that, and similar C code, and then compares the strings for equality. And/or invest a little more in C code that prints out correct Modula .i3 files, driven by a bunch of data with sizeof and offsetof, including sorting by offsetof, and checking for padding by adding offsetof+sizeof. It kind of looks like "lazyalign" is the answer, but I know this was brought up as "broken" recently, but that "Darwin (MacOSX)" needs it. I didn't follow the discusion closely. Lazyalign maybe is exactly the thing, as long as it is applicable on a type-by-type or field-by-field basis. There are some <* UNALIGNED *> and <* PRAGMA UNALIGNED *> but I see no implementation of these. I think they are being silently ignored. ?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jun 3 11:36:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 3 Jun 2008 09:36:25 +0000 Subject: [M3devel] FW: unsigned integers? In-Reply-To: <4844AFC8.5060004@wichita.edu> References: <4844AFC8.5060004@wichita.edu> Message-ID: truncated yet again, albeit slightly.. From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; m3devel at elegosoft.comSubject: RE: [M3devel] unsigned integers?Date: Tue, 3 Jun 2008 03:10:40 +0000 Very interesting.The suggestion of one of the links is that the extra range of a full unsigned type isn't particularly needed, once you have 31 bits instead of only 15.Now, in C, it is common to do a manual range check, and having unsigned cuts that check in half, makes it easier to get correct -- no need to remember to check for >=0, but also easy to do that..However Modula-3 does that checking for you, taking away more of the point of the full unsigned type.So I guess there's just no need.It might be nice to make Word.T != INTEGER though. ?Gotta run. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 5 13:30:40 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 5 Jun 2008 11:30:40 +0000 Subject: [M3devel] modula-3 uniq.exe? Message-ID: The Modula-3 tree has a simple little uniq.exe. It's like 10 lines, looks reasonable. I haven't debugged it, but when I have \cm3\bin and therefore \cm3\bin\uniq.exe early in %PATH%, building in m3-sys/m3cc hangs. I have seen this twice recently, so it wasn't a one time fluke. Both times I control-c, delete \cm3\bin\uniq.exe, rmdir /q/s NT386 (cross builds of m3cc use a two part output directory), cm3 again, and problem solved. I know it's good to build everything possible, make it sure it all builds and all that, but the code is pretty trivial and uninteresting. How about we remove it from the "std" group? (I'm still not using pkginfo.txt myself, hypocrisy, but let's assume I am; pylib.py has its own list currently.) Or in its m3makefile put like if not equal(target, "nt386") around it all I know I know, I'm lazy, it should be debugged and fixed properly, but it just doesn't seem all that worthwhile. And I also don't to have to keep deleting it. Cloning varous utilities in Modula-3 is a great exercise in using/testing/learning Modula-3, but maybe they shouldn't be identically named or installed or alway installed? Granted, installing them is a great way to test them... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jun 5 14:36:44 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 05 Jun 2008 14:36:44 +0200 Subject: [M3devel] modula-3 uniq.exe? In-Reply-To: References: Message-ID: <20080605143644.n8a7b6az484400ww@mail.elegosoft.com> Quoting Jay : > > The Modula-3 tree has a simple little uniq.exe. It's like 10 lines, > looks reasonable. > I haven't debugged it, but when I have \cm3\bin and therefore > \cm3\bin\uniq.exe early in %PATH%, building in m3-sys/m3cc hangs. I > have seen this twice recently, so it wasn't a one time fluke. Both > times I control-c, delete \cm3\bin\uniq.exe, rmdir /q/s > NT386 (cross builds of m3cc use a two part output > directory), cm3 again, and problem solved. > > I know it's good to build everything possible, make it sure it all > builds and all that, but the code is pretty trivial and uninteresting. > > How about we remove it from the "std" group? > > (I'm still not using pkginfo.txt myself, hypocrisy, but let's assume > I am; pylib.py has its own list currently.) > > Or in its m3makefile put like if not equal(target, "nt386") around it all > I know I know, I'm lazy, it should be debugged and fixed properly, > but it just doesn't seem all that worthwhile. And I also don't to > have to keep deleting it. I think the only point of this program was to make uniq available on Win32, but I don't remember that is has ever been used outside Critical Mass Inc. Thus exluding it on NT386 wouldn't make much sense in my opinion. I've got no problem to remove it from std, as long as we don't really need it somewhere. And I don't really understand why your builds hang; perhaps this would be worth investigating? Olaf > Cloning varous utilities in Modula-3 is a great exercise in > using/testing/learning Modula-3, but maybe they shouldn't be > identically named or installed or alway installed? Granted, > installing them is a great way to test them... > > - 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 jayk123 at hotmail.com Thu Jun 5 20:46:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 5 Jun 2008 18:46:22 +0000 Subject: [M3devel] floats in IL Message-ID: Tony, the way floats/doubles are read/used by parse.c is definitely wrong. Gcc wants an array of longs. At the very least, the current code hits alignment faults on OpenBSD/sparc64. 32 bit architectures would be ok, as would AMD64. As well, gcc wants 32 bits per long -- even if the longs are larger than that. So even on AMD64 it is probably reading garbage. So how about something like this: static treescan_float (unsigned *fkind){ unsigned long i = get_int (); long n_bytes; long longs[(sizeof(long double) + sizeof(long) - 1) / sizeof(long)] = { 0 }; tree tipe; REAL_VALUE_TYPE val; *fkind = i; switch (i) { case 0: tipe = t_reel; n_bytes = REEL_BYTES; break; case 1: tipe = t_lreel; n_bytes = LREEL_BYTES; break; case 2: tipe = t_xreel; n_bytes = XREEL_BYTES; break; default: fatal_error(" *** invalid floating point value, precision = 0x%lx, at m3cg_lineno %d", i, m3cg_lineno); } /* read the value's bytes; each long holds 32 bits */ for (i = 0; i < n_bytes; i++) { longs[i / 4] |= ((0xFF & get_int ()) << ((i % 4) * 8)); } /* finally, assemble a floating point value */ if (tipe == t_reel) { real_from_target_fmt (&val, longs, &ieee_single_format); } else { real_from_target_fmt (&val, longs, &ieee_double_format); } return build_real (tipe, val);}I'd also feel better if get_int returned an unsigned type but don't have enough evidence there yet to change it. And this looks suspicous: #define INTEGER(x) long x = get_int()#define UNUSED_INTEGER(x) int x ATTRIBUTE_UNUSED = get_int()static longget_int (void){ long i, n_bytes, sign, val, shift; i = (long) get_byte (); switch (i) { case M3CG_Int1: return (long) get_byte (); case M3CG_NInt1: return - (long) get_byte (); case M3CG_Int2: n_bytes = 2; sign = 1; break; case M3CG_NInt2: n_bytes = 2; sign = -1; break; case M3CG_Int4: n_bytes = 4; sign = 1; break; case M3CG_NInt4: n_bytes = 4; sign = -1; break; case M3CG_Int8: n_bytes = 8; sign = 1; break; case M3CG_NInt8: n_bytes = 8; sign = -1; break; default: return i; } for (val = 0, shift = 0; n_bytes > 0; n_bytes--, shift += 8) { val = val | (((long) get_byte ()) << shift); } return sign * val;} 8 bytes in a long? I think it needs to be a high and low host wide int, or at least a host wide int and assume that is 64 bits. But I haven't debugged this either, just went groveling for "long". Oh, scan_target_int looks better. Probably get_int is guaranteeably only up to 32 bits and the "8" cases should fail an assertion?or get_int is guaranteed to fit in a host long, so should only assert on the 8 cases if a long is smaller than 8 bytes? It appears that cm3 and cm3cg must be on the same host, that the IL format is not "portable". Because of the endianness of the float/double constants. But I'm not 100% sure. If you don't have time to look at, fix, test this, I will. Just that, you know, I can be both lazy and respectful at the same time. :) Thank, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jun 5 21:05:20 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 5 Jun 2008 20:05:20 +0100 Subject: [M3devel] floats in IL In-Reply-To: References: Message-ID: Indeed there may be problems with those fragments since there were some changes needed there in porting forward into newer versions of gcc. Feel free to fix as needs be. That code has provenance from well before me so no feelings of mine will get hurt. Go for it. On Jun 5, 2008, at 7:46 PM, Jay wrote: > Tony, the way floats/doubles are read/used by parse.c is definitely > wrong. > Gcc wants an array of longs. > At the very least, the current code hits alignment faults on OpenBSD/ > sparc64. > 32 bit architectures would be ok, as would AMD64. > > As well, gcc wants 32 bits per long -- even if the longs are larger > than that. > So even on AMD64 it is probably reading garbage. > > So how about something like this: > > static tree > scan_float (unsigned *fkind) > { > unsigned long i = get_int (); > long n_bytes; > long longs[(sizeof(long double) + sizeof(long) - 1) / > sizeof(long)] = { 0 }; > tree tipe; > REAL_VALUE_TYPE val; > > *fkind = i; > switch (i) { > case 0: tipe = t_reel; n_bytes = REEL_BYTES; break; > case 1: tipe = t_lreel; n_bytes = LREEL_BYTES; break; > case 2: tipe = t_xreel; n_bytes = XREEL_BYTES; break; > default: > fatal_error(" *** invalid floating point value, precision = 0x > %lx, at m3cg_lineno %d", > i, m3cg_lineno); > } > > /* read the value's bytes; each long holds 32 bits */ > for (i = 0; i < n_bytes; i++) > { > longs[i / 4] |= ((0xFF & get_int ()) << ((i % 4) * 8)); > } > > /* finally, assemble a floating point value */ > if (tipe == t_reel) { > real_from_target_fmt (&val, longs, &ieee_single_format); > } else { > real_from_target_fmt (&val, longs, &ieee_double_format); > } > return build_real (tipe, val); > } > > I'd also feel better if get_int returned an unsigned type but don't > have enough evidence there yet to change it. > > And this looks suspicous: > > #define INTEGER(x) long x = get_int() > #define UNUSED_INTEGER(x) int x ATTRIBUTE_UNUSED = get_int() > static long > get_int (void) > { > long i, n_bytes, sign, val, shift; > i = (long) get_byte (); > switch (i) { > case M3CG_Int1: return (long) get_byte (); > case M3CG_NInt1: return - (long) get_byte (); > case M3CG_Int2: n_bytes = 2; sign = 1; break; > case M3CG_NInt2: n_bytes = 2; sign = -1; break; > case M3CG_Int4: n_bytes = 4; sign = 1; break; > case M3CG_NInt4: n_bytes = 4; sign = -1; break; > case M3CG_Int8: n_bytes = 8; sign = 1; break; > case M3CG_NInt8: n_bytes = 8; sign = -1; break; > default: return i; > } > for (val = 0, shift = 0; n_bytes > 0; n_bytes--, shift += 8) { > val = val | (((long) get_byte ()) << shift); > } > return sign * val; > } > > > 8 bytes in a long? > I think it needs to be a high and low host wide int, or at least a > host wide int and assume that is 64 bits. > But I haven't debugged this either, just went groveling for "long". > Oh, scan_target_int looks better. > Probably get_int is guaranteeably only up to 32 bits and the "8" > cases should fail an assertion? > or get_int is guaranteed to fit in a host long, so should only > assert on the 8 cases if a long is smaller than 8 bytes? > > It appears that cm3 and cm3cg must be on the same host, that the IL > format is not "portable". > Because of the endianness of the float/double constants. > But I'm not 100% sure. > > If you don't have time to look at, fix, test this, I will. > Just that, you know, I can be both lazy and respectful at the same > time. :) > > Thank, > - Jay From rodney.bates at wichita.edu Sat Jun 7 18:23:27 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 07 Jun 2008 11:23:27 -0500 Subject: [M3devel] windowsResoures not found Message-ID: <484AB5FF.2080307@wichita.edu> I just tried some building on a new computer, using current cvs updates, as of 2008-6-6. scripts/do-cm3-all.sh build fails with: package windowsResources not found *** cannot find package windowsResources / However, ls -ld m3-sys/windowsResources gives: drwxr-xr-x 4 rodney rodney 4096 2008-06-05 19:07 m3-sys/windowsResources so the files are there. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jayk123 at hotmail.com Sun Jun 8 00:22:49 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 7 Jun 2008 22:22:49 +0000 Subject: [M3devel] windowsResoures not found In-Reply-To: <484AB5FF.2080307@wichita.edu> References: <484AB5FF.2080307@wichita.edu> Message-ID: Try scripts/python instead? - Jay> Date: Sat, 7 Jun 2008 11:23:27 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: [M3devel] windowsResoures not found> > I just tried some building on a new computer, using current cvs updates,> as of 2008-6-6. scripts/do-cm3-all.sh build fails with:> > package windowsResources not found> *** cannot find package windowsResources /> > However, ls -ld m3-sys/windowsResources gives:> > drwxr-xr-x 4 rodney rodney 4096 2008-06-05 19:07 m3-sys/windowsResources> > so the files are there.> > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jun 8 16:39:18 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 8 Jun 2008 15:39:18 +0100 Subject: [M3devel] windowsResoures not found In-Reply-To: References: <484AB5FF.2080307@wichita.edu> Message-ID: <2CFDBEDE-4A3D-45CB-B7C0-A16B09E9745B@cs.purdue.edu> We need to make sure that the standard build scripts work the same on all platforms. It is not acceptable that we forgo the elegant platform independent uniformity of Modula-3 installation procedures. On Jun 7, 2008, at 11:22 PM, Jay wrote: > Try scripts/python instead? > > - Jay > > > > > > Date: Sat, 7 Jun 2008 11:23:27 -0500 > > From: rodney.bates at wichita.edu > > To: m3devel at elegosoft.com > > Subject: [M3devel] windowsResoures not found > > > > I just tried some building on a new computer, using current cvs > updates, > > as of 2008-6-6. scripts/do-cm3-all.sh build fails with: > > > > package windowsResources not found > > *** cannot find package windowsResources / > > > > However, ls -ld m3-sys/windowsResources gives: > > > > drwxr-xr-x 4 rodney rodney 4096 2008-06-05 19:07 m3-sys/ > windowsResources > > > > so the files are there. > > > > > > > > -- > > ------------------------------------------------------------- > > Rodney M. Bates, retired assistant professor > > Dept. of Computer Science, Wichita State University > > Wichita, KS 67260-0083 > > 316-978-3922 > > rodney.bates at wichita.edu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jun 8 20:40:26 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 8 Jun 2008 18:40:26 +0000 Subject: [M3devel] windowsResoures not found In-Reply-To: <2CFDBEDE-4A3D-45CB-B7C0-A16B09E9745B@cs.purdue.edu> References: <484AB5FF.2080307@wichita.edu> <2CFDBEDE-4A3D-45CB-B7C0-A16B09E9745B@cs.purdue.edu> Message-ID: I use one elegant set of build scripts and installation procedures for all platforms. Sh is platform independent and elegant and Python is not? Rodney delete scripts/PKGS and let it get regenerated. I hope to shortly fix it so PKGS never needs to be regenerated. Either a) we should just check it in, pruned down to the small required contents like Randy's cmd stuff or b) I have Solaris up and running so can test out "platform independent" Sh changes, and then the version can be appended to the filename and rm PKGS* before regenerating. - Jay CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] windowsResoures not foundDate: Sun, 8 Jun 2008 15:39:18 +0100 We need to make sure that the standard build scripts work the same on all platforms. It is not acceptable that we forgo the elegant platform independent uniformity of Modula-3 installation procedures. On Jun 7, 2008, at 11:22 PM, Jay wrote: Try scripts/python instead? - Jay> Date: Sat, 7 Jun 2008 11:23:27 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: [M3devel] windowsResoures not found> > I just tried some building on a new computer, using current cvs updates,> as of 2008-6-6. scripts/do-cm3-all.sh build fails with:> > package windowsResources not found> *** cannot find package windowsResources /> > However, ls -ld m3-sys/windowsResources gives:> > drwxr-xr-x 4 rodney rodney 4096 2008-06-05 19:07 m3-sys/windowsResources> > so the files are there.> > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jun 9 15:20:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Jun 2008 15:20:59 +0200 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST Message-ID: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> One more test failure compared to yestereday's run: p211. Anybody knows the reason for this? Olaf ----- Forwarded message from wagner at luthien.in-berlin.de ----- Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST) From: Olaf Wagner Reply-To: Olaf Wagner Subject: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST To: wagner at luthien.iceflower.in-berlin.de Cc: wagner at elego.de === 2008-06-09 01:30:38 checkout cm3 to /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK checkout 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP === 2008-06-09 01:38:52 checkout cm3 done === 2008-06-09 01:38:52 build cm3 core in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK build_lastok_core 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK build_lastok_core_lastok 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 /home/wagner/work/cm3-inst/luthien/last-ok === 2008-06-09 01:53:43 cm3 release build done === 2008-06-09 01:53:43 build cm3 core in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last release /home/wagner/work/cm3-inst/luthien/rel-5.4.0 >>> OK build_rel_upgrade 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK build_rel_core 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK build_rel_core_lastok 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 /home/wagner/work/cm3-inst/luthien/last-ok === 2008-06-09 02:15:19 cm3 release build done === 2008-06-09 02:15:19 build cm3 bindist snapshot in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 === 2008-06-09 02:18:44 cm3 snapshot build done === 2008-06-09 02:18:44 build cm3 std in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK build_std_std 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK build_std_std_lastok 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 /home/wagner/work/cm3-inst/luthien/last-ok === 2008-06-09 02:32:35 cm3 release build done === 2008-06-09 02:32:35 run cm3 compiler and runtime regression test suite in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> test_m3tests error extract: >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 p211 r001 e020 e026 e029 >>> 13 in test_m3tests 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 === 2008-06-09 02:34:35 cm3 m3tests run done === 2008-06-09 02:34:35 build all packages and generate report in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 === 2008-06-09 02:37:16 cm3 package status run done === 2008-06-09 02:37:16 build HTML package doc in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK test_m3tohtml 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 === 2008-06-09 02:38:53 m3tohtml run done ----- End forwarded message ----- -- 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 jayk123 at hotmail.com Mon Jun 9 19:48:03 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 9 Jun 2008 17:48:03 +0000 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> Message-ID: This is a new test that I just added and it should work.Do you have any details on the failure?The output? I thought I tested on both NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have to double check though.(Testing on NT386 is less relevant.) In particular, there was a bug here on new/inactiveplatforms and I wanted a test to verify my fix.The bug caused some platforms to bus/alignment error in cm3cg. I will have to double check both that I updated my cm3cg and ran the test. My internet connection is extremely slow lately and thisis hampering me. I have to call tech support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST> > One more test failure compared to yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > ----- Forwarded message from wagner at luthien.in-berlin.de -----> Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > Reply-To: Olaf Wagner > Subject: CM3 regression test from luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > === 2008-06-09 01:30:38 checkout cm3 to > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK checkout 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_lastok_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK build_rel_upgrade 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 build cm3 std in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_std_std 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_std_std_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and runtime regression test > suite in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok version> >>> test_m3tests error extract:> >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> 13 in test_m3tests 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all packages and generate report in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build HTML package doc in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > -- > 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 jayk123 at hotmail.com Mon Jun 9 20:10:37 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 9 Jun 2008 18:10:37 +0000 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> Message-ID: Both NT386GNU and PPC_DARWIN look good to me. I'm double checking something on PPC_DARWIN but expect it'll still look good. If the program builds, please send me the output. also cm3 -keep and the A.mc file. I'll go and check the tinderbox now..if my internet holds up.. Thanks, - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Mon, 9 Jun 2008 17:48:03 +0000Subject: Re: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 This is a new test that I just added and it should work.Do you have any details on the failure?The output?I thought I tested on both NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have to double check though.(Testing on NT386 is less relevant.) In particular, there was a bug here on new/inactiveplatforms and I wanted a test to verify my fix.The bug caused some platforms to bus/alignment error in cm3cg. I will have to double check both that I updated my cm3cg and ran the test.My internet connection is extremely slow lately and thisis hampering me. I have to call tech support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST> > One more test failure compared to yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > ----- Forwarded message from wagner at luthien.in-berlin.de -----> Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > Reply-To: Olaf Wagner > Subject: CM3 regression test from luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > === 2008-06-09 01:30:38 checkout cm3 to > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK checkout 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_lastok_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK build_rel_upgrade 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 build cm3 std in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_std_std 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_std_std_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and runtime regression test > suite in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok version> >>> test_m3tests error extract:> >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> 13 in test_m3tests 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all packages and generate report in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build HTML package doc in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > -- > 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 jayk123 at hotmail.com Mon Jun 9 21:03:58 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 9 Jun 2008 19:03:58 +0000 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> Message-ID: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1213020039.1032 27414 --- p211 --- float and double constants work27415 cd ../src/p2/p211 && cm3 -silent -DM3TESTS >SOLgnu/stdout.build.raw 2>SOLgnu/stderr.build.raw27416 ../src/p2/p211/stdout.build is missing27417 ../src/p2/p211/stderr.build is missing27418 No differences encountered27419 No differences encountered I just need to add the stdout.build and stderr.build files? - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Mon, 9 Jun 2008 18:10:37 +0000Subject: Re: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 Both NT386GNU and PPC_DARWIN look good to me. I'm double checking something on PPC_DARWIN but expect it'll still look good.If the program builds, please send me the output.also cm3 -keep and the A.mc file. I'll go and check the tinderbox now..if my internet holds up.. Thanks, - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Mon, 9 Jun 2008 17:48:03 +0000Subject: Re: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 This is a new test that I just added and it should work.Do you have any details on the failure?The output?I thought I tested on both NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have to double check though.(Testing on NT386 is less relevant.) In particular, there was a bug here on new/inactiveplatforms and I wanted a test to verify my fix.The bug caused some platforms to bus/alignment error in cm3cg. I will have to double check both that I updated my cm3cg and ran the test.My internet connection is extremely slow lately and thisis hampering me. I have to call tech support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST> > One more test failure compared to yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > ----- Forwarded message from wagner at luthien.in-berlin.de -----> Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > Reply-To: Olaf Wagner > Subject: CM3 regression test from luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > === 2008-06-09 01:30:38 checkout cm3 to > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK checkout 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_lastok_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK build_rel_upgrade 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 build cm3 std in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_std_std 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_std_std_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and runtime regression test > suite in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok version> >>> test_m3tests error extract:> >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> 13 in test_m3tests 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all packages and generate report in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build HTML package doc in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > -- > 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 wagner at elegosoft.com Wed Jun 11 17:13:26 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 11 Jun 2008 17:13:26 +0200 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> Message-ID: <20080611171326.zaa7yv31r4oso4s4@mail.elegosoft.com> Sorry for the long delays; I don't keep up with reading all my mails currently, and haven't got time to really check what's going on in CM3. It seems that the fact that I was able to invest some significant amount of time for the regression test framework some months ago, this is no indication at all that I'll be able to keep it like this. So sorry to all who are waiting for things I should do (like a new CM3 release ):-/ Quoting Jay : > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1213020039.1032 > 27414 --- p211 --- float and double constants work27415 > cd ../src/p2/p211 && cm3 -silent -DM3TESTS > >SOLgnu/stdout.build.raw 2>SOLgnu/stderr.build.raw27416 > ../src/p2/p211/stdout.build is missing27417 > ../src/p2/p211/stderr.build is missing27418 No differences > encountered27419 No differences encountered > I just need to add the stdout.build and stderr.build files? If it's a new test and the files are missing, you probably have to add them. Why doesn't it show up for you on your test platforms? It's no big matter though. I just wondered. Olaf > - Jay > > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > m3devel at elegosoft.comDate: Mon, 9 Jun 2008 18:10:37 +0000Subject: > Re: [M3devel] Fwd: CM3 regression test from > luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 > > > Both NT386GNU and PPC_DARWIN look good to me. I'm double checking > something on PPC_DARWIN but expect it'll still look good.If the > program builds, please send me the output.also cm3 -keep and the > A.mc file. I'll go and check the tinderbox now..if my internet holds > up.. Thanks, - Jay > > > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > m3devel at elegosoft.comDate: Mon, 9 Jun 2008 17:48:03 +0000Subject: > Re: [M3devel] Fwd: CM3 regression test from > luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 > > This is a new test that I just added and it should work.Do you have > any details on the failure?The output?I thought I tested on both > NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have > to double check though.(Testing on NT386 is less relevant.) In > particular, there was a bug here on new/inactiveplatforms and I > wanted a test to verify my fix.The bug caused some platforms to > bus/alignment error in cm3cg. I will have to double check both that > I updated my cm3cg and ran the test.My internet connection is > extremely slow lately and thisis hampering me. I have to call tech > support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: > wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] > Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon > 9 Jun 2008 03:30:38 CEST> > One more test failure compared to > yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > > ----- Forwarded message from wagner at luthien.in-berlin.de -----> > Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > > Reply-To: Olaf Wagner > > Subject: CM3 regression test from > luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> > To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > > === 2008-06-09 01:30:38 checkout cm3 to > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > checkout 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === > 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build > cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > build_lastok_core_lastok 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 > cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last > release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK > build_rel_upgrade 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > build_rel_core 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > build_rel_core_lastok 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 > cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist > snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === > 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 > build cm3 std in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > version> >>> OK build_std_std 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > build_std_std_lastok 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 > cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and > runtime regression test > suite in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok > version> >>> test_m3tests error extract:> >>> failed tests: p116b > p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> > 13 in test_m3tests 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all > packages and generate report in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build > HTML package doc in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: > +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Thu Jun 12 02:44:44 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 11 Jun 2008 20:44:44 -0400 Subject: [M3devel] thread alert problem on NT386 Message-ID: <48503937.1E75.00D7.1@scires.com> I'm running across a problem on Windows XP using threads. Specifically, I am getting the following runtime error: *** *** runtime error: *** Thread client error: Alert called from non-Modula-3 thread *** file "..\src\thread\WIN32\ThreadWin32.m3", line 325 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x5dbfea4 0x5c5e5c Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbfedc 0x5c3acd Alert + 0x35 in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbff2c 0x403bb1 CloseWindow + 0x185 in ..\src\Main.m3 0x5dbff50 0x4082c3 TaskApply + 0x5b in ..\src\Utils.m3 0x5dbff88 0x5c4a6a RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbffb4 0x5c4803 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... Now, I know for a fact that the thread calling Thread.Alert is indeed a modula-3 thread. Any ideas? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 12 03:14:29 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 12 Jun 2008 01:14:29 +0000 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: <20080611171326.zaa7yv31r4oso4s4@mail.elegosoft.com> References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> <20080611171326.zaa7yv31r4oso4s4@mail.elegosoft.com> Message-ID: > add them. Why doesn't it show up for you on your test platforms? I have yet to figure out how to run the Tinderbox correctly. I need to. I tried twice without much luck. Probably should not have bothered with NT386 at the time but used Darwin or such. So I don't see the full reporting or know how it works, what it loks for. I can do cd m3-sys/m3tests; cm3 though. That is much of it and useful. I know to look for "@" for diffs, or other diffs. Maybe I should do cm3 -DHTML? I'll try that. - Jay> Date: Wed, 11 Jun 2008 17:13:26 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3> > Sorry for the long delays; I don't keep up with reading all my> mails currently, and haven't got time to really check what's> going on in CM3. It seems that the fact that I was able to invest> some significant amount of time for the regression test framework> some months ago, this is no indication at all that I'll be able> to keep it like this. So sorry to all who are waiting for things I> should do (like a new CM3 release ):-/> > Quoting Jay :> > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1213020039.1032> > 27414 --- p211 --- float and double constants work27415 > > cd ../src/p2/p211 && cm3 -silent -DM3TESTS > > >SOLgnu/stdout.build.raw 2>SOLgnu/stderr.build.raw27416 > > ../src/p2/p211/stdout.build is missing27417 > > ../src/p2/p211/stderr.build is missing27418 No differences > > encountered27419 No differences encountered> > I just need to add the stdout.build and stderr.build files?> > If it's a new test and the files are missing, you probably have to> add them. Why doesn't it show up for you on your test platforms?> It's no big matter though. I just wondered.> > Olaf> > > - Jay> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > > m3devel at elegosoft.comDate: Mon, 9 Jun 2008 18:10:37 +0000Subject: > > Re: [M3devel] Fwd: CM3 regression test from > > luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3> >> >> > Both NT386GNU and PPC_DARWIN look good to me. I'm double checking > > something on PPC_DARWIN but expect it'll still look good.If the > > program builds, please send me the output.also cm3 -keep and the > > A.mc file. I'll go and check the tinderbox now..if my internet holds > > up.. Thanks, - Jay> >> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > > m3devel at elegosoft.comDate: Mon, 9 Jun 2008 17:48:03 +0000Subject: > > Re: [M3devel] Fwd: CM3 regression test from > > luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3> >> > This is a new test that I just added and it should work.Do you have > > any details on the failure?The output?I thought I tested on both > > NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have > > to double check though.(Testing on NT386 is less relevant.) In > > particular, there was a bug here on new/inactiveplatforms and I > > wanted a test to verify my fix.The bug caused some platforms to > > bus/alignment error in cm3cg. I will have to double check both that > > I updated my cm3cg and ran the test.My internet connection is > > extremely slow lately and thisis hampering me. I have to call tech > > support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: > > wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] > > Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon > > 9 Jun 2008 03:30:38 CEST> > One more test failure compared to > > yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > > > ----- Forwarded message from wagner at luthien.in-berlin.de -----> > > Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > > > Reply-To: Olaf Wagner > > > Subject: CM3 regression test from > > luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> > > To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > > > === 2008-06-09 01:30:38 checkout cm3 to > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > checkout 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === > > 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build > > cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > build_lastok_core_lastok 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 > > cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last > > release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK > > build_rel_upgrade 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > build_rel_core 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > build_rel_core_lastok 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 > > cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist > > snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === > > 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 > > build cm3 std in > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > > version> >>> OK build_std_std 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > build_std_std_lastok 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 > > cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and > > runtime regression test > suite in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok > > version> >>> test_m3tests error extract:> >>> failed tests: p116b > > p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> > > 13 in test_m3tests 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > > 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all > > packages and generate report in > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > > version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > > 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build > > HTML package doc in > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > > version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > > 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH> > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: > > +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | > > USt-IdNr: DE163214194>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jun 12 05:35:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 12 Jun 2008 04:35:11 +0100 Subject: [M3devel] thread alert problem on NT386 In-Reply-To: <48503937.1E75.00D7.1@scires.com> References: <48503937.1E75.00D7.1@scires.com> Message-ID: <40E13342-3A8D-41BD-BA8C-4BC4A445408D@cs.purdue.edu> Jay will need to track this one. I've barely ever touched ThreadWin32. On Jun 12, 2008, at 1:44 AM, Randy Coleburn wrote: > I'm running across a problem on Windows XP using threads. > > Specifically, I am getting the following runtime error: > > *** > *** runtime error: > *** Thread client error: Alert called from non-Modula-3 thread > *** file "..\src\thread\WIN32\ThreadWin32.m3", line 325 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x5dbfea4 0x5c5e5c Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3 > 0x5dbfedc 0x5c3acd Alert + 0x35 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x5dbff2c 0x403bb1 CloseWindow + 0x185 in ..\src\Main.m3 > 0x5dbff50 0x4082c3 TaskApply + 0x5b in ..\src\Utils.m3 > 0x5dbff88 0x5c4a6a RunThread + 0x1f6 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x5dbffb4 0x5c4803 ThreadBase + 0x3a in ..\src\thread > \WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > > Now, I know for a fact that the thread calling Thread.Alert is > indeed a modula-3 thread. > > Any ideas? > > Regards, > Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 12 07:04:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 12 Jun 2008 05:04:22 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? Message-ID: SOLsun..using cm3cg..a bit of a contradiction there? What SOLsun means: Sun cc? Yes. Sun ld? I think so. Only Sun libs? I think so. But cm3cg, emits references to functions in libgcc.Currently just two trivial functions. In fact, I am tempted here to give their "spec"so someone can provide a "free" (non GPL) implementation.Since they get linked into client code. These functions provide unsigned 64 bit division and modulus.Rather than being sensibly named like _uint64div and_uint64mod, their names derive from gcc calling "int64"a "double integer" or "DI". A "single integer" or "SI" is 32 bits. The function prototypes are: unsigned long long __udivdi3 (unsigned long long x, unsigned long long y);unsigned long long __umoddi3 (unsigned long long x, unsigned long long y); Can someone provide "free" implementations?I saw GPLed versions already so I can't.I think I provide a hint though.They can each be implemented in one line of C.As long as the C compiler used - "open codes" then or - calls out to functions with a different name Even if the same name is used, there's a possible workaround using in-between functions. These functions are small enough that static linking should be viable.Currently they are exported from libm3core.so however.Make a separate lib?Currently they are in m3-libs/m3core/src/Csupport/libgcc.Maybe m3-libs/m3coremath/src? This would also be required in SOLsun, and nowhere else currently. There is another "problem" with SOLsun. FloatMode.m3 requires libsunmath.a.Ideally .so files are "fully" position independent and readonly.That is, not merely "relocatable", not merely "patchable" to runat any address, but can run at any address and all "patching" is done"specially" via something like a "RTOC" and/or "GOT" / "PLT" runtime table of contents global offset table procedute linkage table and/or position indepenent addressing modes (for references to self). Tangent: There are a surprisingly number of variables when dynamic linking. Many decisions to make as to the exact semantics. Are things "delay loaded" aka "statically loaded"? When I load m3.so that depends on m3core.so is m3core.so loaded immediately? Are all the functions that m3.so calls resolved immediately? This is a variable one can control through various linker switches. As well, for any function that m3core.so calls and implements, can either another .so, m3.so, or the executable itself, also implement and "replace" or "intercept" or "interpose" those functions? Again, the answer varies. On Windows, the answer is essentially no, not never. Unless you go to some extra length to allow for it. On Unix the answer seems to vary per system and switches. Allowing this interception often requires less efficient code. And at least in one place resulted in buggy code, that I fixed recently, I think it was on AMD64_LINUX. Going through the indirection mechanism, the PLT, trashes the static link in rcx, or something like that. And it is just unnecessary indirection in almost all cases. So, the questions become, what do people want/expect for Modula-3? And, does it vary from person to person? System to system? Windows is "never" going to allow the interposition. Allowing "interposition" also goes by the description "allow unresolved symbols in shared objects", to be resolved at load time. Unix often has one global namespace for all functions in a process. Apple has a similar thing between "one level namespaces" and "two level namespaces". In an older release, they had only one level namespace. Every dynamically imported function would be searched for in all dynamically loaded files. Usually at build time you know the name of the shared object you expect to find the function in. So you can have a "two level namespace" where function names are associated with a particular file name, and only that file is searched. Apple encourages this usage, though of course is bound somewhat by compatibility. You can perhaps still build binaries that run on 10.0, and binaries built to run on 10.0 in the first place can still run today. The need to do either of these is always diminishing but hard to deem zero. SOLsun linker has two related switches. libsunmath.a apparently is not built fully position independent. libm3core.so must link to it, and therefore does not have a fully read only text section. what to do? A few options: Go back to allowing unresolved symbols in SOLsun, enabling "interposition". Then I think libsunmath.a isn't used by .sos, just executables. I don't like this option. Binding functions to particular file names (not paths) seems right and is encouraged by Apple and about the only option on Windows. It seems good to use when available. Allow writable text section in all .so. This is what I commited. Allow writable text section in only libm3core.so. This is a better compromise than previous. Move FloatMode.m3 into a separate so... libm3coremath.so, and only let it have a writable text section. This is a better compromise in terms of amount of writable text, but also adds another .so. The fewer .sos the better, arguably. Change FloatMode.m3 somehow to not use libsunmath.a. I think the only way to do this is to make it do nothing at all, which is probably what most of the implementations do, but I'd have to check. FloatMode.m3 is generally implementable on many systems, like via _controlfp on NT386. It is also dangerous to be mucking with the floating mode -- what code in the process depends on the default and will be broken by it changing? Worse, the SPARC implementation has a comment saying it is implemented process-wide instead of per-thread. Really there are arguments either way. The "common" implementation just asserts false. DS3100, VAX, IRIX, SPARC, SUN386, implement FloatMode. NT386, *_DARWIN, *_LINUX, *_FREEBSD, SOLgnu do not. Maybe just turn it off for SOLsun too? or go through and provide it everywhere? Always per-thread if possible? Only on pthreads implementations preferably? (I'm not a fan of user threads in general, so don't wish to make them "better".) I think removing FloatMode for SOLsun is probably the way to go. See if that removes requirement on libsunmath.a. See if that then allows fully position independent and "resolved" symbols. And maybe there is an updated libsunmath.a? I just have a "random" version of Solaris 10 from eBay. I could try a newer OpenSolaris/Nevada version. Or drop SOLsun as uninteresting? (My internet is slow as I said. I finally finished downloading the "normal" gcc and can build it and try the more active SOLgnu instead.) That would at least ease figuring out the names of: I386_SOLARIS, AMD64_SOLARIS, SPARC64_SOLARIS no need to have two of these of those. :) And is SOLgnu meant to use GNU ld or not? It looks like not. SOLsun and SOLgnu config files are "the same" here. Could be GNU ld is compatible in command line usage though. (not yet -- I almost have the 64 bit hosted cm3cg bug figured out. it occurs the same on SPARC64_OPENBSD as AMD64_LINUX. Something about assignment being DImode vs. VOIDmode. Occurs in many places, including RTRuntimeError.Self, by virtue of it using TRY.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Jun 12 07:04:57 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 12 Jun 2008 01:04:57 -0400 Subject: [M3devel] thread alert problem on NT386 In-Reply-To: <40E13342-3A8D-41BD-BA8C-4BC4A445408D@cs.purdue.edu> References: <48503937.1E75.00D7.1@scires.com> <40E13342-3A8D-41BD-BA8C-4BC4A445408D@cs.purdue.edu> Message-ID: <48507633.1E75.00D7.1@scires.com> Thanks. I've solved the problem. It wound up being my fault. Regards, Randy >>> Tony Hosking 6/11/2008 11:35 PM >>> Jay will need to track this one. I've barely ever touched ThreadWin32. On Jun 12, 2008, at 1:44 AM, Randy Coleburn wrote: I'm running across a problem on Windows XP using threads. Specifically, I am getting the following runtime error: *** *** runtime error: *** Thread client error: Alert called from non-Modula-3 thread *** file "..\src\thread\WIN32\ThreadWin32.m3", line 325 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x5dbfea4 0x5c5e5c Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbfedc 0x5c3acd Alert + 0x35 in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbff2c 0x403bb1 CloseWindow + 0x185 in ..\src\Main.m3 0x5dbff50 0x4082c3 TaskApply + 0x5b in ..\src\Utils.m3 0x5dbff88 0x5c4a6a RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbffb4 0x5c4803 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... Now, I know for a fact that the thread calling Thread.Alert is indeed a modula-3 thread. Any ideas? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Jun 12 07:26:09 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 12 Jun 2008 01:26:09 -0400 Subject: [M3devel] how to obtain screen size of a FormsVBT.T Message-ID: <48507B2B.1E75.00D7.1@scires.com> Using Trestle / FormsVBT / et al, I want to be able to place a new window in the center of the screen. Trestle.Overlap() seems to be the only way I've seen where you can specify the location of the window. Now, the problem I am having is how to determine the size of a particular FormsVBT.T instance so that I can compute where it should go on the screen. It seems that before the FormsVBT.T is actually displayed on the screen that its dimensions aren't readily visible. Here is the way I am using to find out the middle of the screen: trestle := Trestle.Connect(NIL); s := Trestle.GetScreens(trestle); middle := Rect.Middle(s[0].dom); Not sure if this is the best way, but it seems to work. Now, if I have built a FormsVBT.T, say via v := NEW(FormsVBT.T).initFromRsrc(...), I then call Trestle.Attach(v, trestle); >From this point onward, all the methods I have used to try and find out the dimensions of "v" don't seem to work reliably. If I could find out the horizontal (hsize) and vertical (vsize) dimensions of "v", I could make the following calls to place "v" in the center of the screen: nw := Point.Sub(middle, Point.FromCoords(hsize DIV 2, vsize DIV 2); Trestle.Overlap(v, s[0].id, nw); Indeed, if I make an educated guess about hsize and vsize the window is placed properly. But, of course, I need to reliably determine the size of an arbitrary window at runtime. I'd appreciate any insight anyone can give. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 12 14:23:17 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 12 Jun 2008 12:23:17 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? Message-ID: My inclination on the FloatMode/libsunmath issue is to not build the SOLsun FloatMode support, and then see/hope if libsunmath isn't otherwise needed, and -z text otherwise "works" -- if the rest of the system can be built with it. The majority of all platforms and all "current" "active" platforms do not implement FloatMode. It is a negative trend, but I can go along. If that changes, then I'd reconsider. Hopefully there is a better libsunmath.a available too though, or a better way to implement this, perhaps in assembly, maybe some of those new #pragma fenv things.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?Date: Thu, 12 Jun 2008 05:04:22 +0000 SOLsun..using cm3cg..a bit of a contradiction there?What SOLsun means: Sun cc? Yes. Sun ld? I think so. Only Sun libs? I think so.But cm3cg, emits references to functions in libgcc.Currently just two trivial functions.In fact, I am tempted here to give their "spec"so someone can provide a "free" (non GPL) implementation.Since they get linked into client code.These functions provide unsigned 64 bit division and modulus.Rather than being sensibly named like _uint64div and_uint64mod, their names derive from gcc calling "int64"a "double integer" or "DI". A "single integer" or "SI" is 32 bits.The function prototypes are:unsigned long long __udivdi3 (unsigned long long x, unsigned long long y);unsigned long long __umoddi3 (unsigned long long x, unsigned long long y);Can someone provide "free" implementations?I saw GPLed versions already so I can't.I think I provide a hint though.They can each be implemented in one line of C.As long as the C compiler used - "open codes" then or - calls out to functions with a different name Even if the same name is used, there's a possible workaround using in-between functions.These functions are small enough that static linking should be viable.Currently they are exported from libm3core.so however.Make a separate lib?Currently they are in m3-libs/m3core/src/Csupport/libgcc.Maybe m3-libs/m3coremath/src?This would also be required in SOLsun, and nowhere else currently.There is another "problem" with SOLsun.FloatMode.m3 requires libsunmath.a.Ideally .so files are "fully" position independent and readonly.That is, not merely "relocatable", not merely "patchable" to runat any address, but can run at any address and all "patching" is done"specially" via something like a "RTOC" and/or "GOT" / "PLT" runtime table of contents global offset table procedute linkage table and/or position indepenent addressing modes (for references to self).Tangent: There are a surprisingly number of variables when dynamic linking. Many decisions to make as to the exact semantics. Are things "delay loaded" aka "statically loaded"? When I load m3.so that depends on m3core.so is m3core.so loaded immediately? Are all the functions that m3.so calls resolved immediately? This is a variable one can control through various linker switches. As well, for any function that m3core.so calls and implements, can either another .so, m3.so, or the executable itself, also implement and "replace" or "intercept" or "interpose" those functions? Again, the answer varies. On Windows, the answer is essentially no, not never. Unless you go to some extra length to allow for it. On Unix the answer seems to vary per system and switches. Allowing this interception often requires less efficient code. And at least in one place resulted in buggy code, that I fixed recently, I think it was on AMD64_LINUX. Going through the indirection mechanism, the PLT, trashes the static link in rcx, or something like that. And it is just unnecessary indirection in almost all cases. So, the questions become, what do people want/expect for Modula-3? And, does it vary from person to person? System to system? Windows is "never" going to allow the interposition. Allowing "interposition" also goes by the description "allow unresolved symbols in shared objects", to be resolved at load time. Unix often has one global namespace for all functions in a process. Apple has a similar thing between "one level namespaces" and "two level namespaces". In an older release, they had only one level namespace. Every dynamically imported function would be searched for in all dynamically loaded files. Usually at build time you know the name of the shared object you expect to find the function in. So you can have a "two level namespace" where function names are associated with a particular file name, and only that file is searched. Apple encourages this usage, though of course is bound somewhat by compatibility. You can perhaps still build binaries that run on 10.0, and binaries built to run on 10.0 in the first place can still run today. The need to do either of these is always diminishing but hard to deem zero. SOLsun linker has two related switches. libsunmath.a apparently is not built fully position independent. libm3core.so must link to it, and therefore does not have a fully read only text section. what to do? A few options: Go back to allowing unresolved symbols in SOLsun, enabling "interposition". Then I think libsunmath.a isn't used by .sos, just executables. I don't like this option. Binding functions to particular file names (not paths) seems right and is encouraged by Apple and about the only option on Windows. It seems good to use when available. Allow writable text section in all .so. This is what I commited. Allow writable text section in only libm3core.so. This is a better compromise than previous. Move FloatMode.m3 into a separate so... libm3coremath.so, and only let it have a writable text section. This is a better compromise in terms of amount of writable text, but also adds another .so. The fewer .sos the better, arguably. Change FloatMode.m3 somehow to not use libsunmath.a. I think the only way to do this is to make it do nothing at all, which is probably what most of the implementations do, but I'd have to check. FloatMode.m3 is generally implementable on many systems, like via _controlfp on NT386. It is also dangerous to be mucking with the floating mode -- what code in the process depends on the default and will be broken by it changing? Worse, the SPARC implementation has a comment saying it is implemented process-wide instead of per-thread. Really there are arguments either way. The "common" implementation just asserts false. DS3100, VAX, IRIX, SPARC, SUN386, implement FloatMode. NT386, *_DARWIN, *_LINUX, *_FREEBSD, SOLgnu do not. Maybe just turn it off for SOLsun too? or go through and provide it everywhere? Always per-thread if possible? Only on pthreads implementations preferably? (I'm not a fan of user threads in general, so don't wish to make them "better".) I think removing FloatMode for SOLsun is probably the way to go. See if that removes requirement on libsunmath.a. See if that then allows fully position independent and "resolved" symbols. And maybe there is an updated libsunmath.a? I just have a "random" version of Solaris 10 from eBay. I could try a newer OpenSolaris/Nevada version. Or drop SOLsun as uninteresting? (My internet is slow as I said. I finally finished downloading the "normal" gcc and can build it and try the more active SOLgnu instead.) That would at least ease figuring out the names of: I386_SOLARIS, AMD64_SOLARIS, SPARC64_SOLARIS no need to have two of these of those. :) And is SOLgnu meant to use GNU ld or not? It looks like not. SOLsun and SOLgnu config files are "the same" here. Could be GNU ld is compatible in command line usage though. (not yet -- I almost have the 64 bit hosted cm3cg bug figured out. it occurs the same on SPARC64_OPENBSD as AMD64_LINUX. Something about assignment being DImode vs. VOIDmode. Occurs in many places, including RTRuntimeError.Self, by virtue of it using TRY.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jun 12 16:51:18 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 12 Jun 2008 15:51:18 +0100 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: Message-ID: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> There's too much in your e-mail to respond to Jay, so I'll just make a simple historical observation: SOLgnu was originally intended as a Solaris target where there was no availability of Sun's cc (Sun did not bundle cc with the OS at the time -- they wanted you to buy it!). However, the rest of the Solaris toolchain has always been bundled with the OS. Thus, with gcc the easiest free option as a replacement for cc, SOLgnu meant folks could use Modula-3 without having to buy Sun's cc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jun 12 16:51:45 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 12 Jun 2008 15:51:45 +0100 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: Message-ID: <330E728C-016F-465F-9D2D-CDC53A332A70@cs.purdue.edu> I think I agree with you here. On Jun 12, 2008, at 1:23 PM, Jay wrote: > My inclination on the FloatMode/libsunmath issue is to not build the > SOLsun FloatMode support, and then see/hope if libsunmath isn't > otherwise needed, and -z text otherwise "works" -- if the rest of > the system can be built with it. > The majority of all platforms and all "current" "active" platforms > do not implement FloatMode. > It is a negative trend, but I can go along. > If that changes, then I'd reconsider. > Hopefully there is a better libsunmath.a available too though, or a > better way to implement this, perhaps in assembly, maybe some of > those new #pragma fenv things.. > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? > Date: Thu, 12 Jun 2008 05:04:22 +0000 > > SOLsun..using cm3cg.. > a bit of a contradiction there? > > What SOLsun means: > Sun cc? Yes. > Sun ld? I think so. > Only Sun libs? I think so. > > But cm3cg, emits references to functions in libgcc. > Currently just two trivial functions. > > In fact, I am tempted here to give their "spec" > so someone can provide a "free" (non GPL) implementation. > Since they get linked into client code. > > These functions provide unsigned 64 bit division and modulus. > Rather than being sensibly named like _uint64div and > _uint64mod, their names derive from gcc calling "int64" > a "double integer" or "DI". A "single integer" or "SI" is 32 bits. > > The function prototypes are: > > unsigned long long __udivdi3 (unsigned long long x, unsigned long > long y); > unsigned long long __umoddi3 (unsigned long long x, unsigned long > long y); > > Can someone provide "free" implementations? > I saw GPLed versions already so I can't. > I think I provide a hint though. > They can each be implemented in one line of C. > As long as the C compiler used > - "open codes" then > or - calls out to functions with a different name > > Even if the same name is used, there's a possible workaround using > in-between functions. > > These functions are small enough that static linking should be viable. > Currently they are exported from libm3core.so however. > Make a separate lib? > Currently they are in m3-libs/m3core/src/Csupport/libgcc. > Maybe m3-libs/m3coremath/src? > > This would also be required in SOLsun, and nowhere else currently. > > There is another "problem" with SOLsun. > FloatMode.m3 requires libsunmath.a. > Ideally .so files are "fully" position independent and readonly. > That is, not merely "relocatable", not merely "patchable" to run > at any address, but can run at any address and all "patching" is done > "specially" via something like a "RTOC" and/or "GOT" / "PLT" > runtime table of contents > global offset table > procedute linkage table > and/or position indepenent addressing modes (for references to self). > > Tangent: > There are a surprisingly number of variables when dynamic linking. > Many decisions to make as to the exact semantics. > Are things "delay loaded" aka "statically loaded"? > When I load m3.so that depends on m3core.so is > m3core.so loaded immediately? > Are all the functions that m3.so calls resolved immediately? > This is a variable one can control through various linker switches. > As well, for any function that m3core.so calls and implements, > can either another .so, m3.so, or the executable itself, also > implement and "replace" or "intercept" or "interpose" those > functions? > Again, the answer varies. > On Windows, the answer is essentially no, not never. Unless you go > to > some extra length to allow for it. > On Unix the answer seems to vary per system and switches. > Allowing this interception often requires less efficient code. > And at least in one place resulted in buggy code, that I fixed > recently, > I think it was on AMD64_LINUX. Going through the indirection > mechanism, the PLT, > trashes the static link in rcx, or something like that. > And it is just unnecessary indirection in almost all cases. > So, the questions become, what do people want/expect for Modula-3? > And, does it vary from person to person? System to system? > Windows is "never" going to allow the interposition. > Allowing "interposition" also goes by the description "allow > unresolved symbols in shared objects", to be resolved at load time. > Unix often has one global namespace for all functions in a process. > Apple has a similar thing between "one level namespaces" and "two > level namespaces". > In an older release, they had only one level namespace. Every > dynamically imported > function would be searched for in all dynamically loaded files. > Usually at build time you know the name of the shared object you > expect to find > the function in. So you can have a "two level namespace" where > function names > are associated with a particular file name, and only that file is > searched. > Apple encourages this usage, though of course is bound somewhat by > compatibility. > You can perhaps still build binaries that run on 10.0, and > binaries built to run > on 10.0 in the first place can still run today. > The need to do either of these is always diminishing but hard to > deem zero. > > SOLsun linker has two related switches. > libsunmath.a apparently is not built fully position independent. > libm3core.so must link to it, and therefore does not have a fully > read only text section. > > what to do? > > A few options: > Go back to allowing unresolved symbols in SOLsun, enabling > "interposition". > Then I think libsunmath.a isn't used by .sos, just executables. > I don't like this option. Binding functions to particular file > names (not paths) > seems right and is encouraged by Apple and about the only option > on Windows. > It seems good to use when available. > > Allow writable text section in all .so. > This is what I commited. > > Allow writable text section in only libm3core.so. > This is a better compromise than previous. > > Move FloatMode.m3 into a separate so... libm3coremath.so, > and only let it have a writable text section. > This is a better compromise in terms of amount of writable text, > but also > adds another .so. The fewer .sos the better, arguably. > > Change FloatMode.m3 somehow to not use libsunmath.a. > I think the only way to do this is to make it do nothing at all, > which > is probably what most of the implementations do, but I'd have to > check. > FloatMode.m3 is generally implementable on many systems, like via > _controlfp > on NT386. It is also dangerous to be mucking with the floating > mode -- > what code in the process depends on the default and will be > broken by it changing? > > Worse, the SPARC implementation has a comment saying it is > implemented process-wide > instead of per-thread. Really there are arguments either way. > > The "common" implementation just asserts false. > DS3100, VAX, IRIX, SPARC, SUN386, implement FloatMode. > NT386, *_DARWIN, *_LINUX, *_FREEBSD, SOLgnu do not. > > Maybe just turn it off for SOLsun too? > or go through and provide it everywhere? Always per-thread if > possible? > Only on pthreads implementations preferably? > (I'm not a fan of user threads in general, so don't wish to make > them "better".) > > I think removing FloatMode for SOLsun is probably the way to go. > See if that removes requirement on libsunmath.a. > See if that then allows fully position independent and "resolved" > symbols. > > And maybe there is an updated libsunmath.a? > I just have a "random" version of Solaris 10 from eBay. > I could try a newer OpenSolaris/Nevada version. > > Or drop SOLsun as uninteresting? > (My internet is slow as I said. I finally finished downloading > the "normal" gcc and can build it and try the more active SOLgnu > instead.) > > That would at least ease figuring out the names of: > I386_SOLARIS, AMD64_SOLARIS, SPARC64_SOLARIS > > no need to have two of these of those. :) > > And is SOLgnu meant to use GNU ld or not? > It looks like not. SOLsun and SOLgnu config files are "the same" > here. > Could be GNU ld is compatible in command line usage though. > > (not yet -- I almost have the 64 bit hosted cm3cg bug figured out. > it occurs the same on SPARC64_OPENBSD as AMD64_LINUX. Something about > assignment being DImode vs. VOIDmode. Occurs in many places, > including > RTRuntimeError.Self, by virtue of it using TRY.) > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 12 19:21:47 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 12 Jun 2008 17:21:47 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> Message-ID: Ok I'll have to send out some smaller mails. Hey, I figure, you get the quality of email you pay me for. :) The "obvious" question is, sort of, does anyone give a darn about SOLsun? Using it actively? Wanting it back? Not that I'm only "focusing" (haha) on platforms that people care about, I'm aiming at any mildly interesting target, as an exercise of some sort. (and yes, I know I'm leaving some things a bit incomplete and hope to sweep up before I get too far ahead -- AMD64_LINUX garbage colllection, NT386MINGNU __stdcall being among the older/severest issues; the AMD64_LINUX native cm3cg issue occurs on SPARC64_OPENBSD as well, I hope to fix that "next", have been stepping through looking for where things vary, vs. a cross build from NT386GNU that works..DImode vs. VOIDmode on some assignment statements..the output of cm3cg -y is identical, the output of cm3cg -da is identical before the crash except for pointers, was a while before I remember about the various -d switches, stepping through the code saw a reference to "dump_file"..). Another question is, does anyone give a darn what linker is used on SOL*? If the matter is just to use what is most easily/cheaply acquired, then the answer is use the Sun ld. Perhaps if the matter is "cross platform compatibility" then GNU, perhaps. (ie: bring along as much as you can so you can keep as much the same as possible, such as command lines/config file contents). I "just" got Solaris (8,9,10, less luck with getting 8,9 running though, so sticking with 10) from eBay. I don't know the "real" current bundling/pricing, though the OS itself is now free at least as in beer, tools I suspect too but I don't yet have the free stuff running. The free stuff seems to be kept more up to date for x86 -- at least the current release is x86 only and you have to go back a bit for SPARC. I'm not sure about AMD64. I figure they are catering to a "low end community" and hope to still charge money for the "high end" SPARC hardware (though really I expect x86/AMD64 continues to eat into everyone's lunch... as it gets steadily faster/cheaper...(and yeah, I386_SOLARIS, AMD64_SOLARIS, SPARC64_SOLARIS all on my radar but need to wait..) If the tools are free, SOLgnu becomes less interesting and SOLsun more interesting?? Or, we just run a simple market economy here and demand is pretty little all around, hard to tell? :) It happened to be a little easier/quicker/earlier for me get Sun cc up vs. gcc. But I'm wierd. I actually don't have gcc/Solaris up yet, but should before much longer. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?Date: Thu, 12 Jun 2008 15:51:18 +0100 There's too much in your e-mail to respond to Jay, so I'll just make a simple historical observation: SOLgnu was originally intended as a Solaris target where there was no availability of Sun's cc (Sun did not bundle cc with the OS at the time -- they wanted you to buy it!). However, the rest of the Solaris toolchain has always been bundled with the OS. Thus, with gcc the easiest free option as a replacement for cc, SOLgnu meant folks could use Modula-3 without having to buy Sun's cc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jun 13 11:27:44 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 13 Jun 2008 11:27:44 +0200 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> Message-ID: <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> Quoting Jay : > > Ok I'll have to send out some smaller mails. Hey, I figure, you get > the quality of email you pay me for. :) Could you be more elaborate on who exactly is paying you for M3 work? ;-) I'd like to share this experience... > The "obvious" question is, sort of, does anyone give a darn about SOLsun? > Using it actively? > Wanting it back? Not personally, but I'd just like to remind you of the fact that the Sun compilers were/are highly optimized for the SPARC architecture, so that in certain performance critical domains nobody would use gcc. I don't really know if this is still a current problem of gcc, nor do I know if it has much impacts on CM3 as the gcc backend is used anyway for all M3 code. It would be interesting how good or bad M3s compiled code actually is wrt. the different target platforms... I've got no intention to set up benchmark testing for this though ;-) > Another question is, does anyone give a darn what linker is used on SOL*? > If the matter is just to use what is most easily/cheaply acquired, > then the answer is use the Sun ld. > Perhaps if the matter is "cross platform compatibility" then GNU, > perhaps. (ie: bring along as much as you can so you can keep as much > the same as possible, such as command lines/config file contents). Are there any important differences in the linkers? I wouldn't care much otherwise. 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 13 15:33:47 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 13 Jun 2008 15:33:47 +0200 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <485227DD.1E75.00D7.1@scires.com> References: <48508629.1E75.00D7.1@scires.com> <48510198.1E75.00D7.1@scires.com> <48514EB1.1E75.00D7.1@scires.com> <48519947.1E75.00D7.1@scires.com> <20080613123201.p9rtnudjc4c8400s@mail.elegosoft.com> <485227DD.1E75.00D7.1@scires.com> Message-ID: <20080613153347.vrgtyp5ggk8kwkgo@mail.elegosoft.com> Hi Randy, thanks for the excellent summary. I'm not totally against your suggested extensions; I only try to avoid the additional variables (though they may be in the spirit of the interface). You need three additional boolean variables in Stdio.i3 to determine if one of them is lazy. If instead we had a class LazyConsoleWr.T as a subclass of Wr.T, it could be assigned to the existing Stdio.stdout variable on Windows. The only addition of this type could be the boolean function isVisible(). You could then check for the `lazyness' of the writer by calling ISTYPE( Stdio.stdout, LazyConsoleWr.T ), and if that yields true, determine if the lazy console is visible by NARROW( Stdio.stdout, LazyConsoleWr.T ).isVisible(). This would be a more object-oriented approach. I'm not sure if it really is worth the effort or if we shouldn't just live with the additional variables though. I'm also not sure if it is feasible from an implementation point of view, as I haven't had a look at the initialization code in Windows. As this hasn't been discussed on the m3devel list, and others may have interesting opinions on this, I'd like to raise this issue there, too, in the hope that we agree on a solution soon. I've added your original proposal at the end for reference. Best regards, Olaf Quoting Randy Coleburn : > I agree that adding variables to an interface is not normally a good > idea, BUT that is the way Stdio is set up currently. It uses variables > for stdout, stderr, stdin, and bufferedStderr. The client is free to > change these assignments (and indeed I have programs that do) to change > the runtime behavior. For example, you can make Stdio.stdout a TeeWr.T > to get output going to both stdout and a log file at the same time. > > Stdio provides Wr.T's for stdout & stderr, and a Rd.T for stdin. The > client doesn't really know anything else about them. I gather that Jay > is suggesting that I internally subtype these to be something else and > then externally check for the type, but I don't think this is feasible > without some interface changes that may break existing code. (I welcome > more discussion on this point.) > > The problem we have with the whole lazy console allocation issue is > that the behavior is not documented in an interface and thus there is no > way to control it. Indeed, the whole mess is hidden in the LazyConsole > module buried inside the Win32 subfolder. For Unix, there is no such > thing as lazy console allocation and indeed it is possible for one of > the Stdout variables to be NIL. On cm3 v4.1, it is also possible for > one of the Stdout variables to be NIL, especially when the program is a > GUI-mode program. > > So from a platform-independent view, we currently (cm3 v d5.7.0) have > the following four possibilities for each of the Stdio variables: > 1. variable represents a valid writer/reader to an allocated console > window (or other file/device if command line redirection or pipelining > is used); > 2. variable represents a lazy-allocated console window that is not yet > visible; > 3. variable represents a lazy-allocated console window that has popped > up on the screen (probably occluding part of the real gui window); > 4. variable is NIL because the process has no standard file handle of > this type (but only if not running on Windows). > > Since the lazy-allocation is hidden from view, the client code has no > way of knowing reliably at runtime which of the 4 states the program is > in, and on Windows the state can change dynamically from #2 to #3 (it is > not constant as when on Unix). > > On cm3 v4.1, states #2 & #3 did not exist, so clients could simply > check if the variable was NIL to know whether I/O to the Stdout > variables would work. But now, on cm3 v5.7 there is no way to make this > check reliably on all platforms because on Windows state #4 cannot exist > and states #2 and #3 are hidden from the programmer. Further, since > this behavior is not documented in an interface, the change from 4.1 to > 5.7 breaks existing 4.1 code. When I say "breaks" I don't mean > necessarily that the program crashes, but rather that the behavior is > different than expected and thus "broken". > > Now the primary advantage (possibly the only advantage) to the new lazy > console allocation scheme on Windows is that your GUI-mode program won't > crash if you write to stdout without ensuring it is non-NIL. (Maybe > this begs the question of whether the lazy-allocation is really > needed.) > > The proposal I made has the following advantages: > A. It does not break any existing code. > B. It keeps the same spirit of Stdio in terms of using variables. > C. It gives programmers the opportunity to prevent or allow the lazy > pop-up console windows. > D. If programmers don't make a choice about the lazy pop-up windows, > there is no change in behavior from current operation. > E. It works on Unix or Windows (thus is platform-independent) > F. It allows programmers to go back and easily adjust old code built > for cm3 v4.1 to work as expected when built using cm3 5.7. > > The proposal has the following disadvantages: > X. It continues the practice of putting variables in an interface > (assuming this practice is frowned upon) > Y. Since it augments two prominent interfaces (Stdio & Process), it > will require rebuilding of everything. > Z. Programmers using features of the revised interfaces won't be able > to compile their code using older versions of cm3. > > Here is a quick example showing the utility of knowing at runtime about > the lazy allocation: Suppose you have a -GUI mode program. There is a > lot of code in libraries et al that expects to write to stdout to > provide error messages, etc. If the user calls my -GUI program with the > wrong arguments, I want to give him an error message. In the current > situation on Windows, if I write to stdout or stderr, I will get a > pop-up console window that will flash up briefly, but disappear as soon > as the program terminates. On Unix, the behavior is different since > there is no pop-up console window. If I knew at runtime that the > stdout/stderr was lazy-allocated, I could pause for a few seconds to > allow the user to see the error message on the pop-up console, or I > could redirect the message to a file, or I could even require the user > to acknowledge the pop-up console message by pressing Enter on the > keyboard before terminating the program. I could also choose not to > send output to stdout when the console is lazy-allocated and thus > prevent an extra icon from showing up in the task bar. In short, I > believe the lazy-allocation needs to be exposed so programmers can deal > with it appropriately for the operating context of their program. > > If you don't want to go the route of my proposal, I'm welcome to hear > another suggestion on how to expose runtime knowledge of the lazy > allocation. > > Regards, > Randy Original proposal: 1. Add procedure AreStdFileHandlesLazy (VAR stdIn_IsLazy, stdOut_IsLazy, stdErr_IsLazy: BOOLEAN) to interface Process. This won't break any existing code since it is a new procedure addition, but it will force rebuilding of everything. 2. Adjust internals of Process implementations to deal with implementation of this new procedure. The procedure's parameter output values for all platforms will be FALSE, except for Windows where they will depend on whether the file is lazily allocated. These changes will be transparent to all clients. 3. Add following variables to Stdio interface: stdIn_IsLazy, stdOut_IsLazy, stdErr_IsLazy: BOOLEAN; This change won't break any existing code, but it will force rebuilding of everything. 4. Modify Stdio implementation to properly initialize the new variables during module initialization. This change will be transparent to all clients. Now, with these changes, it will be possible for a client to know whether stdout, stderr, and/or stdin represent lazily allocated consoles or not, then act accordingly. For example, if I want to make sure messages written to stdout are recorded even for a GUI-app, but I don't want a popup, I could do the following: IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) THEN Stdio.stdout := FileWr.Open("myLogFile.txt"); Stdio.stdOut_IsLazy := FALSE; END; Now the above code fragment does show the possibility of a race condition in multi-threaded code. I suggest that a comment be added to the Stdio interface that states any manipulation of the exposed variables should be done from single-threaded code or that the client should implement use of a mutex. Otherwise, we could change Stdio to have get/set procedures, but that would break a lot of existing code. Indeed, instead of changing the Stdio interface, it would be better IMO to just provide an extra interface/implementation that provides these functions and tell new multi-threaded clients to use the thread-friendly version. Please let me know what you think about this proposal. If it is okay, I'd like to go ahead and make the changes to the repository, including adding a warning comment about thread friendliness. I won't provide the extra thread-friendly interface/implementation of Stdio unless you want it. Now that I think about it, I should also add the following function procedures to Stdio (3 variants, one each for stdout, stderr, and stdin) and that would probably eliminate need for the thread-friendly interface: PROCEDURE EnsureNotLazyStdOut (alternateWr: Wr.T) : BOOLEAN = (* If stdout is NIL or lazily allocated, replace it by alternateWr, which must be a valid writer (non-nil). Returns TRUE if alternateWr is substituted for stdout; otherwise returns FALSE. Note that this function is thread-safe. *) BEGIN <*ASSERT alternateWr # NIL*> LOCK privateMutex DO IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) THEN Stdio.stdout := alternateWr; Stdio.stdOut_IsLazy := FALSE; RETURN TRUE; ELSE RETURN FALSE; END; END; END EnsureNotLazyStdOut; -- 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 jayk123 at hotmail.com Sat Jun 14 00:58:05 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 13 Jun 2008 22:58:05 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> Message-ID: Right, good point, gcc usually generates worse code than any other compiler. "We" don't have much C code though, so the compiler is mostly just a driver for the linker. > It would be interesting how good or bad M3s compiled code actually The little I've looked at is not good, but nobody notices. Besides I don't want to pay the time or the risk or lost debugability of gcc's optimizer so I don't use it lately. The integrated backend is quite in the middle. It does certain local optimizations all the time, but lacks analysis over a larger scope.> Are there any important differences in the linkers? I wouldn't care> much otherwise. I don't know. I'm still working on getting gcc and ld built/installed/working, though might skip them. Sun ld is what is in use and, for once, I'll say I have enough other stuff to leave this very very low priority. (My ambition on this platform is basically -- make sure I can build it, make sure I can build a distribution, finally introduce "version.txt" now having Solaris /bin/sh/sed/awk to test with!, and then add introduce SPARC64_SOLARIS -- begging the question of GNU/Sun targets...) Hm, speaking of version.txt -- if I test on Solaris 10, good enough? Are folks on this list using Modula-3 on older versions of Solaris? Even so, what works on 10 "probably" works on older. - Jay> Date: Fri, 13 Jun 2008 11:27:44 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?> > Quoting Jay :> > >> > Ok I'll have to send out some smaller mails. Hey, I figure, you get > > the quality of email you pay me for. :)> > Could you be more elaborate on who exactly is paying you for M3 work? ;-)> I'd like to share this experience...> > > The "obvious" question is, sort of, does anyone give a darn about SOLsun?> > Using it actively?> > Wanting it back?> > Not personally, but I'd just like to remind you of the fact that> the Sun compilers were/are highly optimized for the SPARC architecture,> so that in certain performance critical domains nobody would use> gcc. I don't really know if this is still a current problem of gcc,> nor do I know if it has much impacts on CM3 as the gcc backend is> used anyway for all M3 code.> > It would be interesting how good or bad M3s compiled code actually> is wrt. the different target platforms... I've got no intention to> set up benchmark testing for this though ;-)> > > Another question is, does anyone give a darn what linker is used on SOL*?> > If the matter is just to use what is most easily/cheaply acquired, > > then the answer is use the Sun ld.> > Perhaps if the matter is "cross platform compatibility" then GNU, > > perhaps. (ie: bring along as much as you can so you can keep as much > > the same as possible, such as command lines/config file contents).> > Are there any important differences in the linkers? I wouldn't care> much otherwise.> > 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 hosking at cs.purdue.edu Sat Jun 14 13:43:07 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 14 Jun 2008 12:43:07 +0100 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> Message-ID: Can you justify that statement? On Jun 13, 2008, at 11:58 PM, Jay wrote: > > Right, good point, gcc usually generates worse code than any other > compiler From jayk123 at hotmail.com Sat Jun 14 19:32:32 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 14 Jun 2008 17:32:32 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> Message-ID: mostly rumor, hearsay..sorryI had some examples a few months ago but too lazy to dig them up. - Jay> CC: wagner at elegosoft.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> To: jayk123 at hotmail.com> Subject: Re: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?> Date: Sat, 14 Jun 2008 12:43:07 +0100> > Can you justify that statement?> > On Jun 13, 2008, at 11:58 PM, Jay wrote:> > >> > Right, good point, gcc usually generates worse code than any other > > compiler> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jun 15 14:20:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 15 Jun 2008 12:20:12 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> Message-ID: Ok, I'm able to build SOLsun now.I uploaded min and std archives. Juno and some other apps can display on Cygwin. caveats: I forgot to put in Unix.common. Just copy it in from the source tree. I haven't yet been able to build cm3cg, so I used one from a daily SOLgnu (and it depends on libiconv) whatever Sun cc I have (5.8 2005/10/13), won't bootstrap gcc 4.3.1. It doesn't like for example #define FOO(a,b) blah FOO(,c) I'd rather not just download prebuilt binaries.I'll try (Canadian) crossing from Cygwin, else a more current Solaris.Cross is tricky. It is well documented you need to copy over /usr/include,but less clear to me about libs like values*.o, needed for building libgcc,which is needed at some point it seems, or at least there is an attempt to use it..and then not clear to use /usr/local//lib, or -sysroot=/usr/local/ and mimic structure from there (include vs. usr/include, lib vs. usr/lib and usr/ccs/lib)..I'll see... A lot of the cross documentation and friendly wrappers assumes crossing from Linux to Linux. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?Date: Thu, 12 Jun 2008 17:21:47 +0000 ......snip...... -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Jun 18 16:36:59 2008 From: rodney.bates at wichita.edu (rodney.bates) Date: Wed, 18 Jun 2008 09:36:59 -0500 Subject: [M3devel] =?iso-8859-1?q?proposal_for_dealing_with_lazy_console--?= =?iso-8859-1?q?please_review_and_=09comment!?= Message-ID: <481A920F@webmail.wichita.edu> I don't understand well enough what it means for a console to be lazily-allocated, but I wonder if it makes any sense to allow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T ever be lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside procedures that do it in a thread-safe way? >4. Modify Stdio implementation to properly initialize the new >variables during module initialization. >This change will be transparent to all clients. > >Now, with these changes, it will be possible for a client to know >whether stdout, stderr, and/or stdin represent lazily allocated >consoles or not, then act accordingly. > >For example, if I want to make sure messages written to stdout are >recorded even for a GUI-app, but I don't want a popup, I could do the >following: > IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) > THEN > Stdio.stdout := FileWr.Open("myLogFile.txt"); > Stdio.stdOut_IsLazy := FALSE; > END; >Now the above code fragment does show the possibility of a race >condition in multi-threaded code. > Rodney Bates Retired assistant professor Computer Science From rcoleburn at scires.com Wed Jun 18 18:50:29 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 18 Jun 2008 12:50:29 -0400 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <481A920F@webmail.wichita.edu> References: <481A920F@webmail.wichita.edu> Message-ID: <48590490.1E75.00D7.1@scires.com> Hi Rodney: Thanks for your reply. The issue is that for cm3 on Windows you can specify -gui as a command line option. This option causes the program to be built as a Windows GUI-mode application, rather than as a console application. For a GUI-mode application, the Stdio file handles are NIL because it has no console. Seemingly, to prevent a lot of errors when trying to read/write Stdio, some folks introduced the idea of a lazy console post cm3 v4.1. What happens now "under the covers" is that on a GUI-mode program the Stdio file handles are allocated as Lazy Consoles. Then, whenever Stdio.stdout/stderr/stdin is used, the underlying code realizes the first use and magically allocates a new console window on the fly. This console window pops up on the screen on top of your GUI-mode window. My objection is that this behavior is not documented in any interface and the programmer has no way to control the behavior. I want to make such control possible. Hope this explanation helps a bit. Regards, Randy >>> "rodney.bates" 6/18/2008 10:36 AM >>> I don't understand well enough what it means for a console to be lazily-allocated, but I wonder if it makes any sense to allow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T ever be lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside procedures that do it in a thread-safe way? >4. Modify Stdio implementation to properly initialize the new >variables during module initialization. >This change will be transparent to all clients. > >Now, with these changes, it will be possible for a client to know >whether stdout, stderr, and/or stdin represent lazily allocated >consoles or not, then act accordingly. > >For example, if I want to make sure messages written to stdout are >recorded even for a GUI-app, but I don't want a popup, I could do the >following: > IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) > THEN > Stdio.stdout := FileWr.Open("myLogFile.txt"); > Stdio.stdOut_IsLazy := FALSE; > END; >Now the above code fragment does show the possibility of a race >condition in multi-threaded code. > Rodney Bates Retired assistant professor Computer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jun 18 19:20:03 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 18 Jun 2008 17:20:03 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <48590490.1E75.00D7.1@scires.com> References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> Message-ID: Randy, really, the vast majority of behavior is undocumented and not controllable. However I agree making this controllable is perfectly reasonable. The folks that did this were I believe Critical Mass, between "4.1" and "5.1", though granted the history is not completely known, just that 4.1 and earlier doesn't behave this way. I strongly advocate a type-based solution here. However, I believe there are several bits per handle however, not one. Not at the Win32 level, but in terms of the control you would want in the Modula-3. There is: Is the console visible? Either because it started that way, or because "someone" has written to it already. Should any/no write make it visible? Should "this particular" write make it visible? That is, you probably want the ability to avoid the console becoming visible. You probably want the ability to control this globally or per-write. Maybe even per-thread and not just per-process. And, say, if there is a severe error, you want to enable it becoming visible. And, say, if someone else wrote an error and made it visible and now you just have a warning, you might want to "piggy back" on the visibility and go ahead and print. You may even want to rehide the console, if that is possible. (Could expose this in the interface and it make it a nop..) Controlling this per-thread or per-process or per-write is actually pretty problematic. Because even if it is per-thread or per-process, I believe it should at the same time be per-handle. I should be able to block revelation on stdout for current thread, and then restore it when I am done. While leaving stderr unaltered, on the theory that stderr output is more important. Similarly per-process. But then each handle has per-thread locals. Ok, duh, per-process doesn't make sense, that's the same as per-handle. Controlling it per-handle is not problematic. Each handle would just have a fixed set of extra bits. I believe controlling it module-wide either per-process or per-thread *might* be interesting, but less so. Globals are bad. Even if hidden behind thread-safe functions. Just because Modula-3 nicely contains process-globals in modules, doesn't make them acceptable. I think modules are overrated actually, and "objects" -- instances of types are much more important. Modula-3 does "work", just that I should in general create Foo.T data and pass them as the first parameter to Foo.DoSomething. Programming is much more "type based" than "module based" imho. I know there is some disagreement here, but I'm not sure there is much. Really, there is a general issue of globals vs. parameters to functions, throughout a callstack. One implementation strategy would be to able to create a "wrapper" object. You would set the "policy" on that object -- perhaps via which type you created in the first place. You would pass that around to all your code. That would achieve per-thread, or per-whatever-you want, BUT it'd require you pass it around to all of your code. It is a tough discpline to really pass around all parameters, and not rely on some larger "global" or per-thread context. Thread locals and globals quite stink, and "plumbing the full depths of a call tree" can also be quite difficult". The problem, you know, of "oops, I forgot to add a parameter in lots of places. What do I do now? I know, I'll make a thread local, set it at the top of the call tree, check it in the middle or at the bottom, but not pass it all around..." It's a difficult problem. Much of the code in a particular call tree might not know or care about what the top and bottom care about, but somehow should be able to ferry along "context". Thread locals are so tempting and oh so problematic... - Jay Date: Wed, 18 Jun 2008 12:50:29 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Hi Rodney: Thanks for your reply. The issue is that for cm3 on Windows you can specify -gui as a command line option. This option causes the program to be built as a Windows GUI-mode application, rather than as a console application. For a GUI-mode application, the Stdio file handles are NIL because it has no console. Seemingly, to prevent a lot of errors when trying to read/write Stdio, some folks introduced the idea of a lazy console post cm3 v4.1. What happens now "under the covers" is that on a GUI-mode program the Stdio file handles are allocated as Lazy Consoles. Then, whenever Stdio.stdout/stderr/stdin is used, the underlying code realizes the first use and magically allocates a new console window on the fly. This console window pops up on the screen on top of your GUI-mode window. My objection is that this behavior is not documented in any interface and the programmer has no way to control the behavior. I want to make such control possible. Hope this explanation helps a bit. Regards, Randy>>> "rodney.bates" 6/18/2008 10:36 AM >>>I don't understand well enough what it means for a consoleto be lazily-allocated, but I wonder if it makes any sense toallow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T everbe lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside proceduresthat do it in a thread-safe way?>4. Modify Stdio implementation to properly initialize the new>variables during module initialization.>This change will be transparent to all clients.>>Now, with these changes, it will be possible for a client to know>whether stdout, stderr, and/or stdin represent lazily allocated>consoles or not, then act accordingly.>>For example, if I want to make sure messages written to stdout are>recorded even for a GUI-app, but I don't want a popup, I could do the>following:> IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL)> THEN> Stdio.stdout := FileWr.Open("myLogFile.txt");> Stdio.stdOut_IsLazy := FALSE;> END;>Now the above code fragment does show the possibility of a race>condition in multi-threaded code.>Rodney BatesRetired assistant professorComputer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Jun 19 05:18:59 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 18 Jun 2008 23:18:59 -0400 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> Message-ID: <485997DD.1E75.00D7.1@scires.com> Jay: I'd be satisfied just to deal with this on a per program instance, rather than at a thread level. Indeed, I'm not sure it makes sense on a per thread level. The Stdio module and global vars are shared by all code in the program process. I'm wondering if it might be better at this point to use environment variables to control the behavior. The current implementation initializes everything during module initialization at program startup. Thus, this occurs before dependent modules get a chance to run and influence the behavior. Perhaps the lazy console allocation should be the default unless a certain environment variable is set, say CM3_LazyConsole=FALSE. In this case the initialization code would turn off the lazy allocation and in the case of a GUI-mode program on Windows the Stdio.stdin/stdout/stderr would be NIL. If CM3_LazyConsole=TRUE or is not defined, you would get a lazy allocated console on Windows GUI-mode programs and a regular console otherwise. This approach has the advantage that no interfaces have to change. Of course, if folks want to add finer grains of control as you suggest, that would be ok. I just want to be able to prevent the popup of the lazy allocated console. I'm willing to make the modifications to the code unless someone objects to my approach. Regards, Randy >>> Jay 6/18/2008 1:20 PM >>> Randy, really, the vast majority of behavior is undocumented and not controllable. However I agree making this controllable is perfectly reasonable. The folks that did this were I believe Critical Mass, between "4.1" and "5.1", though granted the history is not completely known, just that 4.1 and earlier doesn't behave this way. I strongly advocate a type-based solution here. However, I believe there are several bits per handle however, not one. Not at the Win32 level, but in terms of the control you would want in the Modula-3. There is: Is the console visible? Either because it started that way, or because "someone" has written to it already. Should any/no write make it visible? Should "this particular" write make it visible? That is, you probably want the ability to avoid the console becoming visible. You probably want the ability to control this globally or per-write. Maybe even per-thread and not just per-process. And, say, if there is a severe error, you want to enable it becoming visible. And, say, if someone else wrote an error and made it visible and now you just have a warning, you might want to "piggy back" on the visibility and go ahead and print. You may even want to rehide the console, if that is possible. (Could expose this in the interface and it make it a nop..) Controlling this per-thread or per-process or per-write is actually pretty problematic. Because even if it is per-thread or per-process, I believe it should at the same time be per-handle. I should be able to block revelation on stdout for current thread, and then restore it when I am done. While leaving stderr unaltered, on the theory that stderr output is more important. Similarly per-process. But then each handle has per-thread locals. Ok, duh, per-process doesn't make sense, that's the same as per-handle. Controlling it per-handle is not problematic. Each handle would just have a fixed set of extra bits. I believe controlling it module-wide either per-process or per-thread *might* be interesting, but less so. Globals are bad. Even if hidden behind thread-safe functions. Just because Modula-3 nicely contains process-globals in modules, doesn't make them acceptable. I think modules are overrated actually, and "objects" -- instances of types are much more important. Modula-3 does "work", just that I should in general create Foo.T data and pass them as the first parameter to Foo.DoSomething. Programming is much more "type based" than "module based" imho. I know there is some disagreement here, but I'm not sure there is much. Really, there is a general issue of globals vs. parameters to functions, throughout a callstack. One implementation strategy would be to able to create a "wrapper" object. You would set the "policy" on that object -- perhaps via which type you created in the first place. You would pass that around to all your code. That would achieve per-thread, or per-whatever-you want, BUT it'd require you pass it around to all of your code. It is a tough discpline to really pass around all parameters, and not rely on some larger "global" or per-thread context. Thread locals and globals quite stink, and "plumbing the full depths of a call tree" can also be quite difficult". The problem, you know, of "oops, I forgot to add a parameter in lots of places. What do I do now? I know, I'll make a thread local, set it at the top of the call tree, check it in the middle or at the bottom, but not pass it all around..." It's a difficult problem. Much of the code in a particular call tree might not know or care about what the top and bottom care about, but somehow should be able to ferry along "context". Thread locals are so tempting and oh so problematic... - Jay Date: Wed, 18 Jun 2008 12:50:29 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Hi Rodney: Thanks for your reply. The issue is that for cm3 on Windows you can specify -gui as a command line option. This option causes the program to be built as a Windows GUI-mode application, rather than as a console application. For a GUI-mode application, the Stdio file handles are NIL because it has no console. Seemingly, to prevent a lot of errors when trying to read/write Stdio, some folks introduced the idea of a lazy console post cm3 v4.1. What happens now "under the covers" is that on a GUI-mode program the Stdio file handles are allocated as Lazy Consoles. Then, whenever Stdio.stdout/stderr/stdin is used, the underlying code realizes the first use and magically allocates a new console window on the fly. This console window pops up on the screen on top of your GUI-mode window. My objection is that this behavior is not documented in any interface and the programmer has no way to control the behavior. I want to make such control possible. Hope this explanation helps a bit. Regards, Randy >>> "rodney.bates" 6/18/2008 10:36 AM >>> I don't understand well enough what it means for a console to be lazily-allocated, but I wonder if it makes any sense to allow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T ever be lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside procedures that do it in a thread-safe way? >4. Modify Stdio implementation to properly initialize the new >variables during module initialization. >This change will be transparent to all clients. > >Now, with these changes, it will be possible for a client to know >whether stdout, stderr, and/or stdin represent lazily allocated >consoles or not, then act accordingly. > >For example, if I want to make sure messages written to stdout are >recorded even for a GUI-app, but I don't want a popup, I could do the >following: > IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) > THEN > Stdio.stdout := FileWr.Open("myLogFile.txt"); > Stdio.stdOut_IsLazy := FALSE; > END; >Now the above code fragment does show the possibility of a race >condition in multi-threaded code. > Rodney Bates Retired assistant professor Computer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 19 05:47:28 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 19 Jun 2008 03:47:28 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <485997DD.1E75.00D7.1@scires.com> References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> <485997DD.1E75.00D7.1@scires.com> Message-ID: Randy, just because the initialization happens early does not mean you can't affect the behavior later. The type can be changed at initialization time, and then the instance configured later. Unless you are worried about other module initializers ignorantly calling stdout.Wr() and causing the console to appear? If so, yeah. How about @M3 command line parameters instead? At least they aren't "sticky" and can be more easily localized to a single process. I ignore sh's feature here usually, and in this case that makes good sense. "Command line parameters are better than environment variables". Supporting both is reasonable. However, if so, and if it is an @M3 variable, there should perhaps be one variable to contain @M3 options?? Still I'm not a fan of globals like this. I think it should be configurable per type instantiation. You could also imagine that one variable is the "during initialization time" configuration, and then once Main starts, another configuration takes over, since by then whoever wants to set it has had a chance to run. Btw, sleazy, but you could also make it a built-time configuration. You could easily build your m3core.dll to have one default behavior, while everyone else's has another. - Jay Date: Wed, 18 Jun 2008 23:18:59 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Jay: I'd be satisfied just to deal with this on a per program instance, rather than at a thread level. Indeed, I'm not sure it makes sense on a per thread level. The Stdio module and global vars are shared by all code in the program process. I'm wondering if it might be better at this point to use environment variables to control the behavior. The current implementation initializes everything during module initialization at program startup. Thus, this occurs before dependent modules get a chance to run and influence the behavior. Perhaps the lazy console allocation should be the default unless a certain environment variable is set, say CM3_LazyConsole=FALSE. In this case the initialization code would turn off the lazy allocation and in the case of a GUI-mode program on Windows the Stdio.stdin/stdout/stderr would be NIL. If CM3_LazyConsole=TRUE or is not defined, you would get a lazy allocated console on Windows GUI-mode programs and a regular console otherwise. This approach has the advantage that no interfaces have to change. Of course, if folks want to add finer grains of control as you suggest, that would be ok. I just want to be able to prevent the popup of the lazy allocated console. I'm willing to make the modifications to the code unless someone objects to my approach. Regards, Randy>>> Jay 6/18/2008 1:20 PM >>>Randy, really, the vast majority of behavior is undocumented and not controllable.However I agree making this controllable is perfectly reasonable.The folks that did this were I believe Critical Mass, between "4.1" and "5.1", though granted the history is not completely known, just that 4.1 and earlier doesn't behave this way. I strongly advocate a type-based solution here. However, I believe there are several bits per handle however, not one.Not at the Win32 level, but in terms of the control you would want in the Modula-3. There is: Is the console visible? Either because it started that way, or because "someone" has written to it already. Should any/no write make it visible? Should "this particular" write make it visible? That is, you probably want the ability to avoid the console becoming visible.You probably want the ability to control this globally or per-write.Maybe even per-thread and not just per-process.And, say, if there is a severe error, you want to enable it becoming visible.And, say, if someone else wrote an error and made it visible and now you just have a warning, you might want to "piggy back" on the visibility and go ahead and print. You may even want to rehide the console, if that is possible.(Could expose this in the interface and it make it a nop..) Controlling this per-thread or per-process or per-write is actually pretty problematic. Because even if it is per-thread or per-process, I believe it should at the same time be per-handle. I should be able to block revelation on stdout for current thread, and then restore it when I am done. While leaving stderr unaltered, on the theory that stderr output is more important. Similarly per-process. But then each handle has per-thread locals. Ok, duh, per-process doesn't make sense, that's the same as per-handle. Controlling it per-handle is not problematic. Each handle would just have a fixed set of extra bits. I believe controlling it module-wide either per-process or per-thread *might* be interesting, but less so. Globals are bad. Even if hidden behind thread-safe functions. Just because Modula-3 nicely contains process-globals in modules, doesn't make them acceptable. I think modules are overrated actually, and "objects" -- instances of types are much more important. Modula-3 does "work", just that I should in general create Foo.T data and pass them as the first parameter to Foo.DoSomething. Programming is much more "type based" than "module based" imho. I know there is some disagreement here, but I'm not sure there is much. Really, there is a general issue of globals vs. parameters to functions, throughout a callstack. One implementation strategy would be to able to create a "wrapper" object.You would set the "policy" on that object -- perhaps via which type you created in the first place. You would pass that around to all your code. That would achieve per-thread, or per-whatever-you want, BUT it'd require you pass it around to all of your code. It is a tough discpline to really pass around all parameters, and not rely on some larger "global" or per-thread context. Thread locals and globals quite stink, and "plumbing the full depths of a call tree" can also be quite difficult". The problem, you know, of "oops, I forgot to add a parameter in lots of places. What do I do now? I know, I'll make a thread local, set it at the top of the call tree, check it in the middle or at the bottom, but not pass it all around..." It's a difficult problem. Much of the code in a particular call tree might not know or care about what the top and bottom care about, but somehow should be able to ferry along "context". Thread locals are so tempting and oh so problematic... - Jay Date: Wed, 18 Jun 2008 12:50:29 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Hi Rodney: Thanks for your reply. The issue is that for cm3 on Windows you can specify -gui as a command line option. This option causes the program to be built as a Windows GUI-mode application, rather than as a console application. For a GUI-mode application, the Stdio file handles are NIL because it has no console. Seemingly, to prevent a lot of errors when trying to read/write Stdio, some folks introduced the idea of a lazy console post cm3 v4.1. What happens now "under the covers" is that on a GUI-mode program the Stdio file handles are allocated as Lazy Consoles. Then, whenever Stdio.stdout/stderr/stdin is used, the underlying code realizes the first use and magically allocates a new console window on the fly. This console window pops up on the screen on top of your GUI-mode window. My objection is that this behavior is not documented in any interface and the programmer has no way to control the behavior. I want to make such control possible. Hope this explanation helps a bit. Regards, Randy>>> "rodney.bates" 6/18/2008 10:36 AM >>>I don't understand well enough what it means for a consoleto be lazily-allocated, but I wonder if it makes any sense toallow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T everbe lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside proceduresthat do it in a thread-safe way?>4. Modify Stdio implementation to properly initialize the new>variables during module initialization.>This change will be transparent to all clients.>>Now, with these changes, it will be possible for a client to know>whether stdout, stderr, and/or stdin represent lazily allocated>consoles or not, then act accordingly.>>For example, if I want to make sure messages written to stdout are>recorded even for a GUI-app, but I don't want a popup, I could do the>following:> IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL)> THEN> Stdio.stdout := FileWr.Open("myLogFile.txt");> Stdio.stdOut_IsLazy := FALSE;> END;>Now the above code fragment does show the possibility of a race>condition in multi-threaded code.>Rodney BatesRetired assistant professorComputer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jun 19 08:55:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 19 Jun 2008 08:55:10 +0200 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> <485997DD.1E75.00D7.1@scires.com> Message-ID: <20080619085510.eagbposkcg0g4g4o@mail.elegosoft.com> Quoting Jay : > Randy, just because the initialization happens early does not mean > you can't affect the behavior later. The type can be changed at > initialization time, and then the instance configured later. Unless > you are worried about other module initializers ignorantly calling > stdout.Wr() and causing the console to appear? If so, yeah. > > How about @M3 command line parameters instead? > At least they aren't "sticky" and can be more easily localized to a > single process. What does sticky mean here? > I ignore sh's feature here usually, and in this case that makes good sense. environment variables aren't a feature of shells, but or process contexts. Shells just allow to set them explicitly. > "Command line parameters are better than environment variables". > Supporting both is reasonable. Yes, if we go this way, we should support both options. An environment variable overrides a built-in default, and an explicit parameter overrides the environment setting if present. > However, if so, and if it is an @M3 variable, there should perhaps > be one variable to contain @M3 options?? Something like `@m3opt=lazyconsole,dontcrash,whatsoever'? What other options do you have in mind? > Still I'm not a fan of globals like this. I think it should be > configurable per type instantiation. > You could also imagine that one variable is the "during > initialization time" configuration, and then once Main starts, > another configuration takes over, since by then whoever wants to set > it has had a chance to run. > > Btw, sleazy, but you could also make it a built-time configuration. > You could easily build your m3core.dll to have one default behavior, > while everyone else's has another. I think we'll have to decide which way to go, as Randy needs a solution to continue his work. Currently the easiest approach seems to be the environment variable/command line solution indeed, as no interface need to be touched and no new modules are required. Would anybody object to this approach? More control could easily be added later, if that is really required. (After all, this currently is just a problem for Windows GUI programs.) What about M3_LAZY_CONSOLE and @M3lazyconsole for a start? 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 jayk123 at hotmail.com Thu Jun 19 10:04:12 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 19 Jun 2008 08:04:12 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <20080619085510.eagbposkcg0g4g4o@mail.elegosoft.com> References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> <485997DD.1E75.00D7.1@scires.com> <20080619085510.eagbposkcg0g4g4o@mail.elegosoft.com> Message-ID: set CM3_ConsoleBehavior=4.1 m3guiapp console behavior still changed m3guiapp @M3ConsoleBehavior=4.1 console behavior back to "default" - Jay> Date: Thu, 19 Jun 2008 08:55:10 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] proposal for dealing with lazy console--please review and comment!> > Quoting Jay :> > > Randy, just because the initialization happens early does not mean > > you can't affect the behavior later. The type can be changed at > > initialization time, and then the instance configured later. Unless > > you are worried about other module initializers ignorantly calling > > stdout.Wr() and causing the console to appear? If so, yeah.> >> > How about @M3 command line parameters instead?> > At least they aren't "sticky" and can be more easily localized to a > > single process.> What does sticky mean here?> > > I ignore sh's feature here usually, and in this case that makes good sense -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Sat Jun 21 16:18:35 2008 From: rodney.bates at wichita.edu (rodney.bates) Date: Sat, 21 Jun 2008 09:18:35 -0500 Subject: [M3devel] =?iso-8859-1?q?proposal_for_dealing_with_lazy_=09consol?= =?iso-8859-1?q?e--please=09review_and_comment!?= Message-ID: <481B6AEF@webmail.wichita.edu> I guess I am on a somewhat different wavelength on this. I do agree that a complete set of queries by the application should be supported, concerning lazy allocated streams. But to me, applications need to have either very little or nothing in the way of ability to change behaviour. For one thing, it makes sense for the lazy property to apply only to stdout/stderr, on win32 platforms, compiled as -gui. This is why I was questioning getting a stream from FileWr.Open, and then setting it lazy. Laziness doesn't make any sense on a disk file. Beyond that, I think at the most, an application should be able to change the laziness property only before any data has been written to the stream. After that, the window is already popped, and the semantics would get ugly. In fact, I am very skeptical about the need for an application to change laziness at all. If it can query this property, then it can just refrain from writing to the steam, if it doesn't want the window to pop up. Hence my objection to making the properties variables, not because of general principal, but because an application could assign to them at any time. >===== Original Message From Jay ===== >set CM3_ConsoleBehavior=4.1 >m3guiapp >console behavior still changed > >m3guiapp @M3ConsoleBehavior=4.1 >console behavior back to "default" > - Jay> Rodney Bates Retired assistant professor Computer Science From rcoleburn at scires.com Sat Jun 21 17:41:09 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 21 Jun 2008 11:41:09 -0400 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <481B6AEF@webmail.wichita.edu> References: <481B6AEF@webmail.wichita.edu> Message-ID: <485CE8D0.1E75.00D7.1@scires.com> Thanks Rodney and Jay for your comments. Here are a few points I'd like to add to this discussion. 1. I agree with Jay that command line arguments would be better than environment variables. 2. I agree with Rodney that the "laziness property" must be set before data gets read/written and that it should be set only once, not changed during execution. 3. A drawback to using command-line variables (and env vars) is that it shifts the responsibility from the programmer to the user. IMO, this type of behavior is something that is "designed" and documented as part of the program, so it should not be changeable by the user. For example, if the user fails to put the appropriate parameter on the command-line, the program's behavior changes. In effect, this is sort of what has happened to me, that is, the behavior of my cm3 v4.1 gui-mode program(s) has changed from its design because the underlying implementation changed to use lazy console allocation and I have no way of getting the old behavior back without changing the implementation. 4. Perhaps a better approach would be to devise a new option for the compiler. For example, "-gui" works as now and uses lazy console allocation. "-gui_no_lazy" works the way -gui did in 4.1 where the Stdio.stdin/stderr/stdout would be NIL for a gui-mode program. The problem here is I'm not sure exactly how to implement it. In effect, use of this option would mean we would need to swap (i.e., choose) the implementation of Process.m3 at compile time, OR we would need some way to ensure the Stdio variables get set to NIL after the current Process.m3 initialization (thereby undoing the lazy allocation). Maybe one of these methods can be done via quake somehow, but I'm not sure how to go about it. Any ideas? 5. If I'm the only person having this issue with the lazy allocation, perhaps I can adapt my programs. Perhaps I can just set the Stdio variables to be NIL at the beginning of my mainline code for programs I know should be compiled as -gui. This brings to mind an idea for how to implement -gui_no_lazy. Do you think we could write some quake code that causes a new module implementation to be included in the program whenever the target is NT386 AND the -gui_no_lazy option is set? This new implementation would import from Stdio and all it would do is set the Stdio vars to be NIL. Since it imports from Stdio and Stdio imports Process, I would tend to think that Process and Stdio module initializations would be run before this new module initialization thereby ensuring the lazy allocated consoles get set to NIL. What do you think? Regards, Randy >>> "rodney.bates" 6/21/2008 10:18 AM >>> I guess I am on a somewhat different wavelength on this. I do agree that a complete set of queries by the application should be supported, concerning lazy allocated streams. But to me, applications need to have either very little or nothing in the way of ability to change behaviour. For one thing, it makes sense for the lazy property to apply only to stdout/stderr, on win32 platforms, compiled as -gui. This is why I was questioning getting a stream from FileWr.Open, and then setting it lazy. Laziness doesn't make any sense on a disk file. Beyond that, I think at the most, an application should be able to change the laziness property only before any data has been written to the stream. After that, the window is already popped, and the semantics would get ugly. In fact, I am very skeptical about the need for an application to change laziness at all. If it can query this property, then it can just refrain from writing to the steam, if it doesn't want the window to pop up. Hence my objection to making the properties variables, not because of general principal, but because an application could assign to them at any time. >===== Original Message From Jay ===== >set CM3_ConsoleBehavior=4.1 >m3guiapp >console behavior still changed > >m3guiapp @M3ConsoleBehavior=4.1 >console behavior back to "default" > - Jay> Rodney Bates Retired assistant professor Computer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jun 21 18:04:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 21 Jun 2008 16:04:27 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <485CE8D0.1E75.00D7.1@scires.com> References: <481B6AEF@webmail.wichita.edu> <485CE8D0.1E75.00D7.1@scires.com> Message-ID: 4 (compiler switch) and 5 (adapt your code) are easy enough, though 4 I have *possible* misgivings about. There is in fact an interface whose data flows like so: run the compiler it produces "startup" code (_m3main.o/_m3main.obj/_m3main.c) that startup code passes data to the runtime (RTLinker) I mucked around here to fix environment variables. The "problem" here is that compiler <=> runtime interfaces must be carefully dealt with..perhaps. I am not sure what our compatibility requires are. I don't think Modula-3 binaries are really deployed so far and wide, and old and new .dlls/.so mixed much. So probably this interface can be churned without much concern for what it was in the past. Perhaps. Whatever data flows around here should probably be a record that starts with a size and contains a "set of int" (ie: bitflags) for every field, or every field added after a certain point, and reserve enough room for there to be enough bit flags for a long time. This is a part of a path to "release to release binary compatibility". Or maybe the type fingerprints are it and there isn't really such "adaptivity" around types changing? In C and C++, it is common to runtime link where the types on either side are different, but where there is some little amount of ability to discover some aspects of the types and adapt. As stated, via a size at the start of a record and/or bitfields to indicate which fields are present. Of course, it is limited. You only ever "grow" types. You never delete or rearrange. At the very least, you need to be able to bootstrap from one version to the next. A new compiler has to work at least once against an old statically linked runtime. At the very most, new compilers have to output binaries that work with old dynamically linked runtimes. I doubt this works much really but I am curious as to everyone else's opionions and assertions. Rather than set them to nil, what about typecasing them and then replacing with a non-nil instance that ignores writes? That will save you unhandled exceptions, right? Eventually I could/would probably just sit down and solve this but I haven't had much time and have been working on other Modula-3 things -- bringing up existing/new platforms (I uploaded SOLsun archives recently, still trying to bring up gcc on Solaris (not even SOLgnu, just gcc), and lots more on the radar..), debugging the 64 bit hosted cm3cg bug(s), etc. The quake code you propose sounds trivial, yes. But lately I think more should be in cm3 and less in quake (or sh or Python). Very gradually I am folding my Python into quake and my quake into cm3. Esp. as it proves stable and useful. For example, cm3 now reveals its own platform to Quake (HOST_PLATFORM), so Quake can default to a native build, without the user telling it or it sniffing around. All the use of uname et. al. can probably go away. (see also gcc's various -print-foo switches, that let wrappers introspect about gcc already knows about the target; cm3 could perhaps use similar) My Python wrappers accept a target platform name anywhere on the command line. cm3 should probably just do that. My Quake sniffs around for a config file based on platform, next to itself or in the source tree. Cm3 should probably just do that, esp. next to itself, less clear about in the source tree. It is kind of reasonable to go around implementing things multiple times, as the initial implementations serve as prototypes to try on for size, see if they work out well. The whole mechanism where "packages" are discovered by groveling the source tree could/should probably be merged into cm3, perhaps driven by a hand authored file or files, either like Randy did for Win32, or a more hierarchical tree full of small files linking together directories, like the Windows DDK "dirs" files. - Jay Date: Sat, 21 Jun 2008 11:41:09 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Thanks Rodney and Jay for your comments. Here are a few points I'd like to add to this discussion. 1. I agree with Jay that command line arguments would be better than environment variables. 2. I agree with Rodney that the "laziness property" must be set before data gets read/written and that it should be set only once, not changed during execution. 3. A drawback to using command-line variables (and env vars) is that it shifts the responsibility from the programmer to the user. IMO, this type of behavior is something that is "designed" and documented as part of the program, so it should not be changeable by the user. For example, if the user fails to put the appropriate parameter on the command-line, the program's behavior changes. In effect, this is sort of what has happened to me, that is, the behavior of my cm3 v4.1 gui-mode program(s) has changed from its design because the underlying implementation changed to use lazy console allocation and I have no way of getting the old behavior back without changing the implementation. 4. Perhaps a better approach would be to devise a new option for the compiler. For example, "-gui" works as now and uses lazy console allocation. "-gui_no_lazy" works the way -gui did in 4.1 where the Stdio.stdin/stderr/stdout would be NIL for a gui-mode program. The problem here is I'm not sure exactly how to implement it. In effect, use of this option would mean we would need to swap (i.e., choose) the implementation of Process.m3 at compile time, OR we would need some way to ensure the Stdio variables get set to NIL after the current Process.m3 initialization (thereby undoing the lazy allocation). Maybe one of these methods can be done via quake somehow, but I'm not sure how to go about it. Any ideas? 5. If I'm the only person having this issue with the lazy allocation, perhaps I can adapt my programs. Perhaps I can just set the Stdio variables to be NIL at the beginning of my mainline code for programs I know should be compiled as -gui. This brings to mind an idea for how to implement -gui_no_lazy. Do you think we could write some quake code that causes a new module implementation to be included in the program whenever the target is NT386 AND the -gui_no_lazy option is set? This new implementation would import from Stdio and all it would do is set the Stdio vars to be NIL. Since it imports from Stdio and Stdio imports Process, I would tend to think that Process and Stdio module initializations would be run before this new module initialization thereby ensuring the lazy allocated consoles get set to NIL. What do you think? Regards, Randy>>> "rodney.bates" 6/21/2008 10:18 AM >>>I guess I am on a somewhat different wavelength on this. I doagree that a complete set of queries by the application shouldbe supported, concerning lazy allocated streams. But to me,applications need to have either very little or nothing in theway of ability to change behaviour.For one thing, it makes sense for the lazy property to applyonly to stdout/stderr, on win32 platforms, compiled as -gui.This is why I was questioning getting a stream from FileWr.Open,and then setting it lazy. Laziness doesn't make any sense ona disk file.Beyond that, I think at the most, an application should be able to change the laziness property only before any data has beenwritten to the stream. After that, the window is already popped,and the semantics would get ugly.In fact, I am very skeptical about the need for an application to change laziness at all. If it can query this property, thenit can just refrain from writing to the steam, if it doesn't wantthe window to pop up.Hence my objection to making the properties variables, not becauseof general principal, but because an application could assign tothem at any time.>===== Original Message From Jay =====>set CM3_ConsoleBehavior=4.1>m3guiapp>console behavior still changed>>m3guiapp @M3ConsoleBehavior=4.1>console behavior back to "default"> - Jay>Rodney BatesRetired assistant professorComputer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jun 21 18:17:22 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 21 Jun 2008 16:17:22 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: References: <481B6AEF@webmail.wichita.edu> <485CE8D0.1E75.00D7.1@scires.com> Message-ID: > 3. A drawback to using command-line > variables (and env vars) is that it shifts > the responsibility from the programmer to > the user. IMO, this type of behavior is something > that is "designed" and documented as part of the > program, so it should not be changeable by the user. For example, if the What is constant behavior and what is settable by the user is obviously one of the big sets of questions any programmer must face. No one behavior suits everyone, and too many configurable options are confusing and harder to test. If you make everything configurable, you just ship the consumer nothing and let him "configure" it to do what he wants. Consumer can have any color Ford Model T as long as it is black... Anyway, I think the compiler command line option is reasonable, and implementing via "customizing" main to pass down the switch to runtime, while I expressed possible misgivings about it, I think is reasonable. Adapting quake to output different modules and all that I think is overkill. The main <=> RTLinker interface should probably be a little self describing anyway. And this might be main talking right to ProcessWin32 anyway. One thing I don't understand is how much Modula-3 code can be run before RTLinker. How much runtime linking does Modula-3 do itself, vs. how much code comes in from disk already ready to run. It could, heck, be C code or data if that helped. But just as well, it could flow through RTLinker en route to ProcessWin32, if that is necessary and the C and data exports are to be avoided. RTLinker does seem to do a lot more work than is "normal", in the C build model. That is, it *appears* you can't make cross Modula-3 module calls, even within the same .so/.exe/.dll. Kind of lame if true, given that many intra-module calls are already going unnecessarily through runtime linking a the C level (that problem I hit on AMD64_LINUX where the static link gets trashed by this unnecessary indirection; as well as where I believe I have deliberately removed this unnecessary indirection in my SOLsun configuration files). (This is that simpler focused email I owe...) - Jay From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comDate: Sat, 21 Jun 2008 16:04:27 +0000Subject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! 4 (compiler switch) and 5 (adapt your code) are easy enough, though 4 I have *possible* misgivings about. There is in fact an interface whose data flows like so: run the compiler it produces "startup" code (_m3main.o/_m3main.obj/_m3main.c) that startup code passes data to the runtime (RTLinker) I mucked around here to fix environment variables. The "problem" here is that compiler <=> runtime interfaces must be carefully dealt with..perhaps.I am not sure what our compatibility requires are. I don't think Modula-3 binaries are really deployed so far and wide, and old and new .dlls/.so mixed much. So probably this interface can be churned without much concern for what it was in the past. Perhaps. Whatever data flows around here should probably be a record that starts with a size and contains a "set of int" (ie: bitflags) for every field, or every field added after a certain point, and reserve enough room for there to be enough bit flags for a long time. This is a part of a path to "release to release binary compatibility". Or maybe the type fingerprints are it and there isn't really such "adaptivity" around types changing? In C and C++, it is common to runtime link where the types on either side are different, but where there is some little amount of ability to discover some aspects of the types and adapt. As stated, via a size at the start of a record and/or bitfields to indicate which fields are present. Of course, it is limited. You only ever "grow" types. You never delete or rearrange. At the very least, you need to be able to bootstrap from one version to the next.A new compiler has to work at least once against an old statically linked runtime. At the very most, new compilers have to output binaries that work with old dynamically linked runtimes. I doubt this works much really but I am curious as to everyone else's opionions and assertions. Rather than set them to nil, what about typecasing them and then replacing with a non-nil instance that ignores writes? That will save you unhandled exceptions, right? Eventually I could/would probably just sit down and solve this but I haven't had much time and have been working on other Modula-3 things -- bringing up existing/new platforms (I uploaded SOLsun archives recently, still trying to bring up gcc on Solaris (not even SOLgnu, just gcc), and lots more on the radar..), debugging the 64 bit hosted cm3cg bug(s), etc. The quake code you propose sounds trivial, yes.But lately I think more should be in cm3 and less in quake (or sh or Python).Very gradually I am folding my Python into quake and my quake into cm3. Esp. as it proves stable and useful.For example, cm3 now reveals its own platform to Quake (HOST_PLATFORM), so Quake can default to a native build, without the user telling it or it sniffing around. All the use of uname et. al. can probably go away. (see also gcc's various -print-foo switches, that let wrappers introspect about gcc already knows about the target; cm3 could perhaps use similar) My Python wrappers accept a target platform name anywhere on the command line. cm3 should probably just do that. My Quake sniffs around for a config file based on platform, next to itself or in the source tree. Cm3 should probably just do that, esp. next to itself, less clear about in the source tree. It is kind of reasonable to go around implementing things multiple times, as the initial implementations serve as prototypes to try on for size, see if they work out well. The whole mechanism where "packages" are discovered by groveling the source tree could/should probably be merged into cm3, perhaps driven by a hand authored file or files, either like Randy did for Win32, or a more hierarchical tree full of small files linking together directories, like the Windows DDK "dirs" files. - Jay Date: Sat, 21 Jun 2008 11:41:09 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Thanks Rodney and Jay for your comments. Here are a few points I'd like to add to this discussion. 1. I agree with Jay that command line arguments would be better than environment variables. 2. I agree with Rodney that the "laziness property" must be set before data gets read/written and that it should be set only once, not changed during execution. 3. A drawback to using command-line variables (and env vars) is that it shifts the responsibility from the programmer to the user. IMO, this type of behavior is something that is "designed" and documented as part of the program, so it should not be changeable by the user. For example, if the user fails to put the appropriate parameter on the command-line, the program's behavior changes. In effect, this is sort of what has happened to me, that is, the behavior of my cm3 v4.1 gui-mode program(s) has changed from its design because the underlying implementation changed to use lazy console allocation and I have no way of getting the old behavior back without changing the implementation. 4. Perhaps a better approach would be to devise a new option for the compiler. For example, "-gui" works as now and uses lazy console allocation. "-gui_no_lazy" works the way -gui did in 4.1 where the Stdio.stdin/stderr/stdout would be NIL for a gui-mode program. The problem here is I'm not sure exactly how to implement it. In effect, use of this option would mean we would need to swap (i.e., choose) the implementation of Process.m3 at compile time, OR we would need some way to ensure the Stdio variables get set to NIL after the current Process.m3 initialization (thereby undoing the lazy allocation). Maybe one of these methods can be done via quake somehow, but I'm not sure how to go about it. Any ideas? 5. If I'm the only person having this issue with the lazy allocation, perhaps I can adapt my programs. Perhaps I can just set the Stdio variables to be NIL at the beginning of my mainline code for programs I know should be compiled as -gui. This brings to mind an idea for how to implement -gui_no_lazy. Do you think we could write some quake code that causes a new module implementation to be included in the program whenever the target is NT386 AND the -gui_no_lazy option is set? This new implementation would import from Stdio and all it would do is set the Stdio vars to be NIL. Since it imports from Stdio and Stdio imports Process, I would tend to think that Process and Stdio module initializations would be run before this new module initialization thereby ensuring the lazy allocated consoles get set to NIL. What do you think? Regards, Randy>>> "rodney.bates" 6/21/2008 10:18 AM >>>I guess I am on a somewhat different wavelength on this. I doagree that a complete set of queries by the application shouldbe supported, concerning lazy allocated streams. But to me,applications need to have either very little or nothing in theway of ability to change behaviour.For one thing, it makes sense for the lazy property to applyonly to stdout/stderr, on win32 platforms, compiled as -gui.This is why I was questioning getting a stream from FileWr.Open,and then setting it lazy. Laziness doesn't make any sense ona disk file.Beyond that, I think at the most, an application should be able to change the laziness property only before any data has beenwritten to the stream. After that, the window is already popped,and the semantics would get ugly.In fact, I am very skeptical about the need for an application to change laziness at all. If it can query this property, thenit can just refrain from writing to the steam, if it doesn't wantthe window to pop up.Hence my objection to making the properties variables, not becauseof general principal, but because an application could assign tothem at any time.>===== Original Message From Jay =====>set CM3_ConsoleBehavior=4.1>m3guiapp>console behavior still changed>>m3guiapp @M3ConsoleBehavior=4.1>console behavior back to "default"> - Jay>Rodney BatesRetired assistant professorComputer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Jun 23 20:10:15 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 23 Jun 2008 14:10:15 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080621041535.A19F910D425E@birch.elegosoft.com> Message-ID: <485FAEC0.1E75.00D7.1@scires.com> Hi Henning: Not sure about any "good style rules" here. I am not aware of breaking any rules. PDF is a fairly universal format. These PDF documents provide the user's guide for the CM3-IDE package. The PDF files were created by printing a Microsoft Word document to the free pdf995 driver from Software995.com. I have provided the original Microsoft Word .DOC file in the repository as well, so if anyone wants to convert to a different format, you have the original source. Regards, Randy >>> Henning Thielemann 6/22/2008 4:34 PM >>> On Sat, 21 Jun 2008, Randy Coleburn wrote: > CVSROOT:/usr/cvs > Changes by:rcoleburn at birch.08/06/21 06:15:35 > > Added files: > cm3/doc/help/CM3_IDE/: basics.pdf beyond-basics.pdf > customization.pdf environment.pdf > index.html interface-index.pdf intro.pdf > more-info.pdf packages.pdf recipes.pdf > user-guide.pdf I thought it is not good style to put machine generated files, and especially binary files, to CVS repositories. Are the PDF files made from TeX? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Jun 23 21:01:58 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 23 Jun 2008 21:01:58 +0200 (CEST) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <485FAEC0.1E75.00D7.1@scires.com> References: <20080621041535.A19F910D425E@birch.elegosoft.com> <485FAEC0.1E75.00D7.1@scires.com> Message-ID: On Mon, 23 Jun 2008, Randy Coleburn wrote: > The PDF files were created by printing a Microsoft Word document to the > free pdf995 driver from Software995.com. > > I have provided the original Microsoft Word .DOC file in the repository I see. Then there is certainly no better way. From dragisha at m3w.org Fri Jun 27 15:59:15 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Jun 2008 15:59:15 +0200 Subject: [M3devel] LongSqrt.Sqrt... Message-ID: <1214575155.32091.3.camel@faramir.m3w.org> does not work for LINUXLIBC6... Or I am just missing some voodoo precondition? :) TIA -- Dragi?a Duri? From jayk123 at hotmail.com Sun Jun 1 03:40:42 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 1 Jun 2008 01:40:42 +0000 Subject: [M3devel] function pointers and comparison to nil? mis-typed function pointers? In-Reply-To: <20080531132924.GA30413@topoi.pooq.com> References: <483862F4.1E75.00D7.1@scires.com> <483A3377.7070801@wichita.edu> <48408AEE.8090405@wichita.edu> <20080531132924.GA30413@topoi.pooq.com> Message-ID: > In Modula-3, you can pass any procedure but only assign a top-level procedure. > This precludes dangling environments in yet another way, that is more liberal > than either Pascal or Modula-2,, but requires a runtime check on procedure I don't understand "can only assign a top-level procedure". My understanding is that Modula-3 does allow the "unsafe" option -- take the address of a nested function, pass it off to some code, that stores it in a global, and call it later. But of course, "Modula-3 does allow the unsafe option" does not compute. I need to read up and experiment. Maybe there is a runtime check whenever I assign a function pointer to either a global or to a field in non-local record, that it isn't a closure? That makes a fair amount of sense though hard to not make the check overly strict I think. Rodney my "problem" with your analysis is it mostly "pretends" that each language is its own independent environment. In present reality at least, Modula-3 and C interoperate a lot. That is largely a good thing. It does place restrictions on Modula-3 implementations however. Pointers to top-level Modula-3 functions can be passed to C and treated as pointers to C functions. Pointers to C functions, including gcc nested functions, can be passed to Modula-3 code as pointers. There are not separate types for pointers to C vs. Modula-3 functions. Pointers to nested Modula-3 functions cannot be passed to C code and treated as C function pointers, though enabling this, with the programmer required to notice the situation and change the code slightly, is easy enough. The compiler might also be able to recognize it and possibly error, at least if "extern" is presumed to be C, though of course..insert one level of Modula-3 code between "taking the address" and "passing it to C", and it becomes more difficult..but maybe still quite easy. If the whole world was Modula-3, then you could just change the representation of all function pointers and how they are called. The strategy of optionally heap allocated frames -- when the address is taken of a nested function -- does kill multiple birds with one expensive stone. - ability to pass function pointers to nested functions to C code, and store them anywhere - ability to call nested functions after their caller has returned - remove the check for the -1 marker which might possibly maybe just barely be unportable, and also slows down/bloats calls to function pointers (but at the cost of probably a more sever slow down) - avoid the use of generated code on the stack - still need to ensure the heap is executable but that's less of a problem, Windows for example at least exposes the ability to make the heap executable, besides the strategy of using VirtualAlloc. However it slows down existing code. Depending on which of these features is desirable, if in fact any at all, there are other options. - leave it all alone (but continue talking about it :) ) - put the code on the stack and call mprotect/VirtualProtect, as OpenBSD does for gcc nested functions - Jay > Date: Sat, 31 May 2008 09:29:24 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > On Fri, May 30, 2008 at 06:17:02PM -0500, Rodney M. Bates wrote:> > > > My one handy Algol68 book has the usual tutorial language book problem: it> > omits the cases you really need to look up. It only states that there will> > be problems if you use a dangling environment, but not whether the language> > specifies this should be detected by the language, or whether "all hell will> > break loose." I'm guessing it's the latter. The implementation technique> > Hendrik describes makes it a detected runtime error, but not unless/until> > you try to use the lost environment. This is more generous than Modula-3's > > rule.> > The actual Algol 68 definition does pronounce on this. The CDC > implementation was much more liberal than the language definition.> > Every reference/variable and every procedure has a scope. The scope of > a variable is the level on the run-time stack at which it is allocated. > Variables can be on the heap; this is global scope. The scope of a > procedure is the stack elvel at which its most local global identifier > is bound. Even if the identifier refers to an object on the heap, it is > the level at which it is bound that counts.> > There is a universal scope restriction: No object can refer to a more > local object. The constraint in the language definition is applied on > assignment.> > I know of no Algol 68 implementation that I can say for sure implements > this restriction with a run-time check. Of course it can be done, > either by tagging each pointer with an explicit mention of its stack > level (which takes space) or by comparing its value and comparing it to > various stack locations in a kind of search.> > The first release of the CDC algol 68 compiler just allocated all > variables on the heap, making the check unnecessary for safety. > Programmers almost never wrote code that passed procedures out-of-scope.> > Later releases performed static analysis to determine where it was safe > to allocate in the stack (almost all the time), and used the mechanism I > described earlier to check procedures when they were called if the > static check didn't suffice..> > > > And, of course, if your language is really dynamic, it could just say an> > environment is always accessible, requiring many or all activation records> > to be heap allocated.> > Which was a proposal made for the original Algol 68, but was turned > down. I think it should have been accepted. We would have had a > strongly-typed Scheme ahead of its time.> > -- hendrik> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Sun Jun 1 04:32:37 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 31 May 2008 21:32:37 -0500 Subject: [M3devel] function pointers and comparison to nil? mis-typed function pointers? In-Reply-To: References: <483862F4.1E75.00D7.1@scires.com> <483A3377.7070801@wichita.edu> <48408AEE.8090405@wichita.edu> <20080531132924.GA30413@topoi.pooq.com> Message-ID: <48420A45.6070401@wichita.edu> Jay wrote: > > I don't understand "can only assign a top-level procedure". > My understanding is that Modula-3 does allow the "unsafe" option -- take > the address of a nested function, pass it off to some code, that stores > it in a global, and call it later. But of course, "Modula-3 does allow > the unsafe option" does not compute. I need to read up and experiment. No, Modula-3 does not allow the above. The only thing you can do with a nested procedure is pass it as a parameter. The lifetime of the parameter will always lie within the lifetime of the current activation of the the nested procedure, so this is safe. If you try to assign a procedure to a variable/field/array-element, the language says the procedure value must be top-level. (See 2.3.1, assignability of an expression to a variable, second condition.) This is also safe. If the RHS of the assignment is a procedure constant, this can be checked statically. If the RHS is a formal parameter (thus variable at runtime), this must be a runtime check, because its value could be a nested procedure. The compiler implements the RT check by checking whether the pointer points to a closure or not, or rather, whether it points to a closure flag word. This implementation choice of representation of procedure values correctly implements the language, while still making global procedure values have the same representation as C pointers to (global) functions. > > Maybe there is a runtime check whenever I assign a function pointer to > either a global or to a field in non-local record, that it isn't a closure? > That makes a fair amount of sense though hard to not make the check > overly strict I think. Yes, this is not the loosest safe rule. Hardly anything is, in a safe language. The language designers have to make careful tradeoffs among programmer freedom, efficient implementability, and language simplicity. This is just the way Modula-3 makes the tradeoff to prevent dangling environment pointer bugs from happening. > >-- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jayk123 at hotmail.com Sun Jun 1 04:32:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 1 Jun 2008 02:32:27 +0000 Subject: [M3devel] proposal/insistence for fixed size integer types in Ctypes.i3 Message-ID: Currently the various Utypes.i3 introduce various types LIKE uint8_t = unsigned_char; uint16_t = unsigned_short; uint32_t = unsigned_int; uint64_t = unsigned_long_long; int8_t = signed_char; int16_t = short; int32_t = int; int64_t = long_long; sometimes there is an underscore after the u. There is quite some variation in which, if any, of these types are provided. When they are provided, they are always the same, with one exception I will detail. Arguably they are provided only for defining other types and function signatures within m3-libs/m3core/src/unix. I strongly strongly strongly propose that at least the above 8 types go in Ctypes, and the definitions in Utypes removed. If there was more commonality in Utypes, I'd "forward" them for compatibility, but there is little commonality. Code depending on these types would have to be forked a lot. As I said, the types are always the same, if they are defined, but they are often not defined. One variation I am open to is introducing a new .i3 file. But in general I like to colocate stuff rather than pick apart everything and decide an ideal location. There are tradeoffs either way, though most people only see the tradeoffs in the way I do it. The tradeoffs the other way are having to track down module after module, interface after interface, where to get stuff from, rather than having a "one stop shop", or "fewer shops to stop". I am also willing to have u_* types and CAPITALIZED types: uint8_t = unsigned_char; uint16_t = unsigned_short; uint32_t = unsigned_int; uint64_t = unsigned_long_long; int8_t = signed_char; int16_t = short; int32_t = int; int64_t = long_long; u_int8_t = uint8_t; u_int16_t = uint16_t; u_int32_t = uint32_t; u_int64_t = uint64_t; UINT8 = uint8_t; UINT16 = uint16_t; UINT32 = uint32_t; UINT64 = uint64_t; INT8 = int8_t; INT16 = int16_t; INT32 = int32_t; INT64 = int64_t; All built-in Modula-3 types are capitalized, as all Modula-3 keywords are. And capitalized types is a style widely used in the Windows headers. (Windows and Modula-3 share a common heritage -- Digital -- though I don't know from where the style of capitalized types originates.) The names "int8", "int16" are also obvious candidates, but I feel that some amount of typographical convention should be used to demark types. Some amount of "Hungarian", if you will. Obviously there are vehement opposing opinions on this. "Hungarian" is often too precise and precludes changing types without changing names, as well as producing unpronouncable names. A "weak" form however seems reasonable and useful. These types represent a certain point of view. It is a common point of view, but not universal. There are roughly three or four perspectives here: 1) char, short, int, long are abstractly defined and all code should live with it. char is at least 8 bits, and of unspecified signedness (limits.h defines CHAR_BIT, the number of bits in char for specified signedness, use signed char or unsigned char; I think char has actually three options for its signess -- signed, unsigned, or "half unsigned") short is at least 16 bits, signed int is at least 16 bits, signed long is at least 32 bits, signed There are not necessarily integral types that can hold pointers. size_t and ptrdiff_t perhaps, but unclear. size_t can hold the size of anything, but I think "anything" is "any variable" and not necessarily "the entire address space". ptrdiff_t can hold the result of subtracting pointers, but it is only valid to subtract pointers that point into the same array or just past it. It is common, for example, but not universal, for the "address space" to be divided between "user mode" and "kernel mode", often with a 50/50 split, so therefore size_t could be one bit smaller than a pointer, at least. Of course that's an "unnatural" size, but theoretically possible. (This kernel/user 50/50 split is usually exactly how 32 bit and I assume 64 bit Windows works, though 32 bit Windows can also have a 3 gig / 1 gig split, and 32 bit Windows code running on 64 bit Windows kernel can get a full 4 gig address space.) As well, the representation of signed integers is left unspecified. The range of "int" need only go down to -32767, not necessarily -32768. Signed magnitude and one's complement are valid representations. Overflowing a signed integer causes undefined behavior. Unsigned numbers do not have this abstraction. While this is the "most correct" view, according to (my understanding) the C standard, implementations do nail down details way beyond this, and a lot of code depends on these details. While I may have some of those details slightly wrong, you get the point. You CAN write code within this interface, but a lot of code violates it, sometimes by accident, sometimes for important practical reasons. Some amount of code assumes an int is at least or exactly 32 bits. Some amount of code assumes int or long can hold a pointer, though int probably not so much, and long probably of proportionally rapidly decreasing instance due to Win64. 2) char, short, int, long are somewhat abstractly defined char is exactly 8 bits varying perspectives on its presumed signedness short is exactly 16 bits int is exactly 32 bits long there are few perspectives on; it is exactly 32 bits ("Windows"), or it is exactly the size of a pointer ("Unix"), or it is at least the size of a pointer As well, two's complement is the only representation of signed numbers in use, and code depends on this. (I recently read that we can thank the IBM S/360 or such, in the 1960's, for introducing such modern-day architectural features that everyone takes for granted as an 8 bit byte and two's complement signed numbers.) If you need an integer with a particular exact size, either use char/short/int directly, or run them through "autoconf", or sniff "limits.h". 3) This is my recently acquired perspective, but it isn't new. Given that #1 is "correct but rare", and that #2 are full of "exact": char, short, int, long are funny names with not particularly useful specifications. #2 is a little sleazy (less so if autoconfed/limits.h) Unless you are really adhering to the strict spec, don't use them. If you are in fact indexing a "small" array, they might suffice, but is it worth it? worth having these types? Theory: 16 bit machines are irrelevant and 32 bit integers are perfectly efficient on 64 bit machines, and 64 bit integers are universally available (?) and reasonably efficient (?), so feel free to use them if there is a need. As well, 4gig remains a large capacity in most contexts, so feel free to use explictly 32 bit integers. However file sizes and offsets should really always be 64 bits. Any code still requiring 32 bit file offsets/sizes is unfortunate. That includes PE32+ imho, the file format for .exes/.dlls on Win64. Be clear and unsleazy and adopt new names that represent well their specification and actual use. int_t is exactly n bits in size and signed uint_t is exactly n bits in size and unsigned some names are chosen for unsigned and signed integers with the exact size of a pointer For n=8,16,32 all four types exist, and probably 64. And pointer-sized types exist. If you really feel your capacity limits should scale with address space size, or need to store a pointer in an integer, use size_t or uintptr_t or intptr_t, etc. Modula-3's position here adds that INTEGER is the exact size of a pointer and signed. It is identical to ptrdiff_t or intptr_t. CARDINAL is the exact size but omits the bottom "half" of the range, and does not, I believe, extend the top "half". Now, I also realize, that m3-libs/m3core/src/unix is a fairly mechanical translation of /usr/include, and /usr/include does not necessarily take perspective #3. So the "funny" names are useful for a human mechanical translation. But the precise names can still be used instead. Here is an exception I said I would detail: irix-5.2/utypes.i3: int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END; uint64_t = int64_t; This is different in at least two ways that I see. - default initialization to zero - 32 bit alignment instead of 64 bit alignment I tend to assume that the alignment is actually wrong, however all the uses in Usignal appear unaffected, as they are always preceded by a mix of int64_t and an even number of int32. Either way, it is easy enough to preserve this for compatibility. I would like to continue, where easy and clear, to reduce the "size" of m3-libs/m3core/src/unix. Making these types portable available helps that. For example -- Uin.m3 need not be duplicated at all. But then it either must use the presently more portable unsigned_short and unsigned, or uint16_t and uint32_t should be made always available, either by adding them to all the various Utypes.i3, or the one Ctypes.i3, or a new place. Darwin currently has four Upthread.i3 files (one is dead), but needs either only two, or one with the sizes abstracted out. I don't know if PPC64_DARWIN will needs its own yet, I don't have one of these machines yet. I would like to go ahead with this stuff *today*. It takes some exertion of patience for me to stop and send this first. :) - Jay From jayk123 at hotmail.com Sun Jun 1 04:35:40 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 1 Jun 2008 02:35:40 +0000 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 Message-ID: So much for trying plain text to avoid truncation, darnit.> From: jayk123 at hotmail.com> To: m3devel at elegosoft.com> Subject: proposal/insistence for fixed size integer types in Ctypes.i3> Date: Sun, 1 Jun 2008 02:32:27 +0000> > > > Currently the various Utypes.i3 introduce various types LIKE> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > sometimes there is an underscore after the u.> > > There is quite some variation in which, if any, of these types are provided.> When they are provided, they are always the same, with one exception I will detail.> > > Arguably they are provided only for defining other types and function signatures> within m3-libs/m3core/src/unix.> > > I strongly strongly strongly propose that at least the above 8 types go in> Ctypes, and the definitions in Utypes removed.> > > If there was more commonality in Utypes, I'd "forward" them for compatibility,> but there is little commonality. Code depending on these types would have to> be forked a lot. As I said, the types are always the same, if they are defined,> but they are often not defined.> > > One variation I am open to is introducing a new .i3 file.> But in general I like to colocate stuff rather than pick apart everything> and decide an ideal location. There are tradeoffs either way,> though most people only see the tradeoffs in the way I do it.> The tradeoffs the other way are having to track down module after module,> interface after interface, where to get stuff from, rather than having> a "one stop shop", or "fewer shops to stop".> > > I am also willing to have u_* types and CAPITALIZED types:> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > u_int8_t = uint8_t;> u_int16_t = uint16_t;> u_int32_t = uint32_t;> u_int64_t = uint64_t;> > > UINT8 = uint8_t;> UINT16 = uint16_t;> UINT32 = uint32_t;> UINT64 = uint64_t;> > > INT8 = int8_t;> INT16 = int16_t;> INT32 = int32_t;> INT64 = int64_t;> > > All built-in Modula-3 types are capitalized, as all Modula-3 keywords are.> And capitalized types is a style widely used in the Windows headers.> (Windows and Modula-3 share a common heritage -- Digital -- though I don't know> from where the style of capitalized types originates.)> > > The names "int8", "int16" are also obvious candidates, but I feel that some> amount of typographical convention should be used to demark types.> Some amount of "Hungarian", if you will.> Obviously there are vehement opposing opinions on this.> "Hungarian" is often too precise and precludes changing types without> changing names, as well as producing unpronouncable names.> A "weak" form however seems reasonable and useful.> > > These types represent a certain point of view.> It is a common point of view, but not universal.> > > There are roughly three or four perspectives here:> > > 1)> char, short, int, long are abstractly defined and all code should live with it.> char is at least 8 bits, and of unspecified signedness> (limits.h defines CHAR_BIT, the number of bits in char> for specified signedness, use signed char or unsigned char;> I think char has actually three options for its signess -- signed, unsigned, or "half unsigned")> short is at least 16 bits, signed> int is at least 16 bits, signed> long is at least 32 bits, signed> > > There are not necessarily integral types that can hold pointers.> size_t and ptrdiff_t perhaps, but unclear.> size_t can hold the size of anything, but I think "anything" is "any variable"> and not necessarily "the entire address space".> > > ptrdiff_t can hold the result of subtracting pointers, but it is only> valid to subtract pointers that point into the same array or just past it.> > > It is common, for example, but not universal, for the "address space"> to be divided between "user mode" and "kernel mode", often with a 50/50 split,> so therefore size_t could be one bit smaller than a pointer, at least.> Of course that's an "unnatural" size, but theoretically possible.> (This kernel/user 50/50 split is usually exactly how 32 bit and I assume> 64 bit Windows works, though 32 bit Windows can also have a 3 gig / 1 gig split,> and 32 bit Windows code running on 64 bit Windows kernel can get a> full 4 gig address space.)> > > As well, the representation of signed integers is left unspecified.> The range of "int" need only go down to -32767, not necessarily -32768.> Signed magnitude and one's complement are valid representations.> Overflowing a signed integer causes undefined behavior.> Unsigned numbers do not have this abstraction.> > > While this is the "most correct" view, according to (my understanding) the C standard,> implementations do nail down details way beyond this, and a lot of> code depends on these details.> > > While I may have some of those details slightly wrong, you get the point.> You CAN write code within this interface, but a lot of code violates it, sometimes> > > by accident, sometimes for important practical reasons.> Some amount of code assumes an int is at least or exactly 32 bits.> Some amount of code assumes int or long can hold a pointer, though> int probably not so much, and long probably of proportionally> rapidly decreasing instance due to Win64.> > > > 2)> char, short, int, long are somewhat abstractly defined> char is exactly 8 bits> varying perspectives on its presumed signedness> short is exactly 16 bits> int is exactly 32 bits> long there are few perspectives on; it is exactly 32 bits ("Windows"), or> it is exactly the size of a pointer ("Unix"), or it is at least> the size of a pointer> > > As well, two's complement is the only representation of signed numbers> in use, and code depends on this.> > > (I recently read that we can thank the IBM S/360 or such, in the 1960's,> for introducing such modern-day architectural features that everyone> takes for granted as an 8 bit byte and two's complement signed numbers.)> > > If you need an integer with a particular exact size, either use char/short/int directly,> or run them through "autoconf", or sniff "limits.h".> > > 3) This is my recently acquired perspective, but it isn't new.> > > Given that #1 is "correct but rare", and that #2 are> full of "exact":> > > char, short, int, long are funny names with not particularly> useful specifications. #2 is a little sleazy (less so if autoconfed/limits.h)> Unless you are really adhering to the strict spec, don't use them.> If you are in fact indexing a "small" array, they might suffice,> but is it worth it? worth having these types?> > > Theory: 16 bit machines are irrelevant and 32 bit integers> are perfectly efficient on 64 bit machines, and 64 bit integers> are universally available (?) and reasonably efficient (?),> so feel free to use them if there is a need.> > > As well, 4gig remains a large capacity in most contexts, so feel> free to use explictly 32 bit integers.> > > However file sizes and offsets should really always be 64 bits.> Any code still requiring 32 bit file offsets/sizes is unfortunate.> That includes PE32+ imho, the file format for .exes/.dlls on Win64.> > > Be clear and unsleazy and adopt new names that represent well> their specification and actual use.> > > int_t is exactly n bits in size and signed> uint_t is exactly n bits in size and unsigned> some names are chosen for unsigned and signed integers with> the exact size of a pointer> For n=8,16,32 all four types exist, and probably 64.> And pointer-sized types exist.> > > If you really feel your capacity limits should scale with address space size, or need> to store a pointer in an integer, use size_t or uintptr_t or intptr_t, etc.> > > Modula-3's position here adds that INTEGER is the exact> size of a pointer and signed. It is identical to ptrdiff_t> or intptr_t. CARDINAL is the exact size but omits the bottom "half"> of the range, and does not, I believe, extend the top "half".> > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly mechanical> translation of /usr/include, and /usr/include does not necessarily> take perspective #3. So the "funny" names are useful for a human> mechanical translation. But the precise names can still be used instead.> > > Here is an exception I said I would detail:> > > irix-5.2/utypes.i3:> int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END;> uint64_t = int64_t;> > > This is different in at least two ways that I see.> - default initialization to zero> - 32 bit alignment instead of 64 bit alignment> > > I tend to assume that the alignment is actually wrong,> however all the uses in Usignal appear unaffected, as they are always preceded> by a mix of int64_t and an even number of int32.> Either way, it is easy enough to preserve this for compatibility.> > > I would like to continue, where easy and clear, to reduce the "size" of m3-libs/m3core/src/unix.> Making these types portable available helps that.> For example -- Uin.m3 need not be duplicated at all.> But then it either must use the presently more portable unsigned_short and unsigned,> or uint16_t and uint32_t should be made always available, either by adding them> to all the various Utypes.i3, or the one Ctypes.i3, or a new place.> > > Darwin currently has four Upthread.i3 files (one is dead), but needs either only two, or one> with the sizes abstracted out. I don't know if PPC64_DARWIN will needs its own yet,> I don't have one of these machines yet.> > > I would like to go ahead with this stuff *today*.> It takes some exertion of patience for me to stop and send this first. :)> > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Jun 1 20:57:56 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 01 Jun 2008 11:57:56 -0700 Subject: [M3devel] function pointers and comparison to nil? mis-typed function pointers? In-Reply-To: Your message of "Sun, 01 Jun 2008 01:40:42 -0000." Message-ID: <200806011857.m51Ivu2X045935@camembert.async.caltech.edu> Jay writes: >--_c746a382-25b6-4547-9df2-927b317b6eab_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > In Modula-3, you can pass any procedure but only assign a top-level proc= >edure. > This precludes dangling environments in yet another way, that is m= >ore liberal > than either Pascal or Modula-2,, but requires a runtime check= > on procedure >I don't understand "can only assign a top-level procedure". >My understanding is that Modula-3 does allow the "unsafe" option -- take th= >e address of a nested function, pass it off to some code, that stores it in= > a global, and call it later. But of course, "Modula-3 does allow the unsaf= >e option" does not compute. I need to read up and experiment. >=20 >Maybe there is a runtime check whenever I assign a function pointer to eith= >er a global or to a field in non-local record, that it isn't a closure? >That makes a fair amount of sense though hard to not make the check overly = >strict I think. >=20 Jay, surely you remember that: "A procedure is either NIL or a triple consisting of: * the body, which is a statement, * the signature, ... * the environment, which is the scope with respect to which variable names in the body will be interpreted. A top-level procedure is a procedure declared in the outermost scope of a module. Any other procedure is a local procedure. A local procedure can be passed as a parameter but not assigned, since in a stack implementation a local procedure becomes invalid when the frame for the procedure containing it is popped. ... " The "since in a stack implementation..." clause seems superfluous to me, but I suppose it might be helpful for those who simply must think in terms of a specific implementation. From hosking at cs.purdue.edu Mon Jun 2 11:23:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jun 2008 10:23:44 +0100 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: References: Message-ID: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Are these types defined by the C standard. If not then they don't belong in Ctypes. If they are only defined by their particular platform then they do belong in Utypes. On Jun 1, 2008, at 3:35 AM, Jay wrote: > So much for trying plain text to avoid truncation, darnit. > > > > > From: jayk123 at hotmail.com > > To: m3devel at elegosoft.com > > Subject: proposal/insistence for fixed size integer types in > Ctypes.i3 > > Date: Sun, 1 Jun 2008 02:32:27 +0000 > > > > > > > > Currently the various Utypes.i3 introduce various types LIKE > > > > > > uint8_t = unsigned_char; > > uint16_t = unsigned_short; > > uint32_t = unsigned_int; > > uint64_t = unsigned_long_long; > > > > > > int8_t = signed_char; > > int16_t = short; > > int32_t = int; > > int64_t = long_long; > > > > > > sometimes there is an underscore after the u. > > > > > > There is quite some variation in which, if any, of these types are > provided. > > When they are provided, they are always the same, with one > exception I will detail. > > > > > > Arguably they are provided only for defining other types and > function signatures > > within m3-libs/m3core/src/unix. > > > > > > I strongly strongly strongly propose that at least the above 8 > types go in > > Ctypes, and the definitions in Utypes removed. > > > > > > If there was more commonality in Utypes, I'd "forward" them for > compatibility, > > but there is little commonality. Code depending on these types > would have to > > be forked a lot. As I said, the types are always the same, if they > are defined, > > but they are often not defined. > > > > > > One variation I am open to is introducing a new .i3 file. > > But in general I like to colocate stuff rather than pick apart > everything > > and decide an ideal location. There are tradeoffs either way, > > though most people only see the tradeoffs in the way I do it. > > The tradeoffs the other way are having to track down module after > module, > > interface after interface, where to get stuff from, rather than > having > > a "one stop shop", or "fewer shops to stop". > > > > > > I am also willing to have u_* types and CAPITALIZED types: > > > > > > uint8_t = unsigned_char; > > uint16_t = unsigned_short; > > uint32_t = unsigned_int; > > uint64_t = unsigned_long_long; > > > > > > int8_t = signed_char; > > int16_t = short; > > int32_t = int; > > int64_t = long_long; > > > > > > u_int8_t = uint8_t; > > u_int16_t = uint16_t; > > u_int32_t = uint32_t; > > u_int64_t = uint64_t; > > > > > > UINT8 = uint8_t; > > UINT16 = uint16_t; > > UINT32 = uint32_t; > > UINT64 = uint64_t; > > > > > > INT8 = int8_t; > > INT16 = int16_t; > > INT32 = int32_t; > > INT64 = int64_t; > > > > > > All built-in Modula-3 types are capitalized, as all Modula-3 > keywords are. > > And capitalized types is a style widely used in the Windows headers. > > (Windows and Modula-3 share a common heritage -- Digital -- though > I don't know > > from where the style of capitalized types originates.) > > > > > > The names "int8", "int16" are also obvious candidates, but I feel > that some > > amount of typographical convention should be used to demark types. > > Some amount of "Hungarian", if you will. > > Obviously there are vehement opposing opinions on this. > > "Hungarian" is often too precise and precludes changing types > without > > changing names, as well as producing unpronouncable names. > > A "weak" form however seems reasonable and useful. > > > > > > These types represent a certain point of view. > > It is a common point of view, but not universal. > > > > > > There are roughly three or four perspectives here: > > > > > > 1) > > char, short, int, long are abstractly defined and all code should > live with it. > > char is at least 8 bits, and of unspecified signedness > > (limits.h defines CHAR_BIT, the number of bits in char > > for specified signedness, use signed char or unsigned char; > > I think char has actually three options for its signess -- signed, > unsigned, or "half unsigned") > > short is at least 16 bits, signed > > int is at least 16 bits, signed > > long is at least 32 bits, signed > > > > > > There are not necessarily integral types that can hold pointers. > > size_t and ptrdiff_t perhaps, but unclear. > > size_t can hold the size of anything, but I think "anything" is > "any variable" > > and not necessarily "the entire address space". > > > > > > ptrdiff_t can hold the result of subtracting pointers, but it is > only > > valid to subtract pointers that point into the same array or just > past it. > > > > > > It is common, for example, but not universal, for the "address > space" > > to be divided between "user mode" and "kernel mode", often with a > 50/50 split, > > so therefore size_t could be one bit smaller than a pointer, at > least. > > Of course that's an "unnatural" size, but theoretically possible. > > (This kernel/user 50/50 split is usually exactly how 32 bit and I > assume > > 64 bit Windows works, though 32 bit Windows can also have a 3 > gig / 1 gig split, > > and 32 bit Windows code running on 64 bit Windows kernel can get a > > full 4 gig address space.) > > > > > > As well, the representation of signed integers is left unspecified. > > The range of "int" need only go down to -32767, not necessarily > -32768. > > Signed magnitude and one's complement are valid representations. > > Overflowing a signed integer causes undefined behavior. > > Unsigned numbers do not have this abstraction. > > > > > > While this is the "most correct" view, according to (my > understanding) the C standard, > > implementations do nail down details way beyond this, and a lot of > > code depends on these details. > > > > > > While I may have some of those details slightly wrong, you get the > point. > > You CAN write code within this interface, but a lot of code > violates it, sometimes > > > > > > by accident, sometimes for important practical reasons. > > Some amount of code assumes an int is at least or exactly 32 bits. > > Some amount of code assumes int or long can hold a pointer, though > > int probably not so much, and long probably of proportionally > > rapidly decreasing instance due to Win64. > > > > > > > > 2) > > char, short, int, long are somewhat abstractly defined > > char is exactly 8 bits > > varying perspectives on its presumed signedness > > short is exactly 16 bits > > int is exactly 32 bits > > long there are few perspectives on; it is exactly 32 bits > ("Windows"), or > > it is exactly the size of a pointer ("Unix"), or it is at least > > the size of a pointer > > > > > > As well, two's complement is the only representation of signed > numbers > > in use, and code depends on this. > > > > > > (I recently read that we can thank the IBM S/360 or such, in the > 1960's, > > for introducing such modern-day architectural features that everyone > > takes for granted as an 8 bit byte and two's complement signed > numbers.) > > > > > > If you need an integer with a particular exact size, either use > char/short/int directly, > > or run them through "autoconf", or sniff "limits.h". > > > > > > 3) This is my recently acquired perspective, but it isn't new. > > > > > > Given that #1 is "correct but rare", and that #2 are > > full of "exact": > > > > > > char, short, int, long are funny names with not particularly > > useful specifications. #2 is a little sleazy (less so if > autoconfed/limits.h) > > Unless you are really adhering to the strict spec, don't use them. > > If you are in fact indexing a "small" array, they might suffice, > > but is it worth it? worth having these types? > > > > > > Theory: 16 bit machines are irrelevant and 32 bit integers > > are perfectly efficient on 64 bit machines, and 64 bit integers > > are universally available (?) and reasonably efficient (?), > > so feel free to use them if there is a need. > > > > > > As well, 4gig remains a large capacity in most contexts, so feel > > free to use explictly 32 bit integers. > > > > > > However file sizes and offsets should really always be 64 bits. > > Any code still requiring 32 bit file offsets/sizes is unfortunate. > > That includes PE32+ imho, the file format for .exes/.dlls on Win64. > > > > > > Be clear and unsleazy and adopt new names that represent well > > their specification and actual use. > > > > > > int_t is exactly n bits in size and signed > > uint_t is exactly n bits in size and unsigned > > some names are chosen for unsigned and signed integers with > > the exact size of a pointer > > For n=8,16,32 all four types exist, and probably 64. > > And pointer-sized types exist. > > > > > > If you really feel your capacity limits should scale with address > space size, or need > > to store a pointer in an integer, use size_t or uintptr_t or > intptr_t, etc. > > > > > > Modula-3's position here adds that INTEGER is the exact > > size of a pointer and signed. It is identical to ptrdiff_t > > or intptr_t. CARDINAL is the exact size but omits the bottom "half" > > of the range, and does not, I believe, extend the top "half". > > > > > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly > mechanical > > translation of /usr/include, and /usr/include does not necessarily > > take perspective #3. So the "funny" names are useful for a human > > mechanical translation. But the precise names can still be used > instead. > > > > > > Here is an exception I said I would detail: > > > > > > irix-5.2/utypes.i3: > > int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END; > > uint64_t = int64_t; > > > > > > This is different in at least two ways that I see. > > - default initialization to zero > > - 32 bit alignment instead of 64 bit alignment > > > > > > I tend to assume that the alignment is actually wrong, > > however all the uses in Usignal appear unaffected, as they are > always preceded > > by a mix of int64_t and an even number of int32. > > Either way, it is easy enough to preserve this for compatibility. > > > > > > I would like to continue, where easy and clear, to reduce the > "size" of m3-libs/m3core/src/unix. > > Making these types portable available helps that. > > For example -- Uin.m3 need not be duplicated at all. > > But then it either must use the presently more portable > unsigned_short and unsigned, > > or uint16_t and uint32_t should be made always available, either > by adding them > > to all the various Utypes.i3, or the one Ctypes.i3, or a new place. > > > > > > Darwin currently has four Upthread.i3 files (one is dead), but > needs either only two, or one > > with the sizes abstracted out. I don't know if PPC64_DARWIN will > needs its own yet, > > I don't have one of these machines yet. > > > > > > I would like to go ahead with this stuff *today*. > > It takes some exertion of patience for me to stop and send this > first. :) > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jun 2 12:13:41 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 2 Jun 2008 10:13:41 +0000 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> References: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Message-ID: They are not from the C standard, nor are they necessarily from a particular platform. Some platforms define some of them. But all platforms could define all of them, at least 8/16/32, and could define them identically. I want to add these somewhere in m3core. They are portable enough. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3Date: Mon, 2 Jun 2008 10:23:44 +0100 Are these types defined by the C standard. If not then they don't belong in Ctypes. If they are only defined by their particular platform then they do belong in Utypes. On Jun 1, 2008, at 3:35 AM, Jay wrote: So much for trying plain text to avoid truncation, darnit.> From: jayk123 at hotmail.com> To: m3devel at elegosoft.com> Subject: proposal/insistence for fixed size integer types in Ctypes.i3> Date: Sun, 1 Jun 2008 02:32:27 +0000> > > > Currently the various Utypes.i3 introduce various types LIKE> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > sometimes there is an underscore after the u.> > > There is quite some variation in which, if any, of these types are provided.> When they are provided, they are always the same, with one exception I will detail.> > > Arguably they are provided only for defining other types and function signatures> within m3-libs/m3core/src/unix.> > > I strongly strongly strongly propose that at least the above 8 types go in> Ctypes, and the definitions in Utypes removed.> > > If there was more commonality in Utypes, I'd "forward" them for compatibility,> but there is little commonality. Code depending on these types would have to> be forked a lot. As I said, the types are always the same, if they are defined,> but they are often not defined.> > > One variation I am open to is introducing a new .i3 file.> But in general I like to colocate stuff rather than pick apart everything> and decide an ideal location. There are tradeoffs either way,> though most people only see the tradeoffs in the way I do it.> The tradeoffs the other way are having to track down module after module,> interface after interface, where to get stuff from, rather than having> a "one stop shop", or "fewer shops to stop".> > > I am also willing to have u_* types and CAPITALIZED types:> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > u_int8_t = uint8_t;> u_int16_t = uint16_t;> u_int32_t = uint32_t;> u_int64_t = uint64_t;> > > UINT8 = uint8_t;> UINT16 = uint16_t;> UINT32 = uint32_t;> UINT64 = uint64_t;> > > INT8 = int8_t;> INT16 = int16_t;> INT32 = int32_t;> INT64 = int64_t;> > > All built-in Modula-3 types are capitalized, as all Modula-3 keywords are.> And capitalized types is a style widely used in the Windows headers.> (Windows and Modula-3 share a common heritage -- Digital -- though I don't know> from where the style of capitalized types originates.)> > > The names "int8", "int16" are also obvious candidates, but I feel that some> amount of typographical convention should be used to demark types.> Some amount of "Hungarian", if you will.> Obviously there are vehement opposing opinions on this.> "Hungarian" is often too precise and precludes changing types without> changing names, as well as producing unpronouncable names.> A "weak" form however seems reasonable and useful.> > > These types represent a certain point of view.> It is a common point of view, but not universal.> > > There are roughly three or four perspectives here:> > > 1)> char, short, int, long are abstractly defined and all code should live with it.> char is at least 8 bits, and of unspecified signedness> (limits.h defines CHAR_BIT, the number of bits in char> for specified signedness, use signed char or unsigned char;> I think char has actually three options for its signess -- signed, unsigned, or "half unsigned")> short is at least 16 bits, signed> int is at least 16 bits, signed> long is at least 32 bits, signed> > > There are not necessarily integral types that can hold pointers.> size_t and ptrdiff_t perhaps, but unclear.> size_t can hold the size of anything, but I think "anything" is "any variable"> and not necessarily "the entire address space".> > > ptrdiff_t can hold the result of subtracting pointers, but it is only> valid to subtract pointers that point into the same array or just past it.> > > It is common, for example, but not universal, for the "address space"> to be divided between "user mode" and "kernel mode", often with a 50/50 split,> so therefore size_t could be one bit smaller than a pointer, at least.> Of course that's an "unnatural" size, but theoretically possible.> (This kernel/user 50/50 split is usually exactly how 32 bit and I assume> 64 bit Windows works, though 32 bit Windows can also have a 3 gig / 1 gig split,> and 32 bit Windows code running on 64 bit Windows kernel can get a> full 4 gig address space.)> > > As well, the representation of signed integers is left unspecified.> The range of "int" need only go down to -32767, not necessarily -32768.> Signed magnitude and one's complement are valid representations.> Overflowing a signed integer causes undefined behavior.> Unsigned numbers do not have this abstraction.> > > While this is the "most correct" view, according to (my understanding) the C standard,> implementations do nail down details way beyond this, and a lot of> code depends on these details.> > > While I may have some of those details slightly wrong, you get the point.> You CAN write code within this interface, but a lot of code violates it, sometimes> > > by accident, sometimes for important practical reasons.> Some amount of code assumes an int is at least or exactly 32 bits.> Some amount of code assumes int or long can hold a pointer, though> int probably not so much, and long probably of proportionally> rapidly decreasing instance due to Win64.> > > > 2)> char, short, int, long are somewhat abstractly defined> char is exactly 8 bits> varying perspectives on its presumed signedness> short is exactly 16 bits> int is exactly 32 bits> long there are few perspectives on; it is exactly 32 bits ("Windows"), or> it is exactly the size of a pointer ("Unix"), or it is at least> the size of a pointer> > > As well, two's complement is the only representation of signed numbers> in use, and code depends on this.> > > (I recently read that we can thank the IBM S/360 or such, in the 1960's,> for introducing such modern-day architectural features that everyone> takes for granted as an 8 bit byte and two's complement signed numbers.)> > > If you need an integer with a particular exact size, either use char/short/int directly,> or run them through "autoconf", or sniff "limits.h".> > > 3) This is my recently acquired perspective, but it isn't new.> > > Given that #1 is "correct but rare", and that #2 are> full of "exact":> > > char, short, int, long are funny names with not particularly> useful specifications. #2 is a little sleazy (less so if autoconfed/limits.h)> Unless you are really adhering to the strict spec, don't use them.> If you are in fact indexing a "small" array, they might suffice,> but is it worth it? worth having these types?> > > Theory: 16 bit machines are irrelevant and 32 bit integers> are perfectly efficient on 64 bit machines, and 64 bit integers> are universally available (?) and reasonably efficient (?),> so feel free to use them if there is a need.> > > As well, 4gig remains a large capacity in most contexts, so feel> free to use explictly 32 bit integers.> > > However file sizes and offsets should really always be 64 bits.> Any code still requiring 32 bit file offsets/sizes is unfortunate.> That includes PE32+ imho, the file format for .exes/.dlls on Win64.> > > Be clear and unsleazy and adopt new names that represent well> their specification and actual use.> > > int_t is exactly n bits in size and signed> uint_t is exactly n bits in size and unsigned> some names are chosen for unsigned and signed integers with> the exact size of a pointer> For n=8,16,32 all four types exist, and probably 64.> And pointer-sized types exist.> > > If you really feel your capacity limits should scale with address space size, or need> to store a pointer in an integer, use size_t or uintptr_t or intptr_t, etc.> > > Modula-3's position here adds that INTEGER is the exact> size of a pointer and signed. It is identical to ptrdiff_t> or intptr_t. CARDINAL is the exact size but omits the bottom "half"> of the range, and does not, I believe, extend the top "half".> > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly mechanical> translation of /usr/include, and /usr/include does not necessarily> take perspective #3. So the "funny" names are useful for a human> mechanical translation. But the precise names can still be used instead.> > > Here is an exception I said I would detail:> > > irix-5.2/utypes.i3:> int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END;> uint64_t = int64_t;> > > This is different in at least two ways that I see.> - default initialization to zero> - 32 bit alignment instead of 64 bit alignment> > > I tend to assume that the alignment is actually wrong,> however all the uses in Usignal appear unaffected, as they are always preceded> by a mix of int64_t and an even number of int32.> Either way, it is easy enough to preserve this for compatibility.> > > I would like to continue, where easy and clear, to reduce the "size" of m3-libs/m3core/src/unix.> Making these types portable available helps that.> For example -- Uin.m3 need not be duplicated at all.> But then it either must use the presently more portable unsigned_short and unsigned,> or uint16_t and uint32_t should be made always available, either by adding them> to all the various Utypes.i3, or the one Ctypes.i3, or a new place.> > > Darwin currently has four Upthread.i3 files (one is dead), but needs either only two, or one> with the sizes abstracted out. I don't know if PPC64_DARWIN will needs its own yet,> I don't have one of these machines yet.> > > I would like to go ahead with this stuff *today*.> It takes some exertion of patience for me to stop and send this first. :)> > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 2 12:34:32 2008 From: jay.krell at cornell.edu (Jay) Date: Mon, 2 Jun 2008 10:34:32 +0000 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> References: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Message-ID: > I want to add these somewhere in m3core. Ok, how about this? I think we can agree to this easily. INTERFACE Cstdint; IMPORT Ctypes; TYPE int8_t = Ctypes.signed_char;uint8_t = Ctypes.unsigned_char; int16_t = Ctypes.short;uint16_t = Ctypes.unsigned_short; int32_t = Ctypes.int;uint32_t = Ctypes.unsigned_int; int64_t = Ctypes.long_long;uint64_t = Ctypes.unsigned_long_long; (* from here on out I don't care much, can be removed to avoid being wrong *) intptr_t = INTEGER;uintptr_t = CARDINAL; (* ? *) (* and esp. from here on out if there is any difficulty coming up with the definitions *) CONST PTRDIFF_MIN = FIRST(intptr_t);SIZE_MAX = LAST(uintptr_t); (* Should WCHAR be wchar_t, or be 16 bits always?wchar_t is sometimes larger than 16 bits. *) WCHAR_MIN = FIRST(WIDECHAR);WCHAR_MAX = LAST(WIDECHAR); (* The rest omitted as decreasing usefulness and possibly decreasing portability. *) I would just as soon integrate all this into the language as globalsbut people like to push stuff out to libraries where possible/easy.(Some C++ libraries -- Boost -- have become very contorted because it was possible but not easy.) - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3Date: Mon, 2 Jun 2008 10:13:41 +0000 They are not from the C standard, nor are they necessarily from a particular platform.Some platforms define some of them.But all platforms could define all of them, at least 8/16/32, and could define them identically.I want to add these somewhere in m3core.They are portable enough. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3Date: Mon, 2 Jun 2008 10:23:44 +0100 Are these types defined by the C standard. If not then they don't belong in Ctypes. If they are only defined by their particular platform then they do belong in Utypes. On Jun 1, 2008, at 3:35 AM, Jay wrote: So much for trying plain text to avoid truncation, darnit.> From: jayk123 at hotmail.com> To: m3devel at elegosoft.com> Subject: proposal/insistence for fixed size integer types in Ctypes.i3> Date: Sun, 1 Jun 2008 02:32:27 +0000> > > > Currently the various Utypes.i3 introduce various types LIKE> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > sometimes there is an underscore after the u.> > > There is quite some variation in which, if any, of these types are provided.> When they are provided, they are always the same, with one exception I will detail.> > > Arguably they are provided only for defining other types and function signatures> within m3-libs/m3core/src/unix.> > > I strongly strongly strongly propose that at least the above 8 types go in> Ctypes, and the definitions in Utypes removed.> > > If there was more commonality in Utypes, I'd "forward" them for compatibility,> but there is little commonality. Code depending on these types would have to> be forked a lot. As I said, the types are always the same, if they are defined,> but they are often not defined.> > > One variation I am open to is introducing a new .i3 file.> But in general I like to colocate stuff rather than pick apart everything> and decide an ideal location. There are tradeoffs either way,> though most people only see the tradeoffs in the way I do it.> The tradeoffs the other way are having to track down module after module,> interface after interface, where to get stuff from, rather than having> a "one stop shop", or "fewer shops to stop".> > > I am also willing to have u_* types and CAPITALIZED types:> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > u_int8_t = uint8_t;> u_int16_t = uint16_t;> u_int32_t = uint32_t;> u_int64_t = uint64_t;> > > UINT8 = uint8_t;> UINT16 = uint16_t;> UINT32 = uint32_t;> UINT64 = uint64_t;> > > INT8 = int8_t;> INT16 = int16_t;> INT32 = int32_t;> INT64 = int64_t;> > > All built-in Modula-3 types are capitalized, as all Modula-3 keywords are.> And capitalized types is a style widely used in the Windows headers.> (Windows and Modula-3 share a common heritage -- Digital -- though I don't know> from where the style of capitalized types originates.)> > > The names "int8", "int16" are also obvious candidates, but I feel that some> amount of typographical convention should be used to demark types.> Some amount of "Hungarian", if you will.> Obviously there are vehement opposing opinions on this.> "Hungarian" is often too precise and precludes changing types without> changing names, as well as producing unpronouncable names.> A "weak" form however seems reasonable and useful.> > > These types represent a certain point of view.> It is a common point of view, but not universal.> > > There are roughly three or four perspectives here:> > > 1)> char, short, int, long are abstractly defined and all code should live with it.> char is at least 8 bits, and of unspecified signedness> (limits.h defines CHAR_BIT, the number of bits in char> for specified signedness, use signed char or unsigned char;> I think char has actually three options for its signess -- signed, unsigned, or "half unsigned")> short is at least 16 bits, signed> int is at least 16 bits, signed> long is at least 32 bits, signed> > > There are not necessarily integral types that can hold pointers.> size_t and ptrdiff_t perhaps, but unclear.> size_t can hold the size of anything, but I think "anything" is "any variable"> and not necessarily "the entire address space".> > > ptrdiff_t can hold the result of subtracting pointers, but it is only> valid to subtract pointers that point into the same array or just past it.> > > It is common, for example, but not universal, for the "address space"> to be divided between "user mode" and "kernel mode", often with a 50/50 split,> so therefore size_t could be one bit smaller than a pointer, at least.> Of course that's an "unnatural" size, but theoretically possible.> (This kernel/user 50/50 split is usually exactly how 32 bit and I assume> 64 bit Windows works, though 32 bit Windows can also have a 3 gig / 1 gig split,> and 32 bit Windows code running on 64 bit Windows kernel can get a> full 4 gig address space.)> > > As well, the representation of signed integers is left unspecified.> The range of "int" need only go down to -32767, not necessarily -32768.> Signed magnitude and one's complement are valid representations.> Overflowing a signed integer causes undefined behavior.> Unsigned numbers do not have this abstraction.> > > While this is the "most correct" view, according to (my understanding) the C standard,> implementations do nail down details way beyond this, and a lot of> code depends on these details.> > > While I may have some of those details slightly wrong, you get the point.> You CAN write code within this interface, but a lot of code violates it, sometimes> > > by accident, sometimes for important practical reasons.> Some amount of code assumes an int is at least or exactly 32 bits.> Some amount of code assumes int or long can hold a pointer, though> int probably not so much, and long probably of proportionally> rapidly decreasing instance due to Win64.> > > > 2)> char, short, int, long are somewhat abstractly defined> char is exactly 8 bits> varying perspectives on its presumed signedness> short is exactly 16 bits> int is exactly 32 bits> long there are few perspectives on; it is exactly 32 bits ("Windows"), or> it is exactly the size of a pointer ("Unix"), or it is at least> the size of a pointer> > > As well, two's complement is the only representation of signed numbers> in use, and code depends on this.> > > (I recently read that we can thank the IBM S/360 or such, in the 1960's,> for introducing such modern-day architectural features that everyone> takes for granted as an 8 bit byte and two's complement signed numbers.)> > > If you need an integer with a particular exact size, either use char/short/int directly,> or run them through "autoconf", or sniff "limits.h".> > > 3) This is my recently acquired perspective, but it isn't new.> > > Given that #1 is "correct but rare", and that #2 are> full of "exact":> > > char, short, int, long are funny names with not particularly> useful specifications. #2 is a little sleazy (less so if autoconfed/limits.h)> Unless you are really adhering to the strict spec, don't use them.> If you are in fact indexing a "small" array, they might suffice,> but is it worth it? worth having these types?> > > Theory: 16 bit machines are irrelevant and 32 bit integers> are perfectly efficient on 64 bit machines, and 64 bit integers> are universally available (?) and reasonably efficient (?),> so feel free to use them if there is a need.> > > As well, 4gig remains a large capacity in most contexts, so feel> free to use explictly 32 bit integers.> > > However file sizes and offsets should really always be 64 bits.> Any code still requiring 32 bit file offsets/sizes is unfortunate.> That includes PE32+ imho, the file format for .exes/.dlls on Win64.> > > Be clear and unsleazy and adopt new names that represent well> their specification and actual use.> > > int_t is exactly n bits in size and signed> uint_t is exactly n bits in size and unsigned> some names are chosen for unsigned and signed integers with> the exact size of a pointer> For n=8,16,32 all four types exist, and probably 64.> And pointer-sized types exist.> > > If you really feel your capacity limits should scale with address space size, or need> to store a pointer in an integer, use size_t or uintptr_t or intptr_t, etc.> > > Modula-3's position here adds that INTEGER is the exact> size of a pointer and signed. It is identical to ptrdiff_t> or intptr_t. CARDINAL is the exact size but omits the bottom "half"> of the range, and does not, I believe, extend the top "half".> > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly mechanical> translation of /usr/include, and /usr/include does not necessarily> take perspective #3. So the "funny" names are useful for a human> mechanical translation. But the precise names can still be used instead.> > > Here is an exception I said I would detail:> > > irix-5.2/utypes.i3:> int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END;> uint64_t = int64_t;> > > This is different in at least two ways that I see.> - default initialization to zero> - 32 bit alignment instead of 64 bit alignment> > > I tend to assume that the alignment is actually wrong,> however all the uses in Usignal appear unaffected, as they are always preceded> by a mix of int64_t and an even number of int32.> Either way, it is easy enough to preserve this for compatibility.> > > I would like to continue, where easy and clear, to reduce the "size" of m3-libs/m3core/src/unix.> Making these types portable available helps that.> For example -- Uin.m3 need not be duplicated at all.> But then it either must use the presently more portable unsigned_short and unsigned,> or uint16_t and uint32_t should be made always available, either by adding them> to all the various Utypes.i3, or the one Ctypes.i3, or a new place.> > > Darwin currently has four Upthread.i3 files (one is dead), but needs either only two, or one> with the sizes abstracted out. I don't know if PPC64_DARWIN will needs its own yet,> I don't have one of these machines yet.> > > I would like to go ahead with this stuff *today*.> It takes some exertion of patience for me to stop and send this first. :)> > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jun 2 13:03:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 02 Jun 2008 13:03:23 +0200 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: References: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Message-ID: <20080602130323.17qngqata84ow8wc@mail.elegosoft.com> Quoting Jay : > > They are not from the C standard, nor are they necessarily from a > particular platform. > Some platforms define some of them. > But all platforms could define all of them, at least 8/16/32, and > could define them identically. > I want to add these somewhere in m3core. > They are portable enough. I wouldn't object to a new interface abstracting just some type definitions for all target platforms. If that's OK with Tony, too, you may go ahead. 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 2 13:12:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jun 2008 12:12:39 +0100 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: References: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Message-ID: Cstdint.i3 seems perfectly reasonable as per: http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html On Jun 2, 2008, at 11:34 AM, Jay wrote: > > I want to add these somewhere in m3core. > > Ok, how about this? I think we can agree to this easily. > > INTERFACE Cstdint; > > IMPORT Ctypes; > > TYPE > > int8_t = Ctypes.signed_char; > uint8_t = Ctypes.unsigned_char; > > int16_t = Ctypes.short; > uint16_t = Ctypes.unsigned_short; > > int32_t = Ctypes.int; > uint32_t = Ctypes.unsigned_int; > > int64_t = Ctypes.long_long; > uint64_t = Ctypes.unsigned_long_long; > > (* from here on out I don't care much, can be removed to avoid being > wrong *) > > intptr_t = INTEGER; > uintptr_t = CARDINAL; (* ? *) > > (* and esp. from here on out if there is any difficulty coming up > with the definitions *) > > CONST > > PTRDIFF_MIN = FIRST(intptr_t); > SIZE_MAX = LAST(uintptr_t); > > (* Should WCHAR be wchar_t, or be 16 bits always? > wchar_t is sometimes larger than 16 bits. *) > > WCHAR_MIN = FIRST(WIDECHAR); > WCHAR_MAX = LAST(WIDECHAR); > > (* The rest omitted as decreasing usefulness and possibly decreasing > portability. *) > > I would just as soon integrate all this into the language as globals > but people like to push stuff out to libraries where possible/easy. > (Some C++ libraries -- Boost -- have become very contorted because > it was possible but not easy.) > > - Jay > > > > > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: proposal/insistence for fixed size > integer types in Ctypes.i3 > Date: Mon, 2 Jun 2008 10:13:41 +0000 > > They are not from the C standard, nor are they necessarily from a > particular platform. > Some platforms define some of them. > But all platforms could define all of them, at least 8/16/32, and > could define them identically. > I want to add these somewhere in m3core. > They are portable enough. > > - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] FW: proposal/insistence for fixed size > integer types in Ctypes.i3 > Date: Mon, 2 Jun 2008 10:23:44 +0100 > > Are these types defined by the C standard. If not then they don't > belong in Ctypes. If they are only defined by their particular > platform then they do belong in Utypes. > > On Jun 1, 2008, at 3:35 AM, Jay wrote: > > So much for trying plain text to avoid truncation, darnit. > > > > > From: jayk123 at hotmail.com > > To: m3devel at elegosoft.com > > Subject: proposal/insistence for fixed size integer types in > Ctypes.i3 > > Date: Sun, 1 Jun 2008 02:32:27 +0000 > > > > > > > > Currently the various Utypes.i3 introduce various types LIKE > > > > > > uint8_t = unsigned_char; > > uint16_t = unsigned_short; > > uint32_t = unsigned_int; > > uint64_t = unsigned_long_long; > > > > > > int8_t = signed_char; > > int16_t = short; > > int32_t = int; > > int64_t = long_long; > > > > > > sometimes there is an underscore after the u. > > > > > > There is quite some variation in which, if any, of these types are > provided. > > When they are provided, they are always the same, with one > exception I will detail. > > > > > > Arguably they are provided only for defining other types and > function signatures > > within m3-libs/m3core/src/unix. > > > > > > I strongly strongly strongly propose that at least the above 8 > types go in > > Ctypes, and the definitions in Utypes removed. > > > > > > If there was more commonality in Utypes, I'd "forward" them for > compatibility, > > but there is little commonality. Code depending on these types > would have to > > be forked a lot. As I said, the types are always the same, if they > are defined, > > but they are often not defined. > > > > > > One variation I am open to is introducing a new .i3 file. > > But in general I like to colocate stuff rather than pick apart > everything > > and decide an ideal location. There are tradeoffs either way, > > though most people only see the tradeoffs in the way I do it. > > The tradeoffs the other way are having to track down module after > module, > > interface after interface, where to get stuff from, rather than > having > > a "one stop shop", or "fewer shops to stop". > > > > > > I am also willing to have u_* types and CAPITALIZED types: > > > > > > uint8_t = unsigned_char; > > uint16_t = unsigned_short; > > uint32_t = unsigned_int; > > uint64_t = unsigned_long_long; > > > > > > int8_t = signed_char; > > int16_t = short; > > int32_t = int; > > int64_t = long_long; > > > > > > u_int8_t = uint8_t; > > u_int16_t = uint16_t; > > u_int32_t = uint32_t; > > u_int64_t = uint64_t; > > > > > > UINT8 = uint8_t; > > UINT16 = uint16_t; > > UINT32 = uint32_t; > > UINT64 = uint64_t; > > > > > > INT8 = int8_t; > > INT16 = int16_t; > > INT32 = int32_t; > > INT64 = int64_t; > > > > > > All built-in Modula-3 types are capitalized, as all Modula-3 > keywords are. > > And capitalized types is a style widely used in the Windows headers. > > (Windows and Modula-3 share a common heritage -- Digital -- though > I don't know > > from where the style of capitalized types originates.) > > > > > > The names "int8", "int16" are also obvious candidates, but I feel > that some > > amount of typographical convention should be used to demark types. > > Some amount of "Hungarian", if you will. > > Obviously there are vehement opposing opinions on this. > > "Hungarian" is often too precise and precludes changing types > without > > changing names, as well as producing unpronouncable names. > > A "weak" form however seems reasonable and useful. > > > > > > These types represent a certain point of view. > > It is a common point of view, but not universal. > > > > > > There are roughly three or four perspectives here: > > > > > > 1) > > char, short, int, long are abstractly defined and all code should > live with it. > > char is at least 8 bits, and of unspecified signedness > > (limits.h defines CHAR_BIT, the number of bits in char > > for specified signedness, use signed char or unsigned char; > > I think char has actually three options for its signess -- signed, > unsigned, or "half unsigned") > > short is at least 16 bits, signed > > int is at least 16 bits, signed > > long is at least 32 bits, signed > > > > > > There are not necessarily integral types that can hold pointers. > > size_t and ptrdiff_t perhaps, but unclear. > > size_t can hold the size of anything, but I think "anything" is > "any variable" > > and not necessarily "the entire address space". > > > > > > ptrdiff_t can hold the result of subtracting pointers, but it is > only > > valid to subtract pointers that point into the same array or just > past it. > > > > > > It is common, for example, but not universal, for the "address > space" > > to be divided between "user mode" and "kernel mode", often with a > 50/50 split, > > so therefore size_t could be one bit smaller than a pointer, at > least. > > Of course that's an "unnatural" size, but theoretically possible. > > (This kernel/user 50/50 split is usually exactly how 32 bit and I > assume > > 64 bit Windows works, though 32 bit Windows can also have a 3 > gig / 1 gig split, > > and 32 bit Windows code running on 64 bit Windows kernel can get a > > full 4 gig address space.) > > > > > > As well, the representation of signed integers is left unspecified. > > The range of "int" need only go down to -32767, not necessarily > -32768. > > Signed magnitude and one's complement are valid representations. > > Overflowing a signed integer causes undefined behavior. > > Unsigned numbers do not have this abstraction. > > > > > > While this is the "most correct" view, according to (my > understanding) the C standard, > > implementations do nail down details way beyond this, and a lot of > > code depends on these details. > > > > > > While I may have some of those details slightly wrong, you get the > point. > > You CAN write code within this interface, but a lot of code > violates it, sometimes > > > > > > by accident, sometimes for important practical reasons. > > Some amount of code assumes an int is at least or exactly 32 bits. > > Some amount of code assumes int or long can hold a pointer, though > > int probably not so much, and long probably of proportionally > > rapidly decreasing instance due to Win64. > > > > > > > > 2) > > char, short, int, long are somewhat abstractly defined > > char is exactly 8 bits > > varying perspectives on its presumed signedness > > short is exactly 16 bits > > int is exactly 32 bits > > long there are few perspectives on; it is exactly 32 bits > ("Windows"), or > > it is exactly the size of a pointer ("Unix"), or it is at least > > the size of a pointer > > > > > > As well, two's complement is the only representation of signed > numbers > > in use, and code depends on this. > > > > > > (I recently read that we can thank the IBM S/360 or such, in the > 1960's, > > for introducing such modern-day architectural features that everyone > > takes for granted as an 8 bit byte and two's complement signed > numbers.) > > > > > > If you need an integer with a particular exact size, either use > char/short/int directly, > > or run them through "autoconf", or sniff "limits.h". > > > > > > 3) This is my recently acquired perspective, but it isn't new. > > > > > > Given that #1 is "correct but rare", and that #2 are > > full of "exact": > > > > > > char, short, int, long are funny names with not particularly > > useful specifications. #2 is a little sleazy (less so if > autoconfed/limits.h) > > Unless you are really adhering to the strict spec, don't use them. > > If you are in fact indexing a "small" array, they might suffice, > > but is it worth it? worth having these types? > > > > > > Theory: 16 bit machines are irrelevant and 32 bit integers > > are perfectly efficient on 64 bit machines, and 64 bit integers > > are universally available (?) and reasonably efficient (?), > > so feel free to use them if there is a need. > > > > > > As well, 4gig remains a large capacity in most contexts, so feel > > free to use explictly 32 bit integers. > > > > > > However file sizes and offsets should really always be 64 bits. > > Any code still requiring 32 bit file offsets/sizes is unfortunate. > > That includes PE32+ imho, the file format for .exes/.dlls on Win64. > > > > > > Be clear and unsleazy and adopt new names that represent well > > their specification and actual use. > > > > > > int_t is exactly n bits in size and signed > > uint_t is exactly n bits in size and unsigned > > some names are chosen for unsigned and signed integers with > > the exact size of a pointer > > For n=8,16,32 all four types exist, and probably 64. > > And pointer-sized types exist. > > > > > > If you really feel your capacity limits should scale with address > space size, or need > > to store a pointer in an integer, use size_t or uintptr_t or > intptr_t, etc. > > > > > > Modula-3's position here adds that INTEGER is the exact > > size of a pointer and signed. It is identical to ptrdiff_t > > or intptr_t. CARDINAL is the exact size but omits the bottom "half" > > of the range, and does not, I believe, extend the top "half". > > > > > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly > mechanical > > translation of /usr/include, and /usr/include does not necessarily > > take perspective #3. So the "funny" names are useful for a human > > mechanical translation. But the precise names can still be used > instead. > > > > > > Here is an exception I said I would detail: > > > > > > irix-5.2/utypes.i3: > > int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END; > > uint64_t = int64_t; > > > > > > This is different in at least two ways that I see. > > - default initialization to zero > > - 32 bit alignment instead of 64 bit alignment > > > > > > I tend to assume that the alignment is actually wrong, > > however all the uses in Usignal appear unaffected, as they are > always preceded > > by a mix of int64_t and an even number of int32. > > Either way, it is easy enough to preserve this for compatibility. > > > > > > I would like to continue, where easy and clear, to reduce the > "size" of m3-libs/m3core/src/unix. > > Making these types portable available helps that. > > For example -- Uin.m3 need not be duplicated at all. > > But then it either must use the presently more portable > unsigned_short and unsigned, > > or uint16_t and uint32_t should be made always available, either > by adding them > > to all the various Utypes.i3, or the one Ctypes.i3, or a new place. > > > > > > Darwin currently has four Upthread.i3 files (one is dead), but > needs either only two, or one > > with the sizes abstracted out. I don't know if PPC64_DARWIN will > needs its own yet, > > I don't have one of these machines yet. > > > > > > I would like to go ahead with this stuff *today*. > > It takes some exertion of patience for me to stop and send this > first. :) > > > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jun 2 23:07:22 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 2 Jun 2008 21:07:22 +0000 Subject: [M3devel] unsigned integers? Message-ID: What is the status and chance of a 32 bit integer with the range 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. 0xFFFFFFFFFFFFFFFF? Already available? Impossible to provide?Only available in unsafe modules?Only available with restricted operations in safe modules, and more operations in unsafe modules? Specifically, I think looping from 0 to N is safe -- no overflow. Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow. Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow. Adding or subtracting an INTEGER to "UNSIGNED" is not safe. Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe. Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done carefully. Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL or UNSIGNED.The unsafe operations above could be runtime checked perhaps. I guess that's a different larger point/dilemna -- when to allow potentially unsafe operations but with runtime checks vs. the compiler just disallowing them entirely. e.g. adding an integer to an integer is not even safe, but checked maybe at runtime (ok, at least assignment to subrange types is checked). Yes, I know I know, the runtime checks on at least many integer operations is yet lacking. Is there any, um, value in such a type? Is it just me blindly trying to cast Modula-3 as C (yes), but there's no actual value (uncertain)? Btw, I agree there's no point in this type in representing file sizes or offsets. They should be at least 63 bit integers. One bit doesn't buy much for file sizes. It might be something for address spaces though? It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = INTEGER. It seems quite wrong. Perhaps the unsigned types larger than 16 bits just should not be defined in Cstdint. ?? But there is already Ctypes.unsigned_int, unsigned_long_long, whose underlying type I think is signed, but which convention says you just don't do signed operations on, but which the compiler doesn't enforce, right? You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED/UINT?????? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Jun 3 02:15:23 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 02 Jun 2008 17:15:23 -0700 Subject: [M3devel] unsigned integers? In-Reply-To: Your message of "Mon, 02 Jun 2008 21:07:22 -0000." Message-ID: <200806030015.m530FNvv073806@camembert.async.caltech.edu> What is it you are looking for? 1 Operator overloading of + - * DIV for this new type? 2 Runtime checks of overflow? Or both? You can obviously get #2 by writing a tiny little library of your own? (Just like the Word interface but with overflow checks.) Does it matter whether the underlying implementation uses INTEGER or ARRAY OF BITS 8 FOR [0..255]? Doesn't a : Unsigned.T := 3; b : CARDINAL := 4; c := a - b; overflow? The Green Book is quite clear on the point that Word.T operations can never overflow, that is, all operations are "safe", using your terminology, so no, they aren't the same types. But it's rather confusing that you use a different definition of the word "safe" from that used in the Green Book. (In fact the Green Book only defines "unsafe" but I assume "safe" to mean "not unsafe", which it does, too.) Mika Jay writes: >--_a753fe8a-a24d-445a-8b9d-c524a5a0a41a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >What is the status and chance of a 32 bit integer with the range 0..0xFFFFF= >FFF and of a 64 bit integer type with range 0 .. 0xFFFFFFFFFFFFFFFF? >=20 >=20 >Already available? >Impossible to provide?Only available in unsafe modules?Only available with = >restricted operations in safe modules, and more operations in unsafe module= >s? >=20 >=20 >Specifically, I think looping from 0 to N is safe -- no overflow. >Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow. >Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow. >Adding or subtracting an INTEGER to "UNSIGNED" is not safe. >Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.Comparin= >g UNSIGNED to UNSIGNED for any of =3D, <, >, !=3D, is safe. >Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done careful= >ly. > Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL or U= >NSIGNED.The unsafe operations above could be runtime checked perhaps. > I guess that's a different larger point/dilemna -- when to allow potentia= >lly unsafe operations but with runtime checks vs. the compiler just disallo= >wing them entirely. e.g. adding an integer to an integer is not even safe, = >but checked maybe at runtime (ok, at least assignment to subrange types is = >checked). Yes, I know I know, the runtime checks on at least many integer o= >perations is yet lacking. >=20 >Is there any, um, value in such a type? >Is it just me blindly trying to cast Modula-3 as C (yes), but there's no ac= >tual value (uncertain)? >=20 >Btw, I agree there's no point in this type in representing file sizes or of= >fsets. They should be at least 63 bit integers. One bit doesn't buy much fo= >r file sizes. It might be something for address spaces though? >=20 >It bugs me to define types like uintptr_t =3D CARDINAL or uintptr_t =3D INT= >EGER. It seems quite wrong. >Perhaps the unsigned types larger than 16 bits just should not be defined i= >n Cstdint. ?? >But there is already Ctypes.unsigned_int, unsigned_long_long, whose underly= >ing type I think is signed, but which convention says you just don't do sig= >ned operations on, but which the compiler doesn't enforce, right? >=20 >You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED= >/UINT?????? >=20 > - Jay= > >--_a753fe8a-a24d-445a-8b9d-c524a5a0a41a_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >What is the status and chance of a 32 bit integer= > with the range 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. = >0xFFFFFFFFFFFFFFFF?
> 
> 
>Already available?
>Impossible to provide?
Only available in unsafe modules?
Only availab= >le with restricted operations in safe modules, and more operations in unsaf= >e modules?
> 
> 
>Specifically, I think looping from 0 to N is safe -- no overflow.
>Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow.
>Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow.
>Adding or subtracting an INTEGER to "UNSIGNED" is not safe.
>Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.
Comp= >aring UNSIGNED to UNSIGNED for any of =3D, <, >, !=3D, is safe.
>Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done careful= >ly.
>  Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any = >CARDINAL or UNSIGNED.
The unsafe operations above could be runtime check= >ed perhaps.
>  I guess that's a different larger point/dilemna -- when to allow pot= >entially unsafe operations but with runtime checks vs. the compiler just di= >sallowing them entirely. e.g. adding an integer to an integer is not even s= >afe, but checked maybe at runtime (ok, at least assignment to subrange type= >s is checked). Yes, I know I know, the runtime checks on at least many inte= >ger operations is yet lacking.
> 
>Is there any, um, value in such a type?
>Is it just me blindly trying to cast Modula-3 as C (yes), but there's no ac= >tual value (uncertain)?

> 
>Btw, I agree there's no point in this type in representing file sizes or of= >fsets. They should be at least 63 bit integers. One bit doesn't buy much fo= >r file sizes. It might be something for address spaces though?
> 
>It bugs me to define types like uintptr_t =3D CARDINAL or uintptr_t =3D INT= >EGER. It seems quite wrong.
>Perhaps the unsigned types larger than 16 bits just should not be defined i= >n Cstdint. ??
>But there is already Ctypes.unsigned_int, unsigned_long_long, whose underly= >ing type I think is signed, but which convention says you just don't do sig= >ned operations on, but which the compiler doesn't enforce, right?
> 
>You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED= >/UINT??????
> 
> - Jay
>= > >--_a753fe8a-a24d-445a-8b9d-c524a5a0a41a_-- From dabenavidesd at yahoo.es Tue Jun 3 02:25:43 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 3 Jun 2008 00:25:43 +0000 (GMT) Subject: [M3devel] unsigned integers? In-Reply-To: Message-ID: <618174.58920.qm@web27102.mail.ukl.yahoo.com> Dear Jay and developers: >What is the status and chance of a 32 bit integer with the range >0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. >0xFFFFFFFFFFFFFFFF? I guess you meant like a LONGCARD, I think it was a proposal of native 64 integer language update with recent LONGINT add,  but as I understood it was no accepted (maybe it was not  needed). Did you mean UNSIGNED like a  LONGCARD? There is a Sweden site about the comparison you want to make of C++ types and Modula-3 built-in types (as I understand you want to figure out), maybe this can give you an idea of others thoughts: http://translate.google.com.co/translate?u=http%3A%2F%2Fwww.nada.kth.se%2Fdatorer%2Fhaften%2Fmodula2c%2B%2B%2Fnode9.html&sl=sv&tl=en&hl=es&ie=UTF-8 Also you can check this opinion based on comparison with Modula-2 too: http://catless.ncl.ac.uk/Risks/18.60.html#subj7.1 Also the m3devel list from 2006. And all the others about 64 native proposal of Rodney Bates and others: http://mailarchive.elegosoft.com/Zope/m3/m3devel/archive/2006/2006-09/1157492987000/index_html?fullMode=1#1158164046000 I would vote to keep simplicity even in the mapping of C types to Modula-3 types, does exist any matrix like the translated web of the url above in the documentation of cm3 to help in the implementations of mapping types? Thanks ---2/6/08, Jay <jayk123 at hotmail.com> wrote: De: Jay <jayk123 at hotmail.com> Asunto: [M3devel] unsigned integers? Para: "m3devel at elegosoft.com" <m3devel at elegosoft.com> Fecha: lunes, 2 junio, 2008 4:07 #yiv1585025748 .hmmessage P { margin:0px;padding:0px;} #yiv1585025748 .hmmessage { FONT-SIZE:10pt;FONT-FAMILY:Tahoma;} What is the status and chance of a 32 bit integer with the range 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. 0xFFFFFFFFFFFFFFFF?     Already available? Impossible to provide? Only available in unsafe modules? Only available with restricted operations in safe modules, and more operations in unsafe modules?     Specifically, I think looping from 0 to N is safe -- no overflow. Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow. Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow. Adding or subtracting an INTEGER to "UNSIGNED" is not safe. Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow. Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe. Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done carefully.   Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL or UNSIGNED. The unsafe operations above could be runtime checked perhaps.   I guess that's a different larger point/dilemna -- when to allow potentially unsafe operations but with runtime checks vs. the compiler just disallowing them entirely. e.g. adding an integer to an integer is not even safe, but checked maybe at runtime (ok, at least assignment to subrange types is checked). Yes, I know I know, the runtime checks on at least many integer operations is yet lacking.   Is there any, um, value in such a type? Is it just me blindly trying to cast Modula-3 as C (yes), but there's no actual value (uncertain)?   Btw, I agree there's no point in this type in representing file sizes or offsets. They should be at least 63 bit integers. One bit doesn't buy much for file sizes. It might be something for address spaces though?   It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = INTEGER. It seems quite wrong. Perhaps the unsigned types larger than 16 bits just should not be defined in Cstdint. ?? But there is already Ctypes.unsigned_int, unsigned_long_long, whose underlying type I think is signed, but which convention says you just don't do signed operations on, but which the compiler doesn't enforce, right?   You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED/UINT??????    - Jay ______________________________________________ Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Tue Jun 3 04:43:20 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 02 Jun 2008 21:43:20 -0500 Subject: [M3devel] unsigned integers? In-Reply-To: References: Message-ID: <4844AFC8.5060004@wichita.edu> It's already available, but takes a bit of care. Modula-2 had an INTEGER and a CARDINAL, the latter unsigned and having full unsigned range for its word size. I think it was not fully defined in the original language report. It turned out a semantic nightmare. It was a nightmare to code too. Been there, done that. Modula-3's CARDINAL, as I'm sure everybody knows is just the positive half range of INTEGER and behaves just like a subrange of INTEGER. This solves a lot of problems, at the cost of taking away half the unsigned range. For full-range unsigned, you use the type INTEGER, but use the operations in interface Word. It's the same type, but different interpretations applied to the same bit pattern. It would be a good practice to declare things as INTEGER when they are signed and Word.T when unsigned, but there is nothing in the language to require it. In the case of addition and subtraction, builtin operators "+" and "-" will produce the same results as Word.Plus and Word.Minus, respectively, except that the conditions under which overflow is detected will differ. Not that that matters much, as, AFAIK, none of the implementations detect integer overflows anyway. So use INTEGER and the unary and binary operators if you want it to be signed, and use Word.T and Word. if you want it unsigned. Of course, you are free to assign between a variable that is being treated as signed and one treated as unsigned any time, without any overflow checks, unless you program them yourself. This certainly violates the intuition about what safety means. However, on closer look, it is not at all the same degree of unsafety as, say, arrays going out of bounds. My definition of safe is that nothing can happen that cannot be explained using only the concepts of the language. For example, to understand what an array bounds error actually does, you would need to know that an array actually shares memory with other variables, code, etc., and then a huge amount about how the compiler, linker, loader, heap allocator, etc. lay things out, along with what is declared in all the code, including libraries you are not working on. None of this is part of a so-called high-level language. The INTEGER/Word.T thing can be explained knowing about binary twos-complement representation, which is definitely a machine-level concept. The Word interface defines the unsigned side of it as a language concept too, but only hints at the signed representation. But most importantly, neither the operators nor the functions in Word.T ever produce any values that are not meaningful in the value set of the type. There is no really good linguistic solution to this problem, but I think Modula-3's is definitely the least painful I have seen. Jay wrote: > What is the status and chance of a 32 bit integer with the range > 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. > 0xFFFFFFFFFFFFFFFF? > > > Already available? > Impossible to provide? > Only available in unsafe modules? > Only available with restricted operations in safe modules, and more > operations in unsafe modules? > > > Specifically, I think looping from 0 to N is safe -- no overflow. > Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow. > Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow. > Adding or subtracting an INTEGER to "UNSIGNED" is not safe. > Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow. > Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe. > Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done > carefully. > Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL > or UNSIGNED. > The unsafe operations above could be runtime checked perhaps. > I guess that's a different larger point/dilemna -- when to allow > potentially unsafe operations but with runtime checks vs. the compiler > just disallowing them entirely. e.g. adding an integer to an integer is > not even safe, but checked maybe at runtime (ok, at least assignment to > subrange types is checked). Yes, I know I know, the runtime checks on at > least many integer operations is yet lacking. > > Is there any, um, value in such a type? > Is it just me blindly trying to cast Modula-3 as C (yes), but there's no > actual value (uncertain)? > > > Btw, I agree there's no point in this type in representing file sizes or > offsets. They should be at least 63 bit integers. One bit doesn't buy > much for file sizes. It might be something for address spaces though? > > It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = > INTEGER. It seems quite wrong. > Perhaps the unsigned types larger than 16 bits just should not be > defined in Cstdint. ?? > But there is already Ctypes.unsigned_int, unsigned_long_long, whose > underlying type I think is signed, but which convention says you just > don't do signed operations on, but which the compiler doesn't enforce, > right? > > You know, maybe Word.T should not be INTEGER but this mythological > UNSIGNED/UINT?????? > > - Jay -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jayk123 at hotmail.com Tue Jun 3 05:10:40 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 3 Jun 2008 03:10:40 +0000 Subject: [M3devel] unsigned integers? In-Reply-To: <4844AFC8.5060004@wichita.edu> References: <4844AFC8.5060004@wichita.edu> Message-ID: Very interesting. The suggestion of one of the links is that the extra range of a full unsigned type isn't particularly needed, once you have 31 bits instead of only 15. Now, in C, it is common to do a manual range check, and having unsigned cuts that check in half, makes it easier to get correct. However Modula-3 does that checking for you, taking away more of the point of the full unsigned type. So I guess there's just no need. It might be nice to make Word.T != INTEGER though. ? Gotta run. - Jay> Date: Mon, 2 Jun 2008 21:43:20 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] unsigned integers?> > It's already available, but takes a bit of care.> > Modula-2 had an INTEGER and a CARDINAL, the latter unsigned and having> full unsigned range for its word size. I think it was not fully> defined in the original language report. It turned out a semantic> nightmare. It was a nightmare to code too. Been there, done that.> > Modula-3's CARDINAL, as I'm sure everybody knows is just the positive> half range of INTEGER and behaves just like a subrange of INTEGER.> This solves a lot of problems, at the cost of taking away half the> unsigned range.> > For full-range unsigned, you use the type INTEGER, but use the> operations in interface Word. It's the same type, but different> interpretations applied to the same bit pattern. It would be a> good practice to declare things as INTEGER when they are signed> and Word.T when unsigned, but there is nothing in the language to> require it.> > In the case of addition and subtraction, builtin operators "+" and> "-" will produce the same results as Word.Plus and Word.Minus,> respectively, except that the conditions under which overflow is> detected will differ. Not that that matters much, as, AFAIK, none> of the implementations detect integer overflows anyway.> > So use INTEGER and the unary and binary operators if you want it to> be signed, and use Word.T and Word. if you want it unsigned.> > Of course, you are free to assign between a variable that is being> treated as signed and one treated as unsigned any time, without any> overflow checks, unless you program them yourself. This certainly> violates the intuition about what safety means. However, on closer> look, it is not at all the same degree of unsafety as, say, arrays> going out of bounds.> > My definition of safe is that nothing can happen that cannot be> explained using only the concepts of the language. For example,> to understand what an array bounds error actually does, you would> need to know that an array actually shares memory with other variables,> code, etc., and then a huge amount about how the compiler, linker,> loader, heap allocator, etc. lay things out, along with what is> declared in all the code, including libraries you are not working on.> None of this is part of a so-called high-level language.> > The INTEGER/Word.T thing can be explained knowing about binary> twos-complement representation, which is definitely a machine-level> concept. The Word interface defines the unsigned side of it as> a language concept too, but only hints at the signed representation.> But most importantly, neither the operators nor the functions in> Word.T ever produce any values that are not meaningful in the value> set of the type.> > There is no really good linguistic solution to this problem, but> I think Modula-3's is definitely the least painful I have seen.> > > Jay wrote:> > What is the status and chance of a 32 bit integer with the range > > 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. > > 0xFFFFFFFFFFFFFFFF?> > > > > > Already available?> > Impossible to provide?> > Only available in unsafe modules?> > Only available with restricted operations in safe modules, and more > > operations in unsafe modules?> > > > > > Specifically, I think looping from 0 to N is safe -- no overflow.> > Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow.> > Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow.> > Adding or subtracting an INTEGER to "UNSIGNED" is not safe.> > Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.> > Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe.> > Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done > > carefully.> > Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL > > or UNSIGNED.> > The unsafe operations above could be runtime checked perhaps.> > I guess that's a different larger point/dilemna -- when to allow > > potentially unsafe operations but with runtime checks vs. the compiler > > just disallowing them entirely. e.g. adding an integer to an integer is > > not even safe, but checked maybe at runtime (ok, at least assignment to > > subrange types is checked). Yes, I know I know, the runtime checks on at > > least many integer operations is yet lacking.> > > > Is there any, um, value in such a type?> > Is it just me blindly trying to cast Modula-3 as C (yes), but there's no > > actual value (uncertain)?> > > > > > Btw, I agree there's no point in this type in representing file sizes or > > offsets. They should be at least 63 bit integers. One bit doesn't buy > > much for file sizes. It might be something for address spaces though?> > > > It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = > > INTEGER. It seems quite wrong.> > Perhaps the unsigned types larger than 16 bits just should not be > > defined in Cstdint. ??> > But there is already Ctypes.unsigned_int, unsigned_long_long, whose > > underlying type I think is signed, but which convention says you just > > don't do signed operations on, but which the compiler doesn't enforce, > > right?> > > > You know, maybe Word.T should not be INTEGER but this mythological > > UNSIGNED/UINT??????> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jun 3 11:34:46 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 3 Jun 2008 09:34:46 +0000 Subject: [M3devel] unaligned record fields? Message-ID: I have on my machine like: m3core/src/win32 UINT8 = BITS 8 FOR ... UINT16 = BITS 16 FOR ... UINT32 = BITS 32 FOR ...(actually via an edited Cstdint). This is turning up, as I understand, two sets of problems, one "invented" and easy to fix, one "preexisting" and I don't know how to solve. "Problem" 1: structs that require inserting padding to be aligned: FOO = RECORD a: UINT16; b: UINT32; END; => Could not find a legal alignment... Fixed with: FOO = RECORD a: UINT16; >> padding: UINT16; b: UINT32; END; I think this a good thing, however it definitely might break some code out there -- that is, the problem where I make a breaking change, rebuild all of cm3, fix things up, but that isn't all the Modula-3 code in the world. Really, this is a good thing. I TEND to think that quiet insertion of padding for alignment is a bad thing, but that it should also by default be an error to declare unaligned fields. Granted, if you are going to share binary files between architectures, you might be forced to quash the error and allow unaligned fields. Really, I'm not sure what the answer is, but I don't think the current way of doing things, in the broader C/C++ world, is correct. It causes too many headaches to be correct. I suspend judgement about Modula-3 out of ignorance. At least I found a way, accidentally, for it trigger errors for things I don't like, but I haven't found a way to let through things that while dubious, are meant to be asis (see problem #2). Problem 1b: One record was missing a field! Add that back and the warning goes away. Nice to catch that. Problem 2: types that are not "internally" naturally aligned There are at least of these. The ??? stuff is not my introducing. (*??? #pragma pack(2) *) PBITMAPFILEHEADER = UNTRACED REF BITMAPFILEHEADER; LPBITMAPFILEHEADER = UNTRACED REF BITMAPFILEHEADER; BITMAPFILEHEADER = BITS (16_E * 8) FOR RECORD bfType : UINT16; bfSize : UINT32; (* this is not aligned *) bfReserved1: UINT16; bfReserved2: UINT16; bfOffBits : UINT32; (* nor is this *) END; (*??? #pragma pack() *) (*??? #pragma pack(2) *) PMETAHEADER = UNTRACED REF METAHEADER; LPMETAHEADER = UNTRACED REF METAHEADER; METAHEADER = RECORD mtType : UINT16; mtHeaderSize : UINT16; mtVersion : UINT16; mtSize : UINT32; (* This is not aligned. *) mtNoObjects : UINT16; mtMaxRecord : UINT32; (This is ok. *) mtNoParameters: UINT16; END; (*??? #pragma pack() *) I assume/fear that Modula-3 was not previously laying these types out correctly. NOTE that I don't see evidence of them being really used, so this isn't likely related to "bitmap problems". How does one declare these? I think the best I can do for now is change the unaligned fields to be arrays of bytes and hope nobody uses them. These two programs confirm the bug: UNSAFE MODULE A EXPORTS Main; IMPORT WinGDI;IMPORT IO; VARa: WinGDI.BITMAPFILEHEADER;b: WinGDI.METAHEADER; PROCEDURE F1(a,b: ADDRESS) =BEGIN IO.PutInt(b - a); IO.Put("\n");END F1; BEGIN F1(ADR(a), ADR(a.bfSize)); F1(ADR(b), ADR(b.mtSize)); END A. This prints 4 and 8. vs. #include #include ACCEL a;IMAGE_DOS_HEADER b;TOKEN_STATISTICS c;SE_IMPERSONATION_STATE d;COMSTAT e;BITMAPFILEHEADER f;METAHEADER g;FORMAT_PARAMETERS h;FORMAT_EX_PARAMETERS i;DISK_GEOMETRY j; int main(){ return 0;} look at it in a debugger, should be 2 and 6: 0:000> ?? fstruct tagBITMAPFILEHEADER +0x000 bfType : 0 +0x002 bfSize : 0 +0x006 bfReserved1 : 0 +0x008 bfReserved2 : 0 +0x00a bfOffBits : 00:000> ?? gstruct tagMETAHEADER +0x000 mtType : 0 +0x002 mtHeaderSize : 0 +0x004 mtVersion : 0 +0x006 mtSize : 0 +0x00a mtNoObjects : 0 +0x00c mtMaxRecord : 0 +0x010 mtNoParameters : 0 Btw, regarding struct stat, I did write Modula-3 code to form a string that represents all the sizes/offsets of the fields. We could write little tests that does that, and similar C code, and then compares the strings for equality. And/or invest a little more in C code that prints out correct Modula .i3 files, driven by a bunch of data with sizeof and offsetof, including sorting by offsetof, and checking for padding by adding offsetof+sizeof. It kind of looks like "lazyalign" is the answer, but I know this was brought up as "broken" recently, but that "Darwin (MacOSX)" needs it. I didn't follow the discusion closely. Lazyalign maybe is exactly the thing, as long as it is applicable on a type-by-type or field-by-field basis. There are some <* UNALIGNED *> and <* PRAGMA UNALIGNED *> but I see no implementation of these. I think they are being silently ignored. ?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jun 3 11:36:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 3 Jun 2008 09:36:25 +0000 Subject: [M3devel] FW: unsigned integers? In-Reply-To: <4844AFC8.5060004@wichita.edu> References: <4844AFC8.5060004@wichita.edu> Message-ID: truncated yet again, albeit slightly.. From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; m3devel at elegosoft.comSubject: RE: [M3devel] unsigned integers?Date: Tue, 3 Jun 2008 03:10:40 +0000 Very interesting.The suggestion of one of the links is that the extra range of a full unsigned type isn't particularly needed, once you have 31 bits instead of only 15.Now, in C, it is common to do a manual range check, and having unsigned cuts that check in half, makes it easier to get correct -- no need to remember to check for >=0, but also easy to do that..However Modula-3 does that checking for you, taking away more of the point of the full unsigned type.So I guess there's just no need.It might be nice to make Word.T != INTEGER though. ?Gotta run. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 5 13:30:40 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 5 Jun 2008 11:30:40 +0000 Subject: [M3devel] modula-3 uniq.exe? Message-ID: The Modula-3 tree has a simple little uniq.exe. It's like 10 lines, looks reasonable. I haven't debugged it, but when I have \cm3\bin and therefore \cm3\bin\uniq.exe early in %PATH%, building in m3-sys/m3cc hangs. I have seen this twice recently, so it wasn't a one time fluke. Both times I control-c, delete \cm3\bin\uniq.exe, rmdir /q/s NT386 (cross builds of m3cc use a two part output directory), cm3 again, and problem solved. I know it's good to build everything possible, make it sure it all builds and all that, but the code is pretty trivial and uninteresting. How about we remove it from the "std" group? (I'm still not using pkginfo.txt myself, hypocrisy, but let's assume I am; pylib.py has its own list currently.) Or in its m3makefile put like if not equal(target, "nt386") around it all I know I know, I'm lazy, it should be debugged and fixed properly, but it just doesn't seem all that worthwhile. And I also don't to have to keep deleting it. Cloning varous utilities in Modula-3 is a great exercise in using/testing/learning Modula-3, but maybe they shouldn't be identically named or installed or alway installed? Granted, installing them is a great way to test them... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jun 5 14:36:44 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 05 Jun 2008 14:36:44 +0200 Subject: [M3devel] modula-3 uniq.exe? In-Reply-To: References: Message-ID: <20080605143644.n8a7b6az484400ww@mail.elegosoft.com> Quoting Jay : > > The Modula-3 tree has a simple little uniq.exe. It's like 10 lines, > looks reasonable. > I haven't debugged it, but when I have \cm3\bin and therefore > \cm3\bin\uniq.exe early in %PATH%, building in m3-sys/m3cc hangs. I > have seen this twice recently, so it wasn't a one time fluke. Both > times I control-c, delete \cm3\bin\uniq.exe, rmdir /q/s > NT386 (cross builds of m3cc use a two part output > directory), cm3 again, and problem solved. > > I know it's good to build everything possible, make it sure it all > builds and all that, but the code is pretty trivial and uninteresting. > > How about we remove it from the "std" group? > > (I'm still not using pkginfo.txt myself, hypocrisy, but let's assume > I am; pylib.py has its own list currently.) > > Or in its m3makefile put like if not equal(target, "nt386") around it all > I know I know, I'm lazy, it should be debugged and fixed properly, > but it just doesn't seem all that worthwhile. And I also don't to > have to keep deleting it. I think the only point of this program was to make uniq available on Win32, but I don't remember that is has ever been used outside Critical Mass Inc. Thus exluding it on NT386 wouldn't make much sense in my opinion. I've got no problem to remove it from std, as long as we don't really need it somewhere. And I don't really understand why your builds hang; perhaps this would be worth investigating? Olaf > Cloning varous utilities in Modula-3 is a great exercise in > using/testing/learning Modula-3, but maybe they shouldn't be > identically named or installed or alway installed? Granted, > installing them is a great way to test them... > > - 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 jayk123 at hotmail.com Thu Jun 5 20:46:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 5 Jun 2008 18:46:22 +0000 Subject: [M3devel] floats in IL Message-ID: Tony, the way floats/doubles are read/used by parse.c is definitely wrong. Gcc wants an array of longs. At the very least, the current code hits alignment faults on OpenBSD/sparc64. 32 bit architectures would be ok, as would AMD64. As well, gcc wants 32 bits per long -- even if the longs are larger than that. So even on AMD64 it is probably reading garbage. So how about something like this: static treescan_float (unsigned *fkind){ unsigned long i = get_int (); long n_bytes; long longs[(sizeof(long double) + sizeof(long) - 1) / sizeof(long)] = { 0 }; tree tipe; REAL_VALUE_TYPE val; *fkind = i; switch (i) { case 0: tipe = t_reel; n_bytes = REEL_BYTES; break; case 1: tipe = t_lreel; n_bytes = LREEL_BYTES; break; case 2: tipe = t_xreel; n_bytes = XREEL_BYTES; break; default: fatal_error(" *** invalid floating point value, precision = 0x%lx, at m3cg_lineno %d", i, m3cg_lineno); } /* read the value's bytes; each long holds 32 bits */ for (i = 0; i < n_bytes; i++) { longs[i / 4] |= ((0xFF & get_int ()) << ((i % 4) * 8)); } /* finally, assemble a floating point value */ if (tipe == t_reel) { real_from_target_fmt (&val, longs, &ieee_single_format); } else { real_from_target_fmt (&val, longs, &ieee_double_format); } return build_real (tipe, val);}I'd also feel better if get_int returned an unsigned type but don't have enough evidence there yet to change it. And this looks suspicous: #define INTEGER(x) long x = get_int()#define UNUSED_INTEGER(x) int x ATTRIBUTE_UNUSED = get_int()static longget_int (void){ long i, n_bytes, sign, val, shift; i = (long) get_byte (); switch (i) { case M3CG_Int1: return (long) get_byte (); case M3CG_NInt1: return - (long) get_byte (); case M3CG_Int2: n_bytes = 2; sign = 1; break; case M3CG_NInt2: n_bytes = 2; sign = -1; break; case M3CG_Int4: n_bytes = 4; sign = 1; break; case M3CG_NInt4: n_bytes = 4; sign = -1; break; case M3CG_Int8: n_bytes = 8; sign = 1; break; case M3CG_NInt8: n_bytes = 8; sign = -1; break; default: return i; } for (val = 0, shift = 0; n_bytes > 0; n_bytes--, shift += 8) { val = val | (((long) get_byte ()) << shift); } return sign * val;} 8 bytes in a long? I think it needs to be a high and low host wide int, or at least a host wide int and assume that is 64 bits. But I haven't debugged this either, just went groveling for "long". Oh, scan_target_int looks better. Probably get_int is guaranteeably only up to 32 bits and the "8" cases should fail an assertion?or get_int is guaranteed to fit in a host long, so should only assert on the 8 cases if a long is smaller than 8 bytes? It appears that cm3 and cm3cg must be on the same host, that the IL format is not "portable". Because of the endianness of the float/double constants. But I'm not 100% sure. If you don't have time to look at, fix, test this, I will. Just that, you know, I can be both lazy and respectful at the same time. :) Thank, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jun 5 21:05:20 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 5 Jun 2008 20:05:20 +0100 Subject: [M3devel] floats in IL In-Reply-To: References: Message-ID: Indeed there may be problems with those fragments since there were some changes needed there in porting forward into newer versions of gcc. Feel free to fix as needs be. That code has provenance from well before me so no feelings of mine will get hurt. Go for it. On Jun 5, 2008, at 7:46 PM, Jay wrote: > Tony, the way floats/doubles are read/used by parse.c is definitely > wrong. > Gcc wants an array of longs. > At the very least, the current code hits alignment faults on OpenBSD/ > sparc64. > 32 bit architectures would be ok, as would AMD64. > > As well, gcc wants 32 bits per long -- even if the longs are larger > than that. > So even on AMD64 it is probably reading garbage. > > So how about something like this: > > static tree > scan_float (unsigned *fkind) > { > unsigned long i = get_int (); > long n_bytes; > long longs[(sizeof(long double) + sizeof(long) - 1) / > sizeof(long)] = { 0 }; > tree tipe; > REAL_VALUE_TYPE val; > > *fkind = i; > switch (i) { > case 0: tipe = t_reel; n_bytes = REEL_BYTES; break; > case 1: tipe = t_lreel; n_bytes = LREEL_BYTES; break; > case 2: tipe = t_xreel; n_bytes = XREEL_BYTES; break; > default: > fatal_error(" *** invalid floating point value, precision = 0x > %lx, at m3cg_lineno %d", > i, m3cg_lineno); > } > > /* read the value's bytes; each long holds 32 bits */ > for (i = 0; i < n_bytes; i++) > { > longs[i / 4] |= ((0xFF & get_int ()) << ((i % 4) * 8)); > } > > /* finally, assemble a floating point value */ > if (tipe == t_reel) { > real_from_target_fmt (&val, longs, &ieee_single_format); > } else { > real_from_target_fmt (&val, longs, &ieee_double_format); > } > return build_real (tipe, val); > } > > I'd also feel better if get_int returned an unsigned type but don't > have enough evidence there yet to change it. > > And this looks suspicous: > > #define INTEGER(x) long x = get_int() > #define UNUSED_INTEGER(x) int x ATTRIBUTE_UNUSED = get_int() > static long > get_int (void) > { > long i, n_bytes, sign, val, shift; > i = (long) get_byte (); > switch (i) { > case M3CG_Int1: return (long) get_byte (); > case M3CG_NInt1: return - (long) get_byte (); > case M3CG_Int2: n_bytes = 2; sign = 1; break; > case M3CG_NInt2: n_bytes = 2; sign = -1; break; > case M3CG_Int4: n_bytes = 4; sign = 1; break; > case M3CG_NInt4: n_bytes = 4; sign = -1; break; > case M3CG_Int8: n_bytes = 8; sign = 1; break; > case M3CG_NInt8: n_bytes = 8; sign = -1; break; > default: return i; > } > for (val = 0, shift = 0; n_bytes > 0; n_bytes--, shift += 8) { > val = val | (((long) get_byte ()) << shift); > } > return sign * val; > } > > > 8 bytes in a long? > I think it needs to be a high and low host wide int, or at least a > host wide int and assume that is 64 bits. > But I haven't debugged this either, just went groveling for "long". > Oh, scan_target_int looks better. > Probably get_int is guaranteeably only up to 32 bits and the "8" > cases should fail an assertion? > or get_int is guaranteed to fit in a host long, so should only > assert on the 8 cases if a long is smaller than 8 bytes? > > It appears that cm3 and cm3cg must be on the same host, that the IL > format is not "portable". > Because of the endianness of the float/double constants. > But I'm not 100% sure. > > If you don't have time to look at, fix, test this, I will. > Just that, you know, I can be both lazy and respectful at the same > time. :) > > Thank, > - Jay From rodney.bates at wichita.edu Sat Jun 7 18:23:27 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 07 Jun 2008 11:23:27 -0500 Subject: [M3devel] windowsResoures not found Message-ID: <484AB5FF.2080307@wichita.edu> I just tried some building on a new computer, using current cvs updates, as of 2008-6-6. scripts/do-cm3-all.sh build fails with: package windowsResources not found *** cannot find package windowsResources / However, ls -ld m3-sys/windowsResources gives: drwxr-xr-x 4 rodney rodney 4096 2008-06-05 19:07 m3-sys/windowsResources so the files are there. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jayk123 at hotmail.com Sun Jun 8 00:22:49 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 7 Jun 2008 22:22:49 +0000 Subject: [M3devel] windowsResoures not found In-Reply-To: <484AB5FF.2080307@wichita.edu> References: <484AB5FF.2080307@wichita.edu> Message-ID: Try scripts/python instead? - Jay> Date: Sat, 7 Jun 2008 11:23:27 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: [M3devel] windowsResoures not found> > I just tried some building on a new computer, using current cvs updates,> as of 2008-6-6. scripts/do-cm3-all.sh build fails with:> > package windowsResources not found> *** cannot find package windowsResources /> > However, ls -ld m3-sys/windowsResources gives:> > drwxr-xr-x 4 rodney rodney 4096 2008-06-05 19:07 m3-sys/windowsResources> > so the files are there.> > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jun 8 16:39:18 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 8 Jun 2008 15:39:18 +0100 Subject: [M3devel] windowsResoures not found In-Reply-To: References: <484AB5FF.2080307@wichita.edu> Message-ID: <2CFDBEDE-4A3D-45CB-B7C0-A16B09E9745B@cs.purdue.edu> We need to make sure that the standard build scripts work the same on all platforms. It is not acceptable that we forgo the elegant platform independent uniformity of Modula-3 installation procedures. On Jun 7, 2008, at 11:22 PM, Jay wrote: > Try scripts/python instead? > > - Jay > > > > > > Date: Sat, 7 Jun 2008 11:23:27 -0500 > > From: rodney.bates at wichita.edu > > To: m3devel at elegosoft.com > > Subject: [M3devel] windowsResoures not found > > > > I just tried some building on a new computer, using current cvs > updates, > > as of 2008-6-6. scripts/do-cm3-all.sh build fails with: > > > > package windowsResources not found > > *** cannot find package windowsResources / > > > > However, ls -ld m3-sys/windowsResources gives: > > > > drwxr-xr-x 4 rodney rodney 4096 2008-06-05 19:07 m3-sys/ > windowsResources > > > > so the files are there. > > > > > > > > -- > > ------------------------------------------------------------- > > Rodney M. Bates, retired assistant professor > > Dept. of Computer Science, Wichita State University > > Wichita, KS 67260-0083 > > 316-978-3922 > > rodney.bates at wichita.edu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jun 8 20:40:26 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 8 Jun 2008 18:40:26 +0000 Subject: [M3devel] windowsResoures not found In-Reply-To: <2CFDBEDE-4A3D-45CB-B7C0-A16B09E9745B@cs.purdue.edu> References: <484AB5FF.2080307@wichita.edu> <2CFDBEDE-4A3D-45CB-B7C0-A16B09E9745B@cs.purdue.edu> Message-ID: I use one elegant set of build scripts and installation procedures for all platforms. Sh is platform independent and elegant and Python is not? Rodney delete scripts/PKGS and let it get regenerated. I hope to shortly fix it so PKGS never needs to be regenerated. Either a) we should just check it in, pruned down to the small required contents like Randy's cmd stuff or b) I have Solaris up and running so can test out "platform independent" Sh changes, and then the version can be appended to the filename and rm PKGS* before regenerating. - Jay CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] windowsResoures not foundDate: Sun, 8 Jun 2008 15:39:18 +0100 We need to make sure that the standard build scripts work the same on all platforms. It is not acceptable that we forgo the elegant platform independent uniformity of Modula-3 installation procedures. On Jun 7, 2008, at 11:22 PM, Jay wrote: Try scripts/python instead? - Jay> Date: Sat, 7 Jun 2008 11:23:27 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: [M3devel] windowsResoures not found> > I just tried some building on a new computer, using current cvs updates,> as of 2008-6-6. scripts/do-cm3-all.sh build fails with:> > package windowsResources not found> *** cannot find package windowsResources /> > However, ls -ld m3-sys/windowsResources gives:> > drwxr-xr-x 4 rodney rodney 4096 2008-06-05 19:07 m3-sys/windowsResources> > so the files are there.> > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jun 9 15:20:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Jun 2008 15:20:59 +0200 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST Message-ID: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> One more test failure compared to yestereday's run: p211. Anybody knows the reason for this? Olaf ----- Forwarded message from wagner at luthien.in-berlin.de ----- Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST) From: Olaf Wagner Reply-To: Olaf Wagner Subject: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST To: wagner at luthien.iceflower.in-berlin.de Cc: wagner at elego.de === 2008-06-09 01:30:38 checkout cm3 to /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK checkout 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP === 2008-06-09 01:38:52 checkout cm3 done === 2008-06-09 01:38:52 build cm3 core in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK build_lastok_core 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK build_lastok_core_lastok 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 /home/wagner/work/cm3-inst/luthien/last-ok === 2008-06-09 01:53:43 cm3 release build done === 2008-06-09 01:53:43 build cm3 core in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last release /home/wagner/work/cm3-inst/luthien/rel-5.4.0 >>> OK build_rel_upgrade 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK build_rel_core 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK build_rel_core_lastok 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 /home/wagner/work/cm3-inst/luthien/last-ok === 2008-06-09 02:15:19 cm3 release build done === 2008-06-09 02:15:19 build cm3 bindist snapshot in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 === 2008-06-09 02:18:44 cm3 snapshot build done === 2008-06-09 02:18:44 build cm3 std in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK build_std_std 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK build_std_std_lastok 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 /home/wagner/work/cm3-inst/luthien/last-ok === 2008-06-09 02:32:35 cm3 release build done === 2008-06-09 02:32:35 run cm3 compiler and runtime regression test suite in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> test_m3tests error extract: >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 p211 r001 e020 e026 e029 >>> 13 in test_m3tests 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 === 2008-06-09 02:34:35 cm3 m3tests run done === 2008-06-09 02:34:35 build all packages and generate report in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 === 2008-06-09 02:37:16 cm3 package status run done === 2008-06-09 02:37:16 build HTML package doc in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK test_m3tohtml 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 === 2008-06-09 02:38:53 m3tohtml run done ----- End forwarded message ----- -- 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 jayk123 at hotmail.com Mon Jun 9 19:48:03 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 9 Jun 2008 17:48:03 +0000 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> Message-ID: This is a new test that I just added and it should work.Do you have any details on the failure?The output? I thought I tested on both NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have to double check though.(Testing on NT386 is less relevant.) In particular, there was a bug here on new/inactiveplatforms and I wanted a test to verify my fix.The bug caused some platforms to bus/alignment error in cm3cg. I will have to double check both that I updated my cm3cg and ran the test. My internet connection is extremely slow lately and thisis hampering me. I have to call tech support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST> > One more test failure compared to yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > ----- Forwarded message from wagner at luthien.in-berlin.de -----> Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > Reply-To: Olaf Wagner > Subject: CM3 regression test from luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > === 2008-06-09 01:30:38 checkout cm3 to > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK checkout 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_lastok_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK build_rel_upgrade 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 build cm3 std in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_std_std 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_std_std_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and runtime regression test > suite in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok version> >>> test_m3tests error extract:> >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> 13 in test_m3tests 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all packages and generate report in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build HTML package doc in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > -- > 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 jayk123 at hotmail.com Mon Jun 9 20:10:37 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 9 Jun 2008 18:10:37 +0000 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> Message-ID: Both NT386GNU and PPC_DARWIN look good to me. I'm double checking something on PPC_DARWIN but expect it'll still look good. If the program builds, please send me the output. also cm3 -keep and the A.mc file. I'll go and check the tinderbox now..if my internet holds up.. Thanks, - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Mon, 9 Jun 2008 17:48:03 +0000Subject: Re: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 This is a new test that I just added and it should work.Do you have any details on the failure?The output?I thought I tested on both NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have to double check though.(Testing on NT386 is less relevant.) In particular, there was a bug here on new/inactiveplatforms and I wanted a test to verify my fix.The bug caused some platforms to bus/alignment error in cm3cg. I will have to double check both that I updated my cm3cg and ran the test.My internet connection is extremely slow lately and thisis hampering me. I have to call tech support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST> > One more test failure compared to yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > ----- Forwarded message from wagner at luthien.in-berlin.de -----> Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > Reply-To: Olaf Wagner > Subject: CM3 regression test from luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > === 2008-06-09 01:30:38 checkout cm3 to > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK checkout 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_lastok_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK build_rel_upgrade 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 build cm3 std in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_std_std 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_std_std_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and runtime regression test > suite in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok version> >>> test_m3tests error extract:> >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> 13 in test_m3tests 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all packages and generate report in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build HTML package doc in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > -- > 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 jayk123 at hotmail.com Mon Jun 9 21:03:58 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 9 Jun 2008 19:03:58 +0000 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> Message-ID: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1213020039.1032 27414 --- p211 --- float and double constants work27415 cd ../src/p2/p211 && cm3 -silent -DM3TESTS >SOLgnu/stdout.build.raw 2>SOLgnu/stderr.build.raw27416 ../src/p2/p211/stdout.build is missing27417 ../src/p2/p211/stderr.build is missing27418 No differences encountered27419 No differences encountered I just need to add the stdout.build and stderr.build files? - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Mon, 9 Jun 2008 18:10:37 +0000Subject: Re: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 Both NT386GNU and PPC_DARWIN look good to me. I'm double checking something on PPC_DARWIN but expect it'll still look good.If the program builds, please send me the output.also cm3 -keep and the A.mc file. I'll go and check the tinderbox now..if my internet holds up.. Thanks, - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Mon, 9 Jun 2008 17:48:03 +0000Subject: Re: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 This is a new test that I just added and it should work.Do you have any details on the failure?The output?I thought I tested on both NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have to double check though.(Testing on NT386 is less relevant.) In particular, there was a bug here on new/inactiveplatforms and I wanted a test to verify my fix.The bug caused some platforms to bus/alignment error in cm3cg. I will have to double check both that I updated my cm3cg and ran the test.My internet connection is extremely slow lately and thisis hampering me. I have to call tech support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST> > One more test failure compared to yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > ----- Forwarded message from wagner at luthien.in-berlin.de -----> Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > Reply-To: Olaf Wagner > Subject: CM3 regression test from luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > === 2008-06-09 01:30:38 checkout cm3 to > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK checkout 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_lastok_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK build_rel_upgrade 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 build cm3 std in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_std_std 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_std_std_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and runtime regression test > suite in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok version> >>> test_m3tests error extract:> >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> 13 in test_m3tests 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all packages and generate report in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build HTML package doc in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > -- > 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 wagner at elegosoft.com Wed Jun 11 17:13:26 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 11 Jun 2008 17:13:26 +0200 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> Message-ID: <20080611171326.zaa7yv31r4oso4s4@mail.elegosoft.com> Sorry for the long delays; I don't keep up with reading all my mails currently, and haven't got time to really check what's going on in CM3. It seems that the fact that I was able to invest some significant amount of time for the regression test framework some months ago, this is no indication at all that I'll be able to keep it like this. So sorry to all who are waiting for things I should do (like a new CM3 release ):-/ Quoting Jay : > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1213020039.1032 > 27414 --- p211 --- float and double constants work27415 > cd ../src/p2/p211 && cm3 -silent -DM3TESTS > >SOLgnu/stdout.build.raw 2>SOLgnu/stderr.build.raw27416 > ../src/p2/p211/stdout.build is missing27417 > ../src/p2/p211/stderr.build is missing27418 No differences > encountered27419 No differences encountered > I just need to add the stdout.build and stderr.build files? If it's a new test and the files are missing, you probably have to add them. Why doesn't it show up for you on your test platforms? It's no big matter though. I just wondered. Olaf > - Jay > > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > m3devel at elegosoft.comDate: Mon, 9 Jun 2008 18:10:37 +0000Subject: > Re: [M3devel] Fwd: CM3 regression test from > luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 > > > Both NT386GNU and PPC_DARWIN look good to me. I'm double checking > something on PPC_DARWIN but expect it'll still look good.If the > program builds, please send me the output.also cm3 -keep and the > A.mc file. I'll go and check the tinderbox now..if my internet holds > up.. Thanks, - Jay > > > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > m3devel at elegosoft.comDate: Mon, 9 Jun 2008 17:48:03 +0000Subject: > Re: [M3devel] Fwd: CM3 regression test from > luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 > > This is a new test that I just added and it should work.Do you have > any details on the failure?The output?I thought I tested on both > NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have > to double check though.(Testing on NT386 is less relevant.) In > particular, there was a bug here on new/inactiveplatforms and I > wanted a test to verify my fix.The bug caused some platforms to > bus/alignment error in cm3cg. I will have to double check both that > I updated my cm3cg and ran the test.My internet connection is > extremely slow lately and thisis hampering me. I have to call tech > support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: > wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] > Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon > 9 Jun 2008 03:30:38 CEST> > One more test failure compared to > yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > > ----- Forwarded message from wagner at luthien.in-berlin.de -----> > Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > > Reply-To: Olaf Wagner > > Subject: CM3 regression test from > luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> > To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > > === 2008-06-09 01:30:38 checkout cm3 to > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > checkout 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === > 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build > cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > build_lastok_core_lastok 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 > cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last > release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK > build_rel_upgrade 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > build_rel_core 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > build_rel_core_lastok 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 > cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist > snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === > 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 > build cm3 std in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > version> >>> OK build_std_std 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > build_std_std_lastok 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 > cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and > runtime regression test > suite in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok > version> >>> test_m3tests error extract:> >>> failed tests: p116b > p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> > 13 in test_m3tests 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all > packages and generate report in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build > HTML package doc in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: > +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Thu Jun 12 02:44:44 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 11 Jun 2008 20:44:44 -0400 Subject: [M3devel] thread alert problem on NT386 Message-ID: <48503937.1E75.00D7.1@scires.com> I'm running across a problem on Windows XP using threads. Specifically, I am getting the following runtime error: *** *** runtime error: *** Thread client error: Alert called from non-Modula-3 thread *** file "..\src\thread\WIN32\ThreadWin32.m3", line 325 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x5dbfea4 0x5c5e5c Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbfedc 0x5c3acd Alert + 0x35 in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbff2c 0x403bb1 CloseWindow + 0x185 in ..\src\Main.m3 0x5dbff50 0x4082c3 TaskApply + 0x5b in ..\src\Utils.m3 0x5dbff88 0x5c4a6a RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbffb4 0x5c4803 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... Now, I know for a fact that the thread calling Thread.Alert is indeed a modula-3 thread. Any ideas? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 12 03:14:29 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 12 Jun 2008 01:14:29 +0000 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: <20080611171326.zaa7yv31r4oso4s4@mail.elegosoft.com> References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> <20080611171326.zaa7yv31r4oso4s4@mail.elegosoft.com> Message-ID: > add them. Why doesn't it show up for you on your test platforms? I have yet to figure out how to run the Tinderbox correctly. I need to. I tried twice without much luck. Probably should not have bothered with NT386 at the time but used Darwin or such. So I don't see the full reporting or know how it works, what it loks for. I can do cd m3-sys/m3tests; cm3 though. That is much of it and useful. I know to look for "@" for diffs, or other diffs. Maybe I should do cm3 -DHTML? I'll try that. - Jay> Date: Wed, 11 Jun 2008 17:13:26 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3> > Sorry for the long delays; I don't keep up with reading all my> mails currently, and haven't got time to really check what's> going on in CM3. It seems that the fact that I was able to invest> some significant amount of time for the regression test framework> some months ago, this is no indication at all that I'll be able> to keep it like this. So sorry to all who are waiting for things I> should do (like a new CM3 release ):-/> > Quoting Jay :> > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1213020039.1032> > 27414 --- p211 --- float and double constants work27415 > > cd ../src/p2/p211 && cm3 -silent -DM3TESTS > > >SOLgnu/stdout.build.raw 2>SOLgnu/stderr.build.raw27416 > > ../src/p2/p211/stdout.build is missing27417 > > ../src/p2/p211/stderr.build is missing27418 No differences > > encountered27419 No differences encountered> > I just need to add the stdout.build and stderr.build files?> > If it's a new test and the files are missing, you probably have to> add them. Why doesn't it show up for you on your test platforms?> It's no big matter though. I just wondered.> > Olaf> > > - Jay> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > > m3devel at elegosoft.comDate: Mon, 9 Jun 2008 18:10:37 +0000Subject: > > Re: [M3devel] Fwd: CM3 regression test from > > luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3> >> >> > Both NT386GNU and PPC_DARWIN look good to me. I'm double checking > > something on PPC_DARWIN but expect it'll still look good.If the > > program builds, please send me the output.also cm3 -keep and the > > A.mc file. I'll go and check the tinderbox now..if my internet holds > > up.. Thanks, - Jay> >> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > > m3devel at elegosoft.comDate: Mon, 9 Jun 2008 17:48:03 +0000Subject: > > Re: [M3devel] Fwd: CM3 regression test from > > luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3> >> > This is a new test that I just added and it should work.Do you have > > any details on the failure?The output?I thought I tested on both > > NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have > > to double check though.(Testing on NT386 is less relevant.) In > > particular, there was a bug here on new/inactiveplatforms and I > > wanted a test to verify my fix.The bug caused some platforms to > > bus/alignment error in cm3cg. I will have to double check both that > > I updated my cm3cg and ran the test.My internet connection is > > extremely slow lately and thisis hampering me. I have to call tech > > support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: > > wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] > > Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon > > 9 Jun 2008 03:30:38 CEST> > One more test failure compared to > > yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > > > ----- Forwarded message from wagner at luthien.in-berlin.de -----> > > Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > > > Reply-To: Olaf Wagner > > > Subject: CM3 regression test from > > luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> > > To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > > > === 2008-06-09 01:30:38 checkout cm3 to > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > checkout 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === > > 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build > > cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > build_lastok_core_lastok 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 > > cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last > > release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK > > build_rel_upgrade 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > build_rel_core 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > build_rel_core_lastok 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 > > cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist > > snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === > > 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 > > build cm3 std in > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > > version> >>> OK build_std_std 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > build_std_std_lastok 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 > > cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and > > runtime regression test > suite in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok > > version> >>> test_m3tests error extract:> >>> failed tests: p116b > > p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> > > 13 in test_m3tests 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > > 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all > > packages and generate report in > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > > version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > > 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build > > HTML package doc in > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > > version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > > 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH> > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: > > +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | > > USt-IdNr: DE163214194>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jun 12 05:35:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 12 Jun 2008 04:35:11 +0100 Subject: [M3devel] thread alert problem on NT386 In-Reply-To: <48503937.1E75.00D7.1@scires.com> References: <48503937.1E75.00D7.1@scires.com> Message-ID: <40E13342-3A8D-41BD-BA8C-4BC4A445408D@cs.purdue.edu> Jay will need to track this one. I've barely ever touched ThreadWin32. On Jun 12, 2008, at 1:44 AM, Randy Coleburn wrote: > I'm running across a problem on Windows XP using threads. > > Specifically, I am getting the following runtime error: > > *** > *** runtime error: > *** Thread client error: Alert called from non-Modula-3 thread > *** file "..\src\thread\WIN32\ThreadWin32.m3", line 325 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x5dbfea4 0x5c5e5c Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3 > 0x5dbfedc 0x5c3acd Alert + 0x35 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x5dbff2c 0x403bb1 CloseWindow + 0x185 in ..\src\Main.m3 > 0x5dbff50 0x4082c3 TaskApply + 0x5b in ..\src\Utils.m3 > 0x5dbff88 0x5c4a6a RunThread + 0x1f6 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x5dbffb4 0x5c4803 ThreadBase + 0x3a in ..\src\thread > \WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > > Now, I know for a fact that the thread calling Thread.Alert is > indeed a modula-3 thread. > > Any ideas? > > Regards, > Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 12 07:04:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 12 Jun 2008 05:04:22 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? Message-ID: SOLsun..using cm3cg..a bit of a contradiction there? What SOLsun means: Sun cc? Yes. Sun ld? I think so. Only Sun libs? I think so. But cm3cg, emits references to functions in libgcc.Currently just two trivial functions. In fact, I am tempted here to give their "spec"so someone can provide a "free" (non GPL) implementation.Since they get linked into client code. These functions provide unsigned 64 bit division and modulus.Rather than being sensibly named like _uint64div and_uint64mod, their names derive from gcc calling "int64"a "double integer" or "DI". A "single integer" or "SI" is 32 bits. The function prototypes are: unsigned long long __udivdi3 (unsigned long long x, unsigned long long y);unsigned long long __umoddi3 (unsigned long long x, unsigned long long y); Can someone provide "free" implementations?I saw GPLed versions already so I can't.I think I provide a hint though.They can each be implemented in one line of C.As long as the C compiler used - "open codes" then or - calls out to functions with a different name Even if the same name is used, there's a possible workaround using in-between functions. These functions are small enough that static linking should be viable.Currently they are exported from libm3core.so however.Make a separate lib?Currently they are in m3-libs/m3core/src/Csupport/libgcc.Maybe m3-libs/m3coremath/src? This would also be required in SOLsun, and nowhere else currently. There is another "problem" with SOLsun. FloatMode.m3 requires libsunmath.a.Ideally .so files are "fully" position independent and readonly.That is, not merely "relocatable", not merely "patchable" to runat any address, but can run at any address and all "patching" is done"specially" via something like a "RTOC" and/or "GOT" / "PLT" runtime table of contents global offset table procedute linkage table and/or position indepenent addressing modes (for references to self). Tangent: There are a surprisingly number of variables when dynamic linking. Many decisions to make as to the exact semantics. Are things "delay loaded" aka "statically loaded"? When I load m3.so that depends on m3core.so is m3core.so loaded immediately? Are all the functions that m3.so calls resolved immediately? This is a variable one can control through various linker switches. As well, for any function that m3core.so calls and implements, can either another .so, m3.so, or the executable itself, also implement and "replace" or "intercept" or "interpose" those functions? Again, the answer varies. On Windows, the answer is essentially no, not never. Unless you go to some extra length to allow for it. On Unix the answer seems to vary per system and switches. Allowing this interception often requires less efficient code. And at least in one place resulted in buggy code, that I fixed recently, I think it was on AMD64_LINUX. Going through the indirection mechanism, the PLT, trashes the static link in rcx, or something like that. And it is just unnecessary indirection in almost all cases. So, the questions become, what do people want/expect for Modula-3? And, does it vary from person to person? System to system? Windows is "never" going to allow the interposition. Allowing "interposition" also goes by the description "allow unresolved symbols in shared objects", to be resolved at load time. Unix often has one global namespace for all functions in a process. Apple has a similar thing between "one level namespaces" and "two level namespaces". In an older release, they had only one level namespace. Every dynamically imported function would be searched for in all dynamically loaded files. Usually at build time you know the name of the shared object you expect to find the function in. So you can have a "two level namespace" where function names are associated with a particular file name, and only that file is searched. Apple encourages this usage, though of course is bound somewhat by compatibility. You can perhaps still build binaries that run on 10.0, and binaries built to run on 10.0 in the first place can still run today. The need to do either of these is always diminishing but hard to deem zero. SOLsun linker has two related switches. libsunmath.a apparently is not built fully position independent. libm3core.so must link to it, and therefore does not have a fully read only text section. what to do? A few options: Go back to allowing unresolved symbols in SOLsun, enabling "interposition". Then I think libsunmath.a isn't used by .sos, just executables. I don't like this option. Binding functions to particular file names (not paths) seems right and is encouraged by Apple and about the only option on Windows. It seems good to use when available. Allow writable text section in all .so. This is what I commited. Allow writable text section in only libm3core.so. This is a better compromise than previous. Move FloatMode.m3 into a separate so... libm3coremath.so, and only let it have a writable text section. This is a better compromise in terms of amount of writable text, but also adds another .so. The fewer .sos the better, arguably. Change FloatMode.m3 somehow to not use libsunmath.a. I think the only way to do this is to make it do nothing at all, which is probably what most of the implementations do, but I'd have to check. FloatMode.m3 is generally implementable on many systems, like via _controlfp on NT386. It is also dangerous to be mucking with the floating mode -- what code in the process depends on the default and will be broken by it changing? Worse, the SPARC implementation has a comment saying it is implemented process-wide instead of per-thread. Really there are arguments either way. The "common" implementation just asserts false. DS3100, VAX, IRIX, SPARC, SUN386, implement FloatMode. NT386, *_DARWIN, *_LINUX, *_FREEBSD, SOLgnu do not. Maybe just turn it off for SOLsun too? or go through and provide it everywhere? Always per-thread if possible? Only on pthreads implementations preferably? (I'm not a fan of user threads in general, so don't wish to make them "better".) I think removing FloatMode for SOLsun is probably the way to go. See if that removes requirement on libsunmath.a. See if that then allows fully position independent and "resolved" symbols. And maybe there is an updated libsunmath.a? I just have a "random" version of Solaris 10 from eBay. I could try a newer OpenSolaris/Nevada version. Or drop SOLsun as uninteresting? (My internet is slow as I said. I finally finished downloading the "normal" gcc and can build it and try the more active SOLgnu instead.) That would at least ease figuring out the names of: I386_SOLARIS, AMD64_SOLARIS, SPARC64_SOLARIS no need to have two of these of those. :) And is SOLgnu meant to use GNU ld or not? It looks like not. SOLsun and SOLgnu config files are "the same" here. Could be GNU ld is compatible in command line usage though. (not yet -- I almost have the 64 bit hosted cm3cg bug figured out. it occurs the same on SPARC64_OPENBSD as AMD64_LINUX. Something about assignment being DImode vs. VOIDmode. Occurs in many places, including RTRuntimeError.Self, by virtue of it using TRY.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Jun 12 07:04:57 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 12 Jun 2008 01:04:57 -0400 Subject: [M3devel] thread alert problem on NT386 In-Reply-To: <40E13342-3A8D-41BD-BA8C-4BC4A445408D@cs.purdue.edu> References: <48503937.1E75.00D7.1@scires.com> <40E13342-3A8D-41BD-BA8C-4BC4A445408D@cs.purdue.edu> Message-ID: <48507633.1E75.00D7.1@scires.com> Thanks. I've solved the problem. It wound up being my fault. Regards, Randy >>> Tony Hosking 6/11/2008 11:35 PM >>> Jay will need to track this one. I've barely ever touched ThreadWin32. On Jun 12, 2008, at 1:44 AM, Randy Coleburn wrote: I'm running across a problem on Windows XP using threads. Specifically, I am getting the following runtime error: *** *** runtime error: *** Thread client error: Alert called from non-Modula-3 thread *** file "..\src\thread\WIN32\ThreadWin32.m3", line 325 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x5dbfea4 0x5c5e5c Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbfedc 0x5c3acd Alert + 0x35 in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbff2c 0x403bb1 CloseWindow + 0x185 in ..\src\Main.m3 0x5dbff50 0x4082c3 TaskApply + 0x5b in ..\src\Utils.m3 0x5dbff88 0x5c4a6a RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbffb4 0x5c4803 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... Now, I know for a fact that the thread calling Thread.Alert is indeed a modula-3 thread. Any ideas? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Jun 12 07:26:09 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 12 Jun 2008 01:26:09 -0400 Subject: [M3devel] how to obtain screen size of a FormsVBT.T Message-ID: <48507B2B.1E75.00D7.1@scires.com> Using Trestle / FormsVBT / et al, I want to be able to place a new window in the center of the screen. Trestle.Overlap() seems to be the only way I've seen where you can specify the location of the window. Now, the problem I am having is how to determine the size of a particular FormsVBT.T instance so that I can compute where it should go on the screen. It seems that before the FormsVBT.T is actually displayed on the screen that its dimensions aren't readily visible. Here is the way I am using to find out the middle of the screen: trestle := Trestle.Connect(NIL); s := Trestle.GetScreens(trestle); middle := Rect.Middle(s[0].dom); Not sure if this is the best way, but it seems to work. Now, if I have built a FormsVBT.T, say via v := NEW(FormsVBT.T).initFromRsrc(...), I then call Trestle.Attach(v, trestle); >From this point onward, all the methods I have used to try and find out the dimensions of "v" don't seem to work reliably. If I could find out the horizontal (hsize) and vertical (vsize) dimensions of "v", I could make the following calls to place "v" in the center of the screen: nw := Point.Sub(middle, Point.FromCoords(hsize DIV 2, vsize DIV 2); Trestle.Overlap(v, s[0].id, nw); Indeed, if I make an educated guess about hsize and vsize the window is placed properly. But, of course, I need to reliably determine the size of an arbitrary window at runtime. I'd appreciate any insight anyone can give. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 12 14:23:17 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 12 Jun 2008 12:23:17 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? Message-ID: My inclination on the FloatMode/libsunmath issue is to not build the SOLsun FloatMode support, and then see/hope if libsunmath isn't otherwise needed, and -z text otherwise "works" -- if the rest of the system can be built with it. The majority of all platforms and all "current" "active" platforms do not implement FloatMode. It is a negative trend, but I can go along. If that changes, then I'd reconsider. Hopefully there is a better libsunmath.a available too though, or a better way to implement this, perhaps in assembly, maybe some of those new #pragma fenv things.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?Date: Thu, 12 Jun 2008 05:04:22 +0000 SOLsun..using cm3cg..a bit of a contradiction there?What SOLsun means: Sun cc? Yes. Sun ld? I think so. Only Sun libs? I think so.But cm3cg, emits references to functions in libgcc.Currently just two trivial functions.In fact, I am tempted here to give their "spec"so someone can provide a "free" (non GPL) implementation.Since they get linked into client code.These functions provide unsigned 64 bit division and modulus.Rather than being sensibly named like _uint64div and_uint64mod, their names derive from gcc calling "int64"a "double integer" or "DI". A "single integer" or "SI" is 32 bits.The function prototypes are:unsigned long long __udivdi3 (unsigned long long x, unsigned long long y);unsigned long long __umoddi3 (unsigned long long x, unsigned long long y);Can someone provide "free" implementations?I saw GPLed versions already so I can't.I think I provide a hint though.They can each be implemented in one line of C.As long as the C compiler used - "open codes" then or - calls out to functions with a different name Even if the same name is used, there's a possible workaround using in-between functions.These functions are small enough that static linking should be viable.Currently they are exported from libm3core.so however.Make a separate lib?Currently they are in m3-libs/m3core/src/Csupport/libgcc.Maybe m3-libs/m3coremath/src?This would also be required in SOLsun, and nowhere else currently.There is another "problem" with SOLsun.FloatMode.m3 requires libsunmath.a.Ideally .so files are "fully" position independent and readonly.That is, not merely "relocatable", not merely "patchable" to runat any address, but can run at any address and all "patching" is done"specially" via something like a "RTOC" and/or "GOT" / "PLT" runtime table of contents global offset table procedute linkage table and/or position indepenent addressing modes (for references to self).Tangent: There are a surprisingly number of variables when dynamic linking. Many decisions to make as to the exact semantics. Are things "delay loaded" aka "statically loaded"? When I load m3.so that depends on m3core.so is m3core.so loaded immediately? Are all the functions that m3.so calls resolved immediately? This is a variable one can control through various linker switches. As well, for any function that m3core.so calls and implements, can either another .so, m3.so, or the executable itself, also implement and "replace" or "intercept" or "interpose" those functions? Again, the answer varies. On Windows, the answer is essentially no, not never. Unless you go to some extra length to allow for it. On Unix the answer seems to vary per system and switches. Allowing this interception often requires less efficient code. And at least in one place resulted in buggy code, that I fixed recently, I think it was on AMD64_LINUX. Going through the indirection mechanism, the PLT, trashes the static link in rcx, or something like that. And it is just unnecessary indirection in almost all cases. So, the questions become, what do people want/expect for Modula-3? And, does it vary from person to person? System to system? Windows is "never" going to allow the interposition. Allowing "interposition" also goes by the description "allow unresolved symbols in shared objects", to be resolved at load time. Unix often has one global namespace for all functions in a process. Apple has a similar thing between "one level namespaces" and "two level namespaces". In an older release, they had only one level namespace. Every dynamically imported function would be searched for in all dynamically loaded files. Usually at build time you know the name of the shared object you expect to find the function in. So you can have a "two level namespace" where function names are associated with a particular file name, and only that file is searched. Apple encourages this usage, though of course is bound somewhat by compatibility. You can perhaps still build binaries that run on 10.0, and binaries built to run on 10.0 in the first place can still run today. The need to do either of these is always diminishing but hard to deem zero. SOLsun linker has two related switches. libsunmath.a apparently is not built fully position independent. libm3core.so must link to it, and therefore does not have a fully read only text section. what to do? A few options: Go back to allowing unresolved symbols in SOLsun, enabling "interposition". Then I think libsunmath.a isn't used by .sos, just executables. I don't like this option. Binding functions to particular file names (not paths) seems right and is encouraged by Apple and about the only option on Windows. It seems good to use when available. Allow writable text section in all .so. This is what I commited. Allow writable text section in only libm3core.so. This is a better compromise than previous. Move FloatMode.m3 into a separate so... libm3coremath.so, and only let it have a writable text section. This is a better compromise in terms of amount of writable text, but also adds another .so. The fewer .sos the better, arguably. Change FloatMode.m3 somehow to not use libsunmath.a. I think the only way to do this is to make it do nothing at all, which is probably what most of the implementations do, but I'd have to check. FloatMode.m3 is generally implementable on many systems, like via _controlfp on NT386. It is also dangerous to be mucking with the floating mode -- what code in the process depends on the default and will be broken by it changing? Worse, the SPARC implementation has a comment saying it is implemented process-wide instead of per-thread. Really there are arguments either way. The "common" implementation just asserts false. DS3100, VAX, IRIX, SPARC, SUN386, implement FloatMode. NT386, *_DARWIN, *_LINUX, *_FREEBSD, SOLgnu do not. Maybe just turn it off for SOLsun too? or go through and provide it everywhere? Always per-thread if possible? Only on pthreads implementations preferably? (I'm not a fan of user threads in general, so don't wish to make them "better".) I think removing FloatMode for SOLsun is probably the way to go. See if that removes requirement on libsunmath.a. See if that then allows fully position independent and "resolved" symbols. And maybe there is an updated libsunmath.a? I just have a "random" version of Solaris 10 from eBay. I could try a newer OpenSolaris/Nevada version. Or drop SOLsun as uninteresting? (My internet is slow as I said. I finally finished downloading the "normal" gcc and can build it and try the more active SOLgnu instead.) That would at least ease figuring out the names of: I386_SOLARIS, AMD64_SOLARIS, SPARC64_SOLARIS no need to have two of these of those. :) And is SOLgnu meant to use GNU ld or not? It looks like not. SOLsun and SOLgnu config files are "the same" here. Could be GNU ld is compatible in command line usage though. (not yet -- I almost have the 64 bit hosted cm3cg bug figured out. it occurs the same on SPARC64_OPENBSD as AMD64_LINUX. Something about assignment being DImode vs. VOIDmode. Occurs in many places, including RTRuntimeError.Self, by virtue of it using TRY.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jun 12 16:51:18 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 12 Jun 2008 15:51:18 +0100 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: Message-ID: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> There's too much in your e-mail to respond to Jay, so I'll just make a simple historical observation: SOLgnu was originally intended as a Solaris target where there was no availability of Sun's cc (Sun did not bundle cc with the OS at the time -- they wanted you to buy it!). However, the rest of the Solaris toolchain has always been bundled with the OS. Thus, with gcc the easiest free option as a replacement for cc, SOLgnu meant folks could use Modula-3 without having to buy Sun's cc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jun 12 16:51:45 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 12 Jun 2008 15:51:45 +0100 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: Message-ID: <330E728C-016F-465F-9D2D-CDC53A332A70@cs.purdue.edu> I think I agree with you here. On Jun 12, 2008, at 1:23 PM, Jay wrote: > My inclination on the FloatMode/libsunmath issue is to not build the > SOLsun FloatMode support, and then see/hope if libsunmath isn't > otherwise needed, and -z text otherwise "works" -- if the rest of > the system can be built with it. > The majority of all platforms and all "current" "active" platforms > do not implement FloatMode. > It is a negative trend, but I can go along. > If that changes, then I'd reconsider. > Hopefully there is a better libsunmath.a available too though, or a > better way to implement this, perhaps in assembly, maybe some of > those new #pragma fenv things.. > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? > Date: Thu, 12 Jun 2008 05:04:22 +0000 > > SOLsun..using cm3cg.. > a bit of a contradiction there? > > What SOLsun means: > Sun cc? Yes. > Sun ld? I think so. > Only Sun libs? I think so. > > But cm3cg, emits references to functions in libgcc. > Currently just two trivial functions. > > In fact, I am tempted here to give their "spec" > so someone can provide a "free" (non GPL) implementation. > Since they get linked into client code. > > These functions provide unsigned 64 bit division and modulus. > Rather than being sensibly named like _uint64div and > _uint64mod, their names derive from gcc calling "int64" > a "double integer" or "DI". A "single integer" or "SI" is 32 bits. > > The function prototypes are: > > unsigned long long __udivdi3 (unsigned long long x, unsigned long > long y); > unsigned long long __umoddi3 (unsigned long long x, unsigned long > long y); > > Can someone provide "free" implementations? > I saw GPLed versions already so I can't. > I think I provide a hint though. > They can each be implemented in one line of C. > As long as the C compiler used > - "open codes" then > or - calls out to functions with a different name > > Even if the same name is used, there's a possible workaround using > in-between functions. > > These functions are small enough that static linking should be viable. > Currently they are exported from libm3core.so however. > Make a separate lib? > Currently they are in m3-libs/m3core/src/Csupport/libgcc. > Maybe m3-libs/m3coremath/src? > > This would also be required in SOLsun, and nowhere else currently. > > There is another "problem" with SOLsun. > FloatMode.m3 requires libsunmath.a. > Ideally .so files are "fully" position independent and readonly. > That is, not merely "relocatable", not merely "patchable" to run > at any address, but can run at any address and all "patching" is done > "specially" via something like a "RTOC" and/or "GOT" / "PLT" > runtime table of contents > global offset table > procedute linkage table > and/or position indepenent addressing modes (for references to self). > > Tangent: > There are a surprisingly number of variables when dynamic linking. > Many decisions to make as to the exact semantics. > Are things "delay loaded" aka "statically loaded"? > When I load m3.so that depends on m3core.so is > m3core.so loaded immediately? > Are all the functions that m3.so calls resolved immediately? > This is a variable one can control through various linker switches. > As well, for any function that m3core.so calls and implements, > can either another .so, m3.so, or the executable itself, also > implement and "replace" or "intercept" or "interpose" those > functions? > Again, the answer varies. > On Windows, the answer is essentially no, not never. Unless you go > to > some extra length to allow for it. > On Unix the answer seems to vary per system and switches. > Allowing this interception often requires less efficient code. > And at least in one place resulted in buggy code, that I fixed > recently, > I think it was on AMD64_LINUX. Going through the indirection > mechanism, the PLT, > trashes the static link in rcx, or something like that. > And it is just unnecessary indirection in almost all cases. > So, the questions become, what do people want/expect for Modula-3? > And, does it vary from person to person? System to system? > Windows is "never" going to allow the interposition. > Allowing "interposition" also goes by the description "allow > unresolved symbols in shared objects", to be resolved at load time. > Unix often has one global namespace for all functions in a process. > Apple has a similar thing between "one level namespaces" and "two > level namespaces". > In an older release, they had only one level namespace. Every > dynamically imported > function would be searched for in all dynamically loaded files. > Usually at build time you know the name of the shared object you > expect to find > the function in. So you can have a "two level namespace" where > function names > are associated with a particular file name, and only that file is > searched. > Apple encourages this usage, though of course is bound somewhat by > compatibility. > You can perhaps still build binaries that run on 10.0, and > binaries built to run > on 10.0 in the first place can still run today. > The need to do either of these is always diminishing but hard to > deem zero. > > SOLsun linker has two related switches. > libsunmath.a apparently is not built fully position independent. > libm3core.so must link to it, and therefore does not have a fully > read only text section. > > what to do? > > A few options: > Go back to allowing unresolved symbols in SOLsun, enabling > "interposition". > Then I think libsunmath.a isn't used by .sos, just executables. > I don't like this option. Binding functions to particular file > names (not paths) > seems right and is encouraged by Apple and about the only option > on Windows. > It seems good to use when available. > > Allow writable text section in all .so. > This is what I commited. > > Allow writable text section in only libm3core.so. > This is a better compromise than previous. > > Move FloatMode.m3 into a separate so... libm3coremath.so, > and only let it have a writable text section. > This is a better compromise in terms of amount of writable text, > but also > adds another .so. The fewer .sos the better, arguably. > > Change FloatMode.m3 somehow to not use libsunmath.a. > I think the only way to do this is to make it do nothing at all, > which > is probably what most of the implementations do, but I'd have to > check. > FloatMode.m3 is generally implementable on many systems, like via > _controlfp > on NT386. It is also dangerous to be mucking with the floating > mode -- > what code in the process depends on the default and will be > broken by it changing? > > Worse, the SPARC implementation has a comment saying it is > implemented process-wide > instead of per-thread. Really there are arguments either way. > > The "common" implementation just asserts false. > DS3100, VAX, IRIX, SPARC, SUN386, implement FloatMode. > NT386, *_DARWIN, *_LINUX, *_FREEBSD, SOLgnu do not. > > Maybe just turn it off for SOLsun too? > or go through and provide it everywhere? Always per-thread if > possible? > Only on pthreads implementations preferably? > (I'm not a fan of user threads in general, so don't wish to make > them "better".) > > I think removing FloatMode for SOLsun is probably the way to go. > See if that removes requirement on libsunmath.a. > See if that then allows fully position independent and "resolved" > symbols. > > And maybe there is an updated libsunmath.a? > I just have a "random" version of Solaris 10 from eBay. > I could try a newer OpenSolaris/Nevada version. > > Or drop SOLsun as uninteresting? > (My internet is slow as I said. I finally finished downloading > the "normal" gcc and can build it and try the more active SOLgnu > instead.) > > That would at least ease figuring out the names of: > I386_SOLARIS, AMD64_SOLARIS, SPARC64_SOLARIS > > no need to have two of these of those. :) > > And is SOLgnu meant to use GNU ld or not? > It looks like not. SOLsun and SOLgnu config files are "the same" > here. > Could be GNU ld is compatible in command line usage though. > > (not yet -- I almost have the 64 bit hosted cm3cg bug figured out. > it occurs the same on SPARC64_OPENBSD as AMD64_LINUX. Something about > assignment being DImode vs. VOIDmode. Occurs in many places, > including > RTRuntimeError.Self, by virtue of it using TRY.) > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 12 19:21:47 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 12 Jun 2008 17:21:47 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> Message-ID: Ok I'll have to send out some smaller mails. Hey, I figure, you get the quality of email you pay me for. :) The "obvious" question is, sort of, does anyone give a darn about SOLsun? Using it actively? Wanting it back? Not that I'm only "focusing" (haha) on platforms that people care about, I'm aiming at any mildly interesting target, as an exercise of some sort. (and yes, I know I'm leaving some things a bit incomplete and hope to sweep up before I get too far ahead -- AMD64_LINUX garbage colllection, NT386MINGNU __stdcall being among the older/severest issues; the AMD64_LINUX native cm3cg issue occurs on SPARC64_OPENBSD as well, I hope to fix that "next", have been stepping through looking for where things vary, vs. a cross build from NT386GNU that works..DImode vs. VOIDmode on some assignment statements..the output of cm3cg -y is identical, the output of cm3cg -da is identical before the crash except for pointers, was a while before I remember about the various -d switches, stepping through the code saw a reference to "dump_file"..). Another question is, does anyone give a darn what linker is used on SOL*? If the matter is just to use what is most easily/cheaply acquired, then the answer is use the Sun ld. Perhaps if the matter is "cross platform compatibility" then GNU, perhaps. (ie: bring along as much as you can so you can keep as much the same as possible, such as command lines/config file contents). I "just" got Solaris (8,9,10, less luck with getting 8,9 running though, so sticking with 10) from eBay. I don't know the "real" current bundling/pricing, though the OS itself is now free at least as in beer, tools I suspect too but I don't yet have the free stuff running. The free stuff seems to be kept more up to date for x86 -- at least the current release is x86 only and you have to go back a bit for SPARC. I'm not sure about AMD64. I figure they are catering to a "low end community" and hope to still charge money for the "high end" SPARC hardware (though really I expect x86/AMD64 continues to eat into everyone's lunch... as it gets steadily faster/cheaper...(and yeah, I386_SOLARIS, AMD64_SOLARIS, SPARC64_SOLARIS all on my radar but need to wait..) If the tools are free, SOLgnu becomes less interesting and SOLsun more interesting?? Or, we just run a simple market economy here and demand is pretty little all around, hard to tell? :) It happened to be a little easier/quicker/earlier for me get Sun cc up vs. gcc. But I'm wierd. I actually don't have gcc/Solaris up yet, but should before much longer. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?Date: Thu, 12 Jun 2008 15:51:18 +0100 There's too much in your e-mail to respond to Jay, so I'll just make a simple historical observation: SOLgnu was originally intended as a Solaris target where there was no availability of Sun's cc (Sun did not bundle cc with the OS at the time -- they wanted you to buy it!). However, the rest of the Solaris toolchain has always been bundled with the OS. Thus, with gcc the easiest free option as a replacement for cc, SOLgnu meant folks could use Modula-3 without having to buy Sun's cc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jun 13 11:27:44 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 13 Jun 2008 11:27:44 +0200 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> Message-ID: <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> Quoting Jay : > > Ok I'll have to send out some smaller mails. Hey, I figure, you get > the quality of email you pay me for. :) Could you be more elaborate on who exactly is paying you for M3 work? ;-) I'd like to share this experience... > The "obvious" question is, sort of, does anyone give a darn about SOLsun? > Using it actively? > Wanting it back? Not personally, but I'd just like to remind you of the fact that the Sun compilers were/are highly optimized for the SPARC architecture, so that in certain performance critical domains nobody would use gcc. I don't really know if this is still a current problem of gcc, nor do I know if it has much impacts on CM3 as the gcc backend is used anyway for all M3 code. It would be interesting how good or bad M3s compiled code actually is wrt. the different target platforms... I've got no intention to set up benchmark testing for this though ;-) > Another question is, does anyone give a darn what linker is used on SOL*? > If the matter is just to use what is most easily/cheaply acquired, > then the answer is use the Sun ld. > Perhaps if the matter is "cross platform compatibility" then GNU, > perhaps. (ie: bring along as much as you can so you can keep as much > the same as possible, such as command lines/config file contents). Are there any important differences in the linkers? I wouldn't care much otherwise. 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 13 15:33:47 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 13 Jun 2008 15:33:47 +0200 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <485227DD.1E75.00D7.1@scires.com> References: <48508629.1E75.00D7.1@scires.com> <48510198.1E75.00D7.1@scires.com> <48514EB1.1E75.00D7.1@scires.com> <48519947.1E75.00D7.1@scires.com> <20080613123201.p9rtnudjc4c8400s@mail.elegosoft.com> <485227DD.1E75.00D7.1@scires.com> Message-ID: <20080613153347.vrgtyp5ggk8kwkgo@mail.elegosoft.com> Hi Randy, thanks for the excellent summary. I'm not totally against your suggested extensions; I only try to avoid the additional variables (though they may be in the spirit of the interface). You need three additional boolean variables in Stdio.i3 to determine if one of them is lazy. If instead we had a class LazyConsoleWr.T as a subclass of Wr.T, it could be assigned to the existing Stdio.stdout variable on Windows. The only addition of this type could be the boolean function isVisible(). You could then check for the `lazyness' of the writer by calling ISTYPE( Stdio.stdout, LazyConsoleWr.T ), and if that yields true, determine if the lazy console is visible by NARROW( Stdio.stdout, LazyConsoleWr.T ).isVisible(). This would be a more object-oriented approach. I'm not sure if it really is worth the effort or if we shouldn't just live with the additional variables though. I'm also not sure if it is feasible from an implementation point of view, as I haven't had a look at the initialization code in Windows. As this hasn't been discussed on the m3devel list, and others may have interesting opinions on this, I'd like to raise this issue there, too, in the hope that we agree on a solution soon. I've added your original proposal at the end for reference. Best regards, Olaf Quoting Randy Coleburn : > I agree that adding variables to an interface is not normally a good > idea, BUT that is the way Stdio is set up currently. It uses variables > for stdout, stderr, stdin, and bufferedStderr. The client is free to > change these assignments (and indeed I have programs that do) to change > the runtime behavior. For example, you can make Stdio.stdout a TeeWr.T > to get output going to both stdout and a log file at the same time. > > Stdio provides Wr.T's for stdout & stderr, and a Rd.T for stdin. The > client doesn't really know anything else about them. I gather that Jay > is suggesting that I internally subtype these to be something else and > then externally check for the type, but I don't think this is feasible > without some interface changes that may break existing code. (I welcome > more discussion on this point.) > > The problem we have with the whole lazy console allocation issue is > that the behavior is not documented in an interface and thus there is no > way to control it. Indeed, the whole mess is hidden in the LazyConsole > module buried inside the Win32 subfolder. For Unix, there is no such > thing as lazy console allocation and indeed it is possible for one of > the Stdout variables to be NIL. On cm3 v4.1, it is also possible for > one of the Stdout variables to be NIL, especially when the program is a > GUI-mode program. > > So from a platform-independent view, we currently (cm3 v d5.7.0) have > the following four possibilities for each of the Stdio variables: > 1. variable represents a valid writer/reader to an allocated console > window (or other file/device if command line redirection or pipelining > is used); > 2. variable represents a lazy-allocated console window that is not yet > visible; > 3. variable represents a lazy-allocated console window that has popped > up on the screen (probably occluding part of the real gui window); > 4. variable is NIL because the process has no standard file handle of > this type (but only if not running on Windows). > > Since the lazy-allocation is hidden from view, the client code has no > way of knowing reliably at runtime which of the 4 states the program is > in, and on Windows the state can change dynamically from #2 to #3 (it is > not constant as when on Unix). > > On cm3 v4.1, states #2 & #3 did not exist, so clients could simply > check if the variable was NIL to know whether I/O to the Stdout > variables would work. But now, on cm3 v5.7 there is no way to make this > check reliably on all platforms because on Windows state #4 cannot exist > and states #2 and #3 are hidden from the programmer. Further, since > this behavior is not documented in an interface, the change from 4.1 to > 5.7 breaks existing 4.1 code. When I say "breaks" I don't mean > necessarily that the program crashes, but rather that the behavior is > different than expected and thus "broken". > > Now the primary advantage (possibly the only advantage) to the new lazy > console allocation scheme on Windows is that your GUI-mode program won't > crash if you write to stdout without ensuring it is non-NIL. (Maybe > this begs the question of whether the lazy-allocation is really > needed.) > > The proposal I made has the following advantages: > A. It does not break any existing code. > B. It keeps the same spirit of Stdio in terms of using variables. > C. It gives programmers the opportunity to prevent or allow the lazy > pop-up console windows. > D. If programmers don't make a choice about the lazy pop-up windows, > there is no change in behavior from current operation. > E. It works on Unix or Windows (thus is platform-independent) > F. It allows programmers to go back and easily adjust old code built > for cm3 v4.1 to work as expected when built using cm3 5.7. > > The proposal has the following disadvantages: > X. It continues the practice of putting variables in an interface > (assuming this practice is frowned upon) > Y. Since it augments two prominent interfaces (Stdio & Process), it > will require rebuilding of everything. > Z. Programmers using features of the revised interfaces won't be able > to compile their code using older versions of cm3. > > Here is a quick example showing the utility of knowing at runtime about > the lazy allocation: Suppose you have a -GUI mode program. There is a > lot of code in libraries et al that expects to write to stdout to > provide error messages, etc. If the user calls my -GUI program with the > wrong arguments, I want to give him an error message. In the current > situation on Windows, if I write to stdout or stderr, I will get a > pop-up console window that will flash up briefly, but disappear as soon > as the program terminates. On Unix, the behavior is different since > there is no pop-up console window. If I knew at runtime that the > stdout/stderr was lazy-allocated, I could pause for a few seconds to > allow the user to see the error message on the pop-up console, or I > could redirect the message to a file, or I could even require the user > to acknowledge the pop-up console message by pressing Enter on the > keyboard before terminating the program. I could also choose not to > send output to stdout when the console is lazy-allocated and thus > prevent an extra icon from showing up in the task bar. In short, I > believe the lazy-allocation needs to be exposed so programmers can deal > with it appropriately for the operating context of their program. > > If you don't want to go the route of my proposal, I'm welcome to hear > another suggestion on how to expose runtime knowledge of the lazy > allocation. > > Regards, > Randy Original proposal: 1. Add procedure AreStdFileHandlesLazy (VAR stdIn_IsLazy, stdOut_IsLazy, stdErr_IsLazy: BOOLEAN) to interface Process. This won't break any existing code since it is a new procedure addition, but it will force rebuilding of everything. 2. Adjust internals of Process implementations to deal with implementation of this new procedure. The procedure's parameter output values for all platforms will be FALSE, except for Windows where they will depend on whether the file is lazily allocated. These changes will be transparent to all clients. 3. Add following variables to Stdio interface: stdIn_IsLazy, stdOut_IsLazy, stdErr_IsLazy: BOOLEAN; This change won't break any existing code, but it will force rebuilding of everything. 4. Modify Stdio implementation to properly initialize the new variables during module initialization. This change will be transparent to all clients. Now, with these changes, it will be possible for a client to know whether stdout, stderr, and/or stdin represent lazily allocated consoles or not, then act accordingly. For example, if I want to make sure messages written to stdout are recorded even for a GUI-app, but I don't want a popup, I could do the following: IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) THEN Stdio.stdout := FileWr.Open("myLogFile.txt"); Stdio.stdOut_IsLazy := FALSE; END; Now the above code fragment does show the possibility of a race condition in multi-threaded code. I suggest that a comment be added to the Stdio interface that states any manipulation of the exposed variables should be done from single-threaded code or that the client should implement use of a mutex. Otherwise, we could change Stdio to have get/set procedures, but that would break a lot of existing code. Indeed, instead of changing the Stdio interface, it would be better IMO to just provide an extra interface/implementation that provides these functions and tell new multi-threaded clients to use the thread-friendly version. Please let me know what you think about this proposal. If it is okay, I'd like to go ahead and make the changes to the repository, including adding a warning comment about thread friendliness. I won't provide the extra thread-friendly interface/implementation of Stdio unless you want it. Now that I think about it, I should also add the following function procedures to Stdio (3 variants, one each for stdout, stderr, and stdin) and that would probably eliminate need for the thread-friendly interface: PROCEDURE EnsureNotLazyStdOut (alternateWr: Wr.T) : BOOLEAN = (* If stdout is NIL or lazily allocated, replace it by alternateWr, which must be a valid writer (non-nil). Returns TRUE if alternateWr is substituted for stdout; otherwise returns FALSE. Note that this function is thread-safe. *) BEGIN <*ASSERT alternateWr # NIL*> LOCK privateMutex DO IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) THEN Stdio.stdout := alternateWr; Stdio.stdOut_IsLazy := FALSE; RETURN TRUE; ELSE RETURN FALSE; END; END; END EnsureNotLazyStdOut; -- 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 jayk123 at hotmail.com Sat Jun 14 00:58:05 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 13 Jun 2008 22:58:05 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> Message-ID: Right, good point, gcc usually generates worse code than any other compiler. "We" don't have much C code though, so the compiler is mostly just a driver for the linker. > It would be interesting how good or bad M3s compiled code actually The little I've looked at is not good, but nobody notices. Besides I don't want to pay the time or the risk or lost debugability of gcc's optimizer so I don't use it lately. The integrated backend is quite in the middle. It does certain local optimizations all the time, but lacks analysis over a larger scope.> Are there any important differences in the linkers? I wouldn't care> much otherwise. I don't know. I'm still working on getting gcc and ld built/installed/working, though might skip them. Sun ld is what is in use and, for once, I'll say I have enough other stuff to leave this very very low priority. (My ambition on this platform is basically -- make sure I can build it, make sure I can build a distribution, finally introduce "version.txt" now having Solaris /bin/sh/sed/awk to test with!, and then add introduce SPARC64_SOLARIS -- begging the question of GNU/Sun targets...) Hm, speaking of version.txt -- if I test on Solaris 10, good enough? Are folks on this list using Modula-3 on older versions of Solaris? Even so, what works on 10 "probably" works on older. - Jay> Date: Fri, 13 Jun 2008 11:27:44 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?> > Quoting Jay :> > >> > Ok I'll have to send out some smaller mails. Hey, I figure, you get > > the quality of email you pay me for. :)> > Could you be more elaborate on who exactly is paying you for M3 work? ;-)> I'd like to share this experience...> > > The "obvious" question is, sort of, does anyone give a darn about SOLsun?> > Using it actively?> > Wanting it back?> > Not personally, but I'd just like to remind you of the fact that> the Sun compilers were/are highly optimized for the SPARC architecture,> so that in certain performance critical domains nobody would use> gcc. I don't really know if this is still a current problem of gcc,> nor do I know if it has much impacts on CM3 as the gcc backend is> used anyway for all M3 code.> > It would be interesting how good or bad M3s compiled code actually> is wrt. the different target platforms... I've got no intention to> set up benchmark testing for this though ;-)> > > Another question is, does anyone give a darn what linker is used on SOL*?> > If the matter is just to use what is most easily/cheaply acquired, > > then the answer is use the Sun ld.> > Perhaps if the matter is "cross platform compatibility" then GNU, > > perhaps. (ie: bring along as much as you can so you can keep as much > > the same as possible, such as command lines/config file contents).> > Are there any important differences in the linkers? I wouldn't care> much otherwise.> > 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 hosking at cs.purdue.edu Sat Jun 14 13:43:07 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 14 Jun 2008 12:43:07 +0100 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> Message-ID: Can you justify that statement? On Jun 13, 2008, at 11:58 PM, Jay wrote: > > Right, good point, gcc usually generates worse code than any other > compiler From jayk123 at hotmail.com Sat Jun 14 19:32:32 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 14 Jun 2008 17:32:32 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> Message-ID: mostly rumor, hearsay..sorryI had some examples a few months ago but too lazy to dig them up. - Jay> CC: wagner at elegosoft.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> To: jayk123 at hotmail.com> Subject: Re: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?> Date: Sat, 14 Jun 2008 12:43:07 +0100> > Can you justify that statement?> > On Jun 13, 2008, at 11:58 PM, Jay wrote:> > >> > Right, good point, gcc usually generates worse code than any other > > compiler> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jun 15 14:20:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 15 Jun 2008 12:20:12 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> Message-ID: Ok, I'm able to build SOLsun now.I uploaded min and std archives. Juno and some other apps can display on Cygwin. caveats: I forgot to put in Unix.common. Just copy it in from the source tree. I haven't yet been able to build cm3cg, so I used one from a daily SOLgnu (and it depends on libiconv) whatever Sun cc I have (5.8 2005/10/13), won't bootstrap gcc 4.3.1. It doesn't like for example #define FOO(a,b) blah FOO(,c) I'd rather not just download prebuilt binaries.I'll try (Canadian) crossing from Cygwin, else a more current Solaris.Cross is tricky. It is well documented you need to copy over /usr/include,but less clear to me about libs like values*.o, needed for building libgcc,which is needed at some point it seems, or at least there is an attempt to use it..and then not clear to use /usr/local//lib, or -sysroot=/usr/local/ and mimic structure from there (include vs. usr/include, lib vs. usr/lib and usr/ccs/lib)..I'll see... A lot of the cross documentation and friendly wrappers assumes crossing from Linux to Linux. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?Date: Thu, 12 Jun 2008 17:21:47 +0000 ......snip...... -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Jun 18 16:36:59 2008 From: rodney.bates at wichita.edu (rodney.bates) Date: Wed, 18 Jun 2008 09:36:59 -0500 Subject: [M3devel] =?iso-8859-1?q?proposal_for_dealing_with_lazy_console--?= =?iso-8859-1?q?please_review_and_=09comment!?= Message-ID: <481A920F@webmail.wichita.edu> I don't understand well enough what it means for a console to be lazily-allocated, but I wonder if it makes any sense to allow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T ever be lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside procedures that do it in a thread-safe way? >4. Modify Stdio implementation to properly initialize the new >variables during module initialization. >This change will be transparent to all clients. > >Now, with these changes, it will be possible for a client to know >whether stdout, stderr, and/or stdin represent lazily allocated >consoles or not, then act accordingly. > >For example, if I want to make sure messages written to stdout are >recorded even for a GUI-app, but I don't want a popup, I could do the >following: > IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) > THEN > Stdio.stdout := FileWr.Open("myLogFile.txt"); > Stdio.stdOut_IsLazy := FALSE; > END; >Now the above code fragment does show the possibility of a race >condition in multi-threaded code. > Rodney Bates Retired assistant professor Computer Science From rcoleburn at scires.com Wed Jun 18 18:50:29 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 18 Jun 2008 12:50:29 -0400 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <481A920F@webmail.wichita.edu> References: <481A920F@webmail.wichita.edu> Message-ID: <48590490.1E75.00D7.1@scires.com> Hi Rodney: Thanks for your reply. The issue is that for cm3 on Windows you can specify -gui as a command line option. This option causes the program to be built as a Windows GUI-mode application, rather than as a console application. For a GUI-mode application, the Stdio file handles are NIL because it has no console. Seemingly, to prevent a lot of errors when trying to read/write Stdio, some folks introduced the idea of a lazy console post cm3 v4.1. What happens now "under the covers" is that on a GUI-mode program the Stdio file handles are allocated as Lazy Consoles. Then, whenever Stdio.stdout/stderr/stdin is used, the underlying code realizes the first use and magically allocates a new console window on the fly. This console window pops up on the screen on top of your GUI-mode window. My objection is that this behavior is not documented in any interface and the programmer has no way to control the behavior. I want to make such control possible. Hope this explanation helps a bit. Regards, Randy >>> "rodney.bates" 6/18/2008 10:36 AM >>> I don't understand well enough what it means for a console to be lazily-allocated, but I wonder if it makes any sense to allow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T ever be lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside procedures that do it in a thread-safe way? >4. Modify Stdio implementation to properly initialize the new >variables during module initialization. >This change will be transparent to all clients. > >Now, with these changes, it will be possible for a client to know >whether stdout, stderr, and/or stdin represent lazily allocated >consoles or not, then act accordingly. > >For example, if I want to make sure messages written to stdout are >recorded even for a GUI-app, but I don't want a popup, I could do the >following: > IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) > THEN > Stdio.stdout := FileWr.Open("myLogFile.txt"); > Stdio.stdOut_IsLazy := FALSE; > END; >Now the above code fragment does show the possibility of a race >condition in multi-threaded code. > Rodney Bates Retired assistant professor Computer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jun 18 19:20:03 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 18 Jun 2008 17:20:03 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <48590490.1E75.00D7.1@scires.com> References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> Message-ID: Randy, really, the vast majority of behavior is undocumented and not controllable. However I agree making this controllable is perfectly reasonable. The folks that did this were I believe Critical Mass, between "4.1" and "5.1", though granted the history is not completely known, just that 4.1 and earlier doesn't behave this way. I strongly advocate a type-based solution here. However, I believe there are several bits per handle however, not one. Not at the Win32 level, but in terms of the control you would want in the Modula-3. There is: Is the console visible? Either because it started that way, or because "someone" has written to it already. Should any/no write make it visible? Should "this particular" write make it visible? That is, you probably want the ability to avoid the console becoming visible. You probably want the ability to control this globally or per-write. Maybe even per-thread and not just per-process. And, say, if there is a severe error, you want to enable it becoming visible. And, say, if someone else wrote an error and made it visible and now you just have a warning, you might want to "piggy back" on the visibility and go ahead and print. You may even want to rehide the console, if that is possible. (Could expose this in the interface and it make it a nop..) Controlling this per-thread or per-process or per-write is actually pretty problematic. Because even if it is per-thread or per-process, I believe it should at the same time be per-handle. I should be able to block revelation on stdout for current thread, and then restore it when I am done. While leaving stderr unaltered, on the theory that stderr output is more important. Similarly per-process. But then each handle has per-thread locals. Ok, duh, per-process doesn't make sense, that's the same as per-handle. Controlling it per-handle is not problematic. Each handle would just have a fixed set of extra bits. I believe controlling it module-wide either per-process or per-thread *might* be interesting, but less so. Globals are bad. Even if hidden behind thread-safe functions. Just because Modula-3 nicely contains process-globals in modules, doesn't make them acceptable. I think modules are overrated actually, and "objects" -- instances of types are much more important. Modula-3 does "work", just that I should in general create Foo.T data and pass them as the first parameter to Foo.DoSomething. Programming is much more "type based" than "module based" imho. I know there is some disagreement here, but I'm not sure there is much. Really, there is a general issue of globals vs. parameters to functions, throughout a callstack. One implementation strategy would be to able to create a "wrapper" object. You would set the "policy" on that object -- perhaps via which type you created in the first place. You would pass that around to all your code. That would achieve per-thread, or per-whatever-you want, BUT it'd require you pass it around to all of your code. It is a tough discpline to really pass around all parameters, and not rely on some larger "global" or per-thread context. Thread locals and globals quite stink, and "plumbing the full depths of a call tree" can also be quite difficult". The problem, you know, of "oops, I forgot to add a parameter in lots of places. What do I do now? I know, I'll make a thread local, set it at the top of the call tree, check it in the middle or at the bottom, but not pass it all around..." It's a difficult problem. Much of the code in a particular call tree might not know or care about what the top and bottom care about, but somehow should be able to ferry along "context". Thread locals are so tempting and oh so problematic... - Jay Date: Wed, 18 Jun 2008 12:50:29 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Hi Rodney: Thanks for your reply. The issue is that for cm3 on Windows you can specify -gui as a command line option. This option causes the program to be built as a Windows GUI-mode application, rather than as a console application. For a GUI-mode application, the Stdio file handles are NIL because it has no console. Seemingly, to prevent a lot of errors when trying to read/write Stdio, some folks introduced the idea of a lazy console post cm3 v4.1. What happens now "under the covers" is that on a GUI-mode program the Stdio file handles are allocated as Lazy Consoles. Then, whenever Stdio.stdout/stderr/stdin is used, the underlying code realizes the first use and magically allocates a new console window on the fly. This console window pops up on the screen on top of your GUI-mode window. My objection is that this behavior is not documented in any interface and the programmer has no way to control the behavior. I want to make such control possible. Hope this explanation helps a bit. Regards, Randy>>> "rodney.bates" 6/18/2008 10:36 AM >>>I don't understand well enough what it means for a consoleto be lazily-allocated, but I wonder if it makes any sense toallow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T everbe lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside proceduresthat do it in a thread-safe way?>4. Modify Stdio implementation to properly initialize the new>variables during module initialization.>This change will be transparent to all clients.>>Now, with these changes, it will be possible for a client to know>whether stdout, stderr, and/or stdin represent lazily allocated>consoles or not, then act accordingly.>>For example, if I want to make sure messages written to stdout are>recorded even for a GUI-app, but I don't want a popup, I could do the>following:> IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL)> THEN> Stdio.stdout := FileWr.Open("myLogFile.txt");> Stdio.stdOut_IsLazy := FALSE;> END;>Now the above code fragment does show the possibility of a race>condition in multi-threaded code.>Rodney BatesRetired assistant professorComputer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Jun 19 05:18:59 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 18 Jun 2008 23:18:59 -0400 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> Message-ID: <485997DD.1E75.00D7.1@scires.com> Jay: I'd be satisfied just to deal with this on a per program instance, rather than at a thread level. Indeed, I'm not sure it makes sense on a per thread level. The Stdio module and global vars are shared by all code in the program process. I'm wondering if it might be better at this point to use environment variables to control the behavior. The current implementation initializes everything during module initialization at program startup. Thus, this occurs before dependent modules get a chance to run and influence the behavior. Perhaps the lazy console allocation should be the default unless a certain environment variable is set, say CM3_LazyConsole=FALSE. In this case the initialization code would turn off the lazy allocation and in the case of a GUI-mode program on Windows the Stdio.stdin/stdout/stderr would be NIL. If CM3_LazyConsole=TRUE or is not defined, you would get a lazy allocated console on Windows GUI-mode programs and a regular console otherwise. This approach has the advantage that no interfaces have to change. Of course, if folks want to add finer grains of control as you suggest, that would be ok. I just want to be able to prevent the popup of the lazy allocated console. I'm willing to make the modifications to the code unless someone objects to my approach. Regards, Randy >>> Jay 6/18/2008 1:20 PM >>> Randy, really, the vast majority of behavior is undocumented and not controllable. However I agree making this controllable is perfectly reasonable. The folks that did this were I believe Critical Mass, between "4.1" and "5.1", though granted the history is not completely known, just that 4.1 and earlier doesn't behave this way. I strongly advocate a type-based solution here. However, I believe there are several bits per handle however, not one. Not at the Win32 level, but in terms of the control you would want in the Modula-3. There is: Is the console visible? Either because it started that way, or because "someone" has written to it already. Should any/no write make it visible? Should "this particular" write make it visible? That is, you probably want the ability to avoid the console becoming visible. You probably want the ability to control this globally or per-write. Maybe even per-thread and not just per-process. And, say, if there is a severe error, you want to enable it becoming visible. And, say, if someone else wrote an error and made it visible and now you just have a warning, you might want to "piggy back" on the visibility and go ahead and print. You may even want to rehide the console, if that is possible. (Could expose this in the interface and it make it a nop..) Controlling this per-thread or per-process or per-write is actually pretty problematic. Because even if it is per-thread or per-process, I believe it should at the same time be per-handle. I should be able to block revelation on stdout for current thread, and then restore it when I am done. While leaving stderr unaltered, on the theory that stderr output is more important. Similarly per-process. But then each handle has per-thread locals. Ok, duh, per-process doesn't make sense, that's the same as per-handle. Controlling it per-handle is not problematic. Each handle would just have a fixed set of extra bits. I believe controlling it module-wide either per-process or per-thread *might* be interesting, but less so. Globals are bad. Even if hidden behind thread-safe functions. Just because Modula-3 nicely contains process-globals in modules, doesn't make them acceptable. I think modules are overrated actually, and "objects" -- instances of types are much more important. Modula-3 does "work", just that I should in general create Foo.T data and pass them as the first parameter to Foo.DoSomething. Programming is much more "type based" than "module based" imho. I know there is some disagreement here, but I'm not sure there is much. Really, there is a general issue of globals vs. parameters to functions, throughout a callstack. One implementation strategy would be to able to create a "wrapper" object. You would set the "policy" on that object -- perhaps via which type you created in the first place. You would pass that around to all your code. That would achieve per-thread, or per-whatever-you want, BUT it'd require you pass it around to all of your code. It is a tough discpline to really pass around all parameters, and not rely on some larger "global" or per-thread context. Thread locals and globals quite stink, and "plumbing the full depths of a call tree" can also be quite difficult". The problem, you know, of "oops, I forgot to add a parameter in lots of places. What do I do now? I know, I'll make a thread local, set it at the top of the call tree, check it in the middle or at the bottom, but not pass it all around..." It's a difficult problem. Much of the code in a particular call tree might not know or care about what the top and bottom care about, but somehow should be able to ferry along "context". Thread locals are so tempting and oh so problematic... - Jay Date: Wed, 18 Jun 2008 12:50:29 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Hi Rodney: Thanks for your reply. The issue is that for cm3 on Windows you can specify -gui as a command line option. This option causes the program to be built as a Windows GUI-mode application, rather than as a console application. For a GUI-mode application, the Stdio file handles are NIL because it has no console. Seemingly, to prevent a lot of errors when trying to read/write Stdio, some folks introduced the idea of a lazy console post cm3 v4.1. What happens now "under the covers" is that on a GUI-mode program the Stdio file handles are allocated as Lazy Consoles. Then, whenever Stdio.stdout/stderr/stdin is used, the underlying code realizes the first use and magically allocates a new console window on the fly. This console window pops up on the screen on top of your GUI-mode window. My objection is that this behavior is not documented in any interface and the programmer has no way to control the behavior. I want to make such control possible. Hope this explanation helps a bit. Regards, Randy >>> "rodney.bates" 6/18/2008 10:36 AM >>> I don't understand well enough what it means for a console to be lazily-allocated, but I wonder if it makes any sense to allow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T ever be lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside procedures that do it in a thread-safe way? >4. Modify Stdio implementation to properly initialize the new >variables during module initialization. >This change will be transparent to all clients. > >Now, with these changes, it will be possible for a client to know >whether stdout, stderr, and/or stdin represent lazily allocated >consoles or not, then act accordingly. > >For example, if I want to make sure messages written to stdout are >recorded even for a GUI-app, but I don't want a popup, I could do the >following: > IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) > THEN > Stdio.stdout := FileWr.Open("myLogFile.txt"); > Stdio.stdOut_IsLazy := FALSE; > END; >Now the above code fragment does show the possibility of a race >condition in multi-threaded code. > Rodney Bates Retired assistant professor Computer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 19 05:47:28 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 19 Jun 2008 03:47:28 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <485997DD.1E75.00D7.1@scires.com> References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> <485997DD.1E75.00D7.1@scires.com> Message-ID: Randy, just because the initialization happens early does not mean you can't affect the behavior later. The type can be changed at initialization time, and then the instance configured later. Unless you are worried about other module initializers ignorantly calling stdout.Wr() and causing the console to appear? If so, yeah. How about @M3 command line parameters instead? At least they aren't "sticky" and can be more easily localized to a single process. I ignore sh's feature here usually, and in this case that makes good sense. "Command line parameters are better than environment variables". Supporting both is reasonable. However, if so, and if it is an @M3 variable, there should perhaps be one variable to contain @M3 options?? Still I'm not a fan of globals like this. I think it should be configurable per type instantiation. You could also imagine that one variable is the "during initialization time" configuration, and then once Main starts, another configuration takes over, since by then whoever wants to set it has had a chance to run. Btw, sleazy, but you could also make it a built-time configuration. You could easily build your m3core.dll to have one default behavior, while everyone else's has another. - Jay Date: Wed, 18 Jun 2008 23:18:59 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Jay: I'd be satisfied just to deal with this on a per program instance, rather than at a thread level. Indeed, I'm not sure it makes sense on a per thread level. The Stdio module and global vars are shared by all code in the program process. I'm wondering if it might be better at this point to use environment variables to control the behavior. The current implementation initializes everything during module initialization at program startup. Thus, this occurs before dependent modules get a chance to run and influence the behavior. Perhaps the lazy console allocation should be the default unless a certain environment variable is set, say CM3_LazyConsole=FALSE. In this case the initialization code would turn off the lazy allocation and in the case of a GUI-mode program on Windows the Stdio.stdin/stdout/stderr would be NIL. If CM3_LazyConsole=TRUE or is not defined, you would get a lazy allocated console on Windows GUI-mode programs and a regular console otherwise. This approach has the advantage that no interfaces have to change. Of course, if folks want to add finer grains of control as you suggest, that would be ok. I just want to be able to prevent the popup of the lazy allocated console. I'm willing to make the modifications to the code unless someone objects to my approach. Regards, Randy>>> Jay 6/18/2008 1:20 PM >>>Randy, really, the vast majority of behavior is undocumented and not controllable.However I agree making this controllable is perfectly reasonable.The folks that did this were I believe Critical Mass, between "4.1" and "5.1", though granted the history is not completely known, just that 4.1 and earlier doesn't behave this way. I strongly advocate a type-based solution here. However, I believe there are several bits per handle however, not one.Not at the Win32 level, but in terms of the control you would want in the Modula-3. There is: Is the console visible? Either because it started that way, or because "someone" has written to it already. Should any/no write make it visible? Should "this particular" write make it visible? That is, you probably want the ability to avoid the console becoming visible.You probably want the ability to control this globally or per-write.Maybe even per-thread and not just per-process.And, say, if there is a severe error, you want to enable it becoming visible.And, say, if someone else wrote an error and made it visible and now you just have a warning, you might want to "piggy back" on the visibility and go ahead and print. You may even want to rehide the console, if that is possible.(Could expose this in the interface and it make it a nop..) Controlling this per-thread or per-process or per-write is actually pretty problematic. Because even if it is per-thread or per-process, I believe it should at the same time be per-handle. I should be able to block revelation on stdout for current thread, and then restore it when I am done. While leaving stderr unaltered, on the theory that stderr output is more important. Similarly per-process. But then each handle has per-thread locals. Ok, duh, per-process doesn't make sense, that's the same as per-handle. Controlling it per-handle is not problematic. Each handle would just have a fixed set of extra bits. I believe controlling it module-wide either per-process or per-thread *might* be interesting, but less so. Globals are bad. Even if hidden behind thread-safe functions. Just because Modula-3 nicely contains process-globals in modules, doesn't make them acceptable. I think modules are overrated actually, and "objects" -- instances of types are much more important. Modula-3 does "work", just that I should in general create Foo.T data and pass them as the first parameter to Foo.DoSomething. Programming is much more "type based" than "module based" imho. I know there is some disagreement here, but I'm not sure there is much. Really, there is a general issue of globals vs. parameters to functions, throughout a callstack. One implementation strategy would be to able to create a "wrapper" object.You would set the "policy" on that object -- perhaps via which type you created in the first place. You would pass that around to all your code. That would achieve per-thread, or per-whatever-you want, BUT it'd require you pass it around to all of your code. It is a tough discpline to really pass around all parameters, and not rely on some larger "global" or per-thread context. Thread locals and globals quite stink, and "plumbing the full depths of a call tree" can also be quite difficult". The problem, you know, of "oops, I forgot to add a parameter in lots of places. What do I do now? I know, I'll make a thread local, set it at the top of the call tree, check it in the middle or at the bottom, but not pass it all around..." It's a difficult problem. Much of the code in a particular call tree might not know or care about what the top and bottom care about, but somehow should be able to ferry along "context". Thread locals are so tempting and oh so problematic... - Jay Date: Wed, 18 Jun 2008 12:50:29 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Hi Rodney: Thanks for your reply. The issue is that for cm3 on Windows you can specify -gui as a command line option. This option causes the program to be built as a Windows GUI-mode application, rather than as a console application. For a GUI-mode application, the Stdio file handles are NIL because it has no console. Seemingly, to prevent a lot of errors when trying to read/write Stdio, some folks introduced the idea of a lazy console post cm3 v4.1. What happens now "under the covers" is that on a GUI-mode program the Stdio file handles are allocated as Lazy Consoles. Then, whenever Stdio.stdout/stderr/stdin is used, the underlying code realizes the first use and magically allocates a new console window on the fly. This console window pops up on the screen on top of your GUI-mode window. My objection is that this behavior is not documented in any interface and the programmer has no way to control the behavior. I want to make such control possible. Hope this explanation helps a bit. Regards, Randy>>> "rodney.bates" 6/18/2008 10:36 AM >>>I don't understand well enough what it means for a consoleto be lazily-allocated, but I wonder if it makes any sense toallow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T everbe lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside proceduresthat do it in a thread-safe way?>4. Modify Stdio implementation to properly initialize the new>variables during module initialization.>This change will be transparent to all clients.>>Now, with these changes, it will be possible for a client to know>whether stdout, stderr, and/or stdin represent lazily allocated>consoles or not, then act accordingly.>>For example, if I want to make sure messages written to stdout are>recorded even for a GUI-app, but I don't want a popup, I could do the>following:> IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL)> THEN> Stdio.stdout := FileWr.Open("myLogFile.txt");> Stdio.stdOut_IsLazy := FALSE;> END;>Now the above code fragment does show the possibility of a race>condition in multi-threaded code.>Rodney BatesRetired assistant professorComputer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jun 19 08:55:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 19 Jun 2008 08:55:10 +0200 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> <485997DD.1E75.00D7.1@scires.com> Message-ID: <20080619085510.eagbposkcg0g4g4o@mail.elegosoft.com> Quoting Jay : > Randy, just because the initialization happens early does not mean > you can't affect the behavior later. The type can be changed at > initialization time, and then the instance configured later. Unless > you are worried about other module initializers ignorantly calling > stdout.Wr() and causing the console to appear? If so, yeah. > > How about @M3 command line parameters instead? > At least they aren't "sticky" and can be more easily localized to a > single process. What does sticky mean here? > I ignore sh's feature here usually, and in this case that makes good sense. environment variables aren't a feature of shells, but or process contexts. Shells just allow to set them explicitly. > "Command line parameters are better than environment variables". > Supporting both is reasonable. Yes, if we go this way, we should support both options. An environment variable overrides a built-in default, and an explicit parameter overrides the environment setting if present. > However, if so, and if it is an @M3 variable, there should perhaps > be one variable to contain @M3 options?? Something like `@m3opt=lazyconsole,dontcrash,whatsoever'? What other options do you have in mind? > Still I'm not a fan of globals like this. I think it should be > configurable per type instantiation. > You could also imagine that one variable is the "during > initialization time" configuration, and then once Main starts, > another configuration takes over, since by then whoever wants to set > it has had a chance to run. > > Btw, sleazy, but you could also make it a built-time configuration. > You could easily build your m3core.dll to have one default behavior, > while everyone else's has another. I think we'll have to decide which way to go, as Randy needs a solution to continue his work. Currently the easiest approach seems to be the environment variable/command line solution indeed, as no interface need to be touched and no new modules are required. Would anybody object to this approach? More control could easily be added later, if that is really required. (After all, this currently is just a problem for Windows GUI programs.) What about M3_LAZY_CONSOLE and @M3lazyconsole for a start? 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 jayk123 at hotmail.com Thu Jun 19 10:04:12 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 19 Jun 2008 08:04:12 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <20080619085510.eagbposkcg0g4g4o@mail.elegosoft.com> References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> <485997DD.1E75.00D7.1@scires.com> <20080619085510.eagbposkcg0g4g4o@mail.elegosoft.com> Message-ID: set CM3_ConsoleBehavior=4.1 m3guiapp console behavior still changed m3guiapp @M3ConsoleBehavior=4.1 console behavior back to "default" - Jay> Date: Thu, 19 Jun 2008 08:55:10 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] proposal for dealing with lazy console--please review and comment!> > Quoting Jay :> > > Randy, just because the initialization happens early does not mean > > you can't affect the behavior later. The type can be changed at > > initialization time, and then the instance configured later. Unless > > you are worried about other module initializers ignorantly calling > > stdout.Wr() and causing the console to appear? If so, yeah.> >> > How about @M3 command line parameters instead?> > At least they aren't "sticky" and can be more easily localized to a > > single process.> What does sticky mean here?> > > I ignore sh's feature here usually, and in this case that makes good sense -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Sat Jun 21 16:18:35 2008 From: rodney.bates at wichita.edu (rodney.bates) Date: Sat, 21 Jun 2008 09:18:35 -0500 Subject: [M3devel] =?iso-8859-1?q?proposal_for_dealing_with_lazy_=09consol?= =?iso-8859-1?q?e--please=09review_and_comment!?= Message-ID: <481B6AEF@webmail.wichita.edu> I guess I am on a somewhat different wavelength on this. I do agree that a complete set of queries by the application should be supported, concerning lazy allocated streams. But to me, applications need to have either very little or nothing in the way of ability to change behaviour. For one thing, it makes sense for the lazy property to apply only to stdout/stderr, on win32 platforms, compiled as -gui. This is why I was questioning getting a stream from FileWr.Open, and then setting it lazy. Laziness doesn't make any sense on a disk file. Beyond that, I think at the most, an application should be able to change the laziness property only before any data has been written to the stream. After that, the window is already popped, and the semantics would get ugly. In fact, I am very skeptical about the need for an application to change laziness at all. If it can query this property, then it can just refrain from writing to the steam, if it doesn't want the window to pop up. Hence my objection to making the properties variables, not because of general principal, but because an application could assign to them at any time. >===== Original Message From Jay ===== >set CM3_ConsoleBehavior=4.1 >m3guiapp >console behavior still changed > >m3guiapp @M3ConsoleBehavior=4.1 >console behavior back to "default" > - Jay> Rodney Bates Retired assistant professor Computer Science From rcoleburn at scires.com Sat Jun 21 17:41:09 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 21 Jun 2008 11:41:09 -0400 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <481B6AEF@webmail.wichita.edu> References: <481B6AEF@webmail.wichita.edu> Message-ID: <485CE8D0.1E75.00D7.1@scires.com> Thanks Rodney and Jay for your comments. Here are a few points I'd like to add to this discussion. 1. I agree with Jay that command line arguments would be better than environment variables. 2. I agree with Rodney that the "laziness property" must be set before data gets read/written and that it should be set only once, not changed during execution. 3. A drawback to using command-line variables (and env vars) is that it shifts the responsibility from the programmer to the user. IMO, this type of behavior is something that is "designed" and documented as part of the program, so it should not be changeable by the user. For example, if the user fails to put the appropriate parameter on the command-line, the program's behavior changes. In effect, this is sort of what has happened to me, that is, the behavior of my cm3 v4.1 gui-mode program(s) has changed from its design because the underlying implementation changed to use lazy console allocation and I have no way of getting the old behavior back without changing the implementation. 4. Perhaps a better approach would be to devise a new option for the compiler. For example, "-gui" works as now and uses lazy console allocation. "-gui_no_lazy" works the way -gui did in 4.1 where the Stdio.stdin/stderr/stdout would be NIL for a gui-mode program. The problem here is I'm not sure exactly how to implement it. In effect, use of this option would mean we would need to swap (i.e., choose) the implementation of Process.m3 at compile time, OR we would need some way to ensure the Stdio variables get set to NIL after the current Process.m3 initialization (thereby undoing the lazy allocation). Maybe one of these methods can be done via quake somehow, but I'm not sure how to go about it. Any ideas? 5. If I'm the only person having this issue with the lazy allocation, perhaps I can adapt my programs. Perhaps I can just set the Stdio variables to be NIL at the beginning of my mainline code for programs I know should be compiled as -gui. This brings to mind an idea for how to implement -gui_no_lazy. Do you think we could write some quake code that causes a new module implementation to be included in the program whenever the target is NT386 AND the -gui_no_lazy option is set? This new implementation would import from Stdio and all it would do is set the Stdio vars to be NIL. Since it imports from Stdio and Stdio imports Process, I would tend to think that Process and Stdio module initializations would be run before this new module initialization thereby ensuring the lazy allocated consoles get set to NIL. What do you think? Regards, Randy >>> "rodney.bates" 6/21/2008 10:18 AM >>> I guess I am on a somewhat different wavelength on this. I do agree that a complete set of queries by the application should be supported, concerning lazy allocated streams. But to me, applications need to have either very little or nothing in the way of ability to change behaviour. For one thing, it makes sense for the lazy property to apply only to stdout/stderr, on win32 platforms, compiled as -gui. This is why I was questioning getting a stream from FileWr.Open, and then setting it lazy. Laziness doesn't make any sense on a disk file. Beyond that, I think at the most, an application should be able to change the laziness property only before any data has been written to the stream. After that, the window is already popped, and the semantics would get ugly. In fact, I am very skeptical about the need for an application to change laziness at all. If it can query this property, then it can just refrain from writing to the steam, if it doesn't want the window to pop up. Hence my objection to making the properties variables, not because of general principal, but because an application could assign to them at any time. >===== Original Message From Jay ===== >set CM3_ConsoleBehavior=4.1 >m3guiapp >console behavior still changed > >m3guiapp @M3ConsoleBehavior=4.1 >console behavior back to "default" > - Jay> Rodney Bates Retired assistant professor Computer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jun 21 18:04:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 21 Jun 2008 16:04:27 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <485CE8D0.1E75.00D7.1@scires.com> References: <481B6AEF@webmail.wichita.edu> <485CE8D0.1E75.00D7.1@scires.com> Message-ID: 4 (compiler switch) and 5 (adapt your code) are easy enough, though 4 I have *possible* misgivings about. There is in fact an interface whose data flows like so: run the compiler it produces "startup" code (_m3main.o/_m3main.obj/_m3main.c) that startup code passes data to the runtime (RTLinker) I mucked around here to fix environment variables. The "problem" here is that compiler <=> runtime interfaces must be carefully dealt with..perhaps. I am not sure what our compatibility requires are. I don't think Modula-3 binaries are really deployed so far and wide, and old and new .dlls/.so mixed much. So probably this interface can be churned without much concern for what it was in the past. Perhaps. Whatever data flows around here should probably be a record that starts with a size and contains a "set of int" (ie: bitflags) for every field, or every field added after a certain point, and reserve enough room for there to be enough bit flags for a long time. This is a part of a path to "release to release binary compatibility". Or maybe the type fingerprints are it and there isn't really such "adaptivity" around types changing? In C and C++, it is common to runtime link where the types on either side are different, but where there is some little amount of ability to discover some aspects of the types and adapt. As stated, via a size at the start of a record and/or bitfields to indicate which fields are present. Of course, it is limited. You only ever "grow" types. You never delete or rearrange. At the very least, you need to be able to bootstrap from one version to the next. A new compiler has to work at least once against an old statically linked runtime. At the very most, new compilers have to output binaries that work with old dynamically linked runtimes. I doubt this works much really but I am curious as to everyone else's opionions and assertions. Rather than set them to nil, what about typecasing them and then replacing with a non-nil instance that ignores writes? That will save you unhandled exceptions, right? Eventually I could/would probably just sit down and solve this but I haven't had much time and have been working on other Modula-3 things -- bringing up existing/new platforms (I uploaded SOLsun archives recently, still trying to bring up gcc on Solaris (not even SOLgnu, just gcc), and lots more on the radar..), debugging the 64 bit hosted cm3cg bug(s), etc. The quake code you propose sounds trivial, yes. But lately I think more should be in cm3 and less in quake (or sh or Python). Very gradually I am folding my Python into quake and my quake into cm3. Esp. as it proves stable and useful. For example, cm3 now reveals its own platform to Quake (HOST_PLATFORM), so Quake can default to a native build, without the user telling it or it sniffing around. All the use of uname et. al. can probably go away. (see also gcc's various -print-foo switches, that let wrappers introspect about gcc already knows about the target; cm3 could perhaps use similar) My Python wrappers accept a target platform name anywhere on the command line. cm3 should probably just do that. My Quake sniffs around for a config file based on platform, next to itself or in the source tree. Cm3 should probably just do that, esp. next to itself, less clear about in the source tree. It is kind of reasonable to go around implementing things multiple times, as the initial implementations serve as prototypes to try on for size, see if they work out well. The whole mechanism where "packages" are discovered by groveling the source tree could/should probably be merged into cm3, perhaps driven by a hand authored file or files, either like Randy did for Win32, or a more hierarchical tree full of small files linking together directories, like the Windows DDK "dirs" files. - Jay Date: Sat, 21 Jun 2008 11:41:09 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Thanks Rodney and Jay for your comments. Here are a few points I'd like to add to this discussion. 1. I agree with Jay that command line arguments would be better than environment variables. 2. I agree with Rodney that the "laziness property" must be set before data gets read/written and that it should be set only once, not changed during execution. 3. A drawback to using command-line variables (and env vars) is that it shifts the responsibility from the programmer to the user. IMO, this type of behavior is something that is "designed" and documented as part of the program, so it should not be changeable by the user. For example, if the user fails to put the appropriate parameter on the command-line, the program's behavior changes. In effect, this is sort of what has happened to me, that is, the behavior of my cm3 v4.1 gui-mode program(s) has changed from its design because the underlying implementation changed to use lazy console allocation and I have no way of getting the old behavior back without changing the implementation. 4. Perhaps a better approach would be to devise a new option for the compiler. For example, "-gui" works as now and uses lazy console allocation. "-gui_no_lazy" works the way -gui did in 4.1 where the Stdio.stdin/stderr/stdout would be NIL for a gui-mode program. The problem here is I'm not sure exactly how to implement it. In effect, use of this option would mean we would need to swap (i.e., choose) the implementation of Process.m3 at compile time, OR we would need some way to ensure the Stdio variables get set to NIL after the current Process.m3 initialization (thereby undoing the lazy allocation). Maybe one of these methods can be done via quake somehow, but I'm not sure how to go about it. Any ideas? 5. If I'm the only person having this issue with the lazy allocation, perhaps I can adapt my programs. Perhaps I can just set the Stdio variables to be NIL at the beginning of my mainline code for programs I know should be compiled as -gui. This brings to mind an idea for how to implement -gui_no_lazy. Do you think we could write some quake code that causes a new module implementation to be included in the program whenever the target is NT386 AND the -gui_no_lazy option is set? This new implementation would import from Stdio and all it would do is set the Stdio vars to be NIL. Since it imports from Stdio and Stdio imports Process, I would tend to think that Process and Stdio module initializations would be run before this new module initialization thereby ensuring the lazy allocated consoles get set to NIL. What do you think? Regards, Randy>>> "rodney.bates" 6/21/2008 10:18 AM >>>I guess I am on a somewhat different wavelength on this. I doagree that a complete set of queries by the application shouldbe supported, concerning lazy allocated streams. But to me,applications need to have either very little or nothing in theway of ability to change behaviour.For one thing, it makes sense for the lazy property to applyonly to stdout/stderr, on win32 platforms, compiled as -gui.This is why I was questioning getting a stream from FileWr.Open,and then setting it lazy. Laziness doesn't make any sense ona disk file.Beyond that, I think at the most, an application should be able to change the laziness property only before any data has beenwritten to the stream. After that, the window is already popped,and the semantics would get ugly.In fact, I am very skeptical about the need for an application to change laziness at all. If it can query this property, thenit can just refrain from writing to the steam, if it doesn't wantthe window to pop up.Hence my objection to making the properties variables, not becauseof general principal, but because an application could assign tothem at any time.>===== Original Message From Jay =====>set CM3_ConsoleBehavior=4.1>m3guiapp>console behavior still changed>>m3guiapp @M3ConsoleBehavior=4.1>console behavior back to "default"> - Jay>Rodney BatesRetired assistant professorComputer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jun 21 18:17:22 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 21 Jun 2008 16:17:22 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: References: <481B6AEF@webmail.wichita.edu> <485CE8D0.1E75.00D7.1@scires.com> Message-ID: > 3. A drawback to using command-line > variables (and env vars) is that it shifts > the responsibility from the programmer to > the user. IMO, this type of behavior is something > that is "designed" and documented as part of the > program, so it should not be changeable by the user. For example, if the What is constant behavior and what is settable by the user is obviously one of the big sets of questions any programmer must face. No one behavior suits everyone, and too many configurable options are confusing and harder to test. If you make everything configurable, you just ship the consumer nothing and let him "configure" it to do what he wants. Consumer can have any color Ford Model T as long as it is black... Anyway, I think the compiler command line option is reasonable, and implementing via "customizing" main to pass down the switch to runtime, while I expressed possible misgivings about it, I think is reasonable. Adapting quake to output different modules and all that I think is overkill. The main <=> RTLinker interface should probably be a little self describing anyway. And this might be main talking right to ProcessWin32 anyway. One thing I don't understand is how much Modula-3 code can be run before RTLinker. How much runtime linking does Modula-3 do itself, vs. how much code comes in from disk already ready to run. It could, heck, be C code or data if that helped. But just as well, it could flow through RTLinker en route to ProcessWin32, if that is necessary and the C and data exports are to be avoided. RTLinker does seem to do a lot more work than is "normal", in the C build model. That is, it *appears* you can't make cross Modula-3 module calls, even within the same .so/.exe/.dll. Kind of lame if true, given that many intra-module calls are already going unnecessarily through runtime linking a the C level (that problem I hit on AMD64_LINUX where the static link gets trashed by this unnecessary indirection; as well as where I believe I have deliberately removed this unnecessary indirection in my SOLsun configuration files). (This is that simpler focused email I owe...) - Jay From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comDate: Sat, 21 Jun 2008 16:04:27 +0000Subject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! 4 (compiler switch) and 5 (adapt your code) are easy enough, though 4 I have *possible* misgivings about. There is in fact an interface whose data flows like so: run the compiler it produces "startup" code (_m3main.o/_m3main.obj/_m3main.c) that startup code passes data to the runtime (RTLinker) I mucked around here to fix environment variables. The "problem" here is that compiler <=> runtime interfaces must be carefully dealt with..perhaps.I am not sure what our compatibility requires are. I don't think Modula-3 binaries are really deployed so far and wide, and old and new .dlls/.so mixed much. So probably this interface can be churned without much concern for what it was in the past. Perhaps. Whatever data flows around here should probably be a record that starts with a size and contains a "set of int" (ie: bitflags) for every field, or every field added after a certain point, and reserve enough room for there to be enough bit flags for a long time. This is a part of a path to "release to release binary compatibility". Or maybe the type fingerprints are it and there isn't really such "adaptivity" around types changing? In C and C++, it is common to runtime link where the types on either side are different, but where there is some little amount of ability to discover some aspects of the types and adapt. As stated, via a size at the start of a record and/or bitfields to indicate which fields are present. Of course, it is limited. You only ever "grow" types. You never delete or rearrange. At the very least, you need to be able to bootstrap from one version to the next.A new compiler has to work at least once against an old statically linked runtime. At the very most, new compilers have to output binaries that work with old dynamically linked runtimes. I doubt this works much really but I am curious as to everyone else's opionions and assertions. Rather than set them to nil, what about typecasing them and then replacing with a non-nil instance that ignores writes? That will save you unhandled exceptions, right? Eventually I could/would probably just sit down and solve this but I haven't had much time and have been working on other Modula-3 things -- bringing up existing/new platforms (I uploaded SOLsun archives recently, still trying to bring up gcc on Solaris (not even SOLgnu, just gcc), and lots more on the radar..), debugging the 64 bit hosted cm3cg bug(s), etc. The quake code you propose sounds trivial, yes.But lately I think more should be in cm3 and less in quake (or sh or Python).Very gradually I am folding my Python into quake and my quake into cm3. Esp. as it proves stable and useful.For example, cm3 now reveals its own platform to Quake (HOST_PLATFORM), so Quake can default to a native build, without the user telling it or it sniffing around. All the use of uname et. al. can probably go away. (see also gcc's various -print-foo switches, that let wrappers introspect about gcc already knows about the target; cm3 could perhaps use similar) My Python wrappers accept a target platform name anywhere on the command line. cm3 should probably just do that. My Quake sniffs around for a config file based on platform, next to itself or in the source tree. Cm3 should probably just do that, esp. next to itself, less clear about in the source tree. It is kind of reasonable to go around implementing things multiple times, as the initial implementations serve as prototypes to try on for size, see if they work out well. The whole mechanism where "packages" are discovered by groveling the source tree could/should probably be merged into cm3, perhaps driven by a hand authored file or files, either like Randy did for Win32, or a more hierarchical tree full of small files linking together directories, like the Windows DDK "dirs" files. - Jay Date: Sat, 21 Jun 2008 11:41:09 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Thanks Rodney and Jay for your comments. Here are a few points I'd like to add to this discussion. 1. I agree with Jay that command line arguments would be better than environment variables. 2. I agree with Rodney that the "laziness property" must be set before data gets read/written and that it should be set only once, not changed during execution. 3. A drawback to using command-line variables (and env vars) is that it shifts the responsibility from the programmer to the user. IMO, this type of behavior is something that is "designed" and documented as part of the program, so it should not be changeable by the user. For example, if the user fails to put the appropriate parameter on the command-line, the program's behavior changes. In effect, this is sort of what has happened to me, that is, the behavior of my cm3 v4.1 gui-mode program(s) has changed from its design because the underlying implementation changed to use lazy console allocation and I have no way of getting the old behavior back without changing the implementation. 4. Perhaps a better approach would be to devise a new option for the compiler. For example, "-gui" works as now and uses lazy console allocation. "-gui_no_lazy" works the way -gui did in 4.1 where the Stdio.stdin/stderr/stdout would be NIL for a gui-mode program. The problem here is I'm not sure exactly how to implement it. In effect, use of this option would mean we would need to swap (i.e., choose) the implementation of Process.m3 at compile time, OR we would need some way to ensure the Stdio variables get set to NIL after the current Process.m3 initialization (thereby undoing the lazy allocation). Maybe one of these methods can be done via quake somehow, but I'm not sure how to go about it. Any ideas? 5. If I'm the only person having this issue with the lazy allocation, perhaps I can adapt my programs. Perhaps I can just set the Stdio variables to be NIL at the beginning of my mainline code for programs I know should be compiled as -gui. This brings to mind an idea for how to implement -gui_no_lazy. Do you think we could write some quake code that causes a new module implementation to be included in the program whenever the target is NT386 AND the -gui_no_lazy option is set? This new implementation would import from Stdio and all it would do is set the Stdio vars to be NIL. Since it imports from Stdio and Stdio imports Process, I would tend to think that Process and Stdio module initializations would be run before this new module initialization thereby ensuring the lazy allocated consoles get set to NIL. What do you think? Regards, Randy>>> "rodney.bates" 6/21/2008 10:18 AM >>>I guess I am on a somewhat different wavelength on this. I doagree that a complete set of queries by the application shouldbe supported, concerning lazy allocated streams. But to me,applications need to have either very little or nothing in theway of ability to change behaviour.For one thing, it makes sense for the lazy property to applyonly to stdout/stderr, on win32 platforms, compiled as -gui.This is why I was questioning getting a stream from FileWr.Open,and then setting it lazy. Laziness doesn't make any sense ona disk file.Beyond that, I think at the most, an application should be able to change the laziness property only before any data has beenwritten to the stream. After that, the window is already popped,and the semantics would get ugly.In fact, I am very skeptical about the need for an application to change laziness at all. If it can query this property, thenit can just refrain from writing to the steam, if it doesn't wantthe window to pop up.Hence my objection to making the properties variables, not becauseof general principal, but because an application could assign tothem at any time.>===== Original Message From Jay =====>set CM3_ConsoleBehavior=4.1>m3guiapp>console behavior still changed>>m3guiapp @M3ConsoleBehavior=4.1>console behavior back to "default"> - Jay>Rodney BatesRetired assistant professorComputer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Jun 23 20:10:15 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 23 Jun 2008 14:10:15 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080621041535.A19F910D425E@birch.elegosoft.com> Message-ID: <485FAEC0.1E75.00D7.1@scires.com> Hi Henning: Not sure about any "good style rules" here. I am not aware of breaking any rules. PDF is a fairly universal format. These PDF documents provide the user's guide for the CM3-IDE package. The PDF files were created by printing a Microsoft Word document to the free pdf995 driver from Software995.com. I have provided the original Microsoft Word .DOC file in the repository as well, so if anyone wants to convert to a different format, you have the original source. Regards, Randy >>> Henning Thielemann 6/22/2008 4:34 PM >>> On Sat, 21 Jun 2008, Randy Coleburn wrote: > CVSROOT:/usr/cvs > Changes by:rcoleburn at birch.08/06/21 06:15:35 > > Added files: > cm3/doc/help/CM3_IDE/: basics.pdf beyond-basics.pdf > customization.pdf environment.pdf > index.html interface-index.pdf intro.pdf > more-info.pdf packages.pdf recipes.pdf > user-guide.pdf I thought it is not good style to put machine generated files, and especially binary files, to CVS repositories. Are the PDF files made from TeX? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Jun 23 21:01:58 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 23 Jun 2008 21:01:58 +0200 (CEST) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <485FAEC0.1E75.00D7.1@scires.com> References: <20080621041535.A19F910D425E@birch.elegosoft.com> <485FAEC0.1E75.00D7.1@scires.com> Message-ID: On Mon, 23 Jun 2008, Randy Coleburn wrote: > The PDF files were created by printing a Microsoft Word document to the > free pdf995 driver from Software995.com. > > I have provided the original Microsoft Word .DOC file in the repository I see. Then there is certainly no better way. From dragisha at m3w.org Fri Jun 27 15:59:15 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Jun 2008 15:59:15 +0200 Subject: [M3devel] LongSqrt.Sqrt... Message-ID: <1214575155.32091.3.camel@faramir.m3w.org> does not work for LINUXLIBC6... Or I am just missing some voodoo precondition? :) TIA -- Dragi?a Duri? From jayk123 at hotmail.com Sun Jun 1 03:40:42 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 1 Jun 2008 01:40:42 +0000 Subject: [M3devel] function pointers and comparison to nil? mis-typed function pointers? In-Reply-To: <20080531132924.GA30413@topoi.pooq.com> References: <483862F4.1E75.00D7.1@scires.com> <483A3377.7070801@wichita.edu> <48408AEE.8090405@wichita.edu> <20080531132924.GA30413@topoi.pooq.com> Message-ID: > In Modula-3, you can pass any procedure but only assign a top-level procedure. > This precludes dangling environments in yet another way, that is more liberal > than either Pascal or Modula-2,, but requires a runtime check on procedure I don't understand "can only assign a top-level procedure". My understanding is that Modula-3 does allow the "unsafe" option -- take the address of a nested function, pass it off to some code, that stores it in a global, and call it later. But of course, "Modula-3 does allow the unsafe option" does not compute. I need to read up and experiment. Maybe there is a runtime check whenever I assign a function pointer to either a global or to a field in non-local record, that it isn't a closure? That makes a fair amount of sense though hard to not make the check overly strict I think. Rodney my "problem" with your analysis is it mostly "pretends" that each language is its own independent environment. In present reality at least, Modula-3 and C interoperate a lot. That is largely a good thing. It does place restrictions on Modula-3 implementations however. Pointers to top-level Modula-3 functions can be passed to C and treated as pointers to C functions. Pointers to C functions, including gcc nested functions, can be passed to Modula-3 code as pointers. There are not separate types for pointers to C vs. Modula-3 functions. Pointers to nested Modula-3 functions cannot be passed to C code and treated as C function pointers, though enabling this, with the programmer required to notice the situation and change the code slightly, is easy enough. The compiler might also be able to recognize it and possibly error, at least if "extern" is presumed to be C, though of course..insert one level of Modula-3 code between "taking the address" and "passing it to C", and it becomes more difficult..but maybe still quite easy. If the whole world was Modula-3, then you could just change the representation of all function pointers and how they are called. The strategy of optionally heap allocated frames -- when the address is taken of a nested function -- does kill multiple birds with one expensive stone. - ability to pass function pointers to nested functions to C code, and store them anywhere - ability to call nested functions after their caller has returned - remove the check for the -1 marker which might possibly maybe just barely be unportable, and also slows down/bloats calls to function pointers (but at the cost of probably a more sever slow down) - avoid the use of generated code on the stack - still need to ensure the heap is executable but that's less of a problem, Windows for example at least exposes the ability to make the heap executable, besides the strategy of using VirtualAlloc. However it slows down existing code. Depending on which of these features is desirable, if in fact any at all, there are other options. - leave it all alone (but continue talking about it :) ) - put the code on the stack and call mprotect/VirtualProtect, as OpenBSD does for gcc nested functions - Jay > Date: Sat, 31 May 2008 09:29:24 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > On Fri, May 30, 2008 at 06:17:02PM -0500, Rodney M. Bates wrote:> > > > My one handy Algol68 book has the usual tutorial language book problem: it> > omits the cases you really need to look up. It only states that there will> > be problems if you use a dangling environment, but not whether the language> > specifies this should be detected by the language, or whether "all hell will> > break loose." I'm guessing it's the latter. The implementation technique> > Hendrik describes makes it a detected runtime error, but not unless/until> > you try to use the lost environment. This is more generous than Modula-3's > > rule.> > The actual Algol 68 definition does pronounce on this. The CDC > implementation was much more liberal than the language definition.> > Every reference/variable and every procedure has a scope. The scope of > a variable is the level on the run-time stack at which it is allocated. > Variables can be on the heap; this is global scope. The scope of a > procedure is the stack elvel at which its most local global identifier > is bound. Even if the identifier refers to an object on the heap, it is > the level at which it is bound that counts.> > There is a universal scope restriction: No object can refer to a more > local object. The constraint in the language definition is applied on > assignment.> > I know of no Algol 68 implementation that I can say for sure implements > this restriction with a run-time check. Of course it can be done, > either by tagging each pointer with an explicit mention of its stack > level (which takes space) or by comparing its value and comparing it to > various stack locations in a kind of search.> > The first release of the CDC algol 68 compiler just allocated all > variables on the heap, making the check unnecessary for safety. > Programmers almost never wrote code that passed procedures out-of-scope.> > Later releases performed static analysis to determine where it was safe > to allocate in the stack (almost all the time), and used the mechanism I > described earlier to check procedures when they were called if the > static check didn't suffice..> > > > And, of course, if your language is really dynamic, it could just say an> > environment is always accessible, requiring many or all activation records> > to be heap allocated.> > Which was a proposal made for the original Algol 68, but was turned > down. I think it should have been accepted. We would have had a > strongly-typed Scheme ahead of its time.> > -- hendrik> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Sun Jun 1 04:32:37 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 31 May 2008 21:32:37 -0500 Subject: [M3devel] function pointers and comparison to nil? mis-typed function pointers? In-Reply-To: References: <483862F4.1E75.00D7.1@scires.com> <483A3377.7070801@wichita.edu> <48408AEE.8090405@wichita.edu> <20080531132924.GA30413@topoi.pooq.com> Message-ID: <48420A45.6070401@wichita.edu> Jay wrote: > > I don't understand "can only assign a top-level procedure". > My understanding is that Modula-3 does allow the "unsafe" option -- take > the address of a nested function, pass it off to some code, that stores > it in a global, and call it later. But of course, "Modula-3 does allow > the unsafe option" does not compute. I need to read up and experiment. No, Modula-3 does not allow the above. The only thing you can do with a nested procedure is pass it as a parameter. The lifetime of the parameter will always lie within the lifetime of the current activation of the the nested procedure, so this is safe. If you try to assign a procedure to a variable/field/array-element, the language says the procedure value must be top-level. (See 2.3.1, assignability of an expression to a variable, second condition.) This is also safe. If the RHS of the assignment is a procedure constant, this can be checked statically. If the RHS is a formal parameter (thus variable at runtime), this must be a runtime check, because its value could be a nested procedure. The compiler implements the RT check by checking whether the pointer points to a closure or not, or rather, whether it points to a closure flag word. This implementation choice of representation of procedure values correctly implements the language, while still making global procedure values have the same representation as C pointers to (global) functions. > > Maybe there is a runtime check whenever I assign a function pointer to > either a global or to a field in non-local record, that it isn't a closure? > That makes a fair amount of sense though hard to not make the check > overly strict I think. Yes, this is not the loosest safe rule. Hardly anything is, in a safe language. The language designers have to make careful tradeoffs among programmer freedom, efficient implementability, and language simplicity. This is just the way Modula-3 makes the tradeoff to prevent dangling environment pointer bugs from happening. > >-- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jayk123 at hotmail.com Sun Jun 1 04:32:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 1 Jun 2008 02:32:27 +0000 Subject: [M3devel] proposal/insistence for fixed size integer types in Ctypes.i3 Message-ID: Currently the various Utypes.i3 introduce various types LIKE uint8_t = unsigned_char; uint16_t = unsigned_short; uint32_t = unsigned_int; uint64_t = unsigned_long_long; int8_t = signed_char; int16_t = short; int32_t = int; int64_t = long_long; sometimes there is an underscore after the u. There is quite some variation in which, if any, of these types are provided. When they are provided, they are always the same, with one exception I will detail. Arguably they are provided only for defining other types and function signatures within m3-libs/m3core/src/unix. I strongly strongly strongly propose that at least the above 8 types go in Ctypes, and the definitions in Utypes removed. If there was more commonality in Utypes, I'd "forward" them for compatibility, but there is little commonality. Code depending on these types would have to be forked a lot. As I said, the types are always the same, if they are defined, but they are often not defined. One variation I am open to is introducing a new .i3 file. But in general I like to colocate stuff rather than pick apart everything and decide an ideal location. There are tradeoffs either way, though most people only see the tradeoffs in the way I do it. The tradeoffs the other way are having to track down module after module, interface after interface, where to get stuff from, rather than having a "one stop shop", or "fewer shops to stop". I am also willing to have u_* types and CAPITALIZED types: uint8_t = unsigned_char; uint16_t = unsigned_short; uint32_t = unsigned_int; uint64_t = unsigned_long_long; int8_t = signed_char; int16_t = short; int32_t = int; int64_t = long_long; u_int8_t = uint8_t; u_int16_t = uint16_t; u_int32_t = uint32_t; u_int64_t = uint64_t; UINT8 = uint8_t; UINT16 = uint16_t; UINT32 = uint32_t; UINT64 = uint64_t; INT8 = int8_t; INT16 = int16_t; INT32 = int32_t; INT64 = int64_t; All built-in Modula-3 types are capitalized, as all Modula-3 keywords are. And capitalized types is a style widely used in the Windows headers. (Windows and Modula-3 share a common heritage -- Digital -- though I don't know from where the style of capitalized types originates.) The names "int8", "int16" are also obvious candidates, but I feel that some amount of typographical convention should be used to demark types. Some amount of "Hungarian", if you will. Obviously there are vehement opposing opinions on this. "Hungarian" is often too precise and precludes changing types without changing names, as well as producing unpronouncable names. A "weak" form however seems reasonable and useful. These types represent a certain point of view. It is a common point of view, but not universal. There are roughly three or four perspectives here: 1) char, short, int, long are abstractly defined and all code should live with it. char is at least 8 bits, and of unspecified signedness (limits.h defines CHAR_BIT, the number of bits in char for specified signedness, use signed char or unsigned char; I think char has actually three options for its signess -- signed, unsigned, or "half unsigned") short is at least 16 bits, signed int is at least 16 bits, signed long is at least 32 bits, signed There are not necessarily integral types that can hold pointers. size_t and ptrdiff_t perhaps, but unclear. size_t can hold the size of anything, but I think "anything" is "any variable" and not necessarily "the entire address space". ptrdiff_t can hold the result of subtracting pointers, but it is only valid to subtract pointers that point into the same array or just past it. It is common, for example, but not universal, for the "address space" to be divided between "user mode" and "kernel mode", often with a 50/50 split, so therefore size_t could be one bit smaller than a pointer, at least. Of course that's an "unnatural" size, but theoretically possible. (This kernel/user 50/50 split is usually exactly how 32 bit and I assume 64 bit Windows works, though 32 bit Windows can also have a 3 gig / 1 gig split, and 32 bit Windows code running on 64 bit Windows kernel can get a full 4 gig address space.) As well, the representation of signed integers is left unspecified. The range of "int" need only go down to -32767, not necessarily -32768. Signed magnitude and one's complement are valid representations. Overflowing a signed integer causes undefined behavior. Unsigned numbers do not have this abstraction. While this is the "most correct" view, according to (my understanding) the C standard, implementations do nail down details way beyond this, and a lot of code depends on these details. While I may have some of those details slightly wrong, you get the point. You CAN write code within this interface, but a lot of code violates it, sometimes by accident, sometimes for important practical reasons. Some amount of code assumes an int is at least or exactly 32 bits. Some amount of code assumes int or long can hold a pointer, though int probably not so much, and long probably of proportionally rapidly decreasing instance due to Win64. 2) char, short, int, long are somewhat abstractly defined char is exactly 8 bits varying perspectives on its presumed signedness short is exactly 16 bits int is exactly 32 bits long there are few perspectives on; it is exactly 32 bits ("Windows"), or it is exactly the size of a pointer ("Unix"), or it is at least the size of a pointer As well, two's complement is the only representation of signed numbers in use, and code depends on this. (I recently read that we can thank the IBM S/360 or such, in the 1960's, for introducing such modern-day architectural features that everyone takes for granted as an 8 bit byte and two's complement signed numbers.) If you need an integer with a particular exact size, either use char/short/int directly, or run them through "autoconf", or sniff "limits.h". 3) This is my recently acquired perspective, but it isn't new. Given that #1 is "correct but rare", and that #2 are full of "exact": char, short, int, long are funny names with not particularly useful specifications. #2 is a little sleazy (less so if autoconfed/limits.h) Unless you are really adhering to the strict spec, don't use them. If you are in fact indexing a "small" array, they might suffice, but is it worth it? worth having these types? Theory: 16 bit machines are irrelevant and 32 bit integers are perfectly efficient on 64 bit machines, and 64 bit integers are universally available (?) and reasonably efficient (?), so feel free to use them if there is a need. As well, 4gig remains a large capacity in most contexts, so feel free to use explictly 32 bit integers. However file sizes and offsets should really always be 64 bits. Any code still requiring 32 bit file offsets/sizes is unfortunate. That includes PE32+ imho, the file format for .exes/.dlls on Win64. Be clear and unsleazy and adopt new names that represent well their specification and actual use. int_t is exactly n bits in size and signed uint_t is exactly n bits in size and unsigned some names are chosen for unsigned and signed integers with the exact size of a pointer For n=8,16,32 all four types exist, and probably 64. And pointer-sized types exist. If you really feel your capacity limits should scale with address space size, or need to store a pointer in an integer, use size_t or uintptr_t or intptr_t, etc. Modula-3's position here adds that INTEGER is the exact size of a pointer and signed. It is identical to ptrdiff_t or intptr_t. CARDINAL is the exact size but omits the bottom "half" of the range, and does not, I believe, extend the top "half". Now, I also realize, that m3-libs/m3core/src/unix is a fairly mechanical translation of /usr/include, and /usr/include does not necessarily take perspective #3. So the "funny" names are useful for a human mechanical translation. But the precise names can still be used instead. Here is an exception I said I would detail: irix-5.2/utypes.i3: int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END; uint64_t = int64_t; This is different in at least two ways that I see. - default initialization to zero - 32 bit alignment instead of 64 bit alignment I tend to assume that the alignment is actually wrong, however all the uses in Usignal appear unaffected, as they are always preceded by a mix of int64_t and an even number of int32. Either way, it is easy enough to preserve this for compatibility. I would like to continue, where easy and clear, to reduce the "size" of m3-libs/m3core/src/unix. Making these types portable available helps that. For example -- Uin.m3 need not be duplicated at all. But then it either must use the presently more portable unsigned_short and unsigned, or uint16_t and uint32_t should be made always available, either by adding them to all the various Utypes.i3, or the one Ctypes.i3, or a new place. Darwin currently has four Upthread.i3 files (one is dead), but needs either only two, or one with the sizes abstracted out. I don't know if PPC64_DARWIN will needs its own yet, I don't have one of these machines yet. I would like to go ahead with this stuff *today*. It takes some exertion of patience for me to stop and send this first. :) - Jay From jayk123 at hotmail.com Sun Jun 1 04:35:40 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 1 Jun 2008 02:35:40 +0000 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 Message-ID: So much for trying plain text to avoid truncation, darnit.> From: jayk123 at hotmail.com> To: m3devel at elegosoft.com> Subject: proposal/insistence for fixed size integer types in Ctypes.i3> Date: Sun, 1 Jun 2008 02:32:27 +0000> > > > Currently the various Utypes.i3 introduce various types LIKE> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > sometimes there is an underscore after the u.> > > There is quite some variation in which, if any, of these types are provided.> When they are provided, they are always the same, with one exception I will detail.> > > Arguably they are provided only for defining other types and function signatures> within m3-libs/m3core/src/unix.> > > I strongly strongly strongly propose that at least the above 8 types go in> Ctypes, and the definitions in Utypes removed.> > > If there was more commonality in Utypes, I'd "forward" them for compatibility,> but there is little commonality. Code depending on these types would have to> be forked a lot. As I said, the types are always the same, if they are defined,> but they are often not defined.> > > One variation I am open to is introducing a new .i3 file.> But in general I like to colocate stuff rather than pick apart everything> and decide an ideal location. There are tradeoffs either way,> though most people only see the tradeoffs in the way I do it.> The tradeoffs the other way are having to track down module after module,> interface after interface, where to get stuff from, rather than having> a "one stop shop", or "fewer shops to stop".> > > I am also willing to have u_* types and CAPITALIZED types:> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > u_int8_t = uint8_t;> u_int16_t = uint16_t;> u_int32_t = uint32_t;> u_int64_t = uint64_t;> > > UINT8 = uint8_t;> UINT16 = uint16_t;> UINT32 = uint32_t;> UINT64 = uint64_t;> > > INT8 = int8_t;> INT16 = int16_t;> INT32 = int32_t;> INT64 = int64_t;> > > All built-in Modula-3 types are capitalized, as all Modula-3 keywords are.> And capitalized types is a style widely used in the Windows headers.> (Windows and Modula-3 share a common heritage -- Digital -- though I don't know> from where the style of capitalized types originates.)> > > The names "int8", "int16" are also obvious candidates, but I feel that some> amount of typographical convention should be used to demark types.> Some amount of "Hungarian", if you will.> Obviously there are vehement opposing opinions on this.> "Hungarian" is often too precise and precludes changing types without> changing names, as well as producing unpronouncable names.> A "weak" form however seems reasonable and useful.> > > These types represent a certain point of view.> It is a common point of view, but not universal.> > > There are roughly three or four perspectives here:> > > 1)> char, short, int, long are abstractly defined and all code should live with it.> char is at least 8 bits, and of unspecified signedness> (limits.h defines CHAR_BIT, the number of bits in char> for specified signedness, use signed char or unsigned char;> I think char has actually three options for its signess -- signed, unsigned, or "half unsigned")> short is at least 16 bits, signed> int is at least 16 bits, signed> long is at least 32 bits, signed> > > There are not necessarily integral types that can hold pointers.> size_t and ptrdiff_t perhaps, but unclear.> size_t can hold the size of anything, but I think "anything" is "any variable"> and not necessarily "the entire address space".> > > ptrdiff_t can hold the result of subtracting pointers, but it is only> valid to subtract pointers that point into the same array or just past it.> > > It is common, for example, but not universal, for the "address space"> to be divided between "user mode" and "kernel mode", often with a 50/50 split,> so therefore size_t could be one bit smaller than a pointer, at least.> Of course that's an "unnatural" size, but theoretically possible.> (This kernel/user 50/50 split is usually exactly how 32 bit and I assume> 64 bit Windows works, though 32 bit Windows can also have a 3 gig / 1 gig split,> and 32 bit Windows code running on 64 bit Windows kernel can get a> full 4 gig address space.)> > > As well, the representation of signed integers is left unspecified.> The range of "int" need only go down to -32767, not necessarily -32768.> Signed magnitude and one's complement are valid representations.> Overflowing a signed integer causes undefined behavior.> Unsigned numbers do not have this abstraction.> > > While this is the "most correct" view, according to (my understanding) the C standard,> implementations do nail down details way beyond this, and a lot of> code depends on these details.> > > While I may have some of those details slightly wrong, you get the point.> You CAN write code within this interface, but a lot of code violates it, sometimes> > > by accident, sometimes for important practical reasons.> Some amount of code assumes an int is at least or exactly 32 bits.> Some amount of code assumes int or long can hold a pointer, though> int probably not so much, and long probably of proportionally> rapidly decreasing instance due to Win64.> > > > 2)> char, short, int, long are somewhat abstractly defined> char is exactly 8 bits> varying perspectives on its presumed signedness> short is exactly 16 bits> int is exactly 32 bits> long there are few perspectives on; it is exactly 32 bits ("Windows"), or> it is exactly the size of a pointer ("Unix"), or it is at least> the size of a pointer> > > As well, two's complement is the only representation of signed numbers> in use, and code depends on this.> > > (I recently read that we can thank the IBM S/360 or such, in the 1960's,> for introducing such modern-day architectural features that everyone> takes for granted as an 8 bit byte and two's complement signed numbers.)> > > If you need an integer with a particular exact size, either use char/short/int directly,> or run them through "autoconf", or sniff "limits.h".> > > 3) This is my recently acquired perspective, but it isn't new.> > > Given that #1 is "correct but rare", and that #2 are> full of "exact":> > > char, short, int, long are funny names with not particularly> useful specifications. #2 is a little sleazy (less so if autoconfed/limits.h)> Unless you are really adhering to the strict spec, don't use them.> If you are in fact indexing a "small" array, they might suffice,> but is it worth it? worth having these types?> > > Theory: 16 bit machines are irrelevant and 32 bit integers> are perfectly efficient on 64 bit machines, and 64 bit integers> are universally available (?) and reasonably efficient (?),> so feel free to use them if there is a need.> > > As well, 4gig remains a large capacity in most contexts, so feel> free to use explictly 32 bit integers.> > > However file sizes and offsets should really always be 64 bits.> Any code still requiring 32 bit file offsets/sizes is unfortunate.> That includes PE32+ imho, the file format for .exes/.dlls on Win64.> > > Be clear and unsleazy and adopt new names that represent well> their specification and actual use.> > > int_t is exactly n bits in size and signed> uint_t is exactly n bits in size and unsigned> some names are chosen for unsigned and signed integers with> the exact size of a pointer> For n=8,16,32 all four types exist, and probably 64.> And pointer-sized types exist.> > > If you really feel your capacity limits should scale with address space size, or need> to store a pointer in an integer, use size_t or uintptr_t or intptr_t, etc.> > > Modula-3's position here adds that INTEGER is the exact> size of a pointer and signed. It is identical to ptrdiff_t> or intptr_t. CARDINAL is the exact size but omits the bottom "half"> of the range, and does not, I believe, extend the top "half".> > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly mechanical> translation of /usr/include, and /usr/include does not necessarily> take perspective #3. So the "funny" names are useful for a human> mechanical translation. But the precise names can still be used instead.> > > Here is an exception I said I would detail:> > > irix-5.2/utypes.i3:> int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END;> uint64_t = int64_t;> > > This is different in at least two ways that I see.> - default initialization to zero> - 32 bit alignment instead of 64 bit alignment> > > I tend to assume that the alignment is actually wrong,> however all the uses in Usignal appear unaffected, as they are always preceded> by a mix of int64_t and an even number of int32.> Either way, it is easy enough to preserve this for compatibility.> > > I would like to continue, where easy and clear, to reduce the "size" of m3-libs/m3core/src/unix.> Making these types portable available helps that.> For example -- Uin.m3 need not be duplicated at all.> But then it either must use the presently more portable unsigned_short and unsigned,> or uint16_t and uint32_t should be made always available, either by adding them> to all the various Utypes.i3, or the one Ctypes.i3, or a new place.> > > Darwin currently has four Upthread.i3 files (one is dead), but needs either only two, or one> with the sizes abstracted out. I don't know if PPC64_DARWIN will needs its own yet,> I don't have one of these machines yet.> > > I would like to go ahead with this stuff *today*.> It takes some exertion of patience for me to stop and send this first. :)> > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Jun 1 20:57:56 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 01 Jun 2008 11:57:56 -0700 Subject: [M3devel] function pointers and comparison to nil? mis-typed function pointers? In-Reply-To: Your message of "Sun, 01 Jun 2008 01:40:42 -0000." Message-ID: <200806011857.m51Ivu2X045935@camembert.async.caltech.edu> Jay writes: >--_c746a382-25b6-4547-9df2-927b317b6eab_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > In Modula-3, you can pass any procedure but only assign a top-level proc= >edure. > This precludes dangling environments in yet another way, that is m= >ore liberal > than either Pascal or Modula-2,, but requires a runtime check= > on procedure >I don't understand "can only assign a top-level procedure". >My understanding is that Modula-3 does allow the "unsafe" option -- take th= >e address of a nested function, pass it off to some code, that stores it in= > a global, and call it later. But of course, "Modula-3 does allow the unsaf= >e option" does not compute. I need to read up and experiment. >=20 >Maybe there is a runtime check whenever I assign a function pointer to eith= >er a global or to a field in non-local record, that it isn't a closure? >That makes a fair amount of sense though hard to not make the check overly = >strict I think. >=20 Jay, surely you remember that: "A procedure is either NIL or a triple consisting of: * the body, which is a statement, * the signature, ... * the environment, which is the scope with respect to which variable names in the body will be interpreted. A top-level procedure is a procedure declared in the outermost scope of a module. Any other procedure is a local procedure. A local procedure can be passed as a parameter but not assigned, since in a stack implementation a local procedure becomes invalid when the frame for the procedure containing it is popped. ... " The "since in a stack implementation..." clause seems superfluous to me, but I suppose it might be helpful for those who simply must think in terms of a specific implementation. From hosking at cs.purdue.edu Mon Jun 2 11:23:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jun 2008 10:23:44 +0100 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: References: Message-ID: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Are these types defined by the C standard. If not then they don't belong in Ctypes. If they are only defined by their particular platform then they do belong in Utypes. On Jun 1, 2008, at 3:35 AM, Jay wrote: > So much for trying plain text to avoid truncation, darnit. > > > > > From: jayk123 at hotmail.com > > To: m3devel at elegosoft.com > > Subject: proposal/insistence for fixed size integer types in > Ctypes.i3 > > Date: Sun, 1 Jun 2008 02:32:27 +0000 > > > > > > > > Currently the various Utypes.i3 introduce various types LIKE > > > > > > uint8_t = unsigned_char; > > uint16_t = unsigned_short; > > uint32_t = unsigned_int; > > uint64_t = unsigned_long_long; > > > > > > int8_t = signed_char; > > int16_t = short; > > int32_t = int; > > int64_t = long_long; > > > > > > sometimes there is an underscore after the u. > > > > > > There is quite some variation in which, if any, of these types are > provided. > > When they are provided, they are always the same, with one > exception I will detail. > > > > > > Arguably they are provided only for defining other types and > function signatures > > within m3-libs/m3core/src/unix. > > > > > > I strongly strongly strongly propose that at least the above 8 > types go in > > Ctypes, and the definitions in Utypes removed. > > > > > > If there was more commonality in Utypes, I'd "forward" them for > compatibility, > > but there is little commonality. Code depending on these types > would have to > > be forked a lot. As I said, the types are always the same, if they > are defined, > > but they are often not defined. > > > > > > One variation I am open to is introducing a new .i3 file. > > But in general I like to colocate stuff rather than pick apart > everything > > and decide an ideal location. There are tradeoffs either way, > > though most people only see the tradeoffs in the way I do it. > > The tradeoffs the other way are having to track down module after > module, > > interface after interface, where to get stuff from, rather than > having > > a "one stop shop", or "fewer shops to stop". > > > > > > I am also willing to have u_* types and CAPITALIZED types: > > > > > > uint8_t = unsigned_char; > > uint16_t = unsigned_short; > > uint32_t = unsigned_int; > > uint64_t = unsigned_long_long; > > > > > > int8_t = signed_char; > > int16_t = short; > > int32_t = int; > > int64_t = long_long; > > > > > > u_int8_t = uint8_t; > > u_int16_t = uint16_t; > > u_int32_t = uint32_t; > > u_int64_t = uint64_t; > > > > > > UINT8 = uint8_t; > > UINT16 = uint16_t; > > UINT32 = uint32_t; > > UINT64 = uint64_t; > > > > > > INT8 = int8_t; > > INT16 = int16_t; > > INT32 = int32_t; > > INT64 = int64_t; > > > > > > All built-in Modula-3 types are capitalized, as all Modula-3 > keywords are. > > And capitalized types is a style widely used in the Windows headers. > > (Windows and Modula-3 share a common heritage -- Digital -- though > I don't know > > from where the style of capitalized types originates.) > > > > > > The names "int8", "int16" are also obvious candidates, but I feel > that some > > amount of typographical convention should be used to demark types. > > Some amount of "Hungarian", if you will. > > Obviously there are vehement opposing opinions on this. > > "Hungarian" is often too precise and precludes changing types > without > > changing names, as well as producing unpronouncable names. > > A "weak" form however seems reasonable and useful. > > > > > > These types represent a certain point of view. > > It is a common point of view, but not universal. > > > > > > There are roughly three or four perspectives here: > > > > > > 1) > > char, short, int, long are abstractly defined and all code should > live with it. > > char is at least 8 bits, and of unspecified signedness > > (limits.h defines CHAR_BIT, the number of bits in char > > for specified signedness, use signed char or unsigned char; > > I think char has actually three options for its signess -- signed, > unsigned, or "half unsigned") > > short is at least 16 bits, signed > > int is at least 16 bits, signed > > long is at least 32 bits, signed > > > > > > There are not necessarily integral types that can hold pointers. > > size_t and ptrdiff_t perhaps, but unclear. > > size_t can hold the size of anything, but I think "anything" is > "any variable" > > and not necessarily "the entire address space". > > > > > > ptrdiff_t can hold the result of subtracting pointers, but it is > only > > valid to subtract pointers that point into the same array or just > past it. > > > > > > It is common, for example, but not universal, for the "address > space" > > to be divided between "user mode" and "kernel mode", often with a > 50/50 split, > > so therefore size_t could be one bit smaller than a pointer, at > least. > > Of course that's an "unnatural" size, but theoretically possible. > > (This kernel/user 50/50 split is usually exactly how 32 bit and I > assume > > 64 bit Windows works, though 32 bit Windows can also have a 3 > gig / 1 gig split, > > and 32 bit Windows code running on 64 bit Windows kernel can get a > > full 4 gig address space.) > > > > > > As well, the representation of signed integers is left unspecified. > > The range of "int" need only go down to -32767, not necessarily > -32768. > > Signed magnitude and one's complement are valid representations. > > Overflowing a signed integer causes undefined behavior. > > Unsigned numbers do not have this abstraction. > > > > > > While this is the "most correct" view, according to (my > understanding) the C standard, > > implementations do nail down details way beyond this, and a lot of > > code depends on these details. > > > > > > While I may have some of those details slightly wrong, you get the > point. > > You CAN write code within this interface, but a lot of code > violates it, sometimes > > > > > > by accident, sometimes for important practical reasons. > > Some amount of code assumes an int is at least or exactly 32 bits. > > Some amount of code assumes int or long can hold a pointer, though > > int probably not so much, and long probably of proportionally > > rapidly decreasing instance due to Win64. > > > > > > > > 2) > > char, short, int, long are somewhat abstractly defined > > char is exactly 8 bits > > varying perspectives on its presumed signedness > > short is exactly 16 bits > > int is exactly 32 bits > > long there are few perspectives on; it is exactly 32 bits > ("Windows"), or > > it is exactly the size of a pointer ("Unix"), or it is at least > > the size of a pointer > > > > > > As well, two's complement is the only representation of signed > numbers > > in use, and code depends on this. > > > > > > (I recently read that we can thank the IBM S/360 or such, in the > 1960's, > > for introducing such modern-day architectural features that everyone > > takes for granted as an 8 bit byte and two's complement signed > numbers.) > > > > > > If you need an integer with a particular exact size, either use > char/short/int directly, > > or run them through "autoconf", or sniff "limits.h". > > > > > > 3) This is my recently acquired perspective, but it isn't new. > > > > > > Given that #1 is "correct but rare", and that #2 are > > full of "exact": > > > > > > char, short, int, long are funny names with not particularly > > useful specifications. #2 is a little sleazy (less so if > autoconfed/limits.h) > > Unless you are really adhering to the strict spec, don't use them. > > If you are in fact indexing a "small" array, they might suffice, > > but is it worth it? worth having these types? > > > > > > Theory: 16 bit machines are irrelevant and 32 bit integers > > are perfectly efficient on 64 bit machines, and 64 bit integers > > are universally available (?) and reasonably efficient (?), > > so feel free to use them if there is a need. > > > > > > As well, 4gig remains a large capacity in most contexts, so feel > > free to use explictly 32 bit integers. > > > > > > However file sizes and offsets should really always be 64 bits. > > Any code still requiring 32 bit file offsets/sizes is unfortunate. > > That includes PE32+ imho, the file format for .exes/.dlls on Win64. > > > > > > Be clear and unsleazy and adopt new names that represent well > > their specification and actual use. > > > > > > int_t is exactly n bits in size and signed > > uint_t is exactly n bits in size and unsigned > > some names are chosen for unsigned and signed integers with > > the exact size of a pointer > > For n=8,16,32 all four types exist, and probably 64. > > And pointer-sized types exist. > > > > > > If you really feel your capacity limits should scale with address > space size, or need > > to store a pointer in an integer, use size_t or uintptr_t or > intptr_t, etc. > > > > > > Modula-3's position here adds that INTEGER is the exact > > size of a pointer and signed. It is identical to ptrdiff_t > > or intptr_t. CARDINAL is the exact size but omits the bottom "half" > > of the range, and does not, I believe, extend the top "half". > > > > > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly > mechanical > > translation of /usr/include, and /usr/include does not necessarily > > take perspective #3. So the "funny" names are useful for a human > > mechanical translation. But the precise names can still be used > instead. > > > > > > Here is an exception I said I would detail: > > > > > > irix-5.2/utypes.i3: > > int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END; > > uint64_t = int64_t; > > > > > > This is different in at least two ways that I see. > > - default initialization to zero > > - 32 bit alignment instead of 64 bit alignment > > > > > > I tend to assume that the alignment is actually wrong, > > however all the uses in Usignal appear unaffected, as they are > always preceded > > by a mix of int64_t and an even number of int32. > > Either way, it is easy enough to preserve this for compatibility. > > > > > > I would like to continue, where easy and clear, to reduce the > "size" of m3-libs/m3core/src/unix. > > Making these types portable available helps that. > > For example -- Uin.m3 need not be duplicated at all. > > But then it either must use the presently more portable > unsigned_short and unsigned, > > or uint16_t and uint32_t should be made always available, either > by adding them > > to all the various Utypes.i3, or the one Ctypes.i3, or a new place. > > > > > > Darwin currently has four Upthread.i3 files (one is dead), but > needs either only two, or one > > with the sizes abstracted out. I don't know if PPC64_DARWIN will > needs its own yet, > > I don't have one of these machines yet. > > > > > > I would like to go ahead with this stuff *today*. > > It takes some exertion of patience for me to stop and send this > first. :) > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jun 2 12:13:41 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 2 Jun 2008 10:13:41 +0000 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> References: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Message-ID: They are not from the C standard, nor are they necessarily from a particular platform. Some platforms define some of them. But all platforms could define all of them, at least 8/16/32, and could define them identically. I want to add these somewhere in m3core. They are portable enough. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3Date: Mon, 2 Jun 2008 10:23:44 +0100 Are these types defined by the C standard. If not then they don't belong in Ctypes. If they are only defined by their particular platform then they do belong in Utypes. On Jun 1, 2008, at 3:35 AM, Jay wrote: So much for trying plain text to avoid truncation, darnit.> From: jayk123 at hotmail.com> To: m3devel at elegosoft.com> Subject: proposal/insistence for fixed size integer types in Ctypes.i3> Date: Sun, 1 Jun 2008 02:32:27 +0000> > > > Currently the various Utypes.i3 introduce various types LIKE> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > sometimes there is an underscore after the u.> > > There is quite some variation in which, if any, of these types are provided.> When they are provided, they are always the same, with one exception I will detail.> > > Arguably they are provided only for defining other types and function signatures> within m3-libs/m3core/src/unix.> > > I strongly strongly strongly propose that at least the above 8 types go in> Ctypes, and the definitions in Utypes removed.> > > If there was more commonality in Utypes, I'd "forward" them for compatibility,> but there is little commonality. Code depending on these types would have to> be forked a lot. As I said, the types are always the same, if they are defined,> but they are often not defined.> > > One variation I am open to is introducing a new .i3 file.> But in general I like to colocate stuff rather than pick apart everything> and decide an ideal location. There are tradeoffs either way,> though most people only see the tradeoffs in the way I do it.> The tradeoffs the other way are having to track down module after module,> interface after interface, where to get stuff from, rather than having> a "one stop shop", or "fewer shops to stop".> > > I am also willing to have u_* types and CAPITALIZED types:> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > u_int8_t = uint8_t;> u_int16_t = uint16_t;> u_int32_t = uint32_t;> u_int64_t = uint64_t;> > > UINT8 = uint8_t;> UINT16 = uint16_t;> UINT32 = uint32_t;> UINT64 = uint64_t;> > > INT8 = int8_t;> INT16 = int16_t;> INT32 = int32_t;> INT64 = int64_t;> > > All built-in Modula-3 types are capitalized, as all Modula-3 keywords are.> And capitalized types is a style widely used in the Windows headers.> (Windows and Modula-3 share a common heritage -- Digital -- though I don't know> from where the style of capitalized types originates.)> > > The names "int8", "int16" are also obvious candidates, but I feel that some> amount of typographical convention should be used to demark types.> Some amount of "Hungarian", if you will.> Obviously there are vehement opposing opinions on this.> "Hungarian" is often too precise and precludes changing types without> changing names, as well as producing unpronouncable names.> A "weak" form however seems reasonable and useful.> > > These types represent a certain point of view.> It is a common point of view, but not universal.> > > There are roughly three or four perspectives here:> > > 1)> char, short, int, long are abstractly defined and all code should live with it.> char is at least 8 bits, and of unspecified signedness> (limits.h defines CHAR_BIT, the number of bits in char> for specified signedness, use signed char or unsigned char;> I think char has actually three options for its signess -- signed, unsigned, or "half unsigned")> short is at least 16 bits, signed> int is at least 16 bits, signed> long is at least 32 bits, signed> > > There are not necessarily integral types that can hold pointers.> size_t and ptrdiff_t perhaps, but unclear.> size_t can hold the size of anything, but I think "anything" is "any variable"> and not necessarily "the entire address space".> > > ptrdiff_t can hold the result of subtracting pointers, but it is only> valid to subtract pointers that point into the same array or just past it.> > > It is common, for example, but not universal, for the "address space"> to be divided between "user mode" and "kernel mode", often with a 50/50 split,> so therefore size_t could be one bit smaller than a pointer, at least.> Of course that's an "unnatural" size, but theoretically possible.> (This kernel/user 50/50 split is usually exactly how 32 bit and I assume> 64 bit Windows works, though 32 bit Windows can also have a 3 gig / 1 gig split,> and 32 bit Windows code running on 64 bit Windows kernel can get a> full 4 gig address space.)> > > As well, the representation of signed integers is left unspecified.> The range of "int" need only go down to -32767, not necessarily -32768.> Signed magnitude and one's complement are valid representations.> Overflowing a signed integer causes undefined behavior.> Unsigned numbers do not have this abstraction.> > > While this is the "most correct" view, according to (my understanding) the C standard,> implementations do nail down details way beyond this, and a lot of> code depends on these details.> > > While I may have some of those details slightly wrong, you get the point.> You CAN write code within this interface, but a lot of code violates it, sometimes> > > by accident, sometimes for important practical reasons.> Some amount of code assumes an int is at least or exactly 32 bits.> Some amount of code assumes int or long can hold a pointer, though> int probably not so much, and long probably of proportionally> rapidly decreasing instance due to Win64.> > > > 2)> char, short, int, long are somewhat abstractly defined> char is exactly 8 bits> varying perspectives on its presumed signedness> short is exactly 16 bits> int is exactly 32 bits> long there are few perspectives on; it is exactly 32 bits ("Windows"), or> it is exactly the size of a pointer ("Unix"), or it is at least> the size of a pointer> > > As well, two's complement is the only representation of signed numbers> in use, and code depends on this.> > > (I recently read that we can thank the IBM S/360 or such, in the 1960's,> for introducing such modern-day architectural features that everyone> takes for granted as an 8 bit byte and two's complement signed numbers.)> > > If you need an integer with a particular exact size, either use char/short/int directly,> or run them through "autoconf", or sniff "limits.h".> > > 3) This is my recently acquired perspective, but it isn't new.> > > Given that #1 is "correct but rare", and that #2 are> full of "exact":> > > char, short, int, long are funny names with not particularly> useful specifications. #2 is a little sleazy (less so if autoconfed/limits.h)> Unless you are really adhering to the strict spec, don't use them.> If you are in fact indexing a "small" array, they might suffice,> but is it worth it? worth having these types?> > > Theory: 16 bit machines are irrelevant and 32 bit integers> are perfectly efficient on 64 bit machines, and 64 bit integers> are universally available (?) and reasonably efficient (?),> so feel free to use them if there is a need.> > > As well, 4gig remains a large capacity in most contexts, so feel> free to use explictly 32 bit integers.> > > However file sizes and offsets should really always be 64 bits.> Any code still requiring 32 bit file offsets/sizes is unfortunate.> That includes PE32+ imho, the file format for .exes/.dlls on Win64.> > > Be clear and unsleazy and adopt new names that represent well> their specification and actual use.> > > int_t is exactly n bits in size and signed> uint_t is exactly n bits in size and unsigned> some names are chosen for unsigned and signed integers with> the exact size of a pointer> For n=8,16,32 all four types exist, and probably 64.> And pointer-sized types exist.> > > If you really feel your capacity limits should scale with address space size, or need> to store a pointer in an integer, use size_t or uintptr_t or intptr_t, etc.> > > Modula-3's position here adds that INTEGER is the exact> size of a pointer and signed. It is identical to ptrdiff_t> or intptr_t. CARDINAL is the exact size but omits the bottom "half"> of the range, and does not, I believe, extend the top "half".> > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly mechanical> translation of /usr/include, and /usr/include does not necessarily> take perspective #3. So the "funny" names are useful for a human> mechanical translation. But the precise names can still be used instead.> > > Here is an exception I said I would detail:> > > irix-5.2/utypes.i3:> int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END;> uint64_t = int64_t;> > > This is different in at least two ways that I see.> - default initialization to zero> - 32 bit alignment instead of 64 bit alignment> > > I tend to assume that the alignment is actually wrong,> however all the uses in Usignal appear unaffected, as they are always preceded> by a mix of int64_t and an even number of int32.> Either way, it is easy enough to preserve this for compatibility.> > > I would like to continue, where easy and clear, to reduce the "size" of m3-libs/m3core/src/unix.> Making these types portable available helps that.> For example -- Uin.m3 need not be duplicated at all.> But then it either must use the presently more portable unsigned_short and unsigned,> or uint16_t and uint32_t should be made always available, either by adding them> to all the various Utypes.i3, or the one Ctypes.i3, or a new place.> > > Darwin currently has four Upthread.i3 files (one is dead), but needs either only two, or one> with the sizes abstracted out. I don't know if PPC64_DARWIN will needs its own yet,> I don't have one of these machines yet.> > > I would like to go ahead with this stuff *today*.> It takes some exertion of patience for me to stop and send this first. :)> > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jun 2 12:34:32 2008 From: jay.krell at cornell.edu (Jay) Date: Mon, 2 Jun 2008 10:34:32 +0000 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> References: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Message-ID: > I want to add these somewhere in m3core. Ok, how about this? I think we can agree to this easily. INTERFACE Cstdint; IMPORT Ctypes; TYPE int8_t = Ctypes.signed_char;uint8_t = Ctypes.unsigned_char; int16_t = Ctypes.short;uint16_t = Ctypes.unsigned_short; int32_t = Ctypes.int;uint32_t = Ctypes.unsigned_int; int64_t = Ctypes.long_long;uint64_t = Ctypes.unsigned_long_long; (* from here on out I don't care much, can be removed to avoid being wrong *) intptr_t = INTEGER;uintptr_t = CARDINAL; (* ? *) (* and esp. from here on out if there is any difficulty coming up with the definitions *) CONST PTRDIFF_MIN = FIRST(intptr_t);SIZE_MAX = LAST(uintptr_t); (* Should WCHAR be wchar_t, or be 16 bits always?wchar_t is sometimes larger than 16 bits. *) WCHAR_MIN = FIRST(WIDECHAR);WCHAR_MAX = LAST(WIDECHAR); (* The rest omitted as decreasing usefulness and possibly decreasing portability. *) I would just as soon integrate all this into the language as globalsbut people like to push stuff out to libraries where possible/easy.(Some C++ libraries -- Boost -- have become very contorted because it was possible but not easy.) - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3Date: Mon, 2 Jun 2008 10:13:41 +0000 They are not from the C standard, nor are they necessarily from a particular platform.Some platforms define some of them.But all platforms could define all of them, at least 8/16/32, and could define them identically.I want to add these somewhere in m3core.They are portable enough. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3Date: Mon, 2 Jun 2008 10:23:44 +0100 Are these types defined by the C standard. If not then they don't belong in Ctypes. If they are only defined by their particular platform then they do belong in Utypes. On Jun 1, 2008, at 3:35 AM, Jay wrote: So much for trying plain text to avoid truncation, darnit.> From: jayk123 at hotmail.com> To: m3devel at elegosoft.com> Subject: proposal/insistence for fixed size integer types in Ctypes.i3> Date: Sun, 1 Jun 2008 02:32:27 +0000> > > > Currently the various Utypes.i3 introduce various types LIKE> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > sometimes there is an underscore after the u.> > > There is quite some variation in which, if any, of these types are provided.> When they are provided, they are always the same, with one exception I will detail.> > > Arguably they are provided only for defining other types and function signatures> within m3-libs/m3core/src/unix.> > > I strongly strongly strongly propose that at least the above 8 types go in> Ctypes, and the definitions in Utypes removed.> > > If there was more commonality in Utypes, I'd "forward" them for compatibility,> but there is little commonality. Code depending on these types would have to> be forked a lot. As I said, the types are always the same, if they are defined,> but they are often not defined.> > > One variation I am open to is introducing a new .i3 file.> But in general I like to colocate stuff rather than pick apart everything> and decide an ideal location. There are tradeoffs either way,> though most people only see the tradeoffs in the way I do it.> The tradeoffs the other way are having to track down module after module,> interface after interface, where to get stuff from, rather than having> a "one stop shop", or "fewer shops to stop".> > > I am also willing to have u_* types and CAPITALIZED types:> > > uint8_t = unsigned_char;> uint16_t = unsigned_short;> uint32_t = unsigned_int;> uint64_t = unsigned_long_long;> > > int8_t = signed_char;> int16_t = short;> int32_t = int;> int64_t = long_long;> > > u_int8_t = uint8_t;> u_int16_t = uint16_t;> u_int32_t = uint32_t;> u_int64_t = uint64_t;> > > UINT8 = uint8_t;> UINT16 = uint16_t;> UINT32 = uint32_t;> UINT64 = uint64_t;> > > INT8 = int8_t;> INT16 = int16_t;> INT32 = int32_t;> INT64 = int64_t;> > > All built-in Modula-3 types are capitalized, as all Modula-3 keywords are.> And capitalized types is a style widely used in the Windows headers.> (Windows and Modula-3 share a common heritage -- Digital -- though I don't know> from where the style of capitalized types originates.)> > > The names "int8", "int16" are also obvious candidates, but I feel that some> amount of typographical convention should be used to demark types.> Some amount of "Hungarian", if you will.> Obviously there are vehement opposing opinions on this.> "Hungarian" is often too precise and precludes changing types without> changing names, as well as producing unpronouncable names.> A "weak" form however seems reasonable and useful.> > > These types represent a certain point of view.> It is a common point of view, but not universal.> > > There are roughly three or four perspectives here:> > > 1)> char, short, int, long are abstractly defined and all code should live with it.> char is at least 8 bits, and of unspecified signedness> (limits.h defines CHAR_BIT, the number of bits in char> for specified signedness, use signed char or unsigned char;> I think char has actually three options for its signess -- signed, unsigned, or "half unsigned")> short is at least 16 bits, signed> int is at least 16 bits, signed> long is at least 32 bits, signed> > > There are not necessarily integral types that can hold pointers.> size_t and ptrdiff_t perhaps, but unclear.> size_t can hold the size of anything, but I think "anything" is "any variable"> and not necessarily "the entire address space".> > > ptrdiff_t can hold the result of subtracting pointers, but it is only> valid to subtract pointers that point into the same array or just past it.> > > It is common, for example, but not universal, for the "address space"> to be divided between "user mode" and "kernel mode", often with a 50/50 split,> so therefore size_t could be one bit smaller than a pointer, at least.> Of course that's an "unnatural" size, but theoretically possible.> (This kernel/user 50/50 split is usually exactly how 32 bit and I assume> 64 bit Windows works, though 32 bit Windows can also have a 3 gig / 1 gig split,> and 32 bit Windows code running on 64 bit Windows kernel can get a> full 4 gig address space.)> > > As well, the representation of signed integers is left unspecified.> The range of "int" need only go down to -32767, not necessarily -32768.> Signed magnitude and one's complement are valid representations.> Overflowing a signed integer causes undefined behavior.> Unsigned numbers do not have this abstraction.> > > While this is the "most correct" view, according to (my understanding) the C standard,> implementations do nail down details way beyond this, and a lot of> code depends on these details.> > > While I may have some of those details slightly wrong, you get the point.> You CAN write code within this interface, but a lot of code violates it, sometimes> > > by accident, sometimes for important practical reasons.> Some amount of code assumes an int is at least or exactly 32 bits.> Some amount of code assumes int or long can hold a pointer, though> int probably not so much, and long probably of proportionally> rapidly decreasing instance due to Win64.> > > > 2)> char, short, int, long are somewhat abstractly defined> char is exactly 8 bits> varying perspectives on its presumed signedness> short is exactly 16 bits> int is exactly 32 bits> long there are few perspectives on; it is exactly 32 bits ("Windows"), or> it is exactly the size of a pointer ("Unix"), or it is at least> the size of a pointer> > > As well, two's complement is the only representation of signed numbers> in use, and code depends on this.> > > (I recently read that we can thank the IBM S/360 or such, in the 1960's,> for introducing such modern-day architectural features that everyone> takes for granted as an 8 bit byte and two's complement signed numbers.)> > > If you need an integer with a particular exact size, either use char/short/int directly,> or run them through "autoconf", or sniff "limits.h".> > > 3) This is my recently acquired perspective, but it isn't new.> > > Given that #1 is "correct but rare", and that #2 are> full of "exact":> > > char, short, int, long are funny names with not particularly> useful specifications. #2 is a little sleazy (less so if autoconfed/limits.h)> Unless you are really adhering to the strict spec, don't use them.> If you are in fact indexing a "small" array, they might suffice,> but is it worth it? worth having these types?> > > Theory: 16 bit machines are irrelevant and 32 bit integers> are perfectly efficient on 64 bit machines, and 64 bit integers> are universally available (?) and reasonably efficient (?),> so feel free to use them if there is a need.> > > As well, 4gig remains a large capacity in most contexts, so feel> free to use explictly 32 bit integers.> > > However file sizes and offsets should really always be 64 bits.> Any code still requiring 32 bit file offsets/sizes is unfortunate.> That includes PE32+ imho, the file format for .exes/.dlls on Win64.> > > Be clear and unsleazy and adopt new names that represent well> their specification and actual use.> > > int_t is exactly n bits in size and signed> uint_t is exactly n bits in size and unsigned> some names are chosen for unsigned and signed integers with> the exact size of a pointer> For n=8,16,32 all four types exist, and probably 64.> And pointer-sized types exist.> > > If you really feel your capacity limits should scale with address space size, or need> to store a pointer in an integer, use size_t or uintptr_t or intptr_t, etc.> > > Modula-3's position here adds that INTEGER is the exact> size of a pointer and signed. It is identical to ptrdiff_t> or intptr_t. CARDINAL is the exact size but omits the bottom "half"> of the range, and does not, I believe, extend the top "half".> > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly mechanical> translation of /usr/include, and /usr/include does not necessarily> take perspective #3. So the "funny" names are useful for a human> mechanical translation. But the precise names can still be used instead.> > > Here is an exception I said I would detail:> > > irix-5.2/utypes.i3:> int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END;> uint64_t = int64_t;> > > This is different in at least two ways that I see.> - default initialization to zero> - 32 bit alignment instead of 64 bit alignment> > > I tend to assume that the alignment is actually wrong,> however all the uses in Usignal appear unaffected, as they are always preceded> by a mix of int64_t and an even number of int32.> Either way, it is easy enough to preserve this for compatibility.> > > I would like to continue, where easy and clear, to reduce the "size" of m3-libs/m3core/src/unix.> Making these types portable available helps that.> For example -- Uin.m3 need not be duplicated at all.> But then it either must use the presently more portable unsigned_short and unsigned,> or uint16_t and uint32_t should be made always available, either by adding them> to all the various Utypes.i3, or the one Ctypes.i3, or a new place.> > > Darwin currently has four Upthread.i3 files (one is dead), but needs either only two, or one> with the sizes abstracted out. I don't know if PPC64_DARWIN will needs its own yet,> I don't have one of these machines yet.> > > I would like to go ahead with this stuff *today*.> It takes some exertion of patience for me to stop and send this first. :)> > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jun 2 13:03:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 02 Jun 2008 13:03:23 +0200 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: References: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Message-ID: <20080602130323.17qngqata84ow8wc@mail.elegosoft.com> Quoting Jay : > > They are not from the C standard, nor are they necessarily from a > particular platform. > Some platforms define some of them. > But all platforms could define all of them, at least 8/16/32, and > could define them identically. > I want to add these somewhere in m3core. > They are portable enough. I wouldn't object to a new interface abstracting just some type definitions for all target platforms. If that's OK with Tony, too, you may go ahead. 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 2 13:12:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jun 2008 12:12:39 +0100 Subject: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3 In-Reply-To: References: <17735DC3-16DF-41D7-B42F-13C1E0623432@cs.purdue.edu> Message-ID: Cstdint.i3 seems perfectly reasonable as per: http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html On Jun 2, 2008, at 11:34 AM, Jay wrote: > > I want to add these somewhere in m3core. > > Ok, how about this? I think we can agree to this easily. > > INTERFACE Cstdint; > > IMPORT Ctypes; > > TYPE > > int8_t = Ctypes.signed_char; > uint8_t = Ctypes.unsigned_char; > > int16_t = Ctypes.short; > uint16_t = Ctypes.unsigned_short; > > int32_t = Ctypes.int; > uint32_t = Ctypes.unsigned_int; > > int64_t = Ctypes.long_long; > uint64_t = Ctypes.unsigned_long_long; > > (* from here on out I don't care much, can be removed to avoid being > wrong *) > > intptr_t = INTEGER; > uintptr_t = CARDINAL; (* ? *) > > (* and esp. from here on out if there is any difficulty coming up > with the definitions *) > > CONST > > PTRDIFF_MIN = FIRST(intptr_t); > SIZE_MAX = LAST(uintptr_t); > > (* Should WCHAR be wchar_t, or be 16 bits always? > wchar_t is sometimes larger than 16 bits. *) > > WCHAR_MIN = FIRST(WIDECHAR); > WCHAR_MAX = LAST(WIDECHAR); > > (* The rest omitted as decreasing usefulness and possibly decreasing > portability. *) > > I would just as soon integrate all this into the language as globals > but people like to push stuff out to libraries where possible/easy. > (Some C++ libraries -- Boost -- have become very contorted because > it was possible but not easy.) > > - Jay > > > > > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: proposal/insistence for fixed size > integer types in Ctypes.i3 > Date: Mon, 2 Jun 2008 10:13:41 +0000 > > They are not from the C standard, nor are they necessarily from a > particular platform. > Some platforms define some of them. > But all platforms could define all of them, at least 8/16/32, and > could define them identically. > I want to add these somewhere in m3core. > They are portable enough. > > - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] FW: proposal/insistence for fixed size > integer types in Ctypes.i3 > Date: Mon, 2 Jun 2008 10:23:44 +0100 > > Are these types defined by the C standard. If not then they don't > belong in Ctypes. If they are only defined by their particular > platform then they do belong in Utypes. > > On Jun 1, 2008, at 3:35 AM, Jay wrote: > > So much for trying plain text to avoid truncation, darnit. > > > > > From: jayk123 at hotmail.com > > To: m3devel at elegosoft.com > > Subject: proposal/insistence for fixed size integer types in > Ctypes.i3 > > Date: Sun, 1 Jun 2008 02:32:27 +0000 > > > > > > > > Currently the various Utypes.i3 introduce various types LIKE > > > > > > uint8_t = unsigned_char; > > uint16_t = unsigned_short; > > uint32_t = unsigned_int; > > uint64_t = unsigned_long_long; > > > > > > int8_t = signed_char; > > int16_t = short; > > int32_t = int; > > int64_t = long_long; > > > > > > sometimes there is an underscore after the u. > > > > > > There is quite some variation in which, if any, of these types are > provided. > > When they are provided, they are always the same, with one > exception I will detail. > > > > > > Arguably they are provided only for defining other types and > function signatures > > within m3-libs/m3core/src/unix. > > > > > > I strongly strongly strongly propose that at least the above 8 > types go in > > Ctypes, and the definitions in Utypes removed. > > > > > > If there was more commonality in Utypes, I'd "forward" them for > compatibility, > > but there is little commonality. Code depending on these types > would have to > > be forked a lot. As I said, the types are always the same, if they > are defined, > > but they are often not defined. > > > > > > One variation I am open to is introducing a new .i3 file. > > But in general I like to colocate stuff rather than pick apart > everything > > and decide an ideal location. There are tradeoffs either way, > > though most people only see the tradeoffs in the way I do it. > > The tradeoffs the other way are having to track down module after > module, > > interface after interface, where to get stuff from, rather than > having > > a "one stop shop", or "fewer shops to stop". > > > > > > I am also willing to have u_* types and CAPITALIZED types: > > > > > > uint8_t = unsigned_char; > > uint16_t = unsigned_short; > > uint32_t = unsigned_int; > > uint64_t = unsigned_long_long; > > > > > > int8_t = signed_char; > > int16_t = short; > > int32_t = int; > > int64_t = long_long; > > > > > > u_int8_t = uint8_t; > > u_int16_t = uint16_t; > > u_int32_t = uint32_t; > > u_int64_t = uint64_t; > > > > > > UINT8 = uint8_t; > > UINT16 = uint16_t; > > UINT32 = uint32_t; > > UINT64 = uint64_t; > > > > > > INT8 = int8_t; > > INT16 = int16_t; > > INT32 = int32_t; > > INT64 = int64_t; > > > > > > All built-in Modula-3 types are capitalized, as all Modula-3 > keywords are. > > And capitalized types is a style widely used in the Windows headers. > > (Windows and Modula-3 share a common heritage -- Digital -- though > I don't know > > from where the style of capitalized types originates.) > > > > > > The names "int8", "int16" are also obvious candidates, but I feel > that some > > amount of typographical convention should be used to demark types. > > Some amount of "Hungarian", if you will. > > Obviously there are vehement opposing opinions on this. > > "Hungarian" is often too precise and precludes changing types > without > > changing names, as well as producing unpronouncable names. > > A "weak" form however seems reasonable and useful. > > > > > > These types represent a certain point of view. > > It is a common point of view, but not universal. > > > > > > There are roughly three or four perspectives here: > > > > > > 1) > > char, short, int, long are abstractly defined and all code should > live with it. > > char is at least 8 bits, and of unspecified signedness > > (limits.h defines CHAR_BIT, the number of bits in char > > for specified signedness, use signed char or unsigned char; > > I think char has actually three options for its signess -- signed, > unsigned, or "half unsigned") > > short is at least 16 bits, signed > > int is at least 16 bits, signed > > long is at least 32 bits, signed > > > > > > There are not necessarily integral types that can hold pointers. > > size_t and ptrdiff_t perhaps, but unclear. > > size_t can hold the size of anything, but I think "anything" is > "any variable" > > and not necessarily "the entire address space". > > > > > > ptrdiff_t can hold the result of subtracting pointers, but it is > only > > valid to subtract pointers that point into the same array or just > past it. > > > > > > It is common, for example, but not universal, for the "address > space" > > to be divided between "user mode" and "kernel mode", often with a > 50/50 split, > > so therefore size_t could be one bit smaller than a pointer, at > least. > > Of course that's an "unnatural" size, but theoretically possible. > > (This kernel/user 50/50 split is usually exactly how 32 bit and I > assume > > 64 bit Windows works, though 32 bit Windows can also have a 3 > gig / 1 gig split, > > and 32 bit Windows code running on 64 bit Windows kernel can get a > > full 4 gig address space.) > > > > > > As well, the representation of signed integers is left unspecified. > > The range of "int" need only go down to -32767, not necessarily > -32768. > > Signed magnitude and one's complement are valid representations. > > Overflowing a signed integer causes undefined behavior. > > Unsigned numbers do not have this abstraction. > > > > > > While this is the "most correct" view, according to (my > understanding) the C standard, > > implementations do nail down details way beyond this, and a lot of > > code depends on these details. > > > > > > While I may have some of those details slightly wrong, you get the > point. > > You CAN write code within this interface, but a lot of code > violates it, sometimes > > > > > > by accident, sometimes for important practical reasons. > > Some amount of code assumes an int is at least or exactly 32 bits. > > Some amount of code assumes int or long can hold a pointer, though > > int probably not so much, and long probably of proportionally > > rapidly decreasing instance due to Win64. > > > > > > > > 2) > > char, short, int, long are somewhat abstractly defined > > char is exactly 8 bits > > varying perspectives on its presumed signedness > > short is exactly 16 bits > > int is exactly 32 bits > > long there are few perspectives on; it is exactly 32 bits > ("Windows"), or > > it is exactly the size of a pointer ("Unix"), or it is at least > > the size of a pointer > > > > > > As well, two's complement is the only representation of signed > numbers > > in use, and code depends on this. > > > > > > (I recently read that we can thank the IBM S/360 or such, in the > 1960's, > > for introducing such modern-day architectural features that everyone > > takes for granted as an 8 bit byte and two's complement signed > numbers.) > > > > > > If you need an integer with a particular exact size, either use > char/short/int directly, > > or run them through "autoconf", or sniff "limits.h". > > > > > > 3) This is my recently acquired perspective, but it isn't new. > > > > > > Given that #1 is "correct but rare", and that #2 are > > full of "exact": > > > > > > char, short, int, long are funny names with not particularly > > useful specifications. #2 is a little sleazy (less so if > autoconfed/limits.h) > > Unless you are really adhering to the strict spec, don't use them. > > If you are in fact indexing a "small" array, they might suffice, > > but is it worth it? worth having these types? > > > > > > Theory: 16 bit machines are irrelevant and 32 bit integers > > are perfectly efficient on 64 bit machines, and 64 bit integers > > are universally available (?) and reasonably efficient (?), > > so feel free to use them if there is a need. > > > > > > As well, 4gig remains a large capacity in most contexts, so feel > > free to use explictly 32 bit integers. > > > > > > However file sizes and offsets should really always be 64 bits. > > Any code still requiring 32 bit file offsets/sizes is unfortunate. > > That includes PE32+ imho, the file format for .exes/.dlls on Win64. > > > > > > Be clear and unsleazy and adopt new names that represent well > > their specification and actual use. > > > > > > int_t is exactly n bits in size and signed > > uint_t is exactly n bits in size and unsigned > > some names are chosen for unsigned and signed integers with > > the exact size of a pointer > > For n=8,16,32 all four types exist, and probably 64. > > And pointer-sized types exist. > > > > > > If you really feel your capacity limits should scale with address > space size, or need > > to store a pointer in an integer, use size_t or uintptr_t or > intptr_t, etc. > > > > > > Modula-3's position here adds that INTEGER is the exact > > size of a pointer and signed. It is identical to ptrdiff_t > > or intptr_t. CARDINAL is the exact size but omits the bottom "half" > > of the range, and does not, I believe, extend the top "half". > > > > > > Now, I also realize, that m3-libs/m3core/src/unix is a fairly > mechanical > > translation of /usr/include, and /usr/include does not necessarily > > take perspective #3. So the "funny" names are useful for a human > > mechanical translation. But the precise names can still be used > instead. > > > > > > Here is an exception I said I would detail: > > > > > > irix-5.2/utypes.i3: > > int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END; > > uint64_t = int64_t; > > > > > > This is different in at least two ways that I see. > > - default initialization to zero > > - 32 bit alignment instead of 64 bit alignment > > > > > > I tend to assume that the alignment is actually wrong, > > however all the uses in Usignal appear unaffected, as they are > always preceded > > by a mix of int64_t and an even number of int32. > > Either way, it is easy enough to preserve this for compatibility. > > > > > > I would like to continue, where easy and clear, to reduce the > "size" of m3-libs/m3core/src/unix. > > Making these types portable available helps that. > > For example -- Uin.m3 need not be duplicated at all. > > But then it either must use the presently more portable > unsigned_short and unsigned, > > or uint16_t and uint32_t should be made always available, either > by adding them > > to all the various Utypes.i3, or the one Ctypes.i3, or a new place. > > > > > > Darwin currently has four Upthread.i3 files (one is dead), but > needs either only two, or one > > with the sizes abstracted out. I don't know if PPC64_DARWIN will > needs its own yet, > > I don't have one of these machines yet. > > > > > > I would like to go ahead with this stuff *today*. > > It takes some exertion of patience for me to stop and send this > first. :) > > > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jun 2 23:07:22 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 2 Jun 2008 21:07:22 +0000 Subject: [M3devel] unsigned integers? Message-ID: What is the status and chance of a 32 bit integer with the range 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. 0xFFFFFFFFFFFFFFFF? Already available? Impossible to provide?Only available in unsafe modules?Only available with restricted operations in safe modules, and more operations in unsafe modules? Specifically, I think looping from 0 to N is safe -- no overflow. Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow. Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow. Adding or subtracting an INTEGER to "UNSIGNED" is not safe. Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe. Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done carefully. Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL or UNSIGNED.The unsafe operations above could be runtime checked perhaps. I guess that's a different larger point/dilemna -- when to allow potentially unsafe operations but with runtime checks vs. the compiler just disallowing them entirely. e.g. adding an integer to an integer is not even safe, but checked maybe at runtime (ok, at least assignment to subrange types is checked). Yes, I know I know, the runtime checks on at least many integer operations is yet lacking. Is there any, um, value in such a type? Is it just me blindly trying to cast Modula-3 as C (yes), but there's no actual value (uncertain)? Btw, I agree there's no point in this type in representing file sizes or offsets. They should be at least 63 bit integers. One bit doesn't buy much for file sizes. It might be something for address spaces though? It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = INTEGER. It seems quite wrong. Perhaps the unsigned types larger than 16 bits just should not be defined in Cstdint. ?? But there is already Ctypes.unsigned_int, unsigned_long_long, whose underlying type I think is signed, but which convention says you just don't do signed operations on, but which the compiler doesn't enforce, right? You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED/UINT?????? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Jun 3 02:15:23 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 02 Jun 2008 17:15:23 -0700 Subject: [M3devel] unsigned integers? In-Reply-To: Your message of "Mon, 02 Jun 2008 21:07:22 -0000." Message-ID: <200806030015.m530FNvv073806@camembert.async.caltech.edu> What is it you are looking for? 1 Operator overloading of + - * DIV for this new type? 2 Runtime checks of overflow? Or both? You can obviously get #2 by writing a tiny little library of your own? (Just like the Word interface but with overflow checks.) Does it matter whether the underlying implementation uses INTEGER or ARRAY OF BITS 8 FOR [0..255]? Doesn't a : Unsigned.T := 3; b : CARDINAL := 4; c := a - b; overflow? The Green Book is quite clear on the point that Word.T operations can never overflow, that is, all operations are "safe", using your terminology, so no, they aren't the same types. But it's rather confusing that you use a different definition of the word "safe" from that used in the Green Book. (In fact the Green Book only defines "unsafe" but I assume "safe" to mean "not unsafe", which it does, too.) Mika Jay writes: >--_a753fe8a-a24d-445a-8b9d-c524a5a0a41a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >What is the status and chance of a 32 bit integer with the range 0..0xFFFFF= >FFF and of a 64 bit integer type with range 0 .. 0xFFFFFFFFFFFFFFFF? >=20 >=20 >Already available? >Impossible to provide?Only available in unsafe modules?Only available with = >restricted operations in safe modules, and more operations in unsafe module= >s? >=20 >=20 >Specifically, I think looping from 0 to N is safe -- no overflow. >Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow. >Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow. >Adding or subtracting an INTEGER to "UNSIGNED" is not safe. >Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.Comparin= >g UNSIGNED to UNSIGNED for any of =3D, <, >, !=3D, is safe. >Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done careful= >ly. > Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL or U= >NSIGNED.The unsafe operations above could be runtime checked perhaps. > I guess that's a different larger point/dilemna -- when to allow potentia= >lly unsafe operations but with runtime checks vs. the compiler just disallo= >wing them entirely. e.g. adding an integer to an integer is not even safe, = >but checked maybe at runtime (ok, at least assignment to subrange types is = >checked). Yes, I know I know, the runtime checks on at least many integer o= >perations is yet lacking. >=20 >Is there any, um, value in such a type? >Is it just me blindly trying to cast Modula-3 as C (yes), but there's no ac= >tual value (uncertain)? >=20 >Btw, I agree there's no point in this type in representing file sizes or of= >fsets. They should be at least 63 bit integers. One bit doesn't buy much fo= >r file sizes. It might be something for address spaces though? >=20 >It bugs me to define types like uintptr_t =3D CARDINAL or uintptr_t =3D INT= >EGER. It seems quite wrong. >Perhaps the unsigned types larger than 16 bits just should not be defined i= >n Cstdint. ?? >But there is already Ctypes.unsigned_int, unsigned_long_long, whose underly= >ing type I think is signed, but which convention says you just don't do sig= >ned operations on, but which the compiler doesn't enforce, right? >=20 >You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED= >/UINT?????? >=20 > - Jay= > >--_a753fe8a-a24d-445a-8b9d-c524a5a0a41a_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >What is the status and chance of a 32 bit integer= > with the range 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. = >0xFFFFFFFFFFFFFFFF?
> 
> 
>Already available?
>Impossible to provide?
Only available in unsafe modules?
Only availab= >le with restricted operations in safe modules, and more operations in unsaf= >e modules?
> 
> 
>Specifically, I think looping from 0 to N is safe -- no overflow.
>Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow.
>Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow.
>Adding or subtracting an INTEGER to "UNSIGNED" is not safe.
>Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.
Comp= >aring UNSIGNED to UNSIGNED for any of =3D, <, >, !=3D, is safe.
>Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done careful= >ly.
>  Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any = >CARDINAL or UNSIGNED.
The unsafe operations above could be runtime check= >ed perhaps.
>  I guess that's a different larger point/dilemna -- when to allow pot= >entially unsafe operations but with runtime checks vs. the compiler just di= >sallowing them entirely. e.g. adding an integer to an integer is not even s= >afe, but checked maybe at runtime (ok, at least assignment to subrange type= >s is checked). Yes, I know I know, the runtime checks on at least many inte= >ger operations is yet lacking.
> 
>Is there any, um, value in such a type?
>Is it just me blindly trying to cast Modula-3 as C (yes), but there's no ac= >tual value (uncertain)?

> 
>Btw, I agree there's no point in this type in representing file sizes or of= >fsets. They should be at least 63 bit integers. One bit doesn't buy much fo= >r file sizes. It might be something for address spaces though?
> 
>It bugs me to define types like uintptr_t =3D CARDINAL or uintptr_t =3D INT= >EGER. It seems quite wrong.
>Perhaps the unsigned types larger than 16 bits just should not be defined i= >n Cstdint. ??
>But there is already Ctypes.unsigned_int, unsigned_long_long, whose underly= >ing type I think is signed, but which convention says you just don't do sig= >ned operations on, but which the compiler doesn't enforce, right?
> 
>You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED= >/UINT??????
> 
> - Jay
>= > >--_a753fe8a-a24d-445a-8b9d-c524a5a0a41a_-- From dabenavidesd at yahoo.es Tue Jun 3 02:25:43 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 3 Jun 2008 00:25:43 +0000 (GMT) Subject: [M3devel] unsigned integers? In-Reply-To: Message-ID: <618174.58920.qm@web27102.mail.ukl.yahoo.com> Dear Jay and developers: >What is the status and chance of a 32 bit integer with the range >0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. >0xFFFFFFFFFFFFFFFF? I guess you meant like a LONGCARD, I think it was a proposal of native 64 integer language update with recent LONGINT add,  but as I understood it was no accepted (maybe it was not  needed). Did you mean UNSIGNED like a  LONGCARD? There is a Sweden site about the comparison you want to make of C++ types and Modula-3 built-in types (as I understand you want to figure out), maybe this can give you an idea of others thoughts: http://translate.google.com.co/translate?u=http%3A%2F%2Fwww.nada.kth.se%2Fdatorer%2Fhaften%2Fmodula2c%2B%2B%2Fnode9.html&sl=sv&tl=en&hl=es&ie=UTF-8 Also you can check this opinion based on comparison with Modula-2 too: http://catless.ncl.ac.uk/Risks/18.60.html#subj7.1 Also the m3devel list from 2006. And all the others about 64 native proposal of Rodney Bates and others: http://mailarchive.elegosoft.com/Zope/m3/m3devel/archive/2006/2006-09/1157492987000/index_html?fullMode=1#1158164046000 I would vote to keep simplicity even in the mapping of C types to Modula-3 types, does exist any matrix like the translated web of the url above in the documentation of cm3 to help in the implementations of mapping types? Thanks ---2/6/08, Jay <jayk123 at hotmail.com> wrote: De: Jay <jayk123 at hotmail.com> Asunto: [M3devel] unsigned integers? Para: "m3devel at elegosoft.com" <m3devel at elegosoft.com> Fecha: lunes, 2 junio, 2008 4:07 #yiv1585025748 .hmmessage P { margin:0px;padding:0px;} #yiv1585025748 .hmmessage { FONT-SIZE:10pt;FONT-FAMILY:Tahoma;} What is the status and chance of a 32 bit integer with the range 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. 0xFFFFFFFFFFFFFFFF?     Already available? Impossible to provide? Only available in unsafe modules? Only available with restricted operations in safe modules, and more operations in unsafe modules?     Specifically, I think looping from 0 to N is safe -- no overflow. Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow. Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow. Adding or subtracting an INTEGER to "UNSIGNED" is not safe. Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow. Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe. Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done carefully.   Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL or UNSIGNED. The unsafe operations above could be runtime checked perhaps.   I guess that's a different larger point/dilemna -- when to allow potentially unsafe operations but with runtime checks vs. the compiler just disallowing them entirely. e.g. adding an integer to an integer is not even safe, but checked maybe at runtime (ok, at least assignment to subrange types is checked). Yes, I know I know, the runtime checks on at least many integer operations is yet lacking.   Is there any, um, value in such a type? Is it just me blindly trying to cast Modula-3 as C (yes), but there's no actual value (uncertain)?   Btw, I agree there's no point in this type in representing file sizes or offsets. They should be at least 63 bit integers. One bit doesn't buy much for file sizes. It might be something for address spaces though?   It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = INTEGER. It seems quite wrong. Perhaps the unsigned types larger than 16 bits just should not be defined in Cstdint. ?? But there is already Ctypes.unsigned_int, unsigned_long_long, whose underlying type I think is signed, but which convention says you just don't do signed operations on, but which the compiler doesn't enforce, right?   You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED/UINT??????    - Jay ______________________________________________ Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Tue Jun 3 04:43:20 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 02 Jun 2008 21:43:20 -0500 Subject: [M3devel] unsigned integers? In-Reply-To: References: Message-ID: <4844AFC8.5060004@wichita.edu> It's already available, but takes a bit of care. Modula-2 had an INTEGER and a CARDINAL, the latter unsigned and having full unsigned range for its word size. I think it was not fully defined in the original language report. It turned out a semantic nightmare. It was a nightmare to code too. Been there, done that. Modula-3's CARDINAL, as I'm sure everybody knows is just the positive half range of INTEGER and behaves just like a subrange of INTEGER. This solves a lot of problems, at the cost of taking away half the unsigned range. For full-range unsigned, you use the type INTEGER, but use the operations in interface Word. It's the same type, but different interpretations applied to the same bit pattern. It would be a good practice to declare things as INTEGER when they are signed and Word.T when unsigned, but there is nothing in the language to require it. In the case of addition and subtraction, builtin operators "+" and "-" will produce the same results as Word.Plus and Word.Minus, respectively, except that the conditions under which overflow is detected will differ. Not that that matters much, as, AFAIK, none of the implementations detect integer overflows anyway. So use INTEGER and the unary and binary operators if you want it to be signed, and use Word.T and Word. if you want it unsigned. Of course, you are free to assign between a variable that is being treated as signed and one treated as unsigned any time, without any overflow checks, unless you program them yourself. This certainly violates the intuition about what safety means. However, on closer look, it is not at all the same degree of unsafety as, say, arrays going out of bounds. My definition of safe is that nothing can happen that cannot be explained using only the concepts of the language. For example, to understand what an array bounds error actually does, you would need to know that an array actually shares memory with other variables, code, etc., and then a huge amount about how the compiler, linker, loader, heap allocator, etc. lay things out, along with what is declared in all the code, including libraries you are not working on. None of this is part of a so-called high-level language. The INTEGER/Word.T thing can be explained knowing about binary twos-complement representation, which is definitely a machine-level concept. The Word interface defines the unsigned side of it as a language concept too, but only hints at the signed representation. But most importantly, neither the operators nor the functions in Word.T ever produce any values that are not meaningful in the value set of the type. There is no really good linguistic solution to this problem, but I think Modula-3's is definitely the least painful I have seen. Jay wrote: > What is the status and chance of a 32 bit integer with the range > 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. > 0xFFFFFFFFFFFFFFFF? > > > Already available? > Impossible to provide? > Only available in unsafe modules? > Only available with restricted operations in safe modules, and more > operations in unsafe modules? > > > Specifically, I think looping from 0 to N is safe -- no overflow. > Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow. > Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow. > Adding or subtracting an INTEGER to "UNSIGNED" is not safe. > Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow. > Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe. > Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done > carefully. > Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL > or UNSIGNED. > The unsafe operations above could be runtime checked perhaps. > I guess that's a different larger point/dilemna -- when to allow > potentially unsafe operations but with runtime checks vs. the compiler > just disallowing them entirely. e.g. adding an integer to an integer is > not even safe, but checked maybe at runtime (ok, at least assignment to > subrange types is checked). Yes, I know I know, the runtime checks on at > least many integer operations is yet lacking. > > Is there any, um, value in such a type? > Is it just me blindly trying to cast Modula-3 as C (yes), but there's no > actual value (uncertain)? > > > Btw, I agree there's no point in this type in representing file sizes or > offsets. They should be at least 63 bit integers. One bit doesn't buy > much for file sizes. It might be something for address spaces though? > > It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = > INTEGER. It seems quite wrong. > Perhaps the unsigned types larger than 16 bits just should not be > defined in Cstdint. ?? > But there is already Ctypes.unsigned_int, unsigned_long_long, whose > underlying type I think is signed, but which convention says you just > don't do signed operations on, but which the compiler doesn't enforce, > right? > > You know, maybe Word.T should not be INTEGER but this mythological > UNSIGNED/UINT?????? > > - Jay -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jayk123 at hotmail.com Tue Jun 3 05:10:40 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 3 Jun 2008 03:10:40 +0000 Subject: [M3devel] unsigned integers? In-Reply-To: <4844AFC8.5060004@wichita.edu> References: <4844AFC8.5060004@wichita.edu> Message-ID: Very interesting. The suggestion of one of the links is that the extra range of a full unsigned type isn't particularly needed, once you have 31 bits instead of only 15. Now, in C, it is common to do a manual range check, and having unsigned cuts that check in half, makes it easier to get correct. However Modula-3 does that checking for you, taking away more of the point of the full unsigned type. So I guess there's just no need. It might be nice to make Word.T != INTEGER though. ? Gotta run. - Jay> Date: Mon, 2 Jun 2008 21:43:20 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] unsigned integers?> > It's already available, but takes a bit of care.> > Modula-2 had an INTEGER and a CARDINAL, the latter unsigned and having> full unsigned range for its word size. I think it was not fully> defined in the original language report. It turned out a semantic> nightmare. It was a nightmare to code too. Been there, done that.> > Modula-3's CARDINAL, as I'm sure everybody knows is just the positive> half range of INTEGER and behaves just like a subrange of INTEGER.> This solves a lot of problems, at the cost of taking away half the> unsigned range.> > For full-range unsigned, you use the type INTEGER, but use the> operations in interface Word. It's the same type, but different> interpretations applied to the same bit pattern. It would be a> good practice to declare things as INTEGER when they are signed> and Word.T when unsigned, but there is nothing in the language to> require it.> > In the case of addition and subtraction, builtin operators "+" and> "-" will produce the same results as Word.Plus and Word.Minus,> respectively, except that the conditions under which overflow is> detected will differ. Not that that matters much, as, AFAIK, none> of the implementations detect integer overflows anyway.> > So use INTEGER and the unary and binary operators if you want it to> be signed, and use Word.T and Word. if you want it unsigned.> > Of course, you are free to assign between a variable that is being> treated as signed and one treated as unsigned any time, without any> overflow checks, unless you program them yourself. This certainly> violates the intuition about what safety means. However, on closer> look, it is not at all the same degree of unsafety as, say, arrays> going out of bounds.> > My definition of safe is that nothing can happen that cannot be> explained using only the concepts of the language. For example,> to understand what an array bounds error actually does, you would> need to know that an array actually shares memory with other variables,> code, etc., and then a huge amount about how the compiler, linker,> loader, heap allocator, etc. lay things out, along with what is> declared in all the code, including libraries you are not working on.> None of this is part of a so-called high-level language.> > The INTEGER/Word.T thing can be explained knowing about binary> twos-complement representation, which is definitely a machine-level> concept. The Word interface defines the unsigned side of it as> a language concept too, but only hints at the signed representation.> But most importantly, neither the operators nor the functions in> Word.T ever produce any values that are not meaningful in the value> set of the type.> > There is no really good linguistic solution to this problem, but> I think Modula-3's is definitely the least painful I have seen.> > > Jay wrote:> > What is the status and chance of a 32 bit integer with the range > > 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. > > 0xFFFFFFFFFFFFFFFF?> > > > > > Already available?> > Impossible to provide?> > Only available in unsafe modules?> > Only available with restricted operations in safe modules, and more > > operations in unsafe modules?> > > > > > Specifically, I think looping from 0 to N is safe -- no overflow.> > Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow.> > Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow.> > Adding or subtracting an INTEGER to "UNSIGNED" is not safe.> > Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.> > Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe.> > Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done > > carefully.> > Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL > > or UNSIGNED.> > The unsafe operations above could be runtime checked perhaps.> > I guess that's a different larger point/dilemna -- when to allow > > potentially unsafe operations but with runtime checks vs. the compiler > > just disallowing them entirely. e.g. adding an integer to an integer is > > not even safe, but checked maybe at runtime (ok, at least assignment to > > subrange types is checked). Yes, I know I know, the runtime checks on at > > least many integer operations is yet lacking.> > > > Is there any, um, value in such a type?> > Is it just me blindly trying to cast Modula-3 as C (yes), but there's no > > actual value (uncertain)?> > > > > > Btw, I agree there's no point in this type in representing file sizes or > > offsets. They should be at least 63 bit integers. One bit doesn't buy > > much for file sizes. It might be something for address spaces though?> > > > It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = > > INTEGER. It seems quite wrong.> > Perhaps the unsigned types larger than 16 bits just should not be > > defined in Cstdint. ??> > But there is already Ctypes.unsigned_int, unsigned_long_long, whose > > underlying type I think is signed, but which convention says you just > > don't do signed operations on, but which the compiler doesn't enforce, > > right?> > > > You know, maybe Word.T should not be INTEGER but this mythological > > UNSIGNED/UINT??????> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jun 3 11:34:46 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 3 Jun 2008 09:34:46 +0000 Subject: [M3devel] unaligned record fields? Message-ID: I have on my machine like: m3core/src/win32 UINT8 = BITS 8 FOR ... UINT16 = BITS 16 FOR ... UINT32 = BITS 32 FOR ...(actually via an edited Cstdint). This is turning up, as I understand, two sets of problems, one "invented" and easy to fix, one "preexisting" and I don't know how to solve. "Problem" 1: structs that require inserting padding to be aligned: FOO = RECORD a: UINT16; b: UINT32; END; => Could not find a legal alignment... Fixed with: FOO = RECORD a: UINT16; >> padding: UINT16; b: UINT32; END; I think this a good thing, however it definitely might break some code out there -- that is, the problem where I make a breaking change, rebuild all of cm3, fix things up, but that isn't all the Modula-3 code in the world. Really, this is a good thing. I TEND to think that quiet insertion of padding for alignment is a bad thing, but that it should also by default be an error to declare unaligned fields. Granted, if you are going to share binary files between architectures, you might be forced to quash the error and allow unaligned fields. Really, I'm not sure what the answer is, but I don't think the current way of doing things, in the broader C/C++ world, is correct. It causes too many headaches to be correct. I suspend judgement about Modula-3 out of ignorance. At least I found a way, accidentally, for it trigger errors for things I don't like, but I haven't found a way to let through things that while dubious, are meant to be asis (see problem #2). Problem 1b: One record was missing a field! Add that back and the warning goes away. Nice to catch that. Problem 2: types that are not "internally" naturally aligned There are at least of these. The ??? stuff is not my introducing. (*??? #pragma pack(2) *) PBITMAPFILEHEADER = UNTRACED REF BITMAPFILEHEADER; LPBITMAPFILEHEADER = UNTRACED REF BITMAPFILEHEADER; BITMAPFILEHEADER = BITS (16_E * 8) FOR RECORD bfType : UINT16; bfSize : UINT32; (* this is not aligned *) bfReserved1: UINT16; bfReserved2: UINT16; bfOffBits : UINT32; (* nor is this *) END; (*??? #pragma pack() *) (*??? #pragma pack(2) *) PMETAHEADER = UNTRACED REF METAHEADER; LPMETAHEADER = UNTRACED REF METAHEADER; METAHEADER = RECORD mtType : UINT16; mtHeaderSize : UINT16; mtVersion : UINT16; mtSize : UINT32; (* This is not aligned. *) mtNoObjects : UINT16; mtMaxRecord : UINT32; (This is ok. *) mtNoParameters: UINT16; END; (*??? #pragma pack() *) I assume/fear that Modula-3 was not previously laying these types out correctly. NOTE that I don't see evidence of them being really used, so this isn't likely related to "bitmap problems". How does one declare these? I think the best I can do for now is change the unaligned fields to be arrays of bytes and hope nobody uses them. These two programs confirm the bug: UNSAFE MODULE A EXPORTS Main; IMPORT WinGDI;IMPORT IO; VARa: WinGDI.BITMAPFILEHEADER;b: WinGDI.METAHEADER; PROCEDURE F1(a,b: ADDRESS) =BEGIN IO.PutInt(b - a); IO.Put("\n");END F1; BEGIN F1(ADR(a), ADR(a.bfSize)); F1(ADR(b), ADR(b.mtSize)); END A. This prints 4 and 8. vs. #include #include ACCEL a;IMAGE_DOS_HEADER b;TOKEN_STATISTICS c;SE_IMPERSONATION_STATE d;COMSTAT e;BITMAPFILEHEADER f;METAHEADER g;FORMAT_PARAMETERS h;FORMAT_EX_PARAMETERS i;DISK_GEOMETRY j; int main(){ return 0;} look at it in a debugger, should be 2 and 6: 0:000> ?? fstruct tagBITMAPFILEHEADER +0x000 bfType : 0 +0x002 bfSize : 0 +0x006 bfReserved1 : 0 +0x008 bfReserved2 : 0 +0x00a bfOffBits : 00:000> ?? gstruct tagMETAHEADER +0x000 mtType : 0 +0x002 mtHeaderSize : 0 +0x004 mtVersion : 0 +0x006 mtSize : 0 +0x00a mtNoObjects : 0 +0x00c mtMaxRecord : 0 +0x010 mtNoParameters : 0 Btw, regarding struct stat, I did write Modula-3 code to form a string that represents all the sizes/offsets of the fields. We could write little tests that does that, and similar C code, and then compares the strings for equality. And/or invest a little more in C code that prints out correct Modula .i3 files, driven by a bunch of data with sizeof and offsetof, including sorting by offsetof, and checking for padding by adding offsetof+sizeof. It kind of looks like "lazyalign" is the answer, but I know this was brought up as "broken" recently, but that "Darwin (MacOSX)" needs it. I didn't follow the discusion closely. Lazyalign maybe is exactly the thing, as long as it is applicable on a type-by-type or field-by-field basis. There are some <* UNALIGNED *> and <* PRAGMA UNALIGNED *> but I see no implementation of these. I think they are being silently ignored. ?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jun 3 11:36:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 3 Jun 2008 09:36:25 +0000 Subject: [M3devel] FW: unsigned integers? In-Reply-To: <4844AFC8.5060004@wichita.edu> References: <4844AFC8.5060004@wichita.edu> Message-ID: truncated yet again, albeit slightly.. From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; m3devel at elegosoft.comSubject: RE: [M3devel] unsigned integers?Date: Tue, 3 Jun 2008 03:10:40 +0000 Very interesting.The suggestion of one of the links is that the extra range of a full unsigned type isn't particularly needed, once you have 31 bits instead of only 15.Now, in C, it is common to do a manual range check, and having unsigned cuts that check in half, makes it easier to get correct -- no need to remember to check for >=0, but also easy to do that..However Modula-3 does that checking for you, taking away more of the point of the full unsigned type.So I guess there's just no need.It might be nice to make Word.T != INTEGER though. ?Gotta run. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 5 13:30:40 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 5 Jun 2008 11:30:40 +0000 Subject: [M3devel] modula-3 uniq.exe? Message-ID: The Modula-3 tree has a simple little uniq.exe. It's like 10 lines, looks reasonable. I haven't debugged it, but when I have \cm3\bin and therefore \cm3\bin\uniq.exe early in %PATH%, building in m3-sys/m3cc hangs. I have seen this twice recently, so it wasn't a one time fluke. Both times I control-c, delete \cm3\bin\uniq.exe, rmdir /q/s NT386 (cross builds of m3cc use a two part output directory), cm3 again, and problem solved. I know it's good to build everything possible, make it sure it all builds and all that, but the code is pretty trivial and uninteresting. How about we remove it from the "std" group? (I'm still not using pkginfo.txt myself, hypocrisy, but let's assume I am; pylib.py has its own list currently.) Or in its m3makefile put like if not equal(target, "nt386") around it all I know I know, I'm lazy, it should be debugged and fixed properly, but it just doesn't seem all that worthwhile. And I also don't to have to keep deleting it. Cloning varous utilities in Modula-3 is a great exercise in using/testing/learning Modula-3, but maybe they shouldn't be identically named or installed or alway installed? Granted, installing them is a great way to test them... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jun 5 14:36:44 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 05 Jun 2008 14:36:44 +0200 Subject: [M3devel] modula-3 uniq.exe? In-Reply-To: References: Message-ID: <20080605143644.n8a7b6az484400ww@mail.elegosoft.com> Quoting Jay : > > The Modula-3 tree has a simple little uniq.exe. It's like 10 lines, > looks reasonable. > I haven't debugged it, but when I have \cm3\bin and therefore > \cm3\bin\uniq.exe early in %PATH%, building in m3-sys/m3cc hangs. I > have seen this twice recently, so it wasn't a one time fluke. Both > times I control-c, delete \cm3\bin\uniq.exe, rmdir /q/s > NT386 (cross builds of m3cc use a two part output > directory), cm3 again, and problem solved. > > I know it's good to build everything possible, make it sure it all > builds and all that, but the code is pretty trivial and uninteresting. > > How about we remove it from the "std" group? > > (I'm still not using pkginfo.txt myself, hypocrisy, but let's assume > I am; pylib.py has its own list currently.) > > Or in its m3makefile put like if not equal(target, "nt386") around it all > I know I know, I'm lazy, it should be debugged and fixed properly, > but it just doesn't seem all that worthwhile. And I also don't to > have to keep deleting it. I think the only point of this program was to make uniq available on Win32, but I don't remember that is has ever been used outside Critical Mass Inc. Thus exluding it on NT386 wouldn't make much sense in my opinion. I've got no problem to remove it from std, as long as we don't really need it somewhere. And I don't really understand why your builds hang; perhaps this would be worth investigating? Olaf > Cloning varous utilities in Modula-3 is a great exercise in > using/testing/learning Modula-3, but maybe they shouldn't be > identically named or installed or alway installed? Granted, > installing them is a great way to test them... > > - 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 jayk123 at hotmail.com Thu Jun 5 20:46:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 5 Jun 2008 18:46:22 +0000 Subject: [M3devel] floats in IL Message-ID: Tony, the way floats/doubles are read/used by parse.c is definitely wrong. Gcc wants an array of longs. At the very least, the current code hits alignment faults on OpenBSD/sparc64. 32 bit architectures would be ok, as would AMD64. As well, gcc wants 32 bits per long -- even if the longs are larger than that. So even on AMD64 it is probably reading garbage. So how about something like this: static treescan_float (unsigned *fkind){ unsigned long i = get_int (); long n_bytes; long longs[(sizeof(long double) + sizeof(long) - 1) / sizeof(long)] = { 0 }; tree tipe; REAL_VALUE_TYPE val; *fkind = i; switch (i) { case 0: tipe = t_reel; n_bytes = REEL_BYTES; break; case 1: tipe = t_lreel; n_bytes = LREEL_BYTES; break; case 2: tipe = t_xreel; n_bytes = XREEL_BYTES; break; default: fatal_error(" *** invalid floating point value, precision = 0x%lx, at m3cg_lineno %d", i, m3cg_lineno); } /* read the value's bytes; each long holds 32 bits */ for (i = 0; i < n_bytes; i++) { longs[i / 4] |= ((0xFF & get_int ()) << ((i % 4) * 8)); } /* finally, assemble a floating point value */ if (tipe == t_reel) { real_from_target_fmt (&val, longs, &ieee_single_format); } else { real_from_target_fmt (&val, longs, &ieee_double_format); } return build_real (tipe, val);}I'd also feel better if get_int returned an unsigned type but don't have enough evidence there yet to change it. And this looks suspicous: #define INTEGER(x) long x = get_int()#define UNUSED_INTEGER(x) int x ATTRIBUTE_UNUSED = get_int()static longget_int (void){ long i, n_bytes, sign, val, shift; i = (long) get_byte (); switch (i) { case M3CG_Int1: return (long) get_byte (); case M3CG_NInt1: return - (long) get_byte (); case M3CG_Int2: n_bytes = 2; sign = 1; break; case M3CG_NInt2: n_bytes = 2; sign = -1; break; case M3CG_Int4: n_bytes = 4; sign = 1; break; case M3CG_NInt4: n_bytes = 4; sign = -1; break; case M3CG_Int8: n_bytes = 8; sign = 1; break; case M3CG_NInt8: n_bytes = 8; sign = -1; break; default: return i; } for (val = 0, shift = 0; n_bytes > 0; n_bytes--, shift += 8) { val = val | (((long) get_byte ()) << shift); } return sign * val;} 8 bytes in a long? I think it needs to be a high and low host wide int, or at least a host wide int and assume that is 64 bits. But I haven't debugged this either, just went groveling for "long". Oh, scan_target_int looks better. Probably get_int is guaranteeably only up to 32 bits and the "8" cases should fail an assertion?or get_int is guaranteed to fit in a host long, so should only assert on the 8 cases if a long is smaller than 8 bytes? It appears that cm3 and cm3cg must be on the same host, that the IL format is not "portable". Because of the endianness of the float/double constants. But I'm not 100% sure. If you don't have time to look at, fix, test this, I will. Just that, you know, I can be both lazy and respectful at the same time. :) Thank, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jun 5 21:05:20 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 5 Jun 2008 20:05:20 +0100 Subject: [M3devel] floats in IL In-Reply-To: References: Message-ID: Indeed there may be problems with those fragments since there were some changes needed there in porting forward into newer versions of gcc. Feel free to fix as needs be. That code has provenance from well before me so no feelings of mine will get hurt. Go for it. On Jun 5, 2008, at 7:46 PM, Jay wrote: > Tony, the way floats/doubles are read/used by parse.c is definitely > wrong. > Gcc wants an array of longs. > At the very least, the current code hits alignment faults on OpenBSD/ > sparc64. > 32 bit architectures would be ok, as would AMD64. > > As well, gcc wants 32 bits per long -- even if the longs are larger > than that. > So even on AMD64 it is probably reading garbage. > > So how about something like this: > > static tree > scan_float (unsigned *fkind) > { > unsigned long i = get_int (); > long n_bytes; > long longs[(sizeof(long double) + sizeof(long) - 1) / > sizeof(long)] = { 0 }; > tree tipe; > REAL_VALUE_TYPE val; > > *fkind = i; > switch (i) { > case 0: tipe = t_reel; n_bytes = REEL_BYTES; break; > case 1: tipe = t_lreel; n_bytes = LREEL_BYTES; break; > case 2: tipe = t_xreel; n_bytes = XREEL_BYTES; break; > default: > fatal_error(" *** invalid floating point value, precision = 0x > %lx, at m3cg_lineno %d", > i, m3cg_lineno); > } > > /* read the value's bytes; each long holds 32 bits */ > for (i = 0; i < n_bytes; i++) > { > longs[i / 4] |= ((0xFF & get_int ()) << ((i % 4) * 8)); > } > > /* finally, assemble a floating point value */ > if (tipe == t_reel) { > real_from_target_fmt (&val, longs, &ieee_single_format); > } else { > real_from_target_fmt (&val, longs, &ieee_double_format); > } > return build_real (tipe, val); > } > > I'd also feel better if get_int returned an unsigned type but don't > have enough evidence there yet to change it. > > And this looks suspicous: > > #define INTEGER(x) long x = get_int() > #define UNUSED_INTEGER(x) int x ATTRIBUTE_UNUSED = get_int() > static long > get_int (void) > { > long i, n_bytes, sign, val, shift; > i = (long) get_byte (); > switch (i) { > case M3CG_Int1: return (long) get_byte (); > case M3CG_NInt1: return - (long) get_byte (); > case M3CG_Int2: n_bytes = 2; sign = 1; break; > case M3CG_NInt2: n_bytes = 2; sign = -1; break; > case M3CG_Int4: n_bytes = 4; sign = 1; break; > case M3CG_NInt4: n_bytes = 4; sign = -1; break; > case M3CG_Int8: n_bytes = 8; sign = 1; break; > case M3CG_NInt8: n_bytes = 8; sign = -1; break; > default: return i; > } > for (val = 0, shift = 0; n_bytes > 0; n_bytes--, shift += 8) { > val = val | (((long) get_byte ()) << shift); > } > return sign * val; > } > > > 8 bytes in a long? > I think it needs to be a high and low host wide int, or at least a > host wide int and assume that is 64 bits. > But I haven't debugged this either, just went groveling for "long". > Oh, scan_target_int looks better. > Probably get_int is guaranteeably only up to 32 bits and the "8" > cases should fail an assertion? > or get_int is guaranteed to fit in a host long, so should only > assert on the 8 cases if a long is smaller than 8 bytes? > > It appears that cm3 and cm3cg must be on the same host, that the IL > format is not "portable". > Because of the endianness of the float/double constants. > But I'm not 100% sure. > > If you don't have time to look at, fix, test this, I will. > Just that, you know, I can be both lazy and respectful at the same > time. :) > > Thank, > - Jay From rodney.bates at wichita.edu Sat Jun 7 18:23:27 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 07 Jun 2008 11:23:27 -0500 Subject: [M3devel] windowsResoures not found Message-ID: <484AB5FF.2080307@wichita.edu> I just tried some building on a new computer, using current cvs updates, as of 2008-6-6. scripts/do-cm3-all.sh build fails with: package windowsResources not found *** cannot find package windowsResources / However, ls -ld m3-sys/windowsResources gives: drwxr-xr-x 4 rodney rodney 4096 2008-06-05 19:07 m3-sys/windowsResources so the files are there. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jayk123 at hotmail.com Sun Jun 8 00:22:49 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 7 Jun 2008 22:22:49 +0000 Subject: [M3devel] windowsResoures not found In-Reply-To: <484AB5FF.2080307@wichita.edu> References: <484AB5FF.2080307@wichita.edu> Message-ID: Try scripts/python instead? - Jay> Date: Sat, 7 Jun 2008 11:23:27 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: [M3devel] windowsResoures not found> > I just tried some building on a new computer, using current cvs updates,> as of 2008-6-6. scripts/do-cm3-all.sh build fails with:> > package windowsResources not found> *** cannot find package windowsResources /> > However, ls -ld m3-sys/windowsResources gives:> > drwxr-xr-x 4 rodney rodney 4096 2008-06-05 19:07 m3-sys/windowsResources> > so the files are there.> > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jun 8 16:39:18 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 8 Jun 2008 15:39:18 +0100 Subject: [M3devel] windowsResoures not found In-Reply-To: References: <484AB5FF.2080307@wichita.edu> Message-ID: <2CFDBEDE-4A3D-45CB-B7C0-A16B09E9745B@cs.purdue.edu> We need to make sure that the standard build scripts work the same on all platforms. It is not acceptable that we forgo the elegant platform independent uniformity of Modula-3 installation procedures. On Jun 7, 2008, at 11:22 PM, Jay wrote: > Try scripts/python instead? > > - Jay > > > > > > Date: Sat, 7 Jun 2008 11:23:27 -0500 > > From: rodney.bates at wichita.edu > > To: m3devel at elegosoft.com > > Subject: [M3devel] windowsResoures not found > > > > I just tried some building on a new computer, using current cvs > updates, > > as of 2008-6-6. scripts/do-cm3-all.sh build fails with: > > > > package windowsResources not found > > *** cannot find package windowsResources / > > > > However, ls -ld m3-sys/windowsResources gives: > > > > drwxr-xr-x 4 rodney rodney 4096 2008-06-05 19:07 m3-sys/ > windowsResources > > > > so the files are there. > > > > > > > > -- > > ------------------------------------------------------------- > > Rodney M. Bates, retired assistant professor > > Dept. of Computer Science, Wichita State University > > Wichita, KS 67260-0083 > > 316-978-3922 > > rodney.bates at wichita.edu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jun 8 20:40:26 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 8 Jun 2008 18:40:26 +0000 Subject: [M3devel] windowsResoures not found In-Reply-To: <2CFDBEDE-4A3D-45CB-B7C0-A16B09E9745B@cs.purdue.edu> References: <484AB5FF.2080307@wichita.edu> <2CFDBEDE-4A3D-45CB-B7C0-A16B09E9745B@cs.purdue.edu> Message-ID: I use one elegant set of build scripts and installation procedures for all platforms. Sh is platform independent and elegant and Python is not? Rodney delete scripts/PKGS and let it get regenerated. I hope to shortly fix it so PKGS never needs to be regenerated. Either a) we should just check it in, pruned down to the small required contents like Randy's cmd stuff or b) I have Solaris up and running so can test out "platform independent" Sh changes, and then the version can be appended to the filename and rm PKGS* before regenerating. - Jay CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] windowsResoures not foundDate: Sun, 8 Jun 2008 15:39:18 +0100 We need to make sure that the standard build scripts work the same on all platforms. It is not acceptable that we forgo the elegant platform independent uniformity of Modula-3 installation procedures. On Jun 7, 2008, at 11:22 PM, Jay wrote: Try scripts/python instead? - Jay> Date: Sat, 7 Jun 2008 11:23:27 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: [M3devel] windowsResoures not found> > I just tried some building on a new computer, using current cvs updates,> as of 2008-6-6. scripts/do-cm3-all.sh build fails with:> > package windowsResources not found> *** cannot find package windowsResources /> > However, ls -ld m3-sys/windowsResources gives:> > drwxr-xr-x 4 rodney rodney 4096 2008-06-05 19:07 m3-sys/windowsResources> > so the files are there.> > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jun 9 15:20:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Jun 2008 15:20:59 +0200 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST Message-ID: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> One more test failure compared to yestereday's run: p211. Anybody knows the reason for this? Olaf ----- Forwarded message from wagner at luthien.in-berlin.de ----- Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST) From: Olaf Wagner Reply-To: Olaf Wagner Subject: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST To: wagner at luthien.iceflower.in-berlin.de Cc: wagner at elego.de === 2008-06-09 01:30:38 checkout cm3 to /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK checkout 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP === 2008-06-09 01:38:52 checkout cm3 done === 2008-06-09 01:38:52 build cm3 core in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK build_lastok_core 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK build_lastok_core_lastok 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 /home/wagner/work/cm3-inst/luthien/last-ok === 2008-06-09 01:53:43 cm3 release build done === 2008-06-09 01:53:43 build cm3 core in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last release /home/wagner/work/cm3-inst/luthien/rel-5.4.0 >>> OK build_rel_upgrade 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK build_rel_core 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK build_rel_core_lastok 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 /home/wagner/work/cm3-inst/luthien/last-ok === 2008-06-09 02:15:19 cm3 release build done === 2008-06-09 02:15:19 build cm3 bindist snapshot in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 === 2008-06-09 02:18:44 cm3 snapshot build done === 2008-06-09 02:18:44 build cm3 std in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK build_std_std 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 >>> OK build_std_std_lastok 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 /home/wagner/work/cm3-inst/luthien/last-ok === 2008-06-09 02:32:35 cm3 release build done === 2008-06-09 02:32:35 run cm3 compiler and runtime regression test suite in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> test_m3tests error extract: >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 p211 r001 e020 e026 e029 >>> 13 in test_m3tests 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 === 2008-06-09 02:34:35 cm3 m3tests run done === 2008-06-09 02:34:35 build all packages and generate report in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 === 2008-06-09 02:37:16 cm3 package status run done === 2008-06-09 02:37:16 build HTML package doc in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version >>> OK test_m3tohtml 2008-06-09-01-30-38 /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 === 2008-06-09 02:38:53 m3tohtml run done ----- End forwarded message ----- -- 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 jayk123 at hotmail.com Mon Jun 9 19:48:03 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 9 Jun 2008 17:48:03 +0000 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> Message-ID: This is a new test that I just added and it should work.Do you have any details on the failure?The output? I thought I tested on both NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have to double check though.(Testing on NT386 is less relevant.) In particular, there was a bug here on new/inactiveplatforms and I wanted a test to verify my fix.The bug caused some platforms to bus/alignment error in cm3cg. I will have to double check both that I updated my cm3cg and ran the test. My internet connection is extremely slow lately and thisis hampering me. I have to call tech support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST> > One more test failure compared to yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > ----- Forwarded message from wagner at luthien.in-berlin.de -----> Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > Reply-To: Olaf Wagner > Subject: CM3 regression test from luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > === 2008-06-09 01:30:38 checkout cm3 to > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK checkout 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_lastok_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK build_rel_upgrade 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 build cm3 std in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_std_std 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_std_std_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and runtime regression test > suite in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok version> >>> test_m3tests error extract:> >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> 13 in test_m3tests 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all packages and generate report in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build HTML package doc in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > -- > 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 jayk123 at hotmail.com Mon Jun 9 20:10:37 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 9 Jun 2008 18:10:37 +0000 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> Message-ID: Both NT386GNU and PPC_DARWIN look good to me. I'm double checking something on PPC_DARWIN but expect it'll still look good. If the program builds, please send me the output. also cm3 -keep and the A.mc file. I'll go and check the tinderbox now..if my internet holds up.. Thanks, - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Mon, 9 Jun 2008 17:48:03 +0000Subject: Re: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 This is a new test that I just added and it should work.Do you have any details on the failure?The output?I thought I tested on both NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have to double check though.(Testing on NT386 is less relevant.) In particular, there was a bug here on new/inactiveplatforms and I wanted a test to verify my fix.The bug caused some platforms to bus/alignment error in cm3cg. I will have to double check both that I updated my cm3cg and ran the test.My internet connection is extremely slow lately and thisis hampering me. I have to call tech support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST> > One more test failure compared to yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > ----- Forwarded message from wagner at luthien.in-berlin.de -----> Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > Reply-To: Olaf Wagner > Subject: CM3 regression test from luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > === 2008-06-09 01:30:38 checkout cm3 to > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK checkout 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_lastok_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK build_rel_upgrade 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 build cm3 std in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_std_std 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_std_std_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and runtime regression test > suite in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok version> >>> test_m3tests error extract:> >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> 13 in test_m3tests 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all packages and generate report in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build HTML package doc in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > -- > 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 jayk123 at hotmail.com Mon Jun 9 21:03:58 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 9 Jun 2008 19:03:58 +0000 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> Message-ID: http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1213020039.1032 27414 --- p211 --- float and double constants work27415 cd ../src/p2/p211 && cm3 -silent -DM3TESTS >SOLgnu/stdout.build.raw 2>SOLgnu/stderr.build.raw27416 ../src/p2/p211/stdout.build is missing27417 ../src/p2/p211/stderr.build is missing27418 No differences encountered27419 No differences encountered I just need to add the stdout.build and stderr.build files? - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Mon, 9 Jun 2008 18:10:37 +0000Subject: Re: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 Both NT386GNU and PPC_DARWIN look good to me. I'm double checking something on PPC_DARWIN but expect it'll still look good.If the program builds, please send me the output.also cm3 -keep and the A.mc file. I'll go and check the tinderbox now..if my internet holds up.. Thanks, - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Mon, 9 Jun 2008 17:48:03 +0000Subject: Re: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 This is a new test that I just added and it should work.Do you have any details on the failure?The output?I thought I tested on both NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have to double check though.(Testing on NT386 is less relevant.) In particular, there was a bug here on new/inactiveplatforms and I wanted a test to verify my fix.The bug caused some platforms to bus/alignment error in cm3cg. I will have to double check both that I updated my cm3cg and ran the test.My internet connection is extremely slow lately and thisis hampering me. I have to call tech support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:38 CEST> > One more test failure compared to yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > ----- Forwarded message from wagner at luthien.in-berlin.de -----> Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > Reply-To: Olaf Wagner > Subject: CM3 regression test from luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > === 2008-06-09 01:30:38 checkout cm3 to > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK checkout 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_lastok_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK build_rel_upgrade 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_rel_core_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 build cm3 std in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK build_std_std 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK build_std_std_lastok 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and runtime regression test > suite in /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok version> >>> test_m3tests error extract:> >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> 13 in test_m3tests 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all packages and generate report in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build HTML package doc in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > -- > 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 wagner at elegosoft.com Wed Jun 11 17:13:26 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 11 Jun 2008 17:13:26 +0200 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> Message-ID: <20080611171326.zaa7yv31r4oso4s4@mail.elegosoft.com> Sorry for the long delays; I don't keep up with reading all my mails currently, and haven't got time to really check what's going on in CM3. It seems that the fact that I was able to invest some significant amount of time for the regression test framework some months ago, this is no indication at all that I'll be able to keep it like this. So sorry to all who are waiting for things I should do (like a new CM3 release ):-/ Quoting Jay : > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1213020039.1032 > 27414 --- p211 --- float and double constants work27415 > cd ../src/p2/p211 && cm3 -silent -DM3TESTS > >SOLgnu/stdout.build.raw 2>SOLgnu/stderr.build.raw27416 > ../src/p2/p211/stdout.build is missing27417 > ../src/p2/p211/stderr.build is missing27418 No differences > encountered27419 No differences encountered > I just need to add the stdout.build and stderr.build files? If it's a new test and the files are missing, you probably have to add them. Why doesn't it show up for you on your test platforms? It's no big matter though. I just wondered. Olaf > - Jay > > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > m3devel at elegosoft.comDate: Mon, 9 Jun 2008 18:10:37 +0000Subject: > Re: [M3devel] Fwd: CM3 regression test from > luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 > > > Both NT386GNU and PPC_DARWIN look good to me. I'm double checking > something on PPC_DARWIN but expect it'll still look good.If the > program builds, please send me the output.also cm3 -keep and the > A.mc file. I'll go and check the tinderbox now..if my internet holds > up.. Thanks, - Jay > > > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > m3devel at elegosoft.comDate: Mon, 9 Jun 2008 17:48:03 +0000Subject: > Re: [M3devel] Fwd: CM3 regression test from > luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 > > This is a new test that I just added and it should work.Do you have > any details on the failure?The output?I thought I tested on both > NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have > to double check though.(Testing on NT386 is less relevant.) In > particular, there was a bug here on new/inactiveplatforms and I > wanted a test to verify my fix.The bug caused some platforms to > bus/alignment error in cm3cg. I will have to double check both that > I updated my cm3cg and ran the test.My internet connection is > extremely slow lately and thisis hampering me. I have to call tech > support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: > wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] > Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon > 9 Jun 2008 03:30:38 CEST> > One more test failure compared to > yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > > ----- Forwarded message from wagner at luthien.in-berlin.de -----> > Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > > Reply-To: Olaf Wagner > > Subject: CM3 regression test from > luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> > To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > > === 2008-06-09 01:30:38 checkout cm3 to > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > checkout 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === > 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build > cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > build_lastok_core_lastok 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 > cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last > release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK > build_rel_upgrade 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > build_rel_core 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > build_rel_core_lastok 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 > cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist > snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === > 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 > build cm3 std in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > version> >>> OK build_std_std 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > build_std_std_lastok 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 > cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and > runtime regression test > suite in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok > version> >>> test_m3tests error extract:> >>> failed tests: p116b > p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> > 13 in test_m3tests 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all > packages and generate report in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build > HTML package doc in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: > +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Thu Jun 12 02:44:44 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 11 Jun 2008 20:44:44 -0400 Subject: [M3devel] thread alert problem on NT386 Message-ID: <48503937.1E75.00D7.1@scires.com> I'm running across a problem on Windows XP using threads. Specifically, I am getting the following runtime error: *** *** runtime error: *** Thread client error: Alert called from non-Modula-3 thread *** file "..\src\thread\WIN32\ThreadWin32.m3", line 325 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x5dbfea4 0x5c5e5c Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbfedc 0x5c3acd Alert + 0x35 in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbff2c 0x403bb1 CloseWindow + 0x185 in ..\src\Main.m3 0x5dbff50 0x4082c3 TaskApply + 0x5b in ..\src\Utils.m3 0x5dbff88 0x5c4a6a RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbffb4 0x5c4803 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... Now, I know for a fact that the thread calling Thread.Alert is indeed a modula-3 thread. Any ideas? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 12 03:14:29 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 12 Jun 2008 01:14:29 +0000 Subject: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3 In-Reply-To: <20080611171326.zaa7yv31r4oso4s4@mail.elegosoft.com> References: <20080609152059.gtexuxydwowgo0gk@mail.elegosoft.com> <20080611171326.zaa7yv31r4oso4s4@mail.elegosoft.com> Message-ID: > add them. Why doesn't it show up for you on your test platforms? I have yet to figure out how to run the Tinderbox correctly. I need to. I tried twice without much luck. Probably should not have bothered with NT386 at the time but used Darwin or such. So I don't see the full reporting or know how it works, what it loks for. I can do cd m3-sys/m3tests; cm3 though. That is much of it and useful. I know to look for "@" for diffs, or other diffs. Maybe I should do cm3 -DHTML? I'll try that. - Jay> Date: Wed, 11 Jun 2008 17:13:26 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3> > Sorry for the long delays; I don't keep up with reading all my> mails currently, and haven't got time to really check what's> going on in CM3. It seems that the fact that I was able to invest> some significant amount of time for the regression test framework> some months ago, this is no indication at all that I'll be able> to keep it like this. So sorry to all who are waiting for things I> should do (like a new CM3 release ):-/> > Quoting Jay :> > > http://tinderbox.elegosoft.com/tinderbox/cgi-bin/gunzip.cgi?tree=cm3&brief-log=1213020039.1032> > 27414 --- p211 --- float and double constants work27415 > > cd ../src/p2/p211 && cm3 -silent -DM3TESTS > > >SOLgnu/stdout.build.raw 2>SOLgnu/stderr.build.raw27416 > > ../src/p2/p211/stdout.build is missing27417 > > ../src/p2/p211/stderr.build is missing27418 No differences > > encountered27419 No differences encountered> > I just need to add the stdout.build and stderr.build files?> > If it's a new test and the files are missing, you probably have to> add them. Why doesn't it show up for you on your test platforms?> It's no big matter though. I just wondered.> > Olaf> > > - Jay> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > > m3devel at elegosoft.comDate: Mon, 9 Jun 2008 18:10:37 +0000Subject: > > Re: [M3devel] Fwd: CM3 regression test from > > luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3> >> >> > Both NT386GNU and PPC_DARWIN look good to me. I'm double checking > > something on PPC_DARWIN but expect it'll still look good.If the > > program builds, please send me the output.also cm3 -keep and the > > A.mc file. I'll go and check the tinderbox now..if my internet holds > > up.. Thanks, - Jay> >> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > > m3devel at elegosoft.comDate: Mon, 9 Jun 2008 17:48:03 +0000Subject: > > Re: [M3devel] Fwd: CM3 regression test from > > luthien.iceflower.in-berlin.de at Mon 9 Jun 2008 03:30:3> >> > This is a new test that I just added and it should work.Do you have > > any details on the failure?The output?I thought I tested on both > > NT386GNU and PPC_DARWIN.ie: little endian and big endian.I'll have > > to double check though.(Testing on NT386 is less relevant.) In > > particular, there was a bug here on new/inactiveplatforms and I > > wanted a test to verify my fix.The bug caused some platforms to > > bus/alignment error in cm3cg. I will have to double check both that > > I updated my cm3cg and ran the test.My internet connection is > > extremely slow lately and thisis hampering me. I have to call tech > > support.. - Jay> Date: Mon, 9 Jun 2008 15:20:59 +0200> From: > > wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] > > Fwd: CM3 regression test from luthien.iceflower.in-berlin.de at Mon > > 9 Jun 2008 03:30:38 CEST> > One more test failure compared to > > yestereday's run: p211.> Anybody knows the reason for this?> > Olaf> > > > ----- Forwarded message from wagner at luthien.in-berlin.de -----> > > Date: Mon, 9 Jun 2008 04:39:45 +0200 (CEST)> From: Olaf Wagner > > > Reply-To: Olaf Wagner > > > Subject: CM3 regression test from > > luthien.iceflower.in-berlin.de at > Mon 9 Jun 2008 03:30:38 CEST> > > To: wagner at luthien.iceflower.in-berlin.de> Cc: wagner at elego.de> > > > === 2008-06-09 01:30:38 checkout cm3 to > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > checkout 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 -AP> === > > 2008-06-09 01:38:52 checkout cm3 done> === 2008-06-09 01:38:52 build > > cm3 core in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > with lastok version> >>> OK build_lastok_core 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > build_lastok_core_lastok 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 01:53:43 > > cm3 release build done> === 2008-06-09 01:53:43 build cm3 core in > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with last > > release > /home/wagner/work/cm3-inst/luthien/rel-5.4.0> >>> OK > > build_rel_upgrade 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > build_rel_core 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > build_rel_core_lastok 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:15:19 > > cm3 release build done> === 2008-06-09 02:15:19 build cm3 bindist > > snapshot in > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > with lastok version> >>> OK make_bin_dist_lastok 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === > > 2008-06-09 02:18:44 cm3 snapshot build done> === 2008-06-09 02:18:44 > > build cm3 std in > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > > version> >>> OK build_std_std 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> >>> OK > > build_std_std_lastok 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 > > > /home/wagner/work/cm3-inst/luthien/last-ok> === 2008-06-09 02:32:35 > > cm3 release build done> === 2008-06-09 02:32:35 run cm3 compiler and > > runtime regression test > suite in > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with > lastok > > version> >>> test_m3tests error extract:> >>> failed tests: p116b > > p172 p185 p204 p206 p207 p209 p210 p211 r001 > e020 e026 e029> >>> > > 13 in test_m3tests 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > > 02:34:35 cm3 m3tests run done> === 2008-06-09 02:34:35 build all > > packages and generate report in > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > > version> >>> OK test_m3_all_pkgs 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > > 02:37:16 cm3 package status run done> === 2008-06-09 02:37:16 build > > HTML package doc in > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38 with lastok > > version> >>> OK test_m3tohtml 2008-06-09-01-30-38 > > > /home/wagner/work/cm3-ws/luthien-2008-06-09-01-30-38> === 2008-06-09 > > 02:38:53 m3tohtml run done> > > ----- End forwarded message -----> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH> > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: > > +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | > > USt-IdNr: DE163214194>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jun 12 05:35:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 12 Jun 2008 04:35:11 +0100 Subject: [M3devel] thread alert problem on NT386 In-Reply-To: <48503937.1E75.00D7.1@scires.com> References: <48503937.1E75.00D7.1@scires.com> Message-ID: <40E13342-3A8D-41BD-BA8C-4BC4A445408D@cs.purdue.edu> Jay will need to track this one. I've barely ever touched ThreadWin32. On Jun 12, 2008, at 1:44 AM, Randy Coleburn wrote: > I'm running across a problem on Windows XP using threads. > > Specifically, I am getting the following runtime error: > > *** > *** runtime error: > *** Thread client error: Alert called from non-Modula-3 thread > *** file "..\src\thread\WIN32\ThreadWin32.m3", line 325 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x5dbfea4 0x5c5e5c Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3 > 0x5dbfedc 0x5c3acd Alert + 0x35 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x5dbff2c 0x403bb1 CloseWindow + 0x185 in ..\src\Main.m3 > 0x5dbff50 0x4082c3 TaskApply + 0x5b in ..\src\Utils.m3 > 0x5dbff88 0x5c4a6a RunThread + 0x1f6 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x5dbffb4 0x5c4803 ThreadBase + 0x3a in ..\src\thread > \WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > > Now, I know for a fact that the thread calling Thread.Alert is > indeed a modula-3 thread. > > Any ideas? > > Regards, > Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 12 07:04:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 12 Jun 2008 05:04:22 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? Message-ID: SOLsun..using cm3cg..a bit of a contradiction there? What SOLsun means: Sun cc? Yes. Sun ld? I think so. Only Sun libs? I think so. But cm3cg, emits references to functions in libgcc.Currently just two trivial functions. In fact, I am tempted here to give their "spec"so someone can provide a "free" (non GPL) implementation.Since they get linked into client code. These functions provide unsigned 64 bit division and modulus.Rather than being sensibly named like _uint64div and_uint64mod, their names derive from gcc calling "int64"a "double integer" or "DI". A "single integer" or "SI" is 32 bits. The function prototypes are: unsigned long long __udivdi3 (unsigned long long x, unsigned long long y);unsigned long long __umoddi3 (unsigned long long x, unsigned long long y); Can someone provide "free" implementations?I saw GPLed versions already so I can't.I think I provide a hint though.They can each be implemented in one line of C.As long as the C compiler used - "open codes" then or - calls out to functions with a different name Even if the same name is used, there's a possible workaround using in-between functions. These functions are small enough that static linking should be viable.Currently they are exported from libm3core.so however.Make a separate lib?Currently they are in m3-libs/m3core/src/Csupport/libgcc.Maybe m3-libs/m3coremath/src? This would also be required in SOLsun, and nowhere else currently. There is another "problem" with SOLsun. FloatMode.m3 requires libsunmath.a.Ideally .so files are "fully" position independent and readonly.That is, not merely "relocatable", not merely "patchable" to runat any address, but can run at any address and all "patching" is done"specially" via something like a "RTOC" and/or "GOT" / "PLT" runtime table of contents global offset table procedute linkage table and/or position indepenent addressing modes (for references to self). Tangent: There are a surprisingly number of variables when dynamic linking. Many decisions to make as to the exact semantics. Are things "delay loaded" aka "statically loaded"? When I load m3.so that depends on m3core.so is m3core.so loaded immediately? Are all the functions that m3.so calls resolved immediately? This is a variable one can control through various linker switches. As well, for any function that m3core.so calls and implements, can either another .so, m3.so, or the executable itself, also implement and "replace" or "intercept" or "interpose" those functions? Again, the answer varies. On Windows, the answer is essentially no, not never. Unless you go to some extra length to allow for it. On Unix the answer seems to vary per system and switches. Allowing this interception often requires less efficient code. And at least in one place resulted in buggy code, that I fixed recently, I think it was on AMD64_LINUX. Going through the indirection mechanism, the PLT, trashes the static link in rcx, or something like that. And it is just unnecessary indirection in almost all cases. So, the questions become, what do people want/expect for Modula-3? And, does it vary from person to person? System to system? Windows is "never" going to allow the interposition. Allowing "interposition" also goes by the description "allow unresolved symbols in shared objects", to be resolved at load time. Unix often has one global namespace for all functions in a process. Apple has a similar thing between "one level namespaces" and "two level namespaces". In an older release, they had only one level namespace. Every dynamically imported function would be searched for in all dynamically loaded files. Usually at build time you know the name of the shared object you expect to find the function in. So you can have a "two level namespace" where function names are associated with a particular file name, and only that file is searched. Apple encourages this usage, though of course is bound somewhat by compatibility. You can perhaps still build binaries that run on 10.0, and binaries built to run on 10.0 in the first place can still run today. The need to do either of these is always diminishing but hard to deem zero. SOLsun linker has two related switches. libsunmath.a apparently is not built fully position independent. libm3core.so must link to it, and therefore does not have a fully read only text section. what to do? A few options: Go back to allowing unresolved symbols in SOLsun, enabling "interposition". Then I think libsunmath.a isn't used by .sos, just executables. I don't like this option. Binding functions to particular file names (not paths) seems right and is encouraged by Apple and about the only option on Windows. It seems good to use when available. Allow writable text section in all .so. This is what I commited. Allow writable text section in only libm3core.so. This is a better compromise than previous. Move FloatMode.m3 into a separate so... libm3coremath.so, and only let it have a writable text section. This is a better compromise in terms of amount of writable text, but also adds another .so. The fewer .sos the better, arguably. Change FloatMode.m3 somehow to not use libsunmath.a. I think the only way to do this is to make it do nothing at all, which is probably what most of the implementations do, but I'd have to check. FloatMode.m3 is generally implementable on many systems, like via _controlfp on NT386. It is also dangerous to be mucking with the floating mode -- what code in the process depends on the default and will be broken by it changing? Worse, the SPARC implementation has a comment saying it is implemented process-wide instead of per-thread. Really there are arguments either way. The "common" implementation just asserts false. DS3100, VAX, IRIX, SPARC, SUN386, implement FloatMode. NT386, *_DARWIN, *_LINUX, *_FREEBSD, SOLgnu do not. Maybe just turn it off for SOLsun too? or go through and provide it everywhere? Always per-thread if possible? Only on pthreads implementations preferably? (I'm not a fan of user threads in general, so don't wish to make them "better".) I think removing FloatMode for SOLsun is probably the way to go. See if that removes requirement on libsunmath.a. See if that then allows fully position independent and "resolved" symbols. And maybe there is an updated libsunmath.a? I just have a "random" version of Solaris 10 from eBay. I could try a newer OpenSolaris/Nevada version. Or drop SOLsun as uninteresting? (My internet is slow as I said. I finally finished downloading the "normal" gcc and can build it and try the more active SOLgnu instead.) That would at least ease figuring out the names of: I386_SOLARIS, AMD64_SOLARIS, SPARC64_SOLARIS no need to have two of these of those. :) And is SOLgnu meant to use GNU ld or not? It looks like not. SOLsun and SOLgnu config files are "the same" here. Could be GNU ld is compatible in command line usage though. (not yet -- I almost have the 64 bit hosted cm3cg bug figured out. it occurs the same on SPARC64_OPENBSD as AMD64_LINUX. Something about assignment being DImode vs. VOIDmode. Occurs in many places, including RTRuntimeError.Self, by virtue of it using TRY.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Jun 12 07:04:57 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 12 Jun 2008 01:04:57 -0400 Subject: [M3devel] thread alert problem on NT386 In-Reply-To: <40E13342-3A8D-41BD-BA8C-4BC4A445408D@cs.purdue.edu> References: <48503937.1E75.00D7.1@scires.com> <40E13342-3A8D-41BD-BA8C-4BC4A445408D@cs.purdue.edu> Message-ID: <48507633.1E75.00D7.1@scires.com> Thanks. I've solved the problem. It wound up being my fault. Regards, Randy >>> Tony Hosking 6/11/2008 11:35 PM >>> Jay will need to track this one. I've barely ever touched ThreadWin32. On Jun 12, 2008, at 1:44 AM, Randy Coleburn wrote: I'm running across a problem on Windows XP using threads. Specifically, I am getting the following runtime error: *** *** runtime error: *** Thread client error: Alert called from non-Modula-3 thread *** file "..\src\thread\WIN32\ThreadWin32.m3", line 325 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x5dbfea4 0x5c5e5c Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbfedc 0x5c3acd Alert + 0x35 in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbff2c 0x403bb1 CloseWindow + 0x185 in ..\src\Main.m3 0x5dbff50 0x4082c3 TaskApply + 0x5b in ..\src\Utils.m3 0x5dbff88 0x5c4a6a RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m3 0x5dbffb4 0x5c4803 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... Now, I know for a fact that the thread calling Thread.Alert is indeed a modula-3 thread. Any ideas? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Jun 12 07:26:09 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 12 Jun 2008 01:26:09 -0400 Subject: [M3devel] how to obtain screen size of a FormsVBT.T Message-ID: <48507B2B.1E75.00D7.1@scires.com> Using Trestle / FormsVBT / et al, I want to be able to place a new window in the center of the screen. Trestle.Overlap() seems to be the only way I've seen where you can specify the location of the window. Now, the problem I am having is how to determine the size of a particular FormsVBT.T instance so that I can compute where it should go on the screen. It seems that before the FormsVBT.T is actually displayed on the screen that its dimensions aren't readily visible. Here is the way I am using to find out the middle of the screen: trestle := Trestle.Connect(NIL); s := Trestle.GetScreens(trestle); middle := Rect.Middle(s[0].dom); Not sure if this is the best way, but it seems to work. Now, if I have built a FormsVBT.T, say via v := NEW(FormsVBT.T).initFromRsrc(...), I then call Trestle.Attach(v, trestle); >From this point onward, all the methods I have used to try and find out the dimensions of "v" don't seem to work reliably. If I could find out the horizontal (hsize) and vertical (vsize) dimensions of "v", I could make the following calls to place "v" in the center of the screen: nw := Point.Sub(middle, Point.FromCoords(hsize DIV 2, vsize DIV 2); Trestle.Overlap(v, s[0].id, nw); Indeed, if I make an educated guess about hsize and vsize the window is placed properly. But, of course, I need to reliably determine the size of an arbitrary window at runtime. I'd appreciate any insight anyone can give. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 12 14:23:17 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 12 Jun 2008 12:23:17 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? Message-ID: My inclination on the FloatMode/libsunmath issue is to not build the SOLsun FloatMode support, and then see/hope if libsunmath isn't otherwise needed, and -z text otherwise "works" -- if the rest of the system can be built with it. The majority of all platforms and all "current" "active" platforms do not implement FloatMode. It is a negative trend, but I can go along. If that changes, then I'd reconsider. Hopefully there is a better libsunmath.a available too though, or a better way to implement this, perhaps in assembly, maybe some of those new #pragma fenv things.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?Date: Thu, 12 Jun 2008 05:04:22 +0000 SOLsun..using cm3cg..a bit of a contradiction there?What SOLsun means: Sun cc? Yes. Sun ld? I think so. Only Sun libs? I think so.But cm3cg, emits references to functions in libgcc.Currently just two trivial functions.In fact, I am tempted here to give their "spec"so someone can provide a "free" (non GPL) implementation.Since they get linked into client code.These functions provide unsigned 64 bit division and modulus.Rather than being sensibly named like _uint64div and_uint64mod, their names derive from gcc calling "int64"a "double integer" or "DI". A "single integer" or "SI" is 32 bits.The function prototypes are:unsigned long long __udivdi3 (unsigned long long x, unsigned long long y);unsigned long long __umoddi3 (unsigned long long x, unsigned long long y);Can someone provide "free" implementations?I saw GPLed versions already so I can't.I think I provide a hint though.They can each be implemented in one line of C.As long as the C compiler used - "open codes" then or - calls out to functions with a different name Even if the same name is used, there's a possible workaround using in-between functions.These functions are small enough that static linking should be viable.Currently they are exported from libm3core.so however.Make a separate lib?Currently they are in m3-libs/m3core/src/Csupport/libgcc.Maybe m3-libs/m3coremath/src?This would also be required in SOLsun, and nowhere else currently.There is another "problem" with SOLsun.FloatMode.m3 requires libsunmath.a.Ideally .so files are "fully" position independent and readonly.That is, not merely "relocatable", not merely "patchable" to runat any address, but can run at any address and all "patching" is done"specially" via something like a "RTOC" and/or "GOT" / "PLT" runtime table of contents global offset table procedute linkage table and/or position indepenent addressing modes (for references to self).Tangent: There are a surprisingly number of variables when dynamic linking. Many decisions to make as to the exact semantics. Are things "delay loaded" aka "statically loaded"? When I load m3.so that depends on m3core.so is m3core.so loaded immediately? Are all the functions that m3.so calls resolved immediately? This is a variable one can control through various linker switches. As well, for any function that m3core.so calls and implements, can either another .so, m3.so, or the executable itself, also implement and "replace" or "intercept" or "interpose" those functions? Again, the answer varies. On Windows, the answer is essentially no, not never. Unless you go to some extra length to allow for it. On Unix the answer seems to vary per system and switches. Allowing this interception often requires less efficient code. And at least in one place resulted in buggy code, that I fixed recently, I think it was on AMD64_LINUX. Going through the indirection mechanism, the PLT, trashes the static link in rcx, or something like that. And it is just unnecessary indirection in almost all cases. So, the questions become, what do people want/expect for Modula-3? And, does it vary from person to person? System to system? Windows is "never" going to allow the interposition. Allowing "interposition" also goes by the description "allow unresolved symbols in shared objects", to be resolved at load time. Unix often has one global namespace for all functions in a process. Apple has a similar thing between "one level namespaces" and "two level namespaces". In an older release, they had only one level namespace. Every dynamically imported function would be searched for in all dynamically loaded files. Usually at build time you know the name of the shared object you expect to find the function in. So you can have a "two level namespace" where function names are associated with a particular file name, and only that file is searched. Apple encourages this usage, though of course is bound somewhat by compatibility. You can perhaps still build binaries that run on 10.0, and binaries built to run on 10.0 in the first place can still run today. The need to do either of these is always diminishing but hard to deem zero. SOLsun linker has two related switches. libsunmath.a apparently is not built fully position independent. libm3core.so must link to it, and therefore does not have a fully read only text section. what to do? A few options: Go back to allowing unresolved symbols in SOLsun, enabling "interposition". Then I think libsunmath.a isn't used by .sos, just executables. I don't like this option. Binding functions to particular file names (not paths) seems right and is encouraged by Apple and about the only option on Windows. It seems good to use when available. Allow writable text section in all .so. This is what I commited. Allow writable text section in only libm3core.so. This is a better compromise than previous. Move FloatMode.m3 into a separate so... libm3coremath.so, and only let it have a writable text section. This is a better compromise in terms of amount of writable text, but also adds another .so. The fewer .sos the better, arguably. Change FloatMode.m3 somehow to not use libsunmath.a. I think the only way to do this is to make it do nothing at all, which is probably what most of the implementations do, but I'd have to check. FloatMode.m3 is generally implementable on many systems, like via _controlfp on NT386. It is also dangerous to be mucking with the floating mode -- what code in the process depends on the default and will be broken by it changing? Worse, the SPARC implementation has a comment saying it is implemented process-wide instead of per-thread. Really there are arguments either way. The "common" implementation just asserts false. DS3100, VAX, IRIX, SPARC, SUN386, implement FloatMode. NT386, *_DARWIN, *_LINUX, *_FREEBSD, SOLgnu do not. Maybe just turn it off for SOLsun too? or go through and provide it everywhere? Always per-thread if possible? Only on pthreads implementations preferably? (I'm not a fan of user threads in general, so don't wish to make them "better".) I think removing FloatMode for SOLsun is probably the way to go. See if that removes requirement on libsunmath.a. See if that then allows fully position independent and "resolved" symbols. And maybe there is an updated libsunmath.a? I just have a "random" version of Solaris 10 from eBay. I could try a newer OpenSolaris/Nevada version. Or drop SOLsun as uninteresting? (My internet is slow as I said. I finally finished downloading the "normal" gcc and can build it and try the more active SOLgnu instead.) That would at least ease figuring out the names of: I386_SOLARIS, AMD64_SOLARIS, SPARC64_SOLARIS no need to have two of these of those. :) And is SOLgnu meant to use GNU ld or not? It looks like not. SOLsun and SOLgnu config files are "the same" here. Could be GNU ld is compatible in command line usage though. (not yet -- I almost have the 64 bit hosted cm3cg bug figured out. it occurs the same on SPARC64_OPENBSD as AMD64_LINUX. Something about assignment being DImode vs. VOIDmode. Occurs in many places, including RTRuntimeError.Self, by virtue of it using TRY.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jun 12 16:51:18 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 12 Jun 2008 15:51:18 +0100 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: Message-ID: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> There's too much in your e-mail to respond to Jay, so I'll just make a simple historical observation: SOLgnu was originally intended as a Solaris target where there was no availability of Sun's cc (Sun did not bundle cc with the OS at the time -- they wanted you to buy it!). However, the rest of the Solaris toolchain has always been bundled with the OS. Thus, with gcc the easiest free option as a replacement for cc, SOLgnu meant folks could use Modula-3 without having to buy Sun's cc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jun 12 16:51:45 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 12 Jun 2008 15:51:45 +0100 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: Message-ID: <330E728C-016F-465F-9D2D-CDC53A332A70@cs.purdue.edu> I think I agree with you here. On Jun 12, 2008, at 1:23 PM, Jay wrote: > My inclination on the FloatMode/libsunmath issue is to not build the > SOLsun FloatMode support, and then see/hope if libsunmath isn't > otherwise needed, and -z text otherwise "works" -- if the rest of > the system can be built with it. > The majority of all platforms and all "current" "active" platforms > do not implement FloatMode. > It is a negative trend, but I can go along. > If that changes, then I'd reconsider. > Hopefully there is a better libsunmath.a available too though, or a > better way to implement this, perhaps in assembly, maybe some of > those new #pragma fenv things.. > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? > Date: Thu, 12 Jun 2008 05:04:22 +0000 > > SOLsun..using cm3cg.. > a bit of a contradiction there? > > What SOLsun means: > Sun cc? Yes. > Sun ld? I think so. > Only Sun libs? I think so. > > But cm3cg, emits references to functions in libgcc. > Currently just two trivial functions. > > In fact, I am tempted here to give their "spec" > so someone can provide a "free" (non GPL) implementation. > Since they get linked into client code. > > These functions provide unsigned 64 bit division and modulus. > Rather than being sensibly named like _uint64div and > _uint64mod, their names derive from gcc calling "int64" > a "double integer" or "DI". A "single integer" or "SI" is 32 bits. > > The function prototypes are: > > unsigned long long __udivdi3 (unsigned long long x, unsigned long > long y); > unsigned long long __umoddi3 (unsigned long long x, unsigned long > long y); > > Can someone provide "free" implementations? > I saw GPLed versions already so I can't. > I think I provide a hint though. > They can each be implemented in one line of C. > As long as the C compiler used > - "open codes" then > or - calls out to functions with a different name > > Even if the same name is used, there's a possible workaround using > in-between functions. > > These functions are small enough that static linking should be viable. > Currently they are exported from libm3core.so however. > Make a separate lib? > Currently they are in m3-libs/m3core/src/Csupport/libgcc. > Maybe m3-libs/m3coremath/src? > > This would also be required in SOLsun, and nowhere else currently. > > There is another "problem" with SOLsun. > FloatMode.m3 requires libsunmath.a. > Ideally .so files are "fully" position independent and readonly. > That is, not merely "relocatable", not merely "patchable" to run > at any address, but can run at any address and all "patching" is done > "specially" via something like a "RTOC" and/or "GOT" / "PLT" > runtime table of contents > global offset table > procedute linkage table > and/or position indepenent addressing modes (for references to self). > > Tangent: > There are a surprisingly number of variables when dynamic linking. > Many decisions to make as to the exact semantics. > Are things "delay loaded" aka "statically loaded"? > When I load m3.so that depends on m3core.so is > m3core.so loaded immediately? > Are all the functions that m3.so calls resolved immediately? > This is a variable one can control through various linker switches. > As well, for any function that m3core.so calls and implements, > can either another .so, m3.so, or the executable itself, also > implement and "replace" or "intercept" or "interpose" those > functions? > Again, the answer varies. > On Windows, the answer is essentially no, not never. Unless you go > to > some extra length to allow for it. > On Unix the answer seems to vary per system and switches. > Allowing this interception often requires less efficient code. > And at least in one place resulted in buggy code, that I fixed > recently, > I think it was on AMD64_LINUX. Going through the indirection > mechanism, the PLT, > trashes the static link in rcx, or something like that. > And it is just unnecessary indirection in almost all cases. > So, the questions become, what do people want/expect for Modula-3? > And, does it vary from person to person? System to system? > Windows is "never" going to allow the interposition. > Allowing "interposition" also goes by the description "allow > unresolved symbols in shared objects", to be resolved at load time. > Unix often has one global namespace for all functions in a process. > Apple has a similar thing between "one level namespaces" and "two > level namespaces". > In an older release, they had only one level namespace. Every > dynamically imported > function would be searched for in all dynamically loaded files. > Usually at build time you know the name of the shared object you > expect to find > the function in. So you can have a "two level namespace" where > function names > are associated with a particular file name, and only that file is > searched. > Apple encourages this usage, though of course is bound somewhat by > compatibility. > You can perhaps still build binaries that run on 10.0, and > binaries built to run > on 10.0 in the first place can still run today. > The need to do either of these is always diminishing but hard to > deem zero. > > SOLsun linker has two related switches. > libsunmath.a apparently is not built fully position independent. > libm3core.so must link to it, and therefore does not have a fully > read only text section. > > what to do? > > A few options: > Go back to allowing unresolved symbols in SOLsun, enabling > "interposition". > Then I think libsunmath.a isn't used by .sos, just executables. > I don't like this option. Binding functions to particular file > names (not paths) > seems right and is encouraged by Apple and about the only option > on Windows. > It seems good to use when available. > > Allow writable text section in all .so. > This is what I commited. > > Allow writable text section in only libm3core.so. > This is a better compromise than previous. > > Move FloatMode.m3 into a separate so... libm3coremath.so, > and only let it have a writable text section. > This is a better compromise in terms of amount of writable text, > but also > adds another .so. The fewer .sos the better, arguably. > > Change FloatMode.m3 somehow to not use libsunmath.a. > I think the only way to do this is to make it do nothing at all, > which > is probably what most of the implementations do, but I'd have to > check. > FloatMode.m3 is generally implementable on many systems, like via > _controlfp > on NT386. It is also dangerous to be mucking with the floating > mode -- > what code in the process depends on the default and will be > broken by it changing? > > Worse, the SPARC implementation has a comment saying it is > implemented process-wide > instead of per-thread. Really there are arguments either way. > > The "common" implementation just asserts false. > DS3100, VAX, IRIX, SPARC, SUN386, implement FloatMode. > NT386, *_DARWIN, *_LINUX, *_FREEBSD, SOLgnu do not. > > Maybe just turn it off for SOLsun too? > or go through and provide it everywhere? Always per-thread if > possible? > Only on pthreads implementations preferably? > (I'm not a fan of user threads in general, so don't wish to make > them "better".) > > I think removing FloatMode for SOLsun is probably the way to go. > See if that removes requirement on libsunmath.a. > See if that then allows fully position independent and "resolved" > symbols. > > And maybe there is an updated libsunmath.a? > I just have a "random" version of Solaris 10 from eBay. > I could try a newer OpenSolaris/Nevada version. > > Or drop SOLsun as uninteresting? > (My internet is slow as I said. I finally finished downloading > the "normal" gcc and can build it and try the more active SOLgnu > instead.) > > That would at least ease figuring out the names of: > I386_SOLARIS, AMD64_SOLARIS, SPARC64_SOLARIS > > no need to have two of these of those. :) > > And is SOLgnu meant to use GNU ld or not? > It looks like not. SOLsun and SOLgnu config files are "the same" > here. > Could be GNU ld is compatible in command line usage though. > > (not yet -- I almost have the 64 bit hosted cm3cg bug figured out. > it occurs the same on SPARC64_OPENBSD as AMD64_LINUX. Something about > assignment being DImode vs. VOIDmode. Occurs in many places, > including > RTRuntimeError.Self, by virtue of it using TRY.) > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 12 19:21:47 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 12 Jun 2008 17:21:47 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> Message-ID: Ok I'll have to send out some smaller mails. Hey, I figure, you get the quality of email you pay me for. :) The "obvious" question is, sort of, does anyone give a darn about SOLsun? Using it actively? Wanting it back? Not that I'm only "focusing" (haha) on platforms that people care about, I'm aiming at any mildly interesting target, as an exercise of some sort. (and yes, I know I'm leaving some things a bit incomplete and hope to sweep up before I get too far ahead -- AMD64_LINUX garbage colllection, NT386MINGNU __stdcall being among the older/severest issues; the AMD64_LINUX native cm3cg issue occurs on SPARC64_OPENBSD as well, I hope to fix that "next", have been stepping through looking for where things vary, vs. a cross build from NT386GNU that works..DImode vs. VOIDmode on some assignment statements..the output of cm3cg -y is identical, the output of cm3cg -da is identical before the crash except for pointers, was a while before I remember about the various -d switches, stepping through the code saw a reference to "dump_file"..). Another question is, does anyone give a darn what linker is used on SOL*? If the matter is just to use what is most easily/cheaply acquired, then the answer is use the Sun ld. Perhaps if the matter is "cross platform compatibility" then GNU, perhaps. (ie: bring along as much as you can so you can keep as much the same as possible, such as command lines/config file contents). I "just" got Solaris (8,9,10, less luck with getting 8,9 running though, so sticking with 10) from eBay. I don't know the "real" current bundling/pricing, though the OS itself is now free at least as in beer, tools I suspect too but I don't yet have the free stuff running. The free stuff seems to be kept more up to date for x86 -- at least the current release is x86 only and you have to go back a bit for SPARC. I'm not sure about AMD64. I figure they are catering to a "low end community" and hope to still charge money for the "high end" SPARC hardware (though really I expect x86/AMD64 continues to eat into everyone's lunch... as it gets steadily faster/cheaper...(and yeah, I386_SOLARIS, AMD64_SOLARIS, SPARC64_SOLARIS all on my radar but need to wait..) If the tools are free, SOLgnu becomes less interesting and SOLsun more interesting?? Or, we just run a simple market economy here and demand is pretty little all around, hard to tell? :) It happened to be a little easier/quicker/earlier for me get Sun cc up vs. gcc. But I'm wierd. I actually don't have gcc/Solaris up yet, but should before much longer. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?Date: Thu, 12 Jun 2008 15:51:18 +0100 There's too much in your e-mail to respond to Jay, so I'll just make a simple historical observation: SOLgnu was originally intended as a Solaris target where there was no availability of Sun's cc (Sun did not bundle cc with the OS at the time -- they wanted you to buy it!). However, the rest of the Solaris toolchain has always been bundled with the OS. Thus, with gcc the easiest free option as a replacement for cc, SOLgnu meant folks could use Modula-3 without having to buy Sun's cc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jun 13 11:27:44 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 13 Jun 2008 11:27:44 +0200 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> Message-ID: <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> Quoting Jay : > > Ok I'll have to send out some smaller mails. Hey, I figure, you get > the quality of email you pay me for. :) Could you be more elaborate on who exactly is paying you for M3 work? ;-) I'd like to share this experience... > The "obvious" question is, sort of, does anyone give a darn about SOLsun? > Using it actively? > Wanting it back? Not personally, but I'd just like to remind you of the fact that the Sun compilers were/are highly optimized for the SPARC architecture, so that in certain performance critical domains nobody would use gcc. I don't really know if this is still a current problem of gcc, nor do I know if it has much impacts on CM3 as the gcc backend is used anyway for all M3 code. It would be interesting how good or bad M3s compiled code actually is wrt. the different target platforms... I've got no intention to set up benchmark testing for this though ;-) > Another question is, does anyone give a darn what linker is used on SOL*? > If the matter is just to use what is most easily/cheaply acquired, > then the answer is use the Sun ld. > Perhaps if the matter is "cross platform compatibility" then GNU, > perhaps. (ie: bring along as much as you can so you can keep as much > the same as possible, such as command lines/config file contents). Are there any important differences in the linkers? I wouldn't care much otherwise. 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 13 15:33:47 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 13 Jun 2008 15:33:47 +0200 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <485227DD.1E75.00D7.1@scires.com> References: <48508629.1E75.00D7.1@scires.com> <48510198.1E75.00D7.1@scires.com> <48514EB1.1E75.00D7.1@scires.com> <48519947.1E75.00D7.1@scires.com> <20080613123201.p9rtnudjc4c8400s@mail.elegosoft.com> <485227DD.1E75.00D7.1@scires.com> Message-ID: <20080613153347.vrgtyp5ggk8kwkgo@mail.elegosoft.com> Hi Randy, thanks for the excellent summary. I'm not totally against your suggested extensions; I only try to avoid the additional variables (though they may be in the spirit of the interface). You need three additional boolean variables in Stdio.i3 to determine if one of them is lazy. If instead we had a class LazyConsoleWr.T as a subclass of Wr.T, it could be assigned to the existing Stdio.stdout variable on Windows. The only addition of this type could be the boolean function isVisible(). You could then check for the `lazyness' of the writer by calling ISTYPE( Stdio.stdout, LazyConsoleWr.T ), and if that yields true, determine if the lazy console is visible by NARROW( Stdio.stdout, LazyConsoleWr.T ).isVisible(). This would be a more object-oriented approach. I'm not sure if it really is worth the effort or if we shouldn't just live with the additional variables though. I'm also not sure if it is feasible from an implementation point of view, as I haven't had a look at the initialization code in Windows. As this hasn't been discussed on the m3devel list, and others may have interesting opinions on this, I'd like to raise this issue there, too, in the hope that we agree on a solution soon. I've added your original proposal at the end for reference. Best regards, Olaf Quoting Randy Coleburn : > I agree that adding variables to an interface is not normally a good > idea, BUT that is the way Stdio is set up currently. It uses variables > for stdout, stderr, stdin, and bufferedStderr. The client is free to > change these assignments (and indeed I have programs that do) to change > the runtime behavior. For example, you can make Stdio.stdout a TeeWr.T > to get output going to both stdout and a log file at the same time. > > Stdio provides Wr.T's for stdout & stderr, and a Rd.T for stdin. The > client doesn't really know anything else about them. I gather that Jay > is suggesting that I internally subtype these to be something else and > then externally check for the type, but I don't think this is feasible > without some interface changes that may break existing code. (I welcome > more discussion on this point.) > > The problem we have with the whole lazy console allocation issue is > that the behavior is not documented in an interface and thus there is no > way to control it. Indeed, the whole mess is hidden in the LazyConsole > module buried inside the Win32 subfolder. For Unix, there is no such > thing as lazy console allocation and indeed it is possible for one of > the Stdout variables to be NIL. On cm3 v4.1, it is also possible for > one of the Stdout variables to be NIL, especially when the program is a > GUI-mode program. > > So from a platform-independent view, we currently (cm3 v d5.7.0) have > the following four possibilities for each of the Stdio variables: > 1. variable represents a valid writer/reader to an allocated console > window (or other file/device if command line redirection or pipelining > is used); > 2. variable represents a lazy-allocated console window that is not yet > visible; > 3. variable represents a lazy-allocated console window that has popped > up on the screen (probably occluding part of the real gui window); > 4. variable is NIL because the process has no standard file handle of > this type (but only if not running on Windows). > > Since the lazy-allocation is hidden from view, the client code has no > way of knowing reliably at runtime which of the 4 states the program is > in, and on Windows the state can change dynamically from #2 to #3 (it is > not constant as when on Unix). > > On cm3 v4.1, states #2 & #3 did not exist, so clients could simply > check if the variable was NIL to know whether I/O to the Stdout > variables would work. But now, on cm3 v5.7 there is no way to make this > check reliably on all platforms because on Windows state #4 cannot exist > and states #2 and #3 are hidden from the programmer. Further, since > this behavior is not documented in an interface, the change from 4.1 to > 5.7 breaks existing 4.1 code. When I say "breaks" I don't mean > necessarily that the program crashes, but rather that the behavior is > different than expected and thus "broken". > > Now the primary advantage (possibly the only advantage) to the new lazy > console allocation scheme on Windows is that your GUI-mode program won't > crash if you write to stdout without ensuring it is non-NIL. (Maybe > this begs the question of whether the lazy-allocation is really > needed.) > > The proposal I made has the following advantages: > A. It does not break any existing code. > B. It keeps the same spirit of Stdio in terms of using variables. > C. It gives programmers the opportunity to prevent or allow the lazy > pop-up console windows. > D. If programmers don't make a choice about the lazy pop-up windows, > there is no change in behavior from current operation. > E. It works on Unix or Windows (thus is platform-independent) > F. It allows programmers to go back and easily adjust old code built > for cm3 v4.1 to work as expected when built using cm3 5.7. > > The proposal has the following disadvantages: > X. It continues the practice of putting variables in an interface > (assuming this practice is frowned upon) > Y. Since it augments two prominent interfaces (Stdio & Process), it > will require rebuilding of everything. > Z. Programmers using features of the revised interfaces won't be able > to compile their code using older versions of cm3. > > Here is a quick example showing the utility of knowing at runtime about > the lazy allocation: Suppose you have a -GUI mode program. There is a > lot of code in libraries et al that expects to write to stdout to > provide error messages, etc. If the user calls my -GUI program with the > wrong arguments, I want to give him an error message. In the current > situation on Windows, if I write to stdout or stderr, I will get a > pop-up console window that will flash up briefly, but disappear as soon > as the program terminates. On Unix, the behavior is different since > there is no pop-up console window. If I knew at runtime that the > stdout/stderr was lazy-allocated, I could pause for a few seconds to > allow the user to see the error message on the pop-up console, or I > could redirect the message to a file, or I could even require the user > to acknowledge the pop-up console message by pressing Enter on the > keyboard before terminating the program. I could also choose not to > send output to stdout when the console is lazy-allocated and thus > prevent an extra icon from showing up in the task bar. In short, I > believe the lazy-allocation needs to be exposed so programmers can deal > with it appropriately for the operating context of their program. > > If you don't want to go the route of my proposal, I'm welcome to hear > another suggestion on how to expose runtime knowledge of the lazy > allocation. > > Regards, > Randy Original proposal: 1. Add procedure AreStdFileHandlesLazy (VAR stdIn_IsLazy, stdOut_IsLazy, stdErr_IsLazy: BOOLEAN) to interface Process. This won't break any existing code since it is a new procedure addition, but it will force rebuilding of everything. 2. Adjust internals of Process implementations to deal with implementation of this new procedure. The procedure's parameter output values for all platforms will be FALSE, except for Windows where they will depend on whether the file is lazily allocated. These changes will be transparent to all clients. 3. Add following variables to Stdio interface: stdIn_IsLazy, stdOut_IsLazy, stdErr_IsLazy: BOOLEAN; This change won't break any existing code, but it will force rebuilding of everything. 4. Modify Stdio implementation to properly initialize the new variables during module initialization. This change will be transparent to all clients. Now, with these changes, it will be possible for a client to know whether stdout, stderr, and/or stdin represent lazily allocated consoles or not, then act accordingly. For example, if I want to make sure messages written to stdout are recorded even for a GUI-app, but I don't want a popup, I could do the following: IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) THEN Stdio.stdout := FileWr.Open("myLogFile.txt"); Stdio.stdOut_IsLazy := FALSE; END; Now the above code fragment does show the possibility of a race condition in multi-threaded code. I suggest that a comment be added to the Stdio interface that states any manipulation of the exposed variables should be done from single-threaded code or that the client should implement use of a mutex. Otherwise, we could change Stdio to have get/set procedures, but that would break a lot of existing code. Indeed, instead of changing the Stdio interface, it would be better IMO to just provide an extra interface/implementation that provides these functions and tell new multi-threaded clients to use the thread-friendly version. Please let me know what you think about this proposal. If it is okay, I'd like to go ahead and make the changes to the repository, including adding a warning comment about thread friendliness. I won't provide the extra thread-friendly interface/implementation of Stdio unless you want it. Now that I think about it, I should also add the following function procedures to Stdio (3 variants, one each for stdout, stderr, and stdin) and that would probably eliminate need for the thread-friendly interface: PROCEDURE EnsureNotLazyStdOut (alternateWr: Wr.T) : BOOLEAN = (* If stdout is NIL or lazily allocated, replace it by alternateWr, which must be a valid writer (non-nil). Returns TRUE if alternateWr is substituted for stdout; otherwise returns FALSE. Note that this function is thread-safe. *) BEGIN <*ASSERT alternateWr # NIL*> LOCK privateMutex DO IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) THEN Stdio.stdout := alternateWr; Stdio.stdOut_IsLazy := FALSE; RETURN TRUE; ELSE RETURN FALSE; END; END; END EnsureNotLazyStdOut; -- 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 jayk123 at hotmail.com Sat Jun 14 00:58:05 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 13 Jun 2008 22:58:05 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> Message-ID: Right, good point, gcc usually generates worse code than any other compiler. "We" don't have much C code though, so the compiler is mostly just a driver for the linker. > It would be interesting how good or bad M3s compiled code actually The little I've looked at is not good, but nobody notices. Besides I don't want to pay the time or the risk or lost debugability of gcc's optimizer so I don't use it lately. The integrated backend is quite in the middle. It does certain local optimizations all the time, but lacks analysis over a larger scope.> Are there any important differences in the linkers? I wouldn't care> much otherwise. I don't know. I'm still working on getting gcc and ld built/installed/working, though might skip them. Sun ld is what is in use and, for once, I'll say I have enough other stuff to leave this very very low priority. (My ambition on this platform is basically -- make sure I can build it, make sure I can build a distribution, finally introduce "version.txt" now having Solaris /bin/sh/sed/awk to test with!, and then add introduce SPARC64_SOLARIS -- begging the question of GNU/Sun targets...) Hm, speaking of version.txt -- if I test on Solaris 10, good enough? Are folks on this list using Modula-3 on older versions of Solaris? Even so, what works on 10 "probably" works on older. - Jay> Date: Fri, 13 Jun 2008 11:27:44 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?> > Quoting Jay :> > >> > Ok I'll have to send out some smaller mails. Hey, I figure, you get > > the quality of email you pay me for. :)> > Could you be more elaborate on who exactly is paying you for M3 work? ;-)> I'd like to share this experience...> > > The "obvious" question is, sort of, does anyone give a darn about SOLsun?> > Using it actively?> > Wanting it back?> > Not personally, but I'd just like to remind you of the fact that> the Sun compilers were/are highly optimized for the SPARC architecture,> so that in certain performance critical domains nobody would use> gcc. I don't really know if this is still a current problem of gcc,> nor do I know if it has much impacts on CM3 as the gcc backend is> used anyway for all M3 code.> > It would be interesting how good or bad M3s compiled code actually> is wrt. the different target platforms... I've got no intention to> set up benchmark testing for this though ;-)> > > Another question is, does anyone give a darn what linker is used on SOL*?> > If the matter is just to use what is most easily/cheaply acquired, > > then the answer is use the Sun ld.> > Perhaps if the matter is "cross platform compatibility" then GNU, > > perhaps. (ie: bring along as much as you can so you can keep as much > > the same as possible, such as command lines/config file contents).> > Are there any important differences in the linkers? I wouldn't care> much otherwise.> > 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 hosking at cs.purdue.edu Sat Jun 14 13:43:07 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 14 Jun 2008 12:43:07 +0100 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> Message-ID: Can you justify that statement? On Jun 13, 2008, at 11:58 PM, Jay wrote: > > Right, good point, gcc usually generates worse code than any other > compiler From jayk123 at hotmail.com Sat Jun 14 19:32:32 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 14 Jun 2008 17:32:32 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> <20080613112744.stahoswa8sgs48o8@mail.elegosoft.com> Message-ID: mostly rumor, hearsay..sorryI had some examples a few months ago but too lazy to dig them up. - Jay> CC: wagner at elegosoft.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> To: jayk123 at hotmail.com> Subject: Re: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?> Date: Sat, 14 Jun 2008 12:43:07 +0100> > Can you justify that statement?> > On Jun 13, 2008, at 11:58 PM, Jay wrote:> > >> > Right, good point, gcc usually generates worse code than any other > > compiler> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jun 15 14:20:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 15 Jun 2008 12:20:12 +0000 Subject: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..? In-Reply-To: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> References: <3A52DEDA-A595-4235-BEBD-8F2324E56BB5@cs.purdue.edu> Message-ID: Ok, I'm able to build SOLsun now.I uploaded min and std archives. Juno and some other apps can display on Cygwin. caveats: I forgot to put in Unix.common. Just copy it in from the source tree. I haven't yet been able to build cm3cg, so I used one from a daily SOLgnu (and it depends on libiconv) whatever Sun cc I have (5.8 2005/10/13), won't bootstrap gcc 4.3.1. It doesn't like for example #define FOO(a,b) blah FOO(,c) I'd rather not just download prebuilt binaries.I'll try (Canadian) crossing from Cygwin, else a more current Solaris.Cross is tricky. It is well documented you need to copy over /usr/include,but less clear to me about libs like values*.o, needed for building libgcc,which is needed at some point it seems, or at least there is an attempt to use it..and then not clear to use /usr/local//lib, or -sysroot=/usr/local/ and mimic structure from there (include vs. usr/include, lib vs. usr/lib and usr/ccs/lib)..I'll see... A lot of the cross documentation and friendly wrappers assumes crossing from Linux to Linux. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?Date: Thu, 12 Jun 2008 17:21:47 +0000 ......snip...... -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Jun 18 16:36:59 2008 From: rodney.bates at wichita.edu (rodney.bates) Date: Wed, 18 Jun 2008 09:36:59 -0500 Subject: [M3devel] =?iso-8859-1?q?proposal_for_dealing_with_lazy_console--?= =?iso-8859-1?q?please_review_and_=09comment!?= Message-ID: <481A920F@webmail.wichita.edu> I don't understand well enough what it means for a console to be lazily-allocated, but I wonder if it makes any sense to allow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T ever be lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside procedures that do it in a thread-safe way? >4. Modify Stdio implementation to properly initialize the new >variables during module initialization. >This change will be transparent to all clients. > >Now, with these changes, it will be possible for a client to know >whether stdout, stderr, and/or stdin represent lazily allocated >consoles or not, then act accordingly. > >For example, if I want to make sure messages written to stdout are >recorded even for a GUI-app, but I don't want a popup, I could do the >following: > IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) > THEN > Stdio.stdout := FileWr.Open("myLogFile.txt"); > Stdio.stdOut_IsLazy := FALSE; > END; >Now the above code fragment does show the possibility of a race >condition in multi-threaded code. > Rodney Bates Retired assistant professor Computer Science From rcoleburn at scires.com Wed Jun 18 18:50:29 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 18 Jun 2008 12:50:29 -0400 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <481A920F@webmail.wichita.edu> References: <481A920F@webmail.wichita.edu> Message-ID: <48590490.1E75.00D7.1@scires.com> Hi Rodney: Thanks for your reply. The issue is that for cm3 on Windows you can specify -gui as a command line option. This option causes the program to be built as a Windows GUI-mode application, rather than as a console application. For a GUI-mode application, the Stdio file handles are NIL because it has no console. Seemingly, to prevent a lot of errors when trying to read/write Stdio, some folks introduced the idea of a lazy console post cm3 v4.1. What happens now "under the covers" is that on a GUI-mode program the Stdio file handles are allocated as Lazy Consoles. Then, whenever Stdio.stdout/stderr/stdin is used, the underlying code realizes the first use and magically allocates a new console window on the fly. This console window pops up on the screen on top of your GUI-mode window. My objection is that this behavior is not documented in any interface and the programmer has no way to control the behavior. I want to make such control possible. Hope this explanation helps a bit. Regards, Randy >>> "rodney.bates" 6/18/2008 10:36 AM >>> I don't understand well enough what it means for a console to be lazily-allocated, but I wonder if it makes any sense to allow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T ever be lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside procedures that do it in a thread-safe way? >4. Modify Stdio implementation to properly initialize the new >variables during module initialization. >This change will be transparent to all clients. > >Now, with these changes, it will be possible for a client to know >whether stdout, stderr, and/or stdin represent lazily allocated >consoles or not, then act accordingly. > >For example, if I want to make sure messages written to stdout are >recorded even for a GUI-app, but I don't want a popup, I could do the >following: > IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) > THEN > Stdio.stdout := FileWr.Open("myLogFile.txt"); > Stdio.stdOut_IsLazy := FALSE; > END; >Now the above code fragment does show the possibility of a race >condition in multi-threaded code. > Rodney Bates Retired assistant professor Computer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jun 18 19:20:03 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 18 Jun 2008 17:20:03 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <48590490.1E75.00D7.1@scires.com> References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> Message-ID: Randy, really, the vast majority of behavior is undocumented and not controllable. However I agree making this controllable is perfectly reasonable. The folks that did this were I believe Critical Mass, between "4.1" and "5.1", though granted the history is not completely known, just that 4.1 and earlier doesn't behave this way. I strongly advocate a type-based solution here. However, I believe there are several bits per handle however, not one. Not at the Win32 level, but in terms of the control you would want in the Modula-3. There is: Is the console visible? Either because it started that way, or because "someone" has written to it already. Should any/no write make it visible? Should "this particular" write make it visible? That is, you probably want the ability to avoid the console becoming visible. You probably want the ability to control this globally or per-write. Maybe even per-thread and not just per-process. And, say, if there is a severe error, you want to enable it becoming visible. And, say, if someone else wrote an error and made it visible and now you just have a warning, you might want to "piggy back" on the visibility and go ahead and print. You may even want to rehide the console, if that is possible. (Could expose this in the interface and it make it a nop..) Controlling this per-thread or per-process or per-write is actually pretty problematic. Because even if it is per-thread or per-process, I believe it should at the same time be per-handle. I should be able to block revelation on stdout for current thread, and then restore it when I am done. While leaving stderr unaltered, on the theory that stderr output is more important. Similarly per-process. But then each handle has per-thread locals. Ok, duh, per-process doesn't make sense, that's the same as per-handle. Controlling it per-handle is not problematic. Each handle would just have a fixed set of extra bits. I believe controlling it module-wide either per-process or per-thread *might* be interesting, but less so. Globals are bad. Even if hidden behind thread-safe functions. Just because Modula-3 nicely contains process-globals in modules, doesn't make them acceptable. I think modules are overrated actually, and "objects" -- instances of types are much more important. Modula-3 does "work", just that I should in general create Foo.T data and pass them as the first parameter to Foo.DoSomething. Programming is much more "type based" than "module based" imho. I know there is some disagreement here, but I'm not sure there is much. Really, there is a general issue of globals vs. parameters to functions, throughout a callstack. One implementation strategy would be to able to create a "wrapper" object. You would set the "policy" on that object -- perhaps via which type you created in the first place. You would pass that around to all your code. That would achieve per-thread, or per-whatever-you want, BUT it'd require you pass it around to all of your code. It is a tough discpline to really pass around all parameters, and not rely on some larger "global" or per-thread context. Thread locals and globals quite stink, and "plumbing the full depths of a call tree" can also be quite difficult". The problem, you know, of "oops, I forgot to add a parameter in lots of places. What do I do now? I know, I'll make a thread local, set it at the top of the call tree, check it in the middle or at the bottom, but not pass it all around..." It's a difficult problem. Much of the code in a particular call tree might not know or care about what the top and bottom care about, but somehow should be able to ferry along "context". Thread locals are so tempting and oh so problematic... - Jay Date: Wed, 18 Jun 2008 12:50:29 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Hi Rodney: Thanks for your reply. The issue is that for cm3 on Windows you can specify -gui as a command line option. This option causes the program to be built as a Windows GUI-mode application, rather than as a console application. For a GUI-mode application, the Stdio file handles are NIL because it has no console. Seemingly, to prevent a lot of errors when trying to read/write Stdio, some folks introduced the idea of a lazy console post cm3 v4.1. What happens now "under the covers" is that on a GUI-mode program the Stdio file handles are allocated as Lazy Consoles. Then, whenever Stdio.stdout/stderr/stdin is used, the underlying code realizes the first use and magically allocates a new console window on the fly. This console window pops up on the screen on top of your GUI-mode window. My objection is that this behavior is not documented in any interface and the programmer has no way to control the behavior. I want to make such control possible. Hope this explanation helps a bit. Regards, Randy>>> "rodney.bates" 6/18/2008 10:36 AM >>>I don't understand well enough what it means for a consoleto be lazily-allocated, but I wonder if it makes any sense toallow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T everbe lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside proceduresthat do it in a thread-safe way?>4. Modify Stdio implementation to properly initialize the new>variables during module initialization.>This change will be transparent to all clients.>>Now, with these changes, it will be possible for a client to know>whether stdout, stderr, and/or stdin represent lazily allocated>consoles or not, then act accordingly.>>For example, if I want to make sure messages written to stdout are>recorded even for a GUI-app, but I don't want a popup, I could do the>following:> IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL)> THEN> Stdio.stdout := FileWr.Open("myLogFile.txt");> Stdio.stdOut_IsLazy := FALSE;> END;>Now the above code fragment does show the possibility of a race>condition in multi-threaded code.>Rodney BatesRetired assistant professorComputer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Jun 19 05:18:59 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 18 Jun 2008 23:18:59 -0400 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> Message-ID: <485997DD.1E75.00D7.1@scires.com> Jay: I'd be satisfied just to deal with this on a per program instance, rather than at a thread level. Indeed, I'm not sure it makes sense on a per thread level. The Stdio module and global vars are shared by all code in the program process. I'm wondering if it might be better at this point to use environment variables to control the behavior. The current implementation initializes everything during module initialization at program startup. Thus, this occurs before dependent modules get a chance to run and influence the behavior. Perhaps the lazy console allocation should be the default unless a certain environment variable is set, say CM3_LazyConsole=FALSE. In this case the initialization code would turn off the lazy allocation and in the case of a GUI-mode program on Windows the Stdio.stdin/stdout/stderr would be NIL. If CM3_LazyConsole=TRUE or is not defined, you would get a lazy allocated console on Windows GUI-mode programs and a regular console otherwise. This approach has the advantage that no interfaces have to change. Of course, if folks want to add finer grains of control as you suggest, that would be ok. I just want to be able to prevent the popup of the lazy allocated console. I'm willing to make the modifications to the code unless someone objects to my approach. Regards, Randy >>> Jay 6/18/2008 1:20 PM >>> Randy, really, the vast majority of behavior is undocumented and not controllable. However I agree making this controllable is perfectly reasonable. The folks that did this were I believe Critical Mass, between "4.1" and "5.1", though granted the history is not completely known, just that 4.1 and earlier doesn't behave this way. I strongly advocate a type-based solution here. However, I believe there are several bits per handle however, not one. Not at the Win32 level, but in terms of the control you would want in the Modula-3. There is: Is the console visible? Either because it started that way, or because "someone" has written to it already. Should any/no write make it visible? Should "this particular" write make it visible? That is, you probably want the ability to avoid the console becoming visible. You probably want the ability to control this globally or per-write. Maybe even per-thread and not just per-process. And, say, if there is a severe error, you want to enable it becoming visible. And, say, if someone else wrote an error and made it visible and now you just have a warning, you might want to "piggy back" on the visibility and go ahead and print. You may even want to rehide the console, if that is possible. (Could expose this in the interface and it make it a nop..) Controlling this per-thread or per-process or per-write is actually pretty problematic. Because even if it is per-thread or per-process, I believe it should at the same time be per-handle. I should be able to block revelation on stdout for current thread, and then restore it when I am done. While leaving stderr unaltered, on the theory that stderr output is more important. Similarly per-process. But then each handle has per-thread locals. Ok, duh, per-process doesn't make sense, that's the same as per-handle. Controlling it per-handle is not problematic. Each handle would just have a fixed set of extra bits. I believe controlling it module-wide either per-process or per-thread *might* be interesting, but less so. Globals are bad. Even if hidden behind thread-safe functions. Just because Modula-3 nicely contains process-globals in modules, doesn't make them acceptable. I think modules are overrated actually, and "objects" -- instances of types are much more important. Modula-3 does "work", just that I should in general create Foo.T data and pass them as the first parameter to Foo.DoSomething. Programming is much more "type based" than "module based" imho. I know there is some disagreement here, but I'm not sure there is much. Really, there is a general issue of globals vs. parameters to functions, throughout a callstack. One implementation strategy would be to able to create a "wrapper" object. You would set the "policy" on that object -- perhaps via which type you created in the first place. You would pass that around to all your code. That would achieve per-thread, or per-whatever-you want, BUT it'd require you pass it around to all of your code. It is a tough discpline to really pass around all parameters, and not rely on some larger "global" or per-thread context. Thread locals and globals quite stink, and "plumbing the full depths of a call tree" can also be quite difficult". The problem, you know, of "oops, I forgot to add a parameter in lots of places. What do I do now? I know, I'll make a thread local, set it at the top of the call tree, check it in the middle or at the bottom, but not pass it all around..." It's a difficult problem. Much of the code in a particular call tree might not know or care about what the top and bottom care about, but somehow should be able to ferry along "context". Thread locals are so tempting and oh so problematic... - Jay Date: Wed, 18 Jun 2008 12:50:29 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Hi Rodney: Thanks for your reply. The issue is that for cm3 on Windows you can specify -gui as a command line option. This option causes the program to be built as a Windows GUI-mode application, rather than as a console application. For a GUI-mode application, the Stdio file handles are NIL because it has no console. Seemingly, to prevent a lot of errors when trying to read/write Stdio, some folks introduced the idea of a lazy console post cm3 v4.1. What happens now "under the covers" is that on a GUI-mode program the Stdio file handles are allocated as Lazy Consoles. Then, whenever Stdio.stdout/stderr/stdin is used, the underlying code realizes the first use and magically allocates a new console window on the fly. This console window pops up on the screen on top of your GUI-mode window. My objection is that this behavior is not documented in any interface and the programmer has no way to control the behavior. I want to make such control possible. Hope this explanation helps a bit. Regards, Randy >>> "rodney.bates" 6/18/2008 10:36 AM >>> I don't understand well enough what it means for a console to be lazily-allocated, but I wonder if it makes any sense to allow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T ever be lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside procedures that do it in a thread-safe way? >4. Modify Stdio implementation to properly initialize the new >variables during module initialization. >This change will be transparent to all clients. > >Now, with these changes, it will be possible for a client to know >whether stdout, stderr, and/or stdin represent lazily allocated >consoles or not, then act accordingly. > >For example, if I want to make sure messages written to stdout are >recorded even for a GUI-app, but I don't want a popup, I could do the >following: > IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL) > THEN > Stdio.stdout := FileWr.Open("myLogFile.txt"); > Stdio.stdOut_IsLazy := FALSE; > END; >Now the above code fragment does show the possibility of a race >condition in multi-threaded code. > Rodney Bates Retired assistant professor Computer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 19 05:47:28 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 19 Jun 2008 03:47:28 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <485997DD.1E75.00D7.1@scires.com> References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> <485997DD.1E75.00D7.1@scires.com> Message-ID: Randy, just because the initialization happens early does not mean you can't affect the behavior later. The type can be changed at initialization time, and then the instance configured later. Unless you are worried about other module initializers ignorantly calling stdout.Wr() and causing the console to appear? If so, yeah. How about @M3 command line parameters instead? At least they aren't "sticky" and can be more easily localized to a single process. I ignore sh's feature here usually, and in this case that makes good sense. "Command line parameters are better than environment variables". Supporting both is reasonable. However, if so, and if it is an @M3 variable, there should perhaps be one variable to contain @M3 options?? Still I'm not a fan of globals like this. I think it should be configurable per type instantiation. You could also imagine that one variable is the "during initialization time" configuration, and then once Main starts, another configuration takes over, since by then whoever wants to set it has had a chance to run. Btw, sleazy, but you could also make it a built-time configuration. You could easily build your m3core.dll to have one default behavior, while everyone else's has another. - Jay Date: Wed, 18 Jun 2008 23:18:59 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Jay: I'd be satisfied just to deal with this on a per program instance, rather than at a thread level. Indeed, I'm not sure it makes sense on a per thread level. The Stdio module and global vars are shared by all code in the program process. I'm wondering if it might be better at this point to use environment variables to control the behavior. The current implementation initializes everything during module initialization at program startup. Thus, this occurs before dependent modules get a chance to run and influence the behavior. Perhaps the lazy console allocation should be the default unless a certain environment variable is set, say CM3_LazyConsole=FALSE. In this case the initialization code would turn off the lazy allocation and in the case of a GUI-mode program on Windows the Stdio.stdin/stdout/stderr would be NIL. If CM3_LazyConsole=TRUE or is not defined, you would get a lazy allocated console on Windows GUI-mode programs and a regular console otherwise. This approach has the advantage that no interfaces have to change. Of course, if folks want to add finer grains of control as you suggest, that would be ok. I just want to be able to prevent the popup of the lazy allocated console. I'm willing to make the modifications to the code unless someone objects to my approach. Regards, Randy>>> Jay 6/18/2008 1:20 PM >>>Randy, really, the vast majority of behavior is undocumented and not controllable.However I agree making this controllable is perfectly reasonable.The folks that did this were I believe Critical Mass, between "4.1" and "5.1", though granted the history is not completely known, just that 4.1 and earlier doesn't behave this way. I strongly advocate a type-based solution here. However, I believe there are several bits per handle however, not one.Not at the Win32 level, but in terms of the control you would want in the Modula-3. There is: Is the console visible? Either because it started that way, or because "someone" has written to it already. Should any/no write make it visible? Should "this particular" write make it visible? That is, you probably want the ability to avoid the console becoming visible.You probably want the ability to control this globally or per-write.Maybe even per-thread and not just per-process.And, say, if there is a severe error, you want to enable it becoming visible.And, say, if someone else wrote an error and made it visible and now you just have a warning, you might want to "piggy back" on the visibility and go ahead and print. You may even want to rehide the console, if that is possible.(Could expose this in the interface and it make it a nop..) Controlling this per-thread or per-process or per-write is actually pretty problematic. Because even if it is per-thread or per-process, I believe it should at the same time be per-handle. I should be able to block revelation on stdout for current thread, and then restore it when I am done. While leaving stderr unaltered, on the theory that stderr output is more important. Similarly per-process. But then each handle has per-thread locals. Ok, duh, per-process doesn't make sense, that's the same as per-handle. Controlling it per-handle is not problematic. Each handle would just have a fixed set of extra bits. I believe controlling it module-wide either per-process or per-thread *might* be interesting, but less so. Globals are bad. Even if hidden behind thread-safe functions. Just because Modula-3 nicely contains process-globals in modules, doesn't make them acceptable. I think modules are overrated actually, and "objects" -- instances of types are much more important. Modula-3 does "work", just that I should in general create Foo.T data and pass them as the first parameter to Foo.DoSomething. Programming is much more "type based" than "module based" imho. I know there is some disagreement here, but I'm not sure there is much. Really, there is a general issue of globals vs. parameters to functions, throughout a callstack. One implementation strategy would be to able to create a "wrapper" object.You would set the "policy" on that object -- perhaps via which type you created in the first place. You would pass that around to all your code. That would achieve per-thread, or per-whatever-you want, BUT it'd require you pass it around to all of your code. It is a tough discpline to really pass around all parameters, and not rely on some larger "global" or per-thread context. Thread locals and globals quite stink, and "plumbing the full depths of a call tree" can also be quite difficult". The problem, you know, of "oops, I forgot to add a parameter in lots of places. What do I do now? I know, I'll make a thread local, set it at the top of the call tree, check it in the middle or at the bottom, but not pass it all around..." It's a difficult problem. Much of the code in a particular call tree might not know or care about what the top and bottom care about, but somehow should be able to ferry along "context". Thread locals are so tempting and oh so problematic... - Jay Date: Wed, 18 Jun 2008 12:50:29 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Hi Rodney: Thanks for your reply. The issue is that for cm3 on Windows you can specify -gui as a command line option. This option causes the program to be built as a Windows GUI-mode application, rather than as a console application. For a GUI-mode application, the Stdio file handles are NIL because it has no console. Seemingly, to prevent a lot of errors when trying to read/write Stdio, some folks introduced the idea of a lazy console post cm3 v4.1. What happens now "under the covers" is that on a GUI-mode program the Stdio file handles are allocated as Lazy Consoles. Then, whenever Stdio.stdout/stderr/stdin is used, the underlying code realizes the first use and magically allocates a new console window on the fly. This console window pops up on the screen on top of your GUI-mode window. My objection is that this behavior is not documented in any interface and the programmer has no way to control the behavior. I want to make such control possible. Hope this explanation helps a bit. Regards, Randy>>> "rodney.bates" 6/18/2008 10:36 AM >>>I don't understand well enough what it means for a consoleto be lazily-allocated, but I wonder if it makes any sense toallow client code, by assignments to Stdio.stdout_Islazy, to change this property in general. Why would a FileWr.T everbe lazy, for example? Can't the cases where the lazy property needs to be controlled by client code be enclosed inside proceduresthat do it in a thread-safe way?>4. Modify Stdio implementation to properly initialize the new>variables during module initialization.>This change will be transparent to all clients.>>Now, with these changes, it will be possible for a client to know>whether stdout, stderr, and/or stdin represent lazily allocated>consoles or not, then act accordingly.>>For example, if I want to make sure messages written to stdout are>recorded even for a GUI-app, but I don't want a popup, I could do the>following:> IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL)> THEN> Stdio.stdout := FileWr.Open("myLogFile.txt");> Stdio.stdOut_IsLazy := FALSE;> END;>Now the above code fragment does show the possibility of a race>condition in multi-threaded code.>Rodney BatesRetired assistant professorComputer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jun 19 08:55:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 19 Jun 2008 08:55:10 +0200 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> <485997DD.1E75.00D7.1@scires.com> Message-ID: <20080619085510.eagbposkcg0g4g4o@mail.elegosoft.com> Quoting Jay : > Randy, just because the initialization happens early does not mean > you can't affect the behavior later. The type can be changed at > initialization time, and then the instance configured later. Unless > you are worried about other module initializers ignorantly calling > stdout.Wr() and causing the console to appear? If so, yeah. > > How about @M3 command line parameters instead? > At least they aren't "sticky" and can be more easily localized to a > single process. What does sticky mean here? > I ignore sh's feature here usually, and in this case that makes good sense. environment variables aren't a feature of shells, but or process contexts. Shells just allow to set them explicitly. > "Command line parameters are better than environment variables". > Supporting both is reasonable. Yes, if we go this way, we should support both options. An environment variable overrides a built-in default, and an explicit parameter overrides the environment setting if present. > However, if so, and if it is an @M3 variable, there should perhaps > be one variable to contain @M3 options?? Something like `@m3opt=lazyconsole,dontcrash,whatsoever'? What other options do you have in mind? > Still I'm not a fan of globals like this. I think it should be > configurable per type instantiation. > You could also imagine that one variable is the "during > initialization time" configuration, and then once Main starts, > another configuration takes over, since by then whoever wants to set > it has had a chance to run. > > Btw, sleazy, but you could also make it a built-time configuration. > You could easily build your m3core.dll to have one default behavior, > while everyone else's has another. I think we'll have to decide which way to go, as Randy needs a solution to continue his work. Currently the easiest approach seems to be the environment variable/command line solution indeed, as no interface need to be touched and no new modules are required. Would anybody object to this approach? More control could easily be added later, if that is really required. (After all, this currently is just a problem for Windows GUI programs.) What about M3_LAZY_CONSOLE and @M3lazyconsole for a start? 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 jayk123 at hotmail.com Thu Jun 19 10:04:12 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 19 Jun 2008 08:04:12 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <20080619085510.eagbposkcg0g4g4o@mail.elegosoft.com> References: <481A920F@webmail.wichita.edu> <48590490.1E75.00D7.1@scires.com> <485997DD.1E75.00D7.1@scires.com> <20080619085510.eagbposkcg0g4g4o@mail.elegosoft.com> Message-ID: set CM3_ConsoleBehavior=4.1 m3guiapp console behavior still changed m3guiapp @M3ConsoleBehavior=4.1 console behavior back to "default" - Jay> Date: Thu, 19 Jun 2008 08:55:10 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] proposal for dealing with lazy console--please review and comment!> > Quoting Jay :> > > Randy, just because the initialization happens early does not mean > > you can't affect the behavior later. The type can be changed at > > initialization time, and then the instance configured later. Unless > > you are worried about other module initializers ignorantly calling > > stdout.Wr() and causing the console to appear? If so, yeah.> >> > How about @M3 command line parameters instead?> > At least they aren't "sticky" and can be more easily localized to a > > single process.> What does sticky mean here?> > > I ignore sh's feature here usually, and in this case that makes good sense -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Sat Jun 21 16:18:35 2008 From: rodney.bates at wichita.edu (rodney.bates) Date: Sat, 21 Jun 2008 09:18:35 -0500 Subject: [M3devel] =?iso-8859-1?q?proposal_for_dealing_with_lazy_=09consol?= =?iso-8859-1?q?e--please=09review_and_comment!?= Message-ID: <481B6AEF@webmail.wichita.edu> I guess I am on a somewhat different wavelength on this. I do agree that a complete set of queries by the application should be supported, concerning lazy allocated streams. But to me, applications need to have either very little or nothing in the way of ability to change behaviour. For one thing, it makes sense for the lazy property to apply only to stdout/stderr, on win32 platforms, compiled as -gui. This is why I was questioning getting a stream from FileWr.Open, and then setting it lazy. Laziness doesn't make any sense on a disk file. Beyond that, I think at the most, an application should be able to change the laziness property only before any data has been written to the stream. After that, the window is already popped, and the semantics would get ugly. In fact, I am very skeptical about the need for an application to change laziness at all. If it can query this property, then it can just refrain from writing to the steam, if it doesn't want the window to pop up. Hence my objection to making the properties variables, not because of general principal, but because an application could assign to them at any time. >===== Original Message From Jay ===== >set CM3_ConsoleBehavior=4.1 >m3guiapp >console behavior still changed > >m3guiapp @M3ConsoleBehavior=4.1 >console behavior back to "default" > - Jay> Rodney Bates Retired assistant professor Computer Science From rcoleburn at scires.com Sat Jun 21 17:41:09 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 21 Jun 2008 11:41:09 -0400 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <481B6AEF@webmail.wichita.edu> References: <481B6AEF@webmail.wichita.edu> Message-ID: <485CE8D0.1E75.00D7.1@scires.com> Thanks Rodney and Jay for your comments. Here are a few points I'd like to add to this discussion. 1. I agree with Jay that command line arguments would be better than environment variables. 2. I agree with Rodney that the "laziness property" must be set before data gets read/written and that it should be set only once, not changed during execution. 3. A drawback to using command-line variables (and env vars) is that it shifts the responsibility from the programmer to the user. IMO, this type of behavior is something that is "designed" and documented as part of the program, so it should not be changeable by the user. For example, if the user fails to put the appropriate parameter on the command-line, the program's behavior changes. In effect, this is sort of what has happened to me, that is, the behavior of my cm3 v4.1 gui-mode program(s) has changed from its design because the underlying implementation changed to use lazy console allocation and I have no way of getting the old behavior back without changing the implementation. 4. Perhaps a better approach would be to devise a new option for the compiler. For example, "-gui" works as now and uses lazy console allocation. "-gui_no_lazy" works the way -gui did in 4.1 where the Stdio.stdin/stderr/stdout would be NIL for a gui-mode program. The problem here is I'm not sure exactly how to implement it. In effect, use of this option would mean we would need to swap (i.e., choose) the implementation of Process.m3 at compile time, OR we would need some way to ensure the Stdio variables get set to NIL after the current Process.m3 initialization (thereby undoing the lazy allocation). Maybe one of these methods can be done via quake somehow, but I'm not sure how to go about it. Any ideas? 5. If I'm the only person having this issue with the lazy allocation, perhaps I can adapt my programs. Perhaps I can just set the Stdio variables to be NIL at the beginning of my mainline code for programs I know should be compiled as -gui. This brings to mind an idea for how to implement -gui_no_lazy. Do you think we could write some quake code that causes a new module implementation to be included in the program whenever the target is NT386 AND the -gui_no_lazy option is set? This new implementation would import from Stdio and all it would do is set the Stdio vars to be NIL. Since it imports from Stdio and Stdio imports Process, I would tend to think that Process and Stdio module initializations would be run before this new module initialization thereby ensuring the lazy allocated consoles get set to NIL. What do you think? Regards, Randy >>> "rodney.bates" 6/21/2008 10:18 AM >>> I guess I am on a somewhat different wavelength on this. I do agree that a complete set of queries by the application should be supported, concerning lazy allocated streams. But to me, applications need to have either very little or nothing in the way of ability to change behaviour. For one thing, it makes sense for the lazy property to apply only to stdout/stderr, on win32 platforms, compiled as -gui. This is why I was questioning getting a stream from FileWr.Open, and then setting it lazy. Laziness doesn't make any sense on a disk file. Beyond that, I think at the most, an application should be able to change the laziness property only before any data has been written to the stream. After that, the window is already popped, and the semantics would get ugly. In fact, I am very skeptical about the need for an application to change laziness at all. If it can query this property, then it can just refrain from writing to the steam, if it doesn't want the window to pop up. Hence my objection to making the properties variables, not because of general principal, but because an application could assign to them at any time. >===== Original Message From Jay ===== >set CM3_ConsoleBehavior=4.1 >m3guiapp >console behavior still changed > >m3guiapp @M3ConsoleBehavior=4.1 >console behavior back to "default" > - Jay> Rodney Bates Retired assistant professor Computer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jun 21 18:04:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 21 Jun 2008 16:04:27 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: <485CE8D0.1E75.00D7.1@scires.com> References: <481B6AEF@webmail.wichita.edu> <485CE8D0.1E75.00D7.1@scires.com> Message-ID: 4 (compiler switch) and 5 (adapt your code) are easy enough, though 4 I have *possible* misgivings about. There is in fact an interface whose data flows like so: run the compiler it produces "startup" code (_m3main.o/_m3main.obj/_m3main.c) that startup code passes data to the runtime (RTLinker) I mucked around here to fix environment variables. The "problem" here is that compiler <=> runtime interfaces must be carefully dealt with..perhaps. I am not sure what our compatibility requires are. I don't think Modula-3 binaries are really deployed so far and wide, and old and new .dlls/.so mixed much. So probably this interface can be churned without much concern for what it was in the past. Perhaps. Whatever data flows around here should probably be a record that starts with a size and contains a "set of int" (ie: bitflags) for every field, or every field added after a certain point, and reserve enough room for there to be enough bit flags for a long time. This is a part of a path to "release to release binary compatibility". Or maybe the type fingerprints are it and there isn't really such "adaptivity" around types changing? In C and C++, it is common to runtime link where the types on either side are different, but where there is some little amount of ability to discover some aspects of the types and adapt. As stated, via a size at the start of a record and/or bitfields to indicate which fields are present. Of course, it is limited. You only ever "grow" types. You never delete or rearrange. At the very least, you need to be able to bootstrap from one version to the next. A new compiler has to work at least once against an old statically linked runtime. At the very most, new compilers have to output binaries that work with old dynamically linked runtimes. I doubt this works much really but I am curious as to everyone else's opionions and assertions. Rather than set them to nil, what about typecasing them and then replacing with a non-nil instance that ignores writes? That will save you unhandled exceptions, right? Eventually I could/would probably just sit down and solve this but I haven't had much time and have been working on other Modula-3 things -- bringing up existing/new platforms (I uploaded SOLsun archives recently, still trying to bring up gcc on Solaris (not even SOLgnu, just gcc), and lots more on the radar..), debugging the 64 bit hosted cm3cg bug(s), etc. The quake code you propose sounds trivial, yes. But lately I think more should be in cm3 and less in quake (or sh or Python). Very gradually I am folding my Python into quake and my quake into cm3. Esp. as it proves stable and useful. For example, cm3 now reveals its own platform to Quake (HOST_PLATFORM), so Quake can default to a native build, without the user telling it or it sniffing around. All the use of uname et. al. can probably go away. (see also gcc's various -print-foo switches, that let wrappers introspect about gcc already knows about the target; cm3 could perhaps use similar) My Python wrappers accept a target platform name anywhere on the command line. cm3 should probably just do that. My Quake sniffs around for a config file based on platform, next to itself or in the source tree. Cm3 should probably just do that, esp. next to itself, less clear about in the source tree. It is kind of reasonable to go around implementing things multiple times, as the initial implementations serve as prototypes to try on for size, see if they work out well. The whole mechanism where "packages" are discovered by groveling the source tree could/should probably be merged into cm3, perhaps driven by a hand authored file or files, either like Randy did for Win32, or a more hierarchical tree full of small files linking together directories, like the Windows DDK "dirs" files. - Jay Date: Sat, 21 Jun 2008 11:41:09 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Thanks Rodney and Jay for your comments. Here are a few points I'd like to add to this discussion. 1. I agree with Jay that command line arguments would be better than environment variables. 2. I agree with Rodney that the "laziness property" must be set before data gets read/written and that it should be set only once, not changed during execution. 3. A drawback to using command-line variables (and env vars) is that it shifts the responsibility from the programmer to the user. IMO, this type of behavior is something that is "designed" and documented as part of the program, so it should not be changeable by the user. For example, if the user fails to put the appropriate parameter on the command-line, the program's behavior changes. In effect, this is sort of what has happened to me, that is, the behavior of my cm3 v4.1 gui-mode program(s) has changed from its design because the underlying implementation changed to use lazy console allocation and I have no way of getting the old behavior back without changing the implementation. 4. Perhaps a better approach would be to devise a new option for the compiler. For example, "-gui" works as now and uses lazy console allocation. "-gui_no_lazy" works the way -gui did in 4.1 where the Stdio.stdin/stderr/stdout would be NIL for a gui-mode program. The problem here is I'm not sure exactly how to implement it. In effect, use of this option would mean we would need to swap (i.e., choose) the implementation of Process.m3 at compile time, OR we would need some way to ensure the Stdio variables get set to NIL after the current Process.m3 initialization (thereby undoing the lazy allocation). Maybe one of these methods can be done via quake somehow, but I'm not sure how to go about it. Any ideas? 5. If I'm the only person having this issue with the lazy allocation, perhaps I can adapt my programs. Perhaps I can just set the Stdio variables to be NIL at the beginning of my mainline code for programs I know should be compiled as -gui. This brings to mind an idea for how to implement -gui_no_lazy. Do you think we could write some quake code that causes a new module implementation to be included in the program whenever the target is NT386 AND the -gui_no_lazy option is set? This new implementation would import from Stdio and all it would do is set the Stdio vars to be NIL. Since it imports from Stdio and Stdio imports Process, I would tend to think that Process and Stdio module initializations would be run before this new module initialization thereby ensuring the lazy allocated consoles get set to NIL. What do you think? Regards, Randy>>> "rodney.bates" 6/21/2008 10:18 AM >>>I guess I am on a somewhat different wavelength on this. I doagree that a complete set of queries by the application shouldbe supported, concerning lazy allocated streams. But to me,applications need to have either very little or nothing in theway of ability to change behaviour.For one thing, it makes sense for the lazy property to applyonly to stdout/stderr, on win32 platforms, compiled as -gui.This is why I was questioning getting a stream from FileWr.Open,and then setting it lazy. Laziness doesn't make any sense ona disk file.Beyond that, I think at the most, an application should be able to change the laziness property only before any data has beenwritten to the stream. After that, the window is already popped,and the semantics would get ugly.In fact, I am very skeptical about the need for an application to change laziness at all. If it can query this property, thenit can just refrain from writing to the steam, if it doesn't wantthe window to pop up.Hence my objection to making the properties variables, not becauseof general principal, but because an application could assign tothem at any time.>===== Original Message From Jay =====>set CM3_ConsoleBehavior=4.1>m3guiapp>console behavior still changed>>m3guiapp @M3ConsoleBehavior=4.1>console behavior back to "default"> - Jay>Rodney BatesRetired assistant professorComputer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jun 21 18:17:22 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 21 Jun 2008 16:17:22 +0000 Subject: [M3devel] proposal for dealing with lazy console--please review and comment! In-Reply-To: References: <481B6AEF@webmail.wichita.edu> <485CE8D0.1E75.00D7.1@scires.com> Message-ID: > 3. A drawback to using command-line > variables (and env vars) is that it shifts > the responsibility from the programmer to > the user. IMO, this type of behavior is something > that is "designed" and documented as part of the > program, so it should not be changeable by the user. For example, if the What is constant behavior and what is settable by the user is obviously one of the big sets of questions any programmer must face. No one behavior suits everyone, and too many configurable options are confusing and harder to test. If you make everything configurable, you just ship the consumer nothing and let him "configure" it to do what he wants. Consumer can have any color Ford Model T as long as it is black... Anyway, I think the compiler command line option is reasonable, and implementing via "customizing" main to pass down the switch to runtime, while I expressed possible misgivings about it, I think is reasonable. Adapting quake to output different modules and all that I think is overkill. The main <=> RTLinker interface should probably be a little self describing anyway. And this might be main talking right to ProcessWin32 anyway. One thing I don't understand is how much Modula-3 code can be run before RTLinker. How much runtime linking does Modula-3 do itself, vs. how much code comes in from disk already ready to run. It could, heck, be C code or data if that helped. But just as well, it could flow through RTLinker en route to ProcessWin32, if that is necessary and the C and data exports are to be avoided. RTLinker does seem to do a lot more work than is "normal", in the C build model. That is, it *appears* you can't make cross Modula-3 module calls, even within the same .so/.exe/.dll. Kind of lame if true, given that many intra-module calls are already going unnecessarily through runtime linking a the C level (that problem I hit on AMD64_LINUX where the static link gets trashed by this unnecessary indirection; as well as where I believe I have deliberately removed this unnecessary indirection in my SOLsun configuration files). (This is that simpler focused email I owe...) - Jay From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comDate: Sat, 21 Jun 2008 16:04:27 +0000Subject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! 4 (compiler switch) and 5 (adapt your code) are easy enough, though 4 I have *possible* misgivings about. There is in fact an interface whose data flows like so: run the compiler it produces "startup" code (_m3main.o/_m3main.obj/_m3main.c) that startup code passes data to the runtime (RTLinker) I mucked around here to fix environment variables. The "problem" here is that compiler <=> runtime interfaces must be carefully dealt with..perhaps.I am not sure what our compatibility requires are. I don't think Modula-3 binaries are really deployed so far and wide, and old and new .dlls/.so mixed much. So probably this interface can be churned without much concern for what it was in the past. Perhaps. Whatever data flows around here should probably be a record that starts with a size and contains a "set of int" (ie: bitflags) for every field, or every field added after a certain point, and reserve enough room for there to be enough bit flags for a long time. This is a part of a path to "release to release binary compatibility". Or maybe the type fingerprints are it and there isn't really such "adaptivity" around types changing? In C and C++, it is common to runtime link where the types on either side are different, but where there is some little amount of ability to discover some aspects of the types and adapt. As stated, via a size at the start of a record and/or bitfields to indicate which fields are present. Of course, it is limited. You only ever "grow" types. You never delete or rearrange. At the very least, you need to be able to bootstrap from one version to the next.A new compiler has to work at least once against an old statically linked runtime. At the very most, new compilers have to output binaries that work with old dynamically linked runtimes. I doubt this works much really but I am curious as to everyone else's opionions and assertions. Rather than set them to nil, what about typecasing them and then replacing with a non-nil instance that ignores writes? That will save you unhandled exceptions, right? Eventually I could/would probably just sit down and solve this but I haven't had much time and have been working on other Modula-3 things -- bringing up existing/new platforms (I uploaded SOLsun archives recently, still trying to bring up gcc on Solaris (not even SOLgnu, just gcc), and lots more on the radar..), debugging the 64 bit hosted cm3cg bug(s), etc. The quake code you propose sounds trivial, yes.But lately I think more should be in cm3 and less in quake (or sh or Python).Very gradually I am folding my Python into quake and my quake into cm3. Esp. as it proves stable and useful.For example, cm3 now reveals its own platform to Quake (HOST_PLATFORM), so Quake can default to a native build, without the user telling it or it sniffing around. All the use of uname et. al. can probably go away. (see also gcc's various -print-foo switches, that let wrappers introspect about gcc already knows about the target; cm3 could perhaps use similar) My Python wrappers accept a target platform name anywhere on the command line. cm3 should probably just do that. My Quake sniffs around for a config file based on platform, next to itself or in the source tree. Cm3 should probably just do that, esp. next to itself, less clear about in the source tree. It is kind of reasonable to go around implementing things multiple times, as the initial implementations serve as prototypes to try on for size, see if they work out well. The whole mechanism where "packages" are discovered by groveling the source tree could/should probably be merged into cm3, perhaps driven by a hand authored file or files, either like Randy did for Win32, or a more hierarchical tree full of small files linking together directories, like the Windows DDK "dirs" files. - Jay Date: Sat, 21 Jun 2008 11:41:09 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] proposal for dealing with lazy console--please review and comment! Thanks Rodney and Jay for your comments. Here are a few points I'd like to add to this discussion. 1. I agree with Jay that command line arguments would be better than environment variables. 2. I agree with Rodney that the "laziness property" must be set before data gets read/written and that it should be set only once, not changed during execution. 3. A drawback to using command-line variables (and env vars) is that it shifts the responsibility from the programmer to the user. IMO, this type of behavior is something that is "designed" and documented as part of the program, so it should not be changeable by the user. For example, if the user fails to put the appropriate parameter on the command-line, the program's behavior changes. In effect, this is sort of what has happened to me, that is, the behavior of my cm3 v4.1 gui-mode program(s) has changed from its design because the underlying implementation changed to use lazy console allocation and I have no way of getting the old behavior back without changing the implementation. 4. Perhaps a better approach would be to devise a new option for the compiler. For example, "-gui" works as now and uses lazy console allocation. "-gui_no_lazy" works the way -gui did in 4.1 where the Stdio.stdin/stderr/stdout would be NIL for a gui-mode program. The problem here is I'm not sure exactly how to implement it. In effect, use of this option would mean we would need to swap (i.e., choose) the implementation of Process.m3 at compile time, OR we would need some way to ensure the Stdio variables get set to NIL after the current Process.m3 initialization (thereby undoing the lazy allocation). Maybe one of these methods can be done via quake somehow, but I'm not sure how to go about it. Any ideas? 5. If I'm the only person having this issue with the lazy allocation, perhaps I can adapt my programs. Perhaps I can just set the Stdio variables to be NIL at the beginning of my mainline code for programs I know should be compiled as -gui. This brings to mind an idea for how to implement -gui_no_lazy. Do you think we could write some quake code that causes a new module implementation to be included in the program whenever the target is NT386 AND the -gui_no_lazy option is set? This new implementation would import from Stdio and all it would do is set the Stdio vars to be NIL. Since it imports from Stdio and Stdio imports Process, I would tend to think that Process and Stdio module initializations would be run before this new module initialization thereby ensuring the lazy allocated consoles get set to NIL. What do you think? Regards, Randy>>> "rodney.bates" 6/21/2008 10:18 AM >>>I guess I am on a somewhat different wavelength on this. I doagree that a complete set of queries by the application shouldbe supported, concerning lazy allocated streams. But to me,applications need to have either very little or nothing in theway of ability to change behaviour.For one thing, it makes sense for the lazy property to applyonly to stdout/stderr, on win32 platforms, compiled as -gui.This is why I was questioning getting a stream from FileWr.Open,and then setting it lazy. Laziness doesn't make any sense ona disk file.Beyond that, I think at the most, an application should be able to change the laziness property only before any data has beenwritten to the stream. After that, the window is already popped,and the semantics would get ugly.In fact, I am very skeptical about the need for an application to change laziness at all. If it can query this property, thenit can just refrain from writing to the steam, if it doesn't wantthe window to pop up.Hence my objection to making the properties variables, not becauseof general principal, but because an application could assign tothem at any time.>===== Original Message From Jay =====>set CM3_ConsoleBehavior=4.1>m3guiapp>console behavior still changed>>m3guiapp @M3ConsoleBehavior=4.1>console behavior back to "default"> - Jay>Rodney BatesRetired assistant professorComputer Science -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Jun 23 20:10:15 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 23 Jun 2008 14:10:15 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080621041535.A19F910D425E@birch.elegosoft.com> Message-ID: <485FAEC0.1E75.00D7.1@scires.com> Hi Henning: Not sure about any "good style rules" here. I am not aware of breaking any rules. PDF is a fairly universal format. These PDF documents provide the user's guide for the CM3-IDE package. The PDF files were created by printing a Microsoft Word document to the free pdf995 driver from Software995.com. I have provided the original Microsoft Word .DOC file in the repository as well, so if anyone wants to convert to a different format, you have the original source. Regards, Randy >>> Henning Thielemann 6/22/2008 4:34 PM >>> On Sat, 21 Jun 2008, Randy Coleburn wrote: > CVSROOT:/usr/cvs > Changes by:rcoleburn at birch.08/06/21 06:15:35 > > Added files: > cm3/doc/help/CM3_IDE/: basics.pdf beyond-basics.pdf > customization.pdf environment.pdf > index.html interface-index.pdf intro.pdf > more-info.pdf packages.pdf recipes.pdf > user-guide.pdf I thought it is not good style to put machine generated files, and especially binary files, to CVS repositories. Are the PDF files made from TeX? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Jun 23 21:01:58 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 23 Jun 2008 21:01:58 +0200 (CEST) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <485FAEC0.1E75.00D7.1@scires.com> References: <20080621041535.A19F910D425E@birch.elegosoft.com> <485FAEC0.1E75.00D7.1@scires.com> Message-ID: On Mon, 23 Jun 2008, Randy Coleburn wrote: > The PDF files were created by printing a Microsoft Word document to the > free pdf995 driver from Software995.com. > > I have provided the original Microsoft Word .DOC file in the repository I see. Then there is certainly no better way. From dragisha at m3w.org Fri Jun 27 15:59:15 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Jun 2008 15:59:15 +0200 Subject: [M3devel] LongSqrt.Sqrt... Message-ID: <1214575155.32091.3.camel@faramir.m3w.org> does not work for LINUXLIBC6... Or I am just missing some voodoo precondition? :) TIA -- Dragi?a Duri?