Re: [Pharo-dev] Immutability support

[Clément Bera]

The "CAN'T REACH" comment is there because execution never reach that part
of the code. If you write code there, it will never be executed. The
process code performs a return without pushing any value on stack.

Signalling an error is safe if the error is never resumed. But you'll need
the returnNoValue for performance intensive modification tracking.



On Wed, Jan 25, 2017 at 10:26 PM, Denis Kudriashov 
wrote:

>
> 2017-01-25 22:24 GMT+01:00 Denis Kudriashov :
>
>> For the Process hack, it's because the call-back was designed to return
>>> no value.
>>
>>
>> Now I am confused.
>> Why anybody needs to return value from this method?
>> And why there is  "CAN'T REACH" comment at the end of method?
>> Do you mean that method should never return?
>>
>>
>>> It may look like it works when returning a value but you will have
>>> uncommon crashes.
>>
>>
> And is it safe to just signal error?
>

Re: [Pharo-dev] memoized vs once

[Eliot Miranda]

Oops, forgive me Ben.  I'm wrong.  once is only equivalent to memoized for 
nullary blocks.  It is not the same as memoized:[value:] for N-ary blocks.  
Forgive the noise.

_,,,^..^,,,_ (phone)

> On Jan 25, 2017, at 10:56 AM, Eliot Miranda  wrote:
> 
> Hi Ben,
> 
> via FaceBook via twitter I hear you've coined BlockClosure>>#memoized.  
> Allow me to beg you to rename it to BlockClosure>>#once.  There's a 
> preexisting implementation of this in VisualWorks by Travis Griggs called 
> once.  I hope you agree that it's good to eliminate gratuitous 
> incompatibilities between dialects and that "once" is an elegant name.
> _,,,^..^,,,_
> best, Eliot

Re: [Pharo-dev] memoized vs once

[p...@highoctane.be]

There is the memoized with the internally declared Dictionary new as the
cache and memoized using: cache

There cache is known and the result is a block that does the caching thing.

([ :cacheKey| self getIssueCreateMetaWithExpandKeys: true ] memoizedUsing:
self cache) value: #issueCreateMeta


BlockClosure>>#memoizedUsing: cache
"Provide a memoization block using the given cache. So one can tune by
 passing a LRUCache for instance"

^[ :x | cache at: x ifAbsentPut: [ self value: x ] ]

Basically a shorthand for your recommendation.

But I would have put a cull: instead of value: because sometimes, like in
my case, there is no parameter, the only useful thing is the cacheKey.

And it would be nice to have the :v1 :v2 :vn version with the cache key
being made out of the combination + cull:cull:cull:

Really, this is just a shorthand.

This is nicer IMHO than having cache at:ifAbsentPut: all over.

| cache factorial result |
cache := LRUCache new maximumWeight: 3.
factorial := 0. "avoid not-initialised warning when saving method source"

factorial := [ :n | n = 1 ifTrue: [1] ifFalse: [(factorial value: n - 1) *
n] ] memoizedUsing: cache.

result := (1 to: 5) collect: factorial.

Phil


On Thu, Jan 26, 2017 at 1:36 AM, Igor Stasenko  wrote:

>
>
> On 26 January 2017 at 02:10, p...@highoctane.be 
> wrote:
>
>> Ah ah :-D
>>
>> DynamicVariables are darker magic that this, right?
>>
>> you mean like those that seaside using? it lives as long as session
> lives, and tied to session you are working in..
> in early versions of seaside they were using exceptions to access session
> storage..
> quite ineffective.. but it works.
> for that purpose it is much better to use process-specific variables, that
> live and die together with process that hosts them..
> but has significantly better access timings. and since seaside allocates a
> separate process per session, that's perfect fit.
>
> in any case, the concern about getting rid of volatile data is covered..
> while with memoization, i don't see it. and that seems like a HUGE
> argument against using it,
> because it is more trouble in a long run than time saver when you just
> start using it everywhere.
>
>
>
>> Phil
>>
>>
>>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-dev] memoized vs once

[Igor Stasenko]

On 26 January 2017 at 02:10, p...@highoctane.be  wrote:

> Ah ah :-D
>
> DynamicVariables are darker magic that this, right?
>
> you mean like those that seaside using? it lives as long as session lives,
and tied to session you are working in..
in early versions of seaside they were using exceptions to access session
storage..
quite ineffective.. but it works.
for that purpose it is much better to use process-specific variables, that
live and die together with process that hosts them..
but has significantly better access timings. and since seaside allocates a
separate process per session, that's perfect fit.

in any case, the concern about getting rid of volatile data is covered..
while with memoization, i don't see it. and that seems like a HUGE argument
against using it,
because it is more trouble in a long run than time saver when you just
start using it everywhere.



> Phil
>
>
>
-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] memoized vs once

[Igor Stasenko]

On 26 January 2017 at 02:10, p...@highoctane.be  wrote:

> Ah ah :-D
>
> In my example I want to be able to do the calls without caching or with
> caching. Without for debugging because I amend the server side at times and
> want always fresh data (yes, I could have a cache with TTL of about
> nothing).
>
>
and why that could be the problem in my example? you can always implement
#at:ifAbsentPut: in the way you see fit..

cache disable.
x := cache at: #something ifAbsentPut: [ blah ]. "always calculates,
ignores the cache"
cache enable.
y := cache at: #something ifAbsentPut: [ blah ]. "prefers to calculate
once, reuse result"

you see what i mean?
in any case you can easily avoid repeating  same block twice.. that's for
sure.


> Memoization is useful for not having to write the caching thing all the
> time.
>
> DynamicVariables are darker magic that this, right?
>
> Phil
>
>
> On Thu, Jan 26, 2017 at 12:56 AM, Igor Stasenko 
> wrote:
>
>> Because caching are always comes with concerns, like when/where do we
>> want to drop cached results and recalculate them, if needed..
>> With memoization it seems like there's simply no such concern at all..
>> meaning that cached data will live forever since created once.. which is
>> never good
>> for dynamic system.. because i spent significant portion of my smalltalk
>> life hunting for leaks and immortal references that you cannot get rid of,
>> because some guy forgot to provide a nice and easy interface or api to
>> get rid of volatile data.. like open files or socket connections, session
>> etc etc..
>> and now.. let us welcome.. memoization. :)
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] memoized vs once

[p...@highoctane.be]

Ah ah :-D

In my example I want to be able to do the calls without caching or with
caching. Without for debugging because I amend the server side at times and
want always fresh data (yes, I could have a cache with TTL of about
nothing).

Memoization is useful for not having to write the caching thing all the
time.

DynamicVariables are darker magic that this, right?

Phil


On Thu, Jan 26, 2017 at 12:56 AM, Igor Stasenko  wrote:

> Because caching are always comes with concerns, like when/where do we want
> to drop cached results and recalculate them, if needed..
> With memoization it seems like there's simply no such concern at all..
> meaning that cached data will live forever since created once.. which is
> never good
> for dynamic system.. because i spent significant portion of my smalltalk
> life hunting for leaks and immortal references that you cannot get rid of,
> because some guy forgot to provide a nice and easy interface or api to get
> rid of volatile data.. like open files or socket connections, session etc
> etc..
> and now.. let us welcome.. memoization. :)
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-dev] memoized vs once

[Igor Stasenko]

Because caching are always comes with concerns, like when/where do we want
to drop cached results and recalculate them, if needed..
With memoization it seems like there's simply no such concern at all..
meaning that cached data will live forever since created once.. which is
never good
for dynamic system.. because i spent significant portion of my smalltalk
life hunting for leaks and immortal references that you cannot get rid of,
because some guy forgot to provide a nice and easy interface or api to get
rid of volatile data.. like open files or socket connections, session etc
etc..
and now.. let us welcome.. memoization. :)

-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] memoized vs once

[Igor Stasenko]

On 26 January 2017 at 01:40, p...@highoctane.be  wrote:

> Yeah, I get you 100%.
>
> I wanted to be able to cache or not and have this transparent.
>
> Memoization in its current form in Pharo is not like I would like to have
> it.
>
> As for the repeating block, I was asking to how you would avoid repeating
> in the given code structure.
>

You asking me rewrite it for your example?
unless i missing something (not)obvious here, it can look like this:

getIssueCreateMeta
"Retrieves the metadata for all types of issues. Fields are expanded"
^ self cache at:  #issueCreateMeta ifAbsentPut: [ self
getIssueCreateMetaWithExpandKeys: true ]


Btw, it is a good question, what are the difference between caching and
memoization, besides that google underlines 'memoization' word with thin
red curly line while i typing? :)


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] memoized vs once

[p...@highoctane.be]

Yeah, I get you 100%.

I wanted to be able to cache or not and have this transparent.

Memoization in its current form in Pharo is not like I would like to have
it.

As for the repeating block, I was asking to how you would avoid repeating
in the given code structure.

Phil


On Thu, Jan 26, 2017 at 12:34 AM, Igor Stasenko  wrote:

>
>
> On 26 January 2017 at 01:23, p...@highoctane.be 
> wrote:
>
>> Nothing new, that's the term.
>>
>> Memoization: After computing a solution to a subproblem, store it in a
>> table. Subsequent calls check the table to avoid redoing work.
>>
>> https://en.wikipedia.org/wiki/Memoization
>>
>> http://www.cas.mcmaster.ca/~deza/6_Dynamic++.pdf
>>
>> http://wiki.tcl.tk/10779
>>
>> I have been using the method for something else, caching costly REST
>> calls.
>>
>> getIssueCreateMeta
>> "Retrieves the metadata for all types of issues. Fields are expanded"
>> ^ self isMemoizingMeta
>> ifTrue: [ ([ :ignored | self getIssueCreateMetaWithExpandKeys: true ]
>> memoizedUsing: self cache ) value: #issueCreateMeta ]
>> ifFalse: [ self getIssueCreateMetaWithExpandKeys: true ]
>>
>>
>> using:
>>
>> cache
>> ^ cache ifNil: [cache := LRUCache new maximumWeight: self
>> defaultCacheWeight ]
>>
>> It is nice to see the cache hit rate etc in the inspector.
>>
>> BTW I am interested to see how one coul dwrite the code above without
>> repeating the block.
>> Also, :ignored is not used by the method but is the cache key.
>>
>>
> well, for not repeating, its easy, for instance in NativeBoost i just used
> expressions like:
>
> getIssueCreateMeta
> ^ self cacheAt: somekey ifAbsentPut: [ some data ]
>
> which are self-explanatory (i hope)
> where somekey could be 'self' or whatever seem fit.
>
> as for the caching wihoout key, why not just store result of first
> evaluation and then use it directly anywhere else? why need to wrap it
> with block??
>
> data := [some calculation ] value.
>
> self doSomethingWith: data.
> self doSomethingElseWith: data.
> self doSomethingElseElseWith: data.
>
>
> voila.. plain programming. Where does memoization need to be coined here?
> :)
>
> Phil
>>
>> On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko 
>> wrote:
>>
>>> #once can be interpreted as 'evaluate it once',
>>>
>>> but i don't like the #memoized .. it sounds painful to my ears.
>>> It sounds like something stinking smeared across my face.. and i always
>>> got stuck,confused and lost as the meaning of it always
>>> escaping my mind, since it naturally defends itself from any unpleasant
>>> thoughts.
>>>
>>> IMHO, maybe #once is not the best wording for what it does , but
>>> #memoizing... yuck.. pardon me.
>>>
>>>  :)
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-dev] memoized vs once

[Igor Stasenko]

On 26 January 2017 at 01:33, p...@highoctane.be  wrote:

> self memoize: #methodThatDoesSomethingLong:.
>
> would automatically store parameters values as cache keys. No matter how
> many such parms.
>
> No need to have blocks or anything,operations are memoized.
> We use blocks for lack of a better way right now I guess.
>
> Phil
>
> well, that's something i calling 'caching'.. because if you cashing many
results, depending on input data,
then it is better to call caching..

but in original example, there's noting like this.. it is just block
without arguments.. so, what you going
to use as keys for caching evaluation of such block, how do you identify
what value(s) are inputs for such block
and what not?

-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] memoized vs once

[p...@highoctane.be]

self memoize: #methodThatDoesSomethingLong:.

would automatically store parameters values as cache keys. No matter how
many such parms.

No need to have blocks or anything,operations are memoized.
We use blocks for lack of a better way right now I guess.

Phil

On Thu, Jan 26, 2017 at 12:22 AM, Igor Stasenko  wrote:

> result := [ do something long or short or whatever] cached.
>
> On 26 January 2017 at 01:20, Igor Stasenko  wrote:
>
>>
>>
>> On 26 January 2017 at 01:14, p...@highoctane.be 
>> wrote:
>>
>>> If one is doing any dynamic programming, the memoization term is pretty
>>> natural.
>>>
>>> for that purpose, i naturally using 'caching' wording.
>>
>>
>>> https://youtu.be/OQ5jsbhAv_M?t=3m11s
>>>
>>> Phil
>>>
>>> On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko 
>>> wrote:
>>>
 #once can be interpreted as 'evaluate it once',

 but i don't like the #memoized .. it sounds painful to my ears.
 It sounds like something stinking smeared across my face.. and i always
 got stuck,confused and lost as the meaning of it always
 escaping my mind, since it naturally defends itself from any unpleasant
 thoughts.

 IMHO, maybe #once is not the best wording for what it does , but
 #memoizing... yuck.. pardon me.

  :)


 --
 Best regards,
 Igor Stasenko.

>>>
>>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-dev] memoized vs once

[Igor Stasenko]

On 26 January 2017 at 01:23, p...@highoctane.be  wrote:

> Nothing new, that's the term.
>
> Memoization: After computing a solution to a subproblem, store it in a
> table. Subsequent calls check the table to avoid redoing work.
>
> https://en.wikipedia.org/wiki/Memoization
>
> http://www.cas.mcmaster.ca/~deza/6_Dynamic++.pdf
>
> http://wiki.tcl.tk/10779
>
> I have been using the method for something else, caching costly REST calls.
>
> getIssueCreateMeta
> "Retrieves the metadata for all types of issues. Fields are expanded"
> ^ self isMemoizingMeta
> ifTrue: [ ([ :ignored | self getIssueCreateMetaWithExpandKeys: true ]
> memoizedUsing: self cache ) value: #issueCreateMeta ]
> ifFalse: [ self getIssueCreateMetaWithExpandKeys: true ]
>
>
> using:
>
> cache
> ^ cache ifNil: [cache := LRUCache new maximumWeight: self
> defaultCacheWeight ]
>
> It is nice to see the cache hit rate etc in the inspector.
>
> BTW I am interested to see how one coul dwrite the code above without
> repeating the block.
> Also, :ignored is not used by the method but is the cache key.
>
>
well, for not repeating, its easy, for instance in NativeBoost i just used
expressions like:

getIssueCreateMeta
^ self cacheAt: somekey ifAbsentPut: [ some data ]

which are self-explanatory (i hope)
where somekey could be 'self' or whatever seem fit.

as for the caching wihoout key, why not just store result of first
evaluation and then use it directly anywhere else? why need to wrap it
with block??

data := [some calculation ] value.

self doSomethingWith: data.
self doSomethingElseWith: data.
self doSomethingElseElseWith: data.


voila.. plain programming. Where does memoization need to be coined here? :)

Phil
>
> On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko 
> wrote:
>
>> #once can be interpreted as 'evaluate it once',
>>
>> but i don't like the #memoized .. it sounds painful to my ears.
>> It sounds like something stinking smeared across my face.. and i always
>> got stuck,confused and lost as the meaning of it always
>> escaping my mind, since it naturally defends itself from any unpleasant
>> thoughts.
>>
>> IMHO, maybe #once is not the best wording for what it does , but
>> #memoizing... yuck.. pardon me.
>>
>>  :)
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] memoized vs once

[p...@highoctane.be]

But for caching you have a cache.

The whole point of memoization support is to have it easy to do.
Look at the bottom of this page:
http://wiki.tcl.tk/10981

So if we could have some kind of the same using manipulation of thisContext
and/or Slots, it would be nicer.

e.g.

SomeClass>>#initialize
   self memoize: #someMethod:andParms:.

and bingo, automatic method memoization keyed by the objects passed.

That would be better.

Phil




On Thu, Jan 26, 2017 at 12:20 AM, Igor Stasenko  wrote:

>
>
> On 26 January 2017 at 01:14, p...@highoctane.be 
> wrote:
>
>> If one is doing any dynamic programming, the memoization term is pretty
>> natural.
>>
>> for that purpose, i naturally using 'caching' wording.
>
>
>> https://youtu.be/OQ5jsbhAv_M?t=3m11s
>>
>> Phil
>>
>> On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko 
>> wrote:
>>
>>> #once can be interpreted as 'evaluate it once',
>>>
>>> but i don't like the #memoized .. it sounds painful to my ears.
>>> It sounds like something stinking smeared across my face.. and i always
>>> got stuck,confused and lost as the meaning of it always
>>> escaping my mind, since it naturally defends itself from any unpleasant
>>> thoughts.
>>>
>>> IMHO, maybe #once is not the best wording for what it does , but
>>> #memoizing... yuck.. pardon me.
>>>
>>>  :)
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-dev] memoized vs once

[p...@highoctane.be]

Nothing new, that's the term.

Memoization: After computing a solution to a subproblem, store it in a
table. Subsequent calls check the table to avoid redoing work.

https://en.wikipedia.org/wiki/Memoization

http://www.cas.mcmaster.ca/~deza/6_Dynamic++.pdf

http://wiki.tcl.tk/10779

I have been using the method for something else, caching costly REST calls.

getIssueCreateMeta
"Retrieves the metadata for all types of issues. Fields are expanded"
^ self isMemoizingMeta
ifTrue: [ ([ :ignored | self getIssueCreateMetaWithExpandKeys: true ]
memoizedUsing: self cache ) value: #issueCreateMeta ]
ifFalse: [ self getIssueCreateMetaWithExpandKeys: true ]


using:

cache
^ cache ifNil: [cache := LRUCache new maximumWeight: self
defaultCacheWeight ]

It is nice to see the cache hit rate etc in the inspector.

BTW I am interested to see how one coul dwrite the code above without
repeating the block.
Also, :ignored is not used by the method but is the cache key.

Phil

On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko  wrote:

> #once can be interpreted as 'evaluate it once',
>
> but i don't like the #memoized .. it sounds painful to my ears.
> It sounds like something stinking smeared across my face.. and i always
> got stuck,confused and lost as the meaning of it always
> escaping my mind, since it naturally defends itself from any unpleasant
> thoughts.
>
> IMHO, maybe #once is not the best wording for what it does , but
> #memoizing... yuck.. pardon me.
>
>  :)
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-dev] memoized vs once

[Igor Stasenko]

result := [ do something long or short or whatever] cached.

On 26 January 2017 at 01:20, Igor Stasenko  wrote:

>
>
> On 26 January 2017 at 01:14, p...@highoctane.be 
> wrote:
>
>> If one is doing any dynamic programming, the memoization term is pretty
>> natural.
>>
>> for that purpose, i naturally using 'caching' wording.
>
>
>> https://youtu.be/OQ5jsbhAv_M?t=3m11s
>>
>> Phil
>>
>> On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko 
>> wrote:
>>
>>> #once can be interpreted as 'evaluate it once',
>>>
>>> but i don't like the #memoized .. it sounds painful to my ears.
>>> It sounds like something stinking smeared across my face.. and i always
>>> got stuck,confused and lost as the meaning of it always
>>> escaping my mind, since it naturally defends itself from any unpleasant
>>> thoughts.
>>>
>>> IMHO, maybe #once is not the best wording for what it does , but
>>> #memoizing... yuck.. pardon me.
>>>
>>>  :)
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>



-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] memoized vs once

[Igor Stasenko]

On 26 January 2017 at 01:14, p...@highoctane.be  wrote:

> If one is doing any dynamic programming, the memoization term is pretty
> natural.
>
> for that purpose, i naturally using 'caching' wording.


> https://youtu.be/OQ5jsbhAv_M?t=3m11s
>
> Phil
>
> On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko 
> wrote:
>
>> #once can be interpreted as 'evaluate it once',
>>
>> but i don't like the #memoized .. it sounds painful to my ears.
>> It sounds like something stinking smeared across my face.. and i always
>> got stuck,confused and lost as the meaning of it always
>> escaping my mind, since it naturally defends itself from any unpleasant
>> thoughts.
>>
>> IMHO, maybe #once is not the best wording for what it does , but
>> #memoizing... yuck.. pardon me.
>>
>>  :)
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] memoized vs once

[Aliaksei Syrel]

Underscore.js names it also #memoize.
http://underscorejs.org/#memoize

Cheers

On Jan 26, 2017 00:15, "p...@highoctane.be"  wrote:

If one is doing any dynamic programming, the memoization term is pretty
natural.

https://youtu.be/OQ5jsbhAv_M?t=3m11s

Phil

On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko  wrote:

> #once can be interpreted as 'evaluate it once',
>
> but i don't like the #memoized .. it sounds painful to my ears.
> It sounds like something stinking smeared across my face.. and i always
> got stuck,confused and lost as the meaning of it always
> escaping my mind, since it naturally defends itself from any unpleasant
> thoughts.
>
> IMHO, maybe #once is not the best wording for what it does , but
> #memoizing... yuck.. pardon me.
>
>  :)
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-dev] memoized vs once

[p...@highoctane.be]

If one is doing any dynamic programming, the memoization term is pretty
natural.

https://youtu.be/OQ5jsbhAv_M?t=3m11s

Phil

On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko  wrote:

> #once can be interpreted as 'evaluate it once',
>
> but i don't like the #memoized .. it sounds painful to my ears.
> It sounds like something stinking smeared across my face.. and i always
> got stuck,confused and lost as the meaning of it always
> escaping my mind, since it naturally defends itself from any unpleasant
> thoughts.
>
> IMHO, maybe #once is not the best wording for what it does , but
> #memoizing... yuck.. pardon me.
>
>  :)
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-dev] memoized vs once

[p...@highoctane.be]

All that is nice but I only found about it because I searched for
"memoize"... Which is what it does.

Phil

On Wed, Jan 25, 2017 at 9:29 PM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

> Hi Eliot,
> you should have named the thread "once for all!"
> +1 in any case
>
> 2017-01-25 19:56 GMT+01:00 Eliot Miranda :
>
>> Hi Ben,
>>
>> via FaceBook via twitter I hear you've coined
>> BlockClosure>>#memoized.  Allow me to beg you to rename it to
>> BlockClosure>>#once.  There's a preexisting implementation of this in
>> VisualWorks by Travis Griggs called once.  I hope you agree that it's good
>> to eliminate gratuitous incompatibilities between dialects and that "once"
>> is an elegant name.
>> _,,,^..^,,,_
>> best, Eliot
>>
>
>

Re: [Pharo-dev] memoized vs once

[Torsten Bergmann]

Hi,

>From my perspective:

- I agree with Igor that "once" can be interpreted as "evaluate it only once" 
as in 
  "Halt once". 

- I'm not sure but from the (now very distributed) discussion it is not clear 
to me if 
  the #once mentioned by Eliot really has exactly the same behavior as 
#memoized in Pharo.

  Does it also  return a block that is caching the results and avoids a second 
evalution 
  of the original block when having similar inputs? Also is there a similar 
possibility 
  to give an own cache as in #memoizedUsing: for further tuning?

- #memoizing is really not well explaining what it does but this seems to be 
the official
  term (also in other languages like Python, Java, JS, ...): 
https://en.wikipedia.org/wiki/Memoization

- maybe #withMemo(r)izingResults or #withCachingResults, #withReusedResults, 
... or something along that line
  would be more intention revealing selectors


Side note:
=
- For license reason it would not make much sense to look into non-open 
Smalltalks
- I have no idea about the VW version (and for obvious reasons dont want to 
have a look)
- also dont know about other dialects if they have built in support for 
memoization but it would be
  good if Squeak, Pharo, Cuis, ... could align for such a case
- IMHO if #once and Pharos #memoization really have the same behavior then 
compatibility for VW users
  could be easily retained by adding #once to existing compatibility layers 
(like "Grease")

Bye
T.

Gesendet: Mittwoch, 25. Januar 2017 um 22:30 Uhr
Von: "Igor Stasenko" 
An: "Pharo Development List" 
Betreff: Re: [Pharo-dev] memoized vs once

#once can be interpreted as 'evaluate it once',
 
but i don't like the #memoized .. it sounds painful to my ears.
It sounds like something stinking smeared across my face.. and i always got 
stuck,confused and lost as the meaning of it always 
escaping my mind, since it naturally defends itself from any unpleasant 
thoughts.

IMHO, maybe #once is not the best wording for what it does , but #memoizing... 
yuck.. pardon me.

 
 :)
 
 --
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Pharo by Example 50 released!

[Stephan Eggermont]

On 22/01/17 16:53, stepharong wrote:

https://pharoweekly.wordpress.com/2017/01/22/pharo-by-example-50-released/

Super special thanks to Nicolai Hess that pushed me to do the last steps
to release.
Thanks Nicolai your steady commits pushed me!


Great. Having an up to date introduction like this is crucial to
attracting new people to the community. Well done!

Stephan

Re: [Pharo-dev] memoized vs once

[Igor Stasenko]

#once can be interpreted as 'evaluate it once',

but i don't like the #memoized .. it sounds painful to my ears.
It sounds like something stinking smeared across my face.. and i always got
stuck,confused and lost as the meaning of it always
escaping my mind, since it naturally defends itself from any unpleasant
thoughts.

IMHO, maybe #once is not the best wording for what it does , but
#memoizing... yuck.. pardon me.

 :)


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Immutability support

[Denis Kudriashov]

2017-01-25 22:24 GMT+01:00 Denis Kudriashov :

> For the Process hack, it's because the call-back was designed to return no
>> value.
>
>
> Now I am confused.
> Why anybody needs to return value from this method?
> And why there is  "CAN'T REACH" comment at the end of method?
> Do you mean that method should never return?
>
>
>> It may look like it works when returning a value but you will have
>> uncommon crashes.
>
>
And is it safe to just signal error?

Re: [Pharo-dev] Immutability support

[Denis Kudriashov]

2017-01-25 18:23 GMT+01:00 Clément Bera :

> For the Process hack, it's because the call-back was designed to return no
> value.


Now I am confused.
Why anybody needs to return value from this method?
And why there is  "CAN'T REACH" comment at the end of method?
Do you mean that method should never return?


> It may look like it works when returning a value but you will have
> uncommon crashes.


That's fun :)

Re: [Pharo-dev] Pharo by Example 50 released!

[monty]

This is great news. An up to date PBE is one of the best ways to get people 
into Pharo.

> Sent: Sunday, January 22, 2017 at 10:53 AM
> From: stepharong 
> To: pharo-dev@lists.pharo.org
> Cc: pharo-us...@lists.pharo.org
> Subject: [Pharo-dev] Pharo by Example 50 released!
>
> https://pharoweekly.wordpress.com/2017/01/22/pharo-by-example-50-released/
> 
> Super special thanks to Nicolai Hess that pushed me to do the last steps  
> to release.
> Thanks Nicolai your steady commits pushed me!
> 
> Stef
> 
> 

Re: [Pharo-dev] memoized vs once

[Denis Kudriashov]

Hi Eliot.

2017-01-25 19:56 GMT+01:00 Eliot Miranda :

> Hi Ben,
>
> via FaceBook via twitter I hear you've coined
> BlockClosure>>#memoized.  Allow me to beg you to rename it to
> BlockClosure>>#once.  There's a preexisting implementation of this in
> VisualWorks by Travis Griggs called once.  I hope you agree that it's good
> to eliminate gratuitous incompatibilities between dialects and that "once"
> is an elegant name.
>

#once is not the same as #memoized. #memoized returns another block which
wrap original one to perform some caching. Actually I not understand logic
behind it.
But #once supposed to evaluate receiver while #memoized creates new block.

In Pharo 6 I pushed new method #asMethodConst. Unfortunately I was not
aware about #once from VisualWorks at this time and reviewers too.
But #asMethodConst is a bit different. It is Object method instead of
Block. And it is based on AST modification.
When asMethodConst is executed it replace executing AST-node of sender with
receiver which produce new method where full message node is replaced by
result as literal.
I put mode details here
http://dionisiydk.blogspot.fr/2016/07/magic-with-pharo-reflectivity.html.
In short you can write expressions like:

10 factorial asMethodConst

Re: [Pharo-dev] memoized vs once

[Nicolas Cellier]

Hi Eliot,
you should have named the thread "once for all!"
+1 in any case

2017-01-25 19:56 GMT+01:00 Eliot Miranda :

> Hi Ben,
>
> via FaceBook via twitter I hear you've coined
> BlockClosure>>#memoized.  Allow me to beg you to rename it to
> BlockClosure>>#once.  There's a preexisting implementation of this in
> VisualWorks by Travis Griggs called once.  I hope you agree that it's good
> to eliminate gratuitous incompatibilities between dialects and that "once"
> is an elegant name.
> _,,,^..^,,,_
> best, Eliot
>

Re: [Pharo-dev] Immutability support

[Esteban Lorenzano]

yeah, something fishy is happening there. I will take a look.

> On 25 Jan 2017, at 18:31, p...@highoctane.be wrote:
> 
> pharo-win-i386-201701151442-c50dec0.zip
> 
> On Wed, Jan 25, 2017 at 3:57 PM, Esteban Lorenzano  > wrote:
> nevertheless it should be there in latests vms.
> which version are you using?
> 
> Esteban 
> 
>> On 25 Jan 2017, at 15:04, p...@highoctane.be  
>> wrote:
>> 
>> Tried it and it returns false for this Windows VM.
>> 
>> Phil
>> 
>> On Wed, Jan 25, 2017 at 2:14 PM, Clément Bera > > wrote:
>> I introduced the method #supportsWriteBarrier in Pharo 6.
>> 
>> You can backport it if you want:
>> 
>> VirtualMachine>>#supportsWriteBarrier
>>  "Answer whether the VM observes the per-object read-only flag and 
>> consequently
>>   aborts writes to inst vars of, and fails primitives that attempt to 
>> write, to read-only objects."
>> 
>>  ^(self parameterAt: 65)
>>  ifNil: [false]
>>  ifNotNil:
>>  [:param| "In older VMs this is a boolean reflecting 
>> MULTIPLE_BYTECODE_SETS"
>>   param isInteger "In newer VMs it is a set of integer 
>> flags, bit 1 of which is IMMUTABILITY"
>>  ifTrue: [param anyMask: 2]
>>  ifFalse: [false]]
>> 
>> 
>> 
>> On Wed, Jan 25, 2017 at 2:06 PM, p...@highoctane.be 
>>  > 
>> wrote:
>> The "latest" Windows VM I do use has no such method.
>> 
>> Virtual Machine
>> ---
>> C:\Users\Philippe\Dropbox\Sibelga\JiraAutomation\Pharo5.0\latestvm\pharo.exe
>> CoInterpreter * VMMaker.oscog-eem.2090 uuid: 
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid: 
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>> VM: 201701151442 https://github.com/pharo-project/pharo-vm.git 
>>  $ Date: Sun Jan 15 15:42:39 
>> 2017 +0100 $ Plugins: 201701151442 
>> https://github.com/pharo-project/pharo-vm.git 
>>  $
>> 
>> Win32 built on Jan 15 2017 15:59:52 CUT Compiler: 5.4.0
>> VMMaker versionString VM: 201701151442 
>> https://github.com/pharo-project/pharo-vm.git 
>>  $ Date: Sun Jan 15 15:42:39 
>> 2017 +0100 $ Plugins: 201701151442 
>> https://github.com/pharo-project/pharo-vm.git 
>>  $
>> CoInterpreter * VMMaker.oscog-eem.2090 uuid: 
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid: 
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>> 
>> 
>> 
>> 
>> On Wed, Jan 25, 2017 at 1:54 PM, Clément Bera > > wrote:
>> 
>> 
>> On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl > > wrote:
>> Does anyone know the state of immutability support in vm and image? The 
>> latest vm downloadable is compiled with
>> 
>> IMMUTABILITY=1
>> 
>> (Esteban said that). When I open a pharo6 image with this VM and do:
>> 
>> ASUser new
>> setIsReadOnlyObject: true;
>> name: 'foo'
>> 
>> with
>> 
>> ASUser>>#name: arg1
>> name := arg1
>> 
>> I don't get an exception. Is there something missing or am I not 
>> understanding?
>> 
>> Hi Norbert,
>> 
>> Thank you very much for looking read-only objects.
>> 
>> When mutating an instance variable, the VM triggers a call-back that by 
>> default does nothing. In your case, running your code does not raise an 
>> exception but the object should not be modified either. If you want an 
>> exception, you need to change the call-back code, i.e., the method 
>> Object>>#attemptToAssign: value withIndex: index. For example, you could 
>> write:
>> 
>> Object>>#attemptToAssign: value withIndex: index 
>>  | process |
>>  self notify: 'object changed !'.
>>  process := Processor activeProcess.
>>  [ process suspendedContext: process suspendedContext sender ] forkAt: 
>> Processor activePriority + 1.
>>  Processor yield.
>> 
>> Then, your code should open a notification window with 'object changed', and 
>> proceeding keeps running the code without mutating the object.
>> 
>> One needs to build a ModificationTracker framework on top of the VM support 
>> I introduced. Multiple things are required, like default behavior in this 
>> call-back and in primitive failure code. I am willing to support and help 
>> anyone willing to build such a framework, but I won't build it myself.
>> 
>> If you have any other questions or if you find bug don't hesitate to ask 
>> further questions
>> 
>> Best,
>> 
>> PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your 
>> 

Re: [Pharo-dev] Immutability support

[Martin McClure]

On 01/25/2017 03:59 AM, Esteban Lorenzano wrote:
> but this is not real immutability, is like a write barrier, that’s why
> those method names were not chosen. 

Thank you for choosing names based on "write barrier," not the incorrect
"read-only" or "immutable" (which are just things that can be done with
a write barrier, but not the only useful things).

Regards,

-Martin

[Pharo-dev] memoized vs once

[Eliot Miranda]

Hi Ben,

via FaceBook via twitter I hear you've coined BlockClosure>>#memoized.
Allow me to beg you to rename it to BlockClosure>>#once.  There's a
preexisting implementation of this in VisualWorks by Travis Griggs called
once.  I hope you agree that it's good to eliminate gratuitous
incompatibilities between dialects and that "once" is an elegant name.
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] Immutability support

[p...@highoctane.be]

pharo-win-i386-201701151442-c50dec0.zip

On Wed, Jan 25, 2017 at 3:57 PM, Esteban Lorenzano 
wrote:

> nevertheless it should be there in latests vms.
> which version are you using?
>
> Esteban
>
> On 25 Jan 2017, at 15:04, p...@highoctane.be wrote:
>
> Tried it and it returns false for this Windows VM.
>
> Phil
>
> On Wed, Jan 25, 2017 at 2:14 PM, Clément Bera 
> wrote:
>
>> I introduced the method #supportsWriteBarrier in Pharo 6.
>>
>> You can backport it if you want:
>>
>> VirtualMachine>>#supportsWriteBarrier
>> "Answer whether the VM observes the per-object read-only flag and
>> consequently
>> aborts writes to inst vars of, and fails primitives that attempt to
>> write, to read-only objects."
>>
>> ^(self parameterAt: 65)
>> ifNil: [false]
>> ifNotNil:
>> [:param| "In older VMs this is a boolean reflecting
>> MULTIPLE_BYTECODE_SETS"
>> param isInteger "In newer VMs it is a set of integer flags, bit 1 of
>> which is IMMUTABILITY"
>> ifTrue: [param anyMask: 2]
>> ifFalse: [false]]
>>
>>
>>
>> On Wed, Jan 25, 2017 at 2:06 PM, p...@highoctane.be 
>> wrote:
>>
>>> The "latest" Windows VM I do use has no such method.
>>>
>>> Virtual Machine
>>> ---
>>> C:\Users\Philippe\Dropbox\Sibelga\JiraAutomation\Pharo5.0\la
>>> testvm\pharo.exe
>>> CoInterpreter * VMMaker.oscog-eem.2090 uuid:
>>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>>> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid:
>>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>>> VM: 201701151442 https://github.com/pharo-project/pharo-vm.git $ Date:
>>> Sun Jan 15 15:42:39 2017 +0100 $ Plugins: 201701151442
>>> https://github.com/pharo-project/pharo-vm.git $
>>>
>>> Win32 built on Jan 15 2017 15:59:52 CUT Compiler: 5.4.0
>>> VMMaker versionString VM: 201701151442 https://github.com/pharo-proje
>>> ct/pharo-vm.git $ Date: Sun Jan 15 15:42:39 2017 +0100 $ Plugins:
>>> 201701151442 https://github.com/pharo-project/pharo-vm.git $
>>> CoInterpreter * VMMaker.oscog-eem.2090 uuid:
>>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>>> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid:
>>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>>>
>>> 
>>>
>>>
>>> On Wed, Jan 25, 2017 at 1:54 PM, Clément Bera 
>>> wrote:
>>>


 On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl 
 wrote:

> Does anyone know the state of immutability support in vm and image?
> The latest vm downloadable is compiled with
>
> IMMUTABILITY=1
>
> (Esteban said that). When I open a pharo6 image with this VM and do:
>
> ASUser new
> setIsReadOnlyObject: true;
> name: 'foo'
>
> with
>
> ASUser>>#name: arg1
> name := arg1
>
> I don't get an exception. Is there something missing or am I not
> understanding?
>

 Hi Norbert,

 Thank you very much for looking read-only objects.

 When mutating an instance variable, the VM triggers a call-back that by
 default does nothing. In your case, running your code does not raise an
 exception but the object should not be modified either. If you want an
 exception, you need to change the call-back code, i.e., the method
 Object>>#attemptToAssign: value withIndex: index. For example, you could
 write:

 Object>>#attemptToAssign: value withIndex: index
 | process |
 self notify: 'object changed !'.
 process := Processor activeProcess.
 [ process suspendedContext: process suspendedContext sender ] forkAt:
 Processor activePriority + 1.
 Processor yield.

 Then, your code should open a notification window with 'object
 changed', and proceeding keeps running the code without mutating the 
 object.

 One needs to build a ModificationTracker framework on top of the VM
 support I introduced. Multiple things are required, like default behavior
 in this call-back and in primitive failure code. I am willing to support
 and help anyone willing to build such a framework, but I won't build it
 myself.

 If you have any other questions or if you find bug don't hesitate to
 ask further questions

 Best,

 PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your
 system, if this is not the case it means the VM does not support read-only
 objects.

 Clement






>
> Norbert
>


>>>
>>
>
>

Re: [Pharo-dev] Immutability support

[Clément Bera]

On Wed, Jan 25, 2017 at 4:42 PM, Denis Kudriashov 
wrote:

> Another question Clement.
>
> I found that current method doing something strange:
>
> attemptToAssign: value withIndex: index
> process := Processor activeProcess.
> [ process suspendedContext: process suspendedContext sender ] forkAt:
> Processor activePriority + 1.
> Processor yield.
> "CAN'T REACH"
>
>
> Could you comment why new process needed here?
> I just check simple version with error and it works:
>
> attemptToAssign: value withIndex: index
> ^self error: 'modification failed'.
>
>
> Also if I will modify #contents: as "*^*contents:=newValue" then
> following code is working well:
>
> o := ValueHolder new.
> o beReadOnlyObject.
> [o contents: #test] on: Error do: [:err | err resumeUnchecked: #done]. "=>
> #done"
>
>
> So I not understand the problem described in method comment.
>

Hi Denis,

I will look into this case tomorrow, it looks like a bug. Thanks for
reporting.

For the Process hack, it's because the call-back was designed to return no
value. It may look like it works when returning a value but you will have
uncommon crashes.


> 2017-01-25 16:21 GMT+01:00 Denis Kudriashov :
>
>>
>> 2017-01-25 15:52 GMT+01:00 Clément Bera :
>>
>>> Overall, you need to:
>>> - change the code of all numbered primitives mutating objects (such as
>>> at:put:) so that when they fail because of a read-only object they call the
>>> modification tracker framework.
>>>
>>
>> I think it is for future.
>>
>> But now behaviour is just inconsistent because making object readonly
>> breaks any app using it *silently*.
>> Also I see that instVarAt:put: will raise error instead of skipping it.
>> So two ways to modify object lead to different behavior. It's not good.
>>
>> My conclusion: it must be error by default. Something like this:
>>
>> Object>>#attemptToAssign: value withIndex: index
>>   (ModificationForbidden for: self at: index with: value) signal
>>
>> It is not fix completely inconsistence with #instVarAt:put: but at least
>> they both will fail.
>>
>> By the way I was supprized that failed #instVarAt:put: shows "bad
>> receiver" in primitive *er* variable (). Is
>> "bad receiver" is always about mutability? And if not then how we will
>> distinguish different cases?
>>
>
>

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Thierry Goubier]

2017-01-25 16:34 GMT+01:00 Aliaksei Syrel :

> On 25 January 2017 at 16:02, Thierry Goubier 
>  wrote:
>
>> Yes, it goes a bit faster. But I stopped half way through the list: it is
>> tuned a lot slower than I'm used to with Morphic.
>
>
> Hehe :) Tuning is another story. Current implementation treats mouse wheel
> and trackpad in the same way, which should not be the case of course.
>

And you have to account a possible tuning for a touch screen as well...
I've made my tuning for the trackpad of my two laptops, more or less (a bit
oversensitive for the trackpad, but that makes the scrollwheel usable).


>
> Basically, If I compare the bloc class list to a Morphic class list
>> scrolling variable speed example, I really have to work out hard the scroll
>> wheel with Bloc... and, still, I'm not reaching the end of the list.
>
>
> I made a video comparison of 3 list implementations that display all
> smalltalk classes. I tried to scroll identically for all three cases and
> covered almost the same distance with mouse wheel:
> ​
>  Morphic-Bloc-Lists.mov
> 
> ​
> What morphic example did you use?
>

AltListTests exampleTree1. I'll try to show you side by side (but do I have
a scroll wheel at home? Not sure).

I've made a few irregular examples to test (2 items, with a random text
size from small to very large). Illustrates mostly how slow is subpixel
display of text in Morphic.


> I would be also very very glad to know what DNUs and segfaults you get :)
>

DNU is: Instance of BlSDLEventHandler did not understand #bitOr:

(note, this is the user version of Bloc, not the developer one)

Regards,

Thierry


>
>
> Cheers,
> Alex
>

Re: [Pharo-dev] Immutability support

[Denis Kudriashov]

Another question Clement.

I found that current method doing something strange:

attemptToAssign: value withIndex: index
process := Processor activeProcess.
[ process suspendedContext: process suspendedContext sender ] forkAt:
Processor activePriority + 1.
Processor yield.
"CAN'T REACH"


Could you comment why new process needed here?
I just check simple version with error and it works:

attemptToAssign: value withIndex: index
^self error: 'modification failed'.


Also if I will modify #contents: as "*^*contents:=newValue" then following
code is working well:

o := ValueHolder new.
o beReadOnlyObject.
[o contents: #test] on: Error do: [:err | err resumeUnchecked: #done]. "=>
#done"


So I not understand the problem described in method comment.

2017-01-25 16:21 GMT+01:00 Denis Kudriashov :

>
> 2017-01-25 15:52 GMT+01:00 Clément Bera :
>
>> Overall, you need to:
>> - change the code of all numbered primitives mutating objects (such as
>> at:put:) so that when they fail because of a read-only object they call the
>> modification tracker framework.
>>
>
> I think it is for future.
>
> But now behaviour is just inconsistent because making object readonly
> breaks any app using it *silently*.
> Also I see that instVarAt:put: will raise error instead of skipping it. So
> two ways to modify object lead to different behavior. It's not good.
>
> My conclusion: it must be error by default. Something like this:
>
> Object>>#attemptToAssign: value withIndex: index
>   (ModificationForbidden for: self at: index with: value) signal
>
> It is not fix completely inconsistence with #instVarAt:put: but at least
> they both will fail.
>
> By the way I was supprized that failed #instVarAt:put: shows "bad
> receiver" in primitive *er* variable (). Is
> "bad receiver" is always about mutability? And if not then how we will
> distinguish different cases?
>

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Aliaksei Syrel]

On 25 January 2017 at 16:02, Thierry Goubier 
 wrote:

> Yes, it goes a bit faster. But I stopped half way through the list: it is
> tuned a lot slower than I'm used to with Morphic.


Hehe :) Tuning is another story. Current implementation treats mouse wheel
and trackpad in the same way, which should not be the case of course.

Basically, If I compare the bloc class list to a Morphic class list
> scrolling variable speed example, I really have to work out hard the scroll
> wheel with Bloc... and, still, I'm not reaching the end of the list.


I made a video comparison of 3 list implementations that display all
smalltalk classes. I tried to scroll identically for all three cases and
covered almost the same distance with mouse wheel:
​
 Morphic-Bloc-Lists.mov

​
What morphic example did you use?
I would be also very very glad to know what DNUs and segfaults you get :)

Cheers,
Alex

Re: [Pharo-dev] Immutability support

[Denis Kudriashov]

2017-01-25 15:52 GMT+01:00 Clément Bera :

> Overall, you need to:
> - change the code of all numbered primitives mutating objects (such as
> at:put:) so that when they fail because of a read-only object they call the
> modification tracker framework.
>

I think it is for future.

But now behaviour is just inconsistent because making object readonly
breaks any app using it *silently*.
Also I see that instVarAt:put: will raise error instead of skipping it. So
two ways to modify object lead to different behavior. It's not good.

My conclusion: it must be error by default. Something like this:

Object>>#attemptToAssign: value withIndex: index
  (ModificationForbidden for: self at: index with: value) signal

It is not fix completely inconsistence with #instVarAt:put: but at least
they both will fail.

By the way I was supprized that failed #instVarAt:put: shows "bad receiver"
in primitive *er* variable (). Is "bad
receiver" is always about mutability? And if not then how we will
distinguish different cases?

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Thierry Goubier]

Hi Alex,

it's good to see widget development.

2017-01-25 15:40 GMT+01:00 Aliaksei Syrel :

> Hi Thierry
>
> Thanks for your testing effort!
>
>  moz2D prerequisites do not install cleanly on ubuntu 16.04.
>
> Exactly, it is hard to install many 32 dependencies on 64bit linux system.
> (there is no solution for this). That is why it would be nice to have 64
> bit VM for 64 bit linux :)
>

Yes. This is the reason I gave up on libcgit when I started GitFileTree:
too complex, no :i386 system lib available.


> With 64bit vm there will be almost none additional dependencies required.
>

Almost is the key... Given that the 64bits VM doesn't work properly on
Ubuntu 16.04 and 16.10, take that as a long term goal.


>
> They look nice and smooth, scrolling is tuned at slow for long lists.
>
> How do you scroll? Current scrolling behaviour is very simple while being
> rather powerful. Speed increases if user continuously scrolls with mouse
> wheel or touchpad. Faster you move your finger on touchpad or scroll more
> frequent with mouse wheel than faster is scrolling speed.
>

Ok, I tried again because I could not feel the acceleration effect.

Yes, it goes a bit faster. But I stopped half way through the list: it is
tuned a lot slower than I'm used to with Morphic.

Reversing scrolling direction halts it immediately or slows it down? I
could not see. Slow it down almost immediately (tried with the trackpad).


>
> It segfaults regularly when scrolling.
>
> This might be unrelated to the library. Could you send crash dump?
>
>  Do you have an example of scrolling where I can choose to scroll fast or
>> slow depending on how I use the trackpad or scrollwheel? On Linux, the OS
>> doesn't manipulate those events as Macs seems to be doing, so you need to
>> code that.
>
>
> This behaviour is a default one. Maybe problem is with SDL2 events? Video
> would be great to understand how you scroll and how you expect it to be :)
>

I'll try that on a lower-end machine.

Basically, If I compare the bloc class list to a Morphic class list
scrolling variable speed example, I really have to work out hard the scroll
wheel with Bloc... and, still, I'm not reaching the end of the list.

Works better with the track pad (reached the end, yes!) and had many DNUs.

Segfaults if I quit the image with a bloc window open.

Regards,

Thierry


> Cheers,
> Alex
>

Re: [Pharo-dev] Immutability support

[Clément Bera]

Norbert,

On Wed, Jan 25, 2017 at 3:36 PM, Norbert Hartl  wrote:

> Clément,
>
> Am 25.01.2017 um 13:54 schrieb Clément Bera :
>
>
>
> On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl  wro
> te:
>
>> Does anyone know the state of immutability support in vm and image? The
>> latest vm downloadable is compiled with
>>
>> IMMUTABILITY=1
>>
>> (Esteban said that). When I open a pharo6 image with this VM and do:
>>
>> ASUser new
>> setIsReadOnlyObject: true;
>> name: 'foo'
>>
>> with
>>
>> ASUser>>#name: arg1
>> name := arg1
>>
>> I don't get an exception. Is there something missing or am I not
>> understanding?
>>
>
> Hi Norbert,
>
> Thank you very much for looking read-only objects.
>
> When mutating an instance variable, the VM triggers a call-back that by
> default does nothing. In your case, running your code does not raise an
> exception but the object should not be modified either. If you want an
> exception, you need to change the call-back code, i.e., the method
> Object>>#attemptToAssign: value withIndex: index. For example, you could
> write:
>
> Object>>#attemptToAssign: value withIndex: index
> | process |
> self notify: 'object changed !'.
> process := Processor activeProcess.
> [ process suspendedContext: process suspendedContext sender ] forkAt:
> Processor activePriority + 1.
> Processor yield.
>
> Then, your code should open a notification window with 'object changed',
> and proceeding keeps running the code without mutating the object.
>
> thank you very much for the explanation. What was the rationale behind
> doing nothing as default? I can see there is two interpretations of
> read-only. One being just don't modify the object the other being throwing
> an exception when an attempt to modify is made. I think that having an
> exception thrown would make it easier to write code using it. I don't want
> to monkey patch Object but still make this general applicable.
>

Well, when I introduced the code I thought someone would build a
ModificationTracker framework... I think there should be a modification
tracker framework that throws an exception only if no program is registered
to handle the modification failure. No exception should be thrown in the
generic case.



>
> One needs to build a ModificationTracker framework on top of the VM
> support I introduced. Multiple things are required, like default behavior
> in this call-back and in primitive failure code. I am willing to support
> and help anyone willing to build such a framework, but I won't build it
> myself.
>
> Modification tracking is exactly the reason why I look into it. I have two
> other approaches doing modification tracking. But both are inferior to an
> approach using read-only objects.
>

Overall, you need to:
- change the code of all numbered primitives mutating objects (such as
at:put:) so that when they fail because of a read-only object they call the
modification tracker framework.
- add the call to the modification tracker framework from the
#attemptToAssign:withIndex: call-back.
- build a Modification tracker framework where external programs can easily
register themselves to catch modification on specific objects or all
instances of a specific class. Programs tracking modifications should be
able to temporarily make the object writable, perform the modification and
make it read-only again.

You can check the VisualWork implementation (check for example the
fall-back code of #at:put: and what it calls) and the comment I wrote in
#attemptToAssign:withIndex: to get inspired.

If you do something like that, please, *please*, please contribute it back
to the base Pharo image.

Thank you for experimenting with read-only objects. Don't hesitate to
contact me if you have issues or questions.


> Norbert
>
> If you have any other questions or if you find bug don't hesitate to ask
> further questions
>
> Best,
>
> PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your
> system, if this is not the case it means the VM does not support read-only
> objects.
>
> Clement
>
>
>
>
>
>
>>
>> Norbert
>
>
>

Re: [Pharo-dev] Immutability support

[p...@highoctane.be]

I am using a quite recent VM that Esteban provides on the JFrog bintray
(debug version with symbols).  So this is a bit surprising.

Phil

On Wed, Jan 25, 2017 at 3:41 PM, Clément Bera 
wrote:

> @Phil, then the VM does not support it. I believe the latest VM from
> files.pharo.org should support it, but not the stable one.
>
> @Denis Sure move it to MirrorPrimitive and update the WriteBarrier tests.
>
> On Wed, Jan 25, 2017 at 3:09 PM, Denis Kudriashov 
> wrote:
>
>>
>> 2017-01-25 13:59 GMT+01:00 Clément Bera :
>>
>>> It also raise another question: does these primitives support mirror
 approach? (when it can be called with receiver as first argument?)

>>>
>>> Yes I made sure the mirror approach works. Even better, there are tests
>>> ensuring that it works. You can see in the class WriteBarrierTest that
>>> objects can become read-only through an instance of TTMirror, look for
>>> example into the users of TTMirror>>#setIsReadOnlyObjectOf: object to:
>>> boolean.
>>>
>>
>> I think we need move it to MirrorPrimitives which was introduced in Pharo
>> 6.
>>
>
>

Re: [Pharo-dev] Immutability support

[Esteban Lorenzano]

nevertheless it should be there in latests vms.
which version are you using?

Esteban 

> On 25 Jan 2017, at 15:04, p...@highoctane.be wrote:
> 
> Tried it and it returns false for this Windows VM.
> 
> Phil
> 
> On Wed, Jan 25, 2017 at 2:14 PM, Clément Bera  > wrote:
> I introduced the method #supportsWriteBarrier in Pharo 6.
> 
> You can backport it if you want:
> 
> VirtualMachine>>#supportsWriteBarrier
>   "Answer whether the VM observes the per-object read-only flag and 
> consequently
>aborts writes to inst vars of, and fails primitives that attempt to 
> write, to read-only objects."
> 
>   ^(self parameterAt: 65)
>   ifNil: [false]
>   ifNotNil:
>   [:param| "In older VMs this is a boolean reflecting 
> MULTIPLE_BYTECODE_SETS"
>param isInteger "In newer VMs it is a set of integer 
> flags, bit 1 of which is IMMUTABILITY"
>   ifTrue: [param anyMask: 2]
>   ifFalse: [false]]
> 
> 
> 
> On Wed, Jan 25, 2017 at 2:06 PM, p...@highoctane.be 
>  > 
> wrote:
> The "latest" Windows VM I do use has no such method.
> 
> Virtual Machine
> ---
> C:\Users\Philippe\Dropbox\Sibelga\JiraAutomation\Pharo5.0\latestvm\pharo.exe
> CoInterpreter * VMMaker.oscog-eem.2090 uuid: 
> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid: 
> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
> VM: 201701151442 https://github.com/pharo-project/pharo-vm.git 
>  $ Date: Sun Jan 15 15:42:39 
> 2017 +0100 $ Plugins: 201701151442 
> https://github.com/pharo-project/pharo-vm.git 
>  $
> 
> Win32 built on Jan 15 2017 15:59:52 CUT Compiler: 5.4.0
> VMMaker versionString VM: 201701151442 
> https://github.com/pharo-project/pharo-vm.git 
>  $ Date: Sun Jan 15 15:42:39 
> 2017 +0100 $ Plugins: 201701151442 
> https://github.com/pharo-project/pharo-vm.git 
>  $
> CoInterpreter * VMMaker.oscog-eem.2090 uuid: 
> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid: 
> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
> 
> 
> 
> 
> On Wed, Jan 25, 2017 at 1:54 PM, Clément Bera  > wrote:
> 
> 
> On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl  > wrote:
> Does anyone know the state of immutability support in vm and image? The 
> latest vm downloadable is compiled with
> 
> IMMUTABILITY=1
> 
> (Esteban said that). When I open a pharo6 image with this VM and do:
> 
> ASUser new
> setIsReadOnlyObject: true;
> name: 'foo'
> 
> with
> 
> ASUser>>#name: arg1
> name := arg1
> 
> I don't get an exception. Is there something missing or am I not 
> understanding?
> 
> Hi Norbert,
> 
> Thank you very much for looking read-only objects.
> 
> When mutating an instance variable, the VM triggers a call-back that by 
> default does nothing. In your case, running your code does not raise an 
> exception but the object should not be modified either. If you want an 
> exception, you need to change the call-back code, i.e., the method 
> Object>>#attemptToAssign: value withIndex: index. For example, you could 
> write:
> 
> Object>>#attemptToAssign: value withIndex: index 
>   | process |
>   self notify: 'object changed !'.
>   process := Processor activeProcess.
>   [ process suspendedContext: process suspendedContext sender ] forkAt: 
> Processor activePriority + 1.
>   Processor yield.
> 
> Then, your code should open a notification window with 'object changed', and 
> proceeding keeps running the code without mutating the object.
> 
> One needs to build a ModificationTracker framework on top of the VM support I 
> introduced. Multiple things are required, like default behavior in this 
> call-back and in primitive failure code. I am willing to support and help 
> anyone willing to build such a framework, but I won't build it myself.
> 
> If you have any other questions or if you find bug don't hesitate to ask 
> further questions
> 
> Best,
> 
> PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your 
> system, if this is not the case it means the VM does not support read-only 
> objects.
> 
> Clement
> 
> 
> 
> 
>  
> 
> Norbert
> 
> 
> 
> 

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[p...@highoctane.be]

I am using LXC on Ubuntu to build 32 bits libraries without being bothered
by the 64 bits side of things.
Works nicely, especially since my user home is common to both.

See https://gist.github.com/philippeback/33717128d5fb24263e557922d5ac913e

Phil

On Wed, Jan 25, 2017 at 3:40 PM, Aliaksei Syrel 
wrote:

> Hi Thierry
>
> Thanks for your testing effort!
>
>  moz2D prerequisites do not install cleanly on ubuntu 16.04.
>
> Exactly, it is hard to install many 32 dependencies on 64bit linux system.
> (there is no solution for this). That is why it would be nice to have 64
> bit VM for 64 bit linux :)
> With 64bit vm there will be almost none additional dependencies required.
>
> They look nice and smooth, scrolling is tuned at slow for long lists.
>
> How do you scroll? Current scrolling behaviour is very simple while being
> rather powerful. Speed increases if user continuously scrolls with mouse
> wheel or touchpad. Faster you move your finger on touchpad or scroll more
> frequent with mouse wheel than faster is scrolling speed.
>
> It segfaults regularly when scrolling.
>
> This might be unrelated to the library. Could you send crash dump?
>
>  Do you have an example of scrolling where I can choose to scroll fast or
>> slow depending on how I use the trackpad or scrollwheel? On Linux, the OS
>> doesn't manipulate those events as Macs seems to be doing, so you need to
>> code that.
>
>
> This behaviour is a default one. Maybe problem is with SDL2 events? Video
> would be great to understand how you scroll and how you expect it to be :)
>
> Cheers,
> Alex
>

Re: [Pharo-dev] Immutability support

[Clément Bera]

@Phil, then the VM does not support it. I believe the latest VM from
files.pharo.org should support it, but not the stable one.

@Denis Sure move it to MirrorPrimitive and update the WriteBarrier tests.

On Wed, Jan 25, 2017 at 3:09 PM, Denis Kudriashov 
wrote:

>
> 2017-01-25 13:59 GMT+01:00 Clément Bera :
>
>> It also raise another question: does these primitives support mirror
>>> approach? (when it can be called with receiver as first argument?)
>>>
>>
>> Yes I made sure the mirror approach works. Even better, there are tests
>> ensuring that it works. You can see in the class WriteBarrierTest that
>> objects can become read-only through an instance of TTMirror, look for
>> example into the users of TTMirror>>#setIsReadOnlyObjectOf: object to:
>> boolean.
>>
>
> I think we need move it to MirrorPrimitives which was introduced in Pharo
> 6.
>

Re: [Pharo-dev] Google summer of code

[Ben Coman]

On Wed, Jan 25, 2017 at 4:44 PM, Thierry Goubier 
wrote:

> Hi guys,
>
> what I noted from the last attempts is that the Pharo proposal goes like
> that:
>
> - here is a nice list of project ideas
>
> - newcomers just have to use our current set of tools for interacting and
> producing code (that is
>  slack / mailing list / smalltalkhub / github / fogbugz / medium / etc...)
>
> Maybe preparing something (or planning to) a bit centralized and dedicated
> to GSoC for the last point could be nice, just to explain that we're paying
> attention to GSoC participants.
>


In the past, the GSoC participants seemed to have done their work in
isolation away from the main community.  I often felt the community didn't
hear much from most participants.
I think this is a bit adverse to the state goals of GSoC...

 * Help open source projects identify and bring in new developers. [1]
 * Help students integrate with their development community and so
encourage them to become lifetime contributors [1]
 * During the bonding period, students are expected to get to know their
project communities and participate in project discussion [1]
 * Get students engaged socially in the project. [2]
 * This is about building the STUDENT’S experience. Getting code in your
project is a nice side effect. [3]

Perhaps those are worth some focus in the application and project
selection.

[1] http://write.flossmanuals.net/gsoc-mentoring/what-is-gsoc/
[2] http://write.flossmanuals.net/gsoc-mentoring/mind-the-gap/
[3] http://write.flossmanuals.net/gsoc-mentoring/notes-for-
first-year-organizations/

cheers -ben


> Regards,
>
> Thierry
>
> 2017-01-25 9:21 GMT+01:00 Stephane Ducasse :
>
>> Yuriy I cleaned many of the proposal
>> could you do a pass on yours and keep max 4-5 of them?
>>
>> On Mon, Jan 23, 2017 at 5:15 PM, Yuriy Tymchuk 
>> wrote:
>>
>>> I can also update my projects and help with the application if needed (I
>>> was a part of the application team for the last two years I think)
>>>
>>> Uko
>>>
>>> On 22 Jan 2017, at 16:33, Jigyasa Grover 
>>> wrote:
>>>
>>> Also, a good application is equally important as the list of clearly
>>> defined projects.
>>>
>>> - J
>>>
>>> On Sun, Jan 22, 2017 at 4:30 PM, Serge Stinckwich <
>>> serge.stinckw...@gmail.com> wrote:
>>>
 The list of previous projects is here:
 https://github.com/pharo-project/pharo-project-proposals

 On Sat, Jan 21, 2017 at 10:06 AM, Jigyasa Grover
  wrote:
 > Dear Prof Serge
 >
 > Thanks for the introduction.
 >
 > Dear Alexandre
 > I have been a past Google Summer of Code student and also mentor
 budding
 > developers in Google Code-In.
 > This time, I was hoping to plug-in the loopholes which might have been
 > present in last year's organisation application.
 > Kindly let me know how can we collaborate further on this.
 > Looking forward to your response.
 > Thanks and Regards
 > Jigyasa
 >
 >
 > On Sat, Jan 21, 2017 at 9:06 AM,  wrote:
 >>
 >>
 >>
 >>
 >>
 >> Envoyé de mon iPhone
 >> Le 20 janv. 2017 à 22:21, Yuriy Tymchuk  a
 écrit :
 >>
 >> What do we do?
 >>
 >>
 >>
 >> We have to apply ! ;-)
 >>
 >> We talk with Jigyasa Grover who is doing an internship in my lab at
 the
 >> moment and she is willing to help. Jigyasa was a student in a former
 Google
 >> Summer of code and is involved in several open-source initiative
 like Women
 >> who Code and FOSSASIA. She is a mentor of GoogleCodeIn.
 >>
 >> You can find a small presentation during last FOSSASIA : "
 >>
 >> My journey in FOSS with Pharo & FOSSASIA by Jigyasa Grover - FOSSASIA
 >> 2016"
 >>
 >> https://m.youtube.com/watch?v=uLIzylxvIz4
 >>
 >> She has done a streaming video this morning also:
 http://goo.gl/UyclKP
 >> http://youtube.com/watch?v=2iRG_jpOL54
 >>
 >> Anyone to help her setup a small team for Pharo proposal to Google
 Summer
 >> of Code this year ?
 >>
 >>
 >> On 20 Jan 2017, at 20:38, Alexandre Bergel 
 >> wrote:
 >>
 >> Hi everyone-
 >>
 >> Google Summer of Code 2017 has officially begun! Organization
 applications
 >> open today, Thursday January 19 and are open through Thursday,
 February 9th.
 >> Please see our program site, official timeline and FAQ for more
 details.
 >>
 >> What makes a good organization application? Take a look at our
 manuals for
 >> tips and best practices.
 >>
 >> We look forward to seeing each of your applications and kicking off
 >> another great year of GSoC. If you have any questions, don’t
 hesitate to
 >> reach out to gsoc-supp...@google.com. 

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Aliaksei Syrel]

Hi Thierry

Thanks for your testing effort!

 moz2D prerequisites do not install cleanly on ubuntu 16.04.

Exactly, it is hard to install many 32 dependencies on 64bit linux system.
(there is no solution for this). That is why it would be nice to have 64
bit VM for 64 bit linux :)
With 64bit vm there will be almost none additional dependencies required.

They look nice and smooth, scrolling is tuned at slow for long lists.

How do you scroll? Current scrolling behaviour is very simple while being
rather powerful. Speed increases if user continuously scrolls with mouse
wheel or touchpad. Faster you move your finger on touchpad or scroll more
frequent with mouse wheel than faster is scrolling speed.

It segfaults regularly when scrolling.

This might be unrelated to the library. Could you send crash dump?

 Do you have an example of scrolling where I can choose to scroll fast or
> slow depending on how I use the trackpad or scrollwheel? On Linux, the OS
> doesn't manipulate those events as Macs seems to be doing, so you need to
> code that.


This behaviour is a default one. Maybe problem is with SDL2 events? Video
would be great to understand how you scroll and how you expect it to be :)

Cheers,
Alex

Re: [Pharo-dev] Immutability support

[Norbert Hartl]

Clément,

> Am 25.01.2017 um 13:54 schrieb Clément Bera :
> 
> 
> 
> On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl  > wrote:
> Does anyone know the state of immutability support in vm and image? The 
> latest vm downloadable is compiled with
> 
> IMMUTABILITY=1
> 
> (Esteban said that). When I open a pharo6 image with this VM and do:
> 
> ASUser new
> setIsReadOnlyObject: true;
> name: 'foo'
> 
> with
> 
> ASUser>>#name: arg1
> name := arg1
> 
> I don't get an exception. Is there something missing or am I not 
> understanding?
> 
> Hi Norbert,
> 
> Thank you very much for looking read-only objects.
> 
> When mutating an instance variable, the VM triggers a call-back that by 
> default does nothing. In your case, running your code does not raise an 
> exception but the object should not be modified either. If you want an 
> exception, you need to change the call-back code, i.e., the method 
> Object>>#attemptToAssign: value withIndex: index. For example, you could 
> write:
> 
> Object>>#attemptToAssign: value withIndex: index 
>   | process |
>   self notify: 'object changed !'.
>   process := Processor activeProcess.
>   [ process suspendedContext: process suspendedContext sender ] forkAt: 
> Processor activePriority + 1.
>   Processor yield.
> 
> Then, your code should open a notification window with 'object changed', and 
> proceeding keeps running the code without mutating the object.
> 
thank you very much for the explanation. What was the rationale behind doing 
nothing as default? I can see there is two interpretations of read-only. One 
being just don't modify the object the other being throwing an exception when 
an attempt to modify is made. I think that having an exception thrown would 
make it easier to write code using it. I don't want to monkey patch Object but 
still make this general applicable.

> One needs to build a ModificationTracker framework on top of the VM support I 
> introduced. Multiple things are required, like default behavior in this 
> call-back and in primitive failure code. I am willing to support and help 
> anyone willing to build such a framework, but I won't build it myself.
> 
Modification tracking is exactly the reason why I look into it. I have two 
other approaches doing modification tracking. But both are inferior to an 
approach using read-only objects.

Norbert 

> If you have any other questions or if you find bug don't hesitate to ask 
> further questions
> 
> Best,
> 
> PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your 
> system, if this is not the case it means the VM does not support read-only 
> objects.
> 
> Clement
> 
> 
> 
> 
>  
> 
> Norbert

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/60356
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] a971e2: 60356

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: a971e21d0feef4294360ce08c630eb1bbdd6416f
  
https://github.com/pharo-project/pharo-core/commit/a971e21d0feef4294360ce08c630eb1bbdd6416f
  Author: Jenkins Build Server 
  Date:   2017-01-25 (Wed, 25 Jan 2017)

  Changed paths:
M 
ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/tags/stable_.st
A 
ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/versions/version807_.st
M Epicea.package/EpMonitor.class/instance/announcement 
handling/monticelloVersionSaved_.st
A Epicea.package/extension/MCCacheRepository/instance/isEpiceaCache.st
A Epicea.package/extension/MCDictionaryRepository/instance/isEpiceaCache.st
A Epicea.package/extension/MCRepository/instance/isEpiceaCache.st
M EpiceaBrowsers.package/EpEntryItem.class/instance/converting/asMorph.st
R 
EpiceaBrowsers.package/EpEntryItem.class/instance/operations/authorString.st
A Ombu.package/OmSessionStore.class/class/initialization/initialize.st
A Ombu.package/OmSessionStore.class/class/initialization/startUp.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60355.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60356.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60355.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60356.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60356
19590 Integrate new Epicea release
https://pharo.fogbugz.com/f/cases/19590

http://files.pharo.org/image/60/60356.zip

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Tudor Girba]

Hi,

Thanks a lot for this!

Alex: would you like to take over? :)

Cheers,
Doru


> On Jan 25, 2017, at 3:21 PM, Thierry Goubier  
> wrote:
> 
> 
> 
> 2017-01-25 13:40 GMT+01:00 Denis Kudriashov :
> 
> 2017-01-25 11:45 GMT+01:00 Thierry Goubier :
> > Nevertheless, it would be very cool to have people test this assumption on 
> > old machines. I think Thierry was saying that he has an old machine :). 
> > @Thierry?
> >
> > I have low-end systems on very recent software (chromebook on Ubuntu 16.10, 
> > laptop on 16.04), which causes two issues:
> > - Fairly slow (shows clearly where Pharo is slow or fast)
> > - Too new (breaks some vms)
> >
> > I can be a good performance indicator, yes.
> 
> Great. It would be really cool if you could give Bloc a try :).
> 
> Should I just give it a try, or do you have something specific in mind I 
> should bench (response time, animation jitter, etc..)?
> 
> Would be nice just to know your feedback about BlInfiniteLinearLayoutExamples 
> on old machines. They provide very smooth scrolling on big lists. So it 
> should be just visible: fast it or slow.
> 
> First return: moz2D prerequisites do not install cleanly on ubuntu 16.04.
> 
> They look nice and smooth, scrolling is tuned at slow for long lists.
> 
> It segfaults regularly when scrolling.
> 
> Do you have an example of scrolling where I can choose to scroll fast or slow 
> depending on how I use the trackpad or scrollwheel? On Linux, the OS doesn't 
> manipulate those events as Macs seems to be doing, so you need to code that.
> 
> Regards,
> 
> Thierry

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

"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Thierry Goubier]

2017-01-25 13:40 GMT+01:00 Denis Kudriashov :

>
> 2017-01-25 11:45 GMT+01:00 Thierry Goubier :
>
>> > Nevertheless, it would be very cool to have people test this assumption
>>> on old machines. I think Thierry was saying that he has an old machine :).
>>> @Thierry?
>>> >
>>> > I have low-end systems on very recent software (chromebook on Ubuntu
>>> 16.10, laptop on 16.04), which causes two issues:
>>> > - Fairly slow (shows clearly where Pharo is slow or fast)
>>> > - Too new (breaks some vms)
>>> >
>>> > I can be a good performance indicator, yes.
>>>
>>> Great. It would be really cool if you could give Bloc a try :).
>>>
>>
>> Should I just give it a try, or do you have something specific in mind I
>> should bench (response time, animation jitter, etc..)?
>>
>
> Would be nice just to know your feedback about BlInfiniteLinearLayoutExamples
> on old machines. They provide very smooth scrolling on big lists. So it
> should be just visible: fast it or slow.
>

First return: moz2D prerequisites do not install cleanly on ubuntu 16.04.

They look nice and smooth, scrolling is tuned at slow for long lists.

It segfaults regularly when scrolling.

