- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] [squeak-dev] Re: [Unicode] Class Unicode --> data from unicode.org

by EuanM

Yes, clean room approaches are overkill. Obviousness in code has long been found to be a protection against copyright. For instance, you cannot copyright a programme in BASIC that says 10 Print "Hello World" 20 GOTO 10 (And by copyright, I mean prevent anyone else in the world from typing that programme and distributing their copy). One of the great advantage of writing weird, convoluted or just plain dense clever code is that it becomes non-obvious and therefore indubitably covered under copyright. The mere fact that code has been written somewhere, does *not* make it unusable elsewhere. (As an aside, I tend to write plain, straightforward code. Asserting copyright on a lot of it would be hard). One of the great advantages of not doing my coding in the USA is that Stallman would have to come after me in my jurisdiction, not his. Probably a special case of security through obscurity. Usual disclaimer. IANAL. Just interested in these issues from having developed legal support systems (including litigation support systems). As Hannes says, we haven't hit an area of the project where it is an issue yet. But personally, I'm quite relaxed about looking at the Gnu Smalltalk codebase. I'm pretty certain I can re-implement without violating copyright. In the same way I can prÃ©cis and paraphrase a short story without violating the copyright of the short story. Can any of you tell me the story of Hansel and Gretel without violating the copyright of some recently published re-telling of the tale? I'm pretty certain you could. Please remember that it is much easier to avoid copyright violation than it is to avoid patent violation, in these sorts of cases. None of the Gnu Smalltalk base is patented. Cheers, Euan (back to reading the ICU) On 7 December 2015 at 16:06, Martin BÃ¤hr <mbaehr(a)email.archlab.tuwien.ac.at> wrote: > Excerpts from Martin BÃ¤hr's message of 2015-12-07 16:17:28 +0100: >> randal schwartz suggests a cleanroom approach, though i personally think that >> is overkill. if a cleanroom approach were really necessary than i would never >> be allowed to switch jobs because once i have been working on one companys >> private code i would be tainted for life, as i could accidentally reproduce the >> same code in my next job. >> >> however, either you get the GNU-smalltalk authors to relicense their unicode >> classes under the MIT license, or they will need to be rewritten from scratch. >> >> i would suggest asking them in the name of having a common code-base for all >> smalltalks. > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/123817.… > is worth reading in that context: > > So it's mainly an issue of being willing to cooperate. I think all GNU > Smalltalk people (almost all?) are and it's also true at least for some > Squeak people. If somebody took a package (several thousands lines of > code, etc.) wholesale, ported it to Squeak, and licensed it under MIT on > SqueakMap that would be copyright violation. But everything can be done > "cum grano salis". Nobody is going to sue you if you copy an interface > from GNU Smalltalk, reimplement in Squeak (for fun!), but you did look > at the method comments in GNU Smalltalk -- and OMG maybe you got a > glimpse of the source code just below! Copyright does not protect > having similar implementations. > > I think we're all for interoperability and for exchange of opinions > within the communities. > > so there you have the open invitation to go and ask... > > and read this > http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/123838.… > for a good summary on the issue. > > 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] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

by EuanM

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 Dale Henrichs

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