[Glass] Throw away all 32bit code from the installation code ...

[Dale Henrichs via Glass]

On 09/08/2015 02:02 PM, itlists at schrievkrom.de wrote:
> Dale,
>
> I would like to see a clear 64 bit only (headless) installation for the
> core system - like installGemStone.sh offers.
That makes sense ...
>
> And no: I like to read the installation documentation but I would never
> really like to execute it to make a manual installation of Gemstone but
> its important to have this information somewhere to known what is needed
> to install a running Gemstone.
I think this is being provided by the osPrereqs scripts on the dev 
branch. The README[1] is being rewritten with an eye towards improving 
the information content. If you could read through it and give me (us) 
specific examples of where we are missing information that would help to 
improve the documentation for everyone.

I'm not exactly sure what point you are making here, but now is a very 
good time to give us feedback...

I will mention that I will be making a fairly significant structural 
change to the gsDevKitHome project structure ... I have decided split 
out the todeClient structure/scripts into a separate project/download .. 
The main motivation is to solve some of the problems posed by 
installing/using a todeClient on Windows. By splitting out the 
todeClient, I will be able to write windows-specific "shell" scripts 
that have a chance of actually working:) In addition there were a few 
other things that were confusing because the client and server directory 
structure was shared and those should be cleaned up as well....


[1] 
https://github.com/GsDevKit/gsDevKitHome/tree/dev#open-source-development-kit-for-gemstones-64-bit-
>
> The basic maintenance scripts (however this set is defined) should be
> also runnable out of the box.
All of the scripts are runnable out of the box, modulo the os -specific 
prerequisites...

>
> Then on top of all that the tODE infrastructure (or gsDevKitHome)
> installation can be used - what ever someone likes to implement. The
> customer can then decide if he prefers the additional tools or if he
> prefers a more simple installation.
There are indeed multiple levels in the current gsDevKitHome 
architecture and tODE is not required for all of the scripts ...  my 
take away from this is that I should consider perhaps one more 
segmentation of the scripts/functionality that makes it the distinction 
between scripts that are based on tODE and those that are not ...
>
> Another thing I have to solve is the Proxy problem. If the server has
> only http traffic behind a proxy server the whole infrastructure of the
> Gemstone world seems to break down.
This is a very good point and I am very interested in addressing this 
problem.
> I'm not sure how to solve this  and the solution posted here in the news tody: I simply do not understand
> that.
Okay ...  I don't quite understand what you don't understand:)

When we worked at VMWare I was able to get both Pharo and GemStone to 
function behind a proxy, so I know that it is possible ... Could you 
share with me the information that you have about the proxy and I will 
tell you the Smalltalk expressions that you should execute to get 
GemStone and Pharo working from behind the proxy ...

With that said, I am interested in supporting proxied environments in  
gsDevKitHome at the infrastructure level, so that each stone (and pharo 
vm)  is prepared to work behind the proxy at stone (pharo image) 
creation time ...

For example I seem to recall[2] that the environment variables 
http_proxy and https_proxy are used by programs like wget to correctly 
connect to the http proxy instead of connecting to the host/port named 
in the url ...I think it is reasonable to use those same env variables 
to store the proxy info in the pharo image and GemStone repository so 
that going forward both Pharo and GemStone will honor the proxy 
information ...

Of course there should be additional discussion on these details (I'm 
vary open to alternate solutions), so I've opened a bug on github[3] to 
cover any ongoing discussion/decisions for this problem.

[2] http://stackoverflow.com/questions/11211705/setting-proxy-in-wget
[3] https://github.com/GsDevKit/gsDevKitHome/issues/85

> Perhaps I consider to change Gofer to use native external commands
> like "wget" to use the build-in proxy support ....
if you volunteer to replace Gofer with wget and provide a Smalltalk 
library that runs in Pharo and GemStone then I will gladly welcome your 
contributions ... but I don't think that it's necessary to go that far 
... we can talk in more detail in the issue

I would ask that anyone else who has experience or opions about working 
with proxies and Smalltalk join us in the discussion on github.

Dale