[Pharo-project] CompiledMethodTrailer with a different CompiledMethod class

[Hernán Morales Durand]

Hello

Just to make a little note. I'm adapting the lightweight classes
package to work with CompilerMethodTrailer. In this method

CompiledMethodTrailer>>createMethod: numberOfBytesForAllButTrailer
header: headerWord
| meth |
encodedData ifNil: [ self encode ].
meth := CompiledMethod newMethod: numberOfBytesForAllButTrailer +
size header: headerWord.
...

I need to answer a different kind of CompiledMethod, it would be nice
if my own CompiledMethod class could be specified in some way to make
the CompiledMethodTrailer more flexible.
Cheers,

Hernán

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] About the Pharo Issue tracker

[Adrian Lienhard]

Hi Guille and Carla,

Yes for certain actions you need to be a committer. I added you both. Please 
feel free to help maintaining the issue tracker :)

If an issue is not clear and lacking information, please add a note and/or ask 
in the mailing list. If an issue cannot be reproduced and the creator does not 
provide details, we just switch to "won't fix".

Another area that needs work is to identify which issues should still be 
tackled for 1.1. In the tracker we currently have over 200 issues for milestone 
1.1. Many are of the form "we should do X" and are not critical for the 1.1 
release. Others may be show stopper bugs that need to be fixed. Identifying the 
latter is important.

Cheers,
Adrian

On May 24, 2010, at 07:10 , Carla F. Griggio wrote:

> Hmm... if I wanted to change the status of an issue to Fixed (for example),
> I think I'm not able to do that either. Are you?
> 
> Should we be commiters to be able to do these things?
> 
> On Mon, May 24, 2010 at 2:04 AM, Carla F. Griggio
> wrote:
> 
>> Welcome, Guille :) It was very cool to have you in the Sprint :)
>> 
>> I notice that if I try to post a new issue, I can't categorize it. Who is
>> able to categorize issues?
>> 
>> Carla.
>> 
>> 2010/5/23 Guillermo Polito 
>> 
>>> Hi!
>>> 
>>> First I may introduce myself.  My name is Guillermo Polito and I'm from
>>> Argentina.  I've been using Pharo for several months with some colleagues
>>> that are already here to teach OOP in the UTN university, and i've been
>>> suscribed to this mailing list for some time.  But it's my first mail here
>>> :P.
>>> 
>>> I participated yesterday in the Pharo Sprint in Argentina and there I had
>>> my first look at the issue tracker.  And well, it seemed to me to be a
>>> little messy.  There are lots of issues that aren't properly explained, some
>>> of them are duplicated, and they are not well organized.
>>> It would be nice to use the labels googlecode provides to give them some
>>> categorization, so we can browse them in a more intelligent way.  Maybe we
>>> can split the issues in "modules" (like Collection issues, Compiler Issues,
>>> Closures Issues, Networking Issues...) or something like that.  That will
>>> help in avoiding duplications and looking for issues to solve (because I can
>>> look for issues in the modules I know the most).
>>> 
>>> At the moment I will stay looking for issues i can fix or commenting the
>>> ones that lacks information :).
>>> 
>>> Regards,
>>> Guille
>>> 
>>> 
>>> 
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>> 
>> 
>> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] CompiledMethodTrailer with a different CompiledMethod class

[Igor Stasenko]

On 24 May 2010 10:31, Hernán Morales Durand  wrote:
> Hello
>
> Just to make a little note. I'm adapting the lightweight classes
> package to work with CompilerMethodTrailer. In this method
>
> CompiledMethodTrailer>>createMethod: numberOfBytesForAllButTrailer
> header: headerWord
>        | meth |
>        encodedData ifNil: [ self encode ].
>        meth := CompiledMethod newMethod: numberOfBytesForAllButTrailer +
> size header: headerWord.
>        ...
>
> I need to answer a different kind of CompiledMethod, it would be nice
> if my own CompiledMethod class could be specified in some way to make
> the CompiledMethodTrailer more flexible.

Yes, you could add a class parameter, so method will take 3

createMethod: numberOfBytesForAllButTrailer header: headerWord class:
aMethodClass

> Cheers,
>
> Hernán
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

[Serge Stinckwich]

When i switch to demo mode, method selector in System Browser are no
more bold in the bottom pane.

2010/5/21 Mariano Martinez Peck :
> Hi Pharaoers. I am pleased to announce the first Pharo 1.1 beta based on
> PharoCore-1.1-11367-Beta. It is the first time we build a Pharo 1.1 dev
> image with PharoCore 1.1 so the image may be not 100% stable. However, we
> think it is good to release it so that people can start to test it, load
> their own packages, adapt them, etc. We would like to receive feedback about
> it. It (yet) has failing and error tests.
>
> The main changes with Pharo 1.0 is that of course, it is based on a
> PharoCore 1.1 with all that it means. We started to write down some of the
> actions done in PharoCore 1.1. The list so far can be found here:
> http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotOne
> Of course, for the stable releae of Pharo 1.1 we will do a clear list in the
> website as we did for 1.0.
>
> Regarding the included packages in 1.1 we added ScriptManager (a tool to
> manage and persist workspaces), ProfStefBrowser, ArchiveViewer,
> MethodWrappers and ObjectMetaTools (which includes things like
> ProtocolCatcher, ObjectTracer, ObjectViewer, etc).
>
> Another difference is the font. In Pharo 1.0 we used TrueType fonts by
> default. In Pharo 1.1 we use StrikeFonts (no need of TrueType plugin,
> netiher to have the fonts). However, of course, you can disable StrikeFonts
> and put TrueType like in 1.0.
>
> That's all. We would really appreciate you use it, test it, report issues,
> provide fixes, etc. It is important also that you start to use your own
> packages/applications. There have been several changes in 1.1 that may
> require change in your code.
>
> Ahh if you want to create the image yourself, check as usually the
> installScript.st file to see how to do it. Actually, you can just take a
> PharoCore-1.1-11367-Beta image and evaluate (the same procedure as 1.0):
>
> Gofer new
>     squeaksource: 'MetacelloRepository';
>     package: 'ConfigurationOfPharo';
>     load.
>
> ((Smalltalk at: #ConfigurationOfPharo) project version: '1.1-beta1.10517')
> load.
>
> Here is the link to the image:
>
> https://gforge.inria.fr/frs/download.php/27025/Pharo-1.1-11367-Betadev10.05.1.zip
>
> Cheers
>
> Mariano
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Bug? ParagraphEditor do-its are not following the expected method lookup

[Stéphane Ducasse]

cool!

Stef

On May 24, 2010, at 8:04 AM, Carla F. Griggio wrote:

> Well, just to let you know, I've submitted a fix to PharoInbox:
> 
> Name: SLICE-superBugInParagraphEditor-carlaGriggio.1
> Author: carlaGriggio
> Time: 24 May 2010, 2:33:50 am
> UUID: 94ff9a49-b4ba-488b-9470-777e0f1885a7
> Ancestors: SLICE-superBugInParagraphEditor-carlaGriggio.1
> Dependencies: Compiler-carlaGriggio.212, CompilerTests-carlaGriggio.42, 
> Kernel-carlaGriggio.665, ParagraphEditor-Test-carlaGriggio.1
> 
> But I can't change the status of the issue to fixed :P
> 
> On Wed, May 19, 2010 at 4:51 PM, Carla F. Griggio  
> wrote:
> Not the cs, I have an st. It's in the first email of this thread. I also 
> attached a cs with a possible fix.
> 
> 
> 
> On Wed, May 19, 2010 at 4:35 PM, Stéphane Ducasse  
> wrote:
> Yes this is an important bug
> do you have the cs of your little example?
> 
> Stef
> 
> On May 19, 2010, at 9:17 PM, Carla F. Griggio wrote:
> 
> > Just reproducing it would be helpful :O a friend of mine already
> > tested the code I attatched and saw the same problem.
> >
> > If you recall having a class with a method sending a message to super,
> > and a sublclass inheriting that method, you can try to reproduce it
> > there too debugging that message on an instance of the subclass.
> >
> > It's not easy to explain with words, that's why I made a little
> > package of code to illustrate the situation.
> >
> > The thing is that when printing the evaluation of a selected bunch of
> > code inside a debugger window (paragraphEditor?), if the code you're
> > evaluating is a message to super, and the class of the object you're
> > debugging is inheriting the method you're debugging, the printed
> > result will be wrong. In other words, the method lookup fails.
> >
> > This doesn't happen with normal excution of code (thank God!).
> >
> > I think this is an important bug, seeing those wrong results when
> > debugging can be very confusing. I spent hours feeling stupid last
> > Monday while debugging because I trusted those wrong results and
> > couldn't see where I was doing something wrong :P
> >
> > Cheers!
> > Carla
> >
> > On Wednesday, May 19, 2010, Mariano Martinez Peck  
> > wrote:
> >> Hi Carla. I would like to help you, but I have no idea. I could reproduce 
> >> it.
> >>
> >> Maybe Lukas, Igor, Eliot etc can help you. I have no idea.
> >>
> >> Cheers
> >>
> >> Mariano
> >>
> >> 2010/5/18 Carla F. Griggio 
> >> Hi everybody!
> >> Well, maybe you are already aware of this... maybe not. I tried to find an 
> >> issue about this and unless I didn't think of the right keywords, it's not 
> >> there.
> >>
> >>
> >>
> >> I was debugging a template method and sudenly I found myself spending ours 
> >> trying to find out why I got different results when printing the result of 
> >> a message sent to super and when steping into that message and printing 
> >> the (same) result there.
> >>
> >>
> >>
> >> Imagine this simple situation (I attatch the complete code and some tests 
> >> so you can reproduce this):
> >> AverageTotalization inherits from Totalization.WeightedAverageTotalization 
> >> inherits from AverageTotalization.
> >>
> >>
> >>
> >> Totalization>>total
> >>
> >>  ^self summatory
> >>
> >>
> >>
> >>
> >>
> >> AverageTotalization>>total
> >>
> >> ^(super total) / self denominator
> >>
> >>
> >>
> >>
> >>
> >> AverageTotalization>> denominator
> >>
> >> ^values size
> >>
> >>
> >>
> >>
> >> WeightedAverageTotalization>> denominator
> >>
> >> "Weights is a dictionary"
> >>
> >>  ^self weights values sum
> >>
> >>
> >>
> >>
> >> If I debug aWeightedAverateTotalization total  and try to print super 
> >> total in the debugger ParagraphEditor, I'll get this result:
> >>
> >>
> >>
> >> (self summatory / self denominator)
> >>
> >>
> >> instead of just:
> >> self summatory
> >> This only happens when I print or inspect or other do-its in the debugger 
> >> window. The method lookup works OK when just 
> >> ___
> >> Pharo-project mailing list
> >> Pharo-project@lists.gforge.inria.fr
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>
> >>
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] CompiledMethodTrailer with a different CompiledMethod class

[Stéphane Ducasse]

and send us the fix for inclusion :)

On May 24, 2010, at 10:54 AM, Igor Stasenko wrote:

> On 24 May 2010 10:31, Hernán Morales Durand  wrote:
>> Hello
>> 
>> Just to make a little note. I'm adapting the lightweight classes
>> package to work with CompilerMethodTrailer. In this method
>> 
>> CompiledMethodTrailer>>createMethod: numberOfBytesForAllButTrailer
>> header: headerWord
>>| meth |
>>encodedData ifNil: [ self encode ].
>>meth := CompiledMethod newMethod: numberOfBytesForAllButTrailer +
>> size header: headerWord.
>>...
>> 
>> I need to answer a different kind of CompiledMethod, it would be nice
>> if my own CompiledMethod class could be specified in some way to make
>> the CompiledMethodTrailer more flexible.
> 
> Yes, you could add a class parameter, so method will take 3
> 
> createMethod: numberOfBytesForAllButTrailer header: headerWord class:
> aMethodClass
> 
>> Cheers,
>> 
>> Hernán
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] About the Pharo Issue tracker

[Stéphane Ducasse]

On May 23, 2010, at 8:33 PM, Guillermo Polito wrote:

> Hi!
> 
> First I may introduce myself.  My name is Guillermo Polito and I'm from 
> Argentina.  I've been using Pharo for several months with some colleagues 
> that are already here to teach OOP in the UTN university, and i've been 
> suscribed to this mailing list for some time.  But it's my first mail here :P.

Welcome
> 
> I participated yesterday in the Pharo Sprint in Argentina and there I had my 
> first look at the issue tracker. 

Thanks for your time. I will go over the produced fixes today using Torch :)
> And well, it seemed to me to be a little messy.  There are lots of issues 
> that aren't properly explained, some of them are duplicated, and they are not 
> well organized.

And you would not imagine if we would not spend a lot of time on it
This is like a garden.

> It would be nice to use the labels googlecode provides to give them some 
> categorization, so we can browse them in a more intelligent way.  Maybe we 
> can split the issues in "modules" (like Collection issues, Compiler Issues, 
> Closures Issues, Networking Issues...) or something like that.  That will 
> help in avoiding duplications and looking for issues to solve (because I can 
> look for issues in the modules I know the most).
> 
> At the moment I will stay looking for issues i can fix or commenting the ones 
> that lacks information :).

Excellent

Tagging the entries with semantics is a good idea.
> 
> Regards,
> Guille
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] About the Pharo Issue tracker

[Stéphane Ducasse]

when you close or tag as won't fixes put on on the cc line or send an email to 
the mailing-list.

Stef

On May 24, 2010, at 7:04 AM, Carla F. Griggio wrote:

> Welcome, Guille :) It was very cool to have you in the Sprint :)
> 
> I notice that if I try to post a new issue, I can't categorize it. Who is 
> able to categorize issues?
> 
> Carla.
> 
> 2010/5/23 Guillermo Polito 
> Hi!
> 
> First I may introduce myself.  My name is Guillermo Polito and I'm from 
> Argentina.  I've been using Pharo for several months with some colleagues 
> that are already here to teach OOP in the UTN university, and i've been 
> suscribed to this mailing list for some time.  But it's my first mail here :P.
> 
> I participated yesterday in the Pharo Sprint in Argentina and there I had my 
> first look at the issue tracker.  And well, it seemed to me to be a little 
> messy.  There are lots of issues that aren't properly explained, some of them 
> are duplicated, and they are not well organized.
> It would be nice to use the labels googlecode provides to give them some 
> categorization, so we can browse them in a more intelligent way.  Maybe we 
> can split the issues in "modules" (like Collection issues, Compiler Issues, 
> Closures Issues, Networking Issues...) or something like that.  That will 
> help in avoiding duplications and looking for issues to solve (because I can 
> look for issues in the modules I know the most).
> 
> At the moment I will stay looking for issues i can fix or commenting the ones 
> that lacks information :).
> 
> Regards,
> Guille
> 
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [BUG] VM crash during debbuging some code by Through button with Transcript>>show: in deepest inner methods

[Stéphane Ducasse]

thanks a lot denis.
Can you create one or two bug entries in the bug tracking tool and attach your 
code there?

Stef

On May 23, 2010, at 4:18 PM, Denis Kudriashov wrote:

> I found more bad cases with code simulation. And I think any manipulations 
> with context (errors signals, simaphore, ...) not work in simulation mode. 
> Transcript printing failed because of simaphore accessing (for thread safety)
> 
> I create CodeSimulationTests (see attachement) with some tests which not work 
> and which crash VM.
> 
> Maybe this tests not correct. But I hope it helps to indicate and solve issues
> 
> 2010/5/23 Stéphane Ducasse 
> Thanks!
> 
> Stef
> 
> On May 23, 2010, at 11:13 AM, Denis Kudriashov wrote:
> 
> > And If you replace Transcript code with
> >
> > self halt.
> >
> > You will see that debugging with through button does not work. Code 
> > simulation failure raised (but without VM crash)
> >
> > 2010/5/23 Denis Kudriashov 
> > I has Pharo1.0 one click, Windows 7.
> > I attach class ClassWithTranscriptPrinting.
> > see class side method #debug
> >
> >
> >
> >
> >
> > 2010/5/23 Stéphane Ducasse 
> >
> > Hi denis
> >
> > can you report clearly your bug
> >- image
> >- vm
> >- os
> >- scenario
> >
> > I could not compile
> >Transcript>>show:'something'
> >
> > so I do not know how you did it.
> >
> >
> >
> > On May 23, 2010, at 10:11 AM, Denis Kudriashov wrote:
> >
> > > Hello
> > >
> > > Just insert
> > > Transcript>>show:'something'
> > > at any method begin.
> > >
> > > Now debug sender of your method by debugger Through button.
> > >
> > > If no Transcript opened VM will crash!
> > > ___
> > > Pharo-project mailing list
> > > Pharo-project@lists.gforge.inria.fr
> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Rendering fonts on OpenGL

[Stéphane Ducasse]

On May 23, 2010, at 11:04 PM, Igor Stasenko wrote:

> 2010/5/23 Javier Pimás :
>> Hi, may I ask how you are rendering these fonts? You parse the glyphs and
>> then render lines with opengl or use freetype to render to a texture without
>> antialiasing or both?
> 
> Squeak has already a TT font reader, so i just taking the data from there
> and piping to GPU.
> What you see here is freely scalable vector/curve rendering done
> completely on GPU.
> 
>> If you asked me, I'd say I like the method but for
>> fonts they look a bit blury, I'd say too much for the smaller ones.
> 
> I think this is best what you can achieve without hinting / subpixel AA.
> 
>> Also, what are you working on?
>> 
> I once did a GLCanvas,
> and now i want to reiterate and improve it using new callout mechanism
> (NativeBoost),
> and full coverage of OpenGL API, with all extensions available at your 
> disposal.

Igor it would be good it we could have 

NativeBoostRomeCanvas 

if you see what I mean :)

> 
>> Regards,
>> Javier.
>> 
>> 2010/5/23 Igor Stasenko 
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Metacello and SourceTalk ...

[Stéphane Ducasse]

thanks for the update.

Stef

On May 24, 2010, at 2:42 AM, Julian Fitzell wrote:

> The fact that MC2 is still a moving target. Or at least it would be if it was 
> moving. :) More to the point, the early releases had some problems that 
> prompted further redesign and I'd recommend against creating large amounts of 
> date in those versions that will need to be brought forward. In other words, 
> I don't think it's ready for prime time in its current state.
> 
> Julian
> 
> On Mon, May 17, 2010 at 1:34 PM, Geert Claes  wrote:
> 
> What would be the biggest challenges moving to MC2 and a MC2 Repository like
> SourceTalk?
> 
> 
> Mariano Martinez Peck wrote:
> >
> > Hi Geert. I agree it would awesome to have Monticello 2 and SourcTalk for
> > Pharo 1.2. I have not idea the status. I tested once (you can see
> > squeakdbx there) but I have a lot of problems. And the project seems
> > "dead". I mean, I don't think someone is working on it.  That said, it
> > would be great someone to work on it and maybe start to using it by Pharo
> > 1.2
> >
> --
> View this message in context: 
> http://forum.world.st/Metacello-and-SourceTalk-tp2219294p2219517.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [squeak-dev] runSimulated behaviour

[Stéphane Ducasse]

tx!

On May 23, 2010, at 11:24 PM, Eliot Miranda wrote:

> Hi Michael, Michael, Dennis, Hi All,
> 
> I think this is a simple bug in ContextPart >> 
> #tryNamedPrimitiveIn:for:withArgs:, which neglects to flush the method cache 
> for the method and/or selector used to simulate execution of a named 
> primitive.  With the relevant flushCacher calls added I no longer see any of 
> the simulation failures recently experienced (someMethod getSourceFromFile, 
> TimeStamp now).  Please test the attached and let me know how you get on.
> 
> The problem is caused by using the same method to invoke differet primitives 
> in quick succession where, because the method cache is not flushed, the wrong 
> primitive (a previous primitive) is left in the cache and invoked instead of 
> the desired primitive.  In Cog I added a primitive to directly evaluate a 
> named primitive so the problem does not occur.  Adding the two lines marked 
> >> below fixes the problem.  The line "theMethod flushCache" is probably more 
> than we need, but does not harm.
> 
> HTH
> Eliot
> 
> 
> !ContextPart methodsFor: 'private' stamp: 'eem 5/23/2010 14:13'!
> tryNamedPrimitiveIn: aCompiledMethod for: aReceiver withArgs: arguments
>   "Hack. Attempt to execute the named primitive from the given compiled 
> method"
>   | selector theMethod spec |
>   arguments size > 8 ifTrue:[^PrimitiveFailToken].
>   selector := #(
>   tryNamedPrimitive 
>   tryNamedPrimitive: 
>   tryNamedPrimitive:with: 
>   tryNamedPrimitive:with:with: 
>   tryNamedPrimitive:with:with:with:
>   tryNamedPrimitive:with:with:with:with:
>   tryNamedPrimitive:with:with:with:with:with:
>   tryNamedPrimitive:with:with:with:with:with:with:
>   tryNamedPrimitive:with:with:with:with:with:with:with:) at: 
> arguments size+1.
>   theMethod := aReceiver class lookupSelector: selector.
>   theMethod == nil ifTrue:[^PrimitiveFailToken].
>   spec := theMethod literalAt: 1.
>   spec replaceFrom: 1 to: spec size with: (aCompiledMethod literalAt: 1) 
> startingAt: 1.
> >>theMethod flushCache.
> >>selector flushCache.
>   ^aReceiver perform: selector withArguments: arguments! !
> 
> On Thu, May 20, 2010 at 2:55 AM, Michael Haupt  wrote:
> Dear all,
> 
> we're observing some strange behaviour in simulated bytecode execution
> in Squeak (4.1, on Macs).
> 
> Printing this:
> ContextPart runSimulated: [ TimeStamp now ]
> will work once and then reproducibly fail with code simulation errors.
> 
> This works well (also reproducibly):
> ContextPart trace: [ TimeStamp now ]
> 
> Going to more detail, we figured out that simulation reproducibly
> works if things are written to the Transcript every now and then.
> Printing this:
> n:=0. thisContext runSimulated: [ TimeStamp now ] contextAtEachStep: [
> :c | n\\100=0 ifTrue: [ Transcript show: $. ] ]
> works.
> 
> We've tried to just insert some artificial delays (
> milliSeconds asDelay wait) in the block, but that will not
> reproducibly work; it also leads to code simulation errors. So it
> can't be just the time it takes to write to Transcript. Or so we
> believe.
> 
> Does anybody know the reason for this strange behaviour, or where in
> the simulation logic to look?
> 
> Best,
> 
> Michael
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] TORCH: supporting source-code change integration

[Stéphane Ducasse]

Hi veronica

I wanted to use Torch to check inbox published change and I get
TCTrait>>parAuthorAlia

When I tried to look at Slice-hasEqualElement (using Torch build on 11370)

Stef


On May 18, 2010, at 11:00 AM, Veronica Isabel Uquillas Gomez wrote:

> Dear all,
> 
> I would like to announce Torch, a tool for supporting source-code change 
> integration. For now, it offers visualizations of the changes and enhanced 
> change lists.
> Torch can be accessed through Monticello (in the main MC browser, in the 
> repository browser or in the history browser). Selecting a version or slice, 
> you can view the changes with Torch using the contextual menu. 
> Once you open the Torch dashboard, you can access the enhanced change list or 
> a detailed visualization via the contextual menu as well.
> 
> Torch is available on SqueakSource, the repository is named Torch, and you 
> need to load the ConfigurationOfTorch package. 
> It runs in a dev or core image.
> 
> For a dev image.
> - ConfigurationOfTorch loadVersion10
> 
> For a core image.
> 1) Set fonts - described in the attached file.
> 2) ConfigurationOfTorch loadDefault
> 
> I would appreciate comments and feedback!
> 
> Best Regards,
> Verónica Uquillas Gómez
> Vrije University Brussel - SOFT Lab
> University of Lille - RMOD Team
> 
> 
> 
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] [ENH] CompiledMethodTrailer with a different CompiledMethod class

[Igor Stasenko]

Hello,
i added a simple enhancement to make CompilerMethodTrailer to be more
friendly with
CompiledMethod subclasses.
It provides an additional method #createMethod:header:methodClass:
which allows to create a compiled method with other class, than a
CompiledMethod.

Installing it requires 2 separate phases:
phase1  - adds #createMethod:header:methodClass:  method
phase2 - puts this method in use.

if you merge these changesets, you'd will run into a problem, because
filein/fileout utility does not honors the order of changes, how they
should be applied.


On 24 May 2010 13:27, Stéphane Ducasse  wrote:
> and send us the fix for inclusion :)
>
> On May 24, 2010, at 10:54 AM, Igor Stasenko wrote:
>
>> On 24 May 2010 10:31, Hernán Morales Durand  wrote:
>>> Hello
>>>
>>> Just to make a little note. I'm adapting the lightweight classes
>>> package to work with CompilerMethodTrailer. In this method
>>>
>>> CompiledMethodTrailer>>createMethod: numberOfBytesForAllButTrailer
>>> header: headerWord
>>>        | meth |
>>>        encodedData ifNil: [ self encode ].
>>>        meth := CompiledMethod newMethod: numberOfBytesForAllButTrailer +
>>> size header: headerWord.
>>>        ...
>>>
>>> I need to answer a different kind of CompiledMethod, it would be nice
>>> if my own CompiledMethod class could be specified in some way to make
>>> the CompiledMethodTrailer more flexible.
>>
>> Yes, you could add a class parameter, so method will take 3
>>
>> createMethod: numberOfBytesForAllButTrailer header: headerWord class:
>> aMethodClass
>>
>>> Cheers,
>>>
>>> Hernán
>>>
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.


CMT-methodClass-phase1.1.cs
Description: Binary data


CMT-methodclass-phase2.1.cs
Description: Binary data
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

[Igor Stasenko]

On 24 May 2010 13:36, Stéphane Ducasse  wrote:
>
> On May 23, 2010, at 11:04 PM, Igor Stasenko wrote:
>
>> 2010/5/23 Javier Pimás :
>>> Hi, may I ask how you are rendering these fonts? You parse the glyphs and
>>> then render lines with opengl or use freetype to render to a texture without
>>> antialiasing or both?
>>
>> Squeak has already a TT font reader, so i just taking the data from there
>> and piping to GPU.
>> What you see here is freely scalable vector/curve rendering done
>> completely on GPU.
>>
>>> If you asked me, I'd say I like the method but for
>>> fonts they look a bit blury, I'd say too much for the smaller ones.
>>
>> I think this is best what you can achieve without hinting / subpixel AA.
>>
>>> Also, what are you working on?
>>>
>> I once did a GLCanvas,
>> and now i want to reiterate and improve it using new callout mechanism
>> (NativeBoost),
>> and full coverage of OpenGL API, with all extensions available at your 
>> disposal.
>
> Igor it would be good it we could have
>
> NativeBoostRomeCanvas
>
> if you see what I mean :)
>

Yes, i actually want to do that.

I plan to inject the new methods into a Morph

Morph>>fullDrawOnRomeCanvas: aCanvas
Morph>>drawOnRomeCanvas: aCanvas

which should tell the morph to use a different instructions/commands
to perform drawing,
to conform with RomeReferenceCanvas protocol.

I don't want to repeat a balloon canvas protocol.

Then, eventually, when we will have everything ready,
we will be free to use different rendering backend than Balloon canvas.

And its important to make it a non-intrusive.
So, the plan is:

- create a separate package, which will contain extension methods
to Morph and its various subclasses. And maybe some little classes.

- this package !!_should not_!! have any dependencies on Rome , and
should be loaded cleanly,
even if you don't have Rome installed.
It only should conform with Rome canvas protocol for implementing rendering.

This will ensure a backend agnostic nature of new morphic rendering code.

If you think this plan is cool, then lets pick a package name and
repository, and i will start happy coding :)

>>
>>> Regards,
>>>             Javier.
>>>
>>> 2010/5/23 Igor Stasenko 
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

[Igor Stasenko]

Just an idea how to call the package:
Romph-Rendering

if you swizzle first 3 letters, you'll get

Morph-Rendering
:)

On 24 May 2010 14:36, Igor Stasenko  wrote:
> On 24 May 2010 13:36, Stéphane Ducasse  wrote:
>>
>> On May 23, 2010, at 11:04 PM, Igor Stasenko wrote:
>>
>>> 2010/5/23 Javier Pimás :
 Hi, may I ask how you are rendering these fonts? You parse the glyphs and
 then render lines with opengl or use freetype to render to a texture 
 without
 antialiasing or both?
>>>
>>> Squeak has already a TT font reader, so i just taking the data from there
>>> and piping to GPU.
>>> What you see here is freely scalable vector/curve rendering done
>>> completely on GPU.
>>>
 If you asked me, I'd say I like the method but for
 fonts they look a bit blury, I'd say too much for the smaller ones.
>>>
>>> I think this is best what you can achieve without hinting / subpixel AA.
>>>
 Also, what are you working on?

>>> I once did a GLCanvas,
>>> and now i want to reiterate and improve it using new callout mechanism
>>> (NativeBoost),
>>> and full coverage of OpenGL API, with all extensions available at your 
>>> disposal.
>>
>> Igor it would be good it we could have
>>
>> NativeBoostRomeCanvas
>>
>> if you see what I mean :)
>>
>
> Yes, i actually want to do that.
>
> I plan to inject the new methods into a Morph
>
> Morph>>fullDrawOnRomeCanvas: aCanvas
> Morph>>drawOnRomeCanvas: aCanvas
>
> which should tell the morph to use a different instructions/commands
> to perform drawing,
> to conform with RomeReferenceCanvas protocol.
>
> I don't want to repeat a balloon canvas protocol.
>
> Then, eventually, when we will have everything ready,
> we will be free to use different rendering backend than Balloon canvas.
>
> And its important to make it a non-intrusive.
> So, the plan is:
>
> - create a separate package, which will contain extension methods
> to Morph and its various subclasses. And maybe some little classes.
>
> - this package !!_should not_!! have any dependencies on Rome , and
> should be loaded cleanly,
> even if you don't have Rome installed.
> It only should conform with Rome canvas protocol for implementing rendering.
>
> This will ensure a backend agnostic nature of new morphic rendering code.
>
> If you think this plan is cool, then lets pick a package name and
> repository, and i will start happy coding :)
>
>>>
 Regards,
             Javier.

 2010/5/23 Igor Stasenko 
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Need someone to test if NBOpenGL works for you on win32

[Igor Stasenko]

Hi,

i just snapshotted my stuff with various fixes, to make it load
cleanly on pharo and squeak images.

I'd like you to ask to test and load it and tell me if it works for you.

Currently it works only on win32 platform. It could work on Linux, but
i didn't had time to port it yet.

There is no automatic installation procedure right now, so here what
you should try:

- first, you need to have VM with NativeBoost plugin + NativeBoost
loaded into an image
(see http://code.google.com/p/nativeboost/wiki/Installation for instructions)


- then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL
in following order:

- NBOpenGL-Core
- NBOpenGL-Win
- NBOpenGL-TrueType
- NBOpenGL-Display
- NBOpenGL-Morphic

i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were
released recently,
and it seems works ok.
on squeak/trunk it should also work without problems.

Now, if everything went right, then we're ready to run a demo:

GLViewportMorph new "useOwnForm: true;" openInWorld

This thing should render a TrueType glyphs and animating a smooth zoom of it.
Nothing fancy, i just wanna know, if it works for you (and how well).  :)

As you may know, GPU/OpenGL implementations vary depending on vendor
and how old your hardware is,
and i don't have all of it at my disposal.

Ok.. if you got it running, and it renders the glyphs.. there's one thing left:
 - save your image and quit (without closing this morph)
 - start image

it should continue working as if nothing happens.

-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

[Stéphane Ducasse]

> 
> Yes, i actually want to do that.

I'm trying to understand the reason of such a plan?
Is it because like that the clients of existing rendering do not have to be 
touched?

> 
> I plan to inject the new methods into a Morph
> 
> Morph>>fullDrawOnRomeCanvas: aCanvas
> Morph>>drawOnRomeCanvas: aCanvas
> 
> which should tell the morph to use a different instructions/commands
> to perform drawing,
> to conform with RomeReferenceCanvas protocol.
> 
> I don't want to repeat a balloon canvas protocol.

what was wrong with it?

> 
> Then, eventually, when we will have everything ready,
> we will be free to use different rendering backend than Balloon canvas.
> 
> And its important to make it a non-intrusive.
> So, the plan is:
> 
> - create a separate package, which will contain extension methods
> to Morph and its various subclasses. And maybe some little classes.
> 
> - this package !!_should not_!! have any dependencies on Rome , and
> should be loaded cleanly,
> even if you don't have Rome installed.
> It only should conform with Rome canvas protocol for implementing rendering.
> 
> This will ensure a backend agnostic nature of new morphic rendering code.
> 
> If you think this plan is cool, then lets pick a package name and
> repository, and i will start happy coding :)
> 
>>> 
 Regards,
 Javier.
 
 2010/5/23 Igor Stasenko 
>>> 
>>> 
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>> 
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

[Igor Stasenko]

On 24 May 2010 17:22, Stéphane Ducasse  wrote:
>>
>> Yes, i actually want to do that.
>
> I'm trying to understand the reason of such a plan?
> Is it because like that the clients of existing rendering do not have to be 
> touched?
>
To make things minimally dependent on implementation.

>>
>> I plan to inject the new methods into a Morph
>>
>> Morph>>fullDrawOnRomeCanvas: aCanvas
>> Morph>>drawOnRomeCanvas: aCanvas
>>
>> which should tell the morph to use a different instructions/commands
>> to perform drawing,
>> to conform with RomeReferenceCanvas protocol.
>>
>> I don't want to repeat a balloon canvas protocol.
>
> what was wrong with it?
>

I did this once for GLCanvas, and don't want to repeat that again :)
The Balloon canvas and its uses is too damn focused on blitting, which makes
it too hard to provide a backend which doing most things on GPU.
If you want to go into vector world, you should keep a distance from
any blitting operations.
Simply because they are ineffective, CPU hungry and don't scale well.

>>
>> Then, eventually, when we will have everything ready,
>> we will be free to use different rendering backend than Balloon canvas.
>>
>> And its important to make it a non-intrusive.
>> So, the plan is:
>>
>> - create a separate package, which will contain extension methods
>> to Morph and its various subclasses. And maybe some little classes.
>>
>> - this package !!_should not_!! have any dependencies on Rome , and
>> should be loaded cleanly,
>> even if you don't have Rome installed.
>> It only should conform with Rome canvas protocol for implementing rendering.
>>
>> This will ensure a backend agnostic nature of new morphic rendering code.
>>
>> If you think this plan is cool, then lets pick a package name and
>> repository, and i will start happy coding :)
>>

> Regards,
>             Javier.
>
> 2010/5/23 Igor Stasenko 


 --
 Best regards,
 Igor Stasenko AKA sig.

 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [BUG] VM crash during debbuging some code by Through button with Transcript>>show: in deepest inner methods

[Stéphane Ducasse]

http://code.google.com/p/pharo/issues/detail?id=2469



Stef


On May 23, 2010, at 4:18 PM, Denis Kudriashov wrote:

> I found more bad cases with code simulation. And I think any manipulations 
> with context (errors signals, simaphore, ...) not work in simulation mode. 
> Transcript printing failed because of simaphore accessing (for thread safety)
> 
> I create CodeSimulationTests (see attachement) with some tests which not work 
> and which crash VM.
> 
> Maybe this tests not correct. But I hope it helps to indicate and solve issues
> 
> 2010/5/23 Stéphane Ducasse 
> Thanks!
> 
> Stef
> 
> On May 23, 2010, at 11:13 AM, Denis Kudriashov wrote:
> 
> > And If you replace Transcript code with
> >
> > self halt.
> >
> > You will see that debugging with through button does not work. Code 
> > simulation failure raised (but without VM crash)
> >
> > 2010/5/23 Denis Kudriashov 
> > I has Pharo1.0 one click, Windows 7.
> > I attach class ClassWithTranscriptPrinting.
> > see class side method #debug
> >
> >
> >
> >
> >
> > 2010/5/23 Stéphane Ducasse 
> >
> > Hi denis
> >
> > can you report clearly your bug
> >- image
> >- vm
> >- os
> >- scenario
> >
> > I could not compile
> >Transcript>>show:'something'
> >
> > so I do not know how you did it.
> >
> >
> >
> > On May 23, 2010, at 10:11 AM, Denis Kudriashov wrote:
> >
> > > Hello
> > >
> > > Just insert
> > > Transcript>>show:'something'
> > > at any method begin.
> > >
> > > Now debug sender of your method by debugger Through button.
> > >
> > > If no Transcript opened VM will crash!
> > > ___
> > > Pharo-project mailing list
> > > Pharo-project@lists.gforge.inria.fr
> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] About the Pharo Issue tracker

[Mariano Martinez Peck]

On Mon, May 24, 2010 at 10:37 AM, Adrian Lienhard  wrote:

> Hi Guille and Carla,
>
> Yes for certain actions you need to be a committer. I added you both.
> Please feel free to help maintaining the issue tracker :)
>
>
I don't like this setting. I rather pharo users (not necessary committers)
be able to directly tag. Google code doesn't allow us that or it is just our
configuration ?

Cheers

Mariano



> If an issue is not clear and lacking information, please add a note and/or
> ask in the mailing list. If an issue cannot be reproduced and the creator
> does not provide details, we just switch to "won't fix".
>
> Another area that needs work is to identify which issues should still be
> tackled for 1.1. In the tracker we currently have over 200 issues for
> milestone 1.1. Many are of the form "we should do X" and are not critical
> for the 1.1 release. Others may be show stopper bugs that need to be fixed.
> Identifying the latter is important.
>
> Cheers,
> Adrian
>
> On May 24, 2010, at 07:10 , Carla F. Griggio wrote:
>
> > Hmm... if I wanted to change the status of an issue to Fixed (for
> example),
> > I think I'm not able to do that either. Are you?
> >
> > Should we be commiters to be able to do these things?
> >
> > On Mon, May 24, 2010 at 2:04 AM, Carla F. Griggio
> > wrote:
> >
> >> Welcome, Guille :) It was very cool to have you in the Sprint :)
> >>
> >> I notice that if I try to post a new issue, I can't categorize it. Who
> is
> >> able to categorize issues?
> >>
> >> Carla.
> >>
> >> 2010/5/23 Guillermo Polito 
> >>
> >>> Hi!
> >>>
> >>> First I may introduce myself.  My name is Guillermo Polito and I'm from
> >>> Argentina.  I've been using Pharo for several months with some
> colleagues
> >>> that are already here to teach OOP in the UTN university, and i've been
> >>> suscribed to this mailing list for some time.  But it's my first mail
> here
> >>> :P.
> >>>
> >>> I participated yesterday in the Pharo Sprint in Argentina and there I
> had
> >>> my first look at the issue tracker.  And well, it seemed to me to be a
> >>> little messy.  There are lots of issues that aren't properly explained,
> some
> >>> of them are duplicated, and they are not well organized.
> >>> It would be nice to use the labels googlecode provides to give them
> some
> >>> categorization, so we can browse them in a more intelligent way.  Maybe
> we
> >>> can split the issues in "modules" (like Collection issues, Compiler
> Issues,
> >>> Closures Issues, Networking Issues...) or something like that.  That
> will
> >>> help in avoiding duplications and looking for issues to solve (because
> I can
> >>> look for issues in the modules I know the most).
> >>>
> >>> At the moment I will stay looking for issues i can fix or commenting
> the
> >>> ones that lacks information :).
> >>>
> >>> Regards,
> >>> Guille
> >>>
> >>>
> >>>
> >>> ___
> >>> Pharo-project mailing list
> >>> Pharo-project@lists.gforge.inria.fr
> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>>
> >>
> >>
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Problem with Demo mode [WAS] Re: [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

[Mariano Martinez Peck]

On Mon, May 24, 2010 at 11:56 AM, Serge Stinckwich <
serge.stinckw...@gmail.com> wrote:

> When i switch to demo mode, method selector in System Browser are no
> more bold in the bottom pane.
>

I didn't understand you. Could you please attach both screenshots: how it
should be and how is it ?

Alain do you know about this ?

Cheers





>
> 2010/5/21 Mariano Martinez Peck :
> > Hi Pharaoers. I am pleased to announce the first Pharo 1.1 beta based on
> > PharoCore-1.1-11367-Beta. It is the first time we build a Pharo 1.1 dev
> > image with PharoCore 1.1 so the image may be not 100% stable. However, we
> > think it is good to release it so that people can start to test it, load
> > their own packages, adapt them, etc. We would like to receive feedback
> about
> > it. It (yet) has failing and error tests.
> >
> > The main changes with Pharo 1.0 is that of course, it is based on a
> > PharoCore 1.1 with all that it means. We started to write down some of
> the
> > actions done in PharoCore 1.1. The list so far can be found here:
> > http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotOne
> > Of course, for the stable releae of Pharo 1.1 we will do a clear list in
> the
> > website as we did for 1.0.
> >
> > Regarding the included packages in 1.1 we added ScriptManager (a tool to
> > manage and persist workspaces), ProfStefBrowser, ArchiveViewer,
> > MethodWrappers and ObjectMetaTools (which includes things like
> > ProtocolCatcher, ObjectTracer, ObjectViewer, etc).
> >
> > Another difference is the font. In Pharo 1.0 we used TrueType fonts by
> > default. In Pharo 1.1 we use StrikeFonts (no need of TrueType plugin,
> > netiher to have the fonts). However, of course, you can disable
> StrikeFonts
> > and put TrueType like in 1.0.
> >
> > That's all. We would really appreciate you use it, test it, report
> issues,
> > provide fixes, etc. It is important also that you start to use your own
> > packages/applications. There have been several changes in 1.1 that may
> > require change in your code.
> >
> > Ahh if you want to create the image yourself, check as usually the
> > installScript.st file to see how to do it. Actually, you can just take a
> > PharoCore-1.1-11367-Beta image and evaluate (the same procedure as 1.0):
> >
> > Gofer new
> > squeaksource: 'MetacelloRepository';
> > package: 'ConfigurationOfPharo';
> > load.
> >
> > ((Smalltalk at: #ConfigurationOfPharo) project version:
> '1.1-beta1.10517')
> > load.
> >
> > Here is the link to the image:
> >
> >
> https://gforge.inria.fr/frs/download.php/27025/Pharo-1.1-11367-Betadev10.05.1.zip
> >
> > Cheers
> >
> > Mariano
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
>
>
> --
> Serge Stinckwich
> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
> Every DSL ends up being Smalltalk
> http://doesnotunderstand.org/
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ClassTestCase

[Mariano Martinez Peck]

2010/5/24 Levente Uzonyi 

> On Sun, 23 May 2010, Mariano Abel Coca wrote:
>
>  There are few now, but it was done yesterday in a few hours. We will keep
>> adding new tests to that suites, so suggestions are welcome :).
>>
>> Actually there are only 3 tests there:
>>
>> - One that checks that all the methods in the image are categorized
>> - One that checks that never redefine #doesNotUnderstand: without
>> redefining
>> #respondsTo: and vice versa.
>> - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~=
>> nil, etc. as suggested in issue 1594 (Actually, after reading this issue
>> is
>> that we started with this idea).
>>
>
> "x = nil", "nil = x", "x ~= nil", "nil ~= x", "x ~~ nil" and "nil ~~ x" are
> usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and
> "== nil" is not less readable if you know what #== means (but that's basic
> smalltalk knowledge, so it's fair to assume that everybody knows it).
>
> Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same
> reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible).
>
> So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should
> be used whenever possible.
>
> (*) Benchmarks on my slow machine:
>
> ((1 to: 10) collect: [ :run |
>[ 1 to: 1000 do: [ :i | 1 == nil ] ] timeToRun ]) average
> asFloat. "===> 386.6"
>
> ((1 to: 10) collect: [ :run |
>[ 1 to: 1000 do: [ :i | 1 isNil ] ] timeToRun ]) average
> asFloat. "===> 586.4"
>
> ((1 to: 10) collect: [ :run |
>[ 1 to: 1000 do: [ :i | ] ] timeToRun ]) average asFloat. "===>
> 282.3"
>
> 586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908"
>
> ((1 to: 10) collect: [ :run |
>[ 1 to: 1000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average
> asFloat. "===> 393.6"
>
> ((1 to: 10) collect: [ :run |
>[ 1 to: 1000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ])
> average asFloat. "===> 585.2"
>
> 585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584"
>
>

I ask completely in ignorance, but can't we do some Compiler/Parser teaks so
that allow us to write the more readable and nice but then it convert them
to the fast ones?





>
> Levente
>
>
>> Cheers,
>>
>> Mariano.
>>
>>
>> On Sun, May 23, 2010 at 4:53 AM, Stéphane Ducasse <
>> stephane.duca...@inria.fr
>>
>>> wrote:
>>>
>>
>>  Sounds exciting can you tell us a bit more?
>>>
>>> On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote:
>>>
>>>  If anyone want, can take a look at:

 http://www.squeaksource.com/CodeQualityTests
 http://www.squeaksource.com/CodeStandardsTests

 And run the tests before committing the next version of their packages.

 We will try to help to pass the tests as soon as possible.

 Cheers,

 Mariano.


 On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza <

>>> patchi...@gmail.com> wrote:
>>>
 We're working on it, making small changes and creating code standards
 tests and code quality tests.

 It would be great to have a way of tracking the results of these tests
 in a distant future and make them mandatory before integrate new
 things into the image.

 Francisco

 On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse
  wrote:

> What I was thinking mariano is that we could move one class at a time
>
 in classTests and make the tests green.
>>>
 This way we do not have red tests and still make progress
> Stef
>
>
> On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote:
>
>  It is a must. We have to got all the tests in green. But actually that
>>
> isn't tested.
>>>

>> I'll make the tests, I'll fix them, and then I'll send the whole
>>
> changes to merge in the baseline.
>>>

>> Cheers,
>>
>> Mariano.
>>
>>
>> On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <
>>
> stephane.duca...@inria.fr> wrote:
>>>
 the key point is that we would like to avoid to have red tests all the
>>
> time
>>>
 so fixing the as yet unclassified should be done before.
>>
>>
>> BTW Does anybody use
>>   BadEqualer
>>   HashTester
>>   PrototypeTester
>>
>> because so far I do not see anybody user of them.
>> They look like experiment code to me.
>>
>> Stef
>>
>> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
>>
>>  Hi, I want to make global the checks included in ClassTestCase, and
>>>
>> remove it. That is because actually it's only being tested for it's
>>> subclasses. And also, it's declaring that a subclass will be a class test
>>> instead of just a test, but no one of it's subclasses actually test the
>>> class, but the instances, therefore is a TestCase, not a ClassTestCase.
>>> See
>>> TimespanTest as an example.
>>>

>>> What Im saying is that I'm trying to force a run of a suit of Code
>>>

Re: [Pharo-project] About the Pharo Issue tracker

[Adrian Lienhard]

I couldn't figure how to change that. So it does not seem possible.

Adrian

On May 24, 2010, at 16:52 , Mariano Martinez Peck wrote:

> On Mon, May 24, 2010 at 10:37 AM, Adrian Lienhard  wrote:
> 
>> Hi Guille and Carla,
>> 
>> Yes for certain actions you need to be a committer. I added you both.
>> Please feel free to help maintaining the issue tracker :)
>> 
>> 
> I don't like this setting. I rather pharo users (not necessary committers)
> be able to directly tag. Google code doesn't allow us that or it is just our
> configuration ?
> 
> Cheers
> 
> Mariano
> 
> 
> 
>> If an issue is not clear and lacking information, please add a note and/or
>> ask in the mailing list. If an issue cannot be reproduced and the creator
>> does not provide details, we just switch to "won't fix".
>> 
>> Another area that needs work is to identify which issues should still be
>> tackled for 1.1. In the tracker we currently have over 200 issues for
>> milestone 1.1. Many are of the form "we should do X" and are not critical
>> for the 1.1 release. Others may be show stopper bugs that need to be fixed.
>> Identifying the latter is important.
>> 
>> Cheers,
>> Adrian
>> 
>> On May 24, 2010, at 07:10 , Carla F. Griggio wrote:
>> 
>>> Hmm... if I wanted to change the status of an issue to Fixed (for
>> example),
>>> I think I'm not able to do that either. Are you?
>>> 
>>> Should we be commiters to be able to do these things?
>>> 
>>> On Mon, May 24, 2010 at 2:04 AM, Carla F. Griggio
>>> wrote:
>>> 
 Welcome, Guille :) It was very cool to have you in the Sprint :)
 
 I notice that if I try to post a new issue, I can't categorize it. Who
>> is
 able to categorize issues?
 
 Carla.
 
 2010/5/23 Guillermo Polito 
 
> Hi!
> 
> First I may introduce myself.  My name is Guillermo Polito and I'm from
> Argentina.  I've been using Pharo for several months with some
>> colleagues
> that are already here to teach OOP in the UTN university, and i've been
> suscribed to this mailing list for some time.  But it's my first mail
>> here
> :P.
> 
> I participated yesterday in the Pharo Sprint in Argentina and there I
>> had
> my first look at the issue tracker.  And well, it seemed to me to be a
> little messy.  There are lots of issues that aren't properly explained,
>> some
> of them are duplicated, and they are not well organized.
> It would be nice to use the labels googlecode provides to give them
>> some
> categorization, so we can browse them in a more intelligent way.  Maybe
>> we
> can split the issues in "modules" (like Collection issues, Compiler
>> Issues,
> Closures Issues, Networking Issues...) or something like that.  That
>> will
> help in avoiding duplications and looking for issues to solve (because
>> I can
> look for issues in the modules I know the most).
> 
> At the moment I will stay looking for issues i can fix or commenting
>> the
> ones that lacks information :).
> 
> Regards,
> Guille
> 
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
 
 
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

[Stéphane Ducasse]

>> 
> 
> I did this once for GLCanvas, and don't want to repeat that again :)
> The Balloon canvas and its uses is too damn focused on blitting, which makes
> it too hard to provide a backend which doing most things on GPU.
> If you want to go into vector world, you should keep a distance from
> any blitting operations.
> Simply because they are ineffective, CPU hungry and don't scale well.

In that case what would be the next generation API (call it Athens) 
that would make ROME getting better and that your code would propose an API 
compliant
interface? You could that way have a class that implements the Athens interface 
and
the system gets improved and you would not depend on Athens.
 Because we should not neglect that without common API change and adaptation 
is and will be a pain.

Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] FFI Documentation

[Hernán Morales Durand]

2010/5/20 Sean P. DeNigris :
>
>        
>                Function specification
>                        - should be the first line
>                        - enclosed in angle brackets: < > containing:
>                                1. Calling Convention, either apicall: (Pascal 
> convention) or cdecl: (C
> convention)
>                                        - Mac - use either one
>                                        - Unix - use cdecl
>                                        - Windows - use apical

In Windows the cdecl calling convention may be used when you want your
code interfacing the external library to be portable to other
platforms.

> Questions:
> * why would you want to build the FFI plugin yourself?

To provide better failure handlers. Most of the time writing an
interface is lost decoding the type of failure description when
calling external functions, specially the conversion of types from
Smalltalk to C (coercion).

> * why would a field description have three elements?

I think this is the case when you have in C

char myArray [8]

then you would write in the fields description:

(myArray 'char' 8)

Cheers,

Hernán

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ClassTestCase

[Levente Uzonyi]

On Mon, 24 May 2010, Mariano Martinez Peck wrote:


2010/5/24 Levente Uzonyi 


On Sun, 23 May 2010, Mariano Abel Coca wrote:

 There are few now, but it was done yesterday in a few hours. We will keep

adding new tests to that suites, so suggestions are welcome :).

Actually there are only 3 tests there:

- One that checks that all the methods in the image are categorized
- One that checks that never redefine #doesNotUnderstand: without
redefining
#respondsTo: and vice versa.
- And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~=
nil, etc. as suggested in issue 1594 (Actually, after reading this issue
is
that we started with this idea).



"x = nil", "nil = x", "x ~= nil", "nil ~= x", "x ~~ nil" and "nil ~~ x" are
usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and
"== nil" is not less readable if you know what #== means (but that's basic
smalltalk knowledge, so it's fair to assume that everybody knows it).

Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same
reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible).

So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should
be used whenever possible.

(*) Benchmarks on my slow machine:

((1 to: 10) collect: [ :run |
   [ 1 to: 1000 do: [ :i | 1 == nil ] ] timeToRun ]) average
asFloat. "===> 386.6"

((1 to: 10) collect: [ :run |
   [ 1 to: 1000 do: [ :i | 1 isNil ] ] timeToRun ]) average
asFloat. "===> 586.4"

((1 to: 10) collect: [ :run |
   [ 1 to: 1000 do: [ :i | ] ] timeToRun ]) average asFloat. "===>
282.3"

586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908"

((1 to: 10) collect: [ :run |
   [ 1 to: 1000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average
asFloat. "===> 393.6"

((1 to: 10) collect: [ :run |
   [ 1 to: 1000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ])
average asFloat. "===> 585.2"

585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584"




I ask completely in ignorance, but can't we do some Compiler/Parser teaks so
that allow us to write the more readable and nice but then it convert them
to the fast ones?


I think "== nil" is just as readable as "isNil" and "isNil ifTrue:" is 
less readable than "ifNil:". So I don't see what you're suggesting.



Levente









Levente



Cheers,

Mariano.


On Sun, May 23, 2010 at 4:53 AM, Stéphane Ducasse <
stephane.duca...@inria.fr


wrote:



 Sounds exciting can you tell us a bit more?


On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote:

 If anyone want, can take a look at:


http://www.squeaksource.com/CodeQualityTests
http://www.squeaksource.com/CodeStandardsTests

And run the tests before committing the next version of their packages.

We will try to help to pass the tests as soon as possible.

Cheers,

Mariano.


On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza <


patchi...@gmail.com> wrote:


We're working on it, making small changes and creating code standards
tests and code quality tests.

It would be great to have a way of tracking the results of these tests
in a distant future and make them mandatory before integrate new
things into the image.

Francisco

On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse
 wrote:


What I was thinking mariano is that we could move one class at a time


in classTests and make the tests green.



This way we do not have red tests and still make progress

Stef


On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote:

 It is a must. We have to got all the tests in green. But actually that



isn't tested.





I'll make the tests, I'll fix them, and then I'll send the whole


changes to merge in the baseline.





Cheers,

Mariano.


On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <


stephane.duca...@inria.fr> wrote:



the key point is that we would like to avoid to have red tests all the



time



so fixing the as yet unclassified should be done before.



BTW Does anybody use
  BadEqualer
  HashTester
  PrototypeTester

because so far I do not see anybody user of them.
They look like experiment code to me.

Stef

On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:

 Hi, I want to make global the checks included in ClassTestCase, and



remove it. That is because actually it's only being tested for it's

subclasses. And also, it's declaring that a subclass will be a class test
instead of just a test, but no one of it's subclasses actually test the
class, but the instances, therefore is a TestCase, not a ClassTestCase.
See
TimespanTest as an example.




What Im saying is that I'm trying to force a run of a suit of Code


Standards and Code Quality tests before sending something to merge to

a
baseline of a project.




What do you think? Are you agree with that?

Cheers,

Mariano.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




_

Re: [Pharo-project] ClassTestCase

[Stéphane Ducasse]

Mariano

Some of the combinations are inlined automatically by the compiler as levente 
explained.
The problems is that without a rule checking that for me, I cannot remember 
which one are optimized :)
Now the cost is that if you have more inlined expressions, then the decompiler 
gets more complex.
So having a good and flexible decompiler would be a way to favor optimization. 
For now the list of levente and a slow machine 

"So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: 
should be used whenever possible."
is the one to use


Now 

> 
> 2010/5/24 Levente Uzonyi 
> On Sun, 23 May 2010, Mariano Abel Coca wrote:
> 
> There are few now, but it was done yesterday in a few hours. We will keep
> adding new tests to that suites, so suggestions are welcome :).
> 
> Actually there are only 3 tests there:
> 
> - One that checks that all the methods in the image are categorized
> - One that checks that never redefine #doesNotUnderstand: without redefining
> #respondsTo: and vice versa.
> - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~=
> nil, etc. as suggested in issue 1594 (Actually, after reading this issue is
> that we started with this idea).
> 
> "x = nil", "nil = x", "x ~= nil", "nil ~= x", "x ~~ nil" and "nil ~~ x" are 
> usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and
> "== nil" is not less readable if you know what #== means (but that's basic 
> smalltalk knowledge, so it's fair to assume that everybody knows it).
> 
> Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same 
> reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible).
> 
> So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be 
> used whenever possible.
> 
> (*) Benchmarks on my slow machine:
> 
> ((1 to: 10) collect: [ :run |
>[ 1 to: 1000 do: [ :i | 1 == nil ] ] timeToRun ]) average asFloat. 
> "===> 386.6"
> 
> ((1 to: 10) collect: [ :run |
>[ 1 to: 1000 do: [ :i | 1 isNil ] ] timeToRun ]) average asFloat. 
> "===> 586.4"
> 
> ((1 to: 10) collect: [ :run |
>[ 1 to: 1000 do: [ :i | ] ] timeToRun ]) average asFloat. "===> 
> 282.3"
> 
> 586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908"
> 
> ((1 to: 10) collect: [ :run |
>[ 1 to: 1000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average 
> asFloat. "===> 393.6"
> 
> ((1 to: 10) collect: [ :run |
>[ 1 to: 1000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ]) 
> average asFloat. "===> 585.2"
> 
> 585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584"
> 
> 
> 
> I ask completely in ignorance, but can't we do some Compiler/Parser teaks so 
> that allow us to write the more readable and nice but then it  convert them 
> to the fast ones?
> 
> 
> 
>  
> 
> Levente
> 
> 
> Cheers,
> 
> Mariano.
> 
> 
> On Sun, May 23, 2010 at 4:53 AM, Stéphane Ducasse  wrote:
> 
> Sounds exciting can you tell us a bit more?
> 
> On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote:
> 
> If anyone want, can take a look at:
> 
> http://www.squeaksource.com/CodeQualityTests
> http://www.squeaksource.com/CodeStandardsTests
> 
> And run the tests before committing the next version of their packages.
> 
> We will try to help to pass the tests as soon as possible.
> 
> Cheers,
> 
> Mariano.
> 
> 
> On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza <
> patchi...@gmail.com> wrote:
> We're working on it, making small changes and creating code standards
> tests and code quality tests.
> 
> It would be great to have a way of tracking the results of these tests
> in a distant future and make them mandatory before integrate new
> things into the image.
> 
> Francisco
> 
> On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse
>  wrote:
> What I was thinking mariano is that we could move one class at a time
> in classTests and make the tests green.
> This way we do not have red tests and still make progress
> Stef
> 
> 
> On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote:
> 
> It is a must. We have to got all the tests in green. But actually that
> isn't tested.
> 
> I'll make the tests, I'll fix them, and then I'll send the whole
> changes to merge in the baseline.
> 
> Cheers,
> 
> Mariano.
> 
> 
> On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <
> stephane.duca...@inria.fr> wrote:
> the key point is that we would like to avoid to have red tests all the
> time
> so fixing the as yet unclassified should be done before.
> 
> 
> BTW Does anybody use
>   BadEqualer
>   HashTester
>   PrototypeTester
> 
> because so far I do not see anybody user of them.
> They look like experiment code to me.
> 
> Stef
> 
> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
> 
> Hi, I want to make global the checks included in ClassTestCase, and
> remove it. That is because actually it's only being tested for it's
> subclasses. And also, it's declaring that a subclass will be a class test
> instead of just a test, but no one of it

Re: [Pharo-project] Problem with Demo mode [WAS] Re: [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

[Alain Plantec]

Le 24/05/2010 16:53, Mariano Martinez Peck a écrit :



On Mon, May 24, 2010 at 11:56 AM, Serge Stinckwich 
mailto:serge.stinckw...@gmail.com>> wrote:


When i switch to demo mode, method selector in System Browser are no
more bold in the bottom pane.


I didn't understand you. Could you please attach both screenshots: how 
it should be and how is it ?


Alain do you know about this ?

Hi,
Strange, I've tested and all is ok here.
could you try with

StandardFonts setDemoFonts


Alain


Cheers



___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

[Igor Stasenko]

On 24 May 2010 18:33, Stéphane Ducasse  wrote:
>>>
>>
>> I did this once for GLCanvas, and don't want to repeat that again :)
>> The Balloon canvas and its uses is too damn focused on blitting, which makes
>> it too hard to provide a backend which doing most things on GPU.
>> If you want to go into vector world, you should keep a distance from
>> any blitting operations.
>> Simply because they are ineffective, CPU hungry and don't scale well.
>
> In that case what would be the next generation API (call it Athens)
> that would make ROME getting better and that your code would propose an API 
> compliant
> interface? You could that way have a class that implements the Athens 
> interface and
> the system gets improved and you would not depend on Athens.
>  Because we should not neglect that without common API change and adaptation
> is and will be a pain.
>
Yes. But i want to stress, what meaning we are putting into 'API'.

API is protocols, not classes.
So, a code which renders something using API, should use only messages
sent to a canvas object.
The difference could be illustrated by following:

a)
drawOn: aCanvas

  path := RomePath new.
  path moveTo: .. lineTo:... close.
  aCanvas strokePath: path

b)
drawOn: aCanvas

  path := aCanvas newPath.
  path moveTo: .. lineTo:... close.
  aCanvas strokePath: path

In case a) you are introducing a dependency on a concrete path
implementation(RomePath).
in case b) you asking a canvas to provide a path instance, which
conforms to a path protocol.

Here lies the main difference, which either gives you a freedom of
choice, or otherwise makes your code inflexible.
That's what i mean by no dependecy. In case b), a rendering backend is
free to use own data structures
to optimally reify a path(s), while in case a) you forcing a canvas to
have an intimate knowledge about RomePath
- a concrete implementation, which may not fit best for canvas and
hence it will waste cycles converting a path
representation into more appropriate form, in order to render it.

That's why, if we follow path b), then morphic rendering could be
completely autonomous,
and do not depend on concrete Rome API implementation.
And enforcing it from a very starting, will make sure that we won't
introduce unnecessary
dependencies and inflexibility.

> Stef
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ClassTestCase

[Lukas Renggli]

> For now the list of levente and a slow machine
>
>        "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: 
> should be used whenever possible."
> is the one to use

Please read my comments on the issue tracker.

For *any practical* example it doesn't matter what to use speed wise:

 1 = nil ifTrue: [ ]
 2 == nil ifTrue: [ ]
 3 isNil ifTrue: [ ]
 4 ifNil: [ ]

Personally I find 3 the most readable. 1 and 3 are the only practical
ones if you use OODBs, because they are not shortcut by the compiler.

I only use 4 for lazy initializers, it makes a good pattern. The use
of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable
if you don't care about compatibility with other Smalltalk dialects.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [squeak-dev] Need someone to test if NBOpenGL works for you on win32

[Hernán Morales Durand]

Hi Igor,

I'm testing your work in Win32. Following instructions in this page
http://code.google.com/p/nativeboost/wiki/Installation when evaluating

NBInstaller install

in PharoCore1.1ALPHA #11368 I receive: "You need to enable an
underscore selectors in preferences first". I see no preference listed
in the preferences browsers and didn't found the
#allowUnderscoreSelectors for enabling this setting. Any idea?

Cheers,

Hernán

2010/5/24 Igor Stasenko :
> Hi,
>
> i just snapshotted my stuff with various fixes, to make it load
> cleanly on pharo and squeak images.
>
> I'd like you to ask to test and load it and tell me if it works for you.
>
> Currently it works only on win32 platform. It could work on Linux, but
> i didn't had time to port it yet.
>
> There is no automatic installation procedure right now, so here what
> you should try:
>
> - first, you need to have VM with NativeBoost plugin + NativeBoost
> loaded into an image
> (see http://code.google.com/p/nativeboost/wiki/Installation for instructions)
>
>
> - then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL
> in following order:
>
> - NBOpenGL-Core
> - NBOpenGL-Win
> - NBOpenGL-TrueType
> - NBOpenGL-Display
> - NBOpenGL-Morphic
>
> i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were
> released recently,
> and it seems works ok.
> on squeak/trunk it should also work without problems.
>
> Now, if everything went right, then we're ready to run a demo:
>
> GLViewportMorph new "useOwnForm: true;" openInWorld
>
> This thing should render a TrueType glyphs and animating a smooth zoom of it.
> Nothing fancy, i just wanna know, if it works for you (and how well).  :)
>
> As you may know, GPU/OpenGL implementations vary depending on vendor
> and how old your hardware is,
> and i don't have all of it at my disposal.
>
> Ok.. if you got it running, and it renders the glyphs.. there's one thing 
> left:
>  - save your image and quit (without closing this morph)
>  - start image
>
> it should continue working as if nothing happens.
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] #methodClass: answering different in Pharo and Squeak

[Hernán Morales Durand]

Hi,

If anyone is using the result of CompiledMethod #methodClass:, in
Pharo and Squeak is answering a different object. In Pharo
(PharoCore1.1ALPHA #11367) returns an Association and in Squeak 4.1
the CompiledMethod instance which is the historical behavior. This
would lead to two different tests where should be the same.
Cheers,

Hernán

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Cannot add halos to selected morph in 1.1 #11368

[Hernán Morales Durand]

If you evaluate

BorderedMorph new borderColor: Color red; borderWidth: 10; openInWorld.

in PharoCore1.1ALPHA #11368 in Win32 and if you want to add halos to
this morph to remove it easily, the halos are added to the world
PasteUpMorph and you would need to figure a way to remove it
programatically.
Cheers,

Hernán

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Cannot add halos to selected morph in 1.1 #11368

[Lukas Renggli]

Alt+Shift+Click displays the halos on that particular morph on my system.

Lukas

On 24 May 2010 19:01, Hernán Morales Durand  wrote:
> If you evaluate
>
> BorderedMorph new borderColor: Color red; borderWidth: 10; openInWorld.
>
> in PharoCore1.1ALPHA #11368 in Win32 and if you want to add halos to
> this morph to remove it easily, the halos are added to the world
> PasteUpMorph and you would need to figure a way to remove it
> programatically.
> Cheers,
>
> Hernán
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



-- 
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Cannot add halos to selected morph in 1.1 #11368

[Hernán Morales Durand]

Thanks, I was very used to the right click :)

Hernán

2010/5/24 Lukas Renggli :
> Alt+Shift+Click displays the halos on that particular morph on my system.
>
> Lukas
>
> On 24 May 2010 19:01, Hernán Morales Durand  wrote:
>> If you evaluate
>>
>> BorderedMorph new borderColor: Color red; borderWidth: 10; openInWorld.
>>
>> in PharoCore1.1ALPHA #11368 in Win32 and if you want to add halos to
>> this morph to remove it easily, the halos are added to the world
>> PasteUpMorph and you would need to figure a way to remove it
>> programatically.
>> Cheers,
>>
>> Hernán
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [squeak-dev] Need someone to test if NBOpenGL works for you on win32

[Igor Stasenko]

On 24 May 2010 19:21, Hernán Morales Durand  wrote:
> Hi Igor,
>
> I'm testing your work in Win32. Following instructions in this page
> http://code.google.com/p/nativeboost/wiki/Installation when evaluating
>
> NBInstaller install
>
> in PharoCore1.1ALPHA #11368 I receive: "You need to enable an
> underscore selectors in preferences first". I see no preference listed
> in the preferences browsers and didn't found the
> #allowUnderscoreSelectors for enabling this setting. Any idea?
>

Strange. Here the piece of code, which tests that underscores supported:

[ Compiler evaluate: '| t_a | ' ] on: Error do: [:ex |
  self inform: 'You need to enable an underscore selectors in
preferences first' .
^ self ].

It works fine in pharocore-11367, and actually this message was mainly
for squeak/trunk
where you can control the underscore by preference.
In Pharo it should work out of the box.


> Cheers,
>
> Hernán
>
> 2010/5/24 Igor Stasenko :
>> Hi,
>>
>> i just snapshotted my stuff with various fixes, to make it load
>> cleanly on pharo and squeak images.
>>
>> I'd like you to ask to test and load it and tell me if it works for you.
>>
>> Currently it works only on win32 platform. It could work on Linux, but
>> i didn't had time to port it yet.
>>
>> There is no automatic installation procedure right now, so here what
>> you should try:
>>
>> - first, you need to have VM with NativeBoost plugin + NativeBoost
>> loaded into an image
>> (see http://code.google.com/p/nativeboost/wiki/Installation for instructions)
>>
>>
>> - then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL
>> in following order:
>>
>> - NBOpenGL-Core
>> - NBOpenGL-Win
>> - NBOpenGL-TrueType
>> - NBOpenGL-Display
>> - NBOpenGL-Morphic
>>
>> i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were
>> released recently,
>> and it seems works ok.
>> on squeak/trunk it should also work without problems.
>>
>> Now, if everything went right, then we're ready to run a demo:
>>
>> GLViewportMorph new "useOwnForm: true;" openInWorld
>>
>> This thing should render a TrueType glyphs and animating a smooth zoom of it.
>> Nothing fancy, i just wanna know, if it works for you (and how well).  :)
>>
>> As you may know, GPU/OpenGL implementations vary depending on vendor
>> and how old your hardware is,
>> and i don't have all of it at my disposal.
>>
>> Ok.. if you got it running, and it renders the glyphs.. there's one thing 
>> left:
>>  - save your image and quit (without closing this morph)
>>  - start image
>>
>> it should continue working as if nothing happens.
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

[Stéphane Ducasse]

Guess what is my choice :)

 
> Yes. But i want to stress, what meaning we are putting into 'API'.

the real one :)
> 
> API is protocols, not classes.


> So, a code which renders something using API, should use only messages
> sent to a canvas object.
> The difference could be illustrated by following:
> 
> a)
> drawOn: aCanvas
> 
>  path := RomePath new.
>  path moveTo: .. lineTo:... close.
>  aCanvas strokePath: path
> 
> b)
> drawOn: aCanvas
> 
>  path := aCanvas newPath.
>  path moveTo: .. lineTo:... close.
>  aCanvas strokePath: path
> 
> In case a) you are introducing a dependency on a concrete path
> implementation(RomePath).
> in case b) you asking a canvas to provide a path instance, which
> conforms to a path protocol.
> 
> Here lies the main difference, which either gives you a freedom of
> choice, or otherwise makes your code inflexible.
> That's what i mean by no dependecy.

I understood it :)

> In case b), a rendering backend is
> free to use own data structures
> to optimally reify a path(s), while in case a) you forcing a canvas to
> have an intimate knowledge about RomePath
> - a concrete implementation, which may not fit best for canvas and
> hence it will waste cycles converting a path
> representation into more appropriate form, in order to render it.
> 
> That's why, if we follow path b), then morphic rendering could be
> completely autonomous,
> and do not depend on concrete Rome API implementation.
> And enforcing it from a very starting, will make sure that we won't
> introduce unnecessary
> dependencies and inflexibility.

so this is why it would be good to have a concrete scenario to stress and 
validate
the Athens new canvas
I would really like to see how the one of Morphic 30 will fit into it too.

So let us start like that:
- design your API with flexibility in mind + ROME from the point of you 
of Canvas method
- give feedback about athens inflexibility
- we update it 
- we iterate 
the goal should be that at the end we can get really fast a different back-end.
With a bit of chance we will d the same with Morphic30 and we will have a cool 
system.

Stef


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ClassTestCase

[Stéphane Ducasse]

Lukas 

what would be good is to have a specific pharo smallLint that we could run to 
check.
My brain is too small for all these details.

Stef

On May 24, 2010, at 6:18 PM, Lukas Renggli wrote:

>> For now the list of levente and a slow machine
>> 
>>"So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: 
>> should be used whenever possible."
>> is the one to use
> 
> Please read my comments on the issue tracker.
> 
> For *any practical* example it doesn't matter what to use speed wise:
> 
> 1 = nil ifTrue: [ ]
> 2 == nil ifTrue: [ ]
> 3 isNil ifTrue: [ ]
> 4 ifNil: [ ]
> 
> Personally I find 3 the most readable. 1 and 3 are the only practical
> ones if you use OODBs, because they are not shortcut by the compiler.
> 
> I only use 4 for lazy initializers, it makes a good pattern. The use
> of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable
> if you don't care about compatibility with other Smalltalk dialects.
> 
> Lukas
> 
> -- 
> Lukas Renggli
> www.lukas-renggli.ch
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] PhD thesis potentially in Smalltalk

[Stéphane Ducasse]

Hi guys

This team has a Phd position which can be done in Smalltalk. Christophe Dony is 
an old smalltalk fan in the south of france.
He supervised the PhD of Luc fabresse who is working with Noury (and working on 
Socket for Pharo right now).
If you are interested please contact chouki directly.
Stef


Begin forwarded message:

> From: Chouki TIBERMACINE 
> Date: May 15, 2010 11:59:01 PM GMT+02:00
> To: Stéphane Ducasse 
> Cc: Christophe Dony , Bouraqadi Noury , 
> Fabresse Luc 
> Subject: Re: [Lmo-conference] Thèse en ingénierie des composants logiciels à 
> Montpellier
> 
> Voilà la version anglaise.
> 
> Chouki.
> 
> ---
> TITLE: A Reflective Component-Oriented Programming Language
> 
> SUPERVISORS: Chouki TIBERMACINE (tiberma...@lirmm.fr) and Christophe DONY 
> (d...@lirmm.fr)
> 
> FUNDING: French Government Fellowship (~1500 euros gross salary per month)
> 
> PLACE: LIRMM, CNRS and Montpellier University (South of France)
> 
> SUBJECT:
> 
> Research on the modeling and implementation of applications by assembling 
> components is growing up more and more. Component-based development allows 
> the definition of independent software modules which are put in libraries, 
> available on catalog, and assemblable as deployment and runtime units.
> 
> In our research lab, we developed a voluntarily simple component-oriented 
> programming language (SCL), which allowed an original and innovative 
> integration of the concepts of component, port, interface, connector and 
> aspect (see [1]).
> 
> Component languages are used now in modeling environments in association with 
> architecture description languages. We would like to study, on the basis of 
> SCL, a reflective solution mixing a programming and an architecture 
> description language, which allows:
> - to link entities of conceptual reuse (component descriptors) with units of 
> integration (component instances),
> - via a reflective architecture and an API of meta-programming, allowing 
> introspection and intercession, to describe with the same language 
> architectures, constraints on these architectures (non-functional constraints 
> as specified in [2]), and model transformations.
> 
> Two SCL prototypes have been implemented in Smalltalk and Ruby. A prototype 
> of the new language can be developed in JAVA or another language, and 
> integrated with the Eclipse plugin of modeling component-based application 
> (CLACS).
> 
> [1] Luc Fabresse, Christophe Dony, and Marianne Huchard.
> Foundations of a simple and unified component-oriented language.
> Journal of Computer Languages, Systems and Structures, 34(2-3):130-149, 
> Elsevier 2008.
> 
> [2] Chouki Tibermacine, Régis Fleurquin, and Salah Sadou.
> A family of languages for architecture constraint specification.
> Journal of Systems and Software 83(5):815-831, Elsevier 2010.
> ---
> 
> Le 15/05/10 22:52, Stéphane Ducasse a écrit :
>> tu as une version en anglais?
>> 
>> Stef
>> 
>> On May 15, 2010, at 10:43 PM, Chouki TIBERMACINE wrote:
>> 
>>   
>>> C'est ok pour l'orienter sur notre sujet.
>>> Merci d'avance :-) .
>>> 
>>> Chouki.
>>> 
>>> Le 15/05/10 22:13, Stéphane Ducasse a écrit :
>>> 
 chouki
 
 je peux le contacter en lui disant que notre bourse a ete supprimee et que 
 votre sujet peut l'interesser.
 J'attends ton ok.
 
 Stef
 
 
   
> Oui, bien sûr, avec plaisir  ;-) .
> 
> Chouki.
> 
> Le 15/05/10 21:51, Stéphane Ducasse a écrit :
> 
> 
>> chouki
>> 
>> si vous etes vraiment pret a avoir un mec qui parait bon en langage et 
>> qui est interesse je peux vous mettre en contact
>> avec un des etudiants tchec dont nous avons recu un cv pour une these 
>> langage (mais que pour des raisons de strategie inria nous
>> avons du abandonnee). Nous l'aurions surement embauche si la these ne 
>> devait pas etre allouee sur un autre sujet.
>> 
>> Stef
>> 
>> On May 15, 2010, at 9:14 PM, Chouki TIBERMACINE wrote:
>> 
>> 
>> 
>>   
>>> Merci Stéphane pour ces précisions.
>>> 
>>> En fait, on propose d'utiliser Java pour la future implémentation pour 
>>> la simple raison qu'il est très difficile de nos jours de trouver un 
>>> étudiant qui soit bon et qui voudrait bien travailler sur Smalltalk.
>>> Si vous avez à Lille un bon étudiant à nous recommander, on est 
>>> preneur. On le fera travailler sur Smalltalk (et Pharo) ;-) .
>>> 
>>> On va regarder de près CLIC. Merci pour l'info :-) .
>>> 
>>> Chouki.
>>> 
>>> Le 15/05/10 17:04, Stéphane Ducasse a écrit :
>>> 
>>> 
>>> 
 quel est la pertinence d'utiliser Java?
 conquerir le monde au travers d'eclipse? Bonne chance. :)
 
 peut etre que vous devriez contacter noury car il a un modele a 
 composant
 CLIC
 
 Nous on s'amuse bien avec
http://

[Pharo-project] Concurrency in Pharo?

[Andrei Stebakov]

I've been really impressed with what Seaside and Pier were capable of and
really wanted to start my new web project with Pharo.
I learned that Pharo (and most other open source ST implementations) only
use green threads, having no ability to use a multi-core CPU systems.
For those of you with experience building mid to heavy load web sites, how
do you expect them to scale up on using just one core?
Is Pharo a right tool for that?
Maybe Pharo (Squeak) has something up its sleeve to handle this, but my
heart really sank when I learned about this issue...

Thank you,
Andrei
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Cross-fork Metacello configurations

[Dale Henrichs]

Miguel Enrique Cobá Martinez wrote:


I don't dislike Squeak usage but changing a emerging technology that is
being used in a given way and that appears to be working (I've done the
Magma configuration and I tested it worked on Squeak and Pharo) but this
new Squeak usage of Metacello really discourages to try to keep the
Magma for other distros than Pharo. It really is a gratuitous change and
I don't really have the time to sync two ways to use the same
technology.




Miguel,

I'm not going to defend how the Squeak folks are using Metacello, but I 
will say that they have a slightly different use case and they are 
currently exploring the possibilities in support of that use case.


For the moment I would take a wait and see attitude, while continuing to 
maintain your cross-platform configurations.


Think of your users...Magma is used on both Squeak and Pharo and a cross 
-platform configuration _is_ the best way for you to publish the 
information...


In the absolutely worst case scenario (i.e., impossible to load the 
Magma config because of class name conflicts) it will be possible for 
your users to unload the "configuration package" and use your config, 
then reload the "configuration package".


Hopefully, the Squeak folks will settle on an approach that is 
compatible with cross-platform configs without requiring drastic measures...


Dale


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Concurrency in Pharo?

[Mariano Martinez Peck]

This is a good question. I don't have experience by myself but I can tell
you what I think it is usually done:

1) For one CPU:

If the image don't need to be saved (no need of in image persistence) you
can take the same VM and load N number of images running at the same .image.
You can even not use .changes and .sources. Each image in different port.
Then, you have in front of them a web server (Apache or friends) and you do
load balance. The only thing you should take care with Seaside is to have
AFFINITY -> the same client should go always to the same image while a
conversation occurs. This is just a web-server setting.

2) For multiple core, I am thinking, maybe I am wrong, you may be able to
load different vms. For assigning each VM to a particular CPU. I don't know
windows, but in Linux (maybe I am wrong) I think you can specify where to
exclusively run a process. The, for each VM you do 1).
Do you know if this can work?

Finally, there are different VM that aim not necessary multiple CPU but
similar:

- COG VM
- Hydra

I cc'ed may developers of them so that they can help you.

Cheers

Mariano


2010/5/24 Andrei Stebakov 

> I've been really impressed with what Seaside and Pier were capable of and
> really wanted to start my new web project with Pharo.
> I learned that Pharo (and most other open source ST implementations) only
> use green threads, having no ability to use a multi-core CPU systems.
> For those of you with experience building mid to heavy load web sites, how
> do you expect them to scale up on using just one core?
> Is Pharo a right tool for that?
> Maybe Pharo (Squeak) has something up its sleeve to handle this, but my
> heart really sank when I learned about this issue...
>
> Thank you,
> Andrei
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Concurrency in Pharo?

[Dale Henrichs]

Andrei,

GemStone/S and GLASS provides a free for commercial use multi-vm 
environment that provides "image-based persistence". With an annual 
license you can use multiple vms across multiple cores.


A number of folks using GemStone develop in Pharo and deploy in 
GemStone, so that mode of operation is realistic...


Dale

Mariano Martinez Peck wrote:

This is a good question. I don't have experience by myself but I can tell you 
what I think it is usually done:

1) For one CPU:

If the image don't need to be saved (no need of in image persistence) you can take 
the same VM and load N number of images running at the same .image. You can even 
not use .changes and .sources. Each image in different port. Then, you have in 
front of them a web server (Apache or friends) and you do load balance. The only 
thing you should take care with Seaside is to have AFFINITY -> the same client 
should go always to the same image while a conversation occurs. This is just a 
web-server setting.

2) For multiple core, I am thinking, maybe I am wrong, you may be able to load 
different vms. For assigning each VM to a particular CPU. I don't know windows, 
but in Linux (maybe I am wrong) I think you can specify where to exclusively 
run a process. The, for each VM you do 1).
Do you know if this can work?

Finally, there are different VM that aim not necessary multiple CPU but similar:

- COG VM
- Hydra

I cc'ed may developers of them so that they can help you.

Cheers

Mariano


2010/5/24 Andrei Stebakov mailto:lisper...@gmail.com>>
I've been really impressed with what Seaside and Pier were capable of and 
really wanted to start my new web project with Pharo.
I learned that Pharo (and most other open source ST implementations) only use 
green threads, having no ability to use a multi-core CPU systems.
For those of you with experience building mid to heavy load web sites, how do 
you expect them to scale up on using just one core?
Is Pharo a right tool for that?
Maybe Pharo (Squeak) has something up its sleeve to handle this, but my heart 
really sank when I learned about this issue...

Thank you,
Andrei

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project






___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Concurrency in Pharo?

[Lukas Renggli]

> I've been really impressed with what Seaside and Pier were capable of and
> really wanted to start my new web project with Pharo.

GemStone/S runs Seaside and Pier and scales across multiple CPUs
infinitely, if scalability with Pharo should be a problem.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

[Igor Stasenko]

On 24 May 2010 21:16, Stéphane Ducasse  wrote:
> Guess what is my choice :)
>
>
>> Yes. But i want to stress, what meaning we are putting into 'API'.
>
> the real one :)
>>
>> API is protocols, not classes.
>
>
>> So, a code which renders something using API, should use only messages
>> sent to a canvas object.
>> The difference could be illustrated by following:
>>
>> a)
>> drawOn: aCanvas
>>
>>  path := RomePath new.
>>  path moveTo: .. lineTo:... close.
>>  aCanvas strokePath: path
>>
>> b)
>> drawOn: aCanvas
>>
>>  path := aCanvas newPath.
>>  path moveTo: .. lineTo:... close.
>>  aCanvas strokePath: path
>>
>> In case a) you are introducing a dependency on a concrete path
>> implementation(RomePath).
>> in case b) you asking a canvas to provide a path instance, which
>> conforms to a path protocol.
>>
>> Here lies the main difference, which either gives you a freedom of
>> choice, or otherwise makes your code inflexible.
>> That's what i mean by no dependecy.
>
> I understood it :)
>
>> In case b), a rendering backend is
>> free to use own data structures
>> to optimally reify a path(s), while in case a) you forcing a canvas to
>> have an intimate knowledge about RomePath
>> - a concrete implementation, which may not fit best for canvas and
>> hence it will waste cycles converting a path
>> representation into more appropriate form, in order to render it.
>>
>> That's why, if we follow path b), then morphic rendering could be
>> completely autonomous,
>> and do not depend on concrete Rome API implementation.
>> And enforcing it from a very starting, will make sure that we won't
>> introduce unnecessary
>> dependencies and inflexibility.
>
> so this is why it would be good to have a concrete scenario to stress and 
> validate
> the Athens new canvas
> I would really like to see how the one of Morphic 30 will fit into it too.
>
Me too!

> So let us start like that:
>        - design your API with flexibility in mind + ROME from the point of 
> you of Canvas method
>        - give feedback about athens inflexibility
>        - we update it
>        - we iterate
> the goal should be that at the end we can get really fast a different 
> back-end.
> With a bit of chance we will d the same with Morphic30 and we will have a 
> cool system.
>

Ok. Let me start.
Rome/Athens adds variouls extension methods to classes which are
involved with graphics.
Here is one of them:

GradientFillStyle>>installOnRomePluginCanvas: aCanvas
| colorStops i |
colorStops := WordArray new: colorRamp size * 3.
i := 0.
colorRamp do: [:stop |
colorStops at: (i:=i+1) put: (stop key * 65536.0) rounded.
colorStops at: (i:=i+1) put: stop value privateRGB.
colorStops at: (i:=i+1) put: stop value privateAlpha].
radial == true
ifTrue: [
aCanvas primFillRadialGradientOriginX: origin x asFloat
y: origin y asFloat
directionX: direction x asFloat
y: direction y asFloat
normalX: self normal x asFloat
y: self normal y asFloat
colorStops: colorStops]
ifFalse: [
aCanvas primFillLinearGradientOriginX: origin x asFloat
y: origin y asFloat
directionX: direction x asFloat
y: direction y asFloat
colorStops: colorStops]

Good:
 - a conversion method is context sensitive (it takes a canvas as an argument)
Bad:
- this conversion method will work only for Rome plugin and nothing else.

This means, that if i'd want to use different canvas, i will need to
add another method
which will perform a conversion.

But this can be avoided, if we provide a generic canvas method to
create a gradient fills.
Then this method could be renamed to #installOnRomeCanvas:
and implementation will consist of messages, sent to canvas to build a
gradient fill.

Another example:

asRomeFill , asRomeFont

- this is bad.
Its not a context-sensitive. And therefore , an implementation of
these methods assumes that it will provide
the most suitable conversion of fill or font for Rome backend.
But depending on backend, it may not be the case!
So, all methods like this, should always use a canvas as argument and
talk back to canvas
to perform a conversion.

> Stef
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Concurrency in Pharo?

[Stéphane Ducasse]

you know dabbledb, cmsbox and other are all based on squeak/pharo so you heart 
does not have to sink yet :)


Stef

On May 24, 2010, at 8:36 PM, Andrei Stebakov wrote:

> I've been really impressed with what Seaside and Pier were capable of and 
> really wanted to start my new web project with Pharo.
> I learned that Pharo (and most other open source ST implementations) only use 
> green threads, having no ability to use a multi-core CPU systems. 
> For those of you with experience building mid to heavy load web sites, how do 
> you expect them to scale up on using just one core?
> Is Pharo a right tool for that?
> Maybe Pharo (Squeak) has something up its sleeve to handle this, but my heart 
> really sank when I learned about this issue...
> 
> Thank you,
> Andrei
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

[Stéphane Ducasse]

> Ok. Let me start.

Excellent I want to learn.
And I will ask cyrille to read all that. 
The first things is that we should get Rome working then we fix the api.


> Rome/Athens adds variouls extension methods to classes which are
> involved with graphics.
> Here is one of them:
> 
> GradientFillStyle>>installOnRomePluginCanvas: aCanvas
>   | colorStops i |
>   colorStops := WordArray new: colorRamp size * 3.
>   i := 0.
>   colorRamp do: [:stop |
>   colorStops at: (i:=i+1) put: (stop key * 65536.0) rounded.
>   colorStops at: (i:=i+1) put: stop value privateRGB.
>   colorStops at: (i:=i+1) put: stop value privateAlpha].
>   radial == true
>   ifTrue: [
>   aCanvas primFillRadialGradientOriginX: origin x asFloat
>   y: origin y asFloat
>   directionX: direction x asFloat
>   y: direction y asFloat
>   normalX: self normal x asFloat
>   y: self normal y asFloat
>   colorStops: colorStops]
>   ifFalse: [
>   aCanvas primFillLinearGradientOriginX: origin x asFloat
>   y: origin y asFloat
>   directionX: direction x asFloat
>   y: direction y asFloat
>   colorStops: colorStops]
> 
> Good:
> - a conversion method is context sensitive (it takes a canvas as an argument)
> Bad:
> - this conversion method will work only for Rome plugin and nothing else.

how to you see that?


> This means, that if i'd want to use different canvas, i will need to
> add another method
> which will perform a conversion.

you lost me there. But I ;m sure that you will explain it to me :)


> But this can be avoided, if we provide a generic canvas method to
> create a gradient fills.
> Then this method could be renamed to #installOnRomeCanvas:
> and implementation will consist of messages, sent to canvas to build a
> gradient fill.

do you have a sketch that I follow the example 100% 

> Another example:
> 
> asRomeFill , asRomeFont
> 
> - this is bad.
> Its not a context-sensitive. And therefore , an implementation of
> these methods assumes that it will provide
> the most suitable conversion of fill or font for Rome backend.
> But depending on backend, it may not be the case!
> So, all methods like this, should always use a canvas as argument and
> talk back to canvas
> to perform a conversion.

I see we need a factory and the canvas will play this role.

Stef
> 
>> Stef
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] cant remove accept: method

[Sean Allen]

Pharo 1.0

I have a class that has a method accept: that is no longer used.

When I go to remove it, I get the message:

Possible call to accept: in  Browse?

If you do no, it doesn't remove the method.
If you do yes, you can only browse, not remove.

How can I remove the method short of filing out the class, removing the method
and filing the class back in?

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] I need another pair of eyes to look at: super look in debugger

[stephane ducasse]

http://code.google.com/p/pharo/issues/detail?id=2446

Stef


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] cant remove accept: method

[Sean Allen]

Sorry.

I see that just plain old 'remove method' works, just not from refactoring menu.


On Mon, May 24, 2010 at 3:27 PM, Sean Allen  wrote:
> Pharo 1.0
>
> I have a class that has a method accept: that is no longer used.
>
> When I go to remove it, I get the message:
>
> Possible call to accept: in  Browse?
>
> If you do no, it doesn't remove the method.
> If you do yes, you can only browse, not remove.
>
> How can I remove the method short of filing out the class, removing the method
> and filing the class back in?
>

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

[Igor Stasenko]

On 24 May 2010 22:11, Stéphane Ducasse  wrote:
>> Ok. Let me start.
>
> Excellent I want to learn.
> And I will ask cyrille to read all that.
> The first things is that we should get Rome working then we fix the api.
>
>
>> Rome/Athens adds variouls extension methods to classes which are
>> involved with graphics.
>> Here is one of them:
>>
>> GradientFillStyle>>installOnRomePluginCanvas: aCanvas
>>       | colorStops i |
>>       colorStops := WordArray new: colorRamp size * 3.
>>       i := 0.
>>       colorRamp do: [:stop |
>>               colorStops at: (i:=i+1) put: (stop key * 65536.0) rounded.
>>               colorStops at: (i:=i+1) put: stop value privateRGB.
>>               colorStops at: (i:=i+1) put: stop value privateAlpha].
>>       radial == true
>>               ifTrue: [
>>                       aCanvas primFillRadialGradientOriginX: origin x asFloat
>>                               y: origin y asFloat
>>                               directionX: direction x asFloat
>>                               y: direction y asFloat
>>                               normalX: self normal x asFloat
>>                               y: self normal y asFloat
>>                               colorStops: colorStops]
>>               ifFalse: [
>>                       aCanvas primFillLinearGradientOriginX: origin x asFloat
>>                               y: origin y asFloat
>>                               directionX: direction x asFloat
>>                               y: direction y asFloat
>>                               colorStops: colorStops]
>>
>> Good:
>> - a conversion method is context sensitive (it takes a canvas as an argument)
>> Bad:
>> - this conversion method will work only for Rome plugin and nothing else.
>
> how to you see that?
>

Well, consider this:

   colorRamp do: [:stop |
  colorStops at: (i:=i+1) put: (stop key * 65536.0) rounded.
  colorStops at: (i:=i+1) put: stop value privateRGB.
  colorStops at: (i:=i+1) put: stop value privateAlpha].

most likely, this will be inappropriate for anything else than RomePlugin.
While, of course each kind of canvas could implement own
#primFillLinearGradientOriginX: y:directionX: y: colorStops:
except that it should not be a prim, and then it will waste time converting
color stops again - into a form, which fits best for its own needs.
So, why using 2 conversions, where 1 is enough? :)

In same way, #asFloat may be not necessary, because canvas could
accept integers as well as floats,
so converting everything to floats is just a waste of time.

>
>> This means, that if i'd want to use different canvas, i will need to
>> add another method
>> which will perform a conversion.
>
> you lost me there. But I ;m sure that you will explain it to me :)
>

I meant that i would need to add the
GradientFillStyle>>installOnRomeGLCanvas: aCanvas
instead of reusing the code.

>
>> But this can be avoided, if we provide a generic canvas method to
>> create a gradient fills.
>> Then this method could be renamed to #installOnRomeCanvas:
>> and implementation will consist of messages, sent to canvas to build a
>> gradient fill.
>
> do you have a sketch that I follow the example 100%
>

GradientFillStyle>>installOnRomeCanvas: aCanvas
  ^ aCanvas cacheAt: self ifAbsentPut: [ aCanvas gradientFill: #linear
origin: ... colors: ... ]

and generally, a persistent resources (or ones which may change, but rarely)
could use a following pattern:

Something>>installOnRomeCanvas: aCanvas
  self isChanged ifTrue: [ aCanvas invalidateCache: self ].
  ^ aCanvas cacheAt: self ifAbsentPut: [ aCanvas createSomething: ... ]

Then, after heating-up, it will run at maximum efficiency by using a cached
(and already converted resources) instead of performing conversions each time.

>> Another example:
>>
>> asRomeFill , asRomeFont
>>
>> - this is bad.
>> Its not a context-sensitive. And therefore , an implementation of
>> these methods assumes that it will provide
>> the most suitable conversion of fill or font for Rome backend.
>> But depending on backend, it may not be the case!
>> So, all methods like this, should always use a canvas as argument and
>> talk back to canvas
>> to perform a conversion.
>
> I see we need a factory and the canvas will play this role.
>

Yes.


> Stef
>>
>>> Stef
>>>
>>>
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.

Re: [Pharo-project] Concurrency in Pharo?

[Igor Stasenko]

On 24 May 2010 21:47, Mariano Martinez Peck  wrote:
> This is a good question. I don't have experience by myself but I can tell
> you what I think it is usually done:
>
> 1) For one CPU:
>
> If the image don't need to be saved (no need of in image persistence) you
> can take the same VM and load N number of images running at the same .image.
> You can even not use .changes and .sources. Each image in different port.
> Then, you have in front of them a web server (Apache or friends) and you do
> load balance. The only thing you should take care with Seaside is to have
> AFFINITY -> the same client should go always to the same image while a
> conversation occurs. This is just a web-server setting.
>
> 2) For multiple core, I am thinking, maybe I am wrong, you may be able to
> load different vms. For assigning each VM to a particular CPU. I don't know
> windows, but in Linux (maybe I am wrong) I think you can specify where to
> exclusively run a process. The, for each VM you do 1).
> Do you know if this can work?
>

3) write a good code, so it could handle things well without need of
so much horsepower :)

> Finally, there are different VM that aim not necessary multiple CPU but
> similar:
>
> - COG VM
> - Hydra
>
> I cc'ed may developers of them so that they can help you.
>
> Cheers
>
> Mariano
>
>
> 2010/5/24 Andrei Stebakov 
>>
>> I've been really impressed with what Seaside and Pier were capable of and
>> really wanted to start my new web project with Pharo.
>> I learned that Pharo (and most other open source ST implementations) only
>> use green threads, having no ability to use a multi-core CPU systems.
>> For those of you with experience building mid to heavy load web sites, how
>> do you expect them to scale up on using just one core?
>> Is Pharo a right tool for that?
>> Maybe Pharo (Squeak) has something up its sleeve to handle this, but my
>> heart really sank when I learned about this issue...
>> Thank you,
>> Andrei
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>



-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ClassTestCase

[Levente Uzonyi]

On Mon, 24 May 2010, Lukas Renggli wrote:


For now the list of levente and a slow machine

       "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should 
be used whenever possible."
is the one to use


Please read my comments on the issue tracker.

For *any practical* example it doesn't matter what to use speed wise:


That's not true. Most of the time it doesn't matter, but when these 
checks/conditional statements are in tight loops they can make a huge 
difference. Core packages have some good code examples and those have to 
be fast, but not cross-dialect. I'm sure other smalltalks are implemented 
this way.




1 = nil ifTrue: [ ]
2 == nil ifTrue: [ ]
3 isNil ifTrue: [ ]
4 ifNil: [ ]


IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the 
moment, so that should be preferred in core packages.
2 is cross-dialect and it's probably the fastest in all dialects, so if I 
were writing cross-dialect code then I'd probably use that.
3 looks nice and #isNil is inlined in some dialects (AFAIK), but it's 
"slow" in Squeak/Pharo.
1 just looks bad, I can't imagine an OODB that doesn't map it's "null 
object" directly to nil, otherwise #= will be asymmetric:

null = nil -> true
nil = null -> false

Btw I hope we will have an inlining JIT soon which can decrease/eliminate 
these performance differences.



Levente



Personally I find 3 the most readable. 1 and 3 are the only practical
ones if you use OODBs, because they are not shortcut by the compiler.

I only use 4 for lazy initializers, it makes a good pattern. The use
of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable
if you don't care about compatibility with other Smalltalk dialects.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ClassTestCase

[Lukas Renggli]

> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the
> moment, so that should be preferred in core packages.

It should not be preferred or changes unless you can prove a real
performance benefit. I still haven't seen a single realistic benchmark
with real code (from Pharo, Seaside, Pier, ...) where you can measure
a real difference between these 4 variants.


> 1 just looks bad, I can't imagine an OODB that doesn't map it's "null
> object" directly to nil, otherwise #= will be asymmetric:
> null = nil -> true
> nil = null -> false

That's not the problem. The problem is when you have proxy objects
then all these inlined an shortcut variants fail miserably.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] [update 1.1] #11371

[Stéphane Ducasse]

11371
-
- Issue 1281: Button in TestRunner to fileout the test results. Thanks Laurent. 
- Issue 2468: Better method trailer method creation. Part One. Thanks Igor.
- Issue 2406: MovieMorph should be removed from the core. Thanks Alain.
- Issue 2467: AlllocationTest#testOutOfMemorySignal fails. Thanks Laurent
- Issue 2331: Reuse test unload - Now there is an SUnitUnloader. Thanks 
Guillermo.

Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Concurrency in Pharo?

[Adrian Lienhard]

Hi Andrei,

1) is what most do (at least what we do at netstyle.ch for apps that can have 
higher loads). The following blog post is a nice writeup from Ramon Leon 
describing how to implement such a system: 

http://onsmalltalk.com/scaling-seaside-more-advanced-load-balancing-and-publishing

HTH,
Adrian

On May 24, 2010, at 20:47 , Mariano Martinez Peck wrote:

> This is a good question. I don't have experience by myself but I can tell
> you what I think it is usually done:
> 
> 1) For one CPU:
> 
> If the image don't need to be saved (no need of in image persistence) you
> can take the same VM and load N number of images running at the same .image.
> You can even not use .changes and .sources. Each image in different port.
> Then, you have in front of them a web server (Apache or friends) and you do
> load balance. The only thing you should take care with Seaside is to have
> AFFINITY -> the same client should go always to the same image while a
> conversation occurs. This is just a web-server setting.
> 
> 2) For multiple core, I am thinking, maybe I am wrong, you may be able to
> load different vms. For assigning each VM to a particular CPU. I don't know
> windows, but in Linux (maybe I am wrong) I think you can specify where to
> exclusively run a process. The, for each VM you do 1).
> Do you know if this can work?
> 
> Finally, there are different VM that aim not necessary multiple CPU but
> similar:
> 
> - COG VM
> - Hydra
> 
> I cc'ed may developers of them so that they can help you.
> 
> Cheers
> 
> Mariano
> 
> 
> 2010/5/24 Andrei Stebakov 
> 
>> I've been really impressed with what Seaside and Pier were capable of and
>> really wanted to start my new web project with Pharo.
>> I learned that Pharo (and most other open source ST implementations) only
>> use green threads, having no ability to use a multi-core CPU systems.
>> For those of you with experience building mid to heavy load web sites, how
>> do you expect them to scale up on using just one core?
>> Is Pharo a right tool for that?
>> Maybe Pharo (Squeak) has something up its sleeve to handle this, but my
>> heart really sank when I learned about this issue...
>> 
>> Thank you,
>> Andrei
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ClassTestCase

[Levente Uzonyi]

On Mon, 24 May 2010, Lukas Renggli wrote:


IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the
moment, so that should be preferred in core packages.


It should not be preferred or changes unless you can prove a real
performance benefit. I still haven't seen a single realistic benchmark
with real code (from Pharo, Seaside, Pier, ...) where you can measure
a real difference between these 4 variants.


Well, just replace all uses of == nil and #ifNil:, etc with isNil and 
isNil ifTrue: etc. Then get some benchmarks which you accept as realistic and 
run them in both images.


For now I can only show a microbenchmark that I evaluated in 
PharoCore-1.1-11367 on my slow machine:


Original:
(1 to: 5) collect: [ :run |
FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file |
[ [ file next isNil ] whileFalse ] timeToRun ] ]
#(9928 9733 9753 9703 9711)

Then I replaced the #isNil send to == nil:

(1 to: 5) collect: [ :run |
FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file |
[ [ file next == nil ] whileFalse ] timeToRun ] ]
#(9214 9301 9419 9273 9285)

Not bad 4.8% faster. Then I replaced the line
character1 isNil ifTrue: [^ nil].
with
character1 ifNil: [^ nil].
in UTF8TextConverter >> #nextFromStream:.

(1 to: 5) collect: [ :run |
FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file |
[ [ file next == nil ] whileFalse ] timeToRun ] ]
#(8947 8779 8814 8845 8810).
5% faster than the previous.

Removing 2 #isNil sends from the tight loop gave ~10% speedup.


Levente





1 just looks bad, I can't imagine an OODB that doesn't map it's "null
object" directly to nil, otherwise #= will be asymmetric:
null = nil -> true
nil = null -> false


That's not the problem. The problem is when you have proxy objects
then all these inlined an shortcut variants fail miserably.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ClassTestCase

[Stéphane Ducasse]

5 % is cool in such scenario.
Thanks levente. I believe in small speed ups and you show that.

Stef

On May 24, 2010, at 10:47 PM, Levente Uzonyi wrote:

> On Mon, 24 May 2010, Lukas Renggli wrote:
> 
>>> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the
>>> moment, so that should be preferred in core packages.
>> 
>> It should not be preferred or changes unless you can prove a real
>> performance benefit. I still haven't seen a single realistic benchmark
>> with real code (from Pharo, Seaside, Pier, ...) where you can measure
>> a real difference between these 4 variants.
> 
> Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil 
> ifTrue: etc. Then get some benchmarks which you accept as realistic and run 
> them in both images.
> 
> For now I can only show a microbenchmark that I evaluated in 
> PharoCore-1.1-11367 on my slow machine:
> 
> Original:
> (1 to: 5) collect: [ :run |
>   FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file |
>   [ [ file next isNil ] whileFalse ] timeToRun ] ]
> #(9928 9733 9753 9703 9711)
> 
> Then I replaced the #isNil send to == nil:
> 
> (1 to: 5) collect: [ :run |
>   FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file |
>   [ [ file next == nil ] whileFalse ] timeToRun ] ]
> #(9214 9301 9419 9273 9285)
> 
> Not bad 4.8% faster. Then I replaced the line
> character1 isNil ifTrue: [^ nil].
> with
> character1 ifNil: [^ nil].
> in UTF8TextConverter >> #nextFromStream:.
> 
> (1 to: 5) collect: [ :run |
>   FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file |
>   [ [ file next == nil ] whileFalse ] timeToRun ] ]
> #(8947 8779 8814 8845 8810).
> 5% faster than the previous.
> 
> Removing 2 #isNil sends from the tight loop gave ~10% speedup.
> 
> 
> Levente
> 
>> 
>> 
>>> 1 just looks bad, I can't imagine an OODB that doesn't map it's "null
>>> object" directly to nil, otherwise #= will be asymmetric:
>>> null = nil -> true
>>> nil = null -> false
>> 
>> That's not the problem. The problem is when you have proxy objects
>> then all these inlined an shortcut variants fail miserably.
>> 
>> Lukas
>> 
>> -- 
>> Lukas Renggli
>> www.lukas-renggli.ch
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Old configuration options

[nullPointer]

I did probe the new developer image verion 1.1, and don´t see options like
"easySelection", very useful when works continoously with morphs. That
option is lost or is usable in another place?

Thanks for the answers.
-- 
View this message in context: 
http://forum.world.st/Old-configuration-options-tp2229221p2229221.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Old configuration options

[Mariano Martinez Peck]

On Mon, May 24, 2010 at 11:25 PM, nullPointer  wrote:

>
> I did probe the new developer image verion 1.1, and don´t see options like
> "easySelection", very useful when works continoously with morphs. That
> option is lost or is usable in another place?
>
>
See issue: http://code.google.com/p/pharo/issues/detail?id=1568

I cc'ed Alain.

Cheers

Mariano



> Thanks for the answers.
> --
> View this message in context:
> http://forum.world.st/Old-configuration-options-tp2229221p2229221.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] [Metacello] Re: [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

[Torsten Bergmann]

>We should listen to Torsten but as far as I would expect, only HelpSystem,
>but it is already included in both PharoCore and Squeak.

The help system is included in Squeak trunk and Pharo core, so
one should be able to load the three example books (Squeak, Pharo,
Metacello) which I uploaded in squeksource/HelpSystem in both 
environments. Still they are just small demo books - no real
docu since there is not much content yet.

However - we could reuse them to document these systems if
for instance Dale is willing to contribute stuff to the
Metacello book or we create an ASCII version of the Metacello
preview PBE chapter. Would be nice to have a real Metacello help book
that would be part of the Metacello distro (similar to the ProfStef
Tutorial on Metacello) ...

Thanks
T.








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

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Latex to HelpSystem converter? [WAS] Re: [Metacello] Re: [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

[Mariano Martinez Peck]

On Mon, May 24, 2010 at 11:41 PM, Torsten Bergmann  wrote:

> >We should listen to Torsten but as far as I would expect, only HelpSystem,
> >but it is already included in both PharoCore and Squeak.
>
> The help system is included in Squeak trunk and Pharo core, so
> one should be able to load the three example books (Squeak, Pharo,
> Metacello) which I uploaded in squeksource/HelpSystem in both
> environments. Still they are just small demo books - no real
> docu since there is not much content yet.
>
> However - we could reuse them to document these systems if
> for instance Dale is willing to contribute stuff to the
> Metacello book or we create an ASCII version of the Metacello
> preview PBE chapter.


Maybe I am dreaming too much, but it would be cool to export somehow some
chapters to HelpSystem.
Is there a way to export from Latex to ASCII ?  even more, how difficult
could be to code a plugin (or whatever name is) to automatically generate
the nice code for HelpSystem from Latex code?

Then we can include PBE in the image also ;)

Cheers

Mariano



> Would be nice to have a real Metacello help book
> that would be part of the Metacello distro (similar to the ProfStef
> Tutorial on Metacello) ...
>
> Thanks
> T.
>
>
>
>
>
>
>
>
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Latex to HelpSystem converter? [WAS] Re: [Metacello] Re: [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

[Dale Henrichs]

Mariano Martinez Peck wrote:


On Mon, May 24, 2010 at 11:41 PM, Torsten Bergmann 
mailto:asta...@gmx.de>> wrote:

We should listen to Torsten but as far as I would expect, only HelpSystem,
but it is already included in both PharoCore and Squeak.


The help system is included in Squeak trunk and Pharo core, so
one should be able to load the three example books (Squeak, Pharo,
Metacello) which I uploaded in squeksource/HelpSystem in both
environments. Still they are just small demo books - no real
docu since there is not much content yet.


I have pulled the Metacello-Help package over to the metacello 
repository and have added to a baseline for 1.0-beta.27... but it should 
have more content...




However - we could reuse them to document these systems if
for instance Dale is willing to contribute stuff to the
Metacello book or we create an ASCII version of the Metacello
preview PBE chapter.


Mariano is actually doing all of the heavy lifting on the PBE chapter:)



Maybe I am dreaming too much, but it would be cool to export somehow some 
chapters to HelpSystem.
Is there a way to export from Latex to ASCII ?  even more, how difficult could 
be to code a plugin (or whatever name is) to automatically generate the nice 
code for HelpSystem from Latex code?

Then we can include PBE in the image also ;)


This would be very cool!

It seems that there is a place for online (pdf..) documentation, but the 
online and in-image documentation really needs to stay in synch!


Dale

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] ConnectionQueue defect in 1.0

[Schwab,Wilhelm K]

Hello all,

Attached is a simple test for networking.  It passed in 1.0 RC1 and fails in 
1.0 and in 1.1 beta.  The problem arises in ConnectionQueue>>listenLoop.  
#waitForConnectionFor: returns a boolean, not the new socket, and the listen 
loop looks like it is expecting the socket.  Any ideas?

Bill



NetworkSmokeTestCase.st
Description: NetworkSmokeTestCase.st
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] FFI debugging lesson

[Schwab,Wilhelm K]

I did some FFI based work in Pharo 1.0 and realized something that I found 
surprising; this might help others new to it.  An incorrect argument type in a 
call spec does not result in a compile-time error; instead it leads to "Cannot 
coerce arguments" at the time of the call.  FWIW.

Bill


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ClassTestCase

[John M McIntosh]

On 2010-05-24, at 1:47 PM, Levente Uzonyi wrote:

> On Mon, 24 May 2010, Lukas Renggli wrote:
> 
>>> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the
>>> moment, so that should be preferred in core packages.
>> 
>> It should not be preferred or changes unless you can prove a real
>> performance benefit. I still haven't seen a single realistic benchmark
>> with real code (from Pharo, Seaside, Pier, ...) where you can measure
>> a real difference between these 4 variants.
> 
> Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil 
> ifTrue: etc. Then get some benchmarks which you accept as realistic and run 
> them in both images.
> 


Well what is going on is that you are changing the 
 foo isNil ifTrue:  
which is a message send for the isNil into a 
foo == nil ifTrue: 
which then does an object identity check in byte codes. 

Because messages sends are *slow* removing one from millions of executions does 
improve things. 

However what be more clever is changing the compiler to optimize the use of 
isNil so you maintain readability without a performance penalty.

Also consider 'first' 'second' 

Well and the case of the simple accessor 

self foo ifTrue:[]
where 
foo
^foo


--
===
John M. McIntoshTwitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===






smime.p7s
Description: S/MIME cryptographic signature
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ClassTestCase

[Levente Uzonyi]

On Mon, 24 May 2010, John M McIntosh wrote:



On 2010-05-24, at 1:47 PM, Levente Uzonyi wrote:


On Mon, 24 May 2010, Lukas Renggli wrote:


IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the
moment, so that should be preferred in core packages.


It should not be preferred or changes unless you can prove a real
performance benefit. I still haven't seen a single realistic benchmark
with real code (from Pharo, Seaside, Pier, ...) where you can measure
a real difference between these 4 variants.


Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil 
ifTrue: etc. Then get some benchmarks which you accept as realistic and run 
them in both images.




Well what is going on is that you are changing the
foo isNil ifTrue:
which is a message send for the isNil into a
foo == nil ifTrue:
which then does an object identity check in byte codes.

Because messages sends are *slow* removing one from millions of executions does 
improve things.

However what be more clever is changing the compiler to optimize the use of 
isNil so you maintain readability without a performance penalty.


Is "isNil" really more readable than "== nil"?



Also consider 'first' 'second'

Well and the case of the simple accessor

self foo ifTrue:[]
where
foo
^foo


Inlining more methods is a bad idea IMHO. It makes the compiler and the 
decompiler more complex. An inlining JIT is the real solution.



Levente




--
===
John M. McIntoshTwitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===







___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Monticello keeps "diffing" forvever

[AxiNat]

Hi all,

A package I had uploaded to monticello was corrupt, and besides -I think
it's not relevant, but just in case- squeaksource was down so it was only
saved locally.

When I realized that the version was corrupt I erased it from the repo, and
now every time I try to save a new version it stays "Diffing" forever,
should I wait for it to finish (I'm beginning to lose faith in this ever
happening) or take a different approach?

Thanks!

Bernat Romagosa.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ClassTestCase

[Francisco Ortiz Peñaloza]

Is "isNil" really more readable than "== nil"?

imho yes... i find it more readable, more "smalltalkish" but the
conversation ended up being about performance rather than if it's more
readable or not so obviously there is a bigger issue :)

Francisco

On Mon, May 24, 2010 at 11:22 PM, Levente Uzonyi  wrote:
> On Mon, 24 May 2010, John M McIntosh wrote:
>
>>
>> On 2010-05-24, at 1:47 PM, Levente Uzonyi wrote:
>>
>>> On Mon, 24 May 2010, Lukas Renggli wrote:
>>>
> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at
> the
> moment, so that should be preferred in core packages.

 It should not be preferred or changes unless you can prove a real
 performance benefit. I still haven't seen a single realistic benchmark
 with real code (from Pharo, Seaside, Pier, ...) where you can measure
 a real difference between these 4 variants.
>>>
>>> Well, just replace all uses of == nil and #ifNil:, etc with isNil and
>>> isNil ifTrue: etc. Then get some benchmarks which you accept as realistic
>>> and run them in both images.
>>>
>>
>>
>> Well what is going on is that you are changing the
>> foo isNil ifTrue:
>> which is a message send for the isNil into a
>> foo == nil ifTrue:
>> which then does an object identity check in byte codes.
>>
>> Because messages sends are *slow* removing one from millions of executions
>> does improve things.
>>
>> However what be more clever is changing the compiler to optimize the use
>> of isNil so you maintain readability without a performance penalty.
>
> Is "isNil" really more readable than "== nil"?
>
>>
>> Also consider 'first' 'second'
>>
>> Well and the case of the simple accessor
>>
>> self foo ifTrue:[]
>> where
>> foo
>> ^foo
>
> Inlining more methods is a bad idea IMHO. It makes the compiler and the
> decompiler more complex. An inlining JIT is the real solution.
>
>
> Levente
>
>>
>>
>> --
>>
>> ===
>> John M. McIntosh    Twitter:
>>  squeaker68882
>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>
>> ===
>>
>>
>>
>>
>>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ClassTestCase

[John M McIntosh]

On 2010-05-24, at 7:22 PM, Levente Uzonyi wrote:

> Inlining more methods is a bad idea IMHO. It makes the compiler and the 
> decompiler more complex. An inlining JIT is the real solution.
> 
> 
> Levente


If it's smalltalk code underfoot then likely a bunch of people might have an 
interest or at least be able to hack, criticize, be happy, or ignore it. 

If it's a JIT buried in SLANG, C or assembler then I'd guess not more than 5 
people would know anything about how it works, or figure out
how to fix it.

--
===
John M. McIntoshTwitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===






smime.p7s
Description: S/MIME cryptographic signature
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] How to deal with issue 1594

[Gabriel Cotelli]

During the sprint in baires we write some tests to detect the senders of =
nil to be replaced with isNil as the issue suggest.

We now need to do a rewrite of this methods (this could be done using the
refactoring engine as lukas proposed in the issue). However if I do this
rewrite on the Dev image I will change code not only in Pharo Core but also
in some external packages. Is it the intended scope of the issue?.

I think that first we need to do the rewrite on Pharo Core code.
And let every package maintainer to decide if he wants to do it or not. Of
course for the community maintained packages we can make that decision too.

In the future I think would be good to have some kind of "Pharo Coding
Practices" (or the name we want) that can be automatically tested. As a
community we can discuss this practices and provide some automatic way to
ensure that.

As soon as posible I will create a Slice with the changes in Pharo Core and
post it to the inbox (sorry if it takes me some days but here where are
celebrating the argentinean bicentennial so i don't have too much free time
this days :) ).

Regards,
Gabriel
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] How to deal with issue 1594

[Igor Stasenko]

2010/5/25 Gabriel Cotelli :
> During the sprint in baires we write some tests to detect the senders of =
> nil to be replaced with isNil as the issue suggest.


and what if i intentionally may want to implement:

MyClass>> = anObject
  ^ anObject == nil

to make my object to be 'equal' to nil?

> We now need to do a rewrite of this methods (this could be done using the
> refactoring engine as lukas proposed in the issue). However if I do this
> rewrite on the Dev image I will change code not only in Pharo Core but also
> in some external packages. Is it the intended scope of the issue?.
> I think that first we need to do the rewrite on Pharo Core code.
> And let every package maintainer to decide if he wants to do it or not. Of
> course for the community maintained packages we can make that decision too.
> In the future I think would be good to have some kind of "Pharo Coding
> Practices" (or the name we want) that can be automatically tested. As a
> community we can discuss this practices and provide some automatic way to
> ensure that.
> As soon as posible I will create a Slice with the changes in Pharo Core and
> post it to the inbox (sorry if it takes me some days but here where are
> celebrating the argentinean bicentennial so i don't have too much free time
> this days :) ).
> Regards,
> Gabriel
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] How to deal with issue 1594

[Stéphane Ducasse]

Thanks gabriel and happy celebration!

Stef
On May 25, 2010, at 7:00 AM, Gabriel Cotelli wrote:

> During the sprint in baires we write some tests to detect the senders of = 
> nil to be replaced with isNil as the issue suggest.
> 
> We now need to do a rewrite of this methods (this could be done using the 
> refactoring engine as lukas proposed in the issue). However if I do this 
> rewrite on the Dev image I will change code not only in Pharo Core but also 
> in some external packages. Is it the intended scope of the issue?.
> 
> I think that first we need to do the rewrite on Pharo Core code.
> And let every package maintainer to decide if he wants to do it or not. Of 
> course for the community maintained packages we can make that decision too.
> 
> In the future I think would be good to have some kind of "Pharo Coding 
> Practices" (or the name we want) that can be automatically tested. As a 
> community we can discuss this practices and provide some automatic way to 
> ensure that. 
> 
> As soon as posible I will create a Slice with the changes in Pharo Core and 
> post it to the inbox (sorry if it takes me some days but here where are 
> celebrating the argentinean bicentennial so i don't have too much free time 
> this days :) ).
> 
> Regards,
> Gabriel
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project