- Pharo-dev - lists.pharo.org

[Pharo-project] Found it! [Was: A dog-slow browser ]
by Igor Stasenko May 9, 2010

May 9, 2010

Hello guys, sorry for resurrecting this topic, but i seem found the cause of it: - its an annotation pane, which makes browsing so slow! Right now i have two browser windows opened - one with annotation pane, and other is not. The amount of delay between selecting a particular method and showing it in a code pane is significant. Its even different in a look & feel: if you have annotation pane turned on, each time you selecting a different method, it turns mouse cursor to a hourglass for a moment, and then turns it back to arrow. And while in browser without annotation panes i can scroll through methods list without feeling any seeming delay, in window with annotation pane, its feel like a system using a pigeons to deliver a method's sources to me :) On 20 January 2010 18:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > Please, don't take it as a offense, but as a constructive critics :) > > Pharo-core browser is awfully slooow! > That's why i prefer to develop in squeak trunk image. > Why it showing the distracting hourglass cursor when stepping over a > list of methods in method's list? > > (press and hold the up arrow key when inside a methods list)... damn.. > what happens there, that it consumes so much time > to just switch the source code in a single text pane? > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

5 9

[Pharo-project] Where is my beloved annotation panes?
by Igor Stasenko May 9, 2010

May 9, 2010

Hi, guys, the first thing, which i always doing on fresh image is turning on the annotation panes, so i can always see the method's author and last modification date. I found that in newest pharo1.1.(11343) this option (as well as many others) is gone from preferences browser. Please, tell me that you didn't removed it, and this is only a temporary regression. -- Best regards, Igor Stasenko AKA sig.

2 2

[Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore
by StÃ©phane Ducasse May 9, 2010

May 9, 2010

Hi We cannot do Smalltalk condenseChanges and this is a showStopper for 1.1 beta. http://code.google.com/p/pharo/issues/detail?id=2367 After some hours of debugging, Lukas has the intuition that this is related to methodTrailer. I did some stupid tests... and apparently the problem occured between 11117 and 11128 If you take 11117 and run Utilities readServerUpdatesThrough: 3922 saveLocally: true updateImage: true and in a 11120 image Smalltalk condenseChanges is working. So the problem is somehow related to methodTrailer. Igor can you have a look? Stef 11118 - Issue 1701: ArchiveViewer now works on Pharo - Issue 1679: InputEventSensor refers to defunct class InputSensor - Issue 1703: Closing last windows raise error - Issue 1698: Enhancement: trunk #collect:as: is a must 11119 - Issue 1711: Cleaning host menu' 11120 - Cleaning some tests. #testSort, #testRestoreDefaultFonts - Issue 1691: Adding some tests for formalParameterAt: from nicolas - Moved FixedIdentitySet to Collections-Unordered - Better comments. - Better shuffledBy: - Issue 1713: Clean Duplication in widthOfString:from:to: 11121 - Issue 1690: New Method Trailer part 1 (cs 1_ and 2_) 11122 - Issue 1690: New Method Trailer part 2 (cs 3 merged) 11123 - Issue 1690: New Method Trailer part 3 (cs 4 no conflict) 11124 - Issue 1690: New Method Trailer part 4 (cs 5) 11125 - Issue 1690: New Method Trailer part 5 (cs 6 + postscript cs7) 11126 - Issue 1690: New Method Trailer part 6 (cs 8 - trailer) 11127 - Issue 1690: New Method Trailer part 7 (cs 9) 11128 - Issue 1690: New Method Trailer post clean up :)

4 17

[Pharo-project] Emerging Languages Camp
by Serge Stinckwich May 9, 2010

May 9, 2010

No one could talk about Pharo at this event ? http://emerginglangs.com/speakers/ -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

4 6

[Pharo-project] Build squeak vm screencast updated (with FT2Plugin and Alien)
by laurent laffont May 9, 2010

May 9, 2010

on pharocasts: http://pharocasts.blogspot.com/2010/03/build-squeak-vm-on-linux.html Feedback always appreciated :) Cheers, Laurent Laffont

2 1

[Pharo-project] Fwd: Pharo 1,1 -beta
by StÃ©phane Ducasse May 9, 2010

May 9, 2010

:) No political correctness please :) We have the rights to disagree :) Begin forwarded message: > From: Henrik Johansen <henrik.s.johansen(a)veloxit.no> > Date: May 9, 2010 2:09:35 AM GMT+02:00 > To: "stephane.ducasse(a)gmail.com" <stephane.ducasse(a)gmail.com> > Subject: Pharo 1,1 -beta > > Dear Stephane. > Please forward to whomever else it may concern, a bit too rantish to send to the general mailing list though :) > I'd wish we were able to meet face to face, as the 2 points I'd like to make would be much easier to make without creating any sort of animosity if I had an an instant opportunity to clearify any details. > > 1.RevertLinkedLists or not, I don't really care. (though, reading through my late-night posts, some degree of personal pride might wrongfully be read into it, for which I apologize) > It's a trade-off between handling adding objects and links equivalently, or disallowing this. The current implementation is easier to use, while one which allows adding links only is simpler implementation-wise. > It IS important to reach a deciscion for 1.1 though, as it can have long-lasting consequences support-wise. > No matter what the outcome, please don't remove the objective improvements over Squeak, like the swap method, which actually works. ;) > > Point 2: We CAN NOT release a beta version of 1.1 in which WeakDictionaries depend on their users to register them for finalization in order to work correctly/reliably. > The idea behind the new weakdicts is sound (avoid rehashes whenever removals occur), the implementation however is unsound. (independent of the 10 or so issues which have been resolved for it so far). I have detailed some of my frustrations in comments to / new issues, afraid I can't reference those when writing from my iPhone though. > > The weather here at my friend's is really nice, and I hope you (and Lukas?)'ll have better weather tomorrow :D > > Cheers, > Henry

1 1

[Pharo-project] Issue 2397 fixed and ready to harvest
by Torsten Bergmann May 9, 2010

May 9, 2010

-- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

2 1

Re: [Pharo-project] [vwnc] Survey: Changing method names in JNIPort?
by Mariano Martinez Peck May 8, 2010

May 8, 2010

On Sat, May 8, 2010 at 9:52 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Sat, May 8, 2010 at 9:39 PM, stephane ducasse < > stephane.ducasse(a)gmail.com> wrote: > >> >> On May 8, 2010, at 9:31 PM, Joachim Geidel wrote: >> >> > Hello everybody! >> > >> > I am preparing to port JNIPort (the Smalltalk-to-Java interface) to >> Squeak >> > and Pharo. However, there is a complication: Squeak and Pharo don't >> accept >> > underscores in method names, >> >> Pharo does... >> > > > Only Pharo 1.1. > > Sorry. I forgot to say that I have the same problem with GLORP. For the moment, what I do for Pharo 1.0 is to load an ugly hack: (HTTPSocket httpGet: ' http://www.assembla.com/spaces/SqueakDBX/documents/dvVhPSvuCr3OqXeJe5aVNr/d…') readStream fileIn You can see that .cs if you want. Cheers Mariano > > >> >> > while Dolphin and VisualWorks have no problem >> > with underscores. JNIPort contains many methods with underscores. >> > >> > If you are a JNIPort user, I would like to hear what you think about the >> > ways to solve this problem. Opinions from non-users are welcome, too, of >> > course. >> > >> > I currently see two options: >> > >> > 1. I can keep the versions for all platforms in sync. Obviously, I would >> > prefer this solution, as it is less work for me. On the other hand, >> users of >> > JNIPort would have to get used to new naming conventions: >> > >> > - All underscores would be dropped from method names. As method names >> for >> > generated methods include the type names of the arguments, this can lead >> to >> > somewhat ugly looking names, as the usual camel case notation is not >> > necessarily respected. E.g., >> > get_int: would be replaced by getint: >> > get_Object:String: would be replaced by getObject:String: >> > In those simple cases, the new notation doesn't look much worse than >> before. >> > >> > - Static fields in Java tend to have uppercase names with underscores, >> which >> > I would have to drop, too: >> > get_MAX_VALUE -> getMAXVALUE >> > set_MAX_VALUE: -> setMAXVALUE: >> > This has a small potential for naming conflicts if two field names in >> the >> > same class differ only by underscores. But you can always use lower >> level >> > methods for accessing a field if the generated method is ambiguous. >> > >> > - For names of inner classes which contain a $ character, I can't >> replace $ >> > by _ anymore, and would use 0 (zero) instead - it doesn't look much >> worse >> > than the $ character in Java, and I can't come up with something nicer >> which >> > is a legal character in a selector. >> > >> > 2. I could leave the VisualWorks version as it is, and maintain a second >> > code branch for Squeak and Pharo. I don't like this solution, as it >> means >> > more work for me. For JNIPort users, it would mean that their code isn't >> > easily portable to Squeak. OTOH, it would preserve the current >> more-or-less >> > nice-looking method names in generated classes. >> > >> > So, what do you think? >> > >> > Joachim Geidel >> > >> > >> > _______________________________________________ >> > vwnc mailing list >> > vwnc(a)cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> >> _______________________________________________ >> vwnc mailing list >> vwnc(a)cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > >

1 0

May 8, 2010

https://gforge.inria.fr/frs/download.php/26970/PharoCore-1.1-11343-UNSTABLE…

1 0

Re: [Pharo-project] [vwnc] Survey: Changing method names in JNIPort?
by Tudor Girba May 8, 2010

May 8, 2010

Hi Joachim, As far as I know, Pharo now supports underscores in method names. Am I wrong? Cheers, Doru On 8 May 2010, at 21:31, Joachim Geidel wrote: > Hello everybody! > > I am preparing to port JNIPort (the Smalltalk-to-Java interface) to > Squeak > and Pharo. However, there is a complication: Squeak and Pharo don't > accept > underscores in method names, while Dolphin and VisualWorks have no > problem > with underscores. JNIPort contains many methods with underscores. > > If you are a JNIPort user, I would like to hear what you think about > the > ways to solve this problem. Opinions from non-users are welcome, > too, of > course. > > I currently see two options: > > 1. I can keep the versions for all platforms in sync. Obviously, I > would > prefer this solution, as it is less work for me. On the other hand, > users of > JNIPort would have to get used to new naming conventions: > > - All underscores would be dropped from method names. As method > names for > generated methods include the type names of the arguments, this can > lead to > somewhat ugly looking names, as the usual camel case notation is not > necessarily respected. E.g., > get_int: would be replaced by getint: > get_Object:String: would be replaced by getObject:String: > In those simple cases, the new notation doesn't look much worse than > before. > > - Static fields in Java tend to have uppercase names with > underscores, which > I would have to drop, too: > get_MAX_VALUE -> getMAXVALUE > set_MAX_VALUE: -> setMAXVALUE: > This has a small potential for naming conflicts if two field names > in the > same class differ only by underscores. But you can always use lower > level > methods for accessing a field if the generated method is ambiguous. > > - For names of inner classes which contain a $ character, I can't > replace $ > by _ anymore, and would use 0 (zero) instead - it doesn't look much > worse > than the $ character in Java, and I can't come up with something > nicer which > is a legal character in a selector. > > 2. I could leave the VisualWorks version as it is, and maintain a > second > code branch for Squeak and Pharo. I don't like this solution, as it > means > more work for me. For JNIPort users, it would mean that their code > isn't > easily portable to Squeak. OTOH, it would preserve the current more- > or-less > nice-looking method names in generated classes. > > So, what do you think? > > Joachim Geidel > > > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

1 0