- Pharo-dev - lists.pharo.org

Re: [Pharo-project] about growing streams and allocating buffers
by mkobetic＠gmail.com Jan. 4, 2011

Jan. 4, 2011

"Philippe Marschall"<kustos(a)gmx.net> wrote: > > preallocation OrderedCollection new: instead of relying on its growing behavior. > > Right, but you never know how big the response is going to before > actually rendering. Otherwise you could just do Array/String new: > beforehand. I'm not quite clear about the context here so this may not be relevant, but one technique that paid of for us in terms of managing socket buffers was to start recycling them. The idea is that if you generally allocate let's say 32K buffer for every socket you open, rather then throwing the buffer away when you're done with the socket, just put it aside and let the next socket pick up and reuse the same instance. For us the main concern was a server being hammered by transient connection requests. Occasional buffer allocation could be handled by new space scavenger just fine, but a flood of such requests made the buffers spill over to the old space and throwing them away got expensive quickly. Anyway, I realize that your concern is different here, but the same technique might help growing in most common cases. If there's a reasonable upper bound on most responses (e.g. 32K), you could simply preallocate that size always. If the request fits, great, no growing, if not, it will grow. However you'd probably have the same sort of problem as we had above if you simply threw each buffer away. Recycling should help making it manageable. We use the same technique in Xtreams, where we need internal buffers quite frequently. Check out the RecyclingCenter class there if you want. It's a bit more generic because we need to accommodate different collection classes, so you'll probably want something different, but the basics should be similar. One aspect to note is that the recycling pool can be quite small. You don't need to recycle every instance created, you only need to be able to handle the "overflow" under load. The idea is that if you are under load and the number of concurrently used buffers fluctuates between 100 and 110, you don't need the recycling pool size to be 110, but only 10. It only needs to retain the temporarily unused buffers long enough for those to get picked up again. When the load subsides, it's fine to let the remaining 100 buffers GC, they can be allocated again quickly when next wave hits. At the same time it keeps the memory load reasonable in the quiet periods. HTH, Martin

3 2

[Pharo-project] Some questions about omnibroser framework
by aizcorbe Jan. 4, 2011

Jan. 4, 2011

I have been using the OmniBroser framework to extend the Lint browser (OR2LintBrowser) and i found some strange behavior i would like to comment: 1) When you select an item in the browser, the metagraph define some edges leading to other metanode types. This is translated sending the edge names to the real nodes and getting all the following nodes, and then, those nodes are displayed on the following column at the browser, and if there isn't a next column it is created. The strange issue here is that, if the messages for edge taking on the concrete nodes retrieves an empty collection of nodes, the next column is created anyway, because for the browser there is a next metagraph node. Is this a problem or not? (I had to define much more complex metagraphs because of this, just to avoid an empty column). 2) When you use filters on the metagraph, they are applied over each taken edge leading to the next metagraph. The filters are usually used for node ordering and here is a problem. If you have more than one edge from the current metanode, you will get a order filter applied over two different edges and then, the order will be not ok, since there will be some partially ordered concatenated node lists, and not just a fully ordered list. 3) Another issue is not about omnibrowser, but i think is worth to be noted. If you extend any class in another package using *package-category protocol for new or modified methods, you will see the extended class on the package root, but you won't see it at the cathegory (i think it would be nice and a little more clear seeing the extensions at the specific package-category). Also i found that TestRunner do not put the unitTest classes under a package unless the class itself where defined at the selected package (even if i added some test using the *package-category protocol name) I hope some of you found this intresting cheers -- View this message in context: http://forum.world.st/Some-questions-about-omnibroser-framework-tp3173047p3… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 6

[Pharo-project] Issue 3499 in pharo: FixUnderscores (package & instructions) out of date
by pharo＠googlecode.com Jan. 4, 2011

Jan. 4, 2011

Status: New Owner: ---- New issue 3499 by sean.p.denigris: FixUnderscores (package & instructions) out of date http://code.google.com/p/pharo/issues/detail?id=3499 Pharo image: Core 1.2 #12270 The CollaborActive book says to mcz version 18, however 17 is already loaded as of 1.1, so I propose: * integrate 18 into trunk * update book (e.g. remove installation step from book - I will do this once the package is integrated) I much prefer using this package over RB because it does not alter the method's timestamp. p.s. this does raise the point of documentation for difference Pharo versions. If the installation step is removed from the book, it will create extra work/confusion for 1.0 users; but if it is left in, it will be a continuing distraction for current users.

1 12

[Pharo-project] next steps for pharo
by Torsten Bergmann Jan. 4, 2011

Jan. 4, 2011

>The coolest programmer of the month ;) Take care, sometimes the "coolest programmer" is the one who is not interested in writing documentation. Sometimes people think they are cool when they win the IOCCC contest [1] or find neat coding tricks that other people do not understand. Following conformance rules, writing clean code or documenting is often seen as "boring task" but necessary to grow into professional shared development. So we have to find a way to turn "boring" into "simple & fun". Bye T. [1] http://de.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

3 3

[Pharo-project] Crash on saving with Monticello
by Alexandre Bergel Jan. 4, 2011

Jan. 4, 2011

Hi! Several of my students experience a crash of Pharo when saving with Monticello. They all use linux. I can ask for more detailed description. Are we the only one to experience this? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 15

Re: [Pharo-project] source.lukas-renggli.ch is down
by Marcus Denker Jan. 4, 2011

Jan. 4, 2011

On Jan 2, 2011, at 2:54 PM, Mariano Martinez Peck wrote: > > > On Sun, Jan 2, 2011 at 1:58 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > > On Sun, Jan 2, 2011 at 1:42 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I do not know I have a lot in my caches. I think that this is a really nice experience we should learn from. > We should really have a replication mechanism. By the end of this week I will get information about the server we need. > > We may have it on the Hudson server for last successfull build ? > > > Yes, this is what I suggested some threads ago...check the latest successfull Pharo1.2 build and take the stuff from package-cache > Server is up again, 1.2core build works again. (1.2full fails due to another problem) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] loading of codetalk fails due to
by Marcus Denker Jan. 4, 2011

Jan. 4, 2011

On Jan 1, 2011, at 6:37 PM, Enrico Spinielli wrote: > hi, > loading codetalk from potsdam now fails with > Error: The spelling dictionary cannot be downloaded from > <http://www.lukas-renggli.ch/smalltalk/rb-spelling.dat>. > > I think this is due to recent changes in RB (which codetalk loads) > http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg24201.ht… > The problem was the server lukas-renggli.ch was down. It seems to work now again. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] removing obsolete classes
by sergio_101 Jan. 4, 2011

Jan. 4, 2011

in working with another problem, i think i have narrowed it down to obsolete classes.. running this: PointerFinder on: SystemNavigation default obsoleteClasses inspect. i find three classes (precisely the ones i am having problems with).. my question is.. how do i go about deleting those classes? thanks! -- ---- peace, sergio photographer, journalist, visionary http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

3 3

Re: [Pharo-project] [squeak-dev] [4.2] - VM <-> image release coordination
by Chris Muller Jan. 4, 2011

Jan. 4, 2011

> Well I should not speak for Eliot r.e. Cog, but he has been releasing > reliable, field-tested Cog VMs for some time now, so planning to have > updated VMs for end of January seems perfectly reasonable to me. That's good news. There is also work to do for the actual releasing, which the VM Release Manager person would have to do (e.g., zip and post to squeakvm.org, etc.), so I wanted to see whether that was doable for them too. When Eliot provides a new (or, recommends an old) version of the Cog VM to release with 4.2, we can perform final tests using that VM for the three platforms. This will be nice for 4.2 (and, for Pharo community too) to be able to announce, "compatible with a new Cog VM downloadable over here", and have a new stable baseline out there. - Chris On Mon, Jan 3, 2011 at 3:02 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Mon, Jan 03, 2011 at 02:14:56PM -0600, Chris Muller wrote: >> Excellent, thanks Eliot. Â That's been the plan for 4.2 all along, I >> see no reason to abandon that now. >> >> I am currently trying to get a 4.2 RC1 built and saved under some >> interpreter VM. Â I will need access or assistance for uploading it to >> ftp.squeak.org (preferably access, since I'd like to build the image >> myself). >> >> Then, I would like to have just under 4 more weeks, until 11:59pm, >> 1/30/2011, for "last call" for 4.2. Â We've been testing for some time >> now, we seem to have a stable, worthy release. Â Throughout January, we >> will need to test (and fix) on all platforms, document, improve >> aesthetics, and update web-sites. >> >> We will push the final release out the week of 1/31. >> >> VM Release Manager: Â Does this time-frame seem doable for a final >> release of the simple-stack VM? >> >> Â - Chris > > Well I should not speak for Eliot r.e. Cog, but he has been releasing > reliable, field-tested Cog VMs for some time now, so planning to have > updated VMs for end of January seems perfectly reasonable to me. > > Dave > > >> >> On Mon, Jan 3, 2011 at 1:53 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > On Sun, Jan 2, 2011 at 11:38 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> >> >> >> Quoting Chris Muller <asqueaker(a)gmail.com>: >> >> >> >>> Levente wrote: >> >>> >> >>>> I think we should wait for the new VMs, before releasing the new images. >> >>> >> >>> Hi Levente, >> >>> >> >>> I did agree, but now that Eliot is on a tear with a new code >> >>> generator, the first official release might still be some weeks away. >> >>> Someone please correct me if that is a misstatement. >> >>> >> >>> It seems unlikely 4.2 will be incompatible with whatever ends up being >> >>> the first official Cog release. ??We should consider pushing it out the >> >>> door so we can re-open the trunk to new featurey. >> >> >> >> That's right, Cog's recent improvements introduced some instability. So I >> >> think we should release Squeak 4.2 with SqueakVM only and postpone the >> >> multi-VM release. We can also make the release cycle of Squeak 4.3 shorter >> >> to catch up with the two release per year policy and deliver the VM >> >> improvements earlier. I'm also sure that a lot of improvements will be done >> >> till April/May on both image and VM side. >> > >> > It would be my preference to release with the Cog VM using the naive >> > SimpleStackBasedCogit code generator. ??After all that's worth at least 3x >> > over the standard VM whereas the unstable StackToregisterMappingCogit is >> > only ~ 8% faster than SimpleStackBasedCogit. ??It's quite easy for me to >> > generate either; the two coexist in the same VMMaker. >> > best >> > Eliot >> >> >> >> >> >> Levente >> >> >> >>> >> >>> ??- Chris >> >>> > >

1 0

[Pharo-project] removing obsolete classes
by sergio_101 Jan. 3, 2011

Jan. 3, 2011

in working with another problem, i think i have narrowed it down to obsolete classes.. running this: PointerFinder on: SystemNavigation default obsoleteClasses inspect. i find three classes (precisely the ones i am having problems with).. my question is.. how do i go about deleting those classes? thanks! -- ---- peace, sergio photographer, journalist, visionary http://www.ThoseOptimizeGuys.com http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

1 0