24 Jan
2012
24 Jan
'12
2:10 p.m.
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) P**ut 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*
*
*
26 Jan
26 Jan
6:32 a.m.
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.
11:27 a.m.
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
11:50 a.m.
On Thu, Jan 26, 2012 at 11:27 AM, Nick Ager <nick.ager(a)gmail.com> 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/
12:28 p.m.
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
3:29 p.m.
On Thu, Jan 26, 2012 at 12:28 PM, Nick Ager <nick.ager(a)gmail.com> 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/
27 Jan
27 Jan
12:03 a.m.
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
11:19 a.m.
On Fri, Jan 27, 2012 at 12:03 AM, Nick Ager <nick.ager(a)gmail.com> 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/
11:34 a.m.
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
11:45 a.m.
On Fri, Jan 27, 2012 at 11:34 AM, Nick Ager <nick.ager(a)gmail.com> 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
11:56 a.m.
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
26 Jan
26 Jan
6:17 p.m.
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" <nick.ager(a)gmail.com>
| To: "Pier and Related Tools Magritte ..." <smallwiki(a)iam.unibe.ch>
| 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
9:36 p.m.
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
4472
days inactive
4475
days old
14 comments
4 participants
participants (4)
-
Dale Henrichs -
Davorin Rusevljan -
Nick Ager -
Yanni Chiu