Smalltalk › Frameworks & Tools › Magritte, Pier and Related Tools

Pier port to Magritte with pragmas

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

Nick

Pier port to Magritte with pragmas

Hi,

I've checked-in an initial port of Pier using Magritte with pragma support into: http://source.lukas-renggli.ch/pier2unstable - all tests are green and with a cursory test everything appears to be functioning as before.

The port includes the following packages:

pier-model

pier-seaside

pier-security

pier-pharo-model

pier-pharo-persistency

pier-tests-model

pier-test-security

and the following add ons:

pier-blog

pier-book

pier-setup

pier-google

pier-documents

Next steps:

1) Be great if people can try the initial port and report any errors or different behaviour

2) If success with 1) perhaps we can move to new repositories (e.g. Magritte3, Pier3, Pier3addons)

3) Continue porting addons. There are many add-ons in both http://source.lukas-renggli.ch/pieraddons and http://source.lukas-renggli.ch/pier2addons that would be great to port.

4) Document the changes to Magritte and how they effect Pier.

Porting guide:

1) search for all instances of #description if they are magritte descriptions rename the method #magritteDescription
2) remove #magritteDynamic and remove the block around the method.
3) Use the refactoring support to move class-side descriptions to instance side descriptions with pragmas - making sure that any accessors to class side methods are either prefixed with ‘class’ or moved to the instance side. If you move description help methods to instance side be careful if they contain context := PRCurrentContext value - context will shadow an instance variable of the same name so either replace context with self context and remove context := PRCurrentContext value or rename context say theContext and replace context := PRCurrentContext value with theContext := self context.
4) Remove any empty categories on the class side.

5) PRWidget derived classes should either by modified to be derived from PRWidgetPropertyBase or keep derived from PRWidget but modify the accessors to store state in instance variable rather than the property dictionary in PRWidgetPropertyBase. See PRViewsWidget and PRSearchWidget for examples of both types of port.

6) Modify structure initialisation with PRComponent to use prototype instance rather than classes. So

(PRComponent named: 'contents')
componentClass: PRContentsWidget;
write: '%c' using: PRContentsWidget descriptionHeading;
yourself

becomes to:
(PRComponent named: 'contents') prototypeInstance: (PRContentsWidget new heading: '%c'; yourself)
yourself

you may well have to add setters to allow initial settings to be set on the prototype instances again see PRViewsWidget and PRSearchWidget for examples.

7) Put a break point in Object>>description and Object class>>description to trap any cases you’ve missed (the break-point should not be hit) and check the add-on.

Hope this makes sense

Nick

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

MagrittePackageRefactoring.png (87K) Download Attachment

Yanni Chiu

Re: Pier port to Magritte with pragmas

On 24/01/12 8:10 AM, Nick Ager wrote:
> 1) Be great if people can try the initial port and report any errors or
> different behaviour

I was able to build and run it on a recent Pharo-1.4 image.
Next, I'll try to port my code.

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Yanni Chiu

Re: Pier port to Magritte with pragmas

On 25/01/12 12:40 AM, Yanni Chiu wrote:
> Next, I'll try to port my code.

Following the porting hints, most everything went smoothly.

As I expected, the trouble arose in areas where I was creating
instance-based magritte descriptions. In my PRComponent subclasses I was
already creating prototype instance, it seems. I tried a few things to
fix things up, but could not get everything to work right yet.

I'm not going to complete the port until it becomes clear what the
timeline is for adopting the new code, because I don't want to maintain
two code streams.

The new pragma approach looks good though.

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Nick

Re: Pier port to Magritte with pragmas

Hi Yanni,

As I expected, the trouble arose in areas where I was creating instance-based magritte descriptions. In my PRComponent subclasses I was already creating prototype instance, it seems. I tried a few things to fix things up, but could not get everything to work right yet.

That's interesting I've never derived from PRComponent, always PRWidget or PRViewComponent

I'm not going to complete the port until it becomes clear what the timeline is for adopting the new code, because I don't want to maintain two code streams.

I guess the only impediment to adopting the new code is ensuring it doesn't introduce any nasty bugs - the more people testing it - the more confident we can be.

Nick

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

drush66

Re: Pier port to Magritte with pragmas

On Thu, Jan 26, 2012 at 11:27 AM, Nick Ager <[hidden email]> wrote:
> I guess the only impediment to adopting the new code is ensuring it doesn't
> introduce any nasty bugs - the more people testing it - the more confident
> we can be.

Well, once the dust settles, I guess migrating old pier instances
people are using could raise all kind of strange issues. (not that I
am ungratefull for progress :)

Davorin Rusevljan
http://www.cloud208.com/
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

http://www.cloud208.com/

Nick

Re: Pier port to Magritte with pragmas

Hi Davorin,

Well, once the dust settles, I guess migrating old pier instances
people are using could raise all kind of strange issues. (not that I
am ungratefull for progress :)

That's a great point. One of the issues with Pier is how to upgrade to a new version - I found this particularly challenging on Gemstone as I ended up with multiple version of the same class (#classHistory size ~= 1) which caused strange bugs with class equality checks in the code-base.

One idea I came up with is to build an exporter which generates Pier kernel creation code based on the data currently in Pier - it's a lazy design as I only have to write an exporter not an importer. I've used it successfully on a few smaller projects but have yet to try it on more substantial projects.

The code is available in http://source.lukas-renggli.ch/pier2addons - package Pier-Exporter-Code.

To use it:

PRKernelCodeExporter exportKernel: (PRKernel instances detect: [: each | each name = 'pier']).

The exporter generates PierKernelCreator

and the kernel can be recreated with:

PierKernelCreator new createKernel

A Pier upgrade procedure could then be:

1) load PRKernelCodeExporter

2) export your kernel to code

3) try to regenerate your kernel

4) if 3 is successful then export the created code; PierKernelCreator

5) load PierKernelCreator and any of your custom Pier code into a Pier image with pragma support

6) Ensure that all add ons you use have been ported, including any of your own code using the porting guide outlined at the start of this thread.

I will add PRKernelCodeExporter class>>#exportMigratedKernel: which will generate #prototypeInstance initialisation for PRComponents, but first I'd like feedback if people think this approach is worth pursuing in theory and if so, in practice does the PRKernelCodeExporter work on your existing kernels?

Nick

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

drush66

Re: Pier port to Magritte with pragmas

On Thu, Jan 26, 2012 at 12:28 PM, Nick Ager <[hidden email]> wrote:
> Hi Davorin,
>
> One idea I came up with is to build an exporter which generates Pier kernel
> creation code based on the data currently in Pier - it's a lazy design as I
> only have to write an exporter not an importer. I've used it successfully on
> a few smaller projects but have yet to try it on more substantial projects.
...
> I will add PRKernelCodeExporter class>>#exportMigratedKernel: which will
> generate #prototypeInstance initialisation for PRComponents, but first I'd
> like feedback if people think this approach is worth pursuing in theory and
> if so, in practice does the PRKernelCodeExporter work on your existing
> kernels?

I can not look at it more deeply now, but it seems to me like a good
idea, because if something goes wrong with import (if being close to
rhetorical;), one would probably be able to hack the generated code by
hand until it can create valid PRKernel instance. Which might be
simpler than hacking the binary representation in file, or
transforming the somehow mis-loaded object tree in memory.

I have one ancient Pier 1.x kernel on which I might try that, once I
find some time. Do you think that PRKernelCodeExporter might have a
chance working on old kernels (there has been some variables
additions, removing, etc).

Davorin
http://www.cloud208.com/

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

http://www.cloud208.com/

Yanni Chiu

Re: Pier port to Magritte with pragmas

In reply to this post by Nick

On 26/01/12 5:27 AM, Nick Ager wrote:
>
> That's interesting I've never derived from PRComponent, always PRWidget
> or PRViewComponent

It's possible that I didn't know what I was doing at the time (i.e. just
learning how to use Pier). I should look into it.

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Dale Henrichs

Re: Pier port to Magritte with pragmas

In reply to this post by Nick

Nick,

Yes I seem to recall that Pier was using the class as an index into a collection or the hash of the class was used in an equality comparison and in GemStone class identity is just not preserved over time, so different class versions have different hash values ... Maybe we should tackle these issues sometime, or have you found your exporter to be a better solution?

Dale

----- Original Message -----
| From: "Nick Ager" <[hidden email]>
| To: "Pier and Related Tools Magritte ..." <[hidden email]>
| Sent: Thursday, January 26, 2012 3:28:01 AM
| Subject: Re: Pier port to Magritte with pragmas
|
|
| Hi Davorin,
|
|
|
|
|
|
|
| Well, once the dust settles, I guess migrating old pier instances
| people are using could raise all kind of strange issues. (not that I
| am ungratefull for progress :)
|
|
|
| That's a great point. One of the issues with Pier is how to upgrade
| to a new version - I found this particularly challenging on Gemstone
| as I ended up with multiple version of the same class (#classHistory
| size ~= 1) which caused strange bugs with class equality checks in
| the code-base.
|
|
| One idea I came up with is to build an exporter which generates Pier
| kernel creation code based on the data currently in Pier - it's a
| lazy design as I only have to write an exporter not an importer.
| I've used it successfully on a few smaller projects but have yet to
| try it on more substantial projects.
|
|
| The code is available in http://source.lukas-renggli.ch/pier2addons -
| package Pier-Exporter-Code.
|
|
| To use it:
|
|
|
| PRKernelCodeExporter exportKernel: (PRKernel instances detect: [:
| each | each name = 'pier']).
|
|
| The exporter generates PierKernelCreator
|
|
| and the kernel can be recreated with:
|
|
|
| PierKernelCreator new createKernel
|
|
| A Pier upgrade procedure could then be:
|
|
| 1) load PRKernelCodeExporter
| 2) export your kernel to code
| 3) try to regenerate your kernel
| 4) if 3 is successful then export the created code; PierKernelCreator
| 5) load PierKernelCreator and any of your custom Pier code into a
| Pier image with pragma support
| 6) Ensure that all add ons you use have been ported, including any of
| your own code using the porting guide outlined at the start of this
| thread.
|
|
| I will add PRKernelCodeExporter class>>#exportMigratedKernel: which
| will generate #prototypeInstance initialisation for PRComponents,
| but first I'd like feedback if people think this approach is worth
| pursuing in theory and if so, in practice does the
| PRKernelCodeExporter work on your existing kernels?
|
|
| Nick
|
|
| _______________________________________________
| Magritte, Pier and Related Tools ...
| https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Nick

Re: Pier port to Magritte with pragmas

Hi Dale,

Yes I seem to recall that Pier was using the class as an index into a collection or the hash of the class was used in an equality comparison and in GemStone class identity is just not preserved over time, so different class versions have different hash values ... Maybe we should tackle these issues sometime, or have you found your exporter to be a better solution?

I think having both would be ideal - an exporter and the ability to safely upgrade in-place.

I had a problem upgrading my Pier instance on Gemstone when classes that are held in an instance variable change shape. The situation should be slightly better with Migritte with pragmas as PRComponent now holds a prototype instance rather than a componentClass. However there are other places that hold a class then check for equality e.g. PUSecurity, PUPermission

Nick

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Nick

Re: Pier port to Magritte with pragmas

In reply to this post by drush66

Hi Davorin,

I have one ancient Pier 1.x kernel on which I might try that, once I
find some time. Do you think that PRKernelCodeExporter might have a
chance working on old kernels (there has been some variables
additions, removing, etc).

I've only tried it on a few Pier 2 kernels. Today I've made some revisions to the code to hopefully make it more compatible with Pier 1.x kernels, however you will at least need to modify a method #compile:into:classified: which uses grease's GRPlatform that is only available with Seaside 3.0. There are probably other issues with exporting Pier 1.x kernels - be great for someone to try and see how useful the code is.

I've made a couple of other changes:

* Renamed PRKernelCodeExporter to PRPier2CodeExporter to be explicit that it's designed for Pier 2 with Magritte 2 and will have to be modified for exporting for Pier with Magritte pragmas (though it should work with Pier 1 and Magritte 1 with the above caveats)

* added PRPier2CodeExporter>>#exportMigratedKernel: to export the kernel in a form ready for Pier with Magritte pragmas - the behaviour of PRComponent based structures is changed to use the new #prototypeInstance: rather than #write:using: semantics.

So to check how well the exporter will work with your existing kernel:

PRPier2CodeExporter exportKernel: (PRKernel instances detect: [: each | each name = 'pier']).

If the exporter works OK then prepare to upgrade with:

PRPier2CodeExporter exportMigratedKernel: (PRKernel instances detect: [: each | each name = 'pier']).

Two major caveats:

1) the exporter currently doesn't export owner, group or other permissioning details on the structures.

2) the exporter current doesn't export the users of the kernel.

Both are quite possible to do, I just haven't got round to it yet.

Nick

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

drush66

Re: Pier port to Magritte with pragmas

On Fri, Jan 27, 2012 at 12:03 AM, Nick Ager <[hidden email]> wrote:
> Hi Davorin,
> So to check how well the exporter will work with your existing kernel:

Ok so , as you have4 anticipated one source of problems with exporting
pier1 kernel was that exporter is dependent on Grease, and for some
reason I can not load Grease into my pier 1.1.1 image (metacello fails
to bootstrap itself).

So I have created Dummy GRObject, which let me load exporter package.
Next obstacle was that PRStructure was missing absolutePath method, so
I copied one from Pier2.

After that I had to implement greaseString on Object.

And here I think I have stuck, code generator spits the code with
syntax error, seems like way too many apostrophes smugle in:

mainenvironment
| structure |
structure := PRPage named: 'mainenvironment'.
structure title: #('_''M''a''i''n'' ''E''n''v''i''r''o''n''m''e''n''t').
structure contents: #('<''d''i''v''
''c''l''a''s''s''=''"''c''o''n''t''a''i''n''e''r''"''>''\r''\t''+''/''e''n''v''i''r''o''n''m''e''n''t''/''h''e''
....

It could be because I do not have proper Grease, but more likely it
could also be result of using WAKomEncoded, and something funny going
on with unicode characters. So maybe it would be good idea if someone
has encoded 2.0 kernel to check with it, since maybe there is problem
also.

I do not have many pages, so I guess old fashioned manual migration
will also work :) What worries me is that I also have "live" counter
example inside pier blog, and I am not sure how and if will it make to
new pier with cookies (if I am understanding the discussion in other
thread about sessions)

For the new Pier3 does it work in Pharo 1.3 or 1.4?

Thanks!

Davorin Rusevljan
http://www.cloud208.com/

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

http://www.cloud208.com/

Nick

Re: Pier port to Magritte with pragmas

Hi Davorin,

Thanks for the report. When I get the chance I'll try it on a Pier 1.x kernel and see if there are some simple things I can do to fix the exporter for Pier 1.x and Seaside 2.8. Of course there are other export and import methods which may work for you.

What worries me is that I also have "live" counter
example inside pier blog, and I am not sure how and if will it make to
new pier with cookies (if I am understanding the discussion in other
thread about sessions)

It will work - just currently with the Pier 2 code base the state will be reset for each RESTful call.

For the new Pier3 does it work in Pharo 1.3 or 1.4?

Currently I've only tested on Pharo 1.3, but I guess there will be some of us who want it to work on Pharo 1.4 so I'm sure someone will fix any (if any) issues

Nick

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

drush66

Re: Pier port to Magritte with pragmas

On Fri, Jan 27, 2012 at 11:34 AM, Nick Ager <[hidden email]> wrote:
> Hi Davorin,
>
> Thanks for the report. When I get the chance I'll try it on a Pier 1.x
> kernel and see if there are some simple things I can do to fix the exporter
> for Pier 1.x and Seaside 2.8. Of course there are other export and import
> methods which may work for you.

Yes, I do not think you should waste more time on 1.0 since it is rare
case, and I have other options. But checking exporter on Encoded 2.0
kernel might be a good idea.

> It will work - just currently with the Pier 2 code base the state will be
> reset for each RESTful call.

hm - so when blog reader clicks on + in the example, the counter would
not actually increase as advertised? :) I think I will need to get rid
of that example.

Davorin

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

http://www.cloud208.com/

Nick

Re: Pier port to Magritte with pragmas

hm - so when blog reader clicks on + in the example, the counter would
not actually increase as advertised? :) I think I will need to get rid
of that example.

No it *will* work. The issue (currently) in Pier 2 is if you have cookies enabled and you return to the same blog/blog post via a RESTful url the counter will be reset to zero. This is different to the behaviour in Pier 1.x where the counter maintains it's state when cookies are enabled between RESTful calls.

Nick

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki