[Pharo-dev] mutex optimisation - #ifTrue:ifFalse versus #ifNil:ifNotNil:

[Ben Coman]

The Mutex primitives return a tri-state value: true, false and nil.

So we would have...

  NewMutex>>critical: mutuallyExcludedBlock ifLocked: alternativeBlock
^lock tryAcquire
ifNil: mutuallyExcludedBlock
ifNotNil: [:acquired|
acquired
ifTrue: [mutuallyExcludedBlock ensure: [lock strictRelease]]
ifFalse: alternativeBlock ].


  NewMutex>>critical: mutuallyExcludedBlock
^lock waitAcquire
ifNil: mutuallyExcludedBlock
ifNotNil:[ mutuallyExcludedBlock ensure: [lock strictRelease] ].


So we would have
  NewMutex>>critical: aBlock ifLocked: lockedBlock
^lock tryAcquire
ifNil: mutuallyExcludedBlock
ifNotNil: [:acquired |
acquired
ifTrue: [mutuallyExcludedBlock ensure: [lock strictRelease]]
ifFalse: alternativeBlock ].


Mutex>>critical: aBlock ifLocked: lockedBlock
^self primitiveTestAndSetOwnershipOfCriticalSection
ifNil: [lockedBlock value]
ifNotNil:[:alreadyOwner|
alreadyOwner
ifTrue: [aBlock value]
ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]]]

 ifNil:ifNotNil:


Also, I notice several of RBMessageNode>>isInline methods contain...
self receiver isBlock ifTrue: [^ false].
Does this mean that...
   [ true ] ifTrue: [2] ifFalse: [3]
is not inlined?

Re: [Pharo-dev] mutex optimisation - #ifTrue:ifFalse versus #ifNil:ifNotNil: [ignore last post]

[Ben Coman]

Whoops, sorry,  that last post shot off half done. Please delete it.

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

[Ben Coman]

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

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

At step 3, instead clicking  works okay.

cheers -ben

Re: [Pharo-dev] Who is using Pharo Launcher and for what

[Ben Coman]

PharoLauncher is the my primary entry point to Pharo.  I now feel
awkward starting Pharo any other way.  It makes is cheap to create and
manage throw away images when tackling multiple issues from the
tracker.

The critical thing is the _single_step_ to download the most recent
numeric build to an image named CaseX-buildM.  Then to try another
approach, CaseXb-buildM is created from the _local_ cache.  It cheap
to have two images, one original and one loaded with someone else's
slice loaded and trace the two in parallel.

Its our only tool that makes it feasible to bisect when a problem was
introduced, by creating a *fresh* images from the local template image
cache. Its easy to manage over 100 images, then cull them back in
large groups when redundant.

Company: private enthusiast Pharo community

cheers -ben

On Sat, Feb 20, 2016 at 6:49 PM, Damien Cassou  wrote:
> For my CV, I need to know who is using the stuff I'm doing. If you use
> the Pharo Launcher, could you please tell me in which context (e.g.,
> which company, open-source project) and what you use it for (e.g.,
> download from CI, standard Pharo)?
>
> I don't need long paragraphs, just give me the keywords please.
>
> Thanks
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>

Re: [Pharo-dev] Who is using Pillar and for what

[Ben Coman]

I use it for books for the Pharo project.
cheers -ben

On Sat, Feb 20, 2016 at 6:46 PM, Damien Cassou  wrote:
> For my CV, I need to know who is using the stuff I'm doing. If you use
> Pillar, could you please tell me in which context (e.g., which company,
> open-source project) and what you use it for (e.g., what kind of
> document)?
>
> I don't need long paragraphs, just give me the keywords please.
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>

[Pharo-dev] preferred way to invoke debugger

[Ben Coman]

What is the replacement for...?
[ Smalltalk tools debugger
  openContext: self
  label:'Code simulation error'
  contents: nil].

In adding support to simulate new OwnedLock primitives, I see this is sent from
Context>>doPrimitive:method:receiver:args:
but this is no longer in the image.  I can update it as I go.

cheers -ben

[Pharo-dev] adding custom tabs to bottom of gtDebugger

[Ben Coman]

With...
Error subclass: #OwnedLockBadRelease
instanceVariableNames: 'lockOwner perpetrator'
classVariableNames: ''
package: 'Kernel-Processes'

In playground when I do...
| error |
(error := OwnedLockBadRelease new) signal
then in the debugger select the 'error' tempvar,
the [Raw] tab is too busy, so I'd like a custom [Error] tab
showing only my two instance variables.

I've managed to get a tab to show up by implementing...
OwnedLockBadRelease>>gtDebuggerEvaluatorIn: composite
super gtDebuggerEvaluatorIn: composite.
(GTObjectVariablesBrowser new evaluatorIn: composite)
title: 'Error Tab To Do'
but I can't find how to add variables.

Tips please?
cheers -ben

Re: [Pharo-dev] adding custom tabs to bottom of gtDebugger

[Ben Coman]

Thanks.  Some examples I found useful were
* Date>>gtInspectorDetailsIn:
* GTInspector>>gtInspectorExtensionsIn:

cheers -ben

On Sun, Feb 21, 2016 at 4:53 PM, Tudor Girba <tu...@tudorgirba.com> wrote:
> The tabs from the inspector are defined through inspector extensions.
>
> So, you should have a method annotated with gtInspectorPresentationOrder: in 
> your OwnedLockBadRelease.
>
> Let me know if you need more help.
>
> Cheers,
> Doru
>
>
>> On Feb 21, 2016, at 9:35 AM, Ben Coman <b...@openinworld.com> wrote:
>>
>> With...
>>Error subclass: #OwnedLockBadRelease
>>instanceVariableNames: 'lockOwner perpetrator'
>>classVariableNames: ''
>>package: 'Kernel-Processes'
>>
>> In playground when I do...
>>| error |
>>(error := OwnedLockBadRelease new) signal
>> then in the debugger select the 'error' tempvar,
>> the [Raw] tab is too busy, so I'd like a custom [Error] tab
>> showing only my two instance variables.
>>
>> I've managed to get a tab to show up by implementing...
>>OwnedLockBadRelease>>gtDebuggerEvaluatorIn: composite
>>super gtDebuggerEvaluatorIn: composite.
>>(GTObjectVariablesBrowser new evaluatorIn: composite)
>>title: 'Error Tab To Do'
>> but I can't find how to add variables.
>>
>> Tips please?
>> cheers -ben
>>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "It's not how it is, it is how we see it."
>
>

Re: [Pharo-dev] Off Topic: Children 3-13yr english program -- 4 weeks free access

[Ben Coman]

On Mon, Jul 20, 2015 at 11:17 PM, Ben Coman <b...@openinworld.com> wrote:
> greetings all,
>
> This is a long way off topic, but a random chance someone in the community
> with kids learning english may find it useful.  The past year I've had my 4yr
> & 6yr old girls doing Reading Eggs. Its aimed at native-english children
> ages 3-13 (starting with a test to place kids at a stimulating level).
>
> Its been beneficial for my kids, so I'm forwarding this offer to the
> community.
>
> http://e01.ams11.com/OutboundMessage.aspx?M=1581.347AD7EE-9C8B-4665-A061-90E3147FCA07


There was some appreciation for this six months ago.  Another just
arrived, so I thought I'd share it again.  In another half year I
guess I'll get another, so if anyone doesn't want me to post again
then, let me know.

More background info... ABC is Australia's government sponsored
national TV broadcaster (yay, no commercials!). They produced a web
site to help kids literacy.  It was fantastic for my kids, although my
8 year old got bored with it later on, so it seems more suited for
younger ages.

The 4 week free trial is advertised "No credit card required." An
annual subscription is AU$80.

http://readingeggs.com.au/taf/?utm_source=Aprimo_medium=Email_campaign=Promos=0FE39A32-E6FE-4CBB-8059-62D3593AFE37

cheers -ben

Re: [Pharo-dev] CI is down?

[Ben Coman]

Perhaps pharo-dev can be subscribed to the annoucements?
cheers -ben

On Tue, Feb 2, 2016 at 8:34 PM, Christophe Demarey
 wrote:
> Yes, there is a maintenance.
> You should have received this message (if you did not unregister from
> communication lists):
>
> Dear users,
>
> A maintenance is planned tomorrow (2/2) to upgrade the storage of the CI
> servers. Thus, the service will be stopped between 1pm and 2pm.
>
> Thank you for your understanding,
> Emmanuel
>
>
> Le 2 févr. 2016 à 13:14, Aliaksei Syrel a écrit :
>
> Hi
>
> https://ci.inria.fr/pharo is not responding
> Has any one the same problem?
>
> Cheers,
> Alex
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] dbba45: 50646

[Ben Coman]

On Thu, Mar 17, 2016 at 1:07 AM, Ben Coman <b...@openinworld.com> wrote:
> On Wed, Mar 16, 2016 at 8:36 PM, Esteban Lorenzano <esteba...@gmail.com> 
> wrote:
>> On 16 Mar 2016, at 13:28, GitHub <nore...@github.com> wrote:
>>
>> 17797 random crash while trying to dispose a NULL handle
>> https://pharo.fogbugz.com/f/cases/17797
>>
>> again, this is an attempt against the "Font crashing VM” bug… please I need
>> all reports possible… even if you think is the same as before (even if IS
>> the same as before).
>
>"[A]" ImageWorker do: [ 1 + 1] within: 2 seconds onTimeout: [ self
  inform: 'timeout' ]
>
> A1. Ran refresh.sh per last post and opened Image.
> A2. Opened playground without adjusting native window.
> A3. Three times successfully inspected [A], seeing "2".
> A4. Opened Nautilus and a few more times successfully inspected [A], seeing 
> "2".
> A5. Maximised native window
> A6. Inspecting [A] caused forked child Image to remain open with error
>  FT2Error: Freetype2 primitive failed [error 2][unknown file format]

Refinements...
B1. Ran refresh.sh per last post and opened Image.
B2. Opened playground without adjusting native window.
B3. Three times successfully inspected [A], seeing "2".
B4. Maximised native window
B5. Inspecting [A] caused forked child Image to remain open with error
>  FT2Error: Freetype2 primitive failed [error 2][unknown file format]

C1. Ran refresh.sh per last post and opened Image.
C2. Maximised native window.
C3. Opened playground
C4.  Inspected [A] once, getting...
>  Error: External Image Failed: 34304
C5. Saved Image
C6. Restarted, got...
stack page bytes 4096 available headroom 2788 minimum unused headroom 3020
(Segmentation fault)

D1. Ran refresh.sh per last post and opened Image.
D2. Opened playground
D3. Inspected [A], successfully getting "2"
D4. Several times, Saved Image, Restarted Image, goto D3.
D5. Maximised window.
D6. Inspected [A], forked child Image stayed open, playground is
red-pane-of-death,
  predebug window... FT2Error: Freetype2 primitive failed [error
2][unknown file format]
D7. Quit child Image without saving.
D8. In parent, save then restart produces error...
 stack page bytes 4096 available headroom 2788 minimum unused
headroom 3020 (segmentation fault)

Btw, sometimes the the forked child Image (e.g. named
3635603974497675) that starts up, and sometimes the parent Image is
started, so there are two native windows open titled
"Pharo-5.0-Issue-Tracker-image.image" Both encounter similar frequency
of FT2Error errors.

Trying incrementally changing resolution
244x665 okay = 2
244x683 okay = 2
244x695 okay = 2
244x709 child error FT2Error
244x685 okay = 2 (recovered)
244x700 okay = 2
244x705 parent error Error: External Image Failed: 34304
244x709 okay = 2
244x716 okay = 2
244x918 okay = 2
244x1147 child error FT2Error

The last one is full height.  Now I repeatedly inspected [A] with
strange results.
Using CTRL-I would predominately fail with some successes. Most fails
occurred in spawned Image with a FT2Error.  Using "Inspect" from the
context menu predominately succeeded, with some failures.

Also, sometimes the spawned image startup is s-l-o-w, so the 'timeout'
inform executes, even though the inspect [A] successfully returns "2".

More mucking around indicates a definite tendency to error more often
when the window is large.

cheers -ben

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

[Ben Coman]

On Sun, Mar 13, 2016 at 9:27 AM, Ben Coman <b...@openinworld.com> wrote:

>
>
> On Sun, Mar 13, 2016 at 1:47 AM, Aliaksei Syrel <alex.sy...@gmail.com>
> wrote:
>
>> Hi
>>
>> At some point I got a feeling that actual Delay time is longer than
>> expected. It is especially visible on small delays less than 100ms
>> (otherwise difference is < 1%).
>>
>> [image: Inline image 1]
>> Documentation says that *Delay waits approximately* for specified amount
>> of time. However, according to experimental data an actual difference is
>> always positive with the value around 1.5-2 seconds. It is actually strange
>> where such a constant difference, independent from delay length, comes from.
>> [image: Inline image 2]
>> To conclude, if you want to wait more precisely you need to create delays
>> with duration 1.5 seconds less than expected. Also it would be interesting
>> to test on different hardwares to make sure that difference stays constant
>> (around 1.5-2s)
>>
>> I used the following script to gather data and save in .csv file
>> http://ws.stfx.eu/DSCLG2ON0VBI
>>
>> Tested on:
>> Pharo: #50636
>> Spur-VM: #463
>> OS: Mac OS Yosemite
>> CPU: Intel Core i7 2.39 GHz
>>
>
>
> Nice analysis.  I've previously wondered about such an effect from
> resumptionTime being calculated by the high priority thread in
> #handleTimerEvent: and thus delayed by switching threads, rather than being
> calculated as-soon-as-possible by the low priority process when #schedule:
> is called.   I can't remember my line of reasoning, but doing it the low
> priority process seemed to open the potential for nasty race conditions, so
> I left it as I found it.  Perhaps we should take a time snapshot in the
> #schedule: and pass that through to #handleTimerEvent: similar to
> scheduledDelay.  Would you like to try that?
>
> btw, I have some cleanup of DelayScheduler almost complete that I had
> meant to get into Pharo 5 earlier, but now I think best to wait for early
> Pharo 6.
>
> cheers -ben
>

P.S.  I'm curious how you came to notice this.  I have a long term interest
in Pharo as a soft-real time industrial control system, motion control
system and robotics.  One option is using a protocol like EtherCAT which at
the hardware level does microsecond time synchronisation of all nodes on
the network, and every measurement is microsecond timestamped in the node
before it is sent to the control system.  So your motion control algorithms
can work with an extremely accurate timestamp of *exactly* when a
measurement was taken, rather than when the measurement arrived at the
control program which is dependent on the delay and jitter vagaries of
communications hardware and CPU scheduling of the network stack and control
programs.

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

[Ben Coman]

On Sun, Mar 13, 2016 at 1:47 AM, Aliaksei Syrel 
wrote:

> Hi
>
> At some point I got a feeling that actual Delay time is longer than
> expected. It is especially visible on small delays less than 100ms
> (otherwise difference is < 1%).
>
> [image: Inline image 1]
> Documentation says that *Delay waits approximately* for specified amount
> of time. However, according to experimental data an actual difference is
> always positive with the value around 1.5-2 seconds. It is actually strange
> where such a constant difference, independent from delay length, comes from.
> [image: Inline image 2]
> To conclude, if you want to wait more precisely you need to create delays
> with duration 1.5 seconds less than expected. Also it would be interesting
> to test on different hardwares to make sure that difference stays constant
> (around 1.5-2s)
>
> I used the following script to gather data and save in .csv file
> http://ws.stfx.eu/DSCLG2ON0VBI
>
> Tested on:
> Pharo: #50636
> Spur-VM: #463
> OS: Mac OS Yosemite
> CPU: Intel Core i7 2.39 GHz
>


Nice analysis.  I've previously wondered about such an effect from
resumptionTime being calculated by the high priority thread in
#handleTimerEvent: and thus delayed by switching threads, rather than being
calculated as-soon-as-possible by the low priority process when #schedule:
is called.   I can't remember my line of reasoning, but doing it the low
priority process seemed to open the potential for nasty race conditions, so
I left it as I found it.  Perhaps we should take a time snapshot in the
#schedule: and pass that through to #handleTimerEvent: similar to
scheduledDelay.  Would you like to try that?

btw, I have some cleanup of DelayScheduler almost complete that I had meant
to get into Pharo 5 earlier, but now I think best to wait for early Pharo 6.

cheers -ben

Re: [Pharo-dev] Loading an image crashes the VM

[Ben Coman]

On Tue, Mar 15, 2016 at 1:25 AM, Jan Kurš  wrote:
> Hi,
>
> I am trying to open an image I saved a few days ago and I am getting this
> message (the whole log is attached):
>
> stack page bytes 4096 available headroom 2788 minimum unused headroom 3020
>
> (Segmentation fault)
>
> Anyone experiencing something similar? I am running the latest pharo5 VM on
> Linux.
>
> Cheers,
> Jan

Something similar happened to me for the first time last night, about
three times in quick succession.  Seemed to be when I started an Image
from a shell and later killed it with control-C.  Incidentally, these
was with a recent Tracker image only an hour old for me, which had
locked while I was doing risky changes to DelayScheduler, but I was
surprised that it affected the Image on disk.  I was doing temporary
checkpoint saves just prior to Accepting risky code changes. Then upon
restart I got the error.  But I could not reliably reproduce the
problem.

Certainly it was not a large Image.

VM: http://files.pharo.org/vm/pharo-spur32/linux/463.zip
Image: 
https://ci.inria.fr/pharo/view/5.0-Analysis/job/Pharo-5.0-Issue-Tracker-Image/
Platform: Debian 8 Jessie 32-bit

cheers -ben

Re: [Pharo-dev] Changes Browser is broken

[Ben Coman]

I hadn't used Recover Changes for a while, but recently found that it
had lost a lot of power.  Particularly not being able to filter to
show only the most recent updates.  Its tedious to manually search for
the latest version of several methods.

cheers -ben

On Fri, Mar 18, 2016 at 6:30 AM, Peter Uhnák  wrote:
> Today I learned that you can actually lose code in Pharo because the record
> is not always added to the changes file.
>
> Also using the tool is quite a lot of pain, so if you want to recover your
> changes you have to do a lot of archaeology.
>
> I've added several issues and marked most of them as '2 - Really Important',
> because I think they are (especially for students etc that like to break
> things), but maybe you don't want it for Pharo 5.
>
> https://pharo.fogbugz.com/f/cases/17840/ChangesBrowser-selectAll-DNU
> https://pharo.fogbugz.com/f/cases/17841/Creating-a-class-from-a-debugger-during-compilation-doesn-t-create-a-record-in-changes-file
> https://pharo.fogbugz.com/f/cases/17842/Recover-lost-changes-doesn-t-recover-class-creation
> https://pharo.fogbugz.com/f/cases/17843/Changes-Browser-doesn-t-recover-changes-in-correct-order
>
> Peter
>
>

Re: [Pharo-dev] canc/del closes windows

[Ben Coman]

On Thu, Apr 7, 2016 at 8:56 PM, Davide Varvello via Pharo-dev
 wrote:
>
>
> -- Forwarded message --
> From: Davide Varvello 
> To: pharo-dev@lists.pharo.org
> Cc:
> Date: Thu, 7 Apr 2016 05:24:04 -0700 (PDT)
> Subject: Re: canc/del closes windows
> Hi Ben,
>
> With "it disappears" I intend that weird behaviour. It happens sometimes, I
> can't show you a screenshot because it's random.
>
> Usually, I'm on a system browser or on a playground and I hit the delete key
> and the window closes itself.
> If I'm lucky and I have just written something without saving and I click on
> the delete key, it appears the alert window: "Code has been modified. What
> do you want to do?", so I close the alert, click the cmd key and then I can
> click the delete key to cancel my writings.

Sorry nothing comes to mind.
btw, What version and VM are you on?
   World > System > System Reporter...

cheers -ben

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Ben Coman]

On Wed, Apr 6, 2016 at 4:36 PM, Igor Stasenko  wrote:
> That explains, why, there initially certain features of Cairo, that not
> exposed by Athens.
> It is not because we can't or just don't care.. we do.. But only after we
> can see that it consistent with rest of API and can be easily implemented on
> most of other potential backends.
> Yes, i am talking about that damn 'minimal common denominator' problem. :)
>
> Oh, and also i forgot to mention, that there could be also 2 more potential
> backends:
> - OpenVG
> and
> - Quartz, that is a vector graphics library for Mac OS

and Vulkan?

and thanks for writing up that explanation on Athens.

cheers -ben

Re: [Pharo-dev] canc/del closes windows

[Ben Coman]

On Thu, Apr 7, 2016 at 5:01 PM, Davide Varvello via Pharo-dev
 wrote:
>
>
> -- Forwarded message --
> From: Davide Varvello 
> To: pharo-dev@lists.pharo.org
> Cc:
> Date: Thu, 7 Apr 2016 01:29:21 -0700 (PDT)
> Subject: canc/del closes windows
> Hi Guys,
> Is it only me that sometimes hitting canc/del closes the current window?
>
> It's really annoying, I'm on a mac and I guess it's related to cmd button
> because if I click the cmd button afterward, it disappears (until next
> time).
>
> I tried also on several macs but the result is the same.

Hi David, I haven't used Pharo on a mac for a while, but I don't
remember experiencing this, though I can't quite picture your
scenario.  Could you provide a screen snapshot?  When you say "it"
disappears, could you clarify what "it" is?

cheers -ben

Re: [Pharo-dev] new pharo cheatsheet

[Ben Coman]

On Sat, Apr 9, 2016 at 3:52 PM, olivier auverlot
 wrote:
> I think that it could be interesting to use it also  on a simple HTML page
> for the Pharo web site. This document can be put in the main menu
> ("Beginners" ?) just before "Documentation".
>
> It's really cool to have a synthesis document for the newcomers.

I came across this a while ago and found it quite interesting...

   http://www2.ing.unipi.it/~a009435/issw/extra/readingSmalltalk.pdf

Re: [Pharo-dev] new pharo cheatsheet

[Ben Coman]

On Sat, Apr 9, 2016 at 3:56 AM, stepharo  wrote:
> new cheatsheet for Pharo syntax.
> Any feedback is welcome

So I really went to town and picked the eyes out of it...

> #(abc 123)
> literal array with the symbol #abc and the number 123

This one surprised me. I had to test it to check it was true.  It
doesn't seem very consistent.  Regardless of whether we *can* do it
like that, it would be more intuitive to be #(123 #abc).  But really,
should we even allow it?


> 12 2r1100 16rC
> twelve (decimal, binary, hexadecimal) floating-point numbers

The correspondence of the '2' of the '12 very close to the '2' of the
'2r' is a bit awkward.   Also I think we can take decimal numbers for
granted and its easier for people to immediately identify A=10 rather
than C=12, and lets not leave the meaning of 'r' implicit.  So perhaps
use
2r1010 16rA   binary and hexadecimal radix of 10


> {foo . 3 + 2}

