[tode_st] Screw up tode

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

This looks you are missing some structure for the stone. Here's what a healthy stone structure looks like (bash):

nehalem $ ls $GS_HOME/sys/stones/<stone-name>/*
dirs.ston
homeComposition.ston
packages.ston
projectComposition.ston
repos.ston

home:
seaside.ston

projects:
README.md

.... so you are probably missing the projects directory and maybe more ... but this is the area on disk that is involved with your errors ...

Dale

Dale, 

I have a stone which I now cannot browse my sys structure anymore. This was a stone where I had tODE installed before. My gsDevKit_home is from yesterday, so should be latest code.

Look at this results just after opening a shell 

tode 1 > ls

(class)@  (oop)@  (invariant)@  (committed)@

tode 1 > /sys/default/bin/validateStoneSysNodes --repair

Topez ERROR: a TodeCommandError occurred (error 121000), No such node: '/sys/default/bin/validateStoneSysNodes'

tode 1 > script --script=updateServerTode

---Starting backup to '/quuve/sites/debrisTesting/gemstone/data/backups//preUpdate.dbf' (10/24/2015 08:50:09)

---Finished backup to 24/10/2015 08:50:37 -- preUpdate.dbf.gzTopez ERROR:

That opens a debugger 

aTDDebugger

--------------------

1. MessageNotUnderstood>>defaultAction @2 line 3

2. MessageNotUnderstood(AbstractException)>>_signalWith: @5 line 25

3. MessageNotUnderstood(AbstractException)>>signal @2 line 47

4. UndefinedObject class(Object)>>doesNotUnderstand: @9 line 10

5. UndefinedObject class(Object)>>_doesNotUnderstand:args:envId:reason: @7 line 12

6. [] in ExecBlock2(TDMetacelloTool)>>scanProjectDir:forProjects: @9 line 12

7. [] in ExecBlock1(TDNode)>>composedChildrenDo: @2 line 2

8. [] in TDObjectNode(TDPluggableNode)>>childrenDo: @3 line 2

9. Array(Collection)>>do: @5 line 10

10. TDObjectNode(TDPluggableNode)>>childrenDo: @4 line 2

11. TDObjectNode(TDNode)>>composedChildrenDo: @2 line 2

12. TDObjectGatewayNode(TDGatewayNode)>>composedChildrenDo: @3 line 2

13. TDMetacelloTool>>scanProjectDir:forProjects: @2 line 3

14. TDMetacelloTool>>scanForProjects: @5 line 3

15. TDMetacelloTool>>projectRegistrationDefinitionMap @9 line 8

16. TDMetacelloTool>>projectRegistrationFor: @2 line 2

17. TDMetacelloTool>>resolveProjectRegistrationReference: @18 line 15

18. TDMetacelloTool>>projectload @5 line 40

19. TDMetacelloTool class(TDAbstractDevTool class)>>performSubCommand:objIn:commandOptions:todeCommand: @23 line 22

20. [] in TDMetacelloTool class>>project @2 line 5

21. TDMetacelloTool class(ExecBlock)>>cull:cull:cull:cull: @7 line 4

22. TDTopezServer>>evaluateCommand:objIn: @18 line 22

23. TDTopezServer>>evaluateSTONCommand: @9 line 6

24. Executed Code

25. UndefinedObject(GsNMethod class)>>_gsReturnToC @1 line 1

Problem is in #scanProjectDir: projectDirNode forProjects: projectBlock

Weird is that 'entry' is UndefinedObject (not nil, but it's class).

And 'projectNode' is like this:

Inspect /nil/(class)//

--------------------

.                            -> /nil/(class)/

(class)@                     -> TDObjectNode

(oop)@                       -> 89273857

addBlock@                    -> nil

builderAspect@               -> nil

collectionBlock@             -> nil

contents@                    -> UndefinedObject

elementBlock@                -> anExecBlock

elementExtensionBlock@       -> nil

elementRenderAttributeBlock@ -> nil

extensionBlock@              -> nil

listBlock@                   -> anExecBlock

name@                        -> '(class)'

parent@                      -> /nil/

readMe@                      -> 'I am a maze of twisty little passages, all slightly different.'

removeBlock@                 -> nil

renderAttributeBlock@        -> nil

topez@                       -> aTDTopezServer

I even tried manually reinstalling tODE. Nothing changed. 

Is there a way I can re-initialize everything?

Thanks!

--

Mariano
http://marianopeck.wordpress.com

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

This is a foreign stone....

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Well you still need the `$GS_HOME/sys/stones/<stone-name>/*` disk structure for tODE to work (whether or not it is a foreign stone) .... Did you use $GS_HOME/bin/attachForeignStone create the foreign stone?

If so it looks like I did not anticipate (or think very hard about)that a foreign stone would include a _recent version_ of tODE in a foreign stone. My tests involved testing against foreign stones with old versions of tODE installed.

There are a number of moving parts in this case ... the latest tODE code expects the full set of env vars to be set up (`source $GS_HOME/bin/defGsDevKit.env`) and the full range of GEMSTONE env vars (`source $GS_HOME/server/stones/<stone-name>/stone.env`) ... so these would need to be done before starting your netldi ... Then you'd need to have the directory structure I referred to in my previous message (`$GS_HOME/sys/stones/<stone-name>/*) ...

The script in $GS_HOME/bin/private/attachStone is probably what you need (the bit where `$foreign = false`).

You are a special case in that you have foreign stones, that you want treated more like and "old stone" except that you will be starting/stopping the netldis using your own scripts ... so it is appropriate to create the `$GS_HOME/sys/stones/<stone-name>/` structure ... if it would help I could add another option to the $GS_HOME/bin/private/attachStone script that just build the $GS_HOME/sys/stones structure fresh from scratch without copying from an existing locatioin ...

Dale

This is a foreign stone....

On Oct 24, 2015 12:57 PM, "Dale Henrichs" <[hidden email]> wrote:

This looks you are missing some structure for the stone. Here's what a healthy stone structure looks like (bash):

nehalem $ ls $GS_HOME/sys/stones/<stone-name>/*
dirs.ston
homeComposition.ston
packages.ston
projectComposition.ston
repos.ston

home:
seaside.ston

projects:
README.md

.... so you are probably missing the projects directory and maybe more ... but this is the area on disk that is involved with your errors ...

Dale

On 10/24/15 5:55 AM, Mariano Martinez Peck wrote:

Dale, 

I have a stone which I now cannot browse my sys structure anymore. This was a stone where I had tODE installed before. My gsDevKit_home is from yesterday, so should be latest code.

Look at this results just after opening a shell 

tode 1 > ls

(class)@  (oop)@  (invariant)@  (committed)@

tode 1 > /sys/default/bin/validateStoneSysNodes --repair

Topez ERROR: a TodeCommandError occurred (error 121000), No such node: '/sys/default/bin/validateStoneSysNodes'

tode 1 > script --script=updateServerTode

---Starting backup to '/quuve/sites/debrisTesting/gemstone/data/backups//preUpdate.dbf' (10/24/2015 08:50:09)

---Finished backup to 24/10/2015 08:50:37 -- preUpdate.dbf.gzTopez ERROR:

That opens a debugger 

aTDDebugger

--------------------

1. MessageNotUnderstood>>defaultAction @2 line 3

2. MessageNotUnderstood(AbstractException)>>_signalWith: @5 line 25

3. MessageNotUnderstood(AbstractException)>>signal @2 line 47

4. UndefinedObject class(Object)>>doesNotUnderstand: @9 line 10

5. UndefinedObject class(Object)>>_doesNotUnderstand:args:envId:reason: @7 line 12

6. [] in ExecBlock2(TDMetacelloTool)>>scanProjectDir:forProjects: @9 line 12

7. [] in ExecBlock1(TDNode)>>composedChildrenDo: @2 line 2

8. [] in TDObjectNode(TDPluggableNode)>>childrenDo: @3 line 2

9. Array(Collection)>>do: @5 line 10

10. TDObjectNode(TDPluggableNode)>>childrenDo: @4 line 2

11. TDObjectNode(TDNode)>>composedChildrenDo: @2 line 2

12. TDObjectGatewayNode(TDGatewayNode)>>composedChildrenDo: @3 line 2

13. TDMetacelloTool>>scanProjectDir:forProjects: @2 line 3

14. TDMetacelloTool>>scanForProjects: @5 line 3

15. TDMetacelloTool>>projectRegistrationDefinitionMap @9 line 8

16. TDMetacelloTool>>projectRegistrationFor: @2 line 2

17. TDMetacelloTool>>resolveProjectRegistrationReference: @18 line 15

18. TDMetacelloTool>>projectload @5 line 40

19. TDMetacelloTool class(TDAbstractDevTool class)>>performSubCommand:objIn:commandOptions:todeCommand: @23 line 22

20. [] in TDMetacelloTool class>>project @2 line 5

21. TDMetacelloTool class(ExecBlock)>>cull:cull:cull:cull: @7 line 4

22. TDTopezServer>>evaluateCommand:objIn: @18 line 22

23. TDTopezServer>>evaluateSTONCommand: @9 line 6

24. Executed Code

25. UndefinedObject(GsNMethod class)>>_gsReturnToC @1 line 1

Problem is in #scanProjectDir: projectDirNode forProjects: projectBlock

Weird is that 'entry' is UndefinedObject (not nil, but it's class).

And 'projectNode' is like this:

Inspect /nil/(class)//

--------------------

.                            -> /nil/(class)/

(class)@                     -> TDObjectNode

(oop)@                       -> 89273857

addBlock@                    -> nil

builderAspect@               -> nil

collectionBlock@             -> nil

contents@                    -> UndefinedObject

elementBlock@                -> anExecBlock

elementExtensionBlock@       -> nil

elementRenderAttributeBlock@ -> nil

extensionBlock@              -> nil

listBlock@                   -> anExecBlock

name@                        -> '(class)'

parent@                      -> /nil/

readMe@                      -> 'I am a maze of twisty little passages, all slightly different.'

removeBlock@                 -> nil

renderAttributeBlock@        -> nil

topez@                       -> aTDTopezServer

I even tried manually reinstalling tODE. Nothing changed. 

Is there a way I can re-initialize everything?

Thanks!

--

Mariano
http://marianopeck.wordpress.com

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

On Sat, Oct 24, 2015 at 2:48 PM, Dale Henrichs <[hidden email]> wrote:

Well you still need the `$GS_HOME/sys/stones/<stone-name>/*` disk structure for tODE to work (whether or not it is a foreign stone) .... Did you use $GS_HOME/bin/attachForeignStone create the foreign stone?

If so it looks like I did not anticipate (or think very hard about)that a foreign stone would include a _recent version_ of tODE in a foreign stone. My tests involved testing against foreign stones with old versions of tODE installed.

There are a number of moving parts in this case ... the latest tODE code expects the full set of env vars to be set up (`source $GS_HOME/bin/defGsDevKit.env`) and the full range of GEMSTONE env vars (`source $GS_HOME/server/stones/<stone-name>/stone.env`) ... so these would need to be done before starting your netldi ... Then you'd need to have the directory structure I referred to in my previous message (`$GS_HOME/sys/stones/<stone-name>/*) ...

YEs, that all make sense. In fact, I think these stone was working before with tODE and gsDevKitHome but I needed to run that special code to build the /sys/ directory. Remember? It was some weeks/months ago.

Yeah I do remember ... and I've changed the directory structure twice (so far:) for GsDevKit_home and GsDevKit_home is structured differently than gsDevKitHome... It's been hard enough for me to worry about getting the structure set up correctly and make sure that things run smoothly for stones built and managed completely under GsDevKit_home ... The $GS_HOME/attachOldDevKitStone was intended to work with stones that were built with gsDevKitHome, but your stones are built completely differently and I haven't created scripts for your scenario:(

 

The script in $GS_HOME/bin/private/attachStone is probably what you need (the bit where `$foreign = false`).

You are a special case in that you have foreign stones, that you want treated more like and "old stone" except that you will be starting/stopping the netldis using your own scripts ... so it is appropriate to create the `$GS_HOME/sys/stones/<stone-name>/` structure ... if it would help I could add another option to the $GS_HOME/bin/private/attachStone script that just build the $GS_HOME/sys/stones structure fresh from scratch without copying from an existing locatioin ...

I am bit confused. Let's say I removed my old gsDevKitHome (I may get it back from TimeMachine). How should I do it? I tried this:

 $GS_HOME/bin/attachForeignStone foreignStone 3.1.0.6

And then I edited $GS_HOME/sys/local/sessions/foreignStone with the correct data.

A dummy $GS_HOME/server/stones/foreignStone/   is created correctly. 

However, what doesn't make created is $GS_HOME/sys/local/server/stones/foreginStone ... 

It seems that when passing -f  to the attachStone the /sys/local/server/stpnes/ doesn't get created?

That is correct ... like I said initially ... I assumed that you would not update the foreign stone to use the latest tODE ... so my assumptions are correct and I don't have a script that will will help you ---- if you didn't update tODE, then your stone would have continued to function correctly  --- you stone was not created with gsDevKitHome so I don't have a local stone that I can use to figure out how to solve your problem ...

I am running a bit short of time as it is ... as I have more work ahead of me writing documentation for tODE and getting things running smoothly for the system that is running vanilla GsDevKit_home ...

I thought you were going to convert to using the scripts and structure for GsDefKit_home ... I didn't realize that you were going to try to keep your old structure and use the new scripts and new tODE ...

Dale, as a personal opinion, I think that being able to start using gsDevKit_home and tODE, even a small part of it, with foreign stone, is a very good idea. I mean, it's a first entry, a first place where someone can do a first step to later continue. So I think that efforts in this area should be worth.

Right but the new tODE is written assuming that all of the env vars are set correctly ... which means that you need to start your netldi exactly the same way that it is started with GsDevKit_home ... the start/stop stone scripts are less important than the netldi script ... now the startNetldi script doesn't work with a foreign stone, because it depends upon the knowing what the stone directly structure looks like and by definition I don't know that for a foreign stone ...

Thoughts?  As an example, this will help me to run tODE scripts (stored in $GS_HOME/sys/local/server/home) as part of my upgrade process.

It is very hard for me to consider supporting stones that are not being started/stopped managed with the GsDevKit_home scripts ... I am finding that I am spending a lot of time dealing with issues that are coming up by folks not using the standard scripts ... the whole point of having standard scripts is so that the system can take advantage of knowing where things are and the system can assume that the env vars are set the same, disc structure is known, etc. ... and right now while I still find myself changing scripts, i cannot worry about how my changes will impact unknown structures ...

Like I said earlier, I thought you were going to move toward using the GsDevKit_home structures and scripts and I think that updating tODE in "foreign stones" and then having me figure out what might be wrong with the structure is not very efficient...

Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

On 10/24/15 7:22 PM, Mariano Martinez Peck wrote:
> BTW...dumb question... where I should have run the attach script? In
> the server or in my local machine (where I have the client running).
> I guess in the server... but not sure hahahahha
the stone scripts need to be run on the stone machine ... the only thing
the client cares about is where the sessions directory can be found ...
all of the real moving parts are on the server machine

Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

On 10/25/15 1:36 PM, Mariano Martinez Peck wrote:
> Hi Dale,
>
> Thanks for the explanation. There has been indeed a confusion in our
> communication. I thought I could still re-build a /sys/local/ kind of
> stuff for a foreign stone and still using new tODE and new gsDevKit_home.

Well you can, but you have to figure out how to get it done ... env vars
need to be defined before netldi is called then the `script
--script=setUpSys` or `script --script=rebuildSys` scripts need to be
used to create the directory structure ... the one to use depends upon
which one works for you and perhaps edits need to be made to
`rebuildSys` or `setUpSys` to compensate for the places where your stone
doesn't match up with what is expected ....

As I mentioned on the glass list, all of the scripts are in the
$GS_HOME/sys/default/client/tode-scripts directory and they can be
customized by copying to _your_ $GS_HOME/sys/local/client/tode-scripts
directory and changing as needed ... like remove all of the `bu
snapshot` calls ...
> Anyway, I can still use tODE (for everything, browsing classes, debug
> continuations, etc etc etc). The only thing I cannot use is all the
> sys directory layout for scripts and friends. But I can live this way
> until I fully migrate (hopefully after Smalltalks).
>
> With what you have said, then I agree this should not be your higher
> priority and makes sense not to continue with my weird scenario.
>

I would love to help, but as I said I'm heads down to get the "common
cases" working smoothly ...

Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.