December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About (backwards) Compatibility

by StÃ©phane Ducasse

Sean Just asking that question means that hannes does not need it :) One day I spent 20 min to rename all the file in one directory and got madâ¦. (so I'm probably too dull to understand files) Users of files see the real difference. Stef On Dec 16, 2012, at 12:42 AM, Sean P. DeNigris wrote: > H. Hirzel wrote >> As Chris points out, the difference is minimal. >> >> Sean, it looks like you need better examples to show how you perceive >> the benefits of the FileSystem design > > While you ignored the point of my followup post, which is that beauty and > simplicity lead to more than the sum of a few keywords, here are a few basic > examples... > > Example #1: > file := FileDirectory directoryEntryFor: '/path/to/file'. > FileDirectory extensionFor: file name. > > vs. > > file2 := '/path/to/file' asFileReference. > file2 extension. > > #2: > (FileDirectory on: 'path') entryAt: 'nohup.out'. > vs. > 'path' asFileReference / 'filename' > > "Most operations routed through one massive FD class" vs. "immediate access > to the domain object you want"; not to mention the appreciated absence of > parens. > > No difference?? > > > > -- > View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659396.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by Nicolas Cellier

2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > polymorphically they are a collection with a first and last :) > No. (5 to: 4) is different than (3 to: 2) because they specify a different cursor position. Viewed as collection, they have no first nor last, they're just empty Nicolas > On Dec 15, 2012, at 5:30 PM, Igor Stasenko wrote: > >> hi, >> >> i am alone with this problem (or just mentally ill?), why every time i >> use #start and #end protocol for Interval, e.g.: >> >> start := (1 to: 100) start. >> end := (1 to: 100) end. >> >> why i expecting that something called 'interval' should answer its >> start and end (or begin & end, if you like)? >> >> and i always hitting the wall with my head again and again.. because >> there's no such protocol >> and instead (after opening browser and looking at class, i figuring >> that i should use #first/#last, but it is completely unintuitive to >> me).. >> >> So, i am alone with this? Or maybe intervals deserving to have start and end? >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Dec. 16, 2012

Re: [Pharo-project] About (backwards) Compatibility

by StÃ©phane Ducasse

+ 10000000000 > Let me explain this once again: we are not "backward compatibility killer maniacs" :) > We prefer to keep backward compatibility whenever is possible, but we don't put it as a top priority: if we find room to improve, we do it. > > but, since we take responsibility for all the packages loaded in what we call "pharo", we rather prefer not to have duplicates, so we achieve one of our goal (cleanness) while also focussing out effort. > > I'm sorry if that annoys some of you time to time, but that's the way to improve: to change. > > Also... I think you are overreacting, in pharo 2.0 we just introduced three big changes (visible to users): FS, SystemAnnouncer (who has, btw, same API than old SystemChangeNotifier) and Nautilus... that's all. All the other is infrastructure and shouldn't be a problem for anyone. >

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by StÃ©phane Ducasse

polymorphically they are a collection with a first and last :) On Dec 15, 2012, at 5:30 PM, Igor Stasenko wrote: > hi, > > i am alone with this problem (or just mentally ill?), why every time i > use #start and #end protocol for Interval, e.g.: > > start := (1 to: 100) start. > end := (1 to: 100) end. > > why i expecting that something called 'interval' should answer its > start and end (or begin & end, if you like)? > > and i always hitting the wall with my head again and again.. because > there's no such protocol > and instead (after opening browser and looking at class, i figuring > that i should use #first/#last, but it is completely unintuitive to > me).. > > So, i am alone with this? Or maybe intervals deserving to have start and end? > > > > -- > Best regards, > Igor Stasenko. >

Dec. 16, 2012

Re: [Pharo-project] KeyChain/UsersManager

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=7130 >> Hi, >> >> what is the reason for integration of KeyChain/UsersManager to the image? It >> created the next kernel dependency. Should it replace Author? Should it be >> in the Pharo Kernel? And why there was no mention about it in this mailing >> list before? ;-) >> > > Yes, i also would like to hear arguments why we need it. > > >> Cheers, >> --

Dec. 16, 2012

Re: [Pharo-project] KeyChain/UsersManager

by StÃ©phane Ducasse

Probably we should have a nice configurationOf, fix the dependencies, and do not integrate it 2.0 Stef >> what is the reason for integration of KeyChain/UsersManager to the image? It >> created the next kernel dependency. Should it replace Author? Should it be >> in the Pharo Kernel? And why there was no mention about it in this mailing >> list before? ;-) >> > > Yes, i also would like to hear arguments why we need it. > > >> Cheers, >> -- Pavel > > > > -- > Best regards, > Igor Stasenko. >

Dec. 16, 2012

Re: [Pharo-project] File out of *extension -> debugger -> bug?

by StÃ©phane Ducasse

max can you add a bug entry for 2.0 so that we do not forget to fix it. Thx Stef On Dec 15, 2012, at 10:14 AM, Max Leske wrote: > Hi Sabine. > > Verified, that's a bug in 1.3. > > In 2.0 the OBSystemBrowserAdaptor isn't loaded by default (I doubt that anyone got it running (?)) and the default browser is Nautilus. So you don't actually have that option in 2.0. > > Nautillus shows extensions in separate extension categories. These can be filed out but the file will be empty (not tested in the latest build). > Anyone aware of this problem? > > Cheers, > Max > > > On 15.12.2012, at 09:33, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > >> Hi, >> >> I assume, this is a bug in Pharo? >> I select "browse package" in the System browser and then "file out" for the >> category "*Extensions". >> Other categories work. Occurs also in "*Extensions" of other packages. >> >> Is it fixed in Pharo 2.0? >> >> Greetings >> Sabine >> >> 15 December 2012 9:31:37 am >> >> VM: Win32 - IX86 - 6.1 - Croquet Closure Cog VM [CoInterpreter >> VMMaker.oscog-eem.140] >> Image: Pharo1.3 [Latest update: #13327] >> >> RBPackageEnvironment(Object)>>doesNotUnderstand: #organization >> Receiver: RKA24 >> Arguments and temporary variables: >> aMessage: organization >> exception: MessageNotUnderstood: RBPackageEnvironment>>organization >> resumeValue: nil >> Receiver's instance variables: >> label: 'RKA24' >> searchStrings: nil >> environment: Smalltalk >> packages: a Set(a PackageInfo(RKA24)) >> >> ORPackageExtensionNode(OBClassCategoryNode)>>fileOut >> Receiver: ORPackageExtensionNode<*Extensions> >> Arguments and temporary variables: >> >> Receiver's instance variables: >> metaNode: ExtensionCategory >> #classes->Class >> #comments->ClassComment >> #metaclasse...etc... >> environment: RKA24 >> name: #'*Extensions' >> >> OBCmdFileOut>>execute >> Receiver: an OBCmdFileOut >> Arguments and temporary variables: >> >> Receiver's instance variables: >> target: ORPackageExtensionNode<*Extensions> >> requestor: an OBColumn(*Extensions) >> >> OBCmdFileOut(OBCommand)>>perform:orSendTo: >> Receiver: an OBCmdFileOut >> Arguments and temporary variables: >> aSelector: #execute >> anObject: an OBPluggableListMorph(35651584) >> Receiver's instance variables: >> target: ORPackageExtensionNode<*Extensions> >> requestor: an OBColumn(*Extensions) >> >> [| selArgCount | >> (selArgCount := selector numArgs) = 0 >> ifTrue: [target perform: selector] >> ifFalse: [selArgCount = arguments size >> ifTrue: [target perform: selector withArguments: arguments] >> ifFalse: [target >> perform: selector >> withArguments: (arguments copyWith: evt)]]. >> self changed] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: >> Receiver: a ToggleMenuItemMorph(634388480)'File out' >> Arguments and temporary variables: >> evt: [904@314 mouseUp 195226000 nil] >> selArgCount: 2 >> Receiver's instance variables: >> bounds: 768@307 corner: 964@321 >> owner: a MenuMorph(664535040) >> submorphs: #() >> fullBounds: 768@307 corner: 964@321 >> color: Color black >> extension: a MorphExtension (637009920) >> font: a StrikeFont(Bitmap DejaVu Sans 9 14) >> emphasis: 0 >> contents: 'File out' >> hasFocus: false >> isEnabled: true >> subMenu: nil >> isSelected: false >> target: an OBCmdFileOut >> selector: #perform:orSendTo: >> arguments: an Array(#execute an OBPluggableListMorph(35651584)) >> icon: Form(16x1x8) >> getStateSelector: nil >> enablementSelector: nil >> keyText: 'cmd+o' >> >> >> >> >> -- >> View this message in context: http://forum.world.st/File-out-of-extension-debugger-bug-tp4659339.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

Dec. 16, 2012

Re: [Pharo-project] About (backwards) Compatibility

by dimitris chloupis

Thats a very good quote, and you are absolutely correct . No choice is ideal until it has been taken , materialized and proven itself. But if it does its time is limited until its replaced hopefully by a better idea. None knows before hand what the correct path really is. And as I mentioned already there are cases that braking backward compatibility makes perfect sense in some cases that is desperately needed. And unlike what Stephan said , I am definitely not here to whine. I am here to make sure Pharo is right choice for me. I talked and discussed backward compatibility because I want to know the intentions of Pharo developers. I want to know where Pharo is aiming to go and where it really goes. And finding the right choice is definitely a time consuming always on going travel. I am also aware of Pharo wanting more coding hands to make it better , but then which project does not ? There are times to code and times to discuss or sit back and think where you going , both are very important. Good designs never stay inside museums , they stand the test of time, they become the building blocks of the future.Â I am also excited so see people and teams use languages like smalltalk professionally and not choose other "safe options" or "popular options". It certainly makes me smile a bit more. ________________________________ From: Esteban A. Maringolo <emaringolo(a)gmail.com> To: pharo-project(a)lists.gforge.inria.fr Sent: Sunday, 16 December 2012, 6:44 Subject: Re: [Pharo-project] About (backwards) Compatibility I agree with what most people have said, from "both" sides. Most of the Smalltalkers I know that are making a living out of it are small teams, if not single developer companies (letting aside the fact my company have more than a dozen of smalltalkers). The transition path should be done as painless as possible for the current users of Pharo, given the restricted manpower such teams have. On the other hand going from 1.4 to 2.0 is a major release, and it has its tradeoffs, so to have the improvements you have to sacrifice some things, the Pharo team COULD make everything backward compatible, but it has a limited manpower too. There is certainly a PR issue here, as an outsider to the Pharo community (but watching it close since some time) I've been seeing an increment of "harsh" responses to those requesting features or "wishes" for the project (without considering the fact that some might have good or bad intentions). My POV on this is that Pharo, by means of its "board/committee/team", have a strong decision on where to take the future of it, it will accept improvements and contributions, but in the end they're going to be the curators of the final product, like a vendor would do it. And I think that's a good thing, projects need a "benevolent dictator". It's a matter of time to see the results of the path taken. "If Henry Ford had asked his customers, they would have told him they want a faster horse...'' I certainly do not want a faster horse. Regards, -- Esteban M. -- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659411.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by Nicolas Cellier

What Frank means is that Smalltalk Interval are countable (and most are finite). However, the original usage of Interval was for Text editing, and an Interval from 5 to: 4 means that the cursor is before (after?) position 5. That's why Interval is a strange beast, not exactly polymorphic to an Array of Number. Those two views have introduced a number of unconsistencies in the library... Last thing, I don't recommend using Interval of Float, (1.5 to: 1.6 by: 0.01), rather use Integer or Fraction. You never know where the Float Interval really ends, it's progression is generally not constant, and to:do: used to behaved differently than do: Nicolas 2012/12/16 Igor Stasenko <siguctua(a)gmail.com>: > On 16 December 2012 09:26, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 16 December 2012 01:06, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 15 December 2012 23:45, Chris Muller <asqueaker(a)gmail.com> wrote: >>>>> and i always hitting the wall with my head again and again.. because >>>>> there's no such protocol >>>>> and instead (after opening browser and looking at class, i figuring >>>>> that i should use #first/#last, but it is completely unintuitive to >>>>> me).. >>>> >>>> Me too, when I was using what I knew would only ever need to be, >>>> simply, an Interval. >>>> >>>> Later the complexity increased and it would be either a Interval or >>>> Array of numbers. It was a transparent / painless improvement. After >>>> gaining that appreciation, now I think of Intervals as just "efficient >>>> Arrays" and think naturally to use #first / #last. >>>> >>> >>> Well, my math background prevents me from thinking this way. >>> Since in math, intervals are defined on sets of numbers. >>> (like Real set).. you cannot treat it as array , simply because there >>> is an infinite number >>> of values inside any non-empty interval, and you cannot enumerate them. >> >> But it's a subset of the integers, not the reals! >> > what? > then how you explain this: > > (1.5 to: 1.6 by: 0.01) collect: [:i | i ] > >> frank >> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > > > > -- > Best regards, > Igor Stasenko. >

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by Igor Stasenko

On 16 December 2012 09:26, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 16 December 2012 01:06, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 15 December 2012 23:45, Chris Muller <asqueaker(a)gmail.com> wrote: >>>> and i always hitting the wall with my head again and again.. because >>>> there's no such protocol >>>> and instead (after opening browser and looking at class, i figuring >>>> that i should use #first/#last, but it is completely unintuitive to >>>> me).. >>> >>> Me too, when I was using what I knew would only ever need to be, >>> simply, an Interval. >>> >>> Later the complexity increased and it would be either a Interval or >>> Array of numbers. It was a transparent / painless improvement. After >>> gaining that appreciation, now I think of Intervals as just "efficient >>> Arrays" and think naturally to use #first / #last. >>> >> >> Well, my math background prevents me from thinking this way. >> Since in math, intervals are defined on sets of numbers. >> (like Real set).. you cannot treat it as array , simply because there >> is an infinite number >> of values inside any non-empty interval, and you cannot enumerate them. > > But it's a subset of the integers, not the reals! > what? then how you explain this: (1.5 to: 1.6 by: 0.01) collect: [:i | i ] > frank > >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Dec. 16, 2012