From hendrik at topoi.pooq.com Sun Dec 1 01:16:21 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 Nov 2013 19:16:21 -0500 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529A43B3.2090803@lcwb.coop> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> <20131130172906.GA28372@topoi.pooq.com> <529A43B3.2090803@lcwb.coop> Message-ID: <20131201001621.GA2374@topoi.pooq.com> On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: > > > On 11/30/2013 11:29 AM, Hendrik Boom wrote: > >On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: > >>Another devilish detail to be aware of: UTF-16 is _not_ the same as > >>the current Modula-3 16-bit WIDECHAR, even when restricted to values > >><= 16_FFFF. Current Wr/Rd library code just writes/reads > >>exactly 16 bits in two bytes, with whatever code point is in the > >>WIDECHAR variable. > >> > >>In contrast, UTF-16 will encode code points greater than > >>UFFFF as a pair of 16-bit code units with surrogate values in them. > >>Then to make this work right, the surrogate values are not > >>allowed in unencoded variables. So attempting to encode a surrogate > >>in UTF-16 is an error, and decoding a surrogate that is not part of a > >>proper first-surrogate/second-surrogate pair is "ill formed" and usually > >>decodes to UFFFD. > >> > >>You could get by with treating these as interchangeable only be being > >>careful to ensure there is never either a surrogate code nor a code > >>point > UFFFF, in either input or output. > >> > >>Also, current Wr/Rd always write/read only in little-endian byte order, > >>whereas there are both little- and big-endian variants of UTF-16. > >>I have no idea which endianness of UTF-16 is used by various GUI > >>libraries, but it would have to be little for this to work. > > > >It lools as if one might as well use UTF-8 if one is going to consider UTF-16. > > Hmm. Actually, *if* one could live with the restrictions on values above, > passing the same strings back and forth, with the GUI considering them UTF-16LE > and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have > the advantage that the M3 app code could deal naturally in characters, rather > than varying numbers of fragments of characters. UTF-8 would require > the latter. And then we just wait for the potential user who can't, and we'll have this discussion all over again. With the disadvantage that we'll end up having to put still more mechanisms for handling text everywhere. -- hendrik > > > > > >I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). > >and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have > >been superseded by SCIM, I don't know the status of uim, except that > >it has a uim bridge. > > > >It does look as if SCIM > >(http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended > >as a simple way to interface to many other input methods, such as XIM. > >It may be worth a look. > > > >--- hendrik > > > > > From jay.krell at cornell.edu Sun Dec 1 03:01:14 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 1 Dec 2013 02:01:14 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131201001621.GA2374@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com>, , <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org>, <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org>, <529A17DC.3080906@lcwb.coop>, <20131130172906.GA28372@topoi.pooq.com>, <529A43B3.2090803@lcwb.coop>, <20131201001621.GA2374@topoi.pooq.com> Message-ID: Windows is localized to and runs well with very many languages, using 16bit WCHAR.. - Jay > Date: Sat, 30 Nov 2013 19:16:21 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: > > > > > > On 11/30/2013 11:29 AM, Hendrik Boom wrote: > > >On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: > > >>Another devilish detail to be aware of: UTF-16 is _not_ the same as > > >>the current Modula-3 16-bit WIDECHAR, even when restricted to values > > >><= 16_FFFF. Current Wr/Rd library code just writes/reads > > >>exactly 16 bits in two bytes, with whatever code point is in the > > >>WIDECHAR variable. > > >> > > >>In contrast, UTF-16 will encode code points greater than > > >>UFFFF as a pair of 16-bit code units with surrogate values in them. > > >>Then to make this work right, the surrogate values are not > > >>allowed in unencoded variables. So attempting to encode a surrogate > > >>in UTF-16 is an error, and decoding a surrogate that is not part of a > > >>proper first-surrogate/second-surrogate pair is "ill formed" and usually > > >>decodes to UFFFD. > > >> > > >>You could get by with treating these as interchangeable only be being > > >>careful to ensure there is never either a surrogate code nor a code > > >>point > UFFFF, in either input or output. > > >> > > >>Also, current Wr/Rd always write/read only in little-endian byte order, > > >>whereas there are both little- and big-endian variants of UTF-16. > > >>I have no idea which endianness of UTF-16 is used by various GUI > > >>libraries, but it would have to be little for this to work. > > > > > >It lools as if one might as well use UTF-8 if one is going to consider UTF-16. > > > > Hmm. Actually, *if* one could live with the restrictions on values above, > > passing the same strings back and forth, with the GUI considering them UTF-16LE > > and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have > > the advantage that the M3 app code could deal naturally in characters, rather > > than varying numbers of fragments of characters. UTF-8 would require > > the latter. > > And then we just wait for the potential user who can't, and we'll have > this discussion all over again. > > With the disadvantage that we'll end up having to put still more > mechanisms for handling text everywhere. > > -- hendrik > > > > > > > > > > > >I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). > > >and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have > > >been superseded by SCIM, I don't know the status of uim, except that > > >it has a uim bridge. > > > > > >It does look as if SCIM > > >(http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended > > >as a simple way to interface to many other input methods, such as XIM. > > >It may be worth a look. > > > > > >--- hendrik > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sun Dec 1 09:47:37 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sun, 01 Dec 2013 08:47:37 +0000 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529A1A26.6010007@lcwb.coop> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> Message-ID: <529AF7A9.4090700@elstel.org> Am 30.11.2013 17:02, schrieb Rodney M. Bates: > > The en/decoders are available in one-code-point-per-call forms, as well > as in filters that are semantically almost identical to Wr and Rd, which > work on whole streams, with a constant encoding. The latter, in front of > TextWr/TextRd would probably make it easy to interface to any GUI library > that uses in-memory UTF-8, etc. > > It also would not be hard to make these work with 16-bit WIDECHAR, with > any input coded beyond UFFFF converted to the standard Unicode > replacement > UFFFD. It sounds like you would be unlikely to use such values. Yes, for that project I just need letters up to 0xFFFF i.e. latin-1 and -7. Currently I have copied a keyboard translation into /usr/share/X11/xkb/symbols/ that will give me greek chracters on [AltGr][Letter]. Nonetheless the current Windows implementation of the simulator suffices without such a trick because it can intercept the [AltGr] keystrokes. I have not evaluated yet whether the current VBT input form would allow a similar mechanism. > > How soon do you need to start? It would be good if that was available until January so that I can approach to finish my work until February. Fortunately there is some work which I could do in advance at least if the interfaces should not change radically. At least I should have some result at the beginning of March. Thanks for your effort, Elmar From dragisha at m3w.org Sun Dec 1 17:40:26 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Dec 2013 17:40:26 +0100 Subject: [M3devel] UTF-16: Greek alphabet with CM3 In-Reply-To: References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com>, , <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org>, <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org>, <529A17DC.3080906@lcwb.coop>, <20131130172906.GA28372@topoi.pooq.com>, <529A43B3.2090803@lcwb.coop>, <20131201001621.GA2374@topoi.pooq.com> Message-ID: And is only alive operating system, apart from Windows Phone OS (?), doing it with 16bit WCHAR? On 01 Dec 2013, at 03:01, Jay K wrote: > Windows is localized to and runs well with very many languages, using 16bit WCHAR.. > > - Jay > > > > Date: Sat, 30 Nov 2013 19:16:21 -0500 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > > > On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: > > > > > > > > > On 11/30/2013 11:29 AM, Hendrik Boom wrote: > > > >On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: > > > >>Another devilish detail to be aware of: UTF-16 is _not_ the same as > > > >>the current Modula-3 16-bit WIDECHAR, even when restricted to values > > > >><= 16_FFFF. Current Wr/Rd library code just writes/reads > > > >>exactly 16 bits in two bytes, with whatever code point is in the > > > >>WIDECHAR variable. > > > >> > > > >>In contrast, UTF-16 will encode code points greater than > > > >>UFFFF as a pair of 16-bit code units with surrogate values in them. > > > >>Then to make this work right, the surrogate values are not > > > >>allowed in unencoded variables. So attempting to encode a surrogate > > > >>in UTF-16 is an error, and decoding a surrogate that is not part of a > > > >>proper first-surrogate/second-surrogate pair is "ill formed" and usually > > > >>decodes to UFFFD. > > > >> > > > >>You could get by with treating these as interchangeable only be being > > > >>careful to ensure there is never either a surrogate code nor a code > > > >>point > UFFFF, in either input or output. > > > >> > > > >>Also, current Wr/Rd always write/read only in little-endian byte order, > > > >>whereas there are both little- and big-endian variants of UTF-16. > > > >>I have no idea which endianness of UTF-16 is used by various GUI > > > >>libraries, but it would have to be little for this to work. > > > > > > > >It lools as if one might as well use UTF-8 if one is going to consider UTF-16. > > > > > > Hmm. Actually, *if* one could live with the restrictions on values above, > > > passing the same strings back and forth, with the GUI considering them UTF-16LE > > > and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have > > > the advantage that the M3 app code could deal naturally in characters, rather > > > than varying numbers of fragments of characters. UTF-8 would require > > > the latter. > > > > And then we just wait for the potential user who can't, and we'll have > > this discussion all over again. > > > > With the disadvantage that we'll end up having to put still more > > mechanisms for handling text everywhere. > > > > -- hendrik > > > > > > > > > > > > > > > > > >I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). > > > >and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have > > > >been superseded by SCIM, I don't know the status of uim, except that > > > >it has a uim bridge. > > > > > > > >It does look as if SCIM > > > >(http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended > > > >as a simple way to interface to many other input methods, such as XIM. > > > >It may be worth a look. > > > > > > > >--- hendrik > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rodney_bates at lcwb.coop Sun Dec 1 19:01:21 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 01 Dec 2013 12:01:21 -0600 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131201001621.GA2374@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> <20131130172906.GA28372@topoi.pooq.com> <529A43B3.2090803@lcwb.coop> <20131201001621.GA2374@topoi.pooq.com> Message-ID: <529B7971.3080303@lcwb.coop> On 11/30/2013 06:16 PM, Hendrik Boom wrote: > On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: >> >> >> On 11/30/2013 11:29 AM, Hendrik Boom wrote: >>> On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: >>>> Another devilish detail to be aware of: UTF-16 is _not_ the same as >>>> the current Modula-3 16-bit WIDECHAR, even when restricted to values >>>> <= 16_FFFF. Current Wr/Rd library code just writes/reads >>>> exactly 16 bits in two bytes, with whatever code point is in the >>>> WIDECHAR variable. >>>> >>>> In contrast, UTF-16 will encode code points greater than >>>> UFFFF as a pair of 16-bit code units with surrogate values in them. >>>> Then to make this work right, the surrogate values are not >>>> allowed in unencoded variables. So attempting to encode a surrogate >>>> in UTF-16 is an error, and decoding a surrogate that is not part of a >>>> proper first-surrogate/second-surrogate pair is "ill formed" and usually >>>> decodes to UFFFD. >>>> >>>> You could get by with treating these as interchangeable only be being >>>> careful to ensure there is never either a surrogate code nor a code >>>> point > UFFFF, in either input or output. >>>> >>>> Also, current Wr/Rd always write/read only in little-endian byte order, >>>> whereas there are both little- and big-endian variants of UTF-16. >>>> I have no idea which endianness of UTF-16 is used by various GUI >>>> libraries, but it would have to be little for this to work. >>> >>> It lools as if one might as well use UTF-8 if one is going to consider UTF-16. >> >> Hmm. Actually, *if* one could live with the restrictions on values above, >> passing the same strings back and forth, with the GUI considering them UTF-16LE >> and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have >> the advantage that the M3 app code could deal naturally in characters, rather >> than varying numbers of fragments of characters. UTF-8 would require >> the latter. > > And then we just wait for the potential user who can't, and we'll have > this discussion all over again. > > With the disadvantage that we'll end up having to put still more > mechanisms for handling text everywhere. > > -- hendrik > > Yes, I agree completely, in general. I should have stated that, with that idea, I was thinking specifically of Elmar's problem. >> >> >>> >>> I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). >>> and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have >>> been superseded by SCIM, I don't know the status of uim, except that >>> it has a uim bridge. >>> >>> It does look as if SCIM >>> (http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended >>> as a simple way to interface to many other input methods, such as XIM. >>> It may be worth a look. >>> >>> --- hendrik >>> >>> >> > From dragisha at m3w.org Sun Dec 1 20:07:23 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Dec 2013 20:07:23 +0100 Subject: [M3devel] UTF-16: Greek alphabet with CM3 In-Reply-To: <20131201001621.GA2374@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> <20131130172906.GA28372@topoi.pooq.com> <529A43B3.2090803@lcwb.coop> <20131201001621.GA2374@topoi.pooq.com> Message-ID: <4326B57A-DEC7-4218-AC6C-BCEC4EE0CD59@m3w.org> Problem with Unicode is multiplied with a fact how most users never really dealt with international fonts. People are usually not so good at solving problems they never really felt. My mothers tongue, OTOH, is written in two scripts and Unicode is only way to cover all of it. All Western European languages and most European and near-European languages are covered with single ISO-8859-x 8-bit sets. My language needs two of these - ISO-8859-2 for Latin script, and and ISO-8859-5 for Cyrillic one. Also, I don?t think fixed bitwidth of characters is crucial, as we can cover all uses with good abstraction. Maybe like this one. (* (C) 2013 Dragi?a Duri?, dragisha at m3w.org *) INTERFACE UTF8; IMPORT RefSeq; (* UTF8.T is a subtype of TEXT, and it is also a UTF8 encoded Unicode string. *) TYPE Char = CARDINAL; T <: Public; Public = TEXT OBJECT METHODS init(t: TEXT): T; isValid(): BOOLEAN; (* so I can do all this without exceptions *) length(): CARDINAL; (* in glyphs *) byteSize(): CARDINAL; (* in CHARs/bytes *) empty(): BOOLEAN; (* shorter than ".length() = 0" *) (* hash(): Word.T; No need for this neither here nor at all. Text.Hash would be good enough, when I come to this. *) sub(start: CARDINAL; length: CARDINAL := LAST(CARDINAL)): T; getText(start: CARDINAL := 0; length: CARDINAL := LAST(CARDINAL)): TEXT; getChar(pos: CARDINAL): Char; setChars(VAR a: ARRAY OF Char); pos(pat: T; start: CARDINAL := 0): INTEGER; (* Uses Boyer-Moore [1] for fast search, Observations 1 & 2 are currently implemented. [1] Boyer, Robert S.; Moore, J Strother (October 1977). "A Fast String Searching Algorithm.". Comm. ACM (New York, NY, USA: Association for Computing Machinery) 20 (10): 762?772. *) findChar(ch: Char; start: CARDINAL := 0): INTEGER; findCharR(ch: Char; start: CARDINAL := LAST(CARDINAL)): INTEGER; (* findChar returns first position of ch to the right from start position, or start if ch is there. findCharR returns first position of ch to the left from start position, excluding start position. *) iterate(start: CARDINAL := 0; steps: CARDINAL := LAST(CARDINAL)): Iterator; END; (* All positional/count/length parameters for methods are in Unicode glyphs *) Iterator <: PublicIterator; PublicIterator = OBJECT METHODS next(VAR char: Char): BOOLEAN; (* TODO prev? *) END; (* Construction *) PROCEDURE New(t: TEXT): T; PROCEDURE Cat(u, t: T): T; PROCEDURE FromChars(READONLY chars: ARRAY OF Char): T; PROCEDURE FromCHARArray(VAR chars: ARRAY OF CHAR): T; (* Validation. Checks both NIL value, and invalid UTF8 string. *) PROCEDURE IsValid(t: T): BOOLEAN; (* Comparation/ordering *) PROCEDURE Equal(u, t: T): BOOLEAN; PROCEDURE Compare(t1, t2: T): [-1..1]; (* Future UTF8Ops, here for now: *) PROCEDURE EscapeS(t, s: T; escapeWith: CHAR := '\134'): T; PROCEDURE UnEscape(t: T; esc: CHAR := '\134'): T; PROCEDURE SplitS(t, s: T; skipSucc: BOOLEAN := TRUE): RefSeq.T; (* Treating escaped chars like normal ones. We need to define semantics for special treatment Fri Apr 19 12:00 2013: For now, I only implement skipSucc=TRUE case. *) PROCEDURE RemoveSpaces(t: T): T; PROCEDURE Caps(t: T): T; (* This is probably titlecase in Unicode-speak. CHECK. Also, see what happend with Lows() in case we treat titlecase *) PROCEDURE Lows(t: T): T; END UTF8. On 01 Dec 2013, at 01:16, Hendrik Boom wrote: > On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: >> >> >> On 11/30/2013 11:29 AM, Hendrik Boom wrote: >>> On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: >>>> Another devilish detail to be aware of: UTF-16 is _not_ the same as >>>> the current Modula-3 16-bit WIDECHAR, even when restricted to values >>>> <= 16_FFFF. Current Wr/Rd library code just writes/reads >>>> exactly 16 bits in two bytes, with whatever code point is in the >>>> WIDECHAR variable. >>>> >>>> In contrast, UTF-16 will encode code points greater than >>>> UFFFF as a pair of 16-bit code units with surrogate values in them. >>>> Then to make this work right, the surrogate values are not >>>> allowed in unencoded variables. So attempting to encode a surrogate >>>> in UTF-16 is an error, and decoding a surrogate that is not part of a >>>> proper first-surrogate/second-surrogate pair is "ill formed" and usually >>>> decodes to UFFFD. >>>> >>>> You could get by with treating these as interchangeable only be being >>>> careful to ensure there is never either a surrogate code nor a code >>>> point > UFFFF, in either input or output. >>>> >>>> Also, current Wr/Rd always write/read only in little-endian byte order, >>>> whereas there are both little- and big-endian variants of UTF-16. >>>> I have no idea which endianness of UTF-16 is used by various GUI >>>> libraries, but it would have to be little for this to work. >>> >>> It lools as if one might as well use UTF-8 if one is going to consider UTF-16. >> >> Hmm. Actually, *if* one could live with the restrictions on values above, >> passing the same strings back and forth, with the GUI considering them UTF-16LE >> and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have >> the advantage that the M3 app code could deal naturally in characters, rather >> than varying numbers of fragments of characters. UTF-8 would require >> the latter. > > And then we just wait for the potential user who can't, and we'll have > this discussion all over again. > > With the disadvantage that we'll end up having to put still more > mechanisms for handling text everywhere. > > -- hendrik > > >> >> >>> >>> I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). >>> and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have >>> been superseded by SCIM, I don't know the status of uim, except that >>> it has a uim bridge. >>> >>> It does look as if SCIM >>> (http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended >>> as a simple way to interface to many other input methods, such as XIM. >>> It may be worth a look. >>> >>> --- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From estellnb at elstel.org Sun Dec 1 20:26:21 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sun, 01 Dec 2013 19:26:21 +0000 Subject: [M3devel] VBT and up to date desktop styling Message-ID: <529B8D5D.9080306@elstel.org> As the VBT standard interface does only offer black and white user interface styling I would need to use vbtkit to achieve at least a Windows 3.1 similar user interface. However as I have found out some of the classes in vbtkit required just for the main menu have not been completed and do not compile yet. Would someone be ready to invest some time and affection to complete these classes? To make MainMenu.m3 look good at least the following tasks would have to be done: * AnchorSwitchVBT: to be completed, 3D reflection for the anchors of the popup menus in the main menu * ShadowedBarVBT: is here but does not seem to work: it should display a horizontal bar in one of the popup menus * ShadowVBT: to be completed: draw a 3D border around popup menus and other items * Shadow: have a third color besides background and foreground for the flat style: eliminate the white borders in non-hover mode * adjust the vbtkit menu so that the popup menus stays open if the mouse button is released; this will also be necessary to make sub-menus of popup-menus work; i.e. let popup menus contain AnchorSwitchVBTs * evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs shadows appear to be larger in their horizontal extent by now compared to their vertical extent which is not that good to look at * and likely some other issues I have not discovered yet Considering all of that if I will not have an extended vbtkit interfacing with another GUI component like GTK would likely be the way to go because otherwise there would simply be too much time to be invested into vbtkit not considering underlying Trestle problems like Unicode support yet. Though it would be good to have a well working standard GUI interface for Modula-3 we need to consider now if putting further work into Trestle/vbtkit is still worth to do. If so I believe it would require a joint effort. -------------- next part -------------- MODULE MainMenu EXPORTS Main; IMPORT TextVBT, RigidVBT, HVSplit, VBT, Split, Axis, Trestle, TrestleComm, Thread; IMPORT MenuSwitchVBT, (* AnchorSwitchVBT, *) AnchorBtnVBT, ButtonVBT; IMPORT Shadow, ShadowedFeedbackVBT, ShadowedBarVBT (*, ShadowVBT*), BorderedVBT; IMPORT Wr,Stdio; FROM VBTStyle IMPORT gray, black, blackongray, shadow; <*FATAL TrestleComm.Failure*> <*FATAL Wr.Failure*> <*FATAL Thread.Alerted*> TYPE MenuItemProc = PROCEDURE (v: MenuSwitch; READONLY cd: VBT.MouseRec); MenuSwitch = MenuSwitchVBT.T OBJECT callbackproc : MenuItemProc OVERRIDES callback := MenuSwitchCallbackWrapper; END; PROCEDURE MenuSwitchCallbackWrapper(v: MenuSwitch; READONLY cd:VBT.MouseRec) = BEGIN v.callbackproc(v,cd) END MenuSwitchCallbackWrapper; PROCEDURE AddMenuItem( menu: Split.T; item: TEXT; action: MenuItemProc ) = VAR feedback, menuswitch : VBT.T; BEGIN feedback := ShadowedFeedbackVBT.NewMenu( TextVBT.New( item, bgFg:=blackongray ), shadow ); menuswitch := NEW(MenuSwitch, callbackproc:= action).init(feedback); Split.AddChild(menu,menuswitch); END AddMenuItem; PROCEDURE AddHorizontalBar( menu: Split.T ) = BEGIN Split.AddChild(menu, NEW(ShadowedBarVBT.T).init( Axis.T.Hor, shadow, Shadow.Style.Chiseled ) ); END AddHorizontalBar; PROCEDURE AddSubMenu( menu: Split.T; item: TEXT; submenu: HVSplit.T ) = VAR feedback, anchorbutn : VBT.T; BEGIN feedback := NEW(ShadowedFeedbackVBT.T).init( ch:=TextVBT.New( item, bgFg:=blackongray ), shadow:=shadow, offStyle:=Shadow.Style.Flat, onStyle:=Shadow.Style.Lowered ,onExcitedStyle:=Shadow.Style.Lowered ); (* anchorbutn := AnchorBtnVBT.New( ch:=feedback, menu:= NEW(ShadowVBT.T, submenu, shadow, Shadow.Style.Raised ); *) anchorbutn := AnchorBtnVBT.New( ch:=feedback, menu:=BorderedVBT.New( submenu, 0.2, black ) ); Split.AddChild( menu, anchorbutn ); END AddSubMenu; VAR main, menu : VBT.T; VAR mainmenu, popup1, popup2, popup3 : Split.T; PROCEDURE Cut (<*UNUSED*>v: MenuSwitch; <*UNUSED*>READONLY cd: VBT.MouseRec) = BEGIN Wr.PutText(Stdio.stdout, "Cut\n"); Wr.Flush(Stdio.stdout); END Cut; PROCEDURE Paste (<*UNUSED*>v: MenuSwitch; <*UNUSED*>READONLY cd: VBT.MouseRec) = BEGIN Wr.PutText(Stdio.stdout, "Paste\n"); Wr.Flush(Stdio.stdout); END Paste; PROCEDURE Exit (<*UNUSED*>v: MenuSwitch; <*UNUSED*>READONLY cd: VBT.MouseRec) = BEGIN Trestle.Delete(main); END Exit; BEGIN popup1 := HVSplit.New(Axis.T.Ver); AddMenuItem(popup1, "Open", Cut); AddHorizontalBar(popup1); AddMenuItem(popup1, "Exit", Exit); popup3 := HVSplit.New(Axis.T.Ver); AddMenuItem(popup3, "SubCut", Cut); AddMenuItem(popup3, "SubPaste", Paste); (*popup2 := HVSplit.New(Axis.T.Ver); *) popup2 := HVSplit.New(Axis.T.Ver); AddMenuItem(popup2, "Cut", Cut); AddMenuItem(popup2, "Paste", Paste); AddSubMenu(popup2, "File", popup3); (* mainmenu := HVSplit.New(Axis.T.Hor); *) mainmenu := ButtonVBT.MenuBar( op:=gray ); AddSubMenu(mainmenu, "File", popup1); AddSubMenu(mainmenu, "Edit", popup2); AddMenuItem(mainmenu, "Exit", Exit); Split.AddChild(mainmenu,NEW(VBT.Leaf)); menu := mainmenu; main := HVSplit.Cons( Axis.T.Ver, menu, RigidVBT.FromHV( TextVBT.New("xxxxxx"), 100.0, 80.0 ) ); Trestle.Install(main); Trestle.AwaitDelete(main); END MainMenu. -------------- next part -------------- INTERFACE VBTStyle; IMPORT PaintOp, Shadow, Pixmap; VAR lgray, gray, dgray, black : PaintOp.T; blackongray : PaintOp.ColorQuad; shadow : Shadow.T; graytxt : Pixmap.T; END VBTStyle. -------------- next part -------------- MODULE VBTStyle; IMPORT PaintOp, Shadow; BEGIN lgray := PaintOp.FromRGB(0.9, 0.9, 0.9); gray := PaintOp.FromRGB(0.8, 0.8, 0.8); dgray := PaintOp.FromRGB(0.7, 0.7, 0.7); black := PaintOp.FromRGB(0.0, 0.0, 0.0); blackongray := PaintOp.MakeColorQuad( bg:= gray, fg:= black ); shadow := Shadow.New( size:= 1.0, light:= lgray, dark:= dgray ); END VBTStyle. From estellnb at elstel.org Sun Dec 1 20:37:28 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sun, 01 Dec 2013 19:37:28 +0000 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529B7CB3.2060602@lcwb.coop> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> <529B7CB3.2060602@lcwb.coop> Message-ID: <529B8FF8.4090708@elstel.org> Am 01.12.2013 18:15, schrieb Rodney M. Bates: > > > On 12/01/2013 02:47 AM, Elmar Stellnberger wrote: >> >> Am 30.11.2013 17:02, schrieb Rodney M. Bates: >>> >>> The en/decoders are available in one-code-point-per-call forms, as well >>> as in filters that are semantically almost identical to Wr and Rd, >>> which >>> work on whole streams, with a constant encoding. The latter, in >>> front of >>> TextWr/TextRd would probably make it easy to interface to any GUI >>> library >>> that uses in-memory UTF-8, etc. >>> >>> It also would not be hard to make these work with 16-bit WIDECHAR, with >>> any input coded beyond UFFFF converted to the standard Unicode >>> replacement >>> UFFFD. It sounds like you would be unlikely to use such values. >> Yes, for that project I just need letters up to 0xFFFF i.e. latin-1 >> and -7. >> Currently I have copied a keyboard translation into >> /usr/share/X11/xkb/symbols/ >> that will give me greek chracters on [AltGr][Letter]. Nonetheless the >> current >> Windows implementation of the simulator suffices without such a trick >> because >> it can intercept the [AltGr] keystrokes. I have not evaluated yet >> whether the >> current VBT input form would allow a similar mechanism. >>> >>> How soon do you need to start? >> It would be good if that was available until January so that I can >> approach to >> finish my work until February. Fortunately there is some work which I >> could >> do in advance at least if the interfaces should not change radically. >> At least >> I should have some result at the beginning of March. >> > > Enough of what the Unicode branch could do for you has been working > for some time. > The remaining problems are convenience/packaging things, testing of > big-endian and > mixed-endian pickles and network objects, and bootstrapping. I have > not rebootstrapped > using the release compiler in a couple of months, but I believe there > are some new > bootstrap barriers that have popped up. Also, the only backend that > is done is > the gcc-4.7-derived one, although I think that will cover the majority > of the targets. > What target are you using? AMD64_LINUX, LINUXLIBC6. However the program will need to work on windows as well. > > As for what GUI system to use, that is another question, but the > Unicode branch > would allow you to pass/receive strings in any of the encodings, yet > process > them in M3 code as simple characters, without having to mess with or > understand > the encodings. That should pretty well open up all your options on > what GUI > system to use. Also, it would make late changing to a different > encoding trivial. > Yes, I should likely check that branch out and compile it. However for the final program a stable version of it will be absolutely necessary. Then I will also have to decide whether I can use Trestle/vbtkit or whether I should try to convert a current GTK with swig. Elmar From dragisha at m3w.org Sun Dec 1 21:53:03 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Dec 2013 21:53:03 +0100 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529B8FF8.4090708@elstel.org> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> <529B7CB3.2060602@lcwb.coop> <529B8FF8.4090708@elstel.org> Message-ID: <4DAB8C65-061E-4AF0-B685-53B47B2572D0@m3w.org> Before you start with swig, take a look at this: https://dl.dropboxusercontent.com/u/60554338/m3-m3gtk2-r11929.tar.gz As usual? I do not have a time for legalese, if there is a question about licensing, it is cm3-alike. I would like to know if it's used/useful, but I give no warranty of any kind, and so on :). dd On 01 Dec 2013, at 20:37, Elmar Stellnberger wrote: > Then I will also have to decide whether I can use Trestle/vbtkit or whether I should try to > convert a current GTK with swig. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hendrik at topoi.pooq.com Sun Dec 1 23:50:30 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 1 Dec 2013 17:50:30 -0500 Subject: [M3devel] VBT and up to date desktop styling In-Reply-To: <529B8D5D.9080306@elstel.org> References: <529B8D5D.9080306@elstel.org> Message-ID: <20131201225029.GA24450@topoi.pooq.com> On Sun, Dec 01, 2013 at 07:26:21PM +0000, Elmar Stellnberger wrote: > > Considering all of that if I will not have an extended vbtkit > interfacing with another GUI component like GTK would likely be the > way to go because otherwise there would simply be too much time to > be invested into vbtkit not considering underlying Trestle problems > like Unicode support yet. Though it would be good to have a well > working standard GUI interface for Modula-3 we need to consider now > if putting further work into Trestle/vbtkit is still worth to do. If > so I believe it would require a joint effort. On the face of it, switching to a portable, language-independent user-interface library may be the way to go in the long run. I don't see any reason why the use of Modula 3 should require a different user interface library from the rest of the world, unless, of course the other libraries are crucially unsuitable or have unportable interfaces. In the dark ages, Modula-3 ended up with its own UI library because all UI libraries were hopelessly OS-specific. Yuo even had to rewrite your code for different versios of an OS. There *are* now some portable user-interface libraries. Aren't GTK and Qt candidates for this? Tough I'm not sure just how portable these are. The trouble with these are that they seem to keep coming up with new, incompatible versions, so maintaining the interfaces and client software might be a neverending activity. But there seems to be substantial transition periods between, say, GTK2 and GTK3 when both are available, so that may noot be too terrible. Has anyone done anything towards GTK or Qt bindings for Modula 3? -- hendrik From dmuysers at hotmail.com Sun Dec 1 23:56:18 2013 From: dmuysers at hotmail.com (dirk muysers) Date: Sun, 1 Dec 2013 23:56:18 +0100 Subject: [M3devel] VBT and up to date desktop styling In-Reply-To: <20131201225029.GA24450@topoi.pooq.com> References: <529B8D5D.9080306@elstel.org> <20131201225029.GA24450@topoi.pooq.com> Message-ID: IUP (http://www.tecgraf.puc-rio.br/iup/) is the easiest to interface to from a Modula-3 point of view. -----Original Message----- From: Hendrik Boom Sent: Sunday, December 01, 2013 11:50 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] VBT and up to date desktop styling On Sun, Dec 01, 2013 at 07:26:21PM +0000, Elmar Stellnberger wrote: > > Considering all of that if I will not have an extended vbtkit > interfacing with another GUI component like GTK would likely be the > way to go because otherwise there would simply be too much time to > be invested into vbtkit not considering underlying Trestle problems > like Unicode support yet. Though it would be good to have a well > working standard GUI interface for Modula-3 we need to consider now > if putting further work into Trestle/vbtkit is still worth to do. If > so I believe it would require a joint effort. On the face of it, switching to a portable, language-independent user-interface library may be the way to go in the long run. I don't see any reason why the use of Modula 3 should require a different user interface library from the rest of the world, unless, of course the other libraries are crucially unsuitable or have unportable interfaces. In the dark ages, Modula-3 ended up with its own UI library because all UI libraries were hopelessly OS-specific. Yuo even had to rewrite your code for different versios of an OS. There *are* now some portable user-interface libraries. Aren't GTK and Qt candidates for this? Tough I'm not sure just how portable these are. The trouble with these are that they seem to keep coming up with new, incompatible versions, so maintaining the interfaces and client software might be a neverending activity. But there seems to be substantial transition periods between, say, GTK2 and GTK3 when both are available, so that may noot be too terrible. Has anyone done anything towards GTK or Qt bindings for Modula 3? -- hendrik From dabenavidesd at yahoo.es Mon Dec 2 00:19:32 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 1 Dec 2013 23:19:32 +0000 (GMT) Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529AF7A9.4090700@elstel.org> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> Message-ID: <1385939972.4774.YahooMailNeo@web171902.mail.ir2.yahoo.com> Hi all: another turn around solution for this is to use the qt port developed by by Peter Mckinna. I'm interested in the event Model and signal and slot system, perhaps Peter can guide us through where it is now and where it should be. This will give us free access menu and buttons style in either Win or U*ix platforms. Personally I will base my further developments In Qt, trestle is a small toolkit developed by super minds, but honestly we don't have too much of a parallel system to gain much of its features. Thanks in advance El Domingo 1 de diciembre de 2013 3:47, Elmar Stellnberger escribi?: Am 30.11.2013 17:02, schrieb Rodney M. Bates: > > The en/decoders are available in one-code-point-per-call forms, as well > as in filters that are semantically almost identical to Wr and Rd, which > work on whole streams, with a constant encoding.? The latter, in front of > TextWr/TextRd would probably make it easy to interface to any GUI library > that uses in-memory UTF-8, etc. > > It also would not be hard to make these work with 16-bit WIDECHAR, with > any input coded beyond UFFFF converted to the standard Unicode > replacement > UFFFD.? It sounds like you would be unlikely to use such values. Yes, for that project I just need letters up to 0xFFFF i.e. latin-1 and -7. Currently I have copied a keyboard translation into /usr/share/X11/xkb/symbols/ that will give me greek chracters on [AltGr][Letter]. Nonetheless the current Windows implementation of the simulator suffices without such a trick because it can intercept the [AltGr] keystrokes. I have not evaluated yet whether the current VBT input form would allow a similar mechanism. > > How soon do you need to start? It would be good if that was available until January so that I can approach to finish my work until February. Fortunately there is some work which I could do in advance at least if the interfaces should not change radically. At least I should have some result at the beginning of March. Thanks for your effort, Elmar -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Dec 2 01:19:20 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 1 Dec 2013 19:19:20 -0500 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <1385939972.4774.YahooMailNeo@web171902.mail.ir2.yahoo.com> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> <1385939972.4774.YahooMailNeo@web171902.mail.ir2.yahoo.com> Message-ID: <20131202001920.GA25527@topoi.pooq.com> On Sun, Dec 01, 2013 at 11:19:32PM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > another turn around solution for this is to use the qt port developed > by by Peter Mckinna. I'm interested in the event Model and signal and > slot system, perhaps Peter can guide us through where it is now and > where it should be. This will give us free access menu and buttons > style in either Win or U*ix platforms. So Qt is now portable between OS's? Does it cover Mac, too? > Personally I will base my > further developments > In Qt, trestle is a small toolkit developed by > Not sure what you mean by trestle in Qt. super minds, but honestly we don't have too much of a parallel system A parallel system? > to gain much of its features. -- hendrik k From jay.krell at cornell.edu Sun Dec 1 21:33:53 2013 From: jay.krell at cornell.edu (Jay) Date: Sun, 1 Dec 2013 12:33:53 -0800 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: References: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> Message-ID: <1AB94F78-FE03-43D6-8F56-D6974C480E92@gmail.com> A lot of code within Windows uses WCHAR all the time. The kernel interfaces all accept only WCHAR (and a 16 bit length of bytes). FAT32, NTFS, registry all store 16bit WCHAR, at least when 7bits don't suffice. Trestle surely will remain with Xlib & Win32. New code...Qt? - Jay On Nov 30, 2013, at 2:52 AM, Dragi?a Duri? wrote: > And yes, Cairo uses UTF-8 natively, even on Windows. > > On 30 Nov 2013, at 11:41, Dragi?a Duri? wrote: > >> Are we really sure about this Xlib interfacing? >> >> There are several very-low-level and very-portable libraries right now. Why don?t we use Cairo? >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 30 Nov 2013, at 10:06, Jay K wrote: >> >>> 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? >>> 2) Are we really certain that redefining WIDECHAR is the way to go? >>> Not, say, introduce a new time, CHAR32 or UCHAR32? >>> And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? >>> >>> Or do people now advocate: >>> get rid of WIDECHAR >>> leave 8 bit CHAR >>> with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? >>> ?? >>> >>> Thank you, >>> - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 1 23:35:50 2013 From: jay.krell at cornell.edu (Jay) Date: Sun, 1 Dec 2013 14:35:50 -0800 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: <1AB94F78-FE03-43D6-8F56-D6974C480E92@gmail.com> References: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> <1AB94F78-FE03-43D6-8F56-D6974C480E92@gmail.com> Message-ID: <5D37F47A-AF27-47F6-95F6-9C91C26A076E@gmail.com> Sorry sent too soon. Windows is basically WCHAR everywhere except at boundaries that must accept multiple encodings... - Jay On Dec 1, 2013, at 12:33 PM, Jay wrote: > A lot of code within Windows uses WCHAR all the time. The kernel interfaces all accept only WCHAR (and a 16 bit length of bytes). FAT32, NTFS, registry all store 16bit WCHAR, at least when 7bits don't suffice. > > > Trestle surely will remain with Xlib & Win32. New code...Qt? > > > - Jay > > On Nov 30, 2013, at 2:52 AM, Dragi?a Duri? wrote: > >> And yes, Cairo uses UTF-8 natively, even on Windows. >> >> On 30 Nov 2013, at 11:41, Dragi?a Duri? wrote: >> >>> Are we really sure about this Xlib interfacing? >>> >>> There are several very-low-level and very-portable libraries right now. Why don?t we use Cairo? >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 30 Nov 2013, at 10:06, Jay K wrote: >>> >>>> 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? >>>> 2) Are we really certain that redefining WIDECHAR is the way to go? >>>> Not, say, introduce a new time, CHAR32 or UCHAR32? >>>> And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? >>>> >>>> Or do people now advocate: >>>> get rid of WIDECHAR >>>> leave 8 bit CHAR >>>> with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? >>>> ?? >>>> >>>> Thank you, >>>> - Jay >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 2 04:00:13 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 2 Dec 2013 03:00:13 +0000 (GMT) Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131202001920.GA25527@topoi.pooq.com> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> <1385939972.4774.YahooMailNeo@web171902.mail.ir2.yahoo.com> <20131202001920.GA25527@topoi.pooq.com> Message-ID: <1385953213.62458.YahooMailNeo@web171906.mail.ir2.yahoo.com> Hi all: Yes, mostly portable, since long ago in Mac, I'm not sure in OS/2. I think I miss wrote, I myself will base further development In Qt, though I'm not saying Tresstle is a bad toolkit, it just not fully exploited in current systems, read that as hardware and or software, is just that. Thanks in advance El Domingo 1 de diciembre de 2013 19:19, Hendrik Boom escribi?: On Sun, Dec 01, 2013 at 11:19:32PM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > another turn around solution for this is to use the qt port developed > by by Peter Mckinna. I'm interested in the event Model and signal and > slot system, perhaps Peter can guide us through where it is now and > where it should be. This will give us free access menu and buttons > style in either Win or U*ix platforms. So Qt is now portable between OS's?? Does it cover Mac, too? > Personally I will base my > further developments > In Qt, trestle is a small toolkit developed by > Not sure what you mean by trestle in Qt. super minds, but honestly we don't have too much of a parallel system A parallel system? > to gain much of its features. -- hendrik k -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 3 22:54:27 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Dec 2013 21:54:27 +0000 Subject: [M3devel] unicode in libm3 or separate package In-Reply-To: <20131203211338.B4C655DF608@birch.elegosoft.com> References: <20131203211338.B4C655DF608@birch.elegosoft.com> Message-ID: This is not necessary, but it is ok. m3core and libm3 are never built with an older compiler and can depend on a newer compiler. - Jay > Date: Tue, 3 Dec 2013 22:13:38 +0000 > To: m3commit at elegosoft.com > From: rodney at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/12/03 22:13:38 > > Modified files: > cm3/m3-libs/libm3/src/rw/: Tag: devel_unicode m3makefile > > Log message: > Move Unicode codec stuff to its own package. This allows for > bootstrapping the unicode branch with release and head compilers. > This code depends on being compiled with Unicode-sized WIDECHAR, > which is not initially available when first compiling libm3 and > the compiler, using an earlier compiler. New package libunicode > can now be compiled later, after a new compiler is installed. > > script do-cm3-unicode.sh does everything do-cm3-front.sh does, > plus libunicode. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 4 01:56:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Dec 2013 00:56:33 +0000 Subject: [M3devel] unicode in libm3 or separate package In-Reply-To: <3EDF0150-6846-4FA6-9698-5D41E3208A59@purdue.edu> References: <20131203211338.B4C655DF608@birch.elegosoft.com> , <3EDF0150-6846-4FA6-9698-5D41E3208A59@purdue.edu> Message-ID: Huh? No they aren't. bootstrapping uses old compiler to build everything after m3core/libm3 (up to cm3) bootstrapping uses old compiler to m3front/m3back/m3quake/m3linker/cm3/sysutils, but not m3core/libm3. Then bootstrapping uses new compiler to build everything. m3core/libm3 can depend on new compiler. m3front/m3back/m3quake/m3linker/cm3/sysutils cannot (except by more than one step, then they can -- "flexibility via multiple changes") see http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/upgrade.sh?rev=1.37;content-type=text%2Fplain notice where m3core/libm3 appear. which I don't use but is possibly clearer to people and what I use was based on it (I missed that upgrade.sh actually builds everything and mine stops at cm3). - Jay Subject: Re: [M3devel] unicode in libm3 or separate package From: hosking at purdue.edu Date: Tue, 3 Dec 2013 19:13:46 -0500 CC: m3devel at elegosoft.com; rodney.bates at wichita.edu To: jay.krell at cornell.edu Huh? They are when bootstrapping. Sent from my iPhone On 3 Dec 2013, at 4:54 pm, Jay K wrote: This is not necessary, but it is ok. m3core and libm3 are never built with an older compiler and can depend on a newer compiler. - Jay > Date: Tue, 3 Dec 2013 22:13:38 +0000 > To: m3commit at elegosoft.com > From: rodney at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/12/03 22:13:38 > > Modified files: > cm3/m3-libs/libm3/src/rw/: Tag: devel_unicode m3makefile > > Log message: > Move Unicode codec stuff to its own package. This allows for > bootstrapping the unicode branch with release and head compilers. > This code depends on being compiled with Unicode-sized WIDECHAR, > which is not initially available when first compiling libm3 and > the compiler, using an earlier compiler. New package libunicode > can now be compiled later, after a new compiler is installed. > > script do-cm3-unicode.sh does everything do-cm3-front.sh does, > plus libunicode. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Wed Dec 4 04:10:03 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 4 Dec 2013 03:10:03 +0000 Subject: [M3devel] VBT and up to date desktop styling Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> Elmar: Years ago, I worked with the principals at Critical Mass to make some Trestle/VBT/VBTKit changes that would make the "look and feel" more Windows-like. I'm pretty sure I passed all these to Olaf for incorporation into the CVS repository. I developed some GUIs that looked decent at the time on Windows NT, but more work could be done to provide tighter integration. Not sure if these pics will come thru in the email, but I've pasted a few below to give you some idea of what we achieved using Trestle, VBTKit, FormsVBT, etc. Of course, at that time, our primary motivation was to have one set of GUI code that worked on multiple platforms and gave same look and feel, so tight integration with the underlying OS was not the driving concern. Our code ran well and provided same look and feel on both HP-UX and Windows. [cid:image002.jpg at 01CEF074.68ECE030] [cid:image006.png at 01CEF073.CD228560] [cid:image007.png at 01CEF072.F125B000] [cid:image003.jpg at 01CEF074.68ECE030] Thanks, Randy Coleburn -----Original Message----- From: Elmar Stellnberger [mailto:estellnb at elstel.org] Sent: Sunday, December 01, 2013 2:26 PM To: m3devel Subject: EXT:[M3devel] VBT and up to date desktop styling As the VBT standard interface does only offer black and white user interface styling I would need to use vbtkit to achieve at least a Windows 3.1 similar user interface. However as I have found out some of the classes in vbtkit required just for the main menu have not been completed and do not compile yet. Would someone be ready to invest some time and affection to complete these classes? To make MainMenu.m3 look good at least the following tasks would have to be done: * AnchorSwitchVBT: to be completed, 3D reflection for the anchors of the popup menus in the main menu * ShadowedBarVBT: is here but does not seem to work: it should display a horizontal bar in one of the popup menus * ShadowVBT: to be completed: draw a 3D border around popup menus and other items * Shadow: have a third color besides background and foreground for the flat style: eliminate the white borders in non-hover mode * adjust the vbtkit menu so that the popup menus stays open if the mouse button is released; this will also be necessary to make sub-menus of popup-menus work; i.e. let popup menus contain AnchorSwitchVBTs * evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs shadows appear to be larger in their horizontal extent by now compared to their vertical extent which is not that good to look at * and likely some other issues I have not discovered yet Considering all of that if I will not have an extended vbtkit interfacing with another GUI component like GTK would likely be the way to go because otherwise there would simply be too much time to be invested into vbtkit not considering underlying Trestle problems like Unicode support yet. Though it would be good to have a well working standard GUI interface for Modula-3 we need to consider now if putting further work into Trestle/vbtkit is still worth to do. If so I believe it would require a joint effort. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 51415 bytes Desc: image007.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 47526 bytes Desc: image006.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 57950 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 106584 bytes Desc: image003.jpg URL: From jay.krell at cornell.edu Wed Dec 4 18:52:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Dec 2013 17:52:57 +0000 Subject: [M3devel] VBT and up to date desktop styling In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Randy, definitely at least some of your changes got in. For example, see: https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-ui/vbtkit/src/lego/WIN32/ The changes involved forking large files to make small changes, and apparent bugs resulted as the files drifted apart. There are Qt bindings in the tree now. I haven't tried them yet. Qt is probably the way to go. The challenge in all this is coming up with the right abstraction or adopting the correct existing abstraction. In the language we have a "record". This turns out to be very portable. All processors and intermediate representations support it, or will be force of existing practise throughout the software industry (i.e. C has structs, therefore structs and anything resembling them shall always work efficiently). Then, what is the right abstraction for a GUI library? What will always be "easy enough" to implement on hardware or on top of other libraries? And, how far down do we implement and meet the next layer? Is the next layer a video buffer? Or a high level library? Or generating html for "complete reinterpretation"? A thin stateless wrapper where someone else does 99.9% of the work? And then implementing our part of it. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Wed, 4 Dec 2013 03:10:03 +0000 Subject: Re: [M3devel] VBT and up to date desktop styling Elmar: Years ago, I worked with the principals at Critical Mass to make some Trestle/VBT/VBTKit changes that would make the ?look and feel? more Windows-like. I'm pretty sure I passed all these to Olaf for incorporation into the CVS repository. I developed some GUIs that looked decent at the time on Windows NT, but more work could be done to provide tighter integration. Not sure if these pics will come thru in the email, but I've pasted a few below to give you some idea of what we achieved using Trestle, VBTKit, FormsVBT, etc. Of course, at that time, our primary motivation was to have one set of GUI code that worked on multiple platforms and gave same look and feel, so tight integration with the underlying OS was not the driving concern. Our code ran well and provided same look and feel on both HP-UX and Windows. Thanks, Randy Coleburn -----Original Message----- From: Elmar Stellnberger [mailto:estellnb at elstel.org] Sent: Sunday, December 01, 2013 2:26 PM To: m3devel Subject: EXT:[M3devel] VBT and up to date desktop styling As the VBT standard interface does only offer black and white user interface styling I would need to use vbtkit to achieve at least a Windows 3.1 similar user interface. However as I have found out some of the classes in vbtkit required just for the main menu have not been completed and do not compile yet. Would someone be ready to invest some time and affection to complete these classes? To make MainMenu.m3 look good at least the following tasks would have to be done: * AnchorSwitchVBT: to be completed, 3D reflection for the anchors of the popup menus in the main menu * ShadowedBarVBT: is here but does not seem to work: it should display a horizontal bar in one of the popup menus * ShadowVBT: to be completed: draw a 3D border around popup menus and other items * Shadow: have a third color besides background and foreground for the flat style: eliminate the white borders in non-hover mode * adjust the vbtkit menu so that the popup menus stays open if the mouse button is released; this will also be necessary to make sub-menus of popup-menus work; i.e. let popup menus contain AnchorSwitchVBTs * evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs shadows appear to be larger in their horizontal extent by now compared to their vertical extent which is not that good to look at * and likely some other issues I have not discovered yet Considering all of that if I will not have an extended vbtkit interfacing with another GUI component like GTK would likely be the way to go because otherwise there would simply be too much time to be invested into vbtkit not considering underlying Trestle problems like Unicode support yet. Though it would be good to have a well working standard GUI interface for Modula-3 we need to consider now if putting further work into Trestle/vbtkit is still worth to do. If so I believe it would require a joint effort. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 51415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 47526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 57950 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 106584 bytes Desc: not available URL: From rodney_bates at lcwb.coop Tue Dec 10 18:59:54 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 10 Dec 2013 11:59:54 -0600 Subject: [M3devel] Fwd: Re: unicode in libm3 or separate package In-Reply-To: <529FE6A9.9070404@lcwb.coop> References: <529FE6A9.9070404@lcwb.coop> Message-ID: <52A7569A.9000600@lcwb.coop> 4th try repost: -------- Original Message -------- Subject: Re: [M3devel] unicode in libm3 or separate package Date: Wed, 04 Dec 2013 20:36:25 -0600 From: Rodney M. Bates To: m3devel at elegosoft.com Different meanings and procedures for bootstrapping. I am trying to ensure somebody without a previous M3 distribution can check one out, then build it with a binary only of the release compiler (e.g., via cminstall). I have not been using upgrade.sh, because it alters your /usr/local/cm3 in place, overlaying the original. This is not very handy for repeated experiments, when I have to keep recreating it. It will build though, with the dependencies in question. Instead, I have been using do-pkg.sh and do-cm3-*.sh. These, by default, use -override, which builds everything in the cvs checkout and leaves /usr/local/cm3 alone. In this case, trying to build a compiler first has no m3core or libm3 available, while building a library that depends on the newer compiler also fails. The separation I did allows this by getting code that an older compiler won't build into a separate package, where it can be done later. Unfortunately, it also means you can't just ship later, after all goes well. On 12/03/2013 06:56 PM, Jay K wrote: > Huh? No they aren't. > > > > bootstrapping uses old compiler to build everything /after /m3core/libm3 (up to cm3) > bootstrapping uses old compiler to m3front/m3back/m3quake/m3linker/cm3/sysutils, but not m3core/libm3. > Then bootstrapping uses new compiler to build everything. > > > m3core/libm3 can depend on new compiler. > m3front/m3back/m3quake/m3linker/cm3/sysutils cannot (except by more than one step, then they can -- "flexibility via multiple changes") > > > see > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/upgrade.sh?rev=1.37;content-type=text%2Fplain > notice where m3core/libm3 appear. > > > which I don't use but is possibly clearer to people and what I use was based on it (I missed that upgrade.sh actually builds everything and mine stops at cm3). > > > - Jay > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > Subject: Re: [M3devel] unicode in libm3 or separate package > From: hosking at purdue.edu > Date: Tue, 3 Dec 2013 19:13:46 -0500 > CC: m3devel at elegosoft.com; rodney.bates at wichita.edu > To: jay.krell at cornell.edu > > Huh? They are when bootstrapping. > > Sent from my iPhone > > On 3 Dec 2013, at 4:54 pm, Jay K > wrote: > > This is not necessary, but it is ok. > > m3core and libm3 are never built with an older compiler and can depend on a newer compiler. > > > - Jay > > > > Date: Tue, 3 Dec 2013 22:13:38 +0000 > > To: m3commit at elegosoft.com > > From: rodney at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/12/03 22:13:38 > > > > Modified files: > > cm3/m3-libs/libm3/src/rw/: Tag: devel_unicode m3makefile > > > > Log message: > > Move Unicode codec stuff to its own package. This allows for > > bootstrapping the unicode branch with release and head compilers. > > This code depends on being compiled with Unicode-sized WIDECHAR, > > which is not initially available when first compiling libm3 and > > the compiler, using an earlier compiler. New package libunicode > > can now be compiled later, after a new compiler is installed. > > > > script do-cm3-unicode.sh does everything do-cm3-front.sh does, > > plus libunicode. > > > From jay.krell at cornell.edu Wed Dec 11 23:36:28 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 11 Dec 2013 22:36:28 +0000 Subject: [M3devel] Fwd: Re: unicode in libm3 or separate package In-Reply-To: <52A7569A.9000600@lcwb.coop> References: <529FE6A9.9070404@lcwb.coop>,<52A7569A.9000600@lcwb.coop> Message-ID: 1) That isn't supposed to work. Sometimes it does, but there is no guarantee. 2) yeah, we should fix that, make it be two steps and the second step optional Either via buildlocal + optional ship or buildship into a new location and then optionally copy. - Jay > Date: Tue, 10 Dec 2013 11:59:54 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: Re: unicode in libm3 or separate package > > 4th try repost: > > > -------- Original Message -------- > Subject: Re: [M3devel] unicode in libm3 or separate package > Date: Wed, 04 Dec 2013 20:36:25 -0600 > From: Rodney M. Bates > To: m3devel at elegosoft.com > > Different meanings and procedures for bootstrapping. I am trying to ensure somebody > without a previous M3 distribution can check one out, then build it with a binary > only of the release compiler (e.g., via cminstall). I have not been using upgrade.sh, > because it alters your /usr/local/cm3 in place, overlaying the original. This is not > very handy for repeated experiments, when I have to keep recreating it. It will build > though, with the dependencies in question. > > Instead, I have been using do-pkg.sh and do-cm3-*.sh. These, by default, use -override, > which builds everything in the cvs checkout and leaves /usr/local/cm3 alone. In this case, > trying to build a compiler first has no m3core or libm3 available, while building a > library that depends on the newer compiler also fails. The separation I did allows this > by getting code that an older compiler won't build into a separate package, where it can > be done later. Unfortunately, it also means you can't just ship later, after all goes > well. > > On 12/03/2013 06:56 PM, Jay K wrote: > > Huh? No they aren't. > > > > > > > > bootstrapping uses old compiler to build everything /after /m3core/libm3 (up to cm3) > > bootstrapping uses old compiler to m3front/m3back/m3quake/m3linker/cm3/sysutils, but not m3core/libm3. > > Then bootstrapping uses new compiler to build everything. > > > > > > m3core/libm3 can depend on new compiler. > > m3front/m3back/m3quake/m3linker/cm3/sysutils cannot (except by more than one step, then they can -- "flexibility via multiple changes") > > > > > > see > > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/upgrade.sh?rev=1.37;content-type=text%2Fplain > > notice where m3core/libm3 appear. > > > > > > which I don't use but is possibly clearer to people and what I use was based on it (I missed that upgrade.sh actually builds everything and mine stops at cm3). > > > > > > - Jay > > > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > -- > > Subject: Re: [M3devel] unicode in libm3 or separate package > > From: hosking at purdue.edu > > Date: Tue, 3 Dec 2013 19:13:46 -0500 > > CC: m3devel at elegosoft.com; rodney.bates at wichita.edu > > To: jay.krell at cornell.edu > > > > Huh? They are when bootstrapping. > > > > Sent from my iPhone > > > > On 3 Dec 2013, at 4:54 pm, Jay K > wrote: > > > > This is not necessary, but it is ok. > > > > m3core and libm3 are never built with an older compiler and can depend on a newer compiler. > > > > > > - Jay > > > > > > > Date: Tue, 3 Dec 2013 22:13:38 +0000 > > > To: m3commit at elegosoft.com > > > From: rodney at elego.de > > > Subject: [M3commit] CVS Update: cm3 > > > > > > CVSROOT: /usr/cvs > > > Changes by: rodney at birch. 13/12/03 22:13:38 > > > > > > Modified files: > > > cm3/m3-libs/libm3/src/rw/: Tag: devel_unicode m3makefile > > > > > > Log message: > > > Move Unicode codec stuff to its own package. This allows for > > > bootstrapping the unicode branch with release and head compilers. > > > This code depends on being compiled with Unicode-sized WIDECHAR, > > > which is not initially available when first compiling libm3 and > > > the compiler, using an earlier compiler. New package libunicode > > > can now be compiled later, after a new compiler is installed. > > > > > > script do-cm3-unicode.sh does everything do-cm3-front.sh does, > > > plus libunicode. > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sat Dec 14 11:45:18 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 14 Dec 2013 11:45:18 +0100 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <52AC36BE.6070309@elstel.org> Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. Would anyone mind this to fix in the main trunk? Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. How do I f.i. listen to a 'pressed' signal on a QPushButton? There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. Elmar Am 04.12.13 18:52, schrieb Jay K: > Randy, definitely at least some of your changes got in. > For example, see: > https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-ui/vbtkit/src/lego/WIN32/ > The changes involved forking large files to make small changes, and > apparent bugs resulted as the files drifted apart. > > > There are Qt bindings in the tree now. > I haven't tried them yet. > Qt is probably the way to go. > > > The challenge in all this is coming up with the right abstraction or > adopting the correct existing abstraction. > In the language we have a "record". This turns out to be very portable. > All processors and intermediate representations support it, or will be > force of existing practise throughout the software industry (i.e. C > has structs, therefore structs and anything resembling them shall > always work efficiently). > > > Then, what is the right abstraction for a GUI library? > What will always be "easy enough" to implement on hardware or on top > of other libraries? > And, how far down do we implement and meet the next layer? > Is the next layer a video buffer? Or a high level library? Or > generating html for "complete reinterpretation"? > A thin stateless wrapper where someone else does 99.9% of the work? > > > And then implementing our part of it. > > > - Jay > > ------------------------------------------------------------------------ > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Wed, 4 Dec 2013 03:10:03 +0000 > Subject: Re: [M3devel] VBT and up to date desktop styling > > Elmar: > > Years ago, I worked with the principals at Critical Mass to make some > Trestle/VBT/VBTKit changes that would make the ?look and feel? more > Windows-like. > > I'm pretty sure I passed all these to Olaf for incorporation into the > CVS repository. > > I developed some GUIs that looked decent at the time on Windows NT, > but more work could be done to provide tighter integration. > > Not sure if these pics will come thru in the email, but I've pasted a > few below to give you some idea of what we achieved using Trestle, > VBTKit, FormsVBT, etc. > > Of course, at that time, our primary motivation was to have one set of > GUI code that worked on multiple platforms and gave same look and > feel, so tight integration with the underlying OS was not the driving > concern. Our code ran well and provided same look and feel on both > HP-UX and Windows. > > Thanks, > > Randy Coleburn > > -----Original Message----- > From: Elmar Stellnberger [mailto:estellnb at elstel.org] > Sent: Sunday, December 01, 2013 2:26 PM > To: m3devel > Subject: EXT:[M3devel] VBT and up to date desktop styling > > As the VBT standard interface does only offer black and white user > interface styling I would need to use vbtkit to achieve at least a > Windows 3.1 similar user interface. However as I have found out some > of the classes in vbtkit required just for the main menu have not been > completed and do not compile yet. Would someone be ready to invest > some time and affection to complete these classes? > > To make MainMenu.m3 look good at least the following tasks would have > to be done: > > * AnchorSwitchVBT: to be completed, 3D reflection for the anchors of > the popup menus in the main menu > > * ShadowedBarVBT: is here but does not seem to work: it should display > a horizontal bar in one of the popup menus > > * ShadowVBT: to be completed: draw a 3D border around popup menus and > other items > > * Shadow: have a third color besides background and foreground for the > flat style: eliminate the white borders in non-hover mode > > * adjust the vbtkit menu so that the popup menus stays open if the > mouse button is released; this will also be necessary to make > sub-menus of popup-menus work; i.e. let popup menus contain > AnchorSwitchVBTs > > * evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs > shadows appear to be larger in their horizontal extent by now compared > to their vertical extent which is not that good to look at > > * and likely some other issues I have not discovered yet > > Considering all of that if I will not have an extended vbtkit > interfacing with another GUI component like GTK would likely be the > way to go because otherwise there would simply be too much time to be > invested into vbtkit not considering underlying Trestle problems like > Unicode support yet. Though it would be good to have a well working > standard GUI interface for Modula-3 we need to consider now if putting > further work into Trestle/vbtkit is still worth to do. If so I believe > it would require a joint effort. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 57950 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 47526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 51415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 106584 bytes Desc: not available URL: From dabenavidesd at yahoo.es Sat Dec 14 21:31:58 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 14 Dec 2013 20:31:58 +0000 (GMT) Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52AC36BE.6070309@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> <52AC36BE.6070309@elstel.org> Message-ID: <1387053118.25449.YahooMailNeo@web171902.mail.ir2.yahoo.com> Hi all, not me, but somebody was happily (well almost) compiling 200k lines of Modula-3 from Qt headers some months ago. But I don't know how to browse in that page, I'm openly against new UI in web pages :), are just too crazy, maybe I'm just too old for that technology. Can you help to contact demoitem guy: https://github.com/swig/swig/pull/84 Thanks in advance El S?bado 14 de diciembre de 2013 5:45, Elmar Stellnberger escribi?: Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. Would anyone mind this to fix in the main trunk? Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. How do I f.i. listen to a 'pressed' signal on a QPushButton? There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. Elmar Am 04.12.13 18:52, schrieb Jay K: >Randy, definitely at least some of your changes got in. >For example, see: >?https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-ui/vbtkit/src/lego/WIN32/ >The changes involved forking large files to make small changes, and apparent bugs resulted as the files drifted apart. > > >There are Qt bindings in the tree now. >I haven't tried them yet. >Qt is probably the way to go. > > >The challenge in all this is coming up with the right abstraction or adopting the correct existing abstraction. >In the language we have a "record". This turns out to be very portable. >All processors and intermediate representations support it, or will be force of existing practise throughout the software industry (i.e. C has structs, therefore structs and anything resembling them shall always work efficiently). > > >Then, what is the right abstraction for a GUI library? >What will always be "easy enough" to implement on hardware or on top of other libraries? >And, how far down do we implement and meet the next layer? >Is the next layer a video buffer? Or a high level library? Or generating html for "complete reinterpretation"? >A thin stateless wrapper where someone else does 99.9% of the work? > > >And then implementing our part of it. > > >?- Jay > > > >________________________________ >From: rcolebur at SCIRES.COM >To: m3devel at elegosoft.com >Date: Wed, 4 Dec 2013 03:10:03 +0000 >Subject: Re: [M3devel] VBT and up to date desktop styling > > >Elmar: >? >Years ago, I worked with the principals at Critical Mass to make some Trestle/VBT/VBTKit changes that would make the ?look and feel? more Windows-like. >? >I'm pretty sure I passed all these to Olaf for incorporation into the CVS repository. >? >I developed some GUIs that looked decent at the time on Windows NT, but more work could be done to provide tighter integration. >? >Not sure if these pics will come thru in the email, but I've pasted a few below to give you some idea of what we achieved using Trestle, VBTKit, FormsVBT, etc. >? >Of course, at that time, our primary motivation was to have one set of GUI code that worked on multiple platforms and gave same look and feel, so tight integration with the underlying OS was not the driving concern.? Our code ran well and provided same look and feel on both HP-UX and Windows. >? >? >? >? >? >? >Thanks, >Randy Coleburn >? >-----Original Message----- >From: Elmar Stellnberger [mailto:estellnb at elstel.org] >Sent: Sunday, December 01, 2013 2:26 PM >To: m3devel >Subject: EXT:[M3devel] VBT and up to date desktop styling >? >As the VBT standard interface does only offer black and white user interface styling I would need to use vbtkit to achieve at least a Windows 3.1 similar user interface. However as I have found out some of the classes in vbtkit required just for the main menu have not been completed and do not compile yet. Would someone be ready to invest some time and affection to complete these classes? >To make MainMenu.m3 look good at least the following tasks would have to be done: >? >* AnchorSwitchVBT: to be completed, 3D reflection for the anchors of the popup menus in the main menu >* ShadowedBarVBT: is here but does not seem to work: it should display a horizontal bar in one of the popup menus >* ShadowVBT: to be completed: draw a 3D border around popup menus and other items >* Shadow: have a third color besides background and foreground for the flat style: eliminate the white borders in non-hover mode >* adjust the vbtkit menu so that the popup menus stays open if the mouse button is released; this will also be necessary to make sub-menus of popup-menus work; i.e. let popup menus contain AnchorSwitchVBTs >* evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs shadows appear to be larger in their horizontal extent by now compared to their vertical extent which is not that good to look at >* and likely some other issues I have not discovered yet >? >Considering all of that if I will not have an extended vbtkit interfacing with another GUI component like GTK would likely be the way to go because otherwise there would simply be too much time to be invested into vbtkit not considering underlying Trestle problems like Unicode support yet. Though it would be good to have a well working standard GUI interface for Modula-3 we need to consider now if putting further work into Trestle/vbtkit is still worth to do. If so I believe it would require a joint effort. >? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 57950 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 47526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 51415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 106584 bytes Desc: not available URL: From rodney_bates at lcwb.coop Sun Dec 15 16:40:26 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 15 Dec 2013 09:40:26 -0600 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52AC36BE.6070309@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> <52AC36BE.6070309@elstel.org> Message-ID: <52ADCD6A.10303@lcwb.coop> On 12/14/2013 04:45 AM, Elmar Stellnberger wrote: > Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. > Would anyone mind this to fix in the main trunk? > > Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. > I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. > How do I f.i. listen to a 'pressed' signal on a QPushButton? > There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. > Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). > Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. > > and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. > > Elmar > Just to be sure you understand, Modula-3 arrays of current-sized WIDECHAR are not UTF-16 character arrays. The former can only represent characters whose code points are <= 16_FFFF. UTF-16 encodes up to 16_10FFFF, by using two 16-bit code units for one character in the upper part of the range. This also means that the codes in the two code units are surrogates (16_D800..16_DFFF) and cannot be used as unencoded characters. For output, you could deal with this by just avoiding putting any surrogate values into a WIDECHAR (and, of course, no values beyond 16_FFFF, since they won't fit). But for input, any correctly implemented library that gives you UTF-16 strings could contain these, and probably you can't prevent that, because they can come all the way from a human user. So you would have to treat the WIDECHARs as code units, not code points, and write your own decoder. But then you would need a type to hold the decoded values, and WIDECHAR is not big enough, so it would have to be INTEGER or a subrange, and now you can't use the literals without conversions. Moreover, you can't use TEXT, with its easy-to-use functional style implementation of various string operations. I suppose you could write it so it just rejects or replaces high-valued code points at the decode stage and tell your users they can't use these characters. Or, you could just assume neither your application nor your users will ever need to use codes where 16-bit WIDECHAR and UTF-16 differ, and let it be buggy, if the assumption is ever violated. Also, does your preferred GUI allow you to specify that the UTF-16 strings you give it and get from it always have little endian code units, regardless of the native endianness of the machine? This is the way Modula-3 WIDECHARs work. If not, your application would only work on little-endian machines. From jay.krell at cornell.edu Mon Dec 16 10:31:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 16 Dec 2013 09:31:57 +0000 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52ADCD6A.10303@lcwb.coop> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> Message-ID: > like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. It might as well be UINT32 or UInt32? In C++, std::string is std::basic_string, std::wstring = std::basic_string. Could/should we use generics similarly? CharText, WIDECHAR=UINT16, WideCharText, UInt32Text? There is the problem of text literals. The current "text" can change between "char" and "widechar". Can "widechar" vary per-target? In particular, I think C/C++ wchar_t is 32bits on some platforms, so it might be reasonable for Modula-3 WIDECHAR to match it? (I just checked -- Linux/amd64 does have 32bit wchar_t). It is a thorny issue though, there are pluses and minuse either way. An alternative would be to have WIDECHAR be the same for all targets. - Jay > Date: Sun, 15 Dec 2013 09:40:26 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 does not support Scan.LongInt > > > > On 12/14/2013 04:45 AM, Elmar Stellnberger wrote: > > Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. > > Would anyone mind this to fix in the main trunk? > > > > Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. > > I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. > > How do I f.i. listen to a 'pressed' signal on a QPushButton? > > There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. > > Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). > > Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. > > > > and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. > > > > Elmar > > > > Just to be sure you understand, Modula-3 arrays of current-sized WIDECHAR > are not UTF-16 character arrays. The former can only represent characters > whose code points are <= 16_FFFF. UTF-16 encodes up to 16_10FFFF, by using > two 16-bit code units for one character in the upper part of the range. > This also means that the codes in the two code units are surrogates > (16_D800..16_DFFF) and cannot be used as unencoded characters. > > For output, you could deal with this by just avoiding putting any surrogate > values into a WIDECHAR (and, of course, no values beyond 16_FFFF, since they > won't fit). But for input, any correctly implemented library that gives you > UTF-16 strings could contain these, and probably you can't prevent that, because > they can come all the way from a human user. > > So you would have to treat the WIDECHARs as code units, not code points, and > write your own decoder. But then you would need a type to hold the decoded > values, and WIDECHAR is not big enough, so it would have to be INTEGER or a > subrange, and now you can't use the literals without conversions. Moreover, > you can't use TEXT, with its easy-to-use functional style implementation of > various string operations. I suppose you could write it so it just rejects > or replaces high-valued code points at the decode stage and tell your users > they can't use these characters. > > Or, you could just assume neither your application nor your users will ever > need to use codes where 16-bit WIDECHAR and UTF-16 differ, and let it be buggy, > if the assumption is ever violated. > > Also, does your preferred GUI allow you to specify that the UTF-16 strings > you give it and get from it always have little endian code units, regardless > of the native endianness of the machine? This is the way Modula-3 WIDECHARs > work. If not, your application would only work on little-endian machines. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 16 16:00:40 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Dec 2013 10:00:40 -0500 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> Message-ID: <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> Jumping in late to this whole conversation (please forgive any confusion)... I hesitate to define ANY M3 builtin type in terms of C/C++ standards. Regarding WIDECHAR, realize that its definition, like CHAR, should be in terms of an enumeration containing some (minimal) number of elements. The standard says that CHAR contains at least 256 elements. In M3 enumerations all have a direct mapping to INTEGER. So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded as UTF-8. More radically, what current code will break if CHAR is expanded to UTF-32? The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). On Dec 16, 2013, at 4:31 AM, Jay K wrote: > > like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. > > > It might as well be UINT32 or UInt32? > > > In C++, std::string is std::basic_string, std::wstring = std::basic_string. > Could/should we use generics similarly? > > > CharText, WIDECHAR=UINT16, WideCharText, UInt32Text? > > > There is the problem of text literals. > The current "text" can change between "char" and "widechar". > > > Can "widechar" vary per-target? > In particular, I think C/C++ wchar_t is 32bits on some platforms, so it might be reasonable for Modula-3 WIDECHAR to match it? > (I just checked -- Linux/amd64 does have 32bit wchar_t). > > > It is a thorny issue though, there are pluses and minuse either way. > An alternative would be to have WIDECHAR be the same for all targets. > > > - Jay > > > Date: Sun, 15 Dec 2013 09:40:26 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] cm3 does not support Scan.LongInt > > > > > > > > On 12/14/2013 04:45 AM, Elmar Stellnberger wrote: > > > Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. > > > Would anyone mind this to fix in the main trunk? > > > > > > Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. > > > I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. > > > How do I f.i. listen to a 'pressed' signal on a QPushButton? > > > There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. > > > Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). > > > Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. > > > > > > and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. > > > > > > Elmar > > > > > > > Just to be sure you understand, Modula-3 arrays of current-sized WIDECHAR > > are not UTF-16 character arrays. The former can only represent characters > > whose code points are <= 16_FFFF. UTF-16 encodes up to 16_10FFFF, by using > > two 16-bit code units for one character in the upper part of the range. > > This also means that the codes in the two code units are surrogates > > (16_D800..16_DFFF) and cannot be used as unencoded characters. > > > > For output, you could deal with this by just avoiding putting any surrogate > > values into a WIDECHAR (and, of course, no values beyond 16_FFFF, since they > > won't fit). But for input, any correctly implemented library that gives you > > UTF-16 strings could contain these, and probably you can't prevent that, because > > they can come all the way from a human user. > > > > So you would have to treat the WIDECHARs as code units, not code points, and > > write your own decoder. But then you would need a type to hold the decoded > > values, and WIDECHAR is not big enough, so it would have to be INTEGER or a > > subrange, and now you can't use the literals without conversions. Moreover, > > you can't use TEXT, with its easy-to-use functional style implementation of > > various string operations. I suppose you could write it so it just rejects > > or replaces high-valued code points at the decode stage and tell your users > > they can't use these characters. > > > > Or, you could just assume neither your application nor your users will ever > > need to use codes where 16-bit WIDECHAR and UTF-16 differ, and let it be buggy, > > if the assumption is ever violated. > > > > Also, does your preferred GUI allow you to specify that the UTF-16 strings > > you give it and get from it always have little endian code units, regardless > > of the native endianness of the machine? This is the way Modula-3 WIDECHARs > > work. If not, your application would only work on little-endian machines. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Mon Dec 16 17:20:13 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Mon, 16 Dec 2013 17:20:13 +0100 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> Message-ID: <52AF283D.2090707@elstel.org> Am 16.12.13 16:00, schrieb Tony Hosking: > Jumping in late to this whole conversation (please forgive any > confusion)... > > I hesitate to define ANY M3 builtin type in terms of C/C++ standards. > Regarding WIDECHAR, realize that its definition, like CHAR, should be > in terms of an enumeration containing some (minimal) number of elements. > The standard says that CHAR contains at least 256 elements. > In M3 enumerations all have a direct mapping to INTEGER. > So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded > as UTF-8. > More radically, what current code will break if CHAR is expanded to > UTF-32? > The language definition would allow that (there is nothing that says > BITSIZE(CHAR) == 8). > > On Dec 16, 2013, at 4:31 AM, Jay K > wrote: > Any code that was built to handle multiple character code sequences will break. i.e. any correctly implemented code that relies on UTF-16LE as currently provided expanding this range would be inherently non-portable. (... and it could even cause additional problems for when it came to interface with Xorg and Qt.) I'd believe that relying on a fixed range of values is going to be crucial for any kind of character type. You did not expand the CHAR type to 16 or 32bit either though that could even have caused less problems. Writing code that manipulates characters is simply very different from writing code that does some calculation based on integer numbers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Mon Dec 16 17:42:41 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Mon, 16 Dec 2013 17:42:41 +0100 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> Message-ID: <52AF2D81.2020501@elstel.org> Am 16.12.13 16:00, schrieb Tony Hosking: > Jumping in late to this whole conversation (please forgive any > confusion)... > > I hesitate to define ANY M3 builtin type in terms of C/C++ standards. > Regarding WIDECHAR, realize that its definition, like CHAR, should be > in terms of an enumeration containing some (minimal) number of elements. > The standard says that CHAR contains at least 256 elements. > In M3 enumerations all have a direct mapping to INTEGER. > So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded > as UTF-8. > More radically, what current code will break if CHAR is expanded to > UTF-32? > The language definition would allow that (there is nothing that says > BITSIZE(CHAR) == 8). > Well, if so I could rewrite some code to define as BITS 16 FOR WIDECHAR as WCHAR. Perhaps that would be the way to go. However as Rodney M. Bates has said current WIDECHAR is not BITS 16 for UCHAR. It uses LE encoding rather than host order encoding a fact which one could be quite happy about when it comes to extend Trestle/X11 for widechar support. So even that would fail when it came to interface with X11 (or otherwise one would have to maintain two branches of code all the time; one that does byte swapping and one that does not depending on the host order AND the internally used wchar order which could then differ as well.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 16 23:48:04 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 16 Dec 2013 22:48:04 +0000 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52AF2D81.2020501@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu>, <52AF2D81.2020501@elstel.org> Message-ID: > More radically, what current code will break if CHAR is expanded to UTF-32? > The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). Philosophy: I think you have be careful where you decide something is an abstraction vs. where you keep things unchanged because a lot of code depends on it AND it is adequate, and then introduce new things for new meanings. If something is an abstraction, you need to be sure that - all operations people might want to do are supported - breaking through the abstraction boundary is difficult/impossible, such that you maintain the ability to change the implementation later without breaking things Abstractions can have value, where you change the implementation and imbue existing code with some new features as a result. Such as ability to work with Unicode. For example, INTEGER is abstract enough, I guess, such that we can widen it. It isn't clearly abstract enough such that we can make overflow raise exceptions, because the existing widely used implementation does not. The size of INTEGER is plain to see to its clients and it is easy for them to be (accidentally) dependent on a particular implementation, but we have likely gotten over that by now, by having a good mix of implementations in use. Eventually we will probably see that code won't work if BITSIZE(INTEGER) = 32. Another example is that in C++ std::vector::iterator is very much like T*. In fact, it supports an identical feature set, except that it can be a different type and only mix with itself and not T*. In some implementations, it was in fact T* and there was code that mixed them. The implementation was later changed such as to be a unique type and a bunch of code stopped compiling. This is an example where the implementation wasn't opaque enough. Now presumably it is, so further changes won't cause such problems. (You can convert from iterator to pointer just by "&*" and std::vector is guaranteed contiguous, so the breakage was trivial to fix.) In C and I thought Modula-3 "char" / "CHAR" means "byte". Exactly 8 bits. I know there might be some wierdo Cray environments where all integer types are really 64 bit doubles, but millions of lines of C/C++ code assumes char is byte. Memory is composed of chars, files are composed of chars. Java and C# "fixed" this, char is 16bits there, and there is a new type "byte" or "int8" or "uint8", but for C and I thought Modula-3 we are stuck with char==8 bit byte and that is ok. (The signedness of char remains reasonably abstract and I think most code is ok either way, but I have seen code that depends on it either way.) Does X have an implied little/bigendian for 16 bit characters? If it is host, then we should use host. Windows uses host. Which is pretty much always little (except Xbox 360, and maybe some CE targets?) We would NOT maintain two forks, swapping and not, no matter what. We would have a function "SwapWideCharToLittleEndian" or such, written in C, that would probe the host endian and swap if needed. The probe would be something like: int is_little_endian(void) { union { char a[sizeof(int)]; int b; } c = {{1}}; return c.b == 1; } - Jay Date: Mon, 16 Dec 2013 17:42:41 +0100 From: estellnb at elstel.rivido.de To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com; rodney_bates at lcwb.coop Subject: Re: [M3devel] cm3 does not support Scan.LongInt Am 16.12.13 16:00, schrieb Tony Hosking: Jumping in late to this whole conversation (please forgive any confusion)... I hesitate to define ANY M3 builtin type in terms of C/C++ standards. Regarding WIDECHAR, realize that its definition, like CHAR, should be in terms of an enumeration containing some (minimal) number of elements. The standard says that CHAR contains at least 256 elements. In M3 enumerations all have a direct mapping to INTEGER. So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded as UTF-8. More radically, what current code will break if CHAR is expanded to UTF-32? The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). Well, if so I could rewrite some code to define as BITS 16 FOR WIDECHAR as WCHAR. Perhaps that would be the way to go. However as Rodney M. Bates has said current WIDECHAR is not BITS 16 for UCHAR. It uses LE encoding rather than host order encoding a fact which one could be quite happy about when it comes to extend Trestle/X11 for widechar support. So even that would fail when it came to interface with X11 (or otherwise one would have to maintain two branches of code all the time; one that does byte swapping and one that does not depending on the host order AND the internally used wchar order which could then differ as well.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Tue Dec 17 20:20:17 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Tue, 17 Dec 2013 19:20:17 +0000 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu>, <52AF2D81.2020501@elstel.org> Message-ID: <52B0A3F1.8070509@elstel.org> The Xorg documentation defines: typedef struct { unsigned char byte1; unsigned char byte2; } XChar2b; oopsla: byte1 = N div D + min_byte1 byte2 = N mod D + min_char_or_byte2 so this is big endian in deed (no matter of the arch). Perhaps Modula-3 should then store in host byte order and only convert on request. Defining it to be little endian would impose a certain unnecessary overhead on VAL and ORD and would most likely require byte swapping for Qt which I understand to implement QChar as host byte order (" Most compilers treat it like a unsigned short"). Am 16.12.2013 22:48, schrieb Jay K: > > More radically, what current code will break if CHAR is expanded > to UTF-32? > > The language definition would allow that (there is nothing that > says BITSIZE(CHAR) == 8). > > Philosophy: > > I think you have be careful where you decide something > is an abstraction vs. where you keep things unchanged > because a lot of code depends on it AND it is adequate, and > then introduce new things for new meanings. > > If something is an abstraction, you need to be sure that > - all operations people might want to do are supported > - breaking through the abstraction boundary is difficult/impossible, > such that you maintain the ability to change the implementation later > without breaking things > > Abstractions can have value, where you change the implementation > and imbue existing code with some new features as a result. > Such as ability to work with Unicode. > > For example, INTEGER is abstract enough, I guess, such that we can > widen it. > It isn't clearly abstract enough such that we can make overflow > raise exceptions, because the existing widely used implementation > does not. > > The size of INTEGER is plain to see to its clients and it is easy for > them > to be (accidentally) dependent on a particular implementation, but we > have likely > gotten over that by now, by having a good mix of implementations in use. > Eventually we will probably see that code won't work if > BITSIZE(INTEGER) = 32. > > > Another example is that in C++ std::vector::iterator is very much > like T*. In fact, it supports an identical feature set, except that > it can be a different > type and only mix with itself and not T*. > In some implementations, it was in fact T* and there was code that > mixed them. > The implementation was later changed such as to be a unique type and > a bunch > of code stopped compiling. This is an example where the > implementation wasn't opaque > enough. Now presumably it is, so further changes won't cause such > problems. > (You can convert from iterator to pointer just by "&*" and > std::vector is guaranteed > contiguous, so the breakage was trivial to fix.) > > In C and I thought Modula-3 "char" / "CHAR" means "byte". Exactly 8 > bits. > I know there might be some wierdo Cray environments where all > integer types are really 64 bit doubles, > but millions of lines of C/C++ code assumes char is byte. Memory is > composed of chars, files > are composed of chars. Java and C# "fixed" this, char is 16bits > there, and there is a new type "byte" > or "int8" or "uint8", but for C and I thought Modula-3 we are stuck > with char==8 bit byte and that is ok. > (The signedness of char remains reasonably abstract and I think most > code is ok either way, but > I have seen code that depends on it either way.) > > > Does X have an implied little/bigendian for 16 bit characters? > If it is host, then we should use host. > Windows uses host. Which is pretty much always little (except Xbox > 360, and maybe some CE targets?) > We would NOT maintain two forks, swapping and not, no matter what. > We would have a function "SwapWideCharToLittleEndian" or such, written > in C, > that would probe the host endian and swap if needed. > The probe would be something like: > int is_little_endian(void) { union { char a[sizeof(int)]; int b; } c = > {{1}}; return c.b == 1; } > > > - Jay > > ------------------------------------------------------------------------ > Date: Mon, 16 Dec 2013 17:42:41 +0100 > From: estellnb at elstel.rivido.de > To: hosking at cs.purdue.edu; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; rodney_bates at lcwb.coop > Subject: Re: [M3devel] cm3 does not support Scan.LongInt > > Am 16.12.13 16:00, schrieb Tony Hosking: > > Jumping in late to this whole conversation (please forgive any > confusion)... > > I hesitate to define ANY M3 builtin type in terms of C/C++ standards. > Regarding WIDECHAR, realize that its definition, like CHAR, should > be in terms of an enumeration containing some (minimal) number of > elements. > The standard says that CHAR contains at least 256 elements. > In M3 enumerations all have a direct mapping to INTEGER. > So, I assume that WIDECHAR would be UTF-32, and TEXT could be > encoded as UTF-8. > More radically, what current code will break if CHAR is expanded > to UTF-32? > The language definition would allow that (there is nothing that > says BITSIZE(CHAR) == 8). > > Well, if so I could rewrite some code to define as BITS 16 FOR > WIDECHAR as WCHAR. > Perhaps that would be the way to go. > However as Rodney M. Bates has said current WIDECHAR is not BITS 16 > for UCHAR. > It uses LE encoding rather than host order encoding a fact which one > could be quite > happy about when it comes to extend Trestle/X11 for widechar support. > So even that > would fail when it came to interface with X11 (or otherwise one would > have to maintain > two branches of code all the time; one that does byte swapping and one > that does not > depending on the host order AND the internally used wchar order which > could then > differ as well.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 17 21:55:29 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Dec 2013 20:55:29 +0000 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52B0A3F1.8070509@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu>, <52AF2D81.2020501@elstel.org> , <52B0A3F1.8070509@elstel.org> Message-ID: Yuck. I guess they 1) needed a wire format (definitely) and 2) never added a layer above that. We should use host order, yes, "like unsigned short". And btw there isn't necessarily a need to swap. You can always just extract bytes, like what you show: unsigned short u; unsigned char bigendian_bytes[2] = {(unsigned char)(u >> 8), (unsigned char)u}; is correct no matter the host order, maybe slow on big endian hosts, but fast enough. - Jay Date: Tue, 17 Dec 2013 19:20:17 +0000 From: estellnb at elstel.rivido.de To: jay.krell at cornell.edu; estellnb at elstel.rivido.de; hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] cm3 does not support Scan.LongInt The Xorg documentation defines: typedef struct { unsigned char byte1; unsigned char byte2; } XChar2b; oopsla: byte1 = N div D + min_byte1 byte2 = N mod D + min_char_or_byte2 so this is big endian in deed (no matter of the arch). Perhaps Modula-3 should then store in host byte order and only convert on request. Defining it to be little endian would impose a certain unnecessary overhead on VAL and ORD and would most likely require byte swapping for Qt which I understand to implement QChar as host byte order (" Most compilers treat it like a unsigned short"). Am 16.12.2013 22:48, schrieb Jay K: > More radically, what current code will break if CHAR is expanded to UTF-32? > The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). Philosophy: I think you have be careful where you decide something is an abstraction vs. where you keep things unchanged because a lot of code depends on it AND it is adequate, and then introduce new things for new meanings. If something is an abstraction, you need to be sure that - all operations people might want to do are supported - breaking through the abstraction boundary is difficult/impossible, such that you maintain the ability to change the implementation later without breaking things Abstractions can have value, where you change the implementation and imbue existing code with some new features as a result. Such as ability to work with Unicode. For example, INTEGER is abstract enough, I guess, such that we can widen it. It isn't clearly abstract enough such that we can make overflow raise exceptions, because the existing widely used implementation does not. The size of INTEGER is plain to see to its clients and it is easy for them to be (accidentally) dependent on a particular implementation, but we have likely gotten over that by now, by having a good mix of implementations in use. Eventually we will probably see that code won't work if BITSIZE(INTEGER) = 32. Another example is that in C++ std::vector::iterator is very much like T*. In fact, it supports an identical feature set, except that it can be a different type and only mix with itself and not T*. In some implementations, it was in fact T* and there was code that mixed them. The implementation was later changed such as to be a unique type and a bunch of code stopped compiling. This is an example where the implementation wasn't opaque enough. Now presumably it is, so further changes won't cause such problems. (You can convert from iterator to pointer just by "&*" and std::vector is guaranteed contiguous, so the breakage was trivial to fix.) In C and I thought Modula-3 "char" / "CHAR" means "byte". Exactly 8 bits. I know there might be some wierdo Cray environments where all integer types are really 64 bit doubles, but millions of lines of C/C++ code assumes char is byte. Memory is composed of chars, files are composed of chars. Java and C# "fixed" this, char is 16bits there, and there is a new type "byte" or "int8" or "uint8", but for C and I thought Modula-3 we are stuck with char==8 bit byte and that is ok. (The signedness of char remains reasonably abstract and I think most code is ok either way, but I have seen code that depends on it either way.) Does X have an implied little/bigendian for 16 bit characters? If it is host, then we should use host. Windows uses host. Which is pretty much always little (except Xbox 360, and maybe some CE targets?) We would NOT maintain two forks, swapping and not, no matter what. We would have a function "SwapWideCharToLittleEndian" or such, written in C, that would probe the host endian and swap if needed. The probe would be something like: int is_little_endian(void) { union { char a[sizeof(int)]; int b; } c = {{1}}; return c.b == 1; } - Jay Date: Mon, 16 Dec 2013 17:42:41 +0100 From: estellnb at elstel.rivido.de To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com; rodney_bates at lcwb.coop Subject: Re: [M3devel] cm3 does not support Scan.LongInt Am 16.12.13 16:00, schrieb Tony Hosking: Jumping in late to this whole conversation (please forgive any confusion)... I hesitate to define ANY M3 builtin type in terms of C/C++ standards. Regarding WIDECHAR, realize that its definition, like CHAR, should be in terms of an enumeration containing some (minimal) number of elements. The standard says that CHAR contains at least 256 elements. In M3 enumerations all have a direct mapping to INTEGER. So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded as UTF-8. More radically, what current code will break if CHAR is expanded to UTF-32? The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). Well, if so I could rewrite some code to define as BITS 16 FOR WIDECHAR as WCHAR. Perhaps that would be the way to go. However as Rodney M. Bates has said current WIDECHAR is not BITS 16 for UCHAR. It uses LE encoding rather than host order encoding a fact which one could be quite happy about when it comes to extend Trestle/X11 for widechar support. So even that would fail when it came to interface with X11 (or otherwise one would have to maintain two branches of code all the time; one that does byte swapping and one that does not depending on the host order AND the internally used wchar order which could then differ as well.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 19 22:55:30 2013 From: rodney_bates at lcwb.coop (Rodney Bates) Date: Thu, 19 Dec 2013 13:55:30 -0800 Subject: [M3devel] cm3 does not support Scan.LongInt Message-ID: <20131219135530.EA1CECFD@m0005299.ppops.net> An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 19 23:09:34 2013 From: rodney_bates at lcwb.coop (Rodney Bates) Date: Thu, 19 Dec 2013 14:09:34 -0800 Subject: [M3devel] cm3 does not support Scan.LongInt Message-ID: <20131219140934.EA1CEF38@m0005299.ppops.net> An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 19 22:40:52 2013 From: rodney_bates at lcwb.coop (Rodney Bates) Date: Thu, 19 Dec 2013 13:40:52 -0800 Subject: [M3devel] cm3 does not support Scan.LongInt Message-ID: <20131219134052.EA1CEDDB@m0005299.ppops.net> An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Dec 1 01:16:21 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 Nov 2013 19:16:21 -0500 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529A43B3.2090803@lcwb.coop> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> <20131130172906.GA28372@topoi.pooq.com> <529A43B3.2090803@lcwb.coop> Message-ID: <20131201001621.GA2374@topoi.pooq.com> On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: > > > On 11/30/2013 11:29 AM, Hendrik Boom wrote: > >On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: > >>Another devilish detail to be aware of: UTF-16 is _not_ the same as > >>the current Modula-3 16-bit WIDECHAR, even when restricted to values > >><= 16_FFFF. Current Wr/Rd library code just writes/reads > >>exactly 16 bits in two bytes, with whatever code point is in the > >>WIDECHAR variable. > >> > >>In contrast, UTF-16 will encode code points greater than > >>UFFFF as a pair of 16-bit code units with surrogate values in them. > >>Then to make this work right, the surrogate values are not > >>allowed in unencoded variables. So attempting to encode a surrogate > >>in UTF-16 is an error, and decoding a surrogate that is not part of a > >>proper first-surrogate/second-surrogate pair is "ill formed" and usually > >>decodes to UFFFD. > >> > >>You could get by with treating these as interchangeable only be being > >>careful to ensure there is never either a surrogate code nor a code > >>point > UFFFF, in either input or output. > >> > >>Also, current Wr/Rd always write/read only in little-endian byte order, > >>whereas there are both little- and big-endian variants of UTF-16. > >>I have no idea which endianness of UTF-16 is used by various GUI > >>libraries, but it would have to be little for this to work. > > > >It lools as if one might as well use UTF-8 if one is going to consider UTF-16. > > Hmm. Actually, *if* one could live with the restrictions on values above, > passing the same strings back and forth, with the GUI considering them UTF-16LE > and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have > the advantage that the M3 app code could deal naturally in characters, rather > than varying numbers of fragments of characters. UTF-8 would require > the latter. And then we just wait for the potential user who can't, and we'll have this discussion all over again. With the disadvantage that we'll end up having to put still more mechanisms for handling text everywhere. -- hendrik > > > > > >I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). > >and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have > >been superseded by SCIM, I don't know the status of uim, except that > >it has a uim bridge. > > > >It does look as if SCIM > >(http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended > >as a simple way to interface to many other input methods, such as XIM. > >It may be worth a look. > > > >--- hendrik > > > > > From jay.krell at cornell.edu Sun Dec 1 03:01:14 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 1 Dec 2013 02:01:14 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131201001621.GA2374@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com>, , <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org>, <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org>, <529A17DC.3080906@lcwb.coop>, <20131130172906.GA28372@topoi.pooq.com>, <529A43B3.2090803@lcwb.coop>, <20131201001621.GA2374@topoi.pooq.com> Message-ID: Windows is localized to and runs well with very many languages, using 16bit WCHAR.. - Jay > Date: Sat, 30 Nov 2013 19:16:21 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: > > > > > > On 11/30/2013 11:29 AM, Hendrik Boom wrote: > > >On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: > > >>Another devilish detail to be aware of: UTF-16 is _not_ the same as > > >>the current Modula-3 16-bit WIDECHAR, even when restricted to values > > >><= 16_FFFF. Current Wr/Rd library code just writes/reads > > >>exactly 16 bits in two bytes, with whatever code point is in the > > >>WIDECHAR variable. > > >> > > >>In contrast, UTF-16 will encode code points greater than > > >>UFFFF as a pair of 16-bit code units with surrogate values in them. > > >>Then to make this work right, the surrogate values are not > > >>allowed in unencoded variables. So attempting to encode a surrogate > > >>in UTF-16 is an error, and decoding a surrogate that is not part of a > > >>proper first-surrogate/second-surrogate pair is "ill formed" and usually > > >>decodes to UFFFD. > > >> > > >>You could get by with treating these as interchangeable only be being > > >>careful to ensure there is never either a surrogate code nor a code > > >>point > UFFFF, in either input or output. > > >> > > >>Also, current Wr/Rd always write/read only in little-endian byte order, > > >>whereas there are both little- and big-endian variants of UTF-16. > > >>I have no idea which endianness of UTF-16 is used by various GUI > > >>libraries, but it would have to be little for this to work. > > > > > >It lools as if one might as well use UTF-8 if one is going to consider UTF-16. > > > > Hmm. Actually, *if* one could live with the restrictions on values above, > > passing the same strings back and forth, with the GUI considering them UTF-16LE > > and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have > > the advantage that the M3 app code could deal naturally in characters, rather > > than varying numbers of fragments of characters. UTF-8 would require > > the latter. > > And then we just wait for the potential user who can't, and we'll have > this discussion all over again. > > With the disadvantage that we'll end up having to put still more > mechanisms for handling text everywhere. > > -- hendrik > > > > > > > > > > > >I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). > > >and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have > > >been superseded by SCIM, I don't know the status of uim, except that > > >it has a uim bridge. > > > > > >It does look as if SCIM > > >(http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended > > >as a simple way to interface to many other input methods, such as XIM. > > >It may be worth a look. > > > > > >--- hendrik > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sun Dec 1 09:47:37 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sun, 01 Dec 2013 08:47:37 +0000 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529A1A26.6010007@lcwb.coop> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> Message-ID: <529AF7A9.4090700@elstel.org> Am 30.11.2013 17:02, schrieb Rodney M. Bates: > > The en/decoders are available in one-code-point-per-call forms, as well > as in filters that are semantically almost identical to Wr and Rd, which > work on whole streams, with a constant encoding. The latter, in front of > TextWr/TextRd would probably make it easy to interface to any GUI library > that uses in-memory UTF-8, etc. > > It also would not be hard to make these work with 16-bit WIDECHAR, with > any input coded beyond UFFFF converted to the standard Unicode > replacement > UFFFD. It sounds like you would be unlikely to use such values. Yes, for that project I just need letters up to 0xFFFF i.e. latin-1 and -7. Currently I have copied a keyboard translation into /usr/share/X11/xkb/symbols/ that will give me greek chracters on [AltGr][Letter]. Nonetheless the current Windows implementation of the simulator suffices without such a trick because it can intercept the [AltGr] keystrokes. I have not evaluated yet whether the current VBT input form would allow a similar mechanism. > > How soon do you need to start? It would be good if that was available until January so that I can approach to finish my work until February. Fortunately there is some work which I could do in advance at least if the interfaces should not change radically. At least I should have some result at the beginning of March. Thanks for your effort, Elmar From dragisha at m3w.org Sun Dec 1 17:40:26 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Dec 2013 17:40:26 +0100 Subject: [M3devel] UTF-16: Greek alphabet with CM3 In-Reply-To: References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com>, , <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org>, <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org>, <529A17DC.3080906@lcwb.coop>, <20131130172906.GA28372@topoi.pooq.com>, <529A43B3.2090803@lcwb.coop>, <20131201001621.GA2374@topoi.pooq.com> Message-ID: And is only alive operating system, apart from Windows Phone OS (?), doing it with 16bit WCHAR? On 01 Dec 2013, at 03:01, Jay K wrote: > Windows is localized to and runs well with very many languages, using 16bit WCHAR.. > > - Jay > > > > Date: Sat, 30 Nov 2013 19:16:21 -0500 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > > > On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: > > > > > > > > > On 11/30/2013 11:29 AM, Hendrik Boom wrote: > > > >On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: > > > >>Another devilish detail to be aware of: UTF-16 is _not_ the same as > > > >>the current Modula-3 16-bit WIDECHAR, even when restricted to values > > > >><= 16_FFFF. Current Wr/Rd library code just writes/reads > > > >>exactly 16 bits in two bytes, with whatever code point is in the > > > >>WIDECHAR variable. > > > >> > > > >>In contrast, UTF-16 will encode code points greater than > > > >>UFFFF as a pair of 16-bit code units with surrogate values in them. > > > >>Then to make this work right, the surrogate values are not > > > >>allowed in unencoded variables. So attempting to encode a surrogate > > > >>in UTF-16 is an error, and decoding a surrogate that is not part of a > > > >>proper first-surrogate/second-surrogate pair is "ill formed" and usually > > > >>decodes to UFFFD. > > > >> > > > >>You could get by with treating these as interchangeable only be being > > > >>careful to ensure there is never either a surrogate code nor a code > > > >>point > UFFFF, in either input or output. > > > >> > > > >>Also, current Wr/Rd always write/read only in little-endian byte order, > > > >>whereas there are both little- and big-endian variants of UTF-16. > > > >>I have no idea which endianness of UTF-16 is used by various GUI > > > >>libraries, but it would have to be little for this to work. > > > > > > > >It lools as if one might as well use UTF-8 if one is going to consider UTF-16. > > > > > > Hmm. Actually, *if* one could live with the restrictions on values above, > > > passing the same strings back and forth, with the GUI considering them UTF-16LE > > > and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have > > > the advantage that the M3 app code could deal naturally in characters, rather > > > than varying numbers of fragments of characters. UTF-8 would require > > > the latter. > > > > And then we just wait for the potential user who can't, and we'll have > > this discussion all over again. > > > > With the disadvantage that we'll end up having to put still more > > mechanisms for handling text everywhere. > > > > -- hendrik > > > > > > > > > > > > > > > > > >I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). > > > >and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have > > > >been superseded by SCIM, I don't know the status of uim, except that > > > >it has a uim bridge. > > > > > > > >It does look as if SCIM > > > >(http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended > > > >as a simple way to interface to many other input methods, such as XIM. > > > >It may be worth a look. > > > > > > > >--- hendrik > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rodney_bates at lcwb.coop Sun Dec 1 19:01:21 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 01 Dec 2013 12:01:21 -0600 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131201001621.GA2374@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> <20131130172906.GA28372@topoi.pooq.com> <529A43B3.2090803@lcwb.coop> <20131201001621.GA2374@topoi.pooq.com> Message-ID: <529B7971.3080303@lcwb.coop> On 11/30/2013 06:16 PM, Hendrik Boom wrote: > On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: >> >> >> On 11/30/2013 11:29 AM, Hendrik Boom wrote: >>> On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: >>>> Another devilish detail to be aware of: UTF-16 is _not_ the same as >>>> the current Modula-3 16-bit WIDECHAR, even when restricted to values >>>> <= 16_FFFF. Current Wr/Rd library code just writes/reads >>>> exactly 16 bits in two bytes, with whatever code point is in the >>>> WIDECHAR variable. >>>> >>>> In contrast, UTF-16 will encode code points greater than >>>> UFFFF as a pair of 16-bit code units with surrogate values in them. >>>> Then to make this work right, the surrogate values are not >>>> allowed in unencoded variables. So attempting to encode a surrogate >>>> in UTF-16 is an error, and decoding a surrogate that is not part of a >>>> proper first-surrogate/second-surrogate pair is "ill formed" and usually >>>> decodes to UFFFD. >>>> >>>> You could get by with treating these as interchangeable only be being >>>> careful to ensure there is never either a surrogate code nor a code >>>> point > UFFFF, in either input or output. >>>> >>>> Also, current Wr/Rd always write/read only in little-endian byte order, >>>> whereas there are both little- and big-endian variants of UTF-16. >>>> I have no idea which endianness of UTF-16 is used by various GUI >>>> libraries, but it would have to be little for this to work. >>> >>> It lools as if one might as well use UTF-8 if one is going to consider UTF-16. >> >> Hmm. Actually, *if* one could live with the restrictions on values above, >> passing the same strings back and forth, with the GUI considering them UTF-16LE >> and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have >> the advantage that the M3 app code could deal naturally in characters, rather >> than varying numbers of fragments of characters. UTF-8 would require >> the latter. > > And then we just wait for the potential user who can't, and we'll have > this discussion all over again. > > With the disadvantage that we'll end up having to put still more > mechanisms for handling text everywhere. > > -- hendrik > > Yes, I agree completely, in general. I should have stated that, with that idea, I was thinking specifically of Elmar's problem. >> >> >>> >>> I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). >>> and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have >>> been superseded by SCIM, I don't know the status of uim, except that >>> it has a uim bridge. >>> >>> It does look as if SCIM >>> (http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended >>> as a simple way to interface to many other input methods, such as XIM. >>> It may be worth a look. >>> >>> --- hendrik >>> >>> >> > From dragisha at m3w.org Sun Dec 1 20:07:23 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Dec 2013 20:07:23 +0100 Subject: [M3devel] UTF-16: Greek alphabet with CM3 In-Reply-To: <20131201001621.GA2374@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> <20131130172906.GA28372@topoi.pooq.com> <529A43B3.2090803@lcwb.coop> <20131201001621.GA2374@topoi.pooq.com> Message-ID: <4326B57A-DEC7-4218-AC6C-BCEC4EE0CD59@m3w.org> Problem with Unicode is multiplied with a fact how most users never really dealt with international fonts. People are usually not so good at solving problems they never really felt. My mothers tongue, OTOH, is written in two scripts and Unicode is only way to cover all of it. All Western European languages and most European and near-European languages are covered with single ISO-8859-x 8-bit sets. My language needs two of these - ISO-8859-2 for Latin script, and and ISO-8859-5 for Cyrillic one. Also, I don?t think fixed bitwidth of characters is crucial, as we can cover all uses with good abstraction. Maybe like this one. (* (C) 2013 Dragi?a Duri?, dragisha at m3w.org *) INTERFACE UTF8; IMPORT RefSeq; (* UTF8.T is a subtype of TEXT, and it is also a UTF8 encoded Unicode string. *) TYPE Char = CARDINAL; T <: Public; Public = TEXT OBJECT METHODS init(t: TEXT): T; isValid(): BOOLEAN; (* so I can do all this without exceptions *) length(): CARDINAL; (* in glyphs *) byteSize(): CARDINAL; (* in CHARs/bytes *) empty(): BOOLEAN; (* shorter than ".length() = 0" *) (* hash(): Word.T; No need for this neither here nor at all. Text.Hash would be good enough, when I come to this. *) sub(start: CARDINAL; length: CARDINAL := LAST(CARDINAL)): T; getText(start: CARDINAL := 0; length: CARDINAL := LAST(CARDINAL)): TEXT; getChar(pos: CARDINAL): Char; setChars(VAR a: ARRAY OF Char); pos(pat: T; start: CARDINAL := 0): INTEGER; (* Uses Boyer-Moore [1] for fast search, Observations 1 & 2 are currently implemented. [1] Boyer, Robert S.; Moore, J Strother (October 1977). "A Fast String Searching Algorithm.". Comm. ACM (New York, NY, USA: Association for Computing Machinery) 20 (10): 762?772. *) findChar(ch: Char; start: CARDINAL := 0): INTEGER; findCharR(ch: Char; start: CARDINAL := LAST(CARDINAL)): INTEGER; (* findChar returns first position of ch to the right from start position, or start if ch is there. findCharR returns first position of ch to the left from start position, excluding start position. *) iterate(start: CARDINAL := 0; steps: CARDINAL := LAST(CARDINAL)): Iterator; END; (* All positional/count/length parameters for methods are in Unicode glyphs *) Iterator <: PublicIterator; PublicIterator = OBJECT METHODS next(VAR char: Char): BOOLEAN; (* TODO prev? *) END; (* Construction *) PROCEDURE New(t: TEXT): T; PROCEDURE Cat(u, t: T): T; PROCEDURE FromChars(READONLY chars: ARRAY OF Char): T; PROCEDURE FromCHARArray(VAR chars: ARRAY OF CHAR): T; (* Validation. Checks both NIL value, and invalid UTF8 string. *) PROCEDURE IsValid(t: T): BOOLEAN; (* Comparation/ordering *) PROCEDURE Equal(u, t: T): BOOLEAN; PROCEDURE Compare(t1, t2: T): [-1..1]; (* Future UTF8Ops, here for now: *) PROCEDURE EscapeS(t, s: T; escapeWith: CHAR := '\134'): T; PROCEDURE UnEscape(t: T; esc: CHAR := '\134'): T; PROCEDURE SplitS(t, s: T; skipSucc: BOOLEAN := TRUE): RefSeq.T; (* Treating escaped chars like normal ones. We need to define semantics for special treatment Fri Apr 19 12:00 2013: For now, I only implement skipSucc=TRUE case. *) PROCEDURE RemoveSpaces(t: T): T; PROCEDURE Caps(t: T): T; (* This is probably titlecase in Unicode-speak. CHECK. Also, see what happend with Lows() in case we treat titlecase *) PROCEDURE Lows(t: T): T; END UTF8. On 01 Dec 2013, at 01:16, Hendrik Boom wrote: > On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: >> >> >> On 11/30/2013 11:29 AM, Hendrik Boom wrote: >>> On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: >>>> Another devilish detail to be aware of: UTF-16 is _not_ the same as >>>> the current Modula-3 16-bit WIDECHAR, even when restricted to values >>>> <= 16_FFFF. Current Wr/Rd library code just writes/reads >>>> exactly 16 bits in two bytes, with whatever code point is in the >>>> WIDECHAR variable. >>>> >>>> In contrast, UTF-16 will encode code points greater than >>>> UFFFF as a pair of 16-bit code units with surrogate values in them. >>>> Then to make this work right, the surrogate values are not >>>> allowed in unencoded variables. So attempting to encode a surrogate >>>> in UTF-16 is an error, and decoding a surrogate that is not part of a >>>> proper first-surrogate/second-surrogate pair is "ill formed" and usually >>>> decodes to UFFFD. >>>> >>>> You could get by with treating these as interchangeable only be being >>>> careful to ensure there is never either a surrogate code nor a code >>>> point > UFFFF, in either input or output. >>>> >>>> Also, current Wr/Rd always write/read only in little-endian byte order, >>>> whereas there are both little- and big-endian variants of UTF-16. >>>> I have no idea which endianness of UTF-16 is used by various GUI >>>> libraries, but it would have to be little for this to work. >>> >>> It lools as if one might as well use UTF-8 if one is going to consider UTF-16. >> >> Hmm. Actually, *if* one could live with the restrictions on values above, >> passing the same strings back and forth, with the GUI considering them UTF-16LE >> and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have >> the advantage that the M3 app code could deal naturally in characters, rather >> than varying numbers of fragments of characters. UTF-8 would require >> the latter. > > And then we just wait for the potential user who can't, and we'll have > this discussion all over again. > > With the disadvantage that we'll end up having to put still more > mechanisms for handling text everywhere. > > -- hendrik > > >> >> >>> >>> I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). >>> and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have >>> been superseded by SCIM, I don't know the status of uim, except that >>> it has a uim bridge. >>> >>> It does look as if SCIM >>> (http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended >>> as a simple way to interface to many other input methods, such as XIM. >>> It may be worth a look. >>> >>> --- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From estellnb at elstel.org Sun Dec 1 20:26:21 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sun, 01 Dec 2013 19:26:21 +0000 Subject: [M3devel] VBT and up to date desktop styling Message-ID: <529B8D5D.9080306@elstel.org> As the VBT standard interface does only offer black and white user interface styling I would need to use vbtkit to achieve at least a Windows 3.1 similar user interface. However as I have found out some of the classes in vbtkit required just for the main menu have not been completed and do not compile yet. Would someone be ready to invest some time and affection to complete these classes? To make MainMenu.m3 look good at least the following tasks would have to be done: * AnchorSwitchVBT: to be completed, 3D reflection for the anchors of the popup menus in the main menu * ShadowedBarVBT: is here but does not seem to work: it should display a horizontal bar in one of the popup menus * ShadowVBT: to be completed: draw a 3D border around popup menus and other items * Shadow: have a third color besides background and foreground for the flat style: eliminate the white borders in non-hover mode * adjust the vbtkit menu so that the popup menus stays open if the mouse button is released; this will also be necessary to make sub-menus of popup-menus work; i.e. let popup menus contain AnchorSwitchVBTs * evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs shadows appear to be larger in their horizontal extent by now compared to their vertical extent which is not that good to look at * and likely some other issues I have not discovered yet Considering all of that if I will not have an extended vbtkit interfacing with another GUI component like GTK would likely be the way to go because otherwise there would simply be too much time to be invested into vbtkit not considering underlying Trestle problems like Unicode support yet. Though it would be good to have a well working standard GUI interface for Modula-3 we need to consider now if putting further work into Trestle/vbtkit is still worth to do. If so I believe it would require a joint effort. -------------- next part -------------- MODULE MainMenu EXPORTS Main; IMPORT TextVBT, RigidVBT, HVSplit, VBT, Split, Axis, Trestle, TrestleComm, Thread; IMPORT MenuSwitchVBT, (* AnchorSwitchVBT, *) AnchorBtnVBT, ButtonVBT; IMPORT Shadow, ShadowedFeedbackVBT, ShadowedBarVBT (*, ShadowVBT*), BorderedVBT; IMPORT Wr,Stdio; FROM VBTStyle IMPORT gray, black, blackongray, shadow; <*FATAL TrestleComm.Failure*> <*FATAL Wr.Failure*> <*FATAL Thread.Alerted*> TYPE MenuItemProc = PROCEDURE (v: MenuSwitch; READONLY cd: VBT.MouseRec); MenuSwitch = MenuSwitchVBT.T OBJECT callbackproc : MenuItemProc OVERRIDES callback := MenuSwitchCallbackWrapper; END; PROCEDURE MenuSwitchCallbackWrapper(v: MenuSwitch; READONLY cd:VBT.MouseRec) = BEGIN v.callbackproc(v,cd) END MenuSwitchCallbackWrapper; PROCEDURE AddMenuItem( menu: Split.T; item: TEXT; action: MenuItemProc ) = VAR feedback, menuswitch : VBT.T; BEGIN feedback := ShadowedFeedbackVBT.NewMenu( TextVBT.New( item, bgFg:=blackongray ), shadow ); menuswitch := NEW(MenuSwitch, callbackproc:= action).init(feedback); Split.AddChild(menu,menuswitch); END AddMenuItem; PROCEDURE AddHorizontalBar( menu: Split.T ) = BEGIN Split.AddChild(menu, NEW(ShadowedBarVBT.T).init( Axis.T.Hor, shadow, Shadow.Style.Chiseled ) ); END AddHorizontalBar; PROCEDURE AddSubMenu( menu: Split.T; item: TEXT; submenu: HVSplit.T ) = VAR feedback, anchorbutn : VBT.T; BEGIN feedback := NEW(ShadowedFeedbackVBT.T).init( ch:=TextVBT.New( item, bgFg:=blackongray ), shadow:=shadow, offStyle:=Shadow.Style.Flat, onStyle:=Shadow.Style.Lowered ,onExcitedStyle:=Shadow.Style.Lowered ); (* anchorbutn := AnchorBtnVBT.New( ch:=feedback, menu:= NEW(ShadowVBT.T, submenu, shadow, Shadow.Style.Raised ); *) anchorbutn := AnchorBtnVBT.New( ch:=feedback, menu:=BorderedVBT.New( submenu, 0.2, black ) ); Split.AddChild( menu, anchorbutn ); END AddSubMenu; VAR main, menu : VBT.T; VAR mainmenu, popup1, popup2, popup3 : Split.T; PROCEDURE Cut (<*UNUSED*>v: MenuSwitch; <*UNUSED*>READONLY cd: VBT.MouseRec) = BEGIN Wr.PutText(Stdio.stdout, "Cut\n"); Wr.Flush(Stdio.stdout); END Cut; PROCEDURE Paste (<*UNUSED*>v: MenuSwitch; <*UNUSED*>READONLY cd: VBT.MouseRec) = BEGIN Wr.PutText(Stdio.stdout, "Paste\n"); Wr.Flush(Stdio.stdout); END Paste; PROCEDURE Exit (<*UNUSED*>v: MenuSwitch; <*UNUSED*>READONLY cd: VBT.MouseRec) = BEGIN Trestle.Delete(main); END Exit; BEGIN popup1 := HVSplit.New(Axis.T.Ver); AddMenuItem(popup1, "Open", Cut); AddHorizontalBar(popup1); AddMenuItem(popup1, "Exit", Exit); popup3 := HVSplit.New(Axis.T.Ver); AddMenuItem(popup3, "SubCut", Cut); AddMenuItem(popup3, "SubPaste", Paste); (*popup2 := HVSplit.New(Axis.T.Ver); *) popup2 := HVSplit.New(Axis.T.Ver); AddMenuItem(popup2, "Cut", Cut); AddMenuItem(popup2, "Paste", Paste); AddSubMenu(popup2, "File", popup3); (* mainmenu := HVSplit.New(Axis.T.Hor); *) mainmenu := ButtonVBT.MenuBar( op:=gray ); AddSubMenu(mainmenu, "File", popup1); AddSubMenu(mainmenu, "Edit", popup2); AddMenuItem(mainmenu, "Exit", Exit); Split.AddChild(mainmenu,NEW(VBT.Leaf)); menu := mainmenu; main := HVSplit.Cons( Axis.T.Ver, menu, RigidVBT.FromHV( TextVBT.New("xxxxxx"), 100.0, 80.0 ) ); Trestle.Install(main); Trestle.AwaitDelete(main); END MainMenu. -------------- next part -------------- INTERFACE VBTStyle; IMPORT PaintOp, Shadow, Pixmap; VAR lgray, gray, dgray, black : PaintOp.T; blackongray : PaintOp.ColorQuad; shadow : Shadow.T; graytxt : Pixmap.T; END VBTStyle. -------------- next part -------------- MODULE VBTStyle; IMPORT PaintOp, Shadow; BEGIN lgray := PaintOp.FromRGB(0.9, 0.9, 0.9); gray := PaintOp.FromRGB(0.8, 0.8, 0.8); dgray := PaintOp.FromRGB(0.7, 0.7, 0.7); black := PaintOp.FromRGB(0.0, 0.0, 0.0); blackongray := PaintOp.MakeColorQuad( bg:= gray, fg:= black ); shadow := Shadow.New( size:= 1.0, light:= lgray, dark:= dgray ); END VBTStyle. From estellnb at elstel.org Sun Dec 1 20:37:28 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sun, 01 Dec 2013 19:37:28 +0000 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529B7CB3.2060602@lcwb.coop> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> <529B7CB3.2060602@lcwb.coop> Message-ID: <529B8FF8.4090708@elstel.org> Am 01.12.2013 18:15, schrieb Rodney M. Bates: > > > On 12/01/2013 02:47 AM, Elmar Stellnberger wrote: >> >> Am 30.11.2013 17:02, schrieb Rodney M. Bates: >>> >>> The en/decoders are available in one-code-point-per-call forms, as well >>> as in filters that are semantically almost identical to Wr and Rd, >>> which >>> work on whole streams, with a constant encoding. The latter, in >>> front of >>> TextWr/TextRd would probably make it easy to interface to any GUI >>> library >>> that uses in-memory UTF-8, etc. >>> >>> It also would not be hard to make these work with 16-bit WIDECHAR, with >>> any input coded beyond UFFFF converted to the standard Unicode >>> replacement >>> UFFFD. It sounds like you would be unlikely to use such values. >> Yes, for that project I just need letters up to 0xFFFF i.e. latin-1 >> and -7. >> Currently I have copied a keyboard translation into >> /usr/share/X11/xkb/symbols/ >> that will give me greek chracters on [AltGr][Letter]. Nonetheless the >> current >> Windows implementation of the simulator suffices without such a trick >> because >> it can intercept the [AltGr] keystrokes. I have not evaluated yet >> whether the >> current VBT input form would allow a similar mechanism. >>> >>> How soon do you need to start? >> It would be good if that was available until January so that I can >> approach to >> finish my work until February. Fortunately there is some work which I >> could >> do in advance at least if the interfaces should not change radically. >> At least >> I should have some result at the beginning of March. >> > > Enough of what the Unicode branch could do for you has been working > for some time. > The remaining problems are convenience/packaging things, testing of > big-endian and > mixed-endian pickles and network objects, and bootstrapping. I have > not rebootstrapped > using the release compiler in a couple of months, but I believe there > are some new > bootstrap barriers that have popped up. Also, the only backend that > is done is > the gcc-4.7-derived one, although I think that will cover the majority > of the targets. > What target are you using? AMD64_LINUX, LINUXLIBC6. However the program will need to work on windows as well. > > As for what GUI system to use, that is another question, but the > Unicode branch > would allow you to pass/receive strings in any of the encodings, yet > process > them in M3 code as simple characters, without having to mess with or > understand > the encodings. That should pretty well open up all your options on > what GUI > system to use. Also, it would make late changing to a different > encoding trivial. > Yes, I should likely check that branch out and compile it. However for the final program a stable version of it will be absolutely necessary. Then I will also have to decide whether I can use Trestle/vbtkit or whether I should try to convert a current GTK with swig. Elmar From dragisha at m3w.org Sun Dec 1 21:53:03 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Dec 2013 21:53:03 +0100 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529B8FF8.4090708@elstel.org> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> <529B7CB3.2060602@lcwb.coop> <529B8FF8.4090708@elstel.org> Message-ID: <4DAB8C65-061E-4AF0-B685-53B47B2572D0@m3w.org> Before you start with swig, take a look at this: https://dl.dropboxusercontent.com/u/60554338/m3-m3gtk2-r11929.tar.gz As usual? I do not have a time for legalese, if there is a question about licensing, it is cm3-alike. I would like to know if it's used/useful, but I give no warranty of any kind, and so on :). dd On 01 Dec 2013, at 20:37, Elmar Stellnberger wrote: > Then I will also have to decide whether I can use Trestle/vbtkit or whether I should try to > convert a current GTK with swig. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hendrik at topoi.pooq.com Sun Dec 1 23:50:30 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 1 Dec 2013 17:50:30 -0500 Subject: [M3devel] VBT and up to date desktop styling In-Reply-To: <529B8D5D.9080306@elstel.org> References: <529B8D5D.9080306@elstel.org> Message-ID: <20131201225029.GA24450@topoi.pooq.com> On Sun, Dec 01, 2013 at 07:26:21PM +0000, Elmar Stellnberger wrote: > > Considering all of that if I will not have an extended vbtkit > interfacing with another GUI component like GTK would likely be the > way to go because otherwise there would simply be too much time to > be invested into vbtkit not considering underlying Trestle problems > like Unicode support yet. Though it would be good to have a well > working standard GUI interface for Modula-3 we need to consider now > if putting further work into Trestle/vbtkit is still worth to do. If > so I believe it would require a joint effort. On the face of it, switching to a portable, language-independent user-interface library may be the way to go in the long run. I don't see any reason why the use of Modula 3 should require a different user interface library from the rest of the world, unless, of course the other libraries are crucially unsuitable or have unportable interfaces. In the dark ages, Modula-3 ended up with its own UI library because all UI libraries were hopelessly OS-specific. Yuo even had to rewrite your code for different versios of an OS. There *are* now some portable user-interface libraries. Aren't GTK and Qt candidates for this? Tough I'm not sure just how portable these are. The trouble with these are that they seem to keep coming up with new, incompatible versions, so maintaining the interfaces and client software might be a neverending activity. But there seems to be substantial transition periods between, say, GTK2 and GTK3 when both are available, so that may noot be too terrible. Has anyone done anything towards GTK or Qt bindings for Modula 3? -- hendrik From dmuysers at hotmail.com Sun Dec 1 23:56:18 2013 From: dmuysers at hotmail.com (dirk muysers) Date: Sun, 1 Dec 2013 23:56:18 +0100 Subject: [M3devel] VBT and up to date desktop styling In-Reply-To: <20131201225029.GA24450@topoi.pooq.com> References: <529B8D5D.9080306@elstel.org> <20131201225029.GA24450@topoi.pooq.com> Message-ID: IUP (http://www.tecgraf.puc-rio.br/iup/) is the easiest to interface to from a Modula-3 point of view. -----Original Message----- From: Hendrik Boom Sent: Sunday, December 01, 2013 11:50 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] VBT and up to date desktop styling On Sun, Dec 01, 2013 at 07:26:21PM +0000, Elmar Stellnberger wrote: > > Considering all of that if I will not have an extended vbtkit > interfacing with another GUI component like GTK would likely be the > way to go because otherwise there would simply be too much time to > be invested into vbtkit not considering underlying Trestle problems > like Unicode support yet. Though it would be good to have a well > working standard GUI interface for Modula-3 we need to consider now > if putting further work into Trestle/vbtkit is still worth to do. If > so I believe it would require a joint effort. On the face of it, switching to a portable, language-independent user-interface library may be the way to go in the long run. I don't see any reason why the use of Modula 3 should require a different user interface library from the rest of the world, unless, of course the other libraries are crucially unsuitable or have unportable interfaces. In the dark ages, Modula-3 ended up with its own UI library because all UI libraries were hopelessly OS-specific. Yuo even had to rewrite your code for different versios of an OS. There *are* now some portable user-interface libraries. Aren't GTK and Qt candidates for this? Tough I'm not sure just how portable these are. The trouble with these are that they seem to keep coming up with new, incompatible versions, so maintaining the interfaces and client software might be a neverending activity. But there seems to be substantial transition periods between, say, GTK2 and GTK3 when both are available, so that may noot be too terrible. Has anyone done anything towards GTK or Qt bindings for Modula 3? -- hendrik From dabenavidesd at yahoo.es Mon Dec 2 00:19:32 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 1 Dec 2013 23:19:32 +0000 (GMT) Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529AF7A9.4090700@elstel.org> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> Message-ID: <1385939972.4774.YahooMailNeo@web171902.mail.ir2.yahoo.com> Hi all: another turn around solution for this is to use the qt port developed by by Peter Mckinna. I'm interested in the event Model and signal and slot system, perhaps Peter can guide us through where it is now and where it should be. This will give us free access menu and buttons style in either Win or U*ix platforms. Personally I will base my further developments In Qt, trestle is a small toolkit developed by super minds, but honestly we don't have too much of a parallel system to gain much of its features. Thanks in advance El Domingo 1 de diciembre de 2013 3:47, Elmar Stellnberger escribi?: Am 30.11.2013 17:02, schrieb Rodney M. Bates: > > The en/decoders are available in one-code-point-per-call forms, as well > as in filters that are semantically almost identical to Wr and Rd, which > work on whole streams, with a constant encoding.? The latter, in front of > TextWr/TextRd would probably make it easy to interface to any GUI library > that uses in-memory UTF-8, etc. > > It also would not be hard to make these work with 16-bit WIDECHAR, with > any input coded beyond UFFFF converted to the standard Unicode > replacement > UFFFD.? It sounds like you would be unlikely to use such values. Yes, for that project I just need letters up to 0xFFFF i.e. latin-1 and -7. Currently I have copied a keyboard translation into /usr/share/X11/xkb/symbols/ that will give me greek chracters on [AltGr][Letter]. Nonetheless the current Windows implementation of the simulator suffices without such a trick because it can intercept the [AltGr] keystrokes. I have not evaluated yet whether the current VBT input form would allow a similar mechanism. > > How soon do you need to start? It would be good if that was available until January so that I can approach to finish my work until February. Fortunately there is some work which I could do in advance at least if the interfaces should not change radically. At least I should have some result at the beginning of March. Thanks for your effort, Elmar -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Dec 2 01:19:20 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 1 Dec 2013 19:19:20 -0500 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <1385939972.4774.YahooMailNeo@web171902.mail.ir2.yahoo.com> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> <1385939972.4774.YahooMailNeo@web171902.mail.ir2.yahoo.com> Message-ID: <20131202001920.GA25527@topoi.pooq.com> On Sun, Dec 01, 2013 at 11:19:32PM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > another turn around solution for this is to use the qt port developed > by by Peter Mckinna. I'm interested in the event Model and signal and > slot system, perhaps Peter can guide us through where it is now and > where it should be. This will give us free access menu and buttons > style in either Win or U*ix platforms. So Qt is now portable between OS's? Does it cover Mac, too? > Personally I will base my > further developments > In Qt, trestle is a small toolkit developed by > Not sure what you mean by trestle in Qt. super minds, but honestly we don't have too much of a parallel system A parallel system? > to gain much of its features. -- hendrik k From jay.krell at cornell.edu Sun Dec 1 21:33:53 2013 From: jay.krell at cornell.edu (Jay) Date: Sun, 1 Dec 2013 12:33:53 -0800 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: References: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> Message-ID: <1AB94F78-FE03-43D6-8F56-D6974C480E92@gmail.com> A lot of code within Windows uses WCHAR all the time. The kernel interfaces all accept only WCHAR (and a 16 bit length of bytes). FAT32, NTFS, registry all store 16bit WCHAR, at least when 7bits don't suffice. Trestle surely will remain with Xlib & Win32. New code...Qt? - Jay On Nov 30, 2013, at 2:52 AM, Dragi?a Duri? wrote: > And yes, Cairo uses UTF-8 natively, even on Windows. > > On 30 Nov 2013, at 11:41, Dragi?a Duri? wrote: > >> Are we really sure about this Xlib interfacing? >> >> There are several very-low-level and very-portable libraries right now. Why don?t we use Cairo? >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 30 Nov 2013, at 10:06, Jay K wrote: >> >>> 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? >>> 2) Are we really certain that redefining WIDECHAR is the way to go? >>> Not, say, introduce a new time, CHAR32 or UCHAR32? >>> And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? >>> >>> Or do people now advocate: >>> get rid of WIDECHAR >>> leave 8 bit CHAR >>> with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? >>> ?? >>> >>> Thank you, >>> - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 1 23:35:50 2013 From: jay.krell at cornell.edu (Jay) Date: Sun, 1 Dec 2013 14:35:50 -0800 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: <1AB94F78-FE03-43D6-8F56-D6974C480E92@gmail.com> References: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> <1AB94F78-FE03-43D6-8F56-D6974C480E92@gmail.com> Message-ID: <5D37F47A-AF27-47F6-95F6-9C91C26A076E@gmail.com> Sorry sent too soon. Windows is basically WCHAR everywhere except at boundaries that must accept multiple encodings... - Jay On Dec 1, 2013, at 12:33 PM, Jay wrote: > A lot of code within Windows uses WCHAR all the time. The kernel interfaces all accept only WCHAR (and a 16 bit length of bytes). FAT32, NTFS, registry all store 16bit WCHAR, at least when 7bits don't suffice. > > > Trestle surely will remain with Xlib & Win32. New code...Qt? > > > - Jay > > On Nov 30, 2013, at 2:52 AM, Dragi?a Duri? wrote: > >> And yes, Cairo uses UTF-8 natively, even on Windows. >> >> On 30 Nov 2013, at 11:41, Dragi?a Duri? wrote: >> >>> Are we really sure about this Xlib interfacing? >>> >>> There are several very-low-level and very-portable libraries right now. Why don?t we use Cairo? >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 30 Nov 2013, at 10:06, Jay K wrote: >>> >>>> 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? >>>> 2) Are we really certain that redefining WIDECHAR is the way to go? >>>> Not, say, introduce a new time, CHAR32 or UCHAR32? >>>> And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? >>>> >>>> Or do people now advocate: >>>> get rid of WIDECHAR >>>> leave 8 bit CHAR >>>> with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? >>>> ?? >>>> >>>> Thank you, >>>> - Jay >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 2 04:00:13 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 2 Dec 2013 03:00:13 +0000 (GMT) Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131202001920.GA25527@topoi.pooq.com> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> <1385939972.4774.YahooMailNeo@web171902.mail.ir2.yahoo.com> <20131202001920.GA25527@topoi.pooq.com> Message-ID: <1385953213.62458.YahooMailNeo@web171906.mail.ir2.yahoo.com> Hi all: Yes, mostly portable, since long ago in Mac, I'm not sure in OS/2. I think I miss wrote, I myself will base further development In Qt, though I'm not saying Tresstle is a bad toolkit, it just not fully exploited in current systems, read that as hardware and or software, is just that. Thanks in advance El Domingo 1 de diciembre de 2013 19:19, Hendrik Boom escribi?: On Sun, Dec 01, 2013 at 11:19:32PM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > another turn around solution for this is to use the qt port developed > by by Peter Mckinna. I'm interested in the event Model and signal and > slot system, perhaps Peter can guide us through where it is now and > where it should be. This will give us free access menu and buttons > style in either Win or U*ix platforms. So Qt is now portable between OS's?? Does it cover Mac, too? > Personally I will base my > further developments > In Qt, trestle is a small toolkit developed by > Not sure what you mean by trestle in Qt. super minds, but honestly we don't have too much of a parallel system A parallel system? > to gain much of its features. -- hendrik k -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 3 22:54:27 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Dec 2013 21:54:27 +0000 Subject: [M3devel] unicode in libm3 or separate package In-Reply-To: <20131203211338.B4C655DF608@birch.elegosoft.com> References: <20131203211338.B4C655DF608@birch.elegosoft.com> Message-ID: This is not necessary, but it is ok. m3core and libm3 are never built with an older compiler and can depend on a newer compiler. - Jay > Date: Tue, 3 Dec 2013 22:13:38 +0000 > To: m3commit at elegosoft.com > From: rodney at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/12/03 22:13:38 > > Modified files: > cm3/m3-libs/libm3/src/rw/: Tag: devel_unicode m3makefile > > Log message: > Move Unicode codec stuff to its own package. This allows for > bootstrapping the unicode branch with release and head compilers. > This code depends on being compiled with Unicode-sized WIDECHAR, > which is not initially available when first compiling libm3 and > the compiler, using an earlier compiler. New package libunicode > can now be compiled later, after a new compiler is installed. > > script do-cm3-unicode.sh does everything do-cm3-front.sh does, > plus libunicode. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 4 01:56:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Dec 2013 00:56:33 +0000 Subject: [M3devel] unicode in libm3 or separate package In-Reply-To: <3EDF0150-6846-4FA6-9698-5D41E3208A59@purdue.edu> References: <20131203211338.B4C655DF608@birch.elegosoft.com> , <3EDF0150-6846-4FA6-9698-5D41E3208A59@purdue.edu> Message-ID: Huh? No they aren't. bootstrapping uses old compiler to build everything after m3core/libm3 (up to cm3) bootstrapping uses old compiler to m3front/m3back/m3quake/m3linker/cm3/sysutils, but not m3core/libm3. Then bootstrapping uses new compiler to build everything. m3core/libm3 can depend on new compiler. m3front/m3back/m3quake/m3linker/cm3/sysutils cannot (except by more than one step, then they can -- "flexibility via multiple changes") see http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/upgrade.sh?rev=1.37;content-type=text%2Fplain notice where m3core/libm3 appear. which I don't use but is possibly clearer to people and what I use was based on it (I missed that upgrade.sh actually builds everything and mine stops at cm3). - Jay Subject: Re: [M3devel] unicode in libm3 or separate package From: hosking at purdue.edu Date: Tue, 3 Dec 2013 19:13:46 -0500 CC: m3devel at elegosoft.com; rodney.bates at wichita.edu To: jay.krell at cornell.edu Huh? They are when bootstrapping. Sent from my iPhone On 3 Dec 2013, at 4:54 pm, Jay K wrote: This is not necessary, but it is ok. m3core and libm3 are never built with an older compiler and can depend on a newer compiler. - Jay > Date: Tue, 3 Dec 2013 22:13:38 +0000 > To: m3commit at elegosoft.com > From: rodney at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/12/03 22:13:38 > > Modified files: > cm3/m3-libs/libm3/src/rw/: Tag: devel_unicode m3makefile > > Log message: > Move Unicode codec stuff to its own package. This allows for > bootstrapping the unicode branch with release and head compilers. > This code depends on being compiled with Unicode-sized WIDECHAR, > which is not initially available when first compiling libm3 and > the compiler, using an earlier compiler. New package libunicode > can now be compiled later, after a new compiler is installed. > > script do-cm3-unicode.sh does everything do-cm3-front.sh does, > plus libunicode. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Wed Dec 4 04:10:03 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 4 Dec 2013 03:10:03 +0000 Subject: [M3devel] VBT and up to date desktop styling Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> Elmar: Years ago, I worked with the principals at Critical Mass to make some Trestle/VBT/VBTKit changes that would make the "look and feel" more Windows-like. I'm pretty sure I passed all these to Olaf for incorporation into the CVS repository. I developed some GUIs that looked decent at the time on Windows NT, but more work could be done to provide tighter integration. Not sure if these pics will come thru in the email, but I've pasted a few below to give you some idea of what we achieved using Trestle, VBTKit, FormsVBT, etc. Of course, at that time, our primary motivation was to have one set of GUI code that worked on multiple platforms and gave same look and feel, so tight integration with the underlying OS was not the driving concern. Our code ran well and provided same look and feel on both HP-UX and Windows. [cid:image002.jpg at 01CEF074.68ECE030] [cid:image006.png at 01CEF073.CD228560] [cid:image007.png at 01CEF072.F125B000] [cid:image003.jpg at 01CEF074.68ECE030] Thanks, Randy Coleburn -----Original Message----- From: Elmar Stellnberger [mailto:estellnb at elstel.org] Sent: Sunday, December 01, 2013 2:26 PM To: m3devel Subject: EXT:[M3devel] VBT and up to date desktop styling As the VBT standard interface does only offer black and white user interface styling I would need to use vbtkit to achieve at least a Windows 3.1 similar user interface. However as I have found out some of the classes in vbtkit required just for the main menu have not been completed and do not compile yet. Would someone be ready to invest some time and affection to complete these classes? To make MainMenu.m3 look good at least the following tasks would have to be done: * AnchorSwitchVBT: to be completed, 3D reflection for the anchors of the popup menus in the main menu * ShadowedBarVBT: is here but does not seem to work: it should display a horizontal bar in one of the popup menus * ShadowVBT: to be completed: draw a 3D border around popup menus and other items * Shadow: have a third color besides background and foreground for the flat style: eliminate the white borders in non-hover mode * adjust the vbtkit menu so that the popup menus stays open if the mouse button is released; this will also be necessary to make sub-menus of popup-menus work; i.e. let popup menus contain AnchorSwitchVBTs * evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs shadows appear to be larger in their horizontal extent by now compared to their vertical extent which is not that good to look at * and likely some other issues I have not discovered yet Considering all of that if I will not have an extended vbtkit interfacing with another GUI component like GTK would likely be the way to go because otherwise there would simply be too much time to be invested into vbtkit not considering underlying Trestle problems like Unicode support yet. Though it would be good to have a well working standard GUI interface for Modula-3 we need to consider now if putting further work into Trestle/vbtkit is still worth to do. If so I believe it would require a joint effort. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 51415 bytes Desc: image007.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 47526 bytes Desc: image006.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 57950 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 106584 bytes Desc: image003.jpg URL: From jay.krell at cornell.edu Wed Dec 4 18:52:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Dec 2013 17:52:57 +0000 Subject: [M3devel] VBT and up to date desktop styling In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Randy, definitely at least some of your changes got in. For example, see: https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-ui/vbtkit/src/lego/WIN32/ The changes involved forking large files to make small changes, and apparent bugs resulted as the files drifted apart. There are Qt bindings in the tree now. I haven't tried them yet. Qt is probably the way to go. The challenge in all this is coming up with the right abstraction or adopting the correct existing abstraction. In the language we have a "record". This turns out to be very portable. All processors and intermediate representations support it, or will be force of existing practise throughout the software industry (i.e. C has structs, therefore structs and anything resembling them shall always work efficiently). Then, what is the right abstraction for a GUI library? What will always be "easy enough" to implement on hardware or on top of other libraries? And, how far down do we implement and meet the next layer? Is the next layer a video buffer? Or a high level library? Or generating html for "complete reinterpretation"? A thin stateless wrapper where someone else does 99.9% of the work? And then implementing our part of it. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Wed, 4 Dec 2013 03:10:03 +0000 Subject: Re: [M3devel] VBT and up to date desktop styling Elmar: Years ago, I worked with the principals at Critical Mass to make some Trestle/VBT/VBTKit changes that would make the ?look and feel? more Windows-like. I'm pretty sure I passed all these to Olaf for incorporation into the CVS repository. I developed some GUIs that looked decent at the time on Windows NT, but more work could be done to provide tighter integration. Not sure if these pics will come thru in the email, but I've pasted a few below to give you some idea of what we achieved using Trestle, VBTKit, FormsVBT, etc. Of course, at that time, our primary motivation was to have one set of GUI code that worked on multiple platforms and gave same look and feel, so tight integration with the underlying OS was not the driving concern. Our code ran well and provided same look and feel on both HP-UX and Windows. Thanks, Randy Coleburn -----Original Message----- From: Elmar Stellnberger [mailto:estellnb at elstel.org] Sent: Sunday, December 01, 2013 2:26 PM To: m3devel Subject: EXT:[M3devel] VBT and up to date desktop styling As the VBT standard interface does only offer black and white user interface styling I would need to use vbtkit to achieve at least a Windows 3.1 similar user interface. However as I have found out some of the classes in vbtkit required just for the main menu have not been completed and do not compile yet. Would someone be ready to invest some time and affection to complete these classes? To make MainMenu.m3 look good at least the following tasks would have to be done: * AnchorSwitchVBT: to be completed, 3D reflection for the anchors of the popup menus in the main menu * ShadowedBarVBT: is here but does not seem to work: it should display a horizontal bar in one of the popup menus * ShadowVBT: to be completed: draw a 3D border around popup menus and other items * Shadow: have a third color besides background and foreground for the flat style: eliminate the white borders in non-hover mode * adjust the vbtkit menu so that the popup menus stays open if the mouse button is released; this will also be necessary to make sub-menus of popup-menus work; i.e. let popup menus contain AnchorSwitchVBTs * evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs shadows appear to be larger in their horizontal extent by now compared to their vertical extent which is not that good to look at * and likely some other issues I have not discovered yet Considering all of that if I will not have an extended vbtkit interfacing with another GUI component like GTK would likely be the way to go because otherwise there would simply be too much time to be invested into vbtkit not considering underlying Trestle problems like Unicode support yet. Though it would be good to have a well working standard GUI interface for Modula-3 we need to consider now if putting further work into Trestle/vbtkit is still worth to do. If so I believe it would require a joint effort. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 51415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 47526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 57950 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 106584 bytes Desc: not available URL: From rodney_bates at lcwb.coop Tue Dec 10 18:59:54 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 10 Dec 2013 11:59:54 -0600 Subject: [M3devel] Fwd: Re: unicode in libm3 or separate package In-Reply-To: <529FE6A9.9070404@lcwb.coop> References: <529FE6A9.9070404@lcwb.coop> Message-ID: <52A7569A.9000600@lcwb.coop> 4th try repost: -------- Original Message -------- Subject: Re: [M3devel] unicode in libm3 or separate package Date: Wed, 04 Dec 2013 20:36:25 -0600 From: Rodney M. Bates To: m3devel at elegosoft.com Different meanings and procedures for bootstrapping. I am trying to ensure somebody without a previous M3 distribution can check one out, then build it with a binary only of the release compiler (e.g., via cminstall). I have not been using upgrade.sh, because it alters your /usr/local/cm3 in place, overlaying the original. This is not very handy for repeated experiments, when I have to keep recreating it. It will build though, with the dependencies in question. Instead, I have been using do-pkg.sh and do-cm3-*.sh. These, by default, use -override, which builds everything in the cvs checkout and leaves /usr/local/cm3 alone. In this case, trying to build a compiler first has no m3core or libm3 available, while building a library that depends on the newer compiler also fails. The separation I did allows this by getting code that an older compiler won't build into a separate package, where it can be done later. Unfortunately, it also means you can't just ship later, after all goes well. On 12/03/2013 06:56 PM, Jay K wrote: > Huh? No they aren't. > > > > bootstrapping uses old compiler to build everything /after /m3core/libm3 (up to cm3) > bootstrapping uses old compiler to m3front/m3back/m3quake/m3linker/cm3/sysutils, but not m3core/libm3. > Then bootstrapping uses new compiler to build everything. > > > m3core/libm3 can depend on new compiler. > m3front/m3back/m3quake/m3linker/cm3/sysutils cannot (except by more than one step, then they can -- "flexibility via multiple changes") > > > see > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/upgrade.sh?rev=1.37;content-type=text%2Fplain > notice where m3core/libm3 appear. > > > which I don't use but is possibly clearer to people and what I use was based on it (I missed that upgrade.sh actually builds everything and mine stops at cm3). > > > - Jay > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > Subject: Re: [M3devel] unicode in libm3 or separate package > From: hosking at purdue.edu > Date: Tue, 3 Dec 2013 19:13:46 -0500 > CC: m3devel at elegosoft.com; rodney.bates at wichita.edu > To: jay.krell at cornell.edu > > Huh? They are when bootstrapping. > > Sent from my iPhone > > On 3 Dec 2013, at 4:54 pm, Jay K > wrote: > > This is not necessary, but it is ok. > > m3core and libm3 are never built with an older compiler and can depend on a newer compiler. > > > - Jay > > > > Date: Tue, 3 Dec 2013 22:13:38 +0000 > > To: m3commit at elegosoft.com > > From: rodney at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/12/03 22:13:38 > > > > Modified files: > > cm3/m3-libs/libm3/src/rw/: Tag: devel_unicode m3makefile > > > > Log message: > > Move Unicode codec stuff to its own package. This allows for > > bootstrapping the unicode branch with release and head compilers. > > This code depends on being compiled with Unicode-sized WIDECHAR, > > which is not initially available when first compiling libm3 and > > the compiler, using an earlier compiler. New package libunicode > > can now be compiled later, after a new compiler is installed. > > > > script do-cm3-unicode.sh does everything do-cm3-front.sh does, > > plus libunicode. > > > From jay.krell at cornell.edu Wed Dec 11 23:36:28 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 11 Dec 2013 22:36:28 +0000 Subject: [M3devel] Fwd: Re: unicode in libm3 or separate package In-Reply-To: <52A7569A.9000600@lcwb.coop> References: <529FE6A9.9070404@lcwb.coop>,<52A7569A.9000600@lcwb.coop> Message-ID: 1) That isn't supposed to work. Sometimes it does, but there is no guarantee. 2) yeah, we should fix that, make it be two steps and the second step optional Either via buildlocal + optional ship or buildship into a new location and then optionally copy. - Jay > Date: Tue, 10 Dec 2013 11:59:54 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: Re: unicode in libm3 or separate package > > 4th try repost: > > > -------- Original Message -------- > Subject: Re: [M3devel] unicode in libm3 or separate package > Date: Wed, 04 Dec 2013 20:36:25 -0600 > From: Rodney M. Bates > To: m3devel at elegosoft.com > > Different meanings and procedures for bootstrapping. I am trying to ensure somebody > without a previous M3 distribution can check one out, then build it with a binary > only of the release compiler (e.g., via cminstall). I have not been using upgrade.sh, > because it alters your /usr/local/cm3 in place, overlaying the original. This is not > very handy for repeated experiments, when I have to keep recreating it. It will build > though, with the dependencies in question. > > Instead, I have been using do-pkg.sh and do-cm3-*.sh. These, by default, use -override, > which builds everything in the cvs checkout and leaves /usr/local/cm3 alone. In this case, > trying to build a compiler first has no m3core or libm3 available, while building a > library that depends on the newer compiler also fails. The separation I did allows this > by getting code that an older compiler won't build into a separate package, where it can > be done later. Unfortunately, it also means you can't just ship later, after all goes > well. > > On 12/03/2013 06:56 PM, Jay K wrote: > > Huh? No they aren't. > > > > > > > > bootstrapping uses old compiler to build everything /after /m3core/libm3 (up to cm3) > > bootstrapping uses old compiler to m3front/m3back/m3quake/m3linker/cm3/sysutils, but not m3core/libm3. > > Then bootstrapping uses new compiler to build everything. > > > > > > m3core/libm3 can depend on new compiler. > > m3front/m3back/m3quake/m3linker/cm3/sysutils cannot (except by more than one step, then they can -- "flexibility via multiple changes") > > > > > > see > > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/upgrade.sh?rev=1.37;content-type=text%2Fplain > > notice where m3core/libm3 appear. > > > > > > which I don't use but is possibly clearer to people and what I use was based on it (I missed that upgrade.sh actually builds everything and mine stops at cm3). > > > > > > - Jay > > > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > -- > > Subject: Re: [M3devel] unicode in libm3 or separate package > > From: hosking at purdue.edu > > Date: Tue, 3 Dec 2013 19:13:46 -0500 > > CC: m3devel at elegosoft.com; rodney.bates at wichita.edu > > To: jay.krell at cornell.edu > > > > Huh? They are when bootstrapping. > > > > Sent from my iPhone > > > > On 3 Dec 2013, at 4:54 pm, Jay K > wrote: > > > > This is not necessary, but it is ok. > > > > m3core and libm3 are never built with an older compiler and can depend on a newer compiler. > > > > > > - Jay > > > > > > > Date: Tue, 3 Dec 2013 22:13:38 +0000 > > > To: m3commit at elegosoft.com > > > From: rodney at elego.de > > > Subject: [M3commit] CVS Update: cm3 > > > > > > CVSROOT: /usr/cvs > > > Changes by: rodney at birch. 13/12/03 22:13:38 > > > > > > Modified files: > > > cm3/m3-libs/libm3/src/rw/: Tag: devel_unicode m3makefile > > > > > > Log message: > > > Move Unicode codec stuff to its own package. This allows for > > > bootstrapping the unicode branch with release and head compilers. > > > This code depends on being compiled with Unicode-sized WIDECHAR, > > > which is not initially available when first compiling libm3 and > > > the compiler, using an earlier compiler. New package libunicode > > > can now be compiled later, after a new compiler is installed. > > > > > > script do-cm3-unicode.sh does everything do-cm3-front.sh does, > > > plus libunicode. > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sat Dec 14 11:45:18 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 14 Dec 2013 11:45:18 +0100 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <52AC36BE.6070309@elstel.org> Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. Would anyone mind this to fix in the main trunk? Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. How do I f.i. listen to a 'pressed' signal on a QPushButton? There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. Elmar Am 04.12.13 18:52, schrieb Jay K: > Randy, definitely at least some of your changes got in. > For example, see: > https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-ui/vbtkit/src/lego/WIN32/ > The changes involved forking large files to make small changes, and > apparent bugs resulted as the files drifted apart. > > > There are Qt bindings in the tree now. > I haven't tried them yet. > Qt is probably the way to go. > > > The challenge in all this is coming up with the right abstraction or > adopting the correct existing abstraction. > In the language we have a "record". This turns out to be very portable. > All processors and intermediate representations support it, or will be > force of existing practise throughout the software industry (i.e. C > has structs, therefore structs and anything resembling them shall > always work efficiently). > > > Then, what is the right abstraction for a GUI library? > What will always be "easy enough" to implement on hardware or on top > of other libraries? > And, how far down do we implement and meet the next layer? > Is the next layer a video buffer? Or a high level library? Or > generating html for "complete reinterpretation"? > A thin stateless wrapper where someone else does 99.9% of the work? > > > And then implementing our part of it. > > > - Jay > > ------------------------------------------------------------------------ > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Wed, 4 Dec 2013 03:10:03 +0000 > Subject: Re: [M3devel] VBT and up to date desktop styling > > Elmar: > > Years ago, I worked with the principals at Critical Mass to make some > Trestle/VBT/VBTKit changes that would make the ?look and feel? more > Windows-like. > > I'm pretty sure I passed all these to Olaf for incorporation into the > CVS repository. > > I developed some GUIs that looked decent at the time on Windows NT, > but more work could be done to provide tighter integration. > > Not sure if these pics will come thru in the email, but I've pasted a > few below to give you some idea of what we achieved using Trestle, > VBTKit, FormsVBT, etc. > > Of course, at that time, our primary motivation was to have one set of > GUI code that worked on multiple platforms and gave same look and > feel, so tight integration with the underlying OS was not the driving > concern. Our code ran well and provided same look and feel on both > HP-UX and Windows. > > Thanks, > > Randy Coleburn > > -----Original Message----- > From: Elmar Stellnberger [mailto:estellnb at elstel.org] > Sent: Sunday, December 01, 2013 2:26 PM > To: m3devel > Subject: EXT:[M3devel] VBT and up to date desktop styling > > As the VBT standard interface does only offer black and white user > interface styling I would need to use vbtkit to achieve at least a > Windows 3.1 similar user interface. However as I have found out some > of the classes in vbtkit required just for the main menu have not been > completed and do not compile yet. Would someone be ready to invest > some time and affection to complete these classes? > > To make MainMenu.m3 look good at least the following tasks would have > to be done: > > * AnchorSwitchVBT: to be completed, 3D reflection for the anchors of > the popup menus in the main menu > > * ShadowedBarVBT: is here but does not seem to work: it should display > a horizontal bar in one of the popup menus > > * ShadowVBT: to be completed: draw a 3D border around popup menus and > other items > > * Shadow: have a third color besides background and foreground for the > flat style: eliminate the white borders in non-hover mode > > * adjust the vbtkit menu so that the popup menus stays open if the > mouse button is released; this will also be necessary to make > sub-menus of popup-menus work; i.e. let popup menus contain > AnchorSwitchVBTs > > * evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs > shadows appear to be larger in their horizontal extent by now compared > to their vertical extent which is not that good to look at > > * and likely some other issues I have not discovered yet > > Considering all of that if I will not have an extended vbtkit > interfacing with another GUI component like GTK would likely be the > way to go because otherwise there would simply be too much time to be > invested into vbtkit not considering underlying Trestle problems like > Unicode support yet. Though it would be good to have a well working > standard GUI interface for Modula-3 we need to consider now if putting > further work into Trestle/vbtkit is still worth to do. If so I believe > it would require a joint effort. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 57950 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 47526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 51415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 106584 bytes Desc: not available URL: From dabenavidesd at yahoo.es Sat Dec 14 21:31:58 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 14 Dec 2013 20:31:58 +0000 (GMT) Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52AC36BE.6070309@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> <52AC36BE.6070309@elstel.org> Message-ID: <1387053118.25449.YahooMailNeo@web171902.mail.ir2.yahoo.com> Hi all, not me, but somebody was happily (well almost) compiling 200k lines of Modula-3 from Qt headers some months ago. But I don't know how to browse in that page, I'm openly against new UI in web pages :), are just too crazy, maybe I'm just too old for that technology. Can you help to contact demoitem guy: https://github.com/swig/swig/pull/84 Thanks in advance El S?bado 14 de diciembre de 2013 5:45, Elmar Stellnberger escribi?: Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. Would anyone mind this to fix in the main trunk? Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. How do I f.i. listen to a 'pressed' signal on a QPushButton? There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. Elmar Am 04.12.13 18:52, schrieb Jay K: >Randy, definitely at least some of your changes got in. >For example, see: >?https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-ui/vbtkit/src/lego/WIN32/ >The changes involved forking large files to make small changes, and apparent bugs resulted as the files drifted apart. > > >There are Qt bindings in the tree now. >I haven't tried them yet. >Qt is probably the way to go. > > >The challenge in all this is coming up with the right abstraction or adopting the correct existing abstraction. >In the language we have a "record". This turns out to be very portable. >All processors and intermediate representations support it, or will be force of existing practise throughout the software industry (i.e. C has structs, therefore structs and anything resembling them shall always work efficiently). > > >Then, what is the right abstraction for a GUI library? >What will always be "easy enough" to implement on hardware or on top of other libraries? >And, how far down do we implement and meet the next layer? >Is the next layer a video buffer? Or a high level library? Or generating html for "complete reinterpretation"? >A thin stateless wrapper where someone else does 99.9% of the work? > > >And then implementing our part of it. > > >?- Jay > > > >________________________________ >From: rcolebur at SCIRES.COM >To: m3devel at elegosoft.com >Date: Wed, 4 Dec 2013 03:10:03 +0000 >Subject: Re: [M3devel] VBT and up to date desktop styling > > >Elmar: >? >Years ago, I worked with the principals at Critical Mass to make some Trestle/VBT/VBTKit changes that would make the ?look and feel? more Windows-like. >? >I'm pretty sure I passed all these to Olaf for incorporation into the CVS repository. >? >I developed some GUIs that looked decent at the time on Windows NT, but more work could be done to provide tighter integration. >? >Not sure if these pics will come thru in the email, but I've pasted a few below to give you some idea of what we achieved using Trestle, VBTKit, FormsVBT, etc. >? >Of course, at that time, our primary motivation was to have one set of GUI code that worked on multiple platforms and gave same look and feel, so tight integration with the underlying OS was not the driving concern.? Our code ran well and provided same look and feel on both HP-UX and Windows. >? >? >? >? >? >? >Thanks, >Randy Coleburn >? >-----Original Message----- >From: Elmar Stellnberger [mailto:estellnb at elstel.org] >Sent: Sunday, December 01, 2013 2:26 PM >To: m3devel >Subject: EXT:[M3devel] VBT and up to date desktop styling >? >As the VBT standard interface does only offer black and white user interface styling I would need to use vbtkit to achieve at least a Windows 3.1 similar user interface. However as I have found out some of the classes in vbtkit required just for the main menu have not been completed and do not compile yet. Would someone be ready to invest some time and affection to complete these classes? >To make MainMenu.m3 look good at least the following tasks would have to be done: >? >* AnchorSwitchVBT: to be completed, 3D reflection for the anchors of the popup menus in the main menu >* ShadowedBarVBT: is here but does not seem to work: it should display a horizontal bar in one of the popup menus >* ShadowVBT: to be completed: draw a 3D border around popup menus and other items >* Shadow: have a third color besides background and foreground for the flat style: eliminate the white borders in non-hover mode >* adjust the vbtkit menu so that the popup menus stays open if the mouse button is released; this will also be necessary to make sub-menus of popup-menus work; i.e. let popup menus contain AnchorSwitchVBTs >* evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs shadows appear to be larger in their horizontal extent by now compared to their vertical extent which is not that good to look at >* and likely some other issues I have not discovered yet >? >Considering all of that if I will not have an extended vbtkit interfacing with another GUI component like GTK would likely be the way to go because otherwise there would simply be too much time to be invested into vbtkit not considering underlying Trestle problems like Unicode support yet. Though it would be good to have a well working standard GUI interface for Modula-3 we need to consider now if putting further work into Trestle/vbtkit is still worth to do. If so I believe it would require a joint effort. >? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 57950 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 47526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 51415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 106584 bytes Desc: not available URL: From rodney_bates at lcwb.coop Sun Dec 15 16:40:26 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 15 Dec 2013 09:40:26 -0600 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52AC36BE.6070309@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> <52AC36BE.6070309@elstel.org> Message-ID: <52ADCD6A.10303@lcwb.coop> On 12/14/2013 04:45 AM, Elmar Stellnberger wrote: > Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. > Would anyone mind this to fix in the main trunk? > > Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. > I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. > How do I f.i. listen to a 'pressed' signal on a QPushButton? > There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. > Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). > Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. > > and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. > > Elmar > Just to be sure you understand, Modula-3 arrays of current-sized WIDECHAR are not UTF-16 character arrays. The former can only represent characters whose code points are <= 16_FFFF. UTF-16 encodes up to 16_10FFFF, by using two 16-bit code units for one character in the upper part of the range. This also means that the codes in the two code units are surrogates (16_D800..16_DFFF) and cannot be used as unencoded characters. For output, you could deal with this by just avoiding putting any surrogate values into a WIDECHAR (and, of course, no values beyond 16_FFFF, since they won't fit). But for input, any correctly implemented library that gives you UTF-16 strings could contain these, and probably you can't prevent that, because they can come all the way from a human user. So you would have to treat the WIDECHARs as code units, not code points, and write your own decoder. But then you would need a type to hold the decoded values, and WIDECHAR is not big enough, so it would have to be INTEGER or a subrange, and now you can't use the literals without conversions. Moreover, you can't use TEXT, with its easy-to-use functional style implementation of various string operations. I suppose you could write it so it just rejects or replaces high-valued code points at the decode stage and tell your users they can't use these characters. Or, you could just assume neither your application nor your users will ever need to use codes where 16-bit WIDECHAR and UTF-16 differ, and let it be buggy, if the assumption is ever violated. Also, does your preferred GUI allow you to specify that the UTF-16 strings you give it and get from it always have little endian code units, regardless of the native endianness of the machine? This is the way Modula-3 WIDECHARs work. If not, your application would only work on little-endian machines. From jay.krell at cornell.edu Mon Dec 16 10:31:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 16 Dec 2013 09:31:57 +0000 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52ADCD6A.10303@lcwb.coop> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> Message-ID: > like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. It might as well be UINT32 or UInt32? In C++, std::string is std::basic_string, std::wstring = std::basic_string. Could/should we use generics similarly? CharText, WIDECHAR=UINT16, WideCharText, UInt32Text? There is the problem of text literals. The current "text" can change between "char" and "widechar". Can "widechar" vary per-target? In particular, I think C/C++ wchar_t is 32bits on some platforms, so it might be reasonable for Modula-3 WIDECHAR to match it? (I just checked -- Linux/amd64 does have 32bit wchar_t). It is a thorny issue though, there are pluses and minuse either way. An alternative would be to have WIDECHAR be the same for all targets. - Jay > Date: Sun, 15 Dec 2013 09:40:26 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 does not support Scan.LongInt > > > > On 12/14/2013 04:45 AM, Elmar Stellnberger wrote: > > Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. > > Would anyone mind this to fix in the main trunk? > > > > Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. > > I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. > > How do I f.i. listen to a 'pressed' signal on a QPushButton? > > There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. > > Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). > > Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. > > > > and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. > > > > Elmar > > > > Just to be sure you understand, Modula-3 arrays of current-sized WIDECHAR > are not UTF-16 character arrays. The former can only represent characters > whose code points are <= 16_FFFF. UTF-16 encodes up to 16_10FFFF, by using > two 16-bit code units for one character in the upper part of the range. > This also means that the codes in the two code units are surrogates > (16_D800..16_DFFF) and cannot be used as unencoded characters. > > For output, you could deal with this by just avoiding putting any surrogate > values into a WIDECHAR (and, of course, no values beyond 16_FFFF, since they > won't fit). But for input, any correctly implemented library that gives you > UTF-16 strings could contain these, and probably you can't prevent that, because > they can come all the way from a human user. > > So you would have to treat the WIDECHARs as code units, not code points, and > write your own decoder. But then you would need a type to hold the decoded > values, and WIDECHAR is not big enough, so it would have to be INTEGER or a > subrange, and now you can't use the literals without conversions. Moreover, > you can't use TEXT, with its easy-to-use functional style implementation of > various string operations. I suppose you could write it so it just rejects > or replaces high-valued code points at the decode stage and tell your users > they can't use these characters. > > Or, you could just assume neither your application nor your users will ever > need to use codes where 16-bit WIDECHAR and UTF-16 differ, and let it be buggy, > if the assumption is ever violated. > > Also, does your preferred GUI allow you to specify that the UTF-16 strings > you give it and get from it always have little endian code units, regardless > of the native endianness of the machine? This is the way Modula-3 WIDECHARs > work. If not, your application would only work on little-endian machines. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 16 16:00:40 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Dec 2013 10:00:40 -0500 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> Message-ID: <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> Jumping in late to this whole conversation (please forgive any confusion)... I hesitate to define ANY M3 builtin type in terms of C/C++ standards. Regarding WIDECHAR, realize that its definition, like CHAR, should be in terms of an enumeration containing some (minimal) number of elements. The standard says that CHAR contains at least 256 elements. In M3 enumerations all have a direct mapping to INTEGER. So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded as UTF-8. More radically, what current code will break if CHAR is expanded to UTF-32? The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). On Dec 16, 2013, at 4:31 AM, Jay K wrote: > > like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. > > > It might as well be UINT32 or UInt32? > > > In C++, std::string is std::basic_string, std::wstring = std::basic_string. > Could/should we use generics similarly? > > > CharText, WIDECHAR=UINT16, WideCharText, UInt32Text? > > > There is the problem of text literals. > The current "text" can change between "char" and "widechar". > > > Can "widechar" vary per-target? > In particular, I think C/C++ wchar_t is 32bits on some platforms, so it might be reasonable for Modula-3 WIDECHAR to match it? > (I just checked -- Linux/amd64 does have 32bit wchar_t). > > > It is a thorny issue though, there are pluses and minuse either way. > An alternative would be to have WIDECHAR be the same for all targets. > > > - Jay > > > Date: Sun, 15 Dec 2013 09:40:26 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] cm3 does not support Scan.LongInt > > > > > > > > On 12/14/2013 04:45 AM, Elmar Stellnberger wrote: > > > Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. > > > Would anyone mind this to fix in the main trunk? > > > > > > Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. > > > I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. > > > How do I f.i. listen to a 'pressed' signal on a QPushButton? > > > There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. > > > Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). > > > Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. > > > > > > and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. > > > > > > Elmar > > > > > > > Just to be sure you understand, Modula-3 arrays of current-sized WIDECHAR > > are not UTF-16 character arrays. The former can only represent characters > > whose code points are <= 16_FFFF. UTF-16 encodes up to 16_10FFFF, by using > > two 16-bit code units for one character in the upper part of the range. > > This also means that the codes in the two code units are surrogates > > (16_D800..16_DFFF) and cannot be used as unencoded characters. > > > > For output, you could deal with this by just avoiding putting any surrogate > > values into a WIDECHAR (and, of course, no values beyond 16_FFFF, since they > > won't fit). But for input, any correctly implemented library that gives you > > UTF-16 strings could contain these, and probably you can't prevent that, because > > they can come all the way from a human user. > > > > So you would have to treat the WIDECHARs as code units, not code points, and > > write your own decoder. But then you would need a type to hold the decoded > > values, and WIDECHAR is not big enough, so it would have to be INTEGER or a > > subrange, and now you can't use the literals without conversions. Moreover, > > you can't use TEXT, with its easy-to-use functional style implementation of > > various string operations. I suppose you could write it so it just rejects > > or replaces high-valued code points at the decode stage and tell your users > > they can't use these characters. > > > > Or, you could just assume neither your application nor your users will ever > > need to use codes where 16-bit WIDECHAR and UTF-16 differ, and let it be buggy, > > if the assumption is ever violated. > > > > Also, does your preferred GUI allow you to specify that the UTF-16 strings > > you give it and get from it always have little endian code units, regardless > > of the native endianness of the machine? This is the way Modula-3 WIDECHARs > > work. If not, your application would only work on little-endian machines. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Mon Dec 16 17:20:13 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Mon, 16 Dec 2013 17:20:13 +0100 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> Message-ID: <52AF283D.2090707@elstel.org> Am 16.12.13 16:00, schrieb Tony Hosking: > Jumping in late to this whole conversation (please forgive any > confusion)... > > I hesitate to define ANY M3 builtin type in terms of C/C++ standards. > Regarding WIDECHAR, realize that its definition, like CHAR, should be > in terms of an enumeration containing some (minimal) number of elements. > The standard says that CHAR contains at least 256 elements. > In M3 enumerations all have a direct mapping to INTEGER. > So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded > as UTF-8. > More radically, what current code will break if CHAR is expanded to > UTF-32? > The language definition would allow that (there is nothing that says > BITSIZE(CHAR) == 8). > > On Dec 16, 2013, at 4:31 AM, Jay K > wrote: > Any code that was built to handle multiple character code sequences will break. i.e. any correctly implemented code that relies on UTF-16LE as currently provided expanding this range would be inherently non-portable. (... and it could even cause additional problems for when it came to interface with Xorg and Qt.) I'd believe that relying on a fixed range of values is going to be crucial for any kind of character type. You did not expand the CHAR type to 16 or 32bit either though that could even have caused less problems. Writing code that manipulates characters is simply very different from writing code that does some calculation based on integer numbers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Mon Dec 16 17:42:41 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Mon, 16 Dec 2013 17:42:41 +0100 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> Message-ID: <52AF2D81.2020501@elstel.org> Am 16.12.13 16:00, schrieb Tony Hosking: > Jumping in late to this whole conversation (please forgive any > confusion)... > > I hesitate to define ANY M3 builtin type in terms of C/C++ standards. > Regarding WIDECHAR, realize that its definition, like CHAR, should be > in terms of an enumeration containing some (minimal) number of elements. > The standard says that CHAR contains at least 256 elements. > In M3 enumerations all have a direct mapping to INTEGER. > So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded > as UTF-8. > More radically, what current code will break if CHAR is expanded to > UTF-32? > The language definition would allow that (there is nothing that says > BITSIZE(CHAR) == 8). > Well, if so I could rewrite some code to define as BITS 16 FOR WIDECHAR as WCHAR. Perhaps that would be the way to go. However as Rodney M. Bates has said current WIDECHAR is not BITS 16 for UCHAR. It uses LE encoding rather than host order encoding a fact which one could be quite happy about when it comes to extend Trestle/X11 for widechar support. So even that would fail when it came to interface with X11 (or otherwise one would have to maintain two branches of code all the time; one that does byte swapping and one that does not depending on the host order AND the internally used wchar order which could then differ as well.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 16 23:48:04 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 16 Dec 2013 22:48:04 +0000 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52AF2D81.2020501@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu>, <52AF2D81.2020501@elstel.org> Message-ID: > More radically, what current code will break if CHAR is expanded to UTF-32? > The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). Philosophy: I think you have be careful where you decide something is an abstraction vs. where you keep things unchanged because a lot of code depends on it AND it is adequate, and then introduce new things for new meanings. If something is an abstraction, you need to be sure that - all operations people might want to do are supported - breaking through the abstraction boundary is difficult/impossible, such that you maintain the ability to change the implementation later without breaking things Abstractions can have value, where you change the implementation and imbue existing code with some new features as a result. Such as ability to work with Unicode. For example, INTEGER is abstract enough, I guess, such that we can widen it. It isn't clearly abstract enough such that we can make overflow raise exceptions, because the existing widely used implementation does not. The size of INTEGER is plain to see to its clients and it is easy for them to be (accidentally) dependent on a particular implementation, but we have likely gotten over that by now, by having a good mix of implementations in use. Eventually we will probably see that code won't work if BITSIZE(INTEGER) = 32. Another example is that in C++ std::vector::iterator is very much like T*. In fact, it supports an identical feature set, except that it can be a different type and only mix with itself and not T*. In some implementations, it was in fact T* and there was code that mixed them. The implementation was later changed such as to be a unique type and a bunch of code stopped compiling. This is an example where the implementation wasn't opaque enough. Now presumably it is, so further changes won't cause such problems. (You can convert from iterator to pointer just by "&*" and std::vector is guaranteed contiguous, so the breakage was trivial to fix.) In C and I thought Modula-3 "char" / "CHAR" means "byte". Exactly 8 bits. I know there might be some wierdo Cray environments where all integer types are really 64 bit doubles, but millions of lines of C/C++ code assumes char is byte. Memory is composed of chars, files are composed of chars. Java and C# "fixed" this, char is 16bits there, and there is a new type "byte" or "int8" or "uint8", but for C and I thought Modula-3 we are stuck with char==8 bit byte and that is ok. (The signedness of char remains reasonably abstract and I think most code is ok either way, but I have seen code that depends on it either way.) Does X have an implied little/bigendian for 16 bit characters? If it is host, then we should use host. Windows uses host. Which is pretty much always little (except Xbox 360, and maybe some CE targets?) We would NOT maintain two forks, swapping and not, no matter what. We would have a function "SwapWideCharToLittleEndian" or such, written in C, that would probe the host endian and swap if needed. The probe would be something like: int is_little_endian(void) { union { char a[sizeof(int)]; int b; } c = {{1}}; return c.b == 1; } - Jay Date: Mon, 16 Dec 2013 17:42:41 +0100 From: estellnb at elstel.rivido.de To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com; rodney_bates at lcwb.coop Subject: Re: [M3devel] cm3 does not support Scan.LongInt Am 16.12.13 16:00, schrieb Tony Hosking: Jumping in late to this whole conversation (please forgive any confusion)... I hesitate to define ANY M3 builtin type in terms of C/C++ standards. Regarding WIDECHAR, realize that its definition, like CHAR, should be in terms of an enumeration containing some (minimal) number of elements. The standard says that CHAR contains at least 256 elements. In M3 enumerations all have a direct mapping to INTEGER. So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded as UTF-8. More radically, what current code will break if CHAR is expanded to UTF-32? The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). Well, if so I could rewrite some code to define as BITS 16 FOR WIDECHAR as WCHAR. Perhaps that would be the way to go. However as Rodney M. Bates has said current WIDECHAR is not BITS 16 for UCHAR. It uses LE encoding rather than host order encoding a fact which one could be quite happy about when it comes to extend Trestle/X11 for widechar support. So even that would fail when it came to interface with X11 (or otherwise one would have to maintain two branches of code all the time; one that does byte swapping and one that does not depending on the host order AND the internally used wchar order which could then differ as well.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Tue Dec 17 20:20:17 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Tue, 17 Dec 2013 19:20:17 +0000 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu>, <52AF2D81.2020501@elstel.org> Message-ID: <52B0A3F1.8070509@elstel.org> The Xorg documentation defines: typedef struct { unsigned char byte1; unsigned char byte2; } XChar2b; oopsla: byte1 = N div D + min_byte1 byte2 = N mod D + min_char_or_byte2 so this is big endian in deed (no matter of the arch). Perhaps Modula-3 should then store in host byte order and only convert on request. Defining it to be little endian would impose a certain unnecessary overhead on VAL and ORD and would most likely require byte swapping for Qt which I understand to implement QChar as host byte order (" Most compilers treat it like a unsigned short"). Am 16.12.2013 22:48, schrieb Jay K: > > More radically, what current code will break if CHAR is expanded > to UTF-32? > > The language definition would allow that (there is nothing that > says BITSIZE(CHAR) == 8). > > Philosophy: > > I think you have be careful where you decide something > is an abstraction vs. where you keep things unchanged > because a lot of code depends on it AND it is adequate, and > then introduce new things for new meanings. > > If something is an abstraction, you need to be sure that > - all operations people might want to do are supported > - breaking through the abstraction boundary is difficult/impossible, > such that you maintain the ability to change the implementation later > without breaking things > > Abstractions can have value, where you change the implementation > and imbue existing code with some new features as a result. > Such as ability to work with Unicode. > > For example, INTEGER is abstract enough, I guess, such that we can > widen it. > It isn't clearly abstract enough such that we can make overflow > raise exceptions, because the existing widely used implementation > does not. > > The size of INTEGER is plain to see to its clients and it is easy for > them > to be (accidentally) dependent on a particular implementation, but we > have likely > gotten over that by now, by having a good mix of implementations in use. > Eventually we will probably see that code won't work if > BITSIZE(INTEGER) = 32. > > > Another example is that in C++ std::vector::iterator is very much > like T*. In fact, it supports an identical feature set, except that > it can be a different > type and only mix with itself and not T*. > In some implementations, it was in fact T* and there was code that > mixed them. > The implementation was later changed such as to be a unique type and > a bunch > of code stopped compiling. This is an example where the > implementation wasn't opaque > enough. Now presumably it is, so further changes won't cause such > problems. > (You can convert from iterator to pointer just by "&*" and > std::vector is guaranteed > contiguous, so the breakage was trivial to fix.) > > In C and I thought Modula-3 "char" / "CHAR" means "byte". Exactly 8 > bits. > I know there might be some wierdo Cray environments where all > integer types are really 64 bit doubles, > but millions of lines of C/C++ code assumes char is byte. Memory is > composed of chars, files > are composed of chars. Java and C# "fixed" this, char is 16bits > there, and there is a new type "byte" > or "int8" or "uint8", but for C and I thought Modula-3 we are stuck > with char==8 bit byte and that is ok. > (The signedness of char remains reasonably abstract and I think most > code is ok either way, but > I have seen code that depends on it either way.) > > > Does X have an implied little/bigendian for 16 bit characters? > If it is host, then we should use host. > Windows uses host. Which is pretty much always little (except Xbox > 360, and maybe some CE targets?) > We would NOT maintain two forks, swapping and not, no matter what. > We would have a function "SwapWideCharToLittleEndian" or such, written > in C, > that would probe the host endian and swap if needed. > The probe would be something like: > int is_little_endian(void) { union { char a[sizeof(int)]; int b; } c = > {{1}}; return c.b == 1; } > > > - Jay > > ------------------------------------------------------------------------ > Date: Mon, 16 Dec 2013 17:42:41 +0100 > From: estellnb at elstel.rivido.de > To: hosking at cs.purdue.edu; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; rodney_bates at lcwb.coop > Subject: Re: [M3devel] cm3 does not support Scan.LongInt > > Am 16.12.13 16:00, schrieb Tony Hosking: > > Jumping in late to this whole conversation (please forgive any > confusion)... > > I hesitate to define ANY M3 builtin type in terms of C/C++ standards. > Regarding WIDECHAR, realize that its definition, like CHAR, should > be in terms of an enumeration containing some (minimal) number of > elements. > The standard says that CHAR contains at least 256 elements. > In M3 enumerations all have a direct mapping to INTEGER. > So, I assume that WIDECHAR would be UTF-32, and TEXT could be > encoded as UTF-8. > More radically, what current code will break if CHAR is expanded > to UTF-32? > The language definition would allow that (there is nothing that > says BITSIZE(CHAR) == 8). > > Well, if so I could rewrite some code to define as BITS 16 FOR > WIDECHAR as WCHAR. > Perhaps that would be the way to go. > However as Rodney M. Bates has said current WIDECHAR is not BITS 16 > for UCHAR. > It uses LE encoding rather than host order encoding a fact which one > could be quite > happy about when it comes to extend Trestle/X11 for widechar support. > So even that > would fail when it came to interface with X11 (or otherwise one would > have to maintain > two branches of code all the time; one that does byte swapping and one > that does not > depending on the host order AND the internally used wchar order which > could then > differ as well.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 17 21:55:29 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Dec 2013 20:55:29 +0000 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52B0A3F1.8070509@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu>, <52AF2D81.2020501@elstel.org> , <52B0A3F1.8070509@elstel.org> Message-ID: Yuck. I guess they 1) needed a wire format (definitely) and 2) never added a layer above that. We should use host order, yes, "like unsigned short". And btw there isn't necessarily a need to swap. You can always just extract bytes, like what you show: unsigned short u; unsigned char bigendian_bytes[2] = {(unsigned char)(u >> 8), (unsigned char)u}; is correct no matter the host order, maybe slow on big endian hosts, but fast enough. - Jay Date: Tue, 17 Dec 2013 19:20:17 +0000 From: estellnb at elstel.rivido.de To: jay.krell at cornell.edu; estellnb at elstel.rivido.de; hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] cm3 does not support Scan.LongInt The Xorg documentation defines: typedef struct { unsigned char byte1; unsigned char byte2; } XChar2b; oopsla: byte1 = N div D + min_byte1 byte2 = N mod D + min_char_or_byte2 so this is big endian in deed (no matter of the arch). Perhaps Modula-3 should then store in host byte order and only convert on request. Defining it to be little endian would impose a certain unnecessary overhead on VAL and ORD and would most likely require byte swapping for Qt which I understand to implement QChar as host byte order (" Most compilers treat it like a unsigned short"). Am 16.12.2013 22:48, schrieb Jay K: > More radically, what current code will break if CHAR is expanded to UTF-32? > The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). Philosophy: I think you have be careful where you decide something is an abstraction vs. where you keep things unchanged because a lot of code depends on it AND it is adequate, and then introduce new things for new meanings. If something is an abstraction, you need to be sure that - all operations people might want to do are supported - breaking through the abstraction boundary is difficult/impossible, such that you maintain the ability to change the implementation later without breaking things Abstractions can have value, where you change the implementation and imbue existing code with some new features as a result. Such as ability to work with Unicode. For example, INTEGER is abstract enough, I guess, such that we can widen it. It isn't clearly abstract enough such that we can make overflow raise exceptions, because the existing widely used implementation does not. The size of INTEGER is plain to see to its clients and it is easy for them to be (accidentally) dependent on a particular implementation, but we have likely gotten over that by now, by having a good mix of implementations in use. Eventually we will probably see that code won't work if BITSIZE(INTEGER) = 32. Another example is that in C++ std::vector::iterator is very much like T*. In fact, it supports an identical feature set, except that it can be a different type and only mix with itself and not T*. In some implementations, it was in fact T* and there was code that mixed them. The implementation was later changed such as to be a unique type and a bunch of code stopped compiling. This is an example where the implementation wasn't opaque enough. Now presumably it is, so further changes won't cause such problems. (You can convert from iterator to pointer just by "&*" and std::vector is guaranteed contiguous, so the breakage was trivial to fix.) In C and I thought Modula-3 "char" / "CHAR" means "byte". Exactly 8 bits. I know there might be some wierdo Cray environments where all integer types are really 64 bit doubles, but millions of lines of C/C++ code assumes char is byte. Memory is composed of chars, files are composed of chars. Java and C# "fixed" this, char is 16bits there, and there is a new type "byte" or "int8" or "uint8", but for C and I thought Modula-3 we are stuck with char==8 bit byte and that is ok. (The signedness of char remains reasonably abstract and I think most code is ok either way, but I have seen code that depends on it either way.) Does X have an implied little/bigendian for 16 bit characters? If it is host, then we should use host. Windows uses host. Which is pretty much always little (except Xbox 360, and maybe some CE targets?) We would NOT maintain two forks, swapping and not, no matter what. We would have a function "SwapWideCharToLittleEndian" or such, written in C, that would probe the host endian and swap if needed. The probe would be something like: int is_little_endian(void) { union { char a[sizeof(int)]; int b; } c = {{1}}; return c.b == 1; } - Jay Date: Mon, 16 Dec 2013 17:42:41 +0100 From: estellnb at elstel.rivido.de To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com; rodney_bates at lcwb.coop Subject: Re: [M3devel] cm3 does not support Scan.LongInt Am 16.12.13 16:00, schrieb Tony Hosking: Jumping in late to this whole conversation (please forgive any confusion)... I hesitate to define ANY M3 builtin type in terms of C/C++ standards. Regarding WIDECHAR, realize that its definition, like CHAR, should be in terms of an enumeration containing some (minimal) number of elements. The standard says that CHAR contains at least 256 elements. In M3 enumerations all have a direct mapping to INTEGER. So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded as UTF-8. More radically, what current code will break if CHAR is expanded to UTF-32? The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). Well, if so I could rewrite some code to define as BITS 16 FOR WIDECHAR as WCHAR. Perhaps that would be the way to go. However as Rodney M. Bates has said current WIDECHAR is not BITS 16 for UCHAR. It uses LE encoding rather than host order encoding a fact which one could be quite happy about when it comes to extend Trestle/X11 for widechar support. So even that would fail when it came to interface with X11 (or otherwise one would have to maintain two branches of code all the time; one that does byte swapping and one that does not depending on the host order AND the internally used wchar order which could then differ as well.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 19 22:55:30 2013 From: rodney_bates at lcwb.coop (Rodney Bates) Date: Thu, 19 Dec 2013 13:55:30 -0800 Subject: [M3devel] cm3 does not support Scan.LongInt Message-ID: <20131219135530.EA1CECFD@m0005299.ppops.net> An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 19 23:09:34 2013 From: rodney_bates at lcwb.coop (Rodney Bates) Date: Thu, 19 Dec 2013 14:09:34 -0800 Subject: [M3devel] cm3 does not support Scan.LongInt Message-ID: <20131219140934.EA1CEF38@m0005299.ppops.net> An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 19 22:40:52 2013 From: rodney_bates at lcwb.coop (Rodney Bates) Date: Thu, 19 Dec 2013 13:40:52 -0800 Subject: [M3devel] cm3 does not support Scan.LongInt Message-ID: <20131219134052.EA1CEDDB@m0005299.ppops.net> An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Dec 1 01:16:21 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 Nov 2013 19:16:21 -0500 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529A43B3.2090803@lcwb.coop> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> <20131130172906.GA28372@topoi.pooq.com> <529A43B3.2090803@lcwb.coop> Message-ID: <20131201001621.GA2374@topoi.pooq.com> On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: > > > On 11/30/2013 11:29 AM, Hendrik Boom wrote: > >On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: > >>Another devilish detail to be aware of: UTF-16 is _not_ the same as > >>the current Modula-3 16-bit WIDECHAR, even when restricted to values > >><= 16_FFFF. Current Wr/Rd library code just writes/reads > >>exactly 16 bits in two bytes, with whatever code point is in the > >>WIDECHAR variable. > >> > >>In contrast, UTF-16 will encode code points greater than > >>UFFFF as a pair of 16-bit code units with surrogate values in them. > >>Then to make this work right, the surrogate values are not > >>allowed in unencoded variables. So attempting to encode a surrogate > >>in UTF-16 is an error, and decoding a surrogate that is not part of a > >>proper first-surrogate/second-surrogate pair is "ill formed" and usually > >>decodes to UFFFD. > >> > >>You could get by with treating these as interchangeable only be being > >>careful to ensure there is never either a surrogate code nor a code > >>point > UFFFF, in either input or output. > >> > >>Also, current Wr/Rd always write/read only in little-endian byte order, > >>whereas there are both little- and big-endian variants of UTF-16. > >>I have no idea which endianness of UTF-16 is used by various GUI > >>libraries, but it would have to be little for this to work. > > > >It lools as if one might as well use UTF-8 if one is going to consider UTF-16. > > Hmm. Actually, *if* one could live with the restrictions on values above, > passing the same strings back and forth, with the GUI considering them UTF-16LE > and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have > the advantage that the M3 app code could deal naturally in characters, rather > than varying numbers of fragments of characters. UTF-8 would require > the latter. And then we just wait for the potential user who can't, and we'll have this discussion all over again. With the disadvantage that we'll end up having to put still more mechanisms for handling text everywhere. -- hendrik > > > > > >I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). > >and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have > >been superseded by SCIM, I don't know the status of uim, except that > >it has a uim bridge. > > > >It does look as if SCIM > >(http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended > >as a simple way to interface to many other input methods, such as XIM. > >It may be worth a look. > > > >--- hendrik > > > > > From jay.krell at cornell.edu Sun Dec 1 03:01:14 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 1 Dec 2013 02:01:14 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131201001621.GA2374@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com>, , <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org>, <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org>, <529A17DC.3080906@lcwb.coop>, <20131130172906.GA28372@topoi.pooq.com>, <529A43B3.2090803@lcwb.coop>, <20131201001621.GA2374@topoi.pooq.com> Message-ID: Windows is localized to and runs well with very many languages, using 16bit WCHAR.. - Jay > Date: Sat, 30 Nov 2013 19:16:21 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: > > > > > > On 11/30/2013 11:29 AM, Hendrik Boom wrote: > > >On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: > > >>Another devilish detail to be aware of: UTF-16 is _not_ the same as > > >>the current Modula-3 16-bit WIDECHAR, even when restricted to values > > >><= 16_FFFF. Current Wr/Rd library code just writes/reads > > >>exactly 16 bits in two bytes, with whatever code point is in the > > >>WIDECHAR variable. > > >> > > >>In contrast, UTF-16 will encode code points greater than > > >>UFFFF as a pair of 16-bit code units with surrogate values in them. > > >>Then to make this work right, the surrogate values are not > > >>allowed in unencoded variables. So attempting to encode a surrogate > > >>in UTF-16 is an error, and decoding a surrogate that is not part of a > > >>proper first-surrogate/second-surrogate pair is "ill formed" and usually > > >>decodes to UFFFD. > > >> > > >>You could get by with treating these as interchangeable only be being > > >>careful to ensure there is never either a surrogate code nor a code > > >>point > UFFFF, in either input or output. > > >> > > >>Also, current Wr/Rd always write/read only in little-endian byte order, > > >>whereas there are both little- and big-endian variants of UTF-16. > > >>I have no idea which endianness of UTF-16 is used by various GUI > > >>libraries, but it would have to be little for this to work. > > > > > >It lools as if one might as well use UTF-8 if one is going to consider UTF-16. > > > > Hmm. Actually, *if* one could live with the restrictions on values above, > > passing the same strings back and forth, with the GUI considering them UTF-16LE > > and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have > > the advantage that the M3 app code could deal naturally in characters, rather > > than varying numbers of fragments of characters. UTF-8 would require > > the latter. > > And then we just wait for the potential user who can't, and we'll have > this discussion all over again. > > With the disadvantage that we'll end up having to put still more > mechanisms for handling text everywhere. > > -- hendrik > > > > > > > > > > > >I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). > > >and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have > > >been superseded by SCIM, I don't know the status of uim, except that > > >it has a uim bridge. > > > > > >It does look as if SCIM > > >(http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended > > >as a simple way to interface to many other input methods, such as XIM. > > >It may be worth a look. > > > > > >--- hendrik > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sun Dec 1 09:47:37 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sun, 01 Dec 2013 08:47:37 +0000 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529A1A26.6010007@lcwb.coop> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> Message-ID: <529AF7A9.4090700@elstel.org> Am 30.11.2013 17:02, schrieb Rodney M. Bates: > > The en/decoders are available in one-code-point-per-call forms, as well > as in filters that are semantically almost identical to Wr and Rd, which > work on whole streams, with a constant encoding. The latter, in front of > TextWr/TextRd would probably make it easy to interface to any GUI library > that uses in-memory UTF-8, etc. > > It also would not be hard to make these work with 16-bit WIDECHAR, with > any input coded beyond UFFFF converted to the standard Unicode > replacement > UFFFD. It sounds like you would be unlikely to use such values. Yes, for that project I just need letters up to 0xFFFF i.e. latin-1 and -7. Currently I have copied a keyboard translation into /usr/share/X11/xkb/symbols/ that will give me greek chracters on [AltGr][Letter]. Nonetheless the current Windows implementation of the simulator suffices without such a trick because it can intercept the [AltGr] keystrokes. I have not evaluated yet whether the current VBT input form would allow a similar mechanism. > > How soon do you need to start? It would be good if that was available until January so that I can approach to finish my work until February. Fortunately there is some work which I could do in advance at least if the interfaces should not change radically. At least I should have some result at the beginning of March. Thanks for your effort, Elmar From dragisha at m3w.org Sun Dec 1 17:40:26 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Dec 2013 17:40:26 +0100 Subject: [M3devel] UTF-16: Greek alphabet with CM3 In-Reply-To: References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com>, , <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org>, <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org>, <529A17DC.3080906@lcwb.coop>, <20131130172906.GA28372@topoi.pooq.com>, <529A43B3.2090803@lcwb.coop>, <20131201001621.GA2374@topoi.pooq.com> Message-ID: And is only alive operating system, apart from Windows Phone OS (?), doing it with 16bit WCHAR? On 01 Dec 2013, at 03:01, Jay K wrote: > Windows is localized to and runs well with very many languages, using 16bit WCHAR.. > > - Jay > > > > Date: Sat, 30 Nov 2013 19:16:21 -0500 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > > > On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: > > > > > > > > > On 11/30/2013 11:29 AM, Hendrik Boom wrote: > > > >On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: > > > >>Another devilish detail to be aware of: UTF-16 is _not_ the same as > > > >>the current Modula-3 16-bit WIDECHAR, even when restricted to values > > > >><= 16_FFFF. Current Wr/Rd library code just writes/reads > > > >>exactly 16 bits in two bytes, with whatever code point is in the > > > >>WIDECHAR variable. > > > >> > > > >>In contrast, UTF-16 will encode code points greater than > > > >>UFFFF as a pair of 16-bit code units with surrogate values in them. > > > >>Then to make this work right, the surrogate values are not > > > >>allowed in unencoded variables. So attempting to encode a surrogate > > > >>in UTF-16 is an error, and decoding a surrogate that is not part of a > > > >>proper first-surrogate/second-surrogate pair is "ill formed" and usually > > > >>decodes to UFFFD. > > > >> > > > >>You could get by with treating these as interchangeable only be being > > > >>careful to ensure there is never either a surrogate code nor a code > > > >>point > UFFFF, in either input or output. > > > >> > > > >>Also, current Wr/Rd always write/read only in little-endian byte order, > > > >>whereas there are both little- and big-endian variants of UTF-16. > > > >>I have no idea which endianness of UTF-16 is used by various GUI > > > >>libraries, but it would have to be little for this to work. > > > > > > > >It lools as if one might as well use UTF-8 if one is going to consider UTF-16. > > > > > > Hmm. Actually, *if* one could live with the restrictions on values above, > > > passing the same strings back and forth, with the GUI considering them UTF-16LE > > > and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have > > > the advantage that the M3 app code could deal naturally in characters, rather > > > than varying numbers of fragments of characters. UTF-8 would require > > > the latter. > > > > And then we just wait for the potential user who can't, and we'll have > > this discussion all over again. > > > > With the disadvantage that we'll end up having to put still more > > mechanisms for handling text everywhere. > > > > -- hendrik > > > > > > > > > > > > > > > > > >I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). > > > >and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have > > > >been superseded by SCIM, I don't know the status of uim, except that > > > >it has a uim bridge. > > > > > > > >It does look as if SCIM > > > >(http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended > > > >as a simple way to interface to many other input methods, such as XIM. > > > >It may be worth a look. > > > > > > > >--- hendrik > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rodney_bates at lcwb.coop Sun Dec 1 19:01:21 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 01 Dec 2013 12:01:21 -0600 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131201001621.GA2374@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> <20131130172906.GA28372@topoi.pooq.com> <529A43B3.2090803@lcwb.coop> <20131201001621.GA2374@topoi.pooq.com> Message-ID: <529B7971.3080303@lcwb.coop> On 11/30/2013 06:16 PM, Hendrik Boom wrote: > On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: >> >> >> On 11/30/2013 11:29 AM, Hendrik Boom wrote: >>> On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: >>>> Another devilish detail to be aware of: UTF-16 is _not_ the same as >>>> the current Modula-3 16-bit WIDECHAR, even when restricted to values >>>> <= 16_FFFF. Current Wr/Rd library code just writes/reads >>>> exactly 16 bits in two bytes, with whatever code point is in the >>>> WIDECHAR variable. >>>> >>>> In contrast, UTF-16 will encode code points greater than >>>> UFFFF as a pair of 16-bit code units with surrogate values in them. >>>> Then to make this work right, the surrogate values are not >>>> allowed in unencoded variables. So attempting to encode a surrogate >>>> in UTF-16 is an error, and decoding a surrogate that is not part of a >>>> proper first-surrogate/second-surrogate pair is "ill formed" and usually >>>> decodes to UFFFD. >>>> >>>> You could get by with treating these as interchangeable only be being >>>> careful to ensure there is never either a surrogate code nor a code >>>> point > UFFFF, in either input or output. >>>> >>>> Also, current Wr/Rd always write/read only in little-endian byte order, >>>> whereas there are both little- and big-endian variants of UTF-16. >>>> I have no idea which endianness of UTF-16 is used by various GUI >>>> libraries, but it would have to be little for this to work. >>> >>> It lools as if one might as well use UTF-8 if one is going to consider UTF-16. >> >> Hmm. Actually, *if* one could live with the restrictions on values above, >> passing the same strings back and forth, with the GUI considering them UTF-16LE >> and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have >> the advantage that the M3 app code could deal naturally in characters, rather >> than varying numbers of fragments of characters. UTF-8 would require >> the latter. > > And then we just wait for the potential user who can't, and we'll have > this discussion all over again. > > With the disadvantage that we'll end up having to put still more > mechanisms for handling text everywhere. > > -- hendrik > > Yes, I agree completely, in general. I should have stated that, with that idea, I was thinking specifically of Elmar's problem. >> >> >>> >>> I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). >>> and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have >>> been superseded by SCIM, I don't know the status of uim, except that >>> it has a uim bridge. >>> >>> It does look as if SCIM >>> (http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended >>> as a simple way to interface to many other input methods, such as XIM. >>> It may be worth a look. >>> >>> --- hendrik >>> >>> >> > From dragisha at m3w.org Sun Dec 1 20:07:23 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Dec 2013 20:07:23 +0100 Subject: [M3devel] UTF-16: Greek alphabet with CM3 In-Reply-To: <20131201001621.GA2374@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> <20131130172906.GA28372@topoi.pooq.com> <529A43B3.2090803@lcwb.coop> <20131201001621.GA2374@topoi.pooq.com> Message-ID: <4326B57A-DEC7-4218-AC6C-BCEC4EE0CD59@m3w.org> Problem with Unicode is multiplied with a fact how most users never really dealt with international fonts. People are usually not so good at solving problems they never really felt. My mothers tongue, OTOH, is written in two scripts and Unicode is only way to cover all of it. All Western European languages and most European and near-European languages are covered with single ISO-8859-x 8-bit sets. My language needs two of these - ISO-8859-2 for Latin script, and and ISO-8859-5 for Cyrillic one. Also, I don?t think fixed bitwidth of characters is crucial, as we can cover all uses with good abstraction. Maybe like this one. (* (C) 2013 Dragi?a Duri?, dragisha at m3w.org *) INTERFACE UTF8; IMPORT RefSeq; (* UTF8.T is a subtype of TEXT, and it is also a UTF8 encoded Unicode string. *) TYPE Char = CARDINAL; T <: Public; Public = TEXT OBJECT METHODS init(t: TEXT): T; isValid(): BOOLEAN; (* so I can do all this without exceptions *) length(): CARDINAL; (* in glyphs *) byteSize(): CARDINAL; (* in CHARs/bytes *) empty(): BOOLEAN; (* shorter than ".length() = 0" *) (* hash(): Word.T; No need for this neither here nor at all. Text.Hash would be good enough, when I come to this. *) sub(start: CARDINAL; length: CARDINAL := LAST(CARDINAL)): T; getText(start: CARDINAL := 0; length: CARDINAL := LAST(CARDINAL)): TEXT; getChar(pos: CARDINAL): Char; setChars(VAR a: ARRAY OF Char); pos(pat: T; start: CARDINAL := 0): INTEGER; (* Uses Boyer-Moore [1] for fast search, Observations 1 & 2 are currently implemented. [1] Boyer, Robert S.; Moore, J Strother (October 1977). "A Fast String Searching Algorithm.". Comm. ACM (New York, NY, USA: Association for Computing Machinery) 20 (10): 762?772. *) findChar(ch: Char; start: CARDINAL := 0): INTEGER; findCharR(ch: Char; start: CARDINAL := LAST(CARDINAL)): INTEGER; (* findChar returns first position of ch to the right from start position, or start if ch is there. findCharR returns first position of ch to the left from start position, excluding start position. *) iterate(start: CARDINAL := 0; steps: CARDINAL := LAST(CARDINAL)): Iterator; END; (* All positional/count/length parameters for methods are in Unicode glyphs *) Iterator <: PublicIterator; PublicIterator = OBJECT METHODS next(VAR char: Char): BOOLEAN; (* TODO prev? *) END; (* Construction *) PROCEDURE New(t: TEXT): T; PROCEDURE Cat(u, t: T): T; PROCEDURE FromChars(READONLY chars: ARRAY OF Char): T; PROCEDURE FromCHARArray(VAR chars: ARRAY OF CHAR): T; (* Validation. Checks both NIL value, and invalid UTF8 string. *) PROCEDURE IsValid(t: T): BOOLEAN; (* Comparation/ordering *) PROCEDURE Equal(u, t: T): BOOLEAN; PROCEDURE Compare(t1, t2: T): [-1..1]; (* Future UTF8Ops, here for now: *) PROCEDURE EscapeS(t, s: T; escapeWith: CHAR := '\134'): T; PROCEDURE UnEscape(t: T; esc: CHAR := '\134'): T; PROCEDURE SplitS(t, s: T; skipSucc: BOOLEAN := TRUE): RefSeq.T; (* Treating escaped chars like normal ones. We need to define semantics for special treatment Fri Apr 19 12:00 2013: For now, I only implement skipSucc=TRUE case. *) PROCEDURE RemoveSpaces(t: T): T; PROCEDURE Caps(t: T): T; (* This is probably titlecase in Unicode-speak. CHECK. Also, see what happend with Lows() in case we treat titlecase *) PROCEDURE Lows(t: T): T; END UTF8. On 01 Dec 2013, at 01:16, Hendrik Boom wrote: > On Sat, Nov 30, 2013 at 01:59:47PM -0600, Rodney M. Bates wrote: >> >> >> On 11/30/2013 11:29 AM, Hendrik Boom wrote: >>> On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: >>>> Another devilish detail to be aware of: UTF-16 is _not_ the same as >>>> the current Modula-3 16-bit WIDECHAR, even when restricted to values >>>> <= 16_FFFF. Current Wr/Rd library code just writes/reads >>>> exactly 16 bits in two bytes, with whatever code point is in the >>>> WIDECHAR variable. >>>> >>>> In contrast, UTF-16 will encode code points greater than >>>> UFFFF as a pair of 16-bit code units with surrogate values in them. >>>> Then to make this work right, the surrogate values are not >>>> allowed in unencoded variables. So attempting to encode a surrogate >>>> in UTF-16 is an error, and decoding a surrogate that is not part of a >>>> proper first-surrogate/second-surrogate pair is "ill formed" and usually >>>> decodes to UFFFD. >>>> >>>> You could get by with treating these as interchangeable only be being >>>> careful to ensure there is never either a surrogate code nor a code >>>> point > UFFFF, in either input or output. >>>> >>>> Also, current Wr/Rd always write/read only in little-endian byte order, >>>> whereas there are both little- and big-endian variants of UTF-16. >>>> I have no idea which endianness of UTF-16 is used by various GUI >>>> libraries, but it would have to be little for this to work. >>> >>> It lools as if one might as well use UTF-8 if one is going to consider UTF-16. >> >> Hmm. Actually, *if* one could live with the restrictions on values above, >> passing the same strings back and forth, with the GUI considering them UTF-16LE >> and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have >> the advantage that the M3 app code could deal naturally in characters, rather >> than varying numbers of fragments of characters. UTF-8 would require >> the latter. > > And then we just wait for the potential user who can't, and we'll have > this discussion all over again. > > With the disadvantage that we'll end up having to put still more > mechanisms for handling text everywhere. > > -- hendrik > > >> >> >>> >>> I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). >>> and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have >>> been superseded by SCIM, I don't know the status of uim, except that >>> it has a uim bridge. >>> >>> It does look as if SCIM >>> (http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended >>> as a simple way to interface to many other input methods, such as XIM. >>> It may be worth a look. >>> >>> --- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From estellnb at elstel.org Sun Dec 1 20:26:21 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sun, 01 Dec 2013 19:26:21 +0000 Subject: [M3devel] VBT and up to date desktop styling Message-ID: <529B8D5D.9080306@elstel.org> As the VBT standard interface does only offer black and white user interface styling I would need to use vbtkit to achieve at least a Windows 3.1 similar user interface. However as I have found out some of the classes in vbtkit required just for the main menu have not been completed and do not compile yet. Would someone be ready to invest some time and affection to complete these classes? To make MainMenu.m3 look good at least the following tasks would have to be done: * AnchorSwitchVBT: to be completed, 3D reflection for the anchors of the popup menus in the main menu * ShadowedBarVBT: is here but does not seem to work: it should display a horizontal bar in one of the popup menus * ShadowVBT: to be completed: draw a 3D border around popup menus and other items * Shadow: have a third color besides background and foreground for the flat style: eliminate the white borders in non-hover mode * adjust the vbtkit menu so that the popup menus stays open if the mouse button is released; this will also be necessary to make sub-menus of popup-menus work; i.e. let popup menus contain AnchorSwitchVBTs * evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs shadows appear to be larger in their horizontal extent by now compared to their vertical extent which is not that good to look at * and likely some other issues I have not discovered yet Considering all of that if I will not have an extended vbtkit interfacing with another GUI component like GTK would likely be the way to go because otherwise there would simply be too much time to be invested into vbtkit not considering underlying Trestle problems like Unicode support yet. Though it would be good to have a well working standard GUI interface for Modula-3 we need to consider now if putting further work into Trestle/vbtkit is still worth to do. If so I believe it would require a joint effort. -------------- next part -------------- MODULE MainMenu EXPORTS Main; IMPORT TextVBT, RigidVBT, HVSplit, VBT, Split, Axis, Trestle, TrestleComm, Thread; IMPORT MenuSwitchVBT, (* AnchorSwitchVBT, *) AnchorBtnVBT, ButtonVBT; IMPORT Shadow, ShadowedFeedbackVBT, ShadowedBarVBT (*, ShadowVBT*), BorderedVBT; IMPORT Wr,Stdio; FROM VBTStyle IMPORT gray, black, blackongray, shadow; <*FATAL TrestleComm.Failure*> <*FATAL Wr.Failure*> <*FATAL Thread.Alerted*> TYPE MenuItemProc = PROCEDURE (v: MenuSwitch; READONLY cd: VBT.MouseRec); MenuSwitch = MenuSwitchVBT.T OBJECT callbackproc : MenuItemProc OVERRIDES callback := MenuSwitchCallbackWrapper; END; PROCEDURE MenuSwitchCallbackWrapper(v: MenuSwitch; READONLY cd:VBT.MouseRec) = BEGIN v.callbackproc(v,cd) END MenuSwitchCallbackWrapper; PROCEDURE AddMenuItem( menu: Split.T; item: TEXT; action: MenuItemProc ) = VAR feedback, menuswitch : VBT.T; BEGIN feedback := ShadowedFeedbackVBT.NewMenu( TextVBT.New( item, bgFg:=blackongray ), shadow ); menuswitch := NEW(MenuSwitch, callbackproc:= action).init(feedback); Split.AddChild(menu,menuswitch); END AddMenuItem; PROCEDURE AddHorizontalBar( menu: Split.T ) = BEGIN Split.AddChild(menu, NEW(ShadowedBarVBT.T).init( Axis.T.Hor, shadow, Shadow.Style.Chiseled ) ); END AddHorizontalBar; PROCEDURE AddSubMenu( menu: Split.T; item: TEXT; submenu: HVSplit.T ) = VAR feedback, anchorbutn : VBT.T; BEGIN feedback := NEW(ShadowedFeedbackVBT.T).init( ch:=TextVBT.New( item, bgFg:=blackongray ), shadow:=shadow, offStyle:=Shadow.Style.Flat, onStyle:=Shadow.Style.Lowered ,onExcitedStyle:=Shadow.Style.Lowered ); (* anchorbutn := AnchorBtnVBT.New( ch:=feedback, menu:= NEW(ShadowVBT.T, submenu, shadow, Shadow.Style.Raised ); *) anchorbutn := AnchorBtnVBT.New( ch:=feedback, menu:=BorderedVBT.New( submenu, 0.2, black ) ); Split.AddChild( menu, anchorbutn ); END AddSubMenu; VAR main, menu : VBT.T; VAR mainmenu, popup1, popup2, popup3 : Split.T; PROCEDURE Cut (<*UNUSED*>v: MenuSwitch; <*UNUSED*>READONLY cd: VBT.MouseRec) = BEGIN Wr.PutText(Stdio.stdout, "Cut\n"); Wr.Flush(Stdio.stdout); END Cut; PROCEDURE Paste (<*UNUSED*>v: MenuSwitch; <*UNUSED*>READONLY cd: VBT.MouseRec) = BEGIN Wr.PutText(Stdio.stdout, "Paste\n"); Wr.Flush(Stdio.stdout); END Paste; PROCEDURE Exit (<*UNUSED*>v: MenuSwitch; <*UNUSED*>READONLY cd: VBT.MouseRec) = BEGIN Trestle.Delete(main); END Exit; BEGIN popup1 := HVSplit.New(Axis.T.Ver); AddMenuItem(popup1, "Open", Cut); AddHorizontalBar(popup1); AddMenuItem(popup1, "Exit", Exit); popup3 := HVSplit.New(Axis.T.Ver); AddMenuItem(popup3, "SubCut", Cut); AddMenuItem(popup3, "SubPaste", Paste); (*popup2 := HVSplit.New(Axis.T.Ver); *) popup2 := HVSplit.New(Axis.T.Ver); AddMenuItem(popup2, "Cut", Cut); AddMenuItem(popup2, "Paste", Paste); AddSubMenu(popup2, "File", popup3); (* mainmenu := HVSplit.New(Axis.T.Hor); *) mainmenu := ButtonVBT.MenuBar( op:=gray ); AddSubMenu(mainmenu, "File", popup1); AddSubMenu(mainmenu, "Edit", popup2); AddMenuItem(mainmenu, "Exit", Exit); Split.AddChild(mainmenu,NEW(VBT.Leaf)); menu := mainmenu; main := HVSplit.Cons( Axis.T.Ver, menu, RigidVBT.FromHV( TextVBT.New("xxxxxx"), 100.0, 80.0 ) ); Trestle.Install(main); Trestle.AwaitDelete(main); END MainMenu. -------------- next part -------------- INTERFACE VBTStyle; IMPORT PaintOp, Shadow, Pixmap; VAR lgray, gray, dgray, black : PaintOp.T; blackongray : PaintOp.ColorQuad; shadow : Shadow.T; graytxt : Pixmap.T; END VBTStyle. -------------- next part -------------- MODULE VBTStyle; IMPORT PaintOp, Shadow; BEGIN lgray := PaintOp.FromRGB(0.9, 0.9, 0.9); gray := PaintOp.FromRGB(0.8, 0.8, 0.8); dgray := PaintOp.FromRGB(0.7, 0.7, 0.7); black := PaintOp.FromRGB(0.0, 0.0, 0.0); blackongray := PaintOp.MakeColorQuad( bg:= gray, fg:= black ); shadow := Shadow.New( size:= 1.0, light:= lgray, dark:= dgray ); END VBTStyle. From estellnb at elstel.org Sun Dec 1 20:37:28 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sun, 01 Dec 2013 19:37:28 +0000 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529B7CB3.2060602@lcwb.coop> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> <529B7CB3.2060602@lcwb.coop> Message-ID: <529B8FF8.4090708@elstel.org> Am 01.12.2013 18:15, schrieb Rodney M. Bates: > > > On 12/01/2013 02:47 AM, Elmar Stellnberger wrote: >> >> Am 30.11.2013 17:02, schrieb Rodney M. Bates: >>> >>> The en/decoders are available in one-code-point-per-call forms, as well >>> as in filters that are semantically almost identical to Wr and Rd, >>> which >>> work on whole streams, with a constant encoding. The latter, in >>> front of >>> TextWr/TextRd would probably make it easy to interface to any GUI >>> library >>> that uses in-memory UTF-8, etc. >>> >>> It also would not be hard to make these work with 16-bit WIDECHAR, with >>> any input coded beyond UFFFF converted to the standard Unicode >>> replacement >>> UFFFD. It sounds like you would be unlikely to use such values. >> Yes, for that project I just need letters up to 0xFFFF i.e. latin-1 >> and -7. >> Currently I have copied a keyboard translation into >> /usr/share/X11/xkb/symbols/ >> that will give me greek chracters on [AltGr][Letter]. Nonetheless the >> current >> Windows implementation of the simulator suffices without such a trick >> because >> it can intercept the [AltGr] keystrokes. I have not evaluated yet >> whether the >> current VBT input form would allow a similar mechanism. >>> >>> How soon do you need to start? >> It would be good if that was available until January so that I can >> approach to >> finish my work until February. Fortunately there is some work which I >> could >> do in advance at least if the interfaces should not change radically. >> At least >> I should have some result at the beginning of March. >> > > Enough of what the Unicode branch could do for you has been working > for some time. > The remaining problems are convenience/packaging things, testing of > big-endian and > mixed-endian pickles and network objects, and bootstrapping. I have > not rebootstrapped > using the release compiler in a couple of months, but I believe there > are some new > bootstrap barriers that have popped up. Also, the only backend that > is done is > the gcc-4.7-derived one, although I think that will cover the majority > of the targets. > What target are you using? AMD64_LINUX, LINUXLIBC6. However the program will need to work on windows as well. > > As for what GUI system to use, that is another question, but the > Unicode branch > would allow you to pass/receive strings in any of the encodings, yet > process > them in M3 code as simple characters, without having to mess with or > understand > the encodings. That should pretty well open up all your options on > what GUI > system to use. Also, it would make late changing to a different > encoding trivial. > Yes, I should likely check that branch out and compile it. However for the final program a stable version of it will be absolutely necessary. Then I will also have to decide whether I can use Trestle/vbtkit or whether I should try to convert a current GTK with swig. Elmar From dragisha at m3w.org Sun Dec 1 21:53:03 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Dec 2013 21:53:03 +0100 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529B8FF8.4090708@elstel.org> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> <529B7CB3.2060602@lcwb.coop> <529B8FF8.4090708@elstel.org> Message-ID: <4DAB8C65-061E-4AF0-B685-53B47B2572D0@m3w.org> Before you start with swig, take a look at this: https://dl.dropboxusercontent.com/u/60554338/m3-m3gtk2-r11929.tar.gz As usual? I do not have a time for legalese, if there is a question about licensing, it is cm3-alike. I would like to know if it's used/useful, but I give no warranty of any kind, and so on :). dd On 01 Dec 2013, at 20:37, Elmar Stellnberger wrote: > Then I will also have to decide whether I can use Trestle/vbtkit or whether I should try to > convert a current GTK with swig. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hendrik at topoi.pooq.com Sun Dec 1 23:50:30 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 1 Dec 2013 17:50:30 -0500 Subject: [M3devel] VBT and up to date desktop styling In-Reply-To: <529B8D5D.9080306@elstel.org> References: <529B8D5D.9080306@elstel.org> Message-ID: <20131201225029.GA24450@topoi.pooq.com> On Sun, Dec 01, 2013 at 07:26:21PM +0000, Elmar Stellnberger wrote: > > Considering all of that if I will not have an extended vbtkit > interfacing with another GUI component like GTK would likely be the > way to go because otherwise there would simply be too much time to > be invested into vbtkit not considering underlying Trestle problems > like Unicode support yet. Though it would be good to have a well > working standard GUI interface for Modula-3 we need to consider now > if putting further work into Trestle/vbtkit is still worth to do. If > so I believe it would require a joint effort. On the face of it, switching to a portable, language-independent user-interface library may be the way to go in the long run. I don't see any reason why the use of Modula 3 should require a different user interface library from the rest of the world, unless, of course the other libraries are crucially unsuitable or have unportable interfaces. In the dark ages, Modula-3 ended up with its own UI library because all UI libraries were hopelessly OS-specific. Yuo even had to rewrite your code for different versios of an OS. There *are* now some portable user-interface libraries. Aren't GTK and Qt candidates for this? Tough I'm not sure just how portable these are. The trouble with these are that they seem to keep coming up with new, incompatible versions, so maintaining the interfaces and client software might be a neverending activity. But there seems to be substantial transition periods between, say, GTK2 and GTK3 when both are available, so that may noot be too terrible. Has anyone done anything towards GTK or Qt bindings for Modula 3? -- hendrik From dmuysers at hotmail.com Sun Dec 1 23:56:18 2013 From: dmuysers at hotmail.com (dirk muysers) Date: Sun, 1 Dec 2013 23:56:18 +0100 Subject: [M3devel] VBT and up to date desktop styling In-Reply-To: <20131201225029.GA24450@topoi.pooq.com> References: <529B8D5D.9080306@elstel.org> <20131201225029.GA24450@topoi.pooq.com> Message-ID: IUP (http://www.tecgraf.puc-rio.br/iup/) is the easiest to interface to from a Modula-3 point of view. -----Original Message----- From: Hendrik Boom Sent: Sunday, December 01, 2013 11:50 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] VBT and up to date desktop styling On Sun, Dec 01, 2013 at 07:26:21PM +0000, Elmar Stellnberger wrote: > > Considering all of that if I will not have an extended vbtkit > interfacing with another GUI component like GTK would likely be the > way to go because otherwise there would simply be too much time to > be invested into vbtkit not considering underlying Trestle problems > like Unicode support yet. Though it would be good to have a well > working standard GUI interface for Modula-3 we need to consider now > if putting further work into Trestle/vbtkit is still worth to do. If > so I believe it would require a joint effort. On the face of it, switching to a portable, language-independent user-interface library may be the way to go in the long run. I don't see any reason why the use of Modula 3 should require a different user interface library from the rest of the world, unless, of course the other libraries are crucially unsuitable or have unportable interfaces. In the dark ages, Modula-3 ended up with its own UI library because all UI libraries were hopelessly OS-specific. Yuo even had to rewrite your code for different versios of an OS. There *are* now some portable user-interface libraries. Aren't GTK and Qt candidates for this? Tough I'm not sure just how portable these are. The trouble with these are that they seem to keep coming up with new, incompatible versions, so maintaining the interfaces and client software might be a neverending activity. But there seems to be substantial transition periods between, say, GTK2 and GTK3 when both are available, so that may noot be too terrible. Has anyone done anything towards GTK or Qt bindings for Modula 3? -- hendrik From dabenavidesd at yahoo.es Mon Dec 2 00:19:32 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 1 Dec 2013 23:19:32 +0000 (GMT) Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529AF7A9.4090700@elstel.org> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> Message-ID: <1385939972.4774.YahooMailNeo@web171902.mail.ir2.yahoo.com> Hi all: another turn around solution for this is to use the qt port developed by by Peter Mckinna. I'm interested in the event Model and signal and slot system, perhaps Peter can guide us through where it is now and where it should be. This will give us free access menu and buttons style in either Win or U*ix platforms. Personally I will base my further developments In Qt, trestle is a small toolkit developed by super minds, but honestly we don't have too much of a parallel system to gain much of its features. Thanks in advance El Domingo 1 de diciembre de 2013 3:47, Elmar Stellnberger escribi?: Am 30.11.2013 17:02, schrieb Rodney M. Bates: > > The en/decoders are available in one-code-point-per-call forms, as well > as in filters that are semantically almost identical to Wr and Rd, which > work on whole streams, with a constant encoding.? The latter, in front of > TextWr/TextRd would probably make it easy to interface to any GUI library > that uses in-memory UTF-8, etc. > > It also would not be hard to make these work with 16-bit WIDECHAR, with > any input coded beyond UFFFF converted to the standard Unicode > replacement > UFFFD.? It sounds like you would be unlikely to use such values. Yes, for that project I just need letters up to 0xFFFF i.e. latin-1 and -7. Currently I have copied a keyboard translation into /usr/share/X11/xkb/symbols/ that will give me greek chracters on [AltGr][Letter]. Nonetheless the current Windows implementation of the simulator suffices without such a trick because it can intercept the [AltGr] keystrokes. I have not evaluated yet whether the current VBT input form would allow a similar mechanism. > > How soon do you need to start? It would be good if that was available until January so that I can approach to finish my work until February. Fortunately there is some work which I could do in advance at least if the interfaces should not change radically. At least I should have some result at the beginning of March. Thanks for your effort, Elmar -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Dec 2 01:19:20 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 1 Dec 2013 19:19:20 -0500 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <1385939972.4774.YahooMailNeo@web171902.mail.ir2.yahoo.com> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> <1385939972.4774.YahooMailNeo@web171902.mail.ir2.yahoo.com> Message-ID: <20131202001920.GA25527@topoi.pooq.com> On Sun, Dec 01, 2013 at 11:19:32PM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > another turn around solution for this is to use the qt port developed > by by Peter Mckinna. I'm interested in the event Model and signal and > slot system, perhaps Peter can guide us through where it is now and > where it should be. This will give us free access menu and buttons > style in either Win or U*ix platforms. So Qt is now portable between OS's? Does it cover Mac, too? > Personally I will base my > further developments > In Qt, trestle is a small toolkit developed by > Not sure what you mean by trestle in Qt. super minds, but honestly we don't have too much of a parallel system A parallel system? > to gain much of its features. -- hendrik k From jay.krell at cornell.edu Sun Dec 1 21:33:53 2013 From: jay.krell at cornell.edu (Jay) Date: Sun, 1 Dec 2013 12:33:53 -0800 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: References: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> Message-ID: <1AB94F78-FE03-43D6-8F56-D6974C480E92@gmail.com> A lot of code within Windows uses WCHAR all the time. The kernel interfaces all accept only WCHAR (and a 16 bit length of bytes). FAT32, NTFS, registry all store 16bit WCHAR, at least when 7bits don't suffice. Trestle surely will remain with Xlib & Win32. New code...Qt? - Jay On Nov 30, 2013, at 2:52 AM, Dragi?a Duri? wrote: > And yes, Cairo uses UTF-8 natively, even on Windows. > > On 30 Nov 2013, at 11:41, Dragi?a Duri? wrote: > >> Are we really sure about this Xlib interfacing? >> >> There are several very-low-level and very-portable libraries right now. Why don?t we use Cairo? >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 30 Nov 2013, at 10:06, Jay K wrote: >> >>> 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? >>> 2) Are we really certain that redefining WIDECHAR is the way to go? >>> Not, say, introduce a new time, CHAR32 or UCHAR32? >>> And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? >>> >>> Or do people now advocate: >>> get rid of WIDECHAR >>> leave 8 bit CHAR >>> with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? >>> ?? >>> >>> Thank you, >>> - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 1 23:35:50 2013 From: jay.krell at cornell.edu (Jay) Date: Sun, 1 Dec 2013 14:35:50 -0800 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: <1AB94F78-FE03-43D6-8F56-D6974C480E92@gmail.com> References: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> <1AB94F78-FE03-43D6-8F56-D6974C480E92@gmail.com> Message-ID: <5D37F47A-AF27-47F6-95F6-9C91C26A076E@gmail.com> Sorry sent too soon. Windows is basically WCHAR everywhere except at boundaries that must accept multiple encodings... - Jay On Dec 1, 2013, at 12:33 PM, Jay wrote: > A lot of code within Windows uses WCHAR all the time. The kernel interfaces all accept only WCHAR (and a 16 bit length of bytes). FAT32, NTFS, registry all store 16bit WCHAR, at least when 7bits don't suffice. > > > Trestle surely will remain with Xlib & Win32. New code...Qt? > > > - Jay > > On Nov 30, 2013, at 2:52 AM, Dragi?a Duri? wrote: > >> And yes, Cairo uses UTF-8 natively, even on Windows. >> >> On 30 Nov 2013, at 11:41, Dragi?a Duri? wrote: >> >>> Are we really sure about this Xlib interfacing? >>> >>> There are several very-low-level and very-portable libraries right now. Why don?t we use Cairo? >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 30 Nov 2013, at 10:06, Jay K wrote: >>> >>>> 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? >>>> 2) Are we really certain that redefining WIDECHAR is the way to go? >>>> Not, say, introduce a new time, CHAR32 or UCHAR32? >>>> And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? >>>> >>>> Or do people now advocate: >>>> get rid of WIDECHAR >>>> leave 8 bit CHAR >>>> with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? >>>> ?? >>>> >>>> Thank you, >>>> - Jay >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 2 04:00:13 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 2 Dec 2013 03:00:13 +0000 (GMT) Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131202001920.GA25527@topoi.pooq.com> References: <5298E46D.2020209@lcwb.coop> <529A1A26.6010007@lcwb.coop> <529AF7A9.4090700@elstel.org> <1385939972.4774.YahooMailNeo@web171902.mail.ir2.yahoo.com> <20131202001920.GA25527@topoi.pooq.com> Message-ID: <1385953213.62458.YahooMailNeo@web171906.mail.ir2.yahoo.com> Hi all: Yes, mostly portable, since long ago in Mac, I'm not sure in OS/2. I think I miss wrote, I myself will base further development In Qt, though I'm not saying Tresstle is a bad toolkit, it just not fully exploited in current systems, read that as hardware and or software, is just that. Thanks in advance El Domingo 1 de diciembre de 2013 19:19, Hendrik Boom escribi?: On Sun, Dec 01, 2013 at 11:19:32PM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > another turn around solution for this is to use the qt port developed > by by Peter Mckinna. I'm interested in the event Model and signal and > slot system, perhaps Peter can guide us through where it is now and > where it should be. This will give us free access menu and buttons > style in either Win or U*ix platforms. So Qt is now portable between OS's?? Does it cover Mac, too? > Personally I will base my > further developments > In Qt, trestle is a small toolkit developed by > Not sure what you mean by trestle in Qt. super minds, but honestly we don't have too much of a parallel system A parallel system? > to gain much of its features. -- hendrik k -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 3 22:54:27 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Dec 2013 21:54:27 +0000 Subject: [M3devel] unicode in libm3 or separate package In-Reply-To: <20131203211338.B4C655DF608@birch.elegosoft.com> References: <20131203211338.B4C655DF608@birch.elegosoft.com> Message-ID: This is not necessary, but it is ok. m3core and libm3 are never built with an older compiler and can depend on a newer compiler. - Jay > Date: Tue, 3 Dec 2013 22:13:38 +0000 > To: m3commit at elegosoft.com > From: rodney at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/12/03 22:13:38 > > Modified files: > cm3/m3-libs/libm3/src/rw/: Tag: devel_unicode m3makefile > > Log message: > Move Unicode codec stuff to its own package. This allows for > bootstrapping the unicode branch with release and head compilers. > This code depends on being compiled with Unicode-sized WIDECHAR, > which is not initially available when first compiling libm3 and > the compiler, using an earlier compiler. New package libunicode > can now be compiled later, after a new compiler is installed. > > script do-cm3-unicode.sh does everything do-cm3-front.sh does, > plus libunicode. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 4 01:56:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Dec 2013 00:56:33 +0000 Subject: [M3devel] unicode in libm3 or separate package In-Reply-To: <3EDF0150-6846-4FA6-9698-5D41E3208A59@purdue.edu> References: <20131203211338.B4C655DF608@birch.elegosoft.com> , <3EDF0150-6846-4FA6-9698-5D41E3208A59@purdue.edu> Message-ID: Huh? No they aren't. bootstrapping uses old compiler to build everything after m3core/libm3 (up to cm3) bootstrapping uses old compiler to m3front/m3back/m3quake/m3linker/cm3/sysutils, but not m3core/libm3. Then bootstrapping uses new compiler to build everything. m3core/libm3 can depend on new compiler. m3front/m3back/m3quake/m3linker/cm3/sysutils cannot (except by more than one step, then they can -- "flexibility via multiple changes") see http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/upgrade.sh?rev=1.37;content-type=text%2Fplain notice where m3core/libm3 appear. which I don't use but is possibly clearer to people and what I use was based on it (I missed that upgrade.sh actually builds everything and mine stops at cm3). - Jay Subject: Re: [M3devel] unicode in libm3 or separate package From: hosking at purdue.edu Date: Tue, 3 Dec 2013 19:13:46 -0500 CC: m3devel at elegosoft.com; rodney.bates at wichita.edu To: jay.krell at cornell.edu Huh? They are when bootstrapping. Sent from my iPhone On 3 Dec 2013, at 4:54 pm, Jay K wrote: This is not necessary, but it is ok. m3core and libm3 are never built with an older compiler and can depend on a newer compiler. - Jay > Date: Tue, 3 Dec 2013 22:13:38 +0000 > To: m3commit at elegosoft.com > From: rodney at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/12/03 22:13:38 > > Modified files: > cm3/m3-libs/libm3/src/rw/: Tag: devel_unicode m3makefile > > Log message: > Move Unicode codec stuff to its own package. This allows for > bootstrapping the unicode branch with release and head compilers. > This code depends on being compiled with Unicode-sized WIDECHAR, > which is not initially available when first compiling libm3 and > the compiler, using an earlier compiler. New package libunicode > can now be compiled later, after a new compiler is installed. > > script do-cm3-unicode.sh does everything do-cm3-front.sh does, > plus libunicode. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Wed Dec 4 04:10:03 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 4 Dec 2013 03:10:03 +0000 Subject: [M3devel] VBT and up to date desktop styling Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> Elmar: Years ago, I worked with the principals at Critical Mass to make some Trestle/VBT/VBTKit changes that would make the "look and feel" more Windows-like. I'm pretty sure I passed all these to Olaf for incorporation into the CVS repository. I developed some GUIs that looked decent at the time on Windows NT, but more work could be done to provide tighter integration. Not sure if these pics will come thru in the email, but I've pasted a few below to give you some idea of what we achieved using Trestle, VBTKit, FormsVBT, etc. Of course, at that time, our primary motivation was to have one set of GUI code that worked on multiple platforms and gave same look and feel, so tight integration with the underlying OS was not the driving concern. Our code ran well and provided same look and feel on both HP-UX and Windows. [cid:image002.jpg at 01CEF074.68ECE030] [cid:image006.png at 01CEF073.CD228560] [cid:image007.png at 01CEF072.F125B000] [cid:image003.jpg at 01CEF074.68ECE030] Thanks, Randy Coleburn -----Original Message----- From: Elmar Stellnberger [mailto:estellnb at elstel.org] Sent: Sunday, December 01, 2013 2:26 PM To: m3devel Subject: EXT:[M3devel] VBT and up to date desktop styling As the VBT standard interface does only offer black and white user interface styling I would need to use vbtkit to achieve at least a Windows 3.1 similar user interface. However as I have found out some of the classes in vbtkit required just for the main menu have not been completed and do not compile yet. Would someone be ready to invest some time and affection to complete these classes? To make MainMenu.m3 look good at least the following tasks would have to be done: * AnchorSwitchVBT: to be completed, 3D reflection for the anchors of the popup menus in the main menu * ShadowedBarVBT: is here but does not seem to work: it should display a horizontal bar in one of the popup menus * ShadowVBT: to be completed: draw a 3D border around popup menus and other items * Shadow: have a third color besides background and foreground for the flat style: eliminate the white borders in non-hover mode * adjust the vbtkit menu so that the popup menus stays open if the mouse button is released; this will also be necessary to make sub-menus of popup-menus work; i.e. let popup menus contain AnchorSwitchVBTs * evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs shadows appear to be larger in their horizontal extent by now compared to their vertical extent which is not that good to look at * and likely some other issues I have not discovered yet Considering all of that if I will not have an extended vbtkit interfacing with another GUI component like GTK would likely be the way to go because otherwise there would simply be too much time to be invested into vbtkit not considering underlying Trestle problems like Unicode support yet. Though it would be good to have a well working standard GUI interface for Modula-3 we need to consider now if putting further work into Trestle/vbtkit is still worth to do. If so I believe it would require a joint effort. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 51415 bytes Desc: image007.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 47526 bytes Desc: image006.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 57950 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 106584 bytes Desc: image003.jpg URL: From jay.krell at cornell.edu Wed Dec 4 18:52:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Dec 2013 17:52:57 +0000 Subject: [M3devel] VBT and up to date desktop styling In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Randy, definitely at least some of your changes got in. For example, see: https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-ui/vbtkit/src/lego/WIN32/ The changes involved forking large files to make small changes, and apparent bugs resulted as the files drifted apart. There are Qt bindings in the tree now. I haven't tried them yet. Qt is probably the way to go. The challenge in all this is coming up with the right abstraction or adopting the correct existing abstraction. In the language we have a "record". This turns out to be very portable. All processors and intermediate representations support it, or will be force of existing practise throughout the software industry (i.e. C has structs, therefore structs and anything resembling them shall always work efficiently). Then, what is the right abstraction for a GUI library? What will always be "easy enough" to implement on hardware or on top of other libraries? And, how far down do we implement and meet the next layer? Is the next layer a video buffer? Or a high level library? Or generating html for "complete reinterpretation"? A thin stateless wrapper where someone else does 99.9% of the work? And then implementing our part of it. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Wed, 4 Dec 2013 03:10:03 +0000 Subject: Re: [M3devel] VBT and up to date desktop styling Elmar: Years ago, I worked with the principals at Critical Mass to make some Trestle/VBT/VBTKit changes that would make the ?look and feel? more Windows-like. I'm pretty sure I passed all these to Olaf for incorporation into the CVS repository. I developed some GUIs that looked decent at the time on Windows NT, but more work could be done to provide tighter integration. Not sure if these pics will come thru in the email, but I've pasted a few below to give you some idea of what we achieved using Trestle, VBTKit, FormsVBT, etc. Of course, at that time, our primary motivation was to have one set of GUI code that worked on multiple platforms and gave same look and feel, so tight integration with the underlying OS was not the driving concern. Our code ran well and provided same look and feel on both HP-UX and Windows. Thanks, Randy Coleburn -----Original Message----- From: Elmar Stellnberger [mailto:estellnb at elstel.org] Sent: Sunday, December 01, 2013 2:26 PM To: m3devel Subject: EXT:[M3devel] VBT and up to date desktop styling As the VBT standard interface does only offer black and white user interface styling I would need to use vbtkit to achieve at least a Windows 3.1 similar user interface. However as I have found out some of the classes in vbtkit required just for the main menu have not been completed and do not compile yet. Would someone be ready to invest some time and affection to complete these classes? To make MainMenu.m3 look good at least the following tasks would have to be done: * AnchorSwitchVBT: to be completed, 3D reflection for the anchors of the popup menus in the main menu * ShadowedBarVBT: is here but does not seem to work: it should display a horizontal bar in one of the popup menus * ShadowVBT: to be completed: draw a 3D border around popup menus and other items * Shadow: have a third color besides background and foreground for the flat style: eliminate the white borders in non-hover mode * adjust the vbtkit menu so that the popup menus stays open if the mouse button is released; this will also be necessary to make sub-menus of popup-menus work; i.e. let popup menus contain AnchorSwitchVBTs * evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs shadows appear to be larger in their horizontal extent by now compared to their vertical extent which is not that good to look at * and likely some other issues I have not discovered yet Considering all of that if I will not have an extended vbtkit interfacing with another GUI component like GTK would likely be the way to go because otherwise there would simply be too much time to be invested into vbtkit not considering underlying Trestle problems like Unicode support yet. Though it would be good to have a well working standard GUI interface for Modula-3 we need to consider now if putting further work into Trestle/vbtkit is still worth to do. If so I believe it would require a joint effort. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 51415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 47526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 57950 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 106584 bytes Desc: not available URL: From rodney_bates at lcwb.coop Tue Dec 10 18:59:54 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 10 Dec 2013 11:59:54 -0600 Subject: [M3devel] Fwd: Re: unicode in libm3 or separate package In-Reply-To: <529FE6A9.9070404@lcwb.coop> References: <529FE6A9.9070404@lcwb.coop> Message-ID: <52A7569A.9000600@lcwb.coop> 4th try repost: -------- Original Message -------- Subject: Re: [M3devel] unicode in libm3 or separate package Date: Wed, 04 Dec 2013 20:36:25 -0600 From: Rodney M. Bates To: m3devel at elegosoft.com Different meanings and procedures for bootstrapping. I am trying to ensure somebody without a previous M3 distribution can check one out, then build it with a binary only of the release compiler (e.g., via cminstall). I have not been using upgrade.sh, because it alters your /usr/local/cm3 in place, overlaying the original. This is not very handy for repeated experiments, when I have to keep recreating it. It will build though, with the dependencies in question. Instead, I have been using do-pkg.sh and do-cm3-*.sh. These, by default, use -override, which builds everything in the cvs checkout and leaves /usr/local/cm3 alone. In this case, trying to build a compiler first has no m3core or libm3 available, while building a library that depends on the newer compiler also fails. The separation I did allows this by getting code that an older compiler won't build into a separate package, where it can be done later. Unfortunately, it also means you can't just ship later, after all goes well. On 12/03/2013 06:56 PM, Jay K wrote: > Huh? No they aren't. > > > > bootstrapping uses old compiler to build everything /after /m3core/libm3 (up to cm3) > bootstrapping uses old compiler to m3front/m3back/m3quake/m3linker/cm3/sysutils, but not m3core/libm3. > Then bootstrapping uses new compiler to build everything. > > > m3core/libm3 can depend on new compiler. > m3front/m3back/m3quake/m3linker/cm3/sysutils cannot (except by more than one step, then they can -- "flexibility via multiple changes") > > > see > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/upgrade.sh?rev=1.37;content-type=text%2Fplain > notice where m3core/libm3 appear. > > > which I don't use but is possibly clearer to people and what I use was based on it (I missed that upgrade.sh actually builds everything and mine stops at cm3). > > > - Jay > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > Subject: Re: [M3devel] unicode in libm3 or separate package > From: hosking at purdue.edu > Date: Tue, 3 Dec 2013 19:13:46 -0500 > CC: m3devel at elegosoft.com; rodney.bates at wichita.edu > To: jay.krell at cornell.edu > > Huh? They are when bootstrapping. > > Sent from my iPhone > > On 3 Dec 2013, at 4:54 pm, Jay K > wrote: > > This is not necessary, but it is ok. > > m3core and libm3 are never built with an older compiler and can depend on a newer compiler. > > > - Jay > > > > Date: Tue, 3 Dec 2013 22:13:38 +0000 > > To: m3commit at elegosoft.com > > From: rodney at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/12/03 22:13:38 > > > > Modified files: > > cm3/m3-libs/libm3/src/rw/: Tag: devel_unicode m3makefile > > > > Log message: > > Move Unicode codec stuff to its own package. This allows for > > bootstrapping the unicode branch with release and head compilers. > > This code depends on being compiled with Unicode-sized WIDECHAR, > > which is not initially available when first compiling libm3 and > > the compiler, using an earlier compiler. New package libunicode > > can now be compiled later, after a new compiler is installed. > > > > script do-cm3-unicode.sh does everything do-cm3-front.sh does, > > plus libunicode. > > > From jay.krell at cornell.edu Wed Dec 11 23:36:28 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 11 Dec 2013 22:36:28 +0000 Subject: [M3devel] Fwd: Re: unicode in libm3 or separate package In-Reply-To: <52A7569A.9000600@lcwb.coop> References: <529FE6A9.9070404@lcwb.coop>,<52A7569A.9000600@lcwb.coop> Message-ID: 1) That isn't supposed to work. Sometimes it does, but there is no guarantee. 2) yeah, we should fix that, make it be two steps and the second step optional Either via buildlocal + optional ship or buildship into a new location and then optionally copy. - Jay > Date: Tue, 10 Dec 2013 11:59:54 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: Re: unicode in libm3 or separate package > > 4th try repost: > > > -------- Original Message -------- > Subject: Re: [M3devel] unicode in libm3 or separate package > Date: Wed, 04 Dec 2013 20:36:25 -0600 > From: Rodney M. Bates > To: m3devel at elegosoft.com > > Different meanings and procedures for bootstrapping. I am trying to ensure somebody > without a previous M3 distribution can check one out, then build it with a binary > only of the release compiler (e.g., via cminstall). I have not been using upgrade.sh, > because it alters your /usr/local/cm3 in place, overlaying the original. This is not > very handy for repeated experiments, when I have to keep recreating it. It will build > though, with the dependencies in question. > > Instead, I have been using do-pkg.sh and do-cm3-*.sh. These, by default, use -override, > which builds everything in the cvs checkout and leaves /usr/local/cm3 alone. In this case, > trying to build a compiler first has no m3core or libm3 available, while building a > library that depends on the newer compiler also fails. The separation I did allows this > by getting code that an older compiler won't build into a separate package, where it can > be done later. Unfortunately, it also means you can't just ship later, after all goes > well. > > On 12/03/2013 06:56 PM, Jay K wrote: > > Huh? No they aren't. > > > > > > > > bootstrapping uses old compiler to build everything /after /m3core/libm3 (up to cm3) > > bootstrapping uses old compiler to m3front/m3back/m3quake/m3linker/cm3/sysutils, but not m3core/libm3. > > Then bootstrapping uses new compiler to build everything. > > > > > > m3core/libm3 can depend on new compiler. > > m3front/m3back/m3quake/m3linker/cm3/sysutils cannot (except by more than one step, then they can -- "flexibility via multiple changes") > > > > > > see > > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/upgrade.sh?rev=1.37;content-type=text%2Fplain > > notice where m3core/libm3 appear. > > > > > > which I don't use but is possibly clearer to people and what I use was based on it (I missed that upgrade.sh actually builds everything and mine stops at cm3). > > > > > > - Jay > > > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > -- > > Subject: Re: [M3devel] unicode in libm3 or separate package > > From: hosking at purdue.edu > > Date: Tue, 3 Dec 2013 19:13:46 -0500 > > CC: m3devel at elegosoft.com; rodney.bates at wichita.edu > > To: jay.krell at cornell.edu > > > > Huh? They are when bootstrapping. > > > > Sent from my iPhone > > > > On 3 Dec 2013, at 4:54 pm, Jay K > wrote: > > > > This is not necessary, but it is ok. > > > > m3core and libm3 are never built with an older compiler and can depend on a newer compiler. > > > > > > - Jay > > > > > > > Date: Tue, 3 Dec 2013 22:13:38 +0000 > > > To: m3commit at elegosoft.com > > > From: rodney at elego.de > > > Subject: [M3commit] CVS Update: cm3 > > > > > > CVSROOT: /usr/cvs > > > Changes by: rodney at birch. 13/12/03 22:13:38 > > > > > > Modified files: > > > cm3/m3-libs/libm3/src/rw/: Tag: devel_unicode m3makefile > > > > > > Log message: > > > Move Unicode codec stuff to its own package. This allows for > > > bootstrapping the unicode branch with release and head compilers. > > > This code depends on being compiled with Unicode-sized WIDECHAR, > > > which is not initially available when first compiling libm3 and > > > the compiler, using an earlier compiler. New package libunicode > > > can now be compiled later, after a new compiler is installed. > > > > > > script do-cm3-unicode.sh does everything do-cm3-front.sh does, > > > plus libunicode. > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sat Dec 14 11:45:18 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 14 Dec 2013 11:45:18 +0100 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <52AC36BE.6070309@elstel.org> Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. Would anyone mind this to fix in the main trunk? Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. How do I f.i. listen to a 'pressed' signal on a QPushButton? There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. Elmar Am 04.12.13 18:52, schrieb Jay K: > Randy, definitely at least some of your changes got in. > For example, see: > https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-ui/vbtkit/src/lego/WIN32/ > The changes involved forking large files to make small changes, and > apparent bugs resulted as the files drifted apart. > > > There are Qt bindings in the tree now. > I haven't tried them yet. > Qt is probably the way to go. > > > The challenge in all this is coming up with the right abstraction or > adopting the correct existing abstraction. > In the language we have a "record". This turns out to be very portable. > All processors and intermediate representations support it, or will be > force of existing practise throughout the software industry (i.e. C > has structs, therefore structs and anything resembling them shall > always work efficiently). > > > Then, what is the right abstraction for a GUI library? > What will always be "easy enough" to implement on hardware or on top > of other libraries? > And, how far down do we implement and meet the next layer? > Is the next layer a video buffer? Or a high level library? Or > generating html for "complete reinterpretation"? > A thin stateless wrapper where someone else does 99.9% of the work? > > > And then implementing our part of it. > > > - Jay > > ------------------------------------------------------------------------ > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Wed, 4 Dec 2013 03:10:03 +0000 > Subject: Re: [M3devel] VBT and up to date desktop styling > > Elmar: > > Years ago, I worked with the principals at Critical Mass to make some > Trestle/VBT/VBTKit changes that would make the ?look and feel? more > Windows-like. > > I'm pretty sure I passed all these to Olaf for incorporation into the > CVS repository. > > I developed some GUIs that looked decent at the time on Windows NT, > but more work could be done to provide tighter integration. > > Not sure if these pics will come thru in the email, but I've pasted a > few below to give you some idea of what we achieved using Trestle, > VBTKit, FormsVBT, etc. > > Of course, at that time, our primary motivation was to have one set of > GUI code that worked on multiple platforms and gave same look and > feel, so tight integration with the underlying OS was not the driving > concern. Our code ran well and provided same look and feel on both > HP-UX and Windows. > > Thanks, > > Randy Coleburn > > -----Original Message----- > From: Elmar Stellnberger [mailto:estellnb at elstel.org] > Sent: Sunday, December 01, 2013 2:26 PM > To: m3devel > Subject: EXT:[M3devel] VBT and up to date desktop styling > > As the VBT standard interface does only offer black and white user > interface styling I would need to use vbtkit to achieve at least a > Windows 3.1 similar user interface. However as I have found out some > of the classes in vbtkit required just for the main menu have not been > completed and do not compile yet. Would someone be ready to invest > some time and affection to complete these classes? > > To make MainMenu.m3 look good at least the following tasks would have > to be done: > > * AnchorSwitchVBT: to be completed, 3D reflection for the anchors of > the popup menus in the main menu > > * ShadowedBarVBT: is here but does not seem to work: it should display > a horizontal bar in one of the popup menus > > * ShadowVBT: to be completed: draw a 3D border around popup menus and > other items > > * Shadow: have a third color besides background and foreground for the > flat style: eliminate the white borders in non-hover mode > > * adjust the vbtkit menu so that the popup menus stays open if the > mouse button is released; this will also be necessary to make > sub-menus of popup-menus work; i.e. let popup menus contain > AnchorSwitchVBTs > > * evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs > shadows appear to be larger in their horizontal extent by now compared > to their vertical extent which is not that good to look at > > * and likely some other issues I have not discovered yet > > Considering all of that if I will not have an extended vbtkit > interfacing with another GUI component like GTK would likely be the > way to go because otherwise there would simply be too much time to be > invested into vbtkit not considering underlying Trestle problems like > Unicode support yet. Though it would be good to have a well working > standard GUI interface for Modula-3 we need to consider now if putting > further work into Trestle/vbtkit is still worth to do. If so I believe > it would require a joint effort. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 57950 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 47526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 51415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 106584 bytes Desc: not available URL: From dabenavidesd at yahoo.es Sat Dec 14 21:31:58 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 14 Dec 2013 20:31:58 +0000 (GMT) Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52AC36BE.6070309@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> <52AC36BE.6070309@elstel.org> Message-ID: <1387053118.25449.YahooMailNeo@web171902.mail.ir2.yahoo.com> Hi all, not me, but somebody was happily (well almost) compiling 200k lines of Modula-3 from Qt headers some months ago. But I don't know how to browse in that page, I'm openly against new UI in web pages :), are just too crazy, maybe I'm just too old for that technology. Can you help to contact demoitem guy: https://github.com/swig/swig/pull/84 Thanks in advance El S?bado 14 de diciembre de 2013 5:45, Elmar Stellnberger escribi?: Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. Would anyone mind this to fix in the main trunk? Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. How do I f.i. listen to a 'pressed' signal on a QPushButton? There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. Elmar Am 04.12.13 18:52, schrieb Jay K: >Randy, definitely at least some of your changes got in. >For example, see: >?https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-ui/vbtkit/src/lego/WIN32/ >The changes involved forking large files to make small changes, and apparent bugs resulted as the files drifted apart. > > >There are Qt bindings in the tree now. >I haven't tried them yet. >Qt is probably the way to go. > > >The challenge in all this is coming up with the right abstraction or adopting the correct existing abstraction. >In the language we have a "record". This turns out to be very portable. >All processors and intermediate representations support it, or will be force of existing practise throughout the software industry (i.e. C has structs, therefore structs and anything resembling them shall always work efficiently). > > >Then, what is the right abstraction for a GUI library? >What will always be "easy enough" to implement on hardware or on top of other libraries? >And, how far down do we implement and meet the next layer? >Is the next layer a video buffer? Or a high level library? Or generating html for "complete reinterpretation"? >A thin stateless wrapper where someone else does 99.9% of the work? > > >And then implementing our part of it. > > >?- Jay > > > >________________________________ >From: rcolebur at SCIRES.COM >To: m3devel at elegosoft.com >Date: Wed, 4 Dec 2013 03:10:03 +0000 >Subject: Re: [M3devel] VBT and up to date desktop styling > > >Elmar: >? >Years ago, I worked with the principals at Critical Mass to make some Trestle/VBT/VBTKit changes that would make the ?look and feel? more Windows-like. >? >I'm pretty sure I passed all these to Olaf for incorporation into the CVS repository. >? >I developed some GUIs that looked decent at the time on Windows NT, but more work could be done to provide tighter integration. >? >Not sure if these pics will come thru in the email, but I've pasted a few below to give you some idea of what we achieved using Trestle, VBTKit, FormsVBT, etc. >? >Of course, at that time, our primary motivation was to have one set of GUI code that worked on multiple platforms and gave same look and feel, so tight integration with the underlying OS was not the driving concern.? Our code ran well and provided same look and feel on both HP-UX and Windows. >? >? >? >? >? >? >Thanks, >Randy Coleburn >? >-----Original Message----- >From: Elmar Stellnberger [mailto:estellnb at elstel.org] >Sent: Sunday, December 01, 2013 2:26 PM >To: m3devel >Subject: EXT:[M3devel] VBT and up to date desktop styling >? >As the VBT standard interface does only offer black and white user interface styling I would need to use vbtkit to achieve at least a Windows 3.1 similar user interface. However as I have found out some of the classes in vbtkit required just for the main menu have not been completed and do not compile yet. Would someone be ready to invest some time and affection to complete these classes? >To make MainMenu.m3 look good at least the following tasks would have to be done: >? >* AnchorSwitchVBT: to be completed, 3D reflection for the anchors of the popup menus in the main menu >* ShadowedBarVBT: is here but does not seem to work: it should display a horizontal bar in one of the popup menus >* ShadowVBT: to be completed: draw a 3D border around popup menus and other items >* Shadow: have a third color besides background and foreground for the flat style: eliminate the white borders in non-hover mode >* adjust the vbtkit menu so that the popup menus stays open if the mouse button is released; this will also be necessary to make sub-menus of popup-menus work; i.e. let popup menus contain AnchorSwitchVBTs >* evtl.: Shadow: have a horizontal and a vertical width as ShadowVBTs shadows appear to be larger in their horizontal extent by now compared to their vertical extent which is not that good to look at >* and likely some other issues I have not discovered yet >? >Considering all of that if I will not have an extended vbtkit interfacing with another GUI component like GTK would likely be the way to go because otherwise there would simply be too much time to be invested into vbtkit not considering underlying Trestle problems like Unicode support yet. Though it would be good to have a well working standard GUI interface for Modula-3 we need to consider now if putting further work into Trestle/vbtkit is still worth to do. If so I believe it would require a joint effort. >? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 57950 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 47526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 51415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 106584 bytes Desc: not available URL: From rodney_bates at lcwb.coop Sun Dec 15 16:40:26 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 15 Dec 2013 09:40:26 -0600 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52AC36BE.6070309@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL> <52AC36BE.6070309@elstel.org> Message-ID: <52ADCD6A.10303@lcwb.coop> On 12/14/2013 04:45 AM, Elmar Stellnberger wrote: > Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. > Would anyone mind this to fix in the main trunk? > > Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. > I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. > How do I f.i. listen to a 'pressed' signal on a QPushButton? > There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. > Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). > Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. > > and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. > > Elmar > Just to be sure you understand, Modula-3 arrays of current-sized WIDECHAR are not UTF-16 character arrays. The former can only represent characters whose code points are <= 16_FFFF. UTF-16 encodes up to 16_10FFFF, by using two 16-bit code units for one character in the upper part of the range. This also means that the codes in the two code units are surrogates (16_D800..16_DFFF) and cannot be used as unencoded characters. For output, you could deal with this by just avoiding putting any surrogate values into a WIDECHAR (and, of course, no values beyond 16_FFFF, since they won't fit). But for input, any correctly implemented library that gives you UTF-16 strings could contain these, and probably you can't prevent that, because they can come all the way from a human user. So you would have to treat the WIDECHARs as code units, not code points, and write your own decoder. But then you would need a type to hold the decoded values, and WIDECHAR is not big enough, so it would have to be INTEGER or a subrange, and now you can't use the literals without conversions. Moreover, you can't use TEXT, with its easy-to-use functional style implementation of various string operations. I suppose you could write it so it just rejects or replaces high-valued code points at the decode stage and tell your users they can't use these characters. Or, you could just assume neither your application nor your users will ever need to use codes where 16-bit WIDECHAR and UTF-16 differ, and let it be buggy, if the assumption is ever violated. Also, does your preferred GUI allow you to specify that the UTF-16 strings you give it and get from it always have little endian code units, regardless of the native endianness of the machine? This is the way Modula-3 WIDECHARs work. If not, your application would only work on little-endian machines. From jay.krell at cornell.edu Mon Dec 16 10:31:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 16 Dec 2013 09:31:57 +0000 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52ADCD6A.10303@lcwb.coop> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> Message-ID: > like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. It might as well be UINT32 or UInt32? In C++, std::string is std::basic_string, std::wstring = std::basic_string. Could/should we use generics similarly? CharText, WIDECHAR=UINT16, WideCharText, UInt32Text? There is the problem of text literals. The current "text" can change between "char" and "widechar". Can "widechar" vary per-target? In particular, I think C/C++ wchar_t is 32bits on some platforms, so it might be reasonable for Modula-3 WIDECHAR to match it? (I just checked -- Linux/amd64 does have 32bit wchar_t). It is a thorny issue though, there are pluses and minuse either way. An alternative would be to have WIDECHAR be the same for all targets. - Jay > Date: Sun, 15 Dec 2013 09:40:26 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 does not support Scan.LongInt > > > > On 12/14/2013 04:45 AM, Elmar Stellnberger wrote: > > Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. > > Would anyone mind this to fix in the main trunk? > > > > Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. > > I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. > > How do I f.i. listen to a 'pressed' signal on a QPushButton? > > There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. > > Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). > > Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. > > > > and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. > > > > Elmar > > > > Just to be sure you understand, Modula-3 arrays of current-sized WIDECHAR > are not UTF-16 character arrays. The former can only represent characters > whose code points are <= 16_FFFF. UTF-16 encodes up to 16_10FFFF, by using > two 16-bit code units for one character in the upper part of the range. > This also means that the codes in the two code units are surrogates > (16_D800..16_DFFF) and cannot be used as unencoded characters. > > For output, you could deal with this by just avoiding putting any surrogate > values into a WIDECHAR (and, of course, no values beyond 16_FFFF, since they > won't fit). But for input, any correctly implemented library that gives you > UTF-16 strings could contain these, and probably you can't prevent that, because > they can come all the way from a human user. > > So you would have to treat the WIDECHARs as code units, not code points, and > write your own decoder. But then you would need a type to hold the decoded > values, and WIDECHAR is not big enough, so it would have to be INTEGER or a > subrange, and now you can't use the literals without conversions. Moreover, > you can't use TEXT, with its easy-to-use functional style implementation of > various string operations. I suppose you could write it so it just rejects > or replaces high-valued code points at the decode stage and tell your users > they can't use these characters. > > Or, you could just assume neither your application nor your users will ever > need to use codes where 16-bit WIDECHAR and UTF-16 differ, and let it be buggy, > if the assumption is ever violated. > > Also, does your preferred GUI allow you to specify that the UTF-16 strings > you give it and get from it always have little endian code units, regardless > of the native endianness of the machine? This is the way Modula-3 WIDECHARs > work. If not, your application would only work on little-endian machines. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 16 16:00:40 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Dec 2013 10:00:40 -0500 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> Message-ID: <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> Jumping in late to this whole conversation (please forgive any confusion)... I hesitate to define ANY M3 builtin type in terms of C/C++ standards. Regarding WIDECHAR, realize that its definition, like CHAR, should be in terms of an enumeration containing some (minimal) number of elements. The standard says that CHAR contains at least 256 elements. In M3 enumerations all have a direct mapping to INTEGER. So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded as UTF-8. More radically, what current code will break if CHAR is expanded to UTF-32? The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). On Dec 16, 2013, at 4:31 AM, Jay K wrote: > > like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. > > > It might as well be UINT32 or UInt32? > > > In C++, std::string is std::basic_string, std::wstring = std::basic_string. > Could/should we use generics similarly? > > > CharText, WIDECHAR=UINT16, WideCharText, UInt32Text? > > > There is the problem of text literals. > The current "text" can change between "char" and "widechar". > > > Can "widechar" vary per-target? > In particular, I think C/C++ wchar_t is 32bits on some platforms, so it might be reasonable for Modula-3 WIDECHAR to match it? > (I just checked -- Linux/amd64 does have 32bit wchar_t). > > > It is a thorny issue though, there are pluses and minuse either way. > An alternative would be to have WIDECHAR be the same for all targets. > > > - Jay > > > Date: Sun, 15 Dec 2013 09:40:26 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] cm3 does not support Scan.LongInt > > > > > > > > On 12/14/2013 04:45 AM, Elmar Stellnberger wrote: > > > Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt. > > > Would anyone mind this to fix in the main trunk? > > > > > > Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator. > > > I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3. > > > How do I f.i. listen to a 'pressed' signal on a QPushButton? > > > There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override. > > > Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.). > > > Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port. > > > > > > and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width. > > > > > > Elmar > > > > > > > Just to be sure you understand, Modula-3 arrays of current-sized WIDECHAR > > are not UTF-16 character arrays. The former can only represent characters > > whose code points are <= 16_FFFF. UTF-16 encodes up to 16_10FFFF, by using > > two 16-bit code units for one character in the upper part of the range. > > This also means that the codes in the two code units are surrogates > > (16_D800..16_DFFF) and cannot be used as unencoded characters. > > > > For output, you could deal with this by just avoiding putting any surrogate > > values into a WIDECHAR (and, of course, no values beyond 16_FFFF, since they > > won't fit). But for input, any correctly implemented library that gives you > > UTF-16 strings could contain these, and probably you can't prevent that, because > > they can come all the way from a human user. > > > > So you would have to treat the WIDECHARs as code units, not code points, and > > write your own decoder. But then you would need a type to hold the decoded > > values, and WIDECHAR is not big enough, so it would have to be INTEGER or a > > subrange, and now you can't use the literals without conversions. Moreover, > > you can't use TEXT, with its easy-to-use functional style implementation of > > various string operations. I suppose you could write it so it just rejects > > or replaces high-valued code points at the decode stage and tell your users > > they can't use these characters. > > > > Or, you could just assume neither your application nor your users will ever > > need to use codes where 16-bit WIDECHAR and UTF-16 differ, and let it be buggy, > > if the assumption is ever violated. > > > > Also, does your preferred GUI allow you to specify that the UTF-16 strings > > you give it and get from it always have little endian code units, regardless > > of the native endianness of the machine? This is the way Modula-3 WIDECHARs > > work. If not, your application would only work on little-endian machines. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Mon Dec 16 17:20:13 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Mon, 16 Dec 2013 17:20:13 +0100 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> Message-ID: <52AF283D.2090707@elstel.org> Am 16.12.13 16:00, schrieb Tony Hosking: > Jumping in late to this whole conversation (please forgive any > confusion)... > > I hesitate to define ANY M3 builtin type in terms of C/C++ standards. > Regarding WIDECHAR, realize that its definition, like CHAR, should be > in terms of an enumeration containing some (minimal) number of elements. > The standard says that CHAR contains at least 256 elements. > In M3 enumerations all have a direct mapping to INTEGER. > So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded > as UTF-8. > More radically, what current code will break if CHAR is expanded to > UTF-32? > The language definition would allow that (there is nothing that says > BITSIZE(CHAR) == 8). > > On Dec 16, 2013, at 4:31 AM, Jay K > wrote: > Any code that was built to handle multiple character code sequences will break. i.e. any correctly implemented code that relies on UTF-16LE as currently provided expanding this range would be inherently non-portable. (... and it could even cause additional problems for when it came to interface with Xorg and Qt.) I'd believe that relying on a fixed range of values is going to be crucial for any kind of character type. You did not expand the CHAR type to 16 or 32bit either though that could even have caused less problems. Writing code that manipulates characters is simply very different from writing code that does some calculation based on integer numbers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Mon Dec 16 17:42:41 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Mon, 16 Dec 2013 17:42:41 +0100 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu> Message-ID: <52AF2D81.2020501@elstel.org> Am 16.12.13 16:00, schrieb Tony Hosking: > Jumping in late to this whole conversation (please forgive any > confusion)... > > I hesitate to define ANY M3 builtin type in terms of C/C++ standards. > Regarding WIDECHAR, realize that its definition, like CHAR, should be > in terms of an enumeration containing some (minimal) number of elements. > The standard says that CHAR contains at least 256 elements. > In M3 enumerations all have a direct mapping to INTEGER. > So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded > as UTF-8. > More radically, what current code will break if CHAR is expanded to > UTF-32? > The language definition would allow that (there is nothing that says > BITSIZE(CHAR) == 8). > Well, if so I could rewrite some code to define as BITS 16 FOR WIDECHAR as WCHAR. Perhaps that would be the way to go. However as Rodney M. Bates has said current WIDECHAR is not BITS 16 for UCHAR. It uses LE encoding rather than host order encoding a fact which one could be quite happy about when it comes to extend Trestle/X11 for widechar support. So even that would fail when it came to interface with X11 (or otherwise one would have to maintain two branches of code all the time; one that does byte swapping and one that does not depending on the host order AND the internally used wchar order which could then differ as well.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 16 23:48:04 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 16 Dec 2013 22:48:04 +0000 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52AF2D81.2020501@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu>, <52AF2D81.2020501@elstel.org> Message-ID: > More radically, what current code will break if CHAR is expanded to UTF-32? > The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). Philosophy: I think you have be careful where you decide something is an abstraction vs. where you keep things unchanged because a lot of code depends on it AND it is adequate, and then introduce new things for new meanings. If something is an abstraction, you need to be sure that - all operations people might want to do are supported - breaking through the abstraction boundary is difficult/impossible, such that you maintain the ability to change the implementation later without breaking things Abstractions can have value, where you change the implementation and imbue existing code with some new features as a result. Such as ability to work with Unicode. For example, INTEGER is abstract enough, I guess, such that we can widen it. It isn't clearly abstract enough such that we can make overflow raise exceptions, because the existing widely used implementation does not. The size of INTEGER is plain to see to its clients and it is easy for them to be (accidentally) dependent on a particular implementation, but we have likely gotten over that by now, by having a good mix of implementations in use. Eventually we will probably see that code won't work if BITSIZE(INTEGER) = 32. Another example is that in C++ std::vector::iterator is very much like T*. In fact, it supports an identical feature set, except that it can be a different type and only mix with itself and not T*. In some implementations, it was in fact T* and there was code that mixed them. The implementation was later changed such as to be a unique type and a bunch of code stopped compiling. This is an example where the implementation wasn't opaque enough. Now presumably it is, so further changes won't cause such problems. (You can convert from iterator to pointer just by "&*" and std::vector is guaranteed contiguous, so the breakage was trivial to fix.) In C and I thought Modula-3 "char" / "CHAR" means "byte". Exactly 8 bits. I know there might be some wierdo Cray environments where all integer types are really 64 bit doubles, but millions of lines of C/C++ code assumes char is byte. Memory is composed of chars, files are composed of chars. Java and C# "fixed" this, char is 16bits there, and there is a new type "byte" or "int8" or "uint8", but for C and I thought Modula-3 we are stuck with char==8 bit byte and that is ok. (The signedness of char remains reasonably abstract and I think most code is ok either way, but I have seen code that depends on it either way.) Does X have an implied little/bigendian for 16 bit characters? If it is host, then we should use host. Windows uses host. Which is pretty much always little (except Xbox 360, and maybe some CE targets?) We would NOT maintain two forks, swapping and not, no matter what. We would have a function "SwapWideCharToLittleEndian" or such, written in C, that would probe the host endian and swap if needed. The probe would be something like: int is_little_endian(void) { union { char a[sizeof(int)]; int b; } c = {{1}}; return c.b == 1; } - Jay Date: Mon, 16 Dec 2013 17:42:41 +0100 From: estellnb at elstel.rivido.de To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com; rodney_bates at lcwb.coop Subject: Re: [M3devel] cm3 does not support Scan.LongInt Am 16.12.13 16:00, schrieb Tony Hosking: Jumping in late to this whole conversation (please forgive any confusion)... I hesitate to define ANY M3 builtin type in terms of C/C++ standards. Regarding WIDECHAR, realize that its definition, like CHAR, should be in terms of an enumeration containing some (minimal) number of elements. The standard says that CHAR contains at least 256 elements. In M3 enumerations all have a direct mapping to INTEGER. So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded as UTF-8. More radically, what current code will break if CHAR is expanded to UTF-32? The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). Well, if so I could rewrite some code to define as BITS 16 FOR WIDECHAR as WCHAR. Perhaps that would be the way to go. However as Rodney M. Bates has said current WIDECHAR is not BITS 16 for UCHAR. It uses LE encoding rather than host order encoding a fact which one could be quite happy about when it comes to extend Trestle/X11 for widechar support. So even that would fail when it came to interface with X11 (or otherwise one would have to maintain two branches of code all the time; one that does byte swapping and one that does not depending on the host order AND the internally used wchar order which could then differ as well.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Tue Dec 17 20:20:17 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Tue, 17 Dec 2013 19:20:17 +0000 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu>, <52AF2D81.2020501@elstel.org> Message-ID: <52B0A3F1.8070509@elstel.org> The Xorg documentation defines: typedef struct { unsigned char byte1; unsigned char byte2; } XChar2b; oopsla: byte1 = N div D + min_byte1 byte2 = N mod D + min_char_or_byte2 so this is big endian in deed (no matter of the arch). Perhaps Modula-3 should then store in host byte order and only convert on request. Defining it to be little endian would impose a certain unnecessary overhead on VAL and ORD and would most likely require byte swapping for Qt which I understand to implement QChar as host byte order (" Most compilers treat it like a unsigned short"). Am 16.12.2013 22:48, schrieb Jay K: > > More radically, what current code will break if CHAR is expanded > to UTF-32? > > The language definition would allow that (there is nothing that > says BITSIZE(CHAR) == 8). > > Philosophy: > > I think you have be careful where you decide something > is an abstraction vs. where you keep things unchanged > because a lot of code depends on it AND it is adequate, and > then introduce new things for new meanings. > > If something is an abstraction, you need to be sure that > - all operations people might want to do are supported > - breaking through the abstraction boundary is difficult/impossible, > such that you maintain the ability to change the implementation later > without breaking things > > Abstractions can have value, where you change the implementation > and imbue existing code with some new features as a result. > Such as ability to work with Unicode. > > For example, INTEGER is abstract enough, I guess, such that we can > widen it. > It isn't clearly abstract enough such that we can make overflow > raise exceptions, because the existing widely used implementation > does not. > > The size of INTEGER is plain to see to its clients and it is easy for > them > to be (accidentally) dependent on a particular implementation, but we > have likely > gotten over that by now, by having a good mix of implementations in use. > Eventually we will probably see that code won't work if > BITSIZE(INTEGER) = 32. > > > Another example is that in C++ std::vector::iterator is very much > like T*. In fact, it supports an identical feature set, except that > it can be a different > type and only mix with itself and not T*. > In some implementations, it was in fact T* and there was code that > mixed them. > The implementation was later changed such as to be a unique type and > a bunch > of code stopped compiling. This is an example where the > implementation wasn't opaque > enough. Now presumably it is, so further changes won't cause such > problems. > (You can convert from iterator to pointer just by "&*" and > std::vector is guaranteed > contiguous, so the breakage was trivial to fix.) > > In C and I thought Modula-3 "char" / "CHAR" means "byte". Exactly 8 > bits. > I know there might be some wierdo Cray environments where all > integer types are really 64 bit doubles, > but millions of lines of C/C++ code assumes char is byte. Memory is > composed of chars, files > are composed of chars. Java and C# "fixed" this, char is 16bits > there, and there is a new type "byte" > or "int8" or "uint8", but for C and I thought Modula-3 we are stuck > with char==8 bit byte and that is ok. > (The signedness of char remains reasonably abstract and I think most > code is ok either way, but > I have seen code that depends on it either way.) > > > Does X have an implied little/bigendian for 16 bit characters? > If it is host, then we should use host. > Windows uses host. Which is pretty much always little (except Xbox > 360, and maybe some CE targets?) > We would NOT maintain two forks, swapping and not, no matter what. > We would have a function "SwapWideCharToLittleEndian" or such, written > in C, > that would probe the host endian and swap if needed. > The probe would be something like: > int is_little_endian(void) { union { char a[sizeof(int)]; int b; } c = > {{1}}; return c.b == 1; } > > > - Jay > > ------------------------------------------------------------------------ > Date: Mon, 16 Dec 2013 17:42:41 +0100 > From: estellnb at elstel.rivido.de > To: hosking at cs.purdue.edu; jay.krell at cornell.edu > CC: m3devel at elegosoft.com; rodney_bates at lcwb.coop > Subject: Re: [M3devel] cm3 does not support Scan.LongInt > > Am 16.12.13 16:00, schrieb Tony Hosking: > > Jumping in late to this whole conversation (please forgive any > confusion)... > > I hesitate to define ANY M3 builtin type in terms of C/C++ standards. > Regarding WIDECHAR, realize that its definition, like CHAR, should > be in terms of an enumeration containing some (minimal) number of > elements. > The standard says that CHAR contains at least 256 elements. > In M3 enumerations all have a direct mapping to INTEGER. > So, I assume that WIDECHAR would be UTF-32, and TEXT could be > encoded as UTF-8. > More radically, what current code will break if CHAR is expanded > to UTF-32? > The language definition would allow that (there is nothing that > says BITSIZE(CHAR) == 8). > > Well, if so I could rewrite some code to define as BITS 16 FOR > WIDECHAR as WCHAR. > Perhaps that would be the way to go. > However as Rodney M. Bates has said current WIDECHAR is not BITS 16 > for UCHAR. > It uses LE encoding rather than host order encoding a fact which one > could be quite > happy about when it comes to extend Trestle/X11 for widechar support. > So even that > would fail when it came to interface with X11 (or otherwise one would > have to maintain > two branches of code all the time; one that does byte swapping and one > that does not > depending on the host order AND the internally used wchar order which > could then > differ as well.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 17 21:55:29 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Dec 2013 20:55:29 +0000 Subject: [M3devel] cm3 does not support Scan.LongInt In-Reply-To: <52B0A3F1.8070509@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924E3A8A@ATLEX04-SRV.SCIRES.LOCAL>, , <52AC36BE.6070309@elstel.org>, <52ADCD6A.10303@lcwb.coop> <48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu>, <52AF2D81.2020501@elstel.org> , <52B0A3F1.8070509@elstel.org> Message-ID: Yuck. I guess they 1) needed a wire format (definitely) and 2) never added a layer above that. We should use host order, yes, "like unsigned short". And btw there isn't necessarily a need to swap. You can always just extract bytes, like what you show: unsigned short u; unsigned char bigendian_bytes[2] = {(unsigned char)(u >> 8), (unsigned char)u}; is correct no matter the host order, maybe slow on big endian hosts, but fast enough. - Jay Date: Tue, 17 Dec 2013 19:20:17 +0000 From: estellnb at elstel.rivido.de To: jay.krell at cornell.edu; estellnb at elstel.rivido.de; hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] cm3 does not support Scan.LongInt The Xorg documentation defines: typedef struct { unsigned char byte1; unsigned char byte2; } XChar2b; oopsla: byte1 = N div D + min_byte1 byte2 = N mod D + min_char_or_byte2 so this is big endian in deed (no matter of the arch). Perhaps Modula-3 should then store in host byte order and only convert on request. Defining it to be little endian would impose a certain unnecessary overhead on VAL and ORD and would most likely require byte swapping for Qt which I understand to implement QChar as host byte order (" Most compilers treat it like a unsigned short"). Am 16.12.2013 22:48, schrieb Jay K: > More radically, what current code will break if CHAR is expanded to UTF-32? > The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). Philosophy: I think you have be careful where you decide something is an abstraction vs. where you keep things unchanged because a lot of code depends on it AND it is adequate, and then introduce new things for new meanings. If something is an abstraction, you need to be sure that - all operations people might want to do are supported - breaking through the abstraction boundary is difficult/impossible, such that you maintain the ability to change the implementation later without breaking things Abstractions can have value, where you change the implementation and imbue existing code with some new features as a result. Such as ability to work with Unicode. For example, INTEGER is abstract enough, I guess, such that we can widen it. It isn't clearly abstract enough such that we can make overflow raise exceptions, because the existing widely used implementation does not. The size of INTEGER is plain to see to its clients and it is easy for them to be (accidentally) dependent on a particular implementation, but we have likely gotten over that by now, by having a good mix of implementations in use. Eventually we will probably see that code won't work if BITSIZE(INTEGER) = 32. Another example is that in C++ std::vector::iterator is very much like T*. In fact, it supports an identical feature set, except that it can be a different type and only mix with itself and not T*. In some implementations, it was in fact T* and there was code that mixed them. The implementation was later changed such as to be a unique type and a bunch of code stopped compiling. This is an example where the implementation wasn't opaque enough. Now presumably it is, so further changes won't cause such problems. (You can convert from iterator to pointer just by "&*" and std::vector is guaranteed contiguous, so the breakage was trivial to fix.) In C and I thought Modula-3 "char" / "CHAR" means "byte". Exactly 8 bits. I know there might be some wierdo Cray environments where all integer types are really 64 bit doubles, but millions of lines of C/C++ code assumes char is byte. Memory is composed of chars, files are composed of chars. Java and C# "fixed" this, char is 16bits there, and there is a new type "byte" or "int8" or "uint8", but for C and I thought Modula-3 we are stuck with char==8 bit byte and that is ok. (The signedness of char remains reasonably abstract and I think most code is ok either way, but I have seen code that depends on it either way.) Does X have an implied little/bigendian for 16 bit characters? If it is host, then we should use host. Windows uses host. Which is pretty much always little (except Xbox 360, and maybe some CE targets?) We would NOT maintain two forks, swapping and not, no matter what. We would have a function "SwapWideCharToLittleEndian" or such, written in C, that would probe the host endian and swap if needed. The probe would be something like: int is_little_endian(void) { union { char a[sizeof(int)]; int b; } c = {{1}}; return c.b == 1; } - Jay Date: Mon, 16 Dec 2013 17:42:41 +0100 From: estellnb at elstel.rivido.de To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com; rodney_bates at lcwb.coop Subject: Re: [M3devel] cm3 does not support Scan.LongInt Am 16.12.13 16:00, schrieb Tony Hosking: Jumping in late to this whole conversation (please forgive any confusion)... I hesitate to define ANY M3 builtin type in terms of C/C++ standards. Regarding WIDECHAR, realize that its definition, like CHAR, should be in terms of an enumeration containing some (minimal) number of elements. The standard says that CHAR contains at least 256 elements. In M3 enumerations all have a direct mapping to INTEGER. So, I assume that WIDECHAR would be UTF-32, and TEXT could be encoded as UTF-8. More radically, what current code will break if CHAR is expanded to UTF-32? The language definition would allow that (there is nothing that says BITSIZE(CHAR) == 8). Well, if so I could rewrite some code to define as BITS 16 FOR WIDECHAR as WCHAR. Perhaps that would be the way to go. However as Rodney M. Bates has said current WIDECHAR is not BITS 16 for UCHAR. It uses LE encoding rather than host order encoding a fact which one could be quite happy about when it comes to extend Trestle/X11 for widechar support. So even that would fail when it came to interface with X11 (or otherwise one would have to maintain two branches of code all the time; one that does byte swapping and one that does not depending on the host order AND the internally used wchar order which could then differ as well.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 19 22:55:30 2013 From: rodney_bates at lcwb.coop (Rodney Bates) Date: Thu, 19 Dec 2013 13:55:30 -0800 Subject: [M3devel] cm3 does not support Scan.LongInt Message-ID: <20131219135530.EA1CECFD@m0005299.ppops.net> An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 19 23:09:34 2013 From: rodney_bates at lcwb.coop (Rodney Bates) Date: Thu, 19 Dec 2013 14:09:34 -0800 Subject: [M3devel] cm3 does not support Scan.LongInt Message-ID: <20131219140934.EA1CEF38@m0005299.ppops.net> An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 19 22:40:52 2013 From: rodney_bates at lcwb.coop (Rodney Bates) Date: Thu, 19 Dec 2013 13:40:52 -0800 Subject: [M3devel] cm3 does not support Scan.LongInt Message-ID: <20131219134052.EA1CEDDB@m0005299.ppops.net> An HTML attachment was scrubbed... URL: