Re: [Pharo-project] Notifications of windows opening/closing/focus

[Henrik Johansen]

On Jan 7, 2010, at 12:49 57PM, Gary Chambers wrote:

> I think the annnouncements should be sent by the World (being, effectively, 
> the window manager).
> Too many ways to open open a window exist and only the fact of being added 
> to the World seems consistent.
> I suggest opened, closed, activated (becoming topmost-ish), deactivated, 
> expanded, collapsed, restored and maybe repositioned/resized would be 
> useful.
> 
> Regards, Gary
I thought the same, thus my first thought was doing it in PasteupMorph>> 
addMorph:.

Now I think it's a bad idea, because:
- Not all PasteUpMorphs are necessarily Worlds.
- Not all morphs added to Worlds are windows.

If putting it in a SystemWindow method means having to refactor some methods so 
all ways of opening a window passes through that method, I don't really see 
that as a bad thing.
As far as I can tell though, all open... methods for SystemWindow + subclasses 
already pass through #openAsIsIn:

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] Notifications of windows opening/closing/focus

[Henrik Johansen]

On Jan 7, 2010, at 2:10 04PM, Gary Chambers wrote:

> That is one option, though it does seem to be burdensome on the announcement 
> consumers to (depending upon requirements) possibly have to track all 
> windows themselves.
> 
> Regards, GaryI am not talking about Announcers, but where the Announcement is 
> created.

I'm not talking about letting the window be the announcer, but where the 
announcement is made.

So you'd do 
openAsIsIn: aWorld
"current implementation"
someAnnouncer announce: (WindowOpened for: self in: self world)

someAnnouncer could be a global announcer for all window events.

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] Simple question about NewInspector

[Henrik Johansen]

In latest version from ss, loaded into PharoCore, it does a MNU 
ByteString>types.

ProtoObject >> niChildrenBlockForFixedFields, in the line: 

extractedType types do: [:t | s nextPutAll: t printString] separatedBy: [s 
nextPutAll: ', ']. 
extractedType is the string you mentioned.

Cheers,
Henry

On Jan 4, 2010, at 9:49 49AM, Frederic Pluquet wrote:

> RoelTyper is also used in ProtoObject>>niChildrenBlockForFixedFields (an 
> extension for NewInspector).
> 
> NewInspector can work without RoelTyper. The message "The last version of 
> RoelTyper must be loaded to have this information" is shown when NewInspector 
> tries to calculate types and that RoelTyper is not found.
> 
> 
> Fréd
> 
> Frédéric Pluquet
> Université Libre de Bruxelles (ULB)
> Assistant
> http://www.ulb.ac.be/di/fpluquet
> 
> 
> On Sat, Dec 26, 2009 at 11:29 PM, Mariano Martinez Peck 
>  wrote:
> Hi Frederic. I am trying to see if it make sense to create a metacello 
> configuration for NewInspector.   The only external (not in PharoCore) 
> dependency I saw using the DependencyBrowser is RoelTyper, which is used in 
> the class NICompiledMethodNode >> configurationyou use the class 
> TypeCollector  which is from RoelTyper.
> 
> So, the question is, is this dependency correct?  I ask because I took a 
> PharoCore image, load NewINspector WITHOUT RoelTyper and it "seemed" to work.
> 
> Thank you very much.
> 
> 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] Notifications of windows opening/closing/focus

[Henrik Johansen]

NVM this, I only read the top and thought it was in reply to my last mail, not 
Simons :)

On Jan 7, 2010, at 2:28 31PM, Henrik Johansen wrote:

> 
> On Jan 7, 2010, at 2:10 04PM, Gary Chambers wrote:
> 
>> That is one option, though it does seem to be burdensome on the announcement 
>> consumers to (depending upon requirements) possibly have to track all 
>> windows themselves.
>> 
>> Regards, GaryI am not talking about Announcers, but where the Announcement 
>> is created.
> 
> I'm not talking about letting the window be the announcer, but where the 
> announcement is made.
> 
> So you'd do 
> openAsIsIn: aWorld
> "current implementation"
> someAnnouncer announce: (WindowOpened for: self in: self world)
> 
> someAnnouncer could be a global announcer for all window events.
> 
> 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] Notifications of windows opening/closing/focus

[Henrik Johansen]

On Jan 8, 2010, at 11:56 18AM, Gary Chambers wrote:

> Looks ok to me.
> 
> Regards, Gary
> 
> - Original Message - 
> From: "Stéphane Ducasse" 
> To: 
> Sent: Thursday, January 07, 2010 8:27 PM
> Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus
> 
> 
>> 
>>> Hi!
>>> 
>>> In the PharoTaskForces SqueakSource repository I committed a new
>>> version of Morphic (Morphic-Alexandre_Bergel.393). This version
>>> includes the window announcement I have been working on for few months
>>> already.
>>> 
>>> Here is an example of a unit test.
>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>> MorphicWindowNotificationTest>>testWindowCreationAndDeletion
>>> 
>>> | t window newWindowCreated r |
>>> t := 0.
>>> World announcer on: MorphicCreationWindowAnnouncement do: [:ann |
>>> t := t + 1. newWindowCreated := ann window].
>>> World announcer on: MorphicClosingWindowAnnouncement do: [:ann | t :=
>>> t + 10. newWindowCreated := ann window].
I don't particularly like the naming.

- Why including Announcement at the end?
- Why does one contain a verb, and the other a 
- When are they fired? Closing implies to me it's not been closed yet, but 
fired somewhere after the closing has started, while CreationWindow I have no 
idea what means.

MorphicWindowOpen(ed/ing)
MorphicWindowClos(ed/ing)

are both easier to read for me, shorter, and more in line with the naming 
convention for Pragma announcements already in Pharo.

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] Problems with Strike fonts

[Henrik Johansen]

The fix is easy, add at end of StrikeFont>>createDejaVu:

oblique derivativeFont: boldOblique at: 1.
oblique derivativeFont: oblique at: 2.
oblique derivativeFont: boldOblique at: 3.
boldOblique derivativeFont: boldOblique at: 1.
boldOblique derivativeFont: boldOblique at: 2.
boldOblique derivativeFont: boldOblique at: 3.


The evaluate StrikeFont installDejaVu

and voila! you using the bitmapped versions instead of making derived Oblique 
Oblique fonts, or deriving Bold Oblique font version from Oblique fonts 
manually.

Cheers,
Henry


On Jan 8, 2010, at 3:23 51PM, Adrian Lienhard wrote:

> It seems that emphasized strike fonts do not render properly?
> 
> Anyway, we planned to put back the FreeType deja vu fonts for the  
> Pharo image (but keep the strike fonts installed for PharoCore). Since  
> syntax highlighting is only delivered with Pharo, the problem will not  
> be apparent anymore.
> 
> Adrian
> 
> On Jan 8, 2010, at 15:11 , Mariano Martinez Peck wrote:
> 
>> Thanks Stef, I wanted to see if you were paying attention ;)
>> 
>> hahahah
>> 
>> On Fri, Jan 8, 2010 at 3:03 PM, Alexandre Bergel  
>> wrote:
>> 
>>> No screenshto attached
>>> 
>>> Alexandre
>>> 
>>> 
>>> On 8 Jan 2010, at 10:43, Mariano Martinez Peck wrote:
>>> 
 Weeks ago Lukas reported an issue with StrikeFonts width. I don't
 know if it is the same, but in the latest dev with StrikeFonts
 (pharo1.0-10502-rc1dev09.12.2) you cannot even understand the text.
 
 Look the attached screenshot ?  What do you think it says ?
 
 Ok, it says: "OCompleti"
 
 I am the only one that see that ?
 
 cheers
 
 mariano
 ___
 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 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] Problems with Strike fonts

[Henrik Johansen]

On Jan 8, 2010, at 4:24 25PM, Mariano Martinez Peck wrote:

> Thanks Henrik. However, I tried what you told me and still is ugly :(
> 
> Any idea?
> 
> Thanks
> 
> Mariano
Try setting Code Font to italic though, bolded message names in browsers will 
now look nice, where they previously where fugly :)

To fix the text you mentioned, you additionally need to remove the call to 
isSynthetic: true from StrikeFont >> makeUnderlinedGlyphs.
(Synthetic is only valid if the emphasis alters character width, which 
underlining it does not)

Cheers,
Henry


> 
> On Fri, Jan 8, 2010 at 4:15 PM, Henrik Johansen 
>  wrote:
> The fix is easy, add at end of StrikeFont>>createDejaVu:
> 
>oblique derivativeFont: boldOblique at: 1.
>oblique derivativeFont: oblique at: 2.
>oblique derivativeFont: boldOblique at: 3.
>boldOblique derivativeFont: boldOblique at: 1.
>boldOblique derivativeFont: boldOblique at: 2.
>boldOblique derivativeFont: boldOblique at: 3.
> 
> 
> The evaluate StrikeFont installDejaVu
> 
> and voila! you using the bitmapped versions instead of making derived Oblique 
> Oblique fonts, or deriving Bold Oblique font version from Oblique fonts 
> manually.
> 
> Cheers,
> Henry
> 
> 
> On Jan 8, 2010, at 3:23 51PM, Adrian Lienhard wrote:
> 
> > It seems that emphasized strike fonts do not render properly?
> >
> > Anyway, we planned to put back the FreeType deja vu fonts for the
> > Pharo image (but keep the strike fonts installed for PharoCore). Since
> > syntax highlighting is only delivered with Pharo, the problem will not
> > be apparent anymore.
> >
> > Adrian
> >
> > On Jan 8, 2010, at 15:11 , Mariano Martinez Peck wrote:
> >
> >> Thanks Stef, I wanted to see if you were paying attention ;)
> >>
> >> hahahah
> >>
> >> On Fri, Jan 8, 2010 at 3:03 PM, Alexandre Bergel
> >> wrote:
> >>
> >>> No screenshto attached
> >>>
> >>> Alexandre
> >>>
> >>>
> >>> On 8 Jan 2010, at 10:43, Mariano Martinez Peck wrote:
> >>>
> >>>> Weeks ago Lukas reported an issue with StrikeFonts width. I don't
> >>>> know if it is the same, but in the latest dev with StrikeFonts
> >>>> (pharo1.0-10502-rc1dev09.12.2) you cannot even understand the text.
> >>>>
> >>>> Look the attached screenshot ?  What do you think it says ?
> >>>>
> >>>> Ok, it says: "OCompleti"
> >>>>
> >>>> I am the only one that see that ?
> >>>>
> >>>> cheers
> >>>>
> >>>> mariano
> >>>> ___
> >>>> 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 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] [ANN] ClaseUseDiscovery tool

[Henrik Johansen]

On Jan 11, 2010, at 9:59 13AM, Mariano Martinez Peck wrote:

> Hi folks:  As part of my PhD I started to work with ImageSegment. This week I 
> clean up all the stuff related to class discovery from there. I then wanted 
> to put that extracted code in a separate class. I didn't like that code at 
> all, so at the end I finished rewriting completely this stuff.
> 
> The cool thing is that:
> 
> - I remove all that stuff from ImageSegment (which has nothing to do with 
> that)
> - I remove that stuff from classes like Behavior and ClassDescription
> - I put all these as an external package that can be perfectly loaded in core
> - I rewrote that in style that I like much more. At least for me, it is much 
> more easy to understand and to use now
> - I wrote test cases
> - I wrote good class comment. 
> 
> The repository is: http://www.squeaksource.com/ClaseUseDiscovery
>  and the license is MIT.
> 
> It is a little project, but maybe someone find it useful. This project only 
> works with Pharo images newer than 1.1  version 11142
> 
> I paste here the class comment of CUDClassesUseDiscoverer:
> 
> Cheers
> 
> Mariano
> 
> 
> 
> 
> This approach of swapping out inactive classes have two big problems:
> 
> - The granularity is too high: the class. As soon as only one method is 
> invoked, the whole class is recovered. 
> - It is very common to recover all classes doing a simple action. For 
> example, searching for implementors or senders of a certain method. Because 
> of this, when you are developing in your Smalltalk image is very likely that 
> all classes are recovered in less than 5 minutes of work. It is not useful. 
> Browsing or editing code seems not to be a problem, thus. Maybe this approach 
> has more sense in production images rather than development. 

I guess the next tool you'll make is CUDMethodUseDiscover? ;)

Good job, and good luck!

Cheers,
Henry
 
PS. like in MessageTally, maybe a useful constructor method would be one taking 
a block as argument, and running trace during its execution?___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] inspector and auto-update

[Henrik Johansen]

NewInspector is not in Core.

What I've noticed is AutoUpdating of inspector values stopping to work under 
certain circumstances, like a halt raising a debugger while the inspector is 
selected.
Rather certain this has to do with terminated threads caused by debugger 
opening, similar to a MessageTally never popping up if you encounter a halt in 
code after MT is started.

Cheers,
Henry

On Jan 11, 2010, at 11:16 14AM, Damien Cassou wrote:

> On Wed, Jan 6, 2010 at 9:41 PM, Marcus Denker  wrote:
>>> However this behaviour is lacking in a
>>> PharoCore1.0rc1
>>> Latest update: #10502
>>> 
>>> So is that what is expected?
>>> 
>> 
>> auto-update is supposed to work with the inspector... if not, it's a bug.
> 
> the NewInspector does not support this feature if I remember correctly.
> 
> -- 
> Damien Cassou
> http://damiencassou.seasidehosting.st
> 
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
> 
> ___
> 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] [update 1.1] #11153

[Henrik Johansen]

I think you missed the "StrikeFont installDejaVu", which is necessary to 
reinstall BitMap DejaVu with correct derived fonts.
At least for me, setting code font to italic, then opening a system browser on 
a method still looks bad

Cheers,
Henry

 
On Jan 12, 2010, at 5:34 03PM, Marcus Denker wrote:

> 11153
> -
> 
> Issue 268:TODO: CurvierMorph should be merged with PolygonMorph
> Issue 1141:   Monticello directory selection window is non-resizable and very 
> small
> Issue 1770:   Kernel-Tests-ClassBuilder category is not remove after 
> ClassBuilderFormatTests tests are run
> Issue 1774:   Monticello repository edit works but doesnt update UI
> Issue 1780:   StrikeFont issues with derived fonts
> Issue 1782:   Save Dialog too small
> 
> --
> 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 mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ConfigurationOfAlien

[Henrik Johansen]

On Jan 13, 2010, at 6:06 53PM, Schwab,Wilhelm K wrote:

> That's great news, at least for mac users.  What does a penguin herder do to 
> get a plugin?

1) Download VM sources for latest release from www.squeakvm.org.
2) Make an image with VMMaker and AlienPlugin.
3) Use VMMakerTool to generate AlienPlugin sources.
4) (possibly) use special sqVirtualMachine.c/h from  the \Cross\plugins\IA32ABI 
folder.
5) Try to compile, fix errors that pop up.
6) Repeat step5 enough times that you end up with a compiled plugin.


>  Would it be easier to use a squeak image to build it?
Only step 2, unless you load from  www.squeaksource.org/JBARepo, and run 
VMMakerLoader loadAndFix.

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] ConfigurationOfAlien

[Henrik Johansen]

On Jan 13, 2010, at 7:00 23PM, Levente Uzonyi wrote:

> On Wed, 13 Jan 2010, Henrik Johansen wrote:
> 
>> 
>> On Jan 13, 2010, at 6:06 53PM, Schwab,Wilhelm K wrote:
>> 
>>> That's great news, at least for mac users.  What does a penguin herder do 
>>> to get a plugin?
>> 
>> 1) Download VM sources for latest release from www.squeakvm.org.
>> 2) Make an image with VMMaker and AlienPlugin.
>> 3) Use VMMakerTool to generate AlienPlugin sources.
>> 4) (possibly) use special sqVirtualMachine.c/h from  the 
>> \Cross\plugins\IA32ABI folder.
>> 5) Try to compile, fix errors that pop up.
>> 6) Repeat step5 enough times that you end up with a compiled plugin.
> 
> 7) Run the tests and wonder why your plugin doesn't work. Repeat 1-7 a few 
> times.
> 8) Give up and wait till someone else succeeds.

Well, yes. 

> 
>> 
>> 
>>> Would it be easier to use a squeak image to build it?
>> Only step 2, unless you load from  www.squeaksource.org/JBARepo, and run 
>> VMMakerLoader loadAndFix.
> 
> I wonder why are these packages forked.

It's not really forked, just installing versions different to what is in 
VMMaker repository that needs to be changed to work with Pharo.