Do you have an example of scrolling where I can choose to scroll fast or
slow depending on how I use the trackpad or scrollwheel? On Linux, the OS
doesn't manipulate those events as Macs seems to be doing, so you need to
code that.

Regards,

Thierry

Re: [Pharo-dev] Immutability support

[Denis Kudriashov]

2017-01-25 13:59 GMT+01:00 Clément Bera :

> It also raise another question: does these primitives support mirror
>> approach? (when it can be called with receiver as first argument?)
>>
>
> Yes I made sure the mirror approach works. Even better, there are tests
> ensuring that it works. You can see in the class WriteBarrierTest that
> objects can become read-only through an instance of TTMirror, look for
> example into the users of TTMirror>>#setIsReadOnlyObjectOf: object to:
> boolean.
>

I think we need move it to MirrorPrimitives which was introduced in Pharo 6.

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Tudor Girba]

Hi,

Yes, Sparta is independent from Athens. We actually started originally from 
Athens with a few modifications, but that soon proved to not be feasible 
because Athens also has to accommodate Morphic while Bloc is being developed.

Sparta has a similar structure and intent as Athens, but it differs in some 
essential ways:
- it has local coordinates.
- it offers clipping based on arbitrary shape, not only rectangle.
- it is for the most part stateless which makes it more suitable for composing 
independent visual pieces. This one in particular influences the public API.

About engaging the Moz2D community, we can work on that.

Cheers,
Doru


> On Jan 25, 2017, at 1:52 PM, Guillermo Polito  
> wrote:
> 
> Hi Doru,
> 
> First, I understand the effort you all made to make this big piece of work. I 
> have however some questions that probably you can help with:
> 
> 1) I understand Sparta is a library completely independent from Athens. But I 
> also understand that they follow the same reasoning and general design (a 
> general API to deal with 2D vectorial graphics with pluggable backends).
>   - What are the differences between sparta and athens then? This is really 
> unclear to me. Are there differences in the API? in the internal backend 
> requirements?
>   - In case there are many differences, What are the reasons that made you 
> implement a complete new library and not just extend the existing one 
> (Athens)?  
>   - or even, just make a moz2d backend for athens?
> 
> 2) About moz2d. I understand how the build process you use works. But it 
> looks a bit fragile. You mention engaging the mozilla people. I think this is 
> really important,
>   - either they could propose an alternative solution to what you're doing
>   - or, if you contribute back your patches to mozilla (which I think you 
> should), this will make your process depend less on custom-made patches
>   - besides, creating a link between the two communities is probably worth 
> it: people in mozilla may consider how their changes impact their users.
> 
> Guille
> 
> On Wed, Jan 25, 2017 at 12:41 PM, Tudor Girba  wrote:
> Hi,
> 
> Thank you for the intensive set of issues you raised during the Bloc 
> presentation. I think it is worthwhile addressing them more thoroughly, so 
> let me start with the issue that seemed to have caused the most worries: 
> Sparta & Moz2D.
> 
> Please keep in mind that while I am involved to some extent in Bloc, the real 
> credits for the current state go to Glenn and Alex.
> 
> Moz2D (https://github.com/mozilla/moz2d, 
> https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend and 
> using it puts us on par with the rendering speed of a web browser, which is a 
> significant added value over what we have now.
> 
> However, as it was noted, it does come with a cost due to the fact that it is 
> not available as standalone with only the features we are interested in. The 
> vector graphics part is actually buildable out of the box. However, the text 
> support needs to be extracted out of Moz2D, and this is where the patching 
> scripts are used. The patches are there only for compilation purposes and not 
> for features and they are applied automatically. You can see it here:
> https://github.com/syrel/Moz2D
> 
> Alex updated recently the Moz2D version and it worked without problems. Of 
> course, future changes in Moz2D might imply changes in this script as well, 
> and this implies that we will need to maintain that script. And we could 
> imagine applying these patches on the trunk of Moz2D to see if they work, and 
> we can also imagine engaging with the Moz2D owners to see if we can find a 
> middle ground.
> 
> Now, let’s put this into perspective. We are currently using Athens and the 
> Cairo backend. While Cairo is provided as a standalone library it has not 
> seen significant advances since Mozzila shifted its focus towards Moz2D. So, 
> sticking with it might not be an ideal strategy either.
> 
> Furthermore, just like Athens, Sparta is an abstraction that allows us to 
> switch the underlying backend should we need to. Until now we did not find a 
> cross-platform backend that is as advanced and complete as Moz2D, but there 
> is no reason to think that none other will appear in the future. Skia is an 
> alternative but it is only a vector graphic engine without text support, so 
> using it would imply to have another library for the text support.
> 
> Sparta also comes with a reasonable set of tests that is aimed at testing the 
> basic Moz2D functionality to make sure that the assumptions on top of which 
> Sparta is built are correct.
> 
> All in all, I think that the current situation is not ideal, but there is 
> already enough engineering in place to actually make it work. And I 
> definitely think that the potential it opens is rather significant.
> 
> And, if more people look at the scripts, we might find even better 

Re: [Pharo-dev] Immutability support

[p...@highoctane.be]

Tried it and it returns false for this Windows VM.

Phil

On Wed, Jan 25, 2017 at 2:14 PM, Clément Bera 
wrote:

> I introduced the method #supportsWriteBarrier in Pharo 6.
>
> You can backport it if you want:
>
> VirtualMachine>>#supportsWriteBarrier
> "Answer whether the VM observes the per-object read-only flag and
> consequently
> aborts writes to inst vars of, and fails primitives that attempt to write,
> to read-only objects."
>
> ^(self parameterAt: 65)
> ifNil: [false]
> ifNotNil:
> [:param| "In older VMs this is a boolean reflecting MULTIPLE_BYTECODE_SETS"
> param isInteger "In newer VMs it is a set of integer flags, bit 1 of which
> is IMMUTABILITY"
> ifTrue: [param anyMask: 2]
> ifFalse: [false]]
>
>
>
> On Wed, Jan 25, 2017 at 2:06 PM, p...@highoctane.be 
> wrote:
>
>> The "latest" Windows VM I do use has no such method.
>>
>> Virtual Machine
>> ---
>> C:\Users\Philippe\Dropbox\Sibelga\JiraAutomation\Pharo5.0\
>> latestvm\pharo.exe
>> CoInterpreter * VMMaker.oscog-eem.2090 uuid:
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid:
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>> VM: 201701151442 https://github.com/pharo-project/pharo-vm.git $ Date:
>> Sun Jan 15 15:42:39 2017 +0100 $ Plugins: 201701151442
>> https://github.com/pharo-project/pharo-vm.git $
>>
>> Win32 built on Jan 15 2017 15:59:52 CUT Compiler: 5.4.0
>> VMMaker versionString VM: 201701151442 https://github.com/pharo-proje
>> ct/pharo-vm.git $ Date: Sun Jan 15 15:42:39 2017 +0100 $ Plugins:
>> 201701151442 https://github.com/pharo-project/pharo-vm.git $
>> CoInterpreter * VMMaker.oscog-eem.2090 uuid:
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid:
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>>
>> [image: Inline image 1]
>>
>>
>> On Wed, Jan 25, 2017 at 1:54 PM, Clément Bera 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl 
>>> wrote:
>>>
 Does anyone know the state of immutability support in vm and image? The
 latest vm downloadable is compiled with

 IMMUTABILITY=1

 (Esteban said that). When I open a pharo6 image with this VM and do:

 ASUser new
 setIsReadOnlyObject: true;
 name: 'foo'

 with

 ASUser>>#name: arg1
 name := arg1

 I don't get an exception. Is there something missing or am I not
 understanding?

>>>
>>> Hi Norbert,
>>>
>>> Thank you very much for looking read-only objects.
>>>
>>> When mutating an instance variable, the VM triggers a call-back that by
>>> default does nothing. In your case, running your code does not raise an
>>> exception but the object should not be modified either. If you want an
>>> exception, you need to change the call-back code, i.e., the method
>>> Object>>#attemptToAssign: value withIndex: index. For example, you could
>>> write:
>>>
>>> Object>>#attemptToAssign: value withIndex: index
>>> | process |
>>> self notify: 'object changed !'.
>>> process := Processor activeProcess.
>>> [ process suspendedContext: process suspendedContext sender ] forkAt:
>>> Processor activePriority + 1.
>>> Processor yield.
>>>
>>> Then, your code should open a notification window with 'object changed',
>>> and proceeding keeps running the code without mutating the object.
>>>
>>> One needs to build a ModificationTracker framework on top of the VM
>>> support I introduced. Multiple things are required, like default behavior
>>> in this call-back and in primitive failure code. I am willing to support
>>> and help anyone willing to build such a framework, but I won't build it
>>> myself.
>>>
>>> If you have any other questions or if you find bug don't hesitate to ask
>>> further questions
>>>
>>> Best,
>>>
>>> PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your
>>> system, if this is not the case it means the VM does not support read-only
>>> objects.
>>>
>>> Clement
>>>
>>>
>>>
>>>
>>>
>>>

 Norbert

>>>
>>>
>>
>

Re: [Pharo-dev] Immutability support

[Clément Bera]

I introduced the method #supportsWriteBarrier in Pharo 6.

You can backport it if you want:

VirtualMachine>>#supportsWriteBarrier
"Answer whether the VM observes the per-object read-only flag and
consequently
aborts writes to inst vars of, and fails primitives that attempt to write,
to read-only objects."

^(self parameterAt: 65)
ifNil: [false]
ifNotNil:
[:param| "In older VMs this is a boolean reflecting MULTIPLE_BYTECODE_SETS"
param isInteger "In newer VMs it is a set of integer flags, bit 1 of which
is IMMUTABILITY"
ifTrue: [param anyMask: 2]
ifFalse: [false]]



On Wed, Jan 25, 2017 at 2:06 PM, p...@highoctane.be 
wrote:

> The "latest" Windows VM I do use has no such method.
>
> Virtual Machine
> ---
> C:\Users\Philippe\Dropbox\Sibelga\JiraAutomation\Pharo5.
> 0\latestvm\pharo.exe
> CoInterpreter * VMMaker.oscog-eem.2090 uuid: 
> 63a161b9-17e1-4911-a89a-1687d9ba9a1a
> Jan 15 2017
> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid:
> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
> VM: 201701151442 https://github.com/pharo-project/pharo-vm.git $ Date:
> Sun Jan 15 15:42:39 2017 +0100 $ Plugins: 201701151442
> https://github.com/pharo-project/pharo-vm.git $
>
> Win32 built on Jan 15 2017 15:59:52 CUT Compiler: 5.4.0
> VMMaker versionString VM: 201701151442 https://github.com/pharo-
> project/pharo-vm.git $ Date: Sun Jan 15 15:42:39 2017 +0100 $ Plugins:
> 201701151442 https://github.com/pharo-project/pharo-vm.git $
> CoInterpreter * VMMaker.oscog-eem.2090 uuid: 
> 63a161b9-17e1-4911-a89a-1687d9ba9a1a
> Jan 15 2017
> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid:
> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>
> [image: Inline image 1]
>
>
> On Wed, Jan 25, 2017 at 1:54 PM, Clément Bera 
> wrote:
>
>>
>>
>> On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl 
>> wrote:
>>
>>> Does anyone know the state of immutability support in vm and image? The
>>> latest vm downloadable is compiled with
>>>
>>> IMMUTABILITY=1
>>>
>>> (Esteban said that). When I open a pharo6 image with this VM and do:
>>>
>>> ASUser new
>>> setIsReadOnlyObject: true;
>>> name: 'foo'
>>>
>>> with
>>>
>>> ASUser>>#name: arg1
>>> name := arg1
>>>
>>> I don't get an exception. Is there something missing or am I not
>>> understanding?
>>>
>>
>> Hi Norbert,
>>
>> Thank you very much for looking read-only objects.
>>
>> When mutating an instance variable, the VM triggers a call-back that by
>> default does nothing. In your case, running your code does not raise an
>> exception but the object should not be modified either. If you want an
>> exception, you need to change the call-back code, i.e., the method
>> Object>>#attemptToAssign: value withIndex: index. For example, you could
>> write:
>>
>> Object>>#attemptToAssign: value withIndex: index
>> | process |
>> self notify: 'object changed !'.
>> process := Processor activeProcess.
>> [ process suspendedContext: process suspendedContext sender ] forkAt:
>> Processor activePriority + 1.
>> Processor yield.
>>
>> Then, your code should open a notification window with 'object changed',
>> and proceeding keeps running the code without mutating the object.
>>
>> One needs to build a ModificationTracker framework on top of the VM
>> support I introduced. Multiple things are required, like default behavior
>> in this call-back and in primitive failure code. I am willing to support
>> and help anyone willing to build such a framework, but I won't build it
>> myself.
>>
>> If you have any other questions or if you find bug don't hesitate to ask
>> further questions
>>
>> Best,
>>
>> PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your
>> system, if this is not the case it means the VM does not support read-only
>> objects.
>>
>> Clement
>>
>>
>>
>>
>>
>>
>>>
>>> Norbert
>>>
>>
>>
>

Re: [Pharo-dev] Immutability support

[Clément Bera]

On Wed, Jan 25, 2017 at 12:59 PM, Esteban Lorenzano 
wrote:

> but this is not real immutability, is like a write barrier, that’s why
> those method names were not chosen.
>

As Esteban mentioned, read-only objects are not immutable objects, that's
why we didn't use these names. This followed a lot of discussion with many
mails (read-only objects are working for a year now, so we had time to
discuss) and I don't think we should discuss again this topic.


> Esteban
>
>
> On 25 Jan 2017, at 12:37, p...@highoctane.be wrote:
>
> So, beImmutable and beMutable seem pretty usable and not collision causing
> IMHO.
>
> Phil
>
> On Wed, Jan 25, 2017 at 12:19 PM, Norbert Hartl 
> wrote:
>
>>
>> Am 25.01.2017 um 12:16 schrieb Esteban Lorenzano :
>>
>>
>> On 25 Jan 2017, at 12:04, Denis Kudriashov  wrote:
>>
>>
>> 2017-01-25 12:03 GMT+01:00 Denis Kudriashov :
>>
>>> I think problem that these names could be already in use by frameworks.
>>> I am sure #isReadOnly, #beReadOnly is used in many UI's. For example
>>> Margitte uses it
>>
>>
>> And probably Glorp
>>
>>
>> yes, but #setIsReadOnlyObject: deserves a place in the podium of ugly
>> names :)
>>
>> Absolutely. And we are a really caring community because we care so much
>> about a method name of a feature that does not work :)
>>
>> Norbert
>>
>> I thought the names were going to be like beWritable/beNotWritable/isWri
>> table
>> which are not a lot better, but well…
>>
>> Esteban
>>
>>
>>
>
>

[Pharo-dev] [pharo-project/pharo-core] 3bb59c: 60355

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 3bb59c064656e99de53bfc9092a643229cee9f68
  
https://github.com/pharo-project/pharo-core/commit/3bb59c064656e99de53bfc9092a643229cee9f68
  Author: Jenkins Build Server 
  Date:   2017-01-25 (Wed, 25 Jan 2017)

  Changed paths:
R 
GT-Debugger.package/GTGenericStackDebugger.class/instance/updating/updateBrowser.st
M GT-Debugger.package/GTMoldableDebugger.class/instance/scripting 
opening/open.st
A SUnit-Core.package/extension/TClassDescription/instance/isTestCase.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60354.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60355.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60354.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60355.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
R Traits.package/TClassDescription.class/instance/testing/isTestCase.st

  Log Message:
  ---
  60355
19593 TClassDescription>>#isTestCase should be in SUnit-Core
https://pharo.fogbugz.com/f/cases/19593

19558 GtDebugger should not call #updateSelectionInterval in #updateBrowser
https://pharo.fogbugz.com/f/cases/19558

http://files.pharo.org/image/60/60355.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/60355
  Home:   https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] Immutability support

[p...@highoctane.be]

The "latest" Windows VM I do use has no such method.

Virtual Machine
---
C:\Users\Philippe\Dropbox\Sibelga\JiraAutomation\Pharo5.0\latestvm\pharo.exe
CoInterpreter * VMMaker.oscog-eem.2090 uuid:
63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid:
63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
VM: 201701151442 https://github.com/pharo-project/pharo-vm.git $ Date: Sun
Jan 15 15:42:39 2017 +0100 $ Plugins: 201701151442
https://github.com/pharo-project/pharo-vm.git $

Win32 built on Jan 15 2017 15:59:52 CUT Compiler: 5.4.0
VMMaker versionString VM: 201701151442
https://github.com/pharo-project/pharo-vm.git $ Date: Sun Jan 15 15:42:39
2017 +0100 $ Plugins: 201701151442
https://github.com/pharo-project/pharo-vm.git $
CoInterpreter * VMMaker.oscog-eem.2090 uuid:
63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid:
63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017

[image: Inline image 1]


On Wed, Jan 25, 2017 at 1:54 PM, Clément Bera 
wrote:

>
>
> On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl 
> wrote:
>
>> Does anyone know the state of immutability support in vm and image? The
>> latest vm downloadable is compiled with
>>
>> IMMUTABILITY=1
>>
>> (Esteban said that). When I open a pharo6 image with this VM and do:
>>
>> ASUser new
>> setIsReadOnlyObject: true;
>> name: 'foo'
>>
>> with
>>
>> ASUser>>#name: arg1
>> name := arg1
>>
>> I don't get an exception. Is there something missing or am I not
>> understanding?
>>
>
> Hi Norbert,
>
> Thank you very much for looking read-only objects.
>
> When mutating an instance variable, the VM triggers a call-back that by
> default does nothing. In your case, running your code does not raise an
> exception but the object should not be modified either. If you want an
> exception, you need to change the call-back code, i.e., the method
> Object>>#attemptToAssign: value withIndex: index. For example, you could
> write:
>
> Object>>#attemptToAssign: value withIndex: index
> | process |
> self notify: 'object changed !'.
> process := Processor activeProcess.
> [ process suspendedContext: process suspendedContext sender ] forkAt:
> Processor activePriority + 1.
> Processor yield.
>
> Then, your code should open a notification window with 'object changed',
> and proceeding keeps running the code without mutating the object.
>
> One needs to build a ModificationTracker framework on top of the VM
> support I introduced. Multiple things are required, like default behavior
> in this call-back and in primitive failure code. I am willing to support
> and help anyone willing to build such a framework, but I won't build it
> myself.
>
> If you have any other questions or if you find bug don't hesitate to ask
> further questions
>
> Best,
>
> PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your
> system, if this is not the case it means the VM does not support read-only
> objects.
>
> Clement
>
>
>
>
>
>
>>
>> Norbert
>>
>
>

