December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Unified Property API and persistent properties (Pharo 5)

by stepharo

> Hello, > > If we look at methods, properties are not persistent in the code. Pragmas are (which are > âspecialâ kind of properties. > > We should do the same for all the other properties: the lower property level is not saved > in source, so we can store *anything* there. > But we can add a âhigher levelâ. E.g. some form of class Pragmas. > > And for packages, I would want to store what is now in the Manifest there and make *that* > persistent (by storing it in the MCZ). > > This would a) make the whole Manifest mode much nicer, b) allow for true package comments > and c) we would have a real place for Package meta-data. + 1 > > In general, we should move away from storing data just as arrays or strings in methods. > Instead we should have a true model for the data and store that. > > In the same direction, we should find a way to store data like icons and other âfilesâ nicelyâ¦ > > Marcus > >> On 08 Dec 2015, at 19:26, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> In Pharo 5 the "properties" API is unified (means you can associate properties >> to classes, methods, packages, ...). Really cool and a good step toward a unified >> and more flexible system. >> >> Exampel: >> >> |pck| >> pck := #'Foo-Kernel' asPackage. >> pck propertyAt: #'lastModified' put: DateAndTime now asString. >> pck propertyAt: #'generatedUsing' put: 'Pharo DynaCase'. >> pck properties >> >> So far it looks like the package properties are still transient - that means >> when you save the package and load in another image they will be empty again. >> Havent tried for class properties, ... >> >> Will this change in the near future so they are persistent? I wonder what the >> plans an next steps are in this area. >> >> Thanks >> T. >> > >

Dec. 9, 2015

Re: [Pharo-dev] License agreement - are you kidding me?

by Ben Coman

On Wed, Dec 9, 2015 at 4:44 AM, EuanM <euanmee(a)gmail.com> wrote: > "partially anonymous" > > The correct word is "pseudonimity". > > In UK law, as long as there is no intent to defraud, you can call > yourself anything you like. > > In UK, you can provide signatures digitally, completely legally. > > UK law is has a long tradition of sorting out legal issues between > two-third party jurisdictions. > > Perhaps Pharo ought to do it's work under a legal system that is more > completely designed to handle issues of international commerce? > Knowing that INRIA as a French organisation provided substantial support to kickstart Pharo, without which Pharo may not have happened, I fully understand why Pharo's is governed by French laws. The funder gets to make to rules. The situation may be different once the Pharo Consortium builds a substantial enough income stream to be self governing - but you would gave to be pretty confident to leave the backup of the family nest. > Or perhaps it should be a all-French affair. Non sequitur? cheers -ben

Dec. 9, 2015

Re: [Pharo-dev] Unicode Support

by Guillermo Polito

> On 8 dic 2015, at 10:07 p.m., EuanM <euanmee(a)gmail.com> wrote: > > "No. a codepoint is the numerical value assigned to a character. An > "encoded character" is the way a codepoint is represented in bytes > using a given encoding." > > No. > > A codepoint may represent a component part of an abstract character, > or may represent an abstract character, or it may do both (but not > always at the same time). > > Codepoints represent a single encoding of a single concept. > > Sometimes that concept represents a whole abstract character. > Sometimes it represent part of an abstract character. Well. I do not agree with this. I agree with the quote. Can you explain a bit more about what you mean by abstract character and concept? > > This is the key difference between Unicode and most character encodings. > > A codepoint does not always represent a whole character. > > On 7 December 2015 at 13:06, Henrik Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> >> On 07 Dec 2015, at 1:05 , EuanM <euanmee(a)gmail.com> wrote: >> >> Hi Henry, >> >> To be honest, at some point I'm going to long for the for the much >> more succinct semantics of healthcare systems and sports scoring and >> administration systems again. :-) >> >> codepoints are any of *either* >> - the representation of a component of an abstract character, *or* >> eg. "A" #(0041) as a component of >> - the sole representation of the whole of an abstract character *or* of >> - a representation of an abstract character provided for backwards >> compatibility which is more properly represented by a series of >> codepoints representing a composed character >> >> e.g. >> >> The "A" #(0041) as a codepoint can be: >> the sole representation of the whole of an abstract character "A" #(0041) >> >> The representation of a component of the composed (i.e. preferred) >> version of the abstract character â« #(0041 030a) >> >> â« (#00C5) represents one valid compatibility form of the abstract >> character â« which is most properly represented by #(0041 030a). >> >> â« (#212b) also represents one valid compatibility form of the abstract >> character â« which is most properly represented by #(0041 030a). >> >> With any luck, this satisfies both our semantic understandings of the >> concept of "codepoint" >> >> Would you agree with that? >> >> In Unicode, codepoints are *NOT* an abstract numerical representation >> of a text character. >> >> At least not as we generally understand the term "text character" from >> our experience of non-Unicode character mappings. >> >> >> I agree, they are numerical representations of what Unicode refers to as >> characters. >> >> >> codepoints represent "*encoded characters*" >> >> >> No. a codepoint is the numerical value assigned to a character. An "encoded >> character" is the way a codepoint is represented in bytes using a given >> encoding. >> >> and "a *text element* ... >> is represented by a sequence of one or more codepoints". (And the >> term "text element" is deliberately left undefined in the Unicode >> standard) >> >> Individual codepoints are very often *not* the encoded form of an >> abstract character that we are interested in. Unless we are >> communicating to or from another system (Which in some cases is the >> Smalltalk ByteString class) >> >> >> >> >> i.e. in other words >> >> *Some* individual codepoints *may* be a representation of a specific >> *abstract character*, but only in special cases. >> >> The general case in Unicode is that Unicode defines (a) >> representation(s) of a Unicode *abstract character*. >> >> The Unicode standard representation of an abstract character is a >> composed sequence of codepoints, where in some cases that sequence is >> as short as 1 codepoint. >> >> In other cases, Unicode has a compatibility alias of a single >> codepoint which is *also* a representation of an abstract character >> >> There are some cases where an abstract character can be represented by >> more than one single-codepoint compatibility codepoint. >> >> Cheers, >> Euan >> >> >> I agree you have a good grasp of the distinction between an abstract >> character (characters and character sequences which should be treated >> equivalent wrt, equality / sorting / display, etc.) and a character (which >> each have a code point assigned). >> That is besides the point both Sven and I tried to get through, which is the >> difference between a code point and the encoded form(s) of said code point. >> When you write: >> "and therefore encodable in UTF-8 as compatibility codepoint e9 hex >> and as the composed character #(0065 00b4) (all in hex) and as the >> same composed character as both >> #(feff 0065 00b4) and #(ffef 0065 00b4) when endianness markers are >> included" >> >> I's quite clear you confuse the two. 0xFEFF is the codepoint of the >> character used as bom. >> When you state that it can be written ffef (I assume you meant FFFE), you >> are again confusing the code point and its encoded value (an encoded value >> which only occurs in UTF16/32, no less). >> >> When this distinction is clear, it might be easier to see that value in that >> Strings are kept as Unicode code points arrays, and converted to encoded >> forms when entering/exiting the system. >> >> Cheers, >> Henry >> >

Dec. 9, 2015

Re: [Pharo-dev] Unified Property API and persistent properties (Pharo 5)

by Marcus Denker

Hello, If we look at methods, properties are not persistent in the code. Pragmas are (which are âspecialâ kind of properties. We should do the same for all the other properties: the lower property level is not saved in source, so we can store *anything* there. But we can add a âhigher levelâ. E.g. some form of class Pragmas. And for packages, I would want to store what is now in the Manifest there and make *that* persistent (by storing it in the MCZ). This would a) make the whole Manifest mode much nicer, b) allow for true package comments and c) we would have a real place for Package meta-data. In general, we should move away from storing data just as arrays or strings in methods. Instead we should have a true model for the data and store that. In the same direction, we should find a way to store data like icons and other âfilesâ nicelyâ¦ Marcus > On 08 Dec 2015, at 19:26, Torsten Bergmann <astares(a)gmx.de> wrote: > > In Pharo 5 the "properties" API is unified (means you can associate properties > to classes, methods, packages, ...). Really cool and a good step toward a unified > and more flexible system. > > Exampel: > > |pck| > pck := #'Foo-Kernel' asPackage. > pck propertyAt: #'lastModified' put: DateAndTime now asString. > pck propertyAt: #'generatedUsing' put: 'Pharo DynaCase'. > pck properties > > So far it looks like the package properties are still transient - that means > when you save the package and load in another image they will be empty again. > Havent tried for class properties, ... > > Will this change in the near future so they are persistent? I wonder what the > plans an next steps are in this area. > > Thanks > T. >

Dec. 9, 2015

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

by Max Leske

> On 07 Dec 2015, at 17:17, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > OK Max. In the last version you can find the "likely" final version. It's extremely simple, easy to use, and very very little code. Only one override. All WADynamicVariables subclasses handled automatically. All you need to do is to register the handler: > > app filter configuration at: #exceptionHandler put: WAPharoDebuggererErrorHandler. > > It works for exceptions and both Halt too. The only limit is only the "last opened debugger" will be correct and all previous will be wrong since they will be using another values for dynamic variables. > > I will see if people want to integrate this directly into Seaside. Iâll give it a try tomorrow. > > > On Sat, Dec 5, 2015 at 11:36 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> Can you try with the latest version that does not use LPC if it works? > > Works perfectly! > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 9, 2015

