July 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] stress tester with Pharo

by StÃ©phane Ducasse

On Jul 1, 2011, at 10:42 PM, laurent laffont wrote: > Hi, > > is it possible to create jMeter-like tests with Pharo (and Cog ?) - running a massive number of (native ?) threads that send HTTP requests ? I would be interested by that kind of stress tests. > > Laurent

July 1, 2011

Re: [Pharo-project] [Pharo-users] **Important Please read** Towards First Class Tasks

by Mariano Martinez Peck

I would add one for profilers and friends. Alexandre could be the coordinator there. On Fri, Jul 1, 2011 at 10:40 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Dear Pharoers > > I think that we are doing a great work: when I look at the work on the > theme, better widgets, network.....Excellent! and thanks. > Now we were discussing with Doru about how we as community could coordinate > and structure ourselves better to create more energy. > > Analysis of the current situation: > Right now we have individuals doing great projects, sometimes we > have a group of people but this is often not visible. > Now often happens a bit in ad-hoc way. Because someone ask > something, then somebody replies and we integrate the replies. > > What I would like to see emerging are First Class Tasks with > a name > a topic > a coordinator > a group of interested participants, > a set of identified clients (because clients are the ones that often > make us deliver more), > a little agenda, > a web presence on the web page > > > If we look at what we have right now that are potential Tasks and really > important clients > > - The Z connection: > Network/Socket > Coordinator (proposed): Sven > Socket: Noury Luc Jannik Olivier > Clients: Seasiders, Clouders, > > - Morphic 2: > UI: Alain Gary Igor > Coordinator (proposed): ? > Presenty framework > VoidNullPointer UIBuilder > Athens > Clients: Moose, Pharo IDE > > - Pharo IDE: > Coordinator (proposed): Doru > work around TWM Laurent > Nautilus: Benjamin Laurent > Glamourous: Doru Damien > > - OPAL: > Compiler tool chain > Coordinator (proposed): Marcus? > Jb, Jorge, Marcus, > Helvetia lukas > Niko Schwarz? > > - Package: > Stef, Cyrille > Coordinator (proposed): Stephane > Client: Nautilus, Doru Moose, > > - Metacello > Dale Mariano > Coordinator (proposed): Dale? > Client: Stef with the idea of distribution, Torsten don't > you want to help here? > > - Coral: > Coordinator (proposed): Damien? > Damien, Luc, Adrien, Stef, > Client: Damien, Olivier? > > So what would be good is to have the identification on the web site of > these groups. > More discussions and concentration with a set of little tasks to be > performed > We could tag the mails with [Task-UI], [Task-OPAL], have a little visible > agenda. > > What do you think? I think that it is important. > > > > Stef > > -- Mariano http://marianopeck.wordpress.com

July 1, 2011

Re: [Pharo-project] little challenge for sven and us

by StÃ©phane Ducasse

;D Stef On Jul 1, 2011, at 2:23 PM, Sven Van Caekenberghe wrote: > > On 01 Jul 2011, at 12:53, Janko MivÅ¡ek wrote: > >> Why not simply: >> >> (ZnServer startOn: 1337) >> onRequestRespond: [:request |: ZnResponse ok: 'Hello world'] >> >> >> This is the closest form to that node.js example and really show the >> power of Smalltalk and its closures. Also understandable to everyone >> including the (IMHO) majority, who don't understand design patterns like >> Delegate well. > > If you compare all the Zn delegates that are included, such as Nick's ZnDispatcherDelegate, I think it is clear that #handleRequest: is a good interface. Different use cases require delegate's with more or less features and thus complexity. > > But for the sake of short/elegant examples, I added the ZnSingleThreadedServer>>#onRequestRespond: convenience method, so the examples now become: > > (ZnServer startDefaultOn: 1337) > onRequestRespond: [ :request | ZnResponse ok: (ZnEntity text: 'Hello World!') ]. > > and > > (ZnServer startDefaultOn: 1337) > onRequestRespond: [ :request | ZnResponse ok: (ZnEntity with: request contents) ]. > > Sven > > >

July 1, 2011

[Pharo-project] stress tester with Pharo

by laurent laffont

Hi, is it possible to create jMeter-like tests with Pharo (and Cog ?) - running a massive number of (native ?) threads that send HTTP requests ? Laurent

July 1, 2011

Re: [Pharo-project] [Pharo-users] **Important Please read** Towards First Class Tasks

by Guillermo Polito

I think it is important a team working on application integration (Soap, rest servers, xml and binary rpc, C/Java/ .Net integration) for the enterprise pharo user :). On Fri, Jul 1, 2011 at 9:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > > > > > I think we should try this. IMO a task around SUnit & friends is missing. > > sign in for it and lead it. > What I would like is a small agenda so that other people can see what is > happening > and if they want to help join. > > > > > Laurent. > > >

July 1, 2011

Re: [Pharo-project] Cog VM continuous integration: update

by Eliot Miranda

On Fri, Jul 1, 2011 at 12:40 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 01/07/11 8:54 AM, Igor Stasenko wrote: > >> >> The next step is to run tests for built VMs. For this i planning to >> create a specialized package, which will contain code snippets for >> loading& firing off various tests, >> because currently all tests are a bunch of .st scripts, and managing >> files over dozen of networked machines is not fun. >> So, i think i will just take these snippets and put them into single >> MC package, so then it could be managed much easier. >> > > Building VM's on CI server is a great step forward. Thanks for making it > happen. > > I'm curious about how to test each build. For a C compiler, typically a > fixed-point is done - i.e. compile the new compiler (yielding stage1 > compiler), then use the stage1 compiler to compile the new compiler again > (yielding stage2 compiler). Repeat to get stage3 compiler. The stage2 and > stage3 compiler binaries are supposed to be identical. Then, in a C/UNIX > system, recompiling the OS and tools was a good test suite. > > There may be some equivalent thing to do for a JIT/VM + image, but I can't > figure out what it is. Maybe all the method dictionaries need to be written > out in canonical order, then the stage2 and stage3 results compared. But, > that would only test the compiler, not the JIT functionality. Anyways, just > some random thoughts... > ? The VM source is generated in a canonical order (essentially alphabetic by function, but with exceptions; the interpret interpreter main loop comes first). This source is pure C and compiled with the C compiler. The VM is tested by running tests in the image while running above the VM. HTH -- best, Eliot

July 1, 2011

Re: [Pharo-project] Cog VM continuous integration: update

by Yanni Chiu

On 01/07/11 8:54 AM, Igor Stasenko wrote: > > The next step is to run tests for built VMs. For this i planning to > create a specialized package, which will contain code snippets for > loading& firing off various tests, > because currently all tests are a bunch of .st scripts, and managing > files over dozen of networked machines is not fun. > So, i think i will just take these snippets and put them into single > MC package, so then it could be managed much easier. Building VM's on CI server is a great step forward. Thanks for making it happen. I'm curious about how to test each build. For a C compiler, typically a fixed-point is done - i.e. compile the new compiler (yielding stage1 compiler), then use the stage1 compiler to compile the new compiler again (yielding stage2 compiler). Repeat to get stage3 compiler. The stage2 and stage3 compiler binaries are supposed to be identical. Then, in a C/UNIX system, recompiling the OS and tools was a good test suite. There may be some equivalent thing to do for a JIT/VM + image, but I can't figure out what it is. Maybe all the method dictionaries need to be written out in canonical order, then the stage2 and stage3 results compared. But, that would only test the compiler, not the JIT functionality. Anyways, just some random thoughts...

July 1, 2011

Re: [Pharo-project] [Pharo-users] **Important Please read** Towards First Class Tasks

by Tudor Girba

Hi, The idea of Pharo Tasks is not to get things rigid and to stop the individuals from contributing. This should continue to happen. Instead, the idea is to start acknowledging that Pharo has became larger, and that the integration and drive of individual contributions has more dimensions that can be handled by the core group alone. So, the Pharo Task Force is a mechanism for teams to form around some larger topics. Like I said beforetime, I want to work on the IDE. This is a topic that is larger than one person can and should do. But, it is also a topic that requires integration of contributions, and it won't work by simply doing a union of choices. Just like now the Core team relentlessly cleans up the language and infrastructure, so should the IDE deserve a similar approach to get it strong and reinvented. People should know that this project exists and that they can contribute in a more organized way. This won't work by force. But, if someone wants to build/lead/integrate a project like this, I think it can work nicely. Cheers, Doru On 1 Jul 2011, at 13:08, Igor Stasenko wrote: > Are you trying to repeat experience of Squeak teams? > I can remind you that they are never worked and failed in the end. > > And i think that problem is that its hard to coordinate people which > are located around the globe and their main tasks are completely > different. > Another reason is that you cannot enforce any kind of responsibility > for delaying or not delivering , because we're talking about > enthusiasts. > > I believe that individual people with own vision and own, personal, > agenda could do much more. > If someone would like to voluntary coordinate some activities, i am > all for it. Now this means that given person should have plan in his > head and stick with it, > and keep an eye, ask around, communicate, and of course try coordinate people. > But is it really need to be formalized like that? > > We, as community could discuss the agendas, and then a concrete steps > to implement it. Now, its not really matters who will do it, as long > as there enough people interested in helping > with it. > And its completely pointless to form groups of individuals, only to be > listed as a group member on site and doing nothing (for whatever > objective reason). > > So, the right questions about any improvement, which we would like to > see in future is: > - do/why we need that > - who can do that > > if both of these questions can be answered positively, then it is only > a matter of time for new feature to appear. > And to my opinion, putting any kind of formality around it is > completely orthogonal to what will happen in reality. > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "Some battles are better lost than fought."

July 1, 2011

Re: [Pharo-project] little challenge for sven and us

by Sven Van Caekenberghe

On 01 Jul 2011, at 20:33, Matt Kennedy wrote: > I could see some value to supporting an asZnEntity protocol. As an example, say I have an API which needs to support various output formats. I could build my classes to use the appropriate entity builder when responding to asZnEntity so that in the server code I only need to do ZnResponse ok: myresponse asZnEntity, or just ZnResponse ok: myresponse if ok: sends asZnEntity. Yes, that is indeed possible, although I am not sure if lots of asXX methods all over are a good idea. The problem is that there is no really useful one to one mapping between Smalltalk objects and Entities. An Entity has a content type (mime type) and a content length (rendered byte size) and knows how to represent itself on a binary stream or read itself from a binary stream. Now, given a String or a ByteArray, it is indeed possible to quickly convert to an Entity (ZnEntity class>>#with: does that). But that is not enough: one has to indicate a useful content type (ZnEntity class>#text: and #html: are examples of doing this automatically). In general though, there is no way to hide the need to set the actual type (ZnEntity class>>#with:type:). So you need #asZnEntityOfType: which would add parenthesis again. Sven

July 1, 2011

Re: [Pharo-project] little challenge for sven and us

by Matt Kennedy

I could see some value to supporting an asZnEntity protocol. As an example, say I have an API which needs to support various output formats. I could build my classes to use the appropriate entity builder when responding to asZnEntity so that in the server code I only need to do ZnResponse ok: myresponse asZnEntity, or just ZnResponse ok: myresponse if ok: sends asZnEntity. Matt On Jul 1, 2011, at 11:12 AM, Igor Stasenko wrote: > On 1 July 2011 16:55, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> >> On 01 Jul 2011, at 15:52, Janko MivÅ¡ek wrote: >> >>> I'd just introduce yet that ZnResponse ok: 'Hello world'. To cover the >>> most common response body and this will be really easy to grasp for >>> newcomers. Nothing specially to learn upfront, just that simple two >>> lines with seamless way to respond with some text. >>> >>> This complicate a bit Zinc internals, but the gain on simplicity on API >>> level is IMHO worth that. >> >> I saw your code, and I considered it, but it feels too much out of place (the implementation that is), architecturally wrong and not that usefull. Although ZnResponse ok: (ZnEntity text: 'Hello World!') is longer it is also more intention revealing, it tells you something about HTTP without being too verbose. >> >> These are opinions and aesthetics, of course. >> > > IMO. API should be focused on most often use cases. Not on useless > cases , like showing 'hello world'. > Because going that road, you will just ruin the beautiful design of > what you really need in favor of supporting useless things. > >> Sven > > > > -- > Best regards, > Igor Stasenko AKA sig. >

July 1, 2011