April 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-fuel] Binding semantics of SystemDictionary

by Guillermo Polito

Hmm, there is something that I'm missing: do you have a real case where fuel is failing? :) if so, I'd focus on that: where does it come from, how was that class created, maybe it's a very specific case that you can handle in an ad-hoc way (and then leave fuel as it is right now...) El vie., 10 de abr. de 2015 a la(s) 11:24 a. m., Max Leske < maxleske(a)gmail.com> escribiÃ³: > On 07 Apr 2015, at 13:30, vm-dev-request(a)lists.squeakfoundation.org wrote: > > Hmm, I think we are mixing stuff here ^^ > > Method Dictionaries and system dictionary accept any object as keys. > > To execute code, the VM only checks for identity (+ identity hash that does > not change) in method dictionaries. The VM never looks up in the system > dictionary. > Actually the VM does not make any assumption on the objects you put as > keys. This makes the VM simpler. > Then tools enforce that we put there symbols as keys in both. But, we could > put anything we would like. > > > Interesting. > > > So, answering your questions: > > 1. Are bindings with keys that are not ByteString or ByteSymbol valid? > > Theoretically yes, but nobody uses this for real for now. Camille has > some prototypes that uses this to enforce modularity. > > 2. Should we keep allowing ByteString as keys to globals (ByteSymbol > guarantees identity)? > > Well, usually the tools will make sure that you transform them to a > symbol before. > > 3. If we allow ByteString, do we also allow WideString? > > Any object ^^ > > 4. Would âtype checksâ on SystemDictionary incur a big performance penalty? > > Maybe, but not only that. It makes the code more messy also, and > hardcode tool assumptions. I don't put any type checks in any of my code > usually, why start there... We should fix fuel to not make that assumption > instead I think. > > > I agree. I donât like type checks. Just wanted to have talked about the > option. > > Thanks for your input Guille. Iâm still not sure how to solve this issue > for Fuel though. I see several options: > - signal an exception when the key to a global is not a symbol > - simply serialize a string representation of the key, which will lead to > a lookup failure on materialization - > not good > - serialize the identityHash of the key. The identity hash of a symbol is > stable across different images and VMs but not across Squeak and Pharo -> > not good > - serialize the actual key. This requires us to rewrite the global > handling logic and it will once again break backwards compatibility. This > might be something for the future. > > So maybe we should: > 1. signal an exception -> no change for users > 2. In a future version rewrite the global handling logic to allow for > arbitrary global keys. > > Opinions? > > Cheers, > Max > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >

April 10, 2015

Re: [Pharo-dev] Binding semantics of SystemDictionary

by Max Leske

> On 07 Apr 2015, at 13:30, vm-dev-request(a)lists.squeakfoundation.org wrote: > > Hmm, I think we are mixing stuff here ^^ > > Method Dictionaries and system dictionary accept any object as keys. > > To execute code, the VM only checks for identity (+ identity hash that does > not change) in method dictionaries. The VM never looks up in the system > dictionary. > Actually the VM does not make any assumption on the objects you put as > keys. This makes the VM simpler. > Then tools enforce that we put there symbols as keys in both. But, we could > put anything we would like. Interesting. > > So, answering your questions: > > 1. Are bindings with keys that are not ByteString or ByteSymbol valid? > > Theoretically yes, but nobody uses this for real for now. Camille has > some prototypes that uses this to enforce modularity. > > 2. Should we keep allowing ByteString as keys to globals (ByteSymbol > guarantees identity)? > > Well, usually the tools will make sure that you transform them to a > symbol before. > > 3. If we allow ByteString, do we also allow WideString? > > Any object ^^ > > 4. Would âtype checksâ on SystemDictionary incur a big performance penalty? > > Maybe, but not only that. It makes the code more messy also, and > hardcode tool assumptions. I don't put any type checks in any of my code > usually, why start there... We should fix fuel to not make that assumption > instead I think. I agree. I donât like type checks. Just wanted to have talked about the option. Thanks for your input Guille. Iâm still not sure how to solve this issue for Fuel though. I see several options: - signal an exception when the key to a global is not a symbol - simply serialize a string representation of the key, which will lead to a lookup failure on materialization - > not good - serialize the identityHash of the key. The identity hash of a symbol is stable across different images and VMs but not across Squeak and Pharo -> not good - serialize the actual key. This requires us to rewrite the global handling logic and it will once again break backwards compatibility. This might be something for the future. So maybe we should: 1. signal an exception -> no change for users 2. In a future version rewrite the global handling logic to allow for arbitrary global keys. Opinions? Cheers, Max

April 10, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40599 Home: https://github.com/pharo-project/pharo-core

April 10, 2015

[pharo-project/pharo-core] ea6cb4: 40599

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: ea6cb4930b8e733de7bdf9f41a686ee14f7efb41 https://github.com/pharo-project/pharo-core/commit/ea6cb4930b8e733de7bdf9f4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-10 (Fri, 10 Apr 2015) Changed paths: M Monticello.package/MCMethodDefinition.class/instance/comparing/=.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script598.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script599.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40598.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40599.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeTreeInspector.class/instance/api/childrenForObject_.st Log Message: ----------- 40599 15321 Monticello marks all methods of a package as new/changed https://pharo.fogbugz.com/f/cases/15321 15319 Basic Inspector: MNU when switching to tree https://pharo.fogbugz.com/f/cases/15319 http://files.pharo.org/image/40/40599.zip

April 10, 2015

Re: [Pharo-dev] Problem with asClass usage

by Denis Kudriashov

Hi 2015-04-08 13:32 GMT+03:00 stepharo <stepharo(a)free.fr>: > Hi > > We want to raise a strong warning against the extension of the use of > asClass and friends. > asClass should not be used in Pharo distribution. I will propose to > deprecate it. > > We are working on dependency analysis, module system, remote debugging and > asClass introduces > lose class references and many related problems. > > I would like to remove this behavior because it is clear that it will just > grow up and lead to deadcode and ugly dependencies. > > First, most of the time you can avoid to query Smalltalk globals at: and > that BY CONSTRUCTION a software system should be built and it should > define its own customization. > > > Second, at least use self class environment at: #foo > > Why is it much much much better? because it does not rely on String class > resolution and as such > is much more modular. You do not want to have the resolution of a symbol > related to the place where String is defined but on where your code is > actually. > To me it means that #asClass has wrong implementation and should be fixed like: String>>asClass thisContext sender class environment at: self Because users of code "'className' asClass" obviously want class from sender class environment.

April 10, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by Max Leske

For a little more context: the issue was originally raised by Clara in the thread titled "MNU: receiver of "stepToCallee:" is nilâ. IIRC the issue was easily reproducible when debugging a test, then closing the debugger (via the close icon). Clicking âProceedâ on the other hand gracefully terminated the process. Cheers, Max > On 10 Apr 2015, at 09:56, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2015-04-10 2:37 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: > I was using it frequently too and I have never experienced any issues... > > Ok, can you describe a use case, what test case you can start and > close the debugger without image freeze? > > Maybe we can find what is the difference between that > test case and those that freeze the image, and than find a fix. > > > 2015-04-09 14:58 GMT-07:00 Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>>: > > > 2015-04-09 23:38 GMT+02:00 phil(a)highoctane.be <mailto:phil@highoctane.be> <phil(a)highoctane.be <mailto:phil@highoctane.be>>: > No Debug Tests? > > Geez, I am using that all the time. > > And you're never encountered this issue 14689 <https://pharo.fogbugz.com/default.asp?14689>? > Or did this work in older versions? > > > > > Phil > > > On Thu, Apr 9, 2015 at 10:21 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > > > On 09 Apr 2015, at 22:32, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > > > > Nicolai Hess wrote > >> http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-… <http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-…> > > > > Ah, I miss that too! From that thread, it seems it was removed temporarily > > until we have real breakpoints. Is there an issue for its return? > > > > Not yet. > > Marcus > > > >

April 10, 2015

Re: [Pharo-dev] Problem with asClass usage

by Christophe Demarey

Le 10 avr. 2015 Ã 06:09, Ben Coman a Ã©crit : > I believe #asClass itself was introduced for a use case to simplify Workspace "user interactive" Gofer scripts to retrieve and load Configurations. Since this is through away code its not covered by your modularity concerns, and I'm not sure if it came before or after its friends, but can we retain or substitute something to avoid needing ugly "(Smalltalk at: #ConfigurationOfXXX) load" ? > > This is a "first impression" consideration for people dealing with Configurations for the first time (even thought we now have Configuration Browser). The use case is that newbies will copy-paste a script from a web site to Playground and execute the whole script resulting in a error "Unknown class ConfigurationOfXXX." They don't know to execute in two separate steps, first "Gofer ... load" then "ConfigurationOfXXX load". > > Alternatively, what if the Metacello package extended Gofer with a method #configurationOf: so websites can show... > > config := > Gofer new > url: 'http://smalltalkhub.com/mc/MyProject/main' > package: 'MyXXXPackage'; > load; > configurationOf: 'XXX' "return class ConfigurationOfXXX" > config load. > > ...so the compiler is dealing with a variable "config" rather than class 'ConfigurationOfXXX' that it doesn't know yet, or a further altenative... > > Gofer new > url: 'http://smalltalkhub.com/mc/MyProject/main' > package: 'MyXXXPackage'; > load; > configurationOf: 'XXX' do: [ :config | config load ]; > configurationOf: 'YYY' do: [ :config | config load ]. > > cheers -ben It is not a problem anymore. We have better ways to load a configuration and the associated packages: Metacello new configuration: 'XXX'; squeaksource3: 'MyProject'; version: '0.9.0'; load. Le 10 avr. 2015 Ã 08:57, phil(a)highoctane.be a Ã©crit : > For the GLM things, I guess it allows one to have code that works only if an extra module is loaded. > > We have asString and it is fine. Now asClass will not be. Duh? > > aThing perform: #someAction is as complicated. > > Yeah make a lint rule but do not disallow the usage. > The problem is that if you want to allow to browse remote code or to have 2 versions of the same class in the system for example, aSymbol asClass will not work. It will always search the class in the environment of the String class. The resolution of a symbol should be the responsibility of Environment. asString does not have the same problem. To me, #perform: is not a problem because the resolution of the selector is done by the class. I don't see a case where you do not want that. Christophe. > On 10/04/2015 4:32 am, "stepharo" <stepharo(a)free.fr> wrote: > Hi > > We want to raise a strong warning against the extension of the use of asClass and friends. > asClass should not be used in Pharo distribution. I will propose to deprecate it. > > We are working on dependency analysis, module system, remote debugging and asClass introduces > lose class references and many related problems. > > I would like to remove this behavior because it is clear that it will just grow up and lead to deadcode and ugly dependencies. > > First, most of the time you can avoid to query Smalltalk globals at: and that BY CONSTRUCTION a software system should be built and it should define its own customization. > > > Second, at least use self class environment at: #foo > > Why is it much much much better? because it does not rely on String class resolution and as such > is much more modular. You do not want to have the resolution of a symbol related to the place where String is defined but on where your code is actually. > > Imagine that tomorrow your code is in its own module. Then you want to know from your code point of you > if a binding exist not from the one of environment in which String is. > > > > > here are some examples: > > ============================== > quadrangleClass > ^ 'QuadrangleForTesting' asClass > > Strange it simply breaks. Of course it broke the smallLint rule. > > ============================== > Metacello should better define OSProcess as a dependent.Because it is not clear what will happen > if if not there? > > extractRepositoryFrom: zipFile to: directory > "unzip <zipFile> into <directory>" > > | out err proc errorMessage | > out := FileStream forceNewFileNamed: '/tmp/zip.out'. > err := FileStream forceNewFileNamed: '/tmp/zip.err'. > errorMessage := ''. > [ > proc := #OSProcess asClass thisOSProcess > forkJob: '/usr/bin/unzip' > arguments: > {'-u'. > zipFile. > '-d'. > directory} > environment: nil > descriptors: (Array with: nil with: out with: err). > > ================== > > I do not get why we need this funky logic. > > openInBrickWindowLabeled: aLabel > > #GLMSystemWindowBrick asClassIfAbsent: [ > ^ self asMorph openInWindow ]. > > ^ #GLMSystemWindowBrick asClass new > label: aLabel; > color: Color transparent; > addBrickBack: ( > GLMBrick new > vSpaceFill > > > window > "Answer the receiver's window." > #GLMWindowBrick asClassIfAbsent: [ > ^ self ownerThatIsA: SystemWindow ]. > > ^ (self ownerThatIsA: #GLMWindowBrick asClass) > ifNil: [ self ownerThatIsA: SystemWindow ] > > > > sendUsageData: aBoolean > | settingsClass | > settingsClass := #GTSpotterEventRecorderSettings asClassIfAbsent: [ ^ self ]. > ^ settingsClass sendUsageData: aBoolean > > > sendUsageData > | settingsClass | > settingsClass := #GTSpotterEventRecorderSettings asClassIfAbsent: [ ^ false ]. > ^ settingsClass sendUsageData > >

April 10, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by Nicolai Hess

2015-04-10 2:37 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > I was using it frequently too and I have never experienced any issues... > Ok, can you describe a use case, what test case you can start and close the debugger without image freeze? Maybe we can find what is the difference between that test case and those that freeze the image, and than find a fix. > > 2015-04-09 14:58 GMT-07:00 Nicolai Hess <nicolaihess(a)web.de>: > > >> 2015-04-09 23:38 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> >>> No Debug Tests? >>> >>> Geez, I am using that all the time. >>> >> >> And you're never encountered this issue 14689 >> <https://pharo.fogbugz.com/default.asp?14689>? >> Or did this work in older versions? >> >> >> >> >>> >>> Phil >>> >>> >>> On Thu, Apr 9, 2015 at 10:21 PM, Marcus Denker <marcus.denker(a)inria.fr> >>> wrote: >>> >>>> >>>> > On 09 Apr 2015, at 22:32, Sean P. DeNigris <sean(a)clipperadams.com> >>>> wrote: >>>> > >>>> > Nicolai Hess wrote >>>> >> >>>> http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-… >>>> > >>>> > Ah, I miss that too! From that thread, it seems it was removed >>>> temporarily >>>> > until we have real breakpoints. Is there an issue for its return? >>>> > >>>> >>>> Not yet. >>>> >>>> Marcus >>>> >>> >>> >> >

April 10, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Tudor Girba

Hi, All methods from GT annotated with <gtExample> were renamed to #gtExample*. So, the road for isExampleMethod is simpler. Cheers, Doru On Thu, Apr 9, 2015 at 12:45 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > > > On Thu, Apr 9, 2015 at 12:31 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> 2015-04-09 11:53 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >>> Hi, >>> >>> On Thu, Apr 9, 2015 at 11:44 AM, Nicolai Hess <nicolaihess(a)web.de> >>> wrote: >>> >>>> >>>> >>>> 2015-04-09 11:36 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>> >>>>> Hi, >>>>> >>>>> On Thu, Apr 9, 2015 at 11:31 AM, Nicolai Hess <nicolaihess(a)web.de> >>>>> wrote: >>>>> >>>>>> 2015-04-09 8:48 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>>>> >>>>>>> I would not do that. I think that removing the example pragma check >>>>>>> is sufficient for now. Could we do it? >>>>>>> >>>>>> >>>>>> Sufficient for what? >>>>>> >>>>> >>>>> You said to add the extra check saying " *AND HAS NOT* a <example> (or >>>>> <gtExample>) pragma " >>>>> and I said that it is sufficient to just remove the pragma check for >>>>> the Pharo 4 release :). >>>>> >>>> >>>> No, I don't think this is enough. There are so many #exampleXXX method >>>> from GT in the Pharo4 image >>>> and most of them don't work with nautilus play-icon for #exampleXXX >>>> methods >>>> >>> >>> They don't do anything harmful either. >>> >> >> No? We have now methods with the play icon that opens some >> window/widget/... (The old examples) >> And we have now many new example methods with this play icon that just do >> nothing (visible). >> I find this distracting. >> >> >> >>> But, you can also add the check as you suggest. >>> >> >> >> Well, I don't like this solution. >> We would define a method to be an "example method" if it is *not* tagged >> with <example> pragma. >> This is confusing too. >> > > Yes, that is why I said that we should not add that check :) > > >> Possible solutions: >> - remove the "run this example" play icon from nautilus, because with all >> the new exampleXXX methods from GT >> it is useless for ~half of all the methods. >> - rename the example methods from GT to something else, so it does not >> interfere with nautilus >> > > Ok. We will rename the #example* methods from GT to gtExample* before the > release. > > > >> - change the isExampleMethod check to *only* check for some >> <OnWhatEverExamplePragmaWeAgree> and >> tag all old (spec/widget/UI) example methods with this pragma. >> > > I wish to have no pragma in isExampleMethod for Pharo 4. We can talk about > it afterwards. > > But, we still need a pharo issue. Could you create one? :) > > Cheers, > Doru > > >> >> For Pharo 4.0 I think we have to live with this mess and clean it up for >> the next release. >> >> >> >>> >>> >>>> >>>> >>>>> >>>>> >>>>>> I think there is no problem if we remove the pragma check. Because >>>>>> only very few (if any) >>>>>> >>>>>> example methods (those that really open an example) relies only on >>>>>> the pragma, without having a #exampleXXX name too. >>>>>> >>>>> >>>>> Exactly. >>>>> >>>>> >>>>>> I just think this would not change much. >>>>>> We need to clean up the mess with the #example* methods. >>>>>> >>>>> >>>>> Thanks. >>>>> >>>>> Can you produce the issue and slice? >>>>> >>>> >>>> For what, removing the example check or renaming all #example* methods >>>> that don't open an example? >>>> >>> >>> For removing the example check. >>> >>> Cheers, >>> Doru >>> >>> >>>> >>>> >>>>> >>>>> @Torsten: are you fine with this? >>>>> >>>>> Doru >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> On Wed, Apr 8, 2015 at 5:16 PM, Nicolai Hess <nicolaihess(a)web.de> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2015-04-08 10:20 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>>>>>> >>>>>>>>> >>>>>>>>> And, to have a better chance of having a clean slate discussion >>>>>>>>> later on in which to consider the value we associate to names, I would like >>>>>>>>> to remove the <example> check from isExampleMethod and continue to preserve >>>>>>>>> the treatment of #example* selectors in Nautilus. >>>>>>>>> >>>>>>>>> >>>>>>>> Wouldn't we need to change the check to: >>>>>>>> >>>>>>>> isExampleMethod >>>>>>>> if selector starts with 'example' *AND HAS NOT* a <example> (or >>>>>>>> <gtExample>) pragma >>>>>>>> >>>>>>>> because there are tons of #example* methods, some of them open an >>>>>>>> example and some of them with the pragma, create an instance for the >>>>>>>> inspector? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "Every thing has its own flow" >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

April 10, 2015

Re: [Pharo-dev] source code mgmt issues in Pharo4

by Johan Brichau

Hi Stef, I sent my image to Thierry who found the cause of one issue. So thatâs very cool. Thx Thierry! Unfortunately, there were other issues I had in other images and the problem with reporting an issue on the tracker right now is that I cannot reproduce and can only vaguely describe it. So, until I hit it againâ¦ cannot say much. I hope to get back soon though :/ Johan > On 09 Apr 2015, at 22:42, stepharo <stepharo(a)free.fr> wrote: > > Hi johan > > I usually attract bugs but not these ones. > - I got debugger freezing > - broken refactoring > but not that ones. I would love to have a way to reproduce it. > > Stef > > > > Le 8/4/15 19:41, Johan Brichau a Ã©crit : >> Hi all, >> >> Over the last week, I started working with Pharo4, mostly to make Seaside work cleanly. >> >> On several occasions, I had severe issues with the package management: >> - methods that were changed in a class were not recorded as âchangedâ in monticello and were absent from the published package >> - versions of methods disappeared (i.e. no longer accessible in the version history of a method) >> - looking at the âchangedâ in Monticello showed all code of the package as changed (though only a single method has changed). >> >> This makes working with Pharo4 extremely problematic. I cannot trust the source code packaging/publishing and merging anymore. >> >> I cannot discern a scenario that leads to these issues but I do have an image right now where I only changed a single method and the entire package shows up as âchangedâ. >> >> Anyone experience similar issues? >> >> Johan >> > >

April 10, 2015