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

Re: [Pharo-project] Issue 3447 in pharo: Do we need to menu entry "Shout Workspace"?

by StÃ©phane Ducasse

Hi levente Good idea. Now I do not have cycle to check if this is ok for pharo-dev but we should check that. By construction and contrary to some people may think we are not against Squeak: You do not build a cool vision by opposition and it is not fun in the mid term. This is just that we want to avoid to have constraints and endless negotiation and ranting. Now of course if there is a fit where we can work together in positive energy, this is more than welcome, so thanks for the proposal. Ideally I would like to avoid to have all pharo packages in the pharo repository and I would love to manage a pharo system with a nice metacello description but we should do it first to make it happen. and in such a setup shared/components with their own lifecycle makes a lot of sense. Stef PS: my goal is to have fun and learn a lot and create an eco system with people making a living out of smalltalk like software >> New issue 3447 by marcus.denker: Do we need to menu entry "Shout Workspace"? >> http://code.google.com/p/pharo/issues/detail?id=3447 >> >> The normal workspace seems to have syntax hihjligting alreaday >> >> > > Why don't you give ShoutCore (http://source.squeak.org/trunk/ShoutCore-ul.27.mcz ) a try? It works well in Squeak. There's a menu item to enable/disable Shout in the workspace, besides the global preference (not Preference) which applies to all workspaces. It also has the features of ShoutMonticello. It could be developed as a shared package between Pharo and Squeak, like VMMaker or OCompletion. What do you think? > > > Levente >

Dec. 18, 2010

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

by pharo＠googlecode.com

Updates: Status: Accepted Cc: Benjamin.VanRyseghem.Pharo Comment #1 on issue 3452 by stephane.ducasse: GlorpDBX no longer loads due to garbled timestamp http://code.google.com/p/pharo/issues/detail?id=3452 This is probably due to Issue 3224: Migrating MethodReference to MethodReferenceWithSource Could you load the fix first to see if this is working?

Dec. 18, 2010

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