- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 15 December 2012 12:31, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > Dne 15. 12. 2012 12:12, piÅ¡e Igor Stasenko: >> On 15 December 2012 10:27, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > >>> Is there any technical reason that the old FileDirectory stuff doesn't >>> stay and work in parallel to a new FileSystem? Maybe in some package >>> marked obsolete. Both use the same plugin and the same primitives, so >>> where is the problem? > >> Yes, there's one big reason: maintainability. And manpower. >> Who would like to maintain FD? Any takers? > > Gain with a (in this case very small) bit of manpower to ease upgrade to > new FS by providing existing FD for a while outweighs the loss by not > doing that. As a professional organization providing a professional > product Pharo should think rather that way. > Hold on.. Since when Pharo project became professional product? How much money you and others paying for using it? Yes, we position it as a product FOR professionals, but does it automatically makes a professional one? I don't think so. So, why you think that it is correct to put such requirements/expectations it? > Janko > -- Best regards, Igor Stasenko.

Dec. 15, 2012

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

by Esteban Lorenzano

Janko, that's already done (since ever), and FD is provided in two different ways: in the graveyard is the old FD package (loadable into pharo 2.0) http://smalltalkhub.com/#!/~Pharo/Graveyard20 , and also Camillo made a FD wrapper to FS... Esteban On Dec 15, 2012, at 12:31 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > Dne 15. 12. 2012 12:12, piÅ¡e Igor Stasenko: >> On 15 December 2012 10:27, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > >>> Is there any technical reason that the old FileDirectory stuff doesn't >>> stay and work in parallel to a new FileSystem? Maybe in some package >>> marked obsolete. Both use the same plugin and the same primitives, so >>> where is the problem? > >> Yes, there's one big reason: maintainability. And manpower. >> Who would like to maintain FD? Any takers? > > Gain with a (in this case very small) bit of manpower to ease upgrade to > new FS by providing existing FD for a while outweighs the loss by not > doing that. As a professional organization providing a professional > product Pharo should think rather that way. > > Janko > >> >>> >>> I also think that for a professionally viable product a clear migration >>> path should be provided. Progress yes, but user base must have a >>> guidance how to slowly migrate to the new functionality. If possible >>> with some automated procedure to migrate our code. >>> >>> In case of FileSystem/FileDirectory, this is certainly quite a big >>> change and will break a lot of code. Be sure therefore that you guide us >>> as much as possible, otherwise there is a danger to loose a lot of user >>> base behind. >>> >> But there is a well-written documentation of FS. >> I wonder, if there's any documentation for FileDirectory ever existed. >> >>> Best regards >>> Janko >>> >>> Dne 15. 12. 2012 08:55, piÅ¡e StÃ©phane Ducasse: >>>> Chris >>>> >>>> Could you give us a break pleaseeeeeee? >>>> We are spending all our energy to build a better system that other people can use to make a living. >>>> May be we should just create a system for having fun in our teams? Because at the end of the day >>>> we just need to produce ideas and some prototypes (not even build them as researchers). >>>> >>>> I really think that there are still plenty of places where the system is not good. If you disagree then you may want to >>>> spend more time trying to extend it and build something real with it. (Here this is the place where you should react and prove >>>> to the world that you are a cool entrepreneur) ;D >>>> >>>> Now nobody force you to: >>>> - be in this mailing-list (you are welcome here but can we avoid this kind of endless useless discussions) or >>>> phrase your points with code snippet that can help the system. >>>> >>>> - use pharo in fact you are not using it so you are living in an happy world. So this is perfect. >>>> >>>> Did you read the Pharo motto? >>>> >>>> Stef >>>> >>>> >>>> On Dec 14, 2012, at 5:55 PM, Chris Muller wrote: >>>> >>>>> I'm tired of talking about this but I just can't let this go.. I >>>>> don't know if its just romantic, starry-eyed mountain climbers or >>>>> intentional false-propaganda but... confusion reigns here! :) This >>>>> example is bunk. >>>>> >>>>> Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 >>>>> which, for whatever reason, is admittedly not great code but that's >>>>> not the point -- Sean is trying to use this example to demonstrate how >>>>> using FileSystem will let you "scale new heights" over FileDirectory. >>>>> The real equivalent to what Sean wrote is: >>>>> >>>>> "FileDirectory" >>>>> localFileName: aString >>>>> | file | >>>>> super localFileName: aString. >>>>> file := FileDirectory directoryEntryFor: aString. >>>>> file exists ifFalse: [ ^ self ]. >>>>> self modifiedAt: file entry modificationTime. >>>>> >>>>> "FileSystem" >>>>> localFileName: aString >>>>> | file | >>>>> super localFileName: aString. >>>>> file := aString asFileName. >>>>> file exists ifFalse: [ ^ self ]. >>>>> self modifiedAt: file entry modificationTime. >>>>> >>>>> Ahhhh, I've broken all my systems but look how I'm scaling new heights >>>>> with FileSystem! (not!) >>>>> >>>>> >>>>> >>>>> On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris >>>>> <sean(a)clipperadams.com> wrote: >>>>>> Chris Muller-4 wrote >>>>>>> While someone in the Pharo >>>>>>> community said FileSystem over FileDirectory is "huge", I see it as an >>>>>>> incremental API change >>>>>> >>>>>> Can you still say that after reading >>>>>> http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?! >>>>>> >>>>>> FileSystem has hugely decremented the number of times I've wanted to throw >>>>>> my computer at a wall ;) FileDirectory occurred to me like graffiti painted >>>>>> on a great work of art. >>>>>> >>>>>> Multiply the above by every dark corner of the system and you have the >>>>>> barrier to the next stage of evolution. For myself, every time I've embarked >>>>>> on a bold new idea for our IDE, after getting bogged down in a mess of >>>>>> objects - like FileDirectory et al, or Paragraph and friends, or Morphic >>>>>> layout objects, and on and on - I reached a point where I was not willing to >>>>>> put in the tremendous effort required to understand the system (if even >>>>>> possible). And because few of the design decisions are documented, I didn't >>>>>> know how to clean things without breaking them. So, I gave up and just went >>>>>> back to the standard tools. >>>>>> >>>>>> I hate to keep repeating myself, but the Pharo manifesto is very clear, and >>>>>> makes these types of arguments moot: >>>>>> - Better for the better >>>>>> - Beauty to learn from >>>>>> - Not backward compatible >>>>>> - Clean, lean and fast >>>>>> >>>>>> Cheers, >>>>>> Sean >>> >>> -- >>> Janko MivÅ¡ek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >> >> >> > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

Dec. 15, 2012

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

by Janko MivÅ¡ek

Dne 15. 12. 2012 12:12, piÅ¡e Igor Stasenko: > On 15 December 2012 10:27, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: >> Is there any technical reason that the old FileDirectory stuff doesn't >> stay and work in parallel to a new FileSystem? Maybe in some package >> marked obsolete. Both use the same plugin and the same primitives, so >> where is the problem? > Yes, there's one big reason: maintainability. And manpower. > Who would like to maintain FD? Any takers? Gain with a (in this case very small) bit of manpower to ease upgrade to new FS by providing existing FD for a while outweighs the loss by not doing that. As a professional organization providing a professional product Pharo should think rather that way. Janko > >> >> I also think that for a professionally viable product a clear migration >> path should be provided. Progress yes, but user base must have a >> guidance how to slowly migrate to the new functionality. If possible >> with some automated procedure to migrate our code. >> >> In case of FileSystem/FileDirectory, this is certainly quite a big >> change and will break a lot of code. Be sure therefore that you guide us >> as much as possible, otherwise there is a danger to loose a lot of user >> base behind. >> > But there is a well-written documentation of FS. > I wonder, if there's any documentation for FileDirectory ever existed. > >> Best regards >> Janko >> >> Dne 15. 12. 2012 08:55, piÅ¡e StÃ©phane Ducasse: >>> Chris >>> >>> Could you give us a break pleaseeeeeee? >>> We are spending all our energy to build a better system that other people can use to make a living. >>> May be we should just create a system for having fun in our teams? Because at the end of the day >>> we just need to produce ideas and some prototypes (not even build them as researchers). >>> >>> I really think that there are still plenty of places where the system is not good. If you disagree then you may want to >>> spend more time trying to extend it and build something real with it. (Here this is the place where you should react and prove >>> to the world that you are a cool entrepreneur) ;D >>> >>> Now nobody force you to: >>> - be in this mailing-list (you are welcome here but can we avoid this kind of endless useless discussions) or >>> phrase your points with code snippet that can help the system. >>> >>> - use pharo in fact you are not using it so you are living in an happy world. So this is perfect. >>> >>> Did you read the Pharo motto? >>> >>> Stef >>> >>> >>> On Dec 14, 2012, at 5:55 PM, Chris Muller wrote: >>> >>>> I'm tired of talking about this but I just can't let this go.. I >>>> don't know if its just romantic, starry-eyed mountain climbers or >>>> intentional false-propaganda but... confusion reigns here! :) This >>>> example is bunk. >>>> >>>> Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 >>>> which, for whatever reason, is admittedly not great code but that's >>>> not the point -- Sean is trying to use this example to demonstrate how >>>> using FileSystem will let you "scale new heights" over FileDirectory. >>>> The real equivalent to what Sean wrote is: >>>> >>>> "FileDirectory" >>>> localFileName: aString >>>> | file | >>>> super localFileName: aString. >>>> file := FileDirectory directoryEntryFor: aString. >>>> file exists ifFalse: [ ^ self ]. >>>> self modifiedAt: file entry modificationTime. >>>> >>>> "FileSystem" >>>> localFileName: aString >>>> | file | >>>> super localFileName: aString. >>>> file := aString asFileName. >>>> file exists ifFalse: [ ^ self ]. >>>> self modifiedAt: file entry modificationTime. >>>> >>>> Ahhhh, I've broken all my systems but look how I'm scaling new heights >>>> with FileSystem! (not!) >>>> >>>> >>>> >>>> On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris >>>> <sean(a)clipperadams.com> wrote: >>>>> Chris Muller-4 wrote >>>>>> While someone in the Pharo >>>>>> community said FileSystem over FileDirectory is "huge", I see it as an >>>>>> incremental API change >>>>> >>>>> Can you still say that after reading >>>>> http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?! >>>>> >>>>> FileSystem has hugely decremented the number of times I've wanted to throw >>>>> my computer at a wall ;) FileDirectory occurred to me like graffiti painted >>>>> on a great work of art. >>>>> >>>>> Multiply the above by every dark corner of the system and you have the >>>>> barrier to the next stage of evolution. For myself, every time I've embarked >>>>> on a bold new idea for our IDE, after getting bogged down in a mess of >>>>> objects - like FileDirectory et al, or Paragraph and friends, or Morphic >>>>> layout objects, and on and on - I reached a point where I was not willing to >>>>> put in the tremendous effort required to understand the system (if even >>>>> possible). And because few of the design decisions are documented, I didn't >>>>> know how to clean things without breaking them. So, I gave up and just went >>>>> back to the standard tools. >>>>> >>>>> I hate to keep repeating myself, but the Pharo manifesto is very clear, and >>>>> makes these types of arguments moot: >>>>> - Better for the better >>>>> - Beauty to learn from >>>>> - Not backward compatible >>>>> - Clean, lean and fast >>>>> >>>>> Cheers, >>>>> Sean >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> > > > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Dec. 15, 2012

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

by Igor Stasenko

On 15 December 2012 10:27, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > Hi guys, > > Is there any technical reason that the old FileDirectory stuff doesn't > stay and work in parallel to a new FileSystem? Maybe in some package > marked obsolete. Both use the same plugin and the same primitives, so > where is the problem? Yes, there's one big reason: maintainability. And manpower. Who would like to maintain FD? Any takers? > > I also think that for a professionally viable product a clear migration > path should be provided. Progress yes, but user base must have a > guidance how to slowly migrate to the new functionality. If possible > with some automated procedure to migrate our code. > > In case of FileSystem/FileDirectory, this is certainly quite a big > change and will break a lot of code. Be sure therefore that you guide us > as much as possible, otherwise there is a danger to loose a lot of user > base behind. > But there is a well-written documentation of FS. I wonder, if there's any documentation for FileDirectory ever existed. > Best regards > Janko > > Dne 15. 12. 2012 08:55, piÅ¡e StÃ©phane Ducasse: >> Chris >> >> Could you give us a break pleaseeeeeee? >> We are spending all our energy to build a better system that other people can use to make a living. >> May be we should just create a system for having fun in our teams? Because at the end of the day >> we just need to produce ideas and some prototypes (not even build them as researchers). >> >> I really think that there are still plenty of places where the system is not good. If you disagree then you may want to >> spend more time trying to extend it and build something real with it. (Here this is the place where you should react and prove >> to the world that you are a cool entrepreneur) ;D >> >> Now nobody force you to: >> - be in this mailing-list (you are welcome here but can we avoid this kind of endless useless discussions) or >> phrase your points with code snippet that can help the system. >> >> - use pharo in fact you are not using it so you are living in an happy world. So this is perfect. >> >> Did you read the Pharo motto? >> >> Stef >> >> >> On Dec 14, 2012, at 5:55 PM, Chris Muller wrote: >> >>> I'm tired of talking about this but I just can't let this go.. I >>> don't know if its just romantic, starry-eyed mountain climbers or >>> intentional false-propaganda but... confusion reigns here! :) This >>> example is bunk. >>> >>> Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 >>> which, for whatever reason, is admittedly not great code but that's >>> not the point -- Sean is trying to use this example to demonstrate how >>> using FileSystem will let you "scale new heights" over FileDirectory. >>> The real equivalent to what Sean wrote is: >>> >>> "FileDirectory" >>> localFileName: aString >>> | file | >>> super localFileName: aString. >>> file := FileDirectory directoryEntryFor: aString. >>> file exists ifFalse: [ ^ self ]. >>> self modifiedAt: file entry modificationTime. >>> >>> "FileSystem" >>> localFileName: aString >>> | file | >>> super localFileName: aString. >>> file := aString asFileName. >>> file exists ifFalse: [ ^ self ]. >>> self modifiedAt: file entry modificationTime. >>> >>> Ahhhh, I've broken all my systems but look how I'm scaling new heights >>> with FileSystem! (not!) >>> >>> >>> >>> On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris >>> <sean(a)clipperadams.com> wrote: >>>> Chris Muller-4 wrote >>>>> While someone in the Pharo >>>>> community said FileSystem over FileDirectory is "huge", I see it as an >>>>> incremental API change >>>> >>>> Can you still say that after reading >>>> http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?! >>>> >>>> FileSystem has hugely decremented the number of times I've wanted to throw >>>> my computer at a wall ;) FileDirectory occurred to me like graffiti painted >>>> on a great work of art. >>>> >>>> Multiply the above by every dark corner of the system and you have the >>>> barrier to the next stage of evolution. For myself, every time I've embarked >>>> on a bold new idea for our IDE, after getting bogged down in a mess of >>>> objects - like FileDirectory et al, or Paragraph and friends, or Morphic >>>> layout objects, and on and on - I reached a point where I was not willing to >>>> put in the tremendous effort required to understand the system (if even >>>> possible). And because few of the design decisions are documented, I didn't >>>> know how to clean things without breaking them. So, I gave up and just went >>>> back to the standard tools. >>>> >>>> I hate to keep repeating myself, but the Pharo manifesto is very clear, and >>>> makes these types of arguments moot: >>>> - Better for the better >>>> - Beauty to learn from >>>> - Not backward compatible >>>> - Clean, lean and fast >>>> >>>> Cheers, >>>> Sean > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > -- Best regards, Igor Stasenko.

Dec. 15, 2012

Re: [Pharo-project] Favorite New Features

by Marcus Denker

On Dec 14, 2012, at 5:32 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Hey guys, what are your favorite features added in 2.0? Please answer at > http://code.google.com/p/pharo/wiki/ActionsInPharo20 > > There are so many improvements, I've definitely lost track. I remember there > were some really useful shortcuts cami or ben showed me, something like > cmd-click to browse class... I will have a lookâ¦ if everything fails over christmas holidays. Marcus

Dec. 15, 2012

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

by Janko MivÅ¡ek

Hi guys, Is there any technical reason that the old FileDirectory stuff doesn't stay and work in parallel to a new FileSystem? Maybe in some package marked obsolete. Both use the same plugin and the same primitives, so where is the problem? I also think that for a professionally viable product a clear migration path should be provided. Progress yes, but user base must have a guidance how to slowly migrate to the new functionality. If possible with some automated procedure to migrate our code. In case of FileSystem/FileDirectory, this is certainly quite a big change and will break a lot of code. Be sure therefore that you guide us as much as possible, otherwise there is a danger to loose a lot of user base behind. Best regards Janko Dne 15. 12. 2012 08:55, piÅ¡e StÃ©phane Ducasse: > Chris > > Could you give us a break pleaseeeeeee? > We are spending all our energy to build a better system that other people can use to make a living. > May be we should just create a system for having fun in our teams? Because at the end of the day > we just need to produce ideas and some prototypes (not even build them as researchers). > > I really think that there are still plenty of places where the system is not good. If you disagree then you may want to > spend more time trying to extend it and build something real with it. (Here this is the place where you should react and prove > to the world that you are a cool entrepreneur) ;D > > Now nobody force you to: > - be in this mailing-list (you are welcome here but can we avoid this kind of endless useless discussions) or > phrase your points with code snippet that can help the system. > > - use pharo in fact you are not using it so you are living in an happy world. So this is perfect. > > Did you read the Pharo motto? > > Stef > > > On Dec 14, 2012, at 5:55 PM, Chris Muller wrote: > >> I'm tired of talking about this but I just can't let this go.. I >> don't know if its just romantic, starry-eyed mountain climbers or >> intentional false-propaganda but... confusion reigns here! :) This >> example is bunk. >> >> Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 >> which, for whatever reason, is admittedly not great code but that's >> not the point -- Sean is trying to use this example to demonstrate how >> using FileSystem will let you "scale new heights" over FileDirectory. >> The real equivalent to what Sean wrote is: >> >> "FileDirectory" >> localFileName: aString >> | file | >> super localFileName: aString. >> file := FileDirectory directoryEntryFor: aString. >> file exists ifFalse: [ ^ self ]. >> self modifiedAt: file entry modificationTime. >> >> "FileSystem" >> localFileName: aString >> | file | >> super localFileName: aString. >> file := aString asFileName. >> file exists ifFalse: [ ^ self ]. >> self modifiedAt: file entry modificationTime. >> >> Ahhhh, I've broken all my systems but look how I'm scaling new heights >> with FileSystem! (not!) >> >> >> >> On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris >> <sean(a)clipperadams.com> wrote: >>> Chris Muller-4 wrote >>>> While someone in the Pharo >>>> community said FileSystem over FileDirectory is "huge", I see it as an >>>> incremental API change >>> >>> Can you still say that after reading >>> http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?! >>> >>> FileSystem has hugely decremented the number of times I've wanted to throw >>> my computer at a wall ;) FileDirectory occurred to me like graffiti painted >>> on a great work of art. >>> >>> Multiply the above by every dark corner of the system and you have the >>> barrier to the next stage of evolution. For myself, every time I've embarked >>> on a bold new idea for our IDE, after getting bogged down in a mess of >>> objects - like FileDirectory et al, or Paragraph and friends, or Morphic >>> layout objects, and on and on - I reached a point where I was not willing to >>> put in the tremendous effort required to understand the system (if even >>> possible). And because few of the design decisions are documented, I didn't >>> know how to clean things without breaking them. So, I gave up and just went >>> back to the standard tools. >>> >>> I hate to keep repeating myself, but the Pharo manifesto is very clear, and >>> makes these types of arguments moot: >>> - Better for the better >>> - Beauty to learn from >>> - Not backward compatible >>> - Clean, lean and fast >>> >>> Cheers, >>> Sean -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Dec. 15, 2012

Re: [Pharo-project] Fwd: Lua scripting with nativeboost?

by Peter H. Meadows

Some of these games are fun: http://scratch.mit.edu/ On 15 December 2012 05:43, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 December 2012 21:26, Lawson English <lenglish5(a)cox.net> wrote: >> On 12/13/12 1:58 AM, Igor Stasenko wrote: >>> >>> On 13 December 2012 09:54, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >>>> >>>> I was ready to disagree , but you do make a valid point. >>>> >>>> Also going down the pharo route you dont offer games only a better >>>> language >>>> but also a development enviroment and that is a double win. I am suprised >>>> that pharo is not used heavily for games. >>>> >>>> And no I dont believe sandbox is the reason. Afterall python is very >>>> popular >>>> with games too and has no sandbox. >>> >>> indeed, its all about marketing and having 'killer app', and then you >>> wont notice how eagerly new >>> people will jump into bandwagon. >>> >>> >> >> until certain issues with garbage collection are fixed, there will be no >> playable realtime games on any of the OSS Smalltalks. >> > > and why you assuming that "killer game" should be realtime? > But even if that.. > i do not agree with you. > You can always write a heavy numeric crunching stuff in C, but > write game logic in smalltalk. > > Most of AAA games i seen, paying a lot of attention to crunching, and > little to logic.. > and then people like get bored after 10 minutes of play. > Because running twice as fast don't converts into "playing twice as fun". > >> L > > -- > Best regards, > Igor Stasenko. >

Dec. 15, 2012

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

by Max Leske

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. 15, 2012

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

by Sabine KnÃ¶fel

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. 15, 2012

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

by StÃ©phane Ducasse

Guys could you help us producing a better system instead of winning? We ported pier to pharo 2.0 and it was fixed in less than one afternoon. Do you want more examples? Breaking compatibility is NOT central to pharo. But we do it when we have to. Pharo is not a Smalltalk in a museum!!!! Stef On Dec 15, 2012, at 9:05 AM, dimitris chloupis wrote: > I did not want to take this discussion further , because I dont like to annoy people . > But some of the points made here are presented as facts and I don't like that. > > > Chris, in discussions about "compatibility" , people always missing to > > mention one little thing: > > users can always choose to not upgrade their projects and keep using > > older releases. > > I will mention another thing. Freedom is an illusion. In the end you are always bound by limitations and your own personal needs. > Especially that nasty little thing that is called "dependecies". When a library depends on an another , not upgrading can be not even > option. This is why I separate braking compatibility in the language side and braking compatibility in the library side. > I am perfectly ok with libraries that brake compatibility , why ? Because you can ignore a library and just move to something that fit > your needs better. But with language is a lot more difficult to do that usually because the libraries that you are going to use are going to > depend on a specific language version. > > > Now, don't you think that it would be strange if new release of system > > will function exactly as old one, so users can run their project(s) > > without changing even single line of code? > > This is possible only if new system(s) should be same thing but with > > extra functionality. > > No I don't find it strange , actually its not even rare, its common practice for most libraries > out there not to brake backward compatibility. > > > And that will mean that development model would be "never change > > anything, but add things on top".. > > Nope thats simple is not true, you are allowed to change everything except the name of the methods and classes. Which is a small part of the code. > And you are also allowed to add as much new stuff as you want as long as its optional. This means that there is nothing stopping a backward compatible > library new version to be better than a non backward compatible library new version. > > > The software has to evolve, and evolution means changes. And so, if > > you wanna benefit from system improvements, you'll have to make your > > hands dirty and do some changes in your code to fit with new system. > > This is a price you pay for having better system. And there's no > > escape from that. > > I don't know why you believe that backward compatible means no progress and non backward compatible means progress. > This is simply not true from my experience. I have used a lot of backward compatible libraries and they keep getting > better and better. The only piece of software that I used that has gone through the biggest rewrite ever, is blender and I have to > admit that the rewrite greatly benefit blender. But blender had a lot of issues and it was clear that much of its basic functionality was > deeply flawed and desperately needed a refresh in design. Thats not always the case with software. > > Some designs have stood the test of time so braking compatibility makes no sense. If you want to keep improving that specific library > you can keep doing it. > > I can give you an example if you want, VCL , it's Delphi's own library. We talking here about a massive library nothing like smalltalk libraries. > Has been backward compatible since 1996 that I have first used Delphi and > its still is probably the best library I have used together with the other Delphi libraries. The guy behind Delphi knew exactly what a good design is and > knew how to make real R.A.D tools which is pretty much the goal of smalltalk itself. The result was that his designs were so successful and liked that he was > snatched from Mircrosoft to create .NET and C#. > Suffice to say .NET clone most of the designs of Delphi. > But even till this day Delphi is highly popular (not as popular as it was in the past) and highly regarded piece of > software. > > But as I said , I am not against braking backward compatibility , in many cases its the best thing to do. But if braking > backward compatibility is always your first option then I fear you are going to have the exact same problems blender has > with addons developers. And certainly users wont love you, I can guarantee you that not in the short run or the long run. > > Another thing I must state here , is that as a user did not choose pharo over squeak because it brakes compatibility. > I am saying that because I fear I am not the only one to have done so. Because its a dangerous conclusion for one to make > that just because someone prefers pharo to squeak because for him it has been more stable and because more libraries are actively > developed for it, that is implied he is a big fan of braking compatibility. > > I also respect the fact that you as developers decided to make "braking compatibility" as a central value of pharo. > Its your project you have the right to do whatever you want with it. And I am not even saying its a wrong choice. > I only hope for me and others that I dont end up hitting my head against the wall as I have done with the blender api. > I can bare a bad design and even get used to it, but something that brakes my code in every single version is simply.... > > a pain in the a@@ > > And staying with old versions is not a viable solution for me. I will probably end up choosing squeak > or whatever can make my life happy and fun again. > > On 14 December 2012 23:42, Chris Muller <ma.chris.m(a)gmail.com> wrote: > >> - the consensus is that FileSystem is a nice API > >> - the consensus is that FileDirectory is/was ugly > > > > Hence, you echo my original statement from the other thread. I wrote: > > > >>> ... While someone in the Pharo > >>> community said FileSystem over FileDirectory is "huge", I see it as an > >>> incremental API change, and close to being a matter of preference. > > > >> And you don't want to switch to it ? > >> Or you want to keep the old API and not force the switch on users ? > > > > Both. Because, while FileSystem is a cleaner design, the question > > posed was whether it is _worth_ breaking so many legacy packages and > > the promise of O.T. for "a nice API". That's when dramatic attempts > > to intensify the contrast between the two came out but with no > > concrete examples we arrived full-circle back to the original > > question. > > > > An acceptable compromise for me for putting it Squeak would be a > > FileDirectory wrapper that can pass its own test suite, which is > > precisely what Pharo did! > > > > > > -- > Best regards, > Igor Stasenko. > > >

Dec. 15, 2012