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

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

by StÃ©phane Ducasse

OK so I did not get the ones that are missing for Glorp? Stef On Aug 11, 2009, at 9:18 AM, Adrian Lienhard wrote: > This was already discussed some time ago in the thread > "BlockContextTest". Gabriel posted a list of methods and we discussed > which ones should be copied to BlockClosure. > > Adrian > > On Aug 11, 2009, at 09:06 , StÃ©phane Ducasse wrote: > >> What would be nice is to get a list of the methods that are missing >> in >> BlockClosure. >> After the changes will not be only needed for pharo but also for >> Squeak since Squeak has blockclosure now >> >> Stef >> >>> >>> 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 >>>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 11, 2009

Re: [Pharo-project] Pharo Feature Roadmap Question

by StÃ©phane Ducasse

if somebody helps yes :) It should be in the list of items for 1.1 STef On Aug 11, 2009, at 6:10 AM, Eagle Offshore wrote: > It seems like Pharo 1.0 is crystallized already. > > Is native window support (Areithfa Ffenestri) in the near term plan? > http://wiki.squeak.org/squeak/3862 > > -Todd Blanchard > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 11, 2009

Re: [Pharo-project] Https client

by StÃ©phane Ducasse

Hi dave do you know if there is a way to publish a newer one to the universe or delete the current one? Stef On Aug 11, 2009, at 4:13 AM, David T. Lewis wrote: > On Mon, Aug 10, 2009 at 05:42:11PM -0300, Hernan Wilkinson wrote: >> Hi, >> we need to issue a post using https. We read about SWHTTPClient and >> CurlPlugIn. >> It sounds like SWHTTPClient does not support Https correctly (from >> what we >> read, is that right? ), so we tried CurlPlugIn but we could not >> make it >> work. We tried to download VMMaker from Universes to build the plug- >> in and >> it did not download (it gives a compile error). > > Try using the latest VMMaker from http://www.squeaksource.com/VMMaker. > The version that you got from Universes is now quite out of date. > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 11, 2009

Re: [Pharo-project] Display depth on Linux

by Douglas Brebner

StÃ©phane Ducasse wrote: > Guys > > could you create a wiki pages with "Possible problems with interacting > tools on windows" > or something like that? > > Stef > > I believe this problem is due to a combination of the unix vm putting garbage into the alpha channel (the extra 8bits in 32bit colour after RGB) and a Composite extension manager active on the X server. I think Metacity uses Composite as does Compiz and a few others. Composite is the X extension that allows the 3d desktop stuff and other shiny effects to work btw. > On Aug 10, 2009, at 11:20 PM, Mariano Martinez Peck wrote: > > >> Does someone know if there are also problems in Metacity as there >> are with Compiz when using something else than 32 bits? >> >> Best, >> >> Mariano >> >> 2009/8/10 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> >> yeap, it was that, thanks! >> >> 2009/8/9 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >> >> >> 2009/8/9 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> >> >> On linux, when setting Display Depth to something else than 32, it >> is impossible to recongnize something on the screen. >> We did some research with Juan Vuletich on this and it sounds like >> an error on the VMnot the Smalltalk code >> We try it on Ubuntu 9.04, 64 bits. Is this a known bug? >> >> >> Do you have Compiz activated? >> >> >>

Aug. 11, 2009

Re: [Pharo-project] How to build a GUI

by StÃ©phane Ducasse

Hi I think that what is important is to release your code and learn and iterate. Did you check how VW UIBuilder did it? Stef > > > csrabak wrote: >> >>> >>> I?m developing the UIBuilder of Youtube video. The development not >>> is >>> ended, >>> and is in a Pre Beta state. I believe than in two weeks i could up >>> in >>> SqueakSource; but exists two or three problems, how for example >>> the way >>> of >>> morph builded persistence. My knowledge of Smalltalk and Pharo- >>> Squeak is >>> poor and limited, but i continue working.So it would be necessary >>> that >>> yours >>> recommended me the best way to me to do according to which things >>> when i >>> finished the first step. >> >> In order people can help you, I suggest you post your individual >> doubts >> here, as some of the issues you might be stumbling at may be also >> something Pharo's team may be at an influx of changing. >> > > Well , some problems is discussed before, for example the way of > persist the > morph generated in the UIBuilder -> > http://n2.nabble.com/Persist-a-morph-in-a-message.-td3292117.html#a3292117 > > but dont seems easy do it :) Now i persist the morph in serialized > method, > but that way have serious problems if the controls library changes > in the > time. Another problem is the "binding" between a object with data > and his > representation in controls of UI, i dont like the MorphicModel > mechanism; im > doing than controls working with events. > > > csrabak wrote: >> >> Just as a curiosity: what is "CLFramework" is the hierarchy of >> classes >> you're buiding your toolset or are using other classes than >> PolyMorph? >> > > CLFramework is the package container of all my classes, not only the > UIBuilder; is totally integrated in Polymorph :) > > Regards > > > -- > View this message in context: http://n2.nabble.com/How-to-build-a-GUI-tp3419005p3420211.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 11, 2009

Re: [Pharo-project] How to build a GUI

by StÃ©phane Ducasse

Hi What will be the license of your toolBuilder? Then if you need help for the serialization did you do a call? Where the code is stored? Stef On Aug 10, 2009, at 10:40 PM, nullPointer wrote: > > > > csrabak wrote: >> >> Taking profit this subject is somewhat a revisit of the "Making >> GUI'S" >> one, I would like to know if the implementer of the "Pharo Squeak >> Smalltalk UIBuilder tool sample (I)" video >> http://www.youtube.com/watch?v=CHbc1t83fEI participates of this list? >> >> The six minutes video is worth seeing by itself, but it doesn't >> give any >> further info on availability of the "framework" :-( >> >> Regards, >> >> -- >> Cesar Rabak >> > > Excuse me for my poor english. > > IÂ´m developing the UIBuilder of Youtube video. The development not > is ended, > and is in a Pre Beta state. I believe than in two weeks i could up in > SqueakSource; but exists two or three problems, how for example the > way of > morph builded persistence. My knowledge of Smalltalk and Pharo- > Squeak is > poor and limited, but i continue working.So it would be necessary > that yours > recommended me the best way to me to do according to which things > when i > finished the first step. > > Now im developing a "Resources editor" and a "Context menu editor", > and > implementing too a way for embedding views into another views, ala > VisualWorks, of easy way. > > Here three snapshots: > > http://img41.imageshack.us/i/uibuilder1.png/ > http://img40.imageshack.us/i/uibuilder2.png/ > http://img194.imageshack.us/i/uibuilder3.png/ > > > Regards > > > > > > > -- > View this message in context: http://n2.nabble.com/How-to-build-a-GUI-tp3419005p3419792.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 11, 2009

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

by Adrian Lienhard

This was already discussed some time ago in the thread "BlockContextTest". Gabriel posted a list of methods and we discussed which ones should be copied to BlockClosure. Adrian On Aug 11, 2009, at 09:06 , StÃ©phane Ducasse wrote: > What would be nice is to get a list of the methods that are missing in > BlockClosure. > After the changes will not be only needed for pharo but also for > Squeak since Squeak has blockclosure now > > Stef > >> >> 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 >>> >> >> _______________________________________________ >> 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. 11, 2009

Re: [Pharo-project] Display depth on Linux

by StÃ©phane Ducasse

Guys could you create a wiki pages with "Possible problems with interacting tools on windows" or something like that? Stef On Aug 10, 2009, at 11:20 PM, Mariano Martinez Peck wrote: > Does someone know if there are also problems in Metacity as there > are with Compiz when using something else than 32 bits? > > Best, > > Mariano > > 2009/8/10 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > yeap, it was that, thanks! > > 2009/8/9 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > > 2009/8/9 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > > On linux, when setting Display Depth to something else than 32, it > is impossible to recongnize something on the screen. > We did some research with Juan Vuletich on this and it sounds like > an error on the VMnot the Smalltalk code > We try it on Ubuntu 9.04, 64 bits. Is this a known bug? > > > Do you have Compiz activated? > > > Hernan > > _______________________________________________ > 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 > > > _______________________________________________ > 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. 11, 2009

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

by StÃ©phane Ducasse

Normally not this is strange. Stef On Aug 10, 2009, at 10:27 PM, Stan Shepherd wrote: > > > Douglas Brebner wrote: >> >> Stan Shepherd wrote: >>> Mariano Martinez Peck wrote: >>> >>>> 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. >>>> >>>> >>>> >>> >>> I don't think so- it's all Linux here. I gather Nod32 is a Windows >>> antivirus. >>> >> Are you using it on a network drive? That can be horrifically slow >> too >> >> > > It's right here on my machine - which is quite well speced. I do > have a > firewall at the router, and OenDNS as the DNS server. I also still had > Seaside running while updating - is that an issue? > > > > -- > View this message in context: http://n2.nabble.com/-ANN--Updating-a-Pharo-image-is-now-possible-tp3408773… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 11, 2009

Re: [Pharo-project] a process to maintain non core package

by StÃ©phane Ducasse

