from:"Pharo4Stef"

On 06 Apr 2014, at 23:08, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com
wrote:

2014-04-06 22:29 GMT+02:00 Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com:
Good news,
I've managed to make your issue apparently vanish in Pharo3.0 VM.
For this, I:
- cleaned up unecessary differences with Eliot's VMMaker.oscog branch,
- removed unecessary changes ahead of VMMaker.oscog-eem.333 version (those
stamped LucFabresse)
- carefully applied changes from VMMaker.oscog-eem.333 that were not applied
Note that this version was marked as merged, which it was obviously not
Please, if you do not fully merge, but just cherry pick some changes, it's
better to not merge.
- upgraded to (merged) VMMaker.oscog-eem.335 because it fixes a snafu
- integrated the issues for which I emitted a pull request

All this work can be found publicly at
https://github.com/nicolas-cellier-aka-nice/pharo-vm/compare/fixMergeWithEliotVersion333

I cannot tell which missing change exactly was the root cause, and I cannot
dissect either, but I saw several + LiteralStart missing... Or it could be
related to cogit method/block native code generation...
The changes are most probably here
https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/af718618eee516d15c0b362123e3a77c8b6fd2e8

Bad news,
the structures at beginning of src/cm/cogit.c are generated out of order, and
I didn't find the cause yet.
Once solved, I think my branch should be carefully reviewed and integrated.

Haha! this is Class classsuperclassOrder: which break things...
The order of structures passed on input was mostly good but ruined on
output...

The Squeak ChangeSet classsuperclassOrder: does not convert the list of
classes asSet, thus somehow preserves provided order.
The Pharo version does not take so much care it seems...
Apparently the method was changed again in Pharo3.0, but neither does it
preserve order.

Can you publish the change for the superclassOrder: as a bug entry?
we should add a test

After fixing it, compilation went well...

2014-04-03 4:13 GMT+02:00 Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com:

2014-04-02 23:59 GMT+02:00 Stephan Eggermont step...@stack.nl:

Nicolas wrote:
Hmm, don't waste too much time.
All these methods are unchanged in github pharo-vm head revision
(VMMaker-oscog-StefanMarr.313)
The cause must be completely different in latest pharo vms.

Uhm, why? They haven’t changed.

Sorry, haven't changed means that there's no diff with the corrected version.
IOW, the fixes from Eliot have been integrated for a long time already.
You are seeing another symptom, probably another bug impacting the same code.
There are many diffs between pharo's and Eliot's branch, but not where you're
looking at.

Pharo vms 105 and later no longer crash, but all reliably show the bug.
And 236 is the last Squeak one to show the problem.

I might take a look at Esteban’s versions from the same time,
228 and 229

Stephan

Re: [Pharo-dev] WhatsUp from: 2014-04-07 until: 2014-04-20


On 07 Apr 2014, at 07:00, seas...@rmod.lille.inria.fr wrote:

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


- Presented Pharo to a well known group doing HCI in france. Kind of planting 
seed.

- Working on new chapter or old chapters

- Preparing release

 
 ### What's next, until 2014-04-20 (*):
 
 - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION
 
 (*) we'll be expecting results by then ;)

Re: [Pharo-dev] ghost windows

Yes it happens to me form time to time but it is difficult to debug the 
situation. 
On 07 Apr 2014, at 08:53, Johan Brichau jo...@inceptive.be wrote:

 Hi there,
 
 I often get in a situation where 'ghost windows' remain in the Pharo window 
 (see screenshot).
 These windows are closed (see taskbar) and I cannot select nor click these 
 ghost windows to remove them.
 
 Is there a way to remove them programmatically?
 They cause visual clutter when working with multiple real windows and I do 
 not want to rebuild an entire development image each time this occurs.
 
 Though this is in Pharo3, I think I occassionally had these in Pharo1.4 as 
 well.
 
 cheers
 Johan
 
 PharoScreenshot.png

Re: [Pharo-dev] [Vm-dev] Pharo VM bug 11130

 
 
 
 Yes, I did:
 https://pharo.fogbugz.com/f/cases/13180/Class-class-superclassOrder-should-preserve-classes-order
  
 
 Of course, those kind of expectations should be asserted by a test (I didn't).


TX!
 
 
 After fixing it, compilation went well...
 
 
 
 2014-04-03 4:13 GMT+02:00 Nicolas Cellier 
 nicolas.cellier.aka.n...@gmail.com:
 
 
 
 
 2014-04-02 23:59 GMT+02:00 Stephan Eggermont step...@stack.nl:
 
 
 Nicolas wrote:
 Hmm, don't waste too much time.
 All these methods are unchanged in github pharo-vm head revision 
 (VMMaker-oscog-StefanMarr.313)
 The cause must be completely different in latest pharo vms.
 
 Uhm, why? They haven’t changed.
 
 Sorry, haven't changed means that there's no diff with the corrected version.
 IOW, the fixes from Eliot have been integrated for a long time already.
 You are seeing another symptom, probably another bug impacting the same code.
 There are many diffs between pharo's and Eliot's branch, but not where 
 you're looking at.
 
 Pharo vms 105 and later no longer crash, but all reliably show the bug.
 And 236 is the last Squeak one to show the problem.
 
 I might take a look at Esteban’s versions from the same time,
 228 and 229
 
 Stephan

Re: [Pharo-dev] Case 13007 Cannot-integrate-a-slice-with-monticello-red-square-in-the-UI

Hi

I did not check the latest submission but to me putting a mutex on list looks 
like a bad decision. 
May be the original forking of the project list is the problem.

What is the point of view of the people that work on the issue.
Forking to get speed is often a way to pay high price after. Synchronisation 
points are important. 

Stef
On 07 Apr 2014, at 18:36, Ben Coman b...@openinworld.com wrote:

 Priority 2 fix ready for review. Please come pick it apart.
 https://pharo.fogbugz.com/f/cases/13007/Cannot-integrate-a-slice-with-monticello-red-square-in-the-UI
 cheers -ben

Re: [Pharo-dev] Build process of Pharo image

2014-04-06 Thread Pharo4Stef


On 05 Apr 2014, at 21:48, Hilaire Fernandes hilaire.fernan...@gmail.com wrote:

 Still, I do not get why the newer packages are not loadable with
 configurations instead of been carved in the image. Why can't packages
 developers provide such configurations?

sure give us a list?
- RB
- Nautilus
- spec 
- Keychain
- key mapping
- smart suggestions
- …..
- and many more

do you want an image by default without any tools? I do but we need time.

So what we want to do is
- to have a core mage that the one people use is based on the core + 
the loading of the components
and now we are arriving to this situation because before we did not 
have 
command-line
jenkins
- for Pharo 4.0 we will get there. Now since it is not easy to unload 
tools, and I’m busy with other aspects of work 
we could not do it the way you describe it but this is what we want.

= why did we fail
ok you have a core and some nice configurations
then a guy report a bug and a fixe
from this 
core and configuration we should create a new core AND correctly 
loading configurations and this is not fully automated yet.
have a look at Pharo/SystemConfigurations
You take unReloader you run the scripts and you load the configurations.
when they fail you fix them and restart. I have been doing that a lot 
and we will continue but this is booring.
So we should build tools and so far I do not see many people 
**Helping** beside pavel on this task

so you are right we are concious about it but no resources. 

 Why don't we have an image
 without those packages? Then public images built with. Is it not what
 Jenkins is supposed to do?
 I am afraid the situation looks like Etoys carved in Squeak.

We are fighting against it.
 
 Hilaire
 
 Le 05/04/2014 18:32, Marcus Denker a écrit :
 Yes, we need to look into a more modular build in Pharo4… to not just load 
 updates
 on the server but instead build from a small core (and possibly even from a 
 bootstrap).
 
 -- 
 Dr. Geo http://drgeo.eu

Re: [Pharo-dev] MC diffs are seriously broken in Pharo2.0

2014-04-06 Thread Pharo4Stef


On 06 Apr 2014, at 17:36, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com 
wrote:

 I'm trying to fix some Pharo VM issues (11330), but have awfully bad 
 experience with Pharo2.0 tools.
 
 The autocompletion stuff is a joke, it moves the input cursor randomly and 
 spoils my input. That's the first thing I disable.
Do you have the same with 30?
Because I know that there were some problems when we merged OC and EC but this 
is nearly more than a year ago.

 The pharo's PolyMorphDiffTool is good looking but awfully slw
 It clearly does not scale (10 minutes or so to diff Eliot's branch) so I 
 reverted to the old diff tool.
 But of course, someone broke MCMethodDefinitionsummary (gratuitously?) and 
 I had to revert this method to have class names displayed again.

Nicolas this is probably not gratuitoulsy and you know it. Doing imply doing 
mistakes. Give me a fully tested system and you will see that we
will not break it.

So can you open a bug entry so that we do not forget to fix it. 

 But worse than all, there are insane caches operating in MCVersion that drove 
 me crazy.
 Here is the scenario:
 1) I diff working copy against package.branchA-version.mcz
 2) I cherry pick and install a few methods
 3) I diff against package.branchA-version.mcz again to check if I missed 
 smthing
 4) Huh? it looks like my cherry pick have not been installed???
 Yes they were installed, but the completePackageSnapshot has been cached in 
 MCVersion!!!
 What a mistake! The working copy is going to evolve, caching a snapshot of it 
 is a DUMB thing.It means that methods that I further change in the working 
 copy will NEVER be taken into account next time I'll do a diff.
 So I had to change MCVersionchanges
 ^ self completeSnapshot patchRelativeToBase: self 
 loadCompletePackageSnapshot
 
 This is so broken that I have to report here.

Thanks this is the best things to do. 
You see probably one guy tried to speed up the system and this happens. 

 Note that I did not check if symptoms are still in Pharo 3.0, but the working 
 copy scnapshot cache still is for sure!
 
 Guys, it makes me wonder, who is eating the dog food?

We are constantly using Pharo alpha the complete moose and pharo 

 Did anyone progress into developing VM in Pharo 3.0, because if I must eat 
 it, I'd prefer the freshest ;)

I guess so. Esteban does not look like using Pharo2.0 but I will let him reply.

 Or if I fix some more bug, I'd like my efforts to not apply to an obsolete 
 version.

Us too. :)

Thanks for reporting problems. Can you open bug entries so that we can handle 
these problems?

Stef

Re: [Pharo-dev] Puzzled

2014-04-05 Thread Pharo4Stef

In fact there was an error in the debugger code = endless loop in another 
thread it was strange because the test was not returning 


On 05 Apr 2014, at 19:30, Eliot Miranda eliot.mira...@gmail.com wrote:

 Hi Stef,
 
 I think it is because forContext:priority: does not schedule the process, 
 just creates it.  The debugger code steps the process but after stepping the 
 process is still not runnable.  So the process terminate is unnecessary; the 
 process should not have been added to the run queue and should juts be GCed.  
 Since it is not the question is what refers to the process after the test has 
 run.
 
 To debug, I would rewrite the test as such:
 
 testBasic
 | process debugger printedString |
 process := Process
 forContext: [ 20 factorial ] asContext
 priority: Processor activePriority.
 
 debugger := Smalltalk tools debugger new
 process: process
 controller: nil
 context: context.
 debugger stack expand.
 
 self assert: debugger stack selectedIndex = 1.
 printedString := OpalCompiler isActive
 ifTrue: [   '[ 20 factorial ] in DebuggerTesttestBasic']
 ifFalse: [  '[...] in DebuggerTesttestBasic' ].
 self assert: debugger stack selectedItem printString = printedString.
 
 debugger send.
 debugger send.
 self assert: debugger code getText = (Integer#factorial) sourceCode.
 self assert: debugger stack selectedItem printString =  
 'SmallInteger(Integer)factorial'.
 
 ^process
 
 and then chase pointers on the result to see what is holding onto the 
 process.  Sicne the process is never runnable there's no need to set its 
 priority to anything special.
 
 However, one should also be able to replace the process terminate with 
 process resume to get it to run to termination (provided its priority stays 
 at Processor userInterruptPriority).
 
 HTH
 
 
 On Thu, Apr 3, 2014 at 10:41 AM, Pharo4Stef pharo4s...@free.fr wrote:
 Hi guys
 
 I need your brain cells.
 
 When I execute the test
 
 testBasic
 | context process debugger printedString |
 context := [ 20 factorial ] asContext.
 
 process := Process
 forContext: context
 priority: Processor userInterruptPriority.
 
 debugger := Smalltalk tools debugger new
 process: process
 controller: nil
 context: context.
 debugger stack expand.
 
 self assert: debugger stack selectedIndex = 1.
 printedString := OpalCompiler isActive
 ifTrue: [   '[ 20 factorial ] in DebuggerTesttestBasic']
 ifFalse: [  '[...] in DebuggerTesttestBasic' ].
 self assert: debugger stack selectedItem printString = printedString.
 
 debugger send.
 debugger send.
 self assert: debugger code getText = (Integer#factorial) sourceCode.
 self assert: debugger stack selectedItem printString =  
 'SmallInteger(Integer)factorial'.
 
 two times my image (latest get totally unusable).
 I thought that may be the process should be terminated
 so I added
 
 process terminate
 
 But nothing changes. I tried to debug the code but not chance.
 I tried self halt after [ 20 factorial ] asContext.
 
 I tried to execute the beginning in a workspace and not as a test to 
 eliminate problem.
 But again no chance.
 
 
 So did I miss something obvious?
 
 Stef
 
 
 
 
 
 
 
 
 -- 
 best,
 Eliot

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

Igor 

I was wondering the following: ? But TextStyle is not about strikefont?

Stef

On 04 Apr 2014, at 02:55, Igor Stasenko siguc...@gmail.com wrote:

 Okay, i think i got it..
 
 Here is what happens:
 - the font size is usually specified in points, not x@y points, but 
 typographical points,
 which is 
 1/72 inch
 
 
 TextStyle pointsToPixels: 14
 
 TextStyle pointsToPixels: 14 = 18.668
 
 pointsToPixels: points
 ^points * self pixelsPerInch / 72.0
 
 
 but in Athens, i , stupid idiot, completely forgot about that, 
 and use point size directly, to scale up font ..
 but the point is that this scaling performed in font units (EMs).
 
 so, to actually scale font correctly, i must use same TextStyle 
 pointsToPixels: .. 
 as Freetype package using..
 
 there is one caveat, that if you really want to see exactly , say 16 points 
 sized font on your screen,
 it is not possible without knowing the display resolution - how many pixels 
 in one inch (hence
 #pixelsPerInch ).
 Unfortunately, our VMs don't give us a way to determine DPI of display..
 and so, it is always 96 :/
  
 pheww
 
 fromFreetypeFont: aFont cairoFace: face
 .
 
   -  fontMatrix scaleBy: aFont pointSize.
 
  +  fontMatrix scaleBy: (TextStyle pointsToPixels: aFont pointSize).
 
 problem solved ... (i hope) :)
 
 -- 
 Best regards,
 Igor Stasenko.

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

 
 I don't think there is any way for the VM to know the #pixelsPerInch of the
 display, regardless of the display resolution.

There is no api in the OS for that? It would be really strange that we cannot 
know such information.

 Maybe that implies that some
 calibration would be needed in the image to relate font points to the
 physical display.
 
 Dave

Re: [Pharo-dev] Puzzled

Thanks camille apparently I restarted from a clean image but may be I merged.
Could you try loading the latest version of 12460 and let me know?

On 04 Apr 2014, at 09:21, Camille Teruel camille.ter...@gmail.com wrote:

 I tried on my machine in latest image and no matter how many times I run this 
 test, this test still passes and I don't notice any slowdown nor image 
 freeze. 
 But I see the hanging processes.
 Adding 'process terminate' at the end works for me.
 
 
 On 3 avr. 2014, at 19:41, Pharo4Stef pharo4s...@free.fr wrote:
 
 Hi guys
 
 I need your brain cells.
 
 When I execute the test 
 
 testBasic
  | context process debugger printedString |
  context := [ 20 factorial ] asContext.
 
  process := Process 
  forContext: context
  priority: Processor userInterruptPriority.
 
  debugger := Smalltalk tools debugger new
  process: process
  controller: nil
  context: context.
  debugger stack expand.
 
  self assert: debugger stack selectedIndex = 1.
  printedString := OpalCompiler isActive 
  ifTrue: [   '[ 20 factorial ] in DebuggerTesttestBasic']
  ifFalse: [  '[...] in DebuggerTesttestBasic' ]. 
  self assert: debugger stack selectedItem printString = printedString.
  
  debugger send.
  debugger send.
  self assert: debugger code getText = (Integer#factorial) sourceCode.
  self assert: debugger stack selectedItem printString =  
 'SmallInteger(Integer)factorial'.
 
 two times my image (latest get totally unusable). 
 I thought that may be the process should be terminated 
 so I added 
 
  process terminate
 
 But nothing changes. I tried to debug the code but not chance.
 I tried self halt after [ 20 factorial ] asContext.
 
 I tried to execute the beginning in a workspace and not as a test to 
 eliminate problem.
 But again no chance.
 
 
 So did I miss something obvious?
 
 Stef

[Pharo-dev] font folder on win7

Hi guys


I’m trying to understand why people get problems with fonts on windows.
The logic in the font manager is 

 'cdefghijklmnopqrstuvwxyz' 
et pour chaque disc dans  '\windows\fonts' '\winnt\fonts


but I wonder if the location of font on windows 7 is correct.
Can anybody with a window 7 report where the fonts are located?

stef

Re: [Pharo-dev] font folder on win7

thanks!

On 04 Apr 2014, at 19:44, Vincent BLONDEAU 
vincent.blond...@polytech-lille.net wrote:

 The best is to use environment variables :
 Under W7 it is :
 %SYSTEMROOT%\Fonts
  
 But you can get it under Pharo:
 PlatformResolver forCurrentPlatform directoryFromEnvVariableNamed: 
 'SYSTEMROOT'
  
 Vincent
  
 De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de Chris 
 Cunningham
 Envoyé : vendredi 4 avril 2014 19:09
 À : Pharo Development List
 Objet : Re: [Pharo-dev] font folder on win7
  
 It is located in \Windows\Fonts (and window is case-agnostic, so 
 \windows\fonts works as well)
  
 -cbc
  
 
 On Fri, Apr 4, 2014 at 9:48 AM, Pharo4Stef pharo4s...@free.fr wrote:
 Hi guys
 
 
 I’m trying to understand why people get problems with fonts on windows.
 The logic in the font manager is
 
  'cdefghijklmnopqrstuvwxyz'
 et pour chaque disc dans  '\windows\fonts' '\winnt\fonts
 
 
 but I wonder if the location of font on windows 7 is correct.
 Can anybody with a window 7 report where the fonts are located?
 
 stef

Re: [Pharo-dev] font folder on win7

This is strange because the system is looking for the correct location but does 
not find them.

On 04 Apr 2014, at 19:09, Chris Cunningham cunningham...@gmail.com wrote:

 It is located in \Windows\Fonts (and window is case-agnostic, so 
 \windows\fonts works as well)
 
 -cbc
 
 
 On Fri, Apr 4, 2014 at 9:48 AM, Pharo4Stef pharo4s...@free.fr wrote:
 Hi guys
 
 
 I’m trying to understand why people get problems with fonts on windows.
 The logic in the font manager is
 
  'cdefghijklmnopqrstuvwxyz'
 et pour chaque disc dans  '\windows\fonts' '\winnt\fonts
 
 
 but I wonder if the location of font on windows 7 is correct.
 Can anybody with a window 7 report where the fonts are located?
 
 stef

Re: [Pharo-dev] Suggested Syntax Highlighting Features for Beginners


On 04 Apr 2014, at 19:26, J.F. Rick s...@je77.com wrote:

 On Fri, Apr 4, 2014 at 6:41 PM, Ben Coman b...@openinworld.com wrote:
 For assignment, I would say bold both := and the variable being assigned to.
 
 I like that a lot, especially since it draws the two critical elements of 
 variable and assignment together. On a minor note, both := and = are 
 currently the same color: black. That only furthers the := is a message 
 misconception. It might be worthwhile also giving := its own color, given its 
 uniqueness.



yes this would be nice. And a fix for that. 

Did you also see that what I like is to make a distinction between a possible 
selector and a wrong one? because this is nice.


  
 Underlining sounds interesting, but there are a few choices:
 a. nested underlining - self someMessage: (self otherMessage: arg 1 and: 
 arg2) and: arg3
 b. non-nested underlining - only underline #otherMessage:and: and not 
 #someMessage:and:
 c. dynamically underline only message where cursor is located.
 
 I think you could do nested underlining in the same way that nested blocks 
 and parentheses work. someMessage: and the second and: are underlined in 
 black. otherMessage: and the first and: are underlined in green. That way 
 nesting is clear. This would also be useful for code with nested 
 conditionals, probably the most common occurrence of nested multi-part 
 messages. I also like (c) as a minimally intrusive change that could help 
 novices when they write code. It has the disadvantage that novices couldn't 
 look at a piece of foreign code and get where the multi-part messages were. 
 
 Cheers,
 
 Jeff
 
 -- 
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick

[Pharo-dev] left over when resizing window

Hi all

do you see a glitch when I resize a window? 
Because it is not really nice.
Stef

Re: [Pharo-dev] left over when resizing window


On 03 Apr 2014, at 16:42, Esteban Lorenzano esteba...@gmail.com wrote:

 that happens in retina displays. 
 I’m aware… no time yet to fix it :(

esteban do you think that this is related to the VM?
I would find that strange.

 
 Esteban, still on holidays
 
 On 03 Apr 2014, at 11:32, Serge Stinckwich serge.stinckw...@gmail.com wrote:
 
 This is this kind of glitches (see screenshot) ?
 I already talk about that some months ago in the mailing-list.
 
 On Thu, Apr 3, 2014 at 3:11 PM, Tudor Girba tu...@tudorgirba.com wrote:
 Funny that you do not see the same issues.
 
 I reproduce it consistently like this:
 - On 10.9.2 on a MacBook Pro with Retina display
 - Download the latest Pharo 3 and the latest VM and run it:
 curl -L get.pharo.org/30+vmLatest | sh
 - Open a workspace or any other window and drag it around
 
 
 Doru
 
 
 Doru
 
 
 On Thu, Apr 3, 2014 at 3:04 PM, Camille Teruel camille.ter...@gmail.com
 wrote:
 
 
 On 3 avr. 2014, at 14:58, Tudor Girba tu...@tudorgirba.com wrote:
 
 Hi,
 
 Here it is on the very latest of Pharo 3:
 
 https://www.dropbox.com/s/hfi5j64e9kyim14/Screenshot%202014-04-03%2014.56.33.png
 
 
 Ok, now I remember that I had that once several months ago, but I don't
 remember under which setting.
 I solved it with 'start drawing/stepping again' as Sergi said.
 We should find a way to reproduce it.
 
 
 Pharo3.0 Latest update: #30811
 'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
 acc98e51-2fba-4841-a965-2975997bba66 Mar 20 2014
 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
 acc98e51-2fba-4841-a965-2975997bba66 Mar 20 2014
 https://github.com/pharo-project/pharo-vm.git Commit:
 6e08ad296c0df6c1a4215a5dada5380c897dc2fe Date: 2014-03-17 14:45:12 +0100 
 By:
 Esteban Lorenzano esteba...@gmail.com Jenkins build #14812'
 
 
 Cheers,
 Doru
 
 
 
 
 On Thu, Apr 3, 2014 at 2:33 PM, Camille Teruel camille.ter...@gmail.com
 wrote:
 
 
 On 3 avr. 2014, at 14:21, Tudor Girba tu...@tudorgirba.com wrote:
 
 It happens all the time on Mac. It is not so obvious in the default Pharo
 image because of the background. In the Moose image, the background is 
 white
 and you see it immediately when resizing or dragging a window.
 
 
 I tried with many windows in the latest Moose image and I still see
 nothing.
 I'm on mavericks.
 
 Smalltalk vm version --
 
 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
 a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
 a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
 git://gitorious.org/cogvm/blessed.git Commit:
 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 
 By:
 Esteban Lorenzano esteba...@gmail.com Jenkins build #14535
 '
 
 
 Doru
 
 
 On Thu, Apr 3, 2014 at 2:16 PM, Camille Teruel camille.ter...@gmail.com
 wrote:
 
 
 On 3 avr. 2014, at 13:54, Pharo4Stef pharo4s...@free.fr wrote:
 
 Hi all
 
 do you see a glitch when I resize a window?
 Because it is not really nice.
 
 Nope, nothing in latest image at least.
 Does it happen in a fresh image?
 
 Stef
 
 
 
 
 
 
 --
 www.tudorgirba.com
 
 Every thing has its own flow
 
 
 
 
 
 --
 www.tudorgirba.com
 
 Every thing has its own flow
 
 
 
 
 
 --
 www.tudorgirba.com
 
 Every thing has its own flow
 
 
 
 -- 
 Serge Stinckwich
 UCBN  UMI UMMISCO 209 (IRD/UPMC)
 Every DSL ends up being Smalltalk
 http://www.doesnotunderstand.org/
 Screen Shot 2014-04-03 at 16.30.05.png

[Pharo-dev] Puzzled

Hi guys

I need your brain cells.

When I execute the test 

testBasic
| context process debugger printedString |
context := [ 20 factorial ] asContext.

process := Process 
forContext: context
priority: Processor userInterruptPriority.

debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.

self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive 
ifTrue: [   '[ 20 factorial ] in DebuggerTesttestBasic']
ifFalse: [  '[...] in DebuggerTesttestBasic' ]. 
self assert: debugger stack selectedItem printString = printedString.

debugger send.
debugger send.
self assert: debugger code getText = (Integer#factorial) sourceCode.
self assert: debugger stack selectedItem printString =  
'SmallInteger(Integer)factorial'.

two times my image (latest get totally unusable). 
I thought that may be the process should be terminated 
so I added 

process terminate

But nothing changes. I tried to debug the code but not chance.
I tried self halt after [ 20 factorial ] asContext.

I tried to execute the beginning in a workspace and not as a test to eliminate 
problem.
But again no chance.


So did I miss something obvious?

Stef

Re: [Pharo-dev] Puzzled


even using ensure: to make sure that the process is terminated it is not really 
working.
I have the impression that there is a problem and that the tests does not 
really finishes but this is really difficult to debug.

 Hi guys
 
 I need your brain cells.
 
 When I execute the test 
 
 testBasic
   | context process debugger printedString |
   context := [ 20 factorial ] asContext.
 
   process := Process 
   forContext: context
   priority: Processor userInterruptPriority.
 
   debugger := Smalltalk tools debugger new
   process: process
   controller: nil
   context: context.
   debugger stack expand.
 
   self assert: debugger stack selectedIndex = 1.
   printedString := OpalCompiler isActive 
   ifTrue: [   '[ 20 factorial ] in DebuggerTesttestBasic']
   ifFalse: [  '[...] in DebuggerTesttestBasic' ]. 
   self assert: debugger stack selectedItem printString = printedString.
   
   debugger send.
   debugger send.
   self assert: debugger code getText = (Integer#factorial) sourceCode.
   self assert: debugger stack selectedItem printString =  
 'SmallInteger(Integer)factorial'.
 
 two times my image (latest get totally unusable). 
 I thought that may be the process should be terminated 
 so I added 
 
   process terminate
 
 But nothing changes. I tried to debug the code but not chance.
 I tried self halt after [ 20 factorial ] asContext.
 
 I tried to execute the beginning in a workspace and not as a test to 
 eliminate problem.
 But again no chance.
 
 
 So did I miss something obvious?
 
 Stef

Re: [Pharo-dev] Puzzled

When I use 

| context process |
context := [ 20 factorial ] asContext.

process := Process 
forContext: context
priority: Processor userInterruptPriority.
[  
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.

] ifCurtailed: [ process terminate]

I do not get any extra process hanging around.

now if I do 



| context process |
context := [ 20 factorial ] asContext.

process := Process 
forContext: context
priority: Processor userInterruptPriority.
[  
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
Transcript show: debugger stack selectedIndex

] ifCurtailed: [ process terminate]


But then when I do 


| context process debuggerg |
context := [ 20 factorial ] asContext.

process := Process 
forContext: context
priority: Processor userInterruptPriority.
[  
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
Transcript show: debugger stack selectedIndex; cr.
] ensure: [ process terminate]

I get processes stuck trying to open the log fiel ro something like that.


Now I do not understand because when I ask the setter to stack (to get what is 
set in this variable) the system 
tells me that there is no store. 

Stef



On 03 Apr 2014, at 20:49, Pharo4Stef pharo4s...@free.fr wrote:

 
 even using ensure: to make sure that the process is terminated it is not 
 really working.
 I have the impression that there is a problem and that the tests does not 
 really finishes but this is really difficult to debug.
 
 Hi guys
 
 I need your brain cells.
 
 When I execute the test 
 
 testBasic
  | context process debugger printedString |
  context := [ 20 factorial ] asContext.
 
  process := Process 
  forContext: context
  priority: Processor userInterruptPriority.
 
  debugger := Smalltalk tools debugger new
  process: process
  controller: nil
  context: context.
  debugger stack expand.
 
  self assert: debugger stack selectedIndex = 1.
  printedString := OpalCompiler isActive 
  ifTrue: [   '[ 20 factorial ] in DebuggerTesttestBasic']
  ifFalse: [  '[...] in DebuggerTesttestBasic' ]. 
  self assert: debugger stack selectedItem printString = printedString.
  
  debugger send.
  debugger send.
  self assert: debugger code getText = (Integer#factorial) sourceCode.
  self assert: debugger stack selectedItem printString =  
 'SmallInteger(Integer)factorial'.
 
 two times my image (latest get totally unusable). 
 I thought that may be the process should be terminated 
 so I added 
 
  process terminate
 
 But nothing changes. I tried to debug the code but not chance.
 I tried self halt after [ 20 factorial ] asContext.
 
 I tried to execute the beginning in a workspace and not as a test to 
 eliminate problem.
 But again no chance.
 
 
 So did I miss something obvious?
 
 Stef

Re: [Pharo-dev] Puzzled


| context process debugger  |
context := [ 20 factorial ] asContext.

process := Process 
forContext: context
priority: Processor userInterruptPriority.
[  
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
Transcript show: debugger stack class ; cr
] ensure: [ process terminate]


When I look at some of the stuck processes

SpecDebuggerinitializePresenter
super initializePresenter.
self flag: 'some of this logic could be moved to the stack widget'.
self flag: 'The toolbar should not be updated when the list changes, 
but when an action is perormed.'.
self stack whenListChanged: [ :aList |
aList isEmpty ifFalse: [ self stack setSelectedItem: aList 
first ].
Updating the toolbar will result in changing the button 
widgets.
If the widget hasn't been opened, there will be no spec, which 
leads to an error.
self spec ifNotNil: [
self updateToolbar ] ].

self stack whenSelectedItemChanged: [:aContext |
self updateCodeFromContext: aContext.
self updateInspectorsFromContext: aContext.
self stack updateForSelectionChanged ].

self contextInspector initializeAutoRefresh.

^^^

And initializeAutoRefresh does not exist in the latest image.
I have no idea why the debugger may work may be this method is not used at all. 

Can somebody else confirm because I have the impression to fall into a rat nest.
stef

[Pharo-dev] endless number of call to initializePresenter when opening a debugger!!!

Can one of you do the following experience to let me know if I’m totally mad or 
not?

1 - Add Transcript show:'initializePresenter'; cr.
in the SpecDebuggerinitializePresenter
as below:

initializePresenter
super initializePresenter.
Transcript show:'initializePresenter'; cr.
self flag: 'some of this logic could be moved to the stack widget'.
self flag: 'The toolbar should not be updated when the list changes, 
but when an action is perormed.'.
self stack whenListChanged: [ :aList |
aList isEmpty ifFalse: [ self stack setSelectedItem: aList 
first ].
Updating the toolbar will result in changing the button 
widgets.
If the widget hasn't been opened, there will be no spec, which 
leads to an error.
self spec ifNotNil: [
self updateToolbar ] ].

self stack whenSelectedItemChanged: [:aContext |
self updateCodeFromContext: aContext.
self updateInspectorsFromContext: aContext.
self stack updateForSelectionChanged ].

self contextInspector initializeAutoRefresh.

2- open a transcript 

3- open a workspace and execute 1 halt. 

I get a really large number of initializePresenter in the transcript

Re: [Pharo-dev] endless number of call to initializePresenter when opening a debugger!!!

Indeed this is normal because initializeAutoRefresh does not exist!
So a nice endless loop.


On 03 Apr 2014, at 21:21, Pharo4Stef pharo4s...@free.fr wrote:

 Can one of you do the following experience to let me know if I’m totally mad 
 or not?
 
 1 - Add   Transcript show:'initializePresenter'; cr.
 in the SpecDebuggerinitializePresenter
 as below:
 
 initializePresenter
   super initializePresenter.
   Transcript show:'initializePresenter'; cr.
   self flag: 'some of this logic could be moved to the stack widget'.
   self flag: 'The toolbar should not be updated when the list changes, 
 but when an action is perormed.'.
   self stack whenListChanged: [ :aList |
   aList isEmpty ifFalse: [ self stack setSelectedItem: aList 
 first ].
   Updating the toolbar will result in changing the button 
 widgets.
   If the widget hasn't been opened, there will be no spec, which 
 leads to an error.
   self spec ifNotNil: [
   self updateToolbar ] ].
 
   self stack whenSelectedItemChanged: [:aContext |
   self updateCodeFromContext: aContext.
   self updateInspectorsFromContext: aContext.
   self stack updateForSelectionChanged ].
   
   self contextInspector initializeAutoRefresh.
 
 2- open a transcript 
 
 3- open a workspace and execute 1 halt. 
 
 I get a really large number of initializePresenter in the transcript

Re: [Pharo-dev] endless number of call to initializePresenter when opening a debugger!!!

And now I understand because we forgot to remove this message sent when 
removing the polling behavior of inspector.

On 03 Apr 2014, at 21:23, Pharo4Stef pharo4s...@free.fr wrote:

 Indeed this is normal because initializeAutoRefresh does not exist!
 So a nice endless loop.
 
 
 On 03 Apr 2014, at 21:21, Pharo4Stef pharo4s...@free.fr wrote:
 
 Can one of you do the following experience to let me know if I’m totally mad 
 or not?
 
 1 - Add  Transcript show:'initializePresenter'; cr.
 in the SpecDebuggerinitializePresenter
 as below:
 
 initializePresenter
  super initializePresenter.
  Transcript show:'initializePresenter'; cr.
  self flag: 'some of this logic could be moved to the stack widget'.
  self flag: 'The toolbar should not be updated when the list changes, 
 but when an action is perormed.'.
  self stack whenListChanged: [ :aList |
  aList isEmpty ifFalse: [ self stack setSelectedItem: aList 
 first ].
  Updating the toolbar will result in changing the button 
 widgets.
  If the widget hasn't been opened, there will be no spec, which 
 leads to an error.
  self spec ifNotNil: [
  self updateToolbar ] ].
 
  self stack whenSelectedItemChanged: [:aContext |
  self updateCodeFromContext: aContext.
  self updateInspectorsFromContext: aContext.
  self stack updateForSelectionChanged ].
  
  self contextInspector initializeAutoRefresh.
 
 2- open a transcript 
 
 3- open a workspace and execute 1 halt. 
 
 I get a really large number of initializePresenter in the transcript

Re: [Pharo-dev] Puzzled

ok now I understand: an endless loop inside the debugger creation. I do not 
understand why we did not address it with clement
because we open the debugger and other when we fixed the logic of the inspector 
(to avoid polling refresh).

Stef
On 03 Apr 2014, at 21:13, Pharo4Stef pharo4s...@free.fr wrote:

 
 | context process debugger  |
 context := [ 20 factorial ] asContext.
 
 process := Process 
   forContext: context
   priority: Processor userInterruptPriority.
 [  
   debugger := Smalltalk tools debugger new
   process: process
   controller: nil
   context: context.
   Transcript show: debugger stack class ; cr
 ] ensure: [ process terminate]
 
 
 When I look at some of the stuck processes
 
 SpecDebuggerinitializePresenter
   super initializePresenter.
   self flag: 'some of this logic could be moved to the stack widget'.
   self flag: 'The toolbar should not be updated when the list changes, 
 but when an action is perormed.'.
   self stack whenListChanged: [ :aList |
   aList isEmpty ifFalse: [ self stack setSelectedItem: aList 
 first ].
   Updating the toolbar will result in changing the button 
 widgets.
   If the widget hasn't been opened, there will be no spec, which 
 leads to an error.
   self spec ifNotNil: [
   self updateToolbar ] ].
 
   self stack whenSelectedItemChanged: [:aContext |
   self updateCodeFromContext: aContext.
   self updateInspectorsFromContext: aContext.
   self stack updateForSelectionChanged ].
   
   self contextInspector initializeAutoRefresh.
 
   ^^^
 
 And initializeAutoRefresh does not exist in the latest image.
 I have no idea why the debugger may work may be this method is not used at 
 all. 
 
 Can somebody else confirm because I have the impression to fall into a rat 
 nest.
 stef

[Pharo-dev] where is the jenkins monkey job?

Hi 

I would like to know if the monkey is currently running and not stalled but I 
cannot find the jenkins job doing it.

Stef

Re: [Pharo-dev] where is the jenkins monkey job?

https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/


On 03 Apr 2014, at 22:02, Pharo4Stef pharo4s...@free.fr wrote:

 Hi 
 
 I would like to know if the monkey is currently running and not stalled but I 
 cannot find the jenkins job doing it.
 
 Stef

Re: [Pharo-dev] simulator spotted a small problem with initializing stdout for the CommandLineHandler

Tx

https://pharo.fogbugz.com/default.asp?13165


On 01 Apr 2014, at 19:48, Eliot Miranda eliot.mira...@gmail.com wrote:

 Hi Camillo,
 
 Clément and I are simulating Pharo for Sista and I've spotted the 
 following small problem with the BasicCommandLineHandler's use of stdout.  It 
 looks like a bug in MultiByteFileStreamwantsLineEndConversion:.  
 BasicCommandLineHandlerinitializeStdout sets stdout's line end conventuion, 
 but in doing so MultiByteFileStreamwantsLineEndConversion: sends 
 MultiByteFileStreamdetectLineEndConvention, which is wrong, because stdout 
 is write-only.  I needed to change the simulator to fail as the VM does, but 
 perhaps a better fix is not to try and read from write-only streams.  Anyway, 
 thought I'd point it out.  No biggie.
 
   16r101B18 M MultiByteFileStreamdetectLineEndConvention 16r1F3A7A0: a(n) 
 MultiByteFileStream
   16r101B38 I MultiByteFileStreamwantsLineEndConversion: 16r1F3A7A0: a(n) 
 MultiByteFileStream
   16r101B60 I BasicCommandLineHandler(CommandLineHandler)initializeStdout 
 16r1F3A654: a(n) BasicCommandLineHandler
   16r101B84 I BasicCommandLineHandler(CommandLineHandler)initialize 
 16r1F3A654: a(n) BasicCommandLineHandler
   16r101BA4 I BasicCommandLineHandlerinitialize 16r1F3A654: a(n) 
 BasicCommandLineHandler
   16r101BBC M BasicCommandLineHandler class(Behavior)new 16r5B04CC: a(n) 
 BasicCommandLineHandler class
   16r101BD4 M [] in BasicCommandLineHandler classstartUp: 16r5B04CC: a(n) 
 BasicCommandLineHandler class
 
 -- 
 best,
 Eliot

[Pharo-dev] Was TickingWindow integrated?

Hi guys

I’m in a train (no internet) and I see that the inspector does not refresh but 
in fact 
we introduced with clement a nice tickingWindow in spec and the goal is that 
the window
refresh its contents. I have the impression it was not integrated.
Note that this change is important because it removes a lot of processes 
hanging in the background.

Stef

Re: [Pharo-dev] Was TickingWindow integrated?

https://pharo.fogbugz.com/default.asp?12460

this is this issue and we should not let all these processes in the image.

Stef

 Hi guys
 
 I’m in a train (no internet) and I see that the inspector does not refresh 
 but in fact 
 we introduced with clement a nice tickingWindow in spec and the goal is that 
 the window
 refresh its contents. I have the impression it was not integrated.
 Note that this change is important because it removes a lot of processes 
 hanging in the background.
 
 Stef

Re: [Pharo-dev] Thanks to all of you who asked

great news.

On 02 Apr 2014, at 17:17, Alexandre Bergel alexandre.ber...@me.com wrote:

 As you may know, an earthquake occurred yesterday evening in the north of 
 Chile. It was a strong one. 
 Many of us have asked how well we are. We are all good. 
 
 Luckily, Chile is very well prepared. Whereas a shake of 8.3 is strong enough 
 to swipe away most of countries, Chile almost did not suffer.
 
 It happens in the north of Chile, quite far from Santiago, where most of us 
 are based. We actually did not feel anything. Over the last few months, the 
 Chilean ground has been shaking a lot, around Santiago. 
 
 Thanks for thinking about us. You guys are great! 
 Alexandre (in the name of all the people living in Chile part of this mailing 
 list)
 -- 
 _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
 Alexandre Bergel  http://www.bergel.eu
 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

[Pharo-dev] Where are the monkey rules?

Hi 

this is really annoying not to be able to run the same rules than the ones in 
the monkey. Why? because the feedback
loop is terrible. So where are defined the monkey rules? How can I load them 
and run them on a slice?
Also this is annoying that a change get rejected because of problem in the 
package but not in the code published by the slice.

Right now this leads to important fixes not been integrated because they were 
flagged automatically by the monkey and passed under the radar. So after a 
month going back again inside the changes is not fun. Luckily there were 
simple. 

Stef

Re: [Pharo-dev] [Spec] whenSelectedItemsChanged: on TreeModel


 I made a plugin to spy on the NaytimusAnnouncer and in fact there is a storm 
 of announcements flying around all the time.
 

arghh
Thanks for letting us knowing.
 And they do not carry the expected payload ( nil instead of the method for 
 example)
 
 The plugin is in Smalltallhub in philippeback , HOExtras
 
 I'll do a screencast to show you.
 
 Phil
 
 Le 2 avr. 2014 13:30, Martin Dias tinchod...@gmail.com a écrit :
 Hi,
 
 I still can reproduce this issue in Pharo 30807 (last image). I'm trying to 
 workaround it with some problems.
 
 I ignore if this is already reported in fogbugs. Steps to reproduce:
 
 a) do it:
 
   TreeModel new
   roots: (1 to: 2);
   whenSelectedItemsChanged: [ :items |  self logCr: items ];
   openWithSpec.
 
 
 = in Transcript I see:
 
 b) during initial do it:
 
   #()
 
 c) after a click on 2:
 
   #()
   an OrderedCollection(2)
 
 d) after a click on 1:
 
   an OrderedCollection(2)
   an OrderedCollection(2)
   an OrderedCollection(1)
 
 
 Cheers,
 MArtín
 
 
 
 On Wed, Dec 11, 2013 at 6:10 PM, Benjamin 
 benjamin.vanryseghem.ph...@gmail.com wrote:
 As I said to Martin, I will investigate why, but it’s a bit tricky
 Must be some issue in MorphTreeMorph I introduced recently
 
 Ben
 
 On 11 Dec 2013, at 16:46, Roberto Minelli roberto.mine...@usi.ch wrote:
 
 Hi,
 
 I am experiencing problems with #whenSelectedItemsChanged: on a TreeModel.
 
 In particular, the block (i.e., argument of #whenSelectedItemsChanged: gets 
 randomly executed a couple of times (3/4) the second time that the selection 
 happens. The first time is fine. It looks like the registration of the 
 “event” or “announcement” is done multiple times.
 
 Any hint?
 
 Cheers,
 R

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

On 02 Apr 2014, at 14:46, J.F. Rick s...@je77.com wrote:

Is this supposed to fix the font rendering problem or some other font
problem? I tried it and it doesn't seem to help the rendering problem.

normally it should fix the font PrObLem
can you check that you loaded the latest NB?

Cheers,

Jeff

On Tue, Apr 1, 2014 at 6:27 PM, Igor Stasenko siguc...@gmail.com wrote:
okay i uploaded updated configs for NativeBoost and Athens into official
repositories for these projects.

Gofer new smalltalkhubUser: 'Pharo' project: 'NativeBoost';
configuration;
load.

ConfigurationOfNativeBoost loadDevelopment.

Gofer new smalltalkhubUser: 'Pharo' project: 'Athens';
configuration;
load.

ConfigurationOfAthens loadDevelopment.

shall do the trick..

for more details see
https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-different-platforms

On 28 March 2014 21:13, Pharo4Stef pharo4s...@free.fr wrote:
thanks Igor.
I’m trying to look at the font reloading bug.

On 28 Mar 2014, at 17:19, Igor Stasenko siguc...@gmail.com wrote:

https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-different-platforms

On 28 March 2014 16:42, Igor Stasenko siguc...@gmail.com wrote:
so, the quick and dirty fix is to put:

CairoGlyph classbyteAlignment

NativeBoost platformId = NativeBoostConstants win32PlatformId ifTrue: [
^ 8 ].
^ super byteAlignment

and then:

CairoGlyph rebuildFieldAccessors
CairoGlyphsArray initialize

(note you must run this snippet each time your image changes platform)..

and i need more time to fix it for real, because it is NB issue, to
automatically recalculate the structs size
if it changes platform.. (which also means you cannot store instances of
struct in image which survive the session)
... damn.. that's going to be complicated.

---

On 28 March 2014 16:27, Igor Stasenko siguc...@gmail.com wrote:

On 28 March 2014 16:01, Igor Stasenko siguc...@gmail.com wrote:

Ookkayy..
so, current status:

- finally we got an agreement that big red square because of font loading
issues and font rendering artifacts is two separate issues.
Thanks!
- i am not going to address font-loading issue here and now.. (because we
spent time on it earlier today with Stef already and you should have the
report on it in separate mail).

- we seem to be agreed that it is best to use same (up-to-date version) of
software when reporting issues to work on them. Thanks again. :)

- while on linux and mac things seem to be working fine, i can confirm that
there is rendering artifacts (same as reported by Vincent) on Windows.

so i going to explore what causing this problem..

... and found the cause:

On windows, for unknown reason, the structure (cairo_glyph_t) uses different
memory space alignment than on mac and linux

fieldsDesc
^ #(
ulongindex;
double x;
double y;
)

on mac and linux , the size of this structure in memory = 4 + 8 + 8 = 20
bytes,
on windows, however, due to 8-byte alignment, it is 4 + 8 + 8 + (4
alignment) bytes...

this causing the effect that if you copy array of glyphs in memory,
it does not copying whole array by slightly less (because it uses wrong
struct size which is smaller than it is)..
and because of that, you got weird artefacts at the tail of string, replaced
by misplaced/invalid characters etc..
because it is basically read from uninitialized part of memory with random
data.

i going to fix structure alignment for windows from default 4 bytes to 8
bytes..
but this is not very good news.. because this affecting many things... (as
you can imagine, not only cairo/athens working with external structures,
which need to be properly aligned).

--
Best regards,
Igor Stasenko.

--
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] [Inspiration] Toward a better programming