Re: [Pharo-dev] last opened window does not go away

[Henrik Nergaard]

The RubFindReplaceDialogWindow is made and held by RubFindReplaceService ivar 
dialog. There is also the ivar textAreaHolder which holds the active text area. 
When setting this variable from #textArea: an announcement is created for the 
textArea to the RubFindReplaceService, this should probably be a weak one.
I think the main issue is that the textArea instance variable is not cleared 
from RubFindReplaceService when it is deleted.

There is also announcements linked to RubFindReplaceService made by: 
RubAbstractTextArea>>#plugFindReplace. I guess these announcements should be 
weak.

Hope this helps,
Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Andrei 
Chis
Sent: Monday, November 16, 2015 3:23 PM
To: Discusses Development of Pharo 
Subject: [Pharo-dev] last opened window does not go away

Hi,

In the latest Pharo image there is a rogue instance of GLMSystemWindow.
If I do in the console the following code I get one instance:

/pharo Pharo.image eval "GLMSystemWindow allInstances"
an Array(a GLMSystemWindow(58720256))

There are actually two windows, but one is RubFindReplaceDialogWindow and it 
should have no link with the glamour window.

./pharo Pharo.image eval "SystemWindow allSubInstances"
an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a 
GLMSystemWindow(58720256))

If I create another window that contains a morph that can take the focus then 
the glamour window disappears and the new window stays:

./pharo Pharo.image eval "(PluggableTextMorph on: ' ' text: nil accept: nil)  
openInWindow close. Smalltalk garbageCollect. SystemWindow allSubInstances"
an OrderedCollection(a SystemWindow(234094592) an 
EditorFindReplaceDialogWindow(130547712))

Any idea if the find-replace service from rubric/textmorph holds one somehow to 
the last opened window or if there is another global cache that does it?

Cheers,
Andrei

[Pharo-dev] taskbarThumbnail leaks memory?

[Henrik Nergaard]

It looks like the taskbarThumbnails might be leaking memory.
When moving the mouse across the taskbar viewing the different thumbnails the 
memory usage increases by quite a lot (viewed in the taskmanager (Windows) ).
I made an example script to illustrate the resource usage.

Test scenario: 20 windows;
1 Playground, 19 Nautilus browsers (these are minimized).

=== Create Test Scenario 

19 timesRepeat: [
   Nautilus openOnClass: Object.
   World doOneCycle.
].
World doOneCycle.
World submorphs
   select: [ :m |
  m isKindOf: NautilusWindow
   ]
   thenDo: [ :m | m minimize  ]
= Enumerate the mouse moving from one taskbarButton to the next ===

| delay |

delay := [ :msToWait |
   | t |
   t := Time now asMilliSeconds.
   [ (Time now asMilliSeconds - t) < msToWait ]
  whileTrue: [ World doOneCycle ].

].
20 timesRepeat: [
   World submorphs
  detect: [:m | m isTaskbar ]
  ifFound: [ :taskbar |
 taskbar orderedTasks collect: [ 
:task |
task morph
 ]
 thenDo: [ :morph |
| button |
button := (taskbar 
taskButtonOf: morph).
morph 
taskbarButtonEntered: button event: nil in: nil.
delay value: 100.
morph 
taskbarButtonLeft: button event: nil in: nil.
delay value: 100
 ]
  ].
   Smalltalk garbageCollect.
].


Results: (Newest Win vm -> Image 50377)

opening the 20 Windows RAM used is 70MB.
1 iteration: 93MB
20 iterations: 130MB \ 190 MB when garbageCollect is commented out.

Should the resource usage be that high?
(a taskbarThumbnail is deleted before the next one is shown...)

Best regards,
Henrik

Re: [Pharo-dev] Problems with a large block

[Henrik Nergaard]

Hi Marco,

Had some fun with the code you posted :D.
This *should* be the equivalent, but with less variables so that you can access 
the RBBlockNode.

[ :h :s :v | | chroma rgb |
chroma := s*v.
rgb := { 0 . 0 . 0 }.
rgb 
at: h + 60) // 120) \\ 3) + 1) put: chroma;
at: h // 60) + 2 \\ 3) * 5 \\ 3) + 1) put: (chroma * (1.0 - 
(((h/60) \\ 2) - 1.0) abs));
collect: [ :part | (part + (v - (chroma) )) * 255 ]
] sourceNode .


Best Regards,
Henrik


-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Marco 
Naddeo
Sent: Wednesday, October 7, 2015 3:49 PM
To: Pharo-dev 
Subject: [Pharo-dev] Problems with a large block

Hi,

I have some problems with the large block at bottom:

-sending the message argumentNames gives me an empty array #() -sending the 
message sourceNode gives me a strange result and not a RBBlockNode, as I would 
expect

Best,
Marco



[ :h :s :v |
 | min chroma hdash X red green blue |
 red := 0.
 green:= 0.
 blue := 0.
 chroma := s * v.
 hdash := h / 60.
 X := chroma * (1.0 - ((hdash % 2) - 1.0) abs).
 (hdash < 1.0)
   ifTrue: [ red := chroma.
 green := X ]
   ifFalse: [
 (hdash < 2.0)
   ifTrue: [ red := X.
 green := chroma ]
   ifFalse: [
 (hdash < 3.0)
   ifTrue: [ green := chroma.
 blue := X ]
   ifFalse: [
 (hdash < 4.0)
   ifTrue: [ green := X.
 blue := chroma ]
   ifFalse: [
 (hdash < 5.0)
   ifTrue: [ red := X.
   blue := chroma ]
   ifFalse: [
 (hdash <= 6.0)
   ifTrue: [ red := chroma.
 blue := X ]
   ]
   ]
   ]
   ]
   ].
 min := v - chroma.
 { #red -> ((red + min) * 255).
   #green -> ((green + min) * 255).
   #blue -> ((blue + min) * 255) } ]



--
Marco Naddeo

PhD Student
Dipartimento di Informatica
Università degli Studi di Torino
Corso Svizzera 185, 10149 Torino, Italy

Re: [Pharo-dev] Question about implementation of a delay

[Henrik Nergaard]

delay := [ :msToWait |
| t |
t := Time millisecondClockValue.
[ (Time millisecondClockValue - t) < msToWait ]
  whileTrue: [ World doOneCycle ].
].

delay value: 200.


Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
Ferlicot D. Cyril
Sent: Tuesday, October 13, 2015 9:03 PM
To: Pharo 
Subject: [Pharo-dev] Question about implementation of a delay

Hi,

I am building a widget for fast table in order to filter them for Synectique 
and Pharo.

For now I have a Rubric editor where we can write a pattern and I use a Rubric 
announcement to update the Fast Table. So each time the rubric is update the 
method #update is call.

At the beginning #update was:


pattern := self patternFromString: filterField getText asString trimBoth.
fastTable dataSource: (initialDataSource newDataSourceMatching: pattern).
fastTable refresh
-

But this will update the Fast Table at each character, so I want to add a delay.
For example I want to let the user type and update the table if he don't type 
for 0.2second.

The only way I found is this:


update: anAnnoucement
| pattern timeStamp |
timeStamp := DateAndTime now.
timestamp := timeStamp copy.
[
(Delay forMilliseconds: 200) wait.
timeStamp = timestamp
ifTrue: [
pattern := self patternFromString: filterField getText 
asString trimBoth.
fastTable dataSource: (initialDataSource 
newDataSourceMatching: pattern).
fastTable refresh ] ] fork


But I think that create a new process a each update is really too heavy… So I 
would like to have some advices from experienced people to know if there is a 
better way to implement a delay.

If you want to check the code you can execute:


Gofer new
smalltalkhubUser: 'estebanlm' project: 'FastTable';
configuration;
load.
(Smalltalk globals at: #ConfigurationOfFastTable) loadDevelopment.
FTFastTableComposer browse


--
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France

Re: [Pharo-dev] hash and Collections

[Henrik Nergaard]

The identityHash should stay the same for any number of changes to the array..

| c1 c2 |

c1 := { #a . #b } asOrderedCollection.
c2 := { #a . #b } asOrderedCollection.

{ 
c1 hash.
c1 identityHash.
c2 hash.
c2 identityHash .
(c2 add: #c; yourself) identityHash.
} "inspect"

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Esteban 
Lorenzano
Sent: Friday, October 9, 2015 4:08 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] hash and Collections

but that’s an error, I think. 
a collection has to have always same hash… no matter its size (because is not 
an array) and no matter his elements.


> On 09 Oct 2015, at 15:21, Levente Uzonyi  wrote:
> 
> You simply don't modify _objects_ which are used as keys in hashed 
> collections. Or if you do so, you'll have to deal with the consequences 
> yourself.
> 
> Levente
> 
> On Fri, 9 Oct 2015, Esteban Lorenzano wrote:
> 
>> Hi,
>> 
>> Can anyone explain me how this is correct?
>> 
>> Collection>>#hash
>>  "Answer an integer hash value for the receiver such that,
>>-- the hash value of an unchanged object is constant over time, and
>>-- two equal objects have equal hash values"
>> 
>>  | hash |
>> 
>>  hash := self species hash.
>>  self size <= 10 ifTrue:
>>  [self do: [:elem | hash := hash bitXor: elem hash]].
>>  ^hash bitXor: self size hash
>> 
>> 
>> I mean… a hash that changes when I add elements to the collection… how can 
>> this work?
>> 
>> Esteban

Re: [Pharo-dev] Pedantic on Random>>nextValue method name

[Henrik Nergaard]

The method #nextValue actually calculates the next value the seed should be,
the current value can be accessed by sending #seed. 

I do agree that #nextValue might not be the clearest method name for its
use; perhaps #nextSeed would be a better name?

Best regards,
Henrik




--
View this message in context: 
http://forum.world.st/Pedantic-on-Random-nextValue-method-name-tp4850582p4850601.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Issue validation: #Collection cannot be changed using the classbuilder....

[Henrik Nergaard]

Thanks Marcus, that fixed the issue.

Best regards, 
Henrik



--
View this message in context: 
http://forum.world.st/Issue-validation-Collection-cannot-be-changed-using-the-classbuilder-tp4850387p4850607.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Issue validation: #Collection cannot be changed using the classbuilder....

[Henrik Nergaard]

Hi,

I uploaded a slice to fogbugz which includes removing the class side Ivars
from Collection to a new class managing a default random generator instance.
The Monkey throws this error while checking: /Error: #Collection cannot be
changed using the classbuilder. Use the reflective APi (e.g
#addClassVariable:). If you know what you are doing, you can use
#disableDuring: of DangerousClassNotifier/

Anyone know how to resolve this correctly?

Case 16577:
https://pharo.fogbugz.com/f/cases/16577
  

Error message:
https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/13783//artifact/validationReport.html

  

Best regards,
Henrik



--
View this message in context: 
http://forum.world.st/Issue-validation-Collection-cannot-be-changed-using-the-classbuilder-tp4850387.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Pedantic on Random>>nextValue method name

[Henrik Nergaard]

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Ben
Coman
Sent: Wednesday, September 16, 2015 6:39 PM
To: Pharo Development List <pharo-dev@lists.pharo.org>
Subject: Re: [Pharo-dev] Pedantic on Random>>nextValue method name

On Wed, Sep 16, 2015 at 11:22 PM, Henrik Nergaard <henri...@uia.no> wrote:
>> The method #nextValue actually calculates the next value the seed 
>> should be, the current value can be accessed by sending #seed.

>> I do agree that #nextValue might not be the clearest method name for 
>> its use; perhaps #nextSeed would be a better name?

>Yes. Thats better again.  Now its a private method, so there should be 
>problem changing it ;) ??anyone

Continuing on another Random topic related to..
https://pharo.fogbugz.com/default.asp?16577

I notice that Collection>>atRandom is protected by a mutex but
Collection>>atRandom: is not.  This makes me believe the protection is
for the Random generator and not for the actual picking of the element from
the collection.  So it seems that #atRandom holds the mutex too long - for
both random generation and element picking.
(>
Is there a specific use for the mutex in this case? I tried to use a shared
random without the mutex, and forking a few block closures, worked fine..

If the mutex could be removed we could just add a method in the class side
of Random like this:

globalGenerator
^Generator ifNil: [ Generator := Random new]

<) 

Thus I wonder if rather than copying the existing pattern of
Collection>>atRandom to GlobalSharedRandom>>generateFor:  it might be
better to make a more generic SharedRandom as follows...

(>
Maybe :P

I had a look at the Random Superclass in SciSmalltalk; here #next is used to
create and give the next random value. #seed for seed, and #peek for
checking what the next value would be without changing the current state. 
The peek method could be a good addition in Random -> 
Random>>#Peak
   Self nextValue / m

I would keep the way the #nextValue method behaves since this gives the
option to "peek" at the next value the Ivar seed will have without changing
it (could be useful?), but the name could be improved to be more clear. 
Perhaps the method name #nextSeed might not be so good after all, it might
imply that the method creates a new seed, but what it actually does is to go
to the next state in the random generation? ( so a better name could be
#nextState ?), (perhaps the Ivar seed would also be better called state or
internalState? )

<)

"Old calls to #next changed to private #nextValue"

Random>>nextValue
| lo hi aLoRHi answer |
hi := (seed quo: q) asFloat.
lo := seed - (hi * q).  " = seed rem: q"
aLoRHi := (a * lo) - (r * hi).
seed := (aLoRHi > 0.0)
 ifTrue:  [aLoRHi]
 ifFalse: [aLoRHi + m].
^ seed / m  "this line moved here from old #next"

Random>>next
 ^ self nextValue

Random>>next: anInteger into: anArray
1 to: anInteger do: [:index | anArray at: index put: self nextValue].
^ anArray

Random>>nextInt: anInteger
anInteger strictlyPositive ifFalse: [ self error: 'Range must be
positive' ].
anInteger asFloat isInfinite
ifTrue: [^(self nextValue asFraction * anInteger) truncated + 1].
^ (self nextValue * anInteger) truncated + 1


"SharedRandom protects all calls to private #nextValue"

Random subclass: SharedRandom
 instanceVariableNames: 'mutex'

SharedRandom>>initialize
 mutex := Semaphore forMutualExclusion.

SharedRandom>>next
^ mutex critical: [ self nextValue ]

SharedRandom>>next: anInteger into: anArray
^ mutex critical: [ super next: anInteger into: anArray ].

SharedRandom>>nextInt: anInteger
^ mutex critical: [ nextInt: anInteger ].


Then...

Object subclass: GlobalSharedRandom
classVariables: 'sharedRandom'

GlobalSharedRandom class>>initialize
sharedRandom := SharedRandom new.

GlobalSharedRandom class>>generator
^ sharedRandom


And finally...

Collection>>atRandom
^ self randomAt: GlobalSharedRandom generator. (> +1 <)


What do you think?
cheers, Ben

What do you think?
Best regards,
Henrik





--
View this message in context: 
http://forum.world.st/Pedantic-on-Random-nextValue-method-name-tp4850582p4850743.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Querying the accessors of a variable

[Henrik Nergaard]

Hi,

Is there a simple way to query a variable to check how many methods that
access it? (just want to know the size)

This works, but it is quite slow. 
(Morph whichSelectorsAccess: #owner) size 
Morph withAllSubclasses inject: 0 into: [ :sum :class | sum + (class
whichSelectorsAccess: #owner) size ]

 

Best regards,
Henrik



--
View this message in context: 
http://forum.world.st/Querying-the-accessors-of-a-variable-tp4852956.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [pharo-project/pharo-core] 07c9a0: 50344

[Henrik Nergaard]

Yeah, that might be my mistake. 
Looking into it now -> loading 16648 changes the color. 

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Marcus 
Denker
Sent: Monday, September 28, 2015 3:44 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] [pharo-project/pharo-core] 07c9a0: 50344

There is some strange side effect that now the menus have a very odd reddish 
color.

I guess this is caused somehow by 16648 or maybe even 16647?

I added a new issue tracker entry for that:


https://pharo.fogbugz.com/f/cases/16652/Menues-now-have-a-very-strange-reddish-color


>  Log Message:
>  ---
>  50344
> 16647 Nautilus Variable Menu Improvement
>   https://pharo.fogbugz.com/f/cases/16647
> 
> 16648 ThemeSettings protocol cleanup
>   https://pharo.fogbugz.com/f/cases/16648
> 
> 16649 Links of Globals and Class Vars: implement all reifications + extend 
> for Globals
>   https://pharo.fogbugz.com/f/cases/16649
> 
> http://files.pharo.org/image/50/50344.zip
> 
> 

Re: [Pharo-dev] RubAbstractTextArea copying

[Henrik Nergaard]

It does not seem that RubScrolledTextMorph supports duplication/copy (tried to 
duplicate one from nautilus code area and the same clear all code happened. 
Trying to duplicate a Playground just freezes the image (might be some circular 
references that is not handled when copying )).

Anyway: this code works ish.. (does not add unaccepted edits)

CodeCard>>#duplicate
| newCard |

newCard := self class new.
newCard 
selector: self selector; "must be before selectedClass"
selectedClass: self selectedClass;
updateCodeWith: self textModel text.
self activeHand attachMorph: newCard. "attachMorph: is nicer than 
grabMorph: :)"
selected := false.
self changed.


Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Stephan 
Eggermont
Sent: Friday, September 18, 2015 6:19 PM
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] RubAbstractTextArea copying

On 18-09-15 16:50, Henrik Nergaard wrote:
> I looked into the bug a bit and found something strange
>
> | m m2 |
>
> m := ColorPanel open.
> m2 := m submorphs third copy.
> m = m2 panel. "prints false; the panel is duplicated "

Yes, that is a bug, that should stay the same.

> add this method to DragWelL:
>
> veryDeepInner: deepCopier
>   super veryDeepInner: deepCopier

That seems to work.

> Another observation is that after all the text is lost,
 > if you have a Playground that is effected and try to do  > something like: 
 > (ColorPanel allInstances size.) it raises  > an error 'MessageNotUnderstood: 
 > receiver of "style:" is nil'
 > from "a GLMMorphicPharoPlaygroundRenderer actOnHighlightAndEvaluate: ann"

Yes. All editors break. That is independent of the ColorPanel, I've verified 
with the cloning of cards. I just don't know how I can safely copy a Rubric 
editor morph. Either directly, or through its textModel.

Stephan

Re: [Pharo-dev] RubAbstractTextArea copying

[Henrik Nergaard]

Hi Stephan,

I looked into the bug a bit and found something strange

| m m2 |

m := ColorPanel open.
m2 := m submorphs third copy.
m = m2 panel. "prints false; the panel is duplicated "

-

add this method to DragWelL:

veryDeepInner: deepCopier
super veryDeepInner: deepCopier

and it returns true.

Another observation is that after all the text is lost, if you have a 
Playground that is effected and try to do something like: (ColorPanel 
allInstances size.) it raises an error 'MessageNotUnderstood: receiver of 
"style:" is nil'  from "a GLMMorphicPharoPlaygroundRenderer 
actOnHighlightAndEvaluate: ann"

Hope this helps

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Stephan 
Eggermont
Sent: Friday, September 18, 2015 4:09 PM
To: pharo-dev@lists.pharo.org
Subject: [Pharo-dev] RubAbstractTextArea copying

I'm trying to understand how to copy a rubric text morph.
I don't have a 2nd implementor of #text:textStyle:textColor so how does this 
work?

RubAbstractTextArea>>text: t textStyle: s color: c textColor: tc
"Private -- for use only in morphic duplication"
self releaseParagraph.
super text: t textStyle: s color: c textColor: tc.

Re: [Pharo-dev] Nautilus class definition pane and browseAllAccessesTo

[Henrik Nergaard]

For the Rubric keybinding; changing the calls using “self model” in 
RubSmalltalkEditor>>#modelCurrentSelectedClass to call “self model 
interactionModel” instead should make the keybinding work again (at least 
changing the one to #selectedBehaviour).

Best regards,
Henrik


From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Nicolai 
Hess
Sent: Sunday, November 29, 2015 10:32 PM
To: Pharo Development List 
Subject: [Pharo-dev] Nautilus class definition pane and browseAllAccessesTo

In Nautilus class definition pane, if it shows a class definition like

Object subclass: #RBNamespace
instanceVariableNames: 'changes environment newClasses removedClasses 
changedClasses rootClasses implementorsCache sendersCache'
classVariableNames: ''
package: 'Refactoring-Core-Model'
you can select an inst var and
use cmd+shift+n to browse all accesses to this var.

I broke this behavior. ( But I find it useful and a I want it back).
The problem, Rubric needs to know the current selected class (it calls 
classOrMetaclass on the
*interaction model* (Nautilus) to find the class it searches for this inst var.
But the same method #classOrMetaclass is called by NEC, and if NEC finds a class
it trys to parse the current text as a method definition, but this panes 
contains a
class definition, not a method definition, and this yields to the strange 
completions
(case 16712) this is what I tried to fix when I broke this browseAllAccessesTo 
behavior.
Any Idea how we can get both ?
- Rubric to find the correct class for browsing inst var access
- NEC to find *no class* so it does not try to complete the inst var names.
I don't know how to solve this, I don't understand how rubric delegates this
calls (it should be possible to call #selectedBehavior or #selectedClass but it
uses some delegates
rub editing -> rub editor -> rub scrolled text model -> interaction model -> 
nautilus ui

Re: [Pharo-dev] GTDebugger not draggable with latest VM

[Henrik Nergaard]

Case 17178 added an extra check to the handling of mouse movement to use the 
result from asking the event handler by default (if the morph has an event 
handler) in the same way as other “handles” methods behaves. The default 
behaviour for Morph event handling is that if an event handler is present for a 
morphic object it is up to its class to specify which events that uses the 
event handling mechanism or not.

GLMSystemWindow>>#initialize creates an event handler for itself, which then 
causes the #handlesMouseMove: to return false since it has an event handler, 
but it does not handle #mouseMove.

One solution could be to remove GLMSystemWindow>>#initialize and implement 
#keyStroke: instead.

>>keyStroke:

super keyStroke.
self handleKeyStroke: evt.

Other possible solution could be to implement #handlesMouseMove: in 
GMLSystemWindow with the logic necessary.

Another possibility is to only return early in Morph>>#handlesMouseMove: Iff 
the event handler has an event registration for #mouseMove.

I would go with the first solution, and remove the need for an event handler 
object in GLMSystemWindow.


Best regards,
Henrik


From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Andrei 
Chis
Sent: Friday, December 4, 2015 4:31 PM
To: Pharo Development List 
Cc: Moose-related development 
Subject: Re: [Pharo-dev] GTDebugger not draggable with latest VM

Seems to happen due to the fix in issue 
17178

On Fri, Dec 4, 2015 at 4:21 PM, Andrei Chis 
> wrote:
Seems that starting with Pharo 50483 one cannot drag the 
inspector/playground/debugger.

No idea what happened.

On Fri, Dec 4, 2015 at 3:19 PM, Blondeau Vincent 
> wrote:
Hi,

I have a problem on the latest Moose6.0 image.
I was not able to open a Roassal view, I had a NativeBoost Generic failure…
So I updated the VM to last stable, and, now, the GTdebugger and the Moose 
panel are not draggable anymore…
Can somebody is able to reproduce the problem?

Thanks

Cheers,
Vincent



Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.

Re: [Pharo-dev] displayingProgress on demand

[Henrik Nergaard]

Here is my take on it.

http://smalltalkhub.com/#!/~Latsabben/GafletFremgangFremviser

Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Hernán 
Morales Durand
Sent: Tuesday, December 8, 2015 12:28 AM
To: Pharo Development List 
Subject: Re: [Pharo-dev] displayingProgress on demand

Hi Thierry

2015-12-07 14:43 GMT-03:00 Thierry Goubier 
>:
Hi Hernán,

Le 07/12/2015 18:16, Hernán Morales Durand a écrit :
Hi Sven

2015-12-06 17:34 GMT-03:00 Sven Van Caekenberghe 

>>:

There is still #do:displayingProgress:

There is Job.

In general, the collection API should not be concerned with GUI
matters, does it ?


Believe me when you're executing a large workflow processing 50Gb files
with 5 other people expecting feedback from the screen, the least of
your concerns is the purity of collection API. I don't know what other
coders do, kick your co-workers off the room? Sit to see a blank Pharo
screen?
To me the key is to have feedback from the system without having to
change your 20 iterators in a group of client classes where you NEED to
see progress.

Anyway I agree with you Collection should not have GUI dependencies,
that's the reason I took a different approach and that's why I asked
with an expression like:

SmalltalkImage setDisplayProgressTo: MyClass.

with such kind of expression you never touch the Collection API. You
just walk MyClass for every enumeration messsage send (of your interest)
and perform a transformation. Note the same "technique" could be applied
for logging and/or profiling.

Yes. The Jejak tracer uses a similar technique. I'd guess others do as well.

Will have a look to Jejak, thanks.

We can't have equivalents of all collection methods for displaying
progress, nor can it be a (semi-) global setting.


Sure, that would be the anti-object technology :)

So I implemented a prototype which injects JobProgress code in methods
using RBParseSearchTree. On uninstall I plan to recover the previous
version of marked methods. No need to touch the Collection API at all,
nor a setting. I am sure the same could be done with MethodWrappers but
RB can manipulate AST nodes.

However if there is a better idea I would love to hear about it.

Could you put your RBParseTreeRewriter scripts somewhere? I'm interested.

Ok for the first part create a FooClass>>foo: method

foo: aString

aString asFileReference entries
collect: [ : fileEntry | self openOnFileNamed: fileEntry fullName ]

this one injects a node inside the Job block:

http://ws.stfx.eu/5H7LNMMLIXEX
For the next one, first add

RBSequenceNode>>addNode: aNode after: anotherNode
| index |
index := self indexOfNode: anotherNode.
index = 0
ifTrue: [ ^ self addNode: aNode ].
statements := statements asOrderedCollection
add: aNode afterIndex: index;
yourself.
aNode parent: self.
^ aNode

but now I am failing to see how to replace #collect: with #collect:thenDo: 
using the rewriter:

http://ws.stfx.eu/MOWS947F000O
Regards,
Hernán

Re: [Pharo-dev] gtdebugger in pharo 5.0

[Henrik Nergaard]

http://ws.stfx.eu/3KXXDAJ4EUF6


-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Stephan 
Eggermont
Sent: Saturday, January 9, 2016 3:36 PM
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] gtdebugger in pharo 5.0

On 09-01-16 12:39, Dimitris Chloupis wrote:
> there has been around a script to automate the screenshots, but 
> personally I never bother using it because taking a screenshot and 
> inserting in pillar is the easiest thing.

AFAIK the hard part is keeping things up to date. That's where automation helps.

Stephan

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

[Henrik Nergaard]

Like this?
http://smalltalkhub.com/#!/~Latsabben/NumIt

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of stepharo
Sent: Thursday, December 24, 2015 9:58 AM
To: Pharo Development List 
Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

Just a remark.
I think that we discarded the proposition of having

aCol arithmetic sum

but I found it nice because there if was clear that you want to get back 
0 for #().

Stef

Re: [Pharo-dev] learning from errors....

[Henrik Nergaard]

You could use one of those images and rotate it when drawing, changing the 
angle by #step.

I attached an example.

Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Yuriy 
Tymchuk
Sent: Tuesday, November 24, 2015 7:58 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] learning from errors

Good catch.

At the time when I was developing it, the loading morph implementation was such 
a magic for me, that I was super happy after finishing it and forgot that I 
depend on Komitter.

Is there any alternative for that? Otherwise I will simply remove the spinning 
cog, I don’t feel that this is super important.


Uko

On 24 Nov 2015, at 19:51, stepharo > 
wrote:

BTW: it would be good that QA does not refer to Komitter. And package it as a 
separate project.
QA should not dependent on Komitter because we can remove Komitter. And it 
makes no sense!



hn-HenrikNergaard.1.mcz
Description: hn-HenrikNergaard.1.mcz

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

[Henrik Nergaard]

If the prefix is renamed would it be possible to include a delimiter symbol 
between whatever prefix name and the object name? (for example underscore). 
Then one could change the how a class is viewed in a simple manner (see 
attached example).


Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Esteban 
Lorenzano
Sent: Wednesday, January 13, 2016 11:33 AM
To: Pharo Development List 
Subject: Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

So, recapitulation:

I want to introduce:

1) package renaming, from FFI-NB to UnifiedFFI
2) prefix renaming, from FFI to UFFI (I will not change method prefix, they 
will remain ffi* so this is maybe a problem…)
3) method renaming, from ffiLibraryName to ffiLibrary (we didn’t talk about 
this, but I’m introducing it because is better name :P)

I *think* #2 can be skipped, but #1 and #3 are a must.

opinions?

Esteban

On 13 Jan 2016, at 11:28, Esteban Lorenzano 
> wrote:


On 13 Jan 2016, at 03:46, Ben Coman 
> wrote:


Le 12/1/16 17:58, Denis Kudriashov a écrit :

Hi

UFFI reminds me UFO which can be translated like Unified Foreign Objects.
And objects outside image look really like unidentified flying objects. It's 
just address, blob of bytes and they fly outside smalltalk world
And it has some relation to Alien name.
But maybe it is too much funny name

I guess we are considering...

Prefix: UFO   (shorter)
Package: Unified Foreign Objects(longer)

Prefix: UFFI   (longer)
Package: UnifiedFFI(shorter)

I like your thinking, but I have mixed feelings.  Name is cool.  The
shorter prefix may be a benefit (though the "I" doesn't add much).
But it implies more semantics as an external "object" than external
blobs of memory (for example) for C libraries.
I like "Unified" because it brings together parts of several
implementations (if I understand correctly) and fixes a point of
divergence at the VM level making it harder for limited resources to
collaborate there.
So in the end I think I prefer Unified.

yes, I suppose you are right.
but I was not considering changing prefix from FFI to UFFI, just repackaging as 
UnifiedFFI :P

now… probably I will do it (not many changes to adapt and probably better for 
understanding in the long way).



cheers -ben

P.S.  As I understand it, NativeBoost performs a bit better than
UnifiedFFI, but it hindered cross-architecture compatibility - but
UnifiedFFI essentially keeps the NativeBoost syntax - so I wonder if
its technically feasible for NativeBoost to become a plug-in backend
for UnifiedFFI, that could be used is special circumstances that
super-performance is required only on supported platforms?

actually (though I do not test it since a couple of months) it should be more 
or less compatible… it was at the beginning, then I made some changes…
what is not compatible anymore is the vm who needs to be changed to use 
executable memory.

Also… yes, NativeBoost is faster (callouts, not callbacks) because you cannot 
compete with ASM, but you can compite in activation time and optimised code… so 
who knows, in the future that advantage can not exist anymore.

cheers,
Esteban







2016-01-12 16:55 GMT+01:00 Esteban Lorenzano 
>:


Hi,

People has pointed (and they are right) that the name of the new FFI
front-end is misleading.
So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for
short) is a better name… and to keep packages prox. to regular FFI I was
thinking on rename FFI-NB packages to FFI-Unified… but maybe is better just
to rename them as UFFI or UnifiedFFI…
what do you think?

Esteban

Re: [Pharo-dev] GT-Spotter dive in shortcut

[Henrik Nergaard]

IIRC the shortcut is not changed, it still is meta+right(+shift). Only the 
tooltip was changed to display the system specific key instead of “cmd” so for 
Windows/Linux this would be “ctrl”.

Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Nicolai 
Hess
Sent: Tuesday, June 7, 2016 12:56 PM
To: Pharo Development List 
Subject: [Pharo-dev] GT-Spotter dive in shortcut

Why did the shortcut for dive-in element/category changed from
cmd+right
cmd+shift+right
to

ctrl+right
ctrl+shift+right
I know there were some discussions about this and that the behavior changed some
time ago, but I don't know the rational behind this.

thanks
nicolai

Re: [Pharo-dev] Smalltalk ui icons vs iconNamed: vs @

[Henrik Nergaard]

What about 

Symbol >>#asIcon

   ^ Smalltalk ui icons iconNamed: self 

Then one can do: "#add asIcon" ?

Best regards,
Henrik


-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Peter 
Uhnak
Sent: Monday, May 30, 2016 4:34 PM
To: Pharo Development List 
Subject: [Pharo-dev] Smalltalk ui icons vs iconNamed: vs @

Hi,

My understanding is that now instead of

Smalltalk ui icons smallConfigurationIcon

I should do

Smalltalk ui iconNamed: #smallConfigurationIcon

This is however really unpractical, because it changes the operator priority, 
so I have to wrap it in parentheses every single time.

Button new
icon: (... iconNamed: ...)

How about we add '@' or another binary selector so we can avoid the parentheses?

Peter

Re: [Pharo-dev] 17348 Enhance shortcut learnability

[Henrik Nergaard]

Somehow it integrated

__
Name: SLICE-Issue-17348-Enhance-shortcut-learnability-tr.2
Author: tr
Time: 8 January 2016, 4:18:55.135106 pm
UUID: 0aa30f76-84f3-0449-acde-172e56ea3615
Ancestors: SLICE-Issue-17348-Enhance-shortcut-learnability-tr.1
Dependencies: Morphic-Base-tr.526

better version


instead of:


Name: SLICE-Issue-17348-Enhance-shortcut-learnability-HenrikNergaard.2
Author: HenrikNergaard
Time: 8 January 2016, 11:01:18.490743 pm
UUID: 2a6f1c3f-a0b3-524d-9095-02fb42ab8358
Ancestors: SLICE-Issue-17348-Enhance-shortcut-learnability-tr.1
Dependencies: Morphic-Base-HenrikNergaard.526

Refactor of initial code.

I have updated and merged a new slice (in Image 50521) which should fix it. The 
correct version that should be integrated is:

Name: SLICE-Issue-17348-Enhance-shortcut-learnability-HenrikNergaard.5
Author: HenrikNergaard
Time: 11 January 2016, 12:17:08.504781 am
UUID: f0271c17-07a7-0d4e-a6eb-d2fef9b2853c
Ancestors: SLICE-Issue-17348-Enhance-shortcut-learnability-HenrikNergaard.4
Dependencies: Morphic-Base-HenrikNergaard.530

remove unused variable.



Best regards,
Henrik


From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Marcus 
Denker
Sent: Monday, January 11, 2016 11:35 AM
To: Pharo Development List 
Subject: Re: [Pharo-dev] 17348 Enhance shortcut learnability

Hello,

I wil reopen the issue and put your comment there.

Marcus

On 11 Jan 2016, at 09:56, Nicolai Hess 
> wrote:

Can please someone translate / change the text in the
Shortcut reminder Morph settings.( that got integrated in 50521)

see my comment on
https://pharo.fogbugz.com/f/cases/17348/Enhance-shortcut-learnability#BugEvent.149326
and I asked for resubmitting  the changes with proper author initials
instead of "tr" and if he signed the license agreement.
Anyone knows more about "tr" ?
And I am not sure if the right version is integrated.

nicolai

Re: [Pharo-dev] Growl setting name

[Henrik Nergaard]

NotificationMorph | NotifierMorph | InformationMorph ?

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Tudor 
Girba
Sent: Friday, January 15, 2016 10:21 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] Growl setting name

Hi

I think it should not be named “dialog” and “popup” is too generic.

How about “PopupInfo”?

Doru


> On Jan 15, 2016, at 10:11 PM, Ferlicot D. Cyril  
> wrote:
> 
> Apparently "Growl" is the name of Mac notification. But me, that never 
> used Mac, I don't know that. I think I am not the only one in that case.
> 
> If it's not just my ignorance, I propose to rename "Growl" as "Popup 
> dialog" or "Popup" or "Popup dialog/Growl".
> 
> What do you thing guys ?
> If you think as me I will open an issue.
> 
> --
> Cyril Ferlicot
> 
> http://www.synectique.eu
> 
> 165 Avenue Bretagne
> Lille 59000 France
> 

--
www.tudorgirba.com
www.feenk.com

"Every now and then stop and ask yourself if the war you're fighting is the 
right one."

Re: [Pharo-dev] Growl setting name

[Henrik Nergaard]

The underlying class and implementation relies on Morph and since it is also a 
subclass of Morph, should end with the Morph postfix.
Had the implementation used Bloc or similar I would expect it to be named 
...Bloc or ...Brick to signal this. 

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
Ferlicot D. Cyril
Sent: Friday, January 15, 2016 10:32 PM
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] Growl setting name

Le 15/01/2016 22:25, Henrik Nergaard a écrit :
> NotificationMorph | NotifierMorph | InformationMorph ?
> 
> Best regards,
> Henrik
> 

Since Morph will be replace by Bloc I don't know if it's wise to name things 
with "Morph".

--
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France

Re: [Pharo-dev] Bug in protocol and method selection

[Henrik Nergaard]

Hi Stef,

Do the error still happen if you merge:

Name: Morphic-Widgets-FastTable-HenrikNergaard.148
Author: HenrikNergaard
Time: 13 January 2016, 3:40:48.807358 pm
UUID: b807ebde-ad62-ce41-977a-e6cdce230e93
Ancestors: Morphic-Widgets-FastTable-CyrilFerlicot.147

?

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Yuriy 
Tymchuk
Sent: Thursday, January 14, 2016 1:43 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] Bug in protocol and method selection

Stef,

I cannot see the issue, moreover there were no changes in QA that touch 
Nautilus.

Maybe this is because of FastTable highlighting: when you hover over a selected 
list item, it changes color to the hover color, so when you select an item you 
cannot see the you selected it because you see the tower color. This was 
already fixed, but not yes integrated.

Uko

> On 14 Jan 2016, at 13:33, Yuriy Tymchuk  wrote:
> 
> I will take a look. Just to make sure: this is not the FT coloring thing, 
> right?
> 
> Uko
> 
>> On 14 Jan 2016, at 13:06, stepharo  wrote:
>> 
>> Hi
>> 
>> There is a problem in latest Pharo. I cannot select (and keep the 
>> selection selected) of a method and method protocol.
>> To me it looks like QA is interferring but I do not know.
>> This is the kind of glitches that can kill our effort doing videos. 
>> We have a strong deadline for producing such videos. beginning of 
>> march but we want to get done before any help is welcome.
>> 
>> Stef
>> 
> 
> 

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

[Henrik Nergaard]

Removing
#(IRPrinterV2 #(visitStoreTemp: visitStoreRemoteTemp: 
visitPopIntoLiteralVariable: visitPushTemp: visitReturnLiteral: 
visitStoreInstVar: visitStoreLiteralVariable: visitPushLiteralVariable: 
visitPushInstVar: visitJump: visitPushLiteral: label: visitPushArray: 
visitPopIntoTemp: visitReturnInstVar: visitPopIntoRemoteTemp: visitTempVector: 
visitJumpIf: visitPushRemoteTemp: visitPopIntoInstVar: visitSend: ))
And it stops crashing.

- BTW, there is not crash.dmp, does it works with spur?
https://pharo.fogbugz.com/f/cases/17506/when-an-Image-crashes-a-crash-dmp-file-is-created-but-nothing-is-written-to-it-Windows

Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
Blondeau Vincent
Sent: Friday, February 5, 2016 1:54 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We 
are in "code freeze" for Pharo 5)

Very strange bug indeed that happens on windows machines that crashes the VM. I 
succeeded to reduce the problem to an evaluation of a collection…
Can someone have the same issue under Windows or Mac?

To reproduce : Copy paste the contents of the attached file in the playground 
and print it or do it
It works on pre-spur vm.

BTW, there is not crash.dmp, does it works with spur?
Vincent

De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de Marcus 
Denker
Envoyé : vendredi 5 février 2016 13:01
À : Pharo Development List
Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We 
are in "code freeze" for Pharo 5)


On 05 Feb 2016, at 12:40, Marcus Denker 
> wrote:

I will try do integrate it now…



No, it still fails.

https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/label=win/706/

The last test it executed seems to be this:

running suite: Refactoring-Tests-Environment

starting testcase: RBBrowserEnvironmentTest>>testAndEnvironment ...

Very strange...

   Marcus




Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.

Re: [Pharo-dev] Morphic magician requested. What is referencePosition?

[Henrik Nergaard]

#referencePostion returns the specified center for the morph in global 
coordinates.
By default this will be the same as “self bounds origin + (self bounds 
extent/2.0)” but can have other depending on what #rotationCenter returns.

#referencePositon: on the other hand do not set a new centre, but moves the 
morph to a new position by using the referencePosition as origin instead of its 
top left corner.

Example:


| m |

m := Morph new
   color: Color orange;
   extent: 200@72;
   openCenteredInWorld;
   yourself.

m on: #click send: #value to: [ m referencePosition: (m referencePosition + 
(10@10)) ]   .

Looking at Morph>>#handleDropMorph: referencePosition is used to place the 
dropped morph in centre of the new owner.

“
observation:
‘(self transformedFrom: anEvent hand world) globalPointToLocal: aMorph 
referencePosition’ looks incomplete as it will always be equal to just doing 
‘aMorph referencePosition’ because #transformedFrom: always returns an 
IdentityTransform where # globalPointToLocal: just returns the point given to 
it.
“

Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
Aliaksei Syrel
Sent: Wednesday, January 27, 2016 4:12 PM
To: Pharo Development List 
Subject: [Pharo-dev] Morphic magician requested. What is referencePosition?

Hi

Do anyone know what is Morph>>#referencePosition and why is it used to handle 
drag and drop?

Here is what method doc says:
"Return the current reference position of the receiver"

Thanks,
Alex

Re: [Pharo-dev] Morphic magician requested. What is referencePosition?

[Henrik Nergaard]

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Henrik 
Nergaard
Sent: Wednesday, January 27, 2016 4:47 PM
To: Pharo Development List <pharo-dev@lists.pharo.org>
Subject: Re: [Pharo-dev] Morphic magician requested. What is referencePosition?

#referencePostion returns the specified center for the morph in global 
coordinates.
By default this will be the same as “self bounds origin + (self bounds 
extent/2.0)” but can have other depending on what #rotationCenter returns.

#referencePositon: on the other hand do not set a new centre, but moves the 
morph to a new position by using the referencePosition as origin instead of its 
top left corner.

Example:


| m |

m := Morph new
   color: Color orange;
   extent: 200@72;
   openCenteredInWorld;
   yourself.

m on: #click send: #value to: [ m referencePosition: (m referencePosition + 
(10@10)) ]   .

Looking at Morph>>#handleDropMorph: referencePosition is used to place the 
dropped morph in centre of the new owner.

“
observation:
‘(self transformedFrom: anEvent hand world) globalPointToLocal: aMorph 
referencePosition’ looks incomplete as it will always be equal to just doing 
‘aMorph referencePosition’ because #transformedFrom: always returns an 
IdentityTransform where # globalPointToLocal: just returns the point given to 
it.
“

Correction:

#transformedFrom: translates the dropped morph “center” to the receiving morph 
local coordinates (local from the owning transformationMorph) if it has an 
owner which is a transformation type Morph (see implementors #tranformFrom:) .



Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
Aliaksei Syrel
Sent: Wednesday, January 27, 2016 4:12 PM
To: Pharo Development List 
<pharo-dev@lists.pharo.org<mailto:pharo-dev@lists.pharo.org>>
Subject: [Pharo-dev] Morphic magician requested. What is referencePosition?

Hi

Do anyone know what is Morph>>#referencePosition and why is it used to handle 
drag and drop?

Here is what method doc says:
"Return the current reference position of the receiver"

Thanks,
Alex

Re: [Pharo-dev] System Browser class pane strange behaviour

[Henrik Nergaard]

I think that this is the expected behaviour, keeping focus in the list after 
selecting a/another class/method.

Ps; to check out the filtering: 
Select the class ASTCache and then type RBSC

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Ben 
Coman
Sent: Wednesday, February 3, 2016 3:41 PM
To: Pharo Development List <pharo-dev@lists.pharo.org>
Subject: Re: [Pharo-dev] System Browser class pane strange behaviour

You are right. It disappears when escaping or clicking another class.

On Wed, Feb 3, 2016 at 10:20 PM, Henrik Nergaard <henrik.nerga...@uia.no> wrote:
> That looks like the search field in FastTable; Clicking on another 
> class/pressing escape should remove it. (I guess after discarding the changed 
> code the keyboard focus went to the code pane, and therefore pressing  
> opens the search field instead of typing in the code area)
>
> Best regards,
> Henrik
>
> -Original Message-
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Ben 
> Coman
> Sent: Wednesday, February 3, 2016 2:33 PM
> To: Pharo Development List <pharo-dev@lists.pharo.org>
> Subject: [Pharo-dev] System Browser class pane strange behaviour
>
> I have a talent for breaking things ;) ...
> Found some strange behaviour here...
>
> I open System Browser
> select package AST-Core
> select class ASTCache
> make code pane dirty by typing 1 in the class definition select class 
> ASTCacheReset click  button type 1
>
> --> oh! where did the buttons go? :)
>
> Bisecting finds it
>exists in... 50564, 50510, 50440, 50400, 50384, 50380, 50378
>similar but located differently... 50300, 50368, 50376,  50377
>
>still there... 50250, 50232, 50228
>not in... 50100, 50150, 50200, 50216, 50224, 50226, 50227
>
> So it looks like this was introduced in build 50228...
> * 16197 update and merge Rubric
> * 16198 Add users button in message browser
> * 16201 Remove unsent extension methods in System-Changes 
> http://forum.world.st/pharo-project-pharo-core-56107d-50228-td4842794.html
>
> and it was modified by build 50378...
> * 16751 link invalidation: install cm directly for primitives and 
> optionCompileOnLinkInstallation
> * 16729 Removing PluggableTextField from FT 
> http://forum.world.st/pharo-project-pharo-core-e8c312-50378-td4854678.html
>
> Logged https://pharo.fogbugz.com/default.asp?17520
>
> cheers -ben
>
> P.S.  thank you to those who made PharoLauncher work seemlessly with pre-spur 
> images

Re: [Pharo-dev] System Browser class pane strange behaviour

[Henrik Nergaard]

That looks like the search field in FastTable; Clicking on another 
class/pressing escape should remove it. (I guess after discarding the changed 
code the keyboard focus went to the code pane, and therefore pressing  
opens the search field instead of typing in the code area)

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Ben 
Coman
Sent: Wednesday, February 3, 2016 2:33 PM
To: Pharo Development List 
Subject: [Pharo-dev] System Browser class pane strange behaviour

I have a talent for breaking things ;) ...
Found some strange behaviour here...

I open System Browser
select package AST-Core
select class ASTCache
make code pane dirty by typing 1 in the class definition select class 
ASTCacheReset click  button type 1

--> oh! where did the buttons go? :)

Bisecting finds it
   exists in... 50564, 50510, 50440, 50400, 50384, 50380, 50378
   similar but located differently... 50300, 50368, 50376,  50377

   still there... 50250, 50232, 50228
   not in... 50100, 50150, 50200, 50216, 50224, 50226, 50227

So it looks like this was introduced in build 50228...
* 16197 update and merge Rubric
* 16198 Add users button in message browser
* 16201 Remove unsent extension methods in System-Changes 
http://forum.world.st/pharo-project-pharo-core-56107d-50228-td4842794.html

and it was modified by build 50378...
* 16751 link invalidation: install cm directly for primitives and 
optionCompileOnLinkInstallation
* 16729 Removing PluggableTextField from FT 
http://forum.world.st/pharo-project-pharo-core-e8c312-50378-td4854678.html

Logged https://pharo.fogbugz.com/default.asp?17520

cheers -ben

P.S.  thank you to those who made PharoLauncher work seemlessly with pre-spur 
images

Re: [Pharo-dev] 50603 highlighting broken

[Henrik Nergaard]

Caused by:
Build 50601

16020 Syntax Highlighting Rubric: First shows non-highlighted text, then color. 
Looks slow

   https://pharo.fogbugz.com/f/cases/16020


From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Nicolai 
Hess
Sent: Tuesday, February 23, 2016 2:41 PM
To: Pharo Development List 
Subject: [Pharo-dev] 50603 highlighting broken

in pharo 50603, if you open a sendersOf MessageBrowser, the first selected
methods code is not or wrongly highlightey (all red).
You have to change the selected item to get the right result!

Re: [Pharo-dev] Bad layoutFrame>>#hash

[Henrik Nergaard]

What about something like this?


^self species hash hashComposer
add: leftFraction;
add: leftOffset;
add: topFraction;
add: topOffset;
add: rightOffset;
add: bottomFraction;
add: bottomOffset

HashComposer>>#add: anObject

^hash := (hash + anObject hash) hashMultiply


Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Stephan 
Eggermont
Sent: Wednesday, January 13, 2016 8:34 PM
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] Bad layoutFrame>>#hash

On 13-01-16 18:38, David Allouche wrote:
> Why did you use a single expression instead of using a temporary variable? I 
> find it harder to understand.

I did find it very slightly easier to understand. It is not a strong opinion 
however.

The ideomatic smalltalk would be

^#(leftFraction leftOffset topFraction topOffset rightFraction rightOffset 
bottomFraction bottomOffset)
inject: self species hash into: [:hashValue :selector |
(hashValue + self perform: selector) hashMultiply ]

but that would be slower.

I would be tempted to add a binary message

Integer>>+** aNumber
^(aNumber +self hash) hashMultiply

(I'd prefer +#*, but that doesn't parse)

hash
^self species hash +**
leftFraction +** leftOffset +**
topFraction +** topOffset +**
rightFraction +** rightOffset +**
bottomFraction +** bottomOffset



Stephan

Re: [Pharo-dev] why spotter shows up when I type enter in the inputfield of the finder?

[Henrik Nergaard]

>Except shift-enter in Finder input field still brings up Spotter.
Spotter is a global key-bind meaning that any user of km-dispatcher 
will by default bring up spotter on shift-enter...
Perhaps it would be better to move this to those that actually uses it; 
in the WorldMorph bring up the default spotter, in Nautilus bring up a spotter 
with entries based on the context,  etc..?

Forking it shows the expected result, but the input fetcher is running its own 
thread so this information should be available even though the UI is blocked by 
the wait ?

[2 seconds wait.
InputEventSensor default shiftPressed logCr ] fork.


Delay delaySchedulerClass. " DelayMicrosecondScheduler "
Should not one of the experimental ones be the default scheduler class? 
https://pharo.fogbugz.com/f/cases/13756/Delay-scheduling-deadlock.
"Delay initialize" sets the default one to DelayMicrosecondScheduler, and I 
guess it was re-initialized for the new session manager.

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Ben 
Coman
Sent: Monday, February 15, 2016 12:39 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] why spotter shows up when I type enter in the 
inputfield of the finder?

On Mon, Feb 15, 2016 at 5:48 PM, stepharo  wrote:
> Hi guys
>
> you cannot imagine the amount of energy I'm losing because of the flux 
> of the tools.
> why spotter shows up when I type enter in the inputfield of the finder?
> Is it on purpose?
> This is 5 times that I'm redoing a videos for the mooc. :(

I can't make this happen in 50581 - 32-bit Linux.
Except shift-enter in Finder input field still brings up Spotter.
My first thought is maybe your shift key is somehow stuck.


An aside:
I thought to check behaviour by holding  after evaluating...
2 second wait.
InputEventSensor default shiftPressed inspect

but inspector shows false.  Is this expected?
cheers -ben

Re: [Pharo-dev] GTSUnitDebugger MNU receiver of "paneNamed:" is nil

[Henrik Nergaard]

https://pharo.fogbugz.com/f/cases/17653/GTSpecPreDebugWindow-initializeStackPane-GTSUnitDebugger-MNU-reciever-of-paneNamed-is-nil


-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Ben 
Coman
Sent: Friday, February 19, 2016 6:52 PM
To: Pharo Development List 
Subject: [Pharo-dev] GTSUnitDebugger MNU receiver of "paneNamed:" is nil

I'll follow up logged an issue soon, but just a quick note while I'm in the 
flow on something else...

1. Pick an existing test method e.g. AST-Tests-Core > NumberParserTest
> testFail
2. Insert an error like 1/0.
3. Run test from System Browser by clicking on the method's circular icon
4. Click on top of stack "SmallInteger   /"
 --> MessageNotUnderstood: receiver of "paneNamed:" is nil

At step 3, instead clicking  works okay.

cheers -ben

Re: [Pharo-dev] MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules

[Henrik Nergaard]

The issue should be unrelated:

https://pharo.fogbugz.com/f/cases/17616/CI-Server-Failing-tests-related-to-Traits-Polymorphism

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Sven 
Van Caekenberghe
Sent: Saturday, February 20, 2016 11:05 AM
To: Pharo Development List 
Subject: [Pharo-dev] 
MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules

Hi,

I am trying to load a new version of STON in Pharo 5

https://pharo.fogbugz.com/f/cases/16893/Update-STON

One of the tests that fails is 
MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules

More specifically, (Metaclass localSelectors difference: ClassTrait 
localSelectors) is no longer equal to the exceptions defined in the test 
because #stonName and #stonOn: were added to Metaclass

What should I do ? Did I do something wrong ?

Should I add to the exceptions defined in the test or should I add them to 
ClassTrait ?

I think the first sounds the most correct.

Thx,

Sven

Re: [Pharo-dev] MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules

[Henrik Nergaard]

Ah, test testMetaclass. Somehow I only read testClass 

Moving those two methods from Metaclass to TApplyingOnClassSide should make the 
test happy.

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Sven 
Van Caekenberghe
Sent: Saturday, February 20, 2016 11:58 AM
To: Pharo Development List <pharo-dev@lists.pharo.org>
Subject: Re: [Pharo-dev] 
MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules

If I add (in #50591) my methods to the exception set in the middle, the test is 
green

self
assert:
(Metaclass localSelectors difference: ClassTrait 
localSelectors)
=
{#externalTypeAlias:.
#baseClass.
#basicLocalSelectors:.
#basicLocalSelectors.
#classClass.
#isClass.
#stonName. "<<<"
#stonOn:.  "<<<"
#environment.
#fileOutOn:.
#fileOutOn:initializing:.
#postCopy.
#traitComposition.
#traitComposition:.
#veryDeepCopyWith:} asSet.

I don't know about the other failures.

> On 20 Feb 2016, at 11:37, Henrik Nergaard <henrik.nerga...@uia.no> wrote:
> 
> The issue should be unrelated:
> 
> https://pharo.fogbugz.com/f/cases/17616/CI-Server-Failing-tests-related-to-Traits-Polymorphism
> 
> Best regards,
> Henrik
> 
> -Original Message-
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Sven 
> Van Caekenberghe
> Sent: Saturday, February 20, 2016 11:05 AM
> To: Pharo Development List <pharo-dev@lists.pharo.org>
> Subject: [Pharo-dev] 
> MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules
> 
> Hi,
> 
> I am trying to load a new version of STON in Pharo 5
> 
> https://pharo.fogbugz.com/f/cases/16893/Update-STON
> 
> One of the tests that fails is 
> MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules
> 
> More specifically, (Metaclass localSelectors difference: ClassTrait 
> localSelectors) is no longer equal to the exceptions defined in the test 
> because #stonName and #stonOn: were added to Metaclass
> 
> What should I do ? Did I do something wrong ?
> 
> Should I add to the exceptions defined in the test or should I add them to 
> ClassTrait ?
> 
> I think the first sounds the most correct.
> 
> Thx,
> 
> Sven
> 
> 

Re: [Pharo-dev] feedback from yet another student presentation

[Henrik Nergaard]

And changed back again because it is two different cases ;).

Case 7241 is about removing the instance side method #name , which gives you a 
generic name of the receiver (by default #printString) where any if its uses is 
such that it is really hard to use it for anything like defining a variable 
named name wanting to have an accessor to it, since most senders expect a 
string in return etc.

The issue raised here is about the fragile naming of the instance variable 
'name' in the class Class, which causes all meta classes to have an "class 
side" instance variable name (view the class side of any class in nautilus and 
click on the variables button and you can see all the class side variables 
defined)  + the methods #name/#name:  on the class side of any class. 

This can cause some fun behaviour like crashing the image if you set the name 
to anything but a symbol -> "TabsExample name: TabsExample new"

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of monty
Sent: Thursday, March 10, 2016 10:35 PM
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] feedback from yet another student presentation

> Sent: Thursday, March 10, 2016 at 4:14 PM
> From: "Alexandre Bergel" 
> To: "Pharo Development List" 
> Subject: Re: [Pharo-dev] feedback from yet another student 
> presentation
>
> > - it was realy hard to register a project on smalltalkhub just after we 
> > created an account.
> > This already happened to me during the open-devs.
> > So this is a really big show stopper for the mooc. Because people 
> > will gave up just after the first lecture :(
> 
> The situation will be much easier I hope once git is well supported…
> 
> > - we should really rename Class>>name: into setClassName:
> > students were manipulating object with name such as state of state 
> > machine and one wrote
> > 
> > State name: 'A' and just rename the class and broke the system.
> 
> I have just created an issue:
> https://pharo.fogbugz.com/f/cases/17798/Rename-Class-name-into-setClas
> sName

Marked as a duplicate of: 
https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed

This has been an issue for years.

Leave it as-is and anyone defining a class-side name: constructor risks 
breaking any tooling that still relies on name: renaming a class. Use named: 
(much more common in the image) instead and nothing will break, but now anyone 
that mistypes the selector as name: (no "d") accidentally renames the class, 
and to a string instead of a symbol.

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

Re: [Pharo-dev] Comparison of actual and expected Delay length on small durations

[Henrik Nergaard]

The numbers in that csv from is in float, but with the fraction part is 0.

This is most likely caused by the fact that the precision for timing is in 
milliseconds, not microseconds.
Even the #primUTCMicrosecondsClock only updates per millisecond for me. 
(Windows).

((1 to: 10) collect: [:n | Time primUTCMicrosecondsClock ] as: Set) asArray 
sort. “for me each entry is increased by 1000”


Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
Aliaksei Syrel
Sent: Saturday, March 12, 2016 9:01 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] Comparison of actual and expected Delay length on 
small durations

I get a BoxedFloat64(61.5)

Very strange...

For some unexpected reason you get integers in delay test. But all values 
should be floats. I double checked the script..

There is a difference in arithmetic behaviour between mac and windows!

Cheers,
Alex

On Sat, Mar 12, 2016 at 8:48 PM, Cyril Ferlicot D. 
> wrote:
Le 12/03/2016 20:44, Aliaksei Syrel a écrit :
> I think  we just found a serious bug!
>
> Cyrill, could you perform a division in the same image you used for
> delay test and post result here?
>
> 123 / 2.0
>

I get a BoxedFloat64(61.5)

--
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France

Re: [Pharo-dev] How to set styler for RubEditingArea?

[Henrik Nergaard]

There is no way of doing that, RubParagraphDecorator lacks a method to set its 
style variable.

If you add that, then you can do something like:
Self is a RubEditingArea

(self decoratorNamed:  #shoutStyler) style: yourStyleclass new.

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Yuriy 
Tymchuk
Sent: Saturday, March 19, 2016 1:19 AM
To: Pharo Development List 
Subject: [Pharo-dev] How to set styler for RubEditingArea?

Hi, I have my own styler which is a subclass of SHRBTextStyler. How do I set it 
as a styler for RubEditingArea?

Cheers.
Uko

Re: [Pharo-dev] How to set styler for RubEditingArea?

[Henrik Nergaard]

Correction, I forgot some r's

There is no way of doing that, RubParagraphDecorator lacks a method to set its 
styler variable.

If you add that, then you can do something like:
Self is a RubEditingArea

(self decoratorNamed:  #shoutStyler) styler: yourStyleclass new.

styler: aTextStyler

  styler := aTextStyler.
  styler view: self. 


Best regards,
Henrik


-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Henrik 
Nergaard
Sent: Saturday, March 19, 2016 11:00 AM
To: Pharo Development List <pharo-dev@lists.pharo.org>
Subject: Re: [Pharo-dev] How to set styler for RubEditingArea?

There is no way of doing that, RubParagraphDecorator lacks a method to set its 
style variable.

If you add that, then you can do something like:
Self is a RubEditingArea

(self decoratorNamed:  #shoutStyler) style: yourStyleclass new.

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Yuriy 
Tymchuk
Sent: Saturday, March 19, 2016 1:19 AM
To: Pharo Development List <pharo-dev@lists.pharo.org>
Subject: [Pharo-dev] How to set styler for RubEditingArea?

Hi, I have my own styler which is a subclass of SHRBTextStyler. How do I set it 
as a styler for RubEditingArea?

Cheers.
Uko

Re: [Pharo-dev] TxText model

[Henrik Nergaard]

The only thing required for styling is to specify the attributes for the runs 
associated with the text.
A simple example:

| text attributes oldRuns clr|

text := (String loremIpsum: 1234) asText.

attributes := Array new: text size.

clr := TextColor color: Color random.

1 to: text size do: [ :index |
   attributes at: index put: {
  clr.
  TextFontChange font2
   }.

   (text at: index) isSeparator ifTrue: [ clr := TextColor color: 
Color random ]
].

text runs: (RunArray newFrom: attributes).

text


Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Nicolai 
Hess
Sent: Wednesday, April 6, 2016 8:23 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] TxText model



2016-04-06 18:11 GMT+02:00 p...@highoctane.be 
>:
Ok. Call me stupid but in Pharo I don't see how to do that easily.

Phil

At least for Rubric, it can not be that difficult. I saw a GT-Inspector with a 
XML-styer


On Wed, Apr 6, 2016 at 5:41 PM, Stephan Eggermont 
> wrote:
On 06-04-16 11:13, p...@highoctane.be wrote:
Another pain is the styling of text where the only styler we have is the 
SHSt80Styler (class name out of my mind, need to check) and that's a huge pain 
to support other stylings.

Styling with different stylers worked in TextMorph. In Squeak it is easy
to add styling for a different language in the class browser. Levente did
that for PostgreSQLv3.

Stephan

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

[Henrik Nergaard]

Hi Sven,

Instead of: 

stonProcessSubObjects: block
| didContainStonReferenceAsKey |
didContainStonReferenceAsKey := self stonProcessSubObjects: block

super stonProcessSubObjects: block.

self isHealthy ifFalse: [ self rehash ]..
super stonProcessSubObjects: block.
didContainStonReferenceAsKey
ifTrue: [ self rehash ]


One can do:

stonProcessSubObjects: block

super stonProcessSubObjects: block.

 self isHealthy ifFalse: [ self rehash ].


And this could also be moved to HashedCollection as a generic solution for any 
hash based collection. Moving it there would require implementing #isHealthy as 
a subclass responsibility. (all current subclasses (Set, Dictionary) implements 
it). 

What do you think?

Best regards,
Henrik


-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Sven 
Van Caekenberghe
Sent: Wednesday, April 6, 2016 2:27 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a 
dictionary if the keys are references

Fix for review:

===
Name: STON-Core-SvenVanCaekenberghe.71
Author: SvenVanCaekenberghe
Time: 6 April 2016, 2:22:24.782251 pm
UUID: 64b8b741-365e-41fe-aa98-565e33ca5d24
Ancestors: STON-Core-SvenVanCaekenberghe.70

Fix a bug where STONReferences occurring as keys in Dictionaries or elements in 
Sets caused those to be unhealthy after materialization. Thx to Peter Uhnák for 
reporting this issue.

Add 3 new unit tests to STONReaderTests

#testDictionaryWithReferenceKeys
#testSetWithReferenceElements
#testDeepStructure

Fix Details

change the implementation of STONReader>>#processSubObjectsOf: from iterative 
to recursive (see version 39 of 29 November 2012, this might be a functional 
regression, see #testDeepStructure; cleanup of stack instance variable for 
later) so that #stonProcessSubObjects: can be overwritten with code being 
executed before or after full reference resolution

imho, recursion stack depth will be equal during both writing and reading, and 
should be acceptable.

overwrite #stonProcessSubObjects: in Dictionary and Set to #rehash at the end, 
but only when needed (minimal optimalization, see 
Dictionary>>#containsStonReferenceAsKey and Set>>#containsStonReference) ===
Name: STON-Tests-SvenVanCaekenberghe.63
Author: SvenVanCaekenberghe
Time: 6 April 2016, 2:22:45.01986 pm
UUID: 0beb2322-b81a-46ee-a0e2-6648a808774a
Ancestors: STON-Tests-SvenVanCaekenberghe.62

(idem)
===

> On 06 Apr 2016, at 14:04, Sven Van Caekenberghe  wrote:
> 
> https://pharo.fogbugz.com/f/cases/17946/STON-materializes-unhealthy-Di
> ctionaries-and-Sets-when-references-occur-in-its-keys-or-elements
> 
> fix coming
> 
>> On 05 Apr 2016, at 13:11, Sven Van Caekenberghe  wrote:
>> 
>>> 
>>> On 05 Apr 2016, at 13:02, Nicolai Hess  wrote:
>>> 
>>> 
>>> 
>>> 2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque 
>>> :
>>> 
>>> 
>>> On 05/04/2016 12:09, Sven Van Caekenberghe wrote:
>>> 
 Like I said, it is a hashing issue, sometimes it will be correct by 
 accident.
 
 I hope you did not have to much trouble with this bug, I guess it must 
 have been hard to chase.
 
 Is it urgent ?
 
 I probably can give you a quick fix, but I would like to think a bit more 
 about this, since rehashing each materialised dictionary seems expensive.
 
 
 
>>> 
>>> Hi Sven,
>>> 
>>> I got the same kind of problem in a personal application.
>>> 
>>> I use Sets that I serialize and I had a lot of trouble because 
>>> sometimes some action had strange behaviours.
>>> 
>>> For example in a set with element `aSet remove: aSet anyOne` raised 
>>> 'XXX not found in aSet'.
>>> 
>>> I am glad to hear that it is a Ston issue and not me that used sets 
>>> in a bad way :)
>>> 
>>> For me too it is not urgent since I have a not of university work 
>>> for the moment.
>>> 
>>> 
>>> 
>>> How are hashed collections created/filled during ston-parsing ?
>>> If the position in a hashed collection is created by a 
>>> ston-reference, that is later replaced by the "real" object, the index in 
>>> the dictionary  (or other hashed collections) may be wrong.
>> 
>> Yes, that is indeed it, Nicolai. 
>> 
>> But I would like to try to minimise the rehashing as it seems expensive. But 
>> first I need a more reliable failure.
>> 
>>> --
>>> Cyril Ferlicot
>>> 
>>> http://www.synectique.eu
>>> 
>>> 165 Avenue Bretagne
>>> Lille 59000 France
> 

Re: [Pharo-dev] How to set styler for RubEditingArea?

[Henrik Nergaard]

That is probably done by using GLMHighlighterTextStylerDecorator which includes 
#styler: , but I guess you have to also use GLMRubircSMalltalkTextModel and 
perhaps also some other things then.

Anyways I added a new configuration of rubric (2.12) which adds #styler: to 
RubShoutStylerDecorator and some other stuff.

Best regards,
Henrik


From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Nicolai 
Hess
Sent: Saturday, March 19, 2016 12:24 PM
To: Pharo Development List <pharo-dev@lists.pharo.org>
Subject: Re: [Pharo-dev] How to set styler for RubEditingArea?


Isn't there a xml.-Styler in Moose? How is that implemented?
Am 19.03.2016 11:28 vorm. schrieb "Stephan Eggermont" 
<step...@stack.nl<mailto:step...@stack.nl>>:
On 19-03-16 10:59, Henrik Nergaard wrote:
There is no way of doing that, RubParagraphDecorator lacks a method to set its 
style variable.

If you add that, then you can do something like:
Self is a RubEditingArea

(self decoratorNamed:  #shoutStyler) style: yourStyleclass new.

I'm strongly in favor of adding this. There are other languages I want to style 
than smalltalk.

Stephan

Re: [Pharo-dev] Receiving notification of theme changes or changes to syntax highlighting properties

[Henrik Nergaard]

themeChanged is the hook method which is called from World and then by default 
recursively traverses the tree. 
If you have anything in a morph which is theming dependent, then this method 
should be implemented.
Currently it is the morphs job to update its other parts when the theme changed 
(non morph objects which is theming dependent), using an announcement for this 
would mean that one has to subscribe to a global which brings its own set of 
problems.
 
ConfigurationOfRubric 2.12 includes support for themeChanged which will reapply 
the syntaxHighlighting as well.


Since each textStyler object has a reference to its view one could use that to 
update them when the styleTable is changed:

SHTextStylerST80 >>#StyleTableChanged

 self allSubInstancesDo: [ :i |
i view themeChanged
]


Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of monty
Sent: Sunday, March 20, 2016 6:53 AM
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] Receiving notification of theme changes or changes to 
syntax highlighting properties

Yeah, I saw themeChanged, but what about non-morphs? How do they get notified? 
There should be some announcement that you can subscribe to. Should I add one?

> Sent: Saturday, March 19, 2016 at 10:20 PM
> From: "Cyril Ferlicot Delbecque" 
> To: pharo-dev@lists.pharo.org
> Subject: Re: [Pharo-dev] Receiving notification of theme changes or 
> changes to syntax highlighting properties
>
> 
> 
> On 20/03/2016 03:12, monty wrote:
> > How can you receive notification of a theme change (like going to or from 
> > the Dark theme), or even better, notification of a change to some property 
> > of syntax highlighting (like the styling used for string literals)?
> >
> 
> Hi,
> 
> For the theme change part, morphs should implement a #themeChanged 
> method that should update the colours and send the method to his submorphs.
> 
> 
> > And what is the preferred way of querying the current syntax highlighting 
> > properties? I am using "SHTextStylerST80 new attributesFor: aProperty" now 
> > (SHPreferences doesn't provide enough), but there is talk of Shout being 
> > removed.
> > 
> 
> --
> Cyril Ferlicot
> 
> http://www.synectique.eu
> 
> 165 Avenue Bretagne
> Lille 59000 France
> 
> 

Re: [Pharo-dev] For future version of Spotter

[Henrik Nergaard]

The ShortcutReminder tool includes a button which resets parts of its state 
from the settings. The methods used for this can be found under the "settings" 
protocol on the instance side.

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Yuriy 
Tymchuk
Sent: Sunday, March 6, 2016 2:52 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] For future version of Spotter

I want to have the same thing for 

> On 06 Mar 2016, at 14:44, stepharo  wrote:
> 
> 
> 
> Le 6/3/16 11:39, Tudor Girba a écrit :
>> Hi,
>> 
>> This is on the todo list, but I would rather want to have that in settings 
>> with a button.
> 
> sure
> 
>> I did not check if this is possible yet. Does anyone know if it is?

I want to have the same thing for my stuff. Let me know if you find out how to 
do that. (Juraj was working with settings. Maybe he knows something)


Cheers.
Uko

> 
> it could be also in the help.
> Normally you do not shoot videos every day or need to get to a clean state.
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Mar 6, 2016, at 10:53 AM, stepharo  wrote:
>>> 
>>> Add a menu doing
>>> 
>>>GTSpotter cleanUp.
>>>GTSpotter dontShowPreview
>>> 
>>> Stef
>>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "Every thing should have the right to be different."
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] [bloc] shape size?

[Henrik Nergaard]

>Let me return you the question then: do you do a composition of submorphs if 
>you're trying to get a different drawOn:?

>Oh, ok, that's true FastTable does it for the selection... changing background 
>color by encapsulating a row in another Morph with the right background color.

Did, not anymore.

FTTableRowMorph>>#selectionColor: 

Best regards,
Henrik

Re: [Pharo-dev] [bloc] shape size?

[Henrik Nergaard]

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Thierry 
Goubier
Sent: Sunday, April 3, 2016 9:52 PM
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] [bloc] shape size?

Hi Henrik,

Le 03/04/2016 21:32, Henrik Nergaard a écrit :
> I changed it mostly because it was messing up the color when you did 
> mouse-over (required to check the owner color to set it correctly when 
> there was a selection, the code was ugly and with corner cases).

Ok.

> Encapsulating a morph with another morph just for a background color 
> is kind of waste IMO. Causing unnecessary overhead for 
> rendering/layout/eventHandling etc...

Rendering maybe a bit. Layout, maybe a bit. Event handling? Oh well, row morphs 
contents are already a tree of morphs at least 3 deep, what will be the effect 
of one more doing nothing?

> Mesurable? Don’t think I checked, but in the long run there is less 
> allocations, less layout etc..

I guess that, given how FT works, it is hidden in the number of Morph creation 
per drawOn: :)

> I would also argue that
> --
>   (highligtedRowIndexes includes: rowIndex) ifTrue: [
>   row selectionColor: (self owner colorForSelection:
> primarySelectionIndex = rowIndex) ].
> -
> Is better than
> -
>
>   rowSubviews add: ((highligtedRowIndexes includes: rowIndex)
>   ifTrue: [
>   "IMPORTANT: I need to set owner to nil because 
> otherwise it will trigger an
>invalidation of the owner when adding morph to 
> selectionMorph, causing an
>infinite loop"
>   self
>   toSelectionRow: (row privateOwner: nil)
>   primary: primarySelectionIndex = 
> rowIndex ]
>   ifFalse: [ row ]) ].
> ---

 Selection could be and drawn by the container, but then again you 
> would need much more code and special logic (updating the 
> damageRecorder with correct rectangles when selection changes for 
> example) than to just extend and specialize one morph to be a row.

<I'm doing the selection draw by container, and, honestly, there is none of the 
complexity you describe. Selection is a model operation anyway, so it usually 
 I would much rather prefer one specialized morph doing its thing, than 
> encapsulate it.

I think the FTTableRowMorph has other duties anyway, so giving him that 
additional role is fine.

Regards,

Thierry

> Best regards,
> Henrik
>
> -Original Message-
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf 
> Of Thierry Goubier
> Sent: Sunday, April 3, 2016 8:58 PM
> To: Pharo Development List <pharo-dev@lists.pharo.org>
> Subject: Re: [Pharo-dev] [bloc] shape size?
>
> Le 03/04/2016 20:00, Henrik Nergaard a écrit :
>>
>>> Let me return you the question then: do you do a composition of 
>>> submorphs if you're trying to get a different drawOn:?
>>
>>> Oh, ok, that's true FastTable does it for the selection... changing 
>>> background color by encapsulating a row in another Morph with the 
>>> right background color.
>>
>> Did, not anymore.
>>
>> FTTableRowMorph>>#selectionColor:
>
> Had to check the following code to be sure:
>
>   (highligtedRowIndexes includes: rowIndex) ifTrue: [
>   row selectionColor: (self owner colorForSelection:
> primarySelectionIndex = rowIndex) ].
>
> Was there a measurable inpact when changing that?
>
> Because I have now three ways of doing this, and all of them have trade-offs. 
> For example the one above suppose that row items are a specific kind of 
> Morph, i.e. FTTableRowMorph; one could do without a dedicated Morph subclass 
> for rows and display the selection as a transparent colored rectangle over 
> the row; this is what I do.
>
> Thierry
>

Best regards,
Henrik

Re: [Pharo-dev] [bloc] shape size?

[Henrik Nergaard]

>A FTTableContainerMorph recreates all its submorphs on every drawOn:. 
Not correct.

Submorphs are only recreated when the view of the list has changed 
#canRefreshValues, ie if the variable "needsRefreshExposedRows" is set to true. 
 If this is false nothing will happen in #drawOn: 

If changes is necessary the drawOn: will recreate submorphs for the current 
view (showIndex) and set the "needsRefreshedExposedRows" to false signalling 
that it is correctly laid out.


Best regards,
Henrik


-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Thierry 
Goubier
Sent: Sunday, April 3, 2016 9:32 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] [bloc] shape size?

I think FastTable is something you should have a look at. Esteban did something 
really interesting there.

In FT, Submorphs are only created when they are about to be displayed: 
Pharo can easily create hundreds of morphs on every redraw cycle. So FT 
performance is O(k) where k is the number of rows to display on screen (typical 
k is ~25), and is O(1) regarding the length of the list
(almost: there is a point, for very large tree-like structures, where just 
iterating over the structure becomes the main performance
limitation: see FTTree).

A FTTableContainerMorph recreates all its submorphs on every drawOn:. 
I've played with different variants (do not recreate all submorphs, for
example) but you don't see any performance difference (on the time needed for a 
drawOn:).

Regards,

Thierry

Re: [Pharo-dev] How to set styler for RubEditingArea?

[Henrik Nergaard]

The TextModel? is not set to a specific class, so it does not understand that 
it is a method you are declaring.

The same code is red in the Playground as well.
Switch 'method: sth ^ 1' to for example: '| area | area := RubEditingArea new.'

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Yuriy 
Tymchuk
Sent: Monday, March 21, 2016 8:36 PM
To: Pharo Development List <pharo-dev@lists.pharo.org>
Subject: Re: [Pharo-dev] How to set styler for RubEditingArea?

Ok, I’m continuing my journey of styling code. And at the beginning I want to 
at least recreate the original coding area. I’ve did this and everything is red…

area := RubEditingArea new.

area
backgroundColor: Color lightGray;
updateTextWith: 'method: sth ^ 1';
textColor: Color white;
beNotWrapped;
beForSmalltalkCode;
width: 400;
withDecoratorNamed: #shoutStyler.

area shoutStyler styler: RubSHTextStylerST80 new.

area openInWorld

any idea what could possibly go wrong?
Uko




> On 20 Mar 2016, at 02:56, monty <mon...@programmer.net> wrote:
> 
> There are actually two, a highlighting parser used when you inspect files 
> from spotter, and a highlighting writer used to implement the "Tree" and 
> "Source" tabs when inspecting an already-parsed DOM tree.
>  
> 
> Sent: Saturday, March 19, 2016 at 7:24 AM
> From: "Nicolai Hess" <nicolaih...@gmail.com>
> To: "Pharo Development List" <pharo-dev@lists.pharo.org>
> Subject: Re: [Pharo-dev] How to set styler for RubEditingArea?
> Isn't there a xml.-Styler in Moose? How is that implemented?
> 
> Am 19.03.2016 11:28 vorm. schrieb "Stephan Eggermont" <step...@stack.nl>:On 
> 19-03-16 10:59, Henrik Nergaard wrote:There is no way of doing that, 
> RubParagraphDecorator lacks a method to set its style variable.
> 
> If you add that, then you can do something like:
> Self is a RubEditingArea
> 
> (self decoratorNamed:  #shoutStyler) style: yourStyleclass new.
>  
> I'm strongly in favor of adding this. There are other languages I want to 
> style than smalltalk.
> 
> Stephan
> 
>  
> 

Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5

[Henrik Nergaard]

There is a method in SourceFileArray 
#localProcessReadStreamAtFileIndex:atPosition:ifPresent:ifAbsent: which uses a 
ProccessLocalVariable called ProccessAndSessionLocalSourcesFileArray (see 
#localProcessReadOnlyCopy). Changing the last line in 
#readStreamAt:ifPresent:ifAbsent: to use this local process one makes the time 
to run this snippet:

[ 1 systemNavigation browseMethodsWithSourceString: 'Morph' matchCase: false ] 
timeProfile

From ~ 10 seconds to ~ 3 seconds (Windows).

However I cannot see that the file handles created by this processLocalVariable 
to ever be closed, so I suspect those are leaked? In that case there might be 
the need to implement some “clean up” mechanism for ProccessLocalVariables 
before they are changed/nilled when a process changes.

Another approach could be to not use a ProccessLocalVariabe at all, but extend 
the SourceFilesArray class to also hold one read only handle for each of its 
files, and use these in readStreamAtFileIndex:::… . I guess that it is also 
necessary then to have semaphore protecting the two last lines such that 
setting the position in the stream and reading from it cannot be changed by 
other threads.

readStreamAtFileIndex: index atPosition: position ifPresent: presentBlock 
ifAbsent: absentBlock

   | stream  result|
   stream := self readOnlyFileAt: index.
   stream ifNil: [ ^ absentBlock value ]."sources file not 
available"

   position > stream size ifTrue: [ ^ absentBlock value ].

   readSema critical: [
  stream position: position.
  result := presentBlock value: stream
   ].

   ^ result


Best regards,
Henrik


From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Nicolai 
Hess
Sent: Thursday, May 19, 2016 9:31 AM
To: Pharo Development List 
Subject: Re: [Pharo-dev] From a mooc user: method source with it' take so long 
in Pharo 5

Squeak caches the opened readonly file(handle). It does not have to reopen the 
file on every call for reading (readonly).

2016-05-18 19:12 GMT+02:00 stepharo >:
I am wondering why does the search 'method source with it' take so long in 
Pharo 5? On my PC, When I select the text 'menu' and search for all 'method 
source with it', in Squeak 5 it takes 3 seconds. In Pharo 5 it takes 21 seconds.

Re: [Pharo-dev] weird tales about cursors and rectangle invalidations

[Henrik Nergaard]

Hi Esteban,

To see the damage live:
SystemSettings->Tools->Debugging->Flash damaged morphic region.

Redrawing: 
Only morphs whose area is within the visible draw region of the canvas (the 
damaged area)  needs to be redrawn, so if a morph fullbounds is not 
intersecting with this area it will not be drawn, and its submorphs will not 
check deeper in this submorph hierarchy.
The exclusion is done in #fullDrawOn:  by "(aCanvas isVisible: self fullbounds) 
ifFalse: [ ^self ].
So if the cursor reports a damage rectangle only morphs intersecting with that 
area needs to be redrawn (there is also some layering mechanism IIRC so that it 
should only re-draw the visible layers in that area, and not morphs which are 
covered by their submorphs).

DamageRecorder:
The damage recorder do not know about any layering of morphs when it records 
damage. This means that if there is two overlapping windows in the World, and 
the window in the back triggers an invalid area which intersects with the 
window above, it will have to be redraw for that area as well even though it is 
not necessary.

There is also the issue where multiple small areas close to each other need 
multiple passes to be completed. If the damage recorder has damage in (10@10 
corner: 20@20) and (10@30 corner: 20@40) a morph with bounds (0@0 corner: 
50@50) will be redrawn twice during that cycle. 

Rubric:
There is some issues with how rubric handle changes, which causes blinking the 
cursor to do way to much work that it actually have to do, I think it also 
invalidates the whole selection and needs to redraw that as well.



Best regards,
Henrik


-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Esteban 
Lorenzano
Sent: Sunday, May 22, 2016 8:36 PM
To: Pharo Development List 
Subject: [Pharo-dev] weird tales about cursors and rectangle invalidations

Hi, 

I’ve been playing a bit today with something that is puzzling me and I need 
some more eyes in what I’m doing, because it might be that I’m understanding 
everything wrong… but if not, then, huston, we have a bug. 
So, play with me… you need to create this: 

SystemWindow subclass: #XSystemWindow
instanceVariableNames: 'iteration'
classVariableNames: ''
package: ‘XXX'

XSystemWindow>>initialize
super initialize.
iteration := 0.

XSystemWindow>>drawOn: aCanvas
“Do not use transcript because it does even more crazy stuff"
Stdio stdout << (iteration := iteration + 1) asString; cr; lf.
super drawOn: aCanvas


Then execute this in a playground: 

XSystemWindow new 
addMorph: (RubScrolledTextModel new newScrolledText) fullFrame: 
LayoutFrame identity;
openInWorld.

and then you can watch in your stdout how full window redraws with cursor 
blinking (it stops when window loses focus). 

This happens because cursor is displayed with lapsus of 700ms and is just a 
draw of a line with a color who is set to it’s opposite each time. Then it does 
"color: shownColor” and #color: sends #changed who finalise in #invalidRect. 
I always thought that this invalidation mechanism works by recording “damaged 
areas”, then collecting morphs with that area and triggering the redraw of that 
morph. 
With this in mind, cursor should trigger an invalidation of it’s own area (a 
small portion of the screen, as you can see). 
I could understand that a cursor triggers the text area redraw (but that would 
be a “design flaw”, IMO)… now, what I cannot understand is why blink a cursor 
triggers the redraw of a FULL WINDOW. 
When in Nautilus, that means each cursor blink triggers the redraw of one tree, 
four lists, some buttons and finally, the text area. 
IMO, this is not acceptable. 

What do you think?

Esteban

Re: [Pharo-dev] weird tales about cursors and rectangle invalidations

[Henrik Nergaard]

I thought that they were merged into a larger one.
Only if there is significant overlap between a new damage and current recorded 
damages, or if the amount of invalid rectangles size is >= 50. (see 
DamageRecorder >>#recordInvalidRect:)

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of stepharo
Sent: Sunday, May 22, 2016 9:49 PM
To: Pharo Development List <pharo-dev@lists.pharo.org>
Subject: Re: [Pharo-dev] weird tales about cursors and rectangle invalidations



Le 22/5/16 à 21:28, Henrik Nergaard a écrit :
> Hi Esteban,
>
> To see the damage live:
> SystemSettings->Tools->Debugging->Flash damaged morphic region.
>
> Redrawing:
> Only morphs whose area is within the visible draw region of the canvas (the 
> damaged area)  needs to be redrawn, so if a morph fullbounds is not 
> intersecting with this area it will not be drawn, and its submorphs will not 
> check deeper in this submorph hierarchy.
> The exclusion is done in #fullDrawOn:  by "(aCanvas isVisible: self 
> fullbounds) ifFalse: [ ^self ].
> So if the cursor reports a damage rectangle only morphs intersecting with 
> that area needs to be redrawn (there is also some layering mechanism IIRC so 
> that it should only re-draw the visible layers in that area, and not morphs 
> which are covered by their submorphs).
>
> DamageRecorder:
> The damage recorder do not know about any layering of morphs when it records 
> damage. This means that if there is two overlapping windows in the World, and 
> the window in the back triggers an invalid area which intersects with the 
> window above, it will have to be redraw for that area as well even though it 
> is not necessary.
>
> There is also the issue where multiple small areas close to each other need 
> multiple passes to be completed. If the damage recorder has damage in (10@10 
> corner: 20@20) and (10@30 corner: 20@40) a morph with bounds (0@0 corner: 
> 50@50) will be redrawn twice during that cycle.

I thought that they were merged into a larger one.
>
> Rubric:
> There is some issues with how rubric handle changes, which causes blinking 
> the cursor to do way to much work that it actually have to do, I think it 
> also invalidates the whole selection and needs to redraw that as well.
>
>
>
> Best regards,
> Henrik
>
>
> -Original Message-
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
> Esteban Lorenzano
> Sent: Sunday, May 22, 2016 8:36 PM
> To: Pharo Development List <pharo-dev@lists.pharo.org>
> Subject: [Pharo-dev] weird tales about cursors and rectangle invalidations
>
> Hi,
>
> I’ve been playing a bit today with something that is puzzling me and I need 
> some more eyes in what I’m doing, because it might be that I’m understanding 
> everything wrong… but if not, then, huston, we have a bug.
> So, play with me… you need to create this:
>
> SystemWindow subclass: #XSystemWindow
>   instanceVariableNames: 'iteration'
>   classVariableNames: ''
>   package: ‘XXX'
>
> XSystemWindow>>initialize
>   super initialize.
>   iteration := 0.
>
> XSystemWindow>>drawOn: aCanvas
>   “Do not use transcript because it does even more crazy stuff"
>   Stdio stdout << (iteration := iteration + 1) asString; cr; lf.
>   super drawOn: aCanvas
>
>
> Then execute this in a playground:
>
> XSystemWindow new
>   addMorph: (RubScrolledTextModel new newScrolledText) fullFrame: 
> LayoutFrame identity;
>   openInWorld.
>
> and then you can watch in your stdout how full window redraws with cursor 
> blinking (it stops when window loses focus).
>
> This happens because cursor is displayed with lapsus of 700ms and is just a 
> draw of a line with a color who is set to it’s opposite each time. Then it 
> does "color: shownColor” and #color: sends #changed who finalise in 
> #invalidRect.
> I always thought that this invalidation mechanism works by recording “damaged 
> areas”, then collecting morphs with that area and triggering the redraw of 
> that morph.
> With this in mind, cursor should trigger an invalidation of it’s own area (a 
> small portion of the screen, as you can see).
> I could understand that a cursor triggers the text area redraw (but that 
> would be a “design flaw”, IMO)… now, what I cannot understand is why blink a 
> cursor triggers the redraw of a FULL WINDOW.
> When in Nautilus, that means each cursor blink triggers the redraw of one 
> tree, four lists, some buttons and finally, the text area.
> IMO, this is not acceptable.
>
> What do you think?
>
> Esteban

Re: [Pharo-dev] weird tales about cursors and rectangle invalidations

[Henrik Nergaard]

If the cursor uses a solid fill (color) only it should be redrawn, and when it 
blinks "off" only the RubScrolledTextMorph (if it has a solid fill), and any of 
it submorphs which intersects with the damage area should be redrawn.

(drawing is being called for the full window)
The only area modified is that within the clipping rect of the canvas (damaged 
area). For non-complex drawing (system window only draws a rectangle with 
border) filling over a small area should not be noticeable performance wise (as 
long as the submorph tree is not too deep), but should be fixed.  

I think the best place to start looking at and improving is in WorldState 
>>#drawWorld:submorphs:invalidAreasOn:

Best regards,
Henrik


-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Esteban 
Lorenzano
Sent: Sunday, May 22, 2016 9:50 PM
To: Pharo Development List <pharo-dev@lists.pharo.org>
Subject: Re: [Pharo-dev] weird tales about cursors and rectangle invalidations

Hi,

flash damaged areas is not showing me anything :( but still, you seems to be in 
agreement with me and what is happening *should not* happen, isn’t? (drawing is 
being called for the full window)

btw, this is not just a rubric problem, it happens if I put a 
PluggableTextMorph as well.

cheers!
Esteban


> On 22 May 2016, at 21:28, Henrik Nergaard <henrik.nerga...@uia.no> wrote:
> 
> Hi Esteban,
> 
> To see the damage live:
> SystemSettings->Tools->Debugging->Flash damaged morphic region.
> 
> Redrawing: 
> Only morphs whose area is within the visible draw region of the canvas (the 
> damaged area)  needs to be redrawn, so if a morph fullbounds is not 
> intersecting with this area it will not be drawn, and its submorphs will not 
> check deeper in this submorph hierarchy.
> The exclusion is done in #fullDrawOn:  by "(aCanvas isVisible: self 
> fullbounds) ifFalse: [ ^self ].
> So if the cursor reports a damage rectangle only morphs intersecting with 
> that area needs to be redrawn (there is also some layering mechanism IIRC so 
> that it should only re-draw the visible layers in that area, and not morphs 
> which are covered by their submorphs).
> 
> DamageRecorder:
> The damage recorder do not know about any layering of morphs when it records 
> damage. This means that if there is two overlapping windows in the World, and 
> the window in the back triggers an invalid area which intersects with the 
> window above, it will have to be redraw for that area as well even though it 
> is not necessary.
> 
> There is also the issue where multiple small areas close to each other need 
> multiple passes to be completed. If the damage recorder has damage in (10@10 
> corner: 20@20) and (10@30 corner: 20@40) a morph with bounds (0@0 corner: 
> 50@50) will be redrawn twice during that cycle. 
> 
> Rubric:
> There is some issues with how rubric handle changes, which causes blinking 
> the cursor to do way to much work that it actually have to do, I think it 
> also invalidates the whole selection and needs to redraw that as well.
> 
> 
> 
> Best regards,
> Henrik
> 
> 
> -Original Message-
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf 
> Of Esteban Lorenzano
> Sent: Sunday, May 22, 2016 8:36 PM
> To: Pharo Development List <pharo-dev@lists.pharo.org>
> Subject: [Pharo-dev] weird tales about cursors and rectangle 
> invalidations
> 
> Hi,
> 
> I’ve been playing a bit today with something that is puzzling me and I need 
> some more eyes in what I’m doing, because it might be that I’m understanding 
> everything wrong… but if not, then, huston, we have a bug. 
> So, play with me… you need to create this: 
> 
> SystemWindow subclass: #XSystemWindow
>   instanceVariableNames: 'iteration'
>   classVariableNames: ''
>   package: ‘XXX'
> 
> XSystemWindow>>initialize
>   super initialize.
>   iteration := 0.
> 
> XSystemWindow>>drawOn: aCanvas
>   “Do not use transcript because it does even more crazy stuff"
>   Stdio stdout << (iteration := iteration + 1) asString; cr; lf.
>   super drawOn: aCanvas
> 
> 
> Then execute this in a playground: 
> 
> XSystemWindow new 
>   addMorph: (RubScrolledTextModel new newScrolledText) fullFrame: 
> LayoutFrame identity;
>   openInWorld.
> 
> and then you can watch in your stdout how full window redraws with cursor 
> blinking (it stops when window loses focus). 
> 
> This happens because cursor is displayed with lapsus of 700ms and is just a 
> draw of a line with a color who is set to it’s opposite each time. Then it 
> does "color: shownColor” and #color: sends #changed who finalise in

Re: [Pharo-dev] strange Zinc JPEG bug

[Henrik Nergaard]

Not sure where to report zinc bugs… fogzbugz? or is it a separate project?
Any bug found in the standard image regardless of project should be reported on 
fogbugz, no?

   but this works just fine…
If I do:

| imageStream |

imageStream :=  (ZnEasy get: 
'http://orig13.deviantart.net/e8d3/f/2013/092/a/3/glados_s_activation_by_first9-d605rwi.jpg')
 contents readStream.

JPEGReadWriter formFromStream: imageStream.

It will give me an error “image format not recognized”.

ImageReadWriter chooses to use PluginBasedJPEGReadWriter instead of 
JPEGReadWriter (ImageReadWriter >>#readerClassFromStream: ).

So perhaps #getJpeg: should use the PluginBasedJPEGReadWriter or have a 
fallback on error trying once more by using (
JPEGReadWriter formFromStream: theStream ) ?

Best regards,
Henrik


From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Peter 
Uhnák
Sent: Tuesday, May 24, 2016 6:37 PM
To: Pharo Development List 
Subject: [Pharo-dev] strange Zinc JPEG bug

Hi,

Offray discovered a strange Zinc bug when reading a JPEG.
Not sure where to report zinc bugs… fogzbugz? or is it a separate project?

This fails on "marker D0 cannot be handled"

image := ZnEasy getJpeg: 
'http://orig13.deviantart.net/e8d3/f/2013/092/a/3/glados_s_activation_by_first9-d605rwi.jpg'.
World backgroundImage: image layout: #scaled.

but this works just fine

image := (ImageReadWriter formFromStream: (ZnEasy get: 
'http://orig13.deviantart.net/e8d3/f/2013/092/a/3/glados_s_activation_by_first9-d605rwi.jpg')
 contents readStream).
World
backgroundImage: image
layout: #scaled.

Peter

Re: [Pharo-dev] how to swallow a syntax error?

[Henrik Nergaard]

Catching the Notification stops it from popping up the syntaxErrorDebugger.

'AAA.st' asFileReference readStreamDo: [ :s |
   importer := CodeImporter fileStream: s.

   [ importer evaluateDeclarations ] on: SyntaxErrorNotification 
do: [ :e | …]

].

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Tudor 
Girba
Sent: Saturday, May 21, 2016 11:25 PM
To: Pharo Development List 
Subject: [Pharo-dev] how to swallow a syntax error?

Hi,

I am having trouble making the compiler not be interactive when it encounters a 
syntax error.

To reproduce the problem I attach here an .st file that has a funny character 
in the method name. If I file this in, like:
‘AAA.st’ asFileReference fileIn.

 I get a Syntax Error dialog. I would like to avoid that.

After diving in, I noticed that I can tell the requestor of the CodeImporter to 
not be interactive, but that does not seem to have an effect:
'AAA.st' asFileReference readStreamDo: [ :s |
importer := CodeImporter fileStream: s.
importer requestor interactive: false.
importer evaluateDeclarations ]

I also tried to play on the end of the SyntaxErrorDebugger, and replace it with 
something that logs the exception, but I was not successful because that one is 
expected to return a string that can be compiled.

Can anyone point me in the right direction?

Cheers,
Doru

--
www.tudorgirba.com
www.feenk.com

"Every now and then stop and ask yourself if the war you're fighting is the 
right one."

Re: [Pharo-dev] new collaborators in Pharo 5

[Henrik Nergaard]

hn, Latsabben, and HenrikNergrd is me... (I will create a slice to fix those in 
Pharo 6)

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Esteban 
Lorenzano
Sent: Friday, April 29, 2016 10:26 AM
To: Pharo Board ; Pharo Development List 

Subject: [Pharo-dev] new collaborators in Pharo 5

Hi, 

So, according to my script, this are the new collaborators (people who started 
contributing after 1st march 2015):

Maxleske
CyrilFerlicot
Latsabben
Nicolaihess
synectique
BorisSpasojevic
Stef
Bite
hn
SvenVanCaekebenberghe
StefnReichhart
NicoPasserini
DEMAREYChristophe
HenrikNergrd
SkipLentz
Spirita
Fuel
TravisCI
HolgerHansPeterFreyther
SpurBootstrap
qdq
SergioFedi
jeanbaptisteArnaud
AutoGenTutorial
PabloTesone
ThomasHeniart
ValentinRyckewaert
mml
HenrikNergaard
MarcusDenkr
DenisKudriashov
Alexandre
mcamp
Matthieu
w3ertyu
VincentBlondeauAbdelghaniAlidra
TH
MerwanOuddane
ChristopherCoat
AlainRastoul
FranckWarlouzet
AbdelghaniLaidra
ThibaultArloing
pad
RogerStebler
DavidAllouche
RM
tr

Obviously… many are wrong since they started contributing a lot before (like 
Sven and Stef :P … I wonder why the difference gave me this… but well… )

Anyway, I need to know who are this guys: 

- synectique (I suppose is Guillome, Usman or Cyril)
- Bite (I hope this is not a french guy, because in that case is soo rude… 
or proud of himself :P)
- hn
- Spirita
- qdq
- mml
- Alexandre (Bergel?)
- mcamp
- Matthieu
- w3ertyu
- TH
- pad
- RM
- tr

So… any hints about authors? 

thanks, 
Esteban

Re: [Pharo-dev] slice/merge conflict with package AST-FFI-Pharo50Compatibility

[Henrik Nergaard]

When trying to load the Slice for 17696 from  pharo60Inbox I get: 
“MessageNotUnderstood: receiver of "dependencies" is nil” when it tries to load 
AST-FFI-Pharo50Compatibility.

I think you need to reset the package cache/folder?
You might also I need to do the slice again (without loading the previous), and 
ensure that the author set when uploading the slice is not the same as similar 
slices in the repo so it will not create dependencies of it ( ie before 
creating the slice do: “Author fullname: ‘_NicolaiHess’

Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Nicolai 
Hess
Sent: Tuesday, May 24, 2016 11:38 PM
To: Pharo Development List 
Subject: [Pharo-dev] slice/merge conflict with package 
AST-FFI-Pharo50Compatibility

I need help with issues
17696
 RBParser should not allow variable names for pragma arguments
17994
 RBParserNode: allowed primitive pragma definition can not compile
for both issues I created a slice that will modify methods from package
AST-FFI-Pharo50Compatibility, but merging this slices shows a merge conflict.
I don't know what is wrong or how I could solve this.
any help appreciated.
nicolai

[Pharo-dev] Performance of [ * ] repeat vs [ * . true ] whileTrue

[Henrik Nergaard]

Hi,

Why  is "[ * ] repeat" almost twice as slow as "[ * . true ] whileTrue" ?

--

[
| n |
n := 0.
[
[
n := n + 1.
n > 1 ifTrue: [ Error signal ]
] repeat
] on: Error do: [ :err | ].

] timeToRun "0:00:00:00.874"

--

[
| n |
n := 0.
[
[
n := n + 1.
n > 1 ifTrue: [ Error signal ].
true
] whileTrue
] on: Error do: [ :err | ].

] timeToRun "0:00:00:00.448"



Best regards,
Henrik

Re: [Pharo-dev] Athens Font Rendering Bug

[Henrik Nergaard]

On Windows?

Try:
-
CairoGlyph class removeSelector:#byteAlignment.
CairoGlyph rebuildFieldAccessors .


Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Hilaire
Sent: Tuesday, July 12, 2016 11:00 AM
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] Athens Font Rendering Bug

Not sure it is related, but I found bug in Dr. Geo when rendering string, the 
whole text extent does not seem right and glitches appear,

See the picture attached to this bug report:
https://bugs.launchpad.net/drgeo/+bug/1372933

Hilaire

Le 10/07/2016 19:10, Aliaksei Syrel a écrit :
> Hi
> 
> Actually it is not Athens bug. Problem is in string extent measurement 
> done by text morph. Athens (Cairo in the end) only renders string 
> glyphs created by FreeType2 on positions specified by someone else 
> (morphic in this case).
> 
> Cheers
> Alex
> 

--
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] Spec TreeModel get selected items in order

[Henrik Nergaard]

ListModel has that: #selectedItemsSorted, but looking at the tree model 
structure I guess the simplest way is to just traverse the whole structure 
until the selected nodes are found.
Something like this should do the trick:

--
TreeModel >> selectionSorted
   | ordered lookingFor search |

   ordered := OrderedCollection new.

   lookingFor := self selectedItems asIdentitySet.
   LookingFor ifEmpty: [ ^ #() ]
   search := [ :nodes |
  nodes do: [ :node |
 (lookingFor includes: node) 
ifTrue: [
ordered add: node.
lookingFor remove: 
node.
lookingFor isEmpty 
ifTrue: [ ^ ordered asArray ]
 ].
 search value:  node children value
  ]
   ].

   search value: self roots.

   self error: 'should not happen'

--

Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Nicolai 
Hess
Sent: Sunday, August 7, 2016 4:55 PM
To: Pharo Development List 
Subject: [Pharo-dev] Spec TreeModel get selected items in order

Hi,
Is there a way to retrive the selected nodes of a TreeModel in the same order 
they are
shown in the widget ?
For example, open this tree model, and select item 5/4/3/1
|t|
Transcript clear.
t := TreeModel new.
t beCheckList ;
 autoMultiSelection: true.
t roots:((1 to:10) collect:[:c | TreeNodeModel new 
content:c;hasContentToShow:true]).
t openWithSpec.
t inspect .
Now, if I try to collect the selected items with
t selectedItems collect:#contents
they appear in the order I selected them, but I would like to get the order
1/2/3/4/5
thanks
Nicolai

Re: [Pharo-dev] Spec TreeModel get selected items in order

[Henrik Nergaard]

The test #testPickedChangesAfterSelect selects an item which is not in the 
browser, so I would consider that a bug.

Adding the item to the browser before selecting it should be correct and make 
the test work.

ChangesBrowserTest >> testPickedChangesAfterSelect
   | item |
   Item := RBAddClassChange.
   Item definition: ‘test’ controller: nil.
   Browser changes: {item}.
   Self assert: …..
   ….

Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Nicolai 
Hess
Sent: Sunday, August 7, 2016 7:46 PM
To: Pharo Development List <pharo-dev@lists.pharo.org>
Subject: Re: [Pharo-dev] Spec TreeModel get selected items in order



2016-08-07 18:23 GMT+02:00 Nicolai Hess 
<nicolaih...@gmail.com<mailto:nicolaih...@gmail.com>>:


2016-08-07 17:53 GMT+02:00 Henrik Nergaard 
<henrik.nerga...@uia.no<mailto:henrik.nerga...@uia.no>>:
ListModel has that: #selectedItemsSorted, but looking at the tree model 
structure I guess the simplest way is to just traverse the whole structure 
until the selected nodes are found.
Something like this should do the trick:

--
TreeModel >> selectionSorted
   | ordered lookingFor search |

   ordered := OrderedCollection new.

   lookingFor := self selectedItems asIdentitySet.
   LookingFor ifEmpty: [ ^ #() ]
   search := [ :nodes |
  nodes do: [ :node |
 (lookingFor includes: node) 
ifTrue: [
ordered add: node.
lookingFor remove: 
node.
lookingFor isEmpty 
ifTrue: [ ^ ordered asArray ]
 ].
 search value:  node children value
  ]
   ].

   search value: self roots.

   self error: 'should not happen'

--

Thanks Peter, Henrik,
yes I was afraid there is no other way.


I tried to fix this, but there is a test case for the ChangesBrowser that tests 
the selection.
The problem is, that the test case selects an item by calling #selectedItem: 
and the behavior is different for when this is called by the view.
The test case just selects the "change", whereas when this is called by the 
view, the selected item is TreeNodeModel (with #contents).
And I can not fix #pickedChanges without breaking this test.
Any Idea ?




Best regards,
Henrik

From: Pharo-dev 
[mailto:pharo-dev-boun...@lists.pharo.org<mailto:pharo-dev-boun...@lists.pharo.org>]
 On Behalf Of Nicolai Hess
Sent: Sunday, August 7, 2016 4:55 PM
To: Pharo Development List 
<pharo-dev@lists.pharo.org<mailto:pharo-dev@lists.pharo.org>>
Subject: [Pharo-dev] Spec TreeModel get selected items in order

Hi,
Is there a way to retrive the selected nodes of a TreeModel in the same order 
they are
shown in the widget ?
For example, open this tree model, and select item 5/4/3/1
|t|
Transcript clear.
t := TreeModel new.
t beCheckList ;
 autoMultiSelection: true.
t roots:((1 to:10) collect:[:c | TreeNodeModel new 
content:c;hasContentToShow:true]).
t openWithSpec.
t inspect .
Now, if I try to collect the selected items with
t selectedItems collect:#contents
they appear in the order I selected them, but I would like to get the order
1/2/3/4/5
thanks
Nicolai

Re: [Pharo-dev] How to get fogubugz to send email notifications to me ....

[Henrik Nergaard]

At the top right corner of the webpage there is a dropdown menu with an entry 
“Subscribe”. This enables you to automatically subscribe to cases according to 
certain filters, and changes in those will then be notified by mail.

Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Dale 
Henrichs
Sent: Sunday, August 7, 2016 11:35 PM
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] How to get fogubugz to send email notifications to me 



Oh wait --- I just noticed that I can only ask for notifications for cases I am 
assigned to ... I guess I have to explicitly subscribe to a bug ... sorry for 
the interruption...

Dale
On 8/7/16 2:31 PM, Dale Henrichs wrote:
I have the option selected to email notifications to me in FogBugz but I have 
yet to actually get email ... I must be missing some secret ingredient ... 
anyone else seeing or solving this problem?

Dale

Re: [Pharo-dev] How can I create a trivial "spinner" etc, to see if image is busy?

[Henrik Nergaard]

You can create a morph that steps until the process is terminated. 
Attached is an example class:


StepForProcessMorph new
process: [ 10 seconds asDelay wait ];
extent: 200 asPoint;
openCenteredInWorld 


Best regards,
Henrik

-Opprinnelig melding-
Fra: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] På vegne av Yuriy 
Tymchuk
Sendt: 05 February 2017 20:33
Til: Pharo Development List <pharo-dev@lists.pharo.org>
Emne: Re: [Pharo-dev] How can I create a trivial "spinner" etc, to see if image 
is busy?

This is a really nice solution for STON, thank you!

But in general terms, imagine I have some task and it’s not the trivial to add 
a progress bar. I could spawn a string morph and make circle the digits with 
some interval, but maybe there is something easier. For example Kommiter had a 
spinner morph that you could just open and it would be spinning. So when you 
run a task you can easily see that the task is still running

Uko

> On 5 Feb 2017, at 20:01, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> 
> A bit off topic, but I would do the STON writing as follows:
> 
> [
> (FileLocator temp / 'file.ston') writeStreamDo: [ :out |  (STON writer 
> on: out) in: [ :stonWriter |
>30 timesRepeat: [ 
>  stonWriter nextPut: Smalltalk allClasses ] ] ].
> ] timeToRun. "0:00:00:02.176"
> 
> But in light of alternative streams and some optimisation, this works too:
> 
> [
> | file |
> file := (File named: '/tmp/file.ston') openForWrite.
> [
>  ZnBufferedWriteStream on: (ZnCharacterWriteStream on: file) do: [ :out | 
>(STON writer on: out) in: [ :stonWriter |
>  30 timesRepeat: [ 
>stonWriter nextPut: Smalltalk allClasses ] ] ] ] ensure: [ file 
> close ].
> ] timeToRun. "0:00:00:00.385"
> 
> Which is faster.
> 
> Total file size is ~1.2MB.
> 
> BTW, we need #readStreamDo: and #writeStreamDo: on File I think, as it 
> encourages proper resource management.
> 
>> On 5 Feb 2017, at 19:16, Henrik Nergaard <draag...@outlook.com> wrote:
>> 
>> http://smalltalkhub.com/#!/~Latsabben/GafletFremgangFremviser
>> 
>> -
>> | ston file|
>> 
>> ston := (1 to: 30) flatCollect: [:ix |STON toStringPretty: Smalltalk 
>> allClasses].
>> file := (FileStream fileNamed: 'file.ston').
>> 
>> ston whileDisplayingProgress
>>  action: [ :stream | file nextPutAll: stream ] whenDone: [ file close ];
>>  open;
>>  fillOwner
>> -
>> 
>> Best regards,
>> Henrik
>> 
>> -Opprinnelig melding-
>> Fra: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] På vegne av 
>> Yuriy Tymchuk
>> Sendt: 05 February 2017 16:56
>> Til: Pharo Development List <pharo-dev@lists.pharo.org>
>> Emne: [Pharo-dev] How can I create a trivial "spinner" etc, to see if image 
>> is busy?
>> 
>> Hi all,
>> 
>> is there an easy was to do some thing that is constantly changing? so if my 
>> image freezes (to export a 1gb ston file for example) I can see when it’s 
>> done.Or maybe there is a way to send a mac notification from Pharo?
>> 
>> Cheers.
>> Uko
> 
> 




StepForProcessMorph.st
Description: StepForProcessMorph.st

Re: [Pharo-dev] How can I create a trivial "spinner" etc, to see if image is busy?

[Henrik Nergaard]

Yes, but that will block the UI.
The progress bar update (world rendering) is done by force using “self 
currentWorld displayWorld”, which also means that if the 
#do:displayingProgress: is forked there will be more than one UI rendering at 
the same time.

Open a window, evaluate the script below, drag and drop the window around.
[
Smalltalk allClasses
do:[:aClass| (Delay forMilliseconds: 1) wait]
displayingProgress:[:aClass| 'Processing ', aClass name].
] fork

Best regards,
Henrik

Fra: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] På vegne av 
p...@highoctane.be
Sendt: 05 February 2017 21:43
Til: Pharo Development List <pharo-dev@lists.pharo.org>
Emne: Re: [Pharo-dev] How can I create a trivial "spinner" etc, to see if image 
is busy?

In the base image

Smalltalk allClasses
do:[:aClass| (Delay forMilliseconds: 1) 
wait]
displayingProgress:[:aClass| 'Processing ', 
aClass name].

Phil

On Sun, Feb 5, 2017 at 7:16 PM, Henrik Nergaard 
<draag...@outlook.com<mailto:draag...@outlook.com>> wrote:
http://smalltalkhub.com/#!/~Latsabben/GafletFremgangFremviser

-
| ston file|

ston := (1 to: 30) flatCollect: [:ix |STON toStringPretty: Smalltalk 
allClasses].
file := (FileStream fileNamed: 'file.ston').

ston whileDisplayingProgress
action: [ :stream | file nextPutAll: stream ] whenDone: [ file close ];
open;
fillOwner
-

Best regards,
Henrik

-Opprinnelig melding-
Fra: Pharo-dev 
[mailto:pharo-dev-boun...@lists.pharo.org<mailto:pharo-dev-boun...@lists.pharo.org>]
 På vegne av Yuriy Tymchuk
Sendt: 05 February 2017 16:56
Til: Pharo Development List 
<pharo-dev@lists.pharo.org<mailto:pharo-dev@lists.pharo.org>>
Emne: [Pharo-dev] How can I create a trivial "spinner" etc, to see if image is 
busy?

Hi all,

is there an easy was to do some thing that is constantly changing? so if my 
image freezes (to export a 1gb ston file for example) I can see when it’s done. 
   Or maybe there is a way to send a mac notification from Pharo?

Cheers.
Uko

Re: [Pharo-dev] How can I create a trivial "spinner" etc, to see if image is busy?

[Henrik Nergaard]

http://smalltalkhub.com/#!/~Latsabben/GafletFremgangFremviser

-
| ston file|

ston := (1 to: 30) flatCollect: [:ix |STON toStringPretty: Smalltalk 
allClasses].
file := (FileStream fileNamed: 'file.ston').

ston whileDisplayingProgress
action: [ :stream | file nextPutAll: stream ] whenDone: [ file close ];
open;
fillOwner
-

Best regards,
Henrik

-Opprinnelig melding-
Fra: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] På vegne av Yuriy 
Tymchuk
Sendt: 05 February 2017 16:56
Til: Pharo Development List 
Emne: [Pharo-dev] How can I create a trivial "spinner" etc, to see if image is 
busy?

Hi all,

is there an easy was to do some thing that is constantly changing? so if my 
image freezes (to export a 1gb ston file for example) I can see when it’s done. 
   Or maybe there is a way to send a mac notification from Pharo?

Cheers.
Uko

Re: [Pharo-dev] In the need of Pharo magic

[Henrik Nergaard]

Here is an example of using the ast to remove -all- halts from the code if one 
or more is encountered during execution.

| haltTypes haltingMethods testCode |

haltTypes := #( halt halt: haltIf: haltIfNil haltOnCount: haltOnce).
haltingMethods := IdentitySet new.

"example code"
Object compile: 'aMethod | a | self halt. a := 42. self haltIf: a = 42; 
haltOnCount: 2; yourself. self haltOnce; halt: ''Halting!''. self yourself; 
haltIfNil; yourself. [ 1 halt ] value.  ^ a'.
testCode := (Object >> #aMethod) ast formattedCode.

[ "do stuff here"

  Object new perform: #aMethod

] on: Halt do: [ :ex |
  haltingMethods add: ex signalerContext method.
  "ex debug" "<- show debugger on a halt"
  ex resume.
].

haltingMethods do: [ :method | | ast cascades |
  ast := method ast copy.
  cascades := IdentitySet new.

  ast allChildren
 select: [ :child | child isMessage and: [ 
haltTypes includes: child selector ] ]
 thenDo: [ :child | | parent |
   parent := child parent.
   parent isCascade
  ifTrue: [
parent 
messages remove: child.

cascades add: parent
  ]
  ifFalse: [ parent 
removeNode: child ].
 ].

  cascades
 select: [ :cascadeNode | cascadeNode messages 
isEmpty]
 thenDo: [ :cascadeNode | cascadeNode parent 
removeNode: cascadeNode ].

  method origin
 compile: ast formattedCode
 classified: method protocol.

].

(
DiffMorph
  from: testCode
  to: (Object >>#aMethod) sourceCode
  contextClass: Object
) openInWindow


Best regards,
Henrik

Fra: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] På vegne av Stephane 
Ducasse
Sendt: 19 January 2017 18:46
Til: Pharo Development List 
Emne: [Pharo-dev] In the need of Pharo magic


I would love to get a functionality that dynamically removes from my code all 
the self halt that are encountered during test execution.
This way I will not need to run the test, walk the stack, edit the code and 
retart the process.

It would be really cool

Re: [Pharo-dev] Cycles lost on startup

[Henrik Nergaard]

Rewriting the implementation of #initSelectorTable to:

SelectorTable := WeakSet withAll: (CompiledMethod allInstances collect: [:m | m 
selector] as: IdentitySet).

Makes it 20ms faster, so it looks like there is some overhead when using 
WeakSet compared to first use a normal set to remove duplicates.

Another possibility could be to store the selectors in an IdentityDictionary as 
#selector->count which keep track of how many users of a selector there is 
itself, instead of using a WeakArray.

Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Nicolai 
Hess
Sent: Monday, September 5, 2016 7:52 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] Cycles lost on startup



2016-09-05 18:37 GMT+02:00 Eliot Miranda 
>:
Hi All,

we are simulating a full block Pharo image derived from Pharo 6.  On 
startup we see a very sad loss of cycles due to a very slow rebuild of the 
selector table in Symbol class.  Why is this done at each startup?  Here is the 
stack:

  16r107154 M ByteString class(ProtoObject)>identityHash 16r786AE8: a(n) 
ByteString class
  16r10716C M ByteString class(Object)>hash 16r786AE8: a(n) ByteString class
  16r10718C M ByteSymbol(String)>hash 16rE6A5C8: a(n) ByteSymbol
  16r1071B0 M WeakSet>scanForEmptySlotFor: 16r26B968: a(n) WeakSet
  16r1071DC M WeakSet>noCheckNoGrowFillFrom: 16r26B968: a(n) WeakSet
  16r1071FC M WeakSet>growTo: 16r26B968: a(n) WeakSet
  16r10721C M WeakSet>grow 16r26B968: a(n) WeakSet
  16r107234 M WeakSet(HashedCollection)>fullCheck 16r26B968: a(n) WeakSet
  16r10724C M WeakSet(HashedCollection)>atNewIndex:put: 16r26B968: a(n) WeakSet
  16r107274 M WeakSet>add: 16r26B968: a(n) WeakSet
  16r107294 M [] in Symbol class>(nil) 16r1D319A8: a(n) Symbol class
  16r1072B8 M Array(SequenceableCollection)>do: 16r3C17370: a(n) Array
  16r1072E8 I CompiledMethod class(Behavior)>allInstancesDo: 16r164E260: a(n) 
CompiledMethod class
  16r10730C I Symbol class>initSelectorTable 16r1D319A8: a(n) Symbol class
  16r10732C I Symbol class>selectorTable 16r1D319A8: a(n) Symbol class
  16r107350 I Symbol class>internSelector: 16r1D319A8: a(n) Symbol class
  16r10737C I CompiledMethod>selector: 16r26AB58: a(n) CompiledMethod
  16r1073A4 I IRMethod>generate: 16r25A030: a(n) IRMethod
  16r1073CC I FFICalloutMethodBuilder>generateMethodFromSpec: 16r255580: a(n) 
FFICalloutMethodBuilder
  16r1073F0 I FFICalloutMethodBuilder>generate 16r255580: a(n) 
FFICalloutMethodBuilder
  16r1030C8 I FFICalloutMethodBuilder>build: 16r255580: a(n) 
FFICalloutMethodBuilder
  16r1030F4 I FFICalloutAPI>function:module: 16r255568: a(n) FFICalloutAPI
  16r10311C I UnixEnvironment(Object)>ffiCall:module: 16r3816180: a(n) 
UnixEnvironment
  16r103144 I UnixEnvironment(OSEnvironment)>getEnv: 16r3816180: a(n) 
UnixEnvironment
  16r103168 I UnixEnvironment(OSEnvironment)>at:ifAbsent: 16r3816180: a(n) 
UnixEnvironment
  16r10318C M [] in MacOSResolver>(nil) 16r241170: a(n) MacOSResolver
  16r1031A4 M FullBlockClosure(BlockClosure)>on:do: 16r2553F0: a(n) 
FullBlockClosure
  16r1031D0 I MacOSResolver(PlatformResolver)>directoryFromEnvVariableNamed:or: 
16r241170: a(n) MacOSResolver
  16r1031F8 I MacOSResolver(PlatformResolver)>directoryFromEnvVariableNamed: 
16r241170: a(n) MacOSResolver
  16r10321C I MacOSResolver>home 16r241170: a(n) MacOSResolver
  16r10323C I MacOSResolver>userLibrary 16r241170: a(n) MacOSResolver
  16r103254 M MacOSResolver>userApplicationSupport 16r241170: a(n) MacOSResolver
  16r10326C M MacOSResolver(FileSystemResolver)>resolve: 16r241170: a(n) 
MacOSResolver
  16r103288 M SystemResolver(FileSystemResolver)>unknownOrigin: 16r240D30: a(n) 
SystemResolver
  16r1032A4 M SystemResolver(FileSystemResolver)>resolve: 16r240D30: a(n) 
SystemResolver
  16r1032C4 M InteractiveResolver>unknownOrigin: 16r240CF0: a(n) 
InteractiveResolver
  16r1032E4 M [] in InteractiveResolver>(nil) 16r240CF0: a(n) 
InteractiveResolver
  16r103300 M IdentityDictionary(Dictionary)>at:ifAbsent: 16r240D00: a(n) 
IdentityDictionary
  16r103320 M InteractiveResolver>resolve: 16r240CF0: a(n) InteractiveResolver
  16r10333C M FileLocator>resolve 16r255258: a(n) FileLocator
  16r103354 M FileLocator(AbstractFileReference)>exists 16r255258: a(n) 
FileLocator
  16r10337C M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) PharoFilesOpener
  16r103398 M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) PharoFilesOpener
  16r1033B0 M FullBlockClosure(BlockClosure)>on:do: 16r255190: a(n) 
FullBlockClosure
  16r1033D0 M FullBlockClosure(BlockClosure)>ifError: 16r255190: a(n) 
FullBlockClosure
  16r1033EC M PharoFilesOpener>ignoreIfFail: 16rE79FD8: a(n) PharoFilesOpener
  16r102188 M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) PharoFilesOpener
  16r1021AC M Array(SequenceableCollection)>do: 16r2495E8: a(n) Array
  16r1021DC I PharoFilesOpener>openSources:forImage: 16rE79FD8: a(n) 
PharoFilesOpener
  16r102204 I 

[Pharo-dev] Latest Configuration of XPath is broken

[Henrik Nergaard]

Hi,

Trying to load XPath using the latest configuration 
(ConfigurationOfXPath-monty.91) gives the following error:
MetacelloProjectSpecLoadError: No version found for #'release-2.8.7' of 
ConfigurationOfXMLParser because: The symbolic version #'release-2.8.7' is not 
defined in ConfigurationOfXMLParser for the current platform. Possible symbolic 
version values include: #(#bleedingEdge #development #'release-2' 
#'release-2.4' #'release-2.5' #'release-2.5.3' #'release-2.5.5' #'release-2.6' 
#'release-2.6.3' #'release-2.6.5' #'release-2.6.8' #'release-2.7.3' 
#'release-2.7.4' #'release-2.7.6' #'release-2.7.7' #'release-2.8.1' 
#'release-2.8.3' #'release-2.8.6' #stable)

ConfigurationOfXPath-monty.90 loads fine.

Best regards,
Henrik

Re: [Pharo-dev] Latest Configuration of XPath is broken

[Henrik Nergaard]

Platform is Pharo 6 - Image 60202.
Loading it again in the same image still gives the same error, also for 
-monty.92

I cannot replicate this error using a clean image, so It might have been some 
rare bug in how the repository were added or something. 

Best regards,
Henrik


-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of monty
Sent: Friday, September 9, 2016 3:00 PM
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] Latest Configuration of XPath is broken

Looks OK: 
https://ci.inria.fr/pharo-contribution/job/XPath/PHARO=60,VERSION=stable,VM=vm/lastCompletedBuild/console

From the output:
> Project: XMLParser release-2.8.7 [2.8.7]

Could you try manually loading the latest ConfigurationOfXMLParser from its 
repo and using the latest XPath config again, and tell me what platform you're 
using (Pharo, Squeak, GS)?

>From: "Henrik Nergaard" <henrik.nerga...@uia.no>
>To: "Pharo Development List" <pharo-dev@lists.pharo.org>
>Subject: [Pharo-dev] Latest Configuration of XPath is broken
>
>Hi,
> 
>Trying to load XPath using the latest configuration 
>(ConfigurationOfXPath-monty.91) gives the following error:
>MetacelloProjectSpecLoadError: No version found for #'release-2.8.7' of 
>ConfigurationOfXMLParser because: The symbolic version #'release-2.8.7' is not 
>defined in ConfigurationOfXMLParser for the current platform. Possible 
>symbolic version values include: #(#bleedingEdge #development #'release-2' 
>#'release-2.4' #'release-2.5' #'release-2.5.3' #'release-2.5.5' #'release-2.6' 
>#'release-2.6.3' #'release-2.6.5' #'release-2.6.8' #'release-2.7.3' 
>#'release-2.7.4' #'release-2.7.6' #'release-2.7.7' #'release-2.8.1' 
>#'release-2.8.3' #'release-2.8.6' #stable)
> 
>ConfigurationOfXPath-monty.90 loads fine.
> 
>Best regards,

Re: [Pharo-dev] About the non-use of Announcer in Bloc

[Henrik Nergaard]

Probably from the use of critical (mutex), the way #subscriptionsHandling: is 
done, and that Announcer is built for X number of announcers and Y number of 
subscribers, which means that each announcement the announcer has to filter and 
find the correct subscribers.


| ann a |

ann := Announcer new.

ann when: Announcement do: [ :e ].
a := Announcement new.
[[ ann announce: a ] bench ] timeProfile

-

Other drawbacks to consider when using announcements:
Memory overhead from the Announcer object and each subscription.
Memory ownership, the announcement subscriptions will strongly reference the 
announcement target unless the announcement is weakly, which can lead to memory 
leakage especially if strong and weak subscriptions are mixed in certain 
situations (see the mailing list from around the release of Pharo 6). This also 
leads to code where the announcer is the one who owns the target (multiple 
times if there are different announcements),  which makes understanding who 
references what etc.. much harder to understand.
In many places the control/message flow, and the relationship between the 
different parts of a bigger object tends to become much more difficult to 
understand (For example Rubric).

Announcer usage shines when there is a need for a common place that X objects 
can communicate  Y messages to Z recipients without needing to know who sends 
what, or who wants to receive what (For example System Announcements).

Communication when only one Object "A" announces to another Object(s) "B", is 
better implemented as A referencing B, then B implements the necessary methods 
needed for this communication. 

Best regards,
Henrik



-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Glenn 
Cavarlé
Sent: Sunday, August 28, 2016 9:11 PM
To: pharo-dev@lists.pharo.org
Subject: [Pharo-dev] About the non-use of Announcer in Bloc

Hi all,
Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of 
Announcer in Bloc. 
I made some test cases in Bloc-Tests to compare performances between Announcer 
and BlEventRegistry.
The result is that Announcer is at least 5x slower in all tested cases.
Bloc has only specific needs about event dispatching,  the first one is the 
efficiency during event propagation.
It may be interesting to investigate why Announcer is slower and also what are 
the uncovered cases in BlEventRegistry.
So, i'm interested in continuing our discussion about that.

Regards,
Glenn.



-
Glenn Cavarlé
--
View this message in context: 
http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Usability issue : the class/instance button in Pharo 5 gives poor feedback

[Henrik Nergaard]

What about something like this? 

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Stephan 
Eggermont
Sent: Monday, August 22, 2016 10:36 PM
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] Usability issue : the class/instance button in Pharo 5 
gives poor feedback

On 20/08/16 16:33, Oscar Nierstrasz wrote:
>
> Well, as a user I want to see the current context as well.
>Thanks for pointing out that the methods and protocols on the class side are 
>bold!
 >Now that I know this I will watch for it; but it is not at all obvious.

Indeed. A visual indicator not only needs to be there, it also needs to be 
obviously connected to the widget influencing it. Neither of the three buttons 
provide that. The hover texts should adapt to the button state, b.t.w.

I thought the color differences of the forward and backward arrow of the 
history navigator might have something to do with being on the first/last item, 
but that is not the case.

Stephan

[Pharo-dev] Odd literal in metaclasses methods

[Henrik Nergaard]

Every method implemented in the class side includes a literal: 
"nil->theMetaClass".
Object class methods collect: [ :cm | cm literals last ].

What is it used for?

Best regards,
Henrik

Re: [Pharo-dev] Please test new VMs (round one)

[Henrik Nergaard]

Yup, tried both itimer and threaded linux-x86_64 vm’s

Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Thierry 
Goubier
Sent: Wednesday, November 9, 2016 1:37 PM
To: Pharo Development List <pharo-dev@lists.pharo.org>
Subject: Re: [Pharo-dev] Please test new VMs (round one)



2016-11-09 13:28 GMT+01:00 Henrik Nergaard 
<henrik.nerga...@uia.no<mailto:henrik.nerga...@uia.no>>:
Got it running on Windows using “Ubuntu on Windows” and Xming server.
There are some failing kernel tests, but no crash so far ;)

You've used the linux 64bits vm?
Thierry


Best regards,
Henrik

From: Pharo-dev 
[mailto:pharo-dev-boun...@lists.pharo.org<mailto:pharo-dev-boun...@lists.pharo.org>]
 On Behalf Of Esteban Lorenzano
Sent: Wednesday, November 9, 2016 12:01 PM
To: Pharo Development List 
<pharo-dev@lists.pharo.org<mailto:pharo-dev@lists.pharo.org>>
Subject: [Pharo-dev] Please test new VMs (round one)

Hi guys,

I want to start moving the VM stuff into the new structure. Now I know there 
are still missing things :)
Can you download a VM from here: 
https://bintray.com/estebanlm/pharo-vm/build/201611082123#files

and start using it, and report problems?

thanks!
Esteban

ps: Windows users: I’m still not there, I’m having problems to build 
third-party libraries with cygwin… also if someone can help me here I would 
thank it :)

Re: [Pharo-dev] Pharo6 64bits Unix on Windows 10

[Henrik Nergaard]

Do you mean starting a linux vm via windows-bash with DISPLAY exported to 
something like xming, or was something else done?

- fetching packages from github. (tar fail to create files with ':' in them, so 
downloading filetree from github fails).

If the image/download path is located within the “unix file system” instead of 
“/mnt/c/*” then unpacking files containing $: should work.

Downloading the .zip + unzipping instead of cloning the repo works but it will 
replace the $: with  $_.

There is also the possibility to do this modification by downloading the .zip 
into memory and “patching” the filename / install without using the file system 
at all.
ZipArchive new readFrom: ‘https://gitbub.com/…/..zip’ asZnUrl retrieveContents 
readStream.

Best regards,
Henrik


From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Thierry 
Goubier
Sent: Monday, November 28, 2016 4:26 PM
To: Pharo 
Subject: [Pharo-dev] Pharo6 64bits Unix on Windows 10

Hi guys,
Jason Lecerf, a new PhD student at CEA, has managed to run a Pharo6 64bits vm 
and image (60307) under the ubuntu add-ons to Microsoft Windows 10.
What is validated is:
- downloading the latest 64bits pharo vm from esteban
- downloading the latest image from files.pharo.org
- opening the gui.
What doesn't work well
- fetching packages from github. (tar fail to create files with ':' in them, so 
downloading filetree from github fails).

As far as I know of the process, running a 32bits image and vm should work too.
Thierry

Re: [Pharo-dev] two question about fasttable

[Henrik Nergaard]

- Then I miss an important design point. Why datasource returns Morph?
Do you mean from #cellColumn:row: ?

- I do not get why a data source should return UI element. To me it violates 
layers.
The datasource is a wrapper/binding between the real object and the view 
(table/list) and provides the necessary stuff for display and interaction 
between them. Returning custom UI elements (cells and rows) from the datasource 
is part of what makes it possible to reuse the same table/container morph for 
lists/tables/trees. 

Best regards.
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of stepharo
Sent: Monday, November 28, 2016 9:32 PM
To: pharo-dev@lists.pharo.org
Subject: [Pharo-dev] two question about fasttable

Hi

- Could we rename FastTable into Table?

- Then I miss an important design point. Why datasource returns Morph?
I do not get get why a data source should return UI element. To me it violates 
layers.

Stef



--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] About setProperty:toValue: vs. valueOfProperty:

[Henrik Nergaard]

| dct arr |

dct := IdentityDictionary new.

arr := #(
#valueOfProperty: 
#valueOfProperty:ifAbsent: 
#valueOfProperty:ifAbsentPut:
#setProperty:toValue:
#hasProperty:
).

Morph withAllSubclasses do: [ :class | 
class methods do: [ :each |
each ast allChildren 
select: [ :c |  c isMessage and: [ arr includes: c 
selector ] ]
thenDo: [ :c | 
dct 
at: c selector 
ifPresent: [ :col | col add: c ] 
ifAbsentPut: [ OrderedCollection with: 
c ]
]
]
].

dct

--

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of stepharo
Sent: Thursday, November 3, 2016 8:48 PM
To: Pharo Development List 
Subject: [Pharo-dev] About setProperty:toValue: vs. valueOfProperty:

I would like to be able to compare the **arguments** passed to

setProperty:toValue:

and

the ones of valueOfProperty:, valueOfProperty:ifAbsent:, 
valueOfProperty:ifAbsentPut:,

and

hasProperty:

I quite sure that we will discover more deadcode in morphic.

Any ideas?



PS: I hope (but I cannot read the code of Bloc because it crashes my vm at 
startup) that Bloc and Brick will not use such patterns.

There are plague and lead to shitty and crappy code.


Stef

Re: [Pharo-dev] about syntaxError

[Henrik Nergaard]

Change line 3 of RBExtractMethodRefactoring>>extractMethod to something like:
[ extractedParseTree := RBParser parseExpression: extractCode ] on: 
SyntaxErrorNotification do: [ :ex| ex debug ]. 

To bring up a debugger.

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
stepharong
Sent: Thursday, December 8, 2016 9:08 PM
To: pharo-dev@lists.pharo.org
Subject: [Pharo-dev] about syntaxError

I tried to fix the extract method refactoring that seems broken when extracting 
class or variables.
And I wanted to understand if I can get a debugger stack instead of this 
useless Syntax Error: window.
Now I cannot find reference to SyntaxErrorDebugger.
still putting a break point in

buildMorphicViewOn: aSyntaxError
"Answer an Morphic view on the given SyntaxError."

| window |
self halt.

bring a debugger but with a cut stack 

open: aSyntaxError
"Answer a standard system view whose model is an instance of me."

"Simulation guard"
| process |
process := Processor activeProcess.
UIManager default spawnNewProcessIfThisIsUI: process.
UIManager default defer: [
self buildMorphicViewOn: aSyntaxError.
].
^ process suspend

so it does not really help to understand the syntax error.
I do not get why this is so opaque.

Stef


--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] NeoUUIDGenerator>>testTwoSameGenerator - intermittent CI failure

[Henrik Nergaard]

>The timing problem might indeed be resolution dependent: 100us is probably to 
>short sometimes. 
Time microsecondClockValue gives the time in microseconds, but it does not 
guarantee microsecond resolution, on windows the resolution is still in 
milliseconds. 

--
| col |

col := Array new: 3 streamContents: [ :stream |
1 to: 3 do: [ :x | stream nextPut: Time microsecondClockValue ]
].

col asSet  "a Set(3658909536504622 3658909536503622 3658909536502622)"'
-

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Sven 
Van Caekenberghe
Sent: Sunday, December 11, 2016 11:56 AM
To: Pharo Development List 
Subject: Re: [Pharo-dev] NeoUUIDGenerator>>testTwoSameGenerator - intermittent 
CI failure

Hi Ben,

Thanks for looking into this, it was bothering me for quite some time ;-)

https://pharo.fogbugz.com/f/cases/19453/NeoUUIDGenerator-testTwoSameGenerator-intermittent-CI-failure

Yes, I think the counter roll-over is the problem, stupid of me to to have seen 
this.

The timing problem might indeed be resolution dependent: 100us is probably to 
short sometimes.

I will provide a slice with fixes.

Thanks again !

Regards,

Sven

> On 11 Dec 2016, at 09:07, Ben Coman  wrote:
> 
> For Case [1] I got an unrelated CI failure [2] for
> NeoUUIDGeneratorTests>>#testTwoSameGenerator
> 
> Checking this locally by running this a dozen times...
> 1 to: 1000 do: [:n| last:=n. NeoUUIDGeneratorTests new setUp 
> testTwoSameGenerator ]
> 
> Two distinct failures are apparent...
> 
> 1. Takes longer than expected.
> self assert: (time2 - time1) abs < 100
> last=1 ==> a time difference of 109
> last=1 ==> a time difference of 102
> last=1 ==> a time difference of 155
> last=1 ==> a time difference of 105
> Interesting that whenever this happens its on the first iteration.
> 
> 2. Invalid consecutive ids. 
> self assert: (uuid1 at: 10) + 1 equals: (uuid2 at: 10).
> last=127 ==> TestFailure: Got 256 instead of 0.
> last=828 ==> TestFailure: Got 256 instead of 0.
> last=128 ==> TestFailure: Got 256 instead of 0.
> last=316 ==> TestFailure: Got 256 instead of 0.
> Maybe a problem with rollover?
> 
> So instrumenting a bit:
>   testTwoSameGenerator: n
> | uuid1 uuid2 consecutiveOk time1 time2 timeOk |
> 
> "same generator, consequetive counters"
> consecutiveOk := ((uuid1 at: 10) + 1) = (uuid2 at: 10).
> "same generators, similar clock, within 100 milliseconds"
> time1 := self timeFromUUID: uuid1.
> time2 := self timeFromUUID: uuid2.
> timeOk := (time2 - time1) abs < 100.
> ( timeOk and: [ consecutiveOk ]) ifFalse: [
> Transcript cr;
>show: 'fail n=', (n printPaddedWith: $0 to: 3)  ; tab;
>show: ' time ', ((time2 - time1) printString) , '<100'; tab;
>show: ' uuid ', (((uuid1 at: 10) + 1) printString, '=', (uuid2 at: 
> 10) printString).
> ].
> self assert: consecutiveOk.
> self assert: timeOk.
> 
> From playground running...
> 1 to: 1000 do: [:n|
> NeoUUIDGeneratorTests new setUp testTwoSameGenerator: n].
> Transcript crShow: 'x'.
> 
> Note the 'x' was not output due to one of the consecutiveOk or timeOk asserts 
> triggered each run.
> fail n=001 time 104<100uuid 160=160
> fail n=269 time 2<100  uuid 256=0
> fail n=001 time 152<100uuid 166=166
> fail n=117 time 3<100  uuid 256=0
> fail n=001 time 123<100uuid 128=128
> fail n=278 time 3<100  uuid 256=0
> fail n=001 time 145<100uuid 230=230
> fail n=673 time 1340<100   uuid 141=141
> fail n=707 time 3<100  uuid 256=0
> fail n=001 time 132<100uuid 73=73
> fail n=001 time 117<100uuid 206=206
> fail n=063 time 2<100  uuid 256=0
> fail n=345 time 3<100  uuid 256=0
> 
> Now a strange thing is that after commenting out those two asserts for 
> consecutiveOk and timeOk, the fails at n=001 stop happening.   
> 
> fail n=001 time 141<100uuid 232=232
> x
> x
> fail n=201 time 3<100  uuid 256=0
> fail n=268 time 3<100  uuid 256=0
> fail n=359 time 3<100  uuid 256=0
> fail n=408 time 2<100  uuid 256=0
> fail n=559 time 3<100  uuid 256=0
> x
> fail n=139 time 3<100  uuid 256=0
> fail n=854 time 7<100  uuid 256=0
> x
> fail n=389 time 3<100  uuid 256=0
> fail n=669 time 3<100  uuid 256=0
> fail n=876 time 3<100  uuid 256=0
> fail n=916 time 3<100  uuid 256=0
> fail n=953 time 2<100  uuid 256=0
> fail n=954 time 3<100  uuid 256=0
> x
> fail n=148 time 3<100  uuid 256=0
> fail n=741 time 3<100  uuid 256=0
> x
> fail n=116 time 2<100  uuid 256=0
> fail n=480 time 3<100  uuid 256=0
> x
> 
> After treating the rollover like this... 
> consecutiveOk := ((uuid1 at: 10) + 1) \\ 256 = (uuid2 at: 10).
> 

Re: [Pharo-dev] collection flatCollect: #something VS (collection collect: #something) flattened

[Henrik Nergaard]

>Shouldn't these two code snippets behave the same way?

#flatCollect: expects that aBlock returns a collection for each element (see 
method comment) and only flattens one level, while # flattened expands all sub 
collections it finds: 

#( #(1 #(2) ) ) flatCollect: [ :x | x ]. "#(1 #(2))"
#( #(1 #(2) ) ) flattened. "#(1 2)"


Ps. Using a symbol instead of a block reduces performance.
[ 1 to: 1e9 do: [ :each | each ] ] timeToRun. "0:00:00:02.463"
[ 1 to: 1e9 do: #yourself ] timeToRun. "0:00:00:11.468"

Best regards,
Henrik

-Opprinnelig melding-
Fra: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] På vegne av Julien 
Delplanque
Sendt: 12 January 2017 11:27
Til: Pharo Development List 
Emne: [Pharo-dev] collection flatCollect: #something VS (collection collect: 
#something) flattened

Hello everyone,

While using #flatCollect: on a collection, I realized that, for example, these 
two code snippets do not behave the same way:

#(1 (1)) flatCollect: #yourself. "Raise an error because the array does not 
contain only collections"

(#(1 (1)) collect: #yourself) flattened "Returns #(1 1)

Shouldn't these two code snippets behave the same way?

Thanks in advance for your answers.

Regards,

Julien

Re: [Pharo-dev] collection flatCollect: #something VS (collection collect: #something) flattened

[Henrik Nergaard]

The test was meant to show the overhead when a symbol is used as a message 
argument instead of a block, not the evaluation of each of them by #value:

#(a b c) collect: #asUppercase "#('A' 'B' 'C')"
#(a b c) collect: [ :each | each asUppercase ]. "#('A' 'B' 'C')"


Best regards,
Henrik

-Opprinnelig melding-
Fra: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] På vegne av John Brant
Sendt: 12 January 2017 14:40
Til: pharo-dev@lists.pharo.org
Emne: Re: [Pharo-dev] collection flatCollect: #something VS (collection 
collect: #something) flattened

On 01/12/2017 06:45 AM, Julien Delplanque wrote:
> On 12/01/17 12:32, Henrik Nergaard wrote:
>> Ps. Using a symbol instead of a block reduces performance.
>> [ 1 to: 1e9 do: [ :each | each ] ] timeToRun. "0:00:00:02.463"
>> [ 1 to: 1e9 do: #yourself ] timeToRun. "0:00:00:11.468"
> Wow, I used symbols to make the example clear but I didn't know that.
> That's sad, I think it is sexier to use a symbol to do this kind of 
> things. :(

I'm not sure what this test is supposed to show. The first one is just a loop 
counting to 1 billion inlined in a method. The second one is a message send of 
#to:do: which is implemented as a whileTrue: loop which will send the #value: 
message to #yourself. Essentially, it is showing the time to evaluate 
"#yourself value: someInt" 1 billion times.

I think that a better test to show the performance difference is this:

[ 1 to: 10 do: [ :i | [ :e | e ] value: i ] ] timeToRun. 
"0:00:00:14.917"

[ 1 to: 10 do: [ :i | #yourself value: i ] ] timeToRun. 
"0:00:00:07.846"

These results might lead you to believe that symbols are faster than blocks. 
However, the first one is also creating 1 billion blocks. If we create the 
block once, then blocks are faster:

[ | b | b := [ :e | e ]. 1 to: 10 do: [ :i | b value: i ] ] timeToRun. 
"0:00:00:04.515"

So, if you know how many blocks you will create and how often each block is 
evaluated, you could come up with the optimal solution. Or, you could just 
write your code so the intent is expressed clearly and not worry about 
performance until it is needed.


John Brant

Re: [Pharo-dev] Strange DNU effect on Windows with Pastell

[Henrik Nergaard]

Both #head and #tail is used by MorphTreeNodeMorph (#expandPath: and 
#matchPath:) to select items deeper inside the tree structure and then 
expanding to this.
-
| model morph |
model := ClassTreeExample new.
model openOn: Morph.
model selectItems: { Morph -> BorderedMorph -> AlignmentMorph }.
-

 Changing one should not be done without the other.

Best regards,
Henrik

-Opprinnelig melding-
Fra: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] På vegne av Sven Van 
Caekenberghe
Sendt: 11 January 2017 11:56
Til: Pharo Development List <pharo-dev@lists.pharo.org>
Emne: Re: [Pharo-dev] Strange DNU effect on Windows with Pastell

All good and well, but maybe its me, but I can't see where it is being used ...

> On 11 Jan 2017, at 11:46, Henrik Nergaard <draag...@outlook.com> wrote:
> 
> And Object/Association >> #tail
> 
> Best regards,
> Henrik
> 
> -Opprinnelig melding-
> Fra: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] På vegne av Esteban 
> Lorenzano
> Sendt: 11 January 2017 10:13
> Til: Pharo Development List <pharo-dev@lists.pharo.org>
> Emne: Re: [Pharo-dev] Strange DNU effect on Windows with Pastell
> 
> 
>> On 11 Jan 2017, at 10:12, Esteban Lorenzano <esteba...@gmail.com> wrote:
>> 
>> at least we should rename it as “treeMorphHead”… just “head” is too generic. 
> 
> “treeNodeHead” I meant. 
> 
>> 
>> Esteban
>> 
>> 
>>> On 11 Jan 2017, at 10:03, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>>> 
>>> 
>>>> On 11 Jan 2017, at 09:55, Torsten Bergmann <asta...@gmx.de> wrote:
>>>> 
>>>>> But why the hell would there be a Object>>#head ?!
>>>>> 
>>>>> IMHO such general selectors at this level should not be used unless there 
>>>>> is a very good reason to do so.
>>>>> 
>>>> 
>>>> Yes - some Morphic addition. Version says: BenjaminVanRyseghem in 
>>>> 2013 Only used in MorphTreeNodeMorph and to me this smells. We should nuke 
>>>> it.
>>>> 
>>>> Thx
>>>> T. 
>>> 
>>> Looking in a 6 image, there is also an even uglier implementation in
>>> 
>>> Association>>#head
>>> 
>>> ^ (key isKindOf: Association)
>>> ifTrue: [ key head ]
>>> ifFalse: [ key ]
>>> 
>>> Duh.
>>> 
>>> And I can't seen any senders...
>>> 
>>> 
>> 
> 
> 

Re: [Pharo-dev] Strange DNU effect on Windows with Pastell

[Henrik Nergaard]

And Object/Association >> #tail

Best regards,
Henrik

-Opprinnelig melding-
Fra: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] På vegne av Esteban 
Lorenzano
Sendt: 11 January 2017 10:13
Til: Pharo Development List 
Emne: Re: [Pharo-dev] Strange DNU effect on Windows with Pastell


> On 11 Jan 2017, at 10:12, Esteban Lorenzano  wrote:
> 
> at least we should rename it as “treeMorphHead”… just “head” is too generic. 

“treeNodeHead” I meant. 

> 
> Esteban
> 
> 
>> On 11 Jan 2017, at 10:03, Sven Van Caekenberghe  wrote:
>> 
>> 
>>> On 11 Jan 2017, at 09:55, Torsten Bergmann  wrote:
>>> 
 But why the hell would there be a Object>>#head ?!
 
 IMHO such general selectors at this level should not be used unless there 
 is a very good reason to do so.
 
>>> 
>>> Yes - some Morphic addition. Version says: BenjaminVanRyseghem in 
>>> 2013 Only used in MorphTreeNodeMorph and to me this smells. We should nuke 
>>> it.
>>> 
>>> Thx
>>> T. 
>> 
>> Looking in a 6 image, there is also an even uglier implementation in
>> 
>> Association>>#head
>> 
>>  ^ (key isKindOf: Association)
>>  ifTrue: [ key head ]
>>  ifFalse: [ key ]
>> 
>> Duh.
>> 
>> And I can't seen any senders...
>> 
>> 
> 

Re: [Pharo-dev] Set internal array size

[Henrik Nergaard]

The Set implementation requires the array to have a size > 0.

(Set basicNew initialize: 0) add: #x "Error Zero Devide"

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
Christophe Demarey
Sent: Thursday, December 1, 2016 3:42 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] Set internal array size


> Le 1 déc. 2016 à 15:04, Marcus Denker  a écrit :
> 
> The idea that a set is always created with a minimal size is because we 
> always add at least some elements

not always. You know in some cases 80% of the time, your instances will have an 
empty Set and with some values for the remaining 20%.
If you check in Moose, you should find a lot this pattern.

Re: [Pharo-dev] How to report website text bugs?

[Henrik Nergaard]

SystemNavigation new allLocalCallsOn: 'No change' ofClass: ProtoObject .
"a Set(Delay class>>#delaySchedulerClass:)"

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Esteban 
Lorenzano
Sent: Wednesday, November 30, 2016 12:14 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] How to report website text bugs?


On 30 Nov 2016, at 12:09, Esteban Lorenzano 
> wrote:


On 30 Nov 2016, at 11:26, Tim Mackinnon 
> wrote:

I just tried the new example on the website (factorial is a great example from 
the command line - I like it).

The output is:

$ ./pharo Pharo.image eval "42 factorial"
'No change'
14050061177528798985431426062445115699363840
$


Out of curiosity, What is the ‘No Change’ message above the answer?

no idea :)
obviously… a remaining error :P
and btw… that’s obviously a transcript message.



Esteban




Tim


On 29 Nov 2016, at 08:41, Esteban Lorenzano 
> wrote:

yes, but no need… I already fixed it :)

On 29 Nov 2016, at 09:29, p...@highoctane.be wrote:

Report them on pharo.fogbugz.com

http://pharo.org/contribute-report-bug

Use Project: Websites as the reference.

Phil

On Tue, Nov 29, 2016 at 12:57 AM, Tim Mackinnon 
> wrote:
Hi Guys - how is the best way to report website and text bugs?

As I know the English is not always a first language (and you guys are busy 
writing code anyway) - its up to us native English speakers to chip in where we 
can.

I was pleased to get the notice that on OSX Sierra I need to do something extra 
to get Pharo to work, however the text could be slightly corrected eg. (Bolded 
words changed)

Are you using macOS Sierra?
Due to changes in security policies of macOS, you will need to put the VM in 
the  /Applications folder.
We are working to fix this temporary inconvenience.


Also - the Hello world command line example on the front page doesn’t work on a 
standard Terminal on a Mac (you get an error:

$ ./pharo Pharo.image eval "Stdio stdout << 'Hello,World!'"
-bash: !'": event not found


The culprit is of course the “!” Character so a better example might be:


$ ./pharo Pharo.image eval "Stdio stdout << 'Hello World'"
Hello WorldStdioStream: 'stdout'

Although, in this case, is it expected that the return string is merged with 
some other output text (e.g. the StdioStream:….?). I think its an impressive 
example, but it just doesn’t quite look right?


Tim

Re: [Pharo-dev] Set internal array size

[Henrik Nergaard]

Hashed collections keep a portion of the available memory empty (usually 25%) 
as a partition mechanism to increase lookup speed.

"Normal array"
| col |

col := Smalltalk allClassesAndTraits asArray.

[ col includes: 8; includes: Morph ] bench. "'366.853 per second'"

"Normal set ~75% load"
| set |

set := Smalltalk allClassesAndTraits asSet.

[ set includes: 8; includes: Morph ] bench. "'4,700,967 per second'"


"Set forced to have ~100% load"
| array fullLoadSet |

array := Smalltalk allClassesAndTraits asSet asArray , #(nil).
fullLoadSet:= Set basicNew.
fullLoadSet
instVarNamed: #array put: array;
   instVarNamed: #tally put: array size.

[ fullLoadSet includes: 8; includes: Morph ] bench. "'215.157 per second'"


Best regards,
Henrik


From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
Christophe Demarey
Sent: Thursday, December 1, 2016 11:49 AM
To: Pharo Development List 
Subject: [Pharo-dev] Set internal array size

Hi,

I just discovered a funny thing.
If you create a Set with Set new, you will get a Set with an internal array of 
5 elements (hardcoded in Set class>>#new).
If you ask explicitly a Set for one or no element: Set new: 0 (or a number 
between 0 and 5), you will get an internal array of 7 elements.
This behavior is a bit strange. Either we always need at least 7 elements and 
we need to update Set class>>#new, either the method Set class>>#sizeFor: 
should be updated.

WDYT?

Christophe

Re: [Pharo-dev] :: Separator in class names

[Henrik Nergaard]

+100

I do not think that there should be restrictions on the number of :: separators.
Modified to allow #A::B::Object etc..
---
isValidGlobalName 

self ifEmpty: [ ^ false ]. 

"reserverd default names" 
self = #NameOfSubclass ifTrue: [ ^ false ]. 
self = #TNameOfTrait ifTrue: [ ^ false ]. 

  (self splitOn: '::') allSatisfy: [: part | 
Character supportsNonASCII ifTrue: [ 
(part first isLetter 
and: [ part first isUppercase]) 
and: [ part allSatisfy: [:character | 
character isAlphaNumeric or: [ character = $_ ]]]
]   
ifFalse: [ 
(part first between: $A and: $Z) and: [   
part allSatisfy: [:character | 
(character between: $a and: $z) or: [ 
(character between: $A and: $Z) or: [ 
(character between: $0 and: $9) or: [ 
 character = $_]
] 
]
-

As long as the :: only serve as a visual separator between "namespace(s)" and 
class name then it should not be harder much more harder than to do a 
#copyReplaceAll: '::' with: '' when filing in|out the class to use in a system 
that do not allow :: in class names.

Best regards,
Henrik


-Opprinnelig melding-
Fra: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] På vegne av Torsten 
Bergmann
Sendt: 02 January 2017 12:57
Til: Pharo Development List 
Emne: Re: [Pharo-dev] :: Separator in class names

First of all: happy new year to all Pharo supporters!

Not many of you answered this thread in 2016. Maybe I have more luck in 2017 ;)

So please tell me about the requested change of #isValidGlobalName to allow an 
optional separator in class names. I already communicated possible usages and 
still do not share the fears of Dale that we easily get unportable code with 
that. I guess it will allow us to experiment much easier.

Thanks for taking the time to response and share your own thoughts!

Bye
Torsten

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

[Henrik Nergaard]

Using floats should not be a problem as BitBlt will round these to integers:

| canvas image |

canvas := FormCanvas extent: 100.1@100.2.
canvas fillColor: Color gray.
image := Smalltalk ui icons iconNamed: #error.
canvas image: image at: 2.5@3.9 sourceRect: (1.2@5.3 extent: 42.1@43.4) rule: 
34.

canvas form inspect.


Best regards,
Henrik

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
Stephane Ducasse
Sent: Monday, December 19, 2016 10:09 PM
To: Pharo Development List 
Subject: Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

so did it work?
Is there something that we should do?

On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel 
> wrote:
Okay, trying…

Alexandre


> On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel 
> > wrote:
>
> According to crash.dmp TRMorph>drawOn: draws an image using 
> FormCanvas>>#image:at:sourceRect:rule:  at a coordinate represented by a 
> Float point.
> Try to round it to integer point.
>
> Cheers,
> Alex
>
> On 16 December 2016 at 16:34, Alexandre Bergel 
> > wrote:
> Hi!
>
> Vincent and I are experiencing many crashes from GrafPort>copyBits. It 
> crashes every couple of minutes.
>
> I know that not much can be done so far. Stability is my biggest concern with 
> Pharo :-(
> I use the latest VM.
>
> Cheers,
> Alexandre
>
>
>
>
>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>

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

[Pharo-dev] NumberParser and exponent

[Henrik Nergaard]

Hi,


Apperently the number parser cannot parse '2E+2' correctly, is this a bug or a 
feature.

('2E+2' asNumber = '2e2' asNumber)


Is there any reason to why parsing numbers with uppercase exponent letter is 
not allowed?

(see NumberParser >> #exponentLetters)


The parser has a method named #allowPlusSignInExponent sending self >> 
#allowPlusSign which just returns false.

Is there any reason for not allowing the pluss sign / having it as true instead?

(I guess it should at least be an ivar so it can be configured?).


Best regards,

Henrik

Re: [Pharo-dev] Capitalized

[Henrik Nergaard]

>to "capitalize" is writing a word with its first letter.

The Smalltalk String is not neccessarily just a word, it could be something 
else so the current implementation makes no assumptions of what the string is.

-

| newClass |

newClass := Object subclass: #AbcSomeClass
instanceVariableNames: 'errorCodeName referencePosition instanceVariable'.
newClass instanceVariableNamesDo: [ :aString | | code |
code := String streamContents: [ :aStream | | prefix cap |
prefix := aString first isVowel ifTrue: ['an'] ifFalse: ['a'].
cap := aString capitalized.
aStream
<< aString; << ':'; space; << prefix; << cap;
cr; cr; tab;
<< aString; << ' := '; << prefix; << cap.
].
newClass compile: code classified: 'accessing'
].

newClass browse



>Should we fix this? Do not know about any side effects...

I think it would be better and more clear to then implement a new method called 
something like #onlyCapitalized that removes all other uppercase letters.


Best regards,

Henrik



Fra: Pharo-dev  på vegne av Torsten Bergmann 

Sendt: 15. mars 2017 11:33:35
Til: Pharo Development List
Emne: [Pharo-dev] Capitalized

According to https://en.wikipedia.org/wiki/Capitalization

to "capitalize" is writing a word with its first letter as a capital letter 
(upper-case letter)
AND THE REMAINING LETTERS IN LOWER CASE writing systems.

So

  'SOMETHING' capitalized

currently returns "SOMETHING" in Pharo but should return "Something" according 
to the definition to end up with lowercase.
If we fix this I guess we would also align Pharo with other languages, like C# 
for example [1].

Could be easily changed by replacing "copy" with "asLowercase" in #capitalized:

 capitalized
"Return a copy with the first letter capitalized"
| cap |
self isEmpty ifTrue: [ ^self copy ].
cap := self asLowercase.
cap at: 1 put: (cap at: 1) asUppercase.
^ cap

Should we fix this? Do not know about any side effects...


Note: a) Squeak has the same issue
  b) it fits for #uncapitalized, see [2]
  c) Dont know about ANSI standard or any other ST dialect

Thx
T.


[1] 
https://github.com/srkirkland/Inflector/blob/master/Inflector.Tests/CapitalizeTests.cs
[2] 
https://github.com/srkirkland/Inflector/blob/master/Inflector.Tests/UncapitalizeTests.cs

[Pharo-dev] No Metadata in 7.0

[Henrik Nergaard]

Hi,
I had a look at the Pharo 7.0 today and see metadata for methods (Author and 
timestamp) has been removed*, what is the reason for this?
Having the ability to find methods created around the same time and/or by 
author is quite useful when fixing bugs in the core libraries.
There is also quite a lot of history that is lost as well with this change (I 
am always impressed when I stumble upon methods over 15-20 years old!).

Could this be reverted, please?
[*] all methods have a stamp, but it is the same for all with only a timestamp 
from the bootstrap(?).

Best regards,
Henrik

Re: [Pharo-dev] Sources location inconsistency between WIndows and OSX

[Henrik Nergaard]

Are you sure you have the correct version of .sources?.

It has allways been possible to have the .sources at the .exe (I have allways 
done it that way), (are you sure that the right vm is started, clicking on an 
image might launch a different vm if you have multiple).


What is the output of `OSPlatform current potentialLocationsOfSourcesFile` ?


To debug:

Change PharoFilesOpener>>#ignoreIfFail: no not send ifError: []. and the do 
`SourceFiles ensureOpen`


Best regards,

Henrik




Fra: Pharo-dev  på vegne av Aliaksei Syrel 

Sendt: 28. juni 2017 19:10:19
Til: Pharo Development List
Emne: [Pharo-dev] Sources location inconsistency between WIndows and OSX

Hi,

I just realised that on OSX it is enough to put .sources in the same folder 
with Pharo.app which is extremely cool because there is no need to carry them 
around with images.

However, in case of Window it is different. I tried to put .source in the same 
folder with Pharo.exe but got a notification that sources in the *image* folder 
were not found.

It would be great to unify this behaviour among platforms :)
I prefer OSX .sources location strategy.

Cheers,
Alex

Re: [Pharo-dev] Code colors with dark theme (out of box)

[Henrik Nergaard]

>Looks like changing one color changes back to the default theme coloring ... 
>but I wonder why it
changes the theme when I manipulate only the comment color?
SHPreferences commentStyle class. "SHStyleElement"

Changing any attribue in a ShStyleElement object also sends `SHPreferences 
applyStyle`. This method creates a new styletable based on the SHStyleElement 
objects in the Group class variable in SHPreferences. These object get their 
initial color and emphasis from the the class variable CustomStyleTable also in 
SHPreferences, which is inited from #defaultStyleTable (blueTheme), and this is 
why the whole theme changes when you only change one color.

>Is this a bug?

Probably.


Best regards,

Henrik



Fra: Pharo-dev <pharo-dev-boun...@lists.pharo.org> på vegne av Torsten Bergmann 
<asta...@gmx.de>
Sendt: 27. april 2017 11:51:12
Til: pharo-dev@lists.pharo.org
Emne: Re: [Pharo-dev] Code colors with dark theme (out of box)

Thanks Henrik and Cyril. I now tried on a second machine and the default looks 
fine.

I checked and there was a setting left that changes the color for Smalltalk 
"comments" only:

   SHPreferences commentStyle color: (Color r: 0.06 g: 0.358 b: 0.06 alpha: 1.0)

from grey (Pharo light theme) to greenish (like VisualStudio comments). Because 
this looks
more professional and aligns with Eclipse/VisualStudio/... and others.

Looks like changing one color changes back to the default theme coloring ... 
but I wonder why it
changes the theme when I manipulate only the comment color?

Is this a bug?

Thanks
T.


Gesendet: Donnerstag, 27. April 2017 um 11:33 Uhr
Von: "Henrik Nergaard" <draag...@outlook.com>
An: "Pharo Development List" <pharo-dev@lists.pharo.org>
Betreff: Re: [Pharo-dev] Code colors with dark theme (out of box)

Tested  with a clean 60471  and the correct code theme is used for me (primary 
white text color).

What are these values for you:



--
Smalltalk ui theme. "a Pharo3DarkTheme"
SHTextStylerST80 styleTable = Smalltalk ui theme shStyleTable.  "true"
SHRBTextStyler styleTable = Smalltalk ui theme shStyleTable  "true"
--

My guess is that you have some theme setting that changed just the code color 
back to the default theme coloring.

Best regards,
Henrik





Fra: Pharo-dev <pharo-dev-boun...@lists.pharo.org> på vegne av Torsten Bergmann 
<asta...@gmx.de>
Sendt: 27. april 2017 10:07:42
Til: Pharo Development List
Emne: [Pharo-dev] Code colors with dark theme (out of box)

The damn deal might be done to switch Pharo 6 now to the dark theme - but my 
impression
is that the way we provide it now lets say is "not very comfortable".

When
 - opening Pharo 6.0 Latest update: #60471 (as of today)
 - opening a new Nautilus browser

the code color settings are unreadable (see screenshot).

I suggest to use black text on black background in the future to improve the 
situation
even further ;)

Are there already any bugs to have a better color code scheme for the dark 
theme?

Have fun
T.

Re: [Pharo-dev] Code colors with dark theme (out of box)

[Henrik Nergaard]

Tested  with a clean 60471  and the correct code theme is used for me (primary 
white text color).

What are these values for you:

--
Smalltalk ui theme. "a Pharo3DarkTheme"
SHTextStylerST80 styleTable = Smalltalk ui theme shStyleTable.  "true"
SHRBTextStyler styleTable = Smalltalk ui theme shStyleTable  "true"
--

My guess is that you have some theme setting that changed just the code color 
back to the default theme coloring.

Best regards,
Henrik



Fra: Pharo-dev  på vegne av Torsten Bergmann 

Sendt: 27. april 2017 10:07:42
Til: Pharo Development List
Emne: [Pharo-dev] Code colors with dark theme (out of box)

The damn deal might be done to switch Pharo 6 now to the dark theme - but my 
impression
is that the way we provide it now lets say is "not very comfortable".

When
 - opening Pharo 6.0 Latest update: #60471 (as of today)
 - opening a new Nautilus browser

the code color settings are unreadable (see screenshot).

I suggest to use black text on black background in the future to improve the 
situation
even further ;)

Are there already any bugs to have a better color code scheme for the dark 
theme?

Have fun
T.

Re: [Pharo-dev] confused about hanging pointer

[Henrik Nergaard]

Hi Ben,


---

Smalltalk garbageCollect.
Pharo3DarkTheme allInstances first pointersTo collect: [ :each | each class ]
"{ClassVariable. Context. Context. Context. Context. Context. Context. Context. 
Context. Context. Context}"
---


>I can't understand where in that method a pointer/reference could
remain held. ???


The references are held in contexts created by block closures like 
"[aSystemWindow closeBoxHit]".

These contexts are created because the block closure uses a variable from the 
outer scope.

The block closures in all the #create...BoxFor: methods is not exectued at once 
but used as callbacks for buttons and is why you can still see references to an 
old theme, because the callback is still the same in these buttons.

[aSystemWindow closeBoxHit] could be rewritten to (MessageSend reciever: 
aSystemWindow selector: #closeBoxHit ) making it easier to GC the old theme 
when themes are changed.


Best regards,

Henrik














Fra: Pharo-dev  på vegne av Ben Coman 

Sendt: 24. april 2017 04:50:25
Til: Pharo Development List
Emne: [Pharo-dev] confused about hanging pointer

Background:
I'm looking into
https://pharo.fogbugz.com/f/cases/19973/DarkTheme-tool-bar-icons

Take for example UITheme>>
   windowMaximizeForm
   "Answer the form to use for the maximize button of a window."
   "self haltOnce."
   ^self forms at: #windowMaximize ifAbsent: [  "self haltOnce"
 Form extent: 10@10 depth: Display depth]

If I uncomment the top haltOnce, and then right-click on an item in
the bottom toolbar,
a debug window shows up as expected.

After changing the theme, I would expect "forms" to be nil.
But uncommenting only the second haltOnce inside the block,
then changing "System > Settings > Appearance > User interface theme"
to white then back to dark,
and then right-click on an item in the bottom toolbar,
does *not* produce a debug window.

Now upon booting a freshly downloaded 60469 image...
   Pharo3DarkTheme allInstances size "==> 1"
then after changing  System > Settings > Appearance > User interface theme
to white then back to dark...
   Pharo3DarkTheme allInstances size "==> 2"


Its almost like changing themes creating a new instance of Pharo3DarkTheme,
but it doesn't get installed in the right places.  Preliminary check...

"Booted fresh 60469 image. Opened a playground."
Pharo3DarkTheme allInstances collect: [:i | i identityHash -> i
pointersTo size].
"{748241152->8}"

"Opened System > Settings"
Pharo3DarkTheme allInstances collect: [:i | i identityHash -> i
pointersTo size].
"{748241152->14}"

"1. Changed Appearance > User interface theme to white then back to dark"
Pharo3DarkTheme allInstances collect: [:i | i identityHash -> i
pointersTo size].
"{748241152->6. 954809088->12}"

"2. Changed Appearance > User interface theme to white then back to dark"
Pharo3DarkTheme allInstances collect: [:i | i identityHash -> i
pointersTo size].
"{748241152->6. 954809088->1. 721110784->12}"

"3. Changed Appearance > User interface theme to white then back to dark"
Pharo3DarkTheme allInstances collect: [:i | i identityHash -> i
pointersTo size].
"{748241152->6. 954809088->1. 721110784->1. 127158784->12}"

"Closed settings window."
Smalltalk garbageCollect.
Pharo3DarkTheme allInstances collect: [:i | i identityHash -> i
pointersTo size].
"{748241152->6. 127158784->12}"


Pharo3DarkTheme allInstances first pointersTo inspect.
Pharo3DarkTheme(UITheme)>>createCloseBoxFor:
Pharo3DarkTheme(UIThemeWatery)>>createCollapseBoxFor:
Pharo3DarkTheme(UIThemeWatery)>>createExpandBoxFor:
Pharo3DarkTheme(UITheme)>>createCloseBoxFor:
Pharo3DarkTheme>>createMenuBoxFor:

For a moment I was confused, by seeing only five items,
but of course the sixth was from the block variable "i".


Question: What I really am confused about is, for example in...
UITheme>>createCloseBoxFor: aSystemWindow
"Answer a button for closing the window."
^(self
newCloseControlIn: aSystemWindow
for: aSystemWindow
action: [aSystemWindow closeBoxHit]
help: 'Close this window' translated)
extent: aSystemWindow boxExtent

I can't understand where in that method a pointer/reference could
remain held. ???

cheers -ben

Re: [Pharo-dev] New and richer halt messages

[Henrik Nergaard]

Sounds like a good idea, but please implement them as constructors/class side 
methods in Halt instead of adding even more methods to Object.


"self haltIfTest -> Halt ifTest"


Best regards,

Henrik


Fra: Pharo-dev  på vegne av Denis Kudriashov 

Sendt: 3. juni 2017 21:30:37
Til: Pharo Development List
Emne: Re: [Pharo-dev] New and richer halt messages


2017-06-03 15:21 GMT+02:00 Sean P. DeNigris 
>:
To mirror the existing API, what do you think of:
  - haltOnlyInTest -> #haltIfTest
  - haltOnlyOutOfTest -> #haltIfNotTest
  - haltOnlyMe -> #haltOnly

good names. We need right english overview :)

Re: [Pharo-dev] New and richer halt messages

[Henrik Nergaard]

A simple way of having a "onlyMe" type is to throw another type of error and 
wrap the code execution with an #on:do: catching and resuming Halt.

Here is an example:

---

| cls |

cls := Halt subclass: #CustomHalt.

cls class compile: 'onlyCustomHaltDuring: aBlock
aBlock on: Halt - CustomHalt do: [ :ex | ex resume ]
'.

cls class compile: 'example
self onlyCustomHaltDuring: [
0 crLog.
Halt now.
1 crLog.
Halt once.
2 crLog.
CustomHalt now.
3 crLog.
]
'.

cls example
---

 Best regards,

Henrik


Fra: Pharo-dev  på vegne av Stephane Ducasse 

Sendt: 5. juni 2017 20:57:43
Til: Pharo Development List
Emne: Re: [Pharo-dev] New and richer halt messages

Could be but I like to have message too. Relying too much on tools is
good but when suddently do not have tools because you are in a minimal
kernel then having 3 extra messages should like a good win win situation.

Stef

On Mon, Jun 5, 2017 at 4:06 PM, Ben Coman  wrote:
>
>
> On Mon, Jun 5, 2017 at 5:01 PM, Stephane Ducasse 
> wrote:
>>>
>>> About
>>> Halt only does not convey anything to me.
>>> Halt onlyMe means clearly what is it
>>
>>
>> To me it seems strange/awkward that code in one method will change global
>> debugging state,
>> and it would feel better via direct UI action to add a metalink (IIUC how
>> that would work.)
>> Plus also a global GUI tool to manage breakpoints/metalinks would be good.
>>
>> Yes but when you need you need it.
>> Else what is the alternative:
>> - remove all the halt during the execution.
>> - execute yours
>> - put back the halt if something wrong happens.
>>
>> or
>> - create manually a global.
>> - rewrite all your halt to depend on this global
>> - turn on and off the global to get the desired effects...
>
>
> or hypothetically something like...  right-click code and menu select "break
> here, disable others"
>
> cheers -ben
>
>>
>> Tedious, cumbersome and boring.
>> We can do better.
>>
>>
>>
>>
>>
>> On Mon, Jun 5, 2017 at 4:09 AM, Ben Coman  wrote:
>>>
>>>
>>>
>>> On Mon, Jun 5, 2017 at 5:06 AM, Stephane Ducasse
>>>  wrote:

 What we should consider is that well packaged methods can be in Object.
 The problem is when method in Object are used everywhere and that they
 have nothing to do there.

 About
 Halt only does not convey anything to me.
 Halt onlyMe means clearly what is it
>>>
>>>
>>> To me it seems strange/awkward that code in one method will change global
>>> debugging state,
>>> and it would feel better via direct UI action to add a metalink (IIUC how
>>> that would work.)
>>> Plus also a global GUI tool to manage breakpoints/metalinks would be
>>> good.
>>>
>>>

 For the
 Halt ifTest
 Halt ifNotTest

 Why not. But I would prefer to be really clear.
 I would prefer

 Halt ifInsideTest
 Halt ifOutsideTest
>>>
>>>
>>> These sound good.
>>> cheers -ben
>>>


 Because we are not about a couple of characters.

 Stef



 On Sun, Jun 4, 2017 at 3:09 PM, Cyril Ferlicot D.
  wrote:
>
> Le 04/06/2017 à 11:40, Peter Uhnak a écrit :
> > But then I wouldn't be able to write 1halt. :(
> >
> > Peter
> >
>
> You can still add some startup script :)
>
> I have one compiling a "h" method in object calling halt to be able to
> write "1h" :)
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>

>>>
>>
>

Re: [Pharo-dev] About Git support for windows

[Henrik-Nergaard]

>>Everyone who used filetree with metadata can tell it is super annoying and
destroys the complete experience. 
There has been a fix for this on the issue tracker for some time:
https://pharo.fogbugz.com/f/cases/20251/Write-out-filetree-metadata-in-order

Best regards,
Henrik



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] About Git support for windows

[Henrik Nergaard]

>> but this is still WIP: for example timestamp needs to go to avoid conflicts.

why/how would this cause conflicts versus other changes?




Fra: Pharo-dev  på vegne av Esteban 
Lorenzano 
Sendt: 9. september 2017 11:39:12
Til: Pharo Development List
Emne: Re: [Pharo-dev] About Git support for windows


> On 8 Sep 2017, at 22:02, Eliot Miranda  wrote:
>
> Hi All,
>
>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse  wrote:
>>
>> Hi all
>>
>> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many
>> others :), esteban designed a nice class file format. So that we will
>> not have 2Gb of space on harddisc, problems with long method names and
>> sluggish commits.
>
> Wow, that's great news!  It'll make it much easier to import from Pharo hit 
> repositories.  Thank you, Esteban!
>
> Can someone post the grammar or a description of the syntax asap?

I will commit it with a spec next week.
and I made the parser by hand and simple enough (e.g. I didn’t use RBParser)  
so it can be ported easily to other dialects.

Esteban

>
>>
>> He is waiting at Wien and is probably checking everything right now.
>>
>> It is a nice format because we will be able to use it to communicate
>> by emails using it. So readable, compact and I like it :)
>
> Lovely!  Details please :-)
>
>>
>> Stef
>>
>

Re: [Pharo-dev] [ Pharo 70 ] Build 83 PR 236 introduce-at-at-in-dictionary

[Henrik Nergaard]

The Link to 236 points to something else that is not #at:at:
in 
https://github.com/pharo-project/pharo/commit/00f8cff298cf359b63cee4ab1c0a831829e2354a

Why are new sub dictionaries instansiated as a normal Dictionary instead of 
species/class?
I would expect a sub-Dictionary be  of the same class as its parent.
Here is a test case:
--

| dct key1 key2 subDct |

dct := IdentityDictionary new.
key1 := 'a'.
key2 := key1 copy.
dct
  at: #a at: key1 put: 1;
  at: #a at: key2 put: 2.

subDct := dct at: #a.

TestCase new
  assert: subDct size equals: 2;
  assert: (subDct at: key1) equals: 1;
  assert: (subDct at: key2) equals: 2
--


Best regards,
Henrik

Fra: Pharo-dev  på vegne av Stephane Ducasse 

Sendt: 3. september 2017 15:56:36
Til: Pharo Development List
Emne: [Pharo-dev] [ Pharo 70 ] Build 83 PR 236 introduce-at-at-in-dictionary

https://github.com/pharo-project/pharo/pull/236

https://pharo.fogbugz.com/f/cases/20203/