- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Could someone resuscitate the Google Groups mirror?

by Geert Claes

Probable the best way forward would be to contact the Pharo Google Groups admin and take over the admin duties -- View this message in context: http://forum.world.st/Could-someone-resuscitate-the-Google-Groups-mirror-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by Frank Shearar

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! frank > -- > Best regards, > Igor Stasenko. >

Dec. 16, 2012

[Pharo-project] Could someone resuscitate the Google Groups mirror?

by adrians

Could I ask that whomever set up the Google Groups mirror of this list get it back to working order? That mirror was kicked of this list last February for excessive bounces and at this point is dead. For one, this neglect doesn't look good for people happening onto Pharo from Google Groups. Second, I actually like to read my subscribed lists from as few different places as possible and while I like the Nabble front end, I have the vast majority of the many lists I follow on Google Groups and it would be nice to have this one under that umbrella, too. Fourth, having as many places from which people can interact with the Pharo community is a good thing, more exposure should be welcomed. If whomever set up the current group ( https://groups.google.com/forum/?pli=1#!forum/pharo <https://groups.google.com/forum/?pli=1#!forum/pharo> ) doesn't want to bother, could you at least kill it so I could set up a mirror myself? If on the other hand there is someone on the Pharo admin side who looks after this (but just forgot to do the maintenance here) could you please reset things so that messages are flowing again? While you're at it, could I ask that a Google Group be set up to mirror pharo-users as well? As I said, I could set up another mirror of this list myself, but it doesn't make sense to have two same name groups there. Much appreciated, Adrian -- View this message in context: http://forum.world.st/Could-someone-resuscitate-the-Google-Groups-mirror-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 16, 2012