March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo Command Line

by Camillo Bruni

or simply read the Class comments in the image, that's basically the content shown by all the --help stuff ;) And yes it will be announced in the 2.0 release message :) On 2013-03-08, at 14:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 08 Mar 2013, at 14:50, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Sven wrote: >>> The last couple of days I have been using the new command line tools and zero conf scripts for real and I must say that I am >truly impressed and happy. >>> >>> The save, printVersion, eval, st, config and test handlers are a joy to work with. The terminal colours add a nice polish. >> >> Any documentation on it, blog posts or pharocasts available? >> >> Thx >> Torsten > > It is self-documenting ;-) > > $ ./vm.sh Pharo.image --help > > Usage: [<subcommand>] [--help] [--copyright] [--version] [--list] > --help print this help message > --copyright print the copyrights > --version print the version for the image and the vm > --list list a description of all active command line handlers > <subcommand> a valid subcommand in --list > > Documentation: > A DefaultCommandLineHandler handles default command line arguments and options. > The DefaultCommandLineHandler is activated before all other handlers. > It first checks if another handler is available. If so it will activate the found handler. > > > $ ./vm.sh Pharo.image --list > > Currently installed Command Line Handlers: > st Loads and executes .st source files > Fuel Loads fuel files > config Install and inspect Metacello Configurations from the command line > save Rename the image and changes file > test A command line test runner > update Load updates > printVersion Print image version > eval Directly evaluates passed in one line scripts > > > $ ./vm.sh Pharo.image save --help > > Usage: save <imageBaseName> [--delete-old] > <imageName> a base name for the image > --delete-old remove the old image and changes file > > Documentation: > Saves the image and changes file under a new name. > > Examples: > # create a 'bar.image' and 'foo.changes' > $PHAROVM Foo.image saveAs bar > # create the same file as in the previous example but delete Foo.image and Foo.changes > $PHAROVM Foo.image saveAs bar --delete-old > ubuntu@ip-10-32-48-109:~/t3-push$ > > > And so on... > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

March 8, 2013

Re: [Pharo-project] VM Crashes

by Camillo Bruni

> Yes I understand that I am not part of the target market. I am a person who > is trying to maintain external packages for Squeak and Pharo. Sometimes I need > to use another VM in order to do that, so I think it's a legitimate use case. You can provide a setting to disable the warning manually, which we can include in the standard distro.

March 8, 2013

Re: [Pharo-project] Pharo Command Line

by Camillo Bruni

On 2013-03-08, at 14:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > The last couple of days I have been using the new command line tools and zero conf scripts for real and I must say that I am truly impressed and happy. > > The save, printVersion, eval, st, config and test handlers are a joy to work with. The terminal colours add a nice polish. > > Thank you, Camillo ! You're welcome ;), and I hope we can extend all of that in the future because not only do I hate bash, I am always impressed about my total ignorance of that language! I simply don't know how to write proper bash scripts :D build.sh is dead, long live the command line interface!

March 8, 2013

Re: [Pharo-project] Pharo Command Line

by Sven Van Caekenberghe

On 08 Mar 2013, at 14:50, Torsten Bergmann <astares(a)gmx.de> wrote: > Sven wrote: >> The last couple of days I have been using the new command line tools and zero conf scripts for real and I must say that I am >truly impressed and happy. >> >> The save, printVersion, eval, st, config and test handlers are a joy to work with. The terminal colours add a nice polish. > > Any documentation on it, blog posts or pharocasts available? > > Thx > Torsten It is self-documenting ;-) $ ./vm.sh Pharo.image --help Usage: [<subcommand>] [--help] [--copyright] [--version] [--list] --help print this help message --copyright print the copyrights --version print the version for the image and the vm --list list a description of all active command line handlers <subcommand> a valid subcommand in --list Documentation: A DefaultCommandLineHandler handles default command line arguments and options. The DefaultCommandLineHandler is activated before all other handlers. It first checks if another handler is available. If so it will activate the found handler. $ ./vm.sh Pharo.image --list Currently installed Command Line Handlers: st Loads and executes .st source files Fuel Loads fuel files config Install and inspect Metacello Configurations from the command line save Rename the image and changes file test A command line test runner update Load updates printVersion Print image version eval Directly evaluates passed in one line scripts $ ./vm.sh Pharo.image save --help Usage: save <imageBaseName> [--delete-old] <imageName> a base name for the image --delete-old remove the old image and changes file Documentation: Saves the image and changes file under a new name. Examples: # create a 'bar.image' and 'foo.changes' $PHAROVM Foo.image saveAs bar # create the same file as in the previous example but delete Foo.image and Foo.changes $PHAROVM Foo.image saveAs bar --delete-old ubuntu@ip-10-32-48-109:~/t3-push$ And so on... -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 8, 2013

Re: [Pharo-project] VM Crashes

by Sven Van Caekenberghe

Hi Esteban, On 08 Mar 2013, at 12: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). > > 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 I used the following version CompiledMethod>>#setSourcePointer: srcPointer "We can't change the trailer of existing method, since it could have completely different format. Therefore we need to generate a copy with new trailer, containing scrPointer, and then become it." | trailer copy | trailer := CompiledMethodTrailer new sourcePointer: srcPointer. copy := self copyWithTrailerBytes: trailer. "If possible do a replace in place as an optimization" (self trailer class == trailer class and: [ self size = copy size ]) ifTrue: [ | start | start := self endPC + 1. self replaceFrom: start to: self size with: copy startingAt: start ] ifFalse: [ self becomeForward: copy ]. ^ self And it worked fine. My build completed successfully (1 try only). But it took about as long as before (10 minutes using a Cog based VM). Thanks again for the suggestion, I think we should incorporate that change, no ? The class test is ugly and most probably not necessary in the current image, I would say. Sven > 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

[Pharo-project] Pharo Command Line

by Torsten Bergmann

Sven wrote: >The last couple of days I have been using the new command line tools and zero conf scripts for real and I must say that I am >truly impressed and happy. > >The save, printVersion, eval, st, config and test handlers are a joy to work with. The terminal colours add a nice polish. Any documentation on it, blog posts or pharocasts available? Thx Torsten

March 8, 2013

[Pharo-project] Pharo Command Line

by Sven Van Caekenberghe

Hi, The last couple of days I have been using the new command line tools and zero conf scripts for real and I must say that I am truly impressed and happy. The save, printVersion, eval, st, config and test handlers are a joy to work with. The terminal colours add a nice polish. Thank you, Camillo ! Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 8, 2013

Re: [Pharo-project] VM Crashes

by David T. Lewis

On Fri, Mar 08, 2013 at 11:23:27AM +0100, stephane ducasse wrote: > > 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. I was trying to suggest a more meaningful message for the use case of a user running Pharo on a non-Pharo VM. The message says to get a newer VM, which is wrong in that case. Yes I understand that I am not part of the target market. I am a person who is trying to maintain external packages for Squeak and Pharo. Sometimes I need to use another VM in order to do that, so I think it's a legitimate use case. Dave > > > 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

[Pharo-project] Cleanup of the Zerconf scripts

by Camillo Bruni

With the release of 2.0 imminent we are going to cleanup the zeroconf scripts a bit: - the only valid VM scripts are PharoVM, StackVM and RizelVM - NBCogVM and CogVM scripts are going to be removed! so if you used ciPharo20NBCogVM.sh, use ciPharo20PharoVM.sh from now on! I will deprecate the scripts in a first step, and fully remove them within next week. I hope this won't cause too many problems, otherwise let me know.

March 8, 2013

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

by phil＠highoctane.be

'k thx. I do use FBZ since quite a while (v3), so good :-) 2013/3/8 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: > 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