- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #11042
by Marcus Denker Nov. 14, 2009

Nov. 14, 2009

11042 ----- Issue 1438: Project removal continued.... Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

1 0

[Pharo-project] macintosh carbon VM goes to legacy status.
by John M McIntosh Nov. 14, 2009

Nov. 14, 2009

The macintosh carbon VM is going into a legacy support state. Why? ESUG has provided me with some funds to help build a new 32/64 bit Cocoa (intel/ppc) based Squeak VM, please don't forget to thank them for supporting the community. Today based on the iPhone VM tree and many more hours of effort I managed to start up a 64 bit intel based Cocoa VM using a 32bit squeak image. I still have a "bit" more to go in order to get the keyboard logic to correctly mimic the older carbon behaviour, so I won't start public beta testing until the end of the month. And it only feels like a sea of "warning: cast from pointer to integer of different size" to work thru, but previous efforts by folks like David T Lewis has reduced that to I think a manageable issue. If you are interested in alpha testing the VM please email me privately and I'll see if I can get you a workable VM by the end of next week. The primary project goal is to: Build a new cocoa based 32/64bit intel/ppc VM with an MIT license, basically from scratch, to enable the ability to use a 32bit image or 64bit image. Some other objectives: To build it from scratch using the 4.2.2 VM as a reference To ensure the xcode project can build both an OSX VM and a iPhone VM. Port as little code from the past, excluding the Socket and basic file I/O logic. Other plugins address as needed. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

1 0

[Pharo-project] status about hash changes
by StÃ©phane Ducasse Nov. 14, 2009

Nov. 14, 2009

Hi andres and martin what is the status of the changes you proposed ? Because it would be nice to integrate them. Stef

2 2

[Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?
by CÃ©drick BÃ©ler Nov. 13, 2009

Nov. 13, 2009

Hi, I noticed quite a difference between the two method who "looks" the same to me. Is it normal ? I use a rc image (haven't tested in squeak). And it's the same on windows and linux. count := 0. [1 to: 10000000 do: [:i | count :=count + 1]] timeToRun." 677" count := 0. [10000000 timesRepeat: [count := count + 1]] timeToRun" 2571" If not normal, I'll open a issue. Thanks -- CÃ©drick

9 15

[Pharo-project] Fwd: Fwd: MouseOverHandler
by StÃ©phane Ducasse Nov. 13, 2009

Nov. 13, 2009

Yeah let us be wild. Stef Begin forwarded message: > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > Date: November 13, 2009 2:29:53 PM GMT+01:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] Fwd: MouseOverHandler > > If you want to play then load Synchronization-gvc.1.mcz from the Polymorph squeaksource repo. > Optionaly, load Morphic-Synchronization-gvc.1.mcz for protecting the morphic event loop with a synchronisation monitor. > > Any questions, just ask... Have fun. > > Regards, Gary > > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr>; <gazzaguru2(a)btinternet.com> > Sent: Tuesday, November 03, 2009 3:40 PM > Subject: Re: [Pharo-project] Fwd: MouseOverHandler > > > excellent! > we are in alpha so we can be wild :) > > Stef > > On Nov 2, 2009, at 10:36 PM, Gary Chambers wrote: > >> No arguments on weak stuff... VisualAge did a good job of those things >> (perhaps the garbage collector was better integrated with the concept). >> >> The driving force for our synchronisation stuff was the need to provide >> timely feedback, in terms of screen redraws, driven from separate >> processes that, for instance, were monitoring keystrokes from >> non-standard keypad devices, network messages etc. Was a necessity and >> proven in the field! I can get things together as a package later in the >> week. Very small footprint for a generalised per-object/sub-object >> scheme. >> >> On Mon, 2009-11-02 at 16:24 -0500, Schwab,Wilhelm K wrote: >>> Stef, Gary, >>> >>> Having recently ranted a little about thread safety for weak collection, how can I argue? Well, let me see if I can do so and keep my credibility intact :) >>> >>> Squeak's weak collections, and we have not moved beyond their limitations, do not clean themselves after their elements are finalized. That means they do half of what they should do; once they do all of it, they need to be thread safe; hence they do one third of what they should do. >>> >>> The GUI is arguably a little different. #addDeferredUIMessage: provides a clean way to interact with it from background threads, and that might be enough. IDE specific messages (e.g. #inspect) could probably stand to be queued to make them safe w/o horrible penalties, with the remainder of the GUI understood not to be thread safe for performance reasons. A backround thread can do expensive calculations and then queue a GUI update to safely update the display. >>> >>> Bill >>> >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse >>> Sent: Monday, November 02, 2009 3:28 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Fwd: MouseOverHandler >>> >>> Hi gary >>> do you think that it make sense to have it in general (my gut feeling is saying yes but I'm not thread-safe) >>> >>> If yes, yes we are interested for 1.1 >>> >>> BTW hernan I integrated your changes now it would be interesting to understand from where this nil is coming. >>> >>> Stef >>> On Nov 2, 2009, at 8:58 PM, Gary Chambers wrote: >>> >>>> Yet the cause is unexplained. I still think it is due to non-ui >>>> processes fiddling with morphs (likely delettion or creation). >>>> The Morphic event loop remains non-thread safe. We have some >>>> modifications to ensure thread safety, based on a generalised >>>> synchronisation protocol if anyone is interested. >>>> >>>> Regards, Gary >>>> ----- Original Message ----- >>>> From: Hernan Wilkinson >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Sent: Monday, November 02, 2009 7:45 PM >>>> Subject: Re: [Pharo-project] Fwd: MouseOverHandler >>>> >>>> Hi Adrian, >>>> the current implementation has problems, ie. send messages to nil, >>>> and it bothers a lot when that happens because it comes from >>>> nowhere... >>>> I've been using this implementation for a long time in my images and >>>> I did not get those problems anymore (and it is more readable...) >>>> >>>> On Sat, Oct 31, 2009 at 2:41 PM, Adrian Lienhard <adi(a)netstyle.ch> >>>> wrote: >>>> Hi Hernan, >>>> >>>> The reason this was not integrated is that nobody marked it as 'fixed' >>>> nor tagged it as 1.0. >>>> >>>> Is this critical for 1.0? >>>> >>>> Cheers, >>>> Adrian >>>> >>>> BTW, if anybody sees changes/fixes not being integrated please ask on >>>> the mailing list. >>>> >>>> >>>> On Oct 31, 2009, at 14:29 , StÃ©phane Ducasse wrote: >>>> >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Hernan Wilkinson <hernan.wilkinson(a)gmail.com> >>>>>> Date: October 29, 2009 2:02:32 PM GMT+01:00 >>>>>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>>>> Subject: MouseOverHandler >>>>>> >>>>>> Hi Stef, >>>>>> do you know why the MouseOverHandler version I made is not in the >>>>>> main image? the current version is not working well, under heavy >>>>>> use it generates exceptions... >>>>>> I'm attaching the version I wrote that I'm using without >>>> problem... >>>>>> >>>>>> Hernan. >>>>> <MouseOverHandler.st> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

2 1

[Pharo-project] [update 1.1] #11041
by Marcus Denker Nov. 13, 2009

Nov. 13, 2009

11041 ----- Issue 1436: ClassFactoryForTestCase generate classes which name is a String instead of a Symbol Issue 640: Debugger buildMorphicNotifierLabelled:message: calls: eToyFriendly Issue 1425: Inspector does not handle correctly isVariable class with inst var -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

1 0

[Pharo-project] New Pharo based on core 10495
by Damien Cassou Nov. 13, 2009

Nov. 13, 2009

http://pharo-project.org/pharo-download -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

1 0

[Pharo-project] Issue 1437 : Bitmap #decompress:fromByteArray:at: not wellformed
by arnaud Jean Baptiste Nov. 13, 2009

Nov. 13, 2009

I paste the issue open : the primitive method #decompress:fromByteArray:at: aren't well-formed, cause the code of this method is using by VMMaker to generate source code of the primitive, then it can happen which a selector using in the method was never implemented. Then if the code is fix VMMaker may not be able to generate a clean source code. the main point of this issue is the selector call: #primitiveFail, he doesn't exist in the Pharo environment and seem be change by #primitiveFailed which exist, and then the mistake can't be see if we don't try to generate to use VMMaker without using MiscPrimitivesPlugin. I post a fix in the Inbox. i have simply correct #primitiveFailed to #primitiveFail If you have a better solution i will be glad to discuss with you. link : http://code.google.com/p/pharo/issues/detail?id=1437

1 0

[Pharo-project] testing morphs
by Tudor Girba Nov. 13, 2009

Nov. 13, 2009

Hi, I would like to test the code related to rendering a morphic interface. In particular, I would like to test the rendering of Glamour browsers with morphic. The problem is that the rendering happens in another process than my regular test code. Any idea of how I could solve this problem? Cheers, Doru -- www.tudorgirba.com "Don't give to get. Just give."

2 4

[Pharo-project] accessors entry in submenu of refactor class menu (OB package Browser)
by csrabak＠bol.com.br Nov. 13, 2009

Nov. 13, 2009

Is it by design decision: That we don't have a way to create accessor (specifically the getters) that do lazy evaluation? The way the tool works now is that if one clicks refactor->accessors you get a new window with all accessors "created" and you have to delete the ones you don't want? And last but not least, if I attempt to edit a method in the new window "Changes: refactor class, accessors" I get an MNU: OR2AddMethodChangeNode(Object)>>doesNotUnderstand: #selectedClass. -- Cesar Rabak

3 6