[Pharo-dev] Re: [ANN] New UI renderer with Hi-DPI support (Beta testing)

[Ben Coman]

Was there any recording?

On Thu, 26 Nov 2020 at 21:47, Ronie Salgado  wrote:

> Hello,
>
> Today I am giving a talk about this at 4 pm, Paris time through the
> Discord.
>
>
> Best regards,
> Ronie
>
> El mié, 25 nov 2020 a las 16:11, Ronie Salgado ()
> escribió:
>
>> Hello,
>>
>> The last months I have been working in a new UI rendering framework for
>> Pharo based on adding an intermediate scene graph with the purpose of
>> improving rendering speed, and with the side effect of making the whole UI
>> scalable and adding support for Hi-DPI rendering.
>>
>> We would appreciate that people could start testing this so that we can
>> find bugs and stabilize it. For using this the latest Pharo 9 image and
>> headless vm is required.
>>
>> Form Scene Graph repo, installation and settings repository:
>> https://github.com/ronsaldo/form-scene-graph
>>
>> Known issues:
>> - Iceberg is hanging on fetches and pushes only when using the Athens
>> backend. No segmentation fault or debugger is being launched here so this
>> is difficult to fix. When having to deal with this issue we recommend using
>> the OSWindowGenericRenderer backend (SDL2).
>>
>> Best regards,
>> Ronie
>>
>>

Re: [Pharo-dev] is it possible to send perameter from pharo to EXE ?

[Ben Coman]

I've seen some before but don't know any off the top of my head.
I'd have to try searches like. "pharo" osprocess tutorial

cheers -ben

On Thu, 9 Jul 2020 at 22:02, shawon58  wrote:

> HELLO Ben Coman
> i want to start the EXE with the height as a parameter . as u said  try
> OSPRocess, OSSubprocess or LibC, or compile your code to a DLL with "C"
> function definitions and call using FFI.
> i dont have that much idea, is there any tuturial or sample so know how to
> do that?
>
> Thanks
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] is it possible to send perameter from pharo to EXE ?

[Ben Coman]

Will that EXE already be running in parallel with Pharo before you send the
height?
Or do you want to start the EXE with the height as a parameter?

For the former you will need to open some kind of communication channel
between the two processes.
For the latter, try OSPRocess, OSSubprocess or LibC, or compile your code
to a DLL with "C" function definitions and call using FFI.

cheers -ben

On Wed, 1 Jul 2020 at 17:01, shawon58  wrote:

> Hi
> i want to know is there any way to send value like height , width etc from
> pharo to a exe file what i created using c++ file ?
>
> Thanks
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] is it possible to send data using form

[Ben Coman]

Hi shawon,

Its not clear what you are asking. Can you provide some code examples where
you "can be send from the form and can be display in the result pane"
so its more explicit what you are referring to.

Then also make up an hypothetical example showing how you would
hope to "send some value like height width from the form and save those
data as a text file".
That might help someone fill in the gaps.

cheers -ben

On Tue, 30 Jun 2020 at 11:13, shawon58  wrote:

> Hello
> Normally i know data can be send from the form and can be display in the
> result pan but i want to know is it possible to send some value like height
> width from the form and save those data as a text file ? if any one have
> idea about this please share with me.
>
>

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?

[Ben Coman]

On Sun, 24 May 2020 at 02:01, Sean P. DeNigris 
wrote:

> Esteban Lorenzano wrote
> > The easiest way I have to explain is:
> >
> > You use an OpaqueObject when you will refer to the opaque type in calls
> > as:  someFunction(opaqueobject *someArg).
> > You use an ExternalObject when you will refer to the opaque type in calls
> > as: someFunction(externalobject someArg).
>
> Very clear! We're getting somewhere :) But...
>
> What if a type is used both ways?
>
> For example:
> ^ self ffiCall: #(Method * class_copyMethodList(Class self, uint
> *outCount))
> and
> ^ self ffiCall: #(struct objc_method_description *
> method_getDescription(Method self))
>

In advance of Esteban's answer I'd like to understand better your situation
above.
Passing a method to a function seems like setting up a call-back?
Do you have a concrete C example that can be viewed in its full context?

cheers -ben

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?

[Ben Coman]

On Fri, 22 May 2020 at 15:25, Esteban Lorenzano  wrote:

> On 22 May 2020, at 04:24, Sean P. DeNigris  wrote:
>
> Esteban Lorenzano wrote
>
> The class comments are not clear?
>
>
> Maybe it's me ;-)
>
>
No. I struggled with this also, and still don't have it fully grasped.  I
could follow Eteban's advice in a particular case I asked about, but still
feel hard to reason about next time.
http://forum.world.st/typedef-pointerArity-for-FFIOpaqueObjects-td4914975.html

http://forum.world.st/UFFI-isPointer-absolute-or-versus-naturalPointerArity-td4917236.html



>
>
> Esteban Lorenzano wrote
>
> Opaque object = https://en.wikipedia.org/wiki/Opaque_data_type
> ;
> External object = a pointer to something.
>
>
> For example, why is ObjCClass a subclass of FFIExternalObject instead of
> FFIOpaqueObject when the docs say that a "Class [is] An opaque type that
> represents an Objective-C class"? Also, is the distinction just conceptual?
> I don't see what either class "buys" you in behavior since they are
> siblings
> that both pretty much have no methods.
>
>
> This is because ObjCClass = SomeOpaqueStructurePointer (is already a
> pointer), same as ObjCSelector and ObjCMethod.
> Difference is subtle, because is just a different way of representing the
> same.
>
> The easiest way I have to explain is:
>

As a prelude to my next comment, how does "External" distinguish between
the two case?
Aren't both cases dealing with external C data?

You use an OpaqueObject when you will refer to "the opaque type" in calls
> as:  someFunction(opaqueobject *someArg).
> You use an ExternalObject when you will refer to "the opaque type" in
> calls as: someFunction(externalobject someArg).
>

That makes the distinction really clear.  So if now IIUC, both cases deal
with "opaque types"
with the *only* difference between the two being the arity?
Then I propose the following naming would be more intention revealing...

OpaqueObject when you will refer to "the opaque type" in calls as:
 someFunction(opaqueobject *someArg).
OpaquePointer when you will refer to "the opaque type" in calls as:
someFunction(opaquepointer someArg).


And to test my new understanding, the matching typdefs and FFI calls would
be...

OPAQUE OBJECT
-  typedef MyOpaqueType opaqueobject.
-  int someFunction(opaqueobject *someArg)

-  FFIOpaqueObject subclass: #MyOpaqueType.
-  self ffiCall: #(int someFunction( MyOpaqueType *ot ) ).
- opaque type has arity 0, so FFI needs to take a pointer to it

OPAQUE POINTER
-  typedef MyOpaqueObject *opaquepointer.
-  int someFunction(opaquepointer someArg)

-  FFIOpaquePointer subclass: # MyOpaqueType.
-  self ffiCall: #(int someFunction( MyOpaqueType ot ) ).
- opaque type has arity of 1,  so FFI uses it directly

The latter FFI call is without the *… because FFIOpaquePointer is already a
pointer.
In practice, both FFI calls are identical, and you use the one that matches
the C header definitions.


...or maybe I still don't get it.

 cheers -ben

Re: [Pharo-dev] Squeak and Pharo why the fork

[Ben Coman]

On Sat, 16 May 2020 at 16:57, Shaping  wrote:

> You also had personality differences and disagreements which developed
> over years. Eventually the Pink plane community forked and created Pharo.
> The foundational community of Squeak (Blue plane) did not want to make the
> changes the Pink plane community wanted or required.
>
> What are the specific changes that Squeak folks don’t want to make?
>
> Squeak/Pharo is a configurable environment.  We can still have a quasi-OS
> world if we want that.  What specific aspects of the analytic and creative
> experience break or degrade for Squeak users with these specific changes,
> and also cannot be preserved by loading the right Smalltalk packages?
>

> At a minimum, not until the Squeak community could build Squeak from a
> Pharo kernel image. Then it would be possible. But I don't think likely.
>
> What are the specific problems?  Anyone?
>

I'm mainly focused on Pharo but I respect the Squeak heritage and monitor
their mail list, chipping in when I can - so I have felt comfortable
sharing the general philosophical differences between Squeak and Pharo as I
understand them.  But as to specifics, you'd probably need someone from
Squeak to pair-review the Pharo changelogs [1] with you - and that might
not even capture everything.

[1] https://github.com/pharo-project/pharo-changelogs


But lets also consider something at least as important as all the other
points... "resourcing".
Assuming all technical and political issues were dealt with, who will do
this reintegration work?
Assuming You were at a point where you were familiar with both platforms to
be capable of doing the work,
would You be willing to put aside your other interests to do at least 50%
of that work?
Because otherwise discussion around it with the idea that others do it is
pointless. :)

Note, last year I personally did have the inspiration and intention of
investigating the differences between Squeak and the Pharo Bootstrap to
understand the possibility of Squeak bootstrapping off the Pharo Bootstrap,
so there might one day they might have a common non-gui system - but other
interests ended up having a stronger hold on me.  Realistically its not
something I'll get to any time soon.

cheers -ben

Re: [Pharo-dev] Squeak and Pharo speed differences

[Ben Coman]

On Sat, 16 May 2020 at 12:56, Eliot Miranda  wrote:

> Hi Ben,
>
> On May 15, 2020, at 10:33 AM, Ben Coman  wrote:
> On Fri, 15 May 2020 at 14:09, Shaping  wrote:
>
>
>>
> *Would reintegrating Squeak and Pharo development make more sense?*
>>
>
> I think that is not likely.  Both continue to have different goals.  And a
> significant area where they are likely to continue to diverge is the
> graphics.  Squeak is likely(?) to stay with Morphic a long while Pharo
> intends to dump Morphic.
> This is one of the reasons that Spec was created - to be independence
> layer.
> IIUC in Pharo 9 Spec is already working on top of a GTK3 backend.
>
> wrt the VM, Pharo want to remove all native-windowing from the VM, so that
> window opening
> is controlled from the Image via FFI rather than the VM.  This conflicts
> with Squeak's backward comparability goals.
>
>
> The VM comprises an execution engine[1], a memory manager[2] (which share
> an object representation), and an assorted collection of plugins and
> platform support[3].  The execution engine and memory manager are the core
> support for Smalltalk language execution and are shared 100% between Squeak
> and Pharo.  And I have rearchitected this core, adding a JIT and a much
> improved object representation and memory manager.  Pharo has made *no
> change* to this core.
>
> The assorted collection of plugins and platform support are a kit of parts
> which can be assembled in a variety of configurations, just as a Smalltalk
> image can be configured in radically different ways to develop and deploy
> different applications.
>
> It is therefore not true that there is a conflict in backward
> compatibility.  The core VM is only backward compatible at a source level.
> Backward compatibility in the platform is no more than a configuration in
> the kit of parts.  And the existence of the minheadless minimal core
> platform support alongside the transitional head Gul platform proves that
> there need be no conflict.
>
> The Pharo community makes great claims about how different its VM is when
> in fact the new work that has given us much improved performance and
> scalability is shared 109% between the two.
>

Thanks for clarifying that for Shaping.  I did understand that [1] and [2]
are the same for SqueakVM and PharoVM.  My point was that IIUC Pharo is
dropping some significant parts of [3] from their VM, so a Squeak/Pharo
reintegration into a common Image running on a single VM binary could not
run old Squeak images.  Such backward compatibility I understand is
important to the Squeak community, but not so important to Pharo since
Pharo delivers a specific VM for a specific Image Release and uses
PharoLauncher to coordinate which VM to use for a given Image.  Just
another difference in philosophy the would impede a full Squeak/Pharo
reintegration.

cheers -ben

Re: [Pharo-dev] Squeak and Pharo speed differences

[Ben Coman]

On Fri, 15 May 2020 at 14:09, Shaping  wrote:

> Why can’t the OSVM be a single, unforked, maxed-out VM with all the best
> and fastest features working in Squeak and Pharo?   *Why did the split
> happen?*
>

In very general terms, the fork was due to their being Group A wanting to
go one direction
and Group B wanting to go in a different direction. i.e
B says "We want to do X".
A says "We don't want to do X."
B says "We really want to do X."
A says "Definitely no."
B says "We really want to do X and actually we're doing it over here."

In essence, Squeak considered backward compatibility of prime importance
including the code of some applications that had become entangled in the
main code base.Pharo wanted to "clean the code" by disentangling and
stripping those parts.  They also wanted to move to a
reproducible-build-system where each change "bootstrapped" a nightly image
from an empty file, whereas Squeak continues to use a
"continuous evolution" model. And there are more reasons I probably not
aware of.
Here is the Pharo Vision document circa 2012 which inspired me
https://hal.inria.fr/hal-01879346/document


It looks like a bad use of energy in a community that is small and needs to
> use its human resources efficiently.
>

Trying to go one way and dealing with continual pushback and conflict
around that is also bad energy.


 I want to help, but need to port first from VW, and I’m trying to choose
> Squeak or Pharo.  Both have speed problems.  Squeak has fewer, but Pharo
> could be much faster with broad use of Spec2.
>

>
> *Would reintegrating Squeak and Pharo development make more sense?*
>

I think that is not likely.  Both continue to have different goals.  And a
significant area where they are likely to continue to diverge is the
graphics.  Squeak is likely(?) to stay with Morphic a long while Pharo
intends to dump Morphic.
This is one of the reasons that Spec was created - to be independence
layer.
IIUC in Pharo 9 Spec is already working on top of a GTK3 backend.

wrt the VM, Pharo want to remove all native-windowing from the VM, so that
window opening
is controlled from the Image via FFI rather than the VM.  This conflicts
with Squeak's backward comparability goals.


This change would effectively create more devs willing to work on any
> problem.  This change would also prevent fracturing of feature-sets across
> the two Smalltalks from happening in the first place.
>

I personally had the inspiration that Squeak might be based off the Pharo
Headless Bootstrap,
but in the end I didn't find the time to push this further.


 Squeak and Pharo GUI styles are different.  So be it.  Can’t the GUI
> frameworks and conventions be separated in the same image, and configured
> as desired in GUI sections of Settings?
>

Pharo currently can use both Morphic and GTK3 for its GUI backend.
Possibly the GTK3 backend would provide some speed benefit (??)

cheers -ben

Re: [Pharo-dev] [Pharo-users] Pharo Quality Rules for Beginners

[Ben Coman]

On Wed, 15 Jan 2020 at 17:41, ESTEBAN VILLALOBOS DIAZ via Pharo-users
 wrote:
>
> Hello everyone!
>
> My name is Esteban and I will be working on the Pharo Quality Rules for the 
> next few months. The goal is to create different profiles for the rules 
> according to the programming experience of the user. For example, for the 
> beginner profile we would like to check for common mistakes made by people 
> who are just starting with Pharo like:
>
> Sending self as a message (probably because they forgot a . )
> Using False instead of false
> etc..
>
> I would appreciate it if you could share with me other common mistakes that 
> you have seen beginners do, or maybe tell me a bit of your own experience 
> when you started using Pharo :)

- Getting confused between instance-side and class-side, mixing up
which side methods are on.
When getting a DNU maybe check if that message is known on the class-side.

- leaving out the end of statement trailing dot.
An error message like "Blah doesn't understand self" is a bit complex
for a beginner to decipher.

cheers -ben

Re: [Pharo-dev] Iceberg Bug? Branches with $/

[Ben Coman]

On Tue, 14 Jan 2020 at 21:26, Sean P. DeNigris  wrote:
>
> Ben Coman wrote
> > I find slashes in branch names problematic
>
> Okay, you've convinced me. How do we guide people toward that policy?
> A warning when creating such branches?

That sounds reasonable. Perhaps a discrete warning icon/button appears
that opens a Help Subject
that describes that slashes are supported, but warns of a few
potential pitfalls.

cheers -ben

Re: [Pharo-dev] Iceberg Bug? Branches with $/

[Ben Coman]

Even from the command line I find slashes in branch names problematic,
because slashes are as a "remote/branch" separator incites confusion about
what is being referenced.

Other have different problems...

https://stackoverflow.com/questions/273695/what-are-some-examples-of-commonly-used-practices-for-naming-git-branches

"slashes can cause problems. Because branches are implemented as paths,
you cannot have a branch named "foo" and another branch named "foo/bar".
This can be confusing for new users."

"I'm going to start a campaign to never use slashes in git branch naming.
The reason for this is that if on a CI for example,
you want to refer to the branch name when packaging code for example, you
want to refer to the name of the branch
when building a URI or PATH (for example), perhaps building a URI in a bash
script; you will have trouble building the URI due
to the slash adding a URL part. Yes its possible to replace the slash but
it is going to take me to much time to sort out."


https://news.ycombinator.com/item?id=8872683
 "If you use '/' is branch names you can create path conflicts. I've seen
it happen and it took me a day to debug and figure out.
There is some code checking for path conflicts in the git source but it's
not invoked via all code paths that create branches.
I recommend against using slashes in branch names unless you know what you
are doing.
For example:
  $ git branch fireos
  $ git branch fireos/feature-branch
  error: unable to create directory for
.git/refs/heads/fireos/feature-branch
  fatal: Failed to lock ref for update: No such file or directory
This happens because creating 'fireos' branch stores the sha1 in file
.git/refs/heads/fireos.
But if you later want to create branch 'fireos/feature-branch', git needs
to store the sha1 in .git/refs/heads/fireos/feature-branch.
This is impossible because 'fireos' is a file and cannot be a directory.
Path conflict.

It gets even uglier when you don't discover those conflicts until a pull or
push.

cheers -ben






On Tue, 14 Jan 2020 at 07:45, Sean P. DeNigris 
wrote:

> As per common Git workflow, I named an issue branch "port/mac-pharo-7".
> When
> trying to load via:
> Metacello new
> baseline: 'VLC';
> repository: 'github://seandenigris/Pharo-LibVLC:port/mac-pharo-7';
> onConflict: [ :ex | ex allow ];
> load.
>
> I got: NotFound: Revspec 'port' not found..
>
> Bug?
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] [ANN] Embedding Image Example (Win)

[Ben Coman]

Thanks Pablo.  This will be cool to try sometime, and likely useful if I
want to distribute an app.

Now what woudl be great is an example something like embedding the VM
within a simple REPL written in C.
or something like a simple Pong game where the main loop is in C and does
the rendering,
but the game logic run in Pharo.

cheers -ben

On Mon, 13 Jan 2020 at 21:34, teso...@gmail.com  wrote:

> Hi,
>I have produced an example of using the headless VM to have an
> embedded image in Windows. The example is hosted in Github
> (https://github.com/tesonep/pharo-vm-embedded-example)
>
> The example is a CMake project to generate a new small executable that
> uses the VM as a library. Also, it shows how to perform the branding
> of applications (I have used the same Pharo icon, but we can use
> anything else).
>
> In the example, I am opening one of the SDL2 examples, it opens a
> window where we can draw in an Athens Canvas.
>
> It requires a Cygwin environment, but if you are able to build the
> headless VM you already have it!.
>
> I will do other examples of the use case we are thinking for the headless
> VM!
>
> Cheers,
> Pablo
>
> --
> Pablo Tesone.
> teso...@gmail.com
>
>

Re: [Pharo-dev] about signal

[Ben Coman]

On Sun, 12 Jan 2020 at 20:00, Sven Van Caekenberghe  wrote:

> Hi Alistair,
>
> > On 12 Jan 2020, at 09:33, Alistair Grant  wrote:
> >
> > On Thu, 9 Jan 2020 at 13:01, ducasse  wrote:
> >>
> >> Hi
> >>
> >> I wanted to explain
> >>
> >> | semaphore p1 p2 |
> >> semaphore := Semaphore new.
> >> p1 := [ semaphore wait.
> >>'p1' crTrace ] fork.
> >>
> >> p2 := [semaphore signal.
> >> 'p2' crTrace ] fork.
> >>
> >> displays p2 and p1.
> >> but I would like explain clearly but it depends on the semantics of
> signal.
> >
> > The way this is phrased seems to imply that 'p2' will always be
> > displayed before 'p1', however in Pharo this is not guaranteed (when
> > the processes are at the same priority, as they are this example).
> >
> > As Eliot implied in another reply, Pharo has #processPreemptionYields
> > set to true, which means that any time a higher priority process
> > preempts, the current process will be moved to the back of the queue.
> >
> > So in the case above, after p2 signals the semaphore, if a timer was
> > delivered or keystroke pressed, p2 would be suspended and moved to the
> > back of the queue.  When the timer / keystroke / etc. had finished
> > processing p1 would be at the front of the queue and would complete
> > first.
> >
> > Since time and input events are (for practical purposes) unpredictable
> > it means that the execution order of processes at a given priority is
> > also unpredictable.
> >
> > While this isn't likely to happen in the example above, I have seen it
> > regularly with TaskIt and multiple entries being run concurrently.
> >
> > I agree with Eliot that changing #processPreemptionYields to true by
> > default would be an improvement in Pharo.  It would make it easier to
> > predict what is happening in a complex environment.
>
> I don't understand, in your second paragraph you say 'Pharo has
> #processPreemptionYields set to true' and now you say it should become the
> default. Is that already the case or not then ?


> > Running the following variant, and then typing in to another window,
> > demonstrates the behaviour:
>
> I am not sure what you want to demonstrate: that it is totally random
> depending on external factors ;-) ?
>
> Which is pretty bad: how should semaphores be used (safely) ? What are
> good examples of real world correct semaphore usage ?
>

Bad depends on the assumptions you are working with.
The issue is its generally promoted that our scheduling is
"preemptive-across-priorities, cooperative-within-priorities"
but thats not entirely true for Pharo, which is
"preemptive-across-priorities, mostly-cooperative-within-priorities".

The former is arguably a simpler model to reason about, and having
consistent implicit-behaviour between same-priority-processes lessens the
need for Semaphores between them.
However if you naively "assume" the former you may get burnt in Pharo since
behaviour between same-priority-processes is random
depending on "when" higher priority processes are scheduled.

But if you "assume" the latter (i.e. that your process can be preempted any
time) you'd use Semaphores as-needed and have no problems.
So to reply directly to your last line. Semaphores can always be used
safely.  Its poor assumptions about when Semaphores aren't required that is
bad.


Now a new consideration for whether Pharo might change the default
processPreemptionYields to false
is ThreadedFFI.  Presumably it will be common for a callback to be defined
at same priority as an in-image process.
I can't quite think through the implications myself.
So a question... if a callback is a lower-priority than the current
process, does it wait before grabbing the VM lock (IIUC how that is meant
to work)?



> Right now, all the explanations around scheduling of processes and their
> priorities make it seem as if the answer is 'it all depends' and 'there is
> no way to be 100% sure what will happen'.
>

Reasoning about processes at different-priorities its easy and explicit.
Between processes at the same-priority you are correct, currently 'there is
no way to be 100% sure what will happen' (without Semaphores).
Examples showing same-priority processes interacting like its cooperative
will lead to student confusion when their results differ from the book.
Currently Pharo must be taught with examples presuming a fully preemptive
system (at restricted locations like backward jumps).

cheers -ben

P.S. Now I wonder about the impact of upcoming Idle-VM.  Currently
same-priority-processes are effectively round-robin scheduled
because the high priority DelayScheduler triggers often, bumping the
current process to the back of its runQueue.
When it triggers less often, anything relying on this implicit behaviour
may act differently.

Re: [Pharo-dev] about signal

[Ben Coman]

On Sat, 11 Jan 2020 at 18:01, ducasse  wrote:

>
>
> On 11 Jan 2020, at 10:50, Ben Coman  wrote:
>
>
>
> On Sat, 11 Jan 2020 at 06:31, Sven Van Caekenberghe  wrote:
>
>> Hi Ben,
>>
>> Great approach, though I would make one change to make your example
>> completely copy/paste runnable.
>>
>> Stef's original example:
>>
>> | trace semaphore p1 p2 |
>>
>> semaphore := Semaphore new.
>>
>> trace := [ :message |
>> ('[{1}] {2}' format: { Processor activeProcess priority. message
>> }) crLog ].
>>
>> p1 := [
>> semaphore wait.
>> trace value: 'Process 1' ] fork.
>>
>> p2 := [
>> semaphore signal.
>> trace value: 'Process 2' ] fork.
>>
>> trace value: 'Original process pre-yield'.
>> Processor yield.
>> trace value: 'Original process post-yield'.
>>
>> Gives:
>>
>> '[40] Original process pre-yield'
>> '[40] Process 2'
>> '[40] Original process post-yield'
>> '[40] Process 1'
>>
>> But not running the yield section gives:
>
>
>> '[40] Process 2'
>> '[40] Process 1'
>>
>
> which is an identical result if the 'Original process' traces are filtered
> out.
>
>
>
>> From this it would seem that the code in p2 continues after signal and
>> only later does p1 get past its wait.
>>
>
> Yes, a #signal does not transfer execution unless the waiting-process that
> received the signal is a higher priority.
> Within the same priority, it just makes waiting-process runnable, and the
> highest-priority-runnable-process is the one that is run.
>
>
>
> Playing with the priorities we can change that order (apparently);
>>
>> | trace semaphore p1 p2 |
>>
>> semaphore := Semaphore new.
>>
>> trace := [ :message |
>> ('[{1}] {2}' format: { Processor activeProcess priority. message
>> }) crLog ].
>>
>> p1 := [
>> semaphore wait.
>> trace value: 'Process 1' ] forkAt: 30.
>>
>> p2 := [
>> semaphore signal.
>> trace value: 'Process 2' ] forkAt: 20.
>>
>> Gives:
>>
>> '[30] Process 1'
>> '[20] Process 2'
>>
>> Again, the yield section makes no difference. So something else happened.
>>
>
> The yield made no difference because it only facilitates other processes
> at-the-SAME-priority getting a chance to run.
> Yield doesn't put the current-process to sleep, it just moves the process
> to the back of its-priority-runQueue. It gets to run again before any lower
> priority process gets a chance to run.
>
> Yielding will never allow a lower-priority-process to run.
> For a lower-priority process to run, the current-process needs to sleep
> rather than yield.
>
>
> Indeed. I will add this note to my chapter.
>
>
> Compare...
> | trace semaphore p1 p2 |
> semaphore := Semaphore new.
> trace := [ :message | ('@{1} {2}' format: { Processor activePriority.
> message }) crLog ].
> p1 := [
>trace value: 'Process 1a waits for signal on semaphore'.
>semaphore wait.
>trace value: 'Process 1b received signal' ] forkAt: 30.
> p2 := [
>trace value: 'Process 2a signals semaphore'.
>semaphore signal.
>trace value: 'Process 2b continues' ] forkAt: 20.
> trace value: 'Original process pre-yield'.
> Processor yield.
> trace value: 'Original process post-yield'.
>
> ==>
> '@40 Original process pre-yield'
> '@40 Original process post-yield'
> '@30 Process 1a waits for signal on semaphore'
> '@20 Process 2a signals semaphore'
> '@30 Process 1b received signal'
> '@20 Process 2b continues'
>
> with...
> | trace semaphore p1 p2 |
> semaphore := Semaphore new.
> trace := [ :message | ('@{1} {2}' format: { Processor activePriority.
> message }) crLog ].
> p1 := [
>trace value: 'Process 1a waits for signal on semaphore'.
>semaphore wait.
>trace value: 'Process 1b received signal' ] forkAt: 30.
> p2 := [
>trace value: 'Process 2a signals semaphore'.
>semaphore signal.
>trace value: 'Process 2b continues' ] forkAt: 20.
> trace value: 'Original process pre-delay'.
> 1 milliSecond wait.
> trace value: 'Original process post-delay'.
>
> ==>
> '@40 Original process pre-delay'
> '@30 Process 1a waits for signal on semaphore'
> '@20 Process 2a signals semaphore'
> '@30 Process 1b received signal'
> '@20 Process 2b continues'
> '@40 Original process post-delay'
>
>
>
> Stef, on further consideration I think your first examples should not-have
> p1 and p2 the same priority.
> Scheduling of same-priority processes and how they interact with the UI
> thread is an extra level of complexity that may be better done shortly
> after.
>
>
> Yes I realize it.
>
> Not needing to trace "Original process" in the first example gives less
> for the reader to digest
>
>
> Yes I thought the same.
> I thought that I could have the following strategy.
> Give a first simple version, them revisiting it after.
>

At first glance I thought using #fork would a simpler example than using
#forkAt:,
but the former interacts with the implicit priority of existing UI process,
while the latter is explicit and so actually makes a simpler example.

cheers -ben

Re: [Pharo-dev] about signal

[Ben Coman]

On Sat, 11 Jan 2020 at 06:31, Sven Van Caekenberghe  wrote:

> Hi Ben,
>
> Great approach, though I would make one change to make your example
> completely copy/paste runnable.
>
> Stef's original example:
>
> | trace semaphore p1 p2 |
>
> semaphore := Semaphore new.
>
> trace := [ :message |
> ('[{1}] {2}' format: { Processor activeProcess priority. message
> }) crLog ].
>
> p1 := [
> semaphore wait.
> trace value: 'Process 1' ] fork.
>
> p2 := [
> semaphore signal.
> trace value: 'Process 2' ] fork.
>
> trace value: 'Original process pre-yield'.
> Processor yield.
> trace value: 'Original process post-yield'.
>
> Gives:
>
> '[40] Original process pre-yield'
> '[40] Process 2'
> '[40] Original process post-yield'
> '[40] Process 1'
>
> But not running the yield section gives:


> '[40] Process 2'
> '[40] Process 1'
>

which is an identical result if the 'Original process' traces are filtered
out.



> From this it would seem that the code in p2 continues after signal and
> only later does p1 get past its wait.
>

Yes, a #signal does not transfer execution unless the waiting-process that
received the signal is a higher priority.
Within the same priority, it just makes waiting-process runnable, and the
highest-priority-runnable-process is the one that is run.


Playing with the priorities we can change that order (apparently);
>
> | trace semaphore p1 p2 |
>
> semaphore := Semaphore new.
>
> trace := [ :message |
> ('[{1}] {2}' format: { Processor activeProcess priority. message
> }) crLog ].
>
> p1 := [
> semaphore wait.
> trace value: 'Process 1' ] forkAt: 30.
>
> p2 := [
> semaphore signal.
> trace value: 'Process 2' ] forkAt: 20.
>
> Gives:
>
> '[30] Process 1'
> '[20] Process 2'
>
> Again, the yield section makes no difference. So something else happened.
>

The yield made no difference because it only facilitates other processes
at-the-SAME-priority getting a chance to run.
Yield doesn't put the current-process to sleep, it just moves the process
to the back of its-priority-runQueue. It gets to run again before any lower
priority process gets a chance to run.

Yielding will never allow a lower-priority-process to run.
For a lower-priority process to run, the current-process needs to sleep
rather than yield.

Compare...
| trace semaphore p1 p2 |
semaphore := Semaphore new.
trace := [ :message | ('@{1} {2}' format: { Processor activePriority.
message }) crLog ].
p1 := [
   trace value: 'Process 1a waits for signal on semaphore'.
   semaphore wait.
   trace value: 'Process 1b received signal' ] forkAt: 30.
p2 := [
   trace value: 'Process 2a signals semaphore'.
   semaphore signal.
   trace value: 'Process 2b continues' ] forkAt: 20.
trace value: 'Original process pre-yield'.
Processor yield.
trace value: 'Original process post-yield'.

==>
'@40 Original process pre-yield'
'@40 Original process post-yield'
'@30 Process 1a waits for signal on semaphore'
'@20 Process 2a signals semaphore'
'@30 Process 1b received signal'
'@20 Process 2b continues'

with...
| trace semaphore p1 p2 |
semaphore := Semaphore new.
trace := [ :message | ('@{1} {2}' format: { Processor activePriority.
message }) crLog ].
p1 := [
   trace value: 'Process 1a waits for signal on semaphore'.
   semaphore wait.
   trace value: 'Process 1b received signal' ] forkAt: 30.
p2 := [
   trace value: 'Process 2a signals semaphore'.
   semaphore signal.
   trace value: 'Process 2b continues' ] forkAt: 20.
trace value: 'Original process pre-delay'.
1 milliSecond wait.
trace value: 'Original process post-delay'.

==>
'@40 Original process pre-delay'
'@30 Process 1a waits for signal on semaphore'
'@20 Process 2a signals semaphore'
'@30 Process 1b received signal'
'@20 Process 2b continues'
'@40 Original process post-delay'



Stef, on further consideration I think your first examples should not-have
p1 and p2 the same priority.
Scheduling of same-priority processes and how they interact with the UI
thread is an extra level of complexity that may be better done shortly
after.
Not needing to trace "Original process" in the first example gives less for
the reader to digest

So your first example might compare...
| trace semaphore p1 p2 |
semaphore := Semaphore new.
trace := [ :message | ('@{1} {2}' format: { Processor activePriority.
message }) crLog ].
p1 := [
   trace value: 'Process 1a waits for signal on semaphore'.
   semaphore wait.
   trace value: 'Process 1b received signal' ] forkAt: 20.
p2 := [
   trace value: 'Process 2a signals semaphore'.
   semaphore signal.
   trace value: 'Process 2b continues' ] forkAt: 30.

==>
'@30 Process 1a waits for signal on semaphore'
'@20 Process 2a signals semaphore'
'@30 Process 1b received signal'
'@20 Process 2b continues'


