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

[Veronica Isabel Uquillas Gomez]

Hi Henry

Indeed you are right, and that prerequisite is the only one which is overriding 
code...
I was doing some tests, and I think I can remove it for a core image 
configuration, will discuss with Tudor

regards,
Veronica

On 18 May 2010, at 14:58, Henrik Johansen wrote:

> In particular, this prereq in ConfigurationOfGlamour caused it:
> baseline20beta4: spec
>   spec for: #common do: [
>   *snip*
>   spec package: 'Morphic-MorphTreeWidget' with: [
>   spec repository: 'http://squeaksource.com/Momo10'];
>   *snip*
> ]
> 
> As I said, since MorphTreeWidget is already part of 1.1Core, this caused an 
> older version of the widget to load.
> 
> Since Settings Browser uses methods found in the newer version in Core, 
> loading Glamour caused it to DNU when I tried opening a Settings Browser.
> 
> Cheers,
> Henry
> 
> 
> On May 18, 2010, at 2:41 15PM, Henrik Johansen wrote:
> 
>> Yes, that is where it broke
>> 
>> 
>> On May 18, 2010, at 2:32 30PM, Stéphane Ducasse wrote:
>> 
>>> henrik 
>>> 
>>> did you try on 1.1?
>>> 
>>> Stef
>>> 
>>> On May 18, 2010, at 1:00 PM, Henrik Johansen wrote:
>>> 
 
 
 Den 18.05.2010 12:12, skrev Mariano Martinez Peck:
> Hola Verónica!
> 
> I love it!!! nice, very nice :)
> 
> I will give you more feedback as far as I start to use it.
> The only thing I would add is a button in the MC. Look the attached
> screenshot. It would be cool not only to have it in the context menu,
> but in the MC broser...for example, next to "changes" button a "torch"
> button or something like that.
> 
> I really like it. Moose and all it tools seems to be working in Pharo
> 1.1 somaybe if people agree we can include this cool tool together
> with Mondrian and Glamour ?  They have 460 green tests :)
 Strange, for me it lead to errors in 1.1 because:
 - It depends on Momo10 (MorphTreeMorph)
 - This has been integrated into Morphic in 1.1
 - Loading Torch overrode the code in Morphic with code from Momo rep.
 - The "old" tree was missing methods (rowInset:) used by the settings
 browser, so that broke.
 
 S, Metacello tags with version info as well coming soon?
 I really haven't followed that discussion :)
 
 Cheers,
 Henry
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>> 
>>> 
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>> 
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

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

[Veronica Isabel Uquillas Gomez]

Hola Mariano,

Yup, I considered that but as there are already many buttons, I never tried..
Will try it anyway...

gracias,
Veronica

On 18 May 2010, at 12:12, Mariano Martinez Peck wrote:

> Hola Verónica!
> 
> I love it!!! nice, very nice :)
> 
> I will give you more feedback as far as I start to use it. 
> The only thing I would add is a button in the MC. Look the attached 
> screenshot. It would be cool not only to have it in the context menu, but in 
> the MC broser...for example, next to "changes" button a "torch" button or 
> something like that. 
> 
> I really like it. Moose and all it tools seems to be working in Pharo 1.1 
> somaybe if people agree we can include this cool tool together with 
> Mondrian and Glamour ?  They have 460 green tests :)
> 
> DEV
> 
> :)
> 
> On Tue, May 18, 2010 at 11:39 AM, Tudor Girba  wrote:
> Hi Veronica,
> 
> It is pretty impressive :).
> 
> Would it be Ok if I added this on the Moose page?
> 
> Cheers,
> Doru
> 
> 
> 
> On 18 May 2010, at 11:21, Stéphane Ducasse wrote:
> 
> Thanks veronica.
> lukas said that he was impressed this is a complement :)
> 
> On May 18, 2010, at 11:00 AM, Veronica Isabel Uquillas Gomez wrote:
> 
> Dear all,
> 
> I would like to announce Torch, a tool for supporting source-code change 
> integration. For now, it offers visualizations of the changes and enhanced 
> change lists.
> Torch can be accessed through Monticello (in the main MC browser, in the 
> repository browser or in the history browser). Selecting a version or slice, 
> you can view the changes with Torch using the contextual menu.
> Once you open the Torch dashboard, you can access the enhanced change list or 
> a detailed visualization via the contextual menu as well.
> 
> Torch is available on SqueakSource, the repository is named Torch, and you 
> need to load the ConfigurationOfTorch package.
> It runs in a dev or core image.
> 
> For a dev image.
> - ConfigurationOfTorch loadVersion10
> 
> For a core image.
> 1) Set fonts - described in the attached file.
> 2) ConfigurationOfTorch loadDefault
> 
> I would appreciate comments and feedback!
> 
> Best Regards,
> Verónica Uquillas Gómez
> Vrije University Brussel - SOFT Lab
> University of Lille - RMOD Team
> 
> 
> 
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> --
> www.tudorgirba.com
> 
> "Problem solving efficiency grows with the abstractness level of problem 
> understanding."
> 
> 
> 
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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

[Veronica Isabel Uquillas Gomez]

Hi Tudor,

- could you be more specific, when does the MC browser crash?, i haven't 
noticed any problem with it.
- Yup, Lukas created the AST-semantics package, and I have to include it
- No, I am not overriding code, that is a setting already included in Glamour, 
but true, the border is a cleaner solution... will take a look

thank you,
Veronica


On 19 May 2010, at 08:50, Stéphane Ducasse wrote:

> 
> On May 19, 2010, at 12:47 AM, Tudor Girba wrote:
> 
>> Hi Veronica,
>> 
>> A bit of feedback:
>> - After loading Torch, the package contextual menu seems to crash the 
>> Monticello Browser
>> - You extend isSuper in RBProgramNode and RBVariableNode, which generates an 
>> override conflict with methods in Moose-Core.
> 
> may be moose should have a look at the new AST-semantics package that lukas 
> created because veronica used that ones 
> originally and after a discussing with lukas he created ast-semantics
> 
>> - The Glamour tags look different, so I guess you also have some Glamour 
>> overrides. That should not happen :). Maybe you have some suggestions for 
>> improvement, or maybe you just need the border for the [i] icon?
>> 
>> Cheers,
>> Doru
>> 
>> 
>> On 18 May 2010, at 15:16, Veronica Isabel Uquillas Gomez wrote:
>> 
>>> Hi Tudor,
>>> 
>>> thank you :D
>>> 
>>> sure!!!
>>> 
>>> cheers,
>>> Veronica
>>> 
>>> 
>>> On 18 May 2010, at 11:39, Tudor Girba wrote:
>>> 
 Hi Veronica,
 
 It is pretty impressive :).
 
 Would it be Ok if I added this on the Moose page?
 
 Cheers,
 Doru
 
 
 On 18 May 2010, at 11:21, Stéphane Ducasse wrote:
 
> Thanks veronica.
> lukas said that he was impressed this is a complement :)
> 
> On May 18, 2010, at 11:00 AM, Veronica Isabel Uquillas Gomez wrote:
> 
>> Dear all,
>> 
>> I would like to announce Torch, a tool for supporting source-code change 
>> integration. For now, it offers visualizations of the changes and 
>> enhanced change lists.
>> Torch can be accessed through Monticello (in the main MC browser, in the 
>> repository browser or in the history browser). Selecting a version or 
>> slice, you can view the changes with Torch using the contextual menu.
>> Once you open the Torch dashboard, you can access the enhanced change 
>> list or a detailed visualization via the contextual menu as well.
>> 
>> Torch is available on SqueakSource, the repository is named Torch, and 
>> you need to load the ConfigurationOfTorch package.
>> It runs in a dev or core image.
>> 
>> For a dev image.
>> - ConfigurationOfTorch loadVersion10
>> 
>> For a core image.
>> 1) Set fonts - described in the attached file.
>> 2) ConfigurationOfTorch loadDefault
>> 
>> I would appreciate comments and feedback!
>> 
>> Best Regards,
>> Verónica Uquillas Gómez
>> Vrije University Brussel - SOFT Lab
>> University of Lille - RMOD Team
>> 
>> 
>> 
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 
 --
 www.tudorgirba.com
 
 "Problem solving efficiency grows with the abstractness level of problem 
 understanding."
 
 
 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>> 
>>> 
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> --
>> www.tudorgirba.com
>> 
>> "Problem solving efficiency grows with the abstractness level of problem 
>> understanding."
>> 
>> 
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] UUID on ubuntu 10.04

[Stéphane Ducasse]

Apparently the student reinstalled her ubuntu from scratch (no incremental 
installation) and the vm did not crash
anymore.

Stef

On May 17, 2010, at 9:16 PM, Stéphane Ducasse wrote:

> I asked the student to try.
> 
> Stef
> 
> On May 17, 2010, at 9:06 PM, laurent laffont wrote:
> 
>> On ArchLinux I have the problem when UUID is built external. Official 
>> 4.0.3.2202 Unix VM binaries on http://squeakvm.org/unix/ works well for me 
>> (UUID is internal).
>> 
>> Can you try with this one click image I made once (uses 4.0.3.2202 binaries) 
>> http://lolgzs.free.fr/pharo/Pharo-1.0-OneClick.zip
>> 
>> Laurent Laffont
>> 
>> http://pharocasts.blogspot.com/
>> http://magaloma.blogspot.com/
>> 
>> 
>> On Mon, May 17, 2010 at 8:24 PM, Stéphane Ducasse 
>>  wrote:
>> I can confirm that this is exactly the same trace than the one reported by 
>> laurent (no debug file).
>> 
>> Stef
>> On May 17, 2010, at 7:51 PM, David T. Lewis wrote:
>> 
>>> On Mon, May 17, 2010 at 07:38:59PM +0200, St?phane Ducasse wrote:
 Hi guys
 
 I took seaside the latest one click image and when I have to save a MC 
 package
 I get a core dump with UUID new:...
 I checke the so.UUIDplugin is there and I do not understand.
 Can somebody with a Ubuntu give a try to save something using MC and the 
 latest seaside one click.
>>> 
>>> Hi Stef,
>>> 
>>> This issue is being tracked here: http://bugs.squeak.org/view.php?id=7358
>>> 
>>> It is not clear to me if the issue is resolved in the Ian's latest VM
>>> build, so if you or anyone else can confirm the UUID crash happening
>>> with this VM, that would be helpful to clarify.
>>> 
>>> Dave
>>> 
>>> 
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

[Stéphane Ducasse]

excellent! Let us know this is good to get more support on the XML/DTD part.

Stef

On May 19, 2010, at 2:17 AM, jaayer wrote:

> 
> 
>  Forwarded message 
> From : jaayer
> To :  
> Date : Tue, 18 May 2010 16:30:06 -0700
> Subject : Re: Decoding bug with XMLParser ?
>  Forwarded message 
> 
>  On Tue, 18 May 2010 02:29:18 -0700 Alexandre Bergel 
>  wrote  
> 
>> To give a bit of context, the problem is: 
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-= 
>> exampleEncodedXML 
>> ^' 
>> … 
>> ' 
>> 
>> testDecodingCharacters 
>> | xmlDocument element | 
>> "XMLTokenizer testDecodingCharacters" 
>> 
>> xmlDocument := XMLDOMParser parseDocumentFrom: self exampleEncodedXML 
>> readStream. 
>> element := xmlDocument firstTagNamed: #'test-data'. 
>>  
>> self assert: element contentString first codePoint = 8230 
>> -=-=-=-=-=-=-=-=-=-=-=-= 
>> 
>> #testDecodingCharacters goes yellow 
>> 
>>> Thinking of it, it's not really an encoding problem, rather a bug in 
>>> the entity->character conversion. I guess there should be a similar 
>>> test where there is an actual ellipsis character in the xml, instead 
>>> of the entity. 
>> 
>> Any idea how your test can goes green? 
>> 
>>> And now I realize our server will not be able to connect outside its 
>>> DMZ, so I won't be able to use the fix :D 
>> 
>> DMZ ? 
>> 
>> Cheers, 
>> Alexandre 
>> 
> 
> Character references like the one above are handled using #nextCharReference. 
> It does so by reading the number after the "&#" or "&x" prefix and then 
> sending #value: to the class Unicode with that as the argument. If you 
> evaluate the following code in a workspace with cmd-p: "(Unicode value: 8230) 
> codePoint", you will see that the resulting code point is not what you would 
> expect. For me it was "1069555750". The same behavior results when creating a 
> Unicode character with #charFromUnicode:. Unless Unicode>>value: and 
> Unicode>>charFromUnicode: are being used incorrectly, I am not sure that this 
> is a bug, or least a bug in XML-Support.
> 
> (I am working on adding full DTD support with validation and refactoring and 
> re-engineering the parser at the moment, which is why minor releases have 
> slowed to a trickle. I will take a closer look at how character encoding is 
> handled in the process.)
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

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

[Stéphane Ducasse]

do not add more buttons 
It would be better to use  and cretae them automatically then yous would 
just be added dynamically.

Stef
On May 19, 2010, at 9:30 AM, Veronica Isabel Uquillas Gomez wrote:

> Hola Mariano,
> 
> Yup, I considered that but as there are already many buttons, I never tried..
> Will try it anyway...
> 
> gracias,
> Veronica
> 
> On 18 May 2010, at 12:12, Mariano Martinez Peck wrote:
> 
>> Hola Verónica!
>> 
>> I love it!!! nice, very nice :)
>> 
>> I will give you more feedback as far as I start to use it. 
>> The only thing I would add is a button in the MC. Look the attached 
>> screenshot. It would be cool not only to have it in the context menu, but in 
>> the MC broser...for example, next to "changes" button a "torch" button or 
>> something like that. 
>> 
>> I really like it. Moose and all it tools seems to be working in Pharo 1.1 
>> somaybe if people agree we can include this cool tool together with 
>> Mondrian and Glamour ?  They have 460 green tests :)
>> 
>> DEV
>> 
>> :)
>> 
>> On Tue, May 18, 2010 at 11:39 AM, Tudor Girba  wrote:
>> Hi Veronica,
>> 
>> It is pretty impressive :).
>> 
>> Would it be Ok if I added this on the Moose page?
>> 
>> Cheers,
>> Doru
>> 
>> 
>> 
>> On 18 May 2010, at 11:21, Stéphane Ducasse wrote:
>> 
>> Thanks veronica.
>> lukas said that he was impressed this is a complement :)
>> 
>> On May 18, 2010, at 11:00 AM, Veronica Isabel Uquillas Gomez wrote:
>> 
>> Dear all,
>> 
>> I would like to announce Torch, a tool for supporting source-code change 
>> integration. For now, it offers visualizations of the changes and enhanced 
>> change lists.
>> Torch can be accessed through Monticello (in the main MC browser, in the 
>> repository browser or in the history browser). Selecting a version or slice, 
>> you can view the changes with Torch using the contextual menu.
>> Once you open the Torch dashboard, you can access the enhanced change list 
>> or a detailed visualization via the contextual menu as well.
>> 
>> Torch is available on SqueakSource, the repository is named Torch, and you 
>> need to load the ConfigurationOfTorch package.
>> It runs in a dev or core image.
>> 
>> For a dev image.
>> - ConfigurationOfTorch loadVersion10
>> 
>> For a core image.
>> 1) Set fonts - described in the attached file.
>> 2) ConfigurationOfTorch loadDefault
>> 
>> I would appreciate comments and feedback!
>> 
>> Best Regards,
>> Verónica Uquillas Gómez
>> Vrije University Brussel - SOFT Lab
>> University of Lille - RMOD Team
>> 
>> 
>> 
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> --
>> www.tudorgirba.com
>> 
>> "Problem solving efficiency grows with the abstractness level of problem 
>> understanding."
>> 
>> 
>> 
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] UUID on ubuntu 10.04

[laurent laffont]

On Wed, May 19, 2010 at 9:42 AM, Stéphane Ducasse  wrote:

> Apparently the student reinstalled her ubuntu from scratch (no incremental
> installation) and the vm did not crash
> anymore.
>

:( so we cannot reproduce the bug on Ubuntu now 

Laurent


>
> Stef
>
> On May 17, 2010, at 9:16 PM, Stéphane Ducasse wrote:
>
> > I asked the student to try.
> >
> > Stef
> >
> > On May 17, 2010, at 9:06 PM, laurent laffont wrote:
> >
> >> On ArchLinux I have the problem when UUID is built external. Official
> 4.0.3.2202 Unix VM binaries on http://squeakvm.org/unix/ works well for me
> (UUID is internal).
> >>
> >> Can you try with this one click image I made once (uses 4.0.3.2202
> binaries) http://lolgzs.free.fr/pharo/Pharo-1.0-OneClick.zip
> >>
> >> Laurent Laffont
> >>
> >> http://pharocasts.blogspot.com/
> >> http://magaloma.blogspot.com/
> >>
> >>
> >> On Mon, May 17, 2010 at 8:24 PM, Stéphane Ducasse <
> stephane.duca...@inria.fr> wrote:
> >> I can confirm that this is exactly the same trace than the one reported
> by laurent (no debug file).
> >>
> >> Stef
> >> On May 17, 2010, at 7:51 PM, David T. Lewis wrote:
> >>
> >>> On Mon, May 17, 2010 at 07:38:59PM +0200, St?phane Ducasse wrote:
>  Hi guys
> 
>  I took seaside the latest one click image and when I have to save a MC
> package
>  I get a core dump with UUID new:...
>  I checke the so.UUIDplugin is there and I do not understand.
>  Can somebody with a Ubuntu give a try to save something using MC and
> the latest seaside one click.
> >>>
> >>> Hi Stef,
> >>>
> >>> This issue is being tracked here:
> http://bugs.squeak.org/view.php?id=7358
> >>>
> >>> It is not clear to me if the issue is resolved in the Ian's latest VM
> >>> build, so if you or anyone else can confirm the UUID crash happening
> >>> with this VM, that would be helpful to clarify.
> >>>
> >>> Dave
> >>>
> >>>
> >>> ___
> >>> Pharo-project mailing list
> >>> Pharo-project@lists.gforge.inria.fr
> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>
> >>
> >> ___
> >> Pharo-project mailing list
> >> Pharo-project@lists.gforge.inria.fr
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>
> >> ___
> >> Pharo-project mailing list
> >> Pharo-project@lists.gforge.inria.fr
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Pharo 1.1: String-> arithmetic

[Veronica Isabel Uquillas Gomez]

Hi Stef,

In Pharo 1.1 the class String has not the protocol arithmetic and its 
methods... why?
Got errors when running some tests. Could I add them with a new version of 
Torch?

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

Re: [Pharo-project] Pharo 1.1: String-> arithmetic

[Stéphane Ducasse]

because 

'abc' * 2 does not make sense.
and because this was limited anyway.

better use plain collect:...

> Hi Stef,
> 
> In Pharo 1.1 the class String has not the protocol arithmetic and its 
> methods... why?
> Got errors when running some tests. Could I add them with a new version of 
> Torch?

I would prefer not.

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


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

Re: [Pharo-project] Pharo 1.1: String-> arithmetic

[Fernando olivero]

Hola Vero, check out the Collection arithmethic method category  emails of the 
previous days.
(http://code.google.com/p/pharo/issues/detail?id=332)
Saludos,
Fernando

On May 19, 2010, at 10:26 AM, Veronica Isabel Uquillas Gomez wrote:

> Hi Stef,
> 
> In Pharo 1.1 the class String has not the protocol arithmetic and its 
> methods... why?
> Got errors when running some tests. Could I add them with a new version of 
> Torch?
> 
> Vero
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

Re: [Pharo-project] Pharo 1.1: String-> arithmetic

[Veronica Isabel Uquillas Gomez]

On 19 May 2010, at 10:35, Stéphane Ducasse wrote:

> because 
> 
> 'abc' * 2 does not make sense.
> and because this was limited anyway.
> 
> better use plain collect:...

I am not using them... it is in one of my prerequisites...

> 
>> Hi Stef,
>> 
>> In Pharo 1.1 the class String has not the protocol arithmetic and its 
>> methods... why?
>> Got errors when running some tests. Could I add them with a new version of 
>> Torch?
> 
> I would prefer not.

ok!!

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


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

Re: [Pharo-project] Pharo 1.1: String-> arithmetic

[Veronica Isabel Uquillas Gomez]

gracias Fernando...
it is clear now!!

Vero

On 19 May 2010, at 10:49, Fernando olivero wrote:

> Hola Vero, check out the Collection arithmethic method category  emails of 
> the previous days.
> (http://code.google.com/p/pharo/issues/detail?id=332)
> Saludos,
> Fernando
> 
> On May 19, 2010, at 10:26 AM, Veronica Isabel Uquillas Gomez wrote:
> 
>> Hi Stef,
>> 
>> In Pharo 1.1 the class String has not the protocol arithmetic and its 
>> methods... why?
>> Got errors when running some tests. Could I add them with a new version of 
>> Torch?
>> 
>> Vero
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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

[Veronica Isabel Uquillas Gomez]

On 18 May 2010, at 12:55, Stéphane Ducasse wrote:

> veronica 
> 
> I would love to have the two clouds on the same page :)

or maybe mixed together, and you see the symbols in greed and red!!

> Doru we are looking for a nice way to represent the left top corner (which 
> summarize the changes) if you have any idea.

thinking to add icons and tags in that panel, instead of plain text

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


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

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

[Levente Uzonyi]

On Wed, 19 May 2010, Stéphane Ducasse wrote:


Another "hard to quote" message, but I hope my answer will be clear.
The "problem" is that in Pharo the leadingChar for unicode characters is still 
255. This was changed in Squeak 4.1 to 0. So in Squeak 4.1:
(Unicode value: 8230) codePoint. "===> 8230"

While in Pharo it's:
(Unicode value: 8230) codePoint. "===> 1069555750"
(Character value: 1069555750) charCode. "===> 8230"
(Character value: 1069555750) leadingChar. "===> 255"

So using #charCode instead of #codePoint is the solution.


Thanks levente.
In Pharo 1.1 we get the same as in squeak.

(Unicode value: 8230) codePoint. "===> 1069555750"
(Character value: 1069555750) charCode. "===> 8230"
(Character value: 1069555750) leadingChar. "===> 255"




0 locale encoded by 0 is Unicode

initialize

self allSubclassesDo: [:each | each initialize].

EncodedCharSets := Array new: 256.

EncodedCharSets at: 0+1 put: Unicode "Latin1Environment".
EncodedCharSets at: 1+1 put: JISX0208.
EncodedCharSets at: 2+1 put: GB2312.
EncodedCharSets at: 3+1 put: KSX1001.
EncodedCharSets at: 4+1 put: JISX0208.
EncodedCharSets at: 5+1 put: JapaneseEnvironment.
EncodedCharSets at: 6+1 put: SimplifiedChineseEnvironment.
EncodedCharSets at: 7+1 put: KoreanEnvironment.
EncodedCharSets at: 8+1 put: GB2312.
"EncodedCharSets at: 9+1 put: UnicodeTraditionalChinese."
"EncodedCharSets at: 10+1 put: UnicodeVietnamese."
EncodedCharSets at: 12+1 put: KSX1001.
EncodedCharSets at: 13+1 put: GreekEnvironment.
EncodedCharSets at: 14+1 put: Latin2Environment.
EncodedCharSets at: 15+1 put: RussianEnvironment.
EncodedCharSets at: 16+1 put: NepaleseEnvironment.
EncodedCharSets at: 256 put: Unicode.





Now I was wondering why in squeak and pharo
(Character value: 1069555750) leadingChar. "===> 255"


Because the 22 least significant bits represent the #charCode and the 
rest (8 bits) are the #leadingChar. So 1069555750 means that #charCode 
is 8230 and the #leadingChar is 255.



Levente



stef




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

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

[Alexandre Bergel]

>> 
>> Now I was wondering why in squeak and pharo
>>  (Character value: 1069555750) leadingChar. "===> 255"
> 
> Because the 22 least significant bits represent the #charCode and the rest (8 
> bits) are the #leadingChar. So 1069555750 means that #charCode is 8230 and 
> the #leadingChar is 255.

Pfff... Remind me the old assembly lecture :-)

Thank you all for your comment. I will fix the test.

Alexandre


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


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

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

[Stéphane Ducasse]

I always liked 68000 when I imagine my codev implemented our game in 
overall 30 assembly line of code
and also using 6502 with 3 registers and one specific...
68000 was a dream :)

Stef

On May 19, 2010, at 12:28 PM, Alexandre Bergel wrote:

>>> 
>>> Now I was wondering why in squeak and pharo
>>> (Character value: 1069555750) leadingChar. "===> 255"
>> 
>> Because the 22 least significant bits represent the #charCode and the rest 
>> (8 bits) are the #leadingChar. So 1069555750 means that #charCode is 8230 
>> and the #leadingChar is 255.
> 
> Pfff... Remind me the old assembly lecture :-)
> 
> Thank you all for your comment. I will fix the test.
> 
> Alexandre
> 
> 
>> 
>> 
>> Levente
>> 
>>> 
>>> stef
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] problem with CompiledMethod equality

[Nicolas Cellier]

Hi Eliot,
What about super sends ?

Object>>beNasty
^self

Collection>>beNasty
 self addLast; 1.
 super beNasty.

OrderedCollection>>beNasty
 self addLast; 1.
 super beNasty.

Do you think you can remove OrderedCollection>>beNasty ?

Nicolas

