Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[stepharo]

ere is some interesting event loop stuff from Tcl.


http://wiki.tcl.tk/2567

I wish we had some easy Tk UI building things in Pharo.


Me too :)
First I want Bloc to get out and be ready for integration to Pharo but 
it takes time.




Spec is okay but not intuitive. As it is the only thing that exposes 
the myriad of various Morphs we have and shields us (somewhat) from 
the underlying details, we have to use it, but its explorability is 
really detrimental to the livecoding side of Pharo.


Spec is not to build fun morphic things :)



Phil

On Mon, Oct 3, 2016 at 12:25 PM, Ben Coman > wrote:


On Mon, Oct 3, 2016 at 6:08 PM, Ben Coman mailto:b...@openinworld.com>> wrote:
> On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry
mailto:dimamakh...@gmail.com>> wrote:
>> a JavaScript timeout is a function that takes a block and a
period of time,
>> and after  this period of time, puts the block at the end of
the event
>> queue, to be executed as soon as the runtime is done performing
the tasks in
>> front of it.
>>
>> I am not sure if Pharo has an event queue, so it's a bit harder
to do
>> it(since without one you can't ensure only one thing happens at
a time, and
>> strange things can happen).
>>
>> That said, in simplest terms, imagine writing a clock app for
Pharo, which
>> updates time every second, in JS this would be done by setting
an interval
>> that ticks every 1000ms, and each time places the callback
function(block)
>> at the end of the event queue.
>>
>> Related:
https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ

>
> Pharo has a single threaded VM, but multiple green threads can
run concurrently.
> The closest to the event loop you are thinking of most likely the
> Morphic UI Process
> which you can see using World > Tools > Process Browser.  When
you execute code
> from Playground it runs in that Process (note what Smalltalk
> historically (circa 1970s?) has
> called a Process is today more commonly know as a Green Thread)
>
> If you select Morphic UI Process  you will see its call stack on the
> right, where an interesting method is WorldState>>doOneCycleFor:
> You can gain some insight by turning on auto-update in the Process
> Browser, then open a Browser on WorldState>>doOneCycleFor:
> and put "self haltOnce" at the top, then enable it via...
> Pharo 5: World > System > Enable halt/inspect once.
> Pharo 6: World > Debugging > Enable all break/inspect once.
>
> You will see in the Process Browser that a new Morphic UI Process is
> spawned, and the original Morphic UI Process call stack now has
> #debugProcess at the top
> and a debug window appears that you can step through. Note,
since two
> UI loops are executing here, the image may lock up, but usually its
> fine so hey! live on the edge!


I meant to ask the list about a bug I hit doing this

Putting a "self haltOnce" here...

  WorldState>>doOneCycleNowFor: aWorld
DisplayScreen checkForNewScreenSize.
self haltOnce.
"process user input events"
LastCycleTime := Time millisecondClockValue.
self handsDo: [:h |
self activeHand: h.
h processEvents.
self activeHand: nil.
].
self activeHand: self hands first.
aWorld runStepMethods. "there are currently some variations here"
self displayWorldSafely: aWorld.


When stepping over "self activeHand: nil."
another debugger appears MNU: receiver of "releaseKeyboardFocus:"
is nil
in GLMPagerPanePreviewMorph(Morph)>>delete

  self activeHand
 releaseKeyboardFocus: self;
 releaseMouseFocus: self.


This can obviously be fixed by wrapping "self activeHand" with an
#ifNil:
but alternatively I wonder if the "self activeHand: nil" is really
needed?
It seems redundant since activeHand is set at the top of the loop and
immediately after exiting the loop.
Eliminating it would reduce the propagation of #ifNil: anti-pattern.

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


cheers -ben

>
> In #runStepMethodsIn: you'll see "queue := self class
> deferredUIMessages" for which you enqueue items like this...
>

http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-messages-executed-slowly-td3228060.html


>
> After processing the deferred UI messages, each Morph's #step method
> is processed by #runLocalStepMethodsIn:
> refer... http://wiki.squeak.org/squeak/2096

>
> The display is then rendered by

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[stepharo]

Thanks Ben.

I can tell you that we want to remove all such activeHand. :)

One day it will come.

Stef


Le 3/10/16 à 12:25, Ben Coman a écrit :

On Mon, Oct 3, 2016 at 6:08 PM, Ben Coman  wrote:

On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry  wrote:

a JavaScript timeout is a function that takes a block and a period of time,
and after  this period of time, puts the block at the end of the event
queue, to be executed as soon as the runtime is done performing the tasks in
front of it.

I am not sure if Pharo has an event queue, so it's a bit harder to do
it(since without one you can't ensure only one thing happens at a time, and
strange things can happen).

That said, in simplest terms, imagine writing a clock app for Pharo, which
updates time every second, in JS this would be done by setting an interval
that ticks every 1000ms, and each time places the callback function(block)
at the end of the event queue.

Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ

Pharo has a single threaded VM, but multiple green threads can run concurrently.
The closest to the event loop you are thinking of most likely the
Morphic UI Process
which you can see using World > Tools > Process Browser.  When you execute code
from Playground it runs in that Process (note what Smalltalk
historically (circa 1970s?) has
called a Process is today more commonly know as a Green Thread)

If you select Morphic UI Process  you will see its call stack on the
right, where an interesting method is WorldState>>doOneCycleFor:
You can gain some insight by turning on auto-update in the Process
Browser, then open a Browser on WorldState>>doOneCycleFor:
and put "self haltOnce" at the top, then enable it via...
Pharo 5: World > System > Enable halt/inspect once.
Pharo 6: World > Debugging > Enable all break/inspect once.

You will see in the Process Browser that a new Morphic UI Process is
spawned, and the original Morphic UI Process call stack now has
#debugProcess at the top
and a debug window appears that you can step through.  Note, since two
UI loops are executing here, the image may lock up, but usually its
fine so hey! live on the edge!


I meant to ask the list about a bug I hit doing this

Putting a "self haltOnce" here...

   WorldState>>doOneCycleNowFor: aWorld
 DisplayScreen checkForNewScreenSize.
 self haltOnce.
 "process user input events"
 LastCycleTime := Time millisecondClockValue.
 self handsDo: [:h |
 self activeHand: h.
 h processEvents.
 self activeHand: nil.
 ].
 self activeHand: self hands first.
 aWorld runStepMethods. "there are currently some variations here"
 self displayWorldSafely: aWorld.


When stepping over "self activeHand: nil."
another debugger appears MNU: receiver of "releaseKeyboardFocus:" is nil
in GLMPagerPanePreviewMorph(Morph)>>delete

   self activeHand
  releaseKeyboardFocus: self;
  releaseMouseFocus: self.


This can obviously be fixed by wrapping "self activeHand" with an #ifNil:
but alternatively I wonder if the "self activeHand: nil" is really needed?
It seems redundant since activeHand is set at the top of the loop and
immediately after exiting the loop.
Eliminating it would reduce the propagation of #ifNil: anti-pattern.

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

cheers -ben


In #runStepMethodsIn: you'll see "queue := self class
deferredUIMessages" for which you enqueue items like this...
http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-messages-executed-slowly-td3228060.html

After processing the deferred UI messages, each Morph's #step method
is processed by #runLocalStepMethodsIn:
refer... http://wiki.squeak.org/squeak/2096

The display is then rendered by #displayWorldSafely: calling...
--> #displayWorld
--> #displayWorld:submorphs:
which then is a lot to trace through, but depending on the graphics
back end eventually ends up calling...
Canvas>>fullDrawMorph:which ultimately invokes one of many #drawOn:
or...
AthensCanvas>>fullDrawMorph:which ultimately invokes one of many
#drawOnAthensCanvas:


So, for a regular timed UI animation, you would define your custom
morph's #step and #stepTime methods,
and for lower level stuff you would fork like Dennis suggests.

cheers -ben

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[stepharo]

Le 3/10/16 à 17:25, p...@highoctane.be a écrit :
Case in point, I am submitting a proposal here: 
https://devfest.be/blog/posts/cfp/


That's Google tech event here.

I proposed to showcase MDL in Pharo along with workshop. Let's see how 
it goes...


Nice :)
Cyril will be happy :)

Stef


Phil

On Mon, Oct 3, 2016 at 4:43 PM, Offray Vladimir Luna Cárdenas 
mailto:offray.l...@mutabit.com>> wrote:


Hi,


On 02/10/16 17:13, p...@highoctane.be 
wrote:

[...]

Use it whenever you can, it will force you to understand how
to do real stuff with it properly.

I do hackathons with it.

https://hackernoon.com/hackapost-how-hackathons-can-be-the-best-learning-tool-under-the-sun-9c97e567e0a5




As complementary to the infrastructure, code standards, libraries
and so on, a needed contribution, from the social dynamics
perspective, are hachathons and workshops. We're making them
regularly here (link at [1], in Spanish), with a critical
data/code literacy approach. Last week we have our 5th edition and
this week we're going to make an agile 6th edition.

[1] http://mutabit.com/dataweek/

I found the Pharo community very open to contribution. The fast
feedback loop [2] is experienced here in a very visible way and
most of the time the community is welcoming (with notable few
exceptions, "ad hominen" attacks and poor argumentation, but also
with a good self-correcting feedback from the broader community).

[2]

http://www.slideshare.net/MarcusDenker/perfection-feedback-loops-or-why-worse-is-better-65540840



So is not a perfect place, as any other, but you'll find a way of
contributing that is considered worthy and encouraged and even
supported with economical resources from Pharo Association /
Consorcium from time to time.

Welcome here, you and your contribution ;-),

Offray

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[p...@highoctane.be]

Cool.

Now, I think we should do:

WorldState MinCycleLapse: 16.

So that we get a real 60FPS when moving windows around instead of the
default 20 which is 50FPS, and not as smooth.

Set it at 10 and it is too much, but hey, we have a lot of power these days.

Try to set it to 200 and suffer :-p


Phil



On Mon, Oct 3, 2016 at 8:18 PM, CodeDmitry  wrote:

> You seem to have answered my question as I was revising it D:
>
>
>
> --
> View this message in context: http://forum.world.st/Intro-
> to-Microsoft-COM-for-Smalltalkers-tp4917738p4917916.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>
>

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[CodeDmitry]

You seem to have answered my question as I was revising it D:



--
View this message in context: 
http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917916.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[p...@highoctane.be]

Also, check

MorphicUIManager>>#spawnNewProcess

UIProcess := [
[World doOneCycle.  Processor yield.  false] whileFalse: [].
] newProcess priority: Processor userSchedulingPriority.
UIProcess name: 'Morphic UI Process'.
UIProcess resume

digging into doOneCycle, you'll find:

#doOneCycleFor: aWorld
"Do one cycle of the interaction loop. This method is called *repeatedly *when
the world is running. This is a moderately private method; a better
alternative is usually either to wait for events or to check the state of
things from #step methods."

self interCyclePause: MinCycleLapse.
self doOneCycleNowFor: aWorld.


The interCyclePause is what make the UI timing alignment proper (notice
serverMode) [and some Squeak remnant mention]:

interCyclePause: milliSecs
"delay enough that the previous cycle plus the amount of delay will equal
milliSecs.  If the cycle is already expensive, then no delay occurs.
However, if the system is idly waiting for interaction from the user, the
method will delay for a proportionally long time and cause the overall CPU
usage of *Squeak* to be low.
If self serverMode returns true then, always do a complete delay of 50ms,
independant of my argument. This prevents the freezing problem described in
Mantis #6581"

| wait wait2 |
"*a very long assignment*"
wait := self serverMode
ifTrue: [ 50 ]
ifFalse:
[ wait2 := (lastCycleTime notNil and: [CanSurrenderToOS ~~ false])
ifFalse: [ 0 ]
ifTrue: [ lastCycleTime + milliSecs - Time millisecondClockValue ].

  self flag: 'Issue 14754 - wait2>millisecs is only True for clock
rollover. Remove it once DelayScheduler based on microsecondClock - Ben
Coman 19.01.2015'.  "*< maybe we want this #flag: not to be called all
the time* "
  wait2 > milliSecs
ifTrue: [ 0 ]
ifFalse: [ wait2 ].
].
wait > 0 ifTrue: [ (Delay forMilliseconds: wait) wait ].   "<--- wait
is not #>>wait"

lastCycleTime := Time millisecondClockValue.
CanSurrenderToOS := true.

Now, yeah, how do get stuff to be painted on the  screen?

Like this:

displayWorld: aWorld submorphs: submorphs
"Update this world's display."

| deferredUpdateMode handsToDraw allDamage |

submorphs do: [:m | m fullBounds].  "force re-layout if needed"
self checkIfUpdateNeeded ifFalse: [^ self].  "display is already up-to-date"

deferredUpdateMode := self doDeferredUpdatingFor: aWorld.
deferredUpdateMode ifFalse: [self assuredCanvas].
canvas roundCornersOf: aWorld during:[ | worldDamageRects handDamageRects |
worldDamageRects := self drawWorld: aWorld submorphs: submorphs
invalidAreasOn: canvas.  "repair world's damage on canvas"
"self handsDo:[:h| h noticeDamageRects: worldDamageRects]."
handsToDraw := self selectHandsToDrawForDamage: worldDamageRects.
handDamageRects := handsToDraw collect: [:h | h savePatchFrom: canvas].
allDamage := worldDamageRects, handDamageRects.

handsToDraw reverseDo: [:h | canvas fullDrawMorph: h].  "draw hands onto
world canvas"
].
"*make this true to flash damaged areas for testing*"
self class debugShowDamage ifTrue: [aWorld flashRects: allDamage color:
Color black].

canvas finish.
"quickly copy altered rects of canvas to Display:"
deferredUpdateMode
ifTrue: [self forceDamageToScreen: allDamage]
ifFalse: [canvas showAt: aWorld viewBox origin invalidRects: allDamage].
handsToDraw do: [:h | h restoreSavedPatchOn: canvas].  "restore world
canvas under hands"
Display deferUpdates: false; forceDisplayUpdate.

The VM will take care of throwing the bits to the display in various ways.
Interesting to look how it is done for Windows, OSX, and Linux.

So you have about a full view now.

Timing wise, there is also some interaction with the VM occuring elsewhere.
Pharo is still polling deep inside.  epoll etc isn't there yet, hence the
little idle CPU usage when doing nothing.

Good luck doing this UI trip with other platforms, not to mention change or
instrument it the way you like.

Pharo is really cool for this as it helps in learning about a lot of things.

Want to do sockets?
Do the high level stuff in Pharo and dig in the VM to see how it is done
down under for a set of platforms.

Enjoy.

Phil

On Mon, Oct 3, 2016 at 8:02 PM, p...@highoctane.be 
wrote:

>
>
> On Mon, Oct 3, 2016 at 6:47 PM, CodeDmitry  wrote:
>
>> LOL (in GrowlMorph):
>> is: rect saneWithRespectTo: morphs
>>
>> ^(morphs anySatisfy: [ :morph | morph owner isNotNil and: [morph
>> bounds
>> intersects: rect]]) not
>>
>> for some reason I find this method name quite amusing :3
>>
>
> There are interesting things in there indeed. "Intention revealing"
> enough?
>
>>
>>
>> Let me guess;
>>
>> 1. "World defer: aBlock." defers the event to be called as soon as
>> possible(not necessarily now).
>>
>
> Actually this works for any Morph in 5.0
>
> Morph>>#defer: aValuable
> "aValuable will be executed in the next UI rendering cycle"
> self owner
> ifNotNil: [ self owner defer: aValuable]
> ifNil: [ UIManager default defer: aValuable ]
>
> UIManager (Morphic

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[p...@highoctane.be]

On Mon, Oct 3, 2016 at 6:47 PM, CodeDmitry  wrote:

> LOL (in GrowlMorph):
> is: rect saneWithRespectTo: morphs
>
> ^(morphs anySatisfy: [ :morph | morph owner isNotNil and: [morph
> bounds
> intersects: rect]]) not
>
> for some reason I find this method name quite amusing :3
>

There are interesting things in there indeed. "Intention revealing" enough?

>
>
> Let me guess;
>
> 1. "World defer: aBlock." defers the event to be called as soon as
> possible(not necessarily now).
>

Actually this works for any Morph in 5.0

Morph>>#defer: aValuable
"aValuable will be executed in the next UI rendering cycle"
self owner
ifNotNil: [ self owner defer: aValuable]
ifNil: [ UIManager default defer: aValuable ]

UIManager (MorphicUIManager) will do this at one point (track implementers
'til class side in WorldState)

defer: aValuable
"aValuable will be executed in the next UI rendering cycle"
self addDeferredUIMessage: aValuable.

This will stick it in a queue:

deferredUIMessages

^DeferredUIMessages ifNil: [DeferredUIMessages := WaitfreeQueue  new].

and then, there is interesting black magic going on

runStepMethodsIn: aWorld
"Perform periodic activity inbetween event cycles"
| queue nextInQueue|
"If available dispatch some deferred UI Message"
queue := self class deferredUIMessages.

[(nextInQueue := queue nextOrNil) isNil]"<<
here all is happening ---"
whileFalse: [ nextInQueue value].

self runLocalStepMethodsIn: aWorld. "<< step
methods -"

"The multi-threaded global Transcript needs to be updated periodically and
synchronously with the UI."
Transcript stepGlobal.
 "<< and *this* is some black magic for Transcript "


Fun thing:

stepGlobal
" The superclass method Model>>step indicates a convention that might be
used to interoperate
synchronously with the UI-thread.  However when multiple Transcript windows
are open, their
PluggableTextMorphs share a single instance, from the global Transcript.
To avoid potential trouble,
this method should not be named #step.
As well, we need this method to execute even when no Transcript windows are
open, so the stream
continues to be reset periodically, otherwise it would grow indefinitely.
So this method is invoked
from WorldState>>runStepMethodsIn:.
"

"Next three lines required temporarily to initialize instance variables
added to existing instance"
deferredClear ifNil: [ deferredClear := false ].
deferredEndEntry ifNil: [ deferredEndEntry := false ].
stepContents ifNil: [ stepContents := '' ].
deferredClear ifTrue:
[ deferredClear := false.
stepContents := ''.
self changed: #clearText.
].
deferredEndEntry ifTrue:
[ deferredEndEntry := false.
self critical:
[ stepContents := stream contents.
stream resetContents.
].
self changed: #appendEntry.
].

Just in case one was wondering how Transcript clear actually works, check
this:

clear
" Clear all characters by resetting the stream and voiding any previously
flagged deferredEndEntry.
Redisplays the view by signalling for #step to send #changed: .
"
self
critical: [
deferredClear := true. "<--- magic! ---"
deferredEndEntry := false. "<--- more magic!"
stream reset ]


Good luck to infer that from scratch.





> 2. "[Block] fork" is called immediatly, but on a new thread.
>

Yeah, use forkNamed: aString if you actually want to track the thing easily
in the Process Browser.



> 3. "  wait"  blocks the current thread for specific time
> before continuing.
>

Right.

>
> Now rearrange it into:
>
> [
> 10 seconds wait.
> World defer: [
> Transcript show: 'Hello, World!'.
> ].
> ] fork.
>
> Into
>
> do: aBlock after: nanoTime
> [
> 10 seconds wait. "<--- you need to say something like
> nanoTime asNanoSeconds wait. But careful as Delay works up to milliseconds
> I think, so 5 asNanoseconds asSeconds will just be zero"
> World defer: aBlock.  "<-- OK, World is a WorldMorph, wich extends
> PasteUpMorph, the old World class in Pharo 3.x"
> ] fork.
>
> I guess that all of this shows that there is some flexibility in Pharo
async.

Check the Generator class for some brain twisting with fork.

Run

Generator examplePrimes.

for a start.

Phil

>
>
> --
> View this message in context: http://forum.world.st/Intro-
> to-Microsoft-COM-for-Smalltalkers-tp4917738p4917913.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>
>

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[CodeDmitry]

LOL (in GrowlMorph):
is: rect saneWithRespectTo: morphs

^(morphs anySatisfy: [ :morph | morph owner isNotNil and: [morph bounds
intersects: rect]]) not

for some reason I find this method name quite amusing :3


Let me guess; 

1. "World defer: aBlock." defers the event to be called as soon as
possible(not necessarily now).
2. "[Block] fork" is called immediatly, but on a new thread.
3. "  wait"  blocks the current thread for specific time
before continuing.

Now rearrange it into:

[
10 seconds wait.
World defer: [
Transcript show: 'Hello, World!'.
].
] fork. 

Into

do: aBlock after: nanoTime
[
10 seconds wait.
World defer: aBlock.
] fork.




--
View this message in context: 
http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917913.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo Association

[Esteban Lorenzano]

weird, I just entered and changed some data of my account.
only thing to remark is that on http://association.pharo.org/web/members 
, where you have the login, 
“username” is actually your registered mail.

Esteban

ps: about bountysource, I don’t know :)

> On 3 Oct 2016, at 18:23, Gabriel Cotelli  wrote:
> 
> Same here... probably some manual work is required.
> 
> On Mon, Oct 3, 2016 at 11:52 AM, Esteban A. Maringolo  > wrote:
> 2016-10-03 9:08 GMT-03:00 Marcus Denker  >:
> > On 3 Oct 2016, at 08:59, John Pfersich  > > wrote:
> > I went to the Pharo Association web site (http://association.pharo.org 
> > ) to
> > change my profile, but I didn't find any way to alter it. Am I missing
> > something?
> >
> > There seems to beb a problem with refresh. After logging in, go to
> > http://association.pharo.org/web/members 
> >  and there should be menu entries
> > for editing.
> 
> 
> Also, I've been paying for BountySource Salt since January, and I'm
> not in the list either.
> 
> https://salt.bountysource.com/teams/pharo/supporters 
> 
> 
> Regards!
> 
> Esteban A. Maringolo
> 
> 

Re: [Pharo-users] Pharo Association

[Gabriel Cotelli]

Same here... probably some manual work is required.

On Mon, Oct 3, 2016 at 11:52 AM, Esteban A. Maringolo 
wrote:

> 2016-10-03 9:08 GMT-03:00 Marcus Denker :
> > On 3 Oct 2016, at 08:59, John Pfersich  wrote:
> > I went to the Pharo Association web site (http://association.pharo.org)
> to
> > change my profile, but I didn't find any way to alter it. Am I missing
> > something?
> >
> > There seems to beb a problem with refresh. After logging in, go to
> > http://association.pharo.org/web/members and there should be menu
> entries
> > for editing.
>
>
> Also, I've been paying for BountySource Salt since January, and I'm
> not in the list either.
>
> https://salt.bountysource.com/teams/pharo/supporters
>
> Regards!
>
> Esteban A. Maringolo
>
>

Re: [Pharo-users] Pharo on my Ubuntu laptop :3

[Dimitris Chloupis]

You can install also my ChronosManager project from Package Browser if you
want to take a look at a morphic custom sci fi GUI made mainly with
imagemorphs and of course the necessary technomagic

On Mon, Oct 3, 2016 at 12:04 PM CodeDmitry  wrote:

> Sounds exciting, I've been trying to tweak the window buttons but couldn't
> figure out where to look.
>
>
>
> --
> View this message in context:
> http://forum.world.st/Pharo-on-my-Ubuntu-laptop-3-tp4917833p4917846.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[p...@highoctane.be]

Case in point, I am submitting a proposal here:
https://devfest.be/blog/posts/cfp/

That's Google tech event here.

I proposed to showcase MDL in Pharo along with workshop. Let's see how it
goes...

Phil

On Mon, Oct 3, 2016 at 4:43 PM, Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

> Hi,
>
>
> On 02/10/16 17:13, p...@highoctane.be wrote:
>
> [...]
>
>> Use it whenever you can, it will force you to understand how to do real
>> stuff with it properly.
>>
>> I do hackathons with it. https://hackernoon.com/hackapo
>> st-how-hackathons-can-be-the-best-learning-tool-under-the-
>> sun-9c97e567e0a5
>>
>>
> As complementary to the infrastructure, code standards,  libraries and so
> on, a needed contribution, from the social dynamics perspective, are
> hachathons and workshops. We're making them regularly here (link at [1], in
> Spanish), with a critical data/code literacy approach. Last week we have
> our 5th edition and this week we're going to make an agile 6th edition.
>
> [1] http://mutabit.com/dataweek/
>
> I found the Pharo community very open to contribution. The fast feedback
> loop [2] is experienced here in a very visible way and most of the time the
> community is welcoming (with notable few exceptions, "ad hominen" attacks
> and poor argumentation, but also with a good self-correcting feedback from
> the broader community).
>
> [2] http://www.slideshare.net/MarcusDenker/perfection-feedback-
> loops-or-why-worse-is-better-65540840
>
> So is not a perfect place, as any other, but you'll find a way of
> contributing that is considered worthy and encouraged and even supported
> with economical resources from Pharo Association / Consorcium from time to
> time.
>
> Welcome here, you and your contribution ;-),
>
> Offray
>
>
>

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[p...@highoctane.be]

On Mon, Oct 3, 2016 at 3:00 PM, Thibault Raffaillac <
thibault.raffail...@inria.fr> wrote:

> I am not very fond of event loops in general, because they imply "many
> inputs, one output" (process all pending events, then update screen).
>
For Morphic this is fine, because it displays on one screen, refreshing
> at/around its frequency. But there might be other screens, or
> network-output, file-output, which have different refresh frequencies. Then
> you would want to process input events as they trigger rather than storing
> them in a queue, such that whichever output destination sees the most
> up-to-date state of the program.
>

One upfront queue with several workers is the way to do this fast and in a
scalable way. Nothing new under the sun, Tuxedo has been doing this for
eons, as is any decent TP framework.
https://en.wikipedia.org/wiki/Tuxedo_(software) Most of this has been
rehashed a lot of times bringing nothing new to the table.

Best closest thing for free would be RabbitMQ. Works fine. Even has an MQTT
component, which makes it great for IoT.


> Javascript has this cool function, requestAnimationFrame, which sets a
> one-time callback right before the next redraw. In essence it is an output
> event, allowing some form of reactive programming (no loop, only callbacks
> on input and output).
>

Yes, this is a nice one. This guy uses it a lot to super good effect:
https://www.livecoding.tv/killroy/ - e.g.
https://www.livecoding.tv/killroy/videos/xy8P1-prototypes-and-experiments-javascript-webgl-7


> In Pharo we have InputEventFetcher>>registerHandler: which is great for
> getting input callbacks, but nothing for output :/
> WorldState>>addDeferredUIMessage: is probably a closest match, yet it is
> bound to Morphic, preventing experiments on UI/video games.
>
Any alternatives?
>

This?
http://www.smalltalkhub.com/#!/~Guille/ReactiveExtensions

Maybe this (but not the same thing really)
https://github.com/SquareBracketAssociates/PharoLimbo/blob/master/Xtreams/Xstream.pillar

For video games, well, the ususal update/render with framerate adjustment
is the typical loop.
If the render is too slow vs the expected one things are skipped, several
updates for a render.
And user input is picked at one point during the update bit.
Not really the same as a windowed GUI.

Note that Windows has a queue per app these days (in 3.x days, it was a
single queue for all of Windows, which is why things froze a lot. Same as
current Pharo).


Note also that in Pharo, the InputEventFetcher etc is just the default way
and one can have an image doing things otherwise. Display is the raw thing,
primitives can do whatever, so if you feel like it, you can reinvent
something fully different on the platform.



> Thibault
>
> > Here is some interesting event loop stuff from Tcl.
> >
> > http://wiki.tcl.tk/2567
> >
> > I wish we had some easy Tk UI building things in Pharo.
> >
> > Spec is okay but not intuitive. As it is the only thing that exposes the
> > myriad of various Morphs we have and shields us (somewhat) from the
> > underlying details, we have to use it, but its explorability is really
> > detrimental to the livecoding side of Pharo.
> >
> > Phil
>
>
>

Re: [Pharo-users] Pharo Association

[Esteban A. Maringolo]

2016-10-03 9:08 GMT-03:00 Marcus Denker :
> On 3 Oct 2016, at 08:59, John Pfersich  wrote:
> I went to the Pharo Association web site (http://association.pharo.org) to
> change my profile, but I didn't find any way to alter it. Am I missing
> something?
>
> There seems to beb a problem with refresh. After logging in, go to
> http://association.pharo.org/web/members and there should be menu entries
> for editing.


Also, I've been paying for BountySource Salt since January, and I'm
not in the list either.

https://salt.bountysource.com/teams/pharo/supporters

Regards!

Esteban A. Maringolo

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[Offray Vladimir Luna Cárdenas]

Hi,


On 02/10/16 17:13, p...@highoctane.be wrote:

[...]
Use it whenever you can, it will force you to understand how to do 
real stuff with it properly.


I do hackathons with it. 
https://hackernoon.com/hackapost-how-hackathons-can-be-the-best-learning-tool-under-the-sun-9c97e567e0a5




As complementary to the infrastructure, code standards,  libraries and 
so on, a needed contribution, from the social dynamics perspective, are 
hachathons and workshops. We're making them regularly here (link at [1], 
in Spanish), with a critical data/code literacy approach. Last week we 
have our 5th edition and this week we're going to make an agile 6th edition.


