Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

[Ben Coman]

On Sun, Apr 5, 2015 at 1:23 PM, Ben Coman  wrote:

> I got annoyed since a few times I thought I'd solved everything just the
> issue looking at the manual examples of one issue, only to find I'd caused
> the other case to fail.  Also keeping track of all cases as I threw away
> images with partial solutions was awkward.  So I turned the examples from
> all these Cases into tests and uploaded
> AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can
> consistently test all cases.  These can be integrated once we have a
> solution for all of them.  Can you think of anymore to add?
>
>
>
>
And of course, please advise if you think the tests are correct.
cheers -ben

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

[Ben Coman]

I got annoyed since a few times I thought I'd solved everything just the
issue looking at the manual examples of one issue, only to find I'd caused
the other case to fail.  Also keeping track of all cases as I threw away
images with partial solutions was awkward.  So I turned the examples from
all these Cases into tests and uploaded
AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can
consistently test all cases.  These can be integrated once we have a
solution for all of them.  Can you think of anymore to add?


On Sun, Apr 5, 2015 at 8:27 AM, Nicolai Hess  wrote:

>
>
> 2015-04-01 18:56 GMT+02:00 Ben Coman :
>
>> Issue 14606 [1] is tagged "Really Important" where evaluating
>>
>> | t1 t2 t3 t4 t5 t6 |
>> t1 := 1.
>> t2 := 2.
>> t3 := 3.
>> t4 := 4.
>> t5 := 5 .
>> t6 := 6.
>> [t5 := 50.
>>  t6 := 60.
>>  t3 + t4.
>>  1 halt.
>> ] value
>>
>> => can't see the value of t4, t5, t6.
>>
>> I've just submitted a possible solution for this, but its a bit late
>> before release for such a change - so I'm asking for "all hands in" to help
>> stress test it.  You don't need to review code, just please merge latest
>> slice 14606 into your normal working image and report your experience.
>>
>> cheers -ben
>>
>> [1] https://pharo.fogbugz.com/default.asp?14606#124466
>>
>>
>
>
> Origins of issue "14606 Can't see some variables values while debugging
> closure"
> It starts with issue:
> 14079 Inconsistent information in debugger (pharo 4)
> (fixed in 40258)
> The thisContext inspector in the debugger (sometimes) shows the wrong
> values for the thisContext temp vars.
> This was first seen in Method FreeTypeFontProvider>>#updateFromFile:
> I extracted a minimal example to reproduce this behavior:
> [ :x |
> | d c b a |
> a := 1.
> b := 2.
> c := 3.
> d := 4.
> [ c:=3. c=0 ] on:Error do:[:ex|].
> d halt.
> [ c:=3. c=0 ] whileTrue:[]] value:23
> If you execute this method, it stops at "d halt". Look at the "all temp
> vars" and the
> individual temp var entries in the context inspector. It shows the temp
> vars with the correct
> values. Now do a step over, int the whileTrue block the temp var name list
> is unchanged but
> the values changed their order, now the list of individual temp vars shows
> the wrong values!
> Why did this happen?
> There are two problems,
> 1. The order of temp vars changes between the method context and the block
> closure
> 2. The EyeDebuggerContextInspector compares ContextTempEyeElements
> without their inst vars (tempName AND tempIndex).
>In EyeInspector>>#updateList:
> We step into a new block and the debugger calls updateList, here
> we check the current list (self list getItems) with the new list (elements)
> and check if they are equal, they aren't, because the lists contain
> ContextTempEyeElements with
> the same tempName but different tempIndex, but the #= selector in
> AbstractEyeElement doesn't check this.
> EyeInspector>>#updateList
> "update the list of elements displayed according to the new object"
>
> | elements |
> "self haltOnce."
> elements := self generateElements.
> self list getItems = elements ifTrue: [ ^ self ]. "<<<--- returns
> event if the elements aren't equal"
> 
>
> Possible solutions:
> - Don't reorder tempvars in inner scopes. This needs some deeper knowlegde
> of opals AST Translator.
> - Fix the #= for AbstractEyeElement resp. ContextTempEyeElement
> - in ContextTempEyeElement, access the temp values not by index (they
> changed) but by name
> I choosed the latter, because I could not get a working fix for the other,
> this raised some
> new issues. Not really new, they exists already, but weren't visible
> because they were only
> used in special cases:
>
> 13260 inspecting variables in the debugger fails in some cases
> (fixed in 40354)
> Minimal example:
> x := [ :k || b a |  b:=[ a:=1. a:=k+1.a]] value:7.
> x value
>
> *Execute* the first line, then debug the second.
> In the debugger, in the thisContext inspector, you can select the var
> "k", it shows 7, you can select the var "b" it shows nil (because it *is*
> nil),
> you can not show the value for "a", although it should show "1".
> Why did this happens?
> With the fix for issue 14079, we now use #tempNamed:aName instead of
> #namedTempAt: anIndex
> but in the end, the context only stores the temp vars by index, so we (the
> debugger)
> needs to find the index for the named temp. This is done through
> DebuggerMethodMapOpal
> namedTempAt:in: resp. tempNamed:in:
> It looks up the temp index by the variable binding for the *Method* scope
> (and finally the method context).
> This is wrong, because in this case, the method context is already dead.
> I fixed this by changing OCVectorTempVariable>>#readFromContext:scope:
> to start from the inner scope instead of the scope that defined the method
> (because it can
> be already dead). (This wasn't straight forward, I need 

Re: [Pharo-dev] Spotter

[Ben Coman]

On Sun, Apr 5, 2015 at 9:03 AM, Aliaksei Syrel  wrote:

> Hi Ben,
>>
>>
>> This is quite a hidden and implicit key stroke.  Regardless that I know
>> I've used it before follow a tutorial, I forgot it.  Since Spotter has a
>>  (which I like and think it could be pushed as a standard
>> throughout the system in Pharo 5), it might be useful for Pharo 4 if the
>> Spotter Settings page contains a "How To" or "Keyboard shortcuts" item that
>> just contains descriptive text.  Or if there is no facility for that,
>> perhaps a few of the keyboard shortcuts listed as individual items with
>> descriptions, even if you can't change them.  I think this will be useful
>> for people presented with Spotter for the first time, particularly since
>> first use already prompts users to go to settings to send usage data.
>
>
>
> Yes, you right, shortcuts were quite hidden. However, after we received a
> lot of similar feedback we improved the situation with shortcuts. Now all
> actions in Spotter have explicit action buttons:
>

Cool. When I was looking at a results category down the page, I didn't
notice the icon at the top (in the image shown next to 16/16) or in advance
understand that it would move if I clicked in the category. I can
understand the logic that it indicates which category the shortcut will
apply to, however...
* I'm not really going to be looking at a graphic UI component when using
shortcut.  I'll "just know" what it applies to.
* To use the shortcut on other than the first category, it takes two
actions: mouse-click the category *then* use the shortcut.  If the icon
appeared on each category, it would only need one action to just click the
icon.   (After I wrote this I see Sean had a similar issue, so I know its
late. but can Pharo 4 get that icon per category, rather than just on the
top category?)


>
> As soon as you press "shift" (you can't not to press shift during usage of
> spotter) all action buttons are highlighted explicitly:
>

Nice feature, but actually I don't notice myself using  a lot (maybe
I am under utilising the shortcuts) so this is catch-22 [1] - the feature
may go unnoticed for newbies.  Perhaps where the text entry is seeded with
"Search", this could accommodate a tip more like "Search - hold shift to
show functions/tooltips"

[1]  http://www.urbandictionary.com/define.php?term=Catch+22


>
> If you hover action button for a few second a hint appears that tells
> which shortcut is assigned to an action. If you hover the button while
> pressing shift a hint appears immediately:
>
> Also, in Pharo help there is a good tutorial listing all Spotter shortcuts
> and assigned actions:
>

This is good, but not immediately discoverable. Perhaps a button on the
settings page could link to that page?

cheers -ben


>
> On Sun, Apr 5, 2015 at 2:35 AM, Ben Coman  wrote:
>
>> Thanks Aliaksei.
>>
>> This is quite a hidden and implicit key stroke.  Regardless that I know
>> I've used it before follow a tutorial, I forgot it.  Since Spotter has a
>>  (which I like and think it could be pushed as a standard
>> throughout the system in Pharo 5), it might be useful for Pharo 4 if the
>> Spotter Settings page contains a "How To" or "Keyboard shortcuts" item that
>> just contains descriptive text.  Or if there is no facility for that,
>> perhaps a few of the keyboard shortcuts listed as individual items with
>> descriptions, even if you can't change them.  I think this will be useful
>> for people presented with Spotter for the first time, particularly since
>> first use already prompts users to go to settings to send usage data.
>>
>> cheers -ben
>>
>> On Sun, Apr 5, 2015 at 8:25 AM, Aliaksei Syrel 
>> wrote:
>>
>>> Hi Ben,
>>>
>>> It's CMD+Shift+Right
>>> On Apr 5, 2015 2:23 AM, "Ben Coman"  wrote:
>>>
 Just a note, I went back to an old image and really miss the Spotter
 workflow.

 One thing, can you remind me how when it shows 5/30 implementors I get
 a list of all 30?  I'm sure I've done this before but can't remember.
 Perhaps this means its not obvious and maybe should appear in a "How To
 Use" section in the Release Notes.

 cheers -ben

>>>
>>
>

Re: [Pharo-dev] Spotter

[Sean P. DeNigris]

Ben Coman wrote
> One thing, can you remind me how when it shows 5/30 implementors I get a
> list of all 30?

One strange thing is that the arrow in "[category] x/yy ->" only appears in
the top category, so you can't go to the second or third category and click
it.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Spotter-tp4817609p4817623.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Spotter

[Ben Coman]

Thanks Aliaksei.

This is quite a hidden and implicit key stroke.  Regardless that I know
I've used it before follow a tutorial, I forgot it.  Since Spotter has a
 (which I like and think it could be pushed as a standard
throughout the system in Pharo 5), it might be useful for Pharo 4 if the
Spotter Settings page contains a "How To" or "Keyboard shortcuts" item that
just contains descriptive text.  Or if there is no facility for that,
perhaps a few of the keyboard shortcuts listed as individual items with
descriptions, even if you can't change them.  I think this will be useful
for people presented with Spotter for the first time, particularly since
first use already prompts users to go to settings to send usage data.

cheers -ben

On Sun, Apr 5, 2015 at 8:25 AM, Aliaksei Syrel  wrote:

> Hi Ben,
>
> It's CMD+Shift+Right
> On Apr 5, 2015 2:23 AM, "Ben Coman"  wrote:
>
>> Just a note, I went back to an old image and really miss the Spotter
>> workflow.
>>
>> One thing, can you remind me how when it shows 5/30 implementors I get a
>> list of all 30?  I'm sure I've done this before but can't remember.
>> Perhaps this means its not obvious and maybe should appear in a "How To
>> Use" section in the Release Notes.
>>
>> cheers -ben
>>
>

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

[Nicolai Hess]

2015-04-01 18:56 GMT+02:00 Ben Coman :

> Issue 14606 [1] is tagged "Really Important" where evaluating
>
> | t1 t2 t3 t4 t5 t6 |
> t1 := 1.
> t2 := 2.
> t3 := 3.
> t4 := 4.
> t5 := 5 .
> t6 := 6.
> [t5 := 50.
>  t6 := 60.
>  t3 + t4.
>  1 halt.
> ] value
>
> => can't see the value of t4, t5, t6.
>
> I've just submitted a possible solution for this, but its a bit late
> before release for such a change - so I'm asking for "all hands in" to help
> stress test it.  You don't need to review code, just please merge latest
> slice 14606 into your normal working image and report your experience.
>
> cheers -ben
>
> [1] https://pharo.fogbugz.com/default.asp?14606#124466
>
>


Origins of issue "14606 Can't see some variables values while debugging
closure"
It starts with issue:
14079 Inconsistent information in debugger (pharo 4)
(fixed in 40258)
The thisContext inspector in the debugger (sometimes) shows the wrong
values for the thisContext temp vars.
This was first seen in Method FreeTypeFontProvider>>#updateFromFile:
I extracted a minimal example to reproduce this behavior:
[ :x |
| d c b a |
a := 1.
b := 2.
c := 3.
d := 4.
[ c:=3. c=0 ] on:Error do:[:ex|].
d halt.
[ c:=3. c=0 ] whileTrue:[]] value:23
If you execute this method, it stops at "d halt". Look at the "all temp
vars" and the
individual temp var entries in the context inspector. It shows the temp
vars with the correct
values. Now do a step over, int the whileTrue block the temp var name list
is unchanged but
the values changed their order, now the list of individual temp vars shows
the wrong values!
Why did this happen?
There are two problems,
1. The order of temp vars changes between the method context and the block
closure
2. The EyeDebuggerContextInspector compares ContextTempEyeElements  without
their inst vars (tempName AND tempIndex).
   In EyeInspector>>#updateList:
We step into a new block and the debugger calls updateList, here
we check the current list (self list getItems) with the new list (elements)
and check if they are equal, they aren't, because the lists contain
ContextTempEyeElements with
the same tempName but different tempIndex, but the #= selector in
AbstractEyeElement doesn't check this.
EyeInspector>>#updateList
"update the list of elements displayed according to the new object"

| elements |
"self haltOnce."
elements := self generateElements.
self list getItems = elements ifTrue: [ ^ self ]. "<<<--- returns event
if the elements aren't equal"


Possible solutions:
- Don't reorder tempvars in inner scopes. This needs some deeper knowlegde
of opals AST Translator.
- Fix the #= for AbstractEyeElement resp. ContextTempEyeElement
- in ContextTempEyeElement, access the temp values not by index (they
changed) but by name
I choosed the latter, because I could not get a working fix for the other,
this raised some
new issues. Not really new, they exists already, but weren't visible
because they were only
used in special cases:

13260 inspecting variables in the debugger fails in some cases
(fixed in 40354)
Minimal example:
x := [ :k || b a |  b:=[ a:=1. a:=k+1.a]] value:7.
x value

*Execute* the first line, then debug the second.
In the debugger, in the thisContext inspector, you can select the var
"k", it shows 7, you can select the var "b" it shows nil (because it *is*
nil),
you can not show the value for "a", although it should show "1".
Why did this happens?
With the fix for issue 14079, we now use #tempNamed:aName instead of
#namedTempAt: anIndex
but in the end, the context only stores the temp vars by index, so we (the
debugger)
needs to find the index for the named temp. This is done through
DebuggerMethodMapOpal
namedTempAt:in: resp. tempNamed:in:
It looks up the temp index by the variable binding for the *Method* scope
(and finally the method context).
This is wrong, because in this case, the method context is already dead.
I fixed this by changing OCVectorTempVariable>>#readFromContext:scope:
to start from the inner scope instead of the scope that defined the method
(because it can
be already dead). (This wasn't straight forward, I need to change some more
because the
way the IR class for constructing the closures bytecodes, only searched in
its "block sequence"
but the copyied tempvector is defined in its "sequence" (I don't really
remember what is what).
Even if I had choosed a different fix for issue 14079, this still had to be
fixed, because
indirect variable access through namedTempAt: is used, if we select the
temp var in the *code view*
and do a inspectIt.
Even with this fix, the issue is not fully solved:

Unsolved issues:
14606 Can't see some variables values while debugging closure
Minimal example:
|a b c|
a := [ Transcript show: 'test' ].
[ b :=4.
c := 5.
1 halt] on: Error do: a.
select the b or c value in the thisContext inspector shows "nil" although
they actually have a value.
And

Re: [Pharo-dev] Spotter

[Aliaksei Syrel]

Hi Ben,

It's CMD+Shift+Right
On Apr 5, 2015 2:23 AM, "Ben Coman"  wrote:

> Just a note, I went back to an old image and really miss the Spotter
> workflow.
>
> One thing, can you remind me how when it shows 5/30 implementors I get a
> list of all 30?  I'm sure I've done this before but can't remember.
> Perhaps this means its not obvious and maybe should appear in a "How To
> Use" section in the Release Notes.
>
> cheers -ben
>

[Pharo-dev] Spotter

[Ben Coman]

Just a note, I went back to an old image and really miss the Spotter
workflow.

One thing, can you remind me how when it shows 5/30 implementors I get a
list of all 30?  I'm sure I've done this before but can't remember.
Perhaps this means its not obvious and maybe should appear in a "How To
Use" section in the Release Notes.

cheers -ben

Re: [Pharo-dev] Who maintains Aconcagua & Chalten?

[Sean P. DeNigris]

Hernan Wilkinson-3 wrote
>  I answer you in the morning, contact me directly if you did not get the
> answer

Hi Hernan, I emailed you a few times. I'm afraid my messages have either
gotten trapped in your spam filter or I have the wrong address. Let me
know...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Who-maintains-Aconcagua-Chalten-tp4813575p4817606.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Downloading the latest 40 Image -> Error

[Sven Van Caekenberghe]

I think this has to do with CDN caching or cache invalidation.

> On 04 Apr 2015, at 21:09, Max Leske  wrote:
> 
> Confirmed.
> 
>> On 04 Apr 2015, at 20:46, Hernán Morales Durand  
>> wrote:
>> 
>> FYI
>> 
>> $ wget -O- get.pharo.org/40+vm | bash
>> --2015-04-04 18:41:59--  http://get.pharo.org/40+vm
>> Resolving get.pharo.org... 128.93.162.72
>> Connecting to get.pharo.org|128.93.162.72|:80... connected.
>> HTTP request sent, awaiting response... 200 OK
>> Length: 2885 (2.8K) [text/html]
>> Saving to: `STDOUT'
>> 
>> 100%[==>] 2,885   --.-K/s   in 0.001s
>> 
>> 2015-04-04 18:42:00 (2.54 MB/s) - written to stdout [2885/2885]
>> 
>> Downloading the latest 40 Image:
>> http://files.pharo.org/image/40/latest.zip
>> [image.MJSoCf/image.zip]
>>   End-of-central-directory signature not found.  Either this file is not
>>   a zipfile, or it constitutes one disk of a multi-part archive.  In the
>>   latter case the central directory and zipfile comment will be found on
>>   the last disk(s) of this archive.
>> unzip:  cannot find zipfile directory in one of image.MJSoCf/image.zip or
>> image.MJSoCf/image.zip.zip, and cannot find 
>> image.MJSoCf/image.zip.ZIP,
>> period.
> 

Re: [Pharo-dev] Downloading the latest 40 Image -> Error

[Max Leske]

Confirmed.

> On 04 Apr 2015, at 20:46, Hernán Morales Durand  
> wrote:
> 
> FYI
> 
> $ wget -O- get.pharo.org/40+vm  | bash
> --2015-04-04 18:41:59--  http://get.pharo.org/40+vm 
> 
> Resolving get.pharo.org... 128.93.162.72
> Connecting to get.pharo.org |128.93.162.72|:80... 
> connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 2885 (2.8K) [text/html]
> Saving to: `STDOUT'
> 
> 100%[==>] 2,885   --.-K/s   in 0.001s
> 
> 2015-04-04 18:42:00 (2.54 MB/s) - written to stdout [2885/2885]
> 
> Downloading the latest 40 Image:
> http://files.pharo.org/image/40/latest.zip 
> 
> [image.MJSoCf/image.zip]
>   End-of-central-directory signature not found.  Either this file is not
>   a zipfile, or it constitutes one disk of a multi-part archive.  In the
>   latter case the central directory and zipfile comment will be found on
>   the last disk(s) of this archive.
> unzip:  cannot find zipfile directory in one of image.MJSoCf/image.zip or
> image.MJSoCf/image.zip.zip, and cannot find 
> image.MJSoCf/image.zip.ZIP,
> period.

[Pharo-dev] Downloading the latest 40 Image -> Error

[Hernán Morales Durand]

FYI

$ wget -O- get.pharo.org/40+vm | bash
--2015-04-04 18:41:59--  http://get.pharo.org/40+vm
Resolving get.pharo.org... 128.93.162.72
Connecting to get.pharo.org|128.93.162.72|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2885 (2.8K) [text/html]
Saving to: `STDOUT'

100%[==>] 2,885   --.-K/s   in
0.001s

2015-04-04 18:42:00 (2.54 MB/s) - written to stdout [2885/2885]

Downloading the latest 40 Image:
http://files.pharo.org/image/40/latest.zip
[image.MJSoCf/image.zip]
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of image.MJSoCf/image.zip or
image.MJSoCf/image.zip.zip, and cannot find
image.MJSoCf/image.zip.ZIP,
period.

Re: [Pharo-dev] UpdatedPharoByExample for 3.0, 4.0, 5.0

[Dmitri Zagidulin]

I agree 100% that we should keep separate book versions for the
corresponding Pharo versions. Specifically:

- Use the 'master' branch for the current stable version (4.0). Basically,
the way things are right now. This at least won't break existing CI jobs
(tests and PDF generation).
- Have a 3.0 and a 5.0 branch (or maybe just 5.0, going forward, if there's
not enough demand or reason to do 3.0).
- When time comes for 5.0 release, the 5 branch gets moved to master, and
the previous master gets moved to a 4.0 branch. And so on.

(Btw, I don't think it would make sense for us to use tags like
'Pharo-4-final', since the whole point about having a book under source
control like that is that it's continuously improving. It makes sense to
freeze software with tags (well, sort of, except you still end up making
bugfix releases), but less so for books.)

I think the time / energy investment problem that stepharo was mentioning
has to do with:

1) setting up the Jenkins and Travis CI jobs for the various branches.
Annoying, but at least it's just an initial effort (plus subsequent bursts
of effort for each Pharo version branch).

2) porting new content (or even revisions) to multiple versions. So, if a
new chapter is added to the 5.0 branch in the future, is it then a
requirement to also back-port it to 4.0 (and 3.0, if we have it)? (And to
do the resulting small tweaks to make sure the code still works for that
version, change the screenshots and so on)? This is where most of the
effort comes in, as I see it. The solution is probably in relaxed
expectations. We could have an implicit (or even explicitly stated in the
readme) policy that new revisions will only propagate from the current
version upwards (but not backwards).
Or, even simpler, just leave it up to individual contributors' motivations
-- meaning, new revision comes in, we open up tickets to back-port it to
previous versions, and if somebody cares enough to do it, it'll get ported.


On Sat, Apr 4, 2015 at 10:19 AM, Sean P. DeNigris 
wrote:

> stepharo wrote
> > there is a huge time / energy investment problems.
>
> I don't see it. The simplest thing (which is 0 extra work AFAICT) would be
> to tag the last version before we start updating for 5.0 as something like
> 'Pharo-4-final'. Almost as easy would be to have a branch per version, so
> e.g. typos could be merged back if someone was interested. But maybe I'm
> missing something - where specifically do you see the time & energy
> investment? Because I think we could've set it up in less time than it took
> me to write this reply!
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514p4817525.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] VM and .sources in separate dirs question

[Dmitri Zagidulin]

Ok, that's awesome. Thank you for explaining!

On Sat, Apr 4, 2015 at 8:50 AM, Max Leske  wrote:

>
> On 03 Apr 2015, at 19:02, Dmitri Zagidulin  wrote:
>
> Do you happen to know how it does it? (I wouldn't know where to look, in
> the source code). Does it still work if you move the sources to another
> directory, from your current one? Does Pharo do a whole-disk search every
> time? (Or just when it doesn't find them?)
>
> On Fri, Apr 3, 2015 at 12:00 PM, Max Leske  wrote:
>
>>
>> On 03 Apr 2015, at 17:55, Dmitri Zagidulin  wrote:
>>
>> On Fri, Apr 3, 2015 at 11:49 AM, Max Leske  wrote:
>>>
>>> > that you can keep the VM and .sources in different directories? How do
>>> you tell the VM where to locate the sources?
>>>
>>> You don’t. It’s detected automagically!
>>>
>>
>> Wait, how does it know which .sources file to pick? :) What if there are
>> .sources from multiple versions of Pharo, etc, lying around on the hard
>> drive?
>>
>>
> No, Pharo won’t search your disk, that would take way too long. Basically,
> the image tries to find the sources in two places:
> 1. the image directory
> 2. the vm directory
>
> In reality Pharo tries to do a bit more. The places Pharo looks in are
> listed in OSPlatform>>potentialLocationsOfSourcesFile (and subclasses).
>
> See also PharoFilesOpener>>openSources.
>
> Note that the Pharo implementation has probably diverged a bit from the
> one that Squeak uses / used to use.
>
> Cheers,
> Max
>
>
>>
>> The image decides which sources file it needs. I have all of mine in a
>> single directory with all the different VMs. Works like a charm.
>>
>
>
>

Re: [Pharo-dev] UpdatedPharoByExample for 3.0, 4.0, 5.0

[Sean P. DeNigris]

stepharo wrote
> there is a huge time / energy investment problems.

I don't see it. The simplest thing (which is 0 extra work AFAICT) would be
to tag the last version before we start updating for 5.0 as something like
'Pharo-4-final'. Almost as easy would be to have a branch per version, so
e.g. typos could be merged back if someone was interested. But maybe I'm
missing something - where specifically do you see the time & energy
investment? Because I think we could've set it up in less time than it took
me to write this reply!



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514p4817525.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Brand new modern Spotter design!

[stepharo]

 doru it would be fun to have an even redder GTSpotter and some colored 
windows

In a dark background it can be really "efficient" :)

Stef

Le 3/4/15 18:27, Tudor Girba a écrit :

I wonder :)

Doru

On Fri, Apr 3, 2015 at 3:14 PM, Sven Van Caekenberghe > wrote:


Maybe the color is an April 1st joke ?

> On 03 Apr 2015, at 10:30, Tudor Girba mailto:tu...@tudorgirba.com>> wrote:
>
> Universal :
>
> Doru
>
> On Fri, Apr 3, 2015 at 9:47 AM, Stephan Eggermont
mailto:step...@stack.nl>> wrote:
> On 01/04/15 11:53, Tudor Girba wrote:
> Nah, you have to experience it first hand yourself. It's too cool to
> experience it via a dead picture.
>
> On wednesday we used it in the devnology workshop.
> It just works, no participants had any remarks :)
>
> Stephan
>
>
>
>
>
>
> --
> www.tudorgirba.com 
>
> "Every thing has its own flow"





--
www.tudorgirba.com 

"Every thing has its own flow"

Re: [Pharo-dev] UpdatedPharoByExample for 3.0, 4.0, 5.0

[stepharo]

there is no technical problem.
there is a huge time / energy investment problems.
We will reintroduce in pillar the possibility to run tests.
and we will add support (should check what stephan did to get automatic 
scrneeshots).

Stef


Le 4/4/15 15:04, Sean P. DeNigris a écrit :

Would it make sense to freeze the documentation for each image version? Maybe
a branch per image? This way, people who choose/need to work with previous
image versions have an accurate reference. From my limited Git experience it
shouldn't be much extra work.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] UpdatedPharoByExample for 3.0, 4.0, 5.0

[kilon alios]

I agree it makes sense, we can use git tags , or branches. Having separate
docs for every version is how it works for all other languages I have used.
Its zero extra work.

I dont know about the generation of pdfs though, I am not familair with CI
/ Jenkins and how easy it is to assign specific builds to git tags /
branches.

On Sat, Apr 4, 2015 at 4:04 PM, Sean P. DeNigris 
wrote:

> Would it make sense to freeze the documentation for each image version?
> Maybe
> a branch per image? This way, people who choose/need to work with previous
> image versions have an accurate reference. From my limited Git experience
> it
> shouldn't be much extra work.
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

[Pharo-dev] UpdatedPharoByExample for 3.0, 4.0, 5.0

[Sean P. DeNigris]

Would it make sense to freeze the documentation for each image version? Maybe
a branch per image? This way, people who choose/need to work with previous
image versions have an accurate reference. From my limited Git experience it
shouldn't be much extra work.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Binding semantics of SystemDictionary

[Max Leske]

Bump… I really think this is something we should talk about… Otherwise I’ll 
open an issue on phogbugz.

> On 01 Apr 2015, at 22:58, stepharo  wrote:
> 
> Please do not use Smalltalk at:
> We will ban it for real!

Good to know. I wasn’t aware of that.

> 
> Stef
> 
> Le 31/3/15 20:49, Max Leske a écrit :
>> Hi
>> 
>> Tommaso and I, while hacking on Fuel, today discovered that globals in Pharo 
>> can have very weird bindings (I guess some of you already know that). For 
>> example:
>> 
>>  class := Class new
>>  setName: 4;
>>  yourself.
>>  Smalltalk
>>  at: class name
>>  put: class.
>> 
>> So we now have a class with name 4 (which is a SmallInteger):
>> 
>>  self assert: (Smalltalk at: 4) == class.
>> 
>> 
>> There are basically two different issues:
>> 1. SystemDictionary will store any kind of association, not only symbols / 
>> strings
> 
> arg

Exactly the sound I made when we discovered that :)

> 
>> 2. SystemDictionary is an IdentityDictionary and as such two equivalent but 
>> not identical keys will not resolve to the same object:
>> 
>>  class := Class new
>>  setName: (String streamContents: [ :s | s nextPutAll: 
>> 'someName']);
>>  yourself.
>>  Smalltalk
>>  at: class name
>>  put: class.
>>  
>>  Smalltalk
>>  at: (String streamContents: [ :s | s nextPutAll: 'someName’])
>>  ifAbsent: [ false ]. “——> false”
>> 
>> 
>> In Fuel we simply assume that any key to a global is either a ByteString or 
>> ByteSymbol. If that’s not the case bad things happen.
>> It would help us a lot if we could clear up the semantics of bindings in 
>> SystemDictionary:
>> 1. Are bindings with keys that are not ByteString or ByteSymbol valid?
>> 2. Should we keep allowing ByteString as keys to globals (ByteSymbol 
>> guarantees identity)?
>> 3. If we allow ByteString, do we also allow WideString?
>> 4. Would “type checks” on SystemDictionary incur a big performance penalty?
>> 
>> 
>> Any suggestions are welcome.
>> 
>> Cheers,
>> Max
>> 
> 
> 

Re: [Pharo-dev] VM and .sources in separate dirs question

[Max Leske]

> On 03 Apr 2015, at 19:02, Dmitri Zagidulin  wrote:
> 
> Do you happen to know how it does it? (I wouldn't know where to look, in the 
> source code). Does it still work if you move the sources to another 
> directory, from your current one? Does Pharo do a whole-disk search every 
> time? (Or just when it doesn't find them?)
> 
> On Fri, Apr 3, 2015 at 12:00 PM, Max Leske  > wrote:
> 
>> On 03 Apr 2015, at 17:55, Dmitri Zagidulin > > wrote:
>> 
>> On Fri, Apr 3, 2015 at 11:49 AM, Max Leske > > wrote:
>> > that you can keep the VM and .sources in different directories? How do you 
>> > tell the VM where to locate the sources?
>> 
>> You don’t. It’s detected automagically!
>> 
>> Wait, how does it know which .sources file to pick? :) What if there are 
>> .sources from multiple versions of Pharo, etc, lying around on the hard 
>> drive? 

No, Pharo won’t search your disk, that would take way too long. Basically, the 
image tries to find the sources in two places:
1. the image directory
2. the vm directory

In reality Pharo tries to do a bit more. The places Pharo looks in are listed 
in OSPlatform>>potentialLocationsOfSourcesFile (and subclasses).

See also PharoFilesOpener>>openSources.

Note that the Pharo implementation has probably diverged a bit from the one 
that Squeak uses / used to use.

Cheers,
Max

>> 
> 
> The image decides which sources file it needs. I have all of mine in a single 
> directory with all the different VMs. Works like a charm.
> 

Re: [Pharo-dev] Freeze while running a loop

[Gaurav Singh]

Thanks Alain :)

On Sat, Apr 4, 2015 at 5:02 PM, Alain Rastoul  wrote:

> Hi Gaurav,
>
> As said by Aliaksei, the problem is string concatenation with ,
> your example takes 33 secs on a core i7 3.3Ghz (quite some ms ;) )
> In Smalltalk, you handle that with streams (see Aliaksei example).
> You can also add objects to all types of collections, not only strings
> (Arrays etc).
> You will find examples by searching references of WriteStream class (in
> Nautilus, on WriteStream, right click / Analyse Class refs) or senders of
> streamContents: .
> Have a look at Pharo by examples chapter on streams
> http://pharo.gforge.inria.fr/PBE1/PBE1ch11.html
> (pdf here: http://pharobyexample.org/)
>
> And if you want to see what is going on with some code, you can select
> your code in the workspace and use the 'Profile it' option in the menu.
> Alternatively, you can open the profiler tools with World Menu/Tools/Time
> Profiler, paste your code in the code pane of the profiler and run it.
> A very handy tool, worth to know about it.
>
> HTH
>
> Regards,
>
> Alain
>
>
>

Re: [Pharo-dev] Freeze while running a loop

[Alain Rastoul]

Hi Gaurav,

As said by Aliaksei, the problem is string concatenation with ,
your example takes 33 secs on a core i7 3.3Ghz (quite some ms ;) )
In Smalltalk, you handle that with streams (see Aliaksei example).
You can also add objects to all types of collections, not only strings 
(Arrays etc).
You will find examples by searching references of WriteStream class (in 
Nautilus, on WriteStream, right click / Analyse Class refs) or senders 
of streamContents: .

Have a look at Pharo by examples chapter on streams
http://pharo.gforge.inria.fr/PBE1/PBE1ch11.html
(pdf here: http://pharobyexample.org/)

And if you want to see what is going on with some code, you can select 
your code in the workspace and use the 'Profile it' option in the menu.
Alternatively, you can open the profiler tools with World 
Menu/Tools/Time Profiler, paste your code in the code pane of the 
profiler and run it.

A very handy tool, worth to know about it.

HTH

Regards,

Alain

Re: [Pharo-dev] Forcing GTInspector to refresh

[stepharo]

Ok I found the icon.
Now redoing for the third time my video

Stef


Hi

I was doing a video on teaching how to build a simple counter and
I would like to know how I can refresh the value of an instance 
variable in GT.


I really hope that we will fix such kind of problem because it kills 
my fun showing Pharo.


Stef

Re: [Pharo-dev] Magritte = Auto-GT Presentation

[Norbert Hartl]

Cool! Can you add a spec based editor for the object? ;) That woule be 
übernice, haha.

Norbert



> Am 04.04.2015 um 06:01 schrieb Sean P. DeNigris :
> 
> gtInspectorMagritteIn: composite
>
>| table |
>table := composite table
>title: 'Magritte';
>display: [ self magritteDescription children collect: [ :desc |
>desc label -> (desc toString: (desc accessor read: self)) ] ];
>column: 'Field' evaluated: #key;
>column: 'Value' evaluated: #value;
>send: #value
> 
> descriptionName
>
> 
>^ MAStringDescription new
>accessor: #name;
>label: 'Name';
>priority: 100;
>yourself
> descriptionPages
> etc...
> 
>  
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/Magritte-Auto-GT-Presentation-tp4817448.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

[Pharo-dev] Forcing GTInspector to refresh

[stepharo]

Hi

I was doing a video on teaching how to build a simple counter and
I would like to know how I can refresh the value of an instance variable 
in GT.


I really hope that we will fix such kind of problem because it kills my 
fun showing Pharo.


Stef

Re: [Pharo-dev] Magritte = Auto-GT Presentation

[stepharo]

Cool :)
I still have on my endless todo to write a new chapter on magritte 3 :(


Le 4/4/15 06:01, Sean P. DeNigris a écrit :

gtInspectorMagritteIn: composite

| table |
table := composite table
title: 'Magritte';
display: [ self magritteDescription children collect: [ :desc |
desc label -> (desc toString: (desc accessor read: 
self)) ] ];
column: 'Field' evaluated: #key;
column: 'Value' evaluated: #value;
send: #value

descriptionName


^ MAStringDescription new
accessor: #name;
label: 'Name';
priority: 100;
yourself
descriptionPages
etc...





-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Magritte-Auto-GT-Presentation-tp4817448.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] MethodContextTest

[Marcus Denker]

Yes!

> On 04 Apr 2015, at 08:41, Ben Coman  wrote:
> 
> As I understand it, MethodContext is not more, and now there is only Context.
> 
> Should MethodContextTest be renamed ContextTest ?