2010/5/19 Stéphane Ducasse :
> Elliot I think that we already took into changes made by nicolas.
>
> Stef
>
> On May 19, 2010, at 2:35 AM, Eliot Miranda wrote:
>
>> Hi Lukas,
>>
>> On Tue, May 18, 2010 at 8:17 AM, Lukas Renggli  wrote:
>> > Same method in different classes do not  equal eachother though, if I've 
>> > not made a mistake in:
>> >
>> > |mrtCp|
>> > mrtCp := (InstructionClient>>#methodReturnTop) copy.
>> > mrtCp literalAt: 2 put: #ContextPart->ContextPart.
>> > (InstructionClient>>#methodReturnTop) = mrtCp
>>
>> For methods that send super the behavior changes if you change the
>> class binding. That's probably why it is not ignored for #=.
>>
>> In fact I would suggest to #= from compiled method altogether, in most
>> cases it doesn't do what one would expect in a given context anyway.
>> There are too many and possibility completely different
>> interpretations of #= for CompiledMethod. #== is the only decent
>> implementation for this class.
>>
>> I sympathise but I think there is a reasonable default interpretation of #= 
>> for CompiledMethod that is what most people want.  The intent is to answer 
>> whether two methods have the same execution semantics and same method tags & 
>> properties, e.g. if one were to compile the same source code in two 
>> different classes that had the same inst var offsets for the inst vars in 
>> the methods, then one would want those methods to be #=.  This allows tests 
>> such as
>> - checking whether a subclass has a method that is #= to a superclass, and 
>> is hence redundant.
>> - checking whether a set of sourceless methods are equivalent so that they 
>> may be shared under different selectors (e.g. think auto-generated accessor 
>> methods which can be cached and shared)
>> So for this informal definition the selector and the class are irrelevant, 
>> but bytecodes and literals (apart from the selector and method class 
>> literals) are relevant.  Its almost a short-cut comparison of error-free 
>> decompilation, although there are differences in the bytecode that wouldn't 
>> show in decompilation (e.g. using long branches for short branches).
>>
>> The current definition serves for compiler hackers as it tells you 
>> accurately whether a compiler change has an effect on the bytecode, can be 
>> used to test whether compilation followed by decompilation followed by 
>> recompilation has an effect, etc.  While it may not be a universal code 
>> comparison method it has met my needs throughout the closure compiler so at 
>> least I'm pretty happy with it.
>>
>> (pleading for CompiledMethod>>#= to stay the same as the current Squeak 4.1 
>> definition, which ever since Nichoas Celier's float compilation changes, is 
>> pretty darned good).
>>
>> best
>> Eliot
>>
>>
>>
>>
>>
>> Lukas
>>
>> >
>> > At the very least, the branches of
>> > index = 1 and: [ #(117 120) includes: self primitive ])
>> >                                        ifTrue: [
>> >
>> > REALLY deserve some comments...
>> >
>> > Cheers,
>> > Henry
>> >
>> >
>> >
>> > ___
>> > Pharo-project mailing list
>> > Pharo-project@lists.gforge.inria.fr
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>>
>>
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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

[Pharo-project] about condenseChanges

[Stéphane Ducasse]

Hi marcus/others

I did a condenseChanges and I'm planning to issue a new image. I wanted to 
avoid to put it in the stream of updates
because since it takes a long time everybody can be penalized but at the same 
time we will not have the same flow
if we start from 1.0 and press update.
Thoughts?

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

[Pharo-project] about menu not showing up

[Stéphane Ducasse]

Hi alain

in scriptLoader I added a menu and I do not why it was working and now it does 
not show up.
Can yu have a look?
Normally you should do ScriptLoader showIntegrationMenu

Tx

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

[Pharo-project] [update 1.1] #11367

[stephane ducasse]

11367
-

- Issue 2435:   Cleanup for release does not work due to changes in 
NaturalLanguageTranslator
-  Issue 2442:  Add an help entry in WorldMenu
- condense changes

I will issue a new image soon


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

Re: [Pharo-project] about condenseChanges

[Henrik Johansen]

On May 19, 2010, at 2:05 33PM, Stéphane Ducasse wrote:

> Hi marcus/others
> 
> I did a condenseChanges and I'm planning to issue a new image. I wanted to 
> avoid to put it in the stream of updates
> because since it takes a long time everybody can be penalized but at the same 
> time we will not have the same flow
> if we start from 1.0 and press update.
> Thoughts?
> 
> Stef
Is it really necessary?
The difference in a zipped archive together with the image is a meager 1.2MB.
I personally really don't mind the 5MB extra of spent diskspace for the 
uncondensed .changes file...

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

Re: [Pharo-project] about condenseChanges

[Stéphane Ducasse]

Yes I thought about that too.
Now I done it to remove strange compiled methods floating around.

Stef

On May 19, 2010, at 2:37 PM, Henrik Johansen wrote:

> On May 19, 2010, at 2:05 33PM, Stéphane Ducasse wrote:
> 
>> Hi marcus/others
>> 
>> I did a condenseChanges and I'm planning to issue a new image. I wanted to 
>> avoid to put it in the stream of updates
>> because since it takes a long time everybody can be penalized but at the 
>> same time we will not have the same flow
>> if we start from 1.0 and press update.
>> Thoughts?
>> 
>> Stef
> Is it really necessary?
> The difference in a zipped archive together with the image is a meager 1.2MB.
> I personally really don't mind the 5MB extra of spent diskspace for the 
> uncondensed .changes file...
> 
> Cheers,
> Henry
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] about condenseChanges

[Marcus Denker]

On May 19, 2010, at 2:42 PM, Stéphane Ducasse wrote:

> Yes I thought about that too.
> Now I done it to remove strange compiled methods floating around.
> 

But that's done with #cleanUpForRelease it removes all changesets, then the 
CMs that are referenced
by them are GCed.

Marcus


> Stef
> 
> On May 19, 2010, at 2:37 PM, Henrik Johansen wrote:
> 
>> On May 19, 2010, at 2:05 33PM, Stéphane Ducasse wrote:
>> 
>>> Hi marcus/others
>>> 
>>> I did a condenseChanges and I'm planning to issue a new image. I wanted to 
>>> avoid to put it in the stream of updates
>>> because since it takes a long time everybody can be penalized but at the 
>>> same time we will not have the same flow
>>> if we start from 1.0 and press update.
>>> Thoughts?
>>> 
>>> Stef
>> Is it really necessary?
>> The difference in a zipped archive together with the image is a meager 1.2MB.
>> I personally really don't mind the 5MB extra of spent diskspace for the 
>> uncondensed .changes file...
>> 
>> Cheers,
>> Henry
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


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

[Pharo-project] CollaborActive Book ...

[Geert Claes]

Is there an easier way to upload, insert and replace pictures in the
Collaboractive Book?
-- 
View this message in context: 
http://forum.world.st/CollaborActive-Book-tp835p835.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

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

Re: [Pharo-project] UUID on ubuntu 10.04

[David T. Lewis]

Thanks, I marked the issue as resolved and summarized the status here:

  http://bugs.squeak.org/view.php?id=7358

Dave

On Wed, May 19, 2010 at 09:42:28AM +0200, St?phane Ducasse wrote:
> Apparently the student reinstalled her ubuntu from scratch (no incremental 
> installation) and the vm did not crash
> anymore.
> 
> Stef
> 
> On May 17, 2010, at 9:16 PM, St?phane Ducasse wrote:
> 
> > I asked the student to try.
> > 
> > Stef
> > 
> > On May 17, 2010, at 9:06 PM, laurent laffont wrote:
> > 
> >> On ArchLinux I have the problem when UUID is built external. Official 
> >> 4.0.3.2202 Unix VM binaries on http://squeakvm.org/unix/ works well for me 
> >> (UUID is internal).
> >> 
> >> Can you try with this one click image I made once (uses 4.0.3.2202 
> >> binaries) http://lolgzs.free.fr/pharo/Pharo-1.0-OneClick.zip
> >> 
> >> Laurent Laffont
> >> 
> >> http://pharocasts.blogspot.com/
> >> http://magaloma.blogspot.com/
> >> 
> >> 
> >> On Mon, May 17, 2010 at 8:24 PM, St?phane Ducasse 
> >>  wrote:
> >> I can confirm that this is exactly the same trace than the one reported by 
> >> laurent (no debug file).
> >> 
> >> Stef
> >> On May 17, 2010, at 7:51 PM, David T. Lewis wrote:
> >> 
> >>> On Mon, May 17, 2010 at 07:38:59PM +0200, St?phane Ducasse wrote:
>  Hi guys
>  
>  I took seaside the latest one click image and when I have to save a MC 
>  package
>  I get a core dump with UUID new:...
>  I checke the so.UUIDplugin is there and I do not understand.
>  Can somebody with a Ubuntu give a try to save something using MC and the 
>  latest seaside one click.
> >>> 
> >>> Hi Stef,
> >>> 
> >>> This issue is being tracked here: http://bugs.squeak.org/view.php?id=7358
> >>> 
> >>> It is not clear to me if the issue is resolved in the Ian's latest VM
> >>> build, so if you or anyone else can confirm the UUID crash happening
> >>> with this VM, that would be helpful to clarify.
> >>> 
> >>> Dave

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

Re: [Pharo-project] problem with CompiledMethod equality

[Eliot Miranda]

On Wed, May 19, 2010 at 4:58 AM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

> Hi Eliot,
> What about super sends ?
>
> Object>>beNasty
>^self
>
> Collection>>beNasty
> self addLast; 1.
> super beNasty.
>
> OrderedCollection>>beNasty
> self addLast; 1.
> super beNasty.
>

Good point.  I still find the existing #= definition very useful for
compiler verification.


>
> Do you think you can remove OrderedCollection>>beNasty ?
>
> Nicolas
>
> 2010/5/19 Stéphane Ducasse :
> > Elliot I think that we already took into changes made by nicolas.
> >
> > Stef
> >
> > On May 19, 2010, at 2:35 AM, Eliot Miranda wrote:
> >
> >> Hi Lukas,
> >>
> >> On Tue, May 18, 2010 at 8:17 AM, Lukas Renggli 
> wrote:
> >> > Same method in different classes do not  equal eachother though, if
> I've not made a mistake in:
> >> >
> >> > |mrtCp|
> >> > mrtCp := (InstructionClient>>#methodReturnTop) copy.
> >> > mrtCp literalAt: 2 put: #ContextPart->ContextPart.
> >> > (InstructionClient>>#methodReturnTop) = mrtCp
> >>
> >> For methods that send super the behavior changes if you change the
> >> class binding. That's probably why it is not ignored for #=.
> >>
> >> In fact I would suggest to #= from compiled method altogether, in most
> >> cases it doesn't do what one would expect in a given context anyway.
> >> There are too many and possibility completely different
> >> interpretations of #= for CompiledMethod. #== is the only decent
> >> implementation for this class.
> >>
> >> I sympathise but I think there is a reasonable default interpretation of
> #= for CompiledMethod that is what most people want.  The intent is to
> answer whether two methods have the same execution semantics and same method
> tags & properties, e.g. if one were to compile the same source code in two
> different classes that had the same inst var offsets for the inst vars in
> the methods, then one would want those methods to be #=.  This allows tests
> such as
> >> - checking whether a subclass has a method that is #= to a superclass,
> and is hence redundant.
> >> - checking whether a set of sourceless methods are equivalent so that
> they may be shared under different selectors (e.g. think auto-generated
> accessor methods which can be cached and shared)
> >> So for this informal definition the selector and the class are
> irrelevant, but bytecodes and literals (apart from the selector and method
> class literals) are relevant.  Its almost a short-cut comparison of
> error-free decompilation, although there are differences in the bytecode
> that wouldn't show in decompilation (e.g. using long branches for short
> branches).
> >>
> >> The current definition serves for compiler hackers as it tells you
> accurately whether a compiler change has an effect on the bytecode, can be
> used to test whether compilation followed by decompilation followed by
> recompilation has an effect, etc.  While it may not be a universal code
> comparison method it has met my needs throughout the closure compiler so at
> least I'm pretty happy with it.
> >>
> >> (pleading for CompiledMethod>>#= to stay the same as the current Squeak
> 4.1 definition, which ever since Nichoas Celier's float compilation changes,
> is pretty darned good).
> >>
> >> best
> >> Eliot
> >>
> >>
> >>
> >>
> >>
> >> Lukas
> >>
> >> >
> >> > At the very least, the branches of
> >> > index = 1 and: [ #(117 120) includes: self primitive ])
> >> >ifTrue: [
> >> >
> >> > REALLY deserve some comments...
> >> >
> >> > Cheers,
> >> > Henry
> >> >
> >> >
> >> >
> >> > ___
> >> > Pharo-project mailing list
> >> > Pharo-project@lists.gforge.inria.fr
> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >> >
> >>
> >>
> >>
> >> --
> >> Lukas Renggli
> >> www.lukas-renggli.ch
> >>
> >> ___
> >> Pharo-project mailing list
> >> Pharo-project@lists.gforge.inria.fr
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>
> >> ___
> >> Pharo-project mailing list
> >> Pharo-project@lists.gforge.inria.fr
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] [Gofer] loading only from package cache but with the same expression

[Stéphane Ducasse]

Hi lukas

is it possible that for an expression that would work if we get network Gofer 
looks only in the package cache. 
so that when you do not have internet but are sure that the files you need are 
in the package cache
you can use gofer to load them

I thought is was working but this is not that clear. I could not make it work 
in the library.

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

Re: [Pharo-project] [Gofer] loading only from package cache but with the same expression

[Lukas Renggli]

The default Gofer only uses the package cache:

   Gofer new repositories
--> an Array(a
MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache))

If you specify other repositories they are tried in that order as well:

   Gofer new renggli: 'ob'; squeaksource: 'rb'; repositories
   -->  an Array(a
MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache)
a MCHttpRepository(http://source.lukas-renggli.ch/ob) a
MCHttpRepository(http://www.squeaksource.com/rb))

If you disable the package cache, the package cache is ignored:

   Gofer new disablePackageCache; renggli: 'ob'; squeaksource: 'rb';
repositories
   --> an Array(a MCHttpRepository(http://source.lukas-renggli.ch/ob)
a MCHttpRepository(http://www.squeaksource.com/rb))

If you disable repository errors inaccessible repositories are ignored
and don't throw an error (you have to tell that though):

  Gofer new disableRepositoryErrors; renggli: 'ob'; squeaksource:
'rb'; repositories
  -->  an Array(a
MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache)
a MCHttpRepository(http://source.lukas-renggli.ch/ob) a
MCHttpRepository(http://www.squeaksource.com/rb))

Lukas

On 19 May 2010 16:59, Stéphane Ducasse  wrote:
> Hi lukas
>
> is it possible that for an expression that would work if we get network Gofer 
> looks only in the package cache.
> so that when you do not have internet but are sure that the files you need 
> are in the package cache
> you can use gofer to load them
>
> I thought is was working but this is not that clear. I could not make it work 
> in the library.
>
> Stef
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Lukas Renggli
www.lukas-renggli.ch

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

Re: [Pharo-project] UUID on ubuntu 10.04

[Stéphane Ducasse]

I'm not sure that it is resolved. It would be good to make sure that the system 
does not crash
even without reporting a log. May be having a stupid UUID generator as a 
fallback would be good.

Stef

> Thanks, I marked the issue as resolved and summarized the status here:
> 
>  http://bugs.squeak.org/view.php?id=7358
> 
> Dave
> 
> On Wed, May 19, 2010 at 09:42:28AM +0200, St?phane Ducasse wrote:
>> Apparently the student reinstalled her ubuntu from scratch (no incremental 
>> installation) and the vm did not crash
>> anymore.
>> 
>> Stef
>> 
>> On May 17, 2010, at 9:16 PM, St?phane Ducasse wrote:
>> 
>>> I asked the student to try.
>>> 
>>> Stef
>>> 
>>> On May 17, 2010, at 9:06 PM, laurent laffont wrote:
>>> 
 On ArchLinux I have the problem when UUID is built external. Official 
 4.0.3.2202 Unix VM binaries on http://squeakvm.org/unix/ works well for me 
 (UUID is internal).
 
 Can you try with this one click image I made once (uses 4.0.3.2202 
 binaries) http://lolgzs.free.fr/pharo/Pharo-1.0-OneClick.zip
 
 Laurent Laffont
 
 http://pharocasts.blogspot.com/
 http://magaloma.blogspot.com/
 
 
 On Mon, May 17, 2010 at 8:24 PM, St?phane Ducasse 
  wrote:
 I can confirm that this is exactly the same trace than the one reported by 
 laurent (no debug file).
 
 Stef
 On May 17, 2010, at 7:51 PM, David T. Lewis wrote:
 
> On Mon, May 17, 2010 at 07:38:59PM +0200, St?phane Ducasse wrote:
>> Hi guys
>> 
>> I took seaside the latest one click image and when I have to save a MC 
>> package
>> I get a core dump with UUID new:...
>> I checke the so.UUIDplugin is there and I do not understand.
>> Can somebody with a Ubuntu give a try to save something using MC and the 
>> latest seaside one click.
> 
> Hi Stef,
> 
> This issue is being tracked here: http://bugs.squeak.org/view.php?id=7358
> 
> It is not clear to me if the issue is resolved in the Ian's latest VM
> build, so if you or anyone else can confirm the UUID crash happening
> with this VM, that would be helpful to clarify.
> 
> Dave
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] [Gofer] loading only from package cache but with the same expression

[Stéphane Ducasse]

Yes I know all that now should I disable errors to get it loading only from the 
local cache?

> If you disable repository errors inaccessible repositories are ignored
> and don't throw an error (you have to tell that though):
but does it still load from the local-cache?


Stef


On May 19, 2010, at 6:14 PM, Lukas Renggli wrote:

> The default Gofer only uses the package cache:
> 
>   Gofer new repositories
>--> an Array(a
> MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache))
> 
> If you specify other repositories they are tried in that order as well:
> 
>   Gofer new renggli: 'ob'; squeaksource: 'rb'; repositories
>   -->  an Array(a
> MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache)
> a MCHttpRepository(http://source.lukas-renggli.ch/ob) a
> MCHttpRepository(http://www.squeaksource.com/rb))
> 
> If you disable the package cache, the package cache is ignored:
> 
>   Gofer new disablePackageCache; renggli: 'ob'; squeaksource: 'rb';
> repositories
>   --> an Array(a MCHttpRepository(http://source.lukas-renggli.ch/ob)
> a MCHttpRepository(http://www.squeaksource.com/rb))
> 
> If you disable repository errors inaccessible repositories are ignored
> and don't throw an error (you have to tell that though):
> 
>  Gofer new disableRepositoryErrors; renggli: 'ob'; squeaksource:
> 'rb'; repositories
>  -->  an Array(a
> MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache)
> a MCHttpRepository(http://source.lukas-renggli.ch/ob) a
> MCHttpRepository(http://www.squeaksource.com/rb))
> 
> Lukas
> 
> On 19 May 2010 16:59, Stéphane Ducasse  wrote:
>> Hi lukas
>> 
>> is it possible that for an expression that would work if we get network 
>> Gofer looks only in the package cache.
>> so that when you do not have internet but are sure that the files you need 
>> are in the package cache
>> you can use gofer to load them
>> 
>> I thought is was working but this is not that clear. I could not make it 
>> work in the library.
>> 
>> Stef
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
> 
> 
> 
> -- 
> Lukas Renggli
> www.lukas-renggli.ch
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

[Pharo-project] impossible to move window :)

[Stéphane Ducasse]

is it me or the latest beta introduced a nice behavior that make sure that you 
cannot move windows anymore?

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

Re: [Pharo-project] O2 in 1.1

[Mariano Martinez Peck]

On Tue, May 18, 2010 at 11:04 PM, Stéphane Ducasse <
stephane.duca...@inria.fr> wrote:

>
> On May 18, 2010, at 10:00 PM, Geert Claes wrote:
>
> >
> > Just loaded O2 in 1.1 and when I start it I get the warning "The method
> > Collection asSortedArray has been deprecated. Use asArray sort"
> >
> > How do I actually change my default system browser back?
>
> Look at ToolSet
>

But that sucks completly. Because the only way to change it is to subclass
and override.
If you want to know more why it sucks, read this thread:

http://forum.world.st/Questions-about-ToolSet-td1460544.html#a1460544

If someone is willing to fix it, welcome!!

you can also click on the window right icons and get the menu and select
> choose new default browser.
>
>
Yes, exactly. In the right icon of a system browser -> "Choose new default
browser"

By code SystemBrowser default: OBSystemBrowserAdaptor.

Change OBSystemBrowserAdaptor for what you want.

Cheers

Mariano


> Would be good then to fix the deprecated use.
>
> Stef
>
> > --
> > View this message in context:
> http://forum.world.st/O2-in-1-1-tp2221821p2221821.html
> > Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

[Philippe Marschall]

On 19.05.2010 07:58, Damien Pollet wrote:
> 2010/5/19 Levente Uzonyi :
>> Another "hard to quote" message, but I hope my answer will be clear.
>> The "problem" is that in Pharo the leadingChar for unicode characters is
>> still 255. This was changed in Squeak 4.1 to 0. So in Squeak 4.1:
>> (Unicode value: 8230) codePoint. "===> 8230"
>>
>> While in Pharo it's:
>> (Unicode value: 8230) codePoint. "===> 1069555750"
>> (Character value: 1069555750) charCode. "===> 8230"
>> (Character value: 1069555750) leadingChar. "===> 255"
>>
>> So using #charCode instead of #codePoint is the solution.
> 
> What about updating the leadingChar in Pharo to match Squeak? (I know
> it's not the correct solution to the present problem but it's these
> kinds of sneaky differences between platform that make life difficult)
> 
> What's the semantic difference between picking 0 or 255? Is one more
> correct than the other?
> 

Currently the semantics in Pharo are
0: Latin 1
255: Unicode

which is fun because the first 255 characters are interned and you
therefore can't change their leadingChar. So if you're using Unicode,
you're forced to mix leachingChars.

Cheers
Philippe


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

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

[Mariano Martinez Peck]

Hi Carla. I would like to help you, but I have no idea. I could reproduce
it.

Maybe Lukas, Igor, Eliot etc can help you. I have no idea.

Cheers

Mariano

2010/5/18 Carla F. Griggio 

> Hi everybody!
>
> Well, maybe you are already aware of this... maybe not. I tried to find an
> issue about this and unless I didn't think of the right keywords, it's not
> there.
>
> I was debugging a template method and sudenly I found myself spending ours
> trying to find out why I got different results when printing the result of a
> message sent to super and when steping into that message and printing the
> (same) result there.
>
> Imagine this simple situation (I attatch the complete code and some tests
> so you can reproduce this):
>
> AverageTotalization inherits from Totalization.
> WeightedAverageTotalization inherits from AverageTotalization.
>
> Totalization>>total
>  ^self summatory
>
> AverageTotalization>>total
> ^*(**super total)* / self denominator
>
> AverageTotalization>> denominator
> ^values size
>
> WeightedAverageTotalization>> denominator
> "Weights is a dictionary"
>  ^self weights values sum
>
>
> If I debug aWeightedAverateTotalization total  and try to print *super
> total* in the debugger ParagraphEditor, I'll get this result:
>
> (self summatory / self denominator)
>
> instead of just:
>
> self summatory
>
> This only happens when I print or inspect or other do-its in the debugger
> window. The method lookup works OK when just evaluating the code (the tests
> I made are green).
>
> I think that when you print or inspect (etc) *super total*, the evaluation
> context takes WeightedAverageTotalization class instead of
> AverageTotalization, so when total is sent to super under that context, the
> code is looked up on AverageTotalization instead of Totalization.
> Could that be possible? Am I thinking right?
>
> I spent a *while* chasing this bug, and I found a solution, but I don't
> know if it's OK or if it's the best. It's simple and it seems to work. I
> tested it in the last PharoCore1.1 unstable image.
>
> I attach some code to reproduce the error (you'll get a halt when you run
> the test, read the comments, the problem is clear when you run the weighted
> average test), and the code that fixes this.
>
> If you confirm that this was not a known issue, I'll register it on the
> issue tracker with both these attachments.
>
> If it was a known issue... well, I learned :) (I think XD)
>
> Cheers!
>
> Carla.
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] impossible to move window :)

[Mariano Martinez Peck]

I can. In 11367

On Wed, May 19, 2010 at 6:50 PM, Stéphane Ducasse  wrote:

> is it me or the latest beta introduced a nice behavior that make sure that
> you
> cannot move windows anymore?
>
> Stef
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Fwd: [Lsehub-staff] Why the hacking friday is good :)

[Stéphane Ducasse]

a really cool talk...
Stef

PS: the friday afternoon in our team we just code together or do stuff that 
should not get done automatically :)


Begin forwarded message:

> From: Damien Pollet 
> Date: May 19, 2010 7:04:43 PM GMT+02:00
> To: “lsehub“ 
> Subject: [Lsehub-staff] Why the hacking friday is good :)
> Reply-To: notre liste 
> 
> http://everywhereelse.wordpress.com/2010/05/14/watch-this-when-youre-done-watch-it/
> 
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet
> 
> 
> 
> 
> ___
> Lsehub-staff mailing list
> lsehub-st...@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/lsehub-staff


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

Re: [Pharo-project] O2 in 1.1

[Stéphane Ducasse]

On May 19, 2010, at 6:55 PM, Mariano Martinez Peck wrote:

> 
> 
> On Tue, May 18, 2010 at 11:04 PM, Stéphane Ducasse 
>  wrote:
> 
> On May 18, 2010, at 10:00 PM, Geert Claes wrote:
> 
> >
> > Just loaded O2 in 1.1 and when I start it I get the warning "The method
> > Collection asSortedArray has been deprecated. Use asArray sort"
> >
> > How do I actually change my default system browser back?
> 
> Look at ToolSet
> 
> But that sucks completly. Because the only way to change it is to subclass 
> and override.  
> If you want to know more why it sucks, read this thread: 

ok I was thinking that this  was

> 
> SystemBrowser default: OBSystemBrowserAdaptor.

Stef

> 
> http://forum.world.st/Questions-about-ToolSet-td1460544.html#a1460544
> 
> If someone is willing to fix it, welcome!!
> 
> you can also click on the window right icons and get the menu and select 
> choose new default browser.
> 
> 
> Yes, exactly. In the right icon of a system browser -> "Choose new default 
> browser"
> 
> By code SystemBrowser default: OBSystemBrowserAdaptor.
> 
> Change OBSystemBrowserAdaptor for what you want. 
> 
> Cheers
> 
> Mariano
>  
> Would be good then to fix the deprecated use.
> 
> Stef
> 
> > --
> > View this message in context: 
> > http://forum.world.st/O2-in-1-1-tp2221821p2221821.html
> > Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

[Stéphane Ducasse]

>> 
>> 
> 
> Currently the semantics in Pharo are
> 0: Latin 1
> 255: Unicode
> 
> which is fun because the first 255 characters are interned and you
> therefore can't change their leadingChar. So if you're using Unicode,
> you're forced to mix leachingChars.

so what do you suggest to have unicode as zero?

Stef

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

Re: [Pharo-project] impossible to move window :)

[Stéphane Ducasse]

ok :)
I do not know what I did :)

On May 19, 2010, at 7:32 PM, Mariano Martinez Peck wrote:

> I can. In 11367
> 
> On Wed, May 19, 2010 at 6:50 PM, Stéphane Ducasse  
> wrote:
> is it me or the latest beta introduced a nice behavior that make sure that you
> cannot move windows anymore?
> 
> Stef
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] NetNameResolver in Pharo 1.1

[Miguel Enrique Cobá Martinez]

El sáb, 08-05-2010 a las 17:54 +0200, Lukas Renggli escribió:
> In Pharo 1.0 there were some problems with the network stack (namely
> the NetNameResolver) and the IP6 code was reverted shortly before
> release, see the following issue for details:
> 
>  http://code.google.com/p/pharo/issues/detail?id=1884
> 
> Today I was checking with Stef for the presence of these problems in
> Pharo 1.1, but we could not reproduce neither on Mac, Windows nor
> Linux. Does anybody have problems with the following expressions in
> Pharo 1.1?
> 
> NetNameResolver localHostAddress.
> NetNameResolver addressForName: 'www.yahoo.com'.
> 
> Or are we doing the wrong thing to reproduce?
> 
> Lukas

Sorry for arriving late to the party :).
I tried the doits from the problem on Pharo 1.0 in a Pharo Core 11364
image. I got some error, although not as severe as in Pharo 1.0.

I added an issue for this

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

Now, I'm going to test with Magma to see if some other error shows

Cheers
-- 
Miguel Cobá
http://miguel.leugim.com.mx


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

Re: [Pharo-project] UUID on ubuntu 10.04

[David T. Lewis]

That is exactly how it works:

  UUID>>primMakeUUID

UUIDGenerator default generateBytes: self forVersion: 4.


I added this to the Mantis issue:

  To summarize: The bug exists in some versions of libuuid on some Linux
  distributions. The workaround is to compile the plugin internal. The
  latest versions of Unix VM have the plugin compiled internally, although
  some users may still experience problems if they have a leftover external
  plugin from a prior installation.
  
  If you experience this problem, then get the latest Unix VM and delete
  any existing copies of the external plugin.
   
  Resolved in latest Unix VMs. The UUID plugin must be compiled internally
  to avoid a bug in some versions of libuuid. 

Hopefully this is an accurate summary.

Dave

On Wed, May 19, 2010 at 06:15:32PM +0200, St?phane Ducasse wrote:
> I'm not sure that it is resolved. It would be good to make sure that the 
> system does not crash
> even without reporting a log. May be having a stupid UUID generator as a 
> fallback would be good.
> 
> Stef
> 
> > Thanks, I marked the issue as resolved and summarized the status here:
> > 
> >  http://bugs.squeak.org/view.php?id=7358
> > 
> > Dave
> > 
> > On Wed, May 19, 2010 at 09:42:28AM +0200, St?phane Ducasse wrote:
> >> Apparently the student reinstalled her ubuntu from scratch (no incremental 
> >> installation) and the vm did not crash
> >> anymore.
> >> 
> >> Stef
> >> 
> >> On May 17, 2010, at 9:16 PM, St?phane Ducasse wrote:
> >> 
> >>> I asked the student to try.
> >>> 
> >>> Stef
> >>> 
> >>> On May 17, 2010, at 9:06 PM, laurent laffont wrote:
> >>> 
>  On ArchLinux I have the problem when UUID is built external. Official 
>  4.0.3.2202 Unix VM binaries on http://squeakvm.org/unix/ works well for 
>  me (UUID is internal).
>  
>  Can you try with this one click image I made once (uses 4.0.3.2202 
>  binaries) http://lolgzs.free.fr/pharo/Pharo-1.0-OneClick.zip
>  
>  Laurent Laffont
>  
>  http://pharocasts.blogspot.com/
>  http://magaloma.blogspot.com/
>  
>  
>  On Mon, May 17, 2010 at 8:24 PM, St?phane Ducasse 
>   wrote:
>  I can confirm that this is exactly the same trace than the one reported 
>  by laurent (no debug file).
>  
>  Stef
>  On May 17, 2010, at 7:51 PM, David T. Lewis wrote:
>  
> > On Mon, May 17, 2010 at 07:38:59PM +0200, St?phane Ducasse wrote:
> >> Hi guys
> >> 
> >> I took seaside the latest one click image and when I have to save a MC 
> >> package
> >> I get a core dump with UUID new:...
> >> I checke the so.UUIDplugin is there and I do not understand.
> >> Can somebody with a Ubuntu give a try to save something using MC and 
> >> the latest seaside one click.
> > 
> > Hi Stef,
> > 
> > This issue is being tracked here: 
> > http://bugs.squeak.org/view.php?id=7358
> > 
> > It is not clear to me if the issue is resolved in the Ian's latest VM
> > build, so if you or anyone else can confirm the UUID crash happening
> > with this VM, that would be helpful to clarify.
> > 
> > Dave
> > 
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

[Philippe Marschall]

On 19.05.2010 19:35, Stéphane Ducasse wrote:
>>>
>>>
>>
>> Currently the semantics in Pharo are
>> 0: Latin 1
>> 255: Unicode
>>
>> which is fun because the first 255 characters are interned and you
>> therefore can't change their leadingChar. So if you're using Unicode,
>> you're forced to mix leachingChars.
> 
> so what do you suggest to have unicode as zero?

Yes, the decision of Squeak 4.1 to make Unicode leadingChar 0 is an
improvement.

Cheers
Philippe


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

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

[Carla F. Griggio]

Just reproducing it would be helpful :O a friend of mine already
tested the code I attatched and saw the same problem.

If you recall having a class with a method sending a message to super,
and a sublclass inheriting that method, you can try to reproduce it
there too debugging that message on an instance of the subclass.

It's not easy to explain with words, that's why I made a little
package of code to illustrate the situation.

The thing is that when printing the evaluation of a selected bunch of
code inside a debugger window (paragraphEditor?), if the code you're
evaluating is a message to super, and the class of the object you're
debugging is inheriting the method you're debugging, the printed
result will be wrong. In other words, the method lookup fails.

This doesn't happen with normal excution of code (thank God!).

I think this is an important bug, seeing those wrong results when
debugging can be very confusing. I spent hours feeling stupid last
Monday while debugging because I trusted those wrong results and
couldn't see where I was doing something wrong :P

Cheers!
Carla

On Wednesday, May 19, 2010, Mariano Martinez Peck  wrote:
> Hi Carla. I would like to help you, but I have no idea. I could reproduce it.
>
> Maybe Lukas, Igor, Eliot etc can help you. I have no idea.
>
> Cheers
>
> Mariano
>
> 2010/5/18 Carla F. Griggio 
> Hi everybody!
> Well, maybe you are already aware of this... maybe not. I tried to find an 
> issue about this and unless I didn't think of the right keywords, it's not 
> there.
>
>
>
> I was debugging a template method and sudenly I found myself spending ours 
> trying to find out why I got different results when printing the result of a 
> message sent to super and when steping into that message and printing the 
> (same) result there.
>
>
>
> Imagine this simple situation (I attatch the complete code and some tests so 
> you can reproduce this):
> AverageTotalization inherits from Totalization.WeightedAverageTotalization 
> inherits from AverageTotalization.
>
>
>
> Totalization>>total
>
>   ^self summatory
>
>
>
>
>
> AverageTotalization>>total
>
>         ^(super total) / self denominator
>
>
>
>
>
> AverageTotalization>> denominator
>
>         ^values size
>
>
>
>
> WeightedAverageTotalization>> denominator
>
> "Weights is a dictionary"
>
>   ^self weights values sum
>
>
>
>
> If I debug aWeightedAverateTotalization total  and try to print super total 
> in the debugger ParagraphEditor, I'll get this result:
>
>
>
> (self summatory / self denominator)
>
>
> instead of just:
> self summatory
> This only happens when I print or inspect or other do-its in the debugger 
> window. The method lookup works OK when just 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>

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

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

[Stéphane Ducasse]

Yes this is an important bug
do you have the cs of your little example?

Stef

On May 19, 2010, at 9:17 PM, Carla F. Griggio wrote:

> Just reproducing it would be helpful :O a friend of mine already
> tested the code I attatched and saw the same problem.
> 
> If you recall having a class with a method sending a message to super,
> and a sublclass inheriting that method, you can try to reproduce it
> there too debugging that message on an instance of the subclass.
> 
> It's not easy to explain with words, that's why I made a little
> package of code to illustrate the situation.
> 
> The thing is that when printing the evaluation of a selected bunch of
> code inside a debugger window (paragraphEditor?), if the code you're
> evaluating is a message to super, and the class of the object you're
> debugging is inheriting the method you're debugging, the printed
> result will be wrong. In other words, the method lookup fails.
> 
> This doesn't happen with normal excution of code (thank God!).
> 
> I think this is an important bug, seeing those wrong results when
> debugging can be very confusing. I spent hours feeling stupid last
> Monday while debugging because I trusted those wrong results and
> couldn't see where I was doing something wrong :P
> 
> Cheers!
> Carla
> 
> On Wednesday, May 19, 2010, Mariano Martinez Peck  
> wrote:
>> Hi Carla. I would like to help you, but I have no idea. I could reproduce it.
>> 
>> Maybe Lukas, Igor, Eliot etc can help you. I have no idea.
>> 
>> Cheers
>> 
>> Mariano
>> 
>> 2010/5/18 Carla F. Griggio 
>> Hi everybody!
>> Well, maybe you are already aware of this... maybe not. I tried to find an 
>> issue about this and unless I didn't think of the right keywords, it's not 
>> there.
>> 
>> 
>> 
>> I was debugging a template method and sudenly I found myself spending ours 
>> trying to find out why I got different results when printing the result of a 
>> message sent to super and when steping into that message and printing the 
>> (same) result there.
>> 
>> 
>> 
>> Imagine this simple situation (I attatch the complete code and some tests so 
>> you can reproduce this):
>> AverageTotalization inherits from Totalization.WeightedAverageTotalization 
>> inherits from AverageTotalization.
>> 
>> 
>> 
>> Totalization>>total
>> 
>>  ^self summatory
>> 
>> 
>> 
>> 
>> 
>> AverageTotalization>>total
>> 
>> ^(super total) / self denominator
>> 
>> 
>> 
>> 
>> 
>> AverageTotalization>> denominator
>> 
>> ^values size
>> 
>> 
>> 
>> 
>> WeightedAverageTotalization>> denominator
>> 
>> "Weights is a dictionary"
>> 
>>  ^self weights values sum
>> 
>> 
>> 
>> 
>> If I debug aWeightedAverateTotalization total  and try to print super total 
>> in the debugger ParagraphEditor, I'll get this result:
>> 
>> 
>> 
>> (self summatory / self denominator)
>> 
>> 
>> instead of just:
>> self summatory
>> This only happens when I print or inspect or other do-its in the debugger 
>> window. The method lookup works OK when just 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] NetNameResolver in Pharo 1.1

[Stéphane Ducasse]

MIguel

which version of 1.1 because we rollback the changes so normally we should have 
now the same as in 1.0

Stef

On May 19, 2010, at 8:48 PM, Miguel Enrique Cobá Martinez wrote:

> El sáb, 08-05-2010 a las 17:54 +0200, Lukas Renggli escribió:
>> In Pharo 1.0 there were some problems with the network stack (namely
>> the NetNameResolver) and the IP6 code was reverted shortly before
>> release, see the following issue for details:
>> 
>> http://code.google.com/p/pharo/issues/detail?id=1884
>> 
>> Today I was checking with Stef for the presence of these problems in
>> Pharo 1.1, but we could not reproduce neither on Mac, Windows nor
>> Linux. Does anybody have problems with the following expressions in
>> Pharo 1.1?
>> 
>>NetNameResolver localHostAddress.
>>NetNameResolver addressForName: 'www.yahoo.com'.
>> 
>> Or are we doing the wrong thing to reproduce?
>> 
>> Lukas
> 
> Sorry for arriving late to the party :).
> I tried the doits from the problem on Pharo 1.0 in a Pharo Core 11364
> image. I got some error, although not as severe as in Pharo 1.0.
> 
> I added an issue for this
> 
> http://code.google.com/p/pharo/issues/detail?id=2444
> 
> Now, I'm going to test with Magma to see if some other error shows
> 
> Cheers
> -- 
> Miguel Cobá
> http://miguel.leugim.com.mx
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] UUID on ubuntu 10.04

[Stéphane Ducasse]

thanks

probably the seaside one click does not have the latest vm

Stef

On May 19, 2010, at 9:02 PM, David T. Lewis wrote:

> That is exactly how it works:
> 
>  UUID>>primMakeUUID
>   
>   UUIDGenerator default generateBytes: self forVersion: 4.
> 
> 
> I added this to the Mantis issue:
> 
>  To summarize: The bug exists in some versions of libuuid on some Linux
>  distributions. The workaround is to compile the plugin internal. The
>  latest versions of Unix VM have the plugin compiled internally, although
>  some users may still experience problems if they have a leftover external
>  plugin from a prior installation.
> 
>  If you experience this problem, then get the latest Unix VM and delete
>  any existing copies of the external plugin.
> 
>  Resolved in latest Unix VMs. The UUID plugin must be compiled internally
>  to avoid a bug in some versions of libuuid. 
> 
> Hopefully this is an accurate summary.
> 
> Dave
> 
> On Wed, May 19, 2010 at 06:15:32PM +0200, St?phane Ducasse wrote:
>> I'm not sure that it is resolved. It would be good to make sure that the 
>> system does not crash
>> even without reporting a log. May be having a stupid UUID generator as a 
>> fallback would be good.
>> 
>> Stef
>> 
>>> Thanks, I marked the issue as resolved and summarized the status here:
>>> 
>>> http://bugs.squeak.org/view.php?id=7358
>>> 
>>> Dave
>>> 
>>> On Wed, May 19, 2010 at 09:42:28AM +0200, St?phane Ducasse wrote:
 Apparently the student reinstalled her ubuntu from scratch (no incremental 
 installation) and the vm did not crash
 anymore.
 
 Stef
 
 On May 17, 2010, at 9:16 PM, St?phane Ducasse wrote:
 
> I asked the student to try.
> 
> Stef
> 
> On May 17, 2010, at 9:06 PM, laurent laffont wrote:
> 
>> On ArchLinux I have the problem when UUID is built external. Official 
>> 4.0.3.2202 Unix VM binaries on http://squeakvm.org/unix/ works well for 
>> me (UUID is internal).
>> 
>> Can you try with this one click image I made once (uses 4.0.3.2202 
>> binaries) http://lolgzs.free.fr/pharo/Pharo-1.0-OneClick.zip
>> 
>> Laurent Laffont
>> 
>> http://pharocasts.blogspot.com/
>> http://magaloma.blogspot.com/
>> 
>> 
>> On Mon, May 17, 2010 at 8:24 PM, St?phane Ducasse 
>>  wrote:
>> I can confirm that this is exactly the same trace than the one reported 
>> by laurent (no debug file).
>> 
>> Stef
>> On May 17, 2010, at 7:51 PM, David T. Lewis wrote:
>> 
>>> On Mon, May 17, 2010 at 07:38:59PM +0200, St?phane Ducasse wrote:
 Hi guys
 
 I took seaside the latest one click image and when I have to save a MC 
 package
 I get a core dump with UUID new:...
 I checke the so.UUIDplugin is there and I do not understand.
 Can somebody with a Ubuntu give a try to save something using MC and 
 the latest seaside one click.
>>> 
>>> Hi Stef,
>>> 
>>> This issue is being tracked here: 
>>> http://bugs.squeak.org/view.php?id=7358
>>> 
>>> It is not clear to me if the issue is resolved in the Ian's latest VM
>>> build, so if you or anyone else can confirm the UUID crash happening
>>> with this VM, that would be helpful to clarify.
>>> 
>>> Dave
>>> 
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

[Stéphane Ducasse]

ok 
may be you should have said that before :)
Now how this can be done?
changing the EncodedCharSets?

> initialize
> 
>   self allSubclassesDo: [:each | each initialize].
> 
>   EncodedCharSets := Array new: 256.
> 
>   EncodedCharSets at: 0+1 put: Unicode "Latin1Environment".
>   EncodedCharSets at: 1+1 put: JISX0208.
>   EncodedCharSets at: 2+1 put: GB2312.
>   EncodedCharSets at: 3+1 put: KSX1001.
>   EncodedCharSets at: 4+1 put: JISX0208.

Then I do not understand because 
EncodedCharSets at: 0+1 put: Unicode 
seems to me that this is already the case but may be I'm not looking at the 
right place. 

What are the implications?
What will we break.

Stef

On May 19, 2010, at 9:06 PM, Philippe Marschall wrote:

> On 19.05.2010 19:35, Stéphane Ducasse wrote:
 
 
>>> 
>>> Currently the semantics in Pharo are
>>> 0: Latin 1
>>> 255: Unicode
>>> 
>>> which is fun because the first 255 characters are interned and you
>>> therefore can't change their leadingChar. So if you're using Unicode,
>>> you're forced to mix leachingChars.
>> 
>> so what do you suggest to have unicode as zero?
> 
> Yes, the decision of Squeak 4.1 to make Unicode leadingChar 0 is an
> improvement.
> 
> Cheers
> Philippe
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

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

[Carla F. Griggio]

Not the cs, I have an st. It's in the first email of this thread. I also
attached a cs with a possible fix.



On Wed, May 19, 2010 at 4:35 PM, Stéphane Ducasse  wrote:

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

Re: [Pharo-project] impossible to move window :)

[Stéphane Ducasse]

apparently when I take the latest beta I cannot move windows.
So I will probably check and if necessary rollback

stef
On May 19, 2010, at 7:32 PM, Mariano Martinez Peck wrote:

> I can. In 11367
> 
> On Wed, May 19, 2010 at 6:50 PM, Stéphane Ducasse  
> wrote:
> is it me or the latest beta introduced a nice behavior that make sure that you
> cannot move windows anymore?
> 
> Stef
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Re: [Pharo-project] impossible to move window :)

[Stéphane Ducasse]

If I replay the changes the windows can move.
So I uploaded a new zipped file. I have no clue how this happened.

Stef

> apparently when I take the latest beta I cannot move windows.
> So I will probably check and if necessary rollback
> 
> stef
> On May 19, 2010, at 7:32 PM, Mariano Martinez Peck wrote:
> 
>> I can. In 11367
>> 
>> On Wed, May 19, 2010 at 6:50 PM, Stéphane Ducasse 
>>  wrote:
>> is it me or the latest beta introduced a nice behavior that make sure that 
>> you
>> cannot move windows anymore?
>> 
>> Stef
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

[Pharo-project] nice story for next generation debugger

[stephane ducasse]

Hi 

I have a quite fun bug.
I load some code and suddenly the packageOrganizer is wiped out and contains 
worng information.
I checked checked checked no success so far and I would love to have something 
to say notify me when any change 
happen to the dictionary of packageOrganizer.

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

Re: [Pharo-project] [Gofer] loading only from package cache but with the same expression

[Lukas Renggli]

The default are, as the documentation says:

- report errors
- use package cache

Everything else you need to configure separately.

Lukas

On 19 May 2010 18:23, Stéphane Ducasse  wrote:
> Yes I know all that now should I disable errors to get it loading only from 
> the local cache?
>
>> If you disable repository errors inaccessible repositories are ignored
>> and don't throw an error (you have to tell that though):
> but does it still load from the local-cache?
>
>
> Stef
>
>
> On May 19, 2010, at 6:14 PM, Lukas Renggli wrote:
>
>> The default Gofer only uses the package cache:
>>
>>   Gofer new repositories
>>    --> an Array(a
>> MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache))
>>
>> If you specify other repositories they are tried in that order as well:
>>
>>   Gofer new renggli: 'ob'; squeaksource: 'rb'; repositories
>>   -->  an Array(a
>> MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache)
>> a MCHttpRepository(http://source.lukas-renggli.ch/ob) a
>> MCHttpRepository(http://www.squeaksource.com/rb))
>>
>> If you disable the package cache, the package cache is ignored:
>>
>>   Gofer new disablePackageCache; renggli: 'ob'; squeaksource: 'rb';
>> repositories
>>   --> an Array(a MCHttpRepository(http://source.lukas-renggli.ch/ob)
>> a MCHttpRepository(http://www.squeaksource.com/rb))
>>
>> If you disable repository errors inaccessible repositories are ignored
>> and don't throw an error (you have to tell that though):
>>
>>  Gofer new disableRepositoryErrors; renggli: 'ob'; squeaksource:
>> 'rb'; repositories
>>  -->  an Array(a
>> MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache)
>> a MCHttpRepository(http://source.lukas-renggli.ch/ob) a
>> MCHttpRepository(http://www.squeaksource.com/rb))
>>
>> Lukas
>>
>> On 19 May 2010 16:59, Stéphane Ducasse  wrote:
>>> Hi lukas
>>>
>>> is it possible that for an expression that would work if we get network 
>>> Gofer looks only in the package cache.
>>> so that when you do not have internet but are sure that the files you need 
>>> are in the package cache
>>> you can use gofer to load them
>>>
>>> I thought is was working but this is not that clear. I could not make it 
>>> work in the library.
>>>
>>> Stef
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Lukas Renggli
www.lukas-renggli.ch

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

Re: [Pharo-project] [Gofer] loading only from package cache but with the same expression

[Lukas Renggli]

Yes, these two things are independent of each other.

Lukas

On 19 May 2010 23:13, Lukas Renggli  wrote:
> The default are, as the documentation says:
>
> - report errors
> - use package cache
>
> Everything else you need to configure separately.
>
> Lukas
>
> On 19 May 2010 18:23, Stéphane Ducasse  wrote:
>> Yes I know all that now should I disable errors to get it loading only from 
>> the local cache?
>>
>>> If you disable repository errors inaccessible repositories are ignored
>>> and don't throw an error (you have to tell that though):
>> but does it still load from the local-cache?
>>
>>
>> Stef
>>
>>
>> On May 19, 2010, at 6:14 PM, Lukas Renggli wrote:
>>
>>> The default Gofer only uses the package cache:
>>>
>>>   Gofer new repositories
>>>    --> an Array(a
>>> MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache))
>>>
>>> If you specify other repositories they are tried in that order as well:
>>>
>>>   Gofer new renggli: 'ob'; squeaksource: 'rb'; repositories
>>>   -->  an Array(a
>>> MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache)
>>> a MCHttpRepository(http://source.lukas-renggli.ch/ob) a
>>> MCHttpRepository(http://www.squeaksource.com/rb))
>>>
>>> If you disable the package cache, the package cache is ignored:
>>>
>>>   Gofer new disablePackageCache; renggli: 'ob'; squeaksource: 'rb';
>>> repositories
>>>   --> an Array(a MCHttpRepository(http://source.lukas-renggli.ch/ob)
>>> a MCHttpRepository(http://www.squeaksource.com/rb))
>>>
>>> If you disable repository errors inaccessible repositories are ignored
>>> and don't throw an error (you have to tell that though):
>>>
>>>  Gofer new disableRepositoryErrors; renggli: 'ob'; squeaksource:
>>> 'rb'; repositories
>>>  -->  an Array(a
>>> MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache)
>>> a MCHttpRepository(http://source.lukas-renggli.ch/ob) a
>>> MCHttpRepository(http://www.squeaksource.com/rb))
>>>
>>> Lukas
>>>
>>> On 19 May 2010 16:59, Stéphane Ducasse  wrote:
 Hi lukas

 is it possible that for an expression that would work if we get network 
 Gofer looks only in the package cache.
 so that when you do not have internet but are sure that the files you need 
 are in the package cache
 you can use gofer to load them

 I thought is was working but this is not that clear. I could not make it 
 work in the library.

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

>>>
>>>
>>>
>>> --
>>> Lukas Renggli
>>> www.lukas-renggli.ch
>>>
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>



-- 
Lukas Renggli
www.lukas-renggli.ch

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

Re: [Pharo-project] Fwd: [Lsehub-staff] Why the hacking friday is good :)

[Igor Stasenko]

On 19 May 2010 20:34, Stéphane Ducasse  wrote:
> a really cool talk...
> Stef
>
> PS: the friday afternoon in our team we just code together or do stuff that 
> should not get done automatically :)
>
>
That's amazing video!

> Begin forwarded message:
>
>> From: Damien Pollet 
>> Date: May 19, 2010 7:04:43 PM GMT+02:00
>> To: “lsehub“ 
>> Subject: [Lsehub-staff] Why the hacking friday is good :)
>> Reply-To: notre liste 
>>
>> http://everywhereelse.wordpress.com/2010/05/14/watch-this-when-youre-done-watch-it/
>>
>> --
>> Damien Pollet
>> type less, do more [ | ] http://people.untyped.org/damien.pollet
>>
>>
>>
>>
>> ___
>> Lsehub-staff mailing list
>> lsehub-st...@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/lsehub-staff
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.

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

Re: [Pharo-project] nice story for next generation debugger

[Igor Stasenko]

On 19 May 2010 23:52, stephane ducasse  wrote:
> Hi
>
> I have a quite fun bug.
> I load some code and suddenly the packageOrganizer is wiped out and contains 
> worng information.
> I checked checked checked no success so far and I would love to have 
> something to say notify me when any change
> happen to the dictionary of packageOrganizer.
>
I has similar thoughts about tracking the object's changes.
It could possibly done by replacing a reference to an object by proxy,
which intercepts all messages sent to it
and then, sending the same message to wrapped object,
and after that, compares a object's contents with its hollow copy
(which made beforehead).
Then , if change is detected - notify a listener.

So, this is quite easy to implement.. but integrating it into a
debugger is a lil bit another story :)

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



-- 
Best regards,
Igor Stasenko AKA sig.

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

Re: [Pharo-project] UUID on ubuntu 10.04

[Mariano Martinez Peck]

Maybe they can just take the pharo 1.0 one click, just evaluate the
metacello confing and use it as seaside one click

Ahh and change the logo, open welcome workspaces, etc.

cheers

mariano

On Wed, May 19, 2010 at 9:36 PM, Stéphane Ducasse  wrote:

> thanks
>
> probably the seaside one click does not have the latest vm
>
> Stef
>
> On May 19, 2010, at 9:02 PM, David T. Lewis wrote:
>
> > That is exactly how it works:
> >
> >  UUID>>primMakeUUID
> >   
> >   UUIDGenerator default generateBytes: self forVersion: 4.
> >
> >
> > I added this to the Mantis issue:
> >
> >  To summarize: The bug exists in some versions of libuuid on some Linux
> >  distributions. The workaround is to compile the plugin internal. The
> >  latest versions of Unix VM have the plugin compiled internally, although
> >  some users may still experience problems if they have a leftover
> external
> >  plugin from a prior installation.
> >
> >  If you experience this problem, then get the latest Unix VM and delete
> >  any existing copies of the external plugin.
> >
> >  Resolved in latest Unix VMs. The UUID plugin must be compiled internally
> >  to avoid a bug in some versions of libuuid.
> >
> > Hopefully this is an accurate summary.
> >
> > Dave
> >
> > On Wed, May 19, 2010 at 06:15:32PM +0200, St?phane Ducasse wrote:
> >> I'm not sure that it is resolved. It would be good to make sure that the
> system does not crash
> >> even without reporting a log. May be having a stupid UUID generator as a
> fallback would be good.
> >>
> >> Stef
> >>
> >>> Thanks, I marked the issue as resolved and summarized the status here:
> >>>
> >>> http://bugs.squeak.org/view.php?id=7358
> >>>
> >>> Dave
> >>>
> >>> On Wed, May 19, 2010 at 09:42:28AM +0200, St?phane Ducasse wrote:
>  Apparently the student reinstalled her ubuntu from scratch (no
> incremental installation) and the vm did not crash
>  anymore.
> 
>  Stef
> 
>  On May 17, 2010, at 9:16 PM, St?phane Ducasse wrote:
> 
> > I asked the student to try.
> >
> > Stef
> >
> > On May 17, 2010, at 9:06 PM, laurent laffont wrote:
> >
> >> On ArchLinux I have the problem when UUID is built external.
> Official 4.0.3.2202 Unix VM binaries on http://squeakvm.org/unix/ works
> well for me (UUID is internal).
> >>
> >> Can you try with this one click image I made once (uses 4.0.3.2202
> binaries) http://lolgzs.free.fr/pharo/Pharo-1.0-OneClick.zip
> >>
> >> Laurent Laffont
> >>
> >> http://pharocasts.blogspot.com/
> >> http://magaloma.blogspot.com/
> >>
> >>
> >> On Mon, May 17, 2010 at 8:24 PM, St?phane Ducasse <
> stephane.duca...@inria.fr> wrote:
> >> I can confirm that this is exactly the same trace than the one
> reported by laurent (no debug file).
> >>
> >> Stef
> >> On May 17, 2010, at 7:51 PM, David T. Lewis wrote:
> >>
> >>> On Mon, May 17, 2010 at 07:38:59PM +0200, St?phane Ducasse wrote:
>  Hi guys
> 
>  I took seaside the latest one click image and when I have to save
> a MC package
>  I get a core dump with UUID new:...
>  I checke the so.UUIDplugin is there and I do not understand.
>  Can somebody with a Ubuntu give a try to save something using MC
> and the latest seaside one click.
> >>>
> >>> Hi Stef,
> >>>
> >>> This issue is being tracked here:
> http://bugs.squeak.org/view.php?id=7358
> >>>
> >>> It is not clear to me if the issue is resolved in the Ian's latest
> VM
> >>> build, so if you or anyone else can confirm the UUID crash
> happening
> >>> with this VM, that would be helpful to clarify.
> >>>
> >>> Dave
> >>>
> >>> ___
> >>> Pharo-project mailing list
> >>> Pharo-project@lists.gforge.inria.fr
> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>
> >>
> >> ___
> >> Pharo-project mailing list
> >> Pharo-project@lists.gforge.inria.fr
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] O2 in 1.1

[Mariano Martinez Peck]

On Tue, May 18, 2010 at 10:00 PM, Geert Claes wrote:

>
> Just loaded O2 in 1.1 and when I start it I get the warning "The method
> Collection asSortedArray has been deprecated. Use asArray sort"
>

You can commit the fixes to O2 too...just do that:  change asSortedArray for
asArray sort



> How do I actually change my default system browser back?
> --
> View this message in context:
> http://forum.world.st/O2-in-1-1-tp2221821p2221821.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] nice story for next generation debugger

[Lukas Renggli]

On 19 May 2010 23:34, Igor Stasenko  wrote:
> On 19 May 2010 23:52, stephane ducasse  wrote:
>> Hi
>>
>> I have a quite fun bug.
>> I load some code and suddenly the packageOrganizer is wiped out and contains 
>> worng information.
>> I checked checked checked no success so far and I would love to have 
>> something to say notify me when any change
>> happen to the dictionary of packageOrganizer.
>>
> I has similar thoughts about tracking the object's changes.
> It could possibly done by replacing a reference to an object by proxy,
> which intercepts all messages sent to it
> and then, sending the same message to wrapped object,
> and after that, compares a object's contents with its hollow copy
> (which made beforehead).
> Then , if change is detected - notify a listener.
>
> So, this is quite easy to implement.. but integrating it into a
> debugger is a lil bit another story :)

The proxy gives problems with identity, but indeed change tracking is
solvable as in .

I guess what Stef wants is more something like
.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

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

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

[Henrik Sperre Johansen]

 On 19.05.2010 21:44, Stéphane Ducasse wrote:

ok
may be you should have said that before :)
Now how this can be done?
changing the EncodedCharSets?


initialize

self allSubclassesDo: [:each | each initialize].

EncodedCharSets := Array new: 256.

EncodedCharSets at: 0+1 put: Unicode "Latin1Environment".
EncodedCharSets at: 1+1 put: JISX0208.
EncodedCharSets at: 2+1 put: GB2312.
EncodedCharSets at: 3+1 put: KSX1001.
EncodedCharSets at: 4+1 put: JISX0208.

Then I do not understand because
EncodedCharSets at: 0+1 put: Unicode
seems to me that this is already the case but may be I'm not looking at the 
right place.

What are the implications?
What will we break.

Stef

As you've noted, we've already done it.
It's broken then display of WideStrings with StrikeFonts, since that 
relied on Wide Characters being stops, which did happen when leadingChar 
was 255, but not when it's 0.
That is manifested in that the rest of the string after a WideChar is 
rendered as ?'s.
There's also an error causing the width of the chars to be wrong, and 
the first char on the line to be displayed on the previous line instead, 
but iirc that's not directly related to the stops issue.


Cheers,
Henry

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

[Pharo-project] Algernon for 1.1.

[Torsten Bergmann]

Hi there,

ConfigurationOfAlgernon will crash with 1.1.
Anyone knows if Algernon is still maintained?

The method #multipleFocusHolderCs returns 
a changeset to change HandMorph ... not nice

This will cause the crash (underscores?) and will also
patch the Morphic package which has open changes
afterwards. 

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

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

Re: [Pharo-project] Fwd: [Lsehub-staff] Why the hacking friday is good :)

[Eliot Miranda]

closely related:
http://www.ted.com/talks/lang/eng/tom_wujec_build_a_tower.html

On Wed, May 19, 2010 at 10:34 AM, Stéphane Ducasse <
stephane.duca...@inria.fr> wrote:

> a really cool talk...
> Stef
>
> PS: the friday afternoon in our team we just code together or do stuff that
> should not get done automatically :)
>
>
> Begin forwarded message:
>
> > From: Damien Pollet 
> > Date: May 19, 2010 7:04:43 PM GMT+02:00
> > To: “lsehub“ 
> > Subject: [Lsehub-staff] Why the hacking friday is good :)
> > Reply-To: notre liste 
> >
> >
> http://everywhereelse.wordpress.com/2010/05/14/watch-this-when-youre-done-watch-it/
> >
> > --
> > Damien Pollet
> > type less, do more [ | ] http://people.untyped.org/damien.pollet
> >
> >
> >
> >
> > ___
> > Lsehub-staff mailing list
> > lsehub-st...@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/lsehub-staff
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Pharo sprint this Saturday

[Alexandre Bergel]

Yep. If I am not wrong, then
Time: 9:30 - 21:30 (GMT + 4). For European who wish to follow it via IRC or 
Twitter, it will begin at 14:30 (GMT +1) in Europe.

Alexandre


On 19 May 2010, at 03:41, Serge Stinckwich wrote:

> On Wed, May 19, 2010 at 6:15 AM, Alexandre Bergel
>  wrote:
>> Hi All,
>> 
>> I am now with Mariano, working on the details for this Saturday.
>> More info on http://code.google.com/p/pharo/wiki/PharoSprints
>> Please, get in touch with Mariano first if you want to attend.
>> 
>> As already said, the objective of the sprint will be to help produce Pharo 
>> 1.1
>> 
>> We will try to be present on IRC and/or iChat for remote pair programming :-)
> 
> Hi Alex,
> 
> maybe you could add the GMT time of the sprint if some people want to join.
> 
> Regards,
> -- 
> Serge Stinckwich
> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
> Every DSL ends up being Smalltalk
> http://doesnotunderstand.org/
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






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

[Pharo-project] MetaSource demo app working again

[Torsten Bergmann]

MetaSource (a demo seaside app) was moved to Pharo 1.1. 
The loading via ConfigurationOfMetaSource/ConfigurationOfPharo 
is now working again. 

Image Building is very easy (but slow) - just drop
the attached file onto an up to date (#11367) Pharo 1.1. core
image and select "file in" or evaluate the containted code
in a workspace.

When finished select "Tools" -> "MetaSource" from the world
menu and then "Start" and "Browse" to open the app in the web browser.

Tested on Windows. Would be nice if someone has the time to
test a Linux or Mac build. Thanks.

Bye
T.

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


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

Re: [Pharo-project] about menu not showing up

[Alain Plantec]

Le 19/05/2010 14:26, Stéphane Ducasse a écrit :

Hi alain

in scriptLoader I added a menu and I do not why it was working and now it does 
not show up.
Can yu have a look?
Normally you should do ScriptLoader showIntegrationMenu
   

I've added Issue 2447 

yes, the menu is rebuilt at compile time (when a method with  
is added, removed or updated).
for optional menu item you have to send a #precondition: message with a 
block as argument.

it gives:

menuCommandOn: aBuilder


 (aBuilder group: #Integration)
precondition: [self currentlyIntegratingChanges];
parent: #System;
with: [
(aBuilder item: #'Integrator Menu')
action: [ScriptLoader releaseMenu]]

btw: but here you don't need a group, it can be more simple:

menuCommandOn: aBuilder


(aBuilder item: #'Integrator Menu')
precondition: [self currentlyIntegratingChanges];
parent: #System;
action: [ScriptLoader releaseMenu]

Cheers
Alain

Tx

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

   



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

Re: [Pharo-project] double help entry menu when loading ProfBrowser

[Alain Plantec]

Le 19/05/2010 23:44, Mariano Martinez Peck a écrit :
Hi. When loading the prof browser in 11367  I get TWO entries called 
"help".But one has "Help browser" and the other "ProfStef Browser"


They should be in the same help entry and not duplicate

I attach two screenshots

Hi Mariano
I'll have a look
Alain

cheers

mariano


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



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

Re: [Pharo-project] double help entry menu when loading ProfBrowser

[laurent laffont]

Yes I was waiting for issue 2442 to be integrated to commit ProfStefBrowser
and ConfigurationOfProfStef. Done.

Laurent Laffont

http://pharocasts.blogspot.com/
http://magaloma.blogspot.com/


On Thu, May 20, 2010 at 2:20 AM, Alain Plantec  wrote:

> Le 19/05/2010 23:44, Mariano Martinez Peck a écrit :
>
>  Hi. When loading the prof browser in 11367  I get TWO entries called
>> "help".But one has "Help browser" and the other "ProfStef Browser"
>>
>> They should be in the same help entry and not duplicate
>>
>> I attach two screenshots
>>
> Hi Mariano
> I'll have a look
> Alain
>
>> cheers
>>
>> mariano
>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project