[Pharo-dev] String hash function

[Clément Bera]

Hi all,

I am trying to investigate performance overhead in benchmarks to improve
the VM performance. In a benchmark strings are used as dictionary keys,
which seems to be an OK pattern to me that may be actually used in real
code from time to time. Something stroke me: *the hash function of a string
is actually iterating over the whole string. *

As a result, I get something like this:

#(
'String size: 0, Hash function performance: 17,817,776 per second'
'String size: 1, Hash function performance: 15,395,388 per second'
'String size: 3, Hash function performance: 14,853,109 per second'
'String size: 4, Hash function performance: 15,151,954 per second'
'String size: 5, Hash function performance: 14,139,881 per second'
'String size: 10, Hash function performance: 11,545,749 per second'
'String size: 65, Hash function performance: 3,431,067 per second'
'String size: 130, Hash function performance: 1,879,047 per second'
'String size: 520, Hash function performance: 511,934 per second'
)

This means that if a hash of a 1MB String is computed it takes a hell of a
time.

I wonder why we don't compute the string hash from a small number of inner
characters taken randomly but deterministically from the String. From
example, for all strings longer than 5 characters, one could pick only 5
characters in the String to compute its hash. The hash function is this way
decent enough and the performance does not drop for large strings.

One implementation could be to replace:
1 to: stringSize do: [:pos |
by:
1 to: stringSize by: stringSize // 5 do: [:pos |
in:
ByteString>>stringHash: aString initialHash: speciesHash

Then we need to rehash the whole image.

What do you think ? Is there a hash expert around that can confirm this is
a good idea ?

Re: [Pharo-dev] changing default theme to DarkTheme

[Clément Bera]

Isn't a couple days before release a bit late to change the default theme ?
Aren't we in feature freeze mode ?

If for marketing it makes sense to switch to the dark theme, then let's
switch to dark theme. But why not switching for Pharo 7 instead ?
Instability is bad for marketing anyway, isn't it ?

I don't mind for myself, I will always switch back with user settings to
the light theme it's more about the general perception of Pharo stability.

On Sat, Apr 15, 2017 at 11:31 AM, p...@highoctane.be 
wrote:

> Bah, I made GTSpotter dark theme work with SublimishTheme and got the
> "yeah, for Pharo7".
>
> It is pissing me off but what can I say, just follow what is released.
>
> Compare Pharo 1 and Pharo 6. Worlds apart. I hope this continues.
>
> Phil
>
> On Sat, Apr 15, 2017 at 4:48 PM, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
>
>> I vote for a voting system for these kind of changes. I cannot say it
>> more clearly, and I don't know why is asking for a voting system negative?
>>
>> We all have problems. In the meantime you will make all the changes you
>> like to do, and I will continue working on my own way, until I find there
>> is more voice for the "small minority".
>>
>> 2017-04-15 9:30 GMT-03:00 Stephane Ducasse :
>>
>>> Hi Hernan
>>>
>>> Why are you always so negative? Do you think that this is easy?
>>>
>>> Inria paid Denis to build a remote tool suite for ***research purpose***
>>> and we discovered that a new remote invocation framework was needed and
>>> that they were far too many discussions between the model and the view.
>>> Denis proposed to build a new browser (and it was not in our plans) and
>>> we decided that we cannot do it otherwise.
>>> We could keep this tool for us but we share it with the community.
>>>
>>> Do you want another example?
>>> I asked christopher to build versionner and he discovered that he cannot
>>> script well enough the model. And versionner was made
>>> for everybody. Now with git we will have to revise it.
>>>
>>> Do you want another example?
>>> Iceberg we payed nicolas passerini to analyse the situation and to build
>>> a system that other people
>>> can use it.
>>>
>>> Do you want another example?
>>> Esteban got in his face the FFI problem: you see Spur arrives and FFI
>>> nabive boost does not so what do we do?
>>> He worked like a mad (and it was not planned because we thought that
>>> igor would adpta NB to spur then to 64 bits).
>>> And the FFI is for everbody.
>>>
>>> Do you want another example?
>>> We spent one year with pavel, guillermo and christophe to make sure that
>>> we can make sure that the three yars
>>> effort of the phd of guillermo on bootstrap are not lost.
>>>
>>> Do you want more?
>>> All my books are open-source? Do you know how much time I take to write
>>> a book?
>>>
>>> I spent 8 months designing a mooc and do you know how much I earned
>>> doing it: 3000 Euros ( so I will make the computation to know how much per
>>> hour I lost) and the mooc is free.
>>>
>>> May be all these examples have no value for you. But for me they have.
>>>
>>> So you see you can piss on us if it makes you feeling better, and you
>>> can rant in your corner.
>>> But this is not the vision I have about a community because we are
>>> sharing all the things that we are doing.
>>>
>>> Stef
>>>
>>>
>>>
>>>
>>> On Sat, Apr 15, 2017 at 9:05 AM, Hernán Morales Durand <
>>> hernan.mora...@gmail.com> wrote:
>>>

 2017-04-14 8:44 GMT-03:00 Denis Kudriashov :

>
> 2017-04-14 13:27 GMT+02:00 Esteban Lorenzano :
>
>> Also I am really wondering that this decision was not publicly
>> discussed. We should vote for such kind of changes.
>>
>>
>> no, this is not how it works.
>>
>
> yes, it is how it could work :)
>
> Current approach is not bad for technical choices because it is
> difficult to make everybody evolved in particular technical topic.
> But look&feel is different. You just open Pharo and have impression is
> it looks good or not. Voting can work here.
>

 I would forget about it. I stopped waiting for votes long time ago in
 this community. Also I decided to stop contributing to external projects
 (including reporting bugs) because who knows which tool (browser, morphic,
 etc) the board would like to add/remove tomorrow. I will not invest my time
 fixing tools who knows what's the plan on them.

 The best you can do is to work in the dark and adapt your stuff with
 each new Pharo version.
 Of course anyone with enough time/money could fork a new more
 democratic Pharo ;)

 Hernán


>>>
>>
>

Re: [Pharo-dev] resizing the windows sometimes blocks the image

[Clément Bera]

Hi

Try resizing the window and clicking inside it a couple times. It usually
refreshes the surface correctly and avoids the need to force quit.

I think it happens to other people too, it seems it's exclusive to Mac OS X.

Best,

On Wed, May 3, 2017 at 10:23 AM, Andrei Chis 
wrote:

> Hi,
>
> With the latest moose image based on Pharo 6 and vm (32 bit) sometimes
> when I resize the main window or enter full screen mode on MacOS the window
> becomes totally white and does not recover:[image: Inline image 1]
> I need to force quit the image.  Also this happens not that often and
> quite randomly.
>
> Does this happen to anybody else or it's just me?
>
> Cheers,
> Andrei
>

Re: [Pharo-dev] Missing plugins to make the vmProfiler work on Pharo

[Clément Bera]

Hi Max,

She has already done that. The point is to add the plugins in the default
Pharo VM, so everyone can use the VM profiler. We would like to have the VM
profiler loadable through the Pharo catalog, but many people won't be able
to use it if the default Pharo VM does not support it...

The plugin is lightweight, so I don't see why we can't have it.

Best,

On Wed, May 10, 2017 at 3:00 PM, Max Leske  wrote:

> Hi Sophie,
>
> You will have to compile your own VM for the moment. It's fairly easy but
> you might run into problems when including the extra plugin. To build the
> VM, follow the instructions on https://github.com/
> OpenSmalltalk/opensmalltalk-vm and read the README and HOWTO files.
> Simple build example:
>
> cd ~/git/opensmalltalk-vm/build.macos32x86/pharo.cog.spur/ && ./mvm -d
>
> will build a debug VM. You'll have to modify one of the "plugins.*" files
> to include the plugin.
>
> HTH,
> Max
>
> On 10 May 2017, at 14:36, Sophie Kaleba  wrote:
>
> Hi Esteban, Hi all,
>
> I am working on porting the Squeak VMProfiler to Pharo as a gsoc (I will
> post a more detailed presentation about that in the mailing list later
> today).
>
> While trying to use the profiler with the Pharo VM, I get the following
> error : "PrimitiveFailed : primitive #primitiveExecutableModules in
> VMProfilerLinuxSymbolsManager failed". (see stack trace attached).
>
> This plugin (VMProfileLinuxSupportPlugin) does not seem to be included by
> default in the Pharo VM (it works with a Squeak VM). I haven't tried on a
> mac, but I guess the plugin (VMProfileMacSupportPlugin) is missing too.
>
> For the moment, I am using the latest Squeak VM with my Pharo image but it
> is not quite convenient. Would it be possible to include the 2 plugins to
> the Pharo VM ?
>
> If I can be of any help, just tell me
> Thanks!
>
> Sophie
>
>
>
>
>
>
> 
>
>
>

Re: [Pharo-dev] Missing plugins to make the vmProfiler work on Pharo

[Clément Bera]

On Wed, May 10, 2017 at 5:28 PM, Esteban A. Maringolo 
wrote:

> If it is a plug-in, why does it need VM recompilation?
>
Internal plugins require VM recompilation. Only external plugins do not.

>
> Esteban A. Maringolo
>
>
>
>
>
>
> 2017-05-10 12:15 GMT-03:00 Nicolas Cellier  gmail.com>:
> > Hi Sophie,
> > you could try and modify the plugins.int or plugins.ext files for
> various
> > pharo distributions and do a pull request on github opensmalltalk-vm.
> > Then let Esteban accept the request or not before the release of Pharo...
> > (if the build are green, there's no reason to not accept it).
> >
> > 2017-05-10 15:39 GMT+02:00 Max Leske :
> >>
> >> OK, I see.
> >>
> >>
> >> On 10 May 2017, at 15:11, Clément Bera  wrote:
> >>
> >> Hi Max,
> >>
> >> She has already done that. The point is to add the plugins in the
> default
> >> Pharo VM, so everyone can use the VM profiler. We would like to have
> the VM
> >> profiler loadable through the Pharo catalog, but many people won't be
> able
> >> to use it if the default Pharo VM does not support it...
> >>
> >> The plugin is lightweight, so I don't see why we can't have it.
> >>
> >> Best,
> >>
> >> On Wed, May 10, 2017 at 3:00 PM, Max Leske  wrote:
> >>>
> >>> Hi Sophie,
> >>>
> >>> You will have to compile your own VM for the moment. It's fairly easy
> but
> >>> you might run into problems when including the extra plugin. To build
> the
> >>> VM, follow the instructions on
> >>> https://github.com/OpenSmalltalk/opensmalltalk-vm and read the README
> and
> >>> HOWTO files. Simple build example:
> >>>
> >>> cd ~/git/opensmalltalk-vm/build.macos32x86/pharo.cog.spur/ && ./mvm -d
> >>>
> >>> will build a debug VM. You'll have to modify one of the "plugins.*"
> files
> >>> to include the plugin.
> >>>
> >>> HTH,
> >>> Max
> >>>
> >>> On 10 May 2017, at 14:36, Sophie Kaleba 
> wrote:
> >>>
> >>> Hi Esteban, Hi all,
> >>>
> >>> I am working on porting the Squeak VMProfiler to Pharo as a gsoc (I
> will
> >>> post a more detailed presentation about that in the mailing list later
> >>> today).
> >>>
> >>> While trying to use the profiler with the Pharo VM, I get the following
> >>> error : "PrimitiveFailed : primitive #primitiveExecutableModules in
> >>> VMProfilerLinuxSymbolsManager failed". (see stack trace attached).
> >>>
> >>> This plugin (VMProfileLinuxSupportPlugin) does not seem to be included
> by
> >>> default in the Pharo VM (it works with a Squeak VM). I haven't tried
> on a
> >>> mac, but I guess the plugin (VMProfileMacSupportPlugin) is missing too.
> >>>
> >>> For the moment, I am using the latest Squeak VM with my Pharo image but
> >>> it is not quite convenient. Would it be possible to include the 2
> plugins to
> >>> the Pharo VM ?
> >>>
> >>> If I can be of any help, just tell me
> >>> Thanks!
> >>>
> >>> Sophie
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>
> >>
> >
>
>

Re: [Pharo-dev] Missing plugins to make the vmProfiler work on Pharo

[Clément Bera]

On Wed, May 10, 2017 at 8:12 PM, Esteban A. Maringolo 
wrote:

> 2017-05-10 13:38 GMT-03:00 Clément Bera :
> > On Wed, May 10, 2017 at 5:28 PM, Esteban A. Maringolo <
> emaring...@gmail.com> wrote:
>
> >> If it is a plug-in, why does it need VM recompilation?
> >
> > Internal plugins require VM recompilation. Only external plugins do not.
>
> It was more of a semantic question, I'd expect a plug-in to be that,
> pluggable, as you say external plugins are.
> Or what is the "pluggability" of such plugins?
>

I would say there is 3 levels of pluggability:
1 non optional internal plugin, pluggable because it can be replaced by
another internal plugin implementing the same API at VM compilation time.
Used for modularity of specific aspects of the VM.
2 optional internal plugin, pluggable because it can be removed / added /
replaced at VM compilation time. Used to improve performance over external
plugin or to access VM functions not exposed to external plugins.
3 external plugin, pluggable because it can be removed / added / replaced
after the VM is compiled. Used for all other plugins.

So they're all pluggable in some way.


> Disclaimer: I don't know about the VM internals (*), and this is not a
> complain of any sort. I just wonder it is called that way.
>
> Regards!
>
> Esteban A. Maringolo
>
> (*) I did compile a Squeak VM a decade ago (added two primitives) but
> nothing more than that.
>
>

Re: [Pharo-dev] immediateByteSubclass: ?

[Clément Bera]

This one looks strange and seems indeed to be dead code.

Maybe it was an attempt to make a specific class definition keyword for
CompiledMethod / CompiledCode / CompiledBlock. Right now there is a
specific case in the code somewhere to use the specific compiledCode layout
for those 3 classes instead of the byte layout which is normally used for
the keyword variableByteSubclass: that those 3 classes use.

I am not sure immediateByteSubclass: makes sense though. I would rather
have compiledCodeSubclass, variablePointerAndByteSubclass or something like
that.

On Fri, May 12, 2017 at 5:39 PM, Stephane Ducasse 
wrote:

> Hi
>
> with guille we are working on a class parser and our game is to make sure
> that we can parse all the crazy class definitions among which
>
> variableWordSubclass:
> ephemeronSubclass:
> weakSubclass:
> variableByteSubclass:
> variableSubclass:
> immediateSubclass:
> subclass: aSubclassSymbol  layout:
>
> And we found this method definition and it has no senders and we wonder if
> it is just plain deadcode?
>
> immediateByteSubclass: className instanceVariableNames: instvarNames
> classVariableNames: classVarNames package: package
> "Added to allow for a simplified subclass creation experience. "
>
> ^ self
> immediateSubclass: className
> instanceVariableNames: instvarNames
> classVariableNames: classVarNames
> package: package
>
> S & G
>

[Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

[Clément Bera]

Hi Thierry, hi all,

The Pharo catalog version of OSProcess is not working in the Pharo 6
release and I need to load OSProcess in one of my projects. I cannot load
OSSubProcess instead, so no need to answer this mail talking about it.

In-between version 2231 and 2241 of VMMaker, the vm parameter 1002 (os
version), has changed on Mac from '1011.6' to '10.11.6'. OSProcess tests
the version number against 1000, and should now test against 10.

I checked the SqueakSource repo of OSProcess, I can see that the last
version is 4.6.8 and the catalog configuration loads an older version, but
I cannot see any fix related to the version number ?

Can someone update the OSProcess configuration in the Pharo catalog so that
it loads a working version in the Pharo 6 release or point me to an
OSProcess configuration, outside of the catalog, which works in the release
of Pharo 6 please ?

Thank you very much.

Clement

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

[Clément Bera]

Ok.

Maybe when things are fixed we should update the Pharo 6 release version
(the one-click) to have a version with OSProcess working.

Cyril the production Pharo VM are now generated from opensmalltalk-vm.
There is no separate Pharo build. Just saying to avoid fireworks.

On Tue, Jun 20, 2017 at 5:08 PM, Cyril Ferlicot 
wrote:

> On Tue, Jun 20, 2017 at 5:04 PM, Eliot Miranda 
> wrote:
> > Hi Clément
> >
> >
> > That was a mistake of mine.  In the current VM it now answers e.g.
> 1011.6 and so things should be working again.
> >
>
> Hi!
>
> The problem is that the stable vm does not have the fix and the
> current latest vm is **rally* slow. It happens at least on
> OSX. I don't know if it is a known problem or if it comes from the
> opensmalltalk build or the pharo build.
>
> I got the VM here: http://files.pharo.org/vm/pharo-spur32/mac/
>
>
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>
>

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

[Clément Bera]

On Thu, Jun 22, 2017 at 8:03 AM, Stephane Ducasse 
wrote:

> Clement why you cannot load OSSubprocess?
>
>
1) project has to work on itimer Linux VM.
2) existing project working with OSProcess and I don't want to spend time
migrating.
3) code base has to work at least in Squeak and Pharo, I don't want to add
extra code so it uses different frameworks in different platforms and then
maintain this extra code.


>
>
> On Tue, Jun 20, 2017 at 3:10 PM, Clément Bera 
> wrote:
> > Hi Thierry, hi all,
> >
> > The Pharo catalog version of OSProcess is not working in the Pharo 6
> release
> > and I need to load OSProcess in one of my projects. I cannot load
> > OSSubProcess instead, so no need to answer this mail talking about it.
> >
> > In-between version 2231 and 2241 of VMMaker, the vm parameter 1002 (os
> > version), has changed on Mac from '1011.6' to '10.11.6'. OSProcess tests
> the
> > version number against 1000, and should now test against 10.
> >
> > I checked the SqueakSource repo of OSProcess, I can see that the last
> > version is 4.6.8 and the catalog configuration loads an older version,
> but I
> > cannot see any fix related to the version number ?
> >
> > Can someone update the OSProcess configuration in the Pharo catalog so
> that
> > it loads a working version in the Pharo 6 release or point me to an
> > OSProcess configuration, outside of the catalog, which works in the
> release
> > of Pharo 6 please ?
> >
> > Thank you very much.
> >
> > Clement
>
>

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Clément Bera]

Hi all,

Just to be clear, in Pharo 7, if I want to get some code integrated:
- I *have to* use the pull request process described by Pavel
OR
- I *can* use the pull request process, but I can also use the old slice
monticello process
?

What is the answer to the first question now, and what will be the answer
of this question in 6 months from now ?

Thanks


On Wed, Jun 28, 2017 at 3:42 PM, Ben Coman  wrote:

>
>
> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka 
> wrote:
>
>>
>> El 28-06-2017, a las 02:57, Ben Coman  escribió:
>>
>>
>>
>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <
>> pavel.kriva...@gmail.com> wrote:
>>
>>>
>>>
>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich 
>>> :
>>>
 On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek
  wrote:
 >
 >
 > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <
 serge.stinckw...@gmail.com>:
 >>
 >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek
 >>  wrote:
 >> > Hi,
 >> >
 >> > this mail describes how to start to send pull requests to Pharo 7
 Github
 >> > repository from Pharo 7.
 >>
 >> Thank you for the great explanation Pavel.
 >>
 >> > Preparations
 >> > =
 >> >
 >> > - you need to have a Github account and set SSH keys. See
 >> > https://help.github.com/articles/connecting-to-github-with-ssh/
 >> > - create own pharo-project/pharo repository fork. Go to
 >> > https://github.com/pharo-project/pharo, click on "Fork" button and
 >> > follow
 >> > the instructions
 >>
 >> [ ... ]
 >>
 >> > Issue processing
 >> > =
 >> >
 >> > - create new case on FogBugz to get the issue number
 >> > - open Iceberg and from the context menu on the 'pharo' repository
 do:
 >> > Pharo
 >> > - Create new branch from FogBugz issue, enter the issue ID and it
 will
 >> > fill
 >> > the full branch name for you
 >> > - create your changes (you can do it before the creation of the
 branch
 >> > too)
 >> > - commit and push your changes in Iceberg, this way you will
 commit your
 >> > branch to your fork repository. Remember that the Iceberg commit
 window
 >> > has
 >> > two buttons, one for local commit, the second for commit with
 immediate
 >> > push. They can be very long because they contain the full branch
 (issue)
 >> > name
 >> > - in Iceberg in the 'pharo' repository context menu do: Pharo -
 Create
 >> > pull
 >> > request, fill your
 >> > - fill your Github credentials
 >> > - leave the PR title, comment is not required, check the pull
 request
 >> > head
 >> > and base. The base MUST be pharo-project/pharo development. Create
 the
 >> > pull
 >> > requests
 >> > - go to https://github.com/pharo-project/pharo/pulls, check your
 pull
 >> > requests and put URL of it into the issue record on FogBugz (as a
 >> > comment).
 >> > Resolve the issue as Fix review needed
 >>
 >> It means, there is no PR without a corresponding FogBugz issue ?
 >
 >
 > Yes, at least for code changes we would like to keep this relation.
 If it is
 > a really trivial change in readme or something like that, we can
 accept no
 > related issue record.
 > Please prefer to comment the issues instead of PRs directly to have
 all
 > information at one place.

 Thank you Pavel for the explanation.

 Maybe in the future, it will make sense to put everything in the PR
 and use github issues.
 You will use CI travis builds for all PR ?

>>>
>>> For now we will use FogBugz because it has a lot of nice features and
>>> good API. Maybe we will switch it in future but now we should not change
>>> too many things at once :-)
>>> For several reasons we now prefer to use own infrastructure for checking
>>> of PRs (mainly because of MacOS issues on Travis). But again, it can be
>>> changed in future.
>>>
>>>
>> It would be interesting to see how this might fit in with our workflow...
>> https://blog.fogcreek.com/fogbugz-github-integration/
>>
>>
>>
>> What is the benefit of the integration? I do not understand it from the
>> given link.
>>
>>
> When you submit a PR on github, Fogbugz is automatically updated with a
> link to the PR.
> Presumably this makes it easier for people reviewing cases in Fogbugz to
> identify the slice to test.
> This is a better link...
> https://blog.fogcreek.com/improved-github-integration-
> automatically-create-bug-events-with-commits/
>
> cheers -ben
>

Re: [Pharo-dev] Discussing the roadmap

[Clément Bera]

The incremental GC is already mentioned in "Better support for large heaps
(GC tuning API, incremental GC)". Now we have a second paragraph about the
incremental GC, that's redundant and the form of the paragraph is not
consistent with the rest of the roadmap where each feature has 1 or 2 lines
of explanations, not 10 lines.

Same thing, the Sista-related introduction is 10 lines instead of 2-3,
which is not consistent with the form of the rest of the roadmap.

Inconsistent form makes the document look unprofessional. We need to make
it consistent, we can't let it like that.

On Sat, Jul 8, 2017 at 8:22 AM, Stephane Ducasse 
wrote:

> > Actually that's a good point - should the roadmap encompass what the
> community can offer too (i hadn't appreciated the distinction )?
>
> Yes it does.
> Esteban (and christophe 60% paid by rmod) and guille (60% but also
> writing papers) cannot do all that alone?
>
>
> > We collectively pay for some things to be achieved, but also we expect
> that we can contribute some of the lower hanging fruit.
>
> Yes and even more.
> We at RMOD are not paid to produce Pharo. Pharo only represents a
> small part of our job evaluation.
> Now if everybody takes 1 hour per week to improve Pharo it will be huge.
>
>
> > Of course some things are at the whim of what itches to scratch, but
> others we may be able to rally around?
> >
> > Tim
> >
> > Sent from my iPhone
> >
> >> On 7 Jul 2017, at 06:11, Stephane Ducasse 
> wrote:
> >>
> >>> On Thu, Jul 6, 2017 at 11:27 PM, Tim Mackinnon 
> wrote:
> >>> I didn’t mean to touch a nerve - and this was why I wrote “minor”
> points - but you did ask for feedback…
> >>
> >> you did not :)
> >> Just that if we just count on fully book engineers working on super
> >> important features we will not make it.
> >> This is why once in a while I sit and fix a boring pop up or related.
> >> I hate the stupid pop up for pakcgae selection and one day I will have
> >> to retry to kill it.
> >>
> >>>
> >>> Point noted on giving user feedback - I’d actually like to fix things,
> but currently its just too hard to submit fixes other than pull requests
> for documentation that is sitting in git hub (and I have submitted those).
> I know you are working on a simpler way to contribute (and getting the
> GitHub process smoothed out is in progress so its not fair to comment on
> that yet as its early days - and much appreciated.
> >>>
> >>> The Alt-Tab issue in the tracker since 2015 - but I will try and
> report others and possibly Calypso might have some better keyboard
> navigation tricks that help.
> >>
> >> do you have the bug entry?
> >>
> >>>
> >>> For website documentation - I’ll take it back, as I went back again
> just now and everything I could think of was there (a lot in the news
> section which I hadn’t noticed). I do think the download page is a bit
> confusing but I know there is work being done on that.
> >>>
> >>> Tim
> >>>
> >>>
> > On 6 Jul 2017, at 19:11, Stephane Ducasse 
> wrote:
> >
> > Only 2 minor items stick out as missing:
> >
> > 1) Continuing to improve keyboard shortcut support (its a lot
> better, but
> > not quite completed - I really miss some shortcuts, particularly the
> ability
> > to meta-tab between windows - ALT-Tab only works in some windows,
> and widen
> > selection in the editor - e.g. CMD-W in IntelliJ to increasing
> select a
> > word, a statement, a function etc)
> 
>  There are three issues there:
>  - moving from the vm the keyboard generation (this will be done via
>  OSWindow and the VM can focus its main job: execution).
>  - then there is the way we declare/manage shortcuts: this is an
>  ongoing efforts where everybody can join. We should remove the
>  hardcoded shortcut and turn them into KeyBindings
>  - Most of the tools will be throw away when bloc will be integrated.
>  Now it does not mean that we should not do it.
> 
>  Now an important point: as a user you should report but you can also
>  contribute.
>  This is super difficult for me to fix something that I have no clue
>  how to reproduce/never encounter.
>  You see the mental model of a real open-source movement is to share
>  but also to produce together and the point is
>  what is the reward model: why should I spend time on pain I do not
>  feel. Of course we are already doing a lot
>  of actions that is not focus on our immediate needs and we should
>  improve the situation but I wanted to share
>  with you this perspective.
> 
> 
> >
> > 2) Keeping the website documentation more up to date (again the
> pharo.org
> > website is very slick, and a great showcase, however often there are
> late
> > breaking changes which new users won’t know about unless they trace
> through
> > the news groups or subscribe to some blogs). If we could also focus
> on
> > keeping it simple but up to date - that might hel

Re: [Pharo-dev] Pharo7 and full block closures

[Clément Bera]

Hi Holger,

Nobody can guarantee any framework to be stable on Pharo alpha (Currently
Pharo 7) since deep changes can happen every day during alpha. So the
answer is yes, having any framework *not* working on the alpha version is
to be expected.

The instructions to use the Sista runtime are detailed here
 in
the How to get/build a Sista image and VM section and are very clear in
step 1 about using Pharo 6 (the stable Pharo version). They also work with
Pharo 6.1.

Sista will work for the release of Pharo 7 as it did for Pharo 6 and 6.1
but it won't work every day during the alpha of Pharo 7 and no sane
framework developer can guarantee that. Sista does not work currently in
Pharo 7 due to some changes breaking the full block closures, I am going to
fix it but even then in the incoming months there is a high chance that
another change in Pharo 7 breaks it again, so I would never recommend to
use it with the alpha.


On Fri, Sep 22, 2017 at 5:08 AM, Holger Freyther  wrote:

> Hi,
>
> I kind of missed the open alpha of "Scorch" and to make up for it I tried
> to follow the instructions on Pharo7 but I do crash the VM. Is that to be
> expected?
>
> "Add special selector for trap instruction"
> Smalltalk specialObjectsArray at: 60 put: #trapTripped.
> "Disable hot spot detection (to load the Scorch code)"
> Smalltalk specialObjectsArray at: 59 put: nil.
> "Recompile the fetch mourner primitive which has strange side-effect with
> alternate bytecode set and closures"
> WeakArray class compile: 'primitiveFetchMourner ^ nil' classified: #patch.
> "Enable FullBlockClosure and alternate bytecode set"
> CompilationContext bytecodeBackend: OpalEncoderForSistaV1.
> CompilationContext usesFullBlockClosure: true.
> OpalCompiler recompileAll.
>
>
> If I only execute the last three lines it is crashing as well but at a
> different point in the VM?
>
>
> (lldb) bt
> * thread #1: tid = 0x5636d2, 0xa165e496 libsystem_kernel.dylib`__pthread_kill
> + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
>   * frame #0: 0xa165e496 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0xa1744c63 libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0xa15bea34 libsystem_c.dylib`abort + 141
> frame #3: 0x00087128 Pharo`error + 55
> frame #4: 0x000132e6 Pharo`lookupMethodInClass + 601
> frame #5: 0x85c1 Pharo`interpret + 25756
> frame #6: 0x00011b9a Pharo`enterSmalltalkExecutiveImplementation + 135
> frame #7: 0x23ab Pharo`interpret + 646
> frame #8: 0x000889d9 Pharo`-[sqSqueakMainApplication runSqueak] + 476
> frame #9: 0x95ac4a1b Foundation`__NSFirePerformWithOrder + 419
> frame #10: 0x942811fe CoreFoundation`__CFRUNLOOP_IS_
> CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30
> frame #11: 0x94281157 CoreFoundation`__CFRunLoopDoObservers + 391
> frame #12: 0x942614a2 CoreFoundation`__CFRunLoopRun + 1058
> frame #13: 0x94260e1a CoreFoundation`CFRunLoopRunSpecific + 506
> frame #14: 0x94260c0b CoreFoundation`CFRunLoopRunInMode + 123
> frame #15: 0x93954396 HIToolbox`RunCurrentEventLoopInMode + 268
> frame #16: 0x93954057 HIToolbox`ReceiveNextEventCommon + 195
> frame #17: 0x93953f7b 
> HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter
> + 83
> frame #18: 0x91f86015 AppKit`_DPSNextEvent + 1227
> frame #19: 0x926e AppKit`-[NSApplication(NSEvent)
> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1742
> frame #20: 0x926eb4e5 AppKit`-[NSApplication(NSEvent)
> nextEventMatchingMask:untilDate:inMode:dequeue:] + 132
> frame #21: 0x91f7acb6 AppKit`-[NSApplication run] + 943
> frame #22: 0x91f47d1e AppKit`NSApplicationMain + 1368
> frame #23: 0xa152f395 libdyld.dylib`start + 1
> (lldb) p (int) activeProcess()
> (int) $0 = 115378352
> (lldb) p/x (int) activeProcess()
> (int) $1 = 0x06e088b0
> (lldb) p (void) printAllStacks()
> Process  0x6e088b0 priority 40
> 0xbfffc124 I FileReference(AbstractFileReference)>writeStreamDo:
> 0x9a303d8: a(n) FileReference
> 0xbfffc144 M [] in OmBlockFileStore(OmFileStore)>flushEntryBuffer
> 0x9a2c3c0: a(n) OmBlockFileStore
> 0xbfffc164 M [] in Semaphore>critical: 0x6e08898: a(n) Semaphore
> 0xbfffc184 M BlockClosure>ensure: 0x6f2d1f8: a(n) BlockClosure
> 0xbfffc1a4 M Semaphore>critical: 0x6e08898: a(n) Semaphore
> 0xbfffc1c8 I OmBlockFileStore(OmFileStore)>critical: 0x9a2c3c0: a(n)
> OmBlockFileStore
> 0xbfffc1e4 M OmBlockFileStore(OmFileStore)>flushEntryBuffer 0x9a2c3c0:
> a(n) OmBlockFileStore
> 0xbfffc204 I OmDeferrer>sendMessage 0x9a303f8: a(n) OmDeferrer
> 0xbfffc21c M [] in OmDeferrer>flush 0x9a303f8: a(n) OmDeferrer
> 0xbfffc23c M BlockClosure>ensure: 0x6f2d0e0: a(n) BlockClosure
> 0xbfffc260 I OmDeferrer>flush 0x9a303f8: a(n) OmDeferrer
> 0xbfffc280 I [] in OmDeferrer>runMessageProcess 0x9a303f8: a(n) OmDeferrer
> 0xbfffc2a0 I [] in BlockClosure>newProcess 0x6e12fb8: a(n) BlockClosure
>
> processes

Re: [Pharo-dev] Pharo7 and full block closures

[Clément Bera]

I totally agree with you on this.

For a while I had a CI job that was trying to execute Sista on the latest
version of Pharo and VM, and sent me a mail when something had gone wrong.
I disabled it when there was problems on the CI, I will make it work again.
This way I am notified and I can update the Sista code as Pharo 7 is
developed. That helps a lot.

On the Pharo CI the time to run tests matters hence I will try to find
another solution to test full block and the other bytecode set. I did not
do that because I hope I can change Pharo to use full block by default
soon, but since they're broken...

Regards



On Fri, Sep 22, 2017 at 10:58 AM, Holger Freyther 
wrote:

>
> > On 22. Sep 2017, at 13:33, Clément Bera  wrote:
>
>
> Hi Clement,
>
>
> > Sista will work for the release of Pharo 7 as it did for Pharo 6 and 6.1
> but it won't work every day during the alpha of Pharo 7 and no sane
> framework developer can guarantee that. Sista does not work currently in
> Pharo 7 due to some changes breaking the full block closures, I am going to
> fix it but even then in the incoming months there is a high chance that
> another change in Pharo 7 breaks it again, so I would never recommend to
> use it with the alpha.
>
>
> thank you for your response. I didn't expect it to work (after all you
> label it "Alpha" and I ran into issues already) but my intention for the
> mail was a bit different. Let me try to briefly explain my motivation. In
> my experience:
>
> (1) Software not executed stops to work (or never "worked")
> (2) The earlier breakage is detected the less expensive it is to fix.
>
> My assumption is that Opal is part of Pharo and that we look at a
> regression of the Opal compiler and/or how it interacts with the rest of
> the image. As it might be easier to understand/fix it now than later I
> brought it up. From my point of view I wonder if we want to add ~50s to the
> CI process to execute:
>
> CompilationContext bytecodeBackend: OpalEncoderForSistaV1.
> CompilationContext usesFullBlockClosure: true.
> OpalCompiler recompileAll.
>
>
> Is there any value in doing so?
>
>
> cheers
>
> holger
>
>
> PS
>
> (2) The intuitive explanation is that the cost of analysis is a lot lower
> the earlier the problem is detected. There are fewer potential changes that
> lead to the breakage and the people involved will remember what/why they
> did reducing the cost of fixing. Ideally things are found to be broken and
> fixed before integration.
>
> Maybe an analogy is old-school aviation navigation.. the earlier a mistake
> is found in navigation the closer to the original course...
>

Re: [Pharo-dev] Pharo7 and full block closures

[Clément Bera]

Well we need to use them but the integration process is difficult to deal
with: we need to change the bootstrap to cross compile to the other
bytecode set. I need to have some time to focus on it amd I need the help
of someone understanding the bootstrap like Guille

On Sep 22, 2017 18:31, "Stephane Ducasse"  wrote:

> Hi clement
>
> let us know how we can help because he all want the new closures.
>
> Stef
>
> On Fri, Sep 22, 2017 at 11:11 AM, Clément Bera 
> wrote:
> > I totally agree with you on this.
> >
> > For a while I had a CI job that was trying to execute Sista on the latest
> > version of Pharo and VM, and sent me a mail when something had gone
> wrong. I
> > disabled it when there was problems on the CI, I will make it work again.
> > This way I am notified and I can update the Sista code as Pharo 7 is
> > developed. That helps a lot.
> >
> > On the Pharo CI the time to run tests matters hence I will try to find
> > another solution to test full block and the other bytecode set. I did
> not do
> > that because I hope I can change Pharo to use full block by default soon,
> > but since they're broken...
> >
> > Regards
> >
> >
> >
> > On Fri, Sep 22, 2017 at 10:58 AM, Holger Freyther 
> > wrote:
> >>
> >>
> >> > On 22. Sep 2017, at 13:33, Clément Bera 
> wrote:
> >>
> >>
> >> Hi Clement,
> >>
> >>
> >> > Sista will work for the release of Pharo 7 as it did for Pharo 6 and
> 6.1
> >> > but it won't work every day during the alpha of Pharo 7 and no sane
> >> > framework developer can guarantee that. Sista does not work currently
> in
> >> > Pharo 7 due to some changes breaking the full block closures, I am
> going to
> >> > fix it but even then in the incoming months there is a high chance
> that
> >> > another change in Pharo 7 breaks it again, so I would never recommend
> to use
> >> > it with the alpha.
> >>
> >>
> >> thank you for your response. I didn't expect it to work (after all you
> >> label it "Alpha" and I ran into issues already) but my intention for the
> >> mail was a bit different. Let me try to briefly explain my motivation.
> In my
> >> experience:
> >>
> >> (1) Software not executed stops to work (or never "worked")
> >> (2) The earlier breakage is detected the less expensive it is to fix.
> >>
> >> My assumption is that Opal is part of Pharo and that we look at a
> >> regression of the Opal compiler and/or how it interacts with the rest
> of the
> >> image. As it might be easier to understand/fix it now than later I
> brought
> >> it up. From my point of view I wonder if we want to add ~50s to the CI
> >> process to execute:
> >>
> >> CompilationContext bytecodeBackend: OpalEncoderForSistaV1.
> >> CompilationContext usesFullBlockClosure: true.
> >> OpalCompiler recompileAll.
> >>
> >>
> >> Is there any value in doing so?
> >>
> >>
> >> cheers
> >>
> >> holger
> >>
> >>
> >> PS
> >>
> >> (2) The intuitive explanation is that the cost of analysis is a lot
> lower
> >> the earlier the problem is detected. There are fewer potential changes
> that
> >> lead to the breakage and the people involved will remember what/why
> they did
> >> reducing the cost of fixing. Ideally things are found to be broken and
> fixed
> >> before integration.
> >>
> >> Maybe an analogy is old-school aviation navigation.. the earlier a
> mistake
> >> is found in navigation the closer to the original course...
> >
> >
>
>

Re: [Pharo-dev] Pharo7 and full block closures

[Clément Bera]

Yeah we may need to do that as a transition to move them to production.
Let's do that the first week of october Pablo

On Sep 22, 2017 18:59, "teso...@gmail.com"  wrote:

Hi Clément,
   If you need help with the CI, I can also help you. We can create it as a
another parallel stage in the PR validation. So once it is stable we can
detect asap changes that break it.

Cheers,


On 22 Sep 2017 18:45, "Clément Bera"  wrote:

Well we need to use them but the integration process is difficult to deal
with: we need to change the bootstrap to cross compile to the other
bytecode set. I need to have some time to focus on it amd I need the help
of someone understanding the bootstrap like Guille

On Sep 22, 2017 18:31, "Stephane Ducasse"  wrote:

> Hi clement
>
> let us know how we can help because he all want the new closures.
>
> Stef
>
> On Fri, Sep 22, 2017 at 11:11 AM, Clément Bera 
> wrote:
> > I totally agree with you on this.
> >
> > For a while I had a CI job that was trying to execute Sista on the latest
> > version of Pharo and VM, and sent me a mail when something had gone
> wrong. I
> > disabled it when there was problems on the CI, I will make it work again.
> > This way I am notified and I can update the Sista code as Pharo 7 is
> > developed. That helps a lot.
> >
> > On the Pharo CI the time to run tests matters hence I will try to find
> > another solution to test full block and the other bytecode set. I did
> not do
> > that because I hope I can change Pharo to use full block by default soon,
> > but since they're broken...
> >
> > Regards
> >
> >
> >
> > On Fri, Sep 22, 2017 at 10:58 AM, Holger Freyther 
> > wrote:
> >>
> >>
> >> > On 22. Sep 2017, at 13:33, Clément Bera 
> wrote:
> >>
> >>
> >> Hi Clement,
> >>
> >>
> >> > Sista will work for the release of Pharo 7 as it did for Pharo 6 and
> 6.1
> >> > but it won't work every day during the alpha of Pharo 7 and no sane
> >> > framework developer can guarantee that. Sista does not work currently
> in
> >> > Pharo 7 due to some changes breaking the full block closures, I am
> going to
> >> > fix it but even then in the incoming months there is a high chance
> that
> >> > another change in Pharo 7 breaks it again, so I would never recommend
> to use
> >> > it with the alpha.
> >>
> >>
> >> thank you for your response. I didn't expect it to work (after all you
> >> label it "Alpha" and I ran into issues already) but my intention for the
> >> mail was a bit different. Let me try to briefly explain my motivation.
> In my
> >> experience:
> >>
> >> (1) Software not executed stops to work (or never "worked")
> >> (2) The earlier breakage is detected the less expensive it is to fix.
> >>
> >> My assumption is that Opal is part of Pharo and that we look at a
> >> regression of the Opal compiler and/or how it interacts with the rest
> of the
> >> image. As it might be easier to understand/fix it now than later I
> brought
> >> it up. From my point of view I wonder if we want to add ~50s to the CI
> >> process to execute:
> >>
> >> CompilationContext bytecodeBackend: OpalEncoderForSistaV1.
> >> CompilationContext usesFullBlockClosure: true.
> >> OpalCompiler recompileAll.
> >>
> >>
> >> Is there any value in doing so?
> >>
> >>
> >> cheers
> >>
> >> holger
> >>
> >>
> >> PS
> >>
> >> (2) The intuitive explanation is that the cost of analysis is a lot
> lower
> >> the earlier the problem is detected. There are fewer potential changes
> that
> >> lead to the breakage and the people involved will remember what/why
> they did
> >> reducing the cost of fixing. Ideally things are found to be broken and
> fixed
> >> before integration.
> >>
> >> Maybe an analogy is old-school aviation navigation.. the earlier a
> mistake
> >> is found in navigation the closer to the original course...
> >
> >
>
>

[Pharo-dev] OSWindow in Pharo 6.1 stable

[Clément Bera]

Hi Ronie, Hi all,

I am trying to use OSWindow/SDL2 in Pharo 6,1 stable, I successfully opened
the window and I can draw on it with Athens (with minor changes compared to
Pharo 4). However, the user events (keyboard, mouse, etc.) are not working.
It seems some constants are not initialized but I am not sure what is the
right way to initialize them.

If I am correct Ronie you said you had a script to run to make OSWindow
work in the latest Pharo version. Can you give it to me so I can use it ? I
just need keyboard events for my use case.

Btw for some reason in the one-click version of Pharo 32 bits on Mac there
is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to conflicts (the
VM use randomly one lib or the other). I randomly chose one that I use and
deleted the other one, do you have advises on which one I should prefer ?
Maybe the events are working only with the other one ?

Thanks

Re: [Pharo-dev] OSWindow in Pharo 6.1 stable

[Clément Bera]

Hi Ronie... I need help again.

In fact I am still not able to work with SDL2 events in Mac with Pharo 6
nor 7.

In Pharo 6 and Pharo 7, 32 and 64 bits I need to run this code:
'FFIExternalStructure
allSubclassesDo: #rebuildFieldAccessors'. In all cases I can open the
window and draw on it with Cairo, but the problems lie with the events. In
all cases when I start with libSDL2 and libSDL2-2.0.0 I have warnings in
the command line (2 libs detected, a random one will be used each time), so
I usually use only libSDL2 which seems to work better.

In 32 bits (both Pharo 6 and 7) if I delete the libSDL2-2.0.0 lib and
use libSDL2
only, I have mouse and window events but only **some** keyboard events. I
have around 2/3 of the keyboard events, which makes the app very hard to
use (Each time you press a key, you need to check if it worked or press it
again if not). I don't know for sure if I have all the other events or only
2/3 of them too as there are so many.

In 64 bits, (both Pharo 6 and 7), whatever combination of lib I attempt I
don't have *any* event (keyboard, mouse or window).

I have a working version in Pharo 4 where I have all the events. It's the
same 32 bits lib so it has to come from something else (VM changes or image
changes).

Any idea on what I have to fix to move from 2/3 of the events to all the
events ?
What is the right way to get a working SDL2 window with Pharo 6/7 ?

Thanks

On Thu, Sep 28, 2017 at 4:25 PM, Clément Béra 
wrote:

> Ok I used the other lib (libSDL2 instead of libSDL2-2.0.0) and it worked.
>
> 2017-09-28 16:07 GMT+02:00 Clément Béra :
>
>>
>>
>> 2017-09-28 15:33 GMT+02:00 Ronie Salgado :
>>
>>> Hi Clement,
>>>
>>> The last time I checked, the 64 bits Mac VM version is eating the
>>> keyboard events, but not the mouse and other events. I guess that for the
>>> minheadless this is not required. The 32 bits version of Mac works by
>>> running the folowing script:
>>>
>>> FFIExternalStructure allSubclassesDo: #rebuildFieldAccessors
>>>
>>> I think that Pavel fixed this for Pharo 7.
>>>
>>
>> Ok.
>>
>> I had done that.
>>
>> But...
>>
>> I don't have any keyboard events. I have mouse and window events. I am
>> using Mac 32 bits.
>>
>> Ok...
>>
>> It seems that the keyboard events arrive as touch events...
>>
>> I will try to make that work. We'll see.
>>
>> Thanks
>>
>>
>>
>>>
>>>
>>> Btw for some reason in the one-click version of Pharo 32 bits on Mac
>>>> there is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to
>>>> conflicts (the VM use randomly one lib or the other). I randomly chose one
>>>> that I use and deleted the other one, do you have advises on which one I
>>>> should prefer ? Maybe the events are working only with the other one ?
>>>>
>>> They should be a symlink. The correct one is the libSDL2-2.0.
>>>
>>> Best regards,
>>> Ronie
>>>
>>> 2017-09-28 15:02 GMT+02:00 Clément Bera :
>>>
>>>> Hi Ronie, Hi all,
>>>>
>>>> I am trying to use OSWindow/SDL2 in Pharo 6,1 stable, I successfully
>>>> opened the window and I can draw on it with Athens (with minor changes
>>>> compared to Pharo 4). However, the user events (keyboard, mouse, etc.) are
>>>> not working. It seems some constants are not initialized but I am not sure
>>>> what is the right way to initialize them.
>>>>
>>>> If I am correct Ronie you said you had a script to run to make OSWindow
>>>> work in the latest Pharo version. Can you give it to me so I can use it ? I
>>>> just need keyboard events for my use case.
>>>>
>>>> Btw for some reason in the one-click version of Pharo 32 bits on Mac
>>>> there is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to
>>>> conflicts (the VM use randomly one lib or the other). I randomly chose one
>>>> that I use and deleted the other one, do you have advises on which one I
>>>> should prefer ? Maybe the events are working only with the other one ?
>>>>
>>>> Thanks
>>>>
>>>
>>>
>>
>

Re: [Pharo-dev] OSWindow in Pharo 6.1 stable

[Clément Bera]

On Fri, Sep 29, 2017 at 10:29 AM, Hilaire  wrote:

> Hi,
>
> IMHO, it will make Pharo much more robust if core libraries as sdl, cairo,
> etc will be shipped with each plateform dependent virtual machine and the
> image modified accordingly to use these core libraries.
>

That's how it is now but some of it is not working (Here SDL events and
there are 2 SDL2 libs by default).

I think we should still have a minimal image starting with a minimal UI
without using FFI/SDL/Cairo or whatever lib. Else when we start on a
platform where one of this thing is not properly supported yet (See the
problem on the raspberry pie with some Pharo alpha version) it is too hard
to understand what is going on.


>
> The delivery of Pharo application to end users is an issue because of
> these recuring problem.


Honestly I was trying to write a doc on how to deploy Pharo client app with
SDL2 and Cairo but I have only a version working in Pharo 4 on Mac and
Linux, while in theory I could have it working in Windows/Mac/Linux in the
latest Pharo.


> Hilaire
>
>
>
> Le 28/09/2017 à 15:02, Clément Bera a écrit :
>
>> Btw for some reason in the one-click version of Pharo 32 bits on Mac
>> there is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to
>> conflicts (the VM use randomly one lib or the other). I randomly chose one
>> that I use and deleted the other one, do you have advises on which one I
>> should prefer ? Maybe the events are working only with the other one ?
>>
>>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-dev] Sista alternate bytecodes + Java Bytecode ?

[Clément Bera]

Hi,

That question should be asked on vm-dev.

Just a detail, multibytecode set support is prior to the Sista
implementation, it was used for example in the context of Newspeak (Squeak
and Newspeak bytecodes supported together). Sista uses that feature, which
makes it look like new in the Pharo community since afaik no one used it
before in the context of Pharo.

Then yes it is feasible to have the VM process Java bytecode, but it's
humongous work. On the top my head, we would need to support typed
bytecodes for Numbers and exceptions at the bytecode level (which in itself
is month of work, imagine raising an exception from Java/ST and catch it
from the other runtime, with multiple ensure/try finally in between)

Note that supporting the Java bytecode is far from enough to be able to run
Java code (We also need core Java libraries support at least, including
exceptions/stack reification model that should be able to interact with
each other)

You can have a look at Smalltalk/X where the VM can run Java, C and
Smalltalk.

Regards


On Tue, Oct 3, 2017 at 1:57 PM, Ben Coman  wrote:

> Just wondering about an exotic idea, with Sista facilitating alternate
> bytecodes (btw, is that multiple bytecode sets within one Image?), how
> feasible would it be to have the VM process Java bytecode?
>
> cheers -ben
>

Re: [Pharo-dev] [Pharo 7.0-dev] Build #176: 20505-The-special-objects-array-needs-to-be-recreated-during-bootstrap

[Clément Bera]

Hi Guille,

For "First":
I looked into this problem with Pavel this morning. The special object
array being incorrectly created leads to problems when a large object
(bigger that growthHeadroom) is created, as it does not go through the
handleFailingBasicNew methods. Typically, Pavel could not load Seaside into
the minimal image because of that. The problem lies with the initialization
of error codes.

For "Second":
I don't mind what you do as long as it solves the problem of large
allocations on minimal images. In any case the problems lies with the error
code symbols, so that the code in basicNew:
ec == #'insufficient object memory' ifTrue:
[^self handleFailingBasicNew: sizeRequested].
takes the correct branch. Before Pavel's change, the condition was false
during bootstrap leading to large allocation crashing the VM, ec was equal
to 9 instead of #'insufficient object memory', since the error codes in the
special object array were incorrectly initialized somehow.

PS: Who is nobody ?

Cheers


On Tue, Oct 10, 2017 at 2:04 PM, Guillermo Polito  wrote:

> Hi Pavel,
>
> I don't like this change.
>
> First, there is no comment nor explanation why that is needed. This change
> is obscure, if we forget in a couple of months why that line of code is
> there we may
>  - delete it unintentionally
>  - or leave it forever and fear to clean it up because we do not
> understand it :(
>
> Second, It looks that recreating the special objects array there, like
> that, means that it was not correctly created from the beginning. We should
> instead create it correctly from the beginning.
>
> I think we should revert this change.
>
> On Tue, Oct 10, 2017 at 12:24 PM,  wrote:
>
>> There is a new Pharo build available!
>>
>> The status of the build #176 was: SUCCESS.
>>
>> The Pull Request #336 was integrated: "20505-The-special-objects-arr
>> ay-needs-to-be-recreated-during-bootstrap"
>> Pull request url: https://github.com/pharo-project/pharo/pull/336
>>
>> Issue Url: https://pharo.fogbugz.com/f/cases/20505
>> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p
>> ull%20request%20and%20branch%20Pipeline/job/development/176/
>>
>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>



-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Compiler Explorer (for the Compiler guys) #offtopic

[Clément Bera]

You can do that with the VMMaker package loaded. There is not all the UI,
but you can print the assembly code in the Transcript.

On Tue, Oct 17, 2017 at 10:03 PM, Esteban A. Maringolo  wrote:

> I'm sure we could do this with ease, because we already can see the
> bytecodes.
>
> https://godbolt.org/
>
> Regards!
>
> Esteban A. Maringolo
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] OSWindow in Pharo 6.1 stable

[Clément Bera]

Hi again,

I made many more attempts since those mails: I wrote this page
<https://github.com/clementbera/wizard-battle-arena> showing how to deploy
my game in native app at 50fps on Linux, Mac and Windows.

Currently I deploy with:
Ubuntu 64 bits: Pharo61-64 (Pharo61-32 also works with the right lib
installed)
Mac OS X 64 bits: Pharo5Alpha-32 (On Pharo61 the keyboard events do not
work correctly)
Windows 64 bits: Pharo61-32 (There are bugs with the SDL2 window, the top
bar is not displayed, but the game work. Reportedly it would work better
with Pharo61-64 but the default Pharo64 VM on Windows still does not
feature the JIT, once the default VM does, I will update).

My goal is to deploy on all platforms with Pharo61-64 (and later Pharo7-64).

I wrote this mail since maybe you are interested in knowing that with
Pharo5Alpha-32 and the set-up described on the page of my game the keyboard
events work fine on Mac, so it may be possible to write a fix for
Pharo61/Pharo7 based on that.

Best,




On Fri, Sep 29, 2017 at 8:56 PM, Stephane Ducasse 
wrote:

> Tx ronie!
>
>
> On Fri, Sep 29, 2017 at 1:42 PM, Ronie Salgado 
> wrote:
> > Hi Clément,
> >
> > I just checked on my machine and it is also not working. It seems to be
> a VM
> > bug. It will take me some time to debug it. I have some suspicious on
> > ioProcessEvents .
> >
> > Best regards,
> > Ronie
> >
> > 2017-09-29 10:39 GMT+02:00 Clément Bera :
> >>
> >>
> >>
> >> On Fri, Sep 29, 2017 at 10:29 AM, Hilaire  wrote:
> >>>
> >>> Hi,
> >>>
> >>> IMHO, it will make Pharo much more robust if core libraries as sdl,
> >>> cairo, etc will be shipped with each plateform dependent virtual
> machine and
> >>> the image modified accordingly to use these core libraries.
> >>
> >>
> >> That's how it is now but some of it is not working (Here SDL events and
> >> there are 2 SDL2 libs by default).
> >>
> >> I think we should still have a minimal image starting with a minimal UI
> >> without using FFI/SDL/Cairo or whatever lib. Else when we start on a
> >> platform where one of this thing is not properly supported yet (See the
> >> problem on the raspberry pie with some Pharo alpha version) it is too
> hard
> >> to understand what is going on.
> >>
> >>>
> >>>
> >>> The delivery of Pharo application to end users is an issue because of
> >>> these recuring problem.
> >>
> >>
> >> Honestly I was trying to write a doc on how to deploy Pharo client app
> >> with SDL2 and Cairo but I have only a version working in Pharo 4 on Mac
> and
> >> Linux, while in theory I could have it working in Windows/Mac/Linux in
> the
> >> latest Pharo.
> >>
> >>>
> >>> Hilaire
> >>>
> >>>
> >>>
> >>> Le 28/09/2017 à 15:02, Clément Bera a écrit :
> >>>>
> >>>> Btw for some reason in the one-click version of Pharo 32 bits on Mac
> >>>> there is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to
> conflicts
> >>>> (the VM use randomly one lib or the other). I randomly chose one that
> I use
> >>>> and deleted the other one, do you have advises on which one I should
> prefer
> >>>> ? Maybe the events are working only with the other one ?
> >>>>
> >>>
> >>> --
> >>> Dr. Geo
> >>> http://drgeo.eu
> >>>
> >>>
> >>>
> >>
> >
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Compiler Explorer (for the Compiler guys) #offtopic

[Clément Bera]

On Wed, Oct 18, 2017 at 1:42 PM, Mariano Martinez Peck <
marianop...@gmail.com> wrote:

>
>
> On Wed, Oct 18, 2017 at 3:36 AM, Tudor Girba  wrote:
>
>> Hi,
>>
>> This is already available since some time in the GTInspector. You can
>> just inspect a compiled method. You will get both the bytecode and the AST
>> (with source tracking, too). In fact, this was one of the original reasons
>> why GTInspector exists: I wanted to figure out how the AST is structured so
>> that I can write queries against it :).
>>
>
>
> Sure, we just miss machine code :)
>

Yeah the machine code is what matters.


> But...AFAIR to get the machine code of a method it needs VMMaker to be
> loaded
>

I was thinking of changing that, adding a primitive which answers a
CogMethod as a bytearray, but you still need to use external libs such as
gdb/lldb to disassemble your binary (which is possible but not working out
of the box everywhere and it does not make sense to include that as part of
the VM), and you still need something extracted from VMMaker to make sense
out of the CogMethod header and CogMethod map, which has a lot of
dependencies, so likely the whole VMMaker itself. And I'm not talking about
all the different CogMethod flavors.

With VMMaker loaded you can do it with in-image compilation but you will
have the machine code with only unlinked sends. With linked send it's more
difficult as you need to really simulate the whole runtime.

Overall there's no amazing solution. In the example shown it's easier as in
C++ the code is not modified while it runs and you've already have gdb/lldb
APIs to show what they show.



>
>
>
>
>
>>
>>
>> Cheers,
>> Doru
>>
>>
>> On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo 
>> wrote:
>>
>> I'm sure we could do this with ease, because we already can see the
>> bytecodes.
>>
>> https://godbolt.org/
>>
>> Regards!
>>
>> Esteban A. Maringolo
>>
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "The coherence of a trip is given by the clearness of the goal."
>>
>>
>>
>>
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>



-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Compiler Explorer (for the Compiler guys) #offtopic

[Clément Bera]

On Wed, Oct 18, 2017 at 3:27 PM, Jan Vrany  wrote:

> Hi,
>
> > I was thinking of changing that, adding a primitive which answers a
> > CogMethod as a bytearray, but you still need to use external libs
> > such as gdb/lldb to disassemble your binary
>
> I use udis86 [1] for that purpose. Tiny, clean & dead easy to use.
> x86 only, though.
>
> HTH. Jan
>
> [1]: http://udis86.sourceforge.net/


Tiny that's good.

I normally use the facilities provided by the processor simulators (but
that's not tiny).

Not sure the production environment should have those features anyway


>
>
> > (which is possible but not working out of the box everywhere and it
> > does not make sense to include that as part of the VM), and you still
> > need something extracted from VMMaker to make sense out of the
> > CogMethod header and CogMethod map, which has a lot of dependencies,
> > so likely the whole VMMaker itself. And I'm not talking about all the
> > different CogMethod flavors.
> >
> > With VMMaker loaded you can do it with in-image compilation but you
> > will have the machine code with only unlinked sends. With linked send
> > it's more difficult as you need to really simulate the whole runtime.
> >
> > Overall there's no amazing solution. In the example shown it's easier
> > as in C++ the code is not modified while it runs and you've already
> > have gdb/lldb APIs to show what they show.
> >
> >
> > >
> > >
> > >
> > > >
> > > >
> > > > Cheers,
> > > > Doru
> > > >
> > > >
> > > > > On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo  > > > > gmail.com> wrote:
> > > > >
> > > > > I'm sure we could do this with ease, because we already can see
> > > > > the bytecodes.
> > > > >
> > > > > https://godbolt.org/
> > > > >
> > > > > Regards!
> > > > >
> > > > > Esteban A. Maringolo
> > > > >
> > > >
> > > > --
> > > > www.tudorgirba.com
> > > > www.feenk.com
> > > >
> > > > "The coherence of a trip is given by the clearness of the goal."
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Mariano
> > > http://marianopeck.wordpress.com
> > >
> >
> >
> >
> > --
> > Clément Béra
> > Pharo consortium engineer
> > https://clementbera.wordpress.com/
> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

[Clément Bera]

Hi,

As you can see in the crash dump, this is always due to FreeType. If it's
only at start-up it means it's in the FreeType start-up code. You can try
to change some free type settings (like not using those fonts at all) or to
use more hard-core scripts such as:

#(FT2Handle FreeTypeCache FreeTypeSettings) do: [ :each | SessionManager
default unregisterClassNamed: each  ]


On Fri, Oct 20, 2017 at 5:50 PM, Peter Uhnák  wrote:

> I've experienced the same thing on Windows 10 yesterday, but normally I do
> not work in P7 so I didn't investigate much.
>
> On Fri, Oct 20, 2017 at 3:57 PM, Thomas Dupriez  saclay.fr> wrote:
>
>> Hello,
>>
>> I've had a few issues with Pharo 7 lately. After downloading pharo 7
>> images, doing some work in them and saving them, the images either
>> instantly crashe or freeze when I try to re-run them.
>> If that helps, I was working with and on the calypso browser.
>>
>> Attached are the crash dump files from some of these faulty images.
>>
>> vm version: 201708271955
>> image version: 6521
>> OS: Ubuntu 16.04 LTS
>>
>> Cheers,
>> Thomas
>>
>>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

[Clément Bera]

On Sat, Oct 21, 2017 at 6:23 PM, Peter Uhnák  wrote:

> #(FT2Handle FreeTypeCache FreeTypeSettings) do: [ :each | SessionManager
>> default unregisterClassNamed: each  ]
>>
>
> How am I supposed to launch the script if it crashes on startup? I've
> tried running from terminal but to no avail.
>
>
...

I was talking about future images.

If you want to save your already crashing image, the crash.dump says the VM
crashes in FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: .

So you need to interrupt that / change the behavior of one of the method
leading to this behavior.

What I would try:

- start the image on a VM without Freetype (maybe you will have an error
instead of a crash)

- open a new image, and check what you could return immediately instead of
executing one of the faulty method to start-up without a crash (For
example, if I replace the method body of
FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: by ^ self, does it
crash ? If yes, pick another method upper in the crashing stack of
crash.dump or return something else). Then, you can either:
* start the image on the VMSimulator, set a break point on the method
selector with the body you want to replace and change the runtime behavior
to return the value you want instead.
* open your crashing image with an hexadecimal editor, look for the
bytecode sequence of the method with the body you want to replace, replace
it with new bytecode to return the value you want. Save your image. Restart
it on the VM.

That kind of things.


Best,




> Thanks,
> Peter
>



-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Primitive Failed error trying openInExternalWindow

[Clément Bera]

Hi Eduardo,

Your FFIStructures are not initialised (I thought this was solved in latest
Pharo 7 ? Maybe not integrated yet). Run:

FFIExternalStructure allSubclassesDo: #rebuildFieldAccessors.

Then your code should work.

I wrote a simple game using Pharo/SDL2/Cairo and it works very well (50fps
without problems, responsiveness is really good, etc.), the ReadMe includes
how to run it on Ubuntu/Mac OS X/Windows, check here:

https://github.com/clementbera/wizard-battle-arena

Let me know if you have other questions.

On Sat, Oct 21, 2017 at 6:28 PM, Eduardo de Oliveira Padoan <
eduardo.pad...@gmail.com> wrote:

> Hi, greetings!
>
> I was trying out some examples from the Pharo By Example book on the
> latest development version of Pharo, and I wanted to create a stand-alone
> window for a simple game on Ubuntu. So I found out the openInExternalWindow
> method, the window appears but I get this error that I couldn't understand,
> and could not find any reference to it online. So I'm not sure if it's a
> bug.
>
> The simplest way I found to reproduce it was:
>
> 'Hello' asMorph openInExternalWindow.
>
> I'm using Pharo 7 on Ubuntu 17.10.
>
> A copy of the stack:
>
> ByteArray(Object)>>primitiveFailed:
> ByteArray(Object)>>primitiveFailed
> ByteArray>>integerAt:size:signed:
> ByteArray>>unsignedLongAt:
> SDL_KeyDownEvent>>windowID
> OSSDL2Driver>>convertEvent:
> [ event := self convertEvent: sdlEvent.
> event ifNotNil: [ eventQueue nextPut: event ] ] in
> OSSDL2Driver>>processEvent: in Block: [ event := self convertEvent:
> sdlEvent
> BlockClosure>>on:do:
> OSSDL2Driver>>processEvent:
> OSSDL2Driver>>eventLoopProcessWithoutPlugin
> [ self eventLoopProcessWithoutPlugin ] in OSSDL2Driver>>setupEventLoop in
> Block: [ self eventLoopProcessWithoutPlugin ]
> [ self value.
> Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self
> value
>
> But it seems incomplete. Any more information I can provide?
>
> Thank you.
>



-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

[Clément Bera]

Hi again,

I checked with Stef this morning. Starting the image on a VM without
Freetype solves the problem. Just open the VM, remove or rename the
Freetype dynamic libraries (FT2, Freetype, 3 libs in total), then start
your image.

That's unfortunate the hexadecimal editor solution is so much more fun :-)

Cheers

On Sat, Oct 21, 2017 at 9:30 PM, Stephane Ducasse 
wrote:

> Thanks thomas we should find the problem.
>
> Stef
>
> On Fri, Oct 20, 2017 at 3:57 PM, Thomas Dupriez
>  wrote:
> > Hello,
> >
> > I've had a few issues with Pharo 7 lately. After downloading pharo 7
> images,
> > doing some work in them and saving them, the images either instantly
> crashe
> > or freeze when I try to re-run them.
> > If that helps, I was working with and on the calypso browser.
> >
> > Attached are the crash dump files from some of these faulty images.
> >
> > vm version: 201708271955
> > image version: 6521
> > OS: Ubuntu 16.04 LTS
> >
> > Cheers,
> > Thomas
> >
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] feenk log

[Clément Bera]

Hi,

Good work,

In PolyMaths/SciSmalltalk vectors and matrix are already implemented
efficiently. I would recommend to share the same implementation. In the
next few years, I think we will improve the performance of those
vectors/matrix library using the processor vector instructions, and it
would be nice if we have to improve one but not two libraries of vectors
and matrix (This is the polie way of saying I am going to improve one
library and the others will have to do it themselves).

Regards,

On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:

> Hi,
>
> Our team is working on a couple of projects that are relevant for the core
> of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several
> people, and Stef in particular, to make the progress on these projects more
> transparent. To this end, we will start two streams of signals:
> - fine grained info bits on out Twitter account (several times a week):
> https://twitter.com/feenkcom
> - a less often but regular (probably every 2 weeks) activity log message
> sent to this mailing list
>
> Please let us know if you see an issue with this.
>
> In the meantime, let’s start.
>
> Bloc:
> - Over the past couple of weeks Alex worked on transformations and
> measurements in the core system. It turns out that there was room for quite
> a number of performance optimizations and for making the system more
> debuggable.
> - At the low level, this involved adding matrix and vector support.
> https://twitter.com/feenkcom/status/923123870537863168
> https://twitter.com/feenkcom/status/916300180848349185
> - At a higher level, it implies keeping track of measurements
> https://twitter.com/AliakseiSyrel/status/915203525931622400
> - And of transformations:
> https://twitter.com/feenkcom/status/919603739656417281
> https://twitter.com/feenkcom/status/917116164484096001
> - The BlScalableElement is now working properly
>
> GT Examples:
> - The current repository with unary-based examples is at:
> https://github.com/feenkcom/gtoolkit-examples
> - We now have a runner in the inspector that allows us to both see the
> source code and run and play with the resulting object:
> https://twitter.com/feenkcom/status/923210686204989442
> - Andrei made the “after” behavior to work with unary examples.
>
> Cheers,
> The feenk team
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Being happy is a matter of choice."
>
>
>
>
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Preferences location on linux and windows?

[Clément Bera]

On Sun, Oct 29, 2017 at 9:27 PM, Stephane Ducasse 
wrote:

> tx!
> I would have never guessed it.
>

That's normal, nobody would have guessed it because it's not a guess.
Instead of guessing, one can just use any of the Pharo search engine which
allow to find anything in Pharo in a couple seconds.

Using GTSpotter, typing 'Preferences' immediately shows as the first result
the general and version preference folders, with location and contents.

Using the class search feature of Nautilus [1], entering 'Preferences'
shows only a couple classes, including StartupPreferencesLoader, which by
name explicitly says this is responsible for loading the startup
preferences. Looking at its comment we see:

...
Print the result of "StartupPreferencesLoader preferencesGeneralFolder"
which holds the startup scripts common to all versions of Pharo.
Print the result of "StartupPreferencesLoader preferencesVersionFolder"
which holds the startup scripts specific to the version of the current
image.
...

As Nicolas said, the address of the folder is different based on the OS
version, OS settings, OS updates, the user rights of the person who started
Pharo... That's why in StartupPreferencesLoader the way to find the path is
documented and not the path itself.

 [1] Open Nautilus, right click in the left column and select 'Find
class...' in the menu

>
>
> On Sun, Oct 29, 2017 at 9:23 PM, Cyril Ferlicot D.
>  wrote:
> > Le 29/10/2017 à 21:19, Stephane Ducasse a écrit :
> >> Hi guys
> >>
> >> I'm about to release a new booklet and I need the following information.
> >> What are the preferences  location on linux and windows?
> >>
> >> TX
> >>
> >
> > Hi,
> >
> > For windows:
> >
> > C:\Users\Name_Of_Your_User\AppData\Roaming
> >
> > You can also describe it by:
> >
> > %userprofile%\AppData\Roaming
> >
> > This location contains a "Pharo" folder.
> >
> >
> >
> > --
> > Cyril Ferlicot
> > https://ferlicot.fr
> >
> > http://www.synectique.eu
> > 2 rue Jacques Prévert 01,
> > 59650 Villeneuve d'ascq France
> >
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] UFFI/Sista/Scorch

[Clément Bera]

Hi Ben,

This is the work that Ronie did. You have lower level bytecodes in the
SistaV1 bytecode set which can be used for parameters marshalling. Ronie
has a prototype where the marshalling of FFI calls is generated image-side
once and reused for all calls.

For now, if Scorch does not recognise the primitive (and it does not
recognise FFI calls), the send is just marked as non inlineable. Hence this
works but is not really optimised.

Cheers


On Tue, Nov 14, 2017 at 11:48 AM, Esteban Lorenzano 
wrote:

>
>
> On 13 Nov 2017, at 22:30, Ben Coman  wrote:
>
>
> Just curious regarding Slide 16 [1] which indicates UFFI sequence is...
> 1. Generate bytecodes for marshalling
> 2. Re-send method invocation
>
> Do the bytecodes get cached so that (1.) is only down once?
>
> What impact is Sista/Scorch expected to have on UFFI?
> Considering for example that the commonly used method...
> ffiCall: fnSpec
> ^ (self ffiCalloutIn: thisContext sender)
> convention: self ffiCallingConvention;
> function: fnSpec module: self ffiLibraryName
> ...has several message sends.
>
> [1] https://www.slideshare.net/esug/unifiedffi-a-common-
> language-for-the-outside-world
>
>
> we still do not sit to solve the problem, but we have a strategy: SISTA
> bytecode set contains bytecodes to invoque primitives which means possible
> to do a primitive call inside a method (it does not needs to be an
> independent method). This way, the optimiser can work also on methods that
> ends on primitives.
> As far as I know, adapting to SISTA will not be very complicated. But of
> course, there will be some work needed.
>
>
> btw, Slide 2 gave me a nice chuckle to start the day.  Stabilization is a
> difficult/boring task with highly visible issues which Esteban bears the
> brunt of dealing with, along with accompanying pressures.  I'd like to take
> this random opportunity to thank Esteban for his continuing efforts, and
> also previous Consortium engineers (Igor) and those supporting them.  We
> wouldn't be where we are today without such a focal point.
>
>
> thanks :)
>
> Esteban
>
>
> cheers -ben
>
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

[Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

[Clément Bera]

Hi All,

It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that the
instVarAt: / instVarAt:put: primitive is not doing what it says it does.
When I look at Object>>#instVarAt: I see:

"[...]Answer a fixed variable in an object. The numbering of the variables
corresponds to the named instance variables, followed by the indexed
instance
variables. Fail if the index is not an Integer or is not the index of a
fixed variable[...]"

Now in Pharo 7 when one does:

#(iv1) instVarAt: 1, one gets #iv1.

So the comment is wrong.

The reason for this is that instVarAt: / instVarAt:put: should be primitive
73/74, while they are in Pharo 173/174 (primitive slotAt:/slotAt:put:). The
slot primitive access pointer slots of objects, whichever inst var or
variable fields. A good example would be:

| t |
t := #temp.
[ t ] instVarAt: 4, one gets #temp

So I have two solutions for this problem:
1) We change the instVarAt: / instVarAt:put: primitives comments to match
the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: /
instVarAt:put: means in factslotAt: / slotAt:put: .
2) We change the instVarAt: / instVarAt:put: primitives to primitive 73 and
74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we ask
everyone to fix their code relying on instVarAt: / instVarAt:put: acting as
slotAt: / slotAt:put:

What do you think ?

Best,


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

[Clément Bera]

On Wed, Nov 22, 2017 at 3:34 PM, Denis Kudriashov 
wrote:

> Hi.
>
> Just to notice: it is here long time (I checked Pharo 1 and current
> Squeak).
>
> Probably some Spur changes to integrate in the image then.


>
> 2017-11-22 14:35 GMT+01:00 Clément Bera :
>
>> Hi All,
>>
>> It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that
>> the instVarAt: / instVarAt:put: primitive is not doing what it says it
>> does. When I look at Object>>#instVarAt: I see:
>>
>> "[...]Answer a fixed variable in an object. The numbering of the variables
>> corresponds to the named instance variables, followed by the indexed
>> instance
>> variables. Fail if the index is not an Integer or is not the index of a
>> fixed variable[...]"
>>
>> Now in Pharo 7 when one does:
>>
>> #(iv1) instVarAt: 1, one gets #iv1.
>>
>> So the comment is wrong.
>>
>> The reason for this is that instVarAt: / instVarAt:put: should be
>> primitive 73/74, while they are in Pharo 173/174 (primitive
>> slotAt:/slotAt:put:). The slot primitive access pointer slots of objects,
>> whichever inst var or variable fields. A good example would be:
>>
>> | t |
>> t := #temp.
>> [ t ] instVarAt: 4, one gets #temp
>>
>> So I have two solutions for this problem:
>> 1) We change the instVarAt: / instVarAt:put: primitives comments to match
>> the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: /
>> instVarAt:put: means in factslotAt: / slotAt:put: .
>> 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73
>> and 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we
>> ask everyone to fix their code relying on instVarAt: / instVarAt:put:
>> acting as slotAt: / slotAt:put:
>>
>
> I prefer explicit behaviour. These methods have clear intention in names:
> inst var accessing. It should be error when given index is out of #instSize
> range.
>
> For new methods I would not use slot based naming because slots in Pharo
> is already something more then just object fields.
> Maybe #fieldAt:, #fieldAt:put: would be good? And also #fieldSize for
> consistency
>

fieldSize is not a primitive in this case,

Object>>#fieldSize
 ^ self class instSize + self basicSize


>
>>
>> What do you think ?
>>
>> Best,
>>
>>
>> --
>> Clément Béra
>> Pharo consortium engineer
>> https://clementbera.wordpress.com/
>> Bâtiment B 40, avenue Halley 59650
>> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve
>> d
>> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>
>> 'Ascq
>> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>
>>
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

[Clément Bera]

On Wed, Nov 22, 2017 at 9:05 PM, Stephane Ducasse 
wrote:

> Hi clement
>
> you should discuss with marcus. I had the impression that he was
> thinking that slot should disappear.
>

Then let's use fieldAt:/fieldAt:put:


>
> Stef
>
> On Wed, Nov 22, 2017 at 2:35 PM, Clément Bera 
> wrote:
> > Hi All,
> >
> > It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that
> the
> > instVarAt: / instVarAt:put: primitive is not doing what it says it does.
> > When I look at Object>>#instVarAt: I see:
> >
> > "[...]Answer a fixed variable in an object. The numbering of the
> variables
> > corresponds to the named instance variables, followed by the indexed
> > instance
> > variables. Fail if the index is not an Integer or is not the index of a
> > fixed variable[...]"
> >
> > Now in Pharo 7 when one does:
> >
> > #(iv1) instVarAt: 1, one gets #iv1.
> >
> > So the comment is wrong.
> >
> > The reason for this is that instVarAt: / instVarAt:put: should be
> primitive
> > 73/74, while they are in Pharo 173/174 (primitive slotAt:/slotAt:put:).
> The
> > slot primitive access pointer slots of objects, whichever inst var or
> > variable fields. A good example would be:
> >
> > | t |
> > t := #temp.
> > [ t ] instVarAt: 4, one gets #temp
> >
> > So I have two solutions for this problem:
> > 1) We change the instVarAt: / instVarAt:put: primitives comments to match
> > the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: /
> instVarAt:put:
> > means in factslotAt: / slotAt:put: .
> > 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73
> and
> > 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we ask
> > everyone to fix their code relying on instVarAt: / instVarAt:put: acting
> as
> > slotAt: / slotAt:put:
> >
> > What do you think ?
> >
> > Best,
> >
> >
> > --
> > Clément Béra
> > Pharo consortium engineer
> > https://clementbera.wordpress.com/
> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] OpalCompiler evaluate speed

[Clément Bera]

Hi Nicolas.

Just some comments:

Another thing you can try is to remove the allocation of Opal's IR. It
seems people use the IR only through the IRBuilder, so the API can be kept
but it can generate directly bytecode instead of IR then bytecode. Removing
those allocations would speed things up. It means merging IRFix /
IRTranslator / IRBytecodeGenerator somehow and have the IRBuilder API
directly call the new resulting merged class.

Another thing is that when Opal became the default compiler, I evaluated
the speed and saw it was slower, but when loading large projects it seemed
loading time was dominated by Monticello / source reading / source loading
and the compilation time was overall not that significant (< 20% of time).
I don't know if this is still the case with GIT. I have problems currently
when editing some large methods (it seems in the IDE the method is compiled
at each keystroke...) and when doing OpalCompiler recompileAll (which I do
often since I edit bytecode sets) but else the performance of Opal seems to
be OK. Evaluate performance may be relevant in some cases but I've never
found such cases outside of the IDE in production.

Best !

Clement


On Thu, Nov 23, 2017 at 9:41 PM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

>
>
> 2017-11-22 0:31 GMT+01:00 Ben Coman :
>
>>
>>
>> On 22 November 2017 at 05:49, Nicolas Cellier <
>> nicolas.cellier.aka.n...@gmail.com> wrote:
>>
>>>
>>>
>>> 2017-11-21 14:19 GMT+01:00 Nicolas Cellier <
>>> nicolas.cellier.aka.n...@gmail.com>:
>>>
 I have an ArbitraryPrecisionFloatTests doing an exhaustive test for
 printing and reevaluating all positve half precision float.

 That's about 2^15 or approximately 32k loop which evaluate snippets like

 (ArbitraryPrecisionFloat readFrom: '1.123' readStream numBits: 10)

 The test was naively written with Compiler evaluate: and was using the
 legacy Compiler.

 If I rewrite self class compiler evaluate: the test times out.
 Let's see what increase is necessary:

 [ ArbitraryPrecisionFloatTest new testPrintAndEvaluate  ] timeToRun.
 -> 3s with legacy Compiler
 -> 14s with OpalCompiler

 It's not unexpected that intermediate representation (IR) reification
 has a cost, but here the 4.5x is a bit too much...
 This test did account for 1/4 of total test duration already (3s out of
 12s).
 With Opal, the total test duration doubles... (14s out of 23s)

 So let's analyze the hot spot with:

 MessageTally  spyOn: [ ArbitraryPrecisionFloatTest new
 testPrintAndEvaluate  ].

 (I didn't use AndreasSystemProfiler becuase outputs seems a bit
 garbbled, no matter since the primitives do not account that much, a
 MessageTally will do the job)

 I first see a hot spot which does not seem that necessary:

   ||24.6% {3447ms} RBMethodNode(RBProgramNode)>>formattedCode

 From the comments I understand that AST-based stuff requires a pattern
 (DoIt) and an explicit return (^), but this expensive formatting seems too
 much for just evaluating. i think that we should change that.

 Then comes:

   ||20.7% {2902ms} RBMethodNode>>generate:

 which is split in two halves, ATS->IR and IR->bytecode

   ||  |9.3% {1299ms} RBMethodNode>>generateIR

   ||  |  |11.4% {1596ms} IRMethod>>generate:

 But then I see this cost a 2nd time which also leave room for progress:

   ||10.9% {1529ms} RBMethodNode>>generateIR

   ||  |12.9% {1814ms} IRMethod>>generate:

 The first is in RBMethodNode>>generateWithSource, the second in
 OpalCompiler>>compile

 Last comes the parse time (sourceCode -> AST)

   |  13.2% {1858ms} OpalCompiler>>parse

 Along with semantic analysis

   |  6.0% {837ms} OpalCompiler>>doSemanticAnalysis

 ---

 For comparison, the legacy Compiler decomposes into:

   ||61.5% {2223ms} Parser>>parse:class:category:n
 oPattern:context:notifying:ifFail:

 which more or less covers parse time + semantic analysis time.
 That means that Opal does a fair work for this stage.

 Then, the direct AST->byteCode phase is:

  |  16.9% {609ms} MethodNode>>generate

 IR costs almost a 5x on this phase, but we know it's the price to pay
 for the additional features that it potentially offers. If only we would do
 it once...

 And that's all for the legacy one...

 --

 This little exercize shows that a 2x acceleration of OpalCompiler
 evaluate seems achievable:
 - simplify the uselessely expensive formatted code
 - generate bytecodes once, not twice

>>

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

[Clément Bera]

On Fri, Nov 24, 2017 at 12:00 AM, Stephane Ducasse 
wrote:

> Did you talk with marcus?
>

I don't understand the connection between slots and this problem with
primitives.

>
>
> On Wed, Nov 22, 2017 at 10:12 PM, Clément Bera 
> wrote:
> >
> >
> > On Wed, Nov 22, 2017 at 9:05 PM, Stephane Ducasse <
> stepharo.s...@gmail.com>
> > wrote:
> >>
> >> Hi clement
> >>
> >> you should discuss with marcus. I had the impression that he was
> >> thinking that slot should disappear.
> >
> >
> > Then let's use fieldAt:/fieldAt:put:
> >
> >>
> >>
> >> Stef
> >>
> >> On Wed, Nov 22, 2017 at 2:35 PM, Clément Bera 
> >> wrote:
> >> > Hi All,
> >> >
> >> > It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that
> >> > the
> >> > instVarAt: / instVarAt:put: primitive is not doing what it says it
> does.
> >> > When I look at Object>>#instVarAt: I see:
> >> >
> >> > "[...]Answer a fixed variable in an object. The numbering of the
> >> > variables
> >> > corresponds to the named instance variables, followed by the indexed
> >> > instance
> >> > variables. Fail if the index is not an Integer or is not the index of
> a
> >> > fixed variable[...]"
> >> >
> >> > Now in Pharo 7 when one does:
> >> >
> >> > #(iv1) instVarAt: 1, one gets #iv1.
> >> >
> >> > So the comment is wrong.
> >> >
> >> > The reason for this is that instVarAt: / instVarAt:put: should be
> >> > primitive
> >> > 73/74, while they are in Pharo 173/174 (primitive
> slotAt:/slotAt:put:).
> >> > The
> >> > slot primitive access pointer slots of objects, whichever inst var or
> >> > variable fields. A good example would be:
> >> >
> >> > | t |
> >> > t := #temp.
> >> > [ t ] instVarAt: 4, one gets #temp
> >> >
> >> > So I have two solutions for this problem:
> >> > 1) We change the instVarAt: / instVarAt:put: primitives comments to
> >> > match
> >> > the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: /
> >> > instVarAt:put:
> >> > means in factslotAt: / slotAt:put: .
> >> > 2) We change the instVarAt: / instVarAt:put: primitives to primitive
> 73
> >> > and
> >> > 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we
> ask
> >> > everyone to fix their code relying on instVarAt: / instVarAt:put:
> acting
> >> > as
> >> > slotAt: / slotAt:put:
> >> >
> >> > What do you think ?
> >> >
> >> > Best,
> >> >
> >> >
> >> > --
> >> > Clément Béra
> >> > Pharo consortium engineer
> >> > https://clementbera.wordpress.com/
> >> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
> >>
> >
> >
> >
> > --
> > Clément Béra
> > Pharo consortium engineer
> > https://clementbera.wordpress.com/
> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

[Clément Bera]

In the VM primitiveSlotAt: / at:Put: mean access to any field (pointer or
non pointer, sorry for the confusion Marcus earlier on) of an object. The
primitive in the image can be named fieldAt:/fieldAt:put: if it makes more
sense for Pharo.

#[0] slotAt: 1 => 0
#(#a) slotAt: 1 => #a
0@2 slotAt: 1 => 0
With Pharo 6 blocks:
| t | t := #tmp. {[ t ] slotAt: 3 . [ t ] slotAt: 4} => { 0 "numArgs". #tmp
}

Right now you can do that with instVarAt: on the contrary to what
instVarAt: comment states, and this is wrong.

On Fri, Nov 24, 2017 at 10:32 AM, Marcus Denker 
wrote:

>
>
> On 24 Nov 2017, at 00:21, Clément Bera  wrote:
>
>
>
> On Fri, Nov 24, 2017 at 12:00 AM, Stephane Ducasse  com> wrote:
>
>> Did you talk with marcus?
>>
>
> I don't understand the connection between slots and this problem with
> primitives.
>
>>
>>
> There is no connection, just the same name.
>
> For Slots aka First Class Instance variables:
>
> I sometimes think that Slot for the first class instance variables might
> not be a good name, but then,
> the only alternative would be “instance variable”, but that is not that
> nice either, as these Slots include
> virtual variables (that are computed) or variables that are combine stored
> in a hidden base slot (e.g.
> used for BooleanSlot or PropertySlot).
>
> So for now I will keep the Slot term…
>
>
> Marcus
>



-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

[Clément Bera]

Hi,

So you're advocating for solution 1:
>
> 1) We change the instVarAt: / instVarAt:put: primitives comments in Pharo
> to match
>  the slotAt: / slotAt:put: primitives behavior


I marked in bold the changes in the Pharo comment (so the comment now
reflects the actual behavior):

instVarAt: index
"Primitive. Answer a fixed variable in an object. The numbering of the
variables
corresponds to the named instance variables, followed by the indexed
instance
variables. Fail if the index is not an Integer or is not the index of a
fixed variable
 *or indexed variable*. Essential. See Object documentation
whatIsAPrimitive."


self primitiveFailed

I'll make a patch later on.

On Tue, Nov 28, 2017 at 2:55 AM, David T. Lewis  wrote:

> On Mon, Nov 27, 2017 at 12:11:13PM -0800, Eliot Miranda wrote:
> > Hi Cl??ment,
> >
> > On Wed, Nov 22, 2017 at 5:35 AM, Cl??ment Bera 
> > wrote:
> >
> > > Hi All,
> > >
> > > It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that
> the
> > > instVarAt: / instVarAt:put: primitive is not doing what it says it
> does.
> > > When I look at Object>>#instVarAt: I see:
> > >
> > > "[...]Answer a fixed variable in an object. The numbering of the
> variables
> > > corresponds to the named instance variables, followed by the indexed
> > > instance
> > > variables. Fail if the index is not an Integer or is not the index of a
> > > fixed variable[...]"
> > >
> > > Now in Pharo 7 when one does:
> > >
> > > #(iv1) instVarAt: 1, one gets #iv1.
> > >
> >
> > But the failure code should indeed answer #iv1.
> >
> >
> > > So the comment is wrong.
> > >
> > > The reason for this is that instVarAt: / instVarAt:put: should be
> > > primitive 73/74, while they are in Pharo 173/174 (primitive
> > > slotAt:/slotAt:put:).
> > >
> >
> > Why do you say "should"?  The 173/174 primitives work well and avoid
> > unnecessary primitive failures (which is why they're there).
> >
> >
> > > The slot primitive access pointer slots of objects, whichever inst var
> or
> > > variable fields. A good example would be:
> > >
> > > | t |
> > > t := #temp.
> > > [ t ] instVarAt: 4, one gets #temp
> > >
> > > So I have two solutions for this problem:
> > > 1) We change the instVarAt: / instVarAt:put: primitives comments to
> match
> > > the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: /
> > > instVarAt:put: means in factslotAt: / slotAt:put: .
> > >
> >
> > This is the performant solution, because...
> >
> >
> > > 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73
> > > and 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and
> we
> > > ask everyone to fix their code relying on instVarAt: / instVarAt:put:
> > > acting as slotAt: / slotAt:put:
> > >
> >
> > Early in Squeak Spur testing Chris Muller noticed a slow down in his code
> > He was accessing an Array using instVarAt:, which was failing because he
> > was using it to access an indexed field in an Array.  Now in Spur the VM
> > must scan the object graph of a primitive's  receiver and arguments to
> some
> > depth on primitive failure to follow forwarders.  Because a) at that time
> > the VM computed a depth > 0 for instVarAt:[put:] it scanned the whole
> array
> > on each access, and b) the Array was large, this meant that the failures
> > were very expensive.  So I added the slot primitives, since the old 73/74
> > primitive pair were only used in the instVarAt:[put:] methods that
> accessed
> > indexable slots on failure.  So the new 173/174 pair subsumed the 73/74
> > pair.
> >
> > I eventually added an accessorDepth: pragma rot specify the accessor
> depth
> > manually when the automatically computed depth is too deep.  It is for
> > at:[put:] because the String version of the at: 60 primitive appears to
> > access the innards of non-immediate Characters (it doesn't do this in
> Spur,
> > but the depth inferencer isn't clever enough to notice).  So primitiveAt
> > looks like:
> >
> > primitiveAt
> > 
> > self commonAt: false
> >
> > So we could go back to using 73/74 for instVarAt:[put:] provided that
> their
> > accessorDepth ends up being 0, which likely means they will require the
> > pragma.  But I think the simplest thing is to keep using 173/174.  Here's
> > the Squeak code:
> >
> > Object>>instVarAt: index
> > "Primitive. Answer a fixed variable in an object. The numbering of the
> > variables
> > corresponds to the named instance variables, followed by the indexed
> > instance
> > variables. Fail if the index is not an Integer or is not the index of a
> > fixed or
> > indexed variable. Essential. See Object documentation whatIsAPrimitive."
> >
> > 
> > self primitiveFailed
> >
> > Object>>instVarAt: index put: anObject
> > "Primitive. Store a value into a fixed variable in an object. The
> numbering
> > of the
> > variables corresponds to the named instance variables, followed by the
> > indexed
> > instance variables. Fail if the index is not an Integer or is not the
> index
> > of a fixe

Re: [Pharo-dev] Alternative bytecode sets demo request

[Clément Bera]

To use the alternate bytecode set in Pharo 7 use:

  CompilationContext bytecodeBackend: EncoderForSistaV1.
  OpalCompiler recompileAll.
based on:

https://clementbera.wordpress.com/2017/07/19/sista-open-alpha-release/

Currently in Pharo SqueakV3PlusClosure and SistaV1 are installed in
CompiledCode. You need to install another set if you want to use it using
#installSecondaryBytecodeSet: or similar methods.
  CompiledMethod installSecondaryBytecodeSet: EncoderForMyBytecodeSet.

Then you can just use the first code snippet to use it:

  CompilationContext bytecodeBackend: EncoderForMyBytecodeSet.
  OpalCompiler recompileAll.

On Mon, Dec 4, 2017 at 3:48 AM, Eliot Miranda 
wrote:

> Hi Ben,
>
> On Sun, Dec 3, 2017 at 6:08 PM, Ben Coman  wrote:
>
>> I'm shooting in the dark here since its a bit hard to grasp...
>> a. The implications of support alternative bytecode sets
>> * Do the alternative bytecode sets run in parallel to normal Pharo
>> bytecodes?
>>
>
> Yes.  There's a single bit in the header of a compiled method that selects
> between two bytecode sets.  In current Squeak and Pharoi VMs, if the bit is
> unset then the normal bytecode set is used, and if the nit is set, the
> Sista bytecode set is used.
>
> * Can the bytecode sets be loaded adhoc/dynamically into an Image?
>>or only compiled into the VM?
>>
>
> Only compiled into the VM.
>
>
>> b. How to implement/work with alternative bytecodes
>>
>
> In Squeak there are class-side accessors in CompiledCode.  See
> CompiledCode class>>installSecondaryBytecodeSet:.  Note that the support
> isn't quite finished yet.  I hope to have the Sista vytecde set ready for
> the next release of Squeak.  Clément is providing it in Pharo.
>
> In Squeak the BytecodeEncoder hierarchy implements the necessary support
> for multiple bytecode sets.  Via CompiledCode 
> class>>installSecondaryBytecodeSet:
> the system is informed as to which bytecode set to use.  This must match
> the bytecode set(s) that are in the VM.  Classes beneath BytecodeEncoder,
> in particular EncoderForV3PlusClosures and EncoderForSistaV1 (in package
> BytecodeSets at http://source.squeak.org/VMMaker) encode the current and
> the Sista sets respectively.
>
> For (a.) I guess an exciting opportunity is facilitating an Ethereum
>> virtual machine
>> running as a Process inside a Pharo image, managed by tools written in
>> Pharo.
>> Other languages are already getting in a party which would be good for
>> Pharo to join.
>> In such a revolutionary domain I expect people are more willing to
>> experiment
>> with alternative systems like Pharo, and I bet Pharo could excel in that
>> domain.
>> * https://github.com/ethereum/go-ethereum/blob/master/core/vm/opcodes.go
>> * https://medium.com/@jeff.ethereum/optimising-the-ethereum-
>> virtual-machine-58457e61ca15
>> * https://github.com/pirapira/awesome-ethereum-virtual-machi
>> ne#evm-implementations
>>
>>
>> To help (b.), would it be feasible to blog a mini-demo showing how to
>> install/use alternative bytecodes? maybe for something like this simple RPN
>> calculator substitute for "arith.c"...
>> * https://github.com/philipaconrad/mini-vm/tree/master/examples/arith
>> * https://github.com/philipaconrad/mini-vm/blob/master/
>> examples/arith/arith.c
>>
>
> That's not how this will work.  Essentially it is transparent.  Once the
> bytecode set support is installed in the compiler one simply compiles
> Smalltalk (or anything else that produces parse trees that can be output to
> compiled methods via the BytecodeEncoder hierarchy) and the method will be
> output in the currently selected bytecode set.  So it's not something one
> plays around with, unless that is, one is developing the bytecode set in
> the Vm sim,letter.
>
>
>>
>> (a calculator demo could be an interesting adjunct to Sven's calculator
>> tutorial...)
>> https://medium.com/concerning-pharo/rediscovering-the-ux-of-
>> the-legendary-hp-35-scientific-pocket-calculator-d1d497ece999
>>
>>
>> cheers -ben
>>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>



-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] [Vm-dev] Garbage Collection (was Re: Discussing the roadmap)

[Clément Bera]

hum...

The mail is very long so I did not read all of it.

Here are some ideas/things to say on the tip of my head:
- Changing an object to a forwarding object is non atomic (we need to
maintain at least stack invariant)
- To decrease the pauses in full GC I have 2 plans:
-- incremental marking (split the mark pause in multiple small pauses): Not
implemented right now.
-- selective compaction (compacts only part of the heap instead of all the
heap and sweeps the rest, similar to G1, but uses forwarders instead of
lots of card marking metadata): I implemented SpurSweeper which only sweeps
but works very well.
- Currently the marking phase removes all forwarders and I would like
incremental marking to maintain the same invariant (forwarders are always
white).
- In general, Concurrent marking and sweeping have been implemented
everywhere, but no concurrent compaction. For compaction you can make it
selective (compact only part of the heap and the part which needs it the
most) like I suggest and like in G1, which decreases considerably
compaction pause time. Work on concurrent compaction is state of the art
and not in production everywhere, see for example
Shenandoah Garbage Collector

*A. Shipilev*
Pause-Less GC for Improving Java Responsiveness


*C. Gracie*
And I will watch at talk on this topic tomorrow for the Android GC.
- Some runtime, especially now with small servers being rent, are running
on single core machines. So we need the low-pause GC to work incrementally
aside from concurrently. So step 1 incremental GC. Step 2 concurrent
marking and sweeping with low-pause for scavenge/compaction.

No more time right now.

On Sun, Dec 3, 2017 at 6:33 AM, Ben Coman  wrote:

>
> Hi Eliot, Clement,
>
> On 7 July 2017 at 00:41, Eliot Miranda  wrote:
> >
> > > - Better support for large heaps (GC tuning API, incremental GC).
> > > Pharo 64 bit is now able to manage large heap. However better
> > > performance can be proposed by offering better settings for the
> > > different GC zone.
> >
> > The most important thing here is the incremental GC.  Spur has a
> generation
> > scavenger that collects garbage in newly created objects (new space),
> > and a mark-compact collector that collects and compacts garbage in old
> space.
> >
> > Right now on my 2.3GHz MacMini doing normal development, the generation
> > scavenger causes pauses of 1ms or less, and the mark-compact collector
> > than causes pauses of around 200ms.  Both account for about 0.75% of
> > entire execution time (1.5% total), so the scavenger is invoked
> frequently
> > and the pauses that it creates are not noticeable.  But the occasional
> > pauses created by the mark-compact collector /are/ noticeable,
> > especially in games and music.
> >
> > The idea for the incremental collector is to implement a mark-sweep or
> > mark-sweep-compact collector for old space that works incrementally,
> > doing a little bit of work on each invocation, probably immediately
> after a scavenge.
> > It is intended to avoid the long pauses caused by the non-incremental
> > mark-compact collector and make the system more suitable for games,
> music, etc.
>
> Reading http://www.mirandabanda.org/cogblog/2013/09/13/lazy-
> become-and-a-partial-read-barrier/
>   "An alternative implementation, oft-used in Lisp systems, is to add a
>   read barrier to all object access, and mark objects as forwarders.
>   This can be used to implement a >>>lazy copying garbage collection
>   where objects are copied from one semi-space to another in parallel to
> the
>   main program (the “mutator”).  To become, or move an object one replaces
> the
>   object’s header or first field with a forwarding pointer to the desired
> target
>   or copy in a new location, marking the “corpse” as forwarded.  The
> program
>   checks the forwarded flag on each access.  If there is hardware support,
>   as in a Lisp machine, this can work well.  But without hardware support,
>   and like the object table representation, it has costs, slowing down
>   program execution due to the scattering of forwarding checks and
>   forwarding pointer follows throughout program execution."
>
> I'm curious... Given we now have forwarders with Spur, are we
> already sufficiently paying the cost of forwarding checks that a lazy
> copying
> garbage collector might be a feasible form of incremental garbage
> collection?
>
> I presume "parallel to the main program" means garbage collection occuring
> in a separate thread to the main vm thread, potentially resulting in
> very low main program pause times for garbage collection.
>
> I found this a useful summary of the terminology...
> * https://www.dynatrace.com/resources/ebooks/javabook/
> reduce-garbage-collection-pause-time/
> and I'm curious how our planned Incremental CG fits those categories.
>
> That article got me contemplating our p

Re: [Pharo-dev] Simple game framework

[Clément Bera]

See those ReadMe:

https://github.com/clementbera/wizard-battle-arena

https://github.com/clementbera/SpiderInvasion

Audio has always been a problem to me. I successfully run audio files with
the open AL binding, but I failed to do so cross-platform. Already
key-bindings coherent cross platform is difficult.

Cheers


On Mon, Dec 25, 2017 at 6:58 PM, Hilaire  wrote:

> You may have different kind of games; for example in 2D games, it could be
> fixed frame, side scrolling, up scrolling, isometric, etc. To get it
> started easily, it could come with graphic and audio banks.
>
> I really don't have much idea how such a general system should be
> designed. Only wrote once a commercial decades ago on ARM code.
>
> Will look a the bloc tutorial for game[1]
>
> [1] https://github.com/pharo-graphics/Tutorials/
>
>
> Le 25/12/2017 à 15:57, Stephane Ducasse a écrit :
>
>> B. Build an environment in Pharo to develop simple games, targeted for
>>> kids.
>>> There are some teenagers in my school likely to get interested on such
>>> courses. If it could result in standalone games build thanks to wish 4.,
>>> so
>>> good.
>>>
>> I'm interested into that this is why I proposed to "laura"
>> maximilliano to work on such framework.
>> Now I never got the time to do a pass over it and to release what I
>> learned.
>> - direction
>> - handling on moves.
>> - I created a grid data structure but this is the least interesting
>> part.
>>
>> If you want we can discuss what I learned.
>> Also students in Prague are building games on top of Bloc.
>>
>>
>>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Simple game framework

[Clément Bera]

On Thu, Dec 28, 2017 at 4:39 PM, Hilaire  wrote:

> What is the reason using Cairo over SDSL? Is not SDL just enought?


My understanding is that SDL provides the surface to draw on as part of the
window, but not a 2D vector graphic engine on top. You've got only draw
Line/Rect/pixel functions in SDL. To render a svg/png/jpeg that you want
for games on the SDL surface, the normal way is to use a third party
library such as Cairo.

For 3D I believe people use SDL combined with open GL or direct3D instead
of Cairo but I don't know the details.

For events (keyboard, mouse, joypad) I use SDL event management and it
works differently on each OS. I wrote in the readMe the different set-ups
to make it work on each OS. On Windows and Linux I can use the latest
Pharo. On Mac I use old Pharo 5 images.

I guess it's possible to use SDL for audio, but it seems there is no code
relative to audio in the SDL binding and in OSWindow in Pharo. That's why I
did not go that way. I tried multiple things but I successfully run audio
code in Pharo only with the openAL binding and .wav file (and even in this
case, I had to install external librairies in Mac OS...).

Whichever if Cairo stays around or not does not really matter, normally one
uses Cairo through Athens or Sparta, abstraction layers on top of 2D
graphic engines. I've worked with other 2D engines and the API are always
almost the same, so I have no doubt that if Cairo support is dropped we can
re-bind Athens/Sparta with another 2D engine (such as engines used by web
browsers).


>
> Hilaire
>
>
> Le 25/12/2017 à 19:32, Clément Bera a écrit :
>
>>
>> https://github.com/clementbera/wizard-battle-arena
>>
>> https://github.com/clementbera/SpiderInvasion
>>
>> Audio has always been a problem to me. I successfully run audio files
>> with the open AL binding, but I failed to do so cross-platform. Already
>> key-bindings coherent cross platform is difficult.
>>
>>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Calling primitiveFailed

[Clément Bera]

Hi Norbert,

Not really.

First we distinguish two cases:
- essential primitives : provides features that cannot be implemented in
Smalltalk (SmallInteger>>#+ for instance, requires to use the cpu addition)
- optimisation primitives : optional, they just improve performance

Optimisation primitives are optional and hence the fall-back code should be
the Smalltalk implementation of the primitive.

For essential primitives, the fall-back code is what is called when the
primitive fails. If we look at SmallInteger>>#+, it can fail because one
operand is not a SmallInteger, so the fall-back code use other code to
perform the addition (LargeInteger, Integer code, etc.). In other cases,
such as #at:put:, an error is raised when the primitive fails depending on
why the primitive failed (bounds check, non integer index, etc.). The
primitive is retried in case of number non integer (Try #(1) at: 1.0 put:
$x).

Some essential primitives should not fail in any circumstances and they
can't really be simulated. Good examples is #== primitive or
#basicIdentityHash, they should not fail. If it fails it means likely
something is wrong in the VM or in the kernel, in which case the
primitiveFail error is sent. PrimitiveFail error announces that a primitive
has failed and there is no appropriate Smalltalk code to run.

So no, most primitives should not call primitiveFail, you cannot assume
that.

On Sat, Jan 6, 2018 at 1:38 PM, Norbert Hartl  wrote:

> Looking through primitive methods I can see two cases. Most methods seem
> to call
>
> self primitiveFailed
>
> at the end of the method. But some as
>
> Object>>#at:put:
>
> do not. Can I assume that all primitive methods should call
> primitiveFailed at the end?
>
> Norbert
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] (Morph>>#asDraggableMorph) isPrimitive

[Clément Bera]

On Sat, Jan 6, 2018 at 8:07 PM, Eliot Miranda 
wrote:

> Hi Denis, Hi Norbert,
>
> On Sat, Jan 6, 2018 at 6:30 AM, Denis Kudriashov 
> wrote:
>
>> Hi.
>>
>> I guess "quick" methods are compiled as special primitives. For example
>> accessors are primitives too:
>>
>>
>> (Point >> #x) isPrimitive
>>
>>
>>  There is another method #isRealPrimitive which checks for explicit
>> primitive call.
>>
>
> That's right.  The scheme is as follows:
>
> Numbered primitives used to be 9 bits fields and primitive numbers 1
> through 255 were for conventional primitives, and primitive numbers 256
> through 512 were for quick primitives, such that 256 through 263 pushed
> specific constants and 264 through 512 pushed the inst vars, 263 pushing
> inst var 0, 264 pushing inst var 1, etc.  Here's the relevant section of
> the VM's primitive table:
>
> "Quick Push Const Methods"
> (256 nil) "primitivePushSelf"
> (257 nil) "primitivePushTrue"
> (258 nil) "primitivePushFalse"
> (259 nil) "primitivePushNil"
> (260 nil) "primitivePushMinusOne"
> (261 nil) "primitivePushZero"
> (262 nil) "primitivePushOne"
> (263 nil) "primitivePushTwo"
>
> "Quick Push Inst Var Methods"
> (264 519 nil) "primitiveLoadInstVar"
>
> Now we have 16 bits of primitive index.  The scheme up to 32767 is the
> same; 1 through 32767 are available for conventional primitives, with 256
> through 512 reserved for quick primitives.  Numbers 32768 through 65535 are
> reserved for use "inline primitives".  We divide the 32k values from 32767
> on up into four 8k groups.  Sista has the first 8k.  Lowcode has the second
> 8k, and the remaining two groups of 8k are unassigned, reserved for future
> use.
>
>
> Now that SistaV1 and Spur support up to 64k inst vars one could argue that
> we should extend the range of numbers available to quick primitives.  But
> in the JIT there's no difference between the code generated for a quick
> primitive and the code generated for a conventional
> pshInstVar:/pushConstant:, methodReturnTop.  IQuicjk primitive serve to
> improve performance only in the interpreter.  So given that we have no
> classes defining more than 210 inst vars (in my image) I don't think its a
> pressing need :-)
>
>
I think classes with more than 255 inst var will always be uncommon so we
don't need to improve the interpreter performance for those cases. In the
JIT getters are optimised anyway.


>
>> 2018-01-06 13:24 GMT+01:00 Norbert Hartl :
>>
>>> Can anyone explain why
>>>
>>> (Morph>>#asDraggableMorph) isPrimitive.
>>>
>>> returns true?
>>>
>>> Norbert
>>>
>>
> _,,,^..^,,,_
> best, Eliot
>



-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

[Clément Bera]

I would suspect a bug in primitive 105 on byte objects (it was changed
recently in the VM), called by copyFrom: 1 to: readCount. The bug would
likely by due to specific alignment in readCount or something like that.
(Assuming you're in 32 bits since the 4 bytes are corrupted).

When I get better I can have a look (I am currently quite sick).

On Thu, Jan 18, 2018 at 4:51 PM, Thierry Goubier 
wrote:

> Hi Cyril,
>
> try with the last vms available at:
>
> https://bintray.com/opensmalltalk/vm/cog/
>
> For example, the last Ubuntu 64bits vm is at:
>
> https://bintray.com/opensmalltalk/vm/cog/201801170946#files
>
> Regards,
>
> Thierry
>
> 2018-01-18 16:42 GMT+01:00 Cyrille Delaunay :
>
>> Hi everyone,
>>
>> I just added a new bug entry for an issue we are experimenting since some
>> times:
>>
>> https://pharo.fogbugz.com/f/cases/20982/Random-corrupted-dat
>> a-when-copying-from-very-large-byte-array
>>
>> Here is the description:
>>
>>
>> *History:*
>>
>> This issue has been spotted after experimenting strange behavior with
>> seaside upload.
>> After uploading a big file from a web browser, the modeled file generated
>> within pharo image begins with 4 unexpected bytes.
>> This issue occurs randomly: sometimes the first 4 bytes are right.
>> Sometimes the first 4 bytes are wrong.
>> This issue only occurs with Pharo 6.
>> This issue occurs for all platforms (Mac, Ubuntu, Windows)
>>
>> *Steps to reproduce:*
>>
>> I have been able to set up a small scenario that highlight the issue.
>>
>> Download Pharo 6.1 on my Mac (Sierra 10.12.6): https://pharo.org/we
>> b/download
>> Then, iterate over this process till spotting the issue:
>>
>> => start the pharo image
>> => execute this piece of code in a playground
>>
>> 1:
>> 2:
>> 3:
>> 4:
>> 5:
>> 6:
>>
>> ZnServer startDefaultOn: 1701.ZnServer default maximumEntitySize: 80* 1024 * 
>> 1024.'/Users/cdelaunay/myzip.zip' asFileReference writeStreamDo: [ :out |out 
>> binary; nextPutAll: #[80 75 3 4 10 0 0 0 0 0 125 83 67 73 0 0 0 0 0 
>> 0].18202065 timesRepeat: [ out nextPut: 0 ]].
>>
>> => Open a web browser page on: http://localhost:1701/form-test-3
>> => Upload the file zip file previously generated ('myzip.zip').
>> => If the web page displays: "contents=0a00
>> ..." (or anything
>> unexpected), THIS IS THE ISSUE !
>> => If the web page displays: "contents=504b03040a00
>> ..", the upload
>> worked fine. You can close the image (without saving)
>>
>>
>>
>> *Debugging:*
>>
>>
>>
>> Bob Arning has been able to reproduce the issue with my scenario.
>> He dived into the code involved during this process, till reaching some
>> "basic" methods where he saw the issue occuring.
>>
>> Here are the conclusion till there:
>> => A corruption occurs while reading an input stream with method ZnUtils
>> class>>readUpToEnd:limit:
>> The first 4 bytes may be altered randomely.
>> => The first 4 bytes are initially correctly written to an outputStream.
>>
>> But, the first 4 bytes of this outputStream gets altered (corrupted),
>> sometimes when the inner byte array grows OR when performing the
>> final "outputStream contents"
>> => Here is a piece of code that reproduce the issue (still randomely.
>> stopping an restarting the image may change the behavior)
>>
>> 1:
>> 2:
>> 3:
>> 4:
>> 5:
>> 6:
>> 7:
>> 8:
>> 9:
>> 10:
>> 11:
>> 12:
>> 13:
>> 14:
>> 15:
>> 16:
>> 17:
>> 18:
>> 19:
>> 20:
>>
>> test4"self test4"| species bufferSize buffer totalRead outputStream 
>> answer inputStream ba byte1 |ba := ByteArray new: 18202085.  
>>   ba atAllPut: 99.1 to: 20 do: [  :i | ba at: i put: (#[80 75 3 4 10 
>> 7 7 7 7 7 125 83 67 73 7 7 7 7 7 7] at: i) ].inputStream := ba 
>> readStream.bufferSize := 16384.species := ByteArray.
>> buffer := species new: bufferSize.
>> totalRead := 0.
>> outputStream := nil.
>> [ inputStream atEnd ] whileFalse: [ | readCount |
>> readCount := inputStream readInto: buffer startingAt: 1 count: 
>> bufferSize.
>> totalRead = 0 ifTrue: [
>> byte1 := buffer first.
>> ].
>> totalRead := totalRead + readCount.
>>
>> outputStream ifNil: [
>> inputStream atEnd
>> ifTrue: [ ^ buffer copyFrom: 1 to: readCount ]
>> ifFalse: [ outputStream := (species new: bufferSize) 
>> writeStream ] ].
>> outputStream next: readCount putAll: buffer startingAt: 1.
>> byte1 = outputStream contents first ifFalse: [ self halt ].
>> ].
>> answer := outputStream ifNil: [ species new ] ifNotNil: [ outputStream 
>> contents ].
>> byte1 = answer first ifFalse: [ self halt ].^answer
>>
>>
>>
>> *suspicions*
>>
>> This issue appeared with Pharo 6.
>>
>> Some people suggested that it could be a vm issue, and to try my little
>> scenario with the last available vm.
>>
>> I am not sure where to find the la

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

[Clément Bera]

Does not seem to be related to prim 105.

I am confused. Has the size of the array an impact at all ? It seems the
problem shows since the first copy of 16k elements.

I can't really reproduce the bug - it happened once but I cannot do it
again. Does the bug happen with the StackVM/PharoS VM you can find here the
32 bits versions : http://files.pharo.org/vm/pharoS-spur32/ ? The
StackVM/PharoS VM is the VM without the JIT, it may be since the bug is
unreliable that it happens only in jitted code, so trying that out may be
worth it.


On Thu, Jan 18, 2018 at 7:12 PM, Clément Bera 
wrote:

> I would suspect a bug in primitive 105 on byte objects (it was changed
> recently in the VM), called by copyFrom: 1 to: readCount. The bug would
> likely by due to specific alignment in readCount or something like that.
> (Assuming you're in 32 bits since the 4 bytes are corrupted).
>
> When I get better I can have a look (I am currently quite sick).
>
> On Thu, Jan 18, 2018 at 4:51 PM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>> Hi Cyril,
>>
>> try with the last vms available at:
>>
>> https://bintray.com/opensmalltalk/vm/cog/
>>
>> For example, the last Ubuntu 64bits vm is at:
>>
>> https://bintray.com/opensmalltalk/vm/cog/201801170946#files
>>
>> Regards,
>>
>> Thierry
>>
>> 2018-01-18 16:42 GMT+01:00 Cyrille Delaunay :
>>
>>> Hi everyone,
>>>
>>> I just added a new bug entry for an issue we are experimenting since
>>> some times:
>>>
>>> https://pharo.fogbugz.com/f/cases/20982/Random-corrupted-dat
>>> a-when-copying-from-very-large-byte-array
>>>
>>> Here is the description:
>>>
>>>
>>> *History:*
>>>
>>> This issue has been spotted after experimenting strange behavior with
>>> seaside upload.
>>> After uploading a big file from a web browser, the modeled file
>>> generated within pharo image begins with 4 unexpected bytes.
>>> This issue occurs randomly: sometimes the first 4 bytes are right.
>>> Sometimes the first 4 bytes are wrong.
>>> This issue only occurs with Pharo 6.
>>> This issue occurs for all platforms (Mac, Ubuntu, Windows)
>>>
>>> *Steps to reproduce:*
>>>
>>> I have been able to set up a small scenario that highlight the issue.
>>>
>>> Download Pharo 6.1 on my Mac (Sierra 10.12.6): https://pharo.org/we
>>> b/download
>>> Then, iterate over this process till spotting the issue:
>>>
>>> => start the pharo image
>>> => execute this piece of code in a playground
>>>
>>> 1:
>>> 2:
>>> 3:
>>> 4:
>>> 5:
>>> 6:
>>>
>>> ZnServer startDefaultOn: 1701.ZnServer default maximumEntitySize: 80* 1024 
>>> * 1024.'/Users/cdelaunay/myzip.zip' asFileReference writeStreamDo: [ :out 
>>> |out binary; nextPutAll: #[80 75 3 4 10 0 0 0 0 0 125 83 67 73 0 0 0 0 0 
>>> 0].18202065 timesRepeat: [ out nextPut: 0 ]].
>>>
>>> => Open a web browser page on: http://localhost:1701/form-test-3
>>> => Upload the file zip file previously generated ('myzip.zip').
>>> => If the web page displays: "contents=0a00
>>> <https://pharo.kilnhg.com/Search?search=0a00>..." (or anything
>>> unexpected), THIS IS THE ISSUE !
>>> => If the web page displays: "contents=504b03040a00
>>> <https://pharo.kilnhg.com/Search?search=504b03040a00>..", the upload
>>> worked fine. You can close the image (without saving)
>>>
>>>
>>>
>>> *Debugging:*
>>>
>>>
>>>
>>> Bob Arning has been able to reproduce the issue with my scenario.
>>> He dived into the code involved during this process, till reaching some
>>> "basic" methods where he saw the issue occuring.
>>>
>>> Here are the conclusion till there:
>>> => A corruption occurs while reading an input stream with method ZnUtils
>>> class>>readUpToEnd:limit:
>>> The first 4 bytes may be altered randomely.
>>> => The first 4 bytes are initially correctly written to an
>>> outputStream.
>>> But, the first 4 bytes of this outputStream gets altered (corrupted),
>>> sometimes when the inner byte array grows OR when performing the
>>> final "outputStream contents"
>>> => Here is a piece of code that reproduce the issue (still randomely.
>>> stopping an restarting the image may change

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

[Clément Bera]

Ok so the bug happens in VMMaker 2265 while the change in prim 105 was
introduced in 2273, so that's not it (I was surprised, there is lots of
tests for this).

It seems each time I have the problem, it happens when totalReadCount
reach 18186240. I guess that matches some specific array growth strategy ?
There are multiple different paths in the code dealing with this case.

---

We had issues in the past with signed vs unsigned operations and things
like that which would make some operations fails for large integers but it
does not seem to be related in this case (I don't see any integer
overflowing in the 32 bits range instead of 31 bits).

I don't think that's related to the C compiler either since the bug happen
in Mac and Linux which are compiled with llvm and gcc respectively.

---

I tried in Pharo 5, with recent VM it fails, older VMs it works. I tried
once for each though.

There is no simple code to debug, so I don't really know where to look. I
tried to wrap prim 105 with assertion and they all pass so the primitive
may not be faulty (I could check the diff with old versions though...).

On Fri, Jan 19, 2018 at 9:53 PM, Alistair Grant 
wrote:

> Hi Clément,
>
> On 19 January 2018 at 17:21, Alistair Grant  wrote:
> > Hi Clément,
> >
> > On 19 January 2018 at 17:04, Clément Bera 
> wrote:
> >> Does not seem to be related to prim 105.
> >>
> >> I am confused. Has the size of the array an impact at all ?
> >
> > Yes, I tried reducing the size of the array by a factor of 10 and
> > wasn't able to reproduce the problem at all.
> >
> > With the full size array it failed over half the time (32 bit).
> >
> > I ran the test about 180 times on 64 bit and didn't get a single failure.
> >
> >> It seems the
> >> problem shows since the first copy of 16k elements.
> >>
> >> I can't really reproduce the bug - it happened once but I cannot do it
> >> again. Does the bug happen with the StackVM/PharoS VM you can find here
> the
> >> 32 bits versions : http://files.pharo.org/vm/pharoS-spur32/ ? The
> >> StackVM/PharoS VM is the VM without the JIT, it may be since the bug is
> >> unreliable that it happens only in jitted code, so trying that out may
> be
> >> worth it.
> >
> > I'll try and have a look at this over the weekend.
>
> This didn't fail once in 55 runs.
>
> OS: Ubuntu 16.04
> Image: Pharo 6.0   Latest update: #60528
> VM:
> 5.0 #1 Wed Oct 12 15:48:53 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM]
> StackInterpreter VMMaker.oscog-EstebanLorenzano.1881 uuid:
> ed616067-a57c-409b-bfb6-dab51f058235 Oct 12 2016
> https://github.com/pharo-project/pharo-vm.git Commit:
> 01a03276a2e2b243cd4a7d3427ba541f835c07d3 Date: 2016-10-12 14:31:09
> +0200 By: Esteban Lorenzano  Jenkins build #606
> Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7
> 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux
> plugin path: /home/alistair/pharo7/Issue20982/bin/ [default:
> /home/alistair/pharo7/Issue20982/bin/]
>
>
> I then went back and attempted to reproduce the failures in my regular
> 32 bit image, but only got 1 corruption in 10 runs.  I've been working
> in this image without restarting for most of the day.
>
> Quitting out and restarting the image and then running the corruption
> check resulted in 11 corruptions from 11 runs.
>
>
> Image: Pharo 7.0 Build information:
> Pharo-7.0+alpha.build.425.sha.eb0a6fb140ac4a42b1f158ed37717e0650f778b4
> (32 Bit)
> VM:
> 5.0-201801110739  Thursday 11 January  09:30:12 CET 2018 gcc 4.8.5
> [Production Spur VM]
> CoInterpreter VMMaker.oscog-eem.2302 uuid:
> 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018
> StackToRegisterMappingCogit VMMaker.oscog-eem.2302 uuid:
> 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018
> VM: 201801110739
> alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $
> Date: Wed Jan 10 23:39:30 2018 -0800 $
> Plugins: 201801110739
> alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $
> Linux b07d7880072c 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9
> 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux
> plugin path: /snap/core/3748/lib/i386-linux-gnu/ [default:
> /snap/core/3748/lib/i386-linux-gnu/]
>
>
> So, as well as restarting the image before running the test, just
> wondering if the gcc compiler version could have an impact?
>
>
> HTH,
> Alistair
>
>
>
> > Cheers,
> > Alistair
> >
> >
> >
> >> On Thu, Jan 18, 2018 at 7:12 PM, Clément Bera 
> >> wrote:
> >>>
> >>> I would suspect a bug in primitive 105 on byte objects (it was changed
> >

Re: [Pharo-dev] VMs build process restored

[Clément Bera]

Thank you very much Esteban, Thanks Fabio.

On Tue, Feb 6, 2018 at 5:58 PM, Esteban Lorenzano 
wrote:

> (it was broken since december)
>
> Which means latest vm versions are latest builds from OSVM:
>
> 64bit
>
> • http://files.pharo.org/get-files/70/pharo64-mac-latest.zip
> • http://files.pharo.org/get-files/70/pharo64-linux-
> threaded-latest.zip
> • http://files.pharo.org/get-files/70/pharo64-linux-latest.zip
> • http://files.pharo.org/get-files/70/pharo64-win-latest.zip
> 32bit
>
> • http://files.pharo.org/get-files/70/pharo-linux-threaded-
> latest.zip
> • http://files.pharo.org/get-files/70/pharo-linux-latest.zip
> • http://files.pharo.org/get-files/70/pharo-mac-latest.zip
> • http://files.pharo.org/get-files/70/pharo-win-latest.zip
>
> Hints
>
> • MacOS VMs now are signed! This should fix a lot of problems we
> had before.
> • Please take note that win64 build lacks all library
> dependencies, and many things will not work (working on that).
> Thanks to Fabio to help me put all the pieces together.
>
>
> cheers,
> Esteban
>



-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

[Clément Bera]

Hi,

It seems the two methods have exactly the same behavior indeed.
valueWithPossibleArgs: anArray
valueWithEnoughArguments: anArray

One was edited recently but I think it's only to change the comment,
they're both very old. My guess is that there are two for compatibility
purpose (One is the selector that is considered as the most relevant that
should be used, the other one is the one also present in other Smalltalks
so we have it for cross-Smalltalk librairies or something like that), but
only one is really needed. If you need only the concept for SOM-NS you can
just implement one, if you want to be compatible with different Smalltalk
lib implement both.

All use-cases of these methods I have found do not inject nils, they expect
the block to have a number of arguments of the block less or equal to the
number of parameters in the argument array. I would say they're used as
#cullWithArguments: but for some reason other selector names were
preferred.

Now, as you mentioned, these two methods are more than just cullWithArguments:
since they inject nils if there are not enough parameters. To me it looks
incorrect to do so because then while debugging your code you will get
issues due to those injected nils and it will be tedious for the
application programmer to track the problem down to these two methods.

There a few use-cases for nil injection though. Typically when changing
existing frameworks in multiple repositories, it may be that during the
update process the change to the caller is installed before the change of
the callee, and if the code is actually used (code in UI for instance),
injecting nils might avoid system break-down. Another use-case is for
compatibility with frameworks using the nil injection, but I can't find a
framework doing that right now.

Honestly, I would not implement the nil injection, but maybe some one else
has a different point of view.

On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr 
wrote:

> Hi:
>
> I am trying to understand the different between and perhaps origin of
> BlockClosure>>#valueWithPossibleArgs: and BlockClosure>>#
> valueWithEnoughArguments:
>
> I am trying to decide which of the two I need for SOMns.
>
> The first one has seen more recent changes, when looking at the Pharo 6.1
> download:
>
> valueWithPossibleArgs: anArray—>  2/12/2017 StephaneDucasse
> valueWithEnoughArguments: anArray —>  3/11/2001 nk
>
> While they have rather different implementations, they seem to behave
> identically, as far as I could tell using the following example:
>
> blocks := {
>   [ { } ].
>   [:a | { a } ].
>   [:a :b | { a. b } ].
>   [:a :b :c | { a. b. c } ]
> }.
>
> blocks collect: [:b | b valueWithPossibleArgs: {1}].
> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
> blocks collect: [:b | b valueWithEnoughArguments: {1}].
> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].
>
> I was also wondering how they relate to #cull:*
>
> One of the major differences seems to be that valueWithP* and valueWithE*
> are both injecting nil for absent arguments, while normal #value* and
> #cull* methods signal an error.
> Is there a specific use case why one wouldn’t want to be strict here as
> well, but instead inject nils?
>
> Any comments or pointer appreciated.
>
> Thanks
> Stefan
>
>
> --
> Stefan Marr
> School of Computing, University of Kent
> http://stefan-marr.de/research/
>
>
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

[Clément Bera]

On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse 
wrote:

> Clement
>
> can you open a bug entry so that we clean this situation?
>
>
What is the bug? You want to merge the two selectors and break
compatibility with frameworks using the removed one?


> Stef
>
> On Mon, Feb 19, 2018 at 12:43 PM, Clément Bera 
> wrote:
> > Hi,
> >
> > It seems the two methods have exactly the same behavior indeed.
> > valueWithPossibleArgs: anArray
> > valueWithEnoughArguments: anArray
> >
> > One was edited recently but I think it's only to change the comment,
> they're
> > both very old. My guess is that there are two for compatibility purpose
> (One
> > is the selector that is considered as the most relevant that should be
> used,
> > the other one is the one also present in other Smalltalks so we have it
> for
> > cross-Smalltalk librairies or something like that), but only one is
> really
> > needed. If you need only the concept for SOM-NS you can just implement
> one,
> > if you want to be compatible with different Smalltalk lib implement both.
> >
> > All use-cases of these methods I have found do not inject nils, they
> expect
> > the block to have a number of arguments of the block less or equal to the
> > number of parameters in the argument array. I would say they're used as
> > #cullWithArguments: but for some reason other selector names were
> preferred.
> >
> > Now, as you mentioned, these two methods are more than just
> > cullWithArguments: since they inject nils if there are not enough
> > parameters. To me it looks incorrect to do so because then while
> debugging
> > your code you will get issues due to those injected nils and it will be
> > tedious for the application programmer to track the problem down to these
> > two methods.
> >
> > There a few use-cases for nil injection though. Typically when changing
> > existing frameworks in multiple repositories, it may be that during the
> > update process the change to the caller is installed before the change of
> > the callee, and if the code is actually used (code in UI for instance),
> > injecting nils might avoid system break-down. Another use-case is for
> > compatibility with frameworks using the nil injection, but I can't find a
> > framework doing that right now.
> >
> > Honestly, I would not implement the nil injection, but maybe some one
> else
> > has a different point of view.
> >
> > On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr 
> > wrote:
> >>
> >> Hi:
> >>
> >> I am trying to understand the different between and perhaps origin of
> >> BlockClosure>>#valueWithPossibleArgs: and
> >> BlockClosure>>#valueWithEnoughArguments:
> >>
> >> I am trying to decide which of the two I need for SOMns.
> >>
> >> The first one has seen more recent changes, when looking at the Pharo
> 6.1
> >> download:
> >>
> >> valueWithPossibleArgs: anArray—>  2/12/2017 StephaneDucasse
> >> valueWithEnoughArguments: anArray —>  3/11/2001 nk
> >>
> >> While they have rather different implementations, they seem to behave
> >> identically, as far as I could tell using the following example:
> >>
> >> blocks := {
> >>   [ { } ].
> >>   [:a | { a } ].
> >>   [:a :b | { a. b } ].
> >>   [:a :b :c | { a. b. c } ]
> >> }.
> >>
> >> blocks collect: [:b | b valueWithPossibleArgs: {1}].
> >> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
> >> blocks collect: [:b | b valueWithEnoughArguments: {1}].
> >> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].
> >>
> >> I was also wondering how they relate to #cull:*
> >>
> >> One of the major differences seems to be that valueWithP* and
> valueWithE*
> >> are both injecting nil for absent arguments, while normal #value* and
> #cull*
> >> methods signal an error.
> >> Is there a specific use case why one wouldn’t want to be strict here as
> >> well, but instead inject nils?
> >>
> >> Any comments or pointer appreciated.
> >>
> >> Thanks
> >> Stefan
> >>
> >>
> >> --
> >> Stefan Marr
> >> School of Computing, University of Kent
> >> http://stefan-marr.de/research/
> >>
> >>
> >>
> >
> >
> >
> > --
> > Clément Béra
> > Pharo consortium engineer
> > https://clementbera.wordpress.com/
> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

[Clément Bera]

On Thu, Feb 22, 2018 at 11:47 AM, Sven Van Caekenberghe 
wrote:

>
>
> > On 22 Feb 2018, at 10:41, Clément Bera  wrote:
> >
> >
> >
> > On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse <
> stepharo.s...@gmail.com> wrote:
> > Clement
> >
> > can you open a bug entry so that we clean this situation?
> >
> >
> > What is the bug?
>
> Having two selectors doing the same thing is bad and confuses everybody.
> So that is a 'bug'.
>
> > You want to merge the two selectors and break compatibility with
> frameworks using the removed one?
>
> Either we keep on adding cruft (or leaving cruft in place) in the sake of
> backwards compatibility or be do something about it. It is not hard to fix
> a couple of senders. It could be done more softly with a deprecation.
>
> Cleanups at the level of Object are particularly valuable.
>

Ok.

Is the nil injection a feature or a bug too ? Should it be removed ?


>
> > Stef
> >
> > On Mon, Feb 19, 2018 at 12:43 PM, Clément Bera 
> wrote:
> > > Hi,
> > >
> > > It seems the two methods have exactly the same behavior indeed.
> > > valueWithPossibleArgs: anArray
> > > valueWithEnoughArguments: anArray
> > >
> > > One was edited recently but I think it's only to change the comment,
> they're
> > > both very old. My guess is that there are two for compatibility
> purpose (One
> > > is the selector that is considered as the most relevant that should be
> used,
> > > the other one is the one also present in other Smalltalks so we have
> it for
> > > cross-Smalltalk librairies or something like that), but only one is
> really
> > > needed. If you need only the concept for SOM-NS you can just implement
> one,
> > > if you want to be compatible with different Smalltalk lib implement
> both.
> > >
> > > All use-cases of these methods I have found do not inject nils, they
> expect
> > > the block to have a number of arguments of the block less or equal to
> the
> > > number of parameters in the argument array. I would say they're used as
> > > #cullWithArguments: but for some reason other selector names were
> preferred.
> > >
> > > Now, as you mentioned, these two methods are more than just
> > > cullWithArguments: since they inject nils if there are not enough
> > > parameters. To me it looks incorrect to do so because then while
> debugging
> > > your code you will get issues due to those injected nils and it will be
> > > tedious for the application programmer to track the problem down to
> these
> > > two methods.
> > >
> > > There a few use-cases for nil injection though. Typically when changing
> > > existing frameworks in multiple repositories, it may be that during the
> > > update process the change to the caller is installed before the change
> of
> > > the callee, and if the code is actually used (code in UI for instance),
> > > injecting nils might avoid system break-down. Another use-case is for
> > > compatibility with frameworks using the nil injection, but I can't
> find a
> > > framework doing that right now.
> > >
> > > Honestly, I would not implement the nil injection, but maybe some one
> else
> > > has a different point of view.
> > >
> > > On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr  >
> > > wrote:
> > >>
> > >> Hi:
> > >>
> > >> I am trying to understand the different between and perhaps origin of
> > >> BlockClosure>>#valueWithPossibleArgs: and
> > >> BlockClosure>>#valueWithEnoughArguments:
> > >>
> > >> I am trying to decide which of the two I need for SOMns.
> > >>
> > >> The first one has seen more recent changes, when looking at the Pharo
> 6.1
> > >> download:
> > >>
> > >> valueWithPossibleArgs: anArray—>  2/12/2017 StephaneDucasse
> > >> valueWithEnoughArguments: anArray —>  3/11/2001 nk
> > >>
> > >> While they have rather different implementations, they seem to behave
> > >> identically, as far as I could tell using the following example:
> > >>
> > >> blocks := {
> > >>   [ { } ].
> > >>   [:a | { a } ].
> > >>   [:a :b | { a. b } ].
> > >>   [:a :b :c | { a. b. c } ]
> > >> }.
> > >>
> > >> blocks collect: [:b | b valueWithPossibleArgs: {1}].
>

Re: [Pharo-dev] control flow graph

[Clément Bera]

I used that in the past on intermediate representations, I feel it is very
useful to directly edit the code of methods with large control flows since
when you have many closing brackets ] ] ] ] you never know where to write
your code. Now it's specific to some use-cases such as algorithms where you
write methods with large control flows, in most methods due to object
oriented programming convention the control flow is not that big. In this
context other things could be possible (Smart suggestions to move code out
of loops, etc.)






On Fri, Feb 23, 2018 at 11:37 AM, Stephane Ducasse 
wrote:

> Hi
>
> I'm experimenting in building a control flow graph of pharo methods
> and I would like to know if you have ideas about what we can do
> with them to support our development environment.
>
> Stef
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] control flow graph

[Clément Bera]

The control flow is just a visualisation, everything can be done without
it, it's just way more convenient to look at.

On Feb 24, 2018 09:08, "Stephane Ducasse"  wrote:

> Clement this analysis can be done without a control flow no?
>
>
> On Fri, Feb 23, 2018 at 11:47 AM, Clément Bera 
> wrote:
> > I used that in the past on intermediate representations, I feel it is
> very
> > useful to directly edit the code of methods with large control flows
> since
> > when you have many closing brackets ] ] ] ] you never know where to write
> > your code. Now it's specific to some use-cases such as algorithms where
> you
> > write methods with large control flows, in most methods due to object
> > oriented programming convention the control flow is not that big. In this
> > context other things could be possible (Smart suggestions to move code
> out
> > of loops, etc.)
> >
> >
> >
> >
> >
> >
> > On Fri, Feb 23, 2018 at 11:37 AM, Stephane Ducasse <
> stepharo.s...@gmail.com>
> > wrote:
> >>
> >> Hi
> >>
> >> I'm experimenting in building a control flow graph of pharo methods
> >> and I would like to know if you have ideas about what we can do
> >> with them to support our development environment.
> >>
> >> Stef
> >>
> >
> >
> >
> > --
> > Clément Béra
> > Pharo consortium engineer
> > https://clementbera.wordpress.com/
> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>

Re: [Pharo-dev] Discord server vanished!

[Clément Bera]

Yeah it's been down for already 11 hours or something like that.

On Sat, Mar 10, 2018 at 3:12 AM, Sean P. DeNigris 
wrote:

> Vincent.Blondeau wrote
> > https://discordapp.com/invite/Sj2rhxn
>
> I confirm this doesn't work. Clicking Accept leads to an error.
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.github.io/
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] renaming Matrix to 2dArray

[Clément Bera]

Hi,

long time ago I renamed 2DArray as Matrix. Now our Matrix class does
> not support any of the Matrix operations


Some Matrix operations are implemented:

- I see in Matrix class #+*, #preMultiplyByArray:, #preMultiplyByMatrix:
which are Matrix specific arithmetic (Multiplication of Matrix by Vector
and Matrix) in *Collections-arithmetic protocol. Does that mean these API
will be removed while renaming ? They don't seem to be used anyway.

- There is also #transposed, which is the transposed matrix operator
implemented only for square matrix or an assertion failure is raised. This
method is used, it makes sense to have the transposed operator in Matrix
class but I don't think it would mean anything on a Array2D class (What
does it mean to transpose a 2D Array ?). Is this API going to be removed
and all users patched ? Or maybe we rename it to #squareMatrixTransposed in
Array2D expressing the intent (interpret the Array2D as a Matrix, works
only on square Matrix). What do you think ?

I think it makes sense to rename from Matrix to Array2D only if we patch
first these matrix specific APIs. There are not many we can do it.

Regards,

On Sat, Mar 10, 2018 at 5:35 AM, Esteban A. Maringolo 
wrote:

> I thought you couldn't name classes starting with numbers.
>
> If that wasn't the case I think Array2D would be a better option.
>
> Regards,
>
>
> Esteban A. Maringolo
> Esteban A. Maringolo
>
>
> 2018-03-09 17:46 GMT-03:00 Stephane Ducasse :
> > Hi
> >
> > long time ago I renamed 2DArray as Matrix. Now our Matrix class does
> > not support any of the Matrix operations, so I was thinking that to
> > avoid confusion (people should use polymath) we should rename it back
> > to 2DArray.
> > What do you think?
> >
> > Stef
> >
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.github.io/
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

[Pharo-dev] Using Metacello+git+tonel ?

[Clément Bera]

Hi,

I am trying to write a Metacello configuration loading code from git in the
tonel format.

I checked all the configurations present in the default Pharo image looking
for examples, but it seems most of them load code with Monticello.

I found ConfigurationOfPharoMetacello which loads code from github,
however, it loads code using the file tree format and not tonel format.

Can someone point me to a configuration loading code from git using tonel
so I can use it as an example?

Thanks

-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-05

[Clément Bera]

Hi Pavel,

I'm looking at PosixSharedMemory again since I have to write a Master
student proposal and I think this could be a good topic. I'm not really
expert on SharedMemory, so I'm going to share what I have in mind, we can
discuss about it, you could also co-supervise the student indirectly
(though officially the supervisor has to be VUB staff).

Implementation-wise, I was thinking what could be interesting are:
- Making PosixSharedMemory compatible with TaskIt so from you image you can
create a SharedMemory buffer, spawn another image+VM and attach it to the
shared memory to have multiple threads working on the shared section.
- Add the #at:if:put: primitive, which write into the shared memory using
compare and swap instruction for efficient thread-safe access.
- Add on SharedMemory all the primitives to read/write native types to the
buffer (int64, double, etc.) with CAS and non CAS instructions.
- Maybe add APIs to read/write objects through Fuel to pass them by copy,
though this looks difficult in some cases.
- Implement a lock system or a semaphore system on top of the CAS
- implement lock-free and lock-full algorithm using CAS and non CAS
instructions (I think a first try would be parallelSort on a 1Gb buffer of
int32 with 4 native threads)

What do you think ? Do you have ideas ? Are you interested ? Do you thing
having a student on this would be nice ?

The master thesis proposal has to include a research question. I am not
sure what other languages do regarding shared memory.It's not clear so far
what the research question is.

Best,

On Mon, Feb 12, 2018 at 10:33 AM, Pavel Krivanek 
wrote:

> Hi,
>
> among other less interesting things, I spent some time on existing
> PosixSharedMemory project. It is a UFFI binding for the LibC methods
> that provide support for the memory allocation between several
> separate processes. I significantly improved the performance by
> implementing the block access. Writing of 10MB byte array takes about
> 1 millisecond, reading of it from other image took me about 4
> milliseconds. While serialization with Fuel is very fast, it opens
> interesting possibilities.
> To have a shared memory without synchronization tools is not very
> useful so I wrote a basic UFFI interface for the POSIX named
> semaphores. They are quite easy to use and work nicely with Pharo. The
> VM can all wait on the semaphore or it can check the status of it
> periodically in an image thread. It has two small disadvantages. It
> requires to dynamically link the next library (pthread) and they must
> be cleaned manually. I plan to look at System V alternative in future.
> Now we should write a nice framework for inter-image communication on
> top of it or/and adopt Seamless for it ;-)
>
> Cheers,
> -- Pavel
>
>


-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-05

[Clément Bera]

On Tue, Apr 17, 2018 at 2:08 PM, Thierry Goubier 
wrote:

> 2018-04-17 14:03 GMT+02:00 Clément Bera :
> > Hi Pavel,
> >
> > I'm looking at PosixSharedMemory again since I have to write a Master
> > student proposal and I think this could be a good topic. I'm not really
> > expert on SharedMemory, so I'm going to share what I have in mind, we can
> > discuss about it, you could also co-supervise the student indirectly
> (though
> > officially the supervisor has to be VUB staff).
> >
> > Implementation-wise, I was thinking what could be interesting are:
> > - Making PosixSharedMemory compatible with TaskIt so from you image you
> can
> > create a SharedMemory buffer, spawn another image+VM and attach it to the
> > shared memory to have multiple threads working on the shared section.
> > - Add the #at:if:put: primitive, which write into the shared memory using
> > compare and swap instruction for efficient thread-safe access.
> > - Add on SharedMemory all the primitives to read/write native types to
> the
> > buffer (int64, double, etc.) with CAS and non CAS instructions.
> > - Maybe add APIs to read/write objects through Fuel to pass them by copy,
> > though this looks difficult in some cases.
> > - Implement a lock system or a semaphore system on top of the CAS
> > - implement lock-free and lock-full algorithm using CAS and non CAS
> > instructions (I think a first try would be parallelSort on a 1Gb buffer
> of
> > int32 with 4 native threads)
> >
> > What do you think ? Do you have ideas ? Are you interested ? Do you thing
> > having a student on this would be nice ?
> >
> > The master thesis proposal has to include a research question. I am not
> sure
> > what other languages do regarding shared memory.It's not clear so far
> what
> > the research question is.
>
> I can forward that to a researcher here working on distributed shared
> memory.
>
> Research question can be:
> - heterogeneity (x86 + pi at the same time)
> - load balancing between competing images on heterogeneous hardware
> ...
> - Object migration (pointer forwarding). Probably not, state of the
> art is very advanced on that which means a costly implementation to
> reach parity.
>
>
SharedMemory on heterogenous hardware ? Do you mean you need to physically
plug the memory into a Raspberry Pie and an x86 computer ? Or you mean
exporting the RAM of one hardware as NFS to the others ? I was just
thinking sharing the memory between multiple pairs of image+VM on the same
machine to be able to run some multi-threaded algorithm on the shared
buffer. I know it's not much but we need to start somewhere.

The student would have 6 months, including 1 month to write the thesis so
it cannot be too heavy. Something that we can re-use with a minor research
contribution would be nice.

Thierry
>
> >
> > Best,
> >
> > On Mon, Feb 12, 2018 at 10:33 AM, Pavel Krivanek <
> pavel.kriva...@gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> among other less interesting things, I spent some time on existing
> >> PosixSharedMemory project. It is a UFFI binding for the LibC methods
> >> that provide support for the memory allocation between several
> >> separate processes. I significantly improved the performance by
> >> implementing the block access. Writing of 10MB byte array takes about
> >> 1 millisecond, reading of it from other image took me about 4
> >> milliseconds. While serialization with Fuel is very fast, it opens
> >> interesting possibilities.
> >> To have a shared memory without synchronization tools is not very
> >> useful so I wrote a basic UFFI interface for the POSIX named
> >> semaphores. They are quite easy to use and work nicely with Pharo. The
> >> VM can all wait on the semaphore or it can check the status of it
> >> periodically in an image thread. It has two small disadvantages. It
> >> requires to dynamically link the next library (pthread) and they must
> >> be cleaned manually. I plan to look at System V alternative in future.
> >> Now we should write a nice framework for inter-image communication on
> >> top of it or/and adopt Seamless for it ;-)
> >>
> >> Cheers,
> >> -- Pavel
> >>
> >
> >
> >
> > --
> > Clément Béra
> > https://clementbera.github.io/
> > https://clementbera.wordpress.com/
>
>


-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/

Re: [Pharo-dev] Hierarchy (roots) of package

[Clément Bera]

I would do that:

Implementation:
rootsInsidePackage := [ :packageName |
| myPackage |
myPackage := RPackageOrganizer default packageNamed: packageName.
myPackage definedClasses select: [ :each | each superclass package ~~
myPackage ] ].

Example use-case:
rootsInsidePackage value: 'OpalCompiler-Core'

Is that what you expected ?

On Thu, Apr 19, 2018 at 7:19 AM, Stephane Ducasse 
wrote:

> Hi
>
> Given a package I would like to know the classes that are roots
> of hierarchy inside the package.
>
> Do we have something like that?
>
> Stef
>
>


-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/

Re: [Pharo-dev] Athens based game worked on windows and pharo 60 :)

[Clément Bera]

On Tue, May 1, 2018 at 1:21 PM, H. Hirzel  wrote:

> Hello Stef
>
> Is this Athens based game available somewhere?
>
>
It's not the same game, but I wrote 2 real-time Athens based game and
they're available on my github:
- Spider Invasion: Minimal game if you're interesting in the basics, single
loop for rendering and game logic, code written in a simple way, no
start-up menus, instructions for linux 64 bits only.
https://github.com/clementbera/SpiderInvasion
- Wizard Battle Arena: A bit more complex, Game & rendering loops are
separated to drop frame without corrupting game logic, code inside
game/rendering loop rewritten for 50fps performance, start-up menus,
instructions for Win/Mac/Linux 32-64bits.
https://github.com/clementbera/wizard-battle-arena

I have not been able to set-up sound in a cross platform way so far, if any
one has any clue...


> Regards
>
> Hannes
>
> On 3/10/17, stepharong  wrote:
> > Hi esteban
> >
> > Today during the labs at the university, we verified with the latest VM
> on
> >
> > windows that the athens based game that the students were improving is
> > working with Pharo 60 (while some weeks ago when they tried it did not).
> >
> > Stef
> >
> >
> > --
> >
> >
>
>


-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/

Re: [Pharo-dev] Sista & Pharo 7

[Clément Bera]

Latest release is on Pharo 6 (
https://clementbera.wordpress.com/2017/07/19/sista-open-alpha-release/)
That's the release where the published benchmarks happened and where
multiple developers got involved.

No plan to release on Pharo 7 alpha. Ask again once Pharo 7 is released.

Repository is in migration though, I migrated to github earlier this year,
but with recent changes & new organization, I think the repository will be
merged with open-smalltalk-vm repository. Documentation will be merged too,
so it's going to be easier to build images and matching VMs or move code
from VM-side to image-side or the other way around.

I think questions related to Sista should be on vm-dev since there are only
alpha releases (i.e. no interest for non VM developers).

On Thu, Jun 14, 2018 at 5:28 AM, Ben Coman  wrote:

> Is Sista operational in the latest Pharo 7 builds?
>
> What is the plan for Sista in relation to Pharo 7?
>
> cheers -ben
>



-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/

Re: [Pharo-dev] Why do we have SmallDictionary?

[Clément Bera]

his thread, it would make a lot of
> sense to run benchmarks again. Actually, I think it would be nice to have a
> benchmark suite for these cases, that would let us monitor the performance
> and ensure that changes to the codebase don't have a deteriorative effect.
> I'm not saying that it would be easy to make this happen, writing proper
> benchmarks is hard (for me especially, as it seems, given my utter failure
> to think of the edge cases before starting this thread). Such a suite might
> also prevent these sorts of questions on the mailing list in the future, or
> at least might make it easier to answer them.
>
>
>
>
> On 8 June 2018, at 13:01, Andres Valloud wrote:
>
> In addition, open addressing with linear probing has superior cache line
>> read behavior (no indirection / random traversal, and if the first probe
>> misses the second one was likely cached by the first one).
>>
>
>
> Ah, nice catch! Although that would require frequent access to the
> dictionary / repeated access to the same items to have an effect, wouldn't
> it?
>
>
>
> On 8 Jun 2018, at 10:01, Clément Bera wrote:
>
> Hi Max,
>>
>> Theoretically, for a small number of elements, usually somewhere between 3
>> and 30 depending on implementations, a linear search is faster than a hash
>> search, especially in the Pharo dictionary hash search implementation.
>>
>> Efficient dictionary implementations are usually bucket-based. The
>> dictionary holds a certain number of buckets, and based on the key hash,
>> the bucket where the key value is present is determined. Small buckets are
>> linear (arrays or linked list). Large buckets are typically balanced
>> binary
>> trees (red-black trees typically). Under a certain number of elements
>> there
>> is a single bucket, which means a linear search is performed, as for the
>> SmallDictionary. When it grows the dictionary search becomes a combination
>> between a hash search and a linear or tree search.
>>
>> Pharo dictionary search is first hash-based, then all the buckets are
>> represented next to each other in the same arrays and a linear search is
>> performed there, leading to many collisions and slower search time
>> (especially when the element is not found), sometimes the code searches
>> over multiple buckets because the dictionary is too full or there are too
>> many near-collisions. The memory consumption is competitive with the
>> advanced implementations though (precise measurements would need to be
>> made).
>>
>> Method dictionaries are represented differently to optimize the look-up
>> logic.
>>
>> If you want to improve things and have one dictionary implementation
>> instead of two, implement or look for a bucket based dictionary and put it
>> in the base image instead of Dictionary. This is quite some work since
>> there are many APIs to port. You can look at the Pinnochio implementation,
>> it's quite good but they've not implemented large buckets.
>>
>
> Thanks for the detailed explanations Clément and Levente. I'll probably
> not add a new dictionary implementation ;)
>
>
>
>>
>>
>> On Fri, Jun 8, 2018 at 8:46 AM, Max Leske  wrote:
>>
>> Hi,
>>>
>>> I was messing around with SmallDictionary when I suddenly realised that I
>>> can't find a single reason to use it over a normal Dictionary. While its
>>> name and class comment imply that it is somehow an optimised Dictionary,
>>> I
>>> don't see any measurement where that actually holds up. The following was
>>> run in a Pharo 7 image on a recent VM (see below):
>>>
>>> | d |
>>> d := SmallDictionary new.
>>> d sizeInMemory. "24"
>>> [10 timesRepeat: [
>>> 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun.
>>> "0:00:00:05.226"
>>>
>>> [10 timesRepeat: [
>>> d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.041"
>>>
>>>
>>>
>>> | d |
>>> d := Dictionary new.
>>> d sizeInMemory. "16"
>>> [10 timesRepeat: [
>>> 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun.
>>> "0:00:00:00.385"
>>> [10 timesRepeat: [
>>> d at: 48 ifAbsent: [] ] ] timeToRun.  "0:00:00:00.006"
>>>
>>>
>>> As you can see, SmallDictionary is 8 bytes larger per instance and
>>> significantly faster while reading and writing (I know that this isn't a
>>> good benchmark but it suffices to make my point).
>>>
>>>
>>> Is anyone aware of a reason for hanging on to SmallDictionary? I'm also
>>> curious to know how SmallDictionary came to be. There must have been some
>>> advantage over Dictionary at some point in the past.
>>>
>>>
>>> Cheers,
>>> Max
>>>
>>>
>>>
>>>
>>>
>>> Image version: Pharo 7.0
>>> Build information: Pharo-7.0+alpha.build.961.sha.
>>> a69e72a97136bc3f93831584b6efa2b1703deb84 (32 Bit)
>>>
>>> VM version: CoInterpreter VMMaker.oscog- nice.2281 uuid:
>>> 4beeaee7-567e-1a4b-b0fb-bd95ce302516 Nov 27 2017
>>> StackToRegisterMappingCogit VMMaker.oscog-nice.2283 uuid:
>>> 2d20324d-a2ab-48d6-b0f6-9fc3d66899da Nov 27 2017
>>> VM: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>>> Date: Mon Nov 27 00:36:29 2017 +0100 $ Plugins: 201711262336
>>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>>>
>>> OS: macOS 10.13.5
>>> Machine: MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
>>>
>>>
>>>
>>
>> --
>> Clément Béra
>> https://clementbera.github.io/
>> https://clementbera.wordpress.com/
>>
>
>
>
>


-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/

Re: [Pharo-dev] [rmod] About the infinite debugger

[Clément Bera]

Hi,

Normally the pull request should break the exception tests, especially the
ones with nested handler, since they are the reason 199 marked signalling
contexts were introduced.

Looking quickly this test in latest Pharo 7 for example:
ExceptionTests>>testHandlerContext
fails with the pull request.

Since the pull request changes a green test into a red test, I don't
understand why you say "we unfortunately don't have tests for it". I don't
understand either why you say this pragma is "wrong", so I can't help with
that either.

Best,

On Fri, Jun 29, 2018 at 4:48 PM, Guillermo Polito  wrote:

> Hi all,
>
> during today's sprint we have been working with lots of people on the
> infinite debugger problem (https://pharo.fogbugz.com/f/cases/22085/). We
> have checked the emails sent in the latest month. Then, together with
> Quentin, Pablo, Pavel, Yoan we have been discussing and testing hypothesis
> all day. We have been also comparing the debuggers code between pharo 3/4
> (where the bug was is present) and pharo 7, but this was not necessarily
> straight forward as the code is not the same and there is no easy diff...
>
> ND, we have found that the problem may come from a wrong pragma
> marker. Just removing that pragma gives us back the same behaviour as in
> Pharo 3/4. :D
>
> https://github.com/pharo-project/pharo/pull/1621
>
> I know that the exception handling/debugging has been modified several
> times in the latest years (some refactorings, hiding contexts...), we
> unfortunately don't have tests for it, so I'd like some more pair of eyes
> on it. Ben, Martin could you take a look?
>
> Thanks all for the fish,
> Guille
>



-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/

Re: [Pharo-dev] question

[Clément Bera]

All the primitives in the Cog have error codes. Pharo does not write it
explicitly for each primitive, but Pharo could. Knowing why a primitive
failed is very useful. The Cog support over 400 primitives. Do you want to
copy that comment 400 times ? I don't think so. What if one wants to update
that comment, one would need to update all the 400 comments ? That's insane
and very hard to maintain.

It would be nice to update the comment of Object class>>#whatIsAPrimitive
with a paragraph on error code instead, such as the one you wrote.



On Sun, Jun 26, 2016 at 8:00 PM, stepharo  wrote:

> So could we have a nice method comments that I can add to all the
> primitive using this ec?
>
> Proposal:
> https://pharo.fogbugz.com/f/cases/18618/Better-additional-comment-for-primitive-79-error-ec-usage
>
>  "ec is a special temporary variable that holds an error code. In the
> VM primitive, failure is indicated by a variable called primFailCode being
> non-zero. On activating a method with a failing primitive, if the index is
> in bounds of the primitiveFailCodes array in the VMspecialObjectsArray then
> the failure code substitutes the symbol in the primitiveFailCodes array,
> otherwise it supplies the integer value."
>
> Because what I like the most in smalltalk besides live coding is comments.
>
> Stef
>
>
>
>
> Le 22/6/16 à 17:25, Clément Bera a écrit :
>
> It's a special case added a couple year ago to figure out why a primitive
> fail.
>
> It's a special temporary variable that holds an error code. The special
> object array defines a list of error code that the VM can use to explain to
> the programmer why the primitive failed, which are currently symbols.
>
>
>
> On Wed, Jun 22, 2016 at 4:22 PM, Max Leske  wrote:
>
>>
>> > On 22 Jun 2016, at 15:59, stepharo < steph...@free.fr>
>> wrote:
>> >
>> > Hi
>> >
>> > I want to explain where ec is coming.
>> >
>> > I thought that the arguments of pragmas could only be literal and when
>> I see ec it looks like a variable set by the VM
>> >
>> >
>> > newMethod: numberOfBytes header: headerWord
>> >"Primitive. Answer an instance of me. The number of literals (and
>> other
>> > information) is specified by the headerWord (see my class comment).
>> > The first argument specifies the number of fields for bytecodes in
>> the
>> > method. Fail if either argument is not a SmallInteger, or if
>> numberOfBytes
>> > is negative, or if memory is low. Once the header of a method is
>> set by
>> > this primitive, it cannot be changed to change the number of
>> literals.
>> > Essential. See Object documentation whatIsAPrimitive."
>> >
>> >
>> >ec == #'insufficient object memory' ifTrue:
>> >[^self handleFailingNewMethod: numberOfBytes header: headerWord].
>> >^self primitiveFailed
>> >
>> >
>> > Stef
>> >
>> >
>>
>> That is correct. It’s still a literal though.
>>
>
>
>

Re: [Pharo-dev] question

[Clément Bera]

There is not only #primitive:error: but #primitive:module:error: and
#primitive:error:module: .

Then when you look at Object>>#at:, it's written  but you
could write . I don't know why the error code is
not there by default, it could be for performance, but it is supported and
it is used to know why the primitive fails. So you can look at all of the
users of #primitive: and #primitive:module: too.

When I do this in my Pharo image:
CompiledMethod allInstances count: [ :each | each primitive ~= 0 ]
I have 9136.
And all of them can have error code, though only 268 use it explicitly.

whatIsAPrimitive comment looks correct. There are little details to fix:
- LargeIntegers are 32 or 64 bits, not 16bits.
- the code convention for 'no lookup' is respected, but writting 'optional'
for optional primitive and 'essential' for essential primitive is not done
in many primitives in Pharo. Maybe it makes sense for numbered primitive
only. One needs to check where it's done, where it's not done and why.

I think it's good to improve comments related to primitives as this is one
part of the system where you cannot understand what they do just by reading
the Smalltalk code. Thanks for doing that Stef.




On Sun, Jun 26, 2016 at 10:06 PM, stepharo  wrote:

> There are 28 users of primitive:error: not 400.
>
> So where can I find the others? Do you know if whatIsAPrimitive
> description is up to date?
>
> Stef
>
> Le 26/6/16 à 21:00, Clément Bera a écrit :
>
> All the primitives in the Cog have error codes. Pharo does not write it
> explicitly for each primitive, but Pharo could. Knowing why a primitive
> failed is very useful. The Cog support over 400 primitives. Do you want to
> copy that comment 400 times ? I don't think so. What if one wants to update
> that comment, one would need to update all the 400 comments ? That's insane
> and very hard to maintain.
>
> It would be nice to update the comment of Object class>>#whatIsAPrimitive
> with a paragraph on error code instead, such as the one you wrote.
>
>
>
> On Sun, Jun 26, 2016 at 8:00 PM, stepharo  wrote:
>
>> So could we have a nice method comments that I can add to all the
>> primitive using this ec?
>>
>> Proposal:
>> https://pharo.fogbugz.com/f/cases/18618/Better-additional-comment-for-primitive-79-error-ec-usage
>>
>>  "ec is a special temporary variable that holds an error code. In the
>> VM primitive, failure is indicated by a variable called primFailCode being
>> non-zero. On activating a method with a failing primitive, if the index is
>> in bounds of the primitiveFailCodes array in the VMspecialObjectsArray then
>> the failure code substitutes the symbol in the primitiveFailCodes array,
>> otherwise it supplies the integer value."
>>
>> Because what I like the most in smalltalk besides live coding is
>> comments.
>>
>> Stef
>>
>>
>>
>>
>> Le 22/6/16 à 17:25, Clément Bera a écrit :
>>
>> It's a special case added a couple year ago to figure out why a primitive
>> fail.
>>
>> It's a special temporary variable that holds an error code. The special
>> object array defines a list of error code that the VM can use to explain to
>> the programmer why the primitive failed, which are currently symbols.
>>
>>
>>
>> On Wed, Jun 22, 2016 at 4:22 PM, Max Leske < 
>> maxle...@gmail.com> wrote:
>>
>>>
>>> > On 22 Jun 2016, at 15:59, stepharo  wrote:
>>> >
>>> > Hi
>>> >
>>> > I want to explain where ec is coming.
>>> >
>>> > I thought that the arguments of pragmas could only be literal and when
>>> I see ec it looks like a variable set by the VM
>>> >
>>> >
>>> > newMethod: numberOfBytes header: headerWord
>>> >"Primitive. Answer an instance of me. The number of literals (and
>>> other
>>> > information) is specified by the headerWord (see my class comment).
>>> > The first argument specifies the number of fields for bytecodes in
>>> the
>>> > method. Fail if either argument is not a SmallInteger, or if
>>> numberOfBytes
>>> > is negative, or if memory is low. Once the header of a method is
>>> set by
>>> > this primitive, it cannot be changed to change the number of
>>> literals.
>>> > Essential. See Object documentation whatIsAPrimitive."
>>> >
>>> >
>>> >ec == #'insufficient object memory' ifTrue:
>>> >[^self handleFailingNewMethod: numberOfBytes header:
>>> headerWord].
>>> >^self primitiveFailed
>>> >
>>> >
>>> > Stef
>>> >
>>> >
>>>
>>> That is correct. It’s still a literal though.
>>>
>>
>>
>>
>
>

Re: [Pharo-dev] ShortArray, DoubleArray & influence of 64bit

[Clément Bera]

Hi

On Tue, Jul 5, 2016 at 4:21 PM, Thibault Raffaillac <
thibault.raffail...@inria.fr> wrote:

> Hi all,
>
> For a few months now I have been using IntegerArray and FloatArray with
> UFFI. They are pretty convenient since they reside in Internal memory space
> (unlike FFIExternalArray) yet you can pass them in a C function call with
> the "ByteArray" signature.
> Now I need the equivalent arrays for short, double words and IEEE 64bit
> double. Comment in
> Class>>variableWordSubclass:instanceVariableNames:classVariableNames:package:
> says Spur already supports them. From discussion with Guille it seems we
> just need new subclasses of BitsLayout (ByteLayout and WordLayout
> implemented so far).
>
> Question 1: What is the value of instanceSpecification for shorts and
> double-words?
>

I copy the comment of Behavior>>instSpec

*instSpec*
* "Answer the instance specification part of the format that defines what
kind of object*
* an instance of the receiver is.  The formats are*
* 0 = 0 sized objects (UndefinedObject True False et al)*
* 1 = non-indexable objects with inst vars (Point et al)*
* 2 = indexable objects with no inst vars (Array et al)*
* 3 = indexable objects with inst vars (MethodContext AdditionalMethodState
et al)*
* 4 = weak indexable objects with inst vars (WeakArray et al)*
* 5 = weak non-indexable objects with inst vars (ephemerons) (Ephemeron)*
* 6 = unused*
* 7 = immediates (SmallInteger, Character)*
* 8 = unused*
* 9 = 64-bit indexable*
* 10-11 = 32-bit indexable (Bitmap)*
* 12-15 = 16-bit indexable*
* 16-23 = 8-bit indexable*
* 24-31 = compiled methods (CompiledMethod)"*


>
> Question 2: Both IntegerArray and WordArray exist and refer to 32bit
> arrays, should there be a difference between the two?
>
> Yes.

IntegerArray has two specific accessing primitives to store and read raw
integers.

WordArray uses the normal accessing primitives.

Question 3: How will it fare with 64bit Spur? Does word refer to 32bit or
> 64bit then? Is WordArray/variableWordSubclass growing to 64bit? FloatArray
> too?
>

It depends.

ByteArray is a good name and ShortArray is good name, self-explanatory,
there is no discussion here.

Then it depends, at some place we use WordArray and DoubleWordArray, in
other we use LongArray and SixtyFourBitsIndexableArray... I'd go for
WordArray and DoubleWordArray, but I don't mind if one decides otherwise.

For Float, we changed the representation to be "SmallFloat64" and
"BoxedFloat64". We have no proper support for single precision float in
Pharo. We could consider renaming FloatArray to DoubleArray, Float64Array,
or something similar. I don't know.


> Cheers,
> Thibault
>
>

Re: [Pharo-dev] changing compiled byte arrays

[Clément Bera]

This is the normal behavior. You are mutating the method's literal, which
becomes different. The instance is per method, so even if you do:

foo
#[1 2 3] at: 2 put: 50.
^ #[1 2 3]

You get #[1 50 3], which is easy to understand in this example, but can be
very tricky to understand in some cases.

I've introduced recently "read-only" objects (Object>>#isReadOnlyObject and
co). I am waiting for the VM repo merge which should happen in the next few
weeks to have this feature in the default Pharo VM, then I will be able to
compile method literals "read-only" by default. With this feature, the
#at:put: store will fail telling you that you cannot store into a read-only
object, which will solve the common problem, when one does not mutate a
literal on purpose.

Now as in Pharo everything is reflective, it will always be possible to
mark back the literal as "writable", mutate it, and still have this
behavior.

Best,
Clement


On Sat, Jul 9, 2016 at 10:22 PM, Peter Uhnák  wrote:

> Is this normal behavior?
>
> cls := Object subclass: #Something.
>
> cls compile: 'array
> ^ #[1 2 3 4]'.
>
> cls new array. "#[1 2 3 4]"
>
> cls new array at: 1 put: 55.
>
> cls new array. "#[55 2 3 4]"
>
> (cls>>#array) sourceCode "'array
> ^ #[1 2 3 4]'"
>
>
> So I can permanently change the compiled byte array in the method, which
> is weird.
>
> Shouldn't the behavior be either
>
> a) don't change the original byte array
>
> or
>
> b) change the source code
>
> Thanks,
> Peter
>

Re: [Pharo-dev] changing compiled byte arrays

[Clément Bera]

Allright. But the problem happens for any literal you mutate, not only byte
arrays.

For example this one:

foo
#(true nil 10) at: 2 put: 50.
^ #(true nil 10)

Answers... #(true 50 10)

The most common problems are with Array, not ByteArray.

Even worse, it can happen with LargeIntegers, Floats, ScaledDecimal, etc.

Hopefully read-only objects will solve most of the problems.



On Sun, Jul 10, 2016 at 10:51 AM, Peter Uhnák  wrote:

> Thanks for the explanation!
>
> I've this byte array syntax for the first time and I don't think that I
> will be making heavy use of it, so it shouldn't be a too big problem —
> since now I understand the behavior, so I can keep it in mind.
>
> Thanks,
> Peter
>
> On Sun, Jul 10, 2016 at 7:43 AM, Clément Bera 
> wrote:
>
>> This is the normal behavior. You are mutating the method's literal, which
>> becomes different. The instance is per method, so even if you do:
>>
>> foo
>> #[1 2 3] at: 2 put: 50.
>> ^ #[1 2 3]
>>
>> You get #[1 50 3], which is easy to understand in this example, but can
>> be very tricky to understand in some cases.
>>
>> I've introduced recently "read-only" objects (Object>>#isReadOnlyObject
>> and co). I am waiting for the VM repo merge which should happen in the next
>> few weeks to have this feature in the default Pharo VM, then I will be able
>> to compile method literals "read-only" by default. With this feature, the
>> #at:put: store will fail telling you that you cannot store into a read-only
>> object, which will solve the common problem, when one does not mutate a
>> literal on purpose.
>>
>> Now as in Pharo everything is reflective, it will always be possible to
>> mark back the literal as "writable", mutate it, and still have this
>> behavior.
>>
>> Best,
>> Clement
>>
>>
>> On Sat, Jul 9, 2016 at 10:22 PM, Peter Uhnák  wrote:
>>
>>> Is this normal behavior?
>>>
>>> cls := Object subclass: #Something.
>>>
>>> cls compile: 'array
>>> ^ #[1 2 3 4]'.
>>>
>>> cls new array. "#[1 2 3 4]"
>>>
>>> cls new array at: 1 put: 55.
>>>
>>> cls new array. "#[55 2 3 4]"
>>>
>>> (cls>>#array) sourceCode "'array
>>> ^ #[1 2 3 4]'"
>>>
>>>
>>> So I can permanently change the compiled byte array in the method, which
>>> is weird.
>>>
>>> Shouldn't the behavior be either
>>>
>>> a) don't change the original byte array
>>>
>>> or
>>>
>>> b) change the source code
>>>
>>> Thanks,
>>> Peter
>>>
>>
>>
>

Re: [Pharo-dev] Performance of [ * ] repeat vs [ * . true ] whileTrue

[Clément Bera]

On Mon, Aug 15, 2016 at 12:54 AM, John Brant 
wrote:

>
> > On Aug 14, 2016, at 4:42 PM, Henrik Nergaard 
> wrote:
> >
> > Hi,
> >
> > Why  is “[ * ] repeat” almost twice as slow as “[ * . true ] whileTrue” ?
>
> #repeat isn’t optimized by the compiler like #whileTrue is. I don’t know
> if there is a reason for this, but most every other Smalltalk (Squeak, VW,
> & Dolphin) optimize the #repeat method.
>
>
> On Squeak it's optimized by default too.

I had an intern adding that as a bytecode compiler option and make the
decompiler compliant with this. One needs to check if everything still
works fine but it can be enabled. Something like:  should already work.

I think the idea was to keep limited the number of inlined messages, hence
that one is not inlined by default. #timesRepeat: is not inlined either in
Pharo. But then where's the limit between what you inline and what you
don't...


> John Brant
>

Re: [Pharo-dev] GTPlayground/Inspector print it

[Clément Bera]

Hi,

The result of DoIts can be executed as another DoIt to get the same result.
I use this all the time. Some tools also use this.

With your change it is not possible to execute the DoIt result anymore.

Regards

On Wed, Aug 17, 2016 at 10:01 AM, Peter Uhnák  wrote:

> Hi,
>
> does the print-it option always use only asString (or whatever it actually
> uses), or can it be modified in some way?
>
> I would like to modify it a bit, because for big numbers the default one
> is not easy to read, e.g.
>
>
> ​instead, I would like to see this
>
>
> ​It gives much better idea of the scale of the number.
>
> Can such thing be modified?
>
> Thanks,
> Peter
>

[Pharo-dev] Integrations in Pharo for next generation VMs: FullBlockClosure, SistaV1 bytecode set and Read-only objects

[Clément Bera]

Hi everyone,

With the help of multiple people (Marcus Denker, Eliot Miranda and some
more), I introduced over the past year multiple changes in the Pharo image
to support the next generation VMs. It's still a work in progress, but once
issue 19083 will be introduced the bulk of the changes will be in the Pharo
image.

These changes have no impact on developers only reading/writing source code
and analysing/working with the ASTs, but may have impact with people
working with Opal's IR, the bytecode or directly with the BlockClosure and
CompiledMethod instances (People building frameworks like Reflectivity,
using OpalCompiler extensions or people working on object serializers).

Three main changes were introduced:
- Secondary bytecode set support
- Read-only objects
- FullBlockClosure

The secondary bytecode set support allows the image to run on a VM
supporting 2 bytecode sets. Each compiled method has a flag precising which
set it uses. This change allows the image to convert all the methods from
one bytecode set to another one without any bootstrap (only in-image
do-its). The SistaV1 bytecode set was introduced as the second bytecode
set. This bytecode set removes many encoding limitations of the existing
bytecode set, simplifies bytecode decoding and features new instructions
(such as full block closure instructions).

Read-only objects allows one to mark any object as read-only. Any attempt
to mutate a read-only object (primitive operations, instance variable
store) fails, and the programmer can handle the failures with Smalltalk
code. This feature is present with less than 1% overhead in all of our
benchmark suite. In the near future, we plan to have all literals read-only
to allow more aggressive compiler optimizations and avoid literal mutation
inconsistency bugs. This feature can also be used to build efficient object
modification trackers and could be used to improve the performance of part
of the Reflectivity framework. It may break your code if you mutate
literals (Normally you don't).

FullBlockClosures are a new implementation of BlockClosures. They allow
efficient implementation of Blocks, with the Copying block and Clean block
optimizations present in other Smalltalks. They simplify part of the VM,
making Blocks more similar to methods. They also remove many dependencies
between BlockClosure, compiled method and contexts, which will allow us to
implement more aggressive optimizations in the VM in the future. With
FullBlockClosures, the closure's bytecode is present in a separate object
(an instance of compiled block) instead of being inlined in the enclosing
method. This is still confusing some tools. The debugging support of
FullBlockClosure seems however to be complete.

With the issue 19083 integrated and the latest VM compiled with different
settings than the current Pharo VM (MULTIPLEBYTECODESETS true
bytecodeTableInitializer
initializeBytecodeTableForSqueakV3PlusClosuresAndSistaV1 -DIMMUTABILITY 1),
all these features seems to be working in the Pharo image. The goal is to
get all of these features used by default before the Pharo 6 feature freeze
in November. Alternatively I will need to wait many more months (or Pharo
will get unstable and Esteban will scream at me 'No do not integrate that').

If you worry how any of these changes can impact your frameworks, please
answer this thread so we can analyse the potential problems.

Regards,

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

[Clément Bera]

Why don't you just change nautilus to have two text areas, one with the
test corresponding to the method and the other one with the method's code ?

You're saying:
*Their values is active documentation that can be automatically validated.*
That can also be applied to test we've already had with SUnit. If the only
difference you want is to display the test next to the method, then it's an
IDE problem, nothing has to be changed but the IDE.

In python they have no other choices than putting tests in comments because
their IDE is a text editor, they cannot create other panes or anything like
that.

On Fri, Sep 16, 2016 at 1:21 PM, stepharo  wrote:

>
> Hi,
>
> I was thinking on the metro way to work, and I also saw that this
> discussion is actually split in multiple threads, so it was not easy to
> follow :).
>
> Some of my feelings about this:
>
> - Pragmas are nice because they are easy to "interpret". Parsing them is
> already provided. However, putting expressions or long examples into them
> starts to be awkward. It seems it's pushin the syntax too much, isn't it?
>
> - Comments are nice because they are ignored! But right now comments are
> simple plain text. This thread is to convert *some* comments into
> executable examples. But this should be just some comments and not all of
> them, am I right? So what happens when we want to have comments written in
> Pillar for example? What I mean is that having examples is just an example
> of something we would like to do with comments.
>
> But we can also imagine having comment interpreters. Something like this:
>
> ">>>PillarDoc
> !This is a Pillar title
> And I'm just a paragraph
> And I can link a class like @Object.
> "
>
>
> ">>>ExampleDoc
> self assert: '/foo/gloops.taz' asFileReference basename equals:
> 'gloops.taz'
> "
>
>
> We could have for class comment
>
> ">>>UMLDescription
> UMLClass named: 'Visitor'
>
> Arrow from:
>
> But this can start to be complex
> "
>
> What I like from this is that:
>   - comments that do not specify an interpreter are just plain old text.
> Thus backward compatible.
>   - comments that specify an interpreter that is not present, are just
> plain old text. A decoupling as it happens with the settings.
>   - an ExampleDoc interpreter can be just a test case instance, thus we
> could use assertions instead of special >>> messages.
>
> I do not know because all the comments should be pillar compatible.
> If you do not use pillar commands you just get plain text.
> You see we can easily detect comment too: if a text contains >>> then it
> is a doc
>
> Then
> ExampleDoc
> is an extra syntax.
>
> I'm not found with the
> self assert:
> because it feels like something coming out of nowhere. We will have to
> explain: yes self is bound to an instance of the testCase...
> and to me this is implementation details:
> if I give expr1 and expr2 the implementation can build self assert:
> expr1 equals: expr2
>
> I liked the simplicity of nicolai' solution
> I would just have a comment and a message >>> so that we
> => nearly no syntax change
> => something really lightweight and optional
>
>
> What I care is that
>
> - we get simple examples right in the method
> - one line no more.
> - that these examples are correct and always validated (I do not see
> them as tests), their values is more in the correct documentation
> than the tests. They are basic output. I do not want to have full code
> in the method, in that case this should go one class side example
> or plain tests.
>
>
> Things that would require more thought:
>   - there is an overlap between these interpreted comments and pragmas...
> There are for sure cases that solutions can be imagined with both.
>
> I do not think that expressions can fit inside pragmas
>
>   - there is an overlap between examples and test cases. I saw many people
> that argued that already. I am not against examples, but I think we should
> (whichever implementation is chosen) draw a line and set some guidelines.
>
> To me I do not care that they are tests.
> Their values is active documentation that can be automatically validated.
> I do not expect to run them but the system
> can garantee that they are correct.
>
> Stef, probably you have already in mind when you want a test case and when
> an example and what's the distance. It would be good if we can transform
> that implicit thought in something explicit (maybe even a lint rule in the
> future?)
>
> I do not get what you mean here.
>
> For me a test is a scenario.
> If I do that and that then this happens
> a test can use a class example
>
> Now for me a test should not rely one a online part of method comment.
>
> These onliners are just make the method comments better.
>
>
>
>
>
> Guille
>
>  Original Message 
>
> Hi nicolai
>
>
> I was thinking that I would prefer to have
>
>
> "` '/foo/gloops.taz' asFileReference basename -> 'gloops.taz'.`"
>
>
> instead of
> ` '/foo/gloop

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

[Clément Bera]

On Sat, Sep 17, 2016 at 8:18 AM, Tudor Girba  wrote:

> Hi,
>
> > On Sep 16, 2016, at 8:37 PM, stepharo  wrote:
> >
> > + 1
> >
> > Changing the language metamodel for simple validated comments is a huge
> effort for nothing.
> > Clement is good at VM level but not at other level :)
>
> I think there is a misunderstanding :). I do not see any implication to
> the language meta-model in the remark of Clement.
>
> In fact, I expressed exactly the same opinion, that the design of things
> like PythonDoc comes from the fact that those people do not rely on an IDE,
> so their design focuses on the only thing they have: source code. Clement
> remarked that we already have SUnit tests and he suggested that we could
> just enhance the IDE to present them next to the methods. This might
> actually be less straightforward with SUnit because it was not made for
> preserving links to the code, but it can work out of the box with something
> like GTExamples.
>

Yes, the language meta-model is already too complex in Pharo IMHO, let's
not make it even more complex. I should have precised that's not what I
meant if this was not obvious to everyone.

*1. Method docs with examples, so a user can see an example usage of a
method (sunit test methods sometimes aren't good "examples")*
*2. We already had (and still have) some method docs where the example code
just won't work anymore because the methods or classes used*

Nicolai,

I'm suggesting to show the SUnit test code (or example code, or whatever)
next to the method, and being able to create a unit test this way instead
of only the existing green/red button and the "browse tests" entry in the
right click menu. For existing methods having in their comment executable
code to test how they work (as you mentioned), the code can just be moved
to the test shown in the pane next to it (through a script discovering all
cases like that or manually).

The example usage would still be shown next to the code for the user,
except it would already be under version control as existing SUnit tests
are, it can now have syntax coloring which is not present in comments, it's
automatically executed by each Pharo build through SUnit hence detecting
regressions and the meta-model is not getting more complex at all. As Tudor
said, it's only about IDE changes.

I believe that some SUnit tests are sometimes not good examples because
they're higher level tests (application tests, business tests) while as for
python doctests it's only relevant to show unit tests next to the method
the unit test validates. Currently I believe Nautilus discovers tests and
add the green/red button based on name conventions. Foo>>bar has this
feature if FooTests>>testBar is implemented. So it's either a matter of
improving this heuristic or educating the community with this existing name
convention. In any case, I don't think it's more changes for the user than
having to learn convention in the comments/pragmas.





> Cheers,
> Doru
>
>
> > Stef
> >
> > Le 16/9/16 à 14:18, Denis Kudriashov a écrit :
> >>
> >> 2016-09-16 13:42 GMT+02:00 Clément Bera :
> >> Why don't you just change nautilus to have two text areas, one with the
> test corresponding to the method and the other one with the method's code ?
> >>
> >> You're saying:
> >> Their values is active documentation that can be automatically
> validated.
> >> That can also be applied to test we've already had with SUnit. If the
> only difference you want is to display the test next to the method, then
> it's an IDE problem, nothing has to be changed but the IDE.
> >>
> >> In python they have no other choices than putting tests in comments
> because their IDE is a text editor, they cannot create other panes or
> anything like that.
> >>
> >> It is of course true. But Stef suggestion is really much much simpler.
> It is just convention how to write examples inside comments. Then tools
> could work with them and Nicolai already provide simple extension for
> Nautilus.
> >> We already has a lot of comments with examples inside. Making them
> discoverable and testable will be nice.
> >>
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Yesterday is a fact.
>  Tomorrow is a possibility.
>  Today is a challenge."
>
>
>
>
>
>

Re: [Pharo-dev] SharedPool method definitions do not resolve Class names

[Clément Bera]

Are SharedPool supposed to be instantiated ? Why did you need to
instantiate a SharedPool ?

I only use them (maybe mistakenly) by setting with class-side methods the
default values of the SharedPool class variables, then use the
poolDictionary: keyword to access those variables values from other
classes. I thought that was the only way they should be used. Please
explain me the other use-cases for a shared pool.




On Tue, Sep 20, 2016 at 10:38 AM, Nicolai Hess 
wrote:

>
>
> 2016-09-19 16:02 GMT+02:00 Ben Coman :
>
>> This is probably my lack of understanding but I found this surprising
>> behaviour
>>
>> I was trying to add a method to a subclass of FFIExternalEnumeration
>> and it was not recognising classes.  I traced this back to SharedPool
>> which can be demostrated by trying to save the following method...
>>
>> SharedPool >> test1
>> ^Object
>>
>>
>> reports... "Unknown variable: Object please correct, or cancel:"
>>
>>
>> Any insights?
>>
>
> I think it is a bug. SharedPool implement some special lookup to make the
> SharedPool variable lookup work. But it seems this conflicts with the
> variable lookup for
> globals.
>
>
>> cheers -ben
>>
>>
>

Re: [Pharo-dev] macOS Sierra support

[Clément Bera]

On Tue, Sep 27, 2016 at 11:43 AM, Max Leske  wrote:

> Hi Sven,
>
> An experimental build of the VM works again on Sierra (I’ve tested this
> one: https://bintray.com/estebanlm/pharo-vm/build/201609201407#files).
> The problem was with the bundle code and a change from Apple’s side to
> Cocoa. The new VM is a Spur VM of course. If you need a Cog VM, you can try
> a Squeak VM (e.g.  'Croquet Closure Cog VM [CoInterpreterPrimitives
> VMMaker.oscog-eem.1095] Squeak Cog 4.0.3282’) or run the current PharoVM in
> a virtual machine on Linux (as I’ve done).
>
> Concerning Fuel: the versioning problem is a known and big issue I have to
> admit. Which Fuel versions does your problem concern? There were some big
> changes for Fuel from Pharo 4 to 5, e.g. MethodContext was renamed to
> Context. Depending on the objects you store however, you may be able to
> load the file simply by removing the version check in Fuel, as most things
> should be identical.
>
>
>From Pharo 5 to Pharo 6, likely there will be the change from BlockClosure
to FullBlockClosure that will have some impact... We'll keep for Pharo 6
the BlockClosure support for migration purpose then.



> Cheers,
> Max
>
>
> On 27 Sep 2016, at 11:26, Sven Van Caekenberghe  wrote:
>
>
> On 27 Sep 2016, at 11:21, Norbert Hartl  wrote:
>
> Sven,
>
> Am 27.09.2016 um 11:15 schrieb Sven Van Caekenberghe :
>
> PS2: Another really annoying problem is the following: he saved all his
> (really important) scripts using Script Manager as a FUEL. Moving between
> 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really
> not cool, why would a newer FUEL not be able to read older FUEL. He ended
> up copying string data by opening the binary FUEL file in a text editor.
>
>
> it is like that from the beginning. I guess there was the fear keeping
> everything compatible would be a huge amount of work. But it is indeed an
> annoying thing. The usual way to deal with it is open pharo4 and
> materialize the fuel file then upgrade fuel to the version pharo5 uses and
> save again.
>
> Norbert
>
>
> Yeah, but this is silly: it goes against the principle of a persistence
> format: to save data for future use. [ I knew this already, I never agreed
> with this principle ].
>
> Like I described in the email, after upgrading, we were unable to run the
> old image - catch 22.
>
>
>
>
>

Re: [Pharo-dev] Getting Pharo to Mars?

[Clément Bera]

The first thing is to get naturalised as a US citizen.

It seems that the space market has been opened to private companies in the
US, but they're still quite skeptical about sharing knowledge with non
american citizens. If you want to work with Space X, you have either to be
an american citizen or have something they really really really want to
convince them to work with you (and even so, it's likely your native
country matters).

Quoting their website:

*To conform to U.S. Government space technology export regulations,
applicant must be a U.S. citizen, lawful permanent resident of the U.S.,
protected individual as defined by 8 U.S.C. 1324b(a)(3), or eligible to
obtain the required authorizations from the U.S. Department of State. Learn
more about ITAR here.*



On Thu, Sep 29, 2016 at 6:27 AM, p...@highoctane.be 
wrote:

> Given
>
> http://waitbutwhy.com/2016/09/spacexs-big-fking-rocket-the-full-story.html
>
> we should find some way to get Pharo into it somehow.
>
> Anyone having ideas on how to do that?
>
> Phil
>

Re: [Pharo-dev] testing sista

[Clément Bera]

Hi.

*In short: *
normally you don't, but for some reasons right now you do. Try a VM from
here  [1].

*In long:*
Normally you need a VM with the following slang to C compilation settings:
MULTIPLEBYTECODESETS true
bytecodeTableInitializer
initializeBytecodeTableForSqueakV3PlusClosuresSistaV1Hybrid
which has been added recently to multiple VM builds, including the Pharo
build if I am correct.

The latest Pharo VM on files.pharo.org answers true to "Smalltalk vm
supportsMultipleBytecodeSets", so it should be fine...
But, when I tried to run code with new bytecode set, it does not work
indeed.

So...
I've just compiled another VM to check and it could run the image.
I've just checked with the VM from openSmalltalk
 [1] and both
pharo.cog.spur and squeak.cog.spur could run the Pharo image with both
bytecode set and full blocks.
It's not clear pharo.cog.spur is a complete Pharo VM as the migration
process to opensmalltalk VM is still in progress, it may be a squeak VM
with part of the extra Pharo plugins.

I believe something is temporarily wrong during the opensmalltalk pharo vm
migration. I would recommend to use a VM from bintray to test those
features until the migration is over.
On the openSmalltalkVM git
 [2] you have a link by
clinking "download" to the latest bintray releases. Those releases are
built automatically and very frequently.

[1] https://bintray.com/opensmalltalk/vm/cog/201609292318#files/
[2] https://github.com/OpenSmalltalk/opensmalltalk-vm

On Fri, Sep 30, 2016 at 2:54 PM, Nicolai Hess  wrote:

> Do we need a special vm for testing sista bytecode backend?
> I enabled sista in the compiler settings and evaluating
>
> [ ] class
>
> crashes the vm.
>
>
> nicolai
>

Re: [Pharo-dev] [ANN] Sparta v1.1

[Clément Bera]

On Fri, Oct 21, 2016 at 3:41 PM, Tudor Girba  wrote:

> Hi Clement,
>
> Thanks for raising this question.
>
> In short, Sparta is inspired from Athens and it has a similar structure.
> So, there is an in-image interface of the canvas, and there is a concrete
> implementation through the plugin (based on Moz2D). To target a completely
> in-image rendering, it is certainly possible to implement a BitBlt backend
> of the Sparta canvas. To implement this part, we would need help.
>
> The goal is indeed to have only one canvas in the default Pharo
> distribution: Sparta. However, this will not happen suddenly. Ideally, when
> Pharo 6 will be released, there will be a beta version of Sparta + Bloc +
> some tools that will be loadable externally. Then my guess is that it will
> still take another year until we get the full development environment
> working on top of Sparta. So, it is to be expected that this transition
> will take at least 1.5 years during which time Athens will still provide
> the option of running on top of BitBlt.
>
> Does this answer the concern?
>

It does. I understand a BitBlt back-end is possible to have UI applications
running on a low memory footprint runtime. Now the question the community
should answer is if we want to implement and maintain that back-end or not.


> But, now my question: Would it not be possible to get the VM to not open a
> window when in headless mode?
>

I would love to see that. It's theoretically possible, it's just a matter
of doing it and integrating it while it's time-consuming. I believe there
was some work in that direction as part of the SDL / OSWindow work.

If the community wants to move to Sparta and does not care if the memory
footprint is increased by 5 Mb for non headless application, it may make
sense to invest in that direction instead of the implementation and
maintenance of a BitBlt based back-end.


>
> Cheers,
> Doru
>
> > On Oct 21, 2016, at 2:23 PM, Clément Bera 
> wrote:
> >
> >
> >
> > On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel 
> wrote:
> > Hi Stéphane
> >
> > Indeed, build is broken :)
> > Yesterday I took a very brief look at bloc and can confirm that
> development version is loadable in Pharo 6 and is completely Sparta based.
> (all examples work for me)
> >
> > You are right, live environment on embedded systems is great goal to
> achieve. Sparta must not prevent pharo from getting there. It is true that
> plugin is relatively big (windows 7mb, osx 15mb, linux 18mb). However, it
> is all-in-one build and size can be reduced dramatically.
> >
> > As I understand, Pharo for PC should not make any assumptions about
> user's hardware. If gpu accelerated backend can not be used there should be
> still a performant fallback backend which also needs a fallback that is
> guaranteed to work even on Personal Calculators. (Taschenrechner). That is
> why library is so big. For example for mac and windows Sparta is shipped
> with 3 (!) backends that together build fallback chain, for instance on
> windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia
> reduces binary size from 15mb to 10mb. Removing GL package and leaving only
> software backends may reduce size even more.
> >
> > It is a bit different on embedded systems, since hardware configuration
> is already known and there is no need to have so many fallback backends.
> Library itself allows developers to add new exotic backends quite easily.
> >
> > Let's take Pharo6 for mac. It is shipped with the following libs:
> > Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb
> >
> > Moz2D is self contained and does not require any additional libs.
> > Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ?
> (estimate around 6-7mb).
> >
> > As you can see we get almost the same numbers :)
> >
> > Yeah but none of the libs (Cairo, Pixman, FreeType) are required to run
> Pharo, they're required only if you use them. I compile VMs without such
> libraires and Pharo works just fine as a development environment and for
> simple things like web servers. The Squeak VM for example have around 2Mb
> footprint in total, including 1Mb for the C runtime (initialized and
> uninitialized data, executable code) and 1 Mb for the machine code zone and
> can run most Pharo features just fine, including for examples web services
> and the IDE.
> >
> > Right now the VM cannot start completely headless, the headless mode
> just hides the main window, so if the main window start-up depends on
> Sparta, it's not possible to run Pharo headless without many Mb of memory
> footprint.
> >
> > Which leads 

Re: [Pharo-dev] roundTo: strange behavior

[Clément Bera]

I think the right way to solve these issues is not to think about it like a
Math problem.

We need to write tests showing bugs and doing lots of coverage.

Then, we can look into other programming languages (Java, Ruby, Python,
etc), port an implementation and ensure it's correct.

This is the kind of things where people have spent days to get right and
efficient. The goal is not to figure how to do it better but how to port
the best implementation out there.

On Wed, Oct 26, 2016 at 9:58 AM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

>
>
> 2016-10-26 9:14 GMT+02:00 stepharo :
>
>> Hi nicolas
>>
>> So what is the solution? We can integrate fast a solution.
>> I would really like to see them fix in Pharo 60.
>> I'm writing a book for newbie and this is the third time I change one
>> chapter
>> so may be I should stop and throw away this chapter.
>>
>>
> 1) for Fraction:
>
> round: numberOfWishedDecimal
> v := 10 raisedTo: numberOfWishedDecimal.
> ^ ((self * v) rounded / v) asFloat
>
> or just replace asFloat if you wish to remain exact:
>
> round: numberOfWishedDecimal
> v := 10 raisedTo: numberOfWishedDecimal.
> ^ ((self * v) rounded / v) asScaledDecimal: numberOfWishedDecimal
>
> 2) for Float, it is in 15471:
>
> round: numberOfWishedDecimal
> | v maxNumberOfDecimals |
> maxNumberOfDecimals := self class precision - 1 - (self exponent max:
> self class emin).
> maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self].
> v := 10 raisedTo: numberOfWishedDecimal.
> ^ ((self asFraction * v) rounded / v) asFloat
>
> or if Fraction already answers a Float:
>
> round: numberOfWishedDecimal
> | maxNumberOfDecimals |
> maxNumberOfDecimals := self class precision - 1 - (self exponent max:
> self class emin).
> maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self].
> ^ self asFraction round: numberOfWishedDecimal
>
> It's slower than current implementation, but will round exactly to the
> nearest Float.
> It's possible to have faster implementation up to 22 decimals if you
> provide a fused-multiply-accumulate primitive...
>
>
> You see I'm not good in math so even if I try hard I will not have a good
>> solution.
>> This is the same for marcus and most people in our team.
>> I reopened these issues.
>>
>> Stef
>>
>>
>>
>> 2016-10-25 23:22 GMT+02:00 stepharo :
>>
>>> Ok for the advice
>>>
>>> Now round: aNumberOfDigits seems to work fine.
>>>
>>> Stef
>>>
>>>
>> No it's not, but issues are timing out too fast ;)
>> https://pharo.fogbugz.com/f/cases/15471/Can-t-round-Float-fm
>> ax-to-2-decimal-places
>> https://pharo.fogbugz.com/f/cases/15472/Fraction-rounding-to
>> -n-decimal-places-is-inexact
>> https://pharo.fogbugz.com/f/cases/15473/Float-round-to-n-dec
>> imal-places-is-not-in-agreement-with-printShowingDecimalPlaces
>>
>> I hate to say that, but try in python, they got it right...
>>
>>
>>
>>> Le 25/10/16 à 11:05, Henrik Johansen a écrit :
>>>
>>> +1.
>>>
>>> Unless you're dealing with fixed precision* entities, it's usually
>>> better to specify digits to display in printing methods themselves
>>> (#printShowingDecimalPlaces: & friends in base image).
>>> As per previous discussions around this that arise every second year or
>>> so, rounding the number itself (as long as we're dealing with floats) will
>>> never work as you want reliably.
>>>
>>> Cheers,
>>> Henry
>>>
>>> * And in that case, you'd use ScaledDecimals
>>>
>>> On 23 Oct 2016, at 7:08 , p...@highoctane.be wrote:
>>>
>>> I use the Printf package for that.
>>>
>>> v := 65.456.
>>> 'With 2 decimal digits: %5.2f, or 3 like this: %6.3f'
>>> printf: {v. v}.
>>>
>>> With 2 decimal digits: 65.45, or 3 like this: 65.456
>>>
>>> It is in http://www.smalltalkhub.com/#!/~philippeback/HOExtras
>>>
>>> Printf
>>>
>>> I am just used to C printf and well, I like the way it works.
>>>
>>> Phil
>>>
>>>
>>>
>>
>>
>

Re: [Pharo-dev] Accessing Virtual machine internal?

[Clément Bera]

Yes.

Evaluate "Smalltalk vm parameterAt: 46" it should get you the machine code
zone size.

You can look into the comment in the VirtualMachine class or in
VirtualMachine>>getParameters method comment to see what VM internal is
available.

On Nov 7, 2016 19:37, "Alexandre Bergel"  wrote:

> Hi!
>
> Is there a way to get access to the VM internals? For example the size of
> the method cache and the number of JIT-compiled methods?
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] OpalEncoderForV3PlusClosures error

[Clément Bera]

On latest VM from opensmalltalk you can switch to the SistaV1 encoder which
solves this problem.

On Nov 10, 2016 23:31, "Thierry Goubier"  wrote:

>
>
> 2016-11-10 17:28 GMT+01:00 Max Leske :
>
>> Too many statements probably (e.g. a lot of branches).
>>
>
> I suspected that. Many, many loops over arrays of arrays of arrays of
> float, no branches.
>
> Thierry
>
>
>>
>> Max
>>
>> > On 10 Nov 2016, at 17:11, Thierry Goubier 
>> wrote:
>> >
>> > I've got a compilation error which is:
>> >
>> > genJumpLong: distance index -1504 is out of range -1024 to 1023
>> >
>> > What does it mean? I'm on Pharo6 64 bits.
>> >
>> > Thierry
>>
>>
>>
>

Re: [Pharo-dev] Performance difference between Pharo 32bits and 64bits

[Clément Bera]

Hi Thierry,

On the speed center you can compare 32 bits and 64 bits linux VMs:
http://squeak.org/codespeed/

Normally Pharo 64 should be overall slightly slower than Pharo 32 because
70% of the memory is used for pointers, implying twice more data to process
by the processor for pointer operations. Specific things, for example
SmallFloat arithmetic, should however be faster on 64 bits.

For numerical code, benchs can be faster for two main reasons:
- the bench uses SmallFloat instead of BoxedFloat for most floats it uses
in 64 bits
- the bench overflows the 31bits signed integer range for SmallIntegers,
leading to the usage of LargeInteger in 32 bits, while it does not overflow
the 61 bits signed integer range in 64 bits. This is typically the case for
int32 benchs.

Other numerical benchs may be faster on 32 bits.


On Mon, Nov 14, 2016 at 4:04 PM, Thierry Goubier 
wrote:

> Has anybody seen performance differences between the 32bits and the 64bits
> versions of Pharo 6 ?
>
> I'm seeing a speedup greater than 2 on some intensive numerical code.
>
> Note that, on that code, Pharo 64bits is slower than R, by around 30%. The
> code overall is memory bound.
>
> Thierry
>
>
>

Re: [Pharo-dev] Windows 64 bits VM?

[Clément Bera]

There is a Stack VM (VM without JIT) for Windows 64 working. It works since
yesterday so it's not integrated in automated builds and you need to
compile it yourself.

On Wed, Nov 16, 2016 at 12:01 AM, Gabriel Cotelli 
wrote:

> Hi,
> Is there a Windows 64 bits VM ready to test? I couldn't find one, just the
> MacOs and Linux versions.
>
> Regards,
> Gabriel
>
>

Re: [Pharo-dev] About ~= and ~~

[Clément Bera]

Hi

Do you mean you want to add this pragma "" in Object >> #~~
?

Or do you mean replacing #blockCopy: by #~~ in the special selectors to get
it inlined by default like #== ?


On Wed, Nov 23, 2016 at 2:39 PM, Aliaksei Syrel 
wrote:

> Hi
>
> It is been a while...
> So, do we want to replace ~~ with a primitive? :)
>
> Cheers
> Alex
>
>
>
> --
> View this message in context: http://forum.world.st/About-
> and-tp3898409p4924391.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

[Clément Bera]

On Mon, Dec 5, 2016 at 8:51 AM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

> Translate AST to byte codes?
> One for the case when we don't care of the result (we will pop it off the
> stack), we just want the effect.
> The other case when we want to keep the resulting value on the stack.
>

It translates AST to Opal's IR.

And yes one uses one or the other if one wants only the effect and don't
care about the result or if one cares about the result and the effect.


>
> 2016-12-05 8:47 GMT+01:00 Nicolai Hess :
>
>> Hi,
>>
>> I need a short description for what the OCASTTranslator subclasses
>> OCASTTranslatorForEffect
>> OCASTTranslatorForValue
>> are.
>>
>> I don't fully understand the usage.
>>
>> thanks in advance
>> Nicolai
>>
>>
>

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

[Clément Bera]

Both are used for each compilation. They're instance variables of each
other.

| *Who decides which to use*

In each AST node translation, you know for each value which one to use.

For example, when translating a return, the value to return needs to be
pushed on stack, so the valueTranslator is used:
visitReturnNode: aReturnNode
valueTranslator visitNode: aReturnNode value.
methodBuilder returnTop.

Yet, in #visitMethodNode:, you can see that the effectTranslator is used,
because no value is pushed on stack at the end of the method body:
...effectTranslator visitNode: aMethodNode body...

Then some behavior can be conditional, for example, in OCASTTranslator >>
#visitArrayNode:
...^ self visitLargeArrayNode: anArrayNode ]...
The self here represents either the value or effect translator and
dispatches to the correct method using polymorphism.

*| when do I know that I need to use ?*

If you need the value on stack, use the valueTranslator.
If you need the effect but not the value, use the effectTranslator.

If you're implementing something in the valueTranslator, it needs to push
something on stack at the end.
If you're implementing something in the effectTranslator, it doesn't push
anything on stack at the end.

| * the effect translator only or the value translator?*

I think you always need both.Let's take this method:

MyClass>>return1
 ^ 42.0

The method uses the effect translator to translate is body (^ 42.0).
The body is a sequence node, with one statement only. A sequence node
translates all its statements for effect, except the last one which depends
on how it's called (in this case, it's called with the effectTranslator, so
it's also for effect). Sequence translated for value are used in inlined
control structures.
So the first statement is translated for effect.
The return node asks first the value translator to push the float (42.0) on
stack, generating pushLiteral: 42.0
Then the return node generates the returnTop instruction.

**

I don't know how to explain better. I like to think of this problem as the
difference between procedures and functions in old programming languages.

On Mon, Dec 5, 2016 at 9:36 AM, Nicolai Hess  wrote:

>
>
> 2016-12-05 8:51 GMT+01:00 Nicolas Cellier  gmail.com>:
>
>> Translate AST to byte codes?
>>
>
> (For opal, this first creates the intermediate representation (IR), but
> yes translating from AST to (finally) byte codes)
>
>
>> One for the case when we don't care of the result (we will pop it off the
>> stack), we just want the effect.
>>
>
> Ok.
>
>
>> The other case when we want to keep the resulting value on the stack.
>>
>
> Who decides which to use, when do I know that I need to use, the effect
> translator only or the value translator?
>
>
>>
>> 2016-12-05 8:47 GMT+01:00 Nicolai Hess :
>>
>>> Hi,
>>>
>>> I need a short description for what the OCASTTranslator subclasses
>>> OCASTTranslatorForEffect
>>> OCASTTranslatorForValue
>>> are.
>>>
>>> I don't fully understand the usage.
>>>
>>> thanks in advance
>>> Nicolai
>>>
>>>
>>
>

Re: [Pharo-dev] genJumpLong: distance index 1043 is out of range -1024 to 1023

[Clément Bera]

Hi,

This will be fixed by using the alternative bytecode set, likely in the
next few weeks in Pharo 6 alpha/beta. Basically control flow messages
(ifTrue:, to:do:, etc.) cannot have too many statements in their blocks
(ifTrue: argument, to:do: second arguments, etc) or the compiler can't
compile them due to bytecode set encoding limitation. The new bytecode set
is encoded differently and allows such code to be compiled.

As a temporary solution, you need to split your code in multiple methods to
lower the number of statements inside blocks inside control flow messages.

Sorry for the annoyance. We're working on integrating a solution and we
believe that this will be integrated in Pharo 6 in the next few weeks.

Regards,

Clement

On Wed, Dec 7, 2016 at 4:14 PM, Davide Varvello via Pharo-dev <
pharo-dev@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Davide Varvello 
> To: pharo-dev@lists.pharo.org
> Cc:
> Date: Wed, 7 Dec 2016 07:14:35 -0800 (PST)
> Subject: genJumpLong: distance index 1043 is out of range -1024 to 1023
> Hi,
>
> Sometimes (and also today) after formatting and saving a method, an Error
> is
> thrown.
> Following a chunk of PharoDebug.log
>
> TIA
> Davide
>
>
> -
> THERE_BE_DRAGONS_HERE
> Error: genJumpLong: distance index 1043 is out of range -1024 to 1023
> 7 December 2016 4:21:53.0426 pm
>
> VM: Mac OS - intel - 1096 - CoInterpreter
> VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid:
> 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016
> StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880
> uuid:
> 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016
> https://github.com/pharo-project/pharo-vm.git Commit:
> 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200
> By:
> GitHub  Jenkins build #603
>
> Image: Pharo5.0 [Latest update: #50763]
>
> OpalEncoderForV3PlusClosures(Object)>>error:
> Receiver: an OpalEncoderForV3PlusClosures
> Arguments and temporary variables:
> aString:'genJumpLong: distance index 1043 is out
> of range -1024 to 1023'
> Receiver's instance variables:
> stream: an IRBytecodeGenerator
> position:   nil
> rootNode:   nil
> blockExtentsToLocals:   nil
>
>
> OpalEncoderForV3PlusClosures(OpalBytecodeEncoder)>>
> outOfRangeError:index:range:to:
> Receiver: an OpalEncoderForV3PlusClosures
> Arguments and temporary variables:
> string: 'distance'
> index:  1043
> rangeStart: -1024
> rangeEnd:   1023
> Receiver's instance variables:
> stream: an IRBytecodeGenerator
> position:   nil
> rootNode:   nil
> blockExtentsToLocals:   nil
>
>
> OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJumpLong:
> Receiver: an OpalEncoderForV3PlusClosures
> Arguments and temporary variables:
> distance:   1043
> Receiver's instance variables:
> stream: an IRBytecodeGenerator
> position:   nil
> rootNode:   nil
> blockExtentsToLocals:   nil
>
>
> OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJump:
> Receiver: an OpalEncoderForV3PlusClosures
> Arguments and temporary variables:
> distance:   1043
> Receiver's instance variables:
> stream: an IRBytecodeGenerator
> position:   nil
> rootNode:   nil
> blockExtentsToLocals:   nil
>
>
>
> --
> View this message in context: http://forum.world.st/
> genJumpLong-distance-index-1043-is-out-of-range-1024-to-
> 1023-tp4926103.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>
>

Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?

[Clément Bera]

Hi Igor.

People at Mines de douai were working on Pharo with ROS. Contact Luc
Fabresse or Noury Bouraqadi, people like Santiago, Guillermo polito or Nick
Papoulias may also be aware of the work. I don't know what was done
exactly.

Have fun.



On Thu, Dec 22, 2016 at 9:38 PM, Igor Stasenko  wrote:

> Hi,
>
> i wonder, are there any projects to run/connect Pharo with ROS(robot
> operating system)
> i'm interested in any bits, starting from basic ones,
> since i'm gonna to work with it in closest future, so would be nice to use
> Pharo
> & stand on a shoulders of others, of course, to learn it fester and
> understand it better.
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-dev] PharoSpur32Vm

[Clément Bera]

Hi,

I believe they're built from* https://github.com/OpenSmalltalk/vm
* using travis and appveyor. On the
gitbhub readme there are relevant links. All built artifacts are also kept
on bintray for history.



On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess  wrote:

> Where are the latest Pharo-spur-vms (32bit) are built?
> I don't see them on the build server, only the buildresults at
> http://files.pharo.org/vm/pharo-spur32/linux/
>
> The latest builds on the buildserver are from the last year only.
>
> nicolai
>

Re: [Pharo-dev] About more precise default exception?

[Clément Bera]

I agree this exception should be more specific.

By the way one needs to update all the primitive mutating objects, such as
at:put:, so that when it fails because it attempts to mutate a read-only
object a proper error is raised instead of SubscriptOutOfBounds with an
in-bound index.

Maybe an intern can create a specific error for your case, add an error for
read-only object and write / update tests for everything.

On Sun, Jan 22, 2017 at 6:28 PM, stepharong  wrote:

> When I read that, I thought that errorNotIndexable would raise an
> Exception different from Error.
> But this is not the case and it means that people should write not so good
> tests by checking Error
> instead of a concrete Exception.
>
> [[[
> MyExampleSetTest >> testIllegal
> self should: [ empty at: 5 ] raise: Error.
> self should: [ empty at: 5 put: #zork ] raise: Error
> ]]]
> We even have a rule that states that we should not catch on Error
>
>
> at: index
> "Primitive. Assumes receiver is indexable. Answer the value of an
> indexable element in the receiver. Fail if the argument index is
> not an
> Integer or is out of bounds. Essential. See Object documentation
> whatIsAPrimitive. Read the class comment for a discussion about
> that the fact
> that the index can be a float."
>
> 
> index isInteger ifTrue:
> [self class isVariable
> ifTrue: [self errorSubscriptBounds: index]
> ifFalse: [self errorNotIndexable]].
> index isNumber
> ifTrue: [^self at: index asInteger]
> ifFalse: [self errorNonIntegerIndex]
>
> thoughts comments?
>
>

[Pharo-dev] Collections and Kernel

[Clément Bera]

Hi everyone,

As I am working on an optimising JIT compiler for the Cog VM written in
Smalltalk and partly running in the Smalltalk runtime, I am very careful
about dependencies. I would like to limit the dependencies of the optimiser
to the Kernel.

The main problem I have is that there are no collections in the Pharo
Kernel except MethodDictionary and DependentsArray. The optimiser depends
on Array, ByteArray, OrderedCollection, Set and Dictionary which are not
part of the Kernel.

The second problem is that there are lots of things in the Kernel that the
optimiser do not depend on even though everything is in the Kernel package,
for example, the optimiser does not depend on anything related to
Time/Chronology, on Numbers other than SmallIntegers or Protocol logic.

This leads to questions. I know that with the bootstrap incoming, some
people have answers to these questions, but I would like to the
conversation happening on the mailing list so everyone can contribute.

Question 1) Is there any plan to make a 'Kernel-Collection' package, which
includes Array, ByteArray, OrderedCollection, Set and Dictionary, but not
the rest of the collections ?

Question 2) Is there any plan to split the Kernel (or maybe the Kernel and
all its dependencies ?) into smaller pieces, for example 'KernelCore',
which includes the existing Kernel *but* other Numbers than SmallIntegers,
Protocol logic and Time Chronology, which could be moved to
'KernelExtended' or something like that ?

I understand that those problems are not easy, but I would like to know if
there is a generic plan so I can correctly decide on what dependencies I
can have or not.

Thanks, cheers,

Re: [Pharo-dev] Collections and Kernel

[Clément Bera]

On Mon, Jan 23, 2017 at 3:55 PM, Pavel Krivanek 
wrote:

> I do not think that to have the package "Kernel" as the smallest system
> subset is the good way to go. The minimal system should be a set of
> well-structured packages so it still makes sense to have packages like
> Collections-* where some of them are supposed to be mandatory and others
> optional.
>
> So:
> 1) not in that form
>
2) Kernel package deserves better modularization but in that case names
> will be like Kernel-*
>
>
Ok.

The problem with the names Collections-* and Kernel-* is that pkg-*
currently means a different package tag inside a package and not a
different package, while the dependency analyser tool analyse dependencies
on packages not package tags.

Right now it's difficult for me to keep the dependencies right for my
package as the dependency analyser tool shows me a dependency on the whole
Collection and Kernel packages while I need to enforce a dependency to a
subset of these 2 packages.

Now that I read my mail again I think the problem is not with the packages
but with the dependency analyser tool. I should define a set of classes and
enforce my package to depend only on those classes as the current packages
are too wide and they won't be split in a way I need in the near future.

Cheers



> But of course we should discuss the best approach.
>
> Cheers,
> -- Pavel
>
>
>
> 2017-01-23 15:36 GMT+01:00 Clément Bera :
>
>> Hi everyone,
>>
>> As I am working on an optimising JIT compiler for the Cog VM written in
>> Smalltalk and partly running in the Smalltalk runtime, I am very careful
>> about dependencies. I would like to limit the dependencies of the optimiser
>> to the Kernel.
>>
>> The main problem I have is that there are no collections in the Pharo
>> Kernel except MethodDictionary and DependentsArray. The optimiser depends
>> on Array, ByteArray, OrderedCollection, Set and Dictionary which are not
>> part of the Kernel.
>>
>> The second problem is that there are lots of things in the Kernel that
>> the optimiser do not depend on even though everything is in the Kernel
>> package, for example, the optimiser does not depend on anything related to
>> Time/Chronology, on Numbers other than SmallIntegers or Protocol logic.
>>
>> This leads to questions. I know that with the bootstrap incoming, some
>> people have answers to these questions, but I would like to the
>> conversation happening on the mailing list so everyone can contribute.
>>
>> Question 1) Is there any plan to make a 'Kernel-Collection' package,
>> which includes Array, ByteArray, OrderedCollection, Set and Dictionary, but
>> not the rest of the collections ?
>>
>> Question 2) Is there any plan to split the Kernel (or maybe the Kernel
>> and all its dependencies ?) into smaller pieces, for example 'KernelCore',
>> which includes the existing Kernel *but* other Numbers than SmallIntegers,
>> Protocol logic and Time Chronology, which could be moved to
>> 'KernelExtended' or something like that ?
>>
>> I understand that those problems are not easy, but I would like to know
>> if there is a generic plan so I can correctly decide on what dependencies I
>> can have or not.
>>
>> Thanks, cheers,
>>
>
>

Re: [Pharo-dev] Immutability support

[Clément Bera]

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

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

Hi Norbert,

Thank you very much for looking read-only objects.

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

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

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

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

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

Best,

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

Clement






>
> Norbert
>

Re: [Pharo-dev] Immutability support

[Clément Bera]

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

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

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

Re: [Pharo-dev] Immutability support

[Clément Bera]

Hi again.

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

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

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

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

Re: [Pharo-dev] Immutability support

[Clément Bera]

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

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

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


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

Re: [Pharo-dev] Immutability support

[Clément Bera]

I introduced the method #supportsWriteBarrier in Pharo 6.

You can backport it if you want:

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

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



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

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

Re: [Pharo-dev] Immutability support

[Clément Bera]

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

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

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

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

Re: [Pharo-dev] Immutability support

[Clément Bera]

Norbert,

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

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

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



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

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

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

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

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


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