- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Automated VM build server

by StÃ©phane Ducasse

>> >> this is cool igor!!! yes after all this fight with XCode yesterday ;) >>> 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. agility agility agility agility agility. :)

Dec. 18, 2010

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

by Philippe Marschall

On 17.12.2010 23:54, Sven Van Caekenberghe wrote: > 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 ? Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz Linux 2.6.36 (64bit) Cog r2316 Pharo 1.1.1 (no memory tweaks) Basically an almost four year old Linux box. Cheers Philippe

Dec. 18, 2010

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

by StÃ©phane Ducasse

Hi philippe thanks for helping sven. Now for the blind like me. What do the tool says? Because not too shabby is difficult to fully interpret :) Stef

Dec. 18, 2010

Re: [Pharo-project] Graph library in Smalltalk - Need for advices

by StÃ©phane Ducasse

May this is a ridiculuous thought but may be it would be good to start an effort on build a library for Smalltalk. Reusing some part of mondrian could be good. Stef > JGraphT worked alright in what I tried against in the past, but it won't > scale to huge heights like most libs without major tweaking or a graph DB > backing it along with some serious threading. > > Just to throw in a few others I've used, but not with Smalltalk: > > * https://software.sandia.gov/trac/mtgl MTGL > * http://lemon.cs.elte.hu/trac/lemon LEMON > * .NET http://quickgraph.codeplex.com/ Quickgraph /Graph# > * http://igraph.sourceforge.net/introduction.html iGraph > * http://snap-graph.sourceforge.net/ SNAP > > Of the above, I've had some of the best experience with LEMON in terms of > scale and speed for real-world usage. Unfortunately, none of these libraries > include everything you'd want, so at some point you will have to roll some > stuff yourself. That's been my experience at least. > > Some Graph or Graph-like Databases (tend to have some algorithm libs as > well): > > * http://www.infinitegraph.com InfiniteGraph (this runs on Objectivity > underneath the covers which has a Smalltalk impl) > * http://www.neo4j.org neo4j > * http://www.kobrix.com/hgdb.jsp HyperGraphDB > > Some related useful items for dealing with large sets and graphs when you > are thinking about performance and/or parallel processing: > > * http://gauss.cs.ucsb.edu/~aydin/doc/html/index.html Combinatorial BLAS > * http://www.semanticdesigns.com/Products/PARLANSE/ PARLANSE > * http://research.microsoft.com/en-us/projects/dryadlinq/ DRYAD LINQ > > FYI, I would strongly recommend against using Ruby for anything with graphs > except as a simple client lib. I spent a lot of time on this before and it > simply does not scale or perform to anything beyond very simple cases, and > the memory footprint in a real app becomes horrendous. We had to tweak the > hell out of some libs to get anything decent and even then we ended up > writing stacks of C to compensate. If you're just dealing with 100 vertex > undirected graphs, then it works great. It's honestly the fault of a lot of > the libs rather than the language, but nonetheless be warned. > -- > View this message in context: http://forum.world.st/Graph-library-in-Smalltalk-Need-for-advices-tp3092747… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 18, 2010

Re: [Pharo-project] Pharo 1.2 - default packages

by StÃ©phane Ducasse

so bug dale :) I would love to have them too. On Dec 17, 2010, at 5:48 PM, Miguel CobÃ¡ wrote: > El vie, 17-12-2010 a las 10:05 +0100, laurent laffont escribiÃ³: > >> IMHO for Pharo 1.2 Metacello configurations should be mandatory. > > + 1 > > > > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > >

Dec. 18, 2010

Re: [Pharo-project] Automated VM build server

by Sven Van Caekenberghe

On 17 Dec 2010, at 21:17, Igor Stasenko wrote: > In our nearest plans is make an automated (Hudson based) build setup for Cog and Squeak VMs. [...] Really, really great news! We must also make sure that the resulting VMs are just as fast as those built manually by wizards ;-) Sven

Dec. 18, 2010

[Pharo-project] Issue 3452 in pharo: GlorpDBX no longer loads due to garbled timestamp

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3452 by ya...(a)rogers.com: GlorpDBX no longer loads due to garbled timestamp http://code.google.com/p/pharo/issues/detail?id=3452 Pharo image: Pharo-core Pharo core version: PharoCore-1.2-12251 is OKAY, but PharoCore-1.2-12261 and newer fails Steps to reproduce: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGlorpDBX'; load. ! ConfigurationOfGlorpDBX ensureMetacello. ! (ConfigurationOfGlorpDBX project version: '1.2') load: { 'All with PostgreSQL native'. } I tried to debug it myself, but ended up in method trailer code. I also tried reverting the method #parseTimestampFrom: and got a complaint about "<historical>", which I couldn't figure out where it came from. Attachments: PharoDebug.log 40.3 KB

Dec. 18, 2010

Re: [Pharo-project] Automated VM build server

by Levente Uzonyi

On Fri, 17 Dec 2010, Schwab,Wilhelm K 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? ioLoadModule writes this information to stderr. For example: ioLoadModule(/lib/squeak/3.9-7/UUIDPlugin): libuuid.so.1: cannot open shared object file: No such file or directory So I think your problem is already solved. IIRC #moduleName can also contain the full path, so if you want to avoid the VM to guess the path you can define it explicitly. Levente > > 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. 18, 2010

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