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

Re: [Pharo-project] Loosing file name dowloading PRFile

by Lukas Renggli

Thank you for reporting. I can reproduce this, but not immediately fix this. I created an issue and will look at this ASAP. http://code.google.com/p/pier/issues/detail?id=94 Cheers, Lukas On Sat, Apr 18, 2009 at 9:32 PM, Dennis Schetinin <chaetal(a)gmail.com> wrote: > I use Pier in pharo0.1-10268web09.04. When I try to download a File I > added before, original file name is ignored and it is named as 'Pier' > always. The contents is correct. > > -- > Dennis Schetinin > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch

April 18, 2009

[Pharo-project] [ANN] 10283 and 10284: new events

by StÃ©phane Ducasse

So this is in the box Now we should really shake the code and fix fix fix and release a alpha then beta. Mike the menus and other seems quitttttttt e s low with the new events :) So I imagine that we will get some fixes soon :) Stef Cleanup ------- -remove the old and confusing EventSensor and InputSensor classes and replace them with InputEventSensor. -remove backward compatibility and polling where possible Not all VMs signal the input semaphore, that's why we currently us a polling event fetcher. Pluggability ------------ -events from the VM are now fetched by an InputEventFetcher "InputEventFetcher is responsible for fetching the raw VM events and forward them to the registered event handlers. Event fetching is done in a high priority process, so even with other processes (e.g. the Morphic UI process) being busy events will still be fetched." This finally gets rid of the input event tickler! InputEventHandlers can then listen to events. Current default listeners are the InputEventSensor for Morphic and UserInterruptHandler. This allows for alternative UI frameworks or other interesting stuff ;-) to register as a listener and deal with input events without ever having to deal with Morphic. Next on my list is to do exactly that with Miro and my experimental IMorph implementation, both built on Announcements. Michael

April 18, 2009

[Pharo-project] [ANN] 10283 Freetype pref + ensure with Strema

by StÃ©phane Ducasse

Thanks guys.

April 18, 2009

Re: [Pharo-project] Postgresql + pharo

by John M McIntosh

Well I'm not sure what the problem is since it looks like there is a socket handle there #[181 38 234 73 0 0 0 0 144 184 43 0] The original problem was about a segmentation fault causing the server to crash. This appears to be waiting on the connection? No doubt forever. On 18-Apr-09, at 11:23 AM, MichaelA wrote: > > Here is bug report. > > 18 April 2009 11:22:57 am > > VM: Mac OS - a SmalltalkImage > Image: Pharo0.1 [Latest update: #10281] > > SecurityManager state: > Restricted: false > FileAccess: true > SocketAccess: true > Working Dir /Users/arkhon/Desktop/PharoMacW > Trusted Dir /foobar/tooBar/forSqueak/bogus > Untrusted Dir /Users/arkhon/Library/Preferences/Squeak/Internet/My > Squeak > > [] in Socket>>connectTo:waitForConnectionFor: > Receiver: a Socket[unconnected] > Arguments and temporary variables: > <<error during printing> > Receiver's instance variables: > semaphore: a Semaphore() > socketHandle: #[181 38 234 73 0 0 0 0 144 184 43 0] > readSemaphore: a Semaphore() > writeSemaphore: a Semaphore() > primitiveOnlySupportsOneSemaphore: false > > Socket>>waitForConnectionUntil:ifTimedOut: > Receiver: a Socket[unconnected] > Arguments and temporary variables: > deadline: 352876 > timeoutBlock: [closure] in Socket>>connectTo:waitForConnectionFor: > status: 0 > Receiver's instance variables: > semaphore: a Semaphore() > socketHandle: #[181 38 234 73 0 0 0 0 144 184 43 0] > readSemaphore: a Semaphore() > writeSemaphore: a Semaphore() > primitiveOnlySupportsOneSemaphore: false > > Socket>>waitForConnectionFor:ifTimedOut: > Receiver: a Socket[unconnected] > Arguments and temporary variables: > timeout: 45 > timeoutBlock: [closure] in Socket>>connectTo:waitForConnectionFor: > Receiver's instance variables: > semaphore: a Semaphore() > socketHandle: #[181 38 234 73 0 0 0 0 144 184 43 0] > readSemaphore: a Semaphore() > writeSemaphore: a Semaphore() > primitiveOnlySupportsOneSemaphore: false > > Socket>>connectTo:waitForConnectionFor: > Receiver: a Socket[unconnected] > Arguments and temporary variables: > aSocketAddress: ::1(localhost),5432(postgresql) > timeout: 45 > Receiver's instance variables: > semaphore: a Semaphore() > socketHandle: #[181 38 234 73 0 0 0 0 144 184 43 0] > readSemaphore: a Semaphore() > writeSemaphore: a Semaphore() > primitiveOnlySupportsOneSemaphore: false > > > --- The full stack --- > [] in Socket>>connectTo:waitForConnectionFor: > Socket>>waitForConnectionUntil:ifTimedOut: > Socket>>waitForConnectionFor:ifTimedOut: > Socket>>connectTo:waitForConnectionFor: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Socket>>connectTo: > Socket>>connectTo:port: > PGConnection>>openSocket > PGConnection>>stStartup: > PGConnection(PGActiveObject)>>processEvent: > PGConnection(PGActiveObject)>>saProcessEventsUntil: > PGConnection>>startup > TestPGConnection>>executeAll:withDelayForMilliseconds: > [] in TestPGConnection>>testNotify1 > [] in BlockClosure>>newProcess > > > I am using Squeak 4.0.1beta1U with Pharo0.1Core-10281cl.image. > > > > Do you use the latest mac 4.0 vm? > > Stef > > On Apr 18, 2009, at 7:33 PM, MichaelA wrote: > >> >> Is there a solution for Mac OSX? I am having the same problem. >> >> >> On Mon, 2009-04-13 at 01:01 -0300, Mariano Martinez Peck wrote: >>> >> >>> >>> a) another vm: the latest from squeak.org and the latest from >>> exupery: >>> http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-linux.tz >> >> Use http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15.1-linux.tz >> >> I upgraded the VM to include the IP6 primitives. >> >> Bryce >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> -- >> View this message in context: http://n2.nabble.com/Postgresql-%2B-pharo-tp2621714p2656545.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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > View this message in context: http://n2.nabble.com/Postgresql-%2B-pharo-tp2621714p2656679.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 -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

April 18, 2009

Re: [Pharo-project] Nile and pharo?

by Markus Fritsche

Markus Fritsche <fritsche.markus(a)gmx.net> wrote: > I installed Nile from the Universe. I wonder if it's a) my image or if b) > Nile/ c) Pharo Traits is broken? For instance, NSCollectionStreamTest gives > me an error: > 'A class or trait does not properly resolve a conflict between multiple > traits it uses.' I downloaded the advertised pharo-dev image, installed universe, nile, started the test... same error (so, at least once, a) is not the culprit :-P)

April 18, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Re: Statistics on merging Cuis with 3.10 on Morph hierarchy

by StÃ©phane Ducasse

The problem is that CUIS is based on Squeak 3.7 = 5 years old versions and we will not harvest automatically the changes. Sorry guys but we spent so many hours fixing and improving squeak in 3.8, 3.9 and pharo that I will not just jump on it like that. Now if you are serious and dedicated of course we would value to get the fixes that can possibility be integrated. But it will be work and pain. Also companies like pinesoft invested a lot of effort in the UI so we have to pay attention not to break radically or provide a path for them. So identifying the cs that are affecting Morph or the cs that would be worth to investigate can be interesting but we cannot promise that we will integrate them. Stef On Apr 18, 2009, at 9:31 PM, Mariano Martinez Peck wrote: > It may be of help. > > ---------- Forwarded message ---------- > From: Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > Date: Fri, Apr 17, 2009 at 9:58 PM > Subject: [squeak-dev] Re: Statistics on merging Cuis with 3.10 on > Morph hierarchy > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > > Here are the same statistics but with Pharo dev 09.02.3, Squeak 3.7 > and Cuis > > Number of Classes removed in Cuis: 271 > Number of Classes added on Pharo: 0 > Number of new Classes in Cuis: 5 > Number of Classes to merge: 59 > Number of same methods: 858 > Number of changed methods on Cuis: 91 > Number of new methods on Cuis: 95 > Number of conflicting methods: 66 (methods on 3.7 that different > with the ones in Pharo and Cuis) > Number of changed methods on Pharo: 162 (from 3.7) > Number of removed methods on Cuis: 555 > Number of new methods in Pharo: 2387 > > So, to merge Cuis Morph hierarchy with Pharo, 91+95 methods from > Cuis have to be loaded in Pharo and 66 methods have to be integrated > by a human. > To merge Cuis Morph hierarchy with Squeak 3-10, 117+66 methods from > Cuis have to be loaded in Squeak 3.10 and 44 methods have to be > integrated by a human. > > I ran the statistics only on the Morph hierarchy because what seems > to be faster in Cuis is the UI. I'm assuming that the Cuis changes > in the Morph hierarchy is what makes Cuis run faster, but I'm not > sure of that... of course we can run the same process for other > hierarchies, packages, all the classes, etc. And if somebody is > interesting in knowing which classes, methods, etc. are involved > (the real stuff, not only the numbers), just let me know. > > Hernan. > > > On Fri, Apr 17, 2009 at 5:47 PM, Hernan Wilkinson <hernan.wilkinson(a)gmail.com > > wrote: > Hi, > here is a statistics I made about taking Squeak 3.10 and merging > Cuis with it on the Morph hierarchy, just to have an idea on how > much it could take... > > Number of Classes removed in Cuis: 265 > Number of Classes added on 3.10: 0 > Number of Classes added on Cuis: 5 > Number of Classes to merge: 59 > Number of same methods: 930 > Number of changed methods on Cuis: 117 > Number of new methods on Cuis: 66 > Number of conflicting methods: 44 (method on 3.7 is different > that the one in 3.10 that in Cuis) > Number of changed methods on current: 109 (from 3.7) > Number of removed methods on Cuis: 796 > Number of new methods in current: 2192 > > Hope it is useful! > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 18, 2009