Thanks. I tried to follow sake/package and bob and I got lost. Now for the update there are some tricky operations from time to time (and yes ideally I would like to use a system like the one you describe). >> Why not, the debian project use this model since 1996 or something >> like >> that. >> The same package system the use report packages not maintained >> anymore >> (orphans and waiting for mantainer) >> >> >>>>> - For each package there should be a known way to discuss and >>>>> report >>>>> problems >>>>> >>>>> >>> That's just arbitrary metadata in the package definition, for more >>> general topics we use the packages(a)squeakfoundation.org mailing list >>> >>>>> - A gate keeper includes and removes packages from the set >>>>> depending >>>>> on their status >>>>> >>>>> >>> Probably too complicated to be practical. >>> >>>>> This limits the set of included packages (at least initially) but >>>>> would increase the quality and hence the user experience. >>>>> >>>>> Maybe there could be two sets, a stable and an unstable set. New >>>>> >>>>> >>> Sake/Packages supports a stable and a beta release of each package. >>> >>>>> packages would first go to the unstable set and then move up to >>>>> the >>>>> stable set after a while. >>>>> >>>>> An automated build process could load packages into new builds and >>>>> report the result of the tests. >>>>> >>>>> >>> Bob does that. >>> >>>>> The package management system does not need to be very >>>>> sophisticated, >>>>> >>>>> >>> Sake is as simple as possible for defining actions with >>> dependencies. >>> >>>>> but it should manage dependencies and have a simple GUI (to >>>>> search for >>>>> packages and see what is already loaded). >>>>> >>>>> >>> Sake/Packages uses the class browser as is, no extra GUI is >>> required. >>> >>> Packages provided explore >>> >>> shows you what is loaded, and this should be merged into >>> PackageOrganization. >>> >>> Keith >>> >> >> Keith, it really appear that you have built the platform to bring >> this >> dream a reality, but somehow (the details are not relevant now) you >> haven't materialized a "steve jobs" kind of show off of it. >> I believe your words, based on your other projects that I use. What >> do >> you need, as Stephan said, to bring a complete, working, and as >> simple >> to understand for all of us of your tools. >> This is my proposal: >> >> I think that if you can put a working example (minimal, a couple of >> packages, and the core) using Pharo, the pharo community happily will >> support you. No more fights, no more angry mails, just the working >> full >> simple demo. >> I offer to you access to a server with a homologated IP to install (I >> can help you here too) to setup the repositories to test your tools. >> If the community agree to use your tools and process I can also buy >> and >> donate the domain to host this infrastructure. In the beginning I >> will >> host it, if someday it grows more than I can support (bandwidth >> mainly, >> the space isn't problem) then we will discuss with the community to >> migrate the repos to a bigger servers or to ask for donations or some >> other party that can host it (maybe the folks of seasidehosting). >> We'll >> see in that moment. >> >> But, Keith, we need to see to believe and support you. >> >> >> > I've seen Keiths Seaside gui he made for Bob though I don't know if he > wants it to be shown around. It looks nice. > > Here's a quick explanation for those not familiar with them. > Sake is essentially Make for Smalltalk, allowing you to define tasks > that can depend on other tasks. > Bob is a build tool, which handles all the actual building using Sake > tasks to define what to do. > > With Bob+Sake, you can define a build to: > 1. Start with a defined image. > 2. Load a set of packages into that image (either specific versions or > the latest ones). > 3. Apply specific fixes from the bug tracker. > 4. Run tests. > 5. Save the new image and export all the new package versions to a new > folder. > > You can define tasks to apply features to an image such as closures or > perform updates between versions or even update applications. > > For example, you can define tasks to do the following sort of things > Pharo1.0beta -> Pharo1.0final > Pharo1.0beta -> Pharo-latest. > Squeak 3.10.2 image -> 3.10.2+closures. > Squeak 3.8 image -> 3.8+closures. > Seaside 2.8 -> 2.9. > Pharo-latest -> Pharo-latest + Seaside-latest + your own favourite > packages. > > Once defined, these will allow anyone to repeatably and reliably > produce > an updated image+packages without changing the original image. You can > then do things like upgrade a production image based on 1.0beta to > 1.0final just by using the same task but telling it to start with your > production image instead of the 1.0beta distribution image. Since it > produces a new image you don't risk clobbering your original. > > You should also be able to replace the update stream with distributing > build definitions for Bob. > > I believe one of the key points to this setup is that you don't need > to > work on the image as a single blob any more, you only work on the > packages and use Bob to handle the messy image building stuff. That > does > depend on the image being sectioned into packages of course. > > If I've had any misunderstandings here I hope Keith will correct me > but > the system looks awesome :) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 11, 2009