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

Re: [Pharo-dev] displayingProgress on demand

by HernÃ¡n Morales Durand

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. 7, 2015

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

by Ben Coman

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 > > 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. 7, 2015

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

by Robert Withers

Hi Stef, I think of it as a Pharo Driver's License: you can't drive without a license! I would think you would need to verify identity, so I am surprised a notarized image of a form of ID is not required: drivers license or passport. You would need this for any hotel or car rental. It's a trust moment... On 12/07/2015 02:10 PM, stepharo wrote: > PS: I would be forcing everybody to use PGP for email and code, if > you ask me. > Speaking of that, if you look in the Cryptography repository, you will find SMIME & OpenPGP packages... ;-) cheers, Robert

Dec. 7, 2015

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

by Torsten Bergmann

Hi webwarrior (or whatever your name now is ;) There is always room for improvements - even for better guidance on how to become a contributor. There are good reasons to do things the way they are done now - and yes some of them are not optimal because of history or because of sparse time. Lamenting partially anonymous from the outside is neither useful nor polite. Working as a real member/part of the community on the other side can help us all to move forward step by step with a better open source project. If you or any other is really interested in moving with us the registration or signature for sure will not be the show stopper. >Either we skip this stupid formality and continue working on the code, or >I'm out of this. As Stef explained this was not done to bug people or keep them away. We know that it might be cumbersome at first sight - but hey, many people mastered this easily. I guess we even have people who do not drink beer but wine instead :) You can decide on your own how to proceed. Turn away or return. I guess there is only one big hurdle and this one is on your side ;) As you see friendly people continue to invest their time answering your mails although you as the author not even have the time (or will) to reveal your name. IMHO if someone wants to participate in an open source project he has to be "open" on its own side first. It's up to you... Thanks T.

Dec. 7, 2015

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

by H. Hirzel

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

Dec. 7, 2015

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

by stepharo

Hello webwarrior > It would be logical to make contribution to an open source project easy, > right? Yes but not at the price of legal mess. > Well, in bigger projects some burocracy is inevitable, but usually has some > valid reasons behind it. We have strong reasons and they are quite baked by experience. Read below. > > When I made some commits to Spec (while it was on github), it was as easy as > fork->commit->create pull request. And so what? Even if tomorrow Pharo will be on git and work on pull request. Do not expect that you will not have to sign a license agreement. > In Pharo, it's already more complicated: you have to register yourself in > SmalltalkHub, in fogbugz, in mailing lists. Not in mailing-lists. Fogbugz is a professional bug tracker. The company offered it to us. It costs 25$ per month per seat. I thank them for that :). Even if I sometimes hate its interface. I lowers our energy to work to something else than a buggy bug server. > Slices system is also not very > intuitive. Well saving a composite packages to help us manage changes is not that difficult. Press the +slice, enter the number, select the package to save + save. It should ok. > Then CI system spits out some completely unrelated errors. To you think that we are not burned ourselves by such errors? Seriously? > > But OK, I understand that Pharo is unlike, and the team maybe doesn't have > time to migrate to some integrated bugtracker/repository/whatever. We will keep fogbugz because it is working well and it contains important discussions. > > Then people began asking me of my real name - which is already wierd - why > would they need it? I asked you because I prefer to talk to real people and I do not want to be manipulated. Let us imagine that a nasty person would like to hurt Pharo, using a pseudo, and publish stolen GPL code and that we use it and after a while this pseudo disappears and somebody else declare: oh pharo is bad because they steal GPL code so all Pharo is GPL. You see when Ben changed the license of Spec he really wanted to damage us. We had to ask layywers to take actions. And frankly we have something else to do. Do you think that it would be better that I'm called BozoTheClown? I prefer that people understand that when I do a statement this is me that is doing it. Now you can keep you pseudo but we should not accept your code until you sign the license agreement (even if any code publish in the pharo repo is declared as MIT). > > And then someone suggested that I must sign license agreement (which is also > wierd - MIT license doesn't demand anything like that). In the past, we got **burned** by the licensing problems of Squeak. I remember spending something like 30 emails by linux conferences to have the possibility to present Squeak. I had a folder full of such emails. Just because the license of Squeak mentioned fonts that were not even in Squeak anymore. Then ViewPoint spent a year collecting author agreements so that their code could be relicensed into MIT. We then (thanks Gabriel Cotelli) did blind rewrite of orphan methods. Now we have something else to do - see again. > I looked at that agreeement. It requires you to provide name, address (???), > sgin it and send it via snail mail (WTF???). We took the agreement that was used for Squeak by ViewPoint research. Their laywers are probably right. You can scan it and send it to us. You can put a fake address if you want. > No, guys, that is beyond good and evil. > Either we skip this stupid formality and continue working on the code, or > I'm out of this. I'm sorry but we do not accept code into Pharo from people that did not sign the license agreement. We accept as a temporarily measure that you acknowledge that the code is MIT when you publish to the Pharo repo. Now I found the tone of your email a bit misplaced. The Pharo community is a community of friendly people. We know and appreciate each other. We drink beers together and have fun. We are building great software and enjoy it. If printing or even editing a pdf and sending a pdf is a problem for you, do not do it. But it would have taken you, the time to write this mail and everybody would be happy. I imagine that you understand that we do not do that for the fun of it. I prefer to code. Stef PS: I would be forcing everybody to use PGP for email and code, if you ask me.

Dec. 7, 2015

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

by Tudor Girba

Hi, To be more specific: - Copyright is granted by law at creation time in most countries. - MIT is a license that works inside the copyright concept. - The copyright is preserved but the only thing the MIT imposes is the condition that authorship is retained whenever someone uses the code. This implies that we need to know all owners of the code so that we can properly mention them. - The reason why we need you to sign a physical copy is that the body that releases the code, is a French institution, and in France only physical signatures count. Itâs law. We know it is not comfortable, but historically we had problems with the legalities of releasing the code as MIT. The current solution was chosen to ensure that we do not run into any legal problems for the long run. Cheers, Doru > On Dec 7, 2015, at 1:40 PM, philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: > > This ensures the legal thing is no bull and that the rights are indeed MIT. > There has been cases of problems and this ensured that lawyers could quickly sort things out. > > Phil > > On Dec 7, 2015 7:31 PM, "webwarrior" <reg(a)webwarrior.ws> 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, and the team maybe doesn't have > time to migrate to some integrated bugtracker/repository/whatever. > > Then people began asking me of my real name - which is already wierd - why > would they need it? > > And then someone suggested that I must sign license agreement (which is also > wierd - MIT license doesn't demand anything like that). > > I looked at that agreeement. It requires you to provide name, address (???), > sgin it and send it via snail mail (WTF???). > > No, guys, that is beyond good and evil. > Either we skip this stupid formality and continue working on the code, or > I'm out of this. > > > > -- > 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. > -- www.tudorgirba.com "Being happy is a matter of choice."

Dec. 7, 2015

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

by philippe.back＠highoctane.be

This ensures the legal thing is no bull and that the rights are indeed MIT. There has been cases of problems and this ensured that lawyers could quickly sort things out. Phil On Dec 7, 2015 7:31 PM, "webwarrior" <reg(a)webwarrior.ws> 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, and the team maybe doesn't have > time to migrate to some integrated bugtracker/repository/whatever. > > Then people began asking me of my real name - which is already wierd - why > would they need it? > > And then someone suggested that I must sign license agreement (which is > also > wierd - MIT license doesn't demand anything like that). > > I looked at that agreeement. It requires you to provide name, address > (???), > sgin it and send it via snail mail (WTF???). > > No, guys, that is beyond good and evil. > Either we skip this stupid formality and continue working on the code, or > I'm out of this. > > > > -- > 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. > >

Dec. 7, 2015

License agreement - are you kidding me?

by webwarrior

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, and the team maybe doesn't have time to migrate to some integrated bugtracker/repository/whatever. Then people began asking me of my real name - which is already wierd - why would they need it? And then someone suggested that I must sign license agreement (which is also wierd - MIT license doesn't demand anything like that). I looked at that agreeement. It requires you to provide name, address (???), sgin it and send it via snail mail (WTF???). No, guys, that is beyond good and evil. Either we skip this stupid formality and continue working on the code, or I'm out of this. -- 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.

Dec. 7, 2015

DNU when accepting an empty string

by stepharo

Hi if I select a method, and remove eveyrthing and press accept I get a DNU. I would like to fix that for newbies. https://pharo.fogbugz.com/f/cases/17205/DNU-when-accepting-an-empty-string I proposed one fix but I would love to have someone to have a look at it (I'm preparing the lectures for Yaounde and Lome and I'm sick :( Stef

Dec. 7, 2015