Perhaps move the "declaration of two temporary variables" above this,
so foo it properly introduce foo as a variable rather than leaving it
implicit.  Otherwise from the literal array example it might be
inferred that foo is a symbol.

Also, the "expression separator" should be introduced before it is
used in the dynamic array.   So perhaps the dynamic array (or all
array) examples should be closer to the end.


> A method is invoked by sending a message to an object, the message receiver; 
> the message returns an object.

A message is an identifier for which objects provide methods of
implementation.  A method is invoked by sending a message to an
object. The object is the /receiver/ of the message.  The message
returns an object.


> Messages syntax mimics natural language

Message syntax mimics natural language


> Pharo: aColor r: 0.2 g: 0.3 b: 0

This is not very natural language.  We only need one Java/Pharo
example. Delete this one.


> Array new

You would never(?) really use that line.  So lets not mislead a
newcomer who might try it and get frustrated why they can't add items
to it.  OrderedCollection new is described later, so here perhaps
instead use...
   2 squared
   The receiver of the squared message is the object 2, with the
object 4 returned.


> A keyword message can take one or more arguments that are
inserted in the message name.

A keyword message can take one or more arguments that are
interspersed through the message name. (Put the example of this first,
i.e. #to:by: before #allButFirst:


> Precedence

Message Precedence


> Parentheses > unary > binary > keyword,

Is too concise.  I know the answer but I still feel awkward decoding
that line. Better...
Message sending order of precedence is: parentheses, unary,
binary, keyword, left to right.

> (10 between: 1 and: 2 + 4 * 3) not

Might be better to one more unary message...
(10 between: 1 and: 2 + 4 * 3 negated) not
The unary #negated message inside the parentheses is sent first,
then #+ as the left most binary message, followed by #*.   Then
keyword message #between:and: is sent, and finally #not.


> The rule suffers no exception: operators

The rule suffers no exception. Operators

> so 2 + 4 * 3 reads left-to-right and gives 18, not 14!

so 2 + 4 * 3 reads left-to-right and gives 18, not 14!

Note, comparison operators like equals = is just binary messages, so...
   1 * 3 = 3   produces boolean object true
but
3 = 3 * 1 produces an error, since a boolean object does not
understand multiplication.

Hint, while beginning with Pharo, make liberal us of parentheses in
calculations to make precedence explicit and thus easy to observe.


> OrderedCollection new
>add: #abc;
>add: #def;
>add: #ghi.

Rather than just mentioning needing to send #yourself in the text,
show the pattern more explicitly by putting it in the example...
  OrderedCollection new
add: #abc;
add: #def;
add: #ghi;
yourself.

The message new is sent to OrderedCollection which results in a new
collection to which three add: messages are sent. The value of the
whole message cascade is the value of the last
message sent, so without #yourself this would be the symbol #ghi.
With #yourself, the return value is {#abc.  #def.   #ghi}


> Blocks are objects containing code that is executed on demand,
> (anonymous functions). They are the basis for control structures
> like conditionals and loops.

Blocks are objects, that contain code to be executed on demand
(anonymous functions). They defined by square brackets and are
the basis for control structures like conditionals and loops.


> 2 = 2
>ifTrue: [Error signal: ’Help’].

Lets not mix in additional concepts.  How about...
  2 = 2 ifTrue: [self inform: 'Equal']

> The first example sends the message ifTrue: to the boolean
> true (computed from 2 = 2 ) with a block as argument.


>From 2 = 2 comes the boolean object true, to which the #ifTrue:
message is sent with the block as argument.  The object true always
evaluates #ifTrue: arguments, thus the text 

Re: [Pharo-dev] new pharo cheatsheet

[Ben Coman]

On Sat, Apr 9, 2016 at 6:16 AM, Damien Pollet  wrote:
> On 8 April 2016 at 22:57, Sven Van Caekenberghe  wrote:
>>
>> Since we are simpler and more logical, a cheat sheet should not confuse
>> people by describing what we are not.
>
>
> I beg to disagree. "Simpler and more logical" is just your biased point of
> view; fact is, zero-based indexing is just more widespread in programming
> languages.
>
> I would be happy to be proven wrong about that, but I seriously doubt most
> people that come to Smalltalk have never been exposed to programming before.
> It's not unreasonable to assume that they've started programming in any one
> of the most popular languages these days, and that that language is
> zero-indexed. So mentioning that in Smalltalk the first element is indeed at
> index 1 is pretty essential, if just to lift the ambiguity.

+1.  But to follow Sven's point exactly.  We don't need to say we are
"not 0 based", just that we are "1  based".

cheers -ben

Re: [Pharo-dev] [pharo-project/pharo-core] dbba45: 50646

[Ben Coman]

On Wed, Mar 16, 2016 at 8:36 PM, Esteban Lorenzano  wrote:
> On 16 Mar 2016, at 13:28, GitHub  wrote:
>
> 17797 random crash while trying to dispose a NULL handle
> https://pharo.fogbugz.com/f/cases/17797
>
>
>
> again, this is an attempt against the "Font crashing VM” bug… please I need
> all reports possible… even if you think is the same as before (even if IS
> the same as before).
>
> thanks!
> Esteban
>
>

I am using a fresh Tracker image per attached refresh.sh
Debian 8 Jessie 32-bit
Pharo5.0 Latest update: #50647
CoInterpreter VMMaker.oscog-eem.1726 Mar 15 2016 Jenkins build #576

After one refresh, after starting Image, in Playground and doing the
following several times...
   "[A]" ImageWorker do: [ 1 + 1] within: 2 seconds onTimeout: [ self
inform: 'timeout' ]

1. In parent did [A] and got...
  Error: External Image Failed: 34304
  ImageWorker>>handleForkedImageResultWithExitStatus:

2. In parent did [A] and got...
  Error: External Image Failed: 34304
  ImageWorker>>handleForkedImageResultWithExitStatus:

3. In parent did [A], and in child got...
  FT2Error: Freetype2 primitive failed [error 2][unknown file format]
  FreeTypeFace(FT2Handle)>>primitiveFailed:
  FreeTypeFace(FT2Handle)>>primitiveFailed
  FreeTypeFace(FT2Face)>>primNewFaceFromExternalMemory:size:index:
  FreeTypeFace(FT2Face)>>newFaceFromExternalMemory:index:
  FreeTypeFace>>create
  FreeTypeFace>>validate
  FreeTypeFont>>face
  FreeTypeFontProvider>>fontFor:familyName:
  LogicalFontManager>>bestFontFor:whenFindingAlternativeIgnoreAll:
  LogicalFontManager>>bestFontFor:
  LogicalFont>>findRealFont
  LogicalFont>>realFont
  LogicalFont>>installOn:foregroundColor:backgroundColor:
  FormCanvas>>drawString:from:to:in:font:color:
  FormCanvas(Canvas)>>drawString:in:

4. In parent did [A], and in child got...
  FT2Error: Freetype2 primitive failed [error 2][unknown file format]

5. In parent, did a save Tried to restart from command line got...
  primNewFaceFromExternalMemory:size:index:
  stack page bytes 4096 available headroom 2788 minimum unused headroom 3020
  (Segmentation fault)
 Aborted


refresh.sh
Description: Bourne shell script

Re: [Pharo-dev] [pharo-project/pharo-core] dbba45: 50646

[Ben Coman]

On Wed, Mar 16, 2016 at 8:36 PM, Esteban Lorenzano  wrote:
> On 16 Mar 2016, at 13:28, GitHub  wrote:
>
> 17797 random crash while trying to dispose a NULL handle
> https://pharo.fogbugz.com/f/cases/17797
>
> again, this is an attempt against the "Font crashing VM” bug… please I need
> all reports possible… even if you think is the same as before (even if IS
> the same as before).

   "[A]" ImageWorker do: [ 1 + 1] within: 2 seconds onTimeout: [ self
inform: 'timeout' ]

1. Ran refresh.sh per last post and opened Image.
2. Opened playground without adjusting native window.
3. Three times successfully inspected [A], seeing "2".
4. Opened Nautilus and a few more times successfully inspected [A], seeing "2".
5. Maximised native window
6. Inspecting [A] caused forked child to remain open with error
 FT2Error: Freetype2 primitive failed [error 2][unknown file format]

Re: [Pharo-dev] Naming question for new version of Mocketry

[Ben Coman]

On Wed, Mar 23, 2016 at 6:31 PM, Denis Kudriashov  wrote:
>
> 2016-03-23 11:02 GMT+01:00 Max Leske :
>>
>> But from English it not sounds like it should be occurred in past.

Normally thats my cue ;) but I don't have any great ideas.

>> So what correct and not long sentence can be used here? maybe:
>>
>> mock had received someMessage
>>
>>
>> mock should haveReceived someMessage
>>
>
> Thank's for suggestions. Thats idea from Marcus too. But it feels too long.
> But maybe. Now I actually already rename #receive to #haveReceived. But I
> hope for better sentence.
>>
>>
>> And same question for verification group of message sends (at the end of
>> test):
>>
>> [mock someMessage. mock2 someMessage2] should occur
>>
>> [mock someMessage. mock2 someMessage2] should occurInSameOrder
>>
>>
>> [ mock someMessage. mock2 somMessage2 ] should have beenSent
>
>
> It's long too. And I wish reduce number of separated words because it is not
> good practically.

Maybe...
   [ mock someMessage. mock2 somMessage2 ] shouldve beenSent

but maybe you don't want different #shouldXXX messages.

cheers -ben

> It raises more questions: how it is implemented, what the
> better name for intermediate object (result of have in that case) and
> others.
> At least your suggestion will be like
> [ mock someMessage. mock2 somMessage2 ] should haveBeenSent
>
> Another idea is to use #happen word:
> [ mock someMessage. mock2 somMessage2 ] should happen

Re: [Pharo-dev] Naming question for new version of Mocketry

[Ben Coman]

On Wed, Mar 23, 2016 at 8:39 PM, Denis Kudriashov <dionisi...@gmail.com> wrote:
>
> 2016-03-23 12:38 GMT+01:00 Ben Coman <b...@openinworld.com>:
>>
>> Maybe...
>>[ mock someMessage. mock2 somMessage2 ] shouldve beenSent
>>
>> but maybe you don't want different #shouldXXX messages.
>
>
> Thank you too, Ben. And yes it will not follow other should expressions. But
> it would not be bad to use completely different word instead of #should

Okay, then perhaps...

[mock someMessage. mock2 someMessage2] were sent
[mock someMessage. mock2 someMessage2] were sentInOrder

[mock someMessage. mock2 someMessage2] were done
[mock someMessage. mock2 someMessage2] were doneInOrder

but then do you also need singular #was for single items?


[mock someMessage. mock2 someMessage2] expect done
[mock someMessage. mock2 someMessage2] expect doneInOrder

Expect squeezes in usage in both future and past tense...
"I expect he'll arrive soon"
"I expect he went home"

cheers -ben

Re: [Pharo-dev] [Bloc] content vs contents

[Ben Coman]

On Sun, Mar 6, 2016 at 5:20 PM, stepharo  wrote:
> Hi native english speaker
>
> what is the best content or contents?

Actually I couldn't say off hand.  It depends on the context and I
can't think of a specific rule.  I can only present a few examples.

The contents of the box.
The content of the book - but the book has a Table Of Contents.

Probably just best to refer to the experts: "grammar content versus contents"

http://dictionary.cambridge.org/grammar/british-grammar/content-or-contents

http://english.stackexchange.com/questions/13556/content-or-contents

http://blogg.lnu.se/english-language-blog/blog/maria/content-and-contents/

cheers -ben

[Pharo-dev] Call about Numerical Methods in Pharo :)

[Ben Coman]

On Sun, Mar 6, 2016 at 5:05 AM, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>
>> On 05 Mar 2016, at 19:57, Ben Coman <b...@openinworld.com> wrote:
>>
>> On Sun, Mar 6, 2016 at 2:10 AM, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>>>
>>>> On 05 Mar 2016, at 18:22, Eliot Miranda <eliot.mira...@gmail.com> wrote:
>>>>
>>>> Stef,
>>>>
>>>> On Mar 5, 2016, at 12:10 AM, stepharo <steph...@free.fr> wrote:
>>>>
>>>>> You probably leave in a protected environment but I do not live in the 
>>>>> same.
>>>>> Did you check numPy recently or R? momemtum?
>>>>> Do you think that people do not know how to count?
>>>>> In 1980 my students were not even born, so how can it be better than
>>>>>python, java, c#, lua, ...
>>>>>
>>>>> Do you think that it makes me happy to see my old friends leaving our 
>>>>> language and do node.js.
>>>>> Seriously.
>>>>> Why do you blame me? Frankly tell to leave Pharo and I will leave. I can 
>>>>> tell you.
>>>>> I think that I need a break in my life in this moment so it would be a 
>>>>> good opportunity.
>>>>> Because if each time I do something to improve the wealth and visibility 
>>>>> of our system
>>>>> I get such kind of feedback then may be this is the time to do something.
>>>>> Afterall I may be wrong.
>>>>> Seriously if you think that I'm not doing a good job and you want to stay 
>>>>> with old friends
>>>>> just let me know. but if I stay then do not tell me that I'm an asshole 
>>>>> that does not want to
>>>>> promote smalltalk.
>>>>
>>>> I do not blame you.  I am offended by Pharo disavowing the Smalltalk name. 
>>>> I am offended when people state Pharo is not Smalltalk.  I want to refute 
>>>> false assumptions about the name Smalltalk, such as the equating it with 
>>>> cobol.  Instead of taking it personally why don't you address my points 
>>>> about older programming languages whose names (AFAICT) are not perceived 
>>>> negatively?
>>>>
>>>>
>>>> I support this community and am excited to participate in it.  I admire 
>>>> and respect your efforts, Stéphane, in developing, organizing and 
>>>> supporting this community.  But that does not mean I will keep quiet about 
>>>> something I profoundly disagree with and think is wrong.  And that thing 
>>>> is to deny Pharo is Smalltalk.
>>>>
>>>> And I do this not because I am a zealot, but because words meaning are 
>>>> important, because to understand each other we should call a spade a 
>>>> spade, and because I am grateful for and delighted by this thing called 
>>>> Smalltalk, and I will not support taking credit away from it.  Ruby is 
>>>> inspired by Smalltalk.  Pharo is the real thing.
>>>
>>> Pharo was started because a certain situation existed in the Squeak 
>>> community that blocked progress for a group of people that had another 
>>> vision. Pharo was started and exists to fulfil that grand vision, a vision 
>>> that is clearly rooted in Smalltalk history, but goes beyond that.
>>>
>>> If you want to focus on words, your sentence 'Pharo is Smalltalk' is not so 
>>> innocent or politically free, as you know very well, even if it looks like 
>>> factually correct (it is BTW).
>>>
>>> We say it differently because of what I just wrote, because we want to be 
>>> free of backwards compatibility (if necessary), because we want to have a 
>>> larger future than maintaining something old (even though we absolutely 
>>> respect and acknowledge it). Yes, it is a bit of a play of words, but not 
>>> without reason.
>>>
>>> Here is one writeup that tries to describe the same idea:
>>>
>>>  http://www.tudorgirba.com/blog/pharo-is-pharo
>>>
>>> But the best documents are the Pharo vision documents.
>>
>>
>> The counter argument is that there was Smalltalk-71, -72, -76, -78,
>> -80.   Some of these were distinctly different from the last.  So
>> Smalltalk was an *evolving* system.  Why can't it be so again!?  and
>> be Smalltalk-Renew, Smalltalk-Next, Smalltalk-Evolved, Smalltalk-16,
>> Smalltalk-P16 or Smalltalk-P5 "Pharo 5".
>>
>> As long as the em

Re: [Pharo-dev] [Bloc] content vs contents

[Ben Coman]

Sounds good. Stuart and Dimitris are spot on.
cheers -ben

On Sun, Mar 6, 2016 at 9:18 PM, stepharo <steph...@free.fr> wrote:
> This is for bloc so may be contents is better. I will check when it is used
> and if it returns a collection then we will
> rename it to contents.
> I would prefer contents if the majority of implementors use contents over
> content like that
> I have a smaller probability of mistakes.
>
> Stef
>
> Le 6/3/16 12:03, Ben Coman a écrit :
>
>> On Sun, Mar 6, 2016 at 5:20 PM, stepharo <steph...@free.fr> wrote:
>>>
>>> Hi native english speaker
>>>
>>> what is the best content or contents?
>>
>> Actually I couldn't say off hand.  It depends on the context and I
>> can't think of a specific rule.  I can only present a few examples.
>>
>> The contents of the box.
>> The content of the book - but the book has a Table Of Contents.
>>
>> Probably just best to refer to the experts: "grammar content versus
>> contents"
>>
>>
>> http://dictionary.cambridge.org/grammar/british-grammar/content-or-contents
>>
>> http://english.stackexchange.com/questions/13556/content-or-contents
>>
>> http://blogg.lnu.se/english-language-blog/blog/maria/content-and-contents/
>>
>> cheers -ben
>>
>>
>
>

Re: [Pharo-dev] Call about Numerical Methods in Pharo :)

[Ben Coman]

On Sat, Mar 5, 2016 at 11:32 PM, Serge Stinckwich
<serge.stinckw...@gmail.com> wrote:
> On Sat, Mar 5, 2016 at 4:22 PM, Ben Coman <b...@openinworld.com> wrote:
>> On Sat, Mar 5, 2016 at 4:14 AM, Serge Stinckwich
>> <serge.stinckw...@gmail.com> wrote:
>>> On Fri, Mar 4, 2016 at 8:44 PM, Nicolas Cellier
>>> <nicolas.cellier.aka.n...@gmail.com> wrote:
>>>>
>>>> 2016-03-04 19:51 GMT+01:00 Alexandre Bergel <alexandre.ber...@me.com>:
>>>>>
>>>>> I personally never liked the name “SciSmalltalk”. “SciPharo” is much
>>>>> better in my opinion
>>>>> PhaNum is also okay to me.
>>>>>
>>>>
>>>> SciSmalltalk is ugly.
>>>
>>> I don't like the name either. We will find a better sexy name !
>>
>> Just a random line of thought...
>> PhaNum --> NumPha --> numcha --> numchi
>> --> numqi "An energy around numbers"
>>
>> https://en.wikipedia.org/wiki/Qi
>
> Nice !
>
> Any other ideas ?

Well, since you asked...  Another approach is to consider who the
biggest competitor is - the one you'd like to be compared to and would
like to beat. Maybe its Julia(?), which currently got some buzz.  From
a cursory skim, its multiple dispatch, dynamic typing and Scheme &
Common Lisp influences [1] somewhat echoes Smalltalk.   We have
similar facility as [2] to already inspect method bytecode and I
reckon we might(?) be able to provide a view of the JITed machine code
and might(?) be possible someday be able to hand-tune that machine
code, which would be good to promote our system as a similar
one-stop-shop as described in [2].

So... along the philosophy that when a fight is starting, you should
*first* punch the *biggest* guy on the nose... you could be
provocative and name it Gaston or Fatou [3], except then I discover
the Julia name apparently has nothing to do with Julia Sets [4].
So maybe Julia --> Juliet --> Romeo --> { Romiio, Romiea, Romiia,
Rhomia }  -- these being a selection of variations with high
goognique**.  However, on the one hand, we'd need to gain the
credibility to back this up, but on the other hand, its not just about
punching some on the nose... such naming can be aspirational.  The
research presented by Jim Collins in"Good To Great" advises its quite
beneficial to have an adversary you can compete against in a
*friendly* way.

[1] https://en.wikipedia.org/wiki/Julia_(programming_language)
[2] http://www.evanmiller.org/why-im-betting-on-julia.html
[3] https://en.wikipedia.org/wiki/Julia_set
[4] 
http://stackoverflow.com/questions/29290780/what-does-the-name-of-julia-the-programming-language-refer-to

** My this instant newly contrived portmanteau for "google unique".

Re: [Pharo-dev] Call about Numerical Methods in Pharo :)

[Ben Coman]

On Sun, Mar 6, 2016 at 12:57 AM, Eliot Miranda <eliot.mira...@gmail.com> wrote:
>
>
>> On Mar 5, 2016, at 7:34 AM, Serge Stinckwich <serge.stinckw...@gmail.com> 
>> wrote:
>>
>> I was thinking as this name : Abacus
>>
>> https://en.wikipedia.org/wiki/Abacus
>> A calculating tool !
>
> Good!

But "abacus" --> 18,000,000 results, is not goognique.

Maybe a variation "abacii" --> 2,800 results, as in "more than one
calculating tool".

cheers -ben

>>
>> On Sat, Mar 5, 2016 at 4:22 PM, Ben Coman <b...@openinworld.com> wrote:
>>> On Sat, Mar 5, 2016 at 4:14 AM, Serge Stinckwich
>>> <serge.stinckw...@gmail.com> wrote:
>>>> On Fri, Mar 4, 2016 at 8:44 PM, Nicolas Cellier
>>>> <nicolas.cellier.aka.n...@gmail.com> wrote:
>>>>>
>>>>> 2016-03-04 19:51 GMT+01:00 Alexandre Bergel <alexandre.ber...@me.com>:
>>>>>>
>>>>>> I personally never liked the name “SciSmalltalk”. “SciPharo” is much
>>>>>> better in my opinion
>>>>>> PhaNum is also okay to me.
>>>>>
>>>>> SciSmalltalk is ugly.
>>>>
>>>> I don't like the name either. We will find a better sexy name !
>>>
>>> Just a random line of thought...
>>> PhaNum --> NumPha --> numcha --> numchi
>>> --> numqi "An energy around numbers"
>>>
>>> https://en.wikipedia.org/wiki/Qi
>>>
>>> cheers -ben
>>>
>>>>> Currently, there is no package named SciSmalltalk.
>>>>> SciSmalltalk is just:
>>>>> - an aggregate of packages (a metacello configuration)
>>>>> - a repository (github + Smalltalkhub)
>>>>
>>>> SciSmalltalk is a bit more than just a few packages ...
>>>> We have tests, we have a CI job, we have a book.
>>>>
>>>> --
>>>> Serge Stinckwich
>>>> UCBN & UMI UMMISCO 209 (IRD/UPMC)
>>>> Every DSL ends up being Smalltalk
>>>> http://www.doesnotunderstand.org/
>>
>>
>>
>> --
>> Serge Stinckwich
>> UCBN & UMI UMMISCO 209 (IRD/UPMC)
>> Every DSL ends up being Smalltalk
>> http://www.doesnotunderstand.org/
>>
>

Re: [Pharo-dev] Call about Numerical Methods in Pharo :)

[Ben Coman]

