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

Re: [Pharo-dev] I need reviewer of https://pharo.fogbugz.com/default.asp?15646

by Thierry Goubier

2015-06-03 11:41 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-06-03 8:22 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> Indeed... this has to do something with caching: when looking a .mcz the >> system just takes the one it finds, which might be >> one with the same name but different. >> > > here is a minimal change to the way it uses the cache, or omitting the > cache after the correct version > wasn't find in the cache. > > What do you think, may this work? > I'm not sure the problem is there. Often, in configurations, you don't have the full version info, just the mcz name :( And I would expect that a given repo has a single mcz with a given name (i.e. the repo cache should be working properly)... Nice find that each file based repository has a cache in addition to the main package cache.... Package loads with version info happens in two cases: - dependency loading (i.e. slices) - history loading (i.e. browsing history and merges). Anything else is loading by name, since this is what is recorded in Configurations and Gofer scripts. Thierry > > nicolai > > > > >> >> Maybe we could for real put (part of) the UID in the filename? >> >> In a disconnected system the case that the filename is the same for >> different files will always happen if the name is contructed >> as it is now. >> >> Marcus >> >> > On 02 Jun 2015, at 22:37, stepharo <stepharo(a)free.fr> wrote: >> > >> > I hate so much this bug.... >> > >> > >> > Le 1/6/15 15:04, Ben Coman a Ã©crit : >> >> Stef, I can now see all the dependent packages for the new slice, but >> >> I still have a strange error. However I'm not sure if its a bug or >> >> something unique at my end. >> >> >> >> Can someone try merging >> >> >> SLICE-Issue-15646-Cleaning-method-category-api-should-be-protocol-part-1-StephaneDucasse.1 >> >> >> >> What I see at top of stack is two calls to MCVersionMerger>>addVersion: >> >> >> >> MCVersionMerger>>addVersion: aVersion >> >> records add: (MCMergeRecord version: aVersion). >> >> aVersion dependencies >> >> do: [:ea | | dep satisfied | >> >> dep := ea resolve. >> >> satisfied := (records anySatisfy: [:r | r version = >> dep]). >> >> satisfied ifFalse: [self addVersion: dep]] "<<< race? >> " >> >> displayingProgress: [ :ea| 'Searching dependency: ', ea >> >> package name] >> >> "15646Note: variable /satisfied/ added for reporting/debugging" >> >> >> >> One level down from where the error occurs the debugger shows... >> >> >> >> /aVersion/ --> a >> >> >> MCVersion(SLICE-Issue-15646-Cleaning-method-category-api-should-be-protocol-part-1-StephaneDucasse.1) >> >> >> >> /ea/ --> a MCVersionInfo(DebuggerActions-StephaneDucasse.75) >> >> >> >> /dep/ --> nil >> >> >> >> /satisfied/ --> false >> >> >> >> and the following which contradicts the value in /satisfied/ >> >> >> >> (records anySatisfy: [:r | r version = dep]) --> true. >> >> >> >> so there seems to be a race such that the ifFalse block is improperly >> >> executed, such that the recursive call on top of stack has... >> >> >> >> /aVersion/-->nil >> >> >> >> hence MNU receiver of "dependencies" is nil. >> >> >> >> cheers -ben >> >> >> >> >> >> On Mon, Jun 1, 2015 at 10:36 AM, Ben Coman <btc(a)openinworld.com> >> wrote: >> >>> I tried, but it seems some packages are missing from the inbox. >> >>> cheers -ben >> >>> >> >>> On Sun, May 31, 2015 at 2:19 PM, stepharo <stepharo(a)free.fr> wrote: >> >>>> Hi >> >>>> >> >>>> I continued to clean that classes have categories and method >> protocols >> >>>> because it was not finished. >> >>>> This entry is just adding protocol in the classes that were missing >> it, >> >>>> adding comments, and fixing some local senders >> >>>> It does not remove the category API but puts it in a >> accessing-backward >> >>>> protocol and in a second step I will fix all the senders I can (ie >> not >> >>>> Metacello for example). >> >>>> Category is really overloaded and we get lost when trying to >> understand >> >>>> code. >> >>>> I want to rename RBRule 'category' into 'kind' for this reason. >> >>>> >> >>>> Stef >> >>>> >> >> >> > >> > >> >> >> >

June 3, 2015

Re: [Pharo-dev] I need reviewer of https://pharo.fogbugz.com/default.asp?15646

by Nicolai Hess

2015-06-03 8:22 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > Indeedâ¦ this has to do something with caching: when looking a .mcz the > system just takes the one it finds, which might be > one with the same name but different. > here is a minimal change to the way it uses the cache, or omitting the cache after the correct version wasn't find in the cache. What do you think, may this work? nicolai > > Maybe we could for real put (part of) the UID in the filename? > > In a disconnected system the case that the filename is the same for > different files will always happen if the name is contructed > as it is now. > > Marcus > > > On 02 Jun 2015, at 22:37, stepharo <stepharo(a)free.fr> wrote: > > > > I hate so much this bug.... > > > > > > Le 1/6/15 15:04, Ben Coman a Ã©crit : > >> Stef, I can now see all the dependent packages for the new slice, but > >> I still have a strange error. However I'm not sure if its a bug or > >> something unique at my end. > >> > >> Can someone try merging > >> > SLICE-Issue-15646-Cleaning-method-category-api-should-be-protocol-part-1-StephaneDucasse.1 > >> > >> What I see at top of stack is two calls to MCVersionMerger>>addVersion: > >> > >> MCVersionMerger>>addVersion: aVersion > >> records add: (MCMergeRecord version: aVersion). > >> aVersion dependencies > >> do: [:ea | | dep satisfied | > >> dep := ea resolve. > >> satisfied := (records anySatisfy: [:r | r version = > dep]). > >> satisfied ifFalse: [self addVersion: dep]] "<<< race? " > >> displayingProgress: [ :ea| 'Searching dependency: ', ea > >> package name] > >> "15646Note: variable /satisfied/ added for reporting/debugging" > >> > >> One level down from where the error occurs the debugger shows... > >> > >> /aVersion/ --> a > >> > MCVersion(SLICE-Issue-15646-Cleaning-method-category-api-should-be-protocol-part-1-StephaneDucasse.1) > >> > >> /ea/ --> a MCVersionInfo(DebuggerActions-StephaneDucasse.75) > >> > >> /dep/ --> nil > >> > >> /satisfied/ --> false > >> > >> and the following which contradicts the value in /satisfied/ > >> > >> (records anySatisfy: [:r | r version = dep]) --> true. > >> > >> so there seems to be a race such that the ifFalse block is improperly > >> executed, such that the recursive call on top of stack has... > >> > >> /aVersion/-->nil > >> > >> hence MNU receiver of "dependencies" is nil. > >> > >> cheers -ben > >> > >> > >> On Mon, Jun 1, 2015 at 10:36 AM, Ben Coman <btc(a)openinworld.com> wrote: > >>> I tried, but it seems some packages are missing from the inbox. > >>> cheers -ben > >>> > >>> On Sun, May 31, 2015 at 2:19 PM, stepharo <stepharo(a)free.fr> wrote: > >>>> Hi > >>>> > >>>> I continued to clean that classes have categories and method protocols > >>>> because it was not finished. > >>>> This entry is just adding protocol in the classes that were missing > it, > >>>> adding comments, and fixing some local senders > >>>> It does not remove the category API but puts it in a > accessing-backward > >>>> protocol and in a second step I will fix all the senders I can (ie not > >>>> Metacello for example). > >>>> Category is really overloaded and we get lost when trying to > understand > >>>> code. > >>>> I want to rename RBRule 'category' into 'kind' for this reason. > >>>> > >>>> Stef > >>>> > >> > > > > > > >

June 3, 2015

Re: [Pharo-dev] compiler exercise :)

by Matthieu Lacaton

Nice :) That is funny because I am currently doing something similar. I need to recompile all the methods of all classes of a package to change a word in the methods. I have 237 classes and a hell lot of methods in each :p So I did : (RPackageOrganizer default packageNamed: 'MyPackage') definedClasses do: [ :each1 | each1 methods do: [ :each2 | each1 compile: (each2 sourceCode copyReplaceAll: 'OldWord' with: 'NewWord' asTokens: true). ]. ]. Apparently it worked too ! But now my problem is I have about 200 words to replace every time so I need a third iteration. 2015-06-03 8:34 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi > > I would like to do the following: recompile the method category into a > method name group without removing for now the method category. I have to > do that 125 times :) > > so I did > > RBLintRule > addSelector: #group > withMethod: ((RBLintRule methodDictionary at: #category) ast > selector: #group; generate) > > and it worked :) > At least I believe. > > Great system > > >

June 3, 2015

Re: [Pharo-dev] block syntax experiments

by stepharo

my impression is that we can focus on better improvements with larger impact,. Le 3/6/15 02:17, Francisco Garau a Ã©crit : > Hello, > > I'd like to make some syntax changes that would make block evaluation > more legible. > > Currently we define and evaluate blocks like this: > > inc := [ : x | x + 1 ]. > (inc value: 3) = 4. > addTo := [ : x : y | x + y ]. > (addTo value: 3 value: 4) = 7. > > > But I would like them to be defined like this: > > [ inc: x | x + 1 ]. > (inc: 3) = 4 > > [add: x to: y | x + y ]. > (add: 3 to: 4) = 7. > > > What do you think? Is it feasible? > > I presume it's Opal where I should start looking at implementing this > changes, but any hints/suggestions are welcomed. > > Cheers, > Francisco

June 3, 2015

Re: [Pharo-dev] backport fixes?

by Marcus Denker

Yes! > On 03 Jun 2015, at 10:07, Johan Brichau <johan(a)inceptive.be> wrote: > > Marcus, > > I hope Iâve done this right: https://pharo.fogbugz.com/default.asp?15680 <https://pharo.fogbugz.com/default.asp?15680> > > thanks > Johan > >> On 03 Jun 2015, at 09:34, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> >>> On 03 Jun 2015, at 09:28, Johan Brichau <johan(a)inceptive.be <mailto:johan@inceptive.be>> wrote: >>> >>> Hi, >>> >>> What is the procedure to get fixes backported in 4.0? >>> >>> For example, the fix to this one [1] is really needed for us (it breaks development and also gettext tools). >>> >>> Is there anything you guys do âautomaticallyâ or do I need to make a fix for 4.0 based on the one for 5.0 ? >> >> No, we do back ports when they are so important that people ask. I think this is a good metrik. >> >> What you do is to add a second issue with the title >> >> Backport 4.0: <Original title> >> >> and put it as the *parent* of the Pharo5 issue. >> >>> >>> [1] https://pharo.fogbugz.com/default.asp?15666 <https://pharo.fogbugz.com/default.asp?15666> >>> >>> cheers >>> Johan >> >

June 3, 2015

Re: [Pharo-dev] block syntax experiments

by Francisco Garau

On 3 June 2015 at 05:56, Ben Coman <btc(a)openinworld.com> wrote: > I think that would confuse me, and maybe break syntax highlighting. > It *looks* like a message send to nothing. That might be a good thing as there is no object needed to resolve the method lookup. You already have the "method" to evaluate, which is obviously the block. It's a bit heretic, but the more I think, the more I like it. > How about something that gives more feeling of inserting... > add <-- 3 , 4. > add <<< 3 , 4. > add <<: 3 <<: 4. > add @:3 @:4. > > > cheers -ben > > > On Wed, Jun 3, 2015 at 8:17 AM, Francisco Garau > <francisco.garau(a)gmail.com> wrote: > > Hello, > > > > I'd like to make some syntax changes that would make block evaluation > more > > legible. > > > > Currently we define and evaluate blocks like this: > > > > inc := [ : x | x + 1 ]. > > (inc value: 3) = 4. > > addTo := [ : x : y | x + y ]. > > (addTo value: 3 value: 4) = 7. > > > > > > But I would like them to be defined like this: > > > > [ inc: x | x + 1 ]. > > (inc: 3) = 4 > > > > [add: x to: y | x + y ]. > > (add: 3 to: 4) = 7. > > > > > > What do you think? Is it feasible? > > > > I presume it's Opal where I should start looking at implementing this > > changes, but any hints/suggestions are welcomed. > > > > Cheers, > > Francisco > >

June 3, 2015

Re: [Pharo-dev] backport fixes?

by Johan Brichau

Marcus, I hope Iâve done this right: https://pharo.fogbugz.com/default.asp?15680 <https://pharo.fogbugz.com/default.asp?15680> thanks Johan > On 03 Jun 2015, at 09:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 03 Jun 2015, at 09:28, Johan Brichau <johan(a)inceptive.be <mailto:johan@inceptive.be>> wrote: >> >> Hi, >> >> What is the procedure to get fixes backported in 4.0? >> >> For example, the fix to this one [1] is really needed for us (it breaks development and also gettext tools). >> >> Is there anything you guys do âautomaticallyâ or do I need to make a fix for 4.0 based on the one for 5.0 ? > > No, we do back ports when they are so important that people ask. I think this is a good metrik. > > What you do is to add a second issue with the title > > Backport 4.0: <Original title> > > and put it as the *parent* of the Pharo5 issue. > >> >> [1] https://pharo.fogbugz.com/default.asp?15666 <https://pharo.fogbugz.com/default.asp?15666> >> >> cheers >> Johan >

June 3, 2015

Re: [Pharo-dev] I need reviewer of https://pharo.fogbugz.com/default.asp?15646

by Thierry Goubier

2015-06-03 9:56 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 03 Jun 2015, at 09:52, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > 2015-06-03 8:22 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> Indeed... this has to do something with caching: when looking a .mcz the >> system just takes the one it finds, which might be >> one with the same name but different. >> > > Unless the mcz searched for is a dependency, in which case it checks the > uuid as well (not only the name). > > >> >> Maybe we could for real put (part of) the UID in the filename? >> > > Would that be backward compatible with existing repositories? > > > > I would just put it instead of the Name of the submitter... > I'm not that worried about that problem, but the fact that in MC, when you query a repo, you build a kind of a match between your target version info and a "possible" file name... If you start creating names with UUIDs in them, how will the system distinguish between version infos where you should use the UUID and version infos (for example, in the history) where you shouldn't. Give a higher priority to matching with an UUID-based name ? Go through Gofer twice, first with a UUID version of the name, then with a non-UUID version of the name if the first one fails? I believe there are places (MC itself, Gofer?) where the true version info is decoupled from the search and only the package name is used (i.e. name + author + version number). Thierry > > Marcus > >

June 3, 2015

Re: [Pharo-dev] block syntax experiments

by Francisco Garau

On 3 June 2015 at 02:16, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > But I would like them to be defined like this: >> >> [ inc: x | x + 1 ]. >> (inc: 3) = 4 >> >> [add: x to: y | x + y ]. >> (add: 3 to: 4) = 7. >> >> >> What do you think? Is it feasible? >> > > But you still need to have the block saved in a variable. You cannot > pollute global namespace with names of parameters within the block, > The block would still be saved in a variable -- I see that happening behind the scenes. In other words, you would have something like this: [ inc: x | x + 1 ]. (inc: 3) = 4. inc class = BlockClosure [add: x to: y | x + y ]. (add: 3 to: 4) = 7. addto class = BlockClosure not to mention the fact that most blocks in the system have same parameter > names. > Now while the idea seems interesting; I cannot imagine how it would work > in practice. Imagine collection's "do:" method explicitly stating the name > of the argument, which would force me to name it in such and such way which > would actually impair the readability. > I don't see that problem, as anonymous blocks would remain the same as now. You will still have this: (1 to: 5) do: [ :x | x + 1 ] My extensions are syntactic sugar to store and evaluate a block. They wouldn't help in a case like this: Point class >> incBlock ^[: x | x + 1] b := Point incBlock. I am sure others will have different opinions. > > However if you want to try it out, you should apart from Opal have to look > also at AST-Core since you are changing syntax. > Thanks for the pointers. > > Also I am thinking that combination of variable name + named arguments > could perhaps be done purely with overriding doesNotUnderstand: method in > BlockClosure and calling value:value: internally. (Or even cull:cull:, but > form what I've heard that has some dire performance issues); this could > perhaps even solve my comment about enforced naming. > > Peter > >> >

June 3, 2015

Re: [Pharo-dev] I need reviewer of https://pharo.fogbugz.com/default.asp?15646

by Marcus Denker

> On 03 Jun 2015, at 09:52, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-06-03 8:22 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > Indeedâ¦ this has to do something with caching: when looking a .mcz the system just takes the one it finds, which might be > one with the same name but different. > > Unless the mcz searched for is a dependency, in which case it checks the uuid as well (not only the name). > > > Maybe we could for real put (part of) the UID in the filename? > > Would that be backward compatible with existing repositories? > I would just put it instead of the Name of the submitterâ¦ Marcus

June 3, 2015