January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3499 in pharo: FixUnderscores (package & instructions) out of date

by pharo＠googlecode.com

Comment #10 on issue 3499 by stephane.ducasse: FixUnderscores (package & instructions) out of date http://code.google.com/p/pharo/issues/detail?id=3499 We should not update 22 now why do you remove the description using FixUnderscore from the book. People can take their responsibility.

Jan. 4, 2011

Re: [Pharo-project] Pharo and CommandShell on OSX ?

by David T. Lewis

On Mon, Jan 03, 2011 at 09:06:37PM -0800, Stef T wrote: > > On Jan 3, 2011, at 7:25 PM, David T. Lewis wrote: > > > On Mon, Jan 03, 2011 at 06:55:45PM -0800, Stef T wrote: > >> 1) CommandShell complains about AioPlugin not being present and that it will use the 'old slow' way. That's fine, it's merely a warning > > > > AFAIK, noone has tried building the AioPlugin for Mac, so you will get this > > warning when running on a Mac. But as you say, it's just a warning. > > Is there a pointer for the source code ? I am pretty handy with Xcode and don't mind giving it a whirl ;) > AioPlugin is on SqueakSource in http://www.squeaksource.com/AioPlugin. It's written in Smalltalk, translated to C. I don't have any experience with Mac or Xcode but there are others on the Pharo/Squeak/vm-dev lists who can probably help. > > > >> but > >> 2) None of the commands get executed. If I try the stuff which will eval inside squeak/pharo, then that's fine (Eg; stdout nextPutAll: 'hello world'; cr.). However, if I try a command such as 'ls' or 'who', all hell breaks lose. stack trace follows :) > >> > >> If I am doing anything obviously wrong, please feel free to hit me over the head :) > > > > Nope, it's not you, it's the plugin included with your VM. Some > > of the Mac VMs in circulation were accidentally built with a very > > out of date version of the OSProcessPlugin. Apparently you have > > one of them, and it will definitely not work. But I think there > > is a newer version (4.2.5 IIRC) that has the up to date plugin > > that works properly on Mac. > > > > Hrm, I am using the OSProcess from squeaksource .59. The version history says > > Name: OSProcess-dtl.59 > Author: dtl > Time: 28 November 2010, 8:43:48.839 pm > UUID: bd5d2b4e-efbd-4091-ac0a-d0bd7af64b2c > > surely this is 'new enough' ? Is there a known 'stable' version you would suggest ? > > regards > S. I was referring to the OSProcessPlugin, which separate from the OSProcess package. The plugin is on SqueakSource at: http://www.squeaksource.com/OSProcessPlugin This is written in Smalltalk, translated to C and compiled as a VM plugin. It was originally part of of OSProcess, but I split it out to a separate package years ago. You have an up to date OSProcess package, but your OSProcessPlugin is many years old, from back before we got it working on Mac. The old plugin will crash your VM. Dave

Jan. 4, 2011

[Pharo-project] Some questions about omnibroser framework

by aizcorbe

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.

Jan. 4, 2011

Re: [Pharo-project] Pharo and CommandShell on OSX ?

by Stef T

On Jan 3, 2011, at 7:25 PM, David T. Lewis wrote: > On Mon, Jan 03, 2011 at 06:55:45PM -0800, Stef T wrote: >> 1) CommandShell complains about AioPlugin not being present and that it will use the 'old slow' way. That's fine, it's merely a warning > > AFAIK, noone has tried building the AioPlugin for Mac, so you will get this > warning when running on a Mac. But as you say, it's just a warning. Is there a pointer for the source code ? I am pretty handy with Xcode and don't mind giving it a whirl ;) > >> but >> 2) None of the commands get executed. If I try the stuff which will eval inside squeak/pharo, then that's fine (Eg; stdout nextPutAll: 'hello world'; cr.). However, if I try a command such as 'ls' or 'who', all hell breaks lose. stack trace follows :) >> >> If I am doing anything obviously wrong, please feel free to hit me over the head :) > > Nope, it's not you, it's the plugin included with your VM. Some > of the Mac VMs in circulation were accidentally built with a very > out of date version of the OSProcessPlugin. Apparently you have > one of them, and it will definitely not work. But I think there > is a newer version (4.2.5 IIRC) that has the up to date plugin > that works properly on Mac. > Hrm, I am using the OSProcess from squeaksource .59. The version history says Name: OSProcess-dtl.59 Author: dtl Time: 28 November 2010, 8:43:48.839 pm UUID: bd5d2b4e-efbd-4091-ac0a-d0bd7af64b2c surely this is 'new enough' ? Is there a known 'stable' version you would suggest ? regards S. > Dave > > >> >> Regards >> S. >> >> >> >> >> 3 January 2011 6:49:43 pm >> >> VM: Mac OS - intel - 1065 - Squeak3.8.1 of '28 Aug 2006' [latest update: #6747] Squeak VM 4.2.4b1 >> Image: Pharo-1.1-11406-rc3 [Latest update: #11406] >> >> SecurityManager state: >> Restricted: false >> FileAccess: true >> SocketAccess: true >> Working Dir /Users/stef/squeak/SeaSide-3.0 >> Trusted Dir /foobar/tooBar/forSqueak/bogus >> Untrusted Dir /Users/stef/Library/Preferences/Squeak/Internet/My Squeak >> >> UndefinedObject(Object)>>mustBeBooleanIn: >> Receiver: nil >> Arguments and temporary variables: >> context: BufferedAsyncFileReadStream>>moveAvailableDataFrom: >> proceedValue: nil >> Receiver's instance variables: >> nil >> >> UndefinedObject(Object)>>mustBeBoolean >> Receiver: nil >> Arguments and temporary variables: >> >> Receiver's instance variables: >> nil >> >> BufferedAsyncFileReadStream>>moveAvailableDataFrom: >> Receiver: BufferedAsyncFileReadStream: 'pipeReader' >> Arguments and temporary variables: >> sqFile: #[48 205 236 155 72 91 120 160 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0] >> bufferSize: 1000 >> buffer: '...etc... >> count: #(0) >> Receiver's instance variables: >> >> >> BufferedAsyncFileReadStream>>moveAvailableDataToBuffer >> Receiver: BufferedAsyncFileReadStream: 'pipeReader' >> Arguments and temporary variables: >> >> Receiver's instance variables: >> >> >> BufferedAsyncFileReadStream>>update: >> Receiver: BufferedAsyncFileReadStream: 'pipeReader' >> Arguments and temporary variables: >> aParameter: a PseudoAioEventHandler >> Receiver's instance variables: >> >> >> [] in PseudoAioEventHandler(Object)>>changed: >> Receiver: a PseudoAioEventHandler >> Arguments and temporary variables: >> aParameter: BufferedAsyncFileReadStream: 'pipeReader' >> aDependent: a PseudoAioEventHandler >> Receiver's instance variables: >> dependents: a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader') >> eventGenerator: a Process in Debugger class>>openOn:context:label:contents:full...etc... >> >> DependentsArray>>do: >> Receiver: a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader') >> Arguments and temporary variables: >> aBlock: [:aDependent | aDependent update: aParameter] >> dep: BufferedAsyncFileReadStream: 'pipeReader' >> i: 1 >> iLimiT: 1 >> Receiver's instance variables: >> a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader') >> >> PseudoAioEventHandler(Object)>>changed: >> Receiver: a PseudoAioEventHandler >> Arguments and temporary variables: >> aParameter: a PseudoAioEventHandler >> Receiver's instance variables: >> dependents: a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader') >> eventGenerator: a Process in Debugger class>>openOn:context:label:contents:full...etc... >> >> PseudoAioEventHandler(Object)>>changed >> Receiver: a PseudoAioEventHandler >> Arguments and temporary variables: >> >> Receiver's instance variables: >> dependents: a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader') >> eventGenerator: a Process in Debugger class>>openOn:context:label:contents:full...etc... >> >> [] in [] in PseudoAioEventHandler>>eventGeneratorProcess >> Receiver: a PseudoAioEventHandler >> Arguments and temporary variables: >> d: a Delay(125 msecs) >> Receiver's instance variables: >> dependents: a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader') >> eventGenerator: a Process in Debugger class>>openOn:context:label:contents:full...etc... >> >> BlockClosure>>repeat >> Receiver: [self changed. >> d wait] >> Arguments and temporary variables: >> >> Receiver's instance variables: >> outerContext: [] in PseudoAioEventHandler>>eventGeneratorProcess >> startpc: 59 >> numArgs: 0 >> >> [] in PseudoAioEventHandler>>eventGeneratorProcess >> Receiver: a PseudoAioEventHandler >> Arguments and temporary variables: >> d: a Delay(125 msecs) >> Receiver's instance variables: >> dependents: a DependentsArray(BufferedAsyncFileReadStream: 'pipeReader') >> eventGenerator: a Process in Debugger class>>openOn:context:label:contents:full...etc... >> >> [] in BlockClosure>>newProcess >> Receiver: [[self changed. >> d wait] repeat] >> Arguments and temporary variables: >> >> Receiver's instance variables: >> outerContext: PseudoAioEventHandler>>eventGeneratorProcess >> startpc: 54 >> numArgs: 0 >> >> >> --- The full stack --- >> UndefinedObject(Object)>>mustBeBooleanIn: >> UndefinedObject(Object)>>mustBeBoolean >> BufferedAsyncFileReadStream>>moveAvailableDataFrom: >> BufferedAsyncFileReadStream>>moveAvailableDataToBuffer >> BufferedAsyncFileReadStream>>update: >> [] in PseudoAioEventHandler(Object)>>changed: >> DependentsArray>>do: >> PseudoAioEventHandler(Object)>>changed: >> PseudoAioEventHandler(Object)>>changed >> [] in [] in PseudoAioEventHandler>>eventGeneratorProcess >> BlockClosure>>repeat >> [] in PseudoAioEventHandler>>eventGeneratorProcess >> [] in BlockClosure>>newProcess >> >

Jan. 4, 2011

Re: [Pharo-project] about growing streams and allocating buffers

by mkobetic＠gmail.com

"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

Jan. 4, 2011

Re: [Pharo-project] [squeak-dev] [4.2] - VM <-> image release coordination

by Chris Muller

> 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 >> >>> > >

Jan. 4, 2011

Re: [Pharo-project] next steps for pharo -- a suggestions on documentation

by csrabak＠bol.com.br

Last year (and IIRC before last year as well) we exchanged a set of clever stubs of code which created a collection of classes had not comments. Could we have one of these scripts run as a part of the process in Hudson for validations/QA of the core images (for starting the whole thing) and a statistic which would allow us to track our progress in the percentage of commented classes in core? -- Cesar Rabak

Jan. 3, 2011

Re: [Pharo-project] Issue 3499 in pharo: FixUnderscores (package & instructions) out of date

by pharo＠googlecode.com

Comment #9 on issue 3499 by sean.p.denigris: FixUnderscores (package & instructions) out of date http://code.google.com/p/pharo/issues/detail?id=3499 The book has been updated, instructing to use RB only http://book.pharo-project.org/book/TipsAndTricks/FixingUnderscores

Jan. 3, 2011

Re: [Pharo-project] Issue 3499 in pharo: FixUnderscores (package & instructions) out of date

by pharo＠googlecode.com

Comment #8 on issue 3499 by sean.p.denigris: FixUnderscores (package & instructions) out of date http://code.google.com/p/pharo/issues/detail?id=3499 Okay, I'm not really attached to it, so if everyone thinks RB is the way to go, let's remove the FU package and I'll update the book.

Jan. 3, 2011

Re: [Pharo-project] Issue 3499 in pharo: FixUnderscores (package & instructions) out of date

by pharo＠googlecode.com

Comment #7 on issue 3499 by miguel.coba: FixUnderscores (package & instructions) out of date http://code.google.com/p/pharo/issues/detail?id=3499 I also think that the FixUnderscores are a bad solution to the problem. The point of having the source code versioned is to track *every* change to it. that includes, accents, spaces, newlines, and of course, source code. I don't know why the underscores should be treated differently. It *is* a change in the code. And it is good to have the source code management system to trackit. Even if no other change more semantic was made. So I vote also for the rules for the refactoring browser and the lint rules to search for underscores in the core image.

Jan. 3, 2011