Page 1 of 1

ST/X 5.4.6 packagePath

PostPosted: 24. Nov 2009, 19:11
by csrabak
I've just installed ST/X 5.4.6 (the last version I'd was 5.4.2) in Windows XP SP3 Home Edition. Following recommendation the directory structure is:


With all files from directory structure preserved in stx.

In this new version, when I click in a method of a class in the SystemBrowser (Tools::NewSystemBrowser rev. 1.1426) it shows in the code pane:

Sorry, but the methods sourceCode is not available or corrupted.

Please check the setting of your packagePath, which contains a collection of pathNames.
The system searches those directories for a package-subdirectories,
which should either contain the classes source file.
Also, check if that directory and/or sourceFile grants read access.
The packagePath can be accessed via
Smalltalk packagePath

To fix this (in the running system), evaluate:
Smalltalk packagePath addFirst:'<<pathOfDirContainingPackageDir>>.'
Smalltalk flushPathCaches.

You may also want to add those statements to the end of your 'private.rc'
file - so you will not get this error again and again.

Also, check if you have the sourceCodeManagement (CVS) enabled,
and (if so) configured correctly.

If all of the above fail, and you know the path of the source file,
you can workaround the problem, by adding a symbolic link to that sourcefile
in the 'source' directory.

In the older (5.4.2) ST/X installation a call to:
Code: Select all
Smalltalk packagePath.

returns: OrderedCollection('D:\stx-5.4.2'), so I figured out that the directions were heading to:

Code: Select all
Smalltalk packagePath addFirst:'D:\stx546'.
Smalltalk flushPathCaches.

That didn't work 'dynamically' so I saved the image and restarted ST/X, but problem persists. . .

What should I do to have the source visible in the SystemBrowser?

Re: ST/X 5.4.6 packagePath

PostPosted: 30. Nov 2009, 16:10
by cgittinger
mhmh that all sounds strange, as from whyt you write, it should have worked...
The source fetching scheme is somewhat wierd, as it went through various rewrites and we had to be backward compatible for some customer's setup (maybe it is time to got to vsn 6 and get rid of some of this...)
Anyway: first, when trying to get the source for class C in package P, it looks for a file named P'/C (where P' is P with all colons replaced by /'s) under:
- the current directory
- the stx-executable's directory
- $(STX_TOPDIR) from the shell-environment
- $(STX_PACKAGEPATH) from the shell-environment
- a number of fallback default names, such as "\programs\smalltalk".

if $(STX_TOPDIR) was not set (but only then), the executable's ../.. is also added.
Tha last one is the case, when you execute stx from the development environment; all other cases, when a standAlone stx-application is running.
Thus, I guess that you still have STX_TOPDIR somewhere in your shell-environment (try env in a window).

Get rid of it - it should actually work without any setting (i.e. do not set it to stx546, but instead unset it completely).

Hope this helps; if not, let us(me) know here.

if all fails, enable CVS access in the launcher's settings dialog, setup for access to exept's cvs server, and access the sources from there (takes a bit longer initially, until sources are cached on your local machine; after that, you won't see speed penalty to local source access). Navigate the browser to some class in the stx:libbasic package (Array, for example).

Then, (in the browser) put a breakpoint on
Class >> localSourceStreamFor:
and evaluate (in a workspace):
Array localSourceStreamFor:''

then single step, and try to see what is wrong.
localSourceStreamFor: is supposed to return something like a FileStream(for: C:\Users\cg\work\stx\libbasic\ on my system).

When you found the bug, either disable CVS access, or set the "local source first" flag in the settings dialog.