In specific, the two I remember:
- One of the methods specified in MiscPrimitivePlugin didn't work/return an 
error for WideStrings. The solution in Pharo was to introduce an extra layer of 
indirection, since the method itself was called many places, the original 
definition was moved to a method called ...viaPrimitive (should be renamed 
prim...), and handling introduced before prim call was made. (using fallback 
instead if param was WideString).

- One of the methods used by VMMaker had a spelling error, which has been fixed 
in Pharo, something with occurrencesOf: I think.

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] Issue with deprecated method in ByteString

[Henrik Johansen]

Don't divide a number by a ByteArray?;)

Cheers,
Henry

Den 14. jan. 2010 kl. 19.25 skrev John Toohey :

> Hi,
>
> Running some tests of my own app, I just got a deprecated warning  
> popup in the debugger. The method is #isZero in ByteString, and  
> isZero is called from SmallInteger #/. I'm using the 10506 Core  
> image. What can I do to fix this?
>
> -- 
> -JT
>
>
> ___
> 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] Issue with deprecated method in ByteString

[Henrik Johansen]

Then remember to handle invalid input gracefully too :)
Cheers

Den 14. jan. 2010 kl. 19.40 skrev John Toohey :


:-) forgot an #asNumber in one of my forms.

On Thu, Jan 14, 2010 at 13:35, Henrik Johansen > wrote:

Don't divide a number by a ByteArray?;)

Cheers,
Henry

Den 14. jan. 2010 kl. 19.25 skrev John Toohey :

> Hi,
>
> Running some tests of my own app, I just got a deprecated warning
> popup in the debugger. The method is #isZero in ByteString, and
> isZero is called from SmallInteger #/. I'm using the 10506 Core
> image. What can I do to fix this?
>
> --
> -JT
>
>
> ___
> 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



--
-JT


___
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] [update 1.1] #11164

[Henrik Johansen]

The hardcoded debugger change causes the "Debug it" command to fail.

What is the extra isolationHead: parameter for anyways?

Cheers,
Henry

On Jan 16, 2010, at 9:26 55PM, Marcus Denker wrote:

> 11164
> -
> 
> Issue 441:Hardcoded debugger
> Issue 1828:   testAnnotationPane
> Issue 1819:   1.1: some packages have no repository
> 
> 
> --
> 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 mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] testing the linux vm of pharo-project

[Henrik Johansen]

On Jan 19, 2010, at 3:52 05PM, laurent laffont wrote:

> Some thoughts:
> 
> In the Linux world it's better to have the source code first, and compiled 
> version for convenience.
> 
> For squeak-3.11 there's the source code and it's easy to build following 
> instructions included in the README. It's clean.
> 
> For exupery-vm several people have already asked for source code on this list 
> to create packages for their favorite distrib.  Furthermore the binary is 
> named squeak, not pharo-vm or whatever not really cool. Lot of garbage in 
> the archive. Exupery vm for windows is cleaner (but contains one file called 
> Squeak.exe ;) ).
> 
> Why on Mac it's squeak 4.2.2 b1, on windows/linux squeak 3.11 ? I suppose 
> there's an influence on unit tests / performance / 
> 

John's Mac VM's major version number were bumped to 4 when closures where 
added,  partly because it breaks some backwards-compatability.
See recent vmdev discussion about issues running 2.5-based Scratch images for 
some more details
According to the mentioned discussion, the unix major version might have been 
increased too, had the author picked up on it.


> Finally I don't know why there's an "alternative" download ... I think the 
> alternative stuff should be on the wiki, not on the basic download page.

Historical reasons.
The Exupery VM provided unix/windows builds with closure bytecodes in october 
2008, while the official VM's lagged behind.
The windows version was updated not too far behind, but a unix release for 
closures wasn't made until august 09.

At the time, the exupery VM also included some other fixes not found in the 
official releases, I can't say I know the status of those at this moment though.

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] After OB, compare to current version uses old diff

[Henrik Johansen]

Preferences >> useNewDiffToolsForMC?

There was some discussion some time back, I believe Lukas stated he liked the 
old tools better.
Can't say I blame him, I'm never quite sure if I'm installing new one or 
keeping old when merging from MC until after the fact when I use the Polymorph 
tools ...

Cheers,
Henry

On Jan 19, 2010, at 5:05 26PM, Mariano Martinez Peck wrote:

> Hi: If you take a PharoCore image, and browse the editions of a class, then 
> select an older one, and then select "compare to current", you see the 
> differences using the "new" diff, the same that we use in MC.
> 
> However, after installing OB in a core image, it uses the "old" version. I am 
> not sure that change is due to OB, but at least it seems. I checked in 
> Preferences but I didn't find anything. 
> 
> Any hint how to put new diff again after installing OB ?
> 
> Thanks!
> 
> 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] how to get nice native fonts in 1.0

[Henrik Johansen]

On Jan 20, 2010, at 8:48 10AM, Stéphane Ducasse wrote:

> Hi 
> 
> I have to give some demos of seaside today and I would like to have nice 
> fonts in 1.0
> and I cannot find the preferences to say that the fonts can be looked up on 
> my disc.
> 
> 
> Stef

I don't think there is one...
If Native fonts don't show up in the selection list, or they do, but are 
preview-rendered as Accuny, pressing the Update button should do the trick.

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] Scripts that should be run after a slice and ScriptLoader

[Henrik Johansen]

On Jan 20, 2010, at 1:25 09PM, Simon Denier wrote:

> 
> On 20 janv. 2010, at 11:29, Mariano Martinez Peck wrote:
> 
>> Hi: I found that several times, we need to run some piece of code after a 
>> slide. The only way I see doing this is to write it in a txt , and, 
>> hopefully (many times, the commiter or the integrator forget about it), 
>> remember to put that in the email or issue, when I let you know the fix is 
>> ready.  Is there a better way ? 
>> 
>> What about having a method in ScriptLoader where we can commit that together 
>> with the slice? Then when someone integrates that, it will see that, and 
>> will move that piece of code, from there, to the update or script methods.
>> 
>> I don't know. What do you think ?
> 
> 
> If I understood correctly, Monticello already has this feature for package so 
> I guess it should work for slices.
> 
> Click on a package in MC browser, then click on the 'Scripts' button in the 
> toolbar, you get menu to edit the preamble, postscript, as well as 
> preambleOfRemoval and postscriptOfRemoval

Preamble/Postscripts don't work anymore in Pharo though, following the 
procedure you outlined I get a DNU when selecting the script I want to edit. 
Not sure when they were removed, but probably it was part of some PackageInfo 
cleaning.

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] O2: tester wanted!

[Henrik Johansen]

On Jan 21, 2010, at 2:30 18PM, David Röthlisberger wrote:

> 
>> 
>> OR2PackageBrowser does not open, it lacks a defaultRootNode method 
>> returning other than nil.
>> Is the focus mainly on the O2* browsers, or should OR2* also work?
> 
> How did you spot this problem? From within the O2 browser, OR2PackageBrowser 
> works.
> OR2PackageBrowser is not meant to be used independently from the O2 browser.
> Something like 'OR2PackageBrowser open' is not supposed to work, as the 
> OR2PackageBrowser 
> gets the root node from the O2 browser, so there is no reasonable default 
> root node.
> 
> Or do you see other problems when using OR2PackageBrowser from within O2?
> 
> David
I did OR2PackageBrowser open directly, thinking it was a standalone browser. :/
Not quite sure how/when I use it from within O2, but the refactoring items I've 
tried in O2PackageBrowser seem to work :)

Quick question: How do you open a browser of methods referring an instance 
variable from the O2PackageBrowser?

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] Mac VM 5.4b1 ships

[Henrik Johansen]

Den 25.01.2010 15:34, skrev Marcus Denker:
> Hi John,
>
> Somehow drag-and-drop from the Finder into Pharo is not working for me... If 
> I drag a changeset on the Pharo desktop, in the old vm it would
> be filed in. Now, it can not be dragged to the Pharo window anymore.
>
> Strange... it worked in the 4er series ok, never in the new 5er.
>
>   Marcus
>   
Considering any file dropped on the image is interpreted as if in
MacRoman encoding, I'd consider that a good thing (tm) ;)
(Unless, of course, you're quaint enough to never use anything of
character value > 127)

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] Mac VM 5.4b1 ships

[Henrik Johansen]

Den 25.01.2010 19:03, skrev John M McIntosh:
> On 2010-01-25, at 7:06 AM, Henrik Johansen wrote:
>
>   
>> Den 25.01.2010 15:34, skrev Marcus Denker:
>> 
>>> Hi John,
>>>
>>> Somehow drag-and-drop from the Finder into Pharo is not working for me... 
>>> If I drag a changeset on the Pharo desktop, in the old vm it would
>>> be filed in. Now, it can not be dragged to the Pharo window anymore.
>>>
>>> Strange... it worked in the 4er series ok, never in the new 5er.
>>>
>>> Marcus
>>>
>>>   
>> Considering any file dropped on the image is interpreted as if in
>> MacRoman encoding, I'd consider that a good thing (tm) ;)
>> (Unless, of course, you're quaint enough to never use anything of
>> character value > 127)
>>
>> Cheers,
>> Henry
>> 
> Ok, is that the file name that interpreted as mac roman? Or the contents of 
> the text file? 
> Both are bugs, please make an pharo bug entry. 
http://code.google.com/p/pharo/issues/detail?id=1608

Same thing happens for any file dropped on the image (when dropping works).
The offending method is MultiByteBinaryOrTextStream>>setConverterForCode.

Not sure if Squeak used to save all files MacRoman encoded, but now they
definately do not. (As evidenced by the example .mcz attached to the issue)

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] Mac VM 5.4b1 ships

[Henrik Johansen]

Den 25.01.2010 19:22, skrev John M McIntosh:
> Well it's not a VM issue. The VM has no idea what the file contains, the 
> Smalltalk code has to figure those details. 
>
>   
I know.
Which is why I tried to point out DragPlugin not working isn't that big
a loss.
Using it currently will likely lead to subtle errors untill the image
code is fixed.
(Like invalid utf8-characters in the changes, etc.)

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] readOnlyFileNamed:do: vs. ...

[Henrik Johansen]

My guess is he uses a method which does not register the file in
FileRegistry, thus avoids a WeakDict cleanup when he closes the file
after the block has been evaluated.
(eg readOnlyFileNamed:do: vs. readOnlyFileNamed:)
Thus, a lot of time is saved from not doing weak registry cleanup.
(Which can be a large chunk of the total time when you do many small
operations).

Cheers,
Henry

Den 02.02.2010 10:50, skrev Stéphane Ducasse:
> Nicolas I saw that in squeak you changed and use readOnlyFileNamed:do:
> I like it but I would like to understand what is the key advantage
>
>
> fromFileNamed: aName
>   FileStream readOnlyFileNamed: aName do: [:stream |
>stream setConverterForCode.
>self fileInFrom: stream]
>
> fromFileNamed: aName
>| stream |
>stream := FileStream readOnlyFileNamed: aName.
>stream setConverterForCode.
>[self fileInFrom: stream] ensure: [stream close].
>
> ___
> 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] readOnlyFileNamed:do: vs. ...

[Henrik Johansen]

Scratch that. It's what I would have done with a fileNamed:do: selector :)

The main difference is readOnlyFileNamed:do: does not evaluate the block
if file creation returns nil, while the second code errors out with
stream dnu setConverterFromCode if the file could not be opened for any
reason.

Cheers,
Henry

Den 02.02.2010 11:02, skrev Henrik Johansen:
> My guess is he uses a method which does not register the file in
> FileRegistry, thus avoids a WeakDict cleanup when he closes the file
> after the block has been evaluated.
> (eg readOnlyFileNamed:do: vs. readOnlyFileNamed:)
> Thus, a lot of time is saved from not doing weak registry cleanup.
> (Which can be a large chunk of the total time when you do many small
> operations).
>
> Cheers,
> Henry
>
> Den 02.02.2010 10:50, skrev Stéphane Ducasse:
>   
>> Nicolas I saw that in squeak you changed and use readOnlyFileNamed:do:
>> I like it but I would like to understand what is the key advantage
>>
>>
>> fromFileNamed: aName
>>   FileStream readOnlyFileNamed: aName do: [:stream |
>>stream setConverterForCode.
>>self fileInFrom: stream]
>>
>> fromFileNamed: aName
>>| stream |
>>stream := FileStream readOnlyFileNamed: aName.
>>stream setConverterForCode.
>>[self fileInFrom: stream] ensure: [stream close].
>>
>> ___
>> 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] readOnlyFileNamed:do: vs. ...

[Henrik Johansen]

Den 02.02.2010 13:00, skrev Schwab,Wilhelm K:
> Henry,
>
> I would not toss your first thought too quickly.  Staying clear of 
> finalization is a big benefit.  I have never been able to trust it (for 
> files) on Dolphin, which has a remarkably better implementation of weak 
> collections and finalization than Squeak/Pharo.
>
> Bill
>   

Stephane's question was not what it should do differently though, but
what it did do differently ;)

For information:
(1 to: 3) collect: [:h | [CompiledMethod allInstancesDo: [:each | each
getSourceFromFile]] timeToRun]

Standard way, which both registers in the FileRegistry, and does close
at end of getSourceFromFile:
#(13348 12786 12712)

Explicit closing with readOnlyFileNamed:do:
 #(12091 12061 12189) 

Considering the amount of work done in reading each source, that's not
entirely insignificant,
but it requires quite a large amount of additional private protocol in
the FileStream classes...

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] readOnlyFileNamed:do: vs. ...

[Henrik Johansen]

Den 02.02.2010 13:14, skrev Henrik Johansen:
> For information:
> (1 to: 3) collect: [:h | [CompiledMethod allInstancesDo: [:each | each
> getSourceFromFile]] timeToRun]
>
> Standard way, which both registers in the FileRegistry, and does close
> at end of getSourceFromFile:
> #(13348 12786 12712)
>
> Explicit closing with readOnlyFileNamed:do:
>  #(12091 12061 12189) 
>   
Blargh, numbers were without nextChunk update.

With latest version, the differences are:

Standard way, which both registers in the FileRegistry, and does close
at end of getSourceFromFile:
#(7697 7684 7694)

Explicit closing with readOnlyFileNamed:do:
 #(6586 6597 6594)

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] Morphic cleaning

[Henrik Johansen]

Den 05.02.2010 11:15, skrev Laval Jannik:
> Hi all,
>
> I have used SystemNavigation>>unsentMessagesInPackageNamed:
> on the package Morphic.
>
Wow, I feel your pain, the runtime of that method is quite brutal for
large packages...

Find attached a somewhat faster (but still slow) implementation.

Test:
findTime := [unsent := SystemNavigation default
unsentMessagesInPackageNamed: 'Morphic'] timeToRun

Numbers on my machine:
Current:
findTime - 29 minutes, 35 seconds.
unsent size - 531

Attached:
findTime - 3 minutes, 9 seconds.
unsent size - 531

Cheers,
Henry
'From PharoCore1.1ALPHA of ''19 October 2009'' [Latest update: #11194] on 5 
February 2010 at 1:50:49 pm'!

!TPureBehavior methodsFor: 'testing method dictionary' stamp: 
'HenrikSperreJohansen 2/5/2010 13:44'!
thoroughHasSelectorReferringTo: literal special: specialFlag byte: specialByte
"Answer true if any of my methods access the argument as a 
literal. Dives into the compact literal notation, making it slow but 
thorough "


self methodsDo: [ :method |
((method hasLiteralThorough: literal) or: [specialFlag and: 
[method scanFor: specialByte]])
ifTrue: [^true]].
^false! !


!SystemNavigation methodsFor: 'message sends' stamp: 'HenrikSperreJohansen 
2/5/2010 13:49'!
isUnsentMessage: selector
| special byte |

special := Smalltalk 
hasSpecialSelector: selector
ifTrueSetByte: [ :b | byte := b ].
self allBehaviorsDo: 
[ :behavior | 
(behavior 
thoroughHasSelectorReferringTo: selector
special: special
byte: byte) ifTrue: [^false] ].
^true! !

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

Re: [Pharo-project] Morphic cleaning

[Henrik Johansen]

You can now do

findTime := [unsent := SystemNavigation default
unsentMessagesInPackageNamed: '*'] timeToRun

in the time it used to take for Morphic alone. (about 30 mins)
That's the entire system btw, 7486  unsents in my core image ;)

Cheers,
Henry


Den 05.02.2010 14:11, skrev Stéphane Ducasse:
> [update 1.1] #11196
> 11196
> -
>
> - faster isUnsentMessage: tx Henrik
>
>
>
>
>
> On Feb 5, 2010, at 1:54 PM, Henrik Johansen wrote:
>
>   
>> Den 05.02.2010 11:15, skrev Laval Jannik:
>> 
>>> Hi all,
>>>
>>> I have used SystemNavigation>>unsentMessagesInPackageNamed:
>>> on the package Morphic.
>>>
>>>   
>> Wow, I feel your pain, the runtime of that method is quite brutal for
>> large packages...
>>
>> Find attached a somewhat faster (but still slow) implementation.
>>
>> Test:
>> findTime := [unsent := SystemNavigation default
>> unsentMessagesInPackageNamed: 'Morphic'] timeToRun
>>
>> Numbers on my machine:
>> Current:
>> findTime - 29 minutes, 35 seconds.
>> unsent size - 531
>>
>> Attached:
>> findTime - 3 minutes, 9 seconds.
>> unsent size - 531
>>
>> 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

Re: [Pharo-project] something in 1.1 broke ImageSegment

[Henrik Johansen]

Den 09.02.2010 06:14, skrev Levente Uzonyi:
> On Mon, 8 Feb 2010, Henrik Sperre Johansen wrote:
>
>   
>> I believe its due to stream positioning when crossing buffer boundries in 
>> basicChunk, I have to debug a bit further for a solution though, sorry...
>> 
> It seems to be an easy one, though I didn't try the fix, just reviewed 
> the code. So the cause of the issue is in MultiByteFileStream >> 
> #basicChunk, which doesn't care about readLimit. When readLimit is less 
> than "collection size", the end of the returned chunk may be the end of a 
> previous chunk.
>   
Thanks Levente, in my original-author-blindness, I couldn't see past
that position was apparently set wrong compared to the original
approach. When you say it like that, it's obvious :)
> This method has at least two other flaws (These probably won't hurt 
> anyone in the near future, though both can be avoided):
> 1. if read buffering is disabled it will raise an error
>   
Yes, this should be fixed. I assume a collection ifNil: [^nil] is enough?
> 2. it assumes that the encoding of the stream is ascii compatible
>
>   
Yes, that was a tradeoff. (Which I hoped was a clear implication from
the method comment)
Only Converter with this characteristic currently existing (afaict) is
QuotedPrintable, I doubt that or another format will ever be used for
storage of code.
The method you wrote in Squeak doesn't have this limitiation, on the
other hand that does little for encodings other than utf8 (which, of
course, could be successfully argued to be the important case).
This way, you also avoid a Stream creation/String copy in the common
case, as well as not let encodings in addition to streams contain
special logic to read in code chunks.
> Levente
>
>   
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] broken polymorph example in 1.1?

[Henrik Johansen]

I couldn't help noticing there are also a few Undefined entries
resulting from the Squeak-ToolBuilder merge, should also be looked into :)

Cheers,
Henry

Den 09.02.2010 08:22, skrev Stéphane Ducasse:
> Really may be one of my mistakes.
>
> stef
>
> On Feb 8, 2010, at 12:30 PM, Gary Chambers wrote:
>
>   
>> Looks like PluggableDialogWindow has had its superclass changed (was 
>> DialogWindow)...
>>
>> Regards, Gary
>>
>> - Original Message - 
>> From: "Hilaire Fernandes" 
>> To: 
>> Sent: Saturday, February 06, 2010 5:04 PM
>> Subject: [Pharo-project] broken polymorph example in 1.1?
>>
>>
>> 
>>> Is it me or examples of the Polymorph usage are broken?
>>>
>>> For example exampleOtherControls break
>>>
>>> Hilaire
>>>
>>>
>>> ___
>>> 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] OpenGL in pharo?

[Henrik Johansen]

Den 11.02.2010 10:48, skrev Torsten Bergmann:
>> It would be good to have 'AlienFFI working on linux' published so that we 
>> >can use it.
>> 
> I still wonder what's required to have it available on any
> Squeak/Pharo platform (incl. Windows) similar to FFI?
>
> Does one just have to generate the plugin or is OS specific
> code required?
>
> Bye
> T.
>   
My short foray into compiling it on Windows:
http://n4.nabble.com/Re-MPEG-in-Pharo-depricated-why-td1299484.html#a1299489

Haven't had time to look into it more since then, but there's definately
more involved than just generating and compiling the plugin.

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] labeled or labelled?

[Henrik Johansen]

Den 12.02.2010 13:13, skrev Torsten Bergmann:
> Question to native english speakers, what is correct:
>
>  a)  MyClass labeled: 'foo'
>  b)  MyClass labelled: 'foo' 
>
> for a class MyClass defining an instance variable "label".
>
> Me and google would tend to a) but there is a method
> #labelled: on SystemWindow.
>
> Thx
> T.
>
>
>   
AFAIK:
labelled - en-GB
labeled - en-US
Seeing as there is no Behaviour in Smalltalk, I'd go for labeled:

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] Pharo changing the game

[Henrik Johansen]

Den 12.02.2010 14:52, skrev Stéphane Ducasse:
>> > Hint: FFI has its own proprietary hardcoded pragma format. 
>
> PS: do you know if FFI declarations are compatible with VW ones or they are
> just funky?
>   

FWIW, DLLCC-declarations are not pragma-compatible either, not sure if
they're the same as FFI though.
In fact, seing as how ExternalMethod depends on inst var indexes,  you
*can't* annotate DLLCC-methods (AnnotatedMethod adds inst var with
pragmas, so can't easily make ExternalMethod a subclass of it).
I see it's implemented differently in Squeak/Pharo though, is it
possible to do that with FFI? How about Alien?

In my mind, that is a loss for external libraries accessing-code which
wants to provide a nice way to deal with changing versions (where
version is queriable from the library), as it .

F.ex. in the case of OpenGL, being able to tag the ExternalMethods with
pragmas like
, etc would make it possible to know if an unsuccessfully resolved
method was due to not being supported by your driver/hardware, or a
coding error somewhere.
It would also be easier to programatically build version-compliant
interfaces instead of always prividing an Interface with a superset of
what is needed/available.

Plus, reasoning about which versions of a plugin is required from a
piece of code using the interface gets a whole lot easier.

Sure, you can do all of the above with dictionaries of which versions
include which methods, but upgrading that to support a new version would
be a huge pain, wheras with the pragma approach you simply add new
annotations for the things which have changed.

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] FileSystem question

[Henrik Johansen]

Den 12.02.2010 16:18, skrev Stéphane Ducasse:
> I'm trying to move some of the examples of Coral from rio to filesystem and I 
> get some questions.
>
> Are there some examples (not tests)?
> What is the difference between FSReference and FSPath?
>
> For example how can I print in the Transcript all the files in my current dir?
>
> Stef
> _
There's probably an easier way, but:

(FSDiskFilesystem current childrenAt: FSDiskFilesystem current
workingDirectory) do:
[:each | each printOn: Transcript cr ].
Transcript flush.

Speaking of current dir...
FSDiskFilesystem current workingDirectory isWorkingDirectory -> false,
at least on Windows :)

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] DateAndTime and TimeStamp precision

[Henrik Johansen]

Den 16.02.2010 16:44, skrev Marcus Denker:
> On Feb 16, 2010, at 4:39 PM, Miguel Enrique Cobá Martinez wrote:
>
>   
>> El mar, 16-02-2010 a las 14:39 +0100, Luc Fabresse escribió:
>> 
>>> Hi,
>>>
>>>  I think it is related to: 
>>> http://code.google.com/p/pharo/issues/detail?id=982
>>>  If I remember well, there is no primitive with nano second accuracy  
>>> so it is impossible to have it in real.
>>>   
>> Yes, and indeed nano second accuracy is overkill for my current problem.
>> I only want some given precision so that
>>
>> DateAndTime now < DateAndTime now
>>
>> is always true, so that can be used to order events (object creation in
>> this case) using the date.
>> 
But it's not. DateAndTime now <= DateAndTime now.
If you are batching them together so close that resolution is an issue
why not rewrite it to something like:

currTime:= DateAndTime now.
obj Count:= 0.
someLoop whileTrue: [
newObj := aClass new time: currTime+ objCount; yourself.
currTime := currTime +1.
]

Saves you quite a few system calls as well :)


> I think this was removed as part of speeding up date and time because it was 
> slowing down everything. 
> (long time ago)
>
> And people where thinking that this is actually not true: if you ask two 
> times for a corse-grained
> time, you *can* get the same time twice if you ask faster than the base 
> resolution.
>
> It would be interesting to know how other languages handle this. 
>
>
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>   
I think the answer is as simple as you might suspect - they don't.
It doesn't really make sense to ensure now < now, so they leave it to
the developer to make sure that is the case if he really needs it.

F.ex.:
VW uses a millisecond clock for its (default) Timestamps. It provides a
microsecondValue method as well, but no default Timestamp creation
method using it.

Java provides currentTimeMillis() (walltime since Jan 1970, resolution
OS-dependent)
and nanoTime (since startup).
You can't really combine the two and get a Timestamp with nanosecond
precision that makes sense, so I'd say it does millisecond precision as
well.

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] DateAndTime and TimeStamp precision

[Henrik Johansen]

Den 16.02.2010 18:32, skrev Miguel Enrique Cobá Martinez:
> El mar, 16-02-2010 a las 18:26 +0100, Henrik Johansen escribió:
>   
>> Den 16.02.2010 16:44, skrev Marcus Denker:
>> 
>>> On Feb 16, 2010, at 4:39 PM, Miguel Enrique Cobá Martinez wrote:
>>>
>>>   
>>>   
>>>> El mar, 16-02-2010 a las 14:39 +0100, Luc Fabresse escribió:
>>>> 
>>>> 
>>>>> Hi,
>>>>>
>>>>>  I think it is related to: 
>>>>> http://code.google.com/p/pharo/issues/detail?id=982
>>>>>  If I remember well, there is no primitive with nano second accuracy  
>>>>> so it is impossible to have it in real.
>>>>>   
>>>>>   
>>>> Yes, and indeed nano second accuracy is overkill for my current problem.
>>>> I only want some given precision so that
>>>>
>>>> DateAndTime now < DateAndTime now
>>>>
>>>> is always true, so that can be used to order events (object creation in
>>>> this case) using the date.
>>>> 
>>>> 
>> But it's not. DateAndTime now <= DateAndTime now.
>> If you are batching them together so close that resolution is an issue
>> why not rewrite it to something like:
>>
>> currTime:= DateAndTime now.
>> obj Count:= 0.
>> someLoop whileTrue: [
>> newObj := aClass new time: currTime+ objCount; yourself.
>> currTime := currTime +1.
>> ]
>> 
> Thank you very much! I am doing something similar to this.

If this resembles your approach, just remember to make sure that the
function is never called frequently.
If it is, you'll have to account for (if likely enough to be a potential
problem):
a) The function being called twice in the same DateAndTime resolution
interval (code to handle this which will be different based on whether
you want to protect against sequential or concurrent calls)
b) You don't allocate so many objects you get an overflow into the next
now, then call again.

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] cull: protocol

[Henrik Johansen]

Refactoring the AXAnnouncements abit so there's no separate classes for
0-, 1-, and 2-arg blocks, and really missing these methods from
VisualWorks...
cull: is equivalent to value: protocol except they accept block with N
or less blockArgs
Yes, I know valueWithEnoughArguments:/valueWithPossibleArgs: provide the
same functionality, but the code looks much less nice using them, you
end up constructing arrays needlessly etc.
Look at the senders of valueWithPossibleArgs: for examples, very few of
those actually need the ability to accept blocks with more arguments
than they provide, and would also look nicer with cull:.

Would anyone object strongly to adding the cull:, cull:cull: methods in
core instead of putting them as extension methods?

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] cull: protocol

[Henrik Johansen]

Den 18.02.2010 21:55, skrev Stéphane Ducasse:
> henrik 
>
> I'm trying to get the pros and cons of cull:
> So am'I correct that this is useful only for situation where we have a block 
> and we do not know
> upfront its number of argument: = places where valueWithPossibleArgs: 
> Now what cull: offers is that the client does not have to create the array.
>
>  I did not check your implementation.
>
> Stef
>   
It's useful where you may or may not be interested in all the arguments
passed to a block.
Announcement and Exception handling are good examples. It covers the
same bases as valueWithPossibleArgs:, with the exception it does not
expand with nil args if block has more args than the corresponding
message sent.

Pros:
- Maps well with to the value:, value:value, etc. protocol
- Your code looks cleaner (imo), since you don't have to put the args in
an array, and it's clear in a heart beat how many args you can choose to
use in your block.
- It's faster than valueWithPossibleArgs, since you don't have to put
your args in an array (Also you avoid a max of 2 extra array creations
as part of the method)

Cons:
- Functionality is already provided by valueWithPossibleArgs: (That's a
superset though, if you need the exact functionality of cull, your code
will end up even hairier since you need an arg size check before calling
valueWithPossibleArgs:)
- Portability. VW and GNU ST has them, Squeak does not, not sure about
other implementations.

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] Object >> toFinalizeSend:to:with:

[Henrik Johansen]

The two uses I've seen of this method
(RequiredSelectors>>registerLifelongInterestOf:inAll: in Core, and
AXWeakSubscription in AXAnnouncements on SqueakSource) have used this as
a poor mans replacement for ephemerons.
The problem is it does not work the way these senders expect (ie:
registering an action for each resource to be taken when the receiver is
finalized), but only executes the last action registered for an object.

Would it be an idea to change the implementation to conform to the
expectations of the senders, rather than considering the uses as bugs,
seeing as how that seems to be the common usage? (And a quite more
useful one in the absence of real ephemerons, if you ask me)

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] cull: protocol

[Henrik Johansen]

Den 19.02.2010 12:40, skrev Levente Uzonyi:
> On Fri, 19 Feb 2010, Henrik Johansen wrote:
>
>> Den 18.02.2010 21:55, skrev Stéphane Ducasse:
>>> henrik
>>>
>>> I'm trying to get the pros and cons of cull:
>>> So am'I correct that this is useful only for situation where we have
>>> a block and we do not know
>>> upfront its number of argument: = places where valueWithPossibleArgs:
>>> Now what cull: offers is that the client does not have to create the
>>> array.
>>>
>>>  I did not check your implementation.
>>>
>>> Stef
>>>
>> It's useful where you may or may not be interested in all the arguments
>> passed to a block.
>> Announcement and Exception handling are good examples. It covers the
>> same bases as valueWithPossibleArgs:, with the exception it does not
>> expand with nil args if block has more args than the corresponding
>> message sent.
>>
>> Pros:
>> - Maps well with to the value:, value:value, etc. protocol
>> - Your code looks cleaner (imo), since you don't have to put the args in
>> an array, and it's clear in a heart beat how many args you can choose to
>> use in your block.
>> - It's faster than valueWithPossibleArgs, since you don't have to put
>> your args in an array (Also you avoid a max of 2 extra array creations
>> as part of the method)
>>
>> Cons:
>> - Functionality is already provided by valueWithPossibleArgs: (That's a
>> superset though, if you need the exact functionality of cull, your code
>> will end up even hairier since you need an arg size check before calling
>> valueWithPossibleArgs:)
>> - Portability. VW and GNU ST has them, Squeak does not, not sure about
>> other implementations.
>
> Even though I'm just a lurker here, I think you should add this
> feature to Pharo. Of course I'd add the "uglier" implementation (as we
> discussed it with Henry in January), since I think it's not "uglier"
> and gives better performance (~1.3x faster for #cull:cull: if the
> block has less than 2 arguments while same performance if the block
> has 2 arguments).
>
>
> Levente
Well, ugly was a strong word.
Reusing less, aka. shorter is a better choice, I guess.

Cheers,
Henry

PS. In VisualWorks, the two perform equally. *Wishing for a Cog VM to
test on* :)
PPS. For those interested, the alternative, faster version Levente made
can be found at http://paste.lisp.org/display/93130

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

Re: [Pharo-project] cull: protocol

[Henrik Johansen]

Den 19.02.2010 14:03, skrev Levente Uzonyi:
> On Fri, 19 Feb 2010, Henrik Johansen wrote:
>
>   
>> Well, ugly was a strong word.
>> Reusing less, aka. shorter is a better choice, I guess.
>> 
> I think the difference is 3 lines for the 4 methods.
>
>   
>> Cheers,
>> Henry
>>
>> PS. In VisualWorks, the two perform equally. *Wishing for a Cog VM to
>> test on* :)
>> 
> There's no inlining VM available ATM (besides SqueakJ, but that can't 
> run current images) and noone knows when one will be. And even though I 
> didn't try it, I expect that "inlining by hand" saves time and memory.
>   
No objections here, it's definately faster.
>> PPS. For those interested, the alternative, faster version Levente made
>> can be found at http://paste.lisp.org/display/93130
>> 
> Here is a working example (the linked version has a bug):
> BlockClosure >> cull: argument1 cull: argument2
>
>   numArgs = 2 ifTrue: [ ^self value: argument1 value: argument2 ].
>   numArgs = 1 ifTrue: [ ^self value: argument1 ].
>   ^self value
>   
Ah yes, had forgotten about that.
How about:

 numArgs > 1 ifTrue: [ ^self value: argument1 value: argument2 ].
 numArgs = 1 ifTrue: [ ^self value: argument1 ].
 ^self value

That way, you get "This block accepts 3 arguments, but was called with 2 
arguments" instead of "... was called with 0 arguments" error messages if the 
block has too many args.

> (For #cull:cull:cull: the difference is ~1.7x if the block has 0 or 1 
> argument, and ~1.3x if it has 2 arguments)
>   
Then also consider the scale
"overhead of 120 ms rather than 320ms for 1 million cull:cull:cull:
sends where the block has one arg, compared to a raw value: send
(130ms)". ;)

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] cull: protocol

[Henrik Johansen]

Den 21.02.2010 23:11, skrev Bryce Kampjes:
> On Fri, 2010-02-19 at 14:03 +0100, Levente Uzonyi wrote:
>   
>> On Fri, 19 Feb 2010, Henrik Johansen wrote:
>>
>> 
>>> Well, ugly was a strong word.
>>> Reusing less, aka. shorter is a better choice, I guess.
>>>   
>> I think the difference is 3 lines for the 4 methods.
>>
>> 
>>> Cheers,
>>> Henry
>>>
>>> PS. In VisualWorks, the two perform equally. *Wishing for a Cog VM to
>>> test on* :)
>>>   
>> There's no inlining VM available ATM (besides SqueakJ, but that can't 
>> run current images) and noone knows when one will be. And even though I 
>> didn't try it, I expect that "inlining by hand" saves time and memory.
>> 
> I'm working on inlining in Exupery at the moment though progress is
> still slow. (Time I've two young boys)...
>
> Bryce
>   

Will Exupery work on the 0.15 VM now?
IIRC, when making it available, you mentioned there was primitive
collision between Exupery/Closures.

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] Why a package management system

[Henrik Johansen]

Den 23.02.2010 13:00, skrev Göran Krampe:
> Hi!
>
> Torsten Bergmann wrote:
>   
>>> So you are educating them
>>> Frankly I stopped trying long time ago.
>>>   
>> No, I just tell them what I think is necessary to move forward.
>> Other may be more educated here, it is just sharing MHO so others
>> can to form an own opinion. 
>> 
> Right, discussion is good. And believe me - the squeak-dev community is 
> NOT oblivious to the needs of a package system. I mean, come on, 
> Monticello, SqueakMap, Universes etc etc - it all was around before 
> Pharo was born.
>
> What I have seen so far in Metacello is indeed nothing new - the 
> senarios and discussions about dependencies etc go lng way back.
>
> BUT... that *doesn't* mean I am passing any judgment on Metacello - IMHO 
> all efforts are good per definition! :) I haven't formed an opinion myself.
>
>   
No system is going to perfectly fulfill everyones perception of what
would be "The Best Way"(tm), but as long as the need for functionality
provided by a system is real, actually deciding on one, IS important.
>From what I've seen in archive discussion, that seems to have been the
biggest showstopper for noticeable progress in the Squeak community.
Paradoxically, existing systems which clearly contain lousy code, are
left in (or replacements objected to) on the basis of
backwards-compatability...
IMHO, this is the biggest difference between Squeak and Pharo I've seen.
Sure, you can now unload Etoys from Squeak, your image will still
contain code like ImageSegment>>findRogueRootsAllMorphs: though.
Sure, you can new add Preferences with pragmas now, you still have a
class with a Dictionary accessed and stored into by the entire system,
and 1223 accessors for things local to specific packages though.

Metacello is nothing new for sure, but contrary to other systems, it
seems to have reached wide acceptance in Pharo.
Understandably, many here feel it'd be nice if the "classic"
Squeak-community decided to use it as well.
Personally, I doubt it will happen (for any PMS really, as evidenced by
Sake/Packages, as well as all the other previous attempts), yet I
appreciate Torsten's and others effort to at least correct the plain-out
misconceptions some people seem to have about deficiencies of Metacello.

Pretty sure noone would argue Monticello is a perfect system either,
achieving critical mass was though.

>> Meanwhile the Pharo community has grown with new members and many people 
>> dont care about old discussions. 
>>
>> Let's use our energy to move forward and (if possible) share as much
>> knowledge and code as long as parts of our communities overlap.
>> 
> Yes, exactly.
>   
+1.

> Anyway, "common exchange mechanism" - I am working on Deltastreams which 
> I even presented at Brest, though unfortunately colliding with the 
> Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY 
> this problem (fork interchange), and it was born in 2007:
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.html
>
> I and Igor are the ones working on it - and after Brest we have had very 
> little time to move it forward. I still think it is a very important 
> piece of the puzzle though.
>
> regards, Göran
I've been meaning to make system-change notifications for Pharo so the
recording-part could work there too, but I never seem to get around to it :(
Part of the problem is of course my own personal "The Best Way"(tm),
which f.ex. would include Announcements.
Since I'd like the ability to have Weak subscriptions, I'd first have to
deoptimize the Announcement-package Levente made a bit to make it
"prettier", make it a strict superset of what if found in Core already,
fix WeakRegistry so each resource registered for an object actually gets
finalized, which again means... etc... Oh, and hope it'd end up good
enough that it'd warrant inclusion:)

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] how to remove World?

[Henrik Johansen]

Den 25.02.2010 13:49, skrev Esteban Lorenzano:
> Ok, I tried passing a .st by command line:
>
> UIManager default: DummyUIManager new.
>
> Project uiProcess terminate.
>
> SmalltalkImage current snapshot: true andQuit: true.
>
> but I fail miserably :'(
> (it stops do anything after "Project uiProcess terminate"... and the 
> same using "Project uiProcess suspend")
>
> Any idea of how can I proceed from here? (I confess: I'm totally lost here)
>
> Cheers,
> Esteban
>   
As Lukas already said, that's not very strange if the script is being
executed by the uiProcess. (which it is if you're using the ProjectLauncher)

You can't plan to kill yourself, then afterwards send a goodbye-letter
to your friends, you need to get someone else to perform the actions if
you want to be sure it happens. (ie. fork off the execution)

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] Thread UI

[Henrik Johansen]

Den 25.02.2010 15:05, skrev Alexandre Bergel:
> Dear List,
>
> I am extending the current set of Mondrian tests. I would like to  
> force some system window to appear on the screen in order to properly  
> test the size of its composing morphs. However, I do not know how to  
> effectively make the morph show up on the screen in a test.
>
> For example, consider the following test with a contrived situation:
>
> testDummy
>   | morph c |
>   morph := Morph new openInWorld.
>   c := Display colorAt: 0...@0.
>   morph delete.
>   self assert: c = morph color.
>
> If I run the test from a test runner, it will fail. However, if I open  
> a debugger and do a step by step, c = morph color is true.
>
> I guess the problem is that the morph is not actually displayed, since  
> the UI thread does not have the hand. Any idea how to force this?
>
> Cheers,
> Alexandre
>
>   
You could insert World doOneCycle
between the lines
morph :=
and
c :=

>From a test-clarity (and robustness) POV though, you'd be much much
better by instead asserting properties of the morphs layout/colors than
sampling of display colors...
| morph |

morph := Morph new. 
morph doLayoutIn: someBounds.
self assert: whatIExpectedWithAboveBounds equals: morph 
someLayoutVariable


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] Worth reading discussion on Smalltalk vs SmalltalkImage

[Henrik Johansen]

Den 03.03.2010 10:36, skrev Stéphane Ducasse:
> Browser vs SystemNavigation and much more such as abstraction (traits kind of 
> mistakes) for the sake of it.
>
> I was thinking that I would love to have a message-oriented solution.
> One of these days 1.2 we will have to clean Smalltalk, SmalltalkImage current.
> The mail is long but worth to get some ideas that you may like or not.
>
> Stef
>   
I have to say I support what to me seemed like the general consensus on
this, that the separation just didn't go far enough to make it worth it :)
I especially like the
Smalltalk vm parameterAt:
Smalltalk query allCallsOn:
etc.
protocol, sure you add a globals category to SystemDictionary, but to me
the resulting code looks much better than both the current state of 
SmalltalkImage vmParameterAt: and SystemNavigation current allCallsOn:
(or were those class methods?), and the old where SystemDictionary was a
complete mess.

The important thing if this becomes the solution, is deciding what goes
where, (in a consistent fashion across forks), as well as the level of
backwards-compatibility packages should be offered/deprecation methods
kept in the image.


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] Fwd: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk

[Henrik Johansen]

I'd vote for b) too, should make it easier than a) in the future to move
towards a separation of concerns like what was discussed.

Personally, I think some of the voters might be a bit mislead by the
points "compatible with Cuis" for a), and "different from Cuis" for b,
listed in the initial post.
Option b) is still _compatible_ with Cuis, only the _implementation_ is
different. (ie code like Smalltalk vmParameterAt: xyz will work with
both proposed solutions). Unless, of course,  I'm the one
misunderstanding :)

Cheers,
Henry

Den 03.03.2010 15:02, skrev Nicolas Cellier:
> Sorry to open a new thread, but here is my own position.
>
> Cheers
>
> Nicolas
>
> -- Forwarded message --
> From: Nicolas Cellier 
> Date: 2010/3/3
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> To: The general-purpose Squeak developers list
> 
>
>
> 2010/3/3 Andreas Raab :
>   
>> On 3/2/2010 10:14 PM, Michael Haupt wrote:
>> 
>>> Hi,
>>>
>>> Am 03.03.2010 um 03:41 schrieb Andreas Raab :
>>>   
 Consequently I'm going to completely ignore any forward-looking
 proposals and simply state that the current count is 3 votes for the
 first variant (Phil, David, Bert) and 1 vote for the second variant
 (Igor).
 
>>> here's another for "Smalltalk", then.
>>>   
>> That choice doesn't exist :-) You can vote for:
>>
>> a) Smalltalk class == SystemDictionary, or
>>
>> b) Smalltalk class == SmalltalkImage
>>
>> Cheers,
>>  - Andreas
>>
>>
>> 
> I vote for b).
>
> After discussing this with Stephane Ducasse, I quite agree on this scheme:
>
> SmalltalkImage should better be renamed System.
> System soleInstance = Smalltalk.
> Of course an optional bakward compatibility module would define
> SmalltalkImage current
>
> Smalltalk globals or Smalltalk namespace class = SystemDictionary
> Maybe SystemDictionary shouldbetter be renamed Namespace to separate
> the notion of System.
>
> Then, if we are in need of separating methods, create new classes
> SmalltalkVM etc...
> But don't impose that in Kernel code, use methods indirections
> (Smalltalk vm blah...)
>
> This is a bit harder path than a), but lot cleaner IMO
>
> Nicolas
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>   

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

Re: [Pharo-project] [squeak-dev] #ensure: issues

[Henrik Johansen]

FWIW, this quote from the following discussion on Squeak-dev distills
what I was trying (but failing) to demonstrate:
"We shouldn't stop trying to support well-behaved ensure blocks properly.
Because if we don't then ensure
becomes entirely random. Or can anyone here explain why it would be
reasonable to expect that this version works:

p := [[Processor yield] ensure:[Transcript show: 'finished']] fork.
Processor yield.
p terminate.

but this one doesn't:

p := [[] ensure:[Processor yield. Transcript show: 'finished']] fork.
Processor yield.
p terminate.

(we're using yield here to denote any kind of process switch) If the
only thing that determines whether an ensure block is executed is a
process switch, then we basically have random, non-predictable unwind
handling. Which is a problem that is entirely unrelated to whether the
unwind block is itself well-behaved or not. "

In a book with chapters discussing topics such as ensure and processes,
(based on Pharo 1.0 which is unlikely to contain any fixes for such an
issue), it deserves at least a mention.

Cheers,
Henry

Den 03.03.2010 15:33, skrev Levente Uzonyi:
> On Wed, 3 Mar 2010, Stéphane Ducasse wrote:
>
>>
>> On Mar 2, 2010, at 10:33 PM, Levente Uzonyi wrote:
>>
>>> On Tue, 2 Mar 2010, Henrik Sperre Johansen wrote:
>>>

>> PS. For the not-so-faint-of-heart, open a Transcript and try
>> evaluating:
>> |proc|
>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show:
>> 'Finish!' Processor yield.]] newProcess.
>> proc resume.
>> Processor yield.
>> proc suspend.
>> proc terminate.
> Why don't we get it printing?
 Forgot a . there, supposed to be

 |proc|
 proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show:
 'Finish!'. Processor yield.]] newProcess.
 proc resume.
 Processor yield.
 proc suspend.
 proc terminate.

 on my machine it prints:
 *Start!Start!Finish!
>>>
>>> The problem occurs because Transcript >> #endEntry (sent from #show:)
>>> takes a while to execute, so the process (proc) prints 'Start!', but
>>> it gets terminated before execution reaches #resetContents (#reset in
>>> Squeak). So 'Start!' is still in the stream. Then our process
>>> executes the
>>> #ensure: block and it prints 'Start!' and 'Finish!' too.
>>
>>
>> Thanks for the explanation levente!
>> But I'm still dizzy :) why Transcript show: 'Finish' would also print
>> 'start' ?
>
> Transcript is just a stream. #show: is just a combination of
> #nextPutAll: and #endEntry. #endEntry displays the contents of the
> stream and when that's done it removes everything from the stream with
> #resetContents. #resetContents is never executed, because the process
> is terminated before that. So the contents of the stream are kept and
> displayed again later.
>
>
> Levente
>
>>
>>>
>>> There's worse problem with #ensure: and #terminate is that, a
>>> process executing an #ensure: block can be terminated. If you
>>> evaluate this code:
>>>
>>> | process stage1 stage2 stage3 counter |
>>> stage1 := stage2 := stage3 := false.
>>> counter := 0.
>>> process := [
>>> [ stage1 := true ] ensure: [
>>> stage2 := true.
>>> 100 timesRepeat: [ counter := counter + 1 ].
>>> stage3 := true ] ] newProcess.
>>> process resume.
>>> Processor yield.
>>> process suspend.
>>> process terminate.
>>> 1000 milliSeconds asDelay wait.
>>> { stage1. stage2. stage3. counter } explore
>>>
>>> you will find that stage1 and stage2 is reached as expected, but
>>> stage3 is not and counter is less than 100. That's because the
>>> forked process started evaluating the #ensure: block, but it was
>>> terminated by our process.
>>>
>>> Is this the expected behavior when sending #terminate to a process
>>> which is evaluating an #ensure: block?
>>>
>>>
>>> Cheers,
>>> Balázs & Levente
>>>
>>>

 *yay
 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

Re: [Pharo-project] [squeak-dev] #ensure: issues

[Henrik Johansen]

Den 04.03.2010 13:19, skrev Stéphane Ducasse:
> btw henrik
>
> does VW have the same behavior?
>
> Stef
>   
Short answer is no, Eliot described the details:
http://n4.nabble.com/ensure-issues-was-Re-Pharo-project-Pharo-by-Example-vol-2-new-chapter-available-tp1575765p1577519.html

Cheers,
Henry

> On Mar 4, 2010, at 11:38 AM, Henrik Johansen wrote:
>
>   
>> FWIW, this quote from the following discussion on Squeak-dev distills what I 
>> was trying (but failing) to demonstrate:
>> "We shouldn't stop trying to support well-behaved ensure blocks properly. 
>> Because if we don't then ensure 
>> becomes entirely random. Or can anyone here explain why it would be 
>> reasonable to expect that this version works: 
>>
>> p := [[Processor yield] ensure:[Transcript show: 'finished']] fork. 
>> Processor yield. 
>> p terminate. 
>>
>> but this one doesn't: 
>>
>> p := [[] ensure:[Processor yield. Transcript show: 'finished']] fork. 
>> Processor yield. 
>> p terminate. 
>>
>> (we're using yield here to denote any kind of process switch) If the 
>> only thing that determines whether an ensure block is executed is a 
>> process switch, then we basically have random, non-predictable unwind 
>> handling. Which is a problem that is entirely unrelated to whether the 
>> unwind block is itself well-behaved or not. "
>>
>> In a book with chapters discussing topics such as ensure and processes, 
>> (based on Pharo 1.0 which is unlikely to contain any fixes for such an 
>> issue), it deserves at least a mention.
>>
>> Cheers,
>> Henry
>>
>> Den 03.03.2010 15:33, skrev Levente Uzonyi:
>> 
>>> On Wed, 3 Mar 2010, Stéphane Ducasse wrote: 
>>>
>>>   
>>>> On Mar 2, 2010, at 10:33 PM, Levente Uzonyi wrote: 
>>>>
>>>> 
>>>>> On Tue, 2 Mar 2010, Henrik Sperre Johansen wrote: 
>>>>>
>>>>>   
>>>>>> 
>>>>>>>> PS. For the not-so-faint-of-heart, open a Transcript and try 
>>>>>>>> evaluating: 
>>>>>>>> |proc| 
>>>>>>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: 
>>>>>>>> 'Finish!' Processor yield.]] newProcess. 
>>>>>>>> proc resume. 
>>>>>>>> Processor yield. 
>>>>>>>> proc suspend. 
>>>>>>>> proc terminate. 
>>>>>>>> 
>>>>>>> Why don't we get it printing? 
>>>>>>>   
>>>>>> Forgot a . there, supposed to be 
>>>>>>
>>>>>> |proc| 
>>>>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: 
>>>>>> 'Finish!'. Processor yield.]] newProcess. 
>>>>>> proc resume. 
>>>>>> Processor yield. 
>>>>>> proc suspend. 
>>>>>> proc terminate. 
>>>>>>
>>>>>> on my machine it prints: 
>>>>>> *Start!Start!Finish! 
>>>>>> 
>>>>> The problem occurs because Transcript >> #endEntry (sent from #show:) 
>>>>> takes a while to execute, so the process (proc) prints 'Start!', but 
>>>>> it gets terminated before execution reaches #resetContents (#reset in 
>>>>> Squeak). So 'Start!' is still in the stream. Then our process executes 
>>>>> the 
>>>>> #ensure: block and it prints 'Start!' and 'Finish!' too. 
>>>>>   
>>>>
>>>> Thanks for the explanation levente! 
>>>> But I'm still dizzy :) why Transcript show: 'Finish' would also print 
>>>> 'start' ? 
>>>> 
>>> Transcript is just a stream. #show: is just a combination of #nextPutAll: 
>>> and #endEntry. #endEntry displays the contents of the stream and when 
>>> that's done it removes everything from the stream with #resetContents. 
>>> #resetContents is never executed, because the process is terminated before 
>>> that. So the contents of the stream are kept and displayed again later. 
>>>
>>>
>>> Levente 
>>>
>>>   
>>>> 
>>>>> There's worse problem with #ensure: and #termi

Re: [Pharo-project] String>>beginsWith: with empty strings issue

[Henrik Johansen]

Den 04.03.2010 14:40, skrev Julian Fitzell:
> I'm not sure, but in ANSI, indexOfSubcollection:startingAt: is defined
> as returning 0 (no match) for an empty collection.
>   
If a string can not contain the empty string, then how can (and does) it
start/end with it?
IMHO, to be consistent, the set of what I contain should be a strict
superset of what I begin/end with.

In that regards, according to the ansi-standard, returning false is correct.

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] String>>beginsWith: with empty strings issue

[Henrik Johansen]

