- Pharo-dev - lists.pharo.org

Using ZnLogEvents to build a live updating requests per second monitor for an HTTP server
by Sven Van Caekenberghe June 17, 2014

June 17, 2014

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

4 4

Survey - needing Protocol Chooser when creating methods from the debugger
by Ben Coman June 17, 2014

June 17, 2014

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

6 6

strange difference between localhost and 127.0.0.1 with a Zinc server on mac
by Luc Fabresse June 16, 2014

June 16, 2014

Hi, I experiencing a strange difference between localhost and 127.0.0.1. In Pharo I do: (ZnServer startDefaultOn: 4444) onRequestRespond: [ :request | ZnResponse ok: (ZnEntity text: 'hello') ] In bash: $ lsof -Pi | grep Pharo Pharo 2718 luc 7u IPv4 0x1e64a2e9381f409b 0t0 TCP *:4444 (LISTEN) I perfectly listen on port 4444 from all interfaces * $ curl http://127.0.0.1:4444 hello $ curl http://localhost:4444 curl: (7) Failed to connect to localhost port 4444: Connection refused *<- why ?* localhost is correctly resolved on my mac $ ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.044 ms I tested with other programs than Zinc to open listening sockets and it works. Any idea? #Luc

5 14

Re: [Pharo-dev] [PROVENANCE INTERNET] Re: Brainstorming Pharo4
by Goubier Thierry June 16, 2014

June 16, 2014

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

2 1

New Cog & Spur VMs available
by Eliot Miranda June 16, 2014

June 16, 2014

in http://www.mirandabanda.org/files/Cog/VM/VM.r3003/. Apologies for the non-Spur VMs in r3000 which should have had the "relocating call to invalid address" bug fixed but I made a mistake. It is fixed in 3003. Further, those who got crashes running the test suite due to the Aio tests should now find the VM does not crash. CogVM source as per VMMaker.oscog-eem.774/r3003 Remember to regenerate the cogit.c's from the non-Spur configurations to fix the "relocating call to invalid address" bug. Add a hack to link the XDisplayControlPlugin against vm-display-X11 (a hack because it assumes paths etc). But at least the plugin works. Add an initial revision of platforms/unix/plugins/UUIDPlugin/acinclude.m4 to search for uuid.h in either /usr/include/uuid or /usr/include and use either uuidgenerate or uuidgen. -- best, Eliot

3 2

Vm on Mac OS 7.5 no cairo
by Stephan Eggermont June 16, 2014

June 16, 2014

I find I'm unable to use a recent vm with Roassal/cairo on Mac OS 7.5. The dec 12 version works, but all new ones say: failed to get a symbol address: cairo_image_surface_create Stephan

3 4

Brainstorming Pharo4
by Esteban Lorenzano June 16, 2014

June 16, 2014

Hi, A couple of weeks ago we started to plan Pharo4. This work became stagnated for many reasons, but mainly because I needed to travel to Argentina. Now I'm slowly resuming the work and I wanted to share with you what we have been talking/dreaming. In esence, we have two important drivers for this release: 1) Improving tools Turns out that we have introduced a lot of kernel improvements (opal compiler, layouts, slots, etc.) and tools are still not aware of them. Even worst: we have traits since a lot of time and our tools are still now aware enough to provide good interoperability. But not just that: we have introduced things that are not well used yet: keybindings (who do not want a better keybindings structure... coherent and editable?), spec should allow us to continue enhancing existing tools and to replace old ones. 2) Modularisation One of the fundamental ideas behind Pharo is to provide a modular environment. But well... since Pharo start to the moment, we prepared things to allow it, but still few direct effort has been made. In our dreams, Pharo should be built starting for a small kernel image and adding different modules to get a complete version. In this idea Pharo=Kernel+GUI(Morphic)+Tools. This has huge advantages (I do not think is necesary to explain them, isn't ;)?) We brainstomed around this and we get this list of issues (not all of them directly related to the objectives, but well... good stuff also :) ) Web site: - add catalog - add videos - enhance it in general Infrastructure: - support more vm platforms VM: - spur - 64bits - make vm embedable and UI independent (with SDL2 and OSWindow) Image: - Modularisation - Removing old compiler - Repackage Morphic (to allow better modularisation) - Athens (replace old bitblt) Tools - Replace changes with Ombu/Epicea - Replace sources with a better abstraction - Git support inside image (with libgit2 + tools) - Pass on Spec - Include Glamour? - Make Ring unloadable - Fonts with FreeType And lots of bugfixes :) We would like to exchange ideas with you. So, what do you think? Esteban

19 32

Spec list with checkboxes?
by Yuriy Tymchuk June 16, 2014

June 16, 2014

Hi everyone. I need to generate arbitrary number of checkboxes and I wander if there is something like a list with checkboxes or something similar. I know that I can use dynamic UI, but maybe there are some existing components that can help to solve the problem. Uko

2 2

[experimental/in-progress] Framework agnostic pure object logging for Zinc
by Sven Van Caekenberghe June 16, 2014

June 16, 2014

Hi, Since years, Zinc has been using its own Announcements-based logging mechanism for client and server logging. The payload of the Announcements used was still essentially text based though. In some discussions months ago with Norbert Hartl in the context of his work on SystemLogger, the concept of pure object logging as an alternative to text based logging became an interesting alternative for me. In an internal project that I did earlier this year I tried out this concept for myself and was quite happy with the result. Doru Girba had indicated several times to me that he was also interested in thinking about logging, so when he started talking about Beacon, I decided to write down my ideas a bit in a quick draft: https://github.com/svenvc/docs/blob/master/draft/logging-with-objects.md And to make this even clearer, I had to change Zinc logging to work along these principles. The current #bleedingEdge experimental/in-progress version of Zinc now contains a first working version of 'framework agnostic pure object logging'. The conversion is not yet finished - there is still much to learn here - but it already looks quite nice I think. Monitoring logging output can be done by opening an Announcement Spy. ZnNewLogEvent open. Next you run some code (start a server, do one request, stop the server). (ZnServer defaultOn: 1701) route: #server1; start. ZnClient new clientId: #client1; beOneShot; get: 'http://localhost:1701/random'. ZnServer stopDefault. Which give the following output (using the standard string representation). However, each line is a rich object containing tons of information. Here is the highlighted line in the Explorer. As you can see, all information from during the client and the server's execution is preserved, ready to be used for logging and/or debugging, right now or later on. Nowhere in the main ZnClient or ZnServer logging code is there simple string or text logging, everything being logged by announcing a log event object. I hope that this plays well with both SystemLogger, Beacon and maybe other logging frameworks out there. When I bring this approach more and more in production use, it will most probably evolve further. In the meantime, have a look: I would love feedback. Sven

5 5

WhatsUp from: 2014-06-16 until: 2014-06-30
by seaside＠rmod.lille.inria.fr June 16, 2014

June 16, 2014

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-06-30 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

2 1