Re: [Pharo-users] Pharo 6 snap install

[Luke Gorrie]

On 14 April 2017 at 22:20, Stephane Ducasse  wrote:

> This is what we always have when we release and we freeze it.
> The vm 60 will be compatible with latest pharo 60 image.
>

It is possible that I have misunderstood the whole situation and there is
no problem at all. That would be awesome. Let's check :-) here is my
understanding of the state of the world right now:

The latest stable image release is Pharo-50771.image.
The latest stable VM source release is pharo-vm-2016.02.18.
These two releases are not compatible: This interpreter (vers. 6505) cannot
read image file (vers. 6521).

So the problem is that if a distribution packages the latest VM source
release then the users won't be able to run the Pharo 5 VM that they
download from pharo.org or via the pharo-launcher image.

Is that correct? If so that's fine and hopefully we can fix it for Pharo
6.0. But if I am misunderstanding and a fix is available today that would
also be good to know.

I am looking for the "latest VM source release" in
http://files.pharo.org/vm/src/vm-unix-sources/ and assuming that non-spur
is the stable option for pre-6.0 images.

Cheers!
-Luke

Re: [Pharo-users] Pharo6 server deployment and no home directory

[Juraj Kubelka]

Hi,

> El 14-04-2017, a las 16:17, Holger Freyther  escribió:
> 
> Hi,
> 
> as Pharo6 is around the corner I have moved my CI build from tracking Pharo5 
> to Pharo6 but I run into a problem. Either if $HOME is not set at all or 
> $HOME points to a wrong directory I run into the error below.
> 
> As this is a server application and I run multiple VMs with the same image 
> and there is no home directory I would prefer that no information is 
> persisted at all. Can this be done? Have there been any changes in Pharo6 in 
> regard to this?

Do you think that checking if `FileIdentifier home` exist solves the issue? 

Can we detect headless state? 

> 
> It also seems to change from Fuel->Ston for the identifier? Is this intended?

Yes, this is intended and should not produce problems. 

Juraj

> 
> holger
> 
> 
> 
> HOME=/home/blabla ./vm/pharo --nodisplay My.image eval --save 
> '(NonInteractiveTranscript onFileNamed: #stdout)' install
> PrimitiveFailed: primitive #createDirectory: in UnixStore failed
> UnixStore(Object)>>primitiveFailed:
> UnixStore(Object)>>primitiveFailed
> UnixStore(DiskStore)>>createDirectory:
> UnixStore(FileSystemStore)>>ensureCreateDirectory:
> UnixStore(FileSystemStore)>>ensureCreateDirectory:
> UnixStore(FileSystemStore)>>ensureCreateDirectory:
> FileSystem>>ensureCreateDirectory:
> FileReference>>ensureCreateDirectory
> FileLocator(AbstractFileReference)>>ensureCreateDirectory
> GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>ensureDirectory
> GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>save:
> GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>load:
> GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>ensure:
> GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure:
> GlobalIdentifier>>ensure
> GlobalIdentifier class>>initializeUniqueInstance
> GlobalIdentifier class>>uniqueInstance
> SystemSettingsPersistence class>>resumeSystemSettings
> [ :persistence | persistence resumeSystemSettings ] in 
> PharoCommandLineHandler>>runPreferences in Block: [ :persistence | 
> persistence resumeSystemSettings ...etc...
> BlockClosure>>cull:
> SystemDictionary(Dictionary)>>at:ifPresent:
> SmalltalkImage>>at:ifPresent:
> PharoCommandLineHandler>>runPreferences
> PharoCommandLineHandler>>activate
> PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
> [ super activateWith: aCommandLine ] in PharoCommandLineHandler 
> class>>activateWith: in Block: [ super activateWith: aCommandLine ]
> NonInteractiveUIManager(UIManager)>>defer:
> PharoCommandLineHandler class>>activateWith:
> [ aCommandLinehandler activateWith: commandLine ] in 
> BasicCommandLineHandler>>activateSubCommand: in Block: [ aCommandLinehandler 
> activateWith: commandLine ]
> BlockClosure>>on:do:
> 
> 

Re: [Pharo-users] How can I set the SmaccDebugParser in Moose

[Andrei Chis]

Not exactly sure how to do to it because I never used it.
>From what I see in SmaCCParserDebugger>>handlesContext: if you have in the
stack a context created by  SmaCCParser>>parse you should have a
'SmaCCParser' button at the top right of the window. But maybe John can
provide you with more details.

Cheers,
Andrei


On Fri, Apr 14, 2017 at 2:45 PM, Stephane Ducasse 
wrote:

> Andrei?
> Help?
>
>
>
> On Fri, Apr 7, 2017 at 3:14 PM, Stephane Ducasse 
> wrote:
>
>> Hi
>>
>> I found the SmaCCParserDebugger and I found the debug menu in the Smacc
>> tool.
>> Now I get a GT and byteCode debugger but I do not find a way to make the
>> new debugger actif.
>>
>> Stef
>>
>
>

Re: [Pharo-users] Pharo 6 snap install

[Stephane Ducasse]

This is what we always have when we release and we freeze it.
The vm 60 will be compatible with latest pharo 60 image.



On Fri, Apr 14, 2017 at 12:09 PM, Luke Gorrie  wrote:

> On 14 April 2017 at 08:53, Stephane Ducasse 
> wrote:
>
>> We always try to have a major release around mid/end of april
>>
>
> Once the dust settles, I think it would be wonderful to have this
> invariant:
>
> - The latest Pharo VM source release is compatible with the latest Pharo
> image.
>
> This would make it easy for me to help nix users. My job will be to
> package the latest source release of the VM, period, and I will know that
> users can use this to run the latest image. I don't have much scope to
> screw things up and make people sad e.g. by shipping a bad commit from the
> master branch.
>
> (Of course it makes life harder for you upstream Pharo maintainers. Now
> updating the VM source release is a blocker for releasing a new image.
> Could be that this is too constraining in practice, I dunno. I'm just a guy
> who wants to setup a stable Pharo that I can use to build an application
> :-))
>
>
>

[Pharo-users] Pharo6 server deployment and no home directory

[Holger Freyther]

Hi,

as Pharo6 is around the corner I have moved my CI build from tracking Pharo5 to 
Pharo6 but I run into a problem. Either if $HOME is not set at all or $HOME 
points to a wrong directory I run into the error below.

As this is a server application and I run multiple VMs with the same image and 
there is no home directory I would prefer that no information is persisted at 
all. Can this be done? Have there been any changes in Pharo6 in regard to this?

It also seems to change from Fuel->Ston for the identifier? Is this intended?

holger



HOME=/home/blabla ./vm/pharo --nodisplay My.image eval --save 
'(NonInteractiveTranscript onFileNamed: #stdout)' install
PrimitiveFailed: primitive #createDirectory: in UnixStore failed
UnixStore(Object)>>primitiveFailed:
UnixStore(Object)>>primitiveFailed
UnixStore(DiskStore)>>createDirectory:
UnixStore(FileSystemStore)>>ensureCreateDirectory:
UnixStore(FileSystemStore)>>ensureCreateDirectory:
UnixStore(FileSystemStore)>>ensureCreateDirectory:
FileSystem>>ensureCreateDirectory:
FileReference>>ensureCreateDirectory
FileLocator(AbstractFileReference)>>ensureCreateDirectory
GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>ensureDirectory
GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>save:
GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>load:
GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>ensure:
GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure:
GlobalIdentifier>>ensure
GlobalIdentifier class>>initializeUniqueInstance
GlobalIdentifier class>>uniqueInstance
SystemSettingsPersistence class>>resumeSystemSettings
[ :persistence | persistence resumeSystemSettings ] in 
PharoCommandLineHandler>>runPreferences in Block: [ :persistence | persistence 
resumeSystemSettings ...etc...
BlockClosure>>cull:
SystemDictionary(Dictionary)>>at:ifPresent:
SmalltalkImage>>at:ifPresent:
PharoCommandLineHandler>>runPreferences
PharoCommandLineHandler>>activate
PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
[ super activateWith: aCommandLine ] in PharoCommandLineHandler 
class>>activateWith: in Block: [ super activateWith: aCommandLine ]
NonInteractiveUIManager(UIManager)>>defer:
PharoCommandLineHandler class>>activateWith:
[ aCommandLinehandler activateWith: commandLine ] in 
BasicCommandLineHandler>>activateSubCommand: in Block: [ aCommandLinehandler 
activateWith: commandLine ]
BlockClosure>>on:do:

Re: [Pharo-users] Traits score: Squeak: 1, Pharo5: 0

[Hilaire]

I tried but I can't reproduce the case with dummy code.
I can share privately an image though.

Hilaire

Le 14/04/2017 à 15:24, Denis Kudriashov a écrit :
> 
> Could you create example set of packages to reproduce problem? (to be
> not dependant on your private code)
> 

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

Re: [Pharo-users] Export MongoDB to sql format

[Ben Coman]

On Fri, Apr 14, 2017 at 5:13 PM, Igor Stasenko  wrote:

>
>
> On 13 April 2017 at 22:23, Esteban Lorenzano  wrote:
>
>>
>> On 13 Apr 2017, at 19:26, Asbath Sama biyalou via Pharo-users <
>> pharo-users@lists.pharo.org> wrote:
>>
>>
>> *From: *Asbath Sama biyalou 
>> *Subject: **Export MongoDB to sql format*
>> *Date: *13 April 2017 at 19:26:25 GMT+2
>> *To: *Pharo users users 
>>
>>
>> Hello Everyone.
>>
>> I think this is not the right place for this question. But I am doing a
>> work with Pharo.
>>
>> I use MongoDB with Voyage. But I am asked to export my database in sql
>> format.
>>
>> I want to know if there is a way to export mongoDB in sql.
>>
>>
>> there is not.
>> a nosql database will have problems to export its data as sql.
>> of course it can be done (as everything), but it is a manual task :S
>>
>>
> This sort of questions most strangest ones , that i always wonder..
>

Pure supposition... Because the corporate policy *only* allows relational
database,
but nosql was a better solution, but needs fake that its relational.

cheers -ben


> Like people who buying microwave asking: cool , now how i could fit a coal
> burner to it?
>
> Why I mean if you need your traditional oven, they why even bother to
> buy a microvawe in a first place?
>
>
> cheers,
>> Esteban
>>
>>
>> Thanks.
>>
>>
>> Asbath
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-users] Traits score: Squeak: 1, Pharo5: 0

[Denis Kudriashov]

Hi.

Could you create example set of packages to reproduce problem? (to be not
dependant on your private code)

2017-04-14 14:41 GMT+02:00 Hilaire :

> Tested on Pharo6, result is the same :(
> Traits logic is lost when saving the package.
>
> Squeak: 1 - Pharo6: 0
>
>
> Le 14/04/2017 à 14:33, Hilaire a écrit :
> > So it looks like Squeak[1] is capable to produce a correct .mcz file,
> > out of a package coming  with Traits and class.
> > By correct, read the Traits logic is not lost.
> >
> > Hilaire
> >
> > [1] I tested with a Squeak6 alpha waiting somewhere on my disk
> >
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-users] Traits score: Squeak: 1, Pharo5: 0

[Hilaire]

Tested on Pharo6, result is the same :(
Traits logic is lost when saving the package.

Squeak: 1 - Pharo6: 0


Le 14/04/2017 à 14:33, Hilaire a écrit :
> So it looks like Squeak[1] is capable to produce a correct .mcz file,
> out of a package coming  with Traits and class.
> By correct, read the Traits logic is not lost.
> 
> Hilaire
> 
> [1] I tested with a Squeak6 alpha waiting somewhere on my disk
> 

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

[Pharo-users] Traits score: Squeak: 1, Pharo5: 0

[Hilaire]

So it looks like Squeak[1] is capable to produce a correct .mcz file,
out of a package coming  with Traits and class.
By correct, read the Traits logic is not lost.

Hilaire

[1] I tested with a Squeak6 alpha waiting somewhere on my disk


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

Re: [Pharo-users] Export MongoDB to sql format

[Dimitris Chloupis]

Some traditional ovens cook some foods better

the answer is always
"because its a complex world and any effort to simplify it is doomed to
fail"


On Fri, Apr 14, 2017 at 12:14 PM Igor Stasenko  wrote:

> On 13 April 2017 at 22:23, Esteban Lorenzano  wrote:
>
>>
>> On 13 Apr 2017, at 19:26, Asbath Sama biyalou via Pharo-users <
>> pharo-users@lists.pharo.org> wrote:
>>
>>
>> *From: *Asbath Sama biyalou 
>> *Subject: **Export MongoDB to sql format*
>> *Date: *13 April 2017 at 19:26:25 GMT+2
>> *To: *Pharo users users 
>>
>>
>> Hello Everyone.
>>
>> I think this is not the right place for this question. But I am doing a
>> work with Pharo.
>>
>> I use MongoDB with Voyage. But I am asked to export my database in sql
>> format.
>>
>> I want to know if there is a way to export mongoDB in sql.
>>
>>
>> there is not.
>> a nosql database will have problems to export its data as sql.
>> of course it can be done (as everything), but it is a manual task :S
>>
>>
> This sort of questions most strangest ones , that i always wonder..
> Like people who buying microwave asking: cool , now how i could fit a coal
> burner to it?
>
> Why I mean if you need your traditional oven, they why even bother to
> buy a microvawe in a first place?
>
>
> cheers,
>> Esteban
>>
>>
>> Thanks.
>>
>>
>> Asbath
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>

[Pharo-users] [ANN] Prometheas : a Pharo wiki database

[Dimitris Chloupis]

Part of my Discord bot as a goal was to add the ability to create database
entries so that people can quickly find documentation.

It was quite a challenge for me because I had to learn how heroku works,
PostgreSQL and all the other things but I did it!!!

In any discord channel you have now 3 commands !doc , !docadd , !docremove

1) !doc 
search for a term in the documentation database
eg. !doc pharo

2) !docadd
add a new entry to the documentation database
eg. !docadd "pharo" "Pharo is a modern implementation of Smalltalk"
"{'smalltalk','live coding','language'}" "{'squeak','IDE'}"

3)!docremove 
remove a term from database
eg. !docremove pharo

tags , is for more complex searches in the future, links for sending users
to relevant documentation

I am also planning to give access to pharo users to the database from
inside the pharo image, if its easy enough to use PostgreSQL from inside
Pharo. Currently the bot is fully coded in python.

The goal is not to create a full documentation but rather quick help tips
for fast pointing to the right direction.

This is also an invite to experience pharo devs and newcomers to start
adding to this database.

The database is PostgreSQL , one of the most populars, I have nothing
against MongoDB , its just that it works better with heroku where I host
the database. But if in the future find a way to do it for free I can move
to MongoDB, but no promises.

Anyway this was an excuse for me to learn database programming that I had
abandoned 25 years ago (DBASE).

So have fun with this :)

Re: [Pharo-users] Traits, method flatten

[Hilaire]

Ah, no my bad. Squeak was file in correctly the Trait and Class, it is
just that its browser does not let you know if a method class belong to
one of its Traits or the class itself

Le 14/04/2017 à 11:16, Hilaire a écrit :
> Give a try to filein the correct .st source file of the Traits+Classes
> package. It does not get it right :(
> 
> Pharo5 get it right when loading the .st source file though.
> 
> Still investigating...

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

Re: [Pharo-users] How can I set the SmaccDebugParser in Moose

[Stephane Ducasse]

Andrei?
Help?



On Fri, Apr 7, 2017 at 3:14 PM, Stephane Ducasse 
wrote:

> Hi
>
> I found the SmaCCParserDebugger and I found the debug menu in the Smacc
> tool.
> Now I get a GT and byteCode debugger but I do not find a way to make the
> new debugger actif.
>
> Stef
>

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

[Denis Kudriashov]

2017-04-14 11:09 GMT+02:00 teso...@gmail.com :

> Hi, I think the problem was not clearly explained. This is the scenario
> that is problematic.
> This scenario does not happen in the new Spur implementation of
> forwarding, but I think is happening in the old one.
>
> 1. You have, let's say 3 instances of ClassA.
> 2. You add a new instance variable to ClassA. It produces
>2a. A new ClassAv2 is created with the instances variables of ClassA
> and the newone
>2b. 3 Instances of ClassAv2 are created
>2c. The values of the instance variables of ClassA are copied to the
> ones in ClassAv2 (the ones missing are left in nil).
>2d. The 3 instances of ClassA are becomed forward to the 3 instances of
> ClassAv2
>2e. The ClassA is becomed forward ClassAv2
>

I still not see why my example not reflects all these steps. I checked also
scenario with class becoming:

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


It also works in Cog

Re: [Pharo-users] Pharo 6 snap install

[Luke Gorrie]

On 14 April 2017 at 08:53, Stephane Ducasse  wrote:

> We always try to have a major release around mid/end of april
>

Once the dust settles, I think it would be wonderful to have this invariant:

- The latest Pharo VM source release is compatible with the latest Pharo
image.

This would make it easy for me to help nix users. My job will be to package
the latest source release of the VM, period, and I will know that users can
use this to run the latest image. I don't have much scope to screw things
up and make people sad e.g. by shipping a bad commit from the master branch.

(Of course it makes life harder for you upstream Pharo maintainers. Now
updating the VM source release is a blocker for releasing a new image.
Could be that this is too constraining in practice, I dunno. I'm just a guy
who wants to setup a stable Pharo that I can use to build an application
:-))

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

[Denis Kudriashov]

2017-04-14 10:51 GMT+02:00 teso...@gmail.com :

> Hi Denis,
>  in the script you are not generating instances of Class1, the problem
> is with the instances.
>

But it generates:

 c1 := Class1 new.

Or what kind of generation you mean?

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

[Igor Stasenko]

i don't see much difference comparing to old implementation of
#becomeForward:
the only issue is that #allInstances could report same instance twice
first, it will find an old instance (that is forwards to new one) and so,
add it to results array,
and then walking the heap further will find a new version of same instance.

That's why , it think #allInstances should use IdentitySet-behavior to
mitigate such problem,
and always look if there's already same object captured to avoid reporting
it twice.
Or else we can declare it as a feature and warn users of #allInstances that
they could have duplications,
so in case if it important to them, they could always do 'allInstances
asIdentitySet'

But again, this is s orthogonal to adding instance variables to
class... maybe we should rename the topic instead
and speak about #allInstances behavior? :)



On 14 April 2017 at 12:09, teso...@gmail.com  wrote:

> Hi, I think the problem was not clearly explained. This is the scenario
> that is problematic.
> This scenario does not happen in the new Spur implementation of
> forwarding, but I think is happening in the old one.
>
> 1. You have, let's say 3 instances of ClassA.
> 2. You add a new instance variable to ClassA. It produces
>2a. A new ClassAv2 is created with the instances variables of ClassA
> and the newone
>2b. 3 Instances of ClassAv2 are created
>2c. The values of the instance variables of ClassA are copied to the
> ones in ClassAv2 (the ones missing are left in nil).
>2d. The 3 instances of ClassA are becomed forward to the 3 instances of
> ClassAv2
>2e. The ClassA is becomed forward ClassAv2
>
> 3. You add a new instance variable to ClassAv2. It produces
>3a. A new ClassAv3 is created with the instances variables of ClassAv2
> and the newone
>3b. 3 Instances of ClassAv3 are created
>3c. The values of the instance variables of ClassAv2 are copied to the
> ones in ClassAv3 (the ones missing are left in nil).
>3d. The 3 instances of ClassAv2 are becomed forward to the 3 instances
> of ClassAv3
>3e. The ClassAv2 is becomedFormeward ClassAv3
>
> 4. All the instances of ClassAV3 have the correct format and everything
> works.
>
> What is the problem:
> ===
>
> - When you do the first add instance variable, the old instances (the one
> from ClassA) which are smaller (has 1 instance variable less)
> have its class changed (after you perform a become of ClassA to ClassAv2).
> So if you try to use them everything will explode, because you will trying
> to access an instance variable that does not exists.
> These instances are not referenced by anyone, however if you perform a
> ClassAv2>>allInstances you will find them. So if you modify the class
> adding two variables, one after another the second time
> you will be accessing the invalid instances.
>
>
> Considering the differences in the Become implementation
> 
>
> However, the main difference is the implementation of the become forward.
> Let's start with the new implementation, as it has not problems.
>
> When you do a become forward, from object a to b, the primitive replaces
> the object a with a forwarder to b.
> When this forwarded is accessed the references to it are rewrited.
> If the objects are the same size (not this scenario) the object b replaces
> object a. It does not produces an error because the old.
> In the become forward the old instances are not keeped.
>
> In the old implementation the whole image is scanned, changing the
> references to the old instances, replacing with references to the new
> instances.
> The old instances are not removed, just kept there to let the GC do its
> work.
> Again if the objects are the same size there is special behavior.
>
> I hope know the problem is better explained
>
> Cheers,
> Pablo
>
>
>
> On Fri, Apr 14, 2017 at 10:50 AM, Igor Stasenko 
> wrote:
>
>>
>>
>> On 14 April 2017 at 10:19, Stephane Ducasse 
>> wrote:
>>
>>> But I do not get how doing that would handle the old instances?
>>> Because you want to migrate the old instances.
>>>
>>>
>> +1
>> there are no such thing as 'bad zombies', if they are there, it means you
>> either don't care about migrating data
>> or again, don't care about doing #becomeForward-ing them properly.
>> In any case i don't see how GC could help to fix these issues. You either
>> have consistency or don't have it,
>> and GC cannot do anything magical to fix it.
>>
>>
>>
>>> Stef
>>>
>>> On Wed, Apr 12, 2017 at 1:26 PM, Denis Kudriashov 
>>> wrote:
>>>

 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 

Re: [Pharo-users] Traits, method flatten

[Hilaire]

Give a try to filein the correct .st source file of the Traits+Classes
package. It does not get it right :(

Pharo5 get it right when loading the .st source file though.

Still investigating...

Le 14/04/2017 à 11:04, Hilaire a écrit :
> - Test on Squeak, not sure how stable it is there...

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

Re: [Pharo-users] Export MongoDB to sql format

[Igor Stasenko]

On 13 April 2017 at 22:23, Esteban Lorenzano  wrote:

>
> On 13 Apr 2017, at 19:26, Asbath Sama biyalou via Pharo-users <
> pharo-users@lists.pharo.org> wrote:
>
>
> *From: *Asbath Sama biyalou 
> *Subject: **Export MongoDB to sql format*
> *Date: *13 April 2017 at 19:26:25 GMT+2
> *To: *Pharo users users 
>
>
> Hello Everyone.
>
> I think this is not the right place for this question. But I am doing a
> work with Pharo.
>
> I use MongoDB with Voyage. But I am asked to export my database in sql
> format.
>
> I want to know if there is a way to export mongoDB in sql.
>
>
> there is not.
> a nosql database will have problems to export its data as sql.
> of course it can be done (as everything), but it is a manual task :S
>
>
This sort of questions most strangest ones , that i always wonder..
Like people who buying microwave asking: cool , now how i could fit a coal
burner to it?

Why I mean if you need your traditional oven, they why even bother to
buy a microvawe in a first place?


cheers,
> Esteban
>
>
> Thanks.
>
>
> Asbath
>
>


-- 
Best regards,
Igor Stasenko.

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

[teso...@gmail.com]

Hi, I think the problem was not clearly explained. This is the scenario
that is problematic.
This scenario does not happen in the new Spur implementation of forwarding,
but I think is happening in the old one.

1. You have, let's say 3 instances of ClassA.
2. You add a new instance variable to ClassA. It produces
   2a. A new ClassAv2 is created with the instances variables of ClassA and
the newone
   2b. 3 Instances of ClassAv2 are created
   2c. The values of the instance variables of ClassA are copied to the
ones in ClassAv2 (the ones missing are left in nil).
   2d. The 3 instances of ClassA are becomed forward to the 3 instances of
ClassAv2
   2e. The ClassA is becomed forward ClassAv2

3. You add a new instance variable to ClassAv2. It produces
   3a. A new ClassAv3 is created with the instances variables of ClassAv2
and the newone
   3b. 3 Instances of ClassAv3 are created
   3c. The values of the instance variables of ClassAv2 are copied to the
ones in ClassAv3 (the ones missing are left in nil).
   3d. The 3 instances of ClassAv2 are becomed forward to the 3 instances
of ClassAv3
   3e. The ClassAv2 is becomedFormeward ClassAv3

4. All the instances of ClassAV3 have the correct format and everything
works.

What is the problem:
===

- When you do the first add instance variable, the old instances (the one
from ClassA) which are smaller (has 1 instance variable less)
have its class changed (after you perform a become of ClassA to ClassAv2).
So if you try to use them everything will explode, because you will trying
to access an instance variable that does not exists.
These instances are not referenced by anyone, however if you perform a
ClassAv2>>allInstances you will find them. So if you modify the class
adding two variables, one after another the second time
you will be accessing the invalid instances.


Considering the differences in the Become implementation


However, the main difference is the implementation of the become forward.
Let's start with the new implementation, as it has not problems.

When you do a become forward, from object a to b, the primitive replaces
the object a with a forwarder to b.
When this forwarded is accessed the references to it are rewrited.
If the objects are the same size (not this scenario) the object b replaces
object a. It does not produces an error because the old.
In the become forward the old instances are not keeped.

In the old implementation the whole image is scanned, changing the
references to the old instances, replacing with references to the new
instances.
The old instances are not removed, just kept there to let the GC do its
work.
Again if the objects are the same size there is special behavior.

I hope know the problem is better explained

Cheers,
Pablo



On Fri, Apr 14, 2017 at 10:50 AM, Igor Stasenko  wrote:

>
>
> On 14 April 2017 at 10:19, Stephane Ducasse 
> wrote:
>
>> But I do not get how doing that would handle the old instances?
>> Because you want to migrate the old instances.
>>
>>
> +1
> there are no such thing as 'bad zombies', if they are there, it means you
> either don't care about migrating data
> or again, don't care about doing #becomeForward-ing them properly.
> In any case i don't see how GC could help to fix these issues. You either
> have consistency or don't have it,
> and GC cannot do anything magical to fix it.
>
>
>
>> Stef
>>
>> On Wed, Apr 12, 2017 at 1:26 PM, Denis Kudriashov 
>> wrote:
>>
>>>
>>> 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
>>>
>>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>



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

Re: [Pharo-users] Traits, method flatten

[Hilaire]

On a restored Traits logic of my package, I made another attempt to
persist this time with filetree://. The net result is the same, the
Traits logic is lost in the classes using the Traits: all traits methods
are duplicated !!

To sum up, package saved with the following methods:

- *.mcz package with the traits got broken. The .st source file is
~207kB of mostly duplicated methods

- filetree package got broken too

- Brave old fileout handles it just fine :) with Pharo5 (Pharo4 has UTF8
characters issues) . Source file is about 40KB


Solutions:

- Get it fixed. The problem is there since Pharo3 or 4... Not sure where
to look at.

- Escape from Traits :(

- Test on Squeak, not sure how stable it is there...

- Use fileout + CVS to persist code.

Hilaire


Le 13/04/2017 à 09:44, Hilaire a écrit :
> May be an important note, FileOut is handling just right the Traits logic.
> 
> Hilaire
> 
> 
> Le 13/04/2017 à 08:53, Nicolai Hess a écrit :
>> 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).
>>

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

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

[Igor Stasenko]

On 12 April 2017 at 14:17, 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.
>

if you run #allInstances and in between you will trigger adding instance
var & GC etc etc..
you'll have everything broken.. because there are things didn't meant to
work in certain scenarios.
IIRC allInstances is highly dependns on NOT having full GC while doing it,
and that's why all loops that
doing it is highly conservative & cautious about creating new objects while
iterating over heap.
That's the nature how #allInstance works, and you could have a tons of
issues with it regardless , if you
do full GC manually, or it triggered by VM itself. So, this is nothing to
do with migrating instances of class.


-- 
Best regards,
Igor Stasenko.

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

[teso...@gmail.com]

Hi Denis,
 in the script you are not generating instances of Class1, the problem
is with the instances.
Cheers,
Pablo

On Fri, Apr 14, 2017 at 10:04 AM, Denis Kudriashov 
wrote:

>
> 2017-04-12 13:29 GMT+02:00 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.
>>
>
> I checked on prespur cogVM: my script produced same result as on spur.
>



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

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

[Igor Stasenko]

On 14 April 2017 at 10:19, Stephane Ducasse  wrote:

> But I do not get how doing that would handle the old instances?
> Because you want to migrate the old instances.
>
>
+1
there are no such thing as 'bad zombies', if they are there, it means you
either don't care about migrating data
or again, don't care about doing #becomeForward-ing them properly.
In any case i don't see how GC could help to fix these issues. You either
have consistency or don't have it,
and GC cannot do anything magical to fix it.



> Stef
>
> On Wed, Apr 12, 2017 at 1:26 PM, Denis Kudriashov 
> wrote:
>
>>
>> 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
>>
>>
>


-- 
Best regards,
Igor Stasenko.

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

[Denis Kudriashov]

2017-04-12 13:29 GMT+02:00 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.
>

I checked on prespur cogVM: my script produced same result as on spur.

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

[Denis Kudriashov]

2017-04-14 9:19 GMT+02:00 Stephane Ducasse :

> But I do not get how doing that would handle the old instances?
> Because you want to migrate the old instances.
>

But my example shows that old instances not exist after becomeFormard
operation. Or what you mean?

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

[Stephane Ducasse]

But I do not get how doing that would handle the old instances?
Because you want to migrate the old instances.

Stef

On Wed, Apr 12, 2017 at 1:26 PM, Denis Kudriashov 
wrote:

>
> 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] Pharo 6 snap install

[Stephane Ducasse]

We always try to have a major release around mid/end of april and this is
in addition we have pharodays + several people moving to new houses :).
And deadline for projects on top.

On Thu, Apr 13, 2017 at 12:39 PM, Luke Gorrie  wrote:

> On 13 April 2017 at 12:20, Stephane Ducasse 
> wrote:
>
>> We will do that.
>>
>
> Thank you! I will wait :).
>
> Now we are under stress for the release :)
>> And PharoDays. Great conference!
>>
>
> Thank you for explaining. I am new around here ("oh, are you working on a
> release now?") so it helps me to have this kind of hint about short-term
> issues (e.g. busy period) vs long term ones (e.g. no longer making source
> releases of the VM for some reason.)
>
>
>