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

Re: [Pharo-project] Fwd: MouseOverHandler

by StÃ©phane Ducasse

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

Nov. 3, 2009

[Pharo-project] Compiler compile:

by Niko Schwarz

Hi list, consider this code: c := Compiler compile: 'meth "bla" ^ 2'. Here, c will be set to the symbol #meth. And Compiler will be added a new method "meth". This is of course counter-intuitive, but it's kind of wired into the system. Behavior>compile: does certainly more than compile. It compiles the code and adds it to itself, then returns the methodName as a symbol. Without mirrors, it's hard to do it right, though. Also, there's an easy method to add a method to a class, but no easy method to get a CompiledMethod object. I don't want to strongly advocate for my change, I just want to offer it. Here's what I did in my system: I changed Compiler>compile: to do the following: class side: compile: aString onClass: aClass ^ self new compiledMethodFor: aString onClass: aClass instance side: compiledMethodFor: textOrStream onClass: aClass | methodNode method | class := aClass. self from: textOrStream class: class context: nil notifying: nil. methodNode := self translate: sourceStream noPattern: false ifFail: [^self error: 'Compilation failed']. method := methodNode generate: #(0 0 0 0). self interactive ifTrue: [method := method copyWithTempsFromMethodNode: methodNode]. ^method This has its own problem, like: compile: suddenly has different semantics on Compiler than anywhere else. Best might be renaming Behavior>compile: to something more intuitive. Like #compileFromAndAdd:. Cheers, Niko

Nov. 3, 2009

Re: [Pharo-project] Unicode support problems

by Alexandr Batalshikov

On Tue, Nov 3, 2009 at 4:00 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > Alexandr Batalshikov wrote: > > For now, some unicode symbols is impossible input from keyboard > > (at least, russian letters 'Ð', 'Ð', 'Ð' on Windows platform). > > I found some solution of this problem: > > in method ParagraphEditor>>dispatchOnKeyEvent:with: > > replace line: > > keyValue := keyValue ifNil: [keyEvent keyValue]. > > with line: > > keyValue := keyValue ifNil: [keyEvent keyCharacter asInteger]. > > In general it looks like most (all?) senders of keyValue should rather > use keyCharacter. > > Apparently, yes. At least, this is not seems to be simple typo error in Unicode tables.

Nov. 3, 2009

[Pharo-project] ScriptLoader does not implement loadComanche

by Torsten Bergmann

see http://code.google.com/p/pharo/issues/detail?id=1398 If you are in a dev-image you can use: loadSeaside30 [ self gofer new squeaksource: 'Seaside30'; addPackage: 'LoadOrderTests'; load ] valueSupplyingAnswers: { {'Load Seaside'. true}. {'SqueakSource User Name'. ''}. {'SqueakSource Password'. ''}. {'Run tests'. false}. }. "Set up to development environment (enables seaside web toolbar) " (self environment at: #WAAdmin) applicationDefaults addParent: (self environment at: #WADevelopmentConfiguration) instance. (self environment at: #WASqueakServerAdaptorBrowser) open -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Nov. 3, 2009

Re: [Pharo-project] Unicode support problems

by Michael Rueger

Alexandr Batalshikov wrote: > For now, some unicode symbols is impossible input from keyboard > (at least, russian letters 'Ð', 'Ð', 'Ð' on Windows platform). > I found some solution of this problem: > in method ParagraphEditor>>dispatchOnKeyEvent:with: > replace line: > keyValue := keyValue ifNil: [keyEvent keyValue]. > with line: > keyValue := keyValue ifNil: [keyEvent keyCharacter asInteger]. In general it looks like most (all?) senders of keyValue should rather use keyCharacter. > I also notice other strange things: method KeyboardEvent>>keyCharacter > sends up to 14 times for one keyboard pressing. > Is this normal? I'm afraid yes, but it would still be interesting to trace who all these senders are. Key handling in Morphic is a mess, so there should be lots of room for improvement. Michael

Nov. 3, 2009

[Pharo-project] ScriptLoader does not implement loadComanche

by Hernan Wilkinson

Does anybody know why? If I want to load Seaside 3.0 from scratch using the ScriptLoader, it does not work becuase loadComanche is not implemented. I solved it copying the implementation from a previous version...

Nov. 3, 2009

[Pharo-project] IRC link in webpage is wrong

by Torsten Bergmann

We can also link to http://webchat.freenode.net/?channels=pharo-project providing access using a browser... -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Nov. 3, 2009

[Pharo-project] Unicode support problems

by Alexandr Batalshikov

For now, some unicode symbols is impossible input from keyboard (at least, russian letters 'Ð', 'Ð', 'Ð' on Windows platform). I found some solution of this problem: in method ParagraphEditor>>dispatchOnKeyEvent:with: replace line: keyValue := keyValue ifNil: [keyEvent keyValue]. with line: keyValue := keyValue ifNil: [keyEvent keyCharacter asInteger]. Then save method and that's all. Cause of the problem: expressoin "keyEvent keyValue" return small number for all symbols, unclude unicode and give activation of shortcut events, defined in methods ParagraphEditor class>>initializeCmdKeyShortcuts, ParagraphEditor class>>initializeShiftCmdKeyShortcuts. I also notice other strange things: method KeyboardEvent>>keyCharacter sends up to 14 times for one keyboard pressing. Is this normal? Regards, Alexander Batalshikov.

Nov. 3, 2009

Re: [Pharo-project] IRC link in webpage is wrong

by Adrian Lienhard

thanks. Adrian On Nov 2, 2009, at 21:52 , Mariano Martinez Peck wrote: > If you go to http://www.pharo-project.org/community and see the > link of " > irc.freenode.net" you will see the link is > http://www.pharo-project.org/irc.freenode.net but that is wrong. I > think > it should be > > irc://irc.freenode.net/#pharo-project > > This was reported in the IRC channel. Thanks to the reporter ;) > > Best regards, > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 3, 2009

Re: [Pharo-project] implementors and senders when there is only one result

by Henrik Johansen

Working mostly in VisualWorks, I too sometimes miss those when doing stuff in Pharo. What would be even cooler imho, would be using RoelTyper to find (potential) results only for the specific method you asked for senders of :) Cheers, Henry On Nov 3, 2009, at 8:30 16AM, Torsten Bergmann wrote: > > It also provides a "local senders" and "local implementors" > functionality (searching only within the class (hierarchy) itself) as > you will find in most Smalltalks. > > This browser provides a nice way to go through the system and follow > message chains. > > Bye > Torsten > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > <stmt.png>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 3, 2009