Re: [Pharo-dev] displayingProgress on demand

by HernÃ¡n Morales Durand

http://www.smalltalkhub.com/#!/~hernan/ProgressBarInstaller Public write access Cheers, HernÃ¡n 2015-12-08 20:40 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Hi John, > > Thank you for your feedback and help! > > I started a ProgressBarInstaller using your corrections. Unfortunately > SmalltalkHub is not working for me right now but will check tomorrow and > share the link. > > Best regards, > > HernÃ¡n > > > 2015-12-08 13:56 GMT-03:00 John Brant <brant(a)refactoryworkers.com>: > >> On 12/7/2015 5:27 PM, HernÃ¡n Morales Durand wrote: >> >>> >>> but now I am failing to see how to replace #collect: with >>> #collect:thenDo: using the rewriter: >>> >>> http://ws.stfx.eu/MOWS947F000O >>> >> >> You don't need to first search using the RBParseTreeSearcher. The >> RBParseTreeRewriter works with search patterns. What your code is really >> doing is searching for the literal pattern that it found from the >> RBParseTreeSearcher in the FooClass>>foo: method: >> >> aString asFileReference entries >> collect: [ : fileEntry | self openOnFileNamed: fileEntry fullName >> ] >> >> It then tries to replace it with the pattern: >> >> `@collection collect: `@arg1 >> thenDo: [ : fileEntry | >> index := index + 1. >> JobProgress progress: (0.1 * index); >> title: 'Procesing...', index asString ] >> >> However, since neither `@collection nor `@arg1 appear in your search >> pattern, you get an error. >> >> Here's a version that works: >> >> | cm rewriteRule replacement | >> cm := FooClass >> #foo:. >> replacement := '`@collection collect: `@arg1 >> thenDo: [ : fileEntry | >> index := index + 1. >> JobProgress progress: (0.1 * index); >> title: ''Procesing...'', index asString ]'. >> rewriteRule := RBParseTreeRewriter new >> replace: '`@collection collect: `@arg1' >> with: replacement. >> rewriteRule executeTree: cm parseTree. >> rewriteRule tree newSource >> >> >> Essentially, I used the same search pattern you used, but I used it for >> the RBParseTreeRewriter and removed all of the RBParseTreeSearcher code. If >> you want to change all #collect: sends in a method, then you should >> probably change `@aCollection and `@arg1 to ``@aCollection and ``@arg1. >> >> >> John Brant >> >> >

Dec. 9, 2015

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

by EuanM

"The ffi_ligature (U+FB03) is not decomposed, because it has a compatibility mapping, not a canonical mapping." Standard's text from Table 7 "what the standard seems to say is, that the ffi ligature is not equivalent to plain ffi because, if i write a string with the ligature, then it is a different string than plain "ffi", because both forms are printable. on the other hand Ã¤ and a" (two different encodings for Ã¤) are the same, because the printed forms are always identical." --Martin I agree with that interpretation. I'm struggling to be clear about the consequences for equality testing. For sorting - every sort order can be created to go along with every encoding, so I suppose it just depends on which pre-assembled sort order is used. On 9 December 2015 at 02:36, Martin BÃ¤hr <mbaehr(a)email.archlab.tuwien.ac.at> wrote: > Excerpts from Martin BÃ¤hr's message of 2015-12-09 02:43:35 +0100: >> Excerpts from EuanM's message of 2015-12-09 01:59:43 +0100: >> > http://www.unicode.org/reports/tr15/#Stable_Code_Points >> > Table 7, the discussion of Ligatures, (which uses the ligature of >> > "ffi" as its example) >> >> Ã is not a ligature of ss, but is a different character. > > rereading this, i think i am wrong, in that this has nothing to do with Ã vs ss. > > looking at the standard i also don't understand your conclusion. > > what the standard seems to say is, that the ffi ligature is not equivalent to > plain ffi because, if i write a string with the ligature, then it is a > different string than plain "ffi", because both forms are printable. > on the other hand Ã¤ and a" (two different encodings for Ã¤) are the same, > because the printed forms are always identical. > > however that doesn't mean that they are sorted differently. > german sorting rules for example explicitly state that Ã and ss are sorted the same. > (at least according to wikipedia :-) > and surely, ffi ligature and ffi are sorted the same too. > > greetings, martin. > > -- > eKita - the online platform for your entire academic life > -- > chief engineer eKita.co > pike programmer pike.lysator.liu.se caudium.net societyserver.org > secretary beijinglug.org > mentor fossasia.org > foresight developer foresightlinux.org realss.com > unix sysadmin > Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Dec. 9, 2015

Re: [Pharo-dev] Help needed: old issues issue tracker entries

by EuanM

Excellent. Can I suggest that in future they are simply closed, rather than re-assigned? On 3 December 2015 at 06:35, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Am 03.12.2015 1:08 vorm. schrieb "EuanM" <euanmee(a)gmail.com>: >> >> I had an issue assigned against me, which I have not the time nor the >> knowledge to fix. >> >> (Inconstant aspect ratio of Desktop background image). >> >> Can I suggest it is given to someone who knows the Desktop GUI codebase? >> >> (If I was in a position to fix it, I would have just submitted a fix, >> not a bug report) > > It was assigned to "everyone". And just assigned to you after a fix was > provided. > That issue is already closed. > >> >> On 2 December 2015 at 13:42, webwarrior <reg(a)webwarrior.ws> wrote: >> > Case 16725 - Merge changes from spec github repository. >> > 2 subcases are resolved, 2 other need decision. Nothing time-consuming - >> > just decide if we integrate them or mark as wontfix. >> > >> > >> > Case 15927 - Menu is broken when contained in a list. >> > This is much more complicated, it's even not clear which class >> > (TransfromMorph or MenuItemMorph) is bugged. >> > I tried to fix it myself, but had no success. >> > >> > >> > >> > -- >> > View this message in context: >> > http://forum.world.st/Help-needed-old-issues-issue-tracker-entries-tp486426… >> > Sent from the Pharo Smalltalk Developers mailing list archive at >> > Nabble.com. >> > >>

Dec. 9, 2015

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

by EuanM

"Accessing ICU library from Squeak/Pharo via NativeBoost interface FFI. This is my port to Squeak/Pharo - to have same interface available under VASmalltalk and Pharo/Squeak." On 9 December 2015 at 01:30, EuanM <euanmee(a)gmail.com> wrote: > I've just discovered the ICU's official listing for an ICU wrapper for > Smalltalk: > https://schrievkrom.wordpress.com/tag/icu/ > > Listed on > http://site.icu-project.org/related > > In turn, it mentions: > > ICU: Initial source code for Squeak/Pharo. > http://ss3.gemstone.com/ss/ICU.html > by Marten Feldtmann, Jan van de Sandt > > ICU-V2 Unicode support > http://ss3.gemstone.com/ss/ICU-V2.html > also by Marten Feldtmann, Jan van de Sandt > > On 9 December 2015 at 00:59, EuanM <euanmee(a)gmail.com> wrote: >> http://www.unicode.org/reports/tr15/#Stable_Code_Points >> Table 7, the discussion of Ligatures, (which uses the ligature of >> "ffi" as its example) >> >> Every time I think I'm about to grokk this standard, something like >> this crops up. >> >> >> >> On 9 December 2015 at 00:43, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>> >>> On 12/08/2015 04:33 PM, EuanM wrote: >>>> >>>> Reading up http://www.unicode.org/reports/tr15/#Examples >>>> >>>> The Unicode standard seems to require you never to make >>>> aGermanStrasse >>>> equivalent in a sort order to the ligatured version, >>>> aGermanStraÃe >>> >>> I didn't see anything in the examples related to this ... could you be a bit >>> more specific? >>> >>> Dale

Dec. 9, 2015

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

by EuanM

I've just discovered the ICU's official listing for an ICU wrapper for Smalltalk: https://schrievkrom.wordpress.com/tag/icu/ Listed on http://site.icu-project.org/related In turn, it mentions: ICU: Initial source code for Squeak/Pharo. http://ss3.gemstone.com/ss/ICU.html by Marten Feldtmann, Jan van de Sandt ICU-V2 Unicode support http://ss3.gemstone.com/ss/ICU-V2.html also by Marten Feldtmann, Jan van de Sandt On 9 December 2015 at 00:59, EuanM <euanmee(a)gmail.com> wrote: > http://www.unicode.org/reports/tr15/#Stable_Code_Points > Table 7, the discussion of Ligatures, (which uses the ligature of > "ffi" as its example) > > Every time I think I'm about to grokk this standard, something like > this crops up. > > > > On 9 December 2015 at 00:43, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: >> >> >> On 12/08/2015 04:33 PM, EuanM wrote: >>> >>> Reading up http://www.unicode.org/reports/tr15/#Examples >>> >>> The Unicode standard seems to require you never to make >>> aGermanStrasse >>> equivalent in a sort order to the ligatured version, >>> aGermanStraÃe >> >> I didn't see anything in the examples related to this ... could you be a bit >> more specific? >> >> Dale

Dec. 9, 2015