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

[Pharo-project] Issue 3455 in pharo: Some SystemNavigationTests failed in 1.2-Dev

by pharo＠googlecode.com

Status: Accepted Owner: luc.fabresse New issue 3455 by luc.fabresse: Some SystemNavigationTests failed in 1.2-Dev http://code.google.com/p/pharo/issues/detail?id=3455 Failing Tests on Build server (Pharo 1.2 build #24) Tests.System.SystemNavigationTest.testDetectUnusedBlocks Tests.System.SystemNavigationTest.testNoUnusedBlocks I attached a changeset that correct it. It was an unsued block in NSRWBinaryOrTextStream>>superNextPutAll Nile tests are still green. Attachments: NSRWBinaryOrTextStream-superNextPutAll.st 599 bytes

Dec. 18, 2010

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

by Philippe Marschall

On 18.12.2010 12:08, Sven Van Caekenberghe wrote: > > On 18 Dec 2010, at 11:30, Philippe Marschall wrote: > >> Benchmarks always are ;-) > > > [...] > > Excellent writeup, once again. > > I think / I'm pretty confident that the cleanup goes well, as long as Socket[Stream] respects its timeout (currently set at 10s for all streams, maybe 5s would be better for the server) and throws ConnectionTimedOut and ConnectionClosed exceptions reliably. > > Doing > > Smalltalk garbageCollect. > Socket allInstances. > > before and after the benchmarks shows no leaking. > > But then again, the HTTP request parsing could be made more bullet proof. Adding a load balancer in front of Zn that also sanitizes requests would be a good idea for production setups. Yeah, in AJP I could save a lot of code because there's an Apache in front of it sanitizing the requests and managing the connections. Cheers Philippe

Dec. 18, 2010

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

by Philippe Marschall

On 18.12.2010 11:59, Sven Van Caekenberghe wrote: > > On 18 Dec 2010, at 09:25, Philippe Marschall wrote: > >> 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. > > Philippe, > > Is that a desktop machine with a normal interactive load, or a server machine ? How much RAM ? Do you run the image headless ? > > On my development machine (Mac Book Pro, Intel Core 2 Duo 2.4 Ghz, 4 GB RAM, Mac OS X 10.6.5, Squeak 5.8b12, normal image, normal desktop load with lots of apps), I cannot get even close to your numbers (/bytes/16384 is a binary unencoded response of 16Kb direct from Zn): > > ... > > This is no more than 1/3 of your results. > I will be trying to find time to get a recent Cog VM on a Linux server machine using a headless deploy image and run benchmarks there. > Thanks for the feedback and for pushing this. That's a desktop Linux with 2 GB of RAM, Gnome and Thunderbird running. Normal headed Pharo image. I have a similar Mac Book Pro where I get somewhat lower numbers than on the Linux box but not a 1/3. How big is your image? I noted that "fresh", small (20 - 30 MB) images are often faster. Is the response static or do you allocate a byte array for every response? Despite everything this benchmark is CPU limited. If you load AJPFastRequestHandler and Zinc-Seaside do you see any difference? I got my Cog VM from [1] [1] http://www.mirandabanda.org/files/Cog/VM/ Cheers Philippe

Dec. 18, 2010

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

by StÃ©phane Ducasse

yes but you know what I mean :) Comanche,.... WebClient.... Swazoo On Dec 18, 2010, at 1:51 PM, Philippe Marschall wrote: > On 18.12.2010 11:43, StÃ©phane Ducasse wrote: >> thanks philippe >> >> now the executive summary: does it mean that zinc is well positioned compared to others? > > That's a much more difficult question. First what do you mean by > "others"? Second raw performance is often not the most important > criteria to chose a web server. Others like reliability and feature set > are often more important. And let's be honest, if raw performance was > your most important criteria, Pharo probably wouldn't be your first > choice anyway. > > Cheers > Philippe > >

Dec. 18, 2010

Re: [Pharo-project] Automated VM build server

by Igor Stasenko

On 18 December 2010 11:31, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Fri, Dec 17, 2010 at 11:13 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> 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. >> > > Igor, what I wanted to express (maybe I did it wrong), is that we need to > first solve a previous problem with the VM. > I think we first need to be able to TRACE!Â And for TRACE I mean, that for a > specific VM state, I can trace: > - which METACELLO version to use in order to generate sources. And with this > metacello version, we can guess ALL the versions of all requiered packages > - which SVN version > Yes, this is what i want to do. All metainformation about what is used for generating sources and building VM. Including a VMMaker config (like set of plugins to include/exclude). > If the idea is to always load all the latest code, then you can just load > the baseline of ConfigurationOfVMMaker and that's all. With svn is even > easier. > No. the idea is to take any snapshot stored in version-managed repository and be able to accurately reproduce it, without using external info/files. > cheers > > mariano > >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- Best regards, Igor Stasenko AKA sig.

Dec. 18, 2010

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

by Levente Uzonyi

On Sat, 18 Dec 2010, StÃ©phane Ducasse wrote: > 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. It would be very slow and really a lot of work. Mondrian is nice for visualization, but a Graph library is a lot more than that. Levente > > 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

[Pharo-project] Issue 3454 in pharo: DNU when looking for implementors in OB on 1.2dev

by pharo＠googlecode.com

Status: Accepted Owner: luc.fabresse Labels: Milestone-1.2-DevImage Type-ReportDefect New issue 3454 by luc.fabresse: DNU when looking for implementors in OB on 1.2dev http://code.google.com/p/pharo/issues/detail?id=3454 Looking for implementors in 1.2 dev (#12281) from OBBrowser raise a DNU. in OBTextMorphEditorWithShout>>send:toModelWith:orDo: self terminateAndInitializeAround: ... but terminateAndInitializeAround is implemented in ParagraphEditor which is not a super class of OBTextMorphEditorWithShout.

Dec. 18, 2010

[Pharo-project] Pharo features

by Ivano Arrighetta

Hello everyone. A friend of mine suggested me to use Pharo because I ask him for informations on Emacs in order to do some MultiMedia stuff. Now, is Pharo ok to do this? (list follows) Raster graphics (processing, synthesis, input/capturing, output/saving), vector graphics (same), 3D graphics (modeling, rigging, rendering, raytracing, opening and saving 3D files), sound processing (sound synthesis, algoritmic music composition, post processing), video editing (opening, saving, cutting/rotating/processing video files), text processing (HTML output, regex/find and replace/whateverI would do with Word + Excel), Optical character recognition, text to speech, speech recognition, ASCII Art. Thanks in advance for any answer.

Dec. 18, 2010

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

by Philippe Marschall

On 18.12.2010 11:43, StÃ©phane Ducasse wrote: > thanks philippe > > now the executive summary: does it mean that zinc is well positioned compared to others? That's a much more difficult question. First what do you mean by "others"? Second raw performance is often not the most important criteria to chose a web server. Others like reliability and feature set are often more important. And let's be honest, if raw performance was your most important criteria, Pharo probably wouldn't be your first choice anyway. Cheers Philippe

Dec. 18, 2010

Re: [Pharo-project] Automated VM build server

by Esteban Lorenzano

this is cool Igor. can I get your scripts? (I'm working on a set to build the vms for mac, and your scripts would be helpful) I think we need to move the vm making stuff into a more formal and repeatable process... so I think we need to bring the vmmaker into a ConfigurationOfVMMaker... if we can achieve that, we can automatize the building in a reliable way. So... if there are things inside cs's and other formats, we first need to package them into monticello files (that's why I packaged ClipboardExtended into VMMaker - my first contribution to vm :) ) that's my 2c. Cheers, Esteban El 18/12/2010, a las 7:31a.m., Mariano Martinez Peck escribiÃ³: > > > On Fri, Dec 17, 2010 at 11:13 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. > > > Igor, what I wanted to express (maybe I did it wrong), is that we need to first solve a previous problem with the VM. > I think we first need to be able to TRACE! And for TRACE I mean, that for a specific VM state, I can trace: > - which METACELLO version to use in order to generate sources. And with this metacello version, we can guess ALL the versions of all requiered packages > - which SVN version > > If the idea is to always load all the latest code, then you can just load the baseline of ConfigurationOfVMMaker and that's all. With svn is even easier. > > cheers > > mariano > > -- > Best regards, > Igor Stasenko AKA sig. > >

Dec. 18, 2010