Work in Progress eventual replacement for glassdb/glass project
Gofer new
package: 'GsUpgrader-Core';
repository: (MCGitHubRepository location: 'github://GsDevKit/gsUpgrader:dev/repository');
load.
(Smalltalk at: #GsUpgrader) upgradeGsDevKit.
master GsDevKit project
Home Page: http://gsdevkit.github.io/GsDevKit_home
License: MIT License
from GemStone internal bug 46040 report:
On foos there is this entry in /etc/services
gs64ldi 50377/tcp # Gemstone netldi
which is a different port number than we have in our services on ldap .
It was possibly put there by a GsDevKit install ,
and should be deleted.
There is a perl script
/export/localnew/scripts/qrysrv
which will query for the existance of a service ; if a machine is on ldap
and the ldap services has a definition it returns it. Perhaps the GsDevKit
installer could query before writing to /etc/services .
so if LDAP is in use and an entry for gs64ldi is present, then the shared memory set step can be bypassed by creating the file $GS_HOME/bin/.sharedMemorySysSetup
should be created as described here until this bug is fixed
According to this pull request against msysgit symbolic links will not be supported on windows ... I was using a symbolic link to for $GS_HOME/sys/local
on the client ($GS_HOME/sys/stones is also a symbolic link, but it is not used in a client install).
It looks like I will have to refactor and relocate the GsDevKit_sys_local project ... luckily the restructuring should be recognized as a rename by git ... but I have no idea what the impact will be on existing data committed and uncommitted ... If I am lucky, I will be able to write a repair script ...
the only drawback is that it isn't convenient to have to munge around in the $GS_SERVER_STONES directory to find the session descriptions and the client still will need the session descriptions in a single directory ... don't like symbolic links because it's too easy to break the link inadvertently (delete stone directory without cleaning session descriptions) ...
If the link goes from stone to session descriptions it is again too easy to accidentally break the link...
It still makes sense to have only one guy:(
Installation
Scripts
tODE
Existing Projects
as a corollary to this I'd once i hit the installation page, I'd like a "prominent link" to the sample script (or the sample script is at top with explanation to follow?) ...
My rationale is that for some of these steps I want to use the example script multiple times after I've read the detailed documentation ... so knowing that it exists and finding are two different things:)
It would be nice to control GemStone/S from Emacs. Emacs has an ffi named elisp-ffi we could use.
from @martinmcclure)
In GsDevKit_home/docs/installation/configOSForSingleNode.md, it should specify that the "Linux" instructions are for Ubuntu, and which Ubuntu version it's for (14.04, I'd guess, but I don't know?). Package names and commands vary by distro. Over time we'll probably provide instructions for more distros, or provide a repo that has the appropriate prereqs.
The port forwarding doc is written from the perspective of a 3.1.0.6 user, but with 3.2, the process is greatly simplified since the port range is no longer required .. need to update the doc for 3.2 while preserving the 3.1.0.6 information for posterity ...
Don't really want folks to have the $GEMSTONE family of env vars in their environment, because there could be issues with polluting another stone with a $GEMSTONE and friends defined ... best to keep the environments completely separated ...
see GsDevKit/gsDevKitHome#47 for original report
Useful information in this doc on gsDevKitHome needs to be preserved
Bob was running with a private build where the fast dirctory was deleted and got this odd error message in the log:
Error running shell command: '/ghana3/users/bretlb/tode/_home/server/bin/gs/startGemstone'
with args:
STDOUT: '=================
GsDevKit GemStone script: startGemstone
=================
Missing password file /ghana3/users/bretlb/tode/_home/server/stones/gs_340/product/seaside/etc/gemstone.secret
'
STDERR: Error: Shell command: '/ghana3/users/bretlb/tode/_home/server/bin/gs/startGemstone' failed.
GsDevKitStartstoneCommandLineHandler class(Object)>>error:
This logic is in Smalltalk, so I should catch startStone errors and check to see that the directory exists before passing on the error output ...
Federico Mennite reported the following problem when trying to install ion Windows 10:
Here's the command output:
$ installClient |& tee $GS_HOME/install.log
=================
GsDevKit script: installClient
path: /c/Users/mennite/Documents/GitHub/GsDevKit_home/bin/installClient
=================
=================
GsDevKit script: setupGsDevKit client
path: /c/Users/mennite/Documents/GitHub/GsDevKit_home/bin/setupGsDevKit
=================
=================
GsDevKit script: installOsPrereqs client
path: /c/Users/mennite/Documents/GitHub/GsDevKit_home/bin/utils/installOsPrereqs
=================
[Error] This script only works on a 64-bit Linux or Mac OS X machine
The result from "uname -sm" is "MSYS_NT-10.0-WOW i686"
Upgrading to 3.3.0 from 3.2.12 using GsUpgrader class>>upgradeGLASSForGsDevKit_home
results in the following error during tODE install:
========>Server Stack: 'AssertionFailure: Assertion failed'
1 [] in ExecBlock1 (GsUpgrader class) >> batchErrorHandlingDo: @8 line 9 [GsNMethod 292858881]
2 AssertionFailure (AbstractException) >> _executeHandler: @4 line 8 [GsNMethod 205057793]
3 AssertionFailure (AbstractException) >> _signalWith: @1 line 1 [GsNMethod 205058817]
4 AssertionFailure (AbstractException) >> signal: @3 line 7 [GsNMethod 205063681]
5 AssertionFailure class (AbstractException class) >> signal: @3 line 4 [GsNMethod 205047809]
6 MetacelloProjectRegistration (Object) >> assert: @4 line 4 [GsNMethod 234370305]
7 MetacelloProjectRegistration >> configurationProjectSpec: @5 line 9 [GsNMethod 309247233]
8 [] in ExecBlock1 (MetacelloMCBaselineOfProjectSpec) >> copyForRegistration:onWrite: @6 line 13 [GsNMethod 309942017]
9 ExecBlock1 (ExecBlock) >> cull: @7 line 4 [GsNMethod 234455297]
10 [] in ExecBlock0 (MetacelloProjectRegistration) >> configurationProjectSpecIfPresent:ifAbsent: @3 line 2 [GsNMethod 309429761]
11 MetacelloMCProjectSpec (Object) >> ifNotNil:ifNil: @6 line 14 [GsNMethod 202736129]
12 MetacelloProjectRegistration >> configurationProjectSpecIfPresent:ifAbsent: @3 line 2 [GsNMethod 309688321]
13 [] in ExecBlock0 (MetacelloMCBaselineOfProjectSpec) >> copyForRegistration:onWrite: @3 line 10 [GsNMethod 310034177]
14 UndefinedObject (Object) >> ifNotNil:ifNil: @10 line 17 [GsNMethod 202736129]
15 MetacelloProjectRegistration >> baselineProjectSpecIfPresent:ifAbsent: @3 line 2 [GsNMethod 309248513]
16 MetacelloMCBaselineOfProjectSpec >> copyForRegistration:onWrite: @3 line 4 [GsNMethod 309849601]
17 [] in ExecBlock1 (MetacelloScriptEngine) >> lock @4 line 18 [GsNMethod 300919553]
18 MetacelloProjectRegistration >> copyOnWrite: @9 line 13 [GsNMethod 309684993]
19 [] in ExecBlock2 (MetacelloScriptEngine) >> lock @3 line 15 [GsNMethod 300534273]
20 [] in ExecBlock1 (MetacelloProjectRegistration class) >> registrationForProjectSpec:ifAbsent:ifPresent: @3 line 6 [GsNMethod 309421057]
21 [] in ExecBlock1 (MetacelloProjectRegistry) >> registrationFor:ifPresent:ifAbsent: @3 line 10 [GsNMethod 233868545]
22 Dictionary (AbstractDictionary) >> at:ifPresent: @5 line 6 [GsNMethod 234326529]
23 MetacelloProjectRegistry >> registrationFor:ifPresent:ifAbsent: @17 line 9 [GsNMethod 226545409]
24 MetacelloProjectRegistration class >> registrationForProjectSpec:ifAbsent:ifPresent: @6 line 5 [GsNMethod 309711617]
25 [] in ExecBlock0 (MetacelloScriptEngine) >> lock @8 line 8 [GsNMethod 300148993]
26 ExecBlock0 (ExecBlock) >> ensure: @2 line 12 [GsNMethod 203455233]
27 MetacelloProjectRegistration class >> copyRegistryRestoreOnErrorWhile: @9 line 14 [GsNMethod 309252097]
28 MetacelloScriptEngine >> lock @3 line 4 [GsNMethod 300812801]
29 MetacelloScriptEngine (Object) >> perform:withArguments: @1 line 1 [GsNMethod 203166721]
30 [] in ExecBlock1 (MetacelloScriptExecutor) >> execute: @12 line 15 [GsNMethod 309661697]
31 [] in ExecBlock1 (MetacelloScriptApiExecutor) >> executeString:do: @6 line 6 [GsNMethod 309663745]
32 Array (Collection) >> do: @6 line 10 [GsNMethod 203580417]
33 MetacelloScriptApiExecutor >> executeString:do: @7 line 4 [GsNMethod 309537793]
34 String >> execute:against: @2 line 2 [GsNMethod 234352641]
35 MetacelloScriptApiExecutor (MetacelloScriptExecutor) >> execute: @7 line 9 [GsNMethod 309540353]
36 Metacello >> execute:args: @9 line 5 [GsNMethod 300721665]
37 Metacello >> lock @2 line 4 [GsNMethod 300720641]
38 [] in Executed Code @57 line 38 [GsNMethod 310142209]
39 ExecBlock0 (ExecBlock) >> on:do: @3 line 44 [GsNMethod 203448321]
40 GsUpgrader class >> batchErrorHandlingDo: @3 line 3 [GsNMethod 240173569]
41 Executed Code @4 line 6 [GsNMethod 309891073]
42 <Reenter marker>
To workaround this issue, edit the $GS_HOME/sys/default/client/server-bootstrap-scripts/upgradeGLASS.ws
file to change line 51 from:
(Smalltalk at: #'GsUpgrader') upgradeGLASSForGsDevKit_home ]
to:
(Smalltalk at: #'GsUpgrader') upgradeGLASS ]
For windows the only prerequisite is to install GitHub for Windows which includes a bash shell.
For mac one must install XCode from the app store (to get git) and then the installOsPrereqs script configures the system for shared memory.
For Ubuntu, there is a laundry list of packages that need to be installed and apt-get
does the job ...
Other non-Ubuntu Linux systems have package managers similar to apt-get
and we need to automate each one as well as make it straightforward for:
The following (from @mariano) can form the basis for a "how to contribute to GsDevKt FAQ:
Steps:
1) I assume I have already al gsDevKit_home projects already clone to local machine. If not true, then you must use:
$GS_HOME/bin/utils/cloneSharedTodeProjects both
2) Go to github and fork RB.
3) From OS shell:
cd $GS_HOME/shared/repos/rb
git remote add rbMariano [email protected]:marianopeck/rb.git
git branch marianodev
git checkout marianodev
git pull origin dev # in this case this is particularly because I wanted dev branch
4) From tODE shell
edit /sys/stone/projects/RB #Here add gitCheckout: 'marianodev'; gitRemoteName: 'rbMariano';
project load RB
5) From tODE, do my changes in RB and commit to filetree repo
7) From OS shell:
git commit -a -m "Fix to xxxx"
git push rbMariano marianodev
8) Got to your fork in github and make a Pull Request.
9) Once the issue is integrated, do again a "edit /sys/stone/projects/RB " to put back "origin/master"
When running code commands from $GS_HOME/bin/devKitCommandLine
servers are caught and the stack is dumped to stdout, followed by the client stack ... since the server stack is the primary error, it should come second, since some folks will ignore the first stack and send me the second (less useful) stack in email ...
@marianopeck has a separate OS user and GemStone user (not DataCurator) for each of his stones.
Here are several checkpoints discussed in Buenos Aires:
su
if $OS_USER is not the same as $USERThe basic plan is to create a branch for this issue and start making changes (shared with @marianopeck) until we get things in good enough shape to merge into the master branch.
@marianopeck, could you chime in with anything I might have missed?
With the new GsUpgrader feature for caching mcs file during upgradeGlass, we now need a way to clear the caches ... also need to modify the tODE install workspaces to use the caching call
I realize this is already on your todo list but an explicit issue is nice for tracking purposes.
I may be able to do this myself as I am reading the SysAdmin guide. If I recall correctly, this is mostly setting up shared memory and file descriptor limits, disks, swap partitions, etc.
Not sure if there is any additional configuration on the server specific to GsDevKit_home
avoid namespace issues with some of the more common script names like servers
, status
, etc.
Of course, this assumes that the system prereqs and shared memory are set up as part of vm creation by someone else with sudo permissions.
In addition to .osPrereqsSysSetup
, installOsPrereqs script needs .sharedMemorySysSetup
committed a fix here, but we'll need folks to run updateGsDevKit -g
to pickup fix ... reminder to include that in next release PR ...
In
GsDevKit_home/docs/installation/installDevKitServerAndClient.md
section 3. Set the environment says
"export GS_HOME="
This is incorrect. I assume it should say
"export GS_HOME=/GsDevKit_home"
Is there a way to get just a server installed on a remote server, and just a client installed on my laptop?
I don't want to add the 32 bit libs for pharo on the remote system, just to be able to install GS. Thanks
I have observed cases where Pharo images (clients and devKitCommandLine) get rebuilt, when not needed ... some cleanup is worthwhile
when running the upgradeSeasideImage script upgrading from a 3.2.4 to either 3.2.12 or 3.3.0 stone.
I can email you the log file if you like.
Is that a permission error I need to fix in the stone I'm upgrading?
(from @martinmcclure)
This was the output:
[Info] Setting up shared memory
Total memory available is 32149 MB
Max shared memory segment size is 4096 MB
Max shared memory allowed is -65536 MB
/home/martin/Projects/Waldorf/GsDevKit_home/bin/downloadGemStone: line 201: [: 18446744073692774399: integer expression expected
[Info] No need to increase max shared memory segment size
/home/martin/Projects/Waldorf/GsDevKit_home/bin/downloadGemStone: line 217: [: 18446744073692774399: integer expression expected
18446744073692774399 is what my system gives for /proc/sys/kernel/shmall. This is apparently the default in the kernel, since I don't have anything in /etc/sysctl.conf that sets this parameter.
18446744073692774399 is also known as 0xFFFFFFFFFEFFFFFF, legitimate (if large) 64-bit unsigned integer. Interpreted as signed, it would be -16MiB - 1. So where it's getting the -65536 MB I can't imagine.
-Martin
The new class was added to the package Change-Notification
and during the bootstrap phase of upgradeSeasideImage, an older version of the Change-Notification
package is loaded, which should result in the class being removed, but the Monticello method Class>>removeFromSystem has not yet been loaded into the system, so the upgrade fails.
The class was added at the beginning of January:
commit 51a0c4587a4c8947c7645ba486bfa713c3489ec5
Author: Dale Henrichs <[email protected]>
Date: Sun Jan 3 09:02:21 2016 -0800
So this is a recently introduced problem. The workaround (and patch to upgradeSeasideImage) is to define Class>>removeFromSystem, before starting the bootstrap:
! patch Class>>removeFromSystem as noop until proper implementation is loaded
category: '*change-notification'
method: Class
removeFromSystem
| ar |
ar := System myUserProfile dictionaryAndSymbolOf: self.
ar ifNotNil: [ (ar at: 1) removeKey: (ar at: 2) ].
%
commit
Internal GemStone bug 46059.
Well this turns out to be a sticky wicket ... when running in headless mode, the Transcript is switched to use a non interactive transcript class ... when the image is saved in headless mode the non-interactive transcript is saved ... when started in heedful mode, the transcript is not switched from non-interactive until after the startUp: code is run ... which means it is impossible to create a good transcript that is hooked up to the real Transcript instance ....
in a test upgrade, MCFileTreeFileUtils class>>current returned nil
and caused post upgrade loads to fail ... the 2.4.4.1 repo was likely running a pretty old version of GLASS as well, so it may not be worth expending too much effort to track down ... OTOH, an ounce of prevention is worth a pound of cure ...
At the end of the day, this could be a job for gsUpgrader, since we failed while running gsUpgrader:
---Step 1 of tODE bootstrap process: execute upgradeGlass.ws
-----Install GsUpgrader-Core package from http://ss3.gemtalksystems.com/ss/gsUpgrader
-----Upgrade GLASS using gsUpgrader
======================
=====Installing patchForGsDevKitIssue60: HTTPSocket
======================
=====Installing patchForGsDevKitIssue60: MCPlatformSupport class
======================
=====Detected version >=1.0-beta.9.2.1 [ConfigurationOfGLASS] of GLASS
======================
=====Upgrading GLASS to 1.0-beta.9.3
======================
=====Using default repository: http://seaside.gemtalksystems.com/ss/MetacelloRepository
Loading 1.0-beta.32.1 of ConfigurationOfMetacello...
Project: FileTree stable [1.0.6.1]
Project: Monticello 0.243 [0.244.3]
Project: GsMonticello 0.244.2
Project: Gofer stable [1.0.5.1]
Project: GsCore 0.247 [0.249]
Fetched -> Metacello-GitHub-dkh.29 --- http://seaside.gemtalksystems.com/ss/metacello --- http://seaside.gemtalksystems.com/ss/metacello
Warning: You are about to load new versions of the following packages that have unsaved changes in the image. If you continue, you will lose these changes.
Metacello-GitHub
Loaded -> Metacello-GitHub-dkh.29 --- http://seaside.gemtalksystems.com/ss/metacello --- cache
Evaluated -> 1.0-beta.32.1 [ConfigurationOfMetacello] >> metacelloPrimeRegistry
...finished 1.0-beta.32.1
======================
=====Upgrading Gofer to #stable
Loading 1.0.5.4 of ConfigurationOfGofer...
Fetched -> Gofer-Core.gemstone-dkh.138 --- http://seaside.gemtalksystems.com/ss/metacello --- http://seaside.gemtalksystems.com/ss/metacello
Starting atomic load
Loaded -> Gofer-Core.gemstone-dkh.138 --- http://seaside.gemtalksystems.com/ss/metacello --- cache
Finished atomic load
...finished 1.0.5.4
Loading 1.0-beta.9.3 of ConfigurationOfGLASS...
Fetched -> ConfigurationOfGoferProjectLoader-dkh.22 --- http://seaside.gemtalksystems.com/ss/MetacelloRepository --- http://seaside.gemtalksystems.com/ss/MetacelloRepository
Loaded -> ConfigurationOfGoferProjectLoader-dkh.22 --- http://seaside.gemtalksystems.com/ss/MetacelloRepository --- http://seaside.gemtalksystems.com/ss/MetacelloRepository
Fetched -> ConfigurationOfMetacelloPreview-dkh.60 --- http://seaside.gemtalksystems.com/ss/MetacelloRepository --- http://seaside.gemtalksystems.com/ss/MetacelloRepository
Loaded -> ConfigurationOfMetacelloPreview-dkh.60 --- http://seaside.gemtalksystems.com/ss/MetacelloRepository --- http://seaside.gemtalksystems.com/ss/MetacelloRepository
Project: Gofer 1.0.5.3 [1.0.5.4]
Project: Monticello 0.244.3
Project: Metacello previewBootstrap [1.0-beta.32.1]
Project: FileTree stable [1.0.6.1]
Project: Monticello 0.243
Project: GsMonticello 0.244.2
Project: Gofer stable [1.0.5.4]
Project: MetacelloPreview stable [1.0.0-beta.32.18]
Project: Metacello
...RETRY->BaselineOfMetacello
...RETRY->BaselineOfMetacello
gofer repository error: 'GoferRepositoryError: a MessageNotUnderstood occurred (error 2010), a UndefinedObject does not understand #''directoryExists:'''...ignoring
...FAILED->BaselineOfMetacello
========>Server Stack: 'Could not resolve: BaselineOfMetacello [BaselineOfMetacello] in cache github://dalehenrich/metacello-work:7deb62a415343f8ba8294c84c9c3438c75455fe3/repository ERROR: ''GoferRepositoryError: a MessageNotUnderstood occurred (error 2010), a UndefinedObject does not understand #''''directoryExists:'''''''
1 [] in Executed Code @8 line 37 [GsNMethod 549838849]
2 MetacelloPackageSpecResolutionError (AbstractException) >> _executeHandler: @4 line 8 [GsNMethod 31183361]
3 MetacelloPackageSpecResolutionError (AbstractException) >> _signalWith: @1 line 1 [GsNMethod 31201537]
4 MetacelloPackageSpecResolutionError (AbstractException) >> signal @2 line 47 [GsNMethod 31205889]
5 MetacelloPackageSpecResolutionError >> signal @4 line 5 [GsNMethod 547849729]
6 MetacelloEnsureFetchingMCSpecLoader (MetacelloCommonMCSpecLoader) >> retryingResolvePackageSpecReferences:gofer: @32 line 39 [GsNMethod 198625281]
7 [] in ExecBlock0 (MetacelloFetchingMCSpecLoader) >> linearLoadPackageSpec:gofer: @18 line 13 [GsNMethod 219537921]
8 MetacelloGemStonePlatform (MetacelloPlatform) >> do:displaying: @2 line 3 [GsNMethod 199332865]
9 MetacelloEnsureFetchingMCSpecLoader (MetacelloFetchingMCSpecLoader) >> linearLoadPackageSpec:gofer: @6 line 3 [GsNMethod 198749953]
10 MetacelloPackageSpec >> loadUsing:gofer: @2 line 3 [GsNMethod 220114433]
11 [] in ExecBlock1 (MetacelloCommonMCSpecLoader) >> linearLoadPackageSpecs:repositories: @3 line 6 [GsNMethod 219477505]
12 Array (Collection) >> do: @6 line 10 [GsNMethod 25125633]
13 MetacelloEnsureFetchingMCSpecLoader (MetacelloCommonMCSpecLoader) >> linearLoadPackageSpecs:repositories: @6 line 6 [GsNMethod 198625025]
14 [] in ExecBlock0 (MetacelloFetchingMCSpecLoader) >> explicitLoadPackageSpecs:repositories: @3 line 5 [GsNMethod 219533057]
15 ExecBlock0 (ExecBlock) >> ensure: @2 line 12 [GsNMethod 22673153]
16 MetacelloLoaderPolicy >> pushLoadDirective:during: @7 line 7 [GsNMethod 198830593]
17 MetacelloLoaderPolicy >> pushExplicitLoadDirectivesDuring:for: @5 line 5 [GsNMethod 198829313]
18 MetacelloEnsureFetchingMCSpecLoader (MetacelloFetchingMCSpecLoader) >> explicitLoadPackageSpecs:repositories: @4 line 5 [GsNMethod 198746369]
19 MetacelloPackageSpec >> explicitLoadUsing: @25 line 14 [GsNMethod 220111873]
20 MetacelloPackageSpec >> ensureLoadUsing: @3 line 2 [GsNMethod 220107265]
21 MetacelloMCBaselineOfProjectSpec (MetacelloMCProjectSpec) >> ensureLoadUsing: @7 line 4 [GsNMethod 220065537]
22 MetacelloMCBaselineOfProjectSpec (MetacelloMCProjectSpec) >> ensureProjectLoaded @25 line 20 [GsNMethod 546831617]
23 MetacelloMCBaselineOfProjectSpec (MetacelloMCProjectSpec) >> loadVersion: @3 line 5 [GsNMethod 220062465]
24 MetacelloProjectSpecForLoad >> performLoad @27 line 18 [GsNMethod 223550209]
25 MetacelloMCBaselineOfProjectSpec (MetacelloGenericProjectSpec) >> load @6 line 4 [GsNMethod 223635201]
26 MetacelloProjectReferenceSpec >> loadUsing:gofer: @6 line 6 [GsNMethod 216546817]
27 [] in ExecBlock1 (MetacelloCommonMCSpecLoader) >> linearLoadPackageSpecs:repositories: @3 line 6 [GsNMethod 219477505]
28 OrderedCollection (Collection) >> do: @6 line 10 [GsNMethod 25125633]
29 MetacelloFetchingMCSpecLoader (MetacelloCommonMCSpecLoader) >> linearLoadPackageSpecs:repositories: @6 line 6 [GsNMethod 198625025]
30 [] in ExecBlock0 (MetacelloFetchingMCSpecLoader) >> linearLoadPackageSpecs:repositories: @3 line 4 [GsNMethod 219534337]
31 ExecBlock0 (ExecBlock) >> ensure: @2 line 12 [GsNMethod 22673153]
32 MetacelloLoaderPolicy >> pushLoadDirective:during: @7 line 7 [GsNMethod 198830593]
33 MetacelloLoaderPolicy >> pushLinearLoadDirectivesDuring:for: @3 line 3 [GsNMethod 198827521]
34 MetacelloFetchingMCSpecLoader >> linearLoadPackageSpecs:repositories: @4 line 4 [GsNMethod 198747137]
35 MetacelloFetchingMCSpecLoader (MetacelloCommonMCSpecLoader) >> load @16 line 7 [GsNMethod 198621953]
36 MetacelloMCVersionSpecLoader >> load @14 line 16 [GsNMethod 198797057]
37 MetacelloMCVersion >> executeLoadFromArray: @10 line 7 [GsNMethod 199140609]
38 [] in ExecBlock1 (MetacelloMCVersion) >> fetchRequiredFromArray: @3 line 11 [GsNMethod 250960897]
39 [] in ExecBlock0 (MetacelloPlatform) >> useStackCacheDuring:defaultDictionary: @3 line 9 [GsNMethod 219676673]
40 ExecBlock0 (ExecBlock) >> on:do: @3 line 44 [GsNMethod 22551809]
41 MetacelloGemStonePlatform (MetacelloPlatform) >> useStackCacheDuring:defaultDictionary: @10 line 10 [GsNMethod 199333377]
42 [] in ExecBlock0 (MetacelloMCVersion) >> fetchRequiredFromArray: @7 line 11 [GsNMethod 241937665]
43 ExecBlock0 (ExecBlock) >> ensure: @2 line 12 [GsNMethod 22673153]
44 [] in ExecBlock0 (MetacelloMCVersion) >> fetchRequiredFromArray: @3 line 12 [GsNMethod 219614465]
45 MetacelloGemStonePlatform (MetacelloPlatform) >> do:displaying: @2 line 3 [GsNMethod 199332865]
46 MetacelloMCVersion >> fetchRequiredFromArray: @18 line 7 [GsNMethod 199142145]
47 [] in ExecBlock1 (MetacelloMCProjectSpec) >> loadVersion: @27 line 38 [GsNMethod 242105345]
48 [] in ExecBlock0 (MetacelloPlatform) >> useStackCacheDuring:defaultDictionary: @3 line 9 [GsNMethod 219676673]
49 ExecBlock0 (ExecBlock) >> on:do: @3 line 44 [GsNMethod 22551809]
50 MetacelloGemStonePlatform (MetacelloPlatform) >> useStackCacheDuring:defaultDictionary: @10 line 10 [GsNMethod 199333377]
51 MetacelloMCProjectSpec >> loadVersion: @22 line 24 [GsNMethod 220062465]
52 MetacelloProjectSpecForLoad >> performLoad @27 line 18 [GsNMethod 223550209]
53 MetacelloMCProjectSpec (MetacelloGenericProjectSpec) >> load @6 line 4 [GsNMethod 223635201]
54 MetacelloProjectReferenceSpec >> loadUsing:gofer: @6 line 6 [GsNMethod 216546817]
55 [] in ExecBlock1 (MetacelloCommonMCSpecLoader) >> linearLoadPackageSpecs:repositories: @3 line 6 [GsNMethod 219477505]
56 OrderedCollection (Collection) >> do: @6 line 10 [GsNMethod 25125633]
57 MetacelloFetchingMCSpecLoader (MetacelloCommonMCSpecLoader) >> linearLoadPackageSpecs:repositories: @6 line 6 [GsNMethod 198625025]
58 [] in ExecBlock0 (MetacelloFetchingMCSpecLoader) >> atomicLoadPackageSpecs:repositories: @3 line 4 [GsNMethod 219537409]
59 ExecBlock0 (ExecBlock) >> ensure: @2 line 12 [GsNMethod 22673153]
60 MetacelloLoaderPolicy >> pushLoadDirective:during: @7 line 7 [GsNMethod 198830593]
61 MetacelloLoaderPolicy >> pushAtomicLoadDirectivesDuring:for: @3 line 3 [GsNMethod 198828289]
62 MetacelloFetchingMCSpecLoader >> atomicLoadPackageSpecs:repositories: @4 line 4 [GsNMethod 198749697]
63 MetacelloFetchingMCSpecLoader (MetacelloCommonMCSpecLoader) >> load @12 line 5 [GsNMethod 198621953]
64 MetacelloMCVersionSpecLoader >> load @14 line 16 [GsNMethod 198797057]
65 MetacelloMCVersion >> executeLoadFromArray: @10 line 7 [GsNMethod 199140609]
66 [] in ExecBlock1 (MetacelloMCVersion) >> fetchRequiredFromArray: @3 line 11 [GsNMethod 250960897]
67 [] in ExecBlock0 (MetacelloPlatform) >> useStackCacheDuring:defaultDictionary: @3 line 9 [GsNMethod 219676673]
68 ExecBlock0 (ExecBlock) >> on:do: @3 line 44 [GsNMethod 22551809]
69 MetacelloGemStonePlatform (MetacelloPlatform) >> useStackCacheDuring:defaultDictionary: @10 line 10 [GsNMethod 199333377]
70 [] in ExecBlock0 (MetacelloMCVersion) >> fetchRequiredFromArray: @7 line 11 [GsNMethod 241937665]
71 ExecBlock0 (ExecBlock) >> ensure: @2 line 12 [GsNMethod 22673153]
72 [] in ExecBlock0 (MetacelloMCVersion) >> fetchRequiredFromArray: @3 line 12 [GsNMethod 219614465]
73 MetacelloGemStonePlatform (MetacelloPlatform) >> do:displaying: @2 line 3 [GsNMethod 199332865]
74 MetacelloMCVersion >> fetchRequiredFromArray: @18 line 7 [GsNMethod 199142145]
75 [] in ExecBlock0 (MetacelloMCVersion) >> doLoadRequiredFromArray: @4 line 10 [GsNMethod 219615233]
76 ExecBlock0 (ExecBlock) >> ensure: @2 line 12 [GsNMethod 22673153]
77 MetacelloMCVersion >> doLoadRequiredFromArray: @23 line 16 [GsNMethod 199142401]
78 MetacelloMCVersion >> load @4 line 3 [GsNMethod 199160577]
79 [] in ExecBlock0 (GsUpgrader) >> upgradeGLASS:from: @42 line 62 [GsNMethod 533116929]
80 [] in ExecBlock0 (GsDeployer) >> deploy: @9 line 8 [GsNMethod 230917377]
81 ExecBlock0 (ExecBlock) >> on:do: @3 line 44 [GsNMethod 22551809]
82 [] in ExecBlock0 (GsDeployer) >> deploy: @3 line 9 [GsNMethod 217580289]
83 [] in ExecBlock0 (MCPlatformSupport class) >> commitOnAlmostOutOfMemoryDuring: @4 line 7 [GsNMethod 218043649]
84 ExecBlock0 (ExecBlock) >> ensure: @2 line 12 [GsNMethod 22673153]
85 MCPlatformSupport class >> commitOnAlmostOutOfMemoryDuring: @7 line 8 [GsNMethod 198234625]
86 [] in ExecBlock0 (GsDeployer) >> mcPlatformSupportDo: @3 line 10 [GsNMethod 217579009]
87 ExecBlock0 (ExecBlock) >> ensure: @2 line 12 [GsNMethod 22673153]
88 GsDeployer >> mcPlatformSupportDo: @11 line 10 [GsNMethod 197276417]
89 GsDeployer >> deploy: @3 line 3 [GsNMethod 197277441]
90 GsDeployer class >> autoMigrate: @3 line 12 [GsNMethod 197281025]
91 GsDeployer class >> deploy: @2 line 12 [GsNMethod 197281281]
92 GsUpgrader >> deploy: @12 line 13 [GsNMethod 527176705]
93 GsUpgrader >> upgradeGLASS:from: @4 line 6 [GsNMethod 527154689]
94 GsUpgrader >> upgradeGLASS: @22 line 19 [GsNMethod 527154945]
95 GsUpgrader >> upgradeGLASS @2 line 2 [GsNMethod 527160065]
96 GsUpgrader class >> upgradeGLASS @3 line 4 [GsNMethod 527085569]
97 [] in Executed Code @28 line 31 [GsNMethod 549839361]
98 ExecBlock0 (ExecBlock) >> on:do: @3 line 44 [GsNMethod 22551809]
99 Executed Code @5 line 32 [GsNMethod 549839873]
100 <Reenter marker>
I have seen cases where the Pharo download of a vm, fails in mid script without setting a nonzero exit code leaving a partial structure behind that causes additional failures downstream .... may have to resort to a sanity check post download to flag these errors
If you want to manually run a $GEMSTONE/bin
command directly, you need $GEMSTONE, etc. set. Here's how:
pushd $GS_HOME/server/stones/<stone-name>
source defStone.env
popd
Running the stones
command doesn't filter out the NetLdi and cache stones.
emaringolo@ubuntu:~/GsDevKit_home$ stones
Installed Stones:
3.2.9 testStone1
Running Stones:
Status Version Owner Pid Port Started Type Name
------- --------- --------- ----- ----- ------------ ------ ----
exists 3.2.9 emaringolo 7951 42617 Nov 12 18:12 Netldi testStone1_ldi
exists 3.2.9 emaringolo 7885 39016 Nov 12 18:12 Stone testStone1
exists 3.2.9 emaringolo 7887 48971 Nov 12 18:12 cache testStone1~3121415339bb1ba4
Running Netldis:
Status Version Owner Pid Port Started Type Name
------- --------- --------- ----- ----- ------------ ------ ----
exists 3.2.9 emaringolo 7951 42617 Nov 12 18:12 Netldi testStone1_ld```
as pointed out by @fniephaus, getting a waring when setting system params on travis:
Mon Jan 4 17:25:00 UTC 2016
[Info] Setting up shared memory
Total memory available is 4096 MB
Max shared memory segment size is 4 MB
Max shared memory allowed is 4 MB
[Info] Increasing max shared memory segment size to 2048 MB
kern.sysv.shmmax: 4194304 -> 2147483648
[Info] Increasing max shared memory allowed to 2048 MB
kern.sysv.shmall: 1024 -> 524288
----> name mseg in kern.sysv.mseg is unknown
[Info] Adding the following section to /etc/sysctl.conf
# kern.sysv.shm* settings added by GsDevKit installation
kern.sysv.shmmax=2147483648
kern.sysv.shmall=524288
kern.sysv.shmmin=1
kern.sysv.shmmni=32
Doesn't appear to have affected operation of GemStone on OSX, but need to look into this ..
Because of the mix of stdout and stderr being dumped out, I seem to recall that using tee
was not even possible ... IIRC, you had to use some pretty arcane redirect techniques ....it's probably worth revisiting this as having a log file for installation (and other scripts) would be pretty useful for debugging problems.
add <host-name>
to /etc/hosts
and:
linux:
sudo hostname <host-name>
sudo vi /etc/hostname
and change to
osx: sudo scutil --set <host-name
@DamienCassou is working on building a Nix package for GsDevKit_home as a prerequisite to working on Issue #22.
The model for GsDevKit_home that @DamienCassou is using is based on having the static structure (primarily scripts) installed in a readonly component while the modifiable data (stones, pharo images, git repos, etc.) would be installed in a user's directory structure ...
I agree that this is a good structure to use.
The plan is to create a sysAdmin branch with the static structure and a user branch with the modifiable data .... over time, the _home project will migrate toward using this model by default ...
A verifier script that scans structure and reports back on what's there and not there would be quite useful to help debug broken structure ...
Install tODE on stone: travis
[Info]: libssl-3.2.12-32.so: loaded
Error: Unable to create a GemStone session, check netldi log file.
NetLDI service 'travis_ldi' not found on node 'testing-gce-6acf178c-94ea-4737-8814-51ccbb221818.c.eco-emissary-' port 54018 :
getaddrinfo failed, EAI error -2, Name or service not known, For further information about login failures, check the gem log file
TDTopezGemStoneClient>>loginUsing:
I suspect that there is an issue with determining the host name ... yikes:(
When an install*
is done the user doesn't necessarily know that they are creating a stone when they first get started so the end up with a useless stone created ... also if you do know what you are doing, but just want to install a system (without creating stones or clients) you can't without creating your own script.
It seems that it would be better to pull out the createSTone
and createClient
as separate documented steps (instroducing deleteStone
and deleteClient
along the way...
(1) syntax |& is not accepted by git bash shell. It does accept 2>&1 | .
(2) During createClient, after displaying a couple of lines status on "Installing Pharo", it puts up a dialog and the bash shell looks like it hung. The dialog is titled "Pharo!" with Pharo usage as contents - looks like an error. But if you figure out there is a dialog, and click OK the install appears to succeed.
...also, now that I look, there are no such files as /proc/sys/kernelmmax or /proc/sys/kernelmall, so I don't think these entries in sysctl.conf are doing anything at all.
What are they supposed to do?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.