- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Using ZnLogEvents to build a live updating requests per second monitor for an HTTP server

by Norbert Hartl

Sven, this is a nice example and the video is great. It shows again what we can do if we model problem domains properly. I really need to have a look at your and Doruâs code. well done, Norbert Am 16.06.2014 um 17:29 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi, > > Here is a concrete example of how cool object logging can be. In the current development version, Zinc HTTP Components announces a number of ZnLogEvent objects while either ZnClient or ZnServer operates. One of those is ZnServerTransactionEvent, which signals the completion of a single HTTP transaction (request/response pair) by the server. By subscribing to this specific event through Zinc's Announcer, we can simply count the number of transactions. If we report and reset this counter every second, we get a rudimentary live updating requests per second monitor, in about ten lines of code in a workspace ! > > Here is the setup: > > | transactionCount transactionsPerSecond | > transactionCount := 0. > transactionsPerSecond := 0 asValueHolder inspectWithLabel: 'HTTP req/s'. > ZnLogEvent announcer > when: ZnServerTransactionEvent > do: [ :each | transactionCount := transactionCount + 1 ] > for: #transactionCountDemo. > [ [ > 1 second asDelay wait. > transactionsPerSecond value: transactionCount. > transactionCount := 0 ] repeat ] > forkAt: Processor userBackgroundPriority > named: #transactionCountDemo. > > Then we start the server: > > ZnServer startDefaultOn: 8080. > > In a terminal, we use ab (the Apache Benchmark tool) to generate some load on the server (10K requests for 1K random data, using 4 concurrent threads): > > $ ab -k -n 10240 -c 4 http://localhost:8080/random/1024 > > Here is a short 2 minute screencast showing this little demo in action (be sure to select the HD version): > > https://www.youtube.com/watch?v=gaUxPNq6_7c > > It starts by showing how a AnnouncementSpy can be used to monitor the server starting up and handling a single request - the logging from the client is visible as well. The lines in the AnnouncementSpy are not just text, but full, detailed objects. We inspect and explore the same transaction from both the client and server perspective. > > Next is the demo of the live updating requests per second monitor with the load described above. You can see that both our counter and ab report approximately the same number: about 800-900 req/s. > > And finally, here is the cleanup code: > > ZnLogEvent announcer unsubscribe: #transactionCountDemo. > ZnServer stopDefault. > Process allInstances select: [ :each | each name = #transactionCountDemo ] thenDo: #terminate. > > Note that by using other data elements in the ZnServerTransactionEvent we could track bytes transferring in or out, rates of failure, slow requests and so. There are lots of possibilities with object logging left to explore, as well as lots to learn. > > Sven > >

June 17, 2014

Re: [Pharo-dev] Where is the postcard with syntax?

by Yuriy Tymchuk

On 17 Jun 2014, at 10:07, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Tue, Jun 17, 2014 at 9:32 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> Now, who is creative enough to add "dynamic array" (one with curly braces) >> and temporaries in a block to the original thing: > > > the postcard on our Pharo slides has a bit more (see slide 34): > http://www.slideshare.net/pharoproject/pharo-tutorial-at-ecooptutorial > Nice, havenât seen that > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

June 17, 2014

Re: [Pharo-dev] Where is the postcard with syntax?

by Damien Cassou

On Tue, Jun 17, 2014 at 9:32 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Now, who is creative enough to add "dynamic array" (one with curly braces) > and temporaries in a block to the original thing: the postcard on our Pharo slides has a bit more (see slide 34): http://www.slideshare.net/pharoproject/pharo-tutorial-at-ecooptutorial -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 17, 2014

Re: [Pharo-dev] Where is the postcard with syntax?

by Yuriy Tymchuk

