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

Re: [Pharo-project] VM crash on Windows

by Andreas Raab

On 3/10/2010 11:40 PM, StÃ©phane Ducasse wrote: > did you not notice problem with the size of the log file with the appening behavior? > Because I started to have a huge file where all the crashes reports were added one by one and I was wondering if > on a server this may not be a problem (probably having a limit for the size of the report could be a good idea - but I do not know). One a production server? Do the math: 1GB of disk space costs cents. One hour of two of your engineers trying to recreate the problem or recover the information costs a few hundred bucks. That's a ratio of 10000:1. On our main server the size of the logs is 500MB going back six months or so when we reimaged it last. That's 0.1% of the disk space on the box. The other day we bought a few more TBs of cheap scratch storage which we use for throwaway VMs in QA (vmware VMs, not Squeak so it's 20+GB each). On a production server it makes no sense whatsoever to limit logging unless you're logging *excessively*. In an emergency the logs are all you have to find out what is going wrong, it's worth keeping them. Cheers, - Andreas > > Stef > > On Mar 10, 2010, at 2:12 PM, Schwab,Wilhelm K wrote: > >> Andreas, >> >> I will give that a try. I think it should be active by default, but it won't matter too much once I modify the shortcuts on a few boxes. Other wish list items would be to have a similar option on Linux and to ensure that the contents of the log are concatenated vs. replaced with each crash. >> >> Thanks!! >> >> Bill >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Andreas Raab >> Sent: Wednesday, March 10, 2010 12:32 AM >> To: Pharo Development >> Subject: Re: [Pharo-project] VM crash on Windows >> >> Hi Bill - >> >> If you have problems like these consider cross-posting to squeak-dev or vm-dev. I only check Pharo in irregular intervals. >> >> On 3/8/2010 4:27 PM, Schwab,Wilhelm K wrote: >>> I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. >> >> The issue you're seeing is caused by a recursive MessageNotUnderstood error. You can easily recreate this by doing the following: >> >> ((ProtoObject subclass: #Bummerator >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Kernel-Objects') >> superclass: nil; >> new) bummer. >> >> The reason why that doesn't result in a regular crash.dmp is that the support code (which catches the crashes and writes the dump) isn't involved at all. The interpreter just quits. >> >> Contrast this with, say the result of an FFI crash: >> >> (ExternalLibraryFunction >> name:'' module: '' callType: 0 >> returnType: ExternalType void argumentTypes: #()) >> setHandle: ((ExternalAddress new) at: 1 put: 1; yourself); >> invoke >> >> This does generate a crash.dmp since the support code can catch the problem. >> >> However, to catch the former issue you can run the vm with -log: >> <logfile> which will contain the resulting output. >> >>> The rebuttal: if it has time/ability to write information all over part of the screen, it can open a file and make sure it leaves a trace of what happened. Right? The current vms (Windows and Linux) appear to be totally disinterested in logging crashes, and that needs to change. >> >> They do if you tell 'em to. >> >> Cheers, >> - Andreas >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 11, 2010

Re: [Pharo-project] How I build squeak-vm with FT2Plugin on Linux

by laurent laffont

Great ! Can we merge our respective posts and put this on the Pharo wiki ? I don't have write access to the wiki. Do you know if there's an equivalent tutorial for windows ? I will try with the svn trunk. Laurent Laffont On Thu, Mar 11, 2010 at 8:38 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Laurent, > > Nice! I just did the same the other day ;) > > My blog post describes step by step how to build a Unix VM from scratch on > OSX: > > > http://www.adrian-lienhard.ch/blog?article=building-a-pharo-squeak-vm-from-… > > Please note that you are using the 3.11.3.*2135* sources, which produce a > VM with terrible performance. The reason is that they don't have the > gnuification step that creates a jump table instead of the case switch for > the interpreter loop. I use the most recent source from SVN (r2151) and the > bytecodes/s is 479400749 compared to 248543689. > > Cheers, > Adrian > > > > On Mar 10, 2010, at 23:24 , laurent laffont wrote: > > > Hi, > > > > As a memento for me, I've written a tutorial to build the VM on Linux. > > > http://magaloma.blogspot.com/2010/03/how-i-build-squeak-vm-on-archlinux.html > > > > I also provide the binaries and Pharo image with VMMaker loaded. > > > > As I'm newbie on building a VM, thanks for additional informations. > > > > Cheers, > > > > Laurent Laffont > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 11, 2010

[Pharo-project] Code bubbles

by StÃ©phane Ducasse

The kind of stuff I would have love to see people experimenting with Squeak. We failed to be sexy on the UI level. Stef > > > Ideas for IDE UIs > http://www.cs.brown.edu/people/acb/codebubbles_site.htm > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > > > > _______________________________________________ > Lsehub-staff mailing list > Lsehub-staff(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/lsehub-staff

March 11, 2010

Re: [Pharo-project] VM crash on Windows

by StÃ©phane Ducasse

bill did you not notice problem with the size of the log file with the appening behavior? Because I started to have a huge file where all the crashes reports were added one by one and I was wondering if on a server this may not be a problem (probably having a limit for the size of the report could be a good idea - but I do not know). Stef On Mar 10, 2010, at 2:12 PM, Schwab,Wilhelm K wrote: > Andreas, > > I will give that a try. I think it should be active by default, but it won't matter too much once I modify the shortcuts on a few boxes. Other wish list items would be to have a similar option on Linux and to ensure that the contents of the log are concatenated vs. replaced with each crash. > > Thanks!! > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Andreas Raab > Sent: Wednesday, March 10, 2010 12:32 AM > To: Pharo Development > Subject: Re: [Pharo-project] VM crash on Windows > > Hi Bill - > > If you have problems like these consider cross-posting to squeak-dev or vm-dev. I only check Pharo in irregular intervals. > > On 3/8/2010 4:27 PM, Schwab,Wilhelm K wrote: >> I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. > > The issue you're seeing is caused by a recursive MessageNotUnderstood error. You can easily recreate this by doing the following: > > ((ProtoObject subclass: #Bummerator > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Kernel-Objects') > superclass: nil; > new) bummer. > > The reason why that doesn't result in a regular crash.dmp is that the support code (which catches the crashes and writes the dump) isn't involved at all. The interpreter just quits. > > Contrast this with, say the result of an FFI crash: > > (ExternalLibraryFunction > name:'' module: '' callType: 0 > returnType: ExternalType void argumentTypes: #()) > setHandle: ((ExternalAddress new) at: 1 put: 1; yourself); > invoke > > This does generate a crash.dmp since the support code can catch the problem. > > However, to catch the former issue you can run the vm with -log: > <logfile> which will contain the resulting output. > >> The rebuttal: if it has time/ability to write information all over part of the screen, it can open a file and make sure it leaves a trace of what happened. Right? The current vms (Windows and Linux) appear to be totally disinterested in logging crashes, and that needs to change. > > They do if you tell 'em to. > > Cheers, > - Andreas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 11, 2010

Re: [Pharo-project] How I build squeak-vm with FT2Plugin on Linux

by Adrian Lienhard

Hi Laurent, Nice! I just did the same the other day ;) My blog post describes step by step how to build a Unix VM from scratch on OSX: http://www.adrian-lienhard.ch/blog?article=building-a-pharo-squeak-vm-from-… Please note that you are using the 3.11.3.*2135* sources, which produce a VM with terrible performance. The reason is that they don't have the gnuification step that creates a jump table instead of the case switch for the interpreter loop. I use the most recent source from SVN (r2151) and the bytecodes/s is 479400749 compared to 248543689. Cheers, Adrian On Mar 10, 2010, at 23:24 , laurent laffont wrote: > Hi, > > As a memento for me, I've written a tutorial to build the VM on Linux. > http://magaloma.blogspot.com/2010/03/how-i-build-squeak-vm-on-archlinux.html > > I also provide the binaries and Pharo image with VMMaker loaded. > > As I'm newbie on building a VM, thanks for additional informations. > > Cheers, > > Laurent Laffont > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 11, 2010

Re: [Pharo-project] VM crash on Windows

by Andreas Raab

Hi Bill - The just released 3.11.8 VM does take care of the issue you're reporting. It creates a proper crash.dmp for all of the cases that would previously silently quit. Try that doIt below in with 3.11.8 to compare to the previous behavior. Cheers, - Andreas On 3/10/2010 5:12 AM, Schwab,Wilhelm K wrote: > Andreas, > > I will give that a try. I think it should be active by default, but it won't matter too much once I modify the shortcuts on a few boxes. Other wish list items would be to have a similar option on Linux and to ensure that the contents of the log are concatenated vs. replaced with each crash. > > Thanks!! > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Andreas Raab > Sent: Wednesday, March 10, 2010 12:32 AM > To: Pharo Development > Subject: Re: [Pharo-project] VM crash on Windows > > Hi Bill - > > If you have problems like these consider cross-posting to squeak-dev or vm-dev. I only check Pharo in irregular intervals. > > On 3/8/2010 4:27 PM, Schwab,Wilhelm K wrote: >> I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. > > The issue you're seeing is caused by a recursive MessageNotUnderstood error. You can easily recreate this by doing the following: > > ((ProtoObject subclass: #Bummerator > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Kernel-Objects') > superclass: nil; > new) bummer. > > The reason why that doesn't result in a regular crash.dmp is that the support code (which catches the crashes and writes the dump) isn't involved at all. The interpreter just quits. > > Contrast this with, say the result of an FFI crash: > > (ExternalLibraryFunction > name:'' module: '' callType: 0 > returnType: ExternalType void argumentTypes: #()) > setHandle: ((ExternalAddress new) at: 1 put: 1; yourself); > invoke > > This does generate a crash.dmp since the support code can catch the problem. > > However, to catch the former issue you can run the vm with -log: > <logfile> which will contain the resulting output. > > > The rebuttal: if it has time/ability to write information all over part of the screen, it can open a file and make sure it leaves a trace of what happened. Right? The current vms (Windows and Linux) appear to be totally disinterested in logging crashes, and that needs to change. > > They do if you tell 'em to. > > Cheers, > - Andreas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 11, 2010

Re: [Pharo-project] Collection >> collectDistinct: ??

by StÃ©phane Ducasse

> > So try it with randomized data: > > a := (1 to: 1000000) asArray shuffled. > > Smalltalk garbageCollect. > [ a collect: #yourself as: Set ] timeToRun. "==> 4143" > > Smalltalk garbageCollect. > [ a asSet ] timeToRun. "==> 3995". > > | s | > s := Set new. > Smalltalk garbageCollect. > [ s addAll: a ] timeToRun. "==> 157304 oops weak hashes". > > | s | > s := Set new: 1000000. > Smalltalk garbageCollect. > [ s addAll: a ] timeToRun. "==> 636". > > > With better hashes: levente how do you determine that you use better hashes below > a := Set new: 1000000. > [ a size < 1000000 ] whileTrue: [ > a add: SmallInteger maxVal atRandom ]. > a := a asArray. > > Smalltalk garbageCollect. > [ a collect: #yourself as: Set ] timeToRun. "==> 3895" > > Smalltalk garbageCollect. > [ a asSet ] timeToRun. "==> 3777". > > | s | > s := Set new. > Smalltalk garbageCollect. > [ s addAll: a ] timeToRun. "==> 4729 much better". > > | s | > s := Set new: 1000000. > Smalltalk garbageCollect. > [ s addAll: a ] timeToRun. "==> 774". > > > Conclusions: > - #collect:as: is (almost) as fast as #asSet > - better hashes can make a huge difference > - message sends cost a lot compared to bytecodes > - if you can guess the size of your collection, do it (applies for all growing collections and collection streaming) yes!! > - only optimize if you have to in your own code > > > Levente > >> -- >> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 >> <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> >> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 11, 2010

Re: [Pharo-project] Collection >> collectDistinct: ??

by StÃ©phane Ducasse

Yes I remember when I was against { . } :) On Mar 11, 2010, at 1:54 AM, Nicolas Cellier wrote: > 2010/3/11 Igor Stasenko <siguctua(a)gmail.com>: >> On 10 March 2010 15:07, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> self collect: aBlock as: Set >>> >> >> One more time, i found this very beatiful and useful extension to >> Collection protocol. >> And i am proud being a witness when this thing is born! :) >> > > Yes, > I remember saying I was not convinced some times ago... > http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129457.html > Being able to change own opinion is a good thing ! > > Nicolas > >>> 2010/3/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>> Hi. I was needing something like the SQL select distinct, that doesn't take >>>> into account repeated objects. I didn't found anything useful in Collection, >>>> and thus, I have implemented this: >>>> >>>> Collection >> collectDistinct: aBlock >>>> >>>> >>>> collectDistinct: aBlock >>>> "Evaluate aBlock with each of the receiver's elements as the argument. >>>> Collect the resulting values into a Set, thus repeated objects will not >>>> be present. >>>> Answer the new collection." >>>> >>>> | newSet | >>>> newSet := self species new asSet. >>>> self do: [:each | newSet add: (aBlock value: each)]. >>>> ^ newSet >>>> >>>> >>>> Is there a better way ? Do you think it make sense to put this in Pharo ? >>>> >>>> Cheers >>>> >>>> Mariano >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 11, 2010

Re: [Pharo-project] [Pharo Project] Installer / Installer Monticello

by StÃ©phane Ducasse

Thanks Norberto. May be you can publish your fixes directly to the installer repository We use Gofer to script MC. Give a try because this is good. Did you have a look at it? Stef On Mar 11, 2010, at 12:24 AM, Norberto Manzanos wrote: > > > I found some bugs in Installer and InstallerMonticello packages. Is this the properly forum to report them? > If not, sorry for bother you. > > InstallerMonticello >>mcDetectFileBlock: > The detection is made with #beginsWith:, but if you have two different packages which begins with the same string, it would detect a wrong package. > Reeplaced by #copyUpToLast: $- > > InstallerMonticello >>mcSortFileBlock > If the file has no number (it could happen, yes, and it happened to me with a file create by MonticelloConfiguration, which I didn't remember it existed) the files collection is sorted wrongly, since #asInteger will answer nil. > Replaced #asInteger by #asNumber > I made other modifications, but I'm not sure they are part of the developing plan of the package. > Errors are logued only with an output on the Transcript, so it's very > difficult to separate errors form manu other messages shown there. > I add a #logErr: method which adds the string to a new instance variable in. > > I attached the package. > <Installer-Core-nm.344.mcz>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 11, 2010

Re: [Pharo-project] freeNamesAndValues

by Marcus Denker

On Mar 10, 2010, at 11:01 PM, StÃ©phane Ducasse wrote: > ok it was removed by pavel so this is a good move This is a leftover NewCompiler hacks/code... I already cleaned up most, should do another pass. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 11, 2010