On Sun, Mar 6, 2016 at 12:59 AM, Ben Coman <b...@openinworld.com> wrote:
> On Sat, Mar 5, 2016 at 11:32 PM, Serge Stinckwich
> <serge.stinckw...@gmail.com> wrote:
>> On Sat, Mar 5, 2016 at 4:22 PM, Ben Coman <b...@openinworld.com> wrote:
>>> On Sat, Mar 5, 2016 at 4:14 AM, Serge Stinckwich
>>> <serge.stinckw...@gmail.com> wrote:
>>>> On Fri, Mar 4, 2016 at 8:44 PM, Nicolas Cellier
>>>> <nicolas.cellier.aka.n...@gmail.com> wrote:
>>>>>
>>>>> 2016-03-04 19:51 GMT+01:00 Alexandre Bergel <alexandre.ber...@me.com>:
>>>>>>
>>>>>> I personally never liked the name “SciSmalltalk”. “SciPharo” is much
>>>>>> better in my opinion
>>>>>> PhaNum is also okay to me.
>>>>>>
>>>>>
>>>>> SciSmalltalk is ugly.
>>>>
>>>> I don't like the name either. We will find a better sexy name !
>>>
>>> Just a random line of thought...
>>> PhaNum --> NumPha --> numcha --> numchi
>>> --> numqi "An energy around numbers"
>>>
>>> https://en.wikipedia.org/wiki/Qi
>>
>> Nice !
>>
>> Any other ideas ?
>
> Well, since you asked...  Another approach is to consider who the
> biggest competitor is - the one you'd like to be compared to and would
> like to beat. Maybe its Julia(?), which currently got some buzz.  From
> a cursory skim, its multiple dispatch, dynamic typing and Scheme &
> Common Lisp influences [1] somewhat echoes Smalltalk.   We have
> similar facility as [2] to already inspect method bytecode and I
> reckon we might(?) be able to provide a view of the JITed machine code
> and might(?) be possible someday be able to hand-tune that machine
> code, which would be good to promote our system as a similar
> one-stop-shop as described in [2].
>
> So... along the philosophy that when a fight is starting, you should
> *first* punch the *biggest* guy on the nose... you could be
> provocative and name it Gaston or Fatou [3], except then I discover
> the Julia name apparently has nothing to do with Julia Sets [4].
> So maybe Julia --> Juliet --> Romeo --> { Romiio, Romiea, Romiia,
> Rhomia }  -- these being a selection of variations with high
> goognique**.  However, on the one hand, we'd need to gain the
> credibility to back this up, but on the other hand, its not just about
> punching some on the nose... such naming can be aspirational.  The
> research presented by Jim Collins in"Good To Great" advises its quite
> beneficial to have an adversary you can compete against in a
> *friendly* way.
>
> [1] https://en.wikipedia.org/wiki/Julia_(programming_language)
> [2] http://www.evanmiller.org/why-im-betting-on-julia.html
> [3] https://en.wikipedia.org/wiki/Julia_set
> [4] 
> http://stackoverflow.com/questions/29290780/what-does-the-name-of-julia-the-programming-language-refer-to
>
> ** My this instant newly contrived portmanteau for "google unique".

And btw, it might be good to pick the eyes out of this discussion on
Julia for points where do (or will) align and use similar language to
promote our Numqi/Abacii system.
https://news.ycombinator.com/item?id=7109982

cheers -ben

Re: [Pharo-dev] [Pharo-users] Little how to

[Ben Coman]

On Sat, Mar 5, 2016 at 11:14 PM, stepharo  wrote:
> I would love one example fetch something using Zinc and check the network
> status.
> I remember once I played with Pop and I wa sfetching mails one by one :)

This could be a good one.  Occasionally when I'm troubleshooting email
problems I resort to basic telnet access [1][2]
But its harder to do this using SSL. Just now I found [3] but I
haven't tried it.

[1] http://www.anta.net/misc/telnet-troubleshooting/pop.shtml
[2] http://arnab.org/notes/accessing-mail-using-pop-and-telnet
[3] 
http://blog.yimingliu.com/2009/01/23/testing-a-pop3-server-via-telnet-or-openssl/

cheers -ben

>
>
> Le 5/3/16 12:11, Tudor Girba a écrit :
>
>> Hi,
>>
>> Let’s take this opportunity to spawn more of these problems. Feel free to
>> shoot them around and I will try to provide the scenario to program more
>> live. What do you think?
>>
>> Cheers,
>> Doru
>>
>>
>>> On Mar 5, 2016, at 10:18 AM, stepharo  wrote:
>>>
>>> So cl, it was on my todo with my son.
>>> --- this is really true, he came and told me I want to build my own
>>> game...
>>> And we do not have a game framework in our community --- at least one
>>> that I understand.
>>> So I was looking at Ruby or JS :(
>>>
>>> And clement show me the link and how he extracted the png.
>>> So we will do that this afternoon and add this as a challenge for the
>>> mooc
>>> I should have got faster :).
>>>
>>>
>>> Le 3/3/16 22:58, Tudor Girba a écrit :

 Hi,

 I wrote a little post with a how to extract sprites from a larger png
 file:
 http://www.humane-assessment.com/blog/extracting-sprite-from-png

 Cheers,
 Doru


> On Mar 3, 2016, at 9:23 AM, stepharo  wrote:
>
> Hi guys
>
> for the mooc I would like have a list of how to that students should
> look in the system and implement.
> The idea is to show to the participants that Pharo is open and that
> they can find information.
> For example,
> - extracting a sprite from a png file
> - access a time service of the web
>
> Now I would love to get your ideas and their solution.
>
> Stef
>
>
>
 --
 www.tudorgirba.com
 www.feenk.com

 "Beauty is where we see it."






>>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "If you can't say why something is relevant,
>> it probably isn't."
>>
>>
>>
>
>

Re: [Pharo-dev] Call about Numerical Methods in Pharo :)

[Ben Coman]

On Sat, Mar 5, 2016 at 4:14 AM, Serge Stinckwich
 wrote:
> On Fri, Mar 4, 2016 at 8:44 PM, Nicolas Cellier
>  wrote:
>>
>> 2016-03-04 19:51 GMT+01:00 Alexandre Bergel :
>>>
>>> I personally never liked the name “SciSmalltalk”. “SciPharo” is much
>>> better in my opinion
>>> PhaNum is also okay to me.
>>>
>>
>> SciSmalltalk is ugly.
>
> I don't like the name either. We will find a better sexy name !

Just a random line of thought...
PhaNum --> NumPha --> numcha --> numchi
--> numqi "An energy around numbers"

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

cheers -ben

>> Currently, there is no package named SciSmalltalk.
>> SciSmalltalk is just:
>> - an aggregate of packages (a metacello configuration)
>> - a repository (github + Smalltalkhub)
>
> SciSmalltalk is a bit more than just a few packages ...
> We have tests, we have a CI job, we have a book.
>
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
>

Re: [Pharo-dev] Call about Numerical Methods in Pharo :)

[Ben Coman]

On Sun, Mar 6, 2016 at 2:10 AM, Sven Van Caekenberghe  wrote:
>
>> On 05 Mar 2016, at 18:22, Eliot Miranda  wrote:
>>
>> Stef,
>>
>> On Mar 5, 2016, at 12:10 AM, stepharo  wrote:
>>
>>> You probably leave in a protected environment but I do not live in the same.
>>> Did you check numPy recently or R? momemtum?
>>> Do you think that people do not know how to count?
>>> In 1980 my students were not even born, so how can it be better than
>>> python, java, c#, lua, ...
>>>
>>> Do you think that it makes me happy to see my old friends leaving our 
>>> language and do node.js.
>>> Seriously.
>>> Why do you blame me? Frankly tell to leave Pharo and I will leave. I can 
>>> tell you.
>>> I think that I need a break in my life in this moment so it would be a good 
>>> opportunity.
>>> Because if each time I do something to improve the wealth and visibility of 
>>> our system
>>> I get such kind of feedback then may be this is the time to do something.
>>> Afterall I may be wrong.
>>> Seriously if you think that I'm not doing a good job and you want to stay 
>>> with old friends
>>> just let me know. but if I stay then do not tell me that I'm an asshole 
>>> that does not want to
>>> promote smalltalk.
>>
>> I do not blame you.  I am offended by Pharo disavowing the Smalltalk name.  
>> I am offended when people state Pharo is not Smalltalk.  I want to refute 
>> false assumptions about the name Smalltalk, such as the equating it with 
>> cobol.  Instead of taking it personally why don't you address my points 
>> about older programming languages whose names (AFAICT) are not perceived 
>> negatively?
>>
>>
>> I support this community and am excited to participate in it.  I admire and 
>> respect your efforts, Stéphane, in developing, organizing and supporting 
>> this community.  But that does not mean I will keep quiet about something I 
>> profoundly disagree with and think is wrong.  And that thing is to deny 
>> Pharo is Smalltalk.
>>
>> And I do this not because I am a zealot, but because words meaning are 
>> important, because to understand each other we should call a spade a spade, 
>> and because I am grateful for and delighted by this thing called Smalltalk, 
>> and I will not support taking credit away from it.  Ruby is inspired by 
>> Smalltalk.  Pharo is the real thing.
>
> Pharo was started because a certain situation existed in the Squeak community 
> that blocked progress for a group of people that had another vision. Pharo 
> was started and exists to fulfil that grand vision, a vision that is clearly 
> rooted in Smalltalk history, but goes beyond that.
>
> If you want to focus on words, your sentence 'Pharo is Smalltalk' is not so 
> innocent or politically free, as you know very well, even if it looks like 
> factually correct (it is BTW).
>
> We say it differently because of what I just wrote, because we want to be 
> free of backwards compatibility (if necessary), because we want to have a 
> larger future than maintaining something old (even though we absolutely 
> respect and acknowledge it). Yes, it is a bit of a play of words, but not 
> without reason.
>
> Here is one writeup that tries to describe the same idea:
>
>   http://www.tudorgirba.com/blog/pharo-is-pharo
>
> But the best documents are the Pharo vision documents.


The counter argument is that there was Smalltalk-71, -72, -76, -78,
-80.   Some of these were distinctly different from the last.  So
Smalltalk was an *evolving* system.  Why can't it be so again!?  and
be Smalltalk-Renew, Smalltalk-Next, Smalltalk-Evolved, Smalltalk-16,
Smalltalk-P16 or Smalltalk-P5 "Pharo 5".

As long as the emphasis is on Pharo being an *evolution* of Smalltalk
(which is not in doubt), I think we cover all bases - stimulating the
interest of newcomers and/or detractors of old, as well as Smalltalk
stalwarts without being constrained by the past.  As much as we might
want to promote Pharo being separate from Smalltalk (which I believe
was a reasonable strategy to establish identity at the time of the
fork from Squeak), Smalltalk is always going to be there for anyone
who scratches beneath the surface and they  end up thinking "Oh its
*just* Smalltalk" anyway.  So this remains the "elephant in the room",
*subtly* undermining of our marketing.  Its the sort of weakness that
can be better to hit head on as "Smalltalk-Evolved" (since "Evolved"
is a term with positive connotations in the gaming / sci-fi
communities.)

cheers -ben


>
>>> Stef
>>>
>>> Le 5/3/16 02:18, Eliot Miranda a écrit :


 On Fri, Mar 4, 2016 at 12:08 PM, stepharo  wrote:

> SciPharo? Not so great news from my POV.
> What is so much pharo specific in this library?
> Is Smalltalk scientific community large enough for yet another split?
 Split of what? Let us be tagged with a name of 1980 and die in peace. Yes 
 this looks like a
 smart move.
 There are just Python 

Re: [Pharo-dev] Pharo Contributors & Consultants

[Ben Coman]

Cool.  Now wishful thinking... for consultants it would be double-cool
be have a location marked world map which could be clicked to sort the
list based on how close to the click the consultant lives.
cheers -ben

On Wed, Mar 2, 2016 at 5:04 PM, Peter Uhnák  wrote:
> Hi all,
>
> we are currently updating the pages for Pharo Contributors and Consultants.
>
> https://consultants.pharo.org/
> and
> https://contributors.pharo.org/
>
> if you want to add or update your record (info, mail, image, ...), you can
> do so by sending us a pull request on GitHub in the appropriate repository
>
> the format is STON so it should be understandable.
>
> Contributors: https://github.com/pharo-project/pharo-project-contributors
> Consultants: https://github.com/pharo-project/pharo-project-consultants
>
> Alternatively you can open an issue in the github issue tracker with the new
> info and it will be handled.
>
> Peter

Re: [Pharo-dev] Pharo Contributors & Consultants

[Ben Coman]

Also, maybe add "Pharo" to the contributors default web site  google search.

On Wed, Mar 2, 2016 at 7:44 PM, Ben Coman <b...@openinworld.com> wrote:
> Cool.  Now wishful thinking... for consultants it would be double-cool
> be have a location marked world map which could be clicked to sort the
> list based on how close to the click the consultant lives.
> cheers -ben
>
> On Wed, Mar 2, 2016 at 5:04 PM, Peter Uhnák <i.uh...@gmail.com> wrote:
>> Hi all,
>>
>> we are currently updating the pages for Pharo Contributors and Consultants.
>>
>> https://consultants.pharo.org/
>> and
>> https://contributors.pharo.org/
>>
>> if you want to add or update your record (info, mail, image, ...), you can
>> do so by sending us a pull request on GitHub in the appropriate repository
>>
>> the format is STON so it should be understandable.
>>
>> Contributors: https://github.com/pharo-project/pharo-project-contributors
>> Consultants: https://github.com/pharo-project/pharo-project-consultants
>>
>> Alternatively you can open an issue in the github issue tracker with the new
>> info and it will be handled.
>>
>> Peter

Re: [Pharo-dev] sprites for games

[Ben Coman]

hey wow! who'd a thought such a thing existed.
cheers -ben

On Wed, Mar 2, 2016 at 9:33 PM, stepharo  wrote:
> Hi
>
> clement shows me this website
>
> http://gaurav.munjal.us/Universal-LPC-Spritesheet-Character-Generator/
>
> and we could use them for building a fun game framework
>
>
> Stef
>
>

Re: [Pharo-dev] Catching Exceptions without any notice

[Ben Coman]

All forms of learning involve some degree criticism, and sometimes we
learn the most from the hardest task masters.

We all want a positive community, but we need to not fall into the
trap of... "hacker forums where, out of some misguided sense of
hyper-courtesy, participants are banned from posting any fault-finding
with another's posts, and told “Don't say anything if you're unwilling
to help the user.” The resulting departure of clueful participants to
elsewhere causes them to descend into meaningless babble and become
useless as technical forums.  Exaggeratedly “friendly” (in that
fashion) or useful: Pick one.   "
[http://www.catb.org/esr/faqs/smart-questions.html]

Its a balance to weave, but lets not be too quick on the trigger to
impede someone's natural flow of thoughts.  If too much burden is
imposed to craft "cheerful" criticism, we might lose its contribution
and the chance to learn.

I learnt something from Igor's post.

cheers -ben


On Sat, Apr 2, 2016 at 6:07 AM, Tudor Girba  wrote:
> Hi Igor,
>
> You are more than welcome to come back.
>
> Too much acidity is good neither for you nor for the people around you :). 
> Let’s be kind with one another and assume that we all care and we want to 
> make this world a better place, but that at the same time we are still only 
> humans.
>
> Cheers,
> Doru
>
>
>
>> On Apr 1, 2016, at 10:51 PM, Igor Stasenko  wrote:
>>
>>
>>
>> On 1 April 2016 at 09:53, Tudor Girba  wrote:
>> Hi,
>>
>> Nice to hear from you Igor. I am glad to see you around here.
>>
>> Hi, Doru. Yeah, i am considering whether i want to return to things i left, 
>> or not. So, expect more of my acid sarcasm in future. Maybe :)
>>
>> I do not see how your quote applies to the current case given that the 
>> original authors did not leave anywhere, but perhaps it was a joke, and I 
>> did not get it.
>>
>> We all will leave sooner or later. The only what matters is what we left 
>> behind :)
>>
>> Cheers,
>> Doru
>>
>>
>> > On Apr 1, 2016, at 5:54 AM, Igor Stasenko  wrote:
>> >
>> > A perfect example of careless programming.
>> > "I'll do it my way, and if it causing any problems, i don't care and i 
>> > will just ignore them. And it's not my problem anyways, i went to 
>> > something else already, since this part is works and DONE"
>> > :)
>> >
>> > On 30 March 2016 at 14:33, Nicolai Hess  wrote:
>> > Please don't do this:
>> >
>> > updateHeight
>> > "no need to care about height, when it's logic is not customized"
>> > self layout isHeightCustom ifFalse: [ ^ self ].
>> > [ self bounds: (self brickBounds withHeight: self customHeight) ]
>> > on: Exception
>> > do: [ "just skip and do nothing" ]
>> >
>> > This makes debugging GLM/Brick ui/layout code with "self haltOnce" 
>> > impossible.
>> > see
>> > GLMBrickGeometryTrait>>#updateHeight
>> > GLMBrickGeometryTrait>>#updateWidth
>> >
>> > And if you log out the raised exception, you see some calls to
>> > not initialized fonts and a ZeroDevide and some more errors.
>> > The above catch, catches and hides wrong / to late initialized objects.
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Igor Stasenko.
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "No matter how many recipes we know, we still value a chef."
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "It's not how it is, it is how we see it."
>
>

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Ben Coman]

On Tue, Apr 5, 2016 at 2:51 AM, Igor Stasenko  wrote:
>
> Some more bashing today.. (don't take it personal, i may be wrong)
>
> BlPath hierarchy.. and BlShape.
>
> Why you redefining what is shape and what is path?
> Of course, you are free to do it in Bloc..
> But in terms of Athens, all of BlPath are actually - shapes..
> And BlShape is some kind of encapsulation of shape, paints and transform.
> It is a dumb state holder without any extra logic.
>
> My rule of thumb: do not produce dumb state holders. They has to be smart,
> else it makes no sense in creating separate entity and designating it as
> something else than any other bunch of data thrown into single clump,
> sitting there deaf, blind, dead and silent until someone else will grab it
> somewhere
> and start using it for own purpose.
>
> Sure, i could understand, why you potentially may want such object(s)
> around,
> but it is not shape anymore and i wouldn't call it like that. Because shape
> are shape, and has nothing to do with paints and transform,
> it don't knows and don't cares whether it will be filled or stroked or both,
>  and how many times, and if there will be single paint or thousand.
> Such kind of properties is simply orthogonal to what shape existing for,
> because it exists only to define geometry.
>
> I think all of that came from not understanding the roles of objects and how
> they interact in Athens.

Can you point us to documentation that describes Athen's architecture
for these interactions?
(sorry I haven't checked class comments, but I'm looking to start with
something at higher level anyway)

cheers -ben

Re: [Pharo-dev] TxText model

[Ben Coman]

On Mon, Apr 4, 2016 at 9:49 PM, Igor Stasenko  wrote:
>
>
> On 4 April 2016 at 16:32, Thierry Goubier  wrote:
>>
>>
>>
>> 2016-04-04 15:23 GMT+02:00 Igor Stasenko :
>>>
>>>

>>> Analogies don't work. Right :) I never used Pillar and have remote ideas
>>> about what it does or requires. From that perspective you appeal to wrong
>>> person. On your place i would be asking a guy who knows Pillar innards about
>>> it.

Please see...

[1] http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf

[2] 
https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html

Most (all?) of docs at [3] are done using Pillar...
[3] https://github.com/SquareBracketAssociates

cheers -ben

Re: [Pharo-dev] What the state of unifying Beacon with SystemLogger?

[Ben Coman]

Sorry for not having a better reviewed understanding of both
frameworks, but I have some thoughts from perspective of one user...

On Thu, Apr 21, 2016 at 12:05 AM, Denis Kudriashov  wrote:
> Hi.
>
> Thank's for answers.
>
> 2016-04-20 10:53 GMT+02:00 Norbert Hartl :
>>
>> Agreed. As I said above. If you take to point of view from legacy logging
>> tool Beacon is not a big help. But the ideas in it are good and should be
>> integrated somewhere. If you are talking about legacy tooling it might ok to
>> use the terms logging as well, no? I personally like the work Beacon but in
>> my opinion it is  wrong for this purpose. A beacon sends a uniform signal in
>> order to be discovered. The Beacon code sends signals to a beacon. And I can
>> register at the beacon in which signals I'm interested in. Feels wrong to
>> me.
>
>
> Your words are reasonable. Interesting what Tudor think about it?
>
> There are few things which I not like in SystemLogger (which not means that
> everything is good with Beacon):
>
> name Log to represent records of the underlying "physical log".
>
> IMHO Log means exactly end logging backend like text file, syslog or
> external database. Log is the place where we can explore (read) what was
> happen.

You are considering Log as a noun, but it can also be used as a verb.
defn "13. to enter in a log; keep a record of; e.g. to log a day's events." [1]

Stef said: "Remember that you want to have them short especially for
the main one. This is why in SystemLogger
we have Log instead of what it is LogObject"
from which I understood that Log was the client interface, to be used
like Transcript.  I think this is a good idea.  It would create the
LogEntry

[1] http://www.dictionary.com/browse/log

> And now these backends are represented by subclasses of Logger:
> StdoutStreamLogger, SysLogSender. I would call them StdoutLog, SysLog.
> But with such change we need to call log entry differently. It can be
> LogRecord or LogEntry. I not understand what was the problem with such
> names? (there was some explanation why Log was chosen for this)

Considering a "log" being the final resting point of the logged
objects, that is the external disk text file or database, then within
Pharo we don't have logs, only processes that write to the external
logs, so Logger seems appropriate.  This is except for an in memory
log, which for backend might need both MemoryLogger and
MemoryObjectLog.

Log would create and send theLogEntry to SystemLogger
which forwards theLogEntry to other registered XXXLogger backend.

> name SystemLogger for collection based log.
>
> SystemLogger makes me think that it is singleton which is used by system and
> I should not use it for my own application.

I guess your application would make use SystemLogger via Log at the
front end, and registering backends with SystemLogger.

> I would call it like ObjectLog or NativeLog (following my first sentence
> about Log).

NativeLog doesn't seems right.  ObjectLog might be suitable for an
in-memory backend, like above I mention MemoryObjectLog.

> Also it is intercepted with SysLog name and I guess that's why it was called
> SysLogSender and not SysLogLogger.
>
> name LogDispatcher.

LogDispatcher is okay, but I'm not sure of convention to be associate
the "doer" with the "target" rather than the "item", where
doer=Dispatcher; item=LogEntry; target=final-backend-log;   A little
it sounds like its dispatching a whole log rather than one log entry.
Maybe should be LogEntryDispatcher(??) or... SystemLogger as the
marshalling point to forward to other XXXLoggers.

>
> Here same problem as Log. What means physical logs dispatching? I know it is
> introduced around Log as log entry. But it is not intuitive for me (same as
> Log).

I don't think Log should be a log entry.  It should be the user
interface that creates and sends LogEntries via some XXXLogger.

> In context of Log as real log (FileLog, SysLog) I would call this dispatcher
> as Logger with same responsibility to register new events in all registered
> logs.
>
>
> announcements LogAdded and LogRemoved in the core.
>
> Why any Logger should announce every log entry?
> I think we not need special LoggerUI app. We can just inspect SystemLogger
> instance to look at all recorded objects. And in perspective of my
> suggestions it will mean that we just explore particular ObjectLog. And we
> can extend GTInspector for this.

GTInspector would need good live updating, filtering, clearing,
scrolling to keep cursor position as new entries arrive.

cheers -ben

Re: [Pharo-dev] [Pharo 5] Symbol #'distance_2pts' not accepted at package installation

[Ben Coman]

On Mon, Apr 25, 2016 at 4:03 AM, Stephan Eggermont  wrote:
> On 24-04-16 21:35, stepharo wrote:
>>
>>
>>
>> Le 24/4/16 à 12:10, Hilaire a écrit :
>>>
>>> Hi Nicolai,
>>>
>>> http://smalltalkhub.com/#!/~HilaireFernandes/DrGeo
>>>
>>> You can't use the installation procedure described in the wiki, because
>>> Pharo5 also got stuck when loading a dependent package (gettext package
>>> to name it).
>>
>> From where do you load gettext because I can have a look.
>> Your work is important to me :)
>
>
> It is a simple, but annoying problem. A symbol with whitespace between the
> # and the literal is no longer accepted by RBScanner>scanLiteral

That seems a bad regression, to break loading code that
loads fine with Pharo 4, and could be a common scenario.

>
> scanLiteral
> "Do not allow whitespace between # and the literal."
>
> "Do not allow number literals after the #"
>
> self step.
> characterType = #alphabetic
> ifTrue: [ ^ self scanSymbol ].
> characterType = #binary
> ifTrue:
> [ ^ (self scanBinary: RBLiteralToken)
> stop: self previousStepPosition ].
> currentCharacter = $'
> ifTrue: [ ^ self scanStringSymbol ].
> (currentCharacter = $( or: [ currentCharacter = $[ ])
> ifTrue: [ ^ self scanLiteralArrayToken ].
> "Accept multiple #."
> currentCharacter = $#
> ifTrue: [ ^ self scanLiteral ].
> ^ self scanError: 'Expecting a literal type'
>
> vs
>
> scanLiteral
> self step.
> self stripSeparators.
> characterType = #alphabetic
> ifTrue: [ ^ self scanSymbol ].
> characterType = #binary
> ifTrue: [ ^ (self scanBinary: RBLiteralToken) stop: self
> previousStepPosition ].
> currentCharacter = $'
> ifTrue: [ ^ self scanStringSymbol ].
> (currentCharacter = $( or: [ currentCharacter = $[ ])
> ifTrue: [ ^ self scanLiteralArrayToken].
> "Accept some strange literals like '#1', '# species' and '##species:'"
> characterType = #digit
> ifTrue: [ ^ self scanNumber ].
> currentCharacter = $#
> ifTrue: [ ^ self scanLiteral ].
> ^self scanError: 'Expecting a literal type' translated.
>
> The problem is that recovering from that while loading code asks for
> rather well-developed debugging skills... It is faster to just load the code
> in an old Pharo image, fix it there and commit a new version

Wouldn't you then have the problem of manually tracking down
that space in your codebase ?

Is it feasible to have a setting for compatibility so old code can at
least be loaded in Pharo 5? Then a re-compilation with setting
disabled would directly identify the error to be fixed.   Maybe even
Monticello could always temporarily enable the setting while loading -
with that behaviour removed for Pharo 6.

cheers -ben

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

[Ben Coman]

On Sat, May 21, 2016 at 12:05 AM, Mariano Martinez Peck
 wrote:
> Ben, for the record, I am using DelayMillisecondScheduler for a day and a
> half and so far no problem.

Cool. Thats why I left it there. I hope to soon have something for you
to try with the newer design. Thanks for the update.

cheers -ben

> On Thu, May 19, 2016 at 9:19 AM, Mariano Martinez Peck
>  wrote:
>>
>>
>>
>> On Wed, May 18, 2016 at 9:49 PM, Martin McClure 
>> wrote:
>>>
>>> On 05/18/2016 03:17 PM, Martin McClure wrote:

 On 05/18/2016 08:49 AM, Mariano Martinez Peck wrote:
>
> Hi guys,
>
> I am seeing a problem in Pharo 5.0 regarding Delay >> wait. I cannot
> explain how this could happened but it does, and it happened to me a 
> couple
> of times (but not fully reproducible).
>

 Hmm. The schedulerResumptionTime is, somehow, being (approximately)
 doubled. It's not clear how that can happen, but I'll look a little more.

>>>
>>> Mario, is there any chance that you might be saving the image during one
>>> of these Delays?
>>>
>>>
>>> This one smells like a race condition, and I think I see something that
>>> *might* explain it. But I don't have any more time to spend on this one, so
>>> I'll leave the rest to someone else. I hope this is helpful:
>>>
>>> The only way I immediately see for the schedulerResumptionTime to become
>>> approximately doubled is if the Delay's resumption time is adjusted by
>>> #restoreResumptionTimes without previously having been adjusted by
>>> #saveResumptionTimes.
>>>
>>> The only time either of those are sent, that I can see, is on saving the
>>> image. Both are normally sent, (save before the snapshot, restore
>>> afterwards), but there may be a hole there.
>>>
>>
>> Martin, first off, thanks for the research!!!
>>
>> Nowyour email made me remember something: I did get VM crash when
>> saving the image a couple of times. The VM crashed when saving the image. If
>> I re-opened the image, it looks like if the image was indeed saved (so the
>> snapshot primitive itself did work), but I suspect not all shutdown code
>> could have been run correctly.
>>
>> The VM crash looks like the FreeTypeFace >> pvtDestroyHandle  which, as
>> far as I know, it's a "known crash" (I attach crash dump). From what I can
>> see, if I follow all the stack, the crash starts from the WeakArray >>
>> startUp: .
>> That means that...depending on the order of the startup list...the
>> Scheduler may not have been run after the crash.
>>
>> Now WeakArray initialization does:
>>
>> SessionManager default
>> registerSystemClassNamed: self name.
>> While...
>>
>> Delay class >> startUp "Restart active delay, if any, when resuming a
>> snapshot." Scheduler startUp.
>>
>> And the Delay registration is
>>
>> SessionManager default
>> registerSystemClassNamed: self name
>> atPriority: 20.
>>
>> So...that seems correct...
>>
>> I can verify this by:
>>
>> SessionManager default systemCategory prioritizedList
>>
>> Anyway...not sure if this adds something, but just wanted to note this.
>>
>>
>>>
>>> #saveResumptionTimes is only sent (by this scheduler class) when the
>>> accessProtect semaphore is held, but #handleTimerEvent: is executed in the
>>> timing Process *without* the protection of accessProtect, in the case of the
>>> VM signaling the timingSemaphore. If the VM signals the timingSemaphore,
>>> #handleTimerEvent: could run in the middle of #saveResumptionTimes. If some
>>> Delay expires because of that timer event, our Delay could move from being
>>> the first suspended delay to being the active delay. If that happens after
>>> we've adjusted the active delay, but before we've processed the suspended
>>> delays, that Delay will not get adjusted, and will show the symptoms that
>>> Mariano is seeing.
>>>
>>> Also, I'm not sure how the Heap that holds the suspendedDelays will react
>>> to being modified in the middle of an enumeration. That might open a larger
>>> window for the problem.
>>>
>>> Regards,
>>>
>>> -Martin
>>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com

Re: [Pharo-dev] cleaning the Pharo Catalog

[Ben Coman]

On Mon, May 23, 2016 at 4:04 PM, Cyril Ferlicot Delbecque
 wrote:
>
>
> On 23/05/2016 10:00, Stephan Eggermont wrote:
>> Split into two categories? Those with full descriptions likely to load
>> and those probably needing some updates?
>>
>
> I like this option. Two tabs. A tab "PharoX" and a tab "Legacy" could be
> an idea.

But there are different levels of legacy.  Once version back maybe not
so bad.  Several versions back likely worse.  So maybe Pharo6, Pharo5,
Legacy ?  And it might be nice for Legacy to indicate which version
Pharo they were associated with, but probably not enough value for
such effort.

cheers -ben

>
>> Stephan
>>
>>
>>
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>

Re: [Pharo-dev] Random is not random at startup

[Ben Coman]

On Thu, May 19, 2016 at 7:05 AM, Peter Uhnák  wrote:
> Hi,
>
> (cc-ing Robert Withers as he seems to be working with cryptography and
> security... as this seems related and may have some implications, but I am
> likely wrong about the implications)
>
> yesterday I've encountered a very surprising behavior
>
> I executed the same script `10 atRandom` on the same image without saving it
> and got the same output:
>
> while true; do
> pharo-vm --nodisplay latest.image --no-default-preferences eval '10
> atRandom'
> done
> 10
> 10
> 10
> 10
> 10
> 10
>
> Not so random… not random at all.

Obligitory cartoon...
https://xkcd.com/221/

cheers -ben

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

[Ben Coman]

On Thu, May 19, 2016 at 8:49 AM, Martin McClure  wrote:
> On 05/18/2016 03:17 PM, Martin McClure wrote:
>>
>> On 05/18/2016 08:49 AM, Mariano Martinez Peck wrote:
>>>
>>> Hi guys,
>>>
>>> I am seeing a problem in Pharo 5.0 regarding Delay >> wait. I cannot
>>> explain how this could happened but it does, and it happened to me a couple
>>> of times (but not fully reproducible).
>>>
>>
>> Hmm. The schedulerResumptionTime is, somehow, being (approximately)
>> doubled. It's not clear how that can happen, but I'll look a little more.
>>
>
> Mario, is there any chance that you might be saving the image during one of
> these Delays?
>
>
> This one smells like a race condition, and I think I see something that
> *might* explain it. But I don't have any more time to spend on this one, so
> I'll leave the rest to someone else. I hope this is helpful:
>
> The only way I immediately see for the schedulerResumptionTime to become
> approximately doubled is if the Delay's resumption time is adjusted by
> #restoreResumptionTimes without previously having been adjusted by
> #saveResumptionTimes.
>
> The only time either of those are sent, that I can see, is on saving the
> image. Both are normally sent, (save before the snapshot, restore
> afterwards), but there may be a hole there.
>
> #saveResumptionTimes is only sent (by this scheduler class) when the
> accessProtect semaphore is held, but #handleTimerEvent: is executed in the
> timing Process *without* the protection of accessProtect, in the case of the
> VM signaling the timingSemaphore. If the VM signals the timingSemaphore,
> #handleTimerEvent: could run in the middle of #saveResumptionTimes. If some
> Delay expires because of that timer event, our Delay could move from being
> the first suspended delay to being the active delay. If that happens after
> we've adjusted the active delay, but before we've processed the suspended
> delays, that Delay will not get adjusted, and will show the symptoms that
> Mariano is seeing.

A quick experiment to test this might be in shutDown/#startUp trying...
[ self saveResumptionTimes ] valueAt: Processor timingPriority
[ self resumeResumptionTimes ] valueAt: Processor timingPriority

>
> Also, I'm not sure how the Heap that holds the suspendedDelays will react to
> being modified in the middle of an enumeration. That might open a larger
> window for the problem.
>
> Regards,
>
> -Martin
>

Even if not directly related to Mariano's problem, I agree with your
general assessment.  I'm not comfortable with the way that
#save/#restoreResumptionTimes (which manipulate suspendedDelays) are
called from user priority code via #shutDown/#startUp.  Per the
original code**, accessProtect can't be used inside the timing
priority #handleTimerEvent since accessProtect is held by the user
priority #schedule when it uses "timingSemaphore signal" to invoke
invokes #handleTimerEvent.  accessProtect never protected
timingPriority manipulation of suspendedDelays by #handleTimerEvent,
nor expired delays waking up.  But ahhh... the disabling of
accessProtect previously prevented new delays being scheduled between
a #save and #restore. If a new delay is scheduled after the #save,
when it is #restore'd its resumptionTime would be wrong.

Waiting in the wings for Pharo 6 I have changes that should help:
* have #save/#restoreResumptionTimes *only* called from timing
priority event loop (i.e. #handleTimerEvent)
* shutDown/startUp suspends/resumes the timing priority event loop,
instead of trying to block signals to timingSemaphore

I haven't touched it for a few months so I'll need to chase it up to
provide a preview.


Mariano, can you try DelayMillisecondScheduler (which however is
missing some fixes for other issues).

cheers -ben

[Pharo-dev] PharoVM-spur32 test newVMTestImage --> Pharo 2.0 ??

[Ben Coman]

In the PharoVM-spur32 CI build, newVMTestImage.sh [1] doesn't seem current?

> wget http://files.pharo.org/vm/src/vm-test-image-20.zip 1>&2
> unzip vm-test-image-20.zip -d vm-test-image 1>&2
>
> wget http://files.pharo.org/sources/PharoV20.sources 
> --output-document=vm-test-image/PharoV20.sources 1>&2
>
> PHARO_IMAGE=`find vm-test-image -name \*.image` 1>&2
> echo $PHARO_IMAGE

cheers -ben

[1] 
https://ci.inria.fr/pharo/job/PharoVM-spur32/Architecture=32,Slave=vm-builder-linux/ws/cog/image/newVMTestImage.sh/*view*/

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

[Ben Coman]

I don't have time to look at this properly until tomorrow.
In the meantime, could you just post the result of...

   Delay delaySchedulerClass
it should be "DelayExperimentalSpinScheduler"   ***

Also could you try a few of the other options from
 World > System > Settings > System ...


***whoops, the Experimental tag should have been dropped for Pharo 5
Release.  Its been fine for months (unless this is a fault :)  ]

On Wed, May 18, 2016 at 11:49 PM, Mariano Martinez Peck
 wrote:
> Hi guys,
>
> I am seeing a problem in Pharo 5.0 regarding Delay >> wait. I cannot explain
> how this could happened but it does, and it happened to me a couple of times
> (but not fully reproducible).
>
> In OSSubprocess I have this child watcher:
>
> initializeChildWatcher
> "This is a process which waits for the death of a child processes. Use
> SIGCHLD events rather than a Delay to poll."
>
> | processSynchronizationDelay |
> processSynchronizationDelay := Delay forMilliseconds: 20.
> childWatcher ifNil: [
> childWatcher := [[
> "OSProcess authors suspected that there were various ways in which OS
> signals
> could be missed under conditions of heavy load. For that reason, we use
> #waitTimeoutMSecs: with the semaphore, so that if a signal is missed,
> we time out and rescan occasionally anyway
> (#updateActiveChildrenAndNotifyDead
> sends queryExitStatus which sends waitpid() )
> "
> self sigChldSemaphore waitTimeoutMSecs: 1000.
> processSynchronizationDelay wait. "Avoids lost signals in heavy process
> switching"
> self updateActiveChildrenAndNotifyDead.
> ] repeat] newProcess.
>
> childWatcher resume.
> "name selected to look reasonable in the process browser"
> childWatcher name: ((ReadStream on: childWatcher hash asString) next: 5)
> , ': the OSSubprocess child watcher'
> ]
>
>
> The problem is that now above process is hung on the
> "processSynchronizationDelay wait.". At least that's what I can see from the
> process browser.  That should not hung, of course, and should stop waiting
> after 20 ms.
>
> If I inspect the Delay instance in question (doing the wait) I see that the
> print string is bad "a Delay(20 msecs; 3641032396485 msecs remaining)".
> WTF? 20ms  and you remain 3641032396485 to wait??? I attach an screenshot of
> the Delay instance in case there could be something wrong.

>
> Maybe it is wrong to keep and re-use same instance of Delay? (note it is
> outside the closure) (this was not a problem in the past).

Not sure.  I've heard others say Delays should only be used once. To
experiment, could you try creating a delay each time.

cheers -ben

Re: [Pharo-dev] [HELP WANTED] Getting ready for Pharo 5.0 release (CentOS, oldLibC, Nix, ArchLinux, and others)

[Ben Coman]

Thanks for the heads up.  The past few releases had some notice when
the changes file was being condensed.
cheers -ben

On Thu, May 5, 2016 at 9:56 PM, Bernardo Ezequiel Contreras
<vonbecm...@gmail.com> wrote:
> Ben,
>   This thread mail subject is Pharo 5.0 release (there is no beta), and even
> if you are right
> please take a look at http://files.pharo.org/sources/, there's a
> PharoV50.sources.
>And also if you try to open a Pharo5.0.image , it will ask for the file
> PharoV50.sources.
>
> thanks
>
> On Thu, May 5, 2016 at 6:04 AM, Ben Coman <b...@openinworld.com> wrote:
>>
>> On Thu, May 5, 2016 at 7:12 AM, Bernardo Ezequiel Contreras
>> <vonbecm...@gmail.com> wrote:
>> > Hi  Esteban,
>> > I tried again and it doesn't work. :(
>> > But now i found another issue, if you take a look to pharo5.0/shared
>> > folder you will see the file PharoV40.sources (wrong version for this
>> > release)
>>
>> This is the correct sources for Pharo5-*beta*.  It doesn't become
>> PharoV50.sources until the changes file is compacted for actual
>> *release*.   However I understand the confusion.  I think this naming
>> is based off the Squeak workflow, where IIUC they just work in, for
>> example 4.5, and don't call it 4.6 until just weeks before release.
>> But we've called it Pharo 5 (beta) for 12 months.
>>
>> I have thought a few times myself that maybe for Pharo 6 we could have
>> PharoV60dev.sources and later PharoV60.sources.
>>
>> cheers -ben
>>
>>
>> >
>> > thanks
>> >
>> > On Sun, May 1, 2016 at 7:13 AM, Esteban Lorenzano <esteba...@gmail.com>
>> > wrote:
>> >>
>> >>
>> >> > On 01 May 2016, at 10:59, Stephan Eggermont <step...@stack.nl> wrote:
>> >> >
>> >> > On 30/04/16 23:13, Bernardo Ezequiel Contreras wrote:
>> >> >> Hi Esteban,
>> >> >>  i found a problem with one of the packages, see below
>> >> >>
>> >> >> ** TODO This interpreter (vers. 6505) cannot read image file (vers.
>> >> >> 6521)
>> >> >
>> >> > So you have a non-spur vm there. You need a spur one
>> >>
>> >> yes, but Pharo5.0-linux-oldLibC.zip should download a spur vm… I need
>> >> to
>> >> review that :)
>> >>
>> >> Esteban
>> >>
>> >> >
>> >> > Stephan
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Bernardo E.C.
>> >
>> > Sent from a cheap desktop computer in South America.
>>
>
>
>
> --
> Bernardo E.C.
>
> Sent from a cheap desktop computer in South America.

Re: [Pharo-dev] [HELP WANTED] Getting ready for Pharo 5.0 release (CentOS, oldLibC, Nix, ArchLinux, and others)

[Ben Coman]

On Thu, May 5, 2016 at 7:12 AM, Bernardo Ezequiel Contreras
 wrote:
> Hi  Esteban,
> I tried again and it doesn't work. :(
> But now i found another issue, if you take a look to pharo5.0/shared
> folder you will see the file PharoV40.sources (wrong version for this
> release)

This is the correct sources for Pharo5-*beta*.  It doesn't become
PharoV50.sources until the changes file is compacted for actual
*release*.   However I understand the confusion.  I think this naming
is based off the Squeak workflow, where IIUC they just work in, for
example 4.5, and don't call it 4.6 until just weeks before release.
But we've called it Pharo 5 (beta) for 12 months.

I have thought a few times myself that maybe for Pharo 6 we could have
PharoV60dev.sources and later PharoV60.sources.

cheers -ben


>
> thanks
>
> On Sun, May 1, 2016 at 7:13 AM, Esteban Lorenzano 
> wrote:
>>
>>
>> > On 01 May 2016, at 10:59, Stephan Eggermont  wrote:
>> >
>> > On 30/04/16 23:13, Bernardo Ezequiel Contreras wrote:
>> >> Hi Esteban,
>> >>  i found a problem with one of the packages, see below
>> >>
>> >> ** TODO This interpreter (vers. 6505) cannot read image file (vers.
>> >> 6521)
>> >
>> > So you have a non-spur vm there. You need a spur one
>>
>> yes, but Pharo5.0-linux-oldLibC.zip should download a spur vm… I need to
>> review that :)
>>
>> Esteban
>>
>> >
>> > Stephan
>> >
>> >
>>
>>
>
>
>
> --
> Bernardo E.C.
>
> Sent from a cheap desktop computer in South America.

Re: [Pharo-dev] [ANN] RefsHunter

[Ben Coman]

On Tue, Apr 19, 2016 at 10:08 PM, Pavel Krivanek
 wrote:
>
>
> 2016-04-19 15:53 GMT+02:00 Mariano Martinez Peck :
>>
>> Hi Pavel,
>>
>> This would have helped us to track that evil object years ago (remember
>> the name???) hahaha.
>
>
> Dzindzik :-)
>
>>
>> Anyway, do you think it's worth an integration of this to
>> http://smalltalkhub.com/#!/~BenComan/PointerDetective ??

The last few commits of this are not stable.  Unfortunately I got
distracted in the middle of some re-factoring when I stumbled due to
debugging circular references which locked the image [1] .  I should
look at reviving this for Pharo 5, maybe on Bloc...

[1] https://pharo.fogbugz.com/default.asp?14827  - printString locks
Image on circular references

cheers -ben

>
> It should be pretty easy. it deserves an attempt.
>
> -- Pavel
>
>>
>>
>> Best,
>>
>> On Tue, Apr 19, 2016 at 10:44 AM, Pavel Krivanek
>>  wrote:
>>>
>>> Hi,
>>>
>>> when we were trying to fix memory leaks in the system in last weeks, it
>>> was very handy to create a small tool that shows a shortest path of backward
>>> references from one object to another one. Our tool is named RefsHunter and
>>> you can find it in the Catalog of Pharo 5.
>>>
>>> You can use Gofer if you want to load it without tests to the minimal
>>> Pharo:
>>>
>>> Gofer new
>>> smalltalkhubUser: 'PavelKrivanek' project: 'RefsHunter';
>>> package: 'RefsHunter-Core';
>>> load.
>>>
>>> The RefsHunter creates a temporary snapshot of all objects in the image
>>> and then collects information about all non-weak backward references. After
>>> that you can ask on the shortest path from one object to another one. That
>>> is useful for example when you still have got some leaking instance in the
>>> image and you want to see how is it linked with the global space.
>>>
>>> Example:
>>>
>>> | rh |
>>> rh := RefsHunter snapshot.
>>> rh wayFrom: (Array>>#asArray) to: Smalltalk specialObjectsArray.
>>>
>>> Notice that this tool is very memory demanding and it is not good idea to
>>> make a new RefsHunter snapshot when you still have some previous snapshot in
>>> the object memory.
>>>
>>> Cheers,
>>> -- Pavel
>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>
>

Re: [Pharo-dev] pharo -spur - vm source

[Ben Coman]

On Sun, Apr 17, 2016 at 10:56 PM, Nicolai Hess  wrote:
> Is https://github.com/pharo-project/pharo-vm the place to look
> for the current pharo spur vm source ?
> I load the master and build a vm but it isn't a spur vm.
> I only saw two other branches, legacy-cog and spur64. Where is the
> source for building the current latest pharo spur vm ?
>
> nicolai

Wanting to do this a few weeks ago, at a guess googling "pharo-vm
jenkins" I followed the path from...
https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/473/console

through to...
https://ci.inria.fr/pharo/job/PharoVM-spur32/Architecture=32,Slave=vm-builder-linux/

where currently 476 is shown to be the last green build, which indeed matches...
http://files.pharo.org/vm/pharo-spur32/linux/

so...
https://ci.inria.fr/pharo/job/PharoVM-spur32/Architecture=32,Slave=vm-builder-linux/476/consoleFull
shows how it is built

and...
https://ci.inria.fr/pharo/job/PharoVM-spur32/Architecture=32,Slave=vm-builder-linux/ws/
provides the last sources used.

I don't know how to match this back to a github commit.  It would be
nice if github was tagged (e.g. 476) for each successful build, or at
least a moving "ci" tag to show where the Jenkins is currently pulling
from - but hopefully the above is enough hint.

cheers -ben

Re: [Pharo-dev] [Pharo-users] GTDebugger shortcuts usability

[Ben Coman]

Interesting. A search turned up... Quick Tip Debugger Shortcut Key Reference
http://www.mularien.com/blog/category/eclipse/

cheers -ben

On Sun, Apr 17, 2016 at 11:15 PM, philippe.b...@highoctane.be
 wrote:
> Most of the world IDE use function keys for debugging.
>
> Additional benefit: easier for newcomers to use it.
>
> Having the buttons on the top is a pain as the code pane is at the bottom
> and requires travels all the time.
>
> Phil
>
> On Apr 17, 2016 4:57 PM, "Peter Uhnák"  wrote:
>>
>> Well, I've added a startup script for myself... but it would be nice to
>> have it everywhere by default in some variant...
>>
>> ~~
>> StartupPreferencesLoader default executeAtomicItems: {
>> StartupAction
>> name: 'Change debugger labels & shortcuts'
>> code: [
>> GLMMorphicActionRenderer compile: (
>> (GLMMorphicActionRenderer>>#render:) sourceCode
>> copyReplaceAll: 'setBalloonText: (anAction title'
>> with: 'setBalloonText: (anAction title asString'
>> ).
>> RestartDebugAction compile: 'defaultKeyText
>> ^ ''R'''.
>> RestartDebugAction compile: 'defaultLabel
>> ^ ''Restart'' asText addAttribute: TextEmphasis underlined from: 1 to: 1'.
>> ResumeDebugAction compile: 'defaultKeyText
>> ^ ''P'''.
>> ResumeDebugAction compile: 'defaultLabel
>> ^ ''Proceed'' asText addAttribute: TextEmphasis underlined from: 1 to: 1'.
>> StepIntoDebugAction compile: 'defaultKeyText
>> ^ ''I'''.
>> StepIntoDebugAction compile: 'defaultLabel
>> ^ ''Into'' asText addAttribute: TextEmphasis underlined from: 1 to: 1'.
>> StepOverDebugAction compile: 'defaultLabel
>> ^ ''Over'' asText addAttribute: TextEmphasis underlined from: 1 to: 1'.
>> StepThroughDebugAction compile: 'defaultLabel
>> ^ ''Through'' asText addAttribute: TextEmphasis underlined from: 1 to: 1'.
>> ]
>> runOnce: true.
>> }
>> ~~
>>
>>
>>
>> On Sat, Apr 16, 2016 at 11:39 PM, Peter Uhnák  wrote:

 Let’s turn this energy into something positive. Please propose a
 concrete set of default keybindings that you think would work better. In
 this process, please take into account all keybindings that are already
 defined in the code editor (it might not be so easy as it appears).
>>>
>>>
>>> As I've said:
>>>
>>> 1. can we unify the shift vs ctrl+shift nonsense? (I'm using linux btw)
>>> 2. can we use the default shortcuts pattern where one of the letters is
>>> underlined?
>>>
>>> as for the shortcuts themselves, problem is proceed, restart & into
>>>
>>> proceed: ctrl+shift+p is not taken, so I don't see why it has shortcut
>>> confusing with restart
>>> restart: ctrl+shift+r indents, but I'd argue that uniformity is more
>>> important here... indent is just convenience
>>> into: ctrl+shift+i is taken (I've never used it, but it maybe it's
>>> important), but we can still use ctrl+shift+n and underline n (point 2)
>>>
>>> If points 1 & 2 are implemented, then the letter is not as important,
>>> although first letter is always preferable.
>>>
>>> Peter
>>>

 Cheers,
 Doru


 > On Apr 16, 2016, at 8:37 PM, Peter Uhnák  wrote:
 >
 > Hi,
 >
 > I'm getting fed-up with GTDebugger shortcuts since they are completely
 > random.
 >
 > Can we have them more meaningful and/or somehow visible?
 >
 > For now I ended up overriding the labels so I can at least see them...
 > but doing this is also stupid, because I still have to look at them 
 > since I
 > cannot remember random shortcuts.
 >
 > 
 >
 > 1. can we unify the shift vs ctrl+shift nonsense? (I'm using linux
 > btw)
 > 2. can we use the default shortcuts pattern where one of the letters
 > is underlined?
 >
 > Peter

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

 "Value is always contextual."





>>>
>>

Re: [Pharo-dev] Class allSubInstances size takes 23 seconds to run on Pharo 5 on OS X

[Ben Coman]

On Wed, Apr 20, 2016 at 9:18 PM, Denis Kudriashov  wrote:
> And here other interesting results:
>
> Class allSubInstances size.
>  "5636"  * 2 = 11272
> Object allSubclasses size
>  "11267"
>
> What they are not almost equal?

Strange that its out by a factor of two.
Its almost like each class is also an object ;)

cheers -ben

>
> 2016-04-20 14:54 GMT+02:00 Pavel Krivanek :
>>
>> Interesting. It takes very high amount of time on Pharo 2.0 too.
>>
>> -- Pavel
>>
>> 2016-04-20 14:26 GMT+02:00 Bernhard Pieber :
>>>
>>> Dear Pharoers,
>>>
>>> I found something strange:
>>> Time millisecondsToRun: [ Class allSubInstances size ]. „23617"
>>>
>>> I did this on a new Pharo 5 image
>>> curl get.pharo.org/alpha+vmLatest | bash
>>>
>>> Can somebody confirm this on their machine? What might be the reason?
>>>
>>> Cheers,
>>> Bernhard
>>
>>
>

Re: [Pharo-dev] github-cache organisation

[Ben Coman]

> On 07/21/2016 08:40 PM, Ben Coman wrote:
>>
>> Just a general observation and first impression of installing a github
>> hosted project.
>>
>> After installing OSSubprocess from the Catalog Browser on Pharo 50760,
>> which uses repository...
>>github://marianopeck/OSSubProcess:v0.2.4/repository
>>
>> ...I see file
>> "github--marianopeckOSSubprocessv024126630702901887488330764830.zip"
>> sitting next to my .image file.  That would seem to dirty up that area
>> when I start to use git more often.  I'd expect that file to be placed in
>> one of the cache folders.
>>
>> cheers -ben
>
>
>

On Sat, Jul 23, 2016 at 1:38 AM, Dale Henrichs
<dale.henri...@gemtalksystems.com> wrote:
> Ben,
>
> I think I've found the bug ... Metacello intends that the zip file be
> downloaded to /tmp, but the code as implemented 3 years ago for Pharo was
> not actually downloading the file to /tmp ... thanks for pointing this out,
> I've created a Metacello issue for this[1] ... I will probably fix this
> shortly, but I'm not sure when (or if) my fix will be integrated into the
> Pharo-5.0 release.

Cool. Thanks Dale.  I created issues for Pharo 5 & 6 to track this our end.
https://pharo.fogbugz.com/default.asp?18804
https://pharo.fogbugz.com/default.asp?18805

cheers -ben

P.S.@All  curious why "Area=divers" for "Project=Metacello"

Re: [Pharo-dev] github-cache organisation

[Ben Coman]

On Sat, Jul 23, 2016 at 2:29 AM, Dale Henrichs
<dale.henri...@gemtalksystems.com> wrote:
>
>
> On 07/22/2016 11:19 AM, Ben Coman wrote:
>>>
>>> On 07/21/2016 08:40 PM, Ben Coman wrote:
>>>>
>>>> Just a general observation and first impression of installing a github
>>>> hosted project.
>>>>
>>>> After installing OSSubprocess from the Catalog Browser on Pharo 50760,
>>>> which uses repository...
>>>> github://marianopeck/OSSubProcess:v0.2.4/repository
>>>>
>>>> ...I see file
>>>> "github--marianopeckOSSubprocessv024126630702901887488330764830.zip"
>>>> sitting next to my .image file.  That would seem to dirty up that area
>>>> when I start to use git more often.  I'd expect that file to be placed
>>>> in
>>>> one of the cache folders.
>>>>
>>>> cheers -ben
>>>
>>>
>>>
>> On Sat, Jul 23, 2016 at 1:38 AM, Dale Henrichs
>> <dale.henri...@gemtalksystems.com> wrote:
>>>
>>> Ben,
>>>
>>> I think I've found the bug ... Metacello intends that the zip file be
>>> downloaded to /tmp, but the code as implemented 3 years ago for Pharo was
>>> not actually downloading the file to /tmp ... thanks for pointing this
>>> out,
>>> I've created a Metacello issue for this[1] ... I will probably fix this
>>> shortly, but I'm not sure when (or if) my fix will be integrated into the
>>> Pharo-5.0 release.
>>
>> Cool. Thanks Dale.  I created issues for Pharo 5 & 6 to track this our
>> end.
>> https://pharo.fogbugz.com/default.asp?18804
>> https://pharo.fogbugz.com/default.asp?18805
>>
>> cheers -ben
>>
>> P.S.@All  curious why "Area=divers" for "Project=Metacello"
>>
>>
> Ben,
>
> Sorry ... I gave you the wrong issue # for this one ... I opened 3 new
> issues for this message and only 2 of them applied directly '#405: Github
> .zip download not downloaded to `/tmp` as expected ... Pharo-5.0' and '#406:
> Github .zip download file should be deleted after archive is extracted' ...
> #404 is not really an issue, since the pid is meant for disambiguation of
> the file name, which is exactly the same thing that is supposed to be done
> by FileReference class>>newTempFilePrefix:suffix: ...
>
> Too many windows floating around:)
>
> Dale
>

@All, btw in the pharo-project swimlane here [1] it would be nice to
have a branch tagged "Pharo5.0" showing the point that was integrated
into Pharo 5.
cheers -ben

[Pharo-dev] github-cache organisation

[Ben Coman]

Just a general observation and first impression of installing a github
hosted project.

After installing OSSubprocess from the Catalog Browser on Pharo 50760,
which uses repository...
   github://marianopeck/OSSubProcess:v0.2.4/repository

...I see file
"github--marianopeckOSSubprocessv024126630702901887488330764830.zip"
sitting next to my .image file.  That would seem to dirty up that area when
I start to use git more often.  I'd expect that file to be placed in one of
the cache folders.

cheers -ben

[Pharo-dev] git feature request

[Ben Coman]

I'm not sure what the roadmap is for git integration, but just a use case
that occurs to me while I work "a bit with git" for the first time from
Pharo.

I install a project via a Baseline from git and makes a small improvement.
What is the easiest way to contribute back?  I can't push back to the
personal repo I downloaded from, so the easiest thing would be a single
menu item to:
1. Fork original repository
2. Push current in-Image code to a new branch in that fork.

Maybe even...
3. Issue a pull request to the original repository.

cheers -ben

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

[Ben Coman]

On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck <
marianop...@gmail.com> wrote:

>
>
> On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <b...@openinworld.com> wrote:
>
>
>> Do you have some test code or a test image I could run to reproduce
>> the problem?
>>
>
>
> The problem is that I cannot reproduce it immediately. It takes me some
> days and likely some image save and start again until I reproduce it.
>

Could you try
How about something that invokes


>
>
>>
>> Now I have one thing for you to try.  In the move of DelaySchedulerXxx
>> from milliseconds to microseconds, the code for dealing with clock
>> wrap-around was removed, but I wonder if it was also covering clock
>> jitter as a side effect.  Could you try again the SpinScheduler but
>> restore this code...
>>
>> From handletTimerEvent...
>>   "Check for clock wrap-around."
>>   millisecondNowTick < activeDelayStartTime ifTrue: [
>> "clock wrapped"
>> self saveResumptionTimes.
>> self restoreResumptionTimes ].
>>   activeDelayStartTime := millisecondNowTick.
>>
>> From runTimerEventLoop...
>>   Time millisecondClockValue < millisecondNowTick
>> ifTrue:[ timingSemaphore signal ]. "retry"
>>
>> From startup...
>>activeDelayStartTime := Time millisecondClockValue.
>>
>>
> OK, I put back the code into the spin scheduler. Then I kept using
> milisecond one until I finished the changes. Then I saved image and switch
> to spin one: the image hungs. I cannot even interrupt it. I attach my
> modifications.
> Do they look correct?
>

I confirm that locked my image also.

One change of milli to micro was missed at the bottom of runTimeEventLoop...
That is...
   Time millisecondClockValue < microsecondNowTick
to...
   Time microsecondClockValue < microsecondNowTick

(just a case of domestic blindness) [1]  :) :)

cheers -ben

[1] http://www.urbandictionary.com/define.php?term=domestic%20blindness

P.S. A trick to debug delays is to bypass interCycleDelay by at the top of
it putting...
true ifTrue: [^self].

Re: [Pharo-dev] Bloc, Bloc 2 and Brick

[Ben Coman]

On Tue, Aug 2, 2016 at 6:58 PM, Torsten Bergmann  wrote:
> Hi Stef,
>
> from past discussions/threads I know "Bloc" as Pharo's possible future UI, 
> watched the video [1] and have played with the premade
> image from the CI Server. Also the Brick layer (which is on top of Bloc) was 
> announced as a preview once [2].
>
>
> Now in some of the mails it was mentioned that there will be or already is a 
> "Bloc 2" (see [3]). Can you or the person
> working on it summarize:
>
>  - who works on it
>  - what are the goals, what will be included (like the CSS styling)
>  - where it is hosted
>  - what the status is
>  - if there is already a CI build or preview
>  - how Brick will relate to "Bloc 2", will there be a "Brick 2" as well?
>  - if it will work with Spec
>
> Even if not all could be answered (yet) more informations on "Bloc 2" would 
> really be nice, ideally as a
> status summary to the community.
>
> Thanks
> T.
>
> [1] https://vimeo.com/115336678
> [2] http://gtoolkit.org/brick/
> [3] 
> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-August/123115.html
>

You read my thoughts Torsten.  It would seem something has been learnt
from Bloc 1 to necessitate a change in direction.  This would be
interesting to know, as well as the plan for the new architecture.

I don't know what is the funding arrangements are to develop Bloc 2.
If its mostly someone's free time then maybe we can't put too much
demands on status report.  However since Bloc will become a core part
of Pharo, perhaps it is worthwhile for the Pharo Association (or other
body) to fund such a status report for the community.  A detailed
forward plan may have the side effect to encourage participation.

cheers -ben

Re: [Pharo-dev] ifTrue ifFalse shortcuts

[Ben Coman]

On Wed, Aug 3, 2016 at 4:36 PM, Esteban Lorenzano  wrote:
> I will just re-post my first answer:
>
> if reintroduce them means reintroduce them hardcoded as before, then I’m
> complete against it and I WILL NOT integrate such solution.
> I’m sorry for being so strong here, but previous implementation was lame and
> we need to get rid of them.
>
> Now, I understand people are used to use those bindings and also some others
> (no idea which ones because I never used them… for me ocompletion is good
> enough… but those are tastes). So I would be very happy to integrate a
> generic way to define keybindings and outputs (which is already there, with
> keymapping, but I mean an editor or something), and I would be very happy to
> integrate a default configuration (which of course, will include
> #ifTrue:/##ifFalse:)

I would guess code expansions could be many and varied between
different individuals, and quickly consume available keyboard
shortcuts.  Perhaps a generic mechanism would be single shortcut for
"code expansion" which processes the letters preceding the cursor.
For example, using shortcut  for code expansion and typing...

itf

==>   ifTrue: [ ] ifFalse: [ ]

The could be an interface to define these code expansions - initially
at least on a purely personal basis.

> And this is not really for adding a new feature. This shortcut already 
> (always :) ) existed

With a single shortcut for code expansion, perhaps a few other
existing combinations could be freed up.

cheers -ben

>
> Esteban
>
> On 03 Aug 2016, at 10:30, Denis Kudriashov  wrote:
>
>
> 2016-08-03 10:27 GMT+02:00 Guille Polito :
>>
>> I'm also against.
>>
>> - They take a place in the shortcuts that prevents others to use it
>> - If lazy people really needs this, the code completion should be
>> enhanced. This is a code completion concern...
>
>
> +1
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] 94fcf4: 60165

[Ben Coman]

Thanks for the follow up log message Marcus.
cheers -ben

On Wed, Aug 3, 2016 at 7:00 PM, Marcus Denker  wrote:
>
>> On 03 Aug 2016, at 12:24, GitHub  wrote:
>>
>>  Branch: refs/heads/6.0
>>  Home:   https://github.com/pharo-project/pharo-core
>>  Commit: 94fcf44742b41d7898726b57a76edc70fb1d9aea
>>  
>> https://github.com/pharo-project/pharo-core/commit/94fcf44742b41d7898726b57a76edc70fb1d9aea
>>  Author: Jenkins Build Server 
>>  Date:   2016-08-03 (Wed, 03 Aug 2016)
>>
>>
>>  Log Message:
>>  ---
>>  60165
>> Moose
>
>
> Fixes these issues:
> - case 18691
> - case 18471
> - case 18244
> - case 18708
> - GT-InspectorExtensions: only show methods for the current class, added 
> basic example for RBCondition
> - Uses Pragma>>#methodSelector instead of Pragma>>#selector (case 18665).
> - Uses Behavior>>#classLayout instead of Behavior>>#layout (case 16636).
> - Uses CompiledMethod>>#sourceCode instead of CompiledMethod>>#getSource 
> (case 18694).
> - GT-EventRecorder: Add a basic recorder event
>
> Marcus

Re: [Pharo-dev] ifTrue ifFalse shortcuts

[Ben Coman]

On Wed, Aug 3, 2016 at 8:05 PM, Esteban Lorenzano <esteba...@gmail.com> wrote:
>
>> On 03 Aug 2016, at 13:47, Cyril Ferlicot Delbecque 
>> <cyril.ferli...@gmail.com> wrote:
>>
>>
>>
>> On 03/08/2016 10:56, Ben Coman wrote:
>>> I would guess code expansions could be many and varied between
>>> different individuals, and quickly consume available keyboard
>>> shortcuts.  Perhaps a generic mechanism would be single shortcut for
>>> "code expansion" which processes the letters preceding the cursor.
>>> For example, using shortcut  for code expansion and typing...
>>>
>>> itf
>>>
>>> ==>   ifTrue: [ ] ifFalse: [ ]
>>>
>>> The could be an interface to define these code expansions - initially
>>> at least on a purely personal basis.
>>>
>>>> And this is not really for adding a new feature. This shortcut already 
>>>> (always :) ) existed
>>>
>>> With a single shortcut for code expansion, perhaps a few other
>>> existing combinations could be freed up.
>>>
>>> cheers -ben
>>>
>>
>> This would be really cool :)
>> If everyone agree, let's open an issue.
>>
>> There is this kind of things in JetBrains Tools but with autocompletion
>> instead of shortcut. You have some expression that make pop the
>> autocompletion dialog to change it on piece of code.
>>
>> For example in Intellij you can type "sout" and the autocompletion will
>> propose "System.out.println()”.
>
> exactly… we even have the algorithm implemented for this.
> I insist I would enhance ocompletion instead of adding an expansion shortcut.

So maybe the shortcut just provides the completion engine an extra hint.
Or maybe the expansion could be invoked by a special key series like a
double-colon ::
(if double-colon has no other special meaning, since single colons are
already associated with keyword messages).
For example typing
itf::
==>  ifTrue:  ifFalse:

cheers -ben

Re: [Pharo-dev] [Ann] Major Seamless update

[Ben Coman]

On Thu, Jul 21, 2016 at 8:24 PM, Denis Kudriashov 
wrote:

> I glad to finally release new version of Seamless (0.8.2).
> It could be loaded by:
>
>Gofer it
>   smalltalkhubUser: 'Pharo' project: 'Seamless';
>   configuration;
>   loadStable.
>
> It works in Pharo 5 and 6.
>
> It is complete redesign of original version with the goal to make it more
> flexible, reliable and simple.
> (original version was created by Nikolaos Papoulias)
>
> Seamless is foundation for RemoteDebuggingTools. It allows reuse existing
> debugger to work with remote process by transparent network communication.
> Particularly new version provides required flexibility to reduce number of
> requests between distributed objects. No debugger changes was needed to
> make it work relatively fast with remote model.
>
> For more details look at my blog
>  and
> read docs: Seamless
> 
>  and
> Basys
> 
>
>
> As usual feedback is welcome.
>
> Best regards,
> Denis
>

It will be a while before I play with it, but the manual was an interesting
read. Some minor nit-picks...

* Perhaps use a dash for compound-words like receiver-peer and
sender-peer.  This phrase was a bit hard to decipher...

"When request is executed on receiver peer sender peer should
receive..."
versus...
"When request is executed on receiver-peer, the sender-peer should
receive..."

* Check spelling ==> knowk?;)

cheers -ben

[Pharo-dev] Pharo minimal & bootstrapping - Time & DelayScheduler

[Ben Coman]

A question on the minimization of the Pharo image and bootstrapping...
Is there a desire to ultimately get down to the point of starting
without the Time class and/or without the DelayScheduler class?

DelayScheduler currently depends on Time, only due to calling
"Time microsecondClockValue' which is   
so this dependency could be removed by copying #microsecondClockValue
to DelayScheduler.

How a bad is it to have one primitive invoked from two different methods?

cheers -ben

Re: [Pharo-dev] [Ann] Remote debugging tools

[Ben Coman]

On Mon, Jul 18, 2016 at 10:26 PM, Denis Kudriashov <dionisi...@gmail.com> wrote:
> Hi Ben.
>
> 2016-07-18 14:46 GMT+02:00 Ben Coman <b...@openinworld.com>:
>>
>> Cool stuff Dennis.  Does it utilise the remote image's DebuggerUI, or
>> DebuggerSession directly?  i.e. Is the aim to remotely debug a
>> headless/UI-less image?  This could open up some great possibilities
>> running a minimal image on embedded hardware.
>
>
> Local debugger is opened on remote process. No UI needed to work with remote
> image.
> Also there is command line option to start image with running server:
>
> ./pharo PharoWithServer.image debuggerServer --port=40423
>
> With Marcus we played with beaglebon device. It works fine like in my demo.

I've been meaning to get a BBB.  I looks like bit better platform for
an industrial controller / robotics than the Rpi - in particular its
Programming Realtime Unit.   Knowing someone else has one maybe I'll
get one now. In the back of my mind I've been considering whether its
PRU could be modelled as a CPU target for Slang , so Slang could be
re-purposed from just compiling VM, to compiling embedded programs for
the PRU, developed from within Pharo and loaded on the fly into the
PRU.

>>
>> When I read "Async evaluation ... does not wait for a result" I wonder
>> if there a particular need for the fork is used here?...
>> debugger evaluateAsync: [ [1/0] fork ].
>>
>
> Yes, it looks strange. Now all remote requests are executed such way that
> errors will be returned as SeamlessRemoteException and server signaller
> process will die. So instead of debugger with failed remote expression you
> will see debugger with local process which performed remote message send
> (but in case of async evaluation no result will returned to client and error
> will be just ignored). To escape such "exception handler" fork is needed.
> Fork will lead to unhanded error which will ask registered remote debugger
> to debug it.

Could you not just fork at the remote side?
Perhaps the invocation would be #evaluateFork:


> It was simplest strategy for error handling and in future it is probably
> possible to implement real smalltalk semantics over distributed errors.
>
>>
>>
>> An interesting proof demonstration would be when setting up the server
>> image do...
>>   Smalltalk at: #whoami put: #IAmTheServer
>>
>> then in the client do...
>>   debugger evaluate: [ Smalltalk at: #whoami ]
>
>
> It works exactly like you want. Evaluation scripts transfer block to remote
> side by value. And for blocks "by value" means transfer all literals as
> "well known objects" (which are known on remote side). If globals not exist
> on remote side then error will be returned. Some literals could be
> transferred by reference. For example workspace variables.
>
>>
>>
>> although maybe its hard to bind to the remote Smalltalk rather than
>> the local one?
>> What is the tradeoff of the #evaluate: parameter being a string rather
>> than a block?
>
>
> In this case you can't execute scripts which reference local objects like
> self, temps or workspace variables. Also it would be impossible to implement
> non local return with regular semantics.
>
>>
>> Without having looked at the Seamless mechanism, intuitively there
>> would seem some benefit having the remote system compile the string to
>> bind to the remote  classes.
>
>
> There is scenario which needs to be covered: debugging images which has no
> compiler. I probably will work on it at some point.
>
>>
>> Another interesting demo might be remotely evaluating...
>>   Object inform: 'Test'
>> and the notification showing up on the remote (if indeed that is the
>> desired behaviour)
>
> Yes, it works: https://youtu.be/Aop7KOGOFN0

HAharrrgh!!   Thats *very* cool indeed !!

cheers -ben

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

[Ben Coman]

On Wed, Jul 13, 2016 at 12:30 AM, Mariano Martinez Peck
<marianop...@gmail.com> wrote:
>
>
> On Wed, May 18, 2016 at 11:39 PM, Ben Coman <b...@openinworld.com> wrote:
>>
>> On Thu, May 19, 2016 at 8:49 AM, Martin McClure <mar...@hand2mouse.com>
>> wrote:
>> > On 05/18/2016 03:17 PM, Martin McClure wrote:
>> >>
>> >> On 05/18/2016 08:49 AM, Mariano Martinez Peck wrote:
>> >>>
>> >>> Hi guys,
>> >>>
>> >>> I am seeing a problem in Pharo 5.0 regarding Delay >> wait. I cannot
>> >>> explain how this could happened but it does, and it happened to me a
>> >>> couple
>> >>> of times (but not fully reproducible).
>> >>>
>> >>
>> >> Hmm. The schedulerResumptionTime is, somehow, being (approximately)
>> >> doubled. It's not clear how that can happen, but I'll look a little
>> >> more.
>> >>
>> >
>> > Mario, is there any chance that you might be saving the image during one
>> > of
>> > these Delays?
>> >
>> >
>> > This one smells like a race condition, and I think I see something that
>> > *might* explain it. But I don't have any more time to spend on this one,
>> > so
>> > I'll leave the rest to someone else. I hope this is helpful:
>> >
>> > The only way I immediately see for the schedulerResumptionTime to become
>> > approximately doubled is if the Delay's resumption time is adjusted by
>> > #restoreResumptionTimes without previously having been adjusted by
>> > #saveResumptionTimes.
>> >
>> > The only time either of those are sent, that I can see, is on saving the
>> > image. Both are normally sent, (save before the snapshot, restore
>> > afterwards), but there may be a hole there.
>> >
>> > #saveResumptionTimes is only sent (by this scheduler class) when the
>> > accessProtect semaphore is held, but #handleTimerEvent: is executed in
>> > the
>> > timing Process *without* the protection of accessProtect, in the case of
>> > the
>> > VM signaling the timingSemaphore. If the VM signals the timingSemaphore,
>> > #handleTimerEvent: could run in the middle of #saveResumptionTimes. If
>> > some
>> > Delay expires because of that timer event, our Delay could move from
>> > being
>> > the first suspended delay to being the active delay. If that happens
>> > after
>> > we've adjusted the active delay, but before we've processed the
>> > suspended
>> > delays, that Delay will not get adjusted, and will show the symptoms
>> > that
>> > Mariano is seeing.
>>
>> A quick experiment to test this might be in shutDown/#startUp trying...
>> [ self saveResumptionTimes ] valueAt: Processor timingPriority
>> [ self resumeResumptionTimes ] valueAt: Processor timingPriority
>>
>> >
>> > Also, I'm not sure how the Heap that holds the suspendedDelays will
>> > react to
>> > being modified in the middle of an enumeration. That might open a larger
>> > window for the problem.
>> >
>> > Regards,
>> >
>> > -Martin
>> >
>>
>> Even if not directly related to Mariano's problem, I agree with your
>> general assessment.  I'm not comfortable with the way that
>> #save/#restoreResumptionTimes (which manipulate suspendedDelays) are
>> called from user priority code via #shutDown/#startUp.  Per the
>> original code**, accessProtect can't be used inside the timing
>> priority #handleTimerEvent since accessProtect is held by the user
>> priority #schedule when it uses "timingSemaphore signal" to invoke
>> invokes #handleTimerEvent.  accessProtect never protected
>> timingPriority manipulation of suspendedDelays by #handleTimerEvent,
>> nor expired delays waking up.  But ahhh... the disabling of
>> accessProtect previously prevented new delays being scheduled between
>> a #save and #restore. If a new delay is scheduled after the #save,
>> when it is #restore'd its resumptionTime would be wrong.
>>
>> Waiting in the wings for Pharo 6 I have changes that should help:
>> * have #save/#restoreResumptionTimes *only* called from timing
>> priority event loop (i.e. #handleTimerEvent)
>> * shutDown/startUp suspends/resumes the timing priority event loop,
>> instead of trying to block signals to timingSemaphore
>>
>> I haven't touched it for a few months so I'll need to chase it up to
>> provide

Re: [Pharo-dev] [Ann] Remote debugging tools

[Ben Coman]

On Tue, Jul 19, 2016 at 10:30 PM, Denis Kudriashov <dionisi...@gmail.com>
wrote:

>
> 2016-07-18 18:26 GMT+02:00 Ben Coman <b...@openinworld.com>:
>
>> I've been meaning to get a BBB.  I looks like bit better platform for
>> an industrial controller / robotics than the Rpi - in particular its
>> Programming Realtime Unit.   Knowing someone else has one maybe I'll
>> get one now. In the back of my mind I've been considering whether its
>> PRU could be modelled as a CPU target for Slang , so Slang could be
>> re-purposed from just compiling VM, to compiling embedded programs for
>> the PRU, developed from within Pharo and loaded on the fly into the
>> PRU.
>>
>
> Do you have link to BBB? (google not helps with such 3 letters).
>

BeagleBoneBlack.  btw here is a nice overview of the PRU...
http://beagleboard.org/static/presentations/MakerFaireNY20140920_UsingBeagleBoneRealTimeMicrocontrollers.pdf

and some videos...
http://beagleboard.org/pru

cheers -ben


>
>>
>> >>
>> >> When I read "Async evaluation ... does not wait for a result" I wonder
>> >> if there a particular need for the fork is used here?...
>> >> debugger evaluateAsync: [ [1/0] fork ].
>> >>
>> >
>> > Yes, it looks strange. Now all remote requests are executed such way
>> that
>> > errors will be returned as SeamlessRemoteException and server signaller
>> > process will die. So instead of debugger with failed remote expression
>> you
>> > will see debugger with local process which performed remote message send
>> > (but in case of async evaluation no result will returned to client and
>> error
>> > will be just ignored). To escape such "exception handler" fork is
>> needed.
>> > Fork will lead to unhanded error which will ask registered remote
>> debugger
>> > to debug it.
>>
>> Could you not just fork at the remote side?
>> Perhaps the invocation would be #evaluateFork:
>>
>
> Here is screen which shows "evaluate: [1/0]":
>
> ​No remote stack here. And on remote side there is no waiting process.
>
> In future real exception semantics could be supported. In that case
> "evaluate: [1/0]" will open debugger with half stack from local process
> (doIt from workspace) and half from remote process (where ZeroDivide
> happens).
>
> ("debugger evaluateAsync: [1/0]" will never show any error because result
> is not supposed to be returned for async)
>
>

Re: [Pharo-dev] State of Pharo in comparison with the "Pharo vision" document

[Ben Coman]

On Wed, Jul 20, 2016 at 4:59 PM, Esteban Lorenzano 
wrote:
>
> 21. New Object Formats
>
> In progress
>

This is Spur?

cheers -ben

Re: [Pharo-dev] [pharo-project/pharo-core] a813b2: 60138

[Ben Coman]

On Thu, Jul 7, 2016 at 12:52 AM, Marcus Denker  wrote:
>
>> On 06 Jul 2016, at 18:16, stepharo  wrote:
>>
>> I always found such kind of changes totally obscure and it would be nice to 
>> have a description.
>>
>
>

The point I took from Stef's question is... not just getting a
followup description here in the mail list, but could this text you've
typed here

> Fixes issues:
>
> - 18450 GT-Tools: "Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, 
> #ifNotNilDo:"
> - 18453 GT-Tools: "do not use #ifEmpty:ifNotEmptyDo: #ifNotEmptyDo: 
> #ifNotEmptyDo:ifEmpty:”
> - 18431 attach glmpopplers shortcut to the textarea instead of the scroll pane
> - Esteban's change to GLMAction

...in future be added as the Log message instead of just "Moose" so
there is a permanent record in our package history.

>
> This was mostly me pushing for getting the trivial things *DONE* and not wait 
> another 3 weeks…
>
> (I should have just committed slices, the overhead with committing and 
> syncing is to high for
> trivial refactorings)

Sure, buts lets document this. Since anyway we'll just ask for a
followup in the mail list ;) and I presume it takes more effort to go
back and look these up after the fact, than copy-pasting at
integration time.

cheers -ben
>
> Marcus

P.S.  Not to take your efforts doing the integrations for granted,
thanks for regularly doing this task.

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[Ben Coman]

On Thu, Jul 7, 2016 at 2:19 AM, Sven Van Caekenberghe  wrote:
> I'll try once more to explain.
>
> You like the catalog, don't you ?  It was your idea in the first place. With 
> this feature you can just type XML, CSV, JSON or whatever and it will suggest 
> a couple of catalog projects that you can install with just one click, no 
> need to open any tool you don't even know. This is especially good for new 
> people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It 
> leverages all the work put in the catalog.
>
> Is Spotter or any other part of Pharo perfect ? No.
>
> For many people, Spotter make a huge functional difference, we use it every 
> minute. If it would hang or block the image even once a day, any of us would 
> complain loudly.
>
> Conclusion: it works for 99% of the people/cases.
>
> Even in the 1% where there is a problem, it is not 100% sure it is related to 
> the catalog searching. In the last concrete issue reported, the guy tried 
> disabling the catalog searching AND IT MADE NO DIFFERENCE !
>
> So again, why turn it off ? It is an overreaction, not engineering.
>
> The underlying problem is that in some very rare, hard to reproduce cases we 
> cannot reliably detect that there is no network. That's about it.

If the root cause is a blocking system call e.g
"NetNameResolver class>>#addressForName: sometimes hangs when there is
no network"
https://pharo.fogbugz.com/default.asp?18281;

this seems very hard to fix at the Image level, except maybe doing
in-Image name resolution instead of relying on the system library. I
found this...
http://forum.world.st/ANN-DnsClient-More-protocol-fun-td2303225.html

and...
http://www.squeaksource.com/dnsclient.html
http://www.squeaksource.com/ar.html

cheers -ben

>
> Note also that almost every application or app today will do some network 
> calls, this is how the world work - we should be able to do the same with 
> Pharo, not run away and kill every feature that does a network call.
>
>> On 06 Jul 2016, at 18:14, stepharo  wrote:
>>
>> Who vote to put it in?
>>
>> Seriously I think that my main concern is about getting Pharo stable in any 
>> occasion and not giving
>>
>> a bad impression of the system. I takes enough time to build traction and 
>> such glitches can spoil
>>
>> our effort in no time. "Yes Pharo froze."
>>
>> So it would be nice to care take of such aspect.
>>
>> I do not understand why super users do not manage to put a reference to on 
>> in the preferences.
>>
>> Sorry esteban but I do not buy your argument that something off is remove. 
>> No it is off.
>>
>> Stef
 On 06 Jul 2016, at 09:52, GitHub  wrote:

 18674 Turn spotter catalog off by default
 https://pharo.fogbugz.com/f/cases/18674
>>> We did not agree on this, at all, there was no public discussion, no vote.
>>>
>>>
>>
>>
>
>

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

[Ben Coman]

Hi Mariano,  How are you going with this problem?

On Fri, Jul 22, 2016 at 11:05 PM, Mariano Martinez Peck
<marianop...@gmail.com> wrote:
>
>
> On Fri, Jul 22, 2016 at 2:26 AM, Ben Coman <b...@openinworld.com> wrote:
>>
>>
>>
>> On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck
>> <marianop...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <b...@openinworld.com> wrote:
>>>
>>>>
>>>> Do you have some test code or a test image I could run to reproduce
>>>> the problem?
>>>
>>>
>>>
>>> The problem is that I cannot reproduce it immediately. It takes me some
>>> days and likely some image save and start again until I reproduce it.
>>
>>
>> Could you try
>> How about something that invokes
>>
>
>
> Hi Ben. I tried to reproduce it in a couple of ways, trying to simulate what
> I do for real but I failed:
>
> | commandString |
> commandString := 'wkhtmltopdf  --javascript-delay 300  --encoding utf8
> --page-size A4 --image-quality 100  --footer-spacing 10  --header-spacing 10
> --margin-top 10  --header-html "http://google.com; --footer-html
> "http://google.com; "http://pharo.org/; "/tmp/TestPharoExport.pdf"'.
>
> 10 timesRepeat: [
>
> 3 timesRepeat: [
> OSSUnixSubprocess new
> shellCommand: commandString;
> redirectStdout;
> redirectStderr;
> runAndWaitOnExitDo: [ :command :outString :errString |
> Transcript show: errString.
> Transcript show: outString.
> ].
>  ].
> Smalltalk saveSession.
>
> ]
>
> But...I could not yet reproduce it in the real case eitherso I will keep
> you informed.
>
>
>>>
>>>
>>>>
>>>>
>>>> Now I have one thing for you to try.  In the move of DelaySchedulerXxx
>>>> from milliseconds to microseconds, the code for dealing with clock
>>>> wrap-around was removed, but I wonder if it was also covering clock
>>>> jitter as a side effect.  Could you try again the SpinScheduler but
>>>> restore this code...
>>>>
>>>> From handletTimerEvent...
>>>>   "Check for clock wrap-around."
>>>>   millisecondNowTick < activeDelayStartTime ifTrue: [
>>>> "clock wrapped"
>>>> self saveResumptionTimes.
>>>> self restoreResumptionTimes ].
>>>>   activeDelayStartTime := millisecondNowTick.
>>>>
>>>> From runTimerEventLoop...
>>>>   Time millisecondClockValue < millisecondNowTick
>>>> ifTrue:[ timingSemaphore signal ]. "retry"
>>>>
>>>> From startup...
>>>>activeDelayStartTime := Time millisecondClockValue.
>>>>
>>>
>>> OK, I put back the code into the spin scheduler. Then I kept using
>>> milisecond one until I finished the changes. Then I saved image and switch
>>> to spin one: the image hungs. I cannot even interrupt it. I attach my
>>> modifications.
>>> Do they look correct?
>>
>>
>> I confirm that locked my image also.
>>
>> One change of milli to micro was missed at the bottom of
>> runTimeEventLoop...
>> That is...
>>Time millisecondClockValue < microsecondNowTick
>> to...
>>Time microsecondClockValue < microsecondNowTick
>>
> Thanks. That did the trick!

Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

[Ben Coman]

On Sun, Aug 7, 2016 at 3:39 PM, stepharo  wrote:
> Hi
>
> Seriously I do not get why printing in the debugger cannot just print the
> text without putting these ^%&*^*&()**(&%^*( double quote around.

I believe the behaviour was introduced for the Workspace/Playground so
that inserting the result into the text wouldn't screw up the syntax
highlighting or running it again.  Perhaps this behaviour was
copied/inherited by the Debugger without considering it might be a
different use case.

??
cheers -ben

>
> Why do we change such basic functionality and in particular we do not
> propose ANY alternative.
>
> If you need a pop up and do not care of manipulating text this is ok but WHY
> the default behavior has to be changed.
>
> I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your &^%*^(&
> flow is not mine.
>
> Should I go and hack to get back the default behavior. WHY do I have to do
> that?
>
> Seriously.
>
> Especially since the solution was super simple: introduce a new binding
> living nicely close to PrintIt
>
> but no "we have to change the default one with something that may fuck your
> flow but who cares because my flow is better."
>
> Why do we get systematically this message? Why such changes are damaging TDD
> practices without any notices?
>
> May be I should use another Smalltalk at the end.
>
> Stef
>
>

Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

[Ben Coman]

On Sun, Aug 7, 2016 at 9:16 PM, Tudor Girba  wrote:
> Hi Stef,
>
> We had a thread on that two months ago, and it is still waiting for your 
> answer. I made concrete proposals on which bindings can work. It would be 
> more constructive to focus on those details (see more below).
>
> First, one thing should get clarified. The case in which someone wants to 
> print and persist inline the result is an edge case. For example, it happens 
> when you want to write tests to document how the code is working currently. 
> The typical case for using print-it is to get a sneak peak of what the object 
> is and in this case, the requirement is specifically to not change the 
> current code (especially when you are debugging you do not want to get the 
> code dirty).
>
> That is why we made the default printing not affect the text editor, and this 
> feature is around since almost 2 years and, except of you, there was no other 
> complain.
>
> But, to come back to the concrete solution, as I mentioned before, I do agree 
> that what you mention should be a supported use case. The only question is 
> how to do it. So, let’s focus on that please.
>
> One solution would be to have a different first level keybinding directly in 
> the text editor, but that would not be a good idea because that space is 
> already overloaded with too many key bindings, and this becomes a problem 
> especially when you place an editor inside a larger tool (like a debugger) 
> and you run out of available key bindings for other actions.
>
> So, the proposals I had was like this:
>
> Cmd+p ==> the print-it popup
> - Enter ==> add as a comment
> - Shift+Enter ==> add as plain text
> - Cmd+v ==> add as plain text (this would not affect the text that was copied 
> to clipboard)
>
> Another option would be to change the meaning of the current Enter:
>
> Cmd+p ==> the print-it popup
> - Enter ==> add as a plain text
> - Shift+Enter ==> add as comment

Doing a CMD key then SHIFT key is a bit of a contortion.
What about...
Cmd+p ==> the print-it popup, then...
- Cmd+p ==> add as a plain text  (fingers don't have to move, most
efficient for old behaviour)
- Enter ==> add as comment (existing behaviour)

cheers -ben

>
>
> What do you think?
>
> Cheers,
> Doru
>
>
>> On Aug 7, 2016, at 9:39 AM, stepharo  wrote:
>>
>> Hi
>>
>> Seriously I do not get why printing in the debugger cannot just print the 
>> text without putting these ^%&*^*&()**(&%^*( double quote around.
>>
>> Why do we change such basic functionality and in particular we do not 
>> propose ANY alternative.
>>
>> If you need a pop up and do not care of manipulating text this is ok but WHY 
>> the default behavior has to be changed.
>>
>> I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your &^%*^(& 
>> flow is not mine.
>>
>> Should I go and hack to get back the default behavior. WHY do I have to do 
>> that?
>>
>> Seriously.
>>
>> Especially since the solution was super simple: introduce a new binding 
>> living nicely close to PrintIt
>>
>> but no "we have to change the default one with something that may fuck your 
>> flow but who cares because
>>
>> my flow is better."
>>
>> Why do we get systematically this message? Why such changes are damaging TDD 
>> practices without any notices?
>>
>> May be I should use another Smalltalk at the end.
>>
>> Stef
>>
>>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Presenting is storytelling."
>
>

Re: [Pharo-dev] git feature request

[Ben Coman]

On Fri, Jul 22, 2016 at 3:11 PM, Peter Uhnak <i.uh...@gmail.com> wrote:
> On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote:
>> I'm not sure what the roadmap is for git integration, but just a use case
>> that occurs to me while I work "a bit with git" for the first time from
>> Pharo.
>>
>> I install a project via a Baseline from git and makes a small improvement.
>> What is the easiest way to contribute back?  I can't push back to the
>> personal repo I downloaded from, so the easiest thing would be a single
>> menu item to:
>> 1. Fork original repository
>> 2. Push current in-Image code to a new branch in that fork.
>>
>> Maybe even...
>> 3. Issue a pull request to the original repository.
>
> This is indeed the idiomatic way to contribute on GitHub.
>
> 1. fork
> 2. install _your fork_ with gitfiletree/remote git repo
> 3. make an improvement (you can use master branch, since it's your repo, but 
> that's a detail)
> 4. issue a pull request

That is how you do it if you *already* know you want to be contribute
to an application or package. But what if I was just planning to *use*
an application or package, only later I ended up tracing down a bug to
that application and fixed it.  What is the *easiest* for me to push
to my personal github account from where I make the Pull Request.
Something like this [1] from within Pharo (disclaimer, I've not
performed these action before, I had to hunt a bit to find it as an
example)...

[1] https://gist.github.com/jagregory/710671

> Maybe IceBerg (https://github.com/npasserini/iceberg) could have some nice 
> interface for this eventually.

Thanks for the link.  This will be interesting to watch.

cheers -ben

Re: [Pharo-dev] A taste of bootstrap

[Ben Coman]

On Fri, Jul 22, 2016 at 9:12 PM, Pavel Krivanek
 wrote:
> Hi,
>
> as you maybe know, we are working on Pharo image bootstrap - the process
> that can generate an image from source codes and initialize it correctly.
> Because of practical reasons we do not bootstrap the standard image at once
> but we are trying to bootstrap a small headless kernel image and then load
> the rest of the system into it.
>
> The good news is that we are successful in our effor. We are already able to
> produce well usable images as you can test here:

Great to hear of your continuing progress.

>
> https://goo.gl/fn1VbP
>
> From the Pharo/Squeak point of view this image is very special because it
> doesn't contain any object inherited from 70's. Pharo lost its umbilical
> cord.

Does this mean you are starting with a zero byte file and adding nil,
true, false, etc...?
Or what is the size of the image you start with?

cheers -ben

>
> Notice that the initial display width is too narrow and and we still need a
> lot of work on the building process, but In the next weeks and months it
> will change a lot the Pharo development - especially as soon as it will be
> combined with Git support.
>
> Cheers,
> -- Pavel
>
>

Re: [Pharo-dev] Fwd: Subscription Form to FogBugz

[Ben Coman]

On Thu, Jun 30, 2016 at 2:40 AM, Tomas Saez Binelli
 wrote:
> Hi everybody!
>
> I was trying to create an account on Fogbugz during a Sprint using the link
> posted here:
>
> https://pharo.fogbugz.com/
>
> But after filling the form and submiting it, i received the following
> message:
>
> "Incorrect password or username"
>
> This is a little bit strange because i was not able to finish the
> registration and create an account.
>
> Sending this email to make the error public.
>
>
> Bye!
> Tomas
>

Thanks for the report Tomas.  I think I've seen this a long time ago,
maybe your account was created but something went wrong with setting
the password.  As a work around, see if you can find a password reset
button.

cheers -ben

Re: [Pharo-dev] Bug in MailA

[Ben Coman]

On Sun, Jul 3, 2016 at 3:16 AM, Bernhard Pieber  wrote:
> Hi,
>
> The following code goes into an endless loop:
> MailAddressParser addressesIn: 'romeo@verona.it‘
>
> It’s because of the ampersand. The fix is trivial, because the bug just was a 
> typo.
>
> Fix and test are in the Pharo50Inbox:
> Network-Mail-BernhardPieber.46.mcz
> Network-Tests-BernhardPieber.14.mcz
>
> Cheers,
> Bernhard
>
>
>

Thanks Bernhard.
Can you log an issue for it on
and submit this in Slice format.
Instructions at http://pharo.org/contribute-propose-fix
This makes it easier to review and the integration system only works
with Slices & Configurations.

cheers -ben

Re: [Pharo-dev] Bug in MailA

[Ben Coman]

On Sun, Jul 3, 2016 at 7:25 PM, Bernhard Pieber  wrote:
> Done!

Thanks Bernhard, but I can't find the issue in the tracker. Can you
paste a link?


On Sun, Jul 3, 2016 at 7:41 PM, Bernhard Pieber  wrote:
> I wonder about the process for fixes for Pharo 4.0? Is it the same? If I’d 
> put the equivalent fix into the Pharo40Inbox, would it be integrated?

I am not familiar with the release process, but apparently there is a
fair amount of manual work to do each release.  Typically it seems
each major release is followed by one minor point release about 6
months later.  So 4.0 is probably too far back for another release.

It would be good however if there was some community process to manage
fixes for very old releases.  Perhaps there could be a tag like
"Pharo4-hotfix" in Fogbugz, so users of their own accord could search
for community fixes contributed long after the main development focus
has moved on - to be used at own risk.  This might provide better
sustainability for older releases without drawing resources from the
latest version.  That is, Pharo 4.0 users would need to rely on review
by other Pharo 4.0 user to review and promote their fixes to "hotfix"
- but at least the Fogbugz facilitates the collaboration.  This might
also work for 5.0 fixes as a state between Work Needed and Closed Fix
Integrated while they are waiting to be rolled up into the point
release.

cheers -ben

>
> Cheers,
> Bernhard
>
>> Am 03.07.2016 um 08:46 schrieb stepharo :
>>
>> Thanks Bernhard
>>
>> - can you open a bug entry?
>>
>> - publish a slice? (press slice + bug number)
>>
>> Our integration tool and process work this way
>>
>> Stef
>>
>> Le 2/7/16 à 21:16, Bernhard Pieber a écrit :
>>> Hi,
>>>
>>> The following code goes into an endless loop:
>>> MailAddressParser addressesIn: 'romeo@verona.it‘
>>>
>>> It’s because of the ampersand. The fix is trivial, because the bug just was 
>>> a typo.
>>>
>>> Fix and test are in the Pharo50Inbox:
>>> Network-Mail-BernhardPieber.46.mcz
>>> Network-Tests-BernhardPieber.14.mcz
>
>

[Pharo-dev] GTDebugger - class variables

[Ben Coman]

I just noticed it seems class variables are not shown in Variables
pane of GTDebugger.  It confused me for a while, and I expect it would
be troubling for newcomers.  Is this due to copying the previous
Debugger functionality here, or some other design decision?Any
reason to not display class variables in the Variable pane?

cheers -ben

Re: [Pharo-dev] Bug in MailA

[Ben Coman]

On Sun, Jul 3, 2016 at 6:08 AM, Ben Coman <b...@openinworld.com> wrote:
> On Sun, Jul 3, 2016 at 3:16 AM, Bernhard Pieber <bernh...@pieber.com> wrote:
>> Hi,
>>
>> The following code goes into an endless loop:
>> MailAddressParser addressesIn: 'romeo@verona.it‘
>>
>> It’s because of the ampersand. The fix is trivial, because the bug just was 
>> a typo.
>>
>> Fix and test are in the Pharo50Inbox:
>> Network-Mail-BernhardPieber.46.mcz
>> Network-Tests-BernhardPieber.14.mcz
>>
>> Cheers,
>> Bernhard
>>
>>
>>
>
> Thanks Bernhard.
> Can you log an issue for it on
> and submit this in Slice format.
> Instructions at http://pharo.org/contribute-propose-fix
> This makes it easier to review and the integration system only works
> with Slices & Configurations.
>
> cheers -ben

P.S. Once your Slice is integrated, see instructions at the bottom of
[1] to get yourself added to the contributors page.
[1] http://pharo.org/about

cheers -ben

[Pharo-dev] Catalog Browser timed out

[Ben Coman]

When opening the Catalog Browser I am getting connection timed out.
Tested from two different Images:
* a fresh generator.image from running newImage.sh of the pharo-vm.
* my usual PharoLauncher image

cheers -ben

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

[Ben Coman]

On Fri, Feb 3, 2017 at 10:13 AM, Ben Coman <b...@openinworld.com> wrote:

> Just curious what the magic numbers here relate to...
> and can they be factored out to a meaningful method name?
>
> Context>>gtInspectorVariableValuePairs
>

Whoops, this is...
Object>>gtInspectorVariableValuePairs


> "This is a helper method that returns a collection of
> variable_name -> value
> for the current object.
> Subclasses can override it to specialize what appears in the variables
> presentation"
> | bindings |
> bindings := OrderedCollection new.
> 1 to: (self basicSize min: 21) do: [ :index |
> bindings add: (index "asString""asTwoCharacterString" -> (self basicAt:
> index)) ].
> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | "self
> haltIf: [ index = 99 ]."
> bindings add: (index "asString" -> (self basicAt: index)) ].
> bindings
> addAll: ((self class allSlots
> collect: [ :slot | slot name -> (slot read: self) ]) sort
> asOrderedCollection).
> ^ bindings
>
>
> cheers -ben
>

Re: [Pharo-dev] GTDebugger variables table

[Ben Coman]

On Fri, Feb 3, 2017 at 10:21 AM, Ben Coman <b...@openinworld.com> wrote:

> On Fri, Feb 3, 2017 at 12:28 AM, Denis Kudriashov <dionisi...@gmail.com>
> wrote:
> >
> > 2017-02-02 17:16 GMT+01:00 John Brant <br...@refactoryworkers.com>:
> >>
> >> I think my preference would be to have several tabs for the variables.
> In
> >> addition to the one tab that we have now that shows all variables, I can
> >> think of tabs for locals, inst vars, interesting variables, watched
> >> variables/expressions, and stack variables. Locals would show just the
> >> method/block arguments and any temps defined in the method.
> >> Inst vars would
> >> show the object's inst vars (and maybe class vars, however these would
> only
> >> appear after the inst vars).
> >>
> >> Interesting variables would show locals and inst vars used by the
> method.
> >> The locals would be limited to the ones that are still active at the
> current
> >> location in the method. For example, if you are in a block, it would
> only
> >> show variables used in the block.
>
> >> Also, if you are before(/after) the first(/final) use of the variable,
> >> it wouldn't show in the interesting list.
>
> I'm not sure I'd like variables slipping in and out and rearranging
> the middle of the list I'm looking at.  Perhaps scope could be
> indicated another way like greying out variables.  It would be okay
> for block variables to be added at the bottom.
>
> >> Interesting variables should also do some analysis to see what accessor
> >> methods are used and show their corresponding variables.
>
> This is a nice idea.  It need not only be for interesting variables.
> Ideally it would be a tab in the next pane to the right of the [Meta]
> tab, but I guess its difficult since that pane is concerned with the
> object, and linking back to the variable holding could be difficult.
>
> >>
> >> Watched variables/expressions would be user controlled. The user could
> >> add/remove variables or expressions. These variables/expressions would
> >> remain across different methods. If a variable didn't exist in the other
> >> method, "Invalid" could be displayed.
>
> I really miss this from my TurboPascal days.
> The difficulty of course is avoiding side effects.
>
> >>
> >> Finally, stack variables would display the whole stack and not just the
> >> top item. I like the ability to see the stack top, but it really doesn't
> >> work if you want to see the first argument of a two argument message
> send.
> >> For example, if you debug "Array with: OrderedCollection new with: Set
> new",
> >> stepping over the "OrderedCollection new" immediately pushes the "Set"
> class
> >> on the stack so you can't see the "OrderedCollection new" object.
>
> Perhaps the stack could be another tab next to [Variables] ?
> Or maybe it [Stack] would be better as a tab of thisContext's next pane.
>
>
Actually you can try...

Context>>stackValueMap
| stackValues stackDepth|
stackValues := OrderedCollection new.
stackDepth := self basicSize min: 21.
(stackDepth to: 1 by: -1) do: [ :index |
|key|
key := (index = stackDepth) ifTrue: ['Top'] ifFalse: [(stackDepth - index +
1) asString].
stackValues add: (key -> (self basicAt: index))
].
^stackValues

Context>>gtInspectorStackValuesIn: composite

| stackValues |
stackValues := self stackValues.
^ (composite table)
title: 'Stack';
display: [ self stackValueMap ];
column: 'Depth' evaluated: [ :assoc | assoc key ] width: 50;
column: 'Item' evaluated: [ :assoc | GTObjectPrinter new
asTruncatedTextFrom: assoc value ]


I'm not sure whether the #stackValueMap is an appropriate name. Perhaps it
should be #methodStackValueMap or something else?  Similar for the tab
name.

And I don't know what the magic number 21 is, as I queried here...
http://forum.world.st/magic-numbers-in-gtInspectorVariableValuePairs-tp4932831.html

cheers -ben

Re: [Pharo-dev] Off Topic: Children 3-13yr english program -- 4 weeks free access

[Ben Coman]

The kid's school year in Australia starts tomorrow (here in Australia)
and another offer arrived.
http://readingeggs.com.au/hp/

Mail me privately if you find this useful, so I can track if there is
value in continuing to forward these offers.
cheers -ben

On Tue, Sep 27, 2016 at 4:17 PM, Ben Coman <b...@openinworld.com> wrote:
> On Tue, Feb 2, 2016 at 9:04 PM, Ben Coman <b...@openinworld.com> wrote:
>> On Mon, Jul 20, 2015 at 11:17 PM, Ben Coman <b...@openinworld.com> wrote:
>>> greetings all,
>>>
>>> This is a long way off topic, but a random chance someone in the community
>>> with kids learning english may find it useful.  The past year I've had my 
>>> 4yr
>>> & 6yr old girls doing Reading Eggs. Its aimed at native-english children
>>> ages 3-13 (starting with a test to place kids at a stimulating level).
>>>
>>> Its been beneficial for my kids, so I'm forwarding this offer to the
>>> community.
>>
>> There was some appreciation for this six months ago.  Another just
>> arrived, so I thought I'd share it again.  In another half year I
>> guess I'll get another, so if anyone doesn't want me to post again
>> then, let me know.
>>
>> More background info... ABC is Australia's government sponsored
>> national TV broadcaster (yay, no commercials!). They produced a web
>> site to help kids literacy.  It was fantastic for my kids, although my
>> 8 year old got bored with it later on, so it seems more suited for
>> younger ages.
>
> I've had no complaints (yet), and six months later another 5 week free
> pass arrived.
> I am a bit hesitant to continue forwarding them since its so far off topic,
> but I think there is real value for my online friends.
> http://readingeggs.com.au/pas2/?M=A2CC1945-52FE-4E22-8C1A-1614649ECE83
>
> My youngest (now 6) is starting to get a bit bored with the final 20
> levels (of 120) so again it seems to work better for the younger kids.
> Non-native-english kids may differ.
> btw, you don't need the book packs. They are all included in the online app.
>
> cheers -ben

Re: [Pharo-dev] WorkingSession UUID looks "sketchy"

[Ben Coman]

On Tue, Feb 7, 2017 at 5:59 AM, Peter Uhnak  wrote:
>
>> > On Windows (10) (with latest 6 image and VM) `Time microsecondClockValue` 
>> > returns microseconds, but (presumably the system) cannot give precision 
>> > beyond 1 second - this will imho need a VM fix;
>>
>> I find that quite hard to believe and I did not know that. Are you really 
>> sure ? That would be terrible. A solution might be to use another clock 
>> primitive.
>>
>> > I can also generate about 1.2M UUIDs per second (limited by single core I 
>> > guess), which means that about every 600-1200 consequential UUIDs will 
>> > have the same clock value.
>>
>> I can't follow your reasoning here: if the clock precision would be 1 
>> second, you would get 1.2M consecutive UUIDs with the same clock value, 
>> right ?
>
> Whoops, I meant the precision on a millisecond, not second... thus the ~1000k 
> consecutive clock values.
> The returned value is still in microseconds, but the last 3 digits are fixed 
> (they are different on startup, but same during execution).

This is a limitation of the Windows VM.  I opened an issue to work on
VM clock, but a few other side-tasks jumped above it while I was
learning more about the VM code.
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/36

cheers -ben

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

[Ben Coman]

On Tue, Feb 7, 2017 at 8:00 PM, Andrei Chis <chisvasileand...@gmail.com> wrote:
>
>
> On Sat, Feb 4, 2017 at 4:40 PM, Ben Coman <b...@openinworld.com> wrote:
>>
>>
>> > On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman <b...@openinworld.com> wrote:
>> >>
>> >> Just curious what the magic numbers here relate to...
>> >> and can they be factored out to a meaningful method name?
>> >>
>> >> Context>>gtInspectorVariableValuePairs
>> >> "This is a helper method that returns a collection of
>> >> variable_name -> value
>> >> for the current object.
>> >> Subclasses can override it to specialize what appears in the variables
>> >> presentation"
>> >> | bindings |
>> >> bindings := OrderedCollection new.
>> >> 1 to: (self basicSize min: 21) do: [ :index |
>> >> bindings add: (index "asString""asTwoCharacterString" -> (self basicAt:
>> >> index)) ].
>> >> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index |
>> >> "self
>> >> haltIf: [ index = 99 ]."
>> >> bindings add: (index "asString" -> (self basicAt: index)) ].
>> >> bindings
>> >> addAll: ((self class allSlots
>> >> collect: [ :slot | slot name -> (slot read: self) ]) sort
>> >> asOrderedCollection).
>> >> ^ bindings
>> >>
>> >>
>> >> cheers -ben
>> >
>> >
>>
>> On Fri, Feb 3, 2017 at 11:20 PM, Andrei Chis <chisvasileand...@gmail.com>
>> wrote:
>> > Yes these numbers should be refactored
>> > For collections only the first and the last 21 elements are displayed in
>> > the
>> > Raw view. Don't remember why 21.
>> >
>> > Cheers,
>> > Andrei
>> >
>>
>> Ahhh. Nice to know.  Here I was thinking it was based on some intrinsic
>> restriction on the number of variables or something.
>>
>> I'm a fan of overusing redundant variables for documenting purposes...
>>
>> Object>>gtInspectorVariableValuePairs
>> | indexableDisplayLimit bottom topLimit bottomLimit bindings |
>>
>> indexableDisplayLimit := 21.
>> top := 1.
>> bottom := self basicSize.
>> topLimit := bottom min: indexableDisplayLimit.
>> bottomLimit := (bottom - indexableDisplayLimit) max: indexableDisplayLimit.
>>
>> bindings := OrderedCollection new.
>> "Return top and bottom of indexable elements"
>> top to: topLimit do: [ :index | bindings add: (index -> (self basicAt:
>> index)) ]. bottomLimit + 1 to: bottom do: [ :index | bindings add: (index ->
>> (self basicAt: index)) ].
>>
>> "Return named variables"
>> bindings
>> addAll: ((self class allSlots
>> collect: [ :slot | slot name -> (slot read: self) ]) sort
>> asOrderedCollection).
>> ^ bindings
>>
>> If this looks reasonable I'll do up a slice.
>
>
> Looks good. I'll commit this to the inspector repo and will be picked by the
> next integration.

Thanks Andre.

Very minor thing if its not too late. Looking at it again I'd actually
rearrange these two lines like this...
  topLimit:= indexableDisplayLimit min: bottom.
  bottomLimit := indexableDisplayLimit max: (bottom - indexableDisplayLimit) .

But don't worry if you've already done the first way.
cheers -ben

>
> Cheers,
> Andrei
>
>>
>>
>> Perhaps defining "top" is overkill - but it does read nice below that.
>> btw, in general I understand that some smart optimising compilers will
>> substitute 1 for "top" directly since its assigned a literal and not
>> reassigned before its use.  I notice from the bytecode this doesn't happen
>> here.  Is there some intrinsic difficulty in our domain stopping this to
>> happen, or its just not been a priority.  I guess while stepping through the
>> debugger "top" a user might set a new value for "top" and reverting the
>> substitution of "1" for "top" needs the sort of facility that Sista will
>> provide??
>>
>>
>> On Sat, Feb 4, 2017 at 12:08 AM, Tudor Girba <tu...@tudorgirba.com> wrote:
>>>
>>> There is very little meaning behind the number.
>>>
>>> The previous inspector showed the first 100 and the last 10 elements. 100
>>> is anyway too large for a quick inspection, so we picked another number. I
>>> wanted 42 but that was still large, so we are now at 21.
>>
>>
>> Well 21 top and bottom gives you 42, and I know life, the universe and
>> everything depends on that number - so this seems reasonable.
>>
>>
>> On Sat, Feb 4, 2017 at 12:39 AM, Aliaksei Syrel <alex.sy...@gmail.com>
>> wrote:
>>>
>>> They could be extracted to class vars for example TWENTY_ONE := 21. Later
>>> if performance is still not good enough they may be changed for example to
>>> TWENTY_ONE := 15.
>>> (joke)
>>
>>
>> You mean something like this...
>> https://xkcd.com/221/
>>
>>
>> cheers -ben
>
>

[Pharo-dev] Debugging "1 ifTrue: [2]" (was Re: Debugger hang when step throught)

[Ben Coman]

On Tue, Feb 7, 2017 at 5:35 PM, Denis Kudriashov 
wrote:
> Also I found another funny issue. Try debugIt following expression:
>
> 1 ifTrue: [2].
>
> You will be wondering that debugger will not able to open.

To quickly get to the point to observe the cause, you can insert...
   Halt if: [interruptedProcess suspendedContext receiver == nil].
into DebugSession>>stepInto: just after the send of #step.

Then when you step into Context>>stepToSendOrReturn
step once over "context := self step"
and the second time step in until you get to
   Context>>jump:if:

which substitutes the following context
  Context
sender: self "=Undefined>>DoIt"
receiver: rcvr "=1"
method: newMethod "=Object>>#mustBeBoolean"
arguments: args "=#()"

such that in RubSmalltalkEditor>>debug:receiver:in:
the condition block
debugSession stepIntoUntil: [:currentContext |
currentContext method == aCompiledMethod ]
always fails, so in DebugSession>>stepIntoUntil:  the  #whileFalse:  never
exits.

A possible fix (if a bit hacky) is...
debugSession stepIntoUntil: [:currentContext |
(currentContext method == aCompiledMethod)
  or: [currentContext method selector==#mustBeBoolean]
].

cheers -ben

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

[Ben Coman]

cool. thx.

On Tue, Feb 7, 2017 at 10:46 PM, Andrei Chis <chisvasileand...@gmail.com>
wrote:

> Done.
>
> Cheers,
> Andrei
>
> On Tue, Feb 7, 2017 at 1:35 PM, Ben Coman <b...@openinworld.com> wrote:
>
>> On Tue, Feb 7, 2017 at 8:00 PM, Andrei Chis <chisvasileand...@gmail.com>
>> wrote:
>> >
>> >
>> > On Sat, Feb 4, 2017 at 4:40 PM, Ben Coman <b...@openinworld.com> wrote:
>> >>
>> >>
>> >> > On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman <b...@openinworld.com>
>> wrote:
>> >> >>
>> >> >> Just curious what the magic numbers here relate to...
>> >> >> and can they be factored out to a meaningful method name?
>> >> >>
>> >> >> Context>>gtInspectorVariableValuePairs
>> >> >> "This is a helper method that returns a collection of
>> >> >> variable_name -> value
>> >> >> for the current object.
>> >> >> Subclasses can override it to specialize what appears in the
>> variables
>> >> >> presentation"
>> >> >> | bindings |
>> >> >> bindings := OrderedCollection new.
>> >> >> 1 to: (self basicSize min: 21) do: [ :index |
>> >> >> bindings add: (index "asString""asTwoCharacterString" -> (self
>> basicAt:
>> >> >> index)) ].
>> >> >> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index |
>> >> >> "self
>> >> >> haltIf: [ index = 99 ]."
>> >> >> bindings add: (index "asString" -> (self basicAt: index)) ].
>> >> >> bindings
>> >> >> addAll: ((self class allSlots
>> >> >> collect: [ :slot | slot name -> (slot read: self) ]) sort
>> >> >> asOrderedCollection).
>> >> >> ^ bindings
>> >> >>
>> >> >>
>> >> >> cheers -ben
>> >> >
>> >> >
>> >>
>> >> On Fri, Feb 3, 2017 at 11:20 PM, Andrei Chis <
>> chisvasileand...@gmail.com>
>> >> wrote:
>> >> > Yes these numbers should be refactored
>> >> > For collections only the first and the last 21 elements are
>> displayed in
>> >> > the
>> >> > Raw view. Don't remember why 21.
>> >> >
>> >> > Cheers,
>> >> > Andrei
>> >> >
>> >>
>> >> Ahhh. Nice to know.  Here I was thinking it was based on some intrinsic
>> >> restriction on the number of variables or something.
>> >>
>> >> I'm a fan of overusing redundant variables for documenting purposes...
>> >>
>> >> Object>>gtInspectorVariableValuePairs
>> >> | indexableDisplayLimit bottom topLimit bottomLimit bindings |
>> >>
>> >> indexableDisplayLimit := 21.
>> >> top := 1.
>> >> bottom := self basicSize.
>> >> topLimit := bottom min: indexableDisplayLimit.
>> >> bottomLimit := (bottom - indexableDisplayLimit) max:
>> indexableDisplayLimit.
>> >>
>> >> bindings := OrderedCollection new.
>> >> "Return top and bottom of indexable elements"
>> >> top to: topLimit do: [ :index | bindings add: (index -> (self basicAt:
>> >> index)) ]. bottomLimit + 1 to: bottom do: [ :index | bindings add:
>> (index ->
>> >> (self basicAt: index)) ].
>> >>
>> >> "Return named variables"
>> >> bindings
>> >> addAll: ((self class allSlots
>> >> collect: [ :slot | slot name -> (slot read: self) ]) sort
>> >> asOrderedCollection).
>> >> ^ bindings
>> >>
>> >> If this looks reasonable I'll do up a slice.
>> >
>> >
>> > Looks good. I'll commit this to the inspector repo and will be picked
>> by the
>> > next integration.
>>
>> Thanks Andre.
>>
>> Very minor thing if its not too late. Looking at it again I'd actually
>> rearrange these two lines like this...
>>   topLimit:= indexableDisplayLimit min: bottom.
>>   bottomLimit := indexableDisplayLimit max: (bottom -
>> indexableDisplayLimit) .
>>
>> But don't worry if you've already done the first way.
>> cheers -ben
>>
>> >
>> > Cheers,
>> > Andrei
>> >
>> >>
>

[Pharo-dev] Pharo 6 cannot parallel trace through same method

[Ben Coman]

This has bugged me a few times recently, so I've produced a demo.
Define...

  Object subclass: #AA
instanceVariableNames: ''
classVariableNames: ''
package: ''

  AA>>test
self haltOnce.
self inform: 'I got here'.

then in playground evaluate
  Halt resetOnce. "i.e. World > Debugging > Enable all break/inspect once."
  AA new test.

and as expected you get a debugger window.
Now once again without closing the debugger ...
  Halt resetOnce.
  AA new test.

and I'd expect another debugger, but instead I'm informed 'I got here'.
Its extremely useful sometimes to parallel trace through code comparing two
cases,
and the current behaviour prevents that. .

The Pharo 5 equivalent works as expected...
  Halt enableHaltOnce.
  AA new test.

I'm not sure where to hang it, but the following test
differentiates between Pharo 5 & 6. (you can also run it from the
playground.)

 testParallelTrace
|completed p1 ds1 p2 ds2|
completed := 0.
Halt resetOnce. "enableHaltOnce"
p1 := [ self haltOnce. completed := completed + 1 ] newProcess.
ds1 := DebugSession named: 'Trace1' on: p1 startedAt: p1
suspendedContext.
ds1 resume.
Halt resetOnce. "enableHaltOnce"
p2 := [ self haltOnce. completed := completed + 1 ] newProcess.
ds2 := DebugSession named: 'Trace2' on: p2 startedAt: p2
suspendedContext.
ds2 resume.
self assert: (completed = 0)

I've opened
https://pharo.fogbugz.com/f/cases/19677/Cannot-parallel-trace-through-same-method

cheers -ben



P.S. I'm not sure if enabling the global haltOnce might cause issues.
It would be useful to be able to set it only for the DebugSession.

Re: [Pharo-dev] GTDebugger variables table

[Ben Coman]

> On 02/02/2017 11:22, Denis Kudriashov wrote:
>
> Hi.
>
> Finally I force myself to report my bad feeling of merged variable table in
> GTDebugger.
> By "merged" I mean that debugger join temps and receiver state in one table.
> Sometimes I really not like it because it is difficult to find concrete
> variable.
>
> Now I think I realized main reason of my confusion. Temps and receiver vars
> are not just in single table but they are also sorted by name all together.
>
> For example try debug #expandBy: method:
>
> (1@2 corner: 3@4) expandBy: 10
>
> You will see rows: self, corner, delta, origin, thisContext, stackTop
> Maybe in this example it is not really bad. But it shows problem.
> And imaging that there are much more inst vars in receiver object like in
> morph or Spec. It is really difficult to find desired temp.
> Actually it is also difficult to find inst var which are really used in
> selected method. And usually methods use only few variables and few temps.
> And the rest variables in table are just waste.
>
> I think we can improve this part of debugger. My idea that variable table
> should show only used temp and variables. And "self" should be selected by
> default.
> With this main table will show only important information. And on the right
> pane we will see receiver state like in the old debuggers.
>
> What you think?

I think thats a really innovative approach.  I've haven't been too
bothered by this, but I imagine it would feel like an improvement.
I'd like to try it.

On Thu, Feb 2, 2017 at 7:00 PM, Nicolas Anquetil
 wrote:
> for what it is worth, Eclipse behaves more or less as described by Denis:
>
> you see only local variables (self being one) and if a variable contains an
> object (such as self), it expands in a three to show the attributes of this
> object.

in a tree?

>
> I sometimes find it a pain to have to expand "self" to see the attributes,

but in this case it would be pre-selected and already showing in the second pane
cheers -ben

> but it is true that when there are many attributes/local variables, one gets
> easily annoyed too.

Re: [Pharo-dev] GTDebugger variables table

[Ben Coman]

On Fri, Feb 3, 2017 at 12:28 AM, Denis Kudriashov  wrote:
>
> 2017-02-02 17:16 GMT+01:00 John Brant :
>>
>> I think my preference would be to have several tabs for the variables. In
>> addition to the one tab that we have now that shows all variables, I can
>> think of tabs for locals, inst vars, interesting variables, watched
>> variables/expressions, and stack variables. Locals would show just the
>> method/block arguments and any temps defined in the method.
>> Inst vars would
>> show the object's inst vars (and maybe class vars, however these would only
>> appear after the inst vars).
>>
>> Interesting variables would show locals and inst vars used by the method.
>> The locals would be limited to the ones that are still active at the current
>> location in the method. For example, if you are in a block, it would only
>> show variables used in the block.

>> Also, if you are before(/after) the first(/final) use of the variable,
>> it wouldn't show in the interesting list.

I'm not sure I'd like variables slipping in and out and rearranging
the middle of the list I'm looking at.  Perhaps scope could be
indicated another way like greying out variables.  It would be okay
for block variables to be added at the bottom.

>> Interesting variables should also do some analysis to see what accessor
>> methods are used and show their corresponding variables.

This is a nice idea.  It need not only be for interesting variables.
Ideally it would be a tab in the next pane to the right of the [Meta]
tab, but I guess its difficult since that pane is concerned with the
object, and linking back to the variable holding could be difficult.

>>
>> Watched variables/expressions would be user controlled. The user could
>> add/remove variables or expressions. These variables/expressions would
>> remain across different methods. If a variable didn't exist in the other
>> method, "Invalid" could be displayed.

I really miss this from my TurboPascal days.
The difficulty of course is avoiding side effects.

>>
>> Finally, stack variables would display the whole stack and not just the
>> top item. I like the ability to see the stack top, but it really doesn't
>> work if you want to see the first argument of a two argument message send.
>> For example, if you debug "Array with: OrderedCollection new with: Set new",
>> stepping over the "OrderedCollection new" immediately pushes the "Set" class
>> on the stack so you can't see the "OrderedCollection new" object.

Perhaps the stack could be another tab next to [Variables] ?
Or maybe it [Stack] would be better as a tab of thisContext's next pane.

>>
>>
>> BTW, the current variable list sometimes shows 'error obtaining field
>> value' for temporaries when stepping through a method. I'm not sure why it
>> occurs, but it should always be able to display the temp variables.
>
>
> I want everything you suggest :)

So we should try in Pharo 7.
cheers -ben

[Pharo-dev] magic numbers in gtInspectorVariableValuePairs

[Ben Coman]

Just curious what the magic numbers here relate to...
and can they be factored out to a meaningful method name?

Context>>gtInspectorVariableValuePairs
"This is a helper method that returns a collection of
variable_name -> value
for the current object.
Subclasses can override it to specialize what appears in the variables
presentation"
| bindings |
bindings := OrderedCollection new.
1 to: (self basicSize min: 21) do: [ :index |
bindings add: (index "asString""asTwoCharacterString" -> (self basicAt:
index)) ].
((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | "self
haltIf: [ index = 99 ]."
bindings add: (index "asString" -> (self basicAt: index)) ].
bindings
addAll: ((self class allSlots
collect: [ :slot | slot name -> (slot read: self) ]) sort
asOrderedCollection).
^ bindings


cheers -ben

[Pharo-dev] Language Server Protocol

[Ben Coman]

Just a very brief thought, to wonder being a Language Server Protocol client
might be a path to polygot programming in Pharo.
Or if providing a LSP server might be a bridge-head
for Pharo to be integrated into larger projects.

* http://langserver.org/
*
https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md

cheers -ben

Re: [Pharo-dev] Language Server Protocol

[Ben Coman]

Hi Stefan,
Thanks for your insight.

On Wed, Feb 8, 2017 at 4:47 PM, Stefan Marr <smallt...@stefan-marr.de> wrote:
> Hi Ben:
>
>> On 8 Feb 2017, at 08:01, Ben Coman <b...@openinworld.com> wrote:
>>
>> Just a very brief thought, to wonder being a Language Server Protocol client
>> might be a path to polygot programming in Pharo.
>> Or if providing a LSP server might be a bridge-head
>> for Pharo to be integrated into larger projects.
>>
>> * http://langserver.org/
>> * 
>> https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md
>
> Just to report on my experience with the language server protocol.
> Most IDEs supporting it assume that you got a file syntax to start from.
> So, that would seem like the biggest hurdle, if you aren’t happy with change 
> sets.

Perhaps a WebDAV server interface, since in the spec I think I saw the
file references were urls.
I vaguely thought I'd seen someone had done a WebDAV server, but I
can't find the reference.

>
> Beside that, providing a basic language server for Pharo should be pretty 
> simple.
> You got already all the functionality in the image, and merely need to expose 
> it via the language server protocol to be consumed by for instance VS Code.
> So, that includes simple parser errors, lookup of senders, documentation or 
> even code critique results.
>
> To get an impression of how that could look for a Smalltalk-like language, 
> check the screenshots here:
> http://stefan-marr.de/2016/08/can-we-get-the-ide-for-free-too/
>
> and here:
> https://marketplace.visualstudio.com/items?itemName=MetaConcProject.SOMns
>
> That’s how it looks for Newspeak/SOMns.

cool.
cheers -ben

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

[Ben Coman]

> On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman <b...@openinworld.com> wrote:
>>
>> Just curious what the magic numbers here relate to...
>> and can they be factored out to a meaningful method name?
>>
>> Context>>gtInspectorVariableValuePairs
>> "This is a helper method that returns a collection of
>> variable_name -> value
>> for the current object.
>> Subclasses can override it to specialize what appears in the variables
>> presentation"
>> | bindings |
>> bindings := OrderedCollection new.
>> 1 to: (self basicSize min: 21) do: [ :index |
>> bindings add: (index "asString""asTwoCharacterString" -> (self basicAt:
>> index)) ].
>> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | "self
>> haltIf: [ index = 99 ]."
>> bindings add: (index "asString" -> (self basicAt: index)) ].
>> bindings
>> addAll: ((self class allSlots
>> collect: [ :slot | slot name -> (slot read: self) ]) sort
>> asOrderedCollection).
>> ^ bindings
>>
>>
>> cheers -ben
>
>

On Fri, Feb 3, 2017 at 11:20 PM, Andrei Chis <chisvasileand...@gmail.com>
wrote:
> Yes these numbers should be refactored
> For collections only the first and the last 21 elements are displayed in
the
> Raw view. Don't remember why 21.
>
> Cheers,
> Andrei
>

Ahhh. Nice to know.  Here I was thinking it was based on some intrinsic
restriction on the number of variables or something.

I'm a fan of overusing redundant variables for documenting purposes...

Object>>gtInspectorVariableValuePairs
| indexableDisplayLimit bottom topLimit bottomLimit bindings |

indexableDisplayLimit := 21.
top := 1.
bottom := self basicSize.
topLimit := bottom min: indexableDisplayLimit.
bottomLimit := (bottom - indexableDisplayLimit) max: indexableDisplayLimit.

bindings := OrderedCollection new.
"Return top and bottom of indexable elements"
top to: topLimit do: [ :index | bindings add: (index -> (self basicAt:
index)) ]. bottomLimit + 1 to: bottom do: [ :index | bindings add: (index
-> (self basicAt: index)) ].

"Return named variables"
bindings
addAll: ((self class allSlots
collect: [ :slot | slot name -> (slot read: self) ]) sort
asOrderedCollection).
^ bindings

If this looks reasonable I'll do up a slice.

Perhaps defining "top" is overkill - but it does read nice below that.
btw, in general I understand that some smart optimising compilers will
substitute 1 for "top" directly since its assigned a literal and not
reassigned before its use.  I notice from the bytecode this doesn't happen
here.  Is there some intrinsic difficulty in our domain stopping this to
happen, or its just not been a priority.  I guess while stepping through
the debugger "top" a user might set a new value for "top" and reverting the
substitution of "1" for "top" needs the sort of facility that Sista will
provide??


On Sat, Feb 4, 2017 at 12:08 AM, Tudor Girba <tu...@tudorgirba.com> wrote:

> There is very little meaning behind the number.
>
> The previous inspector showed the first 100 and the last 10 elements. 100
> is anyway too large for a quick inspection, so we picked another number. I
> wanted 42 but that was still large, so we are now at 21.


Well 21 top and bottom gives you 42, and I know life, the universe and
everything depends on that number - so this seems reasonable.


On Sat, Feb 4, 2017 at 12:39 AM, Aliaksei Syrel <alex.sy...@gmail.com>
 wrote:

> They could be extracted to class vars for example TWENTY_ONE := 21. Later
> if performance is still not good enough they may be changed for example to
> TWENTY_ONE := 15.
> (joke)
>

You mean something like this...
https://xkcd.com/221/


cheers -ben

Re: [Pharo-dev] [QA] quality assurance

[Ben Coman]

On Mon, Feb 6, 2017 at 4:51 AM, Hilaire  wrote:
> Hi,
>
> I discussed briefly with Steph about QA team and dedicated mailing list.
> He proposed to just use the @devel list with an appropriate [QA] tag, so
> every one can participate or just discard the topic without too much noise.

That seems appropriate.
A separate list makes it hard to draw new people in to help.
And part of the discussion can occur on the Fogbugz.

cheers -ben

Re: [Pharo-dev] PharoLauncher Hanging

[Ben Coman]

On Mon, Feb 6, 2017 at 1:52 AM, Sean P. DeNigris  wrote:
> Sean P. DeNigris wrote
>> I just had Launcher hang (Mac's spinning beach ball of death) twice in a
>> row after launching a 5.0 image with "quit on launch" disabled.
>
> Still happening fairly regularly. Pretty disruptive. I can't discern a
> particular pattern. No Debug log or crash dump. I leave "quit on launch"
> disabled because it seems that it's the only way to open multiple images
> simultaneously because Luncher will not start on Mac if there is another
> Pharo image running. Anyone else?

This triggers a vague memory from a while ago (I haven't been on osx
for a year).
Try making sure that PharoLauncher is the first VM to open.  If an
other Images are open, close them all before opening PharoLauncher.
And check your process list.

cheers -ben

Re: [Pharo-dev] AioPlugin not present

[Ben Coman]

hi David,

Maybe you could compile your own VM, adding add AioPlugin.
In my very first attempt to build the VM I found the instructions here
relatively easy .
* https://github.com/pharo-project/pharo-vm
That will give you the newest pre-opensmalltalk-vm. But maybe AioPlugin was
excluded from Linux for a reason.

However future VMs will be built from opensmalltalk-vm where you can see
plugins.int for many of the Squeak build configurations include AioPlugin.
*
https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=%E2%9C%93=AioPlugin+=Code

plus Pharo mac builds there have it...
*
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/9d4e68e555ba7b712a8c92047c95a78e840048cd/build.macos32x86/pharo.stack.spur/plugins.int
*
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/e3bc947d19a2f157cb8122396e293f5c2ba62a8f/build.macos64x64/pharo.cog.spur/plugins.int

with binaries available here...
https://bintray.com/opensmalltalk/vm/cog/201701192114#files

I don't see an opensmalltalk-vm pharo linux build yet, but I expect its in
the plan and maybe will include AioPlugin by default..

cheers -ben


On Sun, Jan 22, 2017 at 10:50 PM, Davide Varvello via Pharo-dev <
pharo-dev@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Davide Varvello 
> To: pharo-dev@lists.pharo.org
> Cc:
> Date: Sun, 22 Jan 2017 06:50:01 -0800 (PST)
> Subject: Re: AioPlugin not present
> Hi Thierry,
>
> I need it for the OSProcess. When my code calls OSProcess the warning
> (http://imgur.com/a/9jhMy) appears.
>
> It happens only once. If I close the warning window It does not happen
> again, but of course if I restart the image it appears once again, so I
> have
> to find a way to include it or another workaround
>
> Cheers
> Davide
>
>
> Thierry Goubier wrote
> > Hi Davide,
> >
> > at one point in the past, the AioPlugin was present in the latest vm and
> > not in the stable one. It seems than now this plugin is not built
> anymore.
> >
> > Do you have any special requirements on the AioPlugin?
> >
> > Regards,
> >
> > Thierry
> >
> > Le 22/01/2017 à 01:05, Davide Varvello via Pharo-dev a écrit :
> >> Other hints?
> >> TIA
> >> Davide
>
>
>
>
>
> --
> View this message in context: http://forum.world.st/AioPlugin-not-present-
> tp4929932p4930254.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>
>

Re: [Pharo-dev] Esteban's ChangeLog week of 16 January 2017

[Ben Coman]

Thanks Esteban. This is interesting to tune in on whats happening in vm and
FFI.
cheers -ben

On Mon, Jan 23, 2017 at 4:00 PM,  wrote:

> Hello!
>
> This is my weekly ChangeLog, from 16 January 2017 to 22 January 2017.
> You can see it in a better format by going here: http://log.smallworks.eu
>
> ChangeLog
> =
>
> 20 January 2017:
> 
>
>   * I'm still fixing a couple of final failing tests on iceberg,
> multi-remotes branch. Problem is that there are still somethings to
> understand
> on the "command line
> backend" (we need to find a better name for this), and the #pushTo:
> method: if I
> do it as I
> think is correct, a couple of failing tests appear... but then, I need
> to
> reflect if this is
> a problem on the functionality or on the tests.
>
> 19 January 2017:
> 
>
>   * I think I finally got the problem with FT2Plugin!
> Yesterday night talking in slack I realised that there was actually
> duplicated
> instances of
> FT2Handle hierarchy with exactly same handle  (pointer address). This,
> of
> course, causes a double free when those instances are released... and
> that's the VM crash :)
> So I quickly sketched a workaround, that you can see here:
> FT2HandlepvtDestroyHandle
> "This should only be sent from the finalizer.
> It runs inside a mutex because in strange cases it can happen that
> this is
> executed twice,
> causing a primitiveFailed to be raised."
> self class destroyMutex critical: [ | handleToRelease |
> self isValid ifFalse: [ ^self ].
> handleToRelease := self handle copy.
> self primDestroyHandle.
> "This is super-ugly, but it will prevent duplicated handles to be
> released"
> FT2Handle allSubInstancesDo: [ :each |
> (handleToRelease = each handle) ifTrue: [ each beNull ] ] ]
> and so far nobody who is testing it crashed!
> This can be important, but of course... now we need to realise why the
> duplicated instances are happening.
>   * I spent some time preparing a new way to annoy people :)
> I prepared a way to send a digest mail about my activity (this stream)
> to
> pharo-dev list.
> I hope it will not be too much.
>
> 18 January 2017:
> 
>
>   * ... and still some more work on iceberg, this time making some test
> pass on the command line backend (who is just a fallback, but well...
> we still
> need it around).
>   * Still working on UFFI 64bits. Now I introduced a new hierarchy,
> FFIArchitecture
> for now with two children:
> * FFI_i386
> * FFI_x86_64
> the purpose is obvious: to allow UFFI to handle differences between
> different
> architectures (for example,
> long has to be parsed to FFIInt32 in i386 and to FFIInt64 in x86_64).
>
> 17 January 2017:
> 
>
>   * I'm working on the UFFI support for 64bits.
> In general, it works fine, but there is a huge problem with
> structures. What's
> this problem? Well, let's take
> this simple structure as example:
> struct point {
> unsigned long x;
> unsigned long y;
> }
> Well, thing is in 32bits sizeof(struct point) = 8 while in 64bits
> sizeof(struct
> point) = 16, and of
> course this breaks our current implementation which would be something
> like this
> StructPointx
> ^ handle unsignedLongAt: 1
> StructPointy
> ^ handle unsignedLongAt: 5
> and of course, this is not correct for 64bits.
> My solution is quite simple, instead hardcoding the field offsets, I
> store those
> values into class variables
> that can be calculated each session (but just once).
> So, this structure would end looking like this:
> StructPointx
> ^ handle unsignedLongAt: OFFSET_X
> StructPointy
> ^ handle unsignedLongAt: OFFSET_Y
> this would solve the problem for most of the cases, but there is still
> the issue
> that emerges when complete
> implementation of the struct changes between platforms. I'm planning to
> implement a strategy pattern to solve
> this, but not yet (probably I will wait until having a concrete case).
> This seems to be working, but now I have other problems not related to
> UFFI:
> many people has implemented
> void * parameters of funtions as unsigned long (including me, time
> ago) which
> was correct in 32bits but
> it is not in 64bits. So now I need to review this implementations to
> see where a
> fix is needed.
> But this is not directly a problem of UFFI, I think.
>   * I worked with Nico on fixing libgit2 backend tests for iceberg.
> Now (more thanks to Nico than me, heh), test for multi-remotes branch
> are
> passing for linux but
> still not for macOS (and forget it about Pharo 5.0).
> I suspect a problem with VM, I need to review if I can configure
> smalltalkci
> to work with latest vm instead stable.
>
> 15