- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50486 Home: https://github.com/pharo-project/pharo-core

Dec. 5, 2015

[pharo-project/pharo-core] df0587: 50486

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: df058777bc359dbcc0b72631e38e6cac232f4428 https://github.com/pharo-project/pharo-core/commit/df058777bc359dbcc0b72631… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-05 (Sat, 05 Dec 2015) Changed paths: R Nautilus.package/AbstractNautilusUI.class/instance/events handling/doubleClickOnGroup.st R Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/createInitializerWithInstVars.st R Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/restrictedBrowseHierarchy.st R Nautilus.package/AbstractNautilusUI.class/instance/plugins announcements/openClass.st R Nautilus.package/AbstractNautilusUI.class/instance/private/buildInitializerFor_.st R Nautilus.package/AbstractNautilusUI.class/instance/private/getGroupsKeyList.st R Nautilus.package/AbstractNautilusUI.class/instance/shortcuts/setClassShorcutsTo_.st R Nautilus.package/AbstractNautilusUI.class/instance/source code area/contentSelectionFor_.st M OpalCompiler-Core.package/AbstractCompiler.class/class/settings/compilerSettingsOn_.st R OpalCompiler-Core.package/CCompilationContext.class/class/accessing/warningAllowed.st R OpalCompiler-Core.package/CCompilationContext.class/class/accessing/warningAllowed_.st M OpalCompiler-Core.package/CCompilationContext.class/definition.st R OpalCompiler-Core.package/CCompilationContext.class/instance/accessing/warningAllowed.st R OpalCompiler-Core.package/CompilationContext.class/class/accessing/warningAllowed.st R OpalCompiler-Core.package/CompilationContext.class/class/accessing/warningAllowed_.st R OpalCompiler-Core.package/CompilationContext.class/instance/accessing/warningAllowed.st R OpalCompiler-Core.package/OCSemanticWarning.class/instance/accessing/errorNotification.st M OpalCompiler-Core.package/OCSemanticWarning.class/instance/correcting/defaultAction.st M Reflectivity.package/extension/RBProgramNode/instance/removeLink_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50485.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50486.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50485.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50486.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Tool-Base.package/AbstractTool.class/instance/class/addCategoryIn_.st R Tool-Base.package/AbstractTool.class/instance/class/basicRemoveClass_.st R Tool-Base.package/AbstractTool.class/instance/method/findMethodIn_.st R Tool-Base.package/AbstractTool.class/instance/method/removeNonLocalSelector_from_.st R Tool-Base.package/AbstractTool.class/instance/method/selectMessageAndEvaluate_defaultValue_.st R Tool-Base.package/AbstractTool.class/instance/method/selectThenBrowseMessagesFrom_.st R Tool-Base.package/AbstractTool.class/instance/method/selectThenBrowseSendersOfMessagesFrom_.st R Tool-Base.package/AbstractTool.class/instance/method/selectThenGetSelectorAndSendQuery_to_with_selector_.st R Tool-Base.package/AbstractTool.class/instance/method/selectorFromPattern_withCaption_startingFrom_.st R Tool-Base.package/AbstractTool.class/instance/package/findPackageIn_.st R Tool-Base.package/AbstractTool.class/instance/package/packageFromPattern_withCaption_.st Log Message: ----------- 50486 17187 make link de- installation more stable https://pharo.fogbugz.com/f/cases/17187 17188 remove unsent methods from AbstracTool and Nautilus https://pharo.fogbugz.com/f/cases/17188 17163 remove Setting #warningAllowed https://pharo.fogbugz.com/f/cases/17163 http://files.pharo.org/image/50/50486.zip

Dec. 5, 2015

Crypto plugins for ubuntu 32-bits

by Robert Withers

I loaded the CryptographyPlugins package, from the Cryptography repository into a VMMaker image, and generated the crypto plugins externally. Although I have not measured it rigorously, there is a noticeable performance improvement with SqueakElib tests. Untar these Ubuntu 32-bit crypto plugins into /usr/local/lib/squeak/5.0... https://www.dropbox.com/s/v502zudwsbtr243/CryptoPlugins.ubuntu32.12.4.15.tg… Let me know any issues. Regards, Robert

Dec. 5, 2015

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

by Mariano Martinez Peck

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

Dec. 4, 2015

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

by Mariano Martinez Peck

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

Dec. 4, 2015

Re: [Pharo-dev] Unicode Support

by Sven Van Caekenberghe

> On 04 Dec 2015, at 17:00, Max Leske <maxleske(a)gmail.com> wrote: > > Hi Euan > > I think itâs great that youâre trying this. I hope you know what youâre getting yourself into :) > > > Iâm no Unicode expert but I want to add two points to your list (although youâve probably already thought of them): > - Normalisation and conversion (http://unicode.org/faq/normalization.html) > Unicode / ICU provide libraries (libuconv / libiconv) that handle this stuff. Specifically normalisation conversions > arenât trivial and I think it wouldnât make much sense to reimplement those algorithms. I do think however, that > having them available is important (where I work weâre currently writing a VM plugin for access to libiconv through > primitives so that we can clean out combining characters through normalisation. And weâll obviously get nice sorting > properties and speeds for free) > - Sorting and comparison. > Basically the same point as above. libuconv / libiconv provide algorithms for this. Do we need our own implementation? These 2 are indeed missing and it would be good to add them. We already have UTF8/UTF16 encoding/decoding, even 2 implementations. See http://files.pharo.org/books/enterprisepharo/book/Zinc-Encoding-Meta/Zinc-E… for the modern version. But IMHO it would not be a good idea to try to implement functionality on in image strings with those representations, it would be too slow. But of course, if you want to try to implement something and show us, go for it. > Cheers, > Max > > >> On 04 Dec 2015, at 12:42, EuanM <euanmee(a)gmail.com> wrote: >> >> 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 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. >> >> 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. 4, 2015

Re: [Pharo-dev] SessionManager (aka new startup / shutdown list manager) needs testers

by Nicolai Hess

2015-12-04 13:39 GMT+01:00 Christophe Demarey <Christophe.Demarey(a)inria.fr>: > Hi, > > Guillermo, Pablo and I started to work on a new implementation for the > image startup / shutdown list. > The old implementation misses domain objects, polluted the SmalltalkImage > class and introduced crazy dependencies to other packages. > > So, what is Session Manager? > > - a replacement of the Session class (is now WorkingSession) > - a rewrite of startup / shutdown list with domain objects > - SessionManager: can create new sessions and manage categories. > Also provide a facade to register new session handlers. Session manager > provide sthe list of handlers by order of priority (categories order and > categories priority) either for the startup or the shutdown, > - WorkingSession: unique object for the current smalltalk session > (I.e. between a startup and a shutdown). On each image startup the current > session is invalidated and a new session is created. Define how errors > should be handled. Run the startup / shutdown process. > - SessionCategory: we defined some well known categories for > startup / shutdown: system, network, GUI, tools and there is room to add > user specific categories, It help to run the handler at the right time > without caring about the whole order. > - and SessionHandlers: handleSession for a specific class or any > other object. > - the shutdown list is now simply the startup list reversed > - we also refactored error handling at startup by using the UIManager > and StartupUIManager. It allowed to remove ugly checks like #isInteractive, > isHeadless in error handling methods and centralize that in UIManager. > > > You can find an image with the new SessionManager in action here: > https://ci.inria.fr/pharo-contribution/job/SessionManager/ > > As it is a critical piece of code, could you play / test it a bit before > we integrate this new mechanism in the Pharo image? > Looks good. What are the main critical startup/shutdown users( classes) that should be tested? I did some tests with AthensSceneView (uses NB and calls Smalltalk session for reinit external resources) and Roassal. I got one image startup failure, but I couldn't reproduce it yet. Maybe I did image save and image save and quit, too quick. > > Regards, > Christophe > > ps: Pharo tests pass > ps2: There is still some code to clean / remove from the old startup > management system. >

Dec. 4, 2015

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

by Mariano Martinez Peck

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

Dec. 4, 2015

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

by Nicolai Hess

2015-12-04 17:42 GMT+01:00 Henrik Nergaard <henrin10(a)student.uia.no>: > 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. > I would go with the third solution, return early only if handlesMouseMove returns true. (The handles mouse move seems somewhere special, maybe because all Morphs supports to be dragged and move, and therefore some Morphs may not care to install a mouse move eventhandler.) > > > > > 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> > 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> 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] Differences Compiler vs. OpalCompiler (or parser)

by Nicolai Hess

2015-12-04 20:29 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > > > 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. > Thanks! > > 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