August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 1058 - Merge of BlockContext and BlockClosure

by Miguel CobÃ¡

On Mon, Aug 10, 2009 at 8:40 AM, Marcus Denker<denker(a)acm.org> wrote: > > On 10.08.2009, at 02:19, Miguel Enrique CobÃ¡ Martinez wrote: > >> http://code.google.com/p/pharo/issues/detail?id=1058 >> >> Can this two classes be merged (the share 80% or more than methods and >> several are identical, maybe were copied) and then (assuming that the >> BlockClosure will be the enduring): >> >> Smalltalk at: #BlockContext put: BlockClosure >> >> This way several packages that extend BlockContext will work in the >> new >> closure vm, for example Magma. >> > > I don't think this is a good idea. BlockClosures are *not* contexts. > So methods > that are about the context part of BlockContext will fail. > > I think we should just keep BlockContext for backward-compatibility in > 1.0. This > way, people can load code and than check if the methods needs to go to > MethodContext > or BlockClosures. > > Â Â Â Â Marcus > > Ok, I assumed that like both classes share a lot of methods, they were mostly interchangeable. So by the responses, I think that this implies that changes will be neccesary to port packages that extend BlockContext to work in Pharo, while, at the same time, they must conserve the extensions to BlockContext. I imagine that given the closure integration in Squeak, this will force all the packages to use BlockClosure (or equivalent class) to update their packages. Miguel CobÃ¡ > > > -- > Marcus Denker - http://marcusdenker.de > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 10, 2009

Re: [Pharo-project] drawing tabs

by Alexandre Bergel

Thanks Gary, this is an excellent help. This problem has been around for a while already. Alexandre On 7 Aug 2009, at 08:50, Gary Chambers wrote: > Hi Tudor. > > It seems the pane colour needs to be adopted after the presentations > are > added to the container (since the layout changes when adding). > > In GLMMorphicRenderer > > renderPane: aPane > | container | > container := self emptyMorph. > aPane whenMatchingPresentationsChanged: [ :ann | > container > removeAllMorphs; > addMorph: (self renderPresentationsOf: aPane) > fullFrame: (LayoutFrame new > leftFraction: 0; > rightFraction: 1; > topFraction: 0; > bottomFraction: 1); > adoptPaneColor: container paneColor. > ]. > container > addMorph: (self renderPresentationsOf: aPane) > fullFrame: (LayoutFrame new > leftFraction: 0; > rightFraction: 1; > topFraction: 0; > bottomFraction: 1); > adoptPaneColor: container paneColor. > ^ container > > Also, although Polymorph fixes up splitters for SystemWindows, those > of > BorderedMorph are left with the original code (which is why the tops > of the > tabs are hidden). You might want an initial offset of SystemWindow > borderWidth for the moment. > > Regards, Gary > > > ----- Original Message ----- > From: "Tudor Girba" <girba(a)iam.unibe.ch> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, August 07, 2009 12:31 PM > Subject: Re: [Pharo-project] drawing tabs > > >> Hi Gary, >> >> It would be great to get some feedback on this. >> >> The code can be downloaded with: >> ScriptLoader loadLatestPackage: 'GlamourLoader' from: >> 'http://www.squeaksource.com/Glamour' >> . >> (Smalltalk at: #GlamourLoader) load >> >> To run the example, you can: >> GLMMorphicExamples new stCodeBrowser. >> >> The code that actually renders can be found in GLMMorphicRenderer. >> >> Cheers, >> Doru >> >> >> On 7 Aug 2009, at 13:10, Gary Chambers wrote: >> >>> Depends how the things are laid out. Browser bits can be a bit odd >>> I've >>> found. >>> >>> If you have some code I'll take a look. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Tudor Girba" <girba(a)iam.unibe.ch> >>> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Friday, August 07, 2009 11:48 AM >>> Subject: [Pharo-project] drawing tabs >>> >>> >>>> Hi, >>>> >>>> We (me and Jorge) are having some problems with drawing >>>> TabGroupMorph >>>> properly. >>>> >>>> The very first time the tabs are displayed, the background is not >>>> drawn correctly (see the attached picture). However, after we >>>> select >>>> another window or a tab, the tabs background are drawn correctly. >>>> >>>> In the same time, when we execute UITheme exampleGroups, everything >>>> works fine. We think we are doing the same thing, but obviously >>>> we do >>>> not. >>>> >>>> Could anyone indicate some possible tracks to look at? >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Not knowing how to do something is not an argument for how it >>>> cannot >>>> be done." >>>> >>>> >>>> >>> >>> >>> -------------------------------------------------------------------------------- >>> >>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Problem solving should be concentrated on describing >> the problem in a way that is relevant for the solution." >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 10, 2009

Re: [Pharo-project] Issue 1058 - Merge of BlockContext and BlockClosure

by Marcus Denker

On 10.08.2009, at 02:19, Miguel Enrique CobÃ¡ Martinez wrote: > http://code.google.com/p/pharo/issues/detail?id=1058 > > Can this two classes be merged (the share 80% or more than methods and > several are identical, maybe were copied) and then (assuming that the > BlockClosure will be the enduring): > > Smalltalk at: #BlockContext put: BlockClosure > > This way several packages that extend BlockContext will work in the > new > closure vm, for example Magma. > I don't think this is a good idea. BlockClosures are *not* contexts. So methods that are about the context part of BlockContext will fail. I think we should just keep BlockContext for backward-compatibility in 1.0. This way, people can load code and than check if the methods needs to go to MethodContext or BlockClosures. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Aug. 10, 2009

Re: [Pharo-project] Pharo beta 1.0 and Tutorials/Books directions

by Alexandre Bergel

> There is a new version of the book in the works, aimed to Pharo. By > the > moment, I agree with you that a disclaimer should be added and maybe > the > first drafts of the book should be uploaded to the site, at least to > review and feedback to the authors. Yes, we are currently working on Pharo by Example. We hope to make a release soon. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 10, 2009

Re: [Pharo-project] Issue 1058 - Merge of BlockContext and BlockClosure

by Mariano Martinez Peck

2009/8/10 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El lun, 10-08-2009 a las 01:19 -0500, Miguel Enrique CobÃ¡ Martinez > escribiÃ³: > > http://code.google.com/p/pharo/issues/detail?id=1058 > > > > Can this two classes be merged (the share 80% or more than methods and > > several are identical, maybe were copied) and then (assuming that the > > BlockClosure will be the enduring): > > > > Smalltalk at: #BlockContext put: BlockClosure > > > > This way several packages that extend BlockContext will work in the new > > closure vm, for example Magma. > > > > What are the pros/cons of this change? > > > > If feasible, will be marked as Milestone-1.0? > > Ramiro Diaz Trepat and Mariano MartÃnez Peck commented on the magma > mailing list that they successfully loaded magma on a pharo image by > copying the extensions added by magma to BlockContext to the class > BlockClosure. It appear that the code worked ok. Maybe with this change > it wouldn't be necessary to modify magma (Chris Muller should speak > about this). That can be the case for a lot of packages and will ease > the integration and "certification" of several packages on pharo. > Miguel: Actually I was talking about Glorp, not Magma ;) However, think I am not agree. In my case, Glorp has methods extensions (like *Glorp) in the BlockContext. But those methods were Glorp specific. So, the merge between BlockContext and BlockClosure has no sense. If there are messages in BlockContext that you need to be in BlockClosure but are closure related, then perhaps we can put them, as there were already some (I remember for example, argumentCount). This is a joke: Perhaps we can override the doesNotUndersand: in BlockClosure so that it delegates to BlockContext hahahahahah > > See: > > http://lists.squeakfoundation.org/pipermail/magma/2009-July/001321.html > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 10, 2009

Re: [Pharo-project] [ANN] Updating a Pharo image is now possible

by Mariano Martinez Peck

On Mon, Aug 10, 2009 at 5:37 AM, stan shepherd <stan.shepherd414(a)gmail.com>wrote: > Hi Damien, it gives the same error on > 'Morphic-adrian_lienhard.345.mcz'. And it seems **very** slow, ie > running for hours. Is that expected? I don't think so. In make case, when it takes a hours is because there is Nod32 activated ;) You must exclude Squeak folders from Nod32. > > > Cheers, ...Stan > > 2009/8/8 Damien Cassou <damien.cassou(a)gmail.com>: > > Please remove this file from the package-cache directory and try again. > > > > 2009/8/8 stan shepherd <stan.shepherd414(a)gmail.com>: > >> Hi, I get Error: can't find EOCD position, during load of > >> 'System-Support-stephane_ducasse.28.mcz' > >> > >> eocdPosition = 0 > >> > >> > >> Full walkback is attached. > >> > >> Cheers, ...Stan > >> > >> 2009/8/8 Damien Cassou <damien.cassou(a)gmail.com>: > >>> Hi, > >>> > >>> just wanted to say that updating a Pharo image seems to work ok now. > >>> I've removed the overrides in some packages. > >>> > >>> However, remember that the update mechanism only updates Core > >>> packages, not packages listed in > >>> http://code.google.com/p/pharo/wiki/Packages. This could be possible > >>> but has not been done yet. What do you think about that? > >>> > >>> -- > >>> Damien Cassou > >>> http://damiencassou.seasidehosting.st > >>> > >>> "Lambdas are relegated to relative obscurity until Java makes them > >>> popular by not having them." James Iry > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st > > > > "Lambdas are relegated to relative obscurity until Java makes them > > popular by not having them." James Iry > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 10, 2009

[Pharo-project] Fix for author initialsPerse

by StÃ©phane Ducasse

Stef

Aug. 10, 2009

Re: [Pharo-project] Expected failures/errors on SUnit

by Lukas Renggli

> know why is it implemented that way? could this be changed? who is the > responsible for maintaining/changing SUnit? Joseph Pelrine is the maintainer of SUnit (http://sunit.sourceforge.net) The last official cross platform SUnit 3.1 release dates back to 2003. The implementation of SUnit in Squeak/Pharo has independently changed over the years and has no official maintainer, as far as I know. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Aug. 10, 2009

Re: [Pharo-project] Good Work Guys!

by Daniel P Zepeda

On Aug 9, 2009, at 8:02 AM, StÃ©phane Ducasse wrote: > Thanks Daniel. > Now we do not want to compete with Squeak. We did pharo because we had > to. No, I don't think there is competing goals. Pharo's and Squeak's goals seem to be different. > > We hope that we will produce something good that people can use. Good so far, and I'm using it for playing right now, with an eye to using it for something serious in the near future. > > Feel free to contribute. There is always something to do (test, > reporting bugs, reporting that fixes > are working....). I don't know what I can do at the level I'm at now, but I'll keep my eye out to contribute what I can. > > > Stef > >>

Aug. 10, 2009

Re: [Pharo-project] Issue 1058 - Merge of BlockContext and BlockClosure

by Stuart Herring

2009/8/10 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com>: > Ramiro Diaz Trepat and Mariano MartÃnez Peck commented on the magma > mailing list that they successfully loaded magma on a pharo image by > copying the extensions added by magma to BlockContext to the class > BlockClosure. It appear that the code worked ok. Maybe with this change > it wouldn't be necessary to modify magma (Chris Muller should speak > about this). That can be the case for a lot of packages and will ease > the integration and "certification" of several packages on pharo. > Doing that allows Magma to _load_ but it fails all block related tests, so there's a bit more to it than that - serialization/deserialization is the issue. Also, there's a number of other issues when porting to Pharo. They're mostly all in the testing code, but being able to run the tests is pretty essential for a successful port. Regards, Stuart

Aug. 10, 2009