Re: [Pharo-dev] Immutability support

[Clément Bera]

Hi again.

On Wed, Jan 25, 2017 at 12:04 PM, Denis Kudriashov 
wrote:

>
> 2017-01-25 12:03 GMT+01:00 Denis Kudriashov :
>
>> I think problem that these names could be already in use by frameworks. I
>> am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte
>> uses it
>
>
> And probably Glorp
>

The only thing we (the VM developers) care is that we have only 2
primitives, 163 to check is an object is read-only and 164 to change the
read-only property of an object. We do not want to have #beReadOnlyObject
and #beWritableObject as 2 different primitives, we prefer having only one
primitive to mutate the state, which is currently in the
Object>>#setIsReadOnlyObject: method.

The Pharo community is free to pick the names they like for their
primitives. We tried to use #isReadOnly, #isWritable and #beReadOnly, but
as Denis mentioned, there were conflicts with other frameworks. If you
rename Object>>#attemptToAssign:withIndex:, don't forget to update the
special object array with the new selector.

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[p...@highoctane.be]

I have got all of the old Pen demos.
No big deal to adjust them to Bloc I think.

Phil

On Wed, Jan 25, 2017 at 12:45 PM, Tudor Girba  wrote:

> Nice ideas!
>
> What would be cool if someone else would like to try to implement any of
> these. Anyone interested?
>
> Cheers,
> Doru
>
>
> > On Jan 25, 2017, at 11:49 AM, Stephane Ducasse 
> wrote:
> >
> > Another example is a logo turtle.
> > With or without animation.
> >
> > Stef
> >
> > On Wed, Jan 25, 2017 at 11:49 AM, Stephane Ducasse <
> stepharo.s...@gmail.com> wrote:
> > Doru
> >
> > I would like to see the laserGame implemented in Bloc (because it does
> not need widgets).
> > and it will be a real example.
> >
> > Stef
> >
> > On Wed, Jan 25, 2017 at 11:45 AM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
> >
> >
> > 2017-01-25 11:33 GMT+01:00 Tudor Girba :
> > Hi,
> >
> > > On Jan 25, 2017, at 11:19 AM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
> > >
> > > Hi Doru,
> > >
> > > 2017-01-25 10:22 GMT+01:00 Tudor Girba :
> > > ...
> > >
> > > Nevertheless, it would be very cool to have people test this
> assumption on old machines. I think Thierry was saying that he has an old
> machine :). @Thierry?
> > >
> > > I have low-end systems on very recent software (chromebook on Ubuntu
> 16.10, laptop on 16.04), which causes two issues:
> > > - Fairly slow (shows clearly where Pharo is slow or fast)
> > > - Too new (breaks some vms)
> > >
> > > I can be a good performance indicator, yes.
> >
> > Great. It would be really cool if you could give Bloc a try :).
> >
> > Should I just give it a try, or do you have something specific in mind I
> should bench (response time, animation jitter, etc..)?
> >
> > Regards,
> >
> > Thierry
> >
> >
> > Cheers,
> > Doru
> >
> >
> > >
> > > Thierry
> > >
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Problem solving efficiency grows with the abstractness level of problem
> understanding."
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "It's not how it is, it is how we see it."
>
>
>

Re: [Pharo-dev] Immutability support

[Clément Bera]

On Wed, Jan 25, 2017 at 11:55 AM, Denis Kudriashov 
wrote:

>
> 2017-01-25 11:47 GMT+01:00 Norbert Hartl :
>
>> To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for
>> testing methods. isXXX with an argument feels even more strange. I would
>> rather have #beReadOnly
>
>
> Now there is #beReadOnlyObject and #beWritableObject. Maybe for primitive
> it is better to use #primReadOnlyObject:.
>
> It also raise another question: does these primitives support mirror
> approach? (when it can be called with receiver as first argument?)
>

Yes I made sure the mirror approach works. Even better, there are tests
ensuring that it works. You can see in the class WriteBarrierTest that
objects can become read-only through an instance of TTMirror, look for
example into the users of TTMirror>>#setIsReadOnlyObjectOf: object to:
boolean.

Re: [Pharo-dev] Immutability support

[Clément Bera]

On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl  wrote:

> Does anyone know the state of immutability support in vm and image? The
> latest vm downloadable is compiled with
>
> IMMUTABILITY=1
>
> (Esteban said that). When I open a pharo6 image with this VM and do:
>
> ASUser new
> setIsReadOnlyObject: true;
> name: 'foo'
>
> with
>
> ASUser>>#name: arg1
> name := arg1
>
> I don't get an exception. Is there something missing or am I not
> understanding?
>

Hi Norbert,

Thank you very much for looking read-only objects.

When mutating an instance variable, the VM triggers a call-back that by
default does nothing. In your case, running your code does not raise an
exception but the object should not be modified either. If you want an
exception, you need to change the call-back code, i.e., the method
Object>>#attemptToAssign: value withIndex: index. For example, you could
write:

Object>>#attemptToAssign: value withIndex: index
| process |
self notify: 'object changed !'.
process := Processor activeProcess.
[ process suspendedContext: process suspendedContext sender ] forkAt:
Processor activePriority + 1.
Processor yield.

Then, your code should open a notification window with 'object changed',
and proceeding keeps running the code without mutating the object.

One needs to build a ModificationTracker framework on top of the VM support
I introduced. Multiple things are required, like default behavior in this
call-back and in primitive failure code. I am willing to support and help
anyone willing to build such a framework, but I won't build it myself.

If you have any other questions or if you find bug don't hesitate to ask
further questions

Best,

PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your
system, if this is not the case it means the VM does not support read-only
objects.

Clement






>
> Norbert
>

Re: [Pharo-dev] Immutability support

[Cyril Ferlicot D.]

On 25/01/2017 12:59, Esteban Lorenzano wrote:
> but this is not real immutability, is like a write barrier, that’s why
> those method names were not chosen. 
> 

Then why not #(des)activateWriteBarrier?

> Esteban
> 
> 

-- 
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Guillermo Polito]

Hi Doru,

First, I understand the effort you all made to make this big piece of work.
I have however some questions that probably you can help with:

1) I understand Sparta is a library completely independent from Athens. But
I also understand that they follow the same reasoning and general design (a
general API to deal with 2D vectorial graphics with pluggable backends).
  - What are the differences between sparta and athens then? This is really
unclear to me. Are there differences in the API? in the internal backend
requirements?
  - In case there are many differences, What are the reasons that made you
implement a complete new library and not just extend the existing one
(Athens)?
  - or even, just make a moz2d backend for athens?

2) About moz2d. I understand how the build process you use works. But it
looks a bit fragile. You mention engaging the mozilla people. I think this
is really important,
  - either they could propose an alternative solution to what you're doing
  - or, if you contribute back your patches to mozilla (which I think you
should), this will make your process depend less on custom-made patches
  - besides, creating a link between the two communities is probably worth
it: people in mozilla may consider how their changes impact their users.

Guille

On Wed, Jan 25, 2017 at 12:41 PM, Tudor Girba  wrote:

> Hi,
>
> Thank you for the intensive set of issues you raised during the Bloc
> presentation. I think it is worthwhile addressing them more thoroughly, so
> let me start with the issue that seemed to have caused the most worries:
> Sparta & Moz2D.
>
> Please keep in mind that while I am involved to some extent in Bloc, the
> real credits for the current state go to Glenn and Alex.
>
> Moz2D (https://github.com/mozilla/moz2d, https://wiki.mozilla.org/
> Platform/GFX/Moz2D) offers an advanced backend and using it puts us on
> par with the rendering speed of a web browser, which is a significant added
> value over what we have now.
>
> However, as it was noted, it does come with a cost due to the fact that it
> is not available as standalone with only the features we are interested in.
> The vector graphics part is actually buildable out of the box. However, the
> text support needs to be extracted out of Moz2D, and this is where the
> patching scripts are used. The patches are there only for compilation
> purposes and not for features and they are applied automatically. You can
> see it here:
> https://github.com/syrel/Moz2D
>
> Alex updated recently the Moz2D version and it worked without problems. Of
> course, future changes in Moz2D might imply changes in this script as well,
> and this implies that we will need to maintain that script. And we could
> imagine applying these patches on the trunk of Moz2D to see if they work,
> and we can also imagine engaging with the Moz2D owners to see if we can
> find a middle ground.
>
> Now, let’s put this into perspective. We are currently using Athens and
> the Cairo backend. While Cairo is provided as a standalone library it has
> not seen significant advances since Mozzila shifted its focus towards
> Moz2D. So, sticking with it might not be an ideal strategy either.
>
> Furthermore, just like Athens, Sparta is an abstraction that allows us to
> switch the underlying backend should we need to. Until now we did not find
> a cross-platform backend that is as advanced and complete as Moz2D, but
> there is no reason to think that none other will appear in the future. Skia
> is an alternative but it is only a vector graphic engine without text
> support, so using it would imply to have another library for the text
> support.
>
> Sparta also comes with a reasonable set of tests that is aimed at testing
> the basic Moz2D functionality to make sure that the assumptions on top of
> which Sparta is built are correct.
>
> All in all, I think that the current situation is not ideal, but there is
> already enough engineering in place to actually make it work. And I
> definitely think that the potential it opens is rather significant.
>
> And, if more people look at the scripts, we might find even better and
> cheaper ways to express it.
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "We cannot reach the flow of things unless we let go."
>
>
>
>
>
>

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/60354
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 3b6ae2: 60354

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 3b6ae280bafad0c62a9e3abfb890a8bcc308b9d3
  
https://github.com/pharo-project/pharo-core/commit/3b6ae280bafad0c62a9e3abfb890a8bcc308b9d3
  Author: Jenkins Build Server 
  Date:   2017-01-25 (Wed, 25 Jan 2017)

  Changed paths:
R GT-Debugger.package/extension/Context/instance/outerMostContext.st
R 
GT-SpotterExtensions-Core.package/extension/MCWorkingCopy/instance/allAncestors.st
R 
GT-SpotterExtensions-Core.package/extension/MCWorkingCopy/instance/nextAncestors.st
R 
GT-SpotterExtensions-Core.package/extension/MCWorkingCopy/instance/versionInfo.st
A Kernel.package/Class.class/instance/accessing/definitionForNautilus.st
A 
Kernel.package/Class.class/instance/accessing/definitionForNautilusWithSlots.st
A Kernel.package/Context.class/instance/accessing/outerMostContext.st
A Monticello.package/MCWorkingCopy.class/instance/accessing/allAncestors.st
A Monticello.package/MCWorkingCopy.class/instance/accessing/nextAncestors.st
A Monticello.package/MCWorkingCopy.class/instance/accessing/versionInfo.st
R Nautilus.package/extension/Class/instance/definitionForNautilus.st
R 
Nautilus.package/extension/Class/instance/definitionForNautilusWithSlots.st
R 
Nautilus.package/extension/TClassDescription/instance/definitionForNautilus.st
R 
Nautilus.package/extension/TClassDescription/instance/definitionForNautilusWithSlots.st
R NautilusCommon.package/NautilusUtils.class/class/utilities/isErrorTest_.st
R 
NautilusCommon.package/NautilusUtils.class/class/utilities/isFailedTest_.st
R 
NautilusCommon.package/NautilusUtils.class/class/utilities/isPassedTest_.st
R 
NautilusCommon.package/NautilusUtils.class/class/utilities/isTestMethod_.st
R NautilusCommon.package/extension/CompiledMethod/instance/isErrorTest.st
R NautilusCommon.package/extension/CompiledMethod/instance/isFailedTest.st
R NautilusCommon.package/extension/CompiledMethod/instance/isPassedTest.st
R NautilusCommon.package/extension/CompiledMethod/instance/isTestMethod.st
R 
NautilusCommon.package/extension/RGMethodDefinition/instance/isErrorTest.st
R 
NautilusCommon.package/extension/RGMethodDefinition/instance/isFailedTest.st
R 
NautilusCommon.package/extension/RGMethodDefinition/instance/isPassedTest.st
R 
NautilusCommon.package/extension/RGMethodDefinition/instance/isTestMethod.st
A SUnit-Core.package/extension/CompiledMethod/instance/isErrorTest.st
A SUnit-Core.package/extension/CompiledMethod/instance/isFailedTest.st
A SUnit-Core.package/extension/CompiledMethod/instance/isPassedTest.st
A SUnit-Core.package/extension/CompiledMethod/instance/isTestMethod.st
A SUnit-Core.package/extension/RGMethodDefinition/instance/isErrorTest.st
A SUnit-Core.package/extension/RGMethodDefinition/instance/isFailedTest.st
A SUnit-Core.package/extension/RGMethodDefinition/instance/isPassedTest.st
A SUnit-Core.package/extension/RGMethodDefinition/instance/isTestMethod.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60353.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60354.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60353.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60354.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A 
Traits.package/TClassDescription.class/instance/accessing/definitionForNautilus.st
A 
Traits.package/TClassDescription.class/instance/accessing/definitionForNautilusWithSlots.st

  Log Message:
  ---
  60354
19596 move #outerMostContext to the KernelPackage
https://pharo.fogbugz.com/f/cases/19596

19597 move #definitionForNautilus  to the Kernel
https://pharo.fogbugz.com/f/cases/19597

19595 Protocol *GT-SpotterExtensions-Core-private in MCWorkingCopy should be 
moved to accessing
https://pharo.fogbugz.com/f/cases/19595

19594 isTestMethods  should be SUnit extensions, not part of Nautilus
https://pharo.fogbugz.com/f/cases/19594

http://files.pharo.org/image/60/60354.zip

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Denis Kudriashov]

2017-01-25 11:45 GMT+01:00 Thierry Goubier :

> > Nevertheless, it would be very cool to have people test this assumption
>> on old machines. I think Thierry was saying that he has an old machine :).
>> @Thierry?
>> >
>> > I have low-end systems on very recent software (chromebook on Ubuntu
>> 16.10, laptop on 16.04), which causes two issues:
>> > - Fairly slow (shows clearly where Pharo is slow or fast)
>> > - Too new (breaks some vms)
>> >
>> > I can be a good performance indicator, yes.
>>
>> Great. It would be really cool if you could give Bloc a try :).
>>
>
> Should I just give it a try, or do you have something specific in mind I
> should bench (response time, animation jitter, etc..)?
>

Would be nice just to know your feedback
about BlInfiniteLinearLayoutExamples on old machines. They provide very
smooth scrolling on big lists. So it should be just visible: fast it or
slow.

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Stephane Ducasse]

I think that the team should do it and take it as an exercise to document
the system.

I would also work on a simple application for kids for example with forms
(rectangle, star, ) that the kids can duplicate and changed.
It could also be a simple application to get satisfactory from customers
  did you like 

Yes  Yes a bitNo a bit  No

With a couple of example, it will show to people that
 - they can do something
 - copy the model

It would be a nice example to show how this is done in bloc.
All the previous examples are based on bloc only (no brick element needed).

I removed graphics from future book to free my mind and be less raging.
If someone wants to try I can explain the topics.

Stef


On Wed, Jan 25, 2017 at 12:45 PM, Tudor Girba  wrote:

> Nice ideas!
>
> What would be cool if someone else would like to try to implement any of
> these. Anyone interested?
>
> Cheers,
> Doru
>
>
> > On Jan 25, 2017, at 11:49 AM, Stephane Ducasse 
> wrote:
> >
> > Another example is a logo turtle.
> > With or without animation.
> >
> > Stef
> >
> > On Wed, Jan 25, 2017 at 11:49 AM, Stephane Ducasse <
> stepharo.s...@gmail.com> wrote:
> > Doru
> >
> > I would like to see the laserGame implemented in Bloc (because it does
> not need widgets).
> > and it will be a real example.
> >
> > Stef
> >
> > On Wed, Jan 25, 2017 at 11:45 AM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
> >
> >
> > 2017-01-25 11:33 GMT+01:00 Tudor Girba :
> > Hi,
> >
> > > On Jan 25, 2017, at 11:19 AM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
> > >
> > > Hi Doru,
> > >
> > > 2017-01-25 10:22 GMT+01:00 Tudor Girba :
> > > ...
> > >
> > > Nevertheless, it would be very cool to have people test this
> assumption on old machines. I think Thierry was saying that he has an old
> machine :). @Thierry?
> > >
> > > I have low-end systems on very recent software (chromebook on Ubuntu
> 16.10, laptop on 16.04), which causes two issues:
> > > - Fairly slow (shows clearly where Pharo is slow or fast)
> > > - Too new (breaks some vms)
> > >
> > > I can be a good performance indicator, yes.
> >
> > Great. It would be really cool if you could give Bloc a try :).
> >
> > Should I just give it a try, or do you have something specific in mind I
> should bench (response time, animation jitter, etc..)?
> >
> > Regards,
> >
> > Thierry
> >
> >
> > Cheers,
> > Doru
> >
> >
> > >
> > > Thierry
> > >
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Problem solving efficiency grows with the abstractness level of problem
> understanding."
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "It's not how it is, it is how we see it."
>
>
>

Re: [Pharo-dev] Immutability support

[Esteban Lorenzano]

but this is not real immutability, is like a write barrier, that’s why those 
method names were not chosen. 

Esteban

