- Pharo-dev - lists.pharo.org

Re: [Pharo-project] IPAddressCountry & Iso3166CountryLongitudeLatitude

by Sven Van Caekenberghe

On 04 Apr 2011, at 15:45, Henrik Johansen wrote: > PS. I take it you'd be interested in updating SmallInteger digitAt: / digitLength to work in 64bit images if they become available? ;) I am not quite sure what you mean. The particular server this application is running on is a quite plain vanilla Dual Core Xeon (4 virtual CPU's @ 3Ghz, 4 GB RAM) running Ubuntu 8.04.4 LTS 64-bit Server edition, shared with some other applications, one taking 2Gb. The server has a high quality internet feed. The Cog VM's can only use 1 core and are 32-bit as far as I know. Running 4 of them better utilizes the machine. Monit, automatic process management, keeps the instances alive. The load balancer + the process management should improve reliability and scalebility under load. Each instance uses less than 100 Mb for its heap, so there is plenty of room left. In terms of addressing space, I don't need more. Granted, representing IPv4 addresses as Integers requires 32 bits, and results in LargePositiveInteger usage. So a 64-bit VM could be better. But honestly, searching through 140.000 entries using binary search is currently very fast already. To give you an idea, for the full stack over the internet (and thus depending on the network, YMMV) : $ ab -k -n 1024 -c 32 http://easy.t3-platform.net/rest/geo-ip?address=81.83.7.35 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 easy.t3-platform.net (be patient) Completed 102 requests Completed 204 requests Completed 306 requests Completed 408 requests Completed 510 requests Completed 612 requests Completed 714 requests Completed 816 requests Completed 918 requests Completed 1020 requests Finished 1024 requests Server Software: Zinc Server Hostname: easy.t3-platform.net Server Port: 80 Document Path: /rest/geo-ip?address=81.83.7.35 Document Length: 76 bytes Concurrency Level: 32 Time taken for tests: 1.118 seconds Complete requests: 1024 Failed requests: 0 Write errors: 0 Keep-Alive requests: 1024 Total transferred: 312657 bytes HTML transferred: 77900 bytes Requests per second: 915.75 [#/sec] (mean) Time per request: 34.944 [ms] (mean) Time per request: 1.092 [ms] (mean, across all concurrent requests) Transfer rate: 273.05 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 4.8 0 32 Processing: 21 34 7.9 32 76 Waiting: 21 34 7.9 32 76 Total: 21 34 9.6 32 109 Percentage of the requests served within a certain time (ms) 50% 32 66% 36 75% 38 80% 40 90% 45 95% 54 98% 64 99% 70 100% 109 (longest request) This means that for 32 concurrent requests, speed is close to 1000 request per second, or 1 ms per request. (Granted the payload is small and keepalive is involved). For me, this means that one can do almost anything with a Smalltalk server. And that is the main point I want to make and share. Regards, Sven

April 4, 2011

Re: [Pharo-project] [SPAM] Re: IPAddressCountry & Iso3166CountryLongitudeLatitude

by Sven Van Caekenberghe

On 04 Apr 2011, at 17:44, StÃ©phane Ducasse wrote: > I would love to have your application in our success stories :) > do you have a simple paragraph? I will be adding more stuff in the coming months, after that things will be closer to a 'success story' than today, this is just a first step. Sven

April 4, 2011

[Pharo-project] Draft Pharo 1.2.1 Release Announcement

by Sven Van Caekenberghe

I have a draft for a release announcement for Pharo 1.2.1 http://homepage.mac.com/svc/Pharo/pharo-1.2.1-release.html [ THIS IS A DRAFT !! - DO NOT YET RELEASE ] Please check this for errors and omissions, I will try to integrate the remarks tomorrow. Please check the links as well. I tried to stick with the basics, as one could write about so much (introducing Pharo Smalltalk and its features could be useful, but is quite challenging; everything loaded into dev could be described, and so on). I am sure I am not doing justice to all efforts by everybody, please give feedback. To give it a little twist, I started with a little 'story' called 'Update #12345', maybe it is to geeky, but it felt like a good angle to cover the basics about the process and the time spent. The most useful raw material was this http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotTwo It feels as if more could be said about Dev. I also tried to stick with just a simple screenshot, I could come up with more complicated ones, but we cannot put everything on one screenshot. Sven

April 4, 2011

Re: [Pharo-project] Issue 3958 in pharo: Remove embedded snapshotting (image level)

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #1 on issue 3958 by marcus.d...(a)gmail.com: Remove embedded snapshotting (image level) http://code.google.com/p/pharo/issues/detail?id=3958 (No comment was entered for this change.)

April 4, 2011

[Pharo-project] Issue 3959 in pharo: A little dead code removal SmalltalkImage

by pharo＠googlecode.com

Status: FixProposed Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3959 by marcus.d...(a)gmail.com: A little dead code removal SmalltalkImage http://code.google.com/p/pharo/issues/detail?id=3959 1) test for formatter SmalltalkImage removeSelector: #testFormatter! SmalltalkImage removeSelector: #testFormatter2! not used, the current pretty printer is crap anyway. 2) #shutDownSound Attachments: RemoveFormatterTestsSmalltalkImage.1.cs 190 bytes RemoveShutDownSound.1.cs 142 bytes

April 4, 2011

[Pharo-project] Issue 3958 in pharo: Remove embedded snapshotting (image level)

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3958 by marcus.d...(a)gmail.com: Remove embedded snapshotting (image level) http://code.google.com/p/pharo/issues/detail?id=3958 SmalltalkImage has code to save the image "embedded" into the executable of the VM. Experimental code, not used for years, not useful these days. Removal attached Attachments: CleanUpEmbeddedImageSaving.1.cs 2.4 KB

April 4, 2011

Re: [Pharo-project] Let's get rid of Core vs. Full

by GermÃ¡n Arduino

As I can understand the proposal of Marcus is not have anymore an image without the minimal set of tools for development. And I full agree with this option. Allways is possible to shrink the image in a next step if needed. In other words, to me Core is not useful witthout a minimal set of dev tools and I'm doing production deployments with such tools with no problems. By other hand, as most of the images are in remote servers I need to use them via VNC and with the dev tools. Just my opinion. Cheers. 2011/4/4 Tudor Girba <tudor.girba(a)gmail.com>: > This is what I understood from what Marcus said, too :) > > Cheers, > Doru > > > On 4 Apr 2011, at 15:57, StÃ©phane Ducasse wrote: > >> This is my ideas. >> >>> My proposition for 1.3: >>> 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) >>> 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser >>> 3) If it is possible, develop Core image into this reduced full image. >> >> > > -- > www.tudorgirba.com > > "Every thing should have the right to be different." > > > > >

April 4, 2011

Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)

by StÃ©phane Ducasse

In fact he got a better changeClassToThatOf: implementation and got kind of initform for slots. Stef > I do read French too, no problem. > > I'm having a look at > > http://fredrivard.ifrance.com/fredrivard/pub/dicl/dicl.ps > > That seems related. > > On 04/04/2011 09:20 PM, Alexandre Bergel wrote: >> he he. I am not sure Fred wrote in English. >> http://scg.unibe.ch/scgbib?_k=qQPhJdNf&query=rivard >> >> Cheers, >> Alexandre >> >> >> On 4 Apr 2011, at 14:15, Toon Verwaest wrote: >> >>> Do you have an exact reference on this? >>> >>> On 04/04/2011 05:55 PM, StÃ©phane Ducasse wrote: >>>>> Another very cool thing that we can do now (which would require 3 lines of change in my system though), is that the slot can also be responsible for instance migration. There are four cases: >>>>> 1- the instance variable didn't exist and now it does >>>>> 2- the instance variable existed but disappeared >>>>> 3- the metaobject changed (new semantics) >>>>> 4- the metaobject stayed the same >>>>> >>>> Did you check the work of fred rivard because he was managing the dynamic change of class and managing slot reinitialization? >>>> >>>> >>>>> Basically the only case that is "handled" by standard Pharo is case 1; and what you do there is putting nil in the field. In our model the slot could do something more interesting when it's migrating the instances. And we could tackle the other cases too. I think it's starting to get ideal to implement an active context on top ;-) >>>>> >>>>> cheers, >>>>> Toon >>> > >

April 4, 2011

Re: [Pharo-project] Transcript rant

by StÃ©phane Ducasse

On Apr 4, 2011, at 8:22 PM, Toon Verwaest wrote: > >> Ok so how do we make progress? > My favorite strategy: reimplement and replace. > If this means I'll have to do it... I can, but not this month. It will of course mean that everybody who relies on the old code will break... so we might need a transitional compatibility class; although I think that these users should just rewrite their code. It doesn't make sense whatsoever. we could simply revert the changes of CUIS. > > I don't have too much knowledge about the whole architecture though; and I'd prefer to spend time on getting my classbuilder in a state that it can be incorporated safely. That would be progress. yes I prefer knowing you working on that :) > > cheers, > Toon >

April 4, 2011

Re: [Pharo-project] Announcement real problems - please read and comment.

by StÃ©phane Ducasse

> Ok guys so I want a solution :). >> So how can we improve Announcement to cover different cases? >> >> Stef >> > Both solutions lead to remaining subscribers being notified when an error occurs. > So which is decided upon, depends on which of their respective benefits are valued more. > For that, it'd be nice if more than 2 people chimed in on. :) :) Me too Thanks a lot for the analysis and pros and cons! I have the impression but I would really like to hear other voices on it that the ease of debugging is a big plus for me. But robustness is important too. > Short summary (not guaranteed to be 100% objective) > > Curtailing -> > - Your image may crash in some cases, more specifically if you: > 1) have errors in subscribers to announcements made in system-critical processes, as they will be suspended while debugging. > 2) deliver announcements in a separate thread from where they're announced, and the announcing thread does so regularily. > + Easy to debug. Entire call-chain available, no modification to state caused by subsequent subscribers. Restart should always lead in bug being reproduceable. > > The remove-from-subscriptions part of Error-handling and ifCurtailed could be combined as well, in which case #2 no longer applies. > > Error handling -> > - Hard/impossible to debug because: > 1) If your error was in ordering, debugger will step through flawlessly if restarted. > 2) You start at the context of the subscriptions action, no idea where it came from. > + More robust, none of the cases mentioned in Curtailing will crash your image. > > > With the different pros/cons mentioned above in mind, here are .cs with example implementations for what both Igor / I would like. (minus remove-from-subscriptions for ifCurtailed: ) > > Cheers, > Henry > <AnnouncementErrorHandling.zip>

April 4, 2011