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

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

by Peter Uhnak

On 12/07, webwarrior wrote: > It would be logical to make contribution to an open source project easy, > right? > Well, in bigger projects some burocracy is inevitable, but usually has some > valid reasons behind it. > > When I made some commits to Spec (while it was on github), it was as easy as > fork->commit->create pull request. > In Pharo, it's already more complicated: you have to register yourself in > SmalltalkHub, in fogbugz, in mailing lists. Slices system is also not very > intuitive. Then CI system spits out some completely unrelated errors. > > But OK, I understand that Pharo is unlike Not every project lives in GitHub. For Ruby, Mozilla, Chromium, Python, PHP, ... you have to register to their bug tracker. After all, these projects predate both GitHub AND git. > Then people began asking me of my real name - which is already wierd - why > would they need it? The Pharo community is quite small and many people know each other personally (have met on Pharo Days, ESUG, are coworkers, ...). So working with someone who goes well out of his way to remain anonymous may be uncomfortable for some. Not to mention that such behavior may seem strange for OSS, but that's your call. > > And then someone suggested that I must sign license agreement (which is also > wierd - MIT license doesn't demand anything like that). The MIT may not demand something like that, however signing License Agreement is also not completely unheard of, see for example https://en.wikipedia.org/wiki/Contributor_License_Agreement#Users This includes names like Python, Apache, jQuery, Django, ... not exactly small fishes. > I looked at that agreeement. It requires you to provide name, address (???), > sgin it and send it via snail mail (WTF???). See above. Also note that copyright in many countries recognized pseudonyms as valid authors. (I am not familiar with French law, but I will assume it is harmonized across EU) Of course in case of a dispute you would need to be able to prove that you are the pseudonym (otherwise you yourself would loose the rights). So considering your position (revealing your real name would undermine all the work you've put into protecting it), going with a pseudonym if you are indeed willing to contribute may be the best course of action. > -- > View this message in context: http://forum.world.st/License-agreement-are-you-kidding-me-tp4865853.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- Peter

Dec. 8, 2015

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

by H. Hirzel

Dale Thank you for your answer with links to the ICU library and the notes about classes in Gemstone. Noteworthy that you have a class Utf8 as a subclass of ByteArray. I understand that Gemstone uses the ICU library and thus does not implement the algorithms in Smalltalk. I am currently looking into what the ICU library provides. I found as well a Ruby library [2] which implements CLDR [3] It has methods like this "Alphabetize a list using regular Ruby sort:" $> ["Art", "Wasa", "Ãlg", "Ved"].sort $> ["Art", "Ved", "Wasa", "Ãlg"] Alphabetize a list using TwitterCLDRâs locale-aware sort: $> ["Art", "Wasa", "Ãlg", "Ved"].localize(:de).sort.to_a $> ["Ãlg", "Art", "Ved", "Wasa"] I hope that given such an example it would not be too difficult to reimplement a similar sort algorithm in Squeak/Cuis/Pharo. Currently the interest is in getting sorting done in a cross-dialect-way. --Hannes [2] https://blog.twitter.com/2012/twittercldr-improving-internationalization-su… [3] Unicode Common Locale Data Repository http://cldr.unicode.org/index On 12/7/15, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > Hannes, > > For GemStone, we are using the ICU library[1]. We have Unicode7, > Unicode16 and Unicode32 classes (subclasses of CharacterCollection) for > internal Strings and the class Utf8 (a subclass of ByteArray) for Utf8 > encoded strings ... > > The ICU library provides the primitive implementations for working with > the Unicode* and Utf8 classes > > When we started considering Unicode support, we looked at what it would > take to support collation - our main reason for looking at Unicode in > the first place) -- and we saw just how complicated the collation rules > can be[2], we were glad to see that someone had already done the hard > work[1]... > > Reconciling our legacy String implementations (String, DoubleByteString, > and QuadByteString) with the Unicode* classes was also interesting, > because the rules for Unicode equality and our legacy equality > implementation were not quite compatible. > > If you are interested in more information, I can share additional > details ... > > Dale > > [1] http://site.icu-project.org/ > [2] http://unicode.org/reports/tr10/ > > On 12/07/2015 11:54 AM, H. Hirzel wrote: >> Hello >> >> According to http://www.unicode.org/cldr/charts/27/collation/de.html the >> German >> phonebook sort order is >> >> a A Ã¤ Ã ÄÌ ÄÌ Ç Ç áº¡Ì áº Ì á¸Ì á¸Ì b B c C d D e E f F g G h H i I j J k K >> l L m M n N o O Ã¶ Ã Ç«Ì ÇªÌ È« Èª Æ¡Ì Æ Ì á»£Ì á»¢Ì á»Ì á»Ì p P q Q r R s S ss Ã t >> T u U Ã¼ Ã Ç Ç Ç Ç Ç Ç Å³Ì Å²Ì Ç Ç Æ°Ì Æ¯Ì á»±Ì á»°Ì á»¥Ì á»¤Ì á¹³Ì á¹²Ì á¹·Ì á¹¶Ì á¹µÌ á¹´Ì v >> V w W x X y Y z Z >> >> I wonder why it looks like this. A lot of characters which never >> appear in a German text. >> >> >> For Spanish there is 'traditional' and 'standard' >> >> http://www.unicode.org/cldr/charts/27/collation/es.html >> >> standard a A Ã¡ Ã b B c C d D e E Ã© Ã f F g G h H i I Ã Ã j J k K l L m >> M n N Ã± Ã ÅÌ ÅÌ á¹Ì á¹Ì á¹Ì á¹Ì á¹Ì á¹Ì o O Ã³ Ã p P q Q r R s S t T u U Ãº Ã >> Ã¼ Ã v V w W x X y Y z Z >> >> traditional a A Ã¡ Ã b B c C ch Ch CH cÄ¥ CÄ¥ CÄ¤ cÈ CÈ CÈ cá¸§ Cá¸§ Cá¸¦ cá¸£ Cá¸£ >> Cá¸¢ cá¸© Cá¸© Cá¸¨ cá¸¥ Cá¸¥ Cá¸¤ cá¸« Cá¸« Cá¸ª cáº Cáº d D e E Ã© Ã f F g G h H i I Ã Ã j >> J k K l L ll Ll LL lÄº LÄº LÄ¹ lÄ¾ LÄ¾ LÄ½ lÄ¼ LÄ¼ LÄ» lá¸· Lá¸· Lá¸¶ lá¸¹ Lá¸¹ Lá¸¸ lá¸½ Lá¸½ >> Lá¸¼ lá¸» Lá¸» Lá¸º m M n N Ã± Ã ÅÌ ÅÌ á¹Ì á¹Ì á¹Ì á¹Ì á¹Ì á¹Ì o O Ã³ Ã p P q Q r R s >> S t T u U Ãº Ã Ã¼ Ã v V w W x X y Y z Z >> >> And French is not easily found >> http://www.unicode.org/cldr/charts/27/collation/index.html >> or seems to be defined elsewhere >> >> http://unicode.org/repos/cldr/tags/release-27/common/collation/fr.xml >> >> Suggestions and hints are welcome >> >> --Hannes >> _______________________________________________ >> Cuis mailing list >> Cuis(a)jvuletich.org >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > _______________________________________________ > Cuis mailing list > Cuis(a)jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by HernÃ¡n Morales Durand

Hi To let you know finally I used the RewriteRuleBuilder http://myfuncoding.blogspot.cz/2015/02/video-presentation-of-rewrite-tool.h… which generated the rule and installed the code (the only minor detail is that class methods are not browsed by the rule browser): [ : job | | index | index := 0. job title: 'Starting.'. ``@object1 collect: `@block1 thenDo: [ :fileEntry | index := index + 1. JobProgress progress: 0.1 * index; title: ' Procesing ' , index asString ] ] asJob run Cheers, HernÃ¡n 2015-12-07 20:27 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Hi Thierry > > 2015-12-07 14:43 GMT-03:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Hi HernÃ¡n, >> >> Le 07/12/2015 18:16, HernÃ¡n Morales Durand a Ã©crit : >> >>> Hi Sven >>> >>> 2015-12-06 17:34 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu >>> <mailto:sven@stfx.eu>>: >>> >>> There is still #do:displayingProgress: >>> >>> There is Job. >>> >>> In general, the collection API should not be concerned with GUI >>> matters, does it ? >>> >>> >>> Believe me when you're executing a large workflow processing 50Gb files >>> with 5 other people expecting feedback from the screen, the least of >>> your concerns is the purity of collection API. I don't know what other >>> coders do, kick your co-workers off the room? Sit to see a blank Pharo >>> screen? >>> To me the key is to have feedback from the system without having to >>> change your 20 iterators in a group of client classes where you NEED to >>> see progress. >>> >>> Anyway I agree with you Collection should not have GUI dependencies, >>> that's the reason I took a different approach and that's why I asked >>> with an expression like: >>> >>> SmalltalkImage setDisplayProgressTo: MyClass. >>> >>> with such kind of expression you never touch the Collection API. You >>> just walk MyClass for every enumeration messsage send (of your interest) >>> and perform a transformation. Note the same "technique" could be applied >>> for logging and/or profiling. >>> >> >> Yes. The Jejak tracer uses a similar technique. I'd guess others do as >> well. >> > > Will have a look to Jejak, thanks. > > >> We can't have equivalents of all collection methods for displaying >>> progress, nor can it be a (semi-) global setting. >>> >>> >>> Sure, that would be the anti-object technology :) >>> >>> So I implemented a prototype which injects JobProgress code in methods >>> using RBParseSearchTree. On uninstall I plan to recover the previous >>> version of marked methods. No need to touch the Collection API at all, >>> nor a setting. I am sure the same could be done with MethodWrappers but >>> RB can manipulate AST nodes. >>> >>> However if there is a better idea I would love to hear about it. >>> >> >> Could you put your RBParseTreeRewriter scripts somewhere? I'm interested. >> >> > Ok for the first part create a FooClass>>foo: method > > foo: aString > > aString asFileReference entries > collect: [ : fileEntry | self openOnFileNamed: fileEntry fullName ] > > this one injects a node inside the Job block: > > http://ws.stfx.eu/5H7LNMMLIXEX > > For the next one, first add > > RBSequenceNode>>addNode: aNode after: anotherNode > | index | > index := self indexOfNode: anotherNode. > index = 0 > ifTrue: [ ^ self addNode: aNode ]. > statements := statements asOrderedCollection > add: aNode afterIndex: index; > yourself. > aNode parent: self. > ^ aNode > > but now I am failing to see how to replace #collect: with #collect:thenDo: > using the rewriter: > > http://ws.stfx.eu/MOWS947F000O > > Regards, > > HernÃ¡n > >

Dec. 8, 2015

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

by H. Hirzel

Thank you for the answers about the sorting sequence. I was just wondering about something like ÄÌ or á¸Ì As it is a collation order given by the Unicode consortium let's take it as is. --Hannes On 12/8/15, Max Leske <maxleske(a)gmail.com> wrote: > >> On 07 Dec 2015, at 23:58, Ben Coman <btc(a)openInWorld.com> wrote: >> >> On Tue, Dec 8, 2015 at 3:54 AM, H. Hirzel <hannes.hirzel(a)gmail.com> >> wrote: >>> Hello >>> >>> According to http://www.unicode.org/cldr/charts/27/collation/de.html the >>> German >>> phonebook sort order is >>> >>> a A Ã¤ Ã ÄÌ ÄÌ Ç Ç áº¡Ì áº Ì á¸Ì á¸Ì b B c C d D e E f F g G h H i I j J k K >>> l L m M n N o O Ã¶ Ã Ç«Ì ÇªÌ È« Èª Æ¡Ì Æ Ì á»£Ì á»¢Ì á»Ì á»Ì p P q Q r R s S ss Ã t >>> T u U Ã¼ Ã Ç Ç Ç Ç Ç Ç Å³Ì Å²Ì Ç Ç Æ°Ì Æ¯Ì á»±Ì á»°Ì á»¥Ì á»¤Ì á¹³Ì á¹²Ì á¹·Ì á¹¶Ì á¹µÌ á¹´Ì v >>> V w W x X y Y z Z >>> >>> I wonder why it looks like this. A lot of characters which never >>> appear in a German text. >> >> Foreign residents? >> cheers -ben > > There are lot of turkish and eastern european names in the german phone > book, yes. > >> >>> >>> For Spanish there is 'traditional' and 'standard' >>> >>> http://www.unicode.org/cldr/charts/27/collation/es.html >>> >>> standard a A Ã¡ Ã b B c C d D e E Ã© Ã f F g G h H i I Ã Ã j J k K l >>> L m >>> M n N Ã± Ã ÅÌ ÅÌ á¹Ì á¹Ì á¹Ì á¹Ì á¹Ì á¹Ì o O Ã³ Ã p P q Q r R s S t T u U Ãº Ã >>> Ã¼ Ã v V w W x X y Y z Z >>> >>> traditional a A Ã¡ Ã b B c C ch Ch CH cÄ¥ CÄ¥ CÄ¤ cÈ CÈ CÈ cá¸§ Cá¸§ Cá¸¦ cá¸£ >>> Cá¸£ >>> Cá¸¢ cá¸© Cá¸© Cá¸¨ cá¸¥ Cá¸¥ Cá¸¤ cá¸« Cá¸« Cá¸ª cáº Cáº d D e E Ã© Ã f F g G h H i I Ã Ã j >>> J k K l L ll Ll LL lÄº LÄº LÄ¹ lÄ¾ LÄ¾ LÄ½ lÄ¼ LÄ¼ LÄ» lá¸· Lá¸· Lá¸¶ lá¸¹ Lá¸¹ Lá¸¸ lá¸½ Lá¸½ >>> Lá¸¼ lá¸» Lá¸» Lá¸º m M n N Ã± Ã ÅÌ ÅÌ á¹Ì á¹Ì á¹Ì á¹Ì á¹Ì á¹Ì o O Ã³ Ã p P q Q r R s >>> S t T u U Ãº Ã Ã¼ Ã v V w W x X y Y z Z >>> >>> And French is not easily found >>> http://www.unicode.org/cldr/charts/27/collation/index.html >>> or seems to be defined elsewhere >>> >>> http://unicode.org/repos/cldr/tags/release-27/common/collation/fr.xml >>> >>> Suggestions and hints are welcome >>> >>> --Hannes > > >

Dec. 8, 2015

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

by Max Leske

> On 07 Dec 2015, at 23:58, Ben Coman <btc(a)openInWorld.com> wrote: > > On Tue, Dec 8, 2015 at 3:54 AM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> Hello >> >> According to http://www.unicode.org/cldr/charts/27/collation/de.html the German >> phonebook sort order is >> >> a A Ã¤ Ã ÄÌ ÄÌ Ç Ç áº¡Ì áº Ì á¸Ì á¸Ì b B c C d D e E f F g G h H i I j J k K >> l L m M n N o O Ã¶ Ã Ç«Ì ÇªÌ È« Èª Æ¡Ì Æ Ì á»£Ì á»¢Ì á»Ì á»Ì p P q Q r R s S ss Ã t >> T u U Ã¼ Ã Ç Ç Ç Ç Ç Ç Å³Ì Å²Ì Ç Ç Æ°Ì Æ¯Ì á»±Ì á»°Ì á»¥Ì á»¤Ì á¹³Ì á¹²Ì á¹·Ì á¹¶Ì á¹µÌ á¹´Ì v >> V w W x X y Y z Z >> >> I wonder why it looks like this. A lot of characters which never >> appear in a German text. > > Foreign residents? > cheers -ben There are lot of turkish and eastern european names in the german phone book, yes. > >> >> For Spanish there is 'traditional' and 'standard' >> >> http://www.unicode.org/cldr/charts/27/collation/es.html >> >> standard a A Ã¡ Ã b B c C d D e E Ã© Ã f F g G h H i I Ã Ã j J k K l L m >> M n N Ã± Ã ÅÌ ÅÌ á¹Ì á¹Ì á¹Ì á¹Ì á¹Ì á¹Ì o O Ã³ Ã p P q Q r R s S t T u U Ãº Ã >> Ã¼ Ã v V w W x X y Y z Z >> >> traditional a A Ã¡ Ã b B c C ch Ch CH cÄ¥ CÄ¥ CÄ¤ cÈ CÈ CÈ cá¸§ Cá¸§ Cá¸¦ cá¸£ Cá¸£ >> Cá¸¢ cá¸© Cá¸© Cá¸¨ cá¸¥ Cá¸¥ Cá¸¤ cá¸« Cá¸« Cá¸ª cáº Cáº d D e E Ã© Ã f F g G h H i I Ã Ã j >> J k K l L ll Ll LL lÄº LÄº LÄ¹ lÄ¾ LÄ¾ LÄ½ lÄ¼ LÄ¼ LÄ» lá¸· Lá¸· Lá¸¶ lá¸¹ Lá¸¹ Lá¸¸ lá¸½ Lá¸½ >> Lá¸¼ lá¸» Lá¸» Lá¸º m M n N Ã± Ã ÅÌ ÅÌ á¹Ì á¹Ì á¹Ì á¹Ì á¹Ì á¹Ì o O Ã³ Ã p P q Q r R s >> S t T u U Ãº Ã Ã¼ Ã v V w W x X y Y z Z >> >> And French is not easily found >> http://www.unicode.org/cldr/charts/27/collation/index.html >> or seems to be defined elsewhere >> >> http://unicode.org/repos/cldr/tags/release-27/common/collation/fr.xml >> >> Suggestions and hints are welcome >> >> --Hannes

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by HernÃ¡n Morales Durand

Hi Henrik I checked, thank you for sharing an elegant approach (although my issue with automatic code transformation remains). May you comment why you implemented another progress bar? Does support stacked progress bars? Do you plan to add labels? HernÃ¡n 2015-12-07 21:04 GMT-03:00 Henrik Nergaard <henrin10(a)student.uia.no>: > Here is my take on it. > > > > http://smalltalkhub.com/#!/~Latsabben/GafletFremgangFremviser > > > > Best regards, > > Henrik > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *HernÃ¡n Morales Durand > *Sent:* Tuesday, December 8, 2015 12:28 AM > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* Re: [Pharo-dev] displayingProgress on demand > > > > Hi Thierry > > > > 2015-12-07 14:43 GMT-03:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > Hi HernÃ¡n, > > Le 07/12/2015 18:16, HernÃ¡n Morales Durand a Ã©crit : > > Hi Sven > > 2015-12-06 17:34 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>>: > > There is still #do:displayingProgress: > > There is Job. > > In general, the collection API should not be concerned with GUI > matters, does it ? > > > Believe me when you're executing a large workflow processing 50Gb files > with 5 other people expecting feedback from the screen, the least of > your concerns is the purity of collection API. I don't know what other > coders do, kick your co-workers off the room? Sit to see a blank Pharo > screen? > To me the key is to have feedback from the system without having to > change your 20 iterators in a group of client classes where you NEED to > see progress. > > Anyway I agree with you Collection should not have GUI dependencies, > that's the reason I took a different approach and that's why I asked > with an expression like: > > SmalltalkImage setDisplayProgressTo: MyClass. > > with such kind of expression you never touch the Collection API. You > just walk MyClass for every enumeration messsage send (of your interest) > and perform a transformation. Note the same "technique" could be applied > for logging and/or profiling. > > > Yes. The Jejak tracer uses a similar technique. I'd guess others do as > well. > > > > Will have a look to Jejak, thanks. > > > > We can't have equivalents of all collection methods for displaying > progress, nor can it be a (semi-) global setting. > > > Sure, that would be the anti-object technology :) > > So I implemented a prototype which injects JobProgress code in methods > using RBParseSearchTree. On uninstall I plan to recover the previous > version of marked methods. No need to touch the Collection API at all, > nor a setting. I am sure the same could be done with MethodWrappers but > RB can manipulate AST nodes. > > However if there is a better idea I would love to hear about it. > > > Could you put your RBParseTreeRewriter scripts somewhere? I'm interested. > > > > Ok for the first part create a FooClass>>foo: method > > foo: aString > > aString asFileReference entries > collect: [ : fileEntry | self openOnFileNamed: fileEntry fullName ] > > this one injects a node inside the Job block: > > http://ws.stfx.eu/5H7LNMMLIXEX > > For the next one, first add > > RBSequenceNode>>addNode: aNode after: anotherNode > | index | > index := self indexOfNode: anotherNode. > index = 0 > ifTrue: [ ^ self addNode: aNode ]. > statements := statements asOrderedCollection > add: aNode afterIndex: index; > yourself. > aNode parent: self. > ^ aNode > > but now I am failing to see how to replace #collect: with #collect:thenDo: > using the rewriter: > > > http://ws.stfx.eu/MOWS947F000O > > Regards, > > HernÃ¡n >

Dec. 8, 2015

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

by HernÃ¡n Morales Durand

Hello webwarrior, Most of your claims are correct, and you could be the best coder but there *is* a trust factor. And part of such trust is built by making life easier to the core team. Maybe the pharo team could implement "closed verification" for cases like yours? Now how do we trust you do not want to corrupt the behavior of the critical code base? Do you have inner source? HernÃ¡n 2015-12-07 20:47 GMT-03:00 webwarrior <reg(a)webwarrior.ws>: > Considering that there are a couple of responses and the fact that you > guys are so easily offended, I will not answer everyone but just state > couple of theses. > > > 0. I will not reveal my real name, because I value privacy. Nickname is > sufficient for identification purposes. Any other information (real > name, address, etc.) is not needed for actually contributing code. Think > of principle of least privilege. > > 1. I could easily make up some human-looking name (Satoshi Nakamoto > anyone?), but will not do it out of principle (see #0). > > 2. Knowing contributor's "real" name would not guard you against any > possible malicious actions from him, because it can't be verified (see > #1). One can also make up address, and even signature, if needed, and I > bet no one would spot it. > > 3. I don't buy argument about requirements of some organizations. Linux > kernel is used in billions of devices and by countless organizations, > and I highly doubt that contributing to Linux requires anything like > singing an agreement or whatever. > > 4. Even in paid services checking a checkbox is usually sufficient for > accepting any license/ToS. > > 5. My intentions are mostly of pragmatic nature. To make things that I > use (and that can be useful to Pharo users) be in upstream. > > 6. I don't care whether you drink beer, your political views, or your > interpersonal relationships (however story with Benjamin shows that > perhaps everything's not as great as you paint it). These are all > irrelevant to Pharo development, from my point of view at least. > > 7. If you don't agree with my arguments and stick to your rules, go for > it. I'm in no position to tell you what's the right thing to do. I'll > just end this discussion and leave. > > ------------------------------ > View this message in context: Re: License agreement - are you kidding me? > <http://forum.world.st/License-agreement-are-you-kidding-me-tp4865853p486591…> > > Sent from the Pharo Smalltalk Developers mailing list archive > <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> at > Nabble.com. >

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by Henrik Nergaard

Here is my take on it. http://smalltalkhub.com/#!/~Latsabben/GafletFremgangFremviser Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of HernÃ¡n Morales Durand Sent: Tuesday, December 8, 2015 12:28 AM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] displayingProgress on demand Hi Thierry 2015-12-07 14:43 GMT-03:00 Thierry Goubier <thierry.goubier(a)gmail.com<mailto:thierry.goubier@gmail.com>>: Hi HernÃ¡n, Le 07/12/2015 18:16, HernÃ¡n Morales Durand a Ã©crit : Hi Sven 2015-12-06 17:34 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu<mailto:sven@stfx.eu> <mailto:sven@stfx.eu<mailto:sven@stfx.eu>>>: There is still #do:displayingProgress: There is Job. In general, the collection API should not be concerned with GUI matters, does it ? Believe me when you're executing a large workflow processing 50Gb files with 5 other people expecting feedback from the screen, the least of your concerns is the purity of collection API. I don't know what other coders do, kick your co-workers off the room? Sit to see a blank Pharo screen? To me the key is to have feedback from the system without having to change your 20 iterators in a group of client classes where you NEED to see progress. Anyway I agree with you Collection should not have GUI dependencies, that's the reason I took a different approach and that's why I asked with an expression like: SmalltalkImage setDisplayProgressTo: MyClass. with such kind of expression you never touch the Collection API. You just walk MyClass for every enumeration messsage send (of your interest) and perform a transformation. Note the same "technique" could be applied for logging and/or profiling. Yes. The Jejak tracer uses a similar technique. I'd guess others do as well. Will have a look to Jejak, thanks. We can't have equivalents of all collection methods for displaying progress, nor can it be a (semi-) global setting. Sure, that would be the anti-object technology :) So I implemented a prototype which injects JobProgress code in methods using RBParseSearchTree. On uninstall I plan to recover the previous version of marked methods. No need to touch the Collection API at all, nor a setting. I am sure the same could be done with MethodWrappers but RB can manipulate AST nodes. However if there is a better idea I would love to hear about it. Could you put your RBParseTreeRewriter scripts somewhere? I'm interested. Ok for the first part create a FooClass>>foo: method foo: aString aString asFileReference entries collect: [ : fileEntry | self openOnFileNamed: fileEntry fullName ] this one injects a node inside the Job block: http://ws.stfx.eu/5H7LNMMLIXEX For the next one, first add RBSequenceNode>>addNode: aNode after: anotherNode | index | index := self indexOfNode: anotherNode. index = 0 ifTrue: [ ^ self addNode: aNode ]. statements := statements asOrderedCollection add: aNode afterIndex: index; yourself. aNode parent: self. ^ aNode but now I am failing to see how to replace #collect: with #collect:thenDo: using the rewriter: http://ws.stfx.eu/MOWS947F000O Regards, HernÃ¡n

Dec. 8, 2015

CollectionValueHolder additions

by Peter Uhnak

Hi, when (any) ValueHolder changes, a ValueChanged announcement is fired. My question: Would it be a good idea to add ValueAdded and ValueRemoved for CollectionValueHolder? Otherwise there's no way to meaningfully observe changes. -- Peter

Dec. 8, 2015

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

by webwarrior

Considering that there are a couple of responses and the fact that you guys are so easily offended, I will not answer everyone but just state couple of theses. 0. I will not reveal my real name, because I value privacy. Nickname is sufficient for identification purposes. Any other information (real name, address, etc.) is not needed for actually contributing code. Think of principle of least privilege. 1. I could easily make up some human-looking name (Satoshi Nakamoto anyone?), but will not do it out of principle (see #0). 2. Knowing contributor's "real" name would not guard you against any possible malicious actions from him, because it can't be verified (see #1). One can also make up address, and even signature, if needed, and I bet no one would spot it. 3. I don't buy argument about requirements of some organizations. Linux kernel is used in billions of devices and by countless organizations, and I highly doubt that contributing to Linux requires anything like singing an agreement or whatever. 4. Even in paid services checking a checkbox is usually sufficient for accepting any license/ToS. 5. My intentions are mostly of pragmatic nature. To make things that I use (and that can be useful to Pharo users) be in upstream. 6. I don't care whether you drink beer, your political views, or your interpersonal relationships (however story with Benjamin shows that perhaps everything's not as great as you paint it). These are all irrelevant to Pharo development, from my point of view at least. 7. If you don't agree with my arguments and stick to your rules, go for it. I'm in no position to tell you what's the right thing to do. I'll just end this discussion and leave. -- View this message in context: http://forum.world.st/License-agreement-are-you-kidding-me-tp4865853p486591… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 7, 2015