- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Differences Compiler vs. OpalCompiler (or parser)

by Andrei Chis

On Sat, Nov 21, 2015 at 3:25 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Hi Nicolai, >> >> On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >>> GTDummyExamples class >>> d: anInteger >>> <gtExample> >>> <label: 'Dummy #d:, depends #c:'> >>> <description: 'should raise an exception as the argument is not >>> anInteger'> >>> <depends: #c:> >>> <raises: Literal constant expected -> MessageNotUnderstood> >>> >>> ^ 1 + anInteger >>> >>> The old Parser complains about the class name "MessageNotUnderstood" >>> used as a pragma >>> argument without being a string or symbol >>> >>> Opal does not complain >>> >>> Is Opals behavior intended ? >>> >> >> IMO no. The pragma design is that the only valid syntax is of a message >> pattern with only literal arguments except for the one piece of syntactic >> sugar where the error temporary name in a primitive call with an error can >> be given as an identifier, e.g. >> >> addressField >> <primitive: 'primAddressField' module: 'IA32ABI' error: errorCode> >> ^self primitiveFailed >> >> instead of >> >> addressField >> <primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'> >> ^self primitiveFailed >> >> >> The issues are class reference, class redefinition, class removal etc. I >> guess we could extend the pragma syntax to allow class references but >> there's a lot of impact. I would prefer if we keep things restricted. >> There's nothing to stop one using a symbol and mapping it to a class name, >> e.g. >> >> >> GTDummyExamples class >> d: anInteger >> <gtExample> >> <label: 'Dummy #d:, depends #c:'> >> <description: 'should raise an exception as the argument is not >> anInteger'> >> <depends: #c:> >> <raises: #MessageNotUnderstood> >> >> ^ 1 + anInteger >> > > Thanks eliot > > Yes, we have this code too, I think, using the global var instead of a > symbol happened by accident. > > @andrei (and stefan?) can you check the GTDummyExamples methods > and replace classes with symbol names. > > After this is removed I will change the parser to notify about this. > I updated the pragmas to use symbols. Cheers, Andrei > > > >> >> Also, I *hate* this style of pragma. Why not >> >> GTDummyExamples class >> d: anInteger >> <gtExampleLabel: 'Dummy #d:, depends #c:' >> description: 'should raise an exception as the argument is not >> anInteger' >> depends: #c: >> raises: #MessageNotUnderstood> >> >> ^ 1 + anInteger >> >> ? >> > > no idea. > > > >> >> That's how the system is designed to be used. Then the message can be >> implemented by a builder which performs the selector from a visitor. >> >> From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770 >>> >>> Cascading message sends to super. >>> >>> Compiler refuses to compile >>> super >>> initialize; >>> setListProperties >>> >>> >>> It looks like Opal would compile this to >>> >>> super initialize. >>> super setListProperties. >>> >>> Intended ? Do we want to keep it? >>> >>> NBNativeCodeGen >>> parseOptions: optionsArray >>> uses association symbol -> block instead of block -> block >>> for caseOf arguments. >>> The old parser does not accept this. >>> >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> > >

Dec. 4, 2015

Cannot upload file on Smalltalkhub

by Juraj Kubelka

Hi, For some reasons I cannot upload mcz files on Smalltalkhub: 500 Internal Server Error text/plain;charset=utf-8 30B Am I only one? I need to upload following files into Pharo/Rubric: Thanks for any help, Juraj

Dec. 4, 2015

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

by Mariano Martinez Peck

OK, I solved the Halt problem. I did it by adding: WADebugErrorHandler class >> exceptionSelector ^ super exceptionSelector, Halt And this override: WAErrorHandler >> handleException: anException (Error handles: anException) ifTrue: [ ^ self handleError: anException ]. (Warning handles: anException) ifTrue: [ ^ self handleWarning: anException ]. (Halt handles: anException) ifTrue: [ "Lets debug Halt as an error so that we can take advantage of the #openDebuggerOn: hook" ^ self handleError: anException ]. ^ super handleException: anException Can you try that too? if it gets complicated to test, I can fire a first version of a package and publish it in Shub. On Fri, Dec 4, 2015 at 2:12 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Fri, Dec 4, 2015 at 1:29 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> OK. But be aware it is very very little tested and probably still a hack, >> and it still need overrides. Hopefully you will help me to polish it until >> we get a "SeasidePharoDebugging" package with no override :) >> >> All what I mention here is tested in Pharo 4.0 with Seaside 3.1.4.1. >> >> These are the steps: >> >> 1) Create a >> >> ProcessLocalVariable subclass: #WACurrentRequestContextPLV >> instanceVariableNames: '' >> classVariableNames: '' >> category: 'SeasidePharoDebugging' >> >> 2) Override GRPharoPlatform >> openDebuggerOn (see highlighted lines) >> The idea is to simply store the WACurrentRequestContext into a processor >> local variable before we loose it. >> >> openDebuggerOn: anError >> | process currentRequest | >> process := Processor activeProcess. >> currentRequest := WACurrentRequestContext value. >> >> "If we are running in the UI process, we don't want to suspend the active >> process. The >> error was presumably triggered while stepping in the Debugger. If we >> simply immediately >> signal an UnhandledError, the debugger will catch this and display the >> signaling context. >> It isn't perfect or pretty but it works." >> (ProcessBrowser isUIProcess: process) >> ifTrue: [ >> UnhandledError signalForException: anError ] >> ifFalse: [ >> WorldState addDeferredUIMessage: [ >> WACurrentRequestContextPLV value: currentRequest. >> process >> debug: anError signalerContext >> title: anError description >> full: true. >> ]. >> process suspend ] >> >> >> 3) Override WACurrentRequestContext class >> defaultValue >> >> defaultValue >> ^ WACurrentRequestContextPLV value ifNil: [ WARequestContextNotFound >> signal ] >> 4) Set WADebugErrorHandler as the error handler in your seaside app (I am >> not sure if this step is needed). >> >> And that's all. Try to put a "self whateverMethodThatCausesDNU" and then, >> try to evalaute something from the debugger that calls #session or >> #requestContext etc... for example, evaluate "WAComponent new session" and >> that should work: >> >> Besides the overrides I still have doubts: >> >> a) do we need WADebugErrorHandler ? >> > > Yes, we do, because we are hooking in #openDebuggerOn: and that's only > called from WADebugErrorHandler. > > >> b) it seems "Halt halt" does not work but sending a message that causes >> dnu does work. Maybe related to WADebugErrorHandler. >> > > I guess problem is that while MessageNotUnderstood is indeed a subclass of > Error, Halt is not. Anyway, the real problem is that with halt, the hooked > method #openDebuggerOn: is not called... I tried to find out which > method handled Halt but I failed. > > > c) what happens if we have multiple debuggers opened? I am worried about >> the "soleInstance" of ProcessSpecificVariable. >> >> >> Thoughts? Can you tell me if this works for you? >> >> >> >> >> On Fri, Dec 4, 2015 at 1:13 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 04 Dec 2015, at 17:11, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> >>> I found a way!!!! Much cleaner and easier. Awesome! >>> I will clean it, test it a bit more and try to package it for public >>> usage :) >>> >>> >>> Give me a snippet! I want to play with it! :D >>> >>> >>> On Fri, Dec 4, 2015 at 12:31 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> >>>> >>>> On Fri, Dec 4, 2015 at 12:05 PM, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>>> >>>>> On 04 Dec 2015, at 14:29, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>> wrote: >>>>> >>>>> Max...Seaside uses WADynamicVariable (NOT DynamicVariable) which >>>>> are completely different. WADynamicVariable uses exception mechanism >>>>> while DynamicVariable uses the ProcessSpecificVariable. >>>>> But thanks anyway! >>>>> >>>>> >>>>> Oh manâ¦. Sorry :) >>>>> >>>>> I wonder, why WADynamicVariable *isnât* a DynamicVariable. The >>>>> semantics are the same if Iâm not mistaken (e.g. only available in the >>>>> current process) and I think access to a dynamic variable may even be >>>>> faster because it *doesnât* use the exception mechanism (i.e. no need to >>>>> walk down the stack). >>>>> If someone knows the answer, Iâd be happy to hear it. >>>>> >>>>> >>>> I bet it's because of portability. For example, i remember in GemStone >>>> the ProcessorLocalVariable did not behave the same as in Pharo. And it was >>>> actually an experiment. I think you cannot expect all this stuff to be ansi >>>> (or easily portable), while exceptions do. >>>> >>>> >>>>> Iâve played around with Process>>signalException: and >>>>> Context>>handleSignal: (which looked quite promising) but didnât get any >>>>> results. Iâm out of ideas. >>>>> >>>>> >>>> I have played all morning with an idea of using local variables. I >>>> arrive to the point where I DO HAVE the request context at hand, but I >>>> don't find an easy way to hook into do-its, print-it etc so that the >>>> closure evaluated gets the request context plugged. In other ways... let's >>>> say I have the context stored somewhere. I am at the SmalltalkEditor >> >>>> evaluateSelectionAndDo: aBlock >>>> >>>> and so..somewhere I need to do something like: >>>> >>>> WACurrentRequestContext use: self storedContextSomewhere during: [ >>>> self theSelectionToBeEvaluated ] >>>> >>>> and that's where I am now :) >>>> >>>> >>>> >>>> >>>>> Cheers, >>>>> Max >>>>> >>>>> >>>>> On Fri, Dec 4, 2015 at 7:32 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>>> >>>>>> Hereâs a snippet to play with: >>>>>> >>>>>> p := Processor activeProcess. >>>>>> x := 2. >>>>>> v := TestDynamicVariable value: x during: [ >>>>>> ((p instVarNamed: 'env') ifNotNil: [ :env| >>>>>> env copyWithout: nil ]) inspect >>>>>> ]. >>>>>> >>>>>> ((p instVarNamed: 'env') ifNotNil: [ :env| >>>>>> env copyWithout: nil ]) inspect >>>>>> >>>>>> Cheers, >>>>>> Max >>>>>> >>>>>> On 04 Dec 2015, at 10:47, Max Leske <maxleske(a)gmail.com> wrote: >>>>>> >>>>>> I feel you :) >>>>>> >>>>>> Without having thought this through completely: if you look at the >>>>>> implementation of DynamicVariable>>value:during: youâll see that the way it >>>>>> works is that the variable is bound to the active process. In the debugger >>>>>> you have access to the process that is being debugged and thus you should >>>>>> have access to the variables bound to it. You could try accessing all such >>>>>> variables by iterating over them (which I think will require an extension >>>>>> on Process because youâd need to access at least the PSKeys class variable). >>>>>> >>>>>> Cheers, >>>>>> Max >>>>>> >>>>>> On 04 Dec 2015, at 00:34, Mariano Martinez Peck < >>>>>> marianopeck(a)gmail.com> wrote: >>>>>> >>>>>> Hi guys, >>>>>> >>>>>> This thing I will ask in this email it's in my mind since YEARS. But >>>>>> I have always thought it was like that and that there was nothing we could >>>>>> do. However, I think it's time I ask again :) >>>>>> >>>>>> For those that have used Seaside, and you try to debug, you know that >>>>>> upon request processing seaside uses Exceptions mechanisim to always have >>>>>> access to the request, session, etc. They way that is done is very smart :) >>>>>> >>>>>> WACurrentRequestContext use: self during: aBlock >>>>>> >>>>>> In that case, "self" is the request instance and aBlock the closure >>>>>> that takes care of the request processing. So, inside that closure, >>>>>> everywhere you do "WACurrentRequestContext value" you get the correct >>>>>> request instance. >>>>>> >>>>>> So..that's great for Seaside, but debugging gets complicated. While >>>>>> you can restart, proceed, etc, once inside debugger, you cannot evaluate >>>>>> any piece of code that will use the session or request because you get >>>>>> a WARequestContextNotFound. Of course, because I guess the evaluation you >>>>>> do from cmd+d on a piece of text or via the debugger inspector, creates >>>>>> another closure/context which does not receive the WACurrentRequestContext >>>>>> instance. >>>>>> >>>>>> Now....besides WACurrentRequestContext I have my own class >>>>>> UserContextInformation where I basically have a bunch of stuff associated >>>>>> to the logged user. And I do exactly the same as the >>>>>> WACurrentRequestContext. And I have the same problem. I really want to be >>>>>> able to fix this. >>>>>> >>>>>> Anyone have an idea on how can I do it? I guess I can change the >>>>>> debugger, in the place where I evaluate code so that I wrap that evaluation >>>>>> with my request context instance??? >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> >>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Dec. 4, 2015

Re: [Pharo-dev] How to listen Monticello load start/end (and origin of changes)

by Andrei Chis

Hi, A fix is now available that uses custom announcements to signal the start/end of a monticello version load (MCVersionLoaderStartAnnouncement, MCVersionLoaderStopAnnouncement) A review is required: https://pharo.fogbugz.com/f/cases/17186 Cheers, Andrei On Fri, Dec 4, 2015 at 1:52 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi Martin, > > Interesting solution but it feels a bit like a hack. > For the GTools we made a solution that triggers a custom announcer before > and after a Monticello load. > We'll make a slice later today. > > Cheers, > Andrei > > On Thu, Dec 3, 2015 at 3:46 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > >> Hi, >> >> Doru asked me how does Epicea listen this information, and I created a >> snippet to demo it *in a plain Pharo 5 image* (no need to load Epicea >> before). Maybe somebody else is interested, that's why I share it with >> everybody. >> >> You can open a Transcript and evaluate the following snippet. After >> evaluation, you can add new methods in Nautilus and see the log in the >> Transcript. (The code is not very nice). >> >> Cheers, >> Martin >> >> >> >> "Listen load start" >> Job jobAnnouncer >> when: JobStart >> do: [ :aJobStart | >> | owner | >> owner := aJobStart job owner. >> >> (owner isKindOf: MCVersionLoader) >> ifTrue: [ ('Starting to load ', owner versions asArray asString) logCr ] >> ]. >> "Listen load end" >> Job jobAnnouncer >> when: JobEnd >> do: [ :aJobEnd | >> | owner | >> owner := aJobEnd job owner. >> >> (owner isKindOf: MCVersionLoader) >> ifTrue: [ ('Ending to load ', owner versions asArray asString) logCr ] ]. >> >> "Listen changes in the middle" >> SystemAnnouncer uniqueInstance >> when: MethodAdded >> do: [ :aMethodAdded | >> | mcLoaderJobOrNil | >> mcLoaderJobOrNil := >> Job current >> ifNil: [ nil ] >> ifNotNil: [ :currentJob | >> currentJob >> lookup: [ :job | job owner isKindOf: MCVersionLoader ] >> ifNone: [ nil ] ]. >> (aMethodAdded methodAdded printString, ' --- ', >> (mcLoaderJobOrNil >> ifNil: [ 'no info' ] >> ifNotNil: [ 'while loading ', mcLoaderJobOrNil owner versions asArray >> asString ])) logCr ]. >> >> >> "Try it loading" >> Gofer it >> smalltalkhubUser: 'MartinDias' project: 'AlarmClock'; >> package: 'AlarmClock'; >> load. >> >> >> >> >

Dec. 4, 2015

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

by Mariano Martinez Peck

On Fri, Dec 4, 2015 at 1:29 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > OK. But be aware it is very very little tested and probably still a hack, > and it still need overrides. Hopefully you will help me to polish it until > we get a "SeasidePharoDebugging" package with no override :) > > All what I mention here is tested in Pharo 4.0 with Seaside 3.1.4.1. > > These are the steps: > > 1) Create a > > ProcessLocalVariable subclass: #WACurrentRequestContextPLV > instanceVariableNames: '' > classVariableNames: '' > category: 'SeasidePharoDebugging' > > 2) Override GRPharoPlatform >> openDebuggerOn (see highlighted lines) > The idea is to simply store the WACurrentRequestContext into a processor > local variable before we loose it. > > openDebuggerOn: anError > | process currentRequest | > process := Processor activeProcess. > currentRequest := WACurrentRequestContext value. > > "If we are running in the UI process, we don't want to suspend the active > process. The > error was presumably triggered while stepping in the Debugger. If we > simply immediately > signal an UnhandledError, the debugger will catch this and display the > signaling context. > It isn't perfect or pretty but it works." > (ProcessBrowser isUIProcess: process) > ifTrue: [ > UnhandledError signalForException: anError ] > ifFalse: [ > WorldState addDeferredUIMessage: [ > WACurrentRequestContextPLV value: currentRequest. > process > debug: anError signalerContext > title: anError description > full: true. > ]. > process suspend ] > > > 3) Override WACurrentRequestContext class >> defaultValue > > defaultValue > ^ WACurrentRequestContextPLV value ifNil: [ WARequestContextNotFound > signal ] > 4) Set WADebugErrorHandler as the error handler in your seaside app (I am > not sure if this step is needed). > > And that's all. Try to put a "self whateverMethodThatCausesDNU" and then, > try to evalaute something from the debugger that calls #session or > #requestContext etc... for example, evaluate "WAComponent new session" and > that should work: > > Besides the overrides I still have doubts: > > a) do we need WADebugErrorHandler ? > Yes, we do, because we are hooking in #openDebuggerOn: and that's only called from WADebugErrorHandler. > b) it seems "Halt halt" does not work but sending a message that causes > dnu does work. Maybe related to WADebugErrorHandler. > I guess problem is that while MessageNotUnderstood is indeed a subclass of Error, Halt is not. Anyway, the real problem is that with halt, the hooked method #openDebuggerOn: is not called... I tried to find out which method handled Halt but I failed. c) what happens if we have multiple debuggers opened? I am worried about > the "soleInstance" of ProcessSpecificVariable. > > > Thoughts? Can you tell me if this works for you? > > > > > On Fri, Dec 4, 2015 at 1:13 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 04 Dec 2015, at 17:11, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> I found a way!!!! Much cleaner and easier. Awesome! >> I will clean it, test it a bit more and try to package it for public >> usage :) >> >> >> Give me a snippet! I want to play with it! :D >> >> >> On Fri, Dec 4, 2015 at 12:31 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> >>> >>> On Fri, Dec 4, 2015 at 12:05 PM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> >>>> On 04 Dec 2015, at 14:29, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>> wrote: >>>> >>>> Max...Seaside uses WADynamicVariable (NOT DynamicVariable) which >>>> are completely different. WADynamicVariable uses exception mechanism >>>> while DynamicVariable uses the ProcessSpecificVariable. >>>> But thanks anyway! >>>> >>>> >>>> Oh manâ¦. Sorry :) >>>> >>>> I wonder, why WADynamicVariable *isnât* a DynamicVariable. The >>>> semantics are the same if Iâm not mistaken (e.g. only available in the >>>> current process) and I think access to a dynamic variable may even be >>>> faster because it *doesnât* use the exception mechanism (i.e. no need to >>>> walk down the stack). >>>> If someone knows the answer, Iâd be happy to hear it. >>>> >>>> >>> I bet it's because of portability. For example, i remember in GemStone >>> the ProcessorLocalVariable did not behave the same as in Pharo. And it was >>> actually an experiment. I think you cannot expect all this stuff to be ansi >>> (or easily portable), while exceptions do. >>> >>> >>>> Iâve played around with Process>>signalException: and >>>> Context>>handleSignal: (which looked quite promising) but didnât get any >>>> results. Iâm out of ideas. >>>> >>>> >>> I have played all morning with an idea of using local variables. I >>> arrive to the point where I DO HAVE the request context at hand, but I >>> don't find an easy way to hook into do-its, print-it etc so that the >>> closure evaluated gets the request context plugged. In other ways... let's >>> say I have the context stored somewhere. I am at the SmalltalkEditor >> >>> evaluateSelectionAndDo: aBlock >>> >>> and so..somewhere I need to do something like: >>> >>> WACurrentRequestContext use: self storedContextSomewhere during: [ self >>> theSelectionToBeEvaluated ] >>> >>> and that's where I am now :) >>> >>> >>> >>> >>>> Cheers, >>>> Max >>>> >>>> >>>> On Fri, Dec 4, 2015 at 7:32 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>>> Hereâs a snippet to play with: >>>>> >>>>> p := Processor activeProcess. >>>>> x := 2. >>>>> v := TestDynamicVariable value: x during: [ >>>>> ((p instVarNamed: 'env') ifNotNil: [ :env| >>>>> env copyWithout: nil ]) inspect >>>>> ]. >>>>> >>>>> ((p instVarNamed: 'env') ifNotNil: [ :env| >>>>> env copyWithout: nil ]) inspect >>>>> >>>>> Cheers, >>>>> Max >>>>> >>>>> On 04 Dec 2015, at 10:47, Max Leske <maxleske(a)gmail.com> wrote: >>>>> >>>>> I feel you :) >>>>> >>>>> Without having thought this through completely: if you look at the >>>>> implementation of DynamicVariable>>value:during: youâll see that the way it >>>>> works is that the variable is bound to the active process. In the debugger >>>>> you have access to the process that is being debugged and thus you should >>>>> have access to the variables bound to it. You could try accessing all such >>>>> variables by iterating over them (which I think will require an extension >>>>> on Process because youâd need to access at least the PSKeys class variable). >>>>> >>>>> Cheers, >>>>> Max >>>>> >>>>> On 04 Dec 2015, at 00:34, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>> wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> This thing I will ask in this email it's in my mind since YEARS. But I >>>>> have always thought it was like that and that there was nothing we could >>>>> do. However, I think it's time I ask again :) >>>>> >>>>> For those that have used Seaside, and you try to debug, you know that >>>>> upon request processing seaside uses Exceptions mechanisim to always have >>>>> access to the request, session, etc. They way that is done is very smart :) >>>>> >>>>> WACurrentRequestContext use: self during: aBlock >>>>> >>>>> In that case, "self" is the request instance and aBlock the closure >>>>> that takes care of the request processing. So, inside that closure, >>>>> everywhere you do "WACurrentRequestContext value" you get the correct >>>>> request instance. >>>>> >>>>> So..that's great for Seaside, but debugging gets complicated. While >>>>> you can restart, proceed, etc, once inside debugger, you cannot evaluate >>>>> any piece of code that will use the session or request because you get >>>>> a WARequestContextNotFound. Of course, because I guess the evaluation you >>>>> do from cmd+d on a piece of text or via the debugger inspector, creates >>>>> another closure/context which does not receive the WACurrentRequestContext >>>>> instance. >>>>> >>>>> Now....besides WACurrentRequestContext I have my own class >>>>> UserContextInformation where I basically have a bunch of stuff associated >>>>> to the logged user. And I do exactly the same as the >>>>> WACurrentRequestContext. And I have the same problem. I really want to be >>>>> able to fix this. >>>>> >>>>> Anyone have an idea on how can I do it? I guess I can change the >>>>> debugger, in the place where I evaluate code so that I wrap that evaluation >>>>> with my request context instance??? >>>>> >>>>> Thoughts? >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Dec. 4, 2015

Re: [Pharo-dev] GTDebugger not draggable with latest VM

by Henrik Nergaard

Case 17178 added an extra check to the handling of mouse movement to use the result from asking the event handler by default (if the morph has an event handler) in the same way as other âhandlesâ methods behaves. The default behaviour for Morph event handling is that if an event handler is present for a morphic object it is up to its class to specify which events that uses the event handling mechanism or not. GLMSystemWindow>>#initialize creates an event handler for itself, which then causes the #handlesMouseMove: to return false since it has an event handler, but it does not handle #mouseMove. One solution could be to remove GLMSystemWindow>>#initialize and implement #keyStroke: instead. >>keyStroke: super keyStroke. self handleKeyStroke: evt. Other possible solution could be to implement #handlesMouseMove: in GMLSystemWindow with the logic necessary. Another possibility is to only return early in Morph>>#handlesMouseMove: Iff the event handler has an event registration for #mouseMove. I would go with the first solution, and remove the need for an event handler object in GLMSystemWindow. Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Andrei Chis Sent: Friday, December 4, 2015 4:31 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Cc: Moose-related development <moose-dev(a)list.inf.unibe.ch> Subject: Re: [Pharo-dev] GTDebugger not draggable with latest VM Seems to happen due to the fix in issue 17178<https://pharo.fogbugz.com/f/cases/17178> On Fri, Dec 4, 2015 at 4:21 PM, Andrei Chis <chisvasileandrei(a)gmail.com<mailto:chisvasileandrei@gmail.com>> wrote: Seems that starting with Pharo 50483 one cannot drag the inspector/playground/debugger. No idea what happened. On Fri, Dec 4, 2015 at 3:19 PM, Blondeau Vincent <vincent.blondeau(a)worldline.com<mailto:vincent.blondeau@worldline.com>> wrote: Hi, I have a problem on the latest Moose6.0 image. I was not able to open a Roassal view, I had a NativeBoost Generic failureâ¦ So I updated the VM to last stable, and, now, the GTdebugger and the Moose panel are not draggable anymoreâ¦ Can somebody is able to reproduce the problem? Thanks Cheers, Vincent ________________________________ Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Dec. 4, 2015

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

by Mariano Martinez Peck

OK. But be aware it is very very little tested and probably still a hack, and it still need overrides. Hopefully you will help me to polish it until we get a "SeasidePharoDebugging" package with no override :) All what I mention here is tested in Pharo 4.0 with Seaside 3.1.4.1. These are the steps: 1) Create a ProcessLocalVariable subclass: #WACurrentRequestContextPLV instanceVariableNames: '' classVariableNames: '' category: 'SeasidePharoDebugging' 2) Override GRPharoPlatform >> openDebuggerOn (see highlighted lines) The idea is to simply store the WACurrentRequestContext into a processor local variable before we loose it. openDebuggerOn: anError | process currentRequest | process := Processor activeProcess. currentRequest := WACurrentRequestContext value. "If we are running in the UI process, we don't want to suspend the active process. The error was presumably triggered while stepping in the Debugger. If we simply immediately signal an UnhandledError, the debugger will catch this and display the signaling context. It isn't perfect or pretty but it works." (ProcessBrowser isUIProcess: process) ifTrue: [ UnhandledError signalForException: anError ] ifFalse: [ WorldState addDeferredUIMessage: [ WACurrentRequestContextPLV value: currentRequest. process debug: anError signalerContext title: anError description full: true. ]. process suspend ] 3) Override WACurrentRequestContext class >> defaultValue defaultValue ^ WACurrentRequestContextPLV value ifNil: [ WARequestContextNotFound signal ] 4) Set WADebugErrorHandler as the error handler in your seaside app (I am not sure if this step is needed). And that's all. Try to put a "self whateverMethodThatCausesDNU" and then, try to evalaute something from the debugger that calls #session or #requestContext etc... for example, evaluate "WAComponent new session" and that should work: Besides the overrides I still have doubts: a) do we need WADebugErrorHandler ? b) it seems "Halt halt" does not work but sending a message that causes dnu does work. Maybe related to WADebugErrorHandler. c) what happens if we have multiple debuggers opened? I am worried about the "soleInstance" of ProcessSpecificVariable. Thoughts? Can you tell me if this works for you? On Fri, Dec 4, 2015 at 1:13 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 04 Dec 2015, at 17:11, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > I found a way!!!! Much cleaner and easier. Awesome! > I will clean it, test it a bit more and try to package it for public usage > :) > > > Give me a snippet! I want to play with it! :D > > > On Fri, Dec 4, 2015 at 12:31 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Fri, Dec 4, 2015 at 12:05 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 04 Dec 2015, at 14:29, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> >>> Max...Seaside uses WADynamicVariable (NOT DynamicVariable) which >>> are completely different. WADynamicVariable uses exception mechanism >>> while DynamicVariable uses the ProcessSpecificVariable. >>> But thanks anyway! >>> >>> >>> Oh manâ¦. Sorry :) >>> >>> I wonder, why WADynamicVariable *isnât* a DynamicVariable. The semantics >>> are the same if Iâm not mistaken (e.g. only available in the current >>> process) and I think access to a dynamic variable may even be faster >>> because it *doesnât* use the exception mechanism (i.e. no need to walk down >>> the stack). >>> If someone knows the answer, Iâd be happy to hear it. >>> >>> >> I bet it's because of portability. For example, i remember in GemStone >> the ProcessorLocalVariable did not behave the same as in Pharo. And it was >> actually an experiment. I think you cannot expect all this stuff to be ansi >> (or easily portable), while exceptions do. >> >> >>> Iâve played around with Process>>signalException: and >>> Context>>handleSignal: (which looked quite promising) but didnât get any >>> results. Iâm out of ideas. >>> >>> >> I have played all morning with an idea of using local variables. I arrive >> to the point where I DO HAVE the request context at hand, but I don't find >> an easy way to hook into do-its, print-it etc so that the closure evaluated >> gets the request context plugged. In other ways... let's say I have the >> context stored somewhere. I am at the SmalltalkEditor >> >> evaluateSelectionAndDo: aBlock >> >> and so..somewhere I need to do something like: >> >> WACurrentRequestContext use: self storedContextSomewhere during: [ self >> theSelectionToBeEvaluated ] >> >> and that's where I am now :) >> >> >> >> >>> Cheers, >>> Max >>> >>> >>> On Fri, Dec 4, 2015 at 7:32 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> Hereâs a snippet to play with: >>>> >>>> p := Processor activeProcess. >>>> x := 2. >>>> v := TestDynamicVariable value: x during: [ >>>> ((p instVarNamed: 'env') ifNotNil: [ :env| >>>> env copyWithout: nil ]) inspect >>>> ]. >>>> >>>> ((p instVarNamed: 'env') ifNotNil: [ :env| >>>> env copyWithout: nil ]) inspect >>>> >>>> Cheers, >>>> Max >>>> >>>> On 04 Dec 2015, at 10:47, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>> I feel you :) >>>> >>>> Without having thought this through completely: if you look at the >>>> implementation of DynamicVariable>>value:during: youâll see that the way it >>>> works is that the variable is bound to the active process. In the debugger >>>> you have access to the process that is being debugged and thus you should >>>> have access to the variables bound to it. You could try accessing all such >>>> variables by iterating over them (which I think will require an extension >>>> on Process because youâd need to access at least the PSKeys class variable). >>>> >>>> Cheers, >>>> Max >>>> >>>> On 04 Dec 2015, at 00:34, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>> wrote: >>>> >>>> Hi guys, >>>> >>>> This thing I will ask in this email it's in my mind since YEARS. But I >>>> have always thought it was like that and that there was nothing we could >>>> do. However, I think it's time I ask again :) >>>> >>>> For those that have used Seaside, and you try to debug, you know that >>>> upon request processing seaside uses Exceptions mechanisim to always have >>>> access to the request, session, etc. They way that is done is very smart :) >>>> >>>> WACurrentRequestContext use: self during: aBlock >>>> >>>> In that case, "self" is the request instance and aBlock the closure >>>> that takes care of the request processing. So, inside that closure, >>>> everywhere you do "WACurrentRequestContext value" you get the correct >>>> request instance. >>>> >>>> So..that's great for Seaside, but debugging gets complicated. While you >>>> can restart, proceed, etc, once inside debugger, you cannot evaluate any >>>> piece of code that will use the session or request because you get >>>> a WARequestContextNotFound. Of course, because I guess the evaluation you >>>> do from cmd+d on a piece of text or via the debugger inspector, creates >>>> another closure/context which does not receive the WACurrentRequestContext >>>> instance. >>>> >>>> Now....besides WACurrentRequestContext I have my own class >>>> UserContextInformation where I basically have a bunch of stuff associated >>>> to the logged user. And I do exactly the same as the >>>> WACurrentRequestContext. And I have the same problem. I really want to be >>>> able to fix this. >>>> >>>> Anyone have an idea on how can I do it? I guess I can change the >>>> debugger, in the place where I evaluate code so that I wrap that evaluation >>>> with my request context instance??? >>>> >>>> Thoughts? >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Dec. 4, 2015

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

by Norbert Hartl

> Am 04.12.2015 um 16:05 schrieb Max Leske <maxleske(a)gmail.com>: > > >> On 04 Dec 2015, at 14:29, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> Max...Seaside uses WADynamicVariable (NOT DynamicVariable) which are completely different. WADynamicVariable uses exception mechanism while DynamicVariable uses the ProcessSpecificVariable. >> But thanks anyway! > > Oh manâ¦. Sorry :) > > I wonder, why WADynamicVariable *isnât* a DynamicVariable. The semantics are the same if Iâm not mistaken (e.g. only available in the current process) and I think access to a dynamic variable may even be faster because it *doesnât* use the exception mechanism (i.e. no need to walk down the stack). > If someone knows the answer, Iâd be happy to hear it. > > Iâve played around with Process>>signalException: and Context>>handleSignal: (which looked quite promising) but didnât get any results. Iâm out of ideas. > There was no DynamicVariable in pharo when seaside was created. It has been introduced in pharo3?? There are not fully equivalent so it is hard to say better or not. We had a problem that you cannot access a process specific variable because the debugger forks off. But we introduced a fix from Eliot where the effective process is taken into account. A resumable exception should be available as long as you have access to the whole stack up to the closure for that exception. So should be independent of the process you are in. I cannot recall why this makes problems at all. my 2 cents, Norbert > Cheers, > Max > >> >> On Fri, Dec 4, 2015 at 7:32 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> Hereâs a snippet to play with: >> >> p := Processor activeProcess. >> x := 2. >> v := TestDynamicVariable value: x during: [ >> ((p instVarNamed: 'env') ifNotNil: [ :env| >> env copyWithout: nil ]) inspect >> ]. >> >> ((p instVarNamed: 'env') ifNotNil: [ :env| >> env copyWithout: nil ]) inspect >> >> Cheers, >> Max >> >>> On 04 Dec 2015, at 10:47, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >>> >>> I feel you :) >>> >>> Without having thought this through completely: if you look at the implementation of DynamicVariable>>value:during: youâll see that the way it works is that the variable is bound to the active process. In the debugger you have access to the process that is being debugged and thus you should have access to the variables bound to it. You could try accessing all such variables by iterating over them (which I think will require an extension on Process because youâd need to access at least the PSKeys class variable). >>> >>> Cheers, >>> Max >>> >>>> On 04 Dec 2015, at 00:34, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>> >>>> Hi guys, >>>> >>>> This thing I will ask in this email it's in my mind since YEARS. But I have always thought it was like that and that there was nothing we could do. However, I think it's time I ask again :) >>>> >>>> For those that have used Seaside, and you try to debug, you know that upon request processing seaside uses Exceptions mechanisim to always have access to the request, session, etc. They way that is done is very smart :) >>>> >>>> WACurrentRequestContext use: self during: aBlock >>>> >>>> In that case, "self" is the request instance and aBlock the closure that takes care of the request processing. So, inside that closure, everywhere you do "WACurrentRequestContext value" you get the correct request instance. >>>> >>>> So..that's great for Seaside, but debugging gets complicated. While you can restart, proceed, etc, once inside debugger, you cannot evaluate any piece of code that will use the session or request because you get a WARequestContextNotFound. Of course, because I guess the evaluation you do from cmd+d on a piece of text or via the debugger inspector, creates another closure/context which does not receive the WACurrentRequestContext instance. >>>> >>>> Now....besides WACurrentRequestContext I have my own class UserContextInformation where I basically have a bunch of stuff associated to the logged user. And I do exactly the same as the WACurrentRequestContext. And I have the same problem. I really want to be able to fix this. >>>> >>>> Anyone have an idea on how can I do it? I guess I can change the debugger, in the place where I evaluate code so that I wrap that evaluation with my request context instance??? >>>> >>>> Thoughts? >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >>> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >

Dec. 4, 2015

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

by Max Leske

> On 04 Dec 2015, at 17:11, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > I found a way!!!! Much cleaner and easier. Awesome! > I will clean it, test it a bit more and try to package it for public usage :) Give me a snippet! I want to play with it! :D > > On Fri, Dec 4, 2015 at 12:31 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > > On Fri, Dec 4, 2015 at 12:05 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> On 04 Dec 2015, at 14:29, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> Max...Seaside uses WADynamicVariable (NOT DynamicVariable) which are completely different. WADynamicVariable uses exception mechanism while DynamicVariable uses the ProcessSpecificVariable. >> But thanks anyway! > > Oh manâ¦. Sorry :) > > I wonder, why WADynamicVariable *isnât* a DynamicVariable. The semantics are the same if Iâm not mistaken (e.g. only available in the current process) and I think access to a dynamic variable may even be faster because it *doesnât* use the exception mechanism (i.e. no need to walk down the stack). > If someone knows the answer, Iâd be happy to hear it. > > > I bet it's because of portability. For example, i remember in GemStone the ProcessorLocalVariable did not behave the same as in Pharo. And it was actually an experiment. I think you cannot expect all this stuff to be ansi (or easily portable), while exceptions do. > > Iâve played around with Process>>signalException: and Context>>handleSignal: (which looked quite promising) but didnât get any results. Iâm out of ideas. > > > I have played all morning with an idea of using local variables. I arrive to the point where I DO HAVE the request context at hand, but I don't find an easy way to hook into do-its, print-it etc so that the closure evaluated gets the request context plugged. In other ways... let's say I have the context stored somewhere. I am at the SmalltalkEditor >> evaluateSelectionAndDo: aBlock > > and so..somewhere I need to do something like: > > WACurrentRequestContext use: self storedContextSomewhere during: [ self theSelectionToBeEvaluated ] > > and that's where I am now :) > > > > Cheers, > Max > >> >> On Fri, Dec 4, 2015 at 7:32 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> Hereâs a snippet to play with: >> >> p := Processor activeProcess. >> x := 2. >> v := TestDynamicVariable value: x during: [ >> ((p instVarNamed: 'env') ifNotNil: [ :env| >> env copyWithout: nil ]) inspect >> ]. >> >> ((p instVarNamed: 'env') ifNotNil: [ :env| >> env copyWithout: nil ]) inspect >> >> Cheers, >> Max >> >>> On 04 Dec 2015, at 10:47, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >>> >>> I feel you :) >>> >>> Without having thought this through completely: if you look at the implementation of DynamicVariable>>value:during: youâll see that the way it works is that the variable is bound to the active process. In the debugger you have access to the process that is being debugged and thus you should have access to the variables bound to it. You could try accessing all such variables by iterating over them (which I think will require an extension on Process because youâd need to access at least the PSKeys class variable). >>> >>> Cheers, >>> Max >>> >>>> On 04 Dec 2015, at 00:34, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>> >>>> Hi guys, >>>> >>>> This thing I will ask in this email it's in my mind since YEARS. But I have always thought it was like that and that there was nothing we could do. However, I think it's time I ask again :) >>>> >>>> For those that have used Seaside, and you try to debug, you know that upon request processing seaside uses Exceptions mechanisim to always have access to the request, session, etc. They way that is done is very smart :) >>>> >>>> WACurrentRequestContext use: self during: aBlock >>>> >>>> In that case, "self" is the request instance and aBlock the closure that takes care of the request processing. So, inside that closure, everywhere you do "WACurrentRequestContext value" you get the correct request instance. >>>> >>>> So..that's great for Seaside, but debugging gets complicated. While you can restart, proceed, etc, once inside debugger, you cannot evaluate any piece of code that will use the session or request because you get a WARequestContextNotFound. Of course, because I guess the evaluation you do from cmd+d on a piece of text or via the debugger inspector, creates another closure/context which does not receive the WACurrentRequestContext instance. >>>> >>>> Now....besides WACurrentRequestContext I have my own class UserContextInformation where I basically have a bunch of stuff associated to the logged user. And I do exactly the same as the WACurrentRequestContext. And I have the same problem. I really want to be able to fix this. >>>> >>>> Anyone have an idea on how can I do it? I guess I can change the debugger, in the place where I evaluate code so that I wrap that evaluation with my request context instance??? >>>> >>>> Thoughts? >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >>> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 4, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Max Leske

> On 04 Dec 2015, at 01:49, Ben Coman <btc(a)openInWorld.com> wrote: > > On Fri, Dec 4, 2015 at 4:23 AM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >> >> >> 2015-12-03 14:48 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>> >>> On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>>> >>>>> On 02 Dec 2015, at 15:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>> >>>>> >>>>> >>>>> 2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>>>> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>>> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> wrote: >>>>>>> >>>>>>> @Doru >>>>>>> Youâre missing the point: #anyOne *fails* for empty collections. >>>>>> >>>>>> I am not missing the point at all. I am saying that if you want sum: >>>>>> to be generic, it cannot assume a specific Zero object. >>>>>> >>>>>> And sum: should be generic because of its name. >>>>> >>>>> I am missing understanding the other use cases. Can you describe >>>>> further the generic nature of #sum & #sum: ? I would have thought by >>>>> default they only applied to numbers. >>>>> >>>>> sum can be applied to anything that supports #+, not only numbers >>>>> sum: can be applied to any collection with a block that return some >>>>> object that supports #+ >>> >>> To me this is a mis-application of polymorphism, that just because >>> something responds to #+ it should be summable. We have overloaded the >>> semantics of #+ to mean both numeric addition and >>> concatenation/membership, but technically "summation" relates only to >>> numeric addition. I agree. If I want to sum something other than a collection of numbers Iâll happily provide the block for that summation (I wouldnât even expect strings to be summable to be honest. Why would you have a collection of numbers that are stringsâ¦? And if you really have one, you should convert it explicitly so that another person reading your code knows whatâs going on.) >> >> >> I didn't wanted to argue for or against any change. I just wanted to clarify >> that there are situations in which a generic sum/sum: that throws an error >> on empty collections and don't assume a null value makes sense. >> >> >>> >>> >>> https://www.google.com.au/search?q=define+sum&oq=define+sum >>> >>> https://www.google.com.au/search?q=define+concatenate&oq=define+concatenate >>> >>> For example... >>> >>> * KMModifier implements #+ so what is the expected semantic of " { >>> KMModifier shift . KMModifier meta} sum " ? >>> To me this is more of a concatenation/join/union facility rather than >>> numeric addition. (btw, that expression actually fails since >>> KMModifier does not understand minus #- ) . >>> >>> * String implements #+ and " { '1' . '2' } sum " --> '3', so >>> actually its doing numeric addition. However " { 'a' . 'b' } sum " >>> produces an error. >>> >>> So actually there seem some existing problems with summing >>> non-numerics. What examples work? >>> >>> * Trait classes implement both #+ and #- , but the semantic seems >>> more to do with membership than numeric addition. I don't how how to >>> produce an example of using #sum against traits. >>> >>> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + >>> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not >>> cause any error in this case. >>> >>> >>> cheers -ben >>> >>> >>>>> >>>>> therefore you can not assume 0 (<- a number) is a proper initial value >>>>> therefore you *need* to work with #anyOne >>>>> and as you can not assume a proper initial value, you can not assume a >>>>> default value for empty collections >>>>> -> it should throw an error. If you (the caller of the function) knows >>>>> what to do with an empty collection you have >>>>> to check, or call inject:into: directly, with a proper initial value. >>>> >>>> I am sorry but I am getting really tired of this, you should read what >>>> is being said. >> >> >> do that change, I am not against it. Ben just asked for an example and I >> thought it would be helpful. > > It was helpful :) It evolved my thinking. Now thinking further, I > wonder how returning 0 will work with applications using units like > Aconcagua, and if it would over-complicate things to do something > like... > > Collection>>sum > | sum sample | > self isEmpty ifTrue: [ ^ ArithmeticZero ]. > sample := self anyOne. > sum := self inject: sample into: [ :accum :each | accum + each ]. > ^ sum - sample > > ArithmeticZero class >> + anObject > ^anObject While I think you might be on to something, I think we should take small steps. Iâd be happy already if we can just get rid of one superfluous method and provide a better API without starting to think about the deeper semantics. Also, I think thereâs a reason why Aconcagua is an external package: developers usually are happy to work with numbers (which are already objects in Smalltalk anyway) and theyâre fast. > > cheers -ben > >> >> >>> >>>> >>>> I am not suggesting to stop using #anyOne because I like why it is there >>>> and what it can do. >>>> >>>> The change I want is what happens with an empty collection when using >>>> the simplest selector, #sum. >>>> >>>> I do not want to say to some collection of numbers #sumIfEmpty: [0], >>>> because summing numbers starting from zero is the most common case and >>>> everybody expects that, hence the unary selector fits. >>>> >>>> I want the less common cases to use the more complicated API, as in some >>>> collection of colors #sumIfEmpty: [ Color black ] >>>> >>>> In my book that is common sense API design. >>>> >>>> Doing that I do no take anything away, because today you already have to >>>> make sure the collection is not empty. >>>> >>>> The only change would be in the error behaviour. I think that is a >>>> reasonable price to pay. Instead of having #anyOne fail, it will say that #+ >>>> cannot add 0 to some object, and in a comment we can point to the >>>> alternative API. >> >> >> >> >>> >>>> >>>> http://izquotes.com/quote/242740 right ? >>>> >>>>> cheers -ben >>>>> >>>>>> >>>>>>>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo >>>>>>>> <emaringolo(a)gmail.com> wrote: >>>>>>>> >>>>>>>> I don't want to be heretic (or too orthodox), but why not to >>>>>>>> delegate >>>>>>>> this behavior to other class (an iterator maybe?). >>>>>>>> >>>>>>>> It's too tempting adding these convenience methods to Collection >>>>>>>> and/or subclasses, but anything that requires an explicit protocol >>>>>>>> of >>>>>>>> its elements is wrong, IMO. >>>>>>>> >>>>>>>> something like aCollection arithmetic sum: [...] or.... aCollection >>>>>>>> arithmetic avg. > > > On Fri, Dec 4, 2015 at 3:26 AM, Chris Cunningham > <cunningham.cb(a)gmail.com <mailto:cunningham.cb@gmail.com>> wrote: >> <uncontrolled snipping> >> >> On Thu, Dec 3, 2015 at 5:48 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + >>> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not >>> cause any error in this case. >> >> but points aren't commutative: >> >> 2@2 + 1 " = 3@3" >> 1 + 2@2 " = 3@2" >> >> Of course, 0 wouldn't be an issue, unless you wanted to access x or y!

Dec. 4, 2015