- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Unicode Support

by stepharo

Hi EuanM Le 4/12/15 12:42, EuanM a Ã©crit : > I'm currently groping my way to seeing how feature-complete our > Unicode support is. I am doing this to establish what still needs to > be done to provide full Unicode support. this is great. Thanks for pushing this. I wrote and collected some roadmap (analyses on different topics) on the pharo github project feel free to add this one there. > > This seems to me to be an area where it would be best to write it > once, and then have the same codebase incorporated into the Smalltalks > that most share a common ancestry. > > I am keen to get: equality-testing for strings; sortability for > strings which have ligatures and diacritic characters; and correct > round-tripping of data. Go! My suggestion is start small make steady progress write tests commit often :) Stef What is the french phoneBook ordering because this is the first time I hear about it. > > Call to action: > ========== > > If you have comments on these proposals - such as "but we already have > that facility" or "the reason we do not have these facilities is > because they are dog-slow" - please let me know them. > > If you would like to help out, please let me know. > > If you have Unicode experience and expertise, and would like to be, or > would be willing to be, in the 'council of experts' for this project, > please let me know. > > If you have comments or ideas on anything mentioned in this email > > In the first instance, the initiative's website will be: > http://smalltalk.uk.to/unicode.html > > I have created a SqueakSource.com project called UnicodeSupport > > I want to avoid re-inventing any facilities which already exist. > Except where they prevent us reaching the goals of: > - sortable UTF8 strings > - sortable UTF16 strings > - equivalence testing of 2 UTF8 strings > - equivalence testing of 2 UTF16 strings > - round-tripping UTF8 strings through Smalltalk > - roundtripping UTF16 strings through Smalltalk. > As I understand it, we have limited Unicode support atm. > > Current state of play > =============== > ByteString gets converted to WideString when need is automagically detected. > > Is there anything else that currently exists? > > Definition of Terms > ============== > A quick definition of terms before I go any further: > > Standard terms from the Unicode standard > =============================== > a compatibility character : an additional encoding of a *normal* > character, for compatibility and round-trip conversion purposes. For > instance, a 1-byte encoding of a Latin character with a diacritic. > > Made-up terms > ============ > a convenience codepoint : a single codepoint which represents an item > that is also encoded as a string of codepoints. > > (I tend to use the terms compatibility character and compatibility > codepoint interchangably. The standard only refers to them as > compatibility characters. However, the standard is determined to > emphasise that characters are abstract and that codepoints are > concrete. So I think it is often more useful and productive to think > of compatibility or convenience codepoints). > > a composed character : a character made up of several codepoints > > Unicode encoding explained > ===================== > A convenience codepoint can therefore be thought of as a code point > used for a character which also has a composed form. > > The way Unicode works is that sometimes you can encode a character in > one byte, sometimes not. Sometimes you can encode it in two bytes, > sometimes not. > > You can therefore have a long stream of ASCII which is single-byte > Unicode. If there is an occasional Cyrillic or Greek character in the > stream, it would be represented either by a compatibility character or > by a multi-byte combination. > > Using compatibility characters can prevent proper sorting and > equivalence testing. > > Using "pure" Unicode, ie. "normal encodings", can cause compatibility > and round-tripping probelms. Although avoiding them can *also* cause > compatibility issues and round-tripping problems. > > Currently my thinking is: > > a Utf8String class > an Ordered collection, with 1 byte characters as the modal element, > but short arrays of wider strings where necessary > a Utf16String class > an Ordered collection, with 2 byte characters as the modal element, > but short arrays of wider strings > beginning with a 2-byte endianness indicator. > > Utf8Strings sometimes need to be sortable, and sometimes need to be compatible. > > So my thinking is that Utf8String will contain convenience codepoints, > for round-tripping. And where there are multiple convenience > codepoints for a character, that it standardises on one. > > And that there is a Utf8SortableString which uses *only* normal characters. > > We then need methods to convert between the two. > > aUtf8String asUtf8SortableString > > and > > aUtf8SortableString asUtf8String > > > Sort orders are culture and context dependent - Sweden and Germany > have different sort orders for the same diacritic-ed characters. Some > countries have one order in general usage, and another for specific > usages, such as phone directories (e.g. UK and France) > > Similarly for Utf16 : Utf16String and Utf16SortableString and > conversion methods > > A list of sorted words would be a SortedCollection, and there could be > pre-prepared sortBlocks for them, e.g. frPhoneBookOrder, deOrder, > seOrder, ukOrder, etc > > along the lines of > aListOfWords := SortedCollection sortBlock: deOrder > > If a word is either a Utf8SortableString, or a well-formed Utf8String, > then we can perform equivalence testing on them trivially. > > To make sure a Utf8String is well formed, we would need to have a way > of cleaning up any convenience codepoints which were valid, but which > were for a character which has multiple equally-valid alternative > convenience codepoints, and for which the string currently had the > "wrong" convenience codepoint. (i.e for any character with valid > alternative convenience codepoints, we would choose one to be in the > well-formed Utf8String, and we would need a method for cleaning the > alternative convenience codepoints out of the string, and replacing > them with the chosen approved convenience codepoint. > > aUtf8String cleanUtf8String > > With WideString, a lot of the issues disappear - except > round-tripping(although I'm sure I have seen something recently about > 4-byte strings that also have an additional bit. Which would make > some Unicode characters 5-bytes long.) > > > (I'm starting to zone out now - if I've overlooked anything - obvious, > subtle, or somewhere in between, please let me know) > > Cheers, > Euan > >

Dec. 5, 2015

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

by Mariano Martinez Peck

On Sat, Dec 5, 2015 at 8:58 AM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Sat, Dec 5, 2015 at 7:33 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> Good stuff Mariano! I think a similar approach will work for Seaside 2.8. >> >> > Great. > > >> - I think you might want to override #handleException: and inject the >> process variable there. Then it doesnât matter from where the debugger is >> being opened and you donât have to mess with the exception handling logic >> (which inevitably leads to trouble in my experience). >> > > Good idea. The reason I was hooking there is because I was setting in the > process local variable once I know I was already at the UI Manager process > and no the Zinc Server one that was processing the request. > However...let me explain... Whenever you evaluate something from the > debugger, inspector, etc...all that is being run with UI Manager process. > While the stack you debugging was actually created at another process (the > Zinc Server one that was processing the request). If we store in PLC > (processor local variables) when we are in the Zinc process, then the > debugger does not see the values at all (since it is in UIManager). We may > be able to fix this, but we will need to hook in every possible > "evaluation" done from debugger: inspect, do it, print it, etc etc etc. > The only reason it make sense to store the values in PLC of the Zinc > process rather than UIManager (and make all necessary hooks in inspect, > print, etc) is because that would allow us to debug multiple exceptions at > the same time. Right now, since values are stored in PLC of UIManager, > those are shared for all debuggers. Meaning...you allow only ONE debugger. > The last debugger will set new values and the older debuggers will now get > the "new values". You can verify this yourself by opening 2 debuggers from > my test case. > > Anyway.... if we are already going to support 1 one debugger at a time > (it's more than enough for my needs), it make no sense to use PLC from > UIManager. In fact, the values could be stored ANYWHERE. The only > condition is to be able to reach them in each WADynamicVariable subclass >> > defaultValue. > > In my last commit you can see this new approach. For this experiment I > store things in Smalltalk globals but next I will: > > 1) Use a class side variable in WAPharoDebuggererErrorHandler > 2) Automatically store all subclasses of WADynamicValue with > convetion..say: > > I just committed that. -- Mariano http://marianopeck.wordpress.com

Dec. 5, 2015

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

by Mariano Martinez Peck

> > > > >> Incidentally, you could reuse WACurrentRequestContext (instead of the new >> process variable) in #openDebuggerOn: like so: >> >> WACurrentRequestContext use: currentRequest during: [ >> process >> debug: anError signalerContext >> title: anError description >> full: true. >> ] >> ]. >> >> That would make it much easier for users not familiar with the process >> variable trick. >> >> >> > > mmmmm are you sure this works? (in any case, we will not go that path > anymore but I am curious if that did work for you) > > by "works" I mean if you tested with WACurrentRequestDebuggingTest and followed the steps in its comments (the identityHash comparison to transcript). > Thanks! > > > >> >> Cheers, >> Max >> >> >> On 05 Dec 2015, at 00:11, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> I added more tests to WACurrentRequestDebuggingTest. If you see, all >> tests work except #callbackAndHalt. >> >> At a later point we will likely need to do this for the rest of the >> WADynamicVariable subclasses (they are 3 in total). >> >> Cheers, >> >> On Fri, Dec 4, 2015 at 7:17 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> OK, I tested it and it works. I added only one test but I plan to add >>> more. >>> >>> On Fri, Dec 4, 2015 at 4:59 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> OK, I started publishing here: >>>> http://smalltalkhub.com/mc/marianopeck/MarianoPublic/main package >>>> called SeasidePharoDebugging >>>> I did not even have the time to try it..just committed. >>>> I must leave now. >>>> >>>> byw >>>> >>>> On Fri, Dec 4, 2015 at 2:43 PM, Mariano Martinez Peck < >>>> marianopeck(a)gmail.com> wrote: >>>> >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> 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. 5, 2015

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

by Mariano Martinez Peck

On Sat, Dec 5, 2015 at 7:33 AM, Max Leske <maxleske(a)gmail.com> wrote: > Good stuff Mariano! I think a similar approach will work for Seaside 2.8. > > Great. > - I think you might want to override #handleException: and inject the > process variable there. Then it doesnât matter from where the debugger is > being opened and you donât have to mess with the exception handling logic > (which inevitably leads to trouble in my experience). > Good idea. The reason I was hooking there is because I was setting in the process local variable once I know I was already at the UI Manager process and no the Zinc Server one that was processing the request. However...let me explain... Whenever you evaluate something from the debugger, inspector, etc...all that is being run with UI Manager process. While the stack you debugging was actually created at another process (the Zinc Server one that was processing the request). If we store in PLC (processor local variables) when we are in the Zinc process, then the debugger does not see the values at all (since it is in UIManager). We may be able to fix this, but we will need to hook in every possible "evaluation" done from debugger: inspect, do it, print it, etc etc etc. The only reason it make sense to store the values in PLC of the Zinc process rather than UIManager (and make all necessary hooks in inspect, print, etc) is because that would allow us to debug multiple exceptions at the same time. Right now, since values are stored in PLC of UIManager, those are shared for all debuggers. Meaning...you allow only ONE debugger. The last debugger will set new values and the older debuggers will now get the "new values". You can verify this yourself by opening 2 debuggers from my test case. Anyway.... if we are already going to support 1 one debugger at a time (it's more than enough for my needs), it make no sense to use PLC from UIManager. In fact, the values could be stored ANYWHERE. The only condition is to be able to reach them in each WADynamicVariable subclass >> defaultValue. In my last commit you can see this new approach. For this experiment I store things in Smalltalk globals but next I will: 1) Use a class side variable in WAPharoDebuggererErrorHandler 2) Automatically store all subclasses of WADynamicValue with convetion..say: WADynamicValue allSubclasses do: [:each | WAPharoDebuggererErrorHandler storedDynamicValues at: (each name, 'Value') put: each value ]. and then, each WADynamicValue subclass would need to implement #defaultValue like this: defaultValue " 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 " ^ (WAPharoDebuggererErrorHandler storedDynamicValues at: (self name, 'Value') ifAbsent: [ WARequestContextNotFound signal ]) ifNil: [ WARequestContextNotFound signal ] Thoughts? > - Thereâs an âerâ too many in WAPharoDebuggererErrorHandler :) > - Your current solution doesnât work for the UI process. Snippet: > > [ > WACurrentRequestContext > use: 'foo' > during: [ > WAPharoDebuggererErrorHandler new handleExceptionsDuring: [ self halt. ] ] > ] fork. > > Without the #fork the process will be the UI process and the request will > not be saved into the process variable. Thatâs not a deal breaker but nice > for testing. > > Can you try with the latest version that does not use LPC if it works? > Incidentally, you could reuse WACurrentRequestContext (instead of the new > process variable) in #openDebuggerOn: like so: > > WACurrentRequestContext use: currentRequest during: [ > process > debug: anError signalerContext > title: anError description > full: true. > ] > ]. > > That would make it much easier for users not familiar with the process > variable trick. > > > mmmmm are you sure this works? (in any case, we will not go that path anymore but I am curious if that did work for you) Thanks! > > Cheers, > Max > > > On 05 Dec 2015, at 00:11, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > I added more tests to WACurrentRequestDebuggingTest. If you see, all tests > work except #callbackAndHalt. > > At a later point we will likely need to do this for the rest of the > WADynamicVariable subclasses (they are 3 in total). > > Cheers, > > On Fri, Dec 4, 2015 at 7:17 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> OK, I tested it and it works. I added only one test but I plan to add >> more. >> >> On Fri, Dec 4, 2015 at 4:59 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> OK, I started publishing here: >>> http://smalltalkhub.com/mc/marianopeck/MarianoPublic/main package >>> called SeasidePharoDebugging >>> I did not even have the time to try it..just committed. >>> I must leave now. >>> >>> byw >>> >>> On Fri, Dec 4, 2015 at 2:43 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> 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 >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Dec. 5, 2015

[pre-ANN][Job] two Pharo engineers for 2016

by Marcus Denker

Hi, This is just a pre-announcement (We will write a formal call over the next days). We have the possibility to hire two programmers working in Pharo itself in 2016 -> one for one year -> one for one year with the possibility to extend another year. The place of work is Lille (due to the nature of the employment via Inria). If you are interested, please contact me. We will send a real announcement soon. Marcus

Dec. 5, 2015

Re: [Pharo-dev] issue 12231 DisplayScreen hostWindowTitle: not working on Linux (ubuntu)

by kmo

I think it was me who reported the bug. If it's going to be closed without being fixed that just means I wasted my time. Not a good message to send out. -- View this message in context: http://forum.world.st/issue-12231-DisplayScreen-hostWindowTitle-not-working… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 5, 2015

AST based syntax colouring: Shout cleanup possible

by marcus.denker＠inria.fr

Hi, Interestingly with both Rubric and TxTxt we now use AST based syntax coverage by default (and the setting has no effect, it was just for PluggableTextMorph). As it seems that after the fixes that where done (mostly by Nicolai, thanks!!), the AST based syntax colouring is good enough to replace the one using SHParserST80. I am sure there are some smaller glitches still to be fixed, but it seems it has proven itself to the point we can start to clean up. SHParserST80 is used in addition by code completion, so we can not yet remove it yet, but we can radically simplify the SHTextStyler hierarchy. Anyone wants to give it a try? Marcus

Dec. 5, 2015

[Help needed] final push for Rubric editor

by Marcus Denker

Hi, We are using Rubric now nearly everywhere. But there are still some places left where the old PluggableTextMorph is used. I made a TODO with a list of what needs to be done: https://pharo.fogbugz.com/f/search/?sSearchFor=outline%3A15596 Marcus

Dec. 5, 2015

Re: [Pharo-dev] Cannot upload file on Smalltalkhub

by Marcus Denker

Done, copied both to rubric repo and then the config to the inbox in addition. > On 04 Dec 2015, at 19:14, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > > 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: > > > <Rubric-JurajKubelka.310.mcz><ConfigurationOfRubric-JurajKubelka.97.mcz> > > Thanks for any help, > Juraj

Dec. 5, 2015

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

by Max Leske

Good stuff Mariano! I think a similar approach will work for Seaside 2.8. - I think you might want to override #handleException: and inject the process variable there. Then it doesnât matter from where the debugger is being opened and you donât have to mess with the exception handling logic (which inevitably leads to trouble in my experience). - Thereâs an âerâ too many in WAPharoDebuggererErrorHandler :) - Your current solution doesnât work for the UI process. Snippet: [ WACurrentRequestContext use: 'foo' during: [ WAPharoDebuggererErrorHandler new handleExceptionsDuring: [ self halt. ] ] ] fork. Without the #fork the process will be the UI process and the request will not be saved into the process variable. Thatâs not a deal breaker but nice for testing. Incidentally, you could reuse WACurrentRequestContext (instead of the new process variable) in #openDebuggerOn: like so: WACurrentRequestContext use: currentRequest during: [ process debug: anError signalerContext title: anError description full: true. ] ]. That would make it much easier for users not familiar with the process variable trick. Cheers, Max > On 05 Dec 2015, at 00:11, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > I added more tests to WACurrentRequestDebuggingTest. If you see, all tests work except #callbackAndHalt. > > At a later point we will likely need to do this for the rest of the WADynamicVariable subclasses (they are 3 in total). > > Cheers, > > On Fri, Dec 4, 2015 at 7:17 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > OK, I tested it and it works. I added only one test but I plan to add more. > > On Fri, Dec 4, 2015 at 4:59 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > OK, I started publishing here: http://smalltalkhub.com/mc/marianopeck/MarianoPublic/main <http://smalltalkhub.com/mc/marianopeck/MarianoPublic/main> package called SeasidePharoDebugging > I did not even have the time to try it..just committed. > I must leave now. > > byw > > On Fri, Dec 4, 2015 at 2:43 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > 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 <mailto:marianopeck@gmail.com>> wrote: > > > On Fri, Dec 4, 2015 at 1:29 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@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 <mailto:maxleske@gmail.com>> wrote: > >> On 04 Dec 2015, at 17:11, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@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/> > > > > > -- > 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/> > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 5, 2015