[Glass] Problem with UTF8 encoding and Monticello after GLASS update

[Dale Henrichs]

Mariano,




On Tue, Aug 26, 2014 at 12:03 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
>>
>>>> For my stones, I don't want to rely on that. I want to load an explicit
>>>> version of glass so that I know and control what do I load.
>>>> So..for the moment, it's fine, the above script is OK.
>>>>
>>>
>>> If you are building a new stone from scratch, you should upgrade to
>>> GLASS1.0-beta.9.3 before loading anything else ... that way you have the
>>> proper GLASS/Metacello foundation for loading any other packages.
>>>
>>
>> I will open another thread for this.
>>
>>
>
> OK. Say I have a fresh extent (not the seaside one) that I grab
> from /opt/gemstone/product/bin/extent0.dbf  in GemStone 3.1.0.5.  Until
> now, I was installing GLASS1.0-beta.... with this script that you share
> with me:
>
>
> su -m $GEMSTONE_USER -c "$GEMSTONE/bin/topaz -l -T200000 <<EOF
>
> set user SystemUser pass $2
> login
> run
> Stream installLegacyStreamImplementation.
> (Globals at: #'PositionableStream_position') == #'ANSI'
>    ifTrue: [
>      Globals at: #'PositionableStream_position' put: #'Legacy'.
>      PositionableStream compilePositionMethods ].
> true
> %
> commit
> logout
>
> EOF
> "
>
> su -m $GEMSTONE_USER -c "$GEMSTONE/bin/topaz -l -T200000 <<EOF
>
> login
> run
> System myUserProfile _createDictionary: #GLASS at: 1.
> UserGlobals at: #BootstrapSymbolDictionaryName put: #GLASS.
> true
> %
> commit
> errorCount
>
> input $GEMSTONE/upgrade/installMaster30.topaz
>
> commit
> errorCount
> logout
>
> EOF
>
> "
>
>
>
> As you can see...this actually executes
>  $GEMSTONE/upgrade/installMaster30.topaz  (which has a hardcoded
> configurationVersionString: '1.0-beta.9'; in my case)  and that calls
> another script and another..etc
>
> So... I wonder, is this still the correct way to install GLASS in a FRESH
> extent?
>

The above script is indeed the correct way to _bootstrap_ GLASS into a
fresh extent0.dbf. When the script if finished you should have the same
code that is already in extent0.seaside.dbf with the exception that the
GLASS classes are installed in a SymbolDictionary called #GLASS instead of
#UserGlobals.

Besides being able to control which SymbolDictionary is used, you can use
the global BootstrapConfigurationLoads to customize what groups and
projects get  loaded in the extent. For example you can choose to exclude
OmniBrowser (in which case neither GemTools nor tODE would function
correctly) ...

If you go this route (using something other than the default install)  then
you will be very interested in managing how GLASS1 is installed as well,
since you don't want to undo any customization you may have desired.


> Or something like an updated https://github.com/glassdb/glass#installation
> should be enough?
>

The  https://github.com/glassdb/glass#installation script is intended to be
used after GLASS has been bootstrapped either with a custom bootstrap
script or extent0.seaside.dbf.

Typically each version of GemStone ships with a different version of GLASS
bootstrapped which contains any bugfixes that have occurred along the way
and patches to GLASS so that code will continue to run correctly in the new
version of GemStone.


Or the idea is that I first do the above to get the "supposed" GLASS
> version for my gemstone version and then after perform an upgrade to get
> latest GLASS?
>

At the end of the day, this is probably the most straight forward approach.

The https://github.com/glassdb/glass#installation script is designed to be
run against the extent that comes with any version of GemStone and brings
the code up to a point that is common across all GemStone versions ... then
you have a solid foundation upon which to build your application ... It
should be possible to move your application code from GemStone2.4.x to
GemStone 3.2.2 without any changes at all ... of course if you are using
some GemStone-specific functionality in your application then the api may
change from release to release ... With GLASS I try to give you a stable
API that does not change from GemStone release to GemStone release.

The GLASS API often changes in response to new requirements from Seaside,
Zinc, Pier, Magritte, etc. as those projects change their API in response
to changes to Pharo and/or Squeak ... so the GLASS API has to change as
well ...

Historically it was not practical to have projects directly dependent upon
the GLASS project, because Metacello was in a state of pretty constant
development and there were often issues in getting a new version of
Metacello to load correctly (as you saw earlier today when you did not load
GLASS1.0-beta9.3 first) ...

GLASS 1.0-beta.9.3 was designed to provide a solid platform where projects
like Zinc and Seaside31 can include a dependency on the GLASS 1 project and
thus make it unnecessary for developers to worry about loading the proper
version of GLASS1 as the projects themselves will ensure that the proper
version of GLASS1 is loaded ...

As I make my way to the various projects like Pier and Magritte I will
change the configurations to depend upon GLASS1 directly as has been done
with Zinc and Seaside ... if things work out well, it will only be
necessary to decide which version of these projects you want to load and
the configuration will take care of the rest ...

In parallel with this I will be expanding the travis-ci test suite for
GLASS1 (soon to be GsDevKit) so that a selection of dependent project
builds will be fired off against GLASS1 to ensure that the GLASS1 changes
don't negatively impact the dependent projects ...

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140826/4f899c37/attachment.html>