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

Re: [Pharo-project] Class>>isSystemDefined ?

by StÃ©phane Ducasse

We should probably remove the isSystemDefined and officialClass but we should do it with care because etoys crept really deep. Stef On Aug 11, 2009, at 4:04 PM, Alexandre Bergel wrote: > Dear List members, > > The following method is defined in Class: > -=-=-=-=-=-=-=-=-= > Class>>isSystemDefined > "Answer true if the receiver is a system-defined class, and not a > UniClass (an instance-specific lightweight class)" > > ^ self == self officialClass > -=-=-=-=-=-=-=-=-= > > isSystemDefined is sent a number of times. Especially by streams. I > guess that this determines what should be serialized what should not. > > However, #officialClass has only two implementers: > > -=-=-=-=-=-=-=-=-= > Class>>officialClass > "I am not a UniClass. (See Player officialClass). Return the class > you use to make new subclasses." > > ^ self > -=-=-=-=-=-=-=-=-= > > And slightly more surprising: > > -=-=-=-=-=-=-=-=-= > MorphicModel>>officialClass > "We want to make a new instance of the receiver, which is a subclass > of MorphicModel. Answer who to make a new subclass of. Also used to > tell if a given class is a UniClass, existing only for its single > instance." > > ^ self name last isDigit ifTrue: [MorphicModel] ifFalse: [self] > "MorphicModel7 can not have subclasses, but Slider and SystemWindow > may" > -=-=-=-=-=-=-=-=-= > > There is a very strong smell for cleaning here. Apparently, most of > usage of #isSystemDefined could be replaced by #isBehavior > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 StÃ©phane Ducasse

ok I was confused then by the mail of miguel Stef On Aug 11, 2009, at 3:26 PM, Mariano Martinez Peck wrote: > > > On Tue, Aug 11, 2009 at 6:28 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > OK so I did not get the ones that are missing for Glorp? > > Sorry Stef I don't understood your question. Glorp uses some methods > that wasn't in BlockCloure. At least, I remember one: argumentCount > which was only a simple accesor. So, we put it in BlockClosure. > Then, Glorp has extensions in BlockContext with category *Glorp that > I had to copy them to BlockClosure, but those methods are Glorp > specific and they are loaded only when you load the Glorp package. > > Best, > > Mariano > > > > 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 > > > _______________________________________________ > 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] right button still doesn't work on Windows

by Mariano Martinez Peck

On Tue, Aug 11, 2009 at 6:15 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Can you reproduce this with a fresh Pharo-core? > > It would be interesting to know whether the method is run at startup > in your image. It is run as expected in my image (latest pharo-core). > Could you add a halt in #installMouseDecodeTable save and restart the > image? Yes, I did that. Clean pharo beta core. The situation is this: When you first open the image, it doesn't work. However, if you save it (without doing nothing) and open it again, it start working (even when not evaluating InputEventSensor installMouseDecodeTable) I am alone? best, mariano > > Adrian > > On Aug 11, 2009, at 20:38 , Mariano Martinez Peck wrote: > > > On Tue, Aug 11, 2009 at 5:29 PM, Adrian Lienhard <adi(a)netstyle.ch> > > wrote: > > > >> What I don't understand is why InputEventSensor > >> installMouseDecodeTable would solve the problem because this method > >> is > >> run at startup... > > > > > > I really don't know, but works :( > > > > > >> > >> > >> Adrian > >> > >> On Aug 11, 2009, at 20:19 , Torsten Bergmann wrote: > >> > >>>> With Pharo beta, right button still doesn't work out of the box > >>>> in Windows. > >>> > >>> Mariano, can you try the installer executable on > >>> http://pharo-project.org/pharo-download ? > >>> > >>> For me right button work out of the box on XP and Vista and the > >>> installer uses the same image as Damien provides on the download > >>> site. > >>> > >>> Bye > >>> Torsten > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla > >>> Firefox 3 - > >>> sicherer, schneller und einfacher! > http://portal.gmx.net/de/go/atbrowser > >>> > >>> _______________________________________________ > >>> 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] right button still doesn't work on Windows

by Adrian Lienhard

Can you reproduce this with a fresh Pharo-core? It would be interesting to know whether the method is run at startup in your image. It is run as expected in my image (latest pharo-core). Could you add a halt in #installMouseDecodeTable save and restart the image? Adrian On Aug 11, 2009, at 20:38 , Mariano Martinez Peck wrote: > On Tue, Aug 11, 2009 at 5:29 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > >> What I don't understand is why InputEventSensor >> installMouseDecodeTable would solve the problem because this method >> is >> run at startup... > > > I really don't know, but works :( > > >> >> >> Adrian >> >> On Aug 11, 2009, at 20:19 , Torsten Bergmann wrote: >> >>>> With Pharo beta, right button still doesn't work out of the box >>>> in Windows. >>> >>> Mariano, can you try the installer executable on >>> http://pharo-project.org/pharo-download ? >>> >>> For me right button work out of the box on XP and Vista and the >>> installer uses the same image as Damien provides on the download >>> site. >>> >>> Bye >>> Torsten >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla >>> Firefox 3 - >>> sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser >>> >>> _______________________________________________ >>> 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-project] right button still doesn't work on Windows

by csrabak＠bol.com.br

Mariano, I have Pharo installed in a Windows XP SP3 machine and right button works (and wheel also which is the central button in my mouse). could you create a test case to ascertain the issue is epidemic and not result of specifics of your image?

Aug. 11, 2009

[Pharo-project] Beta: browser missing splitters?

by Schwab,Wilhelm K

I wanted to take a look at Seaside 2.9's WADevelopment class, specifically how it automates saving packages. After finding the download system for Seaside (very nice!), I had a great excuse to grab the beta and load 2.9 from a change set. It worked - congrats to all involved. One thing that stands out to me is that the panes in the browser appear to lack splitters, so one is stuck with their relative sizes :( As a secondary item, when trying to click-drag where a splitter might be, it picks up the entire browser; IMHO, it should ignore the input. Better still, it should have splitters. Please view all of this as a success. I loaded a beta web framework into a beta Smalltalk system, and that's worst that happened! In fairness, I have not tried to use Seaside 2.9, but for now, I just want to organize the saving of my packages to go from my current image into the beta. Bill

Aug. 11, 2009

Re: [Pharo-project] SWHTTPClient

by Schwab,Wilhelm K

Two reasons: (1) OpenSSL offers a lot more than just SSL sockets, so it is worth wrapping; (2) it would be easy enough to do that is worth the effort. Any time one introduces something like stunnel, there are setup complexities, which become opportunities to make mistakes that leave data unprotected. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Esteban Lorenzano Sent: Tuesday, August 11, 2009 1:03 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] SWHTTPClient Sorry if this is not the case, but... why don't you use stunnel instead trying to make https protocol work on squeak? Is much more easy, I think. Cheers, Esteban On 2009-08-11 14:47:07 -0300, "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> said: > AFAICT, https is just http over an SSL socket. The less incorrect I > am abo ut that, the more you are in fact looking for an SSL socket implementation. > My thought is to create that on top of OpenSSL, whether by plugin or > FFI/ Alien. > > OpenSSL provides non-blocking calls, but my recollection is that they > are n ot simple to use. A plugin that can start OS threads to prevent > blocking ( on connect, read, and write) might be the easiest approach. > Perhaps someon e who actually knows something about Squeak plugins > could comment on whethe r that makes any sense :) > > Bill > > > > -----Original Message----- > From: > pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bou > nces(a)lists.gforge.inria.fr] On Behalf Of HernÃ¡n Morales Durand > Sent: Tuesday, August 11, 2009 12:22 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] SWHTTPClient > > http://universes.dnsalias.net/universes/repositories/squeak-3.9/SWHTTP > Clien > t-bkv.19.mcz > > 2009/8/11 Hernan Wilkinson > <hernan.wilkinson(a)gmail.com>: >> Does anybody know how to download the SWHTTPClient? (still looking >> for > >> a https client :-) ) >> >> _______________________________________________ >> 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] right button still doesn't work on Windows

by Mariano Martinez Peck

On Tue, Aug 11, 2009 at 5:29 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > What I don't understand is why InputEventSensor > installMouseDecodeTable would solve the problem because this method is > run at startup... I really don't know, but works :( > > > Adrian > > On Aug 11, 2009, at 20:19 , Torsten Bergmann wrote: > > >> With Pharo beta, right button still doesn't work out of the box > >> in Windows. > > > > Mariano, can you try the installer executable on > > http://pharo-project.org/pharo-download ? > > > > For me right button work out of the box on XP and Vista and the > > installer uses the same image as Damien provides on the download > > site. > > > > Bye > > Torsten > > > > > > > > > > > > > > > > > > -- > > Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla > > Firefox 3 - > > sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser > > > > _______________________________________________ > > 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] right button still doesn't work on Windows

by Mariano Martinez Peck

On Tue, Aug 11, 2009 at 5:19 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >With Pharo beta, right button still doesn't work out of the box > >in Windows. > > Mariano, can you try the installer executable on > http://pharo-project.org/pharo-download ? > It doesn't work neither. > > For me right button work out of the box on XP and Vista and the > installer uses the same image as Damien provides on the download > site. > > Bye > Torsten > > > > > > > > > -- > Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - > sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser > > _______________________________________________ > 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] right button still doesn't work on Windows

by Adrian Lienhard

What I don't understand is why InputEventSensor installMouseDecodeTable would solve the problem because this method is run at startup... Adrian On Aug 11, 2009, at 20:19 , Torsten Bergmann wrote: >> With Pharo beta, right button still doesn't work out of the box >> in Windows. > > Mariano, can you try the installer executable on > http://pharo-project.org/pharo-download ? > > For me right button work out of the box on XP and Vista and the > installer uses the same image as Damien provides on the download > site. > > Bye > Torsten > > > > > > > > > -- > Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla > Firefox 3 - > sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser > > _______________________________________________ > 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