[tode_st] Small improvement to GsDevKitEvaluateTodeCommandLineHandler, possible?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[tode_st] Small improvement to GsDevKitEvaluateTodeCommandLineHandler, possible?

Mariano Martinez Peck
Dale,

As you know, I am still not using the gsDevKit_home based stones yet I do use some of the other features and I do use tODE. I would love to be able to do this:

% todeIt myDescriptionName bu snapshot xxxBeforeMigration.dbf

If I have a description in tODE with 'myDescriptionName' then that should work. From what I see, all you need from the "stones" folder is the file info.ston, which contains only something like this:

GsDevKitStoneInfo {
#stoneName : 'mariano',
#gsVers : '3.2.9',
#username : nil
}

All that info CAN BE get from the description file, so no need of a "stone" directory. 
So I wonder, can we change the following code:

An attempt to use interactive tools detected, while in non-interactive mode
FileDoesNotExistException: '/Users/mariano/gemstone/GsDevKit_home/server/stones/quuve/info.ston'
NonInteractiveUIManager>>nonInteractive:
NonInteractiveUIManager>>fileDoesNotExistsDefaultAction:
FileDoesNotExistException>>defaultAction
UndefinedObject>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
FileDoesNotExistException(Exception)>>signal
MultiByteFileStream class(StandardFileStream class)>>readOnlyFileNamed:
FileStream class>>readOnlyFileNamed:
FileStream class>>readOnlyFileNamed:do: in Block: [ self readOnlyFileNamed: fileName ]
FileStream class>>detectFile:do:
FileStream class>>readOnlyFileNamed:do:
GsDevKitStoneInfo class>>importFrom:
GsDevKitEvaluateTodeCommandLineHandler(GsDevKitAbstractCommandLineHandler)>>stoneInfo

So that if the "stones" folder doesn't exist, it searches in the descriptions to see if there is a corresponding one and get the info from there?  This would really help guys which want to script with tODE yet does not have all the stones 100% managed by gsDevKit .
As for myself, this will ease for example, the "upgrade" process.

Thoughts? 

--
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.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] Small improvement to GsDevKitEvaluateTodeCommandLineHandler, possible?

Dale Henrichs-3
... let's see, I don't think that you've given me the full stack so I'm not quite sure where the stoneInfo call is coming from ... and whether this is coming from a gsDevKitHome or GsDevKit_home environment...

If the stack includes a call to GsDevKitAbstractCommandLineHandler>>shouldNotBeForeignStone, then you are using GsDevKit_home environment and I'm thinking that I was too aggressive in marking the todeIt as something that shouldn't be done for "foreign stones" ... I'm trying to prevent start/stop stone/netldi and backup/restore operations (the script kind), because a foreign stone is being controlled by a separate set of scripts ...

So when I  fix the shouldNotBeForeignStone call for the todeIt command then the stoneInfo file won't be accessed anymore ... because you are right only the login information is needed ...

In the mean time, if you are using the latest version of GsDevKit_home master branch, you can run `$GS_HOME/bin/devKitCommandLIne -D` and edit the GsDevKitEvaluateTodeCommandLineHandler>>activate method to remove the shouldNotFeForeignStone call yourself ... just save the image after ...

The official fix should be available with my next drop (today or tomorrow) of GsDevKit_home and you'll be rebuilding the tode clients then anyway ...

Dale

On 10/19/2015 08:51 AM, Mariano Martinez Peck wrote:
Dale,

As you know, I am still not using the gsDevKit_home based stones yet I do use some of the other features and I do use tODE. I would love to be able to do this:

% todeIt myDescriptionName bu snapshot xxxBeforeMigration.dbf

If I have a description in tODE with 'myDescriptionName' then that should work. From what I see, all you need from the "stones" folder is the file info.ston, which contains only something like this:

GsDevKitStoneInfo {
#stoneName : 'mariano',
#gsVers : '3.2.9',
#username : nil
}

All that info CAN BE get from the description file, so no need of a "stone" directory. 
So I wonder, can we change the following code:

An attempt to use interactive tools detected, while in non-interactive mode
FileDoesNotExistException: '/Users/mariano/gemstone/GsDevKit_home/server/stones/quuve/info.ston'
NonInteractiveUIManager>>nonInteractive:
NonInteractiveUIManager>>fileDoesNotExistsDefaultAction:
FileDoesNotExistException>>defaultAction
UndefinedObject>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
FileDoesNotExistException(Exception)>>signal
MultiByteFileStream class(StandardFileStream class)>>readOnlyFileNamed:
FileStream class>>readOnlyFileNamed:
FileStream class>>readOnlyFileNamed:do: in Block: [ self readOnlyFileNamed: fileName ]
FileStream class>>detectFile:do:
FileStream class>>readOnlyFileNamed:do:
GsDevKitStoneInfo class>>importFrom:
GsDevKitEvaluateTodeCommandLineHandler(GsDevKitAbstractCommandLineHandler)>>stoneInfo

So that if the "stones" folder doesn't exist, it searches in the descriptions to see if there is a corresponding one and get the info from there?  This would really help guys which want to script with tODE yet does not have all the stones 100% managed by gsDevKit .
As for myself, this will ease for example, the "upgrade" process.

Thoughts? 
--
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.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] Small improvement to GsDevKitEvaluateTodeCommandLineHandler, possible?

Mariano Martinez Peck


On Mon, Oct 19, 2015 at 3:36 PM, Dale Henrichs <[hidden email]> wrote:
... let's see, I don't think that you've given me the full stack so I'm not quite sure where the stoneInfo call is coming from ... and whether this is coming from a gsDevKitHome or GsDevKit_home environment...


Sorry for the lazy description. It was in GsDevKit_home (I will try not to use gsDevKitHome anymore) and the full stack is this:

% todeIt mariano bu snapshot quuve-original.dbf
=================
   GsDevKit script: todeIt mariano bu snapshot quuve-original.dbf
              path: /Users/mariano/gemstone/GsDevKit_home/bin/todeIt
=================
performing tode command: __bu snapshot quuve-original.dbf__
An attempt to use interactive tools detected, while in non-interactive mode
FileDoesNotExistException: '/Users/mariano/gemstone/GsDevKit_home/server/stones/mariano/info.ston'
NonInteractiveUIManager>>nonInteractive:
NonInteractiveUIManager>>fileDoesNotExistsDefaultAction:
FileDoesNotExistException>>defaultAction
UndefinedObject>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
FileDoesNotExistException(Exception)>>signal
MultiByteFileStream class(StandardFileStream class)>>readOnlyFileNamed:
FileStream class>>readOnlyFileNamed:
FileStream class>>readOnlyFileNamed:do: in Block: [ self readOnlyFileNamed: fileName ]
FileStream class>>detectFile:do:
FileStream class>>readOnlyFileNamed:do:
GsDevKitStoneInfo class>>importFrom:
GsDevKitEvaluateTodeCommandLineHandler(GsDevKitAbstractCommandLineHandler)>>stoneInfo
GsDevKitEvaluateTodeCommandLineHandler(GsDevKitAbstractCommandLineHandler)>>shouldNotBeForeignStone
GsDevKitEvaluateTodeCommandLineHandler>>activate
GsDevKitEvaluateTodeCommandLineHandler class(CommandLineHandler class)>>activateWith:
PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ]
BlockClosure>>on:do:
PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand:
PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand
PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument:
PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self handleArgument: (self arguments ifEmpty: [ ...etc...
BlockClosure>>on:do:
PharoCommandLineHandler(BasicCommandLineHandler)>>activate
PharoCommandLineHandler>>activate
PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
PharoCommandLineHandler class>>activateWith: in Block: [ super activateWith: aCommandLine ]
WorldState>>runStepMethodsIn:
WorldMorph>>runStepMethods
 
If the stack includes a call to GsDevKitAbstractCommandLineHandler>>shouldNotBeForeignStone, then you are using GsDevKit_home environment and I'm thinking that I was too aggressive in marking the todeIt as something that shouldn't be done for "foreign stones" ... I'm trying to prevent start/stop stone/netldi and backup/restore operations (the script kind), because a foreign stone is being controlled by a separate set of scripts ...


Exactly. I does appear a shouldNotBeForeignStone in the stack. And I does make sense #shouldNotBeForeignStone to prevent some of the stuff that would break when using foreign stones. However, there are other cases that could work without problem. 
  
So when I  fix the shouldNotBeForeignStone call for the todeIt command then the stoneInfo file won't be accessed anymore ... because you are right only the login information is needed ...

Exactly. 
 

In the mean time, if you are using the latest version of GsDevKit_home master branch, you can run `$GS_HOME/bin/devKitCommandLIne -D` and edit the GsDevKitEvaluateTodeCommandLineHandler>>activate method to remove the shouldNotFeForeignStone call yourself ... just save the image after ...

Thanks. Ok, I will see if I can wait for your next drop, and if not, I will do that the above or either create a dummy info.ston (I did that to confirm that what I pasted below does work for foreign stones)
 

The official fix should be available with my next drop (today or tomorrow) of GsDevKit_home and you'll be rebuilding the tode clients then anyway ...


Great. That super good to hear. Because then, as part of my upgrade process for example, I can run the following with my FOREIGN stone:

todeIt mariano bu snapshot quuve-original.dbf
todeIt mariano eval \`\(AllUsers userWithId: \#SystemUser\) password: \'swordfish\'. System commitTransaction.\`
todeIt mariano bu snapshot quuve-readyForMigration.dbf

and that is ... lovely :)

 
Dale


On 10/19/2015 08:51 AM, Mariano Martinez Peck wrote:
Dale,

As you know, I am still not using the gsDevKit_home based stones yet I do use some of the other features and I do use tODE. I would love to be able to do this:

% todeIt myDescriptionName bu snapshot xxxBeforeMigration.dbf

If I have a description in tODE with 'myDescriptionName' then that should work. From what I see, all you need from the "stones" folder is the file info.ston, which contains only something like this:

GsDevKitStoneInfo {
#stoneName : 'mariano',
#gsVers : '3.2.9',
#username : nil
}

All that info CAN BE get from the description file, so no need of a "stone" directory. 
So I wonder, can we change the following code:

An attempt to use interactive tools detected, while in non-interactive mode
FileDoesNotExistException: '/Users/mariano/gemstone/GsDevKit_home/server/stones/quuve/info.ston'
NonInteractiveUIManager>>nonInteractive:
NonInteractiveUIManager>>fileDoesNotExistsDefaultAction:
FileDoesNotExistException>>defaultAction
UndefinedObject>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
FileDoesNotExistException(Exception)>>signal
MultiByteFileStream class(StandardFileStream class)>>readOnlyFileNamed:
FileStream class>>readOnlyFileNamed:
FileStream class>>readOnlyFileNamed:do: in Block: [ self readOnlyFileNamed: fileName ]
FileStream class>>detectFile:do:
FileStream class>>readOnlyFileNamed:do:
GsDevKitStoneInfo class>>importFrom:
GsDevKitEvaluateTodeCommandLineHandler(GsDevKitAbstractCommandLineHandler)>>stoneInfo

So that if the "stones" folder doesn't exist, it searches in the descriptions to see if there is a corresponding one and get the info from there?  This would really help guys which want to script with tODE yet does not have all the stones 100% managed by gsDevKit .
As for myself, this will ease for example, the "upgrade" process.

Thoughts? 
--
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.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] Small improvement to GsDevKitEvaluateTodeCommandLineHandler, possible?

Dale Henrichs-3


On 10/19/2015 11:52 AM, Mariano Martinez Peck wrote:


On Mon, Oct 19, 2015 at 3:36 PM, Dale Henrichs <[hidden email]> wrote:
... let's see, I don't think that you've given me the full stack so I'm not quite sure where the stoneInfo call is coming from ... and whether this is coming from a gsDevKitHome or GsDevKit_home environment...


Sorry for the lazy description. It was in GsDevKit_home (I will try not to use gsDevKitHome anymore) and the full stack is this:

% todeIt mariano bu snapshot quuve-original.dbf
=================
   GsDevKit script: todeIt mariano bu snapshot quuve-original.dbf
              path: /Users/mariano/gemstone/GsDevKit_home/bin/todeIt
=================
performing tode command: __bu snapshot quuve-original.dbf__
An attempt to use interactive tools detected, while in non-interactive mode
FileDoesNotExistException: '/Users/mariano/gemstone/GsDevKit_home/server/stones/mariano/info.ston'
NonInteractiveUIManager>>nonInteractive:
NonInteractiveUIManager>>fileDoesNotExistsDefaultAction:
FileDoesNotExistException>>defaultAction
UndefinedObject>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
FileDoesNotExistException(Exception)>>signal
MultiByteFileStream class(StandardFileStream class)>>readOnlyFileNamed:
FileStream class>>readOnlyFileNamed:
FileStream class>>readOnlyFileNamed:do: in Block: [ self readOnlyFileNamed: fileName ]
FileStream class>>detectFile:do:
FileStream class>>readOnlyFileNamed:do:
GsDevKitStoneInfo class>>importFrom:
GsDevKitEvaluateTodeCommandLineHandler(GsDevKitAbstractCommandLineHandler)>>stoneInfo
GsDevKitEvaluateTodeCommandLineHandler(GsDevKitAbstractCommandLineHandler)>>shouldNotBeForeignStone
GsDevKitEvaluateTodeCommandLineHandler>>activate
GsDevKitEvaluateTodeCommandLineHandler class(CommandLineHandler class)>>activateWith:
PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ]
BlockClosure>>on:do:
PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand:
PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand
PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument:
PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self handleArgument: (self arguments ifEmpty: [ ...etc...
BlockClosure>>on:do:
PharoCommandLineHandler(BasicCommandLineHandler)>>activate
PharoCommandLineHandler>>activate
PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
PharoCommandLineHandler class>>activateWith: in Block: [ super activateWith: aCommandLine ]
WorldState>>runStepMethodsIn:
WorldMorph>>runStepMethods
 
If the stack includes a call to GsDevKitAbstractCommandLineHandler>>shouldNotBeForeignStone, then you are using GsDevKit_home environment and I'm thinking that I was too aggressive in marking the todeIt as something that shouldn't be done for "foreign stones" ... I'm trying to prevent start/stop stone/netldi and backup/restore operations (the script kind), because a foreign stone is being controlled by a separate set of scripts ...


Exactly. I does appear a shouldNotBeForeignStone in the stack. And I does make sense #shouldNotBeForeignStone to prevent some of the stuff that would break when using foreign stones. However, there are other cases that could work without problem. 
  
So when I  fix the shouldNotBeForeignStone call for the todeIt command then the stoneInfo file won't be accessed anymore ... because you are right only the login information is needed ...

Exactly. 
 

In the mean time, if you are using the latest version of GsDevKit_home master branch, you can run `$GS_HOME/bin/devKitCommandLIne -D` and edit the GsDevKitEvaluateTodeCommandLineHandler>>activate method to remove the shouldNotFeForeignStone call yourself ... just save the image after ...

Thanks. Ok, I will see if I can wait for your next drop, and if not, I will do that the above or either create a dummy info.ston (I did that to confirm that what I pasted below does work for foreign stones)
 

The official fix should be available with my next drop (today or tomorrow) of GsDevKit_home and you'll be rebuilding the tode clients then anyway ...


Great. That super good to hear. Because then, as part of my upgrade process for example, I can run the following with my FOREIGN stone:

todeIt mariano bu snapshot quuve-original.dbf
todeIt mariano eval \`\(AllUsers userWithId: \#SystemUser\) password: \'swordfish\'. System commitTransaction.\`
todeIt mariano bu snapshot quuve-readyForMigration.dbf

and that is ... lovely :)


Haha ... now all of my work has been worthwhile:)

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.