GsDevKit and tode debugger
Locked
GsDevKit and tode debugger
 
|
Hi All, Im starting a new project with GsDevKit and glass as the backend server. The idea is to use the seaside REST interface to communicate to my UI layer. Installation went MUCH better than last time i tried this. Kudos to Dale for getting everything running smoothly. Im running gemstone v 3.2.10 I have a tode client running on my windows PC, which connects to stone running in a ubuntu VM. I can write code just fine and see it serve up my REST calls. but when it comes to trying to debug anything, its not working. my expectation is when an exception occurs -- I should see a continuation in the object log. instead all I see in the object log is a message saying topaz has quit. at first I thought it was due to my choice of error handler in the seaside config for my rest service. but all of them have the same results. See attached the zinc_server log file -- I put a 'self halt' in my domain code. Also on a (possibly?) related note, I cant figure out how to run arbitrary code in gemstone from the tode client. I tried using the 'eval' command but that always gives me a compile error. And using the 'do it' option from within a code browser has no effect. eval 'Array new' ==> a CompileError occurred (error 1001), compilation errors -- parameter 1 is error descriptor -------------------- 1. CompileError(AbstractException)>>_outer:with: @8 line 19 2. CompileError(AbstractException)>>outer @2 line 19 3. [] in UndefinedObject(TDAbstractEnvironment)>>_compileBlock: @9 line 11 4. Array(Collection)>>do: @5 line 10 5. [] in TDStandardEnvironment(TDAbstractEnvironment)>>_compileBlock: @4 line 8 6. CompileError(AbstractException)>>_executeHandler: @3 line 8 7. CompileError(AbstractException)>>_signalFromPrimitive: @1 line 1 8. String>>_compileInContext:symbolList:oldLitVars:environmentId: @1 line 1 9. String>>_compileInContext:symbolList:oldLitVars:environmentId:flags: @2 line 3 10. [] in UndefinedObject(TDAbstractEnvironment)>>_compile:inContext:literalVars:tempSymbolList:environmentId: @3 line 5 11. [] in TDStandardEnvironment(TDAbstractEnvironment)>>_compileBlock: @3 line 2 12. TDStandardEnvironment(ExecBlock)>>on:do: @3 line 42 13. TDStandardEnvironment(TDAbstractEnvironment)>>_compileBlock: @3 line 3 14. TDStandardEnvironment(TDAbstractEnvironment)>>_compile:inContext:literalVars:tempSymbolList:environmentId: @2 line 3 15. TDStandardEnvironment(TDAbstractEnvironment)>>compile:inContext:literalVars:tempSymbolList:environmentId: @2 line 3 16. TDStandardEnvironment(TDAbstractEnvironment)>>evaluate:in:literalVars:tempSymbolList:environmentId: @2 line 3 17. TDTopezServer>>evaluateString:inContext:literalVars:withTempSymbolList:environmentId: @4 line 5 18. [] in TDShellTool>>eval @6 line 15 19. OrderedCollection(Collection)>>do: @5 line 10 20. TDShellTool>>eval @5 line 11 21. TDShellTool class(TDAbstractDevTool class)>>performCommand:withSelector:objIn:commandOptions:todeCommand: @14 line 10 22. TDShellTool class(TDAbstractDevTool class)>>performCommand:objIn:commandOptions:todeCommand: @2 line 3 23. [] in TDShellTool class>>eval @2 line 5 24. TDShellTool class(ExecBlock)>>cull:cull:cull:cull: @7 line 4 25. TDTopezServer>>evaluateCommand:objIn: @18 line 22 26. TDTopezServer>>evaluateSTONCommand: @9 line 6 27. Executed Code 28. GsNMethod class>>_gsReturnToC @1 line 1 Ideas and suggestions on how to solve these would be much appreciated _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
zinc_server.log (10K)
Re: GsDevKit and tode debugger
|
|
For running code you can open a workspace with ‘ws’ and use that.
Or if you use the script a lot, you can create a tODE script node with ‘touch st myScriptName’, then edit it with 'edit myScriptName’. That opens a workspace to use as well. There’s probably a way to run those scripts from the tODE shell, but I can’t remember it right now. Sorry I can’t help with the error. I remember having a similar issue with REST and from memory ended up adding my own debugging hander something like: [ self doMyRestThing ] on: Error do: [ :error | GRPlatform current doTransaction: [ (ObjectLogEntry error: ‘Something screwed up’ object: (Array with: error with: otherThingUsefulForDebugging)) addToLog ] ] I’m not at my dev machine right now so I don’t know if the above code is right, but hopefully help. Cheers, J
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: GsDevKit and tode debugger
|
|
Thanks for the workspace cmd. That will make things a lot easier. debugging via topaz is not pleasant. On Tue, Sep 11, 2018 at 7:58 PM, Jupiter Jones <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: GsDevKit and tode debugger
|
|
This is what I used to do: http://forum.world.st/Debugging-a-multiple-process-system-tp5063742p5063833.html Maybe it helps too. Cheers, On Wed, Sep 12, 2018 at 12:50 AM Jon Paynter via Glass <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: GsDevKit and tode debugger
|
|
In reply to this post by GLASS mailing list
Jon, For running gems and capturing continuations in your REST server, you _could_ take a look at the gsApplicationTools[1] and using Zinc REST support with gsApplicationTools[2] ... For Seaside REST, I would think that the standard Seaside error handling should apply, but I don't see any thing that looks like a an error handler on the stack and I would have expected to see one of the following error handling classes invoked: WAExceptionHandler It's been awhile since I've played with Seaside REST, but I would
have expected that the normal Seaside error handling would come
into play for RESTful calls, but perhaps that is not the case? If the Seaside error handlers are not being installed on the
stack, then inside SersHandler>>handleResult: or
SersHandler>>executeResult: you put in the following code
(expansion of Jupiter's suggestion) that will snap off
continuations and save them to the object log: [ self doMyRestThing ] If there is the potential for commit conflicts, then you need to
be prepared to handle a failed commit (false result from
doTransaction:) and as a fallback bump a stack to the the gem log
... As I say, I am a bit surprised that the Seaside error handlers
are not being invoked ... Dale [2] https://github.com/GsDevKit/gsApplicationTools/blob/master/docs/rest.md#gemserver-support-for-zinc-rest On 09/12/2018 04:38 AM, Jon Paynter via
Glass wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: GsDevKit and tode debugger
|
|
Thanks for the reply. I tried following the instructions in the server-support-for-zinc-rest, but the example would not install. So I added your change into my rest handler (with minor edits) like so: SersHandler>>handleFiltered: aValue [ super handleFiltered: aValue ] on: Error , Halt , Warning do: [ :ex | GRPlatform current doTransaction: [ (ex isKindOf: Warning) ifTrue: [ "record warning message in object log" (ObjectLogEntry warn: ex description) addToLog ] ifFalse: [ "record continuation in object log" DebuggerLogEntry createContinuationLabeled: ex description ] ] ] I used #handleFiltered because the comments in #handle say "do not override this method" which works - but the client is not notified anything went wrong. I get a blank response, instead of a 500 error. so I added SersHandler>>handleFiltered: aValue [ super handleFiltered: aValue ] on: Error , Halt , Warning do: [ :ex | GRPlatform current doTransaction: [ (ex isKindOf: Warning) ifTrue: [ "record warning message in object log" (ObjectLogEntry warn: ex description) addToLog ] ifFalse: [ "record continuation in object log" DebuggerLogEntry createContinuationLabeled: ex description ] ]. ex signal ] Which correctly gives me a 500 error on the client, and creates an entry in the object log. but the zinc log reports "Exception has already been signaled" I want to re-raise the error I poked around in Error, Exception and related classes, but could not find anything that seems to work. the closest i found was #resignalAs, but that got stuck in a loop. is there any way to re-signal the same exception? .... and on a different note with glass & git repositories. I assume the folder in $GS_HOME/shared/repos/<project> is a normal git repo and I can just push the contents to my github? where do i find instructions on how to do 'class extensions' ? Ive added new methods to some classes outside my project and cant find how to add them to my project. On Mon, Sep 17, 2018 at 11:59 PM, Dale Henrichs <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: GsDevKit and tode debugger
|
|
On 09/18/2018 09:51 PM, Jon Paynter
wrote:
Not quite sure what you are trying to do here, but perhaps you want to use `ex pass`? `pass` will cause additional handlers on the stack to be triggered, which seems to be what you want? Yes ... tODE arranges to clone projects into $GS_HOME/shared/repos/ where the projects can be shared by all of your stones ... it is also possible to clone the git repositories in a directory that is "private" to your stone: $GS_HOME/server/stones/<stone-name>/git... That's a very good question! I googled around and could not find a very good explanation anywhere ... except for this[1] ... The convention for Monticello packages is to create a method protocol/category with a leading $* followed by the name of the package (case insensitive), followed by a $- and additional protocol names ... All methods in this category will be included in the named package ... Hope this helps ... Dale [1] http://pharo.gforge.inria.fr/PBE1/PBE1ch7.html#x32-108011r17 _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |