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

Re: [Pharo-dev] #fromFileNamed: seems too UNIX-y

by Sven Van Caekenberghe

> On 21 Feb 2015, at 04:02, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sven Van Caekenberghe-2 wrote >> But convenience and clean separation of responsibilities sometimes >> conflict (I mean, do all these object even have to know about files ?) > > Good point! But what do we do? The logic is too complicated for users to > roll-their-own... It would be nice to have a collaborating role like > dataSource, but the problem is that there are no specific FileReference > sub-types and we don't want to cloud up FileReference on the other side... For me, this is an open design question. Someone should think hard about this and propose something. Existing conversions like #asXYZ or #as: come in the picture as well. Sven

Feb. 21, 2015

Re: [Pharo-dev] #fromFileNamed: seems too UNIX-y

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > But convenience and clean separation of responsibilities sometimes > conflict (I mean, do all these object even have to know about files ?) Good point! But what do we do? The logic is too complicated for users to roll-their-own... It would be nice to have a collaborating role like dataSource, but the problem is that there are no specific FileReference sub-types and we don't want to cloud up FileReference on the other side... ----- Cheers, Sean -- View this message in context: http://forum.world.st/fromFileNamed-seems-too-UNIX-y-tp4806748p4806763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 21, 2015

Re: [Pharo-dev] #fromFileNamed: seems too UNIX-y

by Sven Van Caekenberghe

Yes. But convenience and clean separation of responsibilities sometimes conflict (I mean, do all these object even have to know about files ?) > On 20 Feb 2015, at 23:42, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Now that we have a beautiful File API, would it make sense to use real file > objects everywhere instead of string passing? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/fromFileNamed-seems-too-UNIX-y-tp4806748.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 20, 2015

#fromFileNamed: seems too UNIX-y

by Sean P. DeNigris

Now that we have a beautiful File API, would it make sense to use real file objects everywhere instead of string passing? ----- Cheers, Sean -- View this message in context: http://forum.world.st/fromFileNamed-seems-too-UNIX-y-tp4806748.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 20, 2015

Protocols, Privacy, and Extensions - NOT One Big Happy Family

by Sean P. DeNigris

It will be fun to have these concepts distinguished on their own some day :) How do I create a form from a file? Let's check the instance creation protocol... Nothing there. Hmm... I recall something about ImageMorph... In ImageMorph's class comment: "Form fromFileNamed: 'myGraphicsFileName'..." WHT?! Go back to browsing Form's class-side "Protocol": *Graphics-Files -> #fromFileNamed: Ugh..... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Protocols-Privacy-and-Extensions-NOT-One-Big-Happy-Fa… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 20, 2015

Re: [Pharo-dev] Why was #asLegalSelector removed?

by Sean P. DeNigris

stepharo wrote > I prefer to die because I have moved than because I feared to move because > at the end I will die. Perfectly said :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Why-was-asLegalSelector-removed-tp4806427p4806745.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 20, 2015

Re: [Pharo-dev] CI Server still down...

by stepharo

Thanks doru :) Le 20/2/15 11:22, Tudor Girba a Ã©crit : > Thank you for keeping an eye on this. > > Just a note: while the servers being down can induce some frustration > we should remember that INRIA is very kind to offer this support for > our community. So, thanks for all the hard work that happens behind > the scene! > > Cheers, > Doru > > > > On Fri, Feb 20, 2015 at 11:03 AM, Marcus Denker > <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > > Hi, > > CI Servers are still down. > > Until they are up we can not do any integration nor run the > automatic check > on submitted things. > > Marcus > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Feb. 20, 2015

Re: [Pharo-dev] Why was #asLegalSelector removed?

by stepharo

Damien I decided that living is about mistakes so I will not stress and continue to improve the platform. And from time to time I will do a mistake and we will fix it. I prefer to die because I have moved than because I feared to move because at the end I will die. Stef Le 19/2/15 18:43, Damien Pollet a Ã©crit : > I'm usually extremely apprehensive of changing code I don't own, to > the point I â sadly â contribute nearly nothing to Pharo. Now, > cleaning the platform â and in this case, by cleaning, I really mean > hazmat suits, industrial grade acid, and flame throwers â is going to > break things. I'm all for a process to help others follow such > changes, but if we want a process to work, it has to be even simpler > than not having a process. In any case I don't want to have to stress > over touching platform code. > > I think it would make sense to publish a configuration for > DeprecationFinder in the configuration browser. Does it work on any > Pharo image, or is it written on top of Moose ? > > About #asComment : since class comments are free text, any string will > do and there is no escapement sequences to enforce. Maybe ideally we > would have string un/escaper objects responsible for translating > between free text and and specific encodings (comments, strings, > regexes, URLsâ¦) > > On 19 February 2015 at 15:05, stephan <stephan(a)stack.nl > <mailto:stephan@stack.nl>> wrote: > > The way this was handled can be improved. It is sometimes > difficult for us not in Lille > to find out what is going on. > > - a specific issue name helps us notice what changes > - check where code is used. DeprecationFinder works for that > (and should add more repos and team projects). > > And a specific one: the rename from #asSmalltalkComment > to #asComment is problematic. There are 2 kinds of thing > casually known as comments: the comment text in a method, > and the class comment. The method name should reflect that. > > Stephan > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

Feb. 20, 2015

Re: [Pharo-dev] How to get rid of GT-Playground

by Tudor Girba

Interesting! I sometimes notice the phenomenon of image growing and I suspected it has to do with the playground/inspector. We should investigate a memory leak related to announcements. I will try to look into this. Could you open an issue? This is a must fix for Pharo 4. Cheers, Doru On Fri, Feb 20, 2015 at 2:17 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > instances ? > > If you > open a fresh image and > change the setting to use the old workspace > open a workspace and execute: > GTPlayground allInstances size > -> 1 > > There is already one instance. I tried to get rid of this instance but > I couldn't find a way. > I think this instance is responsible for issue 14928 > <https://pharo.fogbugz.com/default.asp?14928>: > SystemNavigation default obsoleteClasses > -> an Array(AnObsoleteGLMPageScroller AnObsoleteGLMPagerScrollMorph) > > And this in turn, is repsonsible for undeleteable references to > AnObsoleteKMUntypeableSingleKeyCombination. > I need this for issue 14936 <https://pharo.fogbugz.com/default.asp?14936> > > any idea? > > > nicolai > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 20, 2015

Re: [Pharo-dev] MCVersionInfo: 10% of the image

by Thierry Goubier

Le 20/02/2015 15:41, Marcus Denker a Ã©crit : > Hi, > > The current Pharo4 contains *a lot* of MCVersionInfo instances. > > MCVersionInfo allInstances size > > 11095 > > The hold on to strings, Date, UUIDâ¦ a lot of stuff. All in all, this is around 10% of the current > image. > > If you do > > MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. > > you image is a couple of MB smaller. > > In the past, when this information started to be >8MB, we did that. With the bad effect > that we can not merge anymore across this boundary: we kill the past. You can still merge across that boundary, but you need to do it in git, not in Monticello. > Now this information is of course continained in the last MCZ file, too (all of them contain > the complete historyâ¦) > So would the following work? > > -> we set the âancestorsâ of MCVersionInfo to #reload > -> the accessor, when it sees #reload, takes the name, deduces from that the package, > and goes to the repo to load the ancestry info from the MCZFile. > > This means that e.g when saving a MCZFile, it would first re-create history info and then save > it completely (like now), yet someone who just uses the system would never need to have this > info in the image. Yes, this could work. But I'll probably try a subclass of MCVersionInfo with a kind of lazy loading of the ancestry chain (in a weak array so that it gets eaten away if not used). And the weak array would ensure that you don't overuse memory without having to use become: Like that, on git, I could be faster and not write the whole ancestry at all. I just did something a bit reverse with MCDependencyVersion for GitFileTree: I added a MCResolvedDependencyVersion and it worked. Up to you. Thierry

Feb. 20, 2015