[Pharo-project] Loosing file name dowloading PRFile

by Dennis Schetinin

I use Pier in pharo0.1-10268web09.04. When I try to download a File I added before, original file name is ignored and it is named as 'Pier' always. The contents is correct. -- Dennis Schetinin

April 18, 2009

[Pharo-project] Fwd: [squeak-dev] Re: Statistics on merging Cuis with 3.10 on Morph hierarchy

by Mariano Martinez Peck

It may be of help. ---------- Forwarded message ---------- From: Hernan Wilkinson <hernan.wilkinson(a)gmail.com> Date: Fri, Apr 17, 2009 at 9:58 PM Subject: [squeak-dev] Re: Statistics on merging Cuis with 3.10 on Morph hierarchy To: The general-purpose Squeak developers list < squeak-dev(a)lists.squeakfoundation.org> Here are the same statistics but with Pharo dev 09.02.3, Squeak 3.7 and Cuis Number of Classes removed in Cuis: 271 Number of Classes added on Pharo: 0 Number of new Classes in Cuis: 5 Number of Classes to merge: 59 Number of same methods: 858 Number of changed methods on Cuis: 91 Number of new methods on Cuis: 95 Number of conflicting methods: 66 (methods on 3.7 that different with the ones in Pharo and Cuis) Number of changed methods on Pharo: 162 (from 3.7) Number of removed methods on Cuis: 555 Number of new methods in Pharo: 2387 So, to merge Cuis Morph hierarchy with Pharo, 91+95 methods from Cuis have to be loaded in Pharo and 66 methods have to be integrated by a human. To merge Cuis Morph hierarchy with Squeak 3-10, 117+66 methods from Cuis have to be loaded in Squeak 3.10 and 44 methods have to be integrated by a human. I ran the statistics only on the Morph hierarchy because what seems to be faster in Cuis is the UI. I'm assuming that the Cuis changes in the Morph hierarchy is what makes Cuis run faster, but I'm not sure of that... of course we can run the same process for other hierarchies, packages, all the classes, etc. And if somebody is interesting in knowing which classes, methods, etc. are involved (the real stuff, not only the numbers), just let me know. Hernan. On Fri, Apr 17, 2009 at 5:47 PM, Hernan Wilkinson < hernan.wilkinson(a)gmail.com> wrote: > Hi, > here is a statistics I made about taking Squeak 3.10 and merging Cuis with > it on the Morph hierarchy, just to have an idea on how much it could take... > > Number of Classes removed in Cuis: 265 > Number of Classes added on 3.10: 0 > Number of Classes added on Cuis: 5 > Number of Classes to merge: 59 > Number of same methods: 930 > Number of changed methods on Cuis: 117 > Number of new methods on Cuis: 66 > Number of conflicting methods: 44 (method on 3.7 is different that the > one in 3.10 that in Cuis) > Number of changed methods on current: 109 (from 3.7) > Number of removed methods on Cuis: 796 > Number of new methods in current: 2192 > > Hope it is useful! >

April 18, 2009

Re: [Pharo-project] Nile and pharo?

by StÃ©phane Ducasse

Thanks markus. It is probably related to the point alex raised. Since now traits do not share their methods it may happen that a conflict arise when it should not. Could you do me a favor and load the fixes proposed by alex that he published in the Traits project on squeaksource. And redo your experiment this way we may learn something. Stef On Apr 18, 2009, at 9:43 PM, Markus Fritsche wrote: > Markus Fritsche <fritsche.markus(a)gmx.net> wrote: > >> I installed Nile from the Universe. I wonder if it's a) my image or >> if b) >> Nile/ c) Pharo Traits is broken? For instance, >> NSCollectionStreamTest gives >> me an error: > >> 'A class or trait does not properly resolve a conflict between >> multiple >> traits it uses.' > > I downloaded the advertised pharo-dev image, installed universe, nile, > started the test... same error (so, at least once, a) is not the > culprit > :-P) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 18, 2009

Re: [Pharo-project] [ANN] release new image for 20281 on gforge.

by StÃ©phane Ducasse

I know I was just buzy fixing my house and tons of other stuff. stef On Apr 18, 2009, at 8:53 PM, Damien Cassou wrote: > On Sat, Apr 18, 2009 at 6:02 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> take the 20268 image and press update and you will get the answer to >> your question >> after a long period of time. :) > > Yes, please continue so that we all start from the same image. > >> So I do update for you not for me. Since I have all the intermediate >> images >> in general updating takes me no time but for you it can be a >> different >> story >> because this is not obvious that you get all the intermediate release >> images. >> >> Normally except for closure introduction there is no incompatibility >> this is >> just that normally people start to complain... Here you see that >> damien did >> a dev before a core because he was fed up to update :) > > The more I buid dev images, the more people test recent fixes :-). > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 18, 2009