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

Re: [Pharo-project] Issue 3453 in pharo: Primitive failed on ByteString>>copyFrom:To:

by pharo＠googlecode.com

Updates: Cc: stephane.ducasse Comment #1 on issue 3453 by laurent.laffont: Primitive failed on ByteString>>copyFrom:To: http://code.google.com/p/pharo/issues/detail?id=3453 In Inbox: SLICE-Issue-3453-Primitive-failed-on-ByteStringcopyFromTo-LaurentLaffont.1 Tests + fix on Text: add check if start > stop and start > size. So one can write someText copyFrom: 10 to: 5, it will behave like copyFrom:5 to:10. With my little knowledge this fix may be naive: - shouldn't it be in SequenceableCollection ? - this may hide a real bug in the code that handle text selection in morphic / shout

Dec. 18, 2010

[Pharo-project] Issue 3453 in pharo: Primitive failed on ByteString>>copyFrom:To:

by pharo＠googlecode.com

Status: Accepted Owner: laurent.laffont New issue 3453 by laurent.laffont: Primitive failed on ByteString>>copyFrom:To: http://code.google.com/p/pharo/issues/detail?id=3453 Pharo image: 1.2 beta 2 Pharo core version: 12281 Steps to reproduce: 1. ProfStef go. 2. put cursor after the dot of ProfStef next. CMD-D 3. idem in next screen BOOM - primitiveFailed on ByteString>>copyFrom:To: because start > stop (Fix to follow)

Dec. 18, 2010

Re: [Pharo-project] Automated VM build server

by Alexander LazareviÄ

2010/12/18 Levente Uzonyi <leves(a)elte.hu> > [...] so if you want to avoid the VM to guess the path you can define it > explicitly. > The SqueakVM path/filename guessing never works out for me on Ubuntu. So I always have to explicitly set the module/library name like this moduleName "Was: ^ 'sqlite'" ^ '/usr/lib/libsqlite3.so.0'

Dec. 18, 2010

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

by Sven Van Caekenberghe

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. Sven

Dec. 18, 2010

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

by Sven Van Caekenberghe

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): [sven@voyager:~]$ ab -k -n 10000 -c 10 http://127.0.0.1:1701/bytes/16384 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: 1701 Document Path: /bytes/16384 Document Length: 16384 bytes Concurrency Level: 10 Time taken for tests: 14.829 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Keep-Alive requests: 10000 Total transferred: 165610000 bytes HTML transferred: 163840000 bytes Requests per second: 674.37 [#/sec] (mean) Time per request: 14.829 [ms] (mean) Time per request: 1.483 [ms] (mean, across all concurrent requests) Transfer rate: 10906.48 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 1 15 3.1 14 67 Waiting: 0 15 2.8 14 67 Total: 1 15 3.1 14 67 Percentage of the requests served within a certain time (ms) 50% 14 66% 15 75% 16 80% 16 90% 17 95% 18 98% 21 99% 25 100% 67 (longest request) 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. Sven

Dec. 18, 2010

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

by StÃ©phane Ducasse

thanks philippe now the executive summary: does it mean that zinc is well positioned compared to others? Stef On Dec 18, 2010, at 11:30 AM, Philippe Marschall wrote: > On 18.12.2010 09:17, StÃ©phane Ducasse wrote: >> 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 :) > > Benchmarks always are ;-) > > Management summary it does: ~30 Mbytes/sec (bytes not bits) and 1778 > requests per second. Now comes a long section why this is unrealistic > and you can't expect this performance in the real world. > > You can look at the benchmark as an upper bound of what the server is > capable of. It makes 10000 requests using 10 concurrent, recycled > connections to the local machine. > > On the Smalltalk side there's a simple Seaside request handler that > takes a 16k byte array (the www.seaside.st homepage) and writes it to > the response. Note that a smaller page would obviously result in more > requests per second and less throughput while you would expect to see > the opposite from a bigger page. There are no sessions, continuations, > rendering or encoding involved because the idea is to stress the sever, > not Seaside. On the other hand conversion to and from Seaside requests > and responses happens as well as the whole context and handler chain are > set up. > > In a real world scenario you would spend much more time in Seaside and > the back end of your applicationÂ¹. The connections would be slower, each > connection would not make that may requests and you'd have network > latency. To get an idea what impact latency can have see [1]. > > Other points to note: > - The server does not lose any requests. This is a problem I've run into > using the same benchmark on other Smalltalk servers. > - Most requests come back fairly quickly, 80% in 1 ms. The longest takes > 155ms (maybe GC interference). > > One important point this benchmark does not cover is how well does it > clean up hanging or stale connections. This is a much bigger issue in > production than a few Mbytes/sec. > > To reproduce load the package AJP-Benchmark from [2], register > AJPFastRequestHandler (see class side), hit the page once with you > browser so that the cache gets initialized and run: > > ab -k -c 10 -n 10000 http://127.0.0.1:8080/fast > (ab comes with every Mac) > > There are other request handlers in there that do encoding and rendering > which obviously results in worse performance but more realistic numbers. > They are designed to stress Seaside rather than the server. > > [1] http://blogs.webtide.com/gregw/entry/lies_damned_lies_and_benchmarks > [2] http://www.squeaksource.com/ajp > > Â¹ you could use a caching filter though that does a lookup in a dictionary > > Cheers > Philippe > > > > >

Dec. 18, 2010

Re: [Pharo-project] Automated VM build server

by Mariano Martinez Peck

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

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

by Philippe Marschall

On 18.12.2010 09:17, StÃ©phane Ducasse wrote: > 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 :) Benchmarks always are ;-) Management summary it does: ~30 Mbytes/sec (bytes not bits) and 1778 requests per second. Now comes a long section why this is unrealistic and you can't expect this performance in the real world. You can look at the benchmark as an upper bound of what the server is capable of. It makes 10000 requests using 10 concurrent, recycled connections to the local machine. On the Smalltalk side there's a simple Seaside request handler that takes a 16k byte array (the www.seaside.st homepage) and writes it to the response. Note that a smaller page would obviously result in more requests per second and less throughput while you would expect to see the opposite from a bigger page. There are no sessions, continuations, rendering or encoding involved because the idea is to stress the sever, not Seaside. On the other hand conversion to and from Seaside requests and responses happens as well as the whole context and handler chain are set up. In a real world scenario you would spend much more time in Seaside and the back end of your applicationÂ¹. The connections would be slower, each connection would not make that may requests and you'd have network latency. To get an idea what impact latency can have see [1]. Other points to note: - The server does not lose any requests. This is a problem I've run into using the same benchmark on other Smalltalk servers. - Most requests come back fairly quickly, 80% in 1 ms. The longest takes 155ms (maybe GC interference). One important point this benchmark does not cover is how well does it clean up hanging or stale connections. This is a much bigger issue in production than a few Mbytes/sec. To reproduce load the package AJP-Benchmark from [2], register AJPFastRequestHandler (see class side), hit the page once with you browser so that the cache gets initialized and run: ab -k -c 10 -n 10000 http://127.0.0.1:8080/fast (ab comes with every Mac) There are other request handlers in there that do encoding and rendering which obviously results in worse performance but more realistic numbers. They are designed to stress Seaside rather than the server. [1] http://blogs.webtide.com/gregw/entry/lies_damned_lies_and_benchmarks [2] http://www.squeaksource.com/ajp Â¹ you could use a caching filter though that does a lookup in a dictionary Cheers Philippe

Dec. 18, 2010

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

by Enrico Spinielli

maybe you find some useful reference in Graphviz's Reference page http://www.graphviz.org/Resources.php On Fri, Dec 17, 2010 at 17:13, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Hi All (cross-posted squeak and pharo), > > I'm more and more in need for some graph lib in smalltalk. > I need graphs to implement special bayesian networks (specific inference mechanisms which aren't probabilistic) and also influence diagrams [1], and maybe in the future, reliablity tools (markov chains, petri nets, ...)... > > Do you know any existing smalltalk (open source) projects for graphs? I've only found [2] and [3] from 2005 but don't know them (they don't feel as generic as I would expect). > > If not, do you know any open-source projects outside of Smalltalk that I may look at ? > I've found BGL (C++) [3] which was ported in Ruby (RGL) [4]. > Does some of you know this lib ? Do you think it would be interesting to have an equivalent in Smalltalk ? > > As usual, any comments/advises would be greatly appreciated ;-) ? > > Cheers, > > CÃ©drick > > [1] http://en.wikipedia.org/wiki/Influence_diagram > [2] http://www.squeaksource.com/Graph > [3] http://www.squeaksource.com/DynaGraph.html > [4] http://www.boost.org/doc/libs/1_42_0/libs/graph/doc/index.html > [5] http://rgl.rubyforge.org/rgl/index.html > > > > > -- Enrico Spinielli "Do Androids dream of electric sheep?"â Philip K. Dick "Hear and forget; see and remember;do and understand."âMitchel Resnick

Dec. 18, 2010

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

by Michael Haupt

Yossi, On 17 December 2010 19:24, YossiDM <smalltalk(a)fixinsbar.com> wrote: > 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. indeed I didn't use it for large-scale applications. :-) Best, Michael

Dec. 18, 2010