[7.7.1] Bundle's #traceVersion is empty during post-load

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Boris:

> The below post-load used to set our application version in 7.7, but in 7.7.1 p’s traceVersion returns empty string during the block’s execution… Could it be some side effect of the changes to atomic loader? How would I go about obtaining a version at this point?
>  
> [:p | Something version: p traceVersion]
>  
> Immediately after the load completes, I am able to obtain the version string via,
>  
> (Store.Registry bundleNamed: ‘Bundle’) traceVersion  ->  ‘8076.1’

#traceVersion if one looks closely, is a database lookup method. IOW, that value does not actually exist in the image, and instead looked up in the database.

Now, the issue here is that the atomic loader does not set the "dbTrace" of the package's database information (or any of the packages or bundles in that load) until the very end of a load process (see #applyPundleVersionsToTheImage), which happens AFTER postLoad: is sent.

So, messages that depend on information associated with dbTrace, and in fact, any DatabaseConnectionInformation (or for a Bundle, DatabaseConnectionBundleInformation) information/messages, is not (or to be more accurate "no longer") appropriate for postLoad: methods.

That means I have no solution for your situation. I tried to think of a way to create a solution for you, but for now, there is none.

That said, maybe the postLoad: needs to be re-written so that it sends two things: The PundleModel object  and the StorePundle object. That way you can extract anything that is in the Database object (StorePundle) that you might want.

Of course, that doesn't help you now. Sorry

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thanks for that, I'll look for a work-around, but shouldn't "post"-load action really run after the load completes in its entirety?

-Boris (via BlackBerry)

----- Original Message -----
From: Samuel S. Shuster <[hidden email]>
To: Boris Popov, DeepCove Labs (SNN)
Cc: VWNC <[hidden email]>
Sent: Mon Sep 06 14:51:49 2010
Subject: Re: [vwnc] [7.7.1] Bundle's #traceVersion is empty during post-load

Boris:

> The below post-load used to set our application version in 7.7, but in 7.7.1 p’s traceVersion returns empty string during the block’s execution… Could it be some side effect of the changes to atomic loader? How would I go about obtaining a version at this point?
> 
> [:p | Something version: p traceVersion]
> 
> Immediately after the load completes, I am able to obtain the version string via,
> 
> (Store.Registry bundleNamed: ‘Bundle’) traceVersion  ->  ‘8076.1’

#traceVersion if one looks closely, is a database lookup method. IOW, that value does not actually exist in the image, and instead looked up in the database.

Now, the issue here is that the atomic loader does not set the "dbTrace" of the package's database information (or any of the packages or bundles in that load) until the very end of a load process (see #applyPundleVersionsToTheImage), which happens AFTER postLoad: is sent.

So, messages that depend on information associated with dbTrace, and in fact, any DatabaseConnectionInformation (or for a Bundle, DatabaseConnectionBundleInformation) information/messages, is not (or to be more accurate "no longer") appropriate for postLoad: methods.

That means I have no solution for your situation. I tried to think of a way to create a solution for you, but for now, there is none.

That said, maybe the postLoad: needs to be re-written so that it sends two things: The PundleModel object  and the StorePundle object. That way you can extract anything that is in the Database object (StorePundle) that you might want.

Of course, that doesn't help you now. Sorry

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Boris:

> Thanks for that, I'll look for a work-around, but shouldn't "post"-load action really run after the load completes in its entirety?

Actually, that seems right, but once we moved past package at a time (direct) bundle ordered loading, these things got complicated.

An example: Lets say you have a bundle which has within it a package that forces an early install... ie. Redefinition of a Class or Namespace, or is a Binary package, or the package, such as yours, has a postLoadBlock: (yes, that too is a signal for an early install).

The rest of the Bundle is not as yet in the system, and thus not all of the dbInfo is available at that time. So, a hole opens where not all of the Bundle is in the system and yet it is time to run the postLoadBlock of your package.

So, what seems right, isn't for some things. All classes and shareds and namespaces in that Package and prior Packages are guaranteed to be in the system and alive, but these database information objects are not.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc