Re: [Pharo-project] [Moose-dev] font installer & free type fonts

[stephane ducasse]

On May 12, 2013, at 8:18 AM, Tudor Girba  wrote:

> Hi,
> 
> The fonts-related code is a bit too complex for my mind.

for mine too :)

> 
> Semi bold is indeed not a FreeTypeFontFamily, but a FreeTypeFontFamilyMember.
> 
> After loading the font, you can inspect it via:
> (LogicalFontManager current allFamilies 
>   detect: [:each | each familyName = 'Source Code Pro' ])
>   members detect: [ :each | each styleName = 'Semibold' ].
> 
> You will see that it has a couple of integer values for: stretch, weight and 
> slant. The only way I could set a LogicalFont from outside was via these 
> values explicitly:
> 
> StandardFonts codeFont: (LogicalFont
>   familyName: 'Source Code Pro'
>   pointSize: 10
>   stretchValue: 5 
>   weightValue: 600 
>   slantValue: 0).
> 
> I guess we need to review this part of Pharo.
> 
> Cheers,
> Doru
> 
> 
> On May 11, 2013, at 5:39 PM, stephane ducasse  
> wrote:
> 
>> Hi doru
>> 
>> How do you use SourceCodeProSemibold for example 
>> StandardFonts codeFont: (LogicalFont
>> familyName: 'Source Code Pro'
>> pointSize: 10).
>> 
>> Because there is no family name for semi bold
>> 
>> Stef
>> 
>> 
>> 
>> On May 11, 2013, at 12:21 AM, Tudor Girba  wrote:
>> 
>>> Hi,
>>> 
>>> To ease the transition to Athens, we need to get free type fonts in the 
>>> image. I researched a bit, and found a couple of font families that are 
>>> nicely free and open-source: DejaVu, Source Code Pro, Source Sans Pro, and 
>>> LinLibertine.
>>> 
>>> I put together a little tool that imports a TTF file and installs it in a 
>>> dedicated class. You can find a library of already imported fonts on 
>>> SmalltalkHub:
>>> http://www.smalltalkhub.com/#!/~girba/FreeFonts/
>>> 
>>> More details about this library can be found at:
>>> http://www.tudorgirba.com/blog/free-font-collection-for-pharo
>>> 
>>> For example, you can use the SourceCodeProRegular font as a code font like:
>>> Gofer new
>>>  smalltalkhubUser: 'girba' project: 'FreeFonts';
>>>  package: 'SourceCodeProRegular';
>>>  load.
>>> (Smalltalk at: #SourceCodeProRegular) new install.
>>> FreeTypeSystemSettings loadFt2Library: true.
>>> StandardFonts codeFont: (LogicalFont familyName: 'Source Code Pro' 
>>> pointSize: 10).
>>> 
>>> The Moose image already comes with a convenience method to set a complete 
>>> free type font set:
>>> MooseImageSetupCommandLineHandler new installFonts.
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
>>> --
>>> www.tudorgirba.com
>>> 
>>> "Be rather willing to give than demanding to get."
>>> 
>>> ___
>>> Moose-dev mailing list
>>> moose-...@iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>> 
>> ___
>> Moose-dev mailing list
>> moose-...@iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> 
> --
> www.tudorgirba.com
> 
> "If you can't say why something is relevant, 
> it probably isn't."
> 
> 
> ___
> Moose-dev mailing list
> moose-...@iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Re: [Pharo-project] [Moose-dev] font installer & free type fonts

[stephane ducasse]

Hi doru

How do you use SourceCodeProSemibold for example 
StandardFonts codeFont: (LogicalFont
 familyName: 'Source Code Pro'
 pointSize: 10).

Because there is no family name for semi bold

Stef



On May 11, 2013, at 12:21 AM, Tudor Girba  wrote:

> Hi,
> 
> To ease the transition to Athens, we need to get free type fonts in the 
> image. I researched a bit, and found a couple of font families that are 
> nicely free and open-source: DejaVu, Source Code Pro, Source Sans Pro, and 
> LinLibertine.
> 
> I put together a little tool that imports a TTF file and installs it in a 
> dedicated class. You can find a library of already imported fonts on 
> SmalltalkHub:
> http://www.smalltalkhub.com/#!/~girba/FreeFonts/
> 
> More details about this library can be found at:
> http://www.tudorgirba.com/blog/free-font-collection-for-pharo
> 
> For example, you can use the SourceCodeProRegular font as a code font like:
> Gofer new
>   smalltalkhubUser: 'girba' project: 'FreeFonts';
>   package: 'SourceCodeProRegular';
>   load.
> (Smalltalk at: #SourceCodeProRegular) new install.
> FreeTypeSystemSettings loadFt2Library: true.
> StandardFonts codeFont: (LogicalFont familyName: 'Source Code Pro' pointSize: 
> 10).
> 
> The Moose image already comes with a convenience method to set a complete 
> free type font set:
> MooseImageSetupCommandLineHandler new installFonts.
> 
> Cheers,
> Doru
> 
> 
> --
> www.tudorgirba.com
> 
> "Be rather willing to give than demanding to get."
> 
> ___
> Moose-dev mailing list
> moose-...@iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Re: [Pharo-project] [Lsehub-staff] AST-Navigation short demo

[stephane ducasse]

gisela

Did you implement an sender and implementors based on the selector (ast 
analysis)?
Did we replace the old one with this new one?

Stef

On May 8, 2013, at 2:03 PM, Gisela Decuzzi  wrote:

> Hi! I've recorded the video as Damian suggested to show how to use the code 
> navigation based in the ast :)
> 
> Here it's the video: http://www.youtube.com/watch?v=pFLyzEI0jmE (Sorry for my 
> English)
> 
> And if you want to try:
> Gofer it
>  url: 'http://smalltalkhub.com/mc/gisela/NodeNavigation/main';
>  package: 'ConfigurationOfNodeNavigation';
>  load.
> ((Smalltalk globals at: #ConfigurationOfNodeNavigation) project version: 
> #development) load.
> 
> A summary for the shortcuts:
> - going to the parent: ctrl + shift + p (command + shift + p for mac)
> - going to the first child: ctrl + shift + o (command + shift + o for mac)
> - going to same level node: ctrl + shift + u (command + shift + u for mac)
> 
> It would be great to use the arrowUp or down, I want to check if it's easy to 
> make them work first and also make the navigation available for debugger, 
> workspace, message browser (...)
> 
> 

Re: [Pharo-project] [Pharo-users] the future of squeaksource

[stephane ducasse]

On May 7, 2013, at 5:19 PM, Andrei Vasile Chis  
wrote:

> Hi all,
> 
> Given that SmalltalkHub is now stable we were considering to discontinue 
> SqueakSource. 
> Our idea is to provide a grace period of a couple of months to allow the 
> current active users to migrate their projects to the new service and then 
> simply put squeaksource in read-only mode (simply exposing the directory 
> structure and allowing downloads).
> 
> What do you think about it ?
> Are there any good reasons to still keep SqueakSource alive? 

Keep it alive so that we can slowly migrate. Because migrating takes a lot of 
time.



> 
> Cheers,
> The SCG Team

Re: [Pharo-project] WhatsUp from: 2013-05-06 until: 2013-05-19

[stephane ducasse]

On May 6, 2013, at 7:00 AM, seas...@rmod.lille.inria.fr wrote:

> Hi! We're sending this automatic email twice a month, to give the community 
> an opportunity to easily know what's happening and to coordinate efforts.  
> Just answer informally, and feel free to spawn discussions thereafter!
> 
> ### Here's what I've been up to since the last WhatsUp:

- massively cleaned Pharo by example git repository and its clones.
- produced a first version of the spanish book (yes not just a collection of 
draft chapters)
- pushing Squeaksource/Pharo10 to smalltalkhub
- studying logging frameworks
- reviewing Zinc chapter on gutenberg
- produced a video of rolling dice in Pharo 
http://stephane.ducasse.free.fr/Videos/2013-04-20-Dice-v3.mov
- produced a chapter on dice rolling


> ### What's next, until 2013-05-19 (*):

- going back to hacking

Stef

Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:

[stephane ducasse]

On May 6, 2013, at 9:11 AM, Norbert Hartl  wrote:

> 
> Am 06.05.2013 um 08:00 schrieb Denis Kudriashov :
> 
>> Hello.
>> 
>> What about logging levels?
>> 
>> I like "logInfo:", "logDebug:", "logTrace:". Or maybe it is better to split 
>> log with levels: "self log info:", "self log debug:", "self log trace:"
>> 
> I think that opens a can of worms. What Stef wants is a "say something" 
> method that is easy to use and commonly useful. Adding logging levels is a 
> specialized form of logging that is not commonly useful, it's just commonly 
> used in less reflective environments. 
> So my proposal would be to have an equivalent to "self log" where you can 
> return your own logging facility on which you can do "self log info: 
> 'something'". 
> 
> I changed my kind of logging some time ago. I just log objects. A log object 
> isn't much more than to put it on top of a collection. While I'm not using 
> strings for logging I have objects where I can attach all my use case 
> dependent stuff. You could even put something like a log level information in 
> those objects. 
> I log Errors as well as progress state objects,etc. It is easy to process the 
> whole log collection (now or afterwards) because all necessary state is still 
> there. 

Yes!!!

> Another reason why I don't like strings for that is that I put the log 
> messages as json in elasticsearch/mongo because I want to query them to find 
> errornous behaviour. Well, sometimes I do both: Store it in a database and 
> write it to disk. Because I don't convert it to a string at first possible 
> time I can do that easily. 
> 
> We don't put sources in files so we shouldn't put log information only there. 
> Make logging information a first class citizen!


Yes this is what I'm doing right now. 
So back to coding…..
> 
> Norbert
> 
>> Best regards,
>> Denis
>> 
>> 2013/5/5 Stéphane Ducasse 
>> Hi guys
>> 
>> Stupidly I introduced log: a while ago to replace Transcript show:. Now is 
>> the current situation.
>> 
>> I still want to remove all the use of Transcript show:
>> 
>> Now since I thought I did a mistake with log: because it overload 
>> Integer>>log: I introduced trace: and traceCr:
>> 
>> Now I do not like traceCr: because it is not a cool message.
>> 
>> So what do we do:
>> 
>> 1) we use crLog:, logCr:
>> and deprecated log:
>> 
>> 
>> 2) we use crTrace:, trace: and traceCr:
>> 
>> I really prefer solution 1 but I would like to hear from you.
>> 
>> Stef
>> 
> 

Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:

[stephane ducasse]

>> 
> 
> I assume crLog:/logCr: is a short and convenient form of something else. How 
> would these be called? Basically I want to log objects

YES

> and only the default in Object should use Transcript in combination with 
> "asString". On top of the short form a convenient selector that adds a line 
> ending makes sense. 

:)
We are in sync :)

> There needs to be a getter for a log where one can attach all needs like 
> logging levels, log destinations, etc. So is the plan to have only the direct 
> replacement for "Transcript show:" or something that can be extended/used 
> differently.

Yes!

> And why do we use cr?

because of text :)
But since we will have objects :)

> I think it is pretty common to us NL = newline. Where does this come from? 
> Logically a "carriage return" enables you only to print something in bold 
> while newline enables you to print a whole page :)
> 
> Norbert

Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:

[stephane ducasse]

Yes I have that in what I prepare.

Stef

On May 6, 2013, at 8:00 AM, Denis Kudriashov  wrote:

> Hello.
> 
> What about logging levels?
> 
> I like "logInfo:", "logDebug:", "logTrace:". Or maybe it is better to split 
> log with levels: "self log info:", "self log debug:", "self log trace:"
> 
> Best regards,
> Denis
> 
> 2013/5/5 Stéphane Ducasse 
> Hi guys
> 
> Stupidly I introduced log: a while ago to replace Transcript show:. Now is 
> the current situation.
> 
> I still want to remove all the use of Transcript show:
> 
> Now since I thought I did a mistake with log: because it overload 
> Integer>>log: I introduced trace: and traceCr:
> 
> Now I do not like traceCr: because it is not a cool message.
> 
> So what do we do:
> 
> 1) we use crLog:, logCr:
> and deprecated log:
> 
> 
> 2) we use crTrace:, trace: and traceCr:
> 
> I really prefer solution 1 but I would like to hear from you.
> 
> Stef
> 

Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:

[stephane ducasse]

On May 6, 2013, at 7:16 AM, S Krish  wrote:

> I mentioned in another thread. #crLog, #logCr are intuitive and perfectly 
> fine. 
> 
> Also  hook Loggers first class into the system ( Toothpick ) and make it 
> default to Transcript with these messages routed to the Logger.
> 
> Transcript cr / current #crLog is akin to cout / System.out.println .. mostly 
> deprecated in enterprise coding practices.

I want to kill all the Transcript show: as well as as the logCr: 
I started to work on that and when it will be ready for feedback I will 
announce it.


> 
> 
> 
> 
> On Mon, May 6, 2013 at 3:04 AM, Sven Van Caekenberghe  wrote:
> 
> On 05 May 2013, at 21:42, Stéphane Ducasse  wrote:
> 
> > Hi guys
> >
> > Stupidly I introduced log: a while ago to replace Transcript show:. Now is 
> > the current situation.
> >
> > I still want to remove all the use of Transcript show:
> >
> > Now since I thought I did a mistake with log: because it overload 
> > Integer>>log: I introduced trace: and traceCr:
> >
> > Now I do not like traceCr: because it is not a cool message.
> >
> > So what do we do:
> >
> >   1) we use crLog:, logCr:
> >   and deprecated log:
> >
> >
> >   2) we use crTrace:, trace: and traceCr:
> >
> > I really prefer solution 1 but I would like to hear from you.
> >
> > Stef
> 
> I am for 1 as well, but I find #crLog: or #logCr: confusing - there should 
> only be one system wide approach.
> Also, whether or not to add a Cr to a log message (or before or after it) is 
> not a decision a client/user should have to make.
> Maybe Cr makes no sense, for example when log messages are added to a 
> collection.
> 
> So I am for #log: as a simple and clear message.
> 
> The conflict with Number>>#log: is less important than that IMHO.
> Either we live with the conflict or we rename Number>>#log: to 
> Number>>#logBase: or something like that.
> 
> I also like the convention of #value being sent by #log: to its argument.
> That allows for blocks that are not evaluated when logging is disabled.
> 
> My 2c.
> 
> Sven
> 
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
> 
> 
> 

Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:

[stephane ducasse]

I think that Cr is useless because they are to separate line in text and I want 
to kill text and just get objects (that can produce text but from a list of 
objects I easily can add a cr between their printstring :)

Stef

On May 5, 2013, at 11:34 PM, Sven Van Caekenberghe  wrote:

> 
> On 05 May 2013, at 21:42, Stéphane Ducasse  wrote:
> 
>> Hi guys
>> 
>> Stupidly I introduced log: a while ago to replace Transcript show:. Now is 
>> the current situation.
>> 
>> I still want to remove all the use of Transcript show:
>> 
>> Now since I thought I did a mistake with log: because it overload 
>> Integer>>log: I introduced trace: and traceCr:
>> 
>> Now I do not like traceCr: because it is not a cool message.
>> 
>> So what do we do:
>> 
>>  1) we use crLog:, logCr: 
>>  and deprecated log: 
>> 
>> 
>>  2) we use crTrace:, trace: and traceCr: 
>> 
>> I really prefer solution 1 but I would like to hear from you.
>> 
>> Stef
> 
> I am for 1 as well, but I find #crLog: or #logCr: confusing - there should 
> only be one system wide approach.
> Also, whether or not to add a Cr to a log message (or before or after it) is 
> not a decision a client/user should have to make.
> Maybe Cr makes no sense, for example when log messages are added to a 
> collection.
> 
> So I am for #log: as a simple and clear message.
> 
> The conflict with Number>>#log: is less important than that IMHO.
> Either we live with the conflict or we rename Number>>#log: to 
> Number>>#logBase: or something like that.
> 
> I also like the convention of #value being sent by #log: to its argument. 
> That allows for blocks that are not evaluated when logging is disabled.
> 
> My 2c.
> 
> Sven
> 
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
> 
> 

Re: [Pharo-project] Programming interactions with State Machines

[stephane ducasse]

On May 6, 2013, at 2:31 AM, Carla F. Griggio  wrote:

> Hello everyone!
> I'm here to tell you that I started experimenting with a Pharo implementation 
> of this idea: http://swingstates.sourceforge.net/. For those into UI 
> programming I really recommend reading the first paper cited in that page. 
> It's for programming user interface interactions with state machines, an 
> approach to avoid the classical "callback spaghetti" that sometimes we get 
> with event handlers everywhere.

This is looking interesting. Now we should check how it works with inheritance. 
Keep us posted about your progress.

Stef

> I have a tiny first step that shows an example for changing the color of a 
> button on mouse over and changing it back to the original color on mouse out.
> 
> You can download the code from: 
> http://smalltalkhub.com/mc/CarlaGriggio/StateMachines/main
> 
> Evaluate this for executing the example:
> 
> SMButton openWithStateMachineInteraction
> 
> And here is the code of the state machine for that example:
> 
> SMButton class >> openWithStateMachineInteraction
> |button stateMachine iddle hover |
> button := self new.
> stateMachine := SMStateMachine newForWidget: button.
> iddle := (SMState newWithName:'iddle')
> enter:[:stMachine | stMachine widget color: Color yellow ];
> addTransition: ((SMTransition forEvent: 'mouse enter' withOutputState: 
> 'hover')
> transitionAction: [:stMachine | stMachine widget color: Color red ]).
> hover := (SMState newWithName:'hover')
> addTransition: (SMTransition forEvent: 'mouse out' withOutputState: 'iddle');
> addTransition: (SMTransition forEvent: 'mouse enter' withOutputState: 
> 'hover').
> stateMachine addState: iddle; addState: hover.
> stateMachine attachTo: button.
> ^button openInWorld
>  
> That code corresponds to the following states diagram:
> 
> 
> 
> I will keep experimenting with this during the next weeks, and specially try 
> to compare the pros and cons with regular event handling.
> 
> Something cool about this approach is that the same widget could change its 
> interactive behaviour on the fly by just attaching a different interaction 
> state machine to it :) 
> 
> Also, I'm doing this for programming user interface interactions, but it 
> could be useful for anything that can be modelled with a state pattern.
> 
> Is there something similar out there already working? I was so eager to try 
> this that I didn't look for related existing projects.
> 
> Cheers!
> Carla.

Re: [Pharo-project] RFB in 2.0

[stephane ducasse]

this is called PharoExtras.

Stef

On May 6, 2013, at 6:16 PM, Norbert Hartl  wrote:

> 
> Am 03.05.2013 um 20:09 schrieb Mariano Martinez Peck :
> 
>> 
>> 
>> 
>> On Fri, May 3, 2013 at 3:05 PM, Norbert Hartl  wrote:
>> 
>> Am 03.05.2013 um 20:00 schrieb Mariano Martinez Peck :
>> 
>>> Hi Norbert,
>>> 
>>> I would move it to its own new repo in SmalltalkHub.
>>> 
>> Ok, but then it goes under my private section, right?
>> 
>> you can put it under PharoContributions team.
>>  
> How can I do that? I don't find anything like PharoContributions on 
> smalltalkhub.
> 
> Norbert
> 
>> 
>>> Also, I had another problem with RFB and the UIManager. The solution I 
>>> found was this one: http://samadhiweb.com/blog/2012.11.04.headless.rfb.html
>>> I don't like it because I need to change Pharo's base source, but I didn't 
>>> spend time finding a better solution...I guess there is, though.
>>> 
>> The first line of code all my images (deployed on server using RFB) see is
>> 
>> UIManager default: MorphicUIManager new.
>> 
>> 
>> I was going to do that as well. But it is not clear to me WHERE you write 
>> that line of code. Because even if you save the image with that, doesn't the 
>> image set its own UI manager when booting?  So I guess you need to pass 
>> around a script when running the image or something?
>> What about adding RFB at startup list and implement #startUp doing  
>> "UIManager default: MorphicUIManager new." ?
>> 
>> Best, 
>> 
>>  
>> With that I don't have problems at all.
>> 
>> thanks,
>> 
>> Norbert
>> 
>>> Best, 
>>> 
>>> 
>>> 
>>> 
>>> On Fri, May 3, 2013 at 2:56 PM, Norbert Hartl  wrote:
>>> I've found the problem. There is a FileDirectory access in 
>>> RFBSession>>#desktopName. Removing it makes RFB work.
>>> 
>>> The current RFB sources are on Lukas' server. What do we do with that 
>>> stuff? Move to smalltalkhub? If not I can ask Lukas to give me write 
>>> permission. Just wanted to ask what kind of behaviour is en vogue this days.
>>> 
>>> Norbert
>>> 
>>> Am 03.05.2013 um 19:31 schrieb Norbert Hartl :
>>> 
>>> > Esteban,
>>> >
>>> > now I can tell that it isn't working for me either. Socket is open and 
>>> > server is running. But there are immediate disconnects when trying to 
>>> > connect to a pharo2.0 image.
>>> >
>>> > Did you figure it out?
>>> >
>>> > Norbert
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Mariano
>>> http://marianopeck.wordpress.com
>> 
>> 
>> 
>> 
>> -- 
>> Mariano
>> http://marianopeck.wordpress.com
> 

Re: [Pharo-project] Pharo: an AMAZING community

[stephane ducasse]

thanks!
I hope that it will help people in their business.

Stef

On May 5, 2013, at 4:35 PM, Max Leske  wrote:

> +100!
> 
> Special thanks to Stef and all the guys at Lille. You're responsible for a 
> lot of the drive that we generate.
> 
> Max
> 
> On 05.05.2013, at 16:13, Sean P. DeNigris  wrote:
> 
>> I sometimes take for granted how extraordinary our community is. This
>> morning, it sunk in a bit how magical it truly is... I brought up two issues
>> I was having (not even bugs)... in the middle of the night... on a
>> Saturday... And like the Smalltalk fairy had come and snuck a solution under
>> my pillow while I dreamt, Sven and Benjamin added enhancements which solved
>> my dilemma! Thank you both :) And thank you to everyone that's contributed
>> over these years to make Pharo and its community so special :)
>> 
>> 
>> 
>> -
>> Cheers,
>> Sean
>> --
>> View this message in context: 
>> http://forum.world.st/Pharo-an-AMAZING-community-tp4685837.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>> 
> 
> 

Re: [Pharo-project] How to Debug :D

[stephane ducasse]

Thanks.  This is CSP passing style? I thought it was different.
Now going to eat and after I will digest that.
Thanks for the snippet.

Stef

> A trampoline looks like this:
> 
> Foo >> trampoline: initialValue into: aUnaryBlock
>| v |
>v := [initialValue].
>[v isBlock] whileTrue: [v := aUnaryBlock value: v value].
>^ v.
> 
> and then used:
> 
> | f factorial |
> factorial := 1.
> f := Foo new.
> f trampoline: 10 into: [ :n |
>n <= 0
>ifTrue: [factorial]
>ifFalse: [factorial := factorial * n. [n - 1]]].
> 
> The important thing is that the block returns a value for the base
> case/cases of the recursion, and a block that, when evaluated, will
> yield the next value on which to recurse. (So the block replaces the
> recursive call.)
> 
> The trampoline thus turns the recursive algorithm into an iteration.
> 
> frank
> 
> On 4 May 2013 17:42, stephane ducasse  wrote:
>> can you explain?
>> Because I read something like that olong time ago and I forgot
>> 
>> On May 4, 2013, at 5:41 PM, Frank Shearar  wrote:
>> 
>> So use a trampoline. Then you can define your recursion naturally, in
>> constant stack space.
>> 
>> frank
>> 
>> On 04 May 2013, at 16:08, stephane ducasse  wrote:
>> 
>> I understand why he wants that :)
>> no stack explosion…
>> 
>> Stef
>> 
>> On May 4, 2013, at 12:37 PM, Clément Bera  wrote:
>> 
>> To be more precise, for the method :
>> 
>> foo
>>^ 1 + 2
>> 
>> AST will be :
>> ^
>>   \
>>+
>>   /  \
>>  1   2
>> 
>> AST Interpreter, to interpret ^, will do something like :
>> start interpret ^
>>  interpret subnode of ^
>>  start interpret +
>>interpret subnodes of +
>>  interpret 1
>>  interpret 2
>>interpret + with subnodes interpretation result
>>  end interpret +
>>  interpret ^ with subnode interpretation result
>> end interpret ^
>> 
>> Igor would like to have a flatten AST that would be in an array like :
>> #( 1  2  +  ^ )
>> Then you can interpret it with a loop
>> [currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode
>> nextNode ].
>> And interpretation looks like :
>> interpret 2
>> interpret 1
>> interpret + with two precedent results on stack
>> interpret ^ with precedent result on stack
>> 
>> 2013/5/4 Clément Bera 
>>> 
>>> 2013/5/4 stephane ducasse 
>>>> 
>>>> 
>>>> On May 4, 2013, at 1:04 AM, Igor Stasenko  wrote:
>>>> 
>>>>> Did i said already that i don't like how ASTInterpreter implemented? :)
>>>> 
>>>> 
>>>> We will let perfection for later :)
>>> 
>>> 
>>> It is not a question of perfection or so.
>>> 
>>> Igor does not like that we interpret recursively the AST instead of with a
>>> loop (ASTInterpreter>>interpret: calls itself again and again). He would
>>> like to have a flatten-AST-interpreter, with a loop like:
>>> 
>>> [currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode
>>> nextNode ].
>>> 
>>> But Camillo and I don't want that because it interprets a flatten AST,
>>> not a tree.
>>> 
>>>> 
>>>>> 
>>>>> Nevertheless, it is useful.. and this case clearly demonstrates that.
>>>>> 
>>>>> On 4 May 2013 00:14, Clara Allende  wrote:
>>>>>> This is great news! Are you going to publish the code? it will come in
>>>>>> handy
>>>>>> for my summer of code :D
>>>>>> 
>>>>> 
>>>>> Camillo has the image
>>>>> 
>>>>>> 
>>>>>> On 3 May 2013 03:21, stephane ducasse 
>>>>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Begin forwarded message:
>>>>>>> 
>>>>>>> From: Camillo Bruni 
>>>>>>> Subject: [Lsehub-staff] How to Debug :D
>>>>>>> Date: May 2, 2013 6:22:06 PM GMT+02:00
>>>>>>> To: RMoD private list 
>>>>>>> Reply-To: RMoD private list 
>>>>>>> 
>>>>>>> Igor: Camillo can you help me debugging this strange athens rendering
>>>>>>> bug
>>>>>>> Cami: sure
>>>>>>> 
>>>>>>> Igor: where do you think the bug is? The green path jumps if I change
>>>>>>> the
>>>>>>> Y coordinate and it shouldn't...
>>>>>>> Cami: no clue...
>>>>>>> 
>>>>>>> Igor: Any clue how to get to the bug?
>>>>>>> Cami: let's use the ASTInterpreter to interpret two methods with
>>>>>>> different
>>>>>>> transformation matrices and see when they diverge.
>>>>>>> 
>>>>>>> Result:
>>>>>>> ---
>>>>>>> - after 1h comparing AST Debugger is ready
>>>>>>> - we run the two traces, they do NOT diverge => 
>>>>>>> 
>>>>>>> Conclusion:
>>>>>>> ---
>>>>>>> Cairo, which was chosen as reference, did not properly draw the
>>>>>>> path!!!
>>>>>>> 
>>>>>>> So we should publish the code of the ComparingInterpreter a bit and
>>>>>>> we
>>>>>>> can use it for a few more tasks in Pharo ;)
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Best regards,
>>>>> Igor Stasenko.
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>> --
>> Clément Béra
>> Mate Virtual Machine Engineer
>> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>> 
>> 
>> 
> 

Re: [Pharo-project] Using Athens for real ...

[stephane ducasse]

On May 4, 2013, at 7:22 PM, Igor Stasenko  wrote:

> On 4 May 2013 12:31, Camillo Bruni  wrote:
>> Yes that view is very neat! Especially for debugging, maintaining the
>> Smalltalk immediate feedback principle :0
>> 
> 
> and after i finish with path geometry calcucations, you can implement
> "clickable" things,
> no matter what their shape :)


arghh this is too cool :)
I want that ;D
The future will be massively fun :)
Stef

Re: [Pharo-project] Pharo Logo SVG

[stephane ducasse]

this is cool :)

Stef

On May 4, 2013, at 7:49 PM, Igor Stasenko  wrote:

> And here how it looks in Athens..
> yeah SVG importer needs more love, but my hands is too busy right now :(
> 
> AthensSceneView new
>   scene: (AthensSVGConverter fromFile: 'logo.svg');
>   openInWindow
> 
> 
> But this version of svg is much better, because old one contained
> bitmap data ... (brrr).
> Thanks for taking care!
> 
> -- 
> Best regards,
> Igor Stasenko.
> 

Re: [Pharo-project] How to Debug :D

[stephane ducasse]

can you explain?
Because I read something like that olong time ago and I forgot

On May 4, 2013, at 5:41 PM, Frank Shearar  wrote:

> So use a trampoline. Then you can define your recursion naturally, in 
> constant stack space.
> 
> frank
> 
> On 04 May 2013, at 16:08, stephane ducasse  wrote:
> 
>> I understand why he wants that :)
>> no stack explosion…
>> 
>> Stef
>> 
>> On May 4, 2013, at 12:37 PM, Clément Bera  wrote:
>> 
>>> To be more precise, for the method :
>>> 
>>> foo 
>>> ^ 1 + 2
>>> 
>>> AST will be :
>>>  ^
>>>\ 
>>> +
>>>/  \
>>>   1   2
>>> 
>>> AST Interpreter, to interpret ^, will do something like :
>>> start interpret ^
>>>   interpret subnode of ^
>>>   start interpret +
>>> interpret subnodes of +
>>>   interpret 1
>>>   interpret 2
>>> interpret + with subnodes interpretation result
>>>   end interpret +
>>>   interpret ^ with subnode interpretation result
>>> end interpret ^
>>> 
>>> Igor would like to have a flatten AST that would be in an array like :
>>> #( 1  2  +  ^ )
>>> Then you can interpret it with a loop
>>> [currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode 
>>> nextNode ].
>>> And interpretation looks like :
>>> interpret 2
>>> interpret 1
>>> interpret + with two precedent results on stack
>>> interpret ^ with precedent result on stack
>>> 
>>> 2013/5/4 Clément Bera 
>>> 2013/5/4 stephane ducasse 
>>> 
>>> On May 4, 2013, at 1:04 AM, Igor Stasenko  wrote:
>>> 
>>> > Did i said already that i don't like how ASTInterpreter implemented? :)
>>> 
>>> 
>>> We will let perfection for later :)
>>> 
>>> It is not a question of perfection or so.
>>> 
>>> Igor does not like that we interpret recursively the AST instead of with a 
>>> loop (ASTInterpreter>>interpret: calls itself again and again). He would 
>>> like to have a flatten-AST-interpreter, with a loop like: 
>>> 
>>> [currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode 
>>> nextNode ].
>>> 
>>>  But Camillo and I don't want that because it interprets a flatten AST, not 
>>> a tree.
>>> 
>>> 
>>> >
>>> > Nevertheless, it is useful.. and this case clearly demonstrates that.
>>> >
>>> > On 4 May 2013 00:14, Clara Allende  wrote:
>>> >> This is great news! Are you going to publish the code? it will come in 
>>> >> handy
>>> >> for my summer of code :D
>>> >>
>>> >
>>> > Camillo has the image
>>> >
>>> >>
>>> >> On 3 May 2013 03:21, stephane ducasse  wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> Begin forwarded message:
>>> >>>
>>> >>> From: Camillo Bruni 
>>> >>> Subject: [Lsehub-staff] How to Debug :D
>>> >>> Date: May 2, 2013 6:22:06 PM GMT+02:00
>>> >>> To: RMoD private list 
>>> >>> Reply-To: RMoD private list 
>>> >>>
>>> >>> Igor: Camillo can you help me debugging this strange athens rendering 
>>> >>> bug
>>> >>> Cami: sure
>>> >>>
>>> >>> Igor: where do you think the bug is? The green path jumps if I change 
>>> >>> the
>>> >>> Y coordinate and it shouldn't...
>>> >>> Cami: no clue...
>>> >>>
>>> >>> Igor: Any clue how to get to the bug?
>>> >>> Cami: let's use the ASTInterpreter to interpret two methods with 
>>> >>> different
>>> >>> transformation matrices and see when they diverge.
>>> >>>
>>> >>> Result:
>>> >>> ---
>>> >>> - after 1h comparing AST Debugger is ready
>>> >>> - we run the two traces, they do NOT diverge => 
>>> >>>
>>> >>> Conclusion:
>>> >>> ---
>>> >>> Cairo, which was chosen as reference, did not properly draw the path!!!
>>> >>>
>>> >>> So we should publish the code of the ComparingInterpreter a bit and we
>>> >>> can use it for a few more tasks in Pharo ;)
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Best regards,
>>> > Igor Stasenko.
>>> >
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Clément Béra
>>> Mate Virtual Machine Engineer
>>> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>> 

Re: [Pharo-project] How to Debug :D

[stephane ducasse]

I understand why he wants that :)
no stack explosion…

Stef

On May 4, 2013, at 12:37 PM, Clément Bera  wrote:

> To be more precise, for the method :
> 
> foo 
> ^ 1 + 2
> 
> AST will be :
>  ^
>\ 
> +
>/  \
>   1   2
> 
> AST Interpreter, to interpret ^, will do something like :
> start interpret ^
>   interpret subnode of ^
>   start interpret +
> interpret subnodes of +
>   interpret 1
>   interpret 2
> interpret + with subnodes interpretation result
>   end interpret +
>   interpret ^ with subnode interpretation result
> end interpret ^
> 
> Igor would like to have a flatten AST that would be in an array like :
> #( 1  2  +  ^ )
> Then you can interpret it with a loop
> [currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode 
> nextNode ].
> And interpretation looks like :
> interpret 2
> interpret 1
> interpret + with two precedent results on stack
> interpret ^ with precedent result on stack
> 
> 2013/5/4 Clément Bera 
> 2013/5/4 stephane ducasse 
> 
> On May 4, 2013, at 1:04 AM, Igor Stasenko  wrote:
> 
> > Did i said already that i don't like how ASTInterpreter implemented? :)
> 
> 
> We will let perfection for later :)
> 
> It is not a question of perfection or so.
> 
> Igor does not like that we interpret recursively the AST instead of with a 
> loop (ASTInterpreter>>interpret: calls itself again and again). He would like 
> to have a flatten-AST-interpreter, with a loop like: 
> 
> [currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode 
> nextNode ].
> 
>  But Camillo and I don't want that because it interprets a flatten AST, not a 
> tree.
> 
> 
> >
> > Nevertheless, it is useful.. and this case clearly demonstrates that.
> >
> > On 4 May 2013 00:14, Clara Allende  wrote:
> >> This is great news! Are you going to publish the code? it will come in 
> >> handy
> >> for my summer of code :D
> >>
> >
> > Camillo has the image
> >
> >>
> >> On 3 May 2013 03:21, stephane ducasse  wrote:
> >>>
> >>>
> >>>
> >>> Begin forwarded message:
> >>>
> >>> From: Camillo Bruni 
> >>> Subject: [Lsehub-staff] How to Debug :D
> >>> Date: May 2, 2013 6:22:06 PM GMT+02:00
> >>> To: RMoD private list 
> >>> Reply-To: RMoD private list 
> >>>
> >>> Igor: Camillo can you help me debugging this strange athens rendering bug
> >>> Cami: sure
> >>>
> >>> Igor: where do you think the bug is? The green path jumps if I change the
> >>> Y coordinate and it shouldn't...
> >>> Cami: no clue...
> >>>
> >>> Igor: Any clue how to get to the bug?
> >>> Cami: let's use the ASTInterpreter to interpret two methods with different
> >>> transformation matrices and see when they diverge.
> >>>
> >>> Result:
> >>> ---
> >>> - after 1h comparing AST Debugger is ready
> >>> - we run the two traces, they do NOT diverge => 
> >>>
> >>> Conclusion:
> >>> ---
> >>> Cairo, which was chosen as reference, did not properly draw the path!!!
> >>>
> >>> So we should publish the code of the ComparingInterpreter a bit and we
> >>> can use it for a few more tasks in Pharo ;)
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > Best regards,
> > Igor Stasenko.
> >
> 
> 
> 
> 
> 
> 
> 
> -- 
> Clément Béra
> Mate Virtual Machine Engineer
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-project] [update 3.0] #30100

[stephane ducasse]

marcus 

can you merge with my version of scriptloader next time you integrate?
Because my changes are not in.

Stef

On May 4, 2013, at 4:21 PM, Marcus Denker  wrote:

> 30100
> -
> 
> 10501 EyeInspector grammar issue
>   https://pharo.fogbugz.com/f/cases/10501
>   
> 10504 minor cleaning of normalize:ticks:base:
>   https://pharo.fogbugz.com/f/cases/10504
>   
> 10516 clean up #refusesToAcceptCode
>   https://pharo.fogbugz.com/f/cases/10516
>   
> 10505 Time newLocal is not normalized west of Greenwich
>   https://pharo.fogbugz.com/f/cases/10505
> 
> 
> Diff information:
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Tools-MarcusDenker.1103
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Inspector-MarcusDenker.17
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Polymorph-Widgets-MarcusDenker.800
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1423
> 
> 

Re: [Pharo-project] the newlist breaks the changesorter.

[stephane ducasse]

forget it was fixed in latest…30

On May 4, 2013, at 10:02 AM, Stéphane Ducasse  wrote:

> running out to do shopping.
> 
> Stef
> 

Re: [Pharo-project] How to Debug :D

[stephane ducasse]

On May 4, 2013, at 1:04 AM, Igor Stasenko  wrote:

> Did i said already that i don't like how ASTInterpreter implemented? :)


We will let perfection for later :)

> 
> Nevertheless, it is useful.. and this case clearly demonstrates that.
> 
> On 4 May 2013 00:14, Clara Allende  wrote:
>> This is great news! Are you going to publish the code? it will come in handy
>> for my summer of code :D
>> 
> 
> Camillo has the image
> 
>> 
>> On 3 May 2013 03:21, stephane ducasse  wrote:
>>> 
>>> 
>>> 
>>> Begin forwarded message:
>>> 
>>> From: Camillo Bruni 
>>> Subject: [Lsehub-staff] How to Debug :D
>>> Date: May 2, 2013 6:22:06 PM GMT+02:00
>>> To: RMoD private list 
>>> Reply-To: RMoD private list 
>>> 
>>> Igor: Camillo can you help me debugging this strange athens rendering bug
>>> Cami: sure
>>> 
>>> Igor: where do you think the bug is? The green path jumps if I change the
>>> Y coordinate and it shouldn't...
>>> Cami: no clue...
>>> 
>>> Igor: Any clue how to get to the bug?
>>> Cami: let's use the ASTInterpreter to interpret two methods with different
>>> transformation matrices and see when they diverge.
>>> 
>>> Result:
>>> ---
>>> - after 1h comparing AST Debugger is ready
>>> - we run the two traces, they do NOT diverge => 
>>> 
>>> Conclusion:
>>> ---
>>> Cairo, which was chosen as reference, did not properly draw the path!!!
>>> 
>>> So we should publish the code of the ComparingInterpreter a bit and we
>>> can use it for a few more tasks in Pharo ;)
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko.
> 

Re: [Pharo-project] Sprint

[stephane ducasse]

On May 4, 2013, at 12:11 AM, Camillo Bruni  wrote:

> Thanks everybody for the great sprint!
> 
> We fixed a lot of things today (incomplete list, please extend):
> 
> - DateAndTime startup cleansing
> - Fixing and integrating the new EyeInspector
> - Fixing Monticello recategorization bug
> - Removal of RBSmallDictionary 
> - Removal of an old deadly Morphic Halo

> - Full documentation of the Fogbugz tracker statuses: 
> https://pharo.fogbugz.com/default.asp?W65
> - --help on the VM does an exit 0 instead of a failure (exit 1)
> - Monticello commit is no longer run in a separate thread, and thus the image 
> does no longer freeze
> - Newly added Monticello repositories are compared against existing ones and 
> thus not duplicated
> - Configuration and Jenkins job for Smalltalkhub
> ...?
> 
> I hope we can repeat such a sprint again with the same motivation!

Yes we should.
Definitively.

> 
> cheers
> cami

Re: [Pharo-project] [ANN] GemStone/S product and team move to a dedicated company

[stephane ducasse]

this is cool :)

Stef

On May 3, 2013, at 9:22 PM, Dale Henrichs  wrote:

> 
> If you haven't already heard, the GemStone/S team is becoming an independent 
> company after 3 years as part of VMware. The entire engineering team is 
> moving to GemTalk Systems[1].
> 
> GemTalk Systems is completely focused on Smalltalk, GemStone/S and allied 
> initiatives. 
> 
> I've published a blog post[2] with my take on the acquisition (short answer 
> is "excited!"), if you have any additional questions, feel free to contact me.
> 
> Dale
> 
> [1] http://gemtalksystems.com/index.php/about-us/engineers/
> [2] 
> http://gemstonesoup.wordpress.com/2013/05/02/gemtalk-systems-acquires-gemstones/
> 

[Pharo-project] How to Debug :D

[stephane ducasse]

Begin forwarded message:

> From: Camillo Bruni 
> Subject: [Lsehub-staff] How to Debug :D
> Date: May 2, 2013 6:22:06 PM GMT+02:00
> To: RMoD private list 
> Reply-To: RMoD private list 
> 
> Igor: Camillo can you help me debugging this strange athens rendering bug
> Cami: sure
> 
> Igor: where do you think the bug is? The green path jumps if I change the Y 
> coordinate and it shouldn't...
> Cami: no clue...
> 
> Igor: Any clue how to get to the bug?
> Cami: let's use the ASTInterpreter to interpret two methods with different 
> transformation matrices and see when they diverge.
> 
> Result:
> ---
> - after 1h comparing AST Debugger is ready
> - we run the two traces, they do NOT diverge => 
> 
> Conclusion:
> ---
> Cairo, which was chosen as reference, did not properly draw the path!!!
> 
> So we should publish the code of the ComparingInterpreter a bit and we
> can use it for a few more tasks in Pharo ;)
> 
> 

Re: [Pharo-project] froze image just

[stephane ducasse]

On May 2, 2013, at 2:50 PM, Igor Stasenko  wrote:

> On 2 May 2013 09:54, Henrik Johansen  wrote:
>> What?
>> I am 99.99% sure it used to interrupt the GUI process if no other viable 
>> candidate could be found, why change that?
>> At least in my mind, if you hit cmd - dot, either you want to interrupt some 
>> process blocking the UI on a higher priority, or you want the UI process 
>> itself.
>> For everything else, there's the Process Browser.
>> 
> 
> It was never like that.
> It was always looking for a process which is scheduled, but not
> interrupt process itself.
> usually that meant it interrupts things like finalization process,
> so i added logic to avoid interrupting it unless there's nothing else
> to interrupt.
> 
> The problem is that if process is waiting for semaphore (and UI
> process doing it quite often)
> the interrupt handler cannot detect it. Because
> 1) it is not scheduled
> 2) even if you iterate over Process allInstances and ask #isSuspended
> to it, it will answer true
> 
> while 1) is fine, 2) is a design flaw i am talking about:
> - there is no way to discriminate between process which waits on
> semaphore and suspended process (which has no chances to run unless
> you send #resume to it, and therefore no need to interrupt)

thanks for the explanation.

Stef
> 
>> Cheers,
>> Henry
>> 
> 
> -- 
> Best regards,
> Igor Stasenko.
> 

Re: [Pharo-project] How i can retrieve the global by its name?

[stephane ducasse]

> But today using Smalltalk everywhere means that we are always using the same 
> environment, and that does not look like a big deal to anybody :)...
> 
> And then, that's easily solved by doing some simple stuff if you like specify 
> an environment, isn't it?
> 
> Symbol>>asClass
> self asClassInEnvironment: self class environment
> 
> Symbol>>asClassInEnvironment: anEnvironment
> anEnvironment globals at: self

yes :)
something like that.


Stef

Re: [Pharo-project] How i can retrieve the global by its name?

[stephane ducasse]

> asGlobalOrSomethingLikeThat :-)

;D

Re: [Pharo-project] How i can retrieve the global by its name?

[stephane ducasse]

On May 2, 2013, at 10:36 AM, Frank Shearar  wrote:

> What's "global"? Even if you haven't implemented scoped environments,
> rather use a name that doesn't imply that you'll never have scoped
> environments.

:)
this is why I proposed asClass

Now asGlobal can be interpreted as as globally accessible stuff.


> #asClass sounds better, except for Guillermo's point about well-known
> things that aren't classes.
> 
> frank
> 
> On 2 May 2013 09:31, Nicolas Cellier  
> wrote:
>> Sounds a bit like VW #{ }
>> 
>> This sounds good to me, but don't use globalBinding, I would expect this one
>> to answer the binding (Asociation) rather than the value.
>> 
>> 
>> 2013/5/2 Sven Van Caekenberghe 
>>> 
>>> 
>>> On 02 May 2013, at 06:03, Igor Stasenko  wrote:
>>> 
 Hi, all
 
 do not think that i am drunk or vent crazy, asking such silly
 question, which at best should be asked only by beginner :)
 
 I know the answer:
 
 Smalltalk at: #SomeName
 
 or
 
 Smalltalk globals at: #SomeName
 
 what stroke me, just now, that both answers is wrong!
 
 It should be:
 
 #SomeName asGlobal
 
 (or suggest more appropriate/precise method name for a symbol)
>>> 
>>> ConfigurationOfXYZ globalValue project bleedingEdge load.
>>> 
>>> ConfigurationOfXYZ globalValueIfPresent: [ :configuration | configuration
>>> project bleedingEdge load ]
>>> 
>>> An alternative could be globalBinding, but that is more technical.
>>> 
>>> #asGlobal sounds like a conversion, on the other hand it is an accepted
>>> idiom.
>>> 
 optionally, we could also have one, with handling absent case:
 
 #SomeName asGlobalIfAbsent: []
 
 same , but only if present:
 
 #SomeName asGlobalIfPresent: [:global | ]
 
 
 Currently, there is 941 references to 'Smalltalk' global in my pharo
 image.
 If we introduce this convenience method, it will shrink this number
 considerably,
 not saying that code will be more elegant and concise compare:
 
 (Smalltalk globals at: #Foo) doSomething
 
 and
 
 #Foo asGlobal doSomething
 
 P.S. What really strikes me is why we don't have such method from very
 beginning,
 and instead refer to 'Smalltalk' all over the places.
 Some things are so deeply indoctrinated in our minds, that we don't
 even think that it can be different.
 
 --
 Best regards,
 Igor Stasenko.
 
>>> 
>>> 
>> 
> 

Re: [Pharo-project] How i can retrieve the global by its name?

[stephane ducasse]

> 
> ConfigurationOfXYZ globalValue project bleedingEdge load.

#ConfigurationOfXYZ globalValue project bleedingEdge load.

may be 

#ConfigurationOfXYZ asClass

?

Re: [Pharo-project] Moment of fun

[stephane ducasse]

Neat!!!

> Hello.
> 
> (UpdatingStringMorph on: otherMorph selector: #position) openInWorld.
> 
> and then move otherMorph on screen
> 
> or
> 
> (UpdatingStringMorph on: otherMorph selector: #extent) openInWorld.
> 
> and then resize otherMorph
> 
> 2013/4/30 Stéphane Ducasse 
> Hi guys
> 
> I would like to build a small lectures based on all the small little crazy 
> expressions that we use
> like
> 
> StandardWindow allInstances do: #close.
> 
> or
> 
> myObject pointersTo
> 
> or
> 
> anObject become: String new.
> 
> Do you have some cool expressions to share with me.
> 
> Stef
> 

Re: [Pharo-project] How i can retrieve the global by its name?

[stephane ducasse]

+ 1
Let's propose a nice protocal and we use the rewrite tool for real!
This is also why I want 
crLog 
instead of Transcript show: 

Stef

> Hi, all
> 
> do not think that i am drunk or vent crazy, asking such silly
> question, which at best should be asked only by beginner :)
> 
> I know the answer:
> 
> Smalltalk at: #SomeName
> 
> or
> 
> Smalltalk globals at: #SomeName
> 
> what stroke me, just now, that both answers is wrong!
> 
> It should be:
> 
> #SomeName asGlobal
> 
> (or suggest more appropriate/precise method name for a symbol)
> 
> optionally, we could also have one, with handling absent case:
> 
> #SomeName asGlobalIfAbsent: []
> 
> same , but only if present:
> 
> #SomeName asGlobalIfPresent: [:global | ]
> 
> 
> Currently, there is 941 references to 'Smalltalk' global in my pharo image.
> If we introduce this convenience method, it will shrink this number
> considerably,
> not saying that code will be more elegant and concise compare:
> 
> (Smalltalk globals at: #Foo) doSomething
> 
> and
> 
> #Foo asGlobal doSomething
> 
> P.S. What really strikes me is why we don't have such method from very
> beginning,
> and instead refer to 'Smalltalk' all over the places.
> Some things are so deeply indoctrinated in our minds, that we don't
> even think that it can be different.
> 
> -- 
> Best regards,
> Igor Stasenko.
> 

Re: [Pharo-project] Moment of fun

[stephane ducasse]

On May 1, 2013, at 7:01 PM, Nicolas Cellier 
 wrote:

> Yes, great superpowers!
> A bit more lightweight and efficient than abort(); gdb myApp core
> 
> A small reminder for myself:
> 
> [ 
> (Delay forSeconds: 2 hours asSeconds) wait.
> WorldState addDeferredUIMessage: [ UIManager default inform: 'You''re 
> Smalltalking too much
> There are other nice things worth in life' ].
> ] fork

Excellent!
I added that one too :)

Stef

Re: [Pharo-project] Moment of fun

[stephane ducasse]

Yes! That's a great one :)
I added to my presentation. 
Stef

On May 1, 2013, at 6:38 PM, Camillo Bruni  wrote:

> I really love the use of fuel to serialize errors on the build server:
> -
> 
> [ 
>   "some code causing an error"
>Error signal
> ] on: Error do: [ :error |
>FLSerializer serialize: error toFileNamed: 'error.fuel' ]
> 
> -
> Then in a new image open a debugger on the serialized error:
> -
> 
> error := FLMaterializer materializeFromFileNamed: 'error.fuel'.
> error debug.
> 

Re: [Pharo-project] [update 3.0] #30080

[stephane ducasse]

>> 30080
>> -
>> 
>> 10461 Fixes for NewList
>>  https://pharo.fogbugz.com/f/cases/10461
>>  
>> 10432 Move API of Decompiler to Compiler facade
>>  https://pharo.fogbugz.com/f/cases/10432
>>  
>> 10465 Better syntax hilighting of start of existing identifier
>>  https://pharo.fogbugz.com/f/cases/10465
> 
> 
> that one too! :) I just noticed :)

:)

try it first :).
Ideally I would like to be able to express that the incomplete should just be 
italic of the 
plain one but this is not simple to express.

Stef

Re: [Pharo-project] froze image just

[stephane ducasse]

I created a slice then pressed save when clicking on the package cache and I 
was on the train my connection was flaky.
So I should retry to see if I cut internet I get the same behavior

Stef
On May 1, 2013, at 2:16 PM, Sven Van Caekenberghe  wrote:

> 
> On 01 May 2013, at 14:06, stephane ducasse  wrote:
> 
>> Yes :)
>> Same behavior here
>> On May 1, 2013, at 11:51 AM, Stephan Eggermont  wrote:
>> 
>>> Btw. Waiting for network timeout doesn't work. That is to say, waiting a 
>>> night is not long enough
>>> 
>>> Stephan
>>> 
>>> Verstuurd vanaf mijn iPhone
> 
> Well, Stephan or Stéphane, give us/me a repeatable use case on Mac OS X 
> (preferably using latest VM and 2.0) where you are sure a network timeout 
> should occur and it doesn't.  It has to include a description of what is 
> precisely 'no network'.
> 
> I know it is not perfect, but to make any progress we need something concrete.
> 
> Sven
> 
> 
> 

Re: [Pharo-project] SUnit design question

[stephane ducasse]

Indeed it would be nice to have.

On May 1, 2013, at 11:29 AM, Camillo Bruni  wrote:

> I'm not sure if I asked that question before, but why is there no
> dedicated TestRunner model in SUnit? (detailed question further down)
> 
> There is a TestRunner but that is clearly a UI part.
> 
> We have right now 2 places in the system where that would come in
> handy: HDTestReport and the CommandLineTestRunner.
> 
> Both places modify the output of the test runner, so to say instrument
> the test runs.
> 
> see 
> http://stackoverflow.com/questions/16315726/how-do-i-instrument-test-runners-in-sunit

Re: [Pharo-project] froze image just

[stephane ducasse]

Yes :)
Same behavior here
On May 1, 2013, at 11:51 AM, Stephan Eggermont  wrote:

> Btw. Waiting for network timeout doesn't work. That is to say, waiting a 
> night is not long enough
> 
> Stephan
> 
> Verstuurd vanaf mijn iPhone

Re: [Pharo-project] date and time delays

[stephane ducasse]

On May 1, 2013, at 1:33 PM, Camillo Bruni  wrote:

> Igor,
> 
> How far is the fix, can I download it somewhere and test it?

the changes of nicolas are nice and we should integrate them.

> 
> I still think I get very strange side-effects from the waiting
> delay processes :P
> 

Re: [Pharo-project] Moment of fun

[stephane ducasse]

I was more thinking in something useful :)


On Apr 30, 2013, at 11:07 PM, Marcus Denker  wrote:

> 
> On Apr 30, 2013, at 10:56 PM, Stéphane Ducasse  
> wrote:
> 
>> 
>> 
>>  anObject become: String new.
>> 
> 
> 
> for become: related teaching, this is fun:
> 
> magic
>   #thisIsMagiC  isSymbol ifTrue: [#thisIsMagiC become: #(0)].
>   #thisIsMagiC at: 1 put: (#thisIsMagiC at: 1) +1.
>   ^#thisIsMagiC first.
> 
> 

Re: [Pharo-project] froze image just

[stephane ducasse]

On May 1, 2013, at 2:31 AM, Igor Stasenko  wrote:

> On 30 April 2013 22:44, Stéphane Ducasse  wrote:
>> trying to publish a slice on my harddisc without network….
>> and I could not interrupt anything.
>> No cmd+. no interdiction sign did anything :(
>> 
>> So is it normal?
>> Not being able to interrupt something is a pain.
>> 
>> stef
> 
> the problem stems from the point that when you press cmd+.
> an interrupt process logic looking for some other active process
> to stop it..
> now since UI process blocked by semaphore, as well as rest,
> it finds nothing to interrupt and ignores it :)
> 
> i think we should think about it, like putting synthesized context
> with '1halt', to UI process, so when it will awake, it will be halted.
> 
> Or... if interrupt handler found nothing,  then always spawn new UI process
> opening debugger on old one.

Yes igor because the experience is not good.

I added 
https://pharo.fogbugz.com/default.asp?10466
so that we do not forget it

Stef

> 
> -- 
> Best regards,
> Igor Stasenko.
> 

Re: [Pharo-project] 512 MB is not that much (Windows limit) WAS: RE: Opal Decompiler status

[stephane ducasse]

Hi 

I think that you have some points :)
Indeed for Moose we should pay attention because we often deploy on windows.


> I wouldn't oppose to having the sources (or the AST or whatever ;-) in 
> [object-]memory, although retaining the option of _also_ still writing all 
> the changes into an external changelog (in case of VM, or the less rare case, 
> Windows crashes).
> 
> But no, we don't have "enough memory" (although now is perhaps the time to 
> announce that "64GB ought to be enough for anybody" ;-))).
> 
>> (the $25 Raspi comes with 256MB, the $35 with 512MB.)
> 
> Incidentally, ~512 MB is the max you can get on Windows (otherwise crash 
> after an ugly ~ 30 sec freeze; I checked sometime around the 2.0 release), 
> and this is not enough for some applications.
> 
> The Moose people complained a few years back (unable to, on Windows, load a 
> large but otherwise fine image saved on Mac), the only solution offered was 
> "change a #DEFINE or makefile or something like that and rebuild the VM, then 
> pray it works".
> 
> Currently I avoid using Pharo in case I even suspect the app might come 
> anywhere near that limit (to avoid nasty surprises / hasty rewrites later).
> 
> Only problems I've heard of concerning DLL's mapped at "weird" offsets in 
> address space (this was cited as reason for the memory limit) were related to 
> trojan horses / stealth viruses tampering with system, and anti-virus / 
> anti-malware SW doing basically the same ;-))) Or something getting loaded 
> really early, geting the DLL - in this case it was kernel.dll - mapped at 
> unusual offset which then got re-used for all other applications, but this 
> was mentioned in context where in the end they were unable to allocate 
> sufficiently large block of contiguous memory because something was siting in 
> the middle of address space - and i _think_ think it was concerning LuaJIT.
> 
> Would it be possible to prod Jenkins to produce (additional) windows builds 
> with the limit lifted (or set to 2 GB; optionally perhaps a 1GB build) ? So 
> interested testers could try them - as the problem was reported as only 
> manifesting on some comps., while others ran completely fine. I think 
> somebody mentioned that thanks to Jenkins it is/will be a childs play to 
> add/clone another build(s).
yes this is a good idea.


> IMO it would be great to do some larger-scale testing whether this problem 
> still manifests itself and if so whether it could be worked around, or traced 
> to whatever fucks windows up so they load DLL into the middle of the address 
> space ... And lot more people would participate if "build your own VM" would 
> be an optional step (I know, it's not that hard, and setting up mingw or msvc 
> is not that hard either, but it takes a few hours to get it all up & running).
> 
> I've "played with" (used to solve actual problems / write applications which 
> are used in production, i just got to choose the language ...) a LOT of prog. 
> langs, and I don't remember this problem mentioned elsewhere.

Clearly we pay the lag of not moving.
> 
> For example SBCL, Smalltalk/X, Factor, SWI Prolog, Haskell (a few very 
> different - on the inside as much as on the outside - examples) are able to 
> utilise the whole 2GB (if your windows are configured to the standard 2GB/2GB 
> user/kernel space split). Even that abomination that starts with letter J and 
> is touted as The_Only_VM_and_Language is able to utilize ~1.5 GB on a 32bit 
> system.

Yes they probably put also lot of money on the table.

> I'd be able & willing to test on XP/32 and Win7/32+64. I can even test on 
> ~300 machines, although there are only a few hardware configurations, and all 
> are installed according to the same template and mainly use the same software 
> and antivirus. So it's probably not nearly as interesting as 30 totally 
> random machines ...
> 
> Anybody else thinks this sounds like a good idea ? 

Yes

> 
> -Original Message-
> From: pharo-project-boun...@lists.gforge.inria.fr 
> [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Marcus 
> Denker
> Sent: Saturday, April 27, 2013 7:08 PM
> To: Pharo-project@lists.gforge.inria.fr
> Subject: Re: [Pharo-project] Opal Decompiler status
> 
> 
> On Apr 27, 2013, at 6:42 PM, Nicolas Cellier 
>  wrote:
> 
>> Thanks Marcus.
>> I'm among the skepticals concerning the AST, but I'd like to be proven 
>> wrong, because AST level would certainly simplify things a lot.
>> My main reserve is that interruption can occur at BC level, so for debugging 
>> purpose, what are your plans?
>> Will you move the PC at some AST node boundary (if it is possible given side 
>> effects of some BC)?
>> 
> For the Debugger, everything stays as it is (until Pharo 4 or so). if you 
> look at it, the current Debugger never decompiles if there is source 
> available.
> It *compiles* to get 
>   -> the mapping BC -> text 
>   -> the information how temporary variables in the byte code ar

Re: [Pharo-project] dynamic spec contents

[stephane ducasse]

ben 

we should add that to the spec chapter.
Can you log it somewhere and one day :) we pair write it :).

Stef

On Apr 30, 2013, at 4:20 PM, Benjamin  
wrote:

> I just added two new examples in Spec-Examples-PolyWidgets 
> (https://pharo.fogbugz.com/default.asp?10458)
> 
> It should be soon in Pharo ^^
> 
> Ben
> 
> On Apr 30, 2013, at 2:27 PM, Camillo Bruni  wrote:
> 
>> Clement and I are working on the new Inspectors/Debuggers and we would like 
>> yo
>> dynamically change spec widgets on the fly.
>> 
>> Is there an example of that somewhere?
> 

Re: [Pharo-project] about Pharo 3.0 :)

[stephane ducasse]

imagine soon athens :)

Stef

On Apr 30, 2013, at 1:06 PM, Igor Stasenko  wrote:

> 
> 
> On 30 April 2013 07:50, Stéphane Ducasse  wrote:
> Hi guys
> 
> I thought that Pharo 20 got a lot of improvements but when I see Pharo 30, it 
> feels like Pharo 30 is already a big step
> forward. This is really positive energy. When fernando will arrive we will 
> move some efforts to Morphic
> so thanks you all for this cool feeling.
> 
> Stef
> 
> Yes, Opal opened doors for so many improvements...
> 
> -- 
> Best regards,
> Igor Stasenko.

Re: [Pharo-project] rubric performace

[stephane ducasse]

tx!

On Apr 29, 2013, at 9:24 PM, Tudor Girba  wrote:

> Hi,
> 
> I tried but could not :(. I tried multiple times to load the file and go 
> around the "out of memory" limitation and then at some random point, Pharo 
> crashed. I was on Mac when I did the experiment. If I get more info I will 
> let you know.
> 
> Doru
> 
> 
> On Apr 29, 2013, at 8:44 PM, stephane ducasse  
> wrote:
> 
>> doru can you reproduce your crash?
>> Because igor asked and I did not see your answer.
>> 
>> Stef
>> 
>> On Apr 25, 2013, at 12:03 AM, Tudor Girba  wrote:
>> 
>>> Hi,
>>> 
>>> I did a little experiment to check the performance of Rubric when dealing 
>>> with large content. And by large, I mean 45 MB  or about 15 million lines 
>>> of text.
>>> 
>>> I opened the file in several other editors:
>>> - TextMate: 10s + the text is wrapped and can be browsed smoothly
>>> - Sublime Text 2: 10s + the text is wrapped and can be browsed smoothly
>>> - Eclipse: 5s + browsing is very slow (so it is basically useless)
>>> 
>>> How did Rubric perform:
>>> - When opened with unwrapped lines: 33s + the text can be browsed smoothly
>>> - When opened with wrapped lines -> Pharo crashed :(
>>> 
>>> In any case, I think being 3 times slower (even if without wrapping) than 
>>> TextMate is highly exciting. Great job Alain. 
>>> 
>>> If you want to reproduce the experiment, here is the Smalltalk snippet I 
>>> used:
>>> 
>>> ---
>>> Gofer new 
>>> smalltalkhubUser: 'AlainPlantec' project: 'Rubric';
>>> package: 'Rubric-AlainPlantec.26';
>>> load.
>>> 
>>> [
>>> contents := ((FileSystem disk workingDirectory / 'src' / 'ArgoUML-0-34' 
>>> / 'output.mse') readStreamDo: #contents).
>>>  (RubLipsumBasicExample 
>>> windowWithScrolledText: (
>>> RubLipsumBasicExample new
>>> string: contents; 
>>> newScrolledTextNotWrapped))
>>> openInWorld
>>>  ] timeToRun 
>>> ---
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> --
>>> www.tudorgirba.com
>>> 
>>> "What we can governs what we wish."
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> --
> www.tudorgirba.com
> 
> "From an abstract enough point of view, any two things are similar."
> 
> 
> 
> 

Re: [Pharo-project] rubric performace

[stephane ducasse]

doru can you reproduce your crash?
Because igor asked and I did not see your answer.

Stef

On Apr 25, 2013, at 12:03 AM, Tudor Girba  wrote:

> Hi,
> 
> I did a little experiment to check the performance of Rubric when dealing 
> with large content. And by large, I mean 45 MB  or about 15 million lines of 
> text.
> 
> I opened the file in several other editors:
> - TextMate: 10s + the text is wrapped and can be browsed smoothly
> - Sublime Text 2: 10s + the text is wrapped and can be browsed smoothly
> - Eclipse: 5s + browsing is very slow (so it is basically useless)
> 
> How did Rubric perform:
> - When opened with unwrapped lines: 33s + the text can be browsed smoothly
> - When opened with wrapped lines -> Pharo crashed :(
> 
> In any case, I think being 3 times slower (even if without wrapping) than 
> TextMate is highly exciting. Great job Alain. 
> 
> If you want to reproduce the experiment, here is the Smalltalk snippet I used:
> 
> ---
> Gofer new 
>   smalltalkhubUser: 'AlainPlantec' project: 'Rubric';
>   package: 'Rubric-AlainPlantec.26';
>   load.
> 
> [
>   contents := ((FileSystem disk workingDirectory / 'src' / 'ArgoUML-0-34' 
> / 'output.mse') readStreamDo: #contents).
>(RubLipsumBasicExample 
>   windowWithScrolledText: (
>   RubLipsumBasicExample new
>   string: contents; 
>   newScrolledTextNotWrapped))
>   openInWorld
>] timeToRun 
> ---
> 
> Cheers,
> Doru
> 
> --
> www.tudorgirba.com
> 
> "What we can governs what we wish."
> 
> 
> 
> 

Re: [Pharo-project] Generalizing Keymapping idea

[stephane ducasse]

On Apr 29, 2013, at 9:24 AM, Denis Kudriashov  wrote:

> Hello.
> 
> Do you think about generalizing Keymapping idea on any event combinations 
> (not just keyboard)? 
> So we can write code like
> 
> morph on: Mouse click ctrl do: []
> morph on: $a click ctrl do: []
> morph on: Mouse move shift + $b do: []
> morph on: Gesture cicle shift + $x do: [] 

I like the idea but I would really like that we do not overload on:do: 

> I think with such approach we can remove all morph overrides like 
> #mouseDown:, #mouseUp. And it will big cleanup of morphic code. You know how 
> many equal methods we have for each kind of event (handlesMouseDown:, 
> handleMouseDown:, mouseDown: , etc).
> 
> Best regards,
> Denis

Re: [Pharo-project] [update 3.0] #30069

[stephane ducasse]

On Apr 28, 2013, at 11:33 PM, Sean P. DeNigris  wrote:

> stephane ducasse wrote
>> We should really ask nicolas to check why the diff is broken
> 
> I mentioned a few times that it seems that it fails when none of the package
> version's ancestors are present on stub. e.g. from
> http://forum.world.st/update-3-0-30024-td4680178.html,
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Layout-MarcusDenker.39
> works but the others do not.

I really have to check because ideally I would like to send them to the list,

> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/update-3-0-30069-tp4684135p4684190.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 

Re: [Pharo-project] Trying to understand DateAndTime

[stephane ducasse]

On Apr 28, 2013, at 11:19 PM, Nicolas Cellier 
 wrote:

> \\ returns a positive remainder.
> example:
>  -1 \\ 86400 -> 86399
>  -1 // 86400 -> -1

Yes I saw that and now I realized I understand it. 
But funnily I did not notice the difference between the use of // and \\ 
> So the jdn is decremented and seconds are correctly normalized.
> 
> 
> 
> 2013/4/28 stephane ducasse 
> Nicolas
> 
> I read all the slice and I like it (even if they are place where I do not get 
> fully it :).
> I'm dead. So may be this is obvious but I do not understand the or: logic
> If the seconds is negative I do not understand what is happening.
> 
> 
> normalizeSecondsAndNanos
>   (NanosInSecond <= nanos or: [ nanos < 0 ])
>   ifTrue: [
>   seconds := seconds + (nanos // NanosInSecond).
>   nanos := nanos \\ NanosInSecond].
>   (SecondsInDay <= seconds or: [ seconds < 0 ])
>   ifTrue: [
>   julianDayNumber := julianDayNumber + (seconds // 
> SecondsInDay).
>   seconds := seconds \\ SecondsInDay].
> 
> Stef
> 
> 
> 
> On Apr 28, 2013, at 7:03 PM, Nicolas Cellier 
>  wrote:
> 
>> Yes, this was valid when jdn, seconds and nanos where maintained in local 
>> time...
>> 
>> 
>> 2013/4/28 Paul DeBruicker 
>> Nicolas Cellier wrote
>> > What I find strange:
>> > - #hash uses the offset... Why ???
>> 
>> Maybe because of this:
>> http://forum.world.st/true-hash-tp4621497p4624623.html
>> 
>> which you fixed here:
>> 
>> 
>> See http://forum.world.st/true-hash-tp4621497p4624706.html
>> 
>> 
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://forum.world.st/Trying-to-understand-DateAndTime-tp4683997p4684123.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>> 
>> 
> 
> 

Re: [Pharo-project] Trying to understand DateAndTime

[stephane ducasse]

Nicolas

I read all the slice and I like it (even if they are place where I do not get 
fully it :).
I'm dead. So may be this is obvious but I do not understand the or: logic
If the seconds is negative I do not understand what is happening.


normalizeSecondsAndNanos
(NanosInSecond <= nanos or: [ nanos < 0 ])
ifTrue: [
seconds := seconds + (nanos // NanosInSecond).
nanos := nanos \\ NanosInSecond].
(SecondsInDay <= seconds or: [ seconds < 0 ])
ifTrue: [
julianDayNumber := julianDayNumber + (seconds // 
SecondsInDay).
seconds := seconds \\ SecondsInDay].

Stef



On Apr 28, 2013, at 7:03 PM, Nicolas Cellier 
 wrote:

> Yes, this was valid when jdn, seconds and nanos where maintained in local 
> time...
> 
> 
> 2013/4/28 Paul DeBruicker 
> Nicolas Cellier wrote
> > What I find strange:
> > - #hash uses the offset... Why ???
> 
> Maybe because of this:
> http://forum.world.st/true-hash-tp4621497p4624623.html
> 
> which you fixed here:
> 
> 
> See http://forum.world.st/true-hash-tp4621497p4624706.html
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Trying-to-understand-DateAndTime-tp4683997p4684123.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 
> 

Re: [Pharo-project] [Ann] TxText. New text editor done!

[stephane ducasse]

On Apr 28, 2013, at 7:47 PM, Denis Kudriashov  wrote:

> I upload new version 0.7:
> - clipboard operations
> - more navigation shortcuts
> - fixed bugs when editing text from start or end text positions
> - optimized text drawing to draw only visible lines
> - optimized TxInterval>>contains:. So now #newTextContents: works on big 
> strings
> 
> With this version I again investigate beautiful morphic events code (you 
> should install slice 10427).
> I add shortcuts "Character end ctrl" and "Character home ctrl" to move cursor 
> at text end and start. And it was not work.
> I debug what happens and KeyboardEvent from "Character home ctrl" was printed 
> as ctrl+d. What's the crap!
> Ok I found this code:
> 
> modifiedCharacter
> self flag: #hack.
> "Hack me.  When Ctrl is pressed, the key ascii value is not right and we 
> have to do something ugly"
> ^(self controlKeyPressed and: [ (#(MacOSX Windows) includes: Smalltalk os 
> current platformFamily) and: [ keyValue <= 26 ]])
> ifTrue: [ (self keyValue + $a asciiValue - 1) asCharacter ]
> ifFalse: [ self keyCharacter ]

horrible!
As igor said this is not that we do not want but we have to pay attention to 
our ressources.

> 
> I don't know why such complicated code needed but with only "^self 
> keyCharacter" you will replace many standart shortcuts with some random 
> behaviour.
> So I just extract special logic to method and put here special checking for 
> home and end characters:
> 
> KeyboardEvent>>hasSpecialCTRLKeyValue
> "
> 4 - Character end
> 1 - Character home
> "
> 
> ^ self controlKeyPressed and: [ keyValue <= 26 & (keyValue ~= 4) & 
> (keyValue ~= 1) ]
> 
> And I remove dublication in printing keyboard event.
> 
> Slice with fix here https://pharo.fogbugz.com/default.asp?10427. Should I put 
> it at configuration dependency?
> 
> I read about new events system at pharo vision. Is new system will remove 
> such hacks?
> 
> 

Re: [Pharo-project] [update 3.0] #30069

[stephane ducasse]

We should really ask nicolas to check why the diff is broken because it was 
really nice to be able to follow changes.


Stef
On Apr 28, 2013, at 7:35 PM, Marcus Denker  wrote:

> 30069
> -
> 
> 10423 simplify #firstPrecodeCommentFor:
>   https://pharo.fogbugz.com/f/cases/10423
>   
> 10426 move #parseSelector to Compiler
>   https://pharo.fogbugz.com/f/cases/10426
> 
> Diff information:
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Traits-MarcusDenker.481
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Tools-MarcusDenker.1085
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/System-Changes-MarcusDenker.200
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/System-FilePackage-MarcusDenker.76
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/NautilusRefactoring-MarcusDenker.87
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1389
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/DebuggerModel-MarcusDenker.29
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Compiler-MarcusDenker.407
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/AST-Core-MarcusDenker.138
> 
> 

Re: [Pharo-project] Trying to understand DateAndTime

[stephane ducasse]

Igor 
could you review the changes of nicolas - I was planning to do it now but I'm 
dead so I will do it but with half of my mind.
Because may be this is better to integrate his changes then do another pass 
friday.

Stef

On Apr 28, 2013, at 3:38 PM, Igor Stasenko  wrote:

> On 28 April 2013 08:41, stephane ducasse  wrote:
>> thanks a lot!
>> Friday we have an official sprint so I'm sure that this issue will be
>> addressed.
>> 
> yes. and i hope i will put my changes into the soup as well.
> (i did not published them, and some bits are unfinished).
> 
>> Stef
>> 
>> See https://pharo.fogbugz.com/default.asp?10425# and corresponding SLICE in
>> 3.0 inbox
>> Note: I don't know what is the policy with the labels/states of these bug
>> tracker, and it rather bothers me, but the SLICE is ready for tests/reviews.
>> 
>> 
>> 2013/4/27 Nicolas Cellier 
>>> 
>>> There is more:
>>> 
>>> 1) hasEqualTicks: use julianDayNumber instead of julianDayNumberUTC
>>> 2) (Time dateAndTime now) interprets the (Time localSeconds) which are
>>> from the wrong primitive (seconds ellapsed since squeak epoch translated to
>>> local time) as seconds ellapsed since squeak Epoch (UTC time).
>>> 
>>> We should really ban the old primitive 137 and only use the new one (240
>>> which works with UTC microseconds).
>>> 
>>> I think Camillo did a good job, but he stopped cleaning too soon.
>>> Ah, young guys are so impatient to invent the future ;)
>>> 
>>> 
>>> 2013/4/27 stephane ducasse 
>>>> 
>>>> 
>>>> On Apr 27, 2013, at 6:33 PM, Nicolas Cellier
>>>>  wrote:
>>>> 
>>>>> Since DateAndTime comment is out of date (sic !) and current
>>>>> implementation seems not free of bug, here is an effort to summarize and
>>>>> understand the whole thing, let's call this a review.
>>>> 
>>>> Thanks this is a great initiative!
>>>> 
>>>> 
>>>>> Please tell me where my interpretations are wrong.
>>>>> 
>>>>> 1) The DateAndTime is stored internally as
>>>>> - a point in UTC time (julianDayNumber, seconds, nanos)
>>>>> - an offset from UTC (a Duration) denoting the local time zone
>>>>> 
>>>>> 2) The ticks method returns the UTC part {julianDayNumber. seconds.
>>>>> nanos}
>>>>> 
>>>>> 3) DateAndTime print themselves in local time using the offset
>>>>> 
>>>>> 4) other methods (with some exceptions) return the local dateAndTime
>>>>> parts (year month day hours minutes seconds)
>>>>> 
>>>>> Exceptions are:
>>>>> - secondsSinceMidnight (which should be renamed secondsSinceMidnightUTC
>>>>> IMO, even if the method is classified private)
>>>>> - julianDayNumberUTC as the name tells
>>>>> 
>>>>> So far so good (but secondsSinceMidnight which is error prone)
>>>>> 
>>>>> What I find strange:
>>>>> - #hash uses the offset... Why ???
>>>>> 
>>>>> d1 := DateAndTime now.
>>>>> d2 := d1 offset: d1 offset + 1 hours.
>>>>> {
>>>>>d1 = d2.
>>>>>d1 hash = d2 hash.
>>>>> }
>>>>> gives  #(true false), a clue?
>>>>> 
>>>>> - #< compares julianDayNumber (the UTC inst. var.) with otherDate
>>>>> julianDayNumber (with otherDate local offset) which seems wrong, it should
>>>>> better use julianDayNumberUTC or (normalized) ticks.
>>>>> 
>>>>> - #= could be simplified and accelerated if using #hasEqualTicks: (if
>>>>> the ticks are correctly normalized though which would be the case since
>>>>> #ticks:offset: does, unfortunately #setJdn:seconds:nanos:offset: does 
>>>>> not).
>>>>> 
>>>>> Some senders of #setJdn:seconds:nanos:offset: don't normalize the
>>>>> day/seconds/nanos, though it should be their responsibility (DateAndTime
>>>>> todayAtMilliSeconds: xxx) (DateAndTime todayAtNanoSeconds: xxx), not
>>>>> counting year:month:day:hour:minute:second:nanoSecond:offset: which does 
>>>>> not
>>>>> either (many senders...).
>>>>> Maybe we should better let the normalization responsibility to
>>>>> #setJdn:seconds:nanos:offset:.
>>>>> 
>>>>> It remain to analyze the conversion protocol (asYear etc...) which
>>>>> seems to use the local time year, but I don't understand the whole 
>>>>> Timespan
>>>>> thing right now (why DateAndTime now asYear starts now, and not on january
>>>>> 1st?).
>>>>> 
>>>>> Nicolas
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko.
> 

Re: [Pharo-project] Why keymap modifiers change receiver instead of return new instance?

[stephane ducasse]

> Hello.
> 
> I found this:
> 
> shortcut := $a ctrl.
> self assert: shortcut == shortcut shift
> 
> Why modifiers change receiver state instead of create new instance?

I can understand since they modify the shortcut.

> To me it is very bad unexpected behaviour.

Why?

> 
> There is another example:
> 
> shortcut := $a ctrl.
> self assert: shortcut == (KMModifier shift + shortcut)
> 
> Yes. Such operation modified argument of message #+. What the crapp! Why it 
> not returns new instance?
> 
> I hope you agree to change this behaviour
> 
> 

Re: [Pharo-project] [Ann] TxText. New text editor done!

[stephane ducasse]

> Hi denis
> 
> Alain is gone on vacation but it told me that if you code scale he will throw 
> away what he did :)
> May be the decorators that alain wrote can be merged.
> In any case this is excellent to get a better system.
> 
> Yes. This is why I work on this project. 
> But my first proposals was not make editor for large text. I actually not 
> think about it at all. 
> My main idea is make clean and extendible text editor. So anybody can 
> understand how layout built, where text insertion happens, how it processed, 
> how cursor wors and etc. I want text editor which is not required hacks to 
> simple tasks like allow only numbers, hide cursor, disable text selection, 
> make masked input, make smart completions and etc.

Yes I like the idea.

Now if our clients cannot use our tools then we will survive long :).
And this is better for Pharo that we get rich :)

Stef

Re: [Pharo-project] Trying to understand DateAndTime

[stephane ducasse]

thanks a lot!
Friday we have an official sprint so I'm sure that this issue will be 
addressed. 

Stef

> See https://pharo.fogbugz.com/default.asp?10425# and corresponding SLICE in 
> 3.0 inbox
> Note: I don't know what is the policy with the labels/states of these bug 
> tracker, and it rather bothers me, but the SLICE is ready for tests/reviews.
> 
> 
> 2013/4/27 Nicolas Cellier 
> There is more:
> 
> 1) hasEqualTicks: use julianDayNumber instead of julianDayNumberUTC
> 2) (Time dateAndTime now) interprets the (Time localSeconds) which are from 
> the wrong primitive (seconds ellapsed since squeak epoch translated to local 
> time) as seconds ellapsed since squeak Epoch (UTC time).
> 
> We should really ban the old primitive 137 and only use the new one (240 
> which works with UTC microseconds).
> 
> I think Camillo did a good job, but he stopped cleaning too soon.
> Ah, young guys are so impatient to invent the future ;)
> 
> 
> 2013/4/27 stephane ducasse 
> 
> On Apr 27, 2013, at 6:33 PM, Nicolas Cellier 
>  wrote:
> 
> > Since DateAndTime comment is out of date (sic !) and current implementation 
> > seems not free of bug, here is an effort to summarize and understand the 
> > whole thing, let's call this a review.
> 
> Thanks this is a great initiative!
> 
> 
> > Please tell me where my interpretations are wrong.
> >
> > 1) The DateAndTime is stored internally as
> > - a point in UTC time (julianDayNumber, seconds, nanos)
> > - an offset from UTC (a Duration) denoting the local time zone
> >
> > 2) The ticks method returns the UTC part {julianDayNumber. seconds. nanos}
> >
> > 3) DateAndTime print themselves in local time using the offset
> >
> > 4) other methods (with some exceptions) return the local dateAndTime parts 
> > (year month day hours minutes seconds)
> >
> > Exceptions are:
> > - secondsSinceMidnight (which should be renamed secondsSinceMidnightUTC 
> > IMO, even if the method is classified private)
> > - julianDayNumberUTC as the name tells
> >
> > So far so good (but secondsSinceMidnight which is error prone)
> >
> > What I find strange:
> > - #hash uses the offset... Why ???
> >
> > d1 := DateAndTime now.
> > d2 := d1 offset: d1 offset + 1 hours.
> > {
> > d1 = d2.
> > d1 hash = d2 hash.
> > }
> > gives  #(true false), a clue?
> >
> > - #< compares julianDayNumber (the UTC inst. var.) with otherDate 
> > julianDayNumber (with otherDate local offset) which seems wrong, it should 
> > better use julianDayNumberUTC or (normalized) ticks.
> >
> > - #= could be simplified and accelerated if using #hasEqualTicks: (if the 
> > ticks are correctly normalized though which would be the case since 
> > #ticks:offset: does, unfortunately #setJdn:seconds:nanos:offset: does not).
> >
> > Some senders of #setJdn:seconds:nanos:offset: don't normalize the 
> > day/seconds/nanos, though it should be their responsibility (DateAndTime 
> > todayAtMilliSeconds: xxx) (DateAndTime todayAtNanoSeconds: xxx), not 
> > counting year:month:day:hour:minute:second:nanoSecond:offset: which does 
> > not either (many senders...).
> > Maybe we should better let the normalization responsibility to 
> > #setJdn:seconds:nanos:offset:.
> >
> > It remain to analyze the conversion protocol (asYear etc...) which seems to 
> > use the local time year, but I don't understand the whole Timespan thing 
> > right now (why DateAndTime now asYear starts now, and not on january 1st?).
> >
> > Nicolas
> >
> >
> 
> 
> 
> 

Re: [Pharo-project] Opal Decompiler status

[stephane ducasse]

On Apr 27, 2013, at 8:00 PM, Nicolas Cellier 
 wrote:

> Right, if you embed source along with CompiledMethod (to handle the case when 
> the CompiledMethod has been replaced but one of its block of code is still 
> used), then you don't need Decompiler in the first place.
> 
> Nonetheless, I would remove the .sources but not the .changes. The .changes 
> is not only a source code repository (that feature can go away if you want), 
> it's before all a change log, an insurance to retrieve some change when 
> everything else failed (image crashed or worse corrupted image won't 
> restart). You can make the insurance optional if you want, but please 
> continue to provide an equivalent service. A change file is the most simple 
> thing that could possibly work IMO. But this is another thread.

I agree, we have been discussing (and I do not like much the idea to have the 
changes inside the image as objects because now
we have a  nice literal object parser/writer and making sure that we can never 
lose source code is cool). 
In any case we are working on a new change format recording more high-level 
entity (such refactoring). We looked again
at the model that veronica did, and Ezequiel and we looked again at 
DeltaStreams. We should digest all that and come up with a new alternate 
changes model file. I was about to contact goran to see if he wants to 
participate/ read a paper but we should write the paper first :)

> Concerning the temp mapping, I agree, we should not compete with Eliot, he's 
> very tough at tedious tasks, our only weapon is lazyness, lazyness often 
> leads to efficiency ;) I'm curious to check how you handled this complex part 
> with AST when I'll have more time to dig.
> 
> 
> 2013/4/27 Marcus Denker 
> 
> On Apr 27, 2013, at 6:42 PM, Nicolas Cellier 
>  wrote:
> 
> > Thanks Marcus.
> > I'm among the skepticals concerning the AST, but I'd like to be proven 
> > wrong, because AST level would certainly simplify things a lot.
> > My main reserve is that interruption can occur at BC level, so for 
> > debugging purpose, what are your plans?
> > Will you move the PC at some AST node boundary (if it is possible given 
> > side effects of some BC)?
> >
> For the Debugger, everything stays as it is (until Pharo 4 or so)… if you 
> look at it, the current Debugger never decompiles if there is source 
> available.
> It *compiles* to get
> -> the mapping BC -> text
> -> the information how temporary variables in the byte code are 
> actually related to temps in the source.
> (this is very complex, temps can be e.g. stored on the heap if 
> they are written to in a closure, and when they are just
>  read they have a different offset in each closure they are in. 
> Conversely, some temps  in the byte code are used
> to store the array that hold the variables that are on the heap…)
> 
> The old compiler recorded mappings while compiling that where encoded… quite 
> complex, at least for my tiny brain.
> 
> So the new just keeps the AST annotated with all the needed infos, this is 
> much easier to debug (and we do have the
> memory these days, and as we cache the AST, it's even fast).
> 
> So the debugger needs the compiler. The decompiler now exists just to make 
> text so that we can call the compiler
> in the case there is no .sources. The debugger *always* compiles to get the 
> mappings, as soon as there is source code
> the decompiler will never be used. (and even if the decompiler is used, the 
> compiler is called right after on it's results so
> one can record the mappings).
> 
> So if you make sure there is always source-code (or a representation with the 
> right amount of meta data), you don't need the decompiler.
> 
> So at the start it will be the  source code. And yes, this takes memory. But  
> we are in 2013 and if we have one thing than it's memory.
> (the $25 Raspi comes with 256MB, the $35 with 512MB…).
> 
> We could have shipped 2.0 with 8MB of useless Monticello meta data and nobody 
> would have even realized it. (like we
> have now megabytes of fonts in the image…). Yet the source is special… I 
> really wonder why.
> 
> (And yes, there should be solutions to not need unused data in main memory 
> and solutions to share across multiple images
> data that is the same… but for all kinds of stuff, not just source code).
> 
> Marcus
> 

Re: [Pharo-project] Opal Decompiler status

[stephane ducasse]

> Thanks Marcus.
> I'm among the skepticals concerning the AST, but I'd like to be proven wrong, 
> because AST level would certainly simplify things a lot.

Me too :)
But marcus knows it since the end of his PhD :D. This is why I really want to 
see AST compression. 

> My main reserve is that interruption can occur at BC level, so for debugging 
> purpose, what are your plans?
> Will you move the PC at some AST node boundary (if it is possible given side 
> effects of some BC)?
> 
> 
> 2013/4/27 Marcus Denker 
> 
> On Apr 27, 2013, at 5:59 PM, Marcus Denker  wrote:.
> >
> >> Could we have a primer on what remains to do on the Opal front?
> >>
> >
> >
> > -> debug BC-IR->AST->text mapping more (lots of it working already)
> > -> debug temp variable lookup in optimized blocks in the debugger (almost 
> > there, too)
> > -> Go through all the test for the old Compiler and port them to the new.
> > -> Better compiler API and refactor the whole system to use it
> >   (but keep a backward compatible API at least to some extend)
> 
> 
> All the TODOs are in the bug tracker, Project "Compiler (Opal)".
> 
> There are right now 29 Issues.
> 
> Marcus
> 

Re: [Pharo-project] Opal Decompiler status

[stephane ducasse]

But I would like that we finish first all the other cool tasks for 3.0 before 
opening something new.
Finishing is difficult so let us focus on it.

Stef

On Apr 27, 2013, at 8:13 PM, Marcus Denker  wrote:

> 
> On Apr 27, 2013, at 8:01 PM, Nicolas Cellier 
>  wrote:
> 
>> Right, if you embed source along with CompiledMethod (to handle the case 
>> when the CompiledMethod has been replaced but one of its block of code is 
>> still used), then you don't need Decompiler in the first place.
>> 
>> Nonetheless, I would remove the .sources but not the .changes. The .changes 
>> is not only a source code repository (that feature can go away if you want), 
>> it's before all a change log, an insurance to retrieve some change when 
>> everything else failed (image crashed or worse corrupted image won't 
>> restart). You can make the insurance optional if you want, but please 
>> continue to provide an equivalent service. A change file is the most simple 
>> thing that could possibly work IMO. But this is another thread.
>> 
> Yes, we have a solution for that…
> 
> the thing is that the .changes has 3 roles. In the 1978, it was very clever 
> to design one extremely memory efficient mechanism to kill all three:
> 
> 1) keep a history of all the accepted method sources in the image (see 
> "versions")
> 2) store the code on disk efficiently with no duplications (They counted 
> those extremely expensive disks in the one-diget Megabytes back then).
> 3) have transaction log for the source code in case of image crash.
> 
> Now today, we can solve all three using three different methods:
> 
> 1) we will just keep the accepted methods in memory until you commit to 
> monticello/git 
>   (in case of git one can even commit all the intermediates, for MC one 
> would just commit the latest).
>after the in-image history is pruned (like it is now eventually anyway 
> when you start with a fresh image).
> 2) We don't need to store the *current* version on disk. Compressed in 
> memory. Yes, that is what progress brings…
> 3) Disk space is so cheap it is not even funny.
>   -> we will just have a dedicated log. And we can even store Objects… 
> 
> And then we can leverage the extreme simplicity of the resulting scheme.. 
> simplicity is an amazing thing. (Or the
> contrary: I think people understate the effects of complexity).
> 
>   Marcus

Re: [Pharo-project] Trying to understand DateAndTime

[stephane ducasse]

On Apr 27, 2013, at 6:33 PM, Nicolas Cellier 
 wrote:

> Since DateAndTime comment is out of date (sic !) and current implementation 
> seems not free of bug, here is an effort to summarize and understand the 
> whole thing, let's call this a review.

Thanks this is a great initiative!


> Please tell me where my interpretations are wrong.
> 
> 1) The DateAndTime is stored internally as
> - a point in UTC time (julianDayNumber, seconds, nanos)
> - an offset from UTC (a Duration) denoting the local time zone
> 
> 2) The ticks method returns the UTC part {julianDayNumber. seconds. nanos}
> 
> 3) DateAndTime print themselves in local time using the offset
> 
> 4) other methods (with some exceptions) return the local dateAndTime parts 
> (year month day hours minutes seconds)
> 
> Exceptions are:
> - secondsSinceMidnight (which should be renamed secondsSinceMidnightUTC IMO, 
> even if the method is classified private)
> - julianDayNumberUTC as the name tells
> 
> So far so good (but secondsSinceMidnight which is error prone)
> 
> What I find strange:
> - #hash uses the offset... Why ???
> 
> d1 := DateAndTime now.
> d2 := d1 offset: d1 offset + 1 hours.
> {
> d1 = d2.
> d1 hash = d2 hash.
> }
> gives  #(true false), a clue?
> 
> - #< compares julianDayNumber (the UTC inst. var.) with otherDate 
> julianDayNumber (with otherDate local offset) which seems wrong, it should 
> better use julianDayNumberUTC or (normalized) ticks.
> 
> - #= could be simplified and accelerated if using #hasEqualTicks: (if the 
> ticks are correctly normalized though which would be the case since 
> #ticks:offset: does, unfortunately #setJdn:seconds:nanos:offset: does not).
> 
> Some senders of #setJdn:seconds:nanos:offset: don't normalize the 
> day/seconds/nanos, though it should be their responsibility (DateAndTime 
> todayAtMilliSeconds: xxx) (DateAndTime todayAtNanoSeconds: xxx), not counting 
> year:month:day:hour:minute:second:nanoSecond:offset: which does not either 
> (many senders...).
> Maybe we should better let the normalization responsibility to 
> #setJdn:seconds:nanos:offset:.
> 
> It remain to analyze the conversion protocol (asYear etc...) which seems to 
> use the local time year, but I don't understand the whole Timespan thing 
> right now (why DateAndTime now asYear starts now, and not on january 1st?).
> 
> Nicolas
> 
> 

Re: [Pharo-project] [Ann] TxText. New text editor done!

[stephane ducasse]

Hi denis

Alain is gone on vacation but it told me that if you code scale he will throw 
away what he did :)
May be the decorators that alain wrote can be merged.
In any case this is excellent to get a better system.

Stef


On Apr 27, 2013, at 5:17 PM, Denis Kudriashov  wrote:

> I should say it is not difficult to do with current design. I were
> think about it and current layout building logic requires little
> changes, maybe just one spesific method.
> 
> But there is cases where any text change required rebuilding full
> layout. Fo example, single line text with wrapping mode.
> 
> 
> 2013/4/27, Igor Stasenko :
>> Very impressive progress, Denis! :)
>> 
>> I going to finish low-level stuff in Athens (path approximation /
>> point location)
>> and then go straight to text rendering with existing Text.
>> Next stage will be to take TxText model and provide rendering for it
>> with Athens,
>> as well as review the code.
>> 
>> About text editing and re-layout.
>> It should be possible that any local update (which affecting only
>> single character span or multiple adjusted character spans will
>> require only local recalculations of text layout). Otherwise there is
>> no reason why in our model we don't keep whole text in single big
>> buffer (like Text does).
>> Splitting text on multiple spans was the reason to make local layout
>> updates possible.
>> But i know it is not that easy to do :)
>> 
>> 
>> --
>> Best regards,
>> Igor Stasenko.
>> 
>> 
> 

Re: [Pharo-project] [Ann] TxText. New text editor done!

[stephane ducasse]

Thanks for your energy, alain told me that he will also have a look.
This is good to see movement from this front.
Having a scalable texteditor with rich editing capabilities (icons, line 
number) is important for Moose and synectique.
Also the new generation code browser will benefit from this new TextMorph.
Stef

On Apr 27, 2013, at 12:54 PM, Denis Kudriashov  wrote:

> 2013/4/27 Denis Kudriashov 
> 2013/4/27 stephane ducasse 
> Nice!
> Denis did you see the benchs that doru tried to see if we can use Rubric?
> Because it is interesting to see if we can load and manipulate really large 
> file.
> 
> Now it would be good that alain releases Rubric with a stable version and 
> check how to take advantage of the new TextMorph.
> 
> I saw his post. 
> And just now I check this test with TxTextMorph with unwrapped strategy. 
> Similar results like at Rubric test. nearly 30 secs.
> I generate 50 mb string  with almost million lines:
> TxModel building get 10 seconds. Layout building get 20 seconds.
> 
> I found that Tudor wrote about 15 million lines. 
> So I change my test and now I have OutOfMemotyWarning. It raised on splitting 
> given string on lines. Obviously building text model should be optimized by 
> work with stream.
> 

Re: [Pharo-project] Smart Suggestion Version 1

[stephane ducasse]

On Apr 26, 2013, at 4:41 PM, Gisela Decuzzi  wrote:

> 
> 2013/4/24 stephane ducasse 
> What would be cool is to have a way to select the enclosing expression but 
> you know it:)
> 
> Now I'm selecting the node from the expression where you asked for 
> suggestions... I'm looking to for underline the scope but it's an advance.
> 
> Also if you want to try it's working in Rubric text editor example (but only 
> throw the menu).

I should look at it :)

Re: [Pharo-project] [Ann] TxText. New text editor done!

[stephane ducasse]

Nice!
Denis did you see the benchs that doru tried to see if we can use Rubric?
Because it is interesting to see if we can load and manipulate really large 
file.

Now it would be good that alain releases Rubric with a stable version and check 
how to take advantage of the new TextMorph.

Stef

On Apr 26, 2013, at 11:19 PM, Denis Kudriashov  wrote:

> Hi guys. 
> 
> I'm happy to announce that new text editor based on new text model done. You 
> can load configuration from http://www.smalltalkhub.com/#!/~sig/TxText. Last 
> version: 0.6.
> See class side example methods.
> 
> What available now in TxTextMorph:
> - cursor navigation with move left, right, down, up and mouse click
> - text selection with move left, right, down, up and mouse movement
> - editing by keyboard input
> - text wrap
> - #addCursor/#removeCursor 
> - #enableSelection.
> - #beEditable
> - all keyboard interractions based on shortcuts
> 
> Little details about navigation and editing:
> There is TxEditor object which know about cursor position and text selection. 
> Text morph ask him to perform all navigation and editing behaviour. 
> It has cursorMode which knows how to change editor selection when cursor 
> moved. Editor delegates all move actions to cursorPosition by 
> #doesNotUnderstand method. It is simplified adding new navigation methods. 
> For example see TxTextMorph>>enableSelection
> 
> aTxTextMorph>>moveEditorOn: Character arrowLeft by: #moveLeft.
> 
> This expression adds two shortcuts: to move editor left and to select text 
> left (when selectionModeModifier active).
> 
> What next:
> - Remains standart navigation and editing features like copy/paste, move to 
> line end, to text end and etc.
> - halo menu items to edit text and layout properties
> - Edit decorators to get mask behaviour like "(999)***-**-**", pretty numbers 
> like "1'000'000", secrete field like "***"
> - Value specs to filter inserted text (only numbers, only english and etc)
> 
> There are some problems with focus behaviour now. And drawing text morph with 
> transparent back color works bad. It will be cool if somebody with good 
> knowledge at this topics can fix it.
> 
> Best regards,
> Denis

Re: [Pharo-project] [update 3.0] #30066

[stephane ducasse]

marcus do you know why the diff does not work with SmalltalkHub?


On Apr 26, 2013, at 5:43 PM, Marcus Denker  wrote:

> 30066
> -
> 
> 10401 Add Amber BlockClosure asynchronous methods into Pharo
>   https://pharo.fogbugz.com/f/cases/10401
>   
> 10418 cleanUp #methodHeaderFor:
>   https://pharo.fogbugz.com/f/cases/10418
>   
> 10419 Remove CompiledMethodWithNode (part 2)
>   https://pharo.fogbugz.com/f/cases/10419
> 
> Diff information:
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Traits-MarcusDenker.475
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Tools-MarcusDenker.1083
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1382
> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Compiler-MarcusDenker.400
> 
> 

Re: [Pharo-project] SandstoneDB on Pharo 2.0 - done - what next?

[stephane ducasse]

>> 
>>> also, I noticed there is no "ConfigurationOfSandstoneDB"... 
>> 
>> There already is one in MetacellRepository, just look at the comments
>> below the video:
> 
> It seems to work well when the ConfigufationOfXyz is kept with the project
> and then copied to wherever else it should be. I find that by now there are
> too many places to go hunting!

we are working on making it totally automatic.
Now you hsould publish in your project and in MetacelloRepository 
MetaRepoForPharo20

> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/SandstoneDB-on-Pharo-2-0-done-what-next-tp4683508p4683640.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 

Re: [Pharo-project] [update 3.0] #30062

[stephane ducasse]

do what is the easiest for you :)

Stef

On Apr 25, 2013, at 6:12 PM, Marcus Denker  wrote:

> Not yet… so I managed to not see a bug and now the image is in a 
> non-updatable state.
> 
> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-1-Tracker/259/console
> 
> I am even too tired to think what the options are… maybe retracting the 
> faulty one?
> 
> On Apr 25, 2013, at 6:01 PM, Marcus Denker  wrote:
> 
>> 30062
>> -
>> 
>> 10403 Class comments in Kernel and Collections
>>  https://pharo.fogbugz.com/f/cases/10403
>>  
>> 10404 Improve RBScanner error handling
>>  https://pharo.fogbugz.com/f/cases/10404
>>  
>> 10405 Fix a wrong refactoring in CodeImport
>>  https://pharo.fogbugz.com/f/cases/10405
>>  
>> 10352 Fix for MorphTreeMorph>>updateList
>>  https://pharo.fogbugz.com/f/cases/10352/
>>  
>>  
>> 
>> Diff information:
>> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Morphic-MarcusDenker.1403
>> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/KernelTests-MarcusDenker.489
>> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1375
>> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/CollectionsTests-MarcusDenker.594
>> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/CodeImport-MarcusDenker.16
>> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Collections-Arithmetic-MarcusDenker.9
>> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/AST-Core-MarcusDenker.133
>> 
> 
> 

Re: [Pharo-project] Call for ESUG 2013 presentations

[stephane ducasse]

Hi janko
Let's say that I found your email a bit funny.

- First I'm on holidays using a slow connection internet and I should something 
better for my holidays. 
- Second I cannot post to Etoys, Squeak and this is years that nobody posted 
anything on comp.lang.smalltalk.
- Third it took me more than afternoon writing the call so other people can 
click and do forward to the mailing-lists of their wishes.
- Fourth if you believe that this is on purpose that I do not send mail to the 
squeak mailing-lists,
I would say that you should start to do more for squeak than me and then we can 
talk :).

Stef

On Apr 24, 2013, at 7:05 PM, Janko Mivšek  wrote:

> Hi Stef,
> 
> I don't see that announcement on Squeak mailing list, nor others except
> vwnc, on comp.lang.smalltalk should also go, also squeakland, etoys, ...
> 
> Best regards
> Janko
> 
> Dne 24. 04. 2013 16:49, piše stephane ducasse:
>> with the corrected url
>> 
>> with corrected uppercased C for conferences :)
>> 
>> 
>> 
>> 21st International Smalltalk Joint Conference - Call for Contributions
>> 
>>  Annecy, France
>>  from 9 to 13 September 2013
>>  http://www.esug.org/Conferences/2013/
>> 
>>  This call includes:
>>  Developer Forum
>>  Smalltalk Technology Award
>>  International Workshop
>>   http://www.esug.org/Conferences/2013/InternationalWorkshop
>>  Student Volunteer
>>   http://www.esug.org/Conferences/2013/StudentVolunteers
>>  Camp Smalltalk 8 September 2013
>> 
>>  --
>>  For the past 21 years, the European Smalltalk User Group (ESUG) has
>>  organised the International Smalltalk Conference, a lively forum on
>>  cutting edge software technologies that attract people from both
>>  academia and industry for a whole week. The attendees are both
>>  engineers using Smalltalk in business and students and teachers
>>  using Smalltalk both for research and didactic purposes.
>> 
>>  As every year, this year's edition of the largest European Smalltalk
>>  event will include the regular Smalltalk developers conference with
>>  renowned invited speakers, a Smalltalk camp that proves fruitful for
>>  interactions and discussions. This year will be held the
>>  9th edition of the Innovation Technology Awards where prizes will be
>>  awarded to authors of best pieces of Smalltalk-related projects
>>  and an international workshop on Smalltalk and dynamic languages
>>  (http://www.esug.org/Conferences/2013/InternationalWorkshop)
>> 
>>  You can support the ESUG conference in many different ways:
>> 
>>  * Sponsor the conference. New sponsoring packages are described at
>>  http://www.esug.org/supportesug/becomeasponsor/
>>  * Submit a talk, a software or a paper to one of the events. See below.
>>  * Attend the conference. We'd like to beat the previous record of
>>  attendance (170 people at Amsterdam 2008)!
>>  * Students can get free registration and hosting if they enrol
>>  into the the Student Volunteers program. See below.
>> 
>>  Developers Forum: International Smalltalk Developers Conference
>>  
>> 
>>  We are looking for YOUR experience on using Smalltalk. You will have
>>  30 min for presentations and 45 min for hand-ons tutorial.
>> 
>>  The list of topics for the normal talks and tutorials includes, but
>>  is not limited to the following:
>> 
>>  * XP practices,  Development tools,  Experience reports
>>  * Model driven development,  Web development, Team management
>>  * Meta-Modeling,  Security,  New libraries & frameworks
>>  * Educational material,  Embedded systems and robotics
>>  * SOA and Web services,  Interaction with other programming languages
>> 
>>   Teaching Pearls
>>   ---
>>   New this year!!!
>> We want two news types of sessions in addition to default talk and 
>> show us your projects sessions.
>> 
>> - Show your business 10 min session (Get prepared!!)
>> - Teaching pearls : we want some session on how to teach some design
>>   aspects. We want your tip and tricks to teach Smalltalk or OOP.
>> 
>> We expect to have several 10 to 15 min sessions aggregated.
>> 
>>   Open Forum: starting with Smalltalk
>>   
>>   New this year!!
>>   The event will be held at IAE Savoie Mont-Blanc - University of Savoie. 
>>   This is an opportunity for students and local p

Re: [Pharo-project] Rubric questions :)

[stephane ducasse]

I will retry in 30 because I see that you announce symbol :)

On Apr 24, 2013, at 5:25 PM, Stéphane Ducasse  wrote:

> Hi alain
> 
> better talk not privately :)
> 
> 
> MCHttpRepository
>   location: 'http://www.smalltalkhub.com/mc/AlainPlantec/Rubric/main'
>   user: ''
>   password: ''.
> 
> 
> 
> Why 
>   RubParagraphDecorator defines 
>   
>   findRegex 
>^ next findRegex
> 
>   I'm trying to understand the interface of the decorator since all the 
> decorator should have the same to be interchangeable.
> 
> 
> 
>   
> On 
> self blueTextOnGrayBacgroundNotWrapped
>   
>   when I get the menu and change the font nothng changes.
> 
> 
> I get a DNU when I execute
> 
>   self withOnlyThePrimarySelection
> 
> When I type the name of a class in RubMethodEditingExample open
> I get DNUs.
> 
> more to come 

Re: [Pharo-project] configuration speed

[stephane ducasse]

On Apr 24, 2013, at 4:50 PM, Camillo Bruni  wrote:

> I checked the issue under 3.0 with the configuration loading speed.
> 
> 
> Main Performance Issues:
> 
> Gofer: 
>   package-cache always used by Gofer => big shared package-cache is very 
> slow
> RPackageSet: 
>   each method/class change trigger the creation of a new RPackageSet 
>   for EACH Monticello working copy
> 
> What was reported is, that disabling the announcements during configuration 
> loading
> decreases load time. This is due to the RPackageSet problem. No 
> announcements, no new
> RPackageSets.
> 
> For a typical configuration loading CommandShell and Soup + 5 packages I got 
> 518'124
> new instances of RPackageSet!!

Just that :)
There is something wrong. 

> 
> Solutions
> -
> Gofer: 
>   removing the package-cache from the default repositories seems like a 
> good thing
>   to me. There are 3 tests failing after that, mostly checking if there 
> is a default
>   repository or not.
>   I would add an explicit statement for the package-cache otherwise.
> 
> RPackageSet:
>   With a basic cache for RPackageSets I cut the load time to a third!
>   It will need some more love when it comes to changing classes, but for 
> now
>   I invalidate it each time an RPackage changes.
> 
> 
> issue: https://pharo.fogbugz.com/default.asp?10393

Re: [Pharo-project] Call for ESUG 2013 presentations

[stephane ducasse]

with the corrected url

with corrected uppercased C for conferences :)



21st International Smalltalk Joint Conference - Call for Contributions

  Annecy, France
from 9 to 13 September 2013
http://www.esug.org/Conferences/2013/

  This call includes:
  Developer Forum
  Smalltalk Technology Award
  International Workshop
   http://www.esug.org/Conferences/2013/InternationalWorkshop
  Student Volunteer
   http://www.esug.org/Conferences/2013/StudentVolunteers
  Camp Smalltalk 8 September 2013

  --
  For the past 21 years, the European Smalltalk User Group (ESUG) has
  organised the International Smalltalk Conference, a lively forum on
  cutting edge software technologies that attract people from both
  academia and industry for a whole week. The attendees are both
  engineers using Smalltalk in business and students and teachers
  using Smalltalk both for research and didactic purposes.

  As every year, this year's edition of the largest European Smalltalk
  event will include the regular Smalltalk developers conference with
  renowned invited speakers, a Smalltalk camp that proves fruitful for
  interactions and discussions. This year will be held the
  9th edition of the Innovation Technology Awards where prizes will be
  awarded to authors of best pieces of Smalltalk-related projects
  and an international workshop on Smalltalk and dynamic languages
  (http://www.esug.org/Conferences/2013/InternationalWorkshop)

  You can support the ESUG conference in many different ways:

  * Sponsor the conference. New sponsoring packages are described at
 http://www.esug.org/supportesug/becomeasponsor/
  * Submit a talk, a software or a paper to one of the events. See below.
  * Attend the conference. We'd like to beat the previous record of
 attendance (170 people at Amsterdam 2008)!
  * Students can get free registration and hosting if they enrol
into the the Student Volunteers program. See below.

  Developers Forum: International Smalltalk Developers Conference
  

  We are looking for YOUR experience on using Smalltalk. You will have
  30 min for presentations and 45 min for hand-ons tutorial.

  The list of topics for the normal talks and tutorials includes, but
  is not limited to the following:

  * XP practices,  Development tools,  Experience reports
  * Model driven development,  Web development, Team management
  * Meta-Modeling,  Security,  New libraries & frameworks
  * Educational material,  Embedded systems and robotics
  * SOA and Web services,  Interaction with other programming languages

   Teaching Pearls
   ---
   New this year!!!
We want two news types of sessions in addition to default talk 
and 
show us your projects sessions.

- Show your business 10 min session (Get prepared!!)
- Teaching pearls : we want some session on how to teach some 
design
 aspects. We want your tip and tricks to teach Smalltalk or OOP.

We expect to have several 10 to 15 min sessions aggregated.

   Open Forum: starting with Smalltalk
   

   New this year!!
   The event will be held at IAE Savoie Mont-Blanc - University of 
Savoie. 
   This is an opportunity for students and local professionals to 
discover Smalltalk. 
   A room will be freely accessible and we would like to propose some 
talks and workshop 
   for Smalltalk beginners.

The list of topics includes, but is not limited to the 
following:
- Why Smalltalk ?
- Panorama of Smalltalk solutions
- Getting started with Smalltalk
- Success stories




  How to submit?
  --

  Submissions due on 15st June 2013
  Notification of acceptance will be on done on the fly.
  More information at http://www.esug.org/conferences/2013


  Pay attention: the places are limited so do not wait till the last
  minute to apply. Prospective presenters should submit a request to
  stephane.duca...@inria.fr AND USE THE following header [ESUG 2013 Developers].

  Please follow the template below the email will be automatically processed!

  Subject: [ESUG 2013 Developers] + your name
  First Name:
  Last Name:
  Email where you can always be reached:
  Title:
  Type: Tutorial/Talk/Teaching Pearl/OpenForum
  Abstract:
  Bio:


Any presentation not respecting this form will be discarded 
automatically



  International Workshop on Smalltalk Technologies
  
  http://www.esug.org/Conferences/2013/InternationalWorkshop

  Sma

Re: [Pharo-project] [OT] Browsing some code and surprise

[stephane ducasse]

may be the best is to 
- stabilize the current functionality and   
- have a look at rubric 

alain told me that now syntax highlight was working.

Stef


On Apr 24, 2013, at 4:04 PM, Gisela Decuzzi  wrote:

> #Editor>>select
>   "If the text selection is visible on the screen, reverse its highlight."
>   ^'Not doing anything'
>   "screw this logic
>   selectionShowing ifFalse: [self reverseSelection]"
> 
> deselect
>   "If the text selection is visible on the screen, reverse its highlight."
>   " * screw this logic * selectionShowing ifTrue: [self 
> reverseSelection] "
> 
> 

Re: [Pharo-project] Smart Suggestion Version 1

[stephane ducasse]

On Apr 24, 2013, at 3:21 PM, Gisela Decuzzi  wrote:

> Ok, I got the point :)
> https://pharo.fogbugz.com/default.asp?10392#75301
> 
> Now I will work to mark the selections and the problems with senders form the 
> symbol.

Thanks :)

I'm toying with rubric and I dream about seeing the expressions surrounding my 
cursor :).

Stef

Re: [Pharo-project] Smart Suggestion Version 1

[stephane ducasse]

What would be good is that when we get the sender/implementor is to get 
- the name of the entity as first entry in the menu
- get the entity selected in the text.

blockClosureValue: aBlockClosure message: aMessage
|newMessage|
newMessage := Message selector: #valueWithArguments: arguments: (Array 
with: aMessage arguments).
^self blockClosureValueWithArguments: aBlockClosure message: newMessage


when I'm on selector: it works I get selector:arguments: 

now when I'm  #valueWithArgurments it does not 

What would be cool is to have a way to select the enclosing expression but you 
know it:)

When can we push that into 3.0



Stef



> Hello! After some work I think that Smart Suggestions it's ready to have some 
> real feedback to continue growing up :)
> 
> What is it?
> The idea it's to have suggestions based in the text selected or the cursor 
> position.
> Actually there are suggestions for:
> - Temporary/Instance/Class Variable
> - Class
> - Method (when you are in the selector)
> - Source (multiple lines)
> - Message
> 
> How to install it?
> Gofer it 
>   smalltalkhubUser: 'gisela'
>project: 'SmartSuggestions';
>   package: 'SmartSuggestions';
>   load.
> 
> Some screen shots: (to activate de menu the shortcut es Ctrl + t for windows 
> or unix and Command + t for mac)
> 
> 
> 
> 
> 
> How to define a new action?
> It's easy to define your own action only use the pragma in your custom method 
> and make sure to retunr an instance of SugsSuggestion, examples in 
> SugsSuggestionFactory are categorized by the selection.  
> 
> 
> If you have some comments I will be very happy to heard about, I have removed 
> the actions form nautilus menu, because it was to much visual noise (at least 
> for me) if you want to add it, only uncoment the pragma in: 
> #SugsMenuBuilder>>addSuggestionToSourceCodeMenu:
> 
> ps: It could appear a DNU when fetching the suggestions for a class variable 
> the description and solution are in 
> https://pharo.fogbugz.com/default.asp?10380#75204

Re: [Pharo-project] Smart Suggestion Version 1

[stephane ducasse]

+ 1

Interfaces are a cool concept and we should use them and adhere to them 
conceptually
> I am tempted to deprecate #definesMethod: and just rename it to 
> canUnderstand: (and fix all senders)
> This way the RB model for code would be one step closer to normal classes and 
> methods.

Re: [Pharo-project] Metacello for Pharo 2 and Pharo 3 ?

[stephane ducasse]

we should define the 3.0.x tag in the image.

Stef


> Hi,
> 
> is there already a #'pharo3.0.x' tag in metacello when we want to have 
> different package version in Pharo 3.0 instead of 2.0 ? I tried
> 
> spec for: #'pharo3.0.x' version: '0.2'
> 
> and it didn't work.
> 
> Thierry
> -- 
> Thierry Goubier
> CEA list
> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
> 91191 Gif sur Yvette Cedex
> France
> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
> 

Re: [Pharo-project] plugin in Nautilus

[stephane ducasse]

yes! we could try to see.

> Group are made for this.
> 
> Maybe we should automatically create a new group when a package is loaded
> Ben
> 
> On Apr 21, 2013, at 4:23 AM, Alexandre Bergel  wrote:
> 
>> I tried to use groups, but it does not really work for me. Here is my 
>> scenario:
>> 
>> I take a fresh image, I load Versionner then I load Roassal.
>> I open a code browser, and guess what, I want to see Roassal and Versionner 
>> right away, and not have to scroll down.
>> 
>> But I think that the most important, is to be able to particularize the 
>> system, and not really to get the best behavior.
>> 
>> Cheers,
>> Alexandre
>> 
>> 
>> 
>> On Apr 20, 2013, at 3:32 AM, stephane ducasse  
>> wrote:
>> 
>>> I use a group for that :)
>>> 
>>> And what I would love is a group: 
>>> latest loaded packages.
>>> 
>>> 
>>> On Apr 20, 2013, at 12:24 AM, Alexandre Bergel  
>>> wrote:
>>> 
>>>> Hi!
>>>> 
>>>> Is there a documentation on how to create a plugin for Nautilus?
>>>> 
>>>> I would like to create a command 'Hide all packages' in the Package column 
>>>> of Nautilus. Any hint on how to do this?
>>>> 
>>>> Cheers,
>>>> Alexandre
>>>> -- 
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> -- 
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
>> 
> 

Re: [Pharo-project] plugin in Nautilus

[stephane ducasse]

On Apr 21, 2013, at 4:23 AM, Alexandre Bergel  wrote:

> I tried to use groups, but it does not really work for me. Here is my 
> scenario:
> 
> I take a fresh image, I load Versionner then I load Roassal.
> I open a code browser, and guess what, I want to see Roassal and Versionner 
> right away, and not have to scroll down.

So this is why I said I want load latest :)

> But I think that the most important, is to be able to particularize the 
> system, and not really to get the best behavior.
> 
> Cheers,
> Alexandre
> 
> 
> 
> On Apr 20, 2013, at 3:32 AM, stephane ducasse  
> wrote:
> 
>> I use a group for that :)
>> 
>> And what I would love is a group: 
>>  latest loaded packages.
>> 
>> 
>> On Apr 20, 2013, at 12:24 AM, Alexandre Bergel  
>> wrote:
>> 
>>> Hi!
>>> 
>>> Is there a documentation on how to create a plugin for Nautilus?
>>> 
>>> I would like to create a command 'Hide all packages' in the Package column 
>>> of Nautilus. Any hint on how to do this?
>>> 
>>> Cheers,
>>> Alexandre
>>> -- 
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-project] Version 1.39 of Versionner

[stephane ducasse]

On Apr 19, 2013, at 5:25 PM, Torsten Bergmann  wrote:

>>> Works now - thanks. I've put a copy of the config into 
>>> ss3/MetaRepoForPharo20
>>> so one can easily load via Configuration browser from within the 2.0 image.
>> 
>> Excellent!
>> Something that would be amazing, is to have a small text panel that appears 
>> when you select a configuration, with a short description (or at least some 
>> keywords) of what the software about to install is all about.
>> 
>> For example, there are only a few projects that I can imagine what they are 
>> about. For example, no idea what VistaCursors, VoyageMongo, ScriptManager 
>> are about. I know I can easily find the info on the different forges. But my 
>> point is that the visibility of these projects is really small. 
>> 
>> Maybe we can use as a convention a method #readme on each ConfigurationOf ?
>> 
>> Alexandre
> 
> I completely agree that more work is needed. I started a new config browser 
> for 3.0 (based on Spec) as a changeset 
> - currently I cant find the issue on this horrible new issue tracker ;)

:)
Yes me too :)

> 
> Yes - the config itself would be a good place.
> 
> One problem: if you want to have a slick UI (fast moving in the list) you 
> would have to load all the
> configs into the image. Or one needs an updating server job that 
> collects all #readmes
> and provides a txt/xml file for the config browser client

Yes :)
Probably the job that will validate the projects that are accepted in a 
distribution should build this cache.
In fact we want to have a job that loads the ConfigurationOf and parse their 
Pier description and generate a catalog on the web.

Right now I'm continuing to write chapters for a future book in pier 
https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/

but this will be with the same techno

Like that we will not have to maintain the catalog in the collaborative book.

Stef



> Bye
> T.
> 
> 
> 

Re: [Pharo-project] Version 1.39 of Versionner

[stephane ducasse]

We should add more information in the configurationOf

Stef

>>> No idea why happened. 
>>> I copied the a missing file in the repository
>>> Try again, it should work now
>>> 
>>> Alexandre
>> 
>> Works now - thanks. I've put a copy of the config into ss3/MetaRepoForPharo20
>> so one can easily load via Configuration browser from within the 2.0 image.
> 
> Excellent!
> Something that would be amazing, is to have a small text panel that appears 
> when you select a configuration, with a short description (or at least some 
> keywords) of what the software about to install is all about.
> 
> For example, there are only a few projects that I can imagine what they are 
> about. For example, no idea what VistaCursors, VoyageMongo, ScriptManager are 
> about. I know I can easily find the info on the different forges. But my 
> point is that the visibility of these projects is really small. 
> 
> Maybe we can use as a convention a method #readme on each ConfigurationOf ?
> 
> Alexandre
> 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-project] Any wishes for Roassal?

[stephane ducasse]

We want speed up and less garbage generation (ie do not use collect when do 
will make it or some stuff like that).
May be people here could have a look at it and do a fast code review?

Stef



> Hi!
> 
> Roassal 2.0 is on the way. We would like to make sure everybody find this 
> release attractive. 
> We are wondering whether you have some particular requirements you would like 
> us to address or some bugs you would like to see fixed.
> 
> Feel free to speak up!
> 
> Cheers,
> Alexandre
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-project] [Moose-dev] Roassal new algorithms

[stephane ducasse]

On Apr 20, 2013, at 8:23 AM, Tudor Girba  wrote:

> This visualization is precisely made for hierarchical graphs. That is why the 
> edges are called "hierarchical bundled edges". So, yes, you need a 
> hierarchical graph.

+1 

:)

> 
> Cheers,
> Doru
> 
> 
> On Apr 19, 2013, at 8:57 PM, Alexandre Bergel  wrote:
> 
>> This is a very cool visualization. There is no reason why we cannot do it in 
>> Pharo
>> 
>> Alexandre
>> 
>> 
>> On Apr 19, 2013, at 10:49 AM, Frank Shearar  wrote:
>> 
>>> I've played with these before [1]. They work best with hierarchical names. 
>>> In other words, in a flat namespace (say, showing class dependencies with 
>>> just the class name) you end up with a very messy diagram.
>>> 
>>> Let's assume you use "." as the name token separator. If you prefixed the 
>>> names with their packages, say Tools-Debugger.Debugger, you'd get a better 
>>> graph, where the bundles would be tighter. If you made things more 
>>> hierarchical still, say with names like Tools.Debugger.Debugger, things 
>>> would look even better.
>>> 
>>> The deeper the naming hierarchy the fewer fat bundles you get in the image.
>>> 
>>> frank
>>> 
>>> [1] http://mbostock.github.io/d3/talk/2016/bundle.html
>>> 
>>> On 19 April 2013 16:37, Alexandre Bergel  wrote:
>>> Let's have this discussion in the Pharo list.
>>> 
>>> Alexandre
>>> 
>>> Begin forwarded message:
>>> 
 From: Alexandre Bergel 
 Subject: [Moose-dev] Re: Roassal new algorithms
 Date: April 19, 2013 11:25:31 AM GMT-04:00
 To: Moose-related development 
 Reply-To: Moose-related development 
 
> There are more than simply linear, quadratic and cubic Bezier curves. In 
> fact, as you can have as many control points as you wish, you can have a 
> Bezier curve of any order.
 
 Ok
 
> But what I was calling RadialBezierCurve was a kind of strategy, I mean I 
> have an abstract class which knows how to compute a curve, but I still 
> have to choose my control points so I was thinking to create different 
> subclasses whose role is to know what are their control points :
> 
> - The radial one choose its control points within the same radius as its 
> source and its target.
 
 Ah ok
 
> I wanted to create an ortoVertical and an ortoHorizontal whose control 
> points would have been computed differently, so that we could use Bezier 
> curve for regular tree too.
 
 It would be cool to have hierarchical bundles edges in Roassal.
 A screenshot of what it looks like:
 
 
 The technical description: 
 http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf
 
 Alexandre
 
 -- 
 _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
 Alexandre Bergel  http://www.bergel.eu
 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
 
 
 
 ___
 Moose-dev mailing list
 moose-...@iam.unibe.ch
 https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>> 
>>> -- 
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>> 
>>> 
>>> 
>>> 
>> 
>> -- 
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
>> 
> 
> --
> www.tudorgirba.com
> 
> "What is more important: To be happy, or to make happy?"
> 
> 

Re: [Pharo-project] plugin in Nautilus

[stephane ducasse]

I use a group for that :)

And what I would love is a group: 
latest loaded packages.


On Apr 20, 2013, at 12:24 AM, Alexandre Bergel  wrote:

> Hi!
> 
> Is there a documentation on how to create a plugin for Nautilus?
> 
> I would like to create a command 'Hide all packages' in the Package column of 
> Nautilus. Any hint on how to do this?
> 
> Cheers,
> Alexandre
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-project] Old bugs fixed by Opal

[stephane ducasse]

> 
 
 Did you use
 
https://ci.inria.fr/rmod/job/Opal/
 
 The Opal in the image is a bit out-dated…
>>> 
>>> I did just now, but there, debugging *anything* (even 3 + 4, or using cmd 
>>> dot) with the Opal Compiler set to default seemed to bring the image into a 
>>> near catatonic state…
>>> Sort of hard to check if the buttons were fixed, with no debugger ever 
>>> opening. ;)
>>> 
>> 
>> Yes, we committed some changes that might have broken things… 
>> I will check.
>> 
> Ok, found it… at least the debugger appears again after  a "self halt" :-)
> 
>   https://ci.inria.fr/rmod/job/Opal/lastSuccessfulBuild/artifact/Opal.zip
> 
> We should remember to never think it works before the regression tester is 
> successful…
> Clement wrote a blog post: 
> http://clementbera.wordpress.com/2013/03/22/toward-a-zero-bugs-interpreter-compiler/

nicely written :)

Thanks clement this is cool! Push we are getting there.

Re: [Pharo-project] Pharo on iOS with Bluetooth keyboard working almost in full.

[stephane ducasse]

now I considering ipad :)

On Apr 19, 2013, at 11:51 AM, Esteban Lorenzano  wrote:

> sweet :)
> 
> On Apr 19, 2013, at 12:00 AM, "p...@highoctane.be"  wrote:
> 
>> I've made some progress on using the external keyboard.
>> 
>> Now, it is about usable. Some mappings still missing (discovering a lot of 
>> interesting things in the process) but usable.
>> 
>> See video (poor camera, but the better one is on the iPad, oops):
>> 
>> http://www.youtube.com/watch?v=7MNsUiCc5FQ
>> 
>> Phil
> 

Re: [Pharo-project] [Athens] A new wave of impressionism

[stephane ducasse]

:)
This is cool that you push athens.
Because this is really important for Pharo.

Stef

> Not really impressive (that's why it called new wave)
> 
> Here is results of 2 days of preparing/implementing and polishing a
> quadric bezier curve approximation
> algorithm by series of lines.
> 
> The red pill.. err fill is polygon consisting purely from lines,
> the white outline is same quadric bezier, but drawn directly by cairo
> with stroke width = 5.
> 
> Cubic bezier , then elliptical arc and then generic parametric
> functions ahead! :)
> 
> There is two reasons why i implementing highly inefficient (because of
> boxed floats)
> path flattener:
> - some path segments are not supported by cairo, therefore i am
> forced to approximate it with something else (and something else is
> lines ;)
> - having path geometry turned into silly polygon, there is very easy
> algorithm to tell if given point inside or outside of polygon
> 
> so, potentially, this will give use following:
> - being able to use any kind of curves as path segments (well, it
> could be a bit slow, but it is up to you, right?) e.g. something like:
>builder
> lineTo: 50@50;
> parametricCurve: [:t | t sin * t squared ] tMin: 0 tMax: 10 to: 20@30
> 
> - being able to detect whether mouse hovers over shape or not  :)
> 
> 
> -- 
> Best regards,
> Igor Stasenko.
> 

Re: [Pharo-project] Argument names created by Debugger

[stephane ducasse]

a bit smarter system does not hurt.

Stef

On Apr 18, 2013, at 10:15 PM, Sean P. DeNigris  wrote:

> I tweaked the code because in my most common case, I don't care that it's
> e.g. aByteString, but only that it's aString:
> 
>   (argument isKindOf: String) ifTrue: [ ^ 'aString' ].
>   (argument isKindOf: Collection) ifTrue: [ ^ 'aCollection' ].
>   (argument isKindOf: Integer) ifTrue: [ ^ 'anInteger' ].
> 
> Am I the only one, or would this be useful for everyone? lmk and I'll
> prepare a slice...
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/Argument-names-created-by-Debugger-tp4682387.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 

Re: [Pharo-project] How to get the AST Node for a Context

[stephane ducasse]

On Apr 18, 2013, at 8:19 PM, Igor Stasenko  wrote:

> On 18 April 2013 19:17, Nicolas Cellier
>  wrote:
>> Sure, typical refactoring process.
>> Code is convoluted and hard to follow, so you first document and explicit
>> most obscure steps.
>> In a second time, you realize how simpler it could be...
>> 
>> Pharo is quite fast and still accelerating these days, so I understand the
>> "satisfecit", it's already huge progress.
>> My unsatisfied nature just tell to not stop in the middle of the bridge, and
>> to not let un-necessarily complex code, even if well commented :)
>> 
> Opal is there we all can start contributing.
> I, for instance, have plans for replacing parsing.. to make modular
> parser & encoder

Yes :)
I would like to have a compilationContext instead of this ugly full of 
parameter methods and ….

I would like to be able to specify an environment (class binding + literal 
binding) as input and an environment
as output so that we can bootstrap the compiler nicely and do a lot fun stuff.

Stef

Re: [Pharo-project] How to get the AST Node for a Context

[stephane ducasse]

> Sure, typical refactoring process.
> Code is convoluted and hard to follow, so you first document and explicit 
> most obscure steps.
> In a second time, you realize how simpler it could be...
> 
> Pharo is quite fast and still accelerating these days, so I understand the 
> "satisfecit", it's already huge progress.
> My unsatisfied nature just tell to not stop in the middle of the bridge, and 
> to not let un-necessarily complex code, even if well commented :)

do not worry for that we have a long list of tasks for the compiler and even 
more for other components.
:)

Stef

Re: [Pharo-project] Metacello configuration conventions

[stephane ducasse]

Dale

I was discussing with christophe yesterday and what would be good in metacello 
is to be able to have in one version of the configurationOf
all the information about previous heads stable versions because right now to 
get this information 
we need to load previous versions until we see that the stable or development 
deifnitino changes.

I will start to add to my configurations

previousVersions

^ #((stable 20 #(1.0 1.2 1.3))
(stable 1.4 #(1.0 ))

so that we can perform regression testing and not just test the latest stable 
version.

Stef



> 
> 
> - Original Message -
> | From: "Camillo Bruni" 
> | To: Pharo-project@lists.gforge.inria.fr
> | Sent: Tuesday, April 16, 2013 3:19:57 PM
> | Subject: Re: [Pharo-project] Metacello configuration conventions
> | 
> | I liked ruby-gems approach more than the one in Metacello. You usually
> | specify
> | a major version (as under linux) for your dependency. That means the
> | dependency
> | might evolve a bit, typically for bugfixes, without you having to update
> | the configuration manually.
> | 
> | http://docs.rubygems.org/read/chapter/16 for me is what I'd like to see.
> | 
> | As you say, #stable and #development are mostly for humans.
> 
> Cami,
> 
> I did look at the way ruby-gems worked pretty early on in Metacello 
> development and I've arranged things such that I should be able to add the 
> ability to specify ranges of versions, but the whole mechanics of the 
> ruby-gem universe is different than the smalltalk universe so I'm not sure 
> that Metacello would give you the behavior you are looking for even I did 
> allow version ranges to be specified ...
> 
> I'd be willing to spend time working through use cases with you to see if 
> there would be benefit for enabling that feature...
> 
> Dale
> 

Re: [Pharo-project] Versionner in 2.0 again

[stephane ducasse]

On Apr 18, 2013, at 2:34 PM, Christophe Demarey  
wrote:

> 
> Le 18 avr. 2013 à 05:16, Sean P. DeNigris a écrit :
> 
>> Christophe Demarey wrote
>>> I was wondering if it is possible to downgrade an already installed
>>> package in a configuration.
>> 
>> For now, why don't we just declare a dependency to the correct version of
>> the toolbox? I'm uploading a config to Nabble which does this and seems to
>> work...  ConfigurationOfVersionner-SeanDeNigris.101.mcz
>> 
>>   
> 
> I tried with a baseline but it doesn't work (metacello keep the most up to 
> date toolbox).
> I didn't think to declare the toolbox as package. Your version works fine. 
> Thanks. I pushed it to the Versionner repo. :)
> So, now Versionner is loadable as any other lib.
> 
> @Marcus: Yes, if possible, it should be nice to update the toolbox version in 
> the image.

sure open a ticket and explain what we should do.

> 
> Best regards,
> Christophe.

Re: [Pharo-project] SS lost project description edits done in december 2012

[stephane ducasse]

On Apr 18, 2013, at 1:06 PM, Igor Stasenko  wrote:

> On 18 April 2013 12:37, Göran Krampe  wrote:
>> Hi!
>> 
>> I moved a lot of my projects to StHub back in december, and then I edited
>> the Project descriptions on SS to show that. But these changes have been
>> lost I now realize?
>> 
>> Just put it back on Phriak:
>> 
>> http://www.squeaksource.com/Phriak.html
>> 
>> Any idea on when/how that happened?
>> 
> when SS crashing, it "forgets" all metainformation for your project:
> - description
> - members
> etc..
> 
> this is one of the reasons why i migrated my active projects to sthub,
> because i get tired adding members over and over again :)

and it is cooler, fresher and faster :)

Stef

> 
>> regards, Göran
>> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko.
> 

Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness

[stephane ducasse]

add a bug entry and tag it so that we simply do not forget.

Stef

On Apr 18, 2013, at 5:25 AM, Sean P. DeNigris  wrote:

> Johan Brichau-2 wrote
>> fwiw, I changed the implementation of NECController...
>> NECController-Changes.cs (5K)
>> ;
> 
> I think at minimum Johan's change should be integrated immediately and
> backported to 2.0. I simply can not use enterToAccept, and without it now
> it's currently impossible to complete with common prefix matching enabled.
> 
> Are there any objections to the last suggested set of default preferences?
> If not, maybe those should be included as well - but not worth holding up
> Johan's change, which is essential.
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4679488p4682231.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 

Re: [Pharo-project] How to get the AST Node for a Context

[stephane ducasse]

I should say that I LOVVVE the comments in the method.
Yes Yes Yes.

Stef

> 
> Yes, just the AST with Semantic Analysis information (Scope and Semantic 
> Variables), plus
> bytecodelevel IR that provides the bridge to the low-level pc (bytecode 
> mapping) data…
> 
> e.g. to get the highlight in the debugger, this is now just this in 
> DebuggerMethodMapOpal:
> 
> 
> rangeForPC: aPC contextIsActiveContext: contextIsActive
>   "return the debug highlight for aPC"
>   | pc |
>   
>   "When on the top of the stack the pc is pointing to right instruction, 
> but deeper in the stack
>   the pc was already advanced one bytecode, so we need to go back this 
> one bytecode, which
>   can consist of multiple bytes. But on IR, we record the *last* bytecode 
> offset as the offset of the
>   IR instruction, which means we can just go back one"
> 
>   pc := contextIsActive ifTrue: [aPC] ifFalse: [aPC - 1].
>   ^(methodNode ir instructionForPC:  pc) sourceNode debugHighlightRange
> 
> 
> 
> more helper methods will simplify this even more, e.g. we should have a method
> on RBMethodNode like #nodeForPC: 
> 
> 
> rangeForPC: aPC contextIsActiveContext: contextIsActive
>   "return the debug highlight for aPC"
>   | pc |
>   
>   "When on the top of the stack the pc is pointing to right instruction, 
> but deeper in the stack
>   the pc was already advanced one bytecode, so we need to go back this 
> one bytecode, which
>   can consist of multiple bytes. But on IR, we record the *last* bytecode 
> offset as the offset of the
>   IR instruction, which means we can just go back one"
> 
>   pc := contextIsActive ifTrue: [aPC] ifFalse: [aPC - 1].
>   ^(methodNode nodeForPC:  pc) debugHighlightRange
> 
> 
> And this method one then can just implement on MethodContext itself.
> (Caching is handled by ASTCache).
> 
>   Marcus
> 
> 
> 

Re: [Pharo-project] How to get the AST Node for a Context

[stephane ducasse]

On Apr 17, 2013, at 10:29 PM, Camillo Bruni  wrote:

> I really really like this :)
> 
> very simple yet powerful!

Yes this will massively simplify the debugger :)
So we will be able to get a debugger really working without needing an magician 
to fix 
its bugs.

Stef

Re: [Pharo-project] [Sprint] Sprint Lille May 3rd

[stephane ducasse]

we will do one for the next one.
Now we need to kill bugs like mad.

On Apr 17, 2013, at 5:02 PM, p...@highoctane.be wrote:

> Why not make a doodle for this?
> 
> 
> 2013/4/17 Benjamin 
> cool :)
> 
> Ben
> 
> On Apr 17, 2013, at 2:07 PM, Sean P. DeNigris  wrote:
> 
>> Marcus Denker-4 wrote
>>> We are planning a sprint the 3rd of May:
>> 
>> I want to join again via IRC/skype from NYC. It worked out well last time...
>> 
>> 
>> 
>> -
>> Cheers,
>> Sean
>> --
>> View this message in context: 
>> http://forum.world.st/Sprint-Sprint-Lille-May-3rd-tp4682097p4682106.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>> 
> 
> 

Re: [Pharo-project] [update 2.0] #20599

[stephane ducasse]

On Apr 17, 2013, at 1:34 PM, Sven Van Caekenberghe  wrote:

> 
> On 17 Apr 2013, at 13:06, Marcus Denker  wrote:
> 
>> 20599
>> -
>> 
>> 10297 Integrate 2.0: 10295 Zinc Update April 16th
>>  https://pharo.fogbugz.com/f/cases/10297
> 
> Hey Marcus, that is even cooler. I know it is a lot of manual manipulation 
> work, so thanks again.
> 
> If I can make this process easier, please let me know.
> 
> I don't know what the policy is, but one solution could be to use 
> ConfigurationOfZincHTTPComponents.

One of these days we will get there :)

> 
> Sven
> 
> 
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
> 
> 

Re: [Pharo-project] the fun theory

[stephane ducasse]

excellent!

Yes we should make pharo a fun theory :)

Stef
On Apr 16, 2013, at 8:36 PM, Johan Brichau  wrote:

> When I saw this website, I immediately thought about Pharo
> 
> http://www.thefuntheory.com
> "This site is dedicated to the thought that something as simple as fun is the 
> easiest way to change people’s behaviour for the better."
> 
> Keep having fun!
> 
> Johan

Re: [Pharo-project] [pharo-project.org] tweaked download pages a bit...

[stephane ducasse]

thanks.

We should clean also the Pharo-Contribution CI ;)

Stef

On Apr 16, 2013, at 1:31 PM, Marcus Denker  wrote:

> Hi,
> 
> I changed a little the download pages
> 
> http://www.pharo-project.org/
> http://www.pharo-project.org/pharo-download
> http://www.pharo-project.org/pharo-download/release-2-0
> http://www.pharo-project.org/pharo-download/alpha-3-0
> 
> -> Do not present a choice to the new visitor but make it clear what to 
> download
> -> be a bit more consistent between the 4 places
> 
> 

Re: [Pharo-project] [update 3.0] #30042

[stephane ducasse]

On Apr 16, 2013, at 4:30 PM, Benjamin  
wrote:

> Cool :)
> 
> Next step: Athens :)

YES

but igor knows it :)

> 
> Ben
> 
> On Apr 16, 2013, at 4:22 PM, Igor Stasenko  wrote:
> 
>> On 16 April 2013 15:32, Esteban Lorenzano  wrote:
>>> 30042
>>> -
>>> 
>>> 10028 Integrate Opal
>>>https://pharo.fogbugz.com/f/cases/10028
>>> 
>>> (remove destructive tests)
>>> 
>> 
>> YESSS!!
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Best regards,
>> Igor Stasenko.
>> 
> 

Re: [Pharo-project] Metacello configuration conventions

[stephane ducasse]

Christophe I agree with you 

> As a general purpose reflexion on dependencies conventions, I would say:
> If you are in development mode, it makes sense to rely on latest versions of 
> dependencies (bleeding edge) to be able to detect integration problems as 
> soon as possible.
> If you are in a release mode, you should ensure that your code can run at 
> least on fixed dependencies versions (at the best, specify a range of 
> versions you can use with possibly no upper limit if your dependencies ensure 
> backward compatibility). You need reproducible loading of your tool/lib.
> in my opinion, you shouldn't use #stable for release version as the only 
> thing it ensure (if well tested) is that you will not have a broken version 
> of the dependency. The stable version of your dependency will evolve and then 
> the configuration of your release too. At a time, your version will not be 
> usable at all because of that.

Because even if you milestone against a major version, 
what you mean is that the package may change (and still 
work on 20 for example, but be incompatible with your software).

I will write something in the metacello chapter and see what I 
wrote on symbolic version.


> so I would specify a dependency with a versionString for release versions of 
> your lib/tool. It ensures a minimum version.

So I wonder when we should use stable.
Versionner will solve all these points for us :)

Stef



> 
> Regards,
> Christophe.
> 
> Le 16 avr. 2013 à 11:02, Frank Shearar a écrit :
> 
>> On 16 April 2013 09:53, Stephan Eggermont  wrote:
>>> Hi,
>>> 
>>> While working with Diego on some configurations, we noticed two different 
>>> styles
>>> of describing the latest non-baseline versions.
>>> 
>>> In one, the versionString version of a dependency is used.
>>> That is a defensive strategy, where you want to specify the exact version 
>>> that
>>> will be loaded (and has been tested).
>>> 
>>> In the other the #stable version is used. That is an optimistic strategy.
>>> This is much less brittle (but might suddenly not work anymore).
>>> 
>>> Seaside uses defensive/mixed, while Magritte uses optimistic
>>> 
>>> Based on what criteria should I choose which one to use (in a Pharo 
>>> context)?
>> 
>> I'd argue that since you're declaring that a certain set of versions
>> of packages work together, you should _always_ use explicit versions.
>> The "optimistic" strategy leaves you vulnerable to third parties
>> making seemingly innocuous changes that break your code. (I've been
>> bitten by this, by making such an apparently innocuous change.)
>> 
>> frank
>> 
>>> Stephan & Diego
>> 
>