- Pharo-dev - lists.pharo.org

Re: [Pharo-project] https://pharo.fogbugz.com : can I have an account there?

by Benjamin

For now we are just migrating, but soon the doors will be open :) Steps needed before official announcement: - Migrate all issues ( we are currently at 7026 issues migrated) - Deploy the Penelope website (to register easily to the issue tracker and have a list of open issues) - Fix dependency between issues (blockedOn:) - Polish a bit statuses in fogbugz The plan is to announce it at the same time that the announcement of Pharo2.0 release :) Ben On Mar 8, 2013, at 11:13 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > patience, patience :D, we will announce that pretty soon. > until then you can still report on the old issue tracker. > > On 2013-03-08, at 10:51, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> How to do? >> >> Guess bug reporting occurs there now. >> >> Regards, >> Phil >> > >

March 8, 2013

Re: [Pharo-project] VM Crashes

by Frank Shearar

On 8 March 2013 11:44, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Sven, > > One of the problems we currently have is that all method installation execute a becomeForward:, which is of course not terrible cleaver... I tried using the squeak implementation of it and everything looks working (and it has a small optimization that can help). When do you call #becomeForward:? Do you do it for each method? #becomeForward: costs the same to change 1 object as it does 1000. On my rubbish laptop that's 6ms per #becomeForward. If I recall correctly, it's only when you're becoming several thousand objects that it starts taking longer. So if you can batch-become - using myOldMethods elementsForwardIdentityTo: myNewMethods - per package, maybe that would help speed things up? frank > Can you trying the load by installing it? > > CompiledMethod>>#setSourcePointer: srcPointer > "We can't change the trailer of existing method, since it could have a > completely different format. Therefore we need to generate a copy > with new trailer, containing a srcPointer, and then #become it." > | trailer copy start | > > trailer := srcPointer = 0 > ifTrue: [ > "catch the common case of setting the source pointer to 0 when already 0" > self sourcePointer = 0 ifTrue: [ ^ self ]. > CompiledMethodTrailer empty ] > ifFalse: [ > CompiledMethodTrailer new sourcePointer: srcPointer ]. > copy := self copyWithTrailerBytes: trailer. > > "ar 3/31/2010: Be a bit more clever since #become: is slow. > If the old and the new trailer have the same size, just replace it." > (self trailer class == trailer class and:[ self size = copy size ]) > ifTrue: [ > start := self endPC + 1. > self replaceFrom: start to: self size with: copy startingAt: start ] > ifFalse: [ > self becomeForward: copy ]. > > ^self "will be copy if #become was needed" > > this can help in the speed and also can help on the vm crash problem (even if it is a workaround)... > > Esteban > > > > On Mar 8, 2013, at 11:53 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 08 Mar 2013, at 11:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> But I have said this before: the wall clock time of loading a lot of code is actually close to unacceptable - I don't think it is the download or the compilation, but more all the dynamic stuff that happens after that. There should be a way to not do all those updates for each method and move the updates to one big batch update after the load - if that is possible. >> >> To continue my rant (sorry ;-) about the problem with slow code loading. >> >> These are some benchmarks on the same machine: >> >> $ ./vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' >> 106532 >> >> $ ./stack/vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' >> 221708 >> >> So it takes like 3 minutes to recompile every method in the system. >> >> How in the hell can it take 40 minutes to load some code (with all packages already present in the package-cache (but then again the package-cache is only 3.5 Mb, which could be downloaded in seconds)) ? >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> > >

March 8, 2013

Re: [Pharo-project] VM Crashes

by Esteban Lorenzano

Hi Sven, One of the problems we currently have is that all method installation execute a becomeForward:, which is of course not terrible cleaver... I tried using the squeak implementation of it and everything looks working (and it has a small optimization that can help). Can you trying the load by installing it? CompiledMethod>>#setSourcePointer: srcPointer "We can't change the trailer of existing method, since it could have a completely different format. Therefore we need to generate a copy with new trailer, containing a srcPointer, and then #become it." | trailer copy start | trailer := srcPointer = 0 ifTrue: [ "catch the common case of setting the source pointer to 0 when already 0" self sourcePointer = 0 ifTrue: [ ^ self ]. CompiledMethodTrailer empty ] ifFalse: [ CompiledMethodTrailer new sourcePointer: srcPointer ]. copy := self copyWithTrailerBytes: trailer. "ar 3/31/2010: Be a bit more clever since #become: is slow. If the old and the new trailer have the same size, just replace it." (self trailer class == trailer class and:[ self size = copy size ]) ifTrue: [ start := self endPC + 1. self replaceFrom: start to: self size with: copy startingAt: start ] ifFalse: [ self becomeForward: copy ]. ^self "will be copy if #become was needed" this can help in the speed and also can help on the vm crash problem (even if it is a workaround)... Esteban On Mar 8, 2013, at 11:53 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 08 Mar 2013, at 11:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> But I have said this before: the wall clock time of loading a lot of code is actually close to unacceptable - I don't think it is the download or the compilation, but more all the dynamic stuff that happens after that. There should be a way to not do all those updates for each method and move the updates to one big batch update after the load - if that is possible. > > To continue my rant (sorry ;-) about the problem with slow code loading. > > These are some benchmarks on the same machine: > > $ ./vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' > 106532 > > $ ./stack/vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' > 221708 > > So it takes like 3 minutes to recompile every method in the system. > > How in the hell can it take 40 minutes to load some code (with all packages already present in the package-cache (but then again the package-cache is only 3.5 Mb, which could be downloaded in seconds)) ? > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

March 8, 2013

Re: [Pharo-project] VM Crashes

by Sven Van Caekenberghe

On 08 Mar 2013, at 11:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > But I have said this before: the wall clock time of loading a lot of code is actually close to unacceptable - I don't think it is the download or the compilation, but more all the dynamic stuff that happens after that. There should be a way to not do all those updates for each method and move the updates to one big batch update after the load - if that is possible. To continue my rant (sorry ;-) about the problem with slow code loading. These are some benchmarks on the same machine: $ ./vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 106532 $ ./stack/vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 221708 So it takes like 3 minutes to recompile every method in the system. How in the hell can it take 40 minutes to load some code (with all packages already present in the package-cache (but then again the package-cache is only 3.5 Mb, which could be downloaded in seconds)) ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 8, 2013

Re: [Pharo-project] VM Crashes

by stephane ducasse

On Mar 8, 2013, at 2:52 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Thu, Mar 07, 2013 at 11:23:22PM +0100, Sven Van Caekenberghe wrote: >> Hi Eliot, >> >> On 07 Mar 2013, at 23:12, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> I seem to be talking to thin air. If you would use an up-to-date VM your crashes would disappear. This bug was fixed this last week. You are using a VM from December of last year. Of course if you don't want to fix your bug lease continue to ignore anything I might have to say. >> >> I tried using your latest cog vm, but the Pharo 2.0 image side check complained: >> >> checkVMVersion >> "Display a warning if the VM is too old" >> | displayError | >> displayError := [ ^ self inform: 'Your VM is too old for this image. Please download the latest VM.' ]. >> [(VirtualMachine interpreterSourceDate > '2012-07-08+2:00' asDate) >> ifFalse: displayError >> ] on: Error do: [ :e| displayError value ]. >> >> I was unsure if this was a real problem or not ? > > This method in the image is completely wrong and misleading. The VM that > was being used is clearly *not* out of date. If the intent is to give the > user a message that says "please use only the latest Pharo VM", then it should > say so. I do not understand why. I want to know that I'm not using a VM supporting fileplugin latest addition. > To check explicitly for a Pharo VM I would suggest adding a primitive or VM > parameter that identifies the VM as Pharo-specific so the checkVMVersion can > distinguish an out-of-date Pharo VM and provide an appropriate warning message. > > It is really not fair to ask Eliot to spend his time debugging "Cog problems" > when the image is sending incorrect error messages. > > Dave > >

March 8, 2013

Re: [Pharo-project] please add me to phexample

by stephane ducasse

On Mar 8, 2013, at 9:31 AM, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > Hi Doru: > > On 08 Mar 2013, at 06:54, Tudor Girba wrote: > >> The #development version of ConfigurationOfPhexample points to a hardcoded version. Phexample is used extensively in Fame, and Fame is a Moose project, and we have the convention that the Moose projects should have the #development version point to a baseline. >> >> Please add me to the project so that I can fix the configuration. > > I added you. > > But, please, before you fix the configuration, have a look at Stef's solution to the #includesSubString: vs. #includesSubstring: issue between Pharo 1.4 and Pharo 2.0. > > His solution is to use Phexample-StefanMarr.67 as Pharo 2.0 implementation and Phexample-StephaneDucasse.68 as Pharo 1.4 version. See [1]. > > I don't think this is maintainable, but did not yet get around to do it properly. just republishing 67 as 69 can also work to support development in 2.0. > > Thanks > Stefan > > [1] http://smalltalkhub.com/#!/~Phexample/Phexample/diff/Phexample-StephaneDuca… > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

March 8, 2013

Re: [Pharo-project] VM Crashes

by Sven Van Caekenberghe

On 07 Mar 2013, at 17:30, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I hope you can reproduce this ... Well, here is another datapoint. The bigger build that I was doing and that fails a lot with the reported crash.dmp worked twice and has not yet failed with the StackVM, although it takes a ridiculous long time (40 minutes). For the problem I saw, this VM is reliable: $ ./stack/vm.sh -version 3.9-7 #1 Mon Nov 19 19:12:44 CET 2012 gcc 4.1.2 StackInterpreter VMMaker-oscog-EstebanLorenzano.166 uuid: 5773fcb9-2982-4507-8a9e-4308ec33731e Nov 19 2012 git://gitorious.org/cogvm/blessed.git Commit: 40ac7e7bdec6fef0e934d2c019b86db996053912 Date: 2012-11-19 18:54:49 +0100 By: Mariano Martinez Peck <marianopeck(a)gmail.com> Jenkins build #3 Linux pharo-build.lille.inria.fr 2.6.18-194.26.1.el5xen #1 SMP Tue Nov 9 14:13:46 EST 2010 i686 i686 i386 GNU/Linux plugin path: /home/ubuntu/t3-push/stack/vm/stack-linux-latest/ [default: /home/ubuntu/t3-push/stack/vm/stack-linux-latest/] I tried yesterday to come up with some public code to load to generate the problem, but I did not succeed yet. The build that I am doing is a Configuration that depends on a couple of other Configurations, it is not small, but I would not call it massive. Seaside is certainly bigger, and Moose is probably many times as large. But I have said this before: the wall clock time of loading a lot of code is actually close to unacceptable - I don't think it is the download or the compilation, but more all the dynamic stuff that happens after that. There should be a way to not do all those updates for each method and move the updates to one big batch update after the load - if that is possible. C++ is notoriously slow to compile because of all the static type checking and the amount of context that is needed to understand a piece of code. One of the main reasons to start Go was the slow build times, and Go remains statically typed. Smalltalk is dynamically typed and late bound in everything, surely it should be possible to make our code loading process faster. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 8, 2013

Re: [Pharo-project] https://pharo.fogbugz.com : can I have an account there?

by Camillo Bruni

patience, patience :D, we will announce that pretty soon. until then you can still report on the old issue tracker. On 2013-03-08, at 10:51, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > How to do? > > Guess bug reporting occurs there now. > > Regards, > Phil >

March 8, 2013

[Pharo-project] https://pharo.fogbugz.com : can I have an account there?

by phil＠highoctane.be

How to do? Guess bug reporting occurs there now. Regards, Phil

March 8, 2013

Re: [Pharo-project] VM Crashes

by Igor Stasenko

On 8 March 2013 10:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 08 Mar 2013, at 09:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> On 2013-03-08, at 02:52, "David T. Lewis" <lewis(a)mail.msen.com> wrote: >> >>> On Thu, Mar 07, 2013 at 11:23:22PM +0100, Sven Van Caekenberghe wrote: >>>> Hi Eliot, >>>> >>>> On 07 Mar 2013, at 23:12, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>>> I seem to be talking to thin air. If you would use an up-to-date VM your crashes would disappear. This bug was fixed this last week. You are using a VM from December of last year. Of course if you don't want to fix your bug lease continue to ignore anything I might have to say. >>>> >>>> I tried using your latest cog vm, but the Pharo 2.0 image side check complained: >>>> >>>> checkVMVersion >>>> "Display a warning if the VM is too old" >>>> | displayError | >>>> displayError := [ ^ self inform: 'Your VM is too old for this image. Please download the latest VM.' ]. >>>> [(VirtualMachine interpreterSourceDate > '2012-07-08+2:00' asDate) >>>> ifFalse: displayError >>>> ] on: Error do: [ :e| displayError value ]. >>>> >>>> I was unsure if this was a real problem or not ? >>> >>> This method in the image is completely wrong and misleading. The VM that >>> was being used is clearly *not* out of date. If the intent is to give the >>> user a message that says "please use only the latest Pharo VM", then it should >>> say so. >> >> Pharo ships with the PharoVM, hence the targeted audience will have an outdated >> PharoVM, we can make the message more explicit, but it IS an outdate VM no matter >> what. >> >> Besides, we print the VM version date in a different format, which won't lead to >> a parsing error. If you run this on a VM not built by us you get a VM out of date. >> >>> To check explicitly for a Pharo VM I would suggest adding a primitive or VM >>> parameter that identifies the VM as Pharo-specific so the checkVMVersion can >>> distinguish an out-of-date Pharo VM and provide an appropriate warning message. >> >> yes we could update the error message to inform that the user should download >> the latest PharoVM. But as I said before, Pharo is shipped with the branded >> PharoVM, to limit the confusion for newcomers. CogVM, NBCogCM, StackVM, SqueakVM >> and guess not what other names are simply not parseable by newcomers. >> >>> It is really not fair to ask Eliot to spend his time debugging "Cog problems" >>> when the image is sending incorrect error messages. >> >> well, he is free to adopt our additions we made to the FileSystem primitives and >> integrate NativeBoost. >> >> Only if those are integrated I see reason to make this error message disappear on >> other VMs than ours. Otherwise not displaying the error message is misleading >> behavior as well FOR THE WHOLE COMMUNITY. > > Thanks for the explanation, Camillo. > > The crux of the matter is the point about the FileSystem primitives and NativeBoost. > The test itself is misleading as it only seems to check a date and then declares VM's too old. > Maybe it should test for the primitives, if that is possible. > Also the warning 'Too old' should be changed to 'Does not contain the necessary primitives to run Pharo' if I understand correctly. > hmm.. then your tests will define "today's old VM" but since things are moving, you have to throw this test away fairly soon.. to avoid that, i would check the version / VM release date.. but not some concrete feature, because at longer time scale it makes no sense. And to cover features, we have unit tests :) > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > -- Best regards, Igor Stasenko.

March 8, 2013