Re: [Pharo-users] Traits, method flatten

[Nicolai Hess]

I am interested, and I  think I already looked at this issue, I vaguely
remember, that this has
something to do with the determination of the origin of a method (trait
methods that are from another trait
are wrongly recognized as (trait)local methods).

2017-04-13 8:37 GMT+02:00 Hilaire :

> Hi,
>
> If anyone with deep knowledge on Monticello wants to give a look with
> this bugs on Traits, I can share privately an image exposing the
> problem. Just mail me at hilaire [AT] drgeo.eu
>
> Thanks
>
> Hilaire
>
> Le 12/04/2017 à 14:08, Hilaire a écrit :
> > Investigating a bit on the mater, here is the conduct:
> >
> > - In a fresh 5.0, find an a version of my package where the Traits logic
> > is not compromised (All traits methods are not duplicated in the classes
> > using the traits)
> >
> > - Load this package, all seems fine.
> >
> > - Promote the class/trait category to a package, let's say TraitsPackage
> >
> > - Save this package locally in a .mcz file
> >
> > - In the Pharo5.0 image unload all my packages
> >
> > - Load back the TraitsPackage, all traits methods are duplicated...
> >
> > - Examine the source in the .mcz file: the traits logic is already
> > compromised
> >
> >
> > Is there anything wrong in this process?
> >
> >
> > Conclusion1: Pharo5 does not know how to save Trait  correctly.
> > Conclusion2: Already get there,
> > http://forum.world.st/Strange-behaviour-with-traits-td4891623.html
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-users] Traits, method flatten

[Hilaire]

Hi,

If anyone with deep knowledge on Monticello wants to give a look with
this bugs on Traits, I can share privately an image exposing the
problem. Just mail me at hilaire [AT] drgeo.eu

Thanks

Hilaire

Le 12/04/2017 à 14:08, Hilaire a écrit :
> Investigating a bit on the mater, here is the conduct:
> 
> - In a fresh 5.0, find an a version of my package where the Traits logic
> is not compromised (All traits methods are not duplicated in the classes
> using the traits)
> 
> - Load this package, all seems fine.
> 
> - Promote the class/trait category to a package, let's say TraitsPackage
> 
> - Save this package locally in a .mcz file
> 
> - In the Pharo5.0 image unload all my packages
> 
> - Load back the TraitsPackage, all traits methods are duplicated...
> 
> - Examine the source in the .mcz file: the traits logic is already
> compromised
> 
> 
> Is there anything wrong in this process?
> 
> 
> Conclusion1: Pharo5 does not know how to save Trait  correctly.
> Conclusion2: Already get there,
> http://forum.world.st/Strange-behaviour-with-traits-td4891623.html

-- 
Dr. Geo
http://drgeo.eu

[Pharo-users] Machine Learning in Pharo

[frankl1_miky]

Hello everyone,

I would like to experiment machine learning in Pharo.

Is there any library out there for that purpose ?

Thanks !




--
View this message in context: 
http://forum.world.st/Machine-Learning-in-Pharo-tp4941934.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6 snap install

[Alistair Grant]

Hi Subbu,

On Wed, Apr 12, 2017 at 08:22:27PM +0530, K K Subbu wrote:
> On Wednesday 12 April 2017 07:33 PM, Alistair Grant wrote:
> >Hi Everyone,
> >
> >I've made a snap package for Pharo 6 which I think is far enough along
> >for some wider testing.
> 
> Just tried it now. worked like charm.

Thanks!

> >--classic - Snap packages are normally sandboxed for security
> > reasons.  Since Pharo is a development environment
> > in which we want to be able to run any executable,
> > or load any library, it is installed with access to
> > the entire system (as the running user).
> Is this really necessary even if we want to work only within an image?

No, I've used it successfully with strict confinement, however I think
most developers will quickly become frustrated with the restrictions.

If someone has a Pharo based application that they'd like to distribute,
I think strict confinement is a much more likely to be a realistic option.

Cheers,
Alistair

Re: [Pharo-users] Pharo 6 snap install

[Luke Gorrie]

On 12 April 2017 at 16:43, Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

> I'm also interested in the upcoming Nix package initiative that has been
> announced in the list recently, which also deals with installing
> dependencies in a Linux distribution neutral fashion.
>

This can only happen if the Pharo community somehow products a new release
of the VM that I can package.

The suggestion from the list was that I pick a commit from the
pharo-project/pharo-vm#master branch, but I have browsed the commit history
and that is way too much of a moving target for me to ship onwards to
Nix/NixOS users.

Pharo community: Please - somehow - make a new source release of your
bloomin' VM!

Re: [Pharo-users] Pharo 6 snap install

[K K Subbu]

On Wednesday 12 April 2017 07:33 PM, Alistair Grant wrote:

Hi Everyone,

I've made a snap package for Pharo 6 which I think is far enough along
for some wider testing.


Just tried it now. worked like charm.


--classic - Snap packages are normally sandboxed for security
 reasons.  Since Pharo is a development environment
 in which we want to be able to run any executable,
 or load any library, it is installed with access to
 the entire system (as the running user).

Is this really necessary even if we want to work only within an image?

Regards .. Subbu

Re: [Pharo-users] Neural Networks in Pharo

[Ben Coman]

On Wed, Apr 5, 2017 at 8:27 AM, Oleksandr Zaytsev 
wrote:

> Hello!
>
> Several weeks ago I've announced my NeuralNetworks project. Thank you very
> much for your ideas and feedback. As suggested, I wrote examples for every
> class and tested my perceptron on linearly-separable logical functions.
>
> I have just completed a post about my implementation of a single-layer
> perceptron: https://medium.com/@i.oleks/single-layer-perceptron-in-pharo
> -5b13246a041d. It has a detailed explanation of every part of the design
> and illustrates different approaches to implementation.
>
> Please, tell me what you think.
>
> Are my class diagrams correct or did I mess something up?
> Is there a design pattern that I should consider?
> Do you think that I should do something differently?
> Should I improve the quality of my code?
>
> Yours sincerely,
> Oleksandr
>

Hi Oleks,

(sorry for the delayed response. Saw you other post in pharo-dev and found
this sitting in my drafts from last week.)

Nice article and interesting read.  I only did NeuralNetworks in my
undergrad 25 years ago so my knowledge is a bit vague.
I think you design reasoning is fine for this stage.  Down the track you
might consider that OO is about hiding implementation details. So just a
vague idea, you might have SLPerceptron storing neuron data internally in
arrays that a GPU can process efficiently, but when "SLPerceptron>>#at:" is
asked for a neuron, it constructs a "real" neuron object, whose methods
forward to the arrays in theSLPerceptron.

cheers -ben

Re: [Pharo-users] Pharo 6 snap install

[Offray Vladimir Luna Cárdenas]

Thanks for this Alistair. Having more self contained package options, is 
good.


I'm also interested in the upcoming Nix package initiative that has been 
announced in the list recently, which also deals with installing 
dependencies in a Linux distribution neutral fashion.


Cheers,

Offray


On 12/04/17 09:03, Alistair Grant wrote:

Hi Everyone,

I've made a snap package for Pharo 6 which I think is far enough along
for some wider testing.

To get Pharo up and running on Ubuntu 16.04:

# Install Pharo
$ sudo snap install --edge pharo --classic
# If your system isn't configured for threaded heartbeat:
$ sudo pharo.config
# Download the latest Pharo 6 image
$ pharo.getimage
# Go...
$ pharo.ui Pharo.image
# or:
$ pharo Pharo.image eval 4+3

To get a list of available commands:

$ snap info pharo


If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see
https://snapcraft.io/docs/core/install


The VM is the threaded heartbeat, dated 201704101933.

The installation flags are:

 --edge - The edge channel is for development versions.  It
  progresses to beta, candidate and then stable.
 --classic - Snap packages are normally sandboxed for security
  reasons.  Since Pharo is a development environment
  in which we want to be able to run any executable,
  or load any library, it is installed with access to
  the entire system (as the running user).

Why use snap packages?

- They include all dependencies.  In particular, for the 32 bit
   versions, this means that it isn't necessary to install all the 32 bit
   architecture and associated dependencies.
- Including dependencies means that there shouldn't be any problems with
   incompatible library versions when upgrading.

Why not use snap packages?

- It's a relatively new technology, with a number of rough edges.
- There may still be issues with its sandboxing that I haven't
   discovered yet.
- Please let me know of any others to be listed here.
- Because the package uses classic confinement, it isn't
   cross-distribution in practice (unfortunately).

