- Pharo-dev - lists.pharo.org

[Pharo-project] About a better way to curving out etoy
by StÃ©phane Ducasse Oct. 16, 2008

Oct. 16, 2008

hi guys I would like to get some support from the tools to help us curiving out etoys. Here is the scenario: when I see a method I would like to see a color or symbol which tell me how many sender kinds were calling this method either statically or dynamically. I would like to put etoy classes in red and see the colors propagating in the system. So we could get a kind of coloring schema. We could do the same with letters then we could have some single colored methods or mix Alex/Damien do you want to help because this could be fun? Then when i see how I work I always do a kind of yoyo between senders and implementers it would be really interesting to log the senders and implementers so that we could trace back the sequence and understand also how the remove happen and the frequency of the removal. Stef

1 0

[Pharo-project] [updates] 10096
by Marcus Denker Oct. 16, 2008

Oct. 16, 2008

update10096 ----------- Issue 247: remove #hashMappedBy: Issue 243: SMTPClient fix for authentication and support for EHLO (Mantis #6768) Issue 233: fix for BreakPoint Issue 229: remove preference Panel -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 0

[Pharo-project] One click feature list request/question
by Torsten Bergmann Oct. 16, 2008

Oct. 16, 2008

Alexandre wrote >JavaConnect is pretty easy to use and works quite well. >But there is no port to Squeak as far as I am aware of. As I said in the "future" - if pharo grows and is used in commercial applications the pressure may be high enough. Since I work with both languages I might have a look sooner or later myself. As always this mostly depends on time. Or it may become the next Google Summer of code project for a student. According to the comments Joachim made on my blog [1] JNIPort may be easier to port than JavaConnect. It was already ported from Dolphin to VW, supports callbacks and does not require namespaces. On the other hand namespaces are planned for Pharo too. So we will see... At least we need a good FFI since Java is not the only interesting technology out there to integrate. Keep on talking small Torsten [1] http://astares.blogspot.com/2008/04/javaconnect-java-assmalltalkvalue.html?… -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

1 0

[Pharo-project] One click feature list request/question
by Torsten Bergmann Oct. 16, 2008

Oct. 16, 2008

>Go Eliot, go! Any news from the "new FFI" front? Last thing I've heard was [1] >Squeak talk to Java Maybe "JavaConnect" or "JNIPort" using FFI can can help here in the future (see [2]) Bye Torsten [1] http://www.nabble.com/Re:--squeak-dev--Re:-About-Eliot-FFi-changes-p1953668… [2] http://astares.blogspot.com/2008/04/javaconnect-java-assmalltalkvalue.html -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

2 1

[Pharo-project] dual changesorter
by StÃ©phane Ducasse Oct. 16, 2008

Oct. 16, 2008

hi adrian the dual change sorter is better than the simple one (I never used that one) but a lot the other since it allows you to copy changes between cs. Stef

2 1

[Pharo-project] Removing the "Pharo" flap at the left?
by Adrian Lienhard Oct. 15, 2008

Oct. 15, 2008

I think we don't need this flap anymore. What it contains: - the current time (I already have one on my screen) - "load code updates" (is easy to find in the menu today, i.e. world- >System->Software update) - "about this system" (dito, i.e. world->System->About) - "change theme" (there is only one alternative left, which looks ugly) - A huge trash icon (this one we still need to remove EToys! ;)) Any objections? Adrian ___________________ http://www.adrian-lienhard.ch/

3 2

[Pharo-project] [ANN] new 10095 prebuild image
by Marcus Denker Oct. 15, 2008

Oct. 15, 2008

Hi, There is now a new core image available based on 10095: https://gforge.inria.fr/frs/download.php/9395/Pharo0.1-10095.zip one-click will come soon, too. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 0

Oct. 14, 2008

Hi I found that the compiler accepts [:bool : method | method] which is strange to me. Stef

2 1

Oct. 14, 2008

> A nice fix. > http://code.google.com/p/pharo/issues/detail?id=246&colspec=ID%20Type%20Sta… The discussion on squeakdev was interesting. > Stef > > Begin forwarded message: > >> From: "Eliot Miranda" <eliot.miranda(a)gmail.com> >> Date: October 13, 2008 9:43:15 PM CEDT >> To: "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org >> > >> Subject: Re: [squeak-dev] re: About classVariables >> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >> > >> >> >> >> On Mon, Oct 13, 2008 at 2:02 AM, Martin Beck <martin.beck(a)hpi.uni-potsdam.de >> > wrote: >> Craig Latta wrote: >> > >> > Hi Stef-- >> > >> >> To my stupefaction I discovered that the classVariables of a >> class are >> >> not the same as the ones of its metaclass. >> >> >> >> TheRoot classVarNames ~= TheRoot class classVarNames >> >> >> >> Does any body have some ideas why this is like that? For me this >> is a >> >> conceptual bug. >> > >> > Actually, metaclasses don't really have class variables at >> all. >> > Class variables are defined by Class, which is a sibling of >> Metaclass, >> > not a superclass. There's a method in Behavior which just answers >> a new >> > empty Set for classVarNames; this is what you're invoking when you >> > evaluate [TheRoot class classVarNames]. >> > >> However, >> >> TheRoot classPool = TheRoot class classPool >> >> evaluates to true... >> >> Regards, >> Martin >> >> One fix is to add the following method: >> ------------8<----------- >> !Metaclass methodsFor: 'class variables' stamp: 'eem 10/13/2008 >> 12:37'! >> classVarNames >> "Answer a Set of the names of the class variables defined in the >> receiver's instance." >> >> ^thisClass classVarNames! ! >> ------------8<----------- >> c.f. Metaclass>>classPool. >> >> But a better fix is to move Class>>classVarNames to ClassDescription: >> ------------8<----------- >> 'From Croquet1.0beta of 11 April 2006 [latest update: #1] on 13 >> October 2008 at 12:41:36 pm'! >> >> !ClassDescription methodsFor: 'class variables' stamp: 'eem >> 10/13/2008 12:41'! >> classVarNames >> "Answer a Set of the names of the class variables defined in the >> receiver." >> >> ^self classPool keys! ! >> >> Class removeSelector: #classVarNames! >> ------------8<----------- >> >> Whoever said that the class variables of a metaclass should be >> those of Metaclass is very wrong. Code compiled in the context of >> a metaclass includes the class variables of the non-metaclass >> (metaclass's instance), otherwise one couldn't access class >> variables in class-side methods. >> > > >

1 0

[Pharo-project] Long term GUI plans for Pharo
by Hans N Beck Oct. 14, 2008

Oct. 14, 2008

Hi all, I remember darkly a discussion about possibilities to give Sqeak or Pharo indepenend Windows not enclosed in a main window. An other point was to make Cairo the render base for all. So related to this points, what are the long term plans for pharo? Regards Hans --------------- Hans Beck Walzbachtal Germany

2 3