-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
need to create the extra disk structure expected by tODE #4
Comments
see also dalehenrich/tode#322 |
…terProduct.solo tested and validated
…stry= --template=default_seaside --start gs_3.6.6 3.6.6
…e stone; implement destroy stone
…the stone directory (i.e., where a .GDKStoneSpec.ston file is located) the --registry and <stone-name> are not required
….. remove from scripts and make sure the spots where GEMSTONE is needed are covered
…r ... had embedded '$' which was wrong
…ode work to do ... clean up STONES_DATA_HOME definition ... can use customenv to run topaz in stone directory and run solo scripts
…ted. need to create the the stone-specific metadata for tode and create the session description
…. however tODE GUI is not quite happy ... session description issues ...
Did a loadTode.stone with customenv sourced ... and tODE loads, however, using tODE client on remote machine, is logging in, but I get the following project list contents:
PharoCompatibility project is not loaded ... but it seems to be connected to a repository. The repository paths are valid, but the extraction of the git information fails |
… tests are still failing ... need to revamp the tode_shared directory structure
tODE comes up and can be used to work with code (haven't done this extensively), however the project entry and object/filesystem access code is not functional ... namely $GS_HOME/sys/default/client/tode-scripts/setUpSys does not run correctly ... I suspect that there is code on the client that is executed during login that properly initializes the server ... we've got a properly setup TDSessionDescription, so we've got all the pieces ... just need to glue them together properly.
…class used by todeIt script to execute tode commands, so it will have most if not all of the magic needed to properly login ... then we'll see
…dGetOpts, and TodeCommandError was the ticket (to loading cleanly)
…t_stones structure to perform login using TDSessionDescription
…ommands along to remote tODE image ... superDoit does not do well with passing args with embedded spaces, so going with plan B
…jects which is not desirable ... command line handling for 'eval 3+4' is a bit funky at the moment ... but we're getting a resultgit commit -mIssue
…) ... successful load of GsDevKit_stones-GLASS package
…w more commands, before addressing the tODE test failures (run failing tests using --debugGem)
…result is a fair accounting of the the command return value (printString of the object) ... the client forwarder calls may offer access to the actual objects ... worth chasing a bit more
…whole tODE window implementation ... which is not really necessary ... todeIt.solo is to be used to perform operations using tODE commands ... and not provide an interactive experience
…ready in earlier versons of Rowan
…tone ... and it does look like it is the REQUIRED script to populate the tode directory structure correctly ... --repair option is the ticket
Test status as of most recent commit (testProjectBrowse new failure):
|
…up createStone/solo/deleteStone.solo (with tODE load part of createStone.solo) ... todeIt.solo eval 3+4 works ... now need to get the setUpSys_1, validateStoneSysteNodes.stone, setUpSys_2 sequence running; then resume attack on failing tests
…esults in a properly structured tODE directory structure ... major progress
…ctCommandTests>>testProjectNew fails because $GS_SERVER_STONES env var not defined
…from a loadTode.stone called by a .solo script ...
…ests are passing ... TDGemStoneCommandTests remaining
tode directory:
and backup directory.
These tODE tests are failing:
The text was updated successfully, but these errors were encountered: