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 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? > > 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. > Thierry > > 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] Commenting a whole method

by Matthieu Lacaton

Sure, here it is : https://pharo.fogbugz.com/f/cases/15679/Writing-only-one-quote-at-the-begin… I did not really know where to put it though :/ 2015-06-03 9:17 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-06-03 8:56 GMT+02:00 Matthieu Lacaton <matthieu.lacaton(a)gmail.com>: > >> Hello everyone, >> >> When I try to comment a whole method, if I only put one quote at the >> beginning of the method, a window opens telling me that there is a syntax >> error : unmatched " in comment. >> For some reasons it does not appear all the time. >> >> One way to reproduce this is to create a new method , name it and >> directly press the " button on the line below the name. Normally you'll >> have two " printed and if you just remove the last one you'll have the >> window error popping. >> >> I am using image #50074 and I don't know if it is a feature or a bug but >> I didn't have this behavior with #50001. >> >> If it is a feature I just want to say that I find this a bit annoying :( >> > > it is a bug. It is because we changed the styler. The new styler still has > some minor issues (like this one). > can you open a bug report, please. > > > >> >> Cheers, >> >> Matthieu >> > >

June 3, 2015

Re: [Pharo-dev] backport fixes?

by Marcus Denker

> On 03 Jun 2015, at 09:28, Johan Brichau <johan(a)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

backport fixes?

by Johan Brichau

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 ? [1] https://pharo.fogbugz.com/default.asp?15666 <https://pharo.fogbugz.com/default.asp?15666> cheers Johan

June 3, 2015

Re: [Pharo-dev] Commenting a whole method

by Nicolai Hess

2015-06-03 8:56 GMT+02:00 Matthieu Lacaton <matthieu.lacaton(a)gmail.com>: > Hello everyone, > > When I try to comment a whole method, if I only put one quote at the > beginning of the method, a window opens telling me that there is a syntax > error : unmatched " in comment. > For some reasons it does not appear all the time. > > One way to reproduce this is to create a new method , name it and directly > press the " button on the line below the name. Normally you'll have two " > printed and if you just remove the last one you'll have the window error > popping. > > I am using image #50074 and I don't know if it is a feature or a bug but I > didn't have this behavior with #50001. > > If it is a feature I just want to say that I find this a bit annoying :( > it is a bug. It is because we changed the styler. The new styler still has some minor issues (like this one). can you open a bug report, please. > > Cheers, > > Matthieu >

June 3, 2015

Re: [Pharo-dev] Commenting a whole method

by Marcus Denker

Hello, This seems to be a bug with the AST syntax highlighting. I will try to reproduce and add an issue (there was a bug similar that I fixed already). You can turn it off in the preferences and use the old parser for highlighting if you are too disturbed. > On 03 Jun 2015, at 08:56, Matthieu Lacaton <matthieu.lacaton(a)gmail.com> wrote: > > Hello everyone, > > When I try to comment a whole method, if I only put one quote at the beginning of the method, a window opens telling me that there is a syntax error : unmatched " in comment. > For some reasons it does not appear all the time. > > One way to reproduce this is to create a new method , name it and directly press the " button on the line below the name. Normally you'll have two " printed and if you just remove the last one you'll have the window error popping. > > I am using image #50074 and I don't know if it is a feature or a bug but I didn't have this behavior with #50001. > > If it is a feature I just want to say that I find this a bit annoying :( > > Cheers, > > Matthieu

June 3, 2015

Commenting a whole method

by Matthieu Lacaton

Hello everyone, When I try to comment a whole method, if I only put one quote at the beginning of the method, a window opens telling me that there is a syntax error : unmatched " in comment. For some reasons it does not appear all the time. One way to reproduce this is to create a new method , name it and directly press the " button on the line below the name. Normally you'll have two " printed and if you just remove the last one you'll have the window error popping. I am using image #50074 and I don't know if it is a feature or a bug but I didn't have this behavior with #50001. If it is a feature I just want to say that I find this a bit annoying :( Cheers, Matthieu

June 3, 2015

compiler exercise :)

by stepharo

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] I need reviewer of https://pharo.fogbugz.com/default.asp?15646

by Marcus Denker

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. 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] block syntax experiments

by Jan Vrany

On Wed, 2015-06-03 at 03:16 +0200, Peter UhnÃ¡k 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? > Francisco, Interesting. Looks handy, too :-) But I found the syntax bit confusing as it looks like that the block is created and never stored. Maybe add:to:= [:x :y | x + y ] add: 3 to: 4 I'm not terribly happy with that either, but... > > But you still need to have the block saved in a variable. You cannot > pollute global namespace with names of parameters within the block, > 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 am sure others will have different opinions. > This is handy when one needs to define a method-local function sort of things. I do that often using the variable + value:value: syntax but it's ugly and not intention revealing (unless you're really used to this idiom) > > 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. > > > 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. > Using a doesNotUnderstand: here would have performance problems. (unless Cog does something super-smart) Jan > > Peter > >

June 3, 2015