aFilePackage cannot perform the selector '#preamble' with the arguments in anArray( aChangeRecord)

Hi -

I'm trying to import a package I've written that runs in Pharo 1.1 into
Gemstone 2.4.4.1.  I think I have cleared up all of the syntax errors
and now have the error in the subject line of this email.  I don't know
how to approach fixing it.

Any suggestions? The stack trace is below.

Thanks

Paul


[1] System class | signal:args:signalDictionary:
        anInteger: 2013
        anArray: anArray( aFilePackage, #'preamble:', anArray( aChangeRecord))
        anErrorDict: aSymbolDictionary( #'English'->anArray( nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, ...))
        ex: nil
        _topOfStack: System
        receiver: System
[2] FilePackage (Object) | _error:args:
        errorSymbol: #'rtErrCantPerform'
        argList: anArray( #'preamble:', anArray( aChangeRecord))
        newArgList: anArray( aFilePackage, #'preamble:', anArray( aChangeRecord))
        errorNumber: 2013
        receiver: aFilePackage
[3] FilePackage (Object) | cantPerform:withArguments:
        aSelectorSymbol: #'preamble:'
        anArray: anArray( aChangeRecord)
        receiver: aFilePackage
[4] FilePackage (Object) | _perform:withArguments:
        aSelectorSymbol: #'preamble:'
        anArray: anArray( aChangeRecord)
        receiver: aFilePackage
[5] FilePackage (Object) | perform:with:
        aSelectorSymbol: #'preamble:'
        anObject: aChangeRecord
        receiver: aFilePackage
[6] FilePackage | fileInFrom:
        aStream: anAnsiReadStream
        chgRec: aChangeRecord
        changes: anOrderedCollection( aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, aChangeRecord, ...)
        i: 311
        _temp1: 1
        _temp2: 976
        _temp3: 311
        receiver: aFilePackage
[7] MCStReader | loadDefinitions
        filePackage: nil
        _temp1: 21197544880766981
        receiver: aMCStReader
[8] [] in MCSnapshotReader | definitions
        receiver: aComplexBlock
[9] UndefinedObject | ifNil:
        aBlock: aComplexBlock
        receiver: nil
[10] MCStReader (MCSnapshotReader) | definitions
        _temp1: 21197542733283333
        receiver: aMCStReader
[11] [] in MCMczReader | extractDefinitionsFrom:
        rc: MCStReader
        _temp1: anOrderedCollection( )
        member: aZipFileMember
        reader: aMCStReader
        receiver: aComplexBlock
[12] MCStReader class (Object) | ifNotNilDo:
        aBlock: aComplexBlock
        receiver: MCStReader
[13] MCMczReader | extractDefinitionsFrom:
        member: aZipFileMember
        reader: aMCStReader
        _temp1: 21197523405930501
        receiver: aMCMczReader
[14] [] in MCMczReader | loadDefinitions
        m: aZipFileMember
        receiver: aComplexBlock
[15] OrderedCollection (Collection) | do:
        aBlock: aComplexBlock
        i: 1
        _temp1: 1
        _temp2: 1
        _temp3: 1
        receiver: anOrderedCollection( aZipFileMember)
[16] MCMczReader | loadDefinitions
        _temp1: 21197259265441797
        receiver: aMCMczReader
[17] [] in MCVersionReader | definitions
        receiver: aComplexBlock
[18] UndefinedObject | ifNil:
        aBlock: aComplexBlock
        receiver: nil
[19] MCMczReader (MCVersionReader) | definitions
        _temp1: 21197257117958149
        receiver: aMCMczReader
[20] MCMczReader (MCVersionReader) | snapshot
        _temp1: MCSnapshot
        receiver: aMCMczReader
[21] MCMczReader (MCVersionReader) | basicVersion
        _temp1: MCVersion
        _temp2: aMCPackage(Staffer)
        _temp3: aMCVersionInfo(Staffer-PaulDeBruicker.35)
        receiver: aMCMczReader
[22] MCMczReader (MCVersionReader) | version
        receiver: aMCMczReader
[23] [] in MCFileBasedRepository | loadVersionFromFileNamed:
        r: aMCMczReader
        receiver: aSimpleBlock
[24] [] in MCFileBasedRepository | versionReaderForFileNamed:do:
        class: MCMczReader
        s: aRWBinaryOrTextStream
        aString: 'Staffer-PaulDeBruicker.35.mcz'
        aBlock: aSimpleBlock
        receiver: aComplexBlock
[25] MCMczReader class (Object) | ifNotNilDo:
        aBlock: aComplexBlock
        receiver: MCMczReader
[26] [] in MCFileBasedRepository | versionReaderForFileNamed:do:
        s: aRWBinaryOrTextStream
        _temp1: 21194645777842181
        aString: 'Staffer-PaulDeBruicker.35.mcz'
        aBlock: aSimpleBlock
        receiver: aComplexVCBlock
[27] MCPlatformSupport class | readStreamForFileNamed:onClient:do:
        aString: '/home/paul/src/staffer/Staffer-PaulDeBruicker.35.mcz'
        onClient: true
        aBlock: aComplexVCBlock
        file: aGsFile
        stream: aRWBinaryOrTextStream
        receiver: MCPlatformSupport
[28] MCDirectoryRepository | readStreamForFileNamed:do:
        aString: 'Staffer-PaulDeBruicker.35.mcz'
        aBlock: aComplexVCBlock
        receiver: aMCDirectoryRepository(/home/paul/src/staffer)
[29] MCDirectoryRepository (MCFileBasedRepository) | versionReaderForFileNamed:do:
        aString: 'Staffer-PaulDeBruicker.35.mcz'
        aBlock: aSimpleBlock
        _temp1: 21194637187907589
        receiver: aMCDirectoryRepository(/home/paul/src/staffer)
[30] MCDirectoryRepository (MCFileBasedRepository) | loadVersionFromFileNamed:
        aString: 'Staffer-PaulDeBruicker.35.mcz'
        receiver: aMCDirectoryRepository(/home/paul/src/staffer)
[31] [] in MCFileBasedRepository | versionFromFileNamed:
        aString: 'Staffer-PaulDeBruicker.35.mcz'
        v: nil
        receiver: aComplexBlock
[32] Dictionary | at:ifAbsent:
        aKey: 'Staffer-PaulDeBruicker.35.mcz'
        aBlock: aComplexBlock
        anAssoc: nil
        receiver: aDictionary( )
[33] MCDirectoryRepository (MCFileBasedRepository) | versionFromFileNamed:
        aString: 'Staffer-PaulDeBruicker.35.mcz'
        v: nil
        _temp1: 21194632892940293
        receiver: aMCDirectoryRepository(/home/paul/src/staffer)
[34] MCFileBasedVersionNode | version
        receiver: aMCFileBasedVersionNode
[35] MCCmdLoad | execute
        version: nil
        receiver: aMCCmdLoad
[36] [] in OBCommand | clientExecute
        receiver: aComplexBlock
[37] OBUpdateConcentrator | recordUpdatesDuring:
        aBlock: aComplexBlock
        _temp1: 21194630745456645
        receiver: anOBUpdateConcentrator
[38] MCCmdLoad (OBCommand) | clientExecute
        _temp1: 21194628597972997
        receiver: aMCCmdLoad

Paul,

Presumably the Pharo folks have monkeyed with Monticello ... or have you
explicitly added a preamble to your package?

I can add the preamble:: method to FilePackage (it's in the Monticello
package for GemStone), but I'm not sure what else may happen or be
missing ...

I'll have a patch shortly...

Dale

Paul DeBruicker wrote:

Paul,

Try updating to 1.0-beta.8.2
(http://code.google.com/p/glassdb/wiki/GemToolsUpdate#Update_GLASS) you
will have to "Show All Versions" to see 1.0-beta.8.2, because it is
marked as in #development. When we've worked through your issues, I'll
release it.

BTW, I've submitted Issue 145 to track this:

   http://code.google.com/p/glassdb/issues/detail?id=145

Let me know if other problems show up.

Dale

Paul DeBruicker wrote:

Thanks Dale.

I've not added a preamble.  Based on your comment I did copy the
FilePackage>>#preamble: method from Pharo and it seemed to load after
that.  I haven't run any tests yet.

Also, I added the Schedule class from Pharo to the
Squeak-Kernel-Chronolgy package in Gemstone.

and also
Symbol>>value: anObject
     ^anObject perform: self.

Paul







On 07/16/2010 01:51 PM, Paul DeBruicker wrote:

Paul DeBruicker wrote:
Paul,

If you could save your Squeak package to
http://seaside.gemstone.com/ss/monticello as Squeak-pad.226.mcz, I'll
update the 1.0-beta.8.2 to include those changes as well (and I'll do
the merge to the development version) and then release 1.0-beta.8.2.

Thanks,

Dale

Sure.  I added my Squeak package to the repo you specified.  Right now
I'm also having trouble successfully running:

Gofer  project load:  'Seaside30'  group:  'Seaside-Adaptors-Swazoo'.


initially the error was that it couldn't find the
ConfigurationOfSwazoo2.  After I loaded the ConfigurationOfSwazoo2 from
GemSource it complained that:

'Could not resolve: Seaside-Swazoo'

When I try to open the MetacelloRepository on squeaksource, it just
shows up as a blank repository.  When I hit refresh it seems to be
looking for repo information but doesn't display any information.  
Should I be using the Metacello repo on gemsource or squeaksource?


I was able to load Seaside30 Base, JQuery-Core, JQuery-UI,
Javascript-Core, FastCGI, and Development packages just fine.  I just am
having an error now trying to load Swazoo.

Thanks


Paul

Paul,

Thanks for the Squeak additions ... I'll release 1.0-beta.8.2 shortly.

It looks like SqueakSource is down (again) and that is most likely
causing your problems ...

I have arranged for the Metacello code to be dual-homed on SqueakSource
and GemSource and I am very close to dual-homing the Seaside3.0 code
base as well ... SqueakSource has become very unreliable in recent months.

After today's outage, I think that's what I will do ... but I'll have to
wait for SqueakSource to be up again before I can copy all of the mcz
files over:)

Dale

Paul DeBruicker wrote:

Paul DeBruicker wrote: Paul,

I looked in the repository and I didn't see you Squeak package...

Dale

>
> Paul,
>
> I looked in the repository and I didn't see you Squeak package...
>
> Dale
>    


Hi Dale,

I think you later found it as I've updated to 1.0-beta.8.2.

I skipped the Swazoo install and have FastCGI + 3 gems working with
Lighttpd.


My new issue is that when I attempt to load a local package Gemstone
gives me a warning that I need to load a class that's defined in the
package before I can load some definitions in that class.  If I hit
proceed, it loads a subset of the package, and not the class it gives
the warning about.  I get no other warnings or errors while its
loading.  Once its done I have some of the classes and methods in the
Stone but not the class it gave the warning for..  If I reload the same
package it loads a different subset of the package, but not the class it
gave the warning for.  I'm going to wipe the install and reload from
local files and see if something I've done is causing this.  Though I
imagine that its something weird with that class I've written.

So right now the end result of adding this particular local package is
that some of the methods and classes are loaded the first time I try to
load it and a different set are loaded the second time I load it.

I know its the weekend and I'm using the free version so I'll try to
sort it out

Thanks for you help

Paul

>
> Hi Dale,
>
> I think you later found it as I've updated to 1.0-beta.8.2.
>    

I was wrong about this.  I tried to upload it again this AM.  I think
its there now.  I'm still missing some classes and methods when I load
packages with Monticello.

Paul,

The warning message about telling you that you need to load a class is
telling you that you are trying to load a sbuclass of that class or add
extension methods to that class.

This is what load order in Metacello is all about.

You need to figure out which classes are missing and then load that
package and then reload the package from which you get the error...then
things should get straighted out ...

Once you figure out the load order, you should create a Metacello
configuration that records the dependencies so you you "just load the
config" to get you stuff loaded up.

Dale

Paul DeBruicker wrote:

Paul,

If you've got the Squeak package, could you mail it to me so that I can
add it to 1.0-beta.8.2 ... the missing methods and classes might be due
to the fact that I haven't got your changes to the Squeak package yet:)

Dale

Paul DeBruicker wrote:

Hi Dale,

I might have done a bad job explaining and I'm uncertain how do to what
you recommend.  I have Metacello configurations, but I think its a
different error than that or the ones I've made are insufficient on
Gemstone and OK on Pharo.  From what I can tell the classes it needs are
in the package I'm loading when the error occurs.  I don't know if it
will happen for you on your Gemstone setup but to see an example of this
is to load Seaside30: Base, Javscript-Core, JQuery-Core, JQuery-UI; then
from

MCHttpRepository
     location: 'http://www.squeaksource.com/JQueryWidgetBox'
     user: ''
     password: ''


  the package:
JQWidgetBox-Core-tbn.2.mcz

then the package:
JQWidgetBox-FullCalendar-Core-PaulDeBruicker.10.mcz

When I load the JQWidgetBox-FullCalendar package it complains that I
need to load the JQFullCalendar class.  The JQFullCalendar class is
defined in the JQWidgetBox-FullCalendar package.  JQFullCalendar is a
subclass of JQWidget which is provided by JQuery-UI I think. JQWidget is
definitely in my stone when I go to load JQWidgetBox-FullCalendar.  When
I load those packages in that order in a Pharo 1.1 dev image I get no
errors.

If what you're saying is that there are other classes that I need to
load and that the warning does not explicitly mention then I don't know
how to determine what those might be from the error messages.  Is it
just a matter of reviewing the JQFullCalendar class in Pharo, seeing
what types of objects are called then checking that they're in the stone
or not?

Thanks in advance for walking me through it.

Paul

Paul,

I don't have time to reproduce the problem today, but have you tried:

   (ConfigurationOfJQueryWidgetBox project latestVersion)
        load: #('JQWidgetBox-FullCalendar-Core').

before loading your local package? If you use the configuration to load
the package then all of the required packages will be loaded correctly...

Dale

Paul DeBruicker wrote:

Hi Dale,

The same problem occurs.  When I use the code you list above, the class
JQFullCalendar is not loaded and no warning is given.  When I then use
the monticello browser to load the package, the warning about
JQFullCalendar appears and the code for that class is not loaded.   When
I try the above procedure in Pharo the code is loaded and works fine.

Thanks for being attentive.

Paul

Paul,

Hmmm, I assume that you are loading these packages into a 2.4.4.1 extent?

There are no platform-specific packages in
(ConfigurationOfJQueryWidgetBox???

Can you tell me what package(s) the missing classes are in the Pharo
image? That'll help isolate the problem ...

Dale

Paul DeBruicker wrote:

Hi Dale,

I am loading them into a 2.4.4.1 extent.  I am using the
GemTools1.0-beta.8 one click app.  I did upgrade the GLASS to
1.0-beta8.2, but it happens without the upgrade as well. To load seaside
3 I've been using:
Gofer project
     load: 'Seaside30'
     group: #('Base' 'Development' 'Javascript-Core' 'JQuery-Core'
'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' 'Seaside-InternetExplorer'
'Seaside-Adaptors-FastCGI'  ).


     As near as I can tell the only missing class once
JQWidgetBox-FullCalendar-Core has "loaded" is JQFullCalendar.  The class
JQFullCalendar is provided by the package
JQWidgetBox-FullCalendar-Core.   The exact same package that is throwing
the error about needing JQFullCalendar to be loaded for the load to
work.  The monticello loading process seems to think it needs a class
thats defined by the package I'm loading before it can load the package
I'm loading.  Its as if its saying that in order to sign up for
Chemistry 101 you must have completed Chemistry 101.

     JQWidgetBox-FullCalendar-Core only provides 2 classes
JQFullCalendarEvent and JQFullCalendar & 3 extensions.  
JQFullCalendarEvent & the extensions appear to load just fine.  
JQFullCalendar does not load at all.

I'm doing two processes and getting the same result:

Process 1:
1. Browse the JQWidgetBox repo on squeaksource.
2. Load the JQWidgetBox-Core package.
3. Load the JQWidgetBox-FullCalendar-Core package.
4. Get the error about JQWidgetBox-FullCalendar-Core depending on
JQFullCalendar.
5. Hitting proceed, and seeing that JQFullCalendar is not loaded at all
and that JQFullCalendarEvent is loaded as well as the three extension
methods.
6. Getting very confused.

Process 2:
1. Load the ConfigurationOfJQueryWidgetBox from squeaksource Metacello repo.
2. run:

    (ConfigurationOfJQueryWidgetBox project latestVersion)
        load: #('JQWidgetBox-FullCalendar-Core').

3. Get the error about JQWidgetBox-FullCalendar-Core depending on
JQFullCalendar.
4. Hitting proceed, and seeing that JQFullCalendar is not loaded at all
and that JQFullCalendarEvent is loaded as well as the three extension
methods.
5.  Getting very confused.


At this point I'd say there's something very wrong with my packaging
style because this same problem has happened on two of my packages; the
FullCalendar one and another one on my hard drive.  Other JQWidgetBox
packages load just fine.

Thanks again for any insights you might have,

Paul

Paul,

When I get a chance I'll try loading these puppies and see what I can
figure out ... something odd definitely appears to be going on:)

Dale

Paul DeBruicker wrote:

Paul DeBruicker wrote: Paul,

There is a bug, but I'm still characterizing the problem...

Dale

Paul,

Okay, it looks to me like your mcz file(s) are "corrupted" ... probably
due to a bug in Pharo 1.2 (that's the version you're using right?).

In an mcz file the snapshot of the definitions are serialized using two
formats:

   1. a DataStream on an ordered collection of MCDefintions
   2. a chunk-file formatted string.

It appears that for the DataStream, the entire(?) stream is written as a
WideString ... WideString is Squeak/Pharo dependent and is not portable
at all ... this is new. When GemStone hits the widestring an error is
thrown and Monticello tries to use the chunk-file format (which is why
you ran into the preamble probelm ... chunk file format is normally hit
(nor is it desirable to hit it)...

The chunk file-file is partially written as a WideString again...because
  the WideString is not portable it breaks the parsing algorithms for
GemStone ... interestingly enough the chunk-file string looks to be a
WideString for the first hundred characters or so ...

One of three things is happening:

   1. someone in Pharo land decided it was a "good idea" to create mcz
      files using WideString
   2. The that you used to create the class had a WideString in it
   3. there is a bug somewhere in the pharo/monticello implementation

I can't guess which of those 3 the problem is and I can't guess what the
solution might be either.

If you bring up this bug on the Pharo list, I'll monitor the list and if
I can step in and help, I will.

Dale


Dale Henrichs wrote: