- Pharo-dev - lists.pharo.org

[Pharo-project] Select multiple items in ObjectExplorer

by HernÃ¡n Morales Durand

Hi guys, Have you seen out there a specialized ObjectExplorer where you may select several items? Cheers, HernÃ¡n

June 18, 2012

Re: [Pharo-project] PackageOrganizer packages vs. categories

by Eliot Miranda

On Sun, Jun 17, 2012 at 6:30 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 18 June 2012 01:13, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > On Sun, Jun 17, 2012 at 3:46 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 17 June 2012 23:17, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >> >> Guys, we should hack this together. > >> >> When is next sprint? :) > >> > > >> > Next friday? > >> > > >> > >> Yeah,.. > >> because i still found things which i fail to understand in > >> SystemNavigation: > >> some while ago we kind of decided that best would be to match the > >> protocol(s) of > >> CompiledMethod and RGMethodDefinition, so you can use either one or > >> another or mix of them > >> as a model for browsers/lists etc including SystemNavigation. > >> > >> But it looks like we're still not there: > >> > >> methods := Object methodDict values. > >> SystemNavigation default browseMessageList: methods name: 'Object > methods' > >> > >> fails miserably.. > >> but if i convert it to #methodReference, it works: > >> > >> methods := (Object methodDict values). > >> methods := methods collect: #methodReference. > >> SystemNavigation default browseMessageList: methods name: 'Object > methods' > >> > >> and i feel like i was fooled: we replaced one wrapper - > >> MethodDefinition (or what was that?) > >> with another with just different name. But we still cannot use > >> CompiledMethod as a model for lists > >> etc.. > >> so can someone enlighten me, what is then changed, except a name(s)? > > > > > > I did it a long time ago in VisualWorks 3.0 (IIRC). See below. > > > >> > >> I am still clueless, why system tools cannot speak directly with > >> object(s) under the question, if necessary? > > > > > > The wrapper is a pointer. If one redefines a method when recompiling > then > > the pointer refers to the current version of the method but a direct > > reference to the method answers the old version. The direct reference > > prevents the old version being garbage collected but the pointer does > not. > > For these reasons we use methodReference and not direct references. So > the > > use of pointers is necessary to make the tools work as expected. When > > methods are selected in the method list browser tools, the tools show > > current versions, not versions as of when they were opened. This is the > > same as the system browser, which holds onto class names and selectors, > not > > on class objects and method objects. > > > > By the way, in the olden days the method list browsers worked with > strings > > that looked like 'Foo selector' and 'Foo class selector:' which were > > pointers, but painful to parse to indirect to CompiledMethods. I added > > MethodReference in VisualWorks to replace these large and inflexible > strings > > with explicit pointer objects. Looks like Squeak followed suit. > > > > I know it. > But the point is, that those tools are subscribed to system changes, > and so, if listed method get changed or removed, the tool can update > it's list accordingly, > without a need to hold indirect pointer. > IIABDFI, KISS > > > > > As evidence of painful parsing here's code form the Smalltalk-80 > > MethodListBrowser: > > > > MethodListBrowser methodsFor: 'method list' > > methodName: selection > > | aStream aSymbol | > > methodName _ selection. > > selection == nil ifTrue: [selector _ nil. ^ self textMode: > > #unclassified]. > > aStream _ ReadStream on: selection. > > className _ (aStream upTo: $ ) asSymbol. > > aSymbol _ (aStream upTo: $ ) asSymbol. > > (meta _ (aSymbol == #class) & aStream atEnd not) ifTrue: > > [aSymbol _ (aStream upTo: $ ) asSymbol]. > > protocol _ self selectedClass organization categoryOfElement: > aSymbol. > > self selector: aSymbol > > > >> > >> -- > >> Best regards, > >> Igor Stasenko. > > > > -- > > best, > > Eliot > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

June 18, 2012

Re: [Pharo-project] PackageOrganizer packages vs. categories

by Igor Stasenko

On 18 June 2012 01:13, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Sun, Jun 17, 2012 at 3:46 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 17 June 2012 23:17, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> Guys, we should hack this together. >> >> When is next sprint? :) >> > >> > Next friday? >> > >> >> Yeah,.. >> because i still found things which i fail to understand in >> SystemNavigation: >> some while ago we kind of decided that best would be to match the >> protocol(s) of >> CompiledMethod and RGMethodDefinition, so you can use either one or >> another or mix of them >> as a model for browsers/lists etc including SystemNavigation. >> >> But it looks like we're still not there: >> >> methods := Object methodDict values. >> SystemNavigation default browseMessageList: methods name: 'Object methods' >> >> fails miserably.. >> but if i convert it to #methodReference, it works: >> >> methods := (Object methodDict values). >> methods := methods collect: #methodReference. >> SystemNavigation default browseMessageList: methods name: 'Object methods' >> >> and i feel like i was fooled: we replaced one wrapper - >> MethodDefinition (or what was that?) >> with another with just different name. But we still cannot use >> CompiledMethod as a model for lists >> etc.. >> so can someone enlighten me, what is then changed, except a name(s)? > > > I did it a long time ago in VisualWorks 3.0 (IIRC). Â See below. > >> >> I am still clueless, why system tools cannot speak directly with >> object(s) under the question, if necessary? > > > The wrapper is a pointer. Â If one redefines a method when recompiling then > the pointer refers to the current version of the method but a direct > reference to the method answers the old version. Â The direct reference > prevents the old version being garbage collected but the pointer does not. > Â For these reasons we use methodReference and not direct references. Â So the > use of pointers is necessary to make the tools work as expected. Â When > methods are selected in the method list browser tools, the tools show > current versions, not versions as of when they were opened. Â This is the > same as the system browser, which holds onto class names and selectors, not > on class objects and method objects. > > By the way, in the olden days the method list browsers worked with strings > that looked like 'Foo selector' and 'Foo class selector:' Â which were > pointers, but painful to parse to indirect to CompiledMethods. Â I added > MethodReference in VisualWorks to replace these large and inflexible strings > with explicit pointer objects. Â Looks like Squeak followed suit. > I know it. But the point is, that those tools are subscribed to system changes, and so, if listed method get changed or removed, the tool can update it's list accordingly, without a need to hold indirect pointer. > > As evidence of painful parsing here's code form the Smalltalk-80 > MethodListBrowser: > > MethodListBrowser methodsFor: 'method list' > methodName: selection > Â Â | aStream aSymbol | > Â Â methodName _ selection. > Â Â selection == nil ifTrue: [selector _ nil. ^ self textMode: > #unclassified]. > Â Â aStream _ ReadStream on: selection. > Â Â className _ (aStream upTo: $ ) asSymbol. > Â Â aSymbol _ (aStream upTo: $ ) asSymbol. > Â Â (meta _ (aSymbol == #class) & aStream atEnd not) ifTrue: > Â Â Â Â [aSymbol _ (aStream upTo: $ ) asSymbol]. > Â Â protocol _ self selectedClass organization categoryOfElement: aSymbol. > Â Â self selector: aSymbol > >> >> -- >> Best regards, >> Igor Stasenko. > > -- > best, > Eliot > -- Best regards, Igor Stasenko.

June 18, 2012

Re: [Pharo-project] FileSystem and file extensions

by Igor Stasenko

yep. extension should be the thing after _last_ dot. On 18 June 2012 02:35, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Eliot Miranda-2 wrote >> >> Â Â #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: >> [:thing| thing extension] => #('' 'tar' 'gz' 'tar' 'gz') >> and >> Â Â #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: >> [:thing| thing extensions] => #(#() #('tar') #('gz' 'tar') #('tar' '1') >> #('gz' 'tar' '1')) >> or >> Â Â #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: >> [:thing| thing extensions] => #(#() #('tar') #('tar' 'gz') #('1' 'tar') >> #('1' 'tar' 'gz')) >> > > Sounds good. > > -- > View this message in context: http://forum.world.st/FileSystem-and-file-extensions-tp4635256p4635293.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

June 18, 2012

Re: [Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Igor Stasenko

and besides, concerning buggy, the tests which i implemented for ephemerons are green. It maybe, that tests are not fully cover the specs.. sure it can be possible. So if you have some more complex/tricky tests in mind, feel free to add them. -- Best regards, Igor Stasenko.

June 18, 2012

Re: [Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Igor Stasenko

On 18 June 2012 01:36, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Sun, Jun 17, 2012 at 7:40 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 17 June 2012 15:09, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> > >> > Igor Stasenko wrote >> >> >> >> I bet if you do that, some people will be alienated/antagonized by >> >> this change >> > Yes, but 2.0 is changing *alot*, so this is a good time to sneak this in >> > :) >> > Like pulling off a BandAid... the best thing to do is pull fast and get >> > it >> > over with. >> > >> > >> > Igor Stasenko wrote >> >> >> >> As a compromise i would suggest to force people to explicitly tell >> >> their intent >> > That would be an improvement... Also, what's the status of this >> > limitation >> > >> > (http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082565.html) >> > : >> > >> > when:do: anActionBlock subscription does >> >> not work weakly, you are constrained to when:send:to >> > >> > IIUC it was waiting on ephemerons >> > (http://forum.world.st/Working-with-weak-announcements-td3305802.html) >> > >> >> yes. we can add Ephemerons at any moment now. But then people should >> use only VMs built >> on Jenkins, because Eliot's VMs not support them. > > > I wish you would reconsider and reimplement VM ephemeron support using the > format field as we discussed not the class hack you've implemented which is > I think buggy and unsafe. > I don't think changing the format will make it less buggy. The main problem (or perhaps uncertainty) which i faced is the routines to manage stack/JIT space, which run after usual heap tracing is done, which not very well fit with ephemeron strategy, and it won't change if i just use different format. See the #markPhase: i inserted "Process ephemerons" +++ self processEphemeronsQueue: fullGCFlag. before following: "Free unused stack pages. Only safe to free stack pages after all have been traced. " fullGCFlag ifTrue: [ self freeUnusedStackPages ]. "Only safe to free any machine code methods after all stack pages have been traced." self markAndTraceOrFreeMachineCode: fullGCFlag. that means that potentially (in some very unlikely situation), if new ephemeron will be disovered in #markAndTraceOrFreeMachineCode , it won't be processed as it should. I still don't understand why you tracing machine code, because this is just a cache of corresponding compiled methods, and discovering references which reachable only via machine code but not via conventional object memory heap, should actually point to an error in design. And that's why by knowing that, i were so bold to put #processEphemeronsQueue: before that code. So, if an object format is the only concern, and not the above, i can just change it (thanks we have unused format #5 ). -- Best regards, Igor Stasenko.

June 18, 2012

Re: [Pharo-project] FileSystem and file extensions

by Sean P. DeNigris

Eliot Miranda-2 wrote > > #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: > [:thing| thing extension] => #('' 'tar' 'gz' 'tar' 'gz') > and > #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: > [:thing| thing extensions] => #(#() #('tar') #('gz' 'tar') #('tar' '1') > #('gz' 'tar' '1')) > or > #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: > [:thing| thing extensions] => #(#() #('tar') #('tar' 'gz') #('1' 'tar') > #('1' 'tar' 'gz')) > Sounds good. -- View this message in context: http://forum.world.st/FileSystem-and-file-extensions-tp4635256p4635293.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 18, 2012

Re: [Pharo-project] FileSystem and file extensions

by Eliot Miranda

On Sun, Jun 17, 2012 at 4:50 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > indeed this is a bit tricky... but what can you explicitely say :/ > > foo.tar > foo.tar.gz > foo.1.tar > foo.1.tar.gz > > it's rather hard to decide which is the real extension and which one not :) > Why not #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: [:thing| thing extension] => #('' 'tar' 'gz' 'tar' 'gz') and #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: [:thing| thing extensions] => #(#() #('tar') #('gz' 'tar') #('tar' '1') #('gz' 'tar' '1')) or #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: [:thing| thing extensions] => #(#() #('tar') #('tar' 'gz') #('1' 'tar') #('1' 'tar' 'gz')) ? foo.1.tar.gz is still (supposedly) gzipped data. foo.1.tar is still (supposedly) a tar file. so it might make sense to define a couple of test cases to see what we want > (and maybe compare it to ruby / python / java) > > maybe we can add at least an #extensions method returning a list or so. > If you check `man basename` you can pass explicitly an extension name to > be stripped away from the full basename. maybe that's a better strategy? > > we should definitely find a solution for this! > > > On 2012-06-17, at 19:43, Guillermo Polito wrote: > > > Hi! > > > > I've seen that FS takes as a file extension everything after the first > dot, > > instead of the last one. > > > > Now, that conflicts with the naming we are using for our files: > > > > - changesets and fileouts often take the form something.cs, > something.1.cs, > > something.2.cs > > - image names: pharo-2.0.image, pharo-2.0.1.image > > > > One of them has to be changed I think... :) > > > > Also, I'm more used to the other definition of extension: All after the > > last dot :S > > > > Guille > > > -- best, Eliot

June 17, 2012

Re: [Pharo-project] PrimitiveFailed: primitive #deleteDirectory: -> Cannot update to latest version

by Camillo Bruni

latest VM you are running on? YODA Just make sure you kill all the crappy old VMs on your system and replace them with versions that have the file primitives properly implemented :P On 2012-06-18, at 01:04, Guillermo Polito wrote: > Weird, I was able to update 2 secs ago :S > > On Sun, Jun 17, 2012 at 11:31 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> I cannot update since it popup us this error: PrimitiveFailed: primitive >> #deleteDirectory: >> for every file that is downloaded.... >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >>

June 17, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by Camillo Bruni

On 2012-06-17, at 21:42, phil(a)highoctane.be wrote: > Don't get me wrong. I love all of what I do see in there. I've done a > ton of Maven2 stuff (including setting up a quite large maven proxy), > so I perfectly understand the ton of hard work that goes along with > configs. Much important, much needed, much significant work. > > Just that I am running a business and want to make Pharo a cornerstone > of my technical tools. > > This means that I'll have to explain it to a lot of people partnering > with me. I need traction to pull them in. > > There is incredible potential in Pharo. Just that for the newcomer, > the paradigm switch to an image-based beast is big enough to smoothen > the curve. And we can do it. > > Phil maybe you should try again under 2.0 to load configs. We got some massive speedups in Monticello by caching the right things :P. now 2.0 is alpha so be warned :)

June 17, 2012