with the priority order swapped...
| trace semaphore p1 p2 |
semaphore := Semaphore new.
trace := [ :message | ('@{1} {2}' format: { Processor activePriority.
message }) crLog ].
p1 := [
   trace value: '

Re: [Pharo-dev] about signal

[Ben Coman]

For greater visibility and comprehension, it might be useful to early in
the manual define a utility method...
Object>>crTracePriority
  self crTrace: '[', Processor activePriority printString, ']', self
printString

On Fri, 10 Jan 2020 at 13:13, Eliot Miranda  wrote:

>
>
> On Thu, Jan 9, 2020 at 5:03 AM ducasse  wrote:
>
>> Hi
>>
>> I wanted to explain
>>
>> | semaphore p1 p2 |
>> semaphore := Semaphore new.
>> p1 := [ semaphore wait.
>> 'p1' crTrace ] fork.
>>
>> p2 := [semaphore signal.
>>  'p2' crTrace ] fork.
>>
>> displays p2 and p1.
>> but I would like explain clearly but it depends on the semantics of
>> signal.
>>
>>
>> - ==p1== is scheduled and its execution starts to wait on the semaphore,
>> so it is removed from the run queue of the scheduler and added to the
>> waiting list of the semaphore.
>> - ==p2== is scheduled and it signals the semaphore. The semaphore takes
>> the first waiting process (==p1==) and reschedule it by adding it to the
>> end of the suspended lists.
>>
>
> Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2
> will start to run until something else happens after the execution of p1 :=
> [...] fork. p2 := [...] fork. So for example, if there is Processor yield
> then p1 can start to run.
>

> So you need to add code to your example to be able to determine what will
> happen.  The easiest thing would be to delay long enough that both can run.
>  1 millisecond is more than enough.
>

This is a good point.  It may be useful for the example to be expanded to...

| semaphore p1 p2 |
semaphore := Semaphore new.
p1 := [ semaphore wait.
'Process 1' crTracePriority ] fork.

p2 := [semaphore signal.
 'Process 2' crTracePriority ] fork.

'Original process pre-yield' crTracePriority .
1 milliSeconds wait.
'Original process post-yield' crTracePriority .

which would produce==>

[40]'Original process pre-yield'
[40]'Process 2'
[40]'Process 1'
[40]'Original process post-yield'

with other examples producing...

[40]'Original process pre-yield'
[30]'Process 1'
[20]'Process 2'
[40]'Original process post-yield'

[60]'Process 2'
[50]'Process 1'
[40]'Original process pre-yield'
[40]'Original process post-yield'



>
>
>> Now this sentence "The semaphore takes the first waiting process (==p1==)
>> and reschedule it by adding it to the end of the suspended lists.” is super
>> naive. Is the semaphore signalling scheduled? or not?
>>
>
> I would say these three things, something like this:
>
> "A semaphore is a queue (implemented as a linked list) and an excess
> signals count, which is a non-negative integer.  On instance creation a new
> semaphore is empty and has a zero excess signals count.  A semaphore
> created for mutual exclusion is empty and has an excess signals count of
> one."
>
> "When a process waits on a semaphore, if the semaphore's excess signals
> count is non-zero, then the excess signal count is decremented, and the
> process proceeds.  But if the semaphore has a zero excess signals count
> then the process is unscheduled and added to the end of the semaphore,
> after any other processes that are queued on the semaphore."
>
> "When a semaphore is signaled, if it is not empty, the first process is
> removed from it and added to the runnable processes in the scheduler. If
> the semaphore is empty its excess signals count is incremented.
>
> Given these three statements it is easy to see how they work, how to use
> them for mutual exclusion, etc.
>
>
>>
>> signal
>> "Primitive. Send a signal through the receiver. If one or more
>> processes
>> have been suspended trying to receive a signal, allow the first
>> one to
>> proceed. If no process is waiting, remember the excess signal.
>> Essential.
>> See Object documentation whatIsAPrimitive."
>>
>> 
>> self primitiveFailed
>>
>> "self isEmpty
>> ifTrue: [excessSignals := excessSignals+1]
>> ifFalse: [Processor resume: self removeFirstLink]"
>>
>>
>> I wanted to know what is really happening when a semaphore is signalled.
>> Now resume: does not exist on Processor.
>>
>> I will look in the VM code.
>>
>>
For quick reference, here is some relevant VM code (the StackInterpreter
code is a little simpler...)

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/pharo/headless/smalltalksrc/VMMaker/StackInterpreter.class.st#L1422-L1432

StackInterpreter class >> initializePrimitiveTable [
...
"Control Primitives (80-89)"
(85 primitiveSignal)
(86 primitiveWait)
...
]

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/pharo/headless/smalltalksrc/VMMaker/InterpreterPrimitives.class.st#L5385-L5396

InterpreterPrimitives >> primitiveWait [
| sema excessSignals activeProc |
sema := self stackTop.  "rcvr"
excessSignals := self fetchInteger: ExcessSignalsIndex ofObject: sema.
excessSignals > 0
ifTrue:
[self storeInteger: Ex

Re: [Pharo-dev] [ANN] Sysmel, another experimental low-level language implemented in Pharo

[Ben Coman]

On Thu, 9 Jan 2020 at 12:00, Ronie Salgado  wrote:

> Hi All,
>
> I am finally announcing an initial release of my new experimental
> low-level programming language which I am calling Sysmel (For SYStem
> MEtaprogramming Language).
>
> GitHub Page: https://github.com/ronsaldo/sysmel
> Short native game demo: https://www.youtube.com/watch?v=tRoPMbPvqH0
>
> Sysmel is designed to be a flexible language, and a flexible compiler
> front-end. The support for garbage collection in Sysmel is an optional
> feature by design, and the support for dynamic objects and dynamic message
> lookup it is also optional. If garbage collection is disabled, the code
> written in Sysmel is mostly equivalent to C/C++ code (only single
> inheritance is supported for now), but with a hybrid syntax between
> Smalltalk and C++.
>
> For the final code generation I am using my custom SSA intermediate
> representation (the same one that I used in Lowtalk, and in) which it is
> currently tested with the following two backends:
> - LLVM textual IR backend. This is used for generating native object files
> by reusing the LLVM infrastructure. This backend also supports emitting
> DWARF debugging information so the resulting programs can be debugged with
> gdb.
> - Spir-V backend, for generating shaders for Vulkan and executing them in
> the GPU.
>
> I am also re-implementing my previous experiment for converting Pharo
> block closures into shaders by reusing the Sysmel intermediate level AST,
> and its type inference machinery.
>

Side note, for academics needing interesting final projects for students,
one would be have this infrastructure for Pharo blocks
generate/load code for the Programmable Real-time Units on a Beaglebone -
useful for a dynamically programmable hard-real-time system for robotics.
https://www.ti.com/lit/ug/tidu461/tidu461.pdf
https://www.youtube.com/watch?v=B1DssoXzUXw
https://www.youtube.com/results?search_query=beagleboard+pru

cheers -ben

Re: [Pharo-dev] Happy new year!

[Ben Coman]

Its an hour into the new year in Western Australia.
Thank you everyone that has contributed to and supported Pharo over the
past year
and really excited about the progression of the headless VM.
Looking forward to great Pharo year in 2020.

cheers -ben

Re: [Pharo-dev] Spec row height for list of custom widgets

[Ben Coman]

On Fri, 27 Dec 2019 at 09:17, Ben Coman  wrote:

> I'm trying to adapt this example from the  Spec booklet...
>
> ListPresenter  new
>   displayBlock:  [  :x  |  x  buildWithSpec  ];
>   items: ('Files'  asPackage  classes
> collect:  [:cls | ButtonPresenter  new  icon:  cls  systemIcon;
>  label:  cls  name]);
> openWithSpec
>
> to use my own presenter rather than ButtonPresenter, but it seems to be
> only showing the first line of my presenter.  How can the height of each
> list row be changed.  i.e. for the able sample code, how to make the
> buttons taller?
>

I thought #heightToDisplayInList:  looked promising, but overriding it to
force a particular value like this...
```
ButtonPresenter subclass: MyButtonPresenter
...etc

MyButtonPresenter >>  heightToDisplayInList: aList
^200
```

then doing...
```
cls := 'Files'  asPackage  classes anyOne.
mbp := MyButtonPresenter new icon:  cls  systemIcon;  label:  cls  name.

lp := ListPresenter  new
  displayBlock:  [  :x  |  x  buildWithSpec  ];
  items: {mbp. mbp}.
lp openWithSpec.
```

didn't change the row height.

cheers -ben

[Pharo-dev] Spec row height for list of custom widgets

[Ben Coman]

I'm trying to adapt this example from the  Spec booklet...

ListPresenter  new
  displayBlock:  [  :x  |  x  buildWithSpec  ];
  items: ('Files'  asPackage  classes
collect:  [:cls | ButtonPresenter  new  icon:  cls  systemIcon;  label:
 cls  name]);
openWithSpec

to use my own presenter rather than ButtonPresenter, but it seems to be
only showing the first line of my presenter.  How can the height of each
list row be changed.  i.e. for the able sample code, how to make the
buttons taller?

cheers -ben

Re: [Pharo-dev] [Pharo-users] TaskIt

[Ben Coman]

On Mon, 16 Dec 2019 at 18:41, Santiago Bragagnolo <
santiagobragagn...@gmail.com> wrote:

> Hi everybody!
>We are starting to discuss with norbert about letting taskit to leave
> my incubator (my github account to go elsewhere). I have being thinking
> about it since long time, since i would like it to allow taskit to evolve
> into more than just my needs and wishes.
>
>The sidequestion i am bringing today it may seem (or even be) almost
> scholastic at this point, but i think it should have some space.
>The question is if to move it to pharo-contributions, or if to create a
> new pharo-processing.
>

I know a bit of what TaskIt is, but not what "processing" is in-general.
Can you clue me in?

cheers -ben

Re: [Pharo-dev] [Mm10s] 2019-12-16

[Ben Coman]

On Tue, 17 Dec 2019 at 16:22, teso...@gmail.com  wrote:

> My report, some are the same than Esteban, as we work a lot together :D
>
> ### Last week:
>
> - (Pair Programming with Esteban) Modifying the TFFI callbacks to
> include information about the Smalltalk block in the plugin data
> structure. This improves the debugging experience and the detection of
> errors when a Callback in the image side is garbage collected.
>
> - (Pair Programming with Esteban) Compiling the Queue based
> ThreaddedFFI plugin to use the latest libffi version. This is required
> to build in Catalina.
>
> - (Pair Programming with Esteban) Adding synchronization code to
> correctly interrupt the AIO waiting idle loop. This is still work in
> progress as we have to test more scenarios. This modification allows
> us to extend enormously the idle time of the relinquish processor
> primitive without losing events nor delays.
>

This is super cool.   I'm interested in seeing what the changes were.  Are
there a few commits/PRs you could point to?

cheers -ben

[Pharo-dev] Trait subclassResponsibility

[Ben Coman]

#Background
I got a critique... Replaces "a >= b and: [a <= c]" by "a between: b and: c.
for my code...  (location >= (1@1) and: [location <= (self size @ self
size)])

To test, I tried... (2@2) between: (1@1) and: (5@5)
but got... Instance of Point did not understand #between:and:
which it seems reasonable it should have since Point does define #>= and #<=

#Questions
I see  #between:and:  defined for TComparable
and thought I maybe that trait could be added to Point,
except I see also that TComparable has three "subclassReponsibility"
methods:  #< ;   #= ;   #hash
and I'm curious what is the effect of such methods being added to a class?

cheers -ben

Re: [Pharo-dev] [Vm-dev] Debugging GCC code generation

[Ben Coman]

On Thu, 12 Dec 2019 at 04:03, Eliot Miranda  wrote:

>
> Hi Pablo,
>
> On Wed, Dec 11, 2019 at 11:33 AM teso...@gmail.com 
> wrote:
>
>> Hi Nicolas,
>>   thanks for the comment, you are right the problem is the bad
>> original code. But my opinion is that it just is not reporting the
>> situation correctly, generating a warning or non-optimizing the code
>> looks more like a expected behavior. Because as I have said, using a
>> constant as index in the last statement generates a meaningful warning
>> and the non-optimizated version of the function.
>>
>> And again as you said, the only thing to learn about all this is that
>> we should not write crappy code.
>>
>
> Hang on.  "crappy code" is too strong.  Back in tre ANSI days it was not
> undefined behavior, and in fact I think this only because undefined
> behavior because C compilers were faced with lots of code where variables
> were typed int but were being used on 64-bit machines.  Had the C world
> used long as its default type then there would have been no need to make
> casting the address of a long into the address of an int undefined
> behavior.  So this isn't crappy code (if you think of what it means in
> memory on a 64-bit little endnan machine it is perfectly sensible).  It
> /is/ code that is inappropriate given C99.
>
> So yes, we have to bow to the C gods and generate C99 compliant code, but
> what we were doing here wasn't crappy, it was merely code that became
> undefined behavior so that C compilers could generate more efficient code
> for 64-bit systems in the presence of code that contains lots of integer
> variables declared as int.  So let's just say that we have to generate C99
> compliant code.  You'll notice that the Smalltalk code in the original does
> exactly what you suggest Pablo.
>

So maybe interesting to see what happens if C89 is specified...
https://renenyffenegger.ch/notes/development/languages/C-C-plus-plus/GCC/options/std


Possibly useful sanitizer...
https://developers.redhat.com/blog/2014/10/16/gcc-undefined-behavior-sanitizer-ubsa


cheers -ben

Re: [Pharo-dev] PLZ fix it for Pharo8...

[Ben Coman]

Casimiro,

I tested your change and it works well.
btw, for such a simple change, you don't even need to connect your Pharo
image to github.
Just fork the repo and make your edit directly with github's text editor at
your equal location location to this...
https://github.com/pharo-project/pharo/blob/39a50d3d/src/Tool-Catalog/CatalogProject.class.st#L40-L54


Then submit that as a PR to leave your mark on Pharo (with a good PR
description a bug entry not required).
Could you give it a go? :) :)

cheers -ben

On Wed, 16 Oct 2019 at 22:47, ducasse  wrote:

> Thanks Casimiro
>
> Why don’t you open a bug entry on github.com?
>
>
> On 16 Oct 2019, at 14:53, Casimiro de Almeida Barreto <
> casimiro.barr...@gmail.com> wrote:
>
> In the last builds of Pharo8, CatalogBrowser comes with an easily fixable
> glitch... Please could someone take a look? My humble suggestion is:
>
> ===
>
> createRepositoryURLtoNameMappings
> "Return a mapping between repositories URLs and their user names"
>
> 
> |repos|
> repos := Dictionary new.
> 3 to: SystemVersion current major do: [:v |
> repos
> at: ('http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo{1}0/main'
> format: (Array with: v))
> put: ('Pharo{1}.0' format: (Array with: v)].
> repos at: 'http://www.squeaksource.com/MetacelloRepository' put:
> 'Unsorted'.
> ^repos
>
> 
>
>
> Best wishes,
>
>
> Casimiro Barreto
>
>
>

Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019

[Ben Coman]

Nice list. Thx for posting.
cheers -ben

On Mon, 7 Oct 2019 at 22:03, Esteban Lorenzano  wrote:

>
> Hi all,
>
> Since some time we wanted to start with this report to keep you all
> informed on what we are doing to achieve our goals for the release.
> After ESUG we took some time to organise and we managed to put this in
> movement.
> The idea is to post one the first week of each month (but it may vary, as
> you see with this one who came a bit later :P)
>
> Actions reportes are just dots, since we do not have the time to add a big
> explanation and we hope you are already involved and more or less know what
> we are talking about.
> But do not hesitate to ask if you want more details :)
>
> *Roadmap progress report.*
> *September 2019*
>
>
> *Image*
>
> *Code Loading*
>
>- Profiling the time spent to load code
>- Reimplementing a better Read/Write Buffered Stream
>- Improving the performance of Source writing and reading,
>- Improving in at least 20% the time of loading code using Metacello.
>
>
> *Spec 2*
>
>- Pass on SpMillerColumnPresenter to made it of general use.
>   - Implement a specific SpMillerLayout to handle Miller columns.
>- Pass on regular input ports (transmissions subsystem) to implement
>activation ports.
>- Pass on SpStyle subsystem (kind of STON based stylesheets for
>Morphic).
>- Fix SpGridLayout horizontal cell calculous. (It was broken).
>- Fix SpBoxLayout berderWith and padding. (It was broken).
>- Added contextual menus to widgets.
>   - This functionality was completely revamped to make it work in all
>   backends.
>   - It was generalised to all widgets (even if not all should use it!)
>- Added focus order to presenters.
>   - This is also a full revamp of old existing functionality.
>   - it accepts you to change the default order, but it has a default
>   order (previous implementations forced you to do the focusing by hand).
>- Added key binding support for all widgets.
>   - This is also a full revamp of old exiting functionality.
>
>
> *Spec2+GTK3*
>
>- callbacks can now be chained. This requires some explanation: In
>Gtk3 you connect to signals. And you can connect just one callback to one
>signal. Thankfully we control the callbacks in our side, so we modified
>signal callbacks to accept to chain other callbacks (then we can connect
>several actions to one single event, for example "keypress" or “hide").
>   - along with this, we reworked the callback hierarchy.
>- implemented inheritance in Pharo of Gtk3 objects and interfaces
>(this is needed to enhance control of tables and many others).
>- added autocompletion capabilities to SpCodePresenter.
>- added a mechanism to avoid duplicate signalling between the backend
>and the adaptors.
>- Fix an important leak on GtkFormView.
>
>
> *NewTools*
>
>- Inspector
>   - it now implements Miller columns
>   - Using TaskIt as backend for stepping.
>   - extensions migrated (we are at 10% of the total of migrations
>   needed, we will enhance this in iterative way).
>- Debugger
>   - Almost complete revamp of UI.
>   - Fix context updating (to allow commands to actually work)
>   - Integrate new inspector.
>   - Work on new layouts for debugger
>- Make an experimental tool: "playbook", to concentrate playgrounds
>and test some UI ideas.
>
>
> *UFFI*
>
>- Adding Tests
>- Support for kind of literals and support type definitions in literals
>- Documentation
>- Measuring performance issues on large images.
>
>
> *TaskIT*
>
>- Implement a prototype of a distributed backend to execute tasks.
>- Implement a communication layer using Rabbit MQ
>- Implement the first version of a process manager for handling
>multiples images and workers.
>
>
> *VM*
>
>- Fixing problem with LibGIT and Windows 1903.
>- Fixing the performance issues of Windows 1903 with File accesses
>when using solid-state 4k physical sector disks.
>- XCode integration
>- Adding an initial version to detect invalid order in the return from
>concurrent callbacks.
>- Improving the implementation of TFFI to run 50% faster in callouts.
>- Build of StackVM
>
>
>

Re: [Pharo-dev] Cannot extract stable VM on Window

[Ben Coman]

On Mon, 30 Sep 2019 at 02:41, Cyril Ferlicot D. 
wrote:

> Le 29/09/2019 à 16:35, Brainstorms a écrit :
> > Hi Cyril,
> >
> > I downloaded it and tried it on Win7 Pro 64bit (running in Virtualbox),
> and
> > was able to open as expected.
> >
> > However, looking in the zip file itself, I noticed about two dozen
> > "*_Zone.Identifier" files that I was not expecting to see.  They likely
> > should not be there; they have something to do with IT security
> inspections
> > on downloaded files, and I delete them as a matter of course whenever I
> see
> > them (as part of a download).  I'm not sure why the Pharo build process
> > would have these.
> >
> > I tried launching Pharo from this zip file before and after I removed
> these
> > files...  It worked in both cases; no corruption reported.  However,
> since
> > your error dialog was reporting one of these 'zone' files, I would trying
> > removing them and see if that helps.
> >
>
> Thanks!
>
> With your comment I succeeded to launch my image. What I needed to do
> was to open the zip file without extracting it, delete all the
> .Identifier files and extract it once done.
>
> I wonder how the vm zip files end up with those files in them.
>

Looking inside...
http://files.pharo.org/vm/pharo-spur64/win/stable-20190916.zip
I see filename "FT2Plugin.dll:Zone.Identifier"
The colon in the filename is a clue that it was originally an Alternate
Data Stream attached to the root file
https://www.2brightsparks.com/resources/articles/NTFS-Alternate-Data-Stream-ADS.pdf

That ZoneIdentifier ADS wont show in a

Opening "FT2Plugin.dll_Zone.Identifier" in Notepad shows it contains...
 [ZoneTransfer]
 ZoneId=3

...which seems like its been tagged by a Windows system function into an
untrusted "Internet Zone"
http://woshub.com/how-windows-determines-that-the-file-has-been-downloaded-from-the-internet/


So it seems not-malicious, since  I'd guess an attacker would be putting it
in a "Trusted Zone"

Looking in directory... http://files.pharo.org/vm/pharo-spur64/win/
for the following at recent consecutive files, the ones marked "Y" have the
ADS

N   2019-09-13 22:188.1 MBpharo-win-x86_64-201909131927-218e97a.zip
N   2019-09-15 00:168.1 MBpharo-win-x86_64-201909142122-f5de9a4.zip
Y   2019-09-20 11:576.8 MBstable-20190916.zip
Y   2019-09-20 11:576.8 MBpharo-win-x86_64-201909161029-19f5d00.zip
N   2019-09-21 21:50   8.1 MBpharo-win-x86_64-201909211859-521c75a.zip
N   2019-09-25 19:12   8.1 MBpharo-win-x86_64-201909251551-3023fbc.zip

So it seems to be a blip related around the moment that the "stable" zip
was created.
I note that the  2019-09-20 zips  include the following additional files
the surrounding zips don't have.
SurfacePlugin.dll
SqueakSSL.dll
libfontconfig-1.dll
libexpat-1.dll
libbz2
FTPlugin.dll

Highly speculative, but one scenario could be that
"pharo-win-x86_64-201909161029-19f5d00.zip"
was downloaded to someone's machine to add those files and it got tagged by
Windows.
They then got included when " pharo-win-x86_64-201909161029-19f5d00.zip "
was rezipped and also copied to "stable-20190916.zip" ??
It would be good to understand what happened here.

A solution might be to exclude ADS when "stable-20190916.zip" is created.

btw, The `dir` command is not aware of ADS.  This can be used to
investigate...
https://docs.microsoft.com/en-us/sysinternals/downloads/streams

cheers -ben

Re: [Pharo-dev] [Pharo-users] Pumping FFI documentation [WAS] FFI beginner question

[Ben Coman]

On Wed, 25 Sep 2019 at 13:51, Stéphane Ducasse 
wrote:

> Hi
>
> Normally each time a PR is integrated in a book, the CI is generating the
> PDF.
> https://github.com/SquareBracketAssociates/Booklet-uFFI/releases
>
> So what you can do is to not bother and copy-edit and we fix the
> corresponding pillar
> if you break it.
>

Hey Stef :)
I'm guessing you mean to encourage Ted to "not worry" rather than "not
bother"
https://www.phrasemix.com/phrases/not-bother-doing-something

cheers -ben

Re: [Pharo-dev] Allow selected special characters as part of unary and keyword selectors?

[Ben Coman]

On Wed, 11 Sep 2019 at 15:10, ducasse  wrote:

>
>
> > On 11 Sep 2019, at 04:07, James Foster  wrote:
> >
> > Would use of ? and ! in unary/keyword selectors be convention or somehow
> required? If simply convention, then we should start with renaming testing
> methods to be named is* or has*.
> >   flag1 := anInteger even.“not good"
>

Agreed.  That could "almost" be construed  as converting a 3 to a 2 or 4.


>   flag2 := anInteger isEven.  “better"
>

Agreed. It reads well.


>   flag3 := anInteger even?.   “how much better?”
>

For me, this doesn't read as well as flag2, but even though there is some
redundancy, for me a combination reads well...
 flag3a := anInteger isEven?
Perhaps if "?"==>Boolean was a strong convention then there could be a
check when the value is returned rather than when it is used (or would that
complicate other things?)


>   flag4 := #(1 2 3) includes?: 2. “how much better?”
>

My first impression is "yuck!", but then I think... "maybe" if there was a
definite benefit (i.e. optimization) from strong guarantees about the
return value being Boolean.



>
> I think that I would use ? mainly for unary message
>
> Now I’m sure that if you look carefully some people use
>
> include
> for the action
> includes
> for the tests
>
> I took include as an example and this is super not intention revealing.
>
> >> lineUpBlockBrackets
>
> lineUpBlockBrackets?
> Now I will rewrite them all as shouldLineUpBlockBrackets or
> isLineUpBlockBrackets and to me for unary message ? makes it a lot better.
>

btw, some alternatives...
doBlockBracketsLineUp   - reads well but "do" is already a loaded word
areBlockBracketsLinedUp - reads well with the past-tense phrasing

cheers -ben

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

[Ben Coman]

On Mon, 12 Aug 2019 at 17:59, teso...@gmail.com  wrote:

> Hi,
>the repos is https://github.com/pharo-project/opensmalltalk-vm in
> the headless branch
>

btw, to go directly to that branch...
https://github.com/pharo-project/opensmalltalk-vm/tree/headless

I'm really glad to see smalltalksrc on github for its accessibility.
The concern then is synchronization with the original Monticello repo.
Could a branch "headless-tracking-vmmaker" be created as a pure-mirror
updated by a daily CI job
so Github Compare View  can be used to easily see differences (
https://github.blog/2010-03-01-introducing-github-compare-view/)
This would make it easier for anyone to experiment locally merging in
vmmaker updates without needing access to the particular conversion-tool
being used.
That is, it would fan out better to potential contributors.

It might be useful to similarly have an independent
"headless-tracking-extracted".
How is the extraction currently being done?
Is it a script being run adhoc by particular people or is it run by a CI
job?
Again it would fan out better to potential contributors to not need access
to the extraction script.

cheers -ben

Re: [Pharo-dev] [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Ben Coman]

On Fri, 30 Aug 2019 at 15:34, Julien  wrote:

> Hello,
>
> I opened that issue: https://github.com/pharo-project/pharo/issues/4442
>
> And I think to fix it we need to actually discuss about what we want.
>
> #allButFirst: behaves differently depending on the actual type of
> sequenceable collection when argument is greater than collection size.
>
> For instance:
>
> #(1 2) allButFirst: 3.  "PrimitiveFailed signaled"
> (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled"
> (OrderedCollection with: 1 with: 2) allButFirst: 3.  "an
> OrderedCollection() »
>
> The question is then, who is right?
>

Its worthwhile to at least survey other Smalltalks.
For Visualworks...
  #(1 2) allButFirst: 3.  "==> #()"
  (OrderedCollection with: 1 with: 2) allButFirst: 3.   "==>
OrderedCollection ()"
  (LinkedList with: Link new with: Link new ) allButFirst: 3.  "raises
an error Subscription out of bounds error"
and also...
  (LinkedList with: Link new with: Link new ) allButFirst: 2.  "raises
an error Subscription out of bounds error"

I feel that proceeding-without-iterating is nicer than
showing-an-application-error.
It provides the opportunity to not-check the number elements or wrapping
error handling around it - i.e. less code if its not important.
If its important not to exceed the number of elements, then that check can
be explicitly coded.

cheers -ben

Re: [Pharo-dev] possible Windows Update "1903" Iceberg problem

[Ben Coman]

hi Stef,
I feel you missed my point. Probably I wasn't clear this has already been
tested with latest Pharo 8 launched by PharoLauncher.
The problem occurs with Pharo 7.0.3(64 bit) and with
Pharo8.0-SNAPSHOT-build.635(64 bit)
after Microsoft Windows Update 1903...
https://www.computerworld.com/article/3409621/microsoft-starts-windows-10s-1803-to-1903-forced-upgrade.html


If indeed 1903 is the cause, with this update now being *forced* down on
people, this will potentially soon impact more and more Windows users.
But my guess that 1903 is the culprit needs to be confirmed.
So I am requesting someone with access to multiple Windows machines
directly compare a 1903 machine with a pre-1903 machine.

cheers -ben

On Sat, 17 Aug 2019 at 12:58, ducasse  wrote:

> Hi ben
>
> in the pharo launcher if you click on P8.0 (development version) you get
> access to all the builds.
>
> Stef
>
> On 16 Aug 2019, at 16:02, Ben Coman  wrote:
>
> IThis morning the May 2019 Windows Update "1903" forced itself onto my
> computer and now 64-bits Pharo seems to have a problem with
> git_remote_fetch() FFI callout.  I no longer have a non-1903 machine to
> directly compare behaviour before "1903".  Can someone familiar with this
> area with both "pre-1903" and "1903" machines triage whether "1903" is
> indeed the cause?
>
> A few other recent reports are noted here...
> https://github.com/pharo-project/pharo/issues/3418
>
> cheers -ben
>
>
>

[Pharo-dev] possible Windows Update "1903" Iceberg problem

[Ben Coman]

IThis morning the May 2019 Windows Update "1903" forced itself onto my
computer and now 64-bits Pharo seems to have a problem with
git_remote_fetch() FFI callout.  I no longer have a non-1903 machine to
directly compare behaviour before "1903".  Can someone familiar with this
area with both "pre-1903" and "1903" machines triage whether "1903" is
indeed the cause?

A few other recent reports are noted here...
https://github.com/pharo-project/pharo/issues/3418

cheers -ben

[Pharo-dev] Breakpoint restart error

[Ben Coman]

I trying to set a breakpoint programatically so that users can be dropped
into the custom script they can add to a system. I try...

Object compile: 'myTest
  |a b c|
  a := 1.
  b := 2.
  c := 3'.
Breakpoint new node: (Object>>#myTest) ast; install.
Object new myTest.
"click   "

but the following error appears and the debugger gets confused...
[image: image.png]

What am I doing wrong?

cheers -ben

Re: [Pharo-dev] Pharo process scheduling

[Ben Coman]

On Mon, 29 Jul 2019 at 17:40, Alistair Grant  wrote:

> Hi Everyone,
>
> I'm trying to get a better grip on process scheduling in Pharo but
> don't understand the behaviour I'm seeing.
>
> My understanding is that the VM (which does the real work of
> scheduling the processes) is a pre-emptive co-operative model,
> meaning:
>
> - Higher priority processes are always scheduled ahead of lower
> priority processes.
> - Processes at the same priority get the CPU until something is done
> to explicitly stop processing, e.g.:
> -- terminate the process, wait on semaphore (I/O, timer, mutex, etc.),
> #yield the processor
>
> But given the following:
>
> | p x a index |
>
> p := 35.
> a := Array new: 20.
> index := 1.
> [ 1 to: 10 do: [ :i |
> [ a at: index put: i.
> index := index + 1.
> x := 0.
> 3 timesRepeat: [ x := x + 1 ].
> a at: index put: i.
> index := index + 1. ] forkAt: p named: 'Proc', i asString ].
> ] forkAt: p+1.
> a.
>
>
> The code above was written to be as simple as possible (it isn't going
> to be creating streams, have semaphores etc. called somewhere deep
> within).  The 3 number was manually determined as something
> that will run for a few seconds on my laptop.
>
> Since the forking process is higher priority than the 10 worker
> processes, I expect that all 10 processes will be created before the
> first gets any CPU, and they will then be executed in order (since
> there is nothing obvious to cause a context switch), and the results
> to be:
>
> #(1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10)
>

Wow, I find I've been working under a mis-understanding for years.  I
thought this was how Pharo operated.
I just checked Squeak. It gives this result since it has...   Smalltalk vm
processPreemptionYields "==> false"
Pharo has... Smalltalk vm processPreemptionYields "==> true" since at least
Pharo 2.0.

Some pertitant background...
[1]
http://forum.world.st/User-interrupt-does-not-always-break-UI-process-tp3619983p3623236.html
[2]
http://forum.world.st/Stopping-a-Smalltalk-process-from-lldb-gdb-tp4917963p4918000.html

So would Pharo having "processPreemptionYields: false" be beneficial to
match Squeak & VisualWorks?
btw, what does "safer" [1] mean?

Or... even though we are a long way from running multi-CPU, would a system
working with "processPreemptionYields=>false"
be more ready to run threaded on multi-CPU?  Or is that too far away to be
concerned with?

How would assumptions around  "processPreemptionYields=>false"  be affected
by FFI callbacks ?

cheers -ben

Re: [Pharo-dev] [Pharo-users] "whenSelectedItemChanged:" in Spec

[Ben Coman]

Following on from something I noticed commenting on "[Pharo-users]
"whenSelectedItemChanged:" in Spec"...

On Wed, 17 Jul 2019 at 08:38, Ben Coman  wrote:
> Looking at ListPresenter>>whenSelectedItemChanged: aBlock
> it is registering aBlock on selectionHolder using #whenChangedDo:
> Reviewing selectionHolder "Code search...>References to it" I see that
> selectionHolder is initialized as an instance of SelectionHolderClass.
>
> So it seems you are expecting whenSelectedItemChanged: to be called
> every time the-selection-is-changed
> when actually it is only called once (by your application) to register
> the block-to-be-called when the-selection-is-changed.
> You don't seem to have done any such registration.

It seems awkward that the SelectionValueHolder used by ListPresenter
allows  #index: and  #selection:  to be set independently making it too
easy to get insistent state.
Multi-selection also has a completely different basis using
IdentityDictionary
with the boolean "multiSelection" indicating some widget specific handling
to distinguish between the two selection-types that may be duplicated a lot
elsewhere.

It might be nice to have a generic SelectionWrapper class
that behaved a bit like a PositionableStream to encapsulate any
"collection" as its first instance variable, with "positions" as its only
other instance variable.
Selected-values would be a derivation of those two instance variables.
"positions" is used rather than "index" since the latter feels
1-dimensional and it should work just as well with a 2-dimensional
grid/table.
For an event-driven facility it might subclass Model, or it may be simpler
to have its own Announcer.

WDYT?
Would such a class be worthwhile?
Where in the system might this reduce code duplication? (which would define
its requirements)
Are there any existing candidates? (Reviewing Spotter('selection') doesn't
indicate anything. The closest is SelectionMorph which has baggage and
works with items rather than positions)

cheers -ben

[Pharo-dev] SessionErrorHandlingTest UI lockup

[Ben Coman]

In Pharo 80482 I am experiencing a UI lockup running...
SessionErrorHandlingTest>>testErrorCaughtAndDefferedIfExceptionSignaledAtStartupWhenStartupUiManagerActive

Can anyone else confirm?

cheers -ben

Re: [Pharo-dev] Changes proposal on Pre debugger

[Ben Coman]

On Thu, 11 Jul 2019 at 22:30, Cyril Ferlicot  wrote:
>
> On Thu, Jul 11, 2019 at 4:22 PM Peter Uhnak  wrote:
> >
> > Hi Cyril,
> >
> > I had a particular use-case in Sentry Logger (adopted from old ShoreLine 
> > reporter) that added a "Report" button to the pre-debugger (via a 
> > PreDebugAction subclass). Not having the button is fine for me (automated 
> > reporting is always better), just wanted to mention it.
> >
> > What I am wondering more is whether eliminating the pre-debugger would make 
> > it much harder to add something like "Production pre-debug window" that 
> > contains alternative content that doesn't scare non-technical people.
> >
> > Not all users of Pharo are Pharo developers, so dropping on them the full 
> > debugger is not good.
> > Would it be cleaner to enable by default the Always Open Full Debugger, and 
> > then it can be toggled off when building production images?
> >
> > Or did you have some other alternatives in mind?
> >
>
> Hi Peter,
>
> With changes introduced with the GTDebbuger it is possible to register
> alternative debuggers. They have a priority and know if they need to
> open depending on the context.
>
> We discussed with Steven and Thomas from the RMoD team and we think
> this is cool like that we can register alternative debuggers.

That would be cool - especially if it comes with a good Settings UI to
make it more discoverable
and good in-Image Help on how to create such an alternative debugger ;)

cheers -ben

Re: [Pharo-dev] Changes proposal on Pre debugger

[Ben Coman]

On Thu, 11 Jul 2019 at 16:42, Cyril Ferlicot  wrote:
>
> On Thu, Jul 11, 2019 at 7:17 AM Ben Coman  wrote:
> >
> >
> > I'm not sure how I feel.  I usually click in the Pre-Debugger stack
> > rather than click the  button.
> > When doing TDD I'll often know that the method I want to open is four
> > down in the stack rather than where the library method bombed out.
> > But really at worst its one additional click and probably easy enough
> > to adapt so I'm willing to give it a go.
> >
>
> Hi Ben,
>
> In your case there will be no change. You will still click one time
> four down in the stack.
>
> Or did I miss something?

doh! of course you are right. I didn't think that through.
So no objection from me.
cheers -ben

Re: [Pharo-dev] Changes proposal on Pre debugger

[Ben Coman]

On Thu, 11 Jul 2019 at 02:22, Cyril Ferlicot D.
 wrote:
>
> Hi,
>
> After talking with Steven (in copy) we agreed on possible improvements
> around the pre debugger. I would like to share our vision and check if
> the community agrees.
>
> Context:
>
> The pre debugger is the window opening when an exception is signalled
> and not catched. This window currently has two views:
> - On warnings it display a text explaining the encountered problem. You
> can the proceed, abandon or debug. For example, this happens on
> Deprecations.
> - On other exceptions it display a short stack of the context in which
> the error was raised. You can abandon, open a full debugger, ...
>
> Before, both views were managed via the same UI class. Yesterday I
> slitted this class.
>
> Proposed change:
>
> In our opinion, the pre debugger displaying a stack is useless. All the
> options it proposes are in the full debugger within one click reach. The
> only value we see for the pre debugger is about warnings.
>
> Thus, we propose to remove the stack pre debugger and display directly
> the full debugger for anything else than a warning. This will save
> everyone one click each time we want to debug something. We would keep
> the textual view for warnings.
>
> In case we do this, I wonder if we should keep the setting "Open full
> debugger". I think most users of this option are using it in order to
> not see the stack pre debugger and not to skip warnings. So, do someone
> have an opinion about keeping or removing this setting in case we remove
> the stack pre debugger?

I'm not sure how I feel.  I usually click in the Pre-Debugger stack
rather than click the  button.
When doing TDD I'll often know that the method I want to open is four
down in the stack rather than where the library method bombed out.
But really at worst its one additional click and probably easy enough
to adapt so I'm willing to give it a go.

cheers -ben

Re: [Pharo-dev] Additional Divider in Pharo menu

[Ben Coman]

Pharo Zen says: Explicit is better than implicit.
http://blog.pharo.fr/pages/PHARO-Zen

On Thu, 4 Jul 2019 at 21:53, Esteban Maringolo  wrote:
>
> The ***convention*** for exiting anything that requires saving is using a
> Yes/No/Cancel interaction.
>
> Yes: Exit and save.
> No: Exit without saving.
> Cancel: Do nothing.

Thanks for the clarification.
So indeed this a case in point.  The implicit semantics were not clear
to me.  (I don't think I've ever pressed No - only Yes or Cancel).
This would be better:
Save: Exit and save.
Discard: Exit without saving.
Cancel: Do nothing.

Taking as inspiration Marcus' trivial-fix-a-day, rather than just
chatter about it, here is my action...
https://github.com/pharo-project/pharo/pull/3774

cheers -ben

[Pharo-dev] Iceberg > trouble creating branches

[Ben Coman]

In latest Pharo 8.0 (2019-07-05)(55f0b29)
in Iceberg going Pharo > Create new branch from Issue
is not picking up Issues from Github, only from Fogbugz.
I'm half-sure that its been working for Github Issues ??

Then also Repository > Branch button is reporting
an error with DropListPresenter "NotFound: selectedItem ..."
called from
IceTipSelectRemotePresenter >> initializeWidgets

I guess some of this is the in-progress Spec2 updates.
For others, I found a working option with Packages > Branch button.

cheers -ben

Re: [Pharo-dev] Additional Divider in Pharo menu

[Ben Coman]

On Thu, 4 Jul 2019 at 19:37, Torsten Bergmann  wrote:
>
> Hi,
>
> around 20 days ago the order of menu items in the Pharo world menu were 
> munged up in the standard Pharo 8
> image for whatever reasons. "Safe" was on first position and not grouped with 
> other "Save ..." items anymore as it was
> in the past. This was noted by Alexandre Bergel and others on Discord.
>
> I fixed the order in the following PULL REQUEST 
> https://github.com/pharo-project/pharo/pull/3529
> with the menu ending up looking like this:
>
>   !
>   ! SETTINGS
>   !
>   ! SAVE
>   ! SAVE AS
>   ! SAVE AND QUIT
>   !
>   ! QUIT
>   !
>
> having added by intention an additional divider between
>  - the more safe options to store the image (secure)
>  - the unsafe quit where one can loose changes in the image (insecure if you 
> just quit)
>
> I know that "SAVE AND QUIT" and "QUIT" also might belong somehow together as 
> both exit the image
> - but  the diver should separate the more secure options from the more 
> insecure options.
>
>
> Now today the divider was removed again using 
> https://github.com/pharo-project/pharo/pull/3738
> from Cyril Ferlicot mentioning it as "unwanted" - so now the menu looks like 
> this:
>
>   !
>   ! SETTINGS
>   !
>   ! SAVE
>   ! SAVE AS
>   ! SAVE AND QUIT
>   ! QUIT
>   !
>
> as it was back in Pharo 7.
>
> As I'm someone who is mousing around very quickly in the past it often 
> happened to me that while I wanted to
> really "SAVE AND QUIT" I hit accidentally the "QUIT" button directly below - 
> leaving me in a state where I had
> to recover or reapplying changes afterwards.
>
> So using the additonal divider between the three "safe my data" options and 
> the "just leave" was intentional and to
> me makes some sense: from the point of view of grouping, visually and from 
> clicking behavior.
>
> I guess Cyril Ferlicot wanted to restore how it looked in Pharo 7 or had 
> other reasons why he prefers the menu to
> look like in the second picture.
>
> I know it is not a big thing - but nonetheless: It would be good if others 
> could write which option
>
>   a) WITH DIVIDER (as in first picture to separate safe from unsafe options) 
> or
>   b) WITHOUT DIVIDER (as in second picture to stay like it was back in Pharo 
> 7)

Separating dangerous options from the safe options seems a good idea -
Both for physical jitter and also cognitively.
Even though Quit presents a confirmation dialog, I've had
cognitive-fails clicking YES instead of NO**.
so WITH DIVIDER + 1

Further, I personally use Save much more often than Settings.
I'd prefer Save on the top line and Settings above Quit
I advocated this prior to midway through Pharo 7 but got no response.
It would provide even greater separation.

Some Settings menu-item placement examples...
https://www.top-password.com/blog/wp-content/uploads/2017/04/chrome-menu.png
https://ntopology.com/wp-content/uploads/2019/01/FileMenu.png
https://ggnome.com/wiki/images/d/d6/FileMenuWin.png
https://www.mozenda.com/wp-content/uploads/2016/01/AgentBuilder-File-Settings-CursorHighlight-Arrow-274x300.png

cheers -ben


**P.S.  I'm generally opposed to YES/NO buttons.  Its easy to invert
logic when your in a hurry.
A confirmation dialog QUIT/STAY is much more explicit.
Rule #1 ==> 
https://uxmovement.com/buttons/5-rules-for-choosing-the-right-words-on-button-labels/

Re: [Pharo-dev] Loading project with Pharo

[Ben Coman]

On Thu, 27 Jun 2019 at 21:41, Jannik Laval  wrote:

> Dear pharoers,
>
> I use Pharo in Windows 10 and MacOS.
> I find a big difference of loading time between the 2 systems.
>
> For loading Moose for example, In MacOS, it takes few minutes, but in
> Windows 10 it takes more than 15 minutes.
> Also when I load Voyage, in MacOS, all loads correctly, but on Windows the
> path length is too long and generate an error.
>

I expect the repo is in FIleTree format which has two problems on Windows:
* "file per method" produces a massive number of small files which the
system struggles with
* long pathnames exceed Windows 256 character limit.

Tonel "file per class" format was designed to resolve both these problems
on Windows (IIUC).

cheers -ben

Re: [Pharo-dev] Zinc-FileSystem-SvenVanCaekenberghe.20.mcz Empty .st

[Ben Coman]

greetings,

To assist, others need to be able to reproduce your problem. For that, we
it helps to know:
a. what operating system and version you are using
b. what Pharo version you are using (and where you downloaded it from)
c. where you are getting that file from
d. Starting with a fresh Image, the steps to cause the problem

cheers -ben

On Tue, 4 Jun 2019 at 08:45, lpaniceres  wrote:

> I'm experiencing a problem with tha package
> Zinc-FileSystem-SvenVanCaekenberghe, MOnticello downloas the file
> Zinc-FileSystem-SvenVanCaekenberghe.20.mcz with an empty source.st.
>
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] Environments

[Ben Coman]

On Sun, 2 Jun 2019 at 21:24, Shaping  wrote:

>
> https://pharoweekly.wordpress.com/2019/04/18/pre-ann-spec-2-0-gtk3-bindings/
>
> And that’s it. Pharo 8.0 will come with Spec 2.0 and users will be able to
> benefit of it immediately [image: 🙂]
>
> Pharo 80 will not need Gtk3. We will provide packages for Gtk3 for the
> people that need it. We will also release Spec20 soon so that people can
> try Spec 20 – independently of Gtk3
>
> “
>
>
>
> https://github.com/dionisiydk/Spec2
>
>
>
> I don’t see Spec2 in Pharo 8.  I suppose I need to load it.
>
>
>
> Is the Spec book still relevant?  Is Spec2 mostly about the back-end
> changes for use of GTK?
>
>
> This may interest you...
https://www.slideshare.net/pharoproject/spec-20-the-next-step-on-desktop-ui

cheers -ben

Re: [Pharo-dev] Environments

[Ben Coman]

On Sun, 2 Jun 2019 at 07:01, Shaping  wrote:
>
> Does anyone have experience with Squeak Environments?  This came up in the 
> Cuis list.  Environments are Squeak’s attempt at a module or namespace 
> system.  Does this exist for Pharo?  Has anyone worked with it, and found it 
> to be usable?

I'm fairly sure Environments hasn't been ported to Pharo.  Namespacing
is still on open question on Pharo.
The little I know about the topic is that its complicated since it can
introduce as many problems as it solves.
its something that is wanted, but priorities have taken precedence.
A bit work being done in the background should support namespaces when
there are resources to "get it right" ...

http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-tp4983800p4990734.html

For the moment, best best is a few tips on converting from namespaces.
http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334

cheers -ben

Re: [Pharo-dev] Versioning with Iceberg

[Ben Coman]

HI Shaping,
Its interesting getting your fresh eyes perspective on this.
Often I become so fluent in working around it blunts my awareness of
how it comes across to newcomers.

On Fri, 31 May 2019 at 18:45, Shaping  wrote:
> >
> > So are you trying to actually contribute to Pharo? You don’t normally need 
> > to reload pharo (if I’ve understood what you are doing).
>
> Yes, generally to start, I need to track my changes on 7.0.3, save them down 
> to a local repo, and have a way to use that local repo (Iceberg-on-Git repo) 
> to regenerate an image that is 7.0.3 plus my stuff or 8.0 plus my stuff when 
> 8.0 is in better shape.

Is your application making a lot of changes to existing Pharo code?
Are you aware of "extension methods" ? Where a method you add to a
built-in Pharo class (Collection for example) is saved/loaded with
your package.
Then you only need to manage your package not Pharo built-in packages as well.


> This is a really important loop for anyone trying to switch environs, and it 
> should get lots of attention and TLC from Pharo veterans wanting Smalltalkers 
> to migrate to Pharo.  If the new guy can do that loop reliably and 
> repeatedly, the probability that he sticks around and pushes on with Pharo, 
> instead of running back home to VW (done this a lot), increases greatly.  And 
> along the way, there should be no VM crashes.   I still need to determine 
> what caused those.


> > - if you pick Add, then choose GitHub, then enter the owner and project 
> > (e.g. for exercism - owner = exercism, project = pharo-smalltalk), this 
> > will get you the baseline (but won’t load any packages).
>
> After I do the above, Iceberg lists a repo called pharo-smalltalk.  Was this 
> intentional?

Yes, this the the repo name assigned by the Exercism administrators.
The Exercism project has 50 language tracks each with their own
repo... https://github.com/exercism
The Pharo Track repo is https://github.com/exercism/pharo-smalltalk


> Above is the Exercism GitHub page.  The URL and doc mention both Exercism and 
> pharo-smalltalk, but the former is not found in the GUI anywhere to tell the 
> user what he has (without additional digging).
> I just cloned Exercism.  I thought it would be identified somewhere besides 
> in the Git commit comments.  The Iceberg repo context menu item Repository 
> (strange name given that we are already in an Iceberg repo) lists the repo as 
> ‘Repository of pharo-smalltalk’  with a master node, origin node and several 
> version tags.

How much have you used git?
Cloning the Pharo Track repo from the command line is done like this...
   $ git clone g...@github.com:exercism/pharo-smalltalk.git
which creates a folder with the same name as the repo (i.e. "pharo-smalltalk")
As a git GUI, Iceberg does the same.  Indeed, Iceberg uses libgit2 to
do this, so the behaviour is standard git.


> These can’t be Pharo versions because the numbers are too small.   They must 
> be Exercism versions,

yes.

> but ‘exercism’ isn’t mentioned anywhere, except in some of the Git commit 
> comments, or I missed it.  So there is some immediate disorientation on that 
> account.  If I choose Packages on the Iceberg repo context menu, I can see 
> that this repo is all about Exercism.

Would a hover tool tip showing "owner/repo" clear this up for you?

@Tim, another way to mitigate such user confusion would be to separate
the tools out from  https://github.com/exercism/pharo-smalltalk
into https://github.com/pharo-exercism/exercism-tools.


> Would the Iceberg GUI make more sense as a split pane arrangement where the 
> stuff listed in the Repository window is shown in the right pain after 
> selecting a well-named Iceberg repo in the left pane?  We could have 
> bubble-help on the listed repos and details in the right pane on repo 
> selection.

I can't parse that description.  A graphical mockup would be more
useful to discuss.


>> Now you have to right click on the repository, and pick the Metacello menu 
>> item, and then you can load baseline (which gives you the default), or you 
>> can enter a group name (e.g. ‘dev’ for exercism).
>
> I loaded the default baseline and see 4 packages up to date and the rest 
> unloaded.

Thats right, the default-baseline is for students. The other packages
are only required by mentors & maintainers.


> When I tried ‘dev’ I got an assertion failure on the SSH creds.  Did I miss a 
> step concerning SSH creds on install?  But the loading seemed to continue.

Given that it already loaded the 4 packages, your SSH creds have
already been proven working.
Before considering this further, just need to ask how reliable your
internet connection is?
A poor connection might also explain some of your PharoLauncher
"identifying VM version" issues.


> I also got the error:
>
> LGit_GIT_EEXISTS: Failed to stat file '
> F:/_personal/Pharo/images/Shaping 7.0 - 64bit 
> (stable)/pharo-local/iceberg/dionisiydk/Mocketry/Mocketry-Specs-Tests.package/SpecOfExpectedObje

Re: [Pharo-dev] VM crash in Pharo 8.0 during save

[Ben Coman]

On Wed, 29 May 2019 at 21:21, Shaping  wrote:

>
>
> I made a few cosmetic changes (labels in Calypso).  They were working
> fine.  But they were not showing up in Iceberg as changes at some point.
>
>
>
> I’d done some earlier tests with Iceberg, and was able to make
> dummy-method changes, and commit to the local GitHub repo.  Everything
> seemed to work.  At some indeterminate point, the changes I made were no
> longer showing in Iceberg.  Further, when I would save, the image would
> save and quit automatically without actually saving.  I’d relaunch, reapply
> the changes in the change set (Epicea), and re-save with the same results.
> When I tried Save As… instead, I got the above crash.
>
>
>
Looks like it crashed in a full garbage collection, which is something that
is done when you are saving.
Its been a while since I've seen one of those have been reported.  Lately
crashes have been more related to C libraries called by FFI.

Exception code: C005 = "access violation"
Exception addr: 00433CD2
Access violation (read access) at 

VM Version: Cog Spur VM 5.0 (release) from Jan  5 2019
Compiler: gcc 4.2.1 Compatible Clang 5.0.1 (tags/RELEASE_501/final)
Interpreter Build: CoInterpreter VMMaker.oscog-eem.2504 uuid:
a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan  5 2019
Cogit Build: StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid:
a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan  5 2019
Source Version: VM: 201901051900
https://github.com/OpenSmalltalk/opensmalltalk-vm.git
Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6
Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git

Primitive trace:

at:
primitiveGarbageCollect
**FullGC**

Smalltalk stack dump:
  0xb8a948 I SmalltalkImage>garbageCollect 0x5e0aa10: a(n)
SmalltalkImage
  0xb8a990 I Bitmap class(Behavior)>handleFailingBasicNew:
0x64294d0: a(n) Bitmap class
  0xb8a9d0 M Bitmap class(Behavior)>basicNew: 0x64294d0: a(n)
Bitmap class
  0xb8aa08 M Bitmap class(Behavior)>new: 0x64294d0: a(n) Bitmap
class
  0xb8aa68 I Bitmap class>decompressFromByteArray: 0x64294d0: a(n)
Bitmap class
  0xb6f320 M Form>unhibernate 0x9366dc8: a(n) Form


> I’ve managed to crash the VM twice

Not a lot can be done by others until there is a reproducible case.
You might run a debug-vm that would allow more analysis of a crash.

Can you clarify you environment - OS Version, Pharo 32 or 64 bit ?


(I would like the installer to be more graceful about installing to any
> folder on Windows.  Can we make it so?)  Can’t run the .msi installer as
> admin and actually install.  It brings up the command line options instead.
> As far as I can find, there are no Pharo-related files left in the user
> account/Documents area.
>

You could have a go at adapting the installer to provide a concrete example
of what you want.
@all, where are the msi-installer sources?



>
> I would enter this bug at https://pharo.fogbugz.com/, but I’m not sure it
> would get quick attention there.
>
>
>
Bug tracking has moved to https://github.com/pharo-project/pharo/issues

cheers -ben

[Pharo-dev] Default line endings while writing to a file stream

[Ben Coman]

I'm on Windows wanting to write a text file with LF endings.
The code developed on Linux is thus...
(destinationDirectory / 'README.md') ensureCreateFile
writeStreamDo: [ :stream | stream nextPutAll: class comment ]

and I am stuck with CR line endings.
The specific symptom is that it screws `git diff`
Here is a simple experiment...
testfile := 'README.md' asFileReference.
testfile ensureCreateFile writeStreamDo: [ :stream |
stream nextPutAll: 'aa
bb' ].
testfile binaryReadStream contents at: 3  "==>  Character cr "

I think its safe to assume on Linux that will result in "==>  Character lf "
but can someone please confirm?

So my issue is that I've got
#ensureCreateFile - returns a FileReference
and
:stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream
wrapping BinaryFileStream.

and neither seem to have an easily accessible defaultLineEnding setting.
Indeed, line endings are not a property of FileReference
and Binary & Characters have nothing to do with line endings,
and questionable if Buffering is related.

Its more a property of a File, but IIUC that is being deprecated (??)

MultiByteFileStream has #lineEndConvention:
but IIUC that also is being deprecated.

So what is the proper way to force default line endings?


--
Now while composing this email I discovered String>>withUnixLineEndings.
So I have a solution...
testfile := 'README.md' asFileReference.
testfile ensureCreateFile writeStreamDo: [ :stream |
stream nextPutAll: 'aa
bb'  withUnixLineEndings ].
(testfile binaryReadStream contents at: 3) asCharacter   "==> Character
lf "

but that seems to imply that on Windows...
'aa
bb' at: 3  "==> Character cr "

and on Linux (someone please confirm)...
'aa
bb' at: 3   "==> Character lf "

and that is *very* curious.  Strange that I never noticed it before and
obviously that hasn't hurt me,
but considering the Principal Of Least Surprise it leaves me feeling
somewhat violated :)

Re: [Pharo-dev] FW: Versioning with Iceberg

[Ben Coman]

On Fri, 31 May 2019 at 09:09, Shaping  wrote:

> Thanks for the explanation, Ben.   This isn’t good for the future of
> Pharo.
>

Could you expand your thoughts on that?
I don't see why.  Linux didn't fall apart with the introduction of... tar,
rpm, yum, apt, dnf, etc...

What a headache.
>

I don't find it so.  What is the headache for you?
is it confusion about the scope of each? Maybe we need to better
communicate this?


 Has anyone investigated automatic scripted conversion of Monticello
> formats to Iceberg with Git?
>

I believe there has been some work.  If no better answers come, search
http://forum.world.st/


I don’t see how this will ever be done or finished manually, humans being
> what they are.
>

What you a promoting is forcing a monoculture.  Humans being what they are,
don't respond well to that.


The fragmented versioning-technologies will persist then indefinitely.
>

Iceberg/git in only been in broad use for one year since release of Pharo
7.
How fast do you expect the world to change?
The diffusion of innovation applies...
https://en.wikipedia.org/wiki/Diffusion_of_innovations

Some people work in multiple Smalltalk versions that continue to use
Monticello (http://www.squeaksource.com)
and want to maintain a cross-platform package.  So even with the most
perfect conversion script, Monticello will remain an option.

The alternative scenario of having only one versioning system
would have been to stick with Monticello and avoid using git.
I don't consider that viable.

I believe Pharo has a great future with a preferred option going forward
with Git
and an option to access legacy code with Monticello.

cheers -ben


>
>
>
>
> Shaping
>
>
>
> *From:* Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] *On Behalf
> Of *Ben Coman
> *Sent:* Thursday, May 30, 2019 08:45
> *To:* Pharo Development List 
> *Subject:* Re: [Pharo-dev] FW: Versioning with Iceberg
>
>
>
> On Thu, 30 May 2019 at 18:56, Shaping  wrote:
>
>
>
> I prefer to use one tool for versioning.  Is that possible now in any
> version of Pharo?  Can I use only Iceberg for all fetches and all
> commits?   Or must I sometimes use evaluables like:
>
>
>
> Metacello new
>
>  baseline: 'Exercism';
>
>  repository: 'github://exercism/pharo-smalltalk/releases/latest';
>
> onConflict: [ :ex | ex allow ];
>
>  load.
>
>
>
> Metacello operates at a higher level than Iceberg.
>
> Iceberg (like Monticello) versions individual packages.
>
> Metacello defines the version dependencies between packages, including
> different git repos and Monticello repos.
>
> The Metacello definition is versioned like any other code, using either
> Iceberg or Monticello.
>
>
> I'm not completely sure, but I think Metacello uses Iceberg to load from
> github repos,
> so what that last code snippet does is...
> Metacello loads the given baseline from github using Iceberg and parses it,
>
> then loads all the dependent baselines from their respective repos using
> Iceberg or Monticello per the format they are stored in,
>
> then loads all the specified code versions using Iceberg or Monticello as
> appropriate.
>
>
>
> Also once you've loaded an Iceberg repo containing a Metacello baseline,
> you can invoke that baseline from within Iceberg.
>
> [image: image.png]
>
>
>
> Essentially Iceberg replaces Monticello for git repos,
>
> but there is a wealth of historical packages in Monticello format, so its
> not disappearing either.
>
>
>
> HTH,
>
> cheers -ben
>
>
>

Re: [Pharo-dev] Crashing in Windows 10... libssh2-1.dll

[Ben Coman]

Looks like you have the tools to isolate the problem. Would you like to be
coached through building your own debug-vm to help track down whats
happening?

cheers -ben

On Fri, 31 May 2019 at 02:04, casimiro barreto 
wrote:

> Happens in Cog never mind image. During load of Seaside3 (never mind)
> [image: image.png]
>

Re: [Pharo-dev] Versioning with Iceberg

[Ben Coman]

On Wed, 29 May 2019 at 23:08, Shaping  wrote:

> I’m finding 7.0.3 to be more stable.
>
>
>
> How do I load a specific baseline/version with Iceberg?  I’m getting 8.0
> by default from the cloned local repo, and I prefer not to merge 7.0.3 with
> 8.0.  There are many differences.  I want to commit my image changes
> locally for now on a 7.0.3.
>
>
>
Is this what you need... ?
 https://github.com/pharo-vcs/iceberg/issues/1246

cheers -ben

Re: [Pharo-dev] FW: Versioning with Iceberg

[Ben Coman]

On Thu, 30 May 2019 at 18:56, Shaping  wrote:

>
>
> I prefer to use one tool for versioning.  Is that possible now in any
> version of Pharo?  Can I use only Iceberg for all fetches and all
> commits?   Or must I sometimes use evaluables like:
>
>
>
> Metacello new
>
>  baseline: 'Exercism';
>
>  repository: 'github://exercism/pharo-smalltalk/releases/latest';
>
> onConflict: [ :ex | ex allow ];
>
>  load.
>

Metacello operates at a higher level than Iceberg.
Iceberg (like Monticello) versions individual packages.
Metacello defines the version dependencies between packages, including
different git repos and Monticello repos.
The Metacello definition is versioned like any other code, using either
Iceberg or Monticello.

I'm not completely sure, but I think Metacello uses Iceberg to load from
github repos,
so what that last code snippet does is...
Metacello loads the given baseline from github using Iceberg and parses it,
then loads all the dependent baselines from their respective repos using
Iceberg or Monticello per the format they are stored in,
then loads all the specified code versions using Iceberg or Monticello as
appropriate.

Also once you've loaded an Iceberg repo containing a Metacello baseline,
you can invoke that baseline from within Iceberg.
[image: image.png]

Essentially Iceberg replaces Monticello for git repos,
but there is a wealth of historical packages in Monticello format, so its
not disappearing either.

HTH,
cheers -ben

Re: [Pharo-dev] Calypso idea - inherited tests

[Ben Coman]

On Thu, 30 May 2019 at 06:26, Denis Kudriashov  wrote:

> Hi Ben.
>
> There are already two features that support inherited tests:
> - run all tests using class icon: there will be extra red method group
> "broken tests" which will show failed inherited tests.
> - toggle inheritance visibility with checkbox in third panel: you will see
> inherited tests and standard method icon will run them.
>

Ahh, excellent... the second is exactly what I wanted.

Although using TestDelaySemaphoreSchedulerMicrosecondTicker as an example,
clicking on a test gives me an error "#selected was sent to nil" in
"ClyBrowserToolMorph>>isTabSelected"
Do you get the same?

cheers -ben

Re: [Pharo-dev] Versioning with Iceberg

[Ben Coman]

On Wed, 29 May 2019 at 23:08, Shaping  wrote:

> I’m finding 7.0.3 to be more stable.
>
>
>
> How do I load a specific baseline/version with Iceberg?  I’m getting 8.0
> by default from the cloned local repo, and I prefer not to merge 7.0.3 with
> 8.0.  There are many differences.  I want to commit my image changes
> locally for now on a 7.0.3.
>
>
>
Its not completely clear what you want.

You can right-click a repo > Metacello > Install baseline of.

Or right-click a repo > Repository > Remotes
and select one of those branches to check out.

cheers -ben

[Pharo-dev] Calypso idea - inherited tests

[Ben Coman]

(Just a quick share from work before that neuron goes back to sleep and I
forget it...)

When a number of domain substitute classes need to satisfy the same tests,
its useful to define these in a superclass and have subclasses define which
domain class is being tested e.g.
TestDelaySemaphoreSchedulerMmicrosecondTeicker>>classForScheduler.

>From the Browser "all tests" can be run for each subclass by clicking the
class's test-icon,
but when that goes red, its not visible which individual test failed, and
you can't run an individual test from the Browser.

In the same way that extension methods are shown in gray, it would be
useful
for inherited tests to be shown in gray, so each has an individual
indication and can be run separately.

cheers -ben

[Pharo-dev] OSX native title bar with Smalltalk balloon

[Ben Coman]

I don't have OSX but was watching a user launch a 64bit Pharo 7.0.3 image
from PharoLauncher,
and noticed the "Smalltalk balloon" showing in its title bar.

[image: image.png]

I've only the single point of observation, so I'm curious if that is usual?

cheers -ben

[Pharo-dev] tab width on github

[Ben Coman]

Pharo code uses tabs and github renders that as 8 spaces width.
For me thats too large.  Please vote for it to be configurable..
https://gitlab.com/gitlab-org/gitlab-ce/issues/57758
https://gitlab.com/gitlab-org/gitlab-ce/issues/2479

cheers -ben

Re: [Pharo-dev] Metacello/Iceberg detached head of cascade loaded requirements

[Ben Coman]

On Tue, 14 May 2019 at 18:02, Guillermo Polito 
wrote:

> Hi Ben,
>
> I’ll complement a bit Gabriel’s answer. See inline
>
> El 11 may 2019, a las 10:39, Ben Coman  escribió:
>
> I have a query about "Detached HEAD" status after a Metacello/Iceberg
> cascade load of required packages.  Starting with the general questions...
>  Is that a common status for this scenario?
>
>
> Yes.
>
> A git repository can be mainly in two states (I’m not being really
> accurate here, just simplifying the explanation).
>  - you’re working on a branch, and thus commit, merge and other operations
> will affect the current branch
>  - you’re working on a commit, outside of a branch. In this case some
> operations do not work, others will work but with different semantics. The
> thing that is clear is that operations do not affect any branch.
>
> To understand it a bit better: there is a git variable called HEAD which
> points to the current commitish we are working on.
> A git repository is said to be in `Detached HEAD` when HEAD does point to
> a commitish other than a branch.
>
> To put in in bare command-line git, in general you’ll see that HEAD points
> to a branch, mostly when we clone a fresh repository, or when we `checkout`
> a branch:
>
> ```
> $ git checkout myBranch
> ```
>
> However, when checking out a tag or a commit, HEAD points respectively to
> the commit referenced by the tag (recursively…) or to the checked out
> commit.
>
> ```
> $ git checkout tagV1.0
>
> or
>
> $ git checkout abcd123
> ```
>
> This happens in your scenario because the project you’re loading has some
> dependency that has a version corresponding to a tag.
> Detached HEAD does not mean your repository is broken, it means that to
> work properly you need to check out a branch.
>
>
> Now, let’s imagine we decide to do a tool that automatically leaves you in
> the “correct branch” to avoid Detached HEAD state, the reality is that it
> is no straight forward.
>
> Case 1) Take the simple case where the tagged commit is referenced
> directly by two branches.
> There is no good automatic way to decide which branch is the good one
> without knowing the intentions of the user, or the conventions of the
> project…
> Even creating an automatic branch may not be what the user wanted...
>
> Case 2) Still simple but even more complicated: the two branches have
> diverged from the tagged commit.
> The tagged commit is in the history of both branches, and there is no good
> automatic way to determine which branch is the good.
> They are actually both equally good.
> And even more dangerous, if we silently checkout one of the branches, we
> may be checking out a version that does not work!
>
>  How to leave the status looking good as "Up to date”?
>
>
> Well, usually you have nothing to do. First thing to understand is that in
> git there is not such thing as "Up to date”.
> The best you can do is to say that
>
> [a branch] is up to date [with respect to a remote repository]
>
> Which means that a particular branch has everything from that specific
> remote repository.
> But
>  * maybe there is another repository that has more commits (typical case
> of forks in github for example)
>  * while there could be in your repository a branch that is up to date,
> other branches may not.
>
> Now, I understand that you want to “update your project” to the latest
> version.
> Looking at the graph in Case 2 above, what you need to do is to checkout
> the correct branch.
> The selection of the correct branch would depend on the decisions of the
> developer, or the conventions of the community.
> Right now we have no such conventions, and even if we had them, we should
> give some alternative for those who don’t want to strictly follow them.
>
>
>
> Here is a case example...
> To avoid the a Filetree repo "filename too long" error on Windows,
> I pre-cloned the repo to specify s shorter path name...
>   Repositories > Add > Clone from github.com
>   Owner: dionisiydk
>   Project name: Mocketry
>   Local directory: C:\Temp\Mocketry
>   Protocol: SSH
>
> Then in Playground evaluated...
>  Metacello new
> baseline: 'Mocketry';
> repository: 'github://dionisiydk/Mocketry';
> load
>
> This cascade loaded Ghost and StateSpecs repos leaving them
> with a status of "Detached HEAD".
> What does this mean?
> And how to have these load cleanly so they are left "Up to date” ?
>
>
> Hope I answered those questions :).
> If not, keep asking!
>
> Cheers,
> Guille
>

got it. Thx Guille.  I knew what Detached head

Re: [Pharo-dev] DNU Create button auto extension category

[Ben Coman]

On Sun, 12 May 2019 at 15:41, Tim Mackinnon  wrote:

> My point was that in general - method categorisation has degraded (not
> just your debugger case, but in a broader sense).
>
> Nautilus used to infer method protocols , and if not inferred, you used to
> see protocols already in your package... now you basically have to type out
> protocols and search for them every time.
>
> I don’t think you can even bulk categorise methods either.
>
> I keep meaning to have a look, as it’s all quite annoying and doesn’t
> really encourage you to categorise anything as it’s too much like hard work.
>

With Calypso I've had some success using  Protocols Pane > Categorize all
uncategorized.
but as an after-the-fact clean up maybe not what your looking for.

cheers -ben


>
> Tim
>
> Sent from my iPhone
>
> On 12 May 2019, at 07:30, Ben Coman  wrote:
>
> >>> On 11 May 2019, at 18:07, Ben Coman  wrote:
> >>>
> >>> Currently when a DNU occurs we get this cool  button,
> >>> but when this presents the dialog "New Protocol Name" I get a blank
> >>> list and the default is "as yet unclassified" and I end up with a heap
> >>> of such unclassified methods to sort later.
> >>>
> >>> I am wondering if it could be smarter when tests are being run.  A
> >>> reasonable assumption could be that the test's package name is closely
> >>> related to the likely extension package name.
> >>> So for a DNU, I wonder if the debugger could walk the stack to
> >>> discover if a TestCase subclass was on the stack (e.g. MyTestCase) and
> >>> then determine which package MyTestCase belonged to, and present that
> >>> as a choice for "New Protocol Name", helping categorize extension
> >>> methods.
> >>>
> >>> I've started to play like this...
> >>>
> >>> TestCase subclass: #MyTestRoot
> >>>
> >>> MyTestRoot >> runCase
> >>>   [ super runCase ]
> >>>   on: MessageNotUnderstood
> >>>   do: [ :ex |
> >>> "do something here, but for now..."
> >>>  ex pass
> >>>  ].
> >>>
> >>> but before getting to deep, I'm seeking suggestions/solutions from the
> >>> community.
> >
> >> On Sun, 12 May 2019 at 05:06, Tim Mackinnon  wrote:
> >>
> >> It’s a good point Ben - in fact categorisation in general has not been
> finished in pharo7 -
> >> the move to Calypso lost smart method categories and its on the todo
> list to fix and improve it.
> >
> > I don't think this is related to Calypso, more to do with the debugger.
> > I got what I wanted with the following change...
> > ```
> > DoesNotUnderstandDebugAction>>defaultProtocol   "new method"
> >"Facilitate  DNU with TDD creating extension methods by
> > suggesting that as default protocol"
> >| interruptedContext candidateContext |
> >"self halt"
> >interruptedContext := self interruptedContext.
> >candidateContext := interruptedContext sender.
> >[ candidateContext isNil or: [ candidateContext contextClass
> > isKindOf: TestCase class ] ]
> >whileFalse: [ candidateContext := candidateContext sender
> ].
> >candidateContext ifNotNil: [
> >| testPackage dnuPackage|
> >dnuPackage := interruptedContext receiver class package.
> >testPackage := candidateContext contextClass package.
> >(testPackage = dnuPackage) ifFalse: [ ^ '*', testPackage
> name ].
> >].
> >^'as yet unclassified'
> >
> > DoesNotUnderstandDebugAction>>executeAction  "diff modified method"
> >| msg msgCategory chosenClass exception |
> >msg := self interruptedContext tempAt: 1.
> >exception := self interruptedContext tempAt: 2.
> >(exception class == ClassNotUnderstood) ifTrue: [
> >self createMissingClassWith: exception variableNode
> > in: self interruptedContext ].
> >chosenClass := self
> >askForSuperclassOf: self interruptedContext receiver class
> >toImplement: msg selector
> >ifCancel: [^self].
> > -msgCategory := (self askForCategoryIn: chosenClass default:
> > 'as yet unclassified' ).
> > +msgCat

Re: [Pharo-dev] DNU Create button auto extension category

[Ben Coman]

> > On 11 May 2019, at 18:07, Ben Coman  wrote:
> >
> > Currently when a DNU occurs we get this cool  button,
> > but when this presents the dialog "New Protocol Name" I get a blank
> > list and the default is "as yet unclassified" and I end up with a heap
> > of such unclassified methods to sort later.
> >
> > I am wondering if it could be smarter when tests are being run.  A
> > reasonable assumption could be that the test's package name is closely
> > related to the likely extension package name.
> > So for a DNU, I wonder if the debugger could walk the stack to
> > discover if a TestCase subclass was on the stack (e.g. MyTestCase) and
> > then determine which package MyTestCase belonged to, and present that
> > as a choice for "New Protocol Name", helping categorize extension
> > methods.
> >
> > I've started to play like this...
> >
> > TestCase subclass: #MyTestRoot
> >
> > MyTestRoot >> runCase
> >[ super runCase ]
> >on: MessageNotUnderstood
> >do: [ :ex |
> >  "do something here, but for now..."
> >   ex pass
> >   ].
> >
> > but before getting to deep, I'm seeking suggestions/solutions from the
> > community.

On Sun, 12 May 2019 at 05:06, Tim Mackinnon  wrote:
>
> It’s a good point Ben - in fact categorisation in general has not been 
> finished in pharo7 -
> the move to Calypso lost smart method categories and its on the todo list to 
> fix and improve it.

I don't think this is related to Calypso, more to do with the debugger.
I got what I wanted with the following change...
```
DoesNotUnderstandDebugAction>>defaultProtocol   "new method"
"Facilitate  DNU with TDD creating extension methods by
suggesting that as default protocol"
| interruptedContext candidateContext |
"self halt"
interruptedContext := self interruptedContext.
candidateContext := interruptedContext sender.
[ candidateContext isNil or: [ candidateContext contextClass
isKindOf: TestCase class ] ]
whileFalse: [ candidateContext := candidateContext sender ].
candidateContext ifNotNil: [
| testPackage dnuPackage|
dnuPackage := interruptedContext receiver class package.
testPackage := candidateContext contextClass package.
(testPackage = dnuPackage) ifFalse: [ ^ '*', testPackage name ].
].
^'as yet unclassified'

DoesNotUnderstandDebugAction>>executeAction  "diff modified method"
| msg msgCategory chosenClass exception |
msg := self interruptedContext tempAt: 1.
exception := self interruptedContext tempAt: 2.
(exception class == ClassNotUnderstood) ifTrue: [
self createMissingClassWith: exception variableNode
in: self interruptedContext ].
chosenClass := self
askForSuperclassOf: self interruptedContext receiver class
toImplement: msg selector
ifCancel: [^self].
-msgCategory := (self askForCategoryIn: chosenClass default:
'as yet unclassified' ).
+msgCategory := (self askForCategoryIn: chosenClass default:
self defaultProtocol).
  self  session
implement: msg
classified: msgCategory
inClass: chosenClass
forContext: self interruptedContext.
self debugger selectTopContext
```

Tim, Can you trial this with your Exercism Die exercise?

Alternatively an isolated test...
```
Object subclass: MyApp ... package: 'MyPackage'

TestCase subclass: MyTestCase ... package: 'MyPackage'

MyTestCase >> testAutoExtensionProtocol
MyApp new unknown
```

Run the test then click  button to add following method with
default protocol... as yet unclassified
```
MyApp >> unknown
  42 unknown
```

Click  button to add method with default protocol...  *MyPackage

cheers -ben

P.S. Next question is how to create a unit test for such behaviour ??

[Pharo-dev] consortium engineers

[Ben Coman]

I hadn't heard before... four consortium engineers for a year, very cool...
slides 3 & 4... https://www.slideshare.net/pharoproject/pharo-70-and-80-alpha
thanks Schmidt & LIfeware, and all consortium partners.
cheers -ben

[Pharo-dev] DNU Create button auto extension category

[Ben Coman]

Currently when a DNU occurs we get this cool  button,
but when this presents the dialog "New Protocol Name" I get a blank
list and the default is "as yet unclassified" and I end up with a heap
of such unclassified methods to sort later.

I am wondering if it could be smarter when tests are being run.  A
reasonable assumption could be that the test's package name is closely
related to the likely extension package name.
So for a DNU, I wonder if the debugger could walk the stack to
discover if a TestCase subclass was on the stack (e.g. MyTestCase) and
then determine which package MyTestCase belonged to, and present that
as a choice for "New Protocol Name", helping categorize extension
methods.

I've started to play like this...

TestCase subclass: #MyTestRoot

MyTestRoot >> runCase
[ super runCase ]
on: MessageNotUnderstood
do: [ :ex |
  "do something here, but for now..."
   ex pass
   ].

but before getting to deep, I'm seeking suggestions/solutions from the
community.

cheers -ben

[Pharo-dev] Metacello/Iceberg detached head of cascade loaded requirements

[Ben Coman]

I have a query about "Detached HEAD" status after a Metacello/Iceberg
cascade load of required packages.  Starting with the general questions...
  Is that a common status for this scenario?
  How to leave the status looking good as "Up to date"?

Here is a case example...
To avoid the a Filetree repo "filename too long" error on Windows,
I pre-cloned the repo to specify s shorter path name...
   Repositories > Add > Clone from github.com
   Owner: dionisiydk
   Project name: Mocketry
   Local directory: C:\Temp\Mocketry
   Protocol: SSH

Then in Playground evaluated...
  Metacello new
 baseline: 'Mocketry';
 repository: 'github://dionisiydk/Mocketry';
 load

This cascade loaded Ghost and StateSpecs repos leaving them
with a status of "Detached HEAD".
What does this mean?
And how to have these load cleanly so they are left "Up to date" ?

To ease others testing on Windows, I forked the repo and converted to Tonel,
so the same result comes by just evaluating
Metacello new
  baseline: 'Mocketry';
  repository: 'github://bencoman/Mocketry';
  load

cheers -ben

P.S. I've issued a PR upstream for the Tonel conversion.

Re: [Pharo-dev] Explaining Spec2 and why Bloc is on the roadmap

[Ben Coman]

Thanks for the background info Steph.

On Thu, 2 May 2019 at 17:28, ducasse  wrote:
> Spec 2.0 revisits fundamentally Spec.
> - adds much better layouts (we will deprecate the interpreter design)

A very long time ago that I was debugging a Spec app was that
debugging INTO the framework from application code
would take 30 odd steps before it got to evaluate the block passed by
the application code.
Sorry thats a bit vague, but I'm hoping deprecating the interpreter
will improve such experience.

As a general comment also, architectures using stored blocks for
configuration rather than
passing in an "object with defined methods" seems a lot "less live".
Changing the code inside the block doesn't change the behaviour of
existing elements.

But maybe the "methods" way has its own issues.

cheers -ben

Re: [Pharo-dev] how implement isAbstract?

[Ben Coman]

On Mon, 29 Apr 2019 at 22:38, Guillermo Polito 
wrote:

> A class is abstract by design and not necessarily because I can compute
> something from its implementation that tells me that maybe it is abstract.
> I somehow mark a class as abstract because it is abstract, not the other
> way around.
>

Randon idea...
``#Frame abstract`` returning a hypothetical instance of AbstractClassSymbol
which double-dispatches to set a property of the class when it is created
per...
 Object subclass: #Frame abstract
instanceVariableNames: 'frameNumber frameRolls nextFrame'
classVariableNames: ''
package: 'Exercism-Bowling'

cheers -ben

[Pharo-dev] image state saving TDD

[Ben Coman]

Just a thought on a dream feature...

When doing TDD, it would be super cool if in a test method,
the state of the image was saved just before an #assert:
so if the assert fails the state is restored to just before the assert
was called,
so I don't have to  and multi-step  through the whole method
to get back to the message I want to step into.

cheers -ben

Re: [Pharo-dev] How to convey that a message create a new instance

[Ben Coman]

> On Sat, Apr 27, 2019, 14:27 ducasse  wrote:
>>
>> Hi
>>
>> I was looking at the API of Color and it is really confusing to me and wrong
>> For example beOpaque
>>
>> beOpaque
>> "Set the transparency of the receiver to opaque, i.e. alpha to 1.0."
>>
>> ^ self alpha: 1.0
>>
>> But
>>
>> alpha: aFloat
>> "Answer a new Color with the given amount of opacity ('alpha')."
>>
>> ^ self class r: self red g: self green b: self blue alpha: aFloat
>>
>> Or
>>
>> adjustBrightness: brightness
>> "Adjust the relative brightness of this color. (lowest value is 
>> 0.005 so that hue information is not lost)”
>>
>> but this creates a new color.
>>
>> I would really like to see how we can improve the fact that reading the 
>> method selector should
>> let us understand whether a message is modifying or not the receiver.
>>
>> Since many methods such as darker, duller,…. do not show that they return a 
>> new instance but actually do it.
>> May be we can make sure that modifying receiver methods are much better 
>> identified as doing so.
>>
>> beOpaque -> asOpaque
>> adjustBrightness: -> colorWithBrigthness:
>>
>> Do you have any better ideas?
>>
>> Stef
>>


On Sun, 28 Apr 2019 at 07:06, Gabriel Cotelli  wrote:
>
> I tend to use the following idioms:
> - 'beSomething' idiom for cases modifying the receiver.
> - 'asSomething' can or cannot return a new object

This indicates some type of conversion which naturally must be a
different object,
so for consistency it would be nice to be able to consider this always
returns a new object,
except that...
s := 'abcd'.
s == s asString.
==> true
Maybe it *should* return a copy, but thats fairly pervasive in the
system and maybe subtly relied on.

cheers -ben

[Pharo-dev] ReadWriteStream>>on:

[Ben Coman]

I notice...
rs := ReadStream on: #( 1 2 3 4 5 6 7 8 9).
rs do: [ :x | self inform: x printString ].
==> shows 10 notifications.

but...
rws := ReadWriteStream on: #( 1 2 3 4 5 6 7 8 9).
rws do: [ :x | self inform: x printString ]
==> nothing

it seems because "readLimit" instance variable of ReadWriteStream is zero.

Comparing...
ReadStream(PositionalStream)>>on: aCollection
readLimit := aCollection size.

ReadWriteStream(WriteStream)>>on: aCollection
readLimit := 0.

I wonder if ReadWriteStream should override #on:  to set readLimit
similar to ReadStream, but are there subtleties in the stream
hierarchy I'm not aware of ?

cheers -ben

Re: [Pharo-dev] Performance Issues

[Ben Coman]

Thanks for this great initiative Pablo.
cheers -ben

On Tue, 2 Apr 2019 at 22:23, teso...@gmail.com  wrote:

> Hi, this will be a long mail. I have organized it in different sections.
>
> Resume:
> ==
>
> - There are performance issues in Pharo 7.
> - I have made benchmarks.
> - With Guille we made an improvement in saving source code in methods.
> - More improvements to come.
> - Automation and CI in the future.
>
>

Re: [Pharo-dev] Green tests

[Ben Coman]

On Tue, 2 Apr 2019 at 23:36, ducasse  wrote:

> I’m inherently race condition incompatible and just avoid concurrent
> programming because I’m too dull on this.
>

I've solved a few Pharo race conditions before, so just a tip (that you
maybe already know).
You can't troubleshoot a race condition by standard debugging, because it
alters the timing.
Best that I've done before is resorting to plain old print-line tracing
between every line of the suspect code,
or the equivalent threadsafe collection if its not a hard crash.
e.g
someMethod
threadsafeCollection add: "methodname-A" , testCondition
original method line 1
threadsafeCollection add: "methodname-B", testCondition
original method line 2
threadsafeCollection add: "methodname-C", testCondition

and then looking for cyclic patterns in that data and breaks in those
patterns.

I can have a look in a few weeks.  Right now working 13 hour days to the
end of the week
and then vacationing in China for 10 days.

[Pharo-dev] Future 32-bit support

[Ben Coman]

Regarding "PharoLaunched Windows 32bits Pharo 8 image raises primitive
failed error"
because there seems to be no Pharo 8 32-bit Windows VM configured for
PharoLauncher

https://github.com/pharo-project/pharo/issues/3053

and considering...
* Mojave is Apple's last version of macOS to support 32-bit apps
https://appleinsider.com/articles/18/06/05/mojave-is-apples-last-version-of-macos-to-support-32-bit-apps


what is benefit of supporting 32-bit on those platforms?

Perhaps 32-bit VMs are just useful for smaller Linux IoT platforms?

cheers -ben

Re: [Pharo-dev] [Issue Tracker] installed some robots

[Ben Coman]

Thanks. This is useful.

On Thu, 21 Mar 2019 at 17:34, Marcus Denker  wrote:

>
> Request Info: Requests more info on issues and pull requests with the
> default title or an empty body.
> it sets the more-information-needed flag.
> https://probot.github.io/apps/request-info/
>

Can more info be added to the generic message...
> We would appreciate it if you could provide us with more info about this
issue/pr!

"This issue has either a default title or empty body.  We would appreciate
it if you could provide more info about this issue/pr!"


Stale: Close stale Issues and Pull Requests
>
> https://github.com/probot/stale
> Issues: daysUntilStale: 240, daysUntilClose: 60
> Pulls:  daysUntilStale: 20,  daysUntilClose: 10
>

Same general thing about Stalebot comments, I opened...
https://github.com/pharo-project/pharo/issues/2971

cheers -ben

Re: [Pharo-dev] Issue Tracker: enabled Projects (Boards)

[Ben Coman]

Poking around the web bumped into a recommendation for this...
https://www.zenhub.com/blog/open-source/

cheers -ben

On Mon, 18 Mar 2019 at 20:08, Ben Coman  wrote:

> How are issue priorities being assigned? Perhaps there could be a High
> Priority board?
> cheers -ben
>
> On Mon, 18 Mar 2019 at 15:28, Marcus Denker 
> wrote:
>
>> Hi,
>>
>> We enabled the GitHub “Projects” feature for the pharo repo:
>>
>> https://github.com/pharo-project/pharo/projects
>>
>>
>> The idea is that one can add as many “Kanban” style boards as one wants.
>> issues and pull requests can be added, as well as simple cards that are
>> not yet issues.
>>
>> This is quite nice as an issue tracker gets very confusing and
>> overwhelming as soon as there
>> are >500 issues.
>>
>> With these boards, we can create “views” on this sea of issues.
>>
>> I created for now:
>>
>> -> some board related to specific parts of the system (e.g.
>> Traits or Reflectivity)
>> example:
>> https://github.com/pharo-project/pharo/projects/11
>> -> "Pharo7 Backporting”
>>
>> https://github.com/pharo-project/pharo/projects/12
>> -> "Simple Issues for Beginners”
>>
>> https://github.com/pharo-project/pharo/projects/14
>>  Here the feature to be able to put things that are not yet
>> issue tracker entries seems very useful
>>
>>
>> I think this can be quite nice… we should add more Projects as soon as we
>> find that they make sense
>> and should move issues there.
>>
>> Marcus
>>
>

Re: [Pharo-dev] Issue Tracker: enabled Projects (Boards)

[Ben Coman]

How are issue priorities being assigned? Perhaps there could be a High
Priority board?
cheers -ben

On Mon, 18 Mar 2019 at 15:28, Marcus Denker  wrote:

> Hi,
>
> We enabled the GitHub “Projects” feature for the pharo repo:
>
> https://github.com/pharo-project/pharo/projects
>
>
> The idea is that one can add as many “Kanban” style boards as one wants.
> issues and pull requests can be added, as well as simple cards that are
> not yet issues.
>
> This is quite nice as an issue tracker gets very confusing and
> overwhelming as soon as there
> are >500 issues.
>
> With these boards, we can create “views” on this sea of issues.
>
> I created for now:
>
> -> some board related to specific parts of the system (e.g. Traits
> or Reflectivity)
> example:
> https://github.com/pharo-project/pharo/projects/11
> -> "Pharo7 Backporting”
> https://github.com/pharo-project/pharo/projects/12
> -> "Simple Issues for Beginners”
>
> https://github.com/pharo-project/pharo/projects/14
>  Here the feature to be able to put things that are not yet
> issue tracker entries seems very useful
>
>
> I think this can be quite nice… we should add more Projects as soon as we
> find that they make sense
> and should move issues there.
>
> Marcus
>

Re: [Pharo-dev] OSProcess for Pharo 7

[Ben Coman]

On Mon, 18 Mar 2019 at 10:20, David T. Lewis  wrote:

> Hi Mariano,
>
> On Sun, Mar 17, 2019 at 08:29:59PM -0300, Mariano Martinez Peck wrote:
> > >
> > > ducasse wrote
> > > > this is not because we do not care of Pharo that we will fix it
> > > > immediately.
> > >
> > > Yes of course, just want to keep it on the radar (and maybe Mariano
> will
> > > read he he)
> > >
> > >
> > I always do :)
>
> Me too :-)
>
>
> > But honestly, I don't have enough time to carry on that myself. As you
> > could see with latest Guillermo pass, I reviewed every PR and tried to
> give
> > my advice and support as much as possible.
>
> I saw Sean's earlier email (see below) which reminded me of your ideas
> about
> having a child process listener that could provide child exit notifications
> to both OSSubprocess and OSProcess.


What about this being even more generic, so child native process/threads
can be viewed from the Image similar to Process Browser?
I'm not entirely sure of the use case, just wild speculation something like
that might be useful when Threaded-FFI arrives.

cheers -ben

Re: [Pharo-dev] Esteban's ChangeLog week of 4 March 2019

[Ben Coman]

On Mon, 11 Mar 2019 at 15:00,  wrote:

> Hello!
>
> This is my weekly ChangeLog, from 4 March 2019 to 10 March 2019.
> You can see it in a better format by going here:
> http://log.smallworks.eu/web/search?from=4/3/2019&to=10/3/2019
>
> ChangeLog
> =
>
> 6 March 2019:
> -
>
> *I spent last two days trying approaches to make the introduction of
> +Application+ concept less intrusive.
>
> Thing is, since several applications can be alive at the same time (in
> general at least two: Pharo and the
> application the user is developing, but there can be more), when you
> create a window, is mandatory to know
> the application it belongs to.
>
> And this is a problem.
>
> Why? Well, because there are two ways to do it:
>
> It can be:
>
> 
> MyWindowClass newApplication: myApplication.
> 
>
> or:
>
> 
> myApplication new: MyWindowClass.
> 
>
> And well... both approaches require that you are in possesion of an
> application when you create a window.
>

Really random thought...  If somehow a window is created without it knowing
the application,
could it create a new application for it - it occurs to me it might be
called an "anonymous application"
but I've no idea if that makes sense within the framework, and too many
random applications might be unmanageable.

cheers -ben

P.S. Thanks for these ChangeLogs.  Great to see whats in the pipeline.

Re: [Pharo-dev] managing modification of class initialization methods

[Ben Coman]

On Tue, 5 Mar 2019 at 22:08, Sven Van Caekenberghe  wrote:

>
> Now, your solution, the pragma, is just as complex, because it would still
> require people to (1) understand the issue and (2) remember to add the
> pragma correctly.
>

I agree those points apply in relation to creating code,
but for an existing method with such a pragma I believe it would be
reasonably easy for newcomers to read and understand the impact of
modifying the data,
but I've really nothing to back up that belief.

cheers -ben

Re: [Pharo-dev] managing modification of class initialization methods

[Ben Coman]

On Mon, 4 Mar 2019 at 20:08, Norbert Hartl  wrote:

>
>
> > Am 04.03.2019 um 03:46 schrieb Ben Coman :
> >
> > In relation to developing sample solutions for an Exercism exercise, the
> following observation was made about class initialization...
> >
> > > class is initialized on load - and not when you modify it - so this
> can be very confusing for users
> >
> > My first thought was to wonder if Quality Assistant could track whether
> a class initialize method had been run after it was modified,
> > and display alerts.
> >
> > Alternatively, I wonder if a reasonable pattern would be to couple
> class-side lazy initialization
> > with a pragma to reset a variable when the method is saved...
> >
> > MyClass class >> referenceData
> > 
> > ^ ReferenceData := ReferenceData ifNil: [ 'reference data' ]
> >
>
> Isn’t the usual way to do that to register the class in the shutdown list
> and implement #shutdown: ?
>

To me a good minute to work out why I didn't understand you.
Sorry, I meant 

So when 'reference data' is updated and the modified method is saved,
the variable gets lazy initialized *again* with the new definition.

hope that is more clear,
cheers -ben

Re: [Pharo-dev] managing modification of class initialization methods

[Ben Coman]

Le lun. 4 mars 2019 à 03:47, Ben Coman  a écrit :

> In relation to developing sample solutions for an Exercism exercise, the
> following observation was made about class initialization...
>
> > class is initialized on load - and not when you modify it - so this can
> be very confusing for users
>
> My first thought was to wonder if Quality Assistant could track whether a
> class initialize method had been run after it was modified,
> and display alerts.
>
> Alternatively, I wonder if a reasonable pattern would be to
> couple class-side lazy initialization
> with a pragma to reset a variable when the method is saved...
>
> MyClass class >> referenceData
> 
> ^ ReferenceData := ReferenceData ifNil: [ 'reference data' ]
>
>
On Mon, 4 Mar 2019 at 14:52, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

> Hi Ben,
> It's probably time to revisit
>
> http://smallissimo.blogspot.com/2011/08/lazy-initialization-of-shared-variable.html?m=1
>

Interesting stuff, but after ten minutes studying it I didn't fully grok it.
So my first impression is its too much magic and I couldn't isolate what is
required of a simple user.
For comparison, could you show what a user would need to do to duplicate my
example using that system, assuming the background magic was in place.

cheers -ben

[Pharo-dev] managing modification of class initialization methods

[Ben Coman]

In relation to developing sample solutions for an Exercism exercise, the
following observation was made about class initialization...

> class is initialized on load - and not when you modify it - so this can
be very confusing for users

My first thought was to wonder if Quality Assistant could track whether a
class initialize method had been run after it was modified,
and display alerts.

Alternatively, I wonder if a reasonable pattern would be to
couple class-side lazy initialization
with a pragma to reset a variable when the method is saved...

MyClass class >> referenceData

^ ReferenceData := ReferenceData ifNil: [ 'reference data' ]

cheers -ben

Re: [Pharo-dev] looking for an author of a Beginning Pharo or related

[Ben Coman]

Cool.
Thx Stef

On Sat, 2 Mar 2019 at 15:27, Stéphane Ducasse 
wrote:

> Ok I will contact the editor telling that there are some wishes from the
> community to do something.
> After we can brainstorm on what should be purpose and outline.
>
> Stef
>
> On 1 Mar 2019, at 18:21, Ben Coman  wrote:
>
> Obviously its good to be circumspect at such an earlier stage,
> but I can imagine a few "good" editors who publishing a book would really
> lend some legitimacy and exposure to Pharo.
> That would be overall beneficial even if the book is not free.
>
> Stef, I am interested to know more.
>
> cheers -ben
>
> On Fri, 1 Mar 2019 at 17:01, Thomas Dupriez 
> wrote:
>
>> Hello,
>>
>> The timing of this mail is interesting, because just yesterday I stumbled
>> on the "Free Software Needs Free Documentation" preface of the GDB
>> documentation.
>>
>> It's a dozen paragraph so not exactly a short read, but the gist of it is
>> that the author urges other authors to use free documentation licenses for
>> the documentations/manuals they are writing, so that they can be modified
>> and grown by the community along with the free software they talk about.
>>
>> I've attached the full version if some people are interested in reading
>> it.
>>
>> Sorry for this tangent, Stéphane. The timing was just too perfect. :)
>>
>> Thomas
>> On 01/03/2019 08:09, Stéphane Ducasse wrote:
>>
>> Hi guys
>>
>> We have been contacted by a (good) editor that would like to publish on
>> Beginning Pharo or related.
>> I have a lot of material that I can give but no energy to write such book
>> :)
>>
>> If one of you in interested, let me know. I could even be a co-author.
>>
>> Stef
>>
>>
>> 
>> Stéphane Ducasse
>> http://stephane.ducasse.free.fr
>> http://www.synectique.eu / http://www.pharo.org
>> 03 59 35 87 52
>> Assistant: Julie Jonas
>> FAX 03 59 57 78 50
>> TEL 03 59 35 86 16
>> S. Ducasse - Inria
>> 40, avenue Halley,
>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>> Villeneuve d'Ascq 59650
>> France
>>
>>
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
>

Re: [Pharo-dev] looking for an author of a Beginning Pharo or related

[Ben Coman]

Obviously its good to be circumspect at such an earlier stage,
but I can imagine a few "good" editors who publishing a book would really
lend some legitimacy and exposure to Pharo.
That would be overall beneficial even if the book is not free.

Stef, I am interested to know more.

cheers -ben

On Fri, 1 Mar 2019 at 17:01, Thomas Dupriez 
wrote:

> Hello,
>
> The timing of this mail is interesting, because just yesterday I stumbled
> on the "Free Software Needs Free Documentation" preface of the GDB
> documentation.
>
> It's a dozen paragraph so not exactly a short read, but the gist of it is
> that the author urges other authors to use free documentation licenses for
> the documentations/manuals they are writing, so that they can be modified
> and grown by the community along with the free software they talk about.
>
> I've attached the full version if some people are interested in reading it.
>
> Sorry for this tangent, Stéphane. The timing was just too perfect. :)
>
> Thomas
> On 01/03/2019 08:09, Stéphane Ducasse wrote:
>
> Hi guys
>
> We have been contacted by a (good) editor that would like to publish on
> Beginning Pharo or related.
> I have a lot of material that I can give but no energy to write such book
> :)
>
> If one of you in interested, let me know. I could even be a co-author.
>
> Stef
>
>
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
>

Re: [Pharo-dev] Running Pharo under Ubuntu (Windows Subsystem for Linux)

[Ben Coman]

Super Cool !!!
cheers -ben

On Thu, 28 Feb 2019 at 16:53, Christopher Fuhrman <
christopher.fuhr...@inria.fr> wrote:

> Thanks to Cyril who told me it was possible, I got Pharo 7 Unix running
> under the Ubuntu 18 that's part of Windows Subsystem for Linux (WSL) in
> Windows 10. It's not a VM VirtualBox.
>
> I documented the install steps on my new blog that uses Jekyll and github
> pages, which actually took longer to set up than the Pharo under WSL :)
>
> The Mesa install step on the blog might be useful for documenting how to
> get Pharo 7 to work in Ubuntu 18?
>
> https://fuhrmanator.github.io/Pharo-in-WSL/
>

Re: [Pharo-dev] Question on KmGlobalDispatcher

[Ben Coman]

Hi David,

I invite you to consider this an opportunity to submit a PR to fix it.
I'm happy to walk you though the process if you ping me on Discord chat.
I remember it felt cool to have my first code integrated.
Pharo is yours.

cheers -ben

On Wed, 20 Feb 2019 at 02:16, ducasse  wrote:

> Hello David
>
> Indeed this is a good catch.
> Can you open a bug entry on github?
> Else I will do it but this is cool to get involved that way
>
> On 19 Feb 2019, at 17:37, David Richards 
> wrote:
>
> Why does the class name KmGlobalDispatcher have a small 'm'?
>
> Should it be more consistently named KMGlobalDispatcher, as all other
> classes in package: 'Keymapping-Core'?
>
> Object subclass: #KmGlobalDispatcher
> instanceVariableNames: 'dispatcher'
> classVariableNames: ''
> package: 'Keymapping-Core'
>
> Just curious why this name seems inconsistent. I don't recall seeing an
> inconsistency with class name prefixes in any other package group. Is this
> just a mistake, or rather an opportunity to learn something interesting
> about how classes should be named in Pharo? As a beginner, I'm not sure
> which.
>
> Thanks
> David
>
>
>

Re: [Pharo-dev] The HiDPI Issue

[Ben Coman]

On Sat, 16 Feb 2019 at 00:53, Eric Gade  wrote:

> Hello,
>
> I know that others have posted about this before but I wanted to get the
> current status.
>
> I've recently had to buy a new laptop that came with a HiDPI display.
> Generally (especially on Linux systems) this makes Pharo unusable. Though
> there are font size increase and scaling options in the Pharo system
> settings, these do not work as a solution -- buttons are still tiny, there
> is inconsistent scaling behavior across morphic, etc. The overall problem
> can be described as: in Pharo, one pixel equals one "point," and so the
> interface is incredibly small on these HiDPI screens (3k etc).
>
> These HiDPI screens are becoming more common, both as laptop and as
> external displays. Their main advantage is that they can render text very
> crisply. In the HN post announcing the release of P7, there were one or two
> complaints about this issue. It does make it hard to demonstrate to others
> (as I do often) the power of developing in Pharo.
>
> Here are some questions I have about this issue:
> 1) What is the current state of affairs in dealing with this issue, if any?
>

This is what I understand from observing mail list discussions...
For a long time Pharo has been wanting to move windowing out of the VM and
into the Image and utilise FFI for the library calls.
The Pharo 8 roadmap (
http://forum.world.st/Roadmap-for-Pharo-8-0-td5094949.html) includes using
a true headless VM
with zero windowing code as the standard Pharo VM and have windowing done
from the Image.  This should open up
the possibility of you contributing by coding and debugging at the Image
level.  So stay tuned.



> 2) Would this require VM changes (I assume it would)? If so, what might
> those entail?
>

Yes. And, I don't know.
Anyway, this question may end up mute if native-windowing is more exposed
to Image-side as described above.


3) If this does require VM changes, I assume the Squeak people would want
> in on it?
>

I'm sure they would broadly want the functionality. However Squeak is
concerned more about backward compatibility than Pharo.
They may be more conservative about following the same path as Pharo.
Perhaps once Pharo has broken the ground and proved the concept Squeak
could look at how to adopt it in a compatible way.
For example, I wonder if its possible to isolate Squeak's VM side window
initialization to a single function call
that is invoked or not depending on a flag in the Image - which Pharo
Images can have set moving forward,
and remains unset for Squeak Images.


4) Is the current plan to wait for Bloc to resolve these issues and/or
> would switching to Bloc resolve these issues at all anyway?
>

I'm not up to date on Bloc progress.
But with the move to a headless VM, all old problems get thrown away (i.e.
so we can make new problems ;)
so HiDPI is likely to have the opportunity to be addressed this iteration.



> 5) Related -- where can one start to learn about current VM architecture
> and development practices?
>
https://hal.archives-ouvertes.fr/hal-01883380/document
https://clementbera.wordpress.com/2016/05/30/simulating-the-cog-vm/



> That said I'm not here to just bellyache. While I don't have any VM
> experience, I'm willing to jump in and try to work on it if someone can
> point me in the right direction. Or perhaps this is too specialized a
> task...
>

Hopefully it will become less specialised soon.
Would you volunteer for early testing of windowing driven from Image side
of headless-VM ?

cheers -ben

Re: [Pharo-dev] Pillar branch names (was: ConfigurationOfGrease for Pharo8)

[Ben Coman]

On Sun, 10 Feb 2019 at 00:32, Alistair Grant  wrote:

> Hi Guille,
>
> On Mon, 4 Feb 2019 at 09:43, Guillermo Polito 
> wrote:
> >
> > On Mon, Feb 4, 2019 at 9:28 AM Alistair Grant 
> wrote:
> >>
> >> Hi Stef,
> >> On Mon, 4 Feb 2019 at 09:20, ducasse  wrote:
> >> >
> >>
> >> The dev-7 branch loads fine in Pharo 8.
> >>
> >> > > But what do you mean by "now it is 70”?
> >> >
> >> > I thought that guillermo changed the dev-7 branch.
> >
> > Nope, I think that name is good, and then we manage releases using tags.
> We have the following branches:
>
> What do you think of following the same naming convention as
> pharo-project/pharo, i.e. using branch names Pharo7.0 instead of
> dev-7?
>
> I think that would make it easier for newcomers.
>

Thats what we currently have. Its good for me.
https://github.com/pharo-project/pharo/branches

cheers -ben

Re: [Pharo-dev] Roadmap for Pharo 8.0

[Ben Coman]

On Fri, 8 Feb 2019 at 02:03, p...@highoctane.be  wrote:

> Sounds awesome.
>
> Getting the basics rock solid and as a first class server citizen. Sweet!
>
> Phil
>
> On Thu, Feb 7, 2019, 16:09 Esteban Lorenzano 
>> Hi list,
>>
>> We started Pharo 8.0 development and we wanted to share (and discuss, if
>> needed) what is our current Roadmap for Pharo 8.0.
>> As you can see, Windows is getting some love, and also UI.
>> Anyway, here it is:
>>
>> Image
>> ===
>> 1) Missing parts for headless VM to work (explained a bit later)
>> 2) We need to improve Epicea speed. And in general, source access speed.
>> We want to remove the old changes file (since Epicea already does that
>> works and a lot more).
>> 3) Improve Refactors
>> 4) Improve Calypso
>> 5) Introduce Spec2 (our re-work on this framework).
>> - We also want to migrate our tools to it (Inspector, Debugger,
>> Spotter and Calypso are the remaining parts). We will see how much of this
>> migration can be done.
>>
>

>> VM/Low-level side
>> ===
>> 1) headless vm
>> We want to have a real headless VM and make it our default VM.
>> To it, most of the work vm-side is already made by Ronie, but there are
>> missing parts:
>> - a build on windows
>> - image side capabilities: we use SDL2 to start the world, and it mostly
>> works... but not completely.
>>
>>
yay, yay and yay!
This should be great for smaller IoT devices.


One cool thing of this is that we will -finally- be able to clean the event
>> handling, which is ugly (and works bad).
>>
>
Could the scope of the headless vm encompass embed-ability?
@community, are there any use cases you might like to work on to provide a
practical test of such an interface?
e.g. events might need to come from a game engine for that integration to
work properly.


2) Windows several missing/non working parts:
>> - file primitives are slow. This is because they rely in old APIs and we
>> need to put them in "state of the art".
>> - libgit2 does not processes long paths. We workarounded the problem with
>> tonel, but at a point we need to take care about this. Real problem with
>> this is we need to contribute the solution to libgit2, but this is also
>> good Open Source policy (contributing back).
>> - OSSubprocess in windows. We believe we need to extend OSSubprocess (our
>> solution to communicate with system) to windows. And we believe is possible
>> ;)
>>
>> 3) ThreadedFFI.
>> It is already too much time since we have this in agenda. Is time to make
>> it real.
>>
>
cool.  that might help with embedding in a game engine?

cheers -ben


> 4) memory policies.
>> Tweaking the VM to enhance its memory usage is possible, but hard. We
>> want to adopt an scheme of "memory policies" that will allow users to pick
>> what they need.
>>
>> Process
>> ===
>> 1) We will add multiple source directories to Iceberg. This is needed to
>> allow us to put all Pharo sub-projects into an unique project without
>> breaking modularisations.
>>
>> Others
>> ===
>> 1) Launcher
>> - Launcher us getting a new UI
>> - Tests
>> - It needs to be more solid (in part, that's the reason why we
>> want OSSubprocess in windows).
>> 2) Cargo
>> - We need to revisit cargo (a new dependency manager) and at a
>> point decide if it will fly or not :)
>>
>> Nice to have (most probably not this version, but in our TODO) :
>> - embedded VM
>> - event driven VM
>> - what happens if we split VM into main thread and vm thread?
>>
>

Re: [Pharo-dev] An article that talks about Pharo in a portal from México

[Ben Coman]

On Tue, 5 Feb 2019 at 17:58, Esteban Lorenzano  wrote:

> https://www.unocero.com/smartphones/pharo-7-internet-de-las-cosas/
>

Nice. Google translate works wonders.


> 2. IoT has a lot of attention at this moment.
>

IoT is new to a lot of people, which presents an opportunity since people
are
more receptive to new ideas when they are already in an exploring mode.

cheers -ben

Re: [Pharo-dev] iceberg: merging branches just at the git level without changing code in the image

[Ben Coman]

On Tue, 5 Feb 2019 at 01:19, Andrei Chis  wrote:

> Hi,
>
> Currently in Iceberg to merge a branch into another, we need to checkout
> the branch into which we want to merge and then do the merge.
> Checking out a branch also updates the code in the image, which when
> needing to perform automatic releases on a branch can cause issues.
>
> Is there already a way in Iceberg to switch to a branch (for example
> `release`) and then merge another branch (for example `master`) into it
> without updating any code in the image?
> The use-case is that the user is on the `master` branch and needs to merge
> `master` into `release` without changing any code in the image.
>

Another use case for this might be where I recently wanted to resurrect an
old PR
to contribute to Pharo 8 and loading the old code broke the image.  I'd to
update the PR
by merging master into it without loading it.  Rebasing the old PR onto
master would be even better.

Perhaps the existing  button becomes a  button
and the  button presents a dialog for any any-to-any disc-only merge
(default would be "selected" commit into the image's "current" commit)

cheers -ben

Re: [Pharo-dev] Spotter shortcut reset

[Ben Coman]

On Sun, 3 Feb 2019 at 23:25, webwarrior  wrote:

> Ben Coman wrote
> > On Sat, 2 Feb 2019 at 18:54, ducasse <
>
> > stepharo@
>
> > > wrote:
> >
> > ...
> >
> > 3. Ticked "Free tier only" filter.
> > + Selected "Amazon Linux 2 AMI (HVM), SSD Volume Type"
> > + Clicked
> > 
> >   (used default t2.micro)
> > + Clicked
> > 
> > + From the pull-down selected "Create a new key pair",
> > gave it a name and clicked
> > 
> >  saved as
> > "SydneyPharoSpeedTest.pem"
> > + Clicked
> > 
> > + Clicked
> > 
> > noted instance...
> > * IP address: 54.252.136.78
> > * Zone: ap-southeast-2b
> > * Security Group: Launch Wizard 1
> >
> > 4. On my Windows 10 box, in WSL did...
> > $ cd ~/.ssh   # if it doesn't exist, first do...   mkdir -m 700
> ~/.ssh
> > $ cp /mnt/c/Users/Ben/Downloads/SydneyPharoSpeedTest.pem   ~/.ssh
> > $ chmod 400 ~/.ssh/SydneyPharoSpeedTest.pem
> > $ ssh -i ~/.ssh/SydneyPharoSpeedTest.pem  ubuntu@54.252.136.78$ cat
> > /etc/os-release
> > ID="amzn"
> > ID_LIKE="centos rhel fedora"
> >
> >
> > GOOD NETWORK BASELINE TEST...
> > Ignoring any packet loss on poor networks, first testing low bandwidths
> on
> > a good network
> > $ vi test.sh
> > #!/bin/sh
> > if [ -d out ]; then
> > dirdate=`stat -c %z out | awk '{print $1"-"$2}' `
> > mv out out.${dirdate}
> > fi
> > mkdir out
> > for RATE in 1000k 500k 200k 100k 50k 20k 10k 5k 2k 1k
> > do
> >   echo $RATE
> >   /usr/bin/time -f "%e" -o out/time.$RATE \
> >wget --quiet --limit-rate $RATE
> > https://files.pharo.org/pharo-launcher/1.6/pharo-launcher-1.6.msi -O
> > out/file.$RATE &
> > done
> >
> > $ sh test.sh
> > monitoring with...
> > $ cat out/time* | sort -n
> > $ ls -lS out
> >
> > results in following table and graphs...
> > $RATE
> > (kb/s) TIME
> > (s) TIME
> > (min) TIME
> > (hr)
> > 1000 54 1 0.0
> > 500 105 2 0.0
> > 200 259 4 0.1
> > 100 515 9 0.1
> > 50 1029 17 0.3
> > 20 2576 43 0.7
> > 10 5149 86 1.4
> > 5 10527 175 2.9
> >
> > [image: download-speed.png]
> >
> > Wow that surprised me.  I'm not sure what the behaviour of file servers
> at
> > low bandwidth should be,
> > but intuitively the above seems odd.  In the past troubleshooting seems
> to
> > have been
> > focused on the cause of slow speeds, but these can occur for many reasons
> > unrelated to the
> > the file server.  The above test ignores cause to isolate behaviour at
> > slow
> > speeds.
> >
> > I forgot my own download speed yesterday (today is okay), but here is
> > another sample...
> > "(in Argentina) it is really slow ... 3.5KB/s ... average 10KB/s".
> > http://forum.world.st/Pharo-Downloads-are-sluggish-td5084963.html
> >
> > I would hope that download time was near linear with speed all the way
> > down
> > to 1kb/s.
> > Anyone have some sysadmins they can lean on to understand if that is
> > realistic?
> >
> > The straightness of the line using a log-log axis makes it seem like
> > policy
> > rather than physics.
> > [image: download-speed(log).png]
> >
> > HTH,
> > cheers -ben
> >
> >
> > download-speed.png (39K)
> > <http://forum.world.st/attachment/5094677/0/download-speed.png>;
> > download-speed(log).png (34K)
> > <
> http://forum.world.st/attachment/5094677/1/download-speed%28log%29.png>;
>
> Why does that surprise you?
>
> Download time [s] = amount of data [B] / bandwidth [B/s].
> Your data and graphs look exactly like they should. When bandwidth -> 0,
> time
> -> +infinity.
>

Hey! Thanks for that reality check.
100kb ==> 515s
10kb ==>  5149s
duh! makes perfect sense.  I was sure I had checked that simple scaling
and it had been out by another magnitude, but I must have had a screw loose
from being too caught up in the graph.
It was just meant to be a prelude baseline before playing with random
packet loss.
Sorry for the noise.

cheers -ben

Re: [Pharo-dev] Spotter shortcut reset

[Ben Coman]

On Sat, 2 Feb 2019 at 18:54, ducasse  wrote:
> On Sat, 2 Feb 2019 at 11:01, Ben Coman  wrote:
>
> > I am getting network errors trying to download latest Pharo Launcher,
>
> can you tell me how so that I try to reproduce it?

Since network performance depends a lot on location, and presuming you'd
need to be at my house to reproduce my experience,
I spent the afternoon learning about AWS so I could do some testing from a
Australian based cloud box
that you should be able to reproduce fairly easily, since this was my first
time using AWS.

With this 10 minute tutorial...
[Launch a Linux Virtual Machine](
https://aws.amazon.com/getting-started/tutorials/launch-a-virtual-machine/)
1. Signed up and signed in
Tip: I struggled a long while looping on "Sign in with root account
credentials" until I discovered I needed to use the email address I signed
up with, not the account name.

[Edit:] In the top right between account name and support,
pulled down list and selected "Asia Pacfic (Sydney)"


2. Clicked "Launch a virtual machine"
(note, that only seems to show up for blank account, otherwise its "Launch
Instance"


3. Ticked "Free tier only" filter.
+ Selected "Amazon Linux 2 AMI (HVM), SSD Volume Type"
+ Clicked   (used default t2.micro)
+ Clicked 
+ From the pull-down selected "Create a new key pair",
gave it a name and clicked  saved as
"SydneyPharoSpeedTest.pem"
+ Clicked 
+ Clicked 
noted instance...
* IP address: 54.252.136.78
* Zone: ap-southeast-2b
* Security Group: Launch Wizard 1

4. On my Windows 10 box, in WSL did...
$ cd ~/.ssh   # if it doesn't exist, first do...   mkdir -m 700 ~/.ssh
$ cp /mnt/c/Users/Ben/Downloads/SydneyPharoSpeedTest.pem   ~/.ssh
$ chmod 400 ~/.ssh/SydneyPharoSpeedTest.pem
$ ssh -i ~/.ssh/SydneyPharoSpeedTest.pem  ubuntu@54.252.136.78$ cat
/etc/os-release
ID="amzn"
ID_LIKE="centos rhel fedora"


GOOD NETWORK BASELINE TEST...
Ignoring any packet loss on poor networks, first testing low bandwidths on
a good network
$ vi test.sh
#!/bin/sh
if [ -d out ]; then
dirdate=`stat -c %z out | awk '{print $1"-"$2}' `
mv out out.${dirdate}
fi
mkdir out
for RATE in 1000k 500k 200k 100k 50k 20k 10k 5k 2k 1k
do
  echo $RATE
  /usr/bin/time -f "%e" -o out/time.$RATE \
   wget --quiet --limit-rate $RATE
https://files.pharo.org/pharo-launcher/1.6/pharo-launcher-1.6.msi -O
out/file.$RATE &
done

$ sh test.sh
monitoring with...
$ cat out/time* | sort -n
$ ls -lS out

results in following table and graphs...
$RATE
(kb/s) TIME
(s) TIME
(min) TIME
(hr)
1000 54 1 0.0
500 105 2 0.0
200 259 4 0.1
100 515 9 0.1
50 1029 17 0.3
20 2576 43 0.7
10 5149 86 1.4
5 10527 175 2.9

[image: download-speed.png]

Wow that surprised me.  I'm not sure what the behaviour of file servers at
low bandwidth should be,
but intuitively the above seems odd.  In the past troubleshooting seems to
have been
focused on the cause of slow speeds, but these can occur for many reasons
unrelated to the
the file server.  The above test ignores cause to isolate behaviour at slow
speeds.

I forgot my own download speed yesterday (today is okay), but here is
another sample...
"(in Argentina) it is really slow ... 3.5KB/s ... average 10KB/s".
http://forum.world.st/Pharo-Downloads-are-sluggish-td5084963.html

I would hope that download time was near linear with speed all the way down
to 1kb/s.
Anyone have some sysadmins they can lean on to understand if that is
realistic?

The straightness of the line using a log-log axis makes it seem like policy
rather than physics.
[image: download-speed(log).png]

HTH,
cheers -ben

Re: [Pharo-dev] Spotter shortcut reset

[Ben Coman]

On Sat, 2 Feb 2019 at 17:48, ducasse  wrote:

> Ben
>
> How did you do it?
> I downloaded the latest version


By "latest version" do you mean direct download of Pharo 8.0

I don't have Pharo 8.0 listed in my Pharo Launcher.
I am getting network errors trying to download latest Pharo Launcher,
so I created a fresh Pharo 7.0.1 and Spotter works fine out of the box.
Then I used Iceberg to update to Pharo 8.0, this breaks Spotter.
Certainly not the recommended way, but its all I got at the moment to get
into Pharo 8.0 development.

cheers -ben


> and Spotter worked well (>I broke it but loading old code from Pharo 60).
>
> Stef
>
> > On 2 Feb 2019, at 10:25, Ben Coman  wrote:
> >
> > I upgraded Pharo 7.0.1 to latest Pharo 8.0 branch.
> > Now when I hit  I get a debugger...
> >  Instance of AnObsoleteGTSpotterGlobalShortcut class did not
> understand #openGlobalSpotter
> >
> > Although not a certified way to upgrade, its maybe useful.
> > I've looked through settings and class-side methods for some way to
> reset this.
> > Is there some class reset or initialization that can be run to clear
> this up?
> >
> > cheers -ben
>
>
>
>

Re: [Pharo-dev] Debugger opening on user halt and not Object>>halt

[Ben Coman]

On Sat, 2 Feb 2019 at 08:35, Sean P. DeNigris  wrote:

> Ben Coman wrote
> > The first was me. Not sure about the second. The latter two were someone
> > else.
>
> I always thought that DNU should be on this list too. Am I the only one?
>

It seem to already do this?  In Playground evaluating...
  1 + 1.
  2 unknown.
  3 + 3

opens a debugger on the second line with "unknown" highlighted.
See  at the top of Object>>doesNotUnderstand:
Or do you mean something else?

cheers -ben

[Pharo-dev] Spotter shortcut reset

[Ben Coman]

I upgraded Pharo 7.0.1 to latest Pharo 8.0 branch.
Now when I hit  I get a debugger...
 Instance of AnObsoleteGTSpotterGlobalShortcut class did not understand
#openGlobalSpotter

Although not a certified way to upgrade, its maybe useful.
I've looked through settings and class-side methods for some way to reset
this.
Is there some class reset or initialization that can be run to clear this
up?

cheers -ben

Re: [Pharo-dev] contribution workflow

[Ben Coman]

On Tue, 22 Jan 2019 at 17:28, Guillermo Polito 
wrote:

> Hi Ben,
>
> I'll just expand a bit on what Pavel said.
>
> On Mon, Jan 21, 2019 at 4:59 PM Ben Coman  wrote:
>
>> I'm not sure how closely my contribution workflow matches the standard
>> advertised, so just wanted to share it for feedback.  I may remember
>> wrongly, but my understanding of the advertised process was forking the
>> "pharo-project/pharo" repo, then cloning from my fork.  However I found it
>> awkward to keep the "master" branch of my fork synchronised with upstream.
>>
>
> It's important to understand that you don't need to keep any branch in
> your fork synchronized ^^.
> Pull requests bind two branches, not two repositories.
> Your repository may have 30 branches, all outdated, and the only one that
> needs to be "up to date" is the one participating in a pull request.
>
> Even, I'd say it's not really required to have the branch of the PR up to
> date either, as git will just make a merge with it, calculating correctly
> the point of divergence between the two branches. However, making a branch
> that started too far away in the history (too old) will just increase the
> possibility of a merge conflict.
>



> Actually, the easiest is that you start working on a branch whose tip
> points to the same commit the image was created from.
> This is to make sure that:
>  - you will have correct diffs
>  - your PR does not introduce commits that you did not intend to
>

Sure, I often do the same to avoid feeling lost when I don't understanding
where extra changes are coming from.
However right now I have a PR from November that didn't make it into Pharo
7 and I'm now trying bring forward for Pharo 8.
Could work with me to reproduce this to see where I'm going wrong...

My image is up to date with Pharo 8, 2019-01-31 19:23, commit 2c0b5d0.
I repaired the "pharo" repo  such that remotes after repairing are...
* origin = g...@github.com:bencoman/pharo.git
* pharo-project = g...@github.com:pharo-project/pharo.git
though if you use https the rest of this workflow should go the same for
you.

Double-checked I was up to date by again checking out
"pharo-project/Pharo8.0".
Now I want to bring forward my changes from
"origin/22637-Minor-cleanup-of-Delay"
Right-clicking on it I only the choice to "Checkout branch", but I don't
want to do that
since I feel its likely to break something.  A checkout doesn't focus on
the package my
changes are in but reverts months of changes through the whole live
system.

The  button is another option, choosing "origin" then
"22637-Minor-cleanup-of-Delay"
In the preview window is a massive amount of changes that have nothing to
do with me.
I guess its again months of every else's changes to Pharo that would be
risky and confusing to proceed.

I feel what I need is something like "origin/22637-Minor-cleanup-of-Delay"
right-click > Rebase to HEAD
which would determine the common ancestor f2078b5 and integrate just my
changes since then.

I can't see any other options.   How would you handle it?

cheers -ben

P.S. Side info on conflict if you bump into it.  DelaySpinScheduler was
removed from Pharo 7 after I submitted that PR for issue 22637.

>

Re: [Pharo-dev] Debugger opening on user halt and not Object>>halt

[Ben Coman]

On Thu, 31 Jan 2019 at 17:15, Guillermo Polito 
wrote:

> Hi Thomas,
>
> Check the pragma debuggerCompleteToSender and its users. I think it's
> related to that.
> BenComan probably can give a better insight since (if I recall correctly)
> he introduced it?
>

Thats right.  Use "Tools > Finder > Source" to search for...
debuggerCompleteToSender
ignoring where its a pragma.

That leaves...
  Process>>complete:
  Process>>stepToHome:
  GTGenericStackDebugger>>filteredStack
  GTGenericStackDebugger>>setDebuggerToFirstNonFilteredContext

The first was me. Not sure about the second. The latter two were someone
else.



> Guille
>
> On Wed, Jan 30, 2019 at 5:44 PM Thomas Dupriez <
> tdupr...@ens-paris-saclay.fr> wrote:
>
>> Hello,
>>
>> Does someone know which is the code responsible for the debugger opening
>> on the halt of the user instead of Object>>halt (see picture)? It's neat
>> but it's not the regular behaviour so I'm guessing it is handled somewhere
>> specifically for halt messages?
>>
>
Its not just for halt, but for any method that you don't want the debugger
opening in the method sending #signal.
Is your snapshot based on modified code? In
Pharo-7.0.1+build.146.sha.c48755acc5f489337be0e7abc882c15b1707b254 (32 Bit)
in Playground I evaluate...
1 + 1.
self halt.
2 + 2.
and my top line is the same as your second line.

cheers -ben

Re: [Pharo-dev] [ANN] SmalltalkCI now supports Pharo 8

[Ben Coman]

Only in the past week I became aware of that SmalltalkCI was integrated
with Travis...
https://docs.travis-ci.com/user/languages/smalltalk

Now I'm really curious, how is it hooked into the back end of Travis?

cheers -ben


On Wed, 23 Jan 2019 at 07:16, Gabriel Cotelli  wrote:

> Now you can run your builds against Pharo 8:
> Check https://github.com/hpi-swa/smalltalkCI#list-of-supported-images
>
> Stable and Alpha versions were also updated, now pointing to Pharo 7 and
> 8 respectively.
>
> Please report any issue you found.
>
> Regards,
> Gabriel
>