Portability of GLORP from VisualWorks to Pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Portability of GLORP from VisualWorks to Pharo

Esteban A. Maringolo
Hi,


tl;dr question: How can I contribute code to the GLORP codebase in the
current VW version? Where do I get credentials for the Cincom Public
Repository?

As said before, I'm (again) porting GLORP from VW to Pharo, and I'd
like to keep the port as maintainable as possible, it is... easy to
update when significant changes are made in the main codebase
(VisualWorks).


--- Long version ---

For such purpose, I'm using the Monticello exporter referenced by
Marteen Mostert in a previous thread.

One of the problems I found by using it, is that I have to export each
bundle as a Monticello Package, causing dependencies that can't be
resolved during load time in Pharo, no matter what order I use.

For that purpose I modified the exporter to export not only Store
Packages but also to export Store Bundles, so I would end up with a
Glorp.mcz Monticello Package (BTW, that's how it works in the existing
port).

However the problem with that is that once the packages are loaded
into Pharo (I guess the same applies for Squeak) the package
organizations depends on the Category of the classes, so the
'GlorpDatabase' category ends up in a different package, when it
should be in the Glorp package. For that reason I modify the export to
convert the category to a "proper" category name, it is
'GlorpDatabase' becomes 'Glorp-Database', and 'GlorpCore' becomes
'Glorp-Core' and so on.

However there are some methods/classes with "weird" categories, such as:
MjlGlorp, MyClasses, eoglorp and KernelSupport (for the Dialect
class). I believe those are mistakes or simply wrongly categorized
classes and methods.

QUESTION: Can I modify these classes to have more GLORP related names?
If so, how to publish back to the Store repository?

Additionally, there are some methods that require modifications, for
instance Dialect doesn't consider Pharo as a platform (only Squeak).

If anybody is willing to take a look at the attached fileouts and
exported Bundle (Glorp.mcz), you are going to see my changes to the MC
export, which I don't expect to be integrated in the main trunk
because although it only modifies the categories of the exported
method/classes it changes the output from the previous version (I
can't measure how relevant this is).

As said before I'd like to keep VW and Pharo versions as close as
possible, but if its not possible, we will have to fork.

Regards!


Esteban A. Maringolo

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

StoreClassDefinition-asMCClassDefinition.st (2K) Download Attachment
StoreMethod-asMCMethodDefinition.st (1K) Download Attachment
StoreBundle-asMCPackageversionauthorcomment.st (2K) Download Attachment
String-asMCCategory.st (1K) Download Attachment
PublishVersionTool-publish.st (1K) Download Attachment
Glorp-EAM.5.mcz (404K) Download Attachment
Loading...