If you don't trust me to configure your system correctly (which requires
sudo):

- All the scripts that make up the sub-commands are visible, e.g.
   pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG


The packaging code is at: https://github.com/akgrant43/pharo-snap

I'm interested to know if people would like to see this eventually
become a supported package format.

Cheers,
Alistair

[Pharo-users] Pharo 6 snap install

[Alistair Grant]

Hi Everyone,

I've made a snap package for Pharo 6 which I think is far enough along
for some wider testing.

To get Pharo up and running on Ubuntu 16.04:

# Install Pharo
$ sudo snap install --edge pharo --classic
# If your system isn't configured for threaded heartbeat:
$ sudo pharo.config
# Download the latest Pharo 6 image
$ pharo.getimage
# Go...
$ pharo.ui Pharo.image
# or:
$ pharo Pharo.image eval 4+3

To get a list of available commands:

$ snap info pharo


If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see
https://snapcraft.io/docs/core/install


The VM is the threaded heartbeat, dated 201704101933.

The installation flags are:

--edge - The edge channel is for development versions.  It
 progresses to beta, candidate and then stable.
--classic - Snap packages are normally sandboxed for security
 reasons.  Since Pharo is a development environment 
 in which we want to be able to run any executable, 
 or load any library, it is installed with access to 
 the entire system (as the running user).

Why use snap packages?

- They include all dependencies.  In particular, for the 32 bit
  versions, this means that it isn't necessary to install all the 32 bit
  architecture and associated dependencies.
- Including dependencies means that there shouldn't be any problems with
  incompatible library versions when upgrading.

Why not use snap packages?

- It's a relatively new technology, with a number of rough edges.
- There may still be issues with its sandboxing that I haven't
  discovered yet.
- Please let me know of any others to be listed here.
- Because the package uses classic confinement, it isn't
  cross-distribution in practice (unfortunately).

If you don't trust me to configure your system correctly (which requires
sudo):

- All the scripts that make up the sub-commands are visible, e.g.
  pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG


The packaging code is at: https://github.com/akgrant43/pharo-snap

I'm interested to know if people would like to see this eventually
become a supported package format.

Cheers,
Alistair

Re: [Pharo-users] Recommended stable Pharo 5.0 VM for Linux users?

[Luke Gorrie]

On 12 April 2017 at 14:08, Esteban Lorenzano  wrote:

> It is in my TODO list.
> … along with other milliards of things with more priority ;)
>
> I will welcome any Pull Request, in any area but specially on that one :D
>

I can potentially make some time to help out with VM maintenance. I have
already volunteered to maintain the NixOS packaging for Pharo and that is
what leads me here in the first place, I will need to successfully build
the VM myself before I can help anybody else though :).

Before committing time I would like to understand the situation a little
bit better. How come nobody in the Pharo community sees it as a priority to
make a VM source release that is compatible with the current image version
(5.0)?

I had imagined that a compatible VM would be released at the same time as
the image. So I am obviously missing some point about why other people see
the VM source release as such a low priority. Is it just that everybody is
running zeroconf binaries distributed by Jenkins and that I am one of very
few people who wants to build from source (without bootstrapping from
another Pharo)?

Context: I am a relative newbie who wants to develop an application based
on Pharo. It's much harder than I expected to get started!

Re: [Pharo-users] Recommended stable Pharo 5.0 VM for Linux users?

[Esteban Lorenzano]

> On 12 Apr 2017, at 11:43, Luke Gorrie  wrote:
> 
> On 12 April 2017 at 10:27, Esteban Lorenzano  > wrote:
> yes, at the end I did a different process. 
> after cloning vm sources, now you do not need to generate them… just go to 
> 
> $ cd build.linuxWHATEVER/pharo.cog.spur/build
> $ ./mvm
> 
> that will work and produce the official latest VM :)
> 
> Thanks for the information. I will give it a try.
> 
> Any chance of updating the instructions in the README for future reference?

It is in my TODO list.
… along with other milliards of things with more priority ;)

I will welcome any Pull Request, in any area but specially on that one :D

Esteban

> 
> 

Re: [Pharo-users] Traits, method flatten

[Hilaire]

Investigating a bit on the mater, here is the conduct:

- In a fresh 5.0, find an a version of my package where the Traits logic
is not compromised (All traits methods are not duplicated in the classes
using the traits)

- Load this package, all seems fine.

- Promote the class/trait category to a package, let's say TraitsPackage

- Save this package locally in a .mcz file

- In the Pharo5.0 image unload all my packages

- Load back the TraitsPackage, all traits methods are duplicated...

- Examine the source in the .mcz file: the traits logic is already
compromised


Is there anything wrong in this process?


Conclusion1: Pharo5 does not know how to save Trait  correctly.
Conclusion2: Already get there,
http://forum.world.st/Strange-behaviour-with-traits-td4891623.html

Hilaire


-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] why is adding instance variables so slow?

[teso...@gmail.com]

Hi,
in non spur, the only improve that I think it can be made safely is
moving the garbage collect operation to the migration of instances side,
only executing the garbage collect if there are instances.

In spur the garbage collect it is not needed anymore, because the way the
become is working is not the same.

In the old implementation, the old instances where in the image until they
are removed by the garbage collector. So you can access them with the
allInstances. In the new implementation, the old instances are marked as a
forwarded to the new instances.
So, there is no need for the garbage collect.
This should be tried but I think it can work.

Cheers,
Pablo



On Wed, Apr 12, 2017 at 1:17 PM, Guillermo Polito  wrote:

>
>
> On Wed, Apr 12, 2017 at 11:35 AM, Denis Kudriashov 
> wrote:
>
>>
>> 2017-04-12 10:55 GMT+02:00 Guillermo Polito :
>>
>>> PharoClassInstaller>>migrateClasses: old to: new using:
 anInstanceModification
 instanceModification := anInstanceModification.
 old ifEmpty:  [ ^ self ].
 [
 1 to: old size do: [ :index |
 self updateClass: (old at: index) to: (new at: index)].
 old elementsForwardIdentityTo: new.
 " Garbage collect away the zombie instances left behind in garbage
 memory in #updateInstancesFrom: "
 " If we don't clean up this garbage, a second update would revive them
 with a wrong layout! "
 " (newClass rather than oldClass, since they are now both newClass) "
 Smalltalk garbageCollect.
 ] valueUnpreemptively

 Commenting garbage collection here increases performance 10 times.
 Then commenting class update loop increases performance 3 times more.
 But this loop is required. It adopts all instances of old class to new one.
 And time here spent in #allInstances method.

 Can we remove manual garbage collection here? Why it is needed?

>>>
>>> Well, there is the comment that explains it and makes pretty good sense.
>>>
>>
>> But is does not explain why these bad zombies exist. We investigates
>> possible reasons and could not reproduce them. We will try remove garbage
>> collection here in Pharo 7
>>
>
> No, this will break stuff! I'll try to explain what does it mean by zombie
> instances to make some sense:
>
> - Imagine that you have class A + 10 instances of A.
>
> - We add an instance variable to A.
>   - this means the class builder will generate class A' that is the new
> version of A.
>   - then, it migrates all instances of A to class A'.
>  This migration is not magic:
> - 10 new instances of A' are created
> - the state is migrated from the instances of A to A'
> - each instance of A is becomed into its corresponding instance of
> A'
>   - finally we become class A into A'
>   This step will make that old instances of A now have:
>  - the old format
>  - but point to the new class A
>
> If we do not garbage collect, this means that doing
>
> A allInstances
>
> will return not only the new 10 instances of A, but the old instances of
> A'.
> And that will break LOOOTS of stuff.
>



-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-users] why is adding instance variables so slow?

[Denis Kudriashov]

2017-04-12 13:17 GMT+02:00 Guillermo Polito :

>   1) each instance of A is becomed into its corresponding instance of A'
>   2) finally we become class A into A'
>   This step will make that old instances of A now have:
>  - the old format
>  - but point to the new class A
>

step 1) ensures that there are no instances of class A anymore.
Check following script:

c1 := Class1 new.
c2 := Class2 new.
c1 becomeForward: c2.
Class1 allInstances "=> #()".


And full migration is executed in high priority uninterrupted process to
ensure that between 1) and 2) nobody will instantiate Class1

Re: [Pharo-users] why is adding instance variables so slow?

[Guillermo Polito]

On Wed, Apr 12, 2017 at 11:35 AM, Denis Kudriashov 
wrote:

>
> 2017-04-12 10:55 GMT+02:00 Guillermo Polito :
>
>> PharoClassInstaller>>migrateClasses: old to: new using:
>>> anInstanceModification
>>> instanceModification := anInstanceModification.
>>> old ifEmpty:  [ ^ self ].
>>> [
>>> 1 to: old size do: [ :index |
>>> self updateClass: (old at: index) to: (new at: index)].
>>> old elementsForwardIdentityTo: new.
>>> " Garbage collect away the zombie instances left behind in garbage
>>> memory in #updateInstancesFrom: "
>>> " If we don't clean up this garbage, a second update would revive them
>>> with a wrong layout! "
>>> " (newClass rather than oldClass, since they are now both newClass) "
>>> Smalltalk garbageCollect.
>>> ] valueUnpreemptively
>>>
>>> Commenting garbage collection here increases performance 10 times.
>>> Then commenting class update loop increases performance 3 times more.
>>> But this loop is required. It adopts all instances of old class to new one.
>>> And time here spent in #allInstances method.
>>>
>>> Can we remove manual garbage collection here? Why it is needed?
>>>
>>
>> Well, there is the comment that explains it and makes pretty good sense.
>>
>
> But is does not explain why these bad zombies exist. We investigates
> possible reasons and could not reproduce them. We will try remove garbage
> collection here in Pharo 7
>

No, this will break stuff! I'll try to explain what does it mean by zombie
instances to make some sense:

- Imagine that you have class A + 10 instances of A.

- We add an instance variable to A.
  - this means the class builder will generate class A' that is the new
version of A.
  - then, it migrates all instances of A to class A'.
 This migration is not magic:
- 10 new instances of A' are created
- the state is migrated from the instances of A to A'
- each instance of A is becomed into its corresponding instance of
A'
  - finally we become class A into A'
  This step will make that old instances of A now have:
 - the old format
 - but point to the new class A

If we do not garbage collect, this means that doing

A allInstances

will return not only the new 10 instances of A, but the old instances of A'.
And that will break LOOOTS of stuff.

Re: [Pharo-users] [ann] steering agile architecture video published by o'reilly

[Denis Kudriashov]

Do you plan presentation for PharoDays?

2017-04-12 1:04 GMT+02:00 Tudor Girba :

> Hi,
>
> I am happy to announce that O’Reilly has published my Steering Agile
> Architecture video training:
> http://www.humane-assessment.com/blog/steering-agile-
> architecture-video-training-oreilly/
>
> This video is based on my work on humane assessment, and it features Moose
> prominently. It also shows Pharo, GT and Roassal (in the last part).
>
> The video is indeed paid and it is mainly targeted to people that have a
> Safari Books Online subscription. But, the interesting thing about it is
> that it opens Pharo and Moose to a new kind of an audience, O’Reilly being
> the most prominent publishing company in the software area.
>
> Agile architecture is considered a prominent topic but the literature
> (until now) was rather loose at how to make it really work in practice.
> This course offers both a concrete approach based on humane assessment. As
> you might know, humane assessment centers around the idea of building tools
> cheaply as a way to figure the system out, and this is right now pretty
> much only practicable in Moose and Pharo.
>
> One thing that I ask people when I go to conferences, the last one being
> the Software Architecture Conference organized by O’Reilly, is if they like
> working with legacy systems. They actively dislike it. Then I show them
> demos of how it can be like and then I ask them if they think these demos
> are cool. And I never encountered one that did not find it cool. So, in a
> way, we can now be quite confident in saying that we work on the single
> platform that makes working with an existing system cool. Not a small feat.
>
> So, if you do get the chance to look at these things, you might also get a
> concrete inspiration of how to leverage Pharo skills within companies that
> do not yet work with Pharo.
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Presenting is storytelling."
>
>
>

Re: [Pharo-users] Recommended stable Pharo 5.0 VM for Linux users?

[Luke Gorrie]

On 12 April 2017 at 10:27, Esteban Lorenzano  wrote:

> yes, at the end I did a different process.
> after cloning vm sources, now you do not need to generate them… just go to
>
> $ cd build.linuxWHATEVER/pharo.cog.spur/build
> $ ./mvm
>
> that will work and produce the official latest VM :)
>

Thanks for the information. I will give it a try.

Any chance of updating the instructions in the README for future reference?

Re: [Pharo-users] why is adding instance variables so slow?

[Denis Kudriashov]

2017-04-12 10:55 GMT+02:00 Guillermo Polito :

> PharoClassInstaller>>migrateClasses: old to: new using:
>> anInstanceModification
>> instanceModification := anInstanceModification.
>> old ifEmpty:  [ ^ self ].
>> [
>> 1 to: old size do: [ :index |
>> self updateClass: (old at: index) to: (new at: index)].
>> old elementsForwardIdentityTo: new.
>> " Garbage collect away the zombie instances left behind in garbage memory
>> in #updateInstancesFrom: "
>> " If we don't clean up this garbage, a second update would revive them
>> with a wrong layout! "
>> " (newClass rather than oldClass, since they are now both newClass) "
>> Smalltalk garbageCollect.
>> ] valueUnpreemptively
>>
>> Commenting garbage collection here increases performance 10 times.
>> Then commenting class update loop increases performance 3 times more. But
>> this loop is required. It adopts all instances of old class to new one. And
>> time here spent in #allInstances method.
>>
>> Can we remove manual garbage collection here? Why it is needed?
>>
>
> Well, there is the comment that explains it and makes pretty good sense.
>

But is does not explain why these bad zombies exist. We investigates
possible reasons and could not reproduce them. We will try remove garbage
collection here in Pharo 7

Re: [Pharo-users] why is adding instance variables so slow?

[Guillermo Polito]

On Wed, Apr 12, 2017 at 10:51 AM, Denis Kudriashov 
wrote:

> Hi.
>
> I profiled a bit and found problem:
>
> PharoClassInstaller>>migrateClasses: old to: new using:
> anInstanceModification
> instanceModification := anInstanceModification.
> old ifEmpty:  [ ^ self ].
> [
> 1 to: old size do: [ :index |
> self updateClass: (old at: index) to: (new at: index)].
> old elementsForwardIdentityTo: new.
> " Garbage collect away the zombie instances left behind in garbage memory
> in #updateInstancesFrom: "
> " If we don't clean up this garbage, a second update would revive them
> with a wrong layout! "
> " (newClass rather than oldClass, since they are now both newClass) "
> Smalltalk garbageCollect.
> ] valueUnpreemptively
>
> Commenting garbage collection here increases performance 10 times.
> Then commenting class update loop increases performance 3 times more. But
> this loop is required. It adopts all instances of old class to new one. And
> time here spent in #allInstances method.
>
> Can we remove manual garbage collection here? Why it is needed?
>

Well, there is the comment that explains it and makes pretty good sense.


>
> 2017-04-12 9:34 GMT+02:00 Peter Uhnak :
>
>> Hi,
>>
>> does anyone know why adding instance variables is so slow?
>>
>> I did some quick benchmarks (see below), resulting in more than order of
>> magnitude speed difference between having it in the class definition and
>> adding it later.
>>
>> In fact it is still much faster to delete the class and then recreate it
>> with the instance variables in the d efinition. For four arguments it is
>> till 8x faster to delete the class four times and recreate it then just add
>> the variable. Unfortunately I cannot just trash the classes (they have
>> methods and inheritance).
>>
>> So the question is: why is it so slow? can I somehow improve the
>> performance?
>>
>> Thanks,
>> Peter
>>
>>
>> Benchmarks:
>>
>>
>> [
>> cls := Object subclass: #Some1.
>> cls removeFromSystem.
>> ] bench. "'91 per second'"
>>
>> [
>> cls := Object subclass: #Some2 instanceVariableNames: 'variable'.
>> cls removeFromSystem
>> ] bench. "'90 per second'"
>>
>> [
>> cls := Object subclass: #Some3.
>> cls addInstVarNamed: 'variable'.
>> cls removeFromSystem.
>> ] bench. "'7 per second'"
>>
>> [
>> cls := Object subclass: #Some4.
>> cls removeFromSystem.
>> cls := Object subclass: #Some4 instanceVariableNames: 'variable'.
>> cls removeFromSystem.
>> ] bench. "'43 per second'"
>>
>>
>>
>>
>> [
>> cls := Object subclass: #Some3.
>> cls addInstVarNamed: 'variable1'.
>> cls addInstVarNamed: 'variable2'.
>> cls addInstVarNamed: 'variable3'.
>> cls addInstVarNamed: 'variable4'.
>> cls removeFromSystem.
>> ] bench. "'2 per second'"
>>
>> [
>> cls := Object subclass: #Some4.
>> cls removeFromSystem.
>> cls := Object subclass: #Some4 instanceVariableNames: 'variable1
>> variable2 variable3 variable4'.
>> cls removeFromSystem.
>> ] bench. "'44 per second'"
>>
>> [
>> cls := Object subclass: #Some5.
>> cls removeFromSystem.
>> cls := Object subclass: #Some5 instanceVariableNames: 'variable1'.
>> cls removeFromSystem.
>> cls := Object subclass: #Some5 instanceVariableNames: 'variable1
>> variable2'.
>> cls removeFromSystem.
>> cls := Object subclass: #Some5 instanceVariableNames: 'variable1
>> variable2 variable3'.
>> cls removeFromSystem.
>> cls := Object subclass: #Some5 instanceVariableNames: 'variable1
>> variable2 variable3 variable4'.
>> cls removeFromSystem.
>> ] bench. "'17.269 per second'"
>>
>>
>

Re: [Pharo-users] why is adding instance variables so slow?

[Denis Kudriashov]

Hi.

I profiled a bit and found problem:

PharoClassInstaller>>migrateClasses: old to: new using:
anInstanceModification
instanceModification := anInstanceModification.
old ifEmpty:  [ ^ self ].
[
1 to: old size do: [ :index |
self updateClass: (old at: index) to: (new at: index)].
old elementsForwardIdentityTo: new.
" Garbage collect away the zombie instances left behind in garbage memory
in #updateInstancesFrom: "
" If we don't clean up this garbage, a second update would revive them with
a wrong layout! "
" (newClass rather than oldClass, since they are now both newClass) "
Smalltalk garbageCollect.
] valueUnpreemptively

Commenting garbage collection here increases performance 10 times.
Then commenting class update loop increases performance 3 times more. But
this loop is required. It adopts all instances of old class to new one. And
time here spent in #allInstances method.

Can we remove manual garbage collection here? Why it is needed?

2017-04-12 9:34 GMT+02:00 Peter Uhnak :

> Hi,
>
> does anyone know why adding instance variables is so slow?
>
> I did some quick benchmarks (see below), resulting in more than order of
> magnitude speed difference between having it in the class definition and
> adding it later.
>
> In fact it is still much faster to delete the class and then recreate it
> with the instance variables in the d efinition. For four arguments it is
> till 8x faster to delete the class four times and recreate it then just add
> the variable. Unfortunately I cannot just trash the classes (they have
> methods and inheritance).
>
> So the question is: why is it so slow? can I somehow improve the
> performance?
>
> Thanks,
> Peter
>
>
> Benchmarks:
>
>
> [
> cls := Object subclass: #Some1.
> cls removeFromSystem.
> ] bench. "'91 per second'"
>
> [
> cls := Object subclass: #Some2 instanceVariableNames: 'variable'.
> cls removeFromSystem
> ] bench. "'90 per second'"
>
> [
> cls := Object subclass: #Some3.
> cls addInstVarNamed: 'variable'.
> cls removeFromSystem.
> ] bench. "'7 per second'"
>
> [
> cls := Object subclass: #Some4.
> cls removeFromSystem.
> cls := Object subclass: #Some4 instanceVariableNames: 'variable'.
> cls removeFromSystem.
> ] bench. "'43 per second'"
>
>
>
>
> [
> cls := Object subclass: #Some3.
> cls addInstVarNamed: 'variable1'.
> cls addInstVarNamed: 'variable2'.
> cls addInstVarNamed: 'variable3'.
> cls addInstVarNamed: 'variable4'.
> cls removeFromSystem.
> ] bench. "'2 per second'"
>
> [
> cls := Object subclass: #Some4.
> cls removeFromSystem.
> cls := Object subclass: #Some4 instanceVariableNames: 'variable1
> variable2 variable3 variable4'.
> cls removeFromSystem.
> ] bench. "'44 per second'"
>
> [
> cls := Object subclass: #Some5.
> cls removeFromSystem.
> cls := Object subclass: #Some5 instanceVariableNames: 'variable1'.
> cls removeFromSystem.
> cls := Object subclass: #Some5 instanceVariableNames: 'variable1
> variable2'.
> cls removeFromSystem.
> cls := Object subclass: #Some5 instanceVariableNames: 'variable1
> variable2 variable3'.
> cls removeFromSystem.
> cls := Object subclass: #Some5 instanceVariableNames: 'variable1
> variable2 variable3 variable4'.
> cls removeFromSystem.
> ] bench. "'17.269 per second'"
>
>

Re: [Pharo-users] Recommended stable Pharo 5.0 VM for Linux users?

[Esteban Lorenzano]

yes, at the end I did a different process. 
after cloning vm sources, now you do not need to generate them… just go to 

$ cd build.linuxWHATEVER/pharo.cog.spur/build
$ ./mvm

that will work and produce the official latest VM :)

Esteban


> On 12 Apr 2017, at 09:59, Luke Gorrie  wrote:
> 
> On 4 April 2017 at 12:16, Luke Gorrie mailto:l...@snabb.co>> 
> wrote:
> On 4 April 2017 at 12:01, Esteban Lorenzano  > wrote:
> well, I’m working on commit also generated sources as an amend… but you will 
> need to wait a couple of days for that :)
> 
> Sounds great, thanks in advance!
> 
> Gentle ping on a Pharo VM unix source release that works with the 5.0 image 
> :-)
>  
> 

Re: [Pharo-users] Recommended stable Pharo 5.0 VM for Linux users?

[Luke Gorrie]

On 4 April 2017 at 12:16, Luke Gorrie  wrote:

> On 4 April 2017 at 12:01, Esteban Lorenzano  wrote:
>
>> well, I’m working on commit also generated sources as an amend… but you
>> will need to wait a couple of days for that :)
>>
>
> Sounds great, thanks in advance!
>

Gentle ping on a Pharo VM unix source release that works with the 5.0 image
:-)

[Pharo-users] why is adding instance variables so slow?

[Peter Uhnak]

Hi,

does anyone know why adding instance variables is so slow?

I did some quick benchmarks (see below), resulting in more than order of 
magnitude speed difference between having it in the class definition and adding 
it later.

In fact it is still much faster to delete the class and then recreate it with 
the instance variables in the d efinition. For four arguments it is till 8x 
faster to delete the class four times and recreate it then just add the 
variable. Unfortunately I cannot just trash the classes (they have methods and 
inheritance).

So the question is: why is it so slow? can I somehow improve the performance?

Thanks,
Peter


Benchmarks:


[
cls := Object subclass: #Some1.
cls removeFromSystem.
] bench. "'91 per second'"

[
cls := Object subclass: #Some2 instanceVariableNames: 'variable'.
cls removeFromSystem
] bench. "'90 per second'"

[
cls := Object subclass: #Some3.
cls addInstVarNamed: 'variable'.
cls removeFromSystem.
] bench. "'7 per second'"

[
cls := Object subclass: #Some4.
cls removeFromSystem.
cls := Object subclass: #Some4 instanceVariableNames: 'variable'.
cls removeFromSystem.
] bench. "'43 per second'"




[
cls := Object subclass: #Some3.
cls addInstVarNamed: 'variable1'.
cls addInstVarNamed: 'variable2'.
cls addInstVarNamed: 'variable3'.
cls addInstVarNamed: 'variable4'.
cls removeFromSystem.
] bench. "'2 per second'"

[
cls := Object subclass: #Some4.
cls removeFromSystem.
cls := Object subclass: #Some4 instanceVariableNames: 'variable1 
variable2 variable3 variable4'.
cls removeFromSystem.
] bench. "'44 per second'"

[
cls := Object subclass: #Some5.
cls removeFromSystem.
cls := Object subclass: #Some5 instanceVariableNames: 'variable1'.
cls removeFromSystem.
cls := Object subclass: #Some5 instanceVariableNames: 'variable1 
variable2'.
cls removeFromSystem.
cls := Object subclass: #Some5 instanceVariableNames: 'variable1 
variable2 variable3'.
cls removeFromSystem.
cls := Object subclass: #Some5 instanceVariableNames: 'variable1 
variable2 variable3 variable4'.
cls removeFromSystem.
] bench. "'17.269 per second'"