> On 25 Jan 2017, at 12:37, p...@highoctane.be wrote:
> 
> So, beImmutable and beMutable seem pretty usable and not collision causing 
> IMHO.
> 
> Phil
> 
> On Wed, Jan 25, 2017 at 12:19 PM, Norbert Hartl  > wrote:
> 
>> Am 25.01.2017 um 12:16 schrieb Esteban Lorenzano > >:
>> 
>> 
>>> On 25 Jan 2017, at 12:04, Denis Kudriashov >> > wrote:
>>> 
>>> 
>>> 2017-01-25 12:03 GMT+01:00 Denis Kudriashov >> >:
>>> I think problem that these names could be already in use by frameworks. I 
>>> am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte 
>>> uses it 
>>> 
>>> And probably Glorp
>> 
>> 
>> yes, but #setIsReadOnlyObject: deserves a place in the podium of ugly names 
>> :)
>> 
> Absolutely. And we are a really caring community because we care so much 
> about a method name of a feature that does not work :)
> 
> Norbert
>> I thought the names were going to be like beWritable/beNotWritable/isWritable
>> which are not a lot better, but well… 
>> 
>> Esteban
> 
> 

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Tudor Girba]

Nice ideas!

What would be cool if someone else would like to try to implement any of these. 
Anyone interested?

Cheers,
Doru


> On Jan 25, 2017, at 11:49 AM, Stephane Ducasse  
> wrote:
> 
> Another example is a logo turtle. 
> With or without animation.
> 
> Stef
> 
> On Wed, Jan 25, 2017 at 11:49 AM, Stephane Ducasse  
> wrote:
> Doru 
> 
> I would like to see the laserGame implemented in Bloc (because it does not 
> need widgets). 
> and it will be a real example. 
> 
> Stef
> 
> On Wed, Jan 25, 2017 at 11:45 AM, Thierry Goubier  
> wrote:
> 
> 
> 2017-01-25 11:33 GMT+01:00 Tudor Girba :
> Hi,
> 
> > On Jan 25, 2017, at 11:19 AM, Thierry Goubier  
> > wrote:
> >
> > Hi Doru,
> >
> > 2017-01-25 10:22 GMT+01:00 Tudor Girba :
> > ...
> >
> > Nevertheless, it would be very cool to have people test this assumption on 
> > old machines. I think Thierry was saying that he has an old machine :). 
> > @Thierry?
> >
> > I have low-end systems on very recent software (chromebook on Ubuntu 16.10, 
> > laptop on 16.04), which causes two issues:
> > - Fairly slow (shows clearly where Pharo is slow or fast)
> > - Too new (breaks some vms)
> >
> > I can be a good performance indicator, yes.
> 
> Great. It would be really cool if you could give Bloc a try :).
> 
> Should I just give it a try, or do you have something specific in mind I 
> should bench (response time, animation jitter, etc..)?
> 
> Regards,
> 
> Thierry
>  
> 
> Cheers,
> Doru
> 
> 
> >
> > Thierry
> >
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Problem solving efficiency grows with the abstractness level of problem 
> understanding."
> 
> 
> 
> 
> 
> 
> 
> 

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

"It's not how it is, it is how we see it."

[Pharo-dev] [bloc] addressing the moz2d issue

[Tudor Girba]

Hi,

Thank you for the intensive set of issues you raised during the Bloc 
presentation. I think it is worthwhile addressing them more thoroughly, so let 
me start with the issue that seemed to have caused the most worries: Sparta & 
Moz2D.

Please keep in mind that while I am involved to some extent in Bloc, the real 
credits for the current state go to Glenn and Alex.

Moz2D (https://github.com/mozilla/moz2d, 
https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend and 
using it puts us on par with the rendering speed of a web browser, which is a 
significant added value over what we have now.

However, as it was noted, it does come with a cost due to the fact that it is 
not available as standalone with only the features we are interested in. The 
vector graphics part is actually buildable out of the box. However, the text 
support needs to be extracted out of Moz2D, and this is where the patching 
scripts are used. The patches are there only for compilation purposes and not 
for features and they are applied automatically. You can see it here:
https://github.com/syrel/Moz2D

Alex updated recently the Moz2D version and it worked without problems. Of 
course, future changes in Moz2D might imply changes in this script as well, and 
this implies that we will need to maintain that script. And we could imagine 
applying these patches on the trunk of Moz2D to see if they work, and we can 
also imagine engaging with the Moz2D owners to see if we can find a middle 
ground.

Now, let’s put this into perspective. We are currently using Athens and the 
Cairo backend. While Cairo is provided as a standalone library it has not seen 
significant advances since Mozzila shifted its focus towards Moz2D. So, 
sticking with it might not be an ideal strategy either.

Furthermore, just like Athens, Sparta is an abstraction that allows us to 
switch the underlying backend should we need to. Until now we did not find a 
cross-platform backend that is as advanced and complete as Moz2D, but there is 
no reason to think that none other will appear in the future. Skia is an 
alternative but it is only a vector graphic engine without text support, so 
using it would imply to have another library for the text support.

Sparta also comes with a reasonable set of tests that is aimed at testing the 
basic Moz2D functionality to make sure that the assumptions on top of which 
Sparta is built are correct.

All in all, I think that the current situation is not ideal, but there is 
already enough engineering in place to actually make it work. And I definitely 
think that the potential it opens is rather significant.

And, if more people look at the scripts, we might find even better and cheaper 
ways to express it.

Cheers,
Doru


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

"We cannot reach the flow of things unless we let go."

Re: [Pharo-dev] Immutability support

[p...@highoctane.be]

So, beImmutable and beMutable seem pretty usable and not collision causing
IMHO.

Phil

On Wed, Jan 25, 2017 at 12:19 PM, Norbert Hartl  wrote:

>
> Am 25.01.2017 um 12:16 schrieb Esteban Lorenzano :
>
>
> On 25 Jan 2017, at 12:04, Denis Kudriashov  wrote:
>
>
> 2017-01-25 12:03 GMT+01:00 Denis Kudriashov :
>
>> I think problem that these names could be already in use by frameworks. I
>> am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte
>> uses it
>
>
> And probably Glorp
>
>
> yes, but #setIsReadOnlyObject: deserves a place in the podium of ugly
> names :)
>
> Absolutely. And we are a really caring community because we care so much
> about a method name of a feature that does not work :)
>
> Norbert
>
> I thought the names were going to be like beWritable/beNotWritable/
> isWritable
> which are not a lot better, but well…
>
> Esteban
>
>
>

Re: [Pharo-dev] Immutability support

[p...@highoctane.be]

Yes, exactly how it felt. Maybe #setImmutable would be more intention
revealing.

Phil

On Wed, Jan 25, 2017 at 11:47 AM, Norbert Hartl  wrote:

>
> Am 25.01.2017 um 11:40 schrieb Denis Kudriashov :
>
>
> 2017-01-25 11:35 GMT+01:00 Norbert Hartl :
>
>> ASUser new
>> setIsReadOnlyObject: true
>>
>
> And why so ugly name? Why not #isReadOnlyObject:?
>
>
> To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for
> testing methods. isXXX with an argument feels even more strange. I would
> rather have #beReadOnly
>
> Norbert
>

Re: [Pharo-dev] Immutability support

[Norbert Hartl]

> Am 25.01.2017 um 12:16 schrieb Esteban Lorenzano :
> 
> 
>> On 25 Jan 2017, at 12:04, Denis Kudriashov > > wrote:
>> 
>> 
>> 2017-01-25 12:03 GMT+01:00 Denis Kudriashov > >:
>> I think problem that these names could be already in use by frameworks. I am 
>> sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte 
>> uses it 
>> 
>> And probably Glorp
> 
> 
> yes, but #setIsReadOnlyObject: deserves a place in the podium of ugly names :)
> 
Absolutely. And we are a really caring community because we care so much about 
a method name of a feature that does not work :)

Norbert
> I thought the names were going to be like beWritable/beNotWritable/isWritable
> which are not a lot better, but well… 
> 
> Esteban

Re: [Pharo-dev] Immutability support

[Esteban Lorenzano]

> On 25 Jan 2017, at 12:04, Denis Kudriashov  wrote:
> 
> 
> 2017-01-25 12:03 GMT+01:00 Denis Kudriashov  >:
> I think problem that these names could be already in use by frameworks. I am 
> sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte uses 
> it 
> 
> And probably Glorp


yes, but #setIsReadOnlyObject: deserves a place in the podium of ugly names :)

I thought the names were going to be like beWritable/beNotWritable/isWritable
which are not a lot better, but well… 

Esteban

Re: [Pharo-dev] Immutability support

[Denis Kudriashov]

2017-01-25 12:03 GMT+01:00 Denis Kudriashov :

> I think problem that these names could be already in use by frameworks. I
> am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte
> uses it


And probably Glorp

Re: [Pharo-dev] Immutability support

[Denis Kudriashov]

2017-01-25 11:59 GMT+01:00 Sven Van Caekenberghe :

> why the object suffix, everything is an object, right ?


I think problem that these names could be already in use by frameworks. I
am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte
uses it

Re: [Pharo-dev] Immutability support

[Sven Van Caekenberghe]

> On 25 Jan 2017, at 11:55, Denis Kudriashov  wrote:
> 
> 
> 2017-01-25 11:47 GMT+01:00 Norbert Hartl :
> To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for 
> testing methods. isXXX with an argument feels even more strange. I would 
> rather have #beReadOnly 
> 
> Now there is #beReadOnlyObject and #beWritableObject. Maybe for primitive it 
> is better to use #primReadOnlyObject:.

why the object suffix, everything is an object, right ?

the simplest wording is often the best, unless there is a good reason for 
something else.

> It also raise another question: does these primitives support mirror 
> approach? (when it can be called with receiver as first argument?)

Re: [Pharo-dev] Immutability support

[Denis Kudriashov]

2017-01-25 11:47 GMT+01:00 Norbert Hartl :

> To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for
> testing methods. isXXX with an argument feels even more strange. I would
> rather have #beReadOnly


Now there is #beReadOnlyObject and #beWritableObject. Maybe for primitive
it is better to use #primReadOnlyObject:.

It also raise another question: does these primitives support mirror
approach? (when it can be called with receiver as first argument?)

Re: [Pharo-dev] Immutability support

[Sven Van Caekenberghe]

> On 25 Jan 2017, at 11:47, Norbert Hartl  wrote:
> 
> 
>> Am 25.01.2017 um 11:40 schrieb Denis Kudriashov :
>> 
>> 
>> 2017-01-25 11:35 GMT+01:00 Norbert Hartl :
>> ASUser new
>> setIsReadOnlyObject: true
>> 
>> And why so ugly name? Why not #isReadOnlyObject:?
> 
> To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for 
> testing methods. isXXX with an argument feels even more strange. I would 
> rather have #beReadOnly 

Yes, #beReadOnly 

> Norbert

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Stephane Ducasse]

Another example is a logo turtle.
With or without animation.

Stef

On Wed, Jan 25, 2017 at 11:49 AM, Stephane Ducasse 
wrote:

> Doru
>
> I would like to see the laserGame implemented in Bloc (because it does not
> need widgets).
> and it will be a real example.
>
> Stef
>
> On Wed, Jan 25, 2017 at 11:45 AM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>>
>>
>> 2017-01-25 11:33 GMT+01:00 Tudor Girba :
>>
>>> Hi,
>>>
>>> > On Jan 25, 2017, at 11:19 AM, Thierry Goubier <
>>> thierry.goub...@gmail.com> wrote:
>>> >
>>> > Hi Doru,
>>> >
>>> > 2017-01-25 10:22 GMT+01:00 Tudor Girba :
>>> > ...
>>> >
>>> > Nevertheless, it would be very cool to have people test this
>>> assumption on old machines. I think Thierry was saying that he has an old
>>> machine :). @Thierry?
>>> >
>>> > I have low-end systems on very recent software (chromebook on Ubuntu
>>> 16.10, laptop on 16.04), which causes two issues:
>>> > - Fairly slow (shows clearly where Pharo is slow or fast)
>>> > - Too new (breaks some vms)
>>> >
>>> > I can be a good performance indicator, yes.
>>>
>>> Great. It would be really cool if you could give Bloc a try :).
>>>
>>
>> Should I just give it a try, or do you have something specific in mind I
>> should bench (response time, animation jitter, etc..)?
>>
>> Regards,
>>
>> Thierry
>>
>>
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> >
>>> > Thierry
>>> >
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "Problem solving efficiency grows with the abstractness level of problem
>>> understanding."
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Stephane Ducasse]

Doru

I would like to see the laserGame implemented in Bloc (because it does not
need widgets).
and it will be a real example.

Stef

On Wed, Jan 25, 2017 at 11:45 AM, Thierry Goubier  wrote:

>
>
> 2017-01-25 11:33 GMT+01:00 Tudor Girba :
>
>> Hi,
>>
>> > On Jan 25, 2017, at 11:19 AM, Thierry Goubier <
>> thierry.goub...@gmail.com> wrote:
>> >
>> > Hi Doru,
>> >
>> > 2017-01-25 10:22 GMT+01:00 Tudor Girba :
>> > ...
>> >
>> > Nevertheless, it would be very cool to have people test this assumption
>> on old machines. I think Thierry was saying that he has an old machine :).
>> @Thierry?
>> >
>> > I have low-end systems on very recent software (chromebook on Ubuntu
>> 16.10, laptop on 16.04), which causes two issues:
>> > - Fairly slow (shows clearly where Pharo is slow or fast)
>> > - Too new (breaks some vms)
>> >
>> > I can be a good performance indicator, yes.
>>
>> Great. It would be really cool if you could give Bloc a try :).
>>
>
> Should I just give it a try, or do you have something specific in mind I
> should bench (response time, animation jitter, etc..)?
>
> Regards,
>
> Thierry
>
>
>>
>> Cheers,
>> Doru
>>
>>
>> >
>> > Thierry
>> >
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Problem solving efficiency grows with the abstractness level of problem
>> understanding."
>>
>>
>>
>>
>>
>>
>

Re: [Pharo-dev] Immutability support

[Norbert Hartl]

> Am 25.01.2017 um 11:40 schrieb Denis Kudriashov :
> 
> 
> 2017-01-25 11:35 GMT+01:00 Norbert Hartl  >:
> ASUser new
> setIsReadOnlyObject: true
> 
> And why so ugly name? Why not #isReadOnlyObject:?

To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for 
testing methods. isXXX with an argument feels even more strange. I would rather 
have #beReadOnly 

Norbert

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Thierry Goubier]

2017-01-25 11:33 GMT+01:00 Tudor Girba :

> Hi,
>
> > On Jan 25, 2017, at 11:19 AM, Thierry Goubier 
> wrote:
> >
> > Hi Doru,
> >
> > 2017-01-25 10:22 GMT+01:00 Tudor Girba :
> > ...
> >
> > Nevertheless, it would be very cool to have people test this assumption
> on old machines. I think Thierry was saying that he has an old machine :).
> @Thierry?
> >
> > I have low-end systems on very recent software (chromebook on Ubuntu
> 16.10, laptop on 16.04), which causes two issues:
> > - Fairly slow (shows clearly where Pharo is slow or fast)
> > - Too new (breaks some vms)
> >
> > I can be a good performance indicator, yes.
>
> Great. It would be really cool if you could give Bloc a try :).
>

Should I just give it a try, or do you have something specific in mind I
should bench (response time, animation jitter, etc..)?

Regards,

Thierry


>
> Cheers,
> Doru
>
>
> >
> > Thierry
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Problem solving efficiency grows with the abstractness level of problem
> understanding."
>
>
>
>
>
>

Re: [Pharo-dev] Immutability support

[Denis Kudriashov]

2017-01-25 11:35 GMT+01:00 Norbert Hartl :

> ASUser new
> setIsReadOnlyObject: true
>

And why so ugly name? Why not #isReadOnlyObject:?

[Pharo-dev] Immutability support

[Norbert Hartl]

Does anyone know the state of immutability support in vm and image? The latest 
vm downloadable is compiled with

IMMUTABILITY=1

(Esteban said that). When I open a pharo6 image with this VM and do:

ASUser new 
setIsReadOnlyObject: true;
name: 'foo'

with

ASUser>>#name: arg1
name := arg1

I don't get an exception. Is there something missing or am I not understanding?

Norbert

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Tudor Girba]

Hi,

> On Jan 25, 2017, at 11:19 AM, Thierry Goubier  
> wrote:
> 
> Hi Doru,
> 
> 2017-01-25 10:22 GMT+01:00 Tudor Girba :
> ...
> 
> Nevertheless, it would be very cool to have people test this assumption on 
> old machines. I think Thierry was saying that he has an old machine :). 
> @Thierry?
> 
> I have low-end systems on very recent software (chromebook on Ubuntu 16.10, 
> laptop on 16.04), which causes two issues:
> - Fairly slow (shows clearly where Pharo is slow or fast)
> - Too new (breaks some vms)
> 
> I can be a good performance indicator, yes.

Great. It would be really cool if you could give Bloc a try :).

Cheers,
Doru


> 
> Thierry
> 

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

"Problem solving efficiency grows with the abstractness level of problem 
understanding."

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Thierry Goubier]

Hi Doru,

2017-01-25 10:22 GMT+01:00 Tudor Girba :

> ...
>
> Nevertheless, it would be very cool to have people test this assumption on
> old machines. I think Thierry was saying that he has an old machine :).
> @Thierry?
>

I have low-end systems on very recent software (chromebook on Ubuntu 16.10,
laptop on 16.04), which causes two issues:
- Fairly slow (shows clearly where Pharo is slow or fast)
- Too new (breaks some vms)

I can be a good performance indicator, yes.

Thierry

Re: [Pharo-dev] CALL for GSoC project proposals

[Stephane Ducasse]

But I understand the process.
So I did a pass

On Wed, Jan 25, 2017 at 11:05 AM, Stephane Ducasse 
wrote:

> Hi yuriy
>
> you could have done it a bit less brutal.
>
> Stef
>
> On Wed, Jan 25, 2017 at 10:52 AM, Yuriy Tymchuk 
> wrote:
>
>> Dear all, this year we plan to apply again as a mentoring organization
>> for Google Summer of Code. However, we are going to follow a different
>> strategy regarding project proposals. Instead of having a swarm of small
>> ideas we want to end up with around ten well-described projects.
>>
>> This is why I cleaned the topics file, and I ask all interested people to
>> propose the best one of your topics here:
>> https://github.com/pharo-project/pharo-project-proposals/
>> blob/master/Topics.st
>>
>> There is a copy of the old file in case you want to remind what you
>> proposed last year:
>> https://github.com/pharo-project/pharo-project-proposals/
>> blob/master/Topics-old.st
>>
>> As we are going for well-described projects with links to related
>> resources, pictures, prototype videos, etc. you can also add a standalone
>> file with a project description in some rich format to this dir:
>> https://github.com/pharo-project/pharo-project-proposals/
>> tree/master/topics
>>
>> Again, we want around ten diverse and well-described projects with a
>> precise definition of the domain and the problem, possible solutions, and
>> expected benefits. So it also will be nice to have diverse projects, so if
>> you are collaborating with someone, please try to propose a joined project
>> that will have backup members (also crucial for the application) and do not
>> create multiple similar but less powerful projects.
>>
>> We heavily rely on the input of the community.
>> Let’s make Pharo great again ;P
>> Uko on behalf of the Pharo GSoC application team.
>>
>
>