Itâs hard for me to agree with you. Pharoâs compact syntax is one of main features for me. Because in all other languages there was a time when I encountered some unknown constructs even after a year of usage. In Pharo you just have to learn syntax from postcard, and then if you want to know how some thing woks you just read the source code. Maybe this is some special thing related to me. On 17 Jun 2014, at 09:59, kilon alios <kilon.alios(a)gmail.com> wrote: > personally I don't like this postcard , it looks too much like "snake oil marketing" to me. > > It creates the illusion that Pharo is much simpler than other programming languages as a programming language while nothing can be further from the truth. The idea here is to prove to the viewer that Pharo is based on a very simple recipe and that is of course true. But if we have to be honest is should come with a disclaimer for the potential users that Pharo is no blue pill and there tons of things outside this postcard you need to learn if you want to create the simplest Pharo application. I will be frank , as a language I dont find Pharo any simpler than let's say python , which I am more familiar with. And the fact that there is this simple recipe gave me zero benefits to me so far. Its a cool trick that may come handy down the line if I want to shape the language more to my needs, but I dont see doing this to a day by day basis. > > Now a "living coding postcard" stating the workflow of Pharo and demonstrating the power of the debugger is much more honest and frankly better marketing for Pharo. You show something to a person that will benefit his workflow on a day by day basis. > > > On Tue, Jun 17, 2014 at 10:32 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Now, who is creative enough to add âdynamic arrayâ (one with curly braces) and temporaries in a block to the original thing: > > exampleWithNumber: x > | y | > true & false not & (nil isNil) ifFalse: [self halt]. > y := self size + super size. > #($a #a "a" 1 1.0) > do: [ :each | > Transcript show: (each class name); > show: ' ']. > ^x < y > > > Uko > > On 16 Jun 2014, at 15:35, Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: > >> >> I got it from Stef, who always said it came originally from Ralph Johnson. >> >> http://c2.com/cgi-bin/wiki?SmalltalkSyntaxInaPostcard >> >> Googling around finds various copies of this, but no original source. >> >> Oscar >> >> On 16 Jun 2014, at 10:58 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >>> I guess itâs here: http://files.pharo.org/media/flyer-cheat-sheet.pdf >>> >>> I think that it would be interesting to put the syntax on a postcard. It can work as a proof of concept, some addition cheat-sheet for newcomers and also as some king of souvenir. >>> >>> Uko >>> >>> On 16 Jun 2014, at 10:36, stepharo <stepharo(a)free.fr> wrote: >>> >>>> you have the flyer of Damien (no idea where it is) but no real postcard. >>>> >>>> Stef >>>> >>>> On 16/6/14 09:35, Yuriy Tymchuk wrote: >>>>> Hi guys, >>>>> >>>>> we all are talking about the syntax fitting in a postcard, but was there any real postcard with Pharo syntax prototype? This would be really interesting. >>>>> >>>>> Uko >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

June 17, 2014

Re: [Pharo-dev] Spur Squeak Trunk Image Available

by Philippe Marschall

On 13.06.14 01:41, Eliot Miranda wrote: > > > > > Hi All, > > it gives me great pleasure to let you know that a spur-format trunk > Squeak image is finally available at > http://www.mirandabanda.org/files/Cog/SpurImages/. Spur VMs are > available at http://www.mirandabanda.org/files/Cog/VM/VM.r2987/. > > â¦ I'm seeing a Seaside request handling benchmark going from 10k req/s to 11k req/s. Don't be too quick to dismiss this as being IO-bound (being IO-bound is actually quite hard on Squeak/Pharo). During the benchmark Squeak fully saturates one core. It is hard to tell what the limiting factor for this benchmark actually is. But removing one or two String allocations from the request handling loop usually yields about 100 to 200 additional req/s. Cheers Philippe

June 17, 2014

Re: [Pharo-dev] Where is the postcard with syntax?

by kilon alios

personally I don't like this postcard , it looks too much like "snake oil marketing" to me. It creates the illusion that Pharo is much simpler than other programming languages as a programming language while nothing can be further from the truth. The idea here is to prove to the viewer that Pharo is based on a very simple recipe and that is of course true. But if we have to be honest is should come with a disclaimer for the potential users that Pharo is no blue pill and there tons of things outside this postcard you need to learn if you want to create the simplest Pharo application. I will be frank , as a language I dont find Pharo any simpler than let's say python , which I am more familiar with. And the fact that there is this simple recipe gave me zero benefits to me so far. Its a cool trick that may come handy down the line if I want to shape the language more to my needs, but I dont see doing this to a day by day basis. Now a "living coding postcard" stating the workflow of Pharo and demonstrating the power of the debugger is much more honest and frankly better marketing for Pharo. You show something to a person that will benefit his workflow on a day by day basis. On Tue, Jun 17, 2014 at 10:32 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Now, who is creative enough to add âdynamic arrayâ (one with curly braces) > and temporaries in a block to the original thing: > > exampleWithNumber: x > | y | > true & false not & (nil isNil) ifFalse: [self halt]. > y := self size + super size. > #($a #a "a" 1 1.0) > do: [ :each | > Transcript show: (each class name); > show: ' ']. > ^x < y > > > > Uko > > On 16 Jun 2014, at 15:35, Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> > wrote: > > > I got it from Stef, who always said it came originally from Ralph Johnson. > > http://c2.com/cgi-bin/wiki?SmalltalkSyntaxInaPostcard > > Googling around finds various copies of this, but no original source. > > Oscar > > On 16 Jun 2014, at 10:58 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > I guess itâs here: http://files.pharo.org/media/flyer-cheat-sheet.pdf > > I think that it would be interesting to put the syntax on a postcard. It > can work as a proof of concept, some addition cheat-sheet for newcomers and > also as some king of souvenir. > > Uko > > On 16 Jun 2014, at 10:36, stepharo <stepharo(a)free.fr> wrote: > > you have the flyer of Damien (no idea where it is) but no real postcard. > > Stef > > On 16/6/14 09:35, Yuriy Tymchuk wrote: > > Hi guys, > > we all are talking about the syntax fitting in a postcard, but was there > any real postcard with Pharo syntax prototype? This would be really > interesting. > > Uko > > > > > > > > > >

June 17, 2014

Re: [Pharo-dev] Survey - needing Protocol Chooser when creating methods from the debugger

by Damien Cassou

Agree. Except that codecritics is better for this and I think already has this rule On Jun 15, 2014 6:10 PM, "Gabriel Cotelli" <g.cotelli(a)gmail.com> wrote: > I vote for just letting the method unclassified and a test case detecting > unclassified methods to not forget classifying the method later > On Jun 15, 2014 10:04 AM, "Ben Coman" <btc(a)openinworld.com> wrote: > >> Just surveying opinion, when pressing the 'Create' (method) button in the >> debugger, how critical do people consider the need for the Protocol Chooser >> at that time? Personally I find it interrupts my flow, since often I don't >> feel comfortable with the conventions to choose which protocol it should go >> in. It makes me go searching in another browser to try to determine the >> convention from other existing methods. A few options to start with: >> 1. Like it just the way it is. >> 2. Dump the new method in unclassified and clean up later (plus a >> protocol sorting refactoring tool) >> 3. Having Protocol Chooser provide a short list of suggestions, perhaps >> somehow indicating the rule used and weighting. For example: "accessors >> (100 methods matching instance variables)" ; "testing (20 items match 'is' >> prefix)"". >> btw, In 2.0 the Protocol Chooser came up with a massive list (actually >> where this survey question stems from) but in 3.0 the Protocol Chooser >> comes up empty for my use cases. Can anyone suggest an example in 3.0 that >> populates the Protocol Chooser? >> >> cheers -ben >> >> >>

June 17, 2014

Re: [Pharo-dev] Where is the postcard with syntax?

by Yuriy Tymchuk

Now, who is creative enough to add âdynamic arrayâ (one with curly braces) and temporaries in a block to the original thing: exampleWithNumber: x | y | true & false not & (nil isNil) ifFalse: [self halt]. y := self size + super size. #($a #a "a" 1 1.0) do: [ :each | Transcript show: (each class name); show: ' ']. ^x < y Uko On 16 Jun 2014, at 15:35, Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: > > I got it from Stef, who always said it came originally from Ralph Johnson. > > http://c2.com/cgi-bin/wiki?SmalltalkSyntaxInaPostcard > > Googling around finds various copies of this, but no original source. > > Oscar > > On 16 Jun 2014, at 10:58 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> I guess itâs here: http://files.pharo.org/media/flyer-cheat-sheet.pdf >> >> I think that it would be interesting to put the syntax on a postcard. It can work as a proof of concept, some addition cheat-sheet for newcomers and also as some king of souvenir. >> >> Uko >> >> On 16 Jun 2014, at 10:36, stepharo <stepharo(a)free.fr> wrote: >> >>> you have the flyer of Damien (no idea where it is) but no real postcard. >>> >>> Stef >>> >>> On 16/6/14 09:35, Yuriy Tymchuk wrote: >>>> Hi guys, >>>> >>>> we all are talking about the syntax fitting in a postcard, but was there any real postcard with Pharo syntax prototype? This would be really interesting. >>>> >>>> Uko >>>> >>>> >>> >>> >> >> > >

June 17, 2014

Re: [Pharo-dev] Survey - needing Protocol Chooser when creating methods from the debugger

by Esteban A. Maringolo

+1. An update the debugger window title once the method is implemented. :) Esteban A. Maringolo 2014-06-15 10:15 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > For me, having to choose a protocol before creating the method is contrary to TDD spirit of âgo to the green as fast as you can, clean laterâ. > So yes, instead enhance it, I would directly remove the protocol chooser in that workflowâ¦ > > Esteban > > On 15 Jun 2014, at 10:11, Ben Coman <btc(a)openInWorld.com> wrote: > >> Ben Coman wrote: >>> Just surveying opinion, when pressing the 'Create' (method) button in the debugger, how critical do people consider the need for the Protocol Chooser at that time? Personally I find it interrupts my flow, since often I don't feel comfortable with the conventions to choose which protocol it should go in. It makes me go searching in another browser to try to determine the convention from other existing methods. A few options to start with: >>> 1. Like it just the way it is. >>> 2. Dump the new method in unclassified and clean up later (plus a protocol sorting refactoring tool) >>> 3. Having Protocol Chooser provide a short list of suggestions, perhaps somehow indicating the rule used and weighting. For example: "accessors (100 methods matching instance variables)" ; "testing (20 items match 'is' prefix)"". >>> btw, In 2.0 the Protocol Chooser came up with a massive list (actually where this survey question stems from) but in 3.0 the Protocol Chooser comes up empty for my use cases. Can anyone suggest an example in 3.0 that populates the Protocol Chooser? >> doh! I only needed to start typing to populate the Protocol Chooser. Now it still presents too many choices for my sensibilities. >> cheers -ben >> > >

June 17, 2014

Re: [Pharo-dev] Using ZnLogEvents to build a live updating requests per second monitor for an HTTP server

by Esteban A. Maringolo

I was thinking of getting statistics of the usage of our REST API. With this technique I could do it without modifying my current classes, in an orthogonal way. This opens up many possibilities. Regards! Esteban A. Maringolo 2014-06-16 17:33 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Very nice example! > > Doru > > > On Mon, Jun 16, 2014 at 5:29 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> Here is a concrete example of how cool object logging can be. In the >> current development version, Zinc HTTP Components announces a number of >> ZnLogEvent objects while either ZnClient or ZnServer operates. One of those >> is ZnServerTransactionEvent, which signals the completion of a single HTTP >> transaction (request/response pair) by the server. By subscribing to this >> specific event through Zinc's Announcer, we can simply count the number of >> transactions. If we report and reset this counter every second, we get a >> rudimentary live updating requests per second monitor, in about ten lines of >> code in a workspace ! >> >> Here is the setup: >> >> | transactionCount transactionsPerSecond | >> transactionCount := 0. >> transactionsPerSecond := 0 asValueHolder inspectWithLabel: 'HTTP req/s'. >> ZnLogEvent announcer >> when: ZnServerTransactionEvent >> do: [ :each | transactionCount := transactionCount + 1 ] >> for: #transactionCountDemo. >> [ [ >> 1 second asDelay wait. >> transactionsPerSecond value: transactionCount. >> transactionCount := 0 ] repeat ] >> forkAt: Processor userBackgroundPriority >> named: #transactionCountDemo. >> >> Then we start the server: >> >> ZnServer startDefaultOn: 8080. >> >> In a terminal, we use ab (the Apache Benchmark tool) to generate some load >> on the server (10K requests for 1K random data, using 4 concurrent threads): >> >> $ ab -k -n 10240 -c 4 http://localhost:8080/random/1024 >> >> Here is a short 2 minute screencast showing this little demo in action (be >> sure to select the HD version): >> >> https://www.youtube.com/watch?v=gaUxPNq6_7c >> >> It starts by showing how a AnnouncementSpy can be used to monitor the >> server starting up and handling a single request - the logging from the >> client is visible as well. The lines in the AnnouncementSpy are not just >> text, but full, detailed objects. We inspect and explore the same >> transaction from both the client and server perspective. >> >> Next is the demo of the live updating requests per second monitor with the >> load described above. You can see that both our counter and ab report >> approximately the same number: about 800-900 req/s. >> >> And finally, here is the cleanup code: >> >> ZnLogEvent announcer unsubscribe: #transactionCountDemo. >> ZnServer stopDefault. >> Process allInstances select: [ :each | each name = #transactionCountDemo ] >> thenDo: #terminate. >> >> Note that by using other data elements in the ZnServerTransactionEvent we >> could track bytes transferring in or out, rates of failure, slow requests >> and so. There are lots of possibilities with object logging left to explore, >> as well as lots to learn. >> >> Sven >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

June 17, 2014