June 2014 - Pharo-dev - lists.pharo.org

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

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

by Tudor Girba

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 16, 2014

Re: [Pharo-dev] strange difference between localhost and 127.0.0.1 with a Zinc server on mac

by Sven Van Caekenberghe

Thanks for the explanation, Eliot. I am not sure there is a problem resolving localhost and binding to it, as the server did work in the case described, it was just not accessible by curl. I guess we might have to shake down some issue with ipv6 in the future, we'll see. On 14 Jun 2014, at 16:17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Sven, > > > On Sat, Jun 14, 2014 at 4:09 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 14 Jun 2014, at 12:18, Ben Coman <btc(a)openInWorld.com> wrote: > > > Sven Van Caekenberghe wrote: > >> In any case, the server socket used is normally listening on all interfaces [0.0.0.0] > >> > >> Sven > >> > >> > > > > Maybe it matters that [0.0.0.0] is the IPv4-Unspecified-Address > > and it might make a difference to use IPv6-Unspecified-Address [0:0:0:0:0:0:0:0] or [::] > > > > cheers -ben > > I guess it all depends on the Socket plugin. ZnServer has #bindingAddress: which eventually calls Socket>>#listenOn:backlogSize:interface: but the question is, what is acceptable as last argument. And how is the difference between v4 and v6 handled. There is a 'primitives-ipv6' category, but no #listenOn with an interface there. > > I wonder whether this commit is relevant: > > r2552 | eliot | 2012-05-02 16:13:02 -0700 (Wed, 02 May 2012) | 19 lines > > CogVM source as per VMMakerr.oscog-eem.159 > ... > > Fix limitation in platforms/unix/plugins/SocketPlugin/sqUnixSocket.c which could > cause NetNameResolver localHostAddress to answer 0 (if host has a set hostname > not being honoured by local DNS servers). Fix falls back to localhost. > ... > > Here's the relevant part of the platforms/unix/plugins/SocketPlugin/sqUnixSocket.c change: > > -sqInt sqResolverLocalAddress(void) { return nameToAddr(localHostName); } > +sqInt sqResolverLocalAddress(void) > +{ sqInt localaddr = nameToAddr(localHostName); > + if (!localaddr) > + localaddr = nameToAddr("localhost"); > + return localaddr; > +} > > This fixed several socket tests on my Mac OS box. I think it affects systems behind a broadband router, at least that's how it asffected me on my laptop at home. And here's what is probably the root cause in platforms/unix/plugins/SocketPlugin/sqUnixSocket.c: > > ... > static char localHostName[MAXHOSTNAMELEN]; > static u_long localHostAddress; /* GROSS IPv4 ASSUMPTION! */ > ... > /* start a new network session */ > > sqInt sqNetworkInit(sqInt resolverSemaIndex) > { > if (0 != thisNetSession) > return 0; /* already initialised */ > gethostname(localHostName, MAXHOSTNAMELEN); > localHostAddress= nameToAddr(localHostName); > thisNetSession= clock() + time(0); > if (0 == thisNetSession) > thisNetSession= 1; /* 0 => uninitialised */ > resolverSema= resolverSemaIndex; > return 0; > } > ... > and so if gethostname answers something weird, attempts to access localHost are screwed from initialization on. > > HTH > -- > best, > Eliot

June 16, 2014

Re: [Pharo-dev] [PROVENANCE INTERNET] Re: Brainstorming Pharo4

by Tudor Girba

I do :) Doru On Mon, Jun 16, 2014 at 4:35 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 16/06/2014 16:24, Goubier Thierry a Ã©crit : > >> >> >> Le 16/06/2014 16:13, Esteban A. Maringolo a Ã©crit : >> >>> Add this to the wishlist: >>> >>> >>> - Scoped refactorings. Particularly method renames. I'd like to scope >>> the refactorings to class, hierarchy, package or global level. :) >>> >> >> I think it's already there :) >> >> Just need a way to use them. I may already have that, need to test >> (scoped system browser with refactorings coupled to the scope). Try >> scoped browsing with Nautilus and apply refactorings... >> > > And once you're in there, you can refine by cascading scopes. > > In package X, along hierarchy of class Y, find all methods with name > containing visit, rename #visitRootNode: as #acceptRootNode: > > Can also be combined with RB pattern matching for searching in code, but > I'd like to see the GUI for that last one :) Who was said to be working on > that? > > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > -- www.tudorgirba.com "Every thing has its own flow"

June 16, 2014