Gofer project load: 'Seaside30' gives an error

Giving a try to Seaside30, I just executed "Gofer project load:
'Seaside30' "  in a fresh extent.

But an error encountered:
MetacelloFetchingMCSSpecsLoader retryingResolvePackageSpecReferences:gofer:

It is trying to generate an error:   'Could not resolve: ', packageSpec name

The packageSpec name is
spec
   name: 'ConfigurationOfGrease';
   file: 'ConfigurationOfGrease';
   repository: 'http://www.squeaksour.com/MetacelloRepository'.

The repositoryError variable is nil.


Also when I tried to 'copy stack', I get another error (No method was
found for the selector #'do:' when sent to nil...).

Thanks,
Thierry

I made a typo in my error report.  The url is
http://www.squeaksource.com/MetacelloRepository

Anyway, the server seems to be down. Maybe the loading code should be
more explicit about this situation?


Thierry

Ok, squeaksource is back.

Now I am getting a 'VM temporary object memory is full' error during
the Seaside3.0 load.


Thierry

On 10/20/2010 08:00 PM, Thierry Thelliez wrote:
> I made a typo in my error report.  The url is
> http://www.squeaksource.com/MetacelloRepository
>
> Anyway, the server seems to be down. Maybe the loading code should be
> more explicit about this situation?
>
>
> Thierry

When the server that is serving configurations is down, it's hard to get
things going ... without stacks I can't comment on the error message.

I _have_ added a number of features of Metacello on the other hand that
is aimed at surviving in a world where SqueakSource is down once a day:)

The main trick is to store all of the configurations and mcz files that
you use for production in a local disk-based repository (or an HTTP
server that you have control over).

You create (and keep up to date) the "cache repository" adapting the
following script:

         | cacheRepository version map |
         cacheRepository := MCHttpRepository
              location: '<repository URL>'
              user: ''
              password: ''.
         "need to pick up existing repository with user and password set
           supply user/password args"
         cacheRepository := MCRepositoryGroup default repositories
                 detect: [ :each | each = cacheRepository ]
                 ifNone: [ cacheRepository ].

         ConfigurationOfSeaside30 project updateProject.
         version := ConfigurationOfXXX project
              version: '1.0'.

         "update configs that are already loaded ...
           might be able to skip this"
         map := Dictionary new.
         (version record: 'ALL') loadDirective
                 versionDirectivesDo: [ :versionDirective |
                         versionDirective spec ~~ nil
                                 ifTrue: [ | p|
                                   p:= versionDirective spec project.
                                   map at: p configuration put: p ] ].
         map values do: [:p | p updateProject  ].

         "point to target cacheRepository, ignoreImage so all packages
           are fetched and fetch away"
         version cacheRepository: cacheRepository.
         version ignoreImage: true.
         version fetch: 'ALL'

(from
http://code.google.com/p/metacello/wiki/MaintainingSecondaryRepository)
Then you can load from the repository using the following:

   | version repo |
   repo := MCDirectoryRepository new.
   repo directory: FileDirectory on: '<path to directory>'.
   version := ConfigurationOfXXX project version: '1.0'.
   version repositoryOverrides: (OrderedCollection with: repo).
   version load.

(from
http://code.google.com/p/metacello/wiki/FAQ#How_do_I_override_the_repository_for_a_config?)

Using this technique you can include something like
ConfigurationOfSeaside30 in your production configuration so that during
development it is easy to update to newer versions, but by maintaining
your cache repository and using the overrided for loads, you production
build scripts can be isolated from the instability of SqueakSource...

Dale

On 10/21/2010 09:18 AM, Thierry Thelliez wrote:
> Ok, squeaksource is back.
>
> Now I am getting a 'VM temporary object memory is full' error during
> the Seaside3.0 load.
>
>
> Thierry
Thierry,

When doing a large bulk load like that use MCPlatforSupport
class>>commitOnAlmostOutOfMemoryDuring: like the following:

| autoCommit|
autoCommit := MCPlatformSupport autoCommit.
MCPlatformSupport autoCommit: true. "needed if loading from Topaz"
MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [[
                  Gofer project load: 'Seaside30'group: #( 'ALL').
                  Gofer project load: 'Pier2' group: 'ALL'.
                  Gofer project load: 'PierAddOns2' group: 'ALL'.
          ]
                  on: Warning
                  do: [:ex |
                          Transcript cr; show: ex description.
                          ex resume ]].
MCPlatformSupport autoCommit: autoCommit.

(from http://code.google.com/p/glassdb/wiki/Seaside30Configuration).

Dale

Ok, I ended up loading Seaside30 with your code called from a topaz
script, increasing GEM_TEMPOBJ_CACHE_SIZE to 100000;  It took a while
but it loaded.

A note on http://code.google.com/p/glassdb/wiki/Seaside30Configuration
 could be useful if this is the way to go.



Thierry