Den 04.03.2010 16:03, skrev Gabriel Cotelli:
/*Message:  indexOfSubCollection: targetSequence startingAt: start */
> /**Start searching at index start in the receiver. Answer 0 if no such
> subsequence is found.
> /
*snip*
> / Answer 0 if no such
> subsequence is found in the receiver, or if targetSequence is empty.
> /

I don't see how that is ambigous regarding whether an empty collection
is defined as a subsequence or not.

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] Having fun with booleans

[Henrik Johansen]

Den 05.03.2010 10:08, skrev Peter Hugosson-Miller:
> On 5 mar 2010, at 09.33, Fernando olivero  wrote:
>
>   
>> The problem is the side effects, is suddenly Boolean>>and: stops to  
>> be lazy.
>> Possibly evaluating blocks that shouldn't be evaluated.
>> 
> No, but there is one subtle difference anyway: both #and: and #or:  
> will return a Boolean (the receiver) if the block argument isn't  
> executed, whereas #ifTrue: and #ifFalse: will return nil in that case.  
> So if you do something with the return value, then the bytecode will  
> be different for sure.
>
> But it's academic anyway: the use of #and: and #or: gives the reader a  
> very strong hint that the argument block (if executed) is supposed to  
> return a Boolean, so to use it purely for branching in the code could  
> be seen as misleading.
>
> --
> Cheers,
> Peter
>   
I like that argument turned on its head, namely that ifTrue: ifFalse:
gives the reader a very strong hint that the argument blocks are used
purely for branching, thus using them to (eventually) return a boolean
can be seen as misleading :)

i.e. I tend to prefer to use Igors and: example for code I often see written

a < b ifTrue: [... a couple of actions, then returning true or false ...]
ifFalse: [^false]

Cheers,
Henry
>   
>> Fernando
>>
>> On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote:
>>
>> 
>>> Hello,
>>> I just realized, that one can completely avoid using ifTrue/ifFalse
>>> branches, but use #or: and #and: instead.
>>>
>>> a > b ifTrue: [ ... ]
>>> could be written as:
>>> a > b and: [ ... ]
>>>
>>> a > b ifFalse: [ ... ]
>>> could be written as:
>>> a > b or: [ ... ]
>>>
>>> and
>>> a > b ifTrue: [ self foo ] ifFalse: [ self bar ]
>>> could be written as:
>>>
>>> a > b and: [ self foo]; or:[ self bar ]
>>>
>>> :)
>>>
>>> -- 
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>   
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
> ___
> Pharo-project 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] Alien on Win32 - Test and Integration into VM Sources

[Henrik Johansen]

Den 09.03.2010 12:54, skrev Schwab,Wilhelm K:
> How do I get my hands on the Linux plugin?
>
>   
Javier documented the journey to a buildable plugin quite extensively on
the list. So either read and learn from his missteps in the thread
"Trying to build alien plugin in linux", or ask him for a location where
VM + plugin is available.

On another note, the Alien package on SqueakSource could use some cleanup.
Alot of the methods in Alien-Core has since been included in both Pharo
and Squeak Trunk as part of Eliots changes, so should be split of to a
separate package loadable if needed (in older images, I assume).

The notion of an AlienLibrary is also a new addition and at least the
win32 examples are no longer in sync, since Alien lookup:inLibrary: can
no longer be used to get a function pointer in any given library.

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] CrLfFileStream class>>new?!

[Henrik Johansen]

Den 09.03.2010 14:38, skrev Adrian Lienhard:
> I was just puzzled why "CrLfFileStream defaultToLF" does not work until I 
> figured that CrLfFileStream new returns an instance of a different class:
>
> CrLfFileStream class>>new
>   ^ (MultiByteFileStream new) wantsLineEndConversion: true; yourself.
>
>
> Does somebody know what the point is? I really sometimes wonder why good 
> coders write such code, and not even care to add a comment...
>
> Cheers,
> Adrian
> ___
> http://www.adrian-lienhard.ch/
>   
CrLfFileStream does not handle any encodings other than latin1.

My guess is:
-  MultiByteFileStream probably didn't exist when it was created.
- Using a MultiByteFileStream with no encoding, but a lineEndConvention
is now the preferred method, but CrLfFileStream was kept for
backwards-compatability.

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] Paint gradients rectangles on #onDraw: method

[Henrik Johansen]

Den 10.03.2010 16:36, skrev nullPointer:
> Well, I´m continue working on a Grid widget.
>
> My old grid was very slow in load data. I changed the old mechanism of
> columns and rows ( each row was a panel with cells in tableLayout  ) by
> #onDraw: mechanism, painting the cells and contents of it. Now is incredible
> much more faster. I believe than another people with more knowledge could do
> more fast too.
>
> Now my next problem is implement the "styles" of widget. I need paint
> gradient rectangles, for color of rows , alternate rows, cells etc. Is
> possible do that with #onDraw: mechanism? exists some previous example?
>
> Many thanks for the answer; regards. 
>   

Not exactly sure what you mean by having switched the mechanism, but
have you tried using a GradientFillStyle as fill when drawing on canvas?

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] Class comments are in the .sources ?

[Henrik Johansen]

Den 11.03.2010 11:05, skrev Mariano Martinez Peck:
>
>
> On Thu, Mar 11, 2010 at 10:47 AM, Igor Stasenko  > wrote:
>
> 2010/3/11 Mariano Martinez Peck  >:
>
>
>  
>
> I presented some ideas about it in the past, but since it requires a
> substantial efforts to make it done,
> they weren't get past much the state of an ideas. :)
>
>
> I would like to hear those ideas.
http://n4.nabble.com/Source-code-management-my-vision-Was-Re-Why-a-package-management-system-td1566103.html#a1566103

Some grand ideas indeed :)

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] Collection >> collectDistinct: ??

[Henrik Johansen]

Den 11.03.2010 01:54, skrev Nicolas Cellier:
> 2010/3/11 Igor Stasenko :
>   
>> On 10 March 2010 15:07, Nicolas Cellier
>>  wrote:
>> 
>>> self collect: aBlock as: Set
>>>
>>>   
>> One more time, i found this very beatiful and useful extension to
>> Collection protocol.
>> And i am proud being a witness when this thing is born! :)
>>
>> 
> Yes,
> I remember saying I was not convinced some times ago...
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129457.html
> Being able to change own opinion is a good thing !
>
> Nicolas
>   
I have to admit, I still don't quite see what's wrong with
1.
(self collect: aBlock) asSet
or
2.
mySet := Set new: self size.
self do: aBlockAddingToMySetAtEnd.

or (well, this one is IMO indeed a bit ugly)
3.
self inject: (Set new:self size) into:
[ :sub :next |
 sub add: next collectValue; yourself ] ...

Sure, they're a bit verbose, and when you'd like to use 1 vs 2 or 3
varies abit on the collection contents, but they all work in all
dialects, and aren't THAT much longer, unless your collect block is
really short.

Cheers,
Henry
>   
>>> 2010/3/10 Mariano Martinez Peck :
>>>   
 Hi. I was needing something like the SQL select distinct, that doesn't take
 into account repeated objects. I didn't found anything useful in 
 Collection,
 and thus, I have implemented this:

 Collection >> collectDistinct: aBlock


 collectDistinct: aBlock
 "Evaluate aBlock with each of the receiver's elements as the argument.
 Collect the resulting values into a Set, thus repeated objects will not
 be present.
 Answer the new collection."

 | newSet |
 newSet := self species new asSet.
 self do: [:each | newSet add: (aBlock value: each)].
 ^ newSet


 Is there a better way ?   Do you think it make sense to put this in Pharo ?

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

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

Re: [Pharo-project] URGENT!! Please help for GSoC

[Henrik Johansen]

I would recon they mean the percentage of students who actually finished
the projects they were allocated to in previous years, not the
percentage of projects proposals which were accepted.

Cheers,
Henry

Den 12.03.2010 15:34, skrev Mariano Martinez Peck:
> There was a new question in the submission  to  GSoC which says:
>
> "If your organization participated in past GSoCs, please let us know
> the ratio of students passing to students allocated, e.g. 2006: 3/6
> for 3 out of 6 students passed in 2006."
>
> Does someone understand this ? is this acceptance projects (google
> slots) over the total proposed projects ?
>
> If true, I know in 2008 were selected 5 projects over 18, but I have
> no idea about 2007.
>
> Please, we are almost in deadline :(
>
> Thanks
>
> 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] Code Freeze 1.1?

[Henrik Johansen]

Trying to load Magma after the announcement yesterday, I ran into issues with 4 
causes:

- Flaps removal
- MethodProperties removal
- Underscore assignement
- Network :P

Obviously, the tests were hard to run without a network, some of the Collection 
tests seemed to run excessively long as well (in that I alt-. before they 
finished).

There's also the Preferences deprecation, which is bound to cause some work.

Cheers,
Henry

On Mar 16, 2010, at 2:10 39PM, Alexandre Bergel wrote:

> Moose, including Mondrian and Spy load well in Pharo 1.1. No big effort were 
> needed for this.
> I haven't seen that many problems in porting applications to 1.1.
> 
> The only thing I bumped into so far, are initialExtent (but apparently this 
> was fixed) and tool registration.
> 
> Alexandre
> 
> 
> On 16 Mar 2010, at 07:50, Stéphane Ducasse wrote:
> 
>> + 1
>> end of march for a code freeze would be great.
>> Stef
>> 
>> 
>> On Mar 16, 2010, at 10:19 AM, Marcus Denker wrote:
>> 
>>> Hi,
>>> 
>>> Now with 1.0 done, I think we should think about freezing 1.1.
>>> 
>>> The main reason of course is that 1.1 is *far more pleasent* to use than 
>>> 1.0. The other
>>> thing is that 1.1 did change quite some things that have impact on external 
>>> code (Preferences,
>>> as an example).
>>> 
>>> So I think we should
>>> 
>>> -> start slowing down on 1.1 (Stef suggested that already)
>>> -> start polishing   (tests...)
>>> -> start to look at the Dev image.
>>> -> Official code freeze end of March.
>>> -> Release if possible end of April (this of course depends on the 
>>> state of things).
>>> 
>>> 
>>> Any reasons against?
>>> 
>>> 
>>> Marcus
>>> 
>>> 
>>> --
>>> 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 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 mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Code Freeze 1.1?

[Henrik Johansen]

On Mar 16, 2010, at 4:01 51PM, Stéphane Ducasse wrote:

> for code 1.1 I would like to be able to remove Preferences.
> 
> Stef

Personally, I think it's rather important to have a stable release where both 
are in, but where the Preferences adding raises deprecations, and the browser 
removed.
Then, in the future, when someone tries to port an old project with 
Preferences, we can say "Load it into a 1.1 image and fix it there".
Without the availability of such a middle step, it'd be somewhat of a leap 
getting the code up to date. (unless you do it offline, but that's not really 
the smalltalk way, is it?)

Cheers,
Henry

> On Mar 16, 2010, at 10:19 AM, Marcus Denker wrote:
> 
>> Hi,
>> 
>> Now with 1.0 done, I think we should think about freezing 1.1. 
>> 
>> The main reason of course is that 1.1 is *far more pleasent* to use than 
>> 1.0. The other
>> thing is that 1.1 did change quite some things that have impact on external 
>> code (Preferences, 
>> as an example).
>> 
>> So I think we should
>>  
>>  -> start slowing down on 1.1 (Stef suggested that already)
>>  -> start polishing   (tests...)
>>  -> start to look at the Dev image.
>>  -> Official code freeze end of March.
>>  -> Release if possible end of April (this of course depends on the 
>> state of things).
>> 
>> 
>> Any reasons against?
>> 
>> 
>>  Marcus
>> 
>> 
>> --
>> 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 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] Code Freeze 1.1?

[Henrik Johansen]

On Mar 16, 2010, at 4:59 27PM, Stéphane Ducasse wrote:

> 
> On Mar 16, 2010, at 4:52 PM, Henrik Johansen wrote:
> 
>> 
>> On Mar 16, 2010, at 4:01 51PM, Stéphane Ducasse wrote:
>> 
>>> for code 1.1 I would like to be able to remove Preferences.
>>> 
>>> Stef
>> 
>> Personally, I think it's rather important to have a stable release where 
>> both are in, but where the Preferences adding raises deprecations, and the 
>> browser removed.
> 
> Sure this is why I did not say removed :)
> But nobody in the image should refer to it.

Ah, to me it read like you wanted to remove it completely :)

I thought Alain already recreated all uses in the core image as settings?



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

Re: [Pharo-project] packages :)

[Henrik Johansen]

On Mar 17, 2010, at 11:23 15AM, Igor Stasenko wrote:

>> How does the package know when a class is deleted from within a
>> #doSilently: block?
>> 
> this is irrelevant. Because if you build a system from a first
> principles, where a package is one of
> the key concepts in it, instead of a hollow abstraction, sure thing
> you taking care about all of it in proper manner.
> 
 RPackage is about a PackageInfo replacement, not about a namespace
 implementation. Arguably namespacing is something entirely different.
 
>>> As i said, it doesn't implements a new model, but a different view on
>>> existing one.
>> 
>> RPackage does not implement a different view: PackageInfo is implicit,
>> it takes all information from elsewhere (category and protocol names).
> 
> 'Elsewhere' is a key word here, which means that PackageInfo  is a
> view, and nothing more.

Yes, you are talking about two entirely different kinds of Package.

RPackage is, like PackageInfo, just a view of the underlying system, but 
maintaining a cache of the essential data instead of recomputing at every 
message send.

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] [ANN] Gofer Project Loader 1.0 (BETA)

[Henrik Johansen]

On Mar 17, 2010, at 4:54 16PM, Alexandre Bergel wrote:

>> Hi Alexandre,
>> 
>> load:
>> 
>> ...already loads latest stable version, but if the project hasn't any 
>> declared stable version, it will throw a "no stable version found" error, 
>> and you'll need to look for a version (using #availableVersionsOf:)
>> of course, this can be improved... I will think on a way to do it.
> 
> Excellent!
> When you load something, it would be nice to provide some feedback on which 
> version is loaded, and which one is available.
> I am picky, I know :-)

Belongs in complimentary UI / Logging packages, imo. 
As long as the ProjectLoader raises appropriate announcements (cough cough), it 
shouldn't be hard to separate (optional) feedback from the actual loading 
actions.
> 
>> upgrade
>> 
>> loads new versions of an already present project (if there are newer 
>> versions on a configuration).
> 
> But is there a situation where I would prefer an upgrade instead of a load?

It doesn't reinstall if the latest version is already loaded?
Also, if mcd's between two versions were available, it could potentially 
install much faster :)

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] A challenge for us

[Henrik Johansen]

On Mar 18, 2010, at 11:15 18AM, Mariano Martinez Peck wrote:

> 
> PS. The latest 1.0 release is PharoCore-1.0-10515rc3 (available from the 
> gforge page), to get the equivalent of a Pharo (pharo-dev) rc image, load the 
> ConfigurationOfPharo into that, and evaluate (ConfigurationOfPharo version: 
> '1.0-rc.3-baseline') load.
> 
> PPS. There will be an error when doing the load, since the AST-Tests package 
> in squeaksource/rb has been renamed AST-Tests-Core, and the same for 
> Refactoring-Tests, and the old packages removed... 
> Lukas, would you mind uploading them again? 
> For now, you can debug, and in the method that breaks, change the 
> packageSpec's file to 'AST-Tests-Core-lr.8' and Refactoring-Tests-Core-lr.34 
> respectively.
> This will happen twice, since the spec first loads 
> ConfigurationOfRefactoringBrowser once as part of the defined packages, then 
> again as a prereq when loading ConfigurationOfOmniBrowser.
> 
> 
> It was fixed already some time ago. I have also updated all project to 
> latests versions. I actually build a PharoDev image based on Pharo 1.0 RC3 
> and latests pharo dev tools and all seemed to work perfect. 
> 
> I will try to release such image by the end of the week/weekend.
> 
> Cheers
> 
> Mariano

I guess the correct incantation was (ConfigurationOfPharo project version: 
'1.0-rc3.10515') load. :)

We really should set up a backup repository with all the packages included in 
specs though.
Older versions have already stopped working twice now due to package deletions, 
first FFI, and then RB.

F.ex, doing (ConfigurationOfPharo project version: '1.0-rc2.10508') load in a 
10508rc2 Core image will now fail.

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] Here's my problems...

[Henrik Johansen]

On Mar 19, 2010, at 10:07 20AM, Igor Stasenko wrote:

> I tried different VM
> http://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip
> 
> no changes...
> 
> 
> Any ideas why interrupt key makes image unresponsive?
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.

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

Update your image.

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] for 1.0 did we put the welcome message

[Henrik Johansen]

On Mar 19, 2010, at 9:37 40AM, Mariano Martinez Peck wrote:

> Not yet. We should merge the current welcome workspace with the actions done 
> in 1.0.
> 
> Any ideas how to do that ?

There was someone asking a question which was answered in the lower half of the 
welcome workspace on IRC yesterday,
so from a usability viewpoint, it might be better to just put them in a 
separate workspace. ;)

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] Here's my problems...

[Henrik Johansen]

On Mar 19, 2010, at 12:42 24PM, Igor Stasenko wrote:

> my mistake, that i'm using old image...
> 
> its a bit confusing that pharo-dev images downloads listed first
> and they are pretty outdated.
> 
> I just loaded PhaoCore1.1.-11268
> will try there.
> At least , pressing Alt-. no longer hangs an image
> -- 
> Best regards,
> Igor Stasenko AKA sig.

Agreed, 1.1Core downloads are way down there :(

As for why the interrupt makes image unresponsive, iirc, there was something in 
the debugger which needed reinitialization after the new WeakSet was imported. 
Can't remember what off the tip of my head though...

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] [update 1.1] #11293 Polymorph Enhancements

[Henrik Johansen]

On Mar 24, 2010, at 12:54 14PM, Gary Chambers wrote:

> A slightly trickier merge this time...
> 
> Best to keep current for the FuzzyLabelMorph change (somehow that has 
> reverted) to fix the ugly buttons.

Or if you liked it better, you can revert to the original version of 
FuzzyLabelMorph>>drawOn:, and set fuzzColor to Color transparent alpha: 0.001 
instead of Color transparent.

There seems to be a bug in the primitive when alpha is exactly 0, which is what 
causes the weird look, but a color just a tiny fraction off, works.

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] Problem with TransformationMorph

[Henrik Johansen]

It's not fixed in Squeak.
WarpBlt does not work with alpha 0 > < 1.
Another example is rotating a systemwindow (from the halo menu), its dropshadow 
will be pure black. (i.e. all non-transparent pixels are rendered with their 
pure RGB component)

Cheers,
Henry

(TransformationMorph is removed in Cuis 2.3, rotate halo button is there, but 
not working)

On Mar 26, 2010, at 9:31 39AM, Stéphane Ducasse wrote:

> lukas 
> 
> did you check in the latest version of squeak because I saw some fixes about 
> put Morph in TextMorph?
> Also in Cuis 2.0 because I imagine that juan got the same transformation. Now 
> it seems that he changed that.
> 
> Stef
> On Mar 26, 2010, at 8:58 AM, Lukas Renggli wrote:
> 
>> I noticed a problem with transformation morphs and created a bug report:
>> 
>>  http://code.google.com/p/pharo/issues/detail?id=2207
>> 
>> The problem seems to be that the transformation morph creates a black
>> rectangle on the rotated clipping bounds. I does not only happen with
>> TextMorphs but also with (some) other morphs. I tried to convert the
>> TextMorph to a SketchMorph and the same happens there. I have no idea
>> how to fix that problem. I need a solution because eCompletion rotates
>> some text by 90, which is currently not possible.
>> 
>> | stringMorph transformationMorph |
>> stringMorph := 'vertical text' asMorph.
>> transformationMorph := TransformationMorph new asFlexOf: stringMorph.
>> transformationMorph angle: Float pi / 2.
>> transformationMorph position: 5...@5.
>> transformationMorph openInWorld.
>> 
>> Lukas
>> 
>> --
>> Lukas Renggli
>> http://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

Re: [Pharo-project] Problem with TransformationMorph

[Henrik Johansen]

Hmmm, are you running on the latest VM's?
With Pharo 1.1 and squeak 4.1, on both OSX and Windows I do not get black 
rectangles, but "expanded" black areas like attached.

Cheers,
Henry
<>
On Mar 26, 2010, at 10:41 42AM, Lukas Renggli wrote:

>> It's not fixed in Squeak.
>> WarpBlt does not work with alpha 0 > < 1.
>> Another example is rotating a systemwindow (from the halo menu), its 
>> dropshadow will be pure black. (i.e. all non-transparent pixels are rendered 
>> with their pure RGB component)
> 
> Ok, but what does this mean exactly?
> 
> Previously it was possible to have rotated text. When rotating text it
> now shows the complete bounding box in black, not just the aliased
> borders.
> 
> Lukas
> 
>> 
>> Cheers,
>> Henry
>> 
>> (TransformationMorph is removed in Cuis 2.3, rotate halo button is there, 
>> but not working)
>> 
>> On Mar 26, 2010, at 9:31 39AM, Stéphane Ducasse wrote:
>> 
>>> lukas
>>> 
>>> did you check in the latest version of squeak because I saw some fixes 
>>> about put Morph in TextMorph?
>>> Also in Cuis 2.0 because I imagine that juan got the same transformation. 
>>> Now it seems that he changed that.
>>> 
>>> Stef
>>> On Mar 26, 2010, at 8:58 AM, Lukas Renggli wrote:
>>> 
 I noticed a problem with transformation morphs and created a bug report:
 
  http://code.google.com/p/pharo/issues/detail?id=2207
 
 The problem seems to be that the transformation morph creates a black
 rectangle on the rotated clipping bounds. I does not only happen with
 TextMorphs but also with (some) other morphs. I tried to convert the
 TextMorph to a SketchMorph and the same happens there. I have no idea
 how to fix that problem. I need a solution because eCompletion rotates
 some text by 90, which is currently not possible.
 
 | stringMorph transformationMorph |
 stringMorph := 'vertical text' asMorph.
 transformationMorph := TransformationMorph new asFlexOf: stringMorph.
 transformationMorph angle: Float pi / 2.
 transformationMorph position: 5...@5.
 transformationMorph openInWorld.
 
 Lukas
 
 --
 Lukas Renggli
 http://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
>> 
> 
> 
> 
> -- 
> Lukas Renggli
> http://www.lukas-renggli.ch
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 

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

Re: [Pharo-project] [update 1.1] #11296

[Henrik Johansen]

On Mar 26, 2010, at 10:27 34AM, Alain Plantec wrote:

> Stéphane Ducasse a écrit :
>> 11296
>> -
>> 
>> Issue 2208:  Preferences setting
>>  * range setting: bad widget height in the SettingBrowser
>>  * improve TimeProfiler (MorphTreeMorph example)
> Few words about that:
> TimeProfiler is a improvement of the current TimeProfileBrowser.
> just try it:
> TimeProfiler new openOnBlock: [ 10 timesRepeat: [Transcript show: 'n' 
> asString, String cr]].
> or simply
> TimeProfiler new open
> and then type-in the code you want to profile.
> 
> For now, it is in the Morphic-MorphTreeWidget-Examples sys cat,
> maybe it can replace TimeProfileBrowser in the core.
> what do you think ?
> 
> Cheers
> Alain


Absolutely <3 it!
How about a Start profiling (Stop profiling when clicked) button as well, 
providing functionality equal to the Start profiling... options from the debug 
menu?

I'd replace it in a heartbeat already tbh, with that extra button, we could 
reduce it to a single entry for profiling in the debug menu :)

Cheers,
Henry

PS. Anyone know a better naming for "Start drawing again" ? 
I always wondered how you are supposed to access that if you've stopped 
drawing, afaik it resets the drawError property of the World (aka. 
PasteUpMorph) so it starts drawing normally again instead of something crossed 
out red. 
It is not done for submorphs, so it's not a convenient way of resetting all 
drawstates, do we really get drawErrors often enough in the PasteUpMorph itself 
to warrant this item??


___
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 TransformationMorph

[Henrik Johansen]

On Mar 26, 2010, at 11:11 47AM, Lukas Renggli wrote:

> Ahh, with Squeak4.2.3beta1 I get the same as you.
> 
> Not perfect, but already better. Any idea how the ugly expanded areas
> can be fixed?
> 
> Lukas

If the text background color is consistent, it should be fakeble in image. 
Otherwise I'd reckon it requires more BitBlt fixes.

Look at the text in a rotated browser first, that's the result you can expect.
Basic way would be to instead of rendering the text glyphs rotated, render the 
glyphs on top of a bitmap of the proper rotated background, then rotate that 
opaque bitmap instead.
Not a perfect solution by any means, but it can be done if you're desperate 
enough... waiting for VM fixes can take a long time :(

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] Problem with TransformationMorph

[Henrik Johansen]

On Mar 26, 2010, at 11:37 27AM, Lukas Renggli wrote:

>> If the text background color is consistent, it should be fakeble in image.
>> Otherwise I'd reckon it requires more BitBlt fixes.
> 
> Ok, converting the string morph to a bitmap works indeed. The text is
> readable. However the transparency does not work.
> 
> I hope the VM gets fixed :-)
> 
>> Look at the text in a rotated browser first, that's the result you can 
>> expect.
>> Basic way would be to instead of rendering the text glyphs rotated, render 
>> the glyphs on top of a bitmap of the proper rotated background, then rotate 
>> that opaque bitmap instead.
>> Not a perfect solution by any means, but it can be done if you're desperate 
>> enough... waiting for VM fixes can take a long time :(
> 
> Are there any examples for that?
> 
> Lukas

CornerRounder works this way.
These are the basic steps (performed in method roundCornersOf: on: in: 
displayBlock: borderWidth:  corners: )
1. copy bits below to a bitmap.
2. render normal corner to bitmap 2.
3. mask out the rounded bits in bitmap 2.
4. render bitmap2 on top of bitmap1.
5. display the composite on screen.

You'd probably skip 2 and 3 for text, replace 4 with "render text", and add:
2. rotate bits -X degrees
4.5 rotate bits X degrees.

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] [update 1.1] #11296

[Henrik Johansen]

On Mar 26, 2010, at 1:19 53PM, Stéphane Ducasse wrote:

>> Absolutely <3 it!
> 
> DNU???

<3 = Heart
As in, "I <3 Huckabees" 

> 
> 
>> How about a Start profiling (Stop profiling when clicked) button as well, 
>> providing functionality equal to the Start profiling... options from the 
>> debug menu?
>> 
>> I'd replace it in a heartbeat already tbh, with that extra button, we could 
>> reduce it to a single entry for profiling in the debug menu :)
> 
> :)
> We will have to think in terms of architecture and dependencies but it will 
> be present.
A few thoughts:
- MessageTally is the model. Ditch opening CodeHolders and crap as a result of 
calling spyAllOn: and friends, return the raw instance after collection.
- TimeProfile(r)(Browser) is the view. Convenience methods for opening 
browsers. Ditch constructing with report:cutoff; use the tally directly as 
model.
- Define the menu item in TimeProfiler class.

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] A little quizzzzzzz : find the problem :)

[Henrik Johansen]

And here I was, thinking you were talking of copy-pasted code instead  
of reuse ;P


Btw, there's no way that test should be true unless you have a messed  
up changes file caused by a botched truncate or something...


Cheers,
Henry

Den 28. mars 2010 kl. 21.20 skrev Stéphane Ducasse r>:



http://code.google.com/p/pharo/issues/detail?id=2228
of course!
Stef

On Mar 28, 2010, at 9:18 PM, Stéphane Ducasse wrote:


fileStream
   "Answer the file stream with position set at the beginning of my  
string.

   Answer a read only copy to avoid syntax errors when accessed via
   multiple processes."

   | theFile |
   (sourceFileNumber == nil or: [(SourceFiles at: sourceFileNumber)  
== nil]) ifTrue: [^ nil].

   theFile := (SourceFiles at: sourceFileNumber) readOnlyCopy.
   theFile position: filePositionHi.
   ^ theFile

string
   "Answer the receiver's string if remote files are enabled.
   Use a read only copy to avoid syntax errors when accessed via
   multiple processes."

   | theFile |
   (sourceFileNumber == nil or: [(SourceFiles at: sourceFileNumber)  
== nil]) ifTrue: [^''].

   theFile := (SourceFiles at: sourceFileNumber) readOnlyCopy.
   ^[theFile position: filePositionHi.
   theFile nextChunk] ensure: [theFile close]


text
   "Answer the receiver's string asText if remote files are enabled.
   Use a read only copy to avoid syntax errors when accessed via
   multiple processes."

   | theFile |
   (sourceFileNumber == nil or: [(SourceFiles at: sourceFileNumber)  
== nil]) ifTrue: [^ nil].

   theFile := (SourceFiles at: sourceFileNumber) readOnlyCopy.
   ^[theFile position: filePositionHi.
   theFile position > theFile size ifTrue: [
   self error: 'RemoteString past end of file' ].
   theFile nextChunkText] ensure: [theFile close]

I imagine a good soul could fix that and nicely published in the  
inbox :)


Stef Did I say something negative about the past :)
___
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] The Windows VM

[Henrik Johansen]

Ehm, that was a change to allow old image segments to load correctly,  
squeakmap just happened to be the broken usecase.


Cheers,
Henry

Den 29. mars 2010 kl. 00.44 skrev Mariano Martinez Peck >:


The new version 4.1 doesn't seem to be improvements in speed and  
from what I read about Andreas comment, it only fixes problems for  
SqueakMap, which was removed in Pharo, and a change in the close  
event of the windows.


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

Re: [Pharo-project] squeakToUTF-8 and related?

[Henrik Johansen]

On Mar 28, 2010, at 4:36 13PM, Stéphane Ducasse wrote:

> Hi 
> 
> I'm trying to remember the situation with the internal representation of 
> string in pharo/squeak
> to revise 
> http://book.seaside.st/book/in-action/serving-files/character-encodings/seaside-pharo
> 
> I saw that in pharo we have this NonASCIIMap. I do not remember what have 
> been done in pharo. 
> Argh memory leaks Nicolas do you remember the situation?
NonASCIIMap is used for quickly determining whether the string with no 
character codes > 127 (ie only ascii characters).
It's very useful for doing primitive accellerated isAsciiString, which in the 
case of ascii-compatible encodings (utf8, latin1, macroman, etc.) would mean no 
conversion is required for it to be the "appropriate" internal bytestring 
format. 
It's used f.ex. in the nextChunk code,
Strangely it is also used in  FileStream writeSourceCodeFrom: baseName: isSt: , 
for some reason we there use a MacRoman if stream contents isAscii, which 
really makes no sense, but whatever.

John pointed out some converters were lying, I'm not entirely sure that's true 
anymore, what IS certain though, is the external code format used is 
inconsistent, depending on from where/how you save/load it.
It really should be cleaned up to always store in utf8, and possibly also 
latin1 if possible.
All this should be cleared up to always try reading as UTF8, then raising an 
InvalidUTF8 error which can be handled by telling it to use a different 
converter and restart. 
Possibly chosen from a menu when dropping a file on image, or choosing an 
alternative automatically if we know the possible other encodings a file could 
have been saved as,  not sure how to best do it for scripts given as parameters 
when launching the vm

On the font rendering side, I agree with Nicolas it's too complicated doing 
font rendering in-image, FT is an ok compromise though.
As for the bitmap strikefont rendering, what is really needed is a way to 
specify the charset it represents, and mappings from the internal string 
encodings to its glyphs.
F.ex., Bitmap DejaVu is really latin15, so it will currently render some 
ByteString characters incorrectly, as well as render some Unicode chars it 
really has glyphs for as ?. (such as the euro sign)

Which all really has nothing to do with your initial question :)
The internal representation of strings really hasn't changed since it was 
written, with the exception that leadingChar for WideStrings are now zero. 
As far as I can tell, that means the interal storage format of widestrings is 
now equivalent to utf32, not sure what Byte Order it uses though, or if that is 
even consistent across platforms. :)

The point about using WaKomEncoded, and passing all strings going into/out of 
the image through an encoder is still valid.

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] The Pharo Linux Vm [WAS] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

[Henrik Johansen]

On Mar 29, 2010, at 9:29 45AM, Mariano Martinez Peck wrote:

> 
> Yes! The windows VM has already that. The MacVM, I sent an email few months 
> ago to explain how to do it.
> If you want, I can upload a Squeak 4.2.2beta1U.app   but with the Pharo icons 
> and named Pharo 4.2.2beta1U.app
> Then we link from the website to that VM. What do you think ? 
> 
> I know there are newer MacOS VMs, but they are still in beta and for the 
> Pharo 1.0 I think the best VM is the 4.2.2.beta1
> 
> What do you think ?
> 
> Cheers
> 
> Mariano 

Please use 4.2.3.beta1, as it includes the bitblt fixes which affects 
StrikeFont rendering.
So if someone switches to Bitmap DejaVu fonts, they don't have to be annoyed 
their text looks strange when dragging windows :)

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] squeakToUTF-8 and related?

[Henrik Johansen]

On Mar 29, 2010, at 11:16 30AM, Nicolas Cellier wrote:

> I presume that under the idiom "latin1" you refer to code page 1252
> rather than iso8859-L1, right ?
> 
> Nicolas
Good question :)
What IS the presumed internal encoding of Bytestrings in Squeak?
That's the one I meant, I merely assumed it was latin1 seeing as how the text 
converter refers to it as such.
Personally I thought it was iso8859-L1, seeing as the bytestring to unicode 
conversion does a simple shift of chars > 127 to the 0080 - 00FF range.

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] squeakToUTF-8 and related?

[Henrik Johansen]

On Mar 29, 2010, at 11:52 43AM, Nicolas Cellier wrote:

> 2010/3/29 Henrik Johansen :
>> 
>> On Mar 29, 2010, at 11:16 30AM, Nicolas Cellier wrote:
>> 
>>> I presume that under the idiom "latin1" you refer to code page 1252
>>> rather than iso8859-L1, right ?
>>> 
>>> Nicolas
>> Good question :)
>> What IS the presumed internal encoding of Bytestrings in Squeak?
>> That's the one I meant, I merely assumed it was latin1 seeing as how the 
>> text converter refers to it as such.
>> Personally I thought it was iso8859-L1, seeing as the bytestring to unicode 
>> conversion does a simple shift of chars > 127 to the 0080 - 00FF range.
>> 
>> Cheers,
>> Henry
>> 
> 
> From what I understood, CP1252 is Microsoft "latin1" and use codes 128 to 159.
> ISO8859-L1 match fisrt 256 codes of unicode latin-1 and has codes 128
> to 159 unused.
> You know, when Microsoft "uses" a standard, it's always a better standard ;)
> 
> I have nothing against CP1252, it's an optimization which avoid
> wasting 32 cheap codes.
> But I'm not sure about various compatibility issues in/with the
> external world...
> 
> Squeak clearly uses CP1252.
> For Pharo, there might be a mix of the two since Sophie-like
> refactorings. Surely what John was refering to.
> 
> Nicolas

Ummm...
All the utf8-converters in squeak use Unicode value:, which maps directly from 
charCode 128->255 to Unicode value 128->255.
Unicode value 128->255 IS iso8859-L1, so if squeak uses CP1252 as internal 
format, all the converters in Squeak are wrong.

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] squeakToUTF-8 and related?

[Henrik Johansen]

On Mar 29, 2010, at 2:00 09PM, Nicolas Cellier wrote:

> 2010/3/29 Henrik Johansen :
>> 
>> On Mar 29, 2010, at 11:52 43AM, Nicolas Cellier wrote:
>> 
>>> 2010/3/29 Henrik Johansen :
>>>> 
>>>> On Mar 29, 2010, at 11:16 30AM, Nicolas Cellier wrote:
>>>> 
>>>>> I presume that under the idiom "latin1" you refer to code page 1252
>>>>> rather than iso8859-L1, right ?
>>>>> 
>>>>> Nicolas
>>>> Good question :)
>>>> What IS the presumed internal encoding of Bytestrings in Squeak?
>>>> That's the one I meant, I merely assumed it was latin1 seeing as how the 
>>>> text converter refers to it as such.
>>>> Personally I thought it was iso8859-L1, seeing as the bytestring to 
>>>> unicode conversion does a simple shift of chars > 127 to the 0080 - 00FF 
>>>> range.
>>>> 
>>>> Cheers,
>>>> Henry
>>>> 
>>> 
>>> From what I understood, CP1252 is Microsoft "latin1" and use codes 128 to 
>>> 159.
>>> ISO8859-L1 match fisrt 256 codes of unicode latin-1 and has codes 128
>>> to 159 unused.
>>> You know, when Microsoft "uses" a standard, it's always a better standard ;)
>>> 
>>> I have nothing against CP1252, it's an optimization which avoid
>>> wasting 32 cheap codes.
>>> But I'm not sure about various compatibility issues in/with the
>>> external world...
>>> 
>>> Squeak clearly uses CP1252.
>>> For Pharo, there might be a mix of the two since Sophie-like
>>> refactorings. Surely what John was refering to.
>>> 
>>> Nicolas
>> 
>> Ummm...
>> All the utf8-converters in squeak use Unicode value:, which maps directly 
>> from charCode 128->255 to Unicode value 128->255.
>> Unicode value 128->255 IS iso8859-L1, so if squeak uses CP1252 as internal 
>> format, all the converters in Squeak are wrong.
>> 
>> Cheers,
>> Henry
>> 
> 
> ISO8859-L1 and CP1252 only differ for code points 16r80 to 16r9F.
> Contrarily to what I said, these code points are assigned to G1
> control characters (anyone ever used these ?).
> See http://en.wikipedia.org/wiki/ISO_8859-1 and
> http://en.wikipedia.org/wiki/Windows-1252

Not to my knowledge :) 
The strong argument for using latin1 as internal charset for ByteString vs 1252 
is the 1-1 mapping to unicode values.

> 
> Now, I'm not so sure anymore why I thought squeak was CP1252. Is it ?
Seems ambiguous.

> My guess was probably based on macToSqueak and squeakToMac implementation.

Yes, that does indeed do MacRoman -> 1252 transformation. As does 
MacRomanTextConverter, in Pharo as well...
Converters assuming different internal encodings, fonts which render a charset 
different from both of them... Fun eh?

> But endering of following snippet isn't CP1252 complying:
> 
> String withAll: ((16r80 to: 16r9F) collect: [:e | Character value: e])
> or
> (16r80 to: 16r9F) collect: [:e | Character value: e] as: String
> '•™≠∞≥∑∫Ω√≈…—‘Ÿ⁄∂∆Œ‚„‰ˆ˜˘˙˚˝˛ˇıƒ'
> 
> In Squeak 4.1 the different fonts don't agree on rendering these characters...
> DefaultFixedTextStyle is still using MacRoman and display accented characters.
> DefaultTextStyle hack first 4 entries with caret underscore left arrow
Yup, Bitmap DejaVu is latin15 (some characters different from latin1, amongst 
them the € ), with 4 extra entries as you mentioned.
> and up arrow (probably a Cuis hack)
> Accu* just seem to have a hack for left arrow
Yeah, they seem to cover... a blend of latin1, latin15 (has euro symbol), and 
something else (square-root :D ). Wee.

Render with a Unicode font, and you get nothing but []'s, which would be the 
correct latin1-rendering of said string.

Which is why I said an encoding property for the StrikeFonts was needed, so you 
can do the proper conversion of internal string charcodes to the charcode 
values the font expects. (Or rather, bitmap offsets)
This of course means you'd have to come up with a  consistent definition of 
what the internal ByteString encoding in Squeak is first, though. 


> Maybe with a bit more clean-up (Character euro is answering the
> MacRoman code for example,
The keyboardinput handling in Squeak does strange things, at least on a Mac...
Alt - § (which gives a euro symbol on my keyboard layout) is read as a WideChar 
with the correct unicode value on Pharo, but as Char 164 in Squeak.
Alt- 5 (∞) does a similar thing, reads as correct widechar on Pharo, but on 
Squeak turns into char 129.
> and taking macRoman conversions from
> Sophie/Pharo), we could declare Squeak is using unicode...
> Great !
> 
> Nicolas


That would be my dream as well. 
Or really, I'd settle for any unambiguous definition of what the ByteString 
encoding is.
"A little more clean-up" may or may not be an understatement  though, it would 
involve going through all the converters, all keyboard-input processing code 
(seems to be more stable in Pharo on mac), and all places where strings 
enters/leaves the system. :)

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] squeakToUTF-8 and related?

[Henrik Johansen]

On Mar 29, 2010, at 3:54 25PM, Henrik Johansen wrote:

> Yes, that does indeed do MacRoman -> 1252 transformation. As does 
> MacRomanTextConverter, in Pharo as well...
> Converters assuming different internal encodings, fonts which render a 
> charset different from both of them... Fun eh?

Ooops. my bad.
MacRomanTextConverter in Pharo actually does work. (I think... encodings make 
my head spin)

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] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

[Henrik Johansen]

> 
> What's the yearly costs for the Intel Compiler license?
> 
> Adrian
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
According to the website, 600$ for a single-user license on a single platform, 
240$ for yearly support renewal.
Other licensing options you have to contact them for pricing.

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] The Windows VM

[Henrik Johansen]

On Mar 30, 2010, at 9:53 35AM, Mariano Martinez Peck wrote:

> 
> 
> On Mon, Mar 29, 2010 at 9:07 PM, Germán Arduino  wrote:
> Sorry, correct me if I'm wrong, but Pharo don't have its own Win VM right?
> 
> Then if Pharo relies on the Squeak Windows VM I think that a good
> policy is use the latest.
> 
> 
> No, I don't think so. I don't  know who did it, but at the end it is a squeak 
> VM. I mean, the sources come from svn or vmmaker or both, but there is no 
> fork (maybe i am wrong). Ok, we changed the splash picture and the name. 
> 
> Does someone know?

No forking, just custom .rc files to "rebrand" it.

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] squeakToUTF-8 and related?

[Henrik Johansen]

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


Den 1. apr. 2010 kl. 11.31 skrev Michael Rueger :


On 4/1/2010 10:38 AM, Stéphane Ducasse wrote:


So mike could you summarize the Pharo situation.


Until someone proves me wrong I would say that Pharo is UTF-8  
clean :-)



Michael

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



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

Re: [Pharo-project] squeakToUTF-8 and related?

[Henrik Johansen]

On Apr 1, 2010, at 3:47 02PM, Michael Rueger wrote:

> On 4/1/2010 3:26 PM, Stéphane Ducasse wrote:
> 
>>> Until someone proves me wrong I would say that Pharo is UTF-8 clean :-)
>> 
>> Sure but what does it mean for stef the stupid:
>>  characters/strings are encoded in UTF-8 or optimized ->  127 and then 
>> after
>> If you could just rwrtie a little paragraph that I understand once :)
> 
> I'll try :-)
> 
> And I should have written unicode clean, not UTF-8.
> 
> So modulo bugs like the one Henrik pointed out Pharo
> - keeps all strings in the image in unicode. Either as byte strings for 
> strings that do not contain any characters larger than 127, WideString 
> otherwise using basically UTF-32 encoding.
> - has all en/decoders fixed to do the correct *-encoding to unicode and back 
> translation
> - utilizes the unicode character entry in the input events, so it should be 
> possible to input all unicode characters on the different keyboards (us, 
> german, french, russian, etc)
> - uses unicode encoding for filenames
> - uses unicode encoding for the clipboard
> 
> Hope I didn't leave out anything important :-)

I'd like to add
"Other means of importing/exporting code", ie. for mcz., .st, .cs, 
reading/writing logic. 
This is the place to me there seems to still be shady areas in Pharo. Mostly 
because they seem to assume different encodings for non-utf8 readable input. 

Also, I don't really mind we keep some strings as latin1 when possible, as they 
tend to be a lot faster to process, and the conversion between them and 
WideStrings is trivial, and as far as I can tell, reliable.

Cheers,
Henry

PS. The other issues with rendering absolutely apply to Pharo, but not quite 
related to string encoding per se.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] How do i import .MCZ into Squeak?

[Henrik Johansen]

On Apr 6, 2010, at 7:45 32AM, James Ladd wrote:

> Hi Pharo,
> 
> I got the .MCZ package installed, but there is a dependency on RBProgramNode 
> which I can't find.
> 
> I'm looking for the package / source for RBProgramNode, which I think could 
> just
> be a image version issue.  Is it?
> 
> Rgs, James.

I'd recon you need RB installed, open MetacelloRepository, load 
ConfigurationOfRefactoringBrowser, and type ConfigurationOfRefactoringBrowser 
project latestVersion load.
(Or browse the package and see what you need to load manually in 
baseline/version methods).
The ProgramNode class itself is in the AST-Core-Nodes package.
Kind of hard to tell if that is all you need though, as the link you provided 
leads me to the squeaksource frontpage...

Cheers,
Henry

> Hi Pharo,
> 
> Please be gentle as it has been a while since I have filed into my image
> 
> I'm looking at this package: 
> http://www.squeaksource.com/@yDzCRgmmKSZ1rdfr/i3M9pl92
> I'm wondering how to load it into my Squeak image so I can run it?
> 
> Rgs, James.
> 
> Find it at CarPoint.com.au New, Used, Demo, Dealer or Private? 
> Meet local singles online. Browse profiles for FREE! 
> ___
> 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] Handle Close Event in Image - necessary for 1.0?

[Henrik Johansen]

On Apr 6, 2010, at 10:48 19PM, Stéphane Ducasse wrote:

> Torsten I appreciate your effort but we can only do what can be done in the 
> time
> we can allocate to do a task if you see what I mean. 
> I cannot test on windows because we do not have a windows machine. We are 
> doing an incredible
> amount of work but we cannot do more than it is reasonable to do.
> 
> Then in freeze time this is freeze time. we will try to get shorter iteration 
> cycles and this is not 
> by delaying 1.0 that we are making progress on that front. 
> 
> And this is not by saying that pharo "will be less quality than" ... more or 
> less that it helps.
> 
> So 1.0 will be like it can. And if people bash us this is ok too. 
> You remember a while ago one guy asked who is ready to pay 10 Euros per month 
> to have a 
> better pharo and we got 6 persons
> 
>> However I still believe that fixing this in 1.0 would not only
>> be a plus - it will also prevent questions regarding this
>> new problem since people WILL use newer VM's after the 
>> first 1.0 release of Pharo and then instantly step into the problem!
>> 
>> 
>> And it is not a Windows specific problem as Stef thinks it is.
>> 
>> Bert requested John today (see [1]) to change the default for Mac too ...
> 
> TODAY. Imagine I was painting my house and this evening this would have 
> to be fixed?
> When is the last time that a bug that annoys you on windows got fixed in one 
> day?
> because for me on mac so far it took months. 
> 
>> so if you upgrade your Mac VM for whatever reason (maybe to do
>> 1.1 work or since you need a newer VM for a commercial project) 
>> then you will step into this with the 1.0 image.
> 
> Yes and since you are a good pharoers you will know and you will understand
> and help us and help yourself. 

I've put some slices based on the .cs in the inbox, one for 1.0 and one for 
1.1.  (quitSession was moved to WorldState in 1.1, and some other minor diffs)
I've also tested and can confirm they work with the newest Windows VM, not sure 
about the behavior on Linux, which apparently was updated as well.


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] Canvas transform bug when rendering text?

[Henrik Johansen]

On Apr 7, 2010, at 1:45 49PM, David Harvey wrote:

> Hi list,
> 
> I'm writing a little charting morph, and while playing with rotating text for 
> axis labels came across something which I've noted in Morphs text handling a 
> couple of times. 
> 
> If I apply a transform in a drawing operation, rotated text _appears_ to be 
> drawn twice, slightly offset, giving a scrappy bold look. It seems only to do 
> this when drawing on a form canvas that's backed onto the display: if you 
> pick and drag the morph, the text is rendered beautifully.
> 
> The test morph attached isolates the problem. The transcript logging is an 
> attempt to see what might be happening: looking at the output it appears that 
> there are circumstances in which the during: block is invoked twice.
> 
> Any thoughts?
> 
> David


http://n4.nabble.com/Problem-with-TransformationMorph-td1691811.html#a1691811

Basically, transform doesn't work with depth 32.
Workarounds are described in the thread.

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] Handle Close Event in Image - necessary for 1.0?

[Henrik Johansen]

On Apr 7, 2010, at 12:38 25PM, Stéphane Ducasse wrote:

> Thanks Henrik
> this is something I understand. I will integrate that for 1.1

Yes, there's some new stuff there which won't work well if we ever move towards 
multi-window support, but the entire event-handling will have to be rewritten 
in that case anyways, so I didn't think too much of it.
I'd say the first step in any case would be moving Event-object generation out 
of the HandMorph class... (did MVC make its own kind of events?)

Probably a good idea to switch to something reacting to new events in the queue 
rather than polling it too, if we intend to ever switch the 
inputEventPollingFetcher for the actual InputEventFetcher some time in the 
future. 
Though,  InputEventSensor installEventSensorFramework seems borken on Windows 
now (eventbuffer overflows with 4.0.2 VM ), and incredibly slow to signal 
semaphore (albeit not loosing any events anymore in 1.1) on a Mac 4.2.4 VM. On 
the 5.X series, it works like a dream though :D

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] Canvas transform bug when rendering text?

[Henrik Johansen]

On Apr 9, 2010, at 11:40 38AM, Stéphane Ducasse wrote:

> 
> On Apr 9, 2010, at 11:28 AM, Lukas Renggli wrote:
> 
>> I don't write code like this.
> 
> It was a joke :) 
> but I really like the visual effect 
> 
>> Rotating a window is just a good test to
>> see if works, because it calls all kind of different code.
>> 
>> If you rotate a more complex window than a workspace, my system hangs
>> btw. So there must be other stuff broken there.
> 
> oops
> with the fix too?

Yes. The fix was for which draw mode is used, and nothing else.
The transformBy: method still creates a new Form of extent and depth same as 
the Tranformation each draw call, so it gives the GC a real workout.
Sometimes this manifests as system hangs, others as a constantly higher CPU 
usage. (depending on how large your transformed morph is)

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] [update 1.1] #11310

[Henrik Johansen]

Me neither, I just looked at the method changed in the .cs Torsten  
created based on Squeak changes and checked what was appropriate :)
Btw, a "bad" side-effect is you Are no konger able to close a hung  
image with the close button, since it noe gets sent to the image side  
for handling.


Cheers,
Henry

Den 9. apr. 2010 kl. 21.54 skrev Stéphane Ducass r>:




11310
-

- Issue 2286:Class definition while compiling method
- Issue 2131:Handling Window events. Thanks Henrik - I looked at  
the code and I would not be able to fix that.

again some stuff to learn.

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] Canvas transform bug when rendering text?

[Henrik Johansen]

Not entirely sure sesong as I write this from a phone with no code  
nearby, but a hunch would be checking the method in question, and try  
disabling the shadow drawing,


Cheers,
Henry

Den 9. apr. 2010 kl. 23.42 skrev Chris Muller :


Thank you Henrik, it looks like a huge improvement!  The attached
screen shots help explain why I only said "improvement" instead of
"perfect".  Look at the color of my translucent morph when it is
upright vs. rotated.  The translucency is now preserved, which is
great!  However, do you know why the color seems to lose so much
saturation?


2010/4/8 Henrik Sperre Johansen :

On 07.04.2010 14:26, Henrik Johansen wrote:

On Apr 7, 2010, at 1:45 49PM, David Harvey wrote:

Hi list,
I'm writing a little charting morph, and while playing with  
rotating text

for axis labels came across something which I've noted in Morphs text
handling a couple of times.
If I apply a transform in a drawing operation, rotated text  
_appears_ to be
drawn twice, slightly offset, giving a scrappy bold look. It seems  
only to
do this when drawing on a form canvas that's backed onto the  
display: if you

pick and drag the morph, the text is rendered beautifully.
The test morph attached isolates the problem. The transcript  
logging is an
attempt to see what might be happening: looking at the output it  
appears
that there are circumstances in which the during: block is invoked  
twice.

Any thoughts?
David

http://n4.nabble.com/Problem-with-TransformationMorph-td1691811.html#a1691811
Basically, transform doesn't work with depth 32.
Workarounds are described in the thread.
Cheers,
Henry

David, Lukas, whomever else it may concern.

Of course I turned out to be (partly) wrong when looking into it.
Transform does indeed not work with alpha, but not because of bugs in
WarpBlt as I assumed, but because FormCanvas always uses the Paint  
rule when

rotating...
Try the attached code, and you should get better results. (you  
probably want
to use smoothing > 1 if displaying text with rotation other than a  
multiple

of 90 degrees).

This seems to be more of a generic problem though, looking at the  
number of
places a= 32 ifTrue: [] check is made, I'll try to come up with a  
more
consistent solution for a system-wide patch. (which amongst other  
things
would also fix the black border appearing around a window while  
zooming back

to old position when you drag and drop it outside main window)

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

Re: [Pharo-project] news about 1.0

[Henrik Johansen]

On Apr 11, 2010, at 11:26 03PM, Stéphane Ducasse wrote:

> Hi guys
> 
> mariano, marcus and adrian got some push to get 1.0 out. I was just on cc:
> I think that we made a mistake not to roll that publicly via the mailing-list 
> (we will do that for 1.1).
> Now this is holidays time here, mariano is going to get married and adrian 
> just moved so no
> internet connection.
> Tomorrow I will sync with marcus to know if I can help to get this 1.0 
> version out.
> If I remember the mails I saw, marcus was looking for the 
>   BitBltPluging binaries for the one click image on other platforms than 
> mac os.
> 
> Stef
Hum, aren't they usually built as internal?
In that case, the only reason for including plugin binaries would be if there's 
been bug fixes to it since the vm was shipped... 
Which would probably mean you're providing a too old VM in the first place.
IIRC, On Windows, 3.11.8 / 4.0.2 would both include updated plugins, the main 
difference being 4.0.2 providing support for old image segment loading, but 
requiring in-image handling of quit events.

Not sure about linux, since I don't use it.
Seems to be in a state of updating at the moment, with 5-6 commits over the 
weekend, so might be worth waiting for.

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] #recreateSpecialObjectsArray woes

[Henrik Johansen]

On Apr 12, 2010, at 4:17 11PM, Igor Stasenko wrote:

> Hello,
> 
> i attempted to load Alien-Core package into trunk image, and it failed.
> 
> One of the problem is override of recreateSpecialObjectsArray method..
> 
> I wonder, maybe we should design a nicer API for extending/reserving
> slots in special objects array,
> so it won't require overriding this method by every package which
> needs to extend special objects, like FFI or Alien.
> 
> Another aspect of replacing this method is , that it makes problematic
> to unload such package, in case one wants to unload it.
> 
> So, my proposal is to add a simple API to SmalltalkImage class, and in
> order to install additional special objects one should do like:
> 
> MyClass class>>initialize
> 
> Smalltalk registerSpecialObject: myObject at: 55.
> Smalltalk registerSpecialObject: myObject at: 56.
> ...
> 
> or:
> 
> Smalltalk registerSpecialObjects: #( x y z) startingAt: 56.
> 
> upon package unload, a reverse scheme should be supported:
> 
> 
> MyClass class>>unload
> 
> Smalltalk unregisterSpecialObjectAt: 55.
> Smalltalk unregisterSpecialObjectAt: 56.
> ...
> 
> or:
> 
> Smalltalk unregisterSpecialObjects: 3 startingAt: 56.
> 
> 
> what you think?
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.
> 

+1 for the overall idea.
Implementation-wise, I'd also vote for raising errors in 
registerSpecialObject:at: if something other than myObject is already 
registered, changing to unregisterSpecialObject: at: in order to not 
unintentionally unregistering something else, and disallow 
unregisterSpecialObjects:startingAt: ;)

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 getting HashedCollection (another dream happening)

[Henrik Johansen]

On Apr 12, 2010, at 5:33 42PM, Stéphane Ducasse wrote:

> igor
> 
> peter snippets was just a dull example. Peter mentioned that some people fix 
> consequences instead of causes
> 
> 
> Stef

Or their application may have different expectations for what methods are ok to 
return collections with duplicated/nils in them.

In which case (in VW)

mySourcesWithoutNilsOrDuplicates
|myColl|

myColl := List new.
myColl addAll: self aSourceWithNils.
myColl addAll self aSourceWithDuplicates.
^myColl asSet

might have been an entirely legit use, which is sure to cause headaches if 
ported to a dialect which allows nils.

Not that that's a common occurrence, or something we should account for, just 
sayin'

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] Open Pharo debugger from a Seaside wallback

[Henrik Johansen]

On Apr 12, 2010, at 5:54 59PM, Marcus Denker wrote:

> 
> On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote:
> 
>> 
>> On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote:
>> 
>>> Lukas,
>>> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo.
>>> 
>>> But I test it on the same machine with Squeak 4.1 RC4 and it go very very 
>>> fast 
>>> to open de smalltalk debugger. 
>>> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note that 
>>> too or it's only my sensations?
>>> 
>> 
>> Did you check with Pharo 1.1? 
>> 
>>  
>> https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip
>> 
>> In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, but 
>> Pharo 1.1
>> 
> 
> My theory for your bug is that it's this:
> 
>   http://code.google.com/p/pharo/issues/detail?id=860
> 
> We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was supposed to 
> be released
> "very soon". 
> 
>   Marcus

It can still be slow in 1.1, depending on where the log is written to.
F.ex. I opened an image on Windows under Parallells, which decided it wanted to 
write to somewhere in the mounted OSX home directory,
took a few good seconds for the debugger to open.

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] Problem with window cycling (cmd + narrow)

[Henrik Johansen]

My guess is the morph hooks into events at the wrong level (at least a 
non-platform independent one).
It "works" on Windows VM,  and sort of the 5.0 Mac series(does not select at 
depress of command, but when a new button is pressed), and on 4.2.4 Mac VM I 
see the behavior both you and 2289 describe.

Cheers,
Henry


On Apr 13, 2010, at 5:04 17PM, Mariano Martinez Peck wrote:

> I think there is a bug in the windows cycling. Or maybe I don't understand it 
> anymore. I remembered I used to press cmd + narrow and the popup raised and 
> then I could choose slowly which windows I wanted.
> 
> But now, after pressing cmd + left arrow for example, the popup raise, but 
> very quickly disappear.  Giving me now time even to look at the current 
> opened windows. 
> 
> I guess this is a bug. What do you think ?
> 
> I tested in Pharo1.0 rc3 and Pharo 11309. 
> 
> I think this bug is different but related to issue 2289.
> 
> 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] A port of Pharo: Redline Smalltalk ...

[Henrik Johansen]

Yes.

On Apr 13, 2010, at 5:31 18PM, Richard Durr wrote:

> These would be migrated from Squeak to Pharo, right?
> 
> On Sun, Apr 11, 2010 at 10:01 PM, Stéphane Ducasse
>  wrote:
>> Richard
>> 
>> Nicolas checked systematically that add: method returns their argument.
>> 
>>- Issue 2171:   add consistency in MC, Exception and other
>> 
>> for the tests:
>>this a list of possible tests that would be worth to migrate to pharo.
>>- Issue 2238:   tests for FileStream behavior
>>- Issue 1920:   Better PureBehaviorTests
>>- Issue 1934:   some tests for WeakRegistry
>> 
>> Let me know if you need advices.
>> 
>> Stef
>> 
>> On Apr 11, 2010, at 6:16 PM, Richard Durr wrote:
>> 
>>> I'd like to contribute, but I am not good enough for the difficult
>>> ones to come to pleasing solutions, and I somehow don't feel the other
>>> ones accessable for me :/
>>> 
>>> On Sat, Apr 10, 2010 at 9:21 PM, Stéphane Ducasse
>>>  wrote:
 Hi richard
 
 some changes are changes coming from squeak and in such a case there is 
 the squeak change
 It does not mean that we can integrate the change as it is.
 Thanks for looking at fixes and bug entries
 
 Stef
 
 On Apr 10, 2010, at 7:52 PM, Richard Durr wrote:
 
> I am still trying to grok how this issue-fixing works. For example, in
> "Difficulty:Easy" there are some issues which consist mostly of
> ChangeSets of something. O_o
 
 O_o
 
 Nice :)
 
 
> 
> On Tue, Apr 6, 2010 at 10:50 AM, Stéphane Ducasse
>  wrote:
>> Yes this is the vision we have.
>> Now if people would help for simple things in pharo we would have more 
>> time for such issues.
>> We got several people doing PhD on modules and related. We studied 
>> namespace and other kind of
>> points so we have an idea of what could be a solution but it should be 
>> implemented
>> tested.
>> 
>> Stef
>> 
>> 
>> On Apr 6, 2010, at 1:14 AM, Richard Durr wrote:
>> 
>>> No, it's not. I would be far more valuable to have modularized images
>>> though: Just like Next/Apples Nibs or Bundle-mechanism. These
>>> image-modules would be edited from a development-image-bundle. They
>>> could be used to form stand-alone applications already clean of the
>>> development code or libraries that contain only a diff to the base
>>> classes, these library-images could then be combined to form more
>>> complex images. They could also contain their own namespace… and they
>>> would replace the non-modelling packaging mechanism, but I digress… ^^
>>> 
>>> | packageWorkedOn |
>>> packageWorkedOn := Browser newPackageNamed: 'Calculator'.
>>> packageWorkedOn importPackage: 'Seaside'.
>>> "Create code in the Browser…"
>>> packageWorkedOn saveAsMonticello.
>>> packageWordedOn saveAsPackage.
>>> packageWorkedOn saveAsApplication.
>>> 
>>> or something like that … ^^
>>> 
>>> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer  wrote:
 
 jarober says:
 
> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM"
> projects never seem to come off is simple - Smalltalk isn't just flat
> text in an editor.  Smalltalk is the entire interactive environment.
> It would be fairly simple to get a syntax parser, but it wouldn't be
> Smalltalk.  It would be Ruby or Python with Smalltalk syntax.
> Somewhat useful perhaps, but not really Smalltalk.
 
 :(
 
 Hopefully it would have sufficient knowledge to be able to do something
 thus.
 
 Sorry, but I believe that it is the way that had to take commercial
 Smalltalk. It surprises to me that Cincom and company do not see it.
 
 Regards.
 --
 View this message in context: 
 http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.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/list