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

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

by Mariano Martinez Peck

On Fri, Dec 11, 2015 at 12:51 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 11 Dec 2015, at 16:39, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > On Fri, Dec 11, 2015 at 12:25 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 10 Dec 2015, at 21:21, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> >> >> On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> >>> >>> On Thu, Dec 10, 2015 at 7:27 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> >>>> On 07 Dec 2015, at 17:17, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>> wrote: >>>> >>>> OK Max. In the last version you can find the "likely" final version. >>>> It's extremely simple, easy to use, and very very little code. Only one >>>> override. All WADynamicVariables subclasses handled automatically. All you >>>> need to do is to register the handler: >>>> >>>> app filter configuration at: #exceptionHandler put: >>>> WAPharoDebuggererErrorHandler. >>>> >>>> It works for exceptions and both Halt too. The only limit is only the >>>> "last opened debugger" will be correct and all previous will be wrong since >>>> they will be using another values for dynamic variables. >>>> >>>> I will see if people want to integrate this directly into Seaside. >>>> >>>> >>>> Very nice! And since you provide a separate error handler itâs easy to >>>> integrate into seaside too by simply adding it to the handler chain. >>>> >>>> >>> Exactly. The only issue to fix is the override in WADynamicVariable >> >>> defaultAction. >>> And that's not easy. Why? Because at that level, we know nothing about >>> the current seaside app or anything. We don't know which seaside app those >>> signal came from. Of course, I can still do the check to the handler to see >>> if that has that variable stored. But... What if now you have set another >>> error handler? Or what about OTHER possible registered apps which use a >>> different error handler. >>> Thoughts? I have some HACKS in mind, but they are hacks and none solves >>> all problems. And only for Pharo. >>> Any idea to solve this would be nice. >>> >>> >> Assuming you are using GTDebugger (should be very easy to adapt for >> normal debugger), we can do this: >> >> defaultAction >> " This is an override from SeasidePharoDebugging because before raising a >> signal we >> first check if we have the value stored. That way, everywhere >> we evaluate code in a debugger that end ups doing >> 'WACurrentRequestContext value' will simply >> get up to this place. Since in WAPharoDebuggererErrorHandler >> #open: we >> stored the dynamic variables, we should have the value " >> | openedSeasideErrorDebuggers | >> *openedSeasideErrorDebuggers := ((UIManager default currentWorld >> submorphs select: [ :each | each model isKindOf: GTGenericStackDebugger ]) * >> * collect: [ :each | each model ]) * >> * select: [ :each2 | (each2 session interruptedProcess suspendedContext >> method selector = #openDebuggerOn:)* >> * and: (each2 session interruptedProcess suspendedContext sender receiver >> class = WADynamicVariablesErrorHandler) ].* >> ^ openedSeasideErrorDebuggers >> ifEmpty: [ self class defaultValue ] >> ifNotEmpty: [ >> (WADynamicVariablesErrorHandler storedDynamicVariable: self class) >> ifNil: [ self class defaultValue ] >> ] >> >> But that..the only thing it solves is that we would not be getting the >> value of dynamic variables from previous errors if there is none debugger >> opened from a seaside continuation. If you let a debugger opened debugging >> a seaside error, then there is no magic we can do I think. >> Imagine you were in a debugger and you evaluated: "WAComponent new >> session". The signal raised from there knows NOTHING about the debugger >> where that was evaluated... so at #defaultAction level you know nothing >> about what triggered that. >> >> The only thing to solve this would be to hook into the do-it, print it, >> inspect etc...too complicated. >> >> >> Thoughts? >> >> >> I think youâre solution is already pretty good. I wouldnât really care if >> multiple debuggers are a problem. Evaluating a piece of code in context of >> the dynamic variables is already a lot of help. Although, if you donât know >> that youâre seeing a different session / request, thatâs bad... >> >> I do have one idea but it might be a bit more complicated and is not >> Seaside specific: if we could attach the context of the evaluation to the >> suspended context, the handler search should automatically yield the >> correct handlers for the dynamic variables (although I donât know exactly >> how the VM resolves the handlers). Alternatively, instead of attaching the >> whole stack, it would suffice to copy the handler contexts and attach them >> to the evaluation context. Both approaches would also solve the problem of >> multiple debuggers. >> > > Yes, I have thought about doing something similar. In GemStone for > example, there is another possibility since it allows global static handler > for exceptions. So for example you can say install a block to be executed > when nobody handled exception XXX. And that closure execution is BEFORE the > #defaultAction. So for example in this case I would be able to do that > without the override in WADynamicVariable >> defaultAction. > mmmmm I am not 100% sure about what I said about GemStone hahahaha. > > > Intersting. But wouldnât you have the same problem with multiple > debuggers? Theyâd all use the same global handler, wouldnât they? > > Yes. But I would solve the override :) > > >> For this to work the debugger would need highjack the evaluation of code >> e.g. by using a custom code editor. >> > > Exactly. We would need to hook on everything: print it, do it, debug it, > inspect etc. Maybe at the first level is not that hard (say at debugger > level). But imagine you do a "self session inspect". But then, once inside > the inspector, you can inspect other objects and open other inspectors, > evaluate another piece of code etc... and so the scope would end up in the > first level. > > > Yes, right. Thatâs a problem, although what I usually do is inspect the > session and then use the session in a new handler context to run my code: > > WASession use: self during: [ â¦ ] > Indeed, that works. But again, works only inside that closure. So if you want to open a new inspector, or given the same inspector navigate other objects, then execute or or then type something in a playground etc, you are out of context. Each code evaluation will have it's own new context. So you would need to type above code every time you need that. But at least we agree in the pros and cons of each solution :) > > Thus I donât care too much about what happens outside of the debugger. Of > course, not everyone understands the session handling mechanism, so itâs > probably not the solution for everyone. Still, having access to dynamic > variables *at least* in the debugger, is already a big improvement in > itself. We donât need to rethink everything. > > Well...I think I personally prefer to have it accessible everywhere (even outside the debugger) with the known limitations (that we have discussed many times). But tastes are tastes :) If you prefer only at debugger level, allow multiple debugger, etc... and if you use GT Debugger it looked not so hard to hook into code execution. But make sure you are able to first make the "backend" support (copy exception handlers from suspended process to the new process result of evaluation). > > With current approach we simply propagate the values to everybody , > everywhere. But it's also nice to be able to inspect, explore etc from > anywhere and you know you will be dealing with the context of the last > debugger :) I mean, you can do anything in the image and you will be > dealing with the last debug error context :) > So I think that even both approaches have advantages and disadvantages, > right? > > >> The cool thing about this would be that every evaluation would run in the >> same exception handling contexts as the original process. >> The bad thing is of course that in some situations you actually donât >> care (or want to care) about those handlers (e.g. when you want to trigger >> an exception explicitly during evaluation and donât want it to be swallowed >> by the exception handlers). >> >> Iâve CCâed Andrei because he knows more about UI <-> Debugger >> interaction. Maybe he has an idea how to do this. >> >> > OK, Thanks. > >> >> >> >> >>> >>> >>>> Two tiny things: >>>> - youâre not using the #reset method you wrote but instead manually >>>> assign nil to the variable >>>> >>> >>> yes, thanks. >>> >>> >>>> - I guess the dictionary in the handler could be a SmallDictionary. >>>> There wonât be many entries. >>>> >>>> >>> Well..since there will be likely.. less than 10 entries I don't care >>> which Dictionary to use. However, I would prefer to keep Dictionary. Or if >>> not GRSmallDictionary. >>> >>> >>>> Thanks a lot for this. Iâll probably port this back to Seaside 2.8 so I >>>> can use it too :) >>>> >>> >>> No problem. Thanks for reviewing and give feedback. >>> >>> >>> >>>> >>>> On Sat, Dec 5, 2015 at 11:36 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>>> >>>>> On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>> wrote: >>>>> >>>>> Can you try with the latest version that does not use LPC if it works? >>>>> >>>>> >>>>> Works perfectly! >>>>> >>>> >>>> >>>> >>>> -- >>>> 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. 11, 2015

Re: [Pharo-dev] CompilationContext class>>initialize

by Marcus Denker

they donâtâ¦ I think that is a leftover from back when we had some rule or automatic suggestion to add the âsuper initializeâ, which is wrong on the class side. > On 11 Dec 2015, at 16:55, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Why do CompilationContext and CCompilationContext need super initialize in class side initialize? > > Stephan > >

Dec. 11, 2015

CompilationContext class>>initialize

by Stephan Eggermont

Why do CompilationContext and CCompilationContext need super initialize in class side initialize? Stephan

Dec. 11, 2015

Re: [Pharo-dev] Some GT tool for this?

by Eliot Miranda

Hi Mariano, for this in Squeak I added a simple menu pick to the Monticello Browser's package list menu called "search history" which opens up a workspace containing the entire history as a flat string. I then just search using ctrl-f. You can find it in a current squeak trunk image. _,,,^..^,,,_ (phone) > On Dec 10, 2015, at 9:12 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > How many times have you tried to search a string as a comment of a commit in all the history? Myself: many many times. I know we need much better tools for that, store the history in a another way, provide a nicer API, etc etc. And I know there were topics about that. > > However, I would deeply appreciate a very short term solution for ease that. The model side is as simple as this: > > | packageName ancestry anscestors substring | > packageName := 'MyPackageXX'. > substring := 'whatever I want to search'. > ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName = packageName] ) ancestry. > anscestors := ancestry withBreadthFirstAncestors select: [:each | each isKindOf: MCVersionInfo]. > anscestors select: [ :each | each message includesSubstring: substring ] > > Do you think it's worth a simple UI tool? Custom inspector of MCAncestry? > > Cheers, > > > -- > Mariano > http://marianopeck.wordpress.com

Dec. 11, 2015

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

by Max Leske

> On 11 Dec 2015, at 16:39, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Fri, Dec 11, 2015 at 12:25 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> On 10 Dec 2015, at 21:21, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> >> >> On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> >> On Thu, Dec 10, 2015 at 7:27 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> >>> On 07 Dec 2015, at 17:17, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>> >>> OK Max. In the last version you can find the "likely" final version. It's extremely simple, easy to use, and very very little code. Only one override. All WADynamicVariables subclasses handled automatically. All you need to do is to register the handler: >>> >>> app filter configuration at: #exceptionHandler put: WAPharoDebuggererErrorHandler. >>> >>> It works for exceptions and both Halt too. The only limit is only the "last opened debugger" will be correct and all previous will be wrong since they will be using another values for dynamic variables. >>> >>> I will see if people want to integrate this directly into Seaside. >> >> Very nice! And since you provide a separate error handler itâs easy to integrate into seaside too by simply adding it to the handler chain. >> >> >> Exactly. The only issue to fix is the override in WADynamicVariable >> defaultAction. >> And that's not easy. Why? Because at that level, we know nothing about the current seaside app or anything. We don't know which seaside app those signal came from. Of course, I can still do the check to the handler to see if that has that variable stored. But... What if now you have set another error handler? Or what about OTHER possible registered apps which use a different error handler. >> Thoughts? I have some HACKS in mind, but they are hacks and none solves all problems. And only for Pharo. >> Any idea to solve this would be nice. >> >> >> Assuming you are using GTDebugger (should be very easy to adapt for normal debugger), we can do this: >> >> defaultAction >> " This is an override from SeasidePharoDebugging because before raising a signal we >> first check if we have the value stored. That way, everywhere >> we evaluate code in a debugger that end ups doing 'WACurrentRequestContext value' will simply >> get up to this place. Since in WAPharoDebuggererErrorHandler >> #open: we >> stored the dynamic variables, we should have the value " >> | openedSeasideErrorDebuggers | >> openedSeasideErrorDebuggers := ((UIManager default currentWorld submorphs select: [ :each | each model isKindOf: GTGenericStackDebugger ]) >> collect: [ :each | each model ]) >> select: [ :each2 | (each2 session interruptedProcess suspendedContext method selector = #openDebuggerOn:) >> and: (each2 session interruptedProcess suspendedContext sender receiver class = WADynamicVariablesErrorHandler) ]. >> ^ openedSeasideErrorDebuggers >> ifEmpty: [ self class defaultValue ] >> ifNotEmpty: [ >> (WADynamicVariablesErrorHandler storedDynamicVariable: self class) >> ifNil: [ self class defaultValue ] >> ] >> >> >> But that..the only thing it solves is that we would not be getting the value of dynamic variables from previous errors if there is none debugger opened from a seaside continuation. If you let a debugger opened debugging a seaside error, then there is no magic we can do I think. >> Imagine you were in a debugger and you evaluated: "WAComponent new session". The signal raised from there knows NOTHING about the debugger where that was evaluated... so at #defaultAction level you know nothing about what triggered that. >> >> The only thing to solve this would be to hook into the do-it, print it, inspect etc...too complicated. >> >> >> Thoughts? > > I think youâre solution is already pretty good. I wouldnât really care if multiple debuggers are a problem. Evaluating a piece of code in context of the dynamic variables is already a lot of help. Although, if you donât know that youâre seeing a different session / request, thatâs bad... > > I do have one idea but it might be a bit more complicated and is not Seaside specific: if we could attach the context of the evaluation to the suspended context, the handler search should automatically yield the correct handlers for the dynamic variables (although I donât know exactly how the VM resolves the handlers). Alternatively, instead of attaching the whole stack, it would suffice to copy the handler contexts and attach them to the evaluation context. Both approaches would also solve the problem of multiple debuggers. > > Yes, I have thought about doing something similar. In GemStone for example, there is another possibility since it allows global static handler for exceptions. So for example you can say install a block to be executed when nobody handled exception XXX. And that closure execution is BEFORE the #defaultAction. So for example in this case I would be able to do that without the override in WADynamicVariable >> defaultAction. > mmmmm I am not 100% sure about what I said about GemStone hahahaha. Intersting. But wouldnât you have the same problem with multiple debuggers? Theyâd all use the same global handler, wouldnât they? > > > For this to work the debugger would need highjack the evaluation of code e.g. by using a custom code editor. > > Exactly. We would need to hook on everything: print it, do it, debug it, inspect etc. Maybe at the first level is not that hard (say at debugger level). But imagine you do a "self session inspect". But then, once inside the inspector, you can inspect other objects and open other inspectors, evaluate another piece of code etc... and so the scope would end up in the first level. Yes, right. Thatâs a problem, although what I usually do is inspect the session and then use the session in a new handler context to run my code: WASession use: self during: [ â¦ ] Thus I donât care too much about what happens outside of the debugger. Of course, not everyone understands the session handling mechanism, so itâs probably not the solution for everyone. Still, having access to dynamic variables *at least* in the debugger, is already a big improvement in itself. We donât need to rethink everything. > > With current approach we simply propagate the values to everybody , everywhere. But it's also nice to be able to inspect, explore etc from anywhere and you know you will be dealing with the context of the last debugger :) I mean, you can do anything in the image and you will be dealing with the last debug error context :) > So I think that even both approaches have advantages and disadvantages, right? > > The cool thing about this would be that every evaluation would run in the same exception handling contexts as the original process. > The bad thing is of course that in some situations you actually donât care (or want to care) about those handlers (e.g. when you want to trigger an exception explicitly during evaluation and donât want it to be swallowed by the exception handlers). > > Iâve CCâed Andrei because he knows more about UI <-> Debugger interaction. Maybe he has an idea how to do this. > > > OK, Thanks. >> >> >> >> >> Two tiny things: >> - youâre not using the #reset method you wrote but instead manually assign nil to the variable >> >> yes, thanks. >> >> - I guess the dictionary in the handler could be a SmallDictionary. There wonât be many entries. >> >> >> Well..since there will be likely.. less than 10 entries I don't care which Dictionary to use. However, I would prefer to keep Dictionary. Or if not GRSmallDictionary. >> >> Thanks a lot for this. Iâll probably port this back to Seaside 2.8 so I can use it too :) >> >> No problem. Thanks for reviewing and give feedback. >> >> >>> >>> >>> On Sat, Dec 5, 2015 at 11:36 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >>> >>>> On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>> >>>> Can you try with the latest version that does not use LPC if it works? >>> >>> Works perfectly! >>> >>> >>> >>> -- >>> 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. 11, 2015

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

by Mariano Martinez Peck

On Fri, Dec 11, 2015 at 12:25 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 10 Dec 2015, at 21:21, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Thu, Dec 10, 2015 at 7:27 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 07 Dec 2015, at 17:17, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> >>> OK Max. In the last version you can find the "likely" final version. >>> It's extremely simple, easy to use, and very very little code. Only one >>> override. All WADynamicVariables subclasses handled automatically. All you >>> need to do is to register the handler: >>> >>> app filter configuration at: #exceptionHandler put: >>> WAPharoDebuggererErrorHandler. >>> >>> It works for exceptions and both Halt too. The only limit is only the >>> "last opened debugger" will be correct and all previous will be wrong since >>> they will be using another values for dynamic variables. >>> >>> I will see if people want to integrate this directly into Seaside. >>> >>> >>> Very nice! And since you provide a separate error handler itâs easy to >>> integrate into seaside too by simply adding it to the handler chain. >>> >>> >> Exactly. The only issue to fix is the override in WADynamicVariable >> >> defaultAction. >> And that's not easy. Why? Because at that level, we know nothing about >> the current seaside app or anything. We don't know which seaside app those >> signal came from. Of course, I can still do the check to the handler to see >> if that has that variable stored. But... What if now you have set another >> error handler? Or what about OTHER possible registered apps which use a >> different error handler. >> Thoughts? I have some HACKS in mind, but they are hacks and none solves >> all problems. And only for Pharo. >> Any idea to solve this would be nice. >> >> > Assuming you are using GTDebugger (should be very easy to adapt for normal > debugger), we can do this: > > defaultAction > " This is an override from SeasidePharoDebugging because before raising a > signal we > first check if we have the value stored. That way, everywhere > we evaluate code in a debugger that end ups doing 'WACurrentRequestContext > value' will simply > get up to this place. Since in WAPharoDebuggererErrorHandler >> #open: we > stored the dynamic variables, we should have the value " > | openedSeasideErrorDebuggers | > *openedSeasideErrorDebuggers := ((UIManager default currentWorld submorphs > select: [ :each | each model isKindOf: GTGenericStackDebugger ]) * > * collect: [ :each | each model ]) * > * select: [ :each2 | (each2 session interruptedProcess suspendedContext > method selector = #openDebuggerOn:)* > * and: (each2 session interruptedProcess suspendedContext sender receiver > class = WADynamicVariablesErrorHandler) ].* > ^ openedSeasideErrorDebuggers > ifEmpty: [ self class defaultValue ] > ifNotEmpty: [ > (WADynamicVariablesErrorHandler storedDynamicVariable: self class) > ifNil: [ self class defaultValue ] > ] > > But that..the only thing it solves is that we would not be getting the > value of dynamic variables from previous errors if there is none debugger > opened from a seaside continuation. If you let a debugger opened debugging > a seaside error, then there is no magic we can do I think. > Imagine you were in a debugger and you evaluated: "WAComponent new > session". The signal raised from there knows NOTHING about the debugger > where that was evaluated... so at #defaultAction level you know nothing > about what triggered that. > > The only thing to solve this would be to hook into the do-it, print it, > inspect etc...too complicated. > > > Thoughts? > > > I think youâre solution is already pretty good. I wouldnât really care if > multiple debuggers are a problem. Evaluating a piece of code in context of > the dynamic variables is already a lot of help. Although, if you donât know > that youâre seeing a different session / request, thatâs bad... > > I do have one idea but it might be a bit more complicated and is not > Seaside specific: if we could attach the context of the evaluation to the > suspended context, the handler search should automatically yield the > correct handlers for the dynamic variables (although I donât know exactly > how the VM resolves the handlers). Alternatively, instead of attaching the > whole stack, it would suffice to copy the handler contexts and attach them > to the evaluation context. Both approaches would also solve the problem of > multiple debuggers. > Yes, I have thought about doing something similar. In GemStone for example, there is another possibility since it allows global static handler for exceptions. So for example you can say install a block to be executed when nobody handled exception XXX. And that closure execution is BEFORE the #defaultAction. So for example in this case I would be able to do that without the override in WADynamicVariable >> defaultAction. mmmmm I am not 100% sure about what I said about GemStone hahahaha. > For this to work the debugger would need highjack the evaluation of code > e.g. by using a custom code editor. > Exactly. We would need to hook on everything: print it, do it, debug it, inspect etc. Maybe at the first level is not that hard (say at debugger level). But imagine you do a "self session inspect". But then, once inside the inspector, you can inspect other objects and open other inspectors, evaluate another piece of code etc... and so the scope would end up in the first level. With current approach we simply propagate the values to everybody , everywhere. But it's also nice to be able to inspect, explore etc from anywhere and you know you will be dealing with the context of the last debugger :) I mean, you can do anything in the image and you will be dealing with the last debug error context :) So I think that even both approaches have advantages and disadvantages, right? > The cool thing about this would be that every evaluation would run in the > same exception handling contexts as the original process. > The bad thing is of course that in some situations you actually donât care > (or want to care) about those handlers (e.g. when you want to trigger an > exception explicitly during evaluation and donât want it to be swallowed by > the exception handlers). > > Iâve CCâed Andrei because he knows more about UI <-> Debugger interaction. > Maybe he has an idea how to do this. > > OK, Thanks. > > > > >> >> >>> Two tiny things: >>> - youâre not using the #reset method you wrote but instead manually >>> assign nil to the variable >>> >> >> yes, thanks. >> >> >>> - I guess the dictionary in the handler could be a SmallDictionary. >>> There wonât be many entries. >>> >>> >> Well..since there will be likely.. less than 10 entries I don't care >> which Dictionary to use. However, I would prefer to keep Dictionary. Or if >> not GRSmallDictionary. >> >> >>> Thanks a lot for this. Iâll probably port this back to Seaside 2.8 so I >>> can use it too :) >>> >> >> No problem. Thanks for reviewing and give feedback. >> >> >> >>> >>> On Sat, Dec 5, 2015 at 11:36 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> >>>> On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>> wrote: >>>> >>>> Can you try with the latest version that does not use LPC if it works? >>>> >>>> >>>> Works perfectly! >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Dec. 11, 2015

Re: [Pharo-dev] Unicode Support

by Richard Sargent

EuanM wrote > ... > all ISO-8859-1 maps 1:1 to Unicode UTF-8 > ... I am late coming in to this conversation. If it hasn't already been said, please do not conflate Unicode and UTF-8. I think that would be a recipe for a high P.I.T.A. factor. Unicode defines the meaning of the code points. UTF-8 (and -16) define an interchange mechanism. In other words, when you write the code points to an external medium (socket, file, whatever), encode them via UTF-whatever. Read UTF-whatever from an external medium and re-instantiate the code points. (Personally, I see no use for UTF-16 as an interchange mechanism. Others may have justification for it. I don't.) Having characters be a consistent size in their object representation makes everything easier. #at:, #indexOf:, #includes: ... no one wants to be scanning through bytes representing variable sized characters. Model Unicode strings using classes such as e.g. Unicode7, Unicode16, and Unicode32, with automatic coercion to the larger character width. -- View this message in context: http://forum.world.st/Unicode-Support-tp4865139p4866610.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 11, 2015

Re: [Pharo-dev] Why Zinc servers implemented with options dictionary instead of normal instance variables?

by Denis Kudriashov

2015-12-11 15:51 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Because there are many options, 10, 20, and at that time slots were not > yet available. > Is not it is same case as class with 20 variables which always smell bad?

Dec. 11, 2015

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

by Max Leske

> On 10 Dec 2015, at 21:21, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > > On Thu, Dec 10, 2015 at 7:27 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> On 07 Dec 2015, at 17:17, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> OK Max. In the last version you can find the "likely" final version. It's extremely simple, easy to use, and very very little code. Only one override. All WADynamicVariables subclasses handled automatically. All you need to do is to register the handler: >> >> app filter configuration at: #exceptionHandler put: WAPharoDebuggererErrorHandler. >> >> It works for exceptions and both Halt too. The only limit is only the "last opened debugger" will be correct and all previous will be wrong since they will be using another values for dynamic variables. >> >> I will see if people want to integrate this directly into Seaside. > > Very nice! And since you provide a separate error handler itâs easy to integrate into seaside too by simply adding it to the handler chain. > > > Exactly. The only issue to fix is the override in WADynamicVariable >> defaultAction. > And that's not easy. Why? Because at that level, we know nothing about the current seaside app or anything. We don't know which seaside app those signal came from. Of course, I can still do the check to the handler to see if that has that variable stored. But... What if now you have set another error handler? Or what about OTHER possible registered apps which use a different error handler. > Thoughts? I have some HACKS in mind, but they are hacks and none solves all problems. And only for Pharo. > Any idea to solve this would be nice. > > > Assuming you are using GTDebugger (should be very easy to adapt for normal debugger), we can do this: > > defaultAction > " This is an override from SeasidePharoDebugging because before raising a signal we > first check if we have the value stored. That way, everywhere > we evaluate code in a debugger that end ups doing 'WACurrentRequestContext value' will simply > get up to this place. Since in WAPharoDebuggererErrorHandler >> #open: we > stored the dynamic variables, we should have the value " > | openedSeasideErrorDebuggers | > openedSeasideErrorDebuggers := ((UIManager default currentWorld submorphs select: [ :each | each model isKindOf: GTGenericStackDebugger ]) > collect: [ :each | each model ]) > select: [ :each2 | (each2 session interruptedProcess suspendedContext method selector = #openDebuggerOn:) > and: (each2 session interruptedProcess suspendedContext sender receiver class = WADynamicVariablesErrorHandler) ]. > ^ openedSeasideErrorDebuggers > ifEmpty: [ self class defaultValue ] > ifNotEmpty: [ > (WADynamicVariablesErrorHandler storedDynamicVariable: self class) > ifNil: [ self class defaultValue ] > ] > > > But that..the only thing it solves is that we would not be getting the value of dynamic variables from previous errors if there is none debugger opened from a seaside continuation. If you let a debugger opened debugging a seaside error, then there is no magic we can do I think. > Imagine you were in a debugger and you evaluated: "WAComponent new session". The signal raised from there knows NOTHING about the debugger where that was evaluated... so at #defaultAction level you know nothing about what triggered that. > > The only thing to solve this would be to hook into the do-it, print it, inspect etc...too complicated. > > > Thoughts? I think youâre solution is already pretty good. I wouldnât really care if multiple debuggers are a problem. Evaluating a piece of code in context of the dynamic variables is already a lot of help. Although, if you donât know that youâre seeing a different session / request, thatâs bad... I do have one idea but it might be a bit more complicated and is not Seaside specific: if we could attach the context of the evaluation to the suspended context, the handler search should automatically yield the correct handlers for the dynamic variables (although I donât know exactly how the VM resolves the handlers). Alternatively, instead of attaching the whole stack, it would suffice to copy the handler contexts and attach them to the evaluation context. Both approaches would also solve the problem of multiple debuggers. For this to work the debugger would need highjack the evaluation of code e.g. by using a custom code editor. The cool thing about this would be that every evaluation would run in the same exception handling contexts as the original process. The bad thing is of course that in some situations you actually donât care (or want to care) about those handlers (e.g. when you want to trigger an exception explicitly during evaluation and donât want it to be swallowed by the exception handlers). Iâve CCâed Andrei because he knows more about UI <-> Debugger interaction. Maybe he has an idea how to do this. > > > > > Two tiny things: > - youâre not using the #reset method you wrote but instead manually assign nil to the variable > > yes, thanks. > > - I guess the dictionary in the handler could be a SmallDictionary. There wonât be many entries. > > > Well..since there will be likely.. less than 10 entries I don't care which Dictionary to use. However, I would prefer to keep Dictionary. Or if not GRSmallDictionary. > > Thanks a lot for this. Iâll probably port this back to Seaside 2.8 so I can use it too :) > > No problem. Thanks for reviewing and give feedback. > > >> >> >> On Sat, Dec 5, 2015 at 11:36 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> >>> On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>> >>> Can you try with the latest version that does not use LPC if it works? >> >> Works perfectly! >> >> >> >> -- >> 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. 11, 2015

a little poll on the importance of architecture

by Tudor Girba

Hi, I created another little poll about the importance of architecture. If you have a Twitter account, feel free to participate: https://twitter.com/girba/status/675330047608299521 Cheers, Doru -- www.tudorgirba.com "Things happen when they happen, not when you talk about them happening."

Dec. 11, 2015