[1] http://mutabit.com/dataweek/

I found the Pharo community very open to contribution. The fast feedback 
loop [2] is experienced here in a very visible way and most of the time 
the community is welcoming (with notable few exceptions, "ad hominen" 
attacks and poor argumentation, but also with a good self-correcting 
feedback from the broader community).


[2] 
http://www.slideshare.net/MarcusDenker/perfection-feedback-loops-or-why-worse-is-better-65540840


So is not a perfect place, as any other, but you'll find a way of 
contributing that is considered worthy and encouraged and even supported 
with economical resources from Pharo Association / Consorcium from time 
to time.


Welcome here, you and your contribution ;-),

Offray

Re: [Pharo-users] Iceberg and git workflow

[Vitor Medina Cruz]

I think it is pretty much what stash does, but it creates a named shelved
change set that stays locally and that can be viewd from a list. You can
create as many as you need and you can unshelve the entire change set,
destroying it or not, or only part of it, even only one change from a
method.

https://www.jetbrains.com/help/idea/2016.2/shelving-changes.html
https://www.jetbrains.com/help/idea/2016.2/unshelving-changes.html

This video shows how version control works on Intellij all around, the
specific part on a very simple usage of the shelve feature can be seen at
8:00. https://www.youtube.com/watch?v=_YW8-9oLgO0

On Mon, Oct 3, 2016 at 10:51 AM, Nicolas Passerini 
wrote:

> No I do not know it, how does it work?
>
> On Mon, Oct 3, 2016 at 3:43 PM, Vitor Medina Cruz 
> wrote:
>
>> Yes, I agree on the case of fake commit, I prefer your usage of git. In
>> the case of stash, I prefer Intellij shelve feature, do you know it? I
>> think it helps me organize better than the stash, I use it all the time.
>>
>> On Mon, Oct 3, 2016 at 10:35 AM, Nicolas Passerini 
>> wrote:
>>
>>>
>>>
>>> On Mon, Oct 3, 2016 at 2:19 PM, Vitor Medina Cruz 
>>> wrote:
>>>
 My two cents: having different images for branches is a good
 workaround, but I will have to manually control those images, while git
 abstracts this a little since I have a way to tell it to stash and bring
 back work in progress. Depending on the project, I think loading a new
 image with a fresh HEAD would require a lot of time to bring all
 dependencies and compile, while just getting changes made at certain point
 from an image and stash them would be much faster, am I wrong?


>>> Just one comment: the proposal is not to have an image for each branch,
>>> you can switch branches using Iceberg. What Iceberg does support not
>>> currently is just the "stash" command.
>>>
>>> Yet it could be slower to create a clean image with your changes, there
>>> are ways to make it faster. Also git stash has its own problems, personally
>>> I am not a fun of that feature, and I've seen lots of time people messing
>>> with it and loosing changes. Moreover, I do not see that saving a "fake"
>>> commit to later delete it as a "best practice", but more as a workaround
>>> because you do not have a better tool.
>>>
>>> For all this grounds is that we do not see it as a priority, because we
>>> think that there are other tools that can replace it (yet we would like to
>>> listen to other opinions) .
>>>
>>
>>
>

Re: [Pharo-users] Iceberg and git workflow

[Nicolas Passerini]

No I do not know it, how does it work?

On Mon, Oct 3, 2016 at 3:43 PM, Vitor Medina Cruz 
wrote:

> Yes, I agree on the case of fake commit, I prefer your usage of git. In
> the case of stash, I prefer Intellij shelve feature, do you know it? I
> think it helps me organize better than the stash, I use it all the time.
>
> On Mon, Oct 3, 2016 at 10:35 AM, Nicolas Passerini 
> wrote:
>
>>
>>
>> On Mon, Oct 3, 2016 at 2:19 PM, Vitor Medina Cruz 
>> wrote:
>>
>>> My two cents: having different images for branches is a good workaround,
>>> but I will have to manually control those images, while git abstracts this
>>> a little since I have a way to tell it to stash and bring back work in
>>> progress. Depending on the project, I think loading a new image with a
>>> fresh HEAD would require a lot of time to bring all dependencies and
>>> compile, while just getting changes made at certain point from an image and
>>> stash them would be much faster, am I wrong?
>>>
>>>
>> Just one comment: the proposal is not to have an image for each branch,
>> you can switch branches using Iceberg. What Iceberg does support not
>> currently is just the "stash" command.
>>
>> Yet it could be slower to create a clean image with your changes, there
>> are ways to make it faster. Also git stash has its own problems, personally
>> I am not a fun of that feature, and I've seen lots of time people messing
>> with it and loosing changes. Moreover, I do not see that saving a "fake"
>> commit to later delete it as a "best practice", but more as a workaround
>> because you do not have a better tool.
>>
>> For all this grounds is that we do not see it as a priority, because we
>> think that there are other tools that can replace it (yet we would like to
>> listen to other opinions) .
>>
>
>

Re: [Pharo-users] Iceberg and git workflow

[Vitor Medina Cruz]

Yes, I agree on the case of fake commit, I prefer your usage of git. In the
case of stash, I prefer Intellij shelve feature, do you know it? I think it
helps me organize better than the stash, I use it all the time.

On Mon, Oct 3, 2016 at 10:35 AM, Nicolas Passerini 
wrote:

>
>
> On Mon, Oct 3, 2016 at 2:19 PM, Vitor Medina Cruz 
> wrote:
>
>> My two cents: having different images for branches is a good workaround,
>> but I will have to manually control those images, while git abstracts this
>> a little since I have a way to tell it to stash and bring back work in
>> progress. Depending on the project, I think loading a new image with a
>> fresh HEAD would require a lot of time to bring all dependencies and
>> compile, while just getting changes made at certain point from an image and
>> stash them would be much faster, am I wrong?
>>
>>
> Just one comment: the proposal is not to have an image for each branch,
> you can switch branches using Iceberg. What Iceberg does support not
> currently is just the "stash" command.
>
> Yet it could be slower to create a clean image with your changes, there
> are ways to make it faster. Also git stash has its own problems, personally
> I am not a fun of that feature, and I've seen lots of time people messing
> with it and loosing changes. Moreover, I do not see that saving a "fake"
> commit to later delete it as a "best practice", but more as a workaround
> because you do not have a better tool.
>
> For all this grounds is that we do not see it as a priority, because we
> think that there are other tools that can replace it (yet we would like to
> listen to other opinions) .
>

Re: [Pharo-users] Iceberg and git workflow

[Nicolas Passerini]

On Mon, Oct 3, 2016 at 2:19 PM, Vitor Medina Cruz 
wrote:

> My two cents: having different images for branches is a good workaround,
> but I will have to manually control those images, while git abstracts this
> a little since I have a way to tell it to stash and bring back work in
> progress. Depending on the project, I think loading a new image with a
> fresh HEAD would require a lot of time to bring all dependencies and
> compile, while just getting changes made at certain point from an image and
> stash them would be much faster, am I wrong?
>
>
Just one comment: the proposal is not to have an image for each branch, you
can switch branches using Iceberg. What Iceberg does support not currently
is just the "stash" command.

Yet it could be slower to create a clean image with your changes, there are
ways to make it faster. Also git stash has its own problems, personally I
am not a fun of that feature, and I've seen lots of time people messing
with it and loosing changes. Moreover, I do not see that saving a "fake"
commit to later delete it as a "best practice", but more as a workaround
because you do not have a better tool.

For all this grounds is that we do not see it as a priority, because we
think that there are other tools that can replace it (yet we would like to
listen to other opinions) .

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[Thibault Raffaillac]

I am not very fond of event loops in general, because they imply "many inputs, 
one output" (process all pending events, then update screen).
For Morphic this is fine, because it displays on one screen, refreshing 
at/around its frequency. But there might be other screens, or network-output, 
file-output, which have different refresh frequencies. Then you would want to 
process input events as they trigger rather than storing them in a queue, such 
that whichever output destination sees the most up-to-date state of the program.

Javascript has this cool function, requestAnimationFrame, which sets a one-time 
callback right before the next redraw. In essence it is an output event, 
allowing some form of reactive programming (no loop, only callbacks on input 
and output).
In Pharo we have InputEventFetcher>>registerHandler: which is great for getting 
input callbacks, but nothing for output :/
WorldState>>addDeferredUIMessage: is probably a closest match, yet it is bound 
to Morphic, preventing experiments on UI/video games.

Any alternatives?

Thibault

> Here is some interesting event loop stuff from Tcl.
> 
> http://wiki.tcl.tk/2567
> 
> I wish we had some easy Tk UI building things in Pharo.
> 
> Spec is okay but not intuitive. As it is the only thing that exposes the
> myriad of various Morphs we have and shields us (somewhat) from the
> underlying details, we have to use it, but its explorability is really
> detrimental to the livecoding side of Pharo.
> 
> Phil

Re: [Pharo-users] Iceberg and git workflow

[Vitor Medina Cruz]

My two cents: having different images for branches is a good workaround,
but I will have to manually control those images, while git abstracts this
a little since I have a way to tell it to stash and bring back work in
progress. Depending on the project, I think loading a new image with a
fresh HEAD would require a lot of time to bring all dependencies and
compile, while just getting changes made at certain point from an image and
stash them would be much faster, am I wrong?

On Tue, Sep 13, 2016 at 6:20 AM, Nicolas Passerini 
wrote:

> Hi Holger, I think that both patterns are currently supported (in beta
> version), but maybe we do not use exactly the same tools.
>
> First, Iceberg does not use the concept of "stash". The git stash changes
> the file in your git working copy (on your file system), while your
> (modified) code is not there, is in the Pharo image.
>
> Going deeper into it, we understand git is very powerful but we do not
> believe that git is the ultimate perfect code versioning tool. We think
> that there are some git usage patterns that tend to be difficult to
> understand so we are trying to create a better abstraction on top of that.
> Also we would like to come up with an abstraction that works not only for
> git but for other repositories.
>
> So, we try to support the kind of requirements you are worried about, but
> maybe not in the same way that the command line tools you are used to. I
> also have been working with git in languages like Scala, Javascript, Xtend,
> etc and I was used to the command line tools... so now the task for me is
> to try to understand: which of all those things I was used to do were
> really necessary and which of them are just boilerplate I need to do
> because of my tools are too low level?
>
> Maybe your experience can help us answer that question.
>
>
>> a.) If current HEAD is same as origin/master
>>
>> $ git stash (stash away my not finished changes)
>> $ vi code.c fix..
>> $ git commit -a -c "subject
>>
>> long explanation of fix
>> reference to bug"
>> $ git stash apply (and go back to working on my feature)
>>
>>
> So, why is this better than having a new image with a clean version of
> HEAD?
>
>
>> b.) E.g. if I finished n-commits but I am not fully done
>>
>
> For this I would propose a slightly different pattern:
>
>>
>> # store my work
>> $ git commit -a -m "Work In Progress hack.."
>>
>
> You can commit, ok... but also you could just save the image with your
> work in progress, no need to create a hacky commit.
>
>
>> $ git checkout -b new-feature-branch
>>
>> # go back to master
>> $ git checkout master
>> $ git reset --hard origin/master (to restore)
>>
>
> To avoid reset, I would propose to leave master like that and put the new
> work in a clean branch, starting on origin/master.
>
> In git-command-line language it would be:
> git checkout -b fix origin/master
>
> So you create a new branch for your fix out of origin/master, leaving the
> original branch untouched.
>
>
>>
>> # work on the fix
>> $ vi code.c fix..
>> $ git commit -a -c "fix..."
>>
>> No problems here... just we do not use vi for editing code :)
>
>
>> # go back and continue on my fix
>> $ git checkout new-feature-branch
>>
> $ git rebase origin/master
>> $ git reset HEAD^1
>> .. continue to work
>>
>>  Several things here. First, I think that everything is simpler if you
> just leave your original branch untouched, so you could re-checkout that
> branch without the need for reset and removing hacky commits. But even more
> interesting if you agree to have two images one for each task, you just go
> back to your first image and everything is just like you left it, including
> open windows and whatever task you were doing. I think that is a beautiful
> value of Pharo I would not like to loose.
>
> The only thing left would be to incorporate the fix into this image, right
> now we do not support rebase, you would need to merge... but I understand
> why one would prefer rebase in this scenario, at some point we will support
> both options.
>
>
> So, to sum up. I am not trying to replicate in Pharo the way I used to
> work in Javascript... I think that would be silly. Instead, we are trying
> to take the good stuff of git into Pharo, but without loosing all the good
> stuff of Pharo.
>

Re: [Pharo-users] 19169 Debugging World>>doOneCycleNowFor: induces debugger MNU (was Re: Intro to Microsoft COM for Smalltalkers)

[Denis Kudriashov]

So it is not related to Ronie changes which is good because they are main
step for multi windows support

2016-10-03 13:44 GMT+02:00 Ben Coman :

> On Mon, Oct 3, 2016 at 7:08 PM, Denis Kudriashov 
> wrote:
> > Hi Ben.
> >
> > 2016-10-03 12:37 GMT+02:00 Ben Coman :
> >>
> >> A further curiousity occurs to me.  With this being executed 20 times
> >> a second or more, how can the active hand ever be anything other than
> >> the primary hand?
> >> Why isn't the active hand stored, all hands cycled through processing
> >> events, then the active hand restored??
> >
> >
> > Previous version of method was also with nil at the end:
> >
> > self handsDo: [:h |
> > ActiveHand := h.
> > h processEvents.
> > ActiveHand := nil
> > ].
> >
> > Could you try your test on previous version of Pharo?
> >
>
> It happens in...
> * 60246 - MNU #releaseKeyboardFocus: in GLMPagerPanePreviewMorph(
> Morph)>>delete
> up stack from GTGenericStackDebugger>>updateBrowser
> * 50760 - MNU #releaseKeyboardFocus: in GLMPagerPanePreviewMorph(
> Morph)>>delete
> up stack from GTGenericStackDebugger>>updateBrowser
> * 40626 - MNU #newKeyboardFocus:  in NewList(Morph)>>takeKEyboardFocus
> up stack from SpecDebugger>> updateReceiverInspectorFromCon
> text:
>
> Must just be a rarely-debugged corner of the system.
>
> cheers -ben
>
>

Re: [Pharo-users] Pharo Association

[Marcus Denker]

> On 3 Oct 2016, at 08:59, John Pfersich  wrote:
> 
> I went to the Pharo Association web site (http://association.pharo.org 
> ) to change my profile, but I 
> didn't find any way to alter it. Am I missing something?
> 

There seems to beb a problem with refresh. After logging in, go to 
http://association.pharo.org/web/members 
 and there should be menu entries for 
editing.

Marcus

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[p...@highoctane.be]

Here is some interesting event loop stuff from Tcl.

http://wiki.tcl.tk/2567

I wish we had some easy Tk UI building things in Pharo.

Spec is okay but not intuitive. As it is the only thing that exposes the
myriad of various Morphs we have and shields us (somewhat) from the
underlying details, we have to use it, but its explorability is really
detrimental to the livecoding side of Pharo.

Phil

On Mon, Oct 3, 2016 at 12:25 PM, Ben Coman  wrote:

> On Mon, Oct 3, 2016 at 6:08 PM, Ben Coman  wrote:
> > On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry 
> wrote:
> >> a JavaScript timeout is a function that takes a block and a period of
> time,
> >> and after  this period of time, puts the block at the end of the event
> >> queue, to be executed as soon as the runtime is done performing the
> tasks in
> >> front of it.
> >>
> >> I am not sure if Pharo has an event queue, so it's a bit harder to do
> >> it(since without one you can't ensure only one thing happens at a time,
> and
> >> strange things can happen).
> >>
> >> That said, in simplest terms, imagine writing a clock app for Pharo,
> which
> >> updates time every second, in JS this would be done by setting an
> interval
> >> that ticks every 1000ms, and each time places the callback
> function(block)
> >> at the end of the event queue.
> >>
> >> Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ
> >
> > Pharo has a single threaded VM, but multiple green threads can run
> concurrently.
> > The closest to the event loop you are thinking of most likely the
> > Morphic UI Process
> > which you can see using World > Tools > Process Browser.  When you
> execute code
> > from Playground it runs in that Process (note what Smalltalk
> > historically (circa 1970s?) has
> > called a Process is today more commonly know as a Green Thread)
> >
> > If you select Morphic UI Process  you will see its call stack on the
> > right, where an interesting method is WorldState>>doOneCycleFor:
> > You can gain some insight by turning on auto-update in the Process
> > Browser, then open a Browser on WorldState>>doOneCycleFor:
> > and put "self haltOnce" at the top, then enable it via...
> > Pharo 5: World > System > Enable halt/inspect once.
> > Pharo 6: World > Debugging > Enable all break/inspect once.
> >
> > You will see in the Process Browser that a new Morphic UI Process is
> > spawned, and the original Morphic UI Process call stack now has
> > #debugProcess at the top
> > and a debug window appears that you can step through.  Note, since two
> > UI loops are executing here, the image may lock up, but usually its
> > fine so hey! live on the edge!
>
>
> I meant to ask the list about a bug I hit doing this
>
> Putting a "self haltOnce" here...
>
>   WorldState>>doOneCycleNowFor: aWorld
> DisplayScreen checkForNewScreenSize.
> self haltOnce.
> "process user input events"
> LastCycleTime := Time millisecondClockValue.
> self handsDo: [:h |
> self activeHand: h.
> h processEvents.
> self activeHand: nil.
> ].
> self activeHand: self hands first.
> aWorld runStepMethods. "there are currently some variations here"
> self displayWorldSafely: aWorld.
>
>
> When stepping over "self activeHand: nil."
> another debugger appears MNU: receiver of "releaseKeyboardFocus:" is nil
> in GLMPagerPanePreviewMorph(Morph)>>delete
>
>   self activeHand
>  releaseKeyboardFocus: self;
>  releaseMouseFocus: self.
>
>
> This can obviously be fixed by wrapping "self activeHand" with an #ifNil:
> but alternatively I wonder if the "self activeHand: nil" is really needed?
> It seems redundant since activeHand is set at the top of the loop and
> immediately after exiting the loop.
> Eliminating it would reduce the propagation of #ifNil: anti-pattern.
>
> https://pharo.fogbugz.com/default.asp?19169
>
> cheers -ben
>
> >
> > In #runStepMethodsIn: you'll see "queue := self class
> > deferredUIMessages" for which you enqueue items like this...
> > http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-
> messages-executed-slowly-td3228060.html
> >
> > After processing the deferred UI messages, each Morph's #step method
> > is processed by #runLocalStepMethodsIn:
> > refer... http://wiki.squeak.org/squeak/2096
> >
> > The display is then rendered by #displayWorldSafely: calling...
> > --> #displayWorld
> > --> #displayWorld:submorphs:
> > which then is a lot to trace through, but depending on the graphics
> > back end eventually ends up calling...
> > Canvas>>fullDrawMorph:which ultimately invokes one of many #drawOn:
> > or...
> > AthensCanvas>>fullDrawMorph:which ultimately invokes one of many
> > #drawOnAthensCanvas:
> >
> >
> > So, for a regular timed UI animation, you would define your custom
> > morph's #step and #stepTime methods,
> > and for lower level stuff you would fork like Dennis suggests.
> >
> > cheers -ben
>
>
>

[Pharo-users] 19169 Debugging World>>doOneCycleNowFor: induces debugger MNU (was Re: Intro to Microsoft COM for Smalltalkers)

[Ben Coman]

On Mon, Oct 3, 2016 at 7:08 PM, Denis Kudriashov  wrote:
> Hi Ben.
>
> 2016-10-03 12:37 GMT+02:00 Ben Coman :
>>
>> A further curiousity occurs to me.  With this being executed 20 times
>> a second or more, how can the active hand ever be anything other than
>> the primary hand?
>> Why isn't the active hand stored, all hands cycled through processing
>> events, then the active hand restored??
>
>
> Previous version of method was also with nil at the end:
>
> self handsDo: [:h |
> ActiveHand := h.
> h processEvents.
> ActiveHand := nil
> ].
>
> Could you try your test on previous version of Pharo?
>

It happens in...
* 60246 - MNU #releaseKeyboardFocus: in GLMPagerPanePreviewMorph(Morph)>>delete
up stack from GTGenericStackDebugger>>updateBrowser
* 50760 - MNU #releaseKeyboardFocus: in GLMPagerPanePreviewMorph(Morph)>>delete
up stack from GTGenericStackDebugger>>updateBrowser
* 40626 - MNU #newKeyboardFocus:  in NewList(Morph)>>takeKEyboardFocus
up stack from SpecDebugger>> updateReceiverInspectorFromContext:

Must just be a rarely-debugged corner of the system.

cheers -ben

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[p...@highoctane.be]

A good trick is to use raw Display output.

Display getCanvas
drawString: 'hello'
from: 1
to: 5
autoBoundAt: 0 @ 0
font: nil
color: Color black.



On Mon, Oct 3, 2016 at 12:25 PM, Ben Coman  wrote:

> On Mon, Oct 3, 2016 at 6:08 PM, Ben Coman  wrote:
> > On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry 
> wrote:
> >> a JavaScript timeout is a function that takes a block and a period of
> time,
> >> and after  this period of time, puts the block at the end of the event
> >> queue, to be executed as soon as the runtime is done performing the
> tasks in
> >> front of it.
> >>
> >> I am not sure if Pharo has an event queue, so it's a bit harder to do
> >> it(since without one you can't ensure only one thing happens at a time,
> and
> >> strange things can happen).
> >>
> >> That said, in simplest terms, imagine writing a clock app for Pharo,
> which
> >> updates time every second, in JS this would be done by setting an
> interval
> >> that ticks every 1000ms, and each time places the callback
> function(block)
> >> at the end of the event queue.
> >>
> >> Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ
> >
> > Pharo has a single threaded VM, but multiple green threads can run
> concurrently.
> > The closest to the event loop you are thinking of most likely the
> > Morphic UI Process
> > which you can see using World > Tools > Process Browser.  When you
> execute code
> > from Playground it runs in that Process (note what Smalltalk
> > historically (circa 1970s?) has
> > called a Process is today more commonly know as a Green Thread)
> >
> > If you select Morphic UI Process  you will see its call stack on the
> > right, where an interesting method is WorldState>>doOneCycleFor:
> > You can gain some insight by turning on auto-update in the Process
> > Browser, then open a Browser on WorldState>>doOneCycleFor:
> > and put "self haltOnce" at the top, then enable it via...
> > Pharo 5: World > System > Enable halt/inspect once.
> > Pharo 6: World > Debugging > Enable all break/inspect once.
> >
> > You will see in the Process Browser that a new Morphic UI Process is
> > spawned, and the original Morphic UI Process call stack now has
> > #debugProcess at the top
> > and a debug window appears that you can step through.  Note, since two
> > UI loops are executing here, the image may lock up, but usually its
> > fine so hey! live on the edge!
>
>
> I meant to ask the list about a bug I hit doing this
>
> Putting a "self haltOnce" here...
>
>   WorldState>>doOneCycleNowFor: aWorld
> DisplayScreen checkForNewScreenSize.
> self haltOnce.
> "process user input events"
> LastCycleTime := Time millisecondClockValue.
> self handsDo: [:h |
> self activeHand: h.
> h processEvents.
> self activeHand: nil.
> ].
> self activeHand: self hands first.
> aWorld runStepMethods. "there are currently some variations here"
> self displayWorldSafely: aWorld.
>
>
> When stepping over "self activeHand: nil."
> another debugger appears MNU: receiver of "releaseKeyboardFocus:" is nil
> in GLMPagerPanePreviewMorph(Morph)>>delete
>
>   self activeHand
>  releaseKeyboardFocus: self;
>  releaseMouseFocus: self.
>
>
> This can obviously be fixed by wrapping "self activeHand" with an #ifNil:
> but alternatively I wonder if the "self activeHand: nil" is really needed?
> It seems redundant since activeHand is set at the top of the loop and
> immediately after exiting the loop.
> Eliminating it would reduce the propagation of #ifNil: anti-pattern.
>
> https://pharo.fogbugz.com/default.asp?19169
>
> cheers -ben
>
> >
> > In #runStepMethodsIn: you'll see "queue := self class
> > deferredUIMessages" for which you enqueue items like this...
> > http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-
> messages-executed-slowly-td3228060.html
> >
> > After processing the deferred UI messages, each Morph's #step method
> > is processed by #runLocalStepMethodsIn:
> > refer... http://wiki.squeak.org/squeak/2096
> >
> > The display is then rendered by #displayWorldSafely: calling...
> > --> #displayWorld
> > --> #displayWorld:submorphs:
> > which then is a lot to trace through, but depending on the graphics
> > back end eventually ends up calling...
> > Canvas>>fullDrawMorph:which ultimately invokes one of many #drawOn:
> > or...
> > AthensCanvas>>fullDrawMorph:which ultimately invokes one of many
> > #drawOnAthensCanvas:
> >
> >
> > So, for a regular timed UI animation, you would define your custom
> > morph's #step and #stepTime methods,
> > and for lower level stuff you would fork like Dennis suggests.
> >
> > cheers -ben
>
>
>

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[p...@highoctane.be]

There has been some serious refactoring occuring in these specific bowels
of the beast.

Phil

On Mon, Oct 3, 2016 at 1:08 PM, Denis Kudriashov 
wrote:

> Hi Ben.
>
> 2016-10-03 12:37 GMT+02:00 Ben Coman :
>
>> A further curiousity occurs to me.  With this being executed 20 times
>> a second or more, how can the active hand ever be anything other than
>> the primary hand?
>> Why isn't the active hand stored, all hands cycled through processing
>> events, then the active hand restored??
>>
>
> Previous version of method was also with nil at the end:
>
> self handsDo: [:h |
> ActiveHand := h.
> h processEvents.
> ActiveHand := nil
> ].
>
> Could you try your test on previous version of Pharo?
>
>

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[p...@highoctane.be]

UIManager>>#defer: aBlock can be useful too.

defer: aBlock
" Evaluate the given Block in the UI thread as soon as there is nothing
scheduled. Evaluate immediately when there is no UI"
aBlock value



For some fun, check also GrowlMorph

10 timesRepeat: [
(GrowlMorph openWithLabel: 'The time' contents: DateAndTime now)
" vanishDelay: 1000;
resetVanishTimer".
World doOneCycle ].


inspect how vanishDelay: works, so that you can get the same kind of thing
as a JS

setTimeout(function(){ alert("Hello"); }, 3000);

Phil



On Mon, Oct 3, 2016 at 12:08 PM, Ben Coman  wrote:
>
> On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry  wrote:
> > a JavaScript timeout is a function that takes a block and a period of
time,
> > and after  this period of time, puts the block at the end of the event
> > queue, to be executed as soon as the runtime is done performing the
tasks in
> > front of it.
> >
> > I am not sure if Pharo has an event queue, so it's a bit harder to do
> > it(since without one you can't ensure only one thing happens at a time,
and
> > strange things can happen).
> >
> > That said, in simplest terms, imagine writing a clock app for Pharo,
which
> > updates time every second, in JS this would be done by setting an
interval
> > that ticks every 1000ms, and each time places the callback
function(block)
> > at the end of the event queue.
> >
> > Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ
>
> Pharo has a single threaded VM, but multiple green threads can run
concurrently.
> The closest to the event loop you are thinking of most likely the
> Morphic UI Process
> which you can see using World > Tools > Process Browser.  When you
execute code
> from Playground it runs in that Process (note what Smalltalk
> historically (circa 1970s?) has
> called a Process is today more commonly know as a Green Thread)
>
> If you select Morphic UI Process  you will see its call stack on the
> right, where an interesting method is WorldState>>doOneCycleFor:
> You can gain some insight by turning on auto-update in the Process
> Browser, then open a Browser on WorldState>>doOneCycleFor:
> and put "self haltOnce" at the top, then enable it via...
> Pharo 5: World > System > Enable halt/inspect once.
> Pharo 6: World > Debugging > Enable all break/inspect once.
>
> You will see in the Process Browser that a new Morphic UI Process is
> spawned, and the original Morphic UI Process call stack now has
> #debugProcess at the top
> and a debug window appears that you can step through.  Note, since two
> UI loops are executing here, the image may lock up, but usually its
> fine so hey! live on the edge!
>
> In #runStepMethodsIn: you'll see "queue := self class
> deferredUIMessages" for which you enqueue items like this...
>
http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-messages-executed-slowly-td3228060.html
>
> After processing the deferred UI messages, each Morph's #step method
> is processed by #runLocalStepMethodsIn:
> refer... http://wiki.squeak.org/squeak/2096
>
> The display is then rendered by #displayWorldSafely: calling...
> --> #displayWorld
> --> #displayWorld:submorphs:
> which then is a lot to trace through, but depending on the graphics
> back end eventually ends up calling...
> Canvas>>fullDrawMorph:which ultimately invokes one of many #drawOn:
> or...
> AthensCanvas>>fullDrawMorph:which ultimately invokes one of many
> #drawOnAthensCanvas:
>
>
> So, for a regular timed UI animation, you would define your custom
> morph's #step and #stepTime methods,
> and for lower level stuff you would fork like Dennis suggests.
>
> cheers -ben
>
>

Re: [Pharo-users] Pharo on my Ubuntu laptop :3

[p...@highoctane.be]

SystemWindow can be a good start.


On Mon, Oct 3, 2016 at 10:57 AM, CodeDmitry  wrote:

> Sounds exciting, I've been trying to tweak the window buttons but couldn't
> figure out where to look.
>
>
>
> --
> View this message in context: http://forum.world.st/Pharo-
> on-my-Ubuntu-laptop-3-tp4917833p4917846.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>
>

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[Denis Kudriashov]

Hi Ben.

2016-10-03 12:37 GMT+02:00 Ben Coman :

> A further curiousity occurs to me.  With this being executed 20 times
> a second or more, how can the active hand ever be anything other than
> the primary hand?
> Why isn't the active hand stored, all hands cycled through processing
> events, then the active hand restored??
>

Previous version of method was also with nil at the end:

self handsDo: [:h |
ActiveHand := h.
h processEvents.
ActiveHand := nil
].

Could you try your test on previous version of Pharo?

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[Ben Coman]

On Mon, Oct 3, 2016 at 6:25 PM, Ben Coman  wrote:
> On Mon, Oct 3, 2016 at 6:08 PM, Ben Coman  wrote:
>> On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry  wrote:
>>> a JavaScript timeout is a function that takes a block and a period of time,
>>> and after  this period of time, puts the block at the end of the event
>>> queue, to be executed as soon as the runtime is done performing the tasks in
>>> front of it.
>>>
>>> I am not sure if Pharo has an event queue, so it's a bit harder to do
>>> it(since without one you can't ensure only one thing happens at a time, and
>>> strange things can happen).
>>>
>>> That said, in simplest terms, imagine writing a clock app for Pharo, which
>>> updates time every second, in JS this would be done by setting an interval
>>> that ticks every 1000ms, and each time places the callback function(block)
>>> at the end of the event queue.
>>>
>>> Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ
>>
>> Pharo has a single threaded VM, but multiple green threads can run 
>> concurrently.
>> The closest to the event loop you are thinking of most likely the
>> Morphic UI Process
>> which you can see using World > Tools > Process Browser.  When you execute 
>> code
>> from Playground it runs in that Process (note what Smalltalk
>> historically (circa 1970s?) has
>> called a Process is today more commonly know as a Green Thread)
>>
>> If you select Morphic UI Process  you will see its call stack on the
>> right, where an interesting method is WorldState>>doOneCycleFor:
>> You can gain some insight by turning on auto-update in the Process
>> Browser, then open a Browser on WorldState>>doOneCycleFor:
>> and put "self haltOnce" at the top, then enable it via...
>> Pharo 5: World > System > Enable halt/inspect once.
>> Pharo 6: World > Debugging > Enable all break/inspect once.
>>
>> You will see in the Process Browser that a new Morphic UI Process is
>> spawned, and the original Morphic UI Process call stack now has
>> #debugProcess at the top
>> and a debug window appears that you can step through.  Note, since two
>> UI loops are executing here, the image may lock up, but usually its
>> fine so hey! live on the edge!
>
>
> I meant to ask the list about a bug I hit doing this
>
> Putting a "self haltOnce" here...
>
>   WorldState>>doOneCycleNowFor: aWorld
> DisplayScreen checkForNewScreenSize.
> self haltOnce.
> "process user input events"
> LastCycleTime := Time millisecondClockValue.
> self handsDo: [:h |
> self activeHand: h.
> h processEvents.
> self activeHand: nil.
> ].
> self activeHand: self hands first.


A further curiousity occurs to me.  With this being executed 20 times
a second or more, how can the active hand ever be anything other than
the primary hand?
Why isn't the active hand stored, all hands cycled through processing
events, then the active hand restored??

cheers -ben


> aWorld runStepMethods. "there are currently some variations here"
> self displayWorldSafely: aWorld.
>
>
> When stepping over "self activeHand: nil."
> another debugger appears MNU: receiver of "releaseKeyboardFocus:" is nil
> in GLMPagerPanePreviewMorph(Morph)>>delete
>
>   self activeHand
>  releaseKeyboardFocus: self;
>  releaseMouseFocus: self.
>
>
> This can obviously be fixed by wrapping "self activeHand" with an #ifNil:
> but alternatively I wonder if the "self activeHand: nil" is really needed?
> It seems redundant since activeHand is set at the top of the loop and
> immediately after exiting the loop.
> Eliminating it would reduce the propagation of #ifNil: anti-pattern.
>
> https://pharo.fogbugz.com/default.asp?19169
>
> cheers -ben
>
>>
>> In #runStepMethodsIn: you'll see "queue := self class
>> deferredUIMessages" for which you enqueue items like this...
>> http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-messages-executed-slowly-td3228060.html
>>
>> After processing the deferred UI messages, each Morph's #step method
>> is processed by #runLocalStepMethodsIn:
>> refer... http://wiki.squeak.org/squeak/2096
>>
>> The display is then rendered by #displayWorldSafely: calling...
>> --> #displayWorld
>> --> #displayWorld:submorphs:
>> which then is a lot to trace through, but depending on the graphics
>> back end eventually ends up calling...
>> Canvas>>fullDrawMorph:which ultimately invokes one of many #drawOn:
>> or...
>> AthensCanvas>>fullDrawMorph:which ultimately invokes one of many
>> #drawOnAthensCanvas:
>>
>>
>> So, for a regular timed UI animation, you would define your custom
>> morph's #step and #stepTime methods,
>> and for lower level stuff you would fork like Dennis suggests.
>>
>> cheers -ben

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[Ben Coman]

On Mon, Oct 3, 2016 at 6:08 PM, Ben Coman  wrote:
> On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry  wrote:
>> a JavaScript timeout is a function that takes a block and a period of time,
>> and after  this period of time, puts the block at the end of the event
>> queue, to be executed as soon as the runtime is done performing the tasks in
>> front of it.
>>
>> I am not sure if Pharo has an event queue, so it's a bit harder to do
>> it(since without one you can't ensure only one thing happens at a time, and
>> strange things can happen).
>>
>> That said, in simplest terms, imagine writing a clock app for Pharo, which
>> updates time every second, in JS this would be done by setting an interval
>> that ticks every 1000ms, and each time places the callback function(block)
>> at the end of the event queue.
>>
>> Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ
>
> Pharo has a single threaded VM, but multiple green threads can run 
> concurrently.
> The closest to the event loop you are thinking of most likely the
> Morphic UI Process
> which you can see using World > Tools > Process Browser.  When you execute 
> code
> from Playground it runs in that Process (note what Smalltalk
> historically (circa 1970s?) has
> called a Process is today more commonly know as a Green Thread)
>
> If you select Morphic UI Process  you will see its call stack on the
> right, where an interesting method is WorldState>>doOneCycleFor:
> You can gain some insight by turning on auto-update in the Process
> Browser, then open a Browser on WorldState>>doOneCycleFor:
> and put "self haltOnce" at the top, then enable it via...
> Pharo 5: World > System > Enable halt/inspect once.
> Pharo 6: World > Debugging > Enable all break/inspect once.
>
> You will see in the Process Browser that a new Morphic UI Process is
> spawned, and the original Morphic UI Process call stack now has
> #debugProcess at the top
> and a debug window appears that you can step through.  Note, since two
> UI loops are executing here, the image may lock up, but usually its
> fine so hey! live on the edge!


I meant to ask the list about a bug I hit doing this

Putting a "self haltOnce" here...

  WorldState>>doOneCycleNowFor: aWorld
DisplayScreen checkForNewScreenSize.
self haltOnce.
"process user input events"
LastCycleTime := Time millisecondClockValue.
self handsDo: [:h |
self activeHand: h.
h processEvents.
self activeHand: nil.
].
self activeHand: self hands first.
aWorld runStepMethods. "there are currently some variations here"
self displayWorldSafely: aWorld.


When stepping over "self activeHand: nil."
another debugger appears MNU: receiver of "releaseKeyboardFocus:" is nil
in GLMPagerPanePreviewMorph(Morph)>>delete

  self activeHand
 releaseKeyboardFocus: self;
 releaseMouseFocus: self.


This can obviously be fixed by wrapping "self activeHand" with an #ifNil:
but alternatively I wonder if the "self activeHand: nil" is really needed?
It seems redundant since activeHand is set at the top of the loop and
immediately after exiting the loop.
Eliminating it would reduce the propagation of #ifNil: anti-pattern.

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

cheers -ben

>
> In #runStepMethodsIn: you'll see "queue := self class
> deferredUIMessages" for which you enqueue items like this...
> http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-messages-executed-slowly-td3228060.html
>
> After processing the deferred UI messages, each Morph's #step method
> is processed by #runLocalStepMethodsIn:
> refer... http://wiki.squeak.org/squeak/2096
>
> The display is then rendered by #displayWorldSafely: calling...
> --> #displayWorld
> --> #displayWorld:submorphs:
> which then is a lot to trace through, but depending on the graphics
> back end eventually ends up calling...
> Canvas>>fullDrawMorph:which ultimately invokes one of many #drawOn:
> or...
> AthensCanvas>>fullDrawMorph:which ultimately invokes one of many
> #drawOnAthensCanvas:
>
>
> So, for a regular timed UI animation, you would define your custom
> morph's #step and #stepTime methods,
> and for lower level stuff you would fork like Dennis suggests.
>
> cheers -ben

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[Ben Coman]

On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry  wrote:
> a JavaScript timeout is a function that takes a block and a period of time,
> and after  this period of time, puts the block at the end of the event
> queue, to be executed as soon as the runtime is done performing the tasks in
> front of it.
>
> I am not sure if Pharo has an event queue, so it's a bit harder to do
> it(since without one you can't ensure only one thing happens at a time, and
> strange things can happen).
>
> That said, in simplest terms, imagine writing a clock app for Pharo, which
> updates time every second, in JS this would be done by setting an interval
> that ticks every 1000ms, and each time places the callback function(block)
> at the end of the event queue.
>
> Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ

Pharo has a single threaded VM, but multiple green threads can run concurrently.
The closest to the event loop you are thinking of most likely the
Morphic UI Process
which you can see using World > Tools > Process Browser.  When you execute code
from Playground it runs in that Process (note what Smalltalk
historically (circa 1970s?) has
called a Process is today more commonly know as a Green Thread)

If you select Morphic UI Process  you will see its call stack on the
right, where an interesting method is WorldState>>doOneCycleFor:
You can gain some insight by turning on auto-update in the Process
Browser, then open a Browser on WorldState>>doOneCycleFor:
and put "self haltOnce" at the top, then enable it via...
Pharo 5: World > System > Enable halt/inspect once.
Pharo 6: World > Debugging > Enable all break/inspect once.

You will see in the Process Browser that a new Morphic UI Process is
spawned, and the original Morphic UI Process call stack now has
#debugProcess at the top
and a debug window appears that you can step through.  Note, since two
UI loops are executing here, the image may lock up, but usually its
fine so hey! live on the edge!

In #runStepMethodsIn: you'll see "queue := self class
deferredUIMessages" for which you enqueue items like this...
http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-messages-executed-slowly-td3228060.html

After processing the deferred UI messages, each Morph's #step method
is processed by #runLocalStepMethodsIn:
refer... http://wiki.squeak.org/squeak/2096

The display is then rendered by #displayWorldSafely: calling...
--> #displayWorld
--> #displayWorld:submorphs:
which then is a lot to trace through, but depending on the graphics
back end eventually ends up calling...
Canvas>>fullDrawMorph:which ultimately invokes one of many #drawOn:
or...
AthensCanvas>>fullDrawMorph:which ultimately invokes one of many
#drawOnAthensCanvas:


So, for a regular timed UI animation, you would define your custom
morph's #step and #stepTime methods,
and for lower level stuff you would fork like Dennis suggests.

cheers -ben

Re: [Pharo-users] Pharo on my Ubuntu laptop :3

[CodeDmitry]

Sounds exciting, I've been trying to tweak the window buttons but couldn't
figure out where to look.



--
View this message in context: 
http://forum.world.st/Pharo-on-my-Ubuntu-laptop-3-tp4917833p4917846.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] bytes to utf8 string / byte stream parsing

[Fabrice Leal]

hey! yeah, i checked it, it seems to solve my issue but i havent test it
yet. i have a custom binary format that i want to parse, and was looking
for a way for reading a utf8 string as encoded by c# (where i generate
files with this format).

gotta check that Xtreams thing

On Mon, Oct 3, 2016 at 6:39 AM, stepharo  wrote:

> Hello Fabrice
>
> Did you read the excellent book chapter written by sven on stream
> encodings?
>
> Check Enterprise Pharo book http://books.pharo.org
>
> Now can you tell us what you want to do?
>
> It would be nice also to check if Xtreams offers (or deserves some
> extensions).
>
> Stef
>
> Le 30/9/16 à 12:57, Fabrice Leal a écrit :
>
> can anyone provide me some pointers on how to turn a bunch of bytes into a
> utf8 string?
>
> i'm planning on writing a byte stream parser, would appreciate anything
> you might find useful in addition to the Streams chapter from Pharo by
> Example
>
> --
> ---
> Fabrice Leal
>
>
>


-- 
---
Fabrice Leal

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[p...@highoctane.be]

And if this just for a graphical clock, a morph with step should be doing
the trick.
stepTime can be set as well.

Phil

On Mon, Oct 3, 2016 at 10:09 AM, Denis Kudriashov 
wrote:

> Hi.
>
> 2016-10-03 9:49 GMT+02:00 CodeDmitry :
>
>> a JavaScript timeout is a function that takes a block and a period of
>> time,
>> and after  this period of time, puts the block at the end of the event
>> queue, to be executed as soon as the runtime is done performing the tasks
>> in
>> front of it.
>>
>> I am not sure if Pharo has an event queue, so it's a bit harder to do
>> it(since without one you can't ensure only one thing happens at a time,
>> and
>> strange things can happen).
>>
>> That said, in simplest terms, imagine writing a clock app for Pharo, which
>> updates time every second, in JS this would be done by setting an interval
>> that ticks every 1000ms, and each time places the callback function(block)
>> at the end of the event queue.
>>
>
> In Pharo we have cheap green threads. You can write this:
>
> ["your code".
> 1 seconds wait.] fork.
>
>
> Also look at project TaskIt https://github.com/sbragagnolo/taskit. It
> provides many high level scheduling capabilities.
>
>

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[CodeDmitry]

Interesting, I got to play around with these, do some async morph animations.



--
View this message in context: 
http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917839.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[Denis Kudriashov]

Hi.

2016-10-03 9:49 GMT+02:00 CodeDmitry :

> a JavaScript timeout is a function that takes a block and a period of time,
> and after  this period of time, puts the block at the end of the event
> queue, to be executed as soon as the runtime is done performing the tasks
> in
> front of it.
>
> I am not sure if Pharo has an event queue, so it's a bit harder to do
> it(since without one you can't ensure only one thing happens at a time, and
> strange things can happen).
>
> That said, in simplest terms, imagine writing a clock app for Pharo, which
> updates time every second, in JS this would be done by setting an interval
> that ticks every 1000ms, and each time places the callback function(block)
> at the end of the event queue.
>

In Pharo we have cheap green threads. You can write this:

["your code".
1 seconds wait.] fork.


Also look at project TaskIt https://github.com/sbragagnolo/taskit. It
provides many high level scheduling capabilities.

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[Dimitris Chloupis]

of course Pharo has an event queue, we call them announcements. That
implies however that you want the code to execute as soon as something else
happens. If you don't , fork and delay should be enough. With fork you dont
need to wait for othet tasks to finish to execute your code, it will just
put it to a thread and execute it concurently. If you want the code to run
as soon as other tasks finish then of course you dont use fork.

On Mon, Oct 3, 2016 at 10:56 AM CodeDmitry  wrote:

> a JavaScript timeout is a function that takes a block and a period of time,
> and after  this period of time, puts the block at the end of the event
> queue, to be executed as soon as the runtime is done performing the tasks
> in
> front of it.
>
> I am not sure if Pharo has an event queue, so it's a bit harder to do
> it(since without one you can't ensure only one thing happens at a time, and
> strange things can happen).
>
> That said, in simplest terms, imagine writing a clock app for Pharo, which
> updates time every second, in JS this would be done by setting an interval
> that ticks every 1000ms, and each time places the callback function(block)
> at the end of the event queue.
>
> Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ
>
>
>
> --
> View this message in context:
> http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917835.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

[CodeDmitry]

a JavaScript timeout is a function that takes a block and a period of time,
and after  this period of time, puts the block at the end of the event
queue, to be executed as soon as the runtime is done performing the tasks in
front of it.

I am not sure if Pharo has an event queue, so it's a bit harder to do
it(since without one you can't ensure only one thing happens at a time, and
strange things can happen).

That said, in simplest terms, imagine writing a clock app for Pharo, which
updates time every second, in JS this would be done by setting an interval
that ticks every 1000ms, and each time places the callback function(block)
at the end of the event queue.

Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ



--
View this message in context: 
http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917835.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo on my Ubuntu laptop :3

[Dimitris Chloupis]

Oh I forgot to tell you , you can customize the theme too the easy way,
install my project Nireas from Package Browser , then go to settings and
choose the Nirea theme, a blue theme will appear however this is not the
end of the story , open world menu go to Ephestos ->  Nireas, a GUI will
appear , you will see two buttons with number 1 and number 2 , 2 will
revert back to dark theme, use the other buttons to choose the colors you
want. Currently there is no way to save the theme separately so you will
have to save your image to keep the theme.

You will have to close and reopen your windows to see the new theme.

You can also do many other customization like changing the icon of the
pharo executable and its name.

On Mon, Oct 3, 2016 at 10:40 AM CodeDmitry  wrote:

> Behold!
>
> 
>
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/Pharo-on-my-Ubuntu-laptop-3-tp4917833.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

[Pharo-users] Pharo on my Ubuntu laptop :3

[CodeDmitry]

Behold!

 





--
View this message in context: 
http://forum.world.st/Pharo-on-my-Ubuntu-laptop-3-tp4917833.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] About Seaside3.2

[Stephan Eggermont]

On 01/10/16 07:45, stepharo wrote:


And it is proposing the correct menu?
And how do I know that this 3.2.0?


We have a comprehensive site:
https://github.com/SeasideSt/Seaside/wiki/Seaside320Changelog

Or you don't and then you take a look at the
symbolic versions and select one of those,
either #'stable' or #'release3.2'.


In my version that I took from latest ci there is not Zn*adaptor


That is a bug we'd need to fix. Core developers and most users
use specific configurations that use seaside groups, not the
default group.

Stephan

[Pharo-users] Pharo Association

[John Pfersich]

I went to the Pharo Association web site (http://association.pharo.org) to 
change my profile, but I didn't find any way to alter it. Am I missing 
something?

Sent from my iPad