Re: [Pharo-dev] CALL for GSoC project proposals

[Stephane Ducasse]

Hi yuriy

you could have done it a bit less brutal.

Stef

On Wed, Jan 25, 2017 at 10:52 AM, Yuriy Tymchuk 
wrote:

> Dear all, this year we plan to apply again as a mentoring organization for
> Google Summer of Code. However, we are going to follow a different strategy
> regarding project proposals. Instead of having a swarm of small ideas we
> want to end up with around ten well-described projects.
>
> This is why I cleaned the topics file, and I ask all interested people to
> propose the best one of your topics here:
> https://github.com/pharo-project/pharo-project-
> proposals/blob/master/Topics.st
>
> There is a copy of the old file in case you want to remind what you
> proposed last year:
> https://github.com/pharo-project/pharo-project-
> proposals/blob/master/Topics-old.st
>
> As we are going for well-described projects with links to related
> resources, pictures, prototype videos, etc. you can also add a standalone
> file with a project description in some rich format to this dir:
> https://github.com/pharo-project/pharo-project-
> proposals/tree/master/topics
>
> Again, we want around ten diverse and well-described projects with a
> precise definition of the domain and the problem, possible solutions, and
> expected benefits. So it also will be nice to have diverse projects, so if
> you are collaborating with someone, please try to propose a joined project
> that will have backup members (also crucial for the application) and do not
> create multiple similar but less powerful projects.
>
> We heavily rely on the input of the community.
> Let’s make Pharo great again ;P
> Uko on behalf of the Pharo GSoC application team.
>

[Pharo-dev] CALL for GSoC project proposals

[Yuriy Tymchuk]

Dear all, this year we plan to apply again as a mentoring organization for 
Google Summer of Code. However, we are going to follow a different strategy 
regarding project proposals. Instead of having a swarm of small ideas we want 
to end up with around ten well-described projects.

This is why I cleaned the topics file, and I ask all interested people to 
propose the best one of your topics here:
https://github.com/pharo-project/pharo-project-proposals/blob/master/Topics.st 

 

There is a copy of the old file in case you want to remind what you proposed 
last year:
https://github.com/pharo-project/pharo-project-proposals/blob/master/Topics-old.st
 

 

As we are going for well-described projects with links to related resources, 
pictures, prototype videos, etc. you can also add a standalone file with a 
project description in some rich format to this dir:
https://github.com/pharo-project/pharo-project-proposals/tree/master/topics 
 

Again, we want around ten diverse and well-described projects with a precise 
definition of the domain and the problem, possible solutions, and expected 
benefits. So it also will be nice to have diverse projects, so if you are 
collaborating with someone, please try to propose a joined project that will 
have backup members (also crucial for the application) and do not create 
multiple similar but less powerful projects.

We heavily rely on the input of the community.
Let’s make Pharo great again ;P
Uko on behalf of the Pharo GSoC application team.

Re: [Pharo-dev] Google summer of code

[Serge Stinckwich]

On Wed, Jan 25, 2017 at 7:38 AM, Stephan Eggermont  wrote:
> On 24/01/17 10:11, Guillermo Polito wrote:
>>
>> Besides, I'm interested in knowing the official reasons for why we were
>> rejected last years :P.
>
>
> That's the always the same: we get many more applications than we can
> sponsor, and we have to make a choice.

+1
yes we receive this answer last year.

One option to enhance the situation this year is maybe to have less
projects proposed by Pharo community (10-12 ?) but with more detailed
explanations. Apparently this is something important to be accepted as
an organisation by Google.

There is a small team with Jigyasa, Yuriy, Alexandre who is working on that.
If you have ideas and want to help, you can join #gsoc-planning on Slack.

Thank you.
Regards,

-- 
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Tudor Girba]

Hi Stef,

Thanks for these questions. See some replies inline and we will also create 
threads with the larger topics to get people more engaged.


> On Jan 25, 2017, at 9:32 AM, Stephane Ducasse  wrote:
> 
> Hi bloc/brick guys
> 
> I was a great talk. I had to run because I forgot my appointment to the 
> doctor. 
> Now some points
> 
> - first a meta point: we should check how we can get more people following 
> the talks.
> 
> Now related to bloc/bricks
> 
> - we should pay really attention to the maintenance and deployment of the 
> external libraries (I could never install GTK on my mac using darwin. 
> Sure you can experiment but I think that bloc without a widget layer is a 
> nice stuff but not usable. 

Definitely. The goal here is to get something that works without problems. GTK 
is an experiment only at this point to see how flexible we really are on the 
backend side. Moz2D is another problem that I will detail in a separate email.

About Brick, see the end of the mail.


> - what is the oldest machine it is working?

This is an interesting question. One of the cool things about Moz2D is that it 
is actually another layer on top of concrete rendering backends while still 
being fast. The concrete rendering is flexible and decided based on the 
configuration of the machine depending on things like OS or hardware 
acceleration availability. Given that this engine is at the core of Firefox and 
they also have to address the problem of various hardware we are in a 
reasonable position.

Nevertheless, it would be very cool to have people test this assumption on old 
machines. I think Thierry was saying that he has an old machine :). @Thierry?


> What is the entrance barrier in terms of cost?

Do you have another issue in mind beside the one above?


> - So since you are basically two where is the roadmap? What is your 
> visibility in terms of % of your time on the project because at the end of 
> the day you should earn money. 

Let’s postpone this discussion for a bit longer.


> - The question of the patterns used to build the widgets is important. The 
> question of how to validate it for real is also important. 

Yes, definitely. The effort did not get at that point.

Bloc went through an amazing journey and it got refined multiple times by 
exercising it with rather crazy ideas such as effects, composition, layouts and 
now we think it reached a point in which the main structure is stable. I am 
sure we can still find smaller points to refine but the overall structure looks 
quite robust now.

So, the next point is definitely Brick.


> - Do you plan commenting/cleaning categorisation for real? I still do not get 
> how you can design something without writing the assumptions of the design 
> into class comments. 
> Then with such systematic lack of comments you cannot benefit from the "no 
> broken window effect". Now this is more if I see a comments it is either old, 
> bad or useless "I'm an abstract class". At least it was like that the last 
> time I checked. And they are certainly many many concerns that are hidden 
> everywhere and are undocumented. 

Yes. This is a focus point. Right now, there are assertions in the code for 
pre-conditions, there are tests and there are examples. The documentation is 
less advanced, but it is a focus point. For example, the new editor work is 
commented quite thoroughly and these comments will start to appear through the 
rest of the infrastructure. But, it would be very cool to have more people to 
start asking questions as this will help us drive documentation.


> - How do you want to get people involved? To me this is totally unclear. 
> Especially with the previous point in mind. I mean for real not just "oh yes 
> we need users”

I think it is hard to get people involved without providing some benefit. As 
you noted above, without having working widgets, there is almost no value. That 
is why it is critical to get to Brick, and once we will get there the feedback 
will come.

It was really hard to get to the state of current Bloc. Glenn and Alex did a 
really amazing job especially if you look at how many times they iterated over 
the details and put up with that uncertainty. But, the results are quite 
incredible and now we can shift our focus to Brick.

Now, Brick worked in several incarnations, the last ones being done by Glenn. 
And the code is there, but the blocker was text support. That is why we had all 
this investment in Moz2D (the only reason why we have the patching is because 
of the text support) and in the editor. It was not clear at all that the idea 
of representing a text as a plain layout of elements will work, but since a 
week or so we know that it does and now we can commit to it. So, the next focus 
is to get the editor working and then we will iterate on that.

Of course, the patterns of how we compose widgets to models is important, too 
and this will be on focus. MVC/MVP are options, 

Re: [Pharo-dev] Google summer of code

[Thierry Goubier]

Hi guys,

what I noted from the last attempts is that the Pharo proposal goes like
that:

- here is a nice list of project ideas

- newcomers just have to use our current set of tools for interacting and
producing code (that is
 slack / mailing list / smalltalkhub / github / fogbugz / medium / etc...)

Maybe preparing something (or planning to) a bit centralized and dedicated
to GSoC for the last point could be nice, just to explain that we're paying
attention to GSoC participants.

Regards,

Thierry

2017-01-25 9:21 GMT+01:00 Stephane Ducasse :

> Yuriy I cleaned many of the proposal
> could you do a pass on yours and keep max 4-5 of them?
>
> On Mon, Jan 23, 2017 at 5:15 PM, Yuriy Tymchuk 
> wrote:
>
>> I can also update my projects and help with the application if needed (I
>> was a part of the application team for the last two years I think)
>>
>> Uko
>>
>> On 22 Jan 2017, at 16:33, Jigyasa Grover 
>> wrote:
>>
>> Also, a good application is equally important as the list of clearly
>> defined projects.
>>
>> - J
>>
>> On Sun, Jan 22, 2017 at 4:30 PM, Serge Stinckwich <
>> serge.stinckw...@gmail.com> wrote:
>>
>>> The list of previous projects is here:
>>> https://github.com/pharo-project/pharo-project-proposals
>>>
>>> On Sat, Jan 21, 2017 at 10:06 AM, Jigyasa Grover
>>>  wrote:
>>> > Dear Prof Serge
>>> >
>>> > Thanks for the introduction.
>>> >
>>> > Dear Alexandre
>>> > I have been a past Google Summer of Code student and also mentor
>>> budding
>>> > developers in Google Code-In.
>>> > This time, I was hoping to plug-in the loopholes which might have been
>>> > present in last year's organisation application.
>>> > Kindly let me know how can we collaborate further on this.
>>> > Looking forward to your response.
>>> > Thanks and Regards
>>> > Jigyasa
>>> >
>>> >
>>> > On Sat, Jan 21, 2017 at 9:06 AM,  wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Envoyé de mon iPhone
>>> >> Le 20 janv. 2017 à 22:21, Yuriy Tymchuk  a
>>> écrit :
>>> >>
>>> >> What do we do?
>>> >>
>>> >>
>>> >>
>>> >> We have to apply ! ;-)
>>> >>
>>> >> We talk with Jigyasa Grover who is doing an internship in my lab at
>>> the
>>> >> moment and she is willing to help. Jigyasa was a student in a former
>>> Google
>>> >> Summer of code and is involved in several open-source initiative like
>>> Women
>>> >> who Code and FOSSASIA. She is a mentor of GoogleCodeIn.
>>> >>
>>> >> You can find a small presentation during last FOSSASIA : "
>>> >>
>>> >> My journey in FOSS with Pharo & FOSSASIA by Jigyasa Grover - FOSSASIA
>>> >> 2016"
>>> >>
>>> >> https://m.youtube.com/watch?v=uLIzylxvIz4
>>> >>
>>> >> She has done a streaming video this morning also:
>>> http://goo.gl/UyclKP
>>> >> http://youtube.com/watch?v=2iRG_jpOL54
>>> >>
>>> >> Anyone to help her setup a small team for Pharo proposal to Google
>>> Summer
>>> >> of Code this year ?
>>> >>
>>> >>
>>> >> On 20 Jan 2017, at 20:38, Alexandre Bergel 
>>> >> wrote:
>>> >>
>>> >> Hi everyone-
>>> >>
>>> >> Google Summer of Code 2017 has officially begun! Organization
>>> applications
>>> >> open today, Thursday January 19 and are open through Thursday,
>>> February 9th.
>>> >> Please see our program site, official timeline and FAQ for more
>>> details.
>>> >>
>>> >> What makes a good organization application? Take a look at our
>>> manuals for
>>> >> tips and best practices.
>>> >>
>>> >> We look forward to seeing each of your applications and kicking off
>>> >> another great year of GSoC. If you have any questions, don’t hesitate
>>> to
>>> >> reach out to gsoc-supp...@google.com. We’re here to help!
>>> >>
>>> >> Google Open Source Programs Office
>>> >> --
>>> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> >> Alexandre Bergel  http://www.bergel.eu
>>> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Serge Stinckwich
>>> UCBN & UMI UMMISCO 209 (IRD/UPMC)
>>> Every DSL ends up being Smalltalk
>>> http://www.doesnotunderstand.org/
>>>
>>>
>>
>>
>

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Stephane Ducasse]

Hi bloc/brick guys

I was a great talk. I had to run because I forgot my appointment to the
doctor.
Now some points

- first a meta point: we should check how we can get more people following
the talks.

Now related to bloc/bricks

- we should pay really attention to the maintenance and deployment of the
external libraries (I could never install GTK on my mac using
darwin. Sure you can experiment but I think that bloc without a widget
layer is a nice stuff but not usable.

- what is the oldest machine it is working? What is the entrance barrier in
terms of cost?

- So since you are basically two where is the roadmap? What is your
visibility in terms of % of your time on the project because at the end of
the day you should earn money.

- The question of the patterns used to build the widgets is important. The
question of how to validate it for real is also important.

- Do you plan commenting/cleaning categorisation for real? I still do not
get how you can design something without writing the assumptions of the
design into class comments.
Then with such systematic lack of comments you cannot benefit from the "no
broken window effect". Now this is more if I see a comments it is either
old, bad or useless "I'm an abstract class". At least it was like that the
last time I checked. And they are certainly many many concerns that are
hidden everywhere and are undocumented.

- How do you want to get people involved? To me this is totally unclear.
Especially with the previous point in mind. I mean for real not just "oh
yes we need users"

Stef




On Tue, Jan 24, 2017 at 5:00 PM, Esteban Lorenzano 
wrote:

> this is going to start now :)
>
> On 24 Jan 2017, at 14:03, Esteban Lorenzano  wrote:
>
> Hello,
>
> We will handle the techtalk as latest one: One video streaming and
> questions/discussion over our discord channel.
> So here are the links:
>
> stream: https://www.youtube.com/watch?v=fvpfr6OJ0mM
> discord: https://discord.gg/88sbn83
>
> See you there in 3hs!
> Esteban
>
>
>

Re: [Pharo-dev] Google summer of code

[Stephane Ducasse]

Yuriy I cleaned many of the proposal
could you do a pass on yours and keep max 4-5 of them?

On Mon, Jan 23, 2017 at 5:15 PM, Yuriy Tymchuk  wrote:

> I can also update my projects and help with the application if needed (I
> was a part of the application team for the last two years I think)
>
> Uko
>
> On 22 Jan 2017, at 16:33, Jigyasa Grover 
> wrote:
>
> Also, a good application is equally important as the list of clearly
> defined projects.
>
> - J
>
> On Sun, Jan 22, 2017 at 4:30 PM, Serge Stinckwich <
> serge.stinckw...@gmail.com> wrote:
>
>> The list of previous projects is here:
>> https://github.com/pharo-project/pharo-project-proposals
>>
>> On Sat, Jan 21, 2017 at 10:06 AM, Jigyasa Grover
>>  wrote:
>> > Dear Prof Serge
>> >
>> > Thanks for the introduction.
>> >
>> > Dear Alexandre
>> > I have been a past Google Summer of Code student and also mentor budding
>> > developers in Google Code-In.
>> > This time, I was hoping to plug-in the loopholes which might have been
>> > present in last year's organisation application.
>> > Kindly let me know how can we collaborate further on this.
>> > Looking forward to your response.
>> > Thanks and Regards
>> > Jigyasa
>> >
>> >
>> > On Sat, Jan 21, 2017 at 9:06 AM,  wrote:
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Envoyé de mon iPhone
>> >> Le 20 janv. 2017 à 22:21, Yuriy Tymchuk  a
>> écrit :
>> >>
>> >> What do we do?
>> >>
>> >>
>> >>
>> >> We have to apply ! ;-)
>> >>
>> >> We talk with Jigyasa Grover who is doing an internship in my lab at the
>> >> moment and she is willing to help. Jigyasa was a student in a former
>> Google
>> >> Summer of code and is involved in several open-source initiative like
>> Women
>> >> who Code and FOSSASIA. She is a mentor of GoogleCodeIn.
>> >>
>> >> You can find a small presentation during last FOSSASIA : "
>> >>
>> >> My journey in FOSS with Pharo & FOSSASIA by Jigyasa Grover - FOSSASIA
>> >> 2016"
>> >>
>> >> https://m.youtube.com/watch?v=uLIzylxvIz4
>> >>
>> >> She has done a streaming video this morning also: http://goo.gl/UyclKP
>> >> http://youtube.com/watch?v=2iRG_jpOL54
>> >>
>> >> Anyone to help her setup a small team for Pharo proposal to Google
>> Summer
>> >> of Code this year ?
>> >>
>> >>
>> >> On 20 Jan 2017, at 20:38, Alexandre Bergel 
>> >> wrote:
>> >>
>> >> Hi everyone-
>> >>
>> >> Google Summer of Code 2017 has officially begun! Organization
>> applications
>> >> open today, Thursday January 19 and are open through Thursday,
>> February 9th.
>> >> Please see our program site, official timeline and FAQ for more
>> details.
>> >>
>> >> What makes a good organization application? Take a look at our manuals
>> for
>> >> tips and best practices.
>> >>
>> >> We look forward to seeing each of your applications and kicking off
>> >> another great year of GSoC. If you have any questions, don’t hesitate
>> to
>> >> reach out to gsoc-supp...@google.com. We’re here to help!
>> >>
>> >> Google Open Source Programs Office
>> >> --
>> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> >> Alexandre Bergel  http://www.bergel.eu
>> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> >>
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Serge Stinckwich
>> UCBN & UMI UMMISCO 209 (IRD/UPMC)
>> Every DSL ends up being Smalltalk
>> http://www.doesnotunderstand.org/
>>
>>
>
>