May 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Cannot load Pillar

by Cyril Ferlicot

I'll make a new configuration un few hours Le jeudi 14 mai 2015, Alexandre Bergel <alexandre.bergel(a)me.com> a Ã©crit : > Hi! > > When I load Pillar, I have the following: > This package depends on the following classes: > PRWarning > You must resolve these dependencies before you will be able to load these > definitions: > PRParameterWarning > > > I simply do > -=-=-=-=-=-=-=-=-= > Gofer new > smalltalkhubUser: 'Pier' project: 'Pillar'; > configuration; > load. > (Smalltalk globals at: #ConfigurationOfPillar) load > -=-=-=-=-=-=-=-=-= > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Cheers Cyril Ferlicot

May 14, 2015

Re: [Pharo-users] Wait two seconds

by Sean P. DeNigris

Pierre Chanson wrote > this one is not > {'bc'. 'ab'}..{'ab'. 'bc'} Interestingly, `#('bc' 'ab').{'ab'. 'bc'}` works N.B. in general you can leave out the extra $. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Wait-two-seconds-tp4825675p4826362.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 14, 2015

Re: [Pharo-users] funny idea Symbol vs. Selector

by Alexandre Bergel

Back in the time of ModularSmalltalk and S#, we had fierce discussions on a symbol resolution to implement selector namespaces. We had something like that: Symbol + Namespace = selector As a result, several namespaces could define a method with the same selector on a same class, thus avoiding clashes between class extensions. Cheers, Alexandre > On May 13, 2015, at 9:46 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Igor Stasenko wrote >> Symbol + ??? => Selector >> >> give me a strong reason. >> >> i like the idea of shrinking a Symbol's protocol and putting it into >> lean and clean place - Symbol. > > While fixing Issue 15523: "Code Cruft Rule Only Matches One-Liners", I > reeeeeally wanted: > Selector > UnarySelector > BinarySelector > KeywordSelector > so that I could double dispatch. It made me remember this old interesting > thread. So, in addition to the conceptual clarity reification would provide, > this provided a clear (to me) case of technical benefit. We could eliminate > the ~20 or so senders of isUnary, ~20 of isBinary, and ~20 isKeyword in the > Kernel for a start... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/funny-idea-Symbol-vs-Selector-tp2335774p4826193.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 14, 2015

Re: [Pharo-users] Enhancing ICal library

by Sean P. DeNigris

Stephan Eggermont wrote > This is open source. You can commit in the repo. One point of confusion is probably that there is no indication (like we used to have in sqs) in StHub's web interface whether repos are publicly writable or not ----- Cheers, Sean -- View this message in context: http://forum.world.st/Enhancing-ICal-library-tp4825990p4826255.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 13, 2015

Re: [Pharo-users] Image growing size

by Peter UhnÃ¡k

As I have discovered recently I quite regularly have large images (500+ MB); the reason seems to be combination of memory leaks, Roassal (maybe Athens), GUI, and a LOT of saving while having all those things opened. But Image cleanup tends to shrink it back to tens of megabytes. Personally I don't care about the size but saving the image progressively slows done as it gets bigger. Peter On Wed, May 13, 2015 at 4:27 PM, Laura Risani <laura.risani(a)gmail.com> wrote: > Nice! > > On Wed, May 13, 2015 at 8:51 AM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> laura wrote >> > Also the discussion brought up very interesting msg collaborations >> > snippets >> > and system features for future reference! >> >> I compiled them at >> https://github.com/pharo-project/pharo-core/wiki/Memory-Hogs >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Image-growing-size-tp4803428p4826162.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >

May 13, 2015

Re: [Pharo-users] Enhancing ICal library

by Stephan Eggermont

On 13/05/15 15:38, Julien Delplanque wrote: > So, I throw the fork on github and provide a compatibility package on > smalltalkhub? Yes. Forking is ok if it is difficult to maintain compatibility, and that is definitely not the case here. Paul has made improvements to the code a few months back, so it doesn't look like an abandoned code base. The Pharo support for git(hub) is not yet at the level where it is easy to support forking smalltalkhub repos on github and merging back. Soon, I hope. > I wanted to improve the lib, but I don't own it and there is no "pull > request" system on smalltalk hub. > I don't want to bother the owner of the repository with changes I want > to do. He probably has others things to do. Don't need to. This is open source. You can commit in the repo. Mailing lists are not as nice as pull requests for collaboration, but work well enough. > Also, I don't use and don't have interest in squeak and gemstone (for > the moment) so providing compatibility with pharo 2-3-4, squeak and > gemstone... I will not do that. That is ok. The people using squeak, older pharo and gemstone will fix their own problems. The only thing needed is separating between the things you do in a generic package, and those you do in the pharo (4/5) specific one. > Finally, I already made some improvements in some objects of the model > part what should I do? Avoid making people do the work twice. This code is likely to be used in production by some people, so needs to keep working in old versions too. Stephan

May 13, 2015

Re: [Pharo-users] Enhancing ICal library

by Sven Van Caekenberghe

If it is just the Url class, then I can't imagine the difference between the old Url class and the new ZnUrl to be very large. An abstraction layer is probably not needed, both should understand #asUrl and should have quite a lot of common methods. The HTTP client is another story ;-) On a more philosophical note, there is not much point in us trying to make Pharo better, adding new and improved API, and then not using it because external libraries must be compatible (of course this is the choice of the authors). Also, doing things x-platform in Smalltalk is hard, especially if you do not use the other dialects. I would not want this to be a burden for newcomers to contribute. Julien, talk again to Paul, you wil figure something out together, I am sure. If you need help to translate between the old and new, just ask. Sven > On 13 May 2015, at 16:03, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > EstebanLM wrote >> It is not a demand. Just a suggestion. You can do whatever you want and >> nobody can impose you how to handle your code :) > > +1. And to clarify, the suggestion is not that /you/ implement code for > Squeak, Pharo, and Gemstone, but that you abstract a Url layer so that other > interested parties can. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Enhancing-ICal-library-tp4825990p4826198.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

May 13, 2015

Re: [Pharo-users] Image growing size

by Laura Risani

Nice! On Wed, May 13, 2015 at 8:51 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > laura wrote > > Also the discussion brought up very interesting msg collaborations > > snippets > > and system features for future reference! > > I compiled them at > https://github.com/pharo-project/pharo-core/wiki/Memory-Hogs > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Image-growing-size-tp4803428p4826162.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

May 13, 2015

Re: [Pharo-users] Enhancing ICal library

by Sean P. DeNigris

EstebanLM wrote > It is not a demand. Just a suggestion. You can do whatever you want and > nobody can impose you how to handle your code :) +1. And to clarify, the suggestion is not that /you/ implement code for Squeak, Pharo, and Gemstone, but that you abstract a Url layer so that other interested parties can. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Enhancing-ICal-library-tp4825990p4826198.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 13, 2015

Re: [Pharo-users] Enhancing ICal library

by Julien Delplanque

Well, I don't think I'm going to create/keep the compatibility, the purpose of the fork is to make it fully compatible with Pharo and I don't want to be responsible of the compatibility with others smalltalk. I also think that it's going to be harder and harder to keep compatibility between Pharo and other smalltalk because (for example) of packages that will be deprecated in an implementation and not in another etc... Julien On 13/05/15 15:42, Esteban Lorenzano wrote: >> On 13 May 2015, at 15:38, Julien Delplanque <julien(a)tamere.eu> wrote: >> >> So, I throw the fork on github and provide a compatibility package on smalltalkhub? > It is not a demand. Just a suggestion. You can do whatever you want and nobody can impose you how to handle your code :) > > Esteban >

May 13, 2015