October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] do we need handleDisabledKey:

by Gary Chambers

Catching up on emails after being away... will check once software update completes... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, September 24, 2010 7:01 PM Subject: [Pharo-project] do we need handleDisabledKey: > hi gary > > do we need handleDisabledKey: because this is not defined on the new > editorHierarchy? > > http://code.google.com/p/pharo/issues/detail?id=3003 > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 4, 2010

Re: [Pharo-project] CodeMorph >> text should return an instance of Text but return a String

by Fernando olivero

ISSUE 2902: CodeMorph removal . Done, added the change set and set the issue to fixed. Fernando On Oct 1, 2010, at 12:58 PM, Fernando olivero wrote: > Yes, i've been busy so i couldn't finish this issue. > > Because CodeMorph comes from Gaucho, and until now there was no need for it in the Pharo-Core. so i will remove it, and possibly when the need arises will propose its re-inclusion. > > Fernando > pd: the idea behind CodeMorph is to have a specialized NewTextMorph for dealing with Methods sources, Class definitions. But now i have second thoughts, because i have the impression that having diferent Editors ( subclasses of TextEditor or SmalltalkEditor) should do the trick. > > On Oct 1, 2010, at 12:02 PM, Cyrille Delaunay wrote: > >> I just saw that there is propositions to remove CodeMorph: >> >> http://code.google.com/p/pharo/issues/detail?id=2902&q=CodeMorph&colspec=ID… >> >> So maybe the best fix will be to remove all the tests related ? :) >> >> 2010/10/1 Cyrille Delaunay <cy.delaunay(a)gmail.com> >> In pharo 1.2, NewTextMorphTests>>#testFullMethodName raise an error. This error happen when calling: >> >> CodeMorph >> defaultStyledText >> | text attribute | >> text := self text. >> text addAttribute: ( self newTextColorAttribute: Color black ). >> ^ text. >> >> text is a string, and therefore it does not understand 'addAttribute'. The value return by 'text' depends on the value of the instance variable 'adapter'. adapter can have different values according the way we initialize the CodeMorph. One of them is: >> >> beFullMethodName >> aspect := #selector. >> adapter := [:selector| target methodClass name , '.' , self selectorWithArguments ]. >> >> The block return a String and I guess the right code should be >> >> beFullMethodName >> aspect := #selector. >> adapter := [:selector| (target methodClass name , '.' , self selectorWithArguments) asText ] >> >> ??. >> >> I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3031 >> >> <ATT00001..txt> > > <ATT00001..txt>

Oct. 4, 2010

[Pharo-project] Ocean (was Re: Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm))

by Noury Bouraqadi

On 3 oct. 2010, at 16:28, Schwab,Wilhelm K wrote: > For Ocean to succeed, you either have to work really hard to make non-blocking calls (I'm thinking of SSL sockets), or you need the ability to call functions on OS threads. The calls need to block their calling Process and let the other Processes run as though nothing is happening. > You're right. Another option is having a multi-threaded VM. Eliot seem to work on it. So far we're working on cleaning up the design of basic functionalities before going on. Then, we'll try to find a workaround for non-blocking calls. All ideas are welcome :-) BTW, some people (you included) proposed to help for the Ocean project. Luc and I want to thank you and we are happy that others are willing to help. We thought about the best way to integrate others help. Our conclusion is that we should first do alone (luc and me) the reference design, before integrating other developers. So, we all can work on solid foudations. Noury

Oct. 4, 2010

Re: [Pharo-project] [Seaside] Pharocasts: Getting started with Pier CMS

by Tudor Girba

Nice job: http://www.piercms.com/blog/getting-started-screencast Cheers, Doru On 3 Oct 2010, at 22:19, laurent laffont wrote: > Pier is a content management system that is light, flexible and free. > > This screencast shows > - how to setup Pier for a minimal web site > - configure persistency. > > http://www.pharocasts.com/2010/10/getting-started-with-pier-cms.html > > Recorded by Damien Cassou, voice by Christoph Budzinsky, edited by Laurent Laffont. This video is a real team work :) > > Cheers, > > Laurent Laffont > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- www.tudorgirba.com "Some battles are better lost than fought."

Oct. 4, 2010

Re: [Pharo-project] Pool dictionaries = 'private'?

by Yanni Chiu

On 03/10/10 10:58 PM, Schwab,Wilhelm K wrote: > > OSProcess Command Shell still warns about MVC; it's a drag, because > it happens several minutes into my build process :( I hope you have an automated build process. > ... There are clearly potenial problems with packages that create > hassles on load, and there should be a way to detect them before > saving if at all possible. Telling me about it on load is not > nearly as much help as would be telling me, prior to saving, that > something is wrong, at a time when I can fix it. IMHO, the simplest way to detect load problems is to load the code (with an automated build). Soon after you save your code, run your build. Then you'll have the red flag raised at the time you want it, so you can fix the problem.

Oct. 4, 2010

Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)

by Igor Stasenko

On 3 October 2010 13:03, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Â On 03.10.2010 11:59, Igor Stasenko wrote: >> >> On 3 October 2010 12:36, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> Â wrote: >>> >>> Â On 03.10.2010 05:47, Igor Stasenko wrote: >>>> >>>> On 3 October 2010 03:13, Henrik Sperre Johansen >>>> <henrik.s.johansen(a)veloxit.no> Â Â wrote: >>>>> >>>>> Â On 02.10.2010 19:01, Igor Stasenko wrote: >>>>>> >>>>>> On 2 October 2010 19:47, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >>>>>> Â wrote: >>>>>>> >>>>>>> Hi igor >>>>>>> >>>>>>> do you understand why the previous definition was >>>>>>> >>>>>>> cachedDefinitions >>>>>>> Â Â Â Â Definitions ifNil: [Definitions := WeakIdentityKeyDictionary >>>>>>> new. >>>>>>> Â WeakArray addWeakDependent: Definitions]. >>>>>>> Â Â Â Â ^ Definitions >>>>>>> >>>>>> i don't. :) >>>>>> >>>>>> It just a way to free memory as fast as possible. >>>>>> But its really not worth spending so much CPU in order to save few >>>>>> bytes of memory. >>>>> >>>>> Without registering the dict for finalization, the values won't ever be >>>>> removed with the current implementation. >>>> >>>> They are removed. After each package load/unload operation. >>>> I don't see a reason to do this more often. >>> >>> If they are removed explicitly, then yes. But then again, if that's the >>> case, why use a weak dictionary in the first place? >> >> i don't know much about MC to tell for sure. >> >>>>> Which can be somewhat hampering to performance once you have lots of >>>>> nil-keyed elements all stashed from index 1 and onwards after a rehash. >>>>> >>>> In Pharo, weak dict knows how to reuse expired associations: >>>> >>> And when do they expire? Only when they are either finalized, or removed >>> explicitly. >>> So if you do neither, they will stay indefinately without being >>> removed/reused. >> >> no. they expiring when key become nil. >> > You'd think so, yes. > However, see implementor of WeakKeyAssociation>>#expired, and senders of > #expire. > Oh, you are right. They are not reused unless marked as expired (associatin's value == association). But concerning speed, then my benchmark should show an opposite results. :) cache holding a pairs of: compiledmethod -> MCMethodDefinitions. Compiled methods usually gone when you either recompiling class or removing it from system. This is why i put #finalizeValues after package loading/unloading. But if you think it worth adding it into some other places, then tell me where. Still, putting it into FinalizationDependents is bad idea. > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig.

Oct. 4, 2010

Re: [Pharo-project] MC: somebody has to say this

by Lukas Renggli

Gofer? On Monday, October 4, 2010, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > I am starting to make a 1.1.1 image; the first step is to save packages so they can hopefully load in the new image. Â The first step of that is to save my package called Migrate and then to ask it to save everything else. Â Bugs in Migrate or not, I saw a progress bar mentioning the Pharo in box. Â That's not acceptable on various fronts. Â It was cumbersome to add, needed to be added in various packages, and now I find perhaps does things behind my back. Â Whether or not it did is not the point; it emphasizes another way in which our current system is inadequate. > > We need real packages, a single-operation way to save all of them to a clearly specified location, and a simple way to separately upload something that has been so saved to the in-box. Â Migrate is my attempt to help with that; clearly it's not enough. > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 4, 2010

[Pharo-project] Pointer types

by Schwab,Wilhelm K

Sig, You mentioned something that might be useful, depending on where it lives. Our ability to use underscores now leaves me thinking I really should rework some things that suffered mightily: there are some external things that are named assuming underscores, and in mixed case, they turn into an unreadable mess. Along with this, I have a large number of FFI calls that take double pointers, and I have for some time been demoralized into (or stupid enough to<g>) expressing them as void pointers to allow me to pass byte arrays into them. Is there a way that I can get FFI to recognize DOUBLEArray (which uses a ByteArray to hold its data) as something that should be acceptable for a double* call? If not FFI, how does NB handle it? Bill

Oct. 4, 2010

Re: [Pharo-project] Pool dictionaries = 'private'?

by Schwab,Wilhelm K

I'm having a tough time with a pool dictionary that works in 1.1; there are underscores in the variable names, and 1.1.1 appears to be chopping them up somehow. I recalled having to activate _/:= to get SIXXX loaded, so I quickly tried to file in the offending pool dictionary with the setting disabled, and it worked. The SIXX sar is old, so I am assuming it still contains underscore assignments, and hacked the preference at the right time to (hopefully) allow things to load. OSProcess Command Shell still warns about MVC; it's a drag, because it happens several minutes into my build process :( I'm getting a lot of resistance about something anObsoletePresenter, presumably a reference to a class called Presenter that I added to pacify some Dolphin code, and has slowly taken on a life of its own. There are clearly potenial problems with packages that create hassles on load, and there should be a way to detect them before saving if at all possible. Telling me about it on load is not nearly as much help as would be telling me, prior to saving, that something is wrong, at a time when I can fix it. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Sunday, October 03, 2010 7:30 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Pool dictionaries = 'private'? This was probably done by SIF as I brought the code over from Dolphin, but just in case, have any of you ever seen 'private' added for Pool dictionaries? I didn't see it until saving my packages failed; I am pretty sure the code is the first I have ported that used a pool, and that this is the first time I had tried to save it from Pharo. After replacing private with the intended pool name, it appears to be ok. I'll know more when I try to load it. Bill _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 4, 2010

[Pharo-project] Pool dictionaries = 'private'?

by Schwab,Wilhelm K

This was probably done by SIF as I brought the code over from Dolphin, but just in case, have any of you ever seen 'private' added for Pool dictionaries? I didn't see it until saving my packages failed; I am pretty sure the code is the first I have ported that used a pool, and that this is the first time I had tried to save it from Pharo. After replacing private with the intended pool name, it appears to be ok. I'll know more when I try to load it. Bill

Oct. 3, 2010