Hi guys.
I have a strange situation. I have 2 stones. Both using 3.1.0.5. One stone (let's call it the OLD), was created several months ago. The other site, let's call it the NEW, was built a week ago.
I have just updated GLASS in both of them, using this expression: Metacello new baseline: 'GLASS1'; repository: 'github://glassdb/glass:master/repository';
onConflict: [ :ex | ex allow ]; onWarning: [ :ex | Transcript cr; show: ex description. ex resume ]; load: 'default'.
After that... the NEW works ok. But the LAST, I cannot read any more packages from Monticello, since I am getting a UTF error. I debug it and I arrive to this difference: In NEW stone (the one that works), this works:
(UTF8Encoding newEncoder encode: 'ConfigurationOfIAM-MarianoMartinezPeck.68.mcz') asString In OLD stone, it yields a: "a ArgumentTypeError occurred (error 2719), for aCollection expected a anArray( String, ByteArray), arg is a Utf8" when it tries to do the #asString.
The difference is that NEW #encode: answers a string. While the OLD answers a Utf8 instance. So....any workaround? Thanks, Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Mon, Aug 25, 2014 at 6:40 PM, Dale Henrichs <[hidden email]> wrote:
No, the error is not there. The error is because in the OLD (broken) (UTF8Encoding newEncoder encode: 'ConfigurationOfIAM-MarianoMartinezPeck.68.mcz') answers a Utf8 instance rather than a string (which is what happens in the new). Then,..the type error is in the #asString. (UTF8Encoding newEncoder encode: 'ConfigurationOfIAM-MarianoMartinezPeck.68.mcz') asString
Btw,...when loading from MC, the error is from #encodeForHTTPWithTextEncoding: encodingName conditionBlock: conditionBlock where it does: ((GRCodec forEncoding: encodingName) encode: self) asString
How can I get a string full stack from GemTools? Thanks
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Uffff...then I ignore for a minute the utf8 stuff (I let it without encoding) and yet another problem...
MCMczReader >> zip zip ifNil:
[zip _ ZipArchive new. zip readFrom: stream]. ^ zip
Fails because ZipArchive doesn't exist. WTF?? Now I am comparing Core-Squeak and in the OLD stone I have lots of classes and in new stone only a few... In fact...it looks like I miss all Zip classes in the new stone. Maybe they were moved to a separate package yet that package is not included in the conf?
On Mon, Aug 25, 2014 at 7:19 PM, Mariano Martinez Peck <[hidden email]> wrote:
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Second... in Core.v3-dkh.85 I read "put the compression support classes into a separate package that is common for GemStone2.4 and GemStone3.x
- this commit is from a 3.1 stone (which is compatible with 3.2) ... need to finish up with updates to 2.4 and 3.0.1 " I doubt this external package is being loaded....Do you know if configurationOf was updated?
Finally...how can I load an older version of github from gemtools? I can browse with "History", but I cannot find a way to load them :(
Of course...in the OLD stone where it was working, I am using Core.v3-dkh.77. On Mon, Aug 25, 2014 at 10:25 PM, Mariano Martinez Peck <[hidden email]> wrote:
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Mariano Martinez Peck
On Mon, Aug 25, 2014 at 10:50 PM, Dale Henrichs <[hidden email]> wrote:
Hi Dale, Thanks for your answer. Core31x package is loaded in NEW stone, but not in the OLD (failing). Do you know if it should be loaded automatically?
I guess yes...but then I am not sure what it hasn't been loaded. BTW...we agree we are talking about gemstone 3.1 right? and not seaside 3.1? because I am still using seaside 3.0.9. Thanks
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Mon, Aug 25, 2014 at 10:55 PM, Mariano Martinez Peck <[hidden email]> wrote:
as I said in my first email, this was the script I used to update GLAS: Metacello new baseline: 'GLASS1'; repository: 'github://glassdb/glass:master/repository';
onConflict: [ :ex | ex allow ]; onWarning: [ :ex |
Transcript cr; show: ex description.
ex resume ]; load: 'default'.
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Ufff...of course...I should have get the baseline first: Metacello new baseline: 'GLASS1'; repository: 'github://glassdb/glass:master/repository';
get. Metacello new baseline: 'GLASS1'; repository: 'github://glassdb/glass:master/repository'; onConflict: [ :ex | ex allow ];
onWarning: [ :ex | Transcript cr; show: ex description. ex resume ]; load: 'default'. But now I get this error: ...RETRY->BaselineOfGLASS1 ...RETRY->BaselineOfGLASS1 gofer repository error: 'a GoferRepositoryError occurred (error 2710)'...ignoring
...FAILED->BaselineOfGLASS1 The repository is aMCGitHubRepository(github://glassdb/glass:master/repository) .... And a curl-tmpgithubglassdbglassmasterzip.err is writte in /tmp
any idea? On Mon, Aug 25, 2014 at 10:56 PM, Mariano Martinez Peck <[hidden email]> wrote:
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Mariano Martinez Peck
On Mon, Aug 25, 2014 at 6:55 PM, Mariano Martinez Peck <[hidden email]> wrote:
I believe that you have run into a Metacello bug in the OLD stone... If you didn't update to GLASS 1.0-beta9.3 before loading GLASS1 (probably loaded by the new version of ZINC) then it is possible that you have hit a bug ...
I would like to understand the current state of your OLD (broken) stone ... could you send me a copy of your 'Version Report' and a screen shot of the package versions loaded from your Monticello Browser ... with that information I can recommend a course of action for getting things repaired ...
Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Mariano Martinez Peck
what is in the curl-tmpgithubglassdbglassmasterzip.err file?
On Mon, Aug 25, 2014 at 7:11 PM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Are the new and old stones running on the same hardware? On Mon, Aug 25, 2014 at 7:12 PM, Dale Henrichs <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Dale Henrichs-3
On Mon, Aug 25, 2014 at 11:12 PM, Dale Henrichs <[hidden email]> wrote:
xxx@yyy tmp]$ cat curl-tmpgithubglassdbglassmasterzip.err % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed 100 11.3M 100 11.3M 0 0 1662k 0 0:00:06 0:00:06 --:--:-- 1913k
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Dale Henrichs-3
Btw, once you've loaded GLASS1 you do not want to try to load GLASS 1.0-beta.9.3 ... On Mon, Aug 25, 2014 at 7:12 PM, Dale Henrichs <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Mon, Aug 25, 2014 at 11:14 PM, Dale Henrichs <[hidden email]> wrote:
What do you mean exactly? I thought the following will grab the latest GLASS: Metacello new baseline: 'GLASS1'; repository: 'github://glassdb/glass:master/repository'; get. Metacello new baseline: 'GLASS1'; repository: 'github://glassdb/glass:master/repository'; onConflict: [ :ex | ex allow ]; onWarning: [ :ex |
Transcript cr; show: ex description. ex resume ]; load: 'default'. isn't it the case?
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In the process of getting Seaside3.2 and Zinc working, I discovered some issues in how Metacello and GLASS1 were being loaded and after working through the issues I determined that for best results GLASS1.0-beta.9.3 needed to be loaded before attempting to load GLASS1 ... So your load expression could result in some issues ... I am very foggy right now and don't recall all of the details, because of my jet lag ... If I can look at your list of packages and projects loaded into the OLD image, I should be able to recommend a course of action .... tomorrow ...
Dale On Mon, Aug 25, 2014 at 7:16 PM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Mariano, After a couple of hours of sleep, I have realized a couple of things that I should have mentioned earlier: - GLASS 1.0-beta.9.3 is a prerequisite to loading GLASS1.
- 1.0-beta.9.3 loads the MetacelloPreview "in a single step" and replaces the explicit (and ugly) multi-step MetacelloPreview load sequence - once the #stable version of MetacelloPreview is loaded projects may directly depend upon GLASS1
and it should become unnecessary to explicitly load GLASS1 as a prerequisite for loading another project The READMEs for both the Metacello[1] and GLASS1[2] projects are currently out-of-date and need to be updated.
The following script should be equivalent to upgrading to GLASS1.0-beta9.3: "Load the Preview version of Metacello from GitHub" | previewLoaded |
previewLoaded := false. Smalltalk at: #'BaselineOfMetacello' ifPresent: [ :ignored | Smalltalk at: #'MetacelloProjectRegistration'
ifPresent: [ :cls | (cls registrationForClassNamed: 'BaselineOfMetacello' ifAbsent: [ ]) ifNotNil: [ :registration | previewLoaded := registration loadedInImage ] ] ].
previewLoaded ifTrue: [ (Smalltalk at: #'Metacello') new configuration: 'MetacelloPreview'; version: #'stable'; repository: 'github://dalehenrich/metacello-work:configuration';
get ] ifFalse: [ "Bootstrap Metacello Preview, using mcz files (#'previewBootstrap' symbolic version" Gofer new gemsource: 'metacello';
package: 'ConfigurationOfMetacello'; load. GsDeployer deploy: [ ((Smalltalk at: #'ConfigurationOfMetacello') project
version: #'previewBootstrap') load ] ]. GsDeployer deploy: [ "load the Metacello Preview" (Smalltalk at: #'Metacello') new
configuration: 'MetacelloPreview'; version: #'stable'; repository: 'github://dalehenrich/metacello-work:configuration'; load ]
I've tested this script on a virgin 3.1.0.5 extent and it loads cleanly ... then a GLASS1 load using the following script: GsDeployer deploy: [Metacello new
baseline: 'GLASS1'; repository: 'github://glassdb/glass:master/repository'; onConflict: [ :ex | ex allow ]; onWarning: [ :ex | Transcript
cr; show: ex description. ex resume ]; load: 'default'.] also loads cleanly so with luck we should be out of the woods.
I'm still not quite sure what state your image is in,so if you still have trouble loading GLASS1 then I'll probably need to need the detailed package info to try to reproduce the problems myself ...
I'm sorry that I was so dense earlier ... I really shouldn't have tried to answer any emails given how jet-lagged I was .... Dale On Mon, Aug 25, 2014 at 7:25 PM, Dale Henrichs <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Tue, Aug 26, 2014 at 7:06 AM, Dale Henrichs <[hidden email]> wrote:
OK, thanks Dale for taking care. I answer below.
OK, executing that I do get things updated and I can load my code. So it seems this fixes my problem. Now...from what I understand above, I am loading GLASS 1.0-beta.9.3 as a side effect of loading latest Metacello.
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.
But then, what I would appreciate the most, is an updated https://github.com/glassdb/glass#installation
From what I understood from your words, using the script from that page but simply changing to GLASS 1.0-beta.9.3 would not have the same case as the lines provided above. In fact, maybe tomorrow I re-run the lines provided above, and I may get GLASS 1.0-beta.9.4. And I don't want that. I want a script to load GLASS 1.0-beta.9.XXXX plus + Metacello + GLASS1. :)
Np and thanks for answering. I was also very frustrated because I was not able to update my code and everything I tried ended up in another problem.
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Tue, Aug 26, 2014 at 7:55 AM, Mariano Martinez Peck <[hidden email]> wrote:
This script is only there to repair the missing step when you loaded GLASS1 without loading GLASS 1.0-beta.9.3 first. Once you've loaded GLASS1 (which overlaps GLASS) you do not need nor want to load GLASS.
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.
Yes this is one of my mistakes ... this script needs to be updated.
If you look at what GLASS 1.0-beta.9.3 (which is what I did after a couple or hours of sleep:) you will see that the above script is exactly what is done by the Metacello load script. With that said, the proper way thing to do is to load GLASS 1.0-beta.9.3
Agreed ... keep in mind that I don't intend to create a new version of GLASS unless I find that there is bug fix needed all new bugfixes are being put into the GLASS1 project.
As a technicality, my _plan_ is that you should only have to load GLASS 1.0-beta.9.3 and thenGLASS1 as I think that GLASS1 should have a dependency on Metacello. As a technicality for the previous technicality GLASS1 will be renamed GsDevKit "real soon now".
As a final technicality. I expect that for production applications like yours you should have a local clone of each github repository so that you can control exactly what gets loaded into your system you may use the public configurations to load projects and by using the `lock` command you will guarantee that the local clones will always be used ...
You will update your application to use later versions of the cloned repositories by merging updates in a separate sandboxed systems (with their own clones) so that you can independently validate any and all changes that are integrated into your system.
I completely understand.
I'm slowly returning back to normal and now that ESUG is behind me I plan on making passes through the eco systems fixing things up as I go. It will definitely help if you (and others) let me know where the most pain is being felt.
I have a rich target environment of things to address, but I would prefer to address immediate pain as a top priority. Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
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? Or something like an updated https://github.com/glassdb/glass#installation should be enough?
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? Thanks in advance,
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Mariano,
On Tue, Aug 26, 2014 at 12:03 PM, Mariano Martinez Peck <[hidden email]> wrote:
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.
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.
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 _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Mariano Martinez Peck
On Tue, Aug 26, 2014 at 7:55 AM, Mariano Martinez Peck <[hidden email]> wrote:
I've updated the glass install script and it has been tested against 2.4.5.2, 3.0.1, 3.1.0.6 and 3.2.2 [2], the tests not only test the load, but the test suite in GLASS1 is run as well...
Let me know how this works in your load scripts... Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |