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

Re: [Pharo-project] [Vm-dev] Re: Issue 3446 in pharo: VMMakerTool load config buttondoesn't work

by Levente Uzonyi

On Fri, 17 Dec 2010, David T. Lewis wrote: > > On Fri, Dec 17, 2010 at 06:39:33PM +0100, Levente Uzonyi wrote: >> >> On Fri, 17 Dec 2010, Javier Pim?s wrote: >> >>> OK, if I'm correct the 3449 issue is fixed and integrated now. So how do we >>> solve this one? Because the method lays on VMMakerTool's code, for squeak. >>> Maybe we can add a line to ConfigurationOfVMMaker>>#fixVMMakerForPharo like >>> this: > > <snip> > >>> It's a bit of a dirty hack, maybe there's a cleaner way. What do you think? >> >> No need to do dirty hacks, just communicate your needs properly. Ask David >> to update the method. Squeak (since 3.9) also implements UIManager >> >> #chooseFileMatching:label:. Note that the name of this method is a bit >> misleading. The first argument is a list of "file extensions", not a list >> of patterns. So this should work in both Squeak and Pharo: >> >> fileResult := UIManager default >> chooseFileMatching: #('config') >> label: 'Select VMMaker configuration...'. >> >> Since fileResult is a string that contains the full path, the variable >> "file" is not necessary anymore. > > This is in VMMaker-dtl.211. > > The #saveConfig method had a similar problem, so I changed it to > use UIManager>>request:initialAnswer: > > Both methods should work on Squeak/Pharo now. Thanks. Levente > > Thanks, > Dave > >

Dec. 18, 2010

Re: [Pharo-project] [squeak-dev] a slim holiday present, cpic

by Igor Stasenko

On 18 December 2010 01:44, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Fri, Dec 17, 2010 at 02:33:08PM -0800, Eliot Miranda wrote: >> Hi All, >> >> Â Â don't know if this is useful to you or whether you've already written it >> yourself but I finally caved and wrote a shell command that copies an >> image/changes file pair, replacing the hundreds of times I've issued the two >> parallel commands, cpic = copy image and changes. Â Happy holidays > > Very nice holiday stocking stuffer, works a champ. Thanks! > Ohh.. today is a day of shell scripts. I did one too. costs me about 2 hours to make it right. It simply gets the freetype library and builds it with right arch. Because by default this piece of ... builds with x64 target arch, which obviously does not fits for Cog :( ----- if [ ! -d freetype2 ] then /usr/local/git/bin/git clone git://git.sv.gnu.org/freetype/freetype2.git fi cd freetype2 /usr/local/git/bin/git checkout VER-2-4-4 /bin/sh autogen.sh ./configure CFLAGS="-arch i386" LDFLAGS="-arch i386" --without-zlib /usr/bin/make clean /usr/bin/make 2>1 > ../build.log cd .. cp ./freetype2/objs/.libs/libfreetype.a ./ ----- but i'm still not satisfied how it integrated into xcode to build FT2Plugin. Well, at least i got it built. > Dave > > > -- Best regards, Igor Stasenko AKA sig.

Dec. 18, 2010

Re: [Pharo-project] [squeak-dev] a slim holiday present, cpic

by David T. Lewis

On Fri, Dec 17, 2010 at 02:33:08PM -0800, Eliot Miranda wrote: > Hi All, > > don't know if this is useful to you or whether you've already written it > yourself but I finally caved and wrote a shell command that copies an > image/changes file pair, replacing the hundreds of times I've issued the two > parallel commands, cpic = copy image and changes. Happy holidays Very nice holiday stocking stuffer, works a champ. Thanks! Dave

Dec. 18, 2010

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by Sven Van Caekenberghe

Philippe, First of all, thanks a lot for taking the time doing these benchmarks. I know you are very well placed to do these test, so I am honored you did. Second, although this is a static page bypassing encoding, the results are very impressive indeed. It is still Seaside and a 16KB page. Furthermore, all request completed successfully with a good distribution. This makes me quite happy! I do however suspect some serious hardware being used. Could you elaborate on the hardware, OS, VM and other details ? Regards, Sven On 17 Dec 2010, at 20:52, Philippe Marschall wrote: > On 15.12.2010 17:04, Sven Van Caekenberghe wrote: >> I am pleased to report another milestone was reached in the Zn project. >> >> The default implementation for an HTTP Server is now a multi-threaded (forking) keep-alive implementation called ZnMultiThreadedServer. It passes my initial concurrent load tests. ZnServer is now a facade. This means that all features (test server, static file server, monticello server, seaside adaptor, as well as all unit tests) are now using the new code. >> >> In addition, several useful features were added to the servers, including logging and lastRequest/lastResponse debugging hooks. Extra handlers were added to ZnDefaultServerDelegate (favicon, benchmark, random) which double as examples. >> >> Next up will be some benchmarking and optimalization. As always, users/testers are most welcome. > > This is with the AJPFastRequestHandler from the AJP-Benchmark package > from http://www.squeaksource.com/ajp (there are no dependencies to AJP). > > ab -k -c 10 -n 10000 http://127.0.0.1:8080/fast > This is ApacheBench, Version 2.3 <$Revision: 655654 $> > Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ > Licensed to The Apache Software Foundation, http://www.apache.org/ > > Benchmarking 127.0.0.1 (be patient) > Completed 1000 requests > Completed 2000 requests > Completed 3000 requests > Completed 4000 requests > Completed 5000 requests > Completed 6000 requests > Completed 7000 requests > Completed 8000 requests > Completed 9000 requests > Completed 10000 requests > Finished 10000 requests > > > Server Software: Zinc > Server Hostname: 127.0.0.1 > Server Port: 8080 > > Document Path: /fast > Document Length: 16294 bytes > > Concurrency Level: 10 > Time taken for tests: 5.624 seconds > Complete requests: 10000 > Failed requests: 0 > Write errors: 0 > Keep-Alive requests: 10000 > Total transferred: 164560000 bytes > HTML transferred: 162940000 bytes > Requests per second: 1778.08 [#/sec] (mean) > Time per request: 5.624 [ms] (mean) > Time per request: 0.562 [ms] (mean, across all concurrent requests) > Transfer rate: 28574.28 [Kbytes/sec] received > > Connection Times (ms) > min mean[+/-sd] median max > Connect: 0 0 0.0 0 0 > Processing: 0 6 17.1 1 155 > Waiting: 0 6 17.1 0 155 > Total: 0 6 17.1 1 155 > > Percentage of the requests served within a certain time (ms) > 50% 1 > 66% 1 > 75% 1 > 80% 1 > 90% 15 > 95% 44 > 98% 70 > 99% 89 > 100% 155 (longest request) > > Not too shabby. > > Cheers > Philippe

Dec. 17, 2010

Re: [Pharo-project] Automated VM build server

by Igor Stasenko

On 17 December 2010 23:11, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Packages would be nice, but I think a more important goal is to get the vm to describe error conditions. Â If it did that reliably, I would have been completely content to unzip a binary and write a shell script, or just use a one-click image. Â Of the things that are under reported, the most notable is when a shared library does not load, where did the vm look for it? Â One gives it a name via #moduleName, but the vm modifies it and then tries to load using the result. Â If it fails, it needs to say where it looked. Â What was the error code? > This problem lies in different plane: improving the VM code for error reporting. But first we need to build VM. Once we have it, we can play with various options, configurations, settings and so on. And then like biologists, we can afford simply put a dozens of various micro-cultures into incubator (vm configs into build server) and come back next day and see which culture having higher chances to survive (faster, less red tests and error reports) :) > Bill > -- Best regards, Igor Stasenko AKA sig.

Dec. 17, 2010

[Pharo-project] a slim holiday present, cpic

by Eliot Miranda

Hi All, don't know if this is useful to you or whether you've already written it yourself but I finally caved and wrote a shell command that copies an image/changes file pair, replacing the hundreds of times I've issued the two parallel commands, cpic = copy image and changes. Happy holidays -------8<------- #!/bin/sh # copy image and changes force=0 if [ "$1" = -f ]; then force=1 shift fi if [ $# != 2 -o "$1" = "-?" -o "$1" = --help ]; then echo "usage: $0 [-f] image-name-no-ext [image-name-no-ext|dir]" test $# != 2 && exit 1 exit 0 fi if [ -f "$2.image" -o -f "$2.changes" ]; then if [ "$force" = 0 ]; then echo "$2.image and/or $2.changes already exist." 1>&2 exit 1 fi elif [ -d "$2" ]; then if [ -f "$2/$1.image" -o -f "$2/$1.changes" ]; then if [ "$force" = 0 ]; then echo "$2/$1.image and/or $2/$1.changes already exist." 1>&2 exit 1 fi fi cp "$1.image" "$1.changes" "$d" exit 0 fi cp "$1.image" "$2.image" cp "$1.changes" "$2.changes"

Dec. 17, 2010

Re: [Pharo-project] Automated VM build server

by Igor Stasenko

On 17 December 2010 22:37, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Fri, Dec 17, 2010 at 9:17 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> In our nearest plans is make an automated (Hudson based) build setup >> for Cog and Squeak VMs. >> >> > > this is cool igor!!! > >> >> a) image version (or its URL(s) for download) >> b) script for loading VMMaker (of concrete version) > > but how can you set a concrete version if the buid is automatic ? how do you > know which version of VMMaker and ALL its dependencies? we will collect necessary info bit by bit. Obviously, this knowledge is already sits over there, in image, otherwise how else we manage to build VMs till those days? I just want to automate it, which will leave less space for human mistake. > are you going to use ConfigurationOfVMMaker ?Â if true, how is going to > maintain it? > i am not quite sure if metacello will be capable to keep all this info. Some things may require using changesets or other kind of non-packageable messy code. We will see. Things are scary from distance :) In any case i don't think that a config, which fully describing a conglomerate used to generate VM sources and plugins is any bit worse than image which contains same info. Except that you can't diff two smalltalk images to see what difference between them. -- Best regards, Igor Stasenko AKA sig.

Dec. 17, 2010

Re: [Pharo-project] Automated VM build server

by Schwab,Wilhelm K

Sig, Packages would be nice, but I think a more important goal is to get the vm to describe error conditions. If it did that reliably, I would have been completely content to unzip a binary and write a shell script, or just use a one-click image. Of the things that are under reported, the most notable is when a shared library does not load, where did the vm look for it? One gives it a name via #moduleName, but the vm modifies it and then tries to load using the result. If it fails, it needs to say where it looked. What was the error code? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of laurent laffont [laurent.laffont(a)gmail.com] Sent: Friday, December 17, 2010 3:33 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Automated VM build server This is really cool Igor. A next step would be to generate packages for major Linux distro (Debian / Ubuntu, Arch, Fedora, ...). Laurent On Fri, Dec 17, 2010 at 9:17 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: In our nearest plans is make an automated (Hudson based) build setup for Cog and Squeak VMs. All files, which used for building an artifacts should be included in source code repository. So, most probably i will add the 'hudson-build' dir at same level as 'platforms', where scripts and configs will be stored. Some changes which i going to do: - all generated code will be removed from version controlled tree. Instead of it i will add an information, which will be enough to reproduce the generated code by taking 3 separate config file(s) a) image version (or its URL(s) for download) b) script for loading VMMaker (of concrete version) + all addons like FFI , FT2 etc etc into image c) script for generating the source code using VMMaker image .. z) tell me if i miss anything here With removing generated source code from repo we now can make sure that any changes in VMMaker (including code generation itself) can be tested and can be reproduced by build server at any snapshot version. Also, we could test & see if VMMaker loads well and can generate code using different base images. So, we will instantly know if any changes in compiler, or other layers of system is breaking VMMaker. Because having a years old image where VMMaker works 100%, but at same time have 100% chances that it couldn't be loaded (or even if loaded, but can't run correctly) in latest image is not what i think good practice for keeping your house clean. So, by getting rid any intermediate artifacts from build chain we will be able to make sure that: - VMMaker loads w/o problems in latest/multiple image(s) - VMMaker works well and can generate code That's means that for any newcomer, loading and building VM will be much less tedious process, and for 99% of cases it can be fully automated error free process. And let me remind our motto: we're not trying to produce perfect system/setup from first lucky shot. We slowly but steady crawling towards improved state of art. Any comments, ideas and suggestions are welcome. -- Best regards, Igor Stasenko AKA sig.

Dec. 17, 2010

Re: [Pharo-project] Automated VM build server

by Alexandre Bergel

Gorgeous! Alexandre On 17 Dec 2010, at 17:17, Igor Stasenko wrote: > In our nearest plans is make an automated (Hudson based) build setup > for Cog and Squeak VMs. > > All files, which used for building an artifacts should be included in > source code repository. > So, most probably i will add the 'hudson-build' dir at same level as > 'platforms', where scripts and configs will be stored. > > Some changes which i going to do: > - all generated code will be removed from version controlled tree. > Instead of it i will add an information, which will be enough > to reproduce the generated code by taking 3 separate config file(s) > > a) image version (or its URL(s) for download) > b) script for loading VMMaker (of concrete version) + all addons like > FFI , FT2 etc etc into image > c) script for generating the source code using VMMaker image > .. > z) tell me if i miss anything here > > With removing generated source code from repo we now can make sure > that any changes in VMMaker (including code generation itself) > can be tested and can be reproduced by build server at any snapshot version. > Also, we could test & see if VMMaker loads well and can generate code > using different base images. > So, we will instantly know if any changes in compiler, or other layers > of system is breaking VMMaker. > > Because having a years old image where VMMaker works 100%, but at same > time have 100% chances that it > couldn't be loaded (or even if loaded, but can't run correctly) in > latest image is not what i think good practice for > keeping your house clean. > > > So, by getting rid any intermediate artifacts from build chain we > will be able to make sure that: > - VMMaker loads w/o problems in latest/multiple image(s) > - VMMaker works well and can generate code > > That's means that for any newcomer, loading and building VM will be > much less tedious process, and for 99% > of cases it can be fully automated error free process. > > And let me remind our motto: we're not trying to produce perfect > system/setup from first lucky shot. > We slowly but steady crawling towards improved state of art. > > Any comments, ideas and suggestions are welcome. > > -- > Best regards, > Igor Stasenko AKA sig. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 17, 2010

Re: [Pharo-project] Automated VM build server

by Mariano Martinez Peck

On Fri, Dec 17, 2010 at 9:17 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > In our nearest plans is make an automated (Hudson based) build setup > for Cog and Squeak VMs. > > > this is cool igor!!! > > a) image version (or its URL(s) for download) > b) script for loading VMMaker (of concrete version) but how can you set a concrete version if the buid is automatic ? how do you know which version of VMMaker and ALL its dependencies? are you going to use ConfigurationOfVMMaker ? if true, how is going to maintain it? > + all addons like > FFI , FT2 etc etc into image > c) script for generating the source code using VMMaker image > .. > z) tell me if i miss anything here > > With removing generated source code from repo we now can make sure > that any changes in VMMaker (including code generation itself) > can be tested and can be reproduced by build server at any snapshot > version. > Also, we could test & see if VMMaker loads well and can generate code > using different base images. > So, we will instantly know if any changes in compiler, or other layers > of system is breaking VMMaker. > > Because having a years old image where VMMaker works 100%, but at same > time have 100% chances that it > couldn't be loaded (or even if loaded, but can't run correctly) in > latest image is not what i think good practice for > keeping your house clean. > > > So, by getting rid any intermediate artifacts from build chain we > will be able to make sure that: > - VMMaker loads w/o problems in latest/multiple image(s) > - VMMaker works well and can generate code > > That's means that for any newcomer, loading and building VM will be > much less tedious process, and for 99% > of cases it can be fully automated error free process. > > And let me remind our motto: we're not trying to produce perfect > system/setup from first lucky shot. > We slowly but steady crawling towards improved state of art. > > Any comments, ideas and suggestions are welcome. > > -- > Best regards, > Igor Stasenko AKA sig. > >

Dec. 17, 2010