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

Call for Papers: Constrained and Reactive Objects Workshop at Modularity 2016

by timfelgentreff

CROW 2016 - Constrained and Reactive Objects Workshop The Constrained and Reactive Objects Workshop (CROW) invites papers that present research results related to using constraints and reactive programming in combination or integrated with imperative and object-oriented systems. This research area has recently received increasing interest again. Object-constraint, constraint-reactive, constraint-imperative systems and others were proposed in response to challenges posed by, for example, the requirements for applications to work across different devices and form-factors, to provide best-effort computing in the face of unreliable devices and networks, and to more fully utilise HPC technology. However, many questions remain. For example, the interactions among constraints, reactive or event-based programming, and mainstream imperative and object-oriented languages are still not well-understood, and different implementation techniques to combine these paradigms are still being explored. The lack of large applications written with combinations of these paradigms means that there is little experience with patterns and tools for such applications, and modularity mechanisms required for such large applications are in their infancy or completely absent. This workshop is intended to gather researchers working on using constraints or reactive programming in combination with mainstream imperative and object-oriented languages. The goal of this workshop is to present technical research results related to such systems, discuss applications, tools, and patterns used in these systems, and to define better the directions into which this field may evolve by providing overviews of existing work. Call for Papers Even though constraint-based and reactive programming are not new concepts, their combination and interaction with more mainstream imperative and object-oriented languages are receiving more and more attention. This workshop is an attempt to gather researchers working on models, languages, and implementations relating these paradigms. We welcome all submissions on language design, implementation, runtime systems, program analysis, software metrics, patterns, modularity principles, case-studies and benchmarks of systems that combine constraint-based or reactive programming with imperative paradigms. Of particular interest are topics from the following areas: â¢Study of the interactions of constraints and reactive programming with imperative language features such as object-oriented programming, mutable state, encapsulation, modules, or concurrency â¢Applications and case-studies that showcase examples in which the combination of constraints and reactive programming facilitates systems development â¢Empirical studies that motivate further research in the field â¢Patterns, modularity mechanisms, and best-practices for larger applications â¢IDEs and Tools â¢Language runtimes, virtual machine support, or compilers â¢Related fields that constraints and reactive programming can help facilitate, such as self-healing systems, best-effort computing, acceptability-oriented computing, or end-user programming Authors are invited to submit short position papers or long technical papers. using the ACM sigplanconf style at 9pt font size (see http://www.acm.org/publications/article-templates/proceedings-template.html) Short papers are imited to a maximum of 4 pages, excluding references. Long papers are limited to a maximum of 10 pages, including references. Submissions should not have been previously published nor be under review at other events. All submitted papers will be peer reviewed. Accepted papers will be published in the ACM Digital Library (unless the authors wish otherwise). Papers should be submitted via EasyChair: https://easychair.org/conferences/?conf=crow16. Workshop Format The format of the workshop will be that of a mini-conference. Participants can present their work in slots of 30 minutes including Q&A. Because it is often hard to understand the semantics of novel combinations of multiple paradigms as in this workshop just by looking at the code, we also encourage authors to present live demos. The goal of the workshop is to come to a better understanding of the the field. We hope to use the late afternoon session to draw conclusions from the presented work, and to identify fundamental paradigmatic problems that still need to be resolved to reconcile these different technologies and paradigms. Important Dates â¢Submission deadline: January 15, 2016 â¢Notification: February 6, 2016 â¢Camera ready: February 13, 2016 â¢Workshop: March 14-15, 2016 -- View this message in context: http://forum.world.st/Call-for-Papers-Constrained-and-Reactive-Objects-Work… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 4, 2015

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

by Andrei Chis

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] [pharo-project/pharo-core] d12673: 50483

by Pavel Krivanek

Thank you. -- Pavel 2015-12-04 13:37 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > I copied the package to the Glamour repo. > But I have no idea why the integrator decided to create that package. > > Cheers, > Andrei > > On Fri, Dec 4, 2015 at 12:20 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> ConfigurationOfIDE job fails because of this error: >> Could not resolve: Glamour-Morphic-Brick-Tests >> [Glamour-Morphic-Brick-Tests-TheIntegrator.14] in >> /builds/workspace/Pharo-5.0-Update-Step-1-Tracker/package-cache >> http://smalltalkhub.com/mc/Moose/Glamour/main/ >> >> Can someone with write permissions push this package version to the >> Glamour repository? >> >> Cheers, >> -- Pavel >> >> 2015-12-04 11:16 GMT+01:00 GitHub <noreply(a)github.com>: >> >>> Branch: refs/heads/5.0 >>> Home: https://github.com/pharo-project/pharo-core >>> Commit: d1267341a42b97e366de51b22cf83e5cb2f1f22a >>> >>> https://github.com/pharo-project/pharo-core/commit/d1267341a42b97e366de51b2… >>> Author: Jenkins Build Server <board(a)pharo-project.org> >>> Date: 2015-12-04 (Fri, 04 Dec 2015) >>> >>> Changed paths: >>> M FontChooser.package/FontChooserMorph.class/instance/interface >>> building/newFontPointSizeField.st >>> M >>> Morphic-Core.package/Morph.class/instance/events-processing/handleMouseMove_.st >>> A >>> Morphic-Core.package/Morph.class/instance/events-processing/handlesMouseMove_.st >>> R Morphic-Widgets-NewList.package/NewListExample.class/README.md >>> R Morphic-Widgets-NewList.package/NewListExample.class/definition.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/accessing/listMorph.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/accessing/listMorph_.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/initialization/ >>> initialize.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/buildMorph.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/buildMorphWithOld.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/buildTextMorph.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/openInWindow.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/openInWorld.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/withNewList.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/withOldList.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/allowToSelect.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/displayItem_.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/drop_at_.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/getIndex.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/getItems.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/headerTitle.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/iconFor_at_.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/iconMaxSize.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/menu_shifted_.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/setIndex_.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/ >>> title.st >>> R >>> Morphic-Widgets-NewList.package/NewListExample.class/instance/protocol/toggleTitle.st >>> M >>> NECompletion.package/NECContext.class/instance/accessing/createModel.st >>> A >>> NECompletion.package/NECContext.class/instance/private-type-guessing/completionTokenIsComment.st >>> A >>> NECompletion.package/NECContext.class/instance/private-type-guessing/completionTokenIsLiteralOrComment.st >>> M >>> NECompletion.package/NECContext.class/instance/private/createRanges.st >>> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/ >>> script50482.st >>> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/ >>> script50483.st >>> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/ >>> update50482.st >>> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/ >>> update50483.st >>> M >>> ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >>> M Slot.package/extension/Behavior/instance/classLayout.st >>> M Slot.package/extension/Behavior/instance/layout.st >>> M Slot.package/extension/Behavior/instance/layout_.st >>> M >>> SmartSuggestions-Tests.package/SugsMockContext.class/instance/api-context/sourceTextArea.st >>> >>> Log Message: >>> ----------- >>> 50483 >>> 17167 disable NEC completion in method comments >>> https://pharo.fogbugz.com/f/cases/17167 >>> >>> 17181 Rename layout to classLayout (step 3.5 replace implementation in >>> Behavior) >>> https://pharo.fogbugz.com/f/cases/17181 >>> >>> 16724 new removal of RubPluggableTextMorph >>> https://pharo.fogbugz.com/f/cases/16724 >>> >>> 17178 Move checking logic of #handleMouseMove: into #handlesMouseMove: >>> https://pharo.fogbugz.com/f/cases/17178 >>> >>> http://files.pharo.org/image/50/50483.zip >>> >>> >>> >> >

Dec. 4, 2015

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

by Max Leske

> 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âve played around with Process>>signalException: and Context>>handleSignal: (which looked quite promising) but didnât get any results. Iâm out of ideas. Cheers, Max > > On Fri, Dec 4, 2015 at 7:32 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > Hereâs a snippet to play with: > > p := Processor activeProcess. > x := 2. > v := TestDynamicVariable value: x during: [ > ((p instVarNamed: 'env') ifNotNil: [ :env| > env copyWithout: nil ]) inspect > ]. > > ((p instVarNamed: 'env') ifNotNil: [ :env| > env copyWithout: nil ]) inspect > > Cheers, > Max > >> On 04 Dec 2015, at 10:47, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> >> I feel you :) >> >> Without having thought this through completely: if you look at the implementation of DynamicVariable>>value:during: youâll see that the way it works is that the variable is bound to the active process. In the debugger you have access to the process that is being debugged and thus you should have access to the variables bound to it. You could try accessing all such variables by iterating over them (which I think will require an extension on Process because youâd need to access at least the PSKeys class variable). >> >> Cheers, >> Max >> >>> On 04 Dec 2015, at 00:34, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>> >>> Hi guys, >>> >>> This thing I will ask in this email it's in my mind since YEARS. But I have always thought it was like that and that there was nothing we could do. However, I think it's time I ask again :) >>> >>> For those that have used Seaside, and you try to debug, you know that upon request processing seaside uses Exceptions mechanisim to always have access to the request, session, etc. They way that is done is very smart :) >>> >>> WACurrentRequestContext use: self during: aBlock >>> >>> In that case, "self" is the request instance and aBlock the closure that takes care of the request processing. So, inside that closure, everywhere you do "WACurrentRequestContext value" you get the correct request instance. >>> >>> So..that's great for Seaside, but debugging gets complicated. While you can restart, proceed, etc, once inside debugger, you cannot evaluate any piece of code that will use the session or request because you get a WARequestContextNotFound. Of course, because I guess the evaluation you do from cmd+d on a piece of text or via the debugger inspector, creates another closure/context which does not receive the WACurrentRequestContext instance. >>> >>> Now....besides WACurrentRequestContext I have my own class UserContextInformation where I basically have a bunch of stuff associated to the logged user. And I do exactly the same as the WACurrentRequestContext. And I have the same problem. I really want to be able to fix this. >>> >>> Anyone have an idea on how can I do it? I guess I can change the debugger, in the place where I evaluate code so that I wrap that evaluation with my request context instance??? >>> >>> Thoughts? >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >> > > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 4, 2015

GTDebugger not draggable with latest VM

by Blondeau Vincent

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] [Pharo-users] MacroRecorder available in Pharo

by Alexandre Bergel

Excellent! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Dec 4, 2015, at 5:34 AM, Gustavo Santos <gugajansen(a)gmail.com> wrote: > > Hello guys, > > I would like to present you MacroRecorder, a tool to build custom source code transformations in Pharo. > > The tool is available in the Catalog for some weeks now. > The current version runs in Pharo 5 and there is an old version running in Pharo 4. > > To show how this tool works, I prepared a quick demo video. > Take a look: https://youtu.be/gW3l4O-WEGs <https://youtu.be/gW3l4O-WEGs> > Right now, I'm interested in usage data. > That means, if you face a case of repetitive code transformation in practice, and I believe this happened to most of you, please: > (i) show me the transformations you did, in case they already happened in the past, or > (ii) consider using the tool to apply them automatically > > And, of course, feel free to ask questions, provide feedback, etc. > > Kind regards, > > -- > Gustavo Santos > http://gustavojss.github.io/ <http://gustavojss.github.io/>

Dec. 4, 2015

[pharo-project/pharo-core]

by GitHub

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

Dec. 4, 2015

[pharo-project/pharo-core] 03087c: 50484

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 03087c82c794c6db8cb3a15435a9e920e8b99cc9 https://github.com/pharo-project/pharo-core/commit/03087c82c794c6db8cb3a154… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-04 (Fri, 04 Dec 2015) Changed paths: M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version222_.st M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version232_.st M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version142_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version322_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version342_.st M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version241_.st A GT-Inspector.package/GTExample.class/instance/private/resultCached.st M GT-Inspector.package/GTExample.class/instance/private/resultCached_.st M GT-Inspector.package/GTExampleEvaluator.class/instance/private/process_withArguments_.st A GT-Inspector.package/GTExampleNautilus.class/class/private/methodUpdated_with_.st M GT-Inspector.package/GTExampleNautilus.class/instance/private/examples_.st M GT-Inspector.package/GTExampleNautilus.class/instance/private/examples_do_.st A GT-Inspector.package/GTExampleNautilusAction.class/class/private/iconForMethod_result_.st M GT-Inspector.package/GTExampleNautilusAction.class/instance/private/iconForMethod_.st M GT-Inspector.package/GTExampleNautilusAction.class/instance/private/resultForMethod_.st M GT-Inspector.package/GTExampleResult.class/instance/ui/gtDisplaySummaryOn_.st M GT-Inspector.package/GTExampleTestCase.class/instance/private/runExample_fromContainer_.st A GT-InspectorExtensions-Core.package/extension/KMDispatcher/instance/gtAllKeyCategoryPairs.st M GT-InspectorExtensions-Core.package/extension/KMDispatcher/instance/gtInspectorMappingsIn_.st A GT-SpotterExtensions-Core.package/extension/BlockClosure/instance/gtSpotterCodePreviewIn_.st A GT-SpotterExtensions-Core.package/extension/CompiledMethod/instance/spotterForBytecodesFor_.st A GT-SpotterExtensions-Core.package/extension/Dictionary/instance/spotterForKeysFor_.st A GT-SpotterExtensions-Core.package/extension/KMDispatcher/instance/spotterForKeysFor_.st A GT-SpotterExtensions-Core.package/extension/KMKeymap/instance/gtSpotterCodePreviewIn_.st A GT-SpotterExtensions-Core.package/extension/Morph/instance/spotterForKeysFor_.st A GT-SpotterExtensions-Core.package/extension/Morph/instance/spotterForSubmorphsFor_.st A GT-SpotterExtensions-Core.package/extension/RBProgramNode/instance/gtSpotterCodePreviewIn_.st M Glamour-Morphic-Brick.package/GLMPhlowPharoMethodBrick.class/instance/phlow/installEntity.st A Glamour-Morphic-Brick.package/GLMPhlowTextBrick.class/instance/accessing/selectionInterval.st A Glamour-Morphic-Brick.package/GLMPhlowTextBrick.class/instance/accessing/selectionInterval_.st M Glamour-Morphic-Brick.package/GLMPhlowTextBrick.class/instance/phlow/installEntity.st M Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/draw.st M Rubric.package/RubSmalltalkEditor.class/instance/private/modelCurrentSelectedClass.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50483.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50484.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50483.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50484.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50484 ConfigurationOfRubric http://files.pharo.org/image/50/50484.zip

Dec. 4, 2015

SqueakElib project

by Robert Withers

Good morning, Here is a brief writeup of the SqueakElib project and its direction. https://github.com/SqueakCryptographySquad/Cryptography-Common/wiki/SqueakE…. All new squad members welcome. Regards, Robert

Dec. 4, 2015

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

by Mariano Martinez Peck

Max...Seaside uses WADynamicVariable (NOT DynamicVariable) which are completely different. WADynamicVariable uses exception mechanism while DynamicVariable uses the ProcessSpecificVariable. But thanks anyway! 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

Dec. 4, 2015