- Pharo-dev - lists.pharo.org

Re: [Pharo-project] FileSystem and file extensions

by Camillo Bruni

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

June 17, 2012

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

by Eliot Miranda

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. > > > -- > > View this message in context: > http://forum.world.st/Why-don-t-we-always-register-weakly-in-SystemAnnounce… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

June 17, 2012

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

by Eliot Miranda

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

June 17, 2012

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

by Guillermo Polito

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] PackageOrganizer packages vs. categories

by Igor Stasenko

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 am still clueless, why system tools cannot speak directly with object(s) under the question, if necessary? -- Best regards, Igor Stasenko.

June 17, 2012

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

by Mariano Martinez Peck

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 StÃ©phane Ducasse

I reread the web site and this is more for startups? I passed the message to guys around. > Well, it is web-ish enough to warrant some ca$h heh? > > Seaside, tODE, Pier, Zn, Monticello, SS3, all that is web. > > Pharo and the web, distributed coding at its best. > > Pharo is the core upon which all the rest is built for success and > kick-ass delivery! > > Phil > > 2012/6/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> >>> Who wants to hit the button? >>> >>> https://webfwd.org/apply/ >>> >> >> I read it when you told me but I was confused because pharo is not only about web. >> I will reread it. >> >> Stef >> >> > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium >

June 17, 2012

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

by StÃ©phane Ducasse

> Guys, we should hack this together. > When is next sprint? :) Next friday? Stef

June 17, 2012

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

by StÃ©phane Ducasse

On Jun 17, 2012, at 4:05 PM, Sean P. DeNigris wrote: > > EstebanLM wrote >> >> Marcus proposal is good: map RPackage with MCPackage, tag the >> subcategories (RPackage allow adding attributes). >> > I'm not sure I completely understand... So MCPackages will become RPackages, Not really better RingPckage. Ideally we should be able to use ring instead of MCdefinitions. MCPackage are just code model of package > and subcategories will become RPackages tagged to indicate they belong to a > parent package? > > > EstebanLM wrote >> >> with time packages will adapt >> > Adapt how? > > -- > View this message in context: http://forum.world.st/PackageOrganizer-packages-vs-categories-tp4635069p463… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 17, 2012

[Pharo-project] [update 2.0] #20140

by StÃ©phane Ducasse

20140 ----- - Issue 6077: Let DataStream only for Monticello Part2. Thanks Mariano Martinez-Peck. http://code.google.com/p/pharo/issues/detail